--- title: "Sorena AI" canonical_url: "https://www.sorena.io" source_url: "https://www.sorena.io/" author: "Sorena AI" description: "Empower every team involved in governance, risk, and compliance with AI that delivers verified, cited answers in seconds." keywords: - "legal tech" - "cybersecurity" - "GRC" - "governance" - "risk" - "compliance" - "AI solutions" - "workflow automation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Modern Governance Risk & Compliance Empower every team involved in governance, risk, and compliance with AI-powered solutions. We streamline workflows, eliminate redundancies, and enhance efficiency for smarter, faster, and more effective performance across your organization. [Get Started](#one-platform-for-all-your-compliance-needs) ![Sorena AI's modern governance, risk, and compliance platform interface](https://cdn.sorena.io/images/hero-1.jpg) *Platform Preview* ## One Platform for All Your Compliance Needs Built for security, legal, compliance, engineering, and operations teams working together on governance, risk, and compliance. ### Platform Screenshots - ![Sorena Assessment Autopilot overview with AI-driven compliance scoring](https://cdn.sorena.io/images/assessment-6.png) - ![Compliance document management dashboard](https://cdn.sorena.io/images/ssot-3.png) - ![Assessment workflow automation interface](https://cdn.sorena.io/images/assessment-1.png) - ![Risk assessment questionnaire builder](https://cdn.sorena.io/images/assessment-2.png) - ![Document library with smart categorization and search](https://cdn.sorena.io/images/ssot-1.png) - ![AI-powered document analysis and extraction](https://cdn.sorena.io/images/ssot-2.png) - ![Assessment results and gap analysis view](https://cdn.sorena.io/images/assessment-3.png) - ![AI research copilot with citation support](https://cdn.sorena.io/images/copilot-researcher-1.png) - ![Research assistant with multi-source analysis](https://cdn.sorena.io/images/copilot-researcher-4.png) - ![Sorena platform unified compliance dashboard](https://cdn.sorena.io/images/platform-1.png) - ![Platform document library and search interface](https://cdn.sorena.io/images/platform-3.png) - ![Platform assessment automation workflow](https://cdn.sorena.io/images/platform-4.png) - ![Platform analytics and reporting dashboard](https://cdn.sorena.io/images/platform-5.png) *When Work Blocks Work* ## Where Complexity Kills Productivity Employees are overloaded with governance, compliance, and deadlines, leading to stalled innovation and minimal delivery to the market. > Bare Minimum Delivery - **Business**: Started Passionately (Capacity: Full | Stress: Optimal) ![Business](https://cdn.sorena.io/images/1-business.png) CTA: Transform Your GRC - **Governance**: Wasted Productivity (Capacity: High | Stress: Manageable) ![Governance](https://cdn.sorena.io/images/2-governance.png) CTA: Optimize Governance - **Risk**: Reduced Deliveries (Capacity: Moderate | Stress: Challenging) ![Risk](https://cdn.sorena.io/images/3-risk.png) CTA: Manage Risk Smartly - **Compliance**: Employee Burnout (Capacity: Low | Stress: Critical) ![Compliance](https://cdn.sorena.io/images/4-compliance.png) CTA: Emergency Recovery - **Deadline**: Delayed Time to Market (Capacity: Minimal | Stress: Burnout) ![Deadline](https://cdn.sorena.io/images/5-deadline.png) CTA: Crisis Intervention *Speed Meets Accuracy* ## Where AI Drives Efficiency Transform your organization with AI-powered solutions that centralize data, enhance productivity, and automate workflows, enabling teams to focus on innovation instead of administration. ### STEP 1 - Single Source of Truth [DATABASE] Your business data + legal libraries + public sources integrated in one unified system Source-Linked Data Integrity | Multi-Region Coverage ### STEP 2 - Instant Answers [REACTIVE AI] Ask questions, get instant answers with precise references and deep context Instant Responses | Cited Every Answer ### STEP 3 - Works While You Sleep [PASSIVE AI] Continuously monitors changes, sends alerts, and keeps you ahead of the curve Hands-Free Alerting | Real-Time Monitoring ### RESULT - Peak Performance [SUCCESS] Teams focus on innovation while AI handles the heavy lifting. From fire-fighting to future-building Streamlined Workflows | Audit-Ready Operations > From Burnout to Breakthrough: Your AI-Powered Transformation *Unified Data Platform* ## Single Source of Truth Unified intelligence from regulations, standards, and your data, all AI-ready with enterprise-grade security ### Regulatory Intelligence - **Laws & Regulations**: EU, US, APAC, Global jurisdictions - **Court Cases**: De facto and de jure precedents - **Legislative Updates**: Real-time regulatory changes Multi-Region Coverage | Structured Taxonomy ### Standards Library - **Industry Standards**: NIST, ISO, ETSI, CEN/CENELEC - **Frameworks**: SOC2, PCI-DSS, HIPAA, GDPR - **Best Practices**: Industry guidelines + custom Deep Document Index | Source-Linked References ### Your Data Integration - **Smart Browser**: AI scraping with multimedia support - **Integrations**: Confluence, GDrive, MS365 - **Trusted Sources**: Verified public documents Real-time Sync | AI-Ready Search *Intelligent AI Agents* ## AI Agents with Grounded Intelligence Expert AI agents that deliver verified answers backed by real regulations - no guesswork, just facts ### Virtual Colleague (Agent) On-Demand - **Expert AI Agents On Demand**: vCISO • Risk • Legal • Privacy • Audit • Security • Compliance - **Always Right, Always Cited**: Exact law citations, not Wikipedia guesses - **Speaks Everyone's Language**: Bridges legal and technical teams Source-Linked Every Answer | Traceable Citations | Expert-Level Analysis | On-Demand Availability ### Real Impacts - **Ship Faster**: Transform ideas into compliant products in days, not months - **Focus on Innovation**: Teams focus on innovation while AI handles compliance - **Build Customer Trust**: Deliver quality with verified compliance built into every product Rapid Time-to-Market | Hands-Free Workflows | Days Not Months | Policy-Aligned Outputs *Intelligent Copilot* ## Your AI Copilot That Works With You Context-aware assistance that understands your workflow, anticipates needs, and accelerates every task ### Smart Workflow Copilot - **Understands Context**: Learns your processes and adapts - **Predicts Next Steps**: Suggests actions before you ask - **Automates Repetitive Tasks**: One click instead of hundred Instant Retrieval | Intuitive Interface ### Instant Document Generator - **Write Like You Talk**: Tell AI what you need, get perfect docs - **Your Style, Your Voice**: Learns and matches your tone - **Always Current**: Updates with latest regulations Accelerated Delivery | Policy-Aligned By Design ### Decision Intelligence Engine - **See Around Corners**: Spot risks others miss - **Data-Driven Recommendations**: Facts guide every decision - **What-If Scenarios**: Explore every angle before deciding Proactive Risk Detection | Real-Time Insights Learn More About Intelligent Copilot → *Smart Autopilot* ## AI That Works While You Sleep Autonomous AI that runs your operations for governance, risk, and compliance with zero manual work ### Full Workflow Delivery - **Full Assessments**: Wake up to completed work - **Risk Scoring**: Real-time position updates - **Evidence Collection**: Auto-gathered and organized End-to-End Automation | Audit-Ready Evidence ### Active Monitoring 24/7 - **Regulatory Updates**: Instant law change alerts - **Risk Thresholds**: Proactive breach warnings - **Deadline Tracking**: Never miss compliance dates Real-Time Alerting | Continuous Oversight ### Smart Guardrails - **Thousands of Policies**: Pre-built and maintained - **Daily Updates**: Always current standards - **Zero Configuration**: Works out of the box - approve or AI-revise Broad Framework Support | One-Click Deployment Learn More About Smart Autopilot → *Complete Platform* ## See How It All Works Together From a single source of truth to autonomous operations. Explore our complete solutions and see how each layer builds on the next. - **Database**: Unified foundation of verified public and private data that powers every system, AI agent, and workflow with trusted information. - **Assistants**: Intelligent AI orchestrator that coordinates specialized workers to deliver verified answers with complete source citations. - **Copilots**: Real-time AI assistant that understands context and accelerates workflows with instant, compliant document generation. - **Autopilots**: Autonomous AI engine that detects triggers, executes workflows, and maintains compliance operations automatically. ### Read more about AI Assessments *New* Automate all types of security and compliance assessments, including SOC 2, ISO 27001, and vendor due diligence. AI maps controls across frameworks and provides you with a complete evidence-based report. [Explore Our Solutions](/solutions.md) [Talk to Us](/contact.md) *Live Demo* ## Ready to Transform Your Business? Experience how our AI-powered solutions revolutionize your GRC operations - see the platform in action ### See How We Transform Your GRC Operations Book a personalized demo to discover how our AI platform can automate your compliance, reduce risk, and save months of manual work. 30 min - Quick Discovery | 1 hour - Platform Demo | Custom - Executive Briefing [Book Your Demo](/contact.md) No credit card required • Available same day --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/ --- --- title: "Solutions" canonical_url: "https://www.sorena.io/solutions" source_url: "https://www.sorena.io/solutions" author: "Sorena AI" description: "Discover Sorena AI's layered solutions: Database foundation, AI Assistants for verified answers, Copilots for real-time workflows." keywords: - "AI solutions stack" - "database SSOT" - "AI assistants" - "copilot automation" - "autopilot workflows" - "GRC automation" - "compliance automation" - "trusted data" - "multi-agent AI" - "autonomous operations" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Solutions *Solutions* From trusted data to proactive automations. Layer your knowledge, assistants, copilots, and autopilots into one cohesive system. See how Sorena AI moves from a single source of truth to autonomous execution. [View solutions](#solution-layers) | [Talk to us](/contact.md) ## Concentric Solution Layers From outermost to innermost: 1. **Automations** - Autopilot 2. **Platform & Integrations** - Copilot 3. **AI Assistants** - Productivity 4. **Database** - Trusted Information ## Contents - [Database](#section-database) - [Assistants](#section-assistant) - [Copilot](#section-copilot) - [Autopilot](#section-autopilot) ## Data Zones ### Public Intelligence Vaults. *Public Zone* Sorena Libraries harvest regulations, standards, and rulings so only curated public facts roll into SSOT. [Learn more](/solutions.md) ### Sorena Standardizes Every Update. *Sorena Tenant* We ingest, cross-check, and normalize public changes inside the Sorena zone so assistants, APIs, and teams pull the same vetted format every time. [Learn more](/contact.md) ### Your Data Stays with You. *Customer Tenant* Your private datasets and assistants run entirely inside your tenant, so proprietary content, prompts, and outputs never leave your environment. [Learn more](/contact.md) ## Solution Layers ### AUTOPILOT - Proactive AI & Automations *Autonomous* | *Compliant* An AI engine that detects triggers, runs workflows, and performs actions across systems to maintain compliance and operations automatically. Autopilot watches for signals, triggers playbooks, and carries out actions across your stack with guardrails so changes stay compliant and auditable. ### COPILOT - Reactive AI based on user interactions. *Context-Aware* | *Real-Time* A real-time AI assistant that understands user context, tasks, and permissions to create compliant reports, automate actions, and speed up team workflows. Copilot helps teams in the flow of work. It answers, drafts, and routes tasks based on prompts and context so people move faster with fewer clicks. ### ASSISTANT - Passive multi-agent AI with trusted response. *Multi-Agent* | *Verified Answers* A central AI orchestrator coordinates thousands of workers, each focused on a specific task, to produce verified and sourced answers from trusted data. Assistants gather answers from trusted sources, agree on a response, and show citations so teams can rely on the result without re-checking everything. ### DATABASE - A single source of the truth (SSOT) for all public & private information. *Foundation Layer* | *Trusted Data* A live source that collects, cleans, and verifies public and private data so every system, AI, and workflow runs on the same trusted information, because without trusted data everything downstream fails. 1) Data pipelines pull trusted sources daily, categorize them, extract metadata, vectorize, and index everything so AI can search with high accuracy. 2) Live data access uses real browsers running in parallel to hit Google Search and target sites with guardrails, caching, and the option to drop results into your project drive or keep live browsing with advanced queries. ### Database Metrics *Metrics* - **Millions** | Documents Indexed | Laws, regulations, and standards. - **Source-Verified** | Data Accuracy | Checked against original sources - **Daily** | Update Frequency | Continuous monitoring and refresh - **Full** | Traceability | Every fact linked to its source ### Assistant Metrics *Metrics* - **Specialized** | AI Agents | Domain-specific AI workers - **Always Cited** | Source Attribution | Every answer backed by sources - **Serverless** | Hyper Scaling | Elastic agents auto-scale across workloads - **Consensus-Based** | Multi-Agent Accuracy | Verified by agent consensus ### Copilot Metrics *Metrics* - **Significant** | Effort Reduction | Less manual work for teams - **Context Aware** | Valid Suggestions | Each suggestion considers the employee's role and org controls - **Accelerated** | Report Generation | Automated document creation - **24/7** | Availability | Always-on assistance ### Autopilot Metrics *Metrics* - **Risk Sensors** | Always On | Guardrails scan for violations continuously - **Hands-Free** | Event Handling | Most events close without human touch - **Complete** | Audit Trail | Every action documented - **1 Click** | Human Approval | Review or override automations in one click ## Assistant Capabilities ### Parallel Processing *Multi-Agent* Thousands of specialized workers collaborate simultaneously to research, analyze, and validate information at scale. ### Trusted Responses *Verified* Every answer is grounded in SSOT data with full citations, ensuring accuracy and auditability for compliance teams. ### Context-Aware *Intelligent* Understands your organization's context, policies, and preferences to deliver tailored, actionable insights. ## Copilot Use Cases ### Real-Time Assistance *Interactive* Get instant help in the flow of work. Copilot understands your context and delivers immediate, actionable responses. ### Organization-Aware *Contextual* Leverages your templates, policies, and user profile to ensure every output aligns with organizational standards. ### Output-Focused *Productive* Generates reports, triggers actions, and creates documents automatically - reducing manual effort by up to 70%. ## Autopilot Capabilities ### Trigger-Based Automation *Proactive* Monitors regulatory updates, governance changes, and contract events to automatically initiate workflows. ### Multi-Agent Workflows *Orchestrated* Coordinates specialized AI agents, guardrails, copilots, and SSOT to execute complex compliance tasks. ### Complete Deliverables *Auditable* Generates evidence packages, audit trails, risk assessments, and compliance reports automatically. ## Assessment Autopilot *Source-Cited Answers* | *Policy-Validated* Orchestrate AI agents, human reviewers, and policy guardrails to deliver audit-ready RFPs and questionnaires in hours. [Learn more](/solutions/assessment.md) ## Solutions for Every Need *Explore by Capability* Dive deeper into specific capabilities designed to accelerate your compliance and research workflows. ## Available Solutions ### [Assessment Autopilot](/solutions/assessment.md) *High first-pass* Complete security questionnaires and compliance assessments with AI-powered automation. ### [Research Copilot](/solutions/research-copilot.md) *AI-Powered* Get cited answers from regulatory sources and internal documents in seconds. ### [SSOT](/solutions/ssot.md) *Unified Knowledge* Single Source of Truth for regulations, standards, CVE/CWE/CAPEC data, and project documents. ### [Integrations](/solutions/integrations.md) *Flexible Setup* Connect your AI model provider and data sources. Bring your own keys, use managed options, and keep outputs grounded. ## Every Solution Includes *Built-in* - **Project Workspaces**: Organize compliance initiatives with dedicated project spaces - **Team Collaboration**: Role-based access control with Owner, Admin, and Contributor roles - **Progress Tracking**: Monitor activity, track milestones, and measure outcomes - **Activity Logging**: Full audit trail for every action across your workspace ## Ready to Transform Your Workflows? *Get Started* See how our layered solutions transform your data into trusted insights, intelligent assistance, and autonomous operations ### Experience Our Complete Solutions Schedule a demo to see how Database, Assistants, Copilots, and Autopilots work together to deliver measurable results. | Duration | Type | | --- | --- | | 30 min | Quick Overview | | 1 hour | Full Solutions Demo | | Custom | Technical Deep Dive | [Schedule Your Demo](/contact.md) No commitment required - Available same day --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/solutions --- --- title: "Assessment Autopilot" canonical_url: "https://www.sorena.io/solutions/assessment" source_url: "https://www.sorena.io/solutions/assessment" author: "Sorena AI" description: "Turn any source document into a structured assessment. Import regulations, control frameworks, questionnaires, or audit templates." keywords: - "assessment automation" - "compliance automation" - "SOC 2" - "ISO 27001" - "GDPR" - "HIPAA" - "CAIQ" - "OWASP SAMM" - "control frameworks" - "regulatory compliance" - "vendor questionnaires" - "audit automation" - "GRC automation" - "policy guardrails" - "evidence management" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Assessment Autopilot *Assessment Autopilot* | *Citations* | *Policy-Validated* ## Turn Any Document Into a Structured Assessment Drop in regulations, control frameworks, questionnaires, or audit templates. Assessment Autopilot extracts requirements, generates evidence-backed answers, and validates against your policies. **Hours, not weeks.** [Start Your First Assessment](/contact.md) | [See the 6-Step Workflow](#workflow) **Platform Screenshots:** - ![Sorena Assessment Autopilot overview with AI-driven compliance scoring](https://cdn.sorena.io/images/assessment-6.png) - ![Assessment Autopilot dashboard showing active assessments and progress](https://cdn.sorena.io/images/assessment-1.png) - ![Assessment requirement extraction with AI-generated answers](https://cdn.sorena.io/images/assessment-2.png) - ![Assessment reviewer assignment and workflow management](https://cdn.sorena.io/images/assessment-3.png) - ![Assessment policy guardrails and compliance validation](https://cdn.sorena.io/images/assessment-4.png) - ![Assessment audit-ready package export with evidence trails](https://cdn.sorena.io/images/assessment-5.png) **Contents:** - [Preview](#preview) - [Pipeline](#pipeline) - [Workflow](#workflow) - [Playbooks](#playbooks) - [Enterprise](#enterprise) - [Proof](#proof) ### SOC 2 Type II Assessment Run #847 - Completed - Finished **Documents** (3 processed): SOC2_Template.xlsx, CAIQ_v4.pdf, ISO_AnnexA.csv **Pipeline Progress** (6 of 6 Complete): Import -> Extract -> Answer -> Assign -> Policy -> Ship **Reviewer Board** | Name | Role | Items | Status | | --- | --- | --- | --- | | Alice | Privacy | 18 items | On track | | Marcus | Security | 12 items | Needs input | | Julia | Legal | 6 items | On track | **262** Questions Imported | **262** Answers Complete | **High** Confidence | **Fast** Runtime **Policy Guardrails** - [x] Information Disclosure: Pass - [ ] Risk Policy: Auto-remediated - [x] Evidence Grounding: Pass **Run Summary** (All steps complete) - Assignments resolved via NL commands - Policy guardrails closed in 2 iterations - Delivery package generated with audit log *Platform Preview* ## See the Assessment Autopilot in Action From document import to audit-ready export, experience how teams complete assessments in hours instead of weeks. *End-to-End Pipeline* ## Visualize the Assessment Flow From source documents to audit-ready artifacts, see how AI orchestrates every step with full observability. *Use the controls to zoom, pan, download, or enter fullscreen mode.* *6-Step Pipeline* ## Every Requirement to Audit Proof One orchestrated pipeline from intake to audit handoff. Every phase stays visible, controllable, and traceable. 1. **Import Documents**: Paste a URL for AI to fetch the trusted source or drag files in. Pick SOC 2, NIST, ISO, GDPR libraries so every document stays in scope. *Universal Formats + Auto Fetch Sources* > Drop in any file or paste a URL and AI will pull the trusted source, map it to the control set you pick, track every revision, and re-process it the moment the document changes. Contracts, policies, and questionnaires all follow the same lane so nothing slips scope. Metric: **Universal** formats For: Compliance, Audit, GRC 2. **Extract Requirements**: AI reads contracts, policies, or any content to extract every control or question. Each item stays linked to the original line for audit trace. *Context Parsing + Full Extraction* > Legal agreements, contracts, cybersecurity playbooks, and policies all feed the same parser. AI understands the context and extracts every control while flagging duplicates so auditors can trace each item back to its source line. Metric: **Complete** extraction For: Security, Compliance, Legal 3. **Generate Answers**: Answers combine internal docs with approved public sources while questions auto-route to the right evidence stack. *Smart Sources + Answer Selection* > No manual uploads for public info. Low-confidence answers get flagged with reason codes, routed to the right owner, and tracked until they clear. Most drafts are approved on first pass. Metric: **High** first-pass For: Sales Ops, Security, Vendor Risk 4. **Assign to Reviewers**: Type commands like assign privacy to Alice and directory lookups resolve owners without leaving chat. Bulk actions plus alerts keep reviewers aligned. *Command Assignments + Instant Routing* > Bulk actions like "unassign all answered items" work too. Reviewers get notified immediately with links back to the exact question and the evidence they need to confirm it. Metric: **Instant** routing For: Team Leads, Project Mgmt, GRC 5. **Apply Policy Guardrails**: Define policy rules for legal, privacy, and risk controls. Violations auto-fix or escalate with context. Custom rules slot in to keep every control under review. *Policy Guardrails + Custom Rules* > NDAs, data handling, and regulatory rules stay covered by your custom policies. Upload rules so niche controls run alongside your library. Most violations resolve in under three passes with full audit logs. Metric: **Policy-Aligned** outputs For: Legal, Privacy, Risk 6. **Ship Auditable Package**: Generate audit-ready packages with full evidence trails. Every response includes citations, sign-offs, and timestamps for complete traceability. *Evidence Bundle + Audit Trail* > Full evidence trails, sign-offs, timestamps, and attribution included. No manual formatting required and teams ship in hours, not weeks. Metric: **Auditable** packages For: Compliance, Auditors, Execs *Pick a Template, Ship Today* ## Finish in Minutes, Not Days Templates are playbooks, not checklists. Choose the scenario and the platform delivers the assessment, evidence matrix, and audit log in one shot. [See All Templates](/contact.md) ### Security Questionnaire Response Complete CAIQ, SIG, VSAQ, or custom questionnaires in hours. AI drafts answers with citations; you review and ship. When to use: Vendor diligence requests, customer security reviews, or partner assessments. Outputs: Completed questionnaire, Confidence scores, Gap report Buyers: Sales Engineering, Security, Vendor Risk ### Control Framework Assessment Import SOC 2, ISO 27001, NIST CSF, or CIS controls. AI generates evidence-backed narratives linked to your policies. When to use: Audit prep, certification readiness, or control gap analysis. Outputs: Control narratives, Evidence matrix, Review-ready package Buyers: Security, Compliance, GRC ### Regulatory Compliance Mapping Import GDPR, HIPAA, PCI DSS, SOX, or any regulation. AI maps obligations to your controls and finds gaps. When to use: New regulation drops, cross-border expansion, or compliance certification. Outputs: Obligation mapping, Gap analysis, Remediation plan Buyers: Compliance, Privacy, Legal ### Policy Governance Review Re-scan existing assessments against updated policies. Auto-fix violations or escalate to reviewers. When to use: Quarterly reviews, post-incident checks, M&A diligence, or policy updates. Outputs: Violation report, Updated responses, Attestation log Buyers: Legal, Compliance, Risk *Every Run Delivers* ## Three Auditable Artifacts Documentation, traceable evidence, and immutable records ship together for any auditor. - **Completed Assessment**: Shareable assessment package with citations, evidence, reviewer sign-offs, and audit trail. - All requirements addressed - Source file citations - Reviewer sign-offs - **Evidence Matrix**: Which files support which responses. Auditors ask "show me the evidence" and you have it. - Requirement-to-evidence map - Confidence scores - Gaps flagged for review - **Audit Log**: Immutable record of who did what, when, and which policies applied. SOC 2 and ISO aligned. - Timestamped actions - Policy evaluation results - Approval workflow *Automated Compliance* ## Enterprise-Grade Security & Compliance Security controls that enforce themselves. Access, audit, and policy guardrails apply automatically inside every workflow - no manual checks required. ### Inherit Security by Default Every assessment run inherits enterprise controls automatically. Your team works faster while compliance happens in the background. **Full** Audit Trail | **Zero** Manual Gates *Applies automatically in every workflow* - **Role-Based Access**: Workspace and project permissions control who can view, edit, or approve. Every action is logged with user identity. Objection handled: "Who can access our data?" - **No Duplicate Runs**: System locks each assessment in progress. If something fails, recovery resumes exactly where it stopped. Objection handled: "What if two people start the same run?" - **Immutable Audit Trail**: Every action logged with timestamps and user identity. Auditors get full traceability in one export. Objection handled: "How do we prove compliance?" - **Policy Guardrails**: Every AI answer is scanned against your policies before shipping. Violations are fixed or escalated. Objection handled: "How do we prevent leaks?" *Results* ## The Numbers Real results from teams running Assessment Autopilot. **Citations** Answers | **High** First-Pass Approval | **Automated** Policy Checks | **Auditable** Outputs - **Answers**: Every response traced to its origin document - **First-Pass Approval**: Most AI responses accepted without edits - **Policy Checks**: AI-driven loops to resolve violations automatically - **Outputs**: Full evidence trails and citations included > "We help organizations see exactly where they stand by pulling statutes, frameworks, and internal policies into one automated run that produces evidence, citations, and gap analysis." -- Sorena Team, Product + Compliance Group [Accelerate Your Assessments](/contact.md) *Get Started* ## Finish Your Next Assessment Today See it work with your own data. Book a live demo and run your first assessment free. [Run Your First Assessment Free](/contact.md) | [See Other Solutions](/solutions.md) *No credit card required - See results in your first 30-minute session* --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/solutions/assessment --- --- title: "AI Research Copilot" canonical_url: "https://www.sorena.io/solutions/research-copilot" source_url: "https://www.sorena.io/solutions/research-copilot" author: "Sorena AI" description: "Accelerate regulatory research with AI-powered search and analysis. Every answer is source-linked and cited from trusted regulatory documents." --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # AI Research Copilot *AI Research Copilot* ## Research Faster with AI-Powered Citations Ask questions in plain English. Get verified answers with direct citations to regulatory sources, internal policies, and legal documents. Every fact traced to its origin. *Faster Tasks* | *Writing Speed* [Try Research Copilot](/contact.md) **Platform Screenshots:** - ![Research Copilot main chat interface with AI-powered regulatory research](https://cdn.sorena.io/images/copilot-researcher-1.png) - ![Research Copilot showing cited answers from trusted sources](https://cdn.sorena.io/images/copilot-researcher-2.png) - ![Research Copilot document analysis with inline citations](https://cdn.sorena.io/images/copilot-researcher-3.png) - ![Research Copilot multi-source search results aggregation](https://cdn.sorena.io/images/copilot-researcher-4.png) - ![Research Copilot conversation history and session management](https://cdn.sorena.io/images/copilot-researcher-5.png) **Contents:** - [How It Works](#how-it-works) - [Capabilities](#capabilities) - [Results](#results) - [Benchmark](#benchmark) - [Industries](#industries) - [FAQ](#faq) *How It Works* ## From Question to Cited Answer in Seconds The Research Copilot combines multi-agent AI with your trusted data sources to deliver verified answers fast. ## From Question to Cited Answer in Seconds 1. **Ask a Question**: Type your research question in natural language. The copilot understands regulatory, legal, and compliance context. 2. **AI Searches Sources**: Multi-agent AI searches your knowledge base, regulatory libraries, and public sources simultaneously. 3. **Verify & Cite**: Every fact is verified against trusted sources. Citations link directly to the original document and paragraph. 4. **Generate Response**: Receive a comprehensive answer with inline citations, confidence scores, and related follow-up suggestions. *Key Capabilities* ## Built for Compliance Research ### Regulatory Research Search across regulations, standards, and guidance documents with natural language queries. Get answers with direct citations to source text. ### Policy Analysis Analyze internal policies against regulatory requirements. Identify gaps and generate compliance recommendations. ### Contract Review Extract key terms, obligations, and risks from contracts. Identify important clauses and summarize key provisions. ### Audit Preparation Generate evidence packages, control narratives, and audit responses with full traceability to source documents. *Proven Results* ## Research Productivity, Transformed *Benchmark Report* ## See the Performance Data Internal two-auditor evaluation (January 2026) shows measurable advantages in regulatory research tasks **100%** Requirement Coverage | **74%** Coverage Advantage | **0** Factual Errors Our Research Copilot was tested against a leading general-purpose AI across 43 compliance and regulatory tasks. The coverage advantage is the difference between Sorena (100%) and the baseline average coverage (26%) in the two-auditor evaluation. [View Full Benchmark Report](/solutions/benchmarks.md) *Industry Applications* ## Built for Your Industry ## Related Solutions - [ESG Compliance](/solutions/esg-compliance.md) - [Assessment Autopilot](/solutions/assessment.md) - [SSOT](/solutions/ssot.md) - [All Solutions](/solutions.md) ## Common Questions **How does the AI ensure accuracy?** Every response is grounded in your trusted data sources. The copilot retrieves relevant documents from the library and web search before generating answers. All answers include citations linking to the exact source. **What data sources are available?** The copilot searches your document library (Swedish laws, NIST, ETSI, EU regulations, and more), performs web searches across trusted public sources to fetch the latest information, and retrieves documents from your project files. When needed, multiple browser workers run in parallel so research stays fast. All sources are searched simultaneously. **Is my data secure?** Your data stays in your workspace. The AI processes queries within your security boundary with role-based access control. Each workspace is isolated with full activity logging. **Can I save and organize my research?** Yes. Create chat sessions to organize research by topic or project. Access your complete conversation history and revisit past research at any time. Configure RAG and function settings per session. ## Ready to Research Smarter? See how the Research Copilot can accelerate your compliance research with a personalized demo. [Schedule a Demo](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/solutions/research-copilot --- --- title: "SSOT" canonical_url: "https://www.sorena.io/solutions/ssot" source_url: "https://www.sorena.io/solutions/ssot" author: "Sorena AI" description: "Your Single Source of Truth for compliance: regulations, standards, CVE/CWE/CAPEC security data, and internal documents." --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # SSOT *SSOT* ## Your Single Source of Compliance Truth Access curated regulatory content, security vulnerability data (CVE, CWE, CAPEC), and your own project documents, all in one searchable library. *Search Reduction* | *CVE/CWE/CAPEC* [Explore SSOT](/contact.md) **Platform Screenshots:** - ![SSOT document library overview showing categorized regulatory content](https://cdn.sorena.io/images/ssot-1.png) - ![SSOT search interface with filtering by category and source](https://cdn.sorena.io/images/ssot-2.png) - ![SSOT document preview drawer with metadata and quick actions](https://cdn.sorena.io/images/ssot-3.png) - ![SSOT security vulnerability data browser showing CVE entries](https://cdn.sorena.io/images/ssot-4.png) - ![SSOT project document upload and management interface](https://cdn.sorena.io/images/ssot-5.png) - ![SSOT compliance framework mapping and cross-reference view](https://cdn.sorena.io/images/ssot-6.png) **Contents:** - [How It Works](#how-it-works) - [Capabilities](#capabilities) - [Document Types](#document-types) - [Results](#results) - [Industries](#industries) - [FAQ](#faq) *How It Works* ## From Scattered to Searchable SSOT puts authoritative regulatory content and security data at your fingertips. ## From Scattered to Searchable 1. **Browse Library**: Explore curated regulatory content organized by category: Swedish laws, NIST frameworks, ETSI standards, and EU regulations. 2. **Search & Filter**: Use powerful filters to narrow down by category, source, or security classification. Search with debounced queries for fast results. 3. **Preview Documents**: View document details in the side drawer without leaving the search view. See metadata, summaries, and quick actions. 4. **Upload to Projects**: Add your own documents to project workspaces. Uploaded files become searchable by the Research Copilot. *Key Capabilities* ## Built for Compliance Document Management ### Curated Primary Sources Access a comprehensive library of regulatory content including Swedish laws, NIST frameworks, ETSI standards, and European Union regulations. ### Security Vulnerability Data Includes CVE, CWE, and CAPEC datasets for vulnerability research. Filter by severity, category, or attack pattern to inform your security assessments. ### Category Navigation Browse documents through an intuitive category tree. Filter by source, security classification, or document type to find what you need. ### Project Integration Upload your own documents to project workspaces. Project files are indexed and searchable by the Research Copilot for contextual answers. *Proven Results* ## The Cost of Scattered Information *Industry Applications* ## Built for Your Industry *Document Types* ## Organize Everything in One Place - **Policies & Procedures** - Information Security Policy - Incident Response Plan - Access Control Procedures - **Regulatory Guidance** - GDPR Guidelines - SOX Requirements - Industry Circulars - **Standards & Frameworks** - ISO 27001 - NIST CSF - SOC 2 Criteria - **Security Datasets** - CVE Vulnerabilities - CWE Weaknesses - CAPEC Attack Patterns ## Related Solutions - [Research Copilot](/solutions/research-copilot.md) - [Assessment Autopilot](/solutions/assessment.md) - [All Solutions](/solutions.md) ## Common Questions **What content is in the library?** SSOT includes curated regulatory content (Swedish laws, NIST frameworks, ETSI standards, EU regulations), security vulnerability datasets (CVE, CWE, CAPEC), and your own project documents. **What security data is included?** SSOT includes CVE (Common Vulnerabilities and Exposures), CWE (Common Weakness Enumeration), and CAPEC (Common Attack Pattern Enumeration and Classification) datasets for vulnerability research and threat modeling. **How does search work?** Use the search bar with debounced queries for fast results. Filter by categories, sources, severity levels, or security classification using filter chips. Toggle between grid and list views. **Can I add my own documents?** Yes. Upload documents to your project workspaces through the Storage Browser. Uploaded files are indexed and become searchable by the Research Copilot for project-specific context. ## Ready for a Single Source of Truth? See how SSOT can centralize your regulatory content, security data, and project documents. [Schedule a Demo](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/solutions/ssot --- --- title: "Integrations" canonical_url: "https://www.sorena.io/solutions/integrations" source_url: "https://www.sorena.io/solutions/integrations" author: "Sorena AI" description: "Connect Sorena to your AI model provider and the tools where your compliance knowledge lives." --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Integrations *Integrations* ## Connect your stack to Sorena Choose the AI models you trust and connect the data sources your teams already use. Sorena keeps workflows flexible, secure, and grounded in the sources that matter. *Bring Your Own AI* | *Managed Options* [Talk to Us](/contact.md) | [Explore All Solutions](/solutions.md) **Platform Screenshots:** - ![Sorena platform overview showing a unified workspace and connected sources](https://cdn.sorena.io/images/platform-1.png) - ![Sorena SSOT document preview showing grounded sources and quick actions](https://cdn.sorena.io/images/ssot-3.png) - ![Sorena Research Copilot chat interface showing cited research results](https://cdn.sorena.io/images/copilot-researcher-1.png) - ![Sorena Assessment Autopilot dashboard showing progress and reviewer workflow](https://cdn.sorena.io/images/assessment-1.png) - ![Sorena platform workspace view showing projects and research workflows](https://cdn.sorena.io/images/platform-5.png) **Contents:** - [Integration Layer](#providers) - [AI Providers](#ai-providers) - [Data Sources](#sources) - [Workflows](#workflows) - [Use Cases](#use-cases) - [Ingestion](#ingestion) - [Governance](#governance) *Platform Preview* ## See how integrations power every workflow Connected sources feed SSOT, copilots, and autopilots across teams. - **Citations by default**: Keep answers traceable to the exact sources used. - **Central routing**: Choose models and sources by workspace and policy. - **Shared foundation**: Turn scattered knowledge into a governed SSOT. *Integration Layer* ## One integration layer for AI and data Bring your own keys, or use Sorena managed connectivity. Hover or focus a logo to see the provider name. ### AI model providers Anthropic, AWS Bedrock, Azure OpenAI, Cloudflare Workers AI & Browser Rendering, GCP Vertex AI, Google AI Studio Gemini, Ollama (Self Hosted Models), OpenAI, xAI Grok ### Data sources Any website or sitemap.xml, Atlassian Confluence, GitHub Repository & Wiki, Google Team Drive, Live Google search from trusted sources and live browsing, Microsoft SharePoint & Team Drive, Sorena Drive *AI Providers* ## Use the AI models you trust Bring your own keys, use managed options, or mix providers across teams and workspaces. - **Bring Your Own AI**: Use your existing provider accounts and control spend, regions, and data handling settings. - **Managed Options**: Use Sorena managed connectivity for faster rollout, consistent governance, and simplified administration. - **Built for cross-functional work**: Security, legal, compliance, engineering, and operations can share one governance layer. ### How Sorena uses your provider choice - **Governed routing**: Keep provider selection aligned to workspace needs. - **Grounded context**: Use connected documents as the foundation for answers. - **Built for collaboration**: Teams work from shared sources and outcomes. *Data Integrations* ## Ground AI in the tools where work happens Connect documents, tickets, policies, and source material to keep answers traceable. Sorena connects to your existing repositories so teams can search, cite, and reuse knowledge without copy-pasting between tools. - **Workspace-aware access**: Respect roles and boundaries so each team only sees what they are allowed to use. - **Citations by default**: Keep answers grounded with links back to the exact source and context. - **Sorena Drive**: Store and organize internal documents per project, organization, or workspace. **Supported sources**: Microsoft SharePoint & Team Drive, Google Team Drive, GitHub Repository & Wiki, Atlassian Confluence, Any website or sitemap.xml, Live Google search from trusted sources and live browsing, Sorena Drive *Powered By Integrations* ## Integrations that power every workflow The same connection layer feeds SSOT, copilots, and autopilots so teams can move faster with shared context. - **Step 1: Connect sources** - Bring in documents, tickets, policies, and evidence from the tools your teams already trust. - **Step 2: Build SSOT** - Normalize knowledge into a governed library so every workflow starts from the same source of truth. - **Step 3: Run workflows** - Power copilots and automations with grounded context, citations, and policy-aligned outputs. - [SSOT](/solutions/ssot.md): Unify regulatory libraries and internal sources into one searchable, governed foundation for the entire platform. - [Research Copilot](/solutions/research-copilot.md): Ask in plain language and get source-linked answers grounded in connected documents and approved public sources. - [Assessment Autopilot](/solutions/assessment.md): Turn documents into structured assessments with evidence-backed answers and policy-aligned validation. - [Automations](/solutions.md): Use connected sources and governed AI to trigger workflows, generate artifacts, and keep operations audit-friendly. - **Ingest and normalize**: Bring in documents and knowledge, then organize them into a structure teams can trust. - **Ground and cite**: Keep outputs traceable with source links back to the material that teams approve. - **Apply guardrails**: Route by workspace and policy so the right model and sources are used for each workflow. *Use Cases* ## What teams build with integrations Connect the tools you already use, then run repeatable workflows with grounded context and shared governance. - **Vendor questionnaires**: Draft evidence-backed responses from internal policies and approved sources, then route items to the right reviewers. - **Policy to requirement mapping**: Map obligations to controls and evidence with citations so stakeholders can review quickly and confidently. - **Audit evidence packages**: Keep source material connected, then generate artifacts and exports with audit-friendly traceability. - **Cross-team research**: Search across tools and libraries with one question, then keep decisions linked to sources and outcomes. *Ingestion* ## Bring documents and data in any format Sorena ingests common files, normalizes them into searchable knowledge, and keeps source context available for review. 1. Upload files or sync from connected repositories 2. Content is extracted and enriched with metadata 3. Documents become searchable and citable across workflows - **Documents**: Policies, reports, spreadsheets, and evidence packs. (.pdf, .docx, .odt, .pptx, .epub, .txt, .log, .xlsx, .csv, .tsv) - **Code and config**: Source code, scripts, configs, and structured data formats. (.py, .js, .ts/.tsx, .java, .go, .rs, .sql, .sh, .toml, .ini, .env, .json, .jsonl, .xml, .yaml, .yml, .proto, .graphql) - **Web and markdown**: Knowledge pages and internal documentation. (.html, .htm, .md, .markdown, .mdx) - **Images**: Screenshots and visual evidence from teams and tools. (.png, .jpg, .jpeg, .gif, .webp, .svg, .tiff, .tif) - **Source context preserved**: Original files, metadata, and excerpts stay linked to downstream answers. - **Ready for search and reuse**: Content becomes searchable across SSOT, Research Copilot, and Assessment Autopilot. ### Multilingual support Ingest and search content in the languages supported by modern LLMs English, Spanish, German, French, Italian, Polish, Dutch, Swedish, Portuguese, Norwegian, Danish, Finnish, Czech, Hungarian, Romanian, Hebrew, Chinese (Mandarin), Japanese, Korean, Hindi, Vietnamese, Thai, Malay, Indonesian, Arabic, Turkish, and more *Governance* ## Integration controls built for real organizations Keep keys, access, and sources aligned to policy without slowing teams down. - **Central routing**: Choose which models and sources are allowed for each workspace, project, or workflow. - **Source-grounded outputs**: Build answers from approved sources and keep citations attached so reviews stay fast and consistent. - **Audit-friendly history**: Keep a clear record of sources, actions, and outcomes so teams can explain what happened and why. ## Related Solutions - [SSOT](/solutions/ssot.md) - [Research Copilot](/solutions/research-copilot.md) - [Assessment Autopilot](/solutions/assessment.md) - [All Solutions](/solutions.md) ## Ready to connect Sorena to your stack? We will help you choose the right providers, connect your sources, and set governance controls that fit how your teams work. [Schedule a Demo](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/solutions/integrations --- --- title: "ESG Compliance Software" canonical_url: "https://www.sorena.io/solutions/esg-compliance" source_url: "https://www.sorena.io/solutions/esg-compliance" author: "Sorena AI" description: "Navigate EU ESG and sustainability regulations with AI-powered research." --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESG Compliance Software *ESG Compliance* | *Research + Assess + Act* ## ESG Compliance From Research to Action Research Copilot answers your regulatory questions with cited evidence. Assessment Autopilot identifies gaps and generates prioritized action plans. Built for CSRD, DPP, PPWR, CSDDD, and more. [Book a Demo](/contact.md) | [Run an Assessment](/solutions/assessment.md) | [Explore Research Copilot →](/solutions/research-copilot.md) ![ESG Compliance - Environmental, Social, and Governance](https://cdn.sorena.io/images/eco.jpg) Focus areas: Environmental, Governance, Compliance, Social - Research regulations with cited AI answers - Assess gaps and generate prioritized action plans - Track evidence across EU and national requirements *Evidence-first* | *Audit-ready outputs* | *EU + country coverage* ### Key Compliance Milestones - **DPP Registry** (2026+): EU product passport infrastructure - **PPWR Targets** (2026+): Packaging recyclability requirements - **Battery Passport** (2027+): EV and industrial batteries - **CSDDD Phase-in** (2027+): Due diligence obligations begin **Contents:** - [Challenge](#challenge) - [Coverage](#coverage) - [How We Help](#how-we-help) - [Why Sorena](#why-sorena) - [Use Cases](#use-cases) - [Outputs](#product) - [How It Works](#how-it-works) - [Benchmark](#benchmark) - [FAQ](#faq) *The Challenge* ## ESG Compliance Is Complex EU frameworks and national requirements are interconnected, evolving, and jurisdiction-specific - **Regulatory Fragmentation**: Multiple frameworks with overlapping scopes and different timelines. Example: CSRD vs CSDDD vs ESPR scope definitions - **Manual Research Burden**: Hours spent finding applicable articles, delegated acts, and guidance. Example: DPP data carrier specs in delegated acts and annexes - **Evolving Requirements**: New standards and delegated acts published continuously. Example: ESRS sector standards and implementing measures - **Multi-Jurisdictional Complexity**: National transpositions and local requirements vary by country. Example: EPR registration: Sweden vs Germany vs France *Coverage* ## Comprehensive Regulatory Library Research requirements across EU sustainability frameworks and implementation standards Research and scope requirements across EU frameworks and national regulations. Every answer links to official sources you can verify. ### Featured Frameworks and Regulations #### CSRD + ESRS - Corporate Sustainability Reporting Corporate sustainability reporting with ESRS standards; first wave applied for FY2024. Official sources: [Commission CSRD](https://finance.ec.europa.eu/capital-markets-union-and-financial-markets/company-reporting-and-auditing/company-reporting/corporate-sustainability-reporting_en?ref=sorena.io), [EFRAG ESRS](https://www.efrag.org/en/sustainability-reporting?ref=sorena.io) How Sorena helps: - Double materiality assessment - ESRS gap map and disclosure controls - Audit-readiness and tagging plan #### EU Taxonomy - Sustainable Activities Classification Classification system for sustainable activities; defines eligibility and alignment criteria. Official sources: [EUR-Lex 2020/852](https://eur-lex.europa.eu/eli/reg/2020/852/oj), [Commission hub](https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/european-green-deal/finance-and-green-deal_en?ref=sorena.io) How Sorena helps: - Eligibility/alignment tests - KPI computation (turnover/CapEx/OpEx) #### ESPR / DPP - Ecodesign & Digital Product Passport Framework expanding ecodesign to most products; introduces Digital Product Passport and restrictions on unsold goods destruction. Official sources: [EUR-Lex 2024/1781](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1781&ref=sorena.io), [Commission page](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en?ref=sorena.io) How Sorena helps: - DPP data model and product requirements tracker - Supplier clauses and roadmap #### EUDR - Deforestation Regulation Due diligence for listed commodities/products with geolocation evidence and operator/trader statements. Official sources: [Commission overview](https://environment.ec.europa.eu/topics/forests/deforestation/regulation-deforestation-free-products_en?ref=sorena.io) How Sorena helps: - Scope scan and geolocation schema - Risk assessment and mitigation playbook - Due diligence statement filing workflow #### PPWR - Packaging & Packaging Waste Harmonised recyclability, recycled-content targets, labelling, DRS, reuse, and prevention targets; staged from 2025. Official sources: [EUR-Lex 2025/40](https://eur-lex.europa.eu/eli/reg/2025/40/oj?ref=sorena.io) How Sorena helps: - Packaging bill-of-materials data model - Recyclability assessments and label specs - Supplier attestations and timeline plan ### Additional EU Frameworks - **CSDDD - Corporate Sustainability Due Diligence Directive** (2027+): Human rights and environmental due diligence across value chains - **Battery Reg - EU Batteries Regulation** (2027+): Battery passport, recycled content, and collection targets - **Green Claims - Green Claims Directive** (2026+): Substantiation requirements for environmental marketing claims - **EED - Energy Efficiency Directive** (Ongoing): Energy audits, management systems, and efficiency targets ### Implementation Standards **Management Systems** - ISO 14001: Environmental management - ISO 50001: Energy management **Footprinting & LCA** - ISO 14040/44: Life cycle assessment - ISO 14067: Carbon footprint of products **GHG Accounting** - ISO 14064: GHG quantification and verification - GHG Protocol: Corporate emissions accounting **Water & Circularity** - ISO 46001: Water efficiency management - ISO 59020: Circular economy measuring ### Country-Specific Requirements #### Europe ##### Sweden **Environmental Code** (SFS 1998:808) Framework law governing permits, environmental assessments, emissions, supervision, and sanctions. Official sources: [SFS 1998:808](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/miljobalk-1998808_sfs-1998-808/?ref=sorena.io) - Scope assessment and permit-readiness checklist - Register of legal obligations - Policy templates and monitoring calendar **Packaging EPR** (Naturvårdsverket) Producers must register with the Swedish EPA, affiliate to an approved PRO, and report packaging volumes by material/type. Official sources: [Swedish EPA guidance](https://www.naturvardsverket.se/en/guidance/extended-producer-responsibility-epr/producer-responsibility-for-packaging/?ref=sorena.io) - Producer applicability test - Registration pack and data model for reporting - Controls and evidence checklist **Waste Ordinance** (SFS 2020:614) Classification (EWC codes), separate collection, permits/notifications for transport, and hazardous waste recordkeeping. Official sources: [SFS 2020:614](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/avfallsforordning-2020614_sfs-2020-614/?ref=sorena.io) - Waste classification procedures (EWC codes) - Hazardous-waste register workflow - Transporter due-diligence pack - Inspection-ready evidence set **Large Company Energy Audits** (SFS 2014:266 / EED Art. 8) Non-SME companies must conduct energy audits at least every 4 years; Energimyndigheten provides oversight. Official sources: [SFS 2014:266](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/lag-2014266-om-energikartlaggning-i-stora_sfs-2014-266/?ref=sorena.io), [Energimyndigheten](https://www.energimyndigheten.se/effektiv-energianvandning/foretag/energikartlaggning/energikartlaggning-i-stora-foretag/?ref=sorena.io) - Scope test (SME vs non-SME) - Auditor selection brief - Report template aligned to DIN EN 16247-1 - 4-year cycle tracker ##### United Kingdom **Packaging EPR (UK)** (GOV.UK) Registration, data collection, recycling activity model (RAM), base fees, and local-authority payment methodology. Official sources: [GOV.UK EPR Collection](https://www.gov.uk/government/collections/extended-producer-responsibility-for-packaging?ref=sorena.io) - Actor mapping and role determination - Data schema and CSV preparation - Evidence controls and audit trail - RAM and fee planning ##### France **AGEC Law** (Anti-Waste, Circular Economy) Broad measures including EPR expansion, waste prevention, and repairability requirements. Official sources: [Legifrance AGEC](https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000041553759/?ref=sorena.io) - Scope-by-scope EPR mapping - EPR compliance plan - Product labeling roadmap **Info-Tri Labeling** (Decree 2021-835) Consumer sorting label rules and implementation details. Official sources: [Legifrance Decree](https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000043714227?ref=sorena.io) - Label specifications and artwork checks - Stock run-down plan - Litigation watch ##### Netherlands **Packaging Decree** (Besluit beheer verpakkingen 2014) Packaging rules including heavy-metal limits, recycling/reuse targets, and deposit obligations. Official sources: [wetten.overheid.nl](https://wetten.overheid.nl/BWBR0035711/?ref=sorena.io) - Product and packaging scope mapping - Recycling target tracker - Deposit compliance playbook **Single-Use Plastics Rules** (SUP Implementation) National SUP restrictions and mandatory EU harmonised markings for specified products. Official sources: [Rijksoverheid SUP Rules](https://www.rijksoverheid.nl/onderwerpen/afval/regels-voor-wegwerpplastic?ref=sorena.io) - Product scope test - Marking artwork specifications - Procurement guidance #### Asia-Pacific ##### Japan **Plastic Resource Circulation Act** (Act No. 60 of 2021) Lifecycle approach (design to recycling) for plastics; 3R+Renewable; specified items reduction obligations. Official sources: [MOE Act (EN)](https://www.env.go.jp/en/focus/jeq/issue/vol29/The%20Plastic%20Resource%20Circulation%20Act_0128%20final.pdf?ref=sorena.io) - Applicability scope test - Design guideline mapping - Retailer/service provider reduction plan **Containers & Packaging Recycling Law** (Municipal Collection) Municipal sorted collection and producer-funded recycling responsibilities. Official sources: [MOE Law Outline](https://www.env.go.jp/content/900452887.pdf?ref=sorena.io) - Responsibility map - Recycling service contracts - Data and fee planning ##### Australia **NGER Scheme** (CER) Company emissions and energy reporting via CER; 31 Oct deadline. Official sources: [CER NGER Overview](https://cer.gov.au/schemes/national-greenhouse-and-energy-reporting-scheme?ref=sorena.io) - Threshold test - CER reporting submission prep - Data quality assurance - Governance and sign-off flow **Product Stewardship Act 2011** (Mandatory/Co-regulatory Schemes) Framework for mandatory, co-regulatory, and voluntary schemes (e.g., NTCRS). Official sources: [Legislation Register](https://www.legislation.gov.au/Details/C2011A00076?ref=sorena.io) - Scheme applicability check - Producer obligations - Evidence and reporting pack ##### Singapore **Resource Sustainability Act** (RSA) EPR for e-waste, mandatory packaging reporting, food-waste segregation. Official sources: [Singapore Statutes Online](https://sso.agc.gov.sg/Acts-Supp/29-2019?ref=sorena.io) - Producer role determination - Scheme registration plan - Reduce-Reuse-Recycle plan - Compliance records and timelines **Mandatory Packaging Reporting** (MPR) Annual packaging data and 3R plans for companies meeting thresholds. Official sources: [NEA MPR](https://www.nea.gov.sg/our-services/waste-management/mandatory-packaging-reporting?ref=sorena.io) - Packaging data model - NEA reporting portal submission workflow - Reduction target setting **Beverage Container Return Scheme** (DRS - Apr 2026) 10-cent deposit on plastic/metal beverage containers; go-live 1 Apr 2026. Official sources: [NEA BCRS](https://www.nea.gov.sg/our-services/waste-management/beverage-container-return-scheme?ref=sorena.io) - Product registration - Labeling requirements and artwork checks - Deposit collection processes - Returns network readiness ##### India **Plastic Waste Management Rules** (EPR Guidelines 2016+) EPR for plastic packaging, SUP measures, registrations, and targets. Official sources: [CPCB EPR Portal](https://eprplastic.cpcb.gov.in/?ref=sorena.io), [PIB Release](https://www.pib.gov.in/newsite/printrelease.aspx?relid=138144&ref=sorena.io) - CPCB portal registration and access setup - Target planning - Audit trail for certificates **E-Waste Management Rules 2022** (In force Apr 2023) EPR for e-waste with producer/recycler roles and portal-based compliance. Official sources: [CPCB Rules PDF](https://cpcb.nic.in/uploads/Projects/E-Waste/e-waste_rules_2022.pdf?ref=sorena.io), [PIB Note](https://www.pib.gov.in/PressReleseDetailm.aspx?PRID=1986201&ref=sorena.io) - Role mapping (producers/recyclers) - Portal filings and submissions workflow - Take-back plan - Recycler and compliance contracts **Battery Waste Management Rules 2022** (MoEFCC) EPR for all battery types, collection/recycling, portal-based certificates. Official sources: [MoEFCC Gazette PDF](https://moef.gov.in/uploads/pdf-uploads/pdf_67656abd8b77a7.43753969.pdf?ref=sorena.io) - Producer registration workflow - EPR compliance plan - Recycler service contracts - Reporting controls #### Americas ##### Brazil **PNRS** (Lei 12.305/2010) National Solid Waste Policy: principles, instruments, reverse logistics for specified chains, integrated waste management planning. Official sources: [Lei 12.305/2010](https://www.planalto.gov.br/ccivil_03/_ato2007-2010/2010/lei/l12305.htm?ref=sorena.io) - Reverse logistics plan - Sector agreements - State/municipal coordination - Evidence and reporting *Platform Capabilities* ## What Sorena Delivers Structured outputs for every compliance workflow — from scoping to remediation ### Reporting & Disclosure Sustainability reporting frameworks and disclosure requirements - **Double Materiality Assessment**: Identify material sustainability topics with stakeholder input and impact analysis. Outputs: Materiality matrix, Stakeholder map, Topic prioritization - **ESRS Gap Analysis**: Map disclosure requirements against current practices and identify gaps. Outputs: Gap assessment, Disclosure checklist, Action plan - **Audit-Readiness & Tagging**: Prepare for limited assurance with structured data and XBRL tagging guidance. Outputs: Data controls, Tagging plan, Evidence package - **SECR & GHG Reporting**: Boundary selection, conversion factors, and disclosure drafting for energy and carbon. Outputs: Methodology guide, Disclosure template, Verification pack ### EPR & Packaging Extended Producer Responsibility and packaging compliance - **Producer Applicability Test**: Determine producer obligations and registration requirements by jurisdiction. Outputs: Role determination, Threshold check, Obligation register - **Registration & Affiliation**: Prepare registration dossiers for national EPR schemes and PRO affiliations. Outputs: Registration pack, PRO selection, Timeline plan - **Data Model & Reporting**: Structure packaging data for annual reporting to EPR schemes. Outputs: Data schema, CSV templates, Reporting calendar - **Recyclability Assessment**: Evaluate packaging against PPWR recyclability grades and design guidelines. Outputs: Grade assessment, Design guidance, Improvement roadmap - **Label Specifications**: Artwork requirements for sorting labels, SUP markings, and deposit schemes. Outputs: Label specs, Artwork checks, Stock run-down plan ### Product & DPP Digital Product Passport and product compliance - **DPP Data Architecture**: Design data models for product passport information and carrier options. Outputs: Data model, Carrier specs, Registry roadmap - **Product Requirements Tracker**: Track delegated acts and product-specific ecodesign requirements. Outputs: Requirements register, Timeline tracker, Update alerts - **Supplier Clauses & Contracts**: Prepare supplier agreements for data collection and compliance obligations. Outputs: Contract templates, Data requests, Attestation forms ### Waste & Circularity Waste classification, handling, and circular economy - **Waste Coding SOPs**: Standard procedures for EWC classification and separate collection. Outputs: Coding guide, Decision tree, Training materials - **Hazardous Waste Register**: Recordkeeping workflows for hazardous waste tracking and reporting. Outputs: Register workflow, Transport controls, Annual reports - **Transporter Due Diligence**: Verification of waste carriers and receivers for compliance. Outputs: Due diligence pack, License checks, Contract templates - **Reverse Logistics Planning**: Design take-back schemes for product stewardship and PNRS compliance. Outputs: Logistics plan, Collection points, Partner agreements ### Energy & Audits Energy efficiency, audits, and environmental permits - **SME/Non-SME Scope Test**: Determine company classification for energy audit obligations. Outputs: Classification report, Threshold analysis, Evidence pack - **Auditor Brief & Selection**: Prepare scope documentation and selection criteria for energy auditors. Outputs: Auditor brief, RFP template, Selection matrix - **Audit Report Template**: Structured templates aligned to EN 16247 and national requirements. Outputs: Report template, Findings format, Action tracker - **4-Year Cycle Tracker**: Monitor audit cycles, deadlines, and renewal requirements. Outputs: Cycle calendar, Reminder system, Compliance log ### Supply Chain & Due Diligence Value chain due diligence and risk management - **Scope Scan & Risk Assessment**: Identify commodities and geographies requiring due diligence. Outputs: Scope mapping, Risk matrix, Priority areas - **Geolocation Schema**: Design data collection for EUDR geolocation evidence. Outputs: Data schema, Collection SOP, Verification checks - **Statement Filing SOP**: Prepare due diligence statements and operator declarations. Outputs: Filing workflow, Declaration template, Evidence checklist ### Governance & Controls Compliance infrastructure and monitoring - **Obligation Register**: Central register of legal obligations with ownership and status tracking. Outputs: Register template, Ownership matrix, Status dashboard - **Policy Templates**: Environmental and sustainability policy templates and approval workflows. Outputs: Policy drafts, Approval workflow, Version control - **Monitoring Calendar**: Compliance calendar with deadlines, reminders, and escalation paths. Outputs: Calendar view, Reminder rules, Escalation matrix - **Evidence & Audit Trail**: Documentation controls for inspection-ready evidence sets. Outputs: Evidence pack, Audit trail, Inspection checklist *Why Sorena* ## Research and Assess with Confidence Research Copilot answers questions with cited evidence. Assessment Autopilot identifies gaps and builds action plans. Both built for EU frameworks and country-specific requirements. - **Unified Regulatory Library**: All EU sustainability regulations indexed and cross-referenced. - Full text of CSRD, ESPR, PPWR, and more - Delegated acts and implementing measures - Cross-references between related articles - **Timeline Awareness**: Track implementation deadlines and compliance windows. - Phase-in schedules for CSDDD and DPP - PPWR recyclability target dates - ESRS reporting cycle reminders - **Requirement Extraction**: AI identifies applicable obligations from regulation text. - Natural language queries - Direct article citations - Scope and applicability guidance - **Audit-Ready Evidence**: Export cited answers for compliance documentation. - Source links to official EU texts - Paragraph-level citations - Exportable research sessions *How It Works* ## From Scoping to Remediation Research questions, identify gaps, and generate action plans — all with audit-ready evidence ## From Scoping to Remediation 1. **Scope**: Define which regulations apply. Select frameworks (CSRD, DPP, PPWR) and jurisdictions (EU, Sweden, UK). 2. **Research**: Ask questions via Research Copilot. Get cited answers from official sources — regulations, delegated acts, guidance. 3. **Assess**: Run Assessment Autopilot to identify compliance gaps. Get a prioritized list of requirements with status. 4. **Act**: Generate remediation action plans with owners and timelines. Track progress against prioritized gaps. 5. **Export**: Export research sessions, gap assessments, and action plans. Maintain audit-ready evidence trails. ## Key Capabilities ### Corporate Reporting (CSRD/ESRS) Research ESRS disclosure requirements, double materiality concepts, and cross-framework alignment. Inputs: Materiality topics, Company sector, Reporting year Outputs: Disclosure gap assessment, ESRS requirements, Remediation action plan Example questions: - What are the ESRS E1 disclosure requirements for Scope 3 emissions? - How does CSRD double materiality apply to financial services? ### Supply Chain Due Diligence (CSDDD) Understand due diligence obligations, risk assessment frameworks, and remediation requirements. Inputs: Company size, Sector, Value chain scope Outputs: Applicability timeline, Gap assessment, Due diligence action plan Example questions: - When does CSDDD apply to companies with 500+ employees? - What risk assessment is required under CSDDD Article 7? ### Product Compliance (DPP/ESPR) Research Digital Product Passport requirements, repairability rules, and product-group delegated acts. Inputs: Product category, Target market, Launch timeline Outputs: DPP data requirements, Readiness assessment, Implementation roadmap Example questions: - What data must be included in a DPP for textiles? - What are the ESPR repairability requirements for electronics? ### Packaging & Circularity (PPWR) Navigate recyclability grades, recycled content targets, and country-by-country EPR requirements. Inputs: Packaging type, Markets, Material composition Outputs: Compliance gap assessment, EPR registration plan, Target tracker Example questions: - What is the PPWR recycled content target for plastic packaging by 2030? - How do I register for EPR in Germany vs Sweden? ### Environmental Claims Research substantiation requirements for green marketing claims and PEF methodology. Inputs: Claim type, Product category, Evidence available Outputs: Substantiation gaps, Evidence checklist, Risk action plan Example questions: - What evidence is needed for a "carbon neutral" product claim? - How does the Green Claims Directive affect comparative advertising? ### Energy & Resource Efficiency Navigate EED energy audit requirements, BAT conclusions, and product ecodesign rules. Inputs: Facility type, Energy consumption, Product category Outputs: Audit gap assessment, BAT applicability, Compliance action plan Example questions: - What are the EED energy audit requirements for enterprises? - Which BAT conclusions apply to food and beverage manufacturing? *Research Quality* ## Evaluated Against Real Compliance Tasks Independent benchmark comparing AI research assistants In our January 2026 benchmark, two independent auditors scored AI responses against source documentation across 44 compliance research sessions. Sorena Research Copilot achieved full requirement coverage in the evaluated sessions. See the full report for methodology and per-session results. [View Benchmark Report](/solutions/benchmarks.md) *Methodology, scoring criteria, and per-session results available in the full report.* *Use Cases* ## From Research to Remediation Research Copilot answers your questions. Assessment Autopilot identifies gaps and builds action plans. *What You Get* ## Audit-Ready Outputs Research sessions and assessments produce structured, exportable deliverables with full traceability **In Every Answer** - Inline citations to source articles - Links to official source documents - Exportable structured format **Typical Outputs** - Gap assessment with priorities - Obligation register templates - Remediation action plans **Learn More** - [Research Copilot](/solutions/research-copilot.md) — Ask questions, get cited answers - [Assessment Autopilot](/solutions/assessment.md) — Gap analysis and action plans - [SSOT](/solutions/ssot.md) — Indexed regulatory sources ## Related Solutions - [Research Copilot](/solutions/research-copilot.md) - [Benchmarks](/solutions/benchmarks.md) - [All Solutions](/solutions.md) ## Common Questions **Which sustainability regulations does Sorena cover?** Sorena covers major EU sustainability frameworks (CSRD/ESRS, CSDDD, ESPR/DPP, EU Batteries Regulation, PPWR, Green Claims Directive, EED) plus country-specific requirements for Sweden, UK, France, Netherlands, Japan, Australia, Singapore, Brazil, and India. The library includes official texts, delegated acts, implementing measures, and national transpositions. Content is updated as new regulations are published. **What does Assessment Autopilot do?** Assessment Autopilot analyzes your company profile against applicable regulations and identifies compliance gaps. It produces a prioritized list of requirements with status (compliant, gap, not applicable), then generates remediation action plans with suggested owners and timelines. Outputs are exportable for internal tracking. Like all Sorena outputs, assessments are research assistance — not legal or compliance advice. **Does Sorena replace sustainability consultants?** No. Sorena accelerates research and assessment, but expert judgment is essential for compliance decisions. The platform helps consultants and in-house teams work faster by reducing time spent on regulatory research and gap identification. Strategic interpretation and implementation still require professional expertise. **How do citations and source links work?** Every AI-generated answer includes citations linking to the specific regulation article or paragraph. Click any citation to view the source text. This traceability helps you verify answers and maintain audit documentation with clear provenance. **What country-specific coverage is available?** Beyond EU frameworks, the library includes national transpositions and local requirements for multiple jurisdictions: Swedish EPR and Miljöbalken provisions, UK Environment Act and SECR, French AGEC Law, Netherlands packaging regulations, and Asia-Pacific requirements for Japan, Australia, Singapore, and India. For highly specific local permit questions, the AI indicates when local authority consultation is recommended. **How are new delegated acts and updates handled?** Our document library is regularly updated as the EU publishes new delegated acts, implementing measures, and guidance. You can also upload your own documents to research alongside the official library. Updates are noted in the platform changelog. **Is my research data secure?** Your workspace data stays in your isolated tenant with role-based access control. Research sessions, assessments, and uploaded documents are not used to train AI models. Full activity logging is available for compliance audits. ## Ready to Research, Assess, and Close Gaps? See how Sorena helps teams navigate sustainability regulations — from scoping requirements to generating prioritized action plans. [Book a Demo](/contact.md) | [Run an Assessment](/solutions/assessment.md) | [Explore Research Copilot →](/solutions/research-copilot.md) *Your research stays private — not used for model training.* *Evidence-first research assistance. Not legal advice.* --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/solutions/esg-compliance --- --- title: "Benchmarks" canonical_url: "https://www.sorena.io/solutions/benchmarks" source_url: "https://www.sorena.io/solutions/benchmarks" author: "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Benchmarks *Benchmark Report* January 2026 | Two Auditors | Source Citations | Two Passes Two auditors scored both Sorena Research Copilot and ChatGPT (baseline) against the same requirements across 43 real-world compliance, regulatory research, and document analysis sessions. [Try Research Copilot](/solutions/research-copilot.md) | [View Methodology](#methodology) ## Key Results | Metric | Sorena Research Copilot | ChatGPT (baseline) | | --- | --- | --- | | Perfect sessions | 43/43 | 0/43 | | Average coverage | 100% | 25% | | Requirements evaluated | 4332/4332 | Avg of 2 passes | | Factual errors | 0 | 183 | ## Benchmark Breakdown How each tool performed across compliance research sessions Scores reflect independent verification against source documentation. ### Coverage by Task Type | Category | Sessions | Sorena Coverage | ChatGPT Coverage | Gap | ChatGPT Factual Errors | | --- | ---: | ---: | ---: | ---: | ---: | | Privacy Audits | 12 | 100% | 30% | 70pp | 43 | | AI Act Audits | 6 | 100% | 28% | 72pp | 20 | | Timelines | 3 | 100% | 18% | 82pp | 17 | | Sustainability | 9 | 100% | 21% | 79pp | 53 | | Employment Law | 2 | 100% | 18% | 82pp | 3 | | Technical Review | 11 | 100% | 28% | 72pp | 47 | ### Factual Errors Incorrect statements presented as fact across all sessions. - Sorena: 0 errors - ChatGPT: 183 errors ### Requirement Coverage Compliance requirements addressed with accurate information. - Sorena: 100% coverage - ChatGPT: 25% coverage ## Results by Research Session Session-by-session benchmarks for compliance research. Click any row to view the full scenario, score breakdown, and high-level takeaways. Scores reflect independent verification against source documentation. | # | Category | Scenario | Sorena | ChatGPT | Errors | Pass 1 (S/C/T) | Pass 2 (S/C/T) | | ---: | --- | --- | ---: | ---: | ---: | --- | --- | | 1 | Privacy Audit | Privacy Notice Audit - Global e-commerce retailer | 100% | 38% | 5 | 32/16/32 | 95/25/95 | | 2 | AI Act Compliance | AI Terms & Privacy Audit - AI lab | 100% | 19% | 3 | 42/13/42 | 156/12/156 | | 3 | Privacy Audit | Privacy Policy Audit - Consumer device manufacturer | 100% | 21% | 5 | 40/14/40 | 247/19/247 | | 4 | AI Act Compliance | Cloud Service Terms Audit - Major cloud provider | 100% | 19% | 4 | 49/14/49 | 205/19/205 | | 5 | Regulatory Timeline | EUDR Timeline - Office equipment manufacturer | 100% | 19% | 9 | 30/9/30 | 207/17/207 | | 6 | Regulatory Timeline | EUDR Timeline - Beverage multinational | 100% | 13% | 7 | 46/8/46 | 204/16/204 | | 7 | Regulatory Timeline | EU Data Act Timeline - Connected appliance manufacturer | 100% | 26% | 1 | 28/11/28 | 33/4/33 | | 8 | Privacy Audit | Privacy Policy Audit - Gaming platform | 100% | 43% | 3 | 28/16/28 | 47/14/47 | | 9 | AI Act Compliance | AI Terms & Privacy Audit - AI platform | 100% | 48% | 6 | 43/23/43 | 94/40/94 | | 10 | AI Act Compliance | Cloud Terms + DPA Audit - Cloud provider | 100% | 33% | 5 | 145/49/145 | 190/63/190 | | 11 | AI Act Compliance | AI API Terms + Privacy Audit - Model API provider | 100% | 28% | 1 | 45/14/45 | 88/22/88 | | 12 | Privacy Audit | Privacy Policy Audit - Global search platform | 100% | 25% | 4 | 38/12/38 | 105/20/105 | | 13 | Privacy Audit | Privacy Policy Audit - Social platform | 100% | 22% | 5 | 50/19/50 | 92/5/92 | | 14 | Privacy Audit | Privacy Statement Audit - Enterprise software vendor | 100% | 47% | 2 | 70/20/70 | 38/25/38 | | 15 | AI Act Compliance | Product Terms + Privacy Audit - Enterprise cloud/vendor | 100% | 31% | 1 | 72/26/72 | 47/12/47 | | 16 | Privacy Audit | Privacy Statement Audit - Streaming service | 100% | 33% | 5 | 41/19/41 | 74/14/74 | | 17 | Privacy Audit | Terms + Privacy Audit - Secure messaging app | 100% | 32% | 1 | 38/18/38 | 67/11/67 | | 18 | Privacy Audit | Privacy Policy Audit - Music streaming service | 100% | 36% | 1 | 40/21/40 | 84/17/84 | | 19 | Privacy Audit | Privacy Policy Audit - Messaging platform | 100% | 56% | 1 | 45/18/45 | 28/20/28 | | 20 | Privacy Audit | Privacy Policy Audit - Short-form video platform | 100% | 24% | 6 | 38/14/38 | 103/12/103 | | 21 | Privacy Audit | Privacy Policy Audit - Social network | 100% | 30% | 5 | 120/47/120 | 66/14/66 | | 22 | Employment Law | Union Comparison - Swedish software developer | 100% | 20% | 1 | 45/10/45 | 52/9/52 | | 23 | Employment Law | Employment Contract Review - Sweden | 100% | 17% | 2 | 33/8/33 | 53/5/53 | | 24 | Technical Review | Security Guidelines Review - Connected products | 100% | 25% | 12 | 26/10/26 | 141/16/141 | | 25 | Technical Review | Cybersecurity Conformity Planning - CE/CRA readiness | 100% | 37% | 5 | 149/65/149 | 114/35/114 | | 26 | Technical Review | IoT Security Crosswalk + Test Plan - Consumer IoT | 100% | 30% | 4 | 118/45/118 | 90/20/90 | | 27 | Technical Review | FIPS 140 Delta Analysis - Cryptographic modules | 100% | 41% | 1 | 118/54/118 | 58/21/58 | | 28 | Technical Review | FIPS ↔ ISO Crypto Module Mapping | 100% | 34% | 1 | 110/42/110 | 62/19/62 | | 29 | Technical Review | ISO 27001/27002 Migration Package - ISMS update | 100% | 34% | 4 | 130/54/130 | 88/24/88 | | 30 | Technical Review | NIST 800-53 ↔ ISO 27001/27002 Mapping | 100% | 12% | 5 | 175/40/175 | 68/1/68 | | 31 | Technical Review | NIST CSF 1.1 to 2.0 Crosswalk | 100% | 29% | 5 | 180/72/180 | 39/7/39 | | 32 | Technical Review | NIST 800-171 Rev. 3 Delta + CMMC Mapping | 100% | 18% | 4 | 170/30/170 | 79/14/79 | | 33 | Technical Review | OT Security Framework Crosswalk + Gaps (IEC 62443/NIST) | 100% | 20% | 3 | 99/20/99 | 99/20/99 | | 34 | Technical Review | PCI DSS v3.2.1 to v4.0 Delta + Crosswalk | 100% | 32% | 3 | 155/52/155 | 155/47/155 | | 35 | Sustainability Compliance | EU Energy Efficiency Directive Readiness - IoT appliances | 100% | 26% | 8 | 81/21/81 | 83/22/83 | | 36 | Sustainability Compliance | ESPR + Digital Product Passport Readiness - Appliances | 100% | 22% | 2 | 122/25/122 | 112/26/112 | | 37 | Sustainability Compliance | EU Batteries Regulation Readiness - Embedded batteries | 100% | 27% | 6 | 147/35/147 | 112/34/112 | | 38 | Sustainability Compliance | EU CSDDD Readiness - Supply chain due diligence | 100% | 34% | 4 | 98/28/98 | 98/38/98 | | 39 | Sustainability Compliance | EU CSRD/ESRS Compliance Plan - Listed appliance manufacturer | 100% | 20% | 11 | 119/19/119 | 104/25/104 | | 40 | Sustainability Compliance | EU CSRD/ESRS Compliance Plan - Listed automotive manufacturer | 100% | 25% | 5 | 72/19/72 | 100/23/100 | | 41 | Sustainability Compliance | EU Green Claims Readiness - IoT appliances | 100% | 12% | 6 | 89/11/89 | 99/12/99 | | 42 | Sustainability Compliance | EU Packaging Waste EPR Readiness - Appliances | 100% | 14% | 6 | 103/14/103 | 119/17/119 | | 43 | Sustainability Compliance | EU Water Sustainability Readiness - IoT appliances | 100% | 14% | 5 | 145/29/145 | 137/12/137 | *Pass columns show Sorena/ChatGPT/Total requirements for each pass.* ### Session Details #### Session 1: Privacy Notice Audit - Global e-commerce retailer **Category:** Privacy Audit | **Date:** 2026-01-06 Audit of a global e-commerce privacy notice against GDPR and CPRA/CCPA, focusing on transparency, retention, cross-border transfers, and user rights. - **Sorena highlight:** Verified the current US and EU/UK notices, mapped GDPR + CPRA requirements to exact policy text, and produced a gap list with remediation steps. - **ChatGPT issue:** Couldn’t validate the live notices, relied on outdated sources, and missed core disclosures (rights, request methods, categories). - **Score:** Sorena 100% vs ChatGPT 38% | 5 factual errors - **Pass 1:** Sorena 32/32, ChatGPT 16/32 - **Pass 2:** Sorena 95/95, ChatGPT 25/95 #### Session 2: AI Terms & Privacy Audit - AI lab **Category:** AI Act Compliance | **Date:** 2026-01-06 Audit of an AI lab’s consumer terms and privacy policy for EU AI Act and GDPR, focusing on provider duties, transparency, and operational compliance. - **Sorena highlight:** Mapped GDPR accountability and EU AI Act GPAI duties (copyright/TDM, watermarking, transparency) into an audit-ready checklist with citations. - **ChatGPT issue:** Stayed high-level, omitted key GDPR accountability and AI Act obligations, and leaned on secondary sources. - **Score:** Sorena 100% vs ChatGPT 19% | 3 factual errors - **Pass 1:** Sorena 42/42, ChatGPT 13/42 - **Pass 2:** Sorena 156/156, ChatGPT 12/156 #### Session 3: Privacy Policy Audit - Consumer device manufacturer **Category:** Privacy Audit | **Date:** 2026-01-06 Privacy policy audit for a consumer device ecosystem, assessing GDPR/CPRA disclosures, retention clarity, transfers, and rights transparency. - **Sorena highlight:** Pinpointed GDPR/CPRA gaps like right-to-object and recipient disclosures, backed by precise citations and service-level retention details. - **ChatGPT issue:** Missed multiple mandatory disclosures and raised a few misleading compliance concerns without grounding in the policy. - **Score:** Sorena 100% vs ChatGPT 21% | 5 factual errors - **Pass 1:** Sorena 40/40, ChatGPT 14/40 - **Pass 2:** Sorena 247/247, ChatGPT 19/247 #### Session 4: Cloud Service Terms Audit - Major cloud provider **Category:** AI Act Compliance | **Date:** 2026-01-06 Contract-focused audit of cloud service terms and privacy notices for EU AI Act and GDPR coverage, including transfers, processor terms, and AI restrictions. - **Sorena highlight:** Delivered clause-level GDPR processor analysis and AI governance review, including transfer safeguards, AI service restrictions, and concrete next steps. - **ChatGPT issue:** Skipped contract-specific privacy and AI requirements and made unsupported claims instead of verifying the source terms. - **Score:** Sorena 100% vs ChatGPT 19% | 4 factual errors - **Pass 1:** Sorena 49/49, ChatGPT 14/49 - **Pass 2:** Sorena 205/205, ChatGPT 19/205 #### Session 5: EUDR Timeline - Office equipment manufacturer **Category:** Regulatory Timeline | **Date:** 2026-01-06 EU Deforestation Regulation (EUDR) workback plan for a paper supply chain, with due diligence milestones, evidence expectations, and reporting deadlines. - **Sorena highlight:** Built an EUDR workback plan anchored to the amended deadlines, product scope, and technical evidence requirements (geolocation, reporting, customs). - **ChatGPT issue:** Got key dates and scope wrong and missed multiple mandatory EUDR obligations, making the timeline unsafe to rely on. - **Score:** Sorena 100% vs ChatGPT 19% | 9 factual errors - **Pass 1:** Sorena 30/30, ChatGPT 9/30 - **Pass 2:** Sorena 207/207, ChatGPT 17/207 #### Session 6: EUDR Timeline - Beverage multinational **Category:** Regulatory Timeline | **Date:** 2026-01-06 EUDR compliance timeline for a global beverage supply chain, mapping commodity sourcing to scope, due diligence steps, and declaration deadlines. - **Sorena highlight:** Mapped EUDR obligations to a beverage supply chain with commodity/CN code examples, correct deadlines, and a step-by-step evidence plan. - **ChatGPT issue:** Misstated go-live dates and scope and omitted many legal requirements and operational steps needed for execution. - **Score:** Sorena 100% vs ChatGPT 13% | 7 factual errors - **Pass 1:** Sorena 46/46, ChatGPT 8/46 - **Pass 2:** Sorena 204/204, ChatGPT 16/204 #### Session 7: EU Data Act Timeline - Connected appliance manufacturer **Category:** Regulatory Timeline | **Date:** 2026-01-06 EU Data Act compliance timeline for a connected-appliance manufacturer, covering data access, sharing, trade secrets, and cloud switching requirements. - **Sorena highlight:** Provided a date-driven roadmap covering user access/sharing, trade secret safeguards, and cloud switching duties, with a practical workstream plan. - **ChatGPT issue:** Covered basics but omitted critical obligations like cloud switching rules, gatekeeper restrictions, and Commission guidance milestones. - **Score:** Sorena 100% vs ChatGPT 26% | 1 factual errors - **Pass 1:** Sorena 28/28, ChatGPT 11/28 - **Pass 2:** Sorena 33/33, ChatGPT 4/33 #### Session 8: Privacy Policy Audit - Gaming platform **Category:** Privacy Audit | **Date:** 2026-01-06 Privacy policy audit for a gaming platform, focusing on GDPR transparency and CPRA/CCPA disclosures for California residents. - **Sorena highlight:** Performed a requirement-by-requirement GDPR + CPRA audit including retention-per-category, request methods, and opt-out signal expectations. - **ChatGPT issue:** Left out several California and GDPR specifics (submission methods, statutory disclosures) and offered less operational guidance. - **Score:** Sorena 100% vs ChatGPT 43% | 3 factual errors - **Pass 1:** Sorena 28/28, ChatGPT 16/28 - **Pass 2:** Sorena 47/47, ChatGPT 14/47 #### Session 9: AI Terms & Privacy Audit - AI platform **Category:** AI Act Compliance | **Date:** 2026-01-06 Audit of an AI platform’s terms and privacy policy for EU AI Act and GDPR readiness, emphasizing transparency, training boundaries, and provider vs deployer responsibilities. - **Sorena highlight:** Separated what the documents prove vs what’s missing, covering rights tooling, child handling, security posture, and EU AI Act GPAI obligations. - **ChatGPT issue:** Missed practical rights pathways and several AI transparency and child-safety requirements, including a document-reference error. - **Score:** Sorena 100% vs ChatGPT 48% | 6 factual errors - **Pass 1:** Sorena 43/43, ChatGPT 23/43 - **Pass 2:** Sorena 94/94, ChatGPT 40/94 #### Session 10: Cloud Terms + DPA Audit - Cloud provider **Category:** AI Act Compliance | **Date:** 2026-01-06 Audit of cloud service terms and a data processing addendum for GDPR Article 28 and EU AI Act readiness, including key contractual caveats and deployer obligations (e.g., FRIA). - **Sorena highlight:** Mapped processor contract clauses and highlighted high-impact caveats (like pre-release scope exclusions), plus deployer AI Act duties such as FRIA. - **ChatGPT issue:** Focused on broad GDPR alignment but missed key contractual caveats and most deployer-focused AI Act obligations. - **Score:** Sorena 100% vs ChatGPT 33% | 5 factual errors - **Pass 1:** Sorena 145/145, ChatGPT 49/145 - **Pass 2:** Sorena 190/190, ChatGPT 63/190 #### Session 11: AI API Terms + Privacy Audit - Model API provider **Category:** AI Act Compliance | **Date:** 2026-01-06 Audit of an AI model API’s terms and privacy policy for GDPR and EU AI Act requirements, focusing on data-use boundaries, retention, and developer obligations. - **Sorena highlight:** Clarified paid vs unpaid data-use boundaries, retention windows, and both GDPR + AI Act transparency duties for developers and deployers. - **ChatGPT issue:** Skipped controller/legal-basis details and several concrete requirements, and included an incorrect AI Act citation. - **Score:** Sorena 100% vs ChatGPT 28% | 1 factual errors - **Pass 1:** Sorena 45/45, ChatGPT 14/45 - **Pass 2:** Sorena 88/88, ChatGPT 22/88 #### Session 12: Privacy Policy Audit - Global search platform **Category:** Privacy Audit | **Date:** 2026-01-06 Privacy policy audit for a global search platform, assessing data categories, purposes, rights, transfers, retention, and opt-out tooling under GDPR and CPRA. - **Sorena highlight:** Grounded findings in policy text, covering legal bases, controller identity, opt-out tooling (GPC, ad settings), and actionable fixes. - **ChatGPT issue:** Missed major requirements (cookies, minors, sources) and made unsupported claims contradicted by the policy. - **Score:** Sorena 100% vs ChatGPT 25% | 4 factual errors - **Pass 1:** Sorena 38/38, ChatGPT 12/38 - **Pass 2:** Sorena 105/105, ChatGPT 20/105 #### Session 13: Privacy Policy Audit - Social platform **Category:** Privacy Audit | **Date:** 2026-01-06 Privacy policy audit for a social platform, focusing on disclosure completeness, legal bases, retention clarity, and rights mechanisms under GDPR and CPRA. - **Sorena highlight:** Retrieved and analyzed the current geo-dynamic policy plus the US regional notice, verifying sale/share, GPC handling, and rights workflows with quotes. - **ChatGPT issue:** Couldn’t access the current policy, relied on an outdated version, and missed essential CPRA disclosures and request mechanisms. - **Score:** Sorena 100% vs ChatGPT 22% | 5 factual errors - **Pass 1:** Sorena 50/50, ChatGPT 19/50 - **Pass 2:** Sorena 92/92, ChatGPT 5/92 #### Session 14: Privacy Statement Audit - Enterprise software vendor **Category:** Privacy Audit | **Date:** 2026-01-06 Enterprise privacy statement audit for GDPR and CPRA, focusing on transparency obligations, retention, DSAR mechanics, and user rights coverage. - **Sorena highlight:** Completed a comprehensive GDPR + CPRA audit with verified opt-out mechanisms, DSAR timelines, and cookie/ePrivacy considerations. - **ChatGPT issue:** Covered headline items but omitted several statutory details (marketing objection, sources, timelines) needed for a compliance-grade assessment. - **Score:** Sorena 100% vs ChatGPT 47% | 2 factual errors - **Pass 1:** Sorena 70/70, ChatGPT 20/70 - **Pass 2:** Sorena 38/38, ChatGPT 25/38 #### Session 15: Product Terms + Privacy Audit - Enterprise cloud/vendor **Category:** AI Act Compliance | **Date:** 2026-01-06 Audit of enterprise product terms and privacy statements for EU AI Act and GDPR, focused on contractual commitments and shared responsibilities across the AI value chain. - **Sorena highlight:** Connected product terms, DPA expectations, and AI governance obligations, calling out what must be confirmed contractually vs operationally. - **ChatGPT issue:** Provided a higher-level review and missed several contract-specific protections and practical compliance actions (breach timing, training safeguards). - **Score:** Sorena 100% vs ChatGPT 31% | 1 factual errors - **Pass 1:** Sorena 72/72, ChatGPT 26/72 - **Pass 2:** Sorena 47/47, ChatGPT 12/47 #### Session 16: Privacy Statement Audit - Streaming service **Category:** Privacy Audit | **Date:** 2026-01-06 Privacy statement audit for a streaming service, evaluating GDPR transparency and CPRA disclosures such as sharing, preference signals, and required policy structure. - **Sorena highlight:** Verified EU/UK lawful bases and transfer safeguards, and pinpointed California disclosure gaps (GPC, 12-month lists, non-discrimination). - **ChatGPT issue:** Made incorrect claims about lawful bases, transfers, and CPRA disclosures and conflated DNT vs GPC. - **Score:** Sorena 100% vs ChatGPT 33% | 5 factual errors - **Pass 1:** Sorena 41/41, ChatGPT 19/41 - **Pass 2:** Sorena 74/74, ChatGPT 14/74 #### Session 17: Terms + Privacy Audit - Secure messaging app **Category:** Privacy Audit | **Date:** 2026-01-06 Audit of a secure messaging app’s terms and privacy disclosures for GDPR and CPRA, focusing on lawful bases, retention, rights, and audit-ready gaps. - **Sorena highlight:** Reviewed multiple relevant sources (policy, shop opt-out page, support guidance) and flagged Art. 27 representative and CPRA signal requirements. - **ChatGPT issue:** Missed several requirements and confused organizational structure, leading to a misleading compliance conclusion. - **Score:** Sorena 100% vs ChatGPT 32% | 1 factual errors - **Pass 1:** Sorena 38/38, ChatGPT 18/38 - **Pass 2:** Sorena 67/67, ChatGPT 11/67 #### Session 18: Privacy Policy Audit - Music streaming service **Category:** Privacy Audit | **Date:** 2026-01-06 Privacy policy audit for a music streaming service, reviewing GDPR/CPRA disclosures around data categories, sharing, international transfers, and rights. - **Sorena highlight:** Found and cited specific policy statements (sale/share posture) and assessed children’s protections, authorized agents, and request methods. - **ChatGPT issue:** Missed key disclosures and incorrectly claimed important statements were absent. - **Score:** Sorena 100% vs ChatGPT 36% | 1 factual errors - **Pass 1:** Sorena 40/40, ChatGPT 21/40 - **Pass 2:** Sorena 84/84, ChatGPT 17/84 #### Session 19: Privacy Policy Audit - Messaging platform **Category:** Privacy Audit | **Date:** 2026-01-06 Privacy policy audit for a messaging platform under GDPR and CPRA, including transfers, retention, rights workflows, and required disclosures. - **Sorena highlight:** Covered GDPR + CPRA specifics, including timelines, 12-month disclosures, and nuanced cross-regulation considerations (ePrivacy, case law). - **ChatGPT issue:** Omitted several mandatory CPRA/GDPR elements (non-discrimination, SPI scope, minors) and provided less actionable remediation. - **Score:** Sorena 100% vs ChatGPT 56% | 1 factual errors - **Pass 1:** Sorena 45/45, ChatGPT 18/45 - **Pass 2:** Sorena 28/28, ChatGPT 20/28 #### Session 20: Privacy Policy Audit - Short-form video platform **Category:** Privacy Audit | **Date:** 2026-01-06 Privacy policy audit for a short-form video platform under GDPR and CPRA, focusing on disclosures, rights, ad legal bases, and cross-border processing. - **Sorena highlight:** Validated EEA/UK disclosures (consent for ads, complaint routes) and pinpointed California statutory gaps like required link text and SPI handling. - **ChatGPT issue:** Missed several policy-specific disclosures and lacked statutory precision on opt-out and automated decision-making requirements. - **Score:** Sorena 100% vs ChatGPT 24% | 6 factual errors - **Pass 1:** Sorena 38/38, ChatGPT 14/38 - **Pass 2:** Sorena 103/103, ChatGPT 12/103 #### Session 21: Privacy Policy Audit - Social network **Category:** Privacy Audit | **Date:** 2026-01-06 Privacy policy audit for a social network, evaluating GDPR and CPRA transparency items, user rights coverage, and retention disclosures. - **Sorena highlight:** Mapped the policy to GDPR + CPRA with clear statutory checkpoints (toll-free methods, 12-month lists, SPI limit-use) and actionable remediation. - **ChatGPT issue:** Skipped critical California format and request-method requirements and left gaps in indirect-source and necessity disclosures. - **Score:** Sorena 100% vs ChatGPT 30% | 5 factual errors - **Pass 1:** Sorena 120/120, ChatGPT 47/120 - **Pass 2:** Sorena 66/66, ChatGPT 14/66 #### Session 22: Union Comparison - Swedish software developer **Category:** Employment Law | **Date:** 2026-01-07 Comparison of Swedish unions and collective agreements for a full-time software developer, covering benefits, tradeoffs, and agreement coverage. - **Sorena highlight:** Compared unions and collective agreements with the practical details that drive decisions (time bank, sick pay layers, pensions, notice periods). - **ChatGPT issue:** Stayed at a high level, missed core CBA differences, and included an incorrect benefit-duration claim. - **Score:** Sorena 100% vs ChatGPT 20% | 1 factual errors - **Pass 1:** Sorena 45/45, ChatGPT 10/45 - **Pass 2:** Sorena 52/52, ChatGPT 9/52 #### Session 23: Employment Contract Review - Sweden **Category:** Employment Law | **Date:** 2026-01-07 Employment contract compliance review under Swedish law, identifying risk areas, missing mandatory elements, and practical remediation guidance. - **Sorena highlight:** Applied the right Swedish-law framework (CBA context, working time limits, deductions, sick pay) and separated real risks from non-issues. - **ChatGPT issue:** Flagged clauses as violations without CBA context and missed several statutory requirements needed for a defensible review. - **Score:** Sorena 100% vs ChatGPT 17% | 2 factual errors - **Pass 1:** Sorena 33/33, ChatGPT 8/33 - **Pass 2:** Sorena 53/53, ChatGPT 5/53 #### Session 24: Security Guidelines Review - Connected products **Category:** Technical Review | **Date:** 2026-01-07 Technical review of connected product security guidelines, identifying inconsistencies and aligning requirements to real regulatory regimes and standards. - **Sorena highlight:** Turned internal security guidance into an audit-ready, regulator-aligned checklist (CRA/RED/EN 303 645) with dates, scope boundaries, and citations. - **ChatGPT issue:** Missed most regulatory specifics and produced multiple incorrect or vague suggestions that weaken the guideline. - **Score:** Sorena 100% vs ChatGPT 25% | 12 factual errors - **Pass 1:** Sorena 26/26, ChatGPT 10/26 - **Pass 2:** Sorena 141/141, ChatGPT 16/141 #### Session 25: Cybersecurity Conformity Planning - CE/CRA readiness **Category:** Technical Review | **Date:** 2026-01-10 Cybersecurity conformity assessment planning for CE/RED readiness, including evidence artifacts, assessment steps, test strategy, and documentation expectations. - **Sorena highlight:** Produced a CE conformity assessment plan with harmonized-standard traceability (OJ entries, clause IDs) and concrete pass/fail test criteria. - **ChatGPT issue:** Gave a conceptual plan but missed traceability details auditors need (OJ numbers, provision IDs, acceptance criteria) and had version inconsistencies. - **Score:** Sorena 100% vs ChatGPT 37% | 5 factual errors - **Pass 1:** Sorena 149/149, ChatGPT 65/149 - **Pass 2:** Sorena 114/114, ChatGPT 35/114 #### Session 26: IoT Security Crosswalk + Test Plan - Consumer IoT **Category:** Technical Review | **Date:** 2026-01-10 Consumer IoT security crosswalk and test plan, mapping ETSI and NIST requirements into testable procedures and evidence lists. - **Sorena highlight:** Delivered a full ETSI EN 303 645 ↔ NIST 8259A crosswalk with quote-level traceability and assessor-grade test techniques. - **ChatGPT issue:** Provided a general mapping but lacked verifiable quote anchors, missed key control extractions, and suggested risky version/citation approaches. - **Score:** Sorena 100% vs ChatGPT 30% | 4 factual errors - **Pass 1:** Sorena 118/118, ChatGPT 45/118 - **Pass 2:** Sorena 90/90, ChatGPT 20/90 #### Session 27: FIPS 140 Delta Analysis - Cryptographic modules **Category:** Technical Review | **Date:** 2026-01-10 Delta analysis of FIPS 140-1 vs FIPS 140-2 for cryptographic modules, highlighting changed requirements and assessment implications. - **Sorena highlight:** Captured clause-by-clause deltas with testable requirements, including numeric thresholds and CMVP-ready artifacts. - **ChatGPT issue:** Covered the basics but missed many validation-critical details (authentication thresholds, DTR/IG references, level-specific RNG rules). - **Score:** Sorena 100% vs ChatGPT 41% | 1 factual errors - **Pass 1:** Sorena 118/118, ChatGPT 54/118 - **Pass 2:** Sorena 58/58, ChatGPT 21/58 #### Session 28: FIPS ↔ ISO Crypto Module Mapping **Category:** Technical Review | **Date:** 2026-01-10 Crosswalk between FIPS and ISO/IEC cryptographic module requirements, mapping controls and clarifying evidence expectations for audits. - **Sorena highlight:** Mapped FIPS 140-2/140-3 to ISO 19790 with deep links to the SP 800-140x series and validation evidence expectations. - **ChatGPT issue:** Delivered a partial crosswalk but omitted key precision items (verbatim section quotes, interface taxonomy, program documents). - **Score:** Sorena 100% vs ChatGPT 34% | 1 factual errors - **Pass 1:** Sorena 110/110, ChatGPT 42/110 - **Pass 2:** Sorena 62/62, ChatGPT 19/62 #### Session 29: ISO 27001/27002 Migration Package - ISMS update **Category:** Technical Review | **Date:** 2026-01-10 ISO 27001/27002 migration package from 2013 to 2022, covering control changes, reorganization themes, and statement of applicability updates. - **Sorena highlight:** Created a practitioner-ready migration kit: machine-readable change matrix, filled SoA examples, and a timeboxed transition plan backed by authoritative sources. - **ChatGPT issue:** Missed key migration artifacts (Annex B baseline, CSV/filled SoA) and made a couple of unverified claims about control groupings. - **Score:** Sorena 100% vs ChatGPT 34% | 4 factual errors - **Pass 1:** Sorena 130/130, ChatGPT 54/130 - **Pass 2:** Sorena 88/88, ChatGPT 24/88 #### Session 30: NIST 800-53 ↔ ISO 27001/27002 Mapping **Category:** Technical Review | **Date:** 2026-01-10 Control mapping between NIST SP 800-53 Rev. 5 and ISO/IEC 27001:2022 Annex A to support alignment, crosswalks, and audit preparation. - **Sorena highlight:** Explained rev4 to rev5 changes and produced an auditor-friendly crosswalk to ISO with gaps, tests, and source-grounded rationale. - **ChatGPT issue:** Relied too much on workbook references and provided fewer verifiable anchors and test/evidence details. - **Score:** Sorena 100% vs ChatGPT 12% | 5 factual errors - **Pass 1:** Sorena 175/175, ChatGPT 40/175 - **Pass 2:** Sorena 68/68, ChatGPT 1/68 #### Session 31: NIST CSF 1.1 to 2.0 Crosswalk **Category:** Technical Review | **Date:** 2026-01-10 Crosswalk from NIST Cybersecurity Framework 1.1 to 2.0, highlighting changes and mapping structure to support transition planning. - **Sorena highlight:** Mapped CSF changes to practical transition steps and linked crosswalks to authoritative artifacts for traceability and automation. - **ChatGPT issue:** Delivered a reasonable summary but provided fewer pointers to official mapping exports and less detail on profile/tier migration. - **Score:** Sorena 100% vs ChatGPT 29% | 5 factual errors - **Pass 1:** Sorena 180/180, ChatGPT 72/180 - **Pass 2:** Sorena 39/39, ChatGPT 7/39 #### Session 32: NIST 800-171 Rev. 3 Delta + CMMC Mapping **Category:** Technical Review | **Date:** 2026-01-10 Clause-level delta analysis of NIST SP 800-171 Rev. 2 vs Rev. 3 with CMMC 2.0 mapping, identifying added objectives and assessment impact. - **Sorena highlight:** Produced audit-defensible deltas with examples, ODP governance, and a clear Rev. 3 to Rev. 2 to CMMC mapping approach. - **ChatGPT issue:** Listed new requirements but missed assessment-method impacts and source traceability, and added a nonessential news citation. - **Score:** Sorena 100% vs ChatGPT 18% | 4 factual errors - **Pass 1:** Sorena 170/170, ChatGPT 30/170 - **Pass 2:** Sorena 79/79, ChatGPT 14/79 #### Session 33: OT Security Framework Crosswalk + Gaps (IEC 62443/NIST) **Category:** Technical Review | **Date:** 2026-01-10 OT security framework crosswalk between IEC 62443 requirements and NIST SP 800-82 guidance, identifying gaps plus example tests and evidence. - **Sorena highlight:** Built an OT-safe IEC 62443 ↔ NIST 800-82 crosswalk with verification methods, evidence, and a realistic gap model. - **ChatGPT issue:** Covered high-level mapping but missed several nuanced gaps and lacked the same level of audit-defensible sourcing. - **Score:** Sorena 100% vs ChatGPT 20% | 3 factual errors - **Pass 1:** Sorena 99/99, ChatGPT 20/99 - **Pass 2:** Sorena 99/99, ChatGPT 20/99 #### Session 34: PCI DSS v3.2.1 to v4.0 Delta + Crosswalk **Category:** Technical Review | **Date:** 2026-01-10 PCI DSS v3.2.1 to v4.0 delta analysis with crosswalks to NIST SP 800-53 Rev. 5 and ISO/IEC 27001:2022, including key changes and timelines. - **Sorena highlight:** Delivered a PCI DSS migration package with authoritative citations, crosswalks, and evidence-ready remediation guidance. - **ChatGPT issue:** Missed several audit-defensibility elements (official artifacts, full quotes) and included an incorrect timeline claim. - **Score:** Sorena 100% vs ChatGPT 32% | 3 factual errors - **Pass 1:** Sorena 155/155, ChatGPT 52/155 - **Pass 2:** Sorena 155/155, ChatGPT 47/155 #### Session 35: EU Energy Efficiency Directive Readiness - IoT appliances **Category:** Sustainability Compliance | **Date:** 2026-01-14 Readiness assessment for an EU IoT home-appliance manufacturer under the EU Energy Efficiency Directive, including obligations, exemptions, and a practical implementation plan. - **Sorena highlight:** Separated what is mandatory vs optional, identified applicability triggers, and produced an evidence-driven readiness roadmap with governance and reporting steps. - **ChatGPT issue:** Missed or diluted multiple explicit requirements and produced several overconfident obligations without sufficient grounding. - **Score:** Sorena 100% vs ChatGPT 26% | 8 factual errors - **Pass 1:** Sorena 81/81, ChatGPT 21/81 - **Pass 2:** Sorena 83/83, ChatGPT 22/83 #### Session 36: ESPR + Digital Product Passport Readiness - Appliances **Category:** Sustainability Compliance | **Date:** 2026-01-14 Readiness assessment for ESPR and Digital Product Passport obligations for an EU smart-appliance manufacturer, covering applicability, data requirements, and execution plan. - **Sorena highlight:** Mapped the expected DPP/ESPR obligations to concrete product, data, and supply-chain controls with implementation sequencing. - **ChatGPT issue:** Left key requirements vague, missed multiple Sorena-identified constraints, and under-specified required artifacts and scope conditions. - **Score:** Sorena 100% vs ChatGPT 22% | 2 factual errors - **Pass 1:** Sorena 122/122, ChatGPT 25/122 - **Pass 2:** Sorena 112/112, ChatGPT 26/112 #### Session 37: EU Batteries Regulation Readiness - Embedded batteries **Category:** Sustainability Compliance | **Date:** 2026-01-14 Readiness plan for EU Batteries Regulation obligations relevant to consumer appliances with embedded or supplied batteries, including labeling, due diligence, and reporting. - **Sorena highlight:** Provided a compliance-ready breakdown of obligations by battery type and role (producer/importer), with evidence deliverables and timeline discipline. - **ChatGPT issue:** Overlooked several explicit obligations and mis-prioritized workstreams, creating compliance gaps for key battery-related duties. - **Score:** Sorena 100% vs ChatGPT 27% | 6 factual errors - **Pass 1:** Sorena 147/147, ChatGPT 35/147 - **Pass 2:** Sorena 112/112, ChatGPT 34/112 #### Session 38: EU CSDDD Readiness - Supply chain due diligence **Category:** Sustainability Compliance | **Date:** 2026-01-14 Readiness assessment for EU corporate sustainability due diligence obligations for an EU-listed appliance manufacturer, including governance, risk mapping, and remediation. - **Sorena highlight:** Turned due diligence requirements into implementable controls: governance, policy, risk mapping, supplier engagement, grievance handling, and reporting. - **ChatGPT issue:** Missed several explicit duties and introduced ambiguous guidance that would leave audit-critical evidence and controls incomplete. - **Score:** Sorena 100% vs ChatGPT 34% | 4 factual errors - **Pass 1:** Sorena 98/98, ChatGPT 28/98 - **Pass 2:** Sorena 98/98, ChatGPT 38/98 #### Session 39: EU CSRD/ESRS Compliance Plan - Listed appliance manufacturer **Category:** Sustainability Compliance | **Date:** 2026-01-14 CSRD/ESRS compliance applicability and readiness plan for an EU-listed smart-appliance manufacturer, including reporting scope, materiality, assurance, and data controls. - **Sorena highlight:** Clarified applicability boundaries and produced a compliance program plan spanning governance, materiality, ESRS datapoints, assurance, and disclosure logistics. - **ChatGPT issue:** Had multiple scope/timeline inconsistencies and missed high-impact requirements around reporting mechanics and assurance-readiness artifacts. - **Score:** Sorena 100% vs ChatGPT 20% | 11 factual errors - **Pass 1:** Sorena 119/119, ChatGPT 19/119 - **Pass 2:** Sorena 104/104, ChatGPT 25/104 #### Session 40: EU CSRD/ESRS Compliance Plan - Listed automotive manufacturer **Category:** Sustainability Compliance | **Date:** 2026-01-14 CSRD/ESRS applicability and compliance plan for an EU-listed automotive manufacturer, including ESRS scope, phased timelines, and operational reporting readiness. - **Sorena highlight:** Provided a structured, evidence-driven program plan with clear scoping, sequencing, and accountability to operationalize ESRS reporting. - **ChatGPT issue:** Missed multiple explicit requirements and introduced misleading simplifications that would create gaps in CSRD reporting readiness. - **Score:** Sorena 100% vs ChatGPT 25% | 5 factual errors - **Pass 1:** Sorena 72/72, ChatGPT 19/72 - **Pass 2:** Sorena 100/100, ChatGPT 23/100 #### Session 41: EU Green Claims Readiness - IoT appliances **Category:** Sustainability Compliance | **Date:** 2026-01-14 Readiness assessment for EU green-claims compliance in marketing and product communications for an EU IoT appliance manufacturer. - **Sorena highlight:** Converted green-claims obligations into a practical substantiation workflow: claims inventory, evidence standards, governance, and review gates. - **ChatGPT issue:** Overlooked key compliance requirements and provided under-scoped guidance that could increase greenwashing risk. - **Score:** Sorena 100% vs ChatGPT 12% | 6 factual errors - **Pass 1:** Sorena 89/89, ChatGPT 11/89 - **Pass 2:** Sorena 99/99, ChatGPT 12/99 #### Session 42: EU Packaging Waste EPR Readiness - Appliances **Category:** Sustainability Compliance | **Date:** 2026-01-14 Packaging waste and EPR compliance readiness plan for an EU home-appliance manufacturer, covering registration, reporting, labeling, and operational controls. - **Sorena highlight:** Outlined a compliance-ready EPR program with country-by-country obligations, operational ownership, and reporting/evidence requirements. - **ChatGPT issue:** Missed several explicit obligations and under-specified evidence and process controls required for multi-country EPR compliance. - **Score:** Sorena 100% vs ChatGPT 14% | 6 factual errors - **Pass 1:** Sorena 103/103, ChatGPT 14/103 - **Pass 2:** Sorena 119/119, ChatGPT 17/119 #### Session 43: EU Water Sustainability Readiness - IoT appliances **Category:** Sustainability Compliance | **Date:** 2026-01-14 EU water-sustainability and water-efficiency compliance readiness plan for IoT appliances, including product efficiency, disclosures, and governance. - **Sorena highlight:** Translated water-efficiency obligations and expectations into actionable controls, product requirements, and evidence-backed readiness steps. - **ChatGPT issue:** Left multiple requirements uncovered and included misleading generalizations that would not hold up in an audit. - **Score:** Sorena 100% vs ChatGPT 14% | 5 factual errors - **Pass 1:** Sorena 145/145, ChatGPT 29/145 - **Pass 2:** Sorena 137/137, ChatGPT 12/137 ## Why This Matters for Your Organization Purpose-built AI for compliance research delivers measurable advantages - **Complete Coverage**: 100% coverage across 4,332 requirements, with no surprise gaps left for auditors to find. - **Zero Factual Errors**: 0 factual errors flagged across 43 sessions, reducing the risk of acting on incorrect information. - **Audit-Ready Citations**: Direct links to exact text passages in legal documents for full traceability. - **Specialized Expertise**: Purpose-built for regulatory research, not a general-purpose tool stretched thin. ## How We Evaluated Transparent two-step scoring process with an independent second review ### Evaluation Overview | Field | Value | | --- | --- | | Period | Jan 2026 | | Task Categories | 6 | | Total Sessions | 43 | | Requirements Evaluated | 4,332 | | Internet Access | Enabled | | Reasoning Effort | High | ### Scoring Criteria A requirement was marked correct only if the response: - Explicitly addressed the requirement - Provided accurate information - Cited verifiable sources where applicable ### Independent Dual Review Each session was scored independently by two auditors. Neither auditor saw the other's evaluation until scoring was complete. - Auditor 1: Independent review against compliance requirements - Auditor 2: Independent review against compliance requirements Scores shown are the combined average from both auditors. ### Disclaimers - Results based on internal evaluation conducted January 2026. - ChatGPT (baseline) is OpenAI ChatGPT, used as a general-purpose AI comparison. - All factual errors counted are from ChatGPT responses only. - This evaluation focused on regulatory and compliance research tasks. - Results may vary depending on specific use case and document types. - Not a substitute for legal counsel or professional advice. ## Related Solutions - [Research Copilot](/solutions/research-copilot.md) - [ESG Compliance](/solutions/esg-compliance.md) - [Assessment Autopilot](/solutions/assessment.md) - [All Solutions](/solutions.md) ## Ready to Experience the Difference? See how our Research Copilot can transform your compliance research with a personalized demo. [Schedule a Demo](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/solutions/benchmarks --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "EU NIS2 Compliance Decision Map: Scope, Essential vs Important, Article 21 Controls, and Incident Reporting" canonical_url: "https://www.sorena.io/artifacts/eu-nis2-compliance-decision-map" source_url: "https://www.sorena.io/artifacts/eu-nis2-compliance-decision-map" author: "Sorena AI" description: "Advanced EU NIS2 Compliance Decision Map for Directive (EU) 2022/2555 execution: determine applicability across Annex I/II sectors." keywords: - "EU NIS2 Compliance Decision Map compliance" - "EU NIS2 Compliance Decision Map guide" - "EU NIS2 Compliance Decision Map checklist" - "EU NIS2 Compliance Decision Map requirements" - "EU NIS2 Compliance Decision Map template" - "Directive EU 2022 2555 implementation" - "NIS2 scope Annex I Annex II" - "NIS2 essential entity important entity" - "NIS2 Article 21 controls" - "NIS2 Article 23 reporting 24 hours 72 hours one month" - "Implementing Regulation EU 2024 2690" - "NIS2 transposition tracker" - "EU NIS2 Compliance Decision Map" - "Directive (EU) 2022/2555" - "Essential vs important entities" - "Article 21 cybersecurity measures" - "Article 23 incident reporting" - "NIS2 transposition" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU NIS2 Compliance Decision Map: Scope, Essential vs Important, Article 21 Controls, and Incident Reporting Advanced EU NIS2 Compliance Decision Map for Directive (EU) 2022/2555 execution: determine applicability across Annex I/II sectors. ![EU NIS2 Compliance Decision Map: Scope, Essential vs Important, Article 21 Controls, and Incident Reporting](https://cdn.sorena.io/cheatsheets/sorena-ai-nis2-cheatsheet-small.jpg) *NIS2* *Free Resource* ## EU NIS2 Compliance Decision Map This EU NIS2 Compliance Decision Map helps teams convert legal scoping into implementation decisions. Determine whether entities are in scope, classify essential versus important status, and map Article 21 controls and Article 23 reporting duties into accountable operational workflows. Grounded in Directive (EU) 2022/2555, Commission Implementing Regulation (EU) 2024/2690, ENISA technical implementation guidance, and Commission transposition resources across Member States. [Create my custom view](/solutions/assessment.md) ## What you can decide faster - **Scope and applicability**: Assess Annex I/II sector fit, size-cap thresholds, and regardless-of-size triggers with defensible logic. - **Supervisory posture**: Classify essential versus important entity status and map resulting governance, assurance, and enforcement implications. - **Control and reporting operations**: Translate Article 21 risk-management measures and Article 23 timelines into runbooks, ownership, and evidence. By Sorena AI | Updated Mar 2026 | No sign-up required **Key highlights:** Scope first | Essential vs important | 24h/72h/1 month workflow ## Primary sources - [Directive (EU) 2022/2555 (NIS2) - base text](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022L2555&ref=sorena.io) - Primary legal text defining scope, supervisory structure, and cyber-risk management and reporting obligations. - [Directive (EU) 2022/2555 - consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02022L2555-20221227&ref=sorena.io) - Consolidated legal text for implementation and control-mapping work. - [Commission Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ%3AL_202402690&ref=sorena.io) - Technical and methodological requirements supporting cyber risk-management measures. - [European Commission NIS2 policy page](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive?ref=sorena.io) - Official policy overview including obligations, scope, and implementation context. - [European Commission NIS2 transposition tracker](https://digital-strategy.ec.europa.eu/en/policies/nis-transposition?ref=sorena.io) - Member State implementation status and national transposition references. - [Commission NIS2 FAQs](https://digital-strategy.ec.europa.eu/en/faqs/directive-measures-high-common-level-cybersecurity-across-union-nis2-directive-faqs?ref=sorena.io) - Practical interpretation aid for applicability, entities, and obligations. - [ENISA NIS2 Technical Implementation Guidance](https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance?ref=sorena.io) - Implementation support and mappings for technical and organisational control design. ## NIS2 incident reporting workflow *NIS2* | Time | Step | Detail | | --- | --- | --- | | 24h | Early warning | Initial triage and significant-impact alerting to CSIRT/competent authority. | | 72h | Notification | Structured incident notification with indicators, impact, and mitigation status. | | 1 month | Final report | Root cause, service impact, cross-border effects, and long-term corrective actions. | Use this map to connect NIS2 reporting clocks with escalation paths, owners, and audit-ready records. | Value | Metric | | --- | --- | | Annex I/II | Sector basis | | Art. 21 | Control baseline | | 24h/72h | Reporting clocks | | 2024/2690 | Implementing act | ## Key dates for EU NIS2 implementation *NIS2 Timeline* Track NIS2 milestones across Directive adoption, transposition progress, implementing guidance, and supervisory readiness deadlines that affect operational execution. ## What does NIS2 require for your organisation? *NIS2 Compliance Decision Map* Follow the decision flow from applicability to entity classification and then into obligation clusters: governance and management accountability, technical and organisational measures, supply-chain risk, and incident reporting duties. *Go further* ## Turn this NIS2 map into an implementation-grade operating model Use these NIS2 deep-dive pages to convert scoping outcomes into control systems, reporting workflows, and evidence artifacts that survive supervisory and audit scrutiny. - Map scope decisions to legal entities, services, and jurisdiction-specific supervisory entry points - Implement Article 21 measures with control ownership, measurable criteria, and verification evidence - Operationalise 24h/72h/1 month incident reporting with escalation, communications, and forensic handoff - Build management accountability and supply-chain assurance into recurring governance cycles - [Customize with Copilot](/solutions/research-copilot.md): Tailor NIS2 scoping, controls, and reporting workflows to your organisation. - [Open requirements deep dive](/artifacts/eu/nis2-directive/requirements.md): Break down NIS2 obligations into control domains, owners, and evidence outputs. - [Open compliance checklist](/artifacts/eu/nis2-directive/checklist.md): Use an audit-ready checklist with acceptance criteria and proof-of-implementation. - [Open incident reporting workflow](/artifacts/eu/nis2-directive/incident-reporting-workflow.md): Implement end-to-end 24h/72h/1 month reporting with clear escalation ownership. - [Open essential vs important guide](/artifacts/eu/nis2-directive/scope-essential-vs-important.md): Classify entities and align governance and supervisory preparation accordingly. - **Download Decision Map**: Share scope and obligation logic with legal, security, and engineering teams. - **Download Timeline**: Share implementation milestones and transposition checkpoints. - [Talk to an expert](/contact.md): Get a guided scoping session and implementation plan. ## Decision Steps ### STEP 1: Do you provide services or carry out activities within the EU? - NIS2 applies through Member State transposition and supervision. - As a rule, it applies to certain Annex I/II entity types that are medium-sized or larger and provide services or carry out activities within the Union. - NIS2 also sets jurisdiction rules; for certain entity types, if not established in the Union but offering services within the Union, a representative in the Union must be designated. - **YES** Do you exclusively operate in national security / defence / law enforcement (or provide services exclusively to those bodies)? - **NO** NIS2 likely not your primary regime ### STEP 2: Do you exclusively operate in national security / defence / law enforcement (or provide services exclusively to those bodies)? - NIS2 does not apply to certain public administration entities in these areas. - Member States may exempt certain other entities from NIS2 obligations for these activities/services; trust service providers are carved out from that exemption. - NIS2 does not apply to entities exempted from the scope of Regulation (EU) 2022/2554 (DORA) under Article 2(4) of that Regulation. - **YES** Possible exemption for certain activities/services - **NO** Are you covered by NIS2 regardless of your size? ### STEP 3: Are you covered by NIS2 regardless of your size? - NIS2 includes several categories regardless of enterprise size. - Member States can also apply NIS2 to local public administration entities and to education institutions (especially where they carry out critical research). - **YES** Do you provide domain name registration services? - **NO** Is your entity type listed in NIS2 Annex I (sectors of high criticality)? ### STEP 4: Do you provide domain name registration services? - NIS2 explicitly covers entities providing domain name registration services regardless of size. - Separate provisions include a registry (ENISA) and obligations on domain name registration data. - **YES** In scope: Domain name registration services - **NO** Are you explicitly considered an Essential Entity under NIS2 (Article 3)? ### STEP 5: Are you explicitly considered an Essential Entity under NIS2 (Article 3)? - Essential entities include: qualified trust service providers, TLD registries and DNS service providers (regardless of size). - Essential entities also include: central government public administration entities; and critical entities under Directive (EU) 2022/2557. - Providers of public electronic communications networks/services are essential if they qualify as a medium-sized enterprise under the SME definition. - If a Member State so provides, entities identified before 16 January 2023 as operators of essential services under NIS1 may be treated as essential entities. - **YES** Likely Essential Entity under NIS2 - **NO** Likely Important Entity under NIS2 ### STEP 6: Is your entity type listed in NIS2 Annex I (sectors of high criticality)? - Annex I lists sectors of high criticality and specific entity types (for example energy, transport, banking, health, digital infrastructure, public administration, and more). - If you are Annex I and large (exceed medium-sized ceilings), you are generally an essential entity; otherwise you are generally an important entity unless your Member State identifies you differently. - **YES** Do you qualify as a medium-sized enterprise or larger (SME definition)? - **NO** If not Annex I: is your entity type listed in NIS2 Annex II (other critical sectors)? ### STEP 7: Do you qualify as a medium-sized enterprise or larger (SME definition)? - As a rule, NIS2 applies to Annex I/II entity types that qualify as medium-sized enterprises, or exceed the medium-sized ceilings. - If you are micro or small, you may still be covered if your Member State identifies you under the risk-based criteria in Article 2(2)(b)-(f), or if other size-independent rules apply. - **YES** Do you exceed the ceilings for medium-sized enterprises (i.e., are you large)? - **NO** Country-specific NIS2 review needed ### STEP 8: Do you exceed the ceilings for medium-sized enterprises (i.e., are you large)? - Large Annex I entities are generally classified as essential entities under Article 3(1)(a). - If you do not exceed medium-sized ceilings, you are generally an important entity (unless Member State identification applies). - **YES** Likely Essential Entity under NIS2 - **NO** Likely Important Entity under NIS2 ### STEP 6B: If not Annex I: is your entity type listed in NIS2 Annex II (other critical sectors)? - Annex II lists other critical sectors and specific entity types. - Annex II entities that are medium-sized or larger are generally classified as important entities (unless Member State identification applies). - **YES** Do you qualify as a medium-sized enterprise or larger (SME definition)? - **NO** NIS2 likely not your primary regime ### STEP 7B: Do you qualify as a medium-sized enterprise or larger (SME definition)? - As a rule, NIS2 applies to Annex I/II entity types that qualify as medium-sized enterprises, or exceed the medium-sized ceilings. - If you are micro or small, you may still be covered if your Member State identifies you under the risk-based criteria in Article 2(2)(b)-(f), or if other size-independent rules apply. - **YES** Likely Important Entity under NIS2 - **NO** Country-specific NIS2 review needed ## Reference Information ### In-scope Regardless of Size (Examples) - Providers of public electronic communications networks or publicly available electronic communications services (Art. 2(2)(a)(i)) - Trust service providers (Art. 2(2)(a)(ii)) - Top-level domain name registries and DNS service providers (Art. 2(2)(a)(iii)) - Entities identified as critical entities under Directive (EU) 2022/2557 (Art. 2(3)) - Entities providing domain name registration services (Art. 2(4)) - Central government public administration entities; and certain regional public administration entities (Art. 2(2)(f)) - Member-State identified entities under Art. 2(2)(b)-(e) (sole provider, significant public safety/health impact, systemic risk, national/regional criticality) - Member States may apply NIS2 to local public administration entities and to education institutions (Art. 2(5)) ### Annex I - Sectors of High Criticality (Sector/Subsector) - Energy: Electricity; District heating and cooling; Oil; Gas; Hydrogen - Transport: Air; Rail; Water; Road - Banking - Financial market infrastructures - Health - Drinking water - Waste water - Digital infrastructure - ICT service management (business-to-business) - Public administration - Space ### Annex II - Other Critical Sectors (Sector/Subsector) - Postal and courier services - Waste management - Manufacture, production and distribution of chemicals - Production, processing and distribution of food - Manufacturing: Medical devices/IVDs; Computers/electronics/optical; Electrical equipment; Machinery; Motor vehicles; Other transport equipment - Digital providers: Online marketplaces; Online search engines; Social networking services platforms - Research: Research organisations ### SME Thresholds (Recommendation 2003/361/EC, Annex Article 2) - SME category: < 250 persons and turnover ≤ EUR 50m and/or balance sheet total ≤ EUR 43m - Medium-sized enterprise: in SME category but not micro or small - Small enterprise: < 50 persons and turnover and/or balance sheet total ≤ EUR 10m - Microenterprise: < 10 persons and turnover and/or balance sheet total ≤ EUR 2m - Large enterprise: exceeds the medium-sized ceilings (not an SME) ### Governance (Article 20) - Management bodies must approve risk-management measures and oversee implementation (Art. 20(1)) - Management bodies can be held liable for infringements of Article 21 (Art. 20(1)) - Management body members must follow training; entities should train employees regularly (Art. 20(2)) ### Cybersecurity Risk-Management Measures (Article 21(2)) - Policies on risk analysis and information system security - Incident handling - Business continuity (backup, disaster recovery, crisis management) - Supply chain security (direct suppliers/service providers) - Security in acquisition, development and maintenance (vulnerability handling/disclosure) - Assess effectiveness of measures - Basic cyber hygiene practices and cybersecurity training - Use of cryptography and (where appropriate) encryption - HR security, access control policies and asset management - Multi-factor authentication / continuous authentication; secured communications; secured emergency communications (where appropriate) ### Sector-Specific Union Legal Acts (Article 4) - If a sector-specific EU legal act requires risk-management measures or significant incident notification that are at least equivalent in effect, relevant NIS2 provisions (including supervision/enforcement) do not apply to those entities (Art. 4(1)) - Equivalence can be met where measures are at least equivalent to Art. 21(1)-(2), or reporting is at least equivalent to Art. 23(1)-(6) and allows immediate access to notifications (Art. 4(2)) - If a sector-specific act does not cover all entities in a sector within NIS2 scope, NIS2 continues to apply to entities not covered by that act (Art. 4(1)) ### Implementing Acts & ENISA Guidance (Example) - NIS2 provides for implementing acts laying down technical/methodological requirements for Article 21(2) measures for certain digital providers and trust services (Art. 21(5)) - ENISA guidance supports implementation of Commission Implementing Regulation (EU) 2024/2690 for several digital infrastructure, ICT service management, and digital provider entity types (ENISA, 26 June 2025) ### Significant Incident Reporting (Article 23) - Notify significant incidents without undue delay to CSIRT or competent authority (Art. 23(1)) - A significant incident includes severe operational disruption/financial loss, or considerable material/non-material damage to others (Art. 23(3)) - Where applicable, communicate significant cyber threats to potentially affected service recipients (Art. 23(2)) - Early warning: within 24 hours of becoming aware (Art. 23(4)(a)) - Incident notification: within 72 hours of becoming aware (Art. 23(4)(b)) - Intermediate report: upon request (Art. 23(4)(c)) - Final report: no later than one month after incident notification (Art. 23(4)(d)) - Ongoing incident: progress report + final within one month of handling (Art. 23(4)(e)) - Trust service providers: incident notification within 24 hours for trust-service-impacting significant incidents (Art. 23(4), derogation) ### Supervision & Enforcement (Articles 32-33) - Essential entities: competent authorities can use on-site inspections, off-site supervision (including random checks), and regular/targeted security audits (Art. 32(2)) - Important entities: supervision is conducted ex post (Art. 33(2)) ### Registry & Domain Data (Articles 27-28) - ENISA maintains a registry for specific digital providers (Art. 27(1)) - Member States require registry information submission by 17 January 2025 and updates within 3 months (Art. 27(2)-(3)) - TLD registries and domain name registration service providers must collect/maintain accurate domain registration data (Art. 28(1)-(3)) - Access to specific domain registration data must be provided to legitimate access seekers upon lawful/substantiated requests, with reply within 72 hours (Art. 28(5)) ## Possible Outcomes ### [Essential entity] Likely Essential Entity under NIS2 Essential entities must implement cybersecurity risk-management measures and report significant incidents. Management bodies must approve and oversee measures. - Governance obligations apply to management bodies (Art. 20). - Cybersecurity risk-management measures must include the minimum set in Art. 21(2). - Significant incident reporting includes 24h early warning and 72h incident notification (Art. 23). - Sector-specific Union legal acts may replace certain NIS2 provisions where they are equivalent in effect (Art. 4). ### [Important entity] Likely Important Entity under NIS2 If you are an Annex I/II entity type and are in scope but not classified as essential, you are generally considered an important entity. - Important entities must implement cybersecurity risk-management measures (Art. 21) and report significant incidents (Art. 23). - Management bodies must approve and oversee measures (Art. 20). - If your Member State identifies you as essential under Art. 2(2)(b)-(e), you can be treated as essential (Art. 3(1)(e)). - Sector-specific Union legal acts may replace certain NIS2 provisions where they are equivalent in effect (Art. 4). ### [In scope (DNS)] In scope: Domain name registration services NIS2 applies to entities providing domain name registration services regardless of size, and includes specific registry and domain name registration data obligations. - ENISA maintains a registry that includes entities providing domain name registration services (Art. 27). - Member States require submission of specified registry information and updates (Art. 27(2)-(3)). - Domain name registration data obligations apply to entities providing domain name registration services and to TLD registries (Art. 28). ### [Needs review] Country-specific NIS2 review needed If you are in an Annex I/II sector but are not clearly medium-sized or larger, or if your Member State may identify you under the risk-based criteria, confirm your status using national transposition and competent authority guidance. - Member States can identify additional entities as essential/important under Art. 2(2)(b)-(e). - Public administration at regional level is included based on a risk-based assessment; local public administration and education institutions can be included if a Member State so provides (Art. 2(2)(f), Art. 2(5)). - Some entities can be exempted from certain obligations for specific activities/services related to national security/defence/law enforcement (Art. 2(8)). ### [Potential exemption] Possible exemption for certain activities/services If you operate in national security/defence/law enforcement areas (or provide services exclusively to those bodies), your Member State may exempt you from certain NIS2 obligations for those activities/services. - Public administration entities in these areas are excluded (Art. 2(7)). - Member States may exempt specific entities from obligations in Articles 21 and 23 for those activities/services (Art. 2(8)). - This exemption does not apply where an entity acts as a trust service provider (Art. 2(9)). ### [Out of scope] NIS2 likely not your primary regime Based on EU-activity, special-category, and Annex I/II screens, NIS2 may be less likely to apply. Confirm using your Member State transposition and competent authority guidance. - Scope is set out in Article 2, and Annex I/II list the covered sectors and entity types. - Member States can include additional entities using risk-based criteria. ## NIS2 Timeline (Selected Milestones) | Date | Event | Reference | | --- | --- | --- | | 2022-12-27 | NIS2 published in Official Journal (Directive (EU) 2022/2555) | Dir. 2022/2555 | | 2023-01-16 | NIS2 enters into force | Dir. 2022/2555 | | 2023-09-14 | Commission Guidelines on Article 3(4) published (entity list template) | 2023/C 324/02 | | 2023-09-18 | Commission Guidelines on Article 4(1)-(2) published | 2023/C 328/02 | | 2024-10-17 | National transposition deadline | Transposition | | 2024-10-18 | NIS1 repealed; NIS2 measures apply | Art. 44 | | 2025-06-26 | ENISA NIS2 Technical Implementation Guidance published | ENISA | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2020-12-16 | Commission publishes NIS2 proposal | Legislative History | COM(2020) 823 | | 2021-12-03 | Council agrees its position | Legislative History | | | 2022-05-13 | Political agreement reached | Legislative History | | | 2022-07-13 | ITRE committee adopts agreed text | Legislative History | | | 2022-11-10 | Parliament plenary adoption | Legislative History | | | 2022-11-28 | Council formal adoption | Legislative History | | | 2022-12-14 | Final act signed by co-legislators | Official Publication | | | 2022-12-27 | Published in Official Journal | Official Publication | OJ L 333, 27.12.2022 | | 2023-01-16 | Entry into force | Official Publication | | | 2023-07-17 | Commission deadline for Article 4 guidelines | Commission Deliverables | Art. 4(3) | | 2023-09-14 | Guidelines on Article 3(4) published | Commission Deliverables | 2023/C 324/02 | | 2023-09-18 | Guidelines on Article 4(1)-(2) published | Commission Deliverables | 2023/C 328/02 | | 2023-12-22 | Corrigendum: Article 19(1) deadline wording | Corrigendum | Art. 19(1) | | 2024-02-01 | Cooperation Group work programme due | Cooperation & Networks | Art. 14(7) | | 2024-07-17 | EU-CyCLONe first report due | Cooperation & Networks | Art. 16(7) | | 2024-10-17 | Implementing Regulation 2024/2690 adopted | Implementing Acts | Reg. (EU) 2024/2690 | | 2024-10-17 | Transposition deadline | National Transposition | Art. 41(1) | | 2024-10-18 | Implementing Regulation 2024/2690 published in OJ | Implementing Acts | OJ L 2024/2690 | | 2024-10-18 | NIS1 repealed, NIS2 measures apply | National Transposition | Art. 44 | | 2024-11-07 | Implementing Regulation 2024/2690 enters into force | Implementing Acts | OJ L 2024/2690 | | 2025-01-17 | Registry information submission due | National Obligations | Art. 27(2) | | 2025-01-17 | Member States notify penalty rules | National Obligations | Art. 36 | | 2025-01-17 | CSIRTs network progress report due | Cooperation & Networks | Art. 15(4) | | 2025-01-17 | Peer-review methodology due | Cooperation & Networks | Art. 19(1) | | 2025-04-17 | Entity list established | National Obligations | Art. 3(3) | | 2025-04-17 | Aggregate entity data notification | National Obligations | Art. 3(5) | | 2025-06-26 | ENISA technical implementation guidance published | Cooperation & Networks | Version 1.0 | | 2026-01-20 | Commission proposes NIS2 amendment | Legislative History | COM(2026) 13 | | 2027-10-17 | Commission review of NIS2 | Commission Deliverables | Art. 40 | **Event details:** - **2020-12-16 - Commission publishes NIS2 proposal**: European Commission publishes the NIS2 proposal COM(2020) 823 final, proposing measures for a high common level of cybersecurity across the Union. - **2021-12-03 - Council agrees its position**: Council agrees its position (general approach) to start negotiations with the European Parliament. - **2022-05-13 - Political agreement reached**: Council and European Parliament reach provisional political agreement on NIS2. - **2022-07-13 - ITRE committee adopts agreed text**: EP Industry, Research and Energy (ITRE) committee adopts the agreed text after trilogue. - **2022-11-10 - Parliament plenary adoption**: European Parliament adopts NIS2 in plenary: 577 in favour, 6 against, 31 abstentions. - **2022-11-28 - Council formal adoption**: Council of the EU formally adopts NIS2. - **2022-12-14 - Final act signed by co-legislators**: NIS2 Directive signed by both co-legislators on 14 December 2022. - **2022-12-27 - Published in Official Journal**: Directive (EU) 2022/2555 published in the Official Journal of the European Union (OJ L 333, 27.12.2022). - **2023-01-16 - Entry into force**: NIS2 enters into force on the 20th day following OJ publication (16 January 2023). Member States have until 17 October 2024 to transpose. - **2023-07-17 - Commission deadline for Article 4 guidelines**: Commission deadline to provide guidelines clarifying the application of Article 4(1) and Article 4(2). - **2023-09-14 - Guidelines on Article 3(4) published**: Commission publishes Guidelines on the application of Article 3(4) with a data-collection template for establishing entity lists. - **2023-09-18 - Guidelines on Article 4(1)-(2) published**: Commission publishes Guidelines on equivalence with sector-specific Union legal acts, pursuant to Article 4(3) (deadline was 17 Jul 2023). - **2023-12-22 - Corrigendum: Article 19(1) deadline wording**: Corrigendum changes Article 19(1) deadline wording from 'on' to 'by' 17 January 2025 for the Cooperation Group peer-review methodology. - **2024-02-01 - Cooperation Group work programme due**: Cooperation Group must establish a work programme by 1 February 2024 and every two years thereafter. - **2024-07-17 - EU-CyCLONe first report due**: EU-CyCLONe must submit a report assessing its work to the European Parliament and Council by 17 July 2024 and every 18 months thereafter. - **2024-10-17 - Implementing Regulation 2024/2690 adopted**: Commission adopts Implementing Regulation (EU) 2024/2690 specifying technical and methodological requirements and incident-significance criteria for listed digital infrastructure and service providers. OJ publication 18 Oct 2024; enters into force 20 days later. - **2024-10-17 - Transposition deadline**: Member States must adopt and publish national transposition measures by 17 October 2024. Measures apply from 18 October 2024. - **2024-10-18 - Implementing Regulation 2024/2690 published in OJ**: Commission Implementing Regulation (EU) 2024/2690 is published in the Official Journal on 18 October 2024. - **2024-10-18 - NIS1 repealed, NIS2 measures apply**: Directive (EU) 2016/1148 (NIS1) is repealed with effect from 18 October 2024. National NIS2 measures apply from this date. - **2024-11-07 - Implementing Regulation 2024/2690 enters into force**: Commission Implementing Regulation (EU) 2024/2690 enters into force on the twentieth day following its Official Journal publication (published 18 October 2024). - **2025-01-17 - Registry information submission due**: Member States must require entities referred to in Article 27(1) to submit registry information to competent authorities by 17 January 2025. - **2025-01-17 - Member States notify penalty rules**: Member States must notify the Commission of their national penalty rules and enforcement measures by 17 January 2025. - **2025-01-17 - CSIRTs network progress report due**: CSIRTs network must adopt a report assessing progress in operational cooperation by 17 January 2025 and every two years thereafter. - **2025-01-17 - Peer-review methodology due**: Cooperation Group must establish the peer-review methodology and organisational aspects by 17 January 2025. - **2025-04-17 - Entity list established**: Member States must establish a list of essential and important entities (and entities providing domain name registration services) by 17 April 2025. - **2025-04-17 - Aggregate entity data notification**: Competent authorities must notify the Commission and Cooperation Group of aggregate list data (number of essential and important entities per sector) by 17 April 2025 and every two years thereafter. - **2025-06-26 - ENISA technical implementation guidance published**: ENISA publishes the NIS2 Technical Implementation Guidance (version 1.0) supporting implementation of Implementing Regulation (EU) 2024/2690. - **2026-01-20 - Commission proposes NIS2 amendment**: Commission publishes proposal to amend NIS2 (simplification and alignment). This is a proposal, not yet law. - **2027-10-17 - Commission review of NIS2**: The Commission shall review the functioning of the NIS2 Directive by 17 October 2027 and every 36 months thereafter, and submit a report to the European Parliament and Council. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu-nis2-compliance-decision-map --- --- title: "EU AI Act Compliance Decision Map: Scope, Risk Class, GPAI, and Evidence Workflow" canonical_url: "https://www.sorena.io/artifacts/eu-ai-act-compliance-decision-map" source_url: "https://www.sorena.io/artifacts/eu-ai-act-compliance-decision-map" author: "Sorena AI" description: "Advanced EU AI Act Compliance Decision Map for Regulation (EU) 2024/1689 implementation: scope and role tests, prohibited practices, high-risk classification." keywords: - "EU AI Act Compliance Decision Map compliance" - "EU AI Act Compliance Decision Map guide" - "EU AI Act Compliance Decision Map checklist" - "EU AI Act Compliance Decision Map requirements" - "EU AI Act Compliance Decision Map template" - "EU AI Act compliance roadmap" - "Regulation EU 2024 1689 implementation" - "Article 5 prohibited AI practices" - "Annex III high-risk AI systems" - "Article 50 AI transparency requirements" - "GPAI model obligations Article 53" - "systemic risk model obligations Article 55" - "EU AI Act Compliance Decision Map" - "Regulation (EU) 2024/1689" - "High-risk AI" - "Article 5 prohibited practices" - "Article 50 transparency" - "GPAI obligations" - "EU AI Office" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Compliance Decision Map: Scope, Risk Class, GPAI, and Evidence Workflow Advanced EU AI Act Compliance Decision Map for Regulation (EU) 2024/1689 implementation: scope and role tests, prohibited practices, high-risk classification. ![EU AI Act Compliance Decision Map by Sorena AI](https://cdn.sorena.io/cheatsheets/sorena-ai-ai-act-cheatsheet-small.jpg) *EU AI Act* *Free Resource* ## EU AI Act Compliance Decision Map This EU AI Act Compliance Decision Map helps teams convert legal interpretation into implementation actions. Confirm scope and role, test for prohibited practices, classify high-risk AI systems, and identify transparency and GPAI obligations with clear ownership outcomes. Grounded in Regulation (EU) 2024/1689, Commission GPAI scope guidelines (C(2025) 5045 final), AI Office implementation materials, and GPAI code of practice resources. [Create my custom view](/solutions/assessment.md) ## What you can decide faster - **Applicability and role**: Determine whether the AI Act applies and identify provider, deployer, importer, distributor, or product manufacturer duties. - **Risk and controls**: Classify prohibited, high-risk, limited-risk, or minimal-risk use and map obligations to technical and governance controls. - **GPAI and systemic risk**: Map Chapter V obligations, transparency outputs, serious incident reporting, and risk mitigation requirements. By Sorena AI | Updated Mar 2026 | No sign-up required **Key highlights:** Scope and role first | Risk class to controls | Evidence-ready program ## Primary sources - [Regulation (EU) 2024/1689 (Artificial Intelligence Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for AI Act obligations, risk categories, governance, and enforcement architecture. - [Commission Guidelines on GPAI obligations scope (C(2025) 5045 final)](https://digital-strategy.ec.europa.eu/en/library/guidelines-scope-obligations-providers-general-purpose-ai-models-under-ai-act?ref=sorena.io) - Clarifies GPAI model/provider scope, systemic-risk triggers, exemptions, and enforcement expectations. - [General-Purpose AI Code of Practice](https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai?ref=sorena.io) - Voluntary implementation framework covering transparency, copyright, and safety/security practices for GPAI providers. - [Template for Public Summary of Training Content](https://digital-strategy.ec.europa.eu/en/library/explanatory-notice-and-template-public-summary-training-content-general-purpose-ai-models?ref=sorena.io) - Commission materials supporting Article 53(1)(d) public summary obligations for GPAI providers. - [Serious incident reporting template for GPAI models with systemic risk](https://digital-strategy.ec.europa.eu/en/library/ai-act-commission-publishes-reporting-template-serious-incidents-involving-general-purpose-ai-models-systemic-risk?ref=sorena.io) - Operational reference for serious incident reporting under systemic-risk GPAI obligations. ## Compliance quick-start *Regulation (EU) 2024/1689* | Time | Step | Detail | | --- | --- | --- | | Art. 5 | Prohibited practices | Identify banned use cases early and stop non-permitted deployment paths. | | Annex III | High-risk classification | Map lifecycle controls, risk management, technical documentation, and conformity requirements. | | Art. 53/55 | GPAI duties | Implement model transparency, copyright policy, and systemic-risk measures where applicable. | Use the map to connect legal obligations, engineering controls, and evidence-ready governance outputs. | Value | Metric | | --- | --- | | 1 Aug 2024 | Entry into force | | 2 Feb 2025 | Prohibitions apply | | 2 Aug 2025 | GPAI obligations | | 2 Aug 2026 | Main application | ## Key dates for EU AI Act implementation *AI Act Timeline* Track phased application and implementation checkpoints so product, legal, risk, and security teams can sequence delivery with shared assumptions. ## Decide faster what the Act means for your system or model *AI Act Decision Map* Follow yes/no branching from scope to a clear execution path: prohibition handling, high-risk lifecycle controls, transparency implementation, or GPAI compliance operations. *Go further* ## Turn this decision map into a complete AI Act execution program Use the EU AI Act deep-dive pages to move from decision-map outcomes to implementation work items, templates, and evidence workflows. - Prioritise high-risk and prohibited-use remediation with accountable owners and milestones - Operationalise Article 50 transparency and user disclosure controls across product flows - Implement GPAI documentation, public summary, and incident reporting workflows - Build requirement-to-evidence traceability for governance reviews, partners, and audits - [Open requirements deep dive](/artifacts/eu/ai-act/requirements.md): Map AI Act obligations to controls, owners, and evidence outputs. - **Download Decision Map**: Share classification and obligation logic with product, legal, security, and compliance teams. - **Download Timeline**: Share phased dates and planning checkpoints across teams. - [Open compliance checklist](/artifacts/eu/ai-act/checklist.md): Use an audit-ready checklist with acceptance criteria and evidence expectations. ## Decision Steps ### STEP 1: Does the EU AI Act apply to your organisation and AI activity? *Reference: Art. 2(1)* - Providers placing on the market / putting into service AI systems or placing GPAI models on the Union market - Deployers established or located in the Union - Non-EU providers/deployers where the output is used in the Union - Importers and distributors of AI systems; product manufacturers placing AI systems with their products under their name/trademark; authorised representatives of non-EU providers - Affected persons located in the Union (rights and safeguards) - **NO** EU AI Act likely does not apply - **YES** Does your AI system or use-case fall under a prohibited AI practice? ### STEP 2: Does your AI system or use-case fall under a prohibited AI practice? *Reference: Art. 5* - Manipulative/deceptive techniques materially distorting behaviour causing (or likely causing) significant harm (Art. 5(1)(a)) - Exploitation of vulnerabilities (age/disability/socio-economic) causing (or likely causing) significant harm (Art. 5(1)(b)) - Social scoring leading to detrimental/unjustified or disproportionate treatment (Art. 5(1)(c)) - Criminal offence risk assessment of individuals based solely on profiling/personality traits (Art. 5(1)(d)) - Untargeted scraping to build or expand facial recognition databases (Art. 5(1)(e)) - Emotion recognition in workplace/education (narrow medical/safety exception) (Art. 5(1)(f)) - Biometric categorisation inferring sensitive attributes (Art. 5(1)(g)) - Real-time remote biometric ID in public spaces for law enforcement (narrow exceptions + safeguards) (Art. 5(1)(h)) - **YES** Stop: prohibited AI practice - **NO** Are you placing a General-Purpose AI (GPAI) model on the Union market as a provider? ### STEP 3: Are you placing a General-Purpose AI (GPAI) model on the Union market as a provider? *Reference: Art. 2(1)(a); Art. 3(3),(63)* - GPAI model = broadly capable + integrable into downstream systems - If you are only using a third-party model, continue on the AI-system path - **YES** Is it a GPAI model with systemic risk? - **NO** Is your AI system classified as high-risk? ### SYSTEMIC RISK: Is it a GPAI model with systemic risk? - Systemic risk models have additional obligations (Art. 55) - Commission can designate models ex officio; list is published and kept up to date (Art. 52(4)-(6)) - Commission Guidelines (C(2025) 5045 final) provide practical examples and classification guidance - **YES** GPAI systemic-risk obligations - **NO** GPAI model provider obligations ### STEP 4: Is your AI system classified as high-risk? *Reference: Art. 6; Annex I; Annex III* - High-risk if safety component/product under Annex I + third-party conformity assessment (Art. 6(1)) - High-risk if listed in Annex III (Art. 6(2)) - Annex III derogation: may be not high-risk if no significant risk + narrow task (Art. 6(3)) - Annex III is always high-risk if it performs profiling of natural persons (Art. 6(3)) - If you claim Annex III is not high-risk: document assessment + register (Art. 6(4); Art. 49(2)) - **YES** Are you the provider of the high-risk AI system (or did you become one via modifications/rebranding)? - **NO** Does your AI system trigger AI Act transparency obligations? ### STEP 5: Are you the provider of the high-risk AI system (or did you become one via modifications/rebranding)? *Reference: Art. 3(3); Art. 16; Art. 25* - Providers carry conformity assessment, CE marking, documentation and QMS duties - Importers/distributors/deployers may become providers if they rebrand, substantially modify, or change intended purpose - **YES** High-risk AI provider obligations - **NO** High-risk AI deployer obligations ### STEP 6: Does your AI system trigger AI Act transparency obligations? *Reference: Art. 50* - AI systems that interact with people (chatbots/assistants) must disclose the interaction (Art. 50(1)) - Generative AI outputs must be marked as AI-generated/manipulated (Art. 50(2)) - Deployers of emotion recognition or biometric categorisation must inform exposed persons (Art. 50(3)) - Deepfakes and public-interest AI-generated text have disclosure duties (Art. 50(4)) - **YES** Transparency obligations apply - **NO** No high-risk / transparency trigger found ## Reference Information ### Scope & Exclusions (Quick) - Excludes: national security; exclusively military/defence/national security use (Art. 2(3)) - Excludes: AI systems/models developed solely for scientific R&D (Art. 2(6)) - Excludes: personal non-professional use by natural persons (Art. 2(10)) - Open-source exception (limited): not applicable unless high-risk or Art. 5/50 systems (Art. 2(12)) - Sectoral EU product/consumer laws still apply (Art. 2(9)) ### Key Roles & Definitions - Provider: develops (or has developed) and places on market/puts into service under own name/trademark (Art. 3(3)) - Deployer: uses an AI system under its authority (Art. 3(4)) - GPAI model: capable of performing a wide range of distinct tasks; integrable downstream (Art. 3(63)) - Systemic risk: high-impact GPAI risk that can propagate at scale (Art. 3(65)) - Value chain: modifications or rebranding can make you the provider (Art. 25) ### Baseline Obligation: AI Literacy - Providers and deployers must take measures to ensure sufficient AI literacy of staff/users operating AI on their behalf - Consider technical knowledge, experience, education/training, and the context of use - Applies even where your system is not high-risk ### Governance & Authorities - AI Office (Union level): implementation/monitoring for AI systems and GPAI models (Art. 64; Def. Art. 3(47)) - European AI Board: Union-level governance and coordination (Art. 65) - Advisory forum + scientific panel support implementation (Arts. 67-68) - National competent authorities + single point of contact (Art. 70) ### Commission GPAI Guidelines (Scope) - C(2025) 5045 final (18 July 2025): scope of Chapter V obligations - Examples: what counts as a GPAI model; lifecycle; who is a provider placing on market - Open-source exemptions: conditions on licence, lack of monetisation, public availability of parameters - Annex: training compute estimation (for classification guidance) ### GPAI Code of Practice - Voluntary tool to demonstrate compliance (Arts. 53(4), 55(2), 56) - Chapters: Transparency, Copyright, Safety & Security - Includes templates (e.g., Model Documentation Form) and practical measures ### Templates & Reporting (GPAI) - Public Summary of Training Content template (Art. 53(1)(d)) - Model Documentation Form template (Code of Practice - Transparency chapter) - Serious incidents reporting template (Art. 55(1)(c)) ### Annex III (High-Risk Areas) - Biometrics (remote ID, sensitive categorisation, emotion recognition) - Critical infrastructure (as safety components) - Education/vocational training (admission, evaluation, monitoring tests) - Employment/workers management (recruitment, monitoring, termination, task allocation) - Essential services/benefits (credit scoring, insurance pricing, emergency call triage) - Law enforcement; migration/asylum/border; justice & democratic processes ### Annex III Derogation (Not High-Risk Claims) - Annex III system can only be treated as not high-risk if it does not pose a significant risk of harm (incl. not materially influencing decision outcomes) and fits a narrow-task condition (Art. 6(3)) - Always high-risk if it performs profiling of natural persons (Art. 6(3)) - Provider must document the assessment and is subject to registration (Art. 6(4); Art. 49(2)) ### Section 2 Requirements (High-Risk) - Risk management system (Art. 9) - Data & data governance (Art. 10) - Technical documentation (Art. 11; Annex IV) - Record-keeping/logging (Arts. 12 and 19) - Transparency + instructions for use (Art. 13) - Human oversight (Art. 14) - Accuracy, robustness, cybersecurity (Art. 15) ### Responsibilities Along the Value Chain - If you rebrand, substantially modify, or change intended purpose you can become the provider (Art. 25(1)) - Initial provider must cooperate and provide required info/technical access (Art. 25(2)) - Supplier/provider agreements should allocate info/access needed for compliance (Art. 25(4)) ### Notified Bodies & Conformity Assessment - Member States designate notifying authorities (Art. 28) - Notified bodies must meet independence and competence requirements (Art. 31) - Identification numbers and lists of notified bodies (Art. 35) - Use notified bodies where required by the conformity route (Art. 43 context) ### Harmonised Standards & Common Specifications - Applying harmonised standards can create a presumption of conformity for covered AI Act requirements/obligations (Art. 40(1)) - If harmonised standards are missing or insufficient, the Commission may adopt common specifications (Art. 41) - Standards/common specs can reduce ambiguity for documentation, testing, and conformity assessment routes (Art. 40-43 context) ### Fundamental Rights Impact Assessment (FRIA) - Required before deploying certain high-risk AI systems (Art. 27(1)) - Describe use context, affected groups, risks, human oversight, and mitigations (Art. 27(1)(a)-(f)) - Update when changes occur; notify market surveillance authority with a template (Art. 27(2)-(5)) ### Code of Practice (AI-generated Content) - AI Office-led code of practice supports Art. 50(2) and (4) compliance - Working group 1 (providers): machine-readable marking + robustness/interoperability - Working group 2 (deployers): disclosure of deepfakes and other transparency duties - Drafting timeline targets readiness before Art. 50 obligations apply ## Possible Outcomes ### [PROHIBITED] Stop: prohibited AI practice Do not place on the market / put into service / use in the Union - Re-design the system and/or intended purpose to remove the prohibited practice - Assess if a different use-case or safeguards move you out of Art. 5 - Document the decision and seek legal review for edge cases (e.g., law enforcement exceptions) ### [GPAI] GPAI model provider obligations Documentation, downstream transparency, copyright policy, and training-content summary - Technical documentation for AI Office / authorities (Art. 53(1)(a); Annex XI) - Information for downstream system providers (Art. 53(1)(b); Annex XII) - Copyright compliance policy incl. rights reservations (Art. 53(1)(c)) - Publish public summary of training content (Art. 53(1)(d)) ### [GPAI (SYSTEMIC RISK)] GPAI systemic-risk obligations Art. 53 + additional systemic-risk controls - Model evaluation + adversarial testing to identify/mitigate systemic risks (Art. 55(1)(a)) - Assess and mitigate systemic risks at Union level (Art. 55(1)(b)) - Report serious incidents + corrective measures to AI Office without undue delay (Art. 55(1)(c)) - Ensure adequate cybersecurity for the model and supporting infrastructure (Art. 55(1)(d)) ### [HIGH-RISK (PROVIDER)] High-risk AI provider obligations Requirements + conformity assessment + registration + post-market monitoring - Meet Section 2 requirements (risk mgmt, data governance, logs, transparency, human oversight, cybersecurity) - Quality management system (Art. 17) + technical documentation (Art. 11; Annex IV) - Conformity assessment (Art. 43) + EU DoC (Art. 47) + CE marking (Art. 48) - Register in EU database (Art. 49) and run post-market monitoring (Art. 72) + incident reporting (Art. 73) ### [HIGH-RISK (DEPLOYER)] High-risk AI deployer obligations Use per instructions, human oversight, monitoring, FRIA (some cases), and transparency to affected persons - Use per provider instructions + assign competent human oversight (Art. 26(1)-(3)) - Input data quality under your control (Art. 26(4)) - Monitor + suspend and notify for risks/serious incidents (Art. 26(5)) - Inform individuals subject to Annex III decisioning systems (Art. 26(11)); perform FRIA where applicable (Art. 27) ### [TRANSPARENCY] Transparency obligations apply Disclose AI interaction, label AI-generated content, and handle deepfakes - Inform users when they interact with an AI system unless obvious (Art. 50(1)) - Inform people exposed to emotion recognition or biometric categorisation systems (Art. 50(3)) - Mark synthetic content outputs machine-readably and detectably (Art. 50(2)) - Disclose deepfakes; disclose AI-generated public-interest text unless editorial control applies (Art. 50(4)) - Provide info clearly and accessibly by first interaction/exposure (Art. 50(5)) ### [BASELINE] No high-risk / transparency trigger found Still in scope: keep core controls and monitor future classification changes - Maintain AI literacy measures (Art. 4) - Re-check classification when intended purpose, autonomy, or context changes - Track Commission guidelines and standards: Annex III use cases and Art. 50 list can evolve ### [OUT OF SCOPE] EU AI Act likely does not apply No Union nexus under Art. 2(1) (or an exclusion applies) - Document why you are out of scope (facts + legal basis) - Re-assess if output becomes used in the Union or you place systems/models on the Union market - Other laws (GDPR, product safety, sector rules) may still apply ## EU AI Act Timeline | Date | Event | Reference | | --- | --- | --- | | 2024-07-12 | AI Act published in Official Journal (OJ L) | Reg. (EU) 2024/1689 | | 2024-08-01 | AI Act enters into force (20 days after publication) | Art. 113 | | 2025-02-02 | Chapters I (General provisions) and II (Prohibited practices) apply | Art. 113(a) | | 2025-05-02 | Codes of practice for GPAI should be ready (latest) | Art. 56(9) | | 2025-08-02 | GPAI obligations + governance + notified bodies + penalties apply | Art. 113(b) | | 2026-02-02 | Commission provides Art. 6 high-risk classification guidelines (latest) | Art. 6(5) | | 2026-08-02 | AI Act applies (general application date) | Art. 113 | | 2027-08-02 | Art. 6(1) (Annex I product/safety-component high-risk) + corresponding obligations apply | Art. 113(c) | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2024-01-24 | Commission Decision establishes the European AI Office | Notified bodies & governance | | | 2024-07-12 | AI Act published in the Official Journal | Legislative milestones | | | 2024-08-01 | AI Act enters into force | Legislative milestones | | | 2025-02-02 | Chapters I and II apply (including prohibited AI practices) | Prohibitions | | | 2025-07-10 | General-Purpose AI Code of Practice published | GPAI | | | 2025-07-18 | Commission adopts guidelines on GPAI obligations scope | GPAI | | | 2025-08-02 | GPAI obligations and governance provisions apply | GPAI | | | 2025-09-01 | Consultation to develop guidelines and a Code of Practice (transparent AI systems) | Transparency & labelling | | | 2025-09-26 | Consultation on serious AI incident reporting interplay | Incident reporting & post-market | | | 2025-10-01 | Chairs and vice-chairs selection | Transparency & labelling | | | 2025-11-04 | Reporting template for serious incidents (GPAI systemic risk) published | Incident reporting & post-market | | | 2025-11-05 | Kick-off plenary (start of 1st drafting round) | Transparency & labelling | | | 2025-11-17 | 1st working group meetings | Transparency & labelling | | | 2025-12-05 | Template published for public summary of GPAI training content | GPAI | | | 2025-12-17 | First draft published | Transparency & labelling | | | 2026-01-12 | Working group meetings (start of 2nd drafting round) | Transparency & labelling | | | 2026-01-21 | Workshops (working groups 1 and 2) | Transparency & labelling | | | 2026-03-01 | Second draft published (TBC) | Transparency & labelling | | | 2026-04-01 | Working group meetings (TBC) | Transparency & labelling | | | 2026-05-01 | Closing plenary and final Code of Practice published | Transparency & labelling | | | 2026-08-02 | AI Act applies (main obligations start) | Legislative milestones | | | 2026-08-02 | Commission enforcement powers for GPAI enter into application | GPAI | | | 2027-08-02 | Article 6(1) and corresponding obligations apply | High-risk AI | | | 2027-08-02 | Existing GPAI providers must comply by this date | GPAI | | **Event details:** - **2024-01-24 - Commission Decision establishes the European AI Office**: 24 January 2024: European Commission publishes the decision establishing the European AI Office. - **2024-07-12 - AI Act published in the Official Journal**: 12 July 2024: Regulation (EU) 2024/1689 is published in the Official Journal (OJ L, 12.7.2024). - **2024-08-01 - AI Act enters into force**: 1 August 2024: The EU AI Act enters into force (20 days after publication). - **2025-02-02 - Chapters I and II apply (including prohibited AI practices)**: 2 February 2025: Chapters I and II apply under the AI Act entry into force and application rules. - **2025-07-10 - General-Purpose AI Code of Practice published**: 10 July 2025: The General-Purpose AI (GPAI) Code of Practice is published as a voluntary tool to help providers meet AI Act obligations. - **2025-07-18 - Commission adopts guidelines on GPAI obligations scope**: 18 July 2025: Commission finalises its guidelines on the scope of obligations for general-purpose AI models (C(2025) 5045 final). - **2025-08-02 - GPAI obligations and governance provisions apply**: 2 August 2025: Chapter V (general-purpose AI) and selected governance provisions start to apply (per Article 113). - **2025-09-01 - Consultation to develop guidelines and a Code of Practice (transparent AI systems)**: September 2025: Consultation to develop guidelines and a Code of Practice on transparent AI systems, plus a call for expression of interest to participate. - **2025-09-26 - Consultation on serious AI incident reporting interplay**: 26 September 2025: Consultation referenced alongside serious incident reporting guidance and templates for AI incidents. - **2025-10-01 - Chairs and vice-chairs selection**: October 2025: Eligibility checks and selection of applications for chairs and vice-chairs. - **2025-11-04 - Reporting template for serious incidents (GPAI systemic risk) published**: 4 November 2025: Commission publishes a reporting template for serious incidents involving general-purpose AI models with systemic risk. - **2025-11-05 - Kick-off plenary (start of 1st drafting round)**: 5 November 2025: Kick-off plenary; start of the first drafting round. - **2025-11-17 - 1st working group meetings**: 17-18 November 2025: First working group meetings. - **2025-12-05 - Template published for public summary of GPAI training content**: 5 December 2025: Commission publishes an explanatory notice and a template for the public summary of training content (Article 53(1)(d)). - **2025-12-17 - First draft published**: 17 December 2025: Publication of the first draft. - **2026-01-12 - Working group meetings (start of 2nd drafting round)**: 12 and 14 January 2026: Working group meetings; start of the second drafting round. - **2026-01-21 - Workshops (working groups 1 and 2)**: 21-22 January 2026: Workshops for working groups 1 and 2. - **2026-03-01 - Second draft published (TBC)**: March 2026 (TBC): Publication of the second draft; start of the final drafting round. - **2026-04-01 - Working group meetings (TBC)**: April 2026 (TBC): Working group meetings. - **2026-05-01 - Closing plenary and final Code of Practice published**: May-June 2026: Closing plenary; publication of the final Code of Practice. - **2026-08-02 - AI Act applies (main obligations start)**: 2 August 2026: The AI Act applies in general (per Article 113). - **2026-08-02 - Commission enforcement powers for GPAI enter into application**: 2 August 2026: Commission enforcement powers for obligations on providers of GPAI models enter into application (including fines). - **2027-08-02 - Article 6(1) and corresponding obligations apply**: 2 August 2027: Article 6(1) and corresponding obligations apply (per Article 113). - **2027-08-02 - Existing GPAI providers must comply by this date**: By 2 August 2027: Providers of GPAI models placed on the market before 2 August 2025 must comply, per Commission guidance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu-ai-act-compliance-decision-map --- --- title: "EU DORA Compliance Decision Map: Scope, TLPT, Incident Reporting, and ICT Third-Party Controls" canonical_url: "https://www.sorena.io/artifacts/eu-dora-compliance-decision-map" source_url: "https://www.sorena.io/artifacts/eu-dora-compliance-decision-map" author: "Sorena AI" description: "Advanced EU DORA Compliance Decision Map for Regulation (EU) 2022/2554 execution: determine scope and proportionality, operationalise ICT risk controls." keywords: - "EU DORA Compliance Decision Map compliance" - "EU DORA Compliance Decision Map guide" - "EU DORA Compliance Decision Map checklist" - "EU DORA Compliance Decision Map requirements" - "EU DORA Compliance Decision Map template" - "Regulation EU 2022 2554 implementation" - "DORA major ICT incident reporting workflow" - "DORA TLPT readiness program" - "DORA ICT third-party contract clauses" - "DORA register of information template" - "DORA simplified ICT risk management framework" - "critical ICT third-party provider DORA oversight" - "EU DORA Compliance Decision Map" - "Regulation (EU) 2022/2554" - "ICT risk management" - "Major ICT incident reporting" - "TLPT" - "ICT third-party risk" - "Register of information" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DORA Compliance Decision Map: Scope, TLPT, Incident Reporting, and ICT Third-Party Controls Advanced EU DORA Compliance Decision Map for Regulation (EU) 2022/2554 execution: determine scope and proportionality, operationalise ICT risk controls. ![EU DORA Compliance Decision Map by Sorena AI](https://cdn.sorena.io/cheatsheets/sorena-ai-dora-cheatsheet-small.jpg) *DORA* *Free Resource* ## EU DORA Compliance Decision Map This EU DORA Compliance Decision Map helps teams move from legal text to executable decisions. Confirm whether your entity is in scope, determine the right implementation track, and connect DORA obligations to concrete controls, owners, and auditable evidence. Grounded in Regulation (EU) 2022/2554 and key Level 2 RTS/ITS measures for incident reporting, ICT risk management, subcontracting risk, TLPT, and register-of-information operations. [Create my custom view](/solutions/assessment.md) ## What you can decide faster - **Scope and proportionality**: Classify entity status, exclusions, and whether simplified ICT risk measures are relevant. - **Operational reporting model**: Design major ICT incident reporting from initial notification to final report with accountable owners. - **Third-party and testing posture**: Map contract clauses, register governance, subcontracting controls, and TLPT readiness. By Sorena AI | Updated Mar 2026 | No sign-up required ### DORA control-workstream navigator *Regulation (EU) 2022/2554* - **Board and senior management**: Approve resilience strategy, risk appetite, and oversight cadence across ICT and business continuity dependencies. - **Risk, security, and operations**: Run ICT risk lifecycle, incident classification and notification, and testing evidence management. - **Procurement and vendor governance**: Apply mandatory contract requirements, concentration-risk checks, and register-of-information discipline. - **Internal audit and assurance**: Validate control design and operating effectiveness, with remediation tracking tied to DORA obligations. Use the map to turn DORA scope outcomes into implementation work packages and evidence artifacts. | Value | Metric | | --- | --- | | 17 Jan 2025 | Application date | | RTS/ITS | Level 2 detail | | TLPT | Threat-led testing | | ICT TPRM | Third-party focus | **Key highlights:** Scope first | Incident readiness | Vendor governance ## Primary sources - [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary legal text defining digital operational resilience obligations for financial entities. - [Delegated Regulation (EU) 2024/1774 (ICT risk management RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng?ref=sorena.io) - Detailed requirements for ICT risk tools, methods, processes, policies, and simplified framework elements. - [Delegated Regulation (EU) 2025/301 (incident reporting RTS)](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng?ref=sorena.io) - Defines content and time limits for major ICT incident and voluntary significant cyber threat notifications. - [Implementing Regulation (EU) 2025/302 (incident reporting ITS)](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng?ref=sorena.io) - Standard forms, templates, and procedures for initial, intermediate, and final incident reporting. - [Implementing Regulation (EU) 2024/2956 (register of information ITS)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Template and data model expectations for ICT third-party contractual register reporting. - [Delegated Regulation (EU) 2025/1190 (TLPT RTS)](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng?ref=sorena.io) - Criteria for identifying financial entities required to perform threat-led penetration testing. - [Delegated Regulation (EU) 2024/1773 (ICT contract RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - Contractual requirements for ICT services supporting critical or important functions. - [ESAs designation of critical ICT third-party providers](https://www.esma.europa.eu/press-news/esma-news/european-supervisory-authorities-designate-critical-ict-third-party-providers?ref=sorena.io) - Supervisory context for oversight of designated critical ICT third-party providers. ## Key dates for EU DORA implementation *DORA Timeline* Track DORA rollout milestones, Level 2 delegated and implementing acts, and supervisory updates that impact controls, evidence, and operating cadence. ## What does DORA require for your operating model? *DORA Compliance Decision Map* Follow the decision flow from scope to obligation clusters: governance and ICT risk management, major incident reporting, resilience testing and TLPT, and ICT third-party risk management with contract and register expectations. *Go further* ## Turn this decision map into an execution-grade DORA program Use these DORA subpages to convert decision outcomes into implemented controls, evidence workflows, and measurable readiness milestones. - Map each DORA requirement cluster to accountable teams, controls, and evidence outputs - Build major ICT incident reporting playbooks with templates, escalation routes, and deadlines - Operationalise TLPT readiness and testing governance tied to critical or important functions - Implement ICT third-party contracts and register governance with concentration and subcontracting controls - **Open requirements deep dive**: Break down DORA obligations into controls and evidence expectations. - **Open compliance checklist**: Run an audit-ready implementation checklist with owner and evidence tracking. - **Open incident reporting guide**: Implement initial, intermediate, and final major incident reporting workflows. - **Open third-party risk guide**: Apply DORA contract clauses and register-of-information operations for ICT suppliers. - **Open TLPT readiness guide**: Plan governance, scoping, and execution steps for threat-led penetration testing. - **Download Decision Map**: Share DORA decision logic with legal, risk, and engineering stakeholders. - **Download Timeline**: Share implementation milestones and supervisory timing checkpoints. ## Decision Steps ### STEP 1: Are you one of the entity types listed in DORA Article 2(1)? *Reference: Art. 2(1)* - This is the core personal scope test for DORA. - If yes: check exclusions (Art. 2(3)) and any optional Member State exclusion (Art. 2(4)). - **NO** Out of Scope - **YES** Does an Article 2(3) exclusion apply to you? ### STEP 2: Does an Article 2(3) exclusion apply to you? *Reference: Art. 2(3)* - If yes, DORA does not apply to you. - If no, continue to check the Member State optional exclusion (Art. 2(4)) and whether you are a financial entity or an ICT third-party service provider. - **YES** Out of Scope - **NO** Has your Member State excluded your entity type under Article 2(4)? ### STEP 3: Has your Member State excluded your entity type under Article 2(4)? *Reference: Art. 2(4)* - Member States may exclude certain CRD-exempt entities located in their territory (Art. 2(4)). - If unsure: verify with your national competent authority (and any published Member State notification under Art. 2(4)). - If you are not an entity referred to in CRD Art. 2(5)(4)-(23), answer 'No' and continue. - **YES** Out of Scope (Member State Exclusion) - **NO** Which DORA track applies? ### STEP 4: Which DORA track applies? - Financial entity track (Art. 2(1)(a)-(t); defined in Art. 2(2)). - ICT third-party service provider track (Art. 2(1)(u)). - If you are both (e.g., a regulated financial entity that also provides ICT services), follow the financial entity track first and also review the ICT provider track. - -> Are you a 'financial entity' as defined in DORA? ### STEP 5: Are you a 'financial entity' as defined in DORA? *Reference: Art. 2(1)(a)-(t) & Art. 2(2)* - If yes: follow the financial entity compliance track (Chapters II-V). - If no: you may still be in scope as an ICT third-party service provider (Art. 2(1)(u)). - **YES** Financial entity is within DORA scope - **NO** Are you an ICT third-party service provider under Art. 2(1)(u)? ### ICT TRACK: Are you an ICT third-party service provider under Art. 2(1)(u)? *Reference: Art. 2(1)(u) & Art. 3(19)-(21)* - 'ICT third-party service provider' = an undertaking providing ICT services (Art. 3(19)). - 'ICT services' = digital and data services provided through ICT systems on an ongoing basis (includes hardware as a service / support via updates; excludes traditional analogue telephone services) (Art. 3(21)). - DORA also defines an 'ICT intra-group service provider' as an undertaking in a financial group providing predominantly ICT services within the group (Art. 3(20)). - **YES** Have you been designated as a critical ICT third-party service provider (CTPP)? - **NO** Out of Scope ### IN SCOPE: Financial entity is within DORA scope *Reference: Art. 2(1)-(2)* - Implement ICT risk management (Chapter II), incident management and reporting (Chapter III), resilience testing (Chapter IV), and ICT third-party risk management (Chapter V). - Apply proportionality across Chapters II-V as required by Art. 4. - -> Do you qualify for the simplified ICT risk management framework? ### STEP 6: Do you qualify for the simplified ICT risk management framework? *Reference: Art. 16(1)* - If yes: Articles 5 to 15 do not apply, but you must meet the Art. 16 minimum requirements. - Art. 16(1) covers (among others): small and non-interconnected investment firms; payment institutions exempted under PSD2; electronic money institutions exempted under EMD2; small IORPs; and certain CRD-exempt institutions depending on whether the Member State used Art. 2(4). - **YES** DORA Applies (Simplified ICT Risk Framework) - **NO** Are you a microenterprise (as defined in DORA)? ### STEP 7: Are you a microenterprise (as defined in DORA)? *Reference: Art. 3(60)* - Microenterprise = financial entity (excluding trading venues, CCPs, TRs, and CSDs) with fewer than 10 persons and <= EUR 2M annual turnover and/or balance sheet total. - Microenterprises are in scope, but several requirements apply only to financial entities other than microenterprises (e.g., crisis management function; some audit/testing formalities; TLPT). - **YES** DORA Applies (Microenterprise) - **NO** Are you required to perform threat-led penetration testing (TLPT)? ### STEP 8: Are you required to perform threat-led penetration testing (TLPT)? *Reference: Art. 26(1) & 26(8)* - TLPT applies to certain non-microenterprise financial entities that are not covered by Art. 16(1) and are identified by the competent authority. - The criteria used for identifying financial entities required to perform TLPT are further specified by TLPT RTS adopted as delegated acts (e.g., Delegated Reg. (EU) 2025/1190). - If yes: plan for TLPT at least every 3 years and align scope to critical or important functions (and live production systems). - **YES** DORA Applies (Full Framework + TLPT) - **NO** DORA Applies (Full ICT Risk Framework) ### ICT TRACK: Have you been designated as a critical ICT third-party service provider (CTPP)? *Reference: Art. 31* - Designation is under Art. 31 and criteria are further specified by delegated acts (e.g., Delegated Reg. (EU) 2024/1502). - CTPP designation does not apply to certain categories (Art. 31(8)), including: financial entities providing ICT services to other financial entities; ICT third-party service providers subject to oversight frameworks supporting tasks referred to in TFEU Art. 127(2); ICT intra-group service providers; and ICT providers serving only one Member State to financial entities only active in that Member State. - The ESAs establish, publish and update yearly the Union list of critical ICT third-party service providers (Art. 31(9)). - If yes: DORA oversight framework applies; oversight fees may apply (Chapter V, Section II; Delegated Reg. (EU) 2024/1505). - If no/unsure: DORA still affects you through contractual requirements imposed on financial entities (Art. 30) and you may be included in customers' TLPT scope (Arts. 26-27). - **YES** CTPP Oversight Applies - **NO** Not Designated as CTPP ## Reference Information ### Entities In Scope (Overview) - Financial entities (Art. 2(1)(a)-(t)) include: banks, investment firms, (e-)money/payment institutions and AISPs, insurers and intermediaries, fund managers/UCITS managers, market infrastructures (CCPs/CSDs/trading venues/TRs), data reporting service providers, CRAs, critical benchmark administrators, crowdfunding providers, securitisation repositories, crypto-asset service providers and issuers of asset-referenced tokens. - ICT third-party service providers are also in scope as a category (Art. 2(1)(u)). - 'Financial entities' is a defined umbrella term for Art. 2(1)(a)-(t) only (Art. 2(2)). ### Key Exclusions - Art. 2(3) exclusions include (among others): certain AIFMs under AIFMD Art. 3(2); small insurers under Solvency II Art. 4; IORPs with pension schemes totalling <= 15 members; persons exempt under MiFID II Arts. 2 and 3; insurance/reinsurance/ancillary intermediaries that are microenterprises or SMEs; post office giro institutions (CRD Art. 2(5)(3)). - Art. 2(4) optional exclusion: Member States may exclude certain entities listed in CRD Art. 2(5)(4)-(23) located in their territory (and must inform the Commission). ### Proportionality Principle - Implement Chapter II (ICT risk management) in accordance with proportionality (Art. 4(1)). - Apply proportionality to Chapters III-V, Section I (incident reporting, testing, third-party risk) as specifically provided (Art. 4(2)). - Competent authorities consider proportionality when reviewing framework reports (Art. 4(3)). ### Penalties & Publication - Member States must lay down rules establishing administrative penalties and remedial measures for breaches; competent authorities must have supervisory, investigatory and sanctioning powers (Art. 50). - Member States notify the laws, regulations and administrative provisions implementing the administrative penalties chapter (including any relevant criminal law provisions) to the Commission and the ESAs by 17 January 2025, and notify amendments without undue delay (Art. 53). - Competent authorities publish final administrative penalty decisions on their official websites, including breach details and responsible persons, subject to proportionality and other safeguards (Art. 54). - Publication may be deferred, anonymised, or withheld in specific cases (Art. 54(3)). ### Governance & Management Body - Have an internal governance and control framework for effective and prudent ICT risk management (Art. 5(1)). - Management body defines, approves, oversees, and is responsible for ICT risk framework implementation (Art. 5(2)). - Management body responsibilities include: risk ownership; data availability/authenticity/integrity/confidentiality policies; roles/responsibilities; approving resilience strategy and risk tolerance; approving business continuity and response/recovery; approving ICT audit plans; budgeting for resilience and training; and approving ICT third-party arrangements policy (Art. 5(2)). ### ICT Risk Management (Core Components) - Other than microenterprises: assign ICT risk management and oversight responsibility to a control function with an appropriate level of independence; ensure segregation between ICT risk management, control and internal audit functions (Art. 6(4)). - Document and maintain an ICT risk management framework (Art. 6), including a digital operational resilience strategy (Art. 6(8)). - Maintain updated ICT systems, protocols and tools (Art. 7). - Security, detection, response and recovery controls (Arts. 8-12) including business continuity and response/recovery plans (Art. 11). - Training and awareness programmes as part of staff training (Art. 13(6)). - Communication strategy and client communications when disclosure is required (Art. 14; see also Art. 19(3)). - Regular review and audit expectations for non-microenterprises (Art. 6(5)-(7)). - You may outsource verification of compliance with ICT risk management requirements to intra-group or external undertakings, but remain fully responsible (Art. 6(10)). ### Simplified ICT Risk Management Framework - If Art. 16 applies, Articles 5-15 do not apply (Art. 16(1)). - Minimum framework requirements include: sound documented ICT risk framework; continuous monitoring; resilient and updated ICT systems; prompt identification and handling of anomalies/incidents; identifying key ICT third-party dependencies (Art. 16(1)). - Maintain continuity of critical or important functions via business continuity and response/recovery measures (including back-up and restoration), and test plans and controls regularly; implement operational lessons and training as appropriate (Art. 16(1)). - Document and periodically review the Art. 16 framework; submit a review report to the competent authority upon request (Art. 16(2)). - TLPT does not apply to Art. 16(1) entities (Art. 26(1)). ### Incident Management & Reporting - Establish an ICT incident management process to detect, manage and notify ICT-related incidents; record all ICT incidents and significant cyber threats (Art. 17). - Classify ICT incidents and determine impact using Art. 18 criteria (clients/transactions/reputation; duration; geographic spread; data losses; criticality; economic impact). - Report major ICT-related incidents to the relevant competent authority, using RTS time limits and ITS templates; initial notification + intermediate + final report (Arts. 19-20). - RTS time limits (Delegated Reg. (EU) 2025/301) include: initial notification within 4 hours of classifying as major (and no later than 24 hours from awareness), intermediate report within 72 hours of the initial notification, and final report within 1 month of the (latest) intermediate report; if unable to meet a time limit, inform the competent authority and explain the delay; limited weekend/bank-holiday flexibility may apply (2025/301, Art. 5). - Major incident classification criteria, materiality thresholds, and report details are further specified by RTS (Delegated Reg. (EU) 2024/1772), while standard forms/templates and procedures are set by ITS (Implementing Reg. (EU) 2025/302). - If technical impossibility prevents submission using the template, notify the competent authority via alternative means (Art. 19(1)). - Reporting can be outsourced to a third-party service provider, but the financial entity remains fully responsible (Art. 19(5)). - Voluntary notification of significant cyber threats (Art. 19(2)). - Client notification duties for major incidents impacting clients' financial interests (Art. 19(3)). - Payment-related incidents: Chapter III also applies to operational or security payment-related incidents for credit institutions, payment institutions, AISPs and EMIs (Art. 23). - Member States may additionally require some or all financial entities to also provide the incident reports to CSIRTs under NIS2 (Art. 19(1)). ### Incident Reporting Routing (Who to Notify) - Report major ICT-related incidents to the relevant competent authority (Art. 19(1); see Art. 46). - If supervised by more than one national competent authority, the Member State designates a single relevant competent authority for Art. 19 reporting (Art. 19(1)). - Significant credit institutions report to the relevant national competent authority, which immediately transmits the report to the ECB (Art. 19(1)). - Member States may additionally require that reports are also provided to CSIRTs under NIS2 (Art. 19(1)). ### Supervisory Feedback & Sector Learning - Competent authorities acknowledge receipt of the notifications/reports and may provide timely, relevant and proportionate feedback or high-level guidance (Art. 22(1)). - Competent authorities may make available anonymised information and intelligence on similar threats and discuss remedies to minimise adverse impact across the financial sector (Art. 22(1)). - ESAs report yearly on major incidents on an anonymised and aggregated basis, and may issue warnings and produce high-level statistics (Art. 22(2)). ### Digital Operational Resilience Testing - Financial entities other than microenterprises must establish, maintain and review a comprehensive digital operational resilience testing programme (Art. 24(1)). - Testing methods include vulnerability assessments/scans, penetration testing, end-to-end testing and more (Art. 25(1)). - Microenterprises perform the tests using a risk-based approach and strategic planning (Art. 25(3)). - TLPT applies only to certain non-microenterprise financial entities that are not covered by Art. 16(1) and are identified by competent authorities; at least every 3 years (Art. 26(1) & 26(8)). - Use testers meeting DORA requirements and manage TLPT risks and results, including rules for internal testers (Art. 27). ### ICT Third-Party Risk & Contracts - Manage ICT third-party risk as part of ICT risk (Art. 28(1)) and remain fully responsible for compliance (Art. 28(1)(a)). - Adopt a strategy on ICT third-party risk (financial entities other than microenterprises and those in Art. 16(1); Art. 28(2)). - Maintain a register of information for all ICT contractual arrangements; distinguish those supporting critical or important functions; report at least yearly; and provide the register upon request (Art. 28(3)). - Pre-contract assessments include critical/important function determination, risk assessment (including concentration risk), due diligence, and conflicts of interest (Art. 28(4); see also Art. 29). - Baseline contract elements include: service description, subcontracting permissions/conditions, locations and data processing/storage, data protection safeguards, data access/recovery/return, and service levels (Art. 30(2)). - For ICT services supporting critical or important functions, contracts must also include: business contingency + security requirements, TLPT cooperation, ongoing monitoring and audit/access/inspection rights, and exit strategies with an adequate transition period (Art. 30(3)). - Microenterprise derogation: audit/access/inspection rights can be delegated to an independent third party appointed by the ICT provider, under conditions (Art. 30(3)). - When negotiating contractual arrangements, consider standard contractual clauses developed by public authorities for specific services (Art. 30(4)). - If using a third-country ICT provider designated as critical, financial entities may only use its services if it establishes an EU subsidiary within 12 months of designation (Art. 31(12)). - Practical note: intra-group ICT service provision is not automatically less risky than external provision; reflect group control in the overall risk assessment (Recital 31). ### ICT Provider Readiness (Practical) - Expect customers to require written ICT contracts with clear allocation of rights/obligations and service level agreements (Art. 30(1)-(2)). - Prepare for incident assistance obligations tied to the ICT service provided (Art. 30(2)(f)). - Prepare to cooperate with customers' competent authorities and resolution authorities (Art. 30(2)(g)). - For services supporting critical or important functions, expect audit/access/inspection rights, security and contingency requirements, TLPT cooperation, and exit/transition obligations (Art. 30(3)). - Subcontracting: expect customer assessments and controls; RTS further specify elements to assess when subcontracting ICT services supporting critical/important functions (Art. 30(5)). - Customers may consider using standard contractual clauses developed by public authorities for specific services (Art. 30(4)). ### Register of Information (Operational Focus) - Maintain and update the register of information for ICT contracts at entity and (where relevant) consolidated levels (Art. 28(3)). - Be ready to provide the full register or specified sections to the competent authority upon request (Art. 28(3)). - Inform the competent authority about planned ICT contracts supporting critical/important functions, and when a function becomes critical/important (Art. 28(3)). - Use standard templates established by ITS for the register of information (Implementing Regulation (EU) 2024/2956). ### CTPP Oversight (High-Level) - Critical ICT third-party service providers are designated under DORA (Art. 31) and are overseen by a Lead Overseer (Chapter V, Section II). - Designation criteria are further specified by delegated acts (e.g., Delegated Regulation (EU) 2024/1502); oversight fees are set by delegated acts (e.g., Delegated Regulation (EU) 2024/1505). - Oversight Forum supports the Joint Committee and Lead Overseer on ICT third-party risk (Art. 32). - Lead Overseer is the primary point of contact for oversight matters (Art. 33). - Joint Oversight Network coordinates Lead Overseers (Art. 34). - ESAs issue guidelines on cooperation and information exchange for the oversight framework (Art. 32(7)). - This oversight framework is without prejudice to NIS2 and other Union oversight rules applicable to providers of cloud computing services (Art. 32(8)). ### CTPP Oversight: Follow-Up & Enforcement - Lead Overseer powers include requesting information, conducting investigations/inspections, and issuing recommendations (Art. 35(1)). - CTPPs must respond to recommendations within 60 days (intend to follow, or explain why not); the Lead Overseer may publicly disclose certain non-compliance (Art. 42(1)-(2)). - Periodic penalty payments: after at least 30 days of non-compliance with required measures, the Lead Overseer can impose daily penalty payments (up to 1% average daily worldwide turnover) for up to 6 months; disclosed publicly in principle (Art. 35(6)-(10)). - As a last resort, competent authorities may require financial entities to suspend or terminate the use of a service provided by a CTPP until risks are addressed (Art. 42(6)). - Third-country CTPP: financial entities may only use a third-country ICT provider designated as critical if it has established an EU subsidiary within 12 months of designation (Art. 31(12)). ### Critical or Important Function - A 'critical or important function' is a function whose disruption would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities. - It also includes functions where discontinued, defective or failed performance would materially impair continuing compliance with authorisation conditions or other financial services law obligations (Art. 3(22)). ### Microenterprises (Practical Notes) - Definition: a financial entity (excluding trading venues, CCPs, TRs and CSDs) with <10 persons and <= EUR 2M turnover and/or balance sheet total (Art. 3(60)). - Some requirements apply only to financial entities other than microenterprises (e.g., crisis management function: Art. 11(7); continuous monitoring of technological developments: Art. 13(7)). - Redundant ICT capacities: non-microenterprises must maintain; microenterprises assess the need based on risk profile (Art. 12(4)). - Testing: microenterprises perform Art. 25 tests using a risk-based approach and strategic planning; TLPT does not apply (Art. 25(3); Art. 26(1)). - Contracts: for critical/important functions, microenterprises may agree to delegate audit/access/inspection rights to an independent third party appointed by the ICT provider (Art. 30(3) derogation). ### TLPT (Threat-Led Penetration Testing) - Applies to certain non-microenterprise financial entities not covered by Art. 16(1) that are identified by the competent authority; at least every 3 years (Art. 26(1) & 26(8)). - Scope: cover several or all critical or important functions and be performed on live production systems; include outsourced/contracted ICT services where relevant (Art. 26(2)). - If ICT providers are in scope, the financial entity must ensure their participation and remains fully responsible for compliance (Art. 26(3)). - Pooled testing is possible under written agreement in specific circumstances (Art. 26(4)). - Internal vs external testers: if a financial entity uses internal testers, it must contract external testers every three tests; significant credit institutions may only use external testers (Art. 26(8)). - Provide summary findings and remediation plans to the TLPT authority and obtain an attestation to support mutual recognition; notify the relevant competent authority (Art. 26(6)-(7)). - Member States may designate a single public authority for TLPT matters; otherwise a competent authority may delegate some or all TLPT-related tasks (Art. 26(9)-(10)). - Detailed TLPT RTS are developed with the ECB in accordance with the TIBER-EU framework (Art. 26(11)) and adopted as delegated acts (e.g., Delegated Reg. (EU) 2025/1190). ### Key Level 2 Acts to Implement - Incident classification & reporting: Delegated Reg. (EU) 2024/1772; Delegated Reg. (EU) 2025/301; Implementing Reg. (EU) 2025/302. - ICT risk management: Delegated Reg. (EU) 2024/1774. - ICT third-party contractual arrangements: Delegated Reg. (EU) 2024/1773. - Register of information templates: Implementing Reg. (EU) 2024/2956. - CTPP designation criteria and oversight fees: Delegated Reg. (EU) 2024/1502 and 2024/1505. - Subcontracting assessments: Delegated Reg. (EU) 2025/532. ### Voluntary Information Sharing - Financial entities may exchange cyber threat information and intelligence to enhance resilience, within trusted communities, under arrangements that protect sensitive information and respect confidentiality, GDPR and competition guidance (Art. 45(1)). - Information-sharing arrangements should define participation conditions and operational elements; they can involve public authorities and ICT third-party providers where appropriate (Art. 45(2)). - Notify the competent authority of participation or cessation once it takes effect (Art. 45(3)). ## Possible Outcomes ### [RESULT] DORA Applies (Simplified ICT Risk Framework) Art. 16 applies instead of Arts. 5-15 - Apply DORA Chapter II via Art. 16 minimum framework requirements (sound documented ICT risk framework; monitoring; continuity; testing; third-party dependencies). - Other DORA chapters still apply where relevant (incident reporting, testing, third-party risk) subject to proportionality (Art. 4). TLPT does not apply to Art. 16(1) entities (Art. 26(1)). ### [RESULT] DORA Applies (Microenterprise) Tailored obligations across DORA - DORA applies, but several requirements are scaled for microenterprises (see microenterprise-specific provisions across DORA). - Use proportionality (Art. 4) to implement incident reporting, testing, and third-party risk in a practical, evidence-ready way. ### [RESULT] DORA Applies (Full Framework + TLPT) Advanced testing required - Implement the full ICT risk management framework (Arts. 5-15) and related obligations across Chapters III-V as applicable. - Perform TLPT at least every 3 years on live production systems supporting critical or important functions, as validated by competent authorities (Art. 26). ### [RESULT] DORA Applies (Full ICT Risk Framework) Full framework; TLPT not required - Implement the full ICT risk management framework (Arts. 5-15) and related obligations across Chapters III-V as applicable. - Use proportionality to tailor implementation (Art. 4), and run the required testing programme (Arts. 24-25) even if TLPT is not required (Art. 26). ### [RESULT] CTPP Oversight Applies Critical ICT third-party provider under DORA - Expect oversight by a Lead Overseer and supervisory engagement (Chapter V, Section II). - Financial entities remain responsible for their own compliance, but oversight targets the critical provider's services supporting financial entities' critical or important functions. ### [RESULT] Not Designated as CTPP DORA primarily impacts you via customer contractual requirements - Expect contractual terms under Art. 30, including security, audit/access, data return/exit, and subcontracting controls where applicable. - Expect to support customers' resilience testing where relevant, including TLPT cooperation where required (Arts. 26-27 and Art. 30(3)). ### [RESULT] Out of Scope DORA does not directly apply - You are not an entity listed in Art. 2(1), or an Art. 2(3) exclusion applies. - Even if not directly in scope, you may be impacted via contractual demands from DORA-regulated customers. ### [RESULT] Out of Scope (Member State Exclusion) Excluded under Art. 2(4) option - Your Member State has excluded certain entities from DORA under the optional exclusion in Art. 2(4). - Confirm the national scope and any subsequent changes to the exclusion as published by your Member State. ## DORA Timeline | Date | Event | Reference | | --- | --- | --- | | 2022-12-14 | DORA adopted | Reg. (EU) 2022/2554 | | 2022-12-27 | DORA published in Official Journal (OJ L 333) | Reg. (EU) 2022/2554 | | 2023-01-16 | DORA enters into force (20 days after publication) | Reg. (EU) 2022/2554 | | 2024-05-30 | CTPP designation criteria and oversight fees acts published in OJ | Reg. (EU) 2024/1502 and 2024/1505 | | 2024-06-25 | RTS on incident classification, contracts, and ICT risk management published in OJ | Reg. (EU) 2024/1772, 2024/1773, 2024/1774 | | 2024-12-02 | Register of information ITS (templates) published in OJ | Reg. (EU) 2024/2956 | | 2025-01-17 | DORA applies | Reg. (EU) 2022/2554 | | 2025-02-20 | Incident reporting RTS and ITS published in OJ | Reg. (EU) 2025/301 and 2025/302 | | 2025-06-18 | TLPT RTS published in OJ | Reg. (EU) 2025/1190 | | 2025-07-02 | Subcontracting RTS published in OJ | Reg. (EU) 2025/532 | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2022-12-14 | DORA adopted | Legislative History | Reg. (EU) 2022/2554 (of 14 December 2022) | | 2022-12-27 | DORA published in Official Journal | Official Publication | OJ L 333, 27.12.2022 | | 2022-12-27 | Alignment Directive (EU) 2022/2556 published | Official Publication | | | 2023-01-16 | DORA enters into force | Official Publication | Art. 64 | | 2023-06-19 | ESAs first batch public consultation opens | ESAs Mandates & Deliverables | | | 2023-07-17 | Commission PSD2 review report deadline (cyber resilience of payment systems) | Commission Mandates & Reviews | Art. 58(2) | | 2023-09-11 | ESAs first batch public consultation closes | ESAs Mandates & Deliverables | | | 2023-12-08 | ESAs second batch public consultation opens | ESAs Mandates & Deliverables | | | 2024-01-17 | Deadline: ESAs submit first wave draft RTS/ITS to the Commission | ESAs Mandates & Deliverables | Arts. 15, 16(3), 18(4), 28(9)-(10) | | 2024-03-04 | ESAs second batch public consultation closes | ESAs Mandates & Deliverables | | | 2024-05-30 | Delegated Regs. 2024/1502 and 2024/1505 published in OJ | Delegated & Implementing Acts (OJ) | OJ L, 2024/1502 and 2024/1505, 30.5.2024 | | 2024-06-25 | Delegated Regs. 2024/1772, 2024/1773, 2024/1774 published in OJ | Delegated & Implementing Acts (OJ) | OJ L, 2024/1772, 2024/1773, 2024/1774, 25.6.2024 | | 2024-07-17 | Deadline: ESAs submit draft RTS/ITS for incident reporting content and templates | ESAs Mandates & Deliverables | Art. 20 | | 2024-07-17 | Deadline: ESAs submit draft RTS for TLPT (TIBER-EU framework) | ESAs Mandates & Deliverables | Art. 26(11) | | 2024-07-17 | Deadline: ESAs develop guidelines on annual costs and losses from major incidents | ESAs Mandates & Deliverables | Art. 11(11) | | 2024-07-17 | Deadline: ESAs issue guidelines on oversight cooperation and information exchange | ESAs Mandates & Deliverables | Art. 32(7) | | 2024-07-17 | Deadline: ESAs submit draft RTS on subcontracting assessments | ESAs Mandates & Deliverables | Art. 30(5) | | 2024-07-17 | Deadline: ESAs submit draft RTS enabling the conduct of oversight activities | ESAs Mandates & Deliverables | Art. 41(2) | | 2024-07-17 | ESAs publish second batch of policy products (incl. TLPT RTS) | ESAs Mandates & Deliverables | | | 2024-07-17 | Deadline: Commission delegated act on further criteria for critical ICT third-party designation | Commission Mandates & Reviews | Art. 31(6) | | 2024-07-17 | Deadline: Commission delegated act on oversight fees | Commission Mandates & Reviews | Art. 43(2) | | 2024-11-29 | Oversight Forum mandate (JC_24_93) | CTPP Oversight | | | 2024-12-02 | Implementing Reg. 2024/2956 published in OJ (register templates) | Register of Information | Reg. (EU) 2024/2956 | | 2025-01-16 | Lead Overseer applies sub-criterion for CTPP designation (sub-criterion 1.4) | CTPP Oversight | Delegated Reg. (EU) 2024/1502 Art. 7 | | 2025-01-17 | DORA applies | Applicability | Art. 64 | | 2025-01-17 | EU Hub feasibility report due | ESAs Mandates & Deliverables | Art. 21(3) | | 2025-01-17 | ESAs publish feasibility report on EU Hub centralisation (JC 2024 108) | ESAs Mandates & Deliverables | | | 2025-01-17 | Member States notify penalty and criminal-law measures | National Obligations | Art. 53 | | 2025-01-17 | Application date - Guidelines on oversight cooperation and information exchange | Guidelines (Level 3) | | | 2025-02-20 | Delegated Reg. 2025/301 published in OJ (incident reporting RTS) | Delegated & Implementing Acts (OJ) | OJ L, 2025/301, 20.2.2025 | | 2025-02-20 | Implementing Regulation 2025/302 - incident reporting templates (ITS) | Delegated & Implementing Acts (OJ) | OJ L, 2025/302, 20.2.2025 | | 2025-03-06 | Corrigendum (01) to Delegated Reg. 2024/1774 | Corrigendum | | | 2025-05-15 | Corrigendum (02) to Delegated Reg. 2024/1774 | Corrigendum | | | 2025-05-19 | Application date - Guidelines on costs/losses estimation | Guidelines (Level 3) | | | 2025-06-18 | Delegated Reg. 2025/1190 published in OJ (TLPT RTS) | Delegated & Implementing Acts (OJ) | OJ L, 2025/1190, 18.6.2025 | | 2025-07-02 | Delegated Reg. 2025/532 published in OJ (subcontracting assessments) | Delegated & Implementing Acts (OJ) | Reg. (EU) 2025/532 | | 2025-09-11 | Corrigendum to Implementing Reg. 2025/302 (incident templates) | Corrigendum | | | 2025-09-12 | Corrigendum to Delegated Reg. 2025/301 (non-EN) | Corrigendum | | | 2025-09-19 | Corrigendum to Implementing Reg. 2024/2956 (register templates) | Corrigendum | | | 2025-11-18 | First list of designated CTPPs published | CTPP Oversight | | | 2026-01-17 | Commission review on auditors and audit firms due | Commission Mandates & Reviews | Art. 58(3) | | 2028-01-17 | Commission review of DORA due | Commission Mandates & Reviews | Art. 58(1) | **Event details:** - **2022-12-14 - DORA adopted**: Regulation (EU) 2022/2554 on digital operational resilience for the financial sector is adopted by the European Parliament and the Council (date of the act: 14 December 2022). - **2022-12-27 - DORA published in Official Journal**: Regulation (EU) 2022/2554 is published in the Official Journal of the European Union (OJ L 333, 27.12.2022). - **2022-12-27 - Alignment Directive (EU) 2022/2556 published**: Directive (EU) 2022/2556 is published, aligning sectoral directives with DORA; Member States must transpose it by 17 January 2025. - **2023-01-16 - DORA enters into force**: DORA enters into force on the twentieth day following its publication in the Official Journal (27 December 2022 -> 16 January 2023). - **2023-06-19 - ESAs first batch public consultation opens**: First batch of DORA policy products consultation window opens. - **2023-07-17 - Commission PSD2 review report deadline (cyber resilience of payment systems)**: Within the PSD2 review context, the Commission must submit a report to the European Parliament and Council no later than 17 July 2023 assessing the need for increased cyber resilience of payment systems and payment-processing activities. - **2023-09-11 - ESAs first batch public consultation closes**: Closure of first batch consultation window. - **2023-12-08 - ESAs second batch public consultation opens**: Second batch of DORA policy mandates consultation opens. - **2024-01-17 - Deadline: ESAs submit first wave draft RTS/ITS to the Commission**: Deadline for ESAs (through the Joint Committee) to submit several draft RTS/ITS to the Commission, including RTS on ICT risk management, RTS on the simplified ICT risk management framework, RTS on incident classification (materiality thresholds), and draft ITS/RTS related to the register of information and ICT third-party risk policy. - **2024-03-04 - ESAs second batch public consultation closes**: Closure of second batch consultation window. - **2024-05-30 - Delegated Regs. 2024/1502 and 2024/1505 published in OJ**: Delegated Regulations (EU) 2024/1502 (designation criteria for critical ICT third-party service providers; adopted 22 February 2024) and 2024/1505 (oversight fees; adopted 22 February 2024) are published in the Official Journal. - **2024-06-25 - Delegated Regs. 2024/1772, 2024/1773, 2024/1774 published in OJ**: Delegated Regulations (EU) 2024/1772 (incident classification), 2024/1773 (policy content for ICT third-party contractual arrangements supporting critical/important functions) and 2024/1774 (ICT risk management tools/methods and simplified framework) are published in the Official Journal (all adopted 13 March 2024). - **2024-07-17 - Deadline: ESAs submit draft RTS/ITS for incident reporting content and templates**: Deadline for ESAs (through the Joint Committee, in consultation with ENISA and the ECB) to submit to the Commission draft RTS on incident-report content and time limits, and draft ITS on standard forms/templates/procedures for reporting major ICT-related incidents and notifying significant cyber threats. - **2024-07-17 - Deadline: ESAs submit draft RTS for TLPT (TIBER-EU framework)**: Deadline for ESAs (in agreement with the ECB) to submit to the Commission draft RTS specifying criteria and detailed requirements for threat-led penetration testing (TLPT), including methodology phases, internal testers, and cooperation/mutual recognition aspects. - **2024-07-17 - Deadline: ESAs develop guidelines on annual costs and losses from major incidents**: Deadline for ESAs (through the Joint Committee) to develop common guidelines on the estimation of aggregated annual costs and losses caused by major ICT-related incidents. - **2024-07-17 - Deadline: ESAs issue guidelines on oversight cooperation and information exchange**: Deadline for ESAs to issue guidelines on cooperation between ESAs and competent authorities under the CTPP oversight framework, including task allocation/execution procedures and information-exchange details needed for follow-up of Lead Overseer recommendations. - **2024-07-17 - Deadline: ESAs submit draft RTS on subcontracting assessments**: Deadline for ESAs (through the Joint Committee) to submit to the Commission draft RTS specifying further which elements a financial entity needs to determine and assess when subcontracting ICT services supporting critical or important functions. - **2024-07-17 - Deadline: ESAs submit draft RTS enabling the conduct of oversight activities**: Deadline for ESAs (through the Joint Committee) to submit to the Commission draft RTS specifying harmonised conditions enabling the conduct of oversight activities for critical ICT third-party service providers (including information requests, reporting, and Joint Examination Team arrangements). - **2024-07-17 - ESAs publish second batch of policy products (incl. TLPT RTS)**: ESAs publish the second batch of DORA policy products, including the TLPT RTS and the draft RTS/ITS for incident reporting. - **2024-07-17 - Deadline: Commission delegated act on further criteria for critical ICT third-party designation**: Deadline for the Commission to adopt a delegated act supplementing DORA by specifying further the criteria for the designation of ICT third-party service providers as critical for financial entities (implemented via Delegated Regulation (EU) 2024/1502 of 22 February 2024; OJ publication 30 May 2024). - **2024-07-17 - Deadline: Commission delegated act on oversight fees**: Deadline for the Commission to adopt a delegated act determining the amount of the oversight fees to be paid by critical ICT third-party service providers and the way those fees are to be paid (implemented via Delegated Regulation (EU) 2024/1505 of 22 February 2024; OJ publication 30 May 2024). - **2024-11-29 - Oversight Forum mandate (JC_24_93)**: Mandate of the Oversight Forum as a Joint Committee Sub-Committee of the European Supervisory Authorities (JC 2024 93, dated 29 November 2024). - **2024-12-02 - Implementing Reg. 2024/2956 published in OJ (register templates)**: Implementing Regulation (EU) 2024/2956 is published, laying down implementing technical standards establishing standard templates for the register of information. - **2025-01-16 - Lead Overseer applies sub-criterion for CTPP designation (sub-criterion 1.4)**: Under Delegated Regulation (EU) 2024/1502, the Lead Overseer applies sub-criterion 1.4 for the criticality assessment of ICT third-party service providers as of 16 January 2025. - **2025-01-17 - DORA applies**: DORA applies from 17 January 2025. - **2025-01-17 - EU Hub feasibility report due**: ESAs joint report assessing the feasibility of further centralisation of incident reporting through a single EU Hub is due to the European Parliament, Council and Commission by 17 January 2025. - **2025-01-17 - ESAs publish feasibility report on EU Hub centralisation (JC 2024 108)**: ESAs publish their joint report on the feasibility of further centralising reporting of major ICT-related incidents through a single EU Hub (DORA Art. 21). - **2025-01-17 - Member States notify penalty and criminal-law measures**: Member States must notify the Commission, ESMA, EBA and EIOPA of laws/regulations implementing the chapter on administrative penalties (and any relevant criminal law provisions) by 17 January 2025. - **2025-01-17 - Application date - Guidelines on oversight cooperation and information exchange**: Joint Guidelines application date for oversight cooperation and information exchange. - **2025-02-20 - Delegated Reg. 2025/301 published in OJ (incident reporting RTS)**: Delegated Regulation (EU) 2025/301 (adopted 23 October 2024) specifies the content and time limits for the initial notification, and intermediate and final reports on, major ICT-related incidents, and the content of voluntary notifications of significant cyber threats. - **2025-02-20 - Implementing Regulation 2025/302 - incident reporting templates (ITS)**: Implementing Regulation (EU) 2025/302 (adopted 23 October 2024) lays down implementing technical standards establishing the standard forms, templates and procedures for reporting major ICT-related incidents and notifying significant cyber threats, including use under transitional arrangements pending any EU Hub implementation (OJ publication 20 February 2025; earlier drafts sometimes used month-level dating). - **2025-03-06 - Corrigendum (01) to Delegated Reg. 2024/1774**: First corrigendum to Delegated Regulation (EU) 2024/1774 (ICT risk management) published. - **2025-05-15 - Corrigendum (02) to Delegated Reg. 2024/1774**: Second corrigendum to Delegated Regulation (EU) 2024/1774 (ICT risk management) published. - **2025-05-19 - Application date - Guidelines on costs/losses estimation**: Application date for the costs/losses Guidelines. - **2025-06-18 - Delegated Reg. 2025/1190 published in OJ (TLPT RTS)**: Delegated Regulation (EU) 2025/1190 (adopted 13 February 2025) specifies RTS on criteria and detailed requirements for threat-led penetration testing (TLPT). - **2025-07-02 - Delegated Reg. 2025/532 published in OJ (subcontracting assessments)**: Delegated Regulation (EU) 2025/532 is published, specifying elements to determine and assess when subcontracting ICT services supporting critical or important functions. - **2025-09-11 - Corrigendum to Implementing Reg. 2025/302 (incident templates)**: Corrigendum to Implementing Regulation (EU) 2025/302 published. - **2025-09-12 - Corrigendum to Delegated Reg. 2025/301 (non-EN)**: Corrigendum to Delegated Regulation (EU) 2025/301 published; OJ note indicates it does not concern the English version. - **2025-09-19 - Corrigendum to Implementing Reg. 2024/2956 (register templates)**: Corrigendum to Implementing Regulation (EU) 2024/2956 published. - **2025-11-18 - First list of designated CTPPs published**: The European Supervisory Authorities publish the first list of designated critical ICT third-party service providers (CTPPs). - **2026-01-17 - Commission review on auditors and audit firms due**: Commission must review and submit a report (and, where appropriate, a legislative proposal) on strengthened digital operational resilience requirements for statutory auditors and audit firms by 17 January 2026. - **2028-01-17 - Commission review of DORA due**: Commission must review DORA and submit a report (and, where appropriate, a legislative proposal) by 17 January 2028. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu-dora-compliance-decision-map --- --- title: "EU CRA Conformity Route Map: Scope, Classification, CE Path, and Reporting" canonical_url: "https://www.sorena.io/artifacts/eu-cra-conformity-route-map" source_url: "https://www.sorena.io/artifacts/eu-cra-conformity-route-map" author: "Sorena AI" description: "Advanced EU CRA Conformity Route Map for Regulation (EU) 2024/2847 implementation: scope testing for products with digital elements." keywords: - "EU CRA Conformity Route Map compliance" - "EU CRA Conformity Route Map guide" - "EU CRA Conformity Route Map checklist" - "EU CRA Conformity Route Map requirements" - "EU CRA Conformity Route Map template" - "Cyber Resilience Act compliance" - "Regulation EU 2024 2847 implementation" - "products with digital elements scope" - "important products Annex III" - "critical products Annex IV" - "CRA conformity assessment modules" - "CRA CE marking technical documentation" - "CRA Article 14 reporting" - "EU CRA Conformity Route Map" - "Cyber Resilience Act" - "Regulation (EU) 2024/2847" - "CRA conformity assessment" - "CE marking" - "Article 14 reporting" - "products with digital elements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CRA Conformity Route Map: Scope, Classification, CE Path, and Reporting Advanced EU CRA Conformity Route Map for Regulation (EU) 2024/2847 implementation: scope testing for products with digital elements. ![EU CRA Conformity Route Map by Sorena AI](https://cdn.sorena.io/cheatsheets/sorena-ai-cra-cheatsheet-small.jpg) *CRA* *Free Resource* ## EU CRA Conformity Route Map This EU CRA Conformity Route Map helps teams turn legal interpretation into implementation decisions. Confirm scope for products with digital elements, classify important or critical categories, and choose a conformity assessment path with clear evidence outputs. Grounded in Regulation (EU) 2024/2847, Commission CRA FAQs (v1.2), and CRA standardisation implementation materials. Use this as an execution control for product, legal, security, and compliance teams. [Create my custom view](/solutions/assessment.md) ## What you can decide faster - **Scope and exclusions**: Determine whether the product is in CRA scope and whether any exclusions or overlapping sectoral legislation alter obligations. - **Category and route**: Classify default, important, or critical product status and select the right conformity assessment route and assurance level. - **Reporting and evidence**: Operationalise vulnerability handling, Article 14 reporting, and CE technical documentation with accountable owners. By Sorena AI | Updated Mar 2026 | No sign-up required **Key highlights:** Scope before route | Category drives evidence | CE-ready workflow ## Primary sources - [Regulation (EU) 2024/2847 (Cyber Resilience Act)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Primary legal text defining scope, obligations, conformity framework, and enforcement provisions. - [European Commission CRA policy page](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act?ref=sorena.io) - Implementation entry point with CRA timing, policy context, and official implementation links. - [European Commission FAQs on the CRA (v1.2)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Practical clarifications on scope, role interpretation, and interplay with other EU legislation. - [Commission Implementing Decision C(2025) 618 (CRA standardisation request)](https://ec.europa.eu/newsroom/dae/redirection/document/113276?ref=sorena.io) - Defines standardisation work program and delivery milestones supporting CRA conformity evidence. - [ENISA Coordinated Vulnerability Disclosure guidance](https://www.enisa.europa.eu/topics/vulnerability-disclosure?ref=sorena.io) - Reference guidance for vulnerability handling and disclosure operations relevant to CRA obligations. ## Compliance quick-start *Regulation (EU) 2024/2847* | Time | Step | Detail | | --- | --- | --- | | Scope | Products with digital elements | Confirm whether hardware/software is in scope, then map economic operator role and lifecycle responsibilities. | | Route | Conformity assessment | Select path and evidence model aligned to product category and applicable harmonised standards. | | Art. 14 | Incident and vulnerability reporting | Build 24-hour early warning and follow-on report workflow integrated with vulnerability management. | Use the route map to connect legal obligations, product security engineering, and audit-ready evidence packages. | Value | Metric | | --- | --- | | 10 Dec 2024 | Entered into force | | 11 Sep 2026 | Reporting starts | | 11 Dec 2027 | Main application | | Annex III/IV | Category logic | ## Key dates for EU CRA implementation *CRA Timeline* Track entry-into-force, reporting obligations, and full application milestones so engineering and compliance teams can sequence readiness work with shared deadlines. ## Decide faster what the CRA means for your product and supply chain role *CRA Decision Map* Follow yes/no branching from scope to category and conformity route, then map each outcome to implementation tasks, evidence requirements, and reporting controls. *Go further* ## Turn this route map into a complete CRA execution program Use the EU Cyber Resilience Act deep-dive pages to move from route-map outcomes to requirements, checklists, templates, and implementation governance. - Translate scope and category outcomes into owned implementation workstreams - Build conformity-assessment evidence packs aligned to your product architecture - Operationalise vulnerability handling and Article 14 reporting workflows - Maintain traceability from legal obligations to control tests and assurance evidence - [Open requirements deep dive](/artifacts/eu/cyber-resilience-act/requirements.md): Map CRA obligations to control design, owners, and evidence outputs. - **Download Route Map**: Share category and conformity decision logic across product, legal, and compliance teams. - **Download Timeline**: Share milestone and reporting deadlines across stakeholders. - [Open compliance checklist](/artifacts/eu/cyber-resilience-act/checklist.md): Use an audit-ready checklist with acceptance criteria and evidence expectations. ## Decision Steps ### START: Does your product fall under CRA scope (a 'product with digital elements' on the EU market)? - Covers hardware and software products whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network - Includes software or hardware components being placed on the market separately (Art. 3(1)) - Remote data processing is in scope where it is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of it would prevent the product from performing one of its functions (Art. 3(2)) - Websites that do not support product functionality are out of scope (Recital 12) - Placing on the market means the first making available of a product with digital elements on the Union market (Art. 3(20)). Making available on the market means supplying a product for distribution or use on the Union market as part of a commercial activity, whether paid or free (Art. 3(22)) - Commercial activity might be characterised not only by charging a price, but also by paid support beyond cost recovery, an intention to monetise, requiring personal data processing as a condition of use, or accepting donations exceeding the costs associated with design, development, and provision. Donations exceeding costs can indicate commercial activity (Recital 15) - Donations without an intention of making a profit should not be considered a commercial activity (Recital 15) - If yes, continue. If no, CRA does not apply - Sources: Art. 2(1), Art. 3(1)-(2), Art. 3(20), Art. 3(22), Recital 12, Recital 15 - **NO** Out of CRA Scope - **YES** Is the product excluded from CRA scope? ### STEP 1: Is the product excluded from CRA scope? - If yes: CRA does not apply to that product - Medical devices: Regulations (EU) 2017/745 and 2017/746 - Motor vehicles: Regulation (EU) 2019/2144 - Civil aviation: products certified under Regulation (EU) 2018/1139 - Marine equipment: Directive 2014/90/EU - Spare parts replacing identical components manufactured to the same specifications - Products developed or modified exclusively for national security or defence purposes, or specifically designed to process classified information - Commission may adopt delegated acts for further lex specialis limitations or exclusions where sectoral rules achieve the same or a higher level of protection - Sources: Art. 2(2)-(7) - **YES** Out of CRA Scope - **NO** Is the product category listed in Annex III (important) or Annex IV (critical)? ### STEP 2: Is the product category listed in Annex III (important) or Annex IV (critical)? - If no: the product is still in scope, but treated as a default product - If yes: determine whether it is Annex IV (critical) or Annex III (important) - Annex III lists important products (Class I and Class II). Annex IV lists critical products - Classification is based on the product's core functionality matching a listed category - Integrating an Annex III product does not itself make the host product subject to Class I and Class II conformity assessment procedures (Art. 7(1), second sentence) - Sources: Art. 7(1), Art. 8, Annex III-IV - **YES** If listed: is it in Annex IV (critical product)? - **NO** Default product (not listed in Annex III or IV) ### CRITICAL: Critical product (Annex IV) *Reference: Annex IV* - Core functionality matches an Annex IV category - Next: follow the critical conformity assessment route - Sources: Art. 8(1), Art. 32(4), Annex IV - -> Conformity assessment for critical products ### STEP 2A: If listed: is it in Annex IV (critical product)? - Yes: critical product (Annex IV) - No: important product (Annex III). Next: determine Class II vs Class I - Critical products can be subject to mandatory EU cybersecurity certification when required by a Commission delegated act - Sources: Art. 8(1), Annex IV - **NO** If Annex III: is it Class II? - **YES** Critical product (Annex IV) ### DEFAULT: Default product (not listed in Annex III or IV) *Reference: Art. 32(1)* - Not listed in Annex III or Annex IV - Conformity assessment can use internal control (Module A) - Sources: Art. 32(1)(a) - -> Conformity assessment for default products ### STEP 2B: If Annex III: is it Class II? - Class II includes hypervisors, container runtimes, firewalls, intrusion detection systems (IDS), intrusion prevention systems (IPS), and tamper-resistant microprocessors and microcontrollers - If not Class II, it is Class I - Sources: Annex III - **YES** Important product, Class II (Annex III) - **NO** Important product, Class I (Annex III) ### IMPORTANT II: Important product, Class II (Annex III) *Reference: Annex III* - Core functionality matches an Annex III Class II category - Next: follow the Class II conformity assessment route - Sources: Art. 32(3), Annex III - -> Conformity assessment for Important Class II ### IMPORTANT I: Important product, Class I (Annex III) *Reference: Annex III* - Core functionality matches an Annex III Class I category - Next: check whether standards, common specifications, or certification cover all relevant essential requirements - Sources: Art. 32(2), Annex III - -> For Important Class I: do standards, common specifications, or certification cover all relevant essential requirements? ### CRITICAL CA: Conformity assessment for critical products *Reference: Art. 8(1), Art. 32(3)-(4)* - If certification is mandated by a Commission delegated act and a relevant scheme is available: obtain a European cybersecurity certificate at assurance level at least 'substantial' - Otherwise, use Class II procedures (Art. 32(4)(b)): Module B+C or Module H, or European cybersecurity certification at assurance level at least 'substantial' where available and applicable (Art. 32(3)) - Sources: Art. 8(1), Art. 32(3)-(4) - -> Meet essential cybersecurity requirements (Annex I) ### DEFAULT CA: Conformity assessment for default products *Reference: Art. 32(1)* - Conformity assessment can use internal control (Module A) - You can also choose Module B+C, Module H, or European cybersecurity certification where available and applicable - Sources: Art. 32(1) - -> Meet essential cybersecurity requirements (Annex I) ### CLASS II CA: Conformity assessment for Important Class II *Reference: Art. 32(3)* - Internal control (Module A) is not available for Class II products - Use Module B+C, Module H, or European cybersecurity certification where available and applicable, at assurance level at least 'substantial', for the corresponding requirements - Sources: Art. 32(3) - -> Meet essential cybersecurity requirements (Annex I) ### CLASS I CHECK: For Important Class I: do standards, common specifications, or certification cover all relevant essential requirements? - Yes: internal control (Module A) is available for the covered requirements - No or partial: for the uncovered requirements (this can be split by requirement), use Module B+C or Module H - European cybersecurity certification can also be used where available and applicable, at assurance level at least 'substantial' - Where no harmonised standards exist or the Commission considers them insufficient, common specifications may be adopted; compliance with those confers a presumption of conformity (Art. 27(2), Art. 27(5)) - Sources: Art. 32(2), Art. 27(2), Art. 27(5), Art. 27(9) - **YES** Class I: self-assessment allowed (Module A) - **NO** Class I: third-party assessment required ### MODULE A: Class I: self-assessment allowed (Module A) *Reference: Art. 32(2)* - Internal control (Module A) can be used for the covered essential requirements - Sources: Art. 32(2) - -> Meet essential cybersecurity requirements (Annex I) ### NOTIFIED BODY: Class I: third-party assessment required *Reference: Art. 32(2)* - Use Module B+C or Module H for the uncovered essential requirements - Sources: Art. 32(2)(a)-(b) - -> Meet essential cybersecurity requirements (Annex I) ### STEP 4: Meet essential cybersecurity requirements (Annex I) - Annex I Part I: security requirements for the product itself (security by design and by default) - Annex I Part II: vulnerability handling requirements (CVD policy, SBOM, patches, disclosure) - Requirements are risk-based and applied based on a cybersecurity risk assessment - Sources: Art. 13(2)-(3), Annex I - -> Report actively exploited vulnerabilities and severe incidents ### STEP 5: Report actively exploited vulnerabilities and severe incidents - Reporting obligations start applying from 11 Sep 2026, before the CRA fully applies - Submit reports via the single reporting platform to the CSIRT designated as coordinator. ENISA receives them at the same time - Reporting also applies to in-scope products placed on the market before 11 Dec 2027 - Notifications must be updated without undue delay when significant new information becomes available (Art. 14(2)(b), Art. 14(4)(b)) - Sources: Art. 14, Art. 16, Art. 69(3), Art. 71(2) - -> Penalties & Enforcement ## Reference Information ### Economic Operator Roles - Manufacturer: develops or manufactures (or has it designed, developed, or manufactured) and markets under its name or trademark (Art. 3(13)) - Importer: EU-established actor who places on the market a product that bears the name or trademark of a person established outside the Union (Art. 3(16)) - Distributor: makes a product available on the Union market without affecting its properties (Art. 3(17)) - Authorised representative: acts under a written mandate for specified manufacturer tasks (Art. 3(15)) ### Open-Source Software Steward (Definition) - A legal person other than a manufacturer (Art. 3(14)) - Purpose: provide sustained support for development of specific free and open-source software products intended for commercial activities (Art. 3(14)) - Ensures the viability of those products (Art. 3(14)) ### When Roles Change - Importer or distributor becomes a manufacturer when placing a product under its name or trademark, or carrying out a substantial modification (Art. 21) - Anyone else making a substantial modification and making the product available becomes manufacturer for the affected part, or the whole product if impacted (Art. 22(1)-(2)) - Substantial modification: post-market change affecting Annex I Part I compliance, or changing the assessed intended purpose (Art. 3(30), Recitals 38-39) ### Supply Chain Duties - Applies to authorised representatives, importers, and distributors (Articles 18 to 20) - Includes traceability duties and possible fines (Article 23, Article 64(3)) ### Authorised Representative Duties - Retention: keep EU declaration of conformity and technical documentation for 10 years or support period, whichever is longer (Art. 18(3)(a)) - On request: provide information and documentation, including the mandate copy (Art. 18(3)(b)) - The mandate cannot include key manufacturer obligations (Art. 18(2)) ### Importer Duties: Before Market - CE marking: verify it is present (Art. 19(2)) - EU declaration of conformity: verify it is present (Art. 19(2)) - Conformity assessment and technical docs: verify they exist (Art. 19(2)) - Annex II user information and instructions: verify they are included and in a language easily understood by users and market surveillance authorities (Art. 19(2)(c)) - Provide importer name and contact details (Art. 19(4)) - Retention: for at least 10 years after placing on the market or for the support period, whichever is longer, keep the EU declaration of conformity available and ensure technical documentation can be provided on request (Art. 19(6)) - On request: provide documentation and cooperate (Art. 19(7)) ### Importer Duties: When Issues Arise - Suspected nonconformity: do not place on market until fixed (Art. 19(3)) - Significant risk: inform manufacturer and authorities (Art. 19(3)) - Nonconforming after placement: correct, withdraw, or recall (Art. 19(5)) - Vulnerabilities: inform manufacturer without undue delay (Art. 19(5)) - Significant risk after placement: inform authorities (Art. 19(5)) ### Distributor Duties: Before Making Available - Before making available, act with due care (Art. 20(1)) - Verify the product bears the CE marking (Art. 20(2)(a)) - Verify the product as supplied is accompanied by required information and documents, including product identification and manufacturer contact details, Annex II user information and instructions, and importer contact details (Art. 20(2)(b), Art. 13(15)-(16), Art. 13(18)-(20), Art. 19(4)) - On request: provide documentation and cooperate (Art. 20(5)) - If you become aware the manufacturer has ceased operations and cannot comply: inform relevant market surveillance authorities without undue delay, as well as, by any means available and to the extent possible, users of the products placed on the market (Art. 20(6)) ### Distributor Duties: When Issues Arise - Suspected nonconformity: do not make available until fixed (Art. 20(3)) - Significant risk: inform manufacturer and authorities (Art. 20(3)) - Nonconforming after availability: correct, withdraw, or recall (Art. 20(4)) - Vulnerabilities: inform manufacturer without undue delay (Art. 20(4)) - Significant risk after availability: inform authorities (Art. 20(4)) ### Traceability & Penalties - Traceability: keep supplier and recipient details for 10 years, and provide to authorities on request (Art. 23(1)-(2)) - Fines can apply for non-compliance with Articles 18 to 23 (Art. 64(3)) ### Annex III: Important Products (Class I) - Identity management and privileged access management (incl. biometric readers) - Standalone and embedded browsers - Password managers - Anti-malware software - VPN products - Network management systems - SIEM systems - Boot managers - PKI and digital certificate issuance software - Physical and virtual network interfaces - Operating systems - Routers, modems (internet), switches - Microprocessors and microcontrollers with security-related functionalities - ASICs and FPGAs with security-related functionalities - Smart home virtual assistants, smart home security products (locks, cameras, alarms) - Internet-connected toys with social interactive or location tracking features - Personal wearables with health monitoring (not under MDR and IVDR) or for children ### Annex III: Important Products (Class II) - Hypervisors and container runtime systems supporting virtualised OS execution - Firewalls, intrusion detection and prevention systems - Tamper-resistant microprocessors - Tamper-resistant microcontrollers ### Annex IV: Critical Products - Hardware devices with security boxes - Smart meter gateways and devices for advanced security purposes (incl. secure cryptoprocessing) - Smartcards or similar devices, including secure elements - When mandated by Commission delegated act, certification must be at assurance level at least 'substantial' under the EU Cybersecurity Act (Art. 8(1)) ### Default Products: Conformity Assessment - Self-assessment via internal control (Module A) is sufficient (Art. 32(1)(a)) - Manufacturer may also choose: Module B+C, Module H, or, where available and applicable, European cybersecurity certification (Art. 32(1)) - Draw up technical documentation (Annex VII), EU declaration of conformity (Art. 28), affix CE marking (Art. 30) - For software products, the CE marking can be on the EU declaration of conformity or on the website accompanying the software product; the relevant section must be easily and directly accessible to consumers (Art. 30(1)) - Harmonised standards, common specifications, and European cybersecurity certification can provide presumption of conformity for the covered essential requirements (Art. 27) - If harmonised standards do not exist or are insufficient, the Commission may adopt common specifications that can be used to demonstrate conformity (Art. 27(2), Art. 27(5)) ### Important Class I: Conformity Assessment - If harmonised standards or common specifications are applied, or a European cybersecurity certificate at assurance level at least 'substantial' is used: self-assessment (Module A) is allowed (Art. 32(2)). Where no harmonised standards exist or the Commission considers them insufficient, the Commission may adopt common specifications; compliance with those confers a presumption of conformity (Art. 27(2), Art. 27(5)) - If not, or only in part, or where such standards or certification do not exist: third-party assessment is required for the essential requirements not covered, via Module B+C or Module H (Art. 32(2)) - Split applies per essential requirement: Module A can cover only requirements covered by harmonised standards, common specifications, or certification. Uncovered requirements must use Module B+C or Module H (Art. 32(2)) - For Annex III products that qualify as free and open-source software: Article 32(1) procedures (including Module A) are available if technical documentation is made public when placing on the market (Art. 32(5)) - Certification can provide presumption of conformity for covered requirements. A certificate at assurance level at least 'substantial' can remove third-party assessment duties for those requirements (Art. 27(8)-(9)) ### Important Class II: Conformity Assessment - Internal control (Module A) is not available for Class II products (Art. 32(3)) - Module B+C, Module H, or, where available and applicable, European cybersecurity certification at assurance level at least 'substantial', for the corresponding requirements (Art. 32(3)) - Derogation for Annex III free and open-source software: use an Article 32(1) procedure (including Module A) if technical documentation is made public when placing on the market (Art. 32(5)) - Certification can provide presumption of conformity for covered requirements. A certificate at assurance level at least 'substantial' can remove third-party assessment duties for those requirements (Art. 27(8)-(9)) ### Critical Products: Conformity Assessment - Must obtain a European cybersecurity certificate at assurance level at least 'substantial' when a Commission delegated act requires it, provided a scheme covering that product category has been adopted and is available to manufacturers (Art. 8(1), Art. 32(4)(a)) - If no such delegated act: same as Class II procedures (Art. 32(4)(b)) - Delegated act mandating certification must set a transitional period of at least 6 months (Art. 8(1)) - Certification can provide presumption of conformity for covered requirements. A certificate at assurance level at least 'substantial' can remove third-party assessment duties for those requirements (Art. 27(8)-(9)) ### Annex I Part I: Product Security Requirements - (a) No known exploitable vulnerabilities at the time of placing on the market - (b) Secure by default configuration - (c) Automatic security updates that are installed within an appropriate timeframe, with an opt-out mechanism for the user - (d) Ensure protection from unauthorised access by appropriate control mechanisms, and report on possible unauthorised access - (e) Protect confidentiality of data, such as by encrypting relevant data at rest or in transit by state of the art mechanisms - (f) Protect integrity of data, commands, programs and configuration, and report on corruptions - (g) Data minimisation - (h) Availability protection, resilience against DoS - (i) Minimise negative impact on other devices and networks - (j) Minimise attack surfaces - (k) Exploitation mitigation mechanisms - (l) Provide security related information by recording and monitoring relevant internal activity, with an opt-out mechanism for the user - (m) Secure data removal and portability ### Annex I Part II: Vulnerability Handling Requirements - (1) Identify and document vulnerabilities and components. Draw up an SBOM in a commonly used machine-readable format covering at least the top-level dependencies - (2) Address and remediate vulnerabilities without delay. Where technically feasible, provide new security updates separately from functionality updates - (3) Effective and regular security testing and reviews - (4) Publicly disclose fixed vulnerabilities with descriptions, affected products, severity, and remediation info. In duly justified cases, disclosure may be delayed until after users have been given the possibility to apply the relevant patch - (5) Coordinated vulnerability disclosure policy - (6) Facilitate sharing of information about potential vulnerabilities. Provide a contact address for vulnerability reporting - (7) Secure update distribution mechanisms - (8) Disseminate security updates without delay and, unless otherwise agreed with a business user for a tailor-made product, free of charge. Provide advisory messages with relevant information, including potential action to be taken ### Support Period - Minimum 5 years (or expected use time if shorter) (Art. 13(8)) - Must reflect expected product use time, considering user expectations, product nature, intended purpose, relevant EU law - End date (month and year) must be clearly displayed at the time of purchase (Art. 13(19)) - Each security update issued during the support period must remain available for a minimum of 10 years after issuance or the remainder of the support period, whichever is longer (Art. 13(9)) - Commission may adopt delegated acts specifying minimum support periods for specific categories where data shows inadequacy (Art. 13(8)) - Market surveillance authorities monitor how support periods are determined; ADCO publishes statistics and guidance with indicative support periods and may issue recommendations where data suggests inadequacy (Art. 52(16)) ### Single Reporting Platform and Main Establishment (Art. 14(7), Art. 16) - Submit via the single reporting platform using the coordinator CSIRT electronic endpoint of the Member State of the manufacturer's main establishment. ENISA has simultaneous access (Art. 14(7), Art. 16(1)) - Main establishment is where decisions related to product cybersecurity are predominantly taken. If unclear, it is where the Union establishment with the highest number of employees is located (Art. 14(7)) - No Union main establishment: choose coordinator CSIRT in this order: authorised representative, importer, distributor (each: highest number of products), then Member State with most users (Art. 14(7)) - After the first report, subsequent notifications for the same product can be submitted to the same CSIRT designated as coordinator (Art. 14(7)) ### Actively Exploited Vulnerability Reporting (Art. 14(1)-(2)) - Early warning: within 24 hours of becoming aware (Art. 14(2)(a)) - Vulnerability notification: within 72 hours, including general info, nature of exploit, corrective measures. Must be updated without undue delay with significant new information (Art. 14(2)(b)) - Final report: within 14 days after a corrective or mitigating measure is available, including description, severity, impact, malicious actor info, remediation details (Art. 14(2)(c)) - CSIRTs may delay dissemination of notifications for cybersecurity reasons; Commission to adopt delegated acts on conditions by 11 Dec 2025 (Art. 14(9), Art. 16(2)) ### Severe Incident Reporting (Art. 14(3)-(5)) - Early warning: within 24 hours (Art. 14(4)(a)) - Incident notification: within 72 hours, including nature, initial assessment, corrective measures. Must be updated without undue delay with significant new information (Art. 14(4)(b)) - Final report: within 1 month after incident notification, including detailed description, root cause, mitigation (Art. 14(4)(c)) - Severe = negatively affects, or could affect, the ability to protect availability, authenticity, integrity, or confidentiality of sensitive or important data or functions, or has led, or could lead, to introduction or execution of malicious code (Art. 14(5)) ### User Notification (Art. 14(8)) - After becoming aware: inform impacted users (and where appropriate all users) of the vulnerability or incident - Provide risk mitigation and corrective measures users can deploy - Where appropriate, provide information in a structured, machine-readable format that is easily automatically processable - Where manufacturer fails to inform in timely manner, CSIRT may inform users if proportionate and necessary ### Voluntary Reporting & EU Coordination (Art. 15, Art. 17) - Voluntary reporting: manufacturers and other natural or legal persons may notify vulnerabilities, cyber threats, incidents and near misses to a coordinator CSIRT or to ENISA (Art. 15(1)-(2)) - Voluntary notifications follow the Article 16 single reporting platform procedure. CSIRT may prioritise mandatory notifications (Art. 15(3), Art. 16) - If someone other than the manufacturer reports an actively exploited vulnerability or a severe incident, the CSIRT designated as coordinator informs the manufacturer without undue delay (Art. 15(4)) - Confidentiality: CSIRTs and ENISA protect the information. Voluntary reporting must not impose additional obligations on the notifier (Art. 15(5)) - Liability: the mere act of notification does not subject the notifier to increased liability (Art. 17(4)) - ENISA may submit CRA notifications to EU-CyCLONe where relevant for coordinated management of large-scale cybersecurity incidents and crises (Art. 17(1)) - Sources: Art. 15(1)-(5), Art. 16, Art. 17(1), Art. 17(4) ### Open-Source Software Steward Obligations (Art. 24) - Put in place and document a cybersecurity policy fostering secure development and effective vulnerability handling (Art. 24(1)) - Cooperate with market surveillance authorities (Art. 24(2)) - Reporting applies only to the extent the steward is involved in development (Art. 24(3)): actively exploited vulnerabilities (Art. 14(1)), and severe incidents and user notification where the steward's development infrastructure is affected (Art. 14(3), Art. 14(8)) - Derogation from Art. 64(3)-(9) administrative fines for any infringement (Art. 64(10)(b)) - Commission may establish voluntary security attestation programmes for free and open-source software (Art. 25) ### Software Bill of Materials (SBOM) - Formal record of components and supply chain relationships in software elements (Art. 3(39)) - Must be in commonly used, machine-readable format covering at least top-level dependencies (Annex I, Part II(1)) - Part of technical documentation (Annex VII(2)(b)); provided to market surveillance on reasoned request (Annex VII(8)) - Manufacturers not obliged to make SBOM public (Recital 77) - Commission may specify format and elements via implementing acts (Art. 13(24)) ### Technical Documentation & CE Marking - Technical documentation (Annex VII) includes product description, design, development and production info, cybersecurity risk assessment, SBOM, coordinated vulnerability disclosure (CVD) policy, standards applied, and test evidence - Cybersecurity risk assessment must be included in the technical documentation when placing on the market (Art. 13(4)) - EU declaration of conformity follows Annex V structure and includes the elements from the relevant conformity assessment procedures in Annex VIII. It must be made available in the languages required by the Member State where the product is placed on the market or made available (Art. 28(2)) - Prepare before placing on the market and keep it updated during the support period (Art. 31(2)) - Manufacturers keep the technical documentation and the EU declaration of conformity at the disposal of market surveillance authorities for at least 10 years after placing on the market or for the support period, whichever is longer (Art. 13(13)) - CE marking: affix before placing on the market. For software, on the EU declaration of conformity or on an accompanying website section easily and directly accessible to consumers. If Module H is used, add the notified body number (Art. 30(1), Art. 30(4)) - Member States take appropriate action in the event of improper use of the CE marking (Art. 30(5)) - Simplified technical documentation form available for micro and small enterprises (Art. 33(5)) ### Manufacturer: Product ID and Contact Details - Series production: keep procedures in place so products remain in conformity over time (Art. 13(14)) - Product identification: type, batch or serial number, or on packaging or accompanying document where not possible (Art. 13(15)) - Manufacturer contact details must be on the product, packaging, or accompanying document (Art. 13(16)) ### Manufacturer: User Info and Support Period - Single point of contact: enable fast user communication, including vulnerability reporting (Art. 13(17)) - Annex II information and instructions must accompany the product and be in a language easily understood by users and market surveillance authorities. Keep them available for 10 years or the support period, whichever is longer (Art. 13(18)) - Support period: specify the end date at purchase. Where technically feasible, notify users when the support period ends (Art. 13(19)) - Provide the EU declaration of conformity or a simplified declaration with the link to the full declaration (Art. 13(20)) ### Manufacturer: Corrective Measures and Cooperation - Nonconforming product or processes: take corrective measures, or withdraw or recall as appropriate (Art. 13(21)) - On request: provide information and documentation, and cooperate on measures to eliminate cybersecurity risks (Art. 13(22)) - If the manufacturer ceases operations and cannot comply, inform authorities and, where possible, users (Art. 13(23)) ### Annex II: User Info and Instructions - Manufacturer identification and contact: name, registered trade name or trademark, postal address, email or other digital contact, and where available a website contact (Annex II(1)) - Single point of contact for vulnerability reporting and where the coordinated vulnerability disclosure (CVD) policy can be found (Annex II(2)) - Product identification: name, type and any additional information enabling unique identification (Annex II(3)) - Intended purpose and security environment, essential functionalities, and security properties (Annex II(4)) - Any known or foreseeable circumstance, including reasonably foreseeable misuse, that may lead to significant cybersecurity risks (Annex II(5)) - Where applicable, the internet address where the EU declaration of conformity can be accessed (Annex II(6)) - Type of technical security support offered and end date (month and year) of the support period (Annex II(7), Art. 13(19)) - User information and instructions must be provided in a language easily understood by users and market surveillance authorities (Art. 13(18), Art. 19(2)(c)) - Detailed instructions on: secure use throughout the product lifetime (Annex II(8)(a)), how changes can affect data security (Annex II(8)(b)), how to install security-relevant updates (Annex II(8)(c)), secure decommissioning and how user data can be securely removed (Annex II(8)(d)) - Instructions on how to turn off the default automatic installation of security updates (Annex II(8)(e)) - If the manufacturer makes the software bill of materials available to the user: where it can be accessed (Annex II(9)) - Where appropriate, information for users should be provided in a structured, machine-readable format that is easily automatically processable (cross-reference: Art. 14(8) uses this principle for user notifications) - Implementation note: check Member State administrative guidance for any national language expectations for user-facing materials and communications with authorities ### Market Surveillance & Enforcement - Reg. (EU) 2019/1020 on market surveillance applies (Art. 52(1)) - Each Member State designates one or more market surveillance authorities (Art. 52(2)) - ADCO (Administrative Cooperation Group) established for uniform application (Art. 52(15)) - Authorities cooperate with national cybersecurity certification authorities, CSIRTs, ENISA, and data protection authorities (Art. 52(4)-(7)) - Sweeps: simultaneous coordinated control actions for specific product categories (Art. 60) - In exceptional circumstances, the Commission may carry out a compliance evaluation and may request ENISA to provide a supporting analysis (Art. 56(3)) - CRA amends Reg. 2019/1020 Annex I to include CRA products (Art. 66) - ADCO may decide to conduct Union-wide dependency assessments; market surveillance authorities may request SBOMs and provide dependency information to ADCO in anonymised and aggregated form. ADCO transmits a report to the NIS Cooperation Group (Art. 13(25), Directive (EU) 2022/2555 Art. 14) ### Due Diligence for Third-Party Components (Art. 13(5)-(6)) - Manufacturers must exercise due diligence when integrating third-party components (Art. 13(5)) - Includes free and open-source software components that have not been made available on the market in the course of a commercial activity (Art. 13(5)) - Upon identifying a vulnerability in an integrated component: report to component maintainer; address and remediate per Annex I Part II (Art. 13(6)) - Share relevant fix code or documentation with component maintainer where appropriate, in machine-readable form (Art. 13(6)) ### Transitional Provisions (Art. 69) - Products placed on the market before 11 Dec 2027: subject to CRA only if substantially modified after that date (Art. 69(2)) - Exception: from 11 Sep 2026, Art. 14 reporting obligations apply to all in-scope products placed on the market before 11 Dec 2027 (Art. 69(3), Art. 71(2)) - Existing EU type-exam certificates under other harmonisation legislation remain valid until 11 Jun 2028 or expiry (Art. 69(1)) ### Substantial Modification (Art. 3(30), Recitals 38-39) - A change to a product after placing on the market that affects compliance with the essential cybersecurity requirements in Annex I Part I, or that modifies the intended purpose for which the product has been assessed (Art. 3(30)) - Includes software or hardware changes that alter the intended purpose or change the type of cybersecurity risk (Recital 38) - Security updates that do not change the intended purpose and merely maintain compliance are not substantial modifications (Recital 39) - A product placed on the market before 11 Dec 2027 becomes subject to CRA requirements if it is substantially modified from that date (Art. 69(2)) ### High-Risk AI Systems (Art. 12) - High-risk AI products fulfilling Annex I Parts I and II and demonstrating protection level in EU declaration of conformity are deemed compliant with AI Act Art. 15 cybersecurity requirements, without prejudice to accuracy and robustness (Art. 12(1)) - Conformity assessment follows AI Act Art. 43 procedure (Art. 12(2)) - Derogation: where AI Act Annex VI internal control applies, Annex III and Annex IV products follow CRA conformity assessment for the cybersecurity requirements (Art. 12(3)) - Notified bodies under the AI Act may also assess CRA Annex I conformity provided they meet CRA Art. 39 requirements (Art. 12(2)) ## Possible Outcomes ### [RESULT] Out of CRA Scope CRA does not apply to this product - The product is outside CRA scope or explicitly excluded - Sector-specific EU legislation may still apply (for example medical devices, motor vehicles, aviation, marine equipment) - Art. 2(8): "The obligations laid down in this Regulation shall not entail the supply of information the disclosure of which would be contrary to the essential interests of Member States' national security, public security or defence." - Sources: Art. 2(2)-(8) ### [ENFORCEMENT] Penalties & Enforcement Administrative fines for non-compliance (Art. 64) - Tier 1: essential requirements (Annex I) and manufacturer obligations (Articles 13 and 14): up to EUR 15 million or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher - Tier 2: other obligations: up to EUR 10 million or 2% of total worldwide annual turnover for the preceding financial year, whichever is higher - Tier 3: misleading information to authorities: up to EUR 5 million or 1% of total worldwide annual turnover for the preceding financial year, whichever is higher - Microenterprises and small enterprises are exempt from fines under paragraphs 3 to 9 for missing the 24-hour early warning deadline - Open-source software stewards are exempt from fines under paragraphs 3 to 9 for any infringement of this Regulation - Sources: Art. 64(2)-(4), Art. 64(10) ## CRA Timeline | Date | Event | Reference | | --- | --- | --- | | 2024-10-23 | CRA adopted (Regulation (EU) 2024/2847) | Reg. 2024/2847 | | 2024-11-20 | Published in the Official Journal on 20 Nov 2024 (CELEX: 32024R2847) | Reg. 2024/2847 | | 2024-12-10 | CRA enters into force (20 days after OJ publication of 20 Nov 2024) | Art. 71(1) | | 2025-12-11 | Deadline: Commission to adopt implementing act on technical descriptions of Annex III and Annex IV categories (used in practice to classify products) | Art. 7(4) | | 2025-12-11 | Deadline: Commission to adopt delegated acts on delayed dissemination conditions | Art. 14(9) | | 2026-06-11 | Rules on notification of conformity assessment bodies apply | Art. 71(2) | | 2026-09-11 | Reporting obligations (Art. 14) start applying | Art. 71(2), Art. 14 | | 2026-12-11 | Deadline: Member States to strive to ensure sufficient notified bodies are available | Art. 35(2) | | 2027-12-11 | CRA fully applies; all obligations in effect | Art. 71(2) | | 2028-09-11 | Deadline: Commission report on single reporting platform effectiveness | Art. 70(2) | | 2030-12-11 | Deadline: first Commission evaluation and review report due | Art. 70(1) | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2021-09-15 | CRA announced in State of the Union | Legislative History | SOTEU 2021 | | 2021-09-16 | Commission explainer on the CRA (quotes SOTEU speech) | Legislative History | | | 2022-03-16 | Public consultation | Legislative History | | | 2022-09-15 | Commission proposal published | Legislative History | COM(2022) 454 | | 2023-06-08 | Council general approach | Legislative History | | | 2023-07-19 | Council common position | Legislative History | | | 2023-07-19 | EP ITRE Committee adopts report | Legislative History | | | 2023-09-01 | Parliament enters interinstitutional negotiations | Legislative History | | | 2023-11-30 | Political agreement reached | Legislative History | | | 2023-12-01 | Parliament press release on political agreement | Legislative History | | | 2024-03-12 | Parliament plenary adoption | Legislative History | P9_TA(2024)0130 | | 2024-10-10 | Council formal adoption | Legislative History | | | 2024-10-23 | Act date | Official Publication | Reg. (EU) 2024/2847 | | 2024-11-20 | Published in Official Journal | Official Publication | OJ L 2024/2847 | | 2024-12-05 | Corrigendum: editorial title fix | Corrigendum | | | 2024-12-10 | Entry into force | Applicability | Art. 71(1) | | 2024-12-10 | Delegated powers conferred (5-year period begins) | Delegated & Implementing Acts | Art. 61(2) | | 2025-02-03 | Standardisation request M/606 adopted | Standardisation | C(2025) 618 | | 2025-04-03 | M/606 officially accepted by CEN-CENELEC | Standardisation | M/606 | | 2025-07-02 | Corrigendum: Art. 64(10) cross-reference | Corrigendum | Art. 64(10) | | 2025-07-29 | Delegated Reg. 2025/1535 adopted | Delegated & Implementing Acts | Reg. (EU) 2025/1535 | | 2025-10-03 | Corrigendum: Annex I language fix | Corrigendum | Annex I | | 2025-10-17 | Corrigendum: Art. 67 numbering | Corrigendum | Art. 67 | | 2025-10-29 | Delegated Reg. 2025/1535 published in OJ | Delegated & Implementing Acts | OJ L 2025/1535 | | 2025-11-18 | Delegated Reg. 2025/1535 enters into force | Delegated & Implementing Acts | Reg. (EU) 2025/1535 | | 2025-11-28 | Implementing Reg. 2025/2392 adopted | Delegated & Implementing Acts | Reg. (EU) 2025/2392 | | 2025-12-01 | Implementing Reg. 2025/2392 published in OJ | Delegated & Implementing Acts | OJ L 2025/2392 | | 2025-12-11 | Delegated act on CSIRT notification delays | Delegated & Implementing Acts | Art. 16(2) | | 2025-12-11 | Delegated act record published on EUR-Lex | Delegated & Implementing Acts | C(2025) 8407 | | 2025-12-21 | Implementing Reg. 2025/2392 enters into force | Delegated & Implementing Acts | Reg. (EU) 2025/2392 | | 2026-03-03 | Draft CRA guidance published for feedback | Commission Deliverables | | | 2026-03-31 | Feedback closes on draft CRA guidance | Commission Deliverables | | | 2026-06-11 | Chapter IV applies: notified bodies | Conformity Assessment | Art. 35-51 | | 2026-06-11 | Notified bodies listed on NANDO/SMCS (as they are designated) | Conformity Assessment | | | 2026-09-11 | Vulnerability reporting obligations apply | Vulnerability Reporting | Art. 14 | | 2026-09-11 | CRA reporting deadlines (24h / 72h / 14d / 1 month) | Vulnerability Reporting | | | 2026-09-11 | Open-source software stewards: reporting obligations apply (conditional) | Vulnerability Reporting | Art. 24(3), Art. 14 | | 2026-09-11 | Single Reporting Platform operational by this date | Commission Deliverables | | | 2027-12-11 | CRA applies in full | Applicability | Art. 71(2) | | 2027-12-11 | Legacy products: substantial modification rule | Applicability | | | 2027-12-11 | Economic operators obligations apply (importers, distributors, authorised representatives) | Applicability | Arts. 18-21 | | 2027-12-11 | Open-source software stewards: Article 24 obligations apply | Applicability | Art. 24(1)-(2) | | 2029-12-10 | End of initial 5-year delegation period (unless extended) | Delegated & Implementing Acts | Art. 61(2) | **Event details:** - **2021-09-15 - CRA announced in State of the Union**: President von der Leyen announces the CRA in the State of the Union address: 'including legislation on common standards under a new European Cyber Resilience Act.' - **2021-09-16 - Commission explainer on the CRA (quotes SOTEU speech)**: Commission explainer page published the day after SOTEU highlights the CRA and quotes the speech's CRA passage. - **2022-03-16 - Public consultation**: Commission launches CRA public consultation, open 16 March to 25 May 2022. - **2022-09-15 - Commission proposal published**: Commission presents the CRA proposal COM(2022) 454 final. - **2023-06-08 - Council general approach**: Council reaches its 'general approach' (negotiating mandate) on the CRA at the JHA Council meeting. - **2023-07-19 - Council common position**: Member States agree a common position on security requirements for digital products. - **2023-07-19 - EP ITRE Committee adopts report**: EP ITRE Committee adopts its report/position on the CRA. - **2023-09-01 - Parliament enters interinstitutional negotiations**: Parliament confirms its committee decision to enter interinstitutional (trilogue) negotiations in September 2023. - **2023-11-30 - Political agreement reached**: Council and Parliament reach provisional political agreement on the CRA. - **2023-12-01 - Parliament press release on political agreement**: European Parliament press release on the agreement reached with the Council to boost digital products security. - **2024-03-12 - Parliament plenary adoption**: European Parliament adopts the CRA in plenary: 517 in favour, 12 against, 78 abstentions. - **2024-10-10 - Council formal adoption**: Council formally adopts the Cyber Resilience Act. - **2024-10-23 - Act date**: Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 (Cyber Resilience Act) is signed. - **2024-11-20 - Published in Official Journal**: CRA published in the Official Journal of the European Union (OJ L 2024/2847, 20.11.2024). - **2024-12-05 - Corrigendum: editorial title fix**: First corrigendum: corrects '(EU) No 2019/1020' to '(EU) 2019/1020' in the regulation title. - **2024-12-10 - Entry into force**: CRA enters into force on the 20th day following OJ publication (20 Nov + 20 days = 10 Dec 2024). - **2024-12-10 - Delegated powers conferred (5-year period begins)**: Delegation of power to the Commission is conferred for a period of five years from 10 December 2024, with tacit extensions unless opposed. - **2025-02-03 - Standardisation request M/606 adopted**: Commission adopts CRA standardisation request M/606 containing 41 standards. Accepted by CEN, CENELEC, and ETSI on 3 April 2025. - **2025-04-03 - M/606 officially accepted by CEN-CENELEC**: CEN-CENELEC officially accepted the CRA standardisation request on 3 April 2025. - **2025-07-02 - Corrigendum: Art. 64(10) cross-reference**: Corrigendum fixes Article 64(10): 'paragraphs 3 to 9' corrected to 'paragraphs 2 to 9'. - **2025-07-29 - Delegated Reg. 2025/1535 adopted**: Commission excludes most L-category vehicle products from CRA scope (exception for L1e pedal-designed). OJ publication 29 Oct 2025; enters into force 20 days later. - **2025-10-03 - Corrigendum: Annex I language fix**: Corrigendum fixes FR/HU language wording in Annex I, Part I, paragraph 2, point (c). - **2025-10-17 - Corrigendum: Art. 67 numbering**: Corrigendum fixes numbering reference in Article 67: '69' corrected to '72'. - **2025-10-29 - Delegated Reg. 2025/1535 published in OJ**: Delegated Regulation (EU) 2025/1535 is published in the Official Journal on 29 October 2025. - **2025-11-18 - Delegated Reg. 2025/1535 enters into force**: Delegated Regulation (EU) 2025/1535 enters into force on the twentieth day following its OJ publication. - **2025-11-28 - Implementing Reg. 2025/2392 adopted**: Commission adopts technical descriptions for Annex III/IV product categories (important and critical products). OJ publication 1 Dec 2025; enters into force 20 days later. - **2025-12-01 - Implementing Reg. 2025/2392 published in OJ**: Implementing Regulation (EU) 2025/2392 is published in the Official Journal on 1 December 2025. - **2025-12-11 - Delegated act on CSIRT notification delays**: Commission adopts delegated act specifying terms and conditions for delaying dissemination of vulnerability notifications by CSIRTs under Article 16(2). - **2025-12-11 - Delegated act record published on EUR-Lex**: EUR-Lex record for the Commission delegated act concerning Article 16(2) conditions for CSIRTs delaying dissemination to other CSIRTs. - **2025-12-21 - Implementing Reg. 2025/2392 enters into force**: Implementing Regulation (EU) 2025/2392 enters into force on the twentieth day following its OJ publication. - **2026-03-03 - Draft CRA guidance published for feedback**: Commission publishes draft CRA guidance for stakeholder feedback, clarifying scope, remote data processing, free and open-source software, support periods, and interplay with other EU law. - **2026-03-31 - Feedback closes on draft CRA guidance**: The stakeholder feedback period on the Commission's draft CRA guidance closes on 31 March 2026. - **2026-06-11 - Chapter IV applies: notified bodies**: CRA Chapter IV (Articles 35-51) on notification of conformity assessment bodies begins to apply. - **2026-06-11 - Notified bodies listed on NANDO/SMCS (as they are designated)**: From the Chapter IV applicability date, conformity assessment bodies can be notified under the CRA framework and, once notified, will appear in the Commission's NANDO/SMCS notified bodies list for the CRA. - **2026-09-11 - Vulnerability reporting obligations apply**: Article 14 (vulnerability and incident reporting) applies. Manufacturers must report actively exploited vulnerabilities and severe incidents via ENISA's Single Reporting Platform. - **2026-09-11 - CRA reporting deadlines (24h / 72h / 14d / 1 month)**: From the Article 14 applicability date, incident/vulnerability notifications follow operational time limits (early warning within 24 hours of awareness; full notification within 72 hours; final report timelines depending on case, such as 14 days or 1 month). - **2026-09-11 - Open-source software stewards: reporting obligations apply (conditional)**: Open-source software stewards are subject to Article 14(1) (and, where applicable, Article 14(3) and (8)) to the extent they are involved in development, from the date Article 14 applies. - **2026-09-11 - Single Reporting Platform operational by this date**: Commission states ENISA's Single Reporting Platform (SRP) will be operational by 11 September 2026 to support CRA vulnerability and incident reporting. - **2027-12-11 - CRA applies in full**: General application date: the CRA applies in full from 11 December 2027. - **2027-12-11 - Legacy products: substantial modification rule**: Products placed on the EU market before 11 December 2027 are subject to CRA product requirements only if, from that date, they undergo a substantial modification; reporting obligations still apply from the earlier reporting applicability date. - **2027-12-11 - Economic operators obligations apply (importers, distributors, authorised representatives)**: From the general CRA application date, authorised representatives, importers, and distributors must comply with their CRA obligations; in certain cases (e.g., own-branding or substantial modification) importers/distributors are treated as manufacturers. - **2027-12-11 - Open-source software stewards: Article 24 obligations apply**: Open-source software stewards must have a verifiable cybersecurity policy for secure development and vulnerability handling, and cooperate with market surveillance authorities (subject to CRA scope). - **2029-12-10 - End of initial 5-year delegation period (unless extended)**: The initial five-year period for the Commission's delegated powers runs until 10 December 2029, subject to tacit extensions unless opposed. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu-cra-conformity-route-map --- --- title: "EU Data Act Scope Decision Map: Role Logic, Data Sharing, and Switching Readiness" canonical_url: "https://www.sorena.io/artifacts/eu-data-act-scope-decision-map" source_url: "https://www.sorena.io/artifacts/eu-data-act-scope-decision-map" author: "Sorena AI" description: "Advanced EU Data Act Scope Decision Map for Regulation (EU) 2023/2854 implementation: scope and role determination." keywords: - "EU Data Act Scope Decision Map compliance" - "EU Data Act Scope Decision Map guide" - "EU Data Act Scope Decision Map checklist" - "EU Data Act Scope Decision Map requirements" - "EU Data Act Scope Decision Map template" - "Regulation EU 2023 2854 implementation" - "connected products product data access" - "related services data sharing" - "data holder user data recipient roles" - "B2G exceptional need requests" - "cloud switching charges ban 2027" - "Data Act portability requirements" - "EU Data Act Scope Decision Map" - "Regulation (EU) 2023/2854" - "Connected products data" - "B2B data sharing" - "B2G exceptional need" - "Cloud switching" - "Data portability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Data Act Scope Decision Map: Role Logic, Data Sharing, and Switching Readiness Advanced EU Data Act Scope Decision Map for Regulation (EU) 2023/2854 implementation: scope and role determination. ![EU Data Act Scope Decision Map by Sorena AI](https://cdn.sorena.io/cheatsheets/sorena-ai-data-act-cheatsheet-small.jpg) *Data Act* *Free Resource* ## EU Data Act Scope Decision Map This EU Data Act Scope Decision Map helps teams turn legal interpretation into implementation decisions. Confirm whether your scenario is in scope, map user and data-holder duties, and define data-sharing, contractual, and cloud-switching workflows with clear ownership. Grounded in Regulation (EU) 2023/2854, Commission Data Act FAQs (v1.4), and Commission implementation resources. Use this map as an execution control for product, legal, platform, and compliance teams. [Create my custom view](/solutions/assessment.md) ## What you can decide faster - **Scope and role**: Determine whether the product/service is in scope and identify user, data holder, and recipient responsibilities. - **Share, protect, or refuse**: Operationalise user-directed sharing while applying trade-secret, security, and legal-limit safeguards correctly. - **Switching readiness**: Implement portability, switching, and contract updates for data-processing services with measurable milestones. By Sorena AI | Updated Mar 2026 | No sign-up required ### Role-to-obligation navigator *Data Act* - **Product manufacturer**: Design access by default and establish data-availability and transparency flows. - **Data holder**: Deliver user access and user-directed sharing with legal and security safeguards. - **Data recipient**: Implement purpose limits, confidentiality controls, and onward-use governance. - **Cloud provider**: Enable switching, portability, and contractual protections against unlawful access. Use this map to move from legal scope questions to operational workflows and evidence outcomes. | Value | Metric | | --- | --- | | 12 Sep 2025 | Applies | | B2B | Sharing | | B2G | Exceptional need | | 2027 | Switching fees ban | **Key highlights:** Scope first | Switching readiness | Role-based controls ## Primary sources - [Regulation (EU) 2023/2854 (Data Act)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj?ref=sorena.io) - Primary legal text for fair access to and use of data across connected products and services. - [European Commission Data Act policy page](https://digital-strategy.ec.europa.eu/en/policies/data-act?ref=sorena.io) - Official implementation entry point with timing, policy context, and linked implementation resources. - [European Commission FAQs on the Data Act (v1.4)](https://ec.europa.eu/newsroom/dae/redirection/document/108144?ref=sorena.io) - Practical clarifications on scope, role interpretation, obligations, and legislative interplay. - [Commission Guidance on vehicle data under the Data Act (C/2025/5026)](https://eur-lex.europa.eu/eli/C/2025/5026/oj?ref=sorena.io) - Sector-specific guidance on applying Data Act access and sharing logic in vehicle-data scenarios. - [Commission C(2025) 4135 final (Data Act standardisation annexes)](https://ec.europa.eu/newsroom/dae/redirection/document/114410?ref=sorena.io) - Implementation context for interoperability and standardisation supporting Data Act execution. ## Key dates for EU Data Act implementation *Data Act Timeline* Track application and phased obligations so product, legal, and platform teams can sequence contracts, APIs, and governance changes with shared deadlines. ## What does the Data Act mean for your operating model? *Data Act Scope Decision Map* Follow the decision flow from scope and role to user-directed sharing, B2B/B2G handling, portability, and switching obligations. Each branch leads to practical implementation outcomes. *Go further* ## Turn this scope map into a complete Data Act execution program Use the EU Data Act deep-dive pages to convert scope outcomes into implementable controls, clauses, workflows, and evidence practices. - Map each role decision to accountable owners and implementation backlog items - Build user-access and user-directed sharing workflows with security and trade-secret safeguards - Operationalise B2G exceptional-need intake, triage, response, and escalation procedures - Implement cloud switching and portability controls with contract and technical evidence - **Open requirements deep dive**: Map Data Act obligations to controls, owners, and evidence outputs. - **Download Scope Map**: Share scope and role decision logic with product, legal, and platform teams. - **Download Timeline**: Share implementation milestones and switching deadlines. - **Open compliance checklist**: Use an audit-ready checklist with acceptance criteria and evidence expectations. ## Decision Steps ### START: Do any of the Data Act scope categories apply to you for this scenario? *Reference: Art. 1(3)* - Manufacturer of connected products placed on the Union market, or provider of related services (Art. 1(3)(a)). - User in the Union of connected products or related services (Art. 1(3)(b)). - Data holder making data available to data recipients in the Union, or data recipient in the Union (Art. 1(3)(c)-(d)). - Public sector body, the Commission, the ECB, or a Union body requesting data due to exceptional need, or a data holder responding (Art. 1(3)(e)). - Provider of data processing services providing services to customers in the Union (Art. 1(3)(f)). - Participant in data spaces, vendor of applications using smart contracts, or deployment of smart contracts for others in that context (Art. 1(3)(g)). - **YES** Which parts of the Data Act should you focus on? - **NO** Out of Data Act Scope ### IN SCOPE: Which parts of the Data Act should you focus on? - Follow every chapter that matches what you do in practice. Multiple chapters can apply at the same time. - Chapter II is for connected products and related services data access and user-directed sharing. - Chapters III and IV cover B2B making data available and unfair contractual terms. - Chapter V covers exceptional need requests by public sector bodies. - Chapters VI and VII cover cloud switching and safeguards against unlawful third-country access. - Chapter VIII covers interoperability and smart contracts. - -> Connected products and related services: user access and sharing ### CHAPTER II: Connected products and related services: user access and sharing - Applies if you manufacture connected products placed on the Union market, provide related services, or must provide users access to product or related service data. - Covers access by design and transparency (Article 3), user access and data holder duties (Article 4), sharing to third parties (Article 5), and third party duties (Article 6). - -> B2B making data available: terms and safeguards ### CHAPTER III: B2B making data available: terms and safeguards - Applies where, in business-to-business relations, a data holder is obliged under Article 5 or under applicable Union law or national legislation adopted in accordance with Union law to make data available to a data recipient (Art. 12(1)). - For statutory data-sharing obligations arising under other Union or national law, Chapter III applies only where that law enters into force after 12 September 2025 (Art. 50). - Covers fair and non-discriminatory terms (Article 8), compensation (Article 9), disputes (Article 10), technical protection measures (Article 11), and when Chapter III applies (Article 12). - -> Unfair terms in B2B data contracts ### CHAPTER IV: Unfair terms in B2B data contracts - Applies if you have a B2B contract governing access to or use of data and face terms imposed unilaterally. - Explains which unfair terms are not binding (Article 13). - -> Exceptional need requests from public sector bodies (B2G) ### CHAPTER V: Exceptional need requests from public sector bodies (B2G) - Applies if you issue or receive requests for data due to exceptional need by public sector bodies, or respond to such requests as a data holder. - Covers when requests are allowed (Articles 14 to 16), request requirements (Article 17), response and handling duties (Articles 18 and 19), and related rules (Articles 20 to 22). - -> Switching between data processing services (cloud switching) ### CHAPTER VI: Switching between data processing services (cloud switching) - Applies if you provide data processing services to customers in the Union or if you are a customer switching between providers or to on-premises infrastructure. - Covers contract clauses, portability, technical interfaces, and phase-out of switching charges (Articles 23 to 31). - -> Safeguards against unlawful third-country access ### CHAPTER VII: Safeguards against unlawful third-country access - Applies if you are a provider of data processing services providing services to customers in the Union, for non-personal data held in the Union (Art. 1(3)(f), Art. 32). - Covers safeguards against unlawful third-country access requests that conflict with Union or Member State law (Article 32). - -> Interoperability and smart contracts ### CHAPTER VIII: Interoperability and smart contracts - Applies if you participate in data spaces or deploy smart contracts for data sharing agreements in the relevant context. - Covers interoperability requirements (Articles 33 to 35) and smart contract requirements (Article 36). - -> Authorities, remedies, penalties, and dates ### ENFORCEMENT: Authorities, remedies, penalties, and dates - Covers competent authorities and complaints (Article 37), penalties (Article 40), model terms (Article 41), and application dates (Article 50). - Use this section to plan implementation and contract updates. - -> Data Act Compliance Checklist ## Reference Information ### Scope and precedence - Confirm whether the Data Act applies to your roles and scenario. - Check how it interacts with other laws and voluntary sharing. ### Key definitions - Map your products and services to the Regulation's definitions. - Identify roles such as user, data holder, and data recipient. ### What data is covered - Understand what data is in scope for Chapter II and what is excluded. - Pay attention to readily available data and metadata concepts. ### Exemption check - Check whether the Chapter II exemption for micro and small enterprises applies. ### Article 3: access by design and transparency - Design for user access to in-scope data and provide required pre-contract information. ### Article 4: user access and data holder duties - User access rights, data holder duties, and security-based restrictions. ### Trade secret safeguards - Measures for protecting trade secrets during access and sharing. - Rules on withholding, suspension, or refusal where applicable. ### Article 5: user sharing to third parties - Core sharing rule plus verification, data protection, and trade secret safeguards. ### Article 6: third party duties - Obligations and use limits for third parties after receiving data. ### When Chapter V applies - Exceptional need scenarios and who can request data. ### Request requirements (Article 17) - Required content, proportionality, and formalities. - Publication, routing, and penalties information tied to the request. ### Response and handling duties - How data holders respond and the deadlines and refusal grounds. - How requesting bodies must use, protect, and erase the data. ### Sharing limits and onward sharing - No reuse rules and conditions for onward sharing, including research and statistics. ### Coordination and cross-border - Cross-border cooperation and where disputes are handled. ### Definitions for switching - Key terms for switching, exportable data, and charges. ### Contract clauses for switching (Article 25) - Minimum clauses, timelines, customer choices, and retrieval and erasure. ### Information duties and transparency - Registers and procedures that support switching and transparency on international access. ### Switching charges phase-out (Article 29) - Reduced charges period then prohibition for the switching process. ### Technical interfaces, standards, limits - Portability interfaces, standards timing, limits, and exemptions. ### Authorities and governance - Competent authorities, data coordinators, legal representative duties, and governance. ### Complaints and remedies - Complaint handling and judicial remedies. ### Penalties and model terms - Penalties framework plus non-binding model contractual terms and cloud clauses. ### Interaction with other EU law - How the Data Act interacts with other Union data access laws and consumer enforcement. ### Dates and timeline - Entry into force, application dates, and key deadlines. ### Who and What the Data Act Covers - Applies to manufacturers of connected products placed on the EU market and providers of related services, regardless of place of establishment (Art. 1(3)(a)) - Applies to users in the Union of those products or services (Art. 1(3)(b)) - Applies to data holders making data available to data recipients in the Union, and to those data recipients (Art. 1(3)(c)-(d)) - Applies to public sector bodies, the Commission, the ECB, and Union bodies requesting data on exceptional need, and to data holders responding (Art. 1(3)(e)) - Applies to providers of data processing services providing to customers in the Union, regardless of place of establishment (Art. 1(3)(f)) - Also applies to participants in data spaces and certain smart contract actors in scope contexts (Art. 1(3)(g)) ### Precedence and Voluntary Data Sharing - Without prejudice to EU and national data protection, privacy and communications confidentiality rules, including GDPR and ePrivacy; in a conflict, the relevant data protection or privacy rules prevail (Art. 1(5)) - Does not apply to or pre-empt voluntary arrangements for data sharing between private and public entities (Art. 1(6)) - Does not affect Member State competences on public security, defence, national security, customs and tax administration, or health and safety of citizens (Art. 1(6)) ### Connected Products and Related Services - Connected product: obtains, generates or collects data about its use or environment, can communicate product data, and its primary function is not storing, processing or transmitting data on behalf of parties other than the user (Art. 2(5)) - Related service: digital service linked to product functionality, where absence would prevent one or more product functions, or later connected to add to, update or adapt product functions (Art. 2(6)) - References to connected products or related services include virtual assistants insofar as they interact with a connected product or related service (Art. 1(4)) - Connected products fall within scope, with the exception of prototypes (Recital 14) ### Actors and Roles - User: owns a connected product, has temporary rights to use it, or receives related services (Art. 2(12)) - Data holder: has a right or obligation to use and make available data, including product data or related service data where contractually agreed (Art. 2(13)) - Data recipient: business recipient other than the user, including a third party following a user request (Art. 2(14)) - Third party is not a separate defined term in Article 2. A third party may be a natural or legal person such as a consumer, enterprise, research organisation, not-for-profit organisation, or another professional entity. When receiving data at a user's request, a third party may also be a data recipient (Recital 33). - Processors under GDPR are not considered data holders, but can be tasked with making data available by the controller (Recital 22) ### Data Types and Availability - Product data: data generated by use of a connected product that the manufacturer designed to be retrievable by a user, data holder or third party (Art. 2(15)) - Related service data: digitisation of user actions or events related to the connected product during the provision of a related service (Art. 2(16)) - Readily available data: product data and related service data obtainable without disproportionate effort beyond a simple operation (Art. 2(17)) - Readily available data does not include data that is not stored or transmitted outside the component or product where it is generated, and the Data Act does not impose an obligation to store data centrally (Recital 20) ### Cloud Switching Terms - Data processing service: on-demand access to configurable, scalable and elastic computing resources of a centralised, distributed or highly distributed nature (Art. 2(8)) - Same service type: services sharing the same primary objective, service model and main functionalities (Art. 2(9)) - Customer: person with a contract with a provider of data processing services to use one or more such services (Art. 2(30)) - Digital assets: elements in digital form, including applications, for which the customer has a right of use independent of the source provider contract (Art. 2(32)) - Switching: customer changes provider or moves on-premises, including extracting, transforming and uploading data (Art. 2(34)) - Exportable data: customer input and output data, including metadata, generated or cogenerated by use of the service, excluding providers' or third parties' IP-protected assets or trade secrets (Art. 2(38)) ### Switching and Charges Definitions - On-premises ICT infrastructure: ICT infrastructure and computing resources owned, rented or leased by the customer, located in the customer's data centre, operated by the customer or a third party (Art. 2(33)) - Data egress charges: data transfer fees charged for extracting data through the network from a provider to another provider or to on-premises infrastructure (Art. 2(35)) - Switching charges: charges other than standard service fees or early termination penalties imposed for the actions mandated by the Data Act for switching, including data egress charges (Art. 2(36)) - Functional equivalence: re-establishing a minimum level of functionality in the new environment using the customer's exportable data and digital assets, with materially comparable outcomes for shared features (Art. 2(37)) ### What Data Is in Scope - Chapter II covers data, except content, concerning the performance, use and environment of connected products and related services (Art. 1(2)(a)) - Includes product data and related service data as defined (Art. 2(15)-(16)) - Includes raw and pre-processed data plus relevant metadata, but not data cleaning or transformation requiring substantial investments (Recital 15) - Does not include inferred or derived data produced through additional investments, such as proprietary, complex algorithms, unless otherwise agreed (Recital 15) - Content and data generated from recording, transmitting, displaying, or playing content are not covered, and data processed on behalf of parties other than the user is not covered (Recital 16) ### Micro and Small Enterprise Exemption - Chapter II obligations do not apply to data generated through use of connected products manufactured or designed, or related services provided, by a microenterprise or small enterprise (Art. 7(1)) - The exemption does not apply where the enterprise has a non-SME partner or linked enterprise, or where it is subcontracted to manufacture, design, or provide the product or service (Art. 7(1)) - Transitional: applies to an enterprise that has been medium-sized for less than one year, and to connected products for one year after placement on the market by that enterprise (Art. 7(1)) - Contract terms undermining user rights under Chapter II are not binding on the user (Art. 7(2)) ### Access by design checklist (Article 3) - By default, make product data, related service data and necessary metadata easily accessible, secure and free of charge (Art. 3(1)) - Provide data in a comprehensive, structured, commonly used and machine-readable format, and where relevant and technically feasible, make it directly accessible to the user (Art. 3(1)) - The Article 3(1) design obligation applies to connected products and services related to them placed on the market after 12 September 2026 (Art. 50) ### Pre-Contract Transparency (Article 3(2)-(3)) - Before purchase, rent or lease: disclose data type, format, estimated volume, and whether generation is continuous and in real time (Art. 3(2)(a)-(b)) - Also disclose storage location and retention, and how the user can access, retrieve or erase data including technical means, terms and quality of service (Art. 3(2)(c)-(d)) - Before a related service contract: provide data nature, estimated volume and collection frequency, and how to access, retrieve or erase data (Art. 3(3)(a)-(b)) - Also disclose intended use, third party sharing, identities and contacts, complaint rights, trade secret holder details, and contract duration and termination (Art. 3(3)(c)-(i)) ### User access and data holder duties (Article 4) - If data cannot be directly accessed by the user, make readily available data and necessary metadata accessible without undue delay, of the same quality as available to the data holder, easily, securely and free of charge (Art. 4(1)) - Provide the data in a comprehensive, structured, commonly used and machine-readable format, and where relevant and technically feasible, continuously and in real time (Art. 4(1)) - Provide access on the basis of a simple request, through electronic means where technically feasible (Art. 4(1)) - Do not make exercising rights unduly difficult, including via non-neutral user interface design (Art. 4(4)) - Verify whether a person qualifies as a user using only necessary information, and keep access-related information only as needed for execution, security and maintenance (Art. 4(5)) ### Security-Based Restrictions and Authority Notification (Art. 4(2)) - If a data holder refuses to share data based on this security restriction, it must notify the competent authority (Art. 4(2), Art. 37) - Users and data holders may contractually restrict or prohibit accessing, using or further sharing data to protect connected product security requirements under Union or national law (Art. 4(2)) - Such restrictions apply only where access or sharing would result in a serious adverse effect on the health, safety or security of natural persons (Art. 4(2)) - Sectoral authorities may provide users and data holders with technical expertise in that context (Art. 4(2)) - Users can challenge a data holder's security-based refusal through a complaint or dispute settlement (Art. 4(3), Art. 10(1)) ### Limits on Data Holder Use and Disclosure - Non-personal readily available data may be used by a data holder only on the basis of a contract with the user (Art. 4(13)) - A data holder must not use such data to derive insights about the user's economic situation, assets and production methods, or use by the user, in a way that could undermine the user's commercial position (Art. 4(13)) - Data holders shall not make available non-personal product data to third parties for commercial or non-commercial purposes other than the fulfilment of their contract with the user, and where relevant, shall contractually bind third parties not to further share data received from them (Art. 4(14)) ### Trade Secret Safeguards (User Access) - Trade secrets can be shared only where the data holder and the user take necessary measures to preserve confidentiality, especially regarding third-party access (Art. 4(6)) - Identify trade secret data in metadata (Art. 4(6)) - Agree proportionate technical and organisational measures with the user, such as confidentiality agreements, strict access protocols, technical standards and codes of conduct (Art. 4(6)) ### Withholding or Refusing Trade Secret Data - If measures are not agreed, not implemented, or confidentiality is undermined, the data holder may withhold or suspend sharing, must provide a substantiated written decision, and must notify the competent authority (Art. 4(7), Art. 37) - In exceptional circumstances, a trade secret holder may refuse a request case by case if serious economic damage is highly likely despite measures, must provide a substantiated written decision, and must notify the competent authority (Art. 4(8), Art. 37) - Users can challenge refusal, withholding or suspension via a complaint or a dispute settlement body (Art. 4(9), Art. 10(1)) ### User Restrictions When Using Data - Do not use data obtained under Art. 4(1) to develop a competing connected product, and do not share data with that intent (Art. 4(10)) - Do not use data to derive insights about the economic situation, assets, and production methods of the manufacturer or data holder (Art. 4(10)) - Do not use coercive means or abuse gaps in the data holder's technical infrastructure to obtain access (Art. 4(11)) - Where the user is not the data subject, personal data can be made available only with a valid GDPR legal basis and relevant ePrivacy conditions (Art. 4(12)) ### Sharing Data With Third Parties (Core Rules) - On user request, make readily available data and relevant metadata available to a third party without undue delay, of the same quality as available to the data holder, easily, securely and free of charge to the user (Art. 5(1)) - Provide the data in a comprehensive, structured, commonly used and machine-readable format and, where relevant and technically feasible, continuously and in real time (Art. 5(1)) - Provide data to the third party in accordance with the arrangements and compensation rules in Articles 8 and 9 (Art. 5(1)) - Testing exception: paragraph 1 does not apply to readily available data generated during testing of new connected products, substances or processes not yet placed on the market, unless contractually permitted (Art. 5(2)) - DMA gatekeepers are not eligible third parties and cannot solicit, incentivise or receive data through the Art. 5 routes (Art. 5(3)) ### Third-Party Sharing: Verification and Access Integrity - For verification, the user or third party must not be required to provide more information than necessary (Art. 5(4)) - Data holders must not keep third-party access information beyond what is necessary for execution, security and maintenance of the data infrastructure (Art. 5(4)) - Third parties must not use coercive means or abuse gaps in a data holder's technical infrastructure to obtain access (Art. 5(5)) ### Third-Party Sharing: Data Protection and Use Limits - Data holders must not use the data to derive insights about the third party's economic situation, assets and production methods, or use, in any manner that could undermine the third party's commercial position (Art. 5(6)) - Exception: allowed only where the third party permits it and can easily withdraw permission at any time (Art. 5(6)) - Where the user is not the data subject, personal data can be made available to the third party only with a valid GDPR legal basis and relevant ePrivacy conditions (Art. 5(7)) - Failure to agree arrangements for transmitting the data must not hinder the rights of data subjects under GDPR, including data portability (Art. 5(8)) - The Art. 5 right to share data must not adversely affect data subjects' rights under applicable data protection law (Art. 5(13)) ### Sharing Data With Third Parties (Trade Secrets and Disputes) - Trade secrets may be disclosed to third parties only to the extent strictly necessary for the purpose agreed between the user and the third party, and proportionate confidentiality measures must be agreed (Art. 5(9)) - If measures are not agreed, not implemented, or confidentiality is undermined, the data holder may withhold or suspend sharing of trade secret data, must provide a substantiated written decision, and must notify the competent authority (Art. 5(10)) - In exceptional circumstances, a trade secret holder may refuse a request case by case if serious economic damage is highly likely despite measures, and must notify the competent authority (Art. 5(11)) - Third parties can challenge withholding, suspension or refusal via a complaint or a dispute settlement body (Art. 5(12), Art. 10(1)) ### Third Party Duties After Receiving Data - Process data only for the purposes and conditions agreed with the user and comply with data protection law, and erase data when no longer needed unless otherwise agreed for non-personal data (Art. 6(1)) - Do not manipulate the user's choices or rights, including through user interface design (Art. 6(2)(a)) - Do not profile using the data unless necessary to provide the service requested by the user (Art. 6(2)(b)) - Do not pass data to another third party unless contractually agreed with the user and trade secret measures are preserved, and do not make data available to DMA gatekeepers (Art. 6(2)(c)-(d)) - Do not use data to build competing products, derive insights about the data holder, or harm the security of the connected product or related service (Art. 6(2)(e)-(f)) - Maintain agreed trade secret measures and do not prevent consumers from sharing the data onward (Art. 6(2)(g)-(h)) ### When Chapter III Applies (B2B Data Sharing) - Chapter III applies where, in B2B relations, a data holder is obliged under Article 5 or other applicable Union or national law to make data available to a data recipient (Art. 12(1)) - A term that excludes, derogates from, or varies the effect of Chapter III to the detriment of a party, or where applicable the user, is not binding (Art. 12(2)) ### Fair and non-discriminatory terms (Article 8) - Agree arrangements for making data available and provide it under fair, reasonable and non-discriminatory terms and conditions and in a transparent manner (Art. 8(1)) - Unfair contractual terms under Article 13 are not binding, and terms undermining user rights under Chapter II are not binding (Art. 8(2)) - Do not discriminate between comparable categories of data recipients, and provide information showing no discrimination upon a reasoned request (Art. 8(3)) - Do not provide data on an exclusive basis unless requested by the user under Chapter II (Art. 8(4)) - Do not require more information than necessary to verify compliance with agreed terms or legal obligations (Art. 8(5)) - Trade secrets do not need to be disclosed, unless Union or national law provides otherwise, including the safeguards in Art. 4(6) and Art. 5(9) (Art. 8(6)) ### Compensation rules and calculation basis (Article 9) - Compensation must be non-discriminatory and reasonable and may include a margin (Art. 9(1)) - Consider costs of making data available and relevant investments in collection and production (Art. 9(2)) - Compensation may depend on volume, format and nature of the data (Art. 9(3)) - For SME data recipients and not-for-profit research organisations without larger partners, compensation must not exceed the costs of making the data available (Art. 9(4)) - Commission shall adopt guidelines on the calculation of reasonable compensation, taking into account EDIB advice (Art. 9(5), Art. 42) - Data holder shall provide the data recipient with information setting out the basis for the calculation of the compensation in sufficient detail (Art. 9(7)) ### Dispute Settlement Bodies - Users, data holders and data recipients must have access to certified dispute settlement bodies for disputes under Art. 4(3) and Art. 4(9), Art. 5(12), and disputes about fair, reasonable and non-discriminatory and transparent data sharing (Art. 10(1)) - Customers and cloud providers must have access for disputes about rights and obligations under Articles 23 to 31 (Art. 10(4)) - Decisions must be adopted within 90 days of receipt of the request (Art. 10(9)) - Decisions are binding only where the parties explicitly consented to binding nature before the proceedings (Art. 10(12)) ### Technical protection measures and remedies (Article 11) - Data holders may apply technical protection measures, including smart contracts and encryption, to prevent unauthorised access and to ensure compliance (Art. 11(1)) - Measures must not discriminate between data recipients or hinder lawful user and third-party rights to access, retrieve, use, or share data (Art. 11(1)) - Users, third parties and data recipients must not alter or remove protection measures unless agreed by the data holder (Art. 11(1)) - Where a third party or data recipient falls within the circumstances in Art. 11(3), it must comply without undue delay with requests to erase copies, stop infringing goods or services where proportionate, inform users, and compensate harmed parties (Art. 11(2)-(3)) - Similar remedies can apply where users undermine protection measures, and users may have comparable rights where a data recipient infringes certain third-party limits (Art. 11(4)-(5)) ### Unfair Contractual Terms (B2B): Core Rules - Unilaterally imposed terms about data access and use, or liability and remedies for breach or termination of data obligations, are not binding if unfair (Art. 13(1)) - Terms reflecting mandatory Union law, or terms that would apply absent contractual regulation, are not considered unfair (Art. 13(2)) - A term is unfair if it grossly deviates from good commercial practice in data access and use, contrary to good faith and fair dealing (Art. 13(3)) - Burden of proof is on the party supplying the term to show it was not unilaterally imposed (Art. 13(6)) - If an unfair term is severable, the remaining terms of the contract stay binding (Art. 13(7)) - Cannot exclude or derogate from Article 13, and it does not apply to main subject matter or adequacy of price (Art. 13(8)-(9)) ### Unfair term examples (Article 13) - Always unfair: excluding liability for intentional acts or gross negligence, excluding remedies, or giving exclusive right to determine conformity or interpret terms (Art. 13(4)) - Presumed unfair: limiting remedies or extending liability, allowing data access or use significantly detrimental to legitimate interests, or preventing the other party from using its data (Art. 13(5)(a)-(c)) - Also presumed unfair: blocking reasonable termination, preventing copies, unreasonably short notice termination, or unilateral changes to price or substantive data-sharing conditions without valid reason and a termination right (Art. 13(5)(d)-(g)) ### Exceptional Need Overview - In exceptional need, legal-person data holders, other than public sector bodies, must provide requested data and relevant metadata upon a duly reasoned request (Art. 14) - Public emergency: exceptional need exists when the requester cannot obtain the data by alternative means in time and effectively under equivalent conditions (Art. 15(1)(a)) - Non-emergency exceptional need covers non-personal data only and requires a specific public-interest task explicitly provided for by law (Art. 15(1)(b)(i)) - Requester must have exhausted other means, including market purchase and relying on existing obligations or new legislation (Art. 15(1)(b)(ii)) - Non-emergency exceptional need does not apply to microenterprises and small enterprises (Art. 15(2)) - For official statistics, no duty to show inability to purchase where national law does not allow purchase (Art. 15(3)) - Chapter V does not affect reporting, access-to-information, or compliance verification obligations under Union or national law (Art. 16(1)) ### Request Content (Article 17(1)) - Specify the data and relevant metadata, justify the choice of data holder, and state the legal provision allocating the public-interest task (Art. 17(1)(a), Art. 17(1)(e), Art. 17(1)(h)) - Demonstrate exceptional need, explain purpose, intended use and duration, and identify other bodies and third parties expected to receive the data (Art. 17(1)(b)-(c), Art. 17(1)(f)) - Where personal data is requested, specify the safeguards and explain how the processing addresses the exceptional need (Art. 17(1)(c), Art. 17(1)(g)) - Specify, if possible, when the data are expected to be erased by all parties with access to them (Art. 17(1)(d)) - Set the deadline for making data available and the deadline for the data holder to decline or seek modification (Art. 17(1)(i), Art. 18(2)) - Make best efforts to avoid the request resulting in data holder liability for infringement of Union or national law (Art. 17(1)(j)) ### Request Formalities and Proportionality (Article 17(2)(a)-(e)) - Request must be in writing and in clear, concise and plain language understandable to the data holder (Art. 17(2)(a)) - Request must be specific and correspond to data the data holder controls, and be proportionate in granularity, volume and access frequency (Art. 17(2)(b)-(c)) - Request must respect legitimate aims of the data holder, commit to trade secret protection, and account for the cost and effort required (Art. 17(2)(d), Art. 19(3)) - Request must concern non-personal data, and only if insufficient, request personal data in pseudonymised form and set the protective measures to be taken (Art. 17(2)(e)) ### Request Routing, Publication, and Penalties (Article 17(2)(f)-(i)) - Request must inform the data holder of penalties for non-compliance (Art. 17(2)(f), Art. 40) - Public body requests are transmitted to the data coordinator for publication unless publication would create a public security risk, and Commission, ECB and Union body requests are published online (Art. 17(2)(g)-(h)) - Where personal data are requested, notify the GDPR supervisory authority, and the ECB and Union bodies inform the Commission of their requests (Art. 17(2)(i)) ### No Reuse and Limited Sharing (Article 17(3)-(4)) - Do not make Chapter V data available for reuse under the Data Governance Act or the Open Data Directive, and those instruments do not apply to Chapter V data held by public sector bodies (Art. 17(3)) - Exchange with other public sector bodies, the Commission, the ECB or Union bodies is allowed for completing the Art. 15 tasks, as specified in the request (Art. 17(4)) - Data may be made available to a third party for delegated technical inspections or other functions under a publicly available agreement, and Article 19 safeguards also apply to that third party (Art. 17(4), Art. 19) - Notify the data holder without undue delay when data is transmitted or made available under Article 17(4) (Art. 17(4)) ### Complaints and Model Template (Article 17(5)-(6)) - If the data holder considers its rights under Chapter V were infringed by transmission or making data available of data, it may lodge a complaint with the competent authority (Art. 17(5)) - The Commission will develop a model template for requests (Art. 17(6)) ### Data Holder Response - Data holders must provide data without undue delay, considering technical, organisational and legal measures (Art. 18(1)) - Data holders may decline or seek modification within 5 working days for public emergency requests and within 30 working days for other cases (Art. 18(2)) - Refusal grounds include not controlling the data, prior similar request without erasure notification, or non-compliant requests under Art. 17(1)-(2) (Art. 18(2)(a)-(c)) - If declining based on a prior request for the same purpose, indicate the identity of the earlier requesting body (Art. 18(3)) - Where personal data is included, properly anonymise unless disclosure is necessary, then pseudonymise (Art. 18(4)) - Disputes about refusal or the request are referred to the competent authority of the Member State where the data holder is established (Art. 18(5)) ### Public Sector Duties After Receiving Data - Use data only for the stated purpose, implement confidentiality and security measures, and erase when no longer necessary and notify relevant parties, unless archiving is required by transparency law (Art. 19(1)) - Do not use data or insights to develop or enhance competing connected products or related services, and do not share data for that purpose (Art. 19(2)) - Trade secret disclosure is limited to what is strictly necessary, and requesting bodies must take appropriate measures to preserve confidentiality (Art. 19(3)) - Requesting body is responsible for the security of the data it receives (Art. 19(4)) ### Compensation Rules - Public emergency data is provided free of charge by data holders other than micro and small enterprises, and public acknowledgement may be required if requested (Art. 20(1)) - For non-emergency exceptional need, data holders are entitled to fair compensation covering costs and a reasonable margin, and on request provide the basis for the calculation (Art. 20(2)) - Micro and small enterprises may claim compensation under the non-emergency route (Art. 20(3)) - No compensation is due for official statistics where purchasing data is not allowed by national law, and Member States notify the Commission where purchase is not allowed (Art. 20(4)) - Disputes about compensation can be brought to the competent authority (Art. 20(5)) ### Sharing With Researchers and Statistical Bodies (Article 21) - Requesting bodies may share Chapter V data for compatible scientific research or analytics, and with national statistical institutes and Eurostat for official statistics (Art. 21(1)) - Recipients must act not-for-profit or under a public-interest mission recognised in law, and must not be significantly influenced by commercial undertakings likely to lead to preferential access to results (Art. 21(2)) - Recipients must follow the no reuse rule and the Article 19 obligations (Art. 21(3), Art. 17(3), Art. 19) - Recipients may keep the data for up to six months after erasure by the requesting body (Art. 21(4)) - Before sharing, notify the data holder with identity, purpose, usage period, and measures taken, and the data holder may complain if it disagrees (Art. 21(5)) ### Cross-Border Cooperation (Article 22) - Public sector bodies, the Commission, the ECB and Union bodies cooperate and assist one another to apply Chapter V consistently (Art. 22(1)-(2)) - Before requesting data from a data holder in another Member State, notify the competent authority in the data holder's Member State, and that authority examines the request (Art. 22(3)) - After examination, the authority transmits the request and may advise cooperation to reduce burden, or rejects the request on substantiated grounds (Art. 22(4)) - Requester takes into account the authority's advice and grounds before further action, including resubmission (Art. 22(4)) ### Removing Obstacles and Scope - Do not impose and remove pre-commercial, commercial, technical, contractual and organisational obstacles that inhibit switching, porting, functional equivalence, and unbundling where feasible (Art. 23) - Obstacles include contract termination after notice and successful switching, porting exportable data and digital assets including after free-tier, achieving functional equivalence, and unbundling where feasible (Art. 23(a)-(e)) - Provider responsibilities apply only to the services, contracts and commercial practices of the source provider (Art. 24) ### Contract: Switching Process Minimum Clauses (Article 25) - Switching rights and obligations must be in a written contract provided before signing, in a form that can be stored and reproduced (Art. 25(1)) - Contract must allow switching or porting without undue delay and no later than the 30 calendar day transitional period after the notice period (Art. 25(2)(a)) - During the transitional period: provide reasonable assistance and maintain continuity (Art. 25(2)(a)(i)-(ii)) - Also: inform known continuity risks and maintain a high level of security during transfer and retrieval (Art. 25(2)(a)(iii)-(iv)) - Contract must support the customer's exit strategy, including by providing all relevant information (Art. 25(2)(b)) - Contract must specify termination and customer notification after successful switching, or after the notice period if the customer chooses erasure (Art. 25(2)(c)) - Maximum notice period to initiate switching must not exceed two months (Art. 25(2)(d)) ### Contract: Data Scope, Retrieval, Erasure, Charges (Article 25) - Contract must specify all categories of data and digital assets that can be ported, including at minimum all exportable data (Art. 25(2)(e)) - Provider may exempt internal-functioning data categories where trade secret breach risk exists, but exemptions must not impede or delay switching (Art. 25(2)(f), Art. 23) - Provide a minimum retrieval period of at least 30 calendar days after the transitional period, and guarantee full erasure after the retrieval period or an alternative agreed later period once switching is completed (Art. 25(2)(g)-(h)) - Contract must state any switching charges that may be imposed under Article 29 (Art. 25(2)(i)) ### Customer Choices and Transitional Period Extensions (Article 25(3)-(5)) - At the end of the maximum notice period, customer may choose: switch to another provider, switch to on-premises, or erase its exportable data and digital assets (Art. 25(3)) - If the 30-day transitional period is technically unfeasible, notify the customer within 14 working days, justify, and propose an alternative transitional period up to seven months, with continuity ensured (Art. 25(4)) - Customer has the right to extend the transitional period once, for a period it considers more appropriate (Art. 25(5)) ### Information and Cooperation - Provide procedures for switching and porting, including methods, formats, restrictions and known technical limitations (Art. 26(a)) - Provide an up-to-date online register listing data structures, formats, relevant standards and open interoperability specifications for exportable data (Art. 26(b)) - All parties, including destination providers, must cooperate in good faith to make switching effective and maintain continuity (Art. 27) ### Transparency on International Access and Contract Listing (Art. 28) - Contracts must list the websites where the Article 28(1) information is published (Art. 28(2)) - Publish the jurisdiction governing the ICT infrastructure used for processing each service (Art. 28(1)(a)) - Publish a general description of measures to prevent third-country governmental access or transfer of non-personal data held in the Union where it would conflict with Union or Member State law (Art. 28(1)(b)) - Keep those websites up to date and aligned with the service as operated (Art. 28(1)-(2)) ### Switching charges and data egress charges (Article 29) - From 12 January 2027, providers must not impose any switching charges on the customer for the switching process (Art. 29(1)) - Between 11 January 2024 and 12 January 2027, providers may impose reduced switching charges, limited to costs directly linked to the switching process (Art. 29(2)-(3)) - Before contract, disclose standard service fees, early termination penalties, and any reduced switching charges that might apply (Art. 29(4)) - Provide information on highly complex or costly switching scenarios, or where switching is impossible without significant interference (Art. 29(5)-(6)) - Commission may establish a monitoring mechanism for switching charges via delegated acts (Art. 29(7)) - Competent authorities are tasked with ensuring that switching charges are withdrawn when required (Art. 37(5)(i), Art. 29) - Technical compatibility obligations can start at least 12 months after references to standards or common specifications are published in the central Union standards repository (Art. 30(3), Art. 35(8)) ### Technical Switching Interfaces - Infrastructure-only services must take reasonable measures to help customers achieve functional equivalence after switching and provide capabilities, information, support and tools (Art. 30(1)) - Other services must provide open interfaces free of charge and equally to customers and destination providers, with sufficient information for portability and interoperability (Art. 30(2)) ### Standards and Export Requirements (Article 30(3)-(5)) - Ensure compatibility with common specifications or harmonised standards at least 12 months after references are published in the central Union standards repository (Art. 30(3), Art. 35(8)) - Update the online register to reflect those standards or common specifications (Art. 30(4), Art. 26(b)) - If no standards or common specifications are published for a service type, export all exportable data in a structured, commonly used and machine-readable format on customer request (Art. 30(5)) ### Limits and Exemptions (Article 30(6), Article 31) - No obligation to develop new technologies or services, or disclose or transfer digital assets protected by intellectual property rights or constituting a trade secret, or compromise security and integrity of service (Art. 30(6)) - Custom-built services not offered at broad commercial scale and non-production test versions are exempt from certain Chapter VI obligations (Art. 31(1)-(2)) - Before contract, inform prospective customers which Chapter VI obligations do not apply for services under Article 31 (Art. 31(3)) ### International Governmental Access and Transfer - Take adequate technical, organisational and legal measures to prevent third-country governmental access or transfer of non-personal data held in the Union where it would conflict with Union or Member State law (Art. 32(1)) - Third-country decisions requiring access or transfer are enforceable only when based on an international agreement such as a mutual legal assistance treaty (Art. 32(2)) - Without an international agreement, access or transfer can occur only under specific conditions covering proportionality, judicial review, and consideration of EU legal interests (Art. 32(3)) - If conditions apply, provide the minimum data permissible and inform the customer before complying, except for justified law enforcement secrecy (Art. 32(4)-(5)) ### Opinion, One-Month Rule, and EDIB Guidelines - The addressee may ask the opinion of the relevant national body or authority for international legal cooperation to assess whether the Article 32(3) conditions are met (Art. 32(3)) - Do this especially where the request involves trade secrets, commercially sensitive data, intellectual property rights, or re-identification risks (Art. 32(3)) - That national body or authority may consult the Commission (Art. 32(3)) - If the addressee considers the request may affect Union or Member State national security or defence interests, it shall request an opinion on whether the data requested concerns such interests (Art. 32(3)) - If no reply is received within one month, or if the opinion concludes the conditions are not met, the addressee may reject the request for transfer or access on those grounds (Art. 32(3)) - The EDIB shall advise and assist the Commission in developing guidelines on assessing whether the Article 32(3) conditions are met (Art. 32(3), Art. 42) ### Data Spaces Interoperability Requirements - Describe dataset content, use restrictions, licences, collection methodology, data quality and uncertainty to enable find, access and use, and where applicable in machine-readable format (Art. 33(1)(a)) - Describe data structures, formats, vocabularies, classification schemes, taxonomies and code lists in a publicly available and consistent manner (Art. 33(1)(b)) - Describe APIs and other technical access means, terms of use, and quality of service to enable automated access and transmission, including real-time where feasible (Art. 33(1)(c)) - Where applicable, provide means enabling interoperability of tools automating data sharing agreements, including smart contracts (Art. 33(1)(d)) ### Data Space Standards and Common Specifications - Commission may adopt delegated acts to further specify the Article 33(1) essential requirements, taking EDIB advice into account (Art. 33(2), Art. 42) - Harmonised standards and common specifications can create a presumption of conformity for the requirements they cover (Art. 33(3), Art. 33(8)) - Commission may request harmonised standards and, where standards are unavailable or insufficient, adopt common specifications by implementing acts (Art. 33(4)-(7)) - Commission may adopt guidelines on interoperable frameworks for common European data spaces (Art. 33(11)) ### Parallel Use of Data Processing Services - Switching-related requirements also apply to facilitate interoperability for the purposes of in-parallel use of data processing services (Art. 34(1)) - Providers may impose data egress charges for parallel use only to pass through egress costs, without exceeding those costs (Art. 34(2)) ### Interoperability Standards for Data Processing Services - Interoperability specs and harmonised standards should enable interoperability for the same service type, enhance portability of digital assets, and facilitate functional equivalence where feasible (Art. 35(1)) - They should not harm security and integrity and should allow technical advances and innovation (Art. 35(1)(d)-(e)) - Standards should address transport, syntactic, semantic, behavioural and policy interoperability, plus data and application portability aspects (Art. 35(2)) - Commission may request harmonised standards, adopt common specifications, and publish references in a central Union standards repository (Art. 35(4)-(5), Art. 35(8)) ### Smart Contracts for Data Sharing Agreements - Smart contracts used to execute data sharing agreements must meet essential requirements on robustness, access control, safe termination, auditability, and consistency with the executed agreement (Art. 36(1)) - Vendor or deployer must perform a conformity assessment and issue an EU declaration of conformity and is responsible for compliance (Art. 36(2)-(3)) - Harmonised standards and common specifications can create a presumption of conformity (Art. 36(4)-(6)) ### Competent Authorities and Legal Representative - Each Member State designates competent authorities for enforcement, and if more than one is designated, a data coordinator is appointed (Art. 37(1)-(2)) - GDPR supervisory authorities monitor Data Act compliance for personal data aspects, and the EDPS monitors EU institutions where relevant (Art. 37(3)) - Competent authorities handle complaints and investigations, cooperate cross-border, ensure switching charges withdrawal, and examine Chapter V requests (Art. 37(5)(b)-(j)) - Competence is the Member State where the entity is established. If the entity is established in more than one Member State, competence is the Member State of its main establishment, meaning the head office or registered office from which principal financial functions and operational control are exercised (Art. 37(10)) - Any entity falling within scope that makes connected products available or offers services in the Union, and which is not established in the Union, shall designate a legal representative in one Member State (Art. 37(11)) - The legal representative is mandated to be addressed by competent authorities in addition to or instead of the entity, and must cooperate and demonstrate compliance actions upon request (Art. 37(12)) - Such an entity is considered to be under the competence of the Member State where its legal representative is located. Until a legal representative is designated, it can be under the competence of all Member States, depending on the facts (Art. 37(13)) ### Complaints and Judicial Remedies - Natural and legal persons can lodge complaints in their Member State of habitual residence, place of work, or establishment (Art. 38(1)) - Data coordinators must provide information on how to lodge complaints, and authorities must inform complainants of progress and decisions (Art. 38(1)-(2)) - Authorities cooperate to handle complaints effectively, including via electronic information exchange, including cross-border cases (Art. 38(3)) - There is a right to an effective judicial remedy against legally binding decisions, and when authorities fail to act (Art. 39) ### Penalties - Member States set penalties for infringements and must ensure they are effective, proportionate and dissuasive (Art. 40(1)) - Penalty rules must be notified to the Commission by 12 September 2025 (Art. 40(2)) - When imposing penalties, Member States must take into account EDIB recommendations (Art. 40(3)) - Non-exhaustive penalty criteria include nature, gravity, scale and duration; mitigation or remedy actions; prior infringements; and other aggravating or mitigating factors (Art. 40(3)) - Also consider financial benefits gained or losses avoided and annual EU turnover (Art. 40(3)) - For certain infringements in Chapters II, III and V, GDPR supervisory authorities can impose administrative fines under GDPR Article 83 up to Art. 83(5) amounts (Art. 40(4)) - For certain Chapter V infringements by EU institutions, the EDPS can impose fines under Regulation (EU) 2018/1725 (Art. 40(5)) ### Model Contractual Terms and Cloud Clauses - Commission will develop and recommend non-binding model contractual terms on data access and use, including compensation and trade secret protection, before 12 September 2025 (Art. 41) - Commission will also develop and recommend non-binding standard contractual clauses for cloud computing contracts, before 12 September 2025 (Art. 41) ### Database Right Limitation - The sui generis database right does not apply when data is obtained from or generated by a connected product or related service in scope, especially for user access and third-party sharing under Articles 4 and 5 (Art. 43) ### Consumer Protection and Representative Actions - The Data Act is added to the list of laws enforceable under the Consumer Protection Cooperation Regulation (EU) 2017/2394 (Art. 47) - The Data Act is added to Annex I of Directive (EU) 2020/1828 on representative actions for the protection of consumers' collective interests (Art. 48) ### Delegated Acts and Committee Procedure - Commission delegated powers for Article 29(7) and Article 33(2) apply from 11 Jan 2024 for an indeterminate period (Art. 45(2)) - The European Parliament or the Council can revoke the delegation; delegated acts take effect only if no objection is raised within 3 months (extendable by 3 months) (Art. 45(3), Art. 45(6)) - The Commission is assisted by the Committee established by Regulation (EU) 2022/868, under Regulation (EU) No 182/2011 (Art. 46) ### European Data Innovation Board (EDIB) role (Article 42) - EDIB supports consistent application of the Data Act by advising the Commission on enforcement practice for Chapters II, III, V and VII (Art. 42(a)) - EDIB facilitates cooperation between competent authorities, including methods for cross-border information exchange and coordination on penalties (Art. 42(b)) - EDIB advises the Commission on standards requests, implementing acts, delegated acts, and data space interoperability frameworks (Art. 42(c)) ### Interaction With Other EU Data Access Laws - Specific Union acts with data access and sharing obligations that entered into force on or before 11 Jan 2024 remain unaffected, including B2B, B2C and exceptional B2G regimes (Art. 44(1)) - Sector-specific Union law may set further requirements, including technical aspects of access, limits on certain data holder rights, and rules going beyond access and use (Art. 44(2)) - Except for Chapter V, the Data Act is without prejudice to Union and national law on data access and use for scientific research purposes (Art. 44(3)) ### Entry into Force and Application Dates - Enters into force 20 days after OJ publication; OJ publication date is 22 December 2023, so entry into force is 11 January 2024 (Art. 50) - Applies from 12 September 2025 (Art. 50) - The design obligation in Article 3(1) applies to connected products and related services placed on the market after 12 September 2026 (Art. 50) - Chapter III applies in relation to statutory obligations to make data available that enter into force after 12 September 2025 (Art. 50) - Chapter IV applies to contracts concluded after 12 September 2025 (Art. 50) - From 12 September 2027, Chapter IV also applies to contracts concluded on or before 12 September 2025 that are of indefinite duration, or due to expire at least 10 years from 11 January 2024 (Art. 50) ## Possible Outcomes ### [RESULT] Out of Data Act Scope The Data Act does not apply to this scenario - None of the categories in Article 1(3) apply to your scenario, so the Data Act does not apply to you for that scenario. - If your situation changes, for example you place connected products on the Union market or provide data processing services to customers in the Union, reassess scope. ### [NEXT] Data Act Compliance Checklist Map your roles, data, and contracts, then implement the relevant chapters - Identify your roles: connected product or related service manufacturer or provider, data holder, data recipient, third party recipient, cloud provider, data space participant, or smart contract vendor or deployer - Inventory product data, related service data and metadata, and ensure you can provide readily available data in structured and machine-readable formats - Implement user access and sharing workflows, with clear safeguards for security and trade secrets - Update contracts for fair, reasonable and non-discriminatory terms, compensation, trade secret measures, and cloud switching clauses where relevant - Prepare playbooks for exceptional-need requests and for third-country access requests affecting non-personal data - Track application dates and Member State enforcement guidance ## Data Act Timeline | Date | Event | Reference | | --- | --- | --- | | 2020-02-19 | European Strategy for Data published | COM(2020) 66 | | 2022-02-23 | Commission proposal for the Data Act published | COM(2022) 68 | | 2023-06-27 | Council and Parliament reach a provisional agreement (political agreement) | Council press release | | 2023-11-09 | European Parliament position adopted | OJ L 2023/2854 note (4) | | 2023-11-27 | Council decision adopted | OJ L 2023/2854 note (4) | | 2023-12-13 | Regulation (EU) 2023/2854 dated 13 December 2023 | Reg. 2023/2854 | | 2023-12-22 | Published in the Official Journal (OJ L, 22.12.2023) | Reg. 2023/2854 | | 2024-01-11 | Enters into force (20 days after publication) | Art. 50 | | 2024-01-11 | Start of reduced switching charges period for the switching process | Art. 29(2) | | 2024-01-11 | Delegated act powers for Articles 29(7) and 33(2) begin | Art. 45(2) | | 2025-07-01 | Commission Implementing Decision on standardisation request adopted (European Trusted Data Framework) | C(2025) 4135 | | 2025-07-07 | CEN and CENELEC accept the Standardisation Request under Mandate M/614 | M/614 (CEN-CENELEC) | | 2025-09-12 | Data Act starts applying (general application date) | Art. 50 | | 2025-09-12 | Operational timing rules apply (for example user access without undue delay, B2G response windows, cloud switching contract periods) | Art. 4(1), Art. 17(1)(i), Art. 18(2), Art. 25 | | 2025-09-12 | Chapter III applies only to statutory data-sharing obligations entering into force after this date | Art. 50 | | 2025-09-12 | Chapter IV applies to contracts concluded after this date | Art. 50 | | 2025-09-12 | Deadline: Member States notify penalties rules to the Commission | Art. 40(2) | | 2025-09-12 | Deadline: Commission develops and recommends non-binding model contractual terms and non-binding standard contractual clauses for cloud contracts | Art. 41 | | 2026-03-01 | Standardisation deadline: technical specification on a data catalogue implementation framework due | C(2025) 4135 Annex I | | 2026-06-01 | Standardisation deadline: Trusted Data Transactions harmonised standards Part 1 due | C(2025) 4135 Annex I | | 2026-09-01 | Standardisation deadlines: technical specifications on semantic assets and a maturity model for Common European Data Spaces due | C(2025) 4135 Annex I | | 2026-09-12 | Article 3(1) design obligation applies to connected products and related services placed on the market after this date | Art. 50 | | 2026-11-01 | Standardisation deadline: Trusted Data Transactions harmonised standards Part 2 due | C(2025) 4135 Annex I | | 2027-01-12 | Switching charges prohibited for the switching process | Art. 29(1) | | 2027-03-01 | Standardisation deadline: European standard on a quality framework for internal data governance due | C(2025) 4135 Annex I | | 2027-05-01 | Standardisation deadline: Trusted Data Transactions harmonised standards Part 3 due | C(2025) 4135 Annex I | | 2027-09-12 | Chapter IV extends to certain contracts concluded on or before 12 Sep 2025 (indefinite duration or expiring at least 10 years from 11 Jan 2024) | Art. 50 | | 2028-09-12 | Commission evaluation due | Art. 49 | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2023-11-09 | European Parliament position adopted | Legislative History | | | 2023-11-27 | Council decision adopted | Legislative History | | | 2023-12-13 | Regulation adopted (Data Act) | Legislative History | | | 2023-12-22 | Published in Official Journal | Official Publication | | | 2024-01-11 | Entry into force | Official Publication | | | 2024-01-11 | Reduced switching charges period | Cloud Switching | Art. 29(2) | | 2024-01-11 | Delegated powers conferred | Commission Deliverables | Art. 45(2) | | 2024-09-06 | Commission publishes Data Act FAQs | Commission Deliverables | | | 2025-07-01 | Commission standardisation request (European Trusted Data Framework) | Standardisation | | | 2025-07-07 | CEN and CENELEC accept the standardisation request (Mandate M/614) | Standardisation | | | 2025-09-12 | Data Act applies | Applicability | | | 2025-09-12 | Member States notify penalties rules | Member State Duties | Art. 40(2) | | 2025-09-12 | Model contractual terms and cloud clauses deadline | Commission Deliverables | Art. 41 | | 2025-09-15 | Commission guidance on vehicle data (C/2025/5026) | Commission Deliverables | | | 2025-12-16 | Commission launches Data Act legal helpdesk | Commission Deliverables | | | 2026-01-22 | Data Act FAQs updated (v1.4) | Commission Deliverables | | | 2026-03-01 | Data catalogue technical specification deadline | Standardisation | | | 2026-06-01 | Trusted data transactions standards Part 1 deadline | Standardisation | | | 2026-09-01 | European Trusted Data Framework deliverables deadline | Standardisation | | | 2026-09-12 | Connected product access-by-design obligations | Applicability | | | 2026-11-01 | Trusted data transactions standards Part 2 deadline | Standardisation | | | 2027-01-12 | Switching charges prohibited | Cloud Switching | Art. 29(1) | | 2027-03-01 | Internal data governance quality framework standard deadline | Standardisation | | | 2027-05-01 | Trusted data transactions standards Part 3 deadline | Standardisation | | | 2027-09-12 | Chapter IV extends to older contracts | Applicability | | | 2028-09-12 | Commission evaluation report deadline | Commission Deliverables | Art. 49(1) | **Event details:** - **2023-11-09 - European Parliament position adopted**: The Regulation records the European Parliament position of 9 November 2023 in the legislative history footnote. - **2023-11-27 - Council decision adopted**: The Regulation records the Council decision of 27 November 2023 in the legislative history footnote. - **2023-12-13 - Regulation adopted (Data Act)**: Regulation (EU) 2023/2854 is adopted and signed in Strasbourg. - **2023-12-22 - Published in Official Journal**: Regulation (EU) 2023/2854 is published in the Official Journal (OJ L, 2023/2854, 22.12.2023). - **2024-01-11 - Entry into force**: The Data Act enters into force on the twentieth day following publication in the Official Journal. - **2024-01-11 - Reduced switching charges period**: From 11 January 2024 to 12 January 2027, providers of data processing services may impose reduced switching charges for the switching process. - **2024-01-11 - Delegated powers conferred**: The Commission is conferred the power to adopt delegated acts for an indeterminate period of time from 11 January 2024 for specified delegated powers under the Regulation. - **2024-09-06 - Commission publishes Data Act FAQs**: The Commission publishes Frequently Asked Questions about the Data Act to support implementation. - **2025-07-01 - Commission standardisation request (European Trusted Data Framework)**: Commission Implementing Decision of 1 July 2025 issues a standardisation request to CEN, CENELEC and ETSI in support of the Data Act (C(2025) 4135 final). - **2025-07-07 - CEN and CENELEC accept the standardisation request (Mandate M/614)**: CEN and CENELEC accept the Commission standardisation request on the European Trusted Data Framework (Mandate M/614). - **2025-09-12 - Data Act applies**: The Data Act applies from 12 September 2025. - **2025-09-12 - Member States notify penalties rules**: Member States notify the Commission of penalties rules and measures by 12 September 2025. - **2025-09-12 - Model contractual terms and cloud clauses deadline**: Before 12 September 2025, the Commission develops and recommends non-binding model contractual terms on data access and use and non-binding standard contractual clauses for cloud computing contracts. - **2025-09-15 - Commission guidance on vehicle data (C/2025/5026)**: The Commission publishes guidance on vehicle data accompanying the Data Act (OJ C, 15.9.2025). - **2025-12-16 - Commission launches Data Act legal helpdesk**: The Commission launches a Data Act Legal Helpdesk to support stakeholders with practical implementation questions. - **2026-01-22 - Data Act FAQs updated (v1.4)**: The Commission updates the Data Act FAQs page and publishes FAQs Data Act version 1.4 dated 22 January 2026. - **2026-03-01 - Data catalogue technical specification deadline**: Deadline for adoption of technical specification(s) on a data catalogue implementation framework (Annex I). - **2026-06-01 - Trusted data transactions standards Part 1 deadline**: Deadline for adoption of harmonised standards on Trusted Data Transactions Part 1: terminology, concepts and mechanisms (Annex I). - **2026-09-01 - European Trusted Data Framework deliverables deadline**: Deadline for adoption of technical specification(s) on semantic assets and technical specification(s) on a maturity model for Common European Data Spaces (Annex I). - **2026-09-12 - Connected product access-by-design obligations**: The obligation resulting from Article 3(1) applies to connected products and related services placed on the market after 12 September 2026. - **2026-11-01 - Trusted data transactions standards Part 2 deadline**: Deadline for adoption of harmonised standards on Trusted Data Transactions Part 2: trustworthiness requirements (Annex I). - **2027-01-12 - Switching charges prohibited**: From 12 January 2027, providers of data processing services shall not impose any switching charges on the customer for the switching process. - **2027-03-01 - Internal data governance quality framework standard deadline**: Deadline for adoption of the European standard on a quality framework for internal data governance (Annex I). - **2027-05-01 - Trusted data transactions standards Part 3 deadline**: Deadline for adoption of harmonised standards on Trusted Data Transactions Part 3: interoperability requirements (Annex I). - **2027-09-12 - Chapter IV extends to older contracts**: Chapter IV applies from 12 September 2027 to certain contracts concluded on or before 12 September 2025 (indefinite duration or expiring at least 10 years from 11 January 2024). - **2028-09-12 - Commission evaluation report deadline**: By 12 September 2028, the Commission carries out an evaluation of the Regulation and submits a report to the European Parliament and the Council. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu-data-act-scope-decision-map --- --- title: "Regulatory Universal Timeline - 38 Source Timelines and 1297 Compliance Events" canonical_url: "https://www.sorena.io/artifacts/global/regulatory-universal-timelines" source_url: "https://www.sorena.io/artifacts/global/regulatory-universal-timelines" author: "Sorena AI" description: "Use Sorena AI Regulatory Universal Timeline to review 38 source timelines and 1297 dated compliance events in one view." published_at: "2026-02-12" updated_at: "2026-02-12" keywords: - "regulatory universal timeline" - "compliance timeline" - "compliance calendar" - "regulatory deadlines" - "deadline planning" - "governance reporting" - "PNG timeline export" - "Sorena AI timeline" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Regulatory Universal Timeline - 38 Source Timelines and 1297 Compliance Events Use Sorena AI Regulatory Universal Timeline to review 38 source timelines and 1297 dated compliance events in one view. ![Regulatory Universal Timeline - 38 Source Timelines and 1297 Compliance Events](https://cdn.sorena.io/cheatsheets/sorena-ai-regulatory-universal-timeline-small.png) *Universal Timeline* *Merged Local Dataset* ## Regulatory Universal Timeline This page merges 38 source timelines and 1297 dated events from the local artifacts catalog into one interactive compliance timeline. Filter by source label, inspect milestone detail, zoom from 1973 to 2050, and export the current view as a PNG snapshot. The viewer is built from local timeline JSON files. Labels are normalized from source keys and selected regulation identifiers so teams can compare timing across frameworks without rewriting the source events. [Create my custom view](/solutions/assessment.md) | [Talk to an expert](/contact.md) By Sorena AI | Updated Mar 2026 | No sign-up required **Key highlights:** 38 source timelines | PNG export and filters ## Topic Guides - [Framework Overlap and Evidence Reuse for Regulatory Universal Timeline](/artifacts/global/regulatory-universal-timelines/framework-overlap-and-evidence-reuse.md): Use Sorena AI Regulatory Universal Timeline to spot deadline overlap. - [How to Use Regulatory Universal Timelines for Execution Planning](/artifacts/global/regulatory-universal-timelines/how-to-use.md): Step by step guide for using Sorena AI Regulatory Universal Timeline: source filters, category chips, event detail, zoom, minimap navigation. - [Regulatory Universal Timeline Compliance Calendar Guide](/artifacts/global/regulatory-universal-timelines/compliance-calendar.md): Build an internal compliance calendar from Sorena AI Regulatory Universal Timeline by converting external events into owned milestones, collision windows. - [Regulatory Universal Timeline Export and Sharing Guide](/artifacts/global/regulatory-universal-timelines/export-and-sharing.md): Share Sorena AI Regulatory Universal Timeline correctly: browser generated PNG export, filter context, version notes, leadership reporting packs. - [Regulatory Universal Timeline Glossary](/artifacts/global/regulatory-universal-timelines/glossary.md): Glossary for Sorena AI Regulatory Universal Timeline covering source timelines, category chips, milestone events, ranged events, export snapshots. - [What Is Included in Regulatory Universal Timeline](/artifacts/global/regulatory-universal-timelines/what-is-included.md): Review current coverage for Sorena AI Regulatory Universal Timeline: which local timeline files are merged, what event fields are included. ## Universal timeline *38 source timelines* Use category chips, zoom controls, minimap navigation, and event detail to review the current merged dataset. The current build spans 1973 through 2050 and includes 339 milestone events. ## Merged compliance timeline viewer The viewer auto-builds from local timeline datasets. Use source and category filters to isolate a framework, compare overlapping deadlines, click an event for detail, and export the current state for governance or audit reporting. ## Move Regulatory Universal Timeline into live planning Regulatory Universal Timeline should be the shared entry point for your team. Route execution into Research Copilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. [Open Research Copilot](/solutions/research-copilot.md) [Open SSOT](/solutions/ssot.md) ## EU NIS2 Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2020-12-16 | Commission publishes NIS2 proposal | Legislative History | COM(2020) 823 | | 2021-12-03 | Council agrees its position | Legislative History | | | 2022-05-13 | Political agreement reached | Legislative History | | | 2022-07-13 | ITRE committee adopts agreed text | Legislative History | | | 2022-11-10 | Parliament plenary adoption | Legislative History | | | 2022-11-28 | Council formal adoption | Legislative History | | | 2022-12-14 | Final act signed by co-legislators | Official Publication | | | 2022-12-27 | Published in Official Journal | Official Publication | OJ L 333, 27.12.2022 | | 2023-01-16 | Entry into force | Official Publication | | | 2023-07-17 | Commission deadline for Article 4 guidelines | Commission Deliverables | Art. 4(3) | | 2023-09-14 | Guidelines on Article 3(4) published | Commission Deliverables | 2023/C 324/02 | | 2023-09-18 | Guidelines on Article 4(1)-(2) published | Commission Deliverables | 2023/C 328/02 | | 2023-12-22 | Corrigendum: Article 19(1) deadline wording | Corrigendum | Art. 19(1) | | 2024-02-01 | Cooperation Group work programme due | Cooperation & Networks | Art. 14(7) | | 2024-07-17 | EU-CyCLONe first report due | Cooperation & Networks | Art. 16(7) | | 2024-10-17 | Implementing Regulation 2024/2690 adopted | Implementing Acts | Reg. (EU) 2024/2690 | | 2024-10-17 | Transposition deadline | National Transposition | Art. 41(1) | | 2024-10-18 | Implementing Regulation 2024/2690 published in OJ | Implementing Acts | OJ L 2024/2690 | | 2024-10-18 | NIS1 repealed, NIS2 measures apply | National Transposition | Art. 44 | | 2024-11-07 | Implementing Regulation 2024/2690 enters into force | Implementing Acts | OJ L 2024/2690 | | 2025-01-17 | Registry information submission due | National Obligations | Art. 27(2) | | 2025-01-17 | Member States notify penalty rules | National Obligations | Art. 36 | | 2025-01-17 | CSIRTs network progress report due | Cooperation & Networks | Art. 15(4) | | 2025-01-17 | Peer-review methodology due | Cooperation & Networks | Art. 19(1) | | 2025-04-17 | Entity list established | National Obligations | Art. 3(3) | | 2025-04-17 | Aggregate entity data notification | National Obligations | Art. 3(5) | | 2025-06-26 | ENISA technical implementation guidance published | Cooperation & Networks | Version 1.0 | | 2026-01-20 | Commission proposes NIS2 amendment | Legislative History | COM(2026) 13 | | 2027-10-17 | Commission review of NIS2 | Commission Deliverables | Art. 40 | **Event details:** - **2020-12-16 - Commission publishes NIS2 proposal**: European Commission publishes the NIS2 proposal COM(2020) 823 final, proposing measures for a high common level of cybersecurity across the Union. - **2021-12-03 - Council agrees its position**: Council agrees its position (general approach) to start negotiations with the European Parliament. - **2022-05-13 - Political agreement reached**: Council and European Parliament reach provisional political agreement on NIS2. - **2022-07-13 - ITRE committee adopts agreed text**: EP Industry, Research and Energy (ITRE) committee adopts the agreed text after trilogue. - **2022-11-10 - Parliament plenary adoption**: European Parliament adopts NIS2 in plenary: 577 in favour, 6 against, 31 abstentions. - **2022-11-28 - Council formal adoption**: Council of the EU formally adopts NIS2. - **2022-12-14 - Final act signed by co-legislators**: NIS2 Directive signed by both co-legislators on 14 December 2022. - **2022-12-27 - Published in Official Journal**: Directive (EU) 2022/2555 published in the Official Journal of the European Union (OJ L 333, 27.12.2022). - **2023-01-16 - Entry into force**: NIS2 enters into force on the 20th day following OJ publication (16 January 2023). Member States have until 17 October 2024 to transpose. - **2023-07-17 - Commission deadline for Article 4 guidelines**: Commission deadline to provide guidelines clarifying the application of Article 4(1) and Article 4(2). - **2023-09-14 - Guidelines on Article 3(4) published**: Commission publishes Guidelines on the application of Article 3(4) with a data-collection template for establishing entity lists. - **2023-09-18 - Guidelines on Article 4(1)-(2) published**: Commission publishes Guidelines on equivalence with sector-specific Union legal acts, pursuant to Article 4(3) (deadline was 17 Jul 2023). - **2023-12-22 - Corrigendum: Article 19(1) deadline wording**: Corrigendum changes Article 19(1) deadline wording from 'on' to 'by' 17 January 2025 for the Cooperation Group peer-review methodology. - **2024-02-01 - Cooperation Group work programme due**: Cooperation Group must establish a work programme by 1 February 2024 and every two years thereafter. - **2024-07-17 - EU-CyCLONe first report due**: EU-CyCLONe must submit a report assessing its work to the European Parliament and Council by 17 July 2024 and every 18 months thereafter. - **2024-10-17 - Implementing Regulation 2024/2690 adopted**: Commission adopts Implementing Regulation (EU) 2024/2690 specifying technical and methodological requirements and incident-significance criteria for listed digital infrastructure and service providers. OJ publication 18 Oct 2024; enters into force 20 days later. - **2024-10-17 - Transposition deadline**: Member States must adopt and publish national transposition measures by 17 October 2024. Measures apply from 18 October 2024. - **2024-10-18 - Implementing Regulation 2024/2690 published in OJ**: Commission Implementing Regulation (EU) 2024/2690 is published in the Official Journal on 18 October 2024. - **2024-10-18 - NIS1 repealed, NIS2 measures apply**: Directive (EU) 2016/1148 (NIS1) is repealed with effect from 18 October 2024. National NIS2 measures apply from this date. - **2024-11-07 - Implementing Regulation 2024/2690 enters into force**: Commission Implementing Regulation (EU) 2024/2690 enters into force on the twentieth day following its Official Journal publication (published 18 October 2024). - **2025-01-17 - Registry information submission due**: Member States must require entities referred to in Article 27(1) to submit registry information to competent authorities by 17 January 2025. - **2025-01-17 - Member States notify penalty rules**: Member States must notify the Commission of their national penalty rules and enforcement measures by 17 January 2025. - **2025-01-17 - CSIRTs network progress report due**: CSIRTs network must adopt a report assessing progress in operational cooperation by 17 January 2025 and every two years thereafter. - **2025-01-17 - Peer-review methodology due**: Cooperation Group must establish the peer-review methodology and organisational aspects by 17 January 2025. - **2025-04-17 - Entity list established**: Member States must establish a list of essential and important entities (and entities providing domain name registration services) by 17 April 2025. - **2025-04-17 - Aggregate entity data notification**: Competent authorities must notify the Commission and Cooperation Group of aggregate list data (number of essential and important entities per sector) by 17 April 2025 and every two years thereafter. - **2025-06-26 - ENISA technical implementation guidance published**: ENISA publishes the NIS2 Technical Implementation Guidance (version 1.0) supporting implementation of Implementing Regulation (EU) 2024/2690. - **2026-01-20 - Commission proposes NIS2 amendment**: Commission publishes proposal to amend NIS2 (simplification and alignment). This is a proposal, not yet law. - **2027-10-17 - Commission review of NIS2**: The Commission shall review the functioning of the NIS2 Directive by 17 October 2027 and every 36 months thereafter, and submit a report to the European Parliament and Council. ## EU AI Act Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2024-01-24 | Commission Decision establishes the European AI Office | Notified bodies & governance | | | 2024-07-12 | AI Act published in the Official Journal | Legislative milestones | | | 2024-08-01 | AI Act enters into force | Legislative milestones | | | 2025-02-02 | Chapters I and II apply (including prohibited AI practices) | Prohibitions | | | 2025-07-10 | General-Purpose AI Code of Practice published | GPAI | | | 2025-07-18 | Commission adopts guidelines on GPAI obligations scope | GPAI | | | 2025-08-02 | GPAI obligations and governance provisions apply | GPAI | | | 2025-09-01 | Consultation to develop guidelines and a Code of Practice (transparent AI systems) | Transparency & labelling | | | 2025-09-26 | Consultation on serious AI incident reporting interplay | Incident reporting & post-market | | | 2025-10-01 | Chairs and vice-chairs selection | Transparency & labelling | | | 2025-11-04 | Reporting template for serious incidents (GPAI systemic risk) published | Incident reporting & post-market | | | 2025-11-05 | Kick-off plenary (start of 1st drafting round) | Transparency & labelling | | | 2025-11-17 | 1st working group meetings | Transparency & labelling | | | 2025-12-05 | Template published for public summary of GPAI training content | GPAI | | | 2025-12-17 | First draft published | Transparency & labelling | | | 2026-01-12 | Working group meetings (start of 2nd drafting round) | Transparency & labelling | | | 2026-01-21 | Workshops (working groups 1 and 2) | Transparency & labelling | | | 2026-03-01 | Second draft published (TBC) | Transparency & labelling | | | 2026-04-01 | Working group meetings (TBC) | Transparency & labelling | | | 2026-05-01 | Closing plenary and final Code of Practice published | Transparency & labelling | | | 2026-08-02 | AI Act applies (main obligations start) | Legislative milestones | | | 2026-08-02 | Commission enforcement powers for GPAI enter into application | GPAI | | | 2027-08-02 | Article 6(1) and corresponding obligations apply | High-risk AI | | | 2027-08-02 | Existing GPAI providers must comply by this date | GPAI | | **Event details:** - **2024-01-24 - Commission Decision establishes the European AI Office**: 24 January 2024: European Commission publishes the decision establishing the European AI Office. - **2024-07-12 - AI Act published in the Official Journal**: 12 July 2024: Regulation (EU) 2024/1689 is published in the Official Journal (OJ L, 12.7.2024). - **2024-08-01 - AI Act enters into force**: 1 August 2024: The EU AI Act enters into force (20 days after publication). - **2025-02-02 - Chapters I and II apply (including prohibited AI practices)**: 2 February 2025: Chapters I and II apply under the AI Act entry into force and application rules. - **2025-07-10 - General-Purpose AI Code of Practice published**: 10 July 2025: The General-Purpose AI (GPAI) Code of Practice is published as a voluntary tool to help providers meet AI Act obligations. - **2025-07-18 - Commission adopts guidelines on GPAI obligations scope**: 18 July 2025: Commission finalises its guidelines on the scope of obligations for general-purpose AI models (C(2025) 5045 final). - **2025-08-02 - GPAI obligations and governance provisions apply**: 2 August 2025: Chapter V (general-purpose AI) and selected governance provisions start to apply (per Article 113). - **2025-09-01 - Consultation to develop guidelines and a Code of Practice (transparent AI systems)**: September 2025: Consultation to develop guidelines and a Code of Practice on transparent AI systems, plus a call for expression of interest to participate. - **2025-09-26 - Consultation on serious AI incident reporting interplay**: 26 September 2025: Consultation referenced alongside serious incident reporting guidance and templates for AI incidents. - **2025-10-01 - Chairs and vice-chairs selection**: October 2025: Eligibility checks and selection of applications for chairs and vice-chairs. - **2025-11-04 - Reporting template for serious incidents (GPAI systemic risk) published**: 4 November 2025: Commission publishes a reporting template for serious incidents involving general-purpose AI models with systemic risk. - **2025-11-05 - Kick-off plenary (start of 1st drafting round)**: 5 November 2025: Kick-off plenary; start of the first drafting round. - **2025-11-17 - 1st working group meetings**: 17-18 November 2025: First working group meetings. - **2025-12-05 - Template published for public summary of GPAI training content**: 5 December 2025: Commission publishes an explanatory notice and a template for the public summary of training content (Article 53(1)(d)). - **2025-12-17 - First draft published**: 17 December 2025: Publication of the first draft. - **2026-01-12 - Working group meetings (start of 2nd drafting round)**: 12 and 14 January 2026: Working group meetings; start of the second drafting round. - **2026-01-21 - Workshops (working groups 1 and 2)**: 21-22 January 2026: Workshops for working groups 1 and 2. - **2026-03-01 - Second draft published (TBC)**: March 2026 (TBC): Publication of the second draft; start of the final drafting round. - **2026-04-01 - Working group meetings (TBC)**: April 2026 (TBC): Working group meetings. - **2026-05-01 - Closing plenary and final Code of Practice published**: May-June 2026: Closing plenary; publication of the final Code of Practice. - **2026-08-02 - AI Act applies (main obligations start)**: 2 August 2026: The AI Act applies in general (per Article 113). - **2026-08-02 - Commission enforcement powers for GPAI enter into application**: 2 August 2026: Commission enforcement powers for obligations on providers of GPAI models enter into application (including fines). - **2027-08-02 - Article 6(1) and corresponding obligations apply**: 2 August 2027: Article 6(1) and corresponding obligations apply (per Article 113). - **2027-08-02 - Existing GPAI providers must comply by this date**: By 2 August 2027: Providers of GPAI models placed on the market before 2 August 2025 must comply, per Commission guidance. ## EU DORA Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2022-12-14 | DORA adopted | Legislative History | Reg. (EU) 2022/2554 (of 14 December 2022) | | 2022-12-27 | DORA published in Official Journal | Official Publication | OJ L 333, 27.12.2022 | | 2022-12-27 | Alignment Directive (EU) 2022/2556 published | Official Publication | | | 2023-01-16 | DORA enters into force | Official Publication | Art. 64 | | 2023-06-19 | ESAs first batch public consultation opens | ESAs Mandates & Deliverables | | | 2023-07-17 | Commission PSD2 review report deadline (cyber resilience of payment systems) | Commission Mandates & Reviews | Art. 58(2) | | 2023-09-11 | ESAs first batch public consultation closes | ESAs Mandates & Deliverables | | | 2023-12-08 | ESAs second batch public consultation opens | ESAs Mandates & Deliverables | | | 2024-01-17 | Deadline: ESAs submit first wave draft RTS/ITS to the Commission | ESAs Mandates & Deliverables | Arts. 15, 16(3), 18(4), 28(9)-(10) | | 2024-03-04 | ESAs second batch public consultation closes | ESAs Mandates & Deliverables | | | 2024-05-30 | Delegated Regs. 2024/1502 and 2024/1505 published in OJ | Delegated & Implementing Acts (OJ) | OJ L, 2024/1502 and 2024/1505, 30.5.2024 | | 2024-06-25 | Delegated Regs. 2024/1772, 2024/1773, 2024/1774 published in OJ | Delegated & Implementing Acts (OJ) | OJ L, 2024/1772, 2024/1773, 2024/1774, 25.6.2024 | | 2024-07-17 | Deadline: ESAs submit draft RTS/ITS for incident reporting content and templates | ESAs Mandates & Deliverables | Art. 20 | | 2024-07-17 | Deadline: ESAs submit draft RTS for TLPT (TIBER-EU framework) | ESAs Mandates & Deliverables | Art. 26(11) | | 2024-07-17 | Deadline: ESAs develop guidelines on annual costs and losses from major incidents | ESAs Mandates & Deliverables | Art. 11(11) | | 2024-07-17 | Deadline: ESAs issue guidelines on oversight cooperation and information exchange | ESAs Mandates & Deliverables | Art. 32(7) | | 2024-07-17 | Deadline: ESAs submit draft RTS on subcontracting assessments | ESAs Mandates & Deliverables | Art. 30(5) | | 2024-07-17 | Deadline: ESAs submit draft RTS enabling the conduct of oversight activities | ESAs Mandates & Deliverables | Art. 41(2) | | 2024-07-17 | ESAs publish second batch of policy products (incl. TLPT RTS) | ESAs Mandates & Deliverables | | | 2024-07-17 | Deadline: Commission delegated act on further criteria for critical ICT third-party designation | Commission Mandates & Reviews | Art. 31(6) | | 2024-07-17 | Deadline: Commission delegated act on oversight fees | Commission Mandates & Reviews | Art. 43(2) | | 2024-11-29 | Oversight Forum mandate (JC_24_93) | CTPP Oversight | | | 2024-12-02 | Implementing Reg. 2024/2956 published in OJ (register templates) | Register of Information | Reg. (EU) 2024/2956 | | 2025-01-16 | Lead Overseer applies sub-criterion for CTPP designation (sub-criterion 1.4) | CTPP Oversight | Delegated Reg. (EU) 2024/1502 Art. 7 | | 2025-01-17 | DORA applies | Applicability | Art. 64 | | 2025-01-17 | EU Hub feasibility report due | ESAs Mandates & Deliverables | Art. 21(3) | | 2025-01-17 | ESAs publish feasibility report on EU Hub centralisation (JC 2024 108) | ESAs Mandates & Deliverables | | | 2025-01-17 | Member States notify penalty and criminal-law measures | National Obligations | Art. 53 | | 2025-01-17 | Application date - Guidelines on oversight cooperation and information exchange | Guidelines (Level 3) | | | 2025-02-20 | Delegated Reg. 2025/301 published in OJ (incident reporting RTS) | Delegated & Implementing Acts (OJ) | OJ L, 2025/301, 20.2.2025 | | 2025-02-20 | Implementing Regulation 2025/302 - incident reporting templates (ITS) | Delegated & Implementing Acts (OJ) | OJ L, 2025/302, 20.2.2025 | | 2025-03-06 | Corrigendum (01) to Delegated Reg. 2024/1774 | Corrigendum | | | 2025-05-15 | Corrigendum (02) to Delegated Reg. 2024/1774 | Corrigendum | | | 2025-05-19 | Application date - Guidelines on costs/losses estimation | Guidelines (Level 3) | | | 2025-06-18 | Delegated Reg. 2025/1190 published in OJ (TLPT RTS) | Delegated & Implementing Acts (OJ) | OJ L, 2025/1190, 18.6.2025 | | 2025-07-02 | Delegated Reg. 2025/532 published in OJ (subcontracting assessments) | Delegated & Implementing Acts (OJ) | Reg. (EU) 2025/532 | | 2025-09-11 | Corrigendum to Implementing Reg. 2025/302 (incident templates) | Corrigendum | | | 2025-09-12 | Corrigendum to Delegated Reg. 2025/301 (non-EN) | Corrigendum | | | 2025-09-19 | Corrigendum to Implementing Reg. 2024/2956 (register templates) | Corrigendum | | | 2025-11-18 | First list of designated CTPPs published | CTPP Oversight | | | 2026-01-17 | Commission review on auditors and audit firms due | Commission Mandates & Reviews | Art. 58(3) | | 2028-01-17 | Commission review of DORA due | Commission Mandates & Reviews | Art. 58(1) | **Event details:** - **2022-12-14 - DORA adopted**: Regulation (EU) 2022/2554 on digital operational resilience for the financial sector is adopted by the European Parliament and the Council (date of the act: 14 December 2022). - **2022-12-27 - DORA published in Official Journal**: Regulation (EU) 2022/2554 is published in the Official Journal of the European Union (OJ L 333, 27.12.2022). - **2022-12-27 - Alignment Directive (EU) 2022/2556 published**: Directive (EU) 2022/2556 is published, aligning sectoral directives with DORA; Member States must transpose it by 17 January 2025. - **2023-01-16 - DORA enters into force**: DORA enters into force on the twentieth day following its publication in the Official Journal (27 December 2022 -> 16 January 2023). - **2023-06-19 - ESAs first batch public consultation opens**: First batch of DORA policy products consultation window opens. - **2023-07-17 - Commission PSD2 review report deadline (cyber resilience of payment systems)**: Within the PSD2 review context, the Commission must submit a report to the European Parliament and Council no later than 17 July 2023 assessing the need for increased cyber resilience of payment systems and payment-processing activities. - **2023-09-11 - ESAs first batch public consultation closes**: Closure of first batch consultation window. - **2023-12-08 - ESAs second batch public consultation opens**: Second batch of DORA policy mandates consultation opens. - **2024-01-17 - Deadline: ESAs submit first wave draft RTS/ITS to the Commission**: Deadline for ESAs (through the Joint Committee) to submit several draft RTS/ITS to the Commission, including RTS on ICT risk management, RTS on the simplified ICT risk management framework, RTS on incident classification (materiality thresholds), and draft ITS/RTS related to the register of information and ICT third-party risk policy. - **2024-03-04 - ESAs second batch public consultation closes**: Closure of second batch consultation window. - **2024-05-30 - Delegated Regs. 2024/1502 and 2024/1505 published in OJ**: Delegated Regulations (EU) 2024/1502 (designation criteria for critical ICT third-party service providers; adopted 22 February 2024) and 2024/1505 (oversight fees; adopted 22 February 2024) are published in the Official Journal. - **2024-06-25 - Delegated Regs. 2024/1772, 2024/1773, 2024/1774 published in OJ**: Delegated Regulations (EU) 2024/1772 (incident classification), 2024/1773 (policy content for ICT third-party contractual arrangements supporting critical/important functions) and 2024/1774 (ICT risk management tools/methods and simplified framework) are published in the Official Journal (all adopted 13 March 2024). - **2024-07-17 - Deadline: ESAs submit draft RTS/ITS for incident reporting content and templates**: Deadline for ESAs (through the Joint Committee, in consultation with ENISA and the ECB) to submit to the Commission draft RTS on incident-report content and time limits, and draft ITS on standard forms/templates/procedures for reporting major ICT-related incidents and notifying significant cyber threats. - **2024-07-17 - Deadline: ESAs submit draft RTS for TLPT (TIBER-EU framework)**: Deadline for ESAs (in agreement with the ECB) to submit to the Commission draft RTS specifying criteria and detailed requirements for threat-led penetration testing (TLPT), including methodology phases, internal testers, and cooperation/mutual recognition aspects. - **2024-07-17 - Deadline: ESAs develop guidelines on annual costs and losses from major incidents**: Deadline for ESAs (through the Joint Committee) to develop common guidelines on the estimation of aggregated annual costs and losses caused by major ICT-related incidents. - **2024-07-17 - Deadline: ESAs issue guidelines on oversight cooperation and information exchange**: Deadline for ESAs to issue guidelines on cooperation between ESAs and competent authorities under the CTPP oversight framework, including task allocation/execution procedures and information-exchange details needed for follow-up of Lead Overseer recommendations. - **2024-07-17 - Deadline: ESAs submit draft RTS on subcontracting assessments**: Deadline for ESAs (through the Joint Committee) to submit to the Commission draft RTS specifying further which elements a financial entity needs to determine and assess when subcontracting ICT services supporting critical or important functions. - **2024-07-17 - Deadline: ESAs submit draft RTS enabling the conduct of oversight activities**: Deadline for ESAs (through the Joint Committee) to submit to the Commission draft RTS specifying harmonised conditions enabling the conduct of oversight activities for critical ICT third-party service providers (including information requests, reporting, and Joint Examination Team arrangements). - **2024-07-17 - ESAs publish second batch of policy products (incl. TLPT RTS)**: ESAs publish the second batch of DORA policy products, including the TLPT RTS and the draft RTS/ITS for incident reporting. - **2024-07-17 - Deadline: Commission delegated act on further criteria for critical ICT third-party designation**: Deadline for the Commission to adopt a delegated act supplementing DORA by specifying further the criteria for the designation of ICT third-party service providers as critical for financial entities (implemented via Delegated Regulation (EU) 2024/1502 of 22 February 2024; OJ publication 30 May 2024). - **2024-07-17 - Deadline: Commission delegated act on oversight fees**: Deadline for the Commission to adopt a delegated act determining the amount of the oversight fees to be paid by critical ICT third-party service providers and the way those fees are to be paid (implemented via Delegated Regulation (EU) 2024/1505 of 22 February 2024; OJ publication 30 May 2024). - **2024-11-29 - Oversight Forum mandate (JC_24_93)**: Mandate of the Oversight Forum as a Joint Committee Sub-Committee of the European Supervisory Authorities (JC 2024 93, dated 29 November 2024). - **2024-12-02 - Implementing Reg. 2024/2956 published in OJ (register templates)**: Implementing Regulation (EU) 2024/2956 is published, laying down implementing technical standards establishing standard templates for the register of information. - **2025-01-16 - Lead Overseer applies sub-criterion for CTPP designation (sub-criterion 1.4)**: Under Delegated Regulation (EU) 2024/1502, the Lead Overseer applies sub-criterion 1.4 for the criticality assessment of ICT third-party service providers as of 16 January 2025. - **2025-01-17 - DORA applies**: DORA applies from 17 January 2025. - **2025-01-17 - EU Hub feasibility report due**: ESAs joint report assessing the feasibility of further centralisation of incident reporting through a single EU Hub is due to the European Parliament, Council and Commission by 17 January 2025. - **2025-01-17 - ESAs publish feasibility report on EU Hub centralisation (JC 2024 108)**: ESAs publish their joint report on the feasibility of further centralising reporting of major ICT-related incidents through a single EU Hub (DORA Art. 21). - **2025-01-17 - Member States notify penalty and criminal-law measures**: Member States must notify the Commission, ESMA, EBA and EIOPA of laws/regulations implementing the chapter on administrative penalties (and any relevant criminal law provisions) by 17 January 2025. - **2025-01-17 - Application date - Guidelines on oversight cooperation and information exchange**: Joint Guidelines application date for oversight cooperation and information exchange. - **2025-02-20 - Delegated Reg. 2025/301 published in OJ (incident reporting RTS)**: Delegated Regulation (EU) 2025/301 (adopted 23 October 2024) specifies the content and time limits for the initial notification, and intermediate and final reports on, major ICT-related incidents, and the content of voluntary notifications of significant cyber threats. - **2025-02-20 - Implementing Regulation 2025/302 - incident reporting templates (ITS)**: Implementing Regulation (EU) 2025/302 (adopted 23 October 2024) lays down implementing technical standards establishing the standard forms, templates and procedures for reporting major ICT-related incidents and notifying significant cyber threats, including use under transitional arrangements pending any EU Hub implementation (OJ publication 20 February 2025; earlier drafts sometimes used month-level dating). - **2025-03-06 - Corrigendum (01) to Delegated Reg. 2024/1774**: First corrigendum to Delegated Regulation (EU) 2024/1774 (ICT risk management) published. - **2025-05-15 - Corrigendum (02) to Delegated Reg. 2024/1774**: Second corrigendum to Delegated Regulation (EU) 2024/1774 (ICT risk management) published. - **2025-05-19 - Application date - Guidelines on costs/losses estimation**: Application date for the costs/losses Guidelines. - **2025-06-18 - Delegated Reg. 2025/1190 published in OJ (TLPT RTS)**: Delegated Regulation (EU) 2025/1190 (adopted 13 February 2025) specifies RTS on criteria and detailed requirements for threat-led penetration testing (TLPT). - **2025-07-02 - Delegated Reg. 2025/532 published in OJ (subcontracting assessments)**: Delegated Regulation (EU) 2025/532 is published, specifying elements to determine and assess when subcontracting ICT services supporting critical or important functions. - **2025-09-11 - Corrigendum to Implementing Reg. 2025/302 (incident templates)**: Corrigendum to Implementing Regulation (EU) 2025/302 published. - **2025-09-12 - Corrigendum to Delegated Reg. 2025/301 (non-EN)**: Corrigendum to Delegated Regulation (EU) 2025/301 published; OJ note indicates it does not concern the English version. - **2025-09-19 - Corrigendum to Implementing Reg. 2024/2956 (register templates)**: Corrigendum to Implementing Regulation (EU) 2024/2956 published. - **2025-11-18 - First list of designated CTPPs published**: The European Supervisory Authorities publish the first list of designated critical ICT third-party service providers (CTPPs). - **2026-01-17 - Commission review on auditors and audit firms due**: Commission must review and submit a report (and, where appropriate, a legislative proposal) on strengthened digital operational resilience requirements for statutory auditors and audit firms by 17 January 2026. - **2028-01-17 - Commission review of DORA due**: Commission must review DORA and submit a report (and, where appropriate, a legislative proposal) by 17 January 2028. ## EU CRA Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2021-09-15 | CRA announced in State of the Union | Legislative History | SOTEU 2021 | | 2021-09-16 | Commission explainer on the CRA (quotes SOTEU speech) | Legislative History | | | 2022-03-16 | Public consultation | Legislative History | | | 2022-09-15 | Commission proposal published | Legislative History | COM(2022) 454 | | 2023-06-08 | Council general approach | Legislative History | | | 2023-07-19 | Council common position | Legislative History | | | 2023-07-19 | EP ITRE Committee adopts report | Legislative History | | | 2023-09-01 | Parliament enters interinstitutional negotiations | Legislative History | | | 2023-11-30 | Political agreement reached | Legislative History | | | 2023-12-01 | Parliament press release on political agreement | Legislative History | | | 2024-03-12 | Parliament plenary adoption | Legislative History | P9_TA(2024)0130 | | 2024-10-10 | Council formal adoption | Legislative History | | | 2024-10-23 | Act date | Official Publication | Reg. (EU) 2024/2847 | | 2024-11-20 | Published in Official Journal | Official Publication | OJ L 2024/2847 | | 2024-12-05 | Corrigendum: editorial title fix | Corrigendum | | | 2024-12-10 | Entry into force | Applicability | Art. 71(1) | | 2024-12-10 | Delegated powers conferred (5-year period begins) | Delegated & Implementing Acts | Art. 61(2) | | 2025-02-03 | Standardisation request M/606 adopted | Standardisation | C(2025) 618 | | 2025-04-03 | M/606 officially accepted by CEN-CENELEC | Standardisation | M/606 | | 2025-07-02 | Corrigendum: Art. 64(10) cross-reference | Corrigendum | Art. 64(10) | | 2025-07-29 | Delegated Reg. 2025/1535 adopted | Delegated & Implementing Acts | Reg. (EU) 2025/1535 | | 2025-10-03 | Corrigendum: Annex I language fix | Corrigendum | Annex I | | 2025-10-17 | Corrigendum: Art. 67 numbering | Corrigendum | Art. 67 | | 2025-10-29 | Delegated Reg. 2025/1535 published in OJ | Delegated & Implementing Acts | OJ L 2025/1535 | | 2025-11-18 | Delegated Reg. 2025/1535 enters into force | Delegated & Implementing Acts | Reg. (EU) 2025/1535 | | 2025-11-28 | Implementing Reg. 2025/2392 adopted | Delegated & Implementing Acts | Reg. (EU) 2025/2392 | | 2025-12-01 | Implementing Reg. 2025/2392 published in OJ | Delegated & Implementing Acts | OJ L 2025/2392 | | 2025-12-11 | Delegated act on CSIRT notification delays | Delegated & Implementing Acts | Art. 16(2) | | 2025-12-11 | Delegated act record published on EUR-Lex | Delegated & Implementing Acts | C(2025) 8407 | | 2025-12-21 | Implementing Reg. 2025/2392 enters into force | Delegated & Implementing Acts | Reg. (EU) 2025/2392 | | 2026-03-03 | Draft CRA guidance published for feedback | Commission Deliverables | | | 2026-03-31 | Feedback closes on draft CRA guidance | Commission Deliverables | | | 2026-06-11 | Chapter IV applies: notified bodies | Conformity Assessment | Art. 35-51 | | 2026-06-11 | Notified bodies listed on NANDO/SMCS (as they are designated) | Conformity Assessment | | | 2026-09-11 | Vulnerability reporting obligations apply | Vulnerability Reporting | Art. 14 | | 2026-09-11 | CRA reporting deadlines (24h / 72h / 14d / 1 month) | Vulnerability Reporting | | | 2026-09-11 | Open-source software stewards: reporting obligations apply (conditional) | Vulnerability Reporting | Art. 24(3), Art. 14 | | 2026-09-11 | Single Reporting Platform operational by this date | Commission Deliverables | | | 2027-12-11 | CRA applies in full | Applicability | Art. 71(2) | | 2027-12-11 | Legacy products: substantial modification rule | Applicability | | | 2027-12-11 | Economic operators obligations apply (importers, distributors, authorised representatives) | Applicability | Arts. 18-21 | | 2027-12-11 | Open-source software stewards: Article 24 obligations apply | Applicability | Art. 24(1)-(2) | | 2029-12-10 | End of initial 5-year delegation period (unless extended) | Delegated & Implementing Acts | Art. 61(2) | **Event details:** - **2021-09-15 - CRA announced in State of the Union**: President von der Leyen announces the CRA in the State of the Union address: 'including legislation on common standards under a new European Cyber Resilience Act.' - **2021-09-16 - Commission explainer on the CRA (quotes SOTEU speech)**: Commission explainer page published the day after SOTEU highlights the CRA and quotes the speech's CRA passage. - **2022-03-16 - Public consultation**: Commission launches CRA public consultation, open 16 March to 25 May 2022. - **2022-09-15 - Commission proposal published**: Commission presents the CRA proposal COM(2022) 454 final. - **2023-06-08 - Council general approach**: Council reaches its 'general approach' (negotiating mandate) on the CRA at the JHA Council meeting. - **2023-07-19 - Council common position**: Member States agree a common position on security requirements for digital products. - **2023-07-19 - EP ITRE Committee adopts report**: EP ITRE Committee adopts its report/position on the CRA. - **2023-09-01 - Parliament enters interinstitutional negotiations**: Parliament confirms its committee decision to enter interinstitutional (trilogue) negotiations in September 2023. - **2023-11-30 - Political agreement reached**: Council and Parliament reach provisional political agreement on the CRA. - **2023-12-01 - Parliament press release on political agreement**: European Parliament press release on the agreement reached with the Council to boost digital products security. - **2024-03-12 - Parliament plenary adoption**: European Parliament adopts the CRA in plenary: 517 in favour, 12 against, 78 abstentions. - **2024-10-10 - Council formal adoption**: Council formally adopts the Cyber Resilience Act. - **2024-10-23 - Act date**: Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 (Cyber Resilience Act) is signed. - **2024-11-20 - Published in Official Journal**: CRA published in the Official Journal of the European Union (OJ L 2024/2847, 20.11.2024). - **2024-12-05 - Corrigendum: editorial title fix**: First corrigendum: corrects '(EU) No 2019/1020' to '(EU) 2019/1020' in the regulation title. - **2024-12-10 - Entry into force**: CRA enters into force on the 20th day following OJ publication (20 Nov + 20 days = 10 Dec 2024). - **2024-12-10 - Delegated powers conferred (5-year period begins)**: Delegation of power to the Commission is conferred for a period of five years from 10 December 2024, with tacit extensions unless opposed. - **2025-02-03 - Standardisation request M/606 adopted**: Commission adopts CRA standardisation request M/606 containing 41 standards. Accepted by CEN, CENELEC, and ETSI on 3 April 2025. - **2025-04-03 - M/606 officially accepted by CEN-CENELEC**: CEN-CENELEC officially accepted the CRA standardisation request on 3 April 2025. - **2025-07-02 - Corrigendum: Art. 64(10) cross-reference**: Corrigendum fixes Article 64(10): 'paragraphs 3 to 9' corrected to 'paragraphs 2 to 9'. - **2025-07-29 - Delegated Reg. 2025/1535 adopted**: Commission excludes most L-category vehicle products from CRA scope (exception for L1e pedal-designed). OJ publication 29 Oct 2025; enters into force 20 days later. - **2025-10-03 - Corrigendum: Annex I language fix**: Corrigendum fixes FR/HU language wording in Annex I, Part I, paragraph 2, point (c). - **2025-10-17 - Corrigendum: Art. 67 numbering**: Corrigendum fixes numbering reference in Article 67: '69' corrected to '72'. - **2025-10-29 - Delegated Reg. 2025/1535 published in OJ**: Delegated Regulation (EU) 2025/1535 is published in the Official Journal on 29 October 2025. - **2025-11-18 - Delegated Reg. 2025/1535 enters into force**: Delegated Regulation (EU) 2025/1535 enters into force on the twentieth day following its OJ publication. - **2025-11-28 - Implementing Reg. 2025/2392 adopted**: Commission adopts technical descriptions for Annex III/IV product categories (important and critical products). OJ publication 1 Dec 2025; enters into force 20 days later. - **2025-12-01 - Implementing Reg. 2025/2392 published in OJ**: Implementing Regulation (EU) 2025/2392 is published in the Official Journal on 1 December 2025. - **2025-12-11 - Delegated act on CSIRT notification delays**: Commission adopts delegated act specifying terms and conditions for delaying dissemination of vulnerability notifications by CSIRTs under Article 16(2). - **2025-12-11 - Delegated act record published on EUR-Lex**: EUR-Lex record for the Commission delegated act concerning Article 16(2) conditions for CSIRTs delaying dissemination to other CSIRTs. - **2025-12-21 - Implementing Reg. 2025/2392 enters into force**: Implementing Regulation (EU) 2025/2392 enters into force on the twentieth day following its OJ publication. - **2026-03-03 - Draft CRA guidance published for feedback**: Commission publishes draft CRA guidance for stakeholder feedback, clarifying scope, remote data processing, free and open-source software, support periods, and interplay with other EU law. - **2026-03-31 - Feedback closes on draft CRA guidance**: The stakeholder feedback period on the Commission's draft CRA guidance closes on 31 March 2026. - **2026-06-11 - Chapter IV applies: notified bodies**: CRA Chapter IV (Articles 35-51) on notification of conformity assessment bodies begins to apply. - **2026-06-11 - Notified bodies listed on NANDO/SMCS (as they are designated)**: From the Chapter IV applicability date, conformity assessment bodies can be notified under the CRA framework and, once notified, will appear in the Commission's NANDO/SMCS notified bodies list for the CRA. - **2026-09-11 - Vulnerability reporting obligations apply**: Article 14 (vulnerability and incident reporting) applies. Manufacturers must report actively exploited vulnerabilities and severe incidents via ENISA's Single Reporting Platform. - **2026-09-11 - CRA reporting deadlines (24h / 72h / 14d / 1 month)**: From the Article 14 applicability date, incident/vulnerability notifications follow operational time limits (early warning within 24 hours of awareness; full notification within 72 hours; final report timelines depending on case, such as 14 days or 1 month). - **2026-09-11 - Open-source software stewards: reporting obligations apply (conditional)**: Open-source software stewards are subject to Article 14(1) (and, where applicable, Article 14(3) and (8)) to the extent they are involved in development, from the date Article 14 applies. - **2026-09-11 - Single Reporting Platform operational by this date**: Commission states ENISA's Single Reporting Platform (SRP) will be operational by 11 September 2026 to support CRA vulnerability and incident reporting. - **2027-12-11 - CRA applies in full**: General application date: the CRA applies in full from 11 December 2027. - **2027-12-11 - Legacy products: substantial modification rule**: Products placed on the EU market before 11 December 2027 are subject to CRA product requirements only if, from that date, they undergo a substantial modification; reporting obligations still apply from the earlier reporting applicability date. - **2027-12-11 - Economic operators obligations apply (importers, distributors, authorised representatives)**: From the general CRA application date, authorised representatives, importers, and distributors must comply with their CRA obligations; in certain cases (e.g., own-branding or substantial modification) importers/distributors are treated as manufacturers. - **2027-12-11 - Open-source software stewards: Article 24 obligations apply**: Open-source software stewards must have a verifiable cybersecurity policy for secure development and vulnerability handling, and cooperate with market surveillance authorities (subject to CRA scope). - **2029-12-10 - End of initial 5-year delegation period (unless extended)**: The initial five-year period for the Commission's delegated powers runs until 10 December 2029, subject to tacit extensions unless opposed. ## EU Data Act Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2023-11-09 | European Parliament position adopted | Legislative History | | | 2023-11-27 | Council decision adopted | Legislative History | | | 2023-12-13 | Regulation adopted (Data Act) | Legislative History | | | 2023-12-22 | Published in Official Journal | Official Publication | | | 2024-01-11 | Entry into force | Official Publication | | | 2024-01-11 | Reduced switching charges period | Cloud Switching | Art. 29(2) | | 2024-01-11 | Delegated powers conferred | Commission Deliverables | Art. 45(2) | | 2024-09-06 | Commission publishes Data Act FAQs | Commission Deliverables | | | 2025-07-01 | Commission standardisation request (European Trusted Data Framework) | Standardisation | | | 2025-07-07 | CEN and CENELEC accept the standardisation request (Mandate M/614) | Standardisation | | | 2025-09-12 | Data Act applies | Applicability | | | 2025-09-12 | Member States notify penalties rules | Member State Duties | Art. 40(2) | | 2025-09-12 | Model contractual terms and cloud clauses deadline | Commission Deliverables | Art. 41 | | 2025-09-15 | Commission guidance on vehicle data (C/2025/5026) | Commission Deliverables | | | 2025-12-16 | Commission launches Data Act legal helpdesk | Commission Deliverables | | | 2026-01-22 | Data Act FAQs updated (v1.4) | Commission Deliverables | | | 2026-03-01 | Data catalogue technical specification deadline | Standardisation | | | 2026-06-01 | Trusted data transactions standards Part 1 deadline | Standardisation | | | 2026-09-01 | European Trusted Data Framework deliverables deadline | Standardisation | | | 2026-09-12 | Connected product access-by-design obligations | Applicability | | | 2026-11-01 | Trusted data transactions standards Part 2 deadline | Standardisation | | | 2027-01-12 | Switching charges prohibited | Cloud Switching | Art. 29(1) | | 2027-03-01 | Internal data governance quality framework standard deadline | Standardisation | | | 2027-05-01 | Trusted data transactions standards Part 3 deadline | Standardisation | | | 2027-09-12 | Chapter IV extends to older contracts | Applicability | | | 2028-09-12 | Commission evaluation report deadline | Commission Deliverables | Art. 49(1) | **Event details:** - **2023-11-09 - European Parliament position adopted**: The Regulation records the European Parliament position of 9 November 2023 in the legislative history footnote. - **2023-11-27 - Council decision adopted**: The Regulation records the Council decision of 27 November 2023 in the legislative history footnote. - **2023-12-13 - Regulation adopted (Data Act)**: Regulation (EU) 2023/2854 is adopted and signed in Strasbourg. - **2023-12-22 - Published in Official Journal**: Regulation (EU) 2023/2854 is published in the Official Journal (OJ L, 2023/2854, 22.12.2023). - **2024-01-11 - Entry into force**: The Data Act enters into force on the twentieth day following publication in the Official Journal. - **2024-01-11 - Reduced switching charges period**: From 11 January 2024 to 12 January 2027, providers of data processing services may impose reduced switching charges for the switching process. - **2024-01-11 - Delegated powers conferred**: The Commission is conferred the power to adopt delegated acts for an indeterminate period of time from 11 January 2024 for specified delegated powers under the Regulation. - **2024-09-06 - Commission publishes Data Act FAQs**: The Commission publishes Frequently Asked Questions about the Data Act to support implementation. - **2025-07-01 - Commission standardisation request (European Trusted Data Framework)**: Commission Implementing Decision of 1 July 2025 issues a standardisation request to CEN, CENELEC and ETSI in support of the Data Act (C(2025) 4135 final). - **2025-07-07 - CEN and CENELEC accept the standardisation request (Mandate M/614)**: CEN and CENELEC accept the Commission standardisation request on the European Trusted Data Framework (Mandate M/614). - **2025-09-12 - Data Act applies**: The Data Act applies from 12 September 2025. - **2025-09-12 - Member States notify penalties rules**: Member States notify the Commission of penalties rules and measures by 12 September 2025. - **2025-09-12 - Model contractual terms and cloud clauses deadline**: Before 12 September 2025, the Commission develops and recommends non-binding model contractual terms on data access and use and non-binding standard contractual clauses for cloud computing contracts. - **2025-09-15 - Commission guidance on vehicle data (C/2025/5026)**: The Commission publishes guidance on vehicle data accompanying the Data Act (OJ C, 15.9.2025). - **2025-12-16 - Commission launches Data Act legal helpdesk**: The Commission launches a Data Act Legal Helpdesk to support stakeholders with practical implementation questions. - **2026-01-22 - Data Act FAQs updated (v1.4)**: The Commission updates the Data Act FAQs page and publishes FAQs Data Act version 1.4 dated 22 January 2026. - **2026-03-01 - Data catalogue technical specification deadline**: Deadline for adoption of technical specification(s) on a data catalogue implementation framework (Annex I). - **2026-06-01 - Trusted data transactions standards Part 1 deadline**: Deadline for adoption of harmonised standards on Trusted Data Transactions Part 1: terminology, concepts and mechanisms (Annex I). - **2026-09-01 - European Trusted Data Framework deliverables deadline**: Deadline for adoption of technical specification(s) on semantic assets and technical specification(s) on a maturity model for Common European Data Spaces (Annex I). - **2026-09-12 - Connected product access-by-design obligations**: The obligation resulting from Article 3(1) applies to connected products and related services placed on the market after 12 September 2026. - **2026-11-01 - Trusted data transactions standards Part 2 deadline**: Deadline for adoption of harmonised standards on Trusted Data Transactions Part 2: trustworthiness requirements (Annex I). - **2027-01-12 - Switching charges prohibited**: From 12 January 2027, providers of data processing services shall not impose any switching charges on the customer for the switching process. - **2027-03-01 - Internal data governance quality framework standard deadline**: Deadline for adoption of the European standard on a quality framework for internal data governance (Annex I). - **2027-05-01 - Trusted data transactions standards Part 3 deadline**: Deadline for adoption of harmonised standards on Trusted Data Transactions Part 3: interoperability requirements (Annex I). - **2027-09-12 - Chapter IV extends to older contracts**: Chapter IV applies from 12 September 2027 to certain contracts concluded on or before 12 September 2025 (indefinite duration or expiring at least 10 years from 11 January 2024). - **2028-09-12 - Commission evaluation report deadline**: By 12 September 2028, the Commission carries out an evaluation of the Regulation and submits a report to the European Parliament and the Council. ## AU Cyber Security Act Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2021-12-02 | SLACI Act 2021 commences (SOCI reforms - tranche 1) | SOCI Act Context | | | 2021-12-15 | SLACIP Bill exposure-draft consultation window | Policy & Consultation | | | 2022-02-04 | SLACIP Bill exposure-draft: final Town Hall held | Policy & Consultation | | | 2022-02-10 | SLACIP Bill introduced and referred to PJCIS | Legislative Process | | | 2022-03-25 | PJCIS advisory report published (SLACIP Bill) | Legislative Process | | | 2022-04-01 | SLACIP Act 2022 made (Federal Register date) | SOCI Act Context | | | 2022-04-02 | SLACIP Act 2022 comes into effect (SOCI reforms - tranche 2) | SOCI Act Context | | | 2022-04-08 | SOCI Application Rules (LIN 22/026) come into effect | SOCI Act Context | | | 2022-07-07 | Telecommunications assets: Cyber Reporting compliance date (Telecommunications Act context) | SOCI Act Context | | | 2022-09-09 | Protected Information guidance (consultation draft v1) | Guidance (Non-binding) | | | 2022-10-05 | RMP Rules consultation window (SOCI reforms) | Policy & Consultation | | | 2022-10-07 | Telecommunications assets: Register compliance date (Telecommunications Act context) | SOCI Act Context | | | 2022-11-03 | Draft Risk Management Program Guidance (consultation draft v2) | Guidance (Non-binding) | | | 2023-02-16 | CIRMP Rules (LIN 23/006) as made (F2023L00112) | SOCI Act Context | | | 2023-02-27 | Australian Cyber Security Strategy consultation window | Policy & Consultation | | | 2023-11-22 | Smart device standards: Impact Analysis published | Policy & Consultation | | | 2023-12-19 | Cyber Security legislative reforms consultation window | Policy & Consultation | | | 2024-10-09 | Minister's second reading speech (House of Representatives) | Legislative Process | | | 2024-11-25 | Minister's second reading speech (Senate) | Legislative Process | | | 2024-11-29 | Cyber Security Act 2024 receives Royal Assent | Cyber Security Act 2024 | | | 2024-11-30 | Act commences: Parts 1, 4, 6 and 7 | Commencement & Application | | | 2024-12-16 | Draft Cyber Security Act Rules consultation window | Policy & Consultation | | | 2025-02-27 | Cyber Security Act Rules are made (dated) | Subordinate Rules (2025) | | | 2025-03-03 | CIRB Rules registered (F2025L00277) | Subordinate Rules (2025) | | | 2025-03-03 | Ransomware Payment Reporting Rules registered (F2025L00278) | Subordinate Rules (2025) | | | 2025-03-04 | Smart Devices Rules registered; Part 1 commences (F2025L00276) | Subordinate Rules (2025) | | | 2025-03-27 | Smart device standards: Supplementary Explanatory Statement registered | Policy & Consultation | | | 2025-04-03 | CIRMP Rules: as-made version end date (superseded) | SOCI Act Context | | | 2025-04-04 | SOCI Application Rules: April 2025 compilation/version date | SOCI Act Context | | | 2025-05-29 | Act commences: Part 3 (ransomware payment reporting) (backstop date) | Commencement & Application | Part 3; s.27 | | 2025-05-29 | Ransomware Payment Reporting Rules commence (F2025L00278) (aligned to Part 3) | Commencement & Application | | | 2025-05-29 | Act commences: Part 5 (Cyber Incident Review Board) (backstop date) | Commencement & Application | | | 2025-05-29 | CIRB Rules commence (F2025L00277) (aligned to Part 5) | Commencement & Application | | | 2025-11-29 | Act commences: Part 2 (smart device security standards framework) (backstop date) | Commencement & Application | | | 2026-01-28 | Compiled Act: replaced authorised version registered | Cyber Security Act 2024 | | | 2026-03-04 | Smart Devices Rules substantive obligations commence (Part 2 and Schedule 1) | Commencement & Application | | | 2027-12-01 | Statutory review can begin (PJCIS) | Statutory Review | s.88 | **Event details:** - **2021-12-02 - SLACI Act 2021 commences (SOCI reforms - tranche 1)**: Home Affairs describes the Security Legislation Amendment (Critical Infrastructure) Act 2021 (SLACI Act) as the first tranche of reforms to the SOCI Act, commencing from 2 December 2021. - **2021-12-15 - SLACIP Bill exposure-draft consultation window**: Home Affairs records an exposure-draft consultation period for the SLACIP Bill and accompanying draft Explanatory Document running from 15 December 2021 until Tuesday 1 February 2022. - **2022-02-04 - SLACIP Bill exposure-draft: final Town Hall held**: Home Affairs notes a final Town Hall was held on 4 February 2022 following the closure of submissions on the SLACIP Bill exposure draft. - **2022-02-10 - SLACIP Bill introduced and referred to PJCIS**: Home Affairs records that the Minister for Home Affairs introduced the SLACIP Bill to Parliament and referred it to the Parliamentary Joint Committee on Intelligence and Security (PJCIS) on 10 February 2022. - **2022-03-25 - PJCIS advisory report published (SLACIP Bill)**: Home Affairs notes that the PJCIS published its advisory report on the SLACIP Bill on 25 March 2022. - **2022-04-01 - SLACIP Act 2022 made (Federal Register date)**: The Federal Register of Legislation entry for the Security Legislation Amendment (Critical Infrastructure Protection) Act 2022 (C2022A00033) shows a date of 1 April 2022 (as-made Act entry). - **2022-04-02 - SLACIP Act 2022 comes into effect (SOCI reforms - tranche 2)**: Home Affairs records that the Security Legislation Amendment (Critical Infrastructure Protection) Act 2022 (SLACIP Act) came into effect on 2 April 2022. - **2022-04-08 - SOCI Application Rules (LIN 22/026) come into effect**: Draft Risk Management Program Guidance states that the Security of Critical Infrastructure (Application) Rules (LIN 22/026) 2022 came into effect on 8 April 2022, outlining asset classes required to comply with Mandatory Cyber Incident Reporting and certain Register reporting requirements. - **2022-07-07 - Telecommunications assets: Cyber Reporting compliance date (Telecommunications Act context)**: Draft Risk Management Program Guidance notes that telecommunications assets comply with Cyber Reporting from 7 July 2022 under the Telecommunications Act 1997. - **2022-09-09 - Protected Information guidance (consultation draft v1)**: Protected Information Guidance Material for industry is marked as a consultation draft (v1) and states it is current "as at 9 September 2022". - **2022-10-05 - RMP Rules consultation window (SOCI reforms)**: Draft Risk Management Program Guidance states the consultation period for the draft risk management program (RMP) rules was 45 days, from 5 October 2022 to 18 November 2022. - **2022-10-07 - Telecommunications assets: Register compliance date (Telecommunications Act context)**: Draft Risk Management Program Guidance notes that telecommunications assets comply with the Register from 7 October 2022 under the Telecommunications Act 1997. - **2022-11-03 - Draft Risk Management Program Guidance (consultation draft v2)**: Draft Risk Management Program Guidance is marked as a consultation draft (v2) and states it is current "as at 03 November 2022". - **2023-02-16 - CIRMP Rules (LIN 23/006) as made (F2023L00112)**: Security of Critical Infrastructure (Critical infrastructure risk management program) Rules (LIN 23/006) 2023 appear on the Federal Register of Legislation as an as-made version dated 16 February 2023 (F2023L00112). - **2023-02-27 - Australian Cyber Security Strategy consultation window**: Smart Devices Rules Explanatory Statement references the Australian Government consultation on the 2023-2030 Australian Cyber Security Strategy running from 27 February 2023 to 15 April 2023. - **2023-11-22 - Smart device standards: Impact Analysis published**: Impact Analysis Addendum for smart device standards states that the Department of Home Affairs published an Impact Analysis on mandatory security standards and an industry-led voluntary cyber security labelling scheme on 22 November 2023. - **2023-12-19 - Cyber Security legislative reforms consultation window**: Smart Devices Rules Explanatory Statement records that, on 19 December 2023, the Minister released the "Australian Cyber Security Strategy: Cyber Security Legislative Reforms Consultation Paper" and that consultation remained open until 1 March 2024. - **2024-10-09 - Minister's second reading speech (House of Representatives)**: The Act records that the Minister's second reading speech was made in the House of Representatives on 9 October 2024. - **2024-11-25 - Minister's second reading speech (Senate)**: The Act records that the Minister's second reading speech was made in the Senate on 25 November 2024. - **2024-11-29 - Cyber Security Act 2024 receives Royal Assent**: Cyber Security Act 2024 (No. 98, 2024) receives Royal Assent on 29 November 2024. - **2024-11-30 - Act commences: Parts 1, 4, 6 and 7**: Commencement table: Part 1 (and provisions not otherwise covered), Part 4 (coordination of significant cyber security incidents), and Parts 6-7 (regulatory powers and miscellaneous) commence the day after Royal Assent (30 November 2024). - **2024-12-16 - Draft Cyber Security Act Rules consultation window**: Explanatory Statements record that the draft Rules package was published on the Department's website on 16 December 2024 and closed for submissions on 14 February 2025. - **2025-02-27 - Cyber Security Act Rules are made (dated)**: The three Cyber Security Act Rules instruments are dated 27 February 2025 (Smart Devices Rules; Cyber Incident Review Board Rules; Ransomware Payment Reporting Rules). Registration dates follow in early March 2025. - **2025-03-03 - CIRB Rules registered (F2025L00277)**: Cyber Security (Cyber Incident Review Board) Rules 2025 are registered on 3 March 2025. The instrument commences later of the day after registration and the commencement of Act Part 5. - **2025-03-03 - Ransomware Payment Reporting Rules registered (F2025L00278)**: Cyber Security (Ransomware Payment Reporting) Rules 2025 are registered on 3 March 2025. The instrument commences later of the day after registration and the commencement of Act Part 3. - **2025-03-04 - Smart Devices Rules registered; Part 1 commences (F2025L00276)**: Cyber Security (Security Standards for Smart Devices) Rules 2025 are registered on 4 March 2025. The commencement table provides that Part 1 commences on registration, while Part 2 and Schedule 1 have a delayed commencement (4 March 2026). - **2025-03-27 - Smart device standards: Supplementary Explanatory Statement registered**: The smart device standards Impact Analysis (Supplementary Explanatory Statement) is an authorised version registered on 27 March 2025 in connection with F2025L00276. - **2025-04-03 - CIRMP Rules: as-made version end date (superseded)**: The Federal Register of Legislation page for F2023L00112 shows the as-made version dated 16 February 2023 and indicates it is superseded, with the as-made version running until 3 April 2025. - **2025-04-04 - SOCI Application Rules: April 2025 compilation/version date**: The Federal Register metadata for the SOCI Application Rules references an April 2025 compilation (F2025C00404) and links to a 4 April 2025 version in the legislation history/amendment history. - **2025-05-29 - Act commences: Part 3 (ransomware payment reporting) (backstop date)**: Commencement table provides for commencement by proclamation, with an automatic commencement if not commenced within 6 months of Royal Assent. The published commencement table includes 29 May 2025 as the backstop date for Part 3. Part 3 imposes the 72-hour ransomware payment reporting obligation for reporting business entities; the 2025 Rules specify (among other details) the $3 million turnover threshold and report content requirements. - **2025-05-29 - Ransomware Payment Reporting Rules commence (F2025L00278) (aligned to Part 3)**: Commencement clause: the whole instrument commences later of the day after registration and the commencement of Act Part 3; the backstop commencement date for Part 3 is 29 May 2025. - **2025-05-29 - Act commences: Part 5 (Cyber Incident Review Board) (backstop date)**: Commencement table provides for commencement by proclamation, with an automatic commencement if not commenced within 6 months of Royal Assent. The published commencement table includes 29 May 2025 as the backstop date for Part 5. - **2025-05-29 - CIRB Rules commence (F2025L00277) (aligned to Part 5)**: Commencement clause: the whole instrument commences later of the day after registration and the commencement of Act Part 5; the backstop commencement date for Part 5 is 29 May 2025. - **2025-11-29 - Act commences: Part 2 (smart device security standards framework) (backstop date)**: Commencement table provides for commencement by proclamation, with an automatic commencement if not commenced within 12 months of Royal Assent. The published commencement table includes 29 November 2025 as the backstop date for Part 2 (security standards for smart devices). - **2026-01-28 - Compiled Act: replaced authorised version registered**: The Act text indicates a replaced authorised version was registered on 28 January 2026 (compiled version reference). - **2026-03-04 - Smart Devices Rules substantive obligations commence (Part 2 and Schedule 1)**: Commencement table: Part 2 and Schedule 1 of the Smart Devices Rules commence on 4 March 2026 (12-month delayed commencement). This is when the mandatory security standards, statement-of-compliance requirements (including 5-year retention period), and defined support-period rules take effect for covered products. - **2027-12-01 - Statutory review can begin (PJCIS)**: The Parliamentary Joint Committee on Intelligence and Security may review the operation, effectiveness and implications of the Act, so long as it begins the review as soon as practicable after 1 December 2027. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/regulatory-universal-timelines --- --- title: "How to Use Regulatory Universal Timelines for Execution Planning" canonical_url: "https://www.sorena.io/artifacts/global/regulatory-universal-timelines/how-to-use" source_url: "https://www.sorena.io/artifacts/global/regulatory-universal-timelines/how-to-use" author: "Sorena AI" description: "Step by step guide for using Sorena AI Regulatory Universal Timeline: source filters, category chips, event detail, zoom, minimap navigation." published_at: "2026-02-12" updated_at: "2026-02-12" keywords: - "how to use regulatory universal timeline" - "compliance timeline workflow" - "regulatory deadline planning" - "execution planning for compliance" - "milestone ownership workflow" - "Regulatory Universal Timeline" - "Execution planning" - "Compliance workflow" - "Deadline management" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # How to Use Regulatory Universal Timelines for Execution Planning Step by step guide for using Sorena AI Regulatory Universal Timeline: source filters, category chips, event detail, zoom, minimap navigation. *Workflow Guide* *Execution Planning* ## How to Use Regulatory Universal Timelines Run the merged timeline as an operating workflow, not just a date viewer. Start with the right source labels and category filters, then convert dated events into owned internal milestones with evidence and escalation rules. The current viewer merges 38 local source timelines and 1297 dated events. The right way to use it is to narrow the dataset first, inspect the source context for each event, and then move the selected dates into your own delivery and assurance process. ## Start with source labels and category chips The first cut should be by source timeline and category, not by raw date volume. The viewer namespaces categories per source timeline, so a chip tells you both the framework label and the event type you are filtering. This matters because the universal timeline intentionally preserves separate local source timelines even when two datasets are closely related. Review the source label before treating two events as part of the same program. - Use source labels first to isolate the regulations that matter to your entity or product line - Use category chips next to reduce noise inside the selected source timelines - Treat closely related but separately maintained source timelines as separate datasets until you deliberately map them together ## Open event detail before you create internal work Each event carries a normalized title, a category, summary text, and often a source URL. Click the event before you create tickets or board reports so the team works from the actual milestone context instead of a date alone. The article field in the merged view is prefixed with the source label. That makes it easier to preserve legal context when similar milestone names appear across different frameworks. - Read the summary and article context for every high impact event - Follow the source URL for events that could change funding, launch timing, or enforcement exposure - Capture interpretation notes outside the viewer if legal counsel narrows or expands applicability ## Translate external dates into internal milestone ladders The universal timeline stores external dates. Your program still needs internal dates for analysis, design, build, validation, and executive sign off. Do not wait for the legal date to become the first delivery date. Use the viewer to find collision windows, then work backward to create internal gates. - Create an analysis milestone for scope, interpretation, and owner confirmation - Create an implementation milestone for control, product, or policy changes - Create an assurance milestone for testing, evidence review, and remediation closure - Create a final governance milestone for approval and reporting ## Use zoom, minimap, and PNG export for governance review The viewer supports zoom, horizontal navigation, a minimap, and browser-generated PNG export. Use them to prepare leadership packs that show the exact cluster of dates under review. A timeline image is only a snapshot. Store the export date, selected filters, and any interpretation assumptions alongside the PNG so the board pack remains explainable later. - Zoom out to understand the full collision pattern before you zoom in to run a specific program review - Use the minimap to navigate dense periods instead of dragging through the full range repeatedly - Attach filter notes, export date, and ownership summary to every PNG shared outside the working team *Recommended next step* *Placement: near the end of the main content before related guides* ## Use How to Use Regulatory Universal Timelines as a cited research workflow Research Copilot can take How to Use Regulatory Universal Timelines from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on How to Use can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for How to Use Regulatory Universal Timelines](/solutions/research-copilot.md): Start from How to Use Regulatory Universal Timelines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through How to Use](/contact.md): Review your current process, evidence gaps, and next steps for How to Use Regulatory Universal Timelines. ## Primary sources - [EUR-Lex portal](https://eur-lex.europa.eu/homepage.html?locale=en&ref=sorena.io) - Primary source portal for EU regulations represented in the merged timeline. - [Federal Register of Legislation (Australia)](https://www.legislation.gov.au/?ref=sorena.io) - Primary source portal for Australian milestones represented in the merged timeline. - [Planalto - Lei Geral de Protecao de Dados Pessoais](https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2018/lei/l13709.htm?ref=sorena.io) - Primary source text for the Brazil LGPD timeline now included in the merged dataset. - [UK legislation](https://www.legislation.gov.uk/?ref=sorena.io) - Primary source portal for UK GDPR, PSTI, and Online Safety Act milestones in the merged timeline. ## Related Topic Guides - [Framework Overlap and Evidence Reuse for Regulatory Universal Timeline](/artifacts/global/regulatory-universal-timelines/framework-overlap-and-evidence-reuse.md): Use Sorena AI Regulatory Universal Timeline to spot deadline overlap. - [Regulatory Universal Timeline Compliance Calendar Guide](/artifacts/global/regulatory-universal-timelines/compliance-calendar.md): Build an internal compliance calendar from Sorena AI Regulatory Universal Timeline by converting external events into owned milestones, collision windows. - [Regulatory Universal Timeline Export and Sharing Guide](/artifacts/global/regulatory-universal-timelines/export-and-sharing.md): Share Sorena AI Regulatory Universal Timeline correctly: browser generated PNG export, filter context, version notes, leadership reporting packs. - [Regulatory Universal Timeline Glossary](/artifacts/global/regulatory-universal-timelines/glossary.md): Glossary for Sorena AI Regulatory Universal Timeline covering source timelines, category chips, milestone events, ranged events, export snapshots. - [What Is Included in Regulatory Universal Timeline](/artifacts/global/regulatory-universal-timelines/what-is-included.md): Review current coverage for Sorena AI Regulatory Universal Timeline: which local timeline files are merged, what event fields are included. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/regulatory-universal-timelines/how-to-use --- --- title: "Regulatory Universal Timeline Compliance Calendar Guide" canonical_url: "https://www.sorena.io/artifacts/global/regulatory-universal-timelines/compliance-calendar" source_url: "https://www.sorena.io/artifacts/global/regulatory-universal-timelines/compliance-calendar" author: "Sorena AI" description: "Build an internal compliance calendar from Sorena AI Regulatory Universal Timeline by converting external events into owned milestones, collision windows." published_at: "2026-02-12" updated_at: "2026-02-12" keywords: - "regulatory universal timeline compliance calendar" - "compliance calendar guide" - "deadline collision planning" - "governance cadence planning" - "evidence backed milestones" - "Compliance calendar" - "Regulatory Universal Timeline" - "Deadline planning" - "Governance cadence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Regulatory Universal Timeline Compliance Calendar Guide Build an internal compliance calendar from Sorena AI Regulatory Universal Timeline by converting external events into owned milestones, collision windows. *Execution Guide* *Calendar Design* ## Compliance Calendar for Regulatory Universal Timelines Convert merged external dates into one internal calendar that teams can execute. Use the raw event model as input, then add owner, lead time, dependency, and evidence rules outside the viewer. The universal timeline stores dated external events, not your internal work plan. A useful compliance calendar starts from those source-traceable dates and then adds planning layers for analysis, implementation, assurance, and executive closure. ## Start from the real event model The merged viewer is built from local event records with fields such as date, optional endDate, category, title, article, summary, optional source URL, and milestone status. Your compliance calendar should preserve those fields so the internal plan can always point back to the original event. Do not flatten ranged events into a single day without recording the original window. Some obligations are represented as reporting or transition periods rather than one deadline. - Keep the external source label and category on every imported calendar item - Record whether the event is a milestone date or part of a ranged period - Preserve article, summary, and source URL references for high impact events ## Create internal lead time before every external milestone A legal date is too late to become the first action date. Build a milestone ladder that works backward from the external event and gives enough time for review, remediation, and approval. The more frameworks you carry, the more important it is to standardize the internal ladder so program reviews stay comparable across different regulations. - Analysis gate for scope, interpretation, and owner assignment - Design gate for policy, control, or product changes - Implementation gate for deployment and training completion - Assurance gate for testing, evidence review, and defect closure - Governance gate for executive sign off and external reporting readiness *Recommended next step* *Placement: after the timeline or milestone section* ## Use Compliance Calendar for Regulatory Universal Timelines as a cited research workflow Research Copilot can take Compliance Calendar for Regulatory Universal Timelines from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on Compliance Calendar can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Compliance Calendar for Regulatory Universal Timelines](/solutions/research-copilot.md): Start from Compliance Calendar for Regulatory Universal Timelines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Compliance Calendar](/contact.md): Review your current process, evidence gaps, and next steps for Compliance Calendar for Regulatory Universal Timelines. ## Manage collision windows across source timelines The current merged build spans 38 source timelines, so deadline clustering is normal. Use the viewer to detect dense periods, then rebalance internal milestones before the collision reaches the same program team or evidence owner. A calendar that ignores collision windows creates silent capacity failures even when each single obligation appears manageable on its own. - Identify weeks or months where multiple source timelines hit the same delivery teams - Flag shared dependencies such as procurement, product release, privacy review, or third party evidence collection - Escalate conflicts early when the same owners appear in multiple milestone ladders ## Close milestones only with evidence A calendar status should move to complete only when evidence exists, not when someone says the task is done. That rule matters most when leadership is looking at a filtered PNG and cannot see the underlying project system. Define evidence freshness, reviewer, and storage location up front so the calendar can double as a governance and audit tracker. - Link every closed milestone to an evidence package or repository reference - Record reviewer name and review date for high impact obligations - Reopen a milestone if the source interpretation or supporting evidence changes ## Primary sources - [EUR-Lex portal](https://eur-lex.europa.eu/homepage.html?locale=en&ref=sorena.io) - Primary source portal for EU dates that commonly drive the merged calendar. - [Federal Register of Legislation (Australia)](https://www.legislation.gov.au/?ref=sorena.io) - Primary source portal for Australian milestone dates represented in the merged timeline. - [UK legislation](https://www.legislation.gov.uk/?ref=sorena.io) - Primary source portal for UK milestone dates represented in the merged timeline. ## Related Topic Guides - [Framework Overlap and Evidence Reuse for Regulatory Universal Timeline](/artifacts/global/regulatory-universal-timelines/framework-overlap-and-evidence-reuse.md): Use Sorena AI Regulatory Universal Timeline to spot deadline overlap. - [How to Use Regulatory Universal Timelines for Execution Planning](/artifacts/global/regulatory-universal-timelines/how-to-use.md): Step by step guide for using Sorena AI Regulatory Universal Timeline: source filters, category chips, event detail, zoom, minimap navigation. - [Regulatory Universal Timeline Export and Sharing Guide](/artifacts/global/regulatory-universal-timelines/export-and-sharing.md): Share Sorena AI Regulatory Universal Timeline correctly: browser generated PNG export, filter context, version notes, leadership reporting packs. - [Regulatory Universal Timeline Glossary](/artifacts/global/regulatory-universal-timelines/glossary.md): Glossary for Sorena AI Regulatory Universal Timeline covering source timelines, category chips, milestone events, ranged events, export snapshots. - [What Is Included in Regulatory Universal Timeline](/artifacts/global/regulatory-universal-timelines/what-is-included.md): Review current coverage for Sorena AI Regulatory Universal Timeline: which local timeline files are merged, what event fields are included. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/regulatory-universal-timelines/compliance-calendar --- --- title: "Framework Overlap and Evidence Reuse for Regulatory Universal Timeline" canonical_url: "https://www.sorena.io/artifacts/global/regulatory-universal-timelines/framework-overlap-and-evidence-reuse" source_url: "https://www.sorena.io/artifacts/global/regulatory-universal-timelines/framework-overlap-and-evidence-reuse" author: "Sorena AI" description: "Use Sorena AI Regulatory Universal Timeline to spot deadline overlap." published_at: "2026-02-12" updated_at: "2026-02-12" keywords: - "framework overlap regulatory universal timeline" - "evidence reuse model" - "cross framework control mapping" - "deadline overlap planning" - "compliance evidence reuse" - "Framework overlap" - "Evidence reuse" - "Control mapping" - "Compliance efficiency" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Framework Overlap and Evidence Reuse for Regulatory Universal Timeline Use Sorena AI Regulatory Universal Timeline to spot deadline overlap. *Overlap Guide* *Reuse Governance* ## Framework Overlap and Evidence Reuse Use the merged timeline to see when obligations land together, then build reuse decisions outside the viewer with full traceability. The timeline helps you find timing overlap. It does not prove two obligations are substantively identical. The universal timeline is strong at showing timing overlap across source timelines. It is not a control mapping engine. A defensible reuse model starts by keeping each legal source separate, then mapping reuse only after you compare obligation intent, evidence needs, and exception conditions. ## Use the timeline to detect timing overlap, not obligation equivalence When multiple source timelines cluster in the same period, the viewer can reveal where the same teams are likely to feel pressure. That is the right moment to ask whether one control or evidence package can serve more than one obligation. Do not assume overlap means sameness. Two events can share a month and still require different evidence, different approval paths, or different legal interpretations. - Use the timeline first to identify high density deadline windows - Keep each source timeline, category, and article reference intact during mapping - Require an explicit comparison before merging delivery work or evidence packages ## Build the reuse register outside the timeline The timeline viewer does not store your overlap decisions. Keep a separate reuse register keyed to the source label, event title, article reference, and source URL so future reviewers can reconstruct why you reused a control or artifact. That register becomes the authoritative record for exceptions, reviewer approval, and refresh dates. - Record the source event that triggered the reuse decision - Record the control objective or evidence package being reused - Record reviewer, approval date, and next review date - Record the limits of reuse and any framework specific add ons ## Reuse evidence by objective, not by page title The safest reuse method is to group evidence by objective such as governance, supplier assurance, incident response, or technical testing. Then you can assess whether each framework accepts the same artifact with the same level of freshness and detail. This is more reliable than reusing an artifact only because two pages in your catalog have similar titles or due dates. - Define freshness, owner, integrity, and approval rules for each evidence package - Add framework specific supplements when one obligation needs more detail than another - Retire reused evidence when the source interpretation or system state changes *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep Framework Overlap and Evidence Reuse in one governed evidence system SSOT can take Framework Overlap and Evidence Reuse from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on Framework Overlap and can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for Framework Overlap and Evidence Reuse](/solutions/ssot.md): Start from Framework Overlap and Evidence Reuse and keep documents, evidence, and control records in one governed system. - [Talk through Framework Overlap and](/contact.md): Review your current process, evidence gaps, and next steps for Framework Overlap and Evidence Reuse. ## Escalate non-reusable obligations early Some obligations will resist reuse because they impose unique reporting formats, product scope tests, or supervisory expectations. Those cases should be flagged early so leadership sees the real residual work. A reuse program fails when it hides non-reusable work inside a broad overlap narrative. - Maintain a list of obligations that need dedicated evidence or workflow - Explain why the reuse model stops at a certain point - Review non-reusable obligations in every steering cycle until delivery closes ## Primary sources - [EUR-Lex portal](https://eur-lex.europa.eu/homepage.html?locale=en&ref=sorena.io) - Primary source portal for EU obligations that commonly overlap in the merged timeline. - [Federal Register of Legislation (Australia)](https://www.legislation.gov.au/?ref=sorena.io) - Primary source portal for Australian obligations represented in the merged timeline. - [UK legislation](https://www.legislation.gov.uk/?ref=sorena.io) - Primary source portal for UK obligations represented in the merged timeline. ## Related Topic Guides - [How to Use Regulatory Universal Timelines for Execution Planning](/artifacts/global/regulatory-universal-timelines/how-to-use.md): Step by step guide for using Sorena AI Regulatory Universal Timeline: source filters, category chips, event detail, zoom, minimap navigation. - [Regulatory Universal Timeline Compliance Calendar Guide](/artifacts/global/regulatory-universal-timelines/compliance-calendar.md): Build an internal compliance calendar from Sorena AI Regulatory Universal Timeline by converting external events into owned milestones, collision windows. - [Regulatory Universal Timeline Export and Sharing Guide](/artifacts/global/regulatory-universal-timelines/export-and-sharing.md): Share Sorena AI Regulatory Universal Timeline correctly: browser generated PNG export, filter context, version notes, leadership reporting packs. - [Regulatory Universal Timeline Glossary](/artifacts/global/regulatory-universal-timelines/glossary.md): Glossary for Sorena AI Regulatory Universal Timeline covering source timelines, category chips, milestone events, ranged events, export snapshots. - [What Is Included in Regulatory Universal Timeline](/artifacts/global/regulatory-universal-timelines/what-is-included.md): Review current coverage for Sorena AI Regulatory Universal Timeline: which local timeline files are merged, what event fields are included. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/regulatory-universal-timelines/framework-overlap-and-evidence-reuse --- --- title: "Regulatory Universal Timeline Export and Sharing Guide" canonical_url: "https://www.sorena.io/artifacts/global/regulatory-universal-timelines/export-and-sharing" source_url: "https://www.sorena.io/artifacts/global/regulatory-universal-timelines/export-and-sharing" author: "Sorena AI" description: "Share Sorena AI Regulatory Universal Timeline correctly: browser generated PNG export, filter context, version notes, leadership reporting packs." published_at: "2026-02-12" updated_at: "2026-02-12" keywords: - "regulatory universal timeline export" - "compliance timeline PNG export" - "governance reporting timeline" - "audit safe timeline sharing" - "timeline version control" - "Timeline export" - "PNG export" - "Compliance reporting" - "Governance reporting" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Regulatory Universal Timeline Export and Sharing Guide Share Sorena AI Regulatory Universal Timeline correctly: browser generated PNG export, filter context, version notes, leadership reporting packs. *Reporting Guide* *PNG Snapshot Controls* ## Export and Share Regulatory Universal Timelines Share the current viewer state without losing context about filters, dates, and assumptions. The live viewer generates a PNG snapshot in the browser. Treat that image as a reporting artifact that needs scope notes and version control. A timeline image is only useful when the recipient knows what it shows and what it leaves out. The universal timeline export should be shared with filter context, export date, and clear scope notes so leadership and audit teams do not over-read a single screenshot. ## Know what the export contains The viewer generates a PNG snapshot of the current timeline state. That export captures the visible timeline with its title block and dates, but it does not preserve your meeting discussion, legal interpretation notes, or the reasoning behind selected filters. If your team uses publication workflows, Sorena can also generate JPG derivatives for artifact publishing. For operating governance, the primary user-facing export on this page is the PNG snapshot. - Assume the PNG is a visual snapshot, not a full system record - Store the export date and selected filter context with every shared image - Keep a linked work item or memo for interpretation notes and decisions ## Share audience specific packs from one source view Leadership, control owners, and auditors usually need different levels of detail. Use the same source timeline view, then attach different supporting notes instead of making three separate date lists by hand. That approach keeps the visual picture consistent while letting each audience receive the context they actually need. - Executive pack: PNG plus top collision risks, needed decisions, and owner summary - Program pack: PNG plus milestone ladder, dependencies, blockers, and next actions - Audit pack: PNG plus source event references, evidence locations, and review history ## Version exports like governance records The merged dataset changes when local timeline files change. A shared export should therefore carry a publication date and a simple version note so later readers know which build they are looking at. This is especially important when the same source timeline receives new dates, corrections, or added event windows. - Name stored exports with date, program scope, and meeting or decision context - Keep superseded exports instead of overwriting them in shared folders - Record why a later export replaced an earlier one ## Do not let image sharing replace issue tracking PNG export is excellent for alignment, but it is not a task system. The moment a date becomes action, move it into your program tracker with owner, dependency, and evidence fields. That separation keeps the universal timeline clean while preserving accountability in the tool that actually runs delivery. - Use the timeline to align stakeholders on timing and priority - Use your project or GRC system to own tasks and evidence - Link the tracker item back to the source timeline event that triggered it *Recommended next step* *Placement: near the end of the main content before related guides* ## Use Export and Share Regulatory Universal Timelines as a cited research workflow Research Copilot can take Export and Share Regulatory Universal Timelines from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on Export and Share can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Export and Share Regulatory Universal Timelines](/solutions/research-copilot.md): Start from Export and Share Regulatory Universal Timelines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Export and Share](/contact.md): Review your current process, evidence gaps, and next steps for Export and Share Regulatory Universal Timelines. ## Primary sources - [EUR-Lex portal](https://eur-lex.europa.eu/homepage.html?locale=en&ref=sorena.io) - Primary legal source portal for EU events that often appear in shared governance packs. - [Federal Register of Legislation (Australia)](https://www.legislation.gov.au/?ref=sorena.io) - Primary legal source portal for Australian dates that may appear in exported views. - [UK legislation](https://www.legislation.gov.uk/?ref=sorena.io) - Primary legal source portal for UK dates represented in the merged timeline. ## Related Topic Guides - [Framework Overlap and Evidence Reuse for Regulatory Universal Timeline](/artifacts/global/regulatory-universal-timelines/framework-overlap-and-evidence-reuse.md): Use Sorena AI Regulatory Universal Timeline to spot deadline overlap. - [How to Use Regulatory Universal Timelines for Execution Planning](/artifacts/global/regulatory-universal-timelines/how-to-use.md): Step by step guide for using Sorena AI Regulatory Universal Timeline: source filters, category chips, event detail, zoom, minimap navigation. - [Regulatory Universal Timeline Compliance Calendar Guide](/artifacts/global/regulatory-universal-timelines/compliance-calendar.md): Build an internal compliance calendar from Sorena AI Regulatory Universal Timeline by converting external events into owned milestones, collision windows. - [Regulatory Universal Timeline Glossary](/artifacts/global/regulatory-universal-timelines/glossary.md): Glossary for Sorena AI Regulatory Universal Timeline covering source timelines, category chips, milestone events, ranged events, export snapshots. - [What Is Included in Regulatory Universal Timeline](/artifacts/global/regulatory-universal-timelines/what-is-included.md): Review current coverage for Sorena AI Regulatory Universal Timeline: which local timeline files are merged, what event fields are included. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/regulatory-universal-timelines/export-and-sharing --- --- title: "What Is Included in Regulatory Universal Timeline" canonical_url: "https://www.sorena.io/artifacts/global/regulatory-universal-timelines/what-is-included" source_url: "https://www.sorena.io/artifacts/global/regulatory-universal-timelines/what-is-included" author: "Sorena AI" description: "Review current coverage for Sorena AI Regulatory Universal Timeline: which local timeline files are merged, what event fields are included." published_at: "2026-02-12" updated_at: "2026-02-12" keywords: - "what is included in regulatory universal timeline" - "timeline coverage" - "merged source timelines" - "timeline event fields" - "compliance timeline limitations" - "Merged datasets" - "Event model" - "Source validation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # What Is Included in Regulatory Universal Timeline Review current coverage for Sorena AI Regulatory Universal Timeline: which local timeline files are merged, what event fields are included. *Coverage Guide* *Current Build Scope* ## What Is Included in Regulatory Universal Timelines Know exactly what the merged viewer includes today before you rely on it in planning or reporting. Coverage is driven by local timeline files in the artifacts catalog. If a source timeline is not present there, it is not present here. The current build auto-merges every local file in the artifacts data directory that ends with -timeline.json. That means the universal timeline is comprehensive only within that local source set. It is not a live crawler and it does not infer timelines for artifacts that do not ship with timeline data. ## Current source timeline coverage As of the current build, the viewer merges 38 local source timelines and 1297 dated events. The source timelines currently span APAC, EU, LATAM, UK, and US artifacts. The current merged source set includes the following local timeline datasets. - APAC: Australia Cyber Security Act and Singapore PDPA - LATAM: Brazil LGPD - UK: UK GDPR, UK Online Safety Act, and UK PSTI - US: CCPA and CPRA - EU: Accessibility Act, AI Act, Batteries Regulation, CRA, CSDDD, CSRD, Data Act, DDP, Deforestation Regulation, DMA, DORA, DSA, EED, eIDAS, EMC Directive, ePrivacy, ESPR DPP, ESPR, GDPR, GPSR, Green Claims, LVD, Machinery Regulation, MDR, MSR, NIS2, PPWR, RED, RoHS, and Taxonomy Regulation ## What each event record can contain The merged viewer uses a consistent event model. Every event has a date, category, title, summary, and milestone flag. Events can also include an end date, article reference, and source URL. Those fields are what let the viewer support both quick visual scanning and deeper event inspection when a team needs traceability. - date: the event start or single day marker - endDate: optional end date for a transition or reporting window - category: the namespaced category used for filtering - title: the normalized event title shown in the merged view - article: optional article or context field shown with source label prefix - summary: short explanatory text used in event detail - url: optional source link for direct reference - milestone: boolean marker used to distinguish milestone style events ## How labels are normalized in the merged view The builder preserves source separation but normalizes some labels for readability. It gives explicit stable labels to selected frameworks such as EU DORA, EU NIS2, EU CRA, EU Data Act, and Australia. Other source timelines use an uppercase label derived from the local source key. This is why some labels appear as formal framework names while others appear as stable source identifiers. - Categories are namespaced per source timeline before they are shown as filter chips - Event titles are prefixed with the source label unless they already begin with it - The article field is also prefixed with the source label to keep context visible in the merged detail panel - Closely related source timelines may appear separately if they are maintained as separate local datasets ## Known operating limits The universal timeline is a strong planning and coordination view, but it does not replace legal analysis or program management tooling. Teams should understand those limits before using the viewer as a formal control in governance routines. - The viewer does not determine whether a framework applies to your entity - The viewer does not assign owners, tasks, or evidence packages for you - The viewer supports PNG export, not CSV or ICS export in the shipped user flow - High impact dates should still be validated against the official source link or legal text before external commitment *Recommended next step* *Placement: after the scope or definition section* ## Use What Is Included in Regulatory Universal Timelines as a cited research workflow Research Copilot can take What Is Included in Regulatory Universal Timelines from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on What Is Included in can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for What Is Included in Regulatory Universal Timelines](/solutions/research-copilot.md): Start from What Is Included in Regulatory Universal Timelines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through What Is Included in](/contact.md): Review your current process, evidence gaps, and next steps for What Is Included in Regulatory Universal Timelines. ## Primary sources - [EUR-Lex portal](https://eur-lex.europa.eu/homepage.html?locale=en&ref=sorena.io) - Primary legal source portal for EU source timelines in the current merged build. - [Federal Register of Legislation (Australia)](https://www.legislation.gov.au/?ref=sorena.io) - Primary legal source portal for the Australian source timeline in the current merged build. - [Planalto - Lei Geral de Protecao de Dados Pessoais](https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2018/lei/l13709.htm?ref=sorena.io) - Primary legal text for the Brazil LGPD timeline in the current merged build. - [UK legislation](https://www.legislation.gov.uk/?ref=sorena.io) - Primary legal source portal for UK timelines in the current merged build. ## Related Topic Guides - [Framework Overlap and Evidence Reuse for Regulatory Universal Timeline](/artifacts/global/regulatory-universal-timelines/framework-overlap-and-evidence-reuse.md): Use Sorena AI Regulatory Universal Timeline to spot deadline overlap. - [How to Use Regulatory Universal Timelines for Execution Planning](/artifacts/global/regulatory-universal-timelines/how-to-use.md): Step by step guide for using Sorena AI Regulatory Universal Timeline: source filters, category chips, event detail, zoom, minimap navigation. - [Regulatory Universal Timeline Compliance Calendar Guide](/artifacts/global/regulatory-universal-timelines/compliance-calendar.md): Build an internal compliance calendar from Sorena AI Regulatory Universal Timeline by converting external events into owned milestones, collision windows. - [Regulatory Universal Timeline Export and Sharing Guide](/artifacts/global/regulatory-universal-timelines/export-and-sharing.md): Share Sorena AI Regulatory Universal Timeline correctly: browser generated PNG export, filter context, version notes, leadership reporting packs. - [Regulatory Universal Timeline Glossary](/artifacts/global/regulatory-universal-timelines/glossary.md): Glossary for Sorena AI Regulatory Universal Timeline covering source timelines, category chips, milestone events, ranged events, export snapshots. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/regulatory-universal-timelines/what-is-included --- --- title: "Regulatory Universal Timeline Glossary" canonical_url: "https://www.sorena.io/artifacts/global/regulatory-universal-timelines/glossary" source_url: "https://www.sorena.io/artifacts/global/regulatory-universal-timelines/glossary" author: "Sorena AI" description: "Glossary for Sorena AI Regulatory Universal Timeline covering source timelines, category chips, milestone events, ranged events, export snapshots." published_at: "2026-02-12" updated_at: "2026-02-12" keywords: - "regulatory universal timeline glossary" - "compliance terminology" - "timeline event model terms" - "milestone event definition" - "evidence reuse terminology" - "Regulatory timeline glossary" - "Timeline event model" - "Governance language" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Regulatory Universal Timeline Glossary Glossary for Sorena AI Regulatory Universal Timeline covering source timelines, category chips, milestone events, ranged events, export snapshots. *Terminology Guide* *Event Model Language* ## Regulatory Universal Timeline Glossary Use one vocabulary for the merged timeline, the delivery calendar, and governance reporting. Shared terms reduce ambiguity when legal, security, product, and audit teams read the same timeline snapshot. This glossary is tuned to the actual universal timeline implementation and the operating model around it. It defines the core viewer terms as well as the program terms needed when events move from the timeline into owned delivery work. ## Viewer and data model terms These terms describe how the merged timeline is built and how users should interpret what they see on screen. Use them when explaining the timeline itself, not when describing internal remediation work. - Source timeline: one local timeline dataset merged into the universal viewer - Source label: the framework label shown after normalization from source key or regulation identifier - Category chip: a filter chip representing a namespaced category inside one source timeline - Milestone event: an event marked as a milestone in the underlying data model - Ranged event: an event that includes both a start date and an end date - Event detail: the title, article context, summary, and source link shown when an event is opened ## Planning and delivery terms These terms describe how external dates become internal work. Use them in program boards, governance packs, and delivery reviews. - Internal milestone ladder: your ordered set of analysis, design, implementation, assurance, and closure dates built from one external event - Collision window: a period where multiple source timelines create pressure on the same owners or dependencies - Dependency blocker: an unresolved issue that prevents an internal milestone from closing - Control owner: the role accountable for implementation quality and evidence readiness - Escalation trigger: a predefined threshold that forces management review or re-prioritization ## Evidence and reporting terms These terms matter when you export or audit the timeline driven program. They help separate a useful visual snapshot from the evidence record behind it. - Export snapshot: the PNG image generated from the current viewer state - Evidence package: the set of artifacts that proves an internal milestone or external obligation has been met - Evidence freshness: the maximum accepted age for a supporting artifact - Reuse register: the external record that documents when one artifact supports more than one obligation - Version note: the date and change explanation attached to a shared export or calendar update ## Interpretation and governance terms These terms govern how the timeline should and should not be used. They are essential for keeping planning useful without overstating legal certainty. - Scope assumption: a documented interpretation about entities, products, or services considered in scope - Residual regulatory risk: the remaining compliance risk after controls and delivery actions are complete - Non-reusable obligation: a requirement that cannot be fully covered by a shared control or evidence package - Decision log: the record of governance approvals, exceptions, and changed priorities linked to the timeline - Planning tool: the correct role of the universal timeline, which is coordination and prioritization rather than legal determination authority *Recommended next step* *Placement: near the end of the main content before related guides* ## Use Regulatory Universal Timeline Glossary as a cited research workflow Research Copilot can take Regulatory Universal Timeline Glossary from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on Regulatory Universal Timeline can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Regulatory Universal Timeline Glossary](/solutions/research-copilot.md): Start from Regulatory Universal Timeline Glossary and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Regulatory Universal Timeline](/contact.md): Review your current process, evidence gaps, and next steps for Regulatory Universal Timeline Glossary. ## Primary sources - [EUR-Lex portal](https://eur-lex.europa.eu/homepage.html?locale=en&ref=sorena.io) - Legal terminology and milestone context for EU source timelines. - [Federal Register of Legislation (Australia)](https://www.legislation.gov.au/?ref=sorena.io) - Legislative terminology source for Australian timelines in the merged view. - [UK legislation](https://www.legislation.gov.uk/?ref=sorena.io) - Legislative terminology source for UK timelines in the merged view. ## Related Topic Guides - [Framework Overlap and Evidence Reuse for Regulatory Universal Timeline](/artifacts/global/regulatory-universal-timelines/framework-overlap-and-evidence-reuse.md): Use Sorena AI Regulatory Universal Timeline to spot deadline overlap. - [How to Use Regulatory Universal Timelines for Execution Planning](/artifacts/global/regulatory-universal-timelines/how-to-use.md): Step by step guide for using Sorena AI Regulatory Universal Timeline: source filters, category chips, event detail, zoom, minimap navigation. - [Regulatory Universal Timeline Compliance Calendar Guide](/artifacts/global/regulatory-universal-timelines/compliance-calendar.md): Build an internal compliance calendar from Sorena AI Regulatory Universal Timeline by converting external events into owned milestones, collision windows. - [Regulatory Universal Timeline Export and Sharing Guide](/artifacts/global/regulatory-universal-timelines/export-and-sharing.md): Share Sorena AI Regulatory Universal Timeline correctly: browser generated PNG export, filter context, version notes, leadership reporting packs. - [What Is Included in Regulatory Universal Timeline](/artifacts/global/regulatory-universal-timelines/what-is-included.md): Review current coverage for Sorena AI Regulatory Universal Timeline: which local timeline files are merged, what event fields are included. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/regulatory-universal-timelines/glossary --- --- title: "AU Cyber Security Act Compliance Decision Map: Scope, 72-Hour Reporting, Smart Device Rules" canonical_url: "https://www.sorena.io/artifacts/au-cyber-security-act-compliance-decision-map" source_url: "https://www.sorena.io/artifacts/au-cyber-security-act-compliance-decision-map" author: "Sorena AI" description: "Advanced AU Cyber Security Act Compliance Decision Map for Australia Cyber Security Act 2024 implementation: scope testing, smart device security standards." keywords: - "AU Cyber Security Act Compliance Decision Map compliance" - "AU Cyber Security Act Compliance Decision Map guide" - "AU Cyber Security Act Compliance Decision Map checklist" - "AU Cyber Security Act Compliance Decision Map requirements" - "AU Cyber Security Act Compliance Decision Map template" - "Australia Cyber Security Act 2024 compliance" - "smart device security standards Australia" - "ransomware payment reporting 72 hours Australia" - "reporting business entity Australia" - "CIRB review readiness" - "SOCI Part 2B" - "AU Cyber Security Act Compliance Decision Map" - "Australia Cyber Security Act 2024" - "Cyber Security Act 2024" - "Smart devices" - "Ransomware payment reporting 72 hours" - "CIRB" - "APAC cyber compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # AU Cyber Security Act Compliance Decision Map: Scope, 72-Hour Reporting, Smart Device Rules Advanced AU Cyber Security Act Compliance Decision Map for Australia Cyber Security Act 2024 implementation: scope testing, smart device security standards. ![AU Cyber Security Act Compliance Decision Map by Sorena AI](https://cdn.sorena.io/cheatsheets/sorena-ai-au-cyber-security-act-cheatsheet-small.jpg) *CSA 2024* *Free Resource* ## AU Cyber Security Act Compliance Decision Map This AU Cyber Security Act Compliance Decision Map helps teams move from legal text to execution. Confirm scope for smart device obligations, classify reporting business entity status, and operationalise the 72-hour ransomware payment reporting workflow with accountable owners and evidence checkpoints. Grounded in the Cyber Security Act 2024, Smart Devices Rules 2025, Ransomware Payment Reporting Rules 2025, and CIRB Rules 2025. Use this as a practical implementation control for APAC cyber compliance planning. [Create my custom view](/solutions/assessment.md) ## What you can decide faster - **Product scope and standards**: Decide if a device is in-scope and apply Schedule 1 controls, statement of compliance duties, and retention requirements. - **72-hour reporting trigger**: Confirm reporting business entity status, payment trigger logic, required report fields, and escalation pathways. - **Incident coordination and CIRB**: Map Part 4 voluntary coordination and Part 5 CIRB review readiness to governance and evidence operations. By Sorena AI | Updated Mar 2026 | No sign-up required **Key highlights:** Smart device scope | 72-hour reporting | Evidence-ready controls ## Primary sources - [Cyber Security Act 2024 (No. 98, 2024)](https://www.legislation.gov.au/C2024A00098?ref=sorena.io) - Primary legislation for Parts 2-5 including smart devices, ransomware reporting, coordination, and CIRB. - [Cyber Security (Security Standards for Smart Devices) Rules 2025 (F2025L00276)](https://www.legislation.gov.au/F2025L00276?ref=sorena.io) - Defines in-scope consumer-grade products, Schedule 1 controls, and statement of compliance requirements. - [Cyber Security (Ransomware Payment Reporting) Rules 2025 (F2025L00278)](https://www.legislation.gov.au/F2025L00278?ref=sorena.io) - Defines $3 million turnover threshold and required fields for ransomware payment reports. - [Cyber Security (Cyber Incident Review Board) Rules 2025 (F2025L00277)](https://www.legislation.gov.au/F2025L00277?ref=sorena.io) - Defines CIRB review governance, prioritisation criteria, and board/expert panel procedures. ## Compliance quick-start *Australia* | Time | Step | Detail | | --- | --- | --- | | Part 2 + Rules | Smart device controls | Schedule 1 controls and statement of compliance requirements for consumer-grade relevant connectable products. | | 72h | Ransomware reporting | Report within 72 hours after payment or awareness under Part 3 and the reporting rules. | | Part 4-5 | Coordination and CIRB | Voluntary coordination with the National Cyber Security Coordinator and no-fault CIRB review procedures. | Use the map to connect legal triggers, implementation checklists, and auditable evidence owners. | Value | Metric | | --- | --- | | 4 Mar 2026 | Schedule 1 starts | | 72h | Report clock | | $3m | Turnover threshold | | CIRB | Reviews | ## Key dates for AU Cyber Security Act implementation *CSA 2024 Timeline* Track commencement points and operational deadlines across the Act and subordinate rules so legal, security, and product teams can execute with shared timing assumptions. ## Decide faster what the Act means for your product and incident workflows *CSA 2024 Decision Map* Follow yes/no logic from applicability to an operational outcome: smart device control program, ransomware reporting process, significant incident coordination playbook, and CIRB document readiness. *Go further* ## Turn this decision map into an execution-ready compliance program Use the APAC Australia Cyber Security Act topic pages to convert map outcomes into requirements, checklist controls, deadlines, templates, and evidence workflows. - Build a requirement-to-control map for smart devices, ransomware reporting, and CIRB readiness - Operationalise the 72-hour ransomware reporting workflow with owners, inputs, and quality checks - Create policy and template sets for statement of compliance, recordkeeping, and incident reporting - Link controls to evidence so compliance status is defensible for audit and regulator scrutiny - [Open requirements deep dive](/artifacts/apac/australia-cyber-security-act/requirements.md): Map law and rules to operational obligations and evidence expectations. - **Download Decision Map**: Share scope and decision logic across product, security, legal, and compliance teams. - **Download Timeline**: Share commencement milestones and reporting deadlines. - [Open compliance checklist](/artifacts/apac/australia-cyber-security-act/checklist.md): Use an audit-ready checklist with owners, acceptance criteria, and evidence outputs. ## Decision Steps ### OVERVIEW: Cyber Security Act 2024 (Cth) - compliance decision map - Part 2: smart device security standards (connectable products). - Part 3: ransomware payment reporting (72-hour report) for reporting business entities. - Part 4: voluntary information sharing with the National Cyber Security Coordinator for significant incidents. - Part 5: Cyber Incident Review Board (CIRB) reviews and document production notices. - -> Smart device security standards ### PART 2: Smart device security standards - Applies to relevant connectable products manufactured/supplied on/after Part 2 commencement (s 13). - Current standard covers consumer-grade connectable products acquired by a consumer (Rules s 8). - Mandatory Schedule 1 requirements start 4 Mar 2026 (Rules commencement). - -> Do you manufacture or supply a relevant connectable product that will be acquired in Australia? ### STEP 1: Do you manufacture or supply a relevant connectable product that will be acquired in Australia? *Reference: CSA ss 13, 15, 16* - Relevant connectable product: internet-connectable or network-connectable; not exempted under rules. - Part 2 applies to products manufactured on/after Part 2 commencement OR supplied (not second hand) on/after commencement. - Obligations trigger where you are aware (or should be aware) the product will be acquired in Australia in specified circumstances. - **YES** Is the product a consumer grade relevant connectable product acquired by a consumer in Australia? - **NO** Ransomware payment reporting obligations ### STEP 2: Is the product a consumer grade relevant connectable product acquired by a consumer in Australia? *Reference: Smart Devices Rules 2025 ss 6, 8* - Consumer grade: intended/likely for personal, domestic or household use. - Excluded: desktops/laptops, tablets, smartphones, therapeutic goods, road vehicles, vehicle components. - Specified circumstance: acquired in Australia by a consumer (ACL). - **YES** Mandatory smart device security standard applies - **NO** No mandatory smart device standard under current Rules ### PART 3: Ransomware payment reporting obligations - If you are a reporting business entity and a ransomware payment is made, report within 72 hours (CSA s 27). - Turnover threshold: $3 million (Rules s 6). - Payment can be money or a non-monetary benefit. - -> Are you a 'reporting business entity' at the time the ransomware payment is made? ### STEP 3: Are you a 'reporting business entity' at the time the ransomware payment is made? *Reference: CSA s 26(2); Ransomware Rules 2025 s 6* - Track A: business in Australia + previous FY annual turnover > $3m (or prorated), and not a Commonwealth/State body, and not a SOCI responsible entity. - Track B: responsible entity for a critical infrastructure asset to which SOCI Act Part 2B applies. - If unsure: confirm turnover and whether you are a SOCI responsible entity. - **YES** Did an extortion demand and a ransomware payment occur in connection with a cyber security incident impacting you? - **NO** Significant incident coordination (voluntary) ### STEP 4: Did an extortion demand and a ransomware payment occur in connection with a cyber security incident impacting you? *Reference: CSA s 26(1)* - Incident occurred/occurring/imminent and is a cyber security incident (s 9). - Demand made by an extorting entity to benefit from the incident/its impact on you. - You made a payment/benefit, or you're aware another entity made it on your behalf, directly related to the demand. - **YES** Ransomware payment report required - **NO** Significant incident coordination (voluntary) ### PART 4: Significant incident coordination (voluntary) - If impacted by (or likely impacted by) a significant cyber security incident, you may voluntarily share info with the National Cyber Security Coordinator (CSA s 35). - Impacted entity scope: carrying on a business in Australia OR a SOCI responsible entity (CSA s 35(1)(d)). - There is no obligation to provide information in response to a request (note to s 35). - Protections apply (Div 3) and this does not replace other reporting duties (CSA s 44). - -> Are you impacted by a 'significant cyber security incident'? ### STEP 5: Are you impacted by a 'significant cyber security incident'? *Reference: CSA s 34* - Material risk of serious prejudice to social/economic stability, defence, or national security; OR - Incident is/could be of serious concern to the Australian people. - **YES** Voluntary information sharing available - **NO** Cyber Incident Review Board (CIRB) ### PART 5: Cyber Incident Review Board (CIRB) - CIRB can cause reviews into certain incidents (CSA s 46). - Entities may be requested (voluntary) or required (notice) to provide documents (CSA ss 48-50). - Draft review reports must not be disclosed (CSA s 59). - -> Could your incident be eligible for a CIRB review (or are you referring one)? ### STEP 6: Could your incident be eligible for a CIRB review (or are you referring one)? *Reference: CSA s 46* - Referrals: Minister, Coordinator, impacted entity, or Board member (s 46(1)). - Criteria: serious prejudice, novel/complex methods/tech, or serious concern (s 46(3)). - Timing: only after incident + immediate response ended, and Minister approves terms (s 46(2)). - **YES** Have you received a notice requiring you to produce documents (s 49)? - **NO** Be ready to cooperate if approached ### STEP 7: Have you received a notice requiring you to produce documents (s 49)? *Reference: CSA ss 48-50* - s 48 request for info/docs is voluntary (no requirement to comply). - s 49 notice (compulsory) can be issued to certain non-government entities involved in the incident, after a s 48 request; must allow at least 14 days. - Non-compliance with a s 49 notice is a civil penalty (s 50), subject to exceptions. - **YES** Comply with the s 49 notice (document production) - **NO** Be ready to cooperate if approached ## Reference Information ### Key definitions (CSA) - Cyber security incident: s 9 (tied to SOCI meaning + constitutional limits). - Relevant connectable product: internet- or network-connectable; not exempted (s 13). - Ransomware payment: payment/benefit to extorting entity directly related to demand (s 26). - Reporting business entity: turnover or SOCI Part 2B responsible entity test (s 26). - Significant cyber security incident: high-impact/serious concern test (s 34). ### Extraterritorial reach - CSA applies both within and outside Australia (s 5). - Practical triggers still depend on the Part (e.g., products acquired in Australia; business in Australia; SOCI Part 2B links). ### Security standard (Schedule 1) - core requirements - Passwords: unique per product or user-defined; not incremental/guessable; avoid public info and raw serials (crypto/hashing if used). - Security issue reporting: publish contact + acknowledgement + status updates; accessible/clear; in English; free; no personal info required. - Support period & updates: publish defined support period (end date) for security updates; do not shorten; publish extensions; ensure prominence and clarity (including understandable without prior technical knowledge). ### Statement of compliance (Rules s 9) - include - Product type + batch identifier. - Manufacturer name/address + authorised representative(s) (including those in Australia). - Declarations: product complies with standard + manufacturer complied with other Schedule 1 obligations. - Defined support period at issue date; plus signatory signature/name/function + place/date of issue. - Retention: 5 years (Rules s 10). ### Supplier obligations (high-level) - Do not supply non-compliant products in Australia when aware/should be aware of relevant circumstances. - Supply product with manufacturer-prepared statement of compliance. - Retain copy of statement for required period (5 years for current standard). ### Enforcement tools (Part 2) - Secretary may issue compliance, stop, and recall notices (Div 3). - Internal review is available for compliance/stop/recall notices (and certain variations) (s 22). - Failure to comply with a recall notice can trigger public notification (s 20), including matters prescribed by rules (Smart Devices Rules s 11). - Independent examination/audit may be used to assess compliance and statements (s 23). ### Scope notes (current standard) - Current standard only covers consumer-grade relevant connectable products acquired by a consumer in Australia (Rules s 8). - Excluded product categories are not subject to Schedule 1 (Rules s 8). - Act allows future standards for other product classes and acquisition circumstances (CSA s 14). ### Turnover threshold (Rules s 6) - Threshold: $3 million (previous financial year). - Part-year formula: $3m x (days carried on / days in previous FY). - SOCI Part 2B responsible entities are in scope regardless of turnover; SOCI responsible entities not covered by Part 2B are not reporting business entities (CSA s 26(2)). ### Report contents (CSA s 27 + Rules s 7) - Entity details: ABN (if any) + address for reporting entity and payor (Rules s 7(2)-(3)). - Incident: when occurred/estimated; when aware; impact on infrastructure + customers; ransomware/malware variant; vulnerabilities exploited; info to assist response (Rules s 7(4)). - Demand: amount/description + method demanded (Rules s 7(5)). - Payment/benefit: amount/description + method provided (Rules s 7(6)). - Communications: nature/timing; brief description; pre-payment negotiations (Rules s 7(7)). ### Protections (Part 3) - Use/disclosure restricted to permitted purposes and not for most civil/regulatory enforcement (CSA ss 29-30; Privacy Act limits apply). - Disclosure to State bodies requires consent (CSA s 11). - Legal professional privilege preserved (s 31). - Info not admissible against reporting entity in most proceedings (s 32), with limited exceptions. ### Liability protection (Part 3) - Good faith compliance with s 27: entity not liable for damages for acts/omissions (s 28(1)). - Officers, employees, and agents also protected when acting in good faith (s 28(2)). - Entity bears an evidential burden when relying on this protection (s 28(3)). ### Who receives the report? - Report goes to a 'designated Commonwealth body' (CSA s 27(1)). - Designated body is set by rules; if none, defaults to the Department + ASD (CSA s 8 definition). - Form may be approved by Secretary; manner may be prescribed by rules (CSA s 27(4)). ### National Cyber Security Coordinator (role) - Lead whole-of-government coordination and triaging of action in response to a significant cyber security incident (s 37). - Inform and advise the Minister and whole of Government on the response (s 37). ### Parallel reporting may still apply - Voluntary sharing under Part 4 does not affect other legal requirements to provide information (CSA s 44). - Act examples: Part 3 ransomware reporting; SOCI Act Part 2B; Telecommunications Act 1997. - Common outside-CSA reporting: OAIC NDB scheme (Privacy Act) and APRA CPS 234 (if applicable). ### Information sharing beyond significant incidents (ss 36, 39) - If it's unclear whether an incident is a cyber security incident or a significant cyber security incident, you can still provide information (s 36(1)). - NCSC may collect and use the information to determine whether the incident qualifies (s 36(2)). - This collection/use is authorised for Privacy Act purposes (note to s 36(2)). - If you provide information about an incident that is not significant (or not a cyber security incident), NCSC use/disclosure is still limited to specific purposes (s 39). ### Part 4 protections (high-level) - Use/disclosure limited to permitted purposes and not for most civil/regulatory enforcement (CSA ss 38-40; Privacy Act limits apply). - Legal professional privilege preserved (s 41). - Info not admissible against impacted entity in most proceedings (s 42), with limited exceptions. - NCSC may be certified as not compellable as a witness for certain matters (s 43). - Disclosure to State bodies requires consent (s 11). ### CIRB Rules 2025 (process highlights) - Board must consider referrals and decide whether a review should be conducted (Rules s 7). - Prioritisation factors include severity/scale and panel availability (Rules s 8). - Reviews must not be conducted if they would interfere with or prejudice investigations/proceedings (Rules s 10). - Board publishes notice when a review will be conducted (Rules s 11). - Board may discontinue a review at any time and must publish notice within 28 days (CSA s 47). ### CIRB reports: publication, redaction, and no-blame constraints - Final review report must be published, excluding redacted sensitive review information (s 52(6)). - Final review report must not apportion blame, determine liability, identify individuals without consent, or allow adverse inference that an entity is subject of review (s 52(4)). - Sensitive review information must be redacted; protected review report contains redacted info + reasons and is provided to Minister and Prime Minister (ss 53-54). ### Confidentiality & protections (Part 5) - If you receive a draft review report, do not disclose/use it except allowed purposes (CSA s 59). - Legal professional privilege preserved (s 57); admissibility limits (s 58). - Use/disclosure restrictions apply to the Board and recipients (ss 55-56). - Disclosure to State bodies requires consent under the CSA framework (s 11). ### Other Australian cyber reporting obligations (common) - SOCI Act Part 2B incident reporting (critical infrastructure). - SOCI Act CIRMP and other enhanced cyber security obligations may also apply (separate regime; depends on asset classification). - Telecommunications Act 1997 reporting (telecommunications entities). - Privacy Act NDB scheme (OAIC): assess within 30 days; notify OAIC/individuals for eligible data breaches. - APRA CPS 234: notify APRA within 72 hours of certain information security incidents (if APRA-regulated). ### Regulatory powers & enforcement framework (Part 6) - CSA civil penalty provisions are enforceable under the Regulatory Powers (Standard Provisions) Act 2014 (s 79). - Enforceable undertakings can cover CSA civil penalty provisions and smart device sections 15-16 (s 79(2)). - Part 6 also includes monitoring/investigation powers and infringement notices mechanisms. ## Possible Outcomes ### [APPLIES] Mandatory smart device security standard applies Security Standards for Smart Devices Rules 2025 (Schedule 1) - effective 4 Mar 2026 - Manufacture in compliance with Schedule 1 (passwords, security issue reporting, defined support period & security updates). - Publish required security information clearly, in English, free of charge (Schedule 1). - Provide/retain a statement of compliance; suppliers must supply with the statement; retain for 5 years (Rules ss 9-10; CSA s 16). ### [NOT COVERED] No mandatory smart device standard under current Rules Part 2 can expand via future rules (other classes/circumstances) - If excluded (e.g., smartphone, therapeutic goods, vehicle) or not acquired by a consumer, Schedule 1 does not apply. - Track Part 2 commencement and any future standards/exemptions made under the rules. - If you both manufacture and supply, map obligations for each role. ### [REPORT <=72H] Ransomware payment report required Give the report to the designated Commonwealth body (CSA s 27) - Report within 72 hours of making the payment or becoming aware it was made on your behalf. - Include required information (CSA s 27(2); Rules s 7) based on reasonable search/enquiry within the 72-hour window. - Civil penalty for failing to report: 60 penalty units (CSA s 27(5)). ### [VOLUNTARY] Voluntary information sharing available National Cyber Security Coordinator (Part 4) - Impacted entities (or others acting on their behalf) may provide information about significant incidents, or incidents that could reasonably be expected to be significant (CSA s 35(2)). - Information can be shared during the response, on your initiative or in response to a request (s 35(3)). - NCSC collection is authorised (including sensitive information) for Privacy Act purposes (note to s 35(2)). - If it's unclear whether an incident is a cyber security incident or significant, you can still share information for qualification/triage (s 36). - Protections on use/disclosure and admissibility apply (Div 3); this does not replace other obligations (s 44). ### [ACTION] Comply with the s 49 notice (document production) Civil penalty risk for non-compliance - Produce documents/copies within stated period (>=14 days) and manner (CSA s 49(2)). - Civil penalty for failing to comply: 60 penalty units (s 50), subject to prejudice exceptions. - Reasonable compensation may apply for making copies (s 49(4)). ### [MONITOR] Be ready to cooperate if approached CIRB reviews are not automatic - A review can be initiated via referral, but only after incident/response ends and Minister approves terms (s 46). - Requests under s 48 are voluntary; notices under s 49 are compulsory. - Maintain incident evidence and decision records in case of a review. ### [BASELINE] Operationalise the obligations Practical next steps across Parts 2-5 - If you sell covered connectable products into Australia: prepare statements and published disclosures before 4 Mar 2026. - If you are (or could become) a reporting business entity: add ransomware payment reporting (72-hour clock) to IR runbooks and vendor/insurer playbooks. - Maintain a parallel reporting matrix and do not treat Part 4 sharing as a substitute for other obligations (s 44). ## CSA 2024 Timeline | Date | Event | Reference | | --- | --- | --- | | 2024-11-29 | Cyber Security Act 2024 receives Royal Assent | Cyber Security Act 2024 (Cth) | | 2024-11-30 | Parts 1, 4, 6, 7 commence (day after Royal Assent) | CSA s 2(1) table | | 2025-05-29 | Parts 3 and 5 commence (backstop if no proclamation) | CSA s 2(1) table | | 2025-11-29 | Part 2 commences (backstop if no proclamation) | CSA s 2(1) table | | 2026-03-04 | Smart device security standard begins (Schedule 1 in force) | Smart Devices Rules 2025 commencement table | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2021-12-02 | SLACI Act 2021 commences (SOCI reforms - tranche 1) | SOCI Act Context | | | 2021-12-15 | SLACIP Bill exposure-draft consultation window | Policy & Consultation | | | 2022-02-04 | SLACIP Bill exposure-draft: final Town Hall held | Policy & Consultation | | | 2022-02-10 | SLACIP Bill introduced and referred to PJCIS | Legislative Process | | | 2022-03-25 | PJCIS advisory report published (SLACIP Bill) | Legislative Process | | | 2022-04-01 | SLACIP Act 2022 made (Federal Register date) | SOCI Act Context | | | 2022-04-02 | SLACIP Act 2022 comes into effect (SOCI reforms - tranche 2) | SOCI Act Context | | | 2022-04-08 | SOCI Application Rules (LIN 22/026) come into effect | SOCI Act Context | | | 2022-07-07 | Telecommunications assets: Cyber Reporting compliance date (Telecommunications Act context) | SOCI Act Context | | | 2022-09-09 | Protected Information guidance (consultation draft v1) | Guidance (Non-binding) | | | 2022-10-05 | RMP Rules consultation window (SOCI reforms) | Policy & Consultation | | | 2022-10-07 | Telecommunications assets: Register compliance date (Telecommunications Act context) | SOCI Act Context | | | 2022-11-03 | Draft Risk Management Program Guidance (consultation draft v2) | Guidance (Non-binding) | | | 2023-02-16 | CIRMP Rules (LIN 23/006) as made (F2023L00112) | SOCI Act Context | | | 2023-02-27 | Australian Cyber Security Strategy consultation window | Policy & Consultation | | | 2023-11-22 | Smart device standards: Impact Analysis published | Policy & Consultation | | | 2023-12-19 | Cyber Security legislative reforms consultation window | Policy & Consultation | | | 2024-10-09 | Minister's second reading speech (House of Representatives) | Legislative Process | | | 2024-11-25 | Minister's second reading speech (Senate) | Legislative Process | | | 2024-11-29 | Cyber Security Act 2024 receives Royal Assent | Cyber Security Act 2024 | | | 2024-11-30 | Act commences: Parts 1, 4, 6 and 7 | Commencement & Application | | | 2024-12-16 | Draft Cyber Security Act Rules consultation window | Policy & Consultation | | | 2025-02-27 | Cyber Security Act Rules are made (dated) | Subordinate Rules (2025) | | | 2025-03-03 | CIRB Rules registered (F2025L00277) | Subordinate Rules (2025) | | | 2025-03-03 | Ransomware Payment Reporting Rules registered (F2025L00278) | Subordinate Rules (2025) | | | 2025-03-04 | Smart Devices Rules registered; Part 1 commences (F2025L00276) | Subordinate Rules (2025) | | | 2025-03-27 | Smart device standards: Supplementary Explanatory Statement registered | Policy & Consultation | | | 2025-04-03 | CIRMP Rules: as-made version end date (superseded) | SOCI Act Context | | | 2025-04-04 | SOCI Application Rules: April 2025 compilation/version date | SOCI Act Context | | | 2025-05-29 | Act commences: Part 3 (ransomware payment reporting) (backstop date) | Commencement & Application | Part 3; s.27 | | 2025-05-29 | Ransomware Payment Reporting Rules commence (F2025L00278) (aligned to Part 3) | Commencement & Application | | | 2025-05-29 | Act commences: Part 5 (Cyber Incident Review Board) (backstop date) | Commencement & Application | | | 2025-05-29 | CIRB Rules commence (F2025L00277) (aligned to Part 5) | Commencement & Application | | | 2025-11-29 | Act commences: Part 2 (smart device security standards framework) (backstop date) | Commencement & Application | | | 2026-01-28 | Compiled Act: replaced authorised version registered | Cyber Security Act 2024 | | | 2026-03-04 | Smart Devices Rules substantive obligations commence (Part 2 and Schedule 1) | Commencement & Application | | | 2027-12-01 | Statutory review can begin (PJCIS) | Statutory Review | s.88 | **Event details:** - **2021-12-02 - SLACI Act 2021 commences (SOCI reforms - tranche 1)**: Home Affairs describes the Security Legislation Amendment (Critical Infrastructure) Act 2021 (SLACI Act) as the first tranche of reforms to the SOCI Act, commencing from 2 December 2021. - **2021-12-15 - SLACIP Bill exposure-draft consultation window**: Home Affairs records an exposure-draft consultation period for the SLACIP Bill and accompanying draft Explanatory Document running from 15 December 2021 until Tuesday 1 February 2022. - **2022-02-04 - SLACIP Bill exposure-draft: final Town Hall held**: Home Affairs notes a final Town Hall was held on 4 February 2022 following the closure of submissions on the SLACIP Bill exposure draft. - **2022-02-10 - SLACIP Bill introduced and referred to PJCIS**: Home Affairs records that the Minister for Home Affairs introduced the SLACIP Bill to Parliament and referred it to the Parliamentary Joint Committee on Intelligence and Security (PJCIS) on 10 February 2022. - **2022-03-25 - PJCIS advisory report published (SLACIP Bill)**: Home Affairs notes that the PJCIS published its advisory report on the SLACIP Bill on 25 March 2022. - **2022-04-01 - SLACIP Act 2022 made (Federal Register date)**: The Federal Register of Legislation entry for the Security Legislation Amendment (Critical Infrastructure Protection) Act 2022 (C2022A00033) shows a date of 1 April 2022 (as-made Act entry). - **2022-04-02 - SLACIP Act 2022 comes into effect (SOCI reforms - tranche 2)**: Home Affairs records that the Security Legislation Amendment (Critical Infrastructure Protection) Act 2022 (SLACIP Act) came into effect on 2 April 2022. - **2022-04-08 - SOCI Application Rules (LIN 22/026) come into effect**: Draft Risk Management Program Guidance states that the Security of Critical Infrastructure (Application) Rules (LIN 22/026) 2022 came into effect on 8 April 2022, outlining asset classes required to comply with Mandatory Cyber Incident Reporting and certain Register reporting requirements. - **2022-07-07 - Telecommunications assets: Cyber Reporting compliance date (Telecommunications Act context)**: Draft Risk Management Program Guidance notes that telecommunications assets comply with Cyber Reporting from 7 July 2022 under the Telecommunications Act 1997. - **2022-09-09 - Protected Information guidance (consultation draft v1)**: Protected Information Guidance Material for industry is marked as a consultation draft (v1) and states it is current "as at 9 September 2022". - **2022-10-05 - RMP Rules consultation window (SOCI reforms)**: Draft Risk Management Program Guidance states the consultation period for the draft risk management program (RMP) rules was 45 days, from 5 October 2022 to 18 November 2022. - **2022-10-07 - Telecommunications assets: Register compliance date (Telecommunications Act context)**: Draft Risk Management Program Guidance notes that telecommunications assets comply with the Register from 7 October 2022 under the Telecommunications Act 1997. - **2022-11-03 - Draft Risk Management Program Guidance (consultation draft v2)**: Draft Risk Management Program Guidance is marked as a consultation draft (v2) and states it is current "as at 03 November 2022". - **2023-02-16 - CIRMP Rules (LIN 23/006) as made (F2023L00112)**: Security of Critical Infrastructure (Critical infrastructure risk management program) Rules (LIN 23/006) 2023 appear on the Federal Register of Legislation as an as-made version dated 16 February 2023 (F2023L00112). - **2023-02-27 - Australian Cyber Security Strategy consultation window**: Smart Devices Rules Explanatory Statement references the Australian Government consultation on the 2023-2030 Australian Cyber Security Strategy running from 27 February 2023 to 15 April 2023. - **2023-11-22 - Smart device standards: Impact Analysis published**: Impact Analysis Addendum for smart device standards states that the Department of Home Affairs published an Impact Analysis on mandatory security standards and an industry-led voluntary cyber security labelling scheme on 22 November 2023. - **2023-12-19 - Cyber Security legislative reforms consultation window**: Smart Devices Rules Explanatory Statement records that, on 19 December 2023, the Minister released the "Australian Cyber Security Strategy: Cyber Security Legislative Reforms Consultation Paper" and that consultation remained open until 1 March 2024. - **2024-10-09 - Minister's second reading speech (House of Representatives)**: The Act records that the Minister's second reading speech was made in the House of Representatives on 9 October 2024. - **2024-11-25 - Minister's second reading speech (Senate)**: The Act records that the Minister's second reading speech was made in the Senate on 25 November 2024. - **2024-11-29 - Cyber Security Act 2024 receives Royal Assent**: Cyber Security Act 2024 (No. 98, 2024) receives Royal Assent on 29 November 2024. - **2024-11-30 - Act commences: Parts 1, 4, 6 and 7**: Commencement table: Part 1 (and provisions not otherwise covered), Part 4 (coordination of significant cyber security incidents), and Parts 6-7 (regulatory powers and miscellaneous) commence the day after Royal Assent (30 November 2024). - **2024-12-16 - Draft Cyber Security Act Rules consultation window**: Explanatory Statements record that the draft Rules package was published on the Department's website on 16 December 2024 and closed for submissions on 14 February 2025. - **2025-02-27 - Cyber Security Act Rules are made (dated)**: The three Cyber Security Act Rules instruments are dated 27 February 2025 (Smart Devices Rules; Cyber Incident Review Board Rules; Ransomware Payment Reporting Rules). Registration dates follow in early March 2025. - **2025-03-03 - CIRB Rules registered (F2025L00277)**: Cyber Security (Cyber Incident Review Board) Rules 2025 are registered on 3 March 2025. The instrument commences later of the day after registration and the commencement of Act Part 5. - **2025-03-03 - Ransomware Payment Reporting Rules registered (F2025L00278)**: Cyber Security (Ransomware Payment Reporting) Rules 2025 are registered on 3 March 2025. The instrument commences later of the day after registration and the commencement of Act Part 3. - **2025-03-04 - Smart Devices Rules registered; Part 1 commences (F2025L00276)**: Cyber Security (Security Standards for Smart Devices) Rules 2025 are registered on 4 March 2025. The commencement table provides that Part 1 commences on registration, while Part 2 and Schedule 1 have a delayed commencement (4 March 2026). - **2025-03-27 - Smart device standards: Supplementary Explanatory Statement registered**: The smart device standards Impact Analysis (Supplementary Explanatory Statement) is an authorised version registered on 27 March 2025 in connection with F2025L00276. - **2025-04-03 - CIRMP Rules: as-made version end date (superseded)**: The Federal Register of Legislation page for F2023L00112 shows the as-made version dated 16 February 2023 and indicates it is superseded, with the as-made version running until 3 April 2025. - **2025-04-04 - SOCI Application Rules: April 2025 compilation/version date**: The Federal Register metadata for the SOCI Application Rules references an April 2025 compilation (F2025C00404) and links to a 4 April 2025 version in the legislation history/amendment history. - **2025-05-29 - Act commences: Part 3 (ransomware payment reporting) (backstop date)**: Commencement table provides for commencement by proclamation, with an automatic commencement if not commenced within 6 months of Royal Assent. The published commencement table includes 29 May 2025 as the backstop date for Part 3. Part 3 imposes the 72-hour ransomware payment reporting obligation for reporting business entities; the 2025 Rules specify (among other details) the $3 million turnover threshold and report content requirements. - **2025-05-29 - Ransomware Payment Reporting Rules commence (F2025L00278) (aligned to Part 3)**: Commencement clause: the whole instrument commences later of the day after registration and the commencement of Act Part 3; the backstop commencement date for Part 3 is 29 May 2025. - **2025-05-29 - Act commences: Part 5 (Cyber Incident Review Board) (backstop date)**: Commencement table provides for commencement by proclamation, with an automatic commencement if not commenced within 6 months of Royal Assent. The published commencement table includes 29 May 2025 as the backstop date for Part 5. - **2025-05-29 - CIRB Rules commence (F2025L00277) (aligned to Part 5)**: Commencement clause: the whole instrument commences later of the day after registration and the commencement of Act Part 5; the backstop commencement date for Part 5 is 29 May 2025. - **2025-11-29 - Act commences: Part 2 (smart device security standards framework) (backstop date)**: Commencement table provides for commencement by proclamation, with an automatic commencement if not commenced within 12 months of Royal Assent. The published commencement table includes 29 November 2025 as the backstop date for Part 2 (security standards for smart devices). - **2026-01-28 - Compiled Act: replaced authorised version registered**: The Act text indicates a replaced authorised version was registered on 28 January 2026 (compiled version reference). - **2026-03-04 - Smart Devices Rules substantive obligations commence (Part 2 and Schedule 1)**: Commencement table: Part 2 and Schedule 1 of the Smart Devices Rules commence on 4 March 2026 (12-month delayed commencement). This is when the mandatory security standards, statement-of-compliance requirements (including 5-year retention period), and defined support-period rules take effect for covered products. - **2027-12-01 - Statutory review can begin (PJCIS)**: The Parliamentary Joint Committee on Intelligence and Security may review the operation, effectiveness and implications of the Act, so long as it begins the review as soon as practicable after 1 December 2027. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/au-cyber-security-act-compliance-decision-map --- --- title: "About Us" canonical_url: "https://www.sorena.io/about-us" source_url: "https://www.sorena.io/about-us" author: "Sorena AI" description: "Learn about Sorena AI's journey in revolutionizing legal and cybersecurity compliance through AI innovation." keywords: - "Sorena AI" - "Stockholm tech company" - "AI innovation" - "company culture" - "tech startup Stockholm" - "legal tech innovation" - "cybersecurity excellence" - "Swedish technology company" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # About Us *Stockholm, Sweden* Pioneering the future of AI-powered governance, risk, and compliance solutions from the heart of Stockholm ## Our Beginning We started in **February 2024** in Stockholm with a vision to transform how organizations approach legal and cybersecurity challenges. Our journey began with a simple yet powerful idea: to harness the potential of artificial intelligence to make compliance and security more accessible, efficient, and effective. The business is officially registered as **Sorena AB (559573-7338)** (registration **February 2026**). ## Our Values The principles that guide everything we do - **Innovation**: We constantly push the boundaries of what's possible, combining cutting-edge AI with practical solutions. - **Security by Design**: Security isn't just a feature. It's fundamental to everything we build, ensuring robust protection at every layer. - **Environmental Responsibility**: We are committed to environmental sustainability by exclusively using zero or low CO2 emission services. - **Trust**: We build lasting relationships through transparency, reliability, and consistent delivery of secure solutions. - **Customer Focus**: Our clients' success is our success. We're dedicated to delivering solutions that create real value. - **Collaboration**: We foster teamwork and open communication to achieve extraordinary results together. ## Our Culture At Sorena AI, we foster a culture of innovation, collaboration, and continuous learning. Our diverse team brings together experts from legal technology, cybersecurity, and artificial intelligence, creating a dynamic environment where creativity thrives and breakthrough solutions emerge. ## Looking Forward As we continue to grow and evolve, our commitment to innovation and excellence remains unwavering. We're excited about the future and the opportunities to create even more impactful solutions that help organizations thrive in an increasingly complex digital world. ## Join us in shaping the future Be part of our mission to revolutionize legal technology and cybersecurity [Contact Us](mailto:info@sorena.io) | [Try Sorena AI](https://app.sorena.io) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/about-us --- --- title: "Contact Us" canonical_url: "https://www.sorena.io/contact" source_url: "https://www.sorena.io/contact" author: "Sorena AI" description: "Get in touch with Sorena's team of experts for innovative Legal Tech and Cybersecurity solutions. Transform your organization's GRC approach today." keywords: - "contact sorena" - "legal tech support" - "cybersecurity consulting" - "GRC solutions" - "compliance assistance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Contact Us *Let's Connect* Transform your organization's approach to Legal Tech and Cybersecurity. Our team of experts is ready to help you navigate the complexities of modern GRC challenges. ## How Can We Help? - **Demo Request**: Schedule a personalized demo to see how our solutions can transform your organization. - **Partnership**: Explore collaboration opportunities and become part of our growing network. - **Support**: Get assistance with technical questions or product inquiries from our expert team. - **Beta Program**: Join our beta program to shape the future of legal and cybersecurity solutions. - **Custom Solutions**: Discuss your specific needs for tailored GRC and compliance solutions. - **Quick Response**: Expect a response within 24 hours from our dedicated team. ## Contact Information - **Location**: Stockholm, Sweden European Innovation Hub - **Email**: [info@sorena.io](mailto:info@sorena.io) General inquiries ## Send us a Message ### Form Fields - **Name**: Your name - **Email**: your.email@example.com - **Phone Number** (Optional): +1 (555) 000-0000 - **Company** (Optional): Your organization - **Job Title** (Optional): Your role - **Message**: Tell us about your needs, challenges, or how we can help transform your GRC operations... I agree to the [Privacy Policy](/privacy.md) Subscribe to our newsletter for updates and insights on legal tech and cybersecurity Submit: Send Message We'll get back to you within 24 hours > Thank you! Your message has been sent. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/contact --- --- title: "Privacy Policy" canonical_url: "https://www.sorena.io/privacy" source_url: "https://www.sorena.io/privacy" author: "Sorena AI" description: "Learn how Sorena AI protects your data and privacy." keywords: - "privacy policy" - "data protection" - "GDPR compliance" - "user privacy rights" - "data security" - "Sorena AI privacy" - "data handling" - "cybersecurity privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Privacy Policy Effective 9 February 2025 We know that your privacy is important, and we're committed to protecting it. This Privacy Policy explains, in a clear and simple way, how we collect, use, and protect your personal data when you use our generative AI services ("Services"). Sorena AB (559573-7338) is a Swedish company based in Stockholm ("We", "Us" or "Sorena AI"). Sorena started operations in February 2024 and was officially registered in February 2026. All data is encrypted at rest and in transit. None of the cloud providers we partner with have access to the data, as per our enterprise agreements. ## Who collects your data? ### Sorena AI as data controller Sorena AI is the data controller. This means that Sorena AI is the entity that decides how and why your personal data is collected and used. ### Sorena AI as data processor If you use our Services to process personal data on behalf of your business, you are the data controller, and Sorena AI is the data processor. This means that you decide how and why the personal data is processed, and we process such data on your behalf and according to your instructions to provide you with the Services. This Privacy Policy only covers the processing activities we carry out as a data controller. It does not apply to the processing activities we carry out as a data processor on your behalf, which are governed by our Data Processing Agreement. ## What data do we collect? ### Data you provide directly to us Identity, account and contact data when you create your account on our platform or subscribe to our newsletter. We also collect any Feedback (screenshots and comments) you choose to provide. You must be of legal age (18 years or older in Sweden) to provide us with any personal data. ### Personal data generated by your use of our Services When you use the Services, we automatically collect security logs, technical information through cookies, and Output (content generated by the Services based on your Input). If you include personal data in your Input, then such personal data may be included in the Output. ### Personal data that is indirectly provided to us Data publicly available on the Internet: Our models are trained on data that is publicly available on the Internet, which may contain personal data, even if we use good practices to filter out such personal data. ## Why do we use your data? ### Service Provision & Improvement We use your data to provide the Services and generate aggregated and anonymized statistics to enhance functionality and performance. ### General Administration For security management, sending important non-marketing communications about service updates or account information, and managing technically required cookies. ### Model Development We do not use your Input and Output to train our models. ### Marketing Operations For sending newsletters (with consent), lead development, event invitations, and managing our business relationship with you. ### Commercial Management For contract administration, invoicing, and payment processing. ### Dispute Resolution To investigate and resolve disputes, enforce our contract, and protect our legal rights. ### Data Subject Requests To respond to your requests regarding your personal data rights. ## How long do we keep your data? ### Service & Account Data Account data is kept while you're registered plus 1 year after termination. Input and Output data is kept for 30 days for abuse monitoring. Fine-tuning data is kept until you delete it or your account. For technical support, we keep data until request processing plus 5 years for records. ### Security & Technical Data Security logs are kept for 1 rolling year. Cookies are kept as long as you consent to their use. ### Commercial & Legal Records Contracts are kept for contract duration plus 7 years. Invoices are kept for 7 years from year-end. For disputes, data is kept until appeal periods end, with possible archival extension. ### Marketing & Business Data Newsletter contact data until unsubscribe, leads for 3 years from collection, B2B customer data for contract duration plus 3 years. Privacy requests are kept for 6 years after processing. ## Who do we share your data with? ### Internal Access Authorized team members who need access to perform their jobs. ### Service Providers Cloudflare, Inc (Security, Cloud Services, AI Services), Amazon.com, Inc (Cloud Services, AI Services), Microsoft Corporation (Cloud Services, AI Services), GitHub, Inc (Security, Code, CI/CD, Cloud Services, AI Services), OpenAI, Inc (AI Services), Anthropic PBC (AI Services), Google LLC (AI Services), Hetzner Online GmbH (Cloud Services), Bahnhof AB (Cloud Services). All providers are audited and bound by data protection agreements and none of the providers have access to your data. ### Financial & Legal Banks and financial organizations, regulatory authorities like the Swedish data protection authority (Integritetsskyddsmyndigheten), courts, mediators, accountants, auditors, lawyers, bailiffs, and debt collection agencies when appropriate. ### International Transfers We prioritize EU providers compliant with GDPR. For non-EU providers, we ensure adequate safeguards under Article 46 of GDPR and include the latest European Commission's Standard Contractual Clauses. ## Data Breach Notification ### Notification Timeline In the event of a data breach that may affect your personal data, we will notify you and the relevant supervisory authority within 72 hours of becoming aware of the breach, as required by GDPR Article 33. ### Notification Content Our notification will include the nature of the breach, categories of data affected, potential consequences, measures taken to address the breach, and recommendations for you to mitigate potential adverse effects. ### Ongoing Communication We maintain transparent communication throughout the incident response process and provide regular updates on our dedicated security status page. ### Prevention Measures We continuously monitor our systems, conduct regular security assessments, and maintain incident response plans to prevent and quickly address any security incidents. ## Your rights ### Access You have the right to know if we process your personal data. You also have the right to request a copy of such personal data and to obtain further information about the way we process your personal data. ### Rectification You have the right to update or correct your personal data. ### Deletion You have the right to delete and/or ask us to delete your personal data. ### Objection You have the right to object to the processing of your personal data. This right does not apply when we have a legal obligation to process your personal data. ### Consent Withdrawal You have the right to withdraw your consent to the processing of your personal data at any time. ### Limitation You have the right to ask us to freeze the processing of your personal data. ### Portability You have the right to obtain and transfer your personal data to another entity. ### Post-mortem Rights You have the right to tell us how you would like us to process your personal data after your death. ### Lodge a Complaint You have the right to lodge a complaint before the competent data protection authority, including the Swedish data protection authority (Integritetsskyddsmyndigheten). ### How to Exercise Your Rights You can exercise these rights by sending us an email at privacy@sorena.io (or contact our DPO at dpo@sorena.io) or by making a request using our Support Center available on your account. ## Cookies & Tracking ### Essential Technical Cookies These cookies are strictly necessary for the proper functioning of the website and cannot technically be deactivated from the site. However, you can manage these cookies through your browser settings. ### Performance & Analytics Cookies These cookies help us to understand the customer's use of our website. All data collected is anonymous and we do not retain information that will identify you personally. Google Analytics is not included and allowed inside of the internal portal. ### Cookie Management Upon your initial visit, a banner will prompt you to accept or decline non-essential cookies. You can manage preferences through our cookie banner or your browser settings. Note that deleting or blocking cookies may affect your user experience and limit access to certain parts of the site. ## Contact **Contact Us**: If you have any questions about our privacy policy or how we handle your data, please don't hesitate to reach out. Email: [privacy@sorena.io](mailto:privacy@sorena.io) **Data Protection Officer**: For specific inquiries about your data protection rights or to report a privacy concern, contact our DPO directly. Email: [dpo@sorena.io](mailto:dpo@sorena.io) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/privacy --- --- title: "Terms of Use" canonical_url: "https://www.sorena.io/terms-of-use" source_url: "https://www.sorena.io/terms-of-use" author: "Sorena AI" description: "Review Sorena AI's terms of use and service guidelines." keywords: - "terms of use" - "terms of service" - "legal terms" - "user agreement" - "Sorena AI terms" - "service conditions" - "user guidelines" - "legal compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Terms of Use Effective 6 March 2026 Welcome to Sorena AI! We provide technology and services that enable access to and use of Sorena AI's artificial intelligence models. These Terms of Service govern your use of Sorena AI, and the other websites, products, services, and technologies we offer. The Services are provided by Sorena AB (559573-7338), a Swedish company based in Stockholm. Sorena started operations in February 2024 and was officially registered in February 2026. ## 1. Accessing the Services ### Age requirements You must be of legal age (age of majority) in your jurisdiction to use the Services. For users in Sweden, this means you must be at least 18 years old. ### Sorena AI accounts The Service require a Sorena AI account. You must provide complete and accurate account information and promptly update your account if any of your information changes. Your account is intended for your individual use only and you may not share your account with any other person. You are responsible for any activities conducted through your account, including activities of any end user provisioned with an account under your account ('End User Account'), whether or not those activities were actually conducted by you. You may not make account access credentials available to third parties, share individual login credentials between multiple users on an account, or resell or lease access to your account or any End User Account. You must promptly notify us at support@sorena.io or through the Help Center in the event you detect any unauthorized or fraudulent access or use of your account. ### Admin accounts If you have an admin account, you will have access to additional features, such as (a) adding authorized users to your workspace either by invitation or automatically, through the domain of their email address, (b) managing accounts within your workspace, and (c) managing features for the authorized users of your workspace. ## 2. Using the Services ### Our Services We grant you a non-exclusive right to access and use the Services only in compliance with these Terms, any applicable Additional Terms, all applicable laws and regulations, and any other documentation, guidelines, or policies we make available to you, including our Usage Policy. Some Services may be subject to certain restrictions, such as formatting or size restrictions, or rate limits. Any such restrictions can be found in the applicable documentation or on our platform. The different subscription plans applicable to the Services are described on our platform. ### Restrictions We own all right, title, and interest in and to the Services. You only receive rights to use the Services as explicitly granted in these Terms and any applicable Additional Terms. You will not, and will not permit any other person to use the Services or Your Data in a manner that violates any applicable laws, these Terms, or any of our policies; infringe third party rights; send us any personal information of children under 13; reverse engineer the Services; compromise security; or buy, sell, or transfer API keys or Service accounts. ## 3. Acceptable Use and Ethical Standards ### Good Faith Usage You agree to use the Services in good faith and for lawful purposes only. You must not abuse the Services or use them in any manner that could harm Sorena AI, our infrastructure, or other users. All interactions with our Services must comply with ethical standards and professional conduct. ### Prohibited Conduct You may not use the Services to: (a) harass, abuse, threaten, or harm any person or entity; (b) engage in fraudulent, deceptive, or manipulative practices; (c) generate or distribute malicious content, misinformation, or content intended to cause harm; (d) attempt to manipulate, deceive, or exploit vulnerabilities in our AI systems; (e) conduct activities that violate professional ethics or codes of conduct in your industry; (f) facilitate or encourage illegal activities; or (g) circumvent or attempt to circumvent any technical limitations, security measures, or usage restrictions we implement. ### Respect for Others You must not use the Services to abuse, harass, discriminate against, or cause harm to other users or third parties. This includes generating content that promotes hate speech, violence, discrimination, or content that violates the rights or dignity of others. ### Responsible AI Use You acknowledge that AI systems can be misused and agree to use our Services responsibly. You will not attempt to generate outputs that circumvent safety measures, produce harmful content, or exploit the AI system for malicious purposes. You agree to report any vulnerabilities or potential misuse of the Services to our security team. ### Consequences of Violation Violations of these acceptable use standards may result in immediate suspension or termination of your account, and you may be held liable for any damages or harm caused by your misuse of the Services. We reserve the right to cooperate with law enforcement and regulatory authorities regarding any illegal or abusive conduct. ## 4. Your User Data ### Your Data You and your authorized users may provide input to the Services, such as prompts or fine-tuning data ('Input'), and receive output from the Services based on such Input ('Output'). We refer to Input and Output collectively as 'Your Data'. You retain all ownership rights in Input and own all Output. We assign to you all right, title, and interest, if any, in and to Output that we may have. ### Responsibility for Your Data You are responsible for all Input and represent and warrant that you have all rights, licenses, and permissions required to provide Input to the Services. You are solely responsible for all use of the Outputs and evaluating the Output for accuracy and appropriateness for your use case. ### Illegal content You have the availability to report to us any of Your Data or Third-Party Content that violate our Usage Policy or that contains illegal content. You can report such content by using the report feature on the Services and/or by sending an email at support@sorena.io. ## 5. Warranties; Disclaimer ### Our Warranties We warrant that, when used in accordance with these Terms and the applicable Additional Terms, the Services will conform in all material respects with the documentation we provide to you or otherwise make publicly available. ### Your Warranties You warrant that (a) you have the authority to enter into and accept these Terms and (b) you and your authorized users (if any) will use the Services in accordance with the applicable laws and regulations and these Terms. ### Disclaimer EXCEPT FOR THE WARRANTIES IN THIS SECTION 5 (WARRANTIES; DISCLAIMER), THE SERVICES ARE PROVIDED "AS IS" AND WE AND OUR AFFILIATES AND LICENSORS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND TITLE, NONINFRINGEMENT, OR QUIET ENJOYMENT, AND ANY WARRANTIES ARISING OUT OF COURSE OF DEALING OR TRADE USAGE. WE MAKE NO REPRESENTATIONS OR WARRANTIES (I) THAT USE OF THE SERVICES WILL BE UNINTERRUPTED, ERROR FREE, SECURE, OR BE SUITABLE FOR YOUR SPECIFIC PURPOSES OR USE-CASES, (II) THAT DEFECTS WILL BE CORRECTED, OR (III) THAT YOUR DATA WILL BE ACCURATE. ## 6. Indemnification and User Liability for Abuse ### By you You will indemnify, defend, and hold us and our affiliates, service providers, and licensors harmless against any liabilities, damages, and costs (including reasonable attorneys' fees) payable to a third party arising out of a third party claim related to (i) the use of the Services in violation of these Terms, (ii) any of your products or services that you make available to end-users in connection with the Services or Outputs, or (iii) Your Data. ### Liability for Abuse and Misuse You are fully liable for any damages, losses, or harm caused by your abuse, misuse, or unethical use of the Services. This includes but is not limited to: (a) harm caused to other users or third parties through your use of the Services; (b) damages resulting from your violation of acceptable use standards or ethical guidelines; (c) costs incurred by Sorena AI in investigating or responding to your abusive conduct; (d) damages arising from your generation or distribution of harmful, fraudulent, or illegal content using our Services; and (e) any losses resulting from your circumvention of security measures or technical limitations. You agree to compensate Sorena AI and affected parties for all such damages and associated costs, including legal fees. ### Direct Harm Liability In addition to third-party claims covered above, you are directly liable to Sorena AI for any harm, damage, or loss to our platform, infrastructure, reputation, or business operations caused by your violation of these Terms, abuse of the Services, or unethical conduct. This liability is separate from and in addition to any indemnification obligations. ### By us We will indemnify and defend you for any damages finally awarded by a court of competent jurisdiction and any settlement amounts payable to a third party arising out of a third party claim alleging that the Services infringe any third party intellectual property right. ## 7. Liability ### Limitation of Liability NEITHER WE NOR ANY OF OUR AFFILIATES, EMPLOYEES, SHAREHOLDERS, LICENSORS, AGENTS, SUPPLIERS, OR SERVICE PROVIDERS WILL BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR EXEMPLARY DAMAGES, INCLUDING DAMAGES FOR LOSS OF PROFITS, GOODWILL, USE, OR DATA OR OTHER LOSSES, EVEN IF WE HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. OUR AGGREGATE LIABILITY UNDER THESE TERMS AND ANY APPLICABLE ADDITIONAL TERMS WILL NOT EXCEED THE GREATER OF THE AMOUNT YOU PAID FOR THE SERVICE THAT GAVE RISE TO THE CLAIM DURING THE 3 MONTHS BEFORE THE LIABILITY AROSE OR 100 EUROS. THE LIMITATIONS IN THIS SECTION 7 (LIABILITY) APPLY ONLY TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW. ## 8. Term, Suspension, and Termination ### Term These Terms will commence on the earlier of (i) the date you first use the Services or (ii) the date you accept these Terms, and will continue until terminated. ### Termination or suspension We reserve the right to suspend or terminate your account and/or your access to all or part of the Services if: (i) you breach these Terms, (ii) you fail to pay any fees when due, (iii) we need to do so in order to comply with applicable law, or (iv) your continued use of the Services could cause risk or harm to Sorena AI, our users, or anyone else. ## 9. Privacy ### Privacy Policy We process your personal data as data controller for the purposes of (a) providing the Services (unless you are using our Services on behalf of your business) and (b) managing your relationship with us in accordance with these Terms, including any billing, payment, or marketing activities. ### Processing personal data If you use the Services to process personal data on behalf of your business you must (a) provide legally adequate privacy notices and obtain necessary consents for the processing of personal data by the Services, (b) process personal data in accordance with applicable law, and (c) execute our Data Processing Agreement. ## 10. Changes to these Terms or the Services ### Updates to these Terms We may update these Terms, the Additional Terms, our Usage Policy or our Services from time to time. We will give you at least 30 days advance notice of changes to these Terms that materially adversely impact you either via email or an in-product notification. ## 11. General ### Governing law and venue The laws of Sweden will govern all disputes arising out of or relating to these Terms, or related Services, regardless of conflict of laws rules. These disputes will be resolved exclusively in the courts located in Stockholm, Sweden, and you and Sorena AI consent to personal jurisdiction in those courts. ### Entire Agreement Unless otherwise agreed in writing between you and Sorena AI, these Terms, including our Usage Policy and any applicable Additional Terms, constitute the entire agreement between you and us concerning the Services. ## AI Output Disclaimer ### Not Professional Advice The output generated by our AI services is for informational purposes only and should not be considered professional advice. Always consult with qualified domain experts (legal professionals, cybersecurity experts, etc.) before taking any action based on AI-generated content. Our service is designed to supplement, not replace, professional legal counsel or expert consultation. ### Accuracy and Bias While we strive for accuracy, AI-generated content may contain inaccuracies, biases, or errors. We make no representations or warranties about the completeness, reliability, or accuracy of AI outputs. Our AI analyzes vast amounts of compliance and legal data to offer insights and suggestions, but these are best-effort services based on available information. ### No Liability Sorena AI and its affiliates are not responsible for any decisions, actions, or consequences resulting from the use of AI-generated content. Users are solely responsible for verifying and validating any information before use. This includes any attempts to bypass human review processes or misuse of the AI system. ### Limitations of AI Analysis AI-generated advice may not account for all nuances of your specific situation. Regulations and legal landscapes change frequently, and our AI may not reflect the most recent updates. The system provides general insights based on patterns in data but cannot replace human judgment and expertise. ### Intended Use Use our AI Compliance Assist to get started, gain initial insights, and prepare for more informed discussions with your domain experts. The service is not intended as a standalone solution for legal or compliance decisions. ### Human Review Requirement Bypassing recommended human review processes or expert consultation is done at your own risk. We explicitly disclaim any liability for decisions made without appropriate expert review, regardless of the confidence level expressed in the AI output. ### Data Currency While we strive to maintain current information, the AI's knowledge cutoff date may mean it's not aware of recent developments. Users must independently verify the currency of any information provided. ### No Circumvention Any attempt to manipulate the AI system to generate outputs that circumvent legal requirements, professional review processes, or compliance procedures is strictly prohibited and may result in immediate termination of service access. ### Context Dependency AI outputs are highly dependent on the quality and completeness of input provided. Incomplete or inaccurate inputs will result in potentially misleading outputs. Users must ensure they provide complete and accurate context for their queries. ### Regulatory Compliance The use of AI-generated content in regulatory or compliance contexts is at the user's own risk. Users must ensure any application of AI outputs complies with relevant regulations, standards, and professional requirements in their jurisdiction. ## Data Ownership and Rights ### Output Rights Assignment While we assign to you all rights to the AI-generated output, you remain solely responsible for how you use, implement, or act upon such output. This includes ensuring compliance with applicable laws, regulations, and professional standards. ### Input Data Rights You retain all ownership rights to your input data. By using our services, you grant us the necessary licenses to process your input data to provide the services. ### Usage Responsibility You are responsible for ensuring that your use of the output does not infringe on any third-party rights or violate any applicable laws or regulations. ## Data Protection and GDPR Compliance ### GDPR Compliance As a Swedish company, we comply with the General Data Protection Regulation (GDPR) and Swedish data protection laws. We process personal data in accordance with our Privacy Policy and applicable data protection regulations. ### Data Processing When processing personal data on behalf of business users, we act as a data processor and require a Data Processing Agreement (DPA) to be in place. ### International Transfers Any international transfers of personal data are conducted in compliance with GDPR requirements, including appropriate safeguards such as Standard Contractual Clauses. ## Security Measures ### Data Protection We implement industry-standard security measures including encryption in transit and at rest, secure coding practices, and regular security assessments. Our infrastructure is protected by enterprise-grade WAF/Firewalls and we maintain secure backup systems. ### Access Controls We maintain strict access controls, authentication mechanisms, and monitoring systems to protect your data. Our security measures are regularly audited and updated. ### Incident Response We maintain comprehensive incident response plans and will notify affected users of any security incidents in accordance with applicable laws and regulations. ## Competitive Use Restrictions ### AI Output and Training Data Restrictions You are strictly prohibited from using any AI outputs, responses, or generated content from our Services to train, fine-tune, improve, or develop competing artificial intelligence models or systems. This includes but is not limited to using our outputs as training data for machine learning algorithms, benchmarking against competing AI services, or systematic extraction of AI responses for competitive purposes. ### Competing Services Development You may not use our Services, outputs, methodologies, or any insights derived therefrom to develop, enhance, or operate competing AI-powered legal, compliance, or cybersecurity platforms or services. This prohibition extends to creating derivative products, white-labeling our outputs, or reselling our AI-generated content as part of competing solutions. ### Business Intelligence and Competitive Analysis You are prohibited from using our Services to gather competitive intelligence, monitor our capabilities for competitive purposes, analyze our pricing or features for competitive advantage, or study our service architecture to replicate functionality in competing products. ### Bulk Data Extraction Systematic downloading, scraping, crawling, or bulk extraction of AI outputs, website content, documentation, or any other data from our Services is strictly prohibited, especially when intended for competitive use or creating competing datasets. ## Copyright and Content Protection ### Website Content Copyright All content on our website, platform, and services, including but not limited to text, images, graphics, logos, designs, documentation, user interfaces, and educational materials, is protected by copyright and owned by Sorena AI. Unauthorized reproduction, distribution, or public display of any content is strictly prohibited. ### Public Sharing and Distribution Restrictions You may not copy, reproduce, share, post, or distribute any content from our Services on social media, blogs, public forums, presentations, conferences, or any other public platforms without prior written consent. This includes screenshots, recordings, or any other captured content from our platform. ### Attribution and Misrepresentation Prohibitions You may not present our copyrighted content as your original work, remove copyright notices or attribution, use our content to endorse other services, or misrepresent the source or accuracy of any copied content. All use of our content must maintain proper attribution where permitted. ### Digital Content and Materials Downloading, redistributing, or sharing our proprietary documentation, code examples, templates, frameworks, methodologies, or any digital materials is prohibited without explicit written permission. This includes mirroring or archiving our website content. ### Limited Fair Use Brief quotations for academic research or commentary may be permitted under fair use principles, provided they include proper attribution, do not exceed reasonable limits, and are not used for commercial purposes. Any substantial use requires prior written consent from Sorena AI. ## Regulatory Artifacts and Exported Content ### Scope of Artifacts For this section, "Artifacts" means regulatory decision maps, compliance timelines, self-assessment tools, flowcharts, and any other visual or interactive regulatory content provided through the Services, whether viewed online or exported or downloaded. ### Intellectual Property and Copyright Ownership All Artifacts, including their underlying data, structure, design, layout, and presentation, are the exclusive intellectual property of Sorena AI and are protected under applicable copyright and intellectual property laws. Sorena AI retains full and sole ownership of all Artifacts. No license, right, title, or interest in any Artifact is transferred to you except the limited right to view and use Artifacts in accordance with these Terms. ### Permitted Use You may view and download Artifacts solely for your own internal, non-commercial reference purposes. Artifacts may not be redistributed, published, sublicensed, or shared with third parties in any form; used in commercial products, services, publications, or presentations without prior written consent; modified or adapted to create derivative works; incorporated into competing products or services; or presented as your own work or as authoritative legal or compliance guidance. ### No Legal or Professional Advice Artifacts are provided for general informational and educational purposes only. Artifacts do not constitute legal, regulatory, compliance, or professional advice. Regulatory landscapes change frequently and Artifacts may not reflect the most current legislative text, enforcement guidance, or judicial interpretation. You must consult qualified professionals before making decisions based on Artifact content. ### Disclaimer of Warranties and Accuracy ARTIFACTS ARE PROVIDED "AS IS" AND "AS AVAILABLE" WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. SORENA AI MAKES NO REPRESENTATIONS OR WARRANTIES REGARDING THE ACCURACY, COMPLETENESS, TIMELINESS, RELIABILITY, OR SUITABILITY OF ANY ARTIFACT FOR ANY PARTICULAR PURPOSE. REGULATORY SUMMARIES, FLOWCHARTS, TIMELINES, AND ASSESSMENT LOGIC MAY CONTAIN ERRORS, OMISSIONS, OR OUTDATED INFORMATION. ### Limitation of Liability TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, SORENA AI SHALL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR EXEMPLARY DAMAGES ARISING FROM OR RELATED TO YOUR USE OF, RELIANCE ON, OR INABILITY TO USE ANY ARTIFACT. THIS INCLUDES, WITHOUT LIMITATION, DAMAGES FOR REGULATORY NON-COMPLIANCE, FINES, PENALTIES, FAILED AUDITS, LOST BUSINESS OPPORTUNITIES, OR OTHER LOSSES RESULTING FROM DECISIONS MADE BASED ON ARTIFACT CONTENT. ### Indemnification You agree to indemnify, defend, and hold harmless Sorena AI, its officers, directors, employees, and affiliates from and against claims, damages, losses, liabilities, costs, and expenses (including reasonable attorneys' fees) arising from or related to your use of or reliance on any Artifact; redistribution or unauthorized sharing of Artifacts; third-party claims resulting from decisions you made based on Artifact content; or your creation of derivative works from Artifacts. ### Exported File Restrictions Artifacts exported or downloaded as image files (JPEG, PNG) or other formats remain subject to all terms in this section. Embedded metadata, including copyright notices and authorship attribution, must not be removed, altered, or obscured. Removal of metadata is a violation of these Terms and may result in termination of access and legal action. ### No Certification or Compliance Guarantee Use of any Artifact, including a self-assessment tool, decision map, or timeline, does not constitute certification, attestation, or confirmation of compliance with any regulation, directive, or standard. Assessment scores, domain ratings, and flowchart outcomes are indicative only and carry no legal, regulatory, or evidentiary weight. You must not represent to auditors, regulators, clients, or other third parties that Sorena AI has certified or verified your compliance status. ### Self-Assessment Tool Specific Disclaimers Self-assessment tools produce scores and domain-level ratings based on user-provided answers. Results reflect only the information you provide and may be incomplete or inaccurate, are not validated or audited by Sorena AI, do not replace formal compliance assessments or audits by qualified professionals, and may use simplified logic that does not capture full regulatory complexity. Sorena AI accepts no liability for actions or decisions taken in reliance on assessment results. ### Sorena AI Is Not a Regulatory Authority Sorena AI is a private technology company. Sorena AI is not a government body, regulatory authority, notified body, supervisory authority, or accredited certification body. Artifact references to regulations such as NIS2, EU AI Act, GDPR, CRA, and DORA are informational only and do not imply endorsement, affiliation, or authorization by relevant authorities. ### Regulatory Source Material vs. Sorena IP Underlying legislative texts and regulatory guidance may be public domain or government works. Sorena AI's interpretation, analysis, structuring, flowchart logic, decision-tree design, timeline organization, scoring methodology, visual presentation, and other creative and analytical elements are proprietary and protected by copyright. Availability of source regulatory text does not diminish Sorena AI's intellectual property rights in Artifacts. ### No Third-Party Beneficiary Rights These Terms are between you and Sorena AI. No third party, including your clients, auditors, regulators, partners, or end-users, has any right, claim, or benefit under these Terms in relation to Artifacts. If you share, display, or reference an Artifact to a third party where permitted, Sorena AI owes no duty or liability to that third party. ### Stale Export and Snapshot Disclaimer Once an Artifact is exported or downloaded, it becomes a static snapshot as of the export date. Regulations, enforcement guidance, and compliance requirements change over time. Sorena AI has no obligation to notify you when a previously exported Artifact becomes outdated, superseded, or no longer accurate. You are solely responsible for verifying currency before reliance. ### Multi-Jurisdiction Accuracy Disclaimer Artifacts may cover regulations across multiple jurisdictions, including EU, UK, US, Australia, Brazil, Singapore, and others. Requirements vary significantly by jurisdiction, member state, sector, and entity type. Sorena AI does not guarantee that any Artifact reflects requirements applicable to your organization, jurisdiction, or sector. Local legal counsel should always be consulted. ### Prohibition on Automated Decision-Making Artifacts must not be used as the sole or primary basis for automated decision-making systems, including systems that automatically determine compliance status, trigger regulatory filings, generate audit reports, or make employment, procurement, or contractual decisions without meaningful human review. Integration of Artifact data or logic into automated pipelines requires prior written consent from Sorena AI. ### Reverse Engineering and Data Extraction You may not reverse engineer, decompile, disassemble, or otherwise attempt to extract underlying data structures, JSON schemas, decision-tree logic, scoring algorithms, or source code of any Artifact. Programmatic scraping, crawling, or automated extraction of Artifact content is strictly prohibited. ### Embedding, Framing, and Hotlinking You may not embed, frame, or display Artifacts, in whole or part, on third-party websites, applications, or services using iframes, hotlinks, or other technical means without prior written consent. Deep linking to specific Artifact pages is permitted only for non-commercial reference purposes with proper attribution. ### Organizational Use Scope Access to and use of Artifacts is limited to the individual user or the specific legal entity associated with that account. Sharing Artifacts across subsidiaries, affiliates, parent companies, joint ventures, or related entities requires separate authorization. Each legal entity must maintain its own account and license as applicable. ### Cheatsheets and Supplementary Content Regulatory cheatsheets, summary guides, compliance overviews, and other supplementary educational content published alongside Artifacts are subject to the same terms in this section, including copyright ownership, liability disclaimers, permitted use restrictions, and prohibition on redistribution. ### Digital Fingerprinting and Metadata Notice Artifacts may include embedded metadata, watermarks, or fingerprints for copyright protection and attribution tracking. Metadata may identify originating account, export date, and source URL. Attempts to remove, alter, obscure, or circumvent embedded metadata are a material breach of these Terms and may be pursued under applicable copyright and anti-circumvention laws. ### Reservation of Rights Sorena AI reserves the right to modify, update, discontinue, or remove any Artifact at any time without prior notice. Sorena AI may revoke access to Artifacts for users who violate these Terms. ### Survival The provisions in this section relating to intellectual property ownership, disclaimer of warranties, limitation of liability, indemnification, and prohibited uses survive termination or expiration of these Terms and your access to the Services. ## Enforcement and Penalties ### Monitoring and Audit Rights We reserve the right to monitor usage patterns, conduct audits, and investigate potential violations of these competitive use and copyright restrictions. Users must cooperate with reasonable investigations and provide access to relevant records upon request. ### Immediate Termination Any violation of competitive use restrictions or copyright protections will result in immediate termination of your account and access to all Services, without refund of any fees paid. We may also pursue all available legal remedies. ### Legal Remedies and Damages Violations may result in monetary damages, including but not limited to actual damages, lost profits, and statutory damages where applicable. We reserve the right to seek injunctive relief to prevent ongoing violations and protect our intellectual property rights. ### DMCA and Takedown Procedures We will pursue DMCA takedown notices and other legal procedures to remove unauthorized use of our copyrighted content. Repeat offenders may be permanently banned from accessing our Services and may face additional legal consequences. ### Reporting Violations If you become aware of any violations of these restrictions, please report them immediately to legal@sorena.io. We take all violations seriously and will investigate promptly. ## Modifications to Terms ### Right to Modify We reserve the right to modify these Terms at any time. We will provide advance notice of any material changes through email or prominent notice on our services. ### Continued Use Your continued use of the Services after the effective date of any modifications constitutes acceptance of the updated Terms. ### Previous Versions We maintain archives of previous versions of these Terms, which are available upon request. ## Dispute Resolution ### Governing Law These Terms are governed by Swedish law, without regard to its conflict of law principles. ### Arbitration Agreement All disputes arising out of or in connection with this Agreement, including any questions regarding its existence, validity, or termination, shall be finally settled by arbitration in accordance with the Arbitration Rules of the Arbitration Institute of the Stockholm Chamber of Commerce (SCC). ### Arbitration Process The arbitration shall be conducted in Stockholm, Sweden. The language of the arbitration shall be English. The arbitral tribunal shall consist of three arbitrators unless the amount in dispute is less than EUR 100,000, in which case a sole arbitrator shall be appointed. ### Confidentiality The existence and content of the arbitral proceedings and any rulings or award shall be kept strictly confidential by all parties involved. ## Contact Us If you have any questions about our terms of use, please don't hesitate to reach out. Email: [support@sorena.io](mailto:support@sorena.io) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/terms-of-use --- --- title: "DMCA Policy" canonical_url: "https://www.sorena.io/dmca" source_url: "https://www.sorena.io/dmca" author: "Sorena AI" description: "Learn about Sorena AI's DMCA policy and how to submit copyright infringement notices." keywords: - "DMCA notice" - "copyright infringement" - "intellectual property rights" - "takedown request" - "Sorena AI legal" - "digital millennium copyright act" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DMCA Notice & Takedown Policy Digital Millennium Copyright Act Compliance Sorena AI (Sorena AB, 559573-7338) respects the intellectual property rights of others and expects its users to do the same. In accordance with the Digital Millennium Copyright Act (DMCA), we provide a clear process for copyright owners to report alleged infringements. If you believe that your copyrighted work has been copied in a way that constitutes copyright infringement, please follow our guidelines below to submit a DMCA notice. ## Requirements for a DMCA Notice ### Identification - An electronic or physical signature of the person authorized to act on behalf of the copyright owner. - A description of the copyrighted work that you claim has been infringed, including the title, author, and any other relevant details. ### Location and Contact Information - A description of where the material that you claim is infringing is located on the Site, including the specific URL(s) or other identifying information. - Your full name, address, telephone number, and email address. ### Required Statements - A statement by you that you have a good faith belief that the disputed use is not authorized by the copyright owner, its agent, or the law. - A statement by you, made under penalty of perjury, that the above information in your notice is accurate and that you are the copyright owner or authorized to act on the copyright owner's behalf. ### Additional Evidence - Documentation proving your ownership of the copyright or authorization to act on the owner's behalf. - Screenshots or other evidence showing the alleged infringement. - Any additional information that may help us evaluate your claim. ## Notice Review Timeline ### Initial Review We will acknowledge receipt of your DMCA notice within 2 business days. Our legal team will conduct an initial review within 5 business days to ensure all required information is provided. ### Content Removal If your notice is valid, we will remove the allegedly infringing content within 10 business days of receiving a complete DMCA notice. We will notify the affected user of the removal. ### Counter-Notice Period The affected user has 14 business days to submit a counter-notice if they believe the removal was incorrect. ## Counter-Notice Process ### Counter-Notice Requirements - Your physical or electronic signature - Identification of the removed content and its original location - A statement under penalty of perjury that you have a good faith belief the material was removed by mistake or misidentification - Your name, address, and phone number - A statement that you consent to the jurisdiction of the federal district court for your judicial district ### Content Restoration If we receive a valid counter-notice and the original complainant does not notify us of legal action within 14 business days, we will restore the content within 2-3 business days after this period. ## False Claims and Consequences ### Penalties for False Claims Making false claims in a DMCA notice or counter-notice may result in serious consequences: - Legal liability for damages, including costs and attorney's fees - Permanent ban from using our services - Criminal penalties for perjury ## Dispute Resolution ### Resolution Process - Initial mediation through our legal team - Option for third-party mediation services - Final resolution through appropriate legal channels if necessary ### Documentation Requirements All parties must maintain complete records of all correspondence, notices, and evidence related to the dispute. These records may be required if legal action is pursued. ## Submit Your DMCA Notice Please note that submitting a false DMCA notice may have legal consequences. Ensure that your claim is valid and that you have a good faith belief that the use of the material in question is not authorized by the copyright owner, its agent, or the law. Send all DMCA takedown notices to our designated copyright agent at: Email: [dmca@sorena.io](mailto:dmca@sorena.io) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/dmca --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "Artifacts" canonical_url: "https://www.sorena.io/artifacts" source_url: "https://www.sorena.io/artifacts/latam" author: "Sorena AI" description: "GRC artifacts generated by Sorena AI from a simple prompt." keywords: - "GRC artifacts" - "governance risk and compliance" - "compliance artifacts" - "compliance checklists" - "compliance checklist" - "compliance calendar" - "compliance deadlines calendar" - "compliance templates" - "policy templates" - "audit checklist" - "decision maps" - "compliance decision maps" - "cybersecurity compliance" - "privacy compliance" - "product compliance" - "EU compliance" - "UK compliance" - "US privacy compliance" - "NIS2 guide" - "Cyber Resilience Act CRA guide" - "EU Data Act guide" - "EU DORA guide" - "ISO 27001 implementation guide" - "NIST CSF 2.0 guide" - "ETSI EN 303 645 guide" - "Sorena AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Artifacts - LATAM *Artifacts* ## Governance, Risk, and Compliance Artifacts GRC artifacts generated by Sorena AI from a simple prompt. What you see here is a snapshot, and they age fast. Our Copilot regenerates, combines, and tailors them to your context on demand. Our Autopilot evaluates where you stand, finds the gaps, and acts on them. [Stop auditing yourself](/solutions/assessment.md) *Filter: LATAM* ## Available Artifacts ### [Brazil LGPD Timeline and Decision Flow](/artifacts/latam/brazil-lgpd.md) A practical LGPD artifact with key dates and a decision flow to help teams understand scope, roles, and core compliance obligations. By Sorena AI | Updated 2026-02-21 ## Want these tailored to your needs? Get a customised guideline aligned to your organisation, systems, and deadlines, with clear actions your team can execute. [Talk to an expert](/contact.md) --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam --- --- title: "EU AI Act Timeline, Decision Flow, and Compliance Guides" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act" source_url: "https://www.sorena.io/artifacts/eu/artificial-intelligence-act" author: "Sorena AI" description: "Use this EU AI Act hub to work from the actual phased dates in Regulation (EU) 2024/1689, classify prohibited practices, high risk systems." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "EU AI Act" - "Regulation (EU) 2024/1689" - "EU AI Act timeline" - "EU AI Act decision flow" - "prohibited AI practices" - "Article 5 AI Act" - "high risk AI Annex III" - "Annex IV technical documentation" - "Article 50 transparency" - "EU AI Act GPAI" - "Article 53 training content summary" - "Article 55 serious incidents" - "EU AI Act penalties" - "AI Office" - "AI Act implementation guides" - "Article 5" - "Annex III" - "Article 50" - "General purpose AI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Timeline, Decision Flow, and Compliance Guides Use this EU AI Act hub to work from the actual phased dates in Regulation (EU) 2024/1689, classify prohibited practices, high risk systems. ![EU AI Act artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-ai-act-timeline-small.jpg?v=cheatsheets%2Fprod) *EU AI Act* *Free Resource* ## EU AI Act Timeline, Decision Flow & Guides Use this artifact to classify whether your AI system or model is prohibited, high risk, transparency triggered, or covered by GPAI duties, then turn that answer into a practical compliance plan grounded in Regulation (EU) 2024/1689. The phased dates matter: the Regulation entered into force on 1 August 2024, prohibited practices and AI literacy apply from 2 February 2025, GPAI obligations apply from 2 August 2025, and most remaining rules apply from 2 August 2026, with later transition dates for certain cases. [Get an AI Act readiness review](/contact.md) ## What you can decide faster - **Scope and role**: Decide whether the output used in the Union brings the system into scope and who is provider, deployer, importer, or authorised representative. - **Risk and obligations**: Separate Article 5 stop issues from Annex III high risk work, Article 50 disclosures, and GPAI provider duties. - **Evidence path**: Move from classification to documentation, release gates, supplier asks, and post market monitoring. By Sorena AI | Updated 2026 | No signup required ### Quick scan *AI Act* - **Phased dates**: Track the 2025, 2026, 2027, and 2030 milestones that change what must be operational. - **Decision flow**: Classify prohibited practices, high risk status, transparency duties, and GPAI exposure. - **Implementation guides**: Use page specific guidance for applicability, high risk evidence, transparency, GPAI, and penalties. Use the decision flow first, then use the linked guides to assign owners, evidence, and review dates. | Value | Metric | | --- | --- | | 1 Aug 2024 | Entered force | | 2 Feb 2025 | Early duties | | 2 Aug 2025 | GPAI live | | 2 Aug 2026 | Main date | **Key highlights:** Classify scope | Check Article 5 | Plan evidence ## Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/artificial-intelligence-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/artificial-intelligence-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/artificial-intelligence-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/artificial-intelligence-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/artificial-intelligence-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/artificial-intelligence-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/artificial-intelligence-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/artificial-intelligence-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/artificial-intelligence-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/artificial-intelligence-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/artificial-intelligence-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/artificial-intelligence-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/artificial-intelligence-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/artificial-intelligence-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/artificial-intelligence-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/artificial-intelligence-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. ## Key dates for EU AI Act implementation *AI Act Timeline* Track the legal phases so inventory, Article 5 screening, Chapter V work, high risk controls, and transition cases are sequenced correctly. ## Which AI Act duties apply to your system or model *AI Act Decision Flow* Use the decision flow to route the system into the right obligation track, then open the supporting guides for detailed implementation. *Next step* ## Turn EU AI Act Timeline, Decision Flow & Guides into an operational assessment workflow EU AI Act Timeline, Decision Flow & Guides should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into Research Copilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU AI Act Timeline, Decision Flow & Guides and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for EU AI Act Timeline, Decision Flow & Guides. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs from the same artifact. - **Download decision flow**: Share classification logic across product and legal teams. - **Download timeline**: Align phased dates in your implementation plan. - [Talk through EU AI Act Timeline, Decision Flow & Guides](/contact.md): Review your current process, evidence model, and next steps for EU AI Act Timeline, Decision Flow & Guides. ## Decision Steps ### STEP 1: Does the EU AI Act apply to your organisation and AI activity? *Reference: Art. 2(1)* - Providers placing on the market / putting into service AI systems or placing GPAI models on the Union market - Deployers established or located in the Union - Non-EU providers/deployers where the output is used in the Union - Importers and distributors of AI systems; product manufacturers placing AI systems with their products under their name/trademark; authorised representatives of non-EU providers - Affected persons located in the Union (rights and safeguards) - **NO** EU AI Act likely does not apply - **YES** Does your AI system or use-case fall under a prohibited AI practice? ### STEP 2: Does your AI system or use-case fall under a prohibited AI practice? *Reference: Art. 5* - Manipulative/deceptive techniques materially distorting behaviour causing (or likely causing) significant harm (Art. 5(1)(a)) - Exploitation of vulnerabilities (age/disability/socio-economic) causing (or likely causing) significant harm (Art. 5(1)(b)) - Social scoring leading to detrimental/unjustified or disproportionate treatment (Art. 5(1)(c)) - Criminal offence risk assessment of individuals based solely on profiling/personality traits (Art. 5(1)(d)) - Untargeted scraping to build or expand facial recognition databases (Art. 5(1)(e)) - Emotion recognition in workplace/education (narrow medical/safety exception) (Art. 5(1)(f)) - Biometric categorisation inferring sensitive attributes (Art. 5(1)(g)) - Real-time remote biometric ID in public spaces for law enforcement (narrow exceptions + safeguards) (Art. 5(1)(h)) - **YES** Stop: prohibited AI practice - **NO** Are you placing a General-Purpose AI (GPAI) model on the Union market as a provider? ### STEP 3: Are you placing a General-Purpose AI (GPAI) model on the Union market as a provider? *Reference: Art. 2(1)(a); Art. 3(3),(63)* - GPAI model = broadly capable + integrable into downstream systems - If you are only using a third-party model, continue on the AI-system path - **YES** Is it a GPAI model with systemic risk? - **NO** Is your AI system classified as high-risk? ### SYSTEMIC RISK: Is it a GPAI model with systemic risk? - Systemic risk models have additional obligations (Art. 55) - Commission can designate models ex officio; list is published and kept up to date (Art. 52(4)-(6)) - Commission Guidelines (C(2025) 5045 final) provide practical examples and classification guidance - **YES** GPAI systemic-risk obligations - **NO** GPAI model provider obligations ### STEP 4: Is your AI system classified as high-risk? *Reference: Art. 6; Annex I; Annex III* - High-risk if safety component/product under Annex I + third-party conformity assessment (Art. 6(1)) - High-risk if listed in Annex III (Art. 6(2)) - Annex III derogation: may be not high-risk if no significant risk + narrow task (Art. 6(3)) - Annex III is always high-risk if it performs profiling of natural persons (Art. 6(3)) - If you claim Annex III is not high-risk: document assessment + register (Art. 6(4); Art. 49(2)) - **YES** Are you the provider of the high-risk AI system (or did you become one via modifications/rebranding)? - **NO** Does your AI system trigger AI Act transparency obligations? ### STEP 5: Are you the provider of the high-risk AI system (or did you become one via modifications/rebranding)? *Reference: Art. 3(3); Art. 16; Art. 25* - Providers carry conformity assessment, CE marking, documentation and QMS duties - Importers/distributors/deployers may become providers if they rebrand, substantially modify, or change intended purpose - **YES** High-risk AI provider obligations - **NO** High-risk AI deployer obligations ### STEP 6: Does your AI system trigger AI Act transparency obligations? *Reference: Art. 50* - AI systems that interact with people (chatbots/assistants) must disclose the interaction (Art. 50(1)) - Generative AI outputs must be marked as AI-generated/manipulated (Art. 50(2)) - Deployers of emotion recognition or biometric categorisation must inform exposed persons (Art. 50(3)) - Deepfakes and public-interest AI-generated text have disclosure duties (Art. 50(4)) - **YES** Transparency obligations apply - **NO** No high-risk / transparency trigger found ## Reference Information ### Scope & Exclusions (Quick) - Excludes: national security; exclusively military/defence/national security use (Art. 2(3)) - Excludes: AI systems/models developed solely for scientific R&D (Art. 2(6)) - Excludes: personal non-professional use by natural persons (Art. 2(10)) - Open-source exception (limited): not applicable unless high-risk or Art. 5/50 systems (Art. 2(12)) - Sectoral EU product/consumer laws still apply (Art. 2(9)) ### Key Roles & Definitions - Provider: develops (or has developed) and places on market/puts into service under own name/trademark (Art. 3(3)) - Deployer: uses an AI system under its authority (Art. 3(4)) - GPAI model: capable of performing a wide range of distinct tasks; integrable downstream (Art. 3(63)) - Systemic risk: high-impact GPAI risk that can propagate at scale (Art. 3(65)) - Value chain: modifications or rebranding can make you the provider (Art. 25) ### Baseline Obligation: AI Literacy - Providers and deployers must take measures to ensure sufficient AI literacy of staff/users operating AI on their behalf - Consider technical knowledge, experience, education/training, and the context of use - Applies even where your system is not high-risk ### Governance & Authorities - AI Office (Union level): implementation/monitoring for AI systems and GPAI models (Art. 64; Def. Art. 3(47)) - European AI Board: Union-level governance and coordination (Art. 65) - Advisory forum + scientific panel support implementation (Arts. 67-68) - National competent authorities + single point of contact (Art. 70) ### Commission GPAI Guidelines (Scope) - C(2025) 5045 final (18 July 2025): scope of Chapter V obligations - Examples: what counts as a GPAI model; lifecycle; who is a provider placing on market - Open-source exemptions: conditions on licence, lack of monetisation, public availability of parameters - Annex: training compute estimation (for classification guidance) ### GPAI Code of Practice - Voluntary tool to demonstrate compliance (Arts. 53(4), 55(2), 56) - Chapters: Transparency, Copyright, Safety & Security - Includes templates (e.g., Model Documentation Form) and practical measures ### Templates & Reporting (GPAI) - Public Summary of Training Content template (Art. 53(1)(d)) - Model Documentation Form template (Code of Practice - Transparency chapter) - Serious incidents reporting template (Art. 55(1)(c)) ### Annex III (High-Risk Areas) - Biometrics (remote ID, sensitive categorisation, emotion recognition) - Critical infrastructure (as safety components) - Education/vocational training (admission, evaluation, monitoring tests) - Employment/workers management (recruitment, monitoring, termination, task allocation) - Essential services/benefits (credit scoring, insurance pricing, emergency call triage) - Law enforcement; migration/asylum/border; justice & democratic processes ### Annex III Derogation (Not High-Risk Claims) - Annex III system can only be treated as not high-risk if it does not pose a significant risk of harm (incl. not materially influencing decision outcomes) and fits a narrow-task condition (Art. 6(3)) - Always high-risk if it performs profiling of natural persons (Art. 6(3)) - Provider must document the assessment and is subject to registration (Art. 6(4); Art. 49(2)) ### Section 2 Requirements (High-Risk) - Risk management system (Art. 9) - Data & data governance (Art. 10) - Technical documentation (Art. 11; Annex IV) - Record-keeping/logging (Arts. 12 and 19) - Transparency + instructions for use (Art. 13) - Human oversight (Art. 14) - Accuracy, robustness, cybersecurity (Art. 15) ### Responsibilities Along the Value Chain - If you rebrand, substantially modify, or change intended purpose you can become the provider (Art. 25(1)) - Initial provider must cooperate and provide required info/technical access (Art. 25(2)) - Supplier/provider agreements should allocate info/access needed for compliance (Art. 25(4)) ### Notified Bodies & Conformity Assessment - Member States designate notifying authorities (Art. 28) - Notified bodies must meet independence and competence requirements (Art. 31) - Identification numbers and lists of notified bodies (Art. 35) - Use notified bodies where required by the conformity route (Art. 43 context) ### Harmonised Standards & Common Specifications - Applying harmonised standards can create a presumption of conformity for covered AI Act requirements/obligations (Art. 40(1)) - If harmonised standards are missing or insufficient, the Commission may adopt common specifications (Art. 41) - Standards/common specs can reduce ambiguity for documentation, testing, and conformity assessment routes (Art. 40-43 context) ### Fundamental Rights Impact Assessment (FRIA) - Required before deploying certain high-risk AI systems (Art. 27(1)) - Describe use context, affected groups, risks, human oversight, and mitigations (Art. 27(1)(a)-(f)) - Update when changes occur; notify market surveillance authority with a template (Art. 27(2)-(5)) ### Code of Practice (AI-generated Content) - AI Office-led code of practice supports Art. 50(2) and (4) compliance - Working group 1 (providers): machine-readable marking + robustness/interoperability - Working group 2 (deployers): disclosure of deepfakes and other transparency duties - Drafting timeline targets readiness before Art. 50 obligations apply ## Possible Outcomes ### [PROHIBITED] Stop: prohibited AI practice Do not place on the market / put into service / use in the Union - Re-design the system and/or intended purpose to remove the prohibited practice - Assess if a different use-case or safeguards move you out of Art. 5 - Document the decision and seek legal review for edge cases (e.g., law enforcement exceptions) ### [GPAI] GPAI model provider obligations Documentation, downstream transparency, copyright policy, and training-content summary - Technical documentation for AI Office / authorities (Art. 53(1)(a); Annex XI) - Information for downstream system providers (Art. 53(1)(b); Annex XII) - Copyright compliance policy incl. rights reservations (Art. 53(1)(c)) - Publish public summary of training content (Art. 53(1)(d)) ### [GPAI (SYSTEMIC RISK)] GPAI systemic-risk obligations Art. 53 + additional systemic-risk controls - Model evaluation + adversarial testing to identify/mitigate systemic risks (Art. 55(1)(a)) - Assess and mitigate systemic risks at Union level (Art. 55(1)(b)) - Report serious incidents + corrective measures to AI Office without undue delay (Art. 55(1)(c)) - Ensure adequate cybersecurity for the model and supporting infrastructure (Art. 55(1)(d)) ### [HIGH-RISK (PROVIDER)] High-risk AI provider obligations Requirements + conformity assessment + registration + post-market monitoring - Meet Section 2 requirements (risk mgmt, data governance, logs, transparency, human oversight, cybersecurity) - Quality management system (Art. 17) + technical documentation (Art. 11; Annex IV) - Conformity assessment (Art. 43) + EU DoC (Art. 47) + CE marking (Art. 48) - Register in EU database (Art. 49) and run post-market monitoring (Art. 72) + incident reporting (Art. 73) ### [HIGH-RISK (DEPLOYER)] High-risk AI deployer obligations Use per instructions, human oversight, monitoring, FRIA (some cases), and transparency to affected persons - Use per provider instructions + assign competent human oversight (Art. 26(1)-(3)) - Input data quality under your control (Art. 26(4)) - Monitor + suspend and notify for risks/serious incidents (Art. 26(5)) - Inform individuals subject to Annex III decisioning systems (Art. 26(11)); perform FRIA where applicable (Art. 27) ### [TRANSPARENCY] Transparency obligations apply Disclose AI interaction, label AI-generated content, and handle deepfakes - Inform users when they interact with an AI system unless obvious (Art. 50(1)) - Inform people exposed to emotion recognition or biometric categorisation systems (Art. 50(3)) - Mark synthetic content outputs machine-readably and detectably (Art. 50(2)) - Disclose deepfakes; disclose AI-generated public-interest text unless editorial control applies (Art. 50(4)) - Provide info clearly and accessibly by first interaction/exposure (Art. 50(5)) ### [BASELINE] No high-risk / transparency trigger found Still in scope: keep core controls and monitor future classification changes - Maintain AI literacy measures (Art. 4) - Re-check classification when intended purpose, autonomy, or context changes - Track Commission guidelines and standards: Annex III use cases and Art. 50 list can evolve ### [OUT OF SCOPE] EU AI Act likely does not apply No Union nexus under Art. 2(1) (or an exclusion applies) - Document why you are out of scope (facts + legal basis) - Re-assess if output becomes used in the Union or you place systems/models on the Union market - Other laws (GDPR, product safety, sector rules) may still apply ## EU AI Act Timeline | Date | Event | Reference | | --- | --- | --- | | 2024-07-12 | AI Act published in Official Journal (OJ L) | Reg. (EU) 2024/1689 | | 2024-08-01 | AI Act enters into force (20 days after publication) | Art. 113 | | 2025-02-02 | Chapters I (General provisions) and II (Prohibited practices) apply | Art. 113(a) | | 2025-05-02 | Codes of practice for GPAI should be ready (latest) | Art. 56(9) | | 2025-08-02 | GPAI obligations + governance + notified bodies + penalties apply | Art. 113(b) | | 2026-02-02 | Commission provides Art. 6 high-risk classification guidelines (latest) | Art. 6(5) | | 2026-08-02 | AI Act applies (general application date) | Art. 113 | | 2027-08-02 | Art. 6(1) (Annex I product/safety-component high-risk) + corresponding obligations apply | Art. 113(c) | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2024-01-24 | Commission Decision establishes the European AI Office | Notified bodies & governance | | | 2024-07-12 | AI Act published in the Official Journal | Legislative milestones | | | 2024-08-01 | AI Act enters into force | Legislative milestones | | | 2025-02-02 | Chapters I and II apply (including prohibited AI practices) | Prohibitions | | | 2025-07-10 | General-Purpose AI Code of Practice published | GPAI | | | 2025-07-18 | Commission adopts guidelines on GPAI obligations scope | GPAI | | | 2025-08-02 | GPAI obligations and governance provisions apply | GPAI | | | 2025-09-01 | Consultation to develop guidelines and a Code of Practice (transparent AI systems) | Transparency & labelling | | | 2025-09-26 | Consultation on serious AI incident reporting interplay | Incident reporting & post-market | | | 2025-10-01 | Chairs and vice-chairs selection | Transparency & labelling | | | 2025-11-04 | Reporting template for serious incidents (GPAI systemic risk) published | Incident reporting & post-market | | | 2025-11-05 | Kick-off plenary (start of 1st drafting round) | Transparency & labelling | | | 2025-11-17 | 1st working group meetings | Transparency & labelling | | | 2025-12-05 | Template published for public summary of GPAI training content | GPAI | | | 2025-12-17 | First draft published | Transparency & labelling | | | 2026-01-12 | Working group meetings (start of 2nd drafting round) | Transparency & labelling | | | 2026-01-21 | Workshops (working groups 1 and 2) | Transparency & labelling | | | 2026-03-01 | Second draft published (TBC) | Transparency & labelling | | | 2026-04-01 | Working group meetings (TBC) | Transparency & labelling | | | 2026-05-01 | Closing plenary and final Code of Practice published | Transparency & labelling | | | 2026-08-02 | AI Act applies (main obligations start) | Legislative milestones | | | 2026-08-02 | Commission enforcement powers for GPAI enter into application | GPAI | | | 2027-08-02 | Article 6(1) and corresponding obligations apply | High-risk AI | | | 2027-08-02 | Existing GPAI providers must comply by this date | GPAI | | **Event details:** - **2024-01-24 - Commission Decision establishes the European AI Office**: 24 January 2024: European Commission publishes the decision establishing the European AI Office. - **2024-07-12 - AI Act published in the Official Journal**: 12 July 2024: Regulation (EU) 2024/1689 is published in the Official Journal (OJ L, 12.7.2024). - **2024-08-01 - AI Act enters into force**: 1 August 2024: The EU AI Act enters into force (20 days after publication). - **2025-02-02 - Chapters I and II apply (including prohibited AI practices)**: 2 February 2025: Chapters I and II apply under the AI Act entry into force and application rules. - **2025-07-10 - General-Purpose AI Code of Practice published**: 10 July 2025: The General-Purpose AI (GPAI) Code of Practice is published as a voluntary tool to help providers meet AI Act obligations. - **2025-07-18 - Commission adopts guidelines on GPAI obligations scope**: 18 July 2025: Commission finalises its guidelines on the scope of obligations for general-purpose AI models (C(2025) 5045 final). - **2025-08-02 - GPAI obligations and governance provisions apply**: 2 August 2025: Chapter V (general-purpose AI) and selected governance provisions start to apply (per Article 113). - **2025-09-01 - Consultation to develop guidelines and a Code of Practice (transparent AI systems)**: September 2025: Consultation to develop guidelines and a Code of Practice on transparent AI systems, plus a call for expression of interest to participate. - **2025-09-26 - Consultation on serious AI incident reporting interplay**: 26 September 2025: Consultation referenced alongside serious incident reporting guidance and templates for AI incidents. - **2025-10-01 - Chairs and vice-chairs selection**: October 2025: Eligibility checks and selection of applications for chairs and vice-chairs. - **2025-11-04 - Reporting template for serious incidents (GPAI systemic risk) published**: 4 November 2025: Commission publishes a reporting template for serious incidents involving general-purpose AI models with systemic risk. - **2025-11-05 - Kick-off plenary (start of 1st drafting round)**: 5 November 2025: Kick-off plenary; start of the first drafting round. - **2025-11-17 - 1st working group meetings**: 17-18 November 2025: First working group meetings. - **2025-12-05 - Template published for public summary of GPAI training content**: 5 December 2025: Commission publishes an explanatory notice and a template for the public summary of training content (Article 53(1)(d)). - **2025-12-17 - First draft published**: 17 December 2025: Publication of the first draft. - **2026-01-12 - Working group meetings (start of 2nd drafting round)**: 12 and 14 January 2026: Working group meetings; start of the second drafting round. - **2026-01-21 - Workshops (working groups 1 and 2)**: 21-22 January 2026: Workshops for working groups 1 and 2. - **2026-03-01 - Second draft published (TBC)**: March 2026 (TBC): Publication of the second draft; start of the final drafting round. - **2026-04-01 - Working group meetings (TBC)**: April 2026 (TBC): Working group meetings. - **2026-05-01 - Closing plenary and final Code of Practice published**: May-June 2026: Closing plenary; publication of the final Code of Practice. - **2026-08-02 - AI Act applies (main obligations start)**: 2 August 2026: The AI Act applies in general (per Article 113). - **2026-08-02 - Commission enforcement powers for GPAI enter into application**: 2 August 2026: Commission enforcement powers for obligations on providers of GPAI models enter into application (including fines). - **2027-08-02 - Article 6(1) and corresponding obligations apply**: 2 August 2027: Article 6(1) and corresponding obligations apply (per Article 113). - **2027-08-02 - Existing GPAI providers must comply by this date**: By 2 August 2027: Providers of GPAI models placed on the market before 2 August 2025 must comply, per Commission guidance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/artificial-intelligence-act --- --- title: "Australia Cyber Security Act 2024 Compliance Hub" canonical_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act" source_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act" author: "Sorena AI" description: "Practical Australia Cyber Security Act 2024 compliance hub covering commencement dates, smart device security standards." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "Australia Cyber Security Act 2024 compliance" - "Cyber Security Act 2024 compliance" - "Australia Cyber Security Act 2024 timeline" - "Australia Cyber Security Act 2024 requirements" - "Australia Cyber Security Act 2024 checklist" - "smart device security standards Australia" - "relevant connectable product Australia" - "consumer grade relevant connectable products" - "statement of compliance smart devices" - "statement of compliance recordkeeping" - "ransomware payment reporting 72 hours" - "ransomware reporting Australia" - "turnover threshold $3 million" - "reporting business entity Australia" - "SOCI Act critical infrastructure" - "cyber incident reporting Australia" - "compliance evidence pack" - "implementation guide" - "compliance calendar" - "compliance templates" - "Australia Cyber Security Act 2024" - "Cyber Security Act 2024" - "smart device security standards" - "ransomware payment reporting" - "72 hour reporting" - "statement of compliance" - "relevant connectable products" - "APAC compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Australia Cyber Security Act 2024 Compliance Hub Practical Australia Cyber Security Act 2024 compliance hub covering commencement dates, smart device security standards. ![Australia Cyber Security Act artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-au-cyber-security-act-timeline-small.jpg?v=cheatsheets%2Fprod) *Australia Cyber Security Act* *Free Resource* ## Australia Cyber Security Act Timeline and Decision Flow A practical Australia Cyber Security Act 2024 compliance hub for legal, product, security, and operations teams. Use the timeline and decision flow to understand when Part 2 and Part 3 apply, then use the topic guides to run scope tests, implement smart device controls, issue statements of compliance, and prepare ransomware payment reporting within 72 hours. This hub brings together the Act, the Smart Devices Rules 2025, the Ransomware Payment Reporting Rules 2025, and the CIRB Rules 2025. Focus areas include relevant connectable product scope, consumer grade exemptions, support period publication, statement of compliance recordkeeping, reporting business entity thresholds, enforcement risk, and cross market comparison pages. [Get implementation support](/contact.md) ## What you can decide faster - **Smart devices**: Confirm relevant connectable product scope, implement the smart device standard, issue compliant statements, and maintain a retrievable evidence pack. - **Ransomware reporting**: Decide whether you are a reporting business entity, document the 3 million dollar threshold logic, and prepare the 72 hour report path before an incident. - **Evidence pack**: Define owners, acceptance criteria, website disclosure checks, and regulator ready records for statements, support periods, and incident reports. By Sorena AI | Updated 2026 | No signup required ### Quick scan *Artifact* - **Timeline view**: Plan staged commencement and operational readiness checkpoints across Part 2, Part 3, and the 2025 rules. - **Decision flow**: Turn scope, product, and reporting business entity questions into clear implementation actions. - **Topic guides**: Deep dives on requirements, checklists, deadlines, templates, reporting playbooks, and comparison guides. Use the artifact and topic guides to turn Australia Cyber Security Act 2024 legal text into release gates, reporting playbooks, website disclosures, and evidence controls. | Value | Metric | | --- | --- | | 1 | Artifact | | 16 | Guides | | 2026 | Updated | | SEO | Optimized | **Key highlights:** Scope first | Plan controls | Track evidence ## Topic Guides - [Australia Cyber Security Act 2024 Applicability Test | Who Must Comply](/artifacts/apac/australia-cyber-security-act/applicability-test.md): Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations. - [Australia Cyber Security Act 2024 Compliance Checklist](/artifacts/apac/australia-cyber-security-act/checklist.md): Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting. - [Australia Cyber Security Act 2024 Compliance Guide | Implementation Playbook](/artifacts/apac/australia-cyber-security-act/compliance.md): A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements. - [Australia Cyber Security Act 2024 Compliance Templates | Statement of Compliance, Ransomware Report, Evidence Pack, Vulnerability Disclosure, Support Period](/artifacts/apac/australia-cyber-security-act/templates.md): Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field. - [Australia Cyber Security Act 2024 Deadlines and Compliance Calendar | Commencement Dates](/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar.md): Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent. - [Australia Cyber Security Act 2024 FAQ | Frequently Asked Questions](/artifacts/apac/australia-cyber-security-act/faq.md): Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024. - [Australia Cyber Security Act 2024 Requirements | Smart Device and Ransomware Reporting Obligations](/artifacts/apac/australia-cyber-security-act/requirements.md): Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure. - [Australia Cyber Security Act 2024 Timeline and Commencement Dates | Full Schedule](/artifacts/apac/australia-cyber-security-act/timeline-and-commencement.md): Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024. - [Australia Cyber Security Act 2024 vs EU Cyber Resilience Act | Full CRA Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act.md): Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements. - [Australia Cyber Security Act 2024 vs UK PSTI Act | Product Security Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act.md): Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements. - [Australia Smart Device Compliance Checklist | Cyber Security Act 2024 | Sorena](/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist.md): Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure. - [Penalties and fines | Australia Cyber Security Act 2024 | 60 Penalty Units, Smart Device Enforcement, Ransomware Reporting](/artifacts/apac/australia-cyber-security-act/penalties-and-fines.md): Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals. - [Ransomware Payment Reporting in 72 Hours | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours.md): Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. - [Scope and Definitions | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/scope-and-definitions.md): Complete guide to the Australia Cyber Security Act 2024 scope and definitions. - [Smart device security standards | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/smart-device-security-standards.md): Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2. - [Statement of Compliance and Recordkeeping | Australia Cyber Security Act 2024 | Section 9, Section 10, 5 Year Retention](/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping.md): Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025. ## Key milestones for Australia Cyber Security Act *Timeline* Use timeline milestones to sequence policy, engineering, assurance, and reporting work. ## How to operationalize Australia Cyber Security Act *Decision Flow* Use the decision flow to convert applicability and requirement questions into clear actions. *Next step* ## Turn Australia Cyber Security Act Timeline and Decision Flow into an operational assessment workflow Australia Cyber Security Act Timeline and Decision Flow should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into Research Copilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from Australia Cyber Security Act Timeline and Decision Flow and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for Australia Cyber Security Act Timeline and Decision Flow. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs from the same artifact. - **Download decision flow**: Share the logic with implementation teams. - **Download timeline**: Align milestones across stakeholders. - [Talk through Australia Cyber Security Act Timeline and Decision Flow](/contact.md): Review your current process, evidence model, and next steps for Australia Cyber Security Act Timeline and Decision Flow. ## Decision Steps ### OVERVIEW: Cyber Security Act 2024 (Cth) - compliance decision map - Part 2: smart device security standards (connectable products). - Part 3: ransomware payment reporting (72-hour report) for reporting business entities. - Part 4: voluntary information sharing with the National Cyber Security Coordinator for significant incidents. - Part 5: Cyber Incident Review Board (CIRB) reviews and document production notices. - -> Smart device security standards ### PART 2: Smart device security standards - Applies to relevant connectable products manufactured/supplied on/after Part 2 commencement (s 13). - Current standard covers consumer-grade connectable products acquired by a consumer (Rules s 8). - Mandatory Schedule 1 requirements start 4 Mar 2026 (Rules commencement). - -> Do you manufacture or supply a relevant connectable product that will be acquired in Australia? ### STEP 1: Do you manufacture or supply a relevant connectable product that will be acquired in Australia? *Reference: CSA ss 13, 15, 16* - Relevant connectable product: internet-connectable or network-connectable; not exempted under rules. - Part 2 applies to products manufactured on/after Part 2 commencement OR supplied (not second hand) on/after commencement. - Obligations trigger where you are aware (or should be aware) the product will be acquired in Australia in specified circumstances. - **YES** Is the product a consumer grade relevant connectable product acquired by a consumer in Australia? - **NO** Ransomware payment reporting obligations ### STEP 2: Is the product a consumer grade relevant connectable product acquired by a consumer in Australia? *Reference: Smart Devices Rules 2025 ss 6, 8* - Consumer grade: intended/likely for personal, domestic or household use. - Excluded: desktops/laptops, tablets, smartphones, therapeutic goods, road vehicles, vehicle components. - Specified circumstance: acquired in Australia by a consumer (ACL). - **YES** Mandatory smart device security standard applies - **NO** No mandatory smart device standard under current Rules ### PART 3: Ransomware payment reporting obligations - If you are a reporting business entity and a ransomware payment is made, report within 72 hours (CSA s 27). - Turnover threshold: $3 million (Rules s 6). - Payment can be money or a non-monetary benefit. - -> Are you a 'reporting business entity' at the time the ransomware payment is made? ### STEP 3: Are you a 'reporting business entity' at the time the ransomware payment is made? *Reference: CSA s 26(2); Ransomware Rules 2025 s 6* - Track A: business in Australia + previous FY annual turnover > $3m (or prorated), and not a Commonwealth/State body, and not a SOCI responsible entity. - Track B: responsible entity for a critical infrastructure asset to which SOCI Act Part 2B applies. - If unsure: confirm turnover and whether you are a SOCI responsible entity. - **YES** Did an extortion demand and a ransomware payment occur in connection with a cyber security incident impacting you? - **NO** Significant incident coordination (voluntary) ### STEP 4: Did an extortion demand and a ransomware payment occur in connection with a cyber security incident impacting you? *Reference: CSA s 26(1)* - Incident occurred/occurring/imminent and is a cyber security incident (s 9). - Demand made by an extorting entity to benefit from the incident/its impact on you. - You made a payment/benefit, or you're aware another entity made it on your behalf, directly related to the demand. - **YES** Ransomware payment report required - **NO** Significant incident coordination (voluntary) ### PART 4: Significant incident coordination (voluntary) - If impacted by (or likely impacted by) a significant cyber security incident, you may voluntarily share info with the National Cyber Security Coordinator (CSA s 35). - Impacted entity scope: carrying on a business in Australia OR a SOCI responsible entity (CSA s 35(1)(d)). - There is no obligation to provide information in response to a request (note to s 35). - Protections apply (Div 3) and this does not replace other reporting duties (CSA s 44). - -> Are you impacted by a 'significant cyber security incident'? ### STEP 5: Are you impacted by a 'significant cyber security incident'? *Reference: CSA s 34* - Material risk of serious prejudice to social/economic stability, defence, or national security; OR - Incident is/could be of serious concern to the Australian people. - **YES** Voluntary information sharing available - **NO** Cyber Incident Review Board (CIRB) ### PART 5: Cyber Incident Review Board (CIRB) - CIRB can cause reviews into certain incidents (CSA s 46). - Entities may be requested (voluntary) or required (notice) to provide documents (CSA ss 48-50). - Draft review reports must not be disclosed (CSA s 59). - -> Could your incident be eligible for a CIRB review (or are you referring one)? ### STEP 6: Could your incident be eligible for a CIRB review (or are you referring one)? *Reference: CSA s 46* - Referrals: Minister, Coordinator, impacted entity, or Board member (s 46(1)). - Criteria: serious prejudice, novel/complex methods/tech, or serious concern (s 46(3)). - Timing: only after incident + immediate response ended, and Minister approves terms (s 46(2)). - **YES** Have you received a notice requiring you to produce documents (s 49)? - **NO** Be ready to cooperate if approached ### STEP 7: Have you received a notice requiring you to produce documents (s 49)? *Reference: CSA ss 48-50* - s 48 request for info/docs is voluntary (no requirement to comply). - s 49 notice (compulsory) can be issued to certain non-government entities involved in the incident, after a s 48 request; must allow at least 14 days. - Non-compliance with a s 49 notice is a civil penalty (s 50), subject to exceptions. - **YES** Comply with the s 49 notice (document production) - **NO** Be ready to cooperate if approached ## Reference Information ### Key definitions (CSA) - Cyber security incident: s 9 (tied to SOCI meaning + constitutional limits). - Relevant connectable product: internet- or network-connectable; not exempted (s 13). - Ransomware payment: payment/benefit to extorting entity directly related to demand (s 26). - Reporting business entity: turnover or SOCI Part 2B responsible entity test (s 26). - Significant cyber security incident: high-impact/serious concern test (s 34). ### Extraterritorial reach - CSA applies both within and outside Australia (s 5). - Practical triggers still depend on the Part (e.g., products acquired in Australia; business in Australia; SOCI Part 2B links). ### Security standard (Schedule 1) - core requirements - Passwords: unique per product or user-defined; not incremental/guessable; avoid public info and raw serials (crypto/hashing if used). - Security issue reporting: publish contact + acknowledgement + status updates; accessible/clear; in English; free; no personal info required. - Support period & updates: publish defined support period (end date) for security updates; do not shorten; publish extensions; ensure prominence and clarity (including understandable without prior technical knowledge). ### Statement of compliance (Rules s 9) - include - Product type + batch identifier. - Manufacturer name/address + authorised representative(s) (including those in Australia). - Declarations: product complies with standard + manufacturer complied with other Schedule 1 obligations. - Defined support period at issue date; plus signatory signature/name/function + place/date of issue. - Retention: 5 years (Rules s 10). ### Supplier obligations (high-level) - Do not supply non-compliant products in Australia when aware/should be aware of relevant circumstances. - Supply product with manufacturer-prepared statement of compliance. - Retain copy of statement for required period (5 years for current standard). ### Enforcement tools (Part 2) - Secretary may issue compliance, stop, and recall notices (Div 3). - Internal review is available for compliance/stop/recall notices (and certain variations) (s 22). - Failure to comply with a recall notice can trigger public notification (s 20), including matters prescribed by rules (Smart Devices Rules s 11). - Independent examination/audit may be used to assess compliance and statements (s 23). ### Scope notes (current standard) - Current standard only covers consumer-grade relevant connectable products acquired by a consumer in Australia (Rules s 8). - Excluded product categories are not subject to Schedule 1 (Rules s 8). - Act allows future standards for other product classes and acquisition circumstances (CSA s 14). ### Turnover threshold (Rules s 6) - Threshold: $3 million (previous financial year). - Part-year formula: $3m x (days carried on / days in previous FY). - SOCI Part 2B responsible entities are in scope regardless of turnover; SOCI responsible entities not covered by Part 2B are not reporting business entities (CSA s 26(2)). ### Report contents (CSA s 27 + Rules s 7) - Entity details: ABN (if any) + address for reporting entity and payor (Rules s 7(2)-(3)). - Incident: when occurred/estimated; when aware; impact on infrastructure + customers; ransomware/malware variant; vulnerabilities exploited; info to assist response (Rules s 7(4)). - Demand: amount/description + method demanded (Rules s 7(5)). - Payment/benefit: amount/description + method provided (Rules s 7(6)). - Communications: nature/timing; brief description; pre-payment negotiations (Rules s 7(7)). ### Protections (Part 3) - Use/disclosure restricted to permitted purposes and not for most civil/regulatory enforcement (CSA ss 29-30; Privacy Act limits apply). - Disclosure to State bodies requires consent (CSA s 11). - Legal professional privilege preserved (s 31). - Info not admissible against reporting entity in most proceedings (s 32), with limited exceptions. ### Liability protection (Part 3) - Good faith compliance with s 27: entity not liable for damages for acts/omissions (s 28(1)). - Officers, employees, and agents also protected when acting in good faith (s 28(2)). - Entity bears an evidential burden when relying on this protection (s 28(3)). ### Who receives the report? - Report goes to a 'designated Commonwealth body' (CSA s 27(1)). - Designated body is set by rules; if none, defaults to the Department + ASD (CSA s 8 definition). - Form may be approved by Secretary; manner may be prescribed by rules (CSA s 27(4)). ### National Cyber Security Coordinator (role) - Lead whole-of-government coordination and triaging of action in response to a significant cyber security incident (s 37). - Inform and advise the Minister and whole of Government on the response (s 37). ### Parallel reporting may still apply - Voluntary sharing under Part 4 does not affect other legal requirements to provide information (CSA s 44). - Act examples: Part 3 ransomware reporting; SOCI Act Part 2B; Telecommunications Act 1997. - Common outside-CSA reporting: OAIC NDB scheme (Privacy Act) and APRA CPS 234 (if applicable). ### Information sharing beyond significant incidents (ss 36, 39) - If it's unclear whether an incident is a cyber security incident or a significant cyber security incident, you can still provide information (s 36(1)). - NCSC may collect and use the information to determine whether the incident qualifies (s 36(2)). - This collection/use is authorised for Privacy Act purposes (note to s 36(2)). - If you provide information about an incident that is not significant (or not a cyber security incident), NCSC use/disclosure is still limited to specific purposes (s 39). ### Part 4 protections (high-level) - Use/disclosure limited to permitted purposes and not for most civil/regulatory enforcement (CSA ss 38-40; Privacy Act limits apply). - Legal professional privilege preserved (s 41). - Info not admissible against impacted entity in most proceedings (s 42), with limited exceptions. - NCSC may be certified as not compellable as a witness for certain matters (s 43). - Disclosure to State bodies requires consent (s 11). ### CIRB Rules 2025 (process highlights) - Board must consider referrals and decide whether a review should be conducted (Rules s 7). - Prioritisation factors include severity/scale and panel availability (Rules s 8). - Reviews must not be conducted if they would interfere with or prejudice investigations/proceedings (Rules s 10). - Board publishes notice when a review will be conducted (Rules s 11). - Board may discontinue a review at any time and must publish notice within 28 days (CSA s 47). ### CIRB reports: publication, redaction, and no-blame constraints - Final review report must be published, excluding redacted sensitive review information (s 52(6)). - Final review report must not apportion blame, determine liability, identify individuals without consent, or allow adverse inference that an entity is subject of review (s 52(4)). - Sensitive review information must be redacted; protected review report contains redacted info + reasons and is provided to Minister and Prime Minister (ss 53-54). ### Confidentiality & protections (Part 5) - If you receive a draft review report, do not disclose/use it except allowed purposes (CSA s 59). - Legal professional privilege preserved (s 57); admissibility limits (s 58). - Use/disclosure restrictions apply to the Board and recipients (ss 55-56). - Disclosure to State bodies requires consent under the CSA framework (s 11). ### Other Australian cyber reporting obligations (common) - SOCI Act Part 2B incident reporting (critical infrastructure). - SOCI Act CIRMP and other enhanced cyber security obligations may also apply (separate regime; depends on asset classification). - Telecommunications Act 1997 reporting (telecommunications entities). - Privacy Act NDB scheme (OAIC): assess within 30 days; notify OAIC/individuals for eligible data breaches. - APRA CPS 234: notify APRA within 72 hours of certain information security incidents (if APRA-regulated). ### Regulatory powers & enforcement framework (Part 6) - CSA civil penalty provisions are enforceable under the Regulatory Powers (Standard Provisions) Act 2014 (s 79). - Enforceable undertakings can cover CSA civil penalty provisions and smart device sections 15-16 (s 79(2)). - Part 6 also includes monitoring/investigation powers and infringement notices mechanisms. ## Possible Outcomes ### [APPLIES] Mandatory smart device security standard applies Security Standards for Smart Devices Rules 2025 (Schedule 1) - effective 4 Mar 2026 - Manufacture in compliance with Schedule 1 (passwords, security issue reporting, defined support period & security updates). - Publish required security information clearly, in English, free of charge (Schedule 1). - Provide/retain a statement of compliance; suppliers must supply with the statement; retain for 5 years (Rules ss 9-10; CSA s 16). ### [NOT COVERED] No mandatory smart device standard under current Rules Part 2 can expand via future rules (other classes/circumstances) - If excluded (e.g., smartphone, therapeutic goods, vehicle) or not acquired by a consumer, Schedule 1 does not apply. - Track Part 2 commencement and any future standards/exemptions made under the rules. - If you both manufacture and supply, map obligations for each role. ### [REPORT <=72H] Ransomware payment report required Give the report to the designated Commonwealth body (CSA s 27) - Report within 72 hours of making the payment or becoming aware it was made on your behalf. - Include required information (CSA s 27(2); Rules s 7) based on reasonable search/enquiry within the 72-hour window. - Civil penalty for failing to report: 60 penalty units (CSA s 27(5)). ### [VOLUNTARY] Voluntary information sharing available National Cyber Security Coordinator (Part 4) - Impacted entities (or others acting on their behalf) may provide information about significant incidents, or incidents that could reasonably be expected to be significant (CSA s 35(2)). - Information can be shared during the response, on your initiative or in response to a request (s 35(3)). - NCSC collection is authorised (including sensitive information) for Privacy Act purposes (note to s 35(2)). - If it's unclear whether an incident is a cyber security incident or significant, you can still share information for qualification/triage (s 36). - Protections on use/disclosure and admissibility apply (Div 3); this does not replace other obligations (s 44). ### [ACTION] Comply with the s 49 notice (document production) Civil penalty risk for non-compliance - Produce documents/copies within stated period (>=14 days) and manner (CSA s 49(2)). - Civil penalty for failing to comply: 60 penalty units (s 50), subject to prejudice exceptions. - Reasonable compensation may apply for making copies (s 49(4)). ### [MONITOR] Be ready to cooperate if approached CIRB reviews are not automatic - A review can be initiated via referral, but only after incident/response ends and Minister approves terms (s 46). - Requests under s 48 are voluntary; notices under s 49 are compulsory. - Maintain incident evidence and decision records in case of a review. ### [BASELINE] Operationalise the obligations Practical next steps across Parts 2-5 - If you sell covered connectable products into Australia: prepare statements and published disclosures before 4 Mar 2026. - If you are (or could become) a reporting business entity: add ransomware payment reporting (72-hour clock) to IR runbooks and vendor/insurer playbooks. - Maintain a parallel reporting matrix and do not treat Part 4 sharing as a substitute for other obligations (s 44). ## CSA 2024 Timeline | Date | Event | Reference | | --- | --- | --- | | 2024-11-29 | Cyber Security Act 2024 receives Royal Assent | Cyber Security Act 2024 (Cth) | | 2024-11-30 | Parts 1, 4, 6, 7 commence (day after Royal Assent) | CSA s 2(1) table | | 2025-05-29 | Parts 3 and 5 commence (backstop if no proclamation) | CSA s 2(1) table | | 2025-11-29 | Part 2 commences (backstop if no proclamation) | CSA s 2(1) table | | 2026-03-04 | Smart device security standard begins (Schedule 1 in force) | Smart Devices Rules 2025 commencement table | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2021-12-02 | SLACI Act 2021 commences (SOCI reforms - tranche 1) | SOCI Act Context | | | 2021-12-15 | SLACIP Bill exposure-draft consultation window | Policy & Consultation | | | 2022-02-04 | SLACIP Bill exposure-draft: final Town Hall held | Policy & Consultation | | | 2022-02-10 | SLACIP Bill introduced and referred to PJCIS | Legislative Process | | | 2022-03-25 | PJCIS advisory report published (SLACIP Bill) | Legislative Process | | | 2022-04-01 | SLACIP Act 2022 made (Federal Register date) | SOCI Act Context | | | 2022-04-02 | SLACIP Act 2022 comes into effect (SOCI reforms - tranche 2) | SOCI Act Context | | | 2022-04-08 | SOCI Application Rules (LIN 22/026) come into effect | SOCI Act Context | | | 2022-07-07 | Telecommunications assets: Cyber Reporting compliance date (Telecommunications Act context) | SOCI Act Context | | | 2022-09-09 | Protected Information guidance (consultation draft v1) | Guidance (Non-binding) | | | 2022-10-05 | RMP Rules consultation window (SOCI reforms) | Policy & Consultation | | | 2022-10-07 | Telecommunications assets: Register compliance date (Telecommunications Act context) | SOCI Act Context | | | 2022-11-03 | Draft Risk Management Program Guidance (consultation draft v2) | Guidance (Non-binding) | | | 2023-02-16 | CIRMP Rules (LIN 23/006) as made (F2023L00112) | SOCI Act Context | | | 2023-02-27 | Australian Cyber Security Strategy consultation window | Policy & Consultation | | | 2023-11-22 | Smart device standards: Impact Analysis published | Policy & Consultation | | | 2023-12-19 | Cyber Security legislative reforms consultation window | Policy & Consultation | | | 2024-10-09 | Minister's second reading speech (House of Representatives) | Legislative Process | | | 2024-11-25 | Minister's second reading speech (Senate) | Legislative Process | | | 2024-11-29 | Cyber Security Act 2024 receives Royal Assent | Cyber Security Act 2024 | | | 2024-11-30 | Act commences: Parts 1, 4, 6 and 7 | Commencement & Application | | | 2024-12-16 | Draft Cyber Security Act Rules consultation window | Policy & Consultation | | | 2025-02-27 | Cyber Security Act Rules are made (dated) | Subordinate Rules (2025) | | | 2025-03-03 | CIRB Rules registered (F2025L00277) | Subordinate Rules (2025) | | | 2025-03-03 | Ransomware Payment Reporting Rules registered (F2025L00278) | Subordinate Rules (2025) | | | 2025-03-04 | Smart Devices Rules registered; Part 1 commences (F2025L00276) | Subordinate Rules (2025) | | | 2025-03-27 | Smart device standards: Supplementary Explanatory Statement registered | Policy & Consultation | | | 2025-04-03 | CIRMP Rules: as-made version end date (superseded) | SOCI Act Context | | | 2025-04-04 | SOCI Application Rules: April 2025 compilation/version date | SOCI Act Context | | | 2025-05-29 | Act commences: Part 3 (ransomware payment reporting) (backstop date) | Commencement & Application | Part 3; s.27 | | 2025-05-29 | Ransomware Payment Reporting Rules commence (F2025L00278) (aligned to Part 3) | Commencement & Application | | | 2025-05-29 | Act commences: Part 5 (Cyber Incident Review Board) (backstop date) | Commencement & Application | | | 2025-05-29 | CIRB Rules commence (F2025L00277) (aligned to Part 5) | Commencement & Application | | | 2025-11-29 | Act commences: Part 2 (smart device security standards framework) (backstop date) | Commencement & Application | | | 2026-01-28 | Compiled Act: replaced authorised version registered | Cyber Security Act 2024 | | | 2026-03-04 | Smart Devices Rules substantive obligations commence (Part 2 and Schedule 1) | Commencement & Application | | | 2027-12-01 | Statutory review can begin (PJCIS) | Statutory Review | s.88 | **Event details:** - **2021-12-02 - SLACI Act 2021 commences (SOCI reforms - tranche 1)**: Home Affairs describes the Security Legislation Amendment (Critical Infrastructure) Act 2021 (SLACI Act) as the first tranche of reforms to the SOCI Act, commencing from 2 December 2021. - **2021-12-15 - SLACIP Bill exposure-draft consultation window**: Home Affairs records an exposure-draft consultation period for the SLACIP Bill and accompanying draft Explanatory Document running from 15 December 2021 until Tuesday 1 February 2022. - **2022-02-04 - SLACIP Bill exposure-draft: final Town Hall held**: Home Affairs notes a final Town Hall was held on 4 February 2022 following the closure of submissions on the SLACIP Bill exposure draft. - **2022-02-10 - SLACIP Bill introduced and referred to PJCIS**: Home Affairs records that the Minister for Home Affairs introduced the SLACIP Bill to Parliament and referred it to the Parliamentary Joint Committee on Intelligence and Security (PJCIS) on 10 February 2022. - **2022-03-25 - PJCIS advisory report published (SLACIP Bill)**: Home Affairs notes that the PJCIS published its advisory report on the SLACIP Bill on 25 March 2022. - **2022-04-01 - SLACIP Act 2022 made (Federal Register date)**: The Federal Register of Legislation entry for the Security Legislation Amendment (Critical Infrastructure Protection) Act 2022 (C2022A00033) shows a date of 1 April 2022 (as-made Act entry). - **2022-04-02 - SLACIP Act 2022 comes into effect (SOCI reforms - tranche 2)**: Home Affairs records that the Security Legislation Amendment (Critical Infrastructure Protection) Act 2022 (SLACIP Act) came into effect on 2 April 2022. - **2022-04-08 - SOCI Application Rules (LIN 22/026) come into effect**: Draft Risk Management Program Guidance states that the Security of Critical Infrastructure (Application) Rules (LIN 22/026) 2022 came into effect on 8 April 2022, outlining asset classes required to comply with Mandatory Cyber Incident Reporting and certain Register reporting requirements. - **2022-07-07 - Telecommunications assets: Cyber Reporting compliance date (Telecommunications Act context)**: Draft Risk Management Program Guidance notes that telecommunications assets comply with Cyber Reporting from 7 July 2022 under the Telecommunications Act 1997. - **2022-09-09 - Protected Information guidance (consultation draft v1)**: Protected Information Guidance Material for industry is marked as a consultation draft (v1) and states it is current "as at 9 September 2022". - **2022-10-05 - RMP Rules consultation window (SOCI reforms)**: Draft Risk Management Program Guidance states the consultation period for the draft risk management program (RMP) rules was 45 days, from 5 October 2022 to 18 November 2022. - **2022-10-07 - Telecommunications assets: Register compliance date (Telecommunications Act context)**: Draft Risk Management Program Guidance notes that telecommunications assets comply with the Register from 7 October 2022 under the Telecommunications Act 1997. - **2022-11-03 - Draft Risk Management Program Guidance (consultation draft v2)**: Draft Risk Management Program Guidance is marked as a consultation draft (v2) and states it is current "as at 03 November 2022". - **2023-02-16 - CIRMP Rules (LIN 23/006) as made (F2023L00112)**: Security of Critical Infrastructure (Critical infrastructure risk management program) Rules (LIN 23/006) 2023 appear on the Federal Register of Legislation as an as-made version dated 16 February 2023 (F2023L00112). - **2023-02-27 - Australian Cyber Security Strategy consultation window**: Smart Devices Rules Explanatory Statement references the Australian Government consultation on the 2023-2030 Australian Cyber Security Strategy running from 27 February 2023 to 15 April 2023. - **2023-11-22 - Smart device standards: Impact Analysis published**: Impact Analysis Addendum for smart device standards states that the Department of Home Affairs published an Impact Analysis on mandatory security standards and an industry-led voluntary cyber security labelling scheme on 22 November 2023. - **2023-12-19 - Cyber Security legislative reforms consultation window**: Smart Devices Rules Explanatory Statement records that, on 19 December 2023, the Minister released the "Australian Cyber Security Strategy: Cyber Security Legislative Reforms Consultation Paper" and that consultation remained open until 1 March 2024. - **2024-10-09 - Minister's second reading speech (House of Representatives)**: The Act records that the Minister's second reading speech was made in the House of Representatives on 9 October 2024. - **2024-11-25 - Minister's second reading speech (Senate)**: The Act records that the Minister's second reading speech was made in the Senate on 25 November 2024. - **2024-11-29 - Cyber Security Act 2024 receives Royal Assent**: Cyber Security Act 2024 (No. 98, 2024) receives Royal Assent on 29 November 2024. - **2024-11-30 - Act commences: Parts 1, 4, 6 and 7**: Commencement table: Part 1 (and provisions not otherwise covered), Part 4 (coordination of significant cyber security incidents), and Parts 6-7 (regulatory powers and miscellaneous) commence the day after Royal Assent (30 November 2024). - **2024-12-16 - Draft Cyber Security Act Rules consultation window**: Explanatory Statements record that the draft Rules package was published on the Department's website on 16 December 2024 and closed for submissions on 14 February 2025. - **2025-02-27 - Cyber Security Act Rules are made (dated)**: The three Cyber Security Act Rules instruments are dated 27 February 2025 (Smart Devices Rules; Cyber Incident Review Board Rules; Ransomware Payment Reporting Rules). Registration dates follow in early March 2025. - **2025-03-03 - CIRB Rules registered (F2025L00277)**: Cyber Security (Cyber Incident Review Board) Rules 2025 are registered on 3 March 2025. The instrument commences later of the day after registration and the commencement of Act Part 5. - **2025-03-03 - Ransomware Payment Reporting Rules registered (F2025L00278)**: Cyber Security (Ransomware Payment Reporting) Rules 2025 are registered on 3 March 2025. The instrument commences later of the day after registration and the commencement of Act Part 3. - **2025-03-04 - Smart Devices Rules registered; Part 1 commences (F2025L00276)**: Cyber Security (Security Standards for Smart Devices) Rules 2025 are registered on 4 March 2025. The commencement table provides that Part 1 commences on registration, while Part 2 and Schedule 1 have a delayed commencement (4 March 2026). - **2025-03-27 - Smart device standards: Supplementary Explanatory Statement registered**: The smart device standards Impact Analysis (Supplementary Explanatory Statement) is an authorised version registered on 27 March 2025 in connection with F2025L00276. - **2025-04-03 - CIRMP Rules: as-made version end date (superseded)**: The Federal Register of Legislation page for F2023L00112 shows the as-made version dated 16 February 2023 and indicates it is superseded, with the as-made version running until 3 April 2025. - **2025-04-04 - SOCI Application Rules: April 2025 compilation/version date**: The Federal Register metadata for the SOCI Application Rules references an April 2025 compilation (F2025C00404) and links to a 4 April 2025 version in the legislation history/amendment history. - **2025-05-29 - Act commences: Part 3 (ransomware payment reporting) (backstop date)**: Commencement table provides for commencement by proclamation, with an automatic commencement if not commenced within 6 months of Royal Assent. The published commencement table includes 29 May 2025 as the backstop date for Part 3. Part 3 imposes the 72-hour ransomware payment reporting obligation for reporting business entities; the 2025 Rules specify (among other details) the $3 million turnover threshold and report content requirements. - **2025-05-29 - Ransomware Payment Reporting Rules commence (F2025L00278) (aligned to Part 3)**: Commencement clause: the whole instrument commences later of the day after registration and the commencement of Act Part 3; the backstop commencement date for Part 3 is 29 May 2025. - **2025-05-29 - Act commences: Part 5 (Cyber Incident Review Board) (backstop date)**: Commencement table provides for commencement by proclamation, with an automatic commencement if not commenced within 6 months of Royal Assent. The published commencement table includes 29 May 2025 as the backstop date for Part 5. - **2025-05-29 - CIRB Rules commence (F2025L00277) (aligned to Part 5)**: Commencement clause: the whole instrument commences later of the day after registration and the commencement of Act Part 5; the backstop commencement date for Part 5 is 29 May 2025. - **2025-11-29 - Act commences: Part 2 (smart device security standards framework) (backstop date)**: Commencement table provides for commencement by proclamation, with an automatic commencement if not commenced within 12 months of Royal Assent. The published commencement table includes 29 November 2025 as the backstop date for Part 2 (security standards for smart devices). - **2026-01-28 - Compiled Act: replaced authorised version registered**: The Act text indicates a replaced authorised version was registered on 28 January 2026 (compiled version reference). - **2026-03-04 - Smart Devices Rules substantive obligations commence (Part 2 and Schedule 1)**: Commencement table: Part 2 and Schedule 1 of the Smart Devices Rules commence on 4 March 2026 (12-month delayed commencement). This is when the mandatory security standards, statement-of-compliance requirements (including 5-year retention period), and defined support-period rules take effect for covered products. - **2027-12-01 - Statutory review can begin (PJCIS)**: The Parliamentary Joint Committee on Intelligence and Security may review the operation, effectiveness and implications of the Act, so long as it begins the review as soon as practicable after 1 December 2027. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/australia-cyber-security-act --- --- title: "EU Cyber Resilience Act, CRA Compliance, CE Marking and Reporting" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act" author: "Sorena AI" description: "Practical Cyber Resilience Act guidance for products with digital elements: scope, Annex I requirements, support period, Article 14 reporting." published_at: "2026-03-04" updated_at: "2026-03-11" keywords: - "EU Cyber Resilience Act" - "CRA compliance" - "products with digital elements" - "CRA Article 14 reporting" - "CRA CE marking" - "CRA technical documentation" - "CRA Annex I requirements" - "CRA support period" - "CRA conformity assessment" - "Cyber Resilience Act" - "Article 14 reporting" - "CE marking" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Cyber Resilience Act, CRA Compliance, CE Marking and Reporting Practical Cyber Resilience Act guidance for products with digital elements: scope, Annex I requirements, support period, Article 14 reporting. ![Cyber Resilience Act artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-cra-timeline-small.jpg?v=cheatsheets%2Fprod) *Cyber Resilience Act* *Free Resource* ## Cyber Resilience Act Product Security, Reporting and CE Marking Use this CRA hub to decide scope, classify products, map Annex I requirements, design technical documentation, and stand up reporting and support period operations before the regulation fully applies. This resource is grounded in Regulation (EU) 2024/2847, the European Commission policy page, the January 2026 CRA FAQ, and the Commission's March 2026 draft guidance on scope, remote data processing, open source software, and support periods. It is practical guidance, not legal advice. [Get implementation support](/contact.md) ## What this CRA hub helps you decide - **Scope and exclusions**: Confirm whether you have a product with digital elements, whether remote data processing is in scope, and whether any Article 2 exclusion applies. - **Control and evidence model**: Translate Annex I, Annex II, Article 13, Article 14, Article 31, and Article 32 into owners, tests, records, and release gates. - **Timing and enforcement risk**: Sequence the 11 June 2026, 11 September 2026, and 11 December 2027 milestones so reporting, support, CE marking, and authority response are ready. By Sorena AI | Updated 2026-03 | Grounded in official sources ### Quick scan *Artifact* - **Core dates**: Entered into force on 10 December 2024. Draft Commission guidance was published for feedback on 3 March 2026. Reporting starts on 11 September 2026. Main application starts on 11 December 2027. - **Support period**: Manufacturers must set and disclose a support period of at least five years unless expected use is shorter, then keep handling vulnerabilities throughout that period. - **Conformity routes**: Default products can use internal control in many cases. Important and critical products may need Module B plus C or Module H, depending on category and standards coverage. Use the topic guides to turn the CRA from a legal requirement set into a portfolio level product security operating model. | Value | Metric | | --- | --- | | 1 | Hub | | 16 | Guides | | 2026 | Updated | | EU | Focus | **Key highlights:** Scope first | Map evidence | Prepare reporting ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. ## Key milestones for Cyber Resilience Act *Timeline* Use milestones to sequence governance, engineering controls, vulnerability handling, reporting readiness, and CE marking evidence work. ## How to operationalize Cyber Resilience Act *Decision Flow* Use the decision flow to convert scope, conformity route, and requirement questions into clear implementation actions. *Next step* ## Turn Cyber Resilience Act Product Security, Reporting and CE Marking into an operational assessment workflow Cyber Resilience Act Product Security, Reporting and CE Marking should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into Research Copilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from Cyber Resilience Act Product Security, Reporting and CE Marking and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for Cyber Resilience Act Product Security, Reporting and CE Marking. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs from the same artifact. - **Download decision flow**: Share the CRA logic with product and engineering leads. - **Download timeline**: Align dates across product, legal, and operations teams. - [Talk through Cyber Resilience Act Product Security, Reporting and CE Marking](/contact.md): Review your current process, evidence model, and next steps for Cyber Resilience Act Product Security, Reporting and CE Marking. ## Decision Steps ### STEP 1: Are you making available on the EU market a product with digital elements? *Reference: Art. 2(1); Art. 3(1)-(2),(21)-(22)* - CRA scope focuses on products with digital elements made available on the market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. - Product with digital elements includes software or hardware and its remote data processing solutions (and components placed separately). - Making available on the market means supply for distribution or use on the Union market in the course of a commercial activity (payment or free of charge). - **YES** Is the product excluded from the CRA scope? - **NO** Stop: CRA likely does not apply ### STEP 2: Is the product excluded from the CRA scope? *Reference: Art. 2(2)-(8)* - Excluded if covered by: Regulation (EU) 2017/745 (medical devices), Regulation (EU) 2017/746 (IVDs), or Regulation (EU) 2019/2144 (vehicles). - Excluded if certified under Regulation (EU) 2018/1139 (aviation) or if equipment falls under Directive 2014/90/EU (marine equipment). - Excluded for spare parts replacing identical components manufactured to the same specifications. - Excluded for products developed or modified exclusively for national security or defence purposes, or designed to process classified information. - **YES** Stop: CRA excluded for this product category - **NO** Are you the manufacturer for CRA purposes (or treated as one)? ### STEP 3: Are you the manufacturer for CRA purposes (or treated as one)? *Reference: Art. 3(13),(30); Art. 21; Art. 22* - Manufacturer includes anyone marketing the product under its name or trademark (payment, monetisation, or free of charge). - Importers or distributors are treated as manufacturers if they place a product on the market under their name/trademark or carry out a substantial modification (Art. 21). - Other persons carrying out a substantial modification and making the product available are treated as manufacturers, for the affected part or entire product (Art. 22). - **YES** Is the product a critical product category listed in Annex IV? - **NO** Are you an importer or distributor making the product available on the EU market? ### STEP 3B: Are you an importer or distributor making the product available on the EU market? *Reference: Art. 19-20; Art. 23* - If you import from outside the Union and place the product on the market in the Union, you are an importer. - If you make the product available in the supply chain without affecting its properties, you are a distributor. - Economic operators must be able to identify who supplied them and to whom they supplied (Art. 23). - **YES** Do you place it on the market under your name/trademark, or carry out a substantial modification? - **NO** Are you an open-source software steward for free and open-source software intended for commercial activities? ### STEP 3C: Do you place it on the market under your name/trademark, or carry out a substantial modification? *Reference: Art. 21; Art. 3(30)* - If yes, CRA treats the importer or distributor as a manufacturer and applies manufacturer obligations (Art. 21). - Substantial modification includes changes after placing on the market that affect compliance with Annex I Part I or change intended purpose. - **YES** Is the product a critical product category listed in Annex IV? - **NO** Importer and distributor obligations (CRA) ### STEP 3D: Are you an open-source software steward for free and open-source software intended for commercial activities? *Reference: Art. 3(14); Art. 24* - Open-source software steward is a legal person (other than a manufacturer) that provides sustained support to specific products with digital elements qualifying as free and open-source software and intended for commercial activities (Art. 3(14)). - **YES** Open-source software steward obligations (CRA) - **NO** No direct CRA economic-operator obligations from this flow ### STEP 4: Is the product a critical product category listed in Annex IV? *Reference: Art. 8(1); Art. 32(4)* - Critical products are product categories listed in Annex IV. - Annex IV categories can be required (via delegated acts) to obtain a European cybersecurity certificate if a relevant certification scheme exists and is available (Art. 8(1)). - **YES** Is a European cybersecurity certificate required for this Annex IV category (and is a scheme available)? - **NO** Is the product an important product category listed in Annex III? ### STEP 4A: Is a European cybersecurity certificate required for this Annex IV category (and is a scheme available)? *Reference: Art. 8(1); Art. 32(4)(a)-(b)* - CRA allows delegated acts to require certification for Annex IV categories where a European cybersecurity certification scheme covering the category exists and is available (Art. 8(1)). - If no such delegated act exists, Annex IV products are subject to the Art. 32(3) procedures (Art. 8(1), second subparagraph). - **YES** CRA compliance: critical product requiring European cybersecurity certification - **NO** CRA compliance: critical product conformity route (no certification requirement) ### STEP 4B: Is the product an important product category listed in Annex III? *Reference: Art. 7(1); Art. 32(2)-(3)* - Important products have the core functionality of a category set out in Annex III (Art. 7(1)). - Annex III categories are divided into class I and class II (Art. 7(2); Annex III). - **YES** Is it listed under Annex III class II? - **NO** CRA compliance: standard product conformity route ### STEP 4C: Is it listed under Annex III class II? *Reference: Art. 7(2); Art. 32(3)* - If yes, stricter conformity assessment routes apply (Module B + C, Module H, or an applicable certification scheme at assurance level at least 'substantial') (Art. 32(3)). - **YES** CRA compliance: important product (class II) conformity route - **NO** For Annex III class I, do harmonised standards/common specifications/certification schemes fully cover the essential requirements you rely on? ### STEP 4D: For Annex III class I, do harmonised standards/common specifications/certification schemes fully cover the essential requirements you rely on? *Reference: Art. 32(1)-(2)* - If you have not applied (or only partly applied) harmonised standards, common specifications, or certification schemes (assurance level at least 'substantial'), or they do not exist, then for those essential requirements you must use Module B + C or Module H (Art. 32(2)). - If they do exist and you apply them, you can demonstrate conformity using any of the Art. 32(1) procedures (including Module A), subject to product category rules. - **YES** CRA compliance: important product (class I) with full standards coverage - **NO** CRA compliance: important product (class I) requiring Module B + C or Module H ## Reference Information ### Key CRA Definitions (short list) ### Conformity assessment overview (CRA) ### Manufacturer obligations checklist (core) ### Support period and updates (CRA) ### Mandatory reporting (CRA) ## Possible Outcomes ### [OUT OF SCOPE] Stop: CRA likely does not apply Not made available on the EU market as a product with digital elements - If you are not making a product with digital elements available on the Union market in a commercial activity, the CRA obligations in this decision map are not triggered. - If you are still uncertain, validate against the definitions in Art. 3 and seek legal review. ### [EXCLUDED] Stop: CRA excluded for this product category Follow applicable sector rules and any other EU harmonisation legislation - CRA does not apply to the excluded categories listed in Art. 2(2)-(4), plus the specific exclusions in Art. 2(6)-(7). - For products covered by other Union rules that address all or some CRA risks, CRA application may be limited or excluded via delegated acts where sector rules achieve the same or higher protection (Art. 2(5)). ### [IMPORTER / DISTRIBUTOR] Importer and distributor obligations (CRA) Due care, verification, corrective actions, and traceability - Importers: place on the market only compliant products; before placing on the market, verify conformity assessment, technical documentation, CE marking, EU declaration of conformity, and required instructions; keep EU DoC available and ensure technical documentation can be made available for at least 10 years or the support period (whichever is longer) (Art. 19). - Importers: if non-conformity, take corrective measures (bring into conformity, withdraw, or recall) and inform authorities when there is a significant cybersecurity risk; inform the manufacturer without undue delay upon becoming aware of a vulnerability (Art. 19). - Distributors: act with due care; before making available, verify CE marking and that required documents were provided; do not make available if you believe there is non-conformity; cooperate and take corrective actions as needed (Art. 20). - Traceability: on request, provide information on who supplied you and (where available) to whom you supplied, and keep that information for 10 years (Art. 23). ### [OSS STEWARD] Open-source software steward obligations (CRA) Cybersecurity policy, cooperation, and (limited) reporting duties - Put in place and document a verifiable cybersecurity policy to foster secure development and effective vulnerability handling by developers, and foster voluntary reporting under Art. 15 (Art. 24(1)). - Cooperate with market surveillance authorities upon request to mitigate risks; provide the documented policy on request (Art. 24(2)). - Mandatory reporting: Art. 14(1) applies to the extent the steward is involved in development; Art. 14(3) and (8) apply to the extent severe incidents affect network and information systems provided by the steward for development (Art. 24(3)). ### [NO OPERATOR ROLE] No direct CRA economic-operator obligations from this flow You are not acting as a manufacturer, importer, distributor, or OSS steward - This decision map focuses on CRA obligations for economic operators (manufacturer, importer, distributor) and open-source software stewards. - If you are an end user or a downstream entity without those roles, CRA may not impose obligations on you through these articles, but other rules could still apply. ### [STANDARD] CRA compliance: standard product conformity route Not Annex III (important) and not Annex IV (critical) - Conformity assessment: demonstrate Annex I conformity using Module A, Module B + C, Module H, or (where available and applicable) a European cybersecurity certification scheme (Art. 32(1)). - Use the manufacturer checklist (Art. 13; Art. 31-32) and implement support-period and mandatory reporting processes (Art. 13(8)-(9); Art. 14-16). ### [ANNEX III CLASS I] CRA compliance: important product (class I) with full standards coverage Internal control is available when harmonised standards/common specs/cert schemes are fully applied - Conformity assessment: you can use any Art. 32(1) procedure (including Module A), provided the class I condition in Art. 32(2) is not triggered for any essential requirements you need to demonstrate. - Keep evidence of applied standards/specifications/schemes in your technical documentation (Art. 31; Annex VII). - Apply manufacturer, support-period, and reporting obligations (Art. 13; Art. 14-16). ### [ANNEX III CLASS I] CRA compliance: important product (class I) requiring Module B + C or Module H Triggered when standards/specifications/schemes are not applied (or do not exist) for essential requirements - Conformity assessment: for the essential requirements not covered by (or not applying) harmonised standards/common specs/cert schemes, use Module B + C or Module H (Art. 32(2)). - Document the scope of third-party assessment and keep technical documentation updated through the support period (Art. 31(2)). - Apply manufacturer, support-period, and reporting obligations (Art. 13; Art. 14-16). ### [ANNEX III CLASS II] CRA compliance: important product (class II) conformity route Third-party route required (or certification scheme) at assurance level at least 'substantial' - Conformity assessment: use Module B + C, Module H, or (where available and applicable) a European cybersecurity certification scheme at assurance level at least 'substantial' (Art. 32(3)). - Apply manufacturer, support-period, and reporting obligations (Art. 13; Art. 14-16). ### [ANNEX IV] CRA compliance: critical product requiring European cybersecurity certification Certification route applies when required by delegated act and a scheme is available - Conformity assessment: demonstrate Annex I conformity by obtaining a European cybersecurity certificate under a relevant scheme at assurance level at least 'substantial', when required under Art. 8(1) (Art. 32(4)(a)). - Apply manufacturer, support-period, and reporting obligations (Art. 13; Art. 14-16). ### [ANNEX IV] CRA compliance: critical product conformity route (no certification requirement) Use Art. 32(3) procedures when certification is not required or conditions are not met - If a delegated act requiring certification is not adopted, Annex IV products are subject to Art. 32(3) procedures (Art. 8(1), second subparagraph). - Conformity assessment: use Module B + C, Module H, or (where available and applicable) an applicable certification scheme at assurance level at least 'substantial' (Art. 32(4)(b) referring to Art. 32(3)). - Apply manufacturer, support-period, and reporting obligations (Art. 13; Art. 14-16). ## EU Cyber Resilience Act Timeline | Date | Event | Reference | | --- | --- | --- | | 2024-10-23 | Regulation adopted | Reg. (EU) 2024/2847 | | 2024-11-20 | Published in Official Journal (OJ L) | Reg. (EU) 2024/2847 | | 2024-12-10 | Entry into force (20 days after publication) | Art. 71(1) | | 2025-12-11 | Commission deadline for Annex III and Annex IV technical descriptions (implementing act) | Art. 7(4) | | 2025-12-11 | Commission deadline for delegated act on delaying dissemination grounds | Art. 14(9) | | 2026-06-11 | Chapter IV (notification of conformity assessment bodies) applies | Art. 71(2) | | 2026-09-11 | Mandatory reporting obligations apply | Art. 71(2); Art. 14 | | 2027-12-11 | CRA generally applies | Art. 71(2) | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2021-09-15 | CRA announced in State of the Union | Legislative History | SOTEU 2021 | | 2021-09-16 | Commission explainer on the CRA (quotes SOTEU speech) | Legislative History | | | 2022-03-16 | Public consultation | Legislative History | | | 2022-09-15 | Commission proposal published | Legislative History | COM(2022) 454 | | 2023-06-08 | Council general approach | Legislative History | | | 2023-07-19 | Council common position | Legislative History | | | 2023-07-19 | EP ITRE Committee adopts report | Legislative History | | | 2023-09-01 | Parliament enters interinstitutional negotiations | Legislative History | | | 2023-11-30 | Political agreement reached | Legislative History | | | 2023-12-01 | Parliament press release on political agreement | Legislative History | | | 2024-03-12 | Parliament plenary adoption | Legislative History | P9_TA(2024)0130 | | 2024-10-10 | Council formal adoption | Legislative History | | | 2024-10-23 | Act date | Official Publication | Reg. (EU) 2024/2847 | | 2024-11-20 | Published in Official Journal | Official Publication | OJ L 2024/2847 | | 2024-12-05 | Corrigendum: editorial title fix | Corrigendum | | | 2024-12-10 | Entry into force | Applicability | Art. 71(1) | | 2024-12-10 | Delegated powers conferred (5-year period begins) | Delegated & Implementing Acts | Art. 61(2) | | 2025-02-03 | Standardisation request M/606 adopted | Standardisation | C(2025) 618 | | 2025-04-03 | M/606 officially accepted by CEN-CENELEC | Standardisation | M/606 | | 2025-07-02 | Corrigendum: Art. 64(10) cross-reference | Corrigendum | Art. 64(10) | | 2025-07-29 | Delegated Reg. 2025/1535 adopted | Delegated & Implementing Acts | Reg. (EU) 2025/1535 | | 2025-10-03 | Corrigendum: Annex I language fix | Corrigendum | Annex I | | 2025-10-17 | Corrigendum: Art. 67 numbering | Corrigendum | Art. 67 | | 2025-10-29 | Delegated Reg. 2025/1535 published in OJ | Delegated & Implementing Acts | OJ L 2025/1535 | | 2025-11-18 | Delegated Reg. 2025/1535 enters into force | Delegated & Implementing Acts | Reg. (EU) 2025/1535 | | 2025-11-28 | Implementing Reg. 2025/2392 adopted | Delegated & Implementing Acts | Reg. (EU) 2025/2392 | | 2025-12-01 | Implementing Reg. 2025/2392 published in OJ | Delegated & Implementing Acts | OJ L 2025/2392 | | 2025-12-11 | Delegated act on CSIRT notification delays | Delegated & Implementing Acts | Art. 16(2) | | 2025-12-11 | Delegated act record published on EUR-Lex | Delegated & Implementing Acts | C(2025) 8407 | | 2025-12-21 | Implementing Reg. 2025/2392 enters into force | Delegated & Implementing Acts | Reg. (EU) 2025/2392 | | 2026-03-03 | Draft CRA guidance published for feedback | Commission Deliverables | | | 2026-03-31 | Feedback closes on draft CRA guidance | Commission Deliverables | | | 2026-06-11 | Chapter IV applies: notified bodies | Conformity Assessment | Art. 35-51 | | 2026-06-11 | Notified bodies listed on NANDO/SMCS (as they are designated) | Conformity Assessment | | | 2026-09-11 | Vulnerability reporting obligations apply | Vulnerability Reporting | Art. 14 | | 2026-09-11 | CRA reporting deadlines (24h / 72h / 14d / 1 month) | Vulnerability Reporting | | | 2026-09-11 | Open-source software stewards: reporting obligations apply (conditional) | Vulnerability Reporting | Art. 24(3), Art. 14 | | 2026-09-11 | Single Reporting Platform operational by this date | Commission Deliverables | | | 2027-12-11 | CRA applies in full | Applicability | Art. 71(2) | | 2027-12-11 | Legacy products: substantial modification rule | Applicability | | | 2027-12-11 | Economic operators obligations apply (importers, distributors, authorised representatives) | Applicability | Arts. 18-21 | | 2027-12-11 | Open-source software stewards: Article 24 obligations apply | Applicability | Art. 24(1)-(2) | | 2029-12-10 | End of initial 5-year delegation period (unless extended) | Delegated & Implementing Acts | Art. 61(2) | **Event details:** - **2021-09-15 - CRA announced in State of the Union**: President von der Leyen announces the CRA in the State of the Union address: 'including legislation on common standards under a new European Cyber Resilience Act.' - **2021-09-16 - Commission explainer on the CRA (quotes SOTEU speech)**: Commission explainer page published the day after SOTEU highlights the CRA and quotes the speech's CRA passage. - **2022-03-16 - Public consultation**: Commission launches CRA public consultation, open 16 March to 25 May 2022. - **2022-09-15 - Commission proposal published**: Commission presents the CRA proposal COM(2022) 454 final. - **2023-06-08 - Council general approach**: Council reaches its 'general approach' (negotiating mandate) on the CRA at the JHA Council meeting. - **2023-07-19 - Council common position**: Member States agree a common position on security requirements for digital products. - **2023-07-19 - EP ITRE Committee adopts report**: EP ITRE Committee adopts its report/position on the CRA. - **2023-09-01 - Parliament enters interinstitutional negotiations**: Parliament confirms its committee decision to enter interinstitutional (trilogue) negotiations in September 2023. - **2023-11-30 - Political agreement reached**: Council and Parliament reach provisional political agreement on the CRA. - **2023-12-01 - Parliament press release on political agreement**: European Parliament press release on the agreement reached with the Council to boost digital products security. - **2024-03-12 - Parliament plenary adoption**: European Parliament adopts the CRA in plenary: 517 in favour, 12 against, 78 abstentions. - **2024-10-10 - Council formal adoption**: Council formally adopts the Cyber Resilience Act. - **2024-10-23 - Act date**: Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 (Cyber Resilience Act) is signed. - **2024-11-20 - Published in Official Journal**: CRA published in the Official Journal of the European Union (OJ L 2024/2847, 20.11.2024). - **2024-12-05 - Corrigendum: editorial title fix**: First corrigendum: corrects '(EU) No 2019/1020' to '(EU) 2019/1020' in the regulation title. - **2024-12-10 - Entry into force**: CRA enters into force on the 20th day following OJ publication (20 Nov + 20 days = 10 Dec 2024). - **2024-12-10 - Delegated powers conferred (5-year period begins)**: Delegation of power to the Commission is conferred for a period of five years from 10 December 2024, with tacit extensions unless opposed. - **2025-02-03 - Standardisation request M/606 adopted**: Commission adopts CRA standardisation request M/606 containing 41 standards. Accepted by CEN, CENELEC, and ETSI on 3 April 2025. - **2025-04-03 - M/606 officially accepted by CEN-CENELEC**: CEN-CENELEC officially accepted the CRA standardisation request on 3 April 2025. - **2025-07-02 - Corrigendum: Art. 64(10) cross-reference**: Corrigendum fixes Article 64(10): 'paragraphs 3 to 9' corrected to 'paragraphs 2 to 9'. - **2025-07-29 - Delegated Reg. 2025/1535 adopted**: Commission excludes most L-category vehicle products from CRA scope (exception for L1e pedal-designed). OJ publication 29 Oct 2025; enters into force 20 days later. - **2025-10-03 - Corrigendum: Annex I language fix**: Corrigendum fixes FR/HU language wording in Annex I, Part I, paragraph 2, point (c). - **2025-10-17 - Corrigendum: Art. 67 numbering**: Corrigendum fixes numbering reference in Article 67: '69' corrected to '72'. - **2025-10-29 - Delegated Reg. 2025/1535 published in OJ**: Delegated Regulation (EU) 2025/1535 is published in the Official Journal on 29 October 2025. - **2025-11-18 - Delegated Reg. 2025/1535 enters into force**: Delegated Regulation (EU) 2025/1535 enters into force on the twentieth day following its OJ publication. - **2025-11-28 - Implementing Reg. 2025/2392 adopted**: Commission adopts technical descriptions for Annex III/IV product categories (important and critical products). OJ publication 1 Dec 2025; enters into force 20 days later. - **2025-12-01 - Implementing Reg. 2025/2392 published in OJ**: Implementing Regulation (EU) 2025/2392 is published in the Official Journal on 1 December 2025. - **2025-12-11 - Delegated act on CSIRT notification delays**: Commission adopts delegated act specifying terms and conditions for delaying dissemination of vulnerability notifications by CSIRTs under Article 16(2). - **2025-12-11 - Delegated act record published on EUR-Lex**: EUR-Lex record for the Commission delegated act concerning Article 16(2) conditions for CSIRTs delaying dissemination to other CSIRTs. - **2025-12-21 - Implementing Reg. 2025/2392 enters into force**: Implementing Regulation (EU) 2025/2392 enters into force on the twentieth day following its OJ publication. - **2026-03-03 - Draft CRA guidance published for feedback**: Commission publishes draft CRA guidance for stakeholder feedback, clarifying scope, remote data processing, free and open-source software, support periods, and interplay with other EU law. - **2026-03-31 - Feedback closes on draft CRA guidance**: The stakeholder feedback period on the Commission's draft CRA guidance closes on 31 March 2026. - **2026-06-11 - Chapter IV applies: notified bodies**: CRA Chapter IV (Articles 35-51) on notification of conformity assessment bodies begins to apply. - **2026-06-11 - Notified bodies listed on NANDO/SMCS (as they are designated)**: From the Chapter IV applicability date, conformity assessment bodies can be notified under the CRA framework and, once notified, will appear in the Commission's NANDO/SMCS notified bodies list for the CRA. - **2026-09-11 - Vulnerability reporting obligations apply**: Article 14 (vulnerability and incident reporting) applies. Manufacturers must report actively exploited vulnerabilities and severe incidents via ENISA's Single Reporting Platform. - **2026-09-11 - CRA reporting deadlines (24h / 72h / 14d / 1 month)**: From the Article 14 applicability date, incident/vulnerability notifications follow operational time limits (early warning within 24 hours of awareness; full notification within 72 hours; final report timelines depending on case, such as 14 days or 1 month). - **2026-09-11 - Open-source software stewards: reporting obligations apply (conditional)**: Open-source software stewards are subject to Article 14(1) (and, where applicable, Article 14(3) and (8)) to the extent they are involved in development, from the date Article 14 applies. - **2026-09-11 - Single Reporting Platform operational by this date**: Commission states ENISA's Single Reporting Platform (SRP) will be operational by 11 September 2026 to support CRA vulnerability and incident reporting. - **2027-12-11 - CRA applies in full**: General application date: the CRA applies in full from 11 December 2027. - **2027-12-11 - Legacy products: substantial modification rule**: Products placed on the EU market before 11 December 2027 are subject to CRA product requirements only if, from that date, they undergo a substantial modification; reporting obligations still apply from the earlier reporting applicability date. - **2027-12-11 - Economic operators obligations apply (importers, distributors, authorised representatives)**: From the general CRA application date, authorised representatives, importers, and distributors must comply with their CRA obligations; in certain cases (e.g., own-branding or substantial modification) importers/distributors are treated as manufacturers. - **2027-12-11 - Open-source software stewards: Article 24 obligations apply**: Open-source software stewards must have a verifiable cybersecurity policy for secure development and vulnerability handling, and cooperate with market surveillance authorities (subject to CRA scope). - **2029-12-10 - End of initial 5-year delegation period (unless extended)**: The initial five-year period for the Commission's delegated powers runs until 10 December 2029, subject to tacit extensions unless opposed. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act --- --- title: "EU Digital Product Passport (DPP) Timeline and Compliance Decision Flow" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport" author: "Sorena AI" description: "A practical EU Digital Product Passport (DPP) artifact grounded in ESPR (Regulation (EU) 2024/1781): key milestones, current implementation status." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "EU Digital Product Passport" - "Digital Product Passport DPP" - "ESPR" - "Ecodesign for Sustainable Products Regulation" - "Regulation (EU) 2024/1781" - "digital product passport requirements" - "DPP data carrier" - "DPP QR code" - "unique product identifier" - "DPP registry" - "DPP web portal" - "customs checks" - "DPP compliance checklist" - "DPP implementation guide" - "DPP architecture" - "DPP data requirements" - "DPP access control" - "Digital Product Passport" - "Traceability" - "Compliance" - "QR code" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Digital Product Passport (DPP) Timeline and Compliance Decision Flow A practical EU Digital Product Passport (DPP) artifact grounded in ESPR (Regulation (EU) 2024/1781): key milestones, current implementation status. ![EU Digital Product Passport (DPP) artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-espr-dpp-timeline-small.jpg?v=cheatsheets%2Fprod) *Digital Product Passport* *Free Resource* ## EU Digital Product Passport Timeline and Decision Flow Use this artifact to scope DPP applicability and responsibilities, then convert ESPR (Regulation (EU) 2024/1781) requirements into a shipped implementation: data carriers (QR/ID), unique identifiers, open standards, access control, registry and customs readiness. The first ESPR working plan was released in April 2025 and the EU registry deadline is 19 July 2026. This is a practical implementation resource, not legal advice. DPP obligations are product-group specific and are defined in delegated acts adopted under ESPR Article 4. Always validate final decisions against primary sources and your product scope. [Get implementation support](/contact.md) ## What you can decide faster - **Applicability**: Is your product group covered by a delegated act, and at what level (model/batch/item)? - **Data + IDs**: What data fields are required (Annex III) and what identifiers/data carriers you need. - **Architecture**: How to implement open standards, access control, registry integration and audit evidence. By Sorena AI | Updated Mar 2026 | No signup required ### Quick scan *DPP* - **Timeline view**: Track the April 2025 working-plan rollout and the July 2026 registry deadline. - **Decision flow**: Scope roles, obligations and technical requirements. - **Topic guides**: Deep dives: requirements, data, carriers, architecture, audit. Use the artifact + topic guides to build an audit-ready DPP implementation that avoids vendor lock-in, aligns to the current ESPR rollout, and supports customs and market-surveillance needs. | Value | Metric | | --- | --- | | ESPR | Legal basis | | 9-15 | Core DPP articles | | Annex III | Data fields | | Registry | EU system | **Key highlights:** Scope first | Data carrier (QR/ID) | Unique identifiers | Open standards | Access control | Audit evidence ## Topic Guides - [DPP Applicability Test (ESPR Scoping) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/applicability-test.md): A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act. - [DPP Architecture & Integration (Open Standards, Registry, APIs) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/architecture-and-integration.md): An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers. - [DPP Data Carriers, Access Control & UX | QR Code, Identifier, Public vs Restricted Views](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers. - [DPP Data Governance RACI Template | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field. - [DPP Data Requirements & Fields (Annex III) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III). - [DPP Governance, Verification & Audit Readiness | EU Digital Product Passport](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9). - [DPP Implementation Playbook & Vendor Selection | EU Digital Product Passport](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers. - [DPP QR Code Implementation Guide | Data Carrier + Identifier Design](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10). - [DPP vs Traditional Product Passports (Labels, PDFs, EPREL) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals. - [ESPR / DPP Penalties & Fines | EU Digital Product Passport Enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective. - [EU Digital Product Passport (DPP) Checklist | Audit-Ready Implementation Steps](/artifacts/eu/digital-product-passport/checklist.md): An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID). - [EU Digital Product Passport (DPP) Compliance Guide | Implementation Playbook](/artifacts/eu/digital-product-passport/compliance.md): A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements. - [EU Digital Product Passport (DPP) Deadlines & Compliance Calendar | ESPR 2024/1781](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024). - [EU Digital Product Passport (DPP) FAQ | ESPR 2024/1781](/artifacts/eu/digital-product-passport/faq.md): Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III). - [EU Digital Product Passport (DPP) Requirements | ESPR Articles 9-15 + Annex III](/artifacts/eu/digital-product-passport/requirements.md): A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9). - [What Is a Digital Product Passport (DPP)? | EU ESPR 2024/1781](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III). ## Key milestones for Digital Product Passport *Timeline* Use timeline milestones to sequence policy, engineering, supplier onboarding, registry readiness, and assurance work. ## How to operationalize Digital Product Passport *Decision Flow* Use the decision flow to turn applicability and requirement questions into clear actions, owners and evidence deliverables. *Next step* ## Turn EU Digital Product Passport Timeline and Decision Flow into an ESG delivery workflow EU Digital Product Passport Timeline and Decision Flow should be the shared entry point for your team. Route execution into ESG Compliance for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU Digital Product Passport Timeline and Decision Flow and route the work by entity, product, team, or control owner. - Use ESG Compliance to manage cross team sustainability work, reporting, and evidence from one workflow. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open ESG Compliance](/solutions/esg-compliance.md): Manage cross team sustainability work, reporting, and evidence from one workflow for EU Digital Product Passport Timeline and Decision Flow. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share scope logic internally. - **Download timeline**: Coordinate milestones across teams. - [Talk through EU Digital Product Passport Timeline and Decision Flow](/contact.md): Review your current process, evidence model, and next steps for EU Digital Product Passport Timeline and Decision Flow. ## Decision Steps ### STEP 1: Are you placing a physical product on the EU market? *Reference: Art. 1(1), Art. 1(2), Art. 4* - ESPR applies to physical goods placed on the EU market or put into service, including components and intermediate products. - Some product categories are excluded (for example, food and feed, medicinal products, living organisms, products of human origin, and certain vehicles for aspects already addressed by sector-specific Union law). - If yes, continue to check whether your product is excluded. If no, ESPR does not apply to that product placement. - **NO** Out of Scope - **YES** Is your product excluded from ESPR scope? ### STEP 2: Is your product excluded from ESPR scope? *Reference: Art. 1(2)* - Check if your product is food/feed, medicinal product, living organism, or a vehicle for which sector-specific EU law already sets requirements. - If yes, ESPR does not apply. - If no, continue to check if a product-specific delegated act has been adopted. - **YES** Out of Scope - **NO** Has a delegated act setting ecodesign requirements been adopted for your product group? ### STEP 3: Has a delegated act setting ecodesign requirements been adopted for your product group? *Reference: Art. 4, Art. 18(3)* - The Commission sets ecodesign requirements by delegated acts for specific product groups (or horizontally for product groups with similar characteristics). - The delegated act will specify the requirements, dates of application, and (where relevant) conformity assessment, markings, and information tools like the DPP and labels. - If yes, your product must comply with the delegated act. If no, ESPR product-specific requirements are not yet in force for that product group, but some general obligations may still apply (for example, rules on unsold consumer products). - **YES** Ecodesign requirements apply to your product - **NO** General ESPR obligations apply even without delegated act ### TRACK 1: Ecodesign requirements apply to your product *Reference: Art. 4, Art. 5(8), Art. 6, Art. 7* - Your product must comply with the performance requirements and information requirements set out in the delegated act, where relevant to your product group. - The delegated act will also specify how compliance is assessed (conformity assessment procedure) and how conformity is indicated (CE marking or alternative conformity marking). - Economic operator obligations apply based on your role (manufacturer, importer, distributor, dealer, etc.). - -> What is your role as an economic operator? ### STEP 5: What is your role as an economic operator? - Manufacturer (and in some cases importers or distributors are treated as manufacturers). - Authorised representative (appointed by a manufacturer via written mandate). - Importer (placing product from a third country on the EU market for the first time). - Distributor (making a product available on the market after it has been placed by manufacturer or importer). - Dealer (offering product for sale, hire or hire purchase, or displaying to customers/installers). - Fulfilment service provider (warehousing, packaging, addressing, dispatching). - Provider of an online marketplace (and in-scope online search engine obligations). - Each role has specific obligations. - -> Does the delegated act require a Digital Product Passport (DPP)? ### STEP 6: Does the delegated act require a Digital Product Passport (DPP)? *Reference: Art. 9, Art. 10, Art. 11* - If a DPP is required, the product can only be placed on the market or put into service if a DPP is available in accordance with the delegated act and the essential requirements in the Regulation. - The delegated act will specify the DPP data, data carrier(s), accessibility before purchase (including distance selling), access rights, and who can create or update the passport. - Some product groups can be exempted from the DPP requirement where technical specifications are not available or where another Union law provides a comparable digital information system. - **YES** Does the delegated act require product labels? - **NO** Does the delegated act require product labels? ### STEP 7: Does the delegated act require product labels? *Reference: Art. 16, Art. 32* - Where information requirements indicate that information is to be included in a label, the delegated act will specify label content, layout and display requirements (including distance selling). - If labels are required, economic operators must provide labels and dealers must display them as required by the delegated act. - **YES** Does the delegated act set performance requirements? - **NO** Does the delegated act set performance requirements? ### STEP 8: Does the delegated act set performance requirements? *Reference: Art. 5, Art. 6* - Performance requirements set minimum or maximum levels for one or more product parameters in Annex I, to improve relevant product aspects. - If yes, ensure the product meets the performance requirements before placing it on the market or putting it into service. - **YES** Does the delegated act set information requirements? - **NO** Does the delegated act set information requirements? ### STEP 9: Does the delegated act set information requirements? *Reference: Art. 7* - Information requirements specify product information to be made available (e.g., environmental footprint, durability, repair instructions). - Information can be provided via DPP, label, product manual, website, or other means as specified in delegated act. - If yes, ensure required information is made available in the specified manner. - **YES** What conformity assessment procedure applies? - **NO** What conformity assessment procedure applies? ### STEP 10: What conformity assessment procedure applies? *Reference: Art. 4(5), Art. 43* - Conformity assessment procedures range from internal production control (Module A) to more stringent modules involving notified bodies. - The delegated act specifies the applicable conformity assessment module for the product group. - Some modules involve notified bodies, depending on the module specified in the delegated act. - -> ESPR Ecodesign Requirements Apply (Full Compliance) ### TRACK 2: General ESPR obligations apply even without delegated act *Reference: Art. 23, Art. 24, Art. 25* - If no delegated act applies to your product group, ESPR product-specific ecodesign requirements are not yet in force for that product group. - However, Chapter VI sets rules on preventing and (for certain products) prohibiting the destruction of unsold consumer products, and on disclosing information about discarded unsold consumer products. - -> Does the destruction ban apply to your product? ### STEP 11: Does the destruction ban apply to your product? *Reference: Art. 23, Art. 24, Art. 25, Annex VII* - If you discard unsold consumer products (directly or via a third party), you may have a disclosure obligation. - From 19 July 2026, destruction of unsold consumer products listed in Annex VII is prohibited (subject to exemptions). - Micro and small enterprises are exempt from the prohibition, and the prohibition applies to medium-sized enterprises from 19 July 2030. - **YES** General ESPR Obligations Apply - **NO** General ESPR Obligations Apply ## Reference Information ### Products In Scope (Overview) - ESPR sets a framework for ecodesign requirements for physical products placed on the EU market or put into service, including components and intermediate products. - Product-specific requirements apply only when the Commission adopts a delegated act for a product group (and the delegated act will set dates of application). - Ecodesign requirements can include performance requirements and information requirements. - Information requirements can be delivered through tools like the digital product passport and (where applicable) labels. ### Key Exclusions - Food and feed as defined in Regulation (EC) No 178/2002. - Medicinal products (Directive 2001/83/EC) and veterinary medicinal products (Regulation (EU) 2019/6). - Living plants, animals and micro-organisms; products of human origin; products of plants and animals relating directly to their future reproduction. - Vehicles (Regulations (EU) No 167/2013, No 168/2013, 2018/858) for aspects already addressed by sector-specific Union law. ### Authorised Representative Obligations - A manufacturer may appoint an authorised representative by written mandate (Art. 28(1)). - The mandate cannot cover the manufacturer's obligations in Art. 27(1) or the drawing up of technical documentation (Art. 28(1)). - Keep the EU declaration of conformity and technical documentation available to market surveillance authorities for 10 years (unless a delegated act sets a different period) (Art. 28(2)(a)). - Cooperate with competent national authorities and provide information and documentation within 15 days upon a reasoned request (Art. 28(2)(b)-(c)). - Terminate the mandate if the manufacturer acts contrary to its obligations (Art. 28(2)(d)). ### Manufacturer Obligations - For products covered by a delegated act: ensure the product is designed and manufactured in accordance with performance requirements and accompanied by required information (Art. 27(1)(a)-(b)). - Ensure a digital product passport is available where required, including a back-up copy via a digital product passport service provider (Art. 27(1)(c), Art. 10(4)). - Carry out the conformity assessment procedure specified in the delegated act and draw up technical documentation (Art. 27(2)). - Draw up the EU declaration of conformity and affix the CE marking (or the alternative conformity marking specified in the delegated act, if applicable) (Art. 27(2), Art. 44, Art. 46, Art. 4(6)(d)). - Keep technical documentation and the EU declaration of conformity for 10 years (unless the delegated act specifies a different period) (Art. 27(3)). - Ensure products bear an identifier (type, batch, serial number, or equivalent) (Art. 27(5)). - Provide manufacturer name and contact details on the product/packaging and, where applicable, on the public part of the DPP (Art. 27(6)). - Provide digital instructions (plus paper safety information) and keep digital instructions accessible online for at least 10 years (Art. 27(7)). - If you believe a product is non-compliant, take corrective action (including withdrawal/recall where appropriate) and inform market surveillance authorities (Art. 27(8)). ### Importer Obligations - For products covered by a delegated act: place on the market only products that comply with the applicable delegated act (Art. 29(1)). - Before placing a product on the market: ensure conformity assessment and technical documentation are done, required information is provided, and a DPP is available where required (Art. 29(2)(a)-(c)). - Ensure the product bears the CE marking (where applicable) or the alternative conformity marking specified in the delegated act, and the manufacturer has complied with identification and contact details requirements (Art. 29(2), Art. 45, Art. 46, Art. 27(5)-(6)). - Provide importer name and contact details on the product/packaging and, where applicable, on the public part of the DPP (Art. 29(3)). - Ensure digital instructions accompany the product (Art. 29(4)). - Ensure storage and transport conditions do not jeopardise compliance (Art. 29(5)). - If you believe a product is non-compliant, take corrective action (including withdrawal/recall where appropriate) and inform market surveillance authorities (Art. 29(6)). - Keep a copy of the EU declaration of conformity and ensure technical documentation can be made available for 10 years (unless the delegated act specifies a different period) (Art. 29(7)). - Provide information and documentation on request within 15 days and cooperate with authorities (Art. 29(8)). ### Distributor Obligations - For products covered by a delegated act: act with due care in relation to the requirements in the applicable delegated acts (Art. 30(1)). - Before making a product available: verify CE marking (or alternative conformity marking), and where relevant that the product is labelled or linked to a DPP, and that required documents and digital instructions are provided (Art. 30(2)). - Verify that the manufacturer and importer have complied with required identification and contact details obligations (Art. 30(2)(c), Art. 27(5)-(6), Art. 29(3)). - If you believe a product is not in conformity, do not make it available until it is brought into conformity (Art. 30(3)). - Ensure storage and transport conditions do not jeopardise compliance (Art. 30(3)). - If you believe a product you made available is non-compliant, ensure corrective action is taken (withdraw/recall where appropriate) and inform market surveillance authorities (Art. 30(4)). - Provide information and documentation on request within 15 days and cooperate with authorities (Art. 30(5)). ### Dealer Obligations - Ensure customers and potential customers can access the information required by the delegated act, including in the event of distance selling (Art. 31(1)). - Where a DPP is required, ensure it is easily accessible for customers and potential customers, including in the event of distance selling (Art. 31(2), Art. 9(2)(e)). - Where labels are required: display labels visibly, reference label information in visual advertisements and technical promotional material, and do not display other labels/marks that mislead or confuse customers (Art. 31(3)). ### Fulfilment Service Provider Obligations - For products covered by a delegated act that you handle: ensure that conditions during warehousing, packaging, addressing or dispatching do not jeopardise compliance with that delegated act (Art. 33). - In some cases of non-compliance, fulfilment service providers can be liable for consumer damage (Art. 76(c)). ### Online Marketplace Provider Obligations - General obligations under Regulation (EU) 2022/2065 apply for the purposes of ESPR (Art. 35(1)). - Cooperate with market surveillance authorities, at their request and in specific cases, to eliminate or mitigate the non-compliance of products offered online through your services (Art. 35(1)). - Market surveillance authorities can order removal of content referring to non-compliant products offered for sale online (Art. 35(2)). - Establish a single contact point for direct communication with market surveillance authorities (Art. 35(3)). ### Distance Selling: Product Offer Information - When selling a product covered by a delegated act through distance selling, ensure the product offer clearly and visibly includes manufacturer identity and contact details (Art. 36(1)(a)). - If the manufacturer is not established in the Union, include the EU-based economic operator required under Regulation (EU) 2019/1020 (Art. 36(1)(b)). - Include product identification information, including a picture, type, and other product identifier (Art. 36(1)(c)). - Maintain supply chain traceability information (who supplied you; who you supplied; quantities and exact models) for 10 years and provide it within 15 days upon request (Art. 36(2)). ### Digital Product Passport (DPP) Requirements - If a DPP is required, the product can only be placed on the market or put into service if a DPP is available; DPP data must be accurate, complete and up to date (Art. 9(1)). - The delegated act will specify DPP content and operational requirements (data carriers, layout/positioning, level, accessibility before purchase, access rights, who can create/update data, and availability period) (Art. 9(2)). - The DPP must comply with essential requirements, including a data carrier connected to a persistent unique product identifier; interoperable/open standards; machine-readable, structured and searchable data; and no customer personal data without explicit consent (Art. 10(1)). - The economic operator placing the product on the market must provide dealers and providers of online marketplaces with a digital copy of the data carrier or unique product identifier (or a link) and, upon request, do so within 5 working days (Art. 10(3)). - The economic operator must make a back-up copy of the DPP available through a digital product passport service provider (Art. 10(4)). - Technical design and operation requirements include interoperability, access by stakeholders based on rights, integrity/security, and availability for the period set in the delegated act (Art. 11). - The Commission must set up a DPP registry by 19 July 2026, and the economic operator placing the product on the market uploads required data to the registry (Art. 13(1), Art. 13(4)). ### Label Requirements - Where a delegated act requires a label under Art. 16, the delegated act will specify label content, layout, and how it must be displayed to customers (including distance selling) (Art. 16(1)). - Labels can include data carriers or other means to allow customers to access additional information, including access to the DPP where appropriate (Art. 16(4)). - If a delegated act requires a label, economic operators placing products on the market must ensure each unit is accompanied by printed labels, provide labels to dealers within 5 working days upon request, and keep technical documentation to support label accuracy (Art. 32(1)). - Dealers must display labels and reference label information in advertisements and promotional material, and must not display other labels/marks that mislead or confuse customers about the ESPR label information (Art. 31(3), Art. 32(2)). - Products with labels that mislead or confuse customers by mimicking ESPR labels must not be placed on the market or put into service (Art. 17). ### Performance Requirements (Examples) - Performance requirements aim to improve relevant product aspects such as durability, reliability, reusability, upgradability, repairability, and maintenance/refurbishment (Art. 5(1)(a)-(f)). - They can address substances of concern, energy and water use, resource use, recycled content, remanufacturing, recyclability and material recovery (Art. 5(1)(g)-(n)). - They can address environmental impacts, including carbon footprint and environmental footprint, and expected generation of waste (Art. 5(1)(o)-(p)). - Delegated acts can also include measures to prevent premature obsolescence (Art. 5(2)). ### Information Requirements (Examples) - Information requirements can include information on product performance (for example, repairability score, durability score, carbon footprint or environmental footprint) (Art. 7(2)(b)(i)). - They can include customer and other actor information on installation, use, maintenance and repair, and end-of-life handling (Art. 7(2)(b)(ii)-(iv)). - Where appropriate, the Commission can determine classes of performance to help customers compare products (Art. 7(4)). - Information requirements must enable tracking substances of concern throughout the product life cycle, subject to thresholds and exemptions set in delegated acts (Art. 7(5)-(6)). - Required information is made available in the manner specified by the delegated act; where a DPP is available, required information is provided in the DPP and may also be provided via product, packaging, label, documentation, or a free access website/app (Art. 7(7)). ### Conformity Assessment and CE Marking - For products covered by a delegated act, the manufacturer must carry out the conformity assessment procedure specified in that delegated act and draw up technical documentation (Art. 27(2)). - The manufacturer draws up an EU declaration of conformity (Art. 44) and affixes the CE marking (Art. 46), unless the delegated act specifies an alternative conformity marking (Art. 4(6)(d)). - Conformity assessment modules are selected from Annex IV (Module A) or modules in Decision No 768/2008/EC, as specified in delegated acts (Art. 4(5)). - Tests, measurements and calculations for compliance use harmonised standards or other reliable methods specified in delegated acts (Art. 39), and harmonised standards can provide presumption of conformity (Art. 41). - Keep technical documentation and the EU declaration of conformity for 10 years (unless the delegated act specifies a different period) (Art. 27(3), Art. 29(7)). ### Destruction of Unsold Products: Ban and Disclosure - Economic operators must take reasonable measures to prevent the need to destroy unsold consumer products (Art. 23). - Economic operators that discard unsold consumer products (directly or via a third party) must disclose annual information on their website (number/weight, reasons, treatment route proportions, and measures taken/planned) (Art. 24(1)). - The disclosure obligation does not apply to micro and small enterprises and applies to medium-sized enterprises from 19 July 2030 (Art. 24(1)). - From 19 July 2026, destruction of unsold consumer products listed in Annex VII is prohibited, subject to exemptions; micro and small enterprises are exempt and medium-sized enterprises are included from 19 July 2030 (Art. 25(1)). - Economic operators not subject to the prohibition must not destroy products supplied to them to circumvent the prohibition (Art. 25(2)). - The Commission can amend Annex VII and set derogations by delegated acts, and set disclosure format and verification details by implementing acts (Art. 24(3), Art. 25(3)-(5)). - By 19 July 2027 and every 36 months thereafter, the Commission must publish consolidated information on the destruction of unsold consumer products (Art. 26). ### Green Public Procurement (GPP) - Contracting authorities and contracting entities must award public contracts that comply with minimum requirements set under ESPR for products covered by delegated acts (Art. 65(1)). - The Commission can set those minimum requirements by implementing acts (technical specifications, award criteria, contract performance conditions or targets) (Art. 65(3)). - GPP requirements can reference highest classes of performance, carbon footprint, recycled content, or other sustainability parameters. - Where appropriate, award criteria can have a minimum weighting of between 15% and 30%, and targets can require at least 50% procurement of the most environmentally sustainable products (Art. 65(3)). ### Market Surveillance and Enforcement - Regulation (EU) 2019/1020 on market surveillance applies, and Member States plan checks and priorities as part of their national market surveillance strategy (Art. 66(1)). - For high-risk categories, checks can include physical and laboratory checks; authorities can recover testing costs from the responsible economic operator in case of non-compliance (Art. 66(3)). - Market surveillance authorities record penalty information in the EU information system (Art. 67(1)). - The Commission publishes a report every four years; the first report must be published by 19 July 2028 (Art. 67(3)). - ADCO supports coordination, identifies common priorities, and helps define Union support and guidance (Art. 68). ### Penalties and Sanctions - Member States must lay down and implement penalties for infringements of ESPR; penalties must be effective, proportionate and dissuasive, and Member States notify the Commission of their rules and measures (Art. 74(1)). - Penalty setting must consider factors such as nature/gravity/duration, intent, financial situation, economic benefit, and environmental damage (Art. 74(2)). - Member States must at least be able to impose fines and time-limited exclusion from public procurement procedures (Art. 74(3)). ### SME Support and Proportionality - The Commission must ensure initiatives that help SMEs integrate environmental sustainability in their value chain (Art. 22(1)). - When adopting delegated acts under Art. 4, the Commission should, where appropriate, accompany them with digital tools and guidelines addressing SME specificities (Art. 22(2)). - Member States must take measures to help SMEs comply with ecodesign requirements, including one-stop shops or similar mechanisms (Art. 22(3)). - Micro and small enterprises are exempt from the unsold consumer products disclosure obligation and the destruction prohibition; the disclosure and prohibition apply to medium-sized enterprises from 19 July 2030 (Art. 24(1), Art. 25(1)). ### Prohibition of Circumvention - Economic operators must not engage in behaviour that undermines compliance with ESPR (Art. 40(1)). - Products covered by a delegated act must not be designed to alter behaviour during testing to reach a more favourable result for regulated parameters (Art. 40(2)). - Economic operators must not prescribe test-specific instructions that alter product behaviour to reach a more favourable test result (Art. 40(3)). - Products covered by a delegated act must not be designed to worsen performance shortly after being put into service (Art. 40(4)). - Software or firmware updates must not worsen performance beyond acceptable margins specified in the delegated act in a way that makes the product non-compliant (with narrow, consent-based exception described in the Regulation) (Art. 40(5)). ## Possible Outcomes ### [RESULT] ESPR Ecodesign Requirements Apply (Full Compliance) Product-specific delegated act adopted - Comply with all performance requirements (durability, recyclability, energy efficiency, recycled content, etc.) set in delegated act. - Fulfill all information requirements (DPP, labels, classes of performance, substance tracking) as specified. - Carry out conformity assessment; affix CE marking where required. - Ensure economic operator obligations are met based on your role (manufacturer/importer/distributor/dealer). - Keep technical documentation and declaration of conformity for 10 years. ### [RESULT] General ESPR Obligations Apply No product-specific delegated act yet - No product-specific ecodesign requirements yet, but general obligations apply. - If you discard unsold consumer products, you may have website disclosure obligations (Art. 24) and, for products listed in Annex VII, a destruction prohibition from 19 July 2026 (Art. 25). - Monitor Commission working plan for upcoming delegated acts covering your product group. ### [RESULT] Out of Scope ESPR does not apply - This decision map is not applicable if you are not placing a physical product on the EU market or putting it into service. - ESPR also excludes certain product categories (for example, food and feed, medicinal products, living organisms, products of human origin, and certain vehicles for aspects already addressed by sector-specific Union law). - Check if other EU regulations apply to your product (e.g., sector-specific ecodesign rules, product safety regulations). ## ESPR Timeline | Date | Event | Reference | | --- | --- | --- | | 2024-06-28 | ESPR published in Official Journal (OJ L) | Reg. (EU) 2024/1781 | | 2024-07-18 | ESPR enters into force (20 days after publication) | Art. 80 | | 2025-04-16 | Commission adopted the first ESPR and Energy Labelling Working Plan (2025-30) | Commission implementation timeline | | 2026-02-09 | Commission adopted delegated and implementing acts on destruction of unsold consumer products | Commission implementation timeline | | 2026-07-19 | Commission must set up the digital product passport registry by this date | Art. 13(1) | | 2026-07-19 | Destruction prohibition for unsold consumer products listed in Annex VII applies from this date (subject to exemptions) | Art. 25(1) | | 2027-07-19 | Commission must publish consolidated information on the destruction of unsold consumer products by this date | Art. 26 | | 2028-07-19 | First Commission market surveillance report must be published by this date | Art. 67(3) | | 2028-07-19 | Commission must evaluate potential benefits of social sustainability requirements by this date | Art. 75(4) | | 2030-07-19 | Commission must evaluate ESPR and publish its findings by this date | Art. 75(2) | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2019-12-11 | European Green Deal adopted | Policy & Strategy | | | 2020-03-11 | New Circular Economy Action Plan adopted | Policy & Strategy | | | 2020-09-14 | Sustainable Products Initiative roadmap and consultation opens | Policy & Strategy | | | 2022-03-30 | Commission adopts ESPR proposal | Legislation | | | 2022-06-22 | Sustainable Products Initiative roadmap and consultation closes | Policy & Strategy | | | 2022-11-22 | EESC opinion published (OJ C 443) | Legislation | | | 2023-01-31 | Public consultation on new product priorities opens | Policy & Strategy | | | 2023-05-12 | Public consultation on new product priorities closes | Policy & Strategy | | | 2023-12-05 | Provisional agreement welcomed | Legislation | | | 2024-03-01 | CIRPASS DPP use cases report (D2.2) published (version 2.0) | Digital Product Passport | | | 2024-03-28 | CIRPASS DPP recommendations deliverable (v1.2) delivered | Digital Product Passport | | | 2024-04-23 | European Parliament position (23 April 2024) | Legislation | | | 2024-05-01 | CIRPASS DPP system roadmap published (D3.4) | Digital Product Passport | | | 2024-06-13 | ESPR Regulation (EU) 2024/1781 dated | Legislation | | | 2024-06-24 | Public call for participation: CWA 18186 DPP workshop | Standards & Guidance | | | 2024-06-28 | ESPR published in the Official Journal | Legislation | | | 2024-07-18 | ESPR enters into force | Legislation | | | 2024-07-19 | Commission news published on ESPR adoption | Legislation | | | 2024-10-01 | Ecodesign Forum established (Oct/Nov 2024) | Implementation | | | 2024-10-17 | Fit for Future Platform Opinion adopted (2024/4) | Digital Product Passport | | | 2025-02-19 | First Ecodesign Forum meeting (19-20 Feb 2025) | Implementation | | | 2025-04-09 | Commission launches consultation on the Digital Product Passport | Digital Product Passport | | | 2025-04-16 | First ESPR & Energy Labelling Working Plan adopted and published | Implementation | | | 2025-05-05 | CWA 18186:2025 approved | Standards & Guidance | | | 2025-05-13 | Final text of CWA 18186 submitted to CEN for publication | Standards & Guidance | | | 2025-07-25 | Impact assessment on the Digital Product Passport published | Digital Product Passport | | | 2025-08-27 | Deadline to respond to DPP impact assessment surveys | Digital Product Passport | | | 2026-02-09 | Delegated and implementing acts on unsold consumer products adopted | Implementation | | | 2026-07-19 | Prohibition starts: destruction of certain unsold consumer products | Implementation | | | 2030-07-19 | Additional obligations apply to medium-sized enterprises | Implementation | | **Event details:** - **2019-12-11 - European Green Deal adopted**: European Green Deal adopted (Commission timeline item). - **2020-03-11 - New Circular Economy Action Plan adopted**: Adoption of the New Circular Economy Action Plan (CEAP) (Commission timeline item). - **2020-09-14 - Sustainable Products Initiative roadmap and consultation opens**: Public consultation and roadmap for the Sustainable Products Initiative opens (Commission timeline item: 14 September 2020 to 22 June 2022). - **2022-03-30 - Commission adopts ESPR proposal**: Adoption of the ESPR proposal as part of the Sustainable Products Initiative (Commission timeline item). - **2022-06-22 - Sustainable Products Initiative roadmap and consultation closes**: Public consultation and roadmap for the Sustainable Products Initiative closes (Commission timeline item: 14 September 2020 to 22 June 2022). - **2022-11-22 - EESC opinion published (OJ C 443)**: Official Journal reference for the opinion of the European Economic and Social Committee: OJ C 443, 22.11.2022, p. 123. - **2023-01-31 - Public consultation on new product priorities opens**: Open Public Consultation on new product priorities for ESPR opens (Commission timeline item: 31 January 2023 to 12 May 2023). - **2023-05-12 - Public consultation on new product priorities closes**: Open Public Consultation on new product priorities for ESPR closes (Commission timeline item: 31 January 2023 to 12 May 2023). - **2023-12-05 - Provisional agreement welcomed**: Commission welcomes provisional agreement for more sustainable, repairable and circular products (Commission timeline item). - **2024-03-01 - CIRPASS DPP use cases report (D2.2) published (version 2.0)**: CIRPASS deliverable D2.2 cover shows March 2024 as the document date (Version 2.0). - **2024-03-28 - CIRPASS DPP recommendations deliverable (v1.2) delivered**: CIRPASS recommendations deliverable (Version 1.2, May 2024) lists an actual delivery date of 28 March 2024. - **2024-04-23 - European Parliament position (23 April 2024)**: Position of the European Parliament of 23 April 2024 (referenced in Regulation (EU) 2024/1781). - **2024-05-01 - CIRPASS DPP system roadmap published (D3.4)**: CIRPASS project results page links a DPP system roadmap published in May 2024. - **2024-06-13 - ESPR Regulation (EU) 2024/1781 dated**: Regulation (EU) 2024/1781 is dated 13 June 2024. - **2024-06-24 - Public call for participation: CWA 18186 DPP workshop**: Public call for participation made for the CEN Workshop "Guidelines to create a Digital Product Passport" (CWA 18186:2025). - **2024-06-28 - ESPR published in the Official Journal**: Published in the Official Journal (OJ L) on 28.6.2024. - **2024-07-18 - ESPR enters into force**: Regulation (EU) 2024/1781 enters into force on the twentieth day following its publication in the Official Journal (20 days after 28.6.2024). - **2024-07-19 - Commission news published on ESPR adoption**: Commission news page published 19 July 2024: "New law to make products on the EU market more sustainable". - **2024-10-01 - Ecodesign Forum established (Oct/Nov 2024)**: Establishment of the Ecodesign Forum and publication of call for membership applications (Commission timeline item: October/November 2024; date shown here as 2024-10-01 as a month-level placeholder). - **2024-10-17 - Fit for Future Platform Opinion adopted (2024/4)**: Fit for Future Platform Opinion referenced in Commission material on QR codes on products / Digital Product Passports; adoption date listed as 17 October 2024. - **2025-02-19 - First Ecodesign Forum meeting (19-20 Feb 2025)**: First Ecodesign Forum meeting held on 19-20 February 2025 (Commission timeline item). - **2025-04-09 - Commission launches consultation on the Digital Product Passport**: Commission news page URL indicates publication date 9 April 2025 for a consultation on the Digital Product Passport. - **2025-04-16 - First ESPR & Energy Labelling Working Plan adopted and published**: Adoption and publication of the first ESPR and Energy Labelling Working Plan (Commission timeline item). - **2025-05-05 - CWA 18186:2025 approved**: CWA 18186:2025 approved by the CEN Workshop "Guidelines to create a Digital Product Passport". - **2025-05-13 - Final text of CWA 18186 submitted to CEN for publication**: CWA 18186 timeline metadata notes the final text was provided to CEN for publication on 13 May 2025. - **2025-07-25 - Impact assessment on the Digital Product Passport published**: European Commission publishes the call to take part in its impact assessment on the Digital Product Passport (publication date in the article URL). - **2025-08-27 - Deadline to respond to DPP impact assessment surveys**: Please respond by 27 August to one of the surveys (as stated on the impact assessment page). - **2026-02-09 - Delegated and implementing acts on unsold consumer products adopted**: Adoption of implementing and delegated acts on destruction of unsold consumer products (Commission ESPR timeline item dated 9 February 2026). - **2026-07-19 - Prohibition starts: destruction of certain unsold consumer products**: From 19 July 2026, the destruction of unsold consumer products listed in Annex VII is prohibited. - **2030-07-19 - Additional obligations apply to medium-sized enterprises**: Certain obligations apply to medium-sized enterprises from 19 July 2030 (as specified in Regulation (EU) 2024/1781 document status). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport --- --- title: "EU ESPR (Regulation (EU) 2024/1781) Compliance Hub" canonical_url: "https://www.sorena.io/artifacts/eu/espr" source_url: "https://www.sorena.io/artifacts/eu/ecodesign-for-sustainable-products-regulation" author: "Sorena AI" description: "A practical compliance hub for the EU Ecodesign for Sustainable Products Regulation, Regulation (EU) 2024/1781." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ESPR Regulation (EU) 2024/1781" - "Ecodesign for Sustainable Products Regulation" - "EU ESPR compliance" - "ESPR delegated acts" - "digital product passport DPP" - "DPP requirements" - "product sustainability requirements EU" - "ESPR checklist" - "ESPR applicability test" - "ESPR information requirements" - "ESPR" - "Regulation (EU) 2024/1781" - "Digital Product Passport" - "delegated acts" - "ecodesign requirements" - "sustainable products" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU ESPR (Regulation (EU) 2024/1781) Compliance Hub A practical compliance hub for the EU Ecodesign for Sustainable Products Regulation, Regulation (EU) 2024/1781. ![EU ESPR artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-espr-dpp-timeline-small.jpg?v=cheatsheets%2Fprod) *ESPR* *Free Resource* ## EU ESPR Compliance Hub Turn Regulation (EU) 2024/1781 into an execution plan: scope your product portfolio, track delegated acts, and prepare Digital Product Passport information, identifiers, registry readiness, and evidence exports. ESPR entered into force on 18 July 2024. It is a framework regulation, so most product-specific duties will only crystallize through delegated acts, with the first delegated act not entering into force before 19 July 2025 and the EU DPP registry expected by 19 July 2026. [Start with the checklist](/artifacts/eu/espr/checklist.md) ## What you can decide faster - **Scope**: Is the product in the ESPR framework and which roles apply? - **Delegated acts**: Which product priorities and upcoming measures matter most to you? - **DPP readiness**: What data, identifiers, and systems are needed for Digital Product Passport delivery? By Sorena AI | Updated Mar 2026 | No signup required ### Quick scan *ESPR* - **Applicability test**: Decide whether and how ESPR applies to your products. - **Delegated acts tracker**: Track product priorities, consultations, and your internal readiness. - **DPP playbook**: Turn information requirements into data models, identifiers, and evidence. Use the decision flow to scope the portfolio, then use the topic guides to build DPP and requirements evidence that is actually shippable. | Value | Metric | | --- | --- | | 18 Jul 2024 | In force | | 19 Jul 2025 | First acts | | 19 Jul 2026 | DPP registry | | 16 Apr 2025 | Working plan | **Key highlights:** Portfolio scope | Delegated acts | DPP readiness ## Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/ecodesign-for-sustainable-products-regulation/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/ecodesign-for-sustainable-products-regulation/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/ecodesign-for-sustainable-products-regulation/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/ecodesign-for-sustainable-products-regulation/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/ecodesign-for-sustainable-products-regulation/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/ecodesign-for-sustainable-products-regulation/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/ecodesign-for-sustainable-products-regulation/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/ecodesign-for-sustainable-products-regulation/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/ecodesign-for-sustainable-products-regulation/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/ecodesign-for-sustainable-products-regulation/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/ecodesign-for-sustainable-products-regulation/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/ecodesign-for-sustainable-products-regulation/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/ecodesign-for-sustainable-products-regulation/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/ecodesign-for-sustainable-products-regulation/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/ecodesign-for-sustainable-products-regulation/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/ecodesign-for-sustainable-products-regulation/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. ## Key milestones for ESPR + DPP *ESPR Timeline* Use the key milestones, entry into force on 18 July 2024, first working plan on 16 April 2025, first delegated-act floor on 19 July 2025, and DPP registry target by 19 July 2026, to coordinate policy, engineering, supplier enablement, and assurance work. ## How to operationalize ESPR *ESPR Decision Flow* Use the decision flow to convert portfolio facts into actions: product scope -> delegated acts watchlist -> DPP readiness -> registry and evidence planning. *Next step* ## Turn EU ESPR Compliance Hub into an ESG delivery workflow EU ESPR Compliance Hub should be the shared entry point for your team. Route execution into ESG Compliance for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU ESPR Compliance Hub and route the work by entity, product, team, or control owner. - Use ESG Compliance to manage cross team sustainability work, reporting, and evidence from one workflow. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open ESG Compliance](/solutions/esg-compliance.md): Manage cross team sustainability work, reporting, and evidence from one workflow for EU ESPR Compliance Hub. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share the logic with implementation teams. - **Download timeline**: Align milestones across stakeholders. - [Talk through EU ESPR Compliance Hub](/contact.md): Review your current process, evidence model, and next steps for EU ESPR Compliance Hub. ## Decision Steps ### STEP 1: Are you placing a physical product on the EU market? *Reference: Art. 1(1), Art. 1(2), Art. 4* - ESPR applies to physical goods placed on the EU market or put into service, including components and intermediate products. - Some product categories are excluded (for example, food and feed, medicinal products, living organisms, products of human origin, and certain vehicles for aspects already addressed by sector-specific Union law). - If yes, continue to check whether your product is excluded. If no, ESPR does not apply to that product placement. - **NO** Out of Scope - **YES** Is your product excluded from ESPR scope? ### STEP 2: Is your product excluded from ESPR scope? *Reference: Art. 1(2)* - Check if your product is food/feed, medicinal product, living organism, or a vehicle for which sector-specific EU law already sets requirements. - If yes, ESPR does not apply. - If no, continue to check if a product-specific delegated act has been adopted. - **YES** Out of Scope - **NO** Has a delegated act setting ecodesign requirements been adopted for your product group? ### STEP 3: Has a delegated act setting ecodesign requirements been adopted for your product group? *Reference: Art. 4, Art. 18(3)* - The Commission sets ecodesign requirements by delegated acts for specific product groups (or horizontally for product groups with similar characteristics). - The delegated act will specify the requirements, dates of application, and (where relevant) conformity assessment, markings, and information tools like the DPP and labels. - If yes, your product must comply with the delegated act. If no, ESPR product-specific requirements are not yet in force for that product group, but some general obligations may still apply (for example, rules on unsold consumer products). - **YES** Ecodesign requirements apply to your product - **NO** General ESPR obligations apply even without delegated act ### TRACK 1: Ecodesign requirements apply to your product *Reference: Art. 4, Art. 5(8), Art. 6, Art. 7* - Your product must comply with the performance requirements and information requirements set out in the delegated act, where relevant to your product group. - The delegated act will also specify how compliance is assessed (conformity assessment procedure) and how conformity is indicated (CE marking or alternative conformity marking). - Economic operator obligations apply based on your role (manufacturer, importer, distributor, dealer, etc.). - -> What is your role as an economic operator? ### STEP 5: What is your role as an economic operator? - Manufacturer (and in some cases importers or distributors are treated as manufacturers). - Authorised representative (appointed by a manufacturer via written mandate). - Importer (placing product from a third country on the EU market for the first time). - Distributor (making a product available on the market after it has been placed by manufacturer or importer). - Dealer (offering product for sale, hire or hire purchase, or displaying to customers/installers). - Fulfilment service provider (warehousing, packaging, addressing, dispatching). - Provider of an online marketplace (and in-scope online search engine obligations). - Each role has specific obligations. - -> Does the delegated act require a Digital Product Passport (DPP)? ### STEP 6: Does the delegated act require a Digital Product Passport (DPP)? *Reference: Art. 9, Art. 10, Art. 11* - If a DPP is required, the product can only be placed on the market or put into service if a DPP is available in accordance with the delegated act and the essential requirements in the Regulation. - The delegated act will specify the DPP data, data carrier(s), accessibility before purchase (including distance selling), access rights, and who can create or update the passport. - Some product groups can be exempted from the DPP requirement where technical specifications are not available or where another Union law provides a comparable digital information system. - **YES** Does the delegated act require product labels? - **NO** Does the delegated act require product labels? ### STEP 7: Does the delegated act require product labels? *Reference: Art. 16, Art. 32* - Where information requirements indicate that information is to be included in a label, the delegated act will specify label content, layout and display requirements (including distance selling). - If labels are required, economic operators must provide labels and dealers must display them as required by the delegated act. - **YES** Does the delegated act set performance requirements? - **NO** Does the delegated act set performance requirements? ### STEP 8: Does the delegated act set performance requirements? *Reference: Art. 5, Art. 6* - Performance requirements set minimum or maximum levels for one or more product parameters in Annex I, to improve relevant product aspects. - If yes, ensure the product meets the performance requirements before placing it on the market or putting it into service. - **YES** Does the delegated act set information requirements? - **NO** Does the delegated act set information requirements? ### STEP 9: Does the delegated act set information requirements? *Reference: Art. 7* - Information requirements specify product information to be made available (e.g., environmental footprint, durability, repair instructions). - Information can be provided via DPP, label, product manual, website, or other means as specified in delegated act. - If yes, ensure required information is made available in the specified manner. - **YES** What conformity assessment procedure applies? - **NO** What conformity assessment procedure applies? ### STEP 10: What conformity assessment procedure applies? *Reference: Art. 4(5), Art. 43* - Conformity assessment procedures range from internal production control (Module A) to more stringent modules involving notified bodies. - The delegated act specifies the applicable conformity assessment module for the product group. - Some modules involve notified bodies, depending on the module specified in the delegated act. - -> ESPR Ecodesign Requirements Apply (Full Compliance) ### TRACK 2: General ESPR obligations apply even without delegated act *Reference: Art. 23, Art. 24, Art. 25* - If no delegated act applies to your product group, ESPR product-specific ecodesign requirements are not yet in force for that product group. - However, Chapter VI sets rules on preventing and (for certain products) prohibiting the destruction of unsold consumer products, and on disclosing information about discarded unsold consumer products. - -> Does the destruction ban apply to your product? ### STEP 11: Does the destruction ban apply to your product? *Reference: Art. 23, Art. 24, Art. 25, Annex VII* - If you discard unsold consumer products (directly or via a third party), you may have a disclosure obligation. - From 19 July 2026, destruction of unsold consumer products listed in Annex VII is prohibited (subject to exemptions). - Micro and small enterprises are exempt from the prohibition, and the prohibition applies to medium-sized enterprises from 19 July 2030. - **YES** General ESPR Obligations Apply - **NO** General ESPR Obligations Apply ## Reference Information ### Products In Scope (Overview) - ESPR sets a framework for ecodesign requirements for physical products placed on the EU market or put into service, including components and intermediate products. - Product-specific requirements apply only when the Commission adopts a delegated act for a product group (and the delegated act will set dates of application). - Ecodesign requirements can include performance requirements and information requirements. - Information requirements can be delivered through tools like the digital product passport and (where applicable) labels. ### Key Exclusions - Food and feed as defined in Regulation (EC) No 178/2002. - Medicinal products (Directive 2001/83/EC) and veterinary medicinal products (Regulation (EU) 2019/6). - Living plants, animals and micro-organisms; products of human origin; products of plants and animals relating directly to their future reproduction. - Vehicles (Regulations (EU) No 167/2013, No 168/2013, 2018/858) for aspects already addressed by sector-specific Union law. ### Authorised Representative Obligations - A manufacturer may appoint an authorised representative by written mandate (Art. 28(1)). - The mandate cannot cover the manufacturer's obligations in Art. 27(1) or the drawing up of technical documentation (Art. 28(1)). - Keep the EU declaration of conformity and technical documentation available to market surveillance authorities for 10 years (unless a delegated act sets a different period) (Art. 28(2)(a)). - Cooperate with competent national authorities and provide information and documentation within 15 days upon a reasoned request (Art. 28(2)(b)-(c)). - Terminate the mandate if the manufacturer acts contrary to its obligations (Art. 28(2)(d)). ### Manufacturer Obligations - For products covered by a delegated act: ensure the product is designed and manufactured in accordance with performance requirements and accompanied by required information (Art. 27(1)(a)-(b)). - Ensure a digital product passport is available where required, including a back-up copy via a digital product passport service provider (Art. 27(1)(c), Art. 10(4)). - Carry out the conformity assessment procedure specified in the delegated act and draw up technical documentation (Art. 27(2)). - Draw up the EU declaration of conformity and affix the CE marking (or the alternative conformity marking specified in the delegated act, if applicable) (Art. 27(2), Art. 44, Art. 46, Art. 4(6)(d)). - Keep technical documentation and the EU declaration of conformity for 10 years (unless the delegated act specifies a different period) (Art. 27(3)). - Ensure products bear an identifier (type, batch, serial number, or equivalent) (Art. 27(5)). - Provide manufacturer name and contact details on the product/packaging and, where applicable, on the public part of the DPP (Art. 27(6)). - Provide digital instructions (plus paper safety information) and keep digital instructions accessible online for at least 10 years (Art. 27(7)). - If you believe a product is non-compliant, take corrective action (including withdrawal/recall where appropriate) and inform market surveillance authorities (Art. 27(8)). ### Importer Obligations - For products covered by a delegated act: place on the market only products that comply with the applicable delegated act (Art. 29(1)). - Before placing a product on the market: ensure conformity assessment and technical documentation are done, required information is provided, and a DPP is available where required (Art. 29(2)(a)-(c)). - Ensure the product bears the CE marking (where applicable) or the alternative conformity marking specified in the delegated act, and the manufacturer has complied with identification and contact details requirements (Art. 29(2), Art. 45, Art. 46, Art. 27(5)-(6)). - Provide importer name and contact details on the product/packaging and, where applicable, on the public part of the DPP (Art. 29(3)). - Ensure digital instructions accompany the product (Art. 29(4)). - Ensure storage and transport conditions do not jeopardise compliance (Art. 29(5)). - If you believe a product is non-compliant, take corrective action (including withdrawal/recall where appropriate) and inform market surveillance authorities (Art. 29(6)). - Keep a copy of the EU declaration of conformity and ensure technical documentation can be made available for 10 years (unless the delegated act specifies a different period) (Art. 29(7)). - Provide information and documentation on request within 15 days and cooperate with authorities (Art. 29(8)). ### Distributor Obligations - For products covered by a delegated act: act with due care in relation to the requirements in the applicable delegated acts (Art. 30(1)). - Before making a product available: verify CE marking (or alternative conformity marking), and where relevant that the product is labelled or linked to a DPP, and that required documents and digital instructions are provided (Art. 30(2)). - Verify that the manufacturer and importer have complied with required identification and contact details obligations (Art. 30(2)(c), Art. 27(5)-(6), Art. 29(3)). - If you believe a product is not in conformity, do not make it available until it is brought into conformity (Art. 30(3)). - Ensure storage and transport conditions do not jeopardise compliance (Art. 30(3)). - If you believe a product you made available is non-compliant, ensure corrective action is taken (withdraw/recall where appropriate) and inform market surveillance authorities (Art. 30(4)). - Provide information and documentation on request within 15 days and cooperate with authorities (Art. 30(5)). ### Dealer Obligations - Ensure customers and potential customers can access the information required by the delegated act, including in the event of distance selling (Art. 31(1)). - Where a DPP is required, ensure it is easily accessible for customers and potential customers, including in the event of distance selling (Art. 31(2), Art. 9(2)(e)). - Where labels are required: display labels visibly, reference label information in visual advertisements and technical promotional material, and do not display other labels/marks that mislead or confuse customers (Art. 31(3)). ### Fulfilment Service Provider Obligations - For products covered by a delegated act that you handle: ensure that conditions during warehousing, packaging, addressing or dispatching do not jeopardise compliance with that delegated act (Art. 33). - In some cases of non-compliance, fulfilment service providers can be liable for consumer damage (Art. 76(c)). ### Online Marketplace Provider Obligations - General obligations under Regulation (EU) 2022/2065 apply for the purposes of ESPR (Art. 35(1)). - Cooperate with market surveillance authorities, at their request and in specific cases, to eliminate or mitigate the non-compliance of products offered online through your services (Art. 35(1)). - Market surveillance authorities can order removal of content referring to non-compliant products offered for sale online (Art. 35(2)). - Establish a single contact point for direct communication with market surveillance authorities (Art. 35(3)). ### Distance Selling: Product Offer Information - When selling a product covered by a delegated act through distance selling, ensure the product offer clearly and visibly includes manufacturer identity and contact details (Art. 36(1)(a)). - If the manufacturer is not established in the Union, include the EU-based economic operator required under Regulation (EU) 2019/1020 (Art. 36(1)(b)). - Include product identification information, including a picture, type, and other product identifier (Art. 36(1)(c)). - Maintain supply chain traceability information (who supplied you; who you supplied; quantities and exact models) for 10 years and provide it within 15 days upon request (Art. 36(2)). ### Digital Product Passport (DPP) Requirements - If a DPP is required, the product can only be placed on the market or put into service if a DPP is available; DPP data must be accurate, complete and up to date (Art. 9(1)). - The delegated act will specify DPP content and operational requirements (data carriers, layout/positioning, level, accessibility before purchase, access rights, who can create/update data, and availability period) (Art. 9(2)). - The DPP must comply with essential requirements, including a data carrier connected to a persistent unique product identifier; interoperable/open standards; machine-readable, structured and searchable data; and no customer personal data without explicit consent (Art. 10(1)). - The economic operator placing the product on the market must provide dealers and providers of online marketplaces with a digital copy of the data carrier or unique product identifier (or a link) and, upon request, do so within 5 working days (Art. 10(3)). - The economic operator must make a back-up copy of the DPP available through a digital product passport service provider (Art. 10(4)). - Technical design and operation requirements include interoperability, access by stakeholders based on rights, integrity/security, and availability for the period set in the delegated act (Art. 11). - The Commission must set up a DPP registry by 19 July 2026, and the economic operator placing the product on the market uploads required data to the registry (Art. 13(1), Art. 13(4)). ### Label Requirements - Where a delegated act requires a label under Art. 16, the delegated act will specify label content, layout, and how it must be displayed to customers (including distance selling) (Art. 16(1)). - Labels can include data carriers or other means to allow customers to access additional information, including access to the DPP where appropriate (Art. 16(4)). - If a delegated act requires a label, economic operators placing products on the market must ensure each unit is accompanied by printed labels, provide labels to dealers within 5 working days upon request, and keep technical documentation to support label accuracy (Art. 32(1)). - Dealers must display labels and reference label information in advertisements and promotional material, and must not display other labels/marks that mislead or confuse customers about the ESPR label information (Art. 31(3), Art. 32(2)). - Products with labels that mislead or confuse customers by mimicking ESPR labels must not be placed on the market or put into service (Art. 17). ### Performance Requirements (Examples) - Performance requirements aim to improve relevant product aspects such as durability, reliability, reusability, upgradability, repairability, and maintenance/refurbishment (Art. 5(1)(a)-(f)). - They can address substances of concern, energy and water use, resource use, recycled content, remanufacturing, recyclability and material recovery (Art. 5(1)(g)-(n)). - They can address environmental impacts, including carbon footprint and environmental footprint, and expected generation of waste (Art. 5(1)(o)-(p)). - Delegated acts can also include measures to prevent premature obsolescence (Art. 5(2)). ### Information Requirements (Examples) - Information requirements can include information on product performance (for example, repairability score, durability score, carbon footprint or environmental footprint) (Art. 7(2)(b)(i)). - They can include customer and other actor information on installation, use, maintenance and repair, and end-of-life handling (Art. 7(2)(b)(ii)-(iv)). - Where appropriate, the Commission can determine classes of performance to help customers compare products (Art. 7(4)). - Information requirements must enable tracking substances of concern throughout the product life cycle, subject to thresholds and exemptions set in delegated acts (Art. 7(5)-(6)). - Required information is made available in the manner specified by the delegated act; where a DPP is available, required information is provided in the DPP and may also be provided via product, packaging, label, documentation, or a free access website/app (Art. 7(7)). ### Conformity Assessment and CE Marking - For products covered by a delegated act, the manufacturer must carry out the conformity assessment procedure specified in that delegated act and draw up technical documentation (Art. 27(2)). - The manufacturer draws up an EU declaration of conformity (Art. 44) and affixes the CE marking (Art. 46), unless the delegated act specifies an alternative conformity marking (Art. 4(6)(d)). - Conformity assessment modules are selected from Annex IV (Module A) or modules in Decision No 768/2008/EC, as specified in delegated acts (Art. 4(5)). - Tests, measurements and calculations for compliance use harmonised standards or other reliable methods specified in delegated acts (Art. 39), and harmonised standards can provide presumption of conformity (Art. 41). - Keep technical documentation and the EU declaration of conformity for 10 years (unless the delegated act specifies a different period) (Art. 27(3), Art. 29(7)). ### Destruction of Unsold Products: Ban and Disclosure - Economic operators must take reasonable measures to prevent the need to destroy unsold consumer products (Art. 23). - Economic operators that discard unsold consumer products (directly or via a third party) must disclose annual information on their website (number/weight, reasons, treatment route proportions, and measures taken/planned) (Art. 24(1)). - The disclosure obligation does not apply to micro and small enterprises and applies to medium-sized enterprises from 19 July 2030 (Art. 24(1)). - From 19 July 2026, destruction of unsold consumer products listed in Annex VII is prohibited, subject to exemptions; micro and small enterprises are exempt and medium-sized enterprises are included from 19 July 2030 (Art. 25(1)). - Economic operators not subject to the prohibition must not destroy products supplied to them to circumvent the prohibition (Art. 25(2)). - The Commission can amend Annex VII and set derogations by delegated acts, and set disclosure format and verification details by implementing acts (Art. 24(3), Art. 25(3)-(5)). - By 19 July 2027 and every 36 months thereafter, the Commission must publish consolidated information on the destruction of unsold consumer products (Art. 26). ### Green Public Procurement (GPP) - Contracting authorities and contracting entities must award public contracts that comply with minimum requirements set under ESPR for products covered by delegated acts (Art. 65(1)). - The Commission can set those minimum requirements by implementing acts (technical specifications, award criteria, contract performance conditions or targets) (Art. 65(3)). - GPP requirements can reference highest classes of performance, carbon footprint, recycled content, or other sustainability parameters. - Where appropriate, award criteria can have a minimum weighting of between 15% and 30%, and targets can require at least 50% procurement of the most environmentally sustainable products (Art. 65(3)). ### Market Surveillance and Enforcement - Regulation (EU) 2019/1020 on market surveillance applies, and Member States plan checks and priorities as part of their national market surveillance strategy (Art. 66(1)). - For high-risk categories, checks can include physical and laboratory checks; authorities can recover testing costs from the responsible economic operator in case of non-compliance (Art. 66(3)). - Market surveillance authorities record penalty information in the EU information system (Art. 67(1)). - The Commission publishes a report every four years; the first report must be published by 19 July 2028 (Art. 67(3)). - ADCO supports coordination, identifies common priorities, and helps define Union support and guidance (Art. 68). ### Penalties and Sanctions - Member States must lay down and implement penalties for infringements of ESPR; penalties must be effective, proportionate and dissuasive, and Member States notify the Commission of their rules and measures (Art. 74(1)). - Penalty setting must consider factors such as nature/gravity/duration, intent, financial situation, economic benefit, and environmental damage (Art. 74(2)). - Member States must at least be able to impose fines and time-limited exclusion from public procurement procedures (Art. 74(3)). ### SME Support and Proportionality - The Commission must ensure initiatives that help SMEs integrate environmental sustainability in their value chain (Art. 22(1)). - When adopting delegated acts under Art. 4, the Commission should, where appropriate, accompany them with digital tools and guidelines addressing SME specificities (Art. 22(2)). - Member States must take measures to help SMEs comply with ecodesign requirements, including one-stop shops or similar mechanisms (Art. 22(3)). - Micro and small enterprises are exempt from the unsold consumer products disclosure obligation and the destruction prohibition; the disclosure and prohibition apply to medium-sized enterprises from 19 July 2030 (Art. 24(1), Art. 25(1)). ### Prohibition of Circumvention - Economic operators must not engage in behaviour that undermines compliance with ESPR (Art. 40(1)). - Products covered by a delegated act must not be designed to alter behaviour during testing to reach a more favourable result for regulated parameters (Art. 40(2)). - Economic operators must not prescribe test-specific instructions that alter product behaviour to reach a more favourable test result (Art. 40(3)). - Products covered by a delegated act must not be designed to worsen performance shortly after being put into service (Art. 40(4)). - Software or firmware updates must not worsen performance beyond acceptable margins specified in the delegated act in a way that makes the product non-compliant (with narrow, consent-based exception described in the Regulation) (Art. 40(5)). ## Possible Outcomes ### [RESULT] ESPR Ecodesign Requirements Apply (Full Compliance) Product-specific delegated act adopted - Comply with all performance requirements (durability, recyclability, energy efficiency, recycled content, etc.) set in delegated act. - Fulfill all information requirements (DPP, labels, classes of performance, substance tracking) as specified. - Carry out conformity assessment; affix CE marking where required. - Ensure economic operator obligations are met based on your role (manufacturer/importer/distributor/dealer). - Keep technical documentation and declaration of conformity for 10 years. ### [RESULT] General ESPR Obligations Apply No product-specific delegated act yet - No product-specific ecodesign requirements yet, but general obligations apply. - If you discard unsold consumer products, you may have website disclosure obligations (Art. 24) and, for products listed in Annex VII, a destruction prohibition from 19 July 2026 (Art. 25). - Monitor Commission working plan for upcoming delegated acts covering your product group. ### [RESULT] Out of Scope ESPR does not apply - This decision map is not applicable if you are not placing a physical product on the EU market or putting it into service. - ESPR also excludes certain product categories (for example, food and feed, medicinal products, living organisms, products of human origin, and certain vehicles for aspects already addressed by sector-specific Union law). - Check if other EU regulations apply to your product (e.g., sector-specific ecodesign rules, product safety regulations). ## ESPR Timeline | Date | Event | Reference | | --- | --- | --- | | 2024-06-28 | ESPR published in Official Journal (OJ L) | Reg. (EU) 2024/1781 | | 2024-07-18 | ESPR enters into force (20 days after publication) | Art. 80 | | 2025-04-16 | Commission adopted the first ESPR and Energy Labelling Working Plan (2025-30) | Commission implementation timeline | | 2026-02-09 | Commission adopted delegated and implementing acts on destruction of unsold consumer products | Commission implementation timeline | | 2026-07-19 | Commission must set up the digital product passport registry by this date | Art. 13(1) | | 2026-07-19 | Destruction prohibition for unsold consumer products listed in Annex VII applies from this date (subject to exemptions) | Art. 25(1) | | 2027-07-19 | Commission must publish consolidated information on the destruction of unsold consumer products by this date | Art. 26 | | 2028-07-19 | First Commission market surveillance report must be published by this date | Art. 67(3) | | 2028-07-19 | Commission must evaluate potential benefits of social sustainability requirements by this date | Art. 75(4) | | 2030-07-19 | Commission must evaluate ESPR and publish its findings by this date | Art. 75(2) | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2019-12-11 | European Green Deal adopted | Policy & Strategy | | | 2020-03-11 | New Circular Economy Action Plan adopted | Policy & Strategy | | | 2020-09-14 | Sustainable Products Initiative roadmap and consultation opens | Policy & Strategy | | | 2022-03-30 | Commission adopts ESPR proposal | Legislation | | | 2022-06-22 | Sustainable Products Initiative roadmap and consultation closes | Policy & Strategy | | | 2022-11-22 | EESC opinion published (OJ C 443) | Legislation | | | 2023-01-31 | Public consultation on new product priorities opens | Policy & Strategy | | | 2023-05-12 | Public consultation on new product priorities closes | Policy & Strategy | | | 2023-12-05 | Provisional agreement welcomed | Legislation | | | 2024-03-01 | CIRPASS DPP use cases report (D2.2) published (version 2.0) | Digital Product Passport | | | 2024-03-28 | CIRPASS DPP recommendations deliverable (v1.2) delivered | Digital Product Passport | | | 2024-04-23 | European Parliament position (23 April 2024) | Legislation | | | 2024-05-01 | CIRPASS DPP system roadmap published (D3.4) | Digital Product Passport | | | 2024-06-13 | ESPR Regulation (EU) 2024/1781 dated | Legislation | | | 2024-06-24 | Public call for participation: CWA 18186 DPP workshop | Standards & Guidance | | | 2024-06-28 | ESPR published in the Official Journal | Legislation | | | 2024-07-18 | ESPR enters into force | Legislation | | | 2024-07-19 | Commission news published on ESPR adoption | Legislation | | | 2024-10-01 | Ecodesign Forum established (Oct/Nov 2024) | Implementation | | | 2024-10-17 | Fit for Future Platform Opinion adopted (2024/4) | Digital Product Passport | | | 2025-02-19 | First Ecodesign Forum meeting (19-20 Feb 2025) | Implementation | | | 2025-04-09 | Commission launches consultation on the Digital Product Passport | Digital Product Passport | | | 2025-04-16 | First ESPR & Energy Labelling Working Plan adopted and published | Implementation | | | 2025-05-05 | CWA 18186:2025 approved | Standards & Guidance | | | 2025-05-13 | Final text of CWA 18186 submitted to CEN for publication | Standards & Guidance | | | 2025-07-25 | Impact assessment on the Digital Product Passport published | Digital Product Passport | | | 2025-08-27 | Deadline to respond to DPP impact assessment surveys | Digital Product Passport | | | 2026-02-09 | Delegated and implementing acts on unsold consumer products adopted | Implementation | | | 2026-07-19 | Prohibition starts: destruction of certain unsold consumer products | Implementation | | | 2030-07-19 | Additional obligations apply to medium-sized enterprises | Implementation | | **Event details:** - **2019-12-11 - European Green Deal adopted**: European Green Deal adopted (Commission timeline item). - **2020-03-11 - New Circular Economy Action Plan adopted**: Adoption of the New Circular Economy Action Plan (CEAP) (Commission timeline item). - **2020-09-14 - Sustainable Products Initiative roadmap and consultation opens**: Public consultation and roadmap for the Sustainable Products Initiative opens (Commission timeline item: 14 September 2020 to 22 June 2022). - **2022-03-30 - Commission adopts ESPR proposal**: Adoption of the ESPR proposal as part of the Sustainable Products Initiative (Commission timeline item). - **2022-06-22 - Sustainable Products Initiative roadmap and consultation closes**: Public consultation and roadmap for the Sustainable Products Initiative closes (Commission timeline item: 14 September 2020 to 22 June 2022). - **2022-11-22 - EESC opinion published (OJ C 443)**: Official Journal reference for the opinion of the European Economic and Social Committee: OJ C 443, 22.11.2022, p. 123. - **2023-01-31 - Public consultation on new product priorities opens**: Open Public Consultation on new product priorities for ESPR opens (Commission timeline item: 31 January 2023 to 12 May 2023). - **2023-05-12 - Public consultation on new product priorities closes**: Open Public Consultation on new product priorities for ESPR closes (Commission timeline item: 31 January 2023 to 12 May 2023). - **2023-12-05 - Provisional agreement welcomed**: Commission welcomes provisional agreement for more sustainable, repairable and circular products (Commission timeline item). - **2024-03-01 - CIRPASS DPP use cases report (D2.2) published (version 2.0)**: CIRPASS deliverable D2.2 cover shows March 2024 as the document date (Version 2.0). - **2024-03-28 - CIRPASS DPP recommendations deliverable (v1.2) delivered**: CIRPASS recommendations deliverable (Version 1.2, May 2024) lists an actual delivery date of 28 March 2024. - **2024-04-23 - European Parliament position (23 April 2024)**: Position of the European Parliament of 23 April 2024 (referenced in Regulation (EU) 2024/1781). - **2024-05-01 - CIRPASS DPP system roadmap published (D3.4)**: CIRPASS project results page links a DPP system roadmap published in May 2024. - **2024-06-13 - ESPR Regulation (EU) 2024/1781 dated**: Regulation (EU) 2024/1781 is dated 13 June 2024. - **2024-06-24 - Public call for participation: CWA 18186 DPP workshop**: Public call for participation made for the CEN Workshop "Guidelines to create a Digital Product Passport" (CWA 18186:2025). - **2024-06-28 - ESPR published in the Official Journal**: Published in the Official Journal (OJ L) on 28.6.2024. - **2024-07-18 - ESPR enters into force**: Regulation (EU) 2024/1781 enters into force on the twentieth day following its publication in the Official Journal (20 days after 28.6.2024). - **2024-07-19 - Commission news published on ESPR adoption**: Commission news page published 19 July 2024: "New law to make products on the EU market more sustainable". - **2024-10-01 - Ecodesign Forum established (Oct/Nov 2024)**: Establishment of the Ecodesign Forum and publication of call for membership applications (Commission timeline item: October/November 2024; date shown here as 2024-10-01 as a month-level placeholder). - **2024-10-17 - Fit for Future Platform Opinion adopted (2024/4)**: Fit for Future Platform Opinion referenced in Commission material on QR codes on products / Digital Product Passports; adoption date listed as 17 October 2024. - **2025-02-19 - First Ecodesign Forum meeting (19-20 Feb 2025)**: First Ecodesign Forum meeting held on 19-20 February 2025 (Commission timeline item). - **2025-04-09 - Commission launches consultation on the Digital Product Passport**: Commission news page URL indicates publication date 9 April 2025 for a consultation on the Digital Product Passport. - **2025-04-16 - First ESPR & Energy Labelling Working Plan adopted and published**: Adoption and publication of the first ESPR and Energy Labelling Working Plan (Commission timeline item). - **2025-05-05 - CWA 18186:2025 approved**: CWA 18186:2025 approved by the CEN Workshop "Guidelines to create a Digital Product Passport". - **2025-05-13 - Final text of CWA 18186 submitted to CEN for publication**: CWA 18186 timeline metadata notes the final text was provided to CEN for publication on 13 May 2025. - **2025-07-25 - Impact assessment on the Digital Product Passport published**: European Commission publishes the call to take part in its impact assessment on the Digital Product Passport (publication date in the article URL). - **2025-08-27 - Deadline to respond to DPP impact assessment surveys**: Please respond by 27 August to one of the surveys (as stated on the impact assessment page). - **2026-02-09 - Delegated and implementing acts on unsold consumer products adopted**: Adoption of implementing and delegated acts on destruction of unsold consumer products (Commission ESPR timeline item dated 9 February 2026). - **2026-07-19 - Prohibition starts: destruction of certain unsold consumer products**: From 19 July 2026, the destruction of unsold consumer products listed in Annex VII is prohibited. - **2030-07-19 - Additional obligations apply to medium-sized enterprises**: Certain obligations apply to medium-sized enterprises from 19 July 2030 (as specified in Regulation (EU) 2024/1781 document status). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ecodesign-for-sustainable-products-regulation --- --- title: "ETSI EN 303 645 Consumer IoT Security Standard (Provision Map + Evidence Guide)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645" source_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645" author: "Sorena AI" description: "ETSI EN 303 645 implementation guide for consumer IoT security: baseline requirements, secure update mechanisms, vulnerability disclosure policy (CVD)." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 303 645" - "ETSI EN 303 645 requirements" - "consumer IoT security standard" - "IoT security baseline requirements" - "vulnerability disclosure policy" - "coordinated vulnerability disclosure" - "secure software updates" - "secure firmware update mechanism" - "no universal default passwords" - "secure storage" - "secure communications" - "minimize attack surface" - "input validation" - "telemetry anomaly detection" - "support period" - "ETSI TS 103 701 conformance assessment" - "audit evidence mapping" - "Consumer IoT security" - "Secure update mechanism" - "ETSI TS 103 701" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 303 645 Consumer IoT Security Standard (Provision Map + Evidence Guide) ETSI EN 303 645 implementation guide for consumer IoT security: baseline requirements, secure update mechanisms, vulnerability disclosure policy (CVD). ![ETSI EN 303 645 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-etsi-en-303-645-small.jpg?v=cheatsheets%2Fprod) *ETSI EN 303 645* *Free Resource* ## ETSI EN 303 645 Implementation Guide A provision-by-provision ETSI EN 303 645 guide for consumer IoT security: translate baseline requirements into engineering controls, secure update mechanisms, vulnerability disclosure workflows, and audit-ready evidence. Use the current ETSI EN 303 645 V3.1.3 standard together with ETSI TS 103 701 V2.1.1 when you build controls, evidence, and conformance workflows for consumer IoT products. [Start with the requirements map](/artifacts/global/etsi-en-303-645/requirements.md) ## What you can decide faster - **Passwords**: Eliminate universal default credentials and harden authentication mechanisms. - **Vulnerability disclosure**: Publish a VDP and run a coordinated vulnerability disclosure workflow. - **Secure updates**: Ship verifiable software updates and publish a support period your users can trust. Grounded in ETSI PDFs | Updated 2026 | No signup required ### Quick scan *Artifact* - **Provision map (5.1-5.13)**: Turn clauses into controls, evidence, and testable acceptance criteria. - **Evidence pack**: Build audit-ready artifacts (VDP, update policy, SBOM, logs) that map to provisions. - **Topic guides**: Deep dives for requirements, compliance, secure updates, and FAQs. Use the guide and subpages to convert ETSI EN 303 645 into engineering work items and reusable evidence. | Value | Metric | | --- | --- | | 1 | Standard | | 5 | Guides | | 2026 | Updated | | SEO | Optimized | **Key highlights:** Scope first | Plan controls | Track evidence ## Topic Guides - [ETSI EN 303 645 Compliance & Conformance Assessment (ICS/IXIT Evidence)](/artifacts/global/etsi-en-303-645/compliance.md): How to operationalize ETSI EN 303 645 compliance for consumer IoT: conformance assessment approach (ETSI TS 103 701), ICS/IXIT-style evidence. - [ETSI EN 303 645 FAQ (Consumer IoT Security Standard)](/artifacts/global/etsi-en-303-645/faq.md): Answering common product-team questions about ETSI EN 303 645: unique passwords, vulnerability disclosure policy requirements, secure software updates. - [ETSI EN 303 645 Requirements (Provision Map 5.1-5.13)](/artifacts/global/etsi-en-303-645/requirements.md): Provision-by-provision ETSI EN 303 645 requirements for consumer IoT: passwords, vulnerability disclosure policy, secure software updates, secure storage. - [ETSI EN 303 645 Secure Updates & Vulnerability Disclosure (VDP + CVD)](/artifacts/global/etsi-en-303-645/secure-update-and-vulnerability-disclosure.md): Deep implementation guide for ETSI EN 303 645 update security and vulnerability disclosure: publish a VDP, run coordinated vulnerability disclosure (CVD). - [ETSI EN 303 645 vs UK PSTI (Practical Mapping for Connectable Products)](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-uk-psti.md): Practical comparison of ETSI EN 303 645 baseline consumer IoT security provisions vs the UK PSTI security requirements regime. ## Key milestones for ETSI EN 303 645 *Timeline* Use timeline milestones to sequence policy, engineering, assurance, and reporting work. ## How to operationalize ETSI EN 303 645 *Decision Flow* Use the decision flow to convert applicability and requirement questions into clear actions. *Next step* ## Turn ETSI EN 303 645 Implementation Guide into an operational assessment workflow ETSI EN 303 645 Implementation Guide should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into Research Copilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from ETSI EN 303 645 Implementation Guide and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for ETSI EN 303 645 Implementation Guide. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs from the same artifact. - [Talk through ETSI EN 303 645 Implementation Guide](/contact.md): Review your current process, evidence model, and next steps for ETSI EN 303 645 Implementation Guide. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-303-645 --- --- title: "ETSI EN 319 401 V3.1.1 Trust Service Provider Policy Requirements and eIDAS Mapping" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-401" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-401" author: "Sorena AI" description: "ETSI EN 319 401 V3.1.1 implementation guide for Trust Service Providers: REQ-5 risk assessment, REQ-6 policies and practice statements." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 319 401" - "ETSI EN 319 401 V3.1.1" - "trust service provider policy requirements" - "TSP compliance" - "trust service practice statement" - "information security policy" - "REQ-5 risk assessment" - "REQ-6.2 terms and conditions" - "REQ-7.8 network security" - "REQ-7.9 incident response" - "24 hour breach notification" - "REQ-7.10 evidence retention" - "REQ-7.14.3 supply chain policy" - "NIS2" - "eIDAS Article 19 and Article 24 mapping" - "Trust Service Provider" - "Monitoring and logging" - "Incident response" - "eIDAS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 401 V3.1.1 Trust Service Provider Policy Requirements and eIDAS Mapping ETSI EN 319 401 V3.1.1 implementation guide for Trust Service Providers: REQ-5 risk assessment, REQ-6 policies and practice statements. ![ETSI EN 319 401 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-etsi-en-319-401-small.jpg?v=cheatsheets%2Fprod) *ETSI EN 319 401* *Free Resource* ## ETSI EN 319 401 Implementation Guide A practical ETSI EN 319 401 guide for Trust Service Providers (TSPs): translate policy requirements into security controls, monitoring, incident response, and evidence that survives audits and regulatory scrutiny. Use the current ETSI EN 319 401 V3.1.1 standard, its Annex B eIDAS mapping, and the related ETSI conformity-assessment framework when you build TSP controls, evidence, and supervisory reporting readiness. [Start with the requirements map](/artifacts/global/etsi-en-319-401/requirements.md) ## What you can decide faster - **Risk treatment**: Turn REQ-5 risk assessment into security requirements, operating procedures, and management-approved residual risk decisions. - **Audit evidence**: Build an evidence pack for REQ-7.8, REQ-7.9, REQ-7.10, and REQ-7.14.3 that stays current through audits and incidents. - **Incident response**: Operationalize monitoring, post-incident review, and 24-hour breach notification procedures with named owners. Grounded in ETSI PDFs | Updated 2026 | No signup required ### Quick scan *Artifact* - **REQ-5 risk assessment**: Define threats, treatments, and security requirements commensurate to risk. - **REQ-6 policies and practices**: Cover practice statements, security policy, incident reporting, UTC log time, and supplier obligations. - **Topic guides**: Deep dives for requirements, compliance, audit readiness, eIDAS mapping, and FAQs. Use the guide and subpages to convert ETSI EN 319 401 into operating controls, verification, and reusable evidence. | Value | Metric | | --- | --- | | 1 | Standard | | 5 | Guides | | V3.1.1 | Current | | SEO | Optimized | **Key highlights:** Scope first | Plan controls | Track evidence ## Topic Guides - [ETSI EN 319 401 Audit & Conformity Assessment (Evidence Pack + Checklist)](/artifacts/global/etsi-en-319-401/audit-and-conformity-assessment.md): Audit readiness guide for ETSI EN 319 401 Trust Service Providers: how conformity assessment works in practice, what auditors sample. - [ETSI EN 319 401 Compliance Playbook for Trust Service Providers (TSPs)](/artifacts/global/etsi-en-319-401/compliance.md): How to operationalize ETSI EN 319 401 compliance for Trust Service Providers: scope definition, governance, risk assessment to control mapping. - [ETSI EN 319 401 FAQ for Trust Service Providers (TSPs)](/artifacts/global/etsi-en-319-401/faq.md): Frequently asked questions about ETSI EN 319 401 for Trust Service Providers: what a Trust Service Practice Statement is, how risk assessment drives controls. - [ETSI EN 319 401 Requirements (REQ-5/6/7 Map for Trust Service Providers)](/artifacts/global/etsi-en-319-401/requirements.md): Clause-by-clause ETSI EN 319 401 requirements mapping for Trust Service Providers (TSPs): risk assessment (REQ-5). - [ETSI EN 319 401 vs eIDAS (Mapping to Article 19 & 24 TSP Obligations)](/artifacts/global/etsi-en-319-401/etsi-en-319-401-vs-eidas.md): Practical mapping of ETSI EN 319 401 requirements to the EU eIDAS Regulation (EU) No 910/2014. ## Key milestones for ETSI EN 319 401 *Timeline* Use timeline milestones to sequence policy, engineering, assurance, and reporting work. ## How to operationalize ETSI EN 319 401 *Decision Flow* Use the decision flow to convert applicability and requirement questions into clear actions. *Next step* ## Turn ETSI EN 319 401 Implementation Guide into an operational assessment workflow ETSI EN 319 401 Implementation Guide should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from ETSI EN 319 401 Implementation Guide and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for ETSI EN 319 401 Implementation Guide. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through ETSI EN 319 401 Implementation Guide](/contact.md): Review your current process, evidence model, and next steps for ETSI EN 319 401 Implementation Guide. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-401 --- --- title: "ETSI EN 319 411-1 V1.5.1 Certificate Issuance Standard (CP/CPS, Identity Validation, Revocation)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1" author: "Sorena AI" description: "ETSI EN 319 411-1 V1.5.1 implementation guide for Trust Service Providers issuing certificates: CP vs CPS, policy OIDs, repository duties." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 319 411-1" - "ETSI EN 319 411-1 V1.5.1" - "ETSI EN 319 411-1 requirements" - "certificate policy CP" - "certification practice statement CPS" - "CP vs CPS" - "PKI disclosure statement" - "certificate issuance requirements" - "identity validation" - "re-key requests" - "revocation requests" - "certificate revocation and suspension" - "OCSP requirements" - "CRL requirements" - "certificate status service 24/7" - "audit logging" - "records archival" - "retention seven years" - "trust service provider issuing certificates" - "TLS certificate policy OID" - "EN 319 403-1" - "eIDAS trust services" - "Certification Practice Statement" - "Certificate Policy" - "Revocation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 411-1 V1.5.1 Certificate Issuance Standard (CP/CPS, Identity Validation, Revocation) ETSI EN 319 411-1 V1.5.1 implementation guide for Trust Service Providers issuing certificates: CP vs CPS, policy OIDs, repository duties. ![ETSI EN 319 411 1 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-etsi-en-319-411-1-small.jpg?v=cheatsheets%2Fprod) *ETSI EN 319 411 1* *Free Resource* ## ETSI EN 319 411 1 Implementation Guide A practical certificate issuance playbook for Trust Service Providers grounded in ETSI EN 319 411-1 V1.5.1: CP/CPS and PKI disclosures, identity validation, certificate lifecycle operations, revocation and status services, and audit-ready evidence you can reuse. Grounded in the April 2025 edition adopted on 24 March 2025. Validate final scoping against ETSI EN 319 401, EN 319 403-1, and any applicable eIDAS or CA Browser Forum obligations. [Start with CP/CPS requirements](/artifacts/global/etsi-en-319-411-1/requirements.md) ## What you can decide faster - **CP vs CPS**: Define what you commit to (CP) vs how you operate it (CPS) without oversharing sensitive internals. - **Identity validation**: Design identity proofing and authentication flows for issuance, re-key, and revocation requests. - **Revocation & status**: Operationalize revocation decisions and 24/7 status services (OCSP/CRL) with consistent evidence. Grounded in ETSI PDFs | V1.5.1 current edition | No signup required ### Quick scan *Artifact* - **Current edition**: V1.5.1 was published on 7 April 2025 after ETSI adoption on 24 March 2025. - **Documentation and controls**: CP, CPS, terms and conditions, PKI disclosure, identity validation, status services, and evidence retention all have to line up. - **Assessment path**: Use the topic guides to prepare operations and evidence for EN 319 403-1 style conformity assessment. Use the guide and subpages to turn ETSI EN 319 411-1 V1.5.1 into operating controls, relying-party disclosures, and defensible certificate evidence. | Value | Metric | | --- | --- | | V1.5.1 | Edition | | 2025-04-07 | Published | | 3 | Guides | | EN 319 403-1 | Assessment | **Key highlights:** Version verified | Plan controls | Track evidence ## Topic Guides - [ETSI EN 319 411-1 V1.5.1 Compliance Playbook (CA and TSP Certificate Issuance Operations)](/artifacts/global/etsi-en-319-411-1/compliance.md): How to operationalize ETSI EN 319 411-1 V1.5.1 for certificate issuing Trust Service Providers: CP and CPS governance, repository duties. - [ETSI EN 319 411-1 V1.5.1 FAQ (CP vs CPS, TLS Policies, Revocation, OCSP/CRL)](/artifacts/global/etsi-en-319-411-1/faq.md): Answering real-world questions about ETSI EN 319 411-1 V1.5.1: CP vs CPS, policy families, identity validation, repository duties, revocation. - [ETSI EN 319 411-1 V1.5.1 Requirements (CP/CPS, Identity Validation, Revocation, OCSP/CRL)](/artifacts/global/etsi-en-319-411-1/requirements.md): ETSI EN 319 411-1 V1.5.1 requirements map for Trust Service Providers issuing certificates: CP vs CPS, policy OIDs, repository duties, identity validation. ## Key milestones for ETSI EN 319 411 1 *Timeline* Use timeline milestones to sequence policy, engineering, assurance, and reporting work. ## How to operationalize ETSI EN 319 411 1 *Decision Flow* Use the decision flow to convert applicability and requirement questions into clear actions. *Next step* ## Turn ETSI EN 319 411 1 Implementation Guide into an operational assessment workflow ETSI EN 319 411 1 Implementation Guide should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into Research Copilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from ETSI EN 319 411 1 Implementation Guide and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for ETSI EN 319 411 1 Implementation Guide. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs from the same artifact. - [Talk through ETSI EN 319 411 1 Implementation Guide](/contact.md): Review your current process, evidence model, and next steps for ETSI EN 319 411 1 Implementation Guide. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-411-1 --- --- title: "ETSI EN 319 411-2 V2.6.1 EU Qualified Certificates (QCP, QEVCP, QNCP, QSCD, eIDAS)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-2" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-2" author: "Sorena AI" description: "ETSI EN 319 411-2 V2.6.1 implementation guide for EU qualified certificates: qualified policy OIDs, identity verification, QSCD boundaries." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 319 411-2" - "ETSI EN 319 411-2 V2.6.1" - "EU qualified certificates requirements" - "qualified trust service provider" - "QCP-n QCP-l" - "QCP-n-qscd QCP-l-qscd" - "QEVCP-w" - "QNCP-w" - "QNCP-w-gen" - "qualified website authentication certificate" - "QSCD requirements" - "subject sole control" - "subscriber obligations QSCD" - "identity verification natural person legal person" - "revocation status services OCSP CRL 24/7" - "eIDAS Article 19 24 28 38 45" - "qualified certificate policy identifier OID" - "EU trusted list validation" - "ETSI TS 119 615" - "ETSI EN 319 411-1 mapping" - "EU qualified certificates" - "QSCD" - "eIDAS" - "Trusted Lists" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 411-2 V2.6.1 EU Qualified Certificates (QCP, QEVCP, QNCP, QSCD, eIDAS) ETSI EN 319 411-2 V2.6.1 implementation guide for EU qualified certificates: qualified policy OIDs, identity verification, QSCD boundaries. ![ETSI EN 319 411 2 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-etsi-en-319-411-2-small.jpg?v=cheatsheets%2Fprod) *ETSI EN 319 411 2* *Free Resource* ## ETSI EN 319 411 2 Implementation Guide A practical guide for issuing EU qualified certificates under eIDAS grounded in ETSI EN 319 411-2 V2.6.1: choose the right qualified policy OID, implement QSCD-related controls, verify identities correctly, and keep audit-ready evidence. Grounded in the June 2025 edition adopted on 3 June 2025 and published by ETSI on 6 June 2025. The current edition aligns EN 319 411-2 with updated eIDAS and EN 319 411-1 context. [Start with policy OIDs + QSCD requirements](/artifacts/global/etsi-en-319-411-2/requirements.md) ## What you can decide faster - **Which policy to assert**: Pick the correct qualified certificate policy identifier (QCP/QEVCP/QNCP) for your service. - **QSCD boundaries**: Define who controls the private key, when QSCD is required, and how obligations flow to subscriber/TSP. - **Relying party proof**: Build evidence for identity verification, issuance, revocation/status services, and qualified service listing. Grounded in ETSI PDFs | V2.6.1 current edition | No signup required ### Quick scan *Artifact* - **Current edition**: V2.6.1 was adopted on 3 June 2025 and published by ETSI on 6 June 2025. - **Qualified status evidence**: Policy OIDs alone are not enough. QTSP, trusted-list, and QCStatement evidence have to line up for relying parties. - **Operational focus**: The topic guides cover identity verification, QSCD boundaries, trusted-list validation, revocation, and evidence retention. Use the guide and subpages to turn EN 319 411-2 V2.6.1 into qualified-certificate controls, trusted-list proof, and defensible relying-party evidence. | Value | Metric | | --- | --- | | V2.6.1 | Edition | | 2025-06-06 | Published | | 3 | Guides | | EU TL | Validation | **Key highlights:** Version verified | Map OIDs | Prove qualified status ## Topic Guides - [ETSI EN 319 411-2 V2.6.1 Compliance Playbook (EU Qualified Certificates and QSCD Operations)](/artifacts/global/etsi-en-319-411-2/compliance.md): How to operationalize ETSI EN 319 411-2 V2.6.1 for EU qualified certificates: policy OID governance, CP and CPS disclosures, identity verification workflows. - [ETSI EN 319 411-2 V2.6.1 FAQ (EU Qualified Certificates, QCP, QNCP, QEVCP, QSCD)](/artifacts/global/etsi-en-319-411-2/faq.md): Frequently asked questions about ETSI EN 319 411-2 V2.6.1 for qualified trust service providers: policy OIDs, QSCD requirements, trusted-list validation. - [ETSI EN 319 411-2 V2.6.1 Requirements (EU Qualified Certificates, QCP, QEVCP, QNCP, QSCD)](/artifacts/global/etsi-en-319-411-2/requirements.md): ETSI EN 319 411-2 V2.6.1 requirements map for EU qualified certificates under eIDAS: qualified policy OIDs, identity verification, QSCD obligations. ## Key milestones for ETSI EN 319 411 2 *Timeline* Use timeline milestones to sequence policy, engineering, assurance, and reporting work. ## How to operationalize ETSI EN 319 411 2 *Decision Flow* Use the decision flow to convert applicability and requirement questions into clear actions. *Next step* ## Turn ETSI EN 319 411 2 Implementation Guide into an operational assessment workflow ETSI EN 319 411 2 Implementation Guide should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into Research Copilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from ETSI EN 319 411 2 Implementation Guide and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for ETSI EN 319 411 2 Implementation Guide. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs from the same artifact. - [Talk through ETSI EN 319 411 2 Implementation Guide](/contact.md): Review your current process, evidence model, and next steps for ETSI EN 319 411 2 Implementation Guide. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-411-2 --- --- title: "ETSI Standards Hub (EN 303 645 V3.1.3, TS 103 701, EN 319 401, EN 319 411)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-standards-hub" source_url: "https://www.sorena.io/artifacts/global/etsi-standards-hub" author: "Sorena AI" description: "A practical hub for ETSI cybersecurity standards using the current ETSI editions: EN 303 645 V3.1.3 and TS 103 701 V2.1.1 for consumer IoT." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI standards hub" - "ETSI cybersecurity standards" - "ETSI EN 303 645 V3.1.3" - "ETSI TS 103 701 V2.1.1" - "ETSI EN 319 401 V3.1.1" - "ETSI EN 319 411-1 V1.5.1" - "ETSI EN 319 411-2 V2.6.1" - "ETSI consumer IoT security baseline" - "ETSI trust service provider requirements" - "ETSI certificate policy requirements" - "ETSI evidence pack" - "ETSI standards selection guide" - "ETSI standards" - "ETSI EN 303 645" - "ETSI EN 319 401" - "ETSI EN 319 411" - "Trust service provider" - "Consumer IoT security" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI Standards Hub (EN 303 645 V3.1.3, TS 103 701, EN 319 401, EN 319 411) A practical hub for ETSI cybersecurity standards using the current ETSI editions: EN 303 645 V3.1.3 and TS 103 701 V2.1.1 for consumer IoT. ![ETSI Standards Hub artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-etsi-standards-hub-small.jpg?v=cheatsheets%2Fprod) *ETSI Standards Hub* *Free Resource* ## ETSI Standards Hub ETSI Cybersecurity Standards Use this hub to navigate ETSI cybersecurity standards and turn them into controls, tests, and evidence. The focus is practical: choose the right current ETSI standard for your product or trust service, then build an audit-ready implementation plan. This hub pins the current editions used across the linked guides, including EN 303 645 V3.1.3, TS 103 701 V2.1.1, EN 319 401 V3.1.1, EN 319 411-1 V1.5.1, and EN 319 411-2 V2.6.1. [Jump to guides](#topics) ## What you can do here - **Choose the right ETSI standard**: Pick the right ETSI standard for consumer IoT security, trust services, or certificate policy and assurance. - **Map requirements to work**: Convert clauses into owned controls, test plans, and release gates your teams can execute. - **Build evidence that audits accept**: Create an evidence pack that is attributable, current, and traceable to ETSI requirements and assurance questions. Current editions pinned | Grounded in ETSI sources | No signup required ### Fast navigation *Hub* - **Consumer IoT stack**: EN 303 645 V3.1.3 sets the baseline and TS 103 701 V2.1.1 provides the current conformance-assessment method. - **Trust-service stack**: EN 319 401 V3.1.1 covers TSP governance, while EN 319 411-1 V1.5.1 and EN 319 411-2 V2.6.1 cover certificate issuance. - **Selection logic**: Choose by object of assurance first: consumer IoT product, trust service provider, or certificate issuance and qualified status. Use the guides below to select the right current ETSI standard, then translate it into controls, testing, and evidence. | Value | Metric | | --- | --- | | 5 | Core docs | | 2025 | Latest updates | | 4 | Guides | | ETSI | Focused | **Key highlights:** Pin versions | Choose standard | Prove compliance ## Topic Guides - [Choose the Right ETSI Standard (EN 303 645 V3.1.3, TS 103 701, EN 319 401, EN 319 411)](/artifacts/global/etsi-standards-hub/choose-the-right-etsi-standard.md): A practical decision guide to choose the right ETSI cybersecurity standard by product versus service scope and assurance objective. - [ETSI Standards FAQ (Current EN 303 645, TS 103 701, EN 319 401, EN 319 411)](/artifacts/global/etsi-standards-hub/faq.md): ETSI standards FAQ for security, product, and assurance teams: current ETSI editions, how EN 303 645 and TS 103 701 relate, what EN 319 401 covers. - [ETSI vs ISO for Cybersecurity Standards: When to Use Each](/artifacts/global/etsi-standards-hub/etsi-vs-iso.md): ETSI vs ISO explained for cybersecurity and assurance teams using current ETSI examples such as EN 303 645 V3.1.3, TS 103 701 V2.1.1, EN 319 401 V3.1.1. - [What Is Included in ETSI Standards Hub (Current IoT and Trust Services Stack)](/artifacts/global/etsi-standards-hub/what-is-included.md): A coverage map of the ETSI cybersecurity standards included in this hub using current editions: EN 303 645 V3.1.3, TS 103 701 V2.1.1, EN 319 401 V3.1.1. ## Explore ETSI guides *Guides* Use the guides to select the right ETSI standard and build an evidence-driven implementation plan. ## Navigate and apply ETSI standards *Navigation* Use the hub and topic guides to translate ETSI requirements into controls, tests, and audit-ready evidence. *Next step* ## Turn ETSI Standards Hub ETSI Cybersecurity Standards into a cited research workflow ETSI Standards Hub ETSI Cybersecurity Standards should be the shared entry point for your team. Route execution into Research Copilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from ETSI Standards Hub ETSI Cybersecurity Standards and route the work by entity, product, team, or control owner. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs for ETSI Standards Hub ETSI Cybersecurity Standards. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through ETSI Standards Hub ETSI Cybersecurity Standards](/contact.md): Review your current process, evidence model, and next steps for ETSI Standards Hub ETSI Cybersecurity Standards. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-standards-hub --- --- title: "FIPS 140-3 (CMVP Cryptographic Module Validation, Approved Mode, Transition)" canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3" source_url: "https://www.sorena.io/artifacts/global/fips-140-3" author: "Sorena AI" description: "Practical FIPS 140-3 guidance for CMVP cryptographic module validation: security levels, module boundary, approved mode, transition timing, documentation." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "FIPS 140-3" - "FIPS 140-3 compliance" - "CMVP" - "cryptographic module validation" - "FIPS 140-3 validation checklist" - "FIPS 140-3 security levels" - "cryptographic module boundary" - "approved mode of operation" - "FIPS 140-3 security policy" - "NIST CMVP" - "NVLAP CSTL" - "FIPS 140-2 transition 2026" - "Cryptographic boundary" - "Security levels" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FIPS 140-3 (CMVP Cryptographic Module Validation, Approved Mode, Transition) Practical FIPS 140-3 guidance for CMVP cryptographic module validation: security levels, module boundary, approved mode, transition timing, documentation. ![FIPS 140-3 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-fips-140-3-small.jpg?v=cheatsheets%2Fprod) *FIPS 140-3* *Free Resource* ## FIPS 140-3 Cryptographic Module Validation Use these guides to plan a defensible FIPS 140-3 validation: define the module boundary, choose the right security level, map services to approved security functions, and build the documentation and evidence a CST laboratory and the CMVP will actually use. Grounded in FIPS 140-3, the CMVP program pages, the current FIPS 140-3 Management Manual, and current Implementation Guidance. FIPS 140-2 active modules remain usable for new systems only through 21 September 2026. [Jump to guides](#topics) ## What this artifact helps you do - **Define the cryptographic boundary**: Draw the module boundary correctly so test scope, interfaces, and evidence remain consistent. - **Build an approved-mode story**: Map services, algorithms, self-tests, and indicators so approved mode is provable. - **Prepare the validation evidence pack**: Deliver a security policy and test evidence that a CSTL can execute without rework loops. Grounded in official NIST and CCCS sources | Current CMVP transition dates | No signup required ### Quick start *FIPS 140-3* - **Current program state**: FIPS 140-3 validations are the live path. FIPS 140-2 active modules remain usable for new systems only through 21 September 2026. - **Where teams fail**: Most validation delays come from boundary drift, weak service maps, and approved-mode claims that do not match the Security Policy. - **What current work depends on**: You need the base standard, the SP 800-140 series, the current Management Manual, and the current Implementation Guidance revision. FIPS 140-3 success depends on boundary discipline, current-program awareness, and evidence traceability. These guides focus on those practical failure points. | Value | Metric | | --- | --- | | 5 | Guides | | 4 | Levels | | 11 | Areas | | 2026-09-21 | 140-2 active | **Key highlights:** Define boundary | Map services | Prove approved mode ## Topic Guides - [FIPS 140-3 Compliance (CMVP Validation Playbook, Approved Mode, Transition)](/artifacts/global/fips-140-3/compliance.md): A practical FIPS 140-3 compliance and validation playbook for CMVP cryptographic module validation: boundary, security level selection, approved mode. - [FIPS 140-3 FAQ (CMVP Validation, Approved Mode, Embedded Modules, Transition)](/artifacts/global/fips-140-3/faq.md): FIPS 140-3 FAQ for cryptographic module teams: what FIPS 140-3 covers, how CMVP validation works, what approved mode means. - [FIPS 140-3 Module Boundary and Services Mapping (Approved Mode, Embedded Modules)](/artifacts/global/fips-140-3/module-boundary-and-service-mapping.md): Advanced guide to FIPS 140-3 cryptographic module boundary definition and services mapping: boundary diagrams, approved-mode indicators, SSP access. - [FIPS 140-3 Security Levels (Level 1 to Level 4) Explained](/artifacts/global/fips-140-3/security-levels-explained.md): FIPS 140-3 security levels explained: what Level 1, Level 2, Level 3, and Level 4 mean, how they affect boundary and deployment assumptions. - [FIPS 140-3 Validation Checklist (CMVP Lab Readiness, Approved Mode, Transition)](/artifacts/global/fips-140-3/fips-140-3-validation-checklist.md): A practical FIPS 140-3 validation checklist for CMVP lab readiness: boundary, services, approved mode, documentation, self-tests, SSP management. ## Explore FIPS 140-3 guides *Guides* Use these subpages for implementation deep dives: compliance, checklist, boundary mapping, security levels, and FAQ. ## How to execute FIPS 140-3 *Navigation* Use the guides to translate FIPS 140-3 requirement areas into owned controls, current-program decisions, and lab-ready evidence. *Next step* ## Turn FIPS 140-3 Cryptographic Module Validation into an operational assessment workflow FIPS 140-3 Cryptographic Module Validation should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into Research Copilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from FIPS 140-3 Cryptographic Module Validation and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for FIPS 140-3 Cryptographic Module Validation. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs from the same artifact. - [Talk through FIPS 140-3 Cryptographic Module Validation](/contact.md): Review your current process, evidence model, and next steps for FIPS 140-3 Cryptographic Module Validation. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-140-3 --- --- title: "FIPS Crypto Algorithms (AES, SHA, Signatures, PQC)" canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms" source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms" author: "Sorena AI" description: "A practical hub for FIPS cryptographic algorithms used in products and FIPS 140-3 validations: AES, secure hash, digital signatures." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "FIPS crypto algorithms" - "FIPS approved algorithms" - "AES FIPS 197" - "SHA-2 FIPS 180-4" - "SHA-3 FIPS 202" - "FIPS 186-5" - "FIPS 203" - "FIPS 204" - "FIPS 205" - "FIPS 140-3 approved security functions" - "crypto agility" - "cryptographic inventory" - "FIPS cryptographic algorithms" - "AES" - "SHA-2" - "SHA-3" - "Digital signatures" - "Post-quantum cryptography" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FIPS Crypto Algorithms (AES, SHA, Signatures, PQC) A practical hub for FIPS cryptographic algorithms used in products and FIPS 140-3 validations: AES, secure hash, digital signatures. ![FIPS crypto algorithms artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-fips-crypto-algorithms-small.jpg?v=cheatsheets%2Fprod) *FIPS Crypto Algorithms* *Free Resource* ## FIPS Crypto Algorithms Implementation Hub Use this hub to understand what each FIPS crypto standard actually specifies and how to implement it in real systems. The focus is practical engineering and assurance: algorithm selection, safe defaults, interoperability, and evidence that can support FIPS 140-3 approved-mode claims. Grounded in FIPS 197 upd1, FIPS 180-4, FIPS 202, FIPS 186-5, and the August 13, 2024 PQC FIPS releases: FIPS 203, FIPS 204, and FIPS 205. [Jump to guides](#topics) ## What you can do here - **Choose the right algorithm family**: Pick AES, SHA-2, SHA-3, classic signatures, or PQC based on protocol and assurance requirements. - **Implement with safe constraints**: Avoid common failures such as weak mode choices, digest drift, key-purpose reuse, and uncontrolled PQC negotiation. - **Prepare evidence that survives review**: Build inventories, configuration manifests, test artifacts, and source links that support security reviews and module validation. Grounded in NIST primary sources | Current PQC FIPS releases | No signup required ### Coverage *FIPS* - **AES**: FIPS 197 defines AES-128, AES-192, and AES-256 and requires use with a FIPS-approved or NIST-recommended mode of operation. - **Secure hash**: FIPS 180-4 and FIPS 202 together cover SHA-2, SHA-3, and approved XOFs such as SHAKE128 and SHAKE256. - **Signatures and PQC**: FIPS 186-5 covers RSA, ECDSA, deterministic ECDSA, and EdDSA. FIPS 203, 204, and 205 add ML-KEM, ML-DSA, and SLH-DSA. FIPS algorithm work is easiest when you treat it as a system: inventory, selection, implementation, verification, and controlled evidence. | Value | Metric | | --- | --- | | 5 | Guides | | 2023-05-09 | AES upd1 | | 2023-02-03 | DSS | | 2024-08-13 | PQC FIPS | **Key highlights:** Inventory | Safe defaults | Evidence ## Topic Guides - [AES (FIPS 197) - How to Use AES Safely](/artifacts/global/fips-crypto-algorithms/aes-fips-197.md): Advanced implementation guide for AES under FIPS 197 upd1: AES-128, AES-192, AES-256, approved modes. - [Digital Signatures (FIPS 186-5 DSS and FIPS 204 ML-DSA)](/artifacts/global/fips-crypto-algorithms/digital-signatures-fips-186-5-and-fips-204.md): Advanced guide to FIPS digital signatures: RSA, ECDSA, deterministic ECDSA, EdDSA, and post-quantum ML-DSA. - [FIPS Crypto Algorithms FAQ (AES, SHA, Signatures, PQC)](/artifacts/global/fips-crypto-algorithms/faq.md): FAQ for FIPS crypto adoption: AES, SHA-2 and SHA-3, digital signatures, post-quantum standards. - [Post-Quantum Cryptography (FIPS 203, 204, 205) - Migration Guide](/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205.md): Practical post-quantum cryptography migration guidance grounded in FIPS 203, FIPS 204, and FIPS 205. - [Secure Hash (FIPS 180-4 SHA-2, FIPS 202 SHA-3, SHAKE)](/artifacts/global/fips-crypto-algorithms/secure-hash-fips-180-4-and-fips-202.md): Deep guide to FIPS secure hash standards: SHA-2 under FIPS 180-4 and SHA-3 plus SHAKE under FIPS 202. Learn digest selection, XOF rules, and evidence strategy. ## Explore FIPS crypto guides *Guides* Use the topic guides to implement, test, and evidence FIPS crypto algorithms in real systems. ## How to use FIPS crypto standards *Navigation* Pick the guide that matches your need: symmetric encryption, hashing, signatures, post-quantum migration, or FAQ. *Next step* ## Turn FIPS Crypto Algorithms Implementation Hub into a cited research workflow FIPS Crypto Algorithms Implementation Hub should be the shared entry point for your team. Route execution into Research Copilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from FIPS Crypto Algorithms Implementation Hub and route the work by entity, product, team, or control owner. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs for FIPS Crypto Algorithms Implementation Hub. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through FIPS Crypto Algorithms Implementation Hub](/contact.md): Review your current process, evidence model, and next steps for FIPS Crypto Algorithms Implementation Hub. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-crypto-algorithms --- --- title: "FIPS Standards Hub (FIPS 140-3, CMVP, FIPS Crypto)" canonical_url: "https://www.sorena.io/artifacts/global/fips-standards-hub" source_url: "https://www.sorena.io/artifacts/global/fips-standards-hub" author: "Sorena AI" description: "A practical hub for FIPS standards and NIST validation programs: FIPS 140-3 cryptographic module requirements, CMVP guidance." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "FIPS standards hub" - "FIPS 140-3" - "CMVP" - "cryptographic module validation program" - "FIPS approved algorithms" - "FIPS crypto algorithms" - "AES FIPS 197" - "SHA-2 FIPS 180-4" - "SHA-3 FIPS 202" - "FIPS 186-5" - "FIPS 203" - "FIPS 204" - "FIPS 205" - "approved mode of operation" - "cryptographic boundary" - "FIPS standards" - "Cryptographic module validation" - "Procurement" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FIPS Standards Hub (FIPS 140-3, CMVP, FIPS Crypto) A practical hub for FIPS standards and NIST validation programs: FIPS 140-3 cryptographic module requirements, CMVP guidance. ![FIPS standards hub artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-fips-standards-hub-small.jpg?v=cheatsheets%2Fprod) *FIPS Standards Hub* *Free Resource* ## FIPS Standards Hub Standards and Validation Reality Use this hub to navigate FIPS standards and the validation programs that make FIPS claims meaningful. The focus is practical: what the standard actually specifies, what evidence you must retain, and how to avoid procurement and audit confusion between algorithms, modules, and certificates. Grounded in FIPS 140-3, the CMVP program materials, the core FIPS crypto standards, and the related NIST cryptographic SP series used to apply them in practice. [Jump to guides](#topics) ## What this hub helps you do - **Separate algorithms from validation**: Stop mixing FIPS algorithms with FIPS 140-3 validated modules. They support different claims and different evidence. - **Build audit-ready evidence**: Create a traceable evidence pack around boundary, approved mode, services, tests, and change control. - **Choose the right assurance path**: Decide whether you need algorithm conformance evidence, module validation, product evaluation, or a combination. Grounded in official NIST sources | Current PQC FIPS coverage | No signup required ### Quick scan *Hub* - **FIPS 140-3 and CMVP**: Cryptographic module security requirements, validation flow, and common guidance-driven pitfalls. - **FIPS crypto algorithms**: AES, secure hash, digital signatures, and post-quantum standards used in real systems. - **Comparison pages**: Use them to separate standards from guidance and module validation from product evaluation. The highest-leverage deliverable is a boundary-to-evidence blueprint you can defend to auditors, labs, and procurement teams. | Value | Metric | | --- | --- | | 4 | Guides | | CMVP | Program | | FIPS | Standards | | Evidence | Focused | **Key highlights:** Boundary | Approved mode | Evidence ## Topic Guides - [FIPS Standards FAQ (Procurement, CMVP, Evidence)](/artifacts/global/fips-standards-hub/faq.md): FIPS Standards FAQ for procurement, compliance, and crypto-engineering teams: what FIPS-compliant means, FIPS algorithms versus FIPS 140-3 validated modules. - [FIPS vs Common Criteria (CC) - What to Validate vs Evaluate](/artifacts/global/fips-standards-hub/fips-vs-common-criteria.md): Deep comparison of FIPS, especially FIPS 140-3 and CMVP, versus Common Criteria: scope differences, evidence overlap, and when procurement requires both. - [FIPS vs NIST SP Series (Standards vs Cryptographic Guidance)](/artifacts/global/fips-standards-hub/fips-vs-nist-sp-series.md): Deep comparison of FIPS standards versus NIST Special Publications in the cryptographic ecosystem: how they differ, how they are used together. - [What Is Included in FIPS Standards Hub (FIPS 140-3, CMVP, FIPS Crypto)](/artifacts/global/fips-standards-hub/what-is-included.md): Coverage map for the FIPS Standards Hub: FIPS 140-3 cryptographic module requirements, CMVP context and guidance. ## Explore FIPS guides *Guides* Use the subpages for deep dives: what is included, FAQ, and comparisons that reduce procurement confusion. ## Navigate and apply FIPS standards *Navigation* Start with the coverage map, then use comparisons and FAQ to choose your evidence and validation path. *Next step* ## Turn FIPS Standards Hub Standards and Validation Reality into a cited research workflow FIPS Standards Hub Standards and Validation Reality should be the shared entry point for your team. Route execution into Research Copilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from FIPS Standards Hub Standards and Validation Reality and route the work by entity, product, team, or control owner. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs for FIPS Standards Hub Standards and Validation Reality. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through FIPS Standards Hub Standards and Validation Reality](/contact.md): Review your current process, evidence model, and next steps for FIPS Standards Hub Standards and Validation Reality. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-standards-hub --- --- title: "ISO 22301 Business Continuity Management System Guide" canonical_url: "https://www.sorena.io/artifacts/global/iso-22301" source_url: "https://www.sorena.io/artifacts/global/iso-22301" author: "Sorena AI" description: "Practical ISO 22301 guidance for a business continuity management system: BCMS scope, leadership, business impact analysis, risk assessment." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 22301" - "ISO 22301 standard" - "ISO 22301 requirements" - "ISO 22301 compliance" - "ISO 22301 certification" - "ISO 22301 audit" - "ISO 22301 implementation" - "business continuity management system" - "BCMS" - "business continuity" - "business impact analysis" - "continuity strategy" - "recovery planning" - "exercise programme" - "management review" - "operational resilience" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 22301 Business Continuity Management System Guide Practical ISO 22301 guidance for a business continuity management system: BCMS scope, leadership, business impact analysis, risk assessment. ![ISO 22301 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-iso-22301-small.jpg?v=cheatsheets%2Fprod) *ISO 22301* *Free Resource* ## ISO 22301 Business continuity management system Use these guides to implement ISO 22301 as an operating business continuity management system, not a document set. The standard's 2019 edition puts the continuity-specific work into Clause 8: business impact analysis, risk assessment, continuity strategies and solutions, business continuity plans and procedures, exercise programme, and evaluation of documentation and capabilities. This is a practical implementation resource, not legal advice. Validate certification and control decisions against the standard, official guidance, and your operating context. [Jump to guides](#topics) ## What this artifact helps you do - **Define BCMS scope and governance**: Set boundaries, interested parties, leadership ownership, objectives, and document control so the BCMS is both auditable and usable. - **Turn BIA into continuity decisions**: Use impact analysis and risk assessment to select continuity strategies, resource requirements, and recovery priorities. - **Prove the BCMS operates**: Run an exercise programme, evaluate plans and capabilities, then close findings through audit, management review, and corrective action. By Sorena AI | Updated 2026 | No signup required ### Quick start *ISO 22301* - **Second edition structure**: Published in 2019, with Clause 8 carrying the operational continuity work that teams need to implement and evidence. - **Implementation path**: Scope, leadership, BIA, risk assessment, strategies, plans, exercises, monitoring, audit, review, improvement. - **Companion guidance**: ISO 22313:2020 remains current and is the most useful public reference point for tailoring a BCMS approach. ISO 22301 works when business priorities, recovery assumptions, and exercise results are explicit and maintained under change. | Value | Metric | | --- | --- | | 5 | Guides | | 2019 | Edition | | Clause 8 | Operations | | 9 to 10 | Review loop | **Key highlights:** Define scope | Run BIA | Exercise plans ## Topic Guides - [ISO 22301 Business Impact Analysis Template](/artifacts/global/iso-22301/business-impact-analysis-template.md): Use this ISO 22301 business impact analysis template to capture prioritized activities, impact tolerances, dependencies, recovery targets. - [ISO 22301 Compliance Playbook](/artifacts/global/iso-22301/compliance.md): A practical ISO 22301 compliance playbook for implementing a business continuity management system: context, leadership, planning, support. - [ISO 22301 FAQ](/artifacts/global/iso-22301/faq.md): Direct answers to common ISO 22301 questions on BCMS scope, BIA, plans, exercises, certification, audit evidence. - [ISO 22301 Testing and Exercises](/artifacts/global/iso-22301/testing-and-exercises.md): Practical ISO 22301 testing and exercises guidance for designing an exercise programme, evaluating continuity documentation and capabilities. - [ISO 22301 vs DORA](/artifacts/global/iso-22301/iso-22301-vs-dora.md): Compare ISO 22301 and DORA to see where a business continuity management system supports digital operational resilience and where DORA adds binding ICT. ## Explore ISO 22301 guides *Guides* Use these subpages for the implementation playbook, BIA template, testing and exercises, FAQ, and ISO 22301 vs DORA mapping. ## How to implement a BCMS that holds up *Navigation* Use the guides to move from clause reading to owned controls, maintained plans, repeatable exercises, and an evidence set that stays current as the business changes. *Next step* ## Turn ISO 22301 Business continuity management system into an operational assessment workflow ISO 22301 Business continuity management system should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from ISO 22301 Business continuity management system and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for ISO 22301 Business continuity management system. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through ISO 22301 Business continuity management system](/contact.md): Review your current process, evidence model, and next steps for ISO 22301 Business continuity management system. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-22301 --- --- title: "ISO/IEC 27001:2022 ISMS Guide" canonical_url: "https://www.sorena.io/artifacts/global/iso-27001" source_url: "https://www.sorena.io/artifacts/global/iso-27001" author: "Sorena AI" description: "Practical ISO/IEC 27001:2022 guidance for implementing an information security management system: scope, risk assessment, risk treatment." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27001" - "ISO/IEC 27001:2022" - "ISO 27001 standard" - "ISO 27001 requirements" - "ISO 27001 compliance" - "ISO 27001 audit" - "ISO 27001 certification" - "ISO 27001 implementation" - "ISMS" - "Statement of Applicability" - "SoA" - "Annex A controls" - "risk treatment plan" - "residual risk acceptance" - "internal audit" - "management review" - "ISO/IEC 27001" - "Information security management system" - "Risk treatment" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO/IEC 27001:2022 ISMS Guide Practical ISO/IEC 27001:2022 guidance for implementing an information security management system: scope, risk assessment, risk treatment. ![ISO 27001 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-iso-27001-small.jpg?v=cheatsheets%2Fprod) *ISO 27001* *Free Resource* ## ISO/IEC 27001 ISMS implementation hub Use these guides to build an ISO/IEC 27001:2022 information security management system that survives audit sampling and real operational change. The 2022 edition keeps Clauses 4 to 10 as mandatory requirements, aligns the text with the harmonized management-system structure, and uses Annex A as the reference set for the current 93-control model aligned to ISO/IEC 27002:2022. This is practical implementation guidance, not legal advice. Validate final control and certification decisions against the standard, your accredited certification body, and your operating context. [Jump to guides](#topics) ## What this artifact helps you do - **Define a defensible ISMS scope**: Set boundaries, interested parties, interfaces, and dependencies so risk decisions and evidence stay consistent. - **Build a credible SoA and treatment plan**: Link risk treatment choices to Annex A comparison, implementation status, and residual risk acceptance. - **Operate the ISMS as a system**: Keep monitoring, internal audit, management review, and corrective action running on a repeatable cadence. By Sorena AI | Updated 2026 | No signup required ### Quick start *ISO 27001* - **Current edition**: Third edition published in October 2022, with Amendment 1 issued in 2024 and the 2013 transition period now closed. - **Reference controls**: Annex A now points to the 93-control reference structure aligned to ISO/IEC 27002:2022. - **Certification reality**: Auditors sample traceability, not just documents: scope, risk method, SoA, control evidence, audit results, and management review. ISO 27001 works when scope, risk criteria, control decisions, and review outputs stay aligned as the business changes. | Value | Metric | | --- | --- | | 6 | Guides | | 2022 | Edition | | 93 | Annex A refs | | 4 to 10 | Mandatory clauses | **Key highlights:** Define scope | Build SoA | Run reviews ## Topic Guides - [ISO 27001 Audit Readiness](/artifacts/global/iso-27001/audit-readiness.md): Prepare for ISO/IEC 27001 audits with a structured evidence pack, SoA traceability, internal audit and management review outputs. - [ISO 27001 Compliance Playbook](/artifacts/global/iso-27001/compliance.md): Implement ISO/IEC 27001:2022 with a practical ISMS playbook for scope, risk assessment, risk treatment, Statement of Applicability, Annex A alignment. - [ISO 27001 FAQ](/artifacts/global/iso-27001/faq.md): Clear answers to common ISO/IEC 27001:2022 questions on the Statement of Applicability, Annex A, risk treatment, certification, audit evidence. - [ISO 27001 Implementation Roadmap](/artifacts/global/iso-27001/implementation-roadmap.md): A practical ISO/IEC 27001:2022 implementation roadmap with phases, gates, scope decisions, risk and SoA milestones, control rollout priorities. - [ISO 27001 Requirements and Evidence](/artifacts/global/iso-27001/requirements.md): Understand ISO/IEC 27001:2022 requirements across Clauses 4 to 10, Annex A, risk treatment, and the Statement of Applicability. - [ISO 27001 vs NIS2](/artifacts/global/iso-27001/iso-27001-vs-nis2.md): See how ISO/IEC 27001:2022 supports NIS2 cybersecurity governance and where NIS2 adds legal obligations for incident reporting, supervision. ## Explore ISO 27001 guides *Guides* Use these subpages for compliance, requirements, implementation roadmap, audit readiness, FAQ, and ISO 27001 vs NIS2 mapping. ## How to run an ISMS that holds up *Navigation* Use the guides to translate ISO/IEC 27001 into owned decisions, controlled documentation, measurable controls, and evidence that remains usable after audits, incidents, and organizational change. *Next step* ## Turn ISO/IEC 27001 ISMS implementation hub into an operational assessment workflow ISO/IEC 27001 ISMS implementation hub should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from ISO/IEC 27001 ISMS implementation hub and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for ISO/IEC 27001 ISMS implementation hub. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through ISO/IEC 27001 ISMS implementation hub](/contact.md): Review your current process, evidence model, and next steps for ISO/IEC 27001 ISMS implementation hub. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27001 --- --- title: "ISO/IEC 27005:2022 Risk Management Guide" canonical_url: "https://www.sorena.io/artifacts/global/iso-27005" source_url: "https://www.sorena.io/artifacts/global/iso-27005" author: "Sorena AI" description: "Practical ISO/IEC 27005:2022 guidance for information security risk management: context, criteria, assessment, treatment, risk communication, monitoring." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27005" - "ISO/IEC 27005:2022" - "ISO 27005 risk management" - "ISO 27005 risk assessment" - "ISO 27005 risk treatment" - "risk acceptance criteria" - "risk communication" - "residual risk acceptance" - "risk treatment plan" - "ISO 27005 vs NIST 800-30" - "ISO 27001 risk management" - "ISO/IEC 27005" - "Information security risk management" - "Risk assessment" - "Risk owners" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO/IEC 27005:2022 Risk Management Guide Practical ISO/IEC 27005:2022 guidance for information security risk management: context, criteria, assessment, treatment, risk communication, monitoring. ![ISO 27005 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-iso-27005-small.jpg?v=cheatsheets%2Fprod) *ISO 27005* *Free Resource* ## ISO/IEC 27005 Risk management implementation hub Use these guides to build a repeatable information security risk process that supports ISO/IEC 27001 rather than sitting beside it. ISO/IEC 27005:2022 is Edition 4, published in October 2022, and it covers the full risk management cycle for information security: assessment, treatment, communication, monitoring, and review. This is practical implementation guidance, not legal advice. ISO 27005 is a guidance standard, so focus on decision quality, ownership, and evidence quality rather than on certificate theater. [Jump to guides](#topics) ## What this artifact helps you do - **Set explicit risk and acceptance criteria**: Define how risk is scored, what is acceptable, and who has authority to approve exceptions. - **Run consistent risk assessments**: Standardize identification, analysis, evaluation, and prioritization so results are comparable across teams. - **Turn risk into owned action**: Convert assessed risks into treatment plans, residual risk decisions, monitoring, and review cycles. By Sorena AI | Updated 2026 | No signup required ### Quick start *ISO 27005* - **Current edition**: Edition 4 of ISO/IEC 27005 was published in October 2022 and aligns the guidance to ISO/IEC 27001 and ISO 31000. - **What it is**: A guidance standard for information security risk management, not a certification standard on its own. - **What it covers**: Assessment, treatment, communication, monitoring, and review, with practical templates for assessments and treatment plans. ISO 27005 works when criteria, ownership, and follow-up are explicit enough that risk decisions can be defended months later. | Value | Metric | | --- | --- | | 5 | Guides | | 2022 | Edition | | Guide | Not certifiable | | Full cycle | Risk process | **Key highlights:** Define criteria | Assess risks | Treat and review ## Topic Guides - [ISO 27005 Compliance Playbook](/artifacts/global/iso-27005/compliance.md): Operationalize ISO/IEC 27005:2022 with a practical playbook for context, criteria, risk assessment, risk treatment, residual risk acceptance, communication. - [ISO 27005 FAQ](/artifacts/global/iso-27005/faq.md): Answers to common ISO/IEC 27005 questions on risk criteria, acceptance criteria, risk owners, treatment plans, residual risk, NIST comparisons. - [ISO 27005 Risk Assessment Template](/artifacts/global/iso-27005/risk-assessment-template.md): Use this ISO/IEC 27005 risk assessment template to capture context, criteria, scenario details, likelihood, consequence, uncertainty, risk owner, evaluation. - [ISO 27005 Risk Treatment Plan Template](/artifacts/global/iso-27005/risk-treatment-plan-template.md): Use this ISO/IEC 27005 risk treatment plan template to document treatment options, selected actions, owners, milestones, evidence links, acceptance criteria. - [ISO 27005 vs NIST SP 800-30](/artifacts/global/iso-27005/iso-27005-vs-nist-800-30.md): Compare ISO/IEC 27005 and NIST SP 800-30 to see how information security risk management guidance and risk assessment guidance fit together. ## Explore ISO 27005 guides *Guides* Use these subpages for the risk management playbook, FAQ, NIST comparison, and practical templates. ## How to run risk management that stays useful *Navigation* Use the guides to turn ISO 27005 concepts into a working risk model with explicit ownership, treatment choices, and review triggers that fit your ISMS. *Next step* ## Turn ISO/IEC 27005 Risk management implementation hub into an operational assessment workflow ISO/IEC 27005 Risk management implementation hub should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into Research Copilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from ISO/IEC 27005 Risk management implementation hub and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for ISO/IEC 27005 Risk management implementation hub. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs from the same artifact. - [Talk through ISO/IEC 27005 Risk management implementation hub](/contact.md): Review your current process, evidence model, and next steps for ISO/IEC 27005 Risk management implementation hub. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27005 --- --- title: "ISO/IEC 27017:2015 (Cloud Security Controls)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27017" source_url: "https://www.sorena.io/artifacts/global/iso-27017" author: "Sorena AI" description: "Practical ISO/IEC 27017 guidance for cloud security controls based on ISO/IEC 27002: shared responsibility model, cloud-specific implementation guidance." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27017" - "ISO/IEC 27017:2015" - "ISO 27017 cloud security controls" - "ISO 27017 shared responsibility model" - "cloud service provider controls" - "cloud service customer controls" - "ISO 27017 compliance" - "ISO 27017 audit" - "ISO 27017 checklist" - "ISO 27017 control mapping to ISO 27001" - "ISO 27017 vs ISO 27001" - "ISO 27017 vs ISO 27002" - "secure multi-tenancy" - "virtualization security" - "cloud logging and monitoring" - "cloud data deletion" - "ISO/IEC 27017" - "Cloud security controls" - "Shared responsibility model" - "Cloud service provider" - "Cloud service customer" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO/IEC 27017:2015 (Cloud Security Controls) Practical ISO/IEC 27017 guidance for cloud security controls based on ISO/IEC 27002: shared responsibility model, cloud-specific implementation guidance. ![ISO 27017 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-iso-27017-small.jpg?v=cheatsheets%2Fprod) *ISO 27017* *Free Resource* ## ISO/IEC 27017 Cloud security controls implementation hub Use these guides to implement cloud security controls based on ISO/IEC 27002 and the cloud-specific guidance in ISO/IEC 27017:2015. Define provider vs customer responsibilities in the agreement, strengthen virtualization and multi-tenancy security, document data location and jurisdictions, and build an evidence pack that supports audits and customer assurance. This is practical implementation guidance, not legal advice. Validate final decisions against primary sources and your operating context. [Jump to guides](#topics) ## What this artifact helps you do - **Define shared responsibility**: Turn provider-versus-customer ambiguity into a responsibility matrix and contract language that teams can operate. - **Implement cloud-specific controls**: Apply ISO/IEC 27017 guidance on multi-tenancy, virtualization, admin operations, logging, and data lifecycle controls. - **Build audit-ready evidence**: Collect the artifacts auditors and customers ask for: agreements, disclosures, procedures, logs, tests, and review records. By Sorena AI | Updated 2026 | No signup required ### Quick start *ISO 27017* - **Shared responsibility model**: A practical matrix for IaaS, PaaS, and SaaS, grounded in the requirement to agree and document roles and responsibilities. - **Cloud provider checklist**: Due diligence questions + evidence to request from CSPs and vendors. - **ISO 27001 mapping**: How to map ISO 27017 guidance and cloud-specific control themes into an ISO 27001 Statement of Applicability. ISO 27017 succeeds when roles, evidence, and cloud-specific operating controls are explicit. These guides focus on that reality. | Value | Metric | | --- | --- | | 5 | Guides | | Cloud | Focused | | Provider | Customer | | Evidence | Ready | **Key highlights:** Define responsibilities | Harden multi-tenancy | Prove with evidence ## Topic Guides - [ISO 27017 Cloud Provider Checklist (Due Diligence + Evidence)](/artifacts/global/iso-27017/cloud-provider-checklist.md): ISO/IEC 27017 cloud provider checklist for due diligence: what to ask, what evidence to request. - [ISO 27017 Compliance (Cloud Controls Implementation Playbook)](/artifacts/global/iso-27017/compliance.md): A practical ISO/IEC 27017 compliance playbook for cloud security controls: scope, shared responsibility, cloud-specific control implementation. - [ISO 27017 Control Mapping to ISO 27001 (SoA + Evidence)](/artifacts/global/iso-27017/control-mapping-to-iso-27001.md): How to map ISO/IEC 27017 cloud security guidance to an ISO/IEC 27001 ISMS: Statement of Applicability, control owners, shared responsibility. - [ISO 27017 FAQ (Cloud Security Controls, Audit, and Evidence)](/artifacts/global/iso-27017/faq.md): Frequently asked questions about ISO/IEC 27017: what it is, how it relates to ISO 27001 and ISO 27002, shared responsibility in cloud security. - [ISO 27017 Shared Responsibility Model (Provider vs Customer)](/artifacts/global/iso-27017/shared-responsibility-model.md): A practical ISO/IEC 27017 shared responsibility model for cloud services: who owns which security responsibilities in IaaS, PaaS, and SaaS. ## Explore ISO 27017 guides *Guides* Use these subpages for implementation deep dives: compliance, provider checklist, shared responsibility, ISO 27001 mapping, and FAQ. ## How to run cloud security controls that work *Navigation* ISO/IEC 27017 is practical when you translate cloud-sector guidance into owned controls, contract language, and evidence. Use these guides to build an operating model that providers and customers can both explain and audit. *Next step* ## Turn ISO/IEC 27017 Cloud security controls implementation hub into an operational assessment workflow ISO/IEC 27017 Cloud security controls implementation hub should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from ISO/IEC 27017 Cloud security controls implementation hub and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for ISO/IEC 27017 Cloud security controls implementation hub. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through ISO/IEC 27017 Cloud security controls implementation hub](/contact.md): Review your current process, evidence model, and next steps for ISO/IEC 27017 Cloud security controls implementation hub. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27017 --- --- title: "ISO/IEC 27018 (Public Cloud PII Processor Privacy Controls)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27018" source_url: "https://www.sorena.io/artifacts/global/iso-27018" author: "Sorena AI" description: "Practical ISO/IEC 27018 guidance for public cloud PII processors." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27018" - "ISO/IEC 27018" - "ISO/IEC 27018:2025" - "ISO 27018 public cloud PII processor" - "ISO 27018 cloud privacy controls" - "ISO 27018 subprocessor transparency" - "ISO 27018 breach notification" - "ISO 27018 disclosure requests" - "ISO 27018 deletion and return" - "ISO 27018 vendor contract requirements" - "ISO 27018 vs GDPR" - "Cloud privacy controls" - "Public cloud PII processor" - "Processor contract evidence" - "Subprocessor transparency" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO/IEC 27018 (Public Cloud PII Processor Privacy Controls) Practical ISO/IEC 27018 guidance for public cloud PII processors. ![ISO 27018 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-iso-27018-small.jpg?v=cheatsheets%2Fprod) *ISO 27018* *Free Resource* ## ISO/IEC 27018 Public cloud privacy controls for PII processors Use these guides to implement privacy controls for a public cloud service provider acting as a PII processor. Focus on customer instructions, controller versus processor boundaries, marketing restrictions, subprocessor transparency, legally binding disclosure requests, breach records, and deletion across production, backup, and business continuity environments. The current ISO listing shows ISO/IEC 27018:2025 as the active edition. The practical control themes here are grounded in the ISO/IEC 27018:2019 control model and should be validated against the current edition before adoption. [Jump to guides](#topics) ## What this artifact helps you do - **Define the processor boundary**: Separate processor activity under customer instruction from cloud provider activity where you act as a controller, such as account administration data. - **Turn privacy promises into controls**: Convert privacy commitments into contract clauses, runbooks, logging rules, deletion procedures, and customer communications. - **Build reusable customer evidence**: Prepare disclosure logs, breach records, subprocessor notices, country lists, and independent assurance evidence that can be reused across reviews. By Sorena AI | Updated 2026 | No signup required ### Quick start *ISO 27018* - **Compliance playbook**: Build operating procedures and evidence for a public cloud PII processor control set. - **Privacy control checklist**: Review purpose limitation, confidentiality, disclosure, breach, deletion, logging, and retention controls. - **Contract requirements**: Draft processor clauses for instructions, subprocessors, countries, notification, audit evidence, and termination handling. ISO 27018 works when the service agreement, the operating model, and the evidence pack all say the same thing. | Value | Metric | | --- | --- | | 5 | Guides | | PII | Focused | | Cloud | Processor | | Audit | Ready | **Key highlights:** Processor controls | Subprocessor notices | Deletion evidence ## Topic Guides - [ISO 27018 Compliance (Public Cloud PII Processor Playbook)](/artifacts/global/iso-27018/compliance.md): A practical ISO/IEC 27018 compliance playbook for public cloud PII processors. - [ISO 27018 FAQ (Public Cloud PII Processor Controls)](/artifacts/global/iso-27018/faq.md): Frequently asked questions about ISO/IEC 27018 for public cloud PII processors. - [ISO 27018 Privacy Control Checklist (Public Cloud PII Processor)](/artifacts/global/iso-27018/privacy-control-checklist.md): An ISO/IEC 27018 privacy control checklist for public cloud PII processors. - [ISO 27018 Vendor Contract Requirements (Processor Clauses and Evidence)](/artifacts/global/iso-27018/vendor-contract-requirements.md): Processor contract requirements based on ISO/IEC 27018 and GDPR. - [ISO 27018 vs GDPR (Processor Controls and Evidence Mapping)](/artifacts/global/iso-27018/iso-27018-vs-gdpr.md): Compare ISO/IEC 27018 and GDPR for cloud processor operations. ## Explore ISO 27018 guides *Guides* Use these subpages for implementation detail on compliance, privacy control review, processor contract requirements, GDPR mapping, and FAQ. ## How to run cloud processor privacy controls that hold up *Navigation* ISO/IEC 27018 becomes useful when you can prove that personal data is processed only under customer instructions, that subprocessor changes are transparent, that disclosure and breach events are logged and communicated, and that deletion or return is enforceable across the full service lifecycle. *Next step* ## Turn ISO/IEC 27018 Public cloud privacy controls for PII processors into an operational assessment workflow ISO/IEC 27018 Public cloud privacy controls for PII processors should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from ISO/IEC 27018 Public cloud privacy controls for PII processors and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for ISO/IEC 27018 Public cloud privacy controls for PII processors. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through ISO/IEC 27018 Public cloud privacy controls for PII processors](/contact.md): Review your current process, evidence model, and next steps for ISO/IEC 27018 Public cloud privacy controls for PII processors. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27018 --- --- title: "ISO/IEC 27035 (Information Security Incident Management)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27035" source_url: "https://www.sorena.io/artifacts/global/iso-27035" author: "Sorena AI" description: "Practical ISO/IEC 27035 guidance for incident management across the full series: Part 1 principles and process, Part 2 planning and preparation." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27035" - "ISO/IEC 27035" - "ISO 27035-1" - "ISO 27035-2" - "ISO 27035-3" - "incident management" - "incident response" - "information security incident management" - "incident coordinator" - "IMT" - "IRT" - "event report" - "incident management log" - "incident severity matrix" - "incident escalation matrix" - "ISO 27035 vs NIST 800-61r3" - "Incident response playbook" - "Severity and escalation" - "Audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO/IEC 27035 (Information Security Incident Management) Practical ISO/IEC 27035 guidance for incident management across the full series: Part 1 principles and process, Part 2 planning and preparation. ![ISO 27035 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-iso-27035-small.jpg?v=cheatsheets%2Fprod) *ISO 27035* *Free Resource* ## ISO/IEC 27035 Incident management implementation hub Use these guides to build an incident management capability that works in real operations and holds up in audits. Cover the full ISO/IEC 27035 series: Part 1 process and documentation, Part 2 planning and preparation, and Part 3 ICT incident response operations for triage, analysis, containment, eradication, and recovery. The current grounded series here is ISO/IEC 27035-1:2023, ISO/IEC 27035-2:2023, and ISO/IEC 27035-3:2020. These pages focus on the real operating details that teams usually miss: event report quality, incident logs, classification scales, external relationships, exercises, capability registers, and post-incident improvement. [Jump to guides](#topics) ## What this artifact helps you do - **Build the full capability**: Define policy, plan, team structure, support relationships, exercise cadence, and metrics so incident handling is not improvised. - **Run consistent response operations**: Use stable event reporting, classification, prioritization, triage, analysis, containment, eradication, and recovery methods. - **Prove what happened**: Maintain event reports, incident management logs, lessons learned, and improvement records that survive audit and regulator review. By Sorena AI | Updated 2026 | No signup required ### Quick start *ISO 27035* - **Compliance playbook**: Use the 2023 and 2020 series structure to build policy, plan, team roles, exercises, and evidence. - **Incident response playbook**: Execute reporting, triage, analysis, containment, eradication, recovery, and lessons learned with fewer handoff failures. - **Severity and escalation matrix**: Align prioritization to classification scales, business impact, and predetermined response time frames. ISO 27035 works when reporting, decision rights, and records are explicit enough to be used under pressure. | Value | Metric | | --- | --- | | 5 | Guides | | 2023 | Series Core | | Ops | Ready | | Evidence | Traceable | **Key highlights:** IMT and IRT | Event reports | Lessons learned ## Topic Guides - [ISO 27035 Compliance (Incident Management Operating Model)](/artifacts/global/iso-27035/compliance.md): A practical ISO/IEC 27035 compliance playbook for incident management. - [ISO 27035 FAQ (Incident Management, Team Roles, and Evidence)](/artifacts/global/iso-27035/faq.md): Frequently asked questions about ISO/IEC 27035. Understand the 2023 series structure, IMT and IRT roles, event report forms, incident logs, prioritization. - [ISO 27035 Incident Response Playbook (Roles, Forms, and Operations)](/artifacts/global/iso-27035/incident-response-playbook.md): A practical ISO/IEC 27035 incident response playbook that covers event reporting, triage, analysis, containment, eradication, recovery, communications. - [ISO 27035 Incident Severity and Escalation Matrix (Classification and Priority Template)](/artifacts/global/iso-27035/incident-severity-and-escalation-matrix.md): A grounded ISO/IEC 27035 severity and escalation matrix template for classification, evaluation, prioritization, predetermined response times. - [ISO 27035 vs NIST SP 800-61r3 (Incident Response Mapping)](/artifacts/global/iso-27035/iso-27035-vs-nist-800-61r3.md): Compare ISO/IEC 27035 and NIST SP 800-61r3 for incident response. ## Explore ISO 27035 guides *Guides* Use these subpages for grounded implementation detail on compliance, FAQ, playbooks, severity logic, and NIST comparison. ## How to run incident management that stays coherent under stress *Navigation* The series works best when Part 1 provides the process frame, Part 2 defines policy, teams, forms, external relationships, testing, and metrics, and Part 3 drives ICT response operations with disciplined triage, analysis, containment, eradication, and recovery. *Next step* ## Turn ISO/IEC 27035 Incident management implementation hub into an operational assessment workflow ISO/IEC 27035 Incident management implementation hub should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from ISO/IEC 27035 Incident management implementation hub and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for ISO/IEC 27035 Incident management implementation hub. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through ISO/IEC 27035 Incident management implementation hub](/contact.md): Review your current process, evidence model, and next steps for ISO/IEC 27035 Incident management implementation hub. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27035 --- --- title: "ISO/IEC 27036 (Supplier Relationships Security)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27036" source_url: "https://www.sorena.io/artifacts/global/iso-27036" author: "Sorena AI" description: "Practical ISO/IEC 27036 guidance for securing supplier relationships across the full series: overview and concepts (27036-1), requirements (27036-2)." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27036" - "ISO/IEC 27036" - "ISO 27036-1" - "ISO 27036-2" - "ISO 27036-3" - "ISO 27036-4" - "supplier relationship security" - "information security in supplier relationships" - "third party risk management" - "supplier assurance framework" - "procurement security requirements" - "supplier selection process" - "supplier agreement process" - "supplier relationship management process" - "supply chain security" - "ICT supply chain" - "indirect suppliers" - "subcontractors" - "contract security clauses" - "audit rights" - "cloud services supplier security" - "shared responsibility" - "multi-tenancy" - "ISO 27036 compliance" - "ISO 27001 supplier controls" - "ISO 27002 supplier relationship controls" - "Third-party risk management" - "Assurance evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO/IEC 27036 (Supplier Relationships Security) Practical ISO/IEC 27036 guidance for securing supplier relationships across the full series: overview and concepts (27036-1), requirements (27036-2). ![ISO 27036 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-iso-27036-small.jpg?v=cheatsheets%2Fprod) *ISO 27036* *Free Resource* ## ISO/IEC 27036 Supplier relationship security implementation hub Use these guides to secure supplier relationships end-to-end: define governance and risk criteria, tier suppliers, select suppliers with evidence-backed due diligence, build enforceable contract security clauses, manage indirect suppliers and subcontractors, and run ongoing assurance that produces auditable evidence across product, service, hardware, software, and cloud supply chains. The grounded series here is ISO/IEC 27036-1:2021, ISO/IEC 27036-2:2022, ISO/IEC 27036-3:2023, and ISO/IEC 27036-4:2016. Part 2 is the normative requirements part, while Part 3 and Part 4 add deeper guidance for ICT supply chains and cloud services. [Jump to guides](#topics) ## What this artifact helps you do - **Define supplier lifecycle security**: Operationalize supplier relationship planning, supplier selection, agreement requirements, and ongoing monitoring. - **Turn requirements into contracts**: Convert ISO 27036 requirements into contract security clauses with measurable obligations and evidence deliverables. - **Build audit-ready assurance**: Create an evidence pack: tiering, due diligence records, supplier monitoring, exceptions, and remediation tracking. By Sorena AI | Updated 2026 | No signup required ### Quick start *ISO 27036* - **Compliance playbook**: How to operationalize ISO 27036 as a program across procurement and security. - **Contract clauses**: Clause patterns for supplier agreements, audits, subprocessors, and incident handling. - **Assurance framework**: Tiering and monitoring model with evidence requirements, supply chain depth, and cadence. ISO 27036 works when supplier expectations are explicit, enforceable, and evidenced. These guides focus on that reality. | Value | Metric | | --- | --- | | 5 | Guides | | TPRM | Focused | | Contracts | Enforced | | Evidence | Auditable | **Key highlights:** Tier suppliers | Bind contracts | Monitor evidence ## Topic Guides - [ISO 27036 Compliance (Supplier Relationship Security Program)](/artifacts/global/iso-27036/compliance.md): A practical ISO/IEC 27036 compliance playbook for supplier relationship security: governance, lifecycle processes (planning, selection, agreement. - [ISO 27036 Contract Security Clauses (Supplier Agreements + Cloud)](/artifacts/global/iso-27036/contract-security-clauses.md): A practical ISO/IEC 27036 contract clause pack: supplier agreement requirements, audit and assurance evidence, subcontractor visibility. - [ISO 27036 FAQ (Supplier Security, Indirect Suppliers, Cloud Supply Chain)](/artifacts/global/iso-27036/faq.md): ISO/IEC 27036 FAQ for third-party risk management (TPRM): which parts to use across 27036-1, 27036-2, 27036-3, and 27036-4, supplier relationship life cycle. - [ISO 27036 Supplier Assurance Framework (Tiering, Evidence, Monitoring)](/artifacts/global/iso-27036/supplier-assurance-framework.md): Build an ISO/IEC 27036-aligned supplier assurance framework: tier suppliers, define supplier selection criteria and agreement requirements. - [ISO 27036 Third-Party Risk Checklist (Vendor Due Diligence + Monitoring)](/artifacts/global/iso-27036/third-party-risk-checklist.md): An ISO/IEC 27036-aligned third-party risk checklist: supplier tiering, vendor due diligence, supplier selection criteria, contract security clauses. ## Explore ISO 27036 guides *Guides* Use these subpages for implementation deep dives: compliance, contract clauses, supplier assurance framework, third-party risk checklist, and FAQ. ## How to run supplier security that scales *Navigation* ISO/IEC 27036 is practical when you treat supplier security as a lifecycle: plan and prepare internally, select suppliers based on risk, set agreement requirements, monitor and improve continuously, and manage indirect suppliers, hardware and software dependencies, and cloud supply chains with clarity on responsibilities and evidence. *Next step* ## Turn ISO/IEC 27036 Supplier relationship security implementation hub into an operational assessment workflow ISO/IEC 27036 Supplier relationship security implementation hub should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from ISO/IEC 27036 Supplier relationship security implementation hub and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for ISO/IEC 27036 Supplier relationship security implementation hub. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through ISO/IEC 27036 Supplier relationship security implementation hub](/contact.md): Review your current process, evidence model, and next steps for ISO/IEC 27036 Supplier relationship security implementation hub. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27036 --- --- title: "ISO/IEC 42001 (AI Management System)" canonical_url: "https://www.sorena.io/artifacts/global/iso-42001" source_url: "https://www.sorena.io/artifacts/global/iso-42001" author: "Sorena AI" description: "Practical ISO/IEC 42001 guidance to build an AI Management System that matches the standard as written: context and interested parties, role determination." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 42001" - "ISO/IEC 42001" - "ISO 42001 standard" - "ISO 42001 requirements" - "ISO 42001 compliance" - "ISO 42001 audit" - "ISO 42001 implementation" - "AI management system" - "AIMS" - "AI governance framework" - "AI policy" - "AI risk assessment" - "AI risk treatment" - "AI system impact assessment" - "Annex A controls" - "Annex B guidance" - "Annex C objectives" - "Annex D sectors" - "AI technical documentation" - "event logs" - "supplier controls" - "ISO 42001 vs EU AI Act" - "AI governance" - "AI risk management" - "Global compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO/IEC 42001 (AI Management System) Practical ISO/IEC 42001 guidance to build an AI Management System that matches the standard as written: context and interested parties, role determination. ![ISO 42001 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-iso-42001-small.jpg?v=cheatsheets%2Fprod) *ISO/IEC 42001* *Free Resource* ## ISO/IEC 42001 AI management system (AIMS) implementation hub Use these guides to implement ISO/IEC 42001 as a real AI management system: determine your role for each AI system, define interested parties and AI policy, run AI risk assessment and treatment, perform AI system impact assessments, implement Annex A controls, and retain documented information that stands up in audits. Grounded to ISO/IEC 42001:2023, First edition 2023-12. The standard applies to organizations that develop, provide, or use AI systems and expects a risk-based approach that matches the organization context, intended purpose, and affected interested parties. [Jump to guides](#topics) ## What this artifact helps you do - **Build AI governance that scales**: Define AI policy, roles and responsibilities, and a governance model for AI systems across the lifecycle. - **Operationalize AI risk management**: Run AI risk assessment and treatment plus AI system impact assessment with repeatable evidence artifacts. - **Stay audit- and regulation-ready**: Create documented information, internal audit routines, and evidence packs that support ISO certification and AI Act readiness. By Sorena AI | Updated 2026 | No signup required ### Quick scan *ISO 42001* - **Requirements breakdown**: Clause-by-clause implementation guidance and evidence mapping. - **Controls + governance model**: Turn Annex A control objectives into accountable controls and operating routines. - **Topic guides**: Compliance playbook, EU AI Act mapping, and FAQ for real teams. ISO 42001 works when AI governance is explicit, evidenced, and continuously improved. These guides focus on implementation and audit-ready outcomes. | Value | Metric | | --- | --- | | 5 | Guides | | AIMS | Focused | | Evidence | Audit-ready | | AI Act | Mapped | **Key highlights:** AI policy | Risk treatment | Audit evidence ## Topic Guides - [ISO 42001 Compliance (AI Management System Playbook)](/artifacts/global/iso-42001/compliance.md): A practical ISO/IEC 42001 compliance playbook to implement an AI Management System (AIMS): scope, AI policy, roles and responsibilities. - [ISO 42001 Controls and Governance Model (Annex A + Operating Routines)](/artifacts/global/iso-42001/controls-and-governance-model.md): Turn ISO/IEC 42001 into an AI governance operating model: Annex A control objectives and controls, Annex B implementation guidance. - [ISO 42001 FAQ (AIMS, Risk Assessment, Impact Assessment, Audit)](/artifacts/global/iso-42001/faq.md): ISO/IEC 42001 FAQ for AI Management System (AIMS) implementation: what the standard covers, clause structure, Annex A controls. - [ISO 42001 Requirements (Clause-by-Clause Breakdown + Evidence)](/artifacts/global/iso-42001/requirements.md): An advanced ISO/IEC 42001 requirements breakdown: clauses 4-10 (context, leadership, planning, support, operation, performance evaluation, improvement). - [ISO 42001 vs EU AI Act (Mapping + Evidence Reuse)](/artifacts/global/iso-42001/iso-42001-vs-eu-ai-act.md): A practical ISO/IEC 42001 vs EU AI Act mapping: how an AI Management System (AIMS) supports AI Act obligations (risk management, data governance. ## Explore ISO 42001 guides *Guides* Use the subpages for implementation deep dives: compliance playbook, requirements breakdown, controls and governance model, EU AI Act mapping, and FAQ. ## How to run ISO 42001 as an operating system *Navigation* Treat ISO/IEC 42001 as a management system, not a model checklist: define context and scope, determine roles for the AI systems you develop, provide, or use, identify interested parties and their requirements, plan AI risk and impact activities, implement Annex A controls with Annex B guidance, evaluate performance, and improve continuously. *Next step* ## Turn ISO/IEC 42001 AI management system (AIMS) implementation hub into an operational assessment workflow ISO/IEC 42001 AI management system (AIMS) implementation hub should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into Research Copilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from ISO/IEC 42001 AI management system (AIMS) implementation hub and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for ISO/IEC 42001 AI management system (AIMS) implementation hub. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs from the same artifact. - [Talk through ISO/IEC 42001 AI management system (AIMS) implementation hub](/contact.md): Review your current process, evidence model, and next steps for ISO/IEC 42001 AI management system (AIMS) implementation hub. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-42001 --- --- title: "ISO Standards Hub (Cybersecurity, Privacy, Resilience)" canonical_url: "https://www.sorena.io/artifacts/global/iso-standards-hub" source_url: "https://www.sorena.io/artifacts/global/iso-standards-hub" author: "Sorena AI" description: "Choose the right ISO standard with grounded implementation context: ISO 27001 for ISMS governance, ISO 27005 for risk method, ISO 27017 and 27018 for cloud." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO standards hub" - "ISO cybersecurity standards" - "ISO compliance standards" - "ISO 27001" - "ISO 27005" - "ISO 27017" - "ISO 27018" - "ISO 27035" - "ISO 27036" - "ISO 22301" - "ISO 42001" - "choose ISO standard" - "ISO certification" - "ISO audit evidence" - "ISMS" - "third party risk management" - "supplier security" - "incident response standard" - "cloud security standard" - "business continuity standard" - "AI management system standard" - "ISO standards vs regulations" - "ISO standards mapping to NIS2 DORA GDPR EU AI Act" - "ISO standards" - "Cybersecurity standards" - "Information security management" - "Audit evidence" - "Global compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO Standards Hub (Cybersecurity, Privacy, Resilience) Choose the right ISO standard with grounded implementation context: ISO 27001 for ISMS governance, ISO 27005 for risk method, ISO 27017 and 27018 for cloud. ![ISO Standards Hub artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-iso-standards-hub-small.jpg?v=cheatsheets%2Fprod) *ISO Standards Hub* *Free Resource* ## ISO Standards Hub Choose the right ISO standard and build audit-ready evidence Use this hub to select and implement ISO standards with real outcomes: build an ISMS for certification, run a risk program, harden cloud security, mature incident response, secure supplier relationships, build business continuity, and implement AI governance with evidence that supports audits and customer assurance. This hub reflects the grounded state of the standards covered in this repo, including current-series realities such as ISO/IEC 27018:2025 on the ISO listing, the updated ISO/IEC 27035 and ISO/IEC 27036 multi-part series, and ISO/IEC 42001:2023 for AI management systems. [Jump to guides](#topics) ## What this hub helps you do - **Pick the right standard**: Choose the ISO standard that matches your objective (certification, risk, cloud, IR, supplier security, BC, AI). - **Implement controls that hold up**: Turn standard requirements into owners, routines, acceptance criteria, and measurable evidence. - **Build reusable evidence**: Create an evidence index that supports audits, customer assurance, and regulation readiness. By Sorena AI | Updated 2026 | No signup required ### Quick scan *ISO* - **What's included**: Coverage map of ISO standards and how they're used. - **Choose the right standard**: Decision guide by objective, risk, and operating context. - **Topic guides**: Deep guides for ISO 27001, 27005, 27017, 27018, 27035, 27036, 22301, and 42001. Standards work when they're operationalized: owners, cadence, evidence, and enforcement. This hub focuses on implementation, not generic summaries. | Value | Metric | | --- | --- | | 8 | Standards | | Audit | Evidence | | Cloud | Covered | | AI | Governed | **Key highlights:** Choose | Implement | Prove ## Topic Guides - [Choose the Right ISO Standard (27001, 27005, 27017, 27018, 27035, 27036, 22301, 42001)](/artifacts/global/iso-standards-hub/choose-the-right-standard.md): A practical decision guide to choose the right ISO standard by objective: ISMS certification (ISO 27001), risk management (ISO 27005). - [ISO Standards Hub FAQ (27001, 27005, 27017, 27018, 27035, 27036, 22301, 42001)](/artifacts/global/iso-standards-hub/faq.md): FAQ for ISO standards selection and implementation: what certification means, which standard to start with. - [ISO Standards vs Regulations (How to Combine Both)](/artifacts/global/iso-standards-hub/iso-standards-vs-regulations.md): Standards vs regulations explained: what ISO standards do (governance + controls + evidence) vs what laws require (scope + obligations + enforcement). - [What's Included in the ISO Standards Hub (Coverage + Bundles)](/artifacts/global/iso-standards-hub/what-is-included.md): Coverage map of key ISO standards for cybersecurity, privacy, resilience, and AI governance: ISO 27001, ISO 27005, ISO 27017, ISO 27018, ISO 27035, ISO 27036. ## Explore ISO Standards Hub guides *Guides* Use these subpages to navigate ISO standards, choose the right one, compare standards vs regulations, and learn what evidence to keep. ## How to use ISO standards in practice *Navigation* Start with the objective, then check the standard type. Some standards are management-system anchors used for certification or formal audit programs. Others are guidance-heavy multi-part standards that sharpen cloud, incident, supplier, or AI operating practices. Build one evidence index and reuse it across the bundle. *Next step* ## Turn ISO Standards Hub Choose the right ISO standard and build audit-ready evidence into a cited research workflow ISO Standards Hub Choose the right ISO standard and build audit-ready evidence should be the shared entry point for your team. Route execution into Research Copilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from ISO Standards Hub Choose the right ISO standard and build audit-ready evidence and route the work by entity, product, team, or control owner. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs for ISO Standards Hub Choose the right ISO standard and build audit-ready evidence. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through ISO Standards Hub Choose the right ISO standard and build audit-ready evidence](/contact.md): Review your current process, evidence model, and next steps for ISO Standards Hub Choose the right ISO standard and build audit-ready evidence. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-standards-hub --- --- title: "NIST Cybersecurity Framework (CSF) 2.0" canonical_url: "https://www.sorena.io/artifacts/global/nist-csf-2-0" source_url: "https://www.sorena.io/artifacts/global/nist-csf-2-0" author: "Sorena AI" description: "Practical NIST CSF 2.0 guidance grounded to NIST CSWP 29: GOVERN, the CSF Core, Organizational Profiles, Tiers, informative references." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST CSF 2.0" - "NIST Cybersecurity Framework 2.0" - "Cybersecurity Framework 2.0" - "NIST CSF GOVERN function" - "NIST CSF Core" - "NIST CSF Functions Govern Identify Protect Detect Respond Recover" - "NIST CSF Categories Subcategories" - "CSF Organizational Profile" - "CSF current profile" - "CSF target profile" - "current vs target profile template" - "CSF tiers" - "Tier 1 Partial" - "Tier 2 Risk Informed" - "Tier 3 Repeatable" - "Tier 4 Adaptive" - "cybersecurity risk governance" - "cybersecurity risk management" - "executive reporting" - "board metrics" - "informative references" - "implementation examples" - "NIST CSF vs ISO 27001" - "Cybersecurity framework" - "Cyber risk governance" - "Profiles and tiers" - "Global compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST Cybersecurity Framework (CSF) 2.0 Practical NIST CSF 2.0 guidance grounded to NIST CSWP 29: GOVERN, the CSF Core, Organizational Profiles, Tiers, informative references. ![NIST CSF 2.0 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-nist-csf-2-0-small.jpg?v=cheatsheets%2Fprod) *NIST CSF 2.0* *Free Resource* ## NIST CSF 2.0 Cyber risk governance and implementation hub Use these guides to implement NIST CSF 2.0 as a real operating model: establish GOVERN, build Current and Target Organizational Profiles, use Tiers to characterize rigor, prioritize gaps into an action plan, and report progress with metrics that executives and boards can understand. Grounded to NIST CSWP 29, published February 26, 2024. CSF 2.0 is designed for organizations of all sizes and sectors and is meant to be used with NISTs broader CSF portfolio of informative references, implementation examples, quick-start guides, and profile resources. [Jump to guides](#topics) ## What this artifact helps you do - **Build a governance-first program**: Use the new GOVERN function to connect cyber risk decisions to enterprise risk management and executive accountability. - **Turn outcomes into a roadmap**: Create Current/Target Profiles and convert gaps into prioritized work with owners and evidence. - **Report progress with metrics**: Build board-ready metrics and evidence that improves assurance and audit readiness. By Sorena AI | Updated 2026 | No signup required ### Quick scan *NIST CSF* - **Compliance playbook**: How to run CSF 2.0 as an operating model. - **Profiles template**: Current vs Target Profile workflow and template guidance. - **Topic guides**: Governance + metrics, FAQ, and CSF vs ISO 27001 comparison. NIST CSF 2.0 works when outcomes become ownership, cadence, and evidence. These guides focus on implementation and repeatability. | Value | Metric | | --- | --- | | 6 | Functions | | Profiles | Driven | | Tiers | Aligned | | Boards | Readable | **Key highlights:** GOVERN | Profiles | Tiers ## Topic Guides - [NIST CSF 2.0 Compliance Playbook (Profiles, Tiers, GOVERN)](/artifacts/global/nist-csf-2-0/compliance.md): A practical NIST CSF 2.0 compliance playbook: establish GOVERN, implement CSF Core outcomes, build Current and Target Organizational Profiles. - [NIST CSF 2.0 Current vs Target Profile Template (Step-by-Step)](/artifacts/global/nist-csf-2-0/current-vs-target-profile-template.md): How to build a NIST CSF 2.0 Current Profile and Target Profile: template columns, prioritization method, evidence mapping. - [NIST CSF 2.0 FAQ (Profiles, Tiers, GOVERN, Evidence)](/artifacts/global/nist-csf-2-0/faq.md): NIST CSF 2.0 FAQ: what changed in CSF 2.0 (GOVERN, supply chain focus), how to build Organizational Profiles, how to choose CSF Tiers. - [NIST CSF 2.0 Governance and Metrics (GOVERN + Board Reporting)](/artifacts/global/nist-csf-2-0/governance-and-metrics.md): How to operationalize the NIST CSF 2.0 GOVERN function: decision rights, risk acceptance, enterprise risk integration, supplier risk governance. - [NIST CSF 2.0 vs ISO 27001 (Mapping + How to Run Both)](/artifacts/global/nist-csf-2-0/nist-csf-vs-iso-27001.md): NIST CSF 2.0 vs ISO/IEC 27001 explained: outcomes framework vs certifiable management system. ## Explore NIST CSF 2.0 guides *Guides* Use these subpages for implementation deep dives: compliance playbook, current vs target profile template, governance and metrics, FAQ, and CSF vs ISO 27001. ## How to run NIST CSF 2.0 as a program *Navigation* Treat CSF 2.0 as an outcomes-based program: use the Core to define desired outcomes, Profiles to describe current and target posture, Tiers to characterize governance and management rigor, and the online CSF portfolio to map outcomes to controls, examples, and action plans. *Next step* ## Turn NIST CSF 2.0 Cyber risk governance and implementation hub into an operational assessment workflow NIST CSF 2.0 Cyber risk governance and implementation hub should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from NIST CSF 2.0 Cyber risk governance and implementation hub and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for NIST CSF 2.0 Cyber risk governance and implementation hub. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through NIST CSF 2.0 Cyber risk governance and implementation hub](/contact.md): Review your current process, evidence model, and next steps for NIST CSF 2.0 Cyber risk governance and implementation hub. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-csf-2-0 --- --- title: "NIST Frameworks Hub (CSF, RMF, SP 800 Series)" canonical_url: "https://www.sorena.io/artifacts/global/nist-frameworks-hub" source_url: "https://www.sorena.io/artifacts/global/nist-frameworks-hub" author: "Sorena AI" description: "Practical NIST frameworks guidance grounded to the current set used in this repo: CSF 2.0, RMF context, SP 800-53 Rev. 5 Update 1, SP 800-61r3, SP 800-161 Rev." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST frameworks hub" - "NIST cybersecurity frameworks" - "NIST CSF 2.0" - "NIST RMF" - "NIST SP 800-53 rev 5" - "NIST SP 800-61 rev 3" - "NIST SP 800-161 rev 1" - "NIST SP 800-218 SSDF" - "choose NIST framework" - "NIST framework mapping" - "NIST vs ISO" - "NIST compliance evidence" - "NIST implementation guide" - "cybersecurity governance framework" - "NIST frameworks" - "NIST SP 800 series" - "Cybersecurity governance" - "Audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST Frameworks Hub (CSF, RMF, SP 800 Series) Practical NIST frameworks guidance grounded to the current set used in this repo: CSF 2.0, RMF context, SP 800-53 Rev. 5 Update 1, SP 800-61r3, SP 800-161 Rev. ![NIST Frameworks Hub artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-nist-frameworks-hub-small.jpg?v=cheatsheets%2Fprod) *NIST Frameworks Hub* *Free Resource* ## NIST Frameworks Hub Choose the right framework and operationalize it Use this hub to choose and run NIST frameworks as a practical operating model: CSF outcomes, RMF lifecycle context, control baselines, software security practices, incident response guidance, and supply-chain risk management. Build one evidence index that supports executive reporting, assurance, and audits. This hub reflects the current grounded NIST set already covered in this repo: CSF 2.0 published February 26, 2024, SP 800-53 Rev. 5 Update 1, SP 800-61 Rev. 3, SP 800-161 Rev. 1 Update 1, and SP 800-218 SSDF v1.1. [Jump to guides](#topics) ## What this hub helps you do - **Choose the right NIST path**: Pick framework-first (CSF/RMF) or publication-first (SP 800 series) based on your objective and risk profile. - **Map outcomes to controls**: Connect outcomes to specific control families, implementation tasks, and evidence artifacts. - **Run a measurable program**: Track progress with metrics, governance cadence, and corrective action closure. By Sorena AI | Updated 2026 | No signup required ### Quick scan *NIST* - **What is included**: Coverage map of NIST frameworks and SP 800 priorities. - **Choose the right standard**: Decision guide by governance, controls, software, incident response, or supply chain. - **NIST vs ISO**: How to run NIST and ISO together with shared evidence. NIST works best when translated into ownership, implementation cadence, and evidence quality. These guides focus on execution, not generic summaries. | Value | Metric | | --- | --- | | CSF | Outcomes | | SP 800 | Deep Dives | | ISO | Mappable | | Evidence | Reusable | **Key highlights:** Select | Map | Prove ## Topic Guides - [Choose the Right NIST Standard (CSF, RMF, 800-53, 800-61r3, 800-161r1, SSDF)](/artifacts/global/nist-frameworks-hub/choose-the-right-nist-standard.md): Decision guide to choose the right NIST framework or publication by objective: governance and communication (CSF), control baseline depth (SP 800-53). - [NIST Frameworks Hub FAQ (CSF, SP 800, RMF, NIST vs ISO)](/artifacts/global/nist-frameworks-hub/faq.md): FAQ for choosing and implementing NIST frameworks: CSF 2.0, SP 800 publications, RMF context, control mappings, evidence cadence. - [NIST vs ISO (Framework Mapping, Governance, and Evidence Reuse)](/artifacts/global/nist-frameworks-hub/nist-vs-iso.md): NIST vs ISO explained for practical implementation: outcomes-driven NIST frameworks vs certifiable ISO management systems. - [What Is Included in the NIST Frameworks Hub (CSF, RMF, SP 800)](/artifacts/global/nist-frameworks-hub/what-is-included.md): Coverage map for key NIST frameworks and publications: NIST CSF 2.0, RMF, SP 800-53, SP 800-61r3, SP 800-161r1, SP 800-218 SSDF. ## Explore NIST Frameworks Hub guides *Guides* Use these subpages for implementation deep dives: what is included, choose the right NIST standard, NIST vs ISO, and FAQ. ## How to run NIST frameworks in practice *Navigation* Start with the operating objective and the type of depth you need. Use CSF 2.0 for outcome communication and prioritization, RMF when system lifecycle and authorization context matter, SP 800-53 for control selection and assessment depth, SP 800-61r3 for response lifecycle design, SP 800-161 for supply-chain governance, and SSDF for secure software practices. *Next step* ## Turn NIST Frameworks Hub Choose the right framework and operationalize it into a cited research workflow NIST Frameworks Hub Choose the right framework and operationalize it should be the shared entry point for your team. Route execution into Research Copilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from NIST Frameworks Hub Choose the right framework and operationalize it and route the work by entity, product, team, or control owner. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs for NIST Frameworks Hub Choose the right framework and operationalize it. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through NIST Frameworks Hub Choose the right framework and operationalize it](/contact.md): Review your current process, evidence model, and next steps for NIST Frameworks Hub Choose the right framework and operationalize it. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-frameworks-hub --- --- title: "NIST SP 800-161 Rev. 1 (C-SCRM)" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-161-rev-1" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-161-rev-1" author: "Sorena AI" description: "Practical NIST SP 800-161 Rev. 1 Update 1 guidance for cybersecurity supply chain risk management: multilevel enterprise, mission, and operational model." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST SP 800-161 Rev. 1" - "NIST SP 800-161r1-upd1" - "cybersecurity supply chain risk management" - "C-SCRM" - "supply chain cybersecurity" - "third party risk management" - "supplier risk tiering" - "supplier contract cybersecurity clauses" - "continuous supplier monitoring" - "NIST supply chain controls" - "SP 800-161 implementation guide" - "SP 800-161 compliance" - "SP 800-161 audit evidence" - "supplier assurance metrics" - "Supply chain security" - "Third-party risk management" - "Global compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-161 Rev. 1 (C-SCRM) Practical NIST SP 800-161 Rev. 1 Update 1 guidance for cybersecurity supply chain risk management: multilevel enterprise, mission, and operational model. ![NIST SP 800-161 Rev. 1 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-nist-sp-800-161-rev-1-small.jpg?v=cheatsheets%2Fprod) *NIST SP 800-161 Rev. 1* *Free Resource* ## NIST SP 800-161 Rev. 1 Cybersecurity supply chain risk management implementation hub Use these guides to operationalize cybersecurity supply chain risk management with the actual NIST multilevel model: integrate supply chain risk into enterprise governance, develop strategy and implementation plans, tailor mission and operational plans, run supplier risk tiering, enforce contract controls, and monitor suppliers continuously. Grounded to NIST SP 800-161 Rev. 1 Update 1. The base publication is dated May 2022 and includes updates as of November 1, 2024, with NIST Editorial Review Board approval on September 25, 2024. [Jump to guides](#topics) ## What this artifact helps you do - **Integrate C-SCRM into risk governance**: Connect supply chain cybersecurity risk to enterprise risk decisions, accountability, and reporting. - **Run supplier assurance with depth**: Tier suppliers, define contractual requirements, and set monitoring cadence based on risk. - **Prove control effectiveness**: Build an evidence index with measurable outcomes and continuous improvement. By Sorena AI | Updated 2026 | No signup required ### Quick scan *C-SCRM* - **Compliance playbook**: How to build a C-SCRM operating model across enterprise levels. - **Contract + monitoring controls**: Practical controls for supplier agreements and continuous oversight. - **Supplier risk tiering**: Tiering logic and depth model for assessments and evidence cadence. SP 800-161 is most effective when supply chain risk decisions are measurable, enforceable, and continuously monitored. | Value | Metric | | --- | --- | | C-SCRM | Focused | | Suppliers | Tiered | | Contracts | Enforced | | Evidence | Auditable | **Key highlights:** Tier | Contract | Monitor ## Topic Guides - [NIST SP 800-161 Rev. 1 Compliance Playbook (C-SCRM)](/artifacts/global/nist-sp-800-161-rev-1/compliance.md): Practical SP 800-161 Rev. 1 compliance playbook: integrate C-SCRM with enterprise risk management, define strategy and implementation plan. - [NIST SP 800-161 Rev. 1 Contract and Monitoring Controls](/artifacts/global/nist-sp-800-161-rev-1/contract-and-monitoring-controls.md): Practical contract and monitoring controls for C-SCRM under SP 800-161 Rev. - [NIST SP 800-161 Rev. 1 FAQ (C-SCRM Implementation)](/artifacts/global/nist-sp-800-161-rev-1/faq.md): NIST SP 800-161 Rev. 1 FAQ: scope, applicability outside federal environments, supplier risk tiering, acquisition and contract controls, C-SCRM metrics. - [NIST SP 800-161 Rev. 1 Supplier Risk Tiering Model](/artifacts/global/nist-sp-800-161-rev-1/supplier-risk-tiering.md): Build a risk-based supplier tiering model aligned to SP 800-161 Rev. ## Explore NIST SP 800-161 Rev. 1 guides *Guides* Use these subpages for implementation deep dives: compliance playbook, contract and monitoring controls, supplier risk tiering, and FAQ. ## How to run C-SCRM as an operating model *Navigation* Treat C-SCRM as a three-level operating model. At the enterprise level define strategy, implementation plan, policy, and governance. At the mission and business level tailor those artifacts to the process context. At the operational level build C-SCRM plans, tailored controls, acquisition requirements, and monitoring that fit the specific system, service, or product lifecycle. *Next step* ## Turn NIST SP 800-161 Rev. 1 Cybersecurity supply chain risk management implementation hub into an operational assessment workflow NIST SP 800-161 Rev. 1 Cybersecurity supply chain risk management implementation hub should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from NIST SP 800-161 Rev. 1 Cybersecurity supply chain risk management implementation hub and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for NIST SP 800-161 Rev. 1 Cybersecurity supply chain risk management implementation hub. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through NIST SP 800-161 Rev. 1 Cybersecurity supply chain risk management implementation hub](/contact.md): Review your current process, evidence model, and next steps for NIST SP 800-161 Rev. 1 Cybersecurity supply chain risk management implementation hub. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-161-rev-1 --- --- title: "NIST SP 800-218 SSDF v1.1" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-218-ssdf" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-218-ssdf" author: "Sorena AI" description: "Grounded NIST SP 800-218 SSDF guidance covering PO, PS, PW, and RV practices, secure toolchains, release integrity, provenance and SBOM handling." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST SP 800-218 SSDF" - "SSDF v1.1" - "Secure Software Development Framework" - "secure software development" - "NIST secure SDLC" - "PO PS PW RV" - "software release integrity" - "secure build pipeline" - "provenance and SBOM" - "supplier software security requirements" - "vulnerability disclosure program" - "SSDF audit evidence" - "NIST SP 800-218" - "SSDF" - "DevSecOps" - "Global compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-218 SSDF v1.1 Grounded NIST SP 800-218 SSDF guidance covering PO, PS, PW, and RV practices, secure toolchains, release integrity, provenance and SBOM handling. ![NIST SP 800-218 SSDF artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-nist-sp-800-218-ssdf-small.jpg?v=cheatsheets%2Fprod) *NIST SP 800-218 SSDF* *Free Resource* ## NIST SP 800-218 SSDF Secure software development and supplier assurance hub Use these guides to implement NIST SP 800-218 SSDF v1.1 across the full SDLC: define security requirements, secure toolchains and development environments, protect code and releases, manage third-party components with provenance checks, and run a disciplined vulnerability response loop. Grounded to NIST SP 800-218, published February 2022. SSDF is voluntary guidance for software producers and software acquirers, and Appendix A maps specific SSDF tasks to EO 14028 Section 4e software supply chain expectations. [Jump to guides](#topics) ## What this artifact helps you do - **Translate SSDF tasks into engineering controls**: Turn PO.1, PO.3, PO.5, PS.2, PW.4, PW.6 to PW.8, and RV tasks into named workflows, owners, and evidence. - **Strengthen release integrity and provenance**: Operationalize cryptographic hashes, archives, provenance data, SBOM updates, and software acquirer verification paths. - **Improve supplier and vulnerability governance**: Set supplier requirements, verify third-party components through their life cycles, and run disclosure and remediation with root-cause learning. By Sorena AI | Updated 2026 | No signup required ### Quick scan *SSDF* - **Compliance playbook**: How to run PO, PS, PW, and RV as a program with supplier and EO 14028 context. - **Evidence for audits**: Which artifacts prove secure environments, release integrity, provenance, and vulnerability handling. - **Secure development practices**: Task-level guidance for toolchains, code review, testing, third-party components, and response loops. SSDF is strongest when task-level controls generate evidence automatically inside the SDLC, not when teams retrofit documentation after release. | Value | Metric | | --- | --- | | 19 | Practices | | 42 | Tasks | | EO 14028 | Mapped | | Risk-based | Tailored | **Key highlights:** Toolchains | Integrity | Response ## Topic Guides - [NIST SP 800-218 SSDF Compliance Playbook | PO PS PW RV Implementation](/artifacts/global/nist-sp-800-218-ssdf/compliance.md): Task-level SSDF compliance playbook grounded to NIST SP 800-218: PO, PS, PW, and RV implementation, secure environments, release integrity. - [NIST SP 800-218 SSDF Evidence for Audits | Release Integrity and Provenance](/artifacts/global/nist-sp-800-218-ssdf/evidence-for-audits.md): Build an SSDF evidence pack grounded to NIST SP 800-218 with PO, PS, PW, and RV artifacts, release integrity data, provenance and SBOM records. - [NIST SP 800-218 SSDF FAQ | Practical SSDF Questions](/artifacts/global/nist-sp-800-218-ssdf/faq.md): Practical SSDF FAQ grounded to NIST SP 800-218: what SSDF is, how to phase PO PS PW RV, how to handle legacy products, what suppliers should provide. - [NIST SP 800-218 SSDF Secure Development Practices | Task Level Guide](/artifacts/global/nist-sp-800-218-ssdf/secure-development-practices.md): Task-level SSDF practice guide covering PO, PS, PW, and RV: secure toolchains, environment separation, release integrity, provenance, third-party components. ## Explore NIST SP 800-218 SSDF guides *Guides* Use these subpages for implementation depth: SSDF compliance, evidence for audits, secure development practices, and FAQ. ## How to run SSDF as a practical secure SDLC system *Implementation* Treat SSDF as a continuous operating model: maintain security requirements, deploy and monitor supporting toolchains, separate and harden development environments, protect code and release artifacts, verify third-party components, test executables, and use vulnerability root-cause analysis to improve the SDLC. *Next step* ## Turn NIST SP 800-218 SSDF Secure software development and supplier assurance hub into an operational assessment workflow NIST SP 800-218 SSDF Secure software development and supplier assurance hub should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from NIST SP 800-218 SSDF Secure software development and supplier assurance hub and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for NIST SP 800-218 SSDF Secure software development and supplier assurance hub. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through NIST SP 800-218 SSDF Secure software development and supplier assurance hub](/contact.md): Review your current process, evidence model, and next steps for NIST SP 800-218 SSDF Secure software development and supplier assurance hub. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-218-ssdf --- --- title: "NIST SP 800-53 Rev. 5" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5" author: "Sorena AI" description: "Grounded NIST SP 800-53 Rev. 5 guidance covering the integrated security and privacy control catalog, the SR supply chain family, SP 800-53A assessments." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST SP 800-53 Rev 5" - "NIST 800-53 controls" - "security and privacy controls" - "NIST SP 800-53A" - "NIST SP 800-53B" - "control baselines" - "control tailoring" - "common controls" - "supply chain risk management family" - "NIST control assessments" - "audit evidence" - "NIST SP 800-53 Rev. 5" - "RMF" - "Control assessments" - "Global compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-53 Rev. 5 Grounded NIST SP 800-53 Rev. 5 guidance covering the integrated security and privacy control catalog, the SR supply chain family, SP 800-53A assessments. ![NIST SP 800-53 Rev. 5 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-nist-sp-800-53-rev-5-small.jpg?v=cheatsheets%2Fprod) *NIST SP 800-53 Rev. 5* *Free Resource* ## NIST SP 800-53 Rev. 5 Security, privacy, and assessment implementation hub Use these guides to operationalize NIST SP 800-53 Rev. 5 as a real risk management system: implement the integrated security and privacy control catalog, tailor baselines with SP 800-53B, assess effectiveness with SP 800-53A, govern common and inherited controls, and maintain reusable evidence for audits and authorizations. Grounded to NIST SP 800-53 Rev. 5, published September 2020 and updated December 10, 2020. Revision 5 integrated security and privacy controls into one catalog, created the SR supply chain risk management family, and moved control baselines and tailoring guidance into SP 800-53B. [Jump to guides](#topics) ## What this artifact helps you do - **Understand the real Rev. 5 changes**: Work from the integrated security and privacy catalog, the new SR family, and the separation between the catalog, assessment procedures, and baselines. - **Tailor and inherit controls safely**: Use SP 800-53B baselines, overlays, common controls, hybrid controls, and system-specific decisions with documented rationale. - **Assess for effectiveness, not paperwork**: Apply SP 800-53A examine, interview, and test methods with depth and coverage matched to assurance requirements. By Sorena AI | Updated 2026 | No signup required ### Quick scan *NIST 800-53* - **Compliance playbook**: How to run Rev. 5 as a governance and control operating model. - **Assessment procedures**: How 53A uses objectives, determination statements, and assessment methods. - **Tailoring and evidence**: How to select baselines, justify deviations, and preserve assessment-grade proof. SP 800-53 becomes useful when control selection, tailoring, assessment, and evidence are run as one connected system rather than separate documents. | Value | Metric | | --- | --- | | Rev. 5 | Current | | 53A | Assess | | 53B | Tailor | | SR | Supply chain | **Key highlights:** Catalog | Assess | Tailor ## Topic Guides - [NIST SP 800-53 Rev. 5 Compliance Playbook | Rev. 5 Operating Model](/artifacts/global/nist-sp-800-53-rev-5/compliance.md): Grounded playbook for SP 800-53 Rev. 5 covering integrated security and privacy controls, control ownership at organization mission and system levels. - [NIST SP 800-53 Rev. 5 Control Tailoring Method | SP 800-53B Guide](/artifacts/global/nist-sp-800-53-rev-5/control-tailoring-method.md): Grounded control tailoring method for SP 800-53 Rev. - [NIST SP 800-53 Rev. 5 Evidence and Audit Readiness](/artifacts/global/nist-sp-800-53-rev-5/evidence-and-audit-readiness.md): Grounded SP 800-53 evidence guide covering control-to-evidence mapping, common-control inheritance, freshness and sampling, assessment findings. - [NIST SP 800-53 Rev. 5 FAQ | Practical Rev. 5 Questions](/artifacts/global/nist-sp-800-53-rev-5/faq.md): Practical FAQ on NIST SP 800-53 Rev. 5 covering federal and non-federal use, Rev. - [NIST SP 800-53 Rev. 5 vs ISO 27001 | Controls vs ISMS](/artifacts/global/nist-sp-800-53-rev-5/nist-800-53-vs-iso-27001.md): Grounded comparison of NIST SP 800-53 Rev. 5 and ISO 27001 covering control-catalog depth, ISMS governance, assessment style. - [NIST SP 800-53A Rev. 5 Assessment Procedures](/artifacts/global/nist-sp-800-53-rev-5/assessment-procedures-800-53a.md): Grounded guide to SP 800-53A Rev. 5 covering assessment objectives, determination statements, examine interview test methods, depth and coverage. ## Explore NIST SP 800-53 Rev. 5 guides *Guides* Use these subpages for implementation depth: assessment procedures, compliance, tailoring, evidence readiness, FAQ, and ISO 27001 comparison. ## How to run NIST controls as a risk management system *Implementation* Treat SP 800-53 as a living control architecture: define organization, mission, and system responsibilities; tailor baselines and overlays; assess whether controls are implemented correctly, operating as intended, and producing the desired outcome; and feed assessment findings into risk response, authorization, and continuous monitoring. *Next step* ## Turn NIST SP 800-53 Rev. 5 Security, privacy, and assessment implementation hub into an operational assessment workflow NIST SP 800-53 Rev. 5 Security, privacy, and assessment implementation hub should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from NIST SP 800-53 Rev. 5 Security, privacy, and assessment implementation hub and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for NIST SP 800-53 Rev. 5 Security, privacy, and assessment implementation hub. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through NIST SP 800-53 Rev. 5 Security, privacy, and assessment implementation hub](/contact.md): Review your current process, evidence model, and next steps for NIST SP 800-53 Rev. 5 Security, privacy, and assessment implementation hub. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5 --- --- title: "NIST SP 800-61r3" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3" author: "Sorena AI" description: "Grounded NIST SP 800-61r3 guidance covering the April 2025 CSF 2.0 community profile, incident management, incident analysis, response communications." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST SP 800-61r3" - "incident response recommendations and considerations for cybersecurity risk management" - "CSF 2.0 community profile" - "incident management" - "incident analysis" - "response communication" - "incident mitigation" - "incident recovery" - "evidence integrity and provenance" - "NIST incident response" - "Incident response" - "CSF 2.0" - "Cybersecurity operations" - "Global compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-61r3 Grounded NIST SP 800-61r3 guidance covering the April 2025 CSF 2.0 community profile, incident management, incident analysis, response communications. ![NIST SP 800-61r3 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-global-nist-sp-800-61-rev-3-small.jpg?v=cheatsheets%2Fprod) *NIST SP 800-61r3* *Free Resource* ## NIST SP 800-61r3 Incident response and recovery implementation hub Use these guides to implement NIST SP 800-61r3 as a modern incident-response capability: integrate incident response across all six CSF 2.0 Functions, manage incidents with explicit risk evaluation factors, preserve record and evidence integrity, coordinate notifications and information sharing, and execute recovery with declared end-state criteria. Grounded to NIST SP 800-61r3, published April 2025 and approved March 25, 2025. Revision 3 supersedes SP 800-61r2 and replaces the old static lifecycle framing with a CSF 2.0 community-profile model centered on continuous improvement. [Jump to guides](#topics) ## What this artifact helps you do - **Run incident response across CSF 2.0**: Use Govern, Identify, and Protect for preparation, Detect, Respond, and Recover for active handling, and Identify Improvement for lessons learned. - **Prioritize and manage incidents by risk**: Use asset criticality, impact, scope, threat behavior, and recoverability to decide triage, escalation, and when recovery starts. - **Preserve trustworthy response records**: Protect the integrity and provenance of investigation actions, incident data, and recovery records so decisions are defensible later. By Sorena AI | Updated 2026 | No signup required ### Quick scan *IR* - **Compliance playbook**: How Rev. 3 reframes incident response as cybersecurity risk management. - **Playbook template**: A scenario-ready structure for triage, mitigation, communication, and recovery. - **Severity and SLA model**: How to convert NIST risk evaluation factors into prioritization and response timing. SP 800-61r3 is strongest when the incident team, asset owners, leadership, legal, privacy, suppliers, and recovery teams operate from the same incident model. | Value | Metric | | --- | --- | | Apr 2025 | Published | | CSF 2.0 | Profile | | RS plus RC | Integrated | | Evidence | Preserved | **Key highlights:** Analyze | Communicate | Recover ## Topic Guides - [NIST SP 800-61r3 Compliance Playbook | CSF 2.0 Incident Response](/artifacts/global/nist-sp-800-61-rev-3/compliance.md): Grounded incident-response playbook for NIST SP 800-61r3 covering the CSF 2.0 community-profile model, roles, risk-based incident management, communications. - [NIST SP 800-61r3 FAQ | Practical Incident Response Questions](/artifacts/global/nist-sp-800-61-rev-3/faq.md): Practical FAQ on NIST SP 800-61r3 covering what changed from r2, incident declaration, risk evaluation factors, containment versus observation. - [NIST SP 800-61r3 Incident Response Playbook Template](/artifacts/global/nist-sp-800-61-rev-3/incident-response-playbook-template.md): Grounded incident-response playbook template based on NIST SP 800-61r3 with incident criteria, incident lead, risk evaluation factors, communications tracks. - [NIST SP 800-61r3 Severity Classification and SLA Model](/artifacts/global/nist-sp-800-61-rev-3/severity-classification-and-sla-model.md): Grounded severity and SLA model for NIST SP 800-61r3 using NIST risk evaluation factors such as asset criticality, impact, scope, threat behavior. - [NIST SP 800-61r3 vs ISO 27035 | Incident Response Comparison](/artifacts/global/nist-sp-800-61-rev-3/nist-800-61-vs-iso-27035.md): Grounded comparison of NIST SP 800-61r3 and ISO 27035 covering the CSF 2.0 community-profile model, management-process structure, communications, recovery. ## Explore NIST SP 800-61r3 guides *Guides* Use these subpages for implementation depth: compliance, FAQ, playbook template, framework comparison, and severity/SLA model. ## How to run incident response as continuous cyber risk management *Implementation* Treat incident response as a continuous risk management capability, not a closed loop that waits for a final postmortem. Use the CSF 2.0 Functions to prepare, detect, manage, analyze, communicate, mitigate, recover, and continuously improve based on lessons learned identified during and after incidents. *Next step* ## Turn NIST SP 800-61r3 Incident response and recovery implementation hub into an operational assessment workflow NIST SP 800-61r3 Incident response and recovery implementation hub should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from NIST SP 800-61r3 Incident response and recovery implementation hub and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for NIST SP 800-61r3 Incident response and recovery implementation hub. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through NIST SP 800-61r3 Incident response and recovery implementation hub](/contact.md): Review your current process, evidence model, and next steps for NIST SP 800-61r3 Incident response and recovery implementation hub. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3 --- --- title: "EU Accessibility Act Compliance Hub - 28 June 2025 Scope, EN 301 549, Evidence, and Procurement" canonical_url: "https://www.sorena.io/artifacts/eu/accessibility-act" source_url: "https://www.sorena.io/artifacts/eu/accessibility-act" author: "Sorena AI" description: "Practical EU Accessibility Act compliance hub for Directive (EU) 2019/882." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU Accessibility Act compliance" - "European Accessibility Act 2019/882" - "Directive (EU) 2019/882" - "28 June 2025 accessibility" - "EU Accessibility Act scope" - "products and services in scope EAA" - "EN 301 549" - "Annex IV technical documentation" - "EU declaration of conformity accessibility" - "Article 14 disproportionate burden" - "microenterprise EAA" - "e-commerce accessibility EU" - "consumer banking accessibility EU" - "electronic communications accessibility EU" - "accessibility procurement requirements" - "market surveillance accessibility" - "accessibility testing evidence" - "European Accessibility Act checklist" - "EU Accessibility Act" - "28 June 2025" - "Annex IV" - "Article 14" - "procurement accessibility" - "market surveillance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Accessibility Act Compliance Hub - 28 June 2025 Scope, EN 301 549, Evidence, and Procurement Practical EU Accessibility Act compliance hub for Directive (EU) 2019/882. ![EU Accessibility Act artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-accessibility-timeline-small.jpg?v=cheatsheets%2Fprod) *EAA* *Free Resource* ## EU Accessibility Act Timeline and Decision Flow A practical EU Accessibility Act hub for Directive (EU) 2019/882. Use the decision flow to confirm whether a covered product or consumer service is in scope from 28 June 2025, then use the topic guides to implement Annex I requirements, EN 301 549 mapping, testing, procurement language, and evidence retention. The local grounding pack behind this page covers the actual category list in Article 2, the 28 June 2022 transposition deadline, the 28 June 2025 application date, Annex IV technical documentation, Article 14 assessments, transition treatment for legacy service contracts and self service terminals, and the market surveillance consequences of weak documentation. [Get an accessibility review](/contact.md) ## What you can decide faster - **Scope and dates**: Confirm whether the offering is a listed product or consumer service and whether 28 June 2025 or a transition rule controls the analysis. - **Role and evidence**: Separate manufacturer, importer, distributor, and service provider duties and build the right Annex IV or service evidence pack. - **Exceptions and procurement**: Document Article 14 and microenterprise treatment correctly and translate Annex I outcomes into buyer facing acceptance criteria. By Sorena AI | Updated 2026 | No signup required ### Quick scan *EAA* - **Covered categories**: Computing devices, terminals, e-readers, e-commerce, banking, communications, media access, and transport service elements. - **Engineering path**: Map Annex I outcomes to EN 301 549 clauses, tests, defects, fixes, and release approval. - **Response pack**: Keep declarations, statements, Article 14 records, and procurement evidence ready for customer and authority review. Use the decision flow and topic pages to align legal, product, design, QA, procurement, and support on one documented accessibility programme. | Value | Metric | | --- | --- | | EAA | Directive | | EN 301 549 | Standard | | WCAG | Web | | Evidence | Pack | **Key highlights:** Scope first | Accessibility testing | Documentation ## Topic Guides - [EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use](/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping.md): Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way. - [EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence](/artifacts/eu/accessibility-act/accessibility-conformance-statement-template.md): Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method. - [EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs](/artifacts/eu/accessibility-act/applicability-test.md): Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter. - [EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence](/artifacts/eu/accessibility-act/checklist.md): Audit ready EU Accessibility Act compliance checklist for products and services. - [EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence](/artifacts/eu/accessibility-act/compliance.md): Build an EU Accessibility Act compliance programme with this practical playbook. - [EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates](/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar.md): Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025. - [EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly](/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden.md): Understand EU Accessibility Act exceptions correctly. - [EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions](/artifacts/eu/accessibility-act/faq.md): Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549. - [EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence](/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites.md): Detailed EU Accessibility Act guide for e-commerce websites and apps. - [EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk](/artifacts/eu/accessibility-act/penalties-and-fines.md): Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products. - [EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce](/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria.md): Draft procurement ready accessibility language under the EU Accessibility Act. - [EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact](/artifacts/eu/accessibility-act/products-and-services-in-scope.md): Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications. - [EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations](/artifacts/eu/accessibility-act/requirements.md): Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation. - [EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep](/artifacts/eu/accessibility-act/testing-and-conformance-evidence.md): Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements. - [EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness](/artifacts/eu/accessibility-act/deadlines-and-transition-plan.md): Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates. - [EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences](/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508.md): Compare the EU Accessibility Act with the ADA and Section 508 in practical terms. ## Key dates for accessibility rollouts *Accessibility Timeline* Track milestones that shape accessibility planning and market access timing across the EU. ## Does the EAA apply to your offering *Accessibility Decision Flow* Use the decision flow to confirm scope and role, then translate outcomes into design, testing, and documentation workstreams. *Next step* ## Turn EU Accessibility Act Timeline and Decision Flow into an operational assessment workflow EU Accessibility Act Timeline and Decision Flow should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU Accessibility Act Timeline and Decision Flow and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for EU Accessibility Act Timeline and Decision Flow. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share scope logic internally. - **Download timeline**: Align milestones across teams. - [Talk through EU Accessibility Act Timeline and Decision Flow](/contact.md): Review your current process, evidence model, and next steps for EU Accessibility Act Timeline and Decision Flow. ## Decision Steps ### STEP 1: Do you manufacture or place products on the market, OR provide services to consumers in the EU? *Reference: Art. 2(1)-(3)* - The EAA applies to specific products and services placed on the market or provided to consumers after 28 June 2025. - Products: computers, smartphones, tablets, ATMs, ticketing machines, self-service terminals, e-readers, payment terminals. - Services: e-commerce, banking, transport, audiovisual media, e-books, electronic communications, emergency number 112. - **NO** Out of Scope - **YES** Are you placing a product on the EU market (manufacturer/importer/distributor/authorised representative)? ### STEP 2: Are you placing a product on the EU market (manufacturer/importer/distributor/authorised representative)? - If yes: follow the product track (products covered by the EAA, plus economic operator duties). - If no: follow the service track (services covered by the EAA). - If you provide both products and services, you should review both tracks. - **YES** Do you manufacture, import, or distribute products in scope? - **NO** Do you provide services in scope to consumers? ### STEP 3A: Do you manufacture, import, or distribute products in scope? *Reference: Art. 2(1)* - If yes: you are a product economic operator (manufacturer, importer, or distributor). - Manufacturers have primary responsibility for design, conformity assessment, CE marking. - Importers and distributors must ensure products comply before placing/making available on market. - **YES** Are you a microenterprise dealing with products? - **NO** Out of Scope ### STEP 3B: Do you provide services in scope to consumers? *Reference: Art. 2(2)-(3)* - If yes: you are a service provider subject to EAA obligations. - Services must comply with accessibility requirements in Annex I. - Member States designate authorities to check compliance and handle complaints. - **YES** Are you a microenterprise providing services? - **NO** Out of Scope ### STEP 4: Are you a microenterprise providing services? *Reference: Art. 3(23) & Art. 4(5)* - Microenterprise = enterprise with fewer than 10 persons AND annual turnover or balance sheet total not exceeding EUR 2 million. - Microenterprises providing services are EXEMPT from EAA accessibility requirements and compliance obligations. - If yes: you are exempt. Member States should provide guidelines and tools to facilitate voluntary compliance. - **YES** Exempt (Microenterprise Providing Services) - **NO** Would compliance impose a disproportionate burden or fundamental alteration? ### STEP 5: Are you a microenterprise dealing with products? *Reference: Art. 3(23) & Art. 14(4); Art. 16(2)* - Microenterprises dealing with products are not exempt from accessibility requirements for in-scope products. - If relying on the Article 14 exception, microenterprises dealing with products are exempt from documenting their assessment, but must provide the relevant facts to authorities upon request. - Technical documentation requirements should avoid imposing any undue burden for microenterprises and SMEs. - Member States should provide guidelines and tools to microenterprises. - **YES** EAA Applies (Microenterprise Product Economic Operator) - **NO** EAA Applies (Product Economic Operator) ### STEP 6: Would compliance impose a disproportionate burden or fundamental alteration? *Reference: Art. 14 & Annex VI* - Disproportionate burden = additional excessive organizational or financial burden (considering criteria in Annex VI). - Fundamental alteration = change resulting in fundamental alteration of basic nature of product or service. - Economic operators must carry out an assessment; assessments must be documented and kept for 5 years after the last relevant placing on the market or service provision (with microenterprise exceptions for documentation of product assessments). - Service providers relying on disproportionate burden must renew their assessment at least every 5 years (and also when the service is altered or when requested by the competent authority). - When relying on Article 14, economic operators must send information to the relevant authorities (this notification duty does not apply to microenterprises). - **YES** EAA Applies (Service Provider with Disproportionate Burden) - **NO** EAA Applies (Service Provider) ## Reference Information ### Products in Scope - Consumer general purpose computer hardware systems and operating systems (computers, smartphones, tablets). - Self-service terminals: payment terminals, ATMs, ticketing machines, check-in machines, interactive information terminals. - Consumer terminal equipment for electronic communications services (with interactive computing capability). - Consumer terminal equipment for audiovisual media services. - E-readers (dedicated hardware and software for e-books). ### Services in Scope - Electronic communications services (excluding machine-to-machine). - Services providing access to audiovisual media services (including EPGs). - Air, bus, rail and waterborne passenger transport services (websites, mobile apps, electronic tickets, real-time travel info, interactive self-service terminals; urban/suburban/regional transport limited to certain elements). - Consumer banking services (credit, payments, electronic money, investment services). - E-books and dedicated software. - E-commerce services (online sales to consumers). - Answering emergency communications to 112. ### Product Economic Operator Obligations - Manufacturers: design and manufacture in accordance with accessibility requirements (Annex I); draw up technical documentation and EU declaration of conformity (Annex IV); carry out conformity assessment (Module A - Internal production control); affix CE marking; keep documentation for 5 years [Art. 7]. - Importers: ensure products comply before placing on market; verify manufacturer has complied; ensure product marked with CE marking and accompanied by documentation; indicate name and address on product [Art. 8]. - Distributors: ensure product bears CE marking and is accompanied by required documentation; verify manufacturer and importer have fulfilled obligations; ensure handling does not adversely affect compliance [Art. 9]. - All operators: cooperate with market surveillance authorities; take corrective action if product not in conformity; inform relevant authorities if disproportionate burden or fundamental alteration claimed [Art. 7-10]. ### Service Provider Obligations - Design and provide services in accordance with accessibility requirements set out in Annex I [Art. 12(1)]. - Prepare information explaining how services meet applicable accessibility requirements; make information available in accessible formats; keep information for as long as service is in operation [Art. 12(1)(a)]. - Ensure personnel are properly trained on accessible products/services used in provision of services [Art. 12(1)(b)]. - If subcontracting: ensure accessibility of subcontracted services [Recital 20]. - Member States designate authorities to check compliance, follow up on complaints, and verify corrective measures [Art. 23]. ### Accessibility Requirements (Annex I Overview) - Section I: General accessibility requirements for products (design, user interface, information provision). - Section II: Accessibility requirements for products (except self-service terminals) - detailed technical requirements. - Section III: General accessibility requirements for services (information provision, design, delivery). - Section IV: Accessibility requirements for all services (detailed functional requirements). - Section V: Specific accessibility requirements for answering emergency communications to 112. - Key principles: perceivability, operability, understandability, robustness (aligned with Web Accessibility Directive). ### Harmonised Standards and Conformity Assessment - Products and services conforming to harmonised standards (adopted under Regulation (EU) No 1025/2012) benefit from presumption of conformity [Art. 15]. - EN 301 549 is the key harmonised European standard for ICT products and services accessibility requirements. - Commission may adopt implementing acts establishing technical specifications when harmonised standards do not exist or are insufficient [Art. 16]. - Conformity assessment for products uses Module A (Internal production control) from Decision No 768/2008/EC [Annex IV]. - CE marking indicates product conformity [Art. 17-18]. ### Market Surveillance and Compliance Checks - Products: Member States designate market surveillance authorities under Regulation (EC) No 765/2008 [Art. 19]. - Market surveillance authorities check compliance, assess disproportionate burden/fundamental alteration claims, require corrective action, order product withdrawal if necessary [Art. 19-21]. - Services: Member States designate authorities to check compliance with accessibility requirements, follow up on complaints/reports, verify corrective measures [Art. 23]. - Authorities operate in proportionate manner, especially for SMEs and small-scale production [Recital 65]. - Safeguard procedures apply when Member States disagree on measures [Art. 21-22]. ### Built Environment (Optional) - Member States MAY decide that built environment used by clients of services covered by EAA shall comply with accessibility requirements (Annex III) [Art. 4(4)]. - This is optional to maximize use by persons with disabilities in light of national conditions. - Annex III contains indicative requirements for built environment accessibility. ### Transitional Provisions and Exemptions - Service contracts agreed before 28 June 2025 may continue without alteration until expiry, but no longer than 5 years (i.e., until 28 June 2030) [Art. 32]. - Service providers may continue to provide services using products lawfully used to provide similar services before 28 June 2030 [Art. 32(1)]. - Self-service terminals lawfully used by service providers before 28 June 2025 may continue to be used until end of their economically useful life, but no longer than 20 years after their entry into use [Art. 32(2)]. - Content exemptions: pre-recorded time-based media and office file formats published before 28 June 2025; online maps (if essential info provided accessibly); third-party content not under control; archive content not updated after 28 June 2025 [Art. 2(4)]. ### Penalties and Enforcement - Member States must lay down rules on penalties for infringements; penalties must be effective, proportionate, and dissuasive [Art. 30]. - Penalties must be adequate to character of infringement and circumstances; not serve as alternative to fulfilling obligations [Recital 98]. - Member States must notify the Commission of penalty rules and measures, and any subsequent amendments [Art. 30(3)]. - Alternative dispute resolution mechanisms should be in place [Recital 99]. - Procurement procedures: enforcement follows Directives 2014/24/EU and 2014/25/EU rules [Recital 97]. ### Public Procurement Link - Directives 2014/24/EU and 2014/25/EU require technical specifications to take accessibility into account [Recital 90]. - Where mandatory accessibility requirements are adopted by EU law, technical specifications must reference them. - EAA establishes mandatory accessibility requirements for products and services in scope. - Authorities may establish accessibility requirements beyond EAA Annex I minimums [Recital 90]. - EAA obligations apply to procurement procedures where call for competition sent after 28 June 2025 [Recital 92]. ### Annex I Product Requirements (Key Elements) - Provision of information: perceivable, operable, understandable, robust; support assistive technologies; alternatives to visual/auditory information. - User interface and functionality: operable without vision, with limited vision, without hearing, with limited hearing, without vocal capability, with limited manipulation/strength, with limited reach. - Design for cognitive and learning disabilities: minimize errors, provide warnings, reversible actions. - Preservation of accessibility information during conversion/transmission. - Packaging and instructions: accessible; tactile/auditory indicators where needed. ### Annex I Service Requirements (Key Elements) - Information provision: accessible information on functioning, accessibility features, and interoperability with assistive technologies; multiple sensory channels; alternative formats. - Design and delivery: perceivable, operable, understandable, robust; support assistive technologies; websites/mobile apps compliant (aligned with EN 301 549 / WCAG). - Electronic communications: total conversation (voice, real time text, video); relay services where required; caller identification; emergency communications accessible. - Transport services: accessible real-time travel information, booking, ticketing; accessible websites/apps/terminals. - Banking services: accessible authentication, electronic signature, payment services. - E-books: accessible navigation, structure, alternative text for images, reflowable text. ### Emergency Number 112 Accessibility - Member States must ensure answering of emergency communications to 112 by most appropriate PSAP complies with Annex I Section V accessibility requirements [Art. 4(8)]. - Requirements include: receiving calls in voice, text, and video; processing and forwarding emergency communications to emergency services; ensuring equivalent access for end-users with disabilities. - Member States organize emergency systems in manner best suited to national context [Art. 4(8)]. - Alternative: Member States may determine third-party relay service provider for persons with disabilities to communicate with PSAP [Recital 45]. - Member States may decide to apply the measures regarding Article 4(8) obligations at the latest from 28 June 2027 [Art. 31(3)]. ## Possible Outcomes ### [RESULT] EAA Applies (Product Economic Operator) Full compliance required - Design and manufacture products in accordance with Annex I accessibility requirements. - Draw up technical documentation and EU declaration of conformity (Annex IV). - Carry out conformity assessment (Module A); affix CE marking. - Keep documentation for 5 years. - If disproportionate burden or fundamental alteration applies, document assessment and comply to extent possible. ### [RESULT] EAA Applies (Microenterprise Product Economic Operator) Lighter obligations - Accessibility requirements apply to in-scope products placed on the market after 28 June 2025. - If relying on the Article 14 exception, microenterprises dealing with products are exempt from documenting their assessment, but must provide the relevant facts to authorities upon request. - Member States should provide guidelines and tools to facilitate compliance. - Document disproportionate burden or fundamental alteration assessments where applicable. - Encouraged to comply fully to increase competitiveness. ### [RESULT] EAA Applies (Service Provider) Full compliance required - Design and provide services in accordance with Annex I accessibility requirements. - Prepare and maintain accessible information explaining how services meet requirements. - Train personnel on accessible products/services. - If disproportionate burden or fundamental alteration applies, document assessment (renew every 5 years) and comply to extent possible. - Cooperate with national compliance authorities. ### [RESULT] EAA Applies (Service Provider with Disproportionate Burden) Partial compliance - Comply with accessibility requirements to the extent they do not impose disproportionate burden. - Document assessment using Annex VI criteria; keep for 5 years; renew at least every 5 years. - Inform relevant authorities of reliance on disproportionate burden exemption. - Provide assessment to authorities upon request. - Make service as accessible as possible within the constraints. ### [RESULT] Exempt (Microenterprise Providing Services) No EAA obligations - Microenterprises providing services are EXEMPT from EAA accessibility requirements and compliance obligations [Art. 4(5)]. - Member States should provide guidelines and tools to facilitate voluntary compliance [Art. 4(6)]. - Voluntary compliance encouraged to increase competitiveness and growth potential [Recital 72]. ### [RESULT] Out of Scope EAA does not apply - Your products or services are not covered by the EAA scope (Art. 2). - Other accessibility legislation may apply (e.g., Web Accessibility Directive 2016/2102 for public sector websites). - Consider voluntary compliance with accessibility standards (e.g., EN 301 549) for market advantage. ## EAA Timeline | Date | Event | Reference | | --- | --- | --- | | 2019-04-17 | Directive adopted | Directive (EU) 2019/882 | | 2019-06-07 | Published in Official Journal | OJ L 151 | | 2022-06-28 | Member States transposition deadline | Art. 31(1) | | 2025-06-28 | EAA applies to products and services placed on market | Art. 2; Art. 31(2) | | 2030-06-28 | Transitional period ends for existing service contracts and products | Art. 32 | | 2030-06-28 | Commission report on application due | Art. 33(1) | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2014-01-01 | EN 301 549 originally published (ETSI/CEN/CENELEC) | Standards | | | 2019-04-17 | European Accessibility Act (Directive (EU) 2019/882) adopted | Legislative | | | 2019-06-07 | European Accessibility Act published in Official Journal (OJ L 151) | Legislative | | | 2019-06-27 | Directive enters into force; delegated act powers begin | Legislative | | | 2020-06-28 | Deadline to adopt first delegated act (if necessary) | Legislative | | | 2021-03-10 | EN 301 549 V3.2.1 adopted (2021-03) | Standards | | | 2021-06-28 | Draft standardization request due | Standards | | | 2021-08-01 | EN 301 549 officially supports the Web Accessibility Directive | Standards | | | 2022-06-28 | Member State transposition deadline | Implementation | | | 2022-07-01 | Commission letter of formal notice to Bulgaria (transposition infringement) | Enforcement | | | 2023-07-01 | Commission reasoned opinion to Bulgaria (transposition infringement) | Enforcement | | | 2023-12-01 | Bulgaria announces a draft transposition law (planned submission) | Enforcement | | | 2024-06-27 | Five-year delegation period ends for certain delegated powers | Legislative | | | 2024-07-25 | Commission refers Bulgaria to the Court of Justice for failing to transpose the EAA | Enforcement | | | 2025-01-31 | AccessibleEU readiness article published | Implementation | | | 2025-06-27 | Commission Daily News highlights EAA application date | Implementation | | | 2025-06-28 | European Accessibility Act applies (compliance date) | Implementation | | | 2025-09-26 | AccessibleEU publishes a cognitive accessibility guide | Implementation | | | 2026-01-01 | EN 301 549 revision planned to support the EAA | Standards | | | 2030-06-28 | Commission report on application due | Implementation | | | 2030-06-28 | Service-provider transitional period ends | Implementation | | | 2045-06-28 | AccessibleEU guidance notes a removal deadline for inaccessible self-service terminals | Implementation | | **Event details:** - **2014-01-01 - EN 301 549 originally published (ETSI/CEN/CENELEC)**: EN 301 549 was originally published in 2014 to support public procurement of accessible ICT (Mandate 376). - **2019-04-17 - European Accessibility Act (Directive (EU) 2019/882) adopted**: Date of the Directive: of 17 April 2019. - **2019-06-07 - European Accessibility Act published in Official Journal (OJ L 151)**: Published in the Official Journal of the European Union (OJ L 151) on 7 June 2019. - **2019-06-27 - Directive enters into force; delegated act powers begin**: The Directive enters into force on the twentieth day following its publication in the Official Journal. From 27 June 2019, the Commission is also conferred delegated act powers (including Article 4(9), and certain powers for a five-year period). - **2020-06-28 - Deadline to adopt first delegated act (if necessary)**: When necessary, the Commission must adopt the first delegated act by 28 June 2020. - **2021-03-10 - EN 301 549 V3.2.1 adopted (2021-03)**: EN 301 549 V3.2.1 (2021-03) was adopted on 10 March 2021. - **2021-06-28 - Draft standardization request due**: The Commission must submit the first draft standardization request to the relevant committee by 28 June 2021. - **2021-08-01 - EN 301 549 officially supports the Web Accessibility Directive**: Official support for the Web Accessibility Directive since August 2021 (Commission Implementing Decision (EU) 2021/1339). - **2022-06-28 - Member State transposition deadline**: Member States shall adopt and publish the laws, regulations and administrative provisions necessary to comply with this Directive by 28 June 2022. - **2022-07-01 - Commission letter of formal notice to Bulgaria (transposition infringement)**: The Commission sent a letter of formal notice to Bulgaria in July 2022. - **2023-07-01 - Commission reasoned opinion to Bulgaria (transposition infringement)**: The Commission followed up with a reasoned opinion in July 2023. - **2023-12-01 - Bulgaria announces a draft transposition law (planned submission)**: Bulgaria announced it would propose a draft law transposing the Directive and submit it to the National Assembly in December 2023. - **2024-06-27 - Five-year delegation period ends for certain delegated powers**: Certain delegated powers are conferred for a period of five years from 27 June 2019, ending on 27 June 2024 (with extensions unless the Parliament or the Council opposes). - **2024-07-25 - Commission refers Bulgaria to the Court of Justice for failing to transpose the EAA**: Press release date (Jul 25, 2024) published in Brussels. - **2025-01-31 - AccessibleEU readiness article published**: Publication date indicated in the page URL (2025-01-31). - **2025-06-27 - Commission Daily News highlights EAA application date**: Commission Daily News (27 June 2025) notes that the European Accessibility Act will start to apply on 28 June 2025. - **2025-06-28 - European Accessibility Act applies (compliance date)**: Date after which products placed on the market and services provided to consumers fall within the scope of this Directive (Article 2). - **2025-09-26 - AccessibleEU publishes a cognitive accessibility guide**: AccessibleEU lists a publication date of 26 September 2025 for the guide 'A general approach to cognitive accessibility'. - **2026-01-01 - EN 301 549 revision planned to support the EAA**: EN 301 549 will be revised with the aim to publish V4.1.1 in 2026 in support of Directive (EU) 2019/882 (Mandate 587). - **2030-06-28 - Commission report on application due**: By 28 June 2030, and every five years thereafter, the Commission must submit a report on the application of the Directive. - **2030-06-28 - Service-provider transitional period ends**: Transitional period ending on 28 June 2030 during which service providers may continue to provide their services using products lawfully used before that date. - **2045-06-28 - AccessibleEU guidance notes a removal deadline for inaccessible self-service terminals**: AccessibleEU guidance states that all inaccessible self-service terminals will need to be removed by 28 June 2045. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/accessibility-act --- --- title: "EU Data Act (Regulation (EU) 2023/2854): IoT Data Access, B2B Sharing & Cloud Switching" canonical_url: "https://www.sorena.io/artifacts/eu-data-act" source_url: "https://www.sorena.io/artifacts/eu/data-act" author: "Sorena AI" description: "Execution-oriented EU Data Act hub: key dates (applies 12 Sep 2025; connected-product design duty for products placed after 12 Sep 2026." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU Data Act Regulation (EU) 2023/2854" - "connected products product data" - "related services data" - "readily available data" - "data holder user data recipient" - "B2B data sharing contract terms" - "unfair contractual terms Data Act" - "B2G exceptional need request" - "trade secrets handbrake" - "cloud switching exit plan" - "switching charges ban 12 January 2027" - "data portability IoT real time" - "Data Act" - "Regulation (EU) 2023/2854" - "Data access" - "Cloud switching" - "Portability" - "B2B data sharing" - "B2G exceptional need" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Data Act (Regulation (EU) 2023/2854): IoT Data Access, B2B Sharing & Cloud Switching Execution-oriented EU Data Act hub: key dates (applies 12 Sep 2025; connected-product design duty for products placed after 12 Sep 2026. ![EU Data Act artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-data-act-timeline-small.jpg?v=cheatsheets%2Fprod) *Data Act* *Free Resource* ## EU Data Act Scope, Obligations & Switching A practical EU Data Act hub for teams building connected products, data access workflows, and cloud switching. Use it to confirm applicability, identify which chapters matter, and translate obligations into contracts, APIs, and audit ready evidence. This is a practical reference, not legal advice. Validate against your product, contract, and data architecture. [Get a Data Act review](/contact.md) ## What you can decide faster (and deliver faster) - **Scope boundary**: What counts as product data vs related service data vs out-of-scope inferred/derived data. - **Role mapping**: Who is the user vs data holder vs data recipient, and which requests you must support. - **Switching readiness**: Whether your cloud contracts and technical exit plans meet Articles 23-31 and the 2027 pricing rules. By Sorena AI | Updated 2026-03 | No signup required ### Quick scan *Data Act* - **Key dates**: 12 Sep 2025 (applies), 12 Sep 2026 (design duty for new products), 12 Jan 2027 (no switching charges). - **Decision flow**: Identify which chapters apply to your scenario and what you must build. - **Guides**: Deep pages for IoT data access, B2B/B2G sharing, trade secrets, and cloud switching. Use the artifact and topic guides to convert EU Data Act obligations into shippable workflows and contracts. | Value | Metric | | --- | --- | | 2023/2854 | Regulation | | IoT | Products | | B2B | Sharing | | Cloud | Switching | **Key highlights:** Scope first | Role mapping | Switching readiness ## Topic Guides - [Access Rights and Portability | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/access-rights-and-portability.md): EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, "readily available" data. - [Applicability Test | EU Data Act: Connected Products, B2B Data Sharing, B2G Exceptional Need, Cloud Switching](/artifacts/eu/data-act/applicability-test.md): A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services). - [B2B Data Sharing Contract Clauses | EU Data Act: Mandatory Sharing, Unfair Terms, Trade Secrets](/artifacts/eu/data-act/b2b-data-sharing-contract-clauses.md): EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security. - [B2B Data Sharing Contract Template | EU Data Act: Data Access and Use Agreement (Drafting Checklist)](/artifacts/eu/data-act/b2b-data-sharing-contract-template.md): A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use. - [B2G Exceptional Need Requests | EU Data Act: Public Emergency Data Requests, Safeguards, Compensation](/artifacts/eu/data-act/b2g-exceptional-need-requests.md): EU Data Act Chapter V B2G 'exceptional need' requests made practical. - [Cloud Switching and Exit Plans | EU Data Act Chapter VI: Switch Providers, Port Data, Remove Egress Barriers](/artifacts/eu/data-act/cloud-switching-and-exit-plans.md): EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition. - [Cloud Switching Compliance Checklist | EU Data Act Chapter VI: Contracts, Exportable Data, Fees, Transparency](/artifacts/eu/data-act/cloud-switching-compliance-checklist.md): A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period). - [Compliance Program | EU Data Act Implementation Playbook: Governance, Controls, Evidence, Operating Cadence](/artifacts/eu/data-act/compliance.md): Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access. - [Deadlines and Compliance Calendar | EU Data Act](/artifacts/eu/data-act/deadlines-and-compliance-calendar.md): Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025. - [EU Data Act Checklist | Chapter II Access, B2B Sharing, Unfair Terms, B2G Requests, Cloud Switching](/artifacts/eu/data-act/checklist.md): A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access). - [EU Data Act vs GDPR | Differences, Overlap, Portability, Lawful Basis, Implementation Playbook](/artifacts/eu/data-act/data-act-vs-gdpr.md): EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights. - [FAQ | EU Data Act Explained: Key Dates, Access Rights, Trade Secrets, B2G Requests, Cloud Switching](/artifacts/eu/data-act/faq.md): EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access. - [Penalties and Fines | EU Data Act Enforcement: Member State Penalties, GDPR-Linked Fines, Risk Controls](/artifacts/eu/data-act/penalties-and-fines.md): EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider. - [Requirements | EU Data Act Obligations Explained: Chapter II Access, Chapter IV Unfair Terms, Chapter V B2G, Chapter VI Switching](/artifacts/eu/data-act/requirements.md): A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows. - [Scope, Connected Products and Data Types | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/scope-connected-products-and-data-types.md): EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data. - [Trade Secrets and Protection | EU Data Act: Confidentiality Measures, Withholding Rules, Evidence Pack](/artifacts/eu/data-act/trade-secrets-and-protection.md): EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs. ## Key dates for EU Data Act rollout *Data Act Timeline* Track entry into force, application, and key deadlines so you can plan delivery, contracts, and technical readiness. ## Which Data Act chapters apply to your scenario *Data Act Decision Flow* Follow the scope decision flow to identify the chapters you need, then align product, legal, and engineering work on a shared plan. *Next step* ## Turn EU Data Act Scope, Obligations & Switching into a cited research workflow EU Data Act Scope, Obligations & Switching should be the shared entry point for your team. Route execution into Research Copilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU Data Act Scope, Obligations & Switching and route the work by entity, product, team, or control owner. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs for EU Data Act Scope, Obligations & Switching. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share scope logic with legal and engineering. - **Download timeline**: Align deadlines with delivery milestones. - [Talk through EU Data Act Scope, Obligations & Switching](/contact.md): Review your current process, evidence model, and next steps for EU Data Act Scope, Obligations & Switching. ## Decision Steps ### START: Do any of the Data Act scope categories apply to you for this scenario? *Reference: Art. 1(3)* - Manufacturer of connected products placed on the Union market, or provider of related services (Art. 1(3)(a)). - User in the Union of connected products or related services (Art. 1(3)(b)). - Data holder making data available to data recipients in the Union, or data recipient in the Union (Art. 1(3)(c)-(d)). - Public sector body, the Commission, the ECB, or a Union body requesting data due to exceptional need, or a data holder responding (Art. 1(3)(e)). - Provider of data processing services providing services to customers in the Union (Art. 1(3)(f)). - Participant in data spaces, vendor of applications using smart contracts, or deployment of smart contracts for others in that context (Art. 1(3)(g)). - **YES** Which parts of the Data Act should you focus on? - **NO** Out of Data Act Scope ### IN SCOPE: Which parts of the Data Act should you focus on? - Follow every chapter that matches what you do in practice. Multiple chapters can apply at the same time. - Chapter II is for connected products and related services data access and user-directed sharing. - Chapters III and IV cover B2B making data available and unfair contractual terms. - Chapter V covers exceptional need requests by public sector bodies. - Chapters VI and VII cover cloud switching and safeguards against unlawful third-country access. - Chapter VIII covers interoperability and smart contracts. - -> Connected products and related services: user access and sharing ### CHAPTER II: Connected products and related services: user access and sharing - Applies if you manufacture connected products placed on the Union market, provide related services, or must provide users access to product or related service data. - Covers access by design and transparency (Article 3), user access and data holder duties (Article 4), sharing to third parties (Article 5), and third party duties (Article 6). - -> B2B making data available: terms and safeguards ### CHAPTER III: B2B making data available: terms and safeguards - Applies where, in business-to-business relations, a data holder is obliged under Article 5 or under applicable Union law or national legislation adopted in accordance with Union law to make data available to a data recipient (Art. 12(1)). - For statutory data-sharing obligations arising under other Union or national law, Chapter III applies only where that law enters into force after 12 September 2025 (Art. 50). - Covers fair and non-discriminatory terms (Article 8), compensation (Article 9), disputes (Article 10), technical protection measures (Article 11), and when Chapter III applies (Article 12). - -> Unfair terms in B2B data contracts ### CHAPTER IV: Unfair terms in B2B data contracts - Applies if you have a B2B contract governing access to or use of data and face terms imposed unilaterally. - Explains which unfair terms are not binding (Article 13). - -> Exceptional need requests from public sector bodies (B2G) ### CHAPTER V: Exceptional need requests from public sector bodies (B2G) - Applies if you issue or receive requests for data due to exceptional need by public sector bodies, or respond to such requests as a data holder. - Covers when requests are allowed (Articles 14 to 16), request requirements (Article 17), response and handling duties (Articles 18 and 19), and related rules (Articles 20 to 22). - -> Switching between data processing services (cloud switching) ### CHAPTER VI: Switching between data processing services (cloud switching) - Applies if you provide data processing services to customers in the Union or if you are a customer switching between providers or to on-premises infrastructure. - Covers contract clauses, portability, technical interfaces, and phase-out of switching charges (Articles 23 to 31). - -> Safeguards against unlawful third-country access ### CHAPTER VII: Safeguards against unlawful third-country access - Applies if you are a provider of data processing services providing services to customers in the Union, for non-personal data held in the Union (Art. 1(3)(f), Art. 32). - Covers safeguards against unlawful third-country access requests that conflict with Union or Member State law (Article 32). - -> Interoperability and smart contracts ### CHAPTER VIII: Interoperability and smart contracts - Applies if you participate in data spaces or deploy smart contracts for data sharing agreements in the relevant context. - Covers interoperability requirements (Articles 33 to 35) and smart contract requirements (Article 36). - -> Authorities, remedies, penalties, and dates ### ENFORCEMENT: Authorities, remedies, penalties, and dates - Covers competent authorities and complaints (Article 37), penalties (Article 40), model terms (Article 41), and application dates (Article 50). - Use this section to plan implementation and contract updates. - -> Data Act Compliance Checklist ## Reference Information ### Scope and precedence - Confirm whether the Data Act applies to your roles and scenario. - Check how it interacts with other laws and voluntary sharing. ### Key definitions - Map your products and services to the Regulation's definitions. - Identify roles such as user, data holder, and data recipient. ### What data is covered - Understand what data is in scope for Chapter II and what is excluded. - Pay attention to readily available data and metadata concepts. ### Exemption check - Check whether the Chapter II exemption for micro and small enterprises applies. ### Article 3: access by design and transparency - Design for user access to in-scope data and provide required pre-contract information. ### Article 4: user access and data holder duties - User access rights, data holder duties, and security-based restrictions. ### Trade secret safeguards - Measures for protecting trade secrets during access and sharing. - Rules on withholding, suspension, or refusal where applicable. ### Article 5: user sharing to third parties - Core sharing rule plus verification, data protection, and trade secret safeguards. ### Article 6: third party duties - Obligations and use limits for third parties after receiving data. ### When Chapter V applies - Exceptional need scenarios and who can request data. ### Request requirements (Article 17) - Required content, proportionality, and formalities. - Publication, routing, and penalties information tied to the request. ### Response and handling duties - How data holders respond and the deadlines and refusal grounds. - How requesting bodies must use, protect, and erase the data. ### Sharing limits and onward sharing - No reuse rules and conditions for onward sharing, including research and statistics. ### Coordination and cross-border - Cross-border cooperation and where disputes are handled. ### Definitions for switching - Key terms for switching, exportable data, and charges. ### Contract clauses for switching (Article 25) - Minimum clauses, timelines, customer choices, and retrieval and erasure. ### Information duties and transparency - Registers and procedures that support switching and transparency on international access. ### Switching charges phase-out (Article 29) - Reduced charges period then prohibition for the switching process. ### Technical interfaces, standards, limits - Portability interfaces, standards timing, limits, and exemptions. ### Authorities and governance - Competent authorities, data coordinators, legal representative duties, and governance. ### Complaints and remedies - Complaint handling and judicial remedies. ### Penalties and model terms - Penalties framework plus non-binding model contractual terms and cloud clauses. ### Interaction with other EU law - How the Data Act interacts with other Union data access laws and consumer enforcement. ### Dates and timeline - Entry into force, application dates, and key deadlines. ### Who and What the Data Act Covers - Applies to manufacturers of connected products placed on the EU market and providers of related services, regardless of place of establishment (Art. 1(3)(a)) - Applies to users in the Union of those products or services (Art. 1(3)(b)) - Applies to data holders making data available to data recipients in the Union, and to those data recipients (Art. 1(3)(c)-(d)) - Applies to public sector bodies, the Commission, the ECB, and Union bodies requesting data on exceptional need, and to data holders responding (Art. 1(3)(e)) - Applies to providers of data processing services providing to customers in the Union, regardless of place of establishment (Art. 1(3)(f)) - Also applies to participants in data spaces and certain smart contract actors in scope contexts (Art. 1(3)(g)) ### Precedence and Voluntary Data Sharing - Without prejudice to EU and national data protection, privacy and communications confidentiality rules, including GDPR and ePrivacy; in a conflict, the relevant data protection or privacy rules prevail (Art. 1(5)) - Does not apply to or pre-empt voluntary arrangements for data sharing between private and public entities (Art. 1(6)) - Does not affect Member State competences on public security, defence, national security, customs and tax administration, or health and safety of citizens (Art. 1(6)) ### Connected Products and Related Services - Connected product: obtains, generates or collects data about its use or environment, can communicate product data, and its primary function is not storing, processing or transmitting data on behalf of parties other than the user (Art. 2(5)) - Related service: digital service linked to product functionality, where absence would prevent one or more product functions, or later connected to add to, update or adapt product functions (Art. 2(6)) - References to connected products or related services include virtual assistants insofar as they interact with a connected product or related service (Art. 1(4)) - Connected products fall within scope, with the exception of prototypes (Recital 14) ### Actors and Roles - User: owns a connected product, has temporary rights to use it, or receives related services (Art. 2(12)) - Data holder: has a right or obligation to use and make available data, including product data or related service data where contractually agreed (Art. 2(13)) - Data recipient: business recipient other than the user, including a third party following a user request (Art. 2(14)) - Third party is not a separate defined term in Article 2. A third party may be a natural or legal person such as a consumer, enterprise, research organisation, not-for-profit organisation, or another professional entity. When receiving data at a user's request, a third party may also be a data recipient (Recital 33). - Processors under GDPR are not considered data holders, but can be tasked with making data available by the controller (Recital 22) ### Data Types and Availability - Product data: data generated by use of a connected product that the manufacturer designed to be retrievable by a user, data holder or third party (Art. 2(15)) - Related service data: digitisation of user actions or events related to the connected product during the provision of a related service (Art. 2(16)) - Readily available data: product data and related service data obtainable without disproportionate effort beyond a simple operation (Art. 2(17)) - Readily available data does not include data that is not stored or transmitted outside the component or product where it is generated, and the Data Act does not impose an obligation to store data centrally (Recital 20) ### Cloud Switching Terms - Data processing service: on-demand access to configurable, scalable and elastic computing resources of a centralised, distributed or highly distributed nature (Art. 2(8)) - Same service type: services sharing the same primary objective, service model and main functionalities (Art. 2(9)) - Customer: person with a contract with a provider of data processing services to use one or more such services (Art. 2(30)) - Digital assets: elements in digital form, including applications, for which the customer has a right of use independent of the source provider contract (Art. 2(32)) - Switching: customer changes provider or moves on-premises, including extracting, transforming and uploading data (Art. 2(34)) - Exportable data: customer input and output data, including metadata, generated or cogenerated by use of the service, excluding providers' or third parties' IP-protected assets or trade secrets (Art. 2(38)) ### Switching and Charges Definitions - On-premises ICT infrastructure: ICT infrastructure and computing resources owned, rented or leased by the customer, located in the customer's data centre, operated by the customer or a third party (Art. 2(33)) - Data egress charges: data transfer fees charged for extracting data through the network from a provider to another provider or to on-premises infrastructure (Art. 2(35)) - Switching charges: charges other than standard service fees or early termination penalties imposed for the actions mandated by the Data Act for switching, including data egress charges (Art. 2(36)) - Functional equivalence: re-establishing a minimum level of functionality in the new environment using the customer's exportable data and digital assets, with materially comparable outcomes for shared features (Art. 2(37)) ### What Data Is in Scope - Chapter II covers data, except content, concerning the performance, use and environment of connected products and related services (Art. 1(2)(a)) - Includes product data and related service data as defined (Art. 2(15)-(16)) - Includes raw and pre-processed data plus relevant metadata, but not data cleaning or transformation requiring substantial investments (Recital 15) - Does not include inferred or derived data produced through additional investments, such as proprietary, complex algorithms, unless otherwise agreed (Recital 15) - Content and data generated from recording, transmitting, displaying, or playing content are not covered, and data processed on behalf of parties other than the user is not covered (Recital 16) ### Micro and Small Enterprise Exemption - Chapter II obligations do not apply to data generated through use of connected products manufactured or designed, or related services provided, by a microenterprise or small enterprise (Art. 7(1)) - The exemption does not apply where the enterprise has a non-SME partner or linked enterprise, or where it is subcontracted to manufacture, design, or provide the product or service (Art. 7(1)) - Transitional: applies to an enterprise that has been medium-sized for less than one year, and to connected products for one year after placement on the market by that enterprise (Art. 7(1)) - Contract terms undermining user rights under Chapter II are not binding on the user (Art. 7(2)) ### Access by design checklist (Article 3) - By default, make product data, related service data and necessary metadata easily accessible, secure and free of charge (Art. 3(1)) - Provide data in a comprehensive, structured, commonly used and machine-readable format, and where relevant and technically feasible, make it directly accessible to the user (Art. 3(1)) - The Article 3(1) design obligation applies to connected products and services related to them placed on the market after 12 September 2026 (Art. 50) ### Pre-Contract Transparency (Article 3(2)-(3)) - Before purchase, rent or lease: disclose data type, format, estimated volume, and whether generation is continuous and in real time (Art. 3(2)(a)-(b)) - Also disclose storage location and retention, and how the user can access, retrieve or erase data including technical means, terms and quality of service (Art. 3(2)(c)-(d)) - Before a related service contract: provide data nature, estimated volume and collection frequency, and how to access, retrieve or erase data (Art. 3(3)(a)-(b)) - Also disclose intended use, third party sharing, identities and contacts, complaint rights, trade secret holder details, and contract duration and termination (Art. 3(3)(c)-(i)) ### User access and data holder duties (Article 4) - If data cannot be directly accessed by the user, make readily available data and necessary metadata accessible without undue delay, of the same quality as available to the data holder, easily, securely and free of charge (Art. 4(1)) - Provide the data in a comprehensive, structured, commonly used and machine-readable format, and where relevant and technically feasible, continuously and in real time (Art. 4(1)) - Provide access on the basis of a simple request, through electronic means where technically feasible (Art. 4(1)) - Do not make exercising rights unduly difficult, including via non-neutral user interface design (Art. 4(4)) - Verify whether a person qualifies as a user using only necessary information, and keep access-related information only as needed for execution, security and maintenance (Art. 4(5)) ### Security-Based Restrictions and Authority Notification (Art. 4(2)) - If a data holder refuses to share data based on this security restriction, it must notify the competent authority (Art. 4(2), Art. 37) - Users and data holders may contractually restrict or prohibit accessing, using or further sharing data to protect connected product security requirements under Union or national law (Art. 4(2)) - Such restrictions apply only where access or sharing would result in a serious adverse effect on the health, safety or security of natural persons (Art. 4(2)) - Sectoral authorities may provide users and data holders with technical expertise in that context (Art. 4(2)) - Users can challenge a data holder's security-based refusal through a complaint or dispute settlement (Art. 4(3), Art. 10(1)) ### Limits on Data Holder Use and Disclosure - Non-personal readily available data may be used by a data holder only on the basis of a contract with the user (Art. 4(13)) - A data holder must not use such data to derive insights about the user's economic situation, assets and production methods, or use by the user, in a way that could undermine the user's commercial position (Art. 4(13)) - Data holders shall not make available non-personal product data to third parties for commercial or non-commercial purposes other than the fulfilment of their contract with the user, and where relevant, shall contractually bind third parties not to further share data received from them (Art. 4(14)) ### Trade Secret Safeguards (User Access) - Trade secrets can be shared only where the data holder and the user take necessary measures to preserve confidentiality, especially regarding third-party access (Art. 4(6)) - Identify trade secret data in metadata (Art. 4(6)) - Agree proportionate technical and organisational measures with the user, such as confidentiality agreements, strict access protocols, technical standards and codes of conduct (Art. 4(6)) ### Withholding or Refusing Trade Secret Data - If measures are not agreed, not implemented, or confidentiality is undermined, the data holder may withhold or suspend sharing, must provide a substantiated written decision, and must notify the competent authority (Art. 4(7), Art. 37) - In exceptional circumstances, a trade secret holder may refuse a request case by case if serious economic damage is highly likely despite measures, must provide a substantiated written decision, and must notify the competent authority (Art. 4(8), Art. 37) - Users can challenge refusal, withholding or suspension via a complaint or a dispute settlement body (Art. 4(9), Art. 10(1)) ### User Restrictions When Using Data - Do not use data obtained under Art. 4(1) to develop a competing connected product, and do not share data with that intent (Art. 4(10)) - Do not use data to derive insights about the economic situation, assets, and production methods of the manufacturer or data holder (Art. 4(10)) - Do not use coercive means or abuse gaps in the data holder's technical infrastructure to obtain access (Art. 4(11)) - Where the user is not the data subject, personal data can be made available only with a valid GDPR legal basis and relevant ePrivacy conditions (Art. 4(12)) ### Sharing Data With Third Parties (Core Rules) - On user request, make readily available data and relevant metadata available to a third party without undue delay, of the same quality as available to the data holder, easily, securely and free of charge to the user (Art. 5(1)) - Provide the data in a comprehensive, structured, commonly used and machine-readable format and, where relevant and technically feasible, continuously and in real time (Art. 5(1)) - Provide data to the third party in accordance with the arrangements and compensation rules in Articles 8 and 9 (Art. 5(1)) - Testing exception: paragraph 1 does not apply to readily available data generated during testing of new connected products, substances or processes not yet placed on the market, unless contractually permitted (Art. 5(2)) - DMA gatekeepers are not eligible third parties and cannot solicit, incentivise or receive data through the Art. 5 routes (Art. 5(3)) ### Third-Party Sharing: Verification and Access Integrity - For verification, the user or third party must not be required to provide more information than necessary (Art. 5(4)) - Data holders must not keep third-party access information beyond what is necessary for execution, security and maintenance of the data infrastructure (Art. 5(4)) - Third parties must not use coercive means or abuse gaps in a data holder's technical infrastructure to obtain access (Art. 5(5)) ### Third-Party Sharing: Data Protection and Use Limits - Data holders must not use the data to derive insights about the third party's economic situation, assets and production methods, or use, in any manner that could undermine the third party's commercial position (Art. 5(6)) - Exception: allowed only where the third party permits it and can easily withdraw permission at any time (Art. 5(6)) - Where the user is not the data subject, personal data can be made available to the third party only with a valid GDPR legal basis and relevant ePrivacy conditions (Art. 5(7)) - Failure to agree arrangements for transmitting the data must not hinder the rights of data subjects under GDPR, including data portability (Art. 5(8)) - The Art. 5 right to share data must not adversely affect data subjects' rights under applicable data protection law (Art. 5(13)) ### Sharing Data With Third Parties (Trade Secrets and Disputes) - Trade secrets may be disclosed to third parties only to the extent strictly necessary for the purpose agreed between the user and the third party, and proportionate confidentiality measures must be agreed (Art. 5(9)) - If measures are not agreed, not implemented, or confidentiality is undermined, the data holder may withhold or suspend sharing of trade secret data, must provide a substantiated written decision, and must notify the competent authority (Art. 5(10)) - In exceptional circumstances, a trade secret holder may refuse a request case by case if serious economic damage is highly likely despite measures, and must notify the competent authority (Art. 5(11)) - Third parties can challenge withholding, suspension or refusal via a complaint or a dispute settlement body (Art. 5(12), Art. 10(1)) ### Third Party Duties After Receiving Data - Process data only for the purposes and conditions agreed with the user and comply with data protection law, and erase data when no longer needed unless otherwise agreed for non-personal data (Art. 6(1)) - Do not manipulate the user's choices or rights, including through user interface design (Art. 6(2)(a)) - Do not profile using the data unless necessary to provide the service requested by the user (Art. 6(2)(b)) - Do not pass data to another third party unless contractually agreed with the user and trade secret measures are preserved, and do not make data available to DMA gatekeepers (Art. 6(2)(c)-(d)) - Do not use data to build competing products, derive insights about the data holder, or harm the security of the connected product or related service (Art. 6(2)(e)-(f)) - Maintain agreed trade secret measures and do not prevent consumers from sharing the data onward (Art. 6(2)(g)-(h)) ### When Chapter III Applies (B2B Data Sharing) - Chapter III applies where, in B2B relations, a data holder is obliged under Article 5 or other applicable Union or national law to make data available to a data recipient (Art. 12(1)) - A term that excludes, derogates from, or varies the effect of Chapter III to the detriment of a party, or where applicable the user, is not binding (Art. 12(2)) ### Fair and non-discriminatory terms (Article 8) - Agree arrangements for making data available and provide it under fair, reasonable and non-discriminatory terms and conditions and in a transparent manner (Art. 8(1)) - Unfair contractual terms under Article 13 are not binding, and terms undermining user rights under Chapter II are not binding (Art. 8(2)) - Do not discriminate between comparable categories of data recipients, and provide information showing no discrimination upon a reasoned request (Art. 8(3)) - Do not provide data on an exclusive basis unless requested by the user under Chapter II (Art. 8(4)) - Do not require more information than necessary to verify compliance with agreed terms or legal obligations (Art. 8(5)) - Trade secrets do not need to be disclosed, unless Union or national law provides otherwise, including the safeguards in Art. 4(6) and Art. 5(9) (Art. 8(6)) ### Compensation rules and calculation basis (Article 9) - Compensation must be non-discriminatory and reasonable and may include a margin (Art. 9(1)) - Consider costs of making data available and relevant investments in collection and production (Art. 9(2)) - Compensation may depend on volume, format and nature of the data (Art. 9(3)) - For SME data recipients and not-for-profit research organisations without larger partners, compensation must not exceed the costs of making the data available (Art. 9(4)) - Commission shall adopt guidelines on the calculation of reasonable compensation, taking into account EDIB advice (Art. 9(5), Art. 42) - Data holder shall provide the data recipient with information setting out the basis for the calculation of the compensation in sufficient detail (Art. 9(7)) ### Dispute Settlement Bodies - Users, data holders and data recipients must have access to certified dispute settlement bodies for disputes under Art. 4(3) and Art. 4(9), Art. 5(12), and disputes about fair, reasonable and non-discriminatory and transparent data sharing (Art. 10(1)) - Customers and cloud providers must have access for disputes about rights and obligations under Articles 23 to 31 (Art. 10(4)) - Decisions must be adopted within 90 days of receipt of the request (Art. 10(9)) - Decisions are binding only where the parties explicitly consented to binding nature before the proceedings (Art. 10(12)) ### Technical protection measures and remedies (Article 11) - Data holders may apply technical protection measures, including smart contracts and encryption, to prevent unauthorised access and to ensure compliance (Art. 11(1)) - Measures must not discriminate between data recipients or hinder lawful user and third-party rights to access, retrieve, use, or share data (Art. 11(1)) - Users, third parties and data recipients must not alter or remove protection measures unless agreed by the data holder (Art. 11(1)) - Where a third party or data recipient falls within the circumstances in Art. 11(3), it must comply without undue delay with requests to erase copies, stop infringing goods or services where proportionate, inform users, and compensate harmed parties (Art. 11(2)-(3)) - Similar remedies can apply where users undermine protection measures, and users may have comparable rights where a data recipient infringes certain third-party limits (Art. 11(4)-(5)) ### Unfair Contractual Terms (B2B): Core Rules - Unilaterally imposed terms about data access and use, or liability and remedies for breach or termination of data obligations, are not binding if unfair (Art. 13(1)) - Terms reflecting mandatory Union law, or terms that would apply absent contractual regulation, are not considered unfair (Art. 13(2)) - A term is unfair if it grossly deviates from good commercial practice in data access and use, contrary to good faith and fair dealing (Art. 13(3)) - Burden of proof is on the party supplying the term to show it was not unilaterally imposed (Art. 13(6)) - If an unfair term is severable, the remaining terms of the contract stay binding (Art. 13(7)) - Cannot exclude or derogate from Article 13, and it does not apply to main subject matter or adequacy of price (Art. 13(8)-(9)) ### Unfair term examples (Article 13) - Always unfair: excluding liability for intentional acts or gross negligence, excluding remedies, or giving exclusive right to determine conformity or interpret terms (Art. 13(4)) - Presumed unfair: limiting remedies or extending liability, allowing data access or use significantly detrimental to legitimate interests, or preventing the other party from using its data (Art. 13(5)(a)-(c)) - Also presumed unfair: blocking reasonable termination, preventing copies, unreasonably short notice termination, or unilateral changes to price or substantive data-sharing conditions without valid reason and a termination right (Art. 13(5)(d)-(g)) ### Exceptional Need Overview - In exceptional need, legal-person data holders, other than public sector bodies, must provide requested data and relevant metadata upon a duly reasoned request (Art. 14) - Public emergency: exceptional need exists when the requester cannot obtain the data by alternative means in time and effectively under equivalent conditions (Art. 15(1)(a)) - Non-emergency exceptional need covers non-personal data only and requires a specific public-interest task explicitly provided for by law (Art. 15(1)(b)(i)) - Requester must have exhausted other means, including market purchase and relying on existing obligations or new legislation (Art. 15(1)(b)(ii)) - Non-emergency exceptional need does not apply to microenterprises and small enterprises (Art. 15(2)) - For official statistics, no duty to show inability to purchase where national law does not allow purchase (Art. 15(3)) - Chapter V does not affect reporting, access-to-information, or compliance verification obligations under Union or national law (Art. 16(1)) ### Request Content (Article 17(1)) - Specify the data and relevant metadata, justify the choice of data holder, and state the legal provision allocating the public-interest task (Art. 17(1)(a), Art. 17(1)(e), Art. 17(1)(h)) - Demonstrate exceptional need, explain purpose, intended use and duration, and identify other bodies and third parties expected to receive the data (Art. 17(1)(b)-(c), Art. 17(1)(f)) - Where personal data is requested, specify the safeguards and explain how the processing addresses the exceptional need (Art. 17(1)(c), Art. 17(1)(g)) - Specify, if possible, when the data are expected to be erased by all parties with access to them (Art. 17(1)(d)) - Set the deadline for making data available and the deadline for the data holder to decline or seek modification (Art. 17(1)(i), Art. 18(2)) - Make best efforts to avoid the request resulting in data holder liability for infringement of Union or national law (Art. 17(1)(j)) ### Request Formalities and Proportionality (Article 17(2)(a)-(e)) - Request must be in writing and in clear, concise and plain language understandable to the data holder (Art. 17(2)(a)) - Request must be specific and correspond to data the data holder controls, and be proportionate in granularity, volume and access frequency (Art. 17(2)(b)-(c)) - Request must respect legitimate aims of the data holder, commit to trade secret protection, and account for the cost and effort required (Art. 17(2)(d), Art. 19(3)) - Request must concern non-personal data, and only if insufficient, request personal data in pseudonymised form and set the protective measures to be taken (Art. 17(2)(e)) ### Request Routing, Publication, and Penalties (Article 17(2)(f)-(i)) - Request must inform the data holder of penalties for non-compliance (Art. 17(2)(f), Art. 40) - Public body requests are transmitted to the data coordinator for publication unless publication would create a public security risk, and Commission, ECB and Union body requests are published online (Art. 17(2)(g)-(h)) - Where personal data are requested, notify the GDPR supervisory authority, and the ECB and Union bodies inform the Commission of their requests (Art. 17(2)(i)) ### No Reuse and Limited Sharing (Article 17(3)-(4)) - Do not make Chapter V data available for reuse under the Data Governance Act or the Open Data Directive, and those instruments do not apply to Chapter V data held by public sector bodies (Art. 17(3)) - Exchange with other public sector bodies, the Commission, the ECB or Union bodies is allowed for completing the Art. 15 tasks, as specified in the request (Art. 17(4)) - Data may be made available to a third party for delegated technical inspections or other functions under a publicly available agreement, and Article 19 safeguards also apply to that third party (Art. 17(4), Art. 19) - Notify the data holder without undue delay when data is transmitted or made available under Article 17(4) (Art. 17(4)) ### Complaints and Model Template (Article 17(5)-(6)) - If the data holder considers its rights under Chapter V were infringed by transmission or making data available of data, it may lodge a complaint with the competent authority (Art. 17(5)) - The Commission will develop a model template for requests (Art. 17(6)) ### Data Holder Response - Data holders must provide data without undue delay, considering technical, organisational and legal measures (Art. 18(1)) - Data holders may decline or seek modification within 5 working days for public emergency requests and within 30 working days for other cases (Art. 18(2)) - Refusal grounds include not controlling the data, prior similar request without erasure notification, or non-compliant requests under Art. 17(1)-(2) (Art. 18(2)(a)-(c)) - If declining based on a prior request for the same purpose, indicate the identity of the earlier requesting body (Art. 18(3)) - Where personal data is included, properly anonymise unless disclosure is necessary, then pseudonymise (Art. 18(4)) - Disputes about refusal or the request are referred to the competent authority of the Member State where the data holder is established (Art. 18(5)) ### Public Sector Duties After Receiving Data - Use data only for the stated purpose, implement confidentiality and security measures, and erase when no longer necessary and notify relevant parties, unless archiving is required by transparency law (Art. 19(1)) - Do not use data or insights to develop or enhance competing connected products or related services, and do not share data for that purpose (Art. 19(2)) - Trade secret disclosure is limited to what is strictly necessary, and requesting bodies must take appropriate measures to preserve confidentiality (Art. 19(3)) - Requesting body is responsible for the security of the data it receives (Art. 19(4)) ### Compensation Rules - Public emergency data is provided free of charge by data holders other than micro and small enterprises, and public acknowledgement may be required if requested (Art. 20(1)) - For non-emergency exceptional need, data holders are entitled to fair compensation covering costs and a reasonable margin, and on request provide the basis for the calculation (Art. 20(2)) - Micro and small enterprises may claim compensation under the non-emergency route (Art. 20(3)) - No compensation is due for official statistics where purchasing data is not allowed by national law, and Member States notify the Commission where purchase is not allowed (Art. 20(4)) - Disputes about compensation can be brought to the competent authority (Art. 20(5)) ### Sharing With Researchers and Statistical Bodies (Article 21) - Requesting bodies may share Chapter V data for compatible scientific research or analytics, and with national statistical institutes and Eurostat for official statistics (Art. 21(1)) - Recipients must act not-for-profit or under a public-interest mission recognised in law, and must not be significantly influenced by commercial undertakings likely to lead to preferential access to results (Art. 21(2)) - Recipients must follow the no reuse rule and the Article 19 obligations (Art. 21(3), Art. 17(3), Art. 19) - Recipients may keep the data for up to six months after erasure by the requesting body (Art. 21(4)) - Before sharing, notify the data holder with identity, purpose, usage period, and measures taken, and the data holder may complain if it disagrees (Art. 21(5)) ### Cross-Border Cooperation (Article 22) - Public sector bodies, the Commission, the ECB and Union bodies cooperate and assist one another to apply Chapter V consistently (Art. 22(1)-(2)) - Before requesting data from a data holder in another Member State, notify the competent authority in the data holder's Member State, and that authority examines the request (Art. 22(3)) - After examination, the authority transmits the request and may advise cooperation to reduce burden, or rejects the request on substantiated grounds (Art. 22(4)) - Requester takes into account the authority's advice and grounds before further action, including resubmission (Art. 22(4)) ### Removing Obstacles and Scope - Do not impose and remove pre-commercial, commercial, technical, contractual and organisational obstacles that inhibit switching, porting, functional equivalence, and unbundling where feasible (Art. 23) - Obstacles include contract termination after notice and successful switching, porting exportable data and digital assets including after free-tier, achieving functional equivalence, and unbundling where feasible (Art. 23(a)-(e)) - Provider responsibilities apply only to the services, contracts and commercial practices of the source provider (Art. 24) ### Contract: Switching Process Minimum Clauses (Article 25) - Switching rights and obligations must be in a written contract provided before signing, in a form that can be stored and reproduced (Art. 25(1)) - Contract must allow switching or porting without undue delay and no later than the 30 calendar day transitional period after the notice period (Art. 25(2)(a)) - During the transitional period: provide reasonable assistance and maintain continuity (Art. 25(2)(a)(i)-(ii)) - Also: inform known continuity risks and maintain a high level of security during transfer and retrieval (Art. 25(2)(a)(iii)-(iv)) - Contract must support the customer's exit strategy, including by providing all relevant information (Art. 25(2)(b)) - Contract must specify termination and customer notification after successful switching, or after the notice period if the customer chooses erasure (Art. 25(2)(c)) - Maximum notice period to initiate switching must not exceed two months (Art. 25(2)(d)) ### Contract: Data Scope, Retrieval, Erasure, Charges (Article 25) - Contract must specify all categories of data and digital assets that can be ported, including at minimum all exportable data (Art. 25(2)(e)) - Provider may exempt internal-functioning data categories where trade secret breach risk exists, but exemptions must not impede or delay switching (Art. 25(2)(f), Art. 23) - Provide a minimum retrieval period of at least 30 calendar days after the transitional period, and guarantee full erasure after the retrieval period or an alternative agreed later period once switching is completed (Art. 25(2)(g)-(h)) - Contract must state any switching charges that may be imposed under Article 29 (Art. 25(2)(i)) ### Customer Choices and Transitional Period Extensions (Article 25(3)-(5)) - At the end of the maximum notice period, customer may choose: switch to another provider, switch to on-premises, or erase its exportable data and digital assets (Art. 25(3)) - If the 30-day transitional period is technically unfeasible, notify the customer within 14 working days, justify, and propose an alternative transitional period up to seven months, with continuity ensured (Art. 25(4)) - Customer has the right to extend the transitional period once, for a period it considers more appropriate (Art. 25(5)) ### Information and Cooperation - Provide procedures for switching and porting, including methods, formats, restrictions and known technical limitations (Art. 26(a)) - Provide an up-to-date online register listing data structures, formats, relevant standards and open interoperability specifications for exportable data (Art. 26(b)) - All parties, including destination providers, must cooperate in good faith to make switching effective and maintain continuity (Art. 27) ### Transparency on International Access and Contract Listing (Art. 28) - Contracts must list the websites where the Article 28(1) information is published (Art. 28(2)) - Publish the jurisdiction governing the ICT infrastructure used for processing each service (Art. 28(1)(a)) - Publish a general description of measures to prevent third-country governmental access or transfer of non-personal data held in the Union where it would conflict with Union or Member State law (Art. 28(1)(b)) - Keep those websites up to date and aligned with the service as operated (Art. 28(1)-(2)) ### Switching charges and data egress charges (Article 29) - From 12 January 2027, providers must not impose any switching charges on the customer for the switching process (Art. 29(1)) - Between 11 January 2024 and 12 January 2027, providers may impose reduced switching charges, limited to costs directly linked to the switching process (Art. 29(2)-(3)) - Before contract, disclose standard service fees, early termination penalties, and any reduced switching charges that might apply (Art. 29(4)) - Provide information on highly complex or costly switching scenarios, or where switching is impossible without significant interference (Art. 29(5)-(6)) - Commission may establish a monitoring mechanism for switching charges via delegated acts (Art. 29(7)) - Competent authorities are tasked with ensuring that switching charges are withdrawn when required (Art. 37(5)(i), Art. 29) - Technical compatibility obligations can start at least 12 months after references to standards or common specifications are published in the central Union standards repository (Art. 30(3), Art. 35(8)) ### Technical Switching Interfaces - Infrastructure-only services must take reasonable measures to help customers achieve functional equivalence after switching and provide capabilities, information, support and tools (Art. 30(1)) - Other services must provide open interfaces free of charge and equally to customers and destination providers, with sufficient information for portability and interoperability (Art. 30(2)) ### Standards and Export Requirements (Article 30(3)-(5)) - Ensure compatibility with common specifications or harmonised standards at least 12 months after references are published in the central Union standards repository (Art. 30(3), Art. 35(8)) - Update the online register to reflect those standards or common specifications (Art. 30(4), Art. 26(b)) - If no standards or common specifications are published for a service type, export all exportable data in a structured, commonly used and machine-readable format on customer request (Art. 30(5)) ### Limits and Exemptions (Article 30(6), Article 31) - No obligation to develop new technologies or services, or disclose or transfer digital assets protected by intellectual property rights or constituting a trade secret, or compromise security and integrity of service (Art. 30(6)) - Custom-built services not offered at broad commercial scale and non-production test versions are exempt from certain Chapter VI obligations (Art. 31(1)-(2)) - Before contract, inform prospective customers which Chapter VI obligations do not apply for services under Article 31 (Art. 31(3)) ### International Governmental Access and Transfer - Take adequate technical, organisational and legal measures to prevent third-country governmental access or transfer of non-personal data held in the Union where it would conflict with Union or Member State law (Art. 32(1)) - Third-country decisions requiring access or transfer are enforceable only when based on an international agreement such as a mutual legal assistance treaty (Art. 32(2)) - Without an international agreement, access or transfer can occur only under specific conditions covering proportionality, judicial review, and consideration of EU legal interests (Art. 32(3)) - If conditions apply, provide the minimum data permissible and inform the customer before complying, except for justified law enforcement secrecy (Art. 32(4)-(5)) ### Opinion, One-Month Rule, and EDIB Guidelines - The addressee may ask the opinion of the relevant national body or authority for international legal cooperation to assess whether the Article 32(3) conditions are met (Art. 32(3)) - Do this especially where the request involves trade secrets, commercially sensitive data, intellectual property rights, or re-identification risks (Art. 32(3)) - That national body or authority may consult the Commission (Art. 32(3)) - If the addressee considers the request may affect Union or Member State national security or defence interests, it shall request an opinion on whether the data requested concerns such interests (Art. 32(3)) - If no reply is received within one month, or if the opinion concludes the conditions are not met, the addressee may reject the request for transfer or access on those grounds (Art. 32(3)) - The EDIB shall advise and assist the Commission in developing guidelines on assessing whether the Article 32(3) conditions are met (Art. 32(3), Art. 42) ### Data Spaces Interoperability Requirements - Describe dataset content, use restrictions, licences, collection methodology, data quality and uncertainty to enable find, access and use, and where applicable in machine-readable format (Art. 33(1)(a)) - Describe data structures, formats, vocabularies, classification schemes, taxonomies and code lists in a publicly available and consistent manner (Art. 33(1)(b)) - Describe APIs and other technical access means, terms of use, and quality of service to enable automated access and transmission, including real-time where feasible (Art. 33(1)(c)) - Where applicable, provide means enabling interoperability of tools automating data sharing agreements, including smart contracts (Art. 33(1)(d)) ### Data Space Standards and Common Specifications - Commission may adopt delegated acts to further specify the Article 33(1) essential requirements, taking EDIB advice into account (Art. 33(2), Art. 42) - Harmonised standards and common specifications can create a presumption of conformity for the requirements they cover (Art. 33(3), Art. 33(8)) - Commission may request harmonised standards and, where standards are unavailable or insufficient, adopt common specifications by implementing acts (Art. 33(4)-(7)) - Commission may adopt guidelines on interoperable frameworks for common European data spaces (Art. 33(11)) ### Parallel Use of Data Processing Services - Switching-related requirements also apply to facilitate interoperability for the purposes of in-parallel use of data processing services (Art. 34(1)) - Providers may impose data egress charges for parallel use only to pass through egress costs, without exceeding those costs (Art. 34(2)) ### Interoperability Standards for Data Processing Services - Interoperability specs and harmonised standards should enable interoperability for the same service type, enhance portability of digital assets, and facilitate functional equivalence where feasible (Art. 35(1)) - They should not harm security and integrity and should allow technical advances and innovation (Art. 35(1)(d)-(e)) - Standards should address transport, syntactic, semantic, behavioural and policy interoperability, plus data and application portability aspects (Art. 35(2)) - Commission may request harmonised standards, adopt common specifications, and publish references in a central Union standards repository (Art. 35(4)-(5), Art. 35(8)) ### Smart Contracts for Data Sharing Agreements - Smart contracts used to execute data sharing agreements must meet essential requirements on robustness, access control, safe termination, auditability, and consistency with the executed agreement (Art. 36(1)) - Vendor or deployer must perform a conformity assessment and issue an EU declaration of conformity and is responsible for compliance (Art. 36(2)-(3)) - Harmonised standards and common specifications can create a presumption of conformity (Art. 36(4)-(6)) ### Competent Authorities and Legal Representative - Each Member State designates competent authorities for enforcement, and if more than one is designated, a data coordinator is appointed (Art. 37(1)-(2)) - GDPR supervisory authorities monitor Data Act compliance for personal data aspects, and the EDPS monitors EU institutions where relevant (Art. 37(3)) - Competent authorities handle complaints and investigations, cooperate cross-border, ensure switching charges withdrawal, and examine Chapter V requests (Art. 37(5)(b)-(j)) - Competence is the Member State where the entity is established. If the entity is established in more than one Member State, competence is the Member State of its main establishment, meaning the head office or registered office from which principal financial functions and operational control are exercised (Art. 37(10)) - Any entity falling within scope that makes connected products available or offers services in the Union, and which is not established in the Union, shall designate a legal representative in one Member State (Art. 37(11)) - The legal representative is mandated to be addressed by competent authorities in addition to or instead of the entity, and must cooperate and demonstrate compliance actions upon request (Art. 37(12)) - Such an entity is considered to be under the competence of the Member State where its legal representative is located. Until a legal representative is designated, it can be under the competence of all Member States, depending on the facts (Art. 37(13)) ### Complaints and Judicial Remedies - Natural and legal persons can lodge complaints in their Member State of habitual residence, place of work, or establishment (Art. 38(1)) - Data coordinators must provide information on how to lodge complaints, and authorities must inform complainants of progress and decisions (Art. 38(1)-(2)) - Authorities cooperate to handle complaints effectively, including via electronic information exchange, including cross-border cases (Art. 38(3)) - There is a right to an effective judicial remedy against legally binding decisions, and when authorities fail to act (Art. 39) ### Penalties - Member States set penalties for infringements and must ensure they are effective, proportionate and dissuasive (Art. 40(1)) - Penalty rules must be notified to the Commission by 12 September 2025 (Art. 40(2)) - When imposing penalties, Member States must take into account EDIB recommendations (Art. 40(3)) - Non-exhaustive penalty criteria include nature, gravity, scale and duration; mitigation or remedy actions; prior infringements; and other aggravating or mitigating factors (Art. 40(3)) - Also consider financial benefits gained or losses avoided and annual EU turnover (Art. 40(3)) - For certain infringements in Chapters II, III and V, GDPR supervisory authorities can impose administrative fines under GDPR Article 83 up to Art. 83(5) amounts (Art. 40(4)) - For certain Chapter V infringements by EU institutions, the EDPS can impose fines under Regulation (EU) 2018/1725 (Art. 40(5)) ### Model Contractual Terms and Cloud Clauses - Commission will develop and recommend non-binding model contractual terms on data access and use, including compensation and trade secret protection, before 12 September 2025 (Art. 41) - Commission will also develop and recommend non-binding standard contractual clauses for cloud computing contracts, before 12 September 2025 (Art. 41) ### Database Right Limitation - The sui generis database right does not apply when data is obtained from or generated by a connected product or related service in scope, especially for user access and third-party sharing under Articles 4 and 5 (Art. 43) ### Consumer Protection and Representative Actions - The Data Act is added to the list of laws enforceable under the Consumer Protection Cooperation Regulation (EU) 2017/2394 (Art. 47) - The Data Act is added to Annex I of Directive (EU) 2020/1828 on representative actions for the protection of consumers' collective interests (Art. 48) ### Delegated Acts and Committee Procedure - Commission delegated powers for Article 29(7) and Article 33(2) apply from 11 Jan 2024 for an indeterminate period (Art. 45(2)) - The European Parliament or the Council can revoke the delegation; delegated acts take effect only if no objection is raised within 3 months (extendable by 3 months) (Art. 45(3), Art. 45(6)) - The Commission is assisted by the Committee established by Regulation (EU) 2022/868, under Regulation (EU) No 182/2011 (Art. 46) ### European Data Innovation Board (EDIB) role (Article 42) - EDIB supports consistent application of the Data Act by advising the Commission on enforcement practice for Chapters II, III, V and VII (Art. 42(a)) - EDIB facilitates cooperation between competent authorities, including methods for cross-border information exchange and coordination on penalties (Art. 42(b)) - EDIB advises the Commission on standards requests, implementing acts, delegated acts, and data space interoperability frameworks (Art. 42(c)) ### Interaction With Other EU Data Access Laws - Specific Union acts with data access and sharing obligations that entered into force on or before 11 Jan 2024 remain unaffected, including B2B, B2C and exceptional B2G regimes (Art. 44(1)) - Sector-specific Union law may set further requirements, including technical aspects of access, limits on certain data holder rights, and rules going beyond access and use (Art. 44(2)) - Except for Chapter V, the Data Act is without prejudice to Union and national law on data access and use for scientific research purposes (Art. 44(3)) ### Entry into Force and Application Dates - Enters into force 20 days after OJ publication; OJ publication date is 22 December 2023, so entry into force is 11 January 2024 (Art. 50) - Applies from 12 September 2025 (Art. 50) - The design obligation in Article 3(1) applies to connected products and related services placed on the market after 12 September 2026 (Art. 50) - Chapter III applies in relation to statutory obligations to make data available that enter into force after 12 September 2025 (Art. 50) - Chapter IV applies to contracts concluded after 12 September 2025 (Art. 50) - From 12 September 2027, Chapter IV also applies to contracts concluded on or before 12 September 2025 that are of indefinite duration, or due to expire at least 10 years from 11 January 2024 (Art. 50) ## Possible Outcomes ### [RESULT] Out of Data Act Scope The Data Act does not apply to this scenario - None of the categories in Article 1(3) apply to your scenario, so the Data Act does not apply to you for that scenario. - If your situation changes, for example you place connected products on the Union market or provide data processing services to customers in the Union, reassess scope. ### [NEXT] Data Act Compliance Checklist Map your roles, data, and contracts, then implement the relevant chapters - Identify your roles: connected product or related service manufacturer or provider, data holder, data recipient, third party recipient, cloud provider, data space participant, or smart contract vendor or deployer - Inventory product data, related service data and metadata, and ensure you can provide readily available data in structured and machine-readable formats - Implement user access and sharing workflows, with clear safeguards for security and trade secrets - Update contracts for fair, reasonable and non-discriminatory terms, compensation, trade secret measures, and cloud switching clauses where relevant - Prepare playbooks for exceptional-need requests and for third-country access requests affecting non-personal data - Track application dates and Member State enforcement guidance ## Data Act Timeline | Date | Event | Reference | | --- | --- | --- | | 2020-02-19 | European Strategy for Data published | COM(2020) 66 | | 2022-02-23 | Commission proposal for the Data Act published | COM(2022) 68 | | 2023-06-27 | Council and Parliament reach a provisional agreement (political agreement) | Council press release | | 2023-11-09 | European Parliament position adopted | OJ L 2023/2854 note (4) | | 2023-11-27 | Council decision adopted | OJ L 2023/2854 note (4) | | 2023-12-13 | Regulation (EU) 2023/2854 dated 13 December 2023 | Reg. 2023/2854 | | 2023-12-22 | Published in the Official Journal (OJ L, 22.12.2023) | Reg. 2023/2854 | | 2024-01-11 | Enters into force (20 days after publication) | Art. 50 | | 2024-01-11 | Start of reduced switching charges period for the switching process | Art. 29(2) | | 2024-01-11 | Delegated act powers for Articles 29(7) and 33(2) begin | Art. 45(2) | | 2025-07-01 | Commission Implementing Decision on standardisation request adopted (European Trusted Data Framework) | C(2025) 4135 | | 2025-07-07 | CEN and CENELEC accept the Standardisation Request under Mandate M/614 | M/614 (CEN-CENELEC) | | 2025-09-12 | Data Act starts applying (general application date) | Art. 50 | | 2025-09-12 | Operational timing rules apply (for example user access without undue delay, B2G response windows, cloud switching contract periods) | Art. 4(1), Art. 17(1)(i), Art. 18(2), Art. 25 | | 2025-09-12 | Chapter III applies only to statutory data-sharing obligations entering into force after this date | Art. 50 | | 2025-09-12 | Chapter IV applies to contracts concluded after this date | Art. 50 | | 2025-09-12 | Deadline: Member States notify penalties rules to the Commission | Art. 40(2) | | 2025-09-12 | Deadline: Commission develops and recommends non-binding model contractual terms and non-binding standard contractual clauses for cloud contracts | Art. 41 | | 2026-03-01 | Standardisation deadline: technical specification on a data catalogue implementation framework due | C(2025) 4135 Annex I | | 2026-06-01 | Standardisation deadline: Trusted Data Transactions harmonised standards Part 1 due | C(2025) 4135 Annex I | | 2026-09-01 | Standardisation deadlines: technical specifications on semantic assets and a maturity model for Common European Data Spaces due | C(2025) 4135 Annex I | | 2026-09-12 | Article 3(1) design obligation applies to connected products and related services placed on the market after this date | Art. 50 | | 2026-11-01 | Standardisation deadline: Trusted Data Transactions harmonised standards Part 2 due | C(2025) 4135 Annex I | | 2027-01-12 | Switching charges prohibited for the switching process | Art. 29(1) | | 2027-03-01 | Standardisation deadline: European standard on a quality framework for internal data governance due | C(2025) 4135 Annex I | | 2027-05-01 | Standardisation deadline: Trusted Data Transactions harmonised standards Part 3 due | C(2025) 4135 Annex I | | 2027-09-12 | Chapter IV extends to certain contracts concluded on or before 12 Sep 2025 (indefinite duration or expiring at least 10 years from 11 Jan 2024) | Art. 50 | | 2028-09-12 | Commission evaluation due | Art. 49 | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2023-11-09 | European Parliament position adopted | Legislative History | | | 2023-11-27 | Council decision adopted | Legislative History | | | 2023-12-13 | Regulation adopted (Data Act) | Legislative History | | | 2023-12-22 | Published in Official Journal | Official Publication | | | 2024-01-11 | Entry into force | Official Publication | | | 2024-01-11 | Reduced switching charges period | Cloud Switching | Art. 29(2) | | 2024-01-11 | Delegated powers conferred | Commission Deliverables | Art. 45(2) | | 2024-09-06 | Commission publishes Data Act FAQs | Commission Deliverables | | | 2025-07-01 | Commission standardisation request (European Trusted Data Framework) | Standardisation | | | 2025-07-07 | CEN and CENELEC accept the standardisation request (Mandate M/614) | Standardisation | | | 2025-09-12 | Data Act applies | Applicability | | | 2025-09-12 | Member States notify penalties rules | Member State Duties | Art. 40(2) | | 2025-09-12 | Model contractual terms and cloud clauses deadline | Commission Deliverables | Art. 41 | | 2025-09-15 | Commission guidance on vehicle data (C/2025/5026) | Commission Deliverables | | | 2025-12-16 | Commission launches Data Act legal helpdesk | Commission Deliverables | | | 2026-01-22 | Data Act FAQs updated (v1.4) | Commission Deliverables | | | 2026-03-01 | Data catalogue technical specification deadline | Standardisation | | | 2026-06-01 | Trusted data transactions standards Part 1 deadline | Standardisation | | | 2026-09-01 | European Trusted Data Framework deliverables deadline | Standardisation | | | 2026-09-12 | Connected product access-by-design obligations | Applicability | | | 2026-11-01 | Trusted data transactions standards Part 2 deadline | Standardisation | | | 2027-01-12 | Switching charges prohibited | Cloud Switching | Art. 29(1) | | 2027-03-01 | Internal data governance quality framework standard deadline | Standardisation | | | 2027-05-01 | Trusted data transactions standards Part 3 deadline | Standardisation | | | 2027-09-12 | Chapter IV extends to older contracts | Applicability | | | 2028-09-12 | Commission evaluation report deadline | Commission Deliverables | Art. 49(1) | **Event details:** - **2023-11-09 - European Parliament position adopted**: The Regulation records the European Parliament position of 9 November 2023 in the legislative history footnote. - **2023-11-27 - Council decision adopted**: The Regulation records the Council decision of 27 November 2023 in the legislative history footnote. - **2023-12-13 - Regulation adopted (Data Act)**: Regulation (EU) 2023/2854 is adopted and signed in Strasbourg. - **2023-12-22 - Published in Official Journal**: Regulation (EU) 2023/2854 is published in the Official Journal (OJ L, 2023/2854, 22.12.2023). - **2024-01-11 - Entry into force**: The Data Act enters into force on the twentieth day following publication in the Official Journal. - **2024-01-11 - Reduced switching charges period**: From 11 January 2024 to 12 January 2027, providers of data processing services may impose reduced switching charges for the switching process. - **2024-01-11 - Delegated powers conferred**: The Commission is conferred the power to adopt delegated acts for an indeterminate period of time from 11 January 2024 for specified delegated powers under the Regulation. - **2024-09-06 - Commission publishes Data Act FAQs**: The Commission publishes Frequently Asked Questions about the Data Act to support implementation. - **2025-07-01 - Commission standardisation request (European Trusted Data Framework)**: Commission Implementing Decision of 1 July 2025 issues a standardisation request to CEN, CENELEC and ETSI in support of the Data Act (C(2025) 4135 final). - **2025-07-07 - CEN and CENELEC accept the standardisation request (Mandate M/614)**: CEN and CENELEC accept the Commission standardisation request on the European Trusted Data Framework (Mandate M/614). - **2025-09-12 - Data Act applies**: The Data Act applies from 12 September 2025. - **2025-09-12 - Member States notify penalties rules**: Member States notify the Commission of penalties rules and measures by 12 September 2025. - **2025-09-12 - Model contractual terms and cloud clauses deadline**: Before 12 September 2025, the Commission develops and recommends non-binding model contractual terms on data access and use and non-binding standard contractual clauses for cloud computing contracts. - **2025-09-15 - Commission guidance on vehicle data (C/2025/5026)**: The Commission publishes guidance on vehicle data accompanying the Data Act (OJ C, 15.9.2025). - **2025-12-16 - Commission launches Data Act legal helpdesk**: The Commission launches a Data Act Legal Helpdesk to support stakeholders with practical implementation questions. - **2026-01-22 - Data Act FAQs updated (v1.4)**: The Commission updates the Data Act FAQs page and publishes FAQs Data Act version 1.4 dated 22 January 2026. - **2026-03-01 - Data catalogue technical specification deadline**: Deadline for adoption of technical specification(s) on a data catalogue implementation framework (Annex I). - **2026-06-01 - Trusted data transactions standards Part 1 deadline**: Deadline for adoption of harmonised standards on Trusted Data Transactions Part 1: terminology, concepts and mechanisms (Annex I). - **2026-09-01 - European Trusted Data Framework deliverables deadline**: Deadline for adoption of technical specification(s) on semantic assets and technical specification(s) on a maturity model for Common European Data Spaces (Annex I). - **2026-09-12 - Connected product access-by-design obligations**: The obligation resulting from Article 3(1) applies to connected products and related services placed on the market after 12 September 2026. - **2026-11-01 - Trusted data transactions standards Part 2 deadline**: Deadline for adoption of harmonised standards on Trusted Data Transactions Part 2: trustworthiness requirements (Annex I). - **2027-01-12 - Switching charges prohibited**: From 12 January 2027, providers of data processing services shall not impose any switching charges on the customer for the switching process. - **2027-03-01 - Internal data governance quality framework standard deadline**: Deadline for adoption of the European standard on a quality framework for internal data governance (Annex I). - **2027-05-01 - Trusted data transactions standards Part 3 deadline**: Deadline for adoption of harmonised standards on Trusted Data Transactions Part 3: interoperability requirements (Annex I). - **2027-09-12 - Chapter IV extends to older contracts**: Chapter IV applies from 12 September 2027 to certain contracts concluded on or before 12 September 2025 (indefinite duration or expiring at least 10 years from 11 January 2024). - **2028-09-12 - Commission evaluation report deadline**: By 12 September 2028, the Commission carries out an evaluation of the Regulation and submits a report to the European Parliament and the Council. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act --- --- title: "EU Deforestation Regulation (EUDR) Guide: Key Dates, Due Diligence Statement, Geolocation, Traceability" canonical_url: "https://www.sorena.io/artifacts/eu-deforestation" source_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation" author: "Sorena AI" description: "A practical EU Deforestation Regulation (EUDR) hub with key dates, a decision flow, and grounded guidance on scope, operator and trader roles." published_at: "2026-02-22" updated_at: "2026-02-23" keywords: - "EUDR" - "EU Deforestation Regulation" - "deforestation free products" - "Regulation (EU) 2023/1115" - "due diligence statement" - "simplified declaration" - "geolocation coordinates" - "plot of land geolocation" - "traceability system" - "operator downstream operator trader" - "relevant commodities and products Annex I" - "negligible risk assessment" - "risk mitigation measures" - "benchmarking list low risk high risk" - "Deforestation" - "Due diligence" - "Supply chain" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Deforestation Regulation (EUDR) Guide: Key Dates, Due Diligence Statement, Geolocation, Traceability A practical EU Deforestation Regulation (EUDR) hub with key dates, a decision flow, and grounded guidance on scope, operator and trader roles. ![EU deforestation regulation artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-deforestation-timeline-small.jpg?v=cheatsheets%2Fprod) *EUDR* *Free Resource* ## EU Deforestation Regulation Timeline and Decision Flow Use this artifact to confirm whether your commodities and products are in scope, identify your role, and plan due diligence statements, simplified declarations, geolocation evidence, traceability systems, risk assessment, and supplier controls. This reference reflects the consolidated EUDR text in force on 26 December 2025, including the main 30 December 2026 application date and the later 30 June 2027 date for certain micro and small operators. [Get help with EUDR compliance](/contact.md) ## What you can decide faster - **Is it covered**: Relevant commodities and products checks. - **Your role**: Operator, downstream operator, and trader duties. - **What to evidence**: Traceability data, geolocation, and risk controls. By Sorena AI | Updated Feb 2026 | No signup required ### Quick scan *EUDR* - **Scope**: Map products and commodities to in scope status. - **Due diligence**: Plan statements, risk checks, and mitigation steps. - **Data readiness**: Align supplier data and traceability requirements. Use the decision flow to align sourcing, legal, operations, and supplier teams on a workable approach. | Value | Metric | | --- | --- | | 2023 | Regulation | | DDS | Statement | | Geo | Data | | Risk | Controls | **Key highlights:** Scope first | Geolocation data | Due diligence ## Topic Guides - [Applicability Test | EU Deforestation Regulation (EUDR): In-Scope Products, Roles, Dates](/artifacts/eu/deforestation-regulation/applicability-test.md): A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator. - [Compliance Program | EUDR Implementation Playbook: Governance, Controls, Supplier Onboarding, Evidence](/artifacts/eu/deforestation-regulation/compliance.md): Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline. - [Deadlines and Compliance Calendar | EUDR Key Dates 2024 to 2029](/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar.md): EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing. - [Deadlines, Phasing, and What to Do First | EUDR Implementation Plan (90 Days -> Go-Live)](/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first.md): A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence. - [Due Diligence Statement (DDS) and Evidence Pack | EUDR: What to Collect, Store, and Prove](/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence.md): EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream. - [EUDR Checklist | EU Deforestation Regulation Compliance Checklist (Scope -> DDS -> Evidence)](/artifacts/eu/deforestation-regulation/checklist.md): A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline. - [EUDR Due Diligence Statement Template | Copy/Paste DDS Structure and Evidence Checklist](/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template.md): A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data. - [EUDR vs CSDDD | What's Different, What Overlaps, and How to Build One Evidence Program](/artifacts/eu/deforestation-regulation/eudr-vs-csddd.md): EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions. - [FAQ | EUDR Explained: Scope, Roles, DDS Reference Numbers, Geolocation, Risk Mitigation, Penalties](/artifacts/eu/deforestation-regulation/faq.md): EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is. - [Geolocation Data Requirements | EUDR: Plots of Land, Establishments, Validation, Exceptions](/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements.md): EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments). - [Geolocation, Traceability, and Systems | EUDR Technical Architecture and Data Model](/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems.md): Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows. - [In-Scope Commodities and Products (Annex I) | EUDR Scope Mapping Guide](/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products.md): EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends. - [Penalties and Enforcement | EUDR Enforcement Actions, Corrective Measures, Interim Measures, Reporting](/artifacts/eu/deforestation-regulation/penalties-and-enforcement.md): How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension). - [Penalties and Fines | EUDR Penalty Framework (Article 25): Turnover-Based Fines and Other Measures](/artifacts/eu/deforestation-regulation/penalties-and-fines.md): EUDR penalties explained (Article 25): Member State penalty rules. - [Requirements | EU Deforestation Regulation (EUDR) Obligations: Due Diligence, Geolocation, Traceability, Roles](/artifacts/eu/deforestation-regulation/requirements.md): A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a. - [Risk Assessment and Mitigation | EUDR Due Diligence (Articles 10-11) Playbook](/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation.md): EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier. ## Key dates for due diligence planning *EUDR Timeline* Use these dates to plan data readiness, supplier onboarding, and operational rollout for due diligence statements, benchmarking, and application deadlines. ## Does the regulation apply to your products *EUDR Decision Flow* Follow a structured path to confirm scope and supply chain role (operator, downstream operator, or trader), then use the outcomes to prioritize due diligence steps and evidence. *Next step* ## Turn EU Deforestation Regulation Timeline and Decision Flow into an ESG delivery workflow EU Deforestation Regulation Timeline and Decision Flow should be the shared entry point for your team. Route execution into ESG Compliance for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU Deforestation Regulation Timeline and Decision Flow and route the work by entity, product, team, or control owner. - Use ESG Compliance to manage cross team sustainability work, reporting, and evidence from one workflow. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open ESG Compliance](/solutions/esg-compliance.md): Manage cross team sustainability work, reporting, and evidence from one workflow for EU Deforestation Regulation Timeline and Decision Flow. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share the scope logic internally. - **Download timeline**: Coordinate milestones across teams. - [Talk through EU Deforestation Regulation Timeline and Decision Flow](/contact.md): Review your current process, evidence model, and next steps for EU Deforestation Regulation Timeline and Decision Flow. ## Decision Steps ### STEP 1: Are you placing on the EU market, making available on the EU market, or exporting a product covered by the EUDR? *Reference: Reg. (EU) 2023/1115 Art. 1, Art. 3 and Annex I* - The EUDR applies to certain commodities and derived products listed in Annex I. - Covered commodities include: cattle, cocoa, coffee, oil palm, rubber, soya, and wood, plus listed derived products. - If yes: determine whether you are an operator, downstream operator, or trader and what you must do before placing on the market, making available, or exporting. - If no: the EUDR due diligence duties do not apply to that product flow. - **YES** Are you placing relevant products on the EU market or exporting them? - **NO** Out of Scope ### STEP 2: Are you placing relevant products on the EU market or exporting them? *Reference: Reg. (EU) 2023/1115 Art. 2 (definitions)* - If yes: you are either an operator or a downstream operator. Next, confirm whether you are placing products already covered by upstream due diligence. - If no: if you are making relevant products available on the EU market, you may be a trader. - **YES** Are you placing on the market or exporting relevant products made using relevant products that are already covered by a due diligence statement or simplified declaration? - **NO** Are you a trader making relevant products available on the EU market? ### STEP 3: Are you placing on the market or exporting relevant products made using relevant products that are already covered by a due diligence statement or simplified declaration? *Reference: Reg. (EU) 2023/1115 Art. 2 (downstream operator) and Art. 5* - If yes: you are a downstream operator and must follow the downstream operator obligations. - If no: you are an operator and must follow the operator obligations (including due diligence and due diligence statements), unless you qualify for the micro or small primary operator simplified regime. - **YES** Are you a micro or small undertaking (SME) for EUDR purposes? - **NO** Are you a micro or small primary operator? ### STEP 4: Are you a micro or small primary operator? *Reference: Reg. (EU) 2023/1115 Art. 2 (micro or small primary operator) and Art. 4a* - Micro or small primary operators have a simplified regime, including a one-time simplified declaration submitted in the information system (Art. 33). - If yes: follow the micro or small primary operator track. - If no: follow the standard operator due diligence track. - **YES** EUDR Applies (Micro or small primary operator) - **NO** EUDR Applies (Operator) ### STEP 5: Are you a trader making relevant products available on the EU market? *Reference: Reg. (EU) 2023/1115 Art. 2 (trader) and Art. 5* - Traders are supply chain actors (other than operators or downstream operators) that make relevant products available on the market. - If yes: determine whether you are micro or small for the registration requirement and follow the trader obligations track. - If no: you may be out of scope for this flow. - **YES** Are you a micro or small undertaking (SME) for EUDR purposes? - **NO** Out of Scope ### STEP 6: Are you a micro or small undertaking (SME) for EUDR purposes? *Reference: Reg. (EU) 2023/1115 Art. 5(2) and Directive 2013/34/EU Art. 3* - Under Article 5(2), registration in the information system applies to non-SME downstream operators and non-SME traders. - If yes: SME downstream operator obligations apply (no registration requirement under Art. 5(2), but core traceability duties still apply). - If no: non-SME downstream operator obligations apply (including registration under Art. 5(2)). - **YES** EUDR Applies (Downstream operator, micro or small) - **NO** EUDR Applies (Downstream operator, not micro or small) ### STEP 7: Are you a micro or small undertaking (SME) for EUDR purposes? *Reference: Reg. (EU) 2023/1115 Art. 5(2) and Directive 2013/34/EU Art. 3* - Under Article 5(2), registration in the information system applies to non-SME downstream operators and non-SME traders. - If yes: SME trader obligations apply (no registration requirement under Art. 5(2), but core traceability duties still apply). - If no: non-SME trader obligations apply (including registration under Art. 5(2)). - **YES** EUDR Applies (Trader, micro or small) - **NO** EUDR Applies (Trader, not micro or small) ## Reference Information ### Covered commodities and derived products - Start with Annex I: it lists commodities and derived products in scope. - If the commodity or product is not listed in Annex I, EUDR due diligence is not required for that item. - If it is listed, proceed to determine role and complete required steps before placing on the market, making available, or exporting. ### Key roles under the EUDR - Operator: places relevant products on the market or exports them (excluding downstream operators). - Downstream operator: places on the market or exports relevant products made using relevant products that are already covered by a due diligence statement or a simplified declaration. - Trader: makes relevant products available on the market and is not an operator or downstream operator. ### Due diligence in three steps - Information (Art. 9): collect and keep information and evidence (including geolocation) showing products comply with Art. 3. - Risk assessment (Art. 10): assess risk of non-compliance and do not place/export unless risk is no or negligible. - Risk mitigation (Art. 11): where risk is not negligible, mitigate risk before placing/exporting. ### Country benchmarking and simplified due diligence - The Commission will classify countries or parts thereof as low, standard, or high risk under the benchmarking system (Art. 29). - Simplified due diligence may be available for low risk production (Art. 13), but operators remain responsible for compliance. - Your due diligence process should explicitly record the risk level and how it affects checks and evidence collected. ### Authorized representatives - Operators may mandate an authorized representative to submit a due diligence statement (Art. 4(2)) or a simplified declaration (Art. 4a(2)) on their behalf (Art. 6). - The operator retains responsibility for compliance with Art. 3. ### Downstream operators and traders (core obligations) - Before placing, making available, or exporting: be in possession of the required information (Art. 5(1) and Art. 5(3)). - Non-SME downstream operators and non-SME traders must register in the information system before placing, making available, or exporting (Art. 5(2)). - Collect and keep supply chain information, including upstream details and, where the supplier is an operator, due diligence statement reference numbers or declaration identifiers (Art. 5(3)). - Keep the required information for at least five years and provide it to competent authorities on request (Art. 5(4)). ## Possible Outcomes ### [RESULT] EUDR Applies (Operator) Exercise due diligence and submit a due diligence statement before placing on the market or exporting - Do not place on the market or export covered products unless they are deforestation free, produced in accordance with relevant legislation of the country of production, and covered by a due diligence statement or simplified declaration (Art. 3). - Exercise due diligence before placing on the market or exporting (Art. 4(1) and Art. 8). - Submit a due diligence statement through the information system before placing on the market or exporting (Art. 4(2) and Art. 33). - Keep required records and documentation for at least five years and provide them to competent authorities on request (Art. 4(3) and Art. 9). - Communicate due diligence statement reference numbers (or declaration identifiers) to downstream operators and traders further down the supply chain (Art. 4). ### [RESULT] EUDR Applies (Micro or small primary operator) Use the simplified regime (one-time simplified declaration) and still ensure compliance - Submit a one-time simplified declaration in the information system before placing relevant products on the market or exporting them, and obtain a declaration identifier (Art. 4a(2) and Art. 33). - Provide the information set out in Annex III and update it following major changes (Art. 4a(3)). - Place on the market or export only after being assigned a declaration identifier (Art. 4a(4)). - Where applicable, geolocation under Art. 9(1)(d) may be replaced by postal address of plots of land or the establishment (Art. 4a(5)). ### [RESULT] EUDR Applies (Downstream operator, not micro or small) Register, collect required information, keep records, and verify risk signals - Register in the information system before placing, making available, or exporting (Art. 5(2) and Art. 33). - Collect and keep the required supply chain information (Art. 5(3)). - Keep required information for at least five years and provide it to competent authorities on request (Art. 5(4)). - If you obtain relevant information indicating non-compliance prior to placing/making available/exporting, inform competent authorities and, for substantiated concerns, verify due diligence and do not proceed unless verification demonstrates no or negligible risk (Art. 5(6)). ### [RESULT] EUDR Applies (Downstream operator, micro or small) Collect required information and keep records (no registration requirement under Art. 5(2)) - Collect and keep the required supply chain information (Art. 5(3)). - Keep required information for at least five years and provide it to competent authorities on request (Art. 5(4)). - If you obtain relevant new information indicating a product you placed or made available is at risk of non-compliance, inform competent authorities and downstream recipients (Art. 5(5)). ### [RESULT] EUDR Applies (Trader, not micro or small) Register, collect required information, keep records, and verify risk signals - Register in the information system before placing, making available, or exporting (Art. 5(2) and Art. 33). - Collect and keep the required supply chain information (Art. 5(3)). - Keep required information for at least five years and provide it to competent authorities on request (Art. 5(4)). - If you obtain relevant information indicating non-compliance prior to placing/making available/exporting, inform competent authorities and, for substantiated concerns, verify due diligence and do not proceed unless verification demonstrates no or negligible risk (Art. 5(6)). ### [RESULT] EUDR Applies (Trader, micro or small) Collect required information and keep records (no registration requirement under Art. 5(2)) - Collect and keep the required supply chain information (Art. 5(3)). - Keep required information for at least five years and provide it to competent authorities on request (Art. 5(4)). - If you obtain relevant new information indicating a product you made available is at risk of non-compliance, inform competent authorities and downstream recipients (Art. 5(5)). ### [RESULT] Out of Scope EUDR due diligence is not required for this flow - The product is not covered by Annex I, or you are not placing on the EU market, making available on the EU market, or exporting a covered product in this scenario. - Confirm whether other EU product or supply chain requirements apply to your product flow. ## EUDR Timeline (Key Dates) | Date | Event | Reference | | --- | --- | --- | | 2023-06-29 | EUDR enters into force | Art. 38(1) | | 2024-12-30 | Commission information system due (due diligence statements) | Art. 33 | | 2025-06-30 | Benchmarking list deadline (low and high risk countries) | Art. 29 | | 2026-12-30 | Core obligations start applying (most operators and traders) | Art. 38(2) | | 2027-06-30 | Core obligations start applying for certain micro and small undertakings | Art. 38(3) | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2023-05-31 | EUDR adopted | Legislative History | Regulation (EU) 2023/1115 | | 2023-06-09 | EUDR published in the Official Journal (OJ L 150) | Official Publication | | | 2023-06-29 | EUDR enters into force | Official Publication | Art. 38(1) | | 2023-06-29 | All countries assigned standard risk (benchmarking) | Implementation Deliverables | Art. 29 | | 2023-12-30 | Member States notify competent authorities | Implementation Deliverables | Art. 14(2) | | 2024-12-04 | Commission Implementing Regulation (EU) 2024/3084 adopted | Implementation Deliverables | Regulation (EU) 2024/3084 | | 2024-12-09 | Commission Implementing Regulation (EU) 2024/3084 enters into force | Implementation Deliverables | | | 2024-12-19 | Amending Regulation (EU) 2024/3234 adopted | Amendments | Regulation (EU) 2024/3234 | | 2024-12-26 | Amending Regulation (EU) 2024/3234 enters into force | Amendments | | | 2024-12-30 | Commission information system due (due diligence statements) | Implementation Deliverables | Art. 33 | | 2025-06-30 | Country benchmarking list deadline (low and high risk) | Implementation Deliverables | Art. 29 | | 2025-12-19 | Amending Regulation (EU) 2025/2650 adopted | Amendments | Regulation (EU) 2025/2650 | | 2025-12-26 | Amending Regulation (EU) 2025/2650 enters into force | Amendments | | | 2026-02-12 | Corrigendum to Regulation (EU) 2025/2650 published | Amendments | Corrigendum | | 2026-12-30 | Due diligence obligations start applying for most operators and traders | Applicability | Art. 38(2) | | 2026-12-30 | EU Timber Regulation repealed | Applicability | Art. 37(1) | | 2027-06-30 | Due diligence obligations start applying for certain micro and small undertakings | Applicability | Art. 38(3) | | 2029-12-31 | EU Timber Regulation continues to apply for certain timber until this date | Applicability | Art. 37(2) | **Event details:** - **2023-05-31 - EUDR adopted**: The EU adopts Regulation (EU) 2023/1115 on deforestation-free products, setting due diligence obligations for certain commodities and derived products placed on, made available on, or exported from the EU market. - **2023-06-09 - EUDR published in the Official Journal (OJ L 150)**: Regulation (EU) 2023/1115 is published in the Official Journal of the European Union. - **2023-06-29 - EUDR enters into force**: The Regulation enters into force on the twentieth day following its publication in the Official Journal of the European Union. - **2023-06-29 - All countries assigned standard risk (benchmarking)**: All countries are assigned a standard level of risk under the EUDR benchmarking system as of this date, pending the publication of low and high risk classifications. - **2023-12-30 - Member States notify competent authorities**: Member States must inform the Commission of the names, addresses, and contact details of their designated competent authorities by this date. - **2024-12-04 - Commission Implementing Regulation (EU) 2024/3084 adopted**: The Commission adopts implementing rules on the functioning of the EUDR information system. - **2024-12-09 - Commission Implementing Regulation (EU) 2024/3084 enters into force**: Implementing rules on the functioning of the EUDR information system enter into force. - **2024-12-19 - Amending Regulation (EU) 2024/3234 adopted**: The EU adopts Regulation (EU) 2024/3234 amending Regulation (EU) 2023/1115 as regards provisions related to the date of application. - **2024-12-26 - Amending Regulation (EU) 2024/3234 enters into force**: Regulation (EU) 2024/3234 enters into force. - **2024-12-30 - Commission information system due (due diligence statements)**: The Commission must establish and maintain an information system containing due diligence statements made available through the system. - **2025-06-30 - Country benchmarking list deadline (low and high risk)**: The Commission must publish, by implementing act, the list of countries or parts thereof that present a low or high risk under the benchmarking system (all countries are assigned standard risk initially). - **2025-12-19 - Amending Regulation (EU) 2025/2650 adopted**: The EU adopts Regulation (EU) 2025/2650 amending Regulation (EU) 2023/1115 as regards certain obligations for operators and traders. - **2025-12-26 - Amending Regulation (EU) 2025/2650 enters into force**: Regulation (EU) 2025/2650 enters into force. - **2026-02-12 - Corrigendum to Regulation (EU) 2025/2650 published**: An Official Journal corrigendum is published for Regulation (EU) 2025/2650. - **2026-12-30 - Due diligence obligations start applying for most operators and traders**: Core due diligence and related obligations apply from this date for operators and traders, subject to the specific conditions and derogations stated in the Regulation. - **2026-12-30 - EU Timber Regulation repealed**: Regulation (EU) No 995/2010 is repealed with effect from this date. - **2027-06-30 - Due diligence obligations start applying for certain micro and small undertakings**: For certain operators that are natural persons or micro or small undertakings (as defined) established by 31 December 2024, core obligations apply from this later date, subject to the conditions stated in the Regulation. - **2029-12-31 - EU Timber Regulation continues to apply for certain timber until this date**: For certain timber and timber products produced before 29 June 2023 and placed on the market from 30 December 2026, Regulation (EU) No 995/2010 continues to apply until this date. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/deforestation-regulation --- --- title: "EU DMA Timeline and Gatekeeper Decision Flow (Articles 5-7)" canonical_url: "https://www.sorena.io/artifacts/eu-dma" source_url: "https://www.sorena.io/artifacts/eu/digital-markets-act" author: "Sorena AI" description: "A practical EU Digital Markets Act (DMA) artifact with key dates, the current gatekeeper landscape, and a gatekeeper decision flow: CPS scope." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "DMA" - "Digital Markets Act" - "Regulation (EU) 2022/1925" - "EU Digital Markets Act timeline" - "gatekeeper designation" - "gatekeeper thresholds" - "core platform services" - "CPS" - "DMA compliance checklist" - "Article 5 obligations" - "Article 6 obligations" - "Article 7 interoperability" - "choice screens" - "default settings" - "third-party app stores" - "self-preferencing" - "ranking neutrality" - "data portability" - "business user data access" - "online advertising transparency" - "enforcement" - "fines" - "periodic penalty payments" - "Gatekeepers" - "Platform regulation" - "Compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DMA Timeline and Gatekeeper Decision Flow (Articles 5-7) A practical EU Digital Markets Act (DMA) artifact with key dates, the current gatekeeper landscape, and a gatekeeper decision flow: CPS scope. ![EU DMA artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-dma-timeline-small.jpg?v=cheatsheets%2Fprod) *DMA* *Free Resource* ## EU Digital Markets Act Timeline and Decision Flow Use this artifact to understand gatekeeper designation under the DMA, the current gatekeeper map in the EU, and the compliance workstreams that typically follow designation for core platform services. This is a practical reference, not legal advice. Whether and how obligations apply depends on designation decisions, service definitions, and the Commission's interpretation and implementing acts. [Get help assessing DMA exposure](/contact.md) ## What you can decide faster - **Service type**: Core platform service mapping and boundaries. - **Designation context**: Understand how gatekeeper designation works at a high level. - **Workstreams**: Prioritize interoperability, choice screens, and data controls. By Sorena AI | Updated Mar 2026 | No signup required ### Quick scan *DMA* - **Gatekeeper context**: Understand the current 7 gatekeepers and 23 designated CPS. - **Obligations**: Map the key do and do not requirements. - **Evidence**: Plan documentation and monitoring for changes. Use the decision flow to align product, legal, and policy owners on a focused compliance approach for the current gatekeeper landscape and for near-threshold CPS. | Value | Metric | | --- | --- | | 2022 | Regulation | | EU | Market | | CPS | Scope | | Enforcement | Focus | **Key highlights:** Core platform services (CPS) | Gatekeeper designation | Interoperability | Choice screens | Data portability ## Topic Guides - [DMA Applicability Test (Gatekeeper Scoping) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/applicability-test.md): A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds. - [DMA Compliance Checklist (Execution-Ready) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/checklist.md): An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls. - [DMA Compliance Program & Monitoring (Compliance Function + Evidence)](/artifacts/eu/digital-markets-act/compliance-program-and-monitoring.md): How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness. - [DMA Deadlines & Compliance Calendar (Key Dates) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar.md): A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline. - [DMA Do's and Don'ts for Product Teams | EU Digital Markets Act](/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams.md): Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes. - [DMA Enforcement: Penalties, Remedies, and Process | EU Digital Markets Act](/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies.md): How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies. - [DMA Fines & Penalties (10% / 20% / 1% + 5% per day) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/penalties-and-fines.md): A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%. - [DMA Obligations List (Articles 5, 6, 7) - By Obligation | EU Digital Markets Act](/artifacts/eu/digital-markets-act/core-obligations-by-obligation.md): A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores. - [DMA Self-Preferencing Compliance Examples (Article 6(5)) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples.md): Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what "transparent, fair. - [DMA vs DSA: What's the Difference? (EU Platform Laws)](/artifacts/eu/digital-markets-act/dma-vs-dsa.md): A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations. - [EU Digital Markets Act (DMA) Requirements (Articles 5-7)](/artifacts/eu/digital-markets-act/requirements.md): A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution. - [EU DMA Compliance Guide (How to Comply) | Digital Markets Act (DMA)](/artifacts/eu/digital-markets-act/compliance.md): A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations. - [EU DMA FAQ (Gatekeepers, Obligations, Deadlines) | Digital Markets Act](/artifacts/eu/digital-markets-act/faq.md): EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7). - [EU DMA Timeline & Key Milestones | Digital Markets Act (2022/1925)](/artifacts/eu/digital-markets-act/timeline-and-key-milestones.md): A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones. - [Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11)](/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist.md): A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report. - [Gatekeeper Designation Guide (DMA Article 3) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/gatekeeper-designation-guide.md): A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B). ## Key dates for platform governance *DMA Timeline* Track DMA milestones that affect designation timing, compliance planning, and enforcement readiness across core platform services. ## How does the DMA impact your services *DMA Decision Flow* Use the decision flow to map core platform service scope, gatekeeper designation triggers, and common compliance workstreams, then plan internal owners and evidence. *Next step* ## Turn EU Digital Markets Act Timeline and Decision Flow into an operational assessment workflow EU Digital Markets Act Timeline and Decision Flow should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into Research Copilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU Digital Markets Act Timeline and Decision Flow and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for EU Digital Markets Act Timeline and Decision Flow. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs from the same artifact. - **Download decision flow**: Share scope logic internally. - **Download timeline**: Coordinate milestones across teams. - [Talk through EU Digital Markets Act Timeline and Decision Flow](/contact.md): Review your current process, evidence model, and next steps for EU Digital Markets Act Timeline and Decision Flow. ## Decision Steps ### STEP 1: Do you provide any core platform service as defined in DMA Article 2(2)? *Reference: Art. 2(2)* - Core platform services include: online intermediation services, online search engines, online social networking services, video-sharing platforms, number-independent interpersonal communications services, operating systems, web browsers, virtual assistants, cloud computing services, and online advertising services. - If yes: continue to assess gatekeeper designation criteria. - If no: DMA does not apply to you. - **NO** Not a Gatekeeper - **YES** Do you meet ALL quantitative thresholds in Article 3(2)? ### STEP 2: Do you meet ALL quantitative thresholds in Article 3(2)? *Reference: Art. 3(2)* - Threshold 1 (significant impact): EUR 7.5 billion annual EU turnover in each of last 3 years, OR EUR 75 billion market cap/fair market value in last year, AND provides service in at least 3 Member States. - Threshold 2 (important gateway): At least 45 million monthly active end users in EU AND at least 10,000 yearly active business users in EU in last year. - Threshold 3 (entrenched position): Thresholds in 2 above were met in each of the last 3 financial years. - If all thresholds met: you are presumed to be a gatekeeper and must notify the Commission within 2 months (Art. 3(3)). - **YES** Can you rebut the gatekeeper presumption? - **NO** Does your service meet the qualitative criteria even without meeting all thresholds? ### STEP 3: Can you rebut the gatekeeper presumption? *Reference: Art. 3(5)* - Even if you meet all thresholds, you may present sufficiently substantiated arguments that your service does not satisfy the requirements in Art. 3(1) due to exceptional circumstances. - Commission will assess whether arguments manifestly call into question the presumptions. - If Commission rejects arguments or finds them insufficiently substantiated, it will designate you as gatekeeper. - If no rebuttal or rebuttal rejected: proceed to gatekeeper designation. - **NO** Designated as Gatekeeper - **YES** Not a Gatekeeper ### ALTERNATIVE: Does your service meet the qualitative criteria even without meeting all thresholds? *Reference: Art. 3(1) & 3(8)* - Commission may designate you as gatekeeper even if you don't meet quantitative thresholds if you satisfy all three qualitative requirements: - (a) Significant impact on internal market. - (b) Core platform service is important gateway for business users to reach end users. - (c) Entrenched and durable position (or foreseeably will enjoy such position). - Commission conducts market investigation considering: size/operations, number of users, network effects, data advantages, scale/scope effects, lock-in, vertical integration, structural characteristics. - **YES** Designated as Gatekeeper - **NO** Not a Gatekeeper ## Reference Information ### Core Platform Services (Overview) - Online intermediation services: platforms connecting business users and end users (e.g., marketplaces, app stores). - Online search engines: services for searching websites, content, and information. - Online social networking services: platforms enabling users to connect, communicate, share content across devices. - Video-sharing platform services: platforms for sharing and viewing video content. - Number-independent interpersonal communications services: messaging and calling not tied to phone numbers. - Operating systems: system software controlling hardware/software functions. - Web browsers: software for accessing web content. - Virtual assistants: software processing voice/text demands to access services or control devices. - Cloud computing services: on-demand computing resources over the internet. - Online advertising services: advertising networks, exchanges, and intermediation services provided by core platform service providers. ### Notification Obligation - If you meet all quantitative thresholds in Art. 3(2), notify the Commission within 2 months (Art. 3(3)). - Provide relevant information for each core platform service meeting the thresholds. - Commission will designate you as gatekeeper within 45 working days after receiving complete information (Art. 3(4)). - You may submit sufficiently substantiated arguments to rebut the presumption (Art. 3(5)). - Failure to notify does not prevent Commission designation based on available information. ### Article 5 Obligations (Core Prohibitions) - No combining/cross-using personal data without consent (Art. 5(2)): Cannot process personal data from third-party services for advertising, combine data across services, or cross-use data without specific GDPR consent. - No price parity (Art. 5(3)): Cannot prevent business users from offering different prices/conditions on other channels. - Allow business user communications (Art. 5(4)): Business users can communicate offers to end users and conclude contracts outside your platform. - Allow access to purchased content (Art. 5(5)): End users can access content/subscriptions acquired elsewhere via business user apps. - No retaliation for complaints (Art. 5(6)): Cannot prevent business users/end users from raising non-compliance issues with authorities. - No mandatory use of gatekeeper services (Art. 5(7)): Cannot require use of gatekeeper's identification, browser engine, payment services, or in-app payment systems. - No tying of core platform services (Art. 5(8)): Cannot require subscription to other core platform services as condition for access. - Advertising transparency for advertisers (Art. 5(9)): Provide daily, free information on prices, fees, remuneration, and metrics. - Advertising transparency for publishers (Art. 5(10)): Provide daily, free information on remuneration, fees, advertiser prices, and metrics. ### Article 6 Obligations (Can Be Further Specified) - No use of business user data in competition (Art. 6(2)): Cannot use non-public data from business users to compete with them. - Allow app uninstallation (Art. 6(3)): Enable easy uninstallation of apps and changing of default settings; prompt choice of default search engine/browser/assistant. - Allow third-party app stores (Art. 6(4)): Enable installation and use of third-party apps/app stores on your OS, with security safeguards. - No self-preferencing in ranking (Art. 6(5)): Apply fair, non-discriminatory ranking to own vs. third-party services. - Allow switching (Art. 6(6)): Don't restrict ability to switch between apps/services or subscribe to different services. - Interoperability (Art. 6(7)): Provide free, effective interoperability with same hardware/software features available to your own services. - Performance measurement tools (Art. 6(8)): Provide advertisers/publishers free access to performance tools and verification data. - Data portability for end users (Art. 6(9)): Provide free, effective, continuous, real-time data portability. - Data access for business users (Art. 6(10)): Provide free, continuous, real-time access to aggregated/non-aggregated data (including personal data with consent). - Search data access (Art. 6(11)): Provide third-party search engines with access to ranking, query, click, view data on FRAND terms. - FRAND access conditions (Art. 6(12)): Publish fair, reasonable, non-discriminatory general access conditions for app stores, search engines, social networks. - Proportionate termination (Art. 6(13)): Ensure termination conditions are not disproportionate and can be exercised without undue difficulty. ### Article 7 Messaging Interoperability - Applies to: Number-independent interpersonal communications services (e.g., WhatsApp, Messenger). - Make basic functionalities interoperable with other providers, free of charge, upon request (Art. 7(1)). - Timeline for interoperability (Art. 7(2)): (a) Following listing in the designation decision: end-to-end text messaging and sharing of images, voice messages, videos, and other attached files between two users. (b) Within 2 years from designation: group messaging and file sharing. (c) Within 4 years from designation: voice and video calls (individual and group). - Preserve security level including end-to-end encryption (Art. 7(3)). - Publish reference offer with technical details and security specifications (Art. 7(4)). - Respond to interoperability requests within 3 months (Art. 7(5)). - Commission may extend time limits if necessary for security/effective interoperability (Art. 7(6)). - End users free to decide whether to use interoperable features (Art. 7(7)). - Collect/exchange only personal data strictly necessary; comply with GDPR/ePrivacy (Art. 7(8)). - May take proportionate measures to ensure third parties don't endanger integrity/security/privacy (Art. 7(9)). ### Compliance Function Requirement - Establish independent compliance function with one or more compliance officers (Art. 28(1)). - Ensure compliance function has sufficient authority, resources, and access to management body (Art. 28(2)). - Head of compliance function must be independent senior manager with distinct responsibility (Art. 28(3)). - Compliance officers responsible for: organizing/coordinating compliance activities, advising management, identifying/assessing compliance risks, monitoring DMA compliance (Art. 28(5)). - Communicate name and contact details of head of compliance function to Commission (Art. 28(6)). - Management body must define governance arrangements, oversee implementation, approve compliance strategies at least annually (Art. 28(7)-(9)). ### Reporting and Audit Obligations - Compliance report (Art. 11): Within 6 months of designation, provide detailed report describing compliance measures. Publish non-confidential summary. Update at least annually. - Consumer profiling audit (Art. 15): Within 6 months, submit independently audited description of consumer profiling techniques across core platform services. Make public overview available. Update at least annually. - Concentration notification (Art. 14): Inform Commission of intended concentrations involving core platform services or digital services/data collection, regardless of merger control thresholds. Notify prior to implementation. Provide turnover, user numbers, transaction value. - Commission monitors implementation and compliance (Art. 26). May appoint independent experts, auditors, or national authority officials. ### Anti-Circumvention and Enforcement - No segmentation to avoid thresholds (Art. 13(1)): Cannot split services to circumvent quantitative thresholds. - Full and effective compliance required (Art. 13(3)): Must ensure obligations are fully complied with. - No undermining behaviors (Art. 13(4)): Cannot engage in contractual, commercial, technical, or behavioral techniques/interface design that undermine compliance. - No degradation (Art. 13(6)): Cannot degrade conditions/quality for users exercising their rights, make exercise unduly difficult, or subvert user autonomy via interface design (dark patterns). - Consent facilitation (Art. 13(5)): Enable business users to obtain required consent; don't make obtaining consent more burdensome than for own services. - Commission may specify compliance measures if circumvention detected (Art. 13(7)). ### Suspension and Exemption Mechanisms - Suspension for economic viability (Art. 9): Commission may exceptionally suspend specific obligation if compliance would endanger economic viability in EU due to exceptional circumstances beyond control. Limited to extent and duration necessary. Reviewed annually. - Exemption for public interest (Art. 10): Commission may exempt from specific obligation on grounds of public health or public security. Reviewed annually or when grounds no longer exist. - Provisional suspension in urgent cases (Art. 9(3), 10(4)): Commission may provisionally suspend application pending final decision. - Both suspension and exemption decisions adopted as implementing acts with reasoned statement. ### Penalties and Fines - Non-compliance fines (Art. 30(1)): Up to 10% of total worldwide turnover for failing to comply with Arts. 5, 6, 7 obligations, specified measures, or commitments. - Repeat infringement fines (Art. 30(2)): Up to 20% of total worldwide turnover for repeat infringement of same obligation. - Procedural fines (Art. 30(3)): Up to 1% of total worldwide turnover for: supplying incorrect/incomplete/misleading information, failing to provide information, failing to rectify information, breaking seals, refusing inspections. - Periodic penalty payments (Art. 31(1)): Up to 5% of average daily worldwide turnover per day to compel compliance with decisions, information requests, inspections. Maximum 6 months. - Commission considers gravity, duration, recurrence, and (for procedural fines) delay caused (Art. 30(4)). - 5-year limitation period for imposing penalties (Art. 32). ### Market Investigations and Remedies - Designation investigation (Art. 17): Commission may investigate whether undertaking should be designated as gatekeeper. Concluded within 12 months (5 months if rebutting presumption). - Systematic non-compliance investigation (Art. 18): If at least 3 non-compliance decisions within 8 years, Commission may investigate and impose behavioral or structural remedies. May include temporary prohibition on concentrations. Concluded within 12 months (extendable by 6 months). - New services/practices investigation (Art. 19): Commission may investigate whether new services should be added to core platform services list or new practices should be addressed. Report within 18 months. May lead to legislative proposal or delegated acts. - Interim measures (Art. 24): In urgent cases with risk of serious irreparable damage, Commission may order interim measures based on prima facie finding of infringement. - Commitments (Art. 25): During systematic non-compliance proceedings, gatekeeper may offer commitments that Commission can make binding. ### Commission Investigative Powers - Information requests (Art. 21): Commission may request information by simple request or decision. Can request access to data, algorithms, and testing information. - Interviews (Art. 22): Commission may interview persons who consent. Can record interviews. National authorities may assist. - Inspections (Art. 23): Commission may conduct on-site inspections. Powers include: entering premises, examining records, taking copies, accessing IT systems/algorithms/data, sealing premises/records, requiring explanations. National authorities assist. Court authorization may be required under national rules. - Third-party information (Art. 27): Business users, competitors, end users can inform national authorities or Commission about gatekeeper practices. No obligation for authorities to follow up. - Right to be heard (Art. 34): Gatekeepers have right to be heard on preliminary findings and proposed measures before decisions adopted. At least 14 days to submit observations. ### Current Designated Gatekeepers (as of 2026) - Alphabet: Google Play, Google Maps, Google Shopping, Google Search, YouTube, Android, Chrome, Alphabet advertising. - Amazon: Marketplace, Amazon Advertising. - Apple: App Store, iOS, Safari, iPadOS. - Booking: Booking.com online intermediation service. - ByteDance: TikTok. - Meta: Facebook, Instagram, WhatsApp, Messenger, Meta Ads (Facebook Marketplace undesignated April 2025). - Microsoft: Windows PC OS, LinkedIn, Microsoft Ads. - Total: 23 core platform services currently designated (as of February 2026). - Commission publishes and updates list on ongoing basis (Art. 4(3)). ### Updating DMA Obligations - Commission empowered to adopt delegated acts to keep Arts. 5-7 obligations up to date (Art. 12). - Based on market investigation identifying need to address practices limiting contestability or fairness. - Scope limited to: extending obligations to other services/users/data types, specifying how obligations performed, adding conditions, applying obligations to relationships between services. - Commission may update list of basic functionalities for messaging interoperability (Art. 12(3)). - Practice limits contestability/is unfair if: creates/strengthens barriers to entry, prevents access to key input, or creates imbalance where gatekeeper obtains disproportionate advantage (Art. 12(5)). - Commission evaluates the DMA by May 2026 and every 3 years thereafter (Art. 53). ## Possible Outcomes ### [RESULT] Designated as Gatekeeper Obligations apply within 6 months - Commission lists relevant core platform services in designation decision (Art. 3(9)). - You must comply with obligations in Articles 5, 6, and 7 within 6 months after a core platform service has been listed in the designation decision (Art. 3(10)). - Submit compliance report within 6 months (Art. 11). - Establish independent compliance function (Art. 28). - Submit audit of consumer profiling techniques within 6 months (Art. 15). - Inform Commission of any intended concentrations (Art. 14). - Commission reviews gatekeeper status at least every 3 years (Art. 4). ### [RESULT] Not a Gatekeeper DMA obligations do not apply - You are not designated as a gatekeeper under the DMA. - However, Commission may reconsider if circumstances change (Art. 4). - Commission examines whether new undertakings satisfy gatekeeper requirements at least annually (Art. 4(2)). - Even if not a gatekeeper, general competition law (Articles 101-102 TFEU) and sector-specific regulations may apply. ## DMA Timeline | Date | Event | Reference | | --- | --- | --- | | 2022-09-14 | DMA adopted by Parliament and Council | Reg. (EU) 2022/1925 | | 2022-10-12 | DMA published in Official Journal | OJ L 265 | | 2022-11-01 | Entry into force (20 days after publication); Arts. 3(6)-(7) and 40, 46-50 apply | Art. 54 | | 2023-05-02 | DMA applies (main provisions) | Art. 54 | | 2023-06-25 | Arts. 42-43 apply (whistleblower protection) | Art. 54 | | 2023-04-17 | Procedural implementing regulation published (Commission Implementing Regulation (EU) 2023/814) | Reg. (EU) 2023/814 | | 2023-09-06 | First gatekeeper designations: Alphabet, Amazon, Apple, ByteDance, Meta, Microsoft | Commission decision | | 2024-04-29 | Apple iPadOS designated as gatekeeper | Commission decision | | 2025-01-10 | DMA corrigendum published in the Official Journal | Corrigendum | | 2025-04-23 | Meta undesignated for Facebook Marketplace | Commission decision | | 2026-05-03 | First DMA evaluation report due (every 3 years thereafter) | Art. 53 | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2022-09-14 | Digital Markets Act adopted (Regulation (EU) 2022/1925) | Legislation | | | 2022-10-12 | DMA published in the Official Journal (OJ L 265) | Legislation | | | 2022-11-01 | Selected DMA provisions start applying (and delegation period begins) | Compliance & Implementation | | | 2023-04-14 | Procedural implementing regulation adopted (Commission Implementing Regulation (EU) 2023/814) | Legislation | | | 2023-04-17 | Procedural implementing regulation published (OJ L 102/6) | Legislation | | | 2023-05-02 | DMA starts applying | Compliance & Implementation | | | 2023-06-25 | Articles 42 and 43 start applying | Compliance & Implementation | | | 2023-09-06 | Commission designates first gatekeepers under the DMA | Gatekeeper Designations | | | 2023-11-11 | EU SEND replaces eTrustEx for DG Competition document exchange | Compliance & Implementation | | | 2024-04-29 | Apple designated as gatekeeper for iPadOS | Gatekeeper Designations | | | 2024-06-25 | Call for tenders published (DMA interoperability tools study) | Guidance & Consultations | | | 2024-07-01 | Commission sends preliminary findings to Meta over pay-or-consent model | Enforcement Actions | | | 2024-09-19 | Commission opens specification proceedings on iOS interoperability | Enforcement Actions | | | 2024-12-18 | Public consultation launched (Apple iOS interoperability) | Guidance & Consultations | | | 2025-01-10 | Corrigendum to the DMA published in the Official Journal | Legislation | | | 2025-03-19 | Commission provides guidance under the DMA for Apple’s platforms | Guidance & Consultations | | | 2025-04-23 | Meta undesignated for Facebook Marketplace | Gatekeeper Designations | | | 2025-05-20 | Apple process measures deadline (DMA.100204) | Compliance & Implementation | | | 2025-07-21 | Apple dispute resolution mechanisms deadline (DMA.100204) | Compliance & Implementation | | | 2025-12-31 | Apple interoperability measures due by end of 2025 (selected items) | Compliance & Implementation | | | 2026-05-03 | First Commission evaluation report due | Compliance & Implementation | | | 2026-06-01 | Apple iOS notifications measures deadline (DMA.100203) | Compliance & Implementation | | **Event details:** - **2022-09-14 - Digital Markets Act adopted (Regulation (EU) 2022/1925)**: Regulation (EU) 2022/1925 date: 14 September 2022. - **2022-10-12 - DMA published in the Official Journal (OJ L 265)**: Authentic text publication reference: OJ L 265, 12.10.2022, p. 1. - **2022-11-01 - Selected DMA provisions start applying (and delegation period begins)**: Regulation timeline: Article 3(6) and (7) and Articles 40, 46-50 apply from 1 November 2022; delegated act powers are conferred from 1 November 2022 for five years. - **2023-04-14 - Procedural implementing regulation adopted (Commission Implementing Regulation (EU) 2023/814)**: The Commission adopts Implementing Regulation (EU) 2023/814 laying down detailed arrangements for the conduct of certain proceedings under the DMA. - **2023-04-17 - Procedural implementing regulation published (OJ L 102/6)**: Commission Implementing Regulation (EU) 2023/814 is published in the Official Journal of the European Union (L 102/6). - **2023-05-02 - DMA starts applying**: Regulation timeline: it shall apply from 2 May 2023. - **2023-06-25 - Articles 42 and 43 start applying**: Regulation timeline: Article 42 and Article 43 apply from 25 June 2023. - **2023-09-06 - Commission designates first gatekeepers under the DMA**: Gatekeepers page timeline: on 6 September 2023 the Commission designated Alphabet, Amazon, Apple, ByteDance, Meta, and Microsoft as gatekeepers. - **2023-11-11 - EU SEND replaces eTrustEx for DG Competition document exchange**: EU SEND replaces eTrustEx as of 11 November 2023 for secure document exchange with DG Competition (DMA-related submissions and communications). - **2024-04-29 - Apple designated as gatekeeper for iPadOS**: Gatekeepers page timeline: on 29 April 2024, the Commission designated Apple with respect to iPadOS as a gatekeeper under the DMA. - **2024-06-25 - Call for tenders published (DMA interoperability tools study)**: The Commission publishes a call for tenders for a study of interoperability tools for the digital single market under the DMA. - **2024-07-01 - Commission sends preliminary findings to Meta over pay-or-consent model**: DMA website timeline: 1 July 2024 publication date for the preliminary findings related to Meta’s pay-or-consent model under the DMA. - **2024-09-19 - Commission opens specification proceedings on iOS interoperability**: Interoperability Q&A timeline: on 19 September 2024 the Commission opened two specification proceedings (DMA.100203 and DMA.100204) related to iOS interoperability and Apple’s request-handling process. - **2024-12-18 - Public consultation launched (Apple iOS interoperability)**: A public consultation is launched on 18 December 2024 related to DMA guidance and interoperability topics for Apple’s platforms. - **2025-01-10 - Corrigendum to the DMA published in the Official Journal**: Consolidated-text timeline notes a corrigendum: OJ L 90024, 10 January 2025. - **2025-03-19 - Commission provides guidance under the DMA for Apple’s platforms**: DMA website timeline: guidance article dated 19 March 2025 (also references a public consultation launched on 18 December 2024). - **2025-04-23 - Meta undesignated for Facebook Marketplace**: Gatekeepers page timeline: on 23 April 2025, Meta was undesignated for its online intermediation service Facebook Marketplace. - **2025-05-20 - Apple process measures deadline (DMA.100204)**: Interoperability Q&A timeline: for the process specification decision (DMA.100204), measures (except dispute resolution) are due within two months after the decision, i.e., by 20 May 2025. - **2025-07-21 - Apple dispute resolution mechanisms deadline (DMA.100204)**: Interoperability Q&A timeline: for the process specification decision (DMA.100204), dispute resolution mechanisms are due within four months after the decision, i.e., by 21 July 2025. - **2025-12-31 - Apple interoperability measures due by end of 2025 (selected items)**: Interoperability Q&A timeline: selected measures are due by the end of 2025, including an iOS notifications beta version (with stated exceptions) and certain background execution and Wi-Fi connection measures. - **2026-05-03 - First Commission evaluation report due**: DMA Regulation timeline: by 3 May 2026, and subsequently every three years, the Commission shall evaluate the Regulation and report to the European Parliament and the Council. - **2026-06-01 - Apple iOS notifications measures deadline (DMA.100203)**: Interoperability Q&A timeline: for iOS notifications measures (DMA.100203), all measures are due by 1 June 2026. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-markets-act --- --- title: "EU DORA Compliance Hub" canonical_url: "https://www.sorena.io/artifacts/eu-dora" source_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act" author: "Sorena AI" description: "A practical EU DORA compliance hub for Regulation (EU) 2022/2554: confirm scope and proportionality, then implement ICT risk management controls." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU DORA compliance" - "DORA compliance" - "Digital Operational Resilience Act" - "Regulation (EU) 2022/2554" - "DORA checklist" - "DORA requirements" - "ICT risk management DORA" - "major ICT incident reporting DORA" - "DORA incident reporting templates" - "TLPT DORA" - "threat-led penetration testing DORA" - "ICT third-party risk DORA" - "DORA contract clauses" - "DORA register of information" - "critical ICT third-party provider DORA" - "DORA" - "Operational resilience" - "Financial sector" - "Compliance" - "ICT risk" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DORA Compliance Hub A practical EU DORA compliance hub for Regulation (EU) 2022/2554: confirm scope and proportionality, then implement ICT risk management controls. ![EU DORA artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-dora-timeline-small.jpg?v=cheatsheets%2Fprod) *DORA* *Compliance Hub* ## EU Digital Operational Resilience Act Decision Flow + Timeline Use the decision flow to confirm DORA scope and proportionality, then turn requirements into an execution plan: ICT risk management controls, major incident reporting, resilience testing and TLPT, and third-party risk contracts plus register of information. This is a practical implementation hub, not legal advice. Your obligations depend on entity type, national supervision, how critical or important functions and ICT dependencies are assessed under DORA, and whether current RTS and ITS for reporting, register templates, TLPT identification, and subcontracting already apply. [Start with the DORA checklist](/artifacts/eu/dora/checklist.md) ## What you can decide faster - **Scope**: Check Article 2 coverage and exclusions. - **Track**: Choose the right path: financial entity, ICT provider, or CTPP. - **Workstreams**: Plan ICT risk, incident reporting, testing, and third party controls. By Sorena AI | Updated Mar 2026 | No signup required ### Quick scan *DORA* - **Applicability**: Confirm your scope and exclusions. - **Obligations**: Translate requirements into controls. - **Evidence**: Plan owners, artifacts, reporting templates, and review cadence. Use the decision flow for scope and track decisions, then use topic guides to ship controls and evidence. | Value | Metric | | --- | --- | | 2022 | Regulation | | EU | Market | | ICT | Focus | | Resilience | Outcome | **Key highlights:** Incident reporting | Register of information | TLPT readiness ## Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/digital-operational-resilience-act/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/digital-operational-resilience-act/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/digital-operational-resilience-act/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/digital-operational-resilience-act/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/digital-operational-resilience-act/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/digital-operational-resilience-act/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/digital-operational-resilience-act/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/digital-operational-resilience-act/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/digital-operational-resilience-act/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/digital-operational-resilience-act/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/digital-operational-resilience-act/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/digital-operational-resilience-act/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/digital-operational-resilience-act/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/digital-operational-resilience-act/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/digital-operational-resilience-act/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/digital-operational-resilience-act/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. ## Key dates for operational resilience planning *DORA Timeline* Track DORA milestones that affect application timing, Level 2 deliverables, and operational implementation across risk, security, testing and vendor management. ## How does DORA apply to your entity *DORA Decision Flow* Use the decision flow to map scope, proportionality and simplified frameworks, incident reporting expectations, testing/TLPT approach, and ICT third-party risk controls. *Next step* ## Turn EU Digital Operational Resilience Act Decision Flow + Timeline into an operational assessment workflow EU Digital Operational Resilience Act Decision Flow + Timeline should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU Digital Operational Resilience Act Decision Flow + Timeline and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for EU Digital Operational Resilience Act Decision Flow + Timeline. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share scope and track logic internally. - **Download timeline**: Coordinate milestones across teams. - [Talk through EU Digital Operational Resilience Act Decision Flow + Timeline](/contact.md): Review your current process, evidence model, and next steps for EU Digital Operational Resilience Act Decision Flow + Timeline. ## Decision Steps ### STEP 1: Are you one of the entity types listed in DORA Article 2(1)? *Reference: Art. 2(1)* - This is the core personal scope test for DORA. - If yes: check exclusions (Art. 2(3)) and any optional Member State exclusion (Art. 2(4)). - **NO** Out of Scope - **YES** Does an Article 2(3) exclusion apply to you? ### STEP 2: Does an Article 2(3) exclusion apply to you? *Reference: Art. 2(3)* - If yes, DORA does not apply to you. - If no, continue to check the Member State optional exclusion (Art. 2(4)) and whether you are a financial entity or an ICT third-party service provider. - **YES** Out of Scope - **NO** Has your Member State excluded your entity type under Article 2(4)? ### STEP 3: Has your Member State excluded your entity type under Article 2(4)? *Reference: Art. 2(4)* - Member States may exclude certain CRD-exempt entities located in their territory (Art. 2(4)). - If unsure: verify with your national competent authority (and any published Member State notification under Art. 2(4)). - If you are not an entity referred to in CRD Art. 2(5)(4)-(23), answer 'No' and continue. - **YES** Out of Scope (Member State Exclusion) - **NO** Which DORA track applies? ### STEP 4: Which DORA track applies? - Financial entity track (Art. 2(1)(a)-(t); defined in Art. 2(2)). - ICT third-party service provider track (Art. 2(1)(u)). - If you are both (e.g., a regulated financial entity that also provides ICT services), follow the financial entity track first and also review the ICT provider track. - -> Are you a 'financial entity' as defined in DORA? ### STEP 5: Are you a 'financial entity' as defined in DORA? *Reference: Art. 2(1)(a)-(t) & Art. 2(2)* - If yes: follow the financial entity compliance track (Chapters II-V). - If no: you may still be in scope as an ICT third-party service provider (Art. 2(1)(u)). - **YES** Financial entity is within DORA scope - **NO** Are you an ICT third-party service provider under Art. 2(1)(u)? ### ICT TRACK: Are you an ICT third-party service provider under Art. 2(1)(u)? *Reference: Art. 2(1)(u) & Art. 3(19)-(21)* - 'ICT third-party service provider' = an undertaking providing ICT services (Art. 3(19)). - 'ICT services' = digital and data services provided through ICT systems on an ongoing basis (includes hardware as a service / support via updates; excludes traditional analogue telephone services) (Art. 3(21)). - DORA also defines an 'ICT intra-group service provider' as an undertaking in a financial group providing predominantly ICT services within the group (Art. 3(20)). - **YES** Have you been designated as a critical ICT third-party service provider (CTPP)? - **NO** Out of Scope ### IN SCOPE: Financial entity is within DORA scope *Reference: Art. 2(1)-(2)* - Implement ICT risk management (Chapter II), incident management and reporting (Chapter III), resilience testing (Chapter IV), and ICT third-party risk management (Chapter V). - Apply proportionality across Chapters II-V as required by Art. 4. - -> Do you qualify for the simplified ICT risk management framework? ### STEP 6: Do you qualify for the simplified ICT risk management framework? *Reference: Art. 16(1)* - If yes: Articles 5 to 15 do not apply, but you must meet the Art. 16 minimum requirements. - Art. 16(1) covers (among others): small and non-interconnected investment firms; payment institutions exempted under PSD2; electronic money institutions exempted under EMD2; small IORPs; and certain CRD-exempt institutions depending on whether the Member State used Art. 2(4). - **YES** DORA Applies (Simplified ICT Risk Framework) - **NO** Are you a microenterprise (as defined in DORA)? ### STEP 7: Are you a microenterprise (as defined in DORA)? *Reference: Art. 3(60)* - Microenterprise = financial entity (excluding trading venues, CCPs, TRs, and CSDs) with fewer than 10 persons and <= EUR 2M annual turnover and/or balance sheet total. - Microenterprises are in scope, but several requirements apply only to financial entities other than microenterprises (e.g., crisis management function; some audit/testing formalities; TLPT). - **YES** DORA Applies (Microenterprise) - **NO** Are you required to perform threat-led penetration testing (TLPT)? ### STEP 8: Are you required to perform threat-led penetration testing (TLPT)? *Reference: Art. 26(1) & 26(8)* - TLPT applies to certain non-microenterprise financial entities that are not covered by Art. 16(1) and are identified by the competent authority. - The criteria used for identifying financial entities required to perform TLPT are further specified by TLPT RTS adopted as delegated acts (e.g., Delegated Reg. (EU) 2025/1190). - If yes: plan for TLPT at least every 3 years and align scope to critical or important functions (and live production systems). - **YES** DORA Applies (Full Framework + TLPT) - **NO** DORA Applies (Full ICT Risk Framework) ### ICT TRACK: Have you been designated as a critical ICT third-party service provider (CTPP)? *Reference: Art. 31* - Designation is under Art. 31 and criteria are further specified by delegated acts (e.g., Delegated Reg. (EU) 2024/1502). - CTPP designation does not apply to certain categories (Art. 31(8)), including: financial entities providing ICT services to other financial entities; ICT third-party service providers subject to oversight frameworks supporting tasks referred to in TFEU Art. 127(2); ICT intra-group service providers; and ICT providers serving only one Member State to financial entities only active in that Member State. - The ESAs establish, publish and update yearly the Union list of critical ICT third-party service providers (Art. 31(9)). - If yes: DORA oversight framework applies; oversight fees may apply (Chapter V, Section II; Delegated Reg. (EU) 2024/1505). - If no/unsure: DORA still affects you through contractual requirements imposed on financial entities (Art. 30) and you may be included in customers' TLPT scope (Arts. 26-27). - **YES** CTPP Oversight Applies - **NO** Not Designated as CTPP ## Reference Information ### Entities In Scope (Overview) - Financial entities (Art. 2(1)(a)-(t)) include: banks, investment firms, (e-)money/payment institutions and AISPs, insurers and intermediaries, fund managers/UCITS managers, market infrastructures (CCPs/CSDs/trading venues/TRs), data reporting service providers, CRAs, critical benchmark administrators, crowdfunding providers, securitisation repositories, crypto-asset service providers and issuers of asset-referenced tokens. - ICT third-party service providers are also in scope as a category (Art. 2(1)(u)). - 'Financial entities' is a defined umbrella term for Art. 2(1)(a)-(t) only (Art. 2(2)). ### Key Exclusions - Art. 2(3) exclusions include (among others): certain AIFMs under AIFMD Art. 3(2); small insurers under Solvency II Art. 4; IORPs with pension schemes totalling <= 15 members; persons exempt under MiFID II Arts. 2 and 3; insurance/reinsurance/ancillary intermediaries that are microenterprises or SMEs; post office giro institutions (CRD Art. 2(5)(3)). - Art. 2(4) optional exclusion: Member States may exclude certain entities listed in CRD Art. 2(5)(4)-(23) located in their territory (and must inform the Commission). ### Proportionality Principle - Implement Chapter II (ICT risk management) in accordance with proportionality (Art. 4(1)). - Apply proportionality to Chapters III-V, Section I (incident reporting, testing, third-party risk) as specifically provided (Art. 4(2)). - Competent authorities consider proportionality when reviewing framework reports (Art. 4(3)). ### Penalties & Publication - Member States must lay down rules establishing administrative penalties and remedial measures for breaches; competent authorities must have supervisory, investigatory and sanctioning powers (Art. 50). - Member States notify the laws, regulations and administrative provisions implementing the administrative penalties chapter (including any relevant criminal law provisions) to the Commission and the ESAs by 17 January 2025, and notify amendments without undue delay (Art. 53). - Competent authorities publish final administrative penalty decisions on their official websites, including breach details and responsible persons, subject to proportionality and other safeguards (Art. 54). - Publication may be deferred, anonymised, or withheld in specific cases (Art. 54(3)). ### Governance & Management Body - Have an internal governance and control framework for effective and prudent ICT risk management (Art. 5(1)). - Management body defines, approves, oversees, and is responsible for ICT risk framework implementation (Art. 5(2)). - Management body responsibilities include: risk ownership; data availability/authenticity/integrity/confidentiality policies; roles/responsibilities; approving resilience strategy and risk tolerance; approving business continuity and response/recovery; approving ICT audit plans; budgeting for resilience and training; and approving ICT third-party arrangements policy (Art. 5(2)). ### ICT Risk Management (Core Components) - Other than microenterprises: assign ICT risk management and oversight responsibility to a control function with an appropriate level of independence; ensure segregation between ICT risk management, control and internal audit functions (Art. 6(4)). - Document and maintain an ICT risk management framework (Art. 6), including a digital operational resilience strategy (Art. 6(8)). - Maintain updated ICT systems, protocols and tools (Art. 7). - Security, detection, response and recovery controls (Arts. 8-12) including business continuity and response/recovery plans (Art. 11). - Training and awareness programmes as part of staff training (Art. 13(6)). - Communication strategy and client communications when disclosure is required (Art. 14; see also Art. 19(3)). - Regular review and audit expectations for non-microenterprises (Art. 6(5)-(7)). - You may outsource verification of compliance with ICT risk management requirements to intra-group or external undertakings, but remain fully responsible (Art. 6(10)). ### Simplified ICT Risk Management Framework - If Art. 16 applies, Articles 5-15 do not apply (Art. 16(1)). - Minimum framework requirements include: sound documented ICT risk framework; continuous monitoring; resilient and updated ICT systems; prompt identification and handling of anomalies/incidents; identifying key ICT third-party dependencies (Art. 16(1)). - Maintain continuity of critical or important functions via business continuity and response/recovery measures (including back-up and restoration), and test plans and controls regularly; implement operational lessons and training as appropriate (Art. 16(1)). - Document and periodically review the Art. 16 framework; submit a review report to the competent authority upon request (Art. 16(2)). - TLPT does not apply to Art. 16(1) entities (Art. 26(1)). ### Incident Management & Reporting - Establish an ICT incident management process to detect, manage and notify ICT-related incidents; record all ICT incidents and significant cyber threats (Art. 17). - Classify ICT incidents and determine impact using Art. 18 criteria (clients/transactions/reputation; duration; geographic spread; data losses; criticality; economic impact). - Report major ICT-related incidents to the relevant competent authority, using RTS time limits and ITS templates; initial notification + intermediate + final report (Arts. 19-20). - RTS time limits (Delegated Reg. (EU) 2025/301) include: initial notification within 4 hours of classifying as major (and no later than 24 hours from awareness), intermediate report within 72 hours of the initial notification, and final report within 1 month of the (latest) intermediate report; if unable to meet a time limit, inform the competent authority and explain the delay; limited weekend/bank-holiday flexibility may apply (2025/301, Art. 5). - Major incident classification criteria, materiality thresholds, and report details are further specified by RTS (Delegated Reg. (EU) 2024/1772), while standard forms/templates and procedures are set by ITS (Implementing Reg. (EU) 2025/302). - If technical impossibility prevents submission using the template, notify the competent authority via alternative means (Art. 19(1)). - Reporting can be outsourced to a third-party service provider, but the financial entity remains fully responsible (Art. 19(5)). - Voluntary notification of significant cyber threats (Art. 19(2)). - Client notification duties for major incidents impacting clients' financial interests (Art. 19(3)). - Payment-related incidents: Chapter III also applies to operational or security payment-related incidents for credit institutions, payment institutions, AISPs and EMIs (Art. 23). - Member States may additionally require some or all financial entities to also provide the incident reports to CSIRTs under NIS2 (Art. 19(1)). ### Incident Reporting Routing (Who to Notify) - Report major ICT-related incidents to the relevant competent authority (Art. 19(1); see Art. 46). - If supervised by more than one national competent authority, the Member State designates a single relevant competent authority for Art. 19 reporting (Art. 19(1)). - Significant credit institutions report to the relevant national competent authority, which immediately transmits the report to the ECB (Art. 19(1)). - Member States may additionally require that reports are also provided to CSIRTs under NIS2 (Art. 19(1)). ### Supervisory Feedback & Sector Learning - Competent authorities acknowledge receipt of the notifications/reports and may provide timely, relevant and proportionate feedback or high-level guidance (Art. 22(1)). - Competent authorities may make available anonymised information and intelligence on similar threats and discuss remedies to minimise adverse impact across the financial sector (Art. 22(1)). - ESAs report yearly on major incidents on an anonymised and aggregated basis, and may issue warnings and produce high-level statistics (Art. 22(2)). ### Digital Operational Resilience Testing - Financial entities other than microenterprises must establish, maintain and review a comprehensive digital operational resilience testing programme (Art. 24(1)). - Testing methods include vulnerability assessments/scans, penetration testing, end-to-end testing and more (Art. 25(1)). - Microenterprises perform the tests using a risk-based approach and strategic planning (Art. 25(3)). - TLPT applies only to certain non-microenterprise financial entities that are not covered by Art. 16(1) and are identified by competent authorities; at least every 3 years (Art. 26(1) & 26(8)). - Use testers meeting DORA requirements and manage TLPT risks and results, including rules for internal testers (Art. 27). ### ICT Third-Party Risk & Contracts - Manage ICT third-party risk as part of ICT risk (Art. 28(1)) and remain fully responsible for compliance (Art. 28(1)(a)). - Adopt a strategy on ICT third-party risk (financial entities other than microenterprises and those in Art. 16(1); Art. 28(2)). - Maintain a register of information for all ICT contractual arrangements; distinguish those supporting critical or important functions; report at least yearly; and provide the register upon request (Art. 28(3)). - Pre-contract assessments include critical/important function determination, risk assessment (including concentration risk), due diligence, and conflicts of interest (Art. 28(4); see also Art. 29). - Baseline contract elements include: service description, subcontracting permissions/conditions, locations and data processing/storage, data protection safeguards, data access/recovery/return, and service levels (Art. 30(2)). - For ICT services supporting critical or important functions, contracts must also include: business contingency + security requirements, TLPT cooperation, ongoing monitoring and audit/access/inspection rights, and exit strategies with an adequate transition period (Art. 30(3)). - Microenterprise derogation: audit/access/inspection rights can be delegated to an independent third party appointed by the ICT provider, under conditions (Art. 30(3)). - When negotiating contractual arrangements, consider standard contractual clauses developed by public authorities for specific services (Art. 30(4)). - If using a third-country ICT provider designated as critical, financial entities may only use its services if it establishes an EU subsidiary within 12 months of designation (Art. 31(12)). - Practical note: intra-group ICT service provision is not automatically less risky than external provision; reflect group control in the overall risk assessment (Recital 31). ### ICT Provider Readiness (Practical) - Expect customers to require written ICT contracts with clear allocation of rights/obligations and service level agreements (Art. 30(1)-(2)). - Prepare for incident assistance obligations tied to the ICT service provided (Art. 30(2)(f)). - Prepare to cooperate with customers' competent authorities and resolution authorities (Art. 30(2)(g)). - For services supporting critical or important functions, expect audit/access/inspection rights, security and contingency requirements, TLPT cooperation, and exit/transition obligations (Art. 30(3)). - Subcontracting: expect customer assessments and controls; RTS further specify elements to assess when subcontracting ICT services supporting critical/important functions (Art. 30(5)). - Customers may consider using standard contractual clauses developed by public authorities for specific services (Art. 30(4)). ### Register of Information (Operational Focus) - Maintain and update the register of information for ICT contracts at entity and (where relevant) consolidated levels (Art. 28(3)). - Be ready to provide the full register or specified sections to the competent authority upon request (Art. 28(3)). - Inform the competent authority about planned ICT contracts supporting critical/important functions, and when a function becomes critical/important (Art. 28(3)). - Use standard templates established by ITS for the register of information (Implementing Regulation (EU) 2024/2956). ### CTPP Oversight (High-Level) - Critical ICT third-party service providers are designated under DORA (Art. 31) and are overseen by a Lead Overseer (Chapter V, Section II). - Designation criteria are further specified by delegated acts (e.g., Delegated Regulation (EU) 2024/1502); oversight fees are set by delegated acts (e.g., Delegated Regulation (EU) 2024/1505). - Oversight Forum supports the Joint Committee and Lead Overseer on ICT third-party risk (Art. 32). - Lead Overseer is the primary point of contact for oversight matters (Art. 33). - Joint Oversight Network coordinates Lead Overseers (Art. 34). - ESAs issue guidelines on cooperation and information exchange for the oversight framework (Art. 32(7)). - This oversight framework is without prejudice to NIS2 and other Union oversight rules applicable to providers of cloud computing services (Art. 32(8)). ### CTPP Oversight: Follow-Up & Enforcement - Lead Overseer powers include requesting information, conducting investigations/inspections, and issuing recommendations (Art. 35(1)). - CTPPs must respond to recommendations within 60 days (intend to follow, or explain why not); the Lead Overseer may publicly disclose certain non-compliance (Art. 42(1)-(2)). - Periodic penalty payments: after at least 30 days of non-compliance with required measures, the Lead Overseer can impose daily penalty payments (up to 1% average daily worldwide turnover) for up to 6 months; disclosed publicly in principle (Art. 35(6)-(10)). - As a last resort, competent authorities may require financial entities to suspend or terminate the use of a service provided by a CTPP until risks are addressed (Art. 42(6)). - Third-country CTPP: financial entities may only use a third-country ICT provider designated as critical if it has established an EU subsidiary within 12 months of designation (Art. 31(12)). ### Critical or Important Function - A 'critical or important function' is a function whose disruption would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities. - It also includes functions where discontinued, defective or failed performance would materially impair continuing compliance with authorisation conditions or other financial services law obligations (Art. 3(22)). ### Microenterprises (Practical Notes) - Definition: a financial entity (excluding trading venues, CCPs, TRs and CSDs) with <10 persons and <= EUR 2M turnover and/or balance sheet total (Art. 3(60)). - Some requirements apply only to financial entities other than microenterprises (e.g., crisis management function: Art. 11(7); continuous monitoring of technological developments: Art. 13(7)). - Redundant ICT capacities: non-microenterprises must maintain; microenterprises assess the need based on risk profile (Art. 12(4)). - Testing: microenterprises perform Art. 25 tests using a risk-based approach and strategic planning; TLPT does not apply (Art. 25(3); Art. 26(1)). - Contracts: for critical/important functions, microenterprises may agree to delegate audit/access/inspection rights to an independent third party appointed by the ICT provider (Art. 30(3) derogation). ### TLPT (Threat-Led Penetration Testing) - Applies to certain non-microenterprise financial entities not covered by Art. 16(1) that are identified by the competent authority; at least every 3 years (Art. 26(1) & 26(8)). - Scope: cover several or all critical or important functions and be performed on live production systems; include outsourced/contracted ICT services where relevant (Art. 26(2)). - If ICT providers are in scope, the financial entity must ensure their participation and remains fully responsible for compliance (Art. 26(3)). - Pooled testing is possible under written agreement in specific circumstances (Art. 26(4)). - Internal vs external testers: if a financial entity uses internal testers, it must contract external testers every three tests; significant credit institutions may only use external testers (Art. 26(8)). - Provide summary findings and remediation plans to the TLPT authority and obtain an attestation to support mutual recognition; notify the relevant competent authority (Art. 26(6)-(7)). - Member States may designate a single public authority for TLPT matters; otherwise a competent authority may delegate some or all TLPT-related tasks (Art. 26(9)-(10)). - Detailed TLPT RTS are developed with the ECB in accordance with the TIBER-EU framework (Art. 26(11)) and adopted as delegated acts (e.g., Delegated Reg. (EU) 2025/1190). ### Key Level 2 Acts to Implement - Incident classification & reporting: Delegated Reg. (EU) 2024/1772; Delegated Reg. (EU) 2025/301; Implementing Reg. (EU) 2025/302. - ICT risk management: Delegated Reg. (EU) 2024/1774. - ICT third-party contractual arrangements: Delegated Reg. (EU) 2024/1773. - Register of information templates: Implementing Reg. (EU) 2024/2956. - CTPP designation criteria and oversight fees: Delegated Reg. (EU) 2024/1502 and 2024/1505. - Subcontracting assessments: Delegated Reg. (EU) 2025/532. ### Voluntary Information Sharing - Financial entities may exchange cyber threat information and intelligence to enhance resilience, within trusted communities, under arrangements that protect sensitive information and respect confidentiality, GDPR and competition guidance (Art. 45(1)). - Information-sharing arrangements should define participation conditions and operational elements; they can involve public authorities and ICT third-party providers where appropriate (Art. 45(2)). - Notify the competent authority of participation or cessation once it takes effect (Art. 45(3)). ## Possible Outcomes ### [RESULT] DORA Applies (Simplified ICT Risk Framework) Art. 16 applies instead of Arts. 5-15 - Apply DORA Chapter II via Art. 16 minimum framework requirements (sound documented ICT risk framework; monitoring; continuity; testing; third-party dependencies). - Other DORA chapters still apply where relevant (incident reporting, testing, third-party risk) subject to proportionality (Art. 4). TLPT does not apply to Art. 16(1) entities (Art. 26(1)). ### [RESULT] DORA Applies (Microenterprise) Tailored obligations across DORA - DORA applies, but several requirements are scaled for microenterprises (see microenterprise-specific provisions across DORA). - Use proportionality (Art. 4) to implement incident reporting, testing, and third-party risk in a practical, evidence-ready way. ### [RESULT] DORA Applies (Full Framework + TLPT) Advanced testing required - Implement the full ICT risk management framework (Arts. 5-15) and related obligations across Chapters III-V as applicable. - Perform TLPT at least every 3 years on live production systems supporting critical or important functions, as validated by competent authorities (Art. 26). ### [RESULT] DORA Applies (Full ICT Risk Framework) Full framework; TLPT not required - Implement the full ICT risk management framework (Arts. 5-15) and related obligations across Chapters III-V as applicable. - Use proportionality to tailor implementation (Art. 4), and run the required testing programme (Arts. 24-25) even if TLPT is not required (Art. 26). ### [RESULT] CTPP Oversight Applies Critical ICT third-party provider under DORA - Expect oversight by a Lead Overseer and supervisory engagement (Chapter V, Section II). - Financial entities remain responsible for their own compliance, but oversight targets the critical provider's services supporting financial entities' critical or important functions. ### [RESULT] Not Designated as CTPP DORA primarily impacts you via customer contractual requirements - Expect contractual terms under Art. 30, including security, audit/access, data return/exit, and subcontracting controls where applicable. - Expect to support customers' resilience testing where relevant, including TLPT cooperation where required (Arts. 26-27 and Art. 30(3)). ### [RESULT] Out of Scope DORA does not directly apply - You are not an entity listed in Art. 2(1), or an Art. 2(3) exclusion applies. - Even if not directly in scope, you may be impacted via contractual demands from DORA-regulated customers. ### [RESULT] Out of Scope (Member State Exclusion) Excluded under Art. 2(4) option - Your Member State has excluded certain entities from DORA under the optional exclusion in Art. 2(4). - Confirm the national scope and any subsequent changes to the exclusion as published by your Member State. ## DORA Timeline | Date | Event | Reference | | --- | --- | --- | | 2022-12-14 | DORA adopted | Reg. (EU) 2022/2554 | | 2022-12-27 | DORA published in Official Journal (OJ L 333) | Reg. (EU) 2022/2554 | | 2023-01-16 | DORA enters into force (20 days after publication) | Reg. (EU) 2022/2554 | | 2024-05-30 | CTPP designation criteria and oversight fees acts published in OJ | Reg. (EU) 2024/1502 and 2024/1505 | | 2024-06-25 | RTS on incident classification, contracts, and ICT risk management published in OJ | Reg. (EU) 2024/1772, 2024/1773, 2024/1774 | | 2024-12-02 | Register of information ITS (templates) published in OJ | Reg. (EU) 2024/2956 | | 2025-01-17 | DORA applies | Reg. (EU) 2022/2554 | | 2025-02-20 | Incident reporting RTS and ITS published in OJ | Reg. (EU) 2025/301 and 2025/302 | | 2025-06-18 | TLPT RTS published in OJ | Reg. (EU) 2025/1190 | | 2025-07-02 | Subcontracting RTS published in OJ | Reg. (EU) 2025/532 | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2022-12-14 | DORA adopted | Legislative History | Reg. (EU) 2022/2554 (of 14 December 2022) | | 2022-12-27 | DORA published in Official Journal | Official Publication | OJ L 333, 27.12.2022 | | 2022-12-27 | Alignment Directive (EU) 2022/2556 published | Official Publication | | | 2023-01-16 | DORA enters into force | Official Publication | Art. 64 | | 2023-06-19 | ESAs first batch public consultation opens | ESAs Mandates & Deliverables | | | 2023-07-17 | Commission PSD2 review report deadline (cyber resilience of payment systems) | Commission Mandates & Reviews | Art. 58(2) | | 2023-09-11 | ESAs first batch public consultation closes | ESAs Mandates & Deliverables | | | 2023-12-08 | ESAs second batch public consultation opens | ESAs Mandates & Deliverables | | | 2024-01-17 | Deadline: ESAs submit first wave draft RTS/ITS to the Commission | ESAs Mandates & Deliverables | Arts. 15, 16(3), 18(4), 28(9)-(10) | | 2024-03-04 | ESAs second batch public consultation closes | ESAs Mandates & Deliverables | | | 2024-05-30 | Delegated Regs. 2024/1502 and 2024/1505 published in OJ | Delegated & Implementing Acts (OJ) | OJ L, 2024/1502 and 2024/1505, 30.5.2024 | | 2024-06-25 | Delegated Regs. 2024/1772, 2024/1773, 2024/1774 published in OJ | Delegated & Implementing Acts (OJ) | OJ L, 2024/1772, 2024/1773, 2024/1774, 25.6.2024 | | 2024-07-17 | Deadline: ESAs submit draft RTS/ITS for incident reporting content and templates | ESAs Mandates & Deliverables | Art. 20 | | 2024-07-17 | Deadline: ESAs submit draft RTS for TLPT (TIBER-EU framework) | ESAs Mandates & Deliverables | Art. 26(11) | | 2024-07-17 | Deadline: ESAs develop guidelines on annual costs and losses from major incidents | ESAs Mandates & Deliverables | Art. 11(11) | | 2024-07-17 | Deadline: ESAs issue guidelines on oversight cooperation and information exchange | ESAs Mandates & Deliverables | Art. 32(7) | | 2024-07-17 | Deadline: ESAs submit draft RTS on subcontracting assessments | ESAs Mandates & Deliverables | Art. 30(5) | | 2024-07-17 | Deadline: ESAs submit draft RTS enabling the conduct of oversight activities | ESAs Mandates & Deliverables | Art. 41(2) | | 2024-07-17 | ESAs publish second batch of policy products (incl. TLPT RTS) | ESAs Mandates & Deliverables | | | 2024-07-17 | Deadline: Commission delegated act on further criteria for critical ICT third-party designation | Commission Mandates & Reviews | Art. 31(6) | | 2024-07-17 | Deadline: Commission delegated act on oversight fees | Commission Mandates & Reviews | Art. 43(2) | | 2024-11-29 | Oversight Forum mandate (JC_24_93) | CTPP Oversight | | | 2024-12-02 | Implementing Reg. 2024/2956 published in OJ (register templates) | Register of Information | Reg. (EU) 2024/2956 | | 2025-01-16 | Lead Overseer applies sub-criterion for CTPP designation (sub-criterion 1.4) | CTPP Oversight | Delegated Reg. (EU) 2024/1502 Art. 7 | | 2025-01-17 | DORA applies | Applicability | Art. 64 | | 2025-01-17 | EU Hub feasibility report due | ESAs Mandates & Deliverables | Art. 21(3) | | 2025-01-17 | ESAs publish feasibility report on EU Hub centralisation (JC 2024 108) | ESAs Mandates & Deliverables | | | 2025-01-17 | Member States notify penalty and criminal-law measures | National Obligations | Art. 53 | | 2025-01-17 | Application date - Guidelines on oversight cooperation and information exchange | Guidelines (Level 3) | | | 2025-02-20 | Delegated Reg. 2025/301 published in OJ (incident reporting RTS) | Delegated & Implementing Acts (OJ) | OJ L, 2025/301, 20.2.2025 | | 2025-02-20 | Implementing Regulation 2025/302 - incident reporting templates (ITS) | Delegated & Implementing Acts (OJ) | OJ L, 2025/302, 20.2.2025 | | 2025-03-06 | Corrigendum (01) to Delegated Reg. 2024/1774 | Corrigendum | | | 2025-05-15 | Corrigendum (02) to Delegated Reg. 2024/1774 | Corrigendum | | | 2025-05-19 | Application date - Guidelines on costs/losses estimation | Guidelines (Level 3) | | | 2025-06-18 | Delegated Reg. 2025/1190 published in OJ (TLPT RTS) | Delegated & Implementing Acts (OJ) | OJ L, 2025/1190, 18.6.2025 | | 2025-07-02 | Delegated Reg. 2025/532 published in OJ (subcontracting assessments) | Delegated & Implementing Acts (OJ) | Reg. (EU) 2025/532 | | 2025-09-11 | Corrigendum to Implementing Reg. 2025/302 (incident templates) | Corrigendum | | | 2025-09-12 | Corrigendum to Delegated Reg. 2025/301 (non-EN) | Corrigendum | | | 2025-09-19 | Corrigendum to Implementing Reg. 2024/2956 (register templates) | Corrigendum | | | 2025-11-18 | First list of designated CTPPs published | CTPP Oversight | | | 2026-01-17 | Commission review on auditors and audit firms due | Commission Mandates & Reviews | Art. 58(3) | | 2028-01-17 | Commission review of DORA due | Commission Mandates & Reviews | Art. 58(1) | **Event details:** - **2022-12-14 - DORA adopted**: Regulation (EU) 2022/2554 on digital operational resilience for the financial sector is adopted by the European Parliament and the Council (date of the act: 14 December 2022). - **2022-12-27 - DORA published in Official Journal**: Regulation (EU) 2022/2554 is published in the Official Journal of the European Union (OJ L 333, 27.12.2022). - **2022-12-27 - Alignment Directive (EU) 2022/2556 published**: Directive (EU) 2022/2556 is published, aligning sectoral directives with DORA; Member States must transpose it by 17 January 2025. - **2023-01-16 - DORA enters into force**: DORA enters into force on the twentieth day following its publication in the Official Journal (27 December 2022 -> 16 January 2023). - **2023-06-19 - ESAs first batch public consultation opens**: First batch of DORA policy products consultation window opens. - **2023-07-17 - Commission PSD2 review report deadline (cyber resilience of payment systems)**: Within the PSD2 review context, the Commission must submit a report to the European Parliament and Council no later than 17 July 2023 assessing the need for increased cyber resilience of payment systems and payment-processing activities. - **2023-09-11 - ESAs first batch public consultation closes**: Closure of first batch consultation window. - **2023-12-08 - ESAs second batch public consultation opens**: Second batch of DORA policy mandates consultation opens. - **2024-01-17 - Deadline: ESAs submit first wave draft RTS/ITS to the Commission**: Deadline for ESAs (through the Joint Committee) to submit several draft RTS/ITS to the Commission, including RTS on ICT risk management, RTS on the simplified ICT risk management framework, RTS on incident classification (materiality thresholds), and draft ITS/RTS related to the register of information and ICT third-party risk policy. - **2024-03-04 - ESAs second batch public consultation closes**: Closure of second batch consultation window. - **2024-05-30 - Delegated Regs. 2024/1502 and 2024/1505 published in OJ**: Delegated Regulations (EU) 2024/1502 (designation criteria for critical ICT third-party service providers; adopted 22 February 2024) and 2024/1505 (oversight fees; adopted 22 February 2024) are published in the Official Journal. - **2024-06-25 - Delegated Regs. 2024/1772, 2024/1773, 2024/1774 published in OJ**: Delegated Regulations (EU) 2024/1772 (incident classification), 2024/1773 (policy content for ICT third-party contractual arrangements supporting critical/important functions) and 2024/1774 (ICT risk management tools/methods and simplified framework) are published in the Official Journal (all adopted 13 March 2024). - **2024-07-17 - Deadline: ESAs submit draft RTS/ITS for incident reporting content and templates**: Deadline for ESAs (through the Joint Committee, in consultation with ENISA and the ECB) to submit to the Commission draft RTS on incident-report content and time limits, and draft ITS on standard forms/templates/procedures for reporting major ICT-related incidents and notifying significant cyber threats. - **2024-07-17 - Deadline: ESAs submit draft RTS for TLPT (TIBER-EU framework)**: Deadline for ESAs (in agreement with the ECB) to submit to the Commission draft RTS specifying criteria and detailed requirements for threat-led penetration testing (TLPT), including methodology phases, internal testers, and cooperation/mutual recognition aspects. - **2024-07-17 - Deadline: ESAs develop guidelines on annual costs and losses from major incidents**: Deadline for ESAs (through the Joint Committee) to develop common guidelines on the estimation of aggregated annual costs and losses caused by major ICT-related incidents. - **2024-07-17 - Deadline: ESAs issue guidelines on oversight cooperation and information exchange**: Deadline for ESAs to issue guidelines on cooperation between ESAs and competent authorities under the CTPP oversight framework, including task allocation/execution procedures and information-exchange details needed for follow-up of Lead Overseer recommendations. - **2024-07-17 - Deadline: ESAs submit draft RTS on subcontracting assessments**: Deadline for ESAs (through the Joint Committee) to submit to the Commission draft RTS specifying further which elements a financial entity needs to determine and assess when subcontracting ICT services supporting critical or important functions. - **2024-07-17 - Deadline: ESAs submit draft RTS enabling the conduct of oversight activities**: Deadline for ESAs (through the Joint Committee) to submit to the Commission draft RTS specifying harmonised conditions enabling the conduct of oversight activities for critical ICT third-party service providers (including information requests, reporting, and Joint Examination Team arrangements). - **2024-07-17 - ESAs publish second batch of policy products (incl. TLPT RTS)**: ESAs publish the second batch of DORA policy products, including the TLPT RTS and the draft RTS/ITS for incident reporting. - **2024-07-17 - Deadline: Commission delegated act on further criteria for critical ICT third-party designation**: Deadline for the Commission to adopt a delegated act supplementing DORA by specifying further the criteria for the designation of ICT third-party service providers as critical for financial entities (implemented via Delegated Regulation (EU) 2024/1502 of 22 February 2024; OJ publication 30 May 2024). - **2024-07-17 - Deadline: Commission delegated act on oversight fees**: Deadline for the Commission to adopt a delegated act determining the amount of the oversight fees to be paid by critical ICT third-party service providers and the way those fees are to be paid (implemented via Delegated Regulation (EU) 2024/1505 of 22 February 2024; OJ publication 30 May 2024). - **2024-11-29 - Oversight Forum mandate (JC_24_93)**: Mandate of the Oversight Forum as a Joint Committee Sub-Committee of the European Supervisory Authorities (JC 2024 93, dated 29 November 2024). - **2024-12-02 - Implementing Reg. 2024/2956 published in OJ (register templates)**: Implementing Regulation (EU) 2024/2956 is published, laying down implementing technical standards establishing standard templates for the register of information. - **2025-01-16 - Lead Overseer applies sub-criterion for CTPP designation (sub-criterion 1.4)**: Under Delegated Regulation (EU) 2024/1502, the Lead Overseer applies sub-criterion 1.4 for the criticality assessment of ICT third-party service providers as of 16 January 2025. - **2025-01-17 - DORA applies**: DORA applies from 17 January 2025. - **2025-01-17 - EU Hub feasibility report due**: ESAs joint report assessing the feasibility of further centralisation of incident reporting through a single EU Hub is due to the European Parliament, Council and Commission by 17 January 2025. - **2025-01-17 - ESAs publish feasibility report on EU Hub centralisation (JC 2024 108)**: ESAs publish their joint report on the feasibility of further centralising reporting of major ICT-related incidents through a single EU Hub (DORA Art. 21). - **2025-01-17 - Member States notify penalty and criminal-law measures**: Member States must notify the Commission, ESMA, EBA and EIOPA of laws/regulations implementing the chapter on administrative penalties (and any relevant criminal law provisions) by 17 January 2025. - **2025-01-17 - Application date - Guidelines on oversight cooperation and information exchange**: Joint Guidelines application date for oversight cooperation and information exchange. - **2025-02-20 - Delegated Reg. 2025/301 published in OJ (incident reporting RTS)**: Delegated Regulation (EU) 2025/301 (adopted 23 October 2024) specifies the content and time limits for the initial notification, and intermediate and final reports on, major ICT-related incidents, and the content of voluntary notifications of significant cyber threats. - **2025-02-20 - Implementing Regulation 2025/302 - incident reporting templates (ITS)**: Implementing Regulation (EU) 2025/302 (adopted 23 October 2024) lays down implementing technical standards establishing the standard forms, templates and procedures for reporting major ICT-related incidents and notifying significant cyber threats, including use under transitional arrangements pending any EU Hub implementation (OJ publication 20 February 2025; earlier drafts sometimes used month-level dating). - **2025-03-06 - Corrigendum (01) to Delegated Reg. 2024/1774**: First corrigendum to Delegated Regulation (EU) 2024/1774 (ICT risk management) published. - **2025-05-15 - Corrigendum (02) to Delegated Reg. 2024/1774**: Second corrigendum to Delegated Regulation (EU) 2024/1774 (ICT risk management) published. - **2025-05-19 - Application date - Guidelines on costs/losses estimation**: Application date for the costs/losses Guidelines. - **2025-06-18 - Delegated Reg. 2025/1190 published in OJ (TLPT RTS)**: Delegated Regulation (EU) 2025/1190 (adopted 13 February 2025) specifies RTS on criteria and detailed requirements for threat-led penetration testing (TLPT). - **2025-07-02 - Delegated Reg. 2025/532 published in OJ (subcontracting assessments)**: Delegated Regulation (EU) 2025/532 is published, specifying elements to determine and assess when subcontracting ICT services supporting critical or important functions. - **2025-09-11 - Corrigendum to Implementing Reg. 2025/302 (incident templates)**: Corrigendum to Implementing Regulation (EU) 2025/302 published. - **2025-09-12 - Corrigendum to Delegated Reg. 2025/301 (non-EN)**: Corrigendum to Delegated Regulation (EU) 2025/301 published; OJ note indicates it does not concern the English version. - **2025-09-19 - Corrigendum to Implementing Reg. 2024/2956 (register templates)**: Corrigendum to Implementing Regulation (EU) 2024/2956 published. - **2025-11-18 - First list of designated CTPPs published**: The European Supervisory Authorities publish the first list of designated critical ICT third-party service providers (CTPPs). - **2026-01-17 - Commission review on auditors and audit firms due**: Commission must review and submit a report (and, where appropriate, a legislative proposal) on strengthened digital operational resilience requirements for statutory auditors and audit firms by 17 January 2026. - **2028-01-17 - Commission review of DORA due**: Commission must review DORA and submit a report (and, where appropriate, a legislative proposal) by 17 January 2028. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-operational-resilience-act --- --- title: "EU NIS2 Directive (EU) 2022/2555" canonical_url: "https://www.sorena.io/artifacts/eu/nis2-directive" source_url: "https://www.sorena.io/artifacts/eu/nis2-directive" author: "Sorena AI" description: "A practical EU NIS2 Directive artifact grounded in Directive (EU) 2022/2555, the Article 3 and Article 4 Commission guidelines." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU NIS2 Directive compliance" - "Directive (EU) 2022/2555" - "NIS2 scope Annex I Annex II" - "NIS2 Article 3 essential entity important entity" - "NIS2 Article 21 controls" - "NIS2 Article 23 reporting" - "NIS2 early warning within 24 hours" - "NIS2 incident notification within 72 hours" - "NIS2 final report within 1 month" - "NIS2 transposition tracker" - "Implementing Regulation (EU) 2024/2690" - "ENISA NIS2 technical implementation guidance" - "NIS2" - "Cybersecurity risk management" - "Incident reporting" - "Article 21" - "Transposition" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU NIS2 Directive (EU) 2022/2555 A practical EU NIS2 Directive artifact grounded in Directive (EU) 2022/2555, the Article 3 and Article 4 Commission guidelines. ![EU NIS2 artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-nis2-timeline-small.jpg?v=cheatsheets%2Fprod) *NIS2* *Free Resource* ## EU NIS2 Directive Timeline and Compliance Decision Flow Use this artifact to scope NIS2 applicability under Annex I or Annex II, test the size cap and regardless of size triggers, decide whether you are an essential or important entity, and convert Article 20, Article 21, and Article 23 into an implementation plan. NIS2 entered into force on 16 January 2023. Member States had to transpose it by 17 October 2024 and apply national measures from 18 October 2024. The exact supervisory route, reporting portal, and local penalty regime still depend on Member State implementation. [Run the NIS2 applicability test](/artifacts/eu/nis2-directive/applicability-test.md) ## What you can decide faster - **In scope or out of scope**: Annex I or Annex II mapping, size cap logic, regardless of size triggers, and Article 4 overlap checks. - **Essential vs important**: What changes in supervision, evidence expectations, management accountability, and enforcement. - **Controls + reporting**: Article 21 measures, Implementing Regulation (EU) 2024/2690 where relevant, and Article 23 reporting. By Sorena AI | Grounded in official EU sources | Updated March 2026 ### Quick scan *NIS2* - **Scope**: Map services to Annex I or Annex II and document size and jurisdiction logic. - **Controls**: Implement Article 21 measures and the 2024/2690 baseline where applicable. - **Reporting**: Run a 24h early warning, 72h notification, and 1 month final report workflow. Use the linked guides to turn NIS2 into scope memos, management approvals, incident runbooks, and evidence packs. | Value | Metric | | --- | --- | | 16 Jan 2023 | In force | | 17 Oct 2024 | Transposition | | 17 Apr 2025 | Entity lists | | 2024/2690 | Implementing act | **Key highlights:** Essential vs important | Article 21 baseline | 24h/72h reporting ## Topic Guides - [Applicability Test | EU NIS2 Directive (EU) 2022/2555 | In Scope? Essential vs Important?](/artifacts/eu/nis2-directive/applicability-test.md): A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers. - [Article 21 Control Baseline | EU NIS2 Directive (EU) 2022/2555 | Cybersecurity Risk Management Measures](/artifacts/eu/nis2-directive/article-21-control-baseline.md): A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence. - [Checklist | EU NIS2 Directive (EU) 2022/2555 | Audit-Ready Owners, Evidence, Acceptance Criteria](/artifacts/eu/nis2-directive/checklist.md): An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline. - [Compliance Guide | EU NIS2 Directive (EU) 2022/2555 | Build an Audit-Ready Program](/artifacts/eu/nis2-directive/compliance.md): A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows. - [Deadlines and Compliance Calendar | EU NIS2 Directive (EU) 2022/2555 | 16 January 2023, 17 October 2024, 17 April 2025](/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar.md): A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023. - [FAQ | EU NIS2 Directive (EU) 2022/2555 | Scope, Essential vs Important, Article 21, Article 23 (24h/72h)](/artifacts/eu/nis2-directive/faq.md): High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires. - [Incident Reporting Workflow | EU NIS2 Directive (EU) 2022/2555 | 24h Early Warning, 72h Notification, Final Report (1 Month)](/artifacts/eu/nis2-directive/incident-reporting-workflow.md): A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents. - [Management Body Accountability | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Training, Liability](/artifacts/eu/nis2-directive/management-body-accountability.md): A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work. - [National Transposition Tracker | EU NIS2 Directive (EU) 2022/2555 | How to Track Local Laws, Authorities, Portals](/artifacts/eu/nis2-directive/national-transposition-tracker.md): A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes. - [NIS2 vs ISO/IEC 27001 | How to Reuse Your ISMS for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27001.md): A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review. - [NIS2 vs ISO/IEC 27017 | Cloud Security Mapping for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27017.md): A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations. - [NIS2 vs NIS1 | Directive (EU) 2022/2555 vs Directive (EU) 2016/1148 | Scope, Supervision, Reporting](/artifacts/eu/nis2-directive/nis2-vs-nis1.md): A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works. - [Penalties and Fines | EU NIS2 Directive (EU) 2022/2555 | Article 32-34 Enforcement + Fine Thresholds](/artifacts/eu/nis2-directive/penalties-and-fines.md): A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use. - [Requirements | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Article 21 Controls, Article 23 Reporting](/artifacts/eu/nis2-directive/requirements.md): A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690. - [Scope: Essential vs Important | EU NIS2 Directive (EU) 2022/2555 | Article 3 Classification + What Changes](/artifacts/eu/nis2-directive/scope-essential-vs-important.md): A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3). - [Supply Chain Security Program | EU NIS2 Directive (EU) 2022/2555 | Article 21(d) Supplier Risk + Evidence](/artifacts/eu/nis2-directive/supply-chain-security-program.md): A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance. ## Key dates for cybersecurity planning *NIS2 Timeline* Track adoption, transposition, entity list deadlines, the 2024 implementing regulation, the 2025 Commission enforcement step on late transposition, and the 2026 targeted amendment proposal while keeping your local overlays current. ## How to structure a NIS2 scoping review *NIS2 Decision Flow* Use the decision flow as an EU baseline, then confirm authority routes, entity listing mechanics, and national penalty rules in each Member State where you operate. *Next step* ## Turn EU NIS2 Directive Timeline and Compliance Decision Flow into an operational assessment workflow EU NIS2 Directive Timeline and Compliance Decision Flow should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into Research Copilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU NIS2 Directive Timeline and Compliance Decision Flow and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for EU NIS2 Directive Timeline and Compliance Decision Flow. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs from the same artifact. - **Download decision flow**: Share the scoping logic internally. - **Download timeline**: Coordinate milestones across teams. - [Talk through EU NIS2 Directive Timeline and Compliance Decision Flow](/contact.md): Review your current process, evidence model, and next steps for EU NIS2 Directive Timeline and Compliance Decision Flow. ## Decision Steps ### STEP 1: Do you provide services or carry out activities within the EU? - NIS2 applies through Member State transposition and supervision. - As a rule, it applies to certain Annex I/II entity types that are medium-sized or larger and provide services or carry out activities within the Union. - NIS2 also sets jurisdiction rules; for certain entity types, if not established in the Union but offering services within the Union, a representative in the Union must be designated. - **YES** Do you exclusively operate in national security / defence / law enforcement (or provide services exclusively to those bodies)? - **NO** NIS2 likely not your primary regime ### STEP 2: Do you exclusively operate in national security / defence / law enforcement (or provide services exclusively to those bodies)? - NIS2 does not apply to certain public administration entities in these areas. - Member States may exempt certain other entities from NIS2 obligations for these activities/services; trust service providers are carved out from that exemption. - NIS2 does not apply to entities exempted from the scope of Regulation (EU) 2022/2554 (DORA) under Article 2(4) of that Regulation. - **YES** Possible exemption for certain activities/services - **NO** Are you covered by NIS2 regardless of your size? ### STEP 3: Are you covered by NIS2 regardless of your size? - NIS2 includes several categories regardless of enterprise size. - Member States can also apply NIS2 to local public administration entities and to education institutions (especially where they carry out critical research). - **YES** Do you provide domain name registration services? - **NO** Is your entity type listed in NIS2 Annex I (sectors of high criticality)? ### STEP 4: Do you provide domain name registration services? - NIS2 explicitly covers entities providing domain name registration services regardless of size. - Separate provisions include a registry (ENISA) and obligations on domain name registration data. - **YES** In scope: Domain name registration services - **NO** Are you explicitly considered an Essential Entity under NIS2 (Article 3)? ### STEP 5: Are you explicitly considered an Essential Entity under NIS2 (Article 3)? - Essential entities include: qualified trust service providers, TLD registries and DNS service providers (regardless of size). - Essential entities also include: central government public administration entities; and critical entities under Directive (EU) 2022/2557. - Providers of public electronic communications networks/services are essential if they qualify as a medium-sized enterprise under the SME definition. - If a Member State so provides, entities identified before 16 January 2023 as operators of essential services under NIS1 may be treated as essential entities. - **YES** Likely Essential Entity under NIS2 - **NO** Likely Important Entity under NIS2 ### STEP 6: Is your entity type listed in NIS2 Annex I (sectors of high criticality)? - Annex I lists sectors of high criticality and specific entity types (for example energy, transport, banking, health, digital infrastructure, public administration, and more). - If you are Annex I and large (exceed medium-sized ceilings), you are generally an essential entity; otherwise you are generally an important entity unless your Member State identifies you differently. - **YES** Do you qualify as a medium-sized enterprise or larger (SME definition)? - **NO** If not Annex I: is your entity type listed in NIS2 Annex II (other critical sectors)? ### STEP 7: Do you qualify as a medium-sized enterprise or larger (SME definition)? - As a rule, NIS2 applies to Annex I/II entity types that qualify as medium-sized enterprises, or exceed the medium-sized ceilings. - If you are micro or small, you may still be covered if your Member State identifies you under the risk-based criteria in Article 2(2)(b)-(f), or if other size-independent rules apply. - **YES** Do you exceed the ceilings for medium-sized enterprises (i.e., are you large)? - **NO** Country-specific NIS2 review needed ### STEP 8: Do you exceed the ceilings for medium-sized enterprises (i.e., are you large)? - Large Annex I entities are generally classified as essential entities under Article 3(1)(a). - If you do not exceed medium-sized ceilings, you are generally an important entity (unless Member State identification applies). - **YES** Likely Essential Entity under NIS2 - **NO** Likely Important Entity under NIS2 ### STEP 6B: If not Annex I: is your entity type listed in NIS2 Annex II (other critical sectors)? - Annex II lists other critical sectors and specific entity types. - Annex II entities that are medium-sized or larger are generally classified as important entities (unless Member State identification applies). - **YES** Do you qualify as a medium-sized enterprise or larger (SME definition)? - **NO** NIS2 likely not your primary regime ### STEP 7B: Do you qualify as a medium-sized enterprise or larger (SME definition)? - As a rule, NIS2 applies to Annex I/II entity types that qualify as medium-sized enterprises, or exceed the medium-sized ceilings. - If you are micro or small, you may still be covered if your Member State identifies you under the risk-based criteria in Article 2(2)(b)-(f), or if other size-independent rules apply. - **YES** Likely Important Entity under NIS2 - **NO** Country-specific NIS2 review needed ## Reference Information ### In-scope Regardless of Size (Examples) - Providers of public electronic communications networks or publicly available electronic communications services (Art. 2(2)(a)(i)) - Trust service providers (Art. 2(2)(a)(ii)) - Top-level domain name registries and DNS service providers (Art. 2(2)(a)(iii)) - Entities identified as critical entities under Directive (EU) 2022/2557 (Art. 2(3)) - Entities providing domain name registration services (Art. 2(4)) - Central government public administration entities; and certain regional public administration entities (Art. 2(2)(f)) - Member-State identified entities under Art. 2(2)(b)-(e) (sole provider, significant public safety/health impact, systemic risk, national/regional criticality) - Member States may apply NIS2 to local public administration entities and to education institutions (Art. 2(5)) ### Annex I - Sectors of High Criticality (Sector/Subsector) - Energy: Electricity; District heating and cooling; Oil; Gas; Hydrogen - Transport: Air; Rail; Water; Road - Banking - Financial market infrastructures - Health - Drinking water - Waste water - Digital infrastructure - ICT service management (business-to-business) - Public administration - Space ### Annex II - Other Critical Sectors (Sector/Subsector) - Postal and courier services - Waste management - Manufacture, production and distribution of chemicals - Production, processing and distribution of food - Manufacturing: Medical devices/IVDs; Computers/electronics/optical; Electrical equipment; Machinery; Motor vehicles; Other transport equipment - Digital providers: Online marketplaces; Online search engines; Social networking services platforms - Research: Research organisations ### SME Thresholds (Recommendation 2003/361/EC, Annex Article 2) - SME category: < 250 persons and turnover ≤ EUR 50m and/or balance sheet total ≤ EUR 43m - Medium-sized enterprise: in SME category but not micro or small - Small enterprise: < 50 persons and turnover and/or balance sheet total ≤ EUR 10m - Microenterprise: < 10 persons and turnover and/or balance sheet total ≤ EUR 2m - Large enterprise: exceeds the medium-sized ceilings (not an SME) ### Governance (Article 20) - Management bodies must approve risk-management measures and oversee implementation (Art. 20(1)) - Management bodies can be held liable for infringements of Article 21 (Art. 20(1)) - Management body members must follow training; entities should train employees regularly (Art. 20(2)) ### Cybersecurity Risk-Management Measures (Article 21(2)) - Policies on risk analysis and information system security - Incident handling - Business continuity (backup, disaster recovery, crisis management) - Supply chain security (direct suppliers/service providers) - Security in acquisition, development and maintenance (vulnerability handling/disclosure) - Assess effectiveness of measures - Basic cyber hygiene practices and cybersecurity training - Use of cryptography and (where appropriate) encryption - HR security, access control policies and asset management - Multi-factor authentication / continuous authentication; secured communications; secured emergency communications (where appropriate) ### Sector-Specific Union Legal Acts (Article 4) - If a sector-specific EU legal act requires risk-management measures or significant incident notification that are at least equivalent in effect, relevant NIS2 provisions (including supervision/enforcement) do not apply to those entities (Art. 4(1)) - Equivalence can be met where measures are at least equivalent to Art. 21(1)-(2), or reporting is at least equivalent to Art. 23(1)-(6) and allows immediate access to notifications (Art. 4(2)) - If a sector-specific act does not cover all entities in a sector within NIS2 scope, NIS2 continues to apply to entities not covered by that act (Art. 4(1)) ### Implementing Acts & ENISA Guidance (Example) - NIS2 provides for implementing acts laying down technical/methodological requirements for Article 21(2) measures for certain digital providers and trust services (Art. 21(5)) - ENISA guidance supports implementation of Commission Implementing Regulation (EU) 2024/2690 for several digital infrastructure, ICT service management, and digital provider entity types (ENISA, 26 June 2025) ### Significant Incident Reporting (Article 23) - Notify significant incidents without undue delay to CSIRT or competent authority (Art. 23(1)) - A significant incident includes severe operational disruption/financial loss, or considerable material/non-material damage to others (Art. 23(3)) - Where applicable, communicate significant cyber threats to potentially affected service recipients (Art. 23(2)) - Early warning: within 24 hours of becoming aware (Art. 23(4)(a)) - Incident notification: within 72 hours of becoming aware (Art. 23(4)(b)) - Intermediate report: upon request (Art. 23(4)(c)) - Final report: no later than one month after incident notification (Art. 23(4)(d)) - Ongoing incident: progress report + final within one month of handling (Art. 23(4)(e)) - Trust service providers: incident notification within 24 hours for trust-service-impacting significant incidents (Art. 23(4), derogation) ### Supervision & Enforcement (Articles 32-33) - Essential entities: competent authorities can use on-site inspections, off-site supervision (including random checks), and regular/targeted security audits (Art. 32(2)) - Important entities: supervision is conducted ex post (Art. 33(2)) ### Registry & Domain Data (Articles 27-28) - ENISA maintains a registry for specific digital providers (Art. 27(1)) - Member States require registry information submission by 17 January 2025 and updates within 3 months (Art. 27(2)-(3)) - TLD registries and domain name registration service providers must collect/maintain accurate domain registration data (Art. 28(1)-(3)) - Access to specific domain registration data must be provided to legitimate access seekers upon lawful/substantiated requests, with reply within 72 hours (Art. 28(5)) ## Possible Outcomes ### [Essential entity] Likely Essential Entity under NIS2 Essential entities must implement cybersecurity risk-management measures and report significant incidents. Management bodies must approve and oversee measures. - Governance obligations apply to management bodies (Art. 20). - Cybersecurity risk-management measures must include the minimum set in Art. 21(2). - Significant incident reporting includes 24h early warning and 72h incident notification (Art. 23). - Sector-specific Union legal acts may replace certain NIS2 provisions where they are equivalent in effect (Art. 4). ### [Important entity] Likely Important Entity under NIS2 If you are an Annex I/II entity type and are in scope but not classified as essential, you are generally considered an important entity. - Important entities must implement cybersecurity risk-management measures (Art. 21) and report significant incidents (Art. 23). - Management bodies must approve and oversee measures (Art. 20). - If your Member State identifies you as essential under Art. 2(2)(b)-(e), you can be treated as essential (Art. 3(1)(e)). - Sector-specific Union legal acts may replace certain NIS2 provisions where they are equivalent in effect (Art. 4). ### [In scope (DNS)] In scope: Domain name registration services NIS2 applies to entities providing domain name registration services regardless of size, and includes specific registry and domain name registration data obligations. - ENISA maintains a registry that includes entities providing domain name registration services (Art. 27). - Member States require submission of specified registry information and updates (Art. 27(2)-(3)). - Domain name registration data obligations apply to entities providing domain name registration services and to TLD registries (Art. 28). ### [Needs review] Country-specific NIS2 review needed If you are in an Annex I/II sector but are not clearly medium-sized or larger, or if your Member State may identify you under the risk-based criteria, confirm your status using national transposition and competent authority guidance. - Member States can identify additional entities as essential/important under Art. 2(2)(b)-(e). - Public administration at regional level is included based on a risk-based assessment; local public administration and education institutions can be included if a Member State so provides (Art. 2(2)(f), Art. 2(5)). - Some entities can be exempted from certain obligations for specific activities/services related to national security/defence/law enforcement (Art. 2(8)). ### [Potential exemption] Possible exemption for certain activities/services If you operate in national security/defence/law enforcement areas (or provide services exclusively to those bodies), your Member State may exempt you from certain NIS2 obligations for those activities/services. - Public administration entities in these areas are excluded (Art. 2(7)). - Member States may exempt specific entities from obligations in Articles 21 and 23 for those activities/services (Art. 2(8)). - This exemption does not apply where an entity acts as a trust service provider (Art. 2(9)). ### [Out of scope] NIS2 likely not your primary regime Based on EU-activity, special-category, and Annex I/II screens, NIS2 may be less likely to apply. Confirm using your Member State transposition and competent authority guidance. - Scope is set out in Article 2, and Annex I/II list the covered sectors and entity types. - Member States can include additional entities using risk-based criteria. ## NIS2 Timeline (Selected Milestones) | Date | Event | Reference | | --- | --- | --- | | 2022-12-27 | NIS2 published in Official Journal (Directive (EU) 2022/2555) | Dir. 2022/2555 | | 2023-01-16 | NIS2 enters into force | Dir. 2022/2555 | | 2023-09-14 | Commission Guidelines on Article 3(4) published (entity list template) | 2023/C 324/02 | | 2023-09-18 | Commission Guidelines on Article 4(1)-(2) published | 2023/C 328/02 | | 2024-10-17 | National transposition deadline | Transposition | | 2024-10-18 | NIS1 repealed; NIS2 measures apply | Art. 44 | | 2025-06-26 | ENISA NIS2 Technical Implementation Guidance published | ENISA | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2020-12-16 | Commission publishes NIS2 proposal | Legislative History | COM(2020) 823 | | 2021-12-03 | Council agrees its position | Legislative History | | | 2022-05-13 | Political agreement reached | Legislative History | | | 2022-07-13 | ITRE committee adopts agreed text | Legislative History | | | 2022-11-10 | Parliament plenary adoption | Legislative History | | | 2022-11-28 | Council formal adoption | Legislative History | | | 2022-12-14 | Final act signed by co-legislators | Official Publication | | | 2022-12-27 | Published in Official Journal | Official Publication | OJ L 333, 27.12.2022 | | 2023-01-16 | Entry into force | Official Publication | | | 2023-07-17 | Commission deadline for Article 4 guidelines | Commission Deliverables | Art. 4(3) | | 2023-09-14 | Guidelines on Article 3(4) published | Commission Deliverables | 2023/C 324/02 | | 2023-09-18 | Guidelines on Article 4(1)-(2) published | Commission Deliverables | 2023/C 328/02 | | 2023-12-22 | Corrigendum: Article 19(1) deadline wording | Corrigendum | Art. 19(1) | | 2024-02-01 | Cooperation Group work programme due | Cooperation & Networks | Art. 14(7) | | 2024-07-17 | EU-CyCLONe first report due | Cooperation & Networks | Art. 16(7) | | 2024-10-17 | Implementing Regulation 2024/2690 adopted | Implementing Acts | Reg. (EU) 2024/2690 | | 2024-10-17 | Transposition deadline | National Transposition | Art. 41(1) | | 2024-10-18 | Implementing Regulation 2024/2690 published in OJ | Implementing Acts | OJ L 2024/2690 | | 2024-10-18 | NIS1 repealed, NIS2 measures apply | National Transposition | Art. 44 | | 2024-11-07 | Implementing Regulation 2024/2690 enters into force | Implementing Acts | OJ L 2024/2690 | | 2025-01-17 | Registry information submission due | National Obligations | Art. 27(2) | | 2025-01-17 | Member States notify penalty rules | National Obligations | Art. 36 | | 2025-01-17 | CSIRTs network progress report due | Cooperation & Networks | Art. 15(4) | | 2025-01-17 | Peer-review methodology due | Cooperation & Networks | Art. 19(1) | | 2025-04-17 | Entity list established | National Obligations | Art. 3(3) | | 2025-04-17 | Aggregate entity data notification | National Obligations | Art. 3(5) | | 2025-06-26 | ENISA technical implementation guidance published | Cooperation & Networks | Version 1.0 | | 2026-01-20 | Commission proposes NIS2 amendment | Legislative History | COM(2026) 13 | | 2027-10-17 | Commission review of NIS2 | Commission Deliverables | Art. 40 | **Event details:** - **2020-12-16 - Commission publishes NIS2 proposal**: European Commission publishes the NIS2 proposal COM(2020) 823 final, proposing measures for a high common level of cybersecurity across the Union. - **2021-12-03 - Council agrees its position**: Council agrees its position (general approach) to start negotiations with the European Parliament. - **2022-05-13 - Political agreement reached**: Council and European Parliament reach provisional political agreement on NIS2. - **2022-07-13 - ITRE committee adopts agreed text**: EP Industry, Research and Energy (ITRE) committee adopts the agreed text after trilogue. - **2022-11-10 - Parliament plenary adoption**: European Parliament adopts NIS2 in plenary: 577 in favour, 6 against, 31 abstentions. - **2022-11-28 - Council formal adoption**: Council of the EU formally adopts NIS2. - **2022-12-14 - Final act signed by co-legislators**: NIS2 Directive signed by both co-legislators on 14 December 2022. - **2022-12-27 - Published in Official Journal**: Directive (EU) 2022/2555 published in the Official Journal of the European Union (OJ L 333, 27.12.2022). - **2023-01-16 - Entry into force**: NIS2 enters into force on the 20th day following OJ publication (16 January 2023). Member States have until 17 October 2024 to transpose. - **2023-07-17 - Commission deadline for Article 4 guidelines**: Commission deadline to provide guidelines clarifying the application of Article 4(1) and Article 4(2). - **2023-09-14 - Guidelines on Article 3(4) published**: Commission publishes Guidelines on the application of Article 3(4) with a data-collection template for establishing entity lists. - **2023-09-18 - Guidelines on Article 4(1)-(2) published**: Commission publishes Guidelines on equivalence with sector-specific Union legal acts, pursuant to Article 4(3) (deadline was 17 Jul 2023). - **2023-12-22 - Corrigendum: Article 19(1) deadline wording**: Corrigendum changes Article 19(1) deadline wording from 'on' to 'by' 17 January 2025 for the Cooperation Group peer-review methodology. - **2024-02-01 - Cooperation Group work programme due**: Cooperation Group must establish a work programme by 1 February 2024 and every two years thereafter. - **2024-07-17 - EU-CyCLONe first report due**: EU-CyCLONe must submit a report assessing its work to the European Parliament and Council by 17 July 2024 and every 18 months thereafter. - **2024-10-17 - Implementing Regulation 2024/2690 adopted**: Commission adopts Implementing Regulation (EU) 2024/2690 specifying technical and methodological requirements and incident-significance criteria for listed digital infrastructure and service providers. OJ publication 18 Oct 2024; enters into force 20 days later. - **2024-10-17 - Transposition deadline**: Member States must adopt and publish national transposition measures by 17 October 2024. Measures apply from 18 October 2024. - **2024-10-18 - Implementing Regulation 2024/2690 published in OJ**: Commission Implementing Regulation (EU) 2024/2690 is published in the Official Journal on 18 October 2024. - **2024-10-18 - NIS1 repealed, NIS2 measures apply**: Directive (EU) 2016/1148 (NIS1) is repealed with effect from 18 October 2024. National NIS2 measures apply from this date. - **2024-11-07 - Implementing Regulation 2024/2690 enters into force**: Commission Implementing Regulation (EU) 2024/2690 enters into force on the twentieth day following its Official Journal publication (published 18 October 2024). - **2025-01-17 - Registry information submission due**: Member States must require entities referred to in Article 27(1) to submit registry information to competent authorities by 17 January 2025. - **2025-01-17 - Member States notify penalty rules**: Member States must notify the Commission of their national penalty rules and enforcement measures by 17 January 2025. - **2025-01-17 - CSIRTs network progress report due**: CSIRTs network must adopt a report assessing progress in operational cooperation by 17 January 2025 and every two years thereafter. - **2025-01-17 - Peer-review methodology due**: Cooperation Group must establish the peer-review methodology and organisational aspects by 17 January 2025. - **2025-04-17 - Entity list established**: Member States must establish a list of essential and important entities (and entities providing domain name registration services) by 17 April 2025. - **2025-04-17 - Aggregate entity data notification**: Competent authorities must notify the Commission and Cooperation Group of aggregate list data (number of essential and important entities per sector) by 17 April 2025 and every two years thereafter. - **2025-06-26 - ENISA technical implementation guidance published**: ENISA publishes the NIS2 Technical Implementation Guidance (version 1.0) supporting implementation of Implementing Regulation (EU) 2024/2690. - **2026-01-20 - Commission proposes NIS2 amendment**: Commission publishes proposal to amend NIS2 (simplification and alignment). This is a proposal, not yet law. - **2027-10-17 - Commission review of NIS2**: The Commission shall review the functioning of the NIS2 Directive by 17 October 2027 and every 36 months thereafter, and submit a report to the European Parliament and Council. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/nis2-directive --- --- title: "EU CSRD Timeline, Reporting Decision Flow, and ESRS Guides" canonical_url: "https://www.sorena.io/artifacts/eu-csrd" source_url: "https://www.sorena.io/artifacts/eu/corporate-sustainability-reporting-directive" author: "Sorena AI" description: "Use this CSRD hub to confirm scope, apply the stop the clock amendment correctly, build an ESRS reporting model, and prepare double materiality." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "EU CSRD" - "Directive (EU) 2022/2464" - "ESRS" - "CSRD deadlines" - "stop the clock CSRD" - "CSRD applicability" - "double materiality" - "value chain data" - "sustainability statement" - "limited assurance" - "ESEF sustainability reporting" - "Taxonomy Article 8" - "Assurance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Timeline, Reporting Decision Flow, and ESRS Guides Use this CSRD hub to confirm scope, apply the stop the clock amendment correctly, build an ESRS reporting model, and prepare double materiality. ![EU CSRD artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-csrd-timeline-small.jpg?v=cheatsheets%2Fprod) *CSRD* *Free Resource* ## EU CSRD Timeline, reporting decision flow and ESRS guides Use this artifact to determine whether Directive (EU) 2022/2464 applies, assign the correct reporting wave after the 2025 stop the clock amendment, and build a reporting system for double materiality, value chain data, ESRS disclosures, assurance, and digital publication. The dates on many CSRD summaries are now stale. Wave one still started with financial years beginning on or after 1 January 2024. Directive (EU) 2025/794 pushed the second wave to financial years beginning on or after 1 January 2027 and the listed SME wave to financial years beginning on or after 1 January 2028. [Plan CSRD reporting](/contact.md) ## What you can decide faster - **Who reports when**: Confirm the entity category, the reporting boundary, and the current start year without relying on outdated wave charts. - **What to disclose**: Route ESRS general, topical, value chain, and Taxonomy linked work into one data model. - **What must be reviewable**: Prepare the evidence, markup, and assurance controls that can survive audit committee and external scrutiny. By Sorena AI | Updated 2026 | No signup required ### Quick scan *CSRD* - **Wave check**: Use the stop the clock amendment before you set your first reporting year. - **ESRS engine**: Build the double materiality, IRO, and value chain logic before drafting disclosures. - **Assurance pack**: Link narrative, metrics, taxonomy KPIs, and digital files to one evidence model. Start with the decision flow, then use the topic pages to build materiality, controls, value chain methods, and filing readiness. | Value | Metric | | --- | --- | | FY 2024 | Wave 1 | | FY 2027 | Wave 2 | | FY 2028 | Wave 3 | | 1 Oct 2026 | Assurance stds | **Key highlights:** Double materiality | Value chain data | Assurance ready ## Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/corporate-sustainability-reporting-directive/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/corporate-sustainability-reporting-directive/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/corporate-sustainability-reporting-directive/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/corporate-sustainability-reporting-directive/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/corporate-sustainability-reporting-directive/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/corporate-sustainability-reporting-directive/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/corporate-sustainability-reporting-directive/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/corporate-sustainability-reporting-directive/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/corporate-sustainability-reporting-directive/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/corporate-sustainability-reporting-directive/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/corporate-sustainability-reporting-directive/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/corporate-sustainability-reporting-directive/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/corporate-sustainability-reporting-directive/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/corporate-sustainability-reporting-directive/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/corporate-sustainability-reporting-directive/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/corporate-sustainability-reporting-directive/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. ## Key dates for rollout, ESRS, and assurance *CSRD Timeline* Track the current wave dates, ESRS support acts, and assurance deadlines so finance, ESG, legal, and reporting teams work from one calendar. ## Does CSRD apply and what must you build first *CSRD Decision Flow* Follow the reporting decision flow to test scope, assign the right first reporting year, and route the result into ESRS, value chain, Taxonomy, assurance, and filing workstreams. *Next step* ## Turn EU CSRD Timeline, reporting decision flow and ESRS guides into an ESG delivery workflow EU CSRD Timeline, reporting decision flow and ESRS guides should be the shared entry point for your team. Route execution into ESG Compliance for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU CSRD Timeline, reporting decision flow and ESRS guides and route the work by entity, product, team, or control owner. - Use ESG Compliance to manage cross team sustainability work, reporting, and evidence from one workflow. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open ESG Compliance](/solutions/esg-compliance.md): Manage cross team sustainability work, reporting, and evidence from one workflow for EU CSRD Timeline, reporting decision flow and ESRS guides. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share scope and wave logic with finance and ESG. - **Download timeline**: Align the reporting calendar with the current law. - [Talk through EU CSRD Timeline, reporting decision flow and ESRS guides](/contact.md): Review your current process, evidence model, and next steps for EU CSRD Timeline, reporting decision flow and ESRS guides. ## Decision Steps ### STEP 1: Is your company an EU undertaking (formed under Member State law)? *Reference: Directive (EU) 2022/2464; Directive 2013/34/EU (as amended)* - CSRD introduces sustainability reporting obligations for certain EU undertakings and certain third-country undertakings through amendments to Directive 2013/34/EU. - If yes: follow the EU track to determine whether you are a large undertaking, a listed SME (except micro), a small and non-complex credit institution, a captive insurer, or a parent of a large group. - If no: follow the third-country track to check the Art. 40a thresholds (net turnover >EUR 150 million in the Union for each of the last two consecutive financial years, plus a qualifying EU subsidiary or branch). - **YES** Does your company exceed the size criteria for a large undertaking? - **NO** Does your non-EU company generate EUR 150M+ net turnover in the EU in each of the last two consecutive financial years? ### STEP 2: Does your company exceed the size criteria for a large undertaking? *Reference: Art. 3(4) Directive 2013/34/EU* - A large undertaking exceeds at least two of the following on its balance sheet date: (a) 250 employees; (b) EUR 20M balance sheet total; (c) EUR 40M net turnover. - If yes: CSRD reporting applies starting FY 2025 (reports in 2026). Some companies already subject to NFRD start earlier (FY 2024, reports in 2025). - If no but your securities are listed: check if you are a listed SME (next step). - **YES** CSRD Applies (Large EU Company) - **NO** Are your securities admitted to trading on an EU regulated market and are you an SME (not a micro-undertaking)? ### STEP 3: Are your securities admitted to trading on an EU regulated market and are you an SME (not a micro-undertaking)? *Reference: Directive (EU) 2022/2464; Directive 2013/34/EU (as amended)* - Listed SMEs (except micro-undertakings) must report under CSRD. - Micro-undertaking (as defined for the Accounting Directive): does not exceed at least two of: EUR 350k balance sheet total; EUR 700k net turnover; 10 employees. - Micro-undertakings are exempt. - For financial years starting before 2028-01-01, listed SMEs may decide not to include sustainability reporting in their management report, but must briefly state why it was not provided (Directive 2013/34/EU, Art. 19a(7)). - Listed SMEs report in accordance with sustainability reporting standards for SMEs adopted under Directive 2013/34/EU (Art. 29c). - **YES** CSRD Applies (Listed SME) - **NO** Are you a small/non-complex credit institution or a captive insurance undertaking? ### STEP 4: Are you a small/non-complex credit institution or a captive insurance undertaking? *Reference: Art. 29a(2b) Directive 2013/34/EU* - Small and non-complex credit institutions (as defined in CRD Art. 4(1)(145)) and captive insurance undertakings (Solvency II Art. 13(2)) are also subject to CSRD. - Reporting starts for FY 2026 (reports in 2027), if in scope as large undertakings or as listed SMEs (as applicable). - If yes: proceed to reporting obligations. - If no: you are likely out of scope unless you are parent of a large group. - **YES** CSRD Applies (Small Credit Institution / Captive Insurer) - **NO** Are you a parent undertaking of a large group? ### STEP 5: Are you a parent undertaking of a large group? *Reference: Art. 29a Directive 2013/34/EU* - If your group (on a consolidated basis) exceeds the large undertaking thresholds (at least two of: 250 employees; EUR 20M balance sheet; EUR 40M turnover), you must prepare consolidated sustainability reporting. - Subsidiary exemption: an EU subsidiary may be exempt from preparing its own sustainability statement if included in the consolidated report of its parent and certain conditions are met (Art. 19a(9)). - If yes: consolidated reporting applies. - **YES** CSRD Applies (Parent of Large Group) - **NO** Out of Scope ### NON-EU TRACK: Does your non-EU company generate EUR 150M+ net turnover in the EU in each of the last two consecutive financial years? *Reference: Art. 40a & 40b Directive 2013/34/EU* - Non-EU companies must report if they have (a) net turnover > EUR 150M in the EU in each of the last two consecutive FYs, AND (b) at least one EU subsidiary meeting large/listed criteria OR an EU branch with net turnover > EUR 40M in the preceding FY. - Reporting starts for FY 2028 (reports in 2029). - If yes: check if you have an EU subsidiary or branch meeting the criteria. - **YES** Do you have an EU subsidiary (large or listed) or an EU branch with EUR 40M+ turnover? - **NO** Out of Scope ### NON-EU TRACK: Do you have an EU subsidiary (large or listed) or an EU branch with EUR 40M+ turnover? *Reference: Art. 40a(1) Directive 2013/34/EU* - If you have an EU subsidiary that is a large undertaking or listed company, OR an EU branch with net turnover exceeding EUR 40M in the preceding FY, you must publish a sustainability report. - One EU subsidiary or the branch is designated to publish the report on behalf of the non-EU parent. - If yes: proceed to non-EU reporting obligations. - **YES** CSRD Applies (Non-EU Company) - **NO** Out of Scope ## Reference Information ### Companies In Scope (Overview) - EU large undertakings and parent undertakings of large groups are subject to sustainability reporting under Directive 2013/34/EU (as amended by CSRD). - Listed SMEs (except micro-undertakings) and certain financial undertakings have later application dates, with a temporary opt-out for financial years starting before 2028-01-01 (Directive 2013/34/EU, Art. 19a(7)). - Third-country undertakings can be in scope via EU subsidiaries or branches if thresholds in Art. 40a are met (net turnover >EUR 150 million in the Union for each of the last two consecutive financial years, plus a qualifying EU subsidiary or branch). ### Double Materiality Assessment - ESRS uses a double materiality principle: sustainability matters are material if they are material from an impact perspective, a financial perspective, or both (ESRS 1, chapter 3). - Impact materiality focuses on actual and potential impacts connected with the undertaking's business, including in its upstream and downstream value chain. - Financial materiality focuses on sustainability-related risks and opportunities that trigger, or could reasonably be expected to trigger, material financial effects on the undertaking. ### ESRS Structure (Sector-Agnostic Standards) - ESRS 1: General requirements (definitions, concepts, materiality, reporting principles). - ESRS 2: General disclosures (mandatory for all companies; governance, strategy, impact/risk/opportunity management). - Environmental standards: ESRS E1 (Climate change), E2 (Pollution), E3 (Water and marine resources), E4 (Biodiversity and ecosystems), E5 (Resource use and circular economy). - Social standards: ESRS S1 (Own workforce), S2 (Workers in the value chain), S3 (Affected communities), S4 (Consumers and end-users). - Governance standard: ESRS G1 (Business conduct: anti-corruption, bribery, political engagement, lobbying, payment practices). - Topical ESRS disclosures are subject to the materiality assessment. Undertakings can omit a topical standard if the topic is not material, but ESRS E1 climate change requires a detailed explanation when concluded not material (ESRS 1; ESRS 2 IRO-2). - Sector-specific ESRS and ESRS for SMEs are provided for under the Directive and developed via delegated acts. ### Core Reporting Areas (ESRS Disclosure Requirements) - Governance (GOV): describe governance structure, roles and responsibilities of administrative/management/supervisory bodies, integration of sustainability into governance. - Strategy (SBM): describe business model, strategy, and how material impacts, risks, and opportunities interact with strategy and business model; disclose interests and views of stakeholders. - Impact, Risk, and Opportunity management (IRO): describe the process to identify, assess, and manage material sustainability matters; explain which ESRS disclosure requirements are covered by the sustainability statement. - Metrics and Targets: for each material sustainability matter, disclose policies (MDR-P), actions (MDR-A), targets (MDR-T), and metrics specific to each ESRS (e.g., GHG emissions for E1, diversity metrics for S1, supply chain due diligence for S2, anti-corruption metrics for G1). - Value chain reporting: determine at which level within own operations and the upstream and downstream value chain material sustainability matters arise, based on the impacts, risks and opportunities identified through double materiality. ### Assurance & Digital Tagging Requirements - Sustainability reporting is subject to an assurance engagement under the amended EU audit framework (see CSRD amendments). - CSRD provides for Commission action on assurance standards, including a deadline for limited assurance standards (no later than 2026-10-01). - Digital tagging: CSRD links sustainability reporting to the EU single electronic reporting format framework. ESEF requires annual financial reports to be prepared in XHTML and IFRS consolidated financial statements to be marked up using Inline XBRL. ### Phase-In and Simplifications (First-Year Reporting) - ESRS 1 Appendix C lists phase-in provisions for disclosure requirements and datapoints that may be omitted or that are not applicable in the first year(s) of ESRS reporting. - First-year relief: undertakings are not required to disclose comparative information in the first year of preparation of the sustainability statement under ESRS. - If an undertaking or group does not exceed 750 employees (average during the financial year), Appendix C allows omitting certain disclosures (examples: scope 3 and total GHG emissions datapoints under ESRS E1-6 in the first year; all ESRS E4 disclosure requirements for the first 2 years; and all ESRS S2, S3, and S4 disclosure requirements for the first 2 years). - Appendix C also allows first-year omissions and (in some cases) qualitative-only disclosure for a limited period when quantitative disclosure is impracticable (examples: ESRS 2 SBM-3 anticipated financial effects; ESRS E1-9 anticipated financial effects; ESRS E2-6 and ESRS E3-5 anticipated financial effects). ### Subsidiary Exemption - A subsidiary undertaking can be exempt from preparing sustainability reporting when it and its subsidiary undertakings are included in the consolidated management report of a parent undertaking drawn up in accordance with Articles 29 and 29a (group-level sustainability reporting). - This also applies when the parent undertaking is established in a third country, if the consolidated sustainability reporting is carried out in accordance with ESRS (adopted under Article 29b) or in a manner equivalent to ESRS (equivalence determined via an implementing act under Directive 2004/109/EC). - If exempted, the subsidiary's management report must include: the name and registered office of the parent; weblinks to the parent's consolidated management report (or consolidated sustainability reporting) and the assurance opinion; and a statement that the subsidiary is exempt. - If the parent is established in a third country, additional publication conditions apply, and the Article 8 Taxonomy disclosures covering the activities of the exempted EU subsidiary and its subsidiary undertakings must be included either in the subsidiary's management report or in the parent's consolidated sustainability reporting. ### Value Chain Reporting (Practical Approach) - CSRD requires sustainability information, where applicable, to cover the undertaking's own operations and its value chain, including products and services, business relationships, and supply chain. - For the first 3 years of application, if not all necessary value chain information is available, the undertaking explains: the efforts made to obtain the information, the reasons why not all information could be obtained, and its plans to obtain the information in the future. - ESRS requires disclosures about measurement uncertainty and assumptions, including where amounts depend on upstream and downstream value chain data availability and quality. - If you use estimates or proxies, describe the assumptions, approximations, and judgements used, and improve data quality and coverage over time. ### Interoperability with Global Standards - The ESRS delegated regulation notes that the Commission introduced modifications to support a high degree of interoperability with global standard-setting initiatives. - ESRS allows undertakings to include, in addition to ESRS disclosures, information stemming from other legislation and from other generally accepted sustainability reporting standards and frameworks, as long as ESRS requirements are met (and partial application must be precisely referenced). - If a sustainability matter is material but not covered by a topical ESRS, ESRS requires additional entity-specific disclosures, which may draw on available frameworks or reporting standards (examples mentioned in ESRS include IFRS industry-based guidance and GRI Sector Standards). - For scenario analysis, ESRS application requirements cite external guidance such as TCFD scenario analysis publications as examples an undertaking may consider. ### Sector-Specific ESRS (Future Development) - EU law provides for sustainability reporting standards that include both cross-sector (sector-agnostic) requirements and sector-specific requirements to reflect the sustainability-related risks and impacts that are common within sectors. - Directive (EU) 2024/1306 postponed the deadline for adopting delegated acts for the sector-specific sustainability reporting standards from 30 June 2024 to 30 June 2026. - Directive (EU) 2024/1306 also states that this postponement should not prevent the Commission from publishing sector-specific delegated acts earlier, and that the Commission should endeavor to adopt delegated acts containing eight sector-specific standards as soon as each is ready. - Once adopted, sector-specific standards supplement the sector-agnostic ESRS. ### EU Taxonomy Disclosures (Article 8 Regulation (EU) 2020/852) - CSRD references the disclosures laid down in Article 8 of Regulation (EU) 2020/852 (EU Taxonomy) and, in some cases, requires that those disclosures are included alongside sustainability reporting (for example, in certain exemption or third-country structures). - Commission Delegated Regulation (EU) 2021/2178 specifies the content and presentation of the Article 8 disclosures and the methodology to comply with that disclosure obligation. - Taxonomy reporting uses key performance indicators for non-financial undertakings, including turnover, capital expenditure (CapEx), and operating expenditure (OpEx), using the required templates and calculation rules. ### Climate Transition Plan (ESRS E1) - ESRS E1 Disclosure Requirement E1-1 requires the undertaking to disclose its transition plan for climate change mitigation. - ESRS application requirements explain that a transition plan disclosure is expected to provide a high-level explanation of how the undertaking will adjust its strategy and business model to ensure compatibility with the transition to a sustainable economy and with limiting global warming to 1.5 degrees C in line with the Paris Agreement, and the EU objective of climate neutrality by 2050. - ESRS E1-1 includes disclosure about investments and funding supporting implementation of the transition plan, and can reference taxonomy-aligned CapEx key performance indicators where relevant. - ESRS E1-1 includes disclosure about how the transition plan is embedded in and aligned with overall business strategy and financial planning, whether the plan is approved by the administrative, management and supervisory bodies, and progress in implementing the plan. - If the undertaking does not have a transition plan, it must indicate whether and, if so, when it will adopt one. ### ESRS 2 General Disclosures (Mandatory for All) - ESRS 2 disclosure requirements apply to all undertakings subject to CSRD, irrespective of the outcome of the materiality assessment. - ESRS 2 includes general disclosures across governance (GOV), strategy and business model (SBM), and the process to identify and assess impacts, risks and opportunities (IRO). - ESRS 2 includes minimum disclosure requirements for policies (MDR-P), actions and resources (MDR-A), and targets (MDR-T) related to material sustainability matters. - Topical ESRS disclosures build on ESRS 2 and are determined through the materiality assessment (subject to specific always-applicable requirements listed in ESRS). ## Possible Outcomes ### [RESULT] CSRD Applies (Large EU Company) Reporting starts FY 2025 (or FY 2024 if already NFRD) - Prepare the sustainability reporting required under Directive 2013/34/EU (as amended by CSRD) in accordance with ESRS (Delegated Reg. (EU) 2023/2772). - Determine disclosures using the ESRS double materiality principle (impact materiality and financial materiality). - Apply the phase-in schedule in Art. 5(2): NFRD-type undertakings report first for FY 2024; other large undertakings report first for FY 2025. - Obtain assurance on sustainability reporting as required by the amended EU audit framework (see CSRD amendments). ### [RESULT] CSRD Applies (Listed SME) Reporting starts FY 2026 (with temporary opt-out before 2028) - Listed SMEs (except micro-undertakings) are within scope for financial years starting on or after 2026-01-01 (Art. 5(2)). - For financial years starting before 2028-01-01, listed SMEs may decide not to include sustainability reporting in their management report, but must briefly state why it was not provided (Directive 2013/34/EU, Art. 19a(7)). - Listed SMEs report in accordance with sustainability reporting standards for SMEs adopted under Directive 2013/34/EU (Art. 29c). ### [RESULT] CSRD Applies (Small Credit Institution / Captive Insurer) Reporting starts FY 2026 - Small and non-complex credit institutions and captive insurance and reinsurance undertakings can rely on a derogation that limits sustainability reporting to a defined set of information and must report in accordance with sustainability reporting standards for SMEs (Directive 2013/34/EU, Art. 19a(6) and Art. 29c). - Application dates follow the CSRD phase-in schedule (Art. 5(2)). ### [RESULT] CSRD Applies (Parent of Large Group) Consolidated sustainability reporting required - Parent undertakings of large groups prepare consolidated sustainability reporting in the consolidated management report. - Applies to groups exceeding at least two of: 250 employees (on average); EUR 20M balance sheet total; EUR 40M net turnover (on consolidated basis). - Subsidiary exemption can apply where subsidiaries are included in consolidated sustainability reporting and the conditions in Directive 2013/34/EU are met (Art. 19a(9)). - Consolidated report must cover all subsidiaries included in the consolidated financial statements. - Consolidated reporting is prepared in accordance with ESRS adopted pursuant to Directive 2013/34/EU (Art. 29b). ### [RESULT] CSRD Applies (Non-EU Company) Reporting starts FY 2028 - Non-EU companies with EUR 150M+ net turnover in the EU (in each of last two consecutive FYs) and an EU subsidiary (large/listed) or EU branch (EUR 40M+ turnover) must report. - A designated EU subsidiary or the branch publishes the sustainability report on behalf of the non-EU parent. - The sustainability report must be drawn up in accordance with standards adopted for third-country undertakings, or may be drawn up in accordance with ESRS or in a manner equivalent to ESRS (Art. 40a(2)). The deadline for adopting certain third-country reporting standards was revised by Directive (EU) 2024/1306. - The sustainability report is published accompanied by an assurance opinion, or a statement if the assurance opinion is not made available (Art. 40a(3)). - First reporting period: FY 2028 (reports in 2029). ### [RESULT] Out of Scope CSRD does not directly apply - Your company does not meet the CSRD scope criteria. - You may still be impacted indirectly via contractual or supply chain demands from CSRD-regulated companies. - Voluntary sustainability reporting frameworks may still be relevant for customers, lenders, and procurement. ## CSRD Application Timeline | Date | Event | Reference | | --- | --- | --- | | 2022-12-14 | CSRD adopted | Directive (EU) 2022/2464 | | 2022-12-16 | CSRD published in Official Journal (OJ L 322) | Directive (EU) 2022/2464 | | 2023-01-05 | CSRD enters into force (20th day after publication) | Directive (EU) 2022/2464 | | 2023-07-31 | First set of ESRS adopted by Commission | Delegated Reg. (EU) 2023/2772 | | 2023-12-22 | ESRS published in Official Journal | Delegated Reg. (EU) 2023/2772 | | 2024-07-06 | Member State transposition deadline for CSRD core provisions | Directive (EU) 2022/2464 Art. 5(1) | | 2024-01-01 | Measures apply for FY starting on/after this date for companies already subject to NFRD (large PIE with 500+ employees) | Directive (EU) 2022/2464 Art. 5(2) | | 2025-01-01 | Measures apply for FY starting on/after this date for other large undertakings and parent undertakings of large groups | Directive (EU) 2022/2464 Art. 5(2) | | 2026-01-01 | Measures apply for FY starting on/after this date for listed SMEs (except micro) and certain financial undertakings | Directive (EU) 2022/2464 Art. 5(2) | | 2028-01-01 | Measures apply for FY starting on/after this date for certain non-EU undertakings (third-country reporting) | Directive (EU) 2022/2464 Art. 5(2) | | 2026-10-01 | Commission deadline to adopt limited assurance standards for sustainability reporting (no later than) | Directive (EU) 2022/2464 | | 2026-06-30 | Revised deadline for adopting certain ESRS delegated acts (sector and certain third-country standards) | Directive (EU) 2024/1306 | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2014-10-22 | Non-Financial Reporting Directive (NFRD) adopted | Legislative Milestones | | | 2020-06-11 | Public consultation on review of the NFRD closes | Consultations | | | 2021-03-08 | Commission publishes proposal for CSRD | Legislative Milestones | | | 2021-04-21 | Political agreement on CSRD reached | Legislative Milestones | | | 2022-06-22 | EFRAG publishes first set of draft ESRS | Reporting Standards (ESRS) | | | 2022-12-14 | CSRD (Directive (EU) 2022/2464) adopted | Legislative Milestones | | | 2022-12-16 | CSRD published in the Official Journal (OJ L 322) | Legislative Milestones | | | 2023-01-05 | CSRD enters into force | Legislative Milestones | | | 2023-06-09 | Public feedback opens on first set of draft sustainability reporting standards | Consultations | | | 2023-07-31 | Commission adopts ESRS Set 1 (Delegated Regulation (EU) 2023/2772) | Reporting Standards (ESRS) | | | 2023-12-22 | ESRS Set 1 published in the Official Journal | Reporting Standards (ESRS) | | | 2024-01-01 | ESRS start applying for financial years beginning on or after 1 January 2024 | Reporting Milestones | | | 2024-01-01 | CSRD starts applying (Wave 1 reporting for FY 2024) | Reporting Milestones | | | 2024-04-29 | Directive (EU) 2024/1306 adopted (extends deadlines for certain ESRS) | Legislative Milestones | | | 2024-06-30 | Original deadline for adopting certain third-country reporting standards | Reporting Standards (ESRS) | | | 2024-07-06 | Member State transposition deadline for CSRD core provisions | Legislative Milestones | | | 2024-08-07 | Commission publishes CSRD implementation FAQ | Implementation Guidance | | | 2025-01-01 | CSRD starts applying (Wave 2 reporting for FY 2025) | Reporting Milestones | | | 2025-07-11 | Commission adopts ESRS quick-fix delegated act | Reporting Standards (ESRS) | | | 2025-09-11 | Scrutiny period ends for ESRS quick-fix delegated act (no objections) | Reporting Standards (ESRS) | | | 2026-01-01 | CSRD starts applying (Wave 3 reporting for FY 2026) | Reporting Milestones | | | 2026-06-30 | Deadline for adopting certain sector and third-country standards (revised) | Reporting Standards (ESRS) | | | 2026-10-01 | Commission deadline to adopt limited assurance standards for sustainability reporting | Reporting Standards (ESRS) | | | 2028-01-01 | Reporting requirement for certain third-country undertakings applies from financial year 2028 | Reporting Milestones | | **Event details:** - **2014-10-22 - Non-Financial Reporting Directive (NFRD) adopted**: Commission CSRD page timeline references adoption of the Non-Financial Reporting Directive on 22 October 2014 (Directive 2014/95/EU). - **2020-06-11 - Public consultation on review of the NFRD closes**: Commission CSRD page timeline: public consultation on the review of the NFRD ended on 11 June 2020. - **2021-03-08 - Commission publishes proposal for CSRD**: Commission CSRD page timeline references publication of the proposal for a Corporate Sustainability Reporting Directive (CSRD) on 8 March 2021. - **2021-04-21 - Political agreement on CSRD reached**: Commission CSRD page timeline references a political agreement by the European Parliament and the Council on CSRD on 21 April 2021. - **2022-06-22 - EFRAG publishes first set of draft ESRS**: Commission CSRD page timeline: first set of draft EU sustainability reporting standards published by EFRAG on 22 June 2022. - **2022-12-14 - CSRD (Directive (EU) 2022/2464) adopted**: Date of the CSRD: 14 December 2022. - **2022-12-16 - CSRD published in the Official Journal (OJ L 322)**: ESRS delegated regulation timeline references the Official Journal date for Directive (EU) 2022/2464: 16 December 2022. - **2023-01-05 - CSRD enters into force**: CSRD enters into force on the twentieth day following its publication in the Official Journal (published 16 December 2022). - **2023-06-09 - Public feedback opens on first set of draft sustainability reporting standards**: Commission CSRD page timeline: opening of a four-week public feedback period on draft sustainability reporting standards on 9 June 2023. - **2023-07-31 - Commission adopts ESRS Set 1 (Delegated Regulation (EU) 2023/2772)**: Commission news and Delegated Regulation timeline: ESRS Set 1 adopted on 31 July 2023. - **2023-12-22 - ESRS Set 1 published in the Official Journal**: Delegated Regulation (EU) 2023/2772 timeline: publication in the Official Journal on 22 December 2023. - **2024-01-01 - ESRS start applying for financial years beginning on or after 1 January 2024**: Delegated Regulation (EU) 2023/2772 timeline: applies from 1 January 2024 for financial years beginning on or after 1 January 2024. - **2024-01-01 - CSRD starts applying (Wave 1 reporting for FY 2024)**: Member States must apply CSRD measures for financial years starting on or after 1 January 2024 for large public-interest entities (and parent undertakings of large groups) exceeding 500 employees. - **2024-04-29 - Directive (EU) 2024/1306 adopted (extends deadlines for certain ESRS)**: Directive (EU) 2024/1306 of 29 April 2024 amends time limits for adoption of sector standards and certain third-country standards (revising the 30 June 2024 deadline to 30 June 2026). - **2024-06-30 - Original deadline for adopting certain third-country reporting standards**: CSRD legal text includes a 30 June 2024 deadline for adopting standards for sustainability reporting by third-country undertakings; this deadline was later revised to 30 June 2026 (Directive (EU) 2024/1306). - **2024-07-06 - Member State transposition deadline for CSRD core provisions**: Member States must bring into force laws, regulations and administrative provisions necessary to comply with Articles 1 to 3 of CSRD by 6 July 2024. - **2024-08-07 - Commission publishes CSRD implementation FAQ**: FAQ page timeline: publication date 7 August 2024. - **2025-01-01 - CSRD starts applying (Wave 2 reporting for FY 2025)**: Member States must apply CSRD measures for financial years starting on or after 1 January 2025 for other large undertakings and parent undertakings of large groups not in Wave 1. - **2025-07-11 - Commission adopts ESRS quick-fix delegated act**: Implementing and delegated acts page timeline: ESRS quick-fix delegated act adopted by the Commission on 11 July 2025. - **2025-09-11 - Scrutiny period ends for ESRS quick-fix delegated act (no objections)**: Implementing and delegated acts page timeline: scrutiny period expired on 11 September 2025 with no objections by the European Parliament or the Council. - **2026-01-01 - CSRD starts applying (Wave 3 reporting for FY 2026)**: Member States must apply CSRD measures for financial years starting on or after 1 January 2026 for listed SMEs (excluding micro-undertakings) and certain financial undertakings, with an opt-out possibility for listed SMEs for a transitional period. - **2026-06-30 - Deadline for adopting certain sector and third-country standards (revised)**: Directive (EU) 2024/1306 timeline: revised time limit for adoption of delegated acts containing certain sustainability reporting standards is 30 June 2026. - **2026-10-01 - Commission deadline to adopt limited assurance standards for sustainability reporting**: CSRD provides that the Commission shall adopt delegated acts on limited assurance standards no later than 1 October 2026. - **2028-01-01 - Reporting requirement for certain third-country undertakings applies from financial year 2028**: Directive (EU) 2024/1306 timeline: reporting requirement for certain third-country undertakings applies as of financial year 2028. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/corporate-sustainability-reporting-directive --- --- title: "EU Medical Device Regulation (MDR) 2017/745 - Timeline and Decision Flow (Scope, Classification, Clinical Evaluation, PMS, UDI/EUDAMED)" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation" author: "Sorena AI" description: "A practical EU MDR artifact for Regulation (EU) 2017/745: confirm medical device or Annex XVI scope, identify economic operator role." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "EU MDR compliance" - "Regulation (EU) 2017/745" - "EU medical device regulation" - "MDR timeline" - "MDR decision flow" - "MDR applicability test" - "MDR device classification" - "MDR Rule 11 software" - "MDR conformity assessment Annex IX Annex X Annex XI" - "MDR technical documentation Annex II Annex III" - "MDR clinical evaluation Annex XIV" - "MDR post-market surveillance PMS plan PSUR" - "MDR vigilance serious incident reporting" - "UDI MDR" - "EUDAMED registration" - "notified body MDR" - "CE marking medical devices" - "MDR" - "Medical devices" - "CE marking" - "UDI" - "EUDAMED" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Medical Device Regulation (MDR) 2017/745 - Timeline and Decision Flow (Scope, Classification, Clinical Evaluation, PMS, UDI/EUDAMED) A practical EU MDR artifact for Regulation (EU) 2017/745: confirm medical device or Annex XVI scope, identify economic operator role. ![EU MDR artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-mdr-timeline-small.jpg?v=cheatsheets%2Fprod) *MDR* *Free Resource* ## EU Medical Device Regulation (MDR) Timeline and Decision Flow Use this artifact to confirm MDR scope, including Annex XVI products, identify your economic operator role, and map a workable MDR route for CE marking, technical documentation, clinical evaluation, PMS, vigilance, UDI, EUDAMED, and legacy transition decisions. MDR has applied since 26 May 2021. Legacy-device transition now depends on Article 120 conditions, the 26 May 2024 and 26 September 2024 cutoffs, and the staged EUDAMED rollout that makes the first four modules mandatory from 28 May 2026. [Run the MDR applicability test](/artifacts/eu/medical-device-regulation/applicability-test.md) ## What you can decide faster - **Is it a medical device (or Annex XVI product)**: Scope, intended purpose, borderline cases, and Annex XVI common specifications. - **Your role and obligations**: Manufacturer, authorised representative, importer, distributor - and what changes if you relabel or modify. - **Classification to conformity route**: Annex VIII classification (incl. software Rule 11) and Annex IX/X/XI evidence routes. By Sorena AI | Updated 2026 | No signup required ### Quick scan *MDR* - **Scope + role**: Confirm medical-device scope, Annex XVI edge cases, and operator responsibilities. - **Transition + evidence**: Test Article 120 eligibility, then align technical file, CER, and PMS evidence. - **Traceability + reporting**: Plan UDI, EUDAMED, vigilance, PSUR, and actor-registration operations. Use the topic guides to turn MDR obligations into owners, evidence, and an execution plan. | Value | Metric | | --- | --- | | 2017 | Regulation | | 2021 | Applies | | UDI | Traceability | | EUDAMED | Registration | **Key highlights:** Scope first | Classification | Evidence planning ## Topic Guides - [Applicability Test | EU Medical Device Regulation (MDR) 2017/745 | Is it a Medical Device? Annex XVI? Software Rule 11?](/artifacts/eu/medical-device-regulation/applicability-test.md): A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions. - [CER Template | EU Medical Device Regulation (MDR) 2017/745 | Clinical Evaluation Report Structure (Annex XIV)](/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template.md): A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV. - [Clinical Evaluation Overview | EU Medical Device Regulation (MDR) 2017/745 | CER, Clinical Evidence Strategy, PMCF](/artifacts/eu/medical-device-regulation/clinical-evaluation-overview.md): A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP). - [Compliance Checklist | EU Medical Device Regulation (MDR) 2017/745 | Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/checklist.md): An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl. - [Compliance Guide | EU Medical Device Regulation (MDR) 2017/745 | QMS, Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/compliance.md): A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment. - [Deadlines and Compliance Calendar | EU Medical Device Regulation (MDR) 2017/745 | Transition, Legacy Devices, EUDAMED](/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar.md): A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions. - [Device Classification Guide | EU Medical Device Regulation (MDR) 2017/745 | Annex VIII + Software Rule 11](/artifacts/eu/medical-device-regulation/device-classification-guide.md): A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration. - [FAQ | EU Medical Device Regulation (MDR) 2017/745 | Scope, Classification, Technical File, Clinical Evaluation, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/faq.md): High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file. - [MDR vs IVDR | EU Medical Device Regulation (MDR) 2017/745 vs IVDR 2017/746 | Classification, Evidence, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/mdr-vs-ivdr.md): A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches. - [Penalties and Fines | EU Medical Device Regulation (MDR) 2017/745 | Enforcement Risk + How to Reduce Exposure](/artifacts/eu/medical-device-regulation/penalties-and-fines.md): A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims. - [PMS and Vigilance | EU Medical Device Regulation (MDR) 2017/745 | PMS Plan, PSUR, Serious Incidents, FSCA](/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance.md): A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days. - [PMS Plan Template | EU Medical Device Regulation (MDR) 2017/745 | Annex III-Aligned Outline + Metrics](/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template.md): A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources. - [QMS and Technical File | EU Medical Device Regulation (MDR) 2017/745 | Annex II/III Technical Documentation + QMS Controls](/artifacts/eu/medical-device-regulation/qms-and-technical-file.md): A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability. - [Requirements | EU Medical Device Regulation (MDR) 2017/745 | Core Obligations + Evidence Outputs](/artifacts/eu/medical-device-regulation/requirements.md): A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance. - [Transition Timelines | EU Medical Device Regulation (MDR) 2017/745 | Legacy Devices, 2023/607 Extension, Significant Changes](/artifacts/eu/medical-device-regulation/transition-timelines.md): A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true. - [UDI and EUDAMED | EU Medical Device Regulation (MDR) 2017/745 | UDI-DI/PI, Basic UDI-DI, Actor Registration, Device Registration](/artifacts/eu/medical-device-regulation/udi-and-eudamed.md): A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration. ## Key dates for device compliance *MDR Timeline* Track application, transitional provisions, and operational milestones that affect certification planning, evidence readiness, and lifecycle obligations. ## Which MDR obligations apply to your device *MDR Decision Flow* Use the decision flow to confirm scope, role, classification, and route assumptions, then identify the evidence you need across design, release, and post-market operations. *Next step* ## Turn EU Medical Device Regulation (MDR) Timeline and Decision Flow into an operational assessment workflow EU Medical Device Regulation (MDR) Timeline and Decision Flow should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU Medical Device Regulation (MDR) Timeline and Decision Flow and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for EU Medical Device Regulation (MDR) Timeline and Decision Flow. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share compliance route logic internally. - **Download timeline**: Align milestones across teams. - [Talk through EU Medical Device Regulation (MDR) Timeline and Decision Flow](/contact.md): Review your current process, evidence model, and next steps for EU Medical Device Regulation (MDR) Timeline and Decision Flow. ## Decision Steps ### STEP 1: Is your product a medical device under EU MDR? *Reference: Art. 2(1) and Art. 1(2)* - A medical device means any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used for one or more specific medical purposes (diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease; diagnosis, monitoring, treatment, alleviation or compensation for an injury or disability; investigation, replacement or modification of anatomy or physiological/pathological process; providing information by in vitro examination of specimens from the human body). - The MDR also applies, from the date of application of relevant common specifications, to certain products without an intended medical purpose listed in Annex XVI. - If borderline case: consult relevant MDCG guidance (for example software and classification guidance) and note that disputes on Annex VIII classification can be referred to the competent authority; the Commission can also decide classification questions by implementing acts (Art. 51). - Some products are excluded from MDR scope (see Art. 1(6)). - **NO** Not a Medical Device - **YES** Classify your device using Annex VIII classification rules ### STEP 2: Classify your device using Annex VIII classification rules *Reference: Art. 51 and Annex VIII* - Devices are divided into classes I, IIa, IIb and III, taking into account intended purpose and inherent risks (Art. 51(1)). - Classification is carried out in accordance with Annex VIII (Art. 51(1)). - If you and a notified body disagree on the application of Annex VIII, the dispute can be referred to the competent authority for a decision (Art. 51(2)). - The Commission can decide classification questions by implementing acts in certain cases (Art. 51(3)-(6)). - -> Is your device classified as Class I under Annex VIII? ### STEP 3: Is your device classified as Class I under Annex VIII? *Reference: Art. 51 and Annex VIII* - Class is determined under MDR Annex VIII (classification rules), based on intended purpose, inherent risks, and vulnerability of patients/users. - If no: continue to check whether the device is Class IIa, IIb, or III. - **YES** Class I Device - **NO** If not Class I: is your device classified as Class IIa under Annex VIII? ### STEP 3A: If not Class I: is your device classified as Class IIa under Annex VIII? *Reference: Annex VIII* - If no: continue to check whether the device is Class IIb or Class III. - **YES** Class IIa Device - **NO** If not Class IIa: is your device classified as Class IIb under Annex VIII? ### STEP 3B: If not Class IIa: is your device classified as Class IIb under Annex VIII? *Reference: Annex VIII* - If no: the device may be Class III. If you are unsure, treat classification as unresolved and escalate for review. - **YES** Class IIb Device - **NO** Class III Device ## Reference Information ### Medical Device Definition - Medical device means any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer for one or more medical purposes (Art. 2(1)). - Medical purposes include: diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease; diagnosis, monitoring, treatment, alleviation or compensation for injury/disability; investigation, replacement or modification of anatomy/physiology/pathology; providing information by in vitro examination of specimens. - Devices may achieve their principal intended action by physical, mechanical, thermal or other means (not pharmacological, immunological or metabolic). Devices may incorporate substances that support the device function. - Accessories (Art. 2(2)) are classified in their own right and can be subject to the MDR even though they are not themselves medical devices. - Software can qualify as a medical device when it is specifically intended for a medical purpose (see MDR definitions and MDCG guidance). - The MDR also uses the term 'devices' to include medical devices, accessories, and Annex XVI products to which it applies (Art. 1(4)). ### Key Exclusions from MDR Scope - In vitro diagnostic medical devices (covered by Regulation (EU) 2017/746). - Medicinal products (Directive 2001/83/EC) and advanced therapy medicinal products (Regulation (EC) No 1394/2007). - Cosmetic products (Regulation (EC) No 1223/2009). - Transplants, tissues or cells of human origin, or products containing or consisting of them; however the MDR applies to devices manufactured utilising derivatives of tissues or cells of human origin which are non-viable or rendered non-viable (Art. 1(6)(g)). - Transplants, tissues or cells of animal origin, or products containing or consisting of them; however the MDR applies to devices manufactured utilising tissues or cells of animal origin, or their derivatives, which are non-viable or rendered non-viable (Art. 1(6)(f)). - Products (other than certain listed cases) that contain or consist of viable biological material or viable organisms (including micro-organisms) in order to achieve or support the intended purpose of the product (Art. 1(6)(h)). ### Classification Rules Overview - Annex VIII contains the classification rules used to determine class I, IIa, IIb, or III based on intended purpose and inherent risks. - Accessories for a medical device and for an Annex XVI product are classified in their own right separately from the device with which they are used (Annex VIII). ### Conformity Assessment Procedures - Conformity assessment procedures are set out in Annexes IX to XI (Art. 52(1)). - Class III: Annex IX, or alternatively Annex X coupled with Annex XI (Art. 52(3)). - Class IIb: Annex IX Chapters I and III (including assessment of technical documentation per Annex IX Section 4), or alternatively Annex X coupled with Annex XI (Art. 52(4)). - Class IIa: Annex IX Chapters I and III (including assessment of technical documentation per Annex IX Section 4), or alternatively Annexes II and III technical documentation coupled with conformity assessment per Annex XI Section 10 or Section 18 (Art. 52(6)). - Class I: manufacturer issues the EU declaration of conformity after drawing up the technical documentation in Annexes II and III; notified body involvement is limited for sterile, measuring-function, and reusable surgical instrument devices as set out in Art. 52(7). - Custom-made devices follow Annex XIII (Art. 52(8)); class III custom-made implantable devices have additional conformity assessment obligations (Art. 52(8), second subparagraph). - Investigational devices are addressed under the clinical investigation provisions (Articles 62 to 82 and Annex XV) and do not bear the CE marking (Art. 20(1) and Art. 21(1)). ### Notified Body Designation and Role - Notified bodies are designated by Member State authorities (Art. 35-50) and listed in NANDO database. - Notified bodies must meet the requirements in Annex VII. - Notified bodies conduct conformity assessments (Annex IX, X, XI), issue certificates (Art. 56), and perform ongoing surveillance (unannounced audits, testing). - Certificates are valid up to 5 years and must be renewed (Art. 56(6)). - For certain class III implantable and class IIb active devices intended to administer and/or remove a medicinal product, the clinical evaluation consultation procedure in Article 54 can apply. ### Technical Documentation (Annex II & III) - Manufacturers of devices (other than custom-made devices) draw up and keep up to date technical documentation; it includes the elements set out in Annexes II and III (Art. 10(4)). - Technical documentation supports assessment of conformity with MDR requirements, including the general safety and performance requirements in Annex I (Art. 10(1) and Art. 10(4)). - Retention: manufacturers keep technical documentation, the EU declaration of conformity and relevant certificates available for at least 10 years after the last device is placed on the market; for implantable devices at least 15 years (Art. 10(8)). - For custom-made devices, documentation requirements are set out in Annex XIII (Art. 10(5) and Art. 52(8)). ### Clinical Evaluation and Investigation - Manufacturers conduct a clinical evaluation in accordance with Article 61 and Annex XIV, including PMCF (Art. 10(3)). - Clinical investigations are addressed in Articles 62 to 82 and Annex XV. - For products without an intended medical purpose listed in Annex XVI, the requirement to demonstrate a clinical benefit is understood as a requirement to demonstrate performance (Art. 61(9)). - MDCG guidance documents provide additional practical guidance on clinical evaluation and PMCF. ### Unique Device Identification (UDI) - Manufacturers comply with the UDI system requirements referred to in Article 27 (Art. 10(7)). - Under Article 123(3)(f), the obligation in Article 27(4) applies from 26 May 2021 for implantable and class III devices, from 26 May 2023 for class IIa and IIb devices, and from 26 May 2025 for class I devices. - Until the Commission designates issuing entities under Article 27(2), GS1, HIBCC and ICCBBA are considered designated issuing entities (Art. 120(12)). - Device registration is addressed in Article 29. ### EUDAMED Registration - The Commission sets up, maintains and manages EUDAMED for transparency, traceability, clinical investigations, vigilance and post-market surveillance, and market surveillance (Art. 33(1)). - EUDAMED includes electronic systems for registration of devices (Art. 29(4)), the UDI database (Art. 28), registration of economic operators (Art. 30), notified bodies and certificates (Art. 57), clinical investigations (Art. 73), vigilance and post-market surveillance (Art. 92), and market surveillance (Art. 100) (Art. 33(2)). - The Commission draws up a plan for implementation of the functional specifications for EUDAMED and publishes a notice when it has achieved full functionality (Art. 34). - The Commission EUDAMED page includes operational updates, including the stated date when the first four modules become mandatory to use. ### Economic Operator Obligations - Manufacturers have general obligations in Article 10 (including risk management, clinical evaluation, technical documentation in Annexes II and III, QMS, post-market surveillance, UDI and registration, and corrective actions). - Where the manufacturer is not established in a Member State, the device may only be placed on the Union market if the manufacturer designates a sole authorised representative (Art. 11(1)). The authorised representative mandate must include at least the tasks listed in Art. 11(3). - If the manufacturer is not established in a Member State and has not complied with the obligations in Article 10, the authorised representative is legally liable for defective devices on the same basis as, and jointly and severally with, the manufacturer (Art. 11(5)). - Importers have obligations in Article 13 (including verifying CE marking and the EU declaration of conformity, that an authorised representative is designated where required, and that required information and UDI are present where applicable). - Distributors have obligations in Article 14 (including verifying CE marking and required information and cooperating on corrective actions). - Manufacturers must have at least one person responsible for regulatory compliance with the requisite expertise available within the organisation (with an exception for micro and small enterprises); authorised representatives must also have such a person at their disposal (Art. 15). - In certain cases, importers, distributors or other persons assume manufacturer obligations (Art. 16). ### Post-Market Surveillance (PMS) - Manufacturers plan, establish, document, implement, maintain and update a post-market surveillance system proportionate to the risk class and appropriate for the type of device (Art. 83). - The post-market surveillance system is based on a post-market surveillance plan (Art. 84 and Annex III). - Class I devices: post-market surveillance report (Art. 85). - Class IIa, IIb and III devices: periodic safety update report (PSUR) (Art. 86). For class IIb and III devices the PSUR is updated at least annually; for class IIa devices at least every two years (Art. 86(1)). - PMCF is part of clinical evaluation and is addressed in Annex XIV (Art. 10(3) and Art. 61). ### Vigilance and Market Surveillance - Serious incident (Art. 87): any malfunction/deterioration in device characteristics/performance, or inadequacy in labeling/IFU that directly/indirectly led to, might have led to, or might lead to death of patient/user/other, or serious deterioration in health. - Manufacturers report serious incidents and field safety corrective actions through the electronic system referred to in Article 92 (Art. 87(1)). - Trend reporting covers statistically significant increases in frequency or severity of incidents or expected undesirable side-effects that could significantly impact the benefit-risk analysis (Art. 88). - Market surveillance provisions include Articles 93 to 100 (including the electronic system on market surveillance referred to in Article 100). ### CE Marking and Declaration of Conformity - Devices (other than custom-made or investigational devices) considered to be in conformity with the MDR bear the CE marking of conformity (Art. 20(1)). - The CE marking is affixed visibly, legibly and indelibly to the device or its sterile packaging; where not possible, it is affixed to the packaging (Art. 20(3)). - The CE marking is affixed before the device is placed on the market and may be followed by a pictogram or other mark indicating a special risk or use (Art. 20(4)). - Where applicable, the CE marking is followed by the identification number of the notified body responsible for the conformity assessment procedures set out in Article 52 (Art. 20(5)). - The EU declaration of conformity states that MDR requirements have been fulfilled, is continuously updated, and contains at least the information set out in Annex IV (Art. 19(1)). - Devices for special purposes (investigational devices and custom-made devices) do not bear the CE marking, with the exception of devices referred to in Article 74 (Art. 21(1)). ### Special Device Categories - Custom-made devices: manufacturers follow Annex XIII and draw up the statement set out in Section 1 of that Annex before placing such devices on the market (Art. 52(8)). Custom-made devices do not bear the CE marking (Art. 21(1)). - Systems and procedure packs: natural or legal persons who combine CE-marked devices (and certain other products) as a system or procedure pack draw up a statement under Article 22; if certain conditions are not met, the system or procedure pack can be treated as a device requiring conformity assessment under Article 52 (Art. 22(4)). - Devices incorporating a medicinal product substance as an integral part (ancillary action): additional procedure elements apply under Art. 52(9) (in addition to the base procedure for the device class). - Certain devices using non-viable tissues or cells of animal or human origin (or derivatives) are in scope under Art. 1(6)(f)-(g) and can have additional procedure elements under Art. 52(10). - Annex XVI products (products without an intended medical purpose): the MDR applies to these groups from the date of application of common specifications adopted under Article 9; Commission Implementing Regulation (EU) 2022/2346 lays down common specifications for Annex XVI groups (Art. 1(2)). - For certain class III implantable and class IIb active devices intended to administer and/or remove a medicinal product, the clinical evaluation consultation procedure in Article 54 can apply. ### Transitional Provisions (Legacy Devices) - Article 120 sets transitional provisions for certain devices certified under Directives 90/385/EEC and 93/42/EEC (AIMDD/MDD). - Under Article 120(2), certain AIMDD/MDD certificates remain valid until the end of the period indicated on the certificate (subject to the conditions and cutoffs in Article 120). - Under Article 120(3), a device covered by a valid AIMDD/MDD certificate may be placed on the market or put into service only if it continues to comply with the relevant Directive and there are no significant changes in design or intended purpose; MDR requirements on post-market surveillance, market surveillance, vigilance, and registration apply instead of the corresponding Directive requirements. - The notified body that issued the legacy certificate remains responsible for appropriate surveillance of the certified device under the conditions in Article 120(3). - Regulation (EU) 2023/607 amended MDR transitional provisions, including extended transition deadlines for certain legacy devices (depending on device category and conditions) and the removal of the MDR/IVDR sell-off date. ### Penalties and Enforcement - Member States must lay down and implement penalties for infringements of the MDR; penalties must be effective, proportionate, and dissuasive (Article 113). - Competent authorities perform market surveillance checks (including documentation review and physical or laboratory checks) and can require documentation and samples and carry out inspections (Article 93). - If a device presents an unacceptable risk, authorities require corrective action and may restrict making available, withdraw, or recall devices (Articles 94-95). - If there is other non-compliance, authorities require it to be remedied and can restrict/prohibit making available, withdraw, or recall if it is not remedied (Article 97). - Member States may take preventive health protection measures for devices or device categories and must notify the Commission and other Member States (Article 98). - Measures taken under Articles 95-98 must follow the MDR good administrative practice requirements (Article 99). ### General Safety and Performance Requirements (Annex I) - Annex I Chapter I sets general requirements for safety and performance, including benefit-risk, risk management, and reducing risks as far as possible. - Annex I Chapter II sets design and manufacturing requirements, including topics like chemical/physical/biological properties, infection and microbial contamination, radiation protection, and electronic programmable systems (including software). - Annex I Chapter III covers information supplied with the device (label and instructions for use), including identification and safe use information appropriate to the intended user and use environment. - For software and electronic programmable systems, Annex I includes state-of-the-art development, verification/validation, and information security/IT security measures (including protection against unauthorised access) needed for the software to run as intended. - Harmonised standards (Article 8) and common specifications (Article 9) can be used to help demonstrate conformity with applicable Annex I requirements. ## Possible Outcomes ### [RESULT] Not a Medical Device MDR does not apply - Your product does not meet the definition of a medical device under MDR. - Check if other EU product legislation applies (for example the IVDR, medicinal products rules, or cosmetics rules) depending on the intended purpose and claims. - For classification disputes under Annex VIII, see Article 51. ### [CLASS I] Class I Device Manufacturer self-declaration (with exceptions) - Conformity assessment: manufacturer draws up the technical documentation in Annexes II and III and issues the EU declaration of conformity referred to in Article 19 (Art. 52(7)). - If the device is placed on the market in sterile condition, has a measuring function, or is a reusable surgical instrument, apply Chapters I and III of Annex IX or Part A of Annex XI; notified body involvement is limited to the specific aspects listed in Art. 52(7)(a)-(c). - Devices (other than custom-made or investigational devices) that are in conformity must bear the CE marking (Art. 20) and must be accompanied by the information set out in Section 23 of Annex I (Art. 10(11)). - Clinical evaluation is required (Art. 10(3), Art. 61, Annex XIV). - Post-market surveillance and vigilance obligations apply (Art. 83-89 and related provisions). - UDI and registration obligations apply as relevant (Art. 27, 29 and 31). ### [CLASS IIa] Class IIa Device Notified body conformity assessment required - Conformity assessment options are set out in Art. 52(6) (Annex IX Chapters I and III, including assessment of technical documentation per Annex IX Section 4) or, alternatively, Annex II and III technical documentation coupled with conformity assessment per Annex XI Section 10 or Section 18 (Art. 52(6)). - Technical documentation is set out in Annexes II and III (Art. 10(4)). - Clinical evaluation is required (Art. 10(3), Art. 61, Annex XIV). - CE marking must be followed by the identification number of the notified body responsible for the conformity assessment procedures set out in Article 52, where applicable (Art. 20(5)). - Post-market surveillance and vigilance obligations apply, including PSUR requirements for class IIa devices (Art. 83-89 and Art. 86). - UDI and registration obligations apply as relevant (Art. 27, 29 and 31). ### [CLASS IIb] Class IIb Device Notified body conformity assessment required - Conformity assessment options are set out in Art. 52(4): Annex IX Chapters I and III (including assessment of technical documentation per Annex IX Section 4 on a representative basis, with additional requirements for certain class IIb implantable devices), or alternatively Annex X coupled with Annex XI. - Technical documentation is set out in Annexes II and III (Art. 10(4)). - Clinical evaluation is required (Art. 10(3), Art. 61, Annex XIV). - CE marking must be followed by the identification number of the notified body responsible for the conformity assessment procedures set out in Article 52, where applicable (Art. 20(5)). - Post-market surveillance and vigilance obligations apply, including PSUR requirements for class IIb devices (Art. 83-89 and Art. 86). - UDI and registration obligations apply as relevant (Art. 27, 29 and 31). ### [CLASS III] Class III Device Highest scrutiny - notified body conformity assessment - Conformity assessment options are set out in Art. 52(3): Annex IX, or alternatively Annex X coupled with Annex XI. - For certain class III implantable devices, the clinical evaluation consultation procedure in Article 54 can apply as specified in Annex IX Section 5.1 or referred to in Annex X Section 6. - Clinical evaluation is required (Art. 10(3), Art. 61, Annex XIV). - CE marking must be followed by the identification number of the notified body responsible for the conformity assessment procedures set out in Article 52, where applicable (Art. 20(5)). - Post-market surveillance and vigilance obligations apply, including PSUR requirements for class III devices (Art. 83-89 and Art. 86). - Implantable devices have additional patient information requirements (Art. 18). ## MDR Timeline | Date | Event | Reference | | --- | --- | --- | | 2017-04-05 | MDR adopted (Regulation (EU) 2017/745) | Reg. (EU) 2017/745 | | 2017-05-05 | MDR published in Official Journal (OJ L 117) | Reg. (EU) 2017/745 | | 2017-05-25 | MDR enters into force (20 days after publication) | Art. 123 | | 2017-11-26 | Articles 35-50 (notified bodies) apply | Art. 123(3)(a) | | 2020-05-26 | Original MDR application date | Art. 123(2) | | 2021-05-26 | Revised MDR application date (COVID-19 postponement) | Reg. (EU) 2020/561 | | 2027-12-31 | Extended transitional deadline for certain legacy devices (if conditions met) | Art. 120 (as amended by Reg. (EU) 2023/607) | | 2028-12-31 | Extended transitional deadline for remaining legacy devices (if conditions met) | Art. 120 (as amended by Reg. (EU) 2023/607) | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2017-04-05 | MDR Adopted | Adoption & Publication | | | 2017-05-05 | MDR Published in Official Journal | Adoption & Publication | | | 2017-05-25 | MDR Entry Into Force | Adoption & Publication | | | 2017-11-26 | Implementing acts deadline: device codes and types list | Application Dates | | | 2017-11-26 | Notified body framework and MDR governance start applying | Application Dates | | | 2018-05-26 | EUDAMED Implementation Plan Due | EUDAMED System | | | 2018-05-26 | Cooperation rules start applying (Article 102) | Application Dates | | | 2019-05-26 | UDI issuing entities interim rule starts applying | Key Deadlines | | | 2020-03-25 | EUDAMED full functionality notice target date | EUDAMED System | | | 2020-05-26 | Common Specifications Adoption Deadline | Key Deadlines | | | 2021-05-26 | MDR Date of Application | Application Dates | | | 2021-05-26 | UDI carrier requirements start for implantable and class III devices | Key Deadlines | | | 2022-12-01 | Annex XVI Common Specifications Adopted | Guidance & Implementation | | | 2022-12-22 | Annex XVI Regulation Enters Into Force | Application Dates | | | 2023-03-15 | Transitional Period Amendment Adopted | Transitional Provisions | | | 2023-03-20 | Transitional Extension Enters Into Force | Transitional Provisions | | | 2023-05-26 | UDI carrier requirements expand to class IIa and IIb devices | Key Deadlines | | | 2023-06-22 | Annex XVI Common Specifications Apply | Application Dates | | | 2023-09-22 | Annex XVI transition: written agreement condition starts | Transitional Provisions | | | 2024-05-26 | Application Lodgement Deadline | Key Deadlines | | | 2024-05-27 | Commission report due on reprocessing of single-use devices (Article 17) | Key Deadlines | | | 2024-06-22 | Annex XVI transition: clinical investigation notification condition starts | Transitional Provisions | | | 2024-09-26 | Written Agreement Deadline | Key Deadlines | | | 2024-12-22 | Annex XVI transition: clinical investigation notification condition ends | Transitional Provisions | | | 2025-05-26 | UDI carrier requirements expand to class I devices | Key Deadlines | | | 2025-06-22 | Annex XVI transition: written agreement condition ends | Transitional Provisions | | | 2026-05-26 | Class III Custom-Made Implants Transition End | Key Deadlines | | | 2026-05-28 | EUDAMED Four Modules Mandatory | EUDAMED System | | | 2027-05-26 | Article 78 procedure starts applying | Application Dates | | | 2027-12-31 | Legacy Class III & Implantables Transition End | Transitional Provisions | | | 2028-06-22 | Annex XVI Products Final Transition End | Transitional Provisions | | | 2028-12-31 | All Legacy Devices Transition End | Transitional Provisions | | **Event details:** - **2017-04-05 - MDR Adopted**: Regulation (EU) 2017/745 on medical devices adopted by the European Parliament and Council - **2017-05-05 - MDR Published in Official Journal**: Official publication of Regulation (EU) 2017/745 in the Official Journal of the European Union - **2017-05-25 - MDR Entry Into Force**: Regulation (EU) 2017/745 entered into force 20 days after publication - **2017-11-26 - Implementing acts deadline: device codes and types list**: By 26 November 2017, the Commission shall draw up, by means of implementing acts, a list of codes and corresponding types of devices. - **2017-11-26 - Notified body framework and MDR governance start applying**: Articles 35 to 50 (notified bodies) and Articles 101 and 103 (competent authorities and the MDCG) apply from 26 November 2017 (Article 123 derogations). - **2018-05-26 - EUDAMED Implementation Plan Due**: Commission deadline to draw up implementation plan for EUDAMED functional specifications - **2018-05-26 - Cooperation rules start applying (Article 102)**: Article 102 (cooperation between competent authorities and the Commission) applies from 26 May 2018 (Article 123 derogations). - **2019-05-26 - UDI issuing entities interim rule starts applying**: Article 120(12) applies from 26 May 2019: until the Commission designates issuing entities, GS1, HIBCC and ICCBBA are considered designated issuing entities. - **2020-03-25 - EUDAMED full functionality notice target date**: The Commission aimed to publish the EUDAMED full functionality notice by 25 March 2020 once EUDAMED achieved full functionality. - **2020-05-26 - Common Specifications Adoption Deadline**: Deadline for the Commission to adopt necessary common specifications for reprocessing of certain single-use devices (Article 17). - **2021-05-26 - MDR Date of Application**: MDR date of application as referenced in Commission guidance on transitional provisions for legacy devices. - **2021-05-26 - UDI carrier requirements start for implantable and class III devices**: Article 27(4) applies from 26 May 2021 for implantable devices and class III devices (Article 123 derogations). - **2022-12-01 - Annex XVI Common Specifications Adopted**: Commission Implementing Regulation (EU) 2022/2346 laying down common specifications for Annex XVI products without medical purpose - **2022-12-22 - Annex XVI Regulation Enters Into Force**: Commission Implementing Regulation (EU) 2022/2346 entered into force - **2023-03-15 - Transitional Period Amendment Adopted**: Regulation (EU) 2023/607 adopted extending transitional provisions for certain devices - **2023-03-20 - Transitional Extension Enters Into Force**: Regulation (EU) 2023/607 entered into force extending transition periods - **2023-05-26 - UDI carrier requirements expand to class IIa and IIb devices**: Article 27(4) applies from 26 May 2023 for class IIa and class IIb devices (Article 123 derogations). - **2023-06-22 - Annex XVI Common Specifications Apply**: Commission Implementing Regulation (EU) 2022/2346 becomes applicable - **2023-09-22 - Annex XVI transition: written agreement condition starts**: For certain Annex XVI products under the transitional arrangements, from 22 September 2023 until 22 June 2025 the product may only be placed on the market or put into service if a written agreement for the performance of the conformity assessment has been signed by the notified body and the manufacturer. - **2024-05-26 - Application Lodgement Deadline**: Manufacturers must lodge formal application for conformity assessment to benefit from extended transition - **2024-05-27 - Commission report due on reprocessing of single-use devices (Article 17)**: By 27 May 2024, the Commission must draw up a report on the operation of Article 17 and submit it to the European Parliament and the Council. - **2024-06-22 - Annex XVI transition: clinical investigation notification condition starts**: From 22 June 2024 until 22 December 2024, certain Annex XVI products under transitional arrangements may only be placed on the market or put into service if the sponsor has received a Member State notification confirming the clinical investigation application is complete and within scope. - **2024-09-26 - Written Agreement Deadline**: Manufacturers and notified bodies must sign written agreement for conformity assessment to benefit from extended transition - **2024-12-22 - Annex XVI transition: clinical investigation notification condition ends**: End of the 22 June 2024 to 22 December 2024 period where certain Annex XVI transitional placements require a Member State notification about a complete clinical investigation application. - **2025-05-26 - UDI carrier requirements expand to class I devices**: Article 27(4) applies from 26 May 2025 for class I devices (Article 123 derogations). - **2025-06-22 - Annex XVI transition: written agreement condition ends**: End of the 22 September 2023 to 22 June 2025 period where certain Annex XVI transitional placements require a written agreement for conformity assessment between a notified body and the manufacturer. - **2026-05-26 - Class III Custom-Made Implants Transition End**: End of specific transitional period for class III custom-made implantable devices (if application lodged and agreement signed) - **2026-05-28 - EUDAMED Four Modules Mandatory**: First four EUDAMED modules (Actors, UDI/Devices, Notified Bodies, Certificates) become mandatory to use - **2027-05-26 - Article 78 procedure starts applying**: The procedure set out in Article 78 applies from 26 May 2027 (Article 123 derogations). - **2027-12-31 - Legacy Class III & Implantables Transition End**: End of extended transitional period for class III devices and implantable devices under MDD/AIMDD certificates - **2028-06-22 - Annex XVI Products Final Transition End**: Deadline tied to transitional arrangements for certain Annex XVI products without an intended medical purpose that were already lawfully marketed before 22 June 2023. - **2028-12-31 - All Legacy Devices Transition End**: End of extended transitional period for all other legacy devices (class I, IIa, IIb non-implantable) under MDD/AIMDD certificates --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation --- --- title: "UK PSTI Act Compliance Hub: Scope, Security Requirements, Statements, and OPSS Readiness" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act" source_url: "https://www.sorena.io/artifacts/uk/product-security-and-telecommunications-infrastructure-act" author: "Sorena AI" description: "Grounded UK PSTI hub covering relevant connectable product scope, the three mandatory security requirements, manufacturer importer distributor duties." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "UK PSTI Act compliance" - "relevant connectable products" - "UKSI 2023 1007" - "statement of compliance" - "minimum security update period" - "vulnerability disclosure information" - "OPSS enforcement" - "consumer IoT security" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Act Compliance Hub: Scope, Security Requirements, Statements, and OPSS Readiness Grounded UK PSTI hub covering relevant connectable product scope, the three mandatory security requirements, manufacturer importer distributor duties. ![UK PSTI Act compliance hub preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-uk-psti-timeline-small.jpg?v=cheatsheets%2Fprod) *PSTI* *Compliance Hub* ## UK PSTI Act Scope, Security, and Supply Chain Duties This hub is built around the live UK PSTI regime for consumer connectable products. It covers relevant connectable product scope, the three mandatory security requirements, manufacturer importer distributor duties, statement of compliance design, current deemed-compliance routes, supply-chain coordination, and OPSS enforcement exposure. Use the root timeline and decision flow first. Then use the subpages to implement the real legal sequence: the Act received Royal Assent on 6 December 2022, the security requirements regulations were made on 14 September 2023, Part 1 plus the regulations came into force on 29 April 2024, the Schedule 3 and support-period amendment came into force on 25 February 2025, and the expanded deemed-compliance routes came into force on 4 December 2025. [Start with applicability test](/artifacts/uk/psti-act/applicability-test.md) ## What you can decide faster - **Product scope**: Determine whether a product is a relevant connectable product and whether any exclusion or boundary issue changes the duty set. - **Role and evidence**: Separate manufacturer, importer, and distributor duties, then decide what statement, summary, label-based deemed-compliance, retention, and investigation records are required. - **Security implementation**: Translate password, vulnerability disclosure, and minimum security update period duties into release gates and support operations. By Sorena AI | Grounded in PSTI legislation, OPSS, and ETSI materials | Updated March 2026 ### Implementation focus *UK PSTI* - **Scope and categories**: Start with section 4 relevant connectable product logic, section 6 excepted products, and role allocation. - **Mandatory controls**: Implement the three mandatory requirements: no universal default passwords, vulnerability disclosure information, and minimum security update period information. - **Statements and enforcement**: Prepare statement-of-compliance materials where required, validate any Schedule 2A route, maintain retention and compliance-failure records, and keep OPSS response capability ready. Use the decision flow first, then move into the role, statement, and control pages for execution. | Value | Metric | | --- | --- | | 6 Dec 2022 | Royal Assent | | 29 Apr 2024 | In force | | 3 duties | Mandatory controls | | 10 years+ | Statement retention if used | **Key highlights:** Scope first | 3 requirements | Statement evidence ## Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/product-security-and-telecommunications-infrastructure-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/product-security-and-telecommunications-infrastructure-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/product-security-and-telecommunications-infrastructure-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/product-security-and-telecommunications-infrastructure-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/product-security-and-telecommunications-infrastructure-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/product-security-and-telecommunications-infrastructure-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/product-security-and-telecommunications-infrastructure-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/product-security-and-telecommunications-infrastructure-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/product-security-and-telecommunications-infrastructure-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/product-security-and-telecommunications-infrastructure-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/product-security-and-telecommunications-infrastructure-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/product-security-and-telecommunications-infrastructure-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/product-security-and-telecommunications-infrastructure-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/product-security-and-telecommunications-infrastructure-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/product-security-and-telecommunications-infrastructure-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. ## Key dates for UK product security implementation *PSTI Timeline* Track PSTI milestones and commencement timing so product, legal, and compliance teams can stage controls and documentation with clear ownership. ## Do UK PSTI duties apply to your product model *PSTI Decision Flow* Follow the flow from product scope and role classification to obligation sets, then execute via detailed implementation and evidence guides. *Next step* ## Turn UK PSTI Act Scope, Security, and Supply Chain Duties into an operational assessment workflow UK PSTI Act Scope, Security, and Supply Chain Duties should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into Research Copilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from UK PSTI Act Scope, Security, and Supply Chain Duties and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for UK PSTI Act Scope, Security, and Supply Chain Duties. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs from the same artifact. - [Talk through UK PSTI Act Scope, Security, and Supply Chain Duties](/contact.md): Review your current process, evidence model, and next steps for UK PSTI Act Scope, Security, and Supply Chain Duties. ## Decision Steps ### STEP 1: Is your product a relevant connectable product (internet-connectable or network-connectable) that is not an excepted product? *Reference: PSTI Act 2022 s. 4 to s. 6* - Relevant connectable product means a product that is internet-connectable or network-connectable, and is not an excepted product (s. 4). - Internet-connectable product means capable of connecting to the internet using a protocol in the Internet Protocol suite (s. 5(1) to s. 5(2)). - Network-connectable product means capable of sending and receiving data and (among other conditions) capable of connecting directly to an internet-connectable product (s. 5(3) to s. 5(5)). - Excepted products are specified by regulations made under s. 6. For the baseline security requirements regime, SI 2023/1007 reg. 6 points to Schedule 3 (excepted products). - The current Schedule 3 list includes Northern Ireland products under relevant legislation, EV smart charge points, medical devices, certain smart meter products, certain computers, and, since 25 February 2025, specified Great Britain motor vehicles, two- or three-wheel vehicles and quadricycles, and agricultural and forestry vehicles. - Source (Act): https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io - Source (SI 2023/1007): https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io - **NO** Out of scope (for these PSTI product security duties) - **YES** Are you a relevant person for the product (manufacturer, importer, or distributor)? ### STEP 2: Are you a relevant person for the product (manufacturer, importer, or distributor)? *Reference: PSTI Act 2022 s. 7* - Relevant persons are manufacturers, importers, and distributors (s. 7(2)). - Manufacturer includes a person who manufactures (or has designed/manufactured) and markets the product under their name or trade mark, or a person who re-brands another manufacturer's product (s. 7(3)). - Importer means imports from outside the UK into the UK and is not a manufacturer (s. 7(4)). - Distributor means makes the product available in the UK and is not the manufacturer or importer (s. 7(5)). - Not a distributor in a specific installer-only scenario described in s. 7(6). - Source: https://www.legislation.gov.uk/ukpga/2022/46/section/7?ref=sorena.io - **NO** Out of scope (for these PSTI product security duties) - **YES** Is the product (or will it be) a UK consumer connectable product for your supply chain? ### STEP 3: Is the product (or will it be) a UK consumer connectable product for your supply chain? *Reference: PSTI Act 2022 s. 8, s. 14, s. 21, and s. 54* - The duties in s. 8 (manufacturers), s. 14 (importers), and s. 21 (distributors) apply if you intend the product to be, or are (or ought to be) aware it will be, a UK consumer connectable product (Condition A) or if it is a UK consumer connectable product and Condition A was met when you made it available (Condition B). - UK consumer connectable product is defined in s. 54 using Condition A and Condition B, including rules about prior supply and certain return/reconditioning scenarios. - Source (duties): https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io - Source (definition): https://www.legislation.gov.uk/ukpga/2022/46/section/54?ref=sorena.io - **NO** Out of scope (for these PSTI product security duties) - **YES** Are you the manufacturer for this product (as defined in s. 7)? ### STEP 4: Are you the manufacturer for this product (as defined in s. 7)? *Reference: PSTI Act 2022 s. 7(3)* - If yes, follow the manufacturer duties (including security requirements and statements of compliance). - If no, check importer duties next. - Source: https://www.legislation.gov.uk/ukpga/2022/46/section/7?ref=sorena.io - **YES** PSTI applies to you as a manufacturer - **NO** Are you the importer (importing from outside the UK into the UK, and not a manufacturer)? ### STEP 5: Are you the importer (importing from outside the UK into the UK, and not a manufacturer)? *Reference: PSTI Act 2022 s. 7(4)* - If yes, follow the importer duties. - If no, check distributor duties next. - Source: https://www.legislation.gov.uk/ukpga/2022/46/section/7?ref=sorena.io - **YES** PSTI applies to you as an importer - **NO** Are you the distributor (making the product available in the UK, and not the manufacturer or importer)? ### STEP 6: Are you the distributor (making the product available in the UK, and not the manufacturer or importer)? *Reference: PSTI Act 2022 s. 7(5) to s. 7(6)* - Distributor means making the product available in the UK, where you are not the manufacturer or importer (s. 7(5)). - Section 7(6) describes a scenario where a person is not treated as a distributor (installer-only scenario). - Source: https://www.legislation.gov.uk/ukpga/2022/46/section/7?ref=sorena.io - **YES** PSTI applies to you as a distributor - **NO** Out of scope (for these PSTI product security duties) ## Reference Information ### Where to find the baseline security requirements - The Act sets the framework and duties; the specific security requirements are set in regulations. - For the consumer product baseline regime, SI 2023/1007 reg. 3 points to Schedule 1 (security requirements for manufacturers). - SI 2023/1007 reg. 4 and Schedule 2 set deemed-compliance conditions for the three security requirements. These include ETSI EN 303 645 and ISO/IEC 29147 routes, and since 4 December 2025 also JC-STAR STAR-1 and Singapore Cybersecurity Labelling Scheme label routes. - SI 2023/1007 reg. 4A and Schedule 2A set deemed compliance with the section 9 statement-accompaniment requirement for current JC-STAR STAR-1 or Singapore Cybersecurity Labelling Scheme labelled products. - For excepted products, SI 2023/1007 reg. 6 points to Schedule 3, including the 2025 Great Britain vehicle additions. - For statements of compliance, SI 2023/1007 reg. 7 points to Schedule 4 (minimum information required for statements). - Source: https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io ### Statement retention (SI 2023/1007) - Manufacturers: where a statement is required under s. 9(2), retain a copy for the longer of 10 years from issuance or the defined support period (reg. 8). - Importers: where a statement is required under s. 15(2), retain a copy for the longer of 10 years from issuance or the defined support period (reg. 9). - Source: https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io ### Enforcement and penalties (PSTI Act Part 1) - Failure to comply with an enforcement notice is an offence (s. 32). - Monetary penalties: the Secretary of State may issue a penalty notice for a relevant breach, with a fixed penalty and (optionally) a daily penalty not exceeding £20,000 per day while the breach continues (s. 36). - The fixed penalty for a single relevant breach may not exceed the relevant maximum: the greater of £10 million and 4% of qualifying worldwide revenue (s. 38). - Appeals: enforcement notices and penalty notices can be appealed to the First-tier Tribunal (s. 33 and s. 41). - Source (Act): https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io ## Possible Outcomes ### [RESULT] PSTI applies to you as a manufacturer Meet security requirements and use the statement route unless a current deemed-compliance route applies. - Comply with relevant security requirements if Condition A or B is met (s. 8). - For most products, do not make the product available in the UK unless accompanied by a statement of compliance or a permitted summary when s. 9 applies (s. 9(2)). - Since S.I. 2025/1267, reg. 4A and Schedule 2A can treat some products with current JC-STAR STAR-1 or Singapore Cybersecurity Labelling Scheme labels as complying with the section 9 statement-accompaniment requirement. - Statement of compliance is a document in the form and content specified by regulations and states, in the manufacturer's opinion, the applicable security requirements are met (s. 9(3) to s. 9(4)). - Investigate potential compliance failures (s. 10) and take action and notify relevant parties on compliance failures (s. 11). - Maintain records of investigations and compliance failures (s. 12). - Security requirements are specified in regulations under the Act. For the baseline regime, SI 2023/1007 reg. 3 points to Schedule 1, reg. 4 points to Schedule 2, reg. 4A points to Schedule 2A, reg. 6 points to Schedule 3, and reg. 7 points to Schedule 4. - Source (Act): https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io - Source (SI 2023/1007): https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io ### [RESULT] PSTI applies to you as an importer Check the correct UK gateway condition and do not supply when you know or believe there is a compliance failure. - Comply with relevant security requirements if Condition A or B is met (s. 14). - For most products, do not make the product available in the UK unless accompanied by a statement of compliance or permitted summary when s. 15 applies (s. 15(2)). - Where regulations under s. 9(7) deem compliance with section 9, s. 15(5) instead requires the importer to be satisfied that the specified conditions are met; in that case s. 15(2) to s. 15(4) do not apply. - Do not make the product available in the UK if you know or believe there is a compliance failure by the manufacturer (s. 16). - Investigate potential compliance failures (s. 17) and take action and notify relevant parties where required (s. 18 and s. 19). - Maintain records of investigations (s. 20). - SI 2023/1007 reg. 9 sets importer retention of statements of compliance for the longer of 10 years from issuance or the defined support period where a statement is required under s. 15(2). - Source (Act): https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io - Source (SI 2023/1007): https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io ### [RESULT] PSTI applies to you as a distributor Verify the correct UK gateway condition and stop supply when you know or believe there is a compliance failure. - Comply with relevant security requirements if Condition A or B is met (s. 21). - For most products, do not make the product available in the UK unless accompanied by a statement of compliance or permitted summary when s. 22 applies (s. 22(2)). - Where regulations under s. 9(7) deem compliance with section 9, s. 22(3) instead requires the distributor to be satisfied that the specified conditions are met; in that case s. 22(2) does not apply. - Do not make the product available in the UK if you know or believe there is a compliance failure by the manufacturer (s. 23). - Take action and notify relevant parties on distributor compliance failures where required (s. 24). - Source: https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io ### [RESULT] Out of scope (for these PSTI product security duties) Document your reasoning and re-check if your product or supply changes. - You may be out of scope if the product is not a relevant connectable product, is an excepted product, or you are not acting as a manufacturer, importer, or distributor for UK availability. - Source: https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2017-04-03 | OPSS enforcement policy first published | Guidance and Enforcement | | | 2020-06-01 | ETSI TS 103 645 V2.1.2 published (June 2020) | Standards | | | 2020-06-19 | ETSI EN 303 645 V2.1.1 adopted (19 June 2020) | Standards | | | 2021-08-01 | ETSI TS 103 701 V1.1.1 published (August 2021) | Standards | | | 2022-12-06 | PSTI Act receives Royal Assent | Primary Legislation | 2022 c. 46 | | 2023-02-02 | Commencement No. 1 Regulations made (SI 2023/109) | Secondary Legislation | UKSI 2023/109 | | 2023-02-07 | First commencement provisions take effect (7 February 2023) | Secondary Legislation | UKSI 2023/109 reg. 2 | | 2023-04-25 | Commencement No. 2 Regulations made (SI 2023/469) | Secondary Legislation | UKSI 2023/469 | | 2023-04-26 | Additional commencement provisions take effect (26 April 2023) | Secondary Legislation | UKSI 2023/469 | | 2023-09-14 | Security requirements regulations made (SI 2023/1007) | Secondary Legislation | UKSI 2023/1007 | | 2024-04-22 | OPSS enforcement policy revised | Guidance and Enforcement | | | 2024-04-29 | Security requirements regulations come into force | Secondary Legislation | UKSI 2023/1007 reg. 1(2) | | 2024-04-29 | Part 1 of the PSTI Act (product security) comes into force | Secondary Legislation | UKSI 2023/469 reg. 3 | | 2024-09-11 | ETSI EN 303 645 V3.1.3 adopted (11 September 2024) | Standards | | | 2024-10-01 | ETSI TS 103 928 V1.2.1 published (October 2024) | Standards | | | 2025-01-27 | OPSS enforcement policy updated (27 January 2025) | Guidance and Enforcement | | | 2025-02-25 | First 2025 amendment comes into force (25 February 2025) | Secondary Legislation | UKSI 2025/211 | | 2025-12-04 | Amendment No. 2 comes into force (4 December 2025) | Secondary Legislation | UKSI 2025/1267 | | 2026-01-26 | OPSS enforcement policy last updated (26 January 2026) | Guidance and Enforcement | | | 2029-04-28 | First review report due (within 5 years of coming into force) | Review and Reporting | UKSI 2023/1007 reg. 10(2) | **Event details:** - **2017-04-03 - OPSS enforcement policy first published**: Office for Product Safety and Standards (OPSS) enforcement policy first published (general enforcement approach referenced in PSTI grounding sources). - **2020-06-01 - ETSI TS 103 645 V2.1.2 published (June 2020)**: ETSI TS 103 645 V2.1.2 (Baseline Requirements for consumer IoT) is published with a cover version date of 2020-06. - **2020-06-19 - ETSI EN 303 645 V2.1.1 adopted (19 June 2020)**: ETSI EN 303 645 V2.1.1 adoption date (19 June 2020). This standard version is referenced in the PSTI security requirements regulations definition of "ETSI EN 303 645". - **2021-08-01 - ETSI TS 103 701 V1.1.1 published (August 2021)**: ETSI TS 103 701 V1.1.1 (Conformance Assessment of Baseline Requirements) is published with a cover version date of 2021-08. - **2022-12-06 - PSTI Act receives Royal Assent**: Product Security and Telecommunications Infrastructure Act 2022 is enacted, creating the framework for UK consumer connectable product security requirements and statements of compliance. - **2023-02-02 - Commencement No. 1 Regulations made (SI 2023/109)**: The Product Security and Telecommunications Infrastructure Act 2022 (Commencement No. 1) Regulations 2023 are made. - **2023-02-07 - First commencement provisions take effect (7 February 2023)**: Commencement No. 1 Regulations bring specified PSTI Act provisions into force on 7 February 2023. - **2023-04-25 - Commencement No. 2 Regulations made (SI 2023/469)**: The Product Security and Telecommunications Infrastructure Act 2022 (Commencement No. 2) Regulations 2023 are made. - **2023-04-26 - Additional commencement provisions take effect (26 April 2023)**: Commencement No. 2 Regulations bring specified PSTI Act provisions into force, including an effective date of 26 April 2023 for section 66 (as described in the commencement order metadata). - **2023-09-14 - Security requirements regulations made (SI 2023/1007)**: Secondary legislation sets out baseline security requirements (passwords, vulnerability reporting information, and minimum security update period information) and required statement of compliance information. - **2024-04-22 - OPSS enforcement policy revised**: OPSS enforcement policy revision published (general enforcement approach referenced in PSTI grounding sources). - **2024-04-29 - Security requirements regulations come into force**: Security requirements and related statement of compliance requirements take effect for relevant connectable products made available in the UK. - **2024-04-29 - Part 1 of the PSTI Act (product security) comes into force**: Commencement No. 2 Regulations bring Part 1 of the Product Security and Telecommunications Infrastructure Act 2022 into force on 29 April 2024 (so far as not already in force). - **2024-09-11 - ETSI EN 303 645 V3.1.3 adopted (11 September 2024)**: ETSI EN 303 645 V3.1.3 adoption date (11 September 2024). - **2024-10-01 - ETSI TS 103 928 V1.2.1 published (October 2024)**: ETSI TS 103 928 V1.2.1 (home gateways conformance assessment) is published with a cover version date of 2024-10. - **2025-01-27 - OPSS enforcement policy updated (27 January 2025)**: OPSS enforcement policy updated on 27 January 2025 (references to additional legislation added). - **2025-02-25 - First 2025 amendment comes into force (25 February 2025)**: S.I. 2025/211 corrects the support-period wording in Schedule 1 paragraph 3(3) and expands Schedule 3 with Great Britain exceptions for certain motor vehicles, two- or three-wheel vehicles and quadricycles, and agricultural and forestry vehicles. - **2025-12-04 - Amendment No. 2 comes into force (4 December 2025)**: S.I. 2025/1267, made on 3 December 2025 and in force on 4 December 2025, adds Japan JC-STAR STAR-1 and Singapore Cybersecurity Labelling Scheme routes for deemed compliance with the Schedule 1 security requirements and inserts Schedule 2A for deemed compliance with the section 9 statement-accompaniment requirement. - **2026-01-26 - OPSS enforcement policy last updated (26 January 2026)**: OPSS enforcement policy last updated on 26 January 2026 (references to legislation updated). - **2029-04-28 - First review report due (within 5 years of coming into force)**: The Secretary of State must publish the first review report by 28 April 2029 because regulation 10 requires publication before the end of the period of five years beginning with 29 April 2024. Subsequent reports are required at intervals not exceeding five years. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/product-security-and-telecommunications-infrastructure-act --- --- title: "CPRA Timeline and Decision Flow" canonical_url: "https://www.sorena.io/artifacts/us-cpra" source_url: "https://www.sorena.io/artifacts/us/california-privacy-rights-act" author: "Sorena AI" description: "CPRA compliance hub for sensitive personal information, correction rights, service provider and contractor rules, risk assessments, cybersecurity audits." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "CPRA compliance" - "California Privacy Rights Act" - "CPRA requirements" - "CPRA checklist" - "sensitive personal information" - "CPRA risk assessments" - "cybersecurity audits" - "CPPA regulations" - "CPRA contracts" - "CPRA" - "California privacy" - "CPPA" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Timeline and Decision Flow CPRA compliance hub for sensitive personal information, correction rights, service provider and contractor rules, risk assessments, cybersecurity audits. ![US CPRA compliance artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-us-cpra-timeline-small.jpg?v=cheatsheets%2Fprod) *CPRA* *Free Resource* ## California Privacy Rights Act Timeline and Decision Flow Convert CPRA duties into an operating model for correction rights, SPI controls, service provider and contractor governance, and the California rules effective January 1, 2026. Grounded in the current California statute, CPPA regulations, and CPPA rulemaking updates. This is implementation guidance, not legal advice. [Get a CPRA readiness review](/contact.md) ## What teams can decide faster - **What CPRA changed**: Map correction, sharing, SPI limitation, and contractor rules into policy and system updates. - **How to handle SPI**: Classify SPI, decide if the right to limit applies, and propagate limitation instructions. - **How to prepare for 2026 rules**: Track risk assessment, cybersecurity audit, ADMT, and data broker obligations where applicable. By Sorena AI | Updated 2026 | No signup required ### Quick scan *CPRA* - **Scope**: Validate threshold and role applicability with evidence. - **Operations**: Run rights workflows, disclosures, and opt-out signal handling. - **Assurance**: Manage risk assessment, cybersecurity audit, and enforcement readiness. Use linked subpages to implement each CPRA workstream with technical and governance depth. | Value | Metric | | --- | --- | | CPPA | Regulator | | SPI | Control focus | | GPC | Signal support | | DROP | Broker context | **Key highlights:** SPI-ready | Rights-ready | Audit-ready ## Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/california-privacy-rights-act/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/california-privacy-rights-act/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/california-privacy-rights-act/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/california-privacy-rights-act/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/california-privacy-rights-act/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/california-privacy-rights-act/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/california-privacy-rights-act/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/california-privacy-rights-act/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/california-privacy-rights-act/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/california-privacy-rights-act/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/california-privacy-rights-act/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/california-privacy-rights-act/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/california-privacy-rights-act/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/california-privacy-rights-act/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/california-privacy-rights-act/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/california-privacy-rights-act/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. ## Key milestones for California privacy operations *CPRA Timeline* Track statutory, regulatory, and enforcement developments that influence CPRA implementation sequencing and risk posture. ## How to operationalize CPRA obligations *CPRA Decision Flow* Use the decision flow to sequence scope decisions, rights workflows, SPI controls, contract updates, and risk-governance activities. *Next step* ## Turn California Privacy Rights Act Timeline and Decision Flow into a cited research workflow California Privacy Rights Act Timeline and Decision Flow should be the shared entry point for your team. Route execution into Research Copilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from California Privacy Rights Act Timeline and Decision Flow and route the work by entity, product, team, or control owner. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs for California Privacy Rights Act Timeline and Decision Flow. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through California Privacy Rights Act Timeline and Decision Flow](/contact.md): Review your current process, evidence model, and next steps for California Privacy Rights Act Timeline and Decision Flow. ## Decision Steps ### STEP 1: Does your organization meet the CPRA definition of a covered business? *Reference: Civil Code 1798.140(d)* - The CPRA applies to for-profit businesses that collect (or have others collect) consumers' personal information, determine the purposes and means of processing, do business in California, and satisfy one or more thresholds: - 1. Annual gross revenues in excess of $25,000,000 in the preceding calendar year, as adjusted pursuant to Civil Code 1798.199.95(d). - 2. Alone or in combination, annually buy, sell, or share the personal information of 100,000 or more consumers or households. - 3. Derive 50 percent or more of annual revenues from selling or sharing consumers' personal information. - **NO** Not Subject to CPRA - **YES** Identify your role under California privacy law ### STEP 2: Identify your role under California privacy law - Some organizations have additional obligations based on their role, such as data broker registration, or service provider and contractor restrictions. - This decision map covers data broker, service provider or contractor, and standard covered business tracks. - -> Are you a data broker? ### STEP 3: Are you a data broker? *Reference: Civil Code 1798.99.80* - A data broker is a business that knowingly collects and sells to third parties the personal information of a consumer with whom the business does not have a direct relationship. - Data brokers must register annually with CPPA (statutory deadline is January 31). - The Delete Act requires an accessible deletion mechanism. CalPrivacy's consumer-facing portal is DROP (Delete Request and Opt-out Platform). - Requirements for data brokers to access the accessible deletion mechanism and comply with deletion and processing obligations commence on August 1, 2026. - **YES** Data Broker - **NO** Are you a service provider or contractor for a covered business? ### STEP 4: Are you a service provider or contractor for a covered business? *Reference: Civil Code 1798.140(ag), (j)* - Service provider: a person that processes personal information on behalf of a business for a business purpose pursuant to a written contract, subject to statutory restrictions (including prohibitions on selling or sharing and on retaining, using, or disclosing outside the contract). - Contractor: a person to whom the business makes personal information available for a business purpose pursuant to a written contract that includes similar restrictions and a certification of compliance. - If you are not a service provider or contractor, you may be a third party that receives personal information and is subject to separate requirements. - **YES** Service Provider or Contractor - **NO** Covered business: establish your compliance posture ### IN SCOPE: Covered business: establish your compliance posture *Reference: Civil Code Title 1.81.5 and CPPA regulations* - Implement consumer rights (know, delete, correct, opt out of sale and sharing, limit sensitive personal information, non-discrimination). - Provide required disclosures (privacy policy, notice at collection, required links). - Implement data minimization and purpose limitation requirements. - Conduct risk assessments and cybersecurity audits if required by CPPA regulations. - Implement ADMT requirements if you use ADMT for significant decisions. - Provide training and keep records as required by the regulations. - -> Does your processing trigger risk assessment or cybersecurity audit obligations? ### STEP 5: Does your processing trigger risk assessment or cybersecurity audit obligations? *Reference: Regs 7120 and 7150* - CPPA regulations include enhanced obligations for certain processing activities. - Cybersecurity audits apply when your processing presents significant risk to consumers' security (see Reg. 7120). - Risk assessments apply when your processing presents significant risk to consumers' privacy (see Reg. 7150). - **NO** Do you use ADMT for significant decisions? - **YES** Cybersecurity audit check ### STEP 6: Cybersecurity audit check *Reference: Regs 7120 to 7122* - A covered business must complete a cybersecurity audit if its processing presents significant risk to consumers' security. - Under Reg. 7120(b), significant risk to security applies if either: - 1. The business meets the threshold in Civil Code 1798.140(d)(1)(C) in the preceding calendar year; OR - 2. The business meets the revenue threshold in Civil Code 1798.140(d)(1)(A), and in the preceding calendar year processed personal information of 250,000+ consumers or households OR processed sensitive personal information of 50,000+ consumers. - Cybersecurity audits must be performed by a qualified, objective, independent professional using procedures and standards accepted in the auditing profession (see Reg. 7122). - -> Risk assessment check ### STEP 7: Risk assessment check *Reference: Regs 7150 to 7157* - A covered business must conduct a risk assessment before initiating any processing activity identified in Reg. 7150(b). - Reg. 7150(b) lists these processing activities as presenting significant risk to consumers' privacy: - 1. Selling or sharing personal information. - 2. Processing sensitive personal information (subject to a limited employee and independent contractor compensation and benefits exception). - 3. Using ADMT for a significant decision concerning a consumer. - 4. Using automated processing to infer or extrapolate certain attributes based upon systematic observation in education, employment, or independent contractor contexts. - 5. Using automated processing to infer or extrapolate certain attributes based upon a consumer's presence in a sensitive location. - 6. Processing personal information intended to train ADMT for significant decisions, or to train facial-recognition, emotion-recognition, or other identity verification or physical or biological identification or profiling technology. - Risk assessments must be reviewed and updated at least once every three years, and updated sooner when there is a material change (see Reg. 7155). - -> Enhanced Compliance Track ### STEP 8: Do you use ADMT for significant decisions? *Reference: Regs 7001 and 7200* - ADMT (automated decisionmaking technology) means any technology that processes personal information and uses computation to replace or substantially replace human decisionmaking. - A significant decision includes decisions that result in the provision or denial of financial or lending services, housing, education enrollment or opportunities, employment or independent contracting opportunities or compensation, or healthcare services. - If you used ADMT for a significant decision prior to January 1, 2027, you must be in compliance with the ADMT requirements no later than January 1, 2027. - **YES** ADMT Compliance Required - **NO** Do you sell or share personal information of consumers under 16? ### STEP 9: Do you sell or share personal information of consumers under 16? *Reference: Civil Code 1798.120(c) and Regs 7070 to 7072* - A covered business must not sell or share the personal information of a consumer if the business has actual knowledge the consumer is less than 16 years of age unless the consumer (13-15) or the consumer's parent or guardian (under 13) affirmatively authorizes the sale or sharing. - Special rules apply for consumers under 13 and for consumers at least 13 and less than 16, including requirements for opt-in processes and related notices. - **YES** Children's Privacy Requirements - **NO** Do you collect large amounts of personal information (10,000,000+ consumers)? ### STEP 10: Do you collect large amounts of personal information (10,000,000+ consumers)? *Reference: Reg. 7102* - Reg. 7102 applies if a business knows or reasonably should know that it, alone or in combination, buys, receives, sells, shares, or otherwise makes available personal information of 10,000,000 or more consumers in a calendar year. - If this threshold applies, the business must compile and disclose specified metrics on consumer requests. - **YES** Large-Scale Metrics Disclosure - **NO** Standard Compliance Track ## Reference Information ### Business Threshold Notes - Revenue threshold: $25,000,000 in the preceding calendar year, as adjusted pursuant to Civil Code 1798.199.95(d). - Consumer and household threshold: 100,000 consumers or households (as stated in Civil Code 1798.140(d)(1)(B)). - Entities can also be treated as a covered business if they are controlled by or control a covered business and share common branding, if they are part of a qualifying joint venture or partnership (40 percent+ interest), or if they voluntarily certify to CPPA that they are in compliance and agree to be bound. ### Consumer Rights (CCPA as amended by CPRA) - Right to know and access personal information (including categories and specific pieces) and related disclosures. - Right to delete personal information collected from the consumer (subject to exceptions). - Right to correct inaccurate personal information. - Right to opt out of sale and sharing of personal information. - Right to limit the use and disclosure of sensitive personal information. - Right to non-discrimination for exercising CCPA rights. - For certain uses of ADMT involving significant decisions, CPPA regulations include rights to opt out of ADMT and to access and appeal ADMT. ### Sensitive Personal Information (examples) - Social security, driver's license, state identification card, or passport number. - Account log-in, financial account, debit card, or credit card number in combination with required security or access code, password, or credentials allowing access to an account. - Precise geolocation. - Racial or ethnic origin, citizenship or immigration status, religious or philosophical beliefs, or union membership. - Contents of mail, email, and text messages (unless the business is the intended recipient of the communication). - Genetic data and neural data. - Biometric information processed for the purpose of uniquely identifying a consumer. - Personal information collected and analyzed concerning health, sex life, or sexual orientation. - In the CPPA regulations definitions, sensitive personal information also includes personal information of consumers that the business has actual knowledge are less than 16 years of age. ### Required Disclosures to Consumers - Privacy policy requirements are addressed in Article 2 (including Reg. 7011). - Notice at collection must be provided at or before collection and include required information such as categories, purposes, sale and sharing disclosures, and retention period disclosures (Reg. 7012 and Civil Code 1798.100). - If you sell or share personal information, provide a Notice of Right to Opt-out of Sale/Sharing and a 'Do Not Sell or Share My Personal Information' link, or use permitted alternatives (Regs 7013 and 7015). - If you use or disclose sensitive personal information for purposes other than those authorized by law and regulations, provide a Notice of Right to Limit and a 'Limit the Use of My Sensitive Personal Information' link, or use permitted alternatives (Regs 7014 and 7015). - If you offer financial incentives or price or service differences, provide a Notice of Financial Incentive (Reg. 7016). ### Response Timelines for Consumer Requests - Confirmation: confirm receipt within 10 business days for requests covered by Reg. 7021. - Delete, correct, know, access ADMT, and appeal ADMT: respond within 45 calendar days; may extend up to 90 calendar days total with required notice (Reg. 7021). - Opt out of sale and sharing: cease selling or sharing as soon as feasibly possible, but no later than 15 business days (Reg. 7026). - Limit sensitive personal information: cease non-authorized uses and disclosures as soon as feasibly possible, but no later than 15 business days (Reg. 7027). - Opt out preference signals: must be processed as valid opt-out requests when the requirements are met (Reg. 7025). ### Verification of Consumer Requests - A business must establish a reasonable method to verify requestors for requests that require verification (Reg. 7060(a)). - A business must not require identity verification to make a request to opt out of sale and sharing, to make a request to limit, or to make a request to opt out of ADMT (Reg. 7060(b)). - For verification, first match information provided by the consumer to personal information already maintained, and avoid collecting certain highly sensitive identifiers unless necessary (Reg. 7060(c)). - A business must not charge a fee for verification (Reg. 7060(e)). - Non-accountholder standards vary by request type (e.g., reasonable degree of certainty vs reasonably high degree of certainty and declaration under penalty of perjury) (Reg. 7062). ### CPPA Enforcement Authority (high level) - CPPA administers, implements, and enforces the law through administrative actions (Civil Code 1798.199.40). - CPPA may investigate possible violations on a sworn complaint or on its own initiative, and may decide to provide a time period to cure depending on the circumstances (Civil Code 1798.199.45). - CPPA administrative fines can be up to $2,500 per violation, or up to $7,500 per intentional violation and each violation involving the personal information of minor consumers (Civil Code 1798.199.55). - CPPA regulations include complaint and enforcement procedures, stipulated orders, and audits (for example, Regs 7300 to 7304). ### Data Minimization and Purpose Limitation - Collection, use, retention, and sharing must be reasonably necessary and proportionate to achieve disclosed purposes (Reg. 7002). - Purposes must align with consumer reasonable expectations based on factors listed in Reg. 7002(b). - A business must avoid requesting additional information beyond what is necessary for verification and must delete new verification information as soon as practical (Reg. 7060(d)). - Additional purposes must be compatible with the context in which personal information was collected (Reg. 7002(c)). - Consent may be required for processing that does not meet the reasonably necessary and proportionate standard (Reg. 7002(e)). ### Sharing and Cross-Context Behavioral Advertising - Sharing means disclosing personal information to a third party for cross-context behavioral advertising, whether or not for monetary or other valuable consideration (Civil Code 1798.140(ah)). - Cross-context behavioral advertising means targeting advertising based on the consumer's personal information obtained from activity across businesses or distinctly branded websites, applications, or services other than the one the consumer intentionally interacts with (Civil Code 1798.140(k)). - Consumers have a right to opt out of sharing, similar to the right to opt out of sale (Civil Code 1798.120). ### Service Provider, Contractor, and Third Party Distinctions - Service provider: processes personal information on behalf of a business for a business purpose under a written contract and is subject to statutory restrictions (Civil Code 1798.140(ag)). - Contractor: receives personal information made available by a business for a business purpose under a written contract with restrictions and a certification of compliance (Civil Code 1798.140(j)). - Third party: a person that is not the business the consumer interacts with, and not a service provider or contractor (Civil Code 1798.140(ai)). - CPPA regulations include additional operational requirements for service providers, contractors, and third parties (Regs 7050 to 7053). ### Non-Discrimination and Financial Incentives - Businesses must not discriminate against consumers for exercising CCPA rights (Civil Code 1798.125). - Financial incentives and price or service differences are permitted only under specific conditions and require a Notice of Financial Incentive (Reg. 7016 and Article 7). - CPPA Enforcement Advisory 2024-02 provides guidance on avoiding dark patterns and obtaining valid consent. ### Training and Record-Keeping - Provide training on CCPA requirements to individuals responsible for handling consumer inquiries, requests, or complaints (Reg. 7100). - Maintain records of consumer requests and how you responded for at least 24 months and implement reasonable security for those records (Reg. 7101). - If Reg. 7102 applies (10,000,000+ consumers), compile and disclose request metrics (Reg. 7102). ### Opt-out Preference Signals and Global Privacy Control (GPC) - If you sell or share personal information, you must process qualifying opt-out preference signals as valid requests to opt out of sale and sharing (Reg. 7025). - An opt-out preference signal is sent by a platform, technology, or mechanism on behalf of the consumer and is intended to have the effect of opting the consumer out of sale and sharing (Reg. 7025(b)). - Global Privacy Control (GPC) is one example of a browser-based opt-out preference signal recognized by California privacy enforcement/regulatory guidance. ### Delete Act and DROP Platform - The Delete Act requires an accessible deletion mechanism for data brokers and includes annual data broker registration requirements. - DROP (Delete Request and Opt-out Platform) is the consumer portal described by CalPrivacy for submitting requests to data brokers. - Data brokers begin processing DROP requests on August 1, 2026 and are described as deleting data every 45 days moving forward. ### Penalties and Private Right of Action (overview) - CPPA administrative fines can be up to $2,500 per violation, or up to $7,500 per intentional violation and each violation involving the personal information of minor consumers (Civil Code 1798.199.55). - Civil Code 1798.150 provides a private right of action for certain data breach incidents (including a notice-and-cure process for statutory damages claims). - Most other violations are enforced by CPPA and the Attorney General, rather than by private lawsuits for statutory damages. ## Possible Outcomes ### [RESULT] Not Subject to CPRA Business definition or thresholds not met - Your organization does not meet the definition of a covered business or does not meet any CPRA thresholds. - Even if not directly subject, you may be impacted as a service provider, contractor, or third party receiving personal information from CPRA-covered businesses. ### [RESULT] Data Broker Registration and Delete Act obligations apply - Register with CPPA by the statutory deadline (January 31) for each year you meet the definition of a data broker; pay the registration fee and submit required registration information. - Comply with the accessible deletion mechanism requirements, including processing DROP requests beginning August 1, 2026 and deleting data on an ongoing cycle (every 45 days) as described by CalPrivacy. - Be prepared for administrative enforcement, including administrative fines and costs for failure to register or failure to comply with accessible deletion mechanism requirements. ### [RESULT] Service Provider or Contractor Contractual restrictions and assistance obligations - Ensure written contracts include the required restrictions for service providers and contractors and any required certifications. - Do not sell or share personal information received from the business under the contract. - Do not retain, use, or disclose personal information outside the direct business relationship or beyond the contract's business purposes, except as otherwise permitted. - Cooperate with covered businesses when they respond to consumer requests (for example, deletion requests) as required by the regulations. - Notify the business if you determine you can no longer meet your obligations under the CCPA and CPPA regulations. ### [RESULT] Standard Compliance Track Core requirements (no additional high-risk triggers identified here) - Implement consumer rights and required business practices for handling requests (including opt-out preference signals). - Provide required disclosures and links (privacy policy, notice at collection, opt-out and limit links when applicable). - Implement data minimization and purpose limitation requirements (Reg. 7002). - Establish verification procedures for requests that require verification, and do not impose verification where it is prohibited (Reg. 7060). - Provide required training (Reg. 7100) and maintain request records for at least 24 months (Reg. 7101). - Use proper contracts and restrictions for service providers, contractors, and third parties (Regs 7050 to 7053). ### [RESULT] Enhanced Compliance Track Risk assessments and/or cybersecurity audits may be required - Complete all standard compliance track requirements. - Conduct and document risk assessments before initiating Reg. 7150(b) processing activities, review and update risk assessments at least once every three years, and update sooner when there is a material change (Reg. 7155). - Follow the risk assessment submission requirements and deadlines (Reg. 7157). - If Reg. 7120 applies, complete cybersecurity audits and comply with audit timing and independence requirements (Regs 7120 to 7122). - Risk assessments can be consolidated for comparable processing activities and can leverage substantially similar assessments prepared for other laws if they contain the required elements (Reg. 7156). ### [RESULT] ADMT Compliance Required Automated decisionmaking technology requirements for significant decisions - Provide a Pre-use Notice for ADMT uses covered by Reg. 7200 (Reg. 7220). - Provide a consumer opt-out of ADMT (subject to exceptions) and provide appeals where required by the regulations (Reg. 7221). - Respond to requests to access ADMT with the information required by the regulations (Reg. 7222). - If you process personal information to train ADMT, consider additional obligations for training-related risk assessments (Reg. 7153). ### [RESULT] Children's Privacy Requirements Opt-in requirements for sale or sharing under 16 - Under 13: establish, document, and comply with a reasonable method to determine that the person consenting to sale or sharing is the parent or guardian (Reg. 7070). - Ages 13 to 15: establish a reasonable process for allowing consumers to opt in to sale or sharing (Reg. 7071). - Include required descriptions of these processes in your privacy policy (Reg. 7072). - Consider related requirements under COPPA where applicable. ### [RESULT] Large-Scale Metrics Disclosure Reg. 7102 public metrics and reporting - Compile metrics for the previous calendar year, including counts of requests received, complied with (in whole or in part), and denied for: delete, correct, know, access ADMT, opt out of sale and sharing, limit, and opt out of ADMT (Reg. 7102(a)(1)). - Calculate and disclose a median or mean response time for specified request types (Reg. 7102(a)(1)(H)). - Disclose the compiled information by July 1 of every calendar year within your privacy policy or via a link accessible from the privacy policy (Reg. 7102(a)(2)). ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2019-01-01 | CCPA statutory title takes effect | Legislation | | | 2020-01-01 | CCPA becomes operative | Legislation | | | 2020-01-16 | NIST Privacy Framework 1.0 published | Technical Standards | | | 2020-07-01 | Attorney General regulation deadline | Legislation | | | 2020-11-03 | Proposition 24 (CPRA) approved | Legislation | | | 2021-09-22 | Invitation for preliminary rulemaking comments begins | Regulations | | | 2021-11-08 | Preliminary comment period closes | Regulations | | | 2022-03-29 | Informational sessions begin | Regulations | | | 2022-05-04 | Stakeholder sessions begin | Regulations | | | 2022-07-08 | Formal CPPA rulemaking commences | Regulations | | | 2022-08-24 | Oral comments transcript referenced | Regulations | | | 2022-08-24 | Sephora settlement press release | Enforcement | | | 2022-11-03 | Proposed modifications notice posted | Regulations | | | 2022-12-31 | Employee and B2B exemptions expire | Consumer Rights | | | 2023-01-01 | CPRA amendments become operative | Legislation | | | 2023-03-29 | OAL approves CPPA regulations; effective date | Regulations | | | 2023-07-01 | CPRA enforcement may begin | Enforcement | | | 2023-09-14 | Google settlement press release | Enforcement | | | 2023-10-10 | Delete Act (SB 362) signed | Data Brokers and Delete Act | | | 2023-12-01 | Draft cybersecurity audit regulations dated | Regulations | | | 2024-01-01 | CPPA takes over Data Broker Registry | Data Brokers and Delete Act | | | 2024-03-01 | Draft risk assessment regulations dated | Regulations | | | 2024-04-02 | CPPA Enforcement Advisory 2024-01 issued | Enforcement | | | 2024-06-19 | Tilting Point settlement press release | Enforcement | | | 2024-07-05 | Data broker registration rulemaking notice | Data Brokers and Delete Act | | | 2024-09-04 | CPPA Enforcement Advisory 2024-02 issued | Enforcement | | | 2024-11-22 | Cyber, risk, and ADMT rulemaking notice | Regulations | | | 2024-12-26 | Data Broker Registration Regulations effective | Data Brokers and Delete Act | | | 2025-02-19 | Public comment hearing held | Regulations | | | 2025-05-09 | Notice of modifications published | Regulations | | | 2025-07-01 | Healthline settlement press release | Enforcement | | | 2025-07-24 | CPPA Board adopts cyber, risk, and ADMT regulations | Regulations | | | 2025-09-22 | OAL approves cyber, risk, and ADMT regulations | Regulations | | | 2025-11-21 | Jam City settlement press release | Enforcement | | | 2025-12-01 | Delete Act statutory text posted | Data Brokers and Delete Act | | | 2025-12-17 | CPPA Enforcement Advisory 2025-01 issued | Enforcement | | | 2026-01-01 | Cyber, risk, and ADMT regulations effective | Regulations | | | 2026-01-01 | DROP launches | Data Brokers and Delete Act | | | 2026-01-31 | Data broker registration deadline | Data Brokers and Delete Act | | | 2026-02-11 | Disney settlement press release | Enforcement | | | 2026-08-01 | Data brokers begin processing DROP requests | Data Brokers and Delete Act | | | 2026-08-01 | DROP one-time access fee begins | Data Brokers and Delete Act | | | 2026-08-01 | Ongoing 45-day deletion cycle | Data Brokers and Delete Act | | | 2027-12-31 | Risk assessment compliance deadline for existing processing | Regulations | | | 2028-01-01 | Data broker audit requirement begins | Data Brokers and Delete Act | | | 2029-01-01 | Delete Act registry audit disclosure begins | Data Brokers and Delete Act | | **Event details:** - **2019-01-01 - CCPA statutory title takes effect**: California Civil Code Title 1.81.5 (CCPA) became effective (Title 1.81.5 added by AB 375, effective January 1, 2019). - **2020-01-01 - CCPA becomes operative**: The CCPA became operative on January 1, 2020. - **2020-01-16 - NIST Privacy Framework 1.0 published**: NIST publishes Privacy Framework 1.0 (NIST CSWP.01162020). - **2020-07-01 - Attorney General regulation deadline**: By July 1, 2020, the Attorney General was required to solicit public participation and adopt regulations to further the purposes of the CCPA. - **2020-11-03 - Proposition 24 (CPRA) approved**: Proposition 24 amended the CCPA and established the California Privacy Protection Agency (CPPA). - **2021-09-22 - Invitation for preliminary rulemaking comments begins**: CPPA opens a preliminary comment period (Invitation for Comments) for upcoming CPRA implementing regulations. - **2021-11-08 - Preliminary comment period closes**: CPPA preliminary written comment period for the Invitation for Comments closes. - **2022-03-29 - Informational sessions begin**: CPPA holds informational sessions for the public and stakeholders to inform upcoming rulemaking. - **2022-05-04 - Stakeholder sessions begin**: CPPA stakeholder sessions begin for topics relevant to upcoming rulemaking. - **2022-07-08 - Formal CPPA rulemaking commences**: CPPA commences the formal rulemaking process to adopt regulations implementing the CPRA. - **2022-08-24 - Oral comments transcript referenced**: CPPA references an oral comments transcript dated August 24, 2022 as part of the CPRA implementing regulations rulemaking record. - **2022-08-24 - Sephora settlement press release**: California Attorney General press release for the Sephora settlement (as indexed in the DOJ privacy enforcement actions page). - **2022-11-03 - Proposed modifications notice posted**: CPPA posts public notice of proposed modifications and additional materials relied upon for CPRA implementing regulations. - **2022-12-31 - Employee and B2B exemptions expire**: The exemptions for employment-related personal information and B2B personal information expire on December 31, 2022. - **2023-01-01 - CPRA amendments become operative**: CPRA amendments to the CCPA become operative on January 1, 2023. - **2023-03-29 - OAL approves CPPA regulations; effective date**: Office of Administrative Law approves CPPA regulations and files them with the Secretary of State; regulations become effective March 29, 2023. - **2023-07-01 - CPRA enforcement may begin**: Civil and administrative enforcement of CPRA provisions may commence on July 1, 2023 (and applies to violations occurring on or after that date). - **2023-09-14 - Google settlement press release**: California Attorney General press release for the Google settlement (as indexed in the DOJ privacy enforcement actions page). - **2023-10-10 - Delete Act (SB 362) signed**: Governor signs Senate Bill 362 (Delete Act) into law. - **2023-12-01 - Draft cybersecurity audit regulations dated**: Draft cybersecurity audit regulations are dated December 2023. - **2024-01-01 - CPPA takes over Data Broker Registry**: CPPA begins administering the California Data Broker Registry. - **2024-03-01 - Draft risk assessment regulations dated**: Draft risk assessment regulations are dated March 2024. - **2024-04-02 - CPPA Enforcement Advisory 2024-01 issued**: CPPA Enforcement Advisory 2024-01 (Applying Data Minimization to Consumer Requests) is issued. - **2024-06-19 - Tilting Point settlement press release**: California Attorney General press release for the Tilting Point settlement (as indexed in the DOJ privacy enforcement actions page). - **2024-07-05 - Data broker registration rulemaking notice**: CPPA posts a public notice of rulemaking and related documents for Data Broker Registration Regulations. - **2024-09-04 - CPPA Enforcement Advisory 2024-02 issued**: CPPA Enforcement Advisory 2024-02 (Dark Patterns) is issued. - **2024-11-22 - Cyber, risk, and ADMT rulemaking notice**: CPPA posts public notice of rulemaking and related documents for cybersecurity audits, risk assessments, ADMT, and insurance clarifications. - **2024-12-26 - Data Broker Registration Regulations effective**: Data Broker Registration Regulations are approved by OAL, filed with the Secretary of State, and become effective on December 26, 2024. - **2025-02-19 - Public comment hearing held**: CPPA holds a public comment hearing for the proposed cyber, risk assessment, ADMT, and insurance regulations. - **2025-05-09 - Notice of modifications published**: CPPA publishes a public notice of modifications to the proposed cyber, risk assessment, ADMT, and insurance regulations. - **2025-07-01 - Healthline settlement press release**: California Attorney General press release for the Healthline Media LLC settlement (as indexed in the DOJ privacy enforcement actions page). - **2025-07-24 - CPPA Board adopts cyber, risk, and ADMT regulations**: CPPA Board adopts the cyber, risk assessment, ADMT, and insurance regulations. - **2025-09-22 - OAL approves cyber, risk, and ADMT regulations**: OAL approves the regulations and files them with the Secretary of State. - **2025-11-21 - Jam City settlement press release**: California Attorney General press release for the Jam City, Inc. settlement (as indexed in the DOJ privacy enforcement actions page). - **2025-12-01 - Delete Act statutory text posted**: Data Broker Registry and Delete Act statutory text effective January 1, 2026 is posted to cppa.ca.gov in December 2025 (SB 361 update). - **2025-12-17 - CPPA Enforcement Advisory 2025-01 issued**: CPPA Enforcement Advisory 2025-01 (Data Broker Registration) is issued. - **2026-01-01 - Cyber, risk, and ADMT regulations effective**: Cybersecurity audit, risk assessment, and ADMT regulations take effect on January 1, 2026. - **2026-01-01 - DROP launches**: Delete Request and Opt-out Platform (DROP) launches; Californians can start submitting deletion requests. - **2026-01-31 - Data broker registration deadline**: On or before January 31, data brokers must register with CPPA for the year (statutory requirement). - **2026-02-11 - Disney settlement press release**: California Attorney General press release for The Walt Disney Company settlement (as indexed in the DOJ privacy enforcement actions page). - **2026-08-01 - Data brokers begin processing DROP requests**: Data brokers begin processing DROP requests starting August 1, 2026. - **2026-08-01 - DROP one-time access fee begins**: A one-time access fee to integrate with DROP and process deletion requests starts August 1, 2026 (as described on the CalPrivacy data brokers page). - **2026-08-01 - Ongoing 45-day deletion cycle**: Moving forward, data brokers delete data every 45 days (as described on the DROP overview page). - **2027-12-31 - Risk assessment compliance deadline for existing processing**: For certain processing initiated before January 1, 2026 that continues after, businesses must conduct and document a risk assessment no later than December 31, 2027 (per CCPA regulations effective January 1, 2026). - **2028-01-01 - Data broker audit requirement begins**: Starting January 1, 2028 (and every three years after), a data broker must undergo an independent audit to determine compliance with Delete Act deletion requirements (as described on the CalPrivacy data brokers page). - **2029-01-01 - Delete Act registry audit disclosure begins**: Beginning January 1, 2029, Data Broker Registry disclosures include whether a data broker has undergone an audit and the most recent year audit results were submitted to CPPA (per statute text). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/california-privacy-rights-act --- --- title: "Brazil LGPD Compliance Hub: Scope, Rights, Incident Rule, Transfers, and ANPD Enforcement" canonical_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd" source_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd" author: "Sorena AI" description: "Grounded Brazil LGPD compliance hub covering Articles 3, 4, 7, 11, 18, 19, 33, 41, 48, and 52, plus ANPD guidance on roles, legitimate interest." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Brazil LGPD compliance" - "Brazil LGPD requirements" - "ANPD guidance" - "LGPD lawful bases" - "LGPD data subject rights" - "LGPD incident reporting" - "LGPD international transfer" - "LGPD sanctions" - "Brazil LGPD rights" - "Brazil LGPD incident reporting" - "Brazil LGPD transfers" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Brazil LGPD Compliance Hub: Scope, Rights, Incident Rule, Transfers, and ANPD Enforcement Grounded Brazil LGPD compliance hub covering Articles 3, 4, 7, 11, 18, 19, 33, 41, 48, and 52, plus ANPD guidance on roles, legitimate interest. ![Brazil LGPD compliance timeline and decision flow](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-br-lgpd-timeline-small.jpg?v=cheatsheets%2Fprod) *LATAM Brazil LGPD* *Free Resource* ## Brazil LGPD Compliance Hub This Brazil LGPD hub is built around the law itself and the current ANPD guidance set. It covers territorial scope, exclusions, role allocation, lawful basis selection, rights handling, incident reporting, transfer mechanisms, and sanctions risk. Use the root timeline and decision flow first. Then use the subpages to operationalize Articles 18 and 19 rights handling, the 3 business day incident rule under Resolution CD ANPD No. 15 of 24 April 2024, Article 33 to 35 transfer controls, and Article 52 sanctions exposure. [Get an LGPD review](/contact.md) ## What this LGPD hub helps you execute - **Applicability and scope**: Territorial nexus, role classification, and in-scope processing tests. - **Obligations and controls**: Lawful bases, rights operations, incident, transfer, and vendor controls. - **Evidence and assurance**: Audit-ready artifacts for ANPD interactions, governance, and board reporting. By Sorena AI | Grounded in LGPD and ANPD materials | Updated March 2026 ### Compliance focus *LGPD* - **Scope and roles**: Test Article 3 reach, Article 4 exclusions, and controller versus operator allocation before rollout. - **Operational duties**: Run lawful basis, Article 18 and 19 rights, Article 41 DPO, Article 48 incident, and Article 33 transfer workflows. - **Regulator readiness**: Prepare ANPD-ready records for sanctions, transfer safeguards, rights logs, and incident communications. Use the decision flow and timeline first, then open the deep-dive subpages for implementation details. | Value | Metric | | --- | --- | | Law 13.709 | LGPD law | | Art. 18-20 | Rights core | | 3 business days | Incident rule | | 2% / R$50M | Fine cap | **Key highlights:** Article 3 scope | Article 18 rights | Article 33 transfers ## Topic Guides - [ANPD Enforcement and Fines | Brazil LGPD Inspection, Procedure, and Sanctions](/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines.md): Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No. - [Brazil LGPD Applicability Test | Article 3 Scope, Article 4 Exclusions, Roles](/artifacts/latam/brazil-lgpd/applicability-test.md): Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation. - [Brazil LGPD Checklist | Scope, Rights, Incidents, Transfers, Evidence](/artifacts/latam/brazil-lgpd/checklist.md): Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting. - [Brazil LGPD Compliance Program Guide](/artifacts/latam/brazil-lgpd/compliance.md): Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence. - [Brazil LGPD Data Subject Rights | Articles 18 to 20 and 15 Day Access Rule](/artifacts/latam/brazil-lgpd/data-subject-rights.md): Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days. - [Brazil LGPD Deadlines and Compliance Calendar](/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar.md): Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training. - [Brazil LGPD DSAR Response Template | Immediate and 15 Day Response Logic](/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template.md): Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale. - [Brazil LGPD FAQ | Scope, Rights, Incidents, Transfers, Enforcement](/artifacts/latam/brazil-lgpd/faq.md): Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance. - [Brazil LGPD Incident Reporting and Breach Notification](/artifacts/latam/brazil-lgpd/breach-notification.md): Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No. - [Brazil LGPD International Transfers | Articles 33 to 35 and ANPD Transfer Mechanisms](/artifacts/latam/brazil-lgpd/international-transfers.md): Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules. - [Brazil LGPD Lawful Bases | Article 7, Article 11, Legitimate Interest](/artifacts/latam/brazil-lgpd/lawful-bases.md): Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data. - [Brazil LGPD Penalties and Fines | Article 52 and ANPD Dosimetry](/artifacts/latam/brazil-lgpd/penalties-and-fines.md): Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion. - [Brazil LGPD Requirements | Articles, Controls, Evidence, and ANPD Guidance](/artifacts/latam/brazil-lgpd/requirements.md): Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers. - [Brazil LGPD Templates | DSAR, Incident, Basis, Transfer, Governance](/artifacts/latam/brazil-lgpd/templates.md): Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments. - [Brazil LGPD vs CCPA and CPRA | Structure, Rights, Enforcement, and Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa.md): Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls. - [Brazil LGPD vs GDPR | Similarities, Differences, and Control Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr.md): Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting. ## Key milestones for LATAM Brazil LGPD compliance *Brazil LGPD Timeline* Use timeline milestones to schedule policy rollout, rights operations, incident processes, transfer mechanisms, and readiness reviews. ## Determine which LGPD duties apply to your business model *Brazil LGPD Decision Flow* Follow branching logic to classify controller/operator role, lawful basis options, rights obligations, incident duties, and transfer safeguards. *Next step* ## Turn Brazil LGPD Compliance Hub into a cited research workflow Brazil LGPD Compliance Hub should be the shared entry point for your team. Route execution into Research Copilot for live work and into Assessment Autopilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from Brazil LGPD Compliance Hub and route the work by entity, product, team, or control owner. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs for Brazil LGPD Compliance Hub. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints from the same artifact. - [Talk through Brazil LGPD Compliance Hub](/contact.md): Review your current process, evidence model, and next steps for Brazil LGPD Compliance Hub. ## Decision Steps ### STEP 1: Does LGPD apply to your data processing operations? *Reference: Art. 3* - LGPD applies if: (i) processing is carried out in Brazil; OR (ii) processing aims at offering/supplying goods or services or processing data of individuals in Brazil; OR (iii) personal data were collected in Brazil. - Check exclusions in Art. 4 before proceeding. - **NO** Out of Scope - **YES** Does an Article 4 exclusion apply to your processing? ### STEP 2: Does an Article 4 exclusion apply to your processing? *Reference: Art. 4* - If yes, LGPD does not apply to such processing. - If no, continue to determine your processing legal basis. - **YES** Out of Scope - **NO** Are you processing children's or adolescents' personal data? ### STEP 4: Are you processing sensitive personal data? *Reference: Art. 5, II & Art. 11* - Sensitive personal data includes: racial/ethnic origin, religious belief, political opinion, trade union affiliation, data on health/sex life, genetic or biometric data related to a natural person. - If yes: follow Art. 11 requirements for sensitive data processing. - If no: follow Art. 7 requirements for general personal data processing. - **YES** LGPD Applies - Sensitive Personal Data - **NO** LGPD Applies - General Personal Data ### STEP 3: Are you processing children's or adolescents' personal data? *Reference: Art. 14* - Processing of children's personal data requires specific and distinguishable consent from at least one parent or legal representative (Art. 14, para. 1). - Controllers must make public the types of data collected, usage, and procedures for exercising data subject rights (Art. 14, para. 2). - Processing must be in the best interest of the child (Art. 14 head provision). - **YES** LGPD Applies - Children's/Adolescents' Data - **NO** Are you processing sensitive personal data? ### STEP 5: Are you relying on consent as the legal basis? *Reference: Art. 7, I & Art. 8* - Consent must be: freely given, informed, and unambiguous (Art. 5, XII). - Consent must be given in writing or by other means demonstrating manifestation of intention (Art. 8). - Controller bears burden of proving consent was obtained (Art. 8, para. 2). - Consent must refer to specific purposes; generic authorizations are void (Art. 8, para. 4). - Consent can be revoked at any time via free and facilitated procedure (Art. 8, para. 5). - **YES** Consent as Legal Basis - **NO** Are you relying on legitimate interest as the legal basis? ### STEP 6: Are you relying on legitimate interest as the legal basis? *Reference: Art. 7, IX & Art. 10* - Legitimate interest may only be used for legitimate purposes based on particular situations, including: (i) support/promotion of controller's activity; (ii) protection of data subject's regular exercise of rights or provision of services for their benefit (Art. 10). - Only strictly necessary personal data may be processed (Art. 10, para. 1). - Controller must adopt transparency measures (Art. 10, para. 2). - ANPD may request DPIA when processing is based on legitimate interest (Art. 10, para. 3). - **YES** Legitimate Interest as Legal Basis - **NO** Must you appoint a Data Protection Officer (DPO / Encarregado)? ### STEP 7: Must you appoint a Data Protection Officer (DPO / Encarregado)? *Reference: Art. 41* - Controller must appoint a DPO (Art. 41 head provision). - ANPD may establish supplementary rules on definition and duties of DPO, including cases where appointment may be waived according to nature/size of entity or volume of processing (Art. 41, para. 3). - DPO identity and contact data must be publicly, clearly and objectively disclosed, preferably on controller's website (Art. 41, para. 1). - Government authorities must appoint DPO when carrying out personal data processing operations (Art. 23, III). - **YES** DPO Appointment Required - **NO** Must you prepare a Data Protection Impact Assessment (RIPD)? ### STEP 8: Must you prepare a Data Protection Impact Assessment (RIPD)? *Reference: Art. 38* - ANPD may require controller to prepare DPIA (Relatorio de Impacto a Protecao de Dados - RIPD) relating to data processing operations, including sensitive data (Art. 38). - DPIA contains description of processing operations that could pose risks to civil liberties and fundamental rights, and measures/safeguards/mechanisms to mitigate risks (Art. 5, XVII). - Report must contain at least: description of types of data collected, methodology for collection and ensuring information security, analysis of adopted measures/safeguards/risk mitigation mechanisms (Art. 38, sole para.). - ANPD may request DPIA when processing based on legitimate interest (Art. 10, para. 3). - Government authority agents may be requested to publish DPIA reports (Art. 32). - **YES** DPIA May Be Required - **NO** Are you transferring personal data internationally? ### STEP 9: Are you transferring personal data internationally? *Reference: Art. 33* - International transfer of personal data only allowed in Art. 33 cases. - ANPD evaluates level of data protection in foreign country or international organization (Art. 34). - ANPD defines content of standard contractual clauses and verifies specific clauses, binding corporate rules, seals, certificates and codes of conduct (Art. 35). - Amendments to guarantees for international transfer must be communicated to ANPD (Art. 36). - **YES** International Transfer Permitted - **NO** Have you experienced a security incident? ### STEP 10: Have you experienced a security incident? *Reference: Art. 48* - Controller must notify ANPD and data subject of security incident that may result in relevant risk or damage to data subjects (Art. 48). - Communication made as soon as reasonably feasible, as defined by ANPD (Art. 48, para. 1). - Communication must contain: (i) description of nature of affected personal data; (ii) information on data subjects involved; (iii) indication of technical/security measures used; (iv) risks related to incident; (v) reasons for delay if not immediate; (vi) measures adopted or to be adopted to reverse/mitigate effects. - ANPD determines severity of incident and may order measures including full disclosure in media and measures to reverse/mitigate effects (Art. 48, para. 2). - **YES** Security Incident Notification Required - **NO** Are you subject to ANPD enforcement powers? ### STEP 11: Are you subject to ANPD enforcement powers? *Reference: Art. 52* - ANPD has authority to apply administrative sanctions for infractions of LGPD (Art. 52). - Sanctions applied following administrative proceeding providing opportunity for full defense (Art. 52, para. 1). - ANPD defines methodologies for calculation of fine sanctions via public consultation (Art. 53). - Individual data breaches or unauthorized access may be subject of direct conciliation between controller and data subject; if no settlement, controller subject to penalties (Art. 52, para. 7). - **YES** Subject to ANPD Enforcement ## Reference Information ### Territorial Scope (Art. 3) - Processing operation carried out in Brazil (Art. 3, I); - Processing aimed at offering/supplying goods or services, or processing data of individuals located in Brazil (Art. 3, II); - Personal data collected in Brazil - data subject was in Brazil at time of collection (Art. 3, III and para. 1). ### Key Exclusions (Art. 4) - Processing by natural person purely for private and non-economic purposes (Art. 4, I); - Processing exclusively for journalistic and artistic purposes (Art. 4, II(a)); - Processing for academic purposes (subject to Arts. 7 and 11) (Art. 4, II(b)); - Processing exclusively for public security, national defense, State security, or criminal investigation/prosecution (governed by specific legislation) (Art. 4, III); - Processing originating outside Brazil and not subject to communication or shared use with Brazilian processing agents, and not subject to international transfer to a third country other than the country of origin (if the country of origin offers an adequate level of protection) (Art. 4, IV). ### Legal Bases for Processing Personal Data (Art. 7) - I - Consent of the data subject; - II - Compliance with legal/regulatory obligation by controller; - III - Public administration processing for public policies (as per law/regulation or contracts); - IV - Studies by research bodies (with anonymization whenever possible); - V - Performance of contract or preliminary procedures to which data subject is party; - VI - Regular exercise of rights in judicial, administrative or arbitration procedures; - VII - Protection of life or physical integrity of data subject or third party; - VIII - Protection of health in procedures by health professionals/services/authorities; - IX - Legitimate interests of controller or third party (except when data subject's fundamental rights prevail); - X - Protection of credit (as per relevant legislation). ### Legal Bases for Sensitive Personal Data (Art. 11) - I - Specific and emphatic consent for specific purposes; - II - Without consent when indispensable for: (a) compliance with legal/regulatory obligation; (b) shared processing for public policy enforcement; (c) research with anonymization whenever possible; (d) regular exercise of rights in contracts/judicial/administrative/arbitration proceedings; (e) protecting life or physical integrity; (f) health protection in procedures by health professionals/services/authorities; (g) fraud prevention and data subject safety in authentication systems. - Communication/shared use of sensitive health data among controllers for economic advantage is prohibited except for provision of health services, pharmaceutical assistance, health insurance, diagnostic/therapeutic services (Art. 11, para. 4). - Private healthcare plan operators prohibited from processing health data for risk selection or beneficiary inclusion/exclusion (Art. 11, para. 5). ### Controller vs Processor (Operator) - Controller: natural/legal person in charge of making decisions regarding processing of personal data (Art. 5, VI). - Processor (Operator): natural/legal person that processes personal data on behalf of the controller (Art. 5, VII). - Processor carries out processing according to controller's instructions; controller assesses compliance (Art. 39). - Controller and processor are jointly referred to as 'processing agents' (Art. 5, IX). ### DPO Duties (Art. 41, para. 2) - I - Accept complaints and communications from data subjects, provide clarifications and adopt measures; - II - Receive communications from ANPD and adopt measures; - III - Instruct entity's employees and contractors on practices for personal data protection; - IV - Perform other duties determined by controller or established in supplementary rules. ### Data Subject Rights (Art. 18) - I - Confirmation of existence of processing; - II - Access to data; - III - Correction of incomplete, inaccurate or outdated data; - IV - Anonymization, blocking or erasure of unnecessary/excessive data or data processed in non-compliance; - V - Portability of data to another service/product provider (upon express request); - VI - Erasure of personal data processed with consent (except Art. 16 events); - VII - Information on government/private entities with which controller shared data; - VIII - Information on possibility of denying consent and consequences; - IX - Revocation of consent. - Right to petition ANPD against the controller (Art. 18, para. 1). - Right to object to processing carried out on a consent waiver legal basis, in case of non-compliance with LGPD (Art. 18, para. 2). - Rights must be exercised upon express request by data subject or legally appointed representative (Art. 18, para. 3). - Requests must be met free of charge within time periods/terms in regulation (Art. 18, para. 5). - Confirmation/access must be provided: (i) immediately in simplified format; OR (ii) within 15 days via clear and complete statement (Art. 19). ### Automated Decision Review (Art. 20) - Data subject entitled to request review of decisions made solely based on automated processing that affect their interests, including decisions defining personal/professional/consumer/credit profile or personality aspects (Art. 20). - Controller shall provide, upon request, clear and adequate information on criteria and procedures used for automated decision (Art. 20, para. 1). - If information not provided based on trade/industrial secrecy compliance, ANPD may audit to verify discriminatory aspects (Art. 20, para. 2). ### International Transfer Grounds (Art. 33) - I - To countries/organizations providing adequate level of protection; - II - When controller offers and demonstrates guarantees of compliance via: (a) specific contractual clauses; (b) standard contractual clauses; (c) binding corporate rules; (d) regularly issued seals, certificates, codes of conduct; - III - When transfer required for international legal cooperation among intelligence, investigation and prosecution government bodies; - IV - When transfer required to protect life or physical integrity of data subject or third party; - V - When ANPD authorizes the transfer; - VI - When transfer results from commitment in international cooperation agreements; - VII - When transfer required for enforcement of public policy or legal attribution of public service; - VIII - When data subject provided specific and distinguishable consent for transfer, with previous information on international nature of operation; - IX - When required to meet Art. 7, II, V and VI hypotheses (legal obligation, contract performance, exercise of rights). ### Security and Confidentiality (Arts. 46-47, 49) - Processing agents must adopt technical and administrative security measures to protect personal data from unauthorized accesses and accidental/unlawful situations of destruction, loss, alteration, communication, or improper/unlawful processing (Art. 46). - ANPD may provide minimum technical standards, considering nature of processed information, specific characteristics of processing, current state of technology, especially for sensitive personal data (Art. 46, para. 1). - Security measures must be observed from design phase of product/service until implementation (Art. 46, para. 2). - Processing agents or any person involved in processing phases required to ensure information security even after conclusion of processing (Art. 47). - Systems used for personal data processing must be structured to meet security requirements, good practices, governance standards, and general principles (Art. 49). ### Good Practices and Governance (Art. 50) - Controllers and processors may formulate rules for good practices and governance (Art. 50). - Rules may provide for: organization conditions, operational arrangements, procedures (including complaints/requests from data subjects), security rules, technical standards, specific obligations, educational activities, internal supervision/risk mitigation mechanisms (Art. 50). - Controller may implement privacy governance program (Art. 50, para. 2, I) that: (a) demonstrates commitment to internal procedures/policies ensuring compliance; (b) applies to entire set of personal data; (c) is adapted to structure, scale, volume of operations and sensitivity of data; (d) establishes policies/safeguards based on a systematic assessment of impacts and privacy risks; (e) establishes trust relationship via transparent actions ensuring data subject participation; (f) is integrated into general governance structure; (g) has incident response/remediation plans; (h) is constantly updated based on continuous monitoring and periodic assessments. - Controller may demonstrate effectiveness of privacy governance program when appropriate, especially at ANPD request (Art. 50, para. 2, II). - Rules on good practices and governance shall be published, updated periodically, and may be acknowledged and disseminated by ANPD (Art. 50, para. 3). ### Processing by Government Authorities (Art. 23) - Processing by government authorities must be carried out to achieve public purpose, in benefit of public interest, to enforce legal powers or fulfill legal duties of public service (Art. 23). - Government authorities must: (i) inform events in which they process personal data while performing duties, providing clear and updated information on legal basis, purpose, procedures and practices, in easily accessible media (preferably websites) (Art. 23, I); (ii) appoint DPO when carrying out processing operations (Art. 23, III). - Government authorities forbidden to transfer personal data in databases to private entities, except: (a) in cases of decentralized performance of public activity requiring transfer; (b) when data publicly accessible; (c) when there is legal provision or transfer grounded on contracts/agreements; (d) when transfer exclusively intended to prevent fraud/irregularities or protect/safeguard data subject's security/integrity (Art. 26, para. 1). - Contracts and agreements for transfer to private entities must be informed to ANPD (Art. 26, para. 2). - Communication/shared use of personal data from government authority to private entity must be informed to ANPD and rely on data subject consent, except waiver cases in LGPD (Art. 27). - ANPD may request government bodies/entities to provide specific information on scope/nature of data and processing details; may issue supplementary technical report to ensure compliance (Art. 29). ### Termination of Processing and Data Retention (Arts. 15-16) - Processing of personal data ceases: (i) upon evidence purpose achieved or data no longer necessary/pertinent; (ii) upon expiration of processing period; (iii) upon notice from data subject (including consent revocation), subject to public interest; (iv) at order of ANPD upon violation of LGPD (Art. 15). - Personal data shall be erased following termination of processing, within scope and technical limits of activities (Art. 16). - Storage authorized for: (i) compliance with legal/regulatory obligation; (ii) study by research body (with anonymization whenever possible); (iii) transfer to third party, upon compliance with processing requirements; (iv) exclusive use by controller with access by third party prohibited and data anonymized (Art. 16). ### Liability and Damages (Arts. 42-45) - Controller or processor that causes pecuniary, moral, individual or collective damage in violation of data protection legislation shall be required to compensate (Art. 42). - Processor jointly liable for damages when it fails to comply with LGPD obligations or acts contrary to lawful controller instructions (Art. 42, para. 1, I). - Controllers directly involved in processing activities that resulted in damages jointly liable (Art. 42, para. 1, II). - Judge may reverse burden of proof in favor of data subject when allegation appears true, there is hyposufficiency for evidence production, or evidence is overly burdensome (Art. 42, para. 2). - Processing agents not liable only when they prove: (i) they did not carry out processing attributed to them; (ii) although they carried out processing, there was no violation; OR (iii) damage results from exclusive fault of data subject or third party (Art. 43). - Processing deemed irregular when it fails to comply with law or does not provide security expected by data subject (Art. 44). - Controller/processor who causes damage by failing to adopt Art. 46 security measures liable for damages from data security violation (Art. 44, sole para.). - Violations in consumer relations remain subject to liability rules in relevant legislation (Art. 45). ### Administrative Sanctions (Art. 52) - I - Warning, indicating deadline for corrective measures; - II - Simple fine up to 2% of gross revenue of legal entity of private law, group or conglomerate net tax revenues in Brazil in preceding fiscal year (excluding taxes), limited to BRL 50,000,000 (fifty million Reais) per infraction; - III - Daily fine, subject to total limit in item II; - IV - Public disclosure of infraction after investigation and confirmation; - V - Blocking of personal data to which infraction refers until regularization; - VI - Erasure of personal data to which infraction refers; - X - Partial suspension of operations of database for maximum 6 months, extendable for equal period, until controller regularizes processing; - XI - Suspension of personal data processing activity for maximum 6 months, extendable for equal period; - XII - Partial or full prohibition of activities related to data processing. - Sanctions X, XI, XII only applied after at least one of sanctions II, III, IV, V, VI imposed for same specific case, and after hearing other bodies/entities with sanctioning powers (Art. 52, para. 6). ### Sanction Parameters and Criteria (Art. 52, para. 1) - I - Severity and nature of infractions and personal rights affected; - II - Good faith of offender; - III - Advantage obtained or intended by offender; - IV - Economic condition of offender; - V - Recidivism; - VI - Extent of damage; - VII - Cooperation of offender; - VIII - Repeated and demonstrated adoption of internal mechanisms/procedures to minimize damage, aimed at safe and proper data processing; - IX - Adoption of policy of good practices and governance; - X - Prompt adoption of corrective measures; - XI - Proportionality between severity of infraction and intensity of sanction. ### Sanctions for Government Entities (Art. 52, para. 3) - Sanctions I, IV, V, VI, X, XI and XII of Art. 52 may be applied to government entities and bodies (Art. 52, para. 3). - Application without prejudice to provisions of Law No. 8,112/1990 (civil servants), Law No. 8,429/1992 (administrative improbity), and Law No. 12,527/2011 (access to information). - ANPD may issue statement with applicable measures to cease violation by government bodies (Art. 31). - ANPD may request government authority agents to publish DPIA reports and suggest adoption of standards and good practices (Art. 32). ### National Data Protection Authority (ANPD) - ANPD is a special autarchy linked to the Ministry of Justice and Public Security, with functional, technical, decision-making, administrative and financial autonomy, with its own assets, and with headquarters and jurisdiction in the Federal District (Art. 55-A). - ANPD is composed of: (i) Board of Directors (highest governing body); (ii) National Council for Personal Data and Privacy Protection; (iii) Corregedoria; (iv) Ombudsman's Office; (v) Procuradoria; (vi) Auditoria; (vii) administrative and specialized units (Art. 55-C). - Board of Directors consists of 5 directors (including Director-President), chosen and appointed by President of Republic after Federal Senate approval (Art. 55-D). - Directors have 4-year term of office (Art. 55-D, para. 3). - ANPD responsible for: ensuring protection of personal data; ensuring compliance with trade/industrial secrets; preparing guidelines for National Policy for Personal Data and Privacy; and other duties in Art. 55-J. ### Personal Data Protection Principles (Art. 6) - I - Purpose: processing for legitimate, specific and explicit purposes informed to data subject, with no subsequent incompatible processing; - II - Adequacy: compatibility of processing with purposes informed to data subject; - III - Necessity: limitation to minimum required, relevant, proportional and non-excessive data; - IV - Free access: guarantee to data subjects of facilitated and free consultation on form/duration of processing and data integrity; - V - Data quality: guarantee of accuracy, clarity, relevance and updating of data; - VI - Transparency: guarantee of clear, accurate and easily accessible information on processing activities and processing agents; - VII - Security: use of technical/administrative measures to protect personal data; - VIII - Prevention: adoption of measures to prevent damages from processing; - IX - Non-discrimination: impossibility of processing for unlawful or abusive discriminatory purposes; - X - Liability and accountability: proof by agent of adoption of effective measures demonstrating observance and compliance, including effectiveness of measures. ### Key Definitions (Art. 5) - Personal data: information regarding identified or identifiable natural person (Art. 5, I); - Sensitive personal data: data concerning racial/ethnic origin, religious belief, political opinion, trade union affiliation, data on health/sex life, genetic or biometric data related to natural person (Art. 5, II); - Anonymized data: data related to data subject who cannot be identified, considering reasonable technical means available at time of processing (Art. 5, III); - Data subject: natural person to whom personal data being processed refers (Art. 5, V); - Consent: freely, informed and unambiguous manifestation whereby data subject agrees to processing of their personal data for given purpose (Art. 5, XII); - Processing: any operation performed on personal data (collection, production, receipt, classification, use, access, reproduction, transmission, distribution, processing, filing, storage, erasure, evaluation, control, modification, communication, transfer, dissemination or retrieval) (Art. 5, X); - Anonymization: use of reasonable technical means by which data loses possibility of direct or indirect association with individual (Art. 5, XI). ## Possible Outcomes ### [RESULT] Out of Scope LGPD does not apply - LGPD does not apply to your processing operations. - Either territorial scope not met (Art. 3) or an exclusion applies (Art. 4). - Even if LGPD does not apply, consider other applicable data protection laws and best practices. ### [RESULT] LGPD Applies - General Personal Data Follow Art. 7 legal bases and compliance requirements - LGPD applies to your processing of general personal data. - Ensure valid legal basis under Art. 7 for all processing operations. - Comply with all LGPD principles (Art. 6), data subject rights (Arts. 17-22), security obligations (Arts. 46-49), and other applicable requirements. - Appoint DPO as required (Art. 41). - Implement appropriate technical and administrative security measures (Art. 46). - Prepare for data subject rights requests (Art. 18) and security incident notification (Art. 48). - Maintain processing records, especially when based on legitimate interest (Art. 37). ### [RESULT] LGPD Applies - Sensitive Personal Data Follow Art. 11 stricter requirements - LGPD applies to your processing of sensitive personal data. - Ensure valid legal basis under Art. 11 (specific and emphatic consent OR one of Art. 11, II exceptions). - Apply heightened security measures for sensitive data (Art. 46, para. 1). - Be aware of restrictions on communication/shared use of sensitive data for economic advantage (Art. 11, para. 3-5). - Comply with all LGPD principles (Art. 6), data subject rights (Arts. 17-22), and other applicable requirements. - Appoint DPO as required (Art. 41). - Prepare for ANPD requests for DPIA (Art. 38). ### [RESULT] LGPD Applies - Children's/Adolescents' Data Follow Art. 14 best interest requirements - LGPD applies to your processing of children's and adolescents' personal data. - Processing must be in best interest of child/adolescent (Art. 14). - Obtain specific and distinguishable consent from at least one parent or legal representative for children's data (Art. 14, para. 1). - Make public information on types of data collected, usage, and procedures for exercising rights (Art. 14, para. 2). - Make all reasonable efforts to confirm consent given by representative, considering available technologies (Art. 14, para. 5). - Provide information in simple, clear and accessible manner, considering physical-motor, perceptive, sensorial, intellectual and mental characteristics (Art. 14, para. 6). - Do not subject participation to providing personal information beyond strictly necessary (Art. 14, para. 4). - Comply with all other LGPD requirements for general or sensitive data as applicable. ### [RESULT] Consent as Legal Basis Comply with Art. 8 consent requirements - You are relying on consent as legal basis (Art. 7, I or Art. 11, I). - Ensure consent is freely given, informed, and unambiguous (Art. 5, XII). - Obtain consent in writing or by other means demonstrating manifestation of intention (Art. 8). - If in writing, consent must be in clause that stands out from other contractual clauses (Art. 8, para. 1). - Maintain proof that consent was obtained (Art. 8, para. 2). - Consent must refer to specific purposes; generic authorizations are void (Art. 8, para. 4). - Provide data subject with Art. 9 information (purpose, type/duration, controller identity/contact, shared use, responsibilities, data subject rights). - Ensure data subject can revoke consent at any time via free and facilitated procedure (Art. 8, para. 5). - If consent required for communication/sharing with other controllers, obtain specific consent (Art. 7, para. 5). - For sensitive data: obtain specific and emphatic consent for specific purposes (Art. 11, I). - For children's data: obtain specific and distinguishable consent from at least one parent or legal representative (Art. 14, para. 1). ### [RESULT] Legitimate Interest as Legal Basis Comply with Art. 10 requirements - You are relying on legitimate interest as legal basis (Art. 7, IX). - Legitimate interest only for legitimate purposes based on particular situations, including: support/promotion of controller's activity; protection of data subject's regular exercise of rights or provision of services for their benefit (Art. 10). - Process only strictly necessary personal data (Art. 10, para. 1). - Adopt measures to ensure transparency of processing based on legitimate interest (Art. 10, para. 2). - Be prepared for ANPD to request DPIA when processing based on legitimate interest (Art. 10, para. 3). - Maintain records of processing operations based on legitimate interest (Art. 37). - Ensure data subject's fundamental rights and liberties requiring personal data protection do not prevail over legitimate interest (Art. 7, IX exception). ### [RESULT] DPO Appointment Required Comply with Art. 41 DPO requirements - You must appoint a Data Protection Officer (DPO / Encarregado) (Art. 41). - Publicly, clearly and objectively disclose DPO identity and contact data, preferably on website (Art. 41, para. 1). - Ensure DPO performs duties: (i) accept complaints/communications from data subjects, provide clarifications and adopt measures; (ii) receive communications from ANPD and adopt measures; (iii) instruct employees/contractors on data protection practices; (iv) perform other duties determined by controller or in supplementary rules (Art. 41, para. 2). - Monitor ANPD supplementary rules on DPO definition and duties (Art. 41, para. 3). - DPO acts as communication channel between controller, data subjects and ANPD (Art. 5, VIII). ### [RESULT] DPIA May Be Required Prepare for ANPD DPIA request - ANPD may require you to prepare Data Protection Impact Assessment (RIPD) (Art. 38). - DPIA contains description of processing operations that could pose risks to civil liberties and fundamental rights, and measures/safeguards/mechanisms to mitigate risks (Art. 5, XVII). - DPIA must contain at least: (i) description of types of data collected; (ii) methodology for collection and ensuring information security; (iii) analysis of adopted measures, safeguards and risk mitigation mechanisms (Art. 38, sole para.). - ANPD may request a DPIA when processing is based on legitimate interest (Art. 10, para. 3). - ANPD may request public sector agents to publish DPIA reports and may suggest standards and good practices for processing by the public sector (Art. 32). - Security measures must be observed from the product or service design phase through execution (Art. 46, para. 2), and controllers may adopt a privacy governance program based on a systematic assessment of impacts and privacy risks (Art. 50, para. 2, I(d)). ### [RESULT] International Transfer Permitted Ensure ongoing compliance with Art. 33-36 - International transfer of personal data permitted under Art. 33 grounds. - If relying on adequate level of protection (Art. 33, I): monitor ANPD evaluations of foreign country/organization (Art. 34). - If relying on contractual guarantees (Art. 33, II): use ANPD-defined standard contractual clauses or obtain ANPD verification of specific clauses, binding corporate rules, seals, certificates, codes of conduct (Art. 35). - If relying on ANPD authorization (Art. 33, V): maintain authorization documentation. - If relying on data subject consent (Art. 33, VIII): ensure specific and distinguishable consent with previous information on international nature of operation. - Communicate amendments to transfer guarantees to ANPD (Art. 36). - Ensure ongoing compliance with LGPD principles and data subject rights for transferred data. ### [RESULT] Security Incident Notification Required Notify ANPD and data subjects per Art. 48 - You must notify ANPD and data subjects of security incident that may result in relevant risk or damage (Art. 48). - Communicate as soon as reasonably feasible, as defined by ANPD (Art. 48, para. 1). - Communication must contain: (i) description of nature of affected personal data; (ii) information on data subjects involved; (iii) indication of technical/security measures used; (iv) risks related to incident; (v) reasons for delay if not immediate; (vi) measures adopted or to be adopted to reverse/mitigate effects (Art. 48, para. 1). - ANPD will determine severity of incident and may order: (i) full disclosure in media; (ii) measures to reverse/mitigate effects (Art. 48, para. 2). - Document incident and response measures for accountability (Art. 6, X). - Review and update security measures to prevent recurrence (Art. 46). ### [RESULT] Subject to ANPD Enforcement Ensure compliance to avoid Art. 52 sanctions - You are subject to ANPD administrative sanctions for LGPD infractions (Art. 52). - Sanctions range from warning to fines (up to 2% of gross revenue, capped at BRL 50 million per infraction) to partial/full prohibition of data processing activities (Art. 52, I-VI, X-XII). - Sanctions applied following administrative proceeding with opportunity for full defense, considering Art. 52, para. 1 parameters/criteria. - ANPD defines methodologies for fine calculation via public consultation (Art. 53). - Demonstrate good faith, cooperation, adoption of good practices/governance, prompt corrective measures to mitigate sanctions (Art. 52, para. 1, II, VII, VIII, IX, X). - Consider direct conciliation with data subjects for individual data breaches or unauthorized access (Art. 52, para. 7). - ANPD has competences that include issuing regulations and guidelines to implement LGPD (Art. 55-J), and ANPD may acknowledge and disseminate rules on good practices and governance (Art. 50, para. 3). ## LGPD Timeline | Date | Event | Reference | | --- | --- | --- | | 2018-08-14 | LGPD published (Law No. 13,709/2018) | Law No. 13,709/2018 (publication date) | | 2018-12-28 | ANPD framework provisions effective (Arts. 55-A to 55-L and others) | Art. 65, I | | 2019-07-08 | LGPD amended by Law No. 13,853/2019 (ANPD-related amendments) | Law No. 13,853/2019 (publication date) | | 2021-08-01 | Administrative sanctions (Arts. 52-54) became enforceable | Art. 65, I-A | | 2022-10-26 | Law No. 14,460/2022 enters into force (transforms ANPD into a special autarchy) | Law No. 14,460/2022 (publication / entry into force) | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2014-04-23 | Marco Civil da Internet (Lei 12.965/2014) published | Legislation | | | 2014-06-23 | Marco Civil enters into force | Legislation | | | 2016-05-11 | Marco Civil regulation (Decreto 8.771/2016) published | Legislation | | | 2018-08-14 | LGPD enacted (Lei 13.709/2018) published | Legislation | | | 2018-08-15 | LGPD partially republished (extra edition) | Legislation | | | 2018-12-28 | ANPD-related provisions enter into force under LGPD | ANPD Development | | | 2019-07-08 | LGPD amended and ANPD created (Lei 13.853/2019) published | ANPD Development | | | 2020-08-26 | ANPD structure established (Decreto 10.474/2020) published | ANPD Development | | | 2021-01-01 | LGPD guide for the electoral context published (2021) | Guidance & Regulation | | | 2021-01-27 | ANPD Regulatory Agenda 2021-2022 adopted | Regulatory Agenda | | | 2021-03-08 | ANPD internal regulations approved (Portaria No. 1/2021) | ANPD Development | | | 2021-05-01 | ANPD guide on controllers, processors, and DPOs (May 2021) | Guidance & Regulation | | | 2021-07-08 | ANPD rulemaking process approved (Portaria/ANPD No. 16/2021) | ANPD Development | | | 2021-08-01 | LGPD sanctions provisions become effective (Arts. 52-54) | Enforcement & Sanctions | | | 2021-10-28 | ANPD inspection and sanctioning procedures (Resolução CD/ANPD No. 1/2021) adopted | Enforcement & Sanctions | | | 2021-10-29 | Resolução CD/ANPD No. 1/2021 published (in force) | Enforcement & Sanctions | | | 2021-11-10 | International transfer regulation project opened (Termo de Abertura de Projeto) | Regulatory Agenda | | | 2022-01-01 | ANPD guide for personal data processing by public authorities (Jan 2022) | Guidance & Regulation | | | 2022-01-27 | Small-scale processing agents regulation adopted (Resolução CD/ANPD No. 2/2022) | Guidance & Regulation | | | 2022-02-03 | Information security guidance for small-scale processing agents (Feb 2022) | Guidance & Regulation | | | 2022-05-18 | International transfer regulation questionnaire period begins | Regulatory Agenda | | | 2022-06-30 | International transfer regulation questionnaire period ends | Regulatory Agenda | | | 2022-09-01 | Preliminary study on children's and adolescents' personal data (Sep 2022) | Guidance & Regulation | | | 2022-09-21 | ANPD structure amended (Decreto 11.202/2022) published | ANPD Development | | | 2022-10-01 | ANPD cookies and personal data protection guide (Oct 2022) | Guidance & Regulation | | | 2022-10-05 | Decreto 11.202/2022 enters into force | ANPD Development | | | 2022-10-26 | ANPD becomes an autonomous authority (Lei 14.460/2022) published | ANPD Development | | | 2022-11-04 | ANPD Regulatory Agenda 2023-2024 published | Regulatory Agenda | | | 2023-02-24 | Sanctions dosimetry rules (Resolução CD/ANPD No. 4/2023) adopted | Enforcement & Sanctions | | | 2023-02-27 | Resolução CD/ANPD No. 4/2023 published (in force) | Enforcement & Sanctions | | | 2023-05-22 | ANPD Statement (Enunciado CD/ANPD No. 1) approved | Guidance & Regulation | | | 2023-05-24 | Enunciado CD/ANPD No. 1 published in the DOU | Guidance & Regulation | | | 2023-08-14 | International transfer regulation consultation notice published (Consulta Publica No. 2/2023) | Regulatory Agenda | | | 2023-08-15 | International transfer regulation public consultation begins | Regulatory Agenda | | | 2023-09-12 | International transfer regulation public hearing held | Regulatory Agenda | | | 2023-10-14 | International transfer regulation public consultation ends | Regulatory Agenda | | | 2023-12-27 | ANPD Regulatory Agenda 2023-2024 amended | Regulatory Agenda | | | 2024-02-01 | Legitimate interest guide published (Feb 2024) | Guidance & Regulation | | | 2024-04-24 | Security incident communication regulation approved (Resolução CD/ANPD No. 15/2024) | Enforcement & Sanctions | | | 2024-07-17 | ANPD SEI external user manual updated (v17-07-2024) | Guidance & Regulation | | | 2025-08-18 | International data transfer regulation rectified (Aug 2025) | Guidance & Regulation | | | 2026-12-31 | ANPD personnel requisition authority expires (Decreto 10.474/2020) | ANPD Development | | **Event details:** - **2014-04-23 - Marco Civil da Internet (Lei 12.965/2014) published**: LEI Nº 12.965, DE 23 DE ABRIL DE 2014 - **2014-06-23 - Marco Civil enters into force**: Esta Lei entra em vigor após decorridos 60 (sessenta) dias de sua publicação oficial. - **2016-05-11 - Marco Civil regulation (Decreto 8.771/2016) published**: DECRETO Nº 8.771, DE 11 DE MAIO DE 2016 - **2018-08-14 - LGPD enacted (Lei 13.709/2018) published**: LEI Nº 13.709, DE 14 DE AGOSTO DE 2018 - **2018-08-15 - LGPD partially republished (extra edition)**: republicado parcialmente em 15.8.2018 - Edição extra - **2018-12-28 - ANPD-related provisions enter into force under LGPD**: dia 28 de dezembro de 2018, quanto aos arts. 55-A, 55-B, 55-C, 55-D, 55-E, 55-F, 55-G, 55-H, 55-I, 55-J, 55-K, 55-L, 58-A e 58-B - **2019-07-08 - LGPD amended and ANPD created (Lei 13.853/2019) published**: LEI Nº 13.853, DE 8 DE JULHO DE 2019 - **2020-08-26 - ANPD structure established (Decreto 10.474/2020) published**: DECRETO Nº 10.474, DE 26 DE AGOSTO DE 2020 - **2021-01-01 - LGPD guide for the electoral context published (2021)**: Brasilia, TSE, 2021 (year only in source; date normalized for sorting). - **2021-01-27 - ANPD Regulatory Agenda 2021-2022 adopted**: Ordinance No. 11, of January 27, 2021 - **2021-03-08 - ANPD internal regulations approved (Portaria No. 1/2021)**: Regimento Interno da ANPD aprovado pela Portaria No. 1, de 8 de marco de 2021. - **2021-05-01 - ANPD guide on controllers, processors, and DPOs (May 2021)**: Data indicada na capa: MAIO DE 2021 - **2021-07-08 - ANPD rulemaking process approved (Portaria/ANPD No. 16/2021)**: Portaria/ANPD No. 16, de 8 de julho de 2021 (approves the regulatory process within ANPD; cited in RTID annexes). - **2021-08-01 - LGPD sanctions provisions become effective (Arts. 52-54)**: dia 1º de agosto de 2021, quanto aos arts. 52, 53 e 54; (Incluído pela Lei nº 14.010, de 2020) - **2021-10-28 - ANPD inspection and sanctioning procedures (Resolução CD/ANPD No. 1/2021) adopted**: RESOLUÇÃO CD/ANPD Nº 1, DE 28 DE OUTUBRO DE 2021 - **2021-10-29 - Resolução CD/ANPD No. 1/2021 published (in force)**: Publicado em: 29/10/2021 | Edicao: 205 | Secao: 1 | Pagina: 6. Entra em vigor na data de publicacao. - **2021-11-10 - International transfer regulation project opened (Termo de Abertura de Projeto)**: Process to regulate international data transfers started with a project opening term signed on 10/11/2021 (cited in RTID Annex 1-D). - **2022-01-01 - ANPD guide for personal data processing by public authorities (Jan 2022)**: VERSÃO 1.0 JAN. 2022 - **2022-01-27 - Small-scale processing agents regulation adopted (Resolução CD/ANPD No. 2/2022)**: RESOLUCAO CD/ANPD No. 2, de 27 de janeiro de 2022 (Regulamento para agentes de tratamento de pequeno porte). - **2022-02-03 - Information security guidance for small-scale processing agents (Feb 2022)**: Brasilia, 03 de fevereiro de 2022 (date shown in the ANPD guidance document). - **2022-05-18 - International transfer regulation questionnaire period begins**: CGN received responses to 20 questions between 18/05/2022 and 30/06/2022 (cited in RTID Annex 1-D). - **2022-06-30 - International transfer regulation questionnaire period ends**: CGN received responses through 30/06/2022 (cited in RTID Annex 1-D). - **2022-09-01 - Preliminary study on children's and adolescents' personal data (Sep 2022)**: Setembro/2022 (cover; month only). - **2022-09-21 - ANPD structure amended (Decreto 11.202/2022) published**: DECRETO Nº 11.202, DE 21 DE SETEMBRO DE 2022 - **2022-10-01 - ANPD cookies and personal data protection guide (Oct 2022)**: OUT/2022 (cover; month only). - **2022-10-05 - Decreto 11.202/2022 enters into force**: Este Decreto entra em vigor em 5 de outubro de 2022. - **2022-10-26 - ANPD becomes an autonomous authority (Lei 14.460/2022) published**: Publicado no DOU de 26.10.2022. Entra em vigor na data de sua publicacao. - **2022-11-04 - ANPD Regulatory Agenda 2023-2024 published**: ANPD ORDINANCE No. 35, of NOVEMBER 4, 2022 - **2023-02-24 - Sanctions dosimetry rules (Resolução CD/ANPD No. 4/2023) adopted**: RESOLUÇÃO CD/ANPD Nº 4, DE 24 DE FEVEREIRO DE 2023 - **2023-02-27 - Resolução CD/ANPD No. 4/2023 published (in force)**: Publicado em: 27/02/2023 | Edição: 39 | Seção: 1 | Página: 59 - **2023-05-22 - ANPD Statement (Enunciado CD/ANPD No. 1) approved**: ENUNCIADO CD/ANPD Nº 1, DE 22 DE MAIO DE 2023 - **2023-05-24 - Enunciado CD/ANPD No. 1 published in the DOU**: Publicado em: 24/05/2023 | Edicao: 98 | Secao: 1 | Pagina: 129. - **2023-08-14 - International transfer regulation consultation notice published (Consulta Publica No. 2/2023)**: Publicacao da Consulta Publica No. 2, de 14 de agosto de 2023, no DOU (edicao 15/08/2023, citado em RTID Anexo 1-D). - **2023-08-15 - International transfer regulation public consultation begins**: Consulta Publica na plataforma Participa Mais Brasil (15/08/2023 a 14/10/2023, citado em RTID Anexo 1-D). - **2023-09-12 - International transfer regulation public hearing held**: Audiencia Publica virtual realizada em 12/09/2023 (citada em RTID Anexo 1-D). - **2023-10-14 - International transfer regulation public consultation ends**: Fim da Consulta Publica (14/10/2023, citado em RTID Anexo 1-D). - **2023-12-27 - ANPD Regulatory Agenda 2023-2024 amended**: RESOLUTION CD/ANPD No. 11, of DECEMBER 27, 2023 - **2024-02-01 - Legitimate interest guide published (Feb 2024)**: FEV/2024 (cover; month only). - **2024-04-24 - Security incident communication regulation approved (Resolução CD/ANPD No. 15/2024)**: Resolução CD/ANPD No. 15, de 24 de abril de 2024 (Regulamento de Comunicacao de Incidente de Seguranca). - **2024-07-17 - ANPD SEI external user manual updated (v17-07-2024)**: Versao atualizada em 17/07/2024. - **2025-08-18 - International data transfer regulation rectified (Aug 2025)**: (Amended by the RECTIFICATION of August 18, 2025) - **2026-12-31 - ANPD personnel requisition authority expires (Decreto 10.474/2020)**: A ANPD poderá requisitar pessoal civil e militar até 31 de dezembro de 2026 --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam/brazil-lgpd --- --- title: "EU Batteries Regulation Timeline, Decision Flow, and Compliance Guides" canonical_url: "https://www.sorena.io/artifacts/eu/batteries-regulation" source_url: "https://www.sorena.io/artifacts/eu/batteries-regulation" author: "Sorena AI" description: "Use this Batteries Regulation hub to classify battery categories, map the exact dates in Regulation (EU) 2023/1542." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Batteries Regulation" - "Regulation (EU) 2023/1542" - "battery passport" - "QR code batteries" - "battery carbon footprint declaration" - "battery due diligence" - "Article 11 removability" - "Article 14 state of health" - "recycled content batteries" - "collection targets portable batteries" - "collection targets LMT batteries" - "recycling efficiency targets" - "producer responsibility batteries" - "Article 7" - "Article 48" - "Producer responsibility" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Batteries Regulation Timeline, Decision Flow, and Compliance Guides Use this Batteries Regulation hub to classify battery categories, map the exact dates in Regulation (EU) 2023/1542. ![EU Batteries Regulation artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-batteries-timeline-small.jpg?v=cheatsheets%2Fprod) *EU Batteries* *Free Resource* ## EU Batteries Regulation Timeline, Decision Flow & Guides Use this artifact to classify batteries as portable, LMT, SLI, industrial, or EV, then route each model to the right obligations for battery passport, carbon footprint, due diligence, labels, state of health data, recycled content, and waste battery management. The dates matter: the Regulation applies from 18 February 2024, Article 14 and Chapter VI timing start from 18 August 2024, due diligence and penalties readiness start from 18 August 2025, broader labels start from 18 August 2026, and QR plus battery passport and Article 11 removability start from 18 February 2027. [Get a batteries readiness review](/contact.md) ## What you can decide faster - **Category and scope**: Classify portable, LMT, SLI, industrial, and EV batteries using the legal definitions and thresholds. - **Product and data duties**: Route the model to Article 7, Article 8, Article 11, Article 13, Article 14, and Article 77 where they apply. - **Lifecycle and waste duties**: Plan due diligence, producer responsibility, collection, recycling, and reporting with the right dates and evidence. By Sorena AI | Updated 2026 | No signup required ### Quick scan *Batteries* - **Category route**: Decide the legal battery category before you build labels, passport, or due diligence controls. - **Date map**: Track the 2024, 2025, 2026, and 2027 milestones that change what must be operational. - **Evidence path**: Move from product requirements to supplier evidence and waste reporting without splitting the model record. Use the decision flow first, then open the page specific guides to build the right controls and records. | Value | Metric | | --- | --- | | 18 Feb 2024 | Applies | | 18 Aug 2025 | Due diligence | | 18 Aug 2026 | Labels | | 18 Feb 2027 | Passport | **Key highlights:** Classify battery | Build passport | Plan waste duties ## Topic Guides - [Battery Carbon Footprint Declarations | Article 7 Implementation Guide](/artifacts/eu/batteries-regulation/carbon-footprint-declarations.md): Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations. - [Battery Due Diligence Program | Articles 48 to 52 Implementation Guide](/artifacts/eu/batteries-regulation/due-diligence-program.md): Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability. - [Battery Due Diligence Supplier Questionnaire | EU Batteries Regulation](/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire.md): Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542. - [Battery Labeling and Consumer Information | Article 13 and Article 74 Guide](/artifacts/eu/batteries-regulation/labeling-and-consumer-information.md): Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol. - [Battery Passport Data Model Template | Annex XIII Ready Structure](/artifacts/eu/batteries-regulation/battery-passport-data-model-template.md): Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data. - [Battery Passport Implementation | Article 77 and Article 78 Guide](/artifacts/eu/batteries-regulation/battery-passport-implementation.md): Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model. - [Battery Recycled Content and Recovery Targets | Article 8 and Annex XII Guide](/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets.md): Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII. - [EU Batteries Regulation Applicability Test | Category, Scope, and Obligation Routing](/artifacts/eu/batteries-regulation/applicability-test.md): Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Battery Categories and Scope | Portable, LMT, SLI, Industrial, EV](/artifacts/eu/batteries-regulation/battery-categories-and-scope.md): Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Checklist | Practical Compliance Checklist by Battery Category](/artifacts/eu/batteries-regulation/checklist.md): Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations. - [EU Batteries Regulation Compliance Program | Build an Operational Batteries Program](/artifacts/eu/batteries-regulation/compliance.md): Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations. - [EU Batteries Regulation Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar.md): Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024. - [EU Batteries Regulation FAQ | Dates, Categories, Passport, Due Diligence, and Waste Duties](/artifacts/eu/batteries-regulation/faq.md): Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts. - [EU Batteries Regulation Penalties and Enforcement | Article 93 Guide](/artifacts/eu/batteries-regulation/penalties-and-fines.md): Understand the penalty and enforcement structure in Regulation (EU) 2023/1542. - [EU Batteries Regulation Requirements | Article by Article Requirement Map](/artifacts/eu/batteries-regulation/requirements.md): Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability. - [EU Batteries Regulation vs ESPR | Battery Passport vs Digital Product Passport](/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr.md): Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model. ## Key dates for battery compliance *Batteries Timeline* Track the phased dates for state of health, due diligence, labels, QR, passport, recycled content, collection targets, and recycling performance. ## Which obligations apply to your batteries *Batteries Decision Flow* Use the decision flow to classify the battery and route it to the right product, data, due diligence, and waste obligations. *Next step* ## Turn EU Batteries Regulation Timeline, Decision Flow & Guides into an ESG delivery workflow EU Batteries Regulation Timeline, Decision Flow & Guides should be the shared entry point for your team. Route execution into ESG Compliance for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU Batteries Regulation Timeline, Decision Flow & Guides and route the work by entity, product, team, or control owner. - Use ESG Compliance to manage cross team sustainability work, reporting, and evidence from one workflow. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open ESG Compliance](/solutions/esg-compliance.md): Manage cross team sustainability work, reporting, and evidence from one workflow for EU Batteries Regulation Timeline, Decision Flow & Guides. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share the category and obligation logic internally. - **Download timeline**: Align packaging, digital, supplier, and waste work with the legal dates. - [Talk through EU Batteries Regulation Timeline, Decision Flow & Guides](/contact.md): Review your current process, evidence model, and next steps for EU Batteries Regulation Timeline, Decision Flow & Guides. ## Decision Steps ### STEP 1: Do you place batteries on the EU market or put them into service? *Reference: Art. 1, Art. 3(16)-(18)* - This Regulation lays down requirements on sustainability, safety, labelling, marking and information to allow the placing on the market or putting into service of batteries within the Union. - It applies to all categories of batteries, including batteries incorporated into or added to products. - Placing on the market means the first making available of a battery on the Union market; making available on the market means any supply for distribution or use in the course of a commercial activity; putting into service means the first use for the intended purpose in the Union. - **YES** Which battery category applies? - **NO** Not Subject to Batteries Regulation ### STEP 2: Which battery category applies? *Reference: Art. 3(9)-(14)* - Portable battery: sealed, weighs 5 kg or less, not designed specifically for industrial use, and neither an EV, LMT, nor SLI battery. - LMT battery: sealed, weighs 25 kg or less, designed to provide traction power for wheeled vehicles powered by an electric motor alone or by a combination of motor and human power (including category L vehicles), and not an EV battery. - SLI battery: designed to supply electric power for starting, lighting or ignition, and can also be used for auxiliary or backup purposes. - EV battery: designed for traction in hybrid or electric vehicles of category L that weigh more than 25 kg, or in hybrid or electric vehicles of categories M, N or O. - Industrial battery: designed for industrial uses, or intended for industrial uses after preparation for repurposing or repurposing, or any other battery that weighs more than 5 kg and is neither an EV, LMT, nor SLI battery. - -> What is your role as an economic operator? ### STEP 3: What is your role as an economic operator? *Reference: Art. 3(22), (33), (63)-(65)* - Manufacturer: natural or legal person who manufactures a battery or has a battery designed or manufactured, and markets that battery under the manufacturer's name or trademark. - Importer: natural or legal person established in the Union who places a battery from a third country on the Union market. - Distributor: natural or legal person in the supply chain, other than the manufacturer or importer, who makes a battery available on the market. - Authorised representative: natural or legal person established in the Union with a written mandate from the manufacturer to act on the manufacturer's behalf. - Each role has specific obligations under the Regulation. - -> Do sustainability requirements apply to your battery? ### STEP 4: Do sustainability requirements apply to your battery? *Reference: Art. 6-10* - Carbon footprint declaration and performance classes apply to: rechargeable industrial batteries >2 kWh, LMT batteries, and EV batteries (Art. 7). - Recycled content requirements apply to: industrial batteries >2 kWh, EV batteries, and certain SLI and LMT batteries containing cobalt, lead, lithium, or nickel in active materials (Art. 8). - Performance and durability requirements apply to: portable batteries of general use, rechargeable industrial batteries, LMT batteries, and EV batteries (Art. 9-10). - Restrictions on hazardous substances apply to all batteries (Art. 6). - -> Have you met labelling and information requirements? ### STEP 5: Have you met labelling and information requirements? *Reference: Art. 13-14, 77* - Separate collection symbol: from 18 Aug 2025, all batteries must be marked with the separate collection symbol (Art. 13(4)). - General labels and capacity labels: apply from 18 Aug 2026 (or later depending on the implementing act) (Art. 13(1)-(3), Art. 13(10)). - Heavy metal marking: batteries containing more than 0.002% cadmium or more than 0.004% lead must be marked with Cd or Pb (Art. 13(5)). - QR code: from 18 Feb 2027, all batteries must be marked with a QR code providing access to required information (Art. 13(6)). - Battery passport: from 18 Feb 2027, LMT batteries, industrial batteries over 2 kWh and EV batteries must have a battery passport accessible via the QR code (Art. 77(1), Art. 13(6)(a)). - State of health and expected lifetime data: for stationary battery energy storage systems, LMT and EV batteries, up-to-date data must be contained in the battery management system from 18 Aug 2024; read-only access must be provided to legitimate purchasers (Art. 14). - -> Does your battery meet removability and replaceability requirements? ### STEP 6: Does your battery meet removability and replaceability requirements? *Reference: Art. 11, Art. 96(2)(a)* - Article 11 applies from 18 Feb 2027 (Art. 96(2)(a)). - Products incorporating portable batteries: batteries must be readily removable and replaceable by the end-user using commercially available tools (Art. 11(1)). - Derogations: certain products can be designed so the portable battery is removable/replaceable only by independent professionals (Art. 11(2)); and Article 11 does not apply where continuity of power supply is necessary and a permanent connection is required for safety or data integrity reasons (Art. 11(3)). - Products incorporating LMT batteries: LMT batteries and individual cells in the pack must be readily removable and replaceable by an independent professional (Art. 11(5)). - Spare parts and software: portable and LMT batteries must be available as spare parts for at least five years, and software must not impede replacement (Art. 11(7)-(8)). - -> Do you need a battery due diligence policy? ### STEP 7: Do you need a battery due diligence policy? *Reference: Arts. 47-52* - From 18 August 2025: economic operators that place batteries on the market or put them into service must set up and implement battery due diligence policies covering raw materials listed in Annex X (Arts. 48-50, 52). - Chapter VII does not apply to economic operators with net turnover < EUR 40 million (and not part of a group exceeding EUR 40 million consolidated) (Art. 47). - Based on OECD Due Diligence Guidance, UN Guiding Principles on Business and Human Rights, ILO standards. - Policies are risk-based and cover the supply chain for the relevant raw materials and secondary raw materials. - Does not apply (as a due diligence obligation) to batteries that were already placed on the market or put into service before being prepared for re-use/repurposed/repurposing/remanufactured (Art. 47). - -> Which conformity assessment procedure applies? ### STEP 8: Which conformity assessment procedure applies? *Reference: Arts. 17-20, Annex VIII-IX* - Articles 6, 9, 10, 12, 13 and 14: conformity assessment is Module A (internal production control) or Module D1 (quality assurance of the production process) for series production; or Module A or Module G (unit verification) for non-series production (Art. 17(1), Annex VIII). - Articles 7 and 8 (carbon footprint and recycled content): conformity assessment is Module D1 for series production or Module G for non-series production (Art. 17(2), Annex VIII). - Repurposed/remanufactured and similar batteries: an additional conformity assessment is required using Module A, taking into account requirements in Articles 6, 9, 10, 12, 13 and 14 (Art. 17(3), Annex VIII). - EU declaration of conformity: the manufacturer draws up the EU declaration of conformity; the model structure is in Annex IX (Art. 18). - CE marking: affixed before the battery is placed on the market or put into service; where required, it is followed by the notified body identification number (Arts. 19-20). - -> Are you subject to Extended Producer Responsibility (EPR)? ### STEP 9: Are you subject to Extended Producer Responsibility (EPR)? *Reference: Arts. 55-60* - Producers have extended producer responsibility for batteries they make available on the market for the first time in a Member State (Art. 56(1)). - Producers must register in each relevant Member State register before placing batteries on that Member State market (Art. 55(2)). - Producers finance key waste-management costs (separate collection, treatment, compositional surveys, information to end-users, and reporting/data gathering) (Art. 56(4)). - Producers may fulfil EPR obligations collectively via a producer responsibility organisation (Art. 57). - Collection and take-back obligations and targets apply for portable and LMT batteries (Arts. 59-60). - -> Does your battery undergo repurposing or second life? ### STEP 10: Does your battery undergo repurposing or second life? *Reference: Art. 3(30)-(32), Art. 13(9), Art. 17(3), Art. 38(11), Art. 73, Art. 77(7)* - Preparation for repurposing applies to waste batteries (or parts) prepared for a different purpose than originally designed; repurposing applies to non-waste batteries (or parts) used for a different purpose; remanufacturing restores capacity and keeps the same purpose (Art. 3(30)-(32)). - If you place on the market or put into service a battery that has been prepared for re-use/repurposing, repurposed or remanufactured, you are considered a manufacturer for the purposes of this Regulation (Art. 38(11)). - An additional conformity assessment is required (Module A) for batteries that have undergone these operations, taking into account applicable requirements (Art. 17(3), Annex VIII). - Batteries that have undergone these operations must bear new labels or markings, including change-of-status information accessible through the QR code (Art. 13(9)). - For waste LMT/industrial/EV batteries prepared for re-use or prepared for repurposing, documentation is required to demonstrate that the battery is no longer waste; detailed technical requirements for ceasing to be waste may be set by implementing act (Art. 73). - Battery passport responsibilities transfer to the operator placing the repurposed/remanufactured battery on the market, and a new passport is required (Art. 77(7)). - **YES** Is it a portable battery? - **NO** Is it a portable battery? ### STEP 11: Is it a portable battery? *Reference: Art. 3(9)* - Portable battery: sealed, weighs 5 kg or less, not designed specifically for industrial use, and neither an EV, LMT, nor SLI battery. - **YES** Portable Battery Compliance - **NO** Is it an LMT battery? ### STEP 12: Is it an LMT battery? *Reference: Art. 3(11)* - LMT battery: sealed, weighs 25 kg or less, designed to provide traction power for wheeled vehicles powered by an electric motor alone or by a combination of motor and human power (including category L vehicles), and not an EV battery. - **YES** LMT Battery Compliance - **NO** Is it an SLI battery? ### STEP 13: Is it an SLI battery? *Reference: Art. 3(12)* - SLI battery: designed to supply electric power for starting, lighting, or ignition and can also be used for auxiliary or backup purposes in vehicles, other means of transport or machinery. - **YES** SLI Battery Compliance - **NO** Is it an EV battery? ### STEP 14: Is it an EV battery? *Reference: Art. 3(14)* - EV battery: designed to provide traction power for hybrid or electric vehicles of category L (above 25 kg) or for hybrid or electric vehicles of categories M, N or O. - **YES** EV Battery Compliance - **NO** Industrial Battery Compliance ## Reference Information ### Battery Categories Overview - Portable: sealed, 5 kg or less, not industrial and not EV/LMT/SLI (for example, consumer device batteries). - LMT: sealed, 25 kg or less, traction for wheeled vehicles powered by motor alone or motor plus human power (including category L), and not an EV battery. - SLI: starting, lighting and ignition, including auxiliary or backup uses. - EV: traction for hybrid or electric vehicles (category L above 25 kg, or categories M/N/O). - Industrial: designed for industrial uses, or any other battery above 5 kg that is neither EV/LMT/SLI. ### Carbon Footprint Requirements - Applies to: EV batteries, rechargeable industrial batteries with capacity greater than 2 kWh, and LMT batteries (Art. 7). - Carbon footprint declaration applies (earliest): EV from 18 Feb 2025; rechargeable industrial (except exclusively external storage) from 18 Feb 2026; LMT from 18 Aug 2028; rechargeable industrial with external storage from 18 Aug 2030 (Art. 7(1)). - Carbon footprint performance class labelling applies (earliest): EV from 18 Aug 2026; rechargeable industrial (except exclusively external storage) from 18 Aug 2027; LMT from 18 Feb 2030; rechargeable industrial with external storage from 18 Feb 2032 (Art. 7(2)). - Maximum life cycle carbon footprint threshold applies (earliest): EV from 18 Feb 2028; rechargeable industrial (except exclusively external storage) from 18 Feb 2029; LMT from 18 Aug 2031; rechargeable industrial with external storage from 18 Aug 2033 (Art. 7(3)). - Declaration content includes: carbon footprint per kWh over expected service life; carbon footprint by life cycle stage; and a public web link to a supporting study (Art. 7(1)). - These requirements do not apply to a battery that was already placed on the market or put into service before being prepared for re-use/repurposing/repurposed/remanufactured (Art. 7(5)). ### Recycled Content Requirements - Applies to: industrial batteries over 2 kWh (except exclusively external storage), EV batteries, and SLI batteries that contain cobalt, lead, lithium or nickel in active materials; LMT batteries have later start dates for documentation and targets (Art. 8). - Recycled content share documentation accompanies batteries (earliest): industrial/EV/SLI from 18 Aug 2028; LMT from 18 Aug 2033 (Art. 8(1)). - Minimum recycled content shares (technical documentation) apply from 18 Aug 2031 for industrial/EV/SLI: cobalt 16%, lead 85%, lithium 6%, nickel 6% (Art. 8(2)). - Increased minimum recycled content shares apply from 18 Aug 2036 for industrial/EV/LMT/SLI: cobalt 26%, lead 85%, lithium 12%, nickel 15% (Art. 8(3)). - These requirements do not apply to batteries that were already placed on the market or put into service before being prepared for re-use/repurposing/repurposed/remanufactured (Art. 8(4)). ### Performance and Durability Requirements - Portable batteries of general use: minimum values for electrochemical performance and durability parameters apply from 18 Aug 2028 (or later depending on delegated act timing) (Art. 9). - Rechargeable industrial batteries over 2 kWh, LMT batteries and EV batteries: must be accompanied by a document with values for electrochemical performance and durability parameters (from 18 Aug 2024) (Art. 10(1), Annex IV). - Minimum values: rechargeable industrial (except exclusively external storage) apply from 18 Aug 2027 (or later depending on delegated act timing); LMT apply from 18 Aug 2028 (or later depending on delegated act timing) (Art. 10(2)-(3), Art. 10(5)). - Repurposed/remanufactured batteries: certain performance obligations do not apply if the battery was already placed on the market or put into service before the relevant obligation became applicable and the operator demonstrates that (Art. 10(4)). ### Labelling and Information - From 18 Aug 2025: separate collection symbol marking applies to all batteries (Art. 13(4), Annex VI Part B). - From 18 Aug 2026 (or later depending on implementing act timing): batteries must bear labels containing general information, and certain categories must bear capacity labels; non-rechargeable portable batteries also bear a minimum average duration label and a 'non-rechargeable' label (Art. 13(1)-(3), Art. 13(10)). - From 18 Feb 2027: all batteries must be marked with a QR code. For LMT/industrial over 2 kWh/EV, the QR code gives access to the battery passport; for other batteries it gives access to applicable information including the EU declaration of conformity and required waste information; for SLI it also includes recovered materials information calculated in accordance with Art. 8 (Art. 13(6)). - Batteries that have been prepared for re-use/repurposing/repurposed/remanufactured must bear new labels or markings and include change-of-status information accessible through the QR code (Art. 13(9), Annex XIII). - State of health and expected lifetime data must be contained in the battery management system for stationary battery energy storage systems, LMT and EV batteries from 18 Aug 2024, with read-only access to purchasers and certain third parties (Art. 14, Annex VII). - Accessibility: the Regulation highlights that labels and QR codes should be accessible to persons with disabilities (recital (44)). ### Battery Passport - Required from 18 February 2027 for: EV batteries, LMT batteries, and industrial batteries with a capacity greater than 2 kWh (Art. 77). - Information requirements are set out in Annex XIII and include battery model information and information specific to the individual battery, including resulting from use (Art. 77(2)). - The battery passport is accessed through the QR code and a unique identifier attributed by the economic operator placing the battery on the market (Art. 77(3), Art. 13(6)(a)). - Access is tiered (public, authorities/notified bodies/Commission, and legitimate-interest users) and is regulated under the essential requirements in Art. 78 and Annex XIII (Art. 77(2), Art. 77(6)). - For batteries that have been prepared for re-use/repurposing/repurposed/remanufactured, responsibility for keeping passport information accurate and up to date transfers to the operator placing the battery on the market, and a new passport is required (Art. 77(7)). ### Removability and Replaceability - Portable batteries (in products): readily removable by the end-user if they can be removed with commercially available tools and without requiring specialised tools (unless provided free of charge), proprietary tools, thermal energy, or solvents (Art. 11(1)). - Instructions and safety information: products incorporating portable batteries must be accompanied with instructions and safety information on use, removal and replacement, and those instructions must be permanently available online (Art. 11(1)). - Derogations and exclusions: certain water-exposed appliances and certain medical devices may allow removal only by independent professionals; and there is an exclusion where continuity of power supply requires permanent connection for safety or data integrity reasons (Art. 11(2)-(3)). - LMT batteries: must be readily removable and replaceable by an independent professional; replacement must not affect functioning, performance or safety (Art. 11(5)-(6)). - Spare parts availability and software: batteries must be available as spare parts for at least five years, and software must not be used to impede replacement (Art. 11(7)-(8)). ### Battery Due Diligence Policy - Scope and exemptions: this Chapter does not apply to economic operators with net turnover < EUR 40 million (and not part of a group exceeding EUR 40 million consolidated) (Art. 47). - Start date: from 18 August 2025, economic operators placing batteries on the market or putting them into service must set up and implement battery due diligence policies (Art. 48(1)). - Due diligence covers raw materials listed in Annex X and associated social and environmental risk categories (Art. 49(1)(a)-(b) and Annex X). - Core elements include a management system and supply-chain controls/traceability, risk assessment and mitigation, third-party verification by a notified body, and annual public reporting (Arts. 49-52 and 51). - Recordkeeping: keep relevant documentation (including verification/audit reports) for 10 years after the last battery manufactured under the policy has been placed on the market (Art. 48(3)). ### Conformity Assessment and CE Marking - Technical documentation: manufacturers draw up technical documentation and carry out the relevant conformity assessment procedure before placing a battery on the market or putting it into service (Art. 38(2), Annex VIII). - Module A, Module D1, Module G: the Batteries Regulation uses Module A (internal production control), Module D1 (quality assurance of the production process) and Module G (unit verification) as set out in Annex VIII, depending on the requirements and whether production is in series (Art. 17(1)-(2)). - EU declaration of conformity: states that compliance with the relevant requirements has been demonstrated; follows the model structure in Annex IX and includes elements specified in Annex VIII modules (Art. 18(1)-(2)). - CE marking: affixed visibly, legibly and indelibly to the battery (or packaging/documents when not possible) before placing on the market or putting into service; may be followed by the notified body identification number where required (Art. 20). - Notified bodies: required for certain modules; notified bodies are designated and monitored by Member States under Chapter V (Arts. 21-37). ### Extended Producer Responsibility (EPR) - EPR obligation: producers have extended producer responsibility for batteries they make available on the market for the first time in a Member State (Art. 56(1)). - Registration: producers register in each Member State where they first make batteries available; registration is a precondition for placing batteries on that Member State market (Art. 55(2)). - Financed costs: separate collection and subsequent transport/treatment, compositional surveys (Art. 69(5)), information to end-users (Art. 74), and reporting/data gathering (Art. 75) (Art. 56(4)). - Collective compliance: producers may appoint a producer responsibility organisation; Member States may mandate PRO appointment for certain categories (Art. 57(1)). - Portable battery collection targets: 45% by 31 Dec 2023, 63% by 31 Dec 2027, and 73% by 31 Dec 2030 (Art. 59(3)). - LMT battery collection targets: 51% by 31 Dec 2028 and 61% by 31 Dec 2031 (Art. 60(3)). ### Waste Battery Collection Targets - Portable batteries collection targets: 45% by 31 Dec 2023; 63% by 31 Dec 2027; 73% by 31 Dec 2030 (Art. 59(3)). - LMT batteries collection targets: 51% by 31 Dec 2028; 61% by 31 Dec 2031 (Art. 60(3)). - SLI, industrial and EV batteries: producers (or producer responsibility organisations) must take back and ensure separate collection, free of charge and without an obligation to buy a new battery (Art. 61(1)). - Collection systems must cover the whole territory of the Member State and may include collection points in cooperation with distributors, public authorities, and certain treatment facilities (Art. 59(2), Art. 60(2), Art. 61(1)-(2)). - Distributors have take-back obligations for waste batteries from end-users (Art. 62(1)-(3)). - Collection rates are calculated in accordance with Annex XI (Art. 59(3), Art. 60(3)). ### Recycling Efficiency and Material Recovery Targets - Disposal and energy recovery are prohibited for collected waste batteries (Art. 70(1)). - Treatment must comply, as a minimum, with Part A of Annex XII and best available techniques (Art. 70(2)). - Recycling efficiency targets (Part B of Annex XII): by 31 Dec 2025, lead-acid 75%, nickel-cadmium 80%, lithium-based 65%, other 50%; by 31 Dec 2030, lead-acid 80% and lithium-based 70%. - Material recovery targets (Part C of Annex XII): by 31 Dec 2027, cobalt/copper/lead/nickel 90% and lithium 50%; by 31 Dec 2031, cobalt/copper/lead/nickel 95% and lithium 80%. - Permitted facilities must accept waste batteries and ensure they undergo preparation for re-use, preparation for repurposing or recycling (Art. 71(1)). - Methodology and verification: the Commission must adopt a delegated act establishing calculation and verification methodology and documentation format (Art. 71(4)). - Shipments: exported waste batteries count towards targets only if the exporter provides approved evidence of equivalent treatment conditions (Art. 72(3)). ### Repurposing and Second Life - Definitions: preparation for repurposing (waste battery prepared for different purpose), repurposing (non-waste battery used for different purpose), and remanufacturing (restores capacity and keeps the same purpose) are defined in Art. 3(30)-(32). - Economic operators that place on the market or put into service batteries that have undergone these operations are treated as manufacturers (Art. 38(11)). - Conformity: an additional conformity assessment is required using Module A (Art. 17(3), Annex VIII). - Labelling and marking: batteries that have undergone these operations must bear new labels or markings and include change-of-status information accessible through the QR code (Art. 13(9)). - Waste batteries and ceasing-to-be-waste documentation: Article 73 sets documentation requirements for waste LMT/industrial/EV batteries prepared for re-use or prepared for repurposing and provides for an implementing act on detailed requirements for ceasing to be waste (Art. 73(1)-(4)). - Battery passport: a new battery passport is required and responsibility for accuracy transfers to the operator placing the battery on the market after the operation (Art. 77(7)). ### Economic Operator Obligations - Manufacturers: ensure compliance with applicable requirements, carry out conformity assessment, draw up EU declaration of conformity, affix CE marking, mark and label batteries, and keep documentation for 10 years (Art. 38(1)-(4)). - Authorised representatives: perform tasks specified in the written mandate (for example, keep documentation available and cooperate with authorities) (Art. 40). - Importers: verify that the manufacturer has carried out conformity assessment and drawn up documentation, ensure CE marking and required labelling, add importer contact details, and keep documentation available for 10 years (Art. 41). - Distributors: act with due care and verify key compliance elements (including producer registration, CE marking and labelling) before making batteries available (Art. 42). - Fulfilment service providers: ensure that warehousing/packaging/addressing/dispatching conditions do not jeopardise compliance (Art. 43). - Repurposing and similar operations: operators placing on the market or putting into service batteries that have been prepared for re-use/repurposing, repurposed or remanufactured are considered manufacturers (Art. 38(11), Art. 45). ### Market Surveillance and Enforcement - National procedure: where authorities believe a battery presents a risk, they evaluate compliance and can require corrective action, withdrawal or recall (Art. 79). - Union safeguard procedure: for restrictive measures, the Commission evaluates and can adopt an implementing act determining whether the national measure is justified (Art. 80). - Formal non-compliance: authorities can require operators to remedy certain administrative non-compliances (for example, missing CE marking or EU declaration of conformity) (Art. 83). - Due diligence non-compliance: authorities can require due diligence compliance, and can restrict or prohibit batteries if non-compliance persists and is serious (Art. 84). - Penalties: Member States establish effective, proportionate, dissuasive penalties; may include fines, product withdrawal, publication of infringement (Art. 93). - Online platforms: certain providers must obtain producer registration details and self-certification from producers offering batteries to consumers (Art. 62(6)). - Commission reviews: reports on Regulation application and impact every 5 years (Art. 94). ### Hazardous Substances Restrictions - Restrictions are set out under Article 6 and Annex I (Restriction on substances). - Mercury: batteries must not contain more than 0.0005% mercury by weight (Annex I). - Cadmium: portable batteries must not contain more than 0.002% cadmium by weight (Annex I). - Lead: from 18 Aug 2024, portable batteries must not contain more than 0.01% lead by weight; this restriction does not apply to portable zinc-air button cells until 18 Aug 2028 (Annex I). - Marking: batteries containing more than 0.002% cadmium or more than 0.004% lead must be marked with Cd or Pb beneath the separate collection symbol (Art. 13(5)). - The Commission can amend restrictions by delegated acts following a restriction dossier and assessment process (Art. 6(2)-(5)). ### Safety Requirements - Stationary battery energy storage systems placed on the market or put into service must be safe during normal operation and use (Art. 12(1)). - By 18 Aug 2024, technical documentation must demonstrate safety compliance and include evidence of successful testing for applicable safety parameters in Annex V, plus hazard assessment and mitigation instructions (Art. 12(2), Annex V). - If a battery is prepared for re-use, prepared for repurposing, remanufactured or repurposed, the technical documentation must be reviewed (Art. 12(2)). - Tests, measurements and calculations for certain requirements must use reliable, accurate and reproducible methods; harmonised standards and common specifications support presumption of conformity (Arts. 15-16). ### Reporting and Transparency Obligations - Reporting to competent authorities: producers (and certain other actors) must report specified data on batteries and waste batteries, including amounts made available, collected and treated, within six months of the end of the reporting year (Art. 75(1)-(7)). - Reporting to the Commission: Member States must make aggregated data publicly available and in the Commission format, and notify the Commission (Art. 76(1)-(5)). - Due diligence disclosure: economic operators in scope must draw up and make publicly available a due diligence report (Art. 52). - Battery passport accuracy: the operator placing the battery on the market must ensure passport information is accurate, complete and up to date (Art. 77(4)). - Formats: the Commission adopts implementing acts for the reporting format to the Commission (Art. 76(5)). ## Possible Outcomes ### [PORTABLE] Portable Battery Compliance Sealed, 5 kg or less, not industrial/EV/LMT/SLI - Category definition: portable batteries are defined in Art. 3(9). - Substance restrictions and labelling: restrictions are set out under Art. 6 and Annex I; labelling and marking requirements are in Art. 13. - Performance and durability: portable batteries of general use are subject to minimum performance and durability values under Art. 9 (with parameters in Annex III and delegated act timing). - Removability and replaceability: if you place products incorporating portable batteries on the market, Article 11 imposes removability/replaceability and related instructions and online information obligations (Art. 11; applies from 18 Feb 2027 via Art. 96(2)(a)). - Conformity and CE marking: manufacturers carry out conformity assessment and issue the EU declaration of conformity, and affix CE marking where required (Arts. 17-20, Art. 38). - EPR and collection targets: producers must register and fulfil extended producer responsibility obligations, including portable battery collection targets in Art. 59(3) (Arts. 55-62). - Carbon footprint requirements in Art. 7 apply to EV, LMT and rechargeable industrial batteries over 2 kWh, not portable batteries. ### [LMT] LMT Battery Compliance Sealed, 25 kg or less, traction for wheeled vehicles (not EV) - Category definition: LMT batteries are defined in Art. 3(11). - Carbon footprint: LMT batteries are in scope of Art. 7, with LMT-specific phased applicability dates (Art. 7(1)-(3)). - Performance and durability: LMT batteries must be accompanied by performance and durability parameter values from 18 Aug 2024, and minimum values apply from 18 Aug 2028 (or later depending on delegated act timing) (Art. 10(1) and Art. 10(3)). - Labelling and passport: separate collection symbol applies from 18 Aug 2025; QR code marking applies from 18 Feb 2027; and LMT batteries must have a battery passport from 18 Feb 2027 (Art. 13(4) and (6), Art. 77(1)). - Removability: products incorporating LMT batteries must ensure removability and replaceability by an independent professional, plus spare parts and software requirements (Art. 11(5)-(8); applies from 18 Feb 2027 via Art. 96(2)(a)). - EPR and collection targets: LMT collection targets are in Art. 60(3); distributors have take-back obligations under Art. 62 (Chapter VIII applies from 18 Aug 2025 via Art. 96(2)(c)). - Due diligence: if you place batteries on the market or put them into service and you are in scope (including the turnover threshold), due diligence obligations apply from 18 Aug 2025 (Arts. 47-52). - Conformity and CE marking: conformity assessment, EU declaration of conformity and CE marking requirements apply as relevant (Arts. 17-20, Annex VIII-IX, Art. 38). ### [SLI] SLI Battery Compliance Starting, Lighting, Ignition - Category definition: SLI batteries are defined in Art. 3(12). - Recycled content: SLI batteries containing cobalt, lead, lithium or nickel in active materials are subject to recycled content documentation from 18 Aug 2028 and minimum recycled content shares from 18 Aug 2031 (Art. 8(1)-(2)). - Labelling and QR code: separate collection symbol applies from 18 Aug 2025; QR code marking applies from 18 Feb 2027; and for SLI batteries the QR code provides access to recovered material information calculated in accordance with Art. 8 (Art. 13(4)-(6)). - Conformity and CE marking: conformity assessment, EU declaration of conformity and CE marking requirements apply as relevant (Arts. 17-20, Annex VIII-IX, Art. 38). - EPR and take-back: producers must take back and ensure separate collection of waste SLI batteries free of charge under Chapter VIII (Art. 61; Chapter VIII applies from 18 Aug 2025 via Art. 96(2)(c)). ### [EV] EV Battery Compliance Traction batteries for certain L, M, N, O vehicles - Category definition: EV batteries are defined in Art. 3(14). - Carbon footprint: EV batteries are in scope of Art. 7, with EV-specific phased applicability dates (Art. 7(1)-(3)). - Recycled content: EV batteries are in scope of Art. 8 recycled content documentation and targets (Art. 8(1)-(3)). - Performance and durability: EV batteries must be accompanied by performance and durability parameter values from 18 Aug 2024 (Art. 10(1)). - State of health and expected lifetime data: up-to-date parameters must be contained in the battery management system for EV batteries from 18 Aug 2024, with read-only access to purchasers and certain third parties (Art. 14). - Labelling and passport: separate collection symbol applies from 18 Aug 2025; QR code marking applies from 18 Feb 2027; and EV batteries must have a battery passport from 18 Feb 2027 (Art. 13(4) and (6), Art. 77(1)). - Due diligence: if you place batteries on the market or put them into service and you are in scope (including the turnover threshold), due diligence obligations apply from 18 Aug 2025 (Arts. 47-52). - EPR and take-back: producers must take back and ensure separate collection of waste EV batteries free of charge under Chapter VIII (Art. 61; Chapter VIII applies from 18 Aug 2025 via Art. 96(2)(c)). - Conformity and CE marking: conformity assessment, EU declaration of conformity and CE marking requirements apply as relevant (Arts. 17-20, Annex VIII-IX, Art. 38). ### [INDUSTRIAL] Industrial Battery Compliance For industrial activities, energy storage, or >5 kg - Category definition: industrial batteries are defined in Art. 3(13). - If rechargeable and over 2 kWh: carbon footprint requirements apply under Art. 7 (with later dates for exclusively external storage), performance and durability information applies under Art. 10, and battery passport applies from 18 Feb 2027 (Art. 77(1)). - Recycled content: industrial batteries over 2 kWh (except exclusively external storage) are in scope of Art. 8 recycled content documentation and targets (Art. 8(1)-(3)). - Stationary battery energy storage systems: safety requirements apply under Art. 12 and state of health and expected lifetime data requirements apply under Art. 14 (where applicable). - Labelling and QR code: separate collection symbol applies from 18 Aug 2025; general labels apply from 18 Aug 2026 (or later depending on implementing act timing); QR code marking applies from 18 Feb 2027 (Art. 13). - Due diligence: if you place batteries on the market or put them into service and you are in scope (including the turnover threshold), due diligence obligations apply from 18 Aug 2025 (Arts. 47-52). - EPR and take-back: producers must take back and ensure separate collection of waste industrial batteries free of charge under Chapter VIII (Art. 61; Chapter VIII applies from 18 Aug 2025 via Art. 96(2)(c)). - Conformity and CE marking: conformity assessment, EU declaration of conformity and CE marking requirements apply as relevant (Arts. 17-20, Annex VIII-IX, Art. 38). ### [OUT OF SCOPE] Not Subject to Batteries Regulation No batteries placed on EU market - If you do not place batteries on the EU market or put them into service, this Regulation does not apply. - Note: batteries incorporated into products (appliances, vehicles) are still covered when the product is placed on the market. - The Regulation also excludes certain batteries incorporated into equipment connected with essential security interests and equipment designed to be sent into space (Art. 1(5)). - Consider whether you may be indirectly affected via supply chain requirements from EU customers. ## EU Batteries Regulation Timeline | Date | Event | Reference | | --- | --- | --- | | 2023-07-12 | Regulation adopted | Reg. (EU) 2023/1542 | | 2023-07-28 | Published in Official Journal (OJ L 191) | Reg. (EU) 2023/1542 | | 2023-08-17 | Entry into force (20 days after publication) | Art. 96(1) | | 2024-02-18 | General application date (with phased provisions) | Art. 96(2) | | 2024-08-18 | Article 17 and Chapter VI apply (conformity and economic operator obligations) | Art. 96(2)(b) | | 2025-02-18 | Commission deadline to publish due diligence guidelines | Art. 48(5) | | 2025-08-18 | Directive 2006/66/EC repealed; Chapter VIII (waste batteries) applies; due diligence obligations start | Art. 95, Art. 96(2)(c), Art. 48(1) | | 2025-08-18 | Separate collection symbol marking applies | Art. 13(4) | | 2026-08-18 | General labelling and capacity labels apply (earliest) | Art. 13(1)-(3) | | 2027-02-18 | QR code marking and battery passport start; removability applies | Art. 13(6), Art. 77(1), Art. 11 (via Art. 96(2)(a)) | | 2028-08-18 | Recycled content documentation starts (industrial, EV, SLI; LMT later) | Art. 8(1) | | 2031-08-18 | Mandatory minimum recycled content targets start (industrial, EV, SLI; LMT later) | Art. 8(2) | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2006-09-06 | Batteries Directive (2006/66/EC) adopted | Legislative Milestones | | | 2006-09-26 | Batteries Directive (2006/66/EC) published in the Official Journal (OJ L 266) | Legislative Milestones | | | 2023-07-12 | EU Batteries Regulation (EU) 2023/1542 adopted | Legislative Milestones | | | 2023-07-28 | EU Batteries Regulation published in the Official Journal | Legislative Milestones | | | 2023-08-17 | EU Batteries Regulation enters into force | Legislative Milestones | | | 2024-02-18 | EU Batteries Regulation applies (general application date) | Legislative Milestones | | | 2024-04-17 | Corrigendum published (EU Batteries Regulation) | Legislative Milestones | | | 2024-08-18 | Article 17 and Chapter VI apply | Legislative Milestones | | | 2025-02-18 | Carbon footprint declaration starts (earliest) for EV batteries | Carbon Footprint | | | 2025-07-04 | Commission news: Delegated Regulation (EU) 2025/606 on recycling efficiency and material recovery | Recycling & Recovery | | | 2025-07-24 | Recycling methodology enters into force | Recycling & Recovery | | | 2025-08-18 | Chapter VIII applies | Legislative Milestones | | | 2025-10-08 | Corrigendum published (EU Batteries Regulation) | Legislative Milestones | | | 2025-11-19 | Commission technical support report published | Legislative Milestones | | | 2025-12-31 | Recycling efficiency targets due (Annex XII) | Recycling & Recovery | | | 2026-02-18 | Carbon footprint declaration starts (earliest) for rechargeable industrial batteries | Carbon Footprint | | | 2026-08-18 | Carbon footprint performance class labelling starts (earliest) for EV batteries | Carbon Footprint | | | 2027-02-18 | Article 11 applies | Legislative Milestones | | | 2027-02-18 | Battery passport requirement starts | Battery Passport | | | 2027-12-31 | Material recovery targets start (Annex XII) | Recycling & Recovery | | | 2028-02-18 | Maximum life cycle carbon footprint threshold starts (earliest) for EV batteries | Carbon Footprint | | | 2028-08-18 | Carbon footprint declaration starts (earliest) for LMT batteries | Carbon Footprint | | | 2028-08-18 | Recycled content disclosure documentation starts (industrial, EV, SLI) | Recycled Content | | | 2029-02-18 | Maximum life cycle carbon footprint threshold starts (earliest) for rechargeable industrial batteries | Carbon Footprint | | | 2030-02-18 | Carbon footprint performance class labelling starts (earliest) for LMT batteries | Carbon Footprint | | | 2030-08-18 | Carbon footprint declaration starts (earliest) for rechargeable industrial batteries with external storage | Carbon Footprint | | | 2030-12-31 | Increased recycling efficiency targets due (Annex XII) | Recycling & Recovery | | | 2031-08-18 | Maximum life cycle carbon footprint threshold starts (earliest) for LMT batteries | Carbon Footprint | | | 2031-08-18 | Mandatory minimum recycled content targets start (industrial, EV, SLI) | Recycled Content | | | 2031-12-31 | Increased material recovery targets due (Annex XII) | Recycling & Recovery | | | 2032-02-18 | Carbon footprint performance class labelling starts (earliest) for rechargeable industrial batteries with external storage | Carbon Footprint | | | 2033-08-18 | Maximum life cycle carbon footprint threshold starts (earliest) for rechargeable industrial batteries with external storage | Carbon Footprint | | | 2033-08-18 | Recycled content disclosure documentation starts (LMT batteries) | Recycled Content | | | 2036-08-18 | Increased mandatory recycled content targets start | Recycled Content | | **Event details:** - **2006-09-06 - Batteries Directive (2006/66/EC) adopted**: Date of Directive 2006/66/EC of the European Parliament and of the Council: 6 September 2006. - **2006-09-26 - Batteries Directive (2006/66/EC) published in the Official Journal (OJ L 266)**: Official Journal reference for Directive 2006/66/EC: OJ L 266, 26.9.2006, p. 1. - **2023-07-12 - EU Batteries Regulation (EU) 2023/1542 adopted**: Date of the Regulation: of 12 July 2023. - **2023-07-28 - EU Batteries Regulation published in the Official Journal**: Official Journal of the European Union date: 28.7.2023. - **2023-08-17 - EU Batteries Regulation enters into force**: Entry into force: 20 days after publication in the Official Journal (published 28 July 2023). - **2024-02-18 - EU Batteries Regulation applies (general application date)**: General application date: 18 February 2024 (with specific phased provisions). - **2024-04-17 - Corrigendum published (EU Batteries Regulation)**: Corrigendum dated 17 April 2024 (Official Journal corrigendum entry for Regulation (EU) 2023/1542). - **2024-08-18 - Article 17 and Chapter VI apply**: From 18 August 2024, Article 17 and Chapter VI apply (per phased application rules). - **2025-02-18 - Carbon footprint declaration starts (earliest) for EV batteries**: Earliest: 18 February 2025 for EV batteries (or later depending on delegated and implementing acts). - **2025-07-04 - Commission news: Delegated Regulation (EU) 2025/606 on recycling efficiency and material recovery**: 4 July 2025: Commission news announcing Delegated Regulation (EU) 2025/606 on calculating and verifying recycling efficiency and recovery of materials from waste batteries. - **2025-07-24 - Recycling methodology enters into force**: The newly established methodology will enter into force on 24 July 2025. - **2025-08-18 - Chapter VIII applies**: From 18 August 2025, Chapter VIII applies (per phased application rules). - **2025-10-08 - Corrigendum published (EU Batteries Regulation)**: Corrigendum dated 8 October 2025 (Official Journal corrigendum entry for Regulation (EU) 2023/1542). - **2025-11-19 - Commission technical support report published**: General publications: 19 November 2025 (Task 1 Report - technical support for delegated acts and Commission reports). - **2025-12-31 - Recycling efficiency targets due (Annex XII)**: No later than 31 December 2025, recycling efficiency targets apply: 75% lead-acid, 65% lithium-based, 80% nickel-cadmium, 50% other waste batteries. - **2026-02-18 - Carbon footprint declaration starts (earliest) for rechargeable industrial batteries**: Earliest: 18 February 2026 for rechargeable industrial batteries (except those with exclusively external storage), or later depending on delegated and implementing acts. - **2026-08-18 - Carbon footprint performance class labelling starts (earliest) for EV batteries**: Earliest: 18 August 2026 for EV batteries, or later depending on delegated and implementing acts. - **2027-02-18 - Article 11 applies**: From 18 February 2027, Article 11 applies (per phased application rules). - **2027-02-18 - Battery passport requirement starts**: From 18 February 2027, each LMT battery, each industrial battery over 2 kWh, and each EV battery must have a battery passport. - **2027-12-31 - Material recovery targets start (Annex XII)**: No later than 31 December 2027, recovery targets apply: 90% cobalt/copper/lead/nickel and 50% lithium. - **2028-02-18 - Maximum life cycle carbon footprint threshold starts (earliest) for EV batteries**: Earliest: 18 February 2028 for EV batteries, or later depending on delegated acts setting thresholds. - **2028-08-18 - Carbon footprint declaration starts (earliest) for LMT batteries**: Earliest: 18 August 2028 for LMT batteries, or later depending on delegated and implementing acts. - **2028-08-18 - Recycled content disclosure documentation starts (industrial, EV, SLI)**: From 18 August 2028, industrial batteries over 2 kWh (except exclusively external storage), EV batteries and SLI batteries must be accompanied by recycled content share documentation (for cobalt, lead, lithium, nickel in active materials). - **2029-02-18 - Maximum life cycle carbon footprint threshold starts (earliest) for rechargeable industrial batteries**: Earliest: 18 February 2029 for rechargeable industrial batteries (except exclusively external storage), or later depending on delegated acts setting thresholds. - **2030-02-18 - Carbon footprint performance class labelling starts (earliest) for LMT batteries**: Earliest: 18 February 2030 for LMT batteries, or later depending on delegated and implementing acts. - **2030-08-18 - Carbon footprint declaration starts (earliest) for rechargeable industrial batteries with external storage**: Earliest: 18 August 2030 for rechargeable industrial batteries with external storage, or later depending on delegated and implementing acts. - **2030-12-31 - Increased recycling efficiency targets due (Annex XII)**: No later than 31 December 2030, recycling efficiency targets increase to 80% lead-acid and 70% lithium-based. - **2031-08-18 - Maximum life cycle carbon footprint threshold starts (earliest) for LMT batteries**: Earliest: 18 August 2031 for LMT batteries, or later depending on delegated acts setting thresholds. - **2031-08-18 - Mandatory minimum recycled content targets start (industrial, EV, SLI)**: From 18 August 2031, batteries in scope must meet minimum recycled content shares in active materials (including cobalt, lead, lithium, nickel) as part of technical documentation. - **2031-12-31 - Increased material recovery targets due (Annex XII)**: No later than 31 December 2031, recovery targets increase to 95% cobalt/copper/lead/nickel and 80% lithium. - **2032-02-18 - Carbon footprint performance class labelling starts (earliest) for rechargeable industrial batteries with external storage**: Earliest: 18 February 2032 for rechargeable industrial batteries with external storage, or later depending on delegated and implementing acts. - **2033-08-18 - Maximum life cycle carbon footprint threshold starts (earliest) for rechargeable industrial batteries with external storage**: Earliest: 18 August 2033 for rechargeable industrial batteries with external storage, or later depending on delegated acts setting thresholds. - **2033-08-18 - Recycled content disclosure documentation starts (LMT batteries)**: From 18 August 2033, LMT batteries in scope must be accompanied by recycled content share documentation (for cobalt, lead, lithium, nickel in active materials). - **2036-08-18 - Increased mandatory recycled content targets start**: From 18 August 2036, increased minimum recycled content shares apply (including higher cobalt, lithium, and nickel targets). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/batteries-regulation --- --- title: "EU CSDDD Timeline, Scope Decision Flow, and Implementation Guides" canonical_url: "https://www.sorena.io/artifacts/eu/csddd" source_url: "https://www.sorena.io/artifacts/eu/corporate-sustainability-due-diligence-directive" author: "Sorena AI" description: "Use this CSDDD hub to confirm scope under Directive (EU) 2024/1760, apply the 2025 timing amendment correctly." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU CSDDD" - "Directive (EU) 2024/1760" - "CS3D" - "corporate sustainability due diligence" - "chain of activities" - "human rights due diligence" - "environmental due diligence" - "CSDDD applicability" - "CSDDD deadlines" - "CSDDD complaints procedure" - "CSDDD remediation" - "CSDDD penalties" - "CSDDD climate transition plan" - "Due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Timeline, Scope Decision Flow, and Implementation Guides Use this CSDDD hub to confirm scope under Directive (EU) 2024/1760, apply the 2025 timing amendment correctly. ![EU CSDDD artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-csddd-timeline-small.jpg?v=cheatsheets%2Fprod) *EU CSDDD* *Free Resource* ## EU CSDDD Timeline, scope decision flow and practical guides Use this artifact to determine whether Directive (EU) 2024/1760 applies, identify the correct application wave after the 2025 timing amendment, and turn the due diligence duty into an operating model across policies, mapping, prioritization, action plans, remedy, complaints, monitoring, and annual communication. The core dates are now different from many summaries on the web. The Directive entered into force on 25 July 2024. Directive (EU) 2025/794 moved the transposition deadline to 26 July 2027 and moved the first application wave to 26 July 2028, with broader application from 26 July 2029. [Plan due diligence](/contact.md) ## What you can decide faster - **Scope and start date**: Test thresholds, group structure, franchising rules, and non-EU turnover before you launch the program. - **Operational perimeter**: Map upstream and downstream chain-of-activities boundaries so supplier work and complaints routing are grounded. - **Evidence design**: Build the records, annual statement logic, and climate transition plan outputs supervisory authorities will expect. By Sorena AI | Updated 2026 | No signup required ### Quick scan *CSDDD* - **Scope test**: Check the 1000 employee and EUR 450 million threshold, franchising trigger, and non-EU EU-turnover route. - **Due diligence flow**: Move from Article 7 policy to Article 15 monitoring and Article 16 communication without losing traceability. - **Enforcement path**: Prepare for supervisory review, substantiated concerns, penalties, and civil liability risk. Use the decision flow first, then open the page specific guides for scope, chain of activities, complaints, penalties, and transition planning. | Value | Metric | | --- | --- | | 25 Jul 2024 | In force | | 26 Jul 2027 | Transposition | | 26 Jul 2028 | First wave | | 26 Jul 2029 | Broader scope | **Key highlights:** Scope and timing | Chain of activities | Complaints and remedy ## Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/corporate-sustainability-due-diligence-directive/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/corporate-sustainability-due-diligence-directive/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/corporate-sustainability-due-diligence-directive/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/corporate-sustainability-due-diligence-directive/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/corporate-sustainability-due-diligence-directive/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/corporate-sustainability-due-diligence-directive/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/corporate-sustainability-due-diligence-directive/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/corporate-sustainability-due-diligence-directive/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/corporate-sustainability-due-diligence-directive/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/corporate-sustainability-due-diligence-directive/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/corporate-sustainability-due-diligence-directive/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/corporate-sustainability-due-diligence-directive/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/corporate-sustainability-due-diligence-directive/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/corporate-sustainability-due-diligence-directive/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/corporate-sustainability-due-diligence-directive/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/corporate-sustainability-due-diligence-directive/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. ## Key dates for scope, transposition, and rollout *CSDDD Timeline* Track the current legal timing, including the 2025 amendment that postponed transposition and the first application wave, so procurement, legal, ESG, and risk teams work from the same calendar. ## Does CSDDD apply and what must you build first *CSDDD Decision Flow* Follow the scope logic to test thresholds, group structure, non-EU turnover, and franchising triggers, then route the result into due diligence workstreams and evidence requirements. *Next step* ## Turn EU CSDDD Timeline, scope decision flow and practical guides into an ESG delivery workflow EU CSDDD Timeline, scope decision flow and practical guides should be the shared entry point for your team. Route execution into ESG Compliance for live work and into Assessment Autopilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU CSDDD Timeline, scope decision flow and practical guides and route the work by entity, product, team, or control owner. - Use ESG Compliance to manage cross team sustainability work, reporting, and evidence from one workflow. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open ESG Compliance](/solutions/esg-compliance.md): Manage cross team sustainability work, reporting, and evidence from one workflow for EU CSDDD Timeline, scope decision flow and practical guides. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints from the same artifact. - **Download decision flow**: Share scope logic with legal, procurement, and ESG. - **Download timeline**: Coordinate transposition and application planning. - [Talk through EU CSDDD Timeline, scope decision flow and practical guides](/contact.md): Review your current process, evidence model, and next steps for EU CSDDD Timeline, scope decision flow and practical guides. ## Decision Steps ### STEP 1: Are you an EU company, or a non-EU company with significant EU turnover? *Reference: Art. 2* - CSDDD applies to certain EU companies (formed under Member State law) and certain third-country companies based on EU turnover. - Scope depends on the thresholds and criteria in Art. 2(1)-(2), including ultimate parent companies and certain franchising or licensing arrangements. - **YES** Are you an AIF or a UCITS? - **NO** Not Directly Subject to CSDDD ### STEP 2: Are you an AIF or a UCITS? *Reference: Art. 2(8)* - If yes: the Directive does not apply to AIFs or UCITS (Art. 2(8)). - If no: continue to determine whether you are an EU company or a third-country company and whether you meet the relevant thresholds. - **YES** Not Directly Subject to CSDDD - **NO** Are you a company formed under the law of a Member State (an EU company)? ### STEP 3: Are you a company formed under the law of a Member State (an EU company)? *Reference: Art. 2(1) & 2(2)* - If yes: follow the EU company scope thresholds in Art. 2(1). - If no: you may be a third-country company in scope based on EU turnover thresholds in Art. 2(2). - Ultimate parent companies of groups can be in scope and may have group-level obligations (Art. 2(1)(b), Art. 2(2)(b)). - **YES** Does your EU company meet one of the following criteria? - **NO** Does your third-country company meet one of the following criteria? ### STEP 4: Does your EU company meet one of the following criteria? *Reference: Art. 2(1)* - (a) More than 1,000 employees on average and more than EUR 450,000,000 net worldwide turnover in the last financial year (Art. 2(1)(a)); or - (b) Ultimate parent company of a group that reached the Art. 2(1)(a) thresholds on a consolidated basis (Art. 2(1)(b)); or - (c) Franchising or licensing in the EU with royalties >EUR 22,500,000 and net worldwide turnover >EUR 80,000,000 (including ultimate parent groups) (Art. 2(1)(c)). - Two-year rule: the conditions in Art. 2(1) must be met for two consecutive financial years (Art. 2(5)). - Employee counting: part-time employees on a full-time equivalent basis; include temporary agency workers and other non-standard workers meeting CJEU worker criteria (Art. 2(4)). - If you are in scope, when national measures apply depends on phase-in rules in Art. 37. - **YES** EU Company Within CSDDD Scope - **NO** Not Directly Subject to CSDDD ### STEP 4: Does your third-country company meet one of the following criteria? *Reference: Art. 2(2)* - (a) Net turnover >EUR 450m in the EU in the financial year preceding the last financial year; OR - (b) Ultimate parent of a group that (on a consolidated basis) meets (a) in the financial year preceding the last financial year; OR - (c) Franchises/licenses in the EU with >EUR 22.5m royalties AND >EUR 80m net turnover in the EU in the financial year preceding the last financial year (including ultimate parent groups). - Threshold conditions must be met for two consecutive financial years to be in scope (Art. 2(5)). - When you must apply depends on phasing (Art. 37): very large third-country companies apply earlier (26 July 2027/2028); otherwise obligations apply from 26 July 2029. - Third-country companies must designate an authorised representative in the EU (Art. 23). - No employee threshold applies for third-country companies (Art. 2(2)). - **YES** Third-Country Company Within CSDDD Scope - **NO** Not Directly Subject to CSDDD ## Reference Information ### Companies In Scope (Overview) - EU companies: >1,000 employees on average and >EUR 450m net worldwide turnover in the last financial year (Art. 2(1)(a)) - EU ultimate parent companies: in scope if the group reached the Art. 2(1)(a) thresholds on a consolidated basis (Art. 2(1)(b)) - EU franchising or licensing: royalties >EUR 22.5m and net worldwide turnover >EUR 80m (including ultimate parent groups) (Art. 2(1)(c)) - Third-country companies: EU net turnover >EUR 450m in the financial year preceding the last financial year (Art. 2(2)(a)) - Third-country ultimate parent companies: in scope if the group reached the Art. 2(2)(a) threshold on a consolidated basis (Art. 2(2)(b)) - Third-country franchising or licensing: EU royalties >EUR 22.5m and EU net turnover >EUR 80m (including ultimate parent groups) (Art. 2(2)(c)) - Two-year rule: thresholds must be met for two consecutive financial years; CSDDD stops applying if the conditions cease to be met for each of the last two relevant financial years (Art. 2(5)) - Employee counting: part-time employees on a full-time equivalent basis; include temporary agency workers and other non-standard workers meeting CJEU worker criteria (Art. 2(4)) - Holding-parent exemption: an ultimate parent company may be exempt if it is a pure holding and designates an EU subsidiary to fulfil obligations, subject to supervisory approval and joint liability (Art. 2(3)) ### Holding Parent Exemption (Optional) - An ultimate parent company may be exempt if its main activity is holding shares in operational subsidiaries and it does not take management, operational or financial decisions affecting the group or one or more subsidiaries (Art. 2(3)). - The exemption requires designating a subsidiary established in the EU to fulfil the obligations in Arts. 6-16 and Art. 22 on behalf of the ultimate parent, including for the group's subsidiaries (Art. 2(3)). - The ultimate parent must apply to the competent supervisory authority for the exemption; the authority assesses conditions and grants it if met (Art. 2(3), Art. 24). - The ultimate parent remains jointly liable with the designated subsidiary for the latter's failures to comply (Art. 2(3)). ### Key Exclusions - The Directive does not apply to AIFs or UCITS (Art. 2(8)). - The Directive does not apply to pension institutions operating social security systems under Union law (Recital 18). - Where a Member State has chosen not to apply Directive (EU) 2016/2341 in whole or in part to an institution for occupational retirement provision (IORP), the Directive does not apply to those IORPs (Recital 18). ### Chain of Activities - Upstream: activities of direct and indirect business partners related to production of goods or provision of services (design, extraction, sourcing, manufacture, transport, storage, supply of raw materials/products/parts, development of product/service) - Downstream: activities of business partners related to distribution, transport and storage of the product, where partners carry out those activities for or on behalf of the company - Does NOT include: disposal of the product (Recital 25); distribution, transport or storage of export-controlled products after authorisation (Art. 3(1)(g)(ii)); and activities of downstream business partners related to the services of the company (Recital 26) - For regulated financial undertakings, only the upstream part of the chain of activities is covered (Recital 26) ### Six Steps of Due Diligence - 1. Integrate due diligence into policies and risk management systems (Art. 7) - 2. Identify and assess actual/potential adverse impacts (Art. 8); prioritise where necessary (Art. 9) - 3. Prevent, cease or minimise actual and potential adverse impacts (Art. 10-11) - 4. Monitor and assess effectiveness (Art. 15) - 5. Communicate publicly (Art. 16) - 6. Provide remediation (Art. 12) - Due diligence obligations are obligations of means: take appropriate measures commensurate to the severity and likelihood of impacts, but you cannot guarantee all impacts are prevented (Recital 19) ### Step 1: Integrate Due Diligence into Policies - Adopt a due diligence policy describing approach, code of conduct, and implementation processes (Art. 7(2)) - Develop the policy in prior consultation with employees and their representatives - Update the policy after significant changes and review at least every 24 months (Art. 7(3)) - The code of conduct must apply throughout the company, subsidiaries, and direct/indirect business partners - Describe how you will verify compliance with the code of conduct and extend it to business partners ### Step 2: Identify and Assess Adverse Impacts - Map your own operations, subsidiaries, and (where related to chains of activities) business partners to identify general areas where adverse impacts are most likely and most severe (Art. 8(2)(a)) - Carry out in-depth assessment in the areas identified as high-risk (Art. 8(2)(b)) - Consider relevant risk factors: company-level, business operations, geographic and contextual, product and service, and sectoral factors - Use quantitative and qualitative information, independent reports, and stakeholder notifications/complaints (Art. 8(3)) - Prioritise based on severity and likelihood if not feasible to address all impacts at once (Art. 9) ### Step 3: Prevent/Mitigate Potential Impacts & Bring Actual Impacts to an End - Take appropriate measures to prevent/mitigate potential impacts (Art. 10) and bring actual impacts to an end or minimise their extent (Art. 11) - Appropriate measures include: prevention/corrective action plans; contractual assurances from direct and indirect business partners; investments/upgrades; modifications to business plan/purchasing practices; targeted support to SME partners; collaboration with other entities - Where impacts cannot be prevented/ended, seek enhanced action plans; as a last resort, temporarily suspend or terminate the business relationship if the adverse impact is severe (Art. 10(6), 11(7)) - Before termination, assess whether the adverse impacts of termination would be manifestly more severe than the impact you are trying to address - Member States must provide an option to suspend/terminate in contracts governed by their laws (except for mandatory contracts) ### Step 6: Provide Remediation - If you caused or jointly caused an actual adverse impact, you must provide remediation (Art. 12(1)) - Remediation means restoring affected persons, communities or environment to a situation equivalent or as close as possible to the situation before the impact occurred - Remediation can be financial or non-financial compensation, and may include reimbursement of costs to public authorities for remedial measures - If the impact is caused only by a business partner, you may provide voluntary remediation or use your influence to encourage the partner to remediate (Art. 12(2)) ### Meaningful Engagement with Stakeholders - Stakeholders include: employees, trade unions, workers' representatives, consumers, communities affected by your operations/products, civil society organisations, national human rights/environmental institutions, and legitimate representatives of affected individuals - Consult stakeholders when: gathering information on impacts (Art. 8-9); developing action plans (Art. 10-11); deciding to suspend/terminate business relationships; adopting remediation measures (Art. 12); developing monitoring indicators (Art. 15) - Provide stakeholders with relevant and comprehensive information; address barriers to engagement; protect participants from retaliation (Art. 13(5)) - Where effective engagement is not reasonably possible, consult experts who can provide credible insights (Art. 13(4)) - Engagement with employees and their representatives must respect Union and national employment/social rights laws and collective agreements (Art. 13(7)) ### Notification Mechanism & Complaints Procedure - Establish a fair, publicly available, accessible, predictable and transparent complaints procedure (Art. 14(3)) - Complaints may be submitted by: affected persons and their representatives (including civil society); trade unions and workers' representatives; civil society organisations active in related areas (for environmental impacts) - Inform relevant workers' representatives and trade unions of the procedure - Prevent retaliation by ensuring confidentiality of complainant identity; do not disclose identity where it would endanger safety - Where a complaint is well-founded, the adverse impact is deemed identified and you must take appropriate measures (Art. 10-12) - Complainants are entitled to: request follow-up; meet company representatives; receive reasons for founded/unfounded determination and information on steps taken - Establish a notification mechanism for persons/entities with information or concerns about actual/potential impacts (Art. 14(5)); notifications can be anonymous or confidential - You may use collaborative complaints/notification mechanisms (e.g., industry initiatives) if they meet CSDDD requirements (Art. 14(6)) ### Step 4: Monitor Effectiveness - Carry out periodic assessments of your own operations, subsidiaries, and business partners (where related to chain of activities) (Art. 15) - Assess the implementation and effectiveness of identification, prevention, mitigation, ending and minimisation of adverse impacts - Use qualitative and quantitative indicators where appropriate - Conduct assessments without undue delay after significant changes, but at least every 12 months - Update your due diligence policy, identified impacts and appropriate measures based on assessment outcomes and stakeholder input ### Step 5: Publicly Communicate - Publish an annual statement on your website covering due diligence matters (Art. 16(1)) - Publish in at least one official language of the Member State of your supervisory authority and in a language customary in international business - Publish within 12 months of the balance sheet date, or by the date of annual financial statement publication (for voluntary reporters under Directive 2013/34/EU) - Third-country companies: include information on your authorised representative in the statement - Exemption: companies subject to sustainability reporting under Article 19a, 29a or 40a of Directive 2013/34/EU do not need to publish a separate annual statement (Art. 16(2)) - From 1 January 2029: submit the annual statement to the EU single access point (ESAP) in a data extractable format with required metadata (Art. 17) ### Climate Transition Plan for Climate Change Mitigation - In-scope companies referred to in Art. 2(1)(a)-(c) and Art. 2(2)(a)-(c) must adopt and put into effect a transition plan for climate change mitigation (Art. 22(1)). - The plan must aim to ensure the business model and strategy are compatible with the transition to a sustainable economy and limiting global warming to 1.5 degrees C (Paris Agreement) and achieving climate neutrality (Regulation (EU) 2021/1119). - Plan must contain: (a) time-bound targets for 2030 and in five-year steps up to 2050, with absolute emission reduction targets for Scope 1, 2 and 3 GHG emissions where appropriate; (b) decarbonisation levers and key actions (including product/service portfolio changes and new technologies); (c) investments and funding supporting the plan; (d) role of administrative/management/supervisory bodies - Update the plan every 12 months with a description of progress towards targets (Art. 22(3)) - Companies already reporting a transition plan under Article 19a, 29a or 40a of Directive 2013/34/EU are deemed compliant (Art. 22(2)) ### Group-Level Due Diligence - Parent companies may fulfil due diligence obligations (Art. 7-11, 22) on behalf of in-scope subsidiaries if this ensures effective compliance (Art. 6) - Subsidiaries remain subject to supervisory authority powers and civil liability even when the parent fulfils obligations on their behalf - Conditions: subsidiary and parent cooperate and exchange information; subsidiary abides by parent's adapted due diligence policy; subsidiary integrates due diligence into its policies; subsidiary continues appropriate measures under Art. 10-13 where necessary; subsidiary seeks contractual assurances and may suspend/terminate relationships as needed - Companies may share resources and information within groups and with other legal entities to carry out due diligence (Art. 5(2)) ### Support for SMEs - In-scope companies must provide targeted and proportionate support to SME business partners, including: capacity-building, training, management system upgrades, and (where compliance would jeopardise viability) financial support (direct financing, loans, guarantees, sourcing assistance) (Art. 10(2)(e), 11(3)(f)) - When obtaining contractual assurances from SMEs, terms must be fair, reasonable and non-discriminatory (Art. 10(5), 11(6)) - In-scope companies must bear the cost of independent third-party verification for SMEs (Art. 10(5), 11(6)) - Member States may financially support SMEs and stakeholders (Art. 20(2)) - Member States must set up dedicated websites/platforms/portals with information and support, with specific consideration for SMEs in value chains (Art. 20(1)) ### Supervisory Authorities & Enforcement - Each Member State designates one or more supervisory authorities to supervise compliance (Art. 24) - Competent authority for EU companies: the Member State where the company has its registered office - Competent authority for third-country companies: the Member State where the company has a branch; if no branch or multiple branches, the Member State where the company generated most of its EU turnover - Supervisory authorities must be independent, free from external influence and conflicts of interest (Art. 24(9)) - Powers include: requiring information; carrying out investigations; ordering companies to cease infringements/refrain from repetition/provide remediation; imposing penalties; adopting interim measures for imminent risk of severe harm (Art. 25) - European Network of Supervisory Authorities facilitates cooperation, coordination and information sharing (Art. 28) ### Substantiated Concerns - Natural and legal persons may submit substantiated concerns to any supervisory authority if they have reasons to believe (on the basis of objective circumstances) that a company is failing to comply with CSDDD (Art. 26) - Supervisory authorities must protect the identity and personal information of persons submitting concerns, where disclosure would be harmful - Supervisory authorities must assess substantiated concerns and, where appropriate, exercise their powers (Art. 26(4)) - Supervisory authorities must inform submitters of the result and reasoning, and (for persons with legitimate interest) the decision to accept/refuse the request for action and next steps - Persons with legitimate interest have access to a court or other independent body to review the supervisory authority's decision (Art. 26(6)) ### Penalties & Publication - Member States must lay down rules on penalties (including pecuniary penalties) that are effective, proportionate and dissuasive (Art. 27(1)) - Pecuniary penalties based on net worldwide turnover; maximum limit must be not less than 5% of net worldwide turnover in the financial year preceding the decision (Art. 27(4)) - For ultimate parent companies of groups, pecuniary penalties are calculated using the consolidated turnover (Art. 27(4)) - When deciding on penalties, authorities must consider: nature/gravity/duration of infringement; severity of impacts; investments/support provided; collaboration with others; prioritisation decisions; previous infringements; remedial action; financial benefits gained; aggravating/mitigating factors (Art. 27(2)) - Decisions on penalties must be published, remain publicly available for at least five years, and be sent to the European Network of Supervisory Authorities (Art. 27(5)) ### Civil Liability & Right to Full Compensation - A company can be held liable for damage if: (a) it intentionally or negligently failed to comply with obligations in Art. 10 or 11, and the right/prohibition/obligation in the Annex was aimed at protecting the natural/legal person; and (b) as a result, damage to the person's legal interests (protected under national law) was caused (Art. 29(1)) - A company cannot be held liable if the damage was caused only by its business partners in the chain of activities (Art. 29(1)) - Affected persons have the right to full compensation (not overcompensation) (Art. 29(2)) - Limitation period for damages actions: at least 5 years, not shorter than national general civil liability regime; does not begin until infringement ceases and claimant knows of behaviour, harm and infringer identity (Art. 29(3)(a)) - Claimants may seek injunctive measures (including through summary proceedings) (Art. 29(3)(c)) - Trade unions, NGOs, human rights/environmental organisations and national human rights institutions may bring actions on behalf of alleged injured parties (Art. 29(3)(d)) - Courts may order disclosure of evidence in the company's control where claimant presents reasoned justification (Art. 29(3)(e)) - Participation in industry initiatives or use of third-party verification does not prevent liability (Art. 29(4)) - Joint and several liability where damage was caused jointly by company and subsidiary/business partner (Art. 29(5)) ### Industry & Multi-Stakeholder Initiatives - Companies may participate in industry or multi-stakeholder initiatives to support implementation of due diligence obligations (Art. 20(4)) - Initiatives can include: voluntary due diligence procedures, tools, mechanisms developed and overseen by governments, industry associations, civil society organisations or combinations - Companies may use or join relevant risk analysis carried out by such initiatives, and may take/join effective appropriate measures through them - When using initiatives, companies must monitor effectiveness and continue to take appropriate measures to ensure fulfilment of obligations - The Commission (with Member States) shall issue guidance on fitness criteria and methodology for assessing the fitness of industry and multi-stakeholder initiatives (Art. 20(4)) - Companies may fulfil stakeholder engagement, notification and complaints obligations through collaborative mechanisms (if they meet CSDDD requirements) (Art. 13(6), 14(6)) ### Independent Third-Party Verification - Companies may use independent third-party verification to support implementation of due diligence obligations (Art. 20(5)) - Independent verifiers must: act with objectivity and complete independence; be free from conflicts of interest and external influence; have experience and competence in environmental or human rights matters; be accountable for quality and reliability - Verification may be carried out by other companies or by industry/multi-stakeholder initiatives - The Commission (with Member States) shall issue guidance on: fitness criteria and methodology for assessing the fitness of third-party verifiers; monitoring the accuracy, effectiveness and integrity of third-party verification (Art. 20(5)) - For SME partners, in-scope companies must bear the cost of independent third-party verification (Art. 10(5), 11(6)) ### Commission Guidelines & Support - The Commission will issue guidelines to support companies, Member State authorities and stakeholders (Art. 19) - Guidelines include: general and sector-specific guidance; guidance on identification, prioritisation, purchasing practices, responsible disengagement, remediation, stakeholder engagement; practical guidance on transition plans; risk factors assessment; data sources and digital tools; info sharing; stakeholder engagement - Available by 26 January 2027: general guidelines, risk factors, data sources (Art. 19(3)) - Available by 26 July 2027: transition plans, info sharing, stakeholder engagement (Art. 19(3)) - Model contractual clauses available by 26 January 2027 (Art. 18) - Single helpdesk established by the Commission to provide information, guidance and support (Art. 21) ### Adverse Human Rights Impacts Covered - CSDDD covers abuse of rights enshrined in international instruments listed in the Annex, including: right to life; prohibition of torture/cruel treatment; right to liberty and security; freedom of thought/conscience/religion; just and favourable working conditions (including living wage/income); adequate housing/food/water/sanitation; child rights (health, education, adequate standard of living, protection from exploitation/abuse); prohibition of child labour and worst forms of child labour; prohibition of forced labour and slavery; freedom of association and collective bargaining; prohibition of unequal treatment in employment - Also covers abuse of human rights not specifically listed in the Annex but enshrined in the listed instruments, provided: the right can be abused by a company; the abuse directly impairs a legal interest protected in the instruments; the company could reasonably foresee the risk - Comprehensive coverage of all five fundamental principles and rights at work as defined in the 1998 ILO Declaration ### Adverse Environmental Impacts Covered - CSDDD covers breach of prohibitions and obligations listed in Part I (points 15-16) and Part II of the Annex - Prohibition of causing measurable environmental degradation (harmful soil change, water/air pollution, harmful emissions, excessive water consumption, land degradation, deforestation) that: substantially impairs natural bases for food preservation/production; denies access to safe drinking water; makes it difficult to access/destroys sanitary facilities; harms health/safety/normal use of land/possessions; substantially adversely affects ecosystem services - Prohibition of unlawful eviction or taking of land/forests/waters securing livelihoods - Obligation to avoid or minimise adverse impacts on biological diversity (Convention on Biological Diversity, Cartagena Protocol, Nagoya Protocol) - Environmental impacts are interpreted in line with international law and general principles of Union environmental law (Art. 191 TFEU) ### Regulated Financial Undertakings - Regulated financial undertakings can fall within scope under Art. 2 (EU companies) or Art. 2(2) (third-country companies). They are included in the Directive's definition of 'company' (Art. 3(1)(a)(iii)). - The Directive lists the types of regulated financial undertakings it covers (Art. 3(1)(a)(iii)). - For regulated financial undertakings, only the upstream part of the chain of activities is covered; the chain of activities does not include downstream business partners that receive their services and products (Recital 26). - The Commission must submit a report no later than 26 July 2026 on the necessity of additional sustainability due diligence requirements tailored to regulated financial undertakings for the provision of financial services and investment activities (Art. 36(1)). ### Key Definitions - Business partner: an entity with which the company has a commercial agreement related to operations/products/services (direct business partner); or which performs business operations related to the company's operations/products/services (indirect business partner) - Appropriate measures: measures capable of achieving due diligence objectives by effectively addressing adverse impacts, commensurate to severity and likelihood, and reasonably available to the company - Severe adverse impact: especially significant on account of nature (harm to life/health/liberty), scale, scope or irremediable character - Stakeholders: employees, trade unions, workers' representatives, consumers, individuals/communities affected by products/services/operations, national human rights/environmental institutions, civil society organisations, legitimate representatives - SME: micro, small or medium-sized undertaking (not part of a large group) as defined in Directive 2013/34/EU Art. 3(1)-(3) and (7) ## Possible Outcomes ### [IN SCOPE] EU Company Within CSDDD Scope Implement due diligence obligations - Conduct risk-based human rights and environmental due diligence across your operations, subsidiaries and business partners in your chain of activities - Integrate due diligence into policies and risk management (Art. 7) - Identify and assess actual/potential adverse impacts (Art. 8-9) - Prevent/mitigate potential impacts; bring actual impacts to an end (Art. 10-11) - Provide remediation for actual adverse impacts (Art. 12) - Engage meaningfully with stakeholders (Art. 13) - Establish notification mechanism and complaints procedure (Art. 14) - Monitor effectiveness (Art. 15) and publicly communicate (Art. 16) - Adopt and put into effect a transition plan for climate change mitigation (Art. 22). Companies already reporting a transition plan under Directive 2013/34/EU are deemed compliant (Art. 22(2)). ### [IN SCOPE] Third-Country Company Within CSDDD Scope Implement due diligence obligations and designate EU representative - Designate an authorised representative in the EU (Art. 23) - Notify supervisory authority of your in-scope status and representative details - Conduct risk-based human rights and environmental due diligence across your operations, subsidiaries and business partners in your chain of activities - Follow the same due diligence steps as EU companies: integrate, identify, prevent/mitigate, remediate, engage, notify/complain, monitor, communicate - Adopt and put into effect a transition plan for climate change mitigation (Art. 22). Companies already reporting a transition plan under Directive 2013/34/EU are deemed compliant (Art. 22(2)). ### [OUT OF SCOPE] Not Directly Subject to CSDDD But may be affected indirectly - You do not meet the size/turnover thresholds or fall under an exclusion - You may still be impacted as a business partner of an in-scope company - In-scope companies may require you to comply with their code of conduct, prevention/corrective action plans, and contractual assurances (Art. 10-11) - SMEs in the value chain may receive targeted support from in-scope companies (Art. 10(2)(e), 11(3)(f)) ## CSDDD Timeline | Date | Event | Reference | | --- | --- | --- | | 2024-06-13 | CSDDD adopted by Parliament and Council | Directive (EU) 2024/1760 | | 2024-07-05 | CSDDD published in Official Journal (OJ L) | Directive (EU) 2024/1760 | | 2024-07-25 | CSDDD enters into force | Art. 38 | | 2026-07-26 | Member States must transpose CSDDD into national law | Art. 37(1) | | 2026-07-26 | Commission report on additional due diligence requirements for regulated financial undertakings due (no later than) | Art. 36(1) | | 2027-01-26 | Commission guidelines available (general, risk factors, data sources) | Art. 19(3) | | 2027-01-26 | Commission guidance on voluntary model contractual clauses available | Art. 18 | | 2027-03-31 | Commission delegated act on reporting content due | Art. 16(3) | | 2027-07-26 | National measures apply (Wave 1): EU companies >5,000 employees and >EUR 1.5bn net worldwide turnover; and third-country companies >EUR 1.5bn EU net turnover (Article 16 applies for FY starting on/after 2028-01-01) | Art. 37(1)(a) & (c) | | 2027-07-26 | Commission guidelines on transition plans, info sharing, stakeholder engagement available | Art. 19(3) | | 2028-07-26 | National measures apply (Wave 2): EU companies >3,000 employees and >EUR 900m net worldwide turnover; and third-country companies >EUR 900m EU net turnover (Article 16 applies for FY starting on/after 2029-01-01) | Art. 37(1)(b) & (d) | | 2029-01-01 | Annual statements must be submitted to ESAP | Art. 17(1) | | 2029-07-26 | National measures apply (Wave 3): all other in-scope companies under Art. 2 (Article 16 applies for FY starting on/after 2029-01-01) | Art. 37(1)(e) | | 2030-07-26 | Commission review of CSDDD implementation and effectiveness | Art. 36(2) | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2022-02-23 | Commission publishes proposal for a Corporate Sustainability Due Diligence Directive | Proposal & Development | | | 2024-04-24 | European Parliament adopts its first-reading position | Legislative Process | | | 2024-05-24 | Council adopts the final act after Parliament's first reading | Legislative Process | | | 2024-06-13 | Directive (EU) 2024/1760 adopted | Adoption & Publication | | | 2024-07-05 | Directive published in the Official Journal | Adoption & Publication | | | 2024-07-25 | Directive enters into force | Adoption & Publication | | | 2025-02-26 | Commission publishes Omnibus I proposal (COM(2025)80) affecting CSDDD deadlines | 2025 Omnibus Amendments | | | 2025-11-10 | Corrigendum to Directive (EU) 2024/1760 published in the Official Journal | Adoption & Publication | | | 2026-07-26 | Transposition deadline | Transposition & Implementation | | | 2026-07-26 | Commission report on regulated financial undertakings due | Transposition & Implementation | | | 2027-01-26 | Commission guidance on voluntary model contractual clauses due | Transposition & Implementation | | | 2027-07-26 | CSDDD starts applying (wave 1) | Application Deadlines | | | 2027-07-26 | Omnibus I proposal would postpone the transposition deadline (proposal) | 2025 Omnibus Amendments | | | 2028-07-26 | CSDDD starts applying (wave 2) | Application Deadlines | | | 2028-07-26 | Omnibus I proposal would postpone the first application wave (proposal) | 2025 Omnibus Amendments | | | 2029-07-26 | CSDDD starts applying (wave 3) | Application Deadlines | | **Event details:** - **2022-02-23 - Commission publishes proposal for a Corporate Sustainability Due Diligence Directive**: European Commission proposal information page publication date: 23 February 2022. - **2024-04-24 - European Parliament adopts its first-reading position**: OEIL legislative timeline: text adopted by Parliament (first reading/single reading) on 24 April 2024. - **2024-05-24 - Council adopts the final act after Parliament's first reading**: OEIL legislative timeline: act adopted by the Council on 24 May 2024. - **2024-06-13 - Directive (EU) 2024/1760 adopted**: Directive date: 13 June 2024. - **2024-07-05 - Directive published in the Official Journal**: Official Journal publication date for Directive (EU) 2024/1760: 5 July 2024 (OJ L, 2024/1760). - **2024-07-25 - Directive enters into force**: Commission CSDDD page timeline: Directive 2024/1760 entered into force on 25 July 2024. - **2025-02-26 - Commission publishes Omnibus I proposal (COM(2025)80) affecting CSDDD deadlines**: Commission CSDDD page timeline includes a 26 February 2025 proposal (Omnibus I) on postponing certain CSRD reporting requirements and the CSDDD transposition/application timeline. - **2025-11-10 - Corrigendum to Directive (EU) 2024/1760 published in the Official Journal**: OEIL legislative timeline notes a corrigendum in OJ L dated 10 November 2025 (procedure reference 2022/0051(COD)). - **2026-07-26 - Transposition deadline**: EUR-Lex summary timeline: Member States must transpose Directive (EU) 2024/1760 into national law by 26 July 2026. - **2026-07-26 - Commission report on regulated financial undertakings due**: EUR-Lex summary timeline: by 26 July 2026, the Commission must report to the European Parliament and the Council on whether additional sustainability due diligence requirements should be introduced for regulated financial undertakings with respect to financial services and investment activities. - **2027-01-26 - Commission guidance on voluntary model contractual clauses due**: EUR-Lex summary timeline: Commission guidance on voluntary model contractual clauses is due by 26 January 2027. - **2027-07-26 - CSDDD starts applying (wave 1)**: EUR-Lex summary: from 26 July 2027, applies to companies with over 5,000 employees and net turnover over €1.5 billion (and certain non-EU companies meeting turnover criteria). - **2027-07-26 - Omnibus I proposal would postpone the transposition deadline (proposal)**: Commission CSDDD page: under the Omnibus proposal amending the CSDDD, Member States would have to transpose and communicate national measures by 26 July 2027 (proposal; changes enter into force only after co-legislators agree and publication in the Official Journal). - **2028-07-26 - CSDDD starts applying (wave 2)**: EUR-Lex summary: from 26 July 2028, applies to companies with over 3,000 employees and net turnover over €900 million (and certain non-EU companies meeting turnover criteria). - **2028-07-26 - Omnibus I proposal would postpone the first application wave (proposal)**: Commission CSDDD page: under the Omnibus proposal, one year after the proposed transposition deadline, the rules would start to apply to the first group of companies on 26 July 2028, with a staggered approach (proposal). - **2029-07-26 - CSDDD starts applying (wave 3)**: EUR-Lex summary: from 26 July 2029, applies to companies with over 1,000 employees and net turnover over €450 million (and certain non-EU companies meeting turnover criteria). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/corporate-sustainability-due-diligence-directive --- --- title: "EU Digital Services Act (DSA) Compliance Hub" canonical_url: "https://www.sorena.io/artifacts/eu-dsa" source_url: "https://www.sorena.io/artifacts/eu/digital-services-act" author: "Sorena AI" description: "A practical EU Digital Services Act (DSA) compliance hub for Regulation (EU) 2022/2065: classify your service type (hosting/platform/marketplace/search)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Digital Services Act compliance" - "DSA compliance" - "Digital Services Act guide" - "Regulation (EU) 2022/2065" - "DSA decision flow" - "DSA timeline" - "DSA checklist" - "DSA requirements" - "DSA transparency reporting" - "DSA notice and action" - "statement of reasons" - "DSA advertising transparency" - "DSA recommender system transparency" - "VLOP systemic risk assessment" - "VLOP audit" - "Digital Services Coordinator" - "Digital Services Act" - "service classification" - "notice and action" - "transparency reporting" - "VLOP systemic risk" - "audit readiness" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Digital Services Act (DSA) Compliance Hub A practical EU Digital Services Act (DSA) compliance hub for Regulation (EU) 2022/2065: classify your service type (hosting/platform/marketplace/search). ![EU DSA artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-dsa-timeline-small.jpg?v=cheatsheets%2Fprod) *DSA* *Compliance Hub* ## EU Digital Services Act (DSA) Decision Flow + Timeline Use the DSA decision flow to classify your service type and tier, then turn obligations into an executable compliance program: notice and action, statements of reasons, transparency reporting, ad and recommender transparency, and VLOP/VLOSE systemic risk controls. This is a practical implementation guide, not legal advice. Your obligations depend on service features, recipients in the EU, whether you are designated as a VLOP or VLOSE under Article 33, and whether the Commission reporting templates and audit rules already apply to your reporting cycle. [Start with the DSA checklist](/artifacts/eu/digital-services-act/checklist.md) ## What you can decide faster (and defend later) - **Service type and scope**: Intermediary service category (hosting/platform/marketplace/search) + EU offering triggers. - **Obligation set**: What applies to you: notice & action, statements of reasons, transparency reports, ads and recommender transparency. - **VLOP/VLOSE readiness**: Systemic risk assessment, mitigation, independent audits, ad repositories and enhanced reporting. By Sorena AI | Updated Mar 2026 | No signup required ### Quick scan *DSA* - **Scope and tier**: Classify your service (hosting/platform/marketplace/search) and tier. - **Controls and evidence**: Translate articles into controls, runbooks and an evidence pack. - **Reporting cadence**: Plan Article 15, 24, and 42 reporting with the current templates, deadlines, and evidence retention rules. Use the decision flow to turn service facts into a compliance checklist you can ship. | Value | Metric | | --- | --- | | 2022 | DSA | | EU | Market | | VLOP | Tier | | Reports | Ongoing cadence | **Key highlights:** Service classification | Notice & action | Transparency reporting ## Topic Guides - [DSA Ads & Recommender Systems | Article 26, 27, 38 & 39 Compliance](/artifacts/eu/digital-services-act/ads-and-recommender-systems.md): A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27). - [DSA Applicability Test | Is the EU Digital Services Act Applicable to You?](/artifacts/eu/digital-services-act/applicability-test.md): A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers. - [DSA Enforcement & Investigations | DSCs, Commission Powers, Audits & Procedures](/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations.md): A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services. - [DSA Notice & Action Workflow | Article 16 Requirements + Templates](/artifacts/eu/digital-services-act/notice-and-action-workflow.md): A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements. - [DSA Penalties & Fines | Digital Services Act Enforcement Exposure (6% / 1% / 5%)](/artifacts/eu/digital-services-act/penalties-and-fines.md): How DSA penalties work under Regulation (EU) 2022/2065. - [DSA Transparency Report Template | Article 15 + Article 24 + VLOP Article 42](/artifacts/eu/digital-services-act/dsa-transparency-report-template.md): Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835. - [DSA Transparency Reporting | Articles 15, 24 & 42 Reporting Requirements](/artifacts/eu/digital-services-act/transparency-reporting.md): A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24. - [DSA vs DMA | Digital Services Act vs Digital Markets Act (What's the Difference?)](/artifacts/eu/digital-services-act/dsa-vs-dma.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA. - [DSA vs UK Online Safety Act | EU vs UK Online Safety Compliance](/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users). - [EU Digital Services Act (DSA) Requirements | Obligations by Service Type & Tier](/artifacts/eu/digital-services-act/requirements.md): A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms. - [EU DSA Checklist | Digital Services Act Compliance Checklist (Audit-Ready)](/artifacts/eu/digital-services-act/checklist.md): An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency. - [EU DSA Compliance Guide | Digital Services Act Implementation Playbook](/artifacts/eu/digital-services-act/compliance.md): A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering. - [EU DSA Deadlines & Compliance Calendar | Key Dates, Cadence and Milestones](/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar.md): A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24. - [EU DSA FAQ | Digital Services Act Questions & Answers (Practical)](/artifacts/eu/digital-services-act/faq.md): Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what "hosting" and "online platform" mean. - [EU DSA Service Types & Scope | Hosting vs Platform vs Marketplace](/artifacts/eu/digital-services-act/service-types-and-scope.md): How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting). - [VLOP/VLOSE Systemic Risk Assessment (DSA) | Articles 34-36 + Mitigation](/artifacts/eu/digital-services-act/risk-assessments-and-mitigation.md): A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency. ## Key dates for DSA readiness *DSA Timeline* Track DSA applicability milestones that drive reporting calendars, governance set-up, VLOP/VLOSE designation windows, and enforcement readiness. ## Which DSA obligations apply to your service *DSA Decision Flow* Use the decision flow to classify your service and tier, then map the obligations that follow: notice & action, statements of reasons, user redress, marketplace trader checks, transparency reports, and VLOP/VLOSE systemic risk controls. *Next step* ## Turn EU Digital Services Act (DSA) Decision Flow + Timeline into an operational assessment workflow EU Digital Services Act (DSA) Decision Flow + Timeline should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into Research Copilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU Digital Services Act (DSA) Decision Flow + Timeline and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for EU Digital Services Act (DSA) Decision Flow + Timeline. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs from the same artifact. - **Download decision flow**: Share scope and tier classification logic internally. - **Download timeline**: Coordinate DSA milestones across teams. - [Talk through EU Digital Services Act (DSA) Decision Flow + Timeline](/contact.md): Review your current process, evidence model, and next steps for EU Digital Services Act (DSA) Decision Flow + Timeline. ## Decision Steps ### STEP 1: Do you offer intermediary services to recipients that are established in or located in the EU? *Reference: Art. 2(1)* - The Digital Services Act (DSA) applies to intermediary services offered to recipients that have their place of establishment or are located in the EU, regardless of where the provider is established. - An "intermediary service" is one of: mere conduit, caching, or hosting (Art. 3(g)). - If yes: continue to identify your service category and obligations. - **NO** Out of Scope - **YES** Which type of service do you provide? ### STEP 2: Which type of service do you provide? - Intermediary services include mere conduit, caching, and hosting (Art. 3(g)). - Online platforms are a subcategory of hosting services (Art. 3(i)). - Online search engines are an intermediary service with separate rules (Art. 3(j) and Art. 24(2)). - A provider can offer multiple service types; obligations can apply cumulatively. - -> Do you provide a mere conduit service? ### CONDUIT: Do you provide a mere conduit service? *Reference: Art. 3(g)(i)* - Mere conduit involves transmitting information in a communication network provided by a recipient, or providing access to a communication network (Art. 3(g)(i)). - The DSA provides a liability exemption for mere conduit under conditions in Article 4. - **YES** DSA Applies (Mere Conduit) - **NO** Do you provide a caching service? ### CACHING: Do you provide a caching service? *Reference: Art. 3(g)(ii)* - Caching involves automatic, intermediate, and temporary storage for the purpose of making onward transmission more efficient (Art. 3(g)(ii)). - The DSA provides a liability exemption for caching under conditions in Article 5. - **YES** DSA Applies (Caching) - **NO** Do you provide a hosting service? ### HOSTING: Do you provide a hosting service? *Reference: Art. 3(g)(iii)* - Hosting involves storing information provided by and at the request of a recipient of the service (Art. 3(g)(iii)). - The DSA provides a liability exemption for hosting under conditions in Article 6. - **YES** If you provide hosting, are you also an online platform? - **NO** Do you provide an online search engine? ### SEARCH: Do you provide an online search engine? *Reference: Art. 3(j)* - An online search engine allows users to input queries to search websites (in principle, all websites or all websites in a particular language) and returns results (Art. 3(j)). - Online search engines are subject to DSA general obligations and to the AMAR publication rules in Article 24(2). - **YES** Are you designated as a very large online search engine (VLOSE)? - **NO** Out of Scope ### PLATFORM: If you provide hosting, are you also an online platform? *Reference: Art. 3(i)* - An online platform is a hosting service that stores and disseminates information to the public at the request of a recipient (Art. 3(i)). - The definition excludes cases where dissemination to the public is a minor and purely ancillary feature (Art. 3(i)). - **YES** Online platform is within DSA scope - **NO** DSA Applies (Hosting Service) ### IN SCOPE: Online platform is within DSA scope *Reference: Chapter III, Sections 2 and 3* - Hosting obligations apply (Arts. 16-18). - Additional online platform obligations apply (Arts. 19-28), subject to the micro and small enterprise exclusion in Article 19. - -> Do you operate an online platform allowing consumers to conclude distance contracts with traders? ### STEP 3: Do you operate an online platform allowing consumers to conclude distance contracts with traders? *Reference: Arts. 29-32* - The DSA imposes additional obligations for online platforms allowing consumers to conclude distance contracts with traders (Section 4, Arts. 29-32). - This category is often referred to as an online marketplace. - **YES** DSA Applies (Platform Allowing Distance Contracts) - **NO** Are you designated as a very large online platform (VLOP)? ### STEP 4: Are you designated as a very large online platform (VLOP)? *Reference: Art. 33* - The Commission designates VLOPs under Article 33(4). - Section 5 obligations apply from four months after notification of the designation decision (Art. 33(6)). - **YES** DSA Applies (VLOP) - **NO** DSA Applies (Online Platform) ### STEP 4: Are you designated as a very large online search engine (VLOSE)? *Reference: Art. 33* - The Commission designates VLOSEs under Article 33(4). - Section 5 obligations apply from four months after notification of the designation decision (Art. 33(6)). - **YES** DSA Applies (VLOSE) - **NO** DSA Applies (Online Search Engine) ## Reference Information ### Services In Scope (Overview) - Intermediary services are information society services that are: mere conduit, caching, or hosting (Art. 3(g)). - An online platform is a hosting service that stores and disseminates information to the public at the request of a recipient (Art. 3(i)). - An online search engine is an intermediary service that allows users to input queries and returns results (Art. 3(j)). - VLOPs and VLOSEs are designated by the Commission under Article 33 if they meet the threshold of 45 million average monthly active recipients in the EU (Art. 33(1) and (4)). ### Key Exclusions and Carve Outs - The DSA does not apply to services that are not intermediary services (Art. 2(2)). - The DSA is without prejudice to other EU legal acts that regulate other aspects of intermediary services (Art. 2(4)). - Micro and small enterprise exemptions exist for certain obligations (e.g., Art. 15(2), Art. 19, and Art. 29), with specific conditions and exceptions. ### Liability Exemptions (Arts. 4-6) - Mere conduit: Article 4 sets out conditions for an exemption from liability. - Caching: Article 5 sets out conditions for an exemption from liability. - Hosting: Article 6 sets out conditions for an exemption from liability. - The DSA also prohibits a general obligation to monitor or actively seek facts indicating illegal activity (Art. 8). ### General Obligations (All Intermediary Services) - No general monitoring obligation (Art. 8). - Orders to act against illegal content and orders to provide information (Arts. 9-10). - Points of contact: for authorities (Art. 11) and for recipients of the service (Art. 12). - Legal representative in the EU for certain providers not established in the EU (Art. 13). - Terms and conditions requirements (Art. 14). - Annual transparency reporting obligations for intermediary services (Art. 15), with a micro and small enterprise exemption in Article 15(2). ### Hosting Service Obligations (Arts. 16-18) - Notice and action (Art. 16): provide mechanisms to submit notices of illegal content; process notices without undue delay; inform the submitter of the decision. - Statement of reasons (Art. 17): provide clear information to recipients about certain restriction decisions and available redress options. - Notification of suspicions of criminal offences involving threats to life or safety (Art. 18). ### Online Platform Obligations (Arts. 19-28) - Internal complaint-handling system (Art. 20) and out-of-court dispute settlement access (Art. 21). - Trusted flaggers: priority processing of notices from trusted flaggers (Art. 22). - Measures against misuse (Art. 23). - Additional transparency reporting items for online platforms and AMAR publication rules (Art. 24(1)-(2)); communication on request (Art. 24(3)). - Submission of statements of reasons for the Commission database (Art. 24(5)). - Online interface design and organisation: prohibition on deceptive or manipulative interface design (Art. 25). - Advertising transparency obligations (Art. 26). - Recommender system transparency obligations (Art. 27). - Online protection of minors (Art. 28). - Micro and small enterprise exclusion for this section (Art. 19), except for Article 24(3). ### Platforms Allowing Distance Contracts (Arts. 29-32) - Micro and small enterprise exclusion for this section (Art. 29), with conditions and an exception for designated VLOPs (Art. 29(2)). - Traceability of traders (Art. 30): collect specified trader information (including payment account details and a self-certification), make best efforts to assess completeness and reliability, and display specified items to recipients. - Compliance by design (Art. 31): design the interface to enable traders to provide required pre-contractual and product compliance information, and make reasonable efforts to randomly check illegality in official databases. - Right to information (Art. 32): when aware an illegal product or service was offered, inform affected consumers and/or publish accessible information for consumers. ### Online Search Engine Obligations (Key Items) - AMAR publication: online search engines must publish AMAR by 17 February 2023 and at least once every six months thereafter (Art. 24(2)). - Communication on request: upon request, communicate AMAR information to the Digital Services Coordinator of establishment and the Commission (Art. 24(3)). - VLOSE designation and additional obligations may apply under Article 33 and Section 5 (Arts. 33-43). ### VLOP/VLOSE Obligations (Arts. 33-43) - Systemic risk assessment (Art. 34) and risk mitigation measures (Art. 35). - Crisis response mechanism: Commission decision during a crisis (Art. 36). - Independent audits (Art. 37). - Recommender systems: at least one option not based on profiling (Art. 38). - Advertising repository and transparency requirements for VLOPs/VLOSEs (Art. 39). - Data access and scrutiny: access for the DSC of establishment or the Commission, and access for vetted researchers (Art. 40). - Compliance function (Art. 41). - Enhanced transparency reporting and transmission/publication of certain reports (Art. 42). - Supervisory fee (Art. 43). ### Recommender Systems Transparency (Arts. 27 and 38) - Online platforms must describe main recommender parameters and available options in their terms and conditions (Art. 27(1)-(2)). - Where multiple options exist, platforms must provide functionality to select and modify a preferred option at any time (Art. 27(3)). - VLOPs and VLOSEs must provide at least one option not based on profiling (Art. 38(1)). ### Advertising Transparency (Arts. 26, 28(2), and 39) - For each ad, online platforms must enable recipients to identify it as an advertisement and see who is behind and paying for it, plus meaningful targeting parameter information (Art. 26(1)). - Online platforms must not present ads based on profiling using special categories of personal data (Art. 26(3)). - Online platforms must not present advertisements based on profiling using personal data when they are aware with reasonable certainty that the recipient is a minor (Art. 28(2)). - VLOPs and VLOSEs have additional advertising transparency requirements under Article 39 (ad repository). ### Trusted Flaggers (Art. 22) - Online platforms must ensure notices submitted by trusted flaggers are given priority and are processed and decided upon without undue delay (Art. 22(1)). - Trusted flagger status is awarded by the Digital Services Coordinator of the Member State where the applicant is established, subject to conditions in Article 22(2). - The Commission publishes trusted flagger information in a publicly available database (Art. 22(5)). - Where a provider has information about insufficiently precise, inaccurate, or inadequately substantiated notices, it must communicate that information to the awarding DSC; the DSC may suspend and can revoke status (Art. 22(6)-(7)). ### Out-of-Court Dispute Settlement (Art. 21) - Recipients can select a certified out-of-court dispute settlement body to resolve disputes relating to certain platform decisions (Art. 21(1)). - Providers of online platforms must cooperate with certified bodies (Art. 21(4)). ### Micro and Small Enterprise Exemptions (Selected) - Transparency reports under Article 15 do not apply to micro and small enterprises that are not very large online platforms within the meaning of Article 33 (Art. 15(2)). - Section 3 (online platform obligations) generally does not apply to micro and small online platforms, with the exception of Article 24(3), and with a transition rule for the 12 months after losing status (Art. 19). - Section 4 (platforms allowing distance contracts) generally does not apply to micro and small providers, with a transition rule for the 12 months after losing status, except when designated as a VLOP (Art. 29). ### Data Access and Scrutiny (Art. 40) - On reasoned request, VLOPs and VLOSEs must provide the Digital Services Coordinator of establishment or the Commission access to data necessary to monitor and assess compliance (Art. 40(1)). - On reasoned request from the DSC of establishment, VLOPs and VLOSEs must provide access to data to vetted researchers for specified systemic risk research (Art. 40(4)). - The DSC of establishment grants vetted researcher status and issues a reasoned request for data access when conditions are met (Art. 40(8)). ### Crisis Response Mechanism (Art. 36) - During a crisis, the Commission (acting upon a recommendation of the Board) may adopt a decision requiring one or more VLOPs or VLOSEs to assess their contribution to a serious threat, apply measures, and report to the Commission (Art. 36(1)). - A crisis means extraordinary circumstances leading to a serious threat to public security or public health in the EU or significant parts of it (Art. 36(2)). - The Commission decision must meet necessity and proportionality requirements and is time-limited (Art. 36(3)). ### Codes of Conduct and Crisis Protocols (Arts. 45-46 and 48) - The DSA provides for voluntary codes of conduct (Arts. 45-46). - The DSA also provides for voluntary crisis protocols to address crisis situations (Art. 48). - The Commission is encouraged to promote development of certain codes of conduct by 18 February 2025 and their application by 18 August 2025 (Art. 45(3)). ### Digital Services Coordinators (DSCs) and Enforcement - Member States must designate a Digital Services Coordinator and make its contact information public; the designation deadline is 17 February 2024 (Art. 49(3)). - DSCs have investigation and enforcement powers as set out in Article 51, and Member States must set rules on penalties applicable to infringements under their jurisdiction (Art. 52). - DSCs cooperate with each other, the Board, and the Commission (Art. 49(2)). ### Penalties and Fines (Selected) - Member States must lay down rules on penalties applicable to infringements by providers of intermediary services under their jurisdiction (Art. 52). - The DSA also provides Commission-level enforcement for VLOPs and VLOSEs, including fines and periodic penalty payments (Chapter IV). ### European Board for Digital Services (EBDS) (Arts. 61-62) - The Board supports the consistent application of the DSA (Arts. 61-62). - It includes Digital Services Coordinators and the Commission participates (Art. 61). ## Possible Outcomes ### [RESULT] Out of Scope DSA does not directly apply - Based on this flow, you are not offering an intermediary service to recipients established in or located in the EU (Art. 2(1)), or your service is not an intermediary service (Art. 2(2)). - Even if out of scope, you may be impacted indirectly via contractual requirements or platform policies. ### [RESULT] DSA Applies (Mere Conduit) Liability exemption + general obligations - A mere conduit service is an intermediary service (Art. 3(g)(i)). - Liability exemptions for mere conduit are set out in Article 4 (subject to conditions). - General obligations apply (including Arts. 11-15 and Art. 8). ### [RESULT] DSA Applies (Caching) Liability exemption + general obligations - A caching service is an intermediary service (Art. 3(g)(ii)). - Liability exemptions for caching are set out in Article 5 (subject to conditions). - General obligations apply (including Arts. 11-15 and Art. 8). ### [RESULT] DSA Applies (Hosting Service) Liability exemption + hosting obligations - A hosting service is an intermediary service (Art. 3(g)(iii)). - Liability exemptions for hosting are set out in Article 6 (subject to conditions). - Hosting-specific obligations apply (Arts. 16-18), plus general obligations. ### [RESULT] DSA Applies (Online Platform) Hosting + platform obligations (not VLOP) - Online platforms are hosting services (Art. 3(i)). - Hosting obligations apply (Arts. 16-18). - Additional platform obligations apply (Arts. 19-28), subject to Article 19 (micro and small enterprise exclusion). ### [RESULT] DSA Applies (Platform Allowing Distance Contracts) Platform + trader traceability and consumer information obligations - Additional obligations apply for online platforms allowing consumers to conclude distance contracts with traders (Arts. 29-32). - Those obligations are in addition to hosting (Arts. 16-18) and online platform obligations (Arts. 19-28), as applicable. - This section has a micro and small enterprise exclusion in Article 29 (with specific conditions and exceptions). ### [RESULT] DSA Applies (Online Search Engine) General obligations + AMAR publication - Online search engines are an intermediary service as defined in Article 3(j). - General obligations apply (including Arts. 11-15 and Art. 8). - AMAR publication applies to online search engines under Article 24(2). ### [RESULT] DSA Applies (VLOP) Full obligations including systemic risk management - VLOPs are subject to the additional obligations in Section 5 (Arts. 33-43), including systemic risk management, audits, and enhanced transparency reporting. - Hosting and online platform obligations also apply, as applicable. ### [RESULT] DSA Applies (VLOSE) Full obligations including systemic risk management - VLOSEs are subject to the additional obligations in Section 5 (Arts. 33-43), including systemic risk management, audits, and enhanced transparency reporting. - General obligations apply, including AMAR publication and reporting requirements as applicable. ## DSA Timeline | Date | Event | Reference | | --- | --- | --- | | 2022-10-19 | DSA adopted (Regulation (EU) 2022/2065) | Regulation (EU) 2022/2065 | | 2022-10-27 | DSA published in the Official Journal (OJ L 277) | Regulation (EU) 2022/2065 | | 2022-11-16 | DSA enters into force; specified provisions apply from this date | Art. 93 | | 2023-02-17 | First publication of average monthly active recipients (AMAR) for platforms and search engines due | Art. 24(2) | | 2024-02-17 | DSA applies from this date; Member States must designate Digital Services Coordinators | Art. 93 and Art. 49(3) | | 2023-04-25 | First VLOP/VLOSE designation decisions adopted by the Commission | Art. 33(4) | | 2025-02-18 | Commission encouraged to promote development of certain codes of conduct by this date | Art. 45(3) | | 2025-08-18 | Commission encouraged to promote application of certain codes of conduct by this date | Art. 45(3) | | 2025-11-17 | Commission evaluation and report due under the DSA | Art. 90 | | 2027-02-18 | Commission evaluation and report due under the DSA | Art. 90 and Art. 91 | | 2027-11-17 | Commission evaluation of the DSA due (and every 5 years thereafter) | Art. 92 | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2022-06-16 | 2022 Strengthened Code of Practice on Disinformation published | Codes of Conduct | | | 2022-10-19 | Digital Services Act adopted (Regulation (EU) 2022/2065) | Legislative History | | | 2022-10-27 | DSA published in the Official Journal (OJ L 277) | Official Publication | | | 2022-11-16 | DSA enters into force | Official Publication | | | 2022-11-16 | Selected DSA provisions start applying (partial application) | Official Publication | | | 2023-01-31 | Commission publishes guidance on the requirement to publish user numbers | Guidelines & Guidance | | | 2023-02-17 | Deadline for platforms to publish user numbers | Guidelines & Guidance | | | 2023-03-02 | Delegated Regulation (EU) 2023/1127 on supervisory fees adopted | Implementing Acts | | | 2023-04-25 | Commission designates first VLOPs and VLOSEs | VLOP/VLOSE Designation | | | 2023-06-09 | Delegated Regulation (EU) 2023/1127 published in the Official Journal | Implementing Acts | | | 2023-06-21 | Implementing Regulation (EU) 2023/1201 on Commission proceedings adopted | Implementing Acts | | | 2023-06-22 | Implementing Regulation (EU) 2023/1201 published in the Official Journal | Implementing Acts | | | 2023-08-25 | DSA starts applying to the first designated VLOPs and VLOSEs | VLOP/VLOSE Designation | | | 2023-10-20 | Delegated Regulation (EU) 2024/436 on independent audits adopted | Implementing Acts | | | 2024-02-02 | Delegated Regulation (EU) 2024/436 published in the Official Journal | Implementing Acts | | | 2024-02-08 | Public consultation opens on elections systemic risk mitigation guidelines | Guidelines & Guidance | | | 2024-02-15 | Implementing Regulation (EU) 2024/607 (AGORA) adopted | Implementing Acts | | | 2024-02-16 | Implementing Regulation (EU) 2024/607 (AGORA) published in the Official Journal | Implementing Acts | | | 2024-02-17 | DSA fully applies (general date of applicability) and DSC designation deadline | Official Publication | | | 2024-02-17 | European Board for Digital Services established | Governance & Cooperation | | | 2024-02-19 | First European Board for Digital Services meeting held | Governance & Cooperation | | | 2024-03-07 | Public consultation closes on elections systemic risk mitigation guidelines | Guidelines & Guidance | | | 2024-03-26 | Commission publishes elections systemic risk mitigation guidelines (press release) | Guidelines & Guidance | | | 2024-03-31 | Deadline for the first supervisory fees report under Delegated Regulation (EU) 2023/1127 | Implementing Acts | | | 2024-04-24 | Commission issues Letters of Formal Notice related to DSC designation and empowerment | Enforcement Actions | | | 2024-04-26 | Elections systemic risk mitigation guidelines adopted and published | Guidelines & Guidance | | | 2024-06-20 | European Board establishes working groups | Governance & Cooperation | | | 2024-09-25 | European Board adopts working groups terms of reference | Governance & Cooperation | | | 2024-11-04 | Implementing Regulation (EU) 2024/2835 on transparency report templates adopted | Implementing Acts | | | 2024-11-05 | Implementing Regulation (EU) 2024/2835 published in the Official Journal | Implementing Acts | | | 2024-12-17 | Commission opens formal proceedings against TikTok over election risks | Enforcement Actions | | | 2025-01-20 | Hate Speech Online+ integrated into the DSA codes of conduct framework | Codes of Conduct | | | 2025-02-13 | 2022 Code of Practice on Disinformation integrated as a DSA Code of Conduct | Codes of Conduct | | | 2025-02-16 | Deadline for first annual transparency report following the DSA reporting cycle | Implementing Acts | | | 2025-02-18 | DSA codes of conduct development encouraged by the Commission | Codes of Conduct | | | 2025-05-13 | Targeted public consultation opens on the protection of minors guidelines | Guidelines & Guidance | | | 2025-06-15 | Targeted public consultation closes on the protection of minors guidelines | Guidelines & Guidance | | | 2025-07-01 | Transparency reporting templates become mandatory under Implementing Regulation (EU) 2024/2835 | Implementing Acts | | | 2025-07-14 | Guidelines on the protection of minors under the DSA presented | Guidelines & Guidance | | | 2025-08-18 | DSA codes of conduct application encouraged | Codes of Conduct | | | 2025-11-17 | Commission evaluation report due under the DSA | Governance & Cooperation | | | 2025-12-31 | Transparency reporting transition period ends (end of 2025) | Implementing Acts | | | 2026-01-01 | Unified transparency reporting periods apply (start of 2026) | Implementing Acts | | | 2026-02-06 | Commission preliminarily finds TikTok's addictive design in breach of the DSA | Enforcement Actions | | | 2026-12-31 | First full harmonised transparency reporting cycle ends | Implementing Acts | | | 2027-02-17 | AGORA implementation report due (Implementing Regulation (EU) 2024/607) | Implementing Acts | | | 2027-02-18 | Commission report on SME impacts due under the DSA | Governance & Cooperation | | | 2027-11-17 | Commission evaluation of the DSA due (and every 5 years thereafter) | Governance & Cooperation | | **Event details:** - **2022-06-16 - 2022 Strengthened Code of Practice on Disinformation published**: Publication date on the Code of Practice page: 16 June 2022. - **2022-10-19 - Digital Services Act adopted (Regulation (EU) 2022/2065)**: Regulation (EU) 2022/2065 date: 19 October 2022. - **2022-10-27 - DSA published in the Official Journal (OJ L 277)**: Official Journal publication reference for Regulation (EU) 2022/2065: OJ L 277, 27.10.2022, pp. 1-102. - **2022-11-16 - DSA enters into force**: Regulation (EU) 2022/2065 enters into force 20 days after publication in the Official Journal. - **2022-11-16 - Selected DSA provisions start applying (partial application)**: Regulation timeline: Article 24(2), (3) and (6), Article 33(3)-(6), Article 37(7), Article 40(13), Article 43, and Sections 4-6 of Chapter IV apply from 16 November 2022. - **2023-01-31 - Commission publishes guidance on the requirement to publish user numbers**: Guidance page publication date: 31 January 2023. - **2023-02-17 - Deadline for platforms to publish user numbers**: Guidance timeline: 17 February 2023 deadline for first publication of average monthly active recipients of the service (Article 24(2) DSA). - **2023-03-02 - Delegated Regulation (EU) 2023/1127 on supervisory fees adopted**: Commission Delegated Regulation (EU) 2023/1127 date: 2 March 2023. - **2023-04-25 - Commission designates first VLOPs and VLOSEs**: Designation decisions: on 25 April 2023, the Commission designated the first set of VLOPs and VLOSEs. - **2023-06-09 - Delegated Regulation (EU) 2023/1127 published in the Official Journal**: EUR-Lex extract: publication date 9 June 2023 (OJ L 149/16). - **2023-06-21 - Implementing Regulation (EU) 2023/1201 on Commission proceedings adopted**: Commission Implementing Regulation (EU) 2023/1201 date: 21 June 2023. - **2023-06-22 - Implementing Regulation (EU) 2023/1201 published in the Official Journal**: EUR-Lex extract: publication date 22 June 2023 (OJ L 159). - **2023-08-25 - DSA starts applying to the first designated VLOPs and VLOSEs**: Enforcement framework timeline references Commission investigatory steps since 25 August 2023 for the first designated VLOPs and VLOSEs. - **2023-10-20 - Delegated Regulation (EU) 2024/436 on independent audits adopted**: Commission Delegated Regulation (EU) 2024/436 date: 20 October 2023. - **2024-02-02 - Delegated Regulation (EU) 2024/436 published in the Official Journal**: EUR-Lex extract: publication date 2 February 2024 (OJ L, 2024/436). - **2024-02-08 - Public consultation opens on elections systemic risk mitigation guidelines**: Elections guidelines timeline: public consultation ran from 8 February to 7 March 2024. - **2024-02-15 - Implementing Regulation (EU) 2024/607 (AGORA) adopted**: Commission Implementing Regulation (EU) 2024/607 date: 15 February 2024. - **2024-02-16 - Implementing Regulation (EU) 2024/607 (AGORA) published in the Official Journal**: EUR-Lex extract: publication date 16 February 2024 (OJ L, 2024/607). - **2024-02-17 - DSA fully applies (general date of applicability) and DSC designation deadline**: Regulation timeline: the DSA applies from 17 February 2024 and Member States must designate Digital Services Coordinators by 17 February 2024. - **2024-02-17 - European Board for Digital Services established**: European Board for Digital Services policy page timeline: established with effect from 17 February 2024. - **2024-02-19 - First European Board for Digital Services meeting held**: European Board for Digital Services policy page timeline: 1st meeting held on 19 February 2024. - **2024-03-07 - Public consultation closes on elections systemic risk mitigation guidelines**: Elections guidelines timeline: public consultation ran from 8 February to 7 March 2024. - **2024-03-26 - Commission publishes elections systemic risk mitigation guidelines (press release)**: Elections guidelines timeline: press release and consultation results dated 26 March 2024. - **2024-03-31 - Deadline for the first supervisory fees report under Delegated Regulation (EU) 2023/1127**: Delegated Regulation (EU) 2023/1127 extract: the first report (Article 8) to be adopted by the Commission by 31 March 2024. - **2024-04-24 - Commission issues Letters of Formal Notice related to DSC designation and empowerment**: Digital Services Coordinators page timeline: Letters of Formal Notice issued on 24 April 2024 (Czechia, Cyprus, Estonia, Poland, Portugal, Slovakia). - **2024-04-26 - Elections systemic risk mitigation guidelines adopted and published**: Elections guidelines timeline: communication formally adopted and published on 26 April 2024. - **2024-06-20 - European Board establishes working groups**: European Board for Digital Services policy page timeline: the Board established eight working groups in its 5th meeting on 20 June 2024. - **2024-09-25 - European Board adopts working groups terms of reference**: Working groups page timeline: terms of reference adopted at the Board's 7th meeting on 25 September 2024. - **2024-11-04 - Implementing Regulation (EU) 2024/2835 on transparency report templates adopted**: EUR-Lex extract: Commission Implementing Regulation (EU) 2024/2835 date: 4 November 2024. - **2024-11-05 - Implementing Regulation (EU) 2024/2835 published in the Official Journal**: EUR-Lex extract: Official Journal publication date 5 November 2024 (OJ L, 2024/2835). - **2024-12-17 - Commission opens formal proceedings against TikTok over election risks**: TikTok proceedings page publication date: 17 December 2024. - **2025-01-20 - Hate Speech Online+ integrated into the DSA codes of conduct framework**: Codes of conduct page timeline: on 20 January 2025, the Commission and the European Board for Digital Services endorsed integration of the Code of Conduct on Countering Illegal Hate Speech Online+ into the DSA framework. - **2025-02-13 - 2022 Code of Practice on Disinformation integrated as a DSA Code of Conduct**: Code of Practice page timeline: on 13 February 2025, the Commission and the European Board for Digital Services endorsed integration of the 2022 Code of Practice on Disinformation into the DSA framework. - **2025-02-16 - Deadline for first annual transparency report following the DSA reporting cycle**: Implementing Regulation (EU) 2024/2835 extract includes an example first annual transparency report publication latest date: 16 February 2025. - **2025-02-18 - DSA codes of conduct development encouraged by the Commission**: Regulation timeline: the Commission shall encourage development of certain codes of conduct by 18 February 2025. - **2025-05-13 - Targeted public consultation opens on the protection of minors guidelines**: Minors guidelines page timeline: targeted public consultation ran from 13 May to 15 June 2025. - **2025-06-15 - Targeted public consultation closes on the protection of minors guidelines**: Minors guidelines page timeline: targeted public consultation ran from 13 May to 15 June 2025. - **2025-07-01 - Transparency reporting templates become mandatory under Implementing Regulation (EU) 2024/2835**: Implementing Regulation (EU) 2024/2835 timeline: providers shall follow the Annex I templates as of 1 July 2025. - **2025-07-14 - Guidelines on the protection of minors under the DSA presented**: Guidelines hub timeline: the Commission presented its guidelines on the protection of minors under the DSA on 14 July 2025. - **2025-08-18 - DSA codes of conduct application encouraged**: Regulation timeline: the Commission shall encourage application of certain codes of conduct by 18 August 2025. - **2025-11-17 - Commission evaluation report due under the DSA**: Regulation timeline: by 17 November 2025, the Commission shall evaluate and report to the European Parliament and the Council on specified DSA topics. - **2025-12-31 - Transparency reporting transition period ends (end of 2025)**: Implementing Regulation (EU) 2024/2835 timeline includes transition instructions ending on 31 December 2025. - **2026-01-01 - Unified transparency reporting periods apply (start of 2026)**: Implementing Regulation (EU) 2024/2835 timeline: unified reporting periods apply as of 1 January 2026. - **2026-02-06 - Commission preliminarily finds TikTok's addictive design in breach of the DSA**: Algorithmic transparency portal timeline: press release dated 6 February 2026. - **2026-12-31 - First full harmonised transparency reporting cycle ends**: Implementing Regulation (EU) 2024/2835 timeline: first full harmonised reporting cycle covers until 31 December 2026. - **2027-02-17 - AGORA implementation report due (Implementing Regulation (EU) 2024/607)**: Implementing Regulation (EU) 2024/607 timeline: by 17 February 2027, and every three years thereafter, the Commission shall submit an implementation report. - **2027-02-18 - Commission report on SME impacts due under the DSA**: Regulation timeline: by 18 February 2027, the Commission shall evaluate and report on potential effects on SMEs. - **2027-11-17 - Commission evaluation of the DSA due (and every 5 years thereafter)**: Regulation timeline: by 17 November 2027, and every five years thereafter, the Commission shall evaluate the DSA and report. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-services-act --- --- title: "EU eIDAS & eIDAS 2.0 (EUDI Wallet) Hub" canonical_url: "https://www.sorena.io/artifacts/eu-eidas" source_url: "https://www.sorena.io/artifacts/eu/electronic-identification-and-trust-services-regulation" author: "Sorena AI" description: "A practical eIDAS hub for trust services, electronic signatures, electronic attestations of attributes, electronic archiving, electronic ledgers." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "eIDAS" - "Regulation (EU) No 910/2014" - "Regulation (EU) 2024/1183" - "trust services" - "qualified trust service provider" - "electronic signatures" - "electronic attestation of attributes" - "electronic archiving" - "electronic ledgers" - "EU Digital Identity Wallet" - "assurance levels" - "Digital identity" - "Compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU eIDAS & eIDAS 2.0 (EUDI Wallet) Hub A practical eIDAS hub for trust services, electronic signatures, electronic attestations of attributes, electronic archiving, electronic ledgers. ![EU eIDAS artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-eidas-timeline-small.jpg?v=cheatsheets%2Fprod) *eIDAS* *Free Resource* ## EU eIDAS Trust Services + EUDI Wallet Hub Map trust services, signatures, expanded eIDAS 2.0 trust-service categories, and QTSP choices, then plan EUDI Wallet relying party readiness with concrete architecture and evidence workstreams. This is a practical reference, not legal advice. Exact obligations depend on your role, service type, current implementing acts, and national supervision. [Start with the checklist](/artifacts/eu/eidas/checklist.md) ## What you can decide faster - **Service type**: Trust services and identity workflow mapping. - **Assurance level**: Align assurance expectations to risk and use cases. - **Evidence**: Plan audit evidence and operating procedures. By Sorena AI | Updated Mar 2026 | No signup required ### Quick scan *eIDAS* - **Trust services**: Map signatures, seals, timestamps, and delivery services. - **Wallet context**: Plan EUDI Wallet acceptance, attribute verification, and current implementing-act impacts. - **Compliance**: Turn legal requirements into audit-ready controls, evidence, and operating procedures. Use the decision flow to align product, security, and compliance teams on the right path. | Value | Metric | | --- | --- | | 2014 | Regulation | | 2016 | Applies | | 2024 | Update | | Trust | Services | **Key highlights:** Trust services | Qualified signatures | EUDI Wallet readiness ## Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/electronic-identification-and-trust-services-regulation/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/electronic-identification-and-trust-services-regulation/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/electronic-identification-and-trust-services-regulation/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/electronic-identification-and-trust-services-regulation/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/electronic-identification-and-trust-services-regulation/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/electronic-identification-and-trust-services-regulation/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/electronic-identification-and-trust-services-regulation/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/electronic-identification-and-trust-services-regulation/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/electronic-identification-and-trust-services-regulation/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/electronic-identification-and-trust-services-regulation/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/electronic-identification-and-trust-services-regulation/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/electronic-identification-and-trust-services-regulation/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/electronic-identification-and-trust-services-regulation/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/electronic-identification-and-trust-services-regulation/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/electronic-identification-and-trust-services-regulation/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. ## Key dates for digital identity planning *eIDAS Timeline* Track eIDAS milestones that influence trust services, identity assurance, and EUDI Wallet rollout planning. ## Which eIDAS workstream fits your use case *eIDAS Decision Flow* Use the decision flow to map your role and obligations, then translate outcomes into compliance tasks and evidence. *Next step* ## Turn EU eIDAS Trust Services + EUDI Wallet Hub into an operational assessment workflow EU eIDAS Trust Services + EUDI Wallet Hub should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into Research Copilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU eIDAS Trust Services + EUDI Wallet Hub and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for EU eIDAS Trust Services + EUDI Wallet Hub. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs from the same artifact. - **Download decision flow**: Share decision logic internally. - **Download timeline**: Align milestones across teams. - [Talk through EU eIDAS Trust Services + EUDI Wallet Hub](/contact.md): Review your current process, evidence model, and next steps for EU eIDAS Trust Services + EUDI Wallet Hub. ## Decision Steps ### STEP 1: What is your role in electronic transactions? *Reference: Reg. (EU) No 910/2014 and Reg. (EU) 2024/1183* - eIDAS 1.0 (Regulation 910/2014) covers electronic identification and trust services. - eIDAS 2.0 (Regulation 2024/1183) introduces the European Digital Identity Wallet (EUDI Wallet). - Choose your primary role to determine applicable requirements. - -> Are you a Trust Service Provider (providing trust services such as eSignatures, eSeals, timestamps, eDelivery, or website authentication certificates)? ### TRACK SELECTION: Are you a Trust Service Provider (providing trust services such as eSignatures, eSeals, timestamps, eDelivery, or website authentication certificates)? *Reference: Trust services and EUDI Wallet scope overview* - If yes: follow the Trust Service Provider (TSP) track. - If no: check whether you are an eID scheme operator, EUDI Wallet provider, or a relying party/service provider. - **YES** Do you provide trust services as defined by eIDAS? - **NO** If not a TSP: are you a Member State authority or identity provider operating/notifying an eID scheme? ### TRACK SELECTION: If not a TSP: are you a Member State authority or identity provider operating/notifying an eID scheme? *Reference: Reg. (EU) No 910/2014 (Notification - Art. 9)* - eID schemes are notified by Member States for cross-border recognition under eIDAS. - If yes: follow the eID scheme track. - **YES** Are you a Member State or identity provider operating an eID scheme? - **NO** If not an eID scheme operator: are you a provider involved in issuing or operating an EUDI Wallet? ### TRACK SELECTION: If not an eID scheme operator: are you a provider involved in issuing or operating an EUDI Wallet? *Reference: Reg. (EU) No 910/2014 (as amended) - European Digital Identity Wallets (Art. 5a)* - EUDI Wallets are issued/provided under Member State responsibility; private entities may operate components under a framework set by implementing acts. - If yes: follow the EUDI Wallet track. - **YES** Do you plan to issue or manage European Digital Identity Wallets? - **NO** If none of the above: are you a service provider/relying party that uses eID or trust services to authenticate users or validate electronic transactions? ### TRACK SELECTION: If none of the above: are you a service provider/relying party that uses eID or trust services to authenticate users or validate electronic transactions? *Reference: Reg. (EU) No 910/2014 (Art. 6) and (as amended) Art. 5f* - Relying parties can be public sector bodies or private sector service providers. - If yes: follow the relying party track. - **YES** Do you provide online services that require user authentication or trust services? - **NO** Not Directly Subject to eIDAS ### TSP TRACK: Do you provide trust services as defined by eIDAS? *Reference: Reg. (EU) No 910/2014 (definitions - Art. 3(17)-(20))* - Trust services include (among others): electronic signatures and seals, time stamps, electronic registered delivery, website authentication, electronic attestations of attributes, electronic archiving, and electronic ledgers. - eIDAS 2.0 adds and updates trust service types and related requirements (including remote management of qualified signature and seal creation devices). - If yes, you are a Trust Service Provider (TSP). - **YES** Do you provide or plan to provide qualified trust services? - **NO** Not Directly Subject to eIDAS ### STEP 2: Do you provide or plan to provide qualified trust services? *Reference: Reg. (EU) No 910/2014 (qualified trust services - Art. 3(17), Art. 20-22)* - Qualified trust services meet the applicable requirements laid down in the regulation and are provided by qualified trust service providers (QTSPs). - Qualified electronic signatures have the legal effect of handwritten signatures (Art. 25(2)). - Trust service providers must notify the supervisory body when they intend to start providing a qualified trust service, together with a conformity assessment report (Art. 21). - QTSPs and their qualified trust services are supervised by the supervisory body and appear on trusted lists (Art. 20 and Art. 22). - If yes, stricter conformity assessment and supervision requirements apply. - **YES** Qualified Trust Service Provider Requirements - **NO** Non-Qualified Trust Service Provider Requirements ### eID TRACK: Are you a Member State or identity provider operating an eID scheme? *Reference: Reg. (EU) No 910/2014 (Notification - Art. 9; Mutual recognition - Art. 6)* - Electronic identification (eID) schemes enable persons to identify themselves electronically in order to access online services. - Member States may notify their national eID schemes to the European Commission for cross-border recognition (Art. 9). - Notified eID schemes must be recognised by other Member States for accessing online public services (Art. 6). - Notification is voluntary, but once notified, mutual recognition becomes mandatory according to the regulation's application timeline (reported as in force since 29 September 2018). - **YES** eID Scheme Notification and Recognition - **NO** Not Directly Subject to eIDAS ### EUDI WALLET TRACK: Do you plan to issue or manage European Digital Identity Wallets? *Reference: Reg. (EU) No 910/2014 (as amended) - Art. 5a and Art. 5f* - The European Digital Identity Wallet (EUDI Wallet) framework is introduced by eIDAS 2.0 (Regulation (EU) 2024/1183 amending eIDAS). - Member States provide at least one EUDI Wallet, either directly, under mandate, or via providers recognised by the Member State (Art. 5a(2)). - EUDI Wallets enable users to request, obtain, store, share and present person identification data and electronic attestations of attributes, and to sign with qualified electronic signatures or seals (Art. 5a(4)). - Relying parties have acceptance duties for EUDI Wallets in specific cases (Art. 5f). - **YES** EUDI Wallet Provider Requirements - **NO** Not Directly Subject to eIDAS ### RELYING PARTY TRACK: Do you provide online services that require user authentication or trust services? *Reference: Reg. (EU) No 910/2014 (Art. 6 and Art. 25) and (as amended) Art. 5f* - Relying parties are entities that use eID means, trust services, or EUDI Wallets to verify identities or validate electronic transactions. - Public sector relying parties must recognise notified eID schemes from other Member States (Art. 6). - EUDI Wallet acceptance duties are set out in Art. 5f for public sector bodies and certain private relying parties (including very large online platforms) under specific conditions. - When using electronic signatures, an electronic signature cannot be denied legal effect solely for being electronic or non-qualified; qualified signatures have the equivalent legal effect of handwritten signatures (Art. 25(1)-(2)). - **YES** Are you a public sector body providing online public services? - **NO** Not Directly Subject to eIDAS ### RELYING PARTY TRACK: Are you a public sector body providing online public services? *Reference: Reg. (EU) No 910/2014 (Art. 6) and (as amended) Art. 5f(1)* - Public sector bodies have mutual recognition duties for notified eID schemes when eID and authentication are required to access an online public service (Art. 6). - Where Member States require electronic identification and authentication to access an online service provided by a public sector body, they must also accept EUDI Wallets (Art. 5f(1)). - **YES** Public Sector Relying Party Obligations - **NO** Private Sector Relying Party Considerations ## Reference Information ### Trust Service Types (eIDAS 1.0 & 2.0) - Electronic signatures: legal effects and requirements are set out in Art. 25-27. - Electronic seals: legal effects and requirements are set out in Art. 35-37. - Electronic time stamps: legal effects and requirements are set out in Art. 41-42. - Electronic registered delivery: requirements are set out in Art. 43-44. - Website authentication: qualified certificates for website authentication are governed by Art. 45 and Annex IV. - Electronic attestations of attributes: legal effects and requirements are set out in Art. 45b-45h (and related annexes). - Electronic archiving services: legal effects and requirements are set out in Art. 45i-45j. - Electronic ledgers: legal effects and requirements are set out in Art. 45k-45l. - Remote management services: management of remote qualified signature and seal creation devices is governed by Art. 29a and Art. 39a. ### Key ETSI Technical Standards for Trust Services - ETSI EN 319 401 - General Policy Requirements for Trust Service Providers - ETSI EN 319 411-1 - Policy and security requirements for TSPs issuing certificates - Qualified certificates for electronic signatures - ETSI EN 319 411-2 - Policy requirements for certification authorities issuing non-qualified certificates - ETSI EN 319 412 series - Certificate Profiles (including qualified certificates, web authentication certificates, and certificates with attributes) - ETSI EN 319 421 - Policy and security requirements for time-stamping authorities - ETSI EN 319 422 - Time-stamp token profiles - ETSI TS 119 431 series - Remote signature creation - Policy and security requirements - ETSI TS 119 432 - Protocols for remote signature creation - ETSI EN 319 521 - JAdES (JSON Advanced Electronic Signatures) - ETSI EN 319 122-1 - CAdES (CMS Advanced Electronic Signatures) baseline profile - ETSI EN 319 132-1 - PAdES (PDF Advanced Electronic Signatures) baseline profile - ETSI EN 319 142-1 - XAdES (XML Advanced Electronic Signatures) baseline profile - ETSI TS 119 612 - Trusted Lists (TL) specifying how Member States publish lists of qualified trust service providers ### Supervision and Enforcement - Qualified trust service providers are audited at their own expense at least every 24 months by a conformity assessment body (Art. 20(1)). - The supervisory body may at any time audit or request a conformity assessment to confirm compliance (Art. 20(2)). - If requirements are not met, the supervisory body can require remedies and may withdraw qualified status (Art. 20(3)). - Trust service providers notify the supervisory body when they intend to start providing a qualified trust service, together with a conformity assessment report (Art. 21(1)). - Each Member State establishes and publishes trusted lists with qualified trust service providers and the qualified trust services they provide (Art. 22(1)). - Member States notify the Commission about where trusted lists are published and the certificates used to sign or seal them (Art. 22(3)-(4)). - Liability and burden of proof rules for trust service providers are set out in Art. 13 (including limitations on use, Art. 13(2)). ### Levels of Assurance (LoA) for eID Schemes - eIDAS defines three Levels of Assurance (LoA) for electronic identification means (Implementing Regulation 2015/1502): - LoA Low - provides limited confidence in the claimed or asserted identity of a person; suitable for low-risk transactions. - LoA Substantial - provides substantial confidence in the claimed or asserted identity of a person; suitable for medium-risk transactions (e.g., accessing government databases). - LoA High - provides the highest level of confidence in the claimed or asserted identity of a person; suitable for high-risk transactions (e.g., financial transactions, accessing sensitive data). - Each notified eID scheme must specify which LoA(s) it supports. - Member States may require a minimum LoA for accessing specific online services. - Assurance levels are based on the strength of the identity proofing, authentication mechanisms, and management processes. ### EUDI Wallet Architecture and Reference Framework (ARF) - The European Digital Identity Wallet Architecture and Reference Framework (ARF) is a Commission publication that describes architecture and interoperability for the EUDI Wallet ecosystem. - eIDAS requires key wallet properties such as open-source licensing for application software components (Art. 5a(3)) and user control, data separation and anti-tracking safeguards (Art. 5a(14)-(16)). - eIDAS also references implementing acts for detailed technical specifications and procedures (for example Art. 5a(23) and related provisions). ### Legal Effects of Qualified Trust Services - Qualified electronic signatures: have the equivalent legal effect of handwritten signatures (Art. 25(2)). - Qualified electronic seals: enjoy a presumption of integrity of the data and correctness of the origin of that data (Art. 35(2)). - Qualified electronic time stamps: enjoy a presumption of accuracy of the date and time indicated and integrity of the bound data (Art. 41(2)). - Qualified electronic registered delivery: data sent/received enjoys presumptions of integrity, sending by identified sender, receipt by identified addressee, and accuracy of date/time (Art. 43(2)). - Qualified certificates for website authentication: are recognised by providers of web browsers, which must display identity data in a user-friendly manner (Art. 45(1a)). - Non-qualified electronic signatures, seals, time stamps and registered delivery cannot be denied legal effect and admissibility solely because they are electronic or do not meet qualified requirements (Art. 25(1), Art. 35(1), Art. 41(1), Art. 43(1)). ### Liability Framework for Trust Services - Trust service providers are liable for damage caused intentionally or negligently due to a failure to comply with obligations under the regulation (Art. 13(1)). - For non-qualified trust service providers, the burden of proving intention or negligence lies with the person claiming damage (Art. 13(1)). - For qualified trust service providers, intention or negligence is presumed unless the provider proves the damage occurred without intention or negligence (Art. 13(1)). - Where limitations on the use of services are duly communicated in advance and recognisable to third parties, trust service providers are not liable for damages arising from use exceeding those limitations (Art. 13(2)). - Any person who suffers material or non-material damage from an infringement has the right to seek compensation in accordance with Union and national law (Art. 13(1)). ### Data Protection and Privacy in eIDAS - EUDI Wallets must enable user-friendly, transparent and user-traceable control over requesting, obtaining, storing, deleting, sharing and presenting identification data and attestations (Art. 5a(4)(a)). - Wallets provide a transaction log/dashboard and enable users to request erasure by relying parties and report suspicious requests to data protection authorities (Art. 5a(4)(d)(ii)-(iii)). - Wallet providers must not collect unnecessary usage information or combine wallet data with data from other services unless the user expressly requests otherwise, and must keep wallet personal data logically separate from other data (Art. 5a(14)). - Use of EUDI Wallets is voluntary; access to services must remain possible through other identification and authentication means (Art. 5a(15)). - Processing of personal data for the EUDI Wallet as an electronic identification means must comply with appropriate and effective data protection measures and demonstrate compliance with GDPR (Art. 5a(17)). ### International Recognition and Third Countries - Qualified trust services from a third country or an international organisation can be recognised as legally equivalent to qualified trust services in the Union when recognised by implementing acts or by an agreement between the Union and the third country or international organisation (Art. 14(1)). - Recognition is limited to the conditions in the regulation and the relevant implementing acts or international agreement (Art. 14(1)). ### Certification and Accreditation for Trust Services - A conformity assessment body is defined by reference to Regulation (EC) No 765/2008 and must be accredited under that Regulation (Art. 3(18)). - Qualified trust service providers are audited at least every 24 months by a conformity assessment body and submit the resulting conformity assessment report to the supervisory body (Art. 20(1)). - When intending to start providing a qualified trust service, the provider notifies the supervisory body and provides a conformity assessment report (Art. 21(1)). - Trusted lists support verification of qualified status and services across Member States (Art. 22). - EUDI Wallet conformity is certified by conformity assessment bodies designated by Member States (Art. 5c(1)). - Qualified electronic signature creation devices must meet Annex II requirements; Member States notify the Commission about certified devices (Art. 3(23) and Art. 30). ### European Digital Identity Cooperation Group - The Commission establishes the European Digital Identity Cooperation Group to support and facilitate Member States' cross-border cooperation and exchange of information on trust services, EUDI Wallets and notified eID schemes (Art. 46e(1)). - The Cooperation Group is composed of representatives appointed by Member States and of the Commission, is chaired by the Commission, and the Commission provides its Secretariat (Art. 46e(2)). - Relevant stakeholders may be invited on an ad hoc basis as observers; ENISA is invited as an observer for relevant cybersecurity aspects (Art. 46e(3)-(4)). - Tasks include advising the Commission in the preparation of implementing and delegated acts, exchanging best practices, and organising peer reviews of eID schemes to be notified (Art. 46e(5)). ### Technical Implementation Guidance - For trust services, align implementations with relevant ETSI standards for baseline profiles and policy requirements (for example ETSI EN/TS 319 series). - For trusted lists and qualified trust service verification, align with the trusted list specifications referenced in ETSI TS 119 612 and the eIDAS trusted list framework (Art. 22). - For EUDI Wallet implementations, track Commission and Member State technical documentation (including the ARF) and implementing acts referenced in the regulation (for example Art. 5a(23) and Art. 5f). - Use Commission-provided implementation resources where relevant (for example the Digital Signature Service documentation under EU Digital Building Blocks). ### Transition from eIDAS 1.0 to eIDAS 2.0 - Regulation (EU) 2024/1183 amends the eIDAS framework, introducing the EUDI Wallet (Art. 5a) and new reliance/acceptance duties for EUDI Wallets (Art. 5f). - The amended regulation also adds governance provisions, including wallet supervision (Art. 46a) and the European Digital Identity Cooperation Group (Art. 46e). - Key rollout timelines are linked to implementing acts referenced in the amended articles (for example Art. 5a(1) and Art. 5f(2)). - Relying parties should assess whether they fall into mandatory acceptance categories under Art. 5f(2)-(3) and plan integration accordingly. ### Sectors referenced for EUDI Wallet acceptance - Art. 5f(2) lists areas where private relying parties may be required to accept EUDI Wallets when strong user authentication for online identification is required by law or contract, including: transport, energy, banking, financial services, social security, health, drinking water, postal services, digital infrastructure, education and telecommunications. - Microenterprises and small enterprises are excluded from the Art. 5f(2) mandatory acceptance duty. - Mandatory acceptance under Art. 5f(2) applies only upon the voluntary request of the user and is linked to timelines triggered by implementing acts. ## Possible Outcomes ### [QTSP] Qualified Trust Service Provider Requirements Highest assurance level with legal effect - Notify the supervisory body when you intend to start providing a qualified trust service, together with a conformity assessment report (Art. 21(1)). - Undergo audits at least every 24 months by a conformity assessment body and submit the resulting conformity assessment report to the supervisory body (Art. 20(1)). - Inform the supervisory body at the latest one month before planned audits and allow participation as an observer upon request (Art. 20(1a)). - Remain listed on the Member State trusted list for qualified trust service providers and their qualified trust services (Art. 22). - Plan for enforcement outcomes: the supervisory body can require remedies and withdraw qualified status when requirements are not met (Art. 20(3)). - Use appropriate standards and specifications where relevant to demonstrate compliance (for example ETSI EN/TS 319 series referenced by common audit and conformity practices). - Understand liability and burden of proof rules (Art. 13), including limitations on use that are recognisable to third parties (Art. 13(2)). ### [NON-QUALIFIED TSP] Non-Qualified Trust Service Provider Requirements Standard trust services with supervisory oversight - Adopt policies and take measures to manage legal, business and operational risks to the provision of the non-qualified trust service (Art. 19a(1)(a)). - Notify the supervisory body and other parties as required when security breaches or disruptions have a significant impact, without undue delay and in any case within 24 hours of becoming aware (Art. 19a(1)(b)). - Understand liability and burden of proof rules: for non-qualified trust service providers, the burden of proving intention or negligence lies with the person claiming damage (Art. 13(1)). - Non-qualified electronic signatures and seals cannot be denied legal effect and admissibility solely because they are electronic or not qualified (Art. 25(1) and Art. 35(1)). - If you intend to offer qualified trust services, follow the qualified trust service initiation and supervision track (Art. 21 and Art. 20). ### [eID SCHEME] eID Scheme Notification and Recognition Cross-border recognition for notified schemes - Notification (Art. 9(1)): the notifying Member State provides the Commission with a description of the scheme (including assurance levels), information on issuers and authorities, and key information on supervision, liability and suspension/revocation arrangements. - Publication (Art. 9(2)-(3)): the Commission publishes a list of notified eID schemes in the Official Journal and updates it when changes are notified. - Mutual recognition (Art. 6): when eID and authentication are required to access an online service provided by a public sector body, Member States must recognise eID means issued under another Member State's notified scheme (subject to the regulation's conditions). - Security breaches (Art. 10): if a notified scheme or its authentication is breached or compromised affecting reliability, the notifying Member State must suspend or revoke cross-border authentication and inform other Member States and the Commission. - Levels of assurance: notified schemes specify assurance levels (low, substantial, high); Implementing Regulation (EU) 2015/1502 provides technical specifications for assurance levels. ### [EUDI WALLET PROVIDER] EUDI Wallet Provider Requirements Issuing and managing European Digital Identity Wallets - Provide EUDI Wallets via one of the allowed provision models: directly by a Member State, under mandate, or independently but recognised by the Member State (Art. 5a(2)). - Ensure the wallet enables user-controlled, transparent and traceable handling of person identification data and (where applicable) electronic attestations of attributes, including selective disclosure (Art. 5a(4)(a)). - Ensure the wallet supports qualified electronic signatures or seals (Art. 5a(4)(e)) and supports common protocols and interfaces, including for relying party authentication and wallet validity verification (Art. 5a(5)(a)). - Offer natural persons the ability to sign by means of qualified electronic signatures by default and free of charge, with proportionate limits for non-professional purposes as permitted (Art. 5a(5)(g)). - Ensure users have full control and that personal data relating to the wallet is kept logically separate from other data held by the provider (Art. 5a(14)). - Enable users to request technical support and report incidents (Art. 5a(10)). ### [PUBLIC RELYING PARTY] Public Sector Relying Party Obligations Mandatory recognition of notified eID schemes - Recognise and accept eID means issued under notified eID schemes from other Member States for accessing online public services (Art. 6(1)). - Accept EUDI Wallets where electronic identification and authentication are required to access an online service provided by a public sector body (Art. 5f(1)). - If your public service requires an advanced electronic signature, recognise advanced signatures based on qualified certificates and qualified electronic signatures in at least the formats or methods defined by implementing acts (Art. 27(1)-(2)). - Ensure compliance with GDPR when processing personal data obtained from eID means or EUDI Wallets. - Where you rely on qualified trust services, use trusted lists to check qualified status and relevant service listings (Art. 22). ### [PRIVATE RELYING PARTY] Private Sector Relying Party Considerations Optional or mandatory acceptance depending on sector - Private relying parties may choose to accept notified eID schemes and EUDI Wallets beyond mandatory cases. - If you are required by Union or national law (or by contractual obligation) to use strong user authentication for online identification, you must accept EUDI Wallets no later than 36 months after the relevant implementing acts enter into force, and only upon the voluntary request of the user (microenterprises and small enterprises are excluded) (Art. 5f(2)). - If you are a very large online platform that requires user authentication for access to online services, you must accept and facilitate EUDI Wallets for user authentication upon the voluntary request of the user and for the minimum data necessary for the service (Art. 5f(3)). - When using electronic signatures, an electronic signature cannot be denied legal effect solely for being electronic or non-qualified; qualified signatures have the equivalent legal effect of handwritten signatures (Art. 25(1)-(2)). - Where you rely on qualified trust services, use trusted lists to check qualified status and relevant service listings (Art. 22). ### [OUT OF SCOPE] Not Directly Subject to eIDAS May still benefit from using eIDAS services - If you do not provide trust services, operate an eID scheme, issue EUDI Wallets, or provide services requiring authentication, eIDAS does not impose direct obligations on you. - However, you may still benefit from using eIDAS-compliant eID and trust services as a user or relying party. - Consider adopting qualified eSignatures, eSeals, or eTimestamps to improve security and legal certainty in electronic transactions. - Monitor eIDAS 2.0 implementation: EUDI Wallet acceptance duties apply to some relying parties under specific conditions (Art. 5f). ## eIDAS Timeline | Date | Event | Reference | | --- | --- | --- | | 2014-07-23 | eIDAS adopted (Regulation (EU) No 910/2014) | Reg. (EU) No 910/2014 | | 2014-08-28 | eIDAS published in the Official Journal (OJ L 257) | Reg. (EU) No 910/2014 | | 2016-07-01 | Trust services provisions apply | Reg. (EU) No 910/2014 (Art. 52(2)) | | 2018-09-29 | Mandatory cross-border recognition of notified eID schemes | Reg. (EU) No 910/2014 (Art. 6) - reported by ENISA | | 2024-04-11 | eIDAS amended by Regulation (EU) 2024/1183 (date of act) | Reg. (EU) 2024/1183 | | 2024-04-30 | Regulation (EU) 2024/1183 published in the Official Journal | Reg. (EU) 2024/1183 | | 2026-12-31 | Target timeline: Member States provide EUDI Wallets (end of 2026) | Policy timeline (EU Digital Identity) | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2001-06-01 | ETSI TS 101 862 (QCStatements) historical publication (V1.2.1) | Technical Standards | | | 2002-04-01 | ETSI TS 102 023 (time-stamping) historical publication (V1.1.1) | Technical Standards | | | 2003-01-01 | ETSI TS 102 023 (time-stamping) historical publication (V1.2.1) | Technical Standards | | | 2003-03-01 | ETSI SR 002 176 (cryptographic suites) publication (V1.1.1) | Technical Standards | | | 2004-03-01 | ETSI TS 102 280 (qualified certificates profile) historical publication (V1.1.1) | Technical Standards | | | 2004-03-01 | ETSI TS 101 862 (QCStatements) withdrawn publication (V1.3.1) | Technical Standards | | | 2005-07-01 | ETSI TS 102 176-1 (cryptographic suites) historical publication (V1.2.1) | Technical Standards | | | 2007-11-01 | ETSI TS 102 176-1 (cryptographic suites) historical publication (V2.0.0) | Technical Standards | | | 2008-10-01 | ETSI TS 102 023 (time-stamping) historical publication (V1.2.2) | Technical Standards | | | 2013-01-01 | ETSI EN 319 401 publication (V1.1.1) | Technical Standards | | | 2013-06-01 | ETSI TS 119 612 publication (V1.1.1) | Technical Standards | | | 2014-07-23 | eIDAS Regulation (EU) No 910/2014 adopted | Legislation | | | 2014-08-28 | eIDAS published in the Official Journal (OJ L 257) | Legislation | | | 2014-09-17 | Commission empowered to adopt delegated acts under eIDAS (reported) | Legislation | | | 2014-11-01 | ETSI TS 119 312 publication (V1.1.1) | Technical Standards | | | 2015-02-24 | Commission Implementing Decision (EU) 2015/296 adopted | Implementation | | | 2015-07-01 | ETSI TS 119 421 withdrawn publication (V1.0.1) | Technical Standards | | | 2015-07-01 | ETSI TS 119 132-1 withdrawn publication (V1.0.1) | Technical Standards | | | 2015-09-08 | Commission Implementing Regulation (EU) 2015/1501 adopted | Legislation | | | 2015-09-08 | Commission Implementing Regulation (EU) 2015/1502 adopted | Legislation | | | 2015-09-18 | Commission deadline for trusted list specifications (implementing acts) | Implementation | | | 2015-09-18 | Commission deadline for reference formats of advanced e-signatures (implementing acts) | Implementation | | | 2015-09-18 | Commission deadline for assurance-level specifications (implementing acts) | Implementation | | | 2016-02-01 | ETSI EN 319 411-1 publication (V1.1.1) | Technical Standards | | | 2016-02-01 | ETSI EN 319 411-2 publication (V2.1.1) | Technical Standards | | | 2016-02-01 | ETSI EN 319 412-3 publication (V1.1.1) | Technical Standards | | | 2016-02-01 | ETSI EN 319 412-5 publication (V2.1.1) | Technical Standards | | | 2016-03-01 | ETSI EN 319 421 publication (V1.1.1) | Technical Standards | | | 2016-04-01 | ETSI EN 319 142-1 publication (V1.1.1) | Technical Standards | | | 2016-04-01 | ETSI TS 119 612 publication (V2.2.1) | Technical Standards | | | 2016-04-25 | Commission Implementing Decision (EU) 2016/650 adopted | Legislation | | | 2016-07-01 | eIDAS trust-services provisions apply | Legislation | | | 2017-01-01 | eIDAS Made Easy (EC guidebook) published | Implementation | | | 2017-06-01 | ETSI EN 319 401 change history milestone (V2.2.0) | Technical Standards | | | 2017-06-01 | ETSI EN 319 411-1 publication (V1.2.0) | Technical Standards | | | 2017-07-01 | Trusted-lists conformity report deadline (TS 119 612) | Implementation | | | 2017-09-01 | Germany notifies first eID scheme (reported) | Implementation | | | 2017-09-01 | DSS release v5.1 | Implementation | | | 2017-11-01 | ETSI EN 319 412-5 publication (V2.2.1) | Technical Standards | | | 2017-12-19 | ENISA guidelines on supervision of qualified trust service providers published | Implementation | | | 2018-01-01 | ETSI EN 319 401 change history milestone (V2.2.1) | Technical Standards | | | 2018-04-01 | ETSI EN 319 401 publication (V2.2.1) | Technical Standards | | | 2018-04-01 | ETSI EN 319 411-1 publication (V1.2.2) | Technical Standards | | | 2018-04-01 | DSS release v5.3.RC1 | Implementation | | | 2018-05-01 | ETSI EN 319 521 document history milestone (V1.0.0) | Technical Standards | | | 2018-05-01 | ETSI TS 119 495 publication (V1.1.1) | Technical Standards | | | 2018-07-01 | ETSI TS 119 495 version milestone (V1.1.2 / 2018-07) | Technical Standards | | | 2018-09-01 | ETSI EN 319 522-1 publication (V1.1.1) | Technical Standards | | | 2018-09-01 | ETSI EN 319 522-2 publication (V1.1.1) | Technical Standards | | | 2018-09-29 | Mandatory mutual recognition of notified eID schemes comes into force (reported) | Legislation | | | 2018-11-01 | ENISA assessment of standards related to eIDAS published | Implementation | | | 2018-12-01 | ETSI TS 119 431-1 publication (V1.1.1) | Technical Standards | | | 2018-12-01 | ETSI TS 119 431-2 publication (V1.1.1) | Technical Standards | | | 2019-01-01 | DSS release v5.4 | Implementation | | | 2019-02-01 | ETSI EN 319 521 adopted and published (V1.1.1 / 2019-02) | Technical Standards | | | 2019-02-01 | ETSI TS 119 312 publication (V1.3.1) | Technical Standards | | | 2019-03-01 | ETSI TS 119 432 publication (V1.1.1) | Technical Standards | | | 2019-04-02 | ETSI press release: cloud-based digital signature specifications | Technical Standards | | | 2019-05-31 | ETSI EN 319 521 latest announcement date (doa) | Technical Standards | | | 2019-10-01 | DSS release v5.5 | Implementation | | | 2019-11-30 | ETSI EN 319 521 national publication/withdrawal date (dop/e, dow) | Technical Standards | | | 2020-03-01 | ENISA report: eIDAS compliant eID solutions published | Implementation | | | 2020-07-01 | eIDAS review due (reported) | Legislation | | | 2020-08-01 | DSS release v5.7 | Implementation | | | 2020-10-01 | ETSI TS 119 432 publication (V1.2.1 / 2020-10) | Technical Standards | | | 2021-03-01 | ENISA report: recommendations for QTSPs published | Implementation | | | 2021-05-01 | ETSI EN 319 401 publication (V2.3.1) | Technical Standards | | | 2021-05-01 | ETSI TS 119 431-1 publication (V1.2.1) | Technical Standards | | | 2021-06-03 | Commission Recommendation launches EUDI Wallet toolbox work | EUDI Wallet | | | 2021-09-01 | DSS release v5.9 | Implementation | | | 2022-01-01 | EUDI Wallet prototype procured (reported) | Pilot Programs | | | 2022-02-22 | EUDI Architecture & Reference Framework outline published | EUDI Wallet | | | 2022-10-01 | DSS release v5.11 | Implementation | | | 2022-12-14 | Directive (EU) 2022/2555 signed (amends eIDAS) | Legislation | | | 2022-12-27 | Directive (EU) 2022/2555 published (OJ L 333) | Legislation | | | 2023-01-01 | EUDI Wallet large-scale pilots initiated (reported) | Pilot Programs | | | 2023-02-10 | EUDI Wallet Architecture and Reference Framework (ARF) published | EUDI Wallet | | | 2023-05-01 | ETSI EN 319 421 adopted and published (V1.2.1 / 2023-05) | Technical Standards | | | 2023-06-12 | ENISA publication: Trust services secure move to cloud (eIDAS ecosystem) | Implementation | | | 2023-06-26 | ETSI EN 319 122-1 adopted (V1.3.1 / 2023-06) | Technical Standards | | | 2023-07-03 | ENISA publication: Digital Identity Standards | Implementation | | | 2023-08-01 | ETSI TS 119 312 published (V1.4.3 / 2023-08) | Technical Standards | | | 2023-08-31 | ETSI EN 319 421 latest announcement date (doa) | Technical Standards | | | 2023-09-21 | ETSI EN 319 412-3 adopted (V1.3.1 / 2023-09) | Technical Standards | | | 2023-09-21 | ETSI EN 319 412-1 adopted (V1.5.1 / 2023-09) | Technical Standards | | | 2023-09-21 | ETSI EN 319 412-5 adopted (V2.4.1 / 2023-09) | Technical Standards | | | 2023-09-30 | ETSI EN 319 122-1 latest announcement date (doa) | Technical Standards | | | 2023-10-04 | ETSI EN 319 411-1 adopted (V1.4.1 / 2023-10) | Technical Standards | | | 2023-11-01 | DSS release v5.13.RC1 | Implementation | | | 2023-12-31 | ETSI EN 319 412-3 latest announcement date (doa) | Technical Standards | | | 2024-01-03 | ETSI EN 319 522-1 adopted (V1.2.1 / 2024-01) | Technical Standards | | | 2024-01-03 | ETSI EN 319 522-2 adopted (V1.2.1 / 2024-01) | Technical Standards | | | 2024-01-03 | ETSI EN 319 522-3 adopted (V1.2.1 / 2024-01) | Technical Standards | | | 2024-01-15 | ETSI EN 319 142-1 adopted (V1.2.1 / 2024-01) | Technical Standards | | | 2024-01-31 | ETSI EN 319 411-1 latest announcement date (doa) | Technical Standards | | | 2024-02-29 | ETSI EN 319 421 national publication/withdrawal date (dop/e, dow) | Technical Standards | | | 2024-03-12 | ENISA publication: Remote ID Proofing (good practices) | Implementation | | | 2024-03-31 | ETSI EN 319 122-1 national publication/withdrawal date (dop/e, dow) | Technical Standards | | | 2024-04-11 | EUDI Regulation (EU) 2024/1183 signed (date of act) | Legislation | | | 2024-04-30 | EUDI Regulation published in the Official Journal | Legislation | | | 2024-04-30 | ETSI EN 319 522-1 latest announcement date (doa) | Technical Standards | | | 2024-04-30 | ETSI EN 319 522-2 latest announcement date (doa) | Technical Standards | | | 2024-04-30 | ETSI EN 319 522-3 latest announcement date (doa) | Technical Standards | | | 2024-04-30 | ETSI EN 319 142-1 latest announcement date (doa) | Technical Standards | | | 2024-05-21 | Amended eIDAS scope extends (as referenced in TS 119 612) | Legislation | | | 2024-05-30 | ETSI EN 319 401 adopted (V3.1.1 / 2024-06) | Technical Standards | | | 2024-06-01 | ETSI EN 319 401 published (V3.1.1 / 2024-06) | Technical Standards | | | 2024-06-30 | ETSI EN 319 412-3 national publication/withdrawal date (dop/e, dow) | Technical Standards | | | 2024-07-01 | DSS release 6.1.RC1 | Implementation | | | 2024-07-31 | ETSI EN 319 411-1 national publication/withdrawal date (dop/e, dow) | Technical Standards | | | 2024-08-31 | ETSI EN 319 401 latest announcement date (doa) | Technical Standards | | | 2024-09-24 | ENISA support for EUDI Wallet certification (reported) | Pilot Programs | | | 2024-10-18 | eIDAS consolidated text reference date (2024-10-18) | Legislation | | | 2024-10-31 | ETSI EN 319 142-1 national publication/withdrawal date (dop/e, dow) | Technical Standards | | | 2024-10-31 | ETSI EN 319 522-1 national publication/withdrawal date (dop/e, dow) | Technical Standards | | | 2024-10-31 | ETSI EN 319 522-2 national publication/withdrawal date (dop/e, dow) | Technical Standards | | | 2024-10-31 | ETSI EN 319 522-3 national publication/withdrawal date (dop/e, dow) | Technical Standards | | | 2024-11-01 | ETSI TS 119 612 published (V2.3.1 / 2024-11) | Technical Standards | | | 2024-11-21 | Commission deadline for EUDI Wallet technical specifications (reported) | EUDI Wallet | | | 2024-11-28 | Commission adopts implementing regulations for EUDI Wallets (reported) | EUDI Wallet | | | 2024-12-01 | ETSI TS 119 312 published (V1.5.1 / 2024-12) | Technical Standards | | | 2024-12-01 | ETSI TS 119 431-1 version milestone (V1.3.1 / 2024-12) | Technical Standards | | | 2024-12-04 | Implementing regulation for EUDI Wallets page published | EUDI Wallet | | | 2025-01-01 | EUDI Wallet pilots scheduled to continue until 2025 (reported) | Pilot Programs | | | 2025-02-01 | ETSI TS 119 461 published (V2.1.1 / 2025-02) | Technical Standards | | | 2025-02-28 | ETSI EN 319 401 national publication/withdrawal date (dop/e, dow) | Technical Standards | | | 2025-03-01 | DSS release v6.0.1 | Implementation | | | 2025-03-18 | Commission deadline for eID peer review procedural arrangements (implementing acts) | Implementation | | | 2025-03-24 | ETSI EN 319 411-1 adopted (V1.5.1 / 2025-04) | Technical Standards | | | 2025-04-09 | Corrigendum referenced for Regulation (EU) 2024/1183 | Legislation | | | 2025-05-21 | Commission deadline for additional implementing acts (reported) | EUDI Wallet | | | 2025-06-03 | ETSI EN 319 411-2 adopted (V2.6.1 / 2025-06) | Technical Standards | | | 2025-06-12 | ETSI EN 319 412-2 adopted (V2.4.1 / 2025-06) | Technical Standards | | | 2025-06-12 | ETSI EN 319 412-5 adopted (V2.5.1 / 2025-06) | Technical Standards | | | 2025-09-30 | ETSI EN 319 411-2 latest announcement date (doa) | Technical Standards | | | 2025-09-30 | ETSI EN 319 412-2 latest announcement date (doa) | Technical Standards | | | 2025-09-30 | ETSI EN 319 412-5 latest announcement date (doa) | Technical Standards | | | 2025-11-19 | Commission proposes European Business Wallets (reported) | Pilot Programs | | | 2026-03-31 | ETSI EN 319 411-2 national publication/withdrawal date (dop/e, dow) | Technical Standards | | | 2026-03-31 | ETSI EN 319 412-2 national publication/withdrawal date (dop/e, dow) | Technical Standards | | | 2026-03-31 | ETSI EN 319 412-5 national publication/withdrawal date (dop/e, dow) | Technical Standards | | | 2026-04-28 | Trusted Lists TLv6 specifications apply (reported) | Implementation | | | 2026-05-21 | Commission deadline to review eIDAS application and report | Implementation | | | 2026-05-21 | Legacy qualified trust service providers must submit conformity assessment report | Implementation | | | 2026-12-31 | Identity-proofing testing/evaluation deadlines (ETSI TS 119 461) | Technical Standards | | | 2026-12-31 | Member States must provide EUDI Wallets by end of 2026 (reported) | EUDI Wallet | | | 2027-05-21 | Transitional period ends for legacy secure signature creation devices | Implementation | | | 2030-05-21 | Commission periodic progress report deadline (and every four years) | Implementation | | **Event details:** - **2001-06-01 - ETSI TS 101 862 (QCStatements) historical publication (V1.2.1)**: Document history entry: V1.2.1 published as ETSI TS 101 862 (historical). - **2002-04-01 - ETSI TS 102 023 (time-stamping) historical publication (V1.1.1)**: Document history entry: V1.1.1 published as ETSI TS 102 023 (historical). - **2003-01-01 - ETSI TS 102 023 (time-stamping) historical publication (V1.2.1)**: Document history entry: V1.2.1 published as ETSI TS 102 023 (historical). - **2003-03-01 - ETSI SR 002 176 (cryptographic suites) publication (V1.1.1)**: Document history entry: V1.1.1 published as ETSI SR 002 176. - **2004-03-01 - ETSI TS 102 280 (qualified certificates profile) historical publication (V1.1.1)**: Document history entry: V1.1.1 published as ETSI TS 102 280 (historical). - **2004-03-01 - ETSI TS 101 862 (QCStatements) withdrawn publication (V1.3.1)**: Document history entry: V1.3.1 published as ETSI TS 101 862 (withdrawn). - **2005-07-01 - ETSI TS 102 176-1 (cryptographic suites) historical publication (V1.2.1)**: Document history entry: V1.2.1 published as ETSI TS 102 176-1 (historical). - **2007-11-01 - ETSI TS 102 176-1 (cryptographic suites) historical publication (V2.0.0)**: Document history entry: V2.0.0 published as ETSI TS 102 176-1 (historical). - **2008-10-01 - ETSI TS 102 023 (time-stamping) historical publication (V1.2.2)**: Document history entry: V1.2.2 published as ETSI TS 102 023 (historical). - **2013-01-01 - ETSI EN 319 401 publication (V1.1.1)**: Document history entry: V1.1.1 published (January 2013). - **2013-06-01 - ETSI TS 119 612 publication (V1.1.1)**: Document history entry: V1.1.1 published (June 2013). - **2014-07-23 - eIDAS Regulation (EU) No 910/2014 adopted**: Regulation (EU) No 910/2014 date: 23 July 2014. - **2014-08-28 - eIDAS published in the Official Journal (OJ L 257)**: Official Journal reference: OJ L 257, 28.8.2014, p. 73. - **2014-09-17 - Commission empowered to adopt delegated acts under eIDAS (reported)**: Consolidated eIDAS timeline: the power to adopt delegated acts is conferred on the Commission for an indeterminate period from 17 September 2014. - **2014-11-01 - ETSI TS 119 312 publication (V1.1.1)**: Document history entry: V1.1.1 published (November 2014). - **2015-02-24 - Commission Implementing Decision (EU) 2015/296 adopted**: Commission Implementing Decision (EU) 2015/296 date: 24 February 2015 (procedural arrangements for cooperation between Member States). - **2015-07-01 - ETSI TS 119 421 withdrawn publication (V1.0.1)**: Document history entry: V1.0.1 published as ETSI TS 119 421 (withdrawn). - **2015-07-01 - ETSI TS 119 132-1 withdrawn publication (V1.0.1)**: Document history entry: V1.0.1 published as ETSI TS 119 132-1 (withdrawn). - **2015-09-08 - Commission Implementing Regulation (EU) 2015/1501 adopted**: Commission Implementing Regulation (EU) 2015/1501 date: 8 September 2015 (interoperability framework). - **2015-09-08 - Commission Implementing Regulation (EU) 2015/1502 adopted**: Commission Implementing Regulation (EU) 2015/1502 date: 8 September 2015 (assurance levels for eID means). - **2015-09-18 - Commission deadline for trusted list specifications (implementing acts)**: Consolidated eIDAS timeline: by 18 September 2015 the Commission must specify required trusted list information and define technical specifications and formats for trusted lists. - **2015-09-18 - Commission deadline for reference formats of advanced e-signatures (implementing acts)**: Consolidated eIDAS timeline: by 18 September 2015 the Commission must define reference formats (or reference methods) for advanced electronic signatures where alternative formats are used. - **2015-09-18 - Commission deadline for assurance-level specifications (implementing acts)**: Consolidated eIDAS timeline: by 18 September 2015 the Commission must set minimum technical specifications, standards and procedures for specifying assurance levels (low, substantial, high) for eID means. - **2016-02-01 - ETSI EN 319 411-1 publication (V1.1.1)**: Document history entry: V1.1.1 published (February 2016). - **2016-02-01 - ETSI EN 319 411-2 publication (V2.1.1)**: Document history entry: V2.1.1 published (February 2016). - **2016-02-01 - ETSI EN 319 412-3 publication (V1.1.1)**: Document history entry: V1.1.1 published (February 2016). - **2016-02-01 - ETSI EN 319 412-5 publication (V2.1.1)**: Document history entry: V2.1.1 published (February 2016). - **2016-03-01 - ETSI EN 319 421 publication (V1.1.1)**: Document history entry: V1.1.1 published (March 2016). - **2016-04-01 - ETSI EN 319 142-1 publication (V1.1.1)**: Change history entry: V1.1.1 published (April 2016). - **2016-04-01 - ETSI TS 119 612 publication (V2.2.1)**: Document history entry: V2.2.1 published (April 2016). - **2016-04-25 - Commission Implementing Decision (EU) 2016/650 adopted**: Commission Implementing Decision (EU) 2016/650 date: 25 April 2016 (standards for security assessment of qualified signature and seal creation devices). - **2016-07-01 - eIDAS trust-services provisions apply**: As of 1 July 2016, provisions relating to trust services are directly applicable in Member States (also used as a key date for trusted-lists migration rules). - **2017-01-01 - eIDAS Made Easy (EC guidebook) published**: Publication copyright year shown as © European Union, 2017. - **2017-06-01 - ETSI EN 319 401 change history milestone (V2.2.0)**: Change history entry: V2.2.0 (June 2017). - **2017-06-01 - ETSI EN 319 411-1 publication (V1.2.0)**: Document history entry: V1.2.0 (June 2017). - **2017-07-01 - Trusted-lists conformity report deadline (TS 119 612)**: ETSI TS 119 612 timeline: one-year anniversary day of Regulation application (1 July 2017) referenced as the date by which a conformity assessment report should be submitted in certain migration rules. - **2017-09-01 - Germany notifies first eID scheme (reported)**: ENISA eID solutions timeline: Germany was the first country to have a notified eID scheme (September 2017). - **2017-09-01 - DSS release v5.1**: Digital Signature Service (DSS) release table: v5.1 (September 2017). - **2017-11-01 - ETSI EN 319 412-5 publication (V2.2.1)**: Change history entry: V2.2.1 published (November 2017). - **2017-12-19 - ENISA guidelines on supervision of qualified trust service providers published**: Publication date shown: 19 December 2017. - **2018-01-01 - ETSI EN 319 401 change history milestone (V2.2.1)**: Change history entry: V2.2.1 (January 2018). - **2018-04-01 - ETSI EN 319 401 publication (V2.2.1)**: Document history entry: V2.2.1 published (April 2018). - **2018-04-01 - ETSI EN 319 411-1 publication (V1.2.2)**: Document history entry: V1.2.2 published (April 2018). - **2018-04-01 - DSS release v5.3.RC1**: Digital Signature Service (DSS) release table: v5.3.RC1 (April 2018). - **2018-05-01 - ETSI EN 319 521 document history milestone (V1.0.0)**: Document history entry: V1.0.0 (May 2018). - **2018-05-01 - ETSI TS 119 495 publication (V1.1.1)**: Document history entry: V1.1.1 published (May 2018). - **2018-07-01 - ETSI TS 119 495 version milestone (V1.1.2 / 2018-07)**: Cover indicates ETSI TS 119 495 V1.1.2 (2018-07). - **2018-09-01 - ETSI EN 319 522-1 publication (V1.1.1)**: Document history entry: V1.1.1 published (September 2018). - **2018-09-01 - ETSI EN 319 522-2 publication (V1.1.1)**: Document history entry: V1.1.1 published (September 2018). - **2018-09-29 - Mandatory mutual recognition of notified eID schemes comes into force (reported)**: ENISA eID solutions timeline: since 29 September 2018, mandatory mutual recognition of notified eID schemes has come into force. - **2018-11-01 - ENISA assessment of standards related to eIDAS published**: Document cover date: November 2018. - **2018-12-01 - ETSI TS 119 431-1 publication (V1.1.1)**: Document history entry: V1.1.1 published (December 2018). - **2018-12-01 - ETSI TS 119 431-2 publication (V1.1.1)**: History table entry: V1.1.1 published (December 2018). - **2019-01-01 - DSS release v5.4**: Digital Signature Service (DSS) release table: v5.4 (January 2019). - **2019-02-01 - ETSI EN 319 521 adopted and published (V1.1.1 / 2019-02)**: Header indicates V1.1.1 (2019-02); national transposition dates list adoption and publication in February 2019. - **2019-02-01 - ETSI TS 119 312 publication (V1.3.1)**: Document history entry: V1.3.1 published (February 2019). - **2019-03-01 - ETSI TS 119 432 publication (V1.1.1)**: Document history entry: ETSI TS 119 432 V1.1.1 published (March 2019). - **2019-04-02 - ETSI press release: cloud-based digital signature specifications**: Press release date: 2 April 2019 (ETSI releases three specifications for cloud-based digital signatures). - **2019-05-31 - ETSI EN 319 521 latest announcement date (doa)**: National transposition dates list the latest announcement date as 31 May 2019. - **2019-10-01 - DSS release v5.5**: Digital Signature Service (DSS) release table: v5.5 (October 2019). - **2019-11-30 - ETSI EN 319 521 national publication/withdrawal date (dop/e, dow)**: National transposition dates list both dop/e and dow as 30 November 2019. - **2020-03-01 - ENISA report: eIDAS compliant eID solutions published**: Document cover date: March 2020. - **2020-07-01 - eIDAS review due (reported)**: ENISA eID solutions timeline: eIDAS Regulation review due by July 2020. - **2020-08-01 - DSS release v5.7**: Digital Signature Service (DSS) release table: v5.7 (August 2020). - **2020-10-01 - ETSI TS 119 432 publication (V1.2.1 / 2020-10)**: Header indicates ETSI TS 119 432 V1.2.1 (2020-10). - **2021-03-01 - ENISA report: recommendations for QTSPs published**: Publication month shown: March 2021. - **2021-05-01 - ETSI EN 319 401 publication (V2.3.1)**: Document history entry: V2.3.1 published (May 2021). - **2021-05-01 - ETSI TS 119 431-1 publication (V1.2.1)**: Document history entry: V1.2.1 published (May 2021). - **2021-06-03 - Commission Recommendation launches EUDI Wallet toolbox work**: On 3 June 2021, the Commission adopted a Recommendation calling on Member States to develop a common Union toolbox including a technical Architecture and Reference Framework (ARF) and related standards/specifications. - **2021-09-01 - DSS release v5.9**: Digital Signature Service (DSS) release table: v5.9 (September 2021). - **2022-01-01 - EUDI Wallet prototype procured (reported)**: Pilot implementation page timeline: prototype procured under the Digital Europe Programme (year-only mention). - **2022-02-22 - EUDI Architecture & Reference Framework outline published**: The eIDAS expert group adopted and published the ARF outline for stakeholder feedback on 22 February 2022. - **2022-10-01 - DSS release v5.11**: Digital Signature Service (DSS) release table: v5.11 (October 2022). - **2022-12-14 - Directive (EU) 2022/2555 signed (amends eIDAS)**: Directive (EU) 2022/2555 (NIS2) dated 14 December 2022 is cited as amending eIDAS (Regulation (EU) No 910/2014). - **2022-12-27 - Directive (EU) 2022/2555 published (OJ L 333)**: Official Journal publication referenced for Directive (EU) 2022/2555: OJ L 333, 27.12.2022. - **2023-01-01 - EUDI Wallet large-scale pilots initiated (reported)**: Pilot implementation page timeline: in 2023, the EU initiated four major pilot programs to evaluate the EU Digital Identity Wallet. - **2023-02-10 - EUDI Wallet Architecture and Reference Framework (ARF) published**: Publication date: 10 February 2023. - **2023-05-01 - ETSI EN 319 421 adopted and published (V1.2.1 / 2023-05)**: Header indicates V1.2.1 (2023-05); date of adoption is listed as May 2023. - **2023-06-12 - ENISA publication: Trust services secure move to cloud (eIDAS ecosystem)**: Publication date shown: 12 June 2023. - **2023-06-26 - ETSI EN 319 122-1 adopted (V1.3.1 / 2023-06)**: Date of adoption: 26 June 2023; header shows V1.3.1 (2023-06). - **2023-07-03 - ENISA publication: Digital Identity Standards**: Publication date shown: 3 July 2023. - **2023-08-01 - ETSI TS 119 312 published (V1.4.3 / 2023-08)**: Header indicates ETSI TS 119 312 V1.4.3 (2023-08). - **2023-08-31 - ETSI EN 319 421 latest announcement date (doa)**: National transposition dates list the latest announcement date as 31 August 2023. - **2023-09-21 - ETSI EN 319 412-3 adopted (V1.3.1 / 2023-09)**: Date of adoption: 21 September 2023; document history lists V1.3.1 published September 2023. - **2023-09-21 - ETSI EN 319 412-1 adopted (V1.5.1 / 2023-09)**: Date of adoption: 21 September 2023; header shows V1.5.1 (2023-09). - **2023-09-21 - ETSI EN 319 412-5 adopted (V2.4.1 / 2023-09)**: Date of adoption: 21 September 2023; header shows v2.4.1 (2023-09). - **2023-09-30 - ETSI EN 319 122-1 latest announcement date (doa)**: National transposition dates list the latest announcement date as 30 September 2023. - **2023-10-04 - ETSI EN 319 411-1 adopted (V1.4.1 / 2023-10)**: Date of adoption: 4 October 2023; cover indicates V1.4.1 (2023-10). - **2023-11-01 - DSS release v5.13.RC1**: Digital Signature Service (DSS) release table: v5.13.RC1 (November 2023). - **2023-12-31 - ETSI EN 319 412-3 latest announcement date (doa)**: National transposition dates list the latest announcement date as 31 December 2023. - **2024-01-03 - ETSI EN 319 522-1 adopted (V1.2.1 / 2024-01)**: Date of adoption: 3 January 2024; header shows V1.2.1 (2024-01). - **2024-01-03 - ETSI EN 319 522-2 adopted (V1.2.1 / 2024-01)**: Date of adoption: 3 January 2024; header shows V1.2.1 (2024-01). - **2024-01-03 - ETSI EN 319 522-3 adopted (V1.2.1 / 2024-01)**: Date of adoption: 3 January 2024; header shows V1.2.1 (2024-01). - **2024-01-15 - ETSI EN 319 142-1 adopted (V1.2.1 / 2024-01)**: Date of adoption: 15 January 2024; header shows V1.2.1 (2024-01). - **2024-01-31 - ETSI EN 319 411-1 latest announcement date (doa)**: National transposition dates list the latest announcement date as 31 January 2024. - **2024-02-29 - ETSI EN 319 421 national publication/withdrawal date (dop/e, dow)**: National transposition dates list both dop/e and dow as 29 February 2024. - **2024-03-12 - ENISA publication: Remote ID Proofing (good practices)**: Publication date shown: 12 March 2024. - **2024-03-31 - ETSI EN 319 122-1 national publication/withdrawal date (dop/e, dow)**: National transposition dates list both dop/e and dow as 31 March 2024. - **2024-04-11 - EUDI Regulation (EU) 2024/1183 signed (date of act)**: Regulation (EU) 2024/1183 date: 11 April 2024. - **2024-04-30 - EUDI Regulation published in the Official Journal**: Official Journal publication date shown: 30 April 2024 (L series). - **2024-04-30 - ETSI EN 319 522-1 latest announcement date (doa)**: National transposition dates list the latest announcement date as 30 April 2024. - **2024-04-30 - ETSI EN 319 522-2 latest announcement date (doa)**: National transposition dates list the latest announcement date as 30 April 2024. - **2024-04-30 - ETSI EN 319 522-3 latest announcement date (doa)**: National transposition dates list the latest announcement date as 30 April 2024. - **2024-04-30 - ETSI EN 319 142-1 latest announcement date (doa)**: National transposition dates list the latest announcement date as 30 April 2024. - **2024-05-21 - Amended eIDAS scope extends (as referenced in TS 119 612)**: ETSI TS 119 612 timeline notes: as from 21 May 2024, as amended, Regulation (EU) No 910/2014 further extends the scope of qualified trust services and trust service providers. - **2024-05-30 - ETSI EN 319 401 adopted (V3.1.1 / 2024-06)**: Date of adoption of this EN: 30 May 2024. - **2024-06-01 - ETSI EN 319 401 published (V3.1.1 / 2024-06)**: Header indicates V3.1.1 (2024-06); adoption date is 30 May 2024. - **2024-06-30 - ETSI EN 319 412-3 national publication/withdrawal date (dop/e, dow)**: National transposition dates list both dop/e and dow as 30 June 2024. - **2024-07-01 - DSS release 6.1.RC1**: Digital Signature Service (DSS) release table: 6.1.RC1 (July 2024). - **2024-07-31 - ETSI EN 319 411-1 national publication/withdrawal date (dop/e, dow)**: National transposition dates list both dop/e and dow as 31 July 2024. - **2024-08-31 - ETSI EN 319 401 latest announcement date (doa)**: National transposition dates list the latest announcement date as 31 August 2024. - **2024-09-24 - ENISA support for EUDI Wallet certification (reported)**: Pilot implementation page timeline: news item dated 24 September 2024 notes ENISA support for the certification of EU Digital Identity Wallets. - **2024-10-18 - eIDAS consolidated text reference date (2024-10-18)**: EUR-Lex consolidated text identifier indicates a consolidated version as of 18 October 2024 (CELEX 02014R0910-20241018). - **2024-10-31 - ETSI EN 319 142-1 national publication/withdrawal date (dop/e, dow)**: National transposition dates list both dop/e and dow as 31 October 2024. - **2024-10-31 - ETSI EN 319 522-1 national publication/withdrawal date (dop/e, dow)**: National transposition dates list both dop/e and dow as 31 October 2024. - **2024-10-31 - ETSI EN 319 522-2 national publication/withdrawal date (dop/e, dow)**: National transposition dates list both dop/e and dow as 31 October 2024. - **2024-10-31 - ETSI EN 319 522-3 national publication/withdrawal date (dop/e, dow)**: National transposition dates list both dop/e and dow as 31 October 2024. - **2024-11-01 - ETSI TS 119 612 published (V2.3.1 / 2024-11)**: Header indicates ETSI TS 119 612 V2.3.1 (2024-11). - **2024-11-21 - Commission deadline for EUDI Wallet technical specifications (reported)**: EUR-Lex portal timeline: by 21 November 2024, the Commission shall establish technical specifications and procedures for certain wallet requirements by implementing acts. - **2024-11-28 - Commission adopts implementing regulations for EUDI Wallets (reported)**: Implementing regulation page related content references a press release dated 28 November 2024 on adopting technical standards for cross-border EUDI Wallets. - **2024-12-01 - ETSI TS 119 312 published (V1.5.1 / 2024-12)**: Document history entry: V1.5.1 published (December 2024). - **2024-12-01 - ETSI TS 119 431-1 version milestone (V1.3.1 / 2024-12)**: Header indicates ETSI TS 119 431-1 V1.3.1 (2024-12). - **2024-12-04 - Implementing regulation for EUDI Wallets page published**: Publication date shown: 4 December 2024. - **2025-01-01 - EUDI Wallet pilots scheduled to continue until 2025 (reported)**: Pilot implementation page timeline: pilots scheduled to continue until the year 2025. - **2025-02-01 - ETSI TS 119 461 published (V2.1.1 / 2025-02)**: Header indicates ETSI TS 119 461 V2.1.1 (2025-02). Timeline also notes identity-proofing testing/evaluation deadlines by end of 2026. - **2025-02-28 - ETSI EN 319 401 national publication/withdrawal date (dop/e, dow)**: National transposition dates list both dop/e and dow as 28 February 2025. - **2025-03-01 - DSS release v6.0.1**: Digital Signature Service (DSS) release table: v6.0.1 (March 2025). - **2025-03-18 - Commission deadline for eID peer review procedural arrangements (implementing acts)**: Consolidated eIDAS timeline: by 18 March 2025 the Commission must establish procedural arrangements for peer reviews referred to in Article 12(5). - **2025-03-24 - ETSI EN 319 411-1 adopted (V1.5.1 / 2025-04)**: Date of adoption: 24 March 2025; cover indicates V1.5.1 (2025-04). - **2025-04-09 - Corrigendum referenced for Regulation (EU) 2024/1183**: Corrigendum referenced for Regulation (EU) 2024/1183: OJ L 90317, 9.4.2025. - **2025-05-21 - Commission deadline for additional implementing acts (reported)**: EUR-Lex portal timeline: by 21 May 2025, the Commission shall establish (by implementing acts) lists of reference standards/specifications and procedures for several eIDAS amendments (including certification/auditing-related items). - **2025-06-03 - ETSI EN 319 411-2 adopted (V2.6.1 / 2025-06)**: Date of adoption: 3 June 2025; header indicates V2.6.1 (2025-06). - **2025-06-12 - ETSI EN 319 412-2 adopted (V2.4.1 / 2025-06)**: Date of adoption: 12 June 2025; header indicates V2.4.1 (2025-06). - **2025-06-12 - ETSI EN 319 412-5 adopted (V2.5.1 / 2025-06)**: Date of adoption: 12 June 2025; header indicates V2.5.1 (2025-06). - **2025-09-30 - ETSI EN 319 411-2 latest announcement date (doa)**: National transposition dates list the latest announcement date as 30 September 2025. - **2025-09-30 - ETSI EN 319 412-2 latest announcement date (doa)**: National transposition dates list the latest announcement date as 30 September 2025. - **2025-09-30 - ETSI EN 319 412-5 latest announcement date (doa)**: National transposition dates list the latest announcement date as 30 September 2025. - **2025-11-19 - Commission proposes European Business Wallets (reported)**: Pilot implementation page timeline references a news article dated 19 November 2025 about proposing European Business Wallets. - **2026-03-31 - ETSI EN 319 411-2 national publication/withdrawal date (dop/e, dow)**: National transposition dates list both dop/e and dow as 31 March 2026. - **2026-03-31 - ETSI EN 319 412-2 national publication/withdrawal date (dop/e, dow)**: National transposition dates list both dop/e and dow as 31 March 2026. - **2026-03-31 - ETSI EN 319 412-5 national publication/withdrawal date (dop/e, dow)**: National transposition dates list both dop/e and dow as 31 March 2026. - **2026-04-28 - Trusted Lists TLv6 specifications apply (reported)**: Trusted List v6 (TLv6) migration notice: specifications apply from 28 April 2026 at 22:00:00 UTC (Commission Implementing Decision (EU) 2025/2164, amending Decision (EU) 2015/1505). - **2026-05-21 - Commission deadline to review eIDAS application and report**: Consolidated eIDAS timeline: by 21 May 2026 the Commission must review application of the Regulation and submit a report to the European Parliament and the Council (Article 49(1)). - **2026-05-21 - Legacy qualified trust service providers must submit conformity assessment report**: Consolidated eIDAS timeline: qualified trust service providers granted qualified status before 20 May 2024 must submit a conformity assessment report demonstrating compliance by 21 May 2026 (Article 51(4)). - **2026-12-31 - Identity-proofing testing/evaluation deadlines (ETSI TS 119 461)**: ETSI TS 119 461 timeline: certain independent testing and PAD evaluation requirements are set to be completed by the end of 2026. - **2026-12-31 - Member States must provide EUDI Wallets by end of 2026 (reported)**: EUDI regulation overview timeline: Member States must provide EU Digital Identity Wallets to citizens by the end of 2026. - **2027-05-21 - Transitional period ends for legacy secure signature creation devices**: Consolidated eIDAS timeline: devices assessed under Directive 1999/93/EC remain considered qualified electronic signature creation devices until 21 May 2027 (Article 51(1)). - **2030-05-21 - Commission periodic progress report deadline (and every four years)**: Consolidated eIDAS timeline: by 21 May 2030 and every four years thereafter the Commission must report on progress towards the Regulation's objectives (Article 49(3)). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/electronic-identification-and-trust-services-regulation --- --- title: "EU EMC Directive (2014/30/EU) Compliance Hub" canonical_url: "https://www.sorena.io/artifacts/eu/emc-directive" source_url: "https://www.sorena.io/artifacts/eu/emc-directive" author: "Sorena AI" description: "A practical EMC Directive hub: confirm scope for apparatus and fixed installations, choose Annex II or Annex III conformity assessment." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EMC Directive" - "Directive 2014/30/EU" - "electromagnetic compatibility compliance" - "EMC testing" - "emissions and immunity testing" - "CE marking EMC" - "EMC technical file" - "EU Declaration of Conformity EMC" - "harmonised standards EMC" - "fixed installation EMC" - "apparatus EMC" - "EMC" - "Electromagnetic compatibility" - "CE marking" - "Compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU EMC Directive (2014/30/EU) Compliance Hub A practical EMC Directive hub: confirm scope for apparatus and fixed installations, choose Annex II or Annex III conformity assessment. ![EU EMC Directive artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-emc-timeline-small.jpg?v=cheatsheets%2Fprod) *EMC* *Free Resource* ## EU EMC Directive Compliance Hub Confirm scope for apparatus or fixed installations, plan emissions and immunity testing, and build the CE-marking technical file for Directive 2014/30/EU with the right conformity-assessment route. This is a practical reference, not legal advice. The right route depends on your product, its intended environment, whether harmonised standards are fully applied, and whether the equipment is apparatus or part of a fixed installation. [Start with the checklist](/artifacts/eu/emc-directive/checklist.md) ## What you can decide faster - **In scope**: Equipment and exclusions checks. - **What to test**: High-level emissions and immunity planning. - **What to document**: EU DoC, technical documentation, and evidence basics. By Sorena AI | Updated Mar 2026 | No signup required ### Quick scan *EMC* - **Scope**: Confirm EMC applicability for your equipment. - **Standards**: Map harmonised standards, intended environment, and Annex II or Annex III choices. - **Evidence**: Plan test reports, technical documentation, DoC controls, and 10-year retention. Use the decision flow to align engineering and compliance on what is required for CE readiness. | Value | Metric | | --- | --- | | 2014 | Directive | | CE | Marking | | Emissions | Control | | Immunity | Control | **Key highlights:** Scope first | EMC test plan | Technical file + DoC ## Topic Guides - [EMC Conformity Assessment + Documentation | Technical File, EU DoC, CE Marking, Language Rules](/artifacts/eu/emc-directive/conformity-assessment-and-documentation.md): A deep guide to EMC conformity assessment and documentation for Directive 2014/30/EU: how to structure the technical documentation/technical file. - [EMC Directive Applicability Test | Is Directive 2014/30/EU in Scope for Your Product?](/artifacts/eu/emc-directive/applicability-test.md): A practical EMC Directive applicability test: decide scope for Directive 2014/30/EU, classify apparatus vs fixed installations. - [EMC Directive Compliance Checklist | CE Marking, Test Plan, Technical File, EU DoC](/artifacts/eu/emc-directive/checklist.md): An audit-ready EMC Directive checklist (Directive 2014/30/EU): scope and classification (apparatus vs fixed installation), standards strategy. - [EMC Directive Compliance Program | Operating Model, Controls, Testing Cadence, Evidence](/artifacts/eu/emc-directive/compliance.md): A deep EMC Directive compliance playbook: build a role-scoped operating model for manufacturers/importers/distributors. - [EMC Directive Deadlines + Compliance Calendar | CE Marking Milestones, Standards Updates, Language Gates](/artifacts/eu/emc-directive/deadlines-and-compliance-calendar.md): A practical EMC compliance calendar for Directive 2014/30/EU with the legal baseline dates, recurring standards reviews. - [EMC Directive Enforcement | Market Surveillance, Corrective Actions, Evidence to Reduce Risk](/artifacts/eu/emc-directive/penalties-and-fines.md): A practical EMC enforcement guide: how market surveillance works under EU product rules, what authorities typically request (technical file, test reports. - [EMC Directive FAQ | Scope, Testing, Technical File, EU DoC, Fixed Installations, Standards](/artifacts/eu/emc-directive/faq.md): High-signal answers to common EMC Directive questions: what is in scope, apparatus vs fixed installations, what to test (emissions + immunity). - [EMC Directive Requirements (2014/30/EU) | Essential Requirements, Operator Duties, Evidence Map](/artifacts/eu/emc-directive/requirements.md): An advanced EMC Directive requirements breakdown: essential requirements (emissions + immunity), obligations for manufacturers/importers/distributors. - [EMC Directive Scope + Borderline Cases | Apparatus vs Fixed Installations, Exclusions, "Inherently Benign"](/artifacts/eu/emc-directive/scope-and-borderline-cases.md): A deep scope guide for the EU EMC Directive (2014/30/EU): how to decide if your product is in scope. - [EMC Directive Timeline | Key Dates for Directive 2014/30/EU, Transition, Standards, Guidance](/artifacts/eu/emc-directive/timeline.md): A practical EMC Directive timeline: adoption and publication of Directive 2014/30/EU. - [EMC Directive vs Low Voltage Directive (LVD) | What Applies, What to Test, One Technical File](/artifacts/eu/emc-directive/emc-vs-low-voltage-directive.md): A practical comparison of the EU EMC Directive (2014/30/EU) vs the Low Voltage Directive (2014/35/EU): different objectives (EMC vs electrical safety). - [EMC Directive vs Radio Equipment Directive (RED) | Which Route Applies for Wireless Products?](/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive.md): A practical comparison of the EMC Directive (2014/30/EU) vs the Radio Equipment Directive (RED) (2014/53/EU): when wireless products fall under RED. - [EMC Essential Requirements + Testing | Emissions, Immunity, Test Configurations, Evidence](/artifacts/eu/emc-directive/essential-requirements-and-testing.md): A deep EMC testing guide for Directive 2014/30/EU: translate essential requirements into emissions + immunity test plans. - [EMC Harmonised Standards Strategy | Presumption of Conformity, OJEU References, Deviations](/artifacts/eu/emc-directive/harmonized-standards-and-deviations.md): A deep guide to harmonised standards under the EMC Directive: how presumption of conformity works. - [EMC Test Plan Template | Directive 2014/30/EU Emissions + Immunity Plan (Audit-Ready)](/artifacts/eu/emc-directive/emc-test-plan-template.md): A structured EMC test plan template you can copy and adapt for CE marking: scope and configuration matrix, standards selection. ## Key dates for EMC compliance *EMC Timeline* Track the evolution of EMC requirements and major milestones that affect CE readiness and standards strategy. ## Does the EMC Directive apply to your equipment *EMC Decision Flow* Use the decision flow to confirm scope, then translate outcomes into a clear test and documentation plan. *Next step* ## Turn EU EMC Directive Compliance Hub into an operational assessment workflow EU EMC Directive Compliance Hub should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU EMC Directive Compliance Hub and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for EU EMC Directive Compliance Hub. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share applicability logic internally. - **Download timeline**: Align milestones across your team. - [Talk through EU EMC Directive Compliance Hub](/contact.md): Review your current process, evidence model, and next steps for EU EMC Directive Compliance Hub. ## Decision Steps ### STEP 1: Does your product contain electrical and/or electronic parts? *Reference: EMC Guide 2018, Sec. 1.4.1* - Equipment without electrical and/or electronic parts will not generate electromagnetic disturbances and is not affected by such disturbances. - Only equipment with electrical/electronic parts can fall under the EMC Directive scope. - **NO** Out of Scope - **YES** Is your product explicitly excluded from the EMCD? ### STEP 2: Is your product explicitly excluded from the EMCD? *Reference: Art. 2(2) & 2(3)* - Check against the explicit exclusions: radio equipment (RED scope), aeronautical products, radio amateur equipment (not made available on market), equipment under other specific Union legislation, inherently benign equipment, custom R&D evaluation kits. - If yes, the EMCD does not apply (but other directives may apply). - If no, continue to scope determination. - **YES** Out of Scope - **NO** Is your equipment inherently benign in terms of EMC? ### STEP 3: Is your equipment inherently benign in terms of EMC? *Reference: Art. 2(2)(d)* - Inherently benign means: (a) incapable of generating or contributing to EM emissions exceeding a level allowing radio/telecom equipment to operate as intended, AND (b) will operate without unacceptable degradation in the presence of normal EM disturbance. - Both conditions must be met. - Examples (without active electronic parts): cables/cabling accessories, resistive loads without switching, batteries/accumulators, corded headphones/loudspeakers without amplification, pocket lamps without active circuits, passive antennas, quartz watches (no radio), simple switches, induction motors without electronic circuits. - Document the assessment if you conclude equipment is inherently benign. - **YES** Out of Scope - **NO** Is your equipment apparatus or a fixed installation? ### STEP 4: Is your equipment apparatus or a fixed installation? - Apparatus: finished appliance, combination of finished appliances, components/sub-assemblies for incorporation by end-user, or mobile installation. Intended for end-user. Subject to CE marking, DoC, conformity assessment. - Fixed installation: combination of apparatus/devices assembled, installed and used permanently at a predefined location. Not subject to CE marking or DoC, but must comply with essential requirements. - Classification is critical - different provisions apply to each. - -> Is your equipment apparatus (intended for end-user)? ### APPARATUS: Is your equipment apparatus (intended for end-user)? *Reference: Art. 3(1)(2) & 3(2)* - Apparatus includes: finished appliances, combination of finished products as a single functional unit, components/sub-assemblies intended for incorporation by end-user, mobile installations. - If yes: proceed to apparatus conformity assessment route. - If no (not intended for end-user or is a fixed installation): check fixed installation route. - **YES** Is the apparatus intended for incorporation into a particular fixed installation and NOT otherwise commercially available? - **NO** Is your equipment a fixed installation? ### STEP 5: Is the apparatus intended for incorporation into a particular fixed installation and NOT otherwise commercially available? *Reference: Art. 19(1)* - If yes: manufacturer may choose exemption from apparatus provisions (CE marking, DoC, full conformity assessment). Instead: provide documentation identifying the fixed installation, EMC characteristics, precautions for incorporation, and information per Art. 7(5), 7(6) and 9(3). - If no or if commercially available: full apparatus provisions apply. - This is a manufacturer's choice - apparatus can still follow full route even if eligible for exemption. - **YES** Apparatus for Particular Fixed Installation (Exemption) - **NO** Apparatus in Scope - Full Provisions Apply ### FIXED INSTALLATION: Is your equipment a fixed installation? *Reference: Art. 3(1)(3)* - Fixed installation: particular combination of apparatus and other devices, assembled, installed, and intended to be used permanently at a predefined location. - Examples: industrial plants, power plants, telecom networks, cable TV networks, airport installations, wind turbine stations, water treatment plants, railway infrastructures, air conditioning installations. - If yes: fixed installation provisions apply. - If no: check mobile installation (deemed apparatus). - **YES** Fixed Installation in Scope - **NO** Out of Scope ### STEP 6: Do you use EU-type examination by a notified body (Annex III)? - If yes: Annex III route (EU-type examination by a notified body + conformity to type). - If no: Annex II route (internal production control). - **NO** Internal Production Control (Annex II) - **YES** EU-Type Examination (Annex III Module B + C) ## Reference Information ### EMCD Scope Overview - The EMCD applies to 'equipment' defined as any apparatus or fixed installation. - Apparatus: any finished appliance, or combination thereof, made available on the market as a single functional unit, intended for the end-user, liable to generate EM disturbance or affected by such disturbance. - Fixed installation: a particular combination of apparatus and other devices assembled, installed and intended to be used permanently at a predefined location. - Geographic scope: EU + EEA-EFTA States (Iceland, Liechtenstein, Norway) + Turkey. - The EMCD is not a safety related directive. It covers electromagnetic compatibility only. ### Key Exclusions from EMCD - Radio equipment covered by RED (Directive 2014/53/EU) - Art. 2(2)(a). - Aeronautical products under Regulation (EU) 2018/1139 (with specific exceptions for ground equipment, certain drones) - Art. 2(2)(b). - Radio equipment used by radio amateurs (unless made available on market) - Art. 2(2)(c). - Equipment covered more specifically by other Union legislation for EMC (e.g., motor vehicle equipment under UNECE Reg. 10, medical devices, marine equipment) - Art. 2(3). - Inherently benign equipment (incapable of generating or contributing to EM emissions beyond acceptable levels, and operates without degradation in normal EM environment) - Art. 2(2)(d). - Custom built evaluation kits for professionals at R&D facilities - Art. 2(2)(e). ### Essential Requirements (Annex I) - General requirements for all equipment: Equipment must be designed and manufactured ensuring an adequate level of electromagnetic compatibility. Emissions shall not exceed levels allowing radio and telecom equipment to operate as intended. Equipment shall have adequate immunity to EM disturbance expected in its intended use, allowing it to operate without unacceptable degradation. - Specific requirements for fixed installations: Good engineering practices applied; documented and available to authorities; use apparatus complying with the directive where available; if specific apparatus used (Art. 19), incorporate taking into account manufacturer's instructions. - Compliance is mandatory - only compliant equipment may be placed on market or put into service. - Essential requirements are formulated generally to allow technological progress; technical solutions are not prescribed. ### EMC Assessment (Manufacturer Responsibility) - The EMC assessment is the sole responsibility of the manufacturer - never the responsibility of a Notified Body or test laboratory. - Assessment methods: (a) Apply harmonized standards covering all relevant phenomena (presumption of conformity); (b) Apply manufacturer's own methodology and other technical specifications; (c) Mixed approach. - Harmonized standards provide recognized methodology - usually preferred. - Where harmonized standards not applied or only partially applied: detailed technical justification required listing other specifications applied. - Assessment must consider all normal intended operating conditions and all possible configurations representative of intended use. - Worst case approach: document selection of worst case configurations for emissions and immunity. - If assessment establishes equipment is inherently benign (Art. 2(2)(d)): excluded from EMCD scope; document conclusion. ### Harmonized Standards - Harmonized standards are European standards adopted by CEN, CENELEC or ETSI on Commission request for Union harmonization legislation. - Compliance with harmonized standards listed in OJEU gives presumption of conformity with corresponding essential requirements. - Standards are voluntary - manufacturers may choose other means to demonstrate compliance. - Selection precedence: product-specific standards (if available) -> product family standards (if available) -> generic standards. - Generic standards divided by environment (residential, commercial/industrial); product-specific/family standards better suited as they consider operating/loading conditions. - Multiple standards may be needed to cover all phenomena (radiated/conducted disturbances, immunity to continuous and transient phenomena, all frequency ranges, all functions). - References published in OJEU; updated regularly; transition period (18-36 months) between old and new versions. - CENELEC Guide 25 provides practical info on EMC standard selection. ### Technical Documentation (Annex II; EMC Guide Chapter 4.4) - General description of apparatus, intended use, operating conditions. - Design and manufacturing drawings, component/sub-assembly lists, descriptions. - Risk analysis and assessment of EMC phenomena relevant to apparatus and intended environment. - EMC assessment results: harmonized standards applied (full or partial reference), or where not applied - descriptions of solutions adopted to meet essential requirements, technical specifications applied, test reports, calculations, examinations. - If harmonized standards applied partly or not at all: detailed technical assessment of EMC aspects not covered and description of solutions adopted. - Worst case approach documentation where apparatus can take different configurations. - Include identification, traceability and use information as applicable. - Copy of EU Declaration of Conformity. - For components/sub-assemblies used: copies of DoC demonstrating compliance. - Must be in or translated to language easily understood by authorities; kept for 10 years. ### EU Declaration of Conformity (DoC) - Manufacturer or authorized representative draws up written DoC (Art. 15, Annex IV template). - By issuing DoC, manufacturer assumes responsibility for compliance of apparatus with requirements. - Content: apparatus identification (type, batch, serial number, model as appropriate, image if needed), manufacturer name/address/contact, authorized rep (if applicable), sole responsibility statement, object of declaration (apparatus identification allowing traceability, may include image), reference to EMCD 2014/30/EU, references to harmonized standards applied or other technical specifications used, where applicable - NB name/address/number and EU-type examination certificate reference, additional info (if applicable), place/date of issue, name/function and signature of authorized person. - DoC must be kept for 10 years after apparatus placed on market. - Updated DoC required if apparatus modified or new harmonized standard applied. - If DoC incomplete: not valid; may lead to enforcement action. - Template and examples available in official guidance documents. ### CE Marking (Art. 16, 18) - Manufacturer affixes CE marking on apparatus before placing on market. - CE marking must be visible, legible, indelible. - Affixed on apparatus; if not possible due to nature or size - on packaging and accompanying documentation. - CE marking format per Annex II of Regulation (EC) No 765/2008. - If Notified Body involved (Annex III): NB identification number follows CE marking (placed by manufacturer). - CE marking indicates conformity with all applicable Union harmonization legislation (not only EMCD - also LVD, RED, etc. if applicable). - Prohibition of misleading markings: other markings allowed if not reduce visibility/legibility of CE marking and not create confusion. - Incorrect CE marking may result in market surveillance action, withdrawal, recall. ### Manufacturer Obligations (Art. 7) - Ensure apparatus designed and manufactured in accordance with essential requirements (Art. 6, Annex I). - Perform EMC assessment and apply a conformity assessment procedure (Art. 14, Annex II or III). - Draw up technical documentation and the EU Declaration of Conformity (Art. 15). - Affix CE marking when compliance is demonstrated (Art. 16). - Keep technical documentation and the EU Declaration of Conformity for 10 years after the apparatus is placed on the market. - Ensure production processes maintain conformity; take samples, test, investigate complaints/non-conforming apparatus/recalls as appropriate. - Indicate on apparatus: type/batch/serial/model number, name/registered trade name/trademark, contact postal address (or on packaging/documentation if not possible on apparatus). If not established in EU: indicate importer details. - Ensure apparatus accompanied by instructions and safety information in language easily understood by end-users (determined by Member State). - Where apparatus not in conformity: take corrective action, withdraw/recall if necessary, inform authorities. - Provide authorities with info and documentation in language easily understood; cooperate to eliminate risks; provide samples if requested. - May appoint authorized representative (Art. 8) for tasks (except: drawing up technical documentation, ensuring production conformity). ### Importer Obligations (Art. 9) - Place on market only apparatus in conformity with EMCD. - Before placing on market: ensure the apparatus bears CE marking and is accompanied by required documents and instructions. - Ensure the manufacturer has carried out conformity assessment and drawn up technical documentation and the EU Declaration of Conformity. - If apparatus not in conformity or CE marking incorrectly affixed: do not place on market until brought into conformity; inform manufacturer and authorities if risk. - Indicate on apparatus or packaging/documentation: name, registered trade name/trademark, contact postal address. - Ensure instructions and safety information in language easily understood by end-users (Member State determination). - Keep copy of DoC available to authorities; ensure technical documentation can be made available to authorities. - Keep DoC and ensure technical documentation availability for 10 years after apparatus placed on market. - Where apparatus not in conformity: inform manufacturer and authorities; take corrective action, withdraw/recall if necessary. - Keep record of apparatus presenting risk for 10 years; inform authorities. - Provide authorities with info/documentation in language easily understood; cooperate to eliminate risks; provide samples if requested. - Importer who modifies apparatus or places under own name/trademark: assumes manufacturer obligations. ### Distributor Obligations (Art. 10) - Act with due care when making apparatus available on market. - Before making available: verify CE marking is affixed and the apparatus is accompanied by required documents and instructions in the appropriate language. - If apparatus not in conformity or CE marking incorrectly affixed: do not make available until brought into conformity; inform manufacturer/importer and authorities if risk. - Where apparatus not in conformity: inform manufacturer/importer and authorities; take corrective action, withdraw if necessary. - Keep record of apparatus presenting risk for 10 years; inform authorities. - Provide authorities with info/documentation; cooperate to eliminate risks; provide samples/access to apparatus if requested. - Distributor who modifies apparatus or places under own name/trademark: assumes manufacturer obligations. ### Authorized Representative (Art. 8) - Manufacturer established outside EU may appoint authorized representative (AR) by written mandate. - Mandate must allow AR to perform tasks specified; minimum: keep DoC and technical documentation available to authorities for 10 years; provide authorities with info/documentation; cooperate with authorities to eliminate risks posed by apparatus. - AR cannot perform: drawing up technical documentation, ensuring production conformity. - AR acts on manufacturer's behalf; manufacturer remains responsible for compliance. - AR details indicated in DoC if appointed. ### Market Surveillance (EMC Guide Chapter 6; Blue Guide 2022) - Member States designate market surveillance authorities responsible for EMCD enforcement. - Market surveillance aims to ensure that equipment placed on the market or put into service complies with the EMCD when properly installed, maintained and used for its intended purpose. - Authorities can request documentation and evidence of compliance, including for fixed installations. - When non-compliance is identified, authorities can require corrective action and, where needed, restrict making equipment available or require withdrawal or recall. - General EU market surveillance framework is described in the Blue Guide and in Regulation (EU) 2019/1020. ### Notified Bodies (EMC Guide Chapter 7; Annex III) - Notified Bodies (NB) are conformity assessment bodies notified by Member States to perform EU-type examination (Annex III). - Use of NB is voluntary for manufacturers under EMCD (Annex II self-assessment is alternative). - Notified bodies can carry out tasks under the EMCD only for apparatus, not for fixed installations. - NB tasks: examine technical documentation; assess conformity with essential requirements for the aspects requested by the applicant; prepare an evaluation report; issue an EU-type examination certificate if compliant (or refuse with detailed reasons). - The manufacturer informs the notified body of modifications to the approved type that may affect conformity or certificate validity; such modifications can require additional approval. - A notified body can subcontract limited tasks or use a subsidiary under conditions, but remains fully responsible. - Notified bodies have information exchange and coordination obligations under the Directive and Annex III; the EMC notified body coordination group (EUANB) supports consistency. ### Placing on Market & Putting into Service - Placing on market: first making available of product on Union market (each individual product, not a type). - Making available: supply for distribution, consumption or use on Union market in course of commercial activity, whether for payment or free. - Apparatus must comply with legal requirements in place at time of placing on market. - Putting into service: first use of apparatus in Union for its intended purpose. Member States allow putting into service if complies with EMCD. - Trade fairs/exhibitions/demonstrations: display/operation under controlled conditions allowed if visible sign indicates may not be made available/put into service until complies, and adequate measures taken to avoid EM disturbances (Art. 5(3)). - Constructed for own use or bought in third country and brought to EU by consumer: not considered placing on market. - For fixed installations: putting into service covered; must comply when put into service. ### Transition & Key Dates - Old EMCD (2004/108/EC) repealed and replaced by new EMCD (2014/30/EU) aligned with New Legislative Framework. - New EMCD entered into force 18 April 2014; applies from 20 April 2016. - Essential requirements unchanged; substance of harmonized standards not affected. - Main changes: alignment with NLF, Standardisation Regulation (EU) 1025/2012, Article 291 TFEU (Implementing Acts); new economic operator obligations; enhanced traceability. - New exclusion: custom built evaluation kits (Art. 2(2)(e)). - Scope indirectly affected by Radio Equipment Directive (RED) 2014/53/EU replacing R&TTE Directive from 13 June 2016. - Harmonized standards: references published in OJEU; superseded standards have cessation date providing transition period (18-36 months); manufacturers may use old or new during transition. - MRA with Switzerland adapted for EMCD (Decision 1/2017); specific adaptations for obligations re contact details, documentation retention, authorized representative. ### Specific Case: Jammers - A jammer is covered by EMCD unless it falls within scope of RED. - Jamming is inherent to functional principle; normally not possible to construct jammers fulfilling EMC essential requirements. - Jammers should be prohibited or restricted from being made available, or withdrawn/recalled. - Market surveillance authorities should take action against jammers. ## Possible Outcomes ### [APPARATUS] Apparatus in Scope - Full Provisions Apply CE marking, DoC, conformity assessment required - Comply with essential requirements (Art. 6, Annex I). - Perform EMC assessment and apply conformity assessment procedure (Art. 14, Annex II or III). - Prepare technical documentation and EU Declaration of Conformity (Art. 15). - Affix CE marking (Art. 16). - Provide identification, traceability, and use information (Art. 7, 9, 18). - Economic operator obligations apply (manufacturer, authorized representative, importer, distributor). ### [APPARATUS] Apparatus for Particular Fixed Installation (Exemption) Documentation only, no CE marking or DoC - Provide documentation including: identification of the fixed installation and its EMC characteristics, precautions for incorporation into the installation, information per Art. 7(5), 7(6) and 9(3). - No CE marking, no EU Declaration of Conformity, no formal conformity assessment procedure required. - Essential requirements still apply when apparatus is incorporated into the fixed installation. ### [FIXED INSTALLATION] Fixed Installation in Scope Essential requirements apply, no CE marking or DoC - Comply with essential requirements (Art. 6, Annex I general and specific requirements for fixed installations). - Good engineering practices required during installation. - Maintain documentation: description of installation, EMC assessment of installation, supporting technical documentation on EMC characteristics of apparatus used. - Responsible person must make documentation available to competent authorities upon request. - No CE marking, no EU Declaration of Conformity, no formal conformity assessment procedure. - Competent authorities may request evidence of compliance and initiate evaluation if non-compliances established. ### [RESULT] Out of Scope EMCD does not apply - Your product does not fall under the EMCD scope. - Reasons: no electrical/electronic parts, or explicitly excluded under Art. 2(2)/(3), or inherently benign. - Check if other EU product safety directives apply (LVD, RED, Machinery, etc.). ### [ANNEX II] Internal Production Control (Annex II) Self-assessment by manufacturer - Manufacturer performs EMC assessment based on relevant phenomena to meet essential requirements. - Establish technical documentation (Annex II): description of apparatus, design and manufacturing info, EMC assessment, test reports or technical justification, harmonised standards applied (if any), and user information. - Draw up EU Declaration of Conformity (Art. 15, Annex IV). - Affix CE marking (Art. 16). - Manufacturer is fully responsible for compliance; no mandatory Notified Body intervention. - Keep technical documentation and the EU Declaration of Conformity for 10 years after the apparatus is placed on the market. ### [ANNEX III] EU-Type Examination (Annex III Module B + C) Notified Body involved - Manufacturer submits technical documentation to chosen Notified Body for EU-type examination (Module B). - NB examines technical documentation, verifies design meets essential requirements, prepares evaluation report, issues EU-type examination certificate if compliant (or refuses with detailed reasons). - Manufacturer ensures production conforms to approved type (Module C - conformity to type). - Draw up EU Declaration of Conformity referencing the EU-type examination certificate. - Affix CE marking. - Notify NB of any modifications to approved type requiring re-approval. - Certificate conditions may include validity period. ## EMC Directive Timeline | Date | Event | Reference | | --- | --- | --- | | 2004-12-15 | Old EMCD (2004/108/EC) adopted | Directive 2004/108/EC | | 2014-02-26 | New EMCD (2014/30/EU) adopted, aligned with New Legislative Framework | Directive 2014/30/EU | | 2014-04-18 | EMCD 2014/30/EU enters into force | Directive 2014/30/EU | | 2016-04-20 | EMCD 2014/30/EU applies (old EMCD repealed) | Directive 2014/30/EU | | 2016-11-30 | Standardization mandate M/552 issued to CEN, CENELEC and ETSI | C(2016) 7641 final | | 2018-07-13 | First list of harmonized standards published in OJ | 2018/C 246/01 | | 2018-12-19 | Official EMC Guide published (updated version) | Ref. Ares(2019)407039 | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2004-12-15 | EMC Directive 2004/108/EC adopted | Legislation | | | 2004-12-31 | Directive 2004/108/EC published in the Official Journal (OJ L 390) | Legislation | | | 2007-03-30 | Standardisation mandate M404 issued (under Directive 2004/108/EC) | Standards | | | 2010-06-01 | 2nd workshop on cable TV receivers affected by new radio services in the 800 MHz band | Guidance | | | 2010-08-01 | Digital dividend deliverables from the ETSI/CENELEC joint working group | Guidance | | | 2012-10-01 | 3rd workshop on receivers affected by LTE in the 800 MHz band | Guidance | | | 2014-02-26 | EMC Directive 2014/30/EU adopted (recast) | Legislation | | | 2014-03-29 | Directive 2014/30/EU published in the Official Journal (OJ L 96) | Legislation | | | 2014-04-18 | Directive 2014/30/EU enters into force | Legislation | | | 2014-11-12 | Workshop on the transition to the new EMC Directive 2014/30/EU | Guidance | | | 2014-12-12 | Workshop on coexistence challenges from evolving use of the UHF band | Guidance | | | 2016-04-19 | Transposition deadline for Directive 2014/30/EU (as referenced in Q&A) | Implementation | | | 2016-04-19 | EU Declaration of Conformity (DoC) template issued (version 2016/04/19) | Guidance | | | 2016-04-20 | Directive 2014/30/EU starts applying; Directive 2004/108/EC repealed | Legislation | | | 2016-11-20 | Deadline for the first list of titles of requested harmonised standards (C(2016) 7641) | Standards | | | 2016-11-30 | Standardisation request issued for harmonised standards (C(2016) 7641) | Standards | | | 2017-01-31 | First annual report due from European standardisation organisations (per C(2016) 7641) | Standards | | | 2017-04-15 | Deadline for adoption of requested harmonised standards (C(2016) 7641 annex deadline) | Standards | | | 2017-12-01 | EMC ADCO summary of language requirements (V2.0) | Implementation | | | 2018-01-01 | Report on the 10th joint cross-border EMC market surveillance campaign on PLC (2018) | Implementation | | | 2018-07-13 | Harmonised standards communication published (2018/C 246/01) | Standards | | | 2018-12-01 | OJ references for harmonised standards handled via implementing decisions (noted since 1 December 2018) | Updates | | | 2018-12-19 | EMCD Guide published (dated 19 December 2018) | Guidance | | | 2019-08-05 | Implementing Decision (EU) 2019/1326 on harmonised standards adopted | Standards | | | 2020-05-15 | Amendment to Implementing Decision (EU) 2019/1326 (15 May 2020) | Updates | | | 2021-03-15 | Amendment to Implementing Decision (EU) 2019/1326 (15 March 2021) | Updates | | | 2022-04-07 | Amendment to Implementing Decision (EU) 2019/1326 (noted 7 April 2022) | Updates | | | 2022-06-29 | Blue Guide 2022 published (Commission Notice 2022/C 247/01) | Guidance | | | 2023-01-01 | Evaluation of the EMC Directive (Staff Working Document) | Updates | | | 2024-12-13 | Guidance on EMCD vs vehicle legislation endorsed by EMC WP 32 | Guidance | | | 2025-01-18 | Guidance on EMCD vs vehicle legislation dated (Brussels, 18 January 2025) | Guidance | | | 2025-02-18 | Guidance on EMCD vs vehicle legislation published (18 February 2025) | Guidance | | **Event details:** - **2004-12-15 - EMC Directive 2004/108/EC adopted**: Directive 2004/108/EC adopted, replacing Directive 89/336/EEC. - **2004-12-31 - Directive 2004/108/EC published in the Official Journal (OJ L 390)**: Official Journal reference: OJ L 390, 31 December 2004. - **2007-03-30 - Standardisation mandate M404 issued (under Directive 2004/108/EC)**: Mandate M404 issued to CEN, CENELEC and ETSI for harmonised standards under Directive 2004/108/EC. - **2010-06-01 - 2nd workshop on cable TV receivers affected by new radio services in the 800 MHz band**: Commission activity: 2nd workshop held in June 2010 on cable TV receivers affected by new radio services in the 800 MHz band. - **2010-08-01 - Digital dividend deliverables from the ETSI/CENELEC joint working group**: Commission activity: deliverables published in August 2010 from the joint ETSI/CENELEC working group on the digital dividend. - **2012-10-01 - 3rd workshop on receivers affected by LTE in the 800 MHz band**: Commission activity: 3rd workshop held in October 2012 on receivers affected by new radio services (LTE) in the 800 MHz band. - **2014-02-26 - EMC Directive 2014/30/EU adopted (recast)**: Directive 2014/30/EU date: 26 February 2014. - **2014-03-29 - Directive 2014/30/EU published in the Official Journal (OJ L 96)**: Official Journal reference: OJ L 96, 29 March 2014. - **2014-04-18 - Directive 2014/30/EU enters into force**: The new EMCD entered into force on 18 April 2014. - **2014-11-12 - Workshop on the transition to the new EMC Directive 2014/30/EU**: Commission activity: workshop held on 12 November 2014 on transition from Directive 2004/108/EC to Directive 2014/30/EU. - **2014-12-12 - Workshop on coexistence challenges from evolving use of the UHF band**: Commission activity: workshop held in Brussels on 12 December 2014 on coexistence challenges linked to evolving use of the UHF band. - **2016-04-19 - Transposition deadline for Directive 2014/30/EU (as referenced in Q&A)**: Guidance Q&A timeline references transposition by 19 April 2016. - **2016-04-19 - EU Declaration of Conformity (DoC) template issued (version 2016/04/19)**: Commission template for an EU Declaration of Conformity (DoC) is versioned 2016/04/19. - **2016-04-20 - Directive 2014/30/EU starts applying; Directive 2004/108/EC repealed**: Directive 2014/30/EU is applicable from 20 April 2016 and repeals Directive 2004/108/EC as from that date. - **2016-11-20 - Deadline for the first list of titles of requested harmonised standards (C(2016) 7641)**: Standardisation request C(2016) 7641 sets a deadline of 20 November 2016 to provide the first list of titles of requested harmonised standards to the Commission. - **2016-11-30 - Standardisation request issued for harmonised standards (C(2016) 7641)**: Commission Implementing Decision C(2016) 7641 final of 30 November 2016 requests harmonised standards in support of Directive 2014/30/EU. - **2017-01-31 - First annual report due from European standardisation organisations (per C(2016) 7641)**: The standardisation request sets 31 January 2017 as the date for the first annual report. - **2017-04-15 - Deadline for adoption of requested harmonised standards (C(2016) 7641 annex deadline)**: Standardisation request C(2016) 7641 includes a deadline (15 April 2017) for adoption of certain requested harmonised standards. - **2017-12-01 - EMC ADCO summary of language requirements (V2.0)**: Summary list of national language requirements for Directive 2014/30/EU (version 2.0) dated 1 December 2017. - **2018-01-01 - Report on the 10th joint cross-border EMC market surveillance campaign on PLC (2018)**: Commission report on the 10th joint cross-border EMC market surveillance campaign on power line communication (PLC) (2018). - **2018-07-13 - Harmonised standards communication published (2018/C 246/01)**: Commission communication in the framework of Directive 2014/30/EU published in OJ C 246 on 13 July 2018. - **2018-12-01 - OJ references for harmonised standards handled via implementing decisions (noted since 1 December 2018)**: Commission EMC page notes that since 1 December 2018, references of harmonised standards are published/withdrawn via Commission implementing decisions. - **2018-12-19 - EMCD Guide published (dated 19 December 2018)**: Commission guide for Directive 2014/30/EU carries the date 19 December 2018. - **2019-08-05 - Implementing Decision (EU) 2019/1326 on harmonised standards adopted**: Commission Implementing Decision (EU) 2019/1326 dated 5 August 2019 (harmonised standards for electromagnetic compatibility in support of Directive 2014/30/EU). - **2020-05-15 - Amendment to Implementing Decision (EU) 2019/1326 (15 May 2020)**: Commission EMC harmonised standards page notes an amendment of 15 May 2020 to Implementing Decision (EU) 2019/1326. - **2021-03-15 - Amendment to Implementing Decision (EU) 2019/1326 (15 March 2021)**: Commission EMC harmonised standards page notes an amendment of 15 March 2021 to Implementing Decision (EU) 2019/1326. - **2022-04-07 - Amendment to Implementing Decision (EU) 2019/1326 (noted 7 April 2022)**: Commission EMC page timeline notes an amendment of 7 April 2022 to Implementing Decision (EU) 2019/1326. - **2022-06-29 - Blue Guide 2022 published (Commission Notice 2022/C 247/01)**: Official Journal C 247 issue date: 29 June 2022. - **2023-01-01 - Evaluation of the EMC Directive (Staff Working Document)**: Commission evaluation of the EMCD published as a Staff Working Document (CELEX:52023SC0007) (date shown on the Commission page as 2023). - **2024-12-13 - Guidance on EMCD vs vehicle legislation endorsed by EMC WP 32**: Document notes endorsement by the EMC Working Party (WP 32) on 13 December 2024. - **2025-01-18 - Guidance on EMCD vs vehicle legislation dated (Brussels, 18 January 2025)**: The guidance document on application of the EMCD and EU vehicle legislation is dated Brussels, 18 January 2025. - **2025-02-18 - Guidance on EMCD vs vehicle legislation published (18 February 2025)**: Commission EMC directive page references publication of vehicle-equipment applicability guidance dated 18 February 2025. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/emc-directive --- --- title: "EU Energy Efficiency Directive (EED) (EU) 2023/1791 Compliance Hub" canonical_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive" source_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive" author: "Sorena AI" description: "A practical compliance hub for the Energy Efficiency Directive, Directive (EU) 2023/1791: determine the Article 11 route." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Energy Efficiency Directive" - "EED compliance" - "Directive (EU) 2023/1791" - "EED Article 11 energy audits" - "energy management system certification ISO 50001" - "EN 16247 energy audit" - "85 TJ threshold" - "10 TJ threshold" - "data centre reporting 500 kW" - "public sector 1.9% annual reduction" - "public buildings 3% renovation" - "EED transposition 11 October 2025" - "EED" - "Energy audits" - "ISO 50001" - "Compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Energy Efficiency Directive (EED) (EU) 2023/1791 Compliance Hub A practical compliance hub for the Energy Efficiency Directive, Directive (EU) 2023/1791: determine the Article 11 route. ![EU EED artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-eed-timeline-small.jpg?v=cheatsheets%2Fprod) *EED* *Free Resource* ## EU Energy Efficiency Directive Compliance Hub Use the decision flow to determine whether you need a certified energy management system above 85 TJ, energy audits above 10 TJ if no EMS is in place, data centre reporting at >=500 kW, and which public-sector obligations apply, then use the subpages to build an evidence-backed program. Directive (EU) 2023/1791 entered into force on 10 October 2023. Member States had until 11 October 2025 to transpose the main recast obligations, so always validate the current national implementation and sector guidance. [Start with the checklist](/artifacts/eu/energy-efficiency-directive/checklist.md) ## What you can decide faster - **Enterprise route**: 85 TJ certified EMS vs 10 TJ energy audit route. - **Public sector duties**: Annual reduction and public buildings obligations. - **Data centres**: 500 kW reporting trigger and annual cadence. By Sorena AI | Updated Mar 2026 | No signup required ### Quick scan *EED* - **Enterprises**: Compute 3-year average consumption (all carriers). - **Public bodies**: Plan reduction and building inventory/renovation duties. - **Data centres**: Check the installed IT power demand trigger and annual publication cadence. Treat the outcome as a controlled compliance decision, store the inputs, thresholds, Action Plan logic, and publication duties, and review the result every year. | Value | Metric | | --- | --- | | 85 TJ | EMS trigger | | 10 TJ | Audit trigger | | 500 kW | Data centres | | 11 Oct 2025 | Transposition | **Key highlights:** Thresholds | Audit/EMS route | Evidence pack ## Topic Guides - [EED Applicability Test (Directive (EU) 2023/1791) | 85 TJ vs 10 TJ, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/applicability-test.md): A practical applicability test for the EU Energy Efficiency Directive (EED. - [EED Checklist (Directive (EU) 2023/1791) | Audit-Ready Steps for Article 11, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/checklist.md): An audit-ready checklist for the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): scope and boundary memo, 85 TJ vs 10 TJ route decision. - [EED Compliance Program (Directive (EU) 2023/1791) | How to Operationalize Article 11, Audits, ISO 50001, Reporting](/artifacts/eu/energy-efficiency-directive/compliance.md): A practical EED compliance playbook: governance, scope control, threshold route decision (85 TJ / 10 TJ), energy audit program (Annex VI quality gates). - [EED Deadlines & Compliance Calendar (Directive (EU) 2023/1791) | Transposition 11 Oct 2025, Data Centres 15 May](/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED Energy Audits (Directive (EU) 2023/1791 Article 11) | Annex VI Minimum Criteria + Action Plan + Reporting](/artifacts/eu/energy-efficiency-directive/energy-audits.md): A deep-dive on EED energy audits: who must do them (>10 TJ 3-year average if no EMS), deadlines (first audit by 11 Oct 2026. - [EED Energy Management System (EMS) (Directive (EU) 2023/1791 Article 11) | 85 TJ Threshold + ISO 50001 Certification](/artifacts/eu/energy-efficiency-directive/energy-management-systems.md): A practical guide to the EED EMS obligation: who must implement a certified energy management system (>85 TJ 3-year average). - [EED Enforcement (Penalties) | Directive (EU) 2023/1791 Article 32 + How to Reduce Risk](/artifacts/eu/energy-efficiency-directive/penalties-and-fines.md): A practical enforcement guide for the Energy Efficiency Directive (EED): what the directive says about penalties (Article 32). - [EED FAQ (Directive (EU) 2023/1791) | Thresholds, Audits, ISO 50001, Action Plans, Data Centres](/artifacts/eu/energy-efficiency-directive/faq.md): High-signal answers to common EED questions: how to compute the 3-year average TJ. - [EED Reporting & Metrics (Directive (EU) 2023/1791) | Action Plans, Implementation Rate, Data Centres, Public Bodies](/artifacts/eu/energy-efficiency-directive/reporting-and-metrics.md): A practical reporting and metrics guide for EED compliance: what to track to support Article 11 thresholds and route decisions. - [EED Requirements (Directive (EU) 2023/1791) | Article 11 Thresholds, Annex VI Audit Criteria, Data Centres](/artifacts/eu/energy-efficiency-directive/requirements.md): A practical requirements breakdown of the EU Energy Efficiency Directive (EED. - [EED Scope: Who Must Comply (Directive (EU) 2023/1791) | Enterprises, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply.md): A grounded scope guide for the Energy Efficiency Directive (EED. - [EED Timeline | Key Dates for Directive (EU) 2023/1791 (Transposition, Audits, EMS, Data Centres)](/artifacts/eu/energy-efficiency-directive/timeline.md): A high-signal timeline guide for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED vs CSRD | How Energy Efficiency Compliance Feeds Sustainability Reporting (and What It Doesn't Replace)](/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd.md): A practical comparison of the Energy Efficiency Directive (EED, Directive (EU) 2023/1791) vs the Corporate Sustainability Reporting Directive (CSRD. - [Energy Audit Report Template (EED / EN 16247) | Annex VI-Aligned Structure + Acceptance Criteria](/artifacts/eu/energy-efficiency-directive/energy-audit-report-template.md): A practical energy audit report template aligned to the EED (Directive (EU) 2023/1791) and its Annex VI minimum criteria. - [ISO 50001 vs EED | How a Certified Energy Management System Satisfies EED Article 11 (and What EED Adds)](/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive.md): A practical comparison of ISO 50001 vs the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): ISO 50001 is the EMS standard. ## Key dates for Directive (EU) 2023/1791 *EED Timeline* Track key milestones, including entry into force on 10 October 2023, transposition by 11 October 2025, first audits by 11 October 2026, EMS in place by 11 October 2027, and annual data centre publication from 15 May. ## What obligations apply to you under the EED *EED Decision Flow* Use the decision flow to determine the applicable obligations and thresholds, then translate the outcome into a repeatable audit or EMS program with named owners, evidence, and publication controls. *Next step* ## Turn EU Energy Efficiency Directive Compliance Hub into an ESG delivery workflow EU Energy Efficiency Directive Compliance Hub should be the shared entry point for your team. Route execution into ESG Compliance for live work and into Assessment Autopilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU Energy Efficiency Directive Compliance Hub and route the work by entity, product, team, or control owner. - Use ESG Compliance to manage cross team sustainability work, reporting, and evidence from one workflow. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open ESG Compliance](/solutions/esg-compliance.md): Manage cross team sustainability work, reporting, and evidence from one workflow for EU Energy Efficiency Directive Compliance Hub. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints from the same artifact. - **Download decision flow**: Share compliance logic with operations and audit owners. - **Download timeline**: Align planning and reporting with key dates. - [Talk through EU Energy Efficiency Directive Compliance Hub](/contact.md): Review your current process, evidence model, and next steps for EU Energy Efficiency Directive Compliance Hub. ## Decision Steps ### STEP 1: Are you an enterprise, public body, or other entity operating in the EU? *Reference: Art. 1* - The Energy Efficiency Directive applies to all EU Member States and covers enterprises, public bodies, data centres, district heating/cooling systems, and energy consumption across sectors. - If yes: determine which obligations apply to your category. - **NO** Out of Scope - **YES** Which category applies to you? ### STEP 2: Which category applies to you? - Enterprise: energy management system and/or energy audit obligations based on energy consumption thresholds (Art. 11). - SME: Member State programmes encourage SMEs not subject to Art. 11(1)-(2) to undergo energy audits and implement recommendations (Art. 11(6)-(7)). - Public bodies: public sector leading on energy efficiency (Art. 5) and exemplary role of public bodies buildings (Art. 6). - Data centre owners and operators: annual publication obligations for data centres at or above 500 kW installed IT power demand (Art. 12). - Energy distributors and retail energy sales companies may be designated as obligated parties under national obligation schemes to deliver savings (Arts. 8-10). - -> Is your enterprise's average annual energy consumption higher than 85 TJ over the previous 3 years (all energy carriers)? ### STEP 3: Is your enterprise's average annual energy consumption higher than 85 TJ over the previous 3 years (all energy carriers)? *Reference: Art. 11(1)* - If yes: you must implement an energy management system (EMS) that is certified by an independent body in accordance with relevant European or international standards. - Deadline: have a certified EMS in place by 11 October 2027. - If no: you may still be subject to an energy audit obligation if consumption is higher than 10 TJ and you do not implement an EMS (Art. 11(2)). - **YES** Energy Management System (EMS) Required - **NO** Is your enterprise's average annual energy consumption higher than 10 TJ over the previous 3 years (all energy carriers)? ### STEP 4: Is your enterprise's average annual energy consumption higher than 10 TJ over the previous 3 years (all energy carriers)? *Reference: Art. 11(2)* - If yes (and you do not implement an EMS): you must carry out an energy audit. - First energy audit deadline: 11 October 2026; subsequent audits at least every 4 years. - You must draw up an Action Plan based on audit recommendations and submit it to management; Action Plans and the implementation rate must be published in the annual report (subject to applicable secrecy/confidentiality protections). - If no: there is no mandatory Art. 11 EMS or energy audit obligation based on energy consumption thresholds (but voluntary audits are encouraged). - **YES** Do you implement an energy management system (EMS)? - **NO** Are you a small or medium-sized enterprise (SME)? ### STEP 5: Do you implement an energy management system (EMS)? *Reference: Art. 11(1)-(2)* - If your consumption is >85 TJ: you must implement an EMS that is certified by an independent body (Art. 11(1)). - If your consumption is >10 TJ: if you implement an EMS, you are not subject to the energy audit obligation in Art. 11(2). - Example standard: EN ISO 50001 (Energy management systems). - **YES** Exempt via Energy Management System - **NO** Energy Audit Obligation Applies ### SME TRACK: Are you a small or medium-sized enterprise (SME)? *Reference: Art. 2(30) and Art. 11(6)-(7)* - The EED defines SMEs by reference to Commission Recommendation 2003/361/EC (Art. 2(30)). - If you are not subject to the mandatory enterprise thresholds in Art. 11(1)-(2), Member States must develop programmes to encourage and provide technical support for SMEs to undergo energy audits and implement recommendations (Art. 11(6)-(7)). - If your enterprise exceeds the 85 TJ or 10 TJ thresholds, the obligations in Art. 11(1)-(2) can still apply regardless of SME status. - **YES** SME - Voluntary Energy Audits - **NO** Are you a public body as defined in the EED? ### PUBLIC SECTOR: Are you a public body as defined in the EED? *Reference: Art. 2(12)* - Public bodies include national, regional or local authorities and entities directly financed and administered by those authorities but not having an industrial or commercial character (Art. 2(12)). - Public bodies are covered by public sector leading on energy efficiency (Art. 5) and public bodies buildings requirements (Art. 6). - **YES** Do you own or occupy buildings with total useful floor area > 250 m2? - **NO** Do you operate a data centre with installed IT equipment power >= 500 kW? ### STEP 6: Do you own or occupy buildings with total useful floor area > 250 m2? *Reference: Art. 6* - Public bodies must renovate at least 3% of total floor area of heated/cooled buildings each year (Art. 6). - The 3% rate is calculated on the total floor area of heated/cooled buildings with total useful floor area over 250 m2 that are owned by public bodies and that, on 1 January 2024, are not nearly zero-energy buildings (Art. 6(1)). - Member States may exempt social housing where renovations are not cost neutral or would lead to rent increases that exceed energy bill savings (Art. 6(1)). - Member States may apply less stringent requirements for certain categories of buildings (Art. 6(2)). - **YES** Public Building Renovation Obligation - **NO** Does your public body consume energy (regardless of building size)? ### STEP 7: Does your public body consume energy (regardless of building size)? *Reference: Art. 5* - Member States must ensure that total final energy consumption of all public bodies combined is reduced by at least 1.9% each year compared to 2021 (Art. 5(1)). - Member States may choose to exclude public transport or the armed forces from the baseline; reductions in those sectors may still count even if excluded from the baseline (Art. 5(1)). - Transitional period until 11 October 2027: the target is indicative; it becomes binding thereafter (Art. 5(2)). - The obligation does not include, until 31 December 2026, energy consumption of public bodies in local administrative units with population < 50,000 and, until 31 December 2029, population < 5,000 (Art. 5(3)). - **YES** Public Sector Energy Consumption Reduction - **NO** Do you operate a data centre with installed IT equipment power >= 500 kW? ### DATA CENTRES: Do you operate a data centre with installed IT equipment power >= 500 kW? *Reference: Art. 12* - By 15 May 2024 and every year thereafter, Member States must require owners and operators of data centres with installed IT power demand of at least 500 kW to make the Annex VII information publicly available (Art. 12(1)). - This does not apply to data centres used for, or providing their services exclusively with the final aim of, defence and civil protection (Art. 12(2)). - **YES** Data Centre Reporting Obligation - **NO** Are you designated (or likely to be designated) as an obligated party under a national energy efficiency obligation scheme? ### SAVINGS OBLIGATION: Are you designated (or likely to be designated) as an obligated party under a national energy efficiency obligation scheme? *Reference: Arts. 8-10* - Member States must achieve cumulative end-use energy savings (Art. 8) either via obligation schemes (Art. 9) or via alternative policy measures (Art. 10), or a combination. - If your Member State uses an obligation scheme, it must designate obligated parties among energy market actors on the basis of objective and non-discriminatory criteria (Art. 9(3)). - Savings rates for 2021-2030 are set in Art. 8(1)(b) (0.8%, 1.3%, 1.5%, 1.9% across the sub-periods). - **YES** Energy Savings Obligation - **NO** Out of Scope ## Reference Information ### EED Overview (Directive 2023/1791) - Directive (EU) 2023/1791 sets Union-level energy efficiency targets for 2030 and an implementation framework for Member States. - Union 2030 targets (Art. 4): final energy consumption no more than 763 Mtoe; primary energy consumption no more than 992.5 Mtoe. - Key compliance areas covered in this decision map: enterprise EMS and energy audits (Art. 11), public sector leading by example (Arts. 5-7), data centres (Art. 12), and energy savings obligations (Arts. 8-10). ### Penalties and Enforcement - Member States must lay down rules on penalties for infringements (Art. 32). - Penalties must be effective, proportionate, and dissuasive. - Member States must notify the Commission of penalty rules and measures by 11 October 2025 (Art. 32). - National authorities are responsible for monitoring compliance and enforcing obligations. - Reporting: Member States report progress to the Commission via integrated national energy and climate plans (NECPs) and biennial reports under Governance Regulation 2018/1999. ### Annex VI - Energy Audit Minimum Criteria - Be based on up-to-date, measured, traceable operational data on energy consumption and (for electricity) load profiles. - Comprise a detailed review of the energy consumption profile of buildings (or groups), industrial operations or installations, including transportation. - Identify energy efficiency measures to decrease energy consumption and identify the potential for cost-effective use or production of renewable energy. - Build, whenever possible, on life-cycle cost analysis instead of simple payback periods to account for long-term savings and discount rates. - Be proportionate and sufficiently representative to draw a reliable picture of overall energy performance and identify the most significant opportunities for improvement. - Allow detailed and validated calculations for proposed measures, provide clear information on potential savings, and ensure the data used is storable for historical analysis and tracking performance. ### Energy Efficiency First Principle - Member States must ensure that energy efficiency solutions (including demand-side resources and system flexibilities) are assessed in planning, policy and major investment decisions above EUR 100,000,000 (or EUR 175,000,000 for transport infrastructure projects) (Art. 3(1)). - The Commission must assess the thresholds by 11 October 2027 and submit a report by 11 October 2028, followed where appropriate by legislative proposals (Art. 3(2)). - Member States are encouraged to take into account Commission Recommendation (EU) 2021/1749 when applying Article 3 (Art. 3(3)). ### National Energy Efficiency Contributions - EU 2030 headline target: 11.7% reduction in energy consumption (Art. 4). - National contributions: each Member State sets indicative contributions using objective criteria (energy intensity, GDP per capita, energy savings potential, earlier efforts). - Updated EU reference scenario (2023): Member States may use updated scenario for NECP submissions. - Gap-filling mechanism: if collective contributions fall short, Member States must adjust to ensure EU target is met. - Reporting: national contributions and progress reported via NECPs (Governance Regulation 2018/1999). ### Exemptions and Exclusions - Energy audits can comply with Art. 11(2) if implemented under voluntary agreements concluded between stakeholder organisations and an appointed and supervised body (Art. 11(9)(b)). - Enterprises implementing an energy performance contract can be exempt from Art. 11(1)-(2) if the contract covers the necessary elements of the EMS and complies with Annex XV (Art. 11(10)). - Enterprises implementing a certified environmental management system can be exempt from Art. 11(1)-(2) if it includes an energy audit based on Annex VI criteria (Art. 11(11)). - Public bodies consumption reduction: local administrative units under 50,000 population are excluded until 31 December 2026 and under 5,000 population until 31 December 2029 (Art. 5(3)). - Data centres: the Art. 12(1) obligation applies at or above 500 kW installed IT power demand; defence and civil protection data centres are excluded (Art. 12(2)). ### Training and Technical Competence - Member States must ensure certification or equivalent qualification schemes (including, where necessary, suitable training programmes) are available for energy efficiency-related professions, including providers of energy audits, energy managers and energy service providers (Art. 28(1)). - Member States must ensure providers of certification or equivalent qualification schemes are accredited or approved as required (Art. 28(1)). - Member States must promote participation in certification, training and education programmes to ensure appropriate competence levels (Art. 28(2)). ### Financing and Support Mechanisms - Member States must facilitate the establishment of financing facilities (or use existing ones) for energy efficiency improvement measures (Art. 30(1)). - By 31 December 2024, the Commission must provide guidance to help unlock private investment for energy efficiency investments (Art. 30(10)). - Member States may set up a national energy efficiency fund and use it to support priority groups affected by energy poverty and, where applicable, SMEs (Art. 30(11)-(12)). ## Possible Outcomes ### [RESULT] Energy Management System (EMS) Required Certified EMS for enterprises > 85 TJ - Implement an energy management system for your enterprise if average annual energy consumption is >85 TJ over the previous 3 years (all energy carriers) (Art. 11(1)). - Certification: EMS must be certified by an independent body in accordance with relevant European or international standards (Art. 11(1)). - Deadline: have a certified EMS in place by 11 October 2027 (Art. 11(1)). ### [RESULT] Energy Audit Obligation Applies Mandatory energy audits required - Applies to enterprises with average annual energy consumption >10 TJ over the previous 3 years (all energy carriers) that do not implement an EMS (Art. 11(2)). - First energy audit deadline: 11 October 2026; subsequent audits at least every 4 years (Art. 11(2)). - Audits must be carried out independently by qualified or accredited experts (in accordance with Article 28) or implemented and supervised by independent authorities under national legislation (Art. 11(2)). - You must draw up a concrete and feasible Action Plan based on audit recommendations, submit it to management, and publish the Action Plan and implementation rate in the annual report (subject to applicable secrecy/confidentiality protections) (Art. 11(2)). - Alternative: implement an EMS (e.g., EN ISO 50001) to avoid the Art. 11(2) audit obligation. ### [RESULT] Exempt via Energy Management System ISO 50001 or equivalent in place - Enterprises with average annual energy consumption >10 TJ are not subject to the energy audit obligation in Art. 11(2) if they implement an energy management system (Art. 11(2)). - If consumption is >85 TJ, the EMS must be certified by an independent body (Art. 11(1)). - Example standard: EN ISO 50001 (Energy management systems). ### [RESULT] SME - Voluntary Energy Audits Incentives and support available - Member States must develop programmes to encourage and provide technical support to SMEs that are not subject to Art. 11(1)-(2) to undergo energy audits and implement recommendations (Art. 11(6)-(7)). - Member States may set up support mechanisms (for example SME energy audit centres) that do not compete with private auditors, and may cover the costs of energy audits and the implementation of highly cost-effective recommendations if measures are implemented (Art. 11(6)). - Programmes must include support for quantifying the multiple benefits of energy efficiency measures and developing energy efficiency roadmaps and networks for SMEs, facilitated by independent experts (Art. 11(7)). ### [RESULT] Public Building Renovation Obligation 3% annual renovation rate - Renovate at least 3% of total floor area each year (Art. 6). - Establish and publish an inventory of heated/cooled buildings > 250 m2 by 2025-10-11. - Surplus renovation in any year (> 3%) can be counted toward following years (until 2026-12-31: next 3 years; from 2027-01-01: next 2 years). - Renovation passport: if issued, building must achieve nearly zero-energy standard by 2040 at the latest. - Public procurement energy efficiency requirements are addressed separately (Art. 7). ### [RESULT] Public Sector Energy Consumption Reduction Annual reduction targets - Reduce total final energy consumption of all public bodies combined by at least 1.9% each year compared to 2021 (Art. 5(1)). - During the transitional period ending on 11 October 2027, the target is indicative; after that it becomes binding (Art. 5(2)). - Report reductions and measures via national energy and climate plans and progress reports under Regulation (EU) 2018/1999 (Art. 5(5)). ### [RESULT] Data Centre Reporting Obligation Energy performance monitoring & reporting - Make the Annex VII information publicly available every year (Art. 12(1)). - The Commission must establish a European database on data centres that includes the information communicated by obligated data centres; the database is publicly available at an aggregated level (Art. 12(3)). - If your installed IT power demand is >= 1 MW, Member States must encourage you to take into account best practices in the European Code of Conduct on Data Centre Energy Efficiency (Art. 12(4)). ### [RESULT] Energy Savings Obligation Cumulative end-use savings required - Member States must achieve cumulative end-use energy savings for the 2021-2030 period (Art. 8(1)(b)): 0.8% (2021-2023), 1.3% (2024-2025), 1.5% (2026-2027), and 1.9% (2028-2030). - Cyprus and Malta have derogations for 2021-2023 and 2024-2030 savings rates (Art. 8(1)). - Policy measures must be implemented as a priority among people affected by energy poverty, vulnerable customers, people in low-income households and, where applicable, people living in social housing (Art. 8(3)-(4)). ### [RESULT] Out of Scope EED obligations do not directly apply - You do not fall into the categories covered by EED obligations. - However, you may still benefit from energy efficiency programmes, financial incentives, and technical support available in your Member State. - Consider voluntary energy audits and energy management systems to reduce costs and environmental impact. ## EED Timeline | Date | Event | Reference | | --- | --- | --- | | 2012-10-25 | Original EED (2012/27/EU) adopted | Directive 2012/27/EU | | 2018-12-11 | Directive (EU) 2018/2002 adopted (amending the EED) | Directive 2018/2002 | | 2023-09-13 | EED recast (2023/1791) adopted | Directive 2023/1791 | | 2023-10-10 | EED recast enters into force | Directive 2023/1791 | | 2024-05-15 | Data centre reporting and publication requirement applies (>= 500 kW installed IT power demand) | Art. 12(1) | | 2025-10-11 | Transposition deadline for EED recast | Art. 36 | | 2026-10-11 | First energy audit deadline for enterprises > 10 TJ that do not implement an EMS | Art. 11(2) | | 2027-10-11 | Certified EMS in place for enterprises > 85 TJ; public sector consumption reduction target becomes binding | Art. 5(2) and Art. 11(1) | | 2030-01-01 | EU energy efficiency target: 11.7% reduction; 992.5 Mtoe primary / 763 Mtoe final energy | Art. 4 | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2012-10-25 | Energy Efficiency Directive (2012/27/EU) adopted | Legislation | | | 2012-11-14 | Energy Efficiency Directive (2012/27/EU) published in the Official Journal (OJ L 315) | Legislation | | | 2012-12-04 | Energy Efficiency Directive (2012/27/EU) enters into force | Legislation | | | 2014-06-05 | Transposition deadline for EED (2012/27/EU) | Implementation | | | 2014-12-31 | Energy-audit provider qualification schemes deadline (EED 2012/27/EU) | Implementation | | | 2015-12-05 | First energy audit deadline for non-SMEs (EED 2012/27/EU Article 8) | Implementation | | | 2018-12-11 | Amending Energy Efficiency Directive (EU) 2018/2002 adopted | Legislation | | | 2021-07-14 | Commission proposes new Energy Efficiency Directive (Fit for 55) | Proposals & Consultations | | | 2021-09-28 | Commission Recommendation (EU) 2021/1749 adopted (Energy Efficiency First) | Guidance & Recommendations | | | 2021-10-04 | Commission Recommendation (EU) 2021/1749 published in the Official Journal (OJ L 350) | Guidance & Recommendations | | | 2022-05-01 | REPowerEU Plan presented (raising energy-efficiency ambitions) | Proposals & Consultations | | | 2022-09-30 | BS EN 16247-1:2022 (energy audits) released | Standards | | | 2023-09-13 | Recast Energy Efficiency Directive adopted (Directive (EU) 2023/1791) | Legislation | | | 2023-09-20 | Recast EED published in the Official Journal (OJ L 231) | Legislation | | | 2023-10-10 | Recast EED enters into force | Implementation | | | 2024-01-01 | Annual end-use energy savings rate increases (from 2024) | Targets & Reporting | | | 2024-02-01 | Member State notification deadline for updated national contributions (reference scenario use) | Targets & Reporting | | | 2024-04-11 | Commission guideline deadline (common framework for supervision, monitoring, reporting) | Guidance & Recommendations | | | 2024-09-23 | Commission publishes final guidance documents for implementing the revised EED | Guidance & Recommendations | | | 2025-10-11 | Transposition deadline for revised EED | Implementation | | | 2025-10-11 | Public building inventory deadline (EED Article 5) | Implementation | | | 2026-01-01 | Annual energy savings obligation increases (2026-2027) | Targets & Reporting | | | 2026-03-01 | Data centre energy efficiency package planned adoption (month-only reference) | Guidance & Recommendations | | | 2027-02-28 | Commission report submission deadline to evaluate directive effectiveness | Targets & Reporting | | | 2027-10-11 | End of transitional period for certain public sector energy reduction targets | Implementation | | | 2028-01-01 | Annual energy savings obligation increases (2028-2030) | Targets & Reporting | | | 2030-01-01 | EU collective energy-consumption reduction target year (additional 11.7% reduction) | Targets & Reporting | | **Event details:** - **2012-10-25 - Energy Efficiency Directive (2012/27/EU) adopted**: Interpretative note timeline cites Directive 2012/27/EU date: 25 October 2012. - **2012-11-14 - Energy Efficiency Directive (2012/27/EU) published in the Official Journal (OJ L 315)**: Interpretative note timeline cites Official Journal publication date: OJ L 315, 14.11.2012. - **2012-12-04 - Energy Efficiency Directive (2012/27/EU) enters into force**: Interpretative note timeline cites entry into force date: 4 December 2012. - **2014-06-05 - Transposition deadline for EED (2012/27/EU)**: Interpretative note timeline: Member States were required to bring into force national provisions (including for large enterprise audit requirements) by 5 June 2014. - **2014-12-31 - Energy-audit provider qualification schemes deadline (EED 2012/27/EU)**: Interpretative note timeline: Member States must ensure certification/accreditation or equivalent qualification schemes (and where needed training) are available for providers of energy audits by 31 December 2014. - **2015-12-05 - First energy audit deadline for non-SMEs (EED 2012/27/EU Article 8)**: Interpretative note and JRC survey timelines: enterprises that are not SMEs must be subject to a first energy audit by 5 December 2015. - **2018-12-11 - Amending Energy Efficiency Directive (EU) 2018/2002 adopted**: Directive 2012/27/EU consolidated timeline references Directive (EU) 2018/2002 date: 11 December 2018. - **2021-07-14 - Commission proposes new Energy Efficiency Directive (Fit for 55)**: Commission EED overview timeline includes a news item dated 14 July 2021 on the Commission proposal for a recast. - **2021-09-28 - Commission Recommendation (EU) 2021/1749 adopted (Energy Efficiency First)**: EUR-Lex Recommendation timeline: Commission Recommendation (EU) 2021/1749 is dated 28 September 2021. - **2021-10-04 - Commission Recommendation (EU) 2021/1749 published in the Official Journal (OJ L 350)**: EUR-Lex Recommendation timeline: publication in OJ L 350 on 4 October 2021. - **2022-05-01 - REPowerEU Plan presented (raising energy-efficiency ambitions)**: Commission EED overview timeline: REPowerEU Plan presented in May 2022. - **2022-09-30 - BS EN 16247-1:2022 (energy audits) released**: Standard reseller page timeline: release date shown as 30 September 2022 for BS EN 16247-1:2022. - **2023-09-13 - Recast Energy Efficiency Directive adopted (Directive (EU) 2023/1791)**: Directive (EU) 2023/1791 timeline: date of the Directive is 13 September 2023. - **2023-09-20 - Recast EED published in the Official Journal (OJ L 231)**: Directive (EU) 2023/1791 timeline: Official Journal publication date 20 September 2023 (L 231/1). - **2023-10-10 - Recast EED enters into force**: Commission EED overview and guidance news timeline: revised directive entered into force on 10 October 2023. - **2024-01-01 - Annual end-use energy savings rate increases (from 2024)**: Directive (EU) 2023/1791 timeline references that an annual savings rate of at least 1.3% applies from 1 January 2024. - **2024-02-01 - Member State notification deadline for updated national contributions (reference scenario use)**: Directive (EU) 2023/1791 timeline: Member States wishing to use the updated reference scenario should notify updated national contributions by 1 February 2024. - **2024-04-11 - Commission guideline deadline (common framework for supervision, monitoring, reporting)**: Directive (EU) 2023/1791 timeline: by 11 April 2024, the Commission must adopt guidelines providing a common general framework including supervision, monitoring and reporting procedures. - **2024-09-23 - Commission publishes final guidance documents for implementing the revised EED**: Commission news timeline: final guidance documents published on 23 September 2024. - **2025-10-11 - Transposition deadline for revised EED**: Commission EED overview and guidance news timeline: EU countries must transpose the new elements by 11 October 2025. - **2025-10-11 - Public building inventory deadline (EED Article 5)**: Directive (EU) 2023/1791 timeline: by 11 October 2025, Member States must establish and publish an inventory of heated/cooled buildings owned or occupied by public bodies above 250 m2. - **2026-01-01 - Annual energy savings obligation increases (2026-2027)**: Commission EED overview timeline: annual energy savings obligation for 2026-2027 is 1.5%. - **2026-03-01 - Data centre energy efficiency package planned adoption (month-only reference)**: Commission EED overview and data centre page timelines reference an upcoming data centre energy efficiency package planned for March 2026 (month-only in source timeline metadata). - **2027-02-28 - Commission report submission deadline to evaluate directive effectiveness**: Directive (EU) 2023/1791 timeline: deadline to submit a report to the European Parliament and the Council by 28 February 2027. - **2027-10-11 - End of transitional period for certain public sector energy reduction targets**: Directive (EU) 2023/1791 timeline: transitional period ending on 11 October 2027 during which the target is indicative. - **2028-01-01 - Annual energy savings obligation increases (2028-2030)**: Commission EED overview timeline: annual energy savings obligation for 2028-2030 is 1.9%. - **2030-01-01 - EU collective energy-consumption reduction target year (additional 11.7% reduction)**: Commission EED overview and guidance news timeline: EU countries must collectively ensure an additional 11.7% reduction in energy consumption by 2030. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/energy-efficiency-directive --- --- title: "EU ePrivacy Directive (2002/58/EC) Compliance Hub" canonical_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive" source_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive" author: "Sorena AI" description: "A practical compliance hub for the EU ePrivacy Directive." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "ePrivacy Directive" - "Directive 2002/58/EC" - "ePrivacy compliance" - "cookie consent EU" - "cookie banner requirements" - "terminal equipment access Article 5(3)" - "consent exemptions strictly necessary cookies" - "communications confidentiality" - "electronic communications metadata" - "direct marketing consent Article 13" - "soft opt-in EU" - "cookies" - "cookie banner" - "consent" - "direct marketing" - "communications metadata" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU ePrivacy Directive (2002/58/EC) Compliance Hub A practical compliance hub for the EU ePrivacy Directive. ![EU ePrivacy Directive artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-eprivacy-timeline-small.jpg?v=cheatsheets%2Fprod) *ePrivacy* *Free Resource* ## EU ePrivacy Directive Compliance Hub Scope cookies and terminal equipment access under Article 5(3), communications confidentiality and traffic or location data use cases, and direct marketing workflows under Article 13. Use the decision flow to turn product facts into a defensible consent model and evidence pack. The current legal baseline is still Directive 2002/58/EC, as amended by Directive 2009/136/EC and interpreted through national laws, GDPR consent standards, and recent EDPB enforcement positions. Treat the proposed ePrivacy Regulation only as reform context unless and until it is adopted. [Start with the checklist](/artifacts/eu/eprivacy-directive/checklist.md) ## What you can decide faster - **Terminal equipment access**: When cookies/SDKs need consent vs exemptions. - **Cookie banner UX**: What "valid consent" looks like in practice (and common failure modes). - **Direct marketing rules**: Consent, soft opt-in, and opt-out evidence you must retain. By Sorena AI | Updated Mar 2026 | No signup required ### Quick scan *ePrivacy* - **Cookies / SDKs**: Map storage/access to consent or exemptions (Article 5(3)). - **Banner UX**: Implement choice, granularity, and withdrawal with evidence. - **Marketing**: Operationalize consent, soft opt-in, and suppression lists (Article 13). Use the decision flow to pick a defensible consent model, then standardize implementation with checklists and templates. | Value | Metric | | --- | --- | | 2002 | Directive | | 2009 | Cookie update | | 2020 | Consent guide | | 2023 | Banner report | **Key highlights:** Scope checks | Consent model | Audit evidence ## Topic Guides - [Confidentiality of Communications (ePrivacy Directive) | Traffic Data, Location Data, Content, and the OTT Gap](/artifacts/eu/eprivacy-directive/confidentiality-of-communications.md): A practical guide to communications confidentiality under the current ePrivacy Directive, Directive 2002/58/EC: how to classify content, traffic data. - [Cookies & Consent (ePrivacy Directive Article 5(3)) | Exemptions Test, Analytics, CMP Implementation](/artifacts/eu/eprivacy-directive/cookies-and-consent.md): An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage. - [Direct Marketing Consent Checklist (ePrivacy Article 13) | Proof, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist.md): A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control. - [Direct Marketing Rules (ePrivacy Directive Article 13) | Consent, Soft Opt-In, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-rules.md): A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed. - [ePrivacy Applicability Test (Directive 2002/58/EC) | Cookies Article 5(3), Marketing Article 13, Metadata](/artifacts/eu/eprivacy-directive/applicability-test.md): A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting. - [ePrivacy Checklist (Directive 2002/58/EC) | Cookie Banner, Consent Logs, Exemptions, Marketing Evidence](/artifacts/eu/eprivacy-directive/checklist.md): An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions). - [ePrivacy Compliance Program | Cookies, Consent UX, Evidence, Marketing Controls (Directive 2002/58/EC)](/artifacts/eu/eprivacy-directive/compliance.md): A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design. - [ePrivacy Deadlines and Compliance Calendar | Directive Baseline, Banner Audits, Marketing Audits](/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar.md): A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment. - [ePrivacy Directive Enforcement (Cookies + Marketing) | How Regulators Assess Cookie Banners, Consent, and Evidence](/artifacts/eu/eprivacy-directive/enforcement-and-fines.md): An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX. - [ePrivacy Directive Penalties and Fines | What "Effective, Proportionate, Dissuassive" Means + Risk Reduction Controls](/artifacts/eu/eprivacy-directive/penalties-and-fines.md): Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC). - [ePrivacy Directive Requirements (2002/58/EC) | Article 5(3) Cookies, Article 13 Marketing, Metadata + Evidence Map](/artifacts/eu/eprivacy-directive/requirements.md): A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3)). - [ePrivacy Directive vs GDPR | Which Law Applies to Cookies, Tracking, Communications Metadata, and Marketing?](/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr.md): A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality. - [ePrivacy FAQ (Directive 2002/58/EC) | Cookies, Consent Exemptions, Cookie Walls, Marketing, Enforcement](/artifacts/eu/eprivacy-directive/faq.md): High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194). - [ePrivacy vs GDPR (Cookie Stack Blueprint) | Align Consent UX, Tag Firing, Processing Purposes, and Evidence](/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr.md): A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing. - [EU Cookie Banner Requirements | ePrivacy Directive + GDPR Consent (EDPB) | UX Patterns + Test Cases](/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements.md): A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes. ## Key milestones for ePrivacy *ePrivacy Timeline* Track the current legal baseline, 2002 directive, 2009 cookie amendment, GDPR-era consent guidance, and 2023 enforcement learnings, then align your banner and marketing program cadence. ## Which ePrivacy rules apply to your product and marketing *ePrivacy Decision Flow* Use the decision flow to scope cookies and device access, communications confidentiality, and direct marketing, then translate outcomes into banner design, consent evidence, and operational controls. *Next step* ## Turn EU ePrivacy Directive Compliance Hub into a cited research workflow EU ePrivacy Directive Compliance Hub should be the shared entry point for your team. Route execution into Research Copilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU ePrivacy Directive Compliance Hub and route the work by entity, product, team, or control owner. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs for EU ePrivacy Directive Compliance Hub. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share scope and consent logic internally. - **Download timeline**: Align milestones and program cadence. - [Talk through EU ePrivacy Directive Compliance Hub](/contact.md): Review your current process, evidence model, and next steps for EU ePrivacy Directive Compliance Hub. ## Decision Steps ### STEP 1: Are you processing electronic communications data, accessing terminal equipment information, offering a publicly available directory, or sending direct marketing communications to end-users in the EU? *Reference: Council mandate ST 6087/21 (draft ePrivacy Regulation), Articles 1 to 3* - The draft Regulation material scope includes: (a) processing of electronic communications content and metadata, (b) end-users terminal equipment information, (c) offering publicly available directories, and (d) sending direct marketing communications to end-users (Article 2(1)). - The territorial scope covers the provision and use of these activities for end-users who are in the Union, and includes a representative requirement for certain non-EU entities (Article 3). - Where the relevant provider or person is not established in the Union, the Council mandate text requires designating a representative in the Union within one month from the start of activities, subject to an exception for occasional low-risk activities (Article 3(2) and (2a)). - The Council mandate text states Directive 2002/58/EC should be repealed (recital 43). - **NO** Out of Scope - **YES** Which draft ePrivacy Regulation obligations apply to your activities? ### STEP 2: Which draft ePrivacy Regulation obligations apply to your activities? - Terminal equipment: if you use processing and storage capabilities or collect information from end-users terminal equipment (Article 8). - Confidentiality and processing of communications data: if you interfere with or process electronic communications content or metadata (Articles 5 to 7, and related rules). - Communications metadata: if you process electronic communications metadata (including location data) beyond what is necessary to provide the service (Articles 6b and 6c). - Direct marketing: if you send direct marketing communications to end-users (Article 16). - Directories and line identification: if you offer publicly available directories or provide calling or connected line identification options (Articles 12 to 15). - Multiple obligations may apply simultaneously. - -> Do you use cookies or similar techniques to use processing and storage capabilities of terminal equipment or collect information from end-users terminal equipment? ### COOKIES: Do you use cookies or similar techniques to use processing and storage capabilities of terminal equipment or collect information from end-users terminal equipment? *Reference: Council mandate ST 6087/21 (draft ePrivacy Regulation), Article 8* - This includes cookies, SDKs, web storage, tracking pixels, and similar technologies that access or store information on a device or collect device-emitted information. - The Council mandate text prohibits these activities unless one of the grounds listed in Article 8 applies, including end-user consent or specific necessity-based grounds. - WP29 Opinion 04/2012 (WP194) provides detailed analysis of strict necessity concepts under the current Directive, which can help interpret similar concepts in practice. - **NO** Do you interfere with, or as a provider process, electronic communications content or electronic communications metadata? - **YES** Is your terminal equipment access covered by a non-consent ground in Article 8? ### STEP 3: Is your terminal equipment access covered by a non-consent ground in Article 8? *Reference: Council mandate ST 6087/21 (draft ePrivacy Regulation), Article 8* - Examples of non-consent grounds in the Council mandate text include: necessity to provide an electronic communications service; strict necessity to provide a service specifically requested by the end-user; audience measurement under conditions; maintaining or restoring security, preventing fraud, or detecting faults; and software updates under conditions (Article 8(1)). - If any purpose does not meet an Article 8 non-consent ground, you generally need end-user consent for that purpose (Article 8(1)(b)). - If you collect information emitted by terminal equipment to enable connection (for example WiFi or Bluetooth signals), Article 8(2) and its conditions may apply. - **YES** No Consent (Specific Case) - **NO** Consent Required ### CONFIDENTIALITY: Do you interfere with, or as a provider process, electronic communications content or electronic communications metadata? *Reference: Council mandate ST 6087/21 (draft ePrivacy Regulation), Articles 5 to 7* - The Council mandate text sets a confidentiality rule for electronic communications data and prohibits interference such as listening, tapping, storing, monitoring, scanning, or other interception or surveillance, except when permitted by the Regulation (Article 5). - It includes specific grounds for providers to process electronic communications data (Article 6), content (Article 6a), and metadata (Article 6b), and rules on storage and erasure (Article 7). - **NO** Do you process electronic communications metadata (including location data) beyond what is necessary to provide the service? - **YES** Confidentiality and Communications Data Rules Apply ### TRAFFIC & LOCATION: Do you process electronic communications metadata (including location data) beyond what is necessary to provide the service? *Reference: Council mandate ST 6087/21 (draft ePrivacy Regulation), Articles 4 and 6b* - Electronic communications metadata includes data used to trace and identify the source and destination of a communication, location data generated in the context of providing services, and the date, time, duration, and type of communication (Article 4(3)(c)). - The Council mandate text sets specific permitted grounds for processing electronic communications metadata, including network management, contract performance and billing, end-user consent, vital interests, and certain research and statistical purposes (Article 6b). - **NO** Do you use electronic communications services to send direct marketing communications to end-users? - **YES** Electronic Communications Metadata Rules Apply ### DIRECT MARKETING: Do you use electronic communications services to send direct marketing communications to end-users? *Reference: Council mandate ST 6087/21 (draft ePrivacy Regulation), Article 16* - The Council mandate text defines direct marketing communications as advertising sent via a publicly available electronic communications service directly to one or more specific end-users, including voice-to-voice calls, automated calling systems, and electronic messages (Article 4(3)(f)). - It sets a general prohibition on sending direct marketing communications to end-users who are natural persons unless they have given prior consent, with specific rules and exceptions in Article 16. - **NO** Are you including end-user information in a publicly available directory or directory enquiry service? - **YES** Which communication medium do you use for direct marketing? ### STEP 4: Which communication medium do you use for direct marketing? - Electronic messages (email, SMS, MMS, and functionally equivalent applications) are covered by the Council mandate definition of electronic message (Article 4(3)(e)) and the Article 16 consent rule with an exception for existing customer contact details (Article 16(1) to (2)). - Direct marketing calls must present calling line identification (Article 16(3)), and Member States may allow voice-to-voice marketing calls to natural persons on an opt-out basis (Article 16(4)). - The Council mandate text also requires that direct marketing communications clearly identify the sender and provide a free and effective way to withdraw consent or object (Article 16(6)). - -> Are you sending direct marketing as an electronic message (for example email, SMS, or functionally equivalent apps)? ### EMAIL/SMS: Are you sending direct marketing as an electronic message (for example email, SMS, or functionally equivalent apps)? *Reference: Council mandate ST 6087/21 (draft ePrivacy Regulation), Articles 4 and 16* - The Council mandate text generally prohibits direct marketing communications to end-users who are natural persons unless they have given prior consent (Article 16(1)). - It also includes an exception where contact details for electronic messages were obtained in the context of a purchase, allowing marketing of similar products or services if the end-user was given a clear and free opportunity to object at collection and in each subsequent message (Article 16(2)). - **YES** Electronic Message Marketing Requirements - **NO** Are you placing direct marketing voice-to-voice calls to end-users who are natural persons? ### TELEPHONE: Are you placing direct marketing voice-to-voice calls to end-users who are natural persons? *Reference: Council mandate ST 6087/21 (draft ePrivacy Regulation), Article 16* - The Council mandate text requires that direct marketing calls present the calling line identification assigned to the sender (Article 16(3)). - It also allows Member States, by law, to permit direct marketing voice-to-voice calls to natural persons on an opt-out basis (Article 16(4)). - **YES** Telephone Marketing Obligations Apply - **NO** Direct Marketing Rules Do Not Apply ### DIRECTORIES: Are you including end-user information in a publicly available directory or directory enquiry service? *Reference: Council mandate ST 6087/21 (draft ePrivacy Regulation), Article 15* - The Council mandate text defines publicly available directories and sets rules for including end-users data (Article 4(3)(d) and Article 15). - For end-users who are natural persons, providers must obtain consent to include personal data in a directory and for inclusion per category of personal data, unless Member States provide an objection-based approach (Article 15(1) and (1aa)). - End-users must be able to verify, correct, and delete directory data, and to not be included, free of charge (Article 15(3a) and (4)). - **NO** Do you offer calling or connected line identification presentation options? - **YES** Directory Obligations Apply ### LINE ID: Do you offer calling or connected line identification presentation options? *Reference: Council mandate ST 6087/21 (draft ePrivacy Regulation), Articles 12 to 14* - The Council mandate text sets options end-users must have regarding calling line identification and connected line identification where those features are offered (Article 12). - It includes emergency-related exceptions (Article 13) and rules for nuisance or malicious calls (Article 14). - **NO** Line Identification Rules Do Not Apply - **YES** Line Identification Obligations Apply ## Reference Information ### Draft ePrivacy Regulation: Key Areas - Confidentiality: electronic communications data must be confidential and interference is prohibited unless permitted by the Regulation (Article 5). - Permitted processing: providers may process electronic communications data only on the grounds set out in the Regulation, including specific rules for content and for metadata (Articles 6, 6a, 6b, 6c). - Terminal equipment: using processing and storage capabilities or collecting information from end-users terminal equipment is prohibited unless an Article 8 ground applies (Article 8). - Territorial scope: applies to end-users who are in the Union and can require a representative for certain non-EU providers and persons (Article 3). - End-user control: calling and connected line identification rules and emergency exceptions (Articles 12 to 14). - Directories and direct marketing: rules for publicly available directories and for unsolicited and direct marketing communications (Articles 15 and 16). - Restrictions and enforcement: legislative restrictions (Article 11) and administrative fines aligned with GDPR Article 83 (Article 23). ### Relationship with GDPR - The Council mandate text states the draft Regulation particularises and complements GDPR by laying down specific rules (Article 1(3)). - Many definitions and concepts are taken from GDPR (Article 4(1)). - Consent in the Council mandate text relies on GDPR consent provisions for natural persons and applies mutatis mutandis to legal persons (Article 4a). - EDPB Opinion 5/2019 discusses competence, tasks, and cooperation for enforcing ePrivacy rules alongside GDPR. ### Enforcement and Penalties - The Council mandate text provides for remedies (Article 21) and a right to compensation and liability aligned with GDPR Article 82 (Article 22). - Administrative fines follow GDPR Article 83 mutatis mutandis (Article 23(1)). - For certain infringements (including Article 8 terminal equipment rules, Article 15 directories, Article 16 direct marketing, and the representative obligation), the upper limit is up to EUR 10,000,000 or 2% of worldwide annual turnover (Article 23(2)). - For infringements of confidentiality, permitted processing, and time limits for erasure (Articles 5 to 7), the upper limit is up to EUR 20,000,000 or 4% of worldwide annual turnover (Article 23(3)). - The EDPB Cookie Banner Taskforce report discusses practical expectations around withdrawal mechanisms and banner design patterns in enforcement contexts. ### Proposed ePrivacy Regulation (Under Negotiation) - The Commission proposal date is 10 January 2017 (procedure sources in the grounding data). - The Council mandate (ST 6087/21) contains consolidated draft text and states Directive 2002/58/EC should be repealed. - The procedure file and Parliament sources in the grounding data summarize steps in the legislative process, including committee work and a Council negotiating mandate. - EDPB Statement 03/2021 calls for swift adoption and highlights the need for a coherent framework with GDPR. ### Consent Under ePrivacy and GDPR - The Council mandate text applies GDPR consent provisions to natural persons and, mutatis mutandis, to legal persons (Article 4a(1)). - EDPB Guidelines 05/2020 explain key GDPR consent requirements, including freely given, specific, informed, unambiguous consent and the ability to withdraw consent at any time. - The Council mandate text allows consent, where technically possible and feasible, to be expressed via appropriate software technical settings, and states that directly expressed end-user consent prevails over software settings (Article 4a(2) and (2aa)). - Where a provider cannot identify a data subject, the Council mandate text indicates that a technical protocol showing consent from the terminal equipment may be sufficient to demonstrate end-user consent for Article 8(1)(b) (Article 4a(2a)). - The Council mandate text includes a concept of periodic consent withdrawal reminders (no longer than 12 months) while processing continues, unless the end-user requests not to receive reminders (Article 4a(3)). - EDPB guidance on cookie walls addresses the risk that conditional access can undermine the freely given nature of consent. - The Cookie Banner Taskforce report discusses practical expectations around withdrawal mechanisms and certain banner design patterns in enforcement contexts. ### Cookie Consent Exemptions (WP29 Opinion 04/2012) - CRITERION A (sole purpose of transmission): cookies used for the sole purpose of carrying out the transmission of a communication over an electronic communications network. - CRITERION B (strictly necessary for explicitly requested service): cookies strictly necessary for a functionality explicitly requested by the user. - WP29 concludes first-party and third-party analytics cookies do not fall under CRITERION A or B, while noting first-party analytics may present limited privacy risk if safeguards are in place. - Multi-purpose cookies: if a cookie serves multiple purposes, it is exempt only if all purposes individually qualify for an exemption. - Lifespan: WP29 notes exempt cookies should expire once they are no longer needed for their purpose. ### Restrictions and Access Requests - The Council mandate text allows Union or Member State law to restrict the scope of obligations and rights in Articles 5 to 8 under conditions that align with GDPR Article 23(1) interests and proportionality requirements (Article 11(1)). - It requires providers to establish internal procedures for responding to requests for access to end-users electronic communications data based on such legislative measures, and to provide information about those procedures and requests to the competent supervisory authority on demand (Article 11(2)). - The Council mandate text also includes a permitted processing ground for providers where necessary for compliance with a legal obligation under Union or Member State law meeting proportionality conditions (Article 6(1)(d)). ### Key EDPB Guidance on ePrivacy - EDPB Opinion 5/2019 discusses how ePrivacy rules and GDPR relate, including competence, tasks, and cooperation mechanisms for enforcement. - EDPB Guidelines 05/2020 explain GDPR consent requirements used in cookie and tracking contexts. - The EDPB reply letter on cookie walls explains that conditional access can undermine freely given consent. - The EDPB Cookie Banner Taskforce report (adopted 17 January 2023) discusses common banner patterns (for example missing reject options, link design, and withdrawal usability) and highlights the need for case-by-case assessment. - EDPB Statement 03/2021 calls for swift adoption of the ePrivacy Regulation. ### Do Not Track and Browser Signals - WP29 Opinion 04/2012 discusses Do Not Track (DNT) and notes its participation in W3C standardization efforts, arguing that DNT should mean no identifiers for tracking are set or processed for tracking purposes. - The impact assessment grounding material references an EU DNT standard as a possible area for promoting standards and codes of conduct. - The Council mandate text allows consent to be expressed via appropriate software settings where technically possible and feasible, with directly expressed end-user consent prevailing over software settings (Article 4a(2) and (2aa)). ## Possible Outcomes ### [RESULT] Out of Scope Draft ePrivacy Regulation does not apply - Your activity does not fall within the Council mandate text material scope (Article 2(1)) and territorial scope (Article 3). - Examples of exclusions in the Council mandate text include: national security and defence measures, non-publicly available electronic communications services, competent authorities processing for criminal law purposes, and electronic communications data processed after receipt by the end-user concerned (Article 2(2)). - If you still process personal data, GDPR may apply. ### [RESULT] Consent Required Terminal equipment processing requires end-user consent - Obtain end-user consent when relying on the consent ground for terminal equipment processing (Article 8(1)(b)). - The Council mandate text applies GDPR consent provisions to natural persons and, mutatis mutandis, to legal persons (Article 4a). - EDPB Guidelines 05/2020 explain key GDPR consent requirements, including that withdrawal must be as easy as giving consent. - EDPB guidance on cookie walls indicates that making access to a service conditional on consent to non-essential cookies can undermine the freely given nature of consent. - For terminal equipment processing, consent may be expressed via appropriate software technical settings where technically possible and feasible (Article 4a(2)), and directly expressed end-user consent prevails over software settings (Article 4a(2aa)). ### [RESULT] No Consent (Specific Case) An Article 8 non-consent ground applies - Your terminal equipment processing fits within an Article 8 non-consent ground, such as strict necessity for a specifically requested service, audience measurement under conditions, or security and fraud prevention (Article 8). - Examples include: providing an electronic communications service; providing a specifically requested service; audience measurement under the Council mandate conditions (including certain third party processing under GDPR Articles 26 or 28); maintaining or restoring security, preventing fraud, or detecting faults; security software updates that do not change privacy settings and allow postponement; and emergency communications location (Article 8(1)). - This result only applies to the specific purposes that qualify. If you add another purpose that does not qualify, you may need end-user consent for that purpose. - If personal data is processed, GDPR may still apply. ### [RESULT] Confidentiality and Communications Data Rules Apply Confidentiality and permitted processing requirements - Treat electronic communications data as confidential and do not interfere with it unless permitted by the Regulation (Article 5). - If you are a provider, process electronic communications data only on the grounds listed in the Regulation (Articles 6, 6a, 6b, 6c). - For content processing beyond providing a service requested for purely individual use, the Council mandate text generally requires the consent of all end-users concerned (Article 6a). - Apply storage and erasure rules for content and metadata (Article 7). - Restrictions may be introduced by Union or Member State law under the conditions set out in the Regulation (Article 11). ### [RESULT] Electronic Communications Metadata Rules Apply Permitted grounds and safeguards for metadata processing - Providers may process electronic communications metadata only if an Article 6b ground applies, including network management and optimisation, contract performance and billing, fraud prevention, end-user consent, and limited research and statistical grounds with safeguards (Article 6b). - The Council mandate text sets conditions for compatible further processing of metadata, including pseudonymisation, erasure or anonymisation when no longer needed, and restrictions on profiling-type use (Article 6c). - Metadata must be erased or made anonymous when no longer needed to provide the service, subject to specific exceptions listed in the Council mandate text (Article 7). ### [RESULT] Electronic Message Marketing Requirements Consent rule with an existing-customer exception - If you rely on consent, obtain prior consent from end-users who are natural persons (Article 16(1)) and ensure withdrawal is possible and easy (Article 16(6)). - If you rely on the existing-customer exception, ensure the contact details were obtained in the context of a purchase, marketing is limited to your own similar products or services, and the end-user was given a clear and free opportunity to object at collection and in each subsequent message (Article 16(2)). - When sending any direct marketing communication, reveal identity and provide effective return addresses or numbers, make the marketing nature clear, and provide a free and effective way to object or withdraw consent (Article 16(6)). ### [RESULT] Telephone Marketing Obligations Apply Calling line identification and Member State rules - Present the calling line identification assigned to you when placing direct marketing calls (Article 16(3)). - Where applicable, comply with any Member State requirements for a specific code or prefix identifying a direct marketing call (Article 16(3a)). - If a Member State uses an opt-out regime for voice-to-voice marketing calls, ensure you do not call end-users who have expressed their objection (Article 16(4)). ### [RESULT] Direct Marketing Rules Do Not Apply No unsolicited direct marketing - You are not using electronic communications services to send direct marketing communications, so Article 16 does not apply. - If you start sending direct marketing communications later, apply the Article 16 rules and ensure recipients can object or withdraw consent free of charge. ### [RESULT] Directory Obligations Apply Consent or objection model, plus user control rights - For natural persons, obtain consent to include personal data in a directory (and per category), unless Member State law uses an objection model (Article 15(1) and (1aa)). - Inform end-users about search functions that are not based on name or number and obtain consent before enabling such search functions related to their data (Article 15(2)). - Provide legal persons with the possibility to object to data related to them being included (Article 15(3)). - Provide end-users the means to verify, correct, and delete directory data, free of charge (Article 15(3a) and (4)). ### [RESULT] Line Identification Obligations Apply End-user options and emergency exceptions - Where presentation is offered, provide end-users with options to prevent and control presentation of calling and connected line identification, and to reject incoming calls where calling line identification has been prevented (Article 12(1)). - Override elimination and certain consent settings for emergency communications as set out in the Council mandate text (Article 13). - Member States may establish more specific provisions for tracing unwanted, malicious, or nuisance calls (Article 14). ### [RESULT] Line Identification Rules Do Not Apply No calling/connected line identification services - You do not offer calling or connected line identification options, so Articles 12 to 14 do not apply to you. - If you later offer those features, implement the end-user options and emergency-related exceptions described in the Council mandate text. ## ePrivacy Timeline | Date | Event | Reference | | --- | --- | --- | | 2002-07-31 | Directive 2002/58/EC published in the Official Journal (OJ L 201) | SWD(2017) 3 reference: OJ L 201, 31.07.2002 | | 2009-01-01 | Directive 2002/58/EC modified by Directive 2009/136/EC (as referenced in sources) | SWD(2017) 3 reference | | 2012-06-07 | WP29 adopts Opinion 04/2012 (WP194) on cookie consent exemptions | WP29 Opinion 04/2012 | | 2017-01-10 | Commission proposes the ePrivacy Regulation | COM(2017) 10 final | | 2019-03-12 | EDPB adopts Opinion 5/2019 on ePrivacy Directive and GDPR interplay | EDPB Opinion 5/2019 | | 2020-05-04 | EDPB adopts Guidelines 05/2020 on GDPR consent | EDPB Guidelines 05/2020 | | 2021-02-10 | Council negotiation mandate published (ST 6087/21) | ST 6087/21 | | 2023-01-17 | EDPB Cookie Banner Taskforce report adopted | EDPB Cookie Banner Taskforce report | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2002-07-12 | ePrivacy Directive 2002/58/EC adopted | ePrivacy Directive | | | 2002-07-31 | Directive 2002/58/EC published in the Official Journal (OJ L 201) | ePrivacy Directive | | | 2009-01-01 | ePrivacy Directive revised in 2009 (as referenced in sources) | ePrivacy Directive | | | 2012-06-07 | WP29 Opinion 04/2012 on cookie consent exemption adopted | WP29/EDPB Guidance | | | 2016-04-11 | Commission ePrivacy factsheet published | Commission Actions | | | 2016-07-22 | EDPS Preliminary Opinion 5/2016 on the ePrivacy review | EDPS Opinions | | | 2017-01-10 | Commission proposes the ePrivacy Regulation | Proposed Regulation | | | 2017-01-10 | Commission impact assessment issued (SWD(2017) 3 final) | Commission Actions | | | 2017-02-16 | European Parliament: committee referral announced (1st reading) | Proposed Regulation | | | 2017-04-24 | EDPS Opinion 6/2017 on the proposed ePrivacy Regulation published | EDPS Opinions | | | 2017-06-09 | Council: debate in Council (TTE) recorded in procedure file | Proposed Regulation | | | 2017-10-05 | EDPS recommendations on Parliament amendments published | EDPS Opinions | | | 2017-10-19 | European Parliament: LIBE vote and decision to open negotiations | Proposed Regulation | | | 2017-10-23 | European Parliament: committee report tabled for plenary (1st reading) | Proposed Regulation | | | 2017-12-04 | Council: TTE meeting noted in the procedure file | Proposed Regulation | | | 2018-05-18 | Commission ePrivacy factsheet updated | Commission Actions | | | 2018-05-25 | EDPB statement on the revision of the ePrivacy Regulation adopted | WP29/EDPB Guidance | | | 2019-03-12 | EDPB Opinion 5/2019 adopted (interplay between ePrivacy Directive and GDPR) | WP29/EDPB Guidance | | | 2020-05-04 | EDPB Guidelines 05/2020 on consent adopted | WP29/EDPB Guidance | | | 2020-11-19 | EDPB reply letter on cookie walls issued | WP29/EDPB Guidance | | | 2020-11-19 | EDPB statement on the ePrivacy Regulation and future supervisory role adopted | WP29/EDPB Guidance | | | 2021-02-10 | Council negotiation mandate published (ST 6087/21) | Proposed Regulation | | | 2021-03-09 | Commission ePrivacy factsheet last updated | Commission Actions | | | 2021-03-09 | EDPB Statement 03/2021 adopted | WP29/EDPB Guidance | | | 2022-08-01 | Repeal date placeholder for Directive 2002/58/EC (in Council draft) | Proposed Regulation | | | 2023-01-17 | EDPB Cookie Banner Taskforce report adopted | Enforcement & Reports | | | 2024-08-01 | Monitoring programme deadline placeholder (in Council draft) | Proposed Regulation | | **Event details:** - **2002-07-12 - ePrivacy Directive 2002/58/EC adopted**: Directive 2002/58/EC date: 12 July 2002. - **2002-07-31 - Directive 2002/58/EC published in the Official Journal (OJ L 201)**: Impact assessment timeline cites: OJ L 201, 31.07.2002, p. 37. - **2009-01-01 - ePrivacy Directive revised in 2009 (as referenced in sources)**: Legislative documents referenced in the grounding data describe the last revision of the ePrivacy Directive as occurring in 2009 (Directive 2009/136/EC is cited as the amending instrument). - **2012-06-07 - WP29 Opinion 04/2012 on cookie consent exemption adopted**: Opinion 04/2012 (WP194) adopted on 7 June 2012. - **2016-04-11 - Commission ePrivacy factsheet published**: Commission digital-strategy factsheet publication date shown: 11 April 2016. - **2016-07-22 - EDPS Preliminary Opinion 5/2016 on the ePrivacy review**: EDPS preliminary opinion on the review of the ePrivacy Directive issued on 22 July 2016. - **2017-01-10 - Commission proposes the ePrivacy Regulation**: Commission proposal date shown: 10 January 2017 (procedure files and Commission factsheet). - **2017-01-10 - Commission impact assessment issued (SWD(2017) 3 final)**: Impact assessment SWD(2017) 3 final is dated Brussels, 10 January 2017 (published alongside the ePrivacy Regulation proposal). - **2017-02-16 - European Parliament: committee referral announced (1st reading)**: Procedure file timeline lists 16 February 2017 as the committee referral announcement in Parliament. - **2017-04-24 - EDPS Opinion 6/2017 on the proposed ePrivacy Regulation published**: EDPS Opinion 6/2017 is dated 24 April 2017. - **2017-06-09 - Council: debate in Council (TTE) recorded in procedure file**: Procedure file lists a Council debate date of 9 June 2017 (Transport, Telecommunications and Energy). - **2017-10-05 - EDPS recommendations on Parliament amendments published**: EDPS recommendations document is dated 5 October 2017. - **2017-10-19 - European Parliament: LIBE vote and decision to open negotiations**: Procedure file lists 19 October 2017 as the committee vote and decision to open interinstitutional negotiations. - **2017-10-23 - European Parliament: committee report tabled for plenary (1st reading)**: Procedure file lists 23 October 2017 as the date the committee report was tabled for plenary (1st reading). - **2017-12-04 - Council: TTE meeting noted in the procedure file**: Procedure file lists a Council meeting (Transport, Telecommunications and Energy) on 4 December 2017 in the legislative process. - **2018-05-18 - Commission ePrivacy factsheet updated**: Commission ePrivacy factsheet footer shows: Updated 18 May 2018. - **2018-05-25 - EDPB statement on the revision of the ePrivacy Regulation adopted**: EDPB statement on the revision of the ePrivacy Regulation and its impact on privacy and confidentiality of communications adopted on 25 May 2018. - **2019-03-12 - EDPB Opinion 5/2019 adopted (interplay between ePrivacy Directive and GDPR)**: Opinion 5/2019 adoption date shown: 12 March 2019. - **2020-05-04 - EDPB Guidelines 05/2020 on consent adopted**: Guidelines 05/2020 adoption date shown: 4 May 2020. - **2020-11-19 - EDPB reply letter on cookie walls issued**: Reply letter on cookie walls is dated 19 November 2020. - **2020-11-19 - EDPB statement on the ePrivacy Regulation and future supervisory role adopted**: EDPB statement on the ePrivacy Regulation and the future role of supervisory authorities and the EDPB adopted on 19 November 2020. - **2021-02-10 - Council negotiation mandate published (ST 6087/21)**: Council mandate document shows Brussels date: 10 February 2021. - **2021-03-09 - Commission ePrivacy factsheet last updated**: Commission digital-strategy factsheet shows last update: 9 March 2021. - **2021-03-09 - EDPB Statement 03/2021 adopted**: EDPB Statement 03/2021 adoption date shown: 9 March 2021. - **2022-08-01 - Repeal date placeholder for Directive 2002/58/EC (in Council draft)**: Council mandate draft text includes a bracketed repeal effect date for Directive 2002/58/EC: 1 August 2022. - **2023-01-17 - EDPB Cookie Banner Taskforce report adopted**: Cookie Banner Taskforce report adoption date shown: 17 January 2023. - **2024-08-01 - Monitoring programme deadline placeholder (in Council draft)**: Council mandate draft includes a bracketed deadline: by 1 August 2024 the Commission shall establish a detailed monitoring programme for the Regulation’s effectiveness. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eprivacy-directive --- --- title: "EU GDPR (Regulation (EU) 2016/679) Compliance Hub" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr" source_url: "https://www.sorena.io/artifacts/eu/general-data-protection-regulation" author: "Sorena AI" description: "A practical GDPR compliance hub for Regulation (EU) 2016/679: run Article 2 to 3 scope analysis, choose and document lawful bases." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "GDPR compliance" - "Regulation (EU) 2016/679" - "GDPR applicability test" - "GDPR checklist" - "GDPR DSAR workflow" - "GDPR DPIA" - "GDPR breach notification 72 hours" - "GDPR international transfers SCCs" - "GDPR processor contract Article 28" - "GDPR lawful basis Article 6" - "GDPR consent Article 7" - "GDPR" - "DSAR" - "international transfers" - "SCCs" - "DPIA" - "breach notification" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GDPR (Regulation (EU) 2016/679) Compliance Hub A practical GDPR compliance hub for Regulation (EU) 2016/679: run Article 2 to 3 scope analysis, choose and document lawful bases. ![EU GDPR artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-gdpr-timeline-small.jpg?v=cheatsheets%2Fprod) *GDPR* *Free Resource* ## EU GDPR Compliance Hub Turn Regulation (EU) 2016/679 into an execution plan: scope your processing, choose lawful bases, operationalize DSAR and breach workflows, engineer transfer safeguards, and keep audit-ready evidence. This is a practical reference, not legal advice. GDPR interpretation and supervisory authority expectations can vary by case and jurisdiction-validate against your processing context and relevant guidance. [Start with the checklist](/artifacts/eu/gdpr/checklist.md) ## What you can decide faster - **Scope and roles**: Territorial scope, establishment/targeting, and controller vs processor boundaries. - **Transfers**: When Chapter V applies and how to operationalize SCCs + supplementary measures. - **Operational workflows**: DSAR, breach response, DPIAs, and vendor governance with evidence. By Sorena AI | Updated Mar 2026 | No signup required ### Quick scan *GDPR* - **Applicability**: Run the Article 2-3 applicability test and role mapping. - **Controls**: Implement lawful basis, DSAR, breach, DPIA, and vendor controls. - **Evidence**: Build an exportable evidence index for audits and regulators. Use the decision flow to scope applicability, then follow the subpages to implement controls and evidence that hold up under scrutiny. | Value | Metric | | --- | --- | | 2016 | Regulation | | 2018 | Applies | | 72h | Breach notify | | 1m | DSAR target | **Key highlights:** Scope first | Transfers matter | Evidence wins ## Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/general-data-protection-regulation/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/general-data-protection-regulation/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/general-data-protection-regulation/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/general-data-protection-regulation/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/general-data-protection-regulation/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/general-data-protection-regulation/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/general-data-protection-regulation/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/general-data-protection-regulation/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/general-data-protection-regulation/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/general-data-protection-regulation/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/general-data-protection-regulation/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/general-data-protection-regulation/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/general-data-protection-regulation/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/general-data-protection-regulation/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/general-data-protection-regulation/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/general-data-protection-regulation/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. ## Key dates and moments for privacy programs *GDPR Timeline* Use the timeline to align your GDPR operating rhythm: DSAR SLAs, breach response, DPIA governance, and transfer safeguards. ## Does the GDPR apply to your processing *GDPR Decision Flow* Follow a structured path to clarify scope and role assumptions, then turn outcomes into prioritized obligations and evidence work. *Next step* ## Turn EU GDPR Compliance Hub into a cited research workflow EU GDPR Compliance Hub should be the shared entry point for your team. Route execution into Research Copilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU GDPR Compliance Hub and route the work by entity, product, team, or control owner. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs for EU GDPR Compliance Hub. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share the scope logic with your team. - **Download timeline**: Align your plan with key dates. - [Talk through EU GDPR Compliance Hub](/contact.md): Review your current process, evidence model, and next steps for EU GDPR Compliance Hub. ## Decision Steps ### STEP 1: Do you process personal data? *Reference: Art. 2(1) & Art. 4(1)-(2)* - Personal data = any information relating to an identified or identifiable natural person. - Processing = any operation performed on personal data (collection, recording, storage, use, disclosure, erasure, etc.). - If yes: check if GDPR applies to your processing activity. - If no: GDPR does not apply. - **NO** GDPR Does Not Apply - **YES** Is your processing within the material scope of GDPR? ### STEP 2: Is your processing within the material scope of GDPR? *Reference: Art. 2(1)-(2)* - GDPR applies to processing of personal data wholly or partly by automated means, or other processing that forms part of a filing system (Art. 2(1)). - GDPR does NOT apply to: processing outside the scope of Union law; Member State activities under TEU Title V Chapter 2 (CFSP); purely personal or household activities; processing for law enforcement purposes covered by LED (Directive (EU) 2016/680) (Art. 2(2)). - If excluded: GDPR does not apply to this specific processing activity. - **NO** GDPR Does Not Apply - **YES** Does GDPR apply to your processing based on territorial scope? ### STEP 3: Does GDPR apply to your processing based on territorial scope? *Reference: Art. 3* - GDPR applies if ANY of the following criteria are met: - 1. Establishment criterion (Art. 3(1)): processing in the context of activities of an establishment of controller or processor in the Union, regardless of where processing takes place. - 2. Targeting criterion (Art. 3(2)): processing of personal data of data subjects who are in the Union by a controller/processor not established in the Union, where activities relate to (a) offering goods/services to such data subjects in the Union, or (b) monitoring their behavior as far as it takes place within the Union. - 3. Public international law (Art. 3(3)): processing by a controller not established in the Union but in a place where Member State law applies by virtue of public international law. - If yes to any: GDPR applies. If no to all: GDPR does not apply. - **NO** GDPR Does Not Apply - **YES** Do you determine the purposes and means of processing (i.e., are you a controller)? ### STEP 4: Do you determine the purposes and means of processing (i.e., are you a controller)? *Reference: Art. 4(7)-(8)* - If yes: you are a controller (Art. 4(7)) and controller obligations apply. - If no: you may be a processor processing personal data on behalf of a controller (Art. 4(8)) - processor obligations apply. - Joint controllers (Art. 26): two or more controllers may jointly determine purposes and means; allocate responsibilities via an arrangement. - A single organization can be controller for some processing and processor for other processing. - **YES** You are a controller - GDPR applies to your processing - **NO** Are you not established in the Union and subject to GDPR under the targeting criterion (Art. 3(2))? ### CONTROLLER TRACK: You are a controller - GDPR applies to your processing *Reference: Art. 4(7)* - As controller, you determine the purposes and means of processing. - You must comply with all GDPR principles, lawful bases, data subject rights, controller obligations, security, breach notification, DPIA (if required), DPO (if required), and international transfer rules. - Proceed to determine your key obligations. - -> Do you have a lawful basis for processing? ### ART. 3(2) CHECK: Are you not established in the Union and subject to GDPR under the targeting criterion (Art. 3(2))? *Reference: Art. 3(2) & Art. 27* - This check determines whether you may need to designate an EU representative (Art. 27). - Answer yes only if: (1) you are not established in the Union, and (2) your processing relates to offering goods/services to data subjects who are in the Union or monitoring their behavior within the Union (Art. 3(2)). - **YES** If Art. 3(2) applies and you are not established in the Union, must you designate a representative in the Union? - **NO** GDPR Applies (Processor Obligations) ### ART. 27 (PROCESSOR): If Art. 3(2) applies and you are not established in the Union, must you designate a representative in the Union? *Reference: Art. 27* - Where Article 3(2) applies, the controller or the processor shall designate in writing a representative in the Union (Art. 27(1)). - Exceptions (Art. 27(2)): (a) occasional processing, unlikely to result in risk, not including special categories or criminal data on a large scale; (b) public authority or body. - Representative must be established in one of the Member States where data subjects are located whose personal data are processed in relation to offering goods/services to them, or whose behavior is monitored (Art. 27(3)). - Representative acts as contact point for supervisory authorities and data subjects on all issues related to processing (Art. 27(4)). - Designating a representative does not affect controller/processor liability (Art. 27(5)). - Provide the representative's identity and contact details to data subjects (Arts. 13-14). - **YES** GDPR Applies (Processor, designate EU representative) - **NO** GDPR Applies (Processor Obligations) ### STEP 5: Do you have a lawful basis for processing? *Reference: Art. 6(1)* - Processing is lawful only if at least one of the following applies (Art. 6(1)): - (a) Consent: data subject has given consent for specific purpose(s). - (b) Contract: processing necessary for performance of contract with data subject, or to take pre-contractual steps. - (c) Legal obligation: processing necessary for compliance with a legal obligation. - (d) Vital interests: processing necessary to protect vital interests of data subject or another person. - (e) Public task: processing necessary for performance of a task in the public interest or in exercise of official authority. - (f) Legitimate interests: processing necessary for purposes of legitimate interests of controller or third party (except where overridden by data subject's interests/rights, especially for children). Not available for public authorities in performance of their tasks. - You must identify and document your lawful basis before processing. - -> Do you process special categories of personal data? ### STEP 6: Do you process special categories of personal data? *Reference: Art. 9* - Special categories (Art. 9(1)): racial/ethnic origin, political opinions, religious/philosophical beliefs, trade union membership, genetic data, biometric data (for unique identification), health data, data concerning sex life or sexual orientation. - Processing special categories is PROHIBITED unless an Art. 9(2) exception applies (Art. 9(1)). - If you process special categories: you must identify an Art. 9(2) exception AND an Art. 6(1) lawful basis. - If you process data on criminal convictions/offences: Art. 10 applies (processing only under official authority control or when authorized by Union/Member State law). - -> Is a Data Protection Impact Assessment (DPIA) required? ### STEP 7: Is a Data Protection Impact Assessment (DPIA) required? *Reference: Art. 35* - DPIA required when processing is likely to result in high risk to rights/freedoms, in particular when using new technologies (Art. 35(1)). - DPIA always required for (Art. 35(3)): (a) systematic and extensive evaluation of personal aspects based on automated processing (including profiling) on which decisions are based that produce legal/similarly significant effects; (b) large-scale processing of special categories (Art. 9(1)) or criminal convictions/offences (Art. 10); (c) systematic monitoring of publicly accessible area on a large scale. - Supervisory authorities may publish lists of processing requiring DPIA (Art. 35(4)) and processing NOT requiring DPIA (Art. 35(5)). - If DPIA shows high risk in absence of mitigation measures: must consult supervisory authority before processing (Art. 36). - DPIA not required if: processing has legal basis in Union/Member State law regulating the specific operation and a DPIA was already done as part of general impact assessment (Art. 35(10)); or processing is on the supervisory authority's 'not required' list (Art. 35(5)). - -> Must you designate a Data Protection Officer (DPO)? ### STEP 8: Must you designate a Data Protection Officer (DPO)? *Reference: Art. 37* - DPO mandatory in the following cases (Art. 37(1)): - (a) Processing by public authority or body (except courts acting in judicial capacity). - (b) Core activities consist of processing operations which, by their nature/scope/purposes, require regular and systematic monitoring of data subjects on a large scale. - (c) Core activities consist of large-scale processing of special categories (Art. 9) or criminal convictions/offences (Art. 10). - In other cases, DPO designation is optional but may be required by Union or Member State law (Art. 37(4)). - A group of undertakings may appoint a single DPO if easily accessible from each establishment (Art. 37(2)). - If DPO not required: no obligation to designate, but you may do so voluntarily. - -> Do you transfer personal data to third countries or international organizations? ### STEP 9: Do you transfer personal data to third countries or international organizations? *Reference: Chapter V (Arts. 44-50)* - Chapter V applies to any transfer of personal data to a third country (outside EU/EEA) or international organization. - General principle (Art. 44): Level of protection must not be undermined. - Transfers permitted only if conditions in Chapter V are met. - Main transfer mechanisms: (1) Adequacy decision (Art. 45); (2) Appropriate safeguards (Art. 46); (3) Derogations for specific situations (Art. 49). - If you transfer to third countries: identify and implement appropriate transfer mechanism. - -> Are you not established in the Union and subject to GDPR under the targeting criterion (Art. 3(2))? ### ART. 3(2) CHECK: Are you not established in the Union and subject to GDPR under the targeting criterion (Art. 3(2))? *Reference: Art. 3(2) & Art. 27* - This check determines whether you may need to designate an EU representative (Art. 27). - Answer yes only if: (1) you are not established in the Union, and (2) your processing relates to offering goods/services to data subjects who are in the Union or monitoring their behavior within the Union (Art. 3(2)). - **YES** If Art. 3(2) applies and you are not established in the Union, must you designate a representative in the Union? - **NO** GDPR Applies (Controller) ### ART. 3(2) TRACK: If Art. 3(2) applies and you are not established in the Union, must you designate a representative in the Union? *Reference: Art. 27* - Where Article 3(2) applies, the controller or the processor shall designate in writing a representative in the Union (Art. 27(1)). - Exceptions (Art. 27(2)): (a) occasional processing, unlikely to result in risk, not including special categories or criminal data on large scale; (b) public authority or body. - Representative must be established in one of the Member States where data subjects are located whose personal data are processed in relation to offering goods/services to them, or whose behavior is monitored (Art. 27(3)). - Representative acts as contact point for supervisory authorities and data subjects on all GDPR-related issues (Art. 27(4)). - Designating a representative does not affect controller/processor liability or data subjects' rights (Art. 27(5)). - Provide representative's identity and contact details to data subjects (Arts. 13-14). - **YES** GDPR Applies (Designate EU Representative) - **NO** GDPR Applies (Controller) ## Reference Information ### What is Personal Data? - Personal data = any information relating to an identified or identifiable natural person ('data subject') (Art. 4(1)). - Examples: name, ID number, location data, online identifier, IP address, cookie identifier, biometric data, genetic data, health data, etc. - Special categories (Art. 9): racial/ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data (for unique identification), health data, sex life/sexual orientation. - Data on criminal convictions and offences (Art. 10) subject to special rules. ### Material Scope Exclusions - Processing outside Union law scope (Art. 2(2)(a)). - Member State activities under Common Foreign and Security Policy (TEU Title V Chapter 2) (Art. 2(2)(b)). - Purely personal or household activities (Art. 2(2)(c)). - Law enforcement processing (prevention, investigation, detection, prosecution of criminal offences; execution of criminal penalties; safeguarding against threats to public security) - covered by Law Enforcement Directive (EU) 2016/680 (Art. 2(2)(d)). - EU institutions/bodies: covered by Regulation (EC) No 45/2001 until adapted to GDPR (Art. 2(3) & Art. 98). ### Territorial Scope (Art. 3) Explained - Establishment criterion (Art. 3(1)): 'Establishment' = effective and real exercise of activity through stable arrangements in the EU (Recital 22). Legal form (branch, subsidiary) not determinative. Applies even if processing takes place outside EU. - Targeting criterion - offering goods/services (Art. 3(2)(a)): Mere website accessibility in the Union not sufficient. Look for: use of EU language/currency, mention of EU customers, intent to offer to data subjects who are in the Union (Recital 23). - Targeting criterion - monitoring behavior (Art. 3(2)(b)): Tracking/profiling to analyze or predict behavior (Recital 24). Examples: behavioral advertising, location tracking, health/fitness tracking. - If Art. 3(2) applies and you are not established in the Union: you must designate a representative in the Union (Art. 27), unless exempt. ### Lawful Bases for Processing - Consent (Art. 6(1)(a) & Art. 7): Must be freely given, specific, informed, unambiguous indication of wishes by statement or clear affirmative action. Must be as easy to withdraw as to give. Controller must be able to demonstrate consent. - Contract (Art. 6(1)(b)): Processing must be objectively necessary for contract performance or pre-contractual steps at data subject's request. - Legal obligation (Art. 6(1)(c)): Legal basis must be laid down in Union or Member State law (Art. 6(3)). - Vital interests (Art. 6(1)(d)): Only when no other lawful basis is available (typically life-or-death situations). - Public task (Art. 6(1)(e)): Legal basis laid down in Union or Member State law; purpose must be necessary for public interest or official authority (Art. 6(3)). - Legitimate interests (Art. 6(1)(f)): Requires balancing test - controller's legitimate interests vs. data subject's rights/interests. Document the balancing test. Not available for public authorities performing tasks. ### Special Categories - Art. 9(2) Exceptions - (a) Explicit consent (unless Union/MS law prohibits lifting the prohibition by consent). - (b) Employment, social security, social protection law (with appropriate safeguards). - (c) Vital interests (where data subject physically/legally incapable of giving consent). - (d) Legitimate activities of foundation/association/not-for-profit body with political/philosophical/religious/trade union aim (with appropriate safeguards; members/former members/regular contacts only; no disclosure without consent). - (e) Data manifestly made public by data subject. - (f) Legal claims or courts acting in judicial capacity. - (g) Substantial public interest (on basis of Union/MS law; proportionate; respects essence of right to data protection; suitable and specific safeguards). - (h) Preventive/occupational medicine, medical diagnosis, health/social care (on basis of Union/MS law or contract with health professional; subject to professional secrecy). - (i) Public health (on basis of Union/MS law; suitable and specific safeguards, including professional secrecy). - (j) Archiving/research/statistics (Art. 89(1); proportionate; respects essence; suitable and specific safeguards). - Member States may maintain/introduce further conditions or limitations for genetic, biometric, or health data (Art. 9(4)). ### GDPR Principles (Art. 5) - Lawfulness, fairness, transparency (Art. 5(1)(a)): Process lawfully, fairly, transparently. - Purpose limitation (Art. 5(1)(b)): Collect for specified, explicit, legitimate purposes; no incompatible further processing (except archiving/research/statistics under Art. 89(1)). - Data minimization (Art. 5(1)(c)): Adequate, relevant, limited to what is necessary. - Accuracy (Art. 5(1)(d)): Accurate and kept up to date; inaccurate data must be erased or rectified without delay. - Storage limitation (Art. 5(1)(e)): Keep only as long as necessary for purposes (except archiving/research/statistics under Art. 89(1) with appropriate safeguards). - Integrity and confidentiality (Art. 5(1)(f)): Ensure appropriate security (including protection against unauthorized/unlawful processing, accidental loss/destruction/damage). - Accountability (Art. 5(2)): Controller responsible for and must be able to demonstrate compliance with principles. ### Data Subject Rights (Chapter III) - Transparency & information (Arts. 12-14): Provide clear information at collection; respond to requests within 1 month (extendable by 2 months). - Right of access (Art. 15): Confirm if processing; provide copy of data and information on processing. - Right to rectification (Art. 16): Rectify inaccurate data; complete incomplete data. - Right to erasure / 'right to be forgotten' (Art. 17): Erase data in specific circumstances (no longer necessary; consent withdrawn; objection; unlawful processing; legal obligation; child's consent for information society services). Exceptions apply (e.g., freedom of expression, legal obligation, legal claims). - Right to restriction (Art. 18): Restrict processing in specific circumstances (accuracy contested; unlawful processing; no longer needed by controller but needed by data subject for legal claims; objection pending). - Right to data portability (Art. 20): Receive data in structured, machine-readable format and transmit to another controller (where processing based on consent or contract and carried out by automated means). - Right to object (Art. 21): Object to processing based on legitimate interests or public task (controller must stop unless compelling legitimate grounds override); absolute right to object to direct marketing. - Automated decision-making (Art. 22): Right not to be subject to decisions based solely on automated processing (including profiling) that produce legal/similarly significant effects, unless necessary for contract, authorized by law, or based on explicit consent (with safeguards). ### Controller Obligations (Chapter IV) - Responsibility & accountability (Art. 24): Implement appropriate measures to ensure and demonstrate GDPR compliance, taking into account nature/scope/context/purposes and risks. - Data protection by design & by default (Art. 25): Implement appropriate technical/organizational measures at design stage and at processing stage; by default, process only data necessary for each specific purpose. - Joint controllers (Art. 26): Determine respective responsibilities by transparent arrangement; designate point of contact for data subjects. - Representatives (Art. 27): Controllers/processors not established in the Union but subject to Art. 3(2) must designate a representative in the Union (unless: public authority/body; occasional processing; unlikely to result in risk; or special categories/criminal data). Representative acts as contact point. - Processor requirements (Art. 28): Use only processors with sufficient guarantees; written contract required (Art. 28(3) mandatory clauses); processor must not engage sub-processor without authorization. - Processing under authority (Art. 29): Processor and persons acting under controller/processor authority must process only on controller instructions (unless required by law). - Records of processing (Art. 30): Controllers and processors must maintain records of processing activities (exceptions for organizations <250 employees unless processing is not occasional, or involves special categories/criminal data, or likely to result in risk). Records must be available to supervisory authority on request. - Cooperation with supervisory authority (Art. 31): Cooperate on request. ### Security & Breach Notification (Arts. 32-34) - Security of processing (Art. 32): Implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk. Measures may include: pseudonymization; encryption; confidentiality/integrity/availability/resilience; ability to restore availability/access; regular testing/assessment. Take into account state of the art, costs, nature/scope/context/purposes, and risks. - Breach notification to supervisory authority (Art. 33): In case of personal data breach, notify supervisory authority without undue delay and where feasible within 72 hours of becoming aware, unless unlikely to result in risk to rights/freedoms. Processor must notify controller without undue delay. Notification must include: nature of breach, categories/approximate numbers affected, contact details of DPO (or point of contact), likely consequences, measures taken/proposed. Document all breaches. - Breach communication to data subject (Art. 34): If breach likely to result in high risk to rights/freedoms, communicate to data subject without undue delay in clear and plain language. Exceptions: if appropriate technical/organizational measures applied (e.g., encryption); controller has taken subsequent measures ensuring high risk no longer likely; communication would involve disproportionate effort (then public communication or similar effective measure). ### DPIA Contents & Process (Art. 35) - DPIA must contain at least (Art. 35(7)): (a) systematic description of processing operations and purposes (including legitimate interests if applicable); (b) assessment of necessity and proportionality of processing; (c) assessment of risks to rights/freedoms; (d) measures to address risks (safeguards, security, mechanisms to ensure protection and demonstrate compliance, taking into account rights/interests of data subjects and others). - Seek views of data subjects or their representatives where appropriate (Art. 35(9)). - Consult DPO if designated (Art. 35(2)). - Review DPIA at least when there is change of risk (Art. 35(11)). - Prior consultation with supervisory authority (Art. 36): If DPIA indicates high risk in absence of mitigation measures, consult supervisory authority before processing. Supervisory authority provides written advice within 8 weeks (extendable by 6 weeks). If supervisory authority finds processing would infringe GDPR, it may use its Art. 58 powers. ### DPO Requirements & Tasks (Arts. 37-39) - Designation (Art. 37): Based on professional qualities, expert knowledge of data protection law/practices, ability to fulfill tasks. May be staff member or external (service contract). Publish contact details and communicate to supervisory authority. - Position (Art. 38): Involve properly and timely in all data protection issues. Provide resources, access to data/processing operations, support to maintain expert knowledge. DPO must not receive instructions regarding tasks; must not be dismissed/penalized for performing tasks; reports directly to highest management. Data subjects may contact DPO. DPO bound by secrecy/confidentiality. May fulfill other tasks if no conflict of interest. - Tasks (Art. 39): (a) Inform and advise controller/processor and employees of obligations; (b) monitor compliance with GDPR and controller/processor policies (including assignment of responsibilities, awareness-raising, training, audits); (c) provide advice on DPIA and monitor performance; (d) cooperate with supervisory authority; (e) act as contact point for supervisory authority on processing issues (including prior consultation). DPO has due regard to risk (nature, scope, context, purposes). ### International Transfer Mechanisms (Chapter V) - Adequacy decision (Art. 45): Commission decides third country/territory/sector/international organization ensures adequate level of protection. No specific authorization required. Commission publishes list in OJ and on website. Examples: UK, Switzerland, Japan, Canada (commercial organizations), EU-US Data Privacy Framework participants (as of 2023 adequacy decision). - Appropriate safeguards (Art. 46): Legally binding instrument between public authorities; Binding Corporate Rules (BCRs); Standard Contractual Clauses (SCCs); approved code of conduct (with binding enforceable commitments); approved certification mechanism (with binding enforceable commitments); contractual clauses/administrative arrangements authorized by supervisory authority. Must provide enforceable data subject rights and effective legal remedies. Supplementary measures may be required (Schrems II principle). - Derogations (Art. 49): Only in absence of adequacy/safeguards and for specific situations: explicit consent (after being informed of risks); necessary for contract performance or pre-contractual measures; necessary for important public interest; necessary for legal claims; necessary to protect vital interests; transfer from public register; compelling legitimate interests (not repetitive; limited number of data subjects; supplementary safeguards; documented assessment; information to supervisory authority and data subject). - Note: Schrems II (CJEU C-311/18, July 2020) invalidated EU-US Privacy Shield and requires case-by-case assessment of third country law for transfers under Art. 46. ### Supervisory Authorities (Chapter VI) - Each Member State establishes independent supervisory authority (Art. 51-52). - Competence (Art. 55): Each supervisory authority is competent on its territory and for public authorities/bodies in its Member State. - Lead supervisory authority (Art. 56): For cross-border processing, the supervisory authority of the main establishment is the lead authority (one-stop-shop mechanism). - Tasks (Art. 57): Monitor and enforce GDPR; promote awareness; advise parliament/government/institutions; handle complaints; conduct investigations; authorize contractual clauses; issue opinions; report infringements; etc. - Powers (Art. 58): Investigative (e.g., order controller/processor to provide information, conduct audits); corrective (e.g., issue warnings/reprimands, order compliance, impose processing limitations, order erasure, impose administrative fines); authorization and advisory powers. - European Data Protection Board (EDPB) (Arts. 68-76): Independent EU body ensuring consistent GDPR application. Issues guidelines, recommendations, best practices. Composed of head of each Member State supervisory authority and EDPS. ### Remedies, Liability & Penalties (Chapter VIII) - Right to lodge complaint (Art. 77): Data subjects may lodge complaint with supervisory authority (in Member State of habitual residence, place of work, or place of alleged infringement). - Right to effective judicial remedy against supervisory authority (Art. 78): Against binding decisions or failure to handle complaint within 3 months. - Right to effective judicial remedy against controller or processor (Art. 79): Data subjects may bring court proceedings if they consider their rights infringed. - Representation (Art. 80): Data subjects may mandate not-for-profit bodies/organizations to lodge complaints, exercise rights, receive compensation on their behalf. Member States may allow such bodies to act independently of mandate. - Compensation & liability (Art. 82): Any person who suffered material or non-material damage due to GDPR infringement has right to compensation. Controllers and processors liable for damages. Each liable for entire damage (effective compensation). Exempt from liability if prove not in any way responsible. Can claim back from other controllers/processors involved their share of responsibility. - Administrative fines (Art. 83): Up to EUR 10M or 2% of total worldwide annual turnover (whichever higher) for certain infringements (e.g., processor obligations, DPO, certification body, monitoring body). Up to EUR 20M or 4% of turnover (whichever higher) for other infringements (e.g., principles, lawful basis, data subject rights, international transfers, supervisory authority orders). Fines must be effective, proportionate, dissuasive. Factors: nature/gravity/duration; intentional/negligent; mitigating actions; degree of responsibility; previous infringements; cooperation; categories of data; notification; adherence to codes/certification; other aggravating/mitigating factors. - Other penalties (Art. 84): Member States may lay down rules on other penalties (effective, proportionate, dissuasive). ### Consent Requirements (Art. 7) - Controller must be able to demonstrate data subject consented (Art. 7(1)). - If consent given in written declaration covering other matters, consent request must be clearly distinguishable, intelligible, easily accessible, clear and plain language. Infringing parts not binding (Art. 7(2)). - Data subject has right to withdraw consent at any time. Withdrawal does not affect lawfulness of processing before withdrawal. Must be as easy to withdraw as to give. Data subject must be informed of right to withdraw before giving consent (Art. 7(3)). - When assessing if consent is freely given, utmost account taken of whether contract performance (including service provision) is conditional on consent to processing not necessary for performance (Art. 7(4)). - Child's consent for information society services (Art. 8): If child below 16 years (Member States may lower to 13), consent must be given/authorized by holder of parental responsibility. Controller must make reasonable efforts to verify, taking into account available technology. ### Codes of Conduct & Certification (Arts. 40-43) - Codes of conduct (Art. 40): Voluntary; encourage drawing up by associations/bodies representing controllers/processors; can specify application of GDPR (e.g., fair/transparent processing, legitimate interests, collection, pseudonymization, information to public/data subjects, data subject rights, breach notification, transfers). Codes with general validity may provide appropriate safeguards for international transfers. Approved by supervisory authority (or Board for cross-border codes). Commission may give codes general EU validity. Adherence to code considered when assessing compliance. - Monitoring of codes (Art. 41): May be carried out by accredited bodies with appropriate expertise, independence, procedures, and no conflicts of interest. - Certification (Art. 42): Voluntary; mechanisms/seals/marks to demonstrate GDPR compliance. May provide appropriate safeguards for international transfers. Issued by certification bodies or supervisory authority for max 3 years (renewable). Withdrawal if criteria not met. Does not reduce controller/processor responsibility. Board maintains public register. - Certification bodies (Art. 43): Accredited by supervisory authority or national accreditation body (per Regulation (EC) No 765/2008 and EN-ISO/IEC 17065/2012). Must demonstrate independence, expertise, procedures, no conflicts of interest. Accreditation for max 5 years (renewable). Provide reasons for granting/withdrawing certification to supervisory authority. ### Binding Corporate Rules (BCRs) (Art. 47) - BCRs = personal data protection policies adhered to by controller/processor in EU for transfers within a group of undertakings/enterprises to controller/processor in third countries (Art. 4(20)). - BCRs are an appropriate safeguard for international transfers (Art. 46(2)(b)). - BCRs must be legally binding and enforced by all group members (Art. 47(1)). - Must expressly confer enforceable rights on data subjects (Art. 47(2)). - Minimum content (Art. 47(2)): structure/contact details of group; data transfers; legally binding nature; data protection principles; data subject rights; complaint/redress mechanisms; cooperation with supervisory authorities; mechanisms for ensuring compliance; liability; data protection training; monitoring mechanisms; update mechanisms; verification; etc. - Competent supervisory authority approves BCRs (Art. 47(1)). Consistency mechanism applies (Art. 63). - BCRs considered when imposing administrative fines (Art. 83(2)(j)). ### Records of Processing Activities (Art. 30) - Controllers must maintain records including: controller/representative/DPO contact details; purposes of processing; categories of data subjects and personal data; categories of recipients (including third countries/international organizations and safeguards); where applicable, transfers to third countries (including identification of country/international organization and documentation of safeguards); envisaged time limits for erasure; general description of technical and organizational security measures (Art. 30(1)). - Processors must maintain records including: processor/representative/DPO contact details; categories of processing carried out on behalf of each controller; where applicable, transfers to third countries (including identification and documentation of safeguards); general description of technical and organizational security measures (Art. 30(2)). - Records must be in writing (including electronic form) (Art. 30(3)). - Records must be made available to supervisory authority on request (Art. 30(4)). - Exception (Art. 30(5)): Obligations do not apply to organizations with <250 employees, UNLESS: processing is not occasional; OR processing likely to result in risk to rights/freedoms; OR processing includes special categories (Art. 9(1)) or criminal convictions/offences (Art. 10). ## Possible Outcomes ### [PROCESSOR] GDPR Applies (Processor Obligations) Process only on controller instructions - Processors must: process only on documented instructions from controller (Art. 28(3)(a)); ensure persons authorized to process are under confidentiality (Art. 28(3)(b)); implement appropriate security measures (Art. 28(3)(c) & Art. 32); respect sub-processor conditions (Art. 28(2)-(4)); assist controller with security, breach notification, DPIA, and data subject rights (Art. 28(3)(e)-(f)); delete or return data after services end (Art. 28(3)(g)); make available information to demonstrate compliance and allow audits (Art. 28(3)(h)). - Processor must have written contract or legal act with controller (Art. 28(3) & (9)). - Processor liable for damages if it fails to comply with processor-specific obligations or acts outside/contrary to lawful controller instructions (Art. 82(2)). ### [PROCESSOR] GDPR Applies (Processor, designate EU representative) Art. 3(2) and not established in the Union - You are subject to GDPR under the targeting criterion (Art. 3(2)) and are not established in the Union. - Designate a representative in the Union if required under Art. 27 (including considering Art. 27(2) exemptions). - Comply with all processor obligations under Art. 28 and other applicable GDPR requirements. ### [IN SCOPE] GDPR Applies (Controller) Comply with all controller obligations - Ensure lawful basis for all processing (Art. 6); additional lawful basis for special categories (Art. 9) if applicable. - Comply with all principles: lawfulness/fairness/transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity/confidentiality, accountability (Art. 5). - Respect data subject rights: transparency/information, access, rectification, erasure, restriction, data portability, objection, automated decision-making (Arts. 12-22). - Implement controller obligations: accountability, data protection by design/by default, records of processing, cooperation with supervisory authority (Arts. 24-31). - Ensure security and breach notification (Arts. 32-34). - Conduct DPIA if required (Art. 35); prior consultation if high risk (Art. 36). - Designate DPO if required (Arts. 37-39). - Comply with international transfer rules if transferring to third countries (Chapter V). - Designate representative in EU if required under Art. 27. - Be prepared for supervisory authority enforcement and potential administrative fines (up to EUR 20M or 4% of global turnover). ### [IN SCOPE] GDPR Applies (Designate EU Representative) Art. 3(2) and not established in the Union - You are subject to GDPR under the targeting criterion (Art. 3(2)) but not established in the Union. - Designate a representative in the Union (Art. 27(1) & (3)). Representative must be established in one of the Member States where relevant data subjects are located (Art. 27(3)). - Comply with all GDPR obligations as controller or processor (same as if established in the Union). - Representative acts as contact point for supervisory authorities and data subjects. - Provide representative's contact details in privacy notices (Arts. 13-14). - You remain fully responsible for compliance; representative designation does not affect your liability. ### [OUT OF SCOPE] GDPR Does Not Apply Outside GDPR scope - Your processing does not fall within GDPR scope (either material scope or territorial scope). - You are not required to comply with GDPR for this specific processing activity. - Note: You may still be subject to other data protection laws (e.g., national laws, Law Enforcement Directive (EU) 2016/680, or third country laws). - Reassess if circumstances change (e.g., if you start offering goods/services to data subjects who are in the Union or monitoring their behavior within the Union). ## GDPR Timeline | Date | Event | Reference | | --- | --- | --- | | 2016-04-27 | GDPR adopted by EU Parliament and Council | Reg. (EU) 2016/679 | | 2016-05-04 | GDPR published in Official Journal (OJ L 119) | Reg. (EU) 2016/679 | | 2016-05-24 | GDPR enters into force (20 days after publication) | Art. 99(1) | | 2018-05-25 | GDPR becomes applicable (replaces Directive 95/46/EC) | Art. 99(2) & Art. 94 | | 2020-05-25 | First Commission review report due (then every 4 years) | Art. 97 | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2015-10-06 | Schrems I press release (Safe Harbour invalidated) | CJEU Case Law | | | 2015-11-06 | Commission communication after Schrems I (data transfers EU-US) | International Transfers | | | 2016-02-29 | Commission communication on transatlantic data flows (Restoring Trust) | International Transfers | | | 2016-04-27 | GDPR adopted (date of Regulation) | Legislative History | | | 2016-05-04 | GDPR published (OJ L 119) | Legislative History | | | 2016-05-20 | EU-US Data Protection Umbrella Agreement published | International Transfers | | | 2016-05-24 | GDPR enters into force | Legislative History | | | 2016-07-12 | EU-US Privacy Shield adopted | International Transfers | | | 2016-12-01 | EU-US Data Protection Umbrella Agreement concluded | International Transfers | | | 2017-10-18 | First Privacy Shield review press release | International Transfers | | | 2017-12-01 | ENISA handbook on security of personal data processing (published) | EDPB Guidelines | | | 2018-02-01 | CNIL PIA methodology (February 2018 edition) | EDPB Guidelines | | | 2018-05-23 | GDPR corrigendum (OJ L 127) | Legislative History | | | 2018-05-25 | GDPR applies (application date) | Legislative History | | | 2018-05-25 | EDPB endorses WP29 documents (Endorsement 1/2018) | EDPB Guidelines | | | 2018-12-19 | Second Privacy Shield review press release | International Transfers | | | 2019-01-14 | EU-Japan adequacy decision factsheet | Adequacy Decisions | | | 2019-10-23 | Third Privacy Shield annual review report | International Transfers | | | 2020-05-04 | EDPB Guidelines 05/2020 on consent adopted | EDPB Guidelines | | | 2020-05-25 | First GDPR evaluation report due | Legislative History | | | 2020-07-16 | Schrems II press release (Privacy Shield invalidated) | CJEU Case Law | | | 2020-08-10 | EU-US joint press statement listed (data transfers) | International Transfers | | | 2021-06-04 | New Standard Contractual Clauses adopted | International Transfers | | | 2021-06-18 | EDPB Recommendations 01/2020 supplementary measures (Version 2.0) adopted | EDPB Guidelines | | | 2021-06-28 | UK adequacy decision (GDPR) adopted | Adequacy Decisions | | | 2021-07-07 | EDPB Guidelines 07/2020 on controller and processor (Version 2.0) adopted | EDPB Guidelines | | | 2021-09-27 | New SCCs required for new transfer agreements | International Transfers | | | 2021-12-17 | South Korea adequacy decision (17 December 2021) | Adequacy Decisions | | | 2022-10-07 | US Executive Order 14086 adopted | International Transfers | | | 2022-12-27 | Transition ends: old SCCs can no longer be relied upon | International Transfers | | | 2023-03-28 | EDPB Guidelines 01/2022 right of access (Version 2.0) adopted | EDPB Guidelines | | | 2023-03-28 | EDPB Guidelines 09/2022 on personal data breach notification (Version 2.0) adopted | EDPB Guidelines | | | 2023-04-01 | Irish DPC RoPA guidance note (April 2023) published | EDPB Guidelines | | | 2023-04-04 | Report on first periodic review of Japan adequacy decision | Adequacy Decisions | | | 2023-07-10 | EU-US Data Privacy Framework adequacy decision adopted | Adequacy Decisions | | | 2024-01-15 | Report on first review of 11 adequacy decisions (Directive 95/46/EC) | Adequacy Decisions | | | 2024-03-04 | First high-level meeting on safe data flows | Adequacy Decisions | | | 2024-07-18 | EU-US Data Privacy Framework review meeting starts (18-19 July 2024) | Adequacy Decisions | | | 2024-10-09 | First periodic review report of the EU-US Data Privacy Framework (DPF) dated | Adequacy Decisions | | | 2025-07-01 | European Patent Organisation adequacy decision (July 2025) | Adequacy Decisions | | | 2025-07-15 | UK adequacy decision (LED) renewal published | Adequacy Decisions | | | 2025-12-19 | UK adequacy decisions renewed (GDPR and LED) | Adequacy Decisions | | | 2026-02-10 | EU-Japan joint press statement listed (10 February 2026) | Adequacy Decisions | | **Event details:** - **2015-10-06 - Schrems I press release (Safe Harbour invalidated)**: CJEU press release (6 October 2015) on Case C-362/14 declaring the Safe Harbour Decision invalid. - **2015-11-06 - Commission communication after Schrems I (data transfers EU-US)**: Commission communication on the transfer of personal data from the EU to the US following the Schrems I judgment (listed on the Commission EU-US data transfers timeline). - **2016-02-29 - Commission communication on transatlantic data flows (Restoring Trust)**: Commission communication on transatlantic data flows and safeguards, published 29 February 2016 (listed on the Commission EU-US data transfers timeline). - **2016-04-27 - GDPR adopted (date of Regulation)**: Regulation (EU) 2016/679 is dated 27 April 2016. - **2016-05-04 - GDPR published (OJ L 119)**: Regulation (EU) 2016/679 published in the Official Journal (OJ L 119, 4.5.2016). - **2016-05-20 - EU-US Data Protection Umbrella Agreement published**: Publication date shown for the EU-US Data Protection Umbrella Agreement: 20 May 2016 (as shown on the Commission EU-US data transfers page timeline). - **2016-05-24 - GDPR enters into force**: GDPR enters into force (timeline reference date: 24 May 2016). - **2016-07-12 - EU-US Privacy Shield adopted**: EU-US Privacy Shield decision and annexes dated 12 July 2016. - **2016-12-01 - EU-US Data Protection Umbrella Agreement concluded**: EU-US Data Protection Umbrella Agreement concluded in December 2016 (Commission EU-US data transfers page timeline). - **2017-10-18 - First Privacy Shield review press release**: Press release on the first review of the EU-US Privacy Shield dated 18 October 2017. - **2017-12-01 - ENISA handbook on security of personal data processing (published)**: ENISA handbook on security of personal data processing, cover date December 2017. - **2018-02-01 - CNIL PIA methodology (February 2018 edition)**: CNIL Privacy Impact Assessment (PIA) methodology published (February 2018 edition). - **2018-05-23 - GDPR corrigendum (OJ L 127)**: Corrigendum published in OJ L 127, 23.5.2018, p. 2. - **2018-05-25 - GDPR applies (application date)**: GDPR applies from 25 May 2018; Directive 95/46/EC is repealed with effect from that date. - **2018-05-25 - EDPB endorses WP29 documents (Endorsement 1/2018)**: EDPB endorsement dated 25 May 2018 endorsing key Article 29 Working Party documents. - **2018-12-19 - Second Privacy Shield review press release**: Press release on the second review of the EU-US Privacy Shield dated 19 December 2018. - **2019-01-14 - EU-Japan adequacy decision factsheet**: EU Japan adequacy decision factsheet dated 14 January 2019 (as listed on the Commission adequacy decisions page timeline). - **2019-10-23 - Third Privacy Shield annual review report**: Report on the third annual review of the EU-US Privacy Shield dated 23 October 2019 (as listed on the Commission EU-US transfers page timeline). - **2020-05-04 - EDPB Guidelines 05/2020 on consent adopted**: EDPB Guidelines 05/2020 on consent under Regulation 2016/679 adopted on 4 May 2020. - **2020-05-25 - First GDPR evaluation report due**: Commission deadline to submit the first report on the evaluation and review of the GDPR by 25 May 2020, with subsequent reports every four years. - **2020-07-16 - Schrems II press release (Privacy Shield invalidated)**: CJEU press release dated 16 July 2020 on Case C-311/18 (Schrems II), invalidating the EU-US Privacy Shield. - **2020-08-10 - EU-US joint press statement listed (data transfers)**: Joint press statement by Commissioner Didier Reynders and U.S. Secretary of Commerce Wilbur Ross dated 10 August 2020 (listed on the Commission EU-US data transfers timeline). - **2021-06-04 - New Standard Contractual Clauses adopted**: European Commission adopts two sets of SCCs on 4 June 2021 (intra-EEA controller-processor and international transfers). - **2021-06-18 - EDPB Recommendations 01/2020 supplementary measures (Version 2.0) adopted**: EDPB adopted Recommendations 01/2020 on supplementary measures for international transfers (Version 2.0) on 18 June 2021. - **2021-06-28 - UK adequacy decision (GDPR) adopted**: Decision on the adequate protection of personal data by the United Kingdom under the GDPR dated 28 June 2021 (as listed on the Commission adequacy decisions page timeline). - **2021-07-07 - EDPB Guidelines 07/2020 on controller and processor (Version 2.0) adopted**: EDPB adopted Guidelines 07/2020 on the concepts of controller and processor (Version 2.0) on 7 July 2021. - **2021-09-27 - New SCCs required for new transfer agreements**: Agreements to transfer data concluded after 27 September 2021 must be based on the new SCCs. - **2021-12-17 - South Korea adequacy decision (17 December 2021)**: Decision on the adequate protection of personal data by the Republic of Korea dated 17 December 2021 (as listed on the Commission adequacy decisions page timeline). - **2022-10-07 - US Executive Order 14086 adopted**: Executive Order on "Enhancing Safeguards for United States Signals Intelligence Activities" adopted on 7 October 2022 (as referenced on the Commission EU-US transfers page timeline). - **2022-12-27 - Transition ends: old SCCs can no longer be relied upon**: Transition period ends on 27 December 2022 for switching to the new SCCs for agreements entered into before 27 September 2021. - **2023-03-28 - EDPB Guidelines 01/2022 right of access (Version 2.0) adopted**: EDPB adopted Guidelines 01/2022 on data subject rights (right of access) (Version 2.0) on 28 March 2023. - **2023-03-28 - EDPB Guidelines 09/2022 on personal data breach notification (Version 2.0) adopted**: EDPB adopted Guidelines 09/2022 on personal data breach notification under the GDPR (Version 2.0) on 28 March 2023. - **2023-04-01 - Irish DPC RoPA guidance note (April 2023) published**: Irish Data Protection Commission guidance note on Records of Processing Activities (RoPA), cover date April 2023. - **2023-04-04 - Report on first periodic review of Japan adequacy decision**: Commission publishes its report on the first periodic review of the adequacy decision for Japan on 4 April 2023 (as listed on the Commission adequacy decisions page timeline). - **2023-07-10 - EU-US Data Privacy Framework adequacy decision adopted**: Commission adopts its adequacy decision for the EU-US Data Privacy Framework on 10 July 2023 (as listed on the Commission EU-US transfers page timeline). - **2024-01-15 - Report on first review of 11 adequacy decisions (Directive 95/46/EC)**: Commission publishes its report on the first review of the functioning of the eleven adequacy decisions adopted pursuant to Directive 95/46/EC, on 15 January 2024. - **2024-03-04 - First high-level meeting on safe data flows**: Commission hosts the first ever high-level meeting on safe data flows on 4 March 2024. - **2024-07-18 - EU-US Data Privacy Framework review meeting starts (18-19 July 2024)**: First day of the DPF review meeting in Washington D.C. (18-19 July 2024), as referenced in the Commission's first periodic review report timeline section. - **2024-10-09 - First periodic review report of the EU-US Data Privacy Framework (DPF) dated**: Commission report dated Brussels, 9.10.2024 (publication date shown at top of the report). - **2025-07-01 - European Patent Organisation adequacy decision (July 2025)**: European Patent Organisation adequacy decision listed for July 2025 on the Commission adequacy decisions page timeline (month provided, exact day not specified). - **2025-07-15 - UK adequacy decision (LED) renewal published**: Publication date for renewal of the EU adequacy decision for the UK under the Law Enforcement Directive (LED): 15 July 2025 (as listed on the Commission adequacy decisions page timeline). - **2025-12-19 - UK adequacy decisions renewed (GDPR and LED)**: Publication date for renewal of EU adequacy decisions for the UK under the GDPR and under the LED: 19 December 2025 (as listed on the Commission adequacy decisions page timeline). - **2026-02-10 - EU-Japan joint press statement listed (10 February 2026)**: Joint press statement by Commissioner Michael McGrath and TEZUKA Satoru (Japan PIPC) listed under "Adequacy decisions latest" dated 10 February 2026 (as extracted from the Commission adequacy decisions page timeline). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/general-data-protection-regulation --- --- title: "EU General Product Safety Regulation (GPSR) (Regulation (EU) 2023/988) Compliance Hub" canonical_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation" source_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation" author: "Sorena AI" description: "A practical EU GPSR compliance hub for Regulation (EU) 2023/988: confirm scope and covered products." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU GPSR compliance" - "General Product Safety Regulation" - "Regulation (EU) 2023/988" - "product safety compliance EU" - "Safety Gate notification" - "Safety Business Gateway" - "product recall notice template" - "recall readiness playbook" - "online marketplace obligations GPSR" - "economic operator duties manufacturer importer distributor" - "product safety documentation and traceability" - "GPSR" - "product safety" - "Safety Gate" - "recalls" - "online marketplaces" - "economic operators" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU General Product Safety Regulation (GPSR) (Regulation (EU) 2023/988) Compliance Hub A practical EU GPSR compliance hub for Regulation (EU) 2023/988: confirm scope and covered products. ![EU GPSR artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-gpsr-timeline-small.jpg?v=cheatsheets%2Fprod) *GPSR* *Free Resource* ## EU GPSR Compliance Hub Turn Regulation (EU) 2023/988 into deliverables: scope your covered products, map economic operator duties, build documentation and traceability, and operationalize Safety Gate notifications and recall readiness. This is a practical reference, not legal advice. Product safety expectations can vary by product category and Member State practice-validate against your product risk profile and applicable guidance. [Start with the checklist](/artifacts/eu/general-product-safety-regulation/checklist.md) ## What you can decide faster - **Is it covered**: Covered products, exclusions, and how GPSR interacts with sector-specific EU rules. - **Who owns duties**: Manufacturer, importer, distributor, fulfilment service provider, and online marketplace roles. - **What to prepare**: Risk assessment, documentation/traceability, Safety Gate notifications, and recall playbooks. By Sorena AI | Updated Mar 2026 | No signup required ### Quick scan *GPSR* - **Scope**: Confirm covered products and exclusions for your channels. - **Duties**: Assign owners for economic operator obligations and controls. - **Recall readiness**: Prepare corrective action workflows and recall notice templates. Use the decision flow to align product, legal, and operations teams on scope and roles, then implement the subpages to build audit-ready evidence. | Value | Metric | | --- | --- | | 2023 | Regulation | | 2024 | Applies | | EU | Market | | Safety Gate | Portal | | Recall | Readiness | **Key highlights:** Economic operator duties | Safety Gate reporting | Recall readiness ## Topic Guides - [EU GPSR Applicability Test | Is Regulation (EU) 2023/988 Applicable to Your Product, Channel, and Role?](/artifacts/eu/general-product-safety-regulation/applicability-test.md): A step-by-step EU GPSR applicability test for Regulation (EU) 2023/988: confirm whether your products are covered, whether exclusions apply. - [EU GPSR Checklist | Audit-Ready Compliance Checklist for Regulation (EU) 2023/988 (Safety Gate, Recalls, Marketplaces, Evidence)](/artifacts/eu/general-product-safety-regulation/checklist.md): An audit-ready EU GPSR checklist for Regulation (EU) 2023/988: scope and role mapping, documentation and traceability, supplier evidence. - [EU GPSR Compliance Program | Operating Model, Governance, Controls, and Evidence for Regulation (EU) 2023/988](/artifacts/eu/general-product-safety-regulation/compliance.md): A practical EU GPSR compliance playbook for Regulation (EU) 2023/988: program setup, governance cadence, risk assessment controls. - [EU GPSR Deadlines and Compliance Calendar | Key Dates, Workstreams, and Operational Milestones (Safety Gate, Recalls, Marketplaces)](/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar.md): A practical EU GPSR calendar for Regulation (EU) 2023/988: key dates and operational milestones, with a workstream-based plan covering scope and role mapping. - [EU GPSR Economic Operator Duties | Manufacturer vs Importer vs Distributor vs Fulfilment vs Marketplace Roles + Evidence](/artifacts/eu/general-product-safety-regulation/economic-operator-duties.md): A practical guide to EU GPSR economic operator duties under Regulation (EU) 2023/988: how to map roles across your supply chain. - [EU GPSR FAQ | Common Questions About Regulation (EU) 2023/988 (Scope, Online Marketplaces, Safety Gate, Recalls)](/artifacts/eu/general-product-safety-regulation/faq.md): Answers to common EU GPSR questions: scope and exclusions, used/repaired products, online marketplaces, Safety Gate/Safety Business Gateway notifications. - [EU GPSR Online Marketplace Obligations | Safety Gate Interface (2024/1459), Unsafe Product Removal, Notices, and Evidence](/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations.md): A practical guide for online marketplaces under EU GPSR (Regulation (EU) 2023/988): who is a 'provider of an online marketplace'. - [EU GPSR Penalties and Enforcement | Market Surveillance, Corrective Actions, and How to Reduce Risk With Evidence](/artifacts/eu/general-product-safety-regulation/penalties-and-fines.md): A practical guide to enforcement under EU GPSR (Regulation (EU) 2023/988): how market surveillance works, what enforcement actions look like (restrictions. - [EU GPSR Product Recall Notice Template | How to Use Implementing Regulation (EU) 2024/1435 (Article 36)](/artifacts/eu/general-product-safety-regulation/product-recall-notice-template.md): A practical guide to the EU GPSR recall notice template: when it applies, how to fill it correctly, what evidence to retain. - [EU GPSR Recalls and Incident Management | Corrective Actions, Safety Gate Notifications, Recall Effectiveness, Playbooks](/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management.md): A practical recall and incident management playbook for EU GPSR (Regulation (EU) 2023/988): build a triage workflow, decide corrective actions vs recall. - [EU GPSR Requirements (Regulation (EU) 2023/988) | Obligations, Controls, Safety Gate Notifications, and Evidence](/artifacts/eu/general-product-safety-regulation/requirements.md): An implementation-grade breakdown of EU GPSR requirements under Regulation (EU) 2023/988: safe product lifecycle controls, risk assessment. - [EU GPSR Scope and Covered Products | What's In/Out, Overlap With Sector Rules, Online Sales, Used/Reconditioned Goods](/artifacts/eu/general-product-safety-regulation/scope-and-covered-products.md): A practical GPSR scope guide for Regulation (EU) 2023/988: what products are covered, common exclusions. - [EU GPSR Traceability and Documentation | Product Safety Evidence Packs, Supplier Data, and Audit-Ready Records](/artifacts/eu/general-product-safety-regulation/traceability-and-documentation.md): A practical GPSR documentation and traceability guide for Regulation (EU) 2023/988: what information to maintain. - [GPSR vs Market Surveillance Regulation (EU) 2019/1020 | What's Different, What Overlaps, and What to Build](/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Market Surveillance Regulation (EU) 2019/1020: what each governs. - [GPSR vs Product Liability Directive (85/374/EEC) | Safety Obligations vs Liability Risk, Recalls, Evidence, and Claims Readiness](/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Product Liability Directive (85/374/EEC). ## Key dates and operational moments for product safety programs *GPSR Timeline* Use the timeline to align scope rollout, documentation readiness, online marketplace processes, and Safety Gate notification playbooks. ## Does the GPSR apply to your products *GPSR Decision Flow* Follow a structured path to clarify covered products, roles, and notification/recall obligations-then turn outcomes into a prioritized plan and evidence pack. *Next step* ## Turn EU GPSR Compliance Hub into an operational assessment workflow EU GPSR Compliance Hub should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU GPSR Compliance Hub and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for EU GPSR Compliance Hub. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share the scope and role logic with your team. - **Download timeline**: Align milestones across product, ops, and legal. - [Talk through EU GPSR Compliance Hub](/contact.md): Review your current process, evidence model, and next steps for EU GPSR Compliance Hub. ## Decision Steps ### STEP 1: Is your item a product made available on the Union market for consumers (including online offers directed to consumers in the Union)? *Reference: Art. 2, Art. 3(1), Art. 3(6)-(7) & Art. 4* - GPSR applies to products placed on or made available on the Union market (including by distance selling) where there are no specific Union safety rules for the product, or only for aspects and risks not covered by those rules (Art. 2(1)). - It covers new, used, repaired and reconditioned products (Art. 2(3)). - 'Product' includes items supplied for consideration or free of charge (including in the context of a service) that are intended for consumers or are likely to be used by consumers under reasonably foreseeable conditions (Art. 3(1)). - For online and other distance sales, a product is considered made available on the market when the offer is directed to consumers in the Union (Art. 4). - Next: confirm whether the product is excluded under Art. 2(2). - **NO** GPSR Does Not Apply - **YES** Is your product excluded under Article 2(2)? ### STEP 2: Is your product excluded under Article 2(2)? *Reference: Art. 2(2)* - If yes, GPSR does not apply. - If no, continue to determine your role as an economic operator. - **YES** Out of Scope - **NO** What is your role in the supply chain? ### STEP 3: What is your role in the supply chain? - Manufacturer (Art. 3(8)): manufactures a product (or has it designed/manufactured) and markets it under its name or trademark. - Authorised representative (Art. 3(9)): established in the Union and mandated in writing by the manufacturer to perform specific tasks. - Importer (Art. 3(10)): established in the Union and places a product from a third country on the Union market. - Distributor (Art. 3(11)): makes a product available on the market (other than manufacturer or importer). - Fulfilment service provider (Art. 3(12)): offers at least two services (warehousing, packaging, addressing, dispatching) for products it does not own. - Provider of an online marketplace (Art. 3(14)): intermediary service using an online interface that allows consumers to conclude distance contracts with traders for the sale of products. - Economic operator is defined broadly and includes the above roles (Art. 3(13)). - -> Are you the manufacturer (or treated as the manufacturer because you market under your name/trademark or substantially modify a product affecting safety)? ### STEP 4: Are you the manufacturer (or treated as the manufacturer because you market under your name/trademark or substantially modify a product affecting safety)? *Reference: Art. 3(8) & Art. 13; obligations: Art. 9* - Manufacturer means any natural or legal person who manufactures a product (or has it designed/manufactured) and markets it under its name or trademark (Art. 3(8)). - You are also treated as the manufacturer if you place a product on the market under your name/trademark, or if you substantially modify a product in a way that affects its safety (Art. 13). - If yes: manufacturer obligations apply (Art. 9). If no: continue to check other roles. - **YES** Manufacturer Obligations Apply - **NO** Are you an authorised representative established in the Union and mandated in writing by a manufacturer? ### STEP 5: Are you an authorised representative established in the Union and mandated in writing by a manufacturer? *Reference: Art. 3(9) & Art. 10* - An authorised representative is a natural or legal person established in the Union with a written mandate from the manufacturer to perform specific tasks (Art. 3(9)). - If yes: authorised representative obligations apply (Art. 10). If no: continue to check other roles. - **YES** Authorised Representative Obligations Apply - **NO** Are you an importer placing products from third countries on the EU market? ### STEP 6: Are you an importer placing products from third countries on the EU market? *Reference: Art. 3(10) & Art. 11* - Importer means any natural or legal person established in the Union who places a product from a third country on the Union market (Art. 3(10)). - If yes: importer obligations apply (Art. 11). If no: continue to check other roles. - **YES** Importer Obligations Apply - **NO** Are you a distributor making products available on the market? ### STEP 7: Are you a distributor making products available on the market? *Reference: Art. 3(11) & Art. 12* - Distributor means any natural or legal person in the supply chain, other than the manufacturer or the importer, who makes a product available on the market (Art. 3(11)). - If yes: distributor obligations apply (Art. 12). If no: continue to check other roles. - **YES** Distributor Obligations Apply - **NO** Are you a fulfilment service provider? ### STEP 8: Are you a fulfilment service provider? *Reference: Art. 3(12), Art. 14-16 (as applicable)* - A fulfilment service provider offers at least two services (warehousing, packaging, addressing, dispatching) for products it does not own (Art. 3(12)). - Fulfilment service providers are economic operators and must have internal product safety procedures and cooperate with authorities (Art. 14-15). - If yes: fulfilment service provider obligations apply (see outcome). If no: continue to check online marketplace role. - **YES** Fulfilment Service Provider Obligations Apply - **NO** Are you a provider of an online marketplace? ### STEP 9: Are you a provider of an online marketplace? *Reference: Art. 3(14) & Art. 22* - A provider of an online marketplace is a provider of an intermediary service using an online interface that allows consumers to conclude distance contracts with traders for the sale of products (Art. 3(14)). - If yes: online marketplace obligations apply (Art. 22). If no: GPSR may still apply to you as another economic operator depending on your activities. - **YES** Online Marketplace Obligations Apply - **NO** GPSR Does Not Apply ## Reference Information ### Product Scope (Overview) - GPSR applies to products placed on or made available on the Union market where there are no specific Union safety rules for the product, or only for aspects and risks not covered by those rules (Art. 2(1)). - It covers new, used, repaired and reconditioned products (Art. 2(3)). - For online and other distance sales, a product is considered made available on the market when the offer is directed to consumers in the Union (Art. 4). - If a product is subject to Union harmonisation legislation with specific safety requirements, GPSR applies only to the aspects and risks not covered by those requirements (Art. 2(1)). ### Key Exclusions - Art. 2(2) exclusions include: medicinal products; food; feed; living plants and animals (including certain GMOs); animal by-products; plant protection products; certain transport means operated by a service provider; certain low-risk aircraft; and antiques. - GPSR does not apply to products that must be repaired or reconditioned prior to use when they are placed on the market as such and are clearly marked as such (Art. 2(3)). - If a product is subject to Union harmonisation legislation with specific safety requirements, GPSR applies only to aspects and risks not covered by those requirements (Art. 2(1)). ### General Safety Requirement - Economic operators may place on the market or make available on the market only safe products (Art. 5). - A safe product is a product that, under normal or reasonably foreseeable conditions of use, does not present any risk or only minimal risks that are acceptable and consistent with a high level of protection of consumers' health and safety (Art. 3(2)). - Key factors for assessing product safety include product characteristics, presentation and labeling (including warnings and instructions), user categories (especially vulnerable consumers), foreseeable interaction with other products, cybersecurity features, and evolving/learning functions where relevant (Art. 6(1)). ### Risk Assessment - Before placing products on the market, manufacturers must carry out an internal risk analysis and draw up technical documentation (Art. 9(2)). - Product safety assessment considers, among other factors, characteristics, labeling and warnings, foreseeable use and user categories, and (where relevant) cybersecurity and evolving or learning functions (Art. 6(1)). - The Safety Gate framework includes a risk assessment methodology (Delegated Reg. (EU) 2024/3173, Annex II) and supporting tools such as SAGA (Safety Gate risk Assessment). - Serious risk means a risk that, based on a risk assessment, requires rapid intervention by market surveillance authorities (Art. 3(5)). - A dangerous product is a product that is not a safe product (Art. 3(3)). ### Traceability Requirements - Manufacturer identification and product identification elements (e.g., type, batch or serial number) must be provided as required (Art. 9(5)-(6)). - Importer identification and contact details must be provided as required (Art. 11(3)). - If a product requires a responsible person in the Union, that economic operator's name and contact details must be provided as required (Art. 16(3)). - Economic operators must be able to identify their suppliers and customers and provide traceability information to authorities for required periods (Art. 15(3)-(5)). - For distance sales, product offers must include required manufacturer/responsible person information, product identifiers, and warnings/safety information (Art. 19). ### Recall and Corrective Actions - If a manufacturer considers or has reason to believe a product it placed on the market is dangerous, it must take corrective action (including withdrawal or recall), inform consumers, and notify authorities via the Safety Business Gateway (Art. 9(8)). - Importers and distributors have corresponding duties to take action and ensure consumers and authorities are informed when they identify dangerous products (Art. 11(8) and Art. 12(4)). - In case of a product safety recall or a safety warning, economic operators and online marketplace providers must directly inform affected consumers where they can be identified, and otherwise use appropriate channels to maximize reach (Art. 35). - Written recall communication must follow the recall notice requirements, including the heading 'Product safety recall', product identification, risk description, consumer actions, remedies, and contact channels (Art. 36). The Commission sets a template via implementing acts (Implementing Reg. (EU) 2024/1435). - Consumers must be offered effective, cost-free and timely remedies (repair, replacement, or refund), with at least two options where possible (Art. 37). ### Online Marketplace Specific Obligations - Designate contact points for authorities and consumers and register the authority contact point with the Safety Gate Portal (Art. 22(1)-(2)). - Maintain internal procedures to comply with GPSR requirements without undue delay (Art. 22(3)). - Comply with authority orders to remove/disable access to content relating to offers of dangerous products, typically within two working days, and notify the authority of compliance (Art. 22(4)-(5)). - Ensure listings include required manufacturer and responsible person information, product identifiers, and warnings/safety information (Art. 22(9)-(10)). - Support recalls and safety warnings (including directly informing affected consumers where possible) and notify authorities via the Safety Business Gateway when you have actual knowledge of dangerous products offered on your marketplace (Art. 22(12)(a)-(d)). - The Safety Gate Portal includes an interoperable interface for online marketplaces; implementing rules are set by Implementing Reg. (EU) 2024/1459 (Art. 34(5)-(6)). ### Safety Gate (RAPEX) Notification - The Commission develops and maintains the Safety Gate Rapid Alert System for exchanging information on corrective measures related to dangerous products (Art. 25). - Member States notify corrective measures via Safety Gate, including measures related to products presenting a serious risk (Art. 26). - Implementing Reg. (EU) 2024/2639 sets the roles and tasks of the national contact points for Safety Gate (Art. 25(2)). - Delegated Reg. (EU) 2024/3173 supplements the GPSR with detailed rules on access to and operation of the Safety Gate system and related requirements. - Commission Implementing Decision (EU) 2019/417 (RAPEX guidelines) is described as obsolete and replaced in Commission Q&A materials. ### Market Surveillance - Market surveillance for products covered by GPSR is carried out under the EU market surveillance framework (Reg. (EU) 2019/1020), as applied by Art. 23 GPSR. - Member States must report on the application of the GPSR, and the Commission publishes an annual summary report. The output indicators are set via implementing acts (Art. 24; Implementing Reg. (EU) 2024/2958). - Selected information on dangerous products and measures is made publicly available via the Safety Gate Portal (Art. 33(1) and Art. 34). - Consumers and other parties can inform the Commission about products that may present a risk via the Safety Gate Portal; modalities are set via implementing acts (Art. 34(3)-(4); Implementing Reg. (EU) 2024/1740). ### Penalties and Enforcement - Member States must lay down rules on sanctions for infringements of GPSR obligations and take measures to ensure they are implemented (Art. 44(1)). - Sanctions must be effective, proportionate and dissuasive (Art. 44(2)). - Member States must notify the Commission of their sanctions rules and measures by 13 December 2024 (Art. 44(3)). - The Commission must evaluate the implementation of the sanctions article by 13 December 2029 (Art. 47(5)). ### Responsible Person in EU - A product covered by GPSR may not be placed on the market unless there is an economic operator established in the Union responsible for the tasks referenced in the market surveillance framework (Art. 16(1) and Reg. (EU) 2019/1020 Art. 4(3)). - The responsible economic operator must, where appropriate, carry out regular checks related to technical documentation and identification and safety information requirements (Art. 16(2)). - The responsible economic operator's name and contact details (including postal address and electronic address) must be provided on the product, its packaging, the parcel, or an accompanying document (Art. 16(3)). ### Standards and Presumption of Conformity - Products are presumed to comply with the general safety requirement where they comply with applicable European standards (or parts of standards) covering the relevant risks, or (in absence of such standards) with certain national requirements (Art. 7(1)). - The Commission can adopt implementing acts to set specific safety requirements to be covered by European standards (Art. 7(2)). - Where presumption does not apply, additional elements can be considered for the safety assessment, such as other standards, international standards, and Commission guidance (Art. 8). ### Technical Documentation and Record-Keeping - Manufacturers must draw up technical documentation that includes at least a general product description and essential safety-relevant characteristics, and keep it available for 10 years after placing the product on the market (Art. 9(2)-(3)). - Technical documentation can include (as appropriate): risk analysis, test reports, and the standards or other elements used to meet the general safety requirement (Art. 9(2)). - Importers must keep a copy of the technical documentation for 10 years and provide it to authorities on request (Art. 11(6)). ### Consumer Information and Reporting - Consumers and other parties can inform the Commission about products that may present a risk via a dedicated section of the Safety Gate Portal, and the Commission can transmit verified information to Member States for follow up (Art. 34(3)). - The Commission sets the modalities for consumer information submissions and transmission to national authorities via implementing acts (Art. 34(4); Implementing Reg. (EU) 2024/1740). - Consumers can also submit complaints to competent national authorities about product safety, surveillance activities, and inadequate recall remedies, and authorities should follow up appropriately (Art. 33(4)). - In case of recalls and safety warnings, economic operators and online marketplace providers must inform affected consumers where possible and otherwise use appropriate channels to maximize reach (Art. 35). ### Authorised Representative - An authorised representative is a natural or legal person established in the Union with a written mandate from the manufacturer to perform specific tasks under the Regulation (Art. 3(9)). - The written mandate defines the tasks performed and must be made available to market surveillance authorities on request (Art. 10). - Authorised representatives can be part of the economic operator chain and may also serve as the responsible economic operator in the Union where applicable (Art. 16). ### Cybersecurity and AI Features - Product safety assessment considers cybersecurity features where required by the nature of the product, including protection from external influences (including malicious third parties) where such influence could affect product safety (Art. 6(1)(g)). - Where relevant, safety assessment also considers evolving, learning and predictive functions of a product (Art. 6(1)(h)). ### Key Implementing and Delegated Regulations - Implementing Reg. (EU) 2024/1435: recall notice template (Art. 36(3)). - Implementing Reg. (EU) 2024/1459: Safety Gate Portal interoperable interface rules for online marketplaces (Art. 34(5)-(6)). - Implementing Reg. (EU) 2024/1740: consumer information submission modalities via Safety Gate Portal (Art. 34(4)). - Implementing Reg. (EU) 2024/2639: roles and tasks of national Safety Gate contact points (Art. 25(2)). - Implementing Reg. (EU) 2024/2958: output indicators for Member State reporting (Art. 24(2)). - Delegated Reg. (EU) 2024/3173: rules on access to and operation of Safety Gate and related requirements. ## Possible Outcomes ### [RESULT] Authorised Representative Obligations Apply Art. 10 - Have a written mandate from the manufacturer defining the tasks you perform, and provide a copy to market surveillance authorities on request (Art. 10(1)-(2)). - On reasoned request from a market surveillance authority, provide the information and documentation necessary to demonstrate product safety (Art. 10(2)(a)). - If you consider or have reason to believe a product is dangerous, inform the manufacturer (Art. 10(2)(b)). - Notify competent national authorities of measures taken to eliminate risks via the Safety Business Gateway when required and not already done by the manufacturer (Art. 10(2)(c)). - Cooperate with competent authorities on measures to eliminate risks effectively (Art. 10(2)(d)). ### [RESULT] Manufacturer Obligations Apply Art. 9 - Ensure products are designed and manufactured in line with the general safety requirement (Art. 9(1) and Art. 5). - Before placing products on the market, carry out an internal risk analysis and draw up technical documentation (Art. 9(2)). Keep it up to date and available to market surveillance authorities for 10 years (Art. 9(3)). - Ensure product identification and traceability information is provided (e.g., type, batch or serial number; manufacturer name and contact details) and provide required instructions and safety information in the relevant language(s) (Art. 9(5)-(7)). - If you consider or have reason to believe a product is dangerous, take corrective action (including withdrawal/recall), inform consumers, and notify authorities via the Safety Business Gateway (Art. 9(8)). - Maintain channels for consumer complaints and accident reporting, and keep an internal register of complaints, recalls and corrective actions (Art. 9(11)-(12)). ### [RESULT] Importer Obligations Apply Art. 11 - Before placing a product on the market, ensure it complies with the general safety requirement and that the manufacturer has met key requirements (Art. 11(1)). - Do not place a product on the market if you consider or have reason to believe it is not compliant; if it is dangerous, inform the manufacturer and notify authorities via the Safety Business Gateway (Art. 11(2)). - Indicate importer identification and contact details on the product or its packaging/accompanying document, and ensure instructions and safety information in the relevant language(s) (Art. 11(3)-(4)). - Ensure storage and transport conditions do not jeopardize compliance (Art. 11(5)). - Keep a copy of the technical documentation for 10 years and provide it to authorities on request (Art. 11(6)). - If you consider or have reason to believe a product you placed on the market is dangerous, ensure corrective action, consumer notification, and authority notification via the Safety Business Gateway (Art. 11(8)). ### [RESULT] Distributor Obligations Apply Art. 12 - Before making a product available, verify that required identification, manufacturer/importer contact details, and safety information are present (Art. 12(1)). - Ensure storage and transport conditions do not jeopardize compliance (Art. 12(2)). - Do not make a product available if you consider or have reason to believe it is not compliant, unless compliance is restored (Art. 12(3)). - If you consider or have reason to believe a product you made available is dangerous, inform the manufacturer or importer, ensure corrective action, and ensure authorities are notified via the Safety Business Gateway (Art. 12(4)). ### [RESULT] Fulfilment Service Provider Obligations Apply Art. 14-16 (as applicable) - Maintain internal procedures to ensure product safety compliance as an economic operator (Art. 14). - Cooperate with market surveillance authorities and provide information needed to eliminate or mitigate risks (Art. 15(1)-(2)). - Maintain and provide traceability information on suppliers and customers for required periods (Art. 15(3)-(5)). - If you are the economic operator responsible for the product in the Union, ensure you meet the responsible person requirements and that your contact details are provided as required (Art. 16(1)-(3)). ### [RESULT] Online Marketplace Obligations Apply Art. 22 - Designate contact points for market surveillance authorities and for consumers, and register the authority contact point with the Safety Gate Portal (Art. 22(1)-(2)). - Maintain internal procedures to meet the requirements of the GPSR without undue delay (Art. 22(3)). - Comply with authority orders to remove/disable access to content relating to offers of dangerous products, typically within two working days, and notify the authority of compliance (Art. 22(4)-(5)). - Ensure product listings include the required information for consumers (including manufacturer and, where applicable, the responsible person in the Union, plus product identifiers and warnings) (Art. 22(9)-(10)). - Support recalls and safety warnings and notify authorities via the Safety Business Gateway when you have actual knowledge of dangerous products offered on your marketplace (Art. 22(12)(a)-(d)). - Cooperate with authorities and other economic operators on measures to eliminate or mitigate risks (Art. 22(12)). ### [RESULT] Out of Scope Product excluded from GPSR - Your product is excluded under Art. 2(2) (for example: medicinal products, food, feed, certain living plants and animals, animal by-products, plant protection products, certain transport means operated by a service provider, certain low-risk aircraft, and antiques). - Or it is a product that must be repaired or reconditioned prior to use and is placed on the market as such and clearly marked as such (Art. 2(3)). - If the product is subject to Union harmonisation legislation with specific safety requirements, GPSR applies only to aspects and risks not covered by those requirements (Art. 2(1)). ### [RESULT] GPSR Does Not Apply Not a product on the Union market - GPSR applies to products placed on or made available on the Union market (Art. 2(1) and Art. 3(6)-(7)). - For online and other distance sales, a product is considered made available on the market when the offer is directed to consumers in the Union (Art. 4). ## GPSR Timeline | Date | Event | Reference | | --- | --- | --- | | 2023-03-30 | European Parliament position adopted | Reg. (EU) 2023/988 | | 2023-05-10 | GPSR adopted by European Parliament and Council | Reg. (EU) 2023/988 | | 2023-05-23 | GPSR published in Official Journal (OJ L 135) | Reg. (EU) 2023/988 | | 2023-06-12 | GPSR enters into force | Art. 52 | | 2024-05-24 | Recall notice template implementing regulation adopted | Impl. Reg. (EU) 2024/1435 | | 2024-05-27 | Recall notice template implementing regulation published | Impl. Reg. (EU) 2024/1435 | | 2024-05-27 | Online marketplace interoperable interface implementing regulation adopted | Impl. Reg. (EU) 2024/1459 | | 2024-05-28 | Online marketplace interoperable interface implementing regulation published | Impl. Reg. (EU) 2024/1459 | | 2024-06-21 | Consumer reporting modalities implementing regulation adopted | Impl. Reg. (EU) 2024/1740 | | 2024-06-24 | Consumer reporting modalities implementing regulation published | Impl. Reg. (EU) 2024/1740 | | 2024-10-09 | Safety Gate contact points implementing regulation adopted | Impl. Reg. (EU) 2024/2639 | | 2024-10-10 | Safety Gate contact points implementing regulation published | Impl. Reg. (EU) 2024/2639 | | 2024-11-29 | Output indicators implementing regulation adopted | Impl. Reg. (EU) 2024/2958 | | 2024-12-02 | Output indicators implementing regulation published | Impl. Reg. (EU) 2024/2958 | | 2024-12-13 | GPSR applies (replaces Directive 2001/95/EC) | Art. 52 & Art. 50 | | 2024-12-13 | Safety Gate Rapid Alert System delegated regulation published | Del. Reg. (EU) 2024/3173 | | 2029-12-13 | Commission evaluation deadline | Art. 47 | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2023-03-30 | European Parliament Position Adopted | Legislation | | | 2023-05-10 | GPSR Adopted | Legislation | | | 2023-05-23 | GPSR Published in Official Journal | Legislation | | | 2023-06-12 | GPSR Enters Into Force | Legislation | | | 2023-06-12 | Delegated-Act Powers Conferred | Legislation | | | 2023-12-19 | GPSR Corrigendum Published | Legislation | | | 2024-05-24 | Recall Notice Template Regulation Adopted | Implementation | | | 2024-05-27 | Recall Notice Template Published | Implementation | | | 2024-05-27 | Safety Gate Interoperable Interface Regulation Adopted | Implementation | | | 2024-05-28 | Safety Gate Interface Regulation Published | Implementation | | | 2024-06-21 | Consumer Safety Gateway Rules Adopted | Implementation | | | 2024-06-24 | Consumer Safety Gateway Rules Published | Implementation | | | 2024-07-24 | Recall Notice Template Corrigendum | Implementation | | | 2024-08-27 | Safety Gate Delegated Regulation Adopted | Implementation | | | 2024-10-09 | Safety Gate National Contact Points Rules Adopted | Implementation | | | 2024-10-10 | Safety Gate National Contact Points Rules Published | Implementation | | | 2024-11-29 | GPSR Output Indicators Adopted | Implementation | | | 2024-12-02 | GPSR Output Indicators Published | Implementation | | | 2024-12-13 | GPSR Application Date - Full Enforcement Begins | Enforcement | | | 2024-12-13 | Safety Gate Delegated Regulation Published | Implementation | | | 2024-12-13 | Member State Notification Deadline | Implementation | | | 2024-12-13 | Safety Gate Interoperable Interface Deadline | Implementation | | | 2024-12-13 | GPSD and Look-Alike Products Directive Repealed | Legislation | | | 2025-01-01 | Safety Business Gateway Practical Guidelines | Guidance | | | 2025-06-13 | Q&A on Implementing Regulations Updated | Guidance | | | 2026-02-02 | Safety Business Gateway User Manual Updated | Guidance | | | 2026-12-13 | Commission Report on Safety Gate Portal Interconnection Due | Reporting | | | 2027-12-13 | Commission Assessment of Online Content Removal Due | Reporting | | | 2029-12-13 | GPSR Evaluation Deadline | Reporting | | **Event details:** - **2023-03-30 - European Parliament Position Adopted**: European Parliament position adopted (30 March 2023) during the legislative procedure for Regulation (EU) 2023/988. - **2023-05-10 - GPSR Adopted**: Regulation (EU) 2023/988 on general product safety adopted by the European Parliament and Council, amending Regulation (EU) No 1025/2012 and Directive (EU) 2020/1828, and repealing Directive 2001/95/EC and Council Directive 87/357/EEC. - **2023-05-23 - GPSR Published in Official Journal**: Regulation (EU) 2023/988 published in the Official Journal of the European Union (OJ L 135, 23.5.2023, p. 1). - **2023-06-12 - GPSR Enters Into Force**: Regulation (EU) 2023/988 enters into force on the twentieth day following its publication in the Official Journal. - **2023-06-12 - Delegated-Act Powers Conferred**: The power to adopt delegated acts under Article 18(3) and Article 26(10) is conferred on the Commission for an indeterminate period from 12 June 2023. - **2023-12-19 - GPSR Corrigendum Published**: Corrigendum to Regulation (EU) 2023/988 published in the Official Journal (OJ L, 19.12.2023, p. 1). - **2024-05-24 - Recall Notice Template Regulation Adopted**: Commission Implementing Regulation (EU) 2024/1435 adopted, establishing the template for a recall notice under Article 36 of the GPSR. - **2024-05-27 - Recall Notice Template Published**: Commission Implementing Regulation (EU) 2024/1435 published in the Official Journal (OJ L, 2024/1435, 27.5.2024). - **2024-05-27 - Safety Gate Interoperable Interface Regulation Adopted**: Commission Implementing Regulation (EU) 2024/1459 adopted, laying down rules for the interoperable interface of the Safety Gate Portal for providers of online marketplaces. - **2024-05-28 - Safety Gate Interface Regulation Published**: Commission Implementing Regulation (EU) 2024/1459 published in the Official Journal (OJ L, 2024/1459, 28.5.2024). - **2024-06-21 - Consumer Safety Gateway Rules Adopted**: Commission Implementing Regulation (EU) 2024/1740 adopted, setting rules for how consumers and other interested parties can inform the Commission about products that may present a risk, and how that information is transmitted to national authorities. - **2024-06-24 - Consumer Safety Gateway Rules Published**: Commission Implementing Regulation (EU) 2024/1740 published in the Official Journal (OJ L, 2024/1740, 24.6.2024). - **2024-07-24 - Recall Notice Template Corrigendum**: Corrigendum published for Commission Implementing Regulation (EU) 2024/1435 (OJ L 90426, 24.7.2024, p. 1). - **2024-08-27 - Safety Gate Delegated Regulation Adopted**: Commission Delegated Regulation (EU) 2024/3173 adopted, supplementing the GPSR with detailed rules on access to and operation of the Safety Gate Rapid Alert System. - **2024-10-09 - Safety Gate National Contact Points Rules Adopted**: Commission Implementing Regulation (EU) 2024/2639 adopted, setting the roles and tasks of the single national contact points of the Safety Gate Rapid Alert System. - **2024-10-10 - Safety Gate National Contact Points Rules Published**: Commission Implementing Regulation (EU) 2024/2639 published in the Official Journal (OJ L, 2024/2639, 10.10.2024). - **2024-11-29 - GPSR Output Indicators Adopted**: Commission Implementing Regulation (EU) 2024/2958 adopted, determining the output indicators relevant for Regulation (EU) 2023/988. - **2024-12-02 - GPSR Output Indicators Published**: Commission Implementing Regulation (EU) 2024/2958 published in the Official Journal (OJ L, 2024/2958, 2.12.2024). - **2024-12-13 - GPSR Application Date - Full Enforcement Begins**: Regulation (EU) 2023/988 becomes applicable and fully enforceable across the EU, replacing the General Product Safety Directive 2001/95/EC. - **2024-12-13 - Safety Gate Delegated Regulation Published**: Commission Delegated Regulation (EU) 2024/3173 published in the Official Journal (OJ L, 2024/3173, 13.12.2024). - **2024-12-13 - Member State Notification Deadline**: Member States must notify the Commission of national rules and measures by 13 December 2024, and promptly communicate later changes affecting them. - **2024-12-13 - Safety Gate Interoperable Interface Deadline**: By 13 December 2024, the Commission must develop an interoperable interface enabling online marketplace providers to link their interfaces with the Safety Gate Portal. - **2024-12-13 - GPSD and Look-Alike Products Directive Repealed**: Directive 2001/95/EC (GPSD) and Council Directive 87/357/EEC are repealed with effect from 13 December 2024. - **2025-01-01 - Safety Business Gateway Practical Guidelines**: Commission Notice on guidelines for the practical implementation of the Safety Business Gateway under Article 27(2) of Regulation (EU) 2023/988 (C/2025/6238). - **2025-06-13 - Q&A on Implementing Regulations Updated**: European Commission Q&A document updated, clarifying implementing and delegated regulations adopted under the GPSR. - **2026-02-02 - Safety Business Gateway User Manual Updated**: Safety Business Gateway user manual updated (version 5.0.0, February 2026). - **2026-12-13 - Commission Report on Safety Gate Portal Interconnection Due**: Commission must publish a report on the interconnection between the information and communication system in Regulation (EU) 2019/1020 Article 34 and the Safety Gate Portal. - **2027-12-13 - Commission Assessment of Online Content Removal Due**: Commission must assess the modalities for implementing online marketplace illegal content removal provisions (Article 22(4)-(6)), potentially accompanied by legislative proposal. - **2029-12-13 - GPSR Evaluation Deadline**: Commission must evaluate the GPSR and submit a report to the European Parliament, Council, and European Economic and Social Committee with its main findings. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/general-product-safety-regulation --- --- title: "EU Green Claims Directive (Proposal) Compliance Hub" canonical_url: "https://www.sorena.io/artifacts/eu/green-claims-directive" source_url: "https://www.sorena.io/artifacts/eu/green-claims-directive" author: "Sorena AI" description: "A practical EU green claims hub for marketing and sustainability teams: classify what counts as a green claim." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Green Claims Directive" - "green claims compliance" - "environmental claims substantiation" - "greenwashing risk checklist" - "green claims verification" - "product environmental footprint PEF" - "green claims evidence pack" - "sustainability marketing compliance" - "environmental labels governance" - "Green Claims Directive" - "greenwashing" - "environmental claims" - "substantiation" - "verification" - "labels" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Green Claims Directive (Proposal) Compliance Hub A practical EU green claims hub for marketing and sustainability teams: classify what counts as a green claim. ![EU Green Claims Directive artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-green-claims-timeline-small.jpg?v=cheatsheets%2Fprod) *Green Claims* *Free Resource* ## EU Green Claims Compliance Hub Turn green claims into a repeatable operating system: classify the claim, substantiate it with evidence, run verification and approvals, govern labels, and keep audit-ready records for regulators and marketplaces. Status note (March 2026): Parliament reported on 20 June 2025 that the Commission intended to withdraw the proposal, and the text has not been adopted. The workflows here remain the most practical way to reduce greenwashing risk and enforceability gaps across EU markets. [Start with the risk checklist](/artifacts/eu/green-claims-directive/greenwashing-risk-checklist.md) ## What you can decide faster - **Is it a green claim**: Claim classification for product pages, ads, packaging, and corporate statements. - **What to prove**: Evidence design: life-cycle thinking, trade-offs, data quality, and boundaries. - **How to approve**: Verification and review workflow that marketing can run without chaos. By Sorena AI | Status: not adopted | Updated Mar 2026 ### Quick scan *Green Claims* - **Classification**: Define claim type and scope (product vs company, absolute vs comparative). - **Evidence pack**: Build substantiation artifacts you can export on request. - **Governance**: Run verification, approvals, and labels governance with logs. Use the decision flow to standardize claim substantiation and approvals, then use the subpages to build templates and evidence packs. | Value | Metric | | --- | --- | | PEF | Method | | Proof | Evidence | | Review | Approval | | Logs | Records | **Key highlights:** Claim scope | Evidence first | Approval workflow ## Topic Guides - [EU Green Claims Applicability Test | Is This Environmental Claim In Scope (Product vs Company, Labels, Offsets)?](/artifacts/eu/green-claims-directive/applicability-test.md): A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim. - [EU Green Claims Checklist | Audit-Ready Checklist for Environmental Claims (Substantiation, Verification, Labels, Offsets)](/artifacts/eu/green-claims-directive/checklist.md): An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality. - [EU Green Claims Compliance Program | Operating Model for Marketing Claims: Governance, Evidence Packs, Verification, and Labels](/artifacts/eu/green-claims-directive/compliance.md): A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards. - [EU Green Claims FAQ | Greenwashing Questions, Offsets, Labels, Evidence Packs, and Claim Approval Workflows](/artifacts/eu/green-claims-directive/faq.md): Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims. - [EU Green Claims Timeline and Readiness Calendar | Key Policy Dates + Operational Milestones for Evidence, Verification, and Labels](/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar.md): A practical timeline and readiness calendar for green claims. - [EU Green Claims vs UK Green Claims Code | Practical Differences for Substantiation, Disclosures, Verification, and Enforcement](/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code.md): A practical comparison for teams operating in both the EU and UK. - [Green Claims Substantiation Template | Evidence Pack Structure, Life-Cycle Thinking, Data Quality, and Disclosures](/artifacts/eu/green-claims-directive/green-claims-substantiation-template.md): A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective. - [Green Claims Templates | Claim Card, Substantiation Pack, Verification Checklist, Disclosures, and Approval Logs](/artifacts/eu/green-claims-directive/templates.md): A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist. - [Greenwashing Risk Checklist | EU Green Claims | Pre-Publication Review for Ads, Packaging, Product Pages, and Corporate Claims](/artifacts/eu/green-claims-directive/greenwashing-risk-checklist.md): A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims. - [Labels and Certification Schemes | EU Green Claims | How to Govern Eco-Labels, Badges, Seals, and Scheme Evidence](/artifacts/eu/green-claims-directive/labels-and-certification-schemes.md): A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims. - [Penalties and Enforcement | EU Green Claims | How Greenwashing is Enforced, What Evidence Reduces Risk, and What to Do During Challenges](/artifacts/eu/green-claims-directive/penalties-and-enforcement.md): A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for. - [Penalties and Fines | EU Green Claims | Penalty Drivers, Aggravating Factors, and How to Reduce Exposure With Evidence](/artifacts/eu/green-claims-directive/penalties-and-fines.md): A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries. - [Requirements | EU Green Claims Directive (Proposal) | Substantiation, Verification, Labels Governance, and Disclosures](/artifacts/eu/green-claims-directive/requirements.md): An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build). - [Substantiation and Evidence Pack | EU Green Claims | How to Build Audit-Ready Evidence for Environmental Claims](/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack.md): A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation. - [Verification and Audit Readiness | EU Green Claims | Reviewer Checklist, Sampling, Evidence Logs, and Common Findings](/artifacts/eu/green-claims-directive/verification-and-audit-readiness.md): A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios. - [What Counts as a Green Claim? | EU Green Claims Directive (Proposal) | Examples, Claim Types, Boundaries, and Common Traps](/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim.md): A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims. ## Key milestones for green claims readiness *Green Claims Timeline* Use the timeline as context for policy evolution, then focus on operational readiness: evidence packs, review workflows, and labels governance. ## Can you make this claim and how do you prove it *Green Claims Decision Flow* Follow the decision flow to classify claims, define evidence needs, and set an internal approval process that scales across campaigns. *Next step* ## Turn EU Green Claims Compliance Hub into an ESG delivery workflow EU Green Claims Compliance Hub should be the shared entry point for your team. Route execution into ESG Compliance for live work and into Research Copilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU Green Claims Compliance Hub and route the work by entity, product, team, or control owner. - Use ESG Compliance to manage cross team sustainability work, reporting, and evidence from one workflow. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open ESG Compliance](/solutions/esg-compliance.md): Manage cross team sustainability work, reporting, and evidence from one workflow for EU Green Claims Compliance Hub. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs from the same artifact. - **Download decision flow**: Share the review logic with marketing teams. - **Download timeline**: Track milestones and enforcement signals. - [Talk through EU Green Claims Compliance Hub](/contact.md): Review your current process, evidence model, and next steps for EU Green Claims Compliance Hub. ## Decision Steps ### STEP 1: Are you a trader making voluntary environmental claims to consumers in the EU? *Reference: Scope* - The Commission proposal would cover traders (businesses) making voluntary, explicit environmental claims about products, services, or the trader itself in business-to-consumer (B2C) commercial practices. - The proposal would also cover non-EU businesses when they direct voluntary environmental claims at EU consumers. - **NO** Not In Scope - **YES** Are you a microenterprise? ### STEP 2: Are you a microenterprise? *Reference: Exemptions* - Microenterprises are defined as businesses with fewer than 10 employees and less than EUR 2 million turnover. - If adopted, microenterprises would be exempt from the obligations of the proposal, unless they choose to use the rules. - **YES** Microenterprise Exemption - **NO** What type of environmental claim are you making? ### STEP 3: What type of environmental claim are you making? *Reference: Types of claims* - Explicit environmental claims: Specific statements about environmental impact, aspect, or performance (e.g., packaging made of 30% recycled plastic; commitment to reduce CO2 emissions by 50% by 2030 compared to 2020). - Comparative claims: Environmental comparisons with other products or organizations (these would need to be fair and based on equivalent information and data). - Environmental labels: Use of labeling schemes indicating environmental performance. - Offset-based claims: Climate-related claims relying on carbon offsets or credits (e.g., carbon neutral, climate neutral, 100% CO2 compensated). - The proposal would only cover voluntary claims that are not already covered by more specific EU rules. - -> Is your claim already covered by other EU legislation? ### STEP 4: Is your claim already covered by other EU legislation? *Reference: Relationship with other EU rules* - If EU legislation already establishes more specific rules on environmental claims or labels for your sector or product category, those rules would prevail over the Green Claims proposal. - Examples mentioned by the Commission include EU Ecolabel, energy efficiency labels, organic farming label, and EMAS. - **YES** Claim Already Regulated - **NO** Does your claim rely on carbon offsets or credits? ### STEP 5: Does your claim rely on carbon offsets or credits? *Reference: Offset-based claims* - The Commission highlighted offset-based climate claims (e.g., carbon neutral, climate neutral, 100% CO2 compensated) as particularly prone to being unclear and misleading to consumers. - The Commission described the proposal as tackling claims that rely on offsetting and requiring transparency about the role of offsets versus own reductions. - -> Have you completed independent verification of your claim? ### STEP 6: Have you completed independent verification of your claim? *Reference: Verification requirement* - The Commission described the proposal as requiring ex-ante verification of substantiation before claims are communicated to consumers. - Member States would be responsible for setting up verification and enforcement processes, performed by independent and accredited verifiers. - **NO** Independent Verification Required - **YES** Are you creating a new environmental labelling scheme? ### STEP 7: Are you creating a new environmental labelling scheme? *Reference: Environmental labeling schemes* - The Commission described the proposal as controlling the proliferation of public and private environmental labels. - EU-level schemes would be encouraged. - New public schemes (unless developed at EU level) would not be allowed, and new private schemes would only be allowed if they show higher ambition and obtain pre-approval. - **YES** Is the new labelling scheme a public scheme (created or run by a Member State or public authority)? - **NO** Green Claims Proposal Requirements ### STEP 8: Is the new labelling scheme a public scheme (created or run by a Member State or public authority)? *Reference: Environmental labeling schemes* - If yes: the Commission described new public schemes (unless developed at EU level) as not allowed under the proposal. - If no: the Commission described new private schemes as only allowed if they show higher ambition and obtain pre-approval. - **YES** New Public Schemes Not Permitted - **NO** Green Claims Proposal Requirements ## Reference Information ### The Greenwashing Problem - 53.3% of environmental claims examined were vague, misleading, or unfounded (Commission study cited by the Commission, 2020). - 40% of claims examined were completely unsubstantiated (Commission study cited by the Commission, 2020). - Around 230 green labels were identified in the EU (Commission Q&A). - 94% of Europeans say protecting the environment is important to them personally (Special Eurobarometer 501). - 68% agree that their consumption habits adversely affect the environment (Special Eurobarometer 501). ### Substantiation Requirements - Claims would need to be substantiated with scientific evidence that is widely recognised. - Substantiation would take a life-cycle perspective, from raw materials to end-of-life. - Substantiation would identify relevant environmental impacts and any trade-offs between them. - If making comparative claims, comparisons must be fair and based on equivalent information and data. - Claims or labels using aggregate scoring of overall environmental impact would not be permitted unless set in EU rules. - The Commission described the proposal as requiring ex-ante verification, meaning substantiation would be verified before the claim is made. ### Life-Cycle Assessment Approach - The Commission described the proposal as taking a life-cycle approach, from raw materials to end-of-life. - The proposal would expect claims to identify relevant environmental impacts and trade-offs. ### Requirements for Offset-Based Claims - Be transparent about which part of the claim concerns your own operations or value chain, and which part relies on buying offsets. - Focus on reducing emissions in your own organisation or value chain, not only on buying offsets. - Meet the proposal's requirements on the integrity and correct accounting of offsets. ### Independent Verifier Requirements - Verifiers would be independent and accredited. - The verifier would check whether the claim meets the minimum requirements for substantiation and communication described by the Commission. - The Commission described the verifier as issuing a certificate of compliance recognised across the EU. ### Communication Requirements - The Commission described the proposal as setting minimum requirements for substantiation and communication of voluntary environmental claims. - The proposal would complement general EU consumer protection rules that prohibit misleading commercial practices. - Ex-ante verification is intended to ensure claims are not misleading before they are placed on the market. ### New Private Environmental Labeling Schemes - The Commission described new private labelling schemes as only allowed if they can show higher environmental ambition than existing ones and obtain pre-approval. - For private operators (including those outside the EU) placing new schemes on the EU market, the Commission described notification and approval requirements. - Environmental labels were described as needing to be transparent, verified by a third party, and regularly reviewed. ### Using Existing Environmental Labels - EU Ecolabel: Official EU voluntary label for environmental excellence, already regulated and recognized. - EMAS (Eco-Management and Audit Scheme): EU scheme for companies to evaluate, report, and improve environmental performance. - Energy efficiency labels: Regulated under specific EU legislation. - Organic farming labels: Regulated under EU organic production rules. - The Commission described the Green Claims proposal as limited to claims that are not currently covered by other EU rules. ### Enforcement and Penalties - Member States would be responsible for setting up verification and enforcement processes for the proposed rules. - Penalties and enforcement details would be set at Member State level, in line with the directive if adopted. - Consumer organizations can bring collective actions to protect consumer interests (Representative Actions Directive 2020/1828). - Misleading commercial practices can also be addressed under general EU consumer protection law. ### Relationship with Unfair Commercial Practices Directive (UCPD) - The Commission described the Green Claims proposal as complementing the UCPD, which generally prohibits misleading commercial practices. - The UCPD is being strengthened through the 'Empowering Consumers for the Green Transition' directive (proposed March 2022). - The Commission described the proposal as introducing verification requirements before claims can be made and put on the market. ### Support for Small and Medium Enterprises (SMEs) - The Commission described microenterprises as exempt (unless they opt in) to avoid disproportionate burden. - The Commission described the proposal as asking Member States to help SMEs apply the requirements (financial support, organisational assistance, technical assistance). - The Commission also described funding support for data and calculation tools for SMEs. ### International Traders and Third-Country Businesses - The Commission described the proposal as applying to non-EU businesses when they make voluntary environmental claims directed at EU consumers. - The Commission also described notification and approval requirements for new labelling schemes placed on the EU market by private operators, including from external partners. ### Benefits of Compliance - Competitive advantage for companies making a genuine effort to improve environmental performance. - Reduced legal fragmentation in the internal market and lower cross-border compliance costs. - More trustworthy information for consumers and reinforced credibility for EU industries outside the EU. ### Product Environmental Footprint (PEF) Methodology - The Commission Recommendation 2021/2279 describes EU-recommended Product Environmental Footprint (PEF) and Organisation Environmental Footprint (OEF) methods. - PEF/OEF methods are life-cycle assessment approaches that quantify environmental impacts across the life cycle. - PEF Category Rules (PEFCRs) guidance exists to support consistent assessments for specific product groups. - PEF/OEF can be one way to support robust substantiation of voluntary environmental claims. ## Possible Outcomes ### [RESULT] Claim Already Regulated Existing EU rules apply - Your environmental claim is covered by specific EU legislation (e.g., EU Ecolabel, energy efficiency label, organic farming label). - Follow the requirements of that specific EU scheme. - The Commission described the Green Claims proposal as limited to claims that are not currently covered by other EU rules. ### [RESULT] Microenterprise Exemption Optional compliance - If adopted, the Green Claims proposal would exempt microenterprises from its obligations, unless they choose to use the rules. - Even if exempt, misleading commercial practices can still be addressed under general EU consumer protection rules. ### [RESULT] Not In Scope Proposal not in scope - You are not making voluntary environmental claims to consumers in the EU, or you are not a trader. - The Green Claims proposal would not apply in this case, but other EU and national consumer protection rules may still be relevant. ### [ACTION] Independent Verification Required Verify before communicating the claim - If adopted, the proposal would require ex-ante verification by an independent and accredited verifier before the claim is communicated to consumers. - Prepare your substantiation and complete the verification process before publishing or marketing the claim. ### [RESULT] New Public Schemes Not Permitted EU-level schemes only - The Commission described new public environmental labelling schemes (unless developed at EU level) as not allowed under the proposal. - The Commission also described EU-wide schemes as encouraged (e.g., EU Ecolabel). ### [RESULT] Green Claims Proposal Requirements Substantiation and ex-ante verification (if adopted) - The Commission described the proposal as setting minimum requirements for substantiation and communication of voluntary environmental claims, with ex-ante verification by independent and accredited verifiers. - Substantiation would need scientific evidence, a life-cycle perspective, and identification of relevant impacts and trade-offs. - Comparisons would need to be fair and based on equivalent information and data. - If offsets are used, the Commission described the proposal as requiring transparency about what part of a claim concerns own operations versus offsets, plus requirements on integrity and correct accounting. ## Green Claims Directive Timeline | Date | Event | Reference | | --- | --- | --- | | 2023-03-22 | Commission publishes proposal for the Green Claims Directive (COM(2023)0166) and Q&A | COM(2023)0166 | | 2024-03-12 | European Parliament adopts first-reading position | Legislative procedure | | 2024-06-17 | Council approves general approach | Legislative procedure | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2020-01-01 | Environmental Claims in the EU (Study) | Supporting frameworks | | | 2021-12-01 | Environmental Footprint Recommendation Published (December 2021) | Supporting frameworks | | | 2022-01-01 | Impact Assessment Report Published (Empowering Consumers) | Supporting frameworks | | | 2022-03-30 | Empowering Consumers Proposal Put Forward | Commission actions | | | 2023-03-22 | Green Claims Directive Proposal Published | Legislative milestones | | | 2023-03-22 | Commission Q&A Published | Commission actions | | | 2023-06-01 | Committee Referral Announced (1st Reading) | Parliament actions | | | 2023-06-14 | EESC Opinion Published | Supporting frameworks | | | 2023-07-12 | Referral to Joint Committee Announced | Parliament actions | | | 2023-07-13 | AGRI Opinion Rapporteur Appointed | Committee work | | | 2023-07-26 | National Parliament Contribution (Italy) | Supporting frameworks | | | 2023-10-10 | Committee of the Regions Opinion Published | Supporting frameworks | | | 2023-10-11 | Committee Draft Report | Committee work | | | 2023-11-13 | Amendments Tabled | Committee work | | | 2023-11-17 | EPRS Policy Podcast Published | Supporting frameworks | | | 2024-01-25 | AGRI Opinion Published | Committee work | | | 2024-02-14 | Vote in Committee (1st Reading) | Committee work | | | 2024-02-23 | Committee Report Tabled for Plenary | Committee work | | | 2024-03-05 | EPRS Briefing Published | Supporting frameworks | | | 2024-03-11 | Parliament Debate | Parliament actions | | | 2024-03-12 | Parliament First-Reading Position Adopted | Legislative milestones | | | 2024-06-17 | Council General Approach Approved | Council actions | | | 2024-07-22 | Commission Response to Parliament Text | Commission actions | | | 2024-10-11 | EPRS Briefing Updated (Oct 2024 Edition) | Supporting frameworks | | | 2024-11-13 | Committee Referral Announced (New Term) | Parliament actions | | | 2024-12-04 | Decision to Open Interinstitutional Negotiations | Committee work | | | 2024-12-16 | Negotiation Decision Announced in Plenary | Parliament actions | | **Event details:** - **2020-01-01 - Environmental Claims in the EU (Study)**: Commission references the study "Environmental claims in the EU (2020)" as part of the Green Claims policy context. - **2021-12-01 - Environmental Footprint Recommendation Published (December 2021)**: Commission Recommendation (EU) 2021/2279 is cited as the basis for common Environmental Footprint methods (PEF and OEF), published in December 2021. - **2022-01-01 - Impact Assessment Report Published (Empowering Consumers)**: Impact assessment work for the empowering consumers for the green transition initiative is referenced as context for the Green Claims proposal. - **2022-03-30 - Empowering Consumers Proposal Put Forward**: Commission puts forward its proposal for a Directive on empowering consumers for the green transition (complementary to the Green Claims initiative). - **2023-03-22 - Green Claims Directive Proposal Published**: Commission publishes the legislative proposal for a Directive on substantiation and communication of explicit environmental claims (COM(2023)0166) (procedure 2023/0085(COD)). - **2023-03-22 - Commission Q&A Published**: European Commission publishes Q&A on the European Green Claims proposal. - **2023-06-01 - Committee Referral Announced (1st Reading)**: Committee referral announced in Parliament at first reading for the Green Claims Directive file. - **2023-06-14 - EESC Opinion Published**: European Economic and Social Committee publishes its opinion/report on the proposal (CES5381/2022). - **2023-07-12 - Referral to Joint Committee Announced**: Referral to joint committees announced in Parliament (ENVI and IMCO). - **2023-07-13 - AGRI Opinion Rapporteur Appointed**: AGRI (Agriculture and Rural Development) appoints its rapporteur for opinion (Petri Sarvamaa). - **2023-07-26 - National Parliament Contribution (Italy)**: Contribution submitted by the Italian Chamber of Deputies on the proposal (COM(2023)0166). - **2023-10-10 - Committee of the Regions Opinion Published**: Committee of the Regions publishes its opinion on the proposal (CDR2019/2023). - **2023-10-11 - Committee Draft Report**: Committee draft report is issued for the file. - **2023-11-13 - Amendments Tabled**: Amendments are tabled in committee (PE756.119). - **2023-11-17 - EPRS Policy Podcast Published**: European Parliament Research Service publishes its policy podcast on the Green Claims Directive. - **2024-01-25 - AGRI Opinion Published**: AGRI Committee opinion is published (PE753.776). - **2024-02-14 - Vote in Committee (1st Reading)**: Vote in committee at first reading takes place. - **2024-02-23 - Committee Report Tabled for Plenary**: Committee report is tabled for plenary (A9-0056/2024). - **2024-03-05 - EPRS Briefing Published**: EP Research Service briefing entry appears in the procedure timeline (dated 05/03/2024). - **2024-03-11 - Parliament Debate**: Debate in Parliament takes place (CRE-9-2024-03-11-TOC_EN). - **2024-03-12 - Parliament First-Reading Position Adopted**: Text adopted by Parliament at first reading (T9-0131/2024). - **2024-06-17 - Council General Approach Approved**: The Council approves a general approach on the Green Claims Directive proposal, as noted in the Parliament Think Tank briefing. - **2024-07-22 - Commission Response to Parliament Text**: Commission response to the text adopted in plenary is recorded in the procedure timeline (SP(2024)350). - **2024-10-11 - EPRS Briefing Updated (Oct 2024 Edition)**: EPRS Think Tank briefing is updated (dated 11 October 2024). - **2024-11-13 - Committee Referral Announced (New Term)**: Committee referral announced in Parliament again during the new parliamentary term. - **2024-12-04 - Decision to Open Interinstitutional Negotiations**: Committee decision to open interinstitutional negotiations after Parliament's first reading. - **2024-12-16 - Negotiation Decision Announced in Plenary**: Committee decision to enter into interinstitutional negotiations announced in plenary (Rule 72). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/green-claims-directive --- --- title: "EU Low Voltage Directive (LVD) 2014/35/EU - Timeline and Decision Flow (CE Marking, Safety, Technical File)" canonical_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive" source_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive" author: "Sorena AI" description: "A practical EU Low Voltage Directive artifact covering Directive 2014/35/EU as applied since 20 April 2016." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Low Voltage Directive" - "Low Voltage Directive 2014/35/EU" - "LVD compliance" - "LVD scope" - "LVD voltage limits 50 1000 V AC 75 1500 V DC" - "LVD Annex I safety objectives" - "CE marking LVD" - "EU declaration of conformity LVD" - "technical file LVD" - "LVD technical documentation" - "harmonised standards LVD" - "conformity assessment Module A" - "Low Voltage Directive" - "Directive 2014/35/EU" - "Electrical safety" - "CE marking" - "Technical documentation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Low Voltage Directive (LVD) 2014/35/EU - Timeline and Decision Flow (CE Marking, Safety, Technical File) A practical EU Low Voltage Directive artifact covering Directive 2014/35/EU as applied since 20 April 2016. ![EU LVD artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-lvd-timeline-small.jpg?v=cheatsheets%2Fprod) *LVD* *Free Resource* ## EU LVD Timeline and Electrical Safety Decision Flow Use this artifact to confirm whether your electrical equipment falls within the LVD scope of 50 to 1000 V AC or 75 to 1500 V DC, then plan Annex I safety evidence, harmonised standards, technical documentation, and the EU Declaration of Conformity for CE marking. Directive 2014/35/EU was adopted on 26 February 2014, published on 29 March 2014, and has applied since 20 April 2016. This page is a practical compliance reference, not legal advice. [Assess LVD scope](/artifacts/eu/low-voltage-directive/applicability-test.md) ## What you can decide faster - **In scope**: Electrical equipment scope and exclusions checks. - **Safety objectives**: High level safety expectations and hazards mapping. - **Evidence**: Technical file and DoC planning for CE readiness. Applies since 20 Apr 2016 | 10 year retention | Updated Mar 2026 ### Quick scan *LVD* - **Scope**: Check 50 to 1000 V AC and 75 to 1500 V DC, then test Annex II exclusions. - **Safety design**: Map Annex I objectives to hazards, controls, and verification evidence. - **Documentation**: Build Annex III technical documentation and an Annex IV aligned DoC. Use the decision flow to separate in-scope equipment from excluded products, identify the right economic operator duties, and build a defensible CE evidence chain. | Value | Metric | | --- | --- | | 50-1000V AC | Scope | | 75-1500V DC | Scope | | 10 years | Retention | | Module A | Assessment | **Key highlights:** Voltage limits | Annex I safety | OJ standards ## Topic Guides - [Applicability Test | EU Low Voltage Directive (LVD) 2014/35/EU | In Scope or Excluded?](/artifacts/eu/low-voltage-directive/applicability-test.md): A step-by-step applicability test for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, product vs component. - [Checklist | EU Low Voltage Directive (LVD) 2014/35/EU | CE Marking Readiness Checklist (Technical File + DoC)](/artifacts/eu/low-voltage-directive/checklist.md): An audit-ready CE marking checklist for the EU Low Voltage Directive (LVD) 2014/35/EU: scope memo + Annex II exclusions, Annex I safety objectives mapping. - [Compliance Program | EU Low Voltage Directive (LVD) 2014/35/EU | Operating Model, Controls, and Evidence](/artifacts/eu/low-voltage-directive/compliance.md): Build a scalable compliance program for EU Low Voltage Directive (LVD) 2014/35/EU: product family strategy, scope control, Annex I hazard mapping. - [Conformity Assessment and CE Marking | EU Low Voltage Directive (LVD) 2014/35/EU | Module A, DoC, Technical File](/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce.md): A practical CE marking workflow for EU Low Voltage Directive (LVD) 2014/35/EU: Module A (internal production control), risk assessment. - [Deadlines and Compliance Calendar | EU Low Voltage Directive (LVD) 2014/35/EU | Release Gates, Evidence Cadence, Standards Updates](/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for EU Low Voltage Directive 2014/35/EU: legal milestones from adoption through current application, release gate timing. - [Essential Safety Requirements (Annex I) | EU Low Voltage Directive (LVD) 2014/35/EU | Hazards, Controls, and Test Evidence](/artifacts/eu/low-voltage-directive/essential-safety-requirements.md): Translate EU Low Voltage Directive (LVD) 2014/35/EU Annex I safety objectives into an engineering-ready hazard map: protection against electric shock. - [EU LVD vs EMC Directive | Low Voltage Directive 2014/35/EU vs EMC 2014/30/EU | What Changes for CE Marking?](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive.md): A practical comparison of the EU Low Voltage Directive (LVD) 2014/35/EU and the EMC Directive 2014/30/EU. - [EU LVD vs Machinery Regulation | Low Voltage Directive 2014/35/EU vs Machinery Regulation (EU) 2023/1230 | Electrical Risks and CE Evidence](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation.md): A practical overlap guide for Low Voltage Directive (LVD) 2014/35/EU and Machinery Regulation (EU) 2023/1230: when the product is machinery/related product. - [FAQ | EU Low Voltage Directive (LVD) 2014/35/EU | Scope, CE Marking, Technical File](/artifacts/eu/low-voltage-directive/faq.md): High-signal FAQ for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, do you need a notified body. - [Harmonised Standards | EU Low Voltage Directive (LVD) 2014/35/EU | Presumption of Conformity, OJ Lists, and Update Control](/artifacts/eu/low-voltage-directive/harmonized-standards.md): How harmonised standards work under the EU Low Voltage Directive (LVD) 2014/35/EU: presumption of conformity, Official Journal (OJ) references. - [Penalties and Fines | EU Low Voltage Directive (LVD) 2014/35/EU | Enforcement, Market Surveillance Actions, Risk Reduction](/artifacts/eu/low-voltage-directive/penalties-and-fines.md): Enforcement overview for the EU Low Voltage Directive (LVD) 2014/35/EU: what market surveillance authorities typically ask for. - [Requirements | EU Low Voltage Directive (LVD) 2014/35/EU | Manufacturer, Importer, Distributor Obligations](/artifacts/eu/low-voltage-directive/requirements.md): An implementation-grade requirements breakdown for the EU Low Voltage Directive (LVD) 2014/35/EU: obligations for manufacturers, authorised representatives. - [Scope and Products | EU Low Voltage Directive (LVD) 2014/35/EU | Voltage Limits, Exclusions (Annex II), and Examples](/artifacts/eu/low-voltage-directive/scope-and-products.md): A practical scope guide for the EU Low Voltage Directive 2014/35/EU: voltage limits at 50 to 1000 V AC and 75 to 1500 V DC. - [Technical Documentation (Technical File) | EU Low Voltage Directive (LVD) 2014/35/EU | Annex III Checklist and Structure](/artifacts/eu/low-voltage-directive/technical-documentation.md): Build an audit-ready LVD technical file for Directive 2014/35/EU: Annex III elements (product description, drawings/schematics, explanations, standards list. - [Templates | EU Low Voltage Directive (LVD) 2014/35/EU | Technical File Index, DoC Skeleton, Scope Memo, Evidence Pack](/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template.md): Copy/paste templates for EU Low Voltage Directive (LVD) 2014/35/EU compliance: scope memo (voltage + Annex II exclusions + overlap). ## Key dates for electrical safety teams *LVD Timeline* Track key milestones and updates that shape standards strategy, CE readiness, and product lifecycle planning. ## Does the LVD apply to your equipment *LVD Decision Flow* Use the decision flow to confirm applicability, then translate outcomes into safety design and documentation requirements. *Next step* ## Turn EU LVD Timeline and Electrical Safety Decision Flow into an operational assessment workflow EU LVD Timeline and Electrical Safety Decision Flow should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU LVD Timeline and Electrical Safety Decision Flow and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for EU LVD Timeline and Electrical Safety Decision Flow. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share applicability logic internally. - **Download timeline**: Align milestones across teams. - [Talk through EU LVD Timeline and Electrical Safety Decision Flow](/contact.md): Review your current process, evidence model, and next steps for EU LVD Timeline and Electrical Safety Decision Flow. ## Decision Steps ### STEP 1: Is your electrical equipment designed for use within the voltage limits? *Reference: Art. 1* - Voltage limits: 50-1000V AC or 75-1500V DC. - If yes: check scope exclusions (Annex II). - If no: LVD does not apply. - **NO** Out of Scope - Voltage Limits - **YES** Is your equipment listed in Annex II exclusions? ### STEP 2: Is your equipment listed in Annex II exclusions? *Reference: Art. 1 & Annex II* - Check if your equipment is specifically excluded under Annex II. - If yes: LVD does not apply (other directives may apply). - If no: proceed to safety objectives assessment. - **YES** Out of Scope - Annex II Exclusion - **NO** Are you the manufacturer (placing the equipment on the market under your name/trademark)? ### STEP 3: Are you the manufacturer (placing the equipment on the market under your name/trademark)? *Reference: Art. 2(3)-(7)* - If yes: you take full responsibility for design/manufacture, conformity assessment (Module A), EU DoC, and CE marking. - If no: determine whether you are an importer or distributor (different obligations apply). - Authorized representatives act on behalf of the manufacturer (written mandate; established in the EU). - **YES** Manufacturer: Have you completed internal production control (Module A)? - **NO** If not the manufacturer: are you the importer (first placing equipment from a third country on the EU market)? ### STEP 3A: If not the manufacturer: are you the importer (first placing equipment from a third country on the EU market)? *Reference: Art. 2(5), Art. 8* - Importer obligations include verifying CE marking, EU DoC/technical documentation availability, and ensuring required identification and instructions. - If you place equipment on the market under your name/trademark or modify it in a way that may affect compliance, you may be treated as the manufacturer. - **YES** Importer Compliance Achieved - **NO** If not the importer: are you the distributor (making equipment available after it has been placed on the market)? ### STEP 3B: If not the importer: are you the distributor (making equipment available after it has been placed on the market)? *Reference: Art. 2(6), Art. 9* - Distributor obligations include checking CE marking and required documents, and ensuring storage/transport conditions do not jeopardize compliance. - If you place equipment on the market under your name/trademark or modify it in a way that may affect compliance, you may be treated as the manufacturer. - **YES** Distributor Compliance Achieved - **NO** Clarify Economic Operator Role ### STEP 4: Manufacturer: Have you completed internal production control (Module A)? *Reference: Annex III* - Module A is the sole conformity assessment procedure for LVD. - No third-party notified body intervention required. - Manufacturer performs conformity assessment on sole responsibility. - See Module A requirements in detail. - **YES** Have you affixed the CE marking and drawn up the EU declaration of conformity? - **NO** Complete Module A Before Placing on Market ### STEP 5: Have you affixed the CE marking and drawn up the EU declaration of conformity? *Reference: Art. 15, Art. 17 & Annex IV* - CE marking is mandatory for compliant equipment. - EU declaration of conformity must follow Annex IV model structure. - Both required before placing equipment on market. - **YES** Manufacturer Compliance Achieved - **NO** Affix CE Marking and Draw Up EU DoC ## Reference Information ### Voltage Scope - Alternating current (AC): 50V - 1000V - Direct current (DC): 75V - 1500V - Equipment must be designed for use within these limits. - The term 'electrical equipment' is interpreted according to internationally recognized meaning (IEC definition). ### Annex II Exclusions - Electrical equipment for use in explosive atmospheres - Electrical equipment for radiology and medical purposes - Electrical parts for goods and passenger lifts - Electricity meters - Plugs and socket outlets for domestic use - Electric fence controllers - Radio-electrical interference - Specialized electrical equipment for ships, aircraft or railways complying with international body safety provisions - Custom-built evaluation kits for professionals at R&D facilities ### Safety Objectives (Annex I) - General conditions: Essential characteristics marked on equipment or documentation; safe assembly/connection; designed for safe use when properly maintained. - Protection against electrical hazards: Protection from direct/indirect contact; no dangerous temperatures/arcs/radiation; protection from non-electrical dangers; suitable insulation. - Protection against external influences: Meet mechanical requirements; resist environmental influences; safe under foreseeable overload conditions. ### Manufacturer Obligations - Ensure equipment designed and manufactured per safety objectives (Art. 6(1)). - Draw up technical documentation and carry out conformity assessment (Module A - internal production control) (Art. 6(2)). - Draw up EU declaration of conformity and affix CE marking (Art. 6(2)). - Keep technical documentation and EU DoC for 10 years (Art. 6(3)). - Ensure series production remains in conformity; monitor changes (Art. 6(4)). - Mark equipment with type/batch/serial number or other identification (Art. 6(5)). - Indicate name, trademark and contact address on equipment or packaging (Art. 6(6)). - Provide instructions and safety information in language understood by end-users (Art. 6(7)). - Take corrective action if non-compliant; inform authorities if risk exists (Art. 6(8)). - Cooperate with authorities upon request (Art. 6(9)). ### Importer Obligations - Place only compliant equipment on market (Art. 8(1)). - Ensure manufacturer carried out conformity assessment (Art. 8(2)). - Verify CE marking, technical documentation, and EU DoC exist (Art. 8(2)). - Add own name, trademark and contact address on equipment or packaging (Art. 8(3)). - Ensure instructions in appropriate language (Art. 8(4)). - Ensure storage/transport conditions don't jeopardize compliance (Art. 8(5)). - Conduct sample testing if appropriate; monitor complaints and recalls (Art. 8(6)). - Take corrective action if non-compliant; inform authorities if risk exists (Art. 8(7)). - Keep copy of EU DoC for 10 years; ensure technical documentation available (Art. 8(8)). - Cooperate with authorities upon request (Art. 8(9)). ### Distributor Obligations - Act with due care regarding LVD requirements (Art. 9(1)). - Verify CE marking, required documents, instructions in appropriate language before making available (Art. 9(2)). - Verify manufacturer and importer complied with identification requirements (Art. 9(2)). - Ensure storage/transport conditions don't jeopardize compliance (Art. 9(3)). - Ensure corrective measures taken if non-compliant; inform authorities if risk exists (Art. 9(4)). - Cooperate with authorities upon request (Art. 9(5)). ### Module A - Internal Production Control - Establish technical documentation including: general description; design/manufacturing drawings; risk analysis; list of standards applied (harmonized/IEC/national); test reports (Annex III, point 2). - Technical documentation must demonstrate conformity to safety objectives. - Take measures to ensure manufacturing process ensures compliance (Annex III, point 3). - Affix CE marking to each compliant equipment (Annex III, point 4.1). - Draw up written EU declaration of conformity for product model (Annex III, point 4.2). - Keep technical documentation and EU DoC for 10 years (Annex III, point 4.2). - Authorized representative may fulfill marking/declaration obligations if specified in mandate (Annex III, point 5). ### Standards Hierarchy & Presumption of Conformity - Harmonized standards (Art. 12): Equipment conforming to harmonized EN standards (published in OJ) is presumed to comply with safety objectives. - International standards (Art. 13): Where harmonized standards not available, IEC standards published in OJ (after notification procedure) confer presumption of conformity. - National standards (Art. 14): Where harmonized/IEC standards unavailable, national standards satisfying safety requirements confer presumption of conformity. - Presumption is not mandatory - manufacturer may use other solutions and demonstrate compliance directly. - Objection procedure exists if harmonized standards don't fully satisfy safety objectives (Regulation 1025/2012). ### Technical Documentation Requirements - General description of electrical equipment. - Conceptual design and manufacturing drawings/schemes of components, sub-assemblies, circuits. - Descriptions and explanations for understanding drawings/schemes and operation. - List of harmonized standards applied (full or partial) with OJ references, or IEC/national standards per Arts. 13-14. - If standards not applied or only partially applied: descriptions of solutions adopted to meet safety objectives; specify which parts applied. - Results of design calculations and examinations. - Test reports. - Adequate risk analysis and assessment. ### CE Marking Rules - Affix CE marking visibly, legibly and indelibly to equipment or data plate (Art. 17(1)). - If not possible due to size/nature: affix to packaging and accompanying documents (Art. 17(1)). - Affix CE marking before placing equipment on market (Art. 17(2)). - General CE marking principles governed by Regulation (EC) 765/2008 (Art. 16). - CE marking indicates conformity with all applicable Union harmonization legislation. - Only manufacturer (or authorized representative/importer/distributor acting as manufacturer) may affix CE marking. ### EU Declaration of Conformity - Follow model structure in Annex IV. - Must contain: product model/type; manufacturer name/address; statement of sole responsibility; object description (with image if needed for identification); applicable Union harmonization legislation; references to harmonized standards or other technical specifications; additional info; signature, place and date. - Drawn up for product model. - Kept with technical documentation for 10 years after equipment placed on market. - Available to market surveillance authorities upon request. - Continuously updated (Art. 15(2)). - If multiple Union acts apply: single EU DoC (or dossier of individual DoCs) covering all acts (Art. 15(1)). ### Market Surveillance & Compliance - Regulation (EC) 765/2008 provisions apply (Art. 18). - Authorities may request information/documentation from economic operators. - Safeguard procedure (Art. 19): If Member State finds non-compliant equipment on market, it takes measures and informs Commission and other Member States. - Union safeguard procedure (Art. 20): If disagreement or justified objection, Commission determines via implementing acts whether measure justified. - Compliant equipment presenting risk (Art. 21): Member State takes measures and Commission may adopt implementing acts. - Formal non-compliance (Art. 22): Missing/incorrect CE marking or EU DoC triggers corrective measures. - Member States establish penalties for infringements; penalties must be effective, proportionate and dissuasive (Art. 23). ### Penalties & Enforcement - Member States lay down rules on penalties for infringements (Art. 23). - Penalties must be effective, proportionate and dissuasive. - National law implementing LVD sets specific penalties. - Market surveillance authorities have investigatory and enforcement powers per Regulation 765/2008. ### Electricity Supply Bodies - Member States ensure electricity supply bodies do not impose stricter safety requirements than LVD safety objectives for grid connection or electricity supply (Art. 5). - Electricity supply bodies cannot block compliant equipment. ### Good Engineering Practice - Equipment must be constructed per good engineering practice in safety matters in force in the Union (Art. 3). - Equipment must not endanger health/safety of persons, domestic animals, or property when properly installed, maintained and used for intended purpose. - Good engineering practice includes following harmonized standards, IEC standards, or national standards. - Where standards not applied, manufacturer must demonstrate safety objectives met through alternative solutions. ### Free Movement Principle - Member States shall not impede making available on market of compliant equipment (Art. 4). - Compliant equipment benefits from free movement across EU/EEA. - LVD is a 'total harmonization' directive - supersedes national legislation in covered field. - National standards/specifications cannot be mandatory condition for market access. ### Authorized Representatives - Manufacturer may appoint authorized representative by written mandate (Art. 7(1)). - Authorized representative must be established within EU. - Cannot delegate: design/manufacturing obligations, drawing up technical documentation (Art. 7(1)). - Must: keep EU DoC and technical documentation for 10 years; provide information to authorities; cooperate on risk elimination (Art. 7(2)). - Acts on behalf and under responsibility of manufacturer per mandate. ### When Importer/Distributor Becomes Manufacturer - Importer or distributor placing equipment on market under own name/trademark becomes manufacturer (Art. 10). - Modifying equipment in way that may affect compliance makes you manufacturer (Art. 10). - If you become manufacturer: all manufacturer obligations apply. - Must carry out conformity assessment, draw up technical documentation, affix CE marking, draw up EU DoC. ### Traceability Requirements - Manufacturers must mark equipment with type, batch, or serial number (or other identification element) (Art. 6(5)). - Manufacturers must indicate name, trademark and postal address on equipment (or packaging/documents if not possible) (Art. 6(6)). - Importers must add own name, trademark and postal address on equipment (or packaging/documents if not possible) (Art. 8(3)). - Contact details must be in language easily understood by end-users and market surveillance authorities. - Economic operators must be able to identify who supplied them equipment and to whom they supplied equipment - for 10 years (Art. 11). ### New Legislative Framework (NLF) Alignment - LVD 2014/35/EU is recast of 2006/95/EC aligned to NLF. - Scope and safety objectives unchanged from previous directive. - NLF introduces: clearer economic operator obligations, enhanced market surveillance, Committee procedure. - Regulation (EC) 765/2008: accreditation, market surveillance, CE marking principles. - Decision 768/2008/EC: common framework for marketing of products, Module A conformity assessment. ## Possible Outcomes ### [RESULT] Manufacturer Compliance Achieved Equipment may be placed on EU market - You have completed internal production control (Module A). - Technical documentation and EU declaration of conformity prepared. - CE marking affixed. - Equipment meets LVD safety objectives. - You may place equipment on the EU market and benefit from free movement. - Maintain documentation for 10 years and monitor ongoing compliance. ### [ACTION REQUIRED] Complete Module A Before Placing on Market Internal production control is mandatory - Under the LVD, the manufacturer must carry out internal production control (Module A) before placing the equipment on the market. - Prepare technical documentation and ensure the equipment meets the safety objectives in Annex I. - Then draw up the EU declaration of conformity and affix CE marking. ### [ACTION REQUIRED] Affix CE Marking and Draw Up EU DoC Required before placing on market - Before placing the equipment on the market, the manufacturer must draw up the EU declaration of conformity and affix CE marking. - Ensure CE marking is applied according to the LVD and general CE marking rules. ### [RESULT] Importer Compliance Achieved Equipment may be placed on EU market - You have verified manufacturer's conformity assessment, CE marking, and documentation. - You have added your identification to equipment. - You have ensured appropriate language instructions. - You may place equipment on the EU market. - Keep copy of EU DoC for 10 years and cooperate with market surveillance authorities. ### [RESULT] Distributor Compliance Achieved Equipment may be made available on market - You have verified CE marking and required documentation. - You have ensured storage/transport conditions maintain compliance. - You may make equipment available on the market. - Remain vigilant and cooperate with authorities if issues arise. ### [RESULT] Clarify Economic Operator Role Identify applicable obligations first - This flow covers manufacturer, importer, and distributor roles under the LVD. - If you act as an authorized representative, follow the written mandate and keep required documentation available for authorities. - If you rebrand the equipment or modify it in a way that may affect compliance, you may become the manufacturer with corresponding obligations. ### [RESULT] Out of Scope - Voltage Limits LVD does not apply - Your equipment is not designed for use within LVD voltage limits (50-1000V AC / 75-1500V DC). - LVD does not apply. - Other EU legislation may apply depending on equipment type. ### [RESULT] Out of Scope - Annex II Exclusion LVD does not apply - Your equipment is specifically excluded under Annex II. - LVD does not apply. - Other sector-specific EU legislation likely applies (e.g., ATEX for explosive atmospheres, Medical Device Regulation, Lifts Directive, Radio Equipment Directive). ## LVD Timeline | Date | Event | Reference | | --- | --- | --- | | 1973-02-19 | Original LVD (73/23/EEC) adopted | Council Directive 73/23/EEC | | 2006-12-12 | Codified LVD (2006/95/EC) adopted | Directive 2006/95/EC | | 2014-02-26 | Recast LVD (2014/35/EU) adopted | Directive 2014/35/EU | | 2014-03-29 | LVD 2014/35/EU published in Official Journal | OJ L 96 | | 2014-04-18 | LVD 2014/35/EU enters into force | Art. 28 | | 2016-04-19 | Transposition deadline for Member States | Art. 26 | | 2016-04-20 | LVD 2014/35/EU applies; Directive 2006/95/EC repealed | Art. 27 | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 1973-02-19 | Original LVD Adopted | Directive | | | 1974-08-21 | First Transposition Deadline | Implementation | | | 1985-05-07 | New Approach Resolution Approved | Framework & Guidance | | | 1995-01-01 | CE Marking Application | Implementation | | | 2000-01-01 | Blue Guide Published | Framework & Guidance | | | 2006-12-12 | LVD Codified | Directive | | | 2008-07-09 | New Legislative Framework Adopted | Framework & Guidance | | | 2012-10-25 | European Standardisation Regulation | Framework & Guidance | | | 2012-11-08 | Standardisation Request M/511 | Harmonized Standards | | | 2014-02-05 | European Parliament Position | Directive | | | 2014-02-20 | Council Decision on Recast LVD | Directive | | | 2014-02-26 | LVD Recast Adopted | Directive | | | 2014-02-26 | EMC Directive Recast Adopted | Related Directives | | | 2014-03-29 | LVD Recast Published | Directive | | | 2014-04-18 | LVD Recast Entry into Force | Directive | | | 2016-04-19 | Transposition Deadline | Implementation | | | 2016-04-20 | Application Date & Old Directive Repealed | Implementation | | | 2018-08-01 | LVD Guidelines Published | Framework & Guidance | | | 2019-06-20 | Market Surveillance Regulation Adopted | Framework & Guidance | | | 2019-10-01 | Interim Evaluation Study Published | Framework & Guidance | | | 2019-11-26 | Harmonised Standards Decision (2019/1956) Adopted | Harmonized Standards | | | 2019-11-27 | Harmonised Standards Decision (2019/1956) Published | Harmonized Standards | | | 2020-04-19 | Mutual Recognition Regulation Applies | Framework & Guidance | | | 2021-05-27 | Standards Withdrawal Date | Harmonized Standards | | | 2021-07-01 | LVD Evaluation SWD Published | Framework & Guidance | | | 2022-05-05 | Harmonised Standards Update Adopted (2022/713) | Harmonized Standards | | | 2022-05-10 | Harmonised Standards Update Published | Harmonized Standards | | | 2022-06-29 | Blue Guide 2022 Published | Framework & Guidance | | | 2023-11-10 | Harmonised Standards Update Applies (2022/713) | Harmonized Standards | | | 2024-04-19 | Harmonised Standards Update Adopted (2024/1198) | Harmonized Standards | | | 2024-10-30 | Harmonised Standards Update Adopted (2024/2764) | Harmonized Standards | | | 2024-10-31 | Harmonised Standards Update Published (2024/2764) | Harmonized Standards | | | 2025-07-16 | Harmonised Standards Update Adopted (2025/1457) | Harmonized Standards | | | 2025-07-22 | Harmonised Standards Update Adopted (2025/1488) | Harmonized Standards | | | 2025-07-23 | Harmonised Standards Update Published (2025/1488) | Harmonized Standards | | | 2025-10-24 | Harmonised Standards Update Applies (2024/1198) | Harmonized Standards | | | 2026-04-30 | Harmonised Standards Update Applies (2024/2764) | Harmonized Standards | | | 2027-01-18 | Harmonised Standards Update Applies (2025/1457) | Harmonized Standards | | | 2027-01-23 | Harmonised Standards Update Applies (2025/1488) | Harmonized Standards | | **Event details:** - **1973-02-19 - Original LVD Adopted**: Council Directive 73/23/EEC on harmonization of laws relating to electrical equipment for use within certain voltage limits (50-1000V AC, 75-1500V DC). - **1974-08-21 - First Transposition Deadline**: Time-limit for transposition for Directive 73/23/EEC: 21 August 1974 (with an extended deadline for Denmark). - **1985-05-07 - New Approach Resolution Approved**: Council Resolution on a new approach to technical harmonisation and standards approved (7 May 1985), focusing legislation on essential requirements and relying on harmonised standards for technical details. - **1995-01-01 - CE Marking Application**: Date of application for CE marking arrangements under Directive 93/68/EEC. - **2000-01-01 - Blue Guide Published**: The Blue Guide on the implementation of EU product rules was first published in 2000. - **2006-12-12 - LVD Codified**: Directive 2006/95/EC codifies the earlier LVD framework into a single text. - **2008-07-09 - New Legislative Framework Adopted**: Regulation (EC) No 765/2008 and Decision No 768/2008/EC adopted as part of the New Legislative Framework for product rules, accreditation, and market surveillance. - **2012-10-25 - European Standardisation Regulation**: Regulation (EU) No 1025/2012 on European standardisation adopted. - **2012-11-08 - Standardisation Request M/511**: Commission issues standardisation request M/511 to CEN, CENELEC and ETSI. - **2014-02-05 - European Parliament Position**: Position of the European Parliament of 5 February 2014 (not yet published in the Official Journal) during the recast procedure. - **2014-02-20 - Council Decision on Recast LVD**: Council decision of 20 February 2014 during the recast procedure. - **2014-02-26 - LVD Recast Adopted**: Directive 2014/35/EU adopted on 26 February 2014. - **2014-02-26 - EMC Directive Recast Adopted**: Directive 2014/30/EU (EMC Directive recast) adopted on 26 February 2014. - **2014-03-29 - LVD Recast Published**: Directive 2014/35/EU published in the Official Journal (29 March 2014). - **2014-04-18 - LVD Recast Entry into Force**: Directive 2014/35/EU entered into force on 18 April 2014 (as referenced in the LVD Guidelines timeline). - **2016-04-19 - Transposition Deadline**: Member States must adopt and publish national measures necessary to comply with key provisions of Directive 2014/35/EU by 19 April 2016. - **2016-04-20 - Application Date & Old Directive Repealed**: Directive 2014/35/EU applies from 20 April 2016; Directive 2006/95/EC is repealed with effect from the same date. - **2018-08-01 - LVD Guidelines Published**: Guidelines on the application of Directive 2014/35/EU published (August 2018 edition). - **2019-06-20 - Market Surveillance Regulation Adopted**: Regulation (EU) 2019/1020 on market surveillance and compliance of products adopted on 20 June 2019. - **2019-10-01 - Interim Evaluation Study Published**: Interim evaluation study of the Low Voltage Directive 2014/35/EU published (October 2019). - **2019-11-26 - Harmonised Standards Decision (2019/1956) Adopted**: Commission Implementing Decision (EU) 2019/1956 adopted on harmonised standards drafted in support of Directive 2014/35/EU. - **2019-11-27 - Harmonised Standards Decision (2019/1956) Published**: Commission Implementing Decision (EU) 2019/1956 published in the Official Journal (27 November 2019). - **2020-04-19 - Mutual Recognition Regulation Applies**: Regulation (EU) 2019/515 on mutual recognition applies from 19 April 2020. - **2021-05-27 - Standards Withdrawal Date**: Date of withdrawal referenced for a harmonised standard in the harmonised standards decision timeline extraction (27 May 2021). - **2021-07-01 - LVD Evaluation SWD Published**: Staff working document: evaluation of the Low Voltage Directive 2014/35/EU published (July 2021). - **2022-05-05 - Harmonised Standards Update Adopted (2022/713)**: Commission Implementing Decision (EU) 2022/713 (amending Decision (EU) 2019/1956) adopted (Done at Brussels, 5 May 2022). - **2022-05-10 - Harmonised Standards Update Published**: Harmonised standards update published (Legislation date 10 May 2022) for the Decision amending (EU) 2019/1956. - **2022-06-29 - Blue Guide 2022 Published**: Commission Notice 2022/C 247/01 (The ‘Blue Guide’ on the implementation of EU product rules 2022) published on 29 June 2022. - **2023-11-10 - Harmonised Standards Update Applies (2022/713)**: Certain provisions of Implementing Decision (EU) 2022/713 apply from 10 November 2023 (as reflected in the Official Journal issue timeline metadata). - **2024-04-19 - Harmonised Standards Update Adopted (2024/1198)**: Commission Implementing Decision (EU) 2024/1198 adopted (Done at Brussels, 19 April 2024), amending Implementing Decision (EU) 2023/2723 on harmonised standards for electrical equipment. - **2024-10-30 - Harmonised Standards Update Adopted (2024/2764)**: Commission Implementing Decision (EU) 2024/2764 adopted (Done at Brussels, 30 October 2024), amending Implementing Decision (EU) 2023/2723 on harmonised standards for electrical equipment. - **2024-10-31 - Harmonised Standards Update Published (2024/2764)**: Implementing Decision (EU) 2024/2764 published in the Official Journal on 31 October 2024. - **2025-07-16 - Harmonised Standards Update Adopted (2025/1457)**: Commission Implementing Decision (EU) 2025/1457 adopted (of 16 July 2025), amending Implementing Decision (EU) 2023/2723 on harmonised standards for electrical equipment. - **2025-07-22 - Harmonised Standards Update Adopted (2025/1488)**: Commission Implementing Decision (EU) 2025/1488 adopted (Done at Brussels, 22 July 2025), amending Implementing Decision (EU) 2023/2723 on harmonised standards for electrical equipment. - **2025-07-23 - Harmonised Standards Update Published (2025/1488)**: Implementing Decision (EU) 2025/1488 published in the Official Journal on 23 July 2025. - **2025-10-24 - Harmonised Standards Update Applies (2024/1198)**: Point (1) of Annex I of Implementing Decision (EU) 2024/1198 applies from 24 October 2025. - **2026-04-30 - Harmonised Standards Update Applies (2024/2764)**: Point (1) of the Annex of Implementing Decision (EU) 2024/2764 applies from 30 April 2026. - **2027-01-18 - Harmonised Standards Update Applies (2025/1457)**: Point (1) of the Annex of Implementing Decision (EU) 2025/1457 applies from 18 January 2027. - **2027-01-23 - Harmonised Standards Update Applies (2025/1488)**: Point (1) of the Annex of Implementing Decision (EU) 2025/1488 applies from 23 January 2027. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/low-voltage-directive --- --- title: "EU Machinery Regulation (EU) 2023/1230" canonical_url: "https://www.sorena.io/artifacts/eu/machinery-regulation" source_url: "https://www.sorena.io/artifacts/eu/machinery-regulation" author: "Sorena AI" description: "A practical EU Machinery Regulation artifact grounded in Regulation (EU) 2023/1230 and its corrigendum: entry into force on 19 July 2023." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Machinery Regulation" - "Regulation (EU) 2023/1230" - "machinery regulation compliance" - "machinery regulation scope" - "Annex I Part A Part B" - "Article 25 conformity assessment" - "machinery CE marking" - "machinery regulation digital instructions" - "machinery regulation software logging" - "machinery regulation substantial modification" - "Annex IV technical documentation" - "essential health and safety requirements Annex III" - "Machinery Regulation" - "Annex I" - "Article 25" - "CE marking" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Machinery Regulation (EU) 2023/1230 A practical EU Machinery Regulation artifact grounded in Regulation (EU) 2023/1230 and its corrigendum: entry into force on 19 July 2023. ![EU Machinery Regulation artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-machinery-timeline-small.jpg?v=cheatsheets%2Fprod) *Machinery* *Free Resource* ## EU Machinery Regulation Timeline and Decision Flow Use this artifact to confirm whether your product is in scope for Regulation (EU) 2023/1230, identify the Annex I category, and map the conformity assessment route you need for CE marking and technical documentation. Grounded in the corrigendum to Regulation (EU) 2023/1230: entry into force on 19 July 2023, application from 14 January 2027, with earlier-applying provisions and specific digital-document and software-evidence duties. [Assess Machinery Regulation scope](/artifacts/eu/machinery-regulation/applicability-test.md) ## What you can decide faster - **Scope and exclusions**: Confirm if the Machinery Regulation applies to your product. - **Annex I classification**: Check whether your product falls under Annex I Part A or Part B. - **Conformity route**: Decide between Module A and a notified body route based on Article 25. Entry into force 19 Jul 2023 | Applies 14 Jan 2027 | Updated Mar 2026 ### Quick scan *Machinery* - **Scope**: Confirm if the regulation applies to your product. - **Assessment**: Map your Article 25 conformity assessment route. - **CE readiness**: Plan technical file and declarations early. Use the decision flow to connect product facts to scope, Annex I route, software evidence, and digital-document controls you can actually operate. | Value | Metric | | --- | --- | | 19 Jul 2023 | Entry | | 14 Jan 2027 | Applies | | Annex I | Route | | Annex IV | Evidence | **Key highlights:** Scope first | Annex I mapping | CE evidence ## Topic Guides - [Applicability Test | EU Machinery Regulation (EU) 2023/1230 | In Scope? Annex I? Article 25 Route?](/artifacts/eu/machinery-regulation/applicability-test.md): A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery. - [Checklist | EU Machinery Regulation (EU) 2023/1230 | CE Marking Readiness Checklist (Route + Technical File + Declarations)](/artifacts/eu/machinery-regulation/checklist.md): An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2). - [Compliance Program | EU Machinery Regulation (EU) 2023/1230 | Operating Model, Controls, Transition to 2027](/artifacts/eu/machinery-regulation/compliance.md): Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control. - [Conformity Assessment and CE Marking | EU Machinery Regulation (EU) 2023/1230 | Article 25 Modules, Annex I, DoC/DoI](/artifacts/eu/machinery-regulation/conformity-assessment-and-ce.md): A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H. - [Deadlines and Compliance Calendar | EU Machinery Regulation (EU) 2023/1230 | Transition to 14 Jan 2027 + Route and Evidence Milestones](/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar.md): A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. - [FAQ | EU Machinery Regulation (EU) 2023/1230 | Scope, Annex I, Article 25, Technical File, Software](/artifacts/eu/machinery-regulation/faq.md): High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route. - [Machinery Regulation vs EU AI Act | Smart machinery, safety components, high-risk AI](/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act.md): A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6). - [Machinery Regulation vs Machinery Directive | Regulation (EU) 2023/1230 vs Directive 2006/42/EC | Key Changes + Migration Plan](/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive.md): A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates. - [Penalties and Fines | EU Machinery Regulation (EU) 2023/1230 | Article 50, Enforcement, Corrective Actions](/artifacts/eu/machinery-regulation/penalties-and-fines.md): A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline. - [Requirements | EU Machinery Regulation (EU) 2023/1230 | EHSR (Annex III), Technical File (Annex IV), Article 25 Route](/artifacts/eu/machinery-regulation/requirements.md): An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence. - [Risk Assessment Method | EU Machinery Regulation (EU) 2023/1230 | Annex III General Principles Workflow](/artifacts/eu/machinery-regulation/risk-assessment-method.md): A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles. - [Scope and Machine Categories | EU Machinery Regulation (EU) 2023/1230 | Machinery, Related Products, Partly Completed Machinery, Annex I](/artifacts/eu/machinery-regulation/scope-and-machine-categories.md): A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment. - [Software and Cybersecurity Considerations | EU Machinery Regulation (EU) 2023/1230 | Control Systems, Protection Against Corruption, Logs](/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations.md): A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption. - [Technical Documentation and Technical File | EU Machinery Regulation (EU) 2023/1230 | Annex IV Part A/B Checklist + Structure](/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file.md): A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping. - [Templates | EU Machinery Regulation (EU) 2023/1230 | Route Memo, Annex IV Technical File Index, DoC/DoI, Risk Assessment Mapping](/artifacts/eu/machinery-regulation/machinery-ce-documentation-template.md): Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note. - [Timeline and Transition | EU Machinery Regulation (EU) 2023/1230 | From Machinery Directive 2006/42/EC to 14 Jan 2027](/artifacts/eu/machinery-regulation/timeline-and-transition.md): A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. ## Key dates from adoption to mandatory application *Machinery Timeline* Track key milestones that affect planning, standards strategy, and transition from the Machinery Directive to the Machinery Regulation. ## Which compliance path applies to your machinery *Machinery Decision Flow* Use the decision flow to confirm scope, check Annex I, and map the Article 25 conformity assessment route, then translate outcomes into evidence and documentation tasks. *Next step* ## Turn EU Machinery Regulation Timeline and Decision Flow into an operational assessment workflow EU Machinery Regulation Timeline and Decision Flow should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU Machinery Regulation Timeline and Decision Flow and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for EU Machinery Regulation Timeline and Decision Flow. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share compliance logic with your team. - **Download timeline**: Coordinate milestones across teams. - [Talk through EU Machinery Regulation Timeline and Decision Flow](/contact.md): Review your current process, evidence model, and next steps for EU Machinery Regulation Timeline and Decision Flow. ## Decision Steps ### STEP 1: Is your product within the scope of the Machinery Regulation? *Reference: Art. 2(1)* - Regulation (EU) 2023/1230 applies to machinery, related products (interchangeable equipment, safety components, lifting accessories, chains/ropes/webbing, removable mechanical transmission devices) and partly completed machinery. - Check Article 2(2) exclusions before proceeding. - **NO** Out of Scope - **YES** Does an Article 2(2) exclusion apply to your product? ### STEP 2: Does an Article 2(2) exclusion apply to your product? *Reference: Art. 2(2)* - Review the full list of exclusions in Article 2(2). - If yes, the Machinery Regulation does not apply. - If no, continue to determine the product category and applicable requirements. - **YES** Out of Scope - **NO** Which product category applies? ### STEP 3: Which product category applies? - Machinery or related product: follow the full compliance track (Annex III requirements, technical documentation, conformity assessment, EU declaration of conformity, CE marking). - Partly completed machinery: follow the incorporation track (relevant Annex III requirements, technical documentation, EU declaration of incorporation, assembly instructions). - The category determines the applicable obligations and documentation. - -> Is your product machinery or a related product (not partly completed)? ### MACHINERY TRACK: Is your product machinery or a related product (not partly completed)? *Reference: Art. 2(1) and Art. 3* - Machinery is defined in Art. 3(1). - Related products are listed in Art. 2(1) and defined in Art. 3 (interchangeable equipment, safety components, lifting accessories, chains/ropes/webbing, removable mechanical transmission devices). - If yes: follow the machinery/related product compliance track. - If no: check if it is partly completed machinery. - **YES** Is your machinery/related product listed in Annex I? - **NO** Is your product partly completed machinery? ### PCM TRACK: Is your product partly completed machinery? *Reference: Art. 3(10)* - Partly completed machinery (PCM) is an assembly that is not yet machinery because it cannot in itself perform a specific application and is only intended to be incorporated into or assembled with other machinery/partly completed machinery or equipment. - If yes: follow the partly completed machinery track (notably Art. 11, Art. 22, Annex IV Part B, Annex V Part B, and Annex XI). - If no and not excluded: verify scope again or product may be a component not regulated by Machinery Regulation. - **YES** Partly Completed Machinery Track - **NO** Out of Scope ### STEP 4: Is your machinery/related product listed in Annex I? *Reference: Art. 25 & Annex I* - Annex I lists categories of machinery/related products requiring specific conformity assessment procedures. - Annex I Part A: 6 categories with mandatory notified body involvement (including AI/machine learning safety components/systems). - Annex I Part B: 19 categories where notified body involvement may be optional if harmonised standards or common specifications covering all relevant requirements are applied. - If not in Annex I: internal production control (Module A) applies (self-assessment). - If in Annex I: check which Part. - **NO** Module A - Internal Production Control - **YES** Is your product in Annex I Part A (mandatory notified body)? ### STEP 5: Is your product in Annex I Part A (mandatory notified body)? *Reference: Art. 25(2) & Annex I Part A* - Annex I Part A categories (6 total): (1) Removable mechanical transmission devices including guards; (2) Guards for removable mechanical transmission devices; (3) Vehicle servicing lifts; (4) Portable cartridge-operated fixing and other impact machinery; (5) Safety components with fully/partially self-evolving behaviour using machine learning ensuring safety functions; (6) Machinery with embedded systems using machine learning ensuring safety functions (for those systems only). - If yes: apply one of the Art. 25(2) procedures involving a notified body (Module B+C, Module H, or Module G). - If no: check if product is in Annex I Part B. - **YES** Notified Body Involvement Required - **NO** Is your product in Annex I Part B (optional notified body)? ### STEP 6: Is your product in Annex I Part B (optional notified body)? *Reference: Art. 25(3) & Annex I Part B* - Annex I Part B categories (19 total): (1) Circular saws for wood/meat; (2) Hand-fed surface planing machinery for woodworking; (3) Thicknessers; (4) Band-saws; (5) Combined machinery; (6) Hand-fed tenoning machinery; (7) Vertical spindle moulding machinery; (8) Portable chainsaws; (9) Presses for cold working metals; (10) Injection/compression plastics-moulding machinery; (11) Injection/compression rubber-moulding machinery; (12) Underground machinery; (13) Refuse collection trucks; (14) Devices for lifting persons (>3m); (15) Protective devices detecting presence of persons; (16) Power-operated interlocking movable guards; (17) Logic units ensuring safety functions; (18) ROPS; (19) FOPS. - If yes: you may apply Module A only when the product is designed and constructed in accordance with harmonised standards or common specifications specific to that category and covering all relevant essential health and safety requirements; otherwise apply one of the Art. 25(3)(b)-(d) procedures involving a notified body. - If no: Module A (internal production control) applies. - **YES** For Annex I Part B: Are harmonised standards or common specifications applied? - **NO** Module A - Internal Production Control ### STEP 7: For Annex I Part B: Are harmonised standards or common specifications applied? *Reference: Art. 20 & Art. 25(3)* - Harmonised standards are European standards cited in the Official Journal providing presumption of conformity with corresponding essential requirements (Art. 20(1)). - Common specifications may be established by Commission implementing acts where harmonised standards do not exist or are insufficient and for specific reasons (Art. 20(3)). - If harmonised standards or common specifications are applied and are specific to that category and cover all relevant essential health and safety requirements: Module A (self-assessment) may be used. - If not applied or do not cover all relevant requirements for that category: apply one of the Art. 25(3)(b)-(d) procedures involving a notified body. - **YES** Module A - Internal Production Control - **NO** Notified Body Involvement Required ## Reference Information ### Products Within Scope (Overview) - Machinery: defined in Art. 3(1) and includes assemblies with a drive system, assemblies missing only site-connection or energy sources, certain human-powered lifting assemblies, and assemblies missing only the software intended for the specific application. - Related products: interchangeable equipment, safety components, lifting accessories, chains/ropes/webbing, and removable mechanical transmission devices (Art. 2(1), with definitions in Art. 3). - Partly completed machinery: an assembly not yet machinery because it cannot in itself perform a specific application and is intended to be incorporated into or assembled with other machinery/partly completed machinery or equipment (Art. 3(10)). ### Key Exclusions - Art. 2(2) excludes certain products from the Regulation (for example: certain spare safety components, certain transport products, and certain electrical and electronic products covered by the LVD or RED). Review the full list in Art. 2(2). - Where risks covered by more specific Union harmonisation legislation apply, Machinery Regulation does not apply to that product for those risks (Art. 9). ### Manufacturer Obligations (Machinery & Related Products) - Ensure machinery/related product is designed and constructed in accordance with the essential health and safety requirements in Annex III (Art. 10(1)). - Before placing on the market or putting into service: draw up technical documentation (Annex IV Part A) and apply the relevant conformity assessment procedure (Art. 10(2) and Art. 25). - After conformity is demonstrated: draw up the EU declaration of conformity (Art. 21 and Annex V Part A) and affix the CE marking (Art. 24) (Art. 10(2)). - Keep technical documentation and the EU declaration of conformity available to market surveillance authorities for at least 10 years; provide source code or programming logic on reasoned request where necessary for checking compliance (Art. 10(3)). - Maintain procedures so series production remains in conformity; take account of changes in production/design and changes in harmonised standards/technical specifications/common specifications (Art. 10(4)). - Mark the machinery/related product with the required identification information, including year of construction (year the manufacturing process was completed) (Art. 10(5)). - Indicate manufacturer name/trade name or trademark and contact details (postal address plus website/email/other digital contact) (Art. 10(6)). - Provide instructions for use and the information set out in Annex III; digital instructions are permitted with conditions, and certain safety information must be provided in paper for non-professional users (Art. 10(7)). - Provide the EU declaration of conformity with the product or provide an internet address or machine-readable code where it can be accessed; digital EU declarations of conformity must remain accessible online for the expected lifetime and at least 10 years (Art. 10(8)). - Take corrective action for non-conformity or risk and inform authorities where required (Art. 10(9)). ### Manufacturer Obligations (Partly Completed Machinery) - Ensure PCM is designed and constructed in accordance with the relevant essential health and safety requirements in Annex III (Art. 11(1)). - Before placing on the market: draw up technical documentation (Annex IV Part B) and, where compliance is demonstrated in that documentation, draw up the EU declaration of incorporation (Art. 11(2) and Art. 22). - Keep technical documentation and the EU declaration of incorporation available to market surveillance authorities for at least 10 years; provide source code or programming logic on reasoned request where necessary for checking compliance (Art. 11(3)). - Maintain procedures so series production remains in conformity, taking account of changes in production/design and changes in harmonised standards/technical specifications/common specifications (Art. 11(4)). - Mark the PCM with the required identification information, including year of construction (year the manufacturing process was completed) (Art. 11(5)). - Indicate manufacturer name/trade name or trademark and contact details (postal address plus website/email/other digital contact) (Art. 11(6)). - Provide assembly instructions (Annex XI); digital assembly instructions are permitted with conditions (Art. 11(7)). - Provide the EU declaration of incorporation with the PCM or provide an internet address or machine-readable code where it can be accessed in the assembly instructions; digital EU declarations of incorporation must remain accessible online for at least 10 years (Art. 11(8)). ### Economic Operators Obligations - Authorised representative (Art. 12): manufacturer may appoint written authorised representative to act on behalf in EU; representative carries out tasks specified in mandate (min. keep EU declaration of conformity and technical documentation at disposal of market surveillance authorities; provide authorities with information/documentation; cooperate on action to eliminate risks). - Importers (Art. 13): place only conforming products on market; verify manufacturer compliance (CE marking, documentation, markings); add own name/address; ensure transport/storage does not jeopardise conformity; keep copy of EU declaration of conformity for 10 years; take corrective action for non-conforming/risky products. - Distributors (Art. 14): verify product bears CE marking, is accompanied by documentation, and bears required markings; ensure transport/storage does not jeopardise conformity; take corrective action if become aware of non-conformity/risk; cooperate with authorities. - Cases where obligations of manufacturers apply (Art. 17): importer/distributor/authorised representative who places product on market under own name/trademark or modifies product such that conformity may be affected becomes manufacturer. ### CE Marking and EU Declaration of Conformity - The CE marking must be affixed visibly, legibly and indelibly; it must be affixed before the machinery/related product is placed on the market or put into service (Art. 24(1)-(2)). - Where conformity is assessed under Art. 25(2)(a)-(c) or Art. 25(3)(b)-(d), the CE marking must be followed by the identification number of the notified body involved (Art. 24(3)). - General principles of the CE marking apply (Art. 23). - The EU declaration of conformity states that fulfilment of the applicable essential health and safety requirements in Annex III has been demonstrated (Art. 21(1)). - The EU declaration of conformity uses the model structure in Annex V Part A and contains elements specified in the relevant modules; it is continuously updated and translated into the language(s) required by the Member State (Art. 21(2)). - A single EU declaration of conformity may cover multiple Union legal acts if it identifies the acts concerned (Art. 21(3)). - By drawing up the EU declaration of conformity, the manufacturer assumes responsibility for compliance with the Regulation (Art. 21(4)). - Manufacturers must ensure the EU declaration of conformity accompanies the product or provide an internet address or machine-readable code where it can be accessed; digital EU declarations must remain accessible online during the expected lifetime and at least 10 years (Art. 10(8)). ### Essential Health and Safety Requirements - Annex III sets out essential health and safety requirements for design and construction of machinery and related products. - Annex III Part A: Definitions (hazard, danger zone, exposed person, operator, risk, guard, protective device, intended use, reasonably foreseeable misuse). - Annex III Part B: General principles - manufacturer must carry out risk assessment (identify limits, hazards, estimate risks, evaluate risks, eliminate/reduce risks by inherent safe design, technical protective measures, information for use) and design/construct accordingly. - Annex III Part C: General essential health and safety requirements (controls, starting, stopping, operating modes, risks from moving parts, required characteristics of guards/protective devices, risks from other hazards, maintenance, indications/markings/warnings, etc.). - Annex III Parts D-F: Supplementary requirements for certain categories (machinery for foodstuffs/cosmetics/pharmaceuticals; portable hand-held/hand-guided machinery; machinery for lifting operations). - Annex III Part G: Requirements to deal with hazards due to mobility of machinery. - Annex III Part H: Requirements for machinery designed to lift or move persons. - Requirements apply where relevant hazard exists for the machinery/related product concerned. ### AI, Digital and Cybersecurity Requirements - Annex I Part A items 5 and 6 cover certain safety components and embedded systems with fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions; these categories require a conformity assessment procedure involving a notified body (Art. 25(2)). - Annex II includes software ensuring safety functions (item 18) and safety components with fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions (item 19). - Annex III section 1.1.9 (protection against corruption) requires protection of critical hardware, software, and data against accidental or intentional corruption, including when connected to other devices or remote devices. - Annex III section 1.2.1 (safety and reliability of control systems) addresses faults and logic errors, and includes requirements related to reasonably foreseeable malicious attempts from third parties and safety-function limits during learning phases where relevant. - Art. 20(9) provides a presumption of conformity for Annex III sections 1.1.9 and 1.2.1 when a product is certified under certain EU cybersecurity certification schemes (Regulation (EU) 2019/881) to the extent covered by the certificate. ### Notified Bodies (Conformity Assessment) - Notifying authorities (Art. 27): Member States designate notifying authority responsible for notification procedures and monitoring of notified bodies; must be independent and impartial. - Requirements for notified bodies (Art. 30): legal person; independent and impartial; staff with technical competence and professional integrity; covered by liability insurance or Member State assumes liability; safeguards confidentiality; documented procedures. - Presumption of conformity (Art. 31): bodies demonstrating conformity with criteria in harmonised standards or accredited per Regulation (EC) No 765/2008 presumed to comply with Art. 30 requirements. - Application for notification (Art. 33): conformity assessment body applies to notifying authority with documentation demonstrating compliance. - Notification procedure (Art. 34): if body meets requirements, notifying authority notifies Commission (using electronic notification tool NANDO) and other Member States; Commission assigns identification number and publishes list. - Operational obligations (Art. 38): carry out conformity assessments per applicable procedures; avoid unnecessary burden; respect confidentiality; proportionate assessment; inform authorities of refusals/restrictions/suspensions/withdrawals; respond to requests; participate in coordination activities. - Changes to notifications (Art. 36): notified body informs notifying authority of changes affecting notification; authority assesses and may restrict/suspend/withdraw. ### Market Surveillance and Safeguards - Art. 43 sets out the national procedure for products presenting a risk and refers to corrective action as provided for in Art. 16(3) of Regulation (EU) 2019/1020. - Procedure at national level (Art. 43): if Member State finds non-complying product or product presenting risk, market surveillance authority requires economic operator to take corrective action; if risk persists, authority ensures product withdrawn/recalled or availability restricted/prohibited. - Union safeguard procedure (Art. 44): if Member State takes measures and considers action necessary EU-wide, informs Commission and other Member States; Commission assesses whether measure justified; if not justified, Member State must withdraw; if justified, all Member States take necessary measures. - Compliant products presenting risk (Art. 45): if compliant product still presents risk to health/safety, Member State may take provisional measures; inform Commission with justification; Commission evaluates and may adopt implementing acts. - Formal non-compliance (Art. 46): for non-compliance with formal obligations (CE marking, EU declaration of conformity, technical documentation, markings), Member State requires economic operator to end non-compliance; if persists, restrict/prohibit or ensure withdrawal/recall. ### Transition from Directive 2006/42/EC - Directive 2006/42/EC repealed with effect from 20 January 2027 (Art. 51(2)). - Member States must not impede making available on market of products placed on market in conformity with Directive 2006/42/EC before 20 January 2027 (Art. 52(1)). - However, Chapter VI (safeguard procedures) of Regulation (EU) 2023/1230 applies from 19 July 2023 onwards to products under Directive 2006/42/EC (Art. 52(1)). - EC type-examination certificates and approval decisions issued per Directive 2006/42/EC remain valid until they expire (Art. 52(2)). - From 20 January 2027, Regulation (EU) 2023/1230 applies (Art. 54) and replaces Directive 2006/42/EC (Art. 51(2)). ### Penalties and Enforcement - Member States must lay down rules on penalties for infringements by economic operators; penalties must be effective, proportionate and dissuasive; may include criminal penalties for serious infringements (Art. 50(1)). - Member States must notify the Commission of penalty rules and measures by 20 October 2026 and notify amendments without delay (Art. 50(2)). - Art. 54 specifies that Art. 50(1) applies from 20 October 2026. ### Evaluation and Review - Commission must submit report on evaluation and review by 20 July 2028 and every four years thereafter (Art. 53(1)). - Report must include evaluation of essential health and safety requirements (Annex III) and conformity assessment procedure applicable to machinery/related products in Annex I, taking account of technical progress and practical experience (Art. 53(2)). - Commission must submit specific report on assessment of Article 6(4) and (5) (categories of machinery/related products in Annex I and Member State data collection) by 20 July 2026 and every five years thereafter (Art. 53(3)). - The Commission is empowered to adopt delegated acts referred to in Articles 6(2), 6(11) and 7(2); the delegation is conferred for five years from 19 July 2023 and is tacitly extended unless the European Parliament or the Council opposes (Art. 47(2)). - Annex I can be amended by delegated acts in accordance with the criteria and procedure in Article 6 (e.g., adding, withdrawing, or moving categories between Part A and Part B). ### Internal Market Emergency Mode - Amending Regulation (EU) 2024/2748 (Internal Market Emergency and Resilience Act amendments) applies from 29 May 2026. - Once internal market emergency mode activated per Regulation (EU) 2024/2747, special procedures apply to crisis-relevant goods/services. - Conformity-assessment bodies must prioritise applications for conformity of crisis-relevant products over non-crisis products. - Member States may, on exceptional basis with duly justified request, temporarily authorise placing on market of machinery/related products/PCM without normal conformity assessment where notified body involvement mandatory, provided all essential requirements can be ensured. - Member States' authorities may presume conformity where products manufactured per EU standards, relevant national standards, or international standards identified by Commission as suitable. - Commission may adopt common specifications by implementing acts on which manufacturers can rely for presumption of conformity (remain applicable for duration of emergency mode). - These provisions aim to avoid disruptions to internal market in event of emergency (pandemic, natural disaster, etc.). ### Technical Documentation Requirements - Annex IV Part A (machinery/related products): technical documentation specifies the means used to ensure conformity with the applicable essential health and safety requirements in Annex III. - Annex IV Part A includes at least: product description and intended use; risk assessment documentation (including applicable EHSRs, protective measures and residual risks); drawings/schemes and explanations; standards/common specifications or other technical specifications applied; reports/results of calculations, tests and examinations; and production measures to ensure ongoing conformity. - Annex IV Part A also includes: copy of instructions for use and information set out in Annex III section 1.7.4; and, where appropriate, declarations/instructions for incorporated partly completed machinery and declarations for incorporated products subject to other Union harmonisation legislation. - Annex IV Part A may include source code or programming logic on reasoned request where necessary for authorities to check compliance; and includes additional descriptions for certain sensor-fed, remotely-driven, or autonomous machinery where relevant. - Annex IV Part B (partly completed machinery): similar structure tailored to PCM, including intended function when incorporated, risk assessment, drawings/explanations, applied standards/specifications, test results, production measures, and a copy of the assembly instructions set out in Annex XI. ### Instructions for Use and Safety Information - Manufacturers must ensure machinery/related products are accompanied by instructions for use and the information set out in Annex III; instructions may be provided in digital format subject to conditions, and certain safety information must be provided in paper for non-professional users (Art. 10(7)). - Annex III section 1.7.4 sets additional rules for drafting instructions for use and lists required contents (including, where applicable, the EU declaration of conformity or a link/code to access it in accordance with Art. 10(8)). - When instructions are provided digitally, Art. 10(7) sets conditions (including how users access them, ability to print/download, online accessibility during expected lifetime and at least 10 years after placing on the market, and provision of paper instructions on request within one month). - For partly completed machinery, manufacturers must provide assembly instructions set out in Annex XI; assembly instructions may be provided digitally subject to conditions and a paper copy must be provided on request within one month (Art. 11(7)). - For partly completed machinery, the EU declaration of incorporation must accompany the product or be accessible via an internet address or machine-readable code included in the assembly instructions (Art. 11(8) and Annex V Part B). ## Possible Outcomes ### [RESULT] Module A - Internal Production Control Self-assessment procedure - Apply internal production control (Module A) as set out in Annex VI. - Ensure the machinery/related product meets the applicable essential health and safety requirements in Annex III and compile the required technical documentation (Annex IV Part A). - Draw up the EU declaration of conformity (Annex V Part A) and affix the CE marking after conformity is demonstrated. - No notified body involvement is required. ### [RESULT] Notified Body Involvement Required Module B+C, Module H, or Module G - Annex I Part A categories: apply one of the Art. 25(2) procedures (Module B+C, Module H, or Module G). - Annex I Part B categories: if Module A cannot be used, apply one of the Art. 25(3)(b)-(d) procedures (Module B+C, Module H, or Module G). - Module B (EU type-examination) is set out in Annex VII; Module C (conformity to type based on internal production control) is set out in Annex VIII. - Module H (full quality assurance) is set out in Annex IX; Module G (unit verification) is set out in Annex X. - Affix the CE marking and draw up the EU declaration of conformity after conformity assessment is completed. ### [RESULT] Partly Completed Machinery Track EU declaration of incorporation + assembly instructions - Design and document the PCM against the relevant essential health and safety requirements in Annex III (Art. 11(1)). - Draw up technical documentation (Annex IV Part B) and the EU declaration of incorporation (Annex V Part B) (Art. 11(2) and Art. 22). - Provide assembly instructions (Annex XI) and include the EU declaration of incorporation or an internet address or machine-readable code where it can be accessed (Art. 11(7)-(8)). - The EU declaration of incorporation includes a statement that the PCM shall not be put into service until the final machinery has been declared in conformity with the Regulation (Annex V Part B). ### [RESULT] Out of Scope Machinery Regulation does not directly apply - Your product is not within the scope of Regulation (EU) 2023/1230, or an Article 2(2) exclusion applies. - Other Union harmonisation legislation or national requirements may still apply depending on the product. ## Machinery Regulation Timeline | Date | Event | Reference | | --- | --- | --- | | 2023-06-14 | Regulation (EU) 2023/1230 adopted | Reg. (EU) 2023/1230 | | 2023-06-29 | Published in Official Journal (OJ L 165) | Reg. (EU) 2023/1230 | | 2023-07-19 | Entry into force (20 days after publication) | Art. 54 | | 2023-07-19 | Article 6(7), Articles 48 and 52 apply | Art. 54 | | 2024-01-20 | Articles 26 to 42 (notified bodies) apply | Art. 54 | | 2024-07-20 | Article 6(2)-(6), (8), (11), Articles 47, 53(3) apply | Art. 54 | | 2026-10-20 | Member States notify penalties rules; Article 50(1) applies | Art. 50(2) & Art. 54 | | 2027-01-20 | Regulation fully applies; Directive 2006/42/EC repealed | Art. 51(2) & Art. 54 | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2006-05-17 | Machinery Directive 2006/42/EC Adopted | Legacy Directive | | | 2006-12-19 | Standardization Mandate M/396 Issued | Standards & Guidance | | | 2009-10-21 | Directive 2009/127/EC on Pesticide Machinery | Legacy Directive | | | 2010-06-29 | Standardization Mandate M/471 Issued | Standards & Guidance | | | 2019-07-26 | Latest Consolidated Machinery Directive | Legacy Directive | | | 2023-04-18 | European Parliament Position (First Reading) | Legislative Process | | | 2023-05-22 | Council Decision (Legislative Process) | Legislative Process | | | 2023-05-26 | CEN-CENELEC Machinery Webinar (Standardisation Q&A) | Standards & Guidance | | | 2023-06-14 | Machinery Regulation (EU) 2023/1230 Adopted | Legislative Process | | | 2023-06-29 | Regulation Published in Official Journal | Legislative Process | | | 2023-07-04 | Corrigendum Published | Legislative Process | | | 2023-07-19 | Regulation Enters into Force | Application Dates | | | 2024-01-20 | Notified Bodies Provisions Apply | Application Dates | | | 2024-02-23 | CEN-CENELEC Gap Analysis Webinar | Standards & Guidance | | | 2024-06-13 | Machinery Directive Guide Edition 2.3 Published | Standards & Guidance | | | 2024-07-20 | Category Review and Data Collection Provisions Apply | Application Dates | | | 2025-01-20 | Standardization Request C(2025) 129 Adopted | Standards & Guidance | | | 2025-07-20 | First Member State data submission deadline | Implementation | | | 2025-07-20 | Draft Joint Work Programme Due | Standards & Guidance | | | 2026-01-20 | Standards Amendment Status Report Due | Standards & Guidance | | | 2026-01-20 | Standardisation Request Priority Deliverables Target | Standards & Guidance | | | 2026-03-31 | Draft Standards (DAV) Window Ends | Standards & Guidance | | | 2026-05-29 | Emergency Procedures Regulation Applies | Legislative Process | | | 2026-07-20 | First Joint Annual Report Due | Standards & Guidance | | | 2026-10-20 | Penalties Provisions Apply; Member State Notification Due | Application Dates | | | 2027-01-20 | Machinery Regulation Mandatory Application Begins | Application Dates | | | 2027-01-20 | Machinery Directive 2006/42/EC Repealed | Transition Period | | | 2028-07-20 | First Evaluation Report Due | Implementation | | | 2034-01-20 | Standardisation Request Follow Up Deliverables Target | Standards & Guidance | | | 2035-01-20 | Standardization Request Final Report and Expiry | Standards & Guidance | | **Event details:** - **2006-05-17 - Machinery Directive 2006/42/EC Adopted**: Directive 2006/42/EC on machinery adopted, establishing harmonized rules for machinery safety requirements across the EU. This directive served as the foundation for machinery regulation for over 20 years. - **2006-12-19 - Standardization Mandate M/396 Issued**: Commission issued Mandate M/396 to CEN and CENELEC to check and adjust harmonized standards to ensure full compliance with Directive 2006/42/EC and provide specifications for manufacturers. - **2009-10-21 - Directive 2009/127/EC on Pesticide Machinery**: Directive 2009/127/EC adopted, amending Directive 2006/42/EC with regard to machinery for pesticide application, introducing new essential health and safety requirements. - **2010-06-29 - Standardization Mandate M/471 Issued**: Commission issued Mandate M/471 to CEN to develop harmonized standards supporting new essential health and safety requirements for environmental protection in Directive 2006/42/EC. - **2019-07-26 - Latest Consolidated Machinery Directive**: Final consolidated version of Machinery Directive 2006/42/EC published, incorporating all amendments and corrections before the transition to the new Regulation. - **2023-04-18 - European Parliament Position (First Reading)**: European Parliament position adopted on 18 April 2023 during the legislative process for Regulation (EU) 2023/1230 (as referenced in the Regulation text timeline metadata). - **2023-05-22 - Council Decision (Legislative Process)**: Council decision dated 22 May 2023 referenced in the Regulation text timeline metadata as part of the legislative process leading to Regulation (EU) 2023/1230. - **2023-05-26 - CEN-CENELEC Machinery Webinar (Standardisation Q&A)**: CEN-CENELEC webinar held on 26 May 2023 on the transition to the Machinery Regulation and related standardisation topics (per Q&A report timeline metadata). - **2023-06-14 - Machinery Regulation (EU) 2023/1230 Adopted**: European Parliament and Council adopted Regulation (EU) 2023/1230 on machinery, repealing Directive 2006/42/EC and Council Directive 73/361/EEC. - **2023-06-29 - Regulation Published in Official Journal**: Regulation (EU) 2023/1230 published in the Official Journal of the European Union (OJ L 165, 29.6.2023, pp. 1-102), making it the authentic legal text. - **2023-07-04 - Corrigendum Published**: Corrigendum issued to address a clerical error regarding application dates in the original version of the Regulation (OJ L 169, 4.7.2023, p. 35). - **2023-07-19 - Regulation Enters into Force**: Regulation (EU) 2023/1230 entered into force. Article 6(7), Article 48 (committee procedure), and Article 52 (transitional provisions) apply from this date. Delegated powers conferred for 5 years. - **2024-01-20 - Notified Bodies Provisions Apply**: Articles 26 to 42 apply from this date, establishing the framework for notification, requirements, and operational obligations of conformity assessment bodies. - **2024-02-23 - CEN-CENELEC Gap Analysis Webinar**: CEN-CENELEC hosted webinar on gap-analysis of harmonized standards for Machinery against the new Regulation, explaining alignment process and tools for standards bodies. - **2024-06-13 - Machinery Directive Guide Edition 2.3 Published**: European Commission externalized/published the Guide to the application of the Machinery Directive 2006/42/EC, Edition 2.3 (per docsroom metadata). - **2024-07-20 - Category Review and Data Collection Provisions Apply**: Article 6(2)-(6), (8), and (11) apply, enabling Commission category review and Member State data collection. Articles 47 and 53(3) also apply, and the first implementing act for the Article 6 data collection template must be adopted not later than 20 July 2024. - **2025-01-20 - Standardization Request C(2025) 129 Adopted**: Commission Implementing Decision C(2025) 129 final adopted, issuing standardization request to CEN and CENELEC for machinery and related products in support of Regulation (EU) 2023/1230. - **2025-07-20 - First Member State data submission deadline**: By 20 July 2025 (and every five years thereafter), Member States must provide the Article 6(5) data and information for categories of machinery or related products (including when no relevant events occurred). - **2025-07-20 - Draft Joint Work Programme Due**: CEN and CENELEC must submit draft joint work programme to the Commission for developing harmonized standards under the new Regulation. - **2026-01-20 - Standards Amendment Status Report Due**: CEN and CENELEC must inform the Commission of references of harmonized standards from Decision (EU) 2023/1586 that will not be amended or revised, and reasons why. - **2026-01-20 - Standardisation Request Priority Deliverables Target**: Standardisation request annexes include a priority deadline of 20 January 2026 for deliverables aligning existing or potential harmonised standards identified through gap analysis. - **2026-03-31 - Draft Standards (DAV) Window Ends**: CEN webinar Q&A report references draft standards to be published (DAV) between mid-2024 and 31 March 2026 to support both the Machinery Directive and Machinery Regulation transition (with dual Annex ZA references). - **2026-05-29 - Emergency Procedures Regulation Applies**: Amending Regulation (EU) 2024/2748 applies, adding internal market emergency mode provisions to enable rapid market placement of crisis-relevant machinery during emergencies. - **2026-07-20 - First Joint Annual Report Due**: CEN and CENELEC must submit the first joint annual report to the Commission on progress in developing harmonized standards under the standardization request. - **2026-10-20 - Penalties Provisions Apply; Member State Notification Due**: Article 50(1) (penalties) applies from this date, and Member States must notify the Commission of their penalties rules and measures by this date (Article 50(2)). - **2027-01-20 - Machinery Regulation Mandatory Application Begins**: Regulation (EU) 2023/1230 applies on a mandatory basis. All machinery placed on the EU market from this date must comply with the new Regulation. Directive 2006/42/EC is repealed. Mandates M/396 and M/471 expire. - **2027-01-20 - Machinery Directive 2006/42/EC Repealed**: Directive 2006/42/EC formally repealed. Products placed on the market before this date in conformity with the Directive may continue to be made available. Safeguard procedures under Chapter VI apply to such products. - **2028-07-20 - First Evaluation Report Due**: Commission must submit the first report on evaluation and review of Regulation (EU) 2023/1230 to the European Parliament and Council. Reports required every 4 years thereafter. - **2034-01-20 - Standardisation Request Follow Up Deliverables Target**: Standardisation request annexes include a follow up deadline of 20 January 2034 for standards and other deliverables aligning existing or potential harmonised standards identified through gap analysis. - **2035-01-20 - Standardization Request Final Report and Expiry**: CEN and CENELEC must provide final report to the Commission. Commission Implementing Decision C(2025) 129 final on standardization request expires on this date. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/machinery-regulation --- --- title: "EU Market Surveillance Regulation (EU) 2019/1020" canonical_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation" source_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation" author: "Sorena AI" description: "A practical EU Market Surveillance Regulation artifact grounded in Regulation (EU) 2019/1020 and current Commission materials." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Market Surveillance Regulation" - "Regulation (EU) 2019/1020" - "Article 4 economic operator" - "Article 6 distance sales" - "Article 14 online enforcement powers" - "Article 25 customs controls" - "Article 26 suspension of release" - "Article 34 ICSMS" - "Union Product Compliance Network" - "MSR compliance" - "Market surveillance" - "MSR" - "Enforcement" - "Compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Market Surveillance Regulation (EU) 2019/1020 A practical EU Market Surveillance Regulation artifact grounded in Regulation (EU) 2019/1020 and current Commission materials. ![EU Market Surveillance Regulation artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-msr-timeline-small.jpg?v=cheatsheets%2Fprod) *MSR* *Free Resource* ## EU Market Surveillance Regulation (EU) 2019/1020 A practical enforcement guide for EU product compliance: how market surveillance works, what authorities can ask for, how customs and online enforcement interact, and how to stay inspection-ready across online and offline channels. Grounded in Regulation (EU) 2019/1020, the 2021 Article 4 guidance notice, the 2025 Article 4 implementation report, and Commission market-surveillance materials. [Get MSR readiness review](/contact.md) ## What you can decide faster - **Whether MSR triggers**: Distance sales targeting, operator setup, and channel exposure. - **Who must act**: Manufacturer vs importer vs authorised representative vs fulfilment service provider. - **What to show**: DoC/technical documentation retrieval, logs, tests, and corrective actions. Early apply 1 Jan 2021 | Applies 16 Jul 2021 | Updated Mar 2026 ### Quick scan *MSR* - **Economic operator duties**: Article 4 tasks and what to label on product/parcel. - **Online sales targeting**: When an offer is "made available" in the EU (Article 6). - **Investigations + corrective action**: Evidence requests, withdrawals/recalls, and serious risk handling. Use the decision flow to connect Article 4 setup, online targeting, customs controls, and evidence retrieval into one enforcement-ready operating model. | Value | Metric | | --- | --- | | 1 Jan 2021 | Early apply | | 16 Jul 2021 | Applies | | Art. 4 | Operator | | Art. 25 | Customs | **Key highlights:** Article 4 duties | Online sales | Inspection-ready evidence ## Topic Guides - [Authority request response playbook | EU Market Surveillance Regulation (EU) 2019/1020 | Evidence requests, corrective action](/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook.md): An operational playbook for responding to authority requests under Regulation (EU) 2019/1020: first-24-hour triage, Article 4 evidence packs. - [Enforcement powers and penalties | EU MSR (Regulation (EU) 2019/1020) | Checks, serious risk, penalties](/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties.md): A practical enforcement guide for Regulation (EU) 2019/1020 covering Article 11 risk-based checks, Article 14 authority powers. - [EU Market Surveillance Regulation applicability test | Regulation (EU) 2019/1020 scope, Article 6 distance sales](/artifacts/eu/market-surveillance-regulation/applicability-test.md): A practical applicability test for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU Market Surveillance Regulation requirements | Regulation (EU) 2019/1020 (MSR) obligations](/artifacts/eu/market-surveillance-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2019/1020 covering Article 4 EU economic-operator tasks, Article 6 distance-sales targeting. - [EU MSR Article 4 economic operator duties and responsible-person setup | Regulation (EU) 2019/1020](/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties.md): A practical guide to Article 4 of Regulation (EU) 2019/1020: when an EU economic operator is required, who can act, what Article 4(3) tasks they perform. - [EU MSR checklist | Regulation (EU) 2019/1020 compliance checklist for inspections](/artifacts/eu/market-surveillance-regulation/checklist.md): An audit-ready checklist for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting and distance sales (Article 6). - [EU MSR compliance program | Regulation (EU) 2019/1020 implementation guide](/artifacts/eu/market-surveillance-regulation/compliance.md): A practical implementation guide for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU MSR deadlines and compliance calendar | Regulation (EU) 2019/1020 key dates (Article 44, Article 41)](/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar.md): Key dates for Regulation (EU) 2019/1020 covering early application from 1 January 2021 for Articles 29 to 33 and 36, general application from 16 July 2021. - [EU MSR FAQ | Regulation (EU) 2019/1020 questions (Article 4, Article 6, investigations)](/artifacts/eu/market-surveillance-regulation/faq.md): Answers to common questions about the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting (Article 6). - [EU MSR penalties and fines | Article 41 penalties (Regulation (EU) 2019/1020) | Reduce exposure](/artifacts/eu/market-surveillance-regulation/penalties-and-fines.md): Penalty exposure under Regulation (EU) 2019/1020: what Article 41 requires, why penalties differ by Member State. - [Investigations and evidence requests | EU Market Surveillance Regulation (EU) 2019/1020 | What authorities check](/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests.md): A practical guide to MSR investigations under Regulation (EU) 2019/1020 covering Article 11 risk-based checks. - [Market surveillance for online marketplaces | EU MSR (Regulation (EU) 2019/1020) | Operator controls](/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces.md): A practical guide for online marketplaces under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 7(2) cooperation. - [MSR vs GPSR | Market Surveillance Regulation (EU) 2019/1020 vs General Product Safety Regulation (EU) 2023/988](/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr.md): A grounded comparison of Regulation (EU) 2019/1020 and Regulation (EU) 2023/988: MSR as the enforcement and coordination framework. - [Online sales under the EU Market Surveillance Regulation | Article 6 distance sales + ecommerce controls](/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces.md): A practical guide for ecommerce sellers under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 4 operator identification. - [What changes with EU market surveillance | Regulation (EU) 2019/1020 (MSR) practical impact](/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes.md): A practical 'what changed' guide for Regulation (EU) 2019/1020: stronger EU-wide coordination, explicit online/distance sales targeting logic (Article 6). ## Key dates for enforcement planning *MSR Timeline* Track entry into application, staged application for some chapters, and review milestones that affect market surveillance activity and compliance strategy. ## How does the MSR affect your operations *MSR Decision Flow* Use the decision flow to identify applicable obligations and evidence expectations, then translate outcomes into readiness actions and response playbooks. *Next step* ## Turn EU Market Surveillance Regulation (EU) 2019/1020 into an operational assessment workflow EU Market Surveillance Regulation (EU) 2019/1020 should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU Market Surveillance Regulation (EU) 2019/1020 and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for EU Market Surveillance Regulation (EU) 2019/1020. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share operational logic internally. - **Download timeline**: Align milestones across your team. - [Talk through EU Market Surveillance Regulation (EU) 2019/1020](/contact.md): Review your current process, evidence model, and next steps for EU Market Surveillance Regulation (EU) 2019/1020. ## Decision Steps ### STEP 1: Is your product subject to Union harmonisation legislation listed in Annex I of Regulation (EU) 2019/1020? *Reference: Art. 2(1)* - MSR applies to products subject to Union harmonisation legislation listed in Annex I, unless specific provisions in that legislation regulate market surveillance more specifically. - Union harmonisation legislation includes Directives and Regulations covering machinery, PPE, construction products, toys, radio equipment, measuring instruments, ATEX, EMC, pressure equipment, and more. - **NO** Out of MSR Scope - **YES** Which type of economic operator are you? ### STEP 2: Which type of economic operator are you? *Reference: Art. 3(8)-(11), Art. 4* - Economic operator means manufacturer, authorised representative, importer, distributor, fulfilment service provider, or any other natural or legal person subject to obligations under Union harmonisation legislation. - Article 4 applies only to products subject to specific legislation listed in Article 4(5) (including Regulations (EU) No 305/2011, (EU) 2016/425, (EU) 2016/426, (EU) 2023/1542, (EU) 2024/1252 and Directives 2000/14/EC, 2006/42/EC, 2009/48/EC, 2009/125/EC, 2011/65/EU, 2013/29/EU, 2013/53/EU, 2014/29-35/EU, 2014/53/EU, 2014/68/EU). - -> Is your product subject to the legislation listed in Article 4(5)? ### STEP 3: Is your product subject to the legislation listed in Article 4(5)? *Reference: Art. 4(5)* - Article 4 requires an EU-based economic operator only for products subject to the Union harmonisation legislation listed in Article 4(5). - If your product is subject to other Union harmonisation legislation in Annex I but not listed in Article 4(5), Article 4 does not apply (but other MSR obligations may apply). - Article 4(5) legislation includes construction products, PPE, gas appliances, batteries, critical raw materials, outdoor noise, machinery, toys, ecodesign, RoHS, pyrotechnics, recreational craft, simple pressure vessels, EMC, measuring instruments, ATEX, low voltage, radio equipment, and pressure equipment. - **NO** Article 4 Does Not Apply - **YES** Is the manufacturer established in the EU? ### STEP 4: Is the manufacturer established in the EU? - Manufacturer established in the Union: the manufacturer is the economic operator referred to in Article 4 (unless it has appointed an authorised representative for Article 4(3) tasks). - Manufacturer not established in the Union: the importer (if established in the Union) is the economic operator referred to in Article 4, unless the manufacturer has appointed an authorised representative or a fulfilment service provider handles the product. - **YES** EU Manufacturer - **NO** Has the manufacturer appointed an authorised representative in the Union? ### STEP 5: Has the manufacturer appointed an authorised representative in the Union? *Reference: Art. 4(2)(c), Art. 5* - An authorised representative must be established in the Union and hold a written mandate from the manufacturer to perform the tasks in Article 4(3). - The authorised representative must provide a copy of the mandate to market surveillance authorities upon request (Art. 5(2)). - Authorised representatives must have appropriate means to fulfil their tasks (Art. 5(3)). - **YES** Authorised Representative is the Economic Operator - **NO** Is there an importer established in the Union? ### STEP 6: Is there an importer established in the Union? *Reference: Art. 4(2)(b)* - Importer means any natural or legal person established within the Union who places a product from a third country on the Union market (Art. 3(9)). - If the manufacturer is not established in the Union and has not appointed an authorised representative, the importer becomes the economic operator referred to in Article 4. - **YES** Importer is the Economic Operator - **NO** Is there a fulfilment service provider established in the Union handling the products? ### STEP 7: Is there a fulfilment service provider established in the Union handling the products? *Reference: Art. 4(2)(d), Art. 3(11)* - Fulfilment service provider means any person offering, in the course of commercial activity, at least two of the following: warehousing, packaging, addressing, dispatching (excluding postal and parcel delivery services) (Art. 3(11)). - Where no manufacturer, importer, or authorised representative is established in the Union, the fulfilment service provider is the economic operator referred to in Article 4. - **YES** Fulfilment Service Provider is the Economic Operator - **NO** Non-Compliant with Article 4 ## Reference Information ### MSR Scope (Overview) - Regulation (EU) 2019/1020 applies to products subject to Union harmonisation legislation listed in Annex I (machinery, PPE, construction products, toys, radio equipment, low voltage, measuring instruments, ATEX, EMC, recreational craft, pressure equipment, ecodesign, energy labelling, etc.). - MSR covers both online and offline distribution channels (distance sales deemed to be making available if targeted at EU end users). - Market surveillance authorities (MSAs) designated by Member States ensure products comply with Union harmonisation legislation and protect public interests (health, safety, environment, public security). - MSR establishes Article 4 obligations for economic operators: EU-based responsible person required for products subject to specified legislation (listed in Article 4(5)). - Border controls and customs cooperation framework under Chapter VII ensure non-compliant products are stopped at the Union border. ### Article 4 Tasks (EU-Based Economic Operator) - Verify that EU declaration of conformity or declaration of performance and technical documentation have been drawn up; keep declaration at disposal of market surveillance authorities; ensure technical documentation can be made available upon request (Art. 4(3)(a)). - Following a reasoned request from a market surveillance authority, provide all information and documentation necessary to demonstrate product conformity in a language easily understood by the authority (Art. 4(3)(b)). - When having reason to believe a product presents a risk, inform market surveillance authorities (Art. 4(3)(c)). - Cooperate with market surveillance authorities; following a reasoned request, take immediate necessary corrective action to remedy non-compliance or mitigate risks when required by authorities or on own initiative (Art. 4(3)(d)). - Indicate name, registered trade name or trade mark, and contact details including postal address on the product or packaging/parcel/accompanying document (Art. 4(4)). ### Distance Sales (Online and Offline) - Products offered for sale online or through other distance sales are deemed to be made available on the market if the offer is targeted at end users in the Union (Art. 6). - An offer is considered targeted at end users in the Union if the economic operator directs its activities to a Member State by any means (Art. 6). - Information society service providers must cooperate with market surveillance authorities to facilitate action against products presenting risks offered for sale online (Art. 7(2)). ### Market Surveillance Authority Powers - Member States designate market surveillance authorities and confer powers to enforce Union harmonisation legislation (Art. 10, Art. 14). - MSA powers include: requiring documents/data/information (including access to embedded software); requiring supply chain and distribution network information; carrying out unannounced on-site inspections and physical checks; entering premises; starting investigations on own initiative; requiring economic operators to take corrective action; prohibiting/restricting making available, ordering withdrawal or recall; imposing penalties; acquiring samples (including under cover identity); reverse-engineering; requiring removal of online content or restricting access to online interfaces (Art. 14(4)). - MSAs exercise powers efficiently, effectively, and in accordance with the principle of proportionality (Art. 14(2)). - MSAs may reclaim costs of their activities from the relevant economic operator in instances of non-compliance (Art. 15). ### Market Surveillance Measures - MSAs take appropriate measures if a product is liable to compromise health or safety or does not conform to Union harmonisation legislation (Art. 16(1)). - MSAs require the relevant economic operator to take appropriate and proportionate corrective action within a specified period (Art. 16(2)). - Corrective action may include: bringing the product into compliance; preventing the product from being made available; withdrawing or recalling the product; warning end users; destroying the product (Art. 16(3)). - If the economic operator fails to take corrective action or the non-compliance or risk persists, market surveillance authorities ensure the product is withdrawn or recalled, or that making available is prohibited or restricted (Art. 16(5)). ### Products Presenting a Risk - Product presenting a risk means a product that could adversely affect health, safety, environment, public security, or other public interests to a degree beyond what is reasonable and acceptable (Art. 3(19)). - Product presenting a serious risk requires rapid intervention by MSAs (may include cases where effects are not immediate) (Art. 3(20)). - Where a market surveillance authority takes or intends to take a measure pursuant to Article 19 and considers that the reasons or effects go beyond its Member State, it notifies the Commission immediately (Art. 20(1)). - MSAs must take measures to prohibit or restrict making available of products presenting a serious risk, and where applicable order withdrawal or recall (Art. 19). - Economic operators must cooperate to eliminate or mitigate risks presented by products they made available (Art. 7). ### RAPEX (Rapid Information Exchange System) - When a market surveillance authority takes or intends to take a measure pursuant to Article 19 and considers that the reasons or effects go beyond its Member State, it notifies the Commission (Art. 20(1)). - If a product presenting a serious risk has been made available on the market, market surveillance authorities notify the Commission of any voluntary measures taken and communicated by an economic operator (Art. 20(2)). - Notifications include available details needed for identification of the product, origin and supply chain, risk, and the nature and duration of national measures (Art. 20(3)). - For Article 20 notifications, the Rapid Information Exchange System (RAPEX) provided for in Article 12 of Directive 2001/95/EC is used (Art. 20(4)). - The Commission maintains a data interface between RAPEX and the information and communication system referred to in Article 34 to avoid double data entry (Art. 20(5)). ### Union Safeguard Clause Procedure - The MSR is without prejudice to Union safeguard procedures under the applicable Union harmonisation legislation (Art. 11(9), Art. 16(6)). - National measures communicated under Article 16(5) are communicated through the information and communication system referred to in Article 34, and that communication is deemed to fulfil notification requirements for applicable safeguard procedures (Art. 16(6)). - Products deemed non-compliant by a decision of a market surveillance authority in one Member State are presumed non-compliant by authorities in other Member States unless a relevant authority concludes the contrary on the basis of its own investigation (Art. 11(9)). - Market surveillance authorities enter relevant safeguard-related information in the information and communication system, including objections raised by a Member State and subsequent follow-up (Art. 34(4)(e)). ### Customs Controls and Border Checks - Member States designate authorities to perform controls on products entering the Union market (Art. 25). - Designated authorities perform risk-based checks on products intended for release for free circulation, prioritising products presenting a serious risk or significant levels of non-compliance (Art. 25(3)). - Where designated authorities identify non-compliance or a serious risk, they immediately inform the market surveillance authority and suspend release for free circulation (Art. 26). - Where release for free circulation has been suspended, the product is released where the other requirements are fulfilled and either the suspension is not maintained within four working days, or approval is given by market surveillance authorities (Art. 27). - Where placing on the market is prohibited, MSA requires designated authorities not to release the product and to include notice on commercial invoice and in customs data-processing system (Art. 28). - Cooperation between customs and market surveillance authorities is critical to prevent non-compliant products from entering the Union market. ### Union Product Compliance Network (EUPCN) - The Union Product Compliance Network (Network) coordinates market surveillance activities and ensures consistent enforcement across Member States (Art. 29). - Network consists of representatives of market surveillance authorities, the single liaison offices, and the Commission (Art. 30(1)). - Network tasks include: developing best practices; facilitating cooperation and exchange of information; coordinating joint activities; developing work programmes; providing opinions; contributing to consistent application of MSR (Art. 31). - Administrative Cooperation Groups (ADCOs) established for sectors support the Network and coordinate market surveillance in specific sectors (Art. 30(2)). - Network decisions are legally non-binding recommendations (Art. 31(3)). ### Mutual Assistance and Information Sharing - Market surveillance authorities cooperate and exchange information across Member States (Art. 22(1)). - On a reasoned request for information under Article 22, the requested authority supplies relevant information without delay and in any event within 30 days (Art. 22(2)). - Where bringing non-compliance to an end requires measures within another Member State, an applicant authority may submit a reasoned request for enforcement measures, and the requested authority takes appropriate enforcement measures using Article 14 powers (Art. 23). - Requests and related communication use electronic standard forms via the information and communication system referred to in Article 34 (Art. 24(3)). - Evidence used by a market surveillance authority in one Member State may be used by authorities in another Member State without further formal requirements (Art. 11(6)). - Products deemed non-compliant by a decision in one Member State are presumed non-compliant in other Member States unless a relevant authority concludes the contrary on the basis of its own investigation (Art. 11(9)). ### Union Testing Facilities - Union testing facilities aim to enhance laboratory capacity and ensure reliable and consistent testing for market surveillance (Art. 21(1)). - The Commission may designate a public testing facility of a Member State or one of its own testing facilities as a Union testing facility for specific categories of products or specific risks (Art. 21(2)). - Union testing facilities are accredited in accordance with Regulation (EC) No 765/2008 (Art. 21(3)). - Designated Union testing facilities provide services solely to market surveillance authorities, the Network, the Commission and other government or intergovernmental entities (Art. 21(5)). - Union testing facilities can carry out testing at the request of market surveillance authorities, the Network or the Commission, provide independent technical or scientific advice to the Network, and develop new techniques and methods of analysis (Art. 21(6)). ### National Market Surveillance Strategies - Each Member State draws up an overarching national market surveillance strategy at least every four years (Art. 13(1)). - First strategy was due by 16 July 2022; first evaluation by 16 July 2024 (Art. 13(1)). - National strategy includes: information on occurrence of non-compliant products; priority enforcement areas; planned enforcement activities; assessment of cooperation with other Member States (Art. 13(2)). - Member States communicate their strategy to the Commission and other Member States via the information and communication system and publish a summary (Art. 13(3)). ### Penalties and Enforcement - Member States lay down penalties for infringements of the MSR and of the Union harmonisation legislation listed in Annex II that impose obligations on economic operators (Art. 41(1)). - Penalties must be effective, proportionate, and dissuasive (Art. 41(2)). - Member States notify the Commission of penalty provisions by 16 October 2021 and notify subsequent amendments without delay (Art. 41(3)). - Market surveillance authorities have the power to impose penalties in accordance with Article 41 (Art. 14(4)(i)). ### Joint Activities to Promote Compliance - MSAs may agree with other authorities or organisations representing economic operators or end users on joint activities to promote compliance, identify non-compliance, raise awareness, and provide guidance (Art. 9(1)). - Joint activities must not lead to unfair competition and must preserve objectivity, independence, and impartiality (Art. 9(2)). - MSAs may use information from joint activities in investigations (Art. 9(3)). - Agreements on joint activities must be made publicly available and entered in the information and communication system (Art. 9(4)). ### Information to Economic Operators - The Commission ensures the Your Europe portal provides easy online access to information on product requirements, rights, obligations, and rules under Union harmonisation legislation (Art. 8(1)). - Member States put in place procedures to provide economic operators, at their request and free of charge, with information on national transposition and implementation of Union harmonisation legislation (Art. 8(2)). ### Peer Reviews - Peer reviews are organised for market surveillance authorities to strengthen consistency in market surveillance activities (Art. 12). - The Network develops methodology and a rolling plan for peer reviews (Art. 12(2)). - Peer reviews cover best practices and relevant aspects related to effectiveness of market surveillance (Art. 12(3)). - Outcome of peer reviews is reported to the Network (Art. 12(4)). ## Possible Outcomes ### [RESULT] EU Manufacturer Art. 4(2)(a) - You are the economic operator referred to in Article 4 unless you have appointed an authorised representative to perform the tasks set out in Article 4(3) on your behalf. - Your contact details (name, registered trade name or trade mark, postal address) must be indicated on the product or packaging/parcel/accompanying document (Art. 4(4)). - You must perform the tasks in Article 4(3): verify EU declaration of conformity and technical documentation; provide information to market surveillance authorities; inform authorities if the product presents a risk; cooperate on corrective action. ### [RESULT] Authorised Representative is the Economic Operator Art. 4(2)(c) - The authorised representative is the economic operator referred to in Article 4. - The authorised representative must perform the tasks specified in the written mandate from the manufacturer, including Article 4(3) tasks. - The authorised representative's contact details must be indicated on the product or packaging/parcel/accompanying document (Art. 4(4)). ### [RESULT] Importer is the Economic Operator Art. 4(2)(b) - The importer is the economic operator referred to in Article 4. - The importer must perform the tasks in Article 4(3): verify EU declaration of conformity and technical documentation; provide information to market surveillance authorities; inform authorities if the product presents a risk; cooperate on corrective action. - The importer's contact details must be indicated on the product or packaging/parcel/accompanying document (Art. 4(4)). ### [RESULT] Fulfilment Service Provider is the Economic Operator Art. 4(2)(d) - The fulfilment service provider is the economic operator referred to in Article 4 with respect to the products it handles. - This applies only where no manufacturer, importer, or authorised representative is established in the Union. - The fulfilment service provider must perform the tasks in Article 4(3) and indicate contact details on the product or packaging/parcel/accompanying document (Art. 4(4)). ### [RESULT] Non-Compliant with Article 4 Product may not be placed on the market - Article 4(1) prohibits placing products on the market unless there is an economic operator established in the Union responsible for the tasks in Article 4(3). - Market surveillance authorities may prohibit the placing of the product on the market and require border authorities not to release it for free circulation. - Economic operators must cooperate with market surveillance authorities (Art. 7). ### [RESULT] Article 4 Does Not Apply Other MSR obligations may apply - Article 4 applies only to products subject to the legislation listed in Article 4(5). - Even if Article 4 does not apply, economic operators must cooperate with market surveillance authorities (Art. 7). - Distributors and other economic operators remain subject to obligations under Union harmonisation legislation applicable to the product and under general MSR provisions. ### [RESULT] Out of MSR Scope Product not subject to Union harmonisation legislation in Annex I - MSR applies only to products subject to Union harmonisation legislation listed in Annex I. - If your product is not subject to that legislation, MSR does not apply. - The MSR does not prevent market surveillance authorities from taking more specific measures as provided for in Directive 2001/95/EC (Art. 2(3)). ## MSR Timeline | Date | Event | Reference | | --- | --- | --- | | 2019-06-20 | Regulation (EU) 2019/1020 adopted by European Parliament and Council | Reg. (EU) 2019/1020 | | 2019-06-25 | MSR published in Official Journal (OJ L 169) | OJ L 169, 25.6.2019, p. 1 | | 2019-07-15 | MSR enters into force (20 days after publication) | Art. 44 | | 2021-01-01 | Articles 29-33 and 36 apply (Union Product Compliance Network and financing) | Art. 44 | | 2021-07-16 | MSR applies in full (including Article 4 on economic operator obligations) | Art. 44 | | 2022-07-16 | First national market surveillance strategy due | Art. 13(1) | | 2023-07-16 | Commission evaluation report on Article 4 implementation due | Art. 42 | | 2024-07-16 | First evaluation of national market surveillance strategies | Art. 13 | | 2026-12-31 | Commission evaluation of MSR and report to Parliament and Council (every 5 years thereafter) | Art. 42 | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2019-06-14 | Council Decision on Final Text | Legislative History | | | 2019-06-20 | Regulation Adopted | Legislative History | | | 2019-06-25 | Official Journal Publication | Official Publication | | | 2021-01-01 | Early Application of Certain Articles | Application Dates | | | 2021-02-25 | EUPCN Rules of Procedure Adopted | Network & Cooperation | | | 2021-03-05 | Article 4 Guidelines Externalized (Docsroom) | Commission Guidance | | | 2021-03-23 | Article 4 Guidelines Published in Official Journal | Commission Guidance | | | 2021-07-16 | Regulation Applies | Application Dates | | | 2021-10-16 | Member State Notification Deadline | Implementation Milestones | | | 2022-07-16 | First National Market Surveillance Strategy Due | Implementation Milestones | | | 2022-07-20 | Union Testing Facility Designation Procedures Adopted | Implementing Measures | | | 2022-07-21 | Union Testing Facility Procedures Published | Official Publication | | | 2023-07-16 | Article 4 Evaluation Report Due | Evaluation & Review | | | 2023-07-28 | Amendment (EU) 2023/1542 Published | Amendments | | | 2023-12-05 | Implementing Regulation (EU) 2023/2712 Signed | Implementing Measures | | | 2024-05-03 | Amendment (EU) 2024/1252 Published | Amendments | | | 2024-05-27 | Union Testing Facility Designated | Implementing Measures | | | 2024-05-29 | Union Testing Facility Decision Published | Official Publication | | | 2024-06-18 | Union Testing Facility Decision Enters into Force | Implementing Measures | | | 2024-07-16 | First Evaluation of National Strategies | Evaluation & Review | | | 2024-08-06 | Implementing Regulation (EU) 2023/2712 Applies | Implementing Measures | | | 2024-10-01 | Corrigendum to (EU) 2024/1252 Published | Amendments | | | 2026-12-31 | Commission Evaluation Due | Evaluation & Review | | | 2029-06-18 | Union Testing Facility Designation Review | Evaluation & Review | | **Event details:** - **2019-06-14 - Council Decision on Final Text**: Legislative procedure milestone noted in EUR-Lex timeline: decision of the Council of 14 June 2019 (and European Parliament position of 17 April 2019, not yet published in the Official Journal). - **2019-06-20 - Regulation Adopted**: European Parliament and Council adopt Regulation (EU) 2019/1020 on market surveillance and compliance of products. - **2019-06-25 - Official Journal Publication**: Regulation (EU) 2019/1020 published in Official Journal L 169 (25 June 2019). - **2021-01-01 - Early Application of Certain Articles**: Certain provisions of Regulation (EU) 2019/1020 (Articles 29, 30, 31, 32, 33 and 36) apply from 1 January 2021. - **2021-02-25 - EUPCN Rules of Procedure Adopted**: Rules of Procedure of the Union Product Compliance Network (EUPCN) adopted (document referenced with date 25 February 2021). - **2021-03-05 - Article 4 Guidelines Externalized (Docsroom)**: C(2021) 1461 guidance on practical implementation of Article 4 is externalized/published in the Commission Docsroom record metadata on 5 March 2021. - **2021-03-23 - Article 4 Guidelines Published in Official Journal**: Commission Notice 2021/C 100/01 on Article 4 implementation published (Document 52021XC0323(01)). - **2021-07-16 - Regulation Applies**: Regulation (EU) 2019/1020 applies from 16 July 2021. - **2021-10-16 - Member State Notification Deadline**: Member States must notify penalty provisions to the Commission by 16 October 2021 and promptly notify subsequent amendments affecting them. - **2022-07-16 - First National Market Surveillance Strategy Due**: Each Member State must draw up the first national market surveillance strategy by 16 July 2022. - **2022-07-20 - Union Testing Facility Designation Procedures Adopted**: Commission Implementing Regulation (EU) 2022/1267 adopted, specifying procedures for designating Union testing facilities under Regulation (EU) 2019/1020. - **2022-07-21 - Union Testing Facility Procedures Published**: Implementing Regulation (EU) 2022/1267 published in the Official Journal (OJ L 192, 21.7.2022, p. 21). - **2023-07-16 - Article 4 Evaluation Report Due**: By 16 July 2023, the Commission must prepare an evaluation report on the implementation of Article 4 (scope, effects, costs and benefits), accompanied where appropriate by a legislative proposal. - **2023-07-28 - Amendment (EU) 2023/1542 Published**: Regulation (EU) 2023/1542 was published in the Official Journal on 28 July 2023 (OJ L 191, 28.7.2023) and amends Regulation (EU) 2019/1020. - **2023-12-05 - Implementing Regulation (EU) 2023/2712 Signed**: Commission Implementing Regulation (EU) 2023/2712 signed on 5 December 2023 on transmitting information from national customs systems to the market surveillance information system. - **2024-05-03 - Amendment (EU) 2024/1252 Published**: Regulation (EU) 2024/1252 was published in the Official Journal on 3 May 2024 (OJ L, 2024/1252, 3.5.2024) and amends Regulation (EU) 2019/1020. - **2024-05-27 - Union Testing Facility Designated**: Commission Implementing Decision (EU) 2024/1456 adopted, designating a Union testing facility for eco-design and energy labelling under Regulation (EU) 2019/1020. - **2024-05-29 - Union Testing Facility Decision Published**: Implementing Decision (EU) 2024/1456 published in the Official Journal (OJ L, 2024/1456, 29.5.2024). - **2024-06-18 - Union Testing Facility Decision Enters into Force**: Implementing Decision (EU) 2024/1456 enters into force on 18 June 2024 (twentieth day after its publication in the Official Journal, as captured in the EUR-Lex timeline extraction). - **2024-07-16 - First Evaluation of National Strategies**: First evaluation of national market surveillance strategies should take place by 16 July 2024. - **2024-08-06 - Implementing Regulation (EU) 2023/2712 Applies**: Implementing Regulation (EU) 2023/2712 applies from 6 August 2024. - **2024-10-01 - Corrigendum to (EU) 2024/1252 Published**: Corrigendum to Regulation (EU) 2024/1252 published (OJ L 90589, 1.10.2024, p. 1), as recorded in the consolidated MSR regulation timeline. - **2026-12-31 - Commission Evaluation Due**: By 31 December 2026, the Commission must carry out an evaluation of Regulation (EU) 2019/1020 and present a report to the European Parliament, the Council and the European Economic and Social Committee. - **2029-06-18 - Union Testing Facility Designation Review**: The designation of the Union testing facility under Implementing Decision (EU) 2024/1456 must be reviewed by 18 June 2029 (and every 5 years thereafter). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/market-surveillance-regulation --- --- title: "EU Packaging and Packaging Waste Regulation (PPWR)" canonical_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation" source_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation" author: "Sorena AI" description: "A practical PPWR hub for Regulation (EU) 2025/40 on packaging and packaging waste." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Packaging and Packaging Waste Regulation PPWR" - "Regulation (EU) 2025/40" - "PPWR compliance" - "PPWR timeline" - "PPWR decision flow" - "PPWR recyclability grades A B C" - "design for recycling criteria PPWR" - "recyclable at scale PPWR 2035" - "recycled content targets PPWR 2030 2040" - "PFAS limits food contact packaging PPWR" - "PPWR labelling requirements Article 12" - "digital marking packaging composition PPWR" - "deposit return system marking PPWR" - "reuse targets Article 29" - "refill obligations HORECA Article 32 33" - "excessive packaging empty space ratio 50% Article 24" - "restrictions on packaging formats Annex V Article 25" - "PPWR checklist" - "PPWR compliance calendar" - "PPWR" - "Packaging compliance" - "Recyclability grades" - "Recycled content" - "Labelling" - "Reuse and refill" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Packaging and Packaging Waste Regulation (PPWR) A practical PPWR hub for Regulation (EU) 2025/40 on packaging and packaging waste. ![EU PPWR artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-ppwr-timeline-small.jpg?v=cheatsheets%2Fprod) *PPWR* *Free Resource* ## EU Packaging and Packaging Waste Regulation (PPWR) Timeline and Packaging Decision Flow Use this hub to scope obligations under Regulation (EU) 2025/40, then turn outcomes into packaging specs, supplier requirements, and audit-ready evidence across recyclability, recycled content, labelling/digital marking, PFAS/substances, excessive packaging limits, and reuse/refill targets. Regulation (EU) 2025/40 was signed on 19 December 2024, entered into force on 11 February 2025, and applies from 12 August 2026. Several obligations rely on delegated or implementing acts, so your packaging design, channel, and use case drive what good implementation looks like. [Run the PPWR applicability test](/artifacts/eu/packaging-waste-regulation/applicability-test.md) ## What you can decide faster - **What applies to this packaging unit**: Scope, format (sales/grouped/transport/e-commerce), material and use case. - **What must change in design and materials**: Recyclability grades (A/B/C), design-for-recycling criteria, recycled content, PFAS/substances limits. - **What must change in operations**: Labelling/digital marking, excessive packaging (empty space), reuse/refill obligations and evidence packs. By Sorena AI | Grounded in official EU sources | Updated March 2026 ### Quick scan *PPWR* - **Recyclability (Article 6)**: Design-for-recycling criteria, grades A/B/C, and "recycled at scale". - **Materials (Articles 5-7)**: Substances of concern + PFAS limits + minimum recycled content targets. - **Labelling (Articles 12-13)**: Harmonised labels, QR/digital carriers, and waste receptacle labels. Use the decision flow to identify obligations by packaging type, then use the topic guides to build specs and evidence. | Value | Metric | | --- | --- | | 11 Feb 2025 | In force | | 12 Aug 2026 | Applies | | 1 Jan 2030 | Core obligations | | 2040 | Higher targets | **Key highlights:** Recyclability grades | PFAS limits | Labelling + digital marking ## Topic Guides - [Applicability Test | EU Packaging and Packaging Waste Regulation (PPWR) | Regulation (EU) 2025/40 Scope + Roles](/artifacts/eu/packaging-waste-regulation/applicability-test.md): A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging. - [Labelling and Consumer Information | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels, QR/Digital Marking, DRS](/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info.md): A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers. - [PFAS and Restricted Substances | EU PPWR (Regulation (EU) 2025/40) | Article 5 PFAS Thresholds for Food-Contact Packaging](/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances.md): A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits. - [PPWR Compliance Checklist | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40)](/artifacts/eu/packaging-waste-regulation/checklist.md): An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals. - [PPWR Compliance Guide | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40) | Evidence, Conformity, Enforcement](/artifacts/eu/packaging-waste-regulation/compliance.md): A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging. - [PPWR Deadlines and Compliance Calendar | Regulation (EU) 2025/40 | 11 February 2025, 12 August 2026, 1 January 2030](/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar.md): A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026. - [PPWR FAQ | Regulation (EU) 2025/40 Packaging and Packaging Waste Questions (Dates, PFAS, Labelling, Reuse Targets)](/artifacts/eu/packaging-waste-regulation/faq.md): A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions. - [PPWR Labelling Checklist | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels + QR/Digital Carriers](/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist.md): An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking. - [PPWR Penalties and Fines | Regulation (EU) 2025/40 Article 68 Enforcement and Administrative Fines](/artifacts/eu/packaging-waste-regulation/penalties-and-fines.md): A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027. - [PPWR Recyclability Assessment Template | Regulation (EU) 2025/40 | Article 6 Evidence Pack + Grade A/B/C](/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template.md): A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material). - [PPWR Timeline and Deadlines | Regulation (EU) 2025/40 Roadmap | 2025 to 2040](/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines.md): A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028. - [PPWR vs ESPR | Packaging and Packaging Waste Regulation (EU) 2025/40 vs Ecodesign for Sustainable Products Regulation (EU) 2024/1781](/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr.md): A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space. - [Recyclability and Design Requirements | EU PPWR (Regulation (EU) 2025/40) | Article 6 Recyclability Grades A/B/C + Design-for-Recycling](/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements.md): A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components. - [Requirements | EU PPWR (Regulation (EU) 2025/40) | Recyclability (Article 6), Recycled Content (Article 7), Labelling (Article 12), PFAS (Article 5)](/artifacts/eu/packaging-waste-regulation/requirements.md): A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits. - [Reuse and Refill Targets | EU PPWR (Regulation (EU) 2025/40) | Article 28-33 Refill Rules, Article 29 Reuse Targets (40% 2030, 70% 2040)](/artifacts/eu/packaging-waste-regulation/reuse-refill-targets.md): A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging. - [Scope and Packaging Definitions | EU PPWR (Regulation (EU) 2025/40) | Sales vs Grouped vs Transport vs E-commerce](/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions.md): A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging. ## Key dates for packaging compliance *PPWR Timeline* Track entry into force, application, labelling acts, reuse and refill milestones, 2030 design and format obligations, and long-range review dates that affect packaging redesign and supplier planning. ## Which PPWR obligations apply to your packaging *PPWR Decision Flow* Use the decision flow to identify obligations by packaging type and use case, then translate outcomes into product and procurement requirements. *Next step* ## Turn EU Packaging and Packaging Waste Regulation (PPWR) Timeline and Packaging Decision Flow into an ESG delivery workflow EU Packaging and Packaging Waste Regulation (PPWR) Timeline and Packaging Decision Flow should be the shared entry point for your team. Route execution into ESG Compliance for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU Packaging and Packaging Waste Regulation (PPWR) Timeline and Packaging Decision Flow and route the work by entity, product, team, or control owner. - Use ESG Compliance to manage cross team sustainability work, reporting, and evidence from one workflow. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open ESG Compliance](/solutions/esg-compliance.md): Manage cross team sustainability work, reporting, and evidence from one workflow for EU Packaging and Packaging Waste Regulation (PPWR) Timeline and Packaging Decision Flow. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share PPWR logic with packaging owners. - **Download timeline**: Coordinate milestones across your team. - [Talk through EU Packaging and Packaging Waste Regulation (PPWR) Timeline and Packaging Decision Flow](/contact.md): Review your current process, evidence model, and next steps for EU Packaging and Packaging Waste Regulation (PPWR) Timeline and Packaging Decision Flow. ## Decision Steps ### STEP 1: Do you place packaging on the EU market or generate packaging waste? *Reference: Reg. (EU) 2025/40* - This Regulation applies to all packaging placed on the market in the Union and to all packaging waste, regardless of type or material used. - If yes: check if you are a manufacturer, importer, distributor, or economic operator using packaging. - **NO** Out of Scope - **YES** What is your role in the packaging supply chain? ### STEP 2: What is your role in the packaging supply chain? - Manufacturer: designs and produces packaging or has packaging designed/produced. - Importer: places packaging from third countries on the Union market. - Distributor: makes packaging available on the market after manufacturer/importer placed it. - Producer: makes packaged products available on the market (EPR obligations). - Final distributor: sells packaged products to consumers (re-use obligations). - -> Are you a manufacturer or importer of packaging? ### STEP 3: Are you a manufacturer or importer of packaging? *Reference: Arts. 15 and 18* - Manufacturers: ensure packaging complies with Arts. 5-12; carry out conformity assessment (Art. 38) and draw up an EU declaration of conformity (Art. 39); draw up technical documentation (Annex VII). - Importers: only place compliant packaging on the market; verify manufacturer's conformity assessment/technical documentation; ensure labelling per Art. 12; provide importer identification information. - Recordkeeping: single-use packaging - keep relevant documentation for 5 years; reusable packaging - 10 years (Arts. 15(3) and 18(7)). - **YES** Does your packaging meet the sustainability requirements? - **NO** Are you a distributor of packaging? ### STEP 4: Are you a distributor of packaging? *Reference: Art. 19* - Distributors: act with due care to ensure packaging complies with this Regulation. - Before making packaging available: verify producer registration (Art. 44), packaging labelling (Art. 12), and manufacturer/importer identification information (Art. 19(2)). - Do not make packaging available on the market if you know or should have known it does not comply. - Inform manufacturer/importer and market surveillance authorities of non-compliant packaging. - **YES** Distributor Compliance Required - **NO** Are you a producer subject to extended producer responsibility? ### STEP 5: Does your packaging meet the sustainability requirements? *Reference: Arts. 5-12* - Substances in packaging: minimise substances of concern; heavy metals limit; PFAS restriction for food-contact packaging from 12 Aug 2026 (Art. 5). - Recyclability: packaging must be recyclable and meet the recyclability conditions and performance grades (Art. 6). - Minimum recycled content (plastic packaging): targets from 2030 and 2040 (Art. 7). - Compostable packaging: only certain packaging is required/allowed to be compostable; other packaging must be designed for material recycling (Art. 9). - Minimisation: by 1 Jan 2030, packaging weight/volume reduced to the minimum necessary; excessive packaging features restricted (Art. 10, and empty-space rules in Art. 24). - Reusable packaging and labelling: reusability requirements (Art. 11) and harmonised labelling/marking requirements (Art. 12). - **YES** Is your packaging recyclable under PPWR criteria? - **NO** Manufacturer/Importer Compliance Required ### RECYCLABILITY: Is your packaging recyclable under PPWR criteria? *Reference: Art. 6* - From 1 Jan 2030 (or 24 months after the relevant delegated acts enter into force, whichever is later): the design-for-recycling condition applies and packaging cannot be placed on the market unless it is recyclable within grades A, B or C. - From 1 Jan 2035 (or 5 years after the relevant implementing acts enter into force, whichever is later): the recycled-at-scale condition applies. - From 1 Jan 2038: packaging cannot be placed on the market unless it is recyclable within grades A or B. - Exemptions for: immediate medicinal packaging, contact-sensitive medical/infant food packaging, dangerous goods packaging, lightweight wood/cork/textile/rubber/ceramic/porcelain sales packaging. - **YES** Does plastic packaging contain the required recycled content? - **NO** Manufacturer/Importer Compliance Required ### RECYCLED CONTENT: Does plastic packaging contain the required recycled content? *Reference: Art. 7* - From 1 Jan 2030 (or later depending on implementing act timing): minimum post-consumer recycled content per packaging type/format: 30% for single-use plastic beverage bottles; 30% for contact-sensitive PET (except beverage bottles); 10% for contact-sensitive non-PET (except beverage bottles); 35% for other plastic packaging. - From 1 Jan 2040: minimum post-consumer recycled content per packaging type/format: 65% for single-use plastic beverage bottles; 50% for contact-sensitive PET (except beverage bottles); 25% for contact-sensitive non-PET (except beverage bottles); 65% for other plastic packaging. - Calculated as average per manufacturing plant and year, per packaging type/format. - Key exemptions include specific medicinal/medical device packaging, compostable plastic packaging, dangerous goods packaging, certain infant/young children food packaging, and very small plastic parts (<5% of unit weight) (Art. 7(4)-(5)). - **YES** Does food-contact packaging contain PFAS? - **NO** Manufacturer/Importer Compliance Required ### PFAS BAN: Does food-contact packaging contain PFAS? *Reference: Art. 5(5)* - From 12 Aug 2026: food-contact packaging must not be placed on the market if it contains PFAS at or above the limit values in Art. 5(5). - Limit values: 25 ppb for any PFAS (targeted analysis), 250 ppb for the sum of PFAS (targeted analysis, where applicable with precursor degradation), and 50 ppm for PFASs including polymeric PFAS. - By 12 Aug 2030: Commission evaluates whether to amend or repeal this restriction to avoid overlaps with other Union PFAS restrictions. - **YES** Manufacturer/Importer Compliance Required - **NO** Does packaging comply with heavy metal concentration limits? ### HEAVY METALS: Does packaging comply with heavy metal concentration limits? *Reference: Art. 5(4)* - Sum of concentration levels of lead, cadmium, mercury, and hexavalent chromium: max 100 ppm by weight. - Derogations may apply for glass packaging, plastic crates/pallets in closed loops (based on Commission delegated acts). - Commission may adopt delegated acts to lower concentrations or determine conditions for exemptions. - **YES** Is packaging allowed to be compostable? - **NO** Manufacturer/Importer Compliance Required ### COMPOSTABLE: Is packaging allowed to be compostable? *Reference: Art. 9* - By 12 Feb 2028: permeable tea/coffee beverage bags and soft after-use single-serve units, and sticky labels affixed to fruit and vegetables, must be compatible with industrial composting standards; Member States may require compatibility with home-composting standards (Art. 9(1)). - Member States may require certain packaging to be compostable where collection schemes and treatment infrastructure ensure compostable packaging enters the bio-waste stream (Art. 9(2)). - By 12 Feb 2028: packaging other than that referred to in Art. 9(1)-(2) (including biodegradable materials) must be designed for material recycling in accordance with Art. 6 (Art. 9(3)). - Compliance must be demonstrated in the technical information (Annex VII) (Art. 9(4)). - **YES** Is packaging minimised in volume and weight? - **NO** Manufacturer/Importer Compliance Required ### MINIMISATION: Is packaging minimised in volume and weight? *Reference: Art. 10* - Packaging must be minimised while maintaining functionality (protection, hygiene, safety, acceptance). - No double walls, false bottoms, or other features aimed only at increasing perceived volume. - No superfluous packaging not necessary for functionality. - Exemptions: EU geographical indication products, trademark/design rights protected before 11 Feb 2025. - Harmonised standards (when available) provide presumption of conformity. - **YES** If reusable, is packaging designed for re-use and linked to a re-use system? - **NO** Manufacturer/Importer Compliance Required ### REUSABLE DESIGN: If reusable, is packaging designed for re-use and linked to a re-use system? *Reference: Art. 11, Arts. 26-27 & Annex VI* - Reusable packaging must be designed for maximum number of rotations while maintaining safety, quality, hygiene. - Reusable packaging must be linked to a re-use system (open loop or closed loop) that meets the minimum requirements in Annex VI; economic operators using reusable packaging must participate in re-use systems and ensure reconditioning (Arts. 26-27). - Harmonised standards (when available) provide presumption of conformity for reusable packaging and re-use systems. - **YES** Does packaging carry the required labels? - **NO** Does packaging carry the required labels? ### LABELLING: Does packaging carry the required labels? *Reference: Art. 12* - Material composition label: harmonised symbol showing material and waste stream (mandatory, except transport packaging unless e-commerce). - Reusable packaging: QR code or digital carrier with re-use system info, tracking/rotation data, collection channels. - Deposit and return system: harmonised label if covered by mandatory DRS. - Substances of concern: digital marking if packaging contains substances of concern. - Recycled content and biobased plastic content: optional harmonised labels (if manufacturer wishes to display). - **YES** Have you completed the conformity assessment and EU declaration? - **NO** Manufacturer/Importer Compliance Required ### EMPTY SPACE: Does grouped/transport/e-commerce packaging exceed 50% empty space ratio? *Reference: Art. 24* - By 1 Jan 2030 (or 3 years after the implementing acts enter into force, whichever is later): economic operators who fill grouped, transport or e-commerce packaging must ensure the empty space ratio is max 50%. - Methodology for calculating empty space ratio is set by implementing acts (by 12 Feb 2028). - Exemptions: sales packaging used as e-commerce packaging and reusable packaging within a system of re-use are exempt from the 50% ratio obligation (but other minimisation requirements still apply). - **YES** Does packaging fall under the restricted formats? - **NO** Economic Operator Compliance Required ### RESTRICTIONS: Does packaging fall under the restricted formats? *Reference: Art. 25 & Annex V* - From 1 Jan 2030: economic operators must not place on the market packaging in the formats and for the uses listed in Annex V (subject to the Annex V conditions and exceptions). - Commission may publish guidelines to explain the list and exemptions. - **YES** If using reusable packaging, is a re-use system in place? - **NO** Economic Operator Compliance Required ### RE-USE SYSTEM: If using reusable packaging, is a re-use system in place? *Reference: Arts. 26-27 & Annex VI* - Re-use systems must meet minimum requirements: collection channels, reconditioning process (wash, repair, quality check), tracking. - Open loop systems: multiple economic operators participate; must have system operator. - Closed loop systems: single economic operator controls packaging; system operator optional. - Reusable packaging becomes waste when holder discards it; packaging in reconditioning is normally not waste. - **YES** Do you offer refill options for products? - **NO** Economic Operator Compliance Required ### REFILL: Do you offer refill options for products? *Reference: Art. 28* - Refill stations must meet hygiene and safety requirements. - Economic operators must provide information on safe refill and use of consumer-provided containers. - Cannot provide free packaging or non-DRS packaging at refill stations. - Economic operators exempt from liability for food safety issues arising from consumer-provided containers. - From 1 Jan 2030: final distributors with a sales area > 400 m2 shall endeavour to dedicate 10% of sales area to refill stations for food and non-food products. - **YES** Are you subject to re-use or refill targets? - **NO** Are you subject to re-use or refill targets? ### RE-USE TARGETS: Are you subject to re-use or refill targets? *Reference: Art. 29* - Transport packaging (e.g., pallets, crates, boxes, trays, IBCs, etc.): at least 40% reusable within a re-use system from 1 Jan 2030; endeavour at least 70% from 1 Jan 2040. - Grouped packaging (boxes excluding cardboard): at least 10% reusable within a re-use system from 1 Jan 2030; endeavour at least 25% from 1 Jan 2040. - Beverages (final distributors): at least 10% made available in reusable packaging within a re-use system from 1 Jan 2030; endeavour at least 40% from 1 Jan 2040 (with product-category exclusions and other exemptions). - Key exemptions include very small final distributors (sales area <= 100 m2) and micro-enterprises placing <= 1,000 kg packaging on the market in a calendar year; certain beverage categories are excluded (e.g., highly perishable beverages, milk/milk products, wine-related categories, and certain spirits). - **YES** Do you use transport packaging between sites or within one Member State? - **NO** Do you use transport packaging between sites or within one Member State? ### TRANSPORT: Do you use transport packaging between sites or within one Member State? *Reference: Art. 29(2)-(3)* - Economic operators transporting between own sites or with linked/partner enterprises: use only reusable transport packaging (pallets, foldable boxes, plastic crates, IBCs, drums). - Same obligation when transporting within one Member State. - Exemptions: dangerous goods, large-scale machinery, direct-contact flexible food transport, cardboard boxes. - **YES** Do you supply plastic carrier bags? - **NO** Do you supply plastic carrier bags? ### CARRIER BAGS: Do you supply plastic carrier bags? *Reference: Art. 34* - Member States must take measures to achieve a sustained reduction in the consumption of lightweight plastic carrier bags. - Sustained reduction target: annual consumption must not exceed 40 lightweight plastic carrier bags per capita by 31 Dec 2025 (and by 31 Dec each year thereafter). - Member States can use measures such as economic instruments, national reduction targets and (proportionate, non-discriminatory) marketing restrictions. - Member States may exclude very lightweight plastic carrier bags required for hygiene purposes or provided as sales packaging for loose food to prevent food wastage. - **YES** Economic Operator Compliance Required - **NO** Are you a producer subject to extended producer responsibility? ### CONFORMITY: Have you completed the conformity assessment and EU declaration? *Reference: Arts. 15, 38-39 & Annex VII* - Before placing packaging on the market, manufacturers must carry out the conformity assessment procedure (internal production control) and draw up the technical documentation (Annex VII) (Art. 15(2) and Art. 38). - After conformity is demonstrated, manufacturers draw up an EU declaration of conformity (Art. 15(2) and Art. 39). - Recordkeeping: single-use packaging - keep technical documentation and EU declaration for 5 years; reusable packaging - 10 years (Art. 15(3)). - **YES** Does grouped/transport/e-commerce packaging exceed 50% empty space ratio? - **NO** Manufacturer/Importer Compliance Required ### EPR: Are you a producer subject to extended producer responsibility? *Reference: Art. 45* - Producers have extended producer responsibility (EPR) for packaging (including packaging of packaged products) that they make available for the first time in a Member State, or that they unpack without being end users (Art. 45(1)). - If you sell via distance contracts into other Member States, you may need to appoint an authorised representative for EPR in each relevant Member State (Art. 45(3)). - Online platforms facilitating distance contracts with producers must obtain the producer's EPR registration information and self-certification before allowing sales (Art. 45(4)-(6)). - **YES** Producer EPR Obligations Apply - **NO** Does your Member State meet the packaging waste prevention targets? ### WASTE PREVENTION: Does your Member State meet the packaging waste prevention targets? *Reference: Art. 43* - Member State obligations: reduce packaging waste generation per capita compared to 2018. - 5% reduction by 2030, 10% by 2035, 15% by 2040. - Member States adopt measures: economic instruments, re-use systems, refill promotion, EPR measures, packaging minimisation enforcement. - Early warning system: Commission issues reports if MS at risk of missing targets. - **YES** Does your Member State meet the packaging waste recycling targets? - **NO** Member State Obligations ### RECYCLING TARGETS: Does your Member State meet the packaging waste recycling targets? *Reference: Art. 52* - Member State obligations: achieve minimum recycling targets covering the whole territory, by weight of packaging waste generated. - Targets include overall recycling: 65% by 31 Dec 2025 and 70% by 31 Dec 2030 (Art. 52(1)(a) and (c)), plus material-specific targets for 2025 and 2030 (Art. 52(1)(b) and (d)). - Member States report and calculate achievement using the rules set out in Arts. 53-56. - **YES** Member State Obligations - **NO** Member State Obligations ## Reference Information ### Packaging In Scope (Overview) - All packaging placed on the Union market, regardless of type or material: sales packaging, grouped packaging, transport packaging, service packaging. - All packaging waste, regardless of the material used (plastic, paper, cardboard, glass, metal, wood, etc.). - Economic operators: manufacturers, importers, distributors, final distributors, producers (under extended producer responsibility). - Some provisions include exemptions or flexibilities for certain actors or situations where explicitly provided for in the Regulation. ### Recyclability Requirements (Detailed) - All packaging placed on the market must be recyclable (Art. 6(1)). - Recyclability conditions: designed for material recycling (Art. 6(2)(a)) and, when waste, capable of separate collection/sorting and being recycled at scale (Art. 6(2)(b)). - Applicability: design-for-recycling condition applies from 1 Jan 2030 or 24 months after the relevant delegated acts enter into force (whichever is later); recycled-at-scale condition applies from 1 Jan 2035 or 5 years after the relevant implementing acts enter into force (whichever is later) (Art. 6(2)). - Performance grades A, B, C (Annex II): from 1 Jan 2030 (or later depending on delegated acts), packaging cannot be placed on the market unless it is grade A, B, or C; from 1 Jan 2038, it must be grade A or B (Art. 6(3)). - Commission acts: delegated acts by 1 Jan 2028 set design-for-recycling criteria/grades and EPR fee modulation framework (Art. 6(4)); implementing acts by 1 Jan 2030 set recycled-at-scale methodology and chain of custody (Art. 6(5)). - Innovative packaging derogation: from 1 Jan 2030, certain innovative packaging may be made available up to 5 years under conditions (Art. 6(10)). - Exemptions from Art. 6: listed in Art. 6(11) (e.g., certain medicinal/medical device/infant food contact-sensitive packaging, dangerous goods packaging, specified low-volume material sales packaging). ### Recycled Content Requirements (Detailed) - By 1 Jan 2030 (or 3 years after the implementing act under Art. 7(8), whichever is later): minimum post-consumer recycled content per packaging type/format (Art. 7(1)): 30% contact-sensitive PET (excluding single-use plastic beverage bottles), 10% contact-sensitive non-PET (excluding bottles), 30% single-use plastic beverage bottles, 35% other plastic packaging. - By 1 Jan 2040: minimum post-consumer recycled content (Art. 7(2)): 50% contact-sensitive PET (excluding bottles), 25% contact-sensitive non-PET (excluding bottles), 65% single-use plastic beverage bottles, 65% other plastic packaging. - Calculated as an average per manufacturing plant and year, per packaging type/format (Art. 7(1)-(2)). - Key exemptions and carve-outs: Art. 7(4)-(5) (including specific medicinal/medical device packaging, compostable plastic packaging, dangerous goods packaging, certain infant/young children food packaging, recycled content posing a human-health risk for food-contact packaging, and plastic parts <5% of total packaging unit weight). - Commission implementing acts by 31 Dec 2026 establish the calculation and verification methodology and technical documentation format (Art. 7(8)). - Commission delegated acts by 31 Dec 2026 establish sustainability criteria for plastic recycling technologies; additional implementing acts cover equivalence for third-country collection/recycling (Art. 7(9)-(10)). ### Substances of Concern (Detailed) - Packaging must be manufactured so that the presence and concentration of substances of concern is minimised (Art. 5(1)). - Heavy metals: the sum of concentrations of lead, cadmium, mercury and hexavalent chromium must not exceed 100 mg/kg (Art. 5(4)). Compliance is demonstrated in technical documentation (Annex VII) (Art. 5(6)). - PFAS restriction for food-contact packaging: from 12 Aug 2026, food-contact packaging must not be placed on the market if PFAS are present at or above the limit values in Art. 5(5) (25 ppb any PFAS, 250 ppb sum of PFAS, 50 ppm PFAS incl polymeric). - By 12 Aug 2030: Commission evaluates whether to amend or repeal the PFAS paragraph to avoid overlaps with other Union PFAS restrictions (Art. 5(5)). - Commission may adopt delegated acts to lower the heavy-metals limit and to set conditions for time-limited exemptions (e.g., closed and controlled chains) (Art. 5(7)-(8)); Commission also reports on substances of concern by 31 Dec 2026 (Art. 5(2)). ### Compostable Packaging (Detailed) - By 12 Feb 2028: permeable tea/coffee (or other beverage) bags and soft after-use system single-serve units (Art. 3(1)(1)(f)), and sticky labels affixed to fruit and vegetables, must be compatible with the standard for industrial composting in bio-waste treatment facilities; Member States may require compatibility with home-composting standards (Art. 9(1) and 9(6)). - Member States may require certain packaging to be compostable when collected together with bio-waste and where appropriate collection/treatment infrastructure exists, including certain non-permeable single-serve units (Art. 3(1)(1)(g)) made of material other than metal and plastic carrier bags (Art. 9(2)). - By 12 Feb 2028: packaging other than that referred to in Art. 9(1)-(2) must be designed for material recycling under Art. 6 without affecting the recyclability of other waste streams (Art. 9(3)). - Compliance must be demonstrated in the technical information (Annex VII) (Art. 9(4)). ### Packaging Minimisation (Detailed) - By 1 Jan 2030: manufacturers/importers must ensure packaging is designed so weight and volume are reduced to the minimum necessary to ensure functionality (Art. 10(1)). - Certain packaging designs must not be placed on the market if they do not comply with the performance criteria in Annex IV, or if they aim only to increase perceived product volume (e.g., double walls, false bottoms, unnecessary layers), subject to specific derogations (Art. 10(2)). - Derogations in Art. 10(2) include specific situations where protected designs/trademarks (protected before 11 Feb 2025) or protected geographical indications/quality schemes would be affected. - Commission requests harmonised standards for minimisation methodology by 12 Feb 2027 (Art. 10(3)); compliance must be demonstrated in technical documentation (Annex VII) (Art. 10(4)). ### Reusable Packaging & Re-use Systems (Detailed) - Reusable packaging requirements: packaging is reusable if it meets all conditions in Art. 11(1)(a)-(i) (designed for multiple uses/rotations; safe/hygienic; capable of reconditioning; recyclable at end of life). - Commission delegated act: by 12 Feb 2027, establish a minimum number of rotations for frequently used reusable packaging formats (Art. 11(2)). - Obligations for making reusable packaging available for the first time: ensure a re-use system with an incentive for collection is in place and meets Annex VI requirements (Art. 26 and Annex VI). - Obligations for using reusable packaging: participate in one or more re-use systems; ensure the system meets Annex VI Part A; ensure reconditioning in line with Annex VI Part B (Art. 27). ### Labelling Requirements (Detailed) - Material composition label: from 12 Aug 2028 (or later depending on implementing acts), packaging must be marked with a harmonised label with information on material composition to facilitate consumer sorting (Art. 12(1)). - Reusable packaging: from 12 Feb 2029 (or later depending on implementing acts), reusable packaging bears a label informing users it is reusable, and provides further information via a QR code or other standardised, open digital data carrier; the label/QR requirement does not apply to open loop systems without a system operator (Art. 12(2)-(3)). - Deposit and return systems: packaging subject to deposit and return systems under Art. 50(1) must be marked with a clear and unambiguous label (Art. 12(1), second subparagraph). - Substances of concern: packaging containing substances of concern is marked by means of standardised, open digital-marking technologies (Art. 12(1), second subparagraph; methodology via implementing acts under Art. 12(7)). - Implementing acts: Commission adopts implementing acts on harmonised label specifications and formats, and methodologies for digital marking (Art. 12(6)-(7)). ### Re-use & Refill Targets (Detailed) - Transport packaging: from 1 Jan 2030, economic operators using specified transport packaging formats must ensure at least 40% is reusable within a re-use system; from 1 Jan 2040 they shall endeavour to use at least 70% (Art. 29(1)). - Transport between own/linked sites and certain same-Member-State deliveries: from 1 Jan 2030, transport packaging used in those cases must be reusable within a re-use system (Art. 29(2)-(3)). - Grouped packaging (boxes excluding cardboard): from 1 Jan 2030, at least 10% reusable within a re-use system; from 1 Jan 2040 endeavour at least 25% (Art. 29(5)). - Beverages (final distributors): from 1 Jan 2030, ensure at least 10% of alcoholic and non-alcoholic beverages are made available in reusable packaging within a re-use system; from 1 Jan 2040 endeavour at least 40% (Art. 29(6)). - Beverage exclusions/exemptions: Art. 29(7), plus exemptions for final distributors with sales area <= 100 m2 and certain geographic exemptions (Art. 29(10)-(11)); take-back obligations apply when reusable packaging is sold (Art. 29(9)). ### Transport Packaging (Detailed) - From 1 Jan 2030: for specified transport packaging formats, at least 40% must be reusable within a re-use system; from 1 Jan 2040, endeavour at least 70% (Art. 29(1)). - From 1 Jan 2030: for transport packaging used between an operator's own sites (including linked/partner enterprises) and for certain same-Member-State deliveries, packaging must be reusable within a re-use system (Art. 29(2)-(3)). - Exemptions: the transport-packaging obligations do not apply to packaging used for dangerous goods, custom-designed packaging for large-scale machinery/equipment/commodities, certain flexible food/feed contact transport packaging, and cardboard boxes (Art. 29(4)). ### Plastic Carrier Bags (Detailed) - Member States must take measures to achieve a sustained reduction in the consumption of lightweight plastic carrier bags (Art. 34(1)). - Sustained reduction is achieved if annual consumption does not exceed 40 lightweight plastic carrier bags per capita by 31 Dec 2025 and subsequently by 31 Dec each year thereafter (Art. 34(1)). - Member State measures may include marketing restrictions (proportionate and non-discriminatory), economic instruments and national reduction targets; measures should take into account environmental impacts, composting properties, durability and intended use (Art. 34(2)-(3)). - Member States may exclude very lightweight plastic carrier bags required for hygiene purposes or provided as sales packaging for loose food to prevent food wastage (Art. 34(4)). ### Extended Producer Responsibility (Detailed) - Producer definition: set out in Art. 3(15) (covers making packaging/packaged products available for the first time in a Member State, including via distance contracts, and unpacking packaged products without being an end user). - Producer registration: producers register in the Member State register (Art. 44); Member States ensure the list of registered producers is publicly accessible (Art. 44(13)). - EPR obligation: producers have extended producer responsibility under schemes established under Directive 2008/98/EC and Section 3 of the PPWR (Art. 45(1)). - EPR costs: in addition to Directive 2008/98/EC costs, contributions cover costs of labelling waste receptacles (Art. 13) and certain compositional surveys, as specified (Art. 45(2)). - Authorised representative for EPR: certain producers appoint an authorised representative for EPR in each Member State where they first make packaging/packaged products available (Art. 45(3)). - Online platforms: providers enabling distance contracts with producers must obtain EPR registration information and self-certification before allowing sales (Art. 45(4)-(6)). ### Waste Prevention Targets (Detailed) - Targets: each Member State reduces packaging waste generated per capita vs 2018 by at least 5% by 2030, 10% by 2035, and 15% by 2040 (Art. 43(1)). - Commission correction factor: by 12 Feb 2027, Commission establishes a correction factor to account for tourism change vs 2018 (Art. 43(2)). - Member State measures: Member States implement proportionate and non-discriminatory measures to prevent packaging waste and minimise environmental impacts; measures may include economic instruments and incentives via EPR schemes (Art. 43(5)). - Commission review: by 12 Feb 2032, Commission reviews the targets and assesses need for additional material-specific targets (Art. 43(9)). ### Recycling Targets (Detailed) - Overall targets: recycle at least 65% of all packaging waste generated by 31 Dec 2025, and at least 70% by 31 Dec 2030 (Art. 52(1)(a) and (c)). - Material-specific targets: by 31 Dec 2025 and 31 Dec 2030, achieve minimum recycling percentages for plastic, wood, ferrous metals, aluminium, glass, and paper/cardboard as set out in Art. 52(1)(b) and (d). - Postponement: under conditions, a Member State may postpone certain material-specific deadlines by up to 5 years (Art. 52(2)-(3)). - Calculation rules: achievement is calculated under Art. 53 (and related provisions), based on packaging waste entering the recycling operation after necessary preliminary operations. ### Deposit and Return Systems (Detailed) - Separate collection target: by 1 Jan 2029, ensure separate collection of at least 90% per year (by weight) of single-use plastic beverage bottles (up to 3 litres) and single-use metal beverage containers (up to 3 litres) made available on the market for the first time (Art. 50(1)). - To achieve the target, Member States ensure deposit and return systems are set up for those formats and a deposit is charged at point of sale (Art. 50(2)). - Certain exemptions/derogations apply (e.g., HORECA premises consumption; certain beverage categories; possible Member State exemption subject to conditions and Commission interaction) (Art. 50(3)-(7)). - Minimum requirements for certain systems are listed in Annex X; Commission assesses implementation and interoperability over time (Art. 50(11)). ### Market Surveillance & Enforcement - Market surveillance framework: Regulation (EU) 2019/1020 applies to PPWR packaging (see recitals; and PPWR provisions on controls/communication). - Where packaging presents a risk or is non-compliant, market surveillance authorities can require corrective measures, withdrawal or recall; PPWR includes procedures for risk and safeguard measures (Arts. 58-60). - Controls on packaging entering the Union market and coordination with customs are addressed in Art. 61. - Penalties: Member States lay down rules on penalties for infringements; they must be effective, proportionate and dissuasive (Art. 68). ### Reporting & Data Requirements - Member State reporting on packaging waste generation and recycling targets is supported by calculation rules in Art. 53 and implementing powers in Art. 56(7) (including formats/methodologies). - Producer registration and reporting: Chapter VIII includes detailed registration/reporting requirements for producers and producer responsibility organisations (Art. 44 and related provisions). - Packaging waste management operators provide annual data to competent authorities and to producers/PROs as needed for producer reporting (Art. 23). ## Possible Outcomes ### [RESULT] Manufacturer/Importer Compliance Required Sustainability, labelling, conformity assessment - Ensure packaging meets all sustainability requirements (recyclability, recycled content, substances of concern, minimisation, etc.). - Carry out conformity assessment (Module A), draw up EU declaration of conformity, keep technical documentation for 10 years. - Affix required labels (material composition, reusable QR code, DRS label if applicable, substances of concern digital marking). - Affix name, registered trade name/trademark, and postal/electronic contact details on packaging or documentation. ### [RESULT] Distributor Compliance Required Due care and verification - Verify manufacturer/importer has met marking and documentation requirements before making packaging available. - Act with due care to ensure packaging complies with this Regulation. - Do not make non-compliant packaging available on the market. - Inform manufacturer/importer and market surveillance authorities of non-compliance. - Keep records of transactions for 10 years. ### [RESULT] Economic Operator Compliance Required Re-use, refill, empty space, restricted formats - Ensure grouped/transport/e-commerce packaging does not exceed 50% empty space ratio (unless reusable or exempted). - From 1 Jan 2030: do not place on the market packaging formats and uses listed in Annex V (Art. 25). - If using reusable packaging: ensure a re-use system is in place and comply with Annex VI requirements (Arts. 26-27 and Annex VI). - If you are a final distributor offering beverages: check the reusable packaging targets and take-back obligations in Art. 29(6) and 29(9)-(12). - Use only reusable transport packaging between sites/within one MS (unless exempted). - Achieve sustained reduction in plastic carrier bags or comply with national measures. ### [RESULT] Producer EPR Obligations Apply Finance waste management, meet targets, report - Register with competent authority as a producer (or join producer responsibility organisation). - Finance full waste management costs for packaging waste from your products (collection, sorting, recycling, disposal). - Pay EPR fees modulated by recyclability grade and recycled content. - Provide financial/organisational support for re-use systems. - Report annually under the producer registration/reporting requirements in Chapter VIII (Art. 44 and related provisions). - Support Member State objectives, including waste prevention targets (Art. 43) and recycling targets (Art. 52), through compliant packaging design and EPR scheme participation. ### [RESULT] Member State Obligations Targets, infrastructure, reporting, enforcement - Achieve packaging waste prevention targets: 5% by 2030, 10% by 2035, 15% by 2040 (per capita vs. 2018). - Achieve packaging waste recycling targets: 65% by 31 Dec 2025 and 70% by 31 Dec 2030 (overall) + material-specific targets for 2025 and 2030 (Art. 52). - Establish separate collection systems, sorting infrastructure, recycling capacity. - Designate competent authorities for EPR, market surveillance, enforcement. - Report annually to Commission on packaging placed on market, waste generated, collection/recycling rates, prevention measures. - Adopt national measures: economic instruments, deposit and return systems for certain beverage packaging (Art. 50), re-use and refill encouragement measures (Art. 51). ### [RESULT] Out of Scope PPWR does not directly apply - You do not place packaging on the Union market or generate packaging waste within the scope of this Regulation. - Even if not directly in scope, you may be impacted via supply chain requirements from PPWR-regulated customers. ## PPWR Timeline | Date | Event | Reference | | --- | --- | --- | | 2024-12-19 | PPWR adopted | Reg. (EU) 2025/40 | | 2025-01-22 | PPWR published in Official Journal (OJ L) | Reg. (EU) 2025/40 | | 2025-02-11 | PPWR enters into force (20 days after publication) | Reg. (EU) 2025/40 | | 2026-08-12 | PFAS restriction for food-contact packaging applies | Reg. (EU) 2025/40, Art. 5(5) | | 2026-08-12 | PPWR applies; Directive 94/62/EC is repealed (with specified exceptions) | Reg. (EU) 2025/40, Art. 70 | | 2026-08-12 | Commission implementing acts due for harmonised labels and specifications | Reg. (EU) 2025/40, Arts. 12(6)-(7) and 13(2) | | 2026-12-31 | Commission implementing acts due for recycled content methodology and documentation format | Reg. (EU) 2025/40, Art. 7(8) | | 2028-01-01 | Commission adopts delegated acts on recyclability criteria and performance grades (deadline) | Reg. (EU) 2025/40, Art. 6(4) | | 2028-02-12 | Compostable packaging requirements apply for specified packaging types | Reg. (EU) 2025/40, Art. 9(1) and 9(3) | | 2029-01-01 | Deposit and return systems required for certain beverage packaging (to reach 90% separate collection) | Reg. (EU) 2025/40, Art. 50(1)-(2) | | 2030-01-01 | Restrictions on certain packaging formats apply | Reg. (EU) 2025/40, Art. 25 and Annex V | | 2030-01-01 | Packaging minimisation requirements apply | Reg. (EU) 2025/40, Art. 10 | | 2030-01-01 | Packaging cannot be placed on the market unless recyclable within grades A/B/C (subject to timing rules) | Reg. (EU) 2025/40, Art. 6(3) | | 2035-01-01 | Recycled-at-scale condition applies for recyclability (subject to timing rules) | Reg. (EU) 2025/40, Art. 6(2)(b) | | 2038-01-01 | Packaging cannot be placed on the market unless recyclable within grades A or B | Reg. (EU) 2025/40, Art. 6(3) | | 2040-01-01 | Higher recycled content targets for plastic packaging apply | Reg. (EU) 2025/40, Art. 7(2) | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2022-11-30 | Legislative proposal published | Legislative milestones | COM(2022)0677 | | 2023-01-11 | Rapporteur Frederique Ries appointed | Legislative milestones | | | 2023-03-13 | Committee referral announced in Parliament, 1st reading | Legislative milestones | | | 2023-04-27 | EESC opinion published | Legislative milestones | | | 2023-06-15 | Referral to associated committees announced | Legislative milestones | | | 2023-10-24 | Vote in ENVI committee, 1st reading | Legislative milestones | | | 2023-11-06 | Committee report tabled for plenary, 1st reading | Legislative milestones | A9-0319/2023 | | 2023-11-21 | Debate in Parliament | Legislative milestones | | | 2023-11-22 | Decision by Parliament, 1st reading (partial vote) | Legislative milestones | T9-0425/2023 | | 2024-03-15 | Interinstitutional agreement reached | Legislative milestones | PE760.975; GEDA/A/(2024)001591 | | 2024-03-19 | ENVI approval of interinstitutional text | Legislative milestones | | | 2024-04-24 | Parliament adopts final text | Legislative milestones | T9-0318/2024 | | 2024-12-16 | Council adopts regulation | Legislative milestones | | | 2024-12-19 | Final act signed (adoption date) | Legislative milestones | Regulation (EU) 2025/40 | | 2025-01-22 | Publication in Official Journal | Legislative milestones | OJ L, 22.1.2025 | | 2026-08-12 | Regulation applies; Packaging Waste Directive repealed | Legislative milestones | | | 2026-08-12 | Commission implementing acts due for labels and digital marking | Implementing acts | | | 2026-08-12 | PFAS restriction for food-contact packaging applies | PFAS & harmful substances | | | 2029-01-01 | 90% collection target for single-use beverage containers | Deposit return systems | | | 2030-01-01 | Single-use plastic packaging bans take effect | Bans & restrictions | | | 2030-01-01 | All packaging must be recyclable | Recyclability & recycled content | | | 2030-01-01 | 5% packaging waste reduction target (vs 2018) | Packaging waste reduction | | | 2030-01-01 | Reuse and refill targets for 2030 | Reuse & refill | | | 2030-01-01 | Recycled content targets for plastic packaging (2030) | Recyclability & recycled content | | | 2034-08-12 | Commission evaluation report due | Legislative milestones | | | 2035-01-01 | 10% packaging waste reduction target (vs 2018) | Packaging waste reduction | | | 2035-01-01 | Recyclability criteria: recycled-at-scale assessment | Recyclability & recycled content | | | 2038-01-01 | Minimum recyclability grade B required | Recyclability & recycled content | | | 2040-01-01 | 15% packaging waste reduction target (vs 2018) | Packaging waste reduction | | | 2040-01-01 | Recycled content targets for plastic packaging (2040) | Recyclability & recycled content | | **Event details:** - **2022-11-30 - Legislative proposal published**: European Commission publishes legislative proposal COM(2022)0677 on packaging and packaging waste, including baseline statistics showing packaging waste increased from 66 million tonnes in 2009 to 84 million tonnes in 2021. - **2023-01-11 - Rapporteur Frederique Ries appointed**: European Parliament ENVI Committee appoints Frederique Ries (Renew, Belgium) as rapporteur for the Packaging and Packaging Waste Regulation. - **2023-03-13 - Committee referral announced in Parliament, 1st reading**: European Parliament announces referral to ENVI Committee as responsible committee for 1st reading of the packaging regulation. - **2023-04-27 - EESC opinion published**: European Economic and Social Committee issues its opinion (CES6037/2022) on the Commission proposal (dated 27 April 2023; referenced in the final regulation as published in OJ C 228 on 29 June 2023). - **2023-06-15 - Referral to associated committees announced**: European Parliament announces referral to associated committees ITRE and IMCO. - **2023-10-24 - Vote in ENVI committee, 1st reading**: European Parliament ENVI Committee votes on the draft report at first reading. - **2023-11-06 - Committee report tabled for plenary, 1st reading**: ENVI Committee report A9-0319/2023 tabled for plenary consideration at first reading. - **2023-11-21 - Debate in Parliament**: European Parliament holds plenary debate on the Packaging and Packaging Waste Regulation. - **2023-11-22 - Decision by Parliament, 1st reading (partial vote)**: Parliament adopts position at first reading (T9-0425/2023) and refers matter back to committee responsible for interinstitutional negotiations. - **2024-03-15 - Interinstitutional agreement reached**: European Parliament and Council reach provisional agreement on the final text of the Packaging and Packaging Waste Regulation. - **2024-03-19 - ENVI approval of interinstitutional text**: ENVI Committee approves the text agreed at first reading interinstitutional negotiations. - **2024-04-24 - Parliament adopts final text**: European Parliament adopts Regulation at 1st reading with 476 votes in favour, 129 against and 24 abstentions (T9-0318/2024). - **2024-12-16 - Council adopts regulation**: Council of the European Union formally adopts Regulation (EU) 2025/40 after Parliament's first reading. - **2024-12-19 - Final act signed (adoption date)**: Regulation (EU) 2025/40 of the European Parliament and of the Council on packaging and packaging waste is signed and adopted on 19 December 2024. - **2025-01-22 - Publication in Official Journal**: Regulation (EU) 2025/40 is published in the Official Journal of the European Union (OJ L series, 22 January 2025). - **2026-08-12 - Regulation applies; Packaging Waste Directive repealed**: Regulation (EU) 2025/40 applies from 12 August 2026. Directive 94/62/EC is repealed with effect from the same date, subject to transitional provisions. - **2026-08-12 - Commission implementing acts due for labels and digital marking**: By 12 August 2026, the Commission must adopt implementing acts for a harmonised label and related labelling specifications, and for a methodology to identify packaging material composition using standardised, open, digital marking technologies (plus related receptacle labelling specifications). - **2026-08-12 - PFAS restriction for food-contact packaging applies**: From 12 August 2026, food-contact packaging must not be placed on the market if it contains PFAS at or above the Regulation's specified limit values (subject to interaction with other Union restrictions). - **2029-01-01 - 90% collection target for single-use beverage containers**: By 2029, 90% of single-use plastic and metal beverage containers (up to three litres) must be collected separately through deposit-return systems or other solutions. - **2030-01-01 - Single-use plastic packaging bans take effect**: Certain single-use plastic packaging types banned from 1 January 2030: packaging for unprocessed fresh fruit and vegetables, foods and beverages filled and consumed in cafes and restaurants, individual portions (condiments, sauces, creamer, sugar), accommodation miniature toiletry packaging, and very lightweight plastic carrier bags (below 15 microns). - **2030-01-01 - All packaging must be recyclable**: All packaging (except lightweight wood, cork, textile, rubber, ceramic, porcelain and wax) must be recyclable by 2030, fulfilling strict criteria based on design for recycling. - **2030-01-01 - 5% packaging waste reduction target (vs 2018)**: Member States must achieve 5% reduction in packaging waste per capita compared to 2018 baseline figures. - **2030-01-01 - Reuse and refill targets for 2030**: Specific 2030 reuse targets apply for alcoholic and non-alcoholic beverages packaging, transport and sales packaging, grouped packaging. Final distributors must offer 10% of products in reusable packaging format. - **2030-01-01 - Recycled content targets for plastic packaging (2030)**: Plastic packaging must meet minimum recycled content targets by 2030, with increasing targets towards 2040. - **2034-08-12 - Commission evaluation report due**: By 12 August 2034, the Commission must evaluate the regulation and present a report on its main findings to the European Parliament, the Council, and advisory bodies. - **2035-01-01 - 10% packaging waste reduction target (vs 2018)**: Member States must achieve 10% reduction in packaging waste per capita compared to 2018 baseline figures. - **2035-01-01 - Recyclability criteria: recycled-at-scale assessment**: From 2035, recyclability assessment based on both design for recycling and recycled-at-scale criteria for packaging categories. - **2038-01-01 - Minimum recyclability grade B required**: From 1 January 2038, packaging must be at least recyclability grade B to be placed on the market. - **2040-01-01 - 15% packaging waste reduction target (vs 2018)**: Member States must achieve 15% reduction in packaging waste per capita compared to 2018 baseline figures, leading to an overall waste reduction in the EU of approximately 37% compared to business-as-usual scenario. - **2040-01-01 - Recycled content targets for plastic packaging (2040)**: Plastic packaging must meet higher recycled content targets by 2040. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/packaging-waste-regulation --- --- title: "EU Radio Equipment Directive (RED) 2014/53/EU" canonical_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive" source_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive" author: "Sorena AI" description: "A practical EU Radio Equipment Directive (RED) hub for Directive 2014/53/EU: confirm scope and Annex I exclusions, map essential requirements for safety, EMC." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Radio Equipment Directive" - "RED 2014/53/EU" - "EU RED compliance" - "CE marking radio equipment" - "technical documentation RED" - "EU declaration of conformity RED" - "harmonised standards RED" - "notified body RED" - "Delegated Regulation (EU) 2022/30" - "RED cybersecurity requirements Article 3(3)(d)(e)(f)" - "internet-connected radio equipment" - "wearable radio equipment" - "childcare radio equipment" - "common charger Directive (EU) 2022/2380 USB-C dates" - "RED" - "Directive 2014/53/EU" - "CE marking" - "Harmonised standards" - "Cybersecurity" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Radio Equipment Directive (RED) 2014/53/EU A practical EU Radio Equipment Directive (RED) hub for Directive 2014/53/EU: confirm scope and Annex I exclusions, map essential requirements for safety, EMC. ![EU RED artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-red-timeline-small.jpg?v=cheatsheets%2Fprod) *RED* *Free Resource* ## EU Radio Equipment Directive (RED) Timeline and Compliance Decision Flow Use this hub to confirm whether your product is radio equipment under Directive 2014/53/EU, map the essential requirements that apply (safety/health, EMC, spectrum, and where activated: cybersecurity), and plan the evidence you need for CE marking and EU market access. This is practical guidance, not legal advice. Scope and obligations depend on the product's radio features, intended use, and the standards and delegated/implementing acts that apply. [Run the RED applicability test](/artifacts/eu/radio-equipment-directive/applicability-test.md) ## What you can decide faster - **Is it in scope**: Radio equipment definition, exclusions, and borderline cases. - **Which essential requirements apply**: Safety/health, EMC, spectrum efficiency, and cybersecurity (EU) 2022/30. - **What evidence route to use**: Harmonised standards, notified body involvement, and CE documentation. By Sorena AI | Updated Mar 2026 | No signup required ### Quick scan *RED* - **Scope**: Confirm if it's radio equipment (and which exclusions apply). - **Cybersecurity**: Delegated Regulation (EU) 2022/30 applies from 1 Aug 2025 after the date change in Regulation (EU) 2023/2444. - **CE evidence**: Technical documentation + EU DoC + test plan aligned to standards and intended use. Use the decision flow to move from product facts to a repeatable RED compliance plan. | Value | Metric | | --- | --- | | 13 Jun 2016 | Applies | | 12 Jun 2017 | Transition ends | | 1 Aug 2025 | Cyber applies | | CE | Marking | **Key highlights:** Scope first | Cybersecurity | CE evidence ## Topic Guides - [Conformity Assessment and CE Marking | EU RED 2014/53/EU | Technical Documentation, EU DoC, Notified Bodies](/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce.md): A practical guide to RED conformity assessment and CE marking under Directive 2014/53/EU. - [Essential Requirements | EU Radio Equipment Directive (RED) 2014/53/EU | Safety, EMC, Spectrum, Cybersecurity (EU) 2022/30](/artifacts/eu/radio-equipment-directive/requirements.md): A practical RED essential requirements guide for Directive 2014/53/EU: map Article 3 requirements to product features and verification evidence for safety. - [Harmonised Standards and Test Plans | EU RED 2014/53/EU | Presumption of Conformity, OJ References, Verification Strategy](/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans.md): A practical guide to harmonised standards under the EU Radio Equipment Directive (RED) 2014/53/EU: how presumption of conformity works. - [RED Applicability Test | Is My Product in Scope of the EU Radio Equipment Directive (RED) 2014/53/EU?](/artifacts/eu/radio-equipment-directive/applicability-test.md): A structured RED applicability test for Directive 2014/53/EU: determine if your product is radio equipment, whether any exclusions apply. - [RED Compliance Checklist | EU Radio Equipment Directive 2014/53/EU | CE Marking Evidence Pack](/artifacts/eu/radio-equipment-directive/checklist.md): An audit-ready RED compliance checklist for Directive 2014/53/EU: scope and classification, essential requirements mapping (safety/health, EMC, spectrum). - [RED Compliance Program | EU Radio Equipment Directive 2014/53/EU Implementation Playbook](/artifacts/eu/radio-equipment-directive/compliance.md): A practical RED compliance program playbook for Directive 2014/53/EU: set up governance, map essential requirements to standards and tests. - [RED Conformity Assessment Template | CE Technical File Structure for Directive 2014/53/EU](/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template.md): A practical RED conformity assessment template for Directive 2014/53/EU: a CE technical file structure with sections for scope memo. - [RED Cybersecurity Delegated Act Guide | Implement Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025)](/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide.md): Step-by-step implementation guide for the RED cybersecurity delegated act. - [RED Cybersecurity Requirements | Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025) | Article 3(3)(d)(e)(f)](/artifacts/eu/radio-equipment-directive/cybersecurity-requirements.md): A practical RED cybersecurity requirements guide: Delegated Regulation (EU) 2022/30 activates Article 3(3)(d) network protection. - [RED Deadlines and Compliance Calendar | Directive 2014/53/EU Key Dates (2016-2026) | Cybersecurity 2025, Common Charger 2024/2026](/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar.md): A practical RED deadlines and compliance calendar: core RED dates (transposition by 12 Jun 2016; measures apply from 13 Jun 2016. - [RED FAQ | EU Radio Equipment Directive 2014/53/EU Questions | Scope, CE Marking, Cybersecurity (EU) 2022/30, Standards](/artifacts/eu/radio-equipment-directive/faq.md): A practical RED FAQ for Directive 2014/53/EU: what is radio equipment, what is in scope, what happened in the 2016/2017 transition. - [RED Penalties and Enforcement | EU Radio Equipment Directive 2014/53/EU | Market Surveillance, CE Documentation Risk](/artifacts/eu/radio-equipment-directive/penalties-and-fines.md): A practical RED enforcement and penalties guide for Directive 2014/53/EU: how market surveillance works in practice. - [RED Timeline | EU Radio Equipment Directive 2014/53/EU Roadmap | Cybersecurity (EU) 2022/30, Common Charger (EU) 2022/2380](/artifacts/eu/radio-equipment-directive/timeline.md): A practical RED timeline and roadmap: the core RED transition dates. - [RED vs Cyber Resilience Act (CRA) | RED Cybersecurity (EU) 2022/30 vs CRA (EU) 2024/2847 | What Overlaps, What's Different](/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act.md): A practical comparison of RED vs CRA: RED (Directive 2014/53/EU) is radio-equipment-specific and. - [Scope and Classification | EU Radio Equipment Directive (RED) 2014/53/EU | What Is Radio Equipment? Exclusions, Borderline Cases](/artifacts/eu/radio-equipment-directive/scope-and-classification.md): A practical RED scope and classification guide for Directive 2014/53/EU: what counts as radio equipment, which Annex I exclusions take products out of scope. ## Key dates for radio equipment teams *RED Timeline* Track the core RED dates, cybersecurity activation, and common charging interface amendments to plan releases and test cycles. ## Which RED obligations apply to your product *RED Decision Flow* Use the decision flow to confirm scope and essential requirements, then translate outcomes into evidence and documentation tasks. *Next step* ## Turn EU Radio Equipment Directive (RED) Timeline and Compliance Decision Flow into an operational assessment workflow EU Radio Equipment Directive (RED) Timeline and Compliance Decision Flow should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU Radio Equipment Directive (RED) Timeline and Compliance Decision Flow and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for EU Radio Equipment Directive (RED) Timeline and Compliance Decision Flow. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share compliance logic internally. - **Download timeline**: Align milestones across teams. - [Talk through EU Radio Equipment Directive (RED) Timeline and Compliance Decision Flow](/contact.md): Review your current process, evidence model, and next steps for EU Radio Equipment Directive (RED) Timeline and Compliance Decision Flow. ## Decision Steps ### STEP 1: Is your product radio equipment as defined in RED Article 2? *Reference: Art. 2* - Radio equipment = electrical or electronic product which intentionally emits or receives radio waves for the purpose of radio communication or radiodetermination, or electrical or electronic product which must be completed with an accessory (antenna or other) to emit/receive radio waves. - Radio communication = communication by means of radio waves. Radiodetermination = determination of the position, velocity or other characteristics of an object via radio waves (e.g., radar). - Check exclusions (Art. 1(2)-(3)): public security/defence/state security equipment, amateur radio, marine equipment under Directive 2014/90/EU, aviation equipment under Regulation (EU) 2018/1139, custom-built evaluation kits for professional use at R&D facilities. - **NO** Out of Scope - **YES** Does an exclusion in Article 1(2) or 1(3) apply to your product? ### STEP 2: Does an exclusion in Article 1(2) or 1(3) apply to your product? *Reference: Art. 1(2), 1(3)* - If yes: RED does not apply. Product is regulated by sector-specific legislation or is exempt from RED conformity assessment. - If no: continue to assess essential requirements and conformity assessment route. - **YES** Excluded from RED - **NO** Does Article 3(3) (additional essential requirements) apply to your radio equipment? ### STEP 3: Does Article 3(3) (additional essential requirements) apply to your radio equipment? *Reference: Art. 3(3)* - Art. 3(3) sets out additional essential requirements which apply only if Commission adopts a Delegated Act specifying that a category or class of radio equipment must comply. - Key delegated acts: Delegated Regulation (EU) 2022/30 (cybersecurity requirements for internet-connected radio equipment, wearable radio equipment, and certain other categories). - If your radio equipment falls within a category covered by a delegated act, you must comply with the corresponding Art. 3(3) point(s) (d, e, f, g, h, i). - If no delegated act applies to your category: only Art. 3(1) and 3(2) apply (plus interoperability/access/network features where the Commission has specified). - **YES** Is your radio equipment subject to Delegated Regulation (EU) 2022/30 (cybersecurity requirements)? - **NO** Does your radio equipment need to comply with interoperability or other Art. 3(3) requirements? ### STEP 4: Is your radio equipment subject to Delegated Regulation (EU) 2022/30 (cybersecurity requirements)? *Reference: Del. Reg. 2022/30* - Applies from 1 August 2024 to internet-connected radio equipment (equipment that can itself communicate over the internet, directly or via another device). - Also applies to: radio equipment for childcare, radio equipment covered by Directive 2009/48/EC (toys), wearable radio equipment (worn on the body, e.g., smartwatches, fitness trackers, smart glasses). - If yes: must comply with Art. 3(3)(d) (no harm to network), (e) (safeguards for personal data/privacy), and (f) (protection from fraud) where specified in Del. Reg. 2022/30. - Medical devices (Regulations 2017/745, 2017/746), vehicles (Reg. 2019/2144), aviation (Reg. 2018/1139), electronic road toll (Dir. 2019/520) are excluded if already subject to cybersecurity requirements under those regimes. - **YES** Does your radio equipment need to comply with interoperability or other Art. 3(3) requirements? - **NO** Does your radio equipment need to comply with interoperability or other Art. 3(3) requirements? ### STEP 5: Does your radio equipment need to comply with interoperability or other Art. 3(3) requirements? *Reference: Art. 3(3)(a)-(i)* - Art. 3(3)(a)-(c): Interworking via networks and with accessories (including common chargers), access to network interfaces, and related interoperability requirements. - Art. 3(3)(g): Access to emergency services. - Art. 3(3)(h): Support for users with disabilities. - Art. 3(3)(i): Software controls to prevent non-compliant combinations. - Commission specifies categories/classes via delegated acts. If no delegated act applies, these are not mandatory. Check delegated acts for your product category. - Common charger: Directive (EU) 2022/2380 amends RED and applies common charging interface requirements for listed categories and classes from 28 December 2024 (most categories) and 28 April 2026 (laptops). - -> Which conformity assessment procedure applies? ### STEP 6: Which conformity assessment procedure applies? - RED offers two routes: internal production control (Annex II, used by most manufacturers) or procedures involving Notified Bodies (Annex III or Annex IV). - Notified Body route is only required if harmonised standards do not cover all applicable essential requirements or if manufacturer chooses not to apply harmonised standards in full. - If all applicable essential requirements are covered by harmonised standards and manufacturer applies them in full: Annex II (internal production control) is available. - If not all requirements covered by harmonised standards or standards not applied: Annex III (EU-type examination + internal production control) or Annex IV (full quality assurance) with Notified Body involvement. - -> Do harmonised standards cover all applicable essential requirements for your radio equipment? ### STEP 7: Do harmonised standards cover all applicable essential requirements for your radio equipment? *Reference: Art. 17* - Harmonised standards referenced in the Official Journal provide presumption of conformity with the essential requirements they cover (Art. 17(1)). - If harmonised standards cover all applicable essential requirements (Art. 3(1), 3(2), and any applicable Art. 3(3) requirements) and manufacturer applies them in full: proceed via Annex II (internal production control). - If not all requirements covered, or if manufacturer chooses not to apply harmonised standards in full: Notified Body involvement required (Annex III or IV). - Check Commission Implementing Decisions on harmonised standards (e.g., Decisions 2022/2191, 2023/2392, 2025/138, 2025/893). - **YES** Internal Production Control (Self-Assessment) - **NO** Do you use full quality assurance with a notified body (Annex IV)? ### STEP 8: Do you use full quality assurance with a notified body (Annex IV)? - If yes: Annex IV route (notified body assesses and monitors the manufacturer's quality system covering design, manufacture and final product inspection/testing). - If no: Annex III route (EU-type examination by a notified body + conformity to type based on internal production control). - **NO** EU-Type Examination + Internal Production Control - **YES** Full Quality Assurance ### STEP 9: Does your radio equipment operate in non-harmonised frequency bands or is subject to national restrictions? *Reference: Art. 10(8), 10(10)* - Art. 10(8): Radio equipment that intentionally emits radio waves must be accompanied by information on the frequency bands and maximum RF output power with which it is able to operate in the EU. - Art. 10(10): If there are restrictions on putting into service or requirements to obtain authorisation to use the radio equipment in some Member States, manufacturer must provide information on such restrictions/requirements (format specified by Commission Implementing Regulation (EU) 2017/1354). - Check EFIS (European Frequency Information System) at efis.dk for national frequency usage information. - If restrictions or authorisation requirements exist: provide pictogram/text as per Implementing Reg. 2017/1354 on packaging and in instructions. - **YES** RED Compliance Achieved - **NO** RED Compliance Achieved ## Reference Information ### Product Scope (In Scope Overview) - All apparatus that intentionally emits or receives radio waves for radio communication or radiodetermination. - Includes transmitters, receivers, transceivers operating any radio frequency band, cellular phones, Wi-Fi devices, Bluetooth devices, IoT devices, RFID systems, radio broadcast receivers, satellite equipment, radars. - Infrared (IR) devices are excluded (no radio waves). - Fixed-line terminal equipment is excluded (covered by LVD/EMCD where applicable). - Components and accessories (e.g., antennas, amplifiers) may fall in scope depending on whether they meet the definition of radio equipment or are essential for radio functionality. ### Key Exclusions - Radio equipment used exclusively for activities concerning public security, defence, state security (including military) (Art. 1(2)(a)). - Radio equipment used by radio amateurs under CEPT Radio Amateur Licence or national authorisation (Art. 1(2)(b)). - Marine equipment on ships under Directive 2014/90/EU on marine equipment (Art. 1(2)(c)). - Aviation equipment subject to Regulation (EU) 2018/1139 (EU Aviation Safety) (Art. 1(2)(d)). - Custom-built evaluation kits intended for professionals for use solely at R&D facilities for R&D purposes (Art. 1(3)). ### Essential Requirements (All Radio Equipment) - Art. 3(1)(a): Protection of health and safety of persons and domestic animals, and protection of property (objectives of Directive 2014/35/EU LVD apply, no voltage limit). - Art. 3(1)(b): Adequate level of electromagnetic compatibility (requirements of Directive 2014/30/EU EMCD apply). - Art. 3(2): Radio equipment efficiently uses the radio spectrum allocated to terrestrial/space radiocommunication and orbital resources so as to avoid harmful interference. - All radio equipment must comply with Art. 3(1) and 3(2). ### Cybersecurity Requirements (Del. Reg. 2022/30) - Art. 3(3)(d): Radio equipment does not harm the network or its functioning, nor misuse network resources, thereby causing an unacceptable degradation of service. - Art. 3(3)(e): Radio equipment incorporates safeguards to ensure that personal data and privacy of the user and subscriber are protected (for internet-connected and certain other equipment). - Art. 3(3)(f): Radio equipment supports features ensuring protection from fraud (for internet-connected equipment that enables money/monetary value transfers). - Harmonised standards under Regulation (EU) 1025/2012 provide presumption of conformity with these requirements. ### Technical Documentation (Annex V) - General description of the radio equipment (intended use, frequency bands, maximum radio-frequency power). - Conceptual design and manufacturing drawings, diagrams of components, sub-assemblies, circuits. - Descriptions and explanations necessary to understand design, manufacture and operation. - List of harmonised standards applied in full or in part, or references to other technical specifications; description of solutions adopted to meet essential requirements if harmonised standards not applied. - Results of design calculations, examinations, test reports, etc. - Copy of information required under Art. 10(8)-(10) (frequency bands, restrictions on use, conformity information). - Technical documentation must be continuously updated (Art. 21) and kept for 10 years after placing on the market (Art. 10(4)). ### EU Declaration of Conformity (DoC) - EU declaration of conformity requirements are set out in Art. 18 and Annex VI. - Simplified DoC option: each item is accompanied by a simplified EU declaration of conformity (Art. 10(9)), with the full text available at the internet address stated in the simplified DoC (Art. 18). The simplified DoC contains the elements set out in Annex VII. - DoC must be continuously updated (Art. 18). - Translated into language(s) required by Member State where product is placed/made available. - Copy made available to market surveillance authorities upon request. - Keep DoC for 10 years after placing on market (Art. 10(4)). ### CE Marking and Identification - Affix CE marking visibly, legibly and indelibly to the radio equipment or its data plate (Art. 20(1)). - If nature of equipment does not allow, affix CE marking to packaging and accompanying documents (Art. 20(1)). - CE marking also affixed visibly and legibly to the packaging (Art. 20(1)). - The height of the CE marking may be lower than 5 mm if it remains visible and legible (Art. 19(2)). - If Annex IV is applied, the CE marking is followed by the identification number of the notified body (Art. 20(3)). - CE marking must be affixed before the radio equipment is placed on the market (Art. 20(2)). - Manufacturer name/registered trade name or trademark and postal address must be indicated on the equipment or (if not possible) on packaging or accompanying document (Art. 10(7)). ### Frequency and Restriction Information - Provide information on frequency bands in which the radio equipment operates and the maximum radio-frequency power transmitted in those bands (Art. 10(8)). - If restrictions on putting into service or authorisation requirements apply in certain Member States, include pictogram and/or text as specified in Commission Implementing Regulation (EU) 2017/1354 on packaging and in instructions (Art. 10(10)). - Example: equipment may require national authorisation for spectrum use or may be restricted to indoor use in some Member States. - Consult EFIS (European Frequency Information System) and national regulatory authorities for up-to-date information. ### Importer Obligations - Place on the market only compliant radio equipment; verify manufacturer has carried out conformity assessment (Art. 11(1)). - Verify technical documentation has been drawn up and radio equipment bears CE marking and is accompanied by required documents (Art. 11(1)). - Indicate name, registered trade name/trademark and postal address on the equipment or (if not possible) on packaging or accompanying document (Art. 11(3)). - Ensure equipment is accompanied by instructions and safety information in a language easily understood by consumers and users (Art. 11(4)). - Ensure that storage/transport conditions do not jeopardise compliance with essential requirements (Art. 11(5)). - Keep copy of DoC for 10 years and ensure technical documentation can be made available to market surveillance authorities upon request (Art. 11(6)). - If importer has reason to believe equipment is not compliant, take corrective action or withdraw/recall; inform market surveillance authorities (Art. 11(7)). ### Distributor Obligations - Verify that radio equipment bears CE marking, is accompanied by required documents (DoC, instructions, safety information) in required language, and that manufacturer and importer have complied with their labelling obligations (Art. 13(1)). - Ensure that storage/transport conditions do not jeopardise compliance (Art. 13(2)). - If distributor has reason to believe equipment is not compliant, shall not make it available until brought into compliance; inform market surveillance authorities if equipment presents a risk (Art. 13(3)). - Cooperate with market surveillance authorities and provide all information/documentation necessary to demonstrate conformity (Art. 13(4)). - Distributor placing equipment on market under own name/trademark or modifying equipment becomes a manufacturer and assumes manufacturer obligations (Art. 14). ### Market Surveillance and Enforcement - Market surveillance authorities in Member States monitor compliance with RED (Chapter VI). - Union market surveillance and control reference Regulation (EC) 765/2008 (Art. 39). - Non-compliant radio equipment: Member State requires economic operator to take corrective action, withdraw or recall (Art. 40). - Safeguard procedure: if Member State finds compliant radio equipment presents a risk, takes provisional measures and informs Commission; Commission decides via implementing act whether measure is justified (Arts. 41-42). - Formal non-compliance (CE marking affixed incorrectly, DoC missing/incorrect, etc.): Member State requires economic operator to put an end to non-compliance (Art. 43). - Member States must lay down rules on penalties for infringements (effective, proportionate, dissuasive) (Art. 46). ### R&TTE Directive Transition (Historical) - RED replaced the R&TTE Directive 1999/5/EC as of 13 June 2016 (Art. 49, Art. 50). - Transitional period: products placed on market before 13 June 2017 that conformed to R&TTE Directive were not impeded (Art. 48). - After 13 June 2017: all radio equipment must comply with RED. - Commission Decisions adopted under R&TTE Directive (e.g., on essential requirements for specific equipment) were reviewed; many were replaced or adapted under RED framework. ### Software and Compliance (Art. 3(3)(i)) - Radio equipment compliance may be affected by software loaded into it (Recital 16). - Art. 3(3)(i): Radio equipment supports certain features ensuring that software can only be loaded into it where compliance has been demonstrated (applies to categories/classes specified by Commission via delegated act). - Commission may adopt delegated acts requiring manufacturers to provide information on compliance of intended combinations of radio equipment and software (Art. 4). - Software controls must not be abused to prevent use of independent software; must support competition and availability of information (Recital 19). ### Registration Requirement (Art. 5) - Applies only for categories specified by Commission delegated acts (Art. 5(2)). - From 12 June 2018, manufacturers must register radio equipment types within those categories in a Commission central system before the equipment is placed on the market (Art. 5(1), 5(4)). - When registering, manufacturers provide some (or, where justified, all) specified elements of the technical documentation; the Commission allocates a registration number which is affixed on radio equipment placed on the market (Art. 5(1)). - Commission adopts implementing acts laying down operational rules for registration and for affixing the registration number (Art. 5(3)). - The central system ensures appropriate control of access to confidential information (Art. 5(4)). ### Essential Requirements Detail (Art. 3(1)) - Art. 3(1)(a) - Safety: objectives of Directive 2014/35/EU (LVD) apply with no voltage limit; includes protection of health/safety of persons and domestic animals, and protection of property. - Art. 3(1)(b) - EMC: adequate level of electromagnetic compatibility as set out in Directive 2014/30/EU (EMCD); radio equipment must not generate electromagnetic disturbance exceeding a level allowing radio and telecommunications equipment and other apparatus to operate as intended, and must have adequate intrinsic immunity to electromagnetic disturbance. - These requirements apply regardless of frequency bands or RF power level. ### Essential Requirements Detail (Art. 3(2)) - Art. 3(2): Radio equipment efficiently uses the radio spectrum allocated to terrestrial/space radiocommunication and orbital resources so as to avoid harmful interference. - Transmitter: when properly installed, maintained and used for intended purpose, generates radio waves emissions that do not create harmful interference; unwanted emissions limited to avoid harmful interference. - Receiver: has a level of performance allowing it to operate as intended and be protected against harmful interference (in particular from shared or adjacent channels), supporting efficient use of shared/adjacent channels. - This requirement ensures effective use of the radio spectrum, a limited natural resource. ## Possible Outcomes ### [ANNEX II] Internal Production Control (Self-Assessment) No Notified Body required - Manufacturer performs conformity assessment based on internal production control (Annex II). - Prepare technical documentation (Annex V) demonstrating compliance with applicable essential requirements. - Draw up EU Declaration of Conformity (Annex VI or VII for simplified DoC). - Affix CE marking to the product and its packaging (Art. 20). - Keep technical documentation and DoC for 10 years after placing on the market (Art. 10(4)). - This route is available for most radio equipment where harmonised standards cover all applicable essential requirements and are applied in full. ### [ANNEX III] EU-Type Examination + Internal Production Control Notified Body examines design - Submit technical documentation (Annex V) and a representative sample (type) to a Notified Body (Art. 17, Annex III). - Notified Body examines the technical design and verifies compliance with applicable essential requirements and issues EU-type examination certificate. - Manufacturer ensures manufactured products conform to the approved type (internal production control). - Draw up EU Declaration of Conformity (Annex VI or VII). - Affix CE marking to the product and its packaging (Art. 20). - Keep copy of EU-type examination certificate, technical documentation and DoC for 10 years. ### [ANNEX IV] Full Quality Assurance Notified Body assesses quality system - Operate an approved quality system for design, manufacture, final inspection and testing (Annex IV). - Lodge application with a Notified Body for assessment of your quality system (Art. 17, Annex IV). - Notified Body conducts quality system assessment and surveillance (including periodic audits). - Draw up EU Declaration of Conformity (Annex VI or VII). - Affix CE marking and identification number of Notified Body (Art. 20). - Keep technical documentation (Annex V) and quality system documentation for 10 years. ### [RESULT] Out of Scope RED does not apply - Your product does not meet the definition of radio equipment (Art. 2), or an exclusion applies (Art. 1(2)-(3)). - Check whether other EU legislation applies (e.g., LVD 2014/35/EU, EMCD 2014/30/EU, sector-specific directives). - If your product is an accessory or component to be incorporated into radio equipment, it may be subject to requirements under other legislation or contractual obligations with the radio equipment manufacturer. ### [RESULT] Excluded from RED Sector-specific legislation applies - Your radio equipment falls under an exclusion in Art. 1(2) or 1(3) of RED. - If exclusion is due to sector-specific legislation (marine equipment Directive 2014/90/EU, aviation Regulation 2018/1139): comply with that legislation. - If exclusion is due to use (public security/defence/amateur radio): follow applicable national or international rules. - If custom-built evaluation kit: use exclusively at R&D facilities for R&D purposes as per Art. 1(3). ### [RESULT] RED Compliance Achieved Ready to place on market - You have completed conformity assessment via the appropriate procedure (Annex II, III or IV). - Technical documentation (Annex V) and EU Declaration of Conformity (Annex VI or VII) are prepared and will be kept for 10 years. - CE marking (and Notified Body ID number if applicable) is affixed to the product and packaging. - Required information (frequency bands, restrictions, instructions) accompanies the product as per Art. 10(8)-(10). - Economic operator identification (manufacturer, importer if applicable) is indicated on product or packaging (Art. 10(7), 11(3)). - You may place the radio equipment on the EU market and (subject to any national spectrum authorisation or restrictions) put it into service. ## RED Timeline | Date | Event | Reference | | --- | --- | --- | | 2014-04-16 | RED adopted | Directive 2014/53/EU | | 2014-05-22 | RED published in Official Journal (OJ L 153) | Directive 2014/53/EU | | 2016-06-12 | Member States transpose RED (deadline) | Art. 49 | | 2016-06-13 | RED applies; R&TTE Directive 1999/5/EC repealed | Art. 49 | | 2017-06-12 | End of transitional period for R&TTE Directive 1999/5/EC equipment | Art. 48 | | 2022-01-12 | Delegated Regulation (EU) 2022/30 published (cybersecurity requirements) | Del. Reg. 2022/30 | | 2024-08-01 | Delegated Regulation (EU) 2022/30 applies | Del. Reg. 2022/30 Art. 3 | | 2024-12-28 | Common charger requirements apply (most categories) | Directive (EU) 2022/2380 | | 2026-04-28 | Common charger requirements apply (laptops) | Directive (EU) 2022/2380 | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2014-04-16 | Radio Equipment Directive Adopted | Directive | | | 2014-05-22 | RED Published in Official Journal | Directive | | | 2014-06-11 | RED enters into force | Directive | | | 2015-08-04 | Standardization Request to ETSI and Cenelec | Implementing Decision | | | 2016-06-12 | Member States Transposition Deadline | Directive | | | 2016-06-13 | RED Application Date - Directive 1999/5/EC Repealed | Directive | | | 2017-06-13 | Equipment Placement Cutoff Date | Directive | | | 2017-07-20 | Implementing Regulation on Equipment Labeling | Implementing Decision | | | 2017-08-08 | Early conformity presumption for restrictions label | Implementing Decision | | | 2018-06-12 | Type registration required for certain radio equipment | Directive | | | 2018-08-09 | Labeling Requirements Apply | Implementing Decision | | | 2018-10-11 | Harmonization of 874-876 and 915-921 MHz Bands | Implementing Decision | | | 2018-12-12 | Emergency caller-location delegated regulation adopted | Delegated Regulation | | | 2019-02-01 | Spectrum harmonisation implementation deadline | Implementing Decision | | | 2021-10-29 | Cybersecurity Delegated Regulation Adopted | Cybersecurity | | | 2022-01-12 | Cybersecurity Regulation Published | Cybersecurity | | | 2022-03-17 | Emergency caller-location rules apply | Delegated Regulation | | | 2022-08-05 | Standardization Request for Cybersecurity | Cybersecurity | | | 2022-11-08 | First Harmonized Standards Decision | Harmonized Standards | | | 2022-11-23 | Common charger directive adopted (amending RED) | Directive | | | 2023-07-20 | Cybersecurity Regulation Amendment | Cybersecurity | | | 2023-10-03 | Harmonized Standards Update | Harmonized Standards | | | 2023-11-27 | Wireless devices near the body standards updated | Harmonized Standards | | | 2023-12-28 | Common charger transposition deadline | Directive | | | 2024-08-01 | Cybersecurity Requirements Apply | Cybersecurity | | | 2024-12-28 | Common charger requirements apply (most categories) | Directive | | | 2025-01-28 | Cybersecurity Standards Published | Cybersecurity | | | 2025-04-04 | IMT Standards Apply | Harmonized Standards | | | 2025-05-14 | Harmonized Standards for DECT, SRD, IMT, Radars | Harmonized Standards | | | 2025-06-01 | Updated EMF standards start applying | Harmonized Standards | | | 2026-04-28 | Common charger requirements apply (laptops) | Directive | | | 2026-11-15 | Additional Standards Apply | Harmonized Standards | | | 2028-05-15 | Final Standards Transition Deadline | Harmonized Standards | | **Event details:** - **2014-04-16 - Radio Equipment Directive Adopted**: Directive 2014/53/EU adopted by European Parliament and Council, harmonizing laws for making radio equipment available on EU market - **2014-05-22 - RED Published in Official Journal**: Directive 2014/53/EU published in Official Journal (OJ L 153) - **2014-06-11 - RED enters into force**: Directive 2014/53/EU enters into force on 11 June 2014. - **2015-08-04 - Standardization Request to ETSI and Cenelec**: Commission Implementing Decision C(2015) 5376 requesting ETSI and Cenelec to draft harmonized standards for radio equipment - **2016-06-12 - Member States Transposition Deadline**: Deadline for Member States to adopt and publish national laws implementing Directive 2014/53/EU - **2016-06-13 - RED Application Date - Directive 1999/5/EC Repealed**: Directive 2014/53/EU applies, Directive 1999/5/EC repealed. Member States must not impede conforming equipment - **2017-06-13 - Equipment Placement Cutoff Date**: Member States must not impede radio equipment placed on market before this date and conforming to previous legislation - **2017-07-20 - Implementing Regulation on Equipment Labeling**: Commission Implementing Regulation (EU) 2017/1354 specifying presentation of restrictions information under Article 10(10) - **2017-08-08 - Early conformity presumption for restrictions label**: Radio equipment placed on the market after 8 August 2017 and in conformity with Implementing Regulation (EU) 2017/1354 is deemed to be in conformity with RED Article 10(10). - **2018-06-12 - Type registration required for certain radio equipment**: From 12 June 2018, manufacturers must register radio equipment types in specified categories (where required) in a central system before placing the equipment on the market. - **2018-08-09 - Labeling Requirements Apply**: Implementing Regulation (EU) 2017/1354 on labeling and restrictions information becomes applicable - **2018-10-11 - Harmonization of 874-876 and 915-921 MHz Bands**: Commission Implementing Decision (EU) 2018/1538 on spectrum harmonization for short-range devices and IoT - **2018-12-12 - Emergency caller-location delegated regulation adopted**: Commission Delegated Regulation (EU) 2019/320 adopted to apply essential requirements ensuring caller location in emergency communications from mobile devices (RED Article 3(3)(g)). - **2019-02-01 - Spectrum harmonisation implementation deadline**: Member States deadline to implement the spectrum harmonisation measures under Implementing Decision (EU) 2018/1538. - **2021-10-29 - Cybersecurity Delegated Regulation Adopted**: Commission adopts Delegated Regulation (EU) 2022/30 on cybersecurity requirements for Article 3(3) points (d), (e), (f) - **2022-01-12 - Cybersecurity Regulation Published**: Delegated Regulation (EU) 2022/30 published in Official Journal (OJ L 7) - **2022-03-17 - Emergency caller-location rules apply**: Delegated Regulation (EU) 2019/320 becomes applicable, applying essential requirements ensuring caller location in emergency communications from mobile devices. - **2022-08-05 - Standardization Request for Cybersecurity**: Commission Implementing Decision C(2022) 5637 requesting CEN and Cenelec to draft harmonized standards for cybersecurity - **2022-11-08 - First Harmonized Standards Decision**: Commission Implementing Decision (EU) 2022/2191 on harmonized standards for radio equipment - **2022-11-23 - Common charger directive adopted (amending RED)**: Directive (EU) 2022/2380 adopted, amending Directive 2014/53/EU to introduce common charging interface requirements for certain categories/classes of radio equipment. - **2023-07-20 - Cybersecurity Regulation Amendment**: Delegated Regulation (EU) 2023/2444 adopted, postponing application date and correcting Regulation 2022/30 - **2023-10-03 - Harmonized Standards Update**: Implementing Decision (EU) 2023/2392 amending Decision 2022/2191 for IMT, DAB, DRM, maritime devices, satellite systems - **2023-11-27 - Wireless devices near the body standards updated**: Implementing Decision (EU) 2023/2669 updates harmonised standards for wireless communication devices used next to the ear or in close proximity to the human body. - **2023-12-28 - Common charger transposition deadline**: Deadline for Member States to adopt and publish laws implementing Directive (EU) 2022/2380. - **2024-08-01 - Cybersecurity Requirements Apply**: Delegated Regulation (EU) 2022/30 as amended by Regulation (EU) 2023/2444 becomes applicable for the specified categories and classes of radio equipment. - **2024-12-28 - Common charger requirements apply (most categories)**: Member States apply measures implementing Directive (EU) 2022/2380 for categories/classes of radio equipment listed in Annex Ia Part I points 1.1-1.12. - **2025-01-28 - Cybersecurity Standards Published**: Implementing Decision (EU) 2025/138 publishing EN 18031-1, EN 18031-2, EN 18031-3 cybersecurity standards - **2025-04-04 - IMT Standards Apply**: Point (1) of Annex to Implementing Decision (EU) 2023/2392 becomes applicable (EN 301 908-1 V15.2.1) - **2025-05-14 - Harmonized Standards for DECT, SRD, IMT, Radars**: Implementing Decision (EU) 2025/893 amending Decision 2022/2191 for DECT, short range devices, satellite systems, IMT, radars, WLAN - **2025-06-01 - Updated EMF standards start applying**: The update under Implementing Decision (EU) 2023/2669 starts applying (Annex point (1) applies from 1 June 2025). - **2026-04-28 - Common charger requirements apply (laptops)**: Member States apply measures implementing Directive (EU) 2022/2380 for the category/class of radio equipment listed in Annex Ia Part I point 1.13 (laptops). - **2026-11-15 - Additional Standards Apply**: Point (2) of Annex to Implementing Decision (EU) 2025/893 becomes applicable for specified harmonized standards - **2028-05-15 - Final Standards Transition Deadline**: Point (3) of Annex to Implementing Decision (EU) 2025/893 becomes applicable --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/radio-equipment-directive --- --- title: "EU RoHS Directive (2011/65/EU)" canonical_url: "https://www.sorena.io/artifacts/eu/rohs-directive" source_url: "https://www.sorena.io/artifacts/eu/rohs-directive" author: "Sorena AI" description: "A practical EU RoHS hub for Directive 2011/65/EU (including amendments such as (EU) 2015/863 phthalates): confirm EEE scope." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RoHS Directive 2011/65/EU" - "EU RoHS compliance" - "RoHS restricted substances" - "RoHS homogeneous material threshold 0.1%" - "RoHS cadmium 0.01%" - "RoHS phthalates 2015/863 2019" - "RoHS exemptions Annex III Annex IV" - "RoHS exemption tracking" - "EN IEC 63000 technical documentation" - "CE marking RoHS" - "RoHS supplier declaration template" - "RoHS vs REACH" - "RoHS" - "Directive 2011/65/EU" - "Restricted substances" - "Exemptions" - "EN IEC 63000" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU RoHS Directive (2011/65/EU) A practical EU RoHS hub for Directive 2011/65/EU (including amendments such as (EU) 2015/863 phthalates): confirm EEE scope. ![EU RoHS artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-rohs-timeline-small.jpg?v=cheatsheets%2Fprod) *RoHS* *Free Resource* ## EU Restriction of Hazardous Substances (RoHS) Timeline and Exemptions Decision Flow Use this hub to confirm RoHS scope for electrical and electronic equipment (EEE), apply the restricted substances thresholds in homogeneous materials, and run an exemption and evidence workflow that holds up in audits and market surveillance requests. This is practical guidance, not legal advice. Always validate scope and exemptions against the consolidated Directive 2011/65/EU and the latest official exemption updates. [Run the RoHS applicability test](/artifacts/eu/rohs-directive/applicability-test.md) ## What you can decide faster - **In scope**: EEE categories, exclusions, and borderline cases. - **Restricted substances**: Homogeneous material thresholds + where substances hide in a BOM. - **Exemptions**: Annex III/IV eligibility, evidence, expiry risk, and change control. - **Operator duties**: Manufacturer, importer, and distributor checks plus 10 year document retention. By Sorena AI | Updated Feb 2026 | No signup required ### Quick scan *RoHS* - **Substances**: 10 restricted substances and two key thresholds (0.1% / 0.01%). - **Exemptions**: Expiry is a product risk; treat exemptions like expiring certificates. - **Evidence**: Supplier declarations, risk-based testing, and EN IEC 63000 technical documentation. Use the decision flow to align engineering, quality, and suppliers on what is allowed and what needs proof. | Value | Metric | | --- | --- | | 2011/65/EU | Directive | | 10 | Substances | | EN IEC 63000 | Tech docs | | 18 months | Renewal deadline | **Key highlights:** Homogeneous material | Exemption tracking | Supplier evidence ## Topic Guides - [EU RoHS FAQ (Scope, Exemptions, Phthalates, Technical File, CE) | RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/faq.md): High-signal EU RoHS FAQ grounded in official sources: what counts as EEE, staged applicability (22 July 2014/2017/2019). - [EU RoHS Timeline: RoHS 1 (2002) -> RoHS 2 (2011/2013) -> Open Scope (2019) -> Phthalates (2019/2021)](/artifacts/eu/rohs-directive/timeline.md): A date-by-date EU RoHS timeline for implementers: RoHS 1 (2002), RoHS 2 recast and transposition (2011 - 2013). - [Restricted Substances and Thresholds | EU RoHS Directive 2011/65/EU | Homogeneous Material Limits (0.1% / 0.01%) + Phthalates (2015/863)](/artifacts/eu/rohs-directive/restricted-substances-and-thresholds.md): A practical RoHS restricted substances guide for Directive 2011/65/EU: the 10 substances in Annex II, homogeneous material threshold logic (0.1% for most. - [RoHS Applicability Test | Is My Product In Scope of EU RoHS Directive 2011/65/EU? | EEE, Cables, Spare Parts, Open Scope](/artifacts/eu/rohs-directive/applicability-test.md): A structured EU RoHS applicability test for Directive 2011/65/EU: determine if your product is electrical and electronic equipment (EEE). - [RoHS Compliance Checklist | EU RoHS Directive 2011/65/EU | Supplier Evidence, Exemptions, EN IEC 63000 Technical File](/artifacts/eu/rohs-directive/checklist.md): An audit-ready RoHS compliance checklist for Directive 2011/65/EU: scope and EEE category mapping. - [RoHS Compliance Program | EU RoHS Directive 2011/65/EU Implementation Playbook | Supplier Controls, Exemptions, Evidence](/artifacts/eu/rohs-directive/compliance.md): A practical RoHS compliance program playbook for Directive 2011/65/EU: set up governance, map homogeneous material risks across your BOM. - [RoHS Deadlines and Compliance Calendar (2013, 2014, 2017, 2019, 2021) | EU RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar.md): A RoHS compliance calendar you can actually operationalize: staged applicability dates (22 July 2014/2017/2019). - [RoHS Enforcement, Penalties, and Fines | EU RoHS Directive 2011/65/EU (Member State rules)](/artifacts/eu/rohs-directive/penalties-and-fines.md): What EU RoHS enforcement looks like in practice: market surveillance checks, documentation requests, CE marking scrutiny. - [RoHS Exemptions Tracker Guide | How to Build an Exemption Register (Annex III/IV), Link to BOM, Monitor Expiry](/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide.md): A practical guide to building a RoHS exemptions tracker: recommended tracker fields (exemption reference, exact wording, scope conditions. - [RoHS Exemptions Tracking | Directive 2011/65/EU Annex III and Annex IV | Expiry Risk, Evidence, Renewal Strategy](/artifacts/eu/rohs-directive/exemptions-tracking.md): A practical RoHS exemptions tracking guide for Directive 2011/65/EU: how Annex III and Annex IV exemptions work. - [RoHS Requirements | EU RoHS Directive 2011/65/EU | Substance Restrictions (Annex II), Exemptions (Annex III/IV), CE Evidence](/artifacts/eu/rohs-directive/requirements.md): A practical RoHS requirements breakdown for Directive 2011/65/EU: restricted substances thresholds in homogeneous materials (Annex II). - [RoHS Supplier Declaration Template | Annex II Substances, Homogeneous Material Coverage, Exemptions Disclosure](/artifacts/eu/rohs-directive/rohs-supplier-declaration-template.md): A practical RoHS supplier declaration template for Directive 2011/65/EU. - [RoHS vs REACH | What's the Difference? | EU RoHS Directive 2011/65/EU vs REACH Regulation (EC) 1907/2006](/artifacts/eu/rohs-directive/rohs-vs-reach.md): A practical RoHS vs REACH guide: RoHS (Directive 2011/65/EU) restricts specific substances in EEE above thresholds in homogeneous materials and is tied to CE. - [Supplier Declarations and Verification | RoHS Compliance Program | Supplier Questionnaires, Change Control, Risk-Based Testing](/artifacts/eu/rohs-directive/supplier-declarations-and-verification.md): A practical supplier evidence playbook for EU RoHS Directive 2011/65/EU. - [Technical Documentation and CE | RoHS Directive 2011/65/EU | EN IEC 63000, EU Declaration of Conformity, Evidence Vault](/artifacts/eu/rohs-directive/technical-documentation-and-ce.md): A practical RoHS technical documentation guide for Directive 2011/65/EU. ## Key dates for materials compliance *RoHS Timeline* Track RoHS milestones across amendments, staged category dates, phthalates cutovers, and exemption renewal timing that impact engineering and procurement. ## Does RoHS apply to your equipment *RoHS Decision Flow* Use the decision flow to confirm scope, identify restricted substances exposure, decide whether an exemption is relevant, and build the evidence needed for Article 7, 9, and 10 duties. *Next step* ## Turn EU Restriction of Hazardous Substances (RoHS) Timeline and Exemptions Decision Flow into an operational assessment workflow EU Restriction of Hazardous Substances (RoHS) Timeline and Exemptions Decision Flow should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU Restriction of Hazardous Substances (RoHS) Timeline and Exemptions Decision Flow and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for EU Restriction of Hazardous Substances (RoHS) Timeline and Exemptions Decision Flow. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - **Download decision flow**: Share restriction + exemption logic internally. - **Download timeline**: Coordinate milestones across teams. - [Talk through EU Restriction of Hazardous Substances (RoHS) Timeline and Exemptions Decision Flow](/contact.md): Review your current process, evidence model, and next steps for EU Restriction of Hazardous Substances (RoHS) Timeline and Exemptions Decision Flow. ## Decision Steps ### STEP 1: Is your product Electrical and Electronic Equipment (EEE)? *Reference: Art. 3(1)* - EEE = equipment dependent on electric currents or electromagnetic fields to work properly, designed for voltage rating not exceeding 1000V AC or 1500V DC. - 'Dependent' means needing electric currents or electromagnetic fields to fulfil at least one intended function. - Includes equipment for generation, transfer and measurement of such currents and fields. - **NO** Out of RoHS Scope - **YES** Does an Article 2(4) exclusion apply to your EEE? ### STEP 2: Does an Article 2(4) exclusion apply to your EEE? *Reference: Art. 2(4)* - If yes: RoHS does not apply. - If no: continue to substance restrictions and compliance requirements. - **YES** Out of RoHS Scope - **NO** Your EEE is within RoHS scope ### IN SCOPE: Your EEE is within RoHS scope *Reference: Art. 2(1)* - Your EEE must comply with substance restrictions (Art. 4) and conformity assessment requirements (Arts. 7-15). - Check when substance restrictions apply based on your EEE category (see timeline). - -> Do any Annex II substances exceed the maximum concentration values in any homogeneous material? ### STEP 3: Do any Annex II substances exceed the maximum concentration values in any homogeneous material? *Reference: Art. 4(1)-(2) and Annex II* - RoHS prohibits placing EEE on the market if it contains restricted substances above the Annex II limits in any homogeneous material. - If no: proceed with conformity assessment, declaration of conformity, and CE marking. - If yes: continue to exemptions and transitional provisions. - **YES** Does your application benefit from an exemption in Annex III or IV? - **NO** Manufacturer: Have you completed the conformity assessment? ### STEP 4: Does your application benefit from an exemption in Annex III or IV? *Reference: Art. 4(6) & Art. 5* - Annex III lists exemptions for all EEE categories. - Annex IV lists exemptions specific to medical devices (category 8) and monitoring/control instruments (category 9). - Exemptions have validity periods and may expire. - If your application is exempt: you may use the restricted substance for that specific application (and proceed with conformity assessment). - If not exempt: check transitional provisions for cables and spare parts (Art. 4(4)) and reused spare parts (Art. 4(5)), or consider substitution or applying for an exemption under Article 5. - **YES** Manufacturer: Have you completed the conformity assessment? - **NO** Are you placing on the market cables or spare parts for existing EEE? ### STEP 5: Are you placing on the market cables or spare parts for existing EEE? *Reference: Art. 4(4)* - Article 4(4) provides transitional provisions for cables and spare parts for repair, reuse, updating or upgrading of EEE placed on the market before the substance restrictions applied to that EEE category. - If yes: check the Art. 4(4) dates for your EEE category and proceed with conformity assessment steps. - If no: check whether you qualify for the reused spare parts conditions in Art. 4(5). - **YES** Manufacturer: Have you completed the conformity assessment? - **NO** Are you using reused spare parts in an auditable closed-loop B2B return system and notifying the consumer? ### STEP 6: Are you using reused spare parts in an auditable closed-loop B2B return system and notifying the consumer? *Reference: Art. 4(5)* - Article 4(5) allows reuse of spare parts containing restricted substances if reuse takes place in auditable closed-loop business-to-business return systems and reuse is notified to the consumer. - If yes: check the Art. 4(5) time limits and proceed with conformity assessment steps. - If no: substitution or an exemption under Article 5 may be needed before the EEE can be placed on the market. - **YES** Manufacturer: Have you completed the conformity assessment? - **NO** Application Uses Restricted Substance - Check Exemptions ### STEP 7: Manufacturer: Have you completed the conformity assessment? *Reference: Art. 7(b)-(c)* - Draw up required technical documentation and carry out internal production control (Module A of Annex II to Decision 768/2008/EC). - Draw up EU Declaration of Conformity (DoC) and affix CE marking on the finished product. - Keep technical documentation and DoC for 10 years after placing EEE on market. - **YES** RoHS Compliant - Ready for EU Market - **NO** Non-Compliant - Cannot Be Placed on EU Market ## Reference Information ### What is EEE? - Electrical and Electronic Equipment (EEE) depends on electric currents or electromagnetic fields to work properly. - EEE also includes equipment for generation, transfer and measurement of such currents and fields. - Voltage rating: not exceeding 1000V AC or 1500V DC. - Equipment without electrical or electronic parts (for example compact discs and optical cables) is outside the scope of RoHS 2. ### EEE Categories (Annex I) - 1. Large household appliances - 2. Small household appliances - 3. IT and telecommunications equipment - 4. Consumer equipment - 5. Lighting equipment - 6. Electrical and electronic tools (except large-scale stationary industrial tools) - 7. Toys, leisure and sports equipment - 8. Medical devices (including in vitro diagnostic medical devices) - 9. Monitoring and control instruments (including industrial monitoring and control instruments) - 10. Automatic dispensers - 11. Other EEE not covered by categories 1-10 (open scope from 22 July 2019) ### Article 2(4) Exclusions - (a) Equipment necessary for protection of essential security interests of Member States, including arms, munitions and war material for military purposes. - (b) Equipment designed to be sent into space. - (c) Equipment specifically designed and to be installed as part of another type of equipment excluded or outside RoHS scope, which can only function as part of that equipment, and can only be replaced by the same specifically designed equipment. - (d) Large-scale stationary industrial tools. - (e) Large-scale fixed installations. - (f) Means of transport for persons or goods (excluding electric two-wheel vehicles which are not type-approved). - (g) Non-road mobile machinery made available exclusively for professional use. - (h) Active implantable medical devices. - (i) Photovoltaic panels in systems designed, assembled and installed by professionals for permanent use at a defined location to produce energy from solar light. - (j) Equipment specifically designed solely for research and development only made available on a business-to-business basis. - (k) Pipe organs. ### Restricted Substances (Annex II) - 1. Lead (Pb) - max 0.1% by weight in homogeneous materials - 2. Mercury (Hg) - max 0.1% by weight in homogeneous materials - 3. Cadmium (Cd) - max 0.01% by weight in homogeneous materials - 4. Hexavalent chromium (Cr(VI)) - max 0.1% by weight in homogeneous materials - 5. Polybrominated biphenyls (PBB) - max 0.1% by weight in homogeneous materials - 6. Polybrominated diphenyl ethers (PBDE) - max 0.1% by weight in homogeneous materials - 7. Bis(2-ethylhexyl) phthalate (DEHP) - max 0.1% by weight in homogeneous materials (from 22 July 2019; medical/monitoring devices from 22 July 2021) - 8. Butyl benzyl phthalate (BBP) - max 0.1% by weight in homogeneous materials (from 22 July 2019; medical/monitoring devices from 22 July 2021) - 9. Dibutyl phthalate (DBP) - max 0.1% by weight in homogeneous materials (from 22 July 2019; medical/monitoring devices from 22 July 2021) - 10. Diisobutyl phthalate (DIBP) - max 0.1% by weight in homogeneous materials (from 22 July 2019; medical/monitoring devices from 22 July 2021) ### Homogeneous Material - Homogeneous material = one material of uniform composition throughout, or a material consisting of a combination of materials that cannot be disjointed or separated into different materials by mechanical actions such as unscrewing, cutting, crushing, grinding and abrasive processes (Art. 3(20)). - Maximum concentration values apply by weight in homogeneous materials (Art. 4(2)). ### Exemptions (Annex III & IV) - Exemptions allow specific applications to use restricted substances where elimination or substitution is scientifically/technically impracticable, reliability of substitutes is not ensured, or substitution would cause greater harm (Art. 5(1)). - Annex III: exemptions for categories 1-7, 10, 11 (validity up to 5 years, renewable). - Annex IV: exemptions for categories 8 and 9 (medical devices and monitoring/control instruments; validity up to 7 years, renewable). - Exemptions are specific to the application and may include scope and expiry dates. - Exemption applications must be submitted 18 months before expiry (Art. 5(5)). - Existing exemptions remain valid until Commission decision on renewal (Art. 5(5)). ### Spare Parts & Cables (Art. 4(4)) - Article 4(1) does not apply to cables or spare parts for repair, reuse, updating or upgrading of: - (a) EEE placed on the market before 1 July 2006 (RoHS 1 start). - (b) Medical devices placed on the market before 22 July 2014. - (c) In vitro diagnostic medical devices placed on the market before 22 July 2016. - (d) Monitoring and control instruments placed on the market before 22 July 2014. - (e) Industrial monitoring and control instruments placed on the market before 22 July 2017. - (ea) All other EEE that was outside RoHS 1 scope and placed on the market before 22 July 2019. - (f) EEE which benefited from an exemption and was placed on the market before that exemption expired (for that specific exemption). ### Reused Spare Parts (Art. 4(5)) - Provided that reuse takes place in auditable closed-loop business-to-business return systems, and that reuse is notified to the consumer, Art. 4(1) does not apply to reused spare parts: - (a) Recovered from EEE placed on market before 1 July 2006 and used in EEE placed on market before 1 July 2016. - (b) Recovered from medical/monitoring devices placed on market before 22 July 2014 and used in EEE placed on market before 22 July 2024. - (c) Recovered from in vitro diagnostic medical devices placed on market before 22 July 2016 and used in EEE placed on market before 22 July 2026. - (d) Recovered from industrial monitoring/control instruments placed on market before 22 July 2017 and used in EEE placed on market before 22 July 2027. - (e) Recovered from all other EEE outside RoHS 1 scope placed on market before 22 July 2019 and used in EEE placed on market before 22 July 2029. ### Technical Documentation (Art. 7(b)) - Manufacturers must draw up the required technical documentation and carry out internal production control (Art. 7(b)). - Harmonised standard EN IEC 63000:2018 is referenced for the technical documentation required for assessing materials, components and EEE under RoHS (Implementing Decision (EU) 2020/659). - Keep documentation for 10 years after placing EEE on market (Art. 7(d)). - Provide documentation to competent authorities upon request (Art. 7(j)). ### CE Marking & Declaration of Conformity - After demonstrating compliance, manufacturer must draw up EU Declaration of Conformity (DoC) and affix CE marking (Art. 7(c)). - The EU Declaration of Conformity must state that it has been demonstrated that the requirements specified in Article 4 have been met, and follow the model structure and contain the elements specified in Annex VI (Art. 13). - The EU Declaration of Conformity must be translated into the language or languages required by the Member State on the market of which the product is placed or made available (Art. 13(2)). - CE marking must be visible, legible and indelible on the finished EEE or its data plate (Art. 15(1)). - If size or nature of EEE does not allow, CE marking may be on packaging and accompanying documents (Art. 15(1)). - The CE marking must be affixed before the EEE is placed on the market (Art. 15(2)). - A single technical documentation may be drawn up where other applicable Union legislation requires a conformity assessment procedure that is at least as stringent (Art. 7(c) and Art. 13(2)). ### Authorised Representative (Art. 8) - A manufacturer may appoint an authorised representative by written mandate. - The obligations in Article 7(a) and the drawing up of technical documentation shall not form part of the authorised representative's mandate. - The mandate must allow the authorised representative at least to keep the EU declaration of conformity and technical documentation available for market surveillance authorities for 10 years, provide information and documentation upon request, and cooperate with competent national authorities. ### Traceability (Art. 12) - Economic operators must, on request, identify to market surveillance authorities for 10 years following placing on the market: (a) any economic operator who supplied them with an EEE, and (b) any economic operator to whom they supplied an EEE. ### Manufacturer Obligations (Art. 7) - (a) Ensure EEE placed on market is designed and manufactured in accordance with Art. 4. - (b) Draw up technical documentation and carry out internal production control (Module A). - (c) Draw up EU Declaration of Conformity and affix CE marking. - (d) Keep technical documentation and DoC for 10 years. - (e) Ensure procedures are in place for series production to remain in conformity; take account of changes. - (f) Keep a register of non-conforming EEE and product recalls; inform distributors. - (g) Ensure EEE bears type, batch or serial number or other identification. - (h) Indicate name, registered trade name/mark and contact address on EEE or packaging/documents. - (i) Take corrective measures (withdraw, recall) and inform authorities if EEE is non-compliant. - (j) Provide information and documentation to authorities upon request; cooperate on compliance actions. ### Importer Obligations (Art. 9) - (a) Place only compliant EEE on the Union market. - (b) Before placing EEE on market, ensure manufacturer has carried out conformity assessment, drawn up technical documentation, affixed CE marking, provided required documents, and complied with identification/labelling. - (c) If the importer considers or has reason to believe the EEE is not in conformity with Article 4, do not place it on the market until it has been brought into conformity, and inform the manufacturer and market surveillance authorities. - (d) Indicate importer name, registered trade name/mark, and a single contact address on the EEE (or packaging/accompanying document where not possible). - (e) Keep a register of non-compliant EEE and EEE recalls, and keep distributors informed thereof. - (f) If the importer considers or has reason to believe EEE placed on the market is not in conformity, take corrective measures (bring into conformity, withdraw or recall) and inform competent national authorities. - (g) Keep a copy of the EU Declaration of Conformity at the disposal of market surveillance authorities for 10 years and ensure the technical documentation can be made available upon request. - (h) Provide information and documentation to competent authorities upon request and cooperate on actions to ensure compliance. ### Distributor Obligations (Art. 10) - (a) Act with due care when making EEE available on market; verify CE marking, required documents, manufacturer/importer identification, and language requirements. - (b) Do not make non-compliant EEE available on market; inform manufacturer/importer and authorities if EEE presents a risk. - (c) If the distributor considers or has reason to believe EEE is not in conformity with Article 4, do not make it available on the market until it has been brought into conformity, and inform the manufacturer or the importer and the market surveillance authorities. - (d) If the distributor considers or has reason to believe EEE made available is not in conformity, ensure corrective measures are taken (bring into conformity, withdraw or recall) and inform competent national authorities. - (e) Provide information and documentation to competent authorities upon request and cooperate on actions to ensure compliance. - An importer or distributor is considered a manufacturer (and subject to Article 7 obligations) if it places EEE on the market under its name or trademark, or modifies EEE so that compliance may be affected (Art. 11). ### Market Surveillance and Controls (Art. 18) - Member States carry out market surveillance and controls of EEE entering the Union market in accordance with Regulation (EC) No 765/2008 (Art. 18). - Regulation (EU) 2019/1020 provides a framework for market surveillance and compliance of products, including cooperation and enforcement tools for market surveillance authorities. - Market surveillance authorities may request the EU Declaration of Conformity and technical documentation and take action where EEE is non-compliant. ### Penalties (Art. 23) - Member States must lay down rules on penalties applicable to infringements of national provisions adopted pursuant to the Directive and ensure they are implemented. - Penalties must be effective, proportionate and dissuasive. - Member States must notify the penalty rules to the Commission by 2 January 2013 and notify subsequent amendments without delay. ### RoHS Evolution: RoHS 1 -> RoHS 2 -> RoHS 3 - RoHS 1 (Directive 2002/95/EC): original RoHS directive restricting the use of hazardous substances in EEE (substance restrictions apply from 1 July 2006). - RoHS 2 (Directive 2011/65/EU): recast directive with updated scope and definitions and alignment with the CE marking and EU declaration of conformity framework. - RoHS 3 (Delegated Directive (EU) 2015/863): adds four phthalates (DEHP, BBP, DBP, DIBP) to Annex II (applies from 22 July 2019 for most EEE and from 22 July 2021 for medical devices and monitoring/control instruments). - Directive (EU) 2017/2102: further amendments to RoHS 2 scope and exemptions. - Consolidated RoHS 2 (as of 1 January 2025) incorporates all amendments. ### Open Scope (Category 11) - From 22 July 2019, RoHS applies to all EEE not covered by categories 1-10 and not excluded by Art. 2(4) (open scope). - This means any new EEE types are automatically in RoHS scope unless specifically excluded. - Article 2(2) transitional provision: non-compliant EEE that were outside the scope of RoHS 1 but inside the scope of RoHS 2 had full market access until 22 July 2019 (subject to specific application dates in Articles 4(3) and 4(4)). ### Cables (Art. 3(5)) - Cables = all cables with a rated voltage of less than 250 volts that serve as a connection or extension to connect EEE to the electrical outlet or to connect two or more EEE to each other (Art. 3(5)). - Cables are within RoHS scope from 3 January 2013 (with transitional provisions for cables outside RoHS 1 scope until 22 July 2019). - Internal wires and internal cables (inside EEE) are part of the EEE and follow the EEE's scope and compliance dates. - External cables (separate accessories) have separate compliance requirements. - Optical cables (no electrical current) are not EEE and not in RoHS scope. ### Components & Consumables - Finished EEE can only meet the substance restriction requirements if its components and parts meet the substance restrictions according to Article 4. - Components used in finished EEE (or for repair/upgrade of EEE in scope) must meet the substance restrictions, but do not need CE marking as stand-alone components (FAQ Q7.3). - Consumables are in scope only if they meet the definition of EEE (for example, printer cartridges); consumables without an equipment constituent are not in scope (FAQ Q7.4). - Manufacturers placing finished EEE on the market must ensure it is designed and manufactured in accordance with Article 4 (Art. 7(a)). ### Professional vs Consumer Use - RoHS applies to both professional and consumer EEE (unless specifically excluded, e.g., large-scale stationary industrial tools, non-road mobile machinery for professional use). - Professional use does not automatically exempt EEE from RoHS scope. - Industrial monitoring and control instruments (category 9) are in scope from 22 July 2017. - Large-scale stationary industrial tools and large-scale fixed installations are excluded (Art. 2(4)(d)-(e)). ### RoHS & REACH - RoHS and REACH are complementary but distinct EU legislation on chemicals. - REACH (Regulation (EC) 1907/2006) is horizontal legislation covering all products; RoHS is sector-specific for EEE. - RoHS review and amendment of Annex II must be coherent with REACH, particularly Annexes XIV (authorisation) and XVII (restrictions) (Art. 6(1)). - Some substances are restricted under both RoHS and REACH (for example, DEHP, BBP and DBP in toys under REACH Annex XVII entry 51; Annex II notes that RoHS restrictions for those substances do not apply to toys already subject to that REACH restriction). - RoHS applies without prejudice to REACH and other chemicals legislation (Art. 2(3)). ## Possible Outcomes ### [COMPLIANT] RoHS Compliant - Ready for EU Market CE marking affixed; DoC and technical documentation complete - Your EEE complies with RoHS substance restrictions (Annex II) or benefits from a valid exemption (Annex III/IV). - You have completed conformity assessment, drawn up technical documentation (EN IEC 63000:2018), issued DoC and affixed CE marking. - Ensure ongoing compliance during series production and keep documentation for 10 years. - Monitor exemption expiry dates and apply for renewals 18 months before expiry if needed. - Stay informed of Annex II reviews and any new substance additions (Art. 6). ### [ACTION REQUIRED] Application Uses Restricted Substance - Check Exemptions Exemption may be required - Your application uses a restricted substance above the maximum concentration value. - Check if an exemption in Annex III or IV covers your application. - Until the restriction does not apply or a valid exemption covers the application, the EEE cannot be placed on the EU market. - If no exemption exists or exemption has expired: consider substitution or apply for new/renewed exemption under Art. 5. - Exemption applications must demonstrate scientific/technical impracticability of substitution, unreliability of substitutes, or that substitution would cause greater harm. - Apply for exemption renewal at least 18 months before expiry; existing exemption remains valid until decision (Art. 5(5)). ### [NON-COMPLIANT] Non-Compliant - Cannot Be Placed on EU Market Conformity assessment not completed - You have not completed the required conformity assessment steps for RoHS. - Before placing EEE on the EU market, complete internal production control, draw up the EU Declaration of Conformity, and affix CE marking (Art. 7). - Member States must lay down penalties for infringements and ensure they are implemented (Art. 23). - Member States carry out market surveillance and controls in accordance with Article 18. ### [OUT OF SCOPE] Out of RoHS Scope RoHS does not apply - Your product is not EEE, or an Article 2(4) exclusion applies. - RoHS substance restrictions and conformity assessment do not apply. - Other EU legislation may still apply (e.g., REACH, Machinery Directive, Low Voltage Directive, EMC Directive, product-specific directives). ## RoHS Timeline | Date | Event | Reference | | --- | --- | --- | | 2003-02-13 | RoHS 1 published in the Official Journal | Dir. 2002/95/EC | | 2006-07-01 | RoHS 1 substance restrictions apply to new EEE | Dir. 2002/95/EC | | 2011-06-08 | RoHS 2 (Directive 2011/65/EU) adopted (recast) | Dir. 2011/65/EU | | 2011-07-21 | RoHS 2 entered into force | Dir. 2011/65/EU | | 2013-01-02 | Member States transpose RoHS 2 / CE marking begins | Dir. 2011/65/EU | | 2015-03-31 | 4 phthalates added to Annex II (DEHP, BBP, DBP, DIBP) | Del. Dir. (EU) 2015/863 | | 2019-07-22 | Open scope applies (category 11) and RoHS 3 phthalates apply for most EEE | Art. 2(2) and Del. Dir. (EU) 2015/863 | | 2020-05-15 | Implementing Decision (EU) 2020/659 adopted (EN IEC 63000:2018) | Impl. Dec. (EU) 2020/659 | | 2021-07-22 | 4 phthalates apply to medical devices and monitoring/control instruments | Annex II (as amended) | | 2021-11-18 | EN 50581:2012 reference withdrawn | Impl. Dec. (EU) 2020/659 | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2003-01-27 | RoHS 1 Directive Adopted | Legislation | | | 2003-02-13 | RoHS 1 Published in Official Journal | Legislation | | | 2004-08-13 | RoHS 1 Transposition Deadline | Implementation | | | 2005-02-13 | RoHS 1 First Review Deadline | Implementation | | | 2006-07-01 | RoHS 1 Substance Restrictions Effective | Substances | | | 2011-06-08 | RoHS 2 Directive Adopted (Recast) | Legislation | | | 2011-07-01 | RoHS 2 Published in Official Journal | Legislation | | | 2011-07-21 | RoHS 2 Entry into Force | Implementation | | | 2012-01-01 | EN 50581:2012 referenced as RoHS technical documentation standard | Standards | | | 2012-12-12 | RoHS 2 Official FAQ Published | Guidance | | | 2013-01-02 | RoHS 2 transposition deadline; CE marking presumption begins | Implementation | | | 2013-01-03 | RoHS 1 Exemptions Expire | Implementation | | | 2014-07-22 | Medical Devices and Monitoring Instruments in Scope | Implementation | | | 2015-03-31 | RoHS 3 Phthalates Amendment Adopted | Substances | | | 2015-06-04 | RoHS 3 Published in Official Journal | Substances | | | 2016-07-01 | Reuse cutoff for recovered spare parts (Article 4(5) exemption) | Implementation | | | 2016-07-22 | In Vitro Diagnostic Medical Devices in Scope | Implementation | | | 2016-12-31 | RoHS 3 Transposition Deadline | Implementation | | | 2017-07-22 | Industrial Monitoring Instruments in Scope | Implementation | | | 2017-11-15 | Directive 2017/2102 Adopted (Scope Amendment) | Legislation | | | 2017-11-21 | Directive 2017/2102 Published | Legislation | | | 2018-01-01 | EN IEC 63000:2018 Adopted | Standards | | | 2018-07-17 | Commission receives exemption application (phthalates spare parts) | Implementation | | | 2018-11-01 | Technical/scientific assessment study starts (exemption request) | Implementation | | | 2019-03-18 | Stakeholder consultation opens (RoHS exemption assessment) | Implementation | | | 2019-05-17 | Stakeholder consultation closes (RoHS exemption assessment) | Implementation | | | 2019-06-12 | Directive 2017/2102 Transposition Deadline | Implementation | | | 2019-07-22 | Four Phthalates Restriction Effective (General EEE) | Substances | | | 2019-07-22 | Open Scope Fully Effective (Category 11) | Implementation | | | 2020-05-15 | Commission Decision 2020/659 on EN IEC 63000:2018 | Standards | | | 2021-02-23 | Member State expert group consultation (delegated acts) | Implementation | | | 2021-07-22 | Four Phthalates Restriction Effective (Medical Devices) | Substances | | | 2021-08-11 | Delegated directive signed on recovered spare parts exemption (phthalates) | Legislation | | | 2021-11-18 | EN 50581:2012 Reference Withdrawn | Standards | | | 2021-12-13 | Commission adopts mercury-in-lamps exemptions updates | Substances | | | 2022-02-24 | Delegated acts published ending mercury use in lamps | Substances | | | 2022-03-10 | Public consultation on RoHS review opens | Implementation | | | 2022-06-02 | Public consultation on RoHS review closes | Implementation | | | 2022-06-29 | Commission Notice 2022/C 262/04 Published | Guidance | | | 2023-12-07 | RoHS review finalised; targeted amendment proposed | Implementation | | | 2024-07-22 | Reuse Exemption Expires (Medical Devices Cat 8/9) | Implementation | | | 2026-07-22 | Reuse Exemption Expires (In Vitro Devices) | Implementation | | | 2027-07-22 | Reuse Exemption Expires (Industrial Instruments) | Implementation | | | 2029-07-22 | Reuse Exemption Expires (Category 11) | Implementation | | **Event details:** - **2003-01-27 - RoHS 1 Directive Adopted**: Directive 2002/95/EC adopted by European Parliament and Council, restricting use of hazardous substances in electrical and electronic equipment. - **2003-02-13 - RoHS 1 Published in Official Journal**: Directive 2002/95/EC published in Official Journal L 37/19, entering into force on day of publication. - **2004-08-13 - RoHS 1 Transposition Deadline**: Member States required to bring into force laws, regulations and administrative provisions to comply with Directive 2002/95/EC. - **2005-02-13 - RoHS 1 First Review Deadline**: Commission required to review measures and present proposals for additional equipment and substance restrictions. - **2006-07-01 - RoHS 1 Substance Restrictions Effective**: Prohibition effective for lead, mercury, cadmium, hexavalent chromium, PBB, and PBDE in new EEE placed on market. - **2011-06-08 - RoHS 2 Directive Adopted (Recast)**: Directive 2011/65/EU adopted as recast of RoHS 1, expanding scope to all EEE and improving legal clarity. - **2011-07-01 - RoHS 2 Published in Official Journal**: Directive 2011/65/EU published in Official Journal L 174, entering into force 20 days after publication. - **2011-07-21 - RoHS 2 Entry into Force**: Directive 2011/65/EU enters into force, establishing open scope for all EEE with specific exclusions. - **2012-01-01 - EN 50581:2012 referenced as RoHS technical documentation standard**: The Commission FAQ references harmonised European Standard EN 50581:2012 for RoHS technical documentation (year reference). - **2012-12-12 - RoHS 2 Official FAQ Published**: Commission publishes comprehensive FAQ on scope, exclusions, CE marking, and substance restrictions. - **2013-01-02 - RoHS 2 transposition deadline; CE marking presumption begins**: Deadline for Member States to transpose RoHS 2. From 2 January 2013, CE-marked EEE in scope is presumed to conform with RoHS 2 requirements and CE marking is the only marking attesting conformity. - **2013-01-03 - RoHS 1 Exemptions Expire**: Exemptions granted under RoHS 1 expire; new exemption framework under RoHS 2 fully operative. - **2014-07-22 - Medical Devices and Monitoring Instruments in Scope**: RoHS 2 restrictions apply to medical devices and monitoring/control instruments placed on market. - **2015-03-31 - RoHS 3 Phthalates Amendment Adopted**: Commission Delegated Directive (EU) 2015/863 adds four phthalates (DEHP, BBP, DBP, DIBP) to restricted substances list. - **2015-06-04 - RoHS 3 Published in Official Journal**: Delegated Directive (EU) 2015/863 published in Official Journal L 137, entering into force 20 days after publication. - **2016-07-01 - Reuse cutoff for recovered spare parts (Article 4(5) exemption)**: Recovered spare parts from EEE placed on the market before 1 July 2006 can be reused in new EEE placed on the market before 1 July 2016 under the Article 4(5) closed-loop B2B exemption. - **2016-07-22 - In Vitro Diagnostic Medical Devices in Scope**: RoHS 2 restrictions apply to in vitro diagnostic medical devices placed on market. - **2016-12-31 - RoHS 3 Transposition Deadline**: Member States required to adopt national laws implementing four phthalates restriction by December 31, 2016. - **2017-07-22 - Industrial Monitoring Instruments in Scope**: RoHS 2 restrictions apply to industrial monitoring and control instruments placed on market. - **2017-11-15 - Directive 2017/2102 Adopted (Scope Amendment)**: Directive (EU) 2017/2102 adopted, excluding pipe organs and clarifying secondary market operations and exemptions. - **2017-11-21 - Directive 2017/2102 Published**: Directive (EU) 2017/2102 published in Official Journal L 305, entering into force 20 days after publication. - **2018-01-01 - EN IEC 63000:2018 Adopted**: EN IEC 63000:2018 is referenced as the (year) harmonised standard that replaces EN 50581:2012 for RoHS technical documentation. - **2018-07-17 - Commission receives exemption application (phthalates spare parts)**: Commission receives an application for an exemption to allow DEHP, BBP, DBP and DIBP in recovered spare parts from medical devices (referenced as received 17 July 2018). - **2018-11-01 - Technical/scientific assessment study starts (exemption request)**: Commission begins a study (referenced as starting in November 2018) to prepare the technical and scientific assessment for a RoHS exemption request concerning phthalates in recovered spare parts for medical devices. - **2019-03-18 - Stakeholder consultation opens (RoHS exemption assessment)**: Online stakeholder consultation referenced as running from 18 March 2019 in the exemption assessment process for recovered spare parts containing certain phthalates. - **2019-05-17 - Stakeholder consultation closes (RoHS exemption assessment)**: Online stakeholder consultation referenced as ending 17 May 2019 in the exemption assessment process for recovered spare parts containing certain phthalates. - **2019-06-12 - Directive 2017/2102 Transposition Deadline**: Member States required to transpose Directive (EU) 2017/2102 into national law. - **2019-07-22 - Four Phthalates Restriction Effective (General EEE)**: Restriction of DEHP, BBP, DBP, and DIBP effective for all EEE placed on market (except medical devices and monitoring instruments). - **2019-07-22 - Open Scope Fully Effective (Category 11)**: RoHS 2 open scope applies to all other EEE previously outside RoHS 1 scope (category 11). - **2020-05-15 - Commission Decision 2020/659 on EN IEC 63000:2018**: Commission publishes reference of EN IEC 63000:2018 in Official Journal, establishing presumption of conformity. - **2021-02-23 - Member State expert group consultation (delegated acts)**: Commission consults a Member State expert group on RoHS delegated acts on 23 February 2021 (as referenced in the delegated directive file). - **2021-07-22 - Four Phthalates Restriction Effective (Medical Devices)**: Restriction of DEHP, BBP, DBP, and DIBP effective for medical devices, in vitro medical devices, and monitoring/control instruments. - **2021-08-11 - Delegated directive signed on recovered spare parts exemption (phthalates)**: Delegated directive dated 11 August 2021 amends RoHS Annex IV to grant an exemption allowing DEHP, BBP, DBP and DIBP in recovered spare parts from medical devices used for repair/refurbishment (LV language version in source). - **2021-11-18 - EN 50581:2012 Reference Withdrawn**: Reference of EN 50581:2012 withdrawn from Official Journal; EN IEC 63000:2018 becomes sole harmonised standard for technical documentation. - **2021-12-13 - Commission adopts mercury-in-lamps exemptions updates**: Commission adopts a package of delegated directives (mostly dated 13 December 2021) updating exemptions for the use of mercury in lamps under the RoHS Directive; these were later published in OJ L 43 on 24 February 2022. - **2022-02-24 - Delegated acts published ending mercury use in lamps**: Commission publishes delegated acts ending the use of mercury in lamps, updating RoHS exemptions to reflect mercury-free alternatives. - **2022-03-10 - Public consultation on RoHS review opens**: Commission launches an open public consultation on the review of the RoHS Directive (10 March 2022). - **2022-06-02 - Public consultation on RoHS review closes**: Commission closes the open public consultation on the review of the RoHS Directive (2 June 2022). - **2022-06-29 - Commission Notice 2022/C 262/04 Published**: Commission publishes implementation guidance notice in Official Journal C 262/04 on RoHS 2 application. - **2023-12-07 - RoHS review finalised; targeted amendment proposed**: Commission finalises the RoHS review and proposes a targeted amendment of the RoHS Directive. - **2024-07-22 - Reuse Exemption Expires (Medical Devices Cat 8/9)**: Exemption for reused spare parts from medical devices/monitoring instruments placed before July 2014 expires. - **2026-07-22 - Reuse Exemption Expires (In Vitro Devices)**: Exemption for reused spare parts from in vitro diagnostic medical devices placed before July 2016 expires. - **2027-07-22 - Reuse Exemption Expires (Industrial Instruments)**: Exemption for reused spare parts from industrial monitoring/control instruments placed before July 2017 expires. - **2029-07-22 - Reuse Exemption Expires (Category 11)**: Exemption for reused spare parts from all other EEE (category 11) placed before July 2019 expires. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/rohs-directive --- --- title: "EU Taxonomy Regulation (EU) 2020/852: Timeline, Article 8 Scope, Eligibility and Alignment Decision Flow" canonical_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation" source_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation" author: "Sorena AI" description: "A practical EU Taxonomy artifact for Regulation (EU) 2020/852." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Taxonomy" - "Regulation (EU) 2020/852" - "Article 8 Taxonomy" - "Taxonomy eligibility" - "Taxonomy alignment" - "DNSH" - "minimum safeguards" - "GAR" - "turnover KPI" - "CapEx KPI" - "OpEx KPI" - "Delegated Regulation 2026/73" - "Article 8" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Taxonomy Regulation (EU) 2020/852: Timeline, Article 8 Scope, Eligibility and Alignment Decision Flow A practical EU Taxonomy artifact for Regulation (EU) 2020/852. ![EU Taxonomy artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-eu-taxonomy-timeline-small.jpg?v=cheatsheets%2Fprod) *EU Taxonomy* *Free Resource* ## EU Taxonomy Timeline and Eligibility Decision Flow Classify economic activities as taxonomy-eligible and taxonomy-aligned, then plan Article 8 disclosures with evidence for substantial contribution, DNSH, minimum safeguards, and current delegated-act changes. Practical implementation guidance based on Regulation (EU) 2020/852, the delegated acts, and current Commission notices. Root timeline and decision flow preserved for planning use. [Run the applicability test](/artifacts/eu/taxonomy-regulation/applicability-test.md) ## What you can decide faster - **Eligibility**: Is the activity covered by a current Taxonomy activity definition and boundary? - **Alignment**: Does the activity pass the technical screening criteria, DNSH, and minimum safeguards? - **Disclosure**: Which KPI family applies and what evidence, comparatives, and contextual notes are required? By Sorena AI | Updated 2026 | No signup required ### Quick scan *Taxonomy* - **Eligible**: Covered by a current delegated-act activity definition. - **Aligned**: Meets the criteria and can be evidenced. - **Disclosed**: Published in the right KPI template with the right notes. Use the decision flow to keep eligibility, alignment, and disclosure logic separate. | Value | Metric | | --- | --- | | 6 | Objectives | | DNSH | No harm | | GAR | Finance KPI | | 2026 | Current update | **Key highlights:** Eligibility first | DNSH evidence | Current notices ## Topic Guides - [EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures](/artifacts/eu/taxonomy-regulation/applicability-test.md): A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose. - [EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs](/artifacts/eu/taxonomy-regulation/checklist.md): An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping. - [EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence](/artifacts/eu/taxonomy-regulation/compliance.md): A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register. - [EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR](/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar.md): A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases. - [EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73](/artifacts/eu/taxonomy-regulation/delegated-acts-tracker.md): Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts. - [EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link](/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards.md): A practical guide to EU Taxonomy DNSH and minimum safeguards. - [EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7)](/artifacts/eu/taxonomy-regulation/penalties-and-fines.md): How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7. - [EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification](/artifacts/eu/taxonomy-regulation/faq.md): A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice. - [EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8](/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow.md): Build an EU Taxonomy disclosure workflow that can survive review. - [EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs](/artifacts/eu/taxonomy-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means. - [EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8](/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities.md): Understand EU Taxonomy scope and reporting entities under Article 8. - [EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail](/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation.md): How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping. - [EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards)](/artifacts/eu/taxonomy-regulation/templates.md): Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register. - [EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting](/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd.md): Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system. - [EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests](/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr.md): Understand the practical relationship between EU Taxonomy and SFDR. - [Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove](/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained.md): A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed. ## Key dates for delegated acts and disclosures *Taxonomy Timeline* Track Article 8 reporting phases, the 2025 and 2026 interpretation changes, and when the financial KPI stack expands again. ## Is an activity taxonomy eligible and aligned *Taxonomy Decision Flow* Separate eligibility from alignment, then build an evidence pack and disclosure workflow that can survive review. *Next step* ## Turn EU Taxonomy Timeline and Eligibility Decision Flow into an ESG delivery workflow EU Taxonomy Timeline and Eligibility Decision Flow should be the shared entry point for your team. Route execution into ESG Compliance for live work and into Research Copilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from EU Taxonomy Timeline and Eligibility Decision Flow and route the work by entity, product, team, or control owner. - Use ESG Compliance to manage cross team sustainability work, reporting, and evidence from one workflow. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open ESG Compliance](/solutions/esg-compliance.md): Manage cross team sustainability work, reporting, and evidence from one workflow for EU Taxonomy Timeline and Eligibility Decision Flow. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs from the same artifact. - **Download decision flow**: Share the classification logic with finance, sustainability, and assurance owners. - **Download timeline**: Align planning with the actual reporting and simplification milestones. - [Talk through EU Taxonomy Timeline and Eligibility Decision Flow](/contact.md): Review your current process, evidence model, and next steps for EU Taxonomy Timeline and Eligibility Decision Flow. ## Decision Steps ### STEP 1: Are you subject to the EU Taxonomy disclosure requirements? *Reference: Art. 8 (Reg. 2020/852) & Delegated Reg. 2021/2178* - Article 8 requires undertakings that are subject to Articles 19a or 29a of Directive 2013/34/EU to disclose how and to what extent their activities are associated with environmentally sustainable economic activities. - Delegated Regulation (EU) 2021/2178 specifies the content, presentation, and methodology for the KPIs and templates for both non-financial and financial undertakings. - If yes: continue to identify your KPI track and assess Taxonomy eligibility and alignment. - If no: Article 8 reporting does not apply, but you may still use the EU Taxonomy voluntarily. - **NO** Not Subject to EU Taxonomy Disclosure - **YES** Are you a financial undertaking (rather than a non-financial undertaking)? ### STEP 2: Are you a financial undertaking (rather than a non-financial undertaking)? *Reference: Art. 8 (Taxonomy disclosures)* - If yes: follow the financial undertaking track (e.g., credit institutions, asset managers, investment firms, insurance and reinsurance undertakings) and use the financial KPI templates in Delegated Regulation (EU) 2021/2178. - If no: follow the non-financial undertaking track and report turnover, CapEx and OpEx KPIs under Delegated Regulation (EU) 2021/2178. - Both tracks require Taxonomy eligibility and alignment assessments for the relevant economic activities. - **NO** Are you a non-financial undertaking using the turnover, CapEx and OpEx KPIs? - **YES** Are you a financial undertaking using the financial KPIs under Delegated Regulation (EU) 2021/2178? ### STEP 3A: Are you a non-financial undertaking using the turnover, CapEx and OpEx KPIs? *Reference: Delegated Reg. 2021/2178 (Annex I and Annex II templates)* - Non-financial undertakings disclose KPIs on turnover, CapEx and OpEx and accompanying qualitative information using the templates in Delegated Regulation (EU) 2021/2178. - Transitional period: from 1 January 2022 until 31 December 2022, non-financial undertakings disclose only the proportion of Taxonomy-eligible and Taxonomy non-eligible activities and the relevant qualitative information. - If yes: proceed to assess whether your activities are Taxonomy-eligible and Taxonomy-aligned. - **YES** Is your economic activity listed in the Delegated Acts? - **NO** Not Subject to EU Taxonomy Disclosure ### STEP 3B: Are you a financial undertaking using the financial KPIs under Delegated Regulation (EU) 2021/2178? *Reference: Delegated Reg. 2021/2178 (financial KPI templates)* - Delegated Regulation (EU) 2021/2178 specifies KPIs for financial undertakings, including credit institutions (Green Asset Ratio), investment firms, asset managers, and insurance and reinsurance undertakings. - Transitional period: application in 2022 is limited to certain elements and qualitative reporting, with remaining provisions applying from 1 January 2024 for financial undertakings. - If yes: proceed to assess whether the relevant activities and exposures are Taxonomy-eligible and Taxonomy-aligned. - **YES** Is your economic activity listed in the Delegated Acts? - **NO** Not Subject to EU Taxonomy Disclosure ### STEP 4: Is your economic activity listed in the Delegated Acts? *Reference: Climate & Environmental Delegated Acts* - Check if your activity is described in the Climate Delegated Act (Delegated Reg. (EU) 2021/2139), the Complementary Climate Delegated Act (Delegated Reg. (EU) 2022/1214), and the Environmental Delegated Act (Delegated Reg. (EU) 2023/2485). - If listed: the activity is Taxonomy-eligible. Proceed to alignment assessment. - If not listed: the activity is Taxonomy non-eligible. Report as such and no further assessment needed. - Note: An activity can be eligible under multiple objectives. - **YES** Taxonomy-Alignment Assessment (Three Criteria) - **NO** Taxonomy Non-Eligible Activity ### STEP 5: Taxonomy-Alignment Assessment (Three Criteria) - To qualify as Taxonomy-aligned, an activity must meet three cumulative criteria: - 1. Substantial contribution: meet the technical screening criteria (TSC) for at least one environmental objective. - 2. Do No Significant Harm (DNSH): meet DNSH criteria for all other environmental objectives. - 3. Minimum safeguards: comply with minimum social safeguards (OECD Guidelines, UN Guiding Principles, ILO Declaration). - All three criteria must be met. Proceed through each step. - -> Does your activity meet the substantial contribution criteria? ### STEP 6: Does your activity meet the substantial contribution criteria? *Reference: Art. 10-15 & Technical Screening Criteria* - Substantial contribution: your activity must meet the technical screening criteria (TSC) for at least one of the environmental objectives. - TSC are activity-specific and set out in the delegated acts (including Delegated Reg. (EU) 2021/2139, 2022/1214 and 2023/2485). - If yes: proceed to DNSH assessment. If no: the activity is not Taxonomy-aligned. - **YES** Does your activity meet all Do No Significant Harm (DNSH) criteria? - **NO** Taxonomy-Eligible but Not Aligned ### STEP 7: Does your activity meet all Do No Significant Harm (DNSH) criteria? *Reference: Art. 17 & Delegated Acts Appendices* - DNSH: your activity must not significantly harm any of the other environmental objectives (as defined in Article 17). - DNSH criteria are set out in the delegated acts alongside the TSC and can include generic and activity-specific requirements (for example, generic DNSH criteria can be set out in appendices such as Appendix C to Delegated Regulation (EU) 2021/2139). - If any DNSH criterion is not met, the activity is not Taxonomy-aligned. - If yes: proceed to minimum safeguards check. - **YES** Does your undertaking comply with minimum safeguards? - **NO** Taxonomy-Eligible but Not Aligned ### STEP 8: Does your undertaking comply with minimum safeguards? *Reference: Art. 18 (minimum safeguards)* - Minimum safeguards: procedures implemented by an undertaking to ensure alignment with the OECD Guidelines for Multinational Enterprises and the UN Guiding Principles on Business and Human Rights, including the principles and rights set out in the eight fundamental ILO conventions and the International Bill of Human Rights. - When implementing those procedures, undertakings adhere to the principle of 'do no significant harm' referred to in Regulation (EU) 2019/2088. - If yes: the activity is Taxonomy-aligned. Proceed to KPI calculation. - If no: the activity is not Taxonomy-aligned. - **YES** Taxonomy-Aligned Activity - **NO** Taxonomy-Eligible but Not Aligned ## Reference Information ### Six Environmental Objectives - 1. Climate change mitigation (Art. 10) - technical screening criteria set out in the Climate Delegated Act (Delegated Reg. (EU) 2021/2139) and related amendments (including Delegated Reg. (EU) 2022/1214). - 2. Climate change adaptation (Art. 11) - technical screening criteria set out in the Climate Delegated Act (Delegated Reg. (EU) 2021/2139). - 3. Sustainable use and protection of water and marine resources (Art. 12) - technical screening criteria set out in the Environmental Delegated Act (Delegated Reg. (EU) 2023/2485). - 4. Transition to a circular economy (Art. 13) - technical screening criteria set out in the Environmental Delegated Act (Delegated Reg. (EU) 2023/2485). - 5. Pollution prevention and control (Art. 14) - technical screening criteria set out in the Environmental Delegated Act (Delegated Reg. (EU) 2023/2485). - 6. Protection and restoration of biodiversity and ecosystems (Art. 15) - technical screening criteria set out in the Environmental Delegated Act (Delegated Reg. (EU) 2023/2485). ### KPI Calculation for Non-Financial Undertakings - Non-financial undertakings must disclose three KPIs in their non-financial statement: - 1. Turnover KPI: proportion of net turnover derived from products or services associated with Taxonomy-aligned economic activities (Section 1.1.1, Annex I, Disclosures Delegated Act). - 2. CapEx KPI: proportion of capital expenditure related to assets or processes associated with Taxonomy-aligned economic activities (Section 1.1.2, Annex I). - 3. OpEx KPI: proportion of operating expenditure related to assets or processes associated with Taxonomy-aligned economic activities (Section 1.1.3, Annex I). - Report separately: eligible and aligned proportions for each KPI. - Provide qualitative information: accounting policies, context, and any significant changes. - Use templates in Annex II of the Disclosures Delegated Act. ### KPI Calculation for Financial Undertakings - Financial undertakings must disclose KPIs specific to their business model: - Credit institutions: Green Asset Ratio (GAR) - proportion of total assets financing Taxonomy-aligned economic activities (Annex V). - Asset managers: proportion of investments in Taxonomy-aligned economic activities (Annex VIII). - Insurance and reinsurance undertakings: proportion of Taxonomy-aligned investments (Annex IX) and Taxonomy-aligned underwriting (Annex X). - Investment firms: proportion of Taxonomy-aligned assets and exposures (Annex VII). - Report separately: eligible and aligned exposures. - Provide qualitative information: methodologies, data quality, and limitations. - Use templates in Annexes III-XI of the Disclosures Delegated Act. ### EU Taxonomy Delegated Acts - 1. Climate Delegated Act (Delegated Reg. (EU) 2021/2139): technical screening criteria for climate change mitigation and climate change adaptation (with related amendments, including Delegated Reg. (EU) 2022/1214). - 2. Environmental Delegated Act (Delegated Reg. (EU) 2023/2485): technical screening criteria for water and marine resources, circular economy, pollution prevention and control, and biodiversity and ecosystems. - 3. Disclosures Delegated Act (Delegated Reg. (EU) 2021/2178): KPI templates, content and presentation of disclosures for non-financial and financial undertakings. - The Commission has also issued notices and draft notices providing interpretation and implementation guidance for Article 8 disclosures. ### Transitional and Enabling Activities - Transitional activities (Art. 10(2)): economic activities for which there are no technologically and economically feasible low-carbon alternatives, but which support the transition to a climate-neutral economy. They must meet the conditions in Article 10(2) and the relevant technical screening criteria. - Enabling activities (Art. 16): economic activities that directly enable other activities to make a substantial contribution to one or more environmental objectives, subject to the conditions in Article 16 and the relevant technical screening criteria. - Both transitional and enabling activities can qualify as Taxonomy-aligned if they meet the relevant TSC, DNSH criteria, and minimum safeguards. ### EU Taxonomy Reporting Timeline - Article 8 applies for the climate objectives (Art. 9(a) and 9(b)) from 1 January 2022 and for the other objectives (Art. 9(c) to 9(f)) from 1 January 2023. - Non-financial undertakings: from 1 January 2022 until 31 December 2022, disclose only the proportion of Taxonomy-eligible and Taxonomy non-eligible activities and the relevant qualitative information. Remaining provisions apply from 1 January 2023. - Financial undertakings: application in 2022 is limited to certain elements and qualitative reporting, with remaining provisions applying from 1 January 2024. - Credit institutions: additional KPIs related to trading book and commissions and fees apply from 1 January 2026. - Review clauses: Delegated Regulation (EU) 2021/2178 includes a review by 30 June 2024. Regulation (EU) 2020/852 includes periodic reviews. ### Data Sources and Verification - Disclosures include quantitative KPIs and accompanying qualitative information explaining methodologies, assumptions, and limitations (including how data was allocated and how double counting was avoided). - Where information is not readily available, estimates can be used if the approach is transparent and limitations are clearly explained. - Data usability and quality considerations can be informed by the Platform on Sustainable Finance recommendations on taxonomy data treatment, verification, and usability. ### Commission Notices and Guidance - Commission Notice 2022/C 385/01 (6 October 2022): interpretation of the Disclosures Delegated Act for reporting taxonomy-eligible activities and assets. - Commission Notice 2023/C 211/01 (16 June 2023): interpretation of the Taxonomy Regulation and links to the Sustainable Finance Disclosure Regulation (SFDR). - Commission Notice (OJ C/2024/6691, published 8 November 2024): interpretation of certain legal provisions of the Disclosures Delegated Act under Article 8 on reporting of taxonomy-eligible and taxonomy-aligned activities and assets. - Draft Commission Notice (approved in principle on 29 November 2024): comprehensive guidance on Environmental, Climate, and Disclosures delegated acts. - These notices assist with implementation and do not create new legal obligations. ### Future Developments and Reviews - Platform on Sustainable Finance: EU expert group advising the Commission on the development and refinement of the EU Taxonomy. Publishes reports and recommendations on extending the Taxonomy (e.g., to social objectives) and improving usability. - Review clauses: Regulation (EU) 2020/852 includes periodic reviews, and Delegated Regulation (EU) 2021/2178 includes a review by 30 June 2024. - Scope extension: Regulation (EU) 2020/852 includes provisions on assessing potential extensions of the taxonomy framework (including consideration of social taxonomy work). ## Possible Outcomes ### [RESULT] Taxonomy-Aligned Activity Report as aligned in KPIs - Your activity is Taxonomy-aligned: it contributes substantially to at least one objective, does no significant harm to others, and complies with minimum safeguards. - Non-financial undertakings: report the proportion of aligned turnover, CapEx and OpEx in your non-financial statement (Art. 8(1)). - Financial undertakings: report Taxonomy-aligned assets/exposures in your disclosures (Art. 8(2)) using the applicable KPI (e.g., GAR for credit institutions). - Use templates in Annex II (non-financials) or Annexes III-XI (financials) of the Disclosures Delegated Act. ### [RESULT] Taxonomy-Eligible but Not Aligned Report eligibility only - Your activity is Taxonomy-eligible (listed in the Delegated Acts) but does not meet all alignment criteria (substantial contribution, DNSH, or minimum safeguards). - Report the proportion of Taxonomy-eligible economic activities separately from Taxonomy-aligned activities. - Non-financial undertakings: report eligible and aligned proportions for turnover, CapEx and OpEx. - Financial undertakings: report eligible and aligned exposures using applicable KPIs. - Provide qualitative information explaining why the activity is not aligned and any plans to improve alignment. ### [RESULT] Taxonomy Non-Eligible Activity Not covered by Delegated Acts - Your activity is Taxonomy non-eligible: it is not described in the Climate Delegated Act or Environmental Delegated Act. - Report the proportion of Taxonomy non-eligible economic activities in your KPIs. - No alignment assessment is required for non-eligible activities. - Note: The Commission may expand the list of eligible activities in future amendments to the Delegated Acts. ### [RESULT] Not Subject to EU Taxonomy Disclosure No mandatory reporting - You are not subject to the EU Taxonomy disclosure requirements under Article 8 of the Taxonomy Regulation. - Voluntary use: you may use the EU Taxonomy framework voluntarily to assess and communicate the environmental sustainability of your economic activities. - Note: Even if not subject to EU Taxonomy disclosure, you may still be required to report Taxonomy-aligned activities if you access EU sustainable finance instruments (e.g., EU Green Bonds, InvestEU, Recovery and Resilience Facility). ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2018-07-01 | Technical Expert Group (TEG) Established | Governance | | | 2020-06-18 | EU Taxonomy Regulation Adopted | Core Regulation | | | 2020-06-22 | Publication in Official Journal | Core Regulation | | | 2020-07-01 | TEG Mandate Ends | Governance | | | 2020-07-12 | Regulation Entry into Force | Core Regulation | | | 2020-10-01 | Platform on Sustainable Finance (First Mandate) | Governance | | | 2021-03-01 | Transition Finance Report | Platform Reports | | | 2021-06-04 | Climate Delegated Act Adopted | Delegated Acts | | | 2021-07-06 | Disclosures Delegated Act Adopted | Delegated Acts | | | 2021-12-09 | Climate Delegated Act published in Official Journal | Delegated Acts | | | 2021-12-10 | Disclosures Delegated Act published in Official Journal | Delegated Acts | | | 2022-01-01 | Climate Delegated Act Applies | Application Dates | | | 2022-01-01 | Disclosures Delegated Act Begins Phased Application | Application Dates | | | 2022-02-01 | Social Taxonomy Report | Platform Reports | | | 2022-03-09 | Complementary Climate Delegated Act Adopted | Delegated Acts | | | 2022-07-15 | Complementary Climate Act Published in OJ | Delegated Acts | | | 2022-10-01 | Platform First Mandate Ends | Governance | | | 2022-10-01 | Data and Usability Recommendations | Platform Reports | | | 2022-10-01 | Minimum Safeguards Report | Platform Reports | | | 2022-10-06 | Commission Notice on Article 8 Disclosures (2022/C 385/01) | Commission Guidance | | | 2022-12-19 | Draft Commission Notices Approved in Principle (December 2022) | Commission Guidance | | | 2023-01-01 | Complementary Climate Act Applies | Application Dates | | | 2023-01-01 | Disclosures Delegated Act applies (non-financial undertakings) | Application Dates | | | 2023-02-01 | Platform Second Mandate Begins | Governance | | | 2023-06-13 | Environmental Delegated Acts Approved | Delegated Acts | | | 2023-06-16 | Commission Notice on Taxonomy and SFDR | Commission Guidance | | | 2023-06-27 | Environmental Delegated Acts Adopted | Delegated Acts | | | 2023-10-17 | Stakeholder Request Mechanism Launched | Governance | | | 2023-11-21 | Environmental Delegated Acts Published in OJ | Delegated Acts | | | 2024-01-01 | Environmental Delegated Acts Apply | Application Dates | | | 2024-01-01 | Disclosures Delegated Act applies (financial undertakings) | Application Dates | | | 2024-11-08 | Third Commission Notice on Article 8 Disclosures (OJ C/2024/6691) | Commission Guidance | | | 2024-11-29 | Draft Commission Notice (November 2024) Approved in Principle | Commission Guidance | | | 2025-02-26 | Simplification Omnibus Package | Core Regulation | | | 2025-03-01 | Platform Second Mandate Ends | Governance | | | 2025-03-01 | Commission Notice on Three Delegated Acts | Commission Guidance | | | 2025-07-04 | Omnibus Delegated Act Adopted | Delegated Acts | | | 2025-12-17 | Draft Notice on Omnibus Delegated Act | Commission Guidance | | | 2026-01-01 | Additional Credit Institution KPIs Apply | Application Dates | | | 2026-02-01 | Platform Third Mandate Begins | Governance | | | 2050-01-01 | Climate Neutrality Target | Core Regulation | | **Event details:** - **2018-07-01 - Technical Expert Group (TEG) Established**: Commission establishes Technical Expert Group on Sustainable Finance to develop taxonomy framework - **2020-06-18 - EU Taxonomy Regulation Adopted**: Regulation (EU) 2020/852 adopted by European Parliament and Council establishing framework for sustainable investment classification - **2020-06-22 - Publication in Official Journal**: Taxonomy Regulation published in Official Journal (OJ L 198) - **2020-07-01 - TEG Mandate Ends**: Technical Expert Group on Sustainable Finance completes work (2018-2020) - **2020-07-12 - Regulation Entry into Force**: EU Taxonomy Regulation enters into force, establishing six environmental objectives and framework conditions - **2020-10-01 - Platform on Sustainable Finance (First Mandate)**: Platform on Sustainable Finance begins first mandate (October 2020 - October 2022) - **2021-03-01 - Transition Finance Report**: Platform on Sustainable Finance adopts report on transition finance - **2021-06-04 - Climate Delegated Act Adopted**: Commission Delegated Regulation (EU) 2021/2139 establishing technical screening criteria for climate change mitigation and adaptation - **2021-07-06 - Disclosures Delegated Act Adopted**: Commission Delegated Regulation (EU) 2021/2178 on Article 8 disclosure obligations for financial and non-financial undertakings - **2021-12-09 - Climate Delegated Act published in Official Journal**: Official Journal publication of the Climate Delegated Act (Delegated Regulation (EU) 2021/2139). - **2021-12-10 - Disclosures Delegated Act published in Official Journal**: Official Journal publication of the Disclosures Delegated Act (Delegated Regulation (EU) 2021/2178). - **2022-01-01 - Climate Delegated Act Applies**: Climate Delegated Act applies as of 1 January 2022. - **2022-01-01 - Disclosures Delegated Act Begins Phased Application**: Disclosures Delegated Act application in 2022 is limited to certain elements and qualitative reporting. - **2022-02-01 - Social Taxonomy Report**: Platform on Sustainable Finance publishes Final Report on Social Taxonomy development - **2022-03-09 - Complementary Climate Delegated Act Adopted**: Commission Delegated Regulation (EU) 2022/1214 on gas and nuclear energy activities - **2022-07-15 - Complementary Climate Act Published in OJ**: Official Journal publication of Complementary Climate Delegated Act (gas and nuclear) - **2022-10-01 - Platform First Mandate Ends**: End of the first mandate of the Platform on Sustainable Finance (October 2022). - **2022-10-01 - Data and Usability Recommendations**: Platform publishes recommendations on taxonomy data treatment, verification, and usability - **2022-10-01 - Minimum Safeguards Report**: Platform publishes Final Report on Minimum Safeguards (human rights, labor, anti-corruption) - **2022-10-06 - Commission Notice on Article 8 Disclosures (2022/C 385/01)**: Commission Notice on interpretation of the Disclosures Delegated Act for reporting taxonomy-eligible economic activities and assets (OJ C 385, 6 October 2022). - **2022-12-19 - Draft Commission Notices Approved in Principle (December 2022)**: Draft Commission notices on the Climate Delegated Act and on Article 8 disclosures are approved in principle on 19 December 2022. - **2023-01-01 - Complementary Climate Act Applies**: Complementary Climate Delegated Act (gas and nuclear) enters into application - **2023-01-01 - Disclosures Delegated Act applies (non-financial undertakings)**: Remaining provisions of the Disclosures Delegated Act apply from 1 January 2023 for non-financial undertakings. - **2023-02-01 - Platform Second Mandate Begins**: Platform on Sustainable Finance begins its second mandate (February 2023). - **2023-06-13 - Environmental Delegated Acts Approved**: Environmental and Climate amendment delegated acts approved in principle - **2023-06-16 - Commission Notice on Taxonomy and SFDR**: Commission notice on interpretation of EU Taxonomy Regulation and links to Sustainable Finance Disclosure Regulation - **2023-06-27 - Environmental Delegated Acts Adopted**: Commission Delegated Regulations (EU) 2023/2485 (Environmental objectives) and 2023/2486 (Disclosures update) adopted - **2023-10-17 - Stakeholder Request Mechanism Launched**: EU Taxonomy stakeholder request mechanism launched for public input on technical screening criteria - **2023-11-21 - Environmental Delegated Acts Published in OJ**: Official Journal publication of Environmental Delegated Act (four environmental objectives) and Disclosures update - **2024-01-01 - Environmental Delegated Acts Apply**: Environmental Delegated Act (water, circular economy, pollution, biodiversity) enters into application - **2024-01-01 - Disclosures Delegated Act applies (financial undertakings)**: Remaining provisions of the Disclosures Delegated Act apply from 1 January 2024 for financial undertakings. - **2024-11-08 - Third Commission Notice on Article 8 Disclosures (OJ C/2024/6691)**: Commission Notice on interpretation and implementation of certain legal provisions of the Disclosures Delegated Act under Article 8 (published in OJ C on 8 November 2024). - **2024-11-29 - Draft Commission Notice (November 2024) Approved in Principle**: Draft Commission notice providing comprehensive guidance on Environmental, Climate, and Disclosures Delegated Acts is approved in principle on 29 November 2024. - **2025-02-26 - Simplification Omnibus Package**: Legislative package simplifying taxonomy reporting and disclosure requirements - **2025-03-01 - Platform Second Mandate Ends**: Platform on Sustainable Finance second mandate ends (extended until March 2025). - **2025-03-01 - Commission Notice on Three Delegated Acts**: Commission notice on interpretation of Environmental, Climate, and Disclosures Delegated Acts - **2025-07-04 - Omnibus Delegated Act Adopted**: Delegated Act amending Taxonomy Disclosures, Climate and Environmental Delegated Acts (simplification measures) - **2025-12-17 - Draft Notice on Omnibus Delegated Act**: Draft Commission notice on interpretation and implementation of Disclosures Delegated Act as amended by Omnibus - **2026-01-01 - Additional Credit Institution KPIs Apply**: Additional key performance indicators for credit institutions related to trading book and commissions and fees apply from 1 January 2026. - **2026-02-01 - Platform Third Mandate Begins**: Platform on Sustainable Finance begins its third mandate (February 2026 to end of 2027). - **2050-01-01 - Climate Neutrality Target**: EU target for climate-neutral economy, supported by taxonomy framework for sustainable investment --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/taxonomy-regulation --- --- title: "Singapore PDPA Compliance Hub - DPO, Data Intermediaries, Breach Timelines, DNC, and Transfers" canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa" source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa" author: "Sorena AI" description: "Grounded Singapore PDPA compliance hub covering DPO and accountability duties, business contact information, data intermediary role limits." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Singapore PDPA compliance" - "PDPA Singapore" - "PDPC guidelines" - "Data Protection Officer Singapore" - "business contact information PDPA" - "data intermediary Singapore PDPA" - "breach notification Singapore PDPA" - "30 day breach assessment PDPA" - "3 day PDPC notification" - "DNC Registry compliance Singapore" - "cross border transfer PDPA" - "deemed consent by notification" - "legitimate interests PDPA" - "PDPA access and correction" - "PDPA vendor contracts" - "Singapore PDPA" - "PDPC" - "Data Protection Officer" - "business contact information" - "data intermediaries" - "breach notification" - "DNC Registry" - "cross-border transfers" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Singapore PDPA Compliance Hub - DPO, Data Intermediaries, Breach Timelines, DNC, and Transfers Grounded Singapore PDPA compliance hub covering DPO and accountability duties, business contact information, data intermediary role limits. ![Singapore PDPA artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-sg-pdpa-timeline-small.jpg?v=cheatsheets%2Fprod) *PDPA* *Free Resource* ## Singapore PDPA Timeline and Decision Flow A grounded Singapore PDPA hub for teams that need to move from statute and PDPC guidance into daily controls. Use the decision flow to confirm scope, business contact information treatment, organisation versus data intermediary roles, consent and notification logic, breach escalation timing, DNC duties, and transfer safeguards. The local grounding pack behind this page covers Sections 11 and 12 accountability duties, DPO appointment and publication of business contact information, the limited direct obligations of data intermediaries, the 30 calendar day breach assessment window, the 3 calendar day PDPC reporting deadline after a notifiable determination, and the continuing responsibility of the organisation for overseas transfers. [Get a PDPA review](/contact.md) ## What you can decide faster - **Role and scope**: Separate organisations from data intermediaries, recognise business contact information exclusions, and record which PDPA duties apply. - **Breach timing**: Run the 30 day assessment window correctly and escalate to the PDPC within 3 calendar days once a breach is assessed as notifiable. - **Vendors and transfers**: Keep accountability with the organisation while contracting for data intermediary controls and overseas transfer safeguards. By Sorena AI | Updated 2026 | No signup required ### Quick scan *PDPA* - **Accountability**: DPO appointment, published contact details, policies and practices, and access to information about them on request. - **Data intermediary model**: Protection, retention limitation, and breach obligations may sit differently for vendors, but the organisation still owns the wider programme. - **Breach and DNC**: Assess fast, notify the PDPC on time, and operate marketing controls that do not drift away from registry and consent rules. Use the decision flow and topic guides to align legal, security, operations, and marketing on one documented Singapore PDPA programme. | Value | Metric | | --- | --- | | PDPC | Regulator | | Consent | Core | | Breach | Notify | | Transfer | Safeguard | **Key highlights:** Consent logic | Breach readiness | Transfers ## Topic Guides - [Singapore PDPA Applicability Test | Does the PDPA Apply to Your Organisation?](/artifacts/apac/singapore-pdpa/applicability-test.md): Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation. - [Singapore PDPA Breach Notification Playbook - Complete Guide](/artifacts/apac/singapore-pdpa/breach-notification-playbook.md): Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline. - [Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026)](/artifacts/apac/singapore-pdpa/checklist.md): Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules. - [Singapore PDPA Compliance Deadlines and Calendar](/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar.md): Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows. - [Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM](/artifacts/apac/singapore-pdpa/compliance.md): Complete Singapore PDPA compliance guide for organisations. - [Singapore PDPA Consent and Notification Obligations Guide](/artifacts/apac/singapore-pdpa/consent-notification-and-purposes.md): Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception. - [Singapore PDPA Cross-Border Transfer Rules | Section 26 Data Transfer Compliance](/artifacts/apac/singapore-pdpa/cross-border-transfers.md): Complete guide to Singapore PDPA cross-border transfer compliance under Section 26. - [Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide](/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages.md): Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses. - [Singapore PDPA FAQ | Frequently Asked Questions on Personal Data Protection Act Compliance](/artifacts/apac/singapore-pdpa/faq.md): Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements. - [Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions](/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases.md): Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover. - [Singapore PDPA Penalties and Fines | SGD 1M or 10% Turnover Cap + PDPC Enforcement Guide](/artifacts/apac/singapore-pdpa/penalties-and-fines.md): Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions. - [Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide](/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template.md): Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions. - [Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC)](/artifacts/apac/singapore-pdpa/requirements.md): Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18). - [Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations](/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries.md): Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion. - [Singapore PDPA Vendor Outsourcing and Contracts Guide](/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts.md): Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence. - [Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties](/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr.md): Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements. ## Key dates for Singapore PDPA *PDPA Timeline* Track milestones and programme checkpoints (not a substitute for the statute or PDPC guidance). ## Which PDPA obligations apply to your organisation *PDPA Decision Flow* Use the decision flow to map consent and notification choices, then convert outcomes into workflows and evidence. *Next step* ## Turn Singapore PDPA Timeline and Decision Flow into a cited research workflow Singapore PDPA Timeline and Decision Flow should be the shared entry point for your team. Route execution into Research Copilot for live work and into Assessment Autopilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from Singapore PDPA Timeline and Decision Flow and route the work by entity, product, team, or control owner. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs for Singapore PDPA Timeline and Decision Flow. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints from the same artifact. - **Download decision flow**: Share scope logic internally. - **Download timeline**: Align milestones across teams. - [Talk through Singapore PDPA Timeline and Decision Flow](/contact.md): Review your current process, evidence model, and next steps for Singapore PDPA Timeline and Decision Flow. ## Decision Steps ### STEP 1: Are you an organisation that collects, uses or discloses personal data? *Reference: PDPA s.2(1), s.3* - PDPA applies to organisations that collect, use or disclose personal data. - Personal data = data about an individual who can be identified from that data or from that data and other information. - Organisation includes individuals, companies and associations, but excludes certain entities (see exclusions). - **NO** Out of Scope - **YES** Are you excluded from the Data Protection Provisions? ### STEP 2: Are you excluded from the Data Protection Provisions? *Reference: PDPA s.4* - Data Protection Provisions do not apply to: public agencies; individuals acting in a personal or domestic capacity; employees acting in the course of employment; business contact information used solely for business purposes. - If you are a data intermediary processing personal data on behalf of another organisation, different obligations apply (PDPA s.4(2)). - **YES** Out of Scope - **NO** Are you a data intermediary processing personal data on behalf of another organisation? ### STEP 3: Are you a data intermediary processing personal data on behalf of another organisation? *Reference: PDPA s.2(1), s.4(2)-(3)* - Data intermediary = organisation that processes personal data on behalf of another organisation (but does not include an employee of that organisation). - If yes: many Data Protection Provisions do not impose obligations on you for that processing (PDPA s.4(2)). - However: you must comply with the Protection Obligation (s.24) and Retention Limitation Obligation (s.25), and you must notify the organisation without undue delay if you become aware of a data breach (PDPA s.26C(3)(a)). - The organisation on whose behalf you are processing remains fully responsible for compliance. - **YES** Data Intermediary Obligations Apply - **NO** You are subject to PDPA Data Protection Provisions ### DNC (OUT OF SCOPE): Even if Data Protection Provisions do not apply: do you send specified marketing messages to Singapore telephone numbers? *Reference: PDPA Parts 9-9A* - If yes: DNC Provisions may apply (check DNC Registry and consent/exceptions). - If no: neither Data Protection Provisions nor DNC Provisions apply on the facts provided. - **YES** DNC Provisions Apply - **NO** Out of Scope (No DNC Activity Identified) ### IN SCOPE: You are subject to PDPA Data Protection Provisions *Reference: Parts 3-6A* - You must comply with all Data Protection Provisions: consent, purpose limitation, notification, access & correction, accuracy, protection, retention, transfer, data breach notification, and accountability. - Next: determine which specific obligations apply to your data processing activities. - -> Do you collect, use or disclose personal data? ### STEP 4: Do you collect, use or disclose personal data? *Reference: PDPA s.13* - If yes: you must obtain consent unless an exception applies. - Consent must be given voluntarily by the individual (or someone validly acting on their behalf). - Consent can be express or implied (deemed consent), depending on circumstances. - Individuals have the right to withdraw consent at any time. - -> Do you transfer personal data outside Singapore? ### STEP 5: Do you transfer personal data outside Singapore? *Reference: PDPA s.26* - If yes: you must comply with the Transfer Limitation Obligation. - Transfer includes: sending data overseas; allowing overseas entity to access or retrieve data; storing data on servers located overseas. - Organisation remains responsible for personal data transferred overseas. - **YES** Cross-Border Transfer Obligations Apply - **NO** Have you experienced a data breach? ### STEP 6: Have you experienced a data breach? *Reference: Part 6A (s.26A-26E)* - Data breach = unauthorised access, collection, use, disclosure, copying, modification or disposal of personal data; or loss of storage medium where unauthorised access is likely. - If yes: you must conduct an assessment and determine if it is a notifiable data breach. - Data breach can result from: cyber-attack, human error, system weaknesses, physical security lapses. - **YES** Is the data breach a notifiable data breach? - **NO** Have you designated one or more individuals (a DPO) to be responsible for PDPA compliance? ### STEP 7: Is the data breach a notifiable data breach? *Reference: PDPA s.26B* - Notifiable data breach = data breach that is, or is likely to, result in significant harm to affected individuals OR is, or is likely to be, of a significant scale. - Significant harm: physical, psychological, emotional, economic, financial harm; harm to reputation; identity theft; fraud. - Significant scale: affects 500 or more individuals (prescribed threshold). - If yes: you must notify PDPC and affected individuals. - **YES** Notifiable Data Breach - **NO** Have you designated one or more individuals (a DPO) to be responsible for PDPA compliance? ### STEP 8: Have you designated one or more individuals (a DPO) to be responsible for PDPA compliance? *Reference: PDPA s.11(3)-(6), s.12* - An organisation must designate one or more individuals to be responsible for ensuring that the organisation complies with the PDPA (s.11(3)). This individual is typically referred to as a Data Protection Officer (DPO). - The organisation must develop and implement policies and practices necessary to meet its obligations under the PDPA (s.12). - An organisation must make available the business contact information of at least one designated individual (s.11(5)). - Designating an individual does not relieve the organisation of its obligations under the PDPA (s.11(6)). - **YES** Do you send telemarketing messages to Singapore telephone numbers? - **NO** Designate a DPO ### STEP 9: Do you send telemarketing messages to Singapore telephone numbers? *Reference: Parts 9, 9A* - If yes: you must comply with Do Not Call (DNC) Provisions. - DNC Provisions apply to specified messages (marketing messages offering goods, services, land, business/investment opportunities) sent to Singapore telephone numbers. - DNC Registry has three registers: telephone calls, SMS, fax messages. - **YES** DNC Provisions Apply - **NO** DNC Provisions Do Not Apply ### BEST PRACTICE: Does your processing involve new technologies or significant privacy risks? *Reference: Guide to DPIAs* - Data Protection Impact Assessment (DPIA) is a good practice process to identify and mitigate privacy risks. - Conduct DPIA when: implementing new technologies; processing sensitive data; large-scale profiling or automated decision-making; cross-border transfers; significant changes to data processing. - DPIA helps demonstrate accountability and compliance with PDPA. - **YES** PDPA Full Compliance Required - **NO** PDPA Full Compliance Required ## Reference Information ### PDPA Scope Overview - PDPA establishes a general data protection law in Singapore governing collection, use and disclosure of personal data by organisations. - Two main sets of provisions: Data Protection Provisions (Parts 3-6A) and Do Not Call Provisions (Parts 9-9A). - Personal Data Protection Commission (PDPC) administers and enforces the PDPA. - Data Protection Provisions came into effect on 2 July 2014; DNC Provisions on 2 January 2014. ### Exclusions from Data Protection Provisions - Public agencies: government, statutory bodies, tribunals. - Individuals acting in personal or domestic capacity: e.g., individual collecting friend's contact details for personal use. - Employees acting in course of employment: but the employing organisation must comply with PDPA. - Business contact information (name, position, business contact details) when used solely for business purposes. - Data intermediaries: process personal data on behalf of another organisation; some obligations do not apply, but protection, retention, and limited data breach duties still apply. ### Consent Exceptions - First Schedule: consent not required if collection, use or disclosure is necessary for or related to: evaluating individual for employment/volunteer position; managing employment/volunteer relationship; investigation of breach; emergency; national interest; legal proceedings; publicly available data, and other specified purposes. - Second Schedule: additional bases for collection, use and disclosure without consent (e.g., business improvement purposes, if legitimate interests of organisation outweigh adverse effects). - Deemed consent by notification (s.15A): before relying on deemed consent by notification, an organisation must conduct an assessment to eliminate or mitigate adverse effects, provide adequate notification, and give a reasonable opt-out period and method. Deemed consent by notification does not apply to the purpose of sending direct marketing messages. - Legitimate interests exception: an organisation may collect, use or disclose personal data without consent if conditions are met, including an assessment (with a balancing test for legitimate interests). ### Purpose Limitation Obligation - Organisation may collect, use or disclose personal data only for purposes that a reasonable person would consider appropriate in the circumstances (s.18(1)). - Organisation may collect, use or disclose personal data only for purposes that have been notified to the individual or for a directly related purpose the individual would reasonably expect (s.18(2)). - For data collected before 2 July 2014: may use or disclose for purpose of collection or directly related purpose, unless individual withdraws consent (s.19). ### Notification Obligation - On or before collecting personal data, organisation must notify individual of purposes for collection, use or disclosure (s.20(1)). - If data collected from third party source, notify individual of purposes on or before first use/disclosure (s.20(2)). - Notification can be provided through a data protection policy, privacy notice, or other accessible form. - Purposes must be stated clearly and in a manner that is reasonable to expect the individual would understand. ### Access and Correction Obligations - Access (s.21): an individual has the right to request access to personal data in an organisation's possession or under its control, subject to exceptions (Fifth Schedule). Respond as soon as reasonably possible. If you cannot respond within 30 days, inform the individual in writing within 30 days when you will be able to respond. - Correction (s.22): an individual has the right to request correction of personal data, subject to exceptions (Sixth Schedule). If you cannot correct within 30 days, inform the individual in writing within 30 days when you will be able to correct. - Organisation may charge reasonable fee for access request (but must inform individual of fee before providing access). - Individual may apply to PDPC for review of fee charged or organisation's refusal to provide access/correction. ### Accuracy Obligation - Organisation must make reasonable effort to ensure personal data is accurate and complete if it is likely to be used to make a decision affecting the individual or disclosed to another organisation (s.23). - When personal data is provided directly by individual: reasonable to rely on individual to ensure accuracy unless organisation knows or has reason to believe data is inaccurate. - When collected from third party source: conduct appropriate due diligence to verify accuracy. - Maintain records of basis for relying on accuracy of data. ### Protection Obligation - Organisation must make reasonable security arrangements to protect personal data in its possession or under its control (s.24). - Security arrangements should prevent: unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks. - Consider: nature of data; harm from unauthorised access; method of storage; security measures such as encryption, access controls, audit logs, staff training. - Data intermediaries must also comply with this obligation. ### Retention Limitation Obligation - Organisation must cease to retain documents containing personal data (or remove means by which data can be associated with individuals) when it is reasonable to assume retention is no longer necessary for legal or business purposes (s.25). - Consider: purpose of collection; legal/regulatory requirements; business needs; whether individual can be contacted in future. - Anonymisation: if personal data is anonymised such that individual can no longer be identified, PDPA obligations no longer apply. - Data intermediaries must also comply with this obligation. ### Transfer Limitation Obligation - Organisation may transfer personal data outside Singapore only if it ensures the receiving organisation provides comparable standard of protection to PDPA (s.26). - Common ways to ensure comparable protection include legally enforceable obligations (e.g., contractual clauses), binding corporate rules, or consent for the overseas transfer (where appropriate). - Some scenarios (e.g., data in transit) can change how the Transfer Limitation Obligation applies. Use PDPC guidance and the Personal Data Protection Regulations for the detailed conditions. ### Data Breach Notification Obligation - Duty to assess (s.26C): upon becoming aware of a data breach, conduct an assessment as soon as practicable to determine if it is a notifiable data breach. PDPC guidance indicates organisations should generally aim to complete this assessment within 30 calendar days. - Duty to notify PDPC (s.26D): notify PDPC within 3 calendar days after determining it is a notifiable data breach. Submit notification at https://eservice.pdpc.gov.sg/case/db?ref=sorena.io - Duty to notify affected individuals (s.26D): notify affected individuals as soon as practicable (unless exception applies or PDPC prohibits notification). - Information to provide: description of breach; personal data involved; actions taken/to be taken; contact point for further information; recommendation on steps individuals can take. - Exceptions: remedial action taken before significant harm occurs; notification would prejudice security/defence/international relations; prohibited by law. - Failure to notify: financial penalties can apply under PDPA enforcement provisions. PDPC guidance indicates the cap can be up to S$1 million, or (where the organisation's annual turnover in Singapore exceeds S$10 million) up to 10% of annual turnover in Singapore, whichever is higher. ### Accountability Obligation - Compliance (s.11): organisation must comply with PDPA and is responsible for personal data in its possession or under its control (including data processed by data intermediaries on its behalf). - Policies and practices (s.12): develop and implement policies and practices necessary to meet PDPA obligations, including: process to receive and respond to complaints; communication of policies to individuals; information about policies and practices; designate one or more individuals to be responsible for compliance. - Appointing a DPO: good practice to appoint a DPO as contact point and to oversee data protection compliance. - Data Protection Management Programme (DPMP): implement DPMP with governance, processes and controls to ensure ongoing compliance. - Staff training: conduct regular data protection training and awareness programmes. ### Do Not Call Registry Obligations - Duty to check DNC Register (s.43): before sending specified message, check if Singapore telephone number is listed on relevant DNC Register (unless you have clear and unambiguous consent in evidential form or ongoing relationship exception applies). - Do not send if listed: if number is on DNC Register, do not send specified message (unless consent or exception applies). - Validity period: checking results valid for 21 days from receipt. - Contact information (s.44): specified message must contain clear and accurate information identifying sender and contact details. - Calling line identity (s.45): for voice calls, do not conceal or withhold calling line identity. - Consent (s.46): individual may give clear and unambiguous consent in written or other accessible and evidential form to receive specified messages; check DNC Register not required if valid consent obtained. - Withdrawal of consent (s.47): individual may withdraw consent at any time; organisation must cease sending specified messages. - Prohibition on dictionary attacks and address-harvesting software (s.48B): do not use automated means to generate telephone numbers or harvest numbers for sending messages indiscriminately. ### DNC Exceptions - Eighth Schedule: certain messages excluded from being specified messages: messages from public agencies; messages to organisations (B2B); messages related to ongoing relationship (e.g., account updates, subscription renewals, customer service); surveys and market research (if no marketing element); charitable/religious/political messages (if no commercial marketing). - Ongoing relationship: organisation need not check DNC Register if individual has ongoing relationship with organisation and message relates to subject of that relationship. - Clear and unambiguous consent: if individual has given written or evidential consent, no need to check DNC Register. - Requested information: if individual requested information about goods/services, may respond without checking (but only for that specific request). ### PDPC Enforcement Powers - Alternative dispute resolution (s.48G): PDPC may facilitate mediation between complainant and organisation (via Singapore Mediation Centre or CASE). - Reviews (s.48H): individual may apply to PDPC for review of organisation's decision (e.g., access/correction refusal, fee charged). - Investigations (s.50): PDPC may investigate suspected contraventions; appoint inspectors with powers to enter premises, examine documents, question persons. - Directions (s.48I): PDPC may issue directions to organisation to cease contravention, destroy data, pay compensation (up to S$20,000), take remedial action. - Financial penalties (s.48J): PDPC may impose financial penalties for intentional or negligent contraventions, subject to the applicable statutory caps and conditions (see Financial Penalties). - Voluntary undertakings (s.48L): organisation may give voluntary undertaking to PDPC to comply with PDPA. - Reconsideration (s.48N): organisation may apply to PDPC to reconsider direction or decision. - Appeals (s.48Q): organisation may appeal PDPC's direction/decision to Data Protection Appeal Panel. - Right of private action (s.48O): individual may bring civil action in court for contravention of Data Protection Provisions. ### Financial Penalties - Data Protection Provisions: PDPC may require an organisation to pay a financial penalty of up to S$1 million, or (where the organisation's annual turnover in Singapore exceeds S$10 million) up to 10% of annual turnover in Singapore, whichever is higher, for any intentional or negligent contravention of the Data Protection Provisions. - DNC Provisions (dictionary attacks and address-harvesting, PDPA s.48B(1)): for an individual, up to S$200,000; for an organisation, up to S$1 million, or (where annual turnover in Singapore exceeds S$20 million) up to 5% of annual turnover in Singapore, whichever is higher, for intentional or negligent contraventions. - Other DNC contraventions: for an individual, up to S$200,000; and in other cases, up to S$1 million. - Financial penalty calibration factors can include harm and culpability considerations, among other relevant factors. ### Offences Affecting Personal Data - Part 9B creates criminal offences for individuals (not organisations) who commit egregious mishandling of personal data: - Unauthorised disclosure (s.48D): individual knowingly or recklessly discloses personal data without authority. Penalty: fine up to S$5,000 or imprisonment up to 2 years, or both. - Improper use (s.48E): individual knowingly or recklessly uses personal data for wrongful gain or wrongful loss. Penalty: fine up to S$5,000 or imprisonment up to 3 years, or both. - Unauthorised re-identification (s.48F): individual knowingly or recklessly re-identifies anonymised information without authority. Penalty: fine up to S$5,000 or imprisonment up to 2 years, or both. - These offences apply to individuals (including employees and officers of organisations) and hold them personally accountable for egregious conduct. ### Data Protection Impact Assessment (DPIA) - DPIA is a process to identify and assess privacy risks arising from data processing and determine measures to mitigate risks. - When to conduct DPIA: new technology; processing involving sensitive/large-scale data; profiling/automated decision-making; cross-border transfers; changes that materially affect privacy risks. - DPIA steps: describe data processing; identify and assess privacy risks; determine mitigation measures; document and review. - Benefits: demonstrates accountability; builds trust; identifies compliance gaps; helps design privacy-protective systems. - PDPC Guide to Data Protection Impact Assessments provides detailed methodology and templates. ### Cross-Border Transfer Methods - Contractual clauses: ASEAN Model Contractual Clauses (MCCs); EU Standard Contractual Clauses (SCCs); PDPC sample clause for APEC CBPR/PRP certified organisations. - APEC Cross-Border Privacy Rules (CBPR) and Privacy Recognition for Processors (PRP) certification: if overseas organisation is certified, may use PDPC sample clause. - Binding corporate rules (BCRs): for intra-group transfers. - Consent: obtain consent from individual for specific overseas transfer (inform individual of jurisdiction and risks). - Other bases: necessary to perform contract; for individual's benefit; required by law; publicly available data. - Joint ASEAN-EU Guide helps organisations navigate both ASEAN MCCs and EU SCCs for transfers within ASEAN and to EU. ### Withdrawal of Consent - Individual may withdraw consent at any time by giving reasonable notice (s.16). - Organisation must: inform individual of likely consequences of withdrawal; allow and facilitate withdrawal; cease collection, use or disclosure upon withdrawal (unless exception applies). - Exceptions: withdrawal would affect legal obligations; data is needed to complete transaction or provide benefit requested; data may be retained under retention obligation or other law. - Organisation must not: impose unreasonable conditions on withdrawal; require individual to delete account to withdraw consent; penalise individual for withdrawal (but may inform of consequences). - Good practice: provide easy withdrawal mechanism (e.g., unsubscribe link, online portal, contact form). ## Possible Outcomes ### [RESULT] Out of Scope PDPA Data Protection Provisions do not apply - You are not an organisation subject to the Data Protection Provisions under PDPA. - However: DNC Provisions (telemarketing rules) may still apply if you send marketing messages to Singapore telephone numbers. - Even if excluded, consider data protection best practices to build trust. ### [RESULT] Out of Scope (No DNC Activity Identified) No PDPA obligations identified - Based on your answers, the PDPA Data Protection Provisions do not apply to you and you do not send specified marketing messages to Singapore telephone numbers. - If your activities change (e.g., you start sending telemarketing), re-check DNC Provisions and data protection obligations. ### [RESULT] Data Intermediary Obligations Apply Limited obligations under PDPA - You must comply with protection obligation (s.24): make reasonable security arrangements to protect personal data in your possession or under your control. - You must comply with retention limitation obligation (s.25): cease to retain documents containing personal data when it is reasonable to assume retention is no longer necessary. - You must notify the organisation without undue delay if you become aware of a data breach affecting personal data you process on its behalf (PDPA s.26C(3)(a)). - Many other obligations (e.g., consent, purpose, notification, access, correction, accuracy, transfer) do not impose obligations on you for that processing (PDPA s.4(2)). - The organisation on whose behalf you process data remains fully responsible for PDPA compliance. ### [ACTION REQUIRED] Cross-Border Transfer Obligations Apply Transfer Limitation Obligation (s.26) - You must ensure the overseas recipient provides a standard of protection comparable to the PDPA (Transfer Limitation Obligation). - Use an appropriate transfer mechanism (e.g., contractual clauses, binding corporate rules, consent where applicable) and document your approach. ### [ACTION REQUIRED] Notifiable Data Breach Notification duties may apply - If a data breach is notifiable under the PDPA, you must notify the PDPC and affected individuals within the required timelines and include required content. - Preserve evidence, remediate the breach, and document your assessment and notifications. ### [ACTION REQUIRED] Designate a DPO Accountability requirement - Designate one or more individuals to be responsible for ensuring that your organisation complies with the PDPA (PDPA s.11(3)). - Make available the business contact information of at least one designated individual (PDPA s.11(5)). - Adopt and maintain policies and practices necessary to meet PDPA obligations (PDPA s.12). ### [ACTION REQUIRED] DNC Provisions Apply Telemarketing messages to Singapore numbers - You must comply with the DNC Provisions (Parts 9-9A), including checking numbers against the DNC Registry (unless an exception applies) and obtaining/recording consent where required. - If your messages also involve personal data, the PDPA Data Protection Provisions continue to apply. ### [RESULT] PDPA Full Compliance Required All Data Protection Provisions apply - You must comply with all Data Protection Provisions: consent (s.13-17), purpose limitation (s.18), notification (s.20), access (s.21), correction (s.22), accuracy (s.23), protection (s.24), retention (s.25), transfer (s.26), data breach notification (Part 6A), and accountability (s.11-12). - If you send telemarketing messages, you must also comply with DNC Provisions (Parts 9-9A). - Implement a Data Protection Management Programme (DPMP) and appoint a DPO. - Conduct regular staff training and maintain documentation of policies and practices. - Be prepared for PDPC reviews, investigations and potential enforcement action. - Consider conducting DPIAs for high-risk processing activities. ### [RESULT] DNC Provisions Apply Telemarketing compliance required - You must comply with Do Not Call Provisions when sending specified messages (marketing messages) to Singapore telephone numbers. - Key obligations: check DNC Register before sending (unless consent or exception applies); include contact information in messages; do not conceal calling line identity; obtain consent in evidential form if required; allow withdrawal of consent. - Even if Data Protection Provisions do not apply to you (e.g., because telephone numbers are not personal data in your context), DNC Provisions still apply to marketing messages. - Failure to comply may result in financial penalties imposed by PDPC. ### [RESULT] DNC Provisions Do Not Apply No telemarketing or exception applies - DNC Provisions do not apply because: you do not send specified messages (marketing messages); OR your messages are excluded under Eighth Schedule (e.g., B2B, ongoing relationship, surveys without marketing, charitable/religious/political messages); OR you have obtained clear and unambiguous consent. - However: if messages contain personal data, Data Protection Provisions still apply. - Best practice: even if excluded, consider privacy-protective telemarketing practices to build trust. ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2013-01-02 | PDPC Established | Implementation Milestones | | | 2013-09-23 | Advisory Guidelines on Key Concepts Issued | Advisory Guidelines & Guides | | | 2013-09-24 | Advisory Guidelines for Selected Topics Issued | Advisory Guidelines & Guides | | | 2013-12-26 | Advisory Guidelines on the DNC Provisions Issued | Advisory Guidelines & Guides | | | 2014-01-02 | DNC Registry Provisions in Force | Implementation Milestones | | | 2014-07-02 | Main Data Protection Rules in Force | Implementation Milestones | | | 2014-09-11 | Healthcare Sector Advisory Guidelines Issued | Advisory Guidelines & Guides | | | 2015-01-23 | PDPA Version Published (Amended by S 19/2015) | Legislation & Amendments | | | 2016-01-03 | PDPA Version Published (Amended by Act 29 of 2014) | Legislation & Amendments | | | 2016-04-21 | Enforcement Advisory Guidelines Issued | Advisory Guidelines & Guides | | | 2016-10-02 | PDPA Historical Version Listed (Amended by Act 22 of 2016) | Legislation & Amendments | | | 2018-01-25 | Guide to Basic Anonymisation Published | Advisory Guidelines & Guides | | | 2019-09-01 | NRIC Advisory Guidelines Take Effect | Advisory Guidelines & Guides | | | 2020-06-09 | APEC CBPR/PRP Sample Clause Updated | Frameworks & Tools | | | 2020-11-02 | Major PDPA Amendments Passed | Legislation & Amendments | | | 2021-01-02 | PDPA Historical Version Listed (Amended by Act 40 of 2019) | Legislation & Amendments | | | 2021-01-22 | ASEAN MCC Guidance Published | Advisory Guidelines & Guides | | | 2021-02-01 | 2020 Amendments in Force - Phase 1 | Implementation Milestones | | | 2021-02-01 | DNC Advisory Guidelines Revised | Advisory Guidelines & Guides | | | 2021-02-01 | Guide on Data Protection Clauses Updated | Advisory Guidelines & Guides | | | 2021-03-15 | Data Breach Guide Updated | Advisory Guidelines & Guides | | | 2021-09-14 | DPMP Guide Updated | Advisory Guidelines & Guides | | | 2021-12-31 | 2020 Revised Edition Published | Legislation & Amendments | | | 2022-05-16 | Key Concepts Guidelines Revised | Advisory Guidelines & Guides | | | 2022-10-01 | Active Enforcement Guide Revised | Enforcement & Compliance | | | 2023-09-20 | Healthcare Sector Advisory Guidelines Revised | Advisory Guidelines & Guides | | | 2024-03-01 | AI Recommendation and Decision Systems Advisory Guidelines Issued | Advisory Guidelines & Guides | | | 2024-05-23 | Selected Topics Guidelines Revised | Advisory Guidelines & Guides | | | 2024-07-24 | Basic Anonymisation Guide Updated | Advisory Guidelines & Guides | | | 2024-12-13 | NRIC Guidance Update Announced | Advisory Guidelines & Guides | | | 2025-07-07 | New Tools and Trust Ecosystem Announced | Frameworks & Tools | | | 2025-12-05 | PDPA Version Listed (Amended by Act 19 of 2025) | Legislation & Amendments | | **Event details:** - **2013-01-02 - PDPC Established**: Personal Data Protection Commission (PDPC) officially established. Parts I, II, VIII, IX and X of the PDPA commenced operation. - **2013-09-23 - Advisory Guidelines on Key Concepts Issued**: PDPC issued Advisory Guidelines on Key Concepts in the PDPA covering consent, purpose limitation, and other core data protection concepts. - **2013-09-24 - Advisory Guidelines for Selected Topics Issued**: PDPC issued Advisory Guidelines on the PDPA for Selected Topics covering analytics, research, anonymisation, photography, and CCTVs. - **2013-12-26 - Advisory Guidelines on the DNC Provisions Issued**: PDPC issued Advisory Guidelines on the Do Not Call (DNC) Provisions, covering telemarketing rules, checking requirements, and exceptions under the PDPA. - **2014-01-02 - DNC Registry Provisions in Force**: Do Not Call (DNC) Registry provisions came into force, allowing individuals to register Singapore telephone numbers to opt out of telemarketing. - **2014-07-02 - Main Data Protection Rules in Force**: Parts III to VII of the PDPA (main data protection provisions) came into operation, including consent, purpose limitation, access, correction, and care obligations. - **2014-09-11 - Healthcare Sector Advisory Guidelines Issued**: PDPC issued Advisory Guidelines for the Healthcare Sector to help healthcare providers apply the PDPA, including consent, deemed consent, and common operational scenarios. - **2015-01-23 - PDPA Version Published (Amended by S 19/2015)**: Singapore Statutes Online lists a PDPA version published on 23 Jan 2015, with amendments referenced as S 19/2015. - **2016-01-03 - PDPA Version Published (Amended by Act 29 of 2014)**: Singapore Statutes Online lists a PDPA version published on 03 Jan 2016, with amendments referenced as Act 29 of 2014. - **2016-04-21 - Enforcement Advisory Guidelines Issued**: PDPC issued Advisory Guidelines on Enforcement of the PDPA data protection provisions, explaining directions, financial penalties, and voluntary undertakings. - **2016-10-02 - PDPA Historical Version Listed (Amended by Act 22 of 2016)**: Singapore Statutes Online lists a PDPA historical version dated 02 Oct 2016, with amendments referenced as Act 22 of 2016. - **2018-01-25 - Guide to Basic Anonymisation Published**: PDPC published Guide to Basic Data Anonymisation Techniques providing technical guidance on anonymisation methods and risk assessment. - **2019-09-01 - NRIC Advisory Guidelines Take Effect**: PDPC's Advisory Guidelines on the PDPA for NRIC and other national identification numbers take effect on 1 Sep 2019. - **2020-06-09 - APEC CBPR/PRP Sample Clause Updated**: PDPC updated its sample clause for data transfers to APEC CBPR and PRP certified organisations. - **2020-11-02 - Major PDPA Amendments Passed**: Personal Data Protection (Amendment) Act 2020 (Act 40 of 2020) passed by Parliament, introducing mandatory data breach notification, enhanced penalties, and new exceptions. - **2021-01-02 - PDPA Historical Version Listed (Amended by Act 40 of 2019)**: Singapore Statutes Online lists a PDPA historical version dated 02 Jan 2021, with amendments referenced as Act 40 of 2019. - **2021-01-22 - ASEAN MCC Guidance Published**: PDPC published Guidance for Use of ASEAN Model Contractual Clauses for cross-border data transfers. - **2021-02-01 - 2020 Amendments in Force - Phase 1**: First phase of Act 40 of 2020 amendments took effect, including mandatory data breach notification obligations, enhanced enforcement powers, and new exceptions. - **2021-02-01 - DNC Advisory Guidelines Revised**: PDPC revised the Advisory Guidelines on the DNC Provisions, including changes that took effect from 1 Feb 2021 (for example, the validity period of DNC Registry check results). - **2021-02-01 - Guide on Data Protection Clauses Updated**: PDPC updated its guide on data protection clauses for agreements relating to data intermediaries to account for PDPA amendments that came into force on 1 Feb 2021. - **2021-03-15 - Data Breach Guide Updated**: PDPC updated its Guide on Managing and Notifying Data Breaches under the PDPA, including the C.A.R.E. framework (Contain, Assess, Report, Evaluate). - **2021-09-14 - DPMP Guide Updated**: Guide to Developing a Data Protection Management Programme revised to incorporate best practices in accountability. - **2021-12-31 - 2020 Revised Edition Published**: PDPA 2020 Revised Edition came into operation, incorporating all amendments up to 1 December 2021. - **2022-05-16 - Key Concepts Guidelines Revised**: Advisory Guidelines on Key Concepts in the PDPA revised to reflect 2020 amendments including deemed consent by notification and legitimate interests. - **2022-10-01 - Active Enforcement Guide Revised**: Guide on Active Enforcement revised, setting out PDPC's proactive compliance approach and enforcement framework. - **2023-09-20 - Healthcare Sector Advisory Guidelines Revised**: PDPC revised its Advisory Guidelines for the Healthcare Sector. - **2024-03-01 - AI Recommendation and Decision Systems Advisory Guidelines Issued**: PDPC issued Advisory Guidelines on the Use of Personal Data in AI Recommendation and Decision Systems. - **2024-05-23 - Selected Topics Guidelines Revised**: Advisory Guidelines on the PDPA for Selected Topics revised covering analytics, anonymisation, photography, CCTVs, drones, and data portability. - **2024-07-24 - Basic Anonymisation Guide Updated**: Guide to Basic Anonymisation updated with practical guidance for small organizations on anonymisation workflow and techniques. - **2024-12-13 - NRIC Guidance Update Announced**: Following an MDDI statement on 13 Dec 2024 about appropriate use and misuse of NRIC numbers, PDPC noted that its NRIC advisory guidance would be updated (and remains valid in the meantime). - **2025-07-07 - New Tools and Trust Ecosystem Announced**: PDPC published a press release on new tools for data protection and trusted AI deployment, including updates around the Data Protection Trustmark and Singapore's data protection ecosystem. - **2025-12-05 - PDPA Version Listed (Amended by Act 19 of 2025)**: Singapore Statutes Online lists a PDPA version with ValidDate 05 Dec 2025, with amendments referenced as Act 19 of 2025. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/singapore-pdpa --- --- title: "UK GDPR Timeline and Decision Flow" canonical_url: "https://www.sorena.io/artifacts/uk-gdpr" source_url: "https://www.sorena.io/artifacts/uk/general-data-protection-regulation" author: "Sorena AI" description: "UK GDPR compliance hub for Article 30 records, one month rights handling, 72 hour breach reporting, IDTA and UK Addendum transfers." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK GDPR compliance" - "UK GDPR requirements" - "UK GDPR breach notification" - "UK GDPR data subject rights" - "UK GDPR IDTA" - "UK Addendum" - "UK GDPR checklist" - "Children's Code" - "UK GDPR transfers" - "UK GDPR" - "ICO guidance" - "Data Protection Act 2018" - "International transfers" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Timeline and Decision Flow UK GDPR compliance hub for Article 30 records, one month rights handling, 72 hour breach reporting, IDTA and UK Addendum transfers. ![UK GDPR compliance artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-uk-gdpr-timeline-small.jpg?v=cheatsheets%2Fprod) *UK GDPR* *Free Resource* ## UK GDPR Timeline and Decision Flow Turn UK GDPR duties into an operating model for lawful processing, Article 30 documentation, rights handling, processor oversight, international transfers, and breach response. Grounded in ICO guidance, DPA 2018 supplements, IDTA and UK Addendum materials, and child privacy resources. This is operational guidance, not legal advice. [Get a UK GDPR review](/contact.md) ## What teams can decide faster - **Whether UK GDPR applies**: Test Article 3 territorial scope, controller or processor role, and high risk triggers. - **What evidence the ICO expects**: Build Article 30 records, lawful basis files, contracts, DPIAs, and breach logs. - **How to transfer data lawfully**: Choose adequacy, the IDTA, or the UK Addendum and keep a transfer risk assessment. By Sorena AI | Updated 2026 | No signup required ### Quick scan *UK GDPR* - **Governance**: Accountability framework, Article 30 documentation, and controls. - **Rights and incidents**: DSR operations, breach notification, and communication readiness. - **Transfers and children**: IDTA and Addendum workflows plus the Children's Code implementation. Use linked subpages to execute each workstream with practical implementation detail. | Value | Metric | | --- | --- | | 72h | Breach notify | | 17.5M | Fine cap GBP | | IDTA | Transfer tool | | AADC | Children code | **Key highlights:** ICO-grounded | Transfer-ready | Audit-ready evidence ## Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/general-data-protection-regulation/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/general-data-protection-regulation/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/general-data-protection-regulation/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/general-data-protection-regulation/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/general-data-protection-regulation/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/general-data-protection-regulation/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/general-data-protection-regulation/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/general-data-protection-regulation/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/general-data-protection-regulation/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/general-data-protection-regulation/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/general-data-protection-regulation/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/general-data-protection-regulation/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/general-data-protection-regulation/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/general-data-protection-regulation/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/general-data-protection-regulation/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. ## Key milestones for UK data protection operations *UK GDPR Timeline* Track UK GDPR applicability, transfer mechanism changes, and governance checkpoints to coordinate legal, security, and product execution. ## How to operationalize UK GDPR controls *UK GDPR Decision Flow* Use the decision flow to sequence applicability assessment, records, rights handling, transfer controls, and incident response with evidence outputs. *Next step* ## Turn UK GDPR Timeline and Decision Flow into a cited research workflow UK GDPR Timeline and Decision Flow should be the shared entry point for your team. Route execution into Research Copilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from UK GDPR Timeline and Decision Flow and route the work by entity, product, team, or control owner. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs for UK GDPR Timeline and Decision Flow. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through UK GDPR Timeline and Decision Flow](/contact.md): Review your current process, evidence model, and next steps for UK GDPR Timeline and Decision Flow. ## Decision Steps ### STEP 1: Are you processing personal data as part of your organisation's activities? *Reference: UK GDPR (general)* - If you process personal data, you typically need to maintain documentation of your processing activities. - If you do not process personal data, the UK GDPR compliance obligations in this decision flow will not apply to you. - **NO** Out of scope - **YES** For this processing, are you acting as a controller, a processor, or both? ### STEP 2: For this processing, are you acting as a controller, a processor, or both? *Reference: Controllers and processors (UK GDPR)* - Controllers and processors both have documentation obligations. - When a controller uses a processor, a written contract is needed to set responsibilities and liabilities. - -> Do you maintain documentation of your processing activities and related compliance records? ### STEP 3: Do you maintain documentation of your processing activities and related compliance records? *Reference: Article 30 and related documentation* - ICO guidance describes documentation as a legal requirement and a foundation for governance. - Documentation should cover processing purposes, sharing, retention, transfers, and security measures (as applicable). - Documentation can also link to privacy notice information, consent records, controller-processor contracts, DPIA reports, and personal data breach records. - -> Do you process special category data or criminal conviction and offence data? ### STEP 4: Do you process special category data or criminal conviction and offence data? *Reference: DPA 2018 Schedule 1 conditions (documentation)* - ICO documentation guidance includes additional documentation items when you process special category data or criminal conviction and offence data. - This includes documenting the DPA 2018 condition you rely on, your lawful basis, and retention and erasure policy document details where required. - **YES** Add the required sensitive data documentation - -> Do you use processors or share personal data with other organisations? ### STEP 5: Do you use processors or share personal data with other organisations? *Reference: Contracts and data sharing (accountability)* - Where a controller uses a processor, ICO guidance highlights the need for a written contract with required terms. - If you share personal data, you should ensure you have a lawful basis and document it (and reflect it in your privacy notice where relevant). - -> Do you use cookies or similar technologies on user devices? ### STEP 6: Do you use cookies or similar technologies on user devices? *Reference: PECR cookies guidance (consent and information)* - ICO PECR guidance states you must tell people if you set cookies, explain what they do and why, and get the user's consent. - Consent must be actively and clearly given, and must be freely given, specific, informed, and involve an unambiguous positive action. - -> Is the processing likely to result in high risk, so that a DPIA is needed? ### STEP 7: Is the processing likely to result in high risk, so that a DPIA is needed? *Reference: DPIA guidance (accountability and governance)* - ICO DPIA guidance provides a checklist and criteria to help you decide when you should do a DPIA. - Examples include certain types of profiling, automated decision-making, large-scale processing, and processing of children's data in certain contexts. - -> Do you need to appoint a Data Protection Officer (DPO), or otherwise ensure sufficient expertise and governance? ### STEP 8: Do you need to appoint a Data Protection Officer (DPO), or otherwise ensure sufficient expertise and governance? *Reference: DPO and governance (accountability)* - ICO guidance states some organisations are required to appoint a DPO. - Even if you are not obliged to appoint a DPO, ensure you have sufficient staff, skills, and reporting structures to meet UK GDPR obligations. - -> Have you implemented appropriate technical and organisational security measures? ### STEP 9: Have you implemented appropriate technical and organisational security measures? *Reference: Security and accountability* - ICO guidance explains you should implement technical and organisational measures, with a level of security appropriate to the risk. - Examples include information security policies, access controls, security monitoring, and recovery plans. - -> Has a personal data breach occurred, or do you need to strengthen breach readiness? ### STEP 10: Has a personal data breach occurred, or do you need to strengthen breach readiness? *Reference: Breach detection and reporting* - ICO breach guidance defines a personal data breach as a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. - ICO breach guidance states some breaches must be reported to the supervisory authority within 72 hours of becoming aware (where feasible). - ICO breach guidance also states you must keep a record of personal data breaches, regardless of whether you notify. - -> Do you make restricted international transfers of personal data (outside the UK)? ### STEP 11: Do you make restricted international transfers of personal data (outside the UK)? *Reference: International transfers: appropriate safeguards* - ICO guidance explains how to use standard data protection clauses as appropriate safeguards for restricted transfers. - For restricted transfers, you may choose either the UK IDTA or the UK Addendum to the EU SCCs, and you must also complete a transfer risk assessment (TRA). - -> Is your online service likely to be accessed by children in the UK? ### STEP 12: Is your online service likely to be accessed by children in the UK? *Reference: Children's Code (Age Appropriate Design Code)* - Age Appropriate Design Code materials describe expectations for online services likely to be accessed by children, including privacy notices and transparency approaches that work for children. - Use DPIAs and governance to embed child-appropriate safeguards where relevant. - -> Do you use automated decision-making or profiling that affects individuals? ### STEP 13: Do you use automated decision-making or profiling that affects individuals? *Reference: Individual rights: automated decision-making and profiling* - ICO individual rights guidance explains the UK GDPR has provisions on automated individual decision-making and profiling. - Ensure your documentation and privacy information cover automated decision-making where applicable. - -> UK GDPR operations baseline ## Reference Information ### Controller and processor overview (operational view) - Both controllers and processors should document processing activities (Article 30 record keeping is addressed in ICO documentation guidance). - If you use processors, put written contracts in place and include terms such as security requirements and assistance with individual rights. - A single organisation can be a controller for some processing and a processor for other processing. ### Documentation: what to keep (practical list) - Keep a record of processing activities in writing and keep it up to date. - Document processing purposes, data sharing, retention, transfers, and security measures. - Link supporting records such as privacy notice information, consent records, controller-processor contracts, DPIA reports, and personal data breach records. - Use ICO templates where helpful (controller and processor documentation templates). ### Contracts with processors (what to include) - Put a written contract in place when a controller uses a processor. - Include required terms, such as requiring the processor to take appropriate security measures and to assist with individual rights. - Clear and comprehensive contracts help demonstrate accountability. ### Cookies and consent (PECR essentials) - Tell people if you set cookies and explain what they do and why. - Get the user's consent to store non-essential cookies on their device. - Do not set non-essential cookies before the user has consented, and do not treat continued browsing as consent. ### DPIA: what to do and what to record - Use the DPIA process to identify and reduce data protection risks before you start (or while you change) processing. - Record the outcomes of the DPIA, including decisions, mitigations, and any consultation (including with a DPO where relevant). - Link the DPIA to supporting documents where relevant (for example privacy notices and consent documents). ### DPO position and tasks (high level) - ICO guidance describes DPO tasks including advising on the UK GDPR, monitoring compliance, and training staff. - ICO guidance describes the DPO as reporting to the highest level of management, operating independently, and having adequate resources. ### Security measures (risk based) - Implement measures appropriate to risk to protect confidentiality, integrity, and availability. - Define staff responsibilities and embed security into your governance and operating model. - Security readiness supports breach prevention and can affect enforcement outcomes. ### Breach response (core obligations) - Prepare a breach response plan with clear roles and escalation paths. - Notify the ICO within 72 hours of becoming aware of a reportable breach where feasible, and be ready to provide information in phases. - Inform affected individuals without undue delay when there is a high risk to rights and freedoms. - Document breaches, including cases where you decide notification is not required. ### Restricted transfers: use IDTA or Addendum and complete a TRA - Choose the IDTA or the Addendum for restricted transfers; the Addendum may be helpful if you also rely on EU SCCs for EEA flows. - Complete a TRA and add any extra steps or protections needed to meet the data protection test. - Complete the required tables and avoid making changes that reduce protection, as described in ICO guidance. ### Children's data: apply the Children's Code where relevant - If your online service is likely to be accessed by children, use the Children's Code guidance to shape design and governance decisions. - Consider child-specific risks in DPIAs and ensure transparency information is accessible to children. ### Individual rights you should be ready to operationalise - Right to be informed about collection and use of personal data. - Right of access, rectification, erasure, restriction, portability, and objection. - Rights related to automated decision-making including profiling. ### Data protection principles (what your program must support) - Lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality (security); accountability. - ICO guidance notes that failure to comply with the principles may lead to substantial fines (up to GBP 17.5 million or 4% of worldwide turnover for the highest tier). ### UK GDPR and the Data Protection Act 2018 work together - ICO UK GDPR guidance and resources explain how the UK GDPR guidance is organised and how the ICO presents UK GDPR topics and resources. - ICO documentation guidance highlights DPA 2018 Schedule 1 conditions and policy document considerations for certain types of sensitive processing. ## Possible Outcomes ### [RESULT] Out of scope No personal data processing identified - If you are not processing personal data, the UK GDPR documentation and operations described here will not apply. - If you later start processing personal data, revisit these steps and document your activities. ### [ACTION] Add the required sensitive data documentation Document conditions, lawful basis, and retention/erasure policy - Document the DPA 2018 condition you rely on for special category or criminal conviction and offence data (where required in Schedule 1). - Document the lawful basis for processing. - Document whether you retain and erase the personal data in accordance with your policy document, where required. ### [RESULT] UK GDPR operations baseline Document, govern, secure, and be breach and transfer ready - Maintain documentation of processing and supporting records (privacy information, consent, contracts, DPIAs, breach logs). - Use contracts where controllers use processors, and document data sharing decisions and lawful basis where relevant. - Implement security measures appropriate to the risk and keep breach response processes ready (including 72 hour reporting where feasible). - If you make restricted international transfers, choose IDTA or Addendum and complete a transfer risk assessment. - Operationalise individual rights and account for automated decision-making and children's data where relevant. ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2003-01-01 | PECR 2003 referenced alongside UK data protection | UK Legislation | | | 2018-01-01 | Data Protection Act 2018 referenced as a core legal basis | UK Legislation | | | 2020-06-10 | Children's Code produced and laid before Parliament | ICO Guidance & Codes | | | 2020-07-03 | Children's Code impact assessment dated | ICO Guidance & Codes | | | 2021-01-01 | UK GDPR applies in the UK | UK Legislation | | | 2021-06-04 | EU SCCs Implementing Decision (EU) 2021/914 referenced | International Transfers | | | 2022-02-02 | ICO issues IDTA and UK Addendum (laid before Parliament) | International Transfers | | | 2022-03-21 | IDTA and UK Addendum in force | International Transfers | | | 2025-06-19 | Data (Use and Access) Act 2025 comes into law | Legislative Amendments | | **Event details:** - **2003-01-01 - PECR 2003 referenced alongside UK data protection**: Age Appropriate Design Code impact assessment materials reference the Privacy and Electronic Communications Regulations 2003 (PECR) as part of the wider UK privacy framework. - **2018-01-01 - Data Protection Act 2018 referenced as a core legal basis**: Grounding sources repeatedly reference the Data Protection Act 2018 (for example s119A and s123), including as the basis for standard data protection clauses and statutory codes of practice. - **2020-06-10 - Children's Code produced and laid before Parliament**: Age Appropriate Design Code impact assessment materials state that the code was produced by the Information Commissioner and laid before Parliament on 10 June 2020. - **2020-07-03 - Children's Code impact assessment dated**: Age Appropriate Design Code impact assessment materials list an impact assessment date of 3 July 2020. - **2021-01-01 - UK GDPR applies in the UK**: Grounding documentation states that the UK GDPR applies from 1 January 2021 following the UK's exit from the EU, alongside the Data Protection Act 2018. - **2021-06-04 - EU SCCs Implementing Decision (EU) 2021/914 referenced**: The UK International Data Transfer Addendum references Commission Implementing Decision (EU) 2021/914 of 4 June 2021 (the Approved EU SCCs). - **2022-02-02 - ICO issues IDTA and UK Addendum (laid before Parliament)**: IDTA (VERSION A1.0) and the UK Addendum to the EU SCCs (VERSION B1.0) were issued by the ICO and laid before Parliament on 2 February 2022 as standard data protection clauses for restricted transfers. - **2022-03-21 - IDTA and UK Addendum in force**: IDTA (VERSION A1.0) and the UK Addendum (VERSION B1.0) are stated as being in force on 21 March 2022. - **2025-06-19 - Data (Use and Access) Act 2025 comes into law**: ICO guidance pages note that the Data (Use and Access) Act 2025 came into law on 19 June 2025 and that related guidance is under review. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/general-data-protection-regulation --- --- title: "UK Online Safety Act Compliance Hub: Scope, Illegal Harms, Child Safety, and Ofcom Readiness" canonical_url: "https://www.sorena.io/artifacts/uk/online-safety-act" source_url: "https://www.sorena.io/artifacts/uk/online-safety-act" author: "Sorena AI" description: "Grounded UK Online Safety Act hub covering regulated user-to-user and search services, illegal content duties, child access and child risk assessments." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK Online Safety Act compliance" - "Ofcom online safety" - "illegal content risk assessment" - "children access assessment" - "children risk assessment" - "age assurance guidance" - "category 1 services" - "UK online safety penalties" - "illegal content duties" - "children safety duties" - "age assurance" - "risk assessments" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK Online Safety Act Compliance Hub: Scope, Illegal Harms, Child Safety, and Ofcom Readiness Grounded UK Online Safety Act hub covering regulated user-to-user and search services, illegal content duties, child access and child risk assessments. ![UK Online Safety Act compliance hub preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-uk-online-safety-timeline-small.jpg?v=cheatsheets%2Fprod) *UK OSA* *Compliance Hub* ## UK Online Safety Act Scope, Duties, and Implementation This hub is built around the live implementation sequence for the UK Online Safety Act. It covers service scope, illegal content duties, child access and child risk assessments, age assurance, moderation and complaints design, categorised service duties, and Ofcom enforcement exposure. Use the root timeline and decision flow first. Then use the subpages to work from the real implementation milestones: the Act passed on 26 October 2023, criminal offences took effect on 31 January 2024, illegal harms codes were approved on 16 December 2024, section 81 took effect on 17 January 2025, and services likely to be accessed by children had until 24 July 2025 to complete their children's risk assessment. [Start with the applicability test](/artifacts/uk/online-safety-act/applicability-test.md) ## What you can decide faster - **Scope and service model**: Test regulated user-to-user, search, and provider pornography scenarios before you promise dates or controls. - **Duty sequencing**: Separate illegal content, child access, child safety, complaints, terms, transparency, and categorised service duties. - **Ofcom readiness**: Build the evidence pack for risk assessments, control design, terms enforcement, and regulator responses. By Sorena AI | Grounded in UK OSA, GOV.UK, Ofcom, and ICO materials | Updated March 2026 ### Implementation focus *UK OSA* - **Scope and exclusions**: Start with sections 3 to 5, Schedule 1 exemptions, and the service-specific child-access test. - **Live deadlines**: Track the 16 March 2025 illegal risk assessment deadline, the 16 April 2025 child access assessment deadline, and the 24 July 2025 child risk assessment deadline. - **Evidence and enforcement**: Prepare for Ofcom information notices, complaints process scrutiny, terms enforcement checks, and penalties. Use the decision flow first, then move into the specific duty pages and templates for execution. | Value | Metric | | --- | --- | | 26 Oct 2023 | Act passed | | 16 Mar 2025 | Illegal risk deadline | | 24 Jul 2025 | Child risk deadline | | Cat 1 2A 2B | Categories | **Key highlights:** Illegal harms | Child safety | Age assurance ## Topic Guides - [UK Online Safety Act Age Assurance Options | Age Estimation, Verification, and Child Access Controls](/artifacts/uk/online-safety-act/age-assurance-options.md): Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance. - [UK Online Safety Act Applicability Test | Regulated Service, Exemptions, and UK Scope](/artifacts/uk/online-safety-act/applicability-test.md): Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope. - [UK Online Safety Act Checklist | Scope, Risk, Child Safety, Moderation, and Evidence](/artifacts/uk/online-safety-act/checklist.md): Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints. - [UK Online Safety Act Children Safety Duties | Child Access, Child Risk, and Age Assurance](/artifacts/uk/online-safety-act/children-safety-duties.md): Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments. - [UK Online Safety Act Compliance Program | Governance, Controls, and Ofcom Readiness](/artifacts/uk/online-safety-act/compliance.md): Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics. - [UK Online Safety Act Content Moderation and Appeals | Complaints, Terms Enforcement, and Redress](/artifacts/uk/online-safety-act/content-moderation-and-appeals.md): Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement. - [UK Online Safety Act Deadlines and Compliance Calendar | 2023 to 2026 Milestones](/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar.md): Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes. - [UK Online Safety Act Enforcement and Penalties | Ofcom Notices, Penalties, and Escalation](/artifacts/uk/online-safety-act/enforcement-and-penalties.md): Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions. - [UK Online Safety Act FAQ | Scope, Child Duties, Categories, and Ofcom Enforcement](/artifacts/uk/online-safety-act/faq.md): Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties. - [UK Online Safety Act Illegal Content Duties | Illegal Harms, Priority Offences, and Risk Assessments](/artifacts/uk/online-safety-act/illegal-content-duties-explained.md): Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments. - [UK Online Safety Act Penalties and Fines | GBP 18 Million, 10 Percent Revenue, and Liability](/artifacts/uk/online-safety-act/penalties-and-fines.md): Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap. - [UK Online Safety Act Requirements | Sections, Deadlines, Controls, and Evidence](/artifacts/uk/online-safety-act/requirements.md): Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation. - [UK Online Safety Act Risk Assessment Template | Illegal Content and Child Safety Template](/artifacts/uk/online-safety-act/online-safety-risk-assessment-template.md): Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety. - [UK Online Safety Act Risk Assessments Playbook | How to Run Illegal and Children Risk Reviews](/artifacts/uk/online-safety-act/risk-assessments-playbook.md): Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design. - [UK Online Safety Act Service Scope and Categorization | Category 1, 2A, 2B, and Part 3 Logic](/artifacts/uk/online-safety-act/service-scope-and-categorization.md): Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A. - [UK Online Safety Act vs EU Digital Services Act | Scope, Child Safety, and Enforcement Differences](/artifacts/uk/online-safety-act/online-safety-act-vs-dsa.md): Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks. ## Key dates for UK OSA implementation *Online Safety Timeline* Track milestones that shape duties, codes, and operational readiness so legal, policy, trust and safety, and engineering teams can execute in sync. ## How do Online Safety Act duties apply to your service model *Online Safety Decision Flow* Follow the flow from service scope and categorization to duty-specific implementation patterns, then execute via topic guides, templates, and checklists. *Next step* ## Turn UK Online Safety Act Scope, Duties, and Implementation into an operational assessment workflow UK Online Safety Act Scope, Duties, and Implementation should be the shared entry point for your team. Route execution into Assessment Autopilot for live work and into Research Copilot when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from UK Online Safety Act Scope, Duties, and Implementation and route the work by entity, product, team, or control owner. - Use Assessment Autopilot to turn the guidance into owned tasks, evidence requests, and review checkpoints. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Assessment Autopilot](/solutions/assessment.md): Turn the guidance into owned tasks, evidence requests, and review checkpoints for UK Online Safety Act Scope, Duties, and Implementation. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs from the same artifact. - [Talk through UK Online Safety Act Scope, Duties, and Implementation](/contact.md): Review your current process, evidence model, and next steps for UK Online Safety Act Scope, Duties, and Implementation. ## Decision Steps ### STEP 1: Do you provide an in-scope service (user-to-user or search) that has links to the UK? - In-scope services include search services and services that allow users to post content online or interact with each other. - The Act can apply even if you are outside the UK if your service has links to the UK (for example significant UK users, the UK as a target market, or access by UK users with a material risk of significant harm). - Source: https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io - **YES** Do any statutory exclusions or exemptions apply to your service? - **NO** Online Safety Act duties likely do not apply ### STEP 2: Do any statutory exclusions or exemptions apply to your service? - The Act contains exclusions and exemptions (including in Schedule 1). - If an exemption applies, your service (or a part of it) may be outside the Online Safety Act duties. - Source (Schedule 1): https://www.legislation.gov.uk/ukpga/2023/50/schedule/1?ref=sorena.io - **YES** Exempt or excluded service (check Schedule 1 and scope provisions) - **NO** Which in-scope service type do you provide? ### STEP 3: Which in-scope service type do you provide? - User-to-user: users can post content and/or interact with each other on the service. - Search: the service provides search functionality for users. - If you provide both, assess both elements. - -> Illegal content duties apply (in-scope services) ### STEP 4: Is your service likely to be accessed by children? - If yes, the Act requires additional protections for children and Ofcom has published and will continue to publish guidance and codes for the child safety regime. - GOV.UK explains that providers may need to perform a children's access assessment to determine whether the service is likely to be accessed by children. - Source: https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io - **YES** Child safety duties apply (likely accessed by children) - **NO** Do you publish your own pornographic content (a Part 5 service)? ### STEP 5: Do you publish your own pornographic content (a Part 5 service)? - GOV.UK explains that platforms publishing their own pornographic content (Part 5 services) must take steps immediately to introduce robust age checks that meet Ofcom guidance. - GOV.UK references section 81 coming into force on 17 January 2025 for the corresponding duty. - Source: https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io - **YES** Implement robust age checks for pornographic content - **NO** Is your service a categorised service (Category 1, 2A, or 2B) under the Act's categorisation framework? ### STEP 6: Is your service a categorised service (Category 1, 2A, or 2B) under the Act's categorisation framework? - GOV.UK explains that some platforms must comply with additional requirements to enhance transparency and accountability. - Threshold conditions for Category 1, 2A, and 2B are set via secondary legislation, and Ofcom publishes a register of categorised services. - Source: https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io - Threshold regulations (reference): https://www.legislation.gov.uk/ukdsi/2025/9780348267174?ref=sorena.io - **YES** Additional duties for categorised services (transparency and accountability) - **NO** Not categorised (yet): core duties still apply ## Reference Information ### In-Scope Examples (GOV.UK) - User-to-user examples: social media, video-sharing platforms, online forums, dating services, instant messaging services. - Other examples listed by GOV.UK: consumer file cloud storage and sharing sites. - Source: https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io ### Proportionality and Users' Rights (GOV.UK) - Safety duties are proportionate to factors including risk of harm, and the size and capacity of each provider. - Ofcom is required to take users' rights into account when setting out steps in codes of practice, and providers must pay particular regard to users' rights when fulfilling duties. - Source: https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io ### Harmful Algorithms (Risk Assessments) - GOV.UK states providers must consider how algorithms affect users' exposure to illegal content and children's exposure to harmful content as part of risk assessments. - Mitigations can include changes to design, functionalities, algorithms, and other features used to disseminate content. - Categorised services' transparency reports can include information about algorithms and their effects on users (including children). - Source: https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io ### Women and Girls (Illegal Harms) - GOV.UK explains that illegal content includes harassment, stalking, controlling or coercive behaviour, extreme pornography, and intimate image abuse. - All user-to-user and search services have duties to put in place systems and processes to remove illegal content when it is flagged. - Ofcom is required to consult relevant commissioners when developing codes, and to produce guidance summarising measures to tackle abuse that women and girls disproportionately face online. - Source: https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io ### Misinformation and Disinformation (GOV.UK framing) - GOV.UK explains mis- and disinformation is captured where it is illegal or harmful to children. - Services must take steps to remove illegal disinformation content if they become aware of it on their services (including certain state-sponsored disinformation through the Foreign Interference Offence). - Category 1 services also need to remove certain types of mis- and disinformation if prohibited in their terms of service. - Source: https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io ### Enforcement (Ofcom powers per GOV.UK) - Ofcom can assess and enforce compliance with the framework once duties and codes are in effect. - GOV.UK states companies can be fined up to GBP 18 million or 10 percent of qualifying worldwide revenue, whichever is greater. - GOV.UK states criminal action can be taken against senior managers who fail to ensure companies follow information requests from Ofcom. - In extreme cases (with court agreement), Ofcom can require payment providers, advertisers, and internet service providers to stop working with a site. - Source: https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io ### Primary Sources - GOV.UK explainer: https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io - Online Safety Act 2023 (legislation.gov.uk): https://www.legislation.gov.uk/ukpga/2023/50/contents?ref=sorena.io - Schedule 1 (exemptions and exclusions): https://www.legislation.gov.uk/ukpga/2023/50/schedule/1?ref=sorena.io - Category threshold regulations (reference): https://www.legislation.gov.uk/ukdsi/2025/9780348267174?ref=sorena.io ## Possible Outcomes ### [OUT OF SCOPE] Online Safety Act duties likely do not apply Document your scope analysis and re-check if your product changes. - If your service is neither a user-to-user service nor a search service, the main Online Safety Act duties described in the GOV.UK explainer are unlikely to apply. - If you do not have links to the UK, you may be out of scope even if your service is accessible online. - Source: https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io ### [OUT OF SCOPE] Exempt or excluded service (check Schedule 1 and scope provisions) Keep evidence for auditors, partners, and investors. - Confirm which exemption or exclusion applies, and whether it applies to the whole service or only certain functionality. - If you offer multiple functions, some parts may still be in scope even if another part is exempt. - Source (Schedule 1): https://www.legislation.gov.uk/ukpga/2023/50/schedule/1?ref=sorena.io ### [CORE DUTIES] Illegal content duties apply (in-scope services) Build systems and processes to reduce illegal harm and remove illegal content. - Implement measures to reduce the risks your service is used for illegal offending, and put systems in place to remove illegal content when it appears. - Search services also have duties to reduce the risks users encounter illegal content via the service. - The Act includes a list of priority offences; examples referenced by GOV.UK include child sexual abuse, terrorism, fraud, extreme pornography, illegal drugs or weapons, people smuggling, and intimate image abuse. - Remove other illegal content where there is an individual victim when it is flagged by users or you become aware of it through other means. - Use Ofcom codes of practice and guidance as the implementation baseline once finalised. - Source: https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io ### [CHILD SAFETY] Child safety duties apply (likely accessed by children) Prevent children from encountering harmful and age-inappropriate content. - Protect children from content that is illegal, and from content that is harmful or age-inappropriate even if it is not illegal. - GOV.UK describes Primary Priority Content (including pornography and content that encourages self-harm, eating disorders, or suicide) and Priority Content (including bullying and abusive or hateful content). - Enforce age limits consistently. If you use measures to prevent access for underage users, specify in your terms of service what measures are used and enforce them consistently. - Platforms that are likely to be accessed by children must prevent children of all ages from encountering legal content that encourages, promotes, or provides instruction for suicide and self-harm. - Source: https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io ### [AGE ASSURANCE] Implement robust age checks for pornographic content Align age assurance with Ofcom guidance. - Introduce robust age checks that meet Ofcom guidance for services publishing their own pornographic content (Part 5 services). - Update terms, user journeys, and operational processes to ensure the checks are effective and consistently enforced. - Source: https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io ### [CATEGORISED] Additional duties for categorised services (transparency and accountability) Plan for additional obligations if you are Category 1, 2A, or 2B. - Categorised services must publish annual transparency reports with online safety related information, including information about algorithms and their effect on users' experience (including children). - Category 1 user-to-user services: offer adult users tools for greater control over the content they see and who they engage with, including identity verification options, where applicable. - Category 1 user-to-user services: after Ofcom guidance, proactively offer optional tools to reduce exposure to certain categories of legal content (including content encouraging suicide, self-harm, or eating disorders, and abusive or hateful content). - Category 1 user-to-user services: uphold your terms of service where you say you will remove or restrict content or suspend users, and provide effective reporting and redress mechanisms about enforcement of terms. - Category 1 services: remove certain types of mis- and disinformation if they are prohibited in your terms of service. - Source: https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io ### [NOT CATEGORISED] Not categorised (yet): core duties still apply You still need illegal content duties and, if relevant, child safety duties. - Even if you are not a Category 1, 2A, or 2B service, GOV.UK describes core duties that apply to in-scope services (illegal content, and child safety where relevant). - Monitor Ofcom updates and the Ofcom register of categorised services if your service may meet threshold conditions over time. - Source: https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2018-03-31 | PAS 1296:2018 published | Standards | | | 2020-09-01 | Children's Code comes into force (September 2020) | Children's Protection | | | 2021-01-01 | IEEE 2089-2021 referenced | Standards | | | 2021-09-02 | Children's Code transition period ends (September 2021) | Children's Protection | | | 2023-03-01 | Children's Code evaluation published (March 2023) | Children's Protection | | | 2023-10-26 | Online Safety Act 2023 passed into law | Legislation | | | 2024-01-01 | IEEE 2089.1-2024 referenced | Standards | | | 2024-01-31 | Criminal offences under the Act take effect | Enforcement | | | 2024-04-01 | ICO Children's Code Strategy published (April 2024) | Children's Protection | | | 2024-07-02 | Correction slip issued for the Act | Legislation | | | 2024-09-11 | Ofcom approach to small but risky services published | Implementation | | | 2024-10-17 | Ofcom publishes updated implementation roadmap | Implementation | | | 2024-11-20 | Draft Statement of Strategic Priorities published | Guidance & Codes | | | 2024-12-16 | Illegal harms codes approved and Ofcom guidance published | Guidance & Codes | | | 2025-01-01 | Age assurance guidance for online pornography (January 2025) | Guidance & Codes | | | 2025-01-10 | Strategic Priorities consultation ends | Guidance & Codes | | | 2025-01-17 | Section 81 duty comes into force | Implementation | | | 2025-02-25 | Draft guidance published for consultation | Guidance & Codes | | | 2025-04-01 | Ofcom Advisory Committee on Disinformation first meeting | Implementation | | | 2025-06-19 | Data (Use and Access) Act 2025 triggers Children's Code guidance review | Children's Protection | | | 2025-07-01 | Register of categorised services expected (Summer 2025) | Implementation | | | 2025-07-02 | Statement of Strategic Priorities designated | Guidance & Codes | | | 2025-07-24 | Children's risk assessment deadline | Children's Protection | | | 2026-01-01 | Consultation on additional duties for categorised services (early 2026) | Guidance & Codes | | | 2026-01-05 | PAS 1296:2018 withdrawn | Standards | | **Event details:** - **2018-03-31 - PAS 1296:2018 published**: BSI published PAS 1296:2018, a code of practice for online age checking services (BSI Shop issuer record). - **2020-09-01 - Children's Code comes into force (September 2020)**: ICO Children's Code evaluation materials state the code came into force in September 2020 with a 12 month transition period. - **2021-01-01 - IEEE 2089-2021 referenced**: IEEE page for its trustworthy digital experiences for children initiative references IEEE 2089-2021 (Age Appropriate Digital Services Framework). The date is set to 2021-01-01 for ordering because the source provides a year, not a specific day. - **2021-09-02 - Children's Code transition period ends (September 2021)**: ICO Children's Code evaluation materials state that from 2 September 2021 the Commissioner began to take the code into account when considering compliance with the UK GDPR and PECR. - **2023-03-01 - Children's Code evaluation published (March 2023)**: ICO Children's Code evaluation materials (covering 2018 to 2022) were published with a cover date of March 2023. - **2023-10-26 - Online Safety Act 2023 passed into law**: GOV.UK Online Safety Act explainer states the Act passed into law on 26 October 2023. - **2024-01-01 - IEEE 2089.1-2024 referenced**: IEEE page for its trustworthy digital experiences for children initiative references IEEE 2089.1-2024 (online age verification). The date is set to 2024-01-01 for ordering because the source provides a year, not a specific day. - **2024-01-31 - Criminal offences under the Act take effect**: GOV.UK Online Safety Act explainer states that the criminal offences introduced by the Act came into effect on 31 January 2024. - **2024-04-01 - ICO Children's Code Strategy published (April 2024)**: Children's Code Strategy interim impact review notes that in April 2024 the ICO published the Children's Code Strategy (CCS) as a two-year delivery strategy. - **2024-07-02 - Correction slip issued for the Act**: Legislation.gov.uk timeline metadata indicates a correction slip dated 2 July 2024 for the Online Safety Act 2023. - **2024-09-11 - Ofcom approach to small but risky services published**: GOV.UK Online Safety Act explainer timeline references Ofcom's letter on its approach to tackling small but risky services (11 September 2024). - **2024-10-17 - Ofcom publishes updated implementation roadmap**: GOV.UK Online Safety Act explainer states that Ofcom published an updated roadmap setting out its implementation plans on 17 October 2024. - **2024-11-20 - Draft Statement of Strategic Priorities published**: Explanatory memorandum timeline notes the Secretary of State published a draft Statement of Strategic Priorities on 20 November 2024 (consultation period ran to 10 January 2025). - **2024-12-16 - Illegal harms codes approved and Ofcom guidance published**: GOV.UK Online Safety Act explainer states the illegal harms codes of practice were approved by Parliament after being laid on 16 December 2024; Ofcom also published illegal content risk assessment guidance and a policy statement on the same day. - **2025-01-01 - Age assurance guidance for online pornography (January 2025)**: GOV.UK Online Safety Act explainer states that Ofcom published guidance about age assurance to prevent children accessing online pornography in January 2025. - **2025-01-10 - Strategic Priorities consultation ends**: Explanatory memorandum timeline notes targeted stakeholder consultation on the draft Statement of Strategic Priorities closed on 10 January 2025. - **2025-01-17 - Section 81 duty comes into force**: GOV.UK Online Safety Act explainer states that the corresponding duty in the Act (section 81) came into force on 17 January 2025. - **2025-02-25 - Draft guidance published for consultation**: GOV.UK Online Safety Act explainer timeline notes that Ofcom published draft guidance for consultation on 25 February 2025. - **2025-04-01 - Ofcom Advisory Committee on Disinformation first meeting**: GOV.UK Online Safety Act explainer timeline notes the advisory committee planned its first meeting in April 2025 after appointing a Chair. - **2025-06-19 - Data (Use and Access) Act 2025 triggers Children's Code guidance review**: ICO Children's Code guidance pages note that the Data (Use and Access) Act 2025 came into law on 19 June 2025 and related guidance is under review. - **2025-07-01 - Register of categorised services expected (Summer 2025)**: GOV.UK Online Safety Act explainer timeline notes that Ofcom expects to publish the register of categorised services in Summer 2025. The date is set to 2025-07-01 for ordering because the source gives a season, not a specific day. - **2025-07-02 - Statement of Strategic Priorities designated**: Final Statement of Strategic Priorities document states the Secretary of State designated the statement for Online Safety Act 2023 purposes on 2 July 2025. - **2025-07-24 - Children's risk assessment deadline**: GOV.UK Online Safety Act explainer states that services likely to be accessed by children have a deadline of 24 July 2025 to complete their children's risk assessment. - **2026-01-01 - Consultation on additional duties for categorised services (early 2026)**: GOV.UK Online Safety Act explainer timeline notes Ofcom plans to consult on codes of practice and, where relevant, guidance for additional duties on categorised services by early 2026. The date is set to 2026-01-01 for ordering because the source gives an approximate period, not a specific day. - **2026-01-05 - PAS 1296:2018 withdrawn**: BSI Shop issuer record shows PAS 1296:2018 was withdrawn on 5 January 2026. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/online-safety-act --- --- title: "CCPA Timeline and Decision Flow" canonical_url: "https://www.sorena.io/artifacts/us-ccpa" source_url: "https://www.sorena.io/artifacts/us/california-consumer-privacy-act" author: "Sorena AI" description: "California CCPA compliance hub for scope thresholds, notice at collection, privacy policy disclosures, consumer rights, do not sell or share controls." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "CCPA compliance" - "California Consumer Privacy Act" - "CCPA requirements" - "CCPA checklist" - "CCPA privacy policy" - "do not sell or share" - "Global Privacy Control" - "CCPA penalties" - "CCPA service provider contracts" - "CCPA" - "CPRA" - "California privacy law" - "Consumer rights" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Timeline and Decision Flow California CCPA compliance hub for scope thresholds, notice at collection, privacy policy disclosures, consumer rights, do not sell or share controls. ![California CCPA compliance artifact preview](https://cdn.sorena.io/cdn-cgi/image/format=auto/cheatsheets/prod/sorena-ai-us-ccpa-timeline-small.jpg?v=cheatsheets%2Fprod) *CCPA and CPRA* *Free Resource* ## California Consumer Privacy Act Timeline and Decision Flow Translate the California Consumer Privacy Act into an operating model for threshold analysis, notice design, consumer rights handling, do not sell or share controls, and vendor contract enforcement. Built from the current California statute and CPPA regulations, including the rules effective January 1, 2026. This is implementation guidance, not legal advice. [Get a CCPA review](/contact.md) ## What teams can decide faster - **Whether the business is in scope**: Test the 25 million dollars, 100,000 consumers or households, and 50 percent sale or sharing revenue thresholds. - **What disclosures are required**: Operationalize notice at collection, privacy policy, opt out notices, and financial incentive notices. - **How to honor consumer choice**: Run 45 day rights workflows, process GPC, and push opt out instructions to vendors. By Sorena AI | Updated 2026 | No signup required ### Quick scan *CCPA* - **Scope**: Validate threshold and business-role applicability with evidence. - **Consumer rights**: Run know, delete, correct, and opt-out workflows at scale. - **Contracts and disclosures**: Align service provider contracts and privacy notices to legal requirements. Open each subpage to execute requirements with advanced, role-specific guidance. | Value | Metric | | --- | --- | | CPRA | Current regime | | GPC | Signal support | | DSAR | Rights ops | | CPPA | Regulator | **Key highlights:** Scope-ready | Rights-ready | Enforcement-aware ## Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/california-consumer-privacy-act/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/california-consumer-privacy-act/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/california-consumer-privacy-act/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/california-consumer-privacy-act/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/california-consumer-privacy-act/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/california-consumer-privacy-act/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/california-consumer-privacy-act/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/california-consumer-privacy-act/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/california-consumer-privacy-act/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/california-consumer-privacy-act/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/california-consumer-privacy-act/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/california-consumer-privacy-act/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/california-consumer-privacy-act/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/california-consumer-privacy-act/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/california-consumer-privacy-act/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/california-consumer-privacy-act/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. ## Key milestones for California privacy operations *CCPA Timeline* Track statutory, regulatory, and enforcement developments that affect privacy program decisions and implementation timing. ## How to operationalize CCPA and CPRA obligations *CCPA Decision Flow* Use the decision flow to sequence scope, rights, disclosures, sale and sharing controls, and contract updates with evidence outputs. *Next step* ## Turn California Consumer Privacy Act Timeline and Decision Flow into a cited research workflow California Consumer Privacy Act Timeline and Decision Flow should be the shared entry point for your team. Route execution into Research Copilot for live work and into SSOT when the artifact needs deeper research, evidence governance, or supporting analysis. - Start from California Consumer Privacy Act Timeline and Decision Flow and route the work by entity, product, team, or control owner. - Use Research Copilot to answer scope, timing, and interpretation questions with cited outputs. - Use SSOT to keep documents, evidence, and control records in one governed system. - Move from artifact reading to accountable execution without rebuilding the guidance in separate files. - [Open Research Copilot](/solutions/research-copilot.md): Answer scope, timing, and interpretation questions with cited outputs for California Consumer Privacy Act Timeline and Decision Flow. - [Open SSOT](/solutions/ssot.md): Keep documents, evidence, and control records in one governed system from the same artifact. - [Talk through California Consumer Privacy Act Timeline and Decision Flow](/contact.md): Review your current process, evidence model, and next steps for California Consumer Privacy Act Timeline and Decision Flow. ## Decision Steps ### STEP 1: Are you a for-profit business that collects California residents' personal information and does business in California? *Reference: Civil Code 1798.140(d)* - CCPA applies only to for-profit businesses that collect (or have others collect for them) consumers' personal information, determine why and how the information will be processed, and do business in California. - The CCPA does not generally apply to nonprofit organizations or government agencies. - A 'consumer' means a natural person who is a California resident. - **NO** Out of Scope - **YES** Does your business meet at least one of the CCPA thresholds? ### STEP 2: Does your business meet at least one of the CCPA thresholds? *Reference: Civil Code 1798.140(d)(1)* - (A) As of January 1 of the calendar year, had annual gross revenues in excess of $25,000,000 in the preceding calendar year, as adjusted pursuant to Civil Code 1798.199.95(d); OR - (B) Alone or in combination, annually buys, sells, or shares the personal information of 100,000 or more consumers or households; OR - (C) Derives 50% or more of annual revenues from selling or sharing consumers' personal information. - The CCPA also treats as a 'business' certain entities that control or are controlled by a covered business and share common branding, certain joint ventures or partnerships (40%+ interest), and entities that voluntarily certify to be bound. - **NO** Out of Scope - **YES** Are you a "business" under the CCPA (determining the purposes and means of collecting/processing personal information)? ### STEP 3: Are you a "business" under the CCPA (determining the purposes and means of collecting/processing personal information)? - If yes: the primary CCPA obligations apply (notices, consumer rights, opt-out/limit mechanisms, contracts, training, and recordkeeping). - If no: you may instead be acting as a service provider/contractor (processing on behalf of a business under a written contract) or as a third party (receiving PI but not as a service provider/contractor). - Many entities may have more than one role. - **YES** Business subject to CCPA - **NO** If not a business: are you a service provider or contractor (processing personal information on behalf of a business under a written contract)? ### STEP 3A: If not a business: are you a service provider or contractor (processing personal information on behalf of a business under a written contract)? *Reference: Civil Code 1798.140(ag), 1798.140(j)* - Service providers and contractors have specific contractual restrictions and may only use PI for business purposes specified in the contract, subject to exceptions. - If no: you are treated as a third party (additional use/disclosure restrictions can apply depending on how you receive PI). - **YES** Service Provider / Contractor Obligations - **NO** Third Party Obligations ### IN SCOPE: Business subject to CCPA *Reference: Civil Code 1798.100 et seq.* - You must comply with all CCPA requirements for businesses, including: Notice at Collection, Privacy Policy, consumer rights (know, delete, correct, opt out of sale/sharing, limit sensitive PI when applicable, ADMT rights when applicable, and non-discrimination/no retaliation), verification where required, authorized agents, contracts, record-keeping, and training. - Additional obligations may apply if you sell or share personal information, process sensitive personal information, use ADMT for significant decisions, meet cybersecurity audit criteria, or are a data broker. - -> Does your business sell or share personal information? ### STEP 4: Does your business sell or share personal information? *Reference: Civil Code 1798.140(ad), (ah)* - 'Sell' = selling, renting, releasing, disclosing, disseminating, making available, transferring, or otherwise communicating orally, in writing, or by electronic or other means, a consumer's personal information by the business to a third party for monetary or other valuable consideration. - 'Share' = sharing, renting, releasing, disclosing, disseminating, making available, transferring, or otherwise communicating orally, in writing, or by electronic or other means, a consumer's personal information by the business to a third party for cross-context behavioral advertising, whether or not for monetary or other valuable consideration. - Disclosures to service providers/contractors under written contracts are NOT sales or shares. Disclosures at the consumer's direction are NOT sales. - If you sell or share PI, you must provide a 'Do Not Sell or Share My Personal Information' link and honor opt-out preference signals. - **YES** Does your business use or disclose sensitive personal information for purposes beyond those permitted by Civil Code 1798.121(a)? - **NO** Does your business use or disclose sensitive personal information for purposes beyond those permitted by Civil Code 1798.121(a)? ### STEP 5: Does your business use or disclose sensitive personal information for purposes beyond those permitted by Civil Code 1798.121(a)? *Reference: Civil Code 1798.121* - Permitted purposes (no opt-out required): performing services/providing goods reasonably expected by the consumer; preventing fraud/security incidents/illegal activities/physical safety; performing contracted services; short-term transient use (including non-personalized advertising); verifying/maintaining quality or safety; comply with legal obligations, exercise legal claims, or defend legal claims. - If you use or disclose sensitive PI for other purposes, you must provide a 'Limit the Use of My Sensitive Personal Information' link. - You may use a single combined link ('Your Privacy Choices' or 'Your California Privacy Choices') instead of separate 'Do Not Sell or Share' and 'Limit' links. - **YES** Are you a data broker? - **NO** Are you a data broker? ### DATA BROKER: Are you a data broker? *Reference: Civil Code 1798.99.80 et seq.* - A data broker is a business that knowingly collects and sells to third parties the personal information of consumers with whom the business does not have a direct relationship. - Excludes entities covered by the Fair Credit Reporting Act, Gramm-Leach-Bliley Act, Insurance Information and Privacy Protection Act, Confidentiality of Medical Information Act, and HIPAA. - Data brokers must register with the California Privacy Protection Agency annually (January 1-31 deadline) and pay a registration fee. - **YES** Data Broker Registration Required - **NO** Does your business use Automated Decisionmaking Technology (ADMT) for significant decisions? ### ADMT: Does your business use Automated Decisionmaking Technology (ADMT) for significant decisions? *Reference: 11 CCR 7200 et seq.* - ADMT = any technology that processes personal information and uses computation to replace or substantially replace human decisionmaking (including profiling). - A significant decision is a decision that results in the provision or denial of financial or lending services, housing, education enrollment or opportunities, employment or independent contracting opportunities or compensation, or healthcare services. Advertising is not a significant decision. - Compliance deadline: January 1, 2027. - Does not include web hosting, domain registration, networking, caching, data storage, firewalls, anti-virus, spam-filtering, spellchecking, calculators, databases, or spreadsheets (if they do not replace human decisionmaking). - **YES** ADMT Requirements Apply (Compliance Deadline: January 1, 2027) - **NO** ADMT Requirements Do Not Apply ### RISK ASSESSMENT: Must your business conduct a risk assessment? *Reference: 11 CCR 7150 et seq.* - Risk assessments are required for specific processing activities that present significant risk to consumers' privacy, including selling or sharing personal information, processing sensitive personal information (subject to limited employment administration exceptions), and using ADMT for significant decisions. - Additional processing activities can also trigger a risk assessment, including certain automated processing to infer or extrapolate characteristics in employment/education contexts or based on a consumer's presence in a sensitive location, and processing PI intended to train certain ADMT or identity verification/profiling technologies. - Timing: a business must conduct and document a risk assessment before initiating a covered processing activity. For covered processing initiated before January 1, 2026 and continuing after that date, the business must conduct and document a risk assessment no later than December 31, 2027. - Updates and retention: review and update risk assessments at least once every three years (and within 45 calendar days of a material change). Retain risk assessments for as long as the processing continues or for five years after completion, whichever is later. - Submissions: for risk assessments conducted in 2026 and 2027, submit required risk assessment information to the Agency no later than April 1, 2028. For risk assessments conducted after 2027, submit no later than April 1 following any year during which the business conducted the risk assessments. - **YES** Must your business complete a cybersecurity audit? - **NO** CCPA Applies (Full Business Obligations) ### CYBERSECURITY AUDIT: Must your business complete a cybersecurity audit? *Reference: 11 CCR 7120 et seq.* - Cybersecurity audits are required if the business's processing presents significant risk to consumers' security as defined in 11 CCR 7120(b). This includes if the business meets the 50% revenue threshold in Civil Code 1798.140(d)(1)(C) in the preceding calendar year, or if the business meets the gross revenue threshold in Civil Code 1798.140(d)(1)(A) and processed the personal information of 250,000 or more consumers or households, or processed the sensitive personal information of 50,000 or more consumers, in the preceding calendar year. - First cybersecurity audit report deadlines are phased: April 1, 2028 (based on 2026 revenue as of January 1, 2027), April 1, 2029 (based on 2027 revenue as of January 1, 2028), and April 1, 2030 (based on 2028 revenue as of January 1, 2029). After April 1, 2030, annual timing continues based on whether the criteria are met as of January 1 of a year for the preceding year. - **YES** Cybersecurity Audit Required - **NO** CCPA Applies (Full Business Obligations) ## Reference Information ### Categories of Personal Information - Personal information = information that identifies, relates to, or could reasonably be linked to a particular consumer or household (name, email, purchase records, browsing history, geolocation, fingerprints, inferences about preferences/characteristics). - Sensitive personal information = subset of PI that is more sensitive: SSN, driver's license, account credentials, precise geolocation, contents of mail/email/text (unless the business is the intended recipient), genetic data, neural data, biometric information used to uniquely identify a consumer, health information, and information about sex life or sexual orientation, as well as certain other sensitive attributes listed in the statute. - Publicly available information is excluded from the definition of personal information. ### Consumer Rights Under CCPA - Right to know: request disclosure of categories and specific pieces of personal information collected, categories of sources, purposes, and categories of third parties (including categories of personal information sold/shared and to whom). - Right to delete: request deletion of personal information the business collected from the consumer, subject to statutory exceptions. - Right to correct: request correction of inaccurate personal information maintained by the business. - Right to opt out: opt out of sale and sharing (including sharing for cross-context behavioral advertising), including through opt-out preference signals where applicable. - Right to limit: limit the use and disclosure of sensitive personal information to certain permitted purposes, when the business uses or discloses it for other purposes. - ADMT rights (if applicable): right to opt out of ADMT (subject to exceptions) and right to access information about a business's use of ADMT for significant decisions. - Non-discrimination and no retaliation: businesses must not discriminate or retaliate against consumers for exercising their CCPA rights. ### Notice at Collection Requirements - Businesses must provide a Notice at Collection at or before the point of collection, describing: categories of personal information to be collected and purposes for which categories will be used; if selling or sharing PI, a notice of the right to opt-out; if using sensitive PI beyond permitted purposes, a notice of the right to limit; retention period for each category (or criteria used to determine retention). - Disclosures and communications to consumers must be reasonably accessible to consumers with disabilities. - Notice at Collection is separate from the Privacy Policy. ### Privacy Policy Requirements - Businesses must post a Privacy Policy on their homepage and other webpages (using the word 'privacy' in the link). For mobile apps, link must be available on the download page or in the app's settings menu. - The Privacy Policy must describe: categories of PI collected in the preceding 12 months and purposes for use; categories of sources; categories of PI sold/shared (if any) and categories of third parties; categories of PI disclosed for a business purpose and categories of recipients; consumer rights (know, delete, correct, opt out of sale/sharing, limit sensitive PI, ADMT rights when applicable, and no retaliation) and how to exercise them; methods for submitting requests; how long each category of PI is retained (or criteria used); and required information about any financial incentive or price/service difference. - If you are a data broker, you must register with the Data Broker Registry and disclose additional information. ### Do Not Sell or Share My Personal Information Link - If you sell or share personal information, you must provide a clear and conspicuous link on your website homepage (and other designated pages) titled 'Do Not Sell or Share My Personal Information' or 'Your Privacy Choices' or 'Your California Privacy Choices'. - The link must enable consumers (or their authorized agents) to opt-out of the sale or sharing of their personal information. - You must honor opt-out preference signals (OOPS) such as Global Privacy Control (GPC) as valid requests to opt-out of sale/sharing, and process them in a frictionless manner (without requiring consumers to take additional action). - You must comply with opt-out requests as soon as feasibly possible, up to a maximum of 15 business days. ### Limit the Use of My Sensitive Personal Information Link - If you use or disclose sensitive personal information for purposes outside those permitted by Civil Code 1798.121(a), you must provide a clear and conspicuous link on your website homepage (and other designated pages) titled 'Limit the Use of My Sensitive Personal Information' or 'Your Privacy Choices' or 'Your California Privacy Choices'. - The link must enable consumers to limit the use and disclosure of their sensitive personal information to permitted purposes. - You must comply with limit requests as soon as feasibly possible, up to a maximum of 15 business days. ### Verification of Requests - Businesses must verify the identity of consumers making requests to know, delete, or correct personal information to prevent fraudulent requests. - For password-protected accounts: verify the consumer through existing authentication practices (e.g., login credentials). For requests to know specific pieces of PI or delete/correct PI, use multi-factor authentication or another secure method if the request poses a risk of fraud. - For non-accountholders: match at least two or three data points provided by the consumer with data points maintained by the business (depending on the request type and sensitivity). For requests to know specific pieces of PI, use a signed declaration under penalty of perjury. - Businesses cannot require consumers to create an account to make a verifiable request. - Opt-out and limit requests do NOT require identity verification (but businesses may deny requests they reasonably believe to be fraudulent). ### Authorized Agents - Consumers may use an authorized agent (natural person or business entity) to submit requests on their behalf. - Businesses may require: (1) proof that the agent is authorized to act on behalf of the consumer (e.g., power of attorney or signed written permission), and (2) verification of the consumer's identity directly with the business. - If the consumer has provided the authorized agent with power of attorney pursuant to Probate Code sections 4121 to 4130, the business may not require additional proof that the agent is authorized to act on the consumer's behalf. ### Request Response Timelines - Delete, Correct, or Know requests: Confirm receipt within 10 business days. Substantively respond within 45 calendar days (may extend by another 45 days if necessary, with notice to the consumer). - Opt-out of Sale/Sharing or Limit Sensitive PI requests: Comply as soon as feasibly possible, up to a maximum of 15 business days. - Businesses must provide at least two methods for submitting delete/correct/know requests (e.g., toll-free phone number and website form). If exclusively online, may provide only an email address. - Businesses must not charge a fee for verifiable consumer requests unless manifestly unfounded or excessive (particularly if repetitive). ### Exceptions to Deletion Requests - Businesses may deny deletion requests if retaining the PI is necessary to: complete the transaction for which the PI was collected, provide a reasonably anticipated good/service, or perform a contract; detect security incidents, protect against fraud/illegal activity, or ensure physical safety; debug to identify and repair errors; exercise free speech or ensure another consumer's right to free speech, or exercise another legal right; comply with the California Electronic Communications Privacy Act (Penal Code 1546 et seq.); engage in public or peer-reviewed scientific, historical, or statistical research in the public interest; enable solely internal uses reasonably aligned with consumer expectations or the context in which the PI was provided; comply with a legal obligation; or otherwise use the PI internally in a lawful manner compatible with the context in which the consumer provided the information. - Businesses are not required to delete PI that was not collected directly from the consumer (though they must inform the consumer of the right to opt-out if they sell or share PI). - Publicly available information, certain medical information, consumer credit reporting information, and other exempt categories are excluded from deletion requirements. ### Service Provider / Contractor Obligations - Service providers and contractors process personal information on behalf of a business under a written contract. - The contract must: prohibit the service provider/contractor from selling or sharing PI (unless authorized by the business); prohibit retention, use, or disclosure of PI for any purpose other than performing the specified services or as otherwise permitted by the CCPA; prohibit combining PI with information received from other sources (except as permitted by the CCPA); grant the business the right to take reasonable and appropriate steps to ensure the service provider/contractor uses PI consistently with the business's CCPA obligations; require the service provider/contractor to notify the business if it can no longer meet its CCPA obligations; and grant consumers, subject to certain conditions, the right to enforce the service provider/contractor obligations as third-party beneficiaries. - Service providers/contractors must assist businesses with responding to consumer requests to the extent the service provider/contractor maintains the responsive information. - Service providers/contractors may be directly liable for CCPA violations if they fail to comply with their contractual obligations. ### Third Party Obligations - Third parties are persons or entities that receive personal information from a business but are not service providers or contractors. - Third parties may use PI received from a business only for the specific purpose disclosed in the Privacy Policy or Notice at Collection (or as otherwise permitted by the CCPA). - Third parties may not sell or share PI received from a business unless the consumer has received explicit notice and an opportunity to opt-out of further sales or shares. ### Data Broker Registration and Obligations - Data brokers must register with the CPPA annually (by January 31) and provide: business name, primary physical address, website, email contact, whether they collect reproductive health care data, whether they collect precise geolocation, whether they collect PI of minors, and a link to the website where consumers may exercise their CCPA rights. - Data brokers must disclose on their website privacy policy by July 1 each year (and report during registration): the number of consumer requests received in the previous calendar year (delete, access/know, know what is sold or shared and to whom, opt-out of sale/sharing, limit sensitive PI), whether they complied in part or in whole with each request, and the median and mean number of days to respond to each type of request. - SB 362 (Delete Act) requires the CPPA to establish by January 1, 2026, a Delete Request and Opt-out Platform (DROP) that allows consumers to request deletion of all personal information from all registered data brokers through a single request to the Agency. - Data brokers that fail to register by the statutory deadline may be liable for administrative fines and costs, including an administrative fine of $200 per day for each day they fail to register. ### Financial Incentives and Non-Discrimination - Businesses may offer financial incentives (including payments to consumers, price differences, or service level differences) for the collection, retention, sale, or sharing of personal information. - Businesses must provide a Notice of Financial Incentive describing: the material terms of the financial incentive; how to opt-in and withdraw (opt-in consent required for material financial incentives); a good-faith estimate of the value of the consumer's data that forms the basis for offering the incentive; and a description of the method used to calculate the value. - Financial incentives must not be unjust, unreasonable, coercive, or usurious in nature. - Businesses cannot discriminate against consumers for exercising CCPA rights (e.g., denying goods or services, charging different prices or rates, providing a different level or quality of goods or services), unless the difference is reasonably related to the value provided by the consumer's data. - Value of consumer data may be calculated using a reasonable method aligned with the value of the offered incentive, such as: marginal value of data in the context of the product or service, average value of data across all consumers, or revenue or profit generated per consumer divided by the total number of consumers. ### Special Rules for Consumers Under 16 - Businesses may not sell or share the personal information of consumers under 16 years of age unless the consumer (if 13-15 years old) or the consumer's parent or guardian (if under 13 years old) has affirmatively authorized the sale or sharing. - For consumers under 13: Businesses must comply with the Children's Online Privacy Protection Act (COPPA) and obtain verifiable parental consent before selling or sharing the child's PI. - For consumers 13-15 years old: Businesses must obtain opt-in consent from the consumer before selling or sharing their PI. - Businesses that willfully disregard the consumer's age must obtain affirmative authorization. - Notices to consumers under 16 must be written in a manner tailored to the age of the consumer (e.g., age-appropriate language for children). ### ADMT Requirements (Effective January 1, 2027) - Pre-use notice: provide a pre-use notice before using ADMT for a significant decision (and before repurposing previously collected PI for that ADMT use). The notice must describe the specific purpose, opt-out and access rights, and additional plain-language information about how the ADMT works and the alternative process if the consumer opts out (unless an exception applies). - Opt-out of ADMT: provide methods for consumers to submit opt-out requests, and do not require a verifiable consumer request to opt out. Some exceptions apply, including when the business provides a human appeal process that meets the requirements in the regulations. - Access ADMT: respond to requests to access ADMT with plain-language explanations of the specific purpose, the logic of the ADMT (including outputs/parameters as applicable), and the outcome of the decisionmaking process, plus required instructions and anti-retaliation information. Trade secrets and certain security-related information may be excluded. - Risk assessments: ADMT for significant decisions is a processing activity that triggers the risk assessment requirements in Article 10. ### Risk Assessment Requirements - Weigh benefits and risks: identify and weigh the benefits of the processing against the negative impacts to consumers' privacy, including sources and causes of those negative impacts, and identify safeguards to address them. - Document the processing activity: describe categories of PI (including any sensitive PI), the specific purpose, the method of collecting/using/disclosing/retaining, sources, retention periods (or criteria), interaction context, approximate number of consumers, disclosures, and recipients (service providers, contractors, third parties) and purposes. - Stakeholder involvement: include relevant employees whose job duties include participating in the covered processing, and the business may include external parties such as experts or consumers or stakeholder organizations. - Update timing: review and update as necessary at least once every three years, and update within 45 calendar days of a material change. - Retention: retain risk assessments (including original and updated versions) for as long as the processing continues or for five years after completion, whichever is later. - Agency submissions: submit required risk assessment information to the Agency on the timelines set out in section 7157, and be prepared to submit full risk assessment reports within 30 calendar days if requested by the Agency or the Attorney General. ### Cybersecurity Audit Requirements - Scope: assess how the cybersecurity program protects PI from unauthorized access, destruction, use, modification, or disclosure, and protects against unauthorized activity that results in loss of availability. - Thoroughness and independence: use a qualified, objective, independent professional auditor, and follow accepted procedures and standards in the auditing profession. The auditor may be internal or external but must remain objective and independent. - Audit report content: include detailed findings about gaps or weaknesses that increase risk, the plan and timeframe to address them, and required certifications and other required report components set out in the regulations. - Certification to the Agency: for each calendar year a business is required to complete a cybersecurity audit, submit a written certification of completion to the Agency no later than April 1 following any year that the business is required to complete a cybersecurity audit. - Retention: retain documents relevant to each cybersecurity audit for at least five years after completion. ### Training and Record-Keeping - Training: Businesses must train all persons responsible for handling consumer requests or responding to consumer inquiries about the business's privacy practices. Training must cover: the requirements of the CCPA; the business's privacy practices; how to direct consumers to exercise their rights; and how to respond to consumer requests. - Record-Keeping: Businesses must maintain records of consumer requests (including the date received, nature of the request, manner in which the request was submitted, date of the business's response, and the nature of the response). Records must be retained for at least 24 months. - Businesses collecting PI of 10 million or more consumers in a calendar year must compile metrics on consumer requests (number of requests received, complied with in whole or in part, denied, median and mean response times) and disclose these metrics in the Privacy Policy by July 1 each year. ### Enforcement and Penalties - Enforcement: The California Privacy Protection Agency (CPPA) and the California Attorney General can enforce the law. There is no general 30-day notice and cure requirement as of January 1, 2023. - Administrative Penalties: Civil penalties of up to $2,500 per violation, or $7,500 per intentional violation or violation involving minors' PI. - Private Right of Action: Consumers may sue businesses for data breaches involving certain categories of unencrypted or unredacted personal information (e.g., SSN, driver's license, financial account number, medical information, health insurance information, unique biometric data, email address + password or security question answer) if the breach results from the business's failure to implement and maintain reasonable security procedures and practices. Statutory damages of $100-$750 per consumer per incident, or actual damages, whichever is greater. - Complaints: Consumers may file complaints with the CPPA online or by mail. The CPPA does not represent individual consumers but uses complaints to identify trends and inform enforcement actions. ### Key Exemptions - HIPAA-covered entities and business associates (for protected health information). - Medical information governed by the Confidentiality of Medical Information Act. - Entities covered by the Gramm-Leach-Bliley Act (GLBA) for information collected, processed, sold, or disclosed pursuant to GLBA. - Entities covered by the Fair Credit Reporting Act (FCRA) for information collected, processed, sold, or disclosed pursuant to FCRA. - Entities covered by the Driver's Privacy Protection Act (for information governed by that Act). - Nonprofit organizations (as the CCPA applies only to for-profit businesses). - Government agencies (the CCPA does not apply to state or local government agencies). - Employee and B2B exemptions (Civil Code 1798.145(m)-(n)) expired on December 31, 2022. Employee data and B2B data are now covered by the CCPA. - De-identified or aggregate consumer information (if the business maintains reasonable security measures, prohibits re-identification, and makes no attempt to re-identify). ## Possible Outcomes ### [RESULT] Out of Scope CCPA does not directly apply - Your business is not subject to the CCPA because it either does not meet the definition of a 'business' or does not meet any of the threshold criteria. - Even if not directly in scope, you may still be subject to contractual requirements if you act as a service provider, contractor, or third party for a CCPA-covered business. ### [RESULT] CCPA Applies (Full Business Obligations) All CCPA requirements for businesses apply - Implement Notice at Collection and Privacy Policy. Provide methods for consumers to exercise their rights (know, delete, correct, opt out of sale/sharing, limit sensitive PI when applicable, and ADMT rights when applicable). Respond to consumer requests within required timelines. Verify identity where required. Honor authorized agents. - If you sell or share PI: provide 'Do Not Sell or Share My Personal Information' link and honor opt-out preference signals. If you use sensitive PI beyond permitted purposes: provide 'Limit the Use of My Sensitive Personal Information' link. - Maintain contracts with service providers, contractors, and third parties. Train employees responsible for handling consumer requests. Maintain records of consumer requests for at least 24 months. - Additional obligations may apply: data broker registration (if applicable), ADMT requirements (if using ADMT for significant decisions), risk assessments (if you perform any processing activities listed in 11 CCR 7150(b)), cybersecurity audits (if you meet the criteria in 11 CCR 7120(b)), and rules for consumers under 16 (opt-in for sale/sharing when applicable). ### [RESULT] Service Provider / Contractor Obligations Contractual and operational requirements apply - Ensure written contracts with businesses include all required CCPA provisions: prohibition on selling or sharing PI (unless authorized), prohibition on retention/use/disclosure of PI for unauthorized purposes, prohibition on combining PI with information from other sources (except as permitted), right for businesses to ensure compliance, notification to businesses if unable to meet CCPA obligations, and third-party beneficiary rights for consumers. - Assist businesses with responding to consumer requests (to the extent you maintain the responsive information). Maintain reasonable security procedures and practices to protect personal information. - You may be directly liable for CCPA violations if you fail to comply with your contractual obligations (e.g., if you sell or share PI received from a business without authorization). ### [RESULT] Third Party Obligations Use restrictions and notice requirements apply - Use personal information received from a business only for the specific purpose disclosed in the business's Privacy Policy or Notice at Collection (or as otherwise permitted by the CCPA). - Do not sell or share PI received from a business unless the consumer has received explicit notice and an opportunity to opt-out of further sales or shares. - Maintain reasonable security procedures and practices to protect personal information. ### [RESULT] Data Broker Registration Required Annual registration with CPPA + all business obligations - Register with the CPPA annually by January 31 and pay the registration fee. Provide required information (business name, address, website, contact, data collection practices, consumer rights link). - Disclose consumer request metrics on your website privacy policy by July 1 each year (and report during registration): number of requests received (delete, know, opt-out, limit), compliance rate, and median/mean response times. - The CPPA must establish an accessible deletion mechanism by January 1, 2026. Beginning August 1, 2026, data brokers must access it at least once every 45 days and process consumer deletion requests, subject to limited exceptions. - All CCPA business obligations apply (Privacy Policy, Notice at Collection, Consumer Rights, Do Not Sell or Share link, Limit link if applicable, Verification, Contracts, Training, Record-keeping). ### [RESULT] ADMT Requirements Do Not Apply Focus on other CCPA obligations - You do not use ADMT for significant decisions, so ADMT-specific consumer rights and pre-use notice requirements do not apply. - You must still comply with all other applicable CCPA requirements for businesses, including: Notice at Collection, Privacy Policy, Consumer Rights, Opt-out and Limit links (if applicable), Verification, Contracts, Training, and Record-keeping. - Risk assessments may still be required if you perform any processing activities listed in 11 CCR 7150(b), including selling or sharing personal information or processing sensitive personal information. ### [RESULT] ADMT Requirements Apply (Compliance Deadline: January 1, 2027) Pre-use notice, opt-out, access, and risk assessment required - Provide a pre-use notice before using ADMT for a significant decision (including required information about the purpose, opt-out and access rights, and how the ADMT works and the alternative process if the consumer opts out, unless an exception applies). - Provide consumers with the right to opt out of ADMT (subject to exceptions) and comply with opt-out requests within required timelines. Provide consumers with the right to access ADMT and respond with the required plain-language explanations and instructions. - Conduct a risk assessment as required by 11 CCR 7150 et seq. Submit required risk assessment information to the Agency by the applicable deadlines, and be prepared to provide full reports if requested. - All other CCPA business obligations apply (Privacy Policy, Notice at Collection, Consumer Rights, Opt-out and Limit links if applicable, Verification, Contracts, Training, Record-keeping). ### [RESULT] Cybersecurity Audit Required Annual audit and certification to CPPA - Complete a cybersecurity audit if you meet the criteria in 11 CCR 7120(b). Meet the phased first-report deadlines in 11 CCR 7121(a), and follow the annual timing in 11 CCR 7121(b) after April 1, 2030. - Ensure the audit meets the thoroughness and independence requirements, and that the audit report includes the required content (including required certifications) under the regulations. - Submit the required certification of completion to the Agency no later than April 1 following any year that you are required to complete a cybersecurity audit. - Retain documents relevant to each cybersecurity audit for at least five years after completion. ## CCPA Timeline | Date | Event | Reference | | --- | --- | --- | | 2020-01-01 | CCPA becomes operative (January 1, 2020) | Civil Code 1798.198 (operative date) | | 2020-07-01 | CCPA enforcement begins (July 1, 2020) | California Attorney General enforcement materials | | 2020-11-03 | California Privacy Rights Act (CPRA - Proposition 24) approved by voters | Proposition 24 | | 2022-12-31 | Employee and B2B exemptions expire | CPPA FAQ timeline | | 2023-01-01 | CPRA amendments take effect (January 1, 2023) | CPPA FAQ timeline | | 2023-07-01 | CPRA civil and administrative enforcement begins | Proposition 24 (enforcement start) | | 2023-10-10 | Delete Act (SB 362) approved by the Governor | SB 362 (Delete Act) | | 2024-01-01 | CPPA takes over Data Broker Registry from Attorney General | SB 362 (Delete Act) and CPPA FAQ timeline | | 2026-01-01 | CCPA regulations effective (Title 11, Division 6, Chapter 1) | CCPA Regulations effective date | | 2026-08-01 | Data brokers begin required use of the accessible deletion mechanism (at least once every 45 days) | SB 362 (Delete Act) | | 2027-01-01 | ADMT (Automated Decisionmaking Technology) compliance deadline | 11 CCR 7200(b) | ## Compliance Timeline | Date | Event | Category | Reference | | --- | --- | --- | --- | | 2019-01-01 | CCPA added by AB 375 takes effect (January 1, 2019) | Legislation | | | 2020-01-01 | CCPA title becomes operative (January 1, 2020) | Legislation | | | 2020-01-16 | NIST Privacy Framework 1.0 published | Technical Standards | | | 2020-07-01 | Attorney General regulation adoption deadline (July 1, 2020) | Regulations | | | 2020-07-01 | CCPA enforcement begins (July 1, 2020) | Enforcement | | | 2020-08-14 | DOJ initial CCPA regulations promulgated (August 14, 2020) | Regulations | | | 2020-11-03 | Proposition 24 (CPRA) approved by voters | Legislation | | | 2021-03-15 | DOJ CCPA regulations amended (March 15, 2021) | Regulations | | | 2021-07-01 | Rulemaking authority transfers to CPPA (July 1, 2021) | Agency | | | 2022-01-01 | CPRA lookback applies to PI collected on or after January 1, 2022 | Legislation | | | 2022-07-01 | CPRA final regulations adoption deadline (July 1, 2022) | Regulations | | | 2022-07-08 | CPPA commences formal rulemaking (July 8, 2022) | Agency | | | 2022-08-24 | Sephora settlement announced | Enforcement | | | 2022-12-31 | Employee and B2B exemptions expire (December 31, 2022) | Legislation | | | 2023-01-01 | CPRA amendments take effect (January 1, 2023) | Legislation | | | 2023-01-01 | Notice and cure requirement ends (January 1, 2023) | Enforcement | | | 2023-03-29 | CPPA regulations approved by OAL and effective (March 29, 2023) | Regulations | | | 2023-07-01 | CPRA civil and administrative enforcement begins | Enforcement | | | 2023-10-10 | Delete Act (SB 362) signed into law | Data Brokers | | | 2024-01-01 | CPPA takes over Data Broker Registry management (January 1, 2024) | Data Brokers | | | 2024-03-08 | Draft risk assessment regulations published | Regulations | | | 2024-11-22 | Public notice of cybersecurity, risk, and ADMT rulemaking | Regulations | | | 2025-01-13 | Comment period extension notice published | Regulations | | | 2025-02-19 | Public comment hearing held | Regulations | | | 2025-07-24 | CPPA Board adopts cybersecurity, risk, and ADMT regulations | Regulations | | | 2025-09-22 | Final rulemaking documents published | Regulations | | | 2026-01-01 | CCPA regulations compilation effective (January 1, 2026) | Regulations | | | 2026-01-01 | Deletion mechanism deadline and DROP registration window opens | Data Brokers | | | 2026-01-31 | Data broker registration deadline (January 31, 2026) | Data Brokers | | | 2026-07-01 | Data broker metrics disclosure deadline (July 1, 2026) | Data Brokers | | | 2026-08-01 | Data brokers must use the deletion mechanism (August 1, 2026) | Data Brokers | | | 2027-01-01 | ADMT significant decision compliance deadline (January 1, 2027) | Regulations | | | 2027-12-31 | Risk assessment deadline for pre-2026 processing (December 31, 2027) | Regulations | | | 2028-01-01 | Data broker audits required (January 1, 2028) | Data Brokers | | | 2028-04-01 | First cybersecurity audit report deadline example (April 1, 2028) | Regulations | | | 2029-01-01 | Data broker audit disclosure requirement begins (January 1, 2029) | Data Brokers | | **Event details:** - **2019-01-01 - CCPA added by AB 375 takes effect (January 1, 2019)**: Legislative history for the CCPA title notes it was added by Stats. 2018, Ch. 55, Sec. 3 (AB 375) and became effective January 1, 2019. - **2020-01-01 - CCPA title becomes operative (January 1, 2020)**: Civil Code Title 1.81.5 (CCPA) is stated as operative January 1, 2020 (pursuant to Section 1798.198) in the code section group grounding materials. - **2020-01-16 - NIST Privacy Framework 1.0 published**: NIST Privacy Framework v1.0 publication date shown as January 16, 2020 in the NIST Privacy Framework PDF. - **2020-07-01 - Attorney General regulation adoption deadline (July 1, 2020)**: Proposition 24 ballot text and Civil Code legislative materials reference July 1, 2020 as a deadline for the Attorney General to solicit participation and adopt regulations for the CCPA. - **2020-07-01 - CCPA enforcement begins (July 1, 2020)**: California Office of the Attorney General enforcement materials state CCPA enforcement began on July 1, 2020. - **2020-08-14 - DOJ initial CCPA regulations promulgated (August 14, 2020)**: California Office of the Attorney General CCPA materials state the California Department of Justice promulgated an initial round of regulations implementing the CCPA on August 14, 2020. - **2020-11-03 - Proposition 24 (CPRA) approved by voters**: Proposition 24 ballot text references approval by voters at the November 3, 2020 statewide general election and includes the CPRA enforcement commencement date. - **2021-03-15 - DOJ CCPA regulations amended (March 15, 2021)**: California Office of the Attorney General CCPA materials state the initial regulations were further amended on March 15, 2021. - **2021-07-01 - Rulemaking authority transfers to CPPA (July 1, 2021)**: Civil Code legislative materials and Proposition 24 text describe the transfer of regulation adoption authority from the Attorney General to the California Privacy Protection Agency beginning July 1, 2021 (subject to conditions described in the statute). - **2022-01-01 - CPRA lookback applies to PI collected on or after January 1, 2022**: Proposition 24 ballot text states that a consumer right to request information beyond the 12-month period and the related business obligation only apply to personal information collected on or after January 1, 2022. - **2022-07-01 - CPRA final regulations adoption deadline (July 1, 2022)**: Proposition 24 ballot text describes July 1, 2022 as the timeline for adopting final regulations required by the CPRA amendments. - **2022-07-08 - CPPA commences formal rulemaking (July 8, 2022)**: CPPA consumer privacy act page timeline states the Agency commenced formal rulemaking to adopt CPRA implementing regulations on July 8, 2022. - **2022-08-24 - Sephora settlement announced**: California Attorney General press release date for the Sephora CCPA settlement is August 24, 2022. - **2022-12-31 - Employee and B2B exemptions expire (December 31, 2022)**: California Office of the Attorney General and CPPA materials state the employment-related and B2B exemptions described in Civil Code Section 1798.145(m)-(n) expired on December 31, 2022. - **2023-01-01 - CPRA amendments take effect (January 1, 2023)**: CPPA FAQs and Office of the Attorney General materials state the CPRA amendments to the CCPA went into effect on January 1, 2023. - **2023-01-01 - Notice and cure requirement ends (January 1, 2023)**: California Office of the Attorney General enforcement materials state that, as of January 1, 2023, the CCPA no longer requires notice of a violation or an opportunity to cure before filing an enforcement action. - **2023-03-29 - CPPA regulations approved by OAL and effective (March 29, 2023)**: CPPA consumer privacy act page timeline states that on March 29, 2023 the Office of Administrative Law approved the CPPA regulations and filed them with the Secretary of State, and the regulations became effective on March 29, 2023. - **2023-07-01 - CPRA civil and administrative enforcement begins**: Proposition 24 ballot text states civil and administrative enforcement of the CPRA-added or amended provisions does not commence until July 1, 2023 and applies only to violations occurring on or after that date. - **2023-10-10 - Delete Act (SB 362) signed into law**: California legislative materials for SB 362 state the bill was approved by the Governor on October 10, 2023. - **2024-01-01 - CPPA takes over Data Broker Registry management (January 1, 2024)**: CPPA FAQs timeline states that beginning on January 1, 2024 the Agency will take over management of the Data Broker Registry. - **2024-03-08 - Draft risk assessment regulations published**: CPPA publishes draft risk assessment regulations dated March 8, 2024. - **2024-11-22 - Public notice of cybersecurity, risk, and ADMT rulemaking**: CPPA updates page timeline lists a public notice of rulemaking and related documents dated November 22, 2024. - **2025-01-13 - Comment period extension notice published**: CPPA updates page timeline lists a public notice extending the comment period dated January 13, 2025. - **2025-02-19 - Public comment hearing held**: CPPA updates page timeline references a public comment hearing on February 19, 2025 for the cybersecurity, risk, and ADMT rulemaking. - **2025-07-24 - CPPA Board adopts cybersecurity, risk, and ADMT regulations**: CPPA updates page timeline states the CPPA Board adopted regulations on July 24, 2025 covering updates to existing CCPA regulations, risk assessments, annual cybersecurity audits, ADMT rights, and insurance company clarifications. - **2025-09-22 - Final rulemaking documents published**: CPPA updates page timeline lists final rulemaking documents dated September 22, 2025. - **2026-01-01 - CCPA regulations compilation effective (January 1, 2026)**: CPPA regulations compilation PDF indicates an effective date of January 1, 2026. - **2026-01-01 - Deletion mechanism deadline and DROP registration window opens**: CPPA FAQs and CPPA DROP materials describe a deadline to establish a single deletion mechanism by January 1, 2026 and describe a January 1 to January 31, 2026 registration and fee window for data brokers through DROP. - **2026-01-31 - Data broker registration deadline (January 31, 2026)**: CPPA DROP materials state data brokers must register and pay the annual fee between January 1 and January 31, 2026 through DROP, and note consequences for missing the deadline. - **2026-07-01 - Data broker metrics disclosure deadline (July 1, 2026)**: CPPA DROP materials state data brokers must disclose specified request metrics by July 1 (and that these disclosures are part of annual requirements). - **2026-08-01 - Data brokers must use the deletion mechanism (August 1, 2026)**: SB 362 and CPPA DROP materials state that beginning August 1, 2026 data brokers must access the accessible deletion mechanism at least once every 45 days and process consumer deletion requests, subject to exceptions. - **2027-01-01 - ADMT significant decision compliance deadline (January 1, 2027)**: CCPA regulations compilation timeline includes a compliance date stating a business that uses ADMT for a significant decision must be in compliance with Article 11 requirements no later than January 1, 2027. - **2027-12-31 - Risk assessment deadline for pre-2026 processing (December 31, 2027)**: CCPA regulations compilation timeline includes a deadline stating that for processing initiated prior to January 1, 2026 and continuing after that date, the business must conduct and document a risk assessment no later than December 31, 2027. - **2028-01-01 - Data broker audits required (January 1, 2028)**: SB 362 and CPPA DROP materials state that beginning January 1, 2028 and every three years thereafter, data brokers must undergo an independent third-party audit to determine compliance and must submit the audit report to the Agency upon written request. - **2028-04-01 - First cybersecurity audit report deadline example (April 1, 2028)**: CCPA regulations compilation timeline includes an April 1, 2028 deadline for completing a first cybersecurity audit report for certain high revenue businesses (as described in the regulations timeline examples). - **2029-01-01 - Data broker audit disclosure requirement begins (January 1, 2029)**: SB 362 and CPPA DROP materials state that beginning January 1, 2029 data brokers registering with the Agency must disclose whether they have undergone a required audit and, if so, the most recent year of submission to the Agency. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/california-consumer-privacy-act --- --- title: "Australia Cyber Security Act 2024 Applicability Test" canonical_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/applicability-test" source_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/applicability-test" author: "Sorena AI" description: "Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "Australia Cyber Security Act 2024 applicability test" - "who does the Australia Cyber Security Act 2024 apply to" - "Cyber Security Act 2024 scope" - "smart device rules Australia scope" - "ransomware payment reporting Australia" - "reporting business entity" - "$3 million turnover threshold" - "consumer grade relevant connectable product" - "internet connectable product" - "network connectable product" - "SOCI Act critical infrastructure" - "excluded products Australia Cyber Security Act 2024" - "Cyber Security Act 2024 exemptions" - "smart device manufacturer obligations Australia" - "supplier obligations Australia Cyber Security Act 2024" - "Part 2 smart device applicability" - "Part 3 ransomware reporting applicability" - "Australia Cyber Security Act 2024" - "Cyber Security Act 2024 applicability test" - "smart device security standards Australia" - "internet connectable product definition" - "reporting business entity Australia" - "APAC cyber compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Australia Cyber Security Act 2024 Applicability Test Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations. *Artifact Guide* *APAC* ## Australia Cyber Security Act 2024 Applicability Test: Who Must Comply Use this detailed Australia Cyber Security Act 2024 applicability test to determine whether your organisation must comply with the smart device security standards under Part 2, the ransomware payment reporting obligations under Part 3, or both. Walk through each threshold question with exact statutory references, excluded product categories, turnover calculations, and SOCI Act interaction points. Record your conclusion as a dated decision memo. The Australia Cyber Security Act 2024 (No. 98, 2024) creates two separate compliance workstreams that apply to different types of organisations. Part 2 of the Australia Cyber Security Act 2024 imposes mandatory security standards on manufacturers and suppliers of consumer grade relevant connectable products that will be acquired in Australia. Part 3 of the Australia Cyber Security Act 2024 imposes a mandatory ransomware payment reporting obligation on reporting business entities that make, authorise, or become aware of ransomware payments following a cyber security incident. These two workstreams operate independently. A manufacturer of smart home devices may be fully in scope for Part 2 without ever triggering Part 3. A large financial services firm may be a reporting business entity under Part 3 without supplying any connectable product. Compliance professionals should treat each workstream as a separate applicability test, document the reasoning for each conclusion, and revisit the analysis whenever the organisation launches a new product line, enters a new market, or experiences a cyber security incident. ## How to use this Australia Cyber Security Act 2024 applicability test Do not ask whether your business is generally in scope for the Australia Cyber Security Act 2024. Instead, ask which part of the Australia Cyber Security Act 2024 applies to which specific activity. A manufacturer may be in scope for the smart device rules under Part 2 without ever triggering the ransomware payment reporting obligation under Part 3. Conversely, a large operating company may trigger the Part 3 ransomware reporting duty without supplying any smart device product. Treat these as two distinct applicability questions. Your output from this applicability test should be a dated decision note that names the legal entity being assessed, the specific product line or incident scenario under review, the source provisions of the Australia Cyber Security Act 2024 that were considered, and the conclusion reached. This note becomes part of your compliance evidence pack and should be signed off by a responsible officer. Revisit this applicability test whenever your organisation changes its product portfolio, begins importing or distributing new product categories into Australia, crosses the $3 million annual turnover threshold, acquires or becomes responsible for a critical infrastructure asset, or experiences a cyber security incident involving a ransomware demand. - Test product scope under Part 2 and ransomware reporting scope under Part 3 as two separate exercises. - Record the exact legal entity name, ABN, and business activity being assessed in your decision note. - Cite the specific section numbers of the Australia Cyber Security Act 2024 and the applicable 2025 Rules that support your conclusion. - Repeat the applicability test when a new product class, market channel, corporate acquisition, or incident scenario arises. - Store the completed decision note alongside your compliance evidence pack and review it at least annually. - If the applicability conclusion is borderline, document the conservative interpretation and seek legal advice before relying on an exclusion. *Recommended next step* *Placement: after the applicability result* ## Turn Australia Cyber Security Act 2024 Applicability Test: Who Must Comply into an operational assessment Assessment Autopilot can take Australia Cyber Security Act 2024 Applicability Test: Who Must Comply from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on Australia Cyber Security Act 2024 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Australia Cyber Security Act 2024 Applicability Test: Who Must Comply](/solutions/assessment.md): Start from Australia Cyber Security Act 2024 Applicability Test: Who Must Comply and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Australia Cyber Security Act 2024](/contact.md): Review your current process, evidence gaps, and next steps for Australia Cyber Security Act 2024 Applicability Test: Who Must Comply. ## Test 1: Does Part 2 of the Australia Cyber Security Act 2024 apply to your product? Part 2 of the Australia Cyber Security Act 2024 commenced on 29 November 2025. The Cyber Security (Security Standards for Smart Devices) Rules 2025 were registered on 4 March 2025, and the substantive obligations in Part 2 and Schedule 1 of those Rules commenced on 4 March 2026. From that date, manufacturers and suppliers of in scope products must comply with the security standard and the statement of compliance requirements. The starting point is the definition of a relevant connectable product in section 13 of the Australia Cyber Security Act 2024. A relevant connectable product is a product that is either an internet connectable product or a network connectable product, and that is not exempted under the rules. An internet connectable product under section 13(4) is a product that is capable of connecting to the internet using a communication protocol that forms part of the internet protocol suite to send and receive data over the internet. A network connectable product under section 13(5) is a product that can send and receive data by means of electrical or electromagnetic energy, is not itself an internet connectable product, but is capable of connecting directly to an internet connectable product using the internet protocol suite, or is capable of connecting directly to two or more products simultaneously using a non internet protocol suite protocol and is also capable of connecting directly to an internet connectable product. Once you have established that your product is a relevant connectable product, you must then check whether it falls within the consumer grade class defined in section 8 of the Smart Devices Rules 2025. This class covers all relevant connectable products that are intended by the manufacturer to be used, or are of a kind likely to be used, for personal, domestic, or household use or consumption, and that will be acquired in Australia by a consumer as defined by section 3 of the Australian Consumer Law. Part 2 of the Australia Cyber Security Act 2024 applies only to relevant connectable products that are manufactured on or after the commencement of Part 2, or supplied other than as second hand goods on or after that commencement date. Products that were both manufactured and sold before the commencement date are not captured. However, if a product was manufactured before commencement but is being supplied as new goods after commencement, Part 2 applies to that supply. - Step 1: Determine whether the product can connect to the internet using the internet protocol suite (section 13(4) internet connectable product). - Step 2: If the product is not directly internet connectable, determine whether it can connect to an internet connectable product using the internet protocol suite, or meets the two or more device bridge conditions in section 13(7) (network connectable product). - Step 3: Confirm the product is not exempted under the rules. Currently no general exemptions have been made under section 13(2)(b). - Step 4: Confirm the product is intended for, or likely to be used for, personal, domestic, or household use or consumption (consumer grade class under section 8 of the Smart Devices Rules 2025). - Step 5: Confirm the product is not in one of the six excluded categories: desktop computers, laptops, tablet computers, smartphones, therapeutic goods under the Therapeutic Goods Act 1989, or road vehicles and road vehicle components under the Road Vehicle Standards Act 2018. - Step 6: Confirm the product will be acquired in Australia by a consumer (section 3 of the Australian Consumer Law). - Step 7: Confirm the manufacturer or supplier is aware, or could reasonably be expected to be aware, of that Australian consumer acquisition context. ## Excluded product categories under the Australia Cyber Security Act 2024 smart device rules Section 8 of the Cyber Security (Security Standards for Smart Devices) Rules 2025 explicitly excludes six product categories from the consumer grade class for the purposes of the security standard. Understanding these exclusions is important because they narrow the scope of the Australia Cyber Security Act 2024 Part 2 obligations. The exclusions are: (i) a desktop computer or a laptop, (ii) a tablet computer, (iii) a smartphone, (iv) therapeutic goods within the meaning of the Therapeutic Goods Act 1989, (v) a road vehicle within the meaning of the Road Vehicle Standards Act 2018, and (vi) a road vehicle component within the meaning of the Road Vehicle Standards Act 2018. These exclusions exist because these product categories are already subject to other regulatory frameworks. Smartphones, tablets, laptops, and desktop computers are addressed by established industry security practices and other regulatory expectations. Therapeutic goods are regulated by the Therapeutic Goods Administration under the Therapeutic Goods Act 1989, which already includes cybersecurity considerations in its conformity assessment procedures. Road vehicles and their components are regulated under the Road Vehicle Standards Act 2018 and associated standards, including emerging cybersecurity requirements under UN Regulation No. 155. The exclusion list does not cover accessories or peripherals that connect to excluded devices. For example, a smart keyboard that connects via Bluetooth to a tablet may still qualify as a network connectable product if it meets the conditions in section 13(5) to (9) of the Australia Cyber Security Act 2024. Similarly, a smart health monitoring wristband is not automatically excluded just because it pairs with a smartphone. The wristband itself is assessed on its own characteristics against the relevant connectable product definition. If you rely on an exclusion to take a product out of scope, document the specific exclusion category, the product characteristics that place it within that category, and the regulatory reference. The exclusion list in the Rules may be expanded or narrowed in future amendments, so monitor the Federal Register of Legislation for updates to the Cyber Security (Security Standards for Smart Devices) Rules 2025. - Desktop computers and laptops are excluded from the consumer grade class regardless of whether they have consumer or enterprise market positioning. - Tablet computers are excluded. However, a device marketed as a smart home hub that uses a tablet form factor may not qualify for the tablet exclusion if it is not a general purpose tablet computer. - Smartphones are excluded. Devices that have cellular connectivity but are not smartphones, such as smart watches with cellular modems, are not covered by this exclusion. - Therapeutic goods are excluded only if they fall within the meaning of the Therapeutic Goods Act 1989. Consumer wellness devices that are not classified as therapeutic goods remain in scope. - Road vehicles and road vehicle components are excluded only if they meet the definitions in the Road Vehicle Standards Act 2018. Aftermarket accessories that are not road vehicle components may remain in scope. - Document your reliance on any exclusion in your applicability decision note and include the specific statutory basis. ## Understanding internet connectable products and network connectable products The Australia Cyber Security Act 2024 uses two separate definitions to capture the full range of devices that can directly or indirectly reach the internet. Under section 13(4), an internet connectable product is one that is capable of connecting to the internet using a communication protocol that forms part of the internet protocol suite to send and receive data over the internet. In practical terms, this covers any device with a Wi-Fi adapter, an Ethernet port, or a cellular modem that uses TCP/IP or UDP/IP to communicate over the internet. Common examples include smart speakers, smart TVs, IP cameras, smart thermostats, smart lighting hubs, and connected home appliances. Under section 13(5), a network connectable product is a product that can send and receive data by means of electrical or electromagnetic energy, is not itself an internet connectable product, but meets one of two connection conditions. The first condition (section 13(6)) is that the product is capable of connecting directly to an internet connectable product using the internet protocol suite. The second condition (section 13(7)) is that the product is capable of connecting directly to two or more products simultaneously using a non internet protocol suite protocol (such as Bluetooth or Zigbee), and is also capable of connecting directly to an internet connectable product using such a protocol. Section 13(8) provides a carve out for simple wires or cables used merely to connect one product to another. Section 13(9) addresses input peripherals designed to be used together with a computer: if one device in a set (the linking product) connects to an internet connectable product via a non internet protocol suite protocol, and the other devices (input products) connect wirelessly to the linking product via a non internet protocol suite protocol, then the input products also meet the network connectable product condition. When assessing whether a product is an internet connectable product or a network connectable product under the Australia Cyber Security Act 2024, focus on the product's capabilities at the time of supply, not on whether the consumer chooses to connect the product. A smart device that ships with Wi-Fi capability is an internet connectable product even if a particular consumer never connects it to a Wi-Fi network. - Internet connectable products: devices with Wi-Fi, Ethernet, or cellular connectivity that use internet protocol suite protocols (TCP/IP, UDP/IP) to send and receive data over the internet. - Network connectable products: devices that do not connect directly to the internet but can reach it indirectly through another device, for example a Bluetooth sensor that connects to a Wi-Fi enabled hub. - Simple wires and cables used only to connect one product to another are carved out by section 13(8). - Assess connectivity capabilities at the time of supply, not based on whether the end user chooses to activate the connection. - Combination products that include both hardware and companion software or cloud services should be assessed as a whole, covering the full intended use case. ## Who must comply: manufacturers and suppliers under Part 2 of the Australia Cyber Security Act 2024 Part 2 of the Australia Cyber Security Act 2024 places obligations on two categories of entity: manufacturers and suppliers. Under section 15(1), a manufacturer must manufacture a relevant connectable product in compliance with the security standard if the product is included in the specified class and the manufacturer is aware, or could reasonably be expected to be aware, that the product will be acquired in Australia by a consumer. Under section 15(2), the manufacturer must also comply with any other requirements of the security standard, such as publishing a vulnerability disclosure contact point and a defined support period for security updates. Under section 15(3), a supplier must not supply a product in Australia that was not manufactured in compliance with the security standard, if the product is included in the specified class and the supplier is aware, or could reasonably be expected to be aware, that the product will be acquired in Australia by a consumer. The term 'supplier' has the same meaning as in the Australian Consumer Law, which covers any entity that supplies goods in trade or commerce, including distributors, importers, and retailers. Under section 16 of the Australia Cyber Security Act 2024, manufacturers must provide a statement of compliance for each relevant connectable product, and suppliers must supply the product accompanied by that statement of compliance. Both manufacturers and suppliers must retain a copy of the statement of compliance for 5 years, as specified in section 10 of the Smart Devices Rules 2025. The statement must include the product type and batch identifier, the manufacturer name and address, an authorised representative in Australia, a declaration of compliance, the defined support period, and the signature of an authorised signatory. The 'manufacturer' definition follows the Australian Consumer Law, which means it can include the entity whose brand appears on the product, the entity that holds itself out as the manufacturer, or the entity that actually manufactures the product. The 'aware or could reasonably be expected to be aware' knowledge threshold means that a manufacturer or supplier cannot avoid obligations simply by claiming ignorance of the Australian market if the product is available through Australian retail channels or online marketplaces that serve Australian consumers. - Manufacturers must comply with the security standard requirements in Schedule 1 of the Smart Devices Rules 2025 (passwords, vulnerability disclosure, defined support period). - Manufacturers must provide a statement of compliance for each in scope product and retain a copy for 5 years. - Suppliers must not supply non compliant products in Australia and must supply each product accompanied by the statement of compliance. - Suppliers include distributors, importers, wholesalers, and retailers under the Australian Consumer Law definition. - The knowledge threshold is 'aware or could reasonably be expected to be aware' that the product will be acquired in Australia by a consumer. - If your brand appears on a product sold in Australia and the product connects to the internet, you should assume the Australia Cyber Security Act 2024 Part 2 obligations apply to you unless a specific exclusion is documented. ## Test 2: Does Part 3 ransomware payment reporting under the Australia Cyber Security Act 2024 apply to your organisation? Part 3 of the Australia Cyber Security Act 2024 commenced on 29 May 2025. The Cyber Security (Ransomware Payment Reporting) Rules 2025 were registered on 3 March 2025 and commenced at the same time as Part 3. From that date, any reporting business entity that makes a ransomware payment, or becomes aware that a ransomware payment has been made on its behalf, must report the payment to the designated Commonwealth body within 72 hours. The reporting duty under section 26 of the Australia Cyber Security Act 2024 only arises when all of the following elements exist together: (a) an incident has occurred, is occurring, or is imminent, (b) the incident is a cyber security incident as defined in section 9 of the Act, (c) the incident has had, is having, or could reasonably be expected to have a direct or indirect impact on a reporting business entity, (d) an extorting entity makes a demand in order to benefit from the incident or its impact, and (e) the reporting business entity provides, or is aware that another entity has provided on its behalf, a ransomware payment to the extorting entity that is directly related to the demand. Under section 26(2) of the Australia Cyber Security Act 2024, an entity is a reporting business entity if, at the time the ransomware payment is made, it either: (a) is carrying on a business in Australia with an annual turnover for the previous financial year that exceeds the $3 million turnover threshold, is not a Commonwealth body or State body, and is not a responsible entity for a critical infrastructure asset, or (b) is a responsible entity for a critical infrastructure asset to which Part 2B of the Security of Critical Infrastructure Act 2018 applies. These two routes into reporting business entity status are mutually exclusive in the statute: route (a) expressly excludes critical infrastructure responsible entities, because route (b) captures them separately. The $3 million turnover threshold is set by section 6 of the Ransomware Payment Reporting Rules 2025. If the business has been carried on for only part of the previous financial year, the threshold is calculated on a pro rata basis using the formula: $3 million multiplied by the number of days the business was carried on in the previous financial year, divided by the total number of days in that financial year. This means a business that started operating on 1 January of a financial year (approximately 181 days into the year) would have a pro rata threshold of approximately $1.51 million for that partial year. Annual turnover is determined in accordance with the Income Tax Assessment Act 1997 definition of business. - Step 1: Confirm that a ransomware payment was made by your entity, or that your entity became aware that a payment was made on its behalf by another entity (including an insurer, adviser, or incident response firm). - Step 2: Confirm the event qualifies as a cyber security incident under section 9 of the Australia Cyber Security Act 2024. - Step 3: Determine whether your entity is a responsible entity for a critical infrastructure asset to which Part 2B of the Security of Critical Infrastructure Act 2018 applies. If yes, your entity is a reporting business entity under route (b). - Step 4: If your entity is not a critical infrastructure responsible entity, determine whether it carries on business in Australia and had annual turnover exceeding $3 million in the previous financial year (or the pro rata equivalent for a partial year). - Step 5: Confirm your entity is not a Commonwealth body or State body, which are excluded from the turnover route under section 26(2)(a)(ii). - Step 6: Start the 72 hour reporting timer from the time the ransomware payment was made, or from the time your entity became aware the payment was made on its behalf, whichever is applicable. - Step 7: Preserve all evidence supporting your applicability decision, including turnover calculations, even if the conclusion is that no report is required. ## The $3 million annual turnover threshold for ransomware payment reporting The $3 million annual turnover threshold is the primary gateway for private sector organisations into the ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. Section 6(1) of the Cyber Security (Ransomware Payment Reporting) Rules 2025 sets the turnover threshold at $3 million for the previous financial year. The concept of annual turnover follows the meaning of 'business' in the Income Tax Assessment Act 1997, which means you should use the same turnover figure that appears in your tax reporting. For businesses that have been carried on for only part of the previous financial year, section 6(2) of the Rules prescribes a pro rata formula. The threshold for a partial year equals $3 million multiplied by the number of days in the part of the previous financial year during which the business was carried on, divided by the number of days in the previous financial year. This prevents a newly established business from avoiding the reporting obligation simply because it has not yet completed a full financial year. For example, a business that commenced on 1 October and ended its first financial year on 30 June (273 days of operation out of 365 days) would have a threshold of approximately $2.24 million. When assessing turnover, count the aggregate annual turnover of the entity that is the reporting business entity under the Australia Cyber Security Act 2024. If your organisation operates through a corporate group structure, the turnover test applies to the specific entity that made or authorised the ransomware payment, not to the consolidated group revenue. However, if the entity is a partnership or trust, the turnover of the business carried on by the partnership or trust is the relevant figure. Note that the $3 million threshold is assessed at the time the ransomware payment is made, using the turnover for the previous financial year. If your turnover has fluctuated near the threshold, you should check whether the entity exceeded $3 million in the financial year immediately before the payment was made, not the current financial year. Keep auditable records of your turnover calculations and the financial year to which they relate. - The threshold is $3 million annual turnover for the previous financial year (section 6(1) of the Ransomware Payment Reporting Rules 2025). - For a partial year, use the pro rata formula: $3M x (days of operation / days in the financial year) (section 6(2)). - Turnover follows the Income Tax Assessment Act 1997 definition and should match your tax reporting figures. - Assess turnover for the entity that made or authorised the payment, not the consolidated corporate group. - The assessment point is the time the ransomware payment is made, using the previous financial year's turnover. - Keep auditable records of your turnover calculations so you can demonstrate whether the threshold was or was not exceeded. ## SOCI Act interaction and critical infrastructure obligations under the Australia Cyber Security Act 2024 The Australia Cyber Security Act 2024 deliberately interfaces with the Security of Critical Infrastructure Act 2018 (the SOCI Act) in two significant ways. First, the definition of 'cyber security incident' in section 9 of the Australia Cyber Security Act 2024 draws on the meaning of that term in the SOCI Act, covering acts, events, or circumstances of a kind covered by the SOCI Act definition, as well as unauthorised impairment of electronic communication to or from a computer. This means the same incident may trigger obligations under both the SOCI Act and the Australia Cyber Security Act 2024. Second, the reporting business entity definition in section 26(2)(b) of the Australia Cyber Security Act 2024 provides a separate route into scope for entities that are responsible entities for critical infrastructure assets to which Part 2B of the SOCI Act applies. Part 2B of the SOCI Act covers cyber security obligations for critical infrastructure assets, including the requirement to adopt and maintain a critical infrastructure risk management program and to report cyber security incidents to the Australian Signals Directorate. If your entity is a responsible entity under the SOCI Act and Part 2B applies to your critical infrastructure asset, you are automatically a reporting business entity under the Australia Cyber Security Act 2024 for the purposes of ransomware payment reporting, regardless of your turnover. This means critical infrastructure operators may face dual reporting obligations following a ransomware incident: a cyber security incident report to the Australian Signals Directorate under the SOCI Act, and a ransomware payment report to the designated Commonwealth body under Part 3 of the Australia Cyber Security Act 2024. The timelines, reporting bodies, and content requirements are different for each obligation, so you should maintain separate reporting workflows and not assume that filing one report satisfies the other. The SOCI Act covers 11 critical infrastructure sectors: communications, data storage or processing, financial services and markets, water and sewerage, energy, health care and medical, higher education and research, food and grocery, transport, space technology, and defence industry. If your entity is a responsible entity for an asset in any of these sectors and Part 2B applies, you must include the Australia Cyber Security Act 2024 ransomware reporting obligation in your incident response plan alongside your SOCI Act obligations. - A responsible entity for a critical infrastructure asset under the SOCI Act is automatically a reporting business entity under the Australia Cyber Security Act 2024, regardless of turnover. - Part 2B of the SOCI Act must apply to the asset for this automatic inclusion to take effect. Not all critical infrastructure assets are subject to Part 2B. - The SOCI Act cyber security incident report and the Australia Cyber Security Act 2024 ransomware payment report are separate obligations with different timelines and content requirements. - Do not assume that filing a SOCI Act incident report satisfies the ransomware payment reporting requirement under Part 3 of the Australia Cyber Security Act 2024. - Review your SOCI Act registration and Part 2B applicability to determine whether your entity enters scope for the Australia Cyber Security Act 2024 through the critical infrastructure route. - The 11 SOCI Act critical infrastructure sectors are: communications, data storage or processing, financial services and markets, water and sewerage, energy, health care and medical, higher education and research, food and grocery, transport, space technology, and defence industry. ## The 72 hour ransomware payment reporting window under the Australia Cyber Security Act 2024 Section 27(1) of the Australia Cyber Security Act 2024 requires the reporting business entity to give the designated Commonwealth body a ransomware payment report within 72 hours of making the ransomware payment or becoming aware that the ransomware payment has been made on its behalf, whichever is applicable. The 72 hour clock starts from the moment of payment or awareness, not from the moment the cyber security incident began or was discovered. The ransomware payment report must contain information that the reporting business entity knows or is able, by reasonable search or enquiry, to find out within the 72 hour reporting period (section 27(2)). This means you are not required to have complete forensic detail at the time of reporting. You are required to provide what you know and what you can reasonably ascertain within the window. Section 7 of the Ransomware Payment Reporting Rules 2025 specifies the required content: the reporting entity's contact and business details (including ABN and address), the other entity's details if a third party made the payment, information about the cyber security incident and its impact, the demand made by the extorting entity, the ransomware payment amount and method, and communications with the extorting entity. The civil penalty for failing to report within 72 hours is 60 penalty units under section 27(5) of the Australia Cyber Security Act 2024. However, section 28 provides a safe harbour: an entity is not liable to an action or other proceeding for damages for an act done or omitted in good faith in compliance with section 27. This means the Act protects entities that report in good faith, even if the report later turns out to be incomplete or if the information provided was based on the best available evidence at the time. The report must be given in the form approved by the Secretary (if any) and in the manner prescribed by the Rules (section 27(4)). Information in the ransomware payment report is protected under Division 3 of Part 3: it may only be used or disclosed for permitted cyber security purposes, and it cannot be used against the reporting entity in civil or regulatory proceedings (except for contraventions of Part 3 itself or criminal offences). This protection is designed to encourage timely and honest reporting. - The 72 hour clock starts from the time of payment or awareness of payment, not from incident discovery. - Report what you know or can reasonably find out within 72 hours. Perfect information is not required. - Include: entity contact details and ABN, third party payer details if applicable, incident details and impact, the demand, payment amount and method, and communications with the extorting entity. - Civil penalty for non reporting: 60 penalty units (section 27(5) of the Australia Cyber Security Act 2024). - Safe harbour protection: good faith reporting shields you from damages claims (section 28). - Report information is protected and cannot be used against you in civil or regulatory proceedings except for Part 3 contraventions or criminal offences. ## Payments made on your behalf: insurers, advisers, and outsourced ransomware payments Section 26(1)(e) of the Australia Cyber Security Act 2024 expressly captures situations where another entity has provided a ransomware payment on behalf of the reporting business entity. This means that if your cyber insurance provider, your incident response firm, your legal adviser, or any other third party makes a ransomware payment that is directly related to a demand arising from a cyber security incident that impacts your entity, the reporting obligation falls on your entity as soon as you become aware that the payment was made. The trigger for the 72 hour reporting window in this scenario is the moment of awareness. Under section 27(1), if another entity makes the payment on your behalf, the timer starts when your entity becomes aware that the payment has been made. You should ensure that your contracts with incident response firms, cyber insurers, and legal advisers include notification clauses that require them to inform you immediately if a ransomware payment is made or is about to be made on your behalf. Without these contractual safeguards, you risk missing the 72 hour window because you were not told about the payment in time. The Act does not define 'on behalf of' with a specific legal test, but the provision is intended to capture the practical reality of ransomware negotiations, where the entity that is impacted by the incident is not always the entity that physically transfers the payment. If a payment is made by a third party and is directly related to a demand arising from an incident that impacts your entity, assume the reporting obligation may apply and seek legal advice promptly. Pre payment negotiations are also relevant. Section 7(7)(c) of the Ransomware Payment Reporting Rules 2025 requires a brief description of any pre payment negotiations undertaken in relation to the demand or the ransomware payment. This means your reporting obligations extend to documenting the negotiation process, not just the final payment. - Ransomware payments made by insurers, incident response firms, legal advisers, or other third parties on your behalf still trigger your reporting obligation under the Australia Cyber Security Act 2024. - The 72 hour clock starts from when your entity becomes aware the payment was made, not from when the payment was physically transferred. - Update your contracts with cyber insurers and incident response providers to include immediate notification clauses for any ransomware payment made or authorised on your behalf. - Document all pre payment negotiations as required by section 7(7)(c) of the Ransomware Payment Reporting Rules 2025. - If you are unsure whether a payment was made on your behalf, treat the situation conservatively and prepare a report pending legal advice. - Include the third party payer's contact details and ABN in your ransomware payment report (section 7(3) of the Rules). ## Exemptions, exclusions, and entities outside the scope of the Australia Cyber Security Act 2024 The Australia Cyber Security Act 2024 contains several important scoping limitations and exemptions that may take your organisation or product outside the scope of one or both Parts. Understanding these boundaries is as important as understanding the positive scope criteria, because relying on an exemption without proper documentation can expose your organisation to enforcement risk if the exemption is later found not to apply. For Part 2 (smart device security standards), the principal exclusion mechanism is the list of product categories excluded from the consumer grade class in section 8 of the Smart Devices Rules 2025: desktop computers, laptops, tablet computers, smartphones, therapeutic goods, road vehicles, and road vehicle components. In addition, section 13(2)(b) of the Australia Cyber Security Act 2024 allows the rules to exempt specific classes of products or particular products from the definition of relevant connectable product altogether. No such general exemptions have been made in the 2025 Rules, but the power exists and may be exercised in the future. Products that are not intended for personal, domestic, or household use (for example, industrial IoT sensors sold exclusively in business to business channels with no consumer market) fall outside the consumer grade class and are not currently captured. For Part 3 (ransomware payment reporting), Commonwealth bodies and State bodies are excluded from the turnover route into scope under section 26(2)(a)(ii). However, they may still be captured through the critical infrastructure route if they are responsible entities for assets to which Part 2B of the SOCI Act applies. The $3 million turnover threshold itself functions as a de facto exemption for smaller businesses, although the pro rata calculation for partial years means that even a newly established business can be in scope if its annualised revenue pace exceeds $3 million. Section 15(5) of the Australia Cyber Security Act 2024 provides a constitutional exception: an entity is not required to comply with the Part 2 security standard to the extent that a requirement does not relate to internet connectivity or internet security measures, if the entity is neither a constitutional corporation nor engaged in interstate or international trade or commerce. In practice, this exception is narrow because most security standard requirements relate to internet connectivity, passwords, vulnerability disclosure, and security updates, all of which involve internet connection or internet security. - Part 2 exclusions: desktop computers, laptops, tablets, smartphones, therapeutic goods, road vehicles, road vehicle components. Document which exclusion applies and why. - Part 2 products outside the consumer grade class: industrial or enterprise only products not intended for personal, domestic, or household use may be outside scope, but document the basis for this conclusion. - Part 3 exclusion: Commonwealth bodies and State bodies are excluded from the $3 million turnover route but may still be captured through the SOCI Act critical infrastructure route. - Part 3 de facto exemption: entities with annual turnover below $3 million (or the pro rata equivalent) that are not SOCI Act responsible entities are not reporting business entities. - Constitutional exception under section 15(5): narrow in practice because most security standard requirements relate to internet connectivity. - Monitor the Federal Register of Legislation for future rules that may add or remove exemptions under section 13(2)(b) of the Australia Cyber Security Act 2024. ## Step by step applicability decision process for the Australia Cyber Security Act 2024 The following step by step process consolidates the applicability tests described above into a single decision workflow. Work through each step in order, recording your answer and the evidence supporting it. At the end, you will have a clear picture of which Parts of the Australia Cyber Security Act 2024 apply to your organisation and in what capacity. For Part 2 (smart device security standards): (1) List every product your organisation manufactures, imports, distributes, or supplies in Australia. (2) For each product, determine whether it is an internet connectable product or a network connectable product under section 13 of the Australia Cyber Security Act 2024. (3) For each relevant connectable product, check whether it falls within the consumer grade class under section 8 of the Smart Devices Rules 2025 and is not in one of the six excluded categories. (4) For each product that is in the consumer grade class, confirm it will be acquired in Australia by a consumer and that your entity is aware or could reasonably be expected to be aware of that fact. (5) Determine whether your entity is the manufacturer, the supplier, or both, and map the obligations accordingly. For Part 3 (ransomware payment reporting): (1) Determine whether your entity is a responsible entity for a critical infrastructure asset to which Part 2B of the SOCI Act applies. If yes, your entity is a reporting business entity regardless of turnover. (2) If not, determine whether your entity carries on business in Australia with annual turnover exceeding $3 million in the previous financial year (or the pro rata equivalent). (3) Confirm your entity is not a Commonwealth body or State body. (4) Document the conclusion and file it with your incident response plan so that the applicability question is already answered before an incident occurs. Compile your findings into a dated applicability decision memo. The memo should include: the legal entity name and ABN, the date of assessment, the products or activities assessed, the provisions of the Australia Cyber Security Act 2024 considered, the conclusion for Part 2 and Part 3 separately, any exclusions relied upon with statutory references, and the name and role of the officer who approved the conclusion. Store the memo in your compliance evidence pack and schedule the next review. - Step 1: Inventory all products your entity manufactures, imports, distributes, or supplies in Australia. - Step 2: Classify each product as internet connectable, network connectable, or neither under section 13 of the Australia Cyber Security Act 2024. - Step 3: Check the consumer grade class and the six excluded categories under the Smart Devices Rules 2025. - Step 4: Determine whether the product will be acquired in Australia by a consumer. - Step 5: Map manufacturer and supplier obligations under sections 15 and 16 of the Australia Cyber Security Act 2024. - Step 6: Determine reporting business entity status under section 26(2): either the SOCI Act critical infrastructure route or the $3 million turnover route. - Step 7: Document the conclusion for both Part 2 and Part 3 in a dated applicability decision memo and store it with your compliance evidence pack. - Step 8: Schedule a review trigger for new products, new markets, corporate acquisitions, turnover changes, or SOCI Act registration changes. ## Edge cases and practical considerations for the Australia Cyber Security Act 2024 applicability test Mixed hardware and software products can create false confidence about scope. If a product is sold as a household device but includes companion software, a mobile application, or cloud functionality, the applicability analysis under the Australia Cyber Security Act 2024 should cover the full intended use case, not just the hardware shell. The security standard in Schedule 1 of the Smart Devices Rules 2025 applies to hardware and to software that is pre installed on the product, software that must be installed for the manufacturer's intended purposes, and software developed by or on behalf of the manufacturer that is used for the product's intended purposes. All of these software components are in scope for the password, vulnerability disclosure, and security update requirements. For ransomware payment reporting under Part 3 of the Australia Cyber Security Act 2024, do not wait for every technical detail before deciding whether the reporting duty is triggered. The Act and the Ransomware Payment Reporting Rules 2025 only require information that the entity knows or can find out by reasonable search or enquiry within the 72 hour reporting period. If your entity has made or authorised a ransomware payment, or has become aware that a payment was made on its behalf, start the reporting process immediately and supplement the report with additional details as they become available. Group structures require careful analysis. Each legal entity in a corporate group is assessed separately under the Australia Cyber Security Act 2024. A subsidiary that manufactures smart devices is assessed independently from its parent company for Part 2 purposes. For Part 3 purposes, the turnover threshold applies to the specific entity that is the reporting business entity, not to the consolidated group. If an incident impacts multiple entities in a group and payments are made by or on behalf of more than one entity, each entity must independently assess its reporting obligation. International supply chains add complexity to the Part 2 analysis. A manufacturer based outside Australia that sells consumer grade smart devices into the Australian market is subject to the security standard and statement of compliance obligations if it is aware, or could reasonably be expected to be aware, that the product will be acquired in Australia by a consumer. The Australia Cyber Security Act 2024 applies both within and outside Australia under section 5 (extraterritoriality). Importers and distributors in Australia who are suppliers under the Australian Consumer Law are also independently obligated not to supply non compliant products. - Assess the full product ecosystem (hardware, companion apps, cloud services) when determining whether the security standard applies. - Document why a product is outside the consumer grade class if you rely on an exclusion, including the intended market and distribution channels. - Document who decided whether an incident involved a ransomware payment and when that conclusion was reached. - Treat outsourced payments, insurance mediated payments, and payments made by incident response advisers as potential triggers for your own reporting obligation. - Assess each legal entity in a corporate group separately for both Part 2 and Part 3 of the Australia Cyber Security Act 2024. - International manufacturers selling into Australia are subject to the Act under section 5 (extraterritoriality) if they are aware or could reasonably be expected to be aware of Australian consumer acquisition. - Review the applicability decision memo after major product updates, market changes, corporate restructuring, or incident response lessons learned. ## Primary sources - [Cyber Security Act 2024 (No. 98, 2024) official text](https://www.legislation.gov.au/C2024A00098/latest/text?ref=sorena.io) - Primary legislation defining relevant connectable products (section 13), reporting business entities (section 26), ransomware payment reporting (section 27), and enforcement powers. - [Cyber Security (Security Standards for Smart Devices) Rules 2025 official text](https://www.legislation.gov.au/F2025L00276/asmade/text?ref=sorena.io) - Defines the consumer grade smart device class and six excluded product categories (section 8), statement of compliance requirements (section 9), 5 year retention period (section 10), and the security standard in Schedule 1. - [Cyber Security (Ransomware Payment Reporting) Rules 2025 official text](https://www.legislation.gov.au/F2025L00278/asmade/text?ref=sorena.io) - Sets the $3 million annual turnover threshold (section 6), the pro rata formula for partial financial years (section 6(2)), and the required contents of a ransomware payment report (section 7). - [Security of Critical Infrastructure Act 2018 official text](https://www.legislation.gov.au/Details/C2018A00029?ref=sorena.io) - Defines critical infrastructure assets, responsible entities, and Part 2B cyber security obligations that create an alternative route into reporting business entity status under the Australia Cyber Security Act 2024. - [Australian Consumer Law (Schedule 2 to the Competition and Consumer Act 2010)](https://www.legislation.gov.au/C2004A00109/latest/text?ref=sorena.io) - Provides the definitions of manufacturer, supplier, and consumer that are incorporated by reference into the Australia Cyber Security Act 2024. ## Related Topic Guides - [Australia Cyber Security Act 2024 Compliance Checklist](/artifacts/apac/australia-cyber-security-act/checklist.md): Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting. - [Australia Cyber Security Act 2024 Compliance Guide | Implementation Playbook](/artifacts/apac/australia-cyber-security-act/compliance.md): A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements. - [Australia Cyber Security Act 2024 Compliance Templates | Statement of Compliance, Ransomware Report, Evidence Pack, Vulnerability Disclosure, Support Period](/artifacts/apac/australia-cyber-security-act/templates.md): Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field. - [Australia Cyber Security Act 2024 Deadlines and Compliance Calendar | Commencement Dates](/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar.md): Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent. - [Australia Cyber Security Act 2024 FAQ | Frequently Asked Questions](/artifacts/apac/australia-cyber-security-act/faq.md): Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024. - [Australia Cyber Security Act 2024 Requirements | Smart Device and Ransomware Reporting Obligations](/artifacts/apac/australia-cyber-security-act/requirements.md): Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure. - [Australia Cyber Security Act 2024 Timeline and Commencement Dates | Full Schedule](/artifacts/apac/australia-cyber-security-act/timeline-and-commencement.md): Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024. - [Australia Cyber Security Act 2024 vs EU Cyber Resilience Act | Full CRA Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act.md): Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements. - [Australia Cyber Security Act 2024 vs UK PSTI Act | Product Security Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act.md): Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements. - [Australia Smart Device Compliance Checklist | Cyber Security Act 2024 | Sorena](/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist.md): Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure. - [Penalties and fines | Australia Cyber Security Act 2024 | 60 Penalty Units, Smart Device Enforcement, Ransomware Reporting](/artifacts/apac/australia-cyber-security-act/penalties-and-fines.md): Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals. - [Ransomware Payment Reporting in 72 Hours | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours.md): Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. - [Scope and Definitions | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/scope-and-definitions.md): Complete guide to the Australia Cyber Security Act 2024 scope and definitions. - [Smart device security standards | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/smart-device-security-standards.md): Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2. - [Statement of Compliance and Recordkeeping | Australia Cyber Security Act 2024 | Section 9, Section 10, 5 Year Retention](/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping.md): Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/australia-cyber-security-act/applicability-test --- --- title: "Australia Cyber Security Act 2024 Compliance Checklist" canonical_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/checklist" source_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/checklist" author: "Sorena AI" description: "Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "Australia Cyber Security Act 2024 compliance checklist" - "Cyber Security Act 2024 checklist" - "smart device security standards Australia" - "ransomware payment reporting checklist" - "statement of compliance checklist" - "Australia cyber security compliance" - "Cyber Security Act 2024 obligations" - "smart device compliance Australia" - "ransomware reporting 72 hours Australia" - "SOCI Act cyber obligations" - "Australia Cyber Security Act enforcement" - "Cyber Security Act 2024 penalties" - "smart device security standards checklist" - "statement of compliance checklist Australia" - "APAC cyber compliance" - "Australia cyber security law checklist" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Australia Cyber Security Act 2024 Compliance Checklist Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting. *Artifact Guide* *APAC* ## Australia Cyber Security Act 2024 Compliance Checklist A comprehensive, section referenced compliance checklist covering every obligation under the Australia Cyber Security Act 2024, including smart device security standards, statement of compliance preparation, ransomware payment reporting, enforcement readiness, and recordkeeping requirements. This is written as a detailed implementation checklist for compliance professionals, not as a high level summary. Each item references the relevant Act section or Rules clause. The Australia Cyber Security Act 2024 (No. 98, 2024) creates three major compliance pillars: mandatory security standards for smart devices (Part 2), ransomware payment reporting obligations (Part 3), and voluntary information sharing for significant cyber security incidents (Part 4). Two subordinate instruments, the Cyber Security (Security Standards for Smart Devices) Rules 2025 and the Cyber Security (Ransomware Payment Reporting) Rules 2025, provide the operational detail. Splitting these obligations across disconnected teams is the fastest way to fail. This Australia Cyber Security Act 2024 compliance checklist is designed to be run as a single coordinated program, covering scope determination, product controls, evidence packs, incident reporting readiness, and enforcement preparation. Review this checklist at product launch, after every major update, and after every incident exercise. ## 1. Scope and program setup checklist for the Australia Cyber Security Act 2024 Before you can comply with the Australia Cyber Security Act 2024, you must determine which entities, products, and incident scenarios fall within scope. The Act applies both within and outside Australia (section 5) and binds the Crown in each of its capacities (section 6). Part 2 covers relevant connectable products manufactured or supplied (other than as second hand goods) on or after commencement (section 13(1)). Part 3 applies to reporting business entities that make or become aware of a ransomware payment. Assign accountable owners who can close gaps and approve evidence. A checklist without clear ownership becomes a list of wishes. - Identify every legal entity in your corporate group that manufactures or supplies relevant connectable products in Australia. A relevant connectable product is any internet connectable product or network connectable product that is not exempted under the rules (section 13(2) of the Act). - Determine whether each product is a consumer grade relevant connectable product under Schedule 1 of the Smart Device Rules. A product is in scope if it is intended by the manufacturer for personal, domestic, or household use and is not a desktop computer, laptop, tablet, smartphone, therapeutic good, road vehicle, or road vehicle component (Rules section 8(1)(a) and (b)). - For each legal entity, determine whether it qualifies as a reporting business entity under section 26(2) of the Act: either (a) carrying on a business in Australia with annual turnover exceeding the $3 million threshold for the previous financial year, or (b) a responsible entity for a critical infrastructure asset to which Part 2B of the Security of Critical Infrastructure Act 2018 applies. - For entities that carried on business for only part of the previous financial year, apply the prorated turnover threshold formula: $3 million multiplied by the number of days in the part divided by the number of days in the previous financial year (Ransomware Rules section 6(2)). - Name one accountable owner for smart device compliance under Part 2 of the Australia Cyber Security Act 2024, and a separate accountable owner for ransomware reporting readiness under Part 3. - Create an evidence folder structure for each product line (to support statement of compliance preparation) and for each incident reporting playbook (to support ransomware payment report readiness). - Define a review cadence tied to product launches, major firmware or software updates, annual assurance reviews, and post incident exercises. - Record and document every out of scope conclusion and the factual basis for each. Explain why each excluded product is not a relevant connectable product or not a consumer grade product, referencing section 13 of the Act and section 8 of the Rules. - Verify that your scope analysis addresses extraterritorial reach. The Australia Cyber Security Act 2024 applies both within and outside Australia (section 5), so overseas manufacturers and suppliers are covered if they are aware, or could reasonably be expected to be aware, that their products will be acquired in Australia. *Recommended next step* *Placement: after the checklist block* ## Turn Australia Cyber Security Act 2024 Compliance Checklist into an operational assessment Assessment Autopilot can take Australia Cyber Security Act 2024 Compliance Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on Australia Cyber Security Act 2024 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Australia Cyber Security Act 2024 Compliance Checklist](/solutions/assessment.md): Start from Australia Cyber Security Act 2024 Compliance Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Australia Cyber Security Act 2024](/contact.md): Review your current process, evidence gaps, and next steps for Australia Cyber Security Act 2024 Compliance Checklist. ## 2. Smart device password security checklist under Schedule 1 of the Smart Device Rules The Cyber Security (Security Standards for Smart Devices) Rules 2025, Schedule 1, clause 2 prescribes mandatory password requirements for all consumer grade relevant connectable products. These requirements apply to passwords for hardware not in the factory default state, software pre-installed at the point of supply, and software that must be installed for all of the manufacturer's intended purposes. Every product that ships to Australia must meet these Australia Cyber Security Act 2024 password controls before it reaches the consumer. - Verify that all passwords for hardware, pre-installed software, and required installable software are either (a) unique per product, or (b) defined by the user of the product (Schedule 1, clause 2(2)(a) and (b)). - Confirm that unique per product passwords are not based on incremental counters such as 'password1' and 'password2' (Schedule 1, clause 2(3)(a)). - Confirm that unique per product passwords are not based on or derived from publicly available information (Schedule 1, clause 2(3)(b)). - Confirm that unique per product passwords are not based on or derived from unique product identifiers such as serial numbers, unless this is done using an encryption method or keyed hashing algorithm that is accepted as part of good industry practice (Schedule 1, clause 2(3)(c)). - Confirm that unique per product passwords are not otherwise guessable in a manner unacceptable as part of good industry practice (Schedule 1, clause 2(3)(d)). - Document your password generation method and retain evidence that passwords meet good industry practice standards. If you rely on the encryption or keyed hashing exception for serial number based passwords, document the algorithm used and why it qualifies as good industry practice. - Test a sample of products from each production batch to verify that passwords are unique per product and that none are guessable or based on prohibited derivation methods. ## 3. Security issue reporting channel checklist under Schedule 1 of the Smart Device Rules Schedule 1, clause 3 of the Cyber Security (Security Standards for Smart Devices) Rules 2025 requires manufacturers to publish information on how a person can report security issues. This obligation covers hardware, pre-installed software, required installable software, and software used for or in connection with any of the manufacturer's intended purposes. The Australia Cyber Security Act 2024 mandates that this reporting channel be accessible without barriers. - Publish at least one point of contact to allow a person to report security issues to the manufacturer (Schedule 1, clause 3(2)(a)). - Publish the timing for when a person who reports a security issue will receive an acknowledgement of receipt (Schedule 1, clause 3(2)(b)(i)). - Publish the timing for when a person who reports a security issue will receive status updates until the resolution of the reported security issues (Schedule 1, clause 3(2)(b)(ii)). - Verify that the published reporting information is accessible, clear, and transparent (Schedule 1, clause 3(3)). - Verify that the reporting information is available without any prior request for the information (Schedule 1, clause 3(3)(a)). - Verify that the reporting information is published in English (Schedule 1, clause 3(3)(b)). - Verify that the reporting information is available free of charge (Schedule 1, clause 3(3)(c)). - Verify that accessing the reporting information does not require the person to provide personal information (Schedule 1, clause 3(3)(d)). - Conduct a user test: have someone outside the product team attempt to find the reporting channel, submit a test report, and confirm they receive an acknowledgement within the stated timing. ## 4. Defined support period and security update checklist under Schedule 1 of the Smart Device Rules Schedule 1, clause 4 of the Cyber Security (Security Standards for Smart Devices) Rules 2025 requires manufacturers to publish the defined support period for security updates and to comply with strict publication and prominence rules. The Australia Cyber Security Act 2024 compliance checklist must verify that every in scope product has a published support period that a non-technical consumer can understand, and that the manufacturer has not shortened it after publication. - Publish the defined support period for security updates for hardware capable of receiving security updates (Schedule 1, clause 4(1)(a)). - Publish the defined support period for security updates for pre-installed software capable of receiving security updates (Schedule 1, clause 4(1)(b)). - Publish the defined support period for security updates for required installable software capable of receiving security updates (Schedule 1, clause 4(1)(c)). - Publish the defined support period for security updates for software developed by or on behalf of the manufacturer that is capable of receiving security updates and used for any of the manufacturer's intended purposes (Schedule 1, clause 4(1)(d)). - Express the defined support period as a period of time with a clear end date (Schedule 1, clause 4(3)). - Verify that the published support period information is accessible, clear, and transparent (Schedule 1, clause 4(6)(a)). - Verify that the information is available without prior request, in English, free of charge, without requiring personal information, and in a way that is understandable by a reader without prior technical knowledge (Schedule 1, clause 4(6)(b)(i) through (v)). - If the manufacturer offers to supply the product on its own website or another website under its control, verify that the support period information is prominently published alongside other information that informs consumer buying decisions (Schedule 1, clause 4(7)(a)). - If the manufacturer publishes the main characteristics of the product on its website, verify that the support period is published alongside or given equal prominence to those main characteristics (Schedule 1, clause 4(7)(b)). - Confirm that the manufacturer has not shortened the defined support period after it was first published. The manufacturer must not shorten the defined support period (Schedule 1, clause 4(4)). - If the manufacturer extends the defined support period, verify that the new period is published as soon as is practicable (Schedule 1, clause 4(5)). - Document the support period for each product model and version. Retain a record of the original publication date and every subsequent change. ## 5. Statement of compliance preparation checklist under the Australia Cyber Security Act 2024 The statement of compliance is the formal, market facing artifact for the smart device security regime. Manufacturers must provide a statement of compliance for the supply of each in scope product in Australia (section 16(1) of the Act), and suppliers must supply the product accompanied by that statement (section 16(3)). The requirements for the statement are prescribed in section 9 of the Cyber Security (Security Standards for Smart Devices) Rules 2025. Treat this as a controlled release document with evidence gates and retention rules. - Confirm that the statement is prepared by, or on behalf of, the manufacturer of the product (Rules section 9(2)). - Include the product type and batch identifier in the statement (Rules section 9(3)(a)). - Include the name and address of the manufacturer of the product (Rules section 9(3)(b)(i)). - Include the name and address of an authorised representative of the manufacturer (Rules section 9(3)(b)(ii)). - Include the name and address of each (if any) of the manufacturer's other authorised representatives that are in Australia (Rules section 9(3)(b)(iii)). - Include a declaration that the statement has been prepared by, or on behalf of, the manufacturer of the product (Rules section 9(3)(c)). - Include a declaration that, in the opinion of the manufacturer, the product has been manufactured in compliance with the requirements of the security standard (Rules section 9(3)(d)(i)). - Include a declaration that, in the opinion of the manufacturer, the manufacturer has complied with any other obligations relating to the product in the security standard (Rules section 9(3)(d)(ii)). - Include the defined support period for the product at the date the statement of compliance is issued (Rules section 9(3)(e)). - Include the signature, name, and function of the signatory of the manufacturer (Rules section 9(3)(f)). - Include the place and date of issue of the statement of compliance (Rules section 9(3)(g)). - Verify that every field is complete before the signatory signs. An incomplete statement of compliance is a compliance risk under the Australia Cyber Security Act 2024. ## 6. Recordkeeping and evidence retention checklist for the Australia Cyber Security Act 2024 Both manufacturers and suppliers must retain a copy of the statement of compliance for the period specified in the rules (section 16(2) and 16(4) of the Act). The Cyber Security (Security Standards for Smart Devices) Rules 2025 set a 5 year retention period (Rules section 10). Effective recordkeeping is essential because the Secretary may request the product and/or the statement of compliance for independent examination at any time (section 23 of the Act). - Configure document retention for at least 5 years from the date each statement of compliance is issued (Rules section 10). - Test that you can retrieve any statement of compliance within a reasonable period if requested by the Secretary under section 23(3) of the Act. - Retain evidence supporting each declaration in the statement of compliance, including password testing results, security issue reporting channel screenshots, and defined support period publication records. - Maintain a version controlled archive of every statement of compliance issued. Track which product batches each statement covers. - If the manufacturer uses an authorised representative to prepare or manage statements, confirm that the representative retains a copy for the same 5 year period. - Retain records of any changes to the defined support period, including the original publication date, the date of any extension, and the updated end date. - If the manufacturer supplies through a website, retain periodic screenshots or captures showing that the support period information is displayed with equal prominence to main product characteristics, as evidence of compliance with Schedule 1, clause 4(7). - Store evidence in a manner that supports potential independent examination. The Secretary may engage an expert to open, operate, test, analyse, photograph, or video record the product (section 23(2) of the Act). ## 7. Ransomware payment reporting readiness checklist under the Australia Cyber Security Act 2024 Part 3 of the Australia Cyber Security Act 2024 requires reporting business entities to provide a ransomware payment report to the designated Commonwealth body within 72 hours of making a ransomware payment or becoming aware that a payment has been made (section 27(1)). Failure to report carries a civil penalty of 60 penalty units (section 27(5)). The reporting clock is short and the information burden is front loaded, so the only workable model is to prebuild the report pack and escalation paths before you need them. - Prepare a reporting business entity determination memo for each major legal entity. Document whether each entity (a) carries on a business in Australia with annual turnover exceeding $3 million, or (b) is a responsible entity for a critical infrastructure asset to which Part 2B of the SOCI Act applies (section 26(2) of the Act and Ransomware Rules section 6). - Identify who in the organisation decides whether a payment has been made and when the 72 hour reporting clock starts under section 27(1) of the Act. - Confirm the designated Commonwealth body that will receive the report. The default is the Department and ASD unless rules specify otherwise (section 8 definition of designated Commonwealth body). - Prebuild a report template that captures the reporting business entity's ABN (if any) and address (Ransomware Rules section 7(2)). - If another entity made the payment on behalf of the reporting business entity, ensure the template captures that entity's ABN (if any) and address (Ransomware Rules section 7(3)). - Include fields for when the incident occurred or is estimated to have occurred (Ransomware Rules section 7(4)(a)). - Include fields for when the reporting business entity became aware of the incident (Ransomware Rules section 7(4)(b)). - Include fields for the impact of the incident on the reporting business entity's infrastructure (Ransomware Rules section 7(4)(c)). - Include fields for the impact of the incident on the reporting business entity's customers (Ransomware Rules section 7(4)(d)). - Include fields for what variants (if any) of ransomware or other malware were used (Ransomware Rules section 7(4)(e)). - Include fields for what vulnerabilities (if any) in the reporting business entity's system were exploited (Ransomware Rules section 7(4)(f)). - Include fields for information that could assist the response to, mitigation, or resolution of the incident by a Commonwealth body or State body (Ransomware Rules section 7(4)(g)). - Include fields for the amount or description of the ransomware payment demanded, and the method of provision demanded (Ransomware Rules section 7(5)(a) and (b)). - Include fields for the amount or description of the ransomware payment actually made, and the method of provision (Ransomware Rules section 7(6)(a) and (b)). - Include fields for the nature and timing of any communications with the extorting entity, a brief description of those communications, and a brief description of any pre-payment negotiations (Ransomware Rules section 7(7)(a), (b), and (c)). - Map evidence sources for each report field. Information is only required to the extent the entity knows or is able, by reasonable search or enquiry, to find out within the 72 hour reporting window (Ransomware Rules section 7(1) note). - Confirm that outside counsel, insurance brokers, insurers, and any third party negotiators are included in the escalation path and are aware of the 72 hour reporting obligation. - Run a tabletop exercise on a ransomware payment scenario at least once every 12 months. Verify that the team can populate and submit the report within 72 hours. ## 8. Legal protections and admissibility checklist for ransomware reporting The Australia Cyber Security Act 2024 provides important protections for entities that report ransomware payments in good faith. Understanding these protections is part of the compliance checklist because they affect legal strategy, board reporting, and the willingness of incident teams to cooperate with the reporting obligation. - Confirm that legal counsel has reviewed the good faith liability protection: an entity is not liable to an action or other proceeding for damages for acts done or omitted in good faith in compliance with section 27 (section 28(1) of the Act). - Note that this protection extends to officers, employees, and agents of the entity who act in good faith in connection with the report (section 28(2)). - Review the restriction on use and disclosure: the designated Commonwealth body must not use information in a ransomware payment report to investigate or enforce any civil or regulatory contravention by the reporting entity, except for a contravention of Part 3 itself or a criminal offence (section 29(2)). - Review the admissibility protection: information from a ransomware payment report is not admissible in evidence against the reporting entity in criminal proceedings (other than for false or misleading information), civil penalty proceedings (other than under Part 3), or proceedings before a tribunal (section 32(2)). - Note the exceptions to admissibility protection: coronial inquiries, Royal Commissions, and federal court proceedings for writs of mandamus, prohibition, or injunction are not covered (section 32(3)). - Confirm that legal professional privilege is preserved. Providing information in a ransomware payment report does not affect any claim of legal professional privilege (section 31(1)). - Document these protections in the incident response playbook so that decision makers understand the legal framework when deciding whether to pay and report. ## 9. Enforcement readiness checklist for the Australia Cyber Security Act 2024 The Australia Cyber Security Act 2024 provides the Secretary with a graduated enforcement toolkit for smart device non-compliance: compliance notices (section 17), stop notices (section 18), and recall notices (section 19). The Minister may publicly name entities that fail to comply with a recall notice (section 20). The Act also provides monitoring powers, investigation powers, infringement notices, and civil penalty provisions through the Regulatory Powers (Standard Provisions) Act 2014 (Part 6). Organisations should prepare for enforcement before it happens. - Understand the enforcement escalation path: the Secretary issues a compliance notice first (section 17), then a stop notice if the compliance notice is not satisfied (section 18), then a recall notice if the stop notice is not satisfied (section 19). - Note that before any notice is given, the Secretary must notify the entity of the intention and give at least 10 days for the entity to make representations (sections 17(3), 18(3), 19(3)). - Prepare a response process so that the entity can submit representations within the 10 day minimum period when notified of an intended compliance, stop, or recall notice. - Understand that the entity may apply for internal review of a decision to give a compliance, stop, or recall notice within 30 days (section 22(1) and (2)). - Prepare for independent examination: the Secretary may engage an appropriately qualified expert to examine the product by opening, operating, testing, analysing, photographing, or video recording it (section 23(1) and (2)). - If the Secretary requests the product or statement of compliance for examination, comply within the specified period. The entity is entitled to reasonable compensation for complying with such a request (section 23(5)). - Note that the Minister may publish the identity of the entity, product details, non-compliance details, and risk details if the entity fails to comply with a recall notice (section 20). - Monitor for changes to the rules that may prescribe additional matters to be included in enforcement notices or published with recall notice non-compliance (sections 17(2)(h), 18(2)(h), 19(2)(h), 20(e)). - For ransomware reporting, note the civil penalty of 60 penalty units for failure to submit a report within 72 hours (section 27(5)). - Confirm that your entity understands the civil penalty provisions, enforceable undertakings, and injunction powers in Part 6 of the Australia Cyber Security Act 2024 (sections 79 through 83). - Note that monitoring powers (section 80) and investigation powers (section 81) apply and are supported by the Regulatory Powers (Standard Provisions) Act 2014. ## 10. Voluntary information sharing and significant incident readiness checklist Part 4 of the Australia Cyber Security Act 2024 provides a framework for voluntary information sharing with the National Cyber Security Coordinator (NCSC) during significant cyber security incidents. While not mandatory, preparing for this voluntary process is a practical compliance readiness step because many entities that face ransomware scenarios will also face significant incidents. The Act provides strong protections for information shared voluntarily. - Understand the definition of a significant cyber security incident: a cyber security incident where there is a material risk that it has seriously prejudiced or could prejudice the social or economic stability of Australia, the defence of Australia, or national security, or is of serious concern to the Australian people (section 34). - Designate an internal point of contact for voluntary information sharing with the NCSC. Information may be provided at any time during the response to the incident (section 35(3)(a)). - Note that the NCSC may request information but there is no obligation on the entity to provide it (section 35 note after subsection (3)). - Review the NCSC's permitted use of voluntarily shared information: the NCSC may use it only for assisting the entity to respond to, mitigate, or resolve the incident, or for a permitted cyber security purpose (section 38(1)). - Review the restriction on civil or regulatory action: the NCSC must not use voluntarily shared information to investigate or enforce any civil or regulatory contravention by the impacted entity, except for a contravention of Part 4 itself or a criminal offence (section 38(2)). - Note the admissibility protection: voluntarily shared information is not admissible in evidence against the entity in criminal proceedings (other than for false information), civil penalty proceedings (other than under Part 4), or tribunal proceedings (section 42(2)). - Document these protections in the incident response playbook so that decision makers can quickly decide whether to share information voluntarily during a significant incident. - Confirm that voluntary information sharing under Part 4 does not affect any other requirement to provide information under the Act or another Commonwealth law (section 44). ## 11. Cyber Incident Review Board preparedness checklist Part 5 of the Australia Cyber Security Act 2024 establishes the Cyber Incident Review Board (CIRB), which may cause reviews to be conducted in relation to cyber security incidents. While organisations cannot predict whether their incidents will be reviewed, understanding the process and protections helps with readiness. The CIRB will not apportion blame or provide the means to determine liability (section 62(2)), but it may request or require documents. - Note that the Board's function is to identify factors that contributed to an incident and make recommendations to government and industry about prevention, detection, response, and impact minimisation (section 62(1)(a)). - If the Chair requests information or documents under section 48, the entity is not obliged to comply. However, if the Chair requires document production under section 49 (which applies only to non-government entities involved in the incident), failure to comply carries a civil penalty of 60 penalty units (section 50(1)). - Understand the exceptions: production of documents is not required if it would prejudice the security or defence of the Commonwealth, intelligence agency capabilities, offence investigation, or the administration of justice (section 50(2)). - Note the good faith liability protection for complying with section 49 document production notices (section 74(1) and (2)). - Note the admissibility protection: information provided to the Board under section 48, 49, or 51 is not admissible against the entity in criminal, civil penalty, or tribunal proceedings, with exceptions for false information offences and federal court constitutional proceedings (section 58). - Confirm that legal professional privilege is preserved when providing information to the Board (section 57). - Include CIRB cooperation protocols in your incident response playbook so the entity can respond promptly if the Board selects one of your incidents for review. ## 12. Testing, verification, and ongoing assurance checklist Compliance with the Australia Cyber Security Act 2024 is not a one-time exercise. Products change, firmware updates ship, new legal entities enter the market, and incident response teams rotate. This section of the checklist covers the recurring verification activities that maintain compliance over time. - Schedule regular production sampling to verify that password uniqueness and non-guessability requirements remain met after firmware or software updates. - Periodically test the security issue reporting channel to confirm it is still accessible, in English, free of charge, and does not require personal information to access. - Monitor the published defined support period for each product. Confirm that it has not been inadvertently shortened and that any extension is published as soon as practicable. - Review and update statements of compliance whenever a new product batch is manufactured or a material change to the product is introduced. - Conduct an annual review of the reporting business entity determination for each legal entity, accounting for changes in turnover and changes to SOCI Act critical infrastructure asset status. - Run a full ransomware payment reporting tabletop exercise at least annually. Measure time to report completion and compare against the 72 hour window. - Update the pre-built ransomware payment report template whenever the Ransomware Payment Reporting Rules are amended. - Review the Australia Cyber Security Act 2024 rules register on the Federal Register of Legislation for any new or amended rules that change scope, thresholds, or reporting requirements. - Track the Secretary's annual report and the Cyber Incident Review Board's published final review reports for enforcement trends and recommended industry practices. - Review your enforcement response process and ensure it can handle a compliance notice, stop notice, or recall notice within the timelines specified by the Secretary. - Confirm that all compliance roles have designated alternates so that the program continues operating during leave, travel, or personnel changes. ## Primary sources - [Cyber Security Act 2024 (No. 98, 2024) official text](https://www.legislation.gov.au/C2024A00098/latest/text?ref=sorena.io) - The primary legislation. Sets the smart device security standard framework (Part 2), ransomware payment reporting obligations (Part 3), voluntary information sharing with the NCSC (Part 4), the Cyber Incident Review Board (Part 5), and enforcement powers (Part 6). - [Cyber Security (Security Standards for Smart Devices) Rules 2025 (F2025L00276) official text](https://www.legislation.gov.au/F2025L00276/asmade/text?ref=sorena.io) - Prescribes the security standard for consumer grade relevant connectable products, including password requirements, security issue reporting requirements, defined support period requirements, statement of compliance requirements, and the 5 year retention period. - [Cyber Security (Ransomware Payment Reporting) Rules 2025 (F2025L00278) official text](https://www.legislation.gov.au/F2025L00278/asmade/text?ref=sorena.io) - Specifies the $3 million annual turnover threshold for reporting business entities and the detailed information requirements for ransomware payment reports within the 72 hour reporting window. - [Security of Critical Infrastructure Act 2018 official text](https://www.legislation.gov.au/Details/C2018A00029?ref=sorena.io) - Relevant for determining whether an entity is a responsible entity for a critical infrastructure asset, which is one pathway to becoming a reporting business entity under Part 3 of the Australia Cyber Security Act 2024. ## Related Topic Guides - [Australia Cyber Security Act 2024 Applicability Test | Who Must Comply](/artifacts/apac/australia-cyber-security-act/applicability-test.md): Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations. - [Australia Cyber Security Act 2024 Compliance Guide | Implementation Playbook](/artifacts/apac/australia-cyber-security-act/compliance.md): A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements. - [Australia Cyber Security Act 2024 Compliance Templates | Statement of Compliance, Ransomware Report, Evidence Pack, Vulnerability Disclosure, Support Period](/artifacts/apac/australia-cyber-security-act/templates.md): Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field. - [Australia Cyber Security Act 2024 Deadlines and Compliance Calendar | Commencement Dates](/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar.md): Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent. - [Australia Cyber Security Act 2024 FAQ | Frequently Asked Questions](/artifacts/apac/australia-cyber-security-act/faq.md): Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024. - [Australia Cyber Security Act 2024 Requirements | Smart Device and Ransomware Reporting Obligations](/artifacts/apac/australia-cyber-security-act/requirements.md): Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure. - [Australia Cyber Security Act 2024 Timeline and Commencement Dates | Full Schedule](/artifacts/apac/australia-cyber-security-act/timeline-and-commencement.md): Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024. - [Australia Cyber Security Act 2024 vs EU Cyber Resilience Act | Full CRA Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act.md): Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements. - [Australia Cyber Security Act 2024 vs UK PSTI Act | Product Security Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act.md): Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements. - [Australia Smart Device Compliance Checklist | Cyber Security Act 2024 | Sorena](/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist.md): Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure. - [Penalties and fines | Australia Cyber Security Act 2024 | 60 Penalty Units, Smart Device Enforcement, Ransomware Reporting](/artifacts/apac/australia-cyber-security-act/penalties-and-fines.md): Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals. - [Ransomware Payment Reporting in 72 Hours | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours.md): Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. - [Scope and Definitions | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/scope-and-definitions.md): Complete guide to the Australia Cyber Security Act 2024 scope and definitions. - [Smart device security standards | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/smart-device-security-standards.md): Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2. - [Statement of Compliance and Recordkeeping | Australia Cyber Security Act 2024 | Section 9, Section 10, 5 Year Retention](/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping.md): Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/australia-cyber-security-act/checklist --- --- title: "Australia Cyber Security Act 2024 Compliance Guide" canonical_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/compliance" source_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/compliance" author: "Sorena AI" description: "A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "Australia Cyber Security Act 2024 compliance guide" - "Cyber Security Act 2024 implementation playbook" - "smart device security standards Australia compliance" - "ransomware payment reporting Australia compliance" - "statement of compliance smart devices" - "compliance notice stop notice recall notice" - "Cyber Security Act 2024 audit readiness" - "APAC cyber security compliance" - "reporting business entity ransomware" - "National Cyber Security Coordinator" - "Cyber Incident Review Board" - "consumer grade connectable products compliance" - "Australia Cyber Security Act 2024 compliance" - "smart device security standards Australia" - "ransomware payment reporting" - "statement of compliance" - "compliance notice" - "stop notice" - "recall notice" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Australia Cyber Security Act 2024 Compliance Guide A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements. *Implementation Guide* *APAC* ## Australia Cyber Security Act 2024 Compliance Guide A step-by-step compliance guide covering smart device security standards, statement of compliance, ransomware payment reporting, enforcement readiness, and evidence controls. Designed for manufacturers, suppliers, and reporting business entities that need to operationalise the Australia Cyber Security Act 2024. The Australia Cyber Security Act 2024 (No. 98, 2024) creates two core compliance systems. The first system requires manufacturers and suppliers of consumer grade relevant connectable products to meet mandatory security standards and provide a statement of compliance. The second system requires reporting business entities to report ransomware payments to the designated Commonwealth body within 72 hours. A robust Australia Cyber Security Act 2024 compliance program treats these two systems as linked control lanes that share governance, evidence standards, and executive reporting. This guide walks compliance professionals through the regulatory framework, the obligations under each Part, the enforcement escalation pathway, and the practical steps needed to build and maintain an audit-ready program. ## Australia Cyber Security Act 2024 regulatory framework overview The Australia Cyber Security Act 2024 is organised into seven Parts. Part 1 defines core terms including cyber security incident, relevant connectable product, reporting business entity, and permitted cyber security purpose. Part 2 establishes mandatory security standards for smart devices (relevant connectable products). Part 3 imposes ransomware payment reporting obligations on reporting business entities. Part 4 enables voluntary information sharing with the National Cyber Security Coordinator for significant cyber security incidents. Part 5 establishes the Cyber Incident Review Board. Part 6 provides regulatory powers including civil penalties, enforceable undertakings, injunctions, monitoring powers, investigation powers, and infringement notices. Part 7 covers miscellaneous provisions including delegations and rule-making powers. Three legislative instruments work together. The Cyber Security Act 2024 itself provides the framework. The Cyber Security (Security Standards for Smart Devices) Rules 2025 (F2025L00276) prescribes the detailed security standard for consumer grade relevant connectable products and the requirements for the statement of compliance. The Cyber Security (Ransomware Payment Reporting) Rules 2025 (F2025L00278) sets the turnover threshold at $3 million and prescribes the information content requirements for ransomware payment reports. A compliance program under the Australia Cyber Security Act 2024 must address all three instruments. The Act applies both within and outside Australia (Section 5) and binds the Crown in each of its capacities (Section 6). It operates concurrently with State and Territory laws (Section 7). This extraterritorial scope means that overseas manufacturers and suppliers whose products are acquired by consumers in Australia must comply with the security standards prescribed under Part 2 of the Australia Cyber Security Act 2024. - Part 2 commenced 29 November 2025. The Smart Devices Rules (Schedule 1) commenced 4 March 2026. Both are now in force. - Part 3 (ransomware reporting) commenced 29 May 2025. The Ransomware Payment Reporting Rules commenced on the same date. - Part 4 (voluntary information sharing with the National Cyber Security Coordinator) commenced 30 November 2024. - Part 5 (Cyber Incident Review Board) commenced 29 May 2025. - Parts 6 and 7 (regulatory powers and miscellaneous) commenced 30 November 2024. - The Act requires a statutory review to begin before the fifth anniversary of commencement (Section 88). ## Determine scope: who must comply with the Australia Cyber Security Act 2024 The Australia Cyber Security Act 2024 creates obligations for two distinct groups. The first group consists of manufacturers and suppliers of relevant connectable products that will be acquired by consumers in Australia. The second group consists of reporting business entities that make or become aware of a ransomware payment. Compliance professionals must determine whether their organisation falls into one or both groups. A relevant connectable product is a product that is either an internet-connectable product (capable of connecting to the internet using a protocol from the internet protocol suite) or a network-connectable product (capable of sending and receiving data by electrical or electromagnetic transmission and meeting certain connectivity conditions). The Smart Devices Rules narrow the scope to consumer grade relevant connectable products intended for personal, domestic, or household use. Desktop computers, laptops, tablet computers, smartphones, therapeutic goods, road vehicles, and road vehicle components are explicitly excluded from the current security standard. A reporting business entity is an entity that, at the time a ransomware payment is made, is either (a) carrying on a business in Australia with an annual turnover for the previous financial year exceeding $3 million, or (b) a responsible entity for a critical infrastructure asset to which Part 2B of the Security of Critical Infrastructure Act 2018 applies. Commonwealth bodies and State bodies are excluded from category (a) but critical infrastructure entities are captured regardless of turnover. - Manufacturers must comply with the security standard if they are aware, or could reasonably be expected to be aware, that the product will be acquired in Australia by a consumer. - Suppliers must not supply a non-compliant product in Australia and must supply the product with a statement of compliance. - The manufacturer and supplier obligations under Sections 15 and 16 apply to products manufactured on or after Part 2 commencement, or supplied (other than as second-hand goods) on or after that date. - For ransomware reporting, the $3 million turnover threshold is prorated for businesses that operated for only part of the previous financial year. - If your organisation both manufactures or supplies smart devices and operates as a reporting business entity, you must comply with both Part 2 and Part 3 of the Australia Cyber Security Act 2024. ## Build the Australia Cyber Security Act 2024 compliance program structure An effective Australia Cyber Security Act 2024 compliance program is built around two control lanes that feed a single governance forum. Control Lane 1 covers smart device product security: security standard compliance, statement of compliance preparation and retention, public disclosure of support periods and vulnerability reporting mechanisms, and readiness for enforcement notices. Control Lane 2 covers ransomware incident response: reporting business entity threshold analysis, payment escalation procedures, 72-hour ransomware payment report preparation, and post-incident evidence retention. Both control lanes should share a common risk register, a common exceptions process, and a common executive reporting cadence. This prevents compliance gaps from being hidden in separate teams and ensures that product security and incident response obligations are governed under a single accountability structure. - Control Lane 1 covers: product scope assessment, password compliance, vulnerability reporting page publication, defined support period publication, security update commitments, statement of compliance preparation, statement retention for 5 years, and readiness for compliance notices, stop notices, and recall notices. - Control Lane 2 covers: reporting business entity analysis (turnover threshold or critical infrastructure status), payment escalation path, 72-hour reporting clock management, report content assembly, evidence retention, and liaison with the designated Commonwealth body. - Both lanes should use one risk register, one exceptions process, and one executive reporting cadence. - Quarterly governance should review open gaps, product launch readiness, and incident drill outcomes. - Maintain a single compliance register that maps each Section and Rule to a named control, an owner, a test procedure, and an evidence artifact. *Recommended next step* *Placement: after the compliance steps* ## Turn Australia Cyber Security Act 2024 Compliance Guide into an operational assessment Assessment Autopilot can take Australia Cyber Security Act 2024 Compliance Guide from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on Australia Cyber Security Act 2024 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Australia Cyber Security Act 2024 Compliance Guide](/solutions/assessment.md): Start from Australia Cyber Security Act 2024 Compliance Guide and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Australia Cyber Security Act 2024](/contact.md): Review your current process, evidence gaps, and next steps for Australia Cyber Security Act 2024 Compliance Guide. ## Roles and responsibilities for Australia Cyber Security Act 2024 compliance Australia Cyber Security Act 2024 compliance breaks down when ownership is shared in theory but not in practice. Each statutory obligation needs a named owner with the authority to stop a product release, request evidence, or trigger executive escalation. The following role assignments reflect the obligations in the Act and the Rules. For product security, the manufacturer bears primary responsibility. Under Section 15 of the Australia Cyber Security Act 2024, the manufacturer must manufacture the product in compliance with the security standard and comply with all other requirements of the standard (publishing vulnerability reporting information, publishing the defined support period, and ensuring passwords meet the Rules). The supplier bears a secondary but independent obligation under Section 16: the supplier must not supply a non-compliant product and must supply the product with a statement of compliance. Both the manufacturer and the supplier must retain a copy of the statement of compliance for 5 years. For ransomware reporting, the reporting business entity bears the obligation. But the reporting obligation depends on a payment decision, which means finance and executive leadership must be in the escalation path. The obligation is to report within 72 hours of making the payment or becoming aware that the payment has been made. This requires a clear chain of command that connects the cyber response team to the person who authorises payment and to the person who submits the report. - Product security owner: approves control design, release evidence, password compliance, vulnerability reporting page content, and defined support period publication. - Compliance owner: controls statement of compliance templates, retention schedule (5 years per Rule 10), supplier handoff documentation, and legal interpretation records. - Engineering lead: implements password requirements (unique per product or user-defined, not based on incremental counters or publicly available information), security update delivery mechanisms, and defined support period tracking. - Incident commander or cyber response lead: owns the ransomware payment reporting runbook, the 72-hour clock management procedure, and post-incident evidence retention. - Finance and executive leadership: must be in the payment escalation path because the reporting obligation is triggered by the fact of payment, not only by technical containment. - Procurement or channel management: confirms how statements of compliance travel with the product through the supply chain in Australia. - Legal counsel: advises on reporting business entity threshold analysis, legal professional privilege implications (Section 31), and admissibility protections (Section 32). ## Smart device security standard compliance under the Australia Cyber Security Act 2024 Schedule 1, Part 1 of the Smart Devices Rules prescribes three categories of security requirements for consumer grade relevant connectable products. Compliance with these requirements is mandatory for all manufacturers who are aware, or could reasonably be expected to be aware, that their product will be acquired by a consumer in Australia. These requirements form the core of the product security control lane under the Australia Cyber Security Act 2024. The first category is password requirements (Clause 2). Passwords for use with a relevant connectable product must be either unique per product or defined by the user of the product. Passwords that are unique per product must not be based on incremental counters, must not be based on or derived from publicly available information, must not be based on or derived from unique product identifiers (such as serial numbers) unless done using an encryption method or keyed hashing algorithm accepted as part of good industry practice, and must not be otherwise guessable in a manner unacceptable as part of good industry practice. This applies to hardware passwords, pre-installed software passwords, and passwords for software that must be installed for all of the manufacturer's intended purposes. The second category is vulnerability reporting requirements (Clause 3). The manufacturer must publish at least one point of contact for reporting security issues, the timeframes for acknowledgement of receipt, and status updates until resolution. This information must be accessible, clear, transparent, available in English, free of charge, available without prior request, and available without requesting personal information from the person reporting. The third category is defined support period and security update requirements (Clause 4). The manufacturer must publish the defined support period, expressed as a period of time with an end date, for which security updates will be provided. The manufacturer must not shorten the defined support period after publication. If the manufacturer extends the period, the new period must be published as soon as is practicable. If the manufacturer offers to supply the product on its website, the defined support period information must be prominently published alongside the main product characteristics. - Audit every product line to confirm passwords are unique per product or user-defined. Document the password generation method and confirm it does not use incremental counters or publicly available identifiers. - Publish a vulnerability reporting page that includes a contact point, acknowledgement timeframe, and status update commitment. Confirm it is accessible without login, in English, and free of charge. - Publish the defined support period with an explicit end date. Confirm it is displayed alongside main product characteristics on any website where the product is offered for supply. - Build a change control process that prevents the defined support period from being shortened after initial publication. - Map each requirement (Clauses 2, 3, and 4) to a specific test procedure, an owner, and a dated evidence artifact. - Include all three categories in pre-launch release gates so that no product is supplied in Australia without confirmed compliance. ## Statement of compliance requirements under the Australia Cyber Security Act 2024 Section 16 of the Australia Cyber Security Act 2024 requires manufacturers to provide a statement of compliance for the supply of a relevant connectable product in Australia, and requires suppliers to supply the product with that statement. Rule 9 of the Smart Devices Rules prescribes the content requirements for the statement. Rule 10 sets the retention period at 5 years. The statement of compliance is the primary documentary evidence that the regulator will examine when assessing compliance under the Australia Cyber Security Act 2024. The statement must be prepared by, or on behalf of, the manufacturer. It must include: the product type and batch identifier; the name and address of the manufacturer, an authorised representative of the manufacturer, and each other authorised representative of the manufacturer that is in Australia; a declaration that the statement was prepared by or on behalf of the manufacturer; a declaration that in the opinion of the manufacturer the product was manufactured in compliance with the security standard and the manufacturer has complied with all other obligations in the standard; the defined support period for the product at the date the statement is issued; the signature, name, and function of the signatory of the manufacturer; and the place and date of issue. - Create a statement of compliance template that includes all fields required by Rule 9: product type, batch identifier, manufacturer details, authorised representative details, compliance declarations, defined support period, signatory information, and date and place of issue. - Assign a compliance owner to review and approve each statement before it accompanies a product into the Australian supply chain. - Implement a retention system that preserves each issued statement for at least 5 years (Rule 10), indexed by product type, batch, and date of issue. - Ensure both manufacturers and suppliers retain their own copies. The retention obligation applies independently to each party under Sections 16(2) and 16(4). - Version-control statements so that any update to the defined support period or authorised representative details generates a new, dated statement. - Store statements in a searchable archive that supports rapid retrieval in response to a compliance notice or an independent examination request under Section 23. ## Ransomware payment reporting compliance under the Australia Cyber Security Act 2024 Part 3 of the Australia Cyber Security Act 2024 requires a reporting business entity that makes a ransomware payment, or becomes aware that another entity has made a ransomware payment on its behalf, to submit a ransomware payment report to the designated Commonwealth body within 72 hours. Failure to report is a civil penalty of 60 penalty units. The Ransomware Payment Reporting Rules 2025 prescribe the content requirements for the report. The 72-hour clock starts when the payment is made or when the entity becomes aware that the payment has been made, whichever is applicable. Information is only required to be given to the extent that the reporting business entity knows or is able, by reasonable search or enquiry, to find out within the 72-hour period. This means the compliance program must be designed to gather report-ready information quickly and under pressure. The report must contain the entity's ABN (if any) and address; the contact and business details of any other entity that made the payment on behalf of the reporting business entity; detailed information about the cyber security incident (when it occurred, when it was detected, the impact on infrastructure, the impact on customers, the ransomware or malware variants used, the vulnerabilities exploited, and any information that could assist Commonwealth or State body response); the amount or quantum of the demand, the method of provision demanded; the amount or quantum of the payment, the method of provision; and the nature, timing, and description of communications with the extorting entity, including any pre-payment negotiations. - Confirm your organisation's reporting business entity status: annual turnover exceeding $3 million in the previous financial year, or responsible entity for a critical infrastructure asset under Part 2B of the SOCI Act 2018. - Build a ransomware payment reporting runbook that covers: incident detection, escalation to incident commander, payment decision authority, 72-hour clock start, information gathering, report assembly, submission to the designated Commonwealth body, and post-submission evidence retention. - Pre-populate report templates with standing information: ABN, registered address, key contact details, critical infrastructure asset status. - Define clear authority for payment decisions. The reporting obligation is triggered by the fact of payment, so the person who authorises payment must understand the reporting consequences. - Conduct tabletop exercises at least twice per year that simulate a ransomware incident with a payment decision. Measure time to report readiness against the 72-hour deadline. - Document the legal professional privilege protections (Section 31) and the admissibility protections (Section 32) so that response teams understand the safe harbour design of the Act. - Note that ransomware payment report information can only be used or disclosed for permitted purposes under Section 29. It cannot be used for civil or regulatory enforcement against the reporting entity, except for contraventions of Part 3 itself or criminal offences. ## Enforcement escalation under the Australia Cyber Security Act 2024 The Australia Cyber Security Act 2024 provides a graduated enforcement escalation pathway for smart device obligations. The Secretary may issue a compliance notice (Section 17) if reasonably satisfied that an entity is not complying with Section 15 or 16, or if aware of information suggesting possible non-compliance. If the compliance notice is not complied with, or actions taken are inadequate, the Secretary may issue a stop notice (Section 18). If the stop notice is not complied with or remediation is inadequate, the Secretary may issue a recall notice (Section 19). If the entity fails to comply with the recall notice, the Minister may publicly notify the failure on the Department's website (Section 20). Before issuing any notice, the Secretary must notify the entity of the intention to issue the notice and give the entity at least 10 days to make representations. Only one notice of each type may be issued for a particular instance of non-compliance. Notices may be varied or revoked under Section 21. An entity may apply for internal review of a notice decision within 30 days (Section 22). The decision-maker must complete the review and affirm, vary, or revoke the decision within 30 days of receiving the application. The Secretary may also engage an independent expert to examine a product to determine whether it complies with the security standard or whether the statement of compliance meets the requirements (Section 23). The Secretary may request the manufacturer or supplier to provide the product and the statement of compliance for examination. The entity is entitled to reasonable compensation for complying with such a request. Part 6 of the Australia Cyber Security Act 2024 provides additional regulatory powers. Each civil penalty provision is enforceable through civil penalty orders (Part 4 of the Regulatory Powers Act), enforceable undertakings (Part 6), and injunctions (Part 7). Sections 15 and 16 are also subject to enforceable undertakings. Monitoring powers (Section 80) allow authorised persons to enter non-residential premises with a magistrate's warrant. Investigation powers (Section 81) allow investigation of evidential material related to civil penalty provisions. Infringement notices (Section 82) may be issued for alleged civil penalty contraventions. - Compliance notice (Section 17): specifies actions to address non-compliance, sets a reasonable deadline, and may require evidence of remediation. - Stop notice (Section 18): issued after a compliance notice is not adequately addressed. Requires the entity to take or refrain from specified actions. - Recall notice (Section 19): issued after a stop notice is not adequately addressed. May require the entity to ensure the product is not acquired or supplied in Australia, and to arrange for product returns. - Public notification (Section 20): Minister may publish the entity's identity, product details, non-compliance details, and risks posed by the product. - Internal review (Section 22): entity may apply within 30 days. Decision-maker must resolve within 30 days. - Independent examination (Section 23): Secretary may engage an expert to test the product and examine the statement of compliance. - Civil penalties: 60 penalty units for failure to report a ransomware payment (Section 27(5)), and 60 penalty units for secondary misuse of ransomware report information (Sections 30(6) and others). - Relevant courts for enforcement include the Federal Court of Australia and the Federal Circuit and Family Court of Australia (Division 2). ## Evidence requirements and audit preparation under the Australia Cyber Security Act 2024 The regulator can test the product, request the statement of compliance, and examine whether the statutory requirements were met. This means evidence under the Australia Cyber Security Act 2024 must be versioned, retrievable, and linked to the exact product release or incident event. The best approach is to build an evidence index for each product line and for each incident drill or real incident. For smart device compliance, the evidence pack should demonstrate compliance with each requirement in Schedule 1 of the Smart Devices Rules. For ransomware reporting compliance, the evidence pack should demonstrate that the organisation has a functioning reporting capability that can meet the 72-hour deadline. Both evidence packs feed into a single audit-ready compliance file for the Australia Cyber Security Act 2024. - Product evidence: password generation method documentation, test results confirming passwords are not based on incremental counters or publicly available information, screenshots of the published vulnerability reporting page with timestamps, screenshots of the published defined support period with timestamps, and evidence that the support period is displayed alongside main product characteristics on the manufacturer's website. - Statement evidence: archived copies of each issued statement of compliance with product type, batch identifier, signatory details, and date of issue. Confirm the 5-year retention schedule is active. - Ransomware reporting evidence: documented runbook, tabletop exercise records (scenario, participants, time to report readiness, lessons learned), pre-populated report templates, authority matrix for payment decisions, and records of any real ransomware payment reports submitted. - Governance evidence: minutes from quarterly compliance governance meetings, risk register entries related to the Australia Cyber Security Act 2024, exception records, and executive sponsor sign-off on residual risks. - Run retrieval drills at least annually so you can prove not only that evidence exists, but that it can be produced quickly in response to a compliance notice or an examination request under Section 23. - Maintain a log of all regulatory interactions, including any representations made during the 10-day notice consultation period, any internal review applications, and any outcomes. ## Ongoing monitoring and review cadence for Australia Cyber Security Act 2024 compliance The Australia Cyber Security Act 2024 does not reward annual policy reviews. It rewards current, usable controls. The compliance program should be reviewed when products change, when support periods move, when new product lines enter scope, and after incidents or exercises reveal new failure points. The following review cadence keeps the program alive and audit-ready. The Act itself requires a statutory review before the fifth anniversary of commencement (Section 88), and the Rules may be amended over time. Compliance professionals should monitor the Federal Register of Legislation for amendments to the Act, the Smart Devices Rules, and the Ransomware Payment Reporting Rules. - Review smart device evidence before each product launch and each major firmware or software update. - Review public support period content whenever product support commitments change. Confirm the defined support period has not been shortened. - Review the ransomware reporting playbook after every tabletop exercise and every real incident involving extortion. - Conduct annual legal refresh on reporting business entity status (turnover threshold, critical infrastructure status), the scope of excluded product categories, and any amendments to the Rules. - Review the vulnerability reporting page at least quarterly to confirm the contact point, acknowledgement timeframe, and status update commitment remain accurate and accessible. - Report unresolved compliance gaps and accepted risks to an executive sponsor at least quarterly. - Monitor guidance published by the Department of Home Affairs, the Australian Signals Directorate, and the National Cyber Security Coordinator for interpretive updates on the Australia Cyber Security Act 2024. ## Voluntary information sharing and the Cyber Incident Review Board Part 4 of the Australia Cyber Security Act 2024 enables impacted entities to voluntarily share information about significant cyber security incidents with the National Cyber Security Coordinator. A significant cyber security incident is one that poses a material risk to the social or economic stability of Australia, the defence of Australia, or national security, or that is or could reasonably be expected to be of serious concern to the Australian people (Section 34). The information sharing is voluntary and carries strong protections: information provided under Part 4 may only be used for permitted cyber security purposes, cannot be used for civil or regulatory enforcement against the impacted entity (except for Part 4 contraventions or criminal offences), and is not admissible in evidence against the entity in most proceedings (Section 42). Part 5 establishes the Cyber Incident Review Board, which conducts reviews of significant cyber security incidents and makes recommendations to government and industry. The Board may request information from entities and may require certain entities to produce documents (with a civil penalty of 60 penalty units for non-compliance). Draft review reports must not be disclosed (Section 59). Final review reports must redact sensitive review information (Section 53). Compliance professionals should understand the Board's powers and prepare for the possibility that their organisation's incidents may be subject to review. - Consider establishing an internal protocol for voluntary information sharing with the National Cyber Security Coordinator during significant incidents. The protections in Part 4 are designed to encourage participation. - Document the admissibility and use restrictions (Sections 38, 39, 40, 41, 42) so that legal counsel and incident response teams understand what protections apply to voluntarily shared information. - Prepare for the possibility of a Cyber Incident Review Board review. Ensure incident records are structured and retrievable in case the Board requests information or documents under Sections 48 or 49. - The Board is independent (Section 63) and its members are not compellable as witnesses (Section 43). The Board publishes an annual report (Section 76). ## Regulator engagement strategies for Australia Cyber Security Act 2024 compliance Proactive regulator engagement can reduce the risk of enforcement escalation under the Australia Cyber Security Act 2024. The enforcement pathway is graduated: compliance notice, then stop notice, then recall notice, then public notification. At every stage, the Secretary must give the entity at least 10 days to make representations before issuing a notice. Effective engagement during these representation windows can shape the outcome. The Australia Cyber Security Act 2024 also provides for enforceable undertakings under Part 6 of the Regulatory Powers Act. An entity can proactively offer undertakings to comply with Sections 15 and 16, or with any civil penalty provision. This mechanism allows an entity to negotiate a structured remediation plan with the Secretary rather than face enforcement proceedings. For ransomware reporting, the Act includes a good faith liability shield (Section 28). An entity is not liable to an action or other proceeding for damages for an act done or omitted in good faith in compliance with Section 27. This protection extends to officers, employees, and agents of the entity. Legal counsel should ensure that reporting decisions and report content are documented as good faith actions. - Use the 10-day representation window actively: prepare a written submission that addresses the alleged non-compliance, presents evidence of current controls, and proposes a remediation plan with specific milestones. - If remediation is needed, consider offering an enforceable undertaking that includes measurable milestones, independent verification, and a reporting schedule to the Secretary. - Track all notice interactions in a compliance log: date of notice receipt, representation deadline, content of representations, Secretary's response, and any variation or revocation. - For internal review applications (Section 22), submit within the 30-day window with supporting evidence. The decision-maker must resolve within 30 days and provide written reasons. - Document all ransomware reporting actions as good faith compliance to preserve the liability protections in Section 28. - Maintain a relationship with the designated Commonwealth body (the Department and the Australian Signals Directorate, unless other bodies are specified by rules) to facilitate smooth reporting and incident coordination. ## Primary sources - [Cyber Security Act 2024 (Australia) official text](https://www.legislation.gov.au/C2024A00098/latest/text?ref=sorena.io) - Core statute: Part 2 smart device security standards, Part 3 ransomware payment reporting, Part 4 voluntary information sharing, Part 5 Cyber Incident Review Board, Part 6 regulatory powers including civil penalties, enforceable undertakings, monitoring, investigation, and infringement notices. - [Cyber Security (Security Standards for Smart Devices) Rules 2025 official text](https://www.legislation.gov.au/F2025L00276/asmade/text?ref=sorena.io) - Prescribes the security standard for consumer grade relevant connectable products (Schedule 1): password requirements, vulnerability reporting requirements, defined support period requirements. Also prescribes the statement of compliance content (Rule 9) and 5-year retention period (Rule 10). - [Cyber Security (Ransomware Payment Reporting) Rules 2025 official text](https://www.legislation.gov.au/F2025L00278/asmade/text?ref=sorena.io) - Sets the $3 million turnover threshold (Rule 6) and prescribes the ransomware payment report content requirements (Rule 7): entity details, incident details, demand details, payment details, and communications with the extorting entity. - [Cyber Security (Cyber Incident Review Board) Rules 2025 official text](https://www.legislation.gov.au/F2025L00277/asmade/text?ref=sorena.io) - Prescribes eligibility requirements for Board members, Expert Panel composition, and review procedures under Part 5 of the Australia Cyber Security Act 2024. - [Explanatory Statement for Smart Devices Rules 2025](https://www.legislation.gov.au/F2025L00276/asmade/explanatory-statement/text?ref=sorena.io) - Provides implementation context including the 12-month industry transition period, alignment with UK PSTI Act and ETSI EN 303 645, and the reduction of the retention period from 10 years to 5 years following stakeholder consultation. - [Explanatory Statement for Ransomware Payment Reporting Rules 2025](https://www.legislation.gov.au/F2025L00278/asmade/explanatory-statement/text?ref=sorena.io) - Confirms the education-first compliance posture of the Department of Home Affairs, the alignment of the $3 million threshold with the Privacy Act 1988, and the estimated initial compliance cost of $276.80 per entity. - [Security of Critical Infrastructure Act 2018 details](https://www.legislation.gov.au/Details/C2018A00029?ref=sorena.io) - Relevant where critical infrastructure status affects reporting business entity analysis under Section 26(2)(b) of the Australia Cyber Security Act 2024. Part 2B responsible entities are captured regardless of turnover. ## Related Topic Guides - [Australia Cyber Security Act 2024 Applicability Test | Who Must Comply](/artifacts/apac/australia-cyber-security-act/applicability-test.md): Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations. - [Australia Cyber Security Act 2024 Compliance Checklist](/artifacts/apac/australia-cyber-security-act/checklist.md): Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting. - [Australia Cyber Security Act 2024 Compliance Templates | Statement of Compliance, Ransomware Report, Evidence Pack, Vulnerability Disclosure, Support Period](/artifacts/apac/australia-cyber-security-act/templates.md): Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field. - [Australia Cyber Security Act 2024 Deadlines and Compliance Calendar | Commencement Dates](/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar.md): Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent. - [Australia Cyber Security Act 2024 FAQ | Frequently Asked Questions](/artifacts/apac/australia-cyber-security-act/faq.md): Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024. - [Australia Cyber Security Act 2024 Requirements | Smart Device and Ransomware Reporting Obligations](/artifacts/apac/australia-cyber-security-act/requirements.md): Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure. - [Australia Cyber Security Act 2024 Timeline and Commencement Dates | Full Schedule](/artifacts/apac/australia-cyber-security-act/timeline-and-commencement.md): Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024. - [Australia Cyber Security Act 2024 vs EU Cyber Resilience Act | Full CRA Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act.md): Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements. - [Australia Cyber Security Act 2024 vs UK PSTI Act | Product Security Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act.md): Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements. - [Australia Smart Device Compliance Checklist | Cyber Security Act 2024 | Sorena](/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist.md): Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure. - [Penalties and fines | Australia Cyber Security Act 2024 | 60 Penalty Units, Smart Device Enforcement, Ransomware Reporting](/artifacts/apac/australia-cyber-security-act/penalties-and-fines.md): Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals. - [Ransomware Payment Reporting in 72 Hours | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours.md): Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. - [Scope and Definitions | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/scope-and-definitions.md): Complete guide to the Australia Cyber Security Act 2024 scope and definitions. - [Smart device security standards | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/smart-device-security-standards.md): Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2. - [Statement of Compliance and Recordkeeping | Australia Cyber Security Act 2024 | Section 9, Section 10, 5 Year Retention](/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping.md): Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/australia-cyber-security-act/compliance --- --- title: "Australia Cyber Security Act 2024 vs EU Cyber Resilience Act" canonical_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act" source_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act" author: "Sorena AI" description: "Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "Australia Cyber Security Act 2024 vs EU Cyber Resilience Act" - "CRA comparison" - "smart device security standards Australia" - "cyber resilience act product scope" - "dual compliance Australia EU" - "connectable product security" - "Australia EU product security comparison" - "evidence reuse CRA Australia" - "conformity assessment CRA" - "statement of compliance Australia" - "penalties Australia Cyber Security Act" - "EU CRA penalties" - "Australia Cyber Security Act 2024" - "EU Cyber Resilience Act" - "Australia vs EU CRA" - "product security compliance" - "smart device security standards" - "dual market compliance" - "APAC compliance" - "cyber resilience regulation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Australia Cyber Security Act 2024 vs EU Cyber Resilience Act Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements. *Artifact Guide* *APAC* ## Australia Cyber Security Act 2024 vs EU Cyber Resilience Act A detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act for product security, compliance, and governance teams that need to sell connectable products into both the Australian and EU markets. Covers scope differences, product categories, security requirements, conformity assessment, incident reporting, penalties, timelines, and practical dual compliance strategies where one compliance effort can cover both regimes. The Australia Cyber Security Act 2024 and the EU Cyber Resilience Act (Regulation (EU) 2024/2847) both regulate the security of products that connect to the internet, but they differ significantly in scope, enforcement model, and market access requirements. The Australia Cyber Security Act 2024 targets a defined class of consumer grade connectable products through the Security Standards for Smart Devices Rules 2025, while also introducing a separate ransomware payment reporting obligation. The EU Cyber Resilience Act applies more broadly to all products with digital elements placed on the EU single market and uses the EU conformity assessment and CE marking framework. Teams that manufacture or supply products into both Australia and the EU should understand these differences so they can build one shared engineering evidence base and wrap it with the correct legal documentation for each jurisdiction. This CRA comparison guide explains exactly where the two regimes overlap and where they diverge. ## Legislative scope: Australia Cyber Security Act 2024 versus EU Cyber Resilience Act The Australia Cyber Security Act 2024 (No. 98, 2024) is a multi-part statute that covers product security for smart devices, ransomware payment reporting, coordination of significant cyber security incidents through the National Cyber Security Coordinator, and the establishment of the Cyber Incident Review Board. Part 2 of the Australia Cyber Security Act 2024 is the part that is most directly comparable to the EU Cyber Resilience Act because it creates mandatory security standards for relevant connectable products that will be acquired in Australia. The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is a horizontal product security regulation that applies to all products with digital elements placed on the EU market. Unlike the Australia Cyber Security Act 2024, which bundles product security together with incident coordination and ransomware reporting, the EU Cyber Resilience Act is exclusively focused on product cybersecurity across the full product lifecycle. This scope difference is the most important factor for teams doing a CRA comparison. A product team that has fully complied with the Australia Cyber Security Act 2024 smart device rules has addressed only a subset of the obligations that the EU Cyber Resilience Act imposes. Conversely, a team that has achieved EU Cyber Resilience Act compliance will find that much of the engineering evidence already satisfies the Australian requirements. - The Australia Cyber Security Act 2024 received Royal Assent on 29 November 2024 and is structured across seven parts covering preliminary provisions, smart device security standards, ransomware reporting, incident coordination, the Cyber Incident Review Board, regulatory powers, and miscellaneous matters. - The EU Cyber Resilience Act entered into force on 10 December 2024 and applies horizontally to products with digital elements, including hardware and software, placed on the EU single market. - Part 2 of the Australia Cyber Security Act 2024 (security standards for smart devices) commenced on 29 November 2025, while the Security Standards for Smart Devices Rules 2025 take substantive effect from 4 March 2026. - The EU Cyber Resilience Act has a phased timeline: vulnerability and incident reporting obligations apply from 11 September 2026, and the full set of essential cybersecurity requirements apply from 11 December 2027. - The Australia Cyber Security Act 2024 also includes Part 3 (ransomware payment reporting from 29 May 2025) and Part 4 (voluntary information sharing with the National Cyber Security Coordinator from 30 November 2024), which have no equivalent in the EU Cyber Resilience Act. ## Product categories and what is in scope under each regime The Australia Cyber Security Act 2024 defines a 'relevant connectable product' as any product that is an internet-connectable product or a network-connectable product and is not exempted by the rules. An internet-connectable product is one that can connect to the internet using a protocol that forms part of the internet protocol suite. A network-connectable product is one that can send and receive data by electrical or electromagnetic means, is not itself internet-connectable, but can connect directly to an internet-connectable product or to two or more products simultaneously via non-IP protocols. The Security Standards for Smart Devices Rules 2025 then narrow the first regulated class further to consumer grade relevant connectable products that are intended for personal, domestic, or household use. The Security Standards for Smart Devices Rules 2025 explicitly exclude desktop computers, laptops, tablet computers, smartphones, therapeutic goods (under the Therapeutic Goods Act 1989), road vehicles, and road vehicle components from the initial regulated product class. This means the Australia Cyber Security Act 2024 smart device rules currently cover items such as smart home hubs, connected cameras, smart speakers, IoT sensors, connected appliances, baby monitors, smart locks, and similar consumer IoT products. The EU Cyber Resilience Act takes a much broader approach. It applies to all 'products with digital elements' placed on the EU market, meaning any software or hardware product and its remote data processing solutions. The EU Cyber Resilience Act classifies products into a default category, an 'important' category (Class I and Class II in Annex III), and a 'critical' category (Annex IV). Important Class I products include identity management systems, browsers, password managers, VPNs, network management tools, firewalls, routers, modems, switches, and operating systems. Important Class II products include hypervisors, container runtime systems, public key infrastructure, and secure element software. Critical products include hardware security modules, smart cards, and smart meter gateways. This CRA comparison shows that the product scope under the EU Cyber Resilience Act is substantially larger than the product scope under the Australia Cyber Security Act 2024. The EU Cyber Resilience Act covers enterprise software, operating systems, development tools, network infrastructure, and industrial products. The Australia Cyber Security Act 2024 currently covers only consumer grade connectable products, though the Act gives the Minister power to expand the product classes over time through additional rules. - Australia Cyber Security Act 2024 currently regulates consumer grade relevant connectable products: products intended for personal, domestic, or household use that connect directly or indirectly to the internet. - Australia excludes desktops, laptops, tablets, smartphones, therapeutic goods, road vehicles, and road vehicle components from the current smart device product class. - The EU Cyber Resilience Act covers all products with digital elements placed on the EU market, including hardware, software, and remote data processing solutions, with no consumer-only limitation. - The EU Cyber Resilience Act uses a tiered classification: default products, important products (Class I and Class II), and critical products, each with different conformity assessment requirements. - The Australia Cyber Security Act 2024 allows the Minister to prescribe additional product classes through future rules, so the Australian product scope may expand over time. - Both regimes apply to manufacturers and suppliers, but the EU Cyber Resilience Act also imposes specific obligations on importers and distributors as part of the EU product compliance chain. ## Security requirements: Australia smart device standards versus EU Cyber Resilience Act essential requirements The Security Standards for Smart Devices Rules 2025 (Schedule 1, Part 1) prescribe three categories of mandatory security requirements for consumer grade relevant connectable products under the Australia Cyber Security Act 2024. These three categories are: requirements in relation to passwords, requirements relating to reports of security issues, and requirements relating to defined support periods and security updates. These requirements are closely aligned with the ETSI EN 303 645 baseline standard and the UK Product Security and Telecommunications Infrastructure Act 2022. For passwords, the Australia Cyber Security Act 2024 rules require that all passwords for hardware and software of a relevant connectable product must be either unique per product or defined by the user. Passwords that are unique per product must not be based on incremental counters, must not be based on or derived from publicly available information, and must not be based on unique product identifiers such as serial numbers unless an encryption method or keyed hashing algorithm accepted as good industry practice is used. This means universal default passwords such as 'admin' or 'password' are prohibited under the Australia Cyber Security Act 2024. For vulnerability reporting, the Australia Cyber Security Act 2024 rules require that the manufacturer of a relevant connectable product must publish at least one point of contact for reporting security issues, state when a reporter will receive acknowledgement, and provide status updates until resolution. This information must be accessible, clear, transparent, available without prior request, in English, free of charge, and must not require the reporter to provide personal information. For defined support periods, the Australia Cyber Security Act 2024 rules require that the manufacturer must publish the period during which security updates will be provided. The defined support period must be expressed as a time period with an end date. The manufacturer must not shorten the defined support period after publication. If extended, the new period must be published as soon as practicable. When the product is offered on a website, the support period must be published with equal prominence alongside the main product characteristics. The EU Cyber Resilience Act imposes a much more extensive set of essential cybersecurity requirements listed in Annex I. These include secure by design and by default, protection of confidentiality, integrity, and availability, minimisation of data processing, vulnerability handling throughout the lifecycle, provision of security updates for at least five years or the expected product lifetime, SBOM (software bill of materials) documentation, and coordinated vulnerability disclosure. The EU Cyber Resilience Act also requires that products be delivered with a secure default configuration, that all known exploitable vulnerabilities are addressed before placing on the market, and that manufacturers implement a documented vulnerability handling process. This CRA comparison reveals that the three Australian requirements (passwords, vulnerability contact, support period) represent a focused subset of the EU Cyber Resilience Act essential requirements. A team that satisfies the EU Cyber Resilience Act Annex I requirements will generally also satisfy the Australia Cyber Security Act 2024 smart device standards, but a team that only satisfies the Australian standards will still need significant additional work to meet the EU Cyber Resilience Act. - Australia Cyber Security Act 2024: passwords must be unique per product or user defined. Universal defaults are prohibited. Passwords unique per product must not use incremental counters or publicly available information. - Australia Cyber Security Act 2024: manufacturers must publish a security issue contact point, provide acknowledgement timelines, and give status updates through to resolution. - Australia Cyber Security Act 2024: manufacturers must publish a defined support period expressed as a time period with an end date. The period must not be shortened after publication. - EU Cyber Resilience Act: products must be designed, developed, and produced to ensure an appropriate level of cybersecurity based on risk. Products must be delivered without known exploitable vulnerabilities. - EU Cyber Resilience Act: manufacturers must implement and document a vulnerability handling process, provide security updates for at least five years, and maintain an SBOM covering at minimum the top-level dependencies of the product. - EU Cyber Resilience Act: additional requirements include secure default configuration, data minimisation, protection against unauthorised access, encrypted storage and communication where appropriate, and reduction of attack surfaces. - Overlap area: both regimes require non-default credentials, a working vulnerability intake process, and a published support period. These three areas form the shared engineering baseline. ## Conformity assessment and compliance documentation The Australia Cyber Security Act 2024 uses a statement of compliance model. Under Section 16 of the Act and Section 9 of the Security Standards for Smart Devices Rules 2025, the manufacturer of a relevant connectable product must prepare a statement of compliance that includes the product type and batch identifier, the name and address of the manufacturer and any authorised representatives in Australia, a declaration that the statement was prepared by or on behalf of the manufacturer, a declaration that the product was manufactured in compliance with the security standard, the defined support period at the date of issue, the signature and details of the signatory, and the place and date of issue. Both manufacturers and suppliers must retain a copy of the statement of compliance for a period of five years. The EU Cyber Resilience Act uses the established EU conformity assessment framework. For default category products, manufacturers may use Module A (internal production control), which is essentially a self-assessment with technical documentation. For important products in Class I, manufacturers may use Module A or harmonised standards with third-party involvement. For important products in Class II and for critical products, third-party conformity assessment by a notified body is required. Successful conformity assessment results in the application of the CE marking, which is the legal prerequisite for placing the product on the EU market. The EU Cyber Resilience Act also requires manufacturers to prepare and maintain technical documentation that demonstrates conformity with the essential cybersecurity requirements. This technical documentation must include a general description of the product, design and development information, cybersecurity risk assessment, vulnerability handling documentation, test reports, the SBOM, the EU declaration of conformity, and details of any applied harmonised standards or common specifications. In this CRA comparison, the Australian statement of compliance is simpler and more declarative than the EU conformity assessment process. The Australian model requires a manufacturer declaration and basic product identification. The EU model requires detailed technical documentation, risk assessment, and, for higher-risk product categories, independent assessment by a notified body. Teams that build comprehensive EU Cyber Resilience Act technical documentation will easily generate an Australian statement of compliance from the same evidence base, but the reverse is not true. - Australia Cyber Security Act 2024: manufacturers issue a statement of compliance declaring the product meets the security standard. The statement includes product identification, manufacturer details, the defined support period, and a signed declaration. - Australia Cyber Security Act 2024: both manufacturers and suppliers must retain the statement of compliance for five years. - EU Cyber Resilience Act: default products use Module A self-assessment. Important Class I products may use Module A or third-party assessment. Important Class II and critical products require notified body involvement. - EU Cyber Resilience Act: manufacturers must prepare and maintain technical documentation including risk assessment, design details, test reports, SBOM, and a formal EU declaration of conformity. - EU Cyber Resilience Act: successful conformity assessment leads to CE marking, which is the legal gate for EU market access. - Practical overlap: the factual evidence that supports an EU declaration of conformity (design records, test results, vulnerability handling procedures, support period commitments) can be directly referenced in the Australian statement of compliance. ## Incident reporting and vulnerability disclosure obligations The Australia Cyber Security Act 2024 does not impose product-level vulnerability or incident reporting obligations on manufacturers of smart devices. Instead, the Act addresses incident reporting through two separate mechanisms: Part 3 imposes a ransomware payment reporting obligation on qualifying business entities, and Part 4 enables voluntary information sharing with the National Cyber Security Coordinator for significant cyber security incidents. These reporting mechanisms are not tied to the smart device product regime in Part 2. Under Part 3 of the Australia Cyber Security Act 2024, a reporting business entity must give the designated Commonwealth body a ransomware payment report within 72 hours of making or becoming aware of a ransomware payment. A reporting business entity is one that carries on a business in Australia with an annual turnover above the prescribed threshold and is not a Commonwealth body, State body, or critical infrastructure asset responsible entity (unless the entity is a responsible entity for a critical infrastructure asset to which Part 2B of the Security of Critical Infrastructure Act 2018 applies). The ransomware payment report must contain information about the business entity, the cyber security incident, the demand, the payment, and communications with the extorting entity. The EU Cyber Resilience Act imposes direct incident and vulnerability reporting obligations on manufacturers. Starting 11 September 2026, manufacturers must notify ENISA (the EU Agency for Cybersecurity) of any actively exploited vulnerability in their product within 24 hours of becoming aware, followed by a full notification within 72 hours. Manufacturers must also notify ENISA of any severe incident that impacts the security of the product within 24 hours. These reporting obligations run throughout the expected product lifetime or the support period, whichever is longer. The EU Cyber Resilience Act also requires manufacturers to inform users without undue delay about actively exploited vulnerabilities and about security incidents that impact the product. Manufacturers must describe the vulnerability or incident, the risk to users, and the corrective measures that have been taken or can be taken. This CRA comparison shows that the incident reporting obligations are structurally different between the two regimes. The Australia Cyber Security Act 2024 addresses ransomware payments at the business entity level, not at the product level. The EU Cyber Resilience Act addresses vulnerabilities and incidents at the product level through direct manufacturer reporting to ENISA. A team complying with both regimes needs two separate reporting workflows: one for the EU Cyber Resilience Act product vulnerability and incident reports to ENISA, and one for any ransomware payment reporting obligations that may apply under the Australia Cyber Security Act 2024. - Australia Cyber Security Act 2024 Part 2 (smart devices): no product-level vulnerability or incident reporting obligation on manufacturers. - Australia Cyber Security Act 2024 Part 3: reporting business entities must report ransomware payments to the designated Commonwealth body within 72 hours. This obligation applies to businesses above the annual turnover threshold. - Australia Cyber Security Act 2024 Part 3: the ransomware payment report must cover entity details, the cyber security incident, the demand, the payment, and communications with the attacker. - EU Cyber Resilience Act: manufacturers must report actively exploited vulnerabilities to ENISA within 24 hours (early warning) and 72 hours (full notification) from 11 September 2026. - EU Cyber Resilience Act: manufacturers must also report severe incidents that impact product security to ENISA within the same timeframes. - EU Cyber Resilience Act: manufacturers must notify users of actively exploited vulnerabilities and incidents without undue delay, including the corrective measures available. - The two reporting obligations are independent. EU Cyber Resilience Act reporting is about product vulnerabilities. Australia Cyber Security Act 2024 Part 3 reporting is about ransomware payments at the business level. ## Enforcement mechanisms and penalties The Australia Cyber Security Act 2024 provides an escalating enforcement pathway for the smart device regime in Part 2. If the Secretary is reasonably satisfied that a manufacturer or supplier is not complying with security standard or statement of compliance obligations under Sections 15 or 16, the Secretary may issue a compliance notice specifying the non-compliance and the actions required. If the compliance notice is not addressed, the Secretary may issue a stop notice requiring the entity to stop or take further corrective action. If the stop notice is not addressed, the Secretary may issue a recall notice requiring the entity to prevent further supply in Australia and arrange for the return of products. Before issuing any notice, the Secretary must give the entity at least 10 days to make representations. If an entity fails to comply with a recall notice under the Australia Cyber Security Act 2024, the Minister may publicly disclose the entity's identity, details of the product, details of the non-compliance, and the risks posed. The Act also provides civil penalty enforcement through the Regulatory Powers (Standard Provisions) Act 2014. Civil penalty provisions carry a penalty of 60 penalty units. In Australia, one penalty unit for a body corporate is five times the base amount, and the base penalty unit value is AUD 313 (as of 2024-2025), meaning 60 penalty units for an individual is AUD 18,780. For a body corporate the maximum is five times that amount per contravention. The Secretary may also engage an independent expert to examine a product to determine whether it complies with the security standard and whether the statement of compliance meets requirements. The entity is entitled to reasonable compensation for providing the product for examination. The EU Cyber Resilience Act provides for market surveillance authorities in each EU member state to enforce the regulation. Penalties under the EU Cyber Resilience Act are significantly higher. For non-compliance with the essential cybersecurity requirements in Annex I, member states must provide for administrative fines of up to EUR 15,000,000 or 2.5% of the worldwide annual turnover, whichever is higher. For non-compliance with other obligations, fines of up to EUR 10,000,000 or 2% of worldwide annual turnover apply. For providing incorrect, incomplete, or misleading information to authorities or notified bodies, fines of up to EUR 5,000,000 or 1% of worldwide annual turnover apply. EU market surveillance authorities can also order corrective measures, require product withdrawal or recall from the market, restrict or prohibit the making available of the product, and require the CE marking to be removed. The EU Cyber Resilience Act builds on the EU market surveillance regulation (Regulation (EU) 2019/1020) to coordinate enforcement across member states. In this CRA comparison the EU Cyber Resilience Act penalty regime is far more severe. The Australian penalty structure uses relatively modest civil penalty units appropriate for a focused consumer device regime. The EU Cyber Resilience Act penalty structure uses percentage-of-turnover fines comparable to the GDPR, reflecting the broader product scope and the importance the EU places on horizontal product cybersecurity. - Australia Cyber Security Act 2024: the enforcement escalation for smart devices is compliance notice, then stop notice, then recall notice. Each requires at least 10 days for the entity to make representations before issuance. - Australia Cyber Security Act 2024: civil penalty provisions carry 60 penalty units per contravention. For a body corporate, this amounts to approximately AUD 93,900 per contravention at current rates. - Australia Cyber Security Act 2024: failure to comply with a recall notice can result in public disclosure of the entity's identity, product details, and the risks to consumers. - Australia Cyber Security Act 2024: the Secretary can commission independent product examinations and has monitoring and investigation powers under the Regulatory Powers Act. - EU Cyber Resilience Act: administrative fines for essential requirement non-compliance are up to EUR 15,000,000 or 2.5% of worldwide annual turnover, whichever is higher. - EU Cyber Resilience Act: fines for other obligation non-compliance are up to EUR 10,000,000 or 2% of worldwide annual turnover. Fines for misleading information are up to EUR 5,000,000 or 1% of turnover. - EU Cyber Resilience Act: market surveillance authorities can order withdrawal, recall, prohibition of product sales, and removal of CE marking. - The EU Cyber Resilience Act penalty regime is substantially larger in financial terms than the Australia Cyber Security Act 2024 civil penalty regime. ## Timelines and key dates for dual compliance planning Teams that sell connected products into both Australia and the EU must track two sets of compliance deadlines. The Australia Cyber Security Act 2024 has already commenced in stages. Part 1 (preliminary) and Part 4 (incident coordination) commenced on 30 November 2024. Part 3 (ransomware payment reporting) and Part 5 (Cyber Incident Review Board) commenced on 29 May 2025. Part 2 (security standards for smart devices) commenced on 29 November 2025. The Security Standards for Smart Devices Rules 2025 were registered on 4 March 2025, with the substantive security standard in Schedule 1 taking effect on 4 March 2026. The EU Cyber Resilience Act entered into force on 10 December 2024. The reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026. The full set of essential cybersecurity requirements and conformity assessment obligations apply from 11 December 2027. Obligations related to notified bodies apply from 11 June 2026. For teams planning dual compliance, the practical sequencing is as follows. The Australian smart device security standard (passwords, vulnerability contact, support period) is enforceable from 4 March 2026. EU Cyber Resilience Act vulnerability and incident reporting to ENISA begins on 11 September 2026. The full EU Cyber Resilience Act essential cybersecurity requirements, technical documentation, and conformity assessment obligations apply from 11 December 2027. This means teams have an immediate need to address the Australia Cyber Security Act 2024 smart device rules for the Australian market, while building toward full EU Cyber Resilience Act compliance by late 2027. - 30 November 2024: Australia Cyber Security Act 2024 Parts 1, 4, 6, and 7 commenced (preliminary, incident coordination, regulatory powers). - 29 May 2025: Australia Cyber Security Act 2024 Parts 3 and 5 commenced (ransomware reporting, Cyber Incident Review Board). - 29 November 2025: Australia Cyber Security Act 2024 Part 2 commenced (security standards for smart devices). - 4 March 2026: Security Standards for Smart Devices Rules 2025 Schedule 1 takes substantive effect. Manufacturers and suppliers of consumer grade relevant connectable products must comply with password, vulnerability reporting, and support period requirements. - 11 June 2026: EU Cyber Resilience Act notified body obligations apply. - 11 September 2026: EU Cyber Resilience Act vulnerability and incident reporting obligations apply. Manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA. - 11 December 2027: EU Cyber Resilience Act essential cybersecurity requirements, conformity assessment, technical documentation, CE marking, and all remaining obligations fully apply. ## Where one compliance effort covers both regimes Despite the differences in scope and detail between the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act, there are significant areas of overlap where a single compliance effort can support both markets. These overlap areas reduce duplication and allow teams to build shared engineering evidence that satisfies both the Australian smart device standards and the EU Cyber Resilience Act essential requirements. The strongest overlap is in credential management. The Australia Cyber Security Act 2024 requires unique per-product passwords or user-defined passwords and prohibits universal defaults. The EU Cyber Resilience Act requires products to be delivered without known default passwords and with secure authentication mechanisms. A product team that implements unique per-device credentials with proper cryptographic derivation will satisfy both requirements simultaneously. Vulnerability handling is the second major overlap. The Australia Cyber Security Act 2024 requires a published contact point for security issue reports, acknowledgement timelines, and status updates through resolution. The EU Cyber Resilience Act requires a documented vulnerability handling process, coordinated vulnerability disclosure, and active vulnerability remediation. A team that builds a full vulnerability handling program to EU Cyber Resilience Act standards will easily satisfy the Australian vulnerability reporting contact requirements, because the EU requirements are a superset of the Australian ones. Support period transparency is the third overlap. The Australia Cyber Security Act 2024 requires a published defined support period with an end date that cannot be shortened. The EU Cyber Resilience Act requires security updates for at least five years or the expected product lifetime, whichever is longer. A team that commits to a defined support period that meets the EU Cyber Resilience Act minimum will also satisfy the Australian publication requirement. Beyond these three requirement-level overlaps, product design evidence such as threat models, architecture reviews, secure development lifecycle documentation, penetration test reports, and code review records can serve as shared evidence for both the Australian statement of compliance and the EU technical documentation file. - Credential management: unique per-device passwords or user-defined passwords satisfy both the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act. - Vulnerability handling: a documented vulnerability intake, triage, remediation, and disclosure process satisfies both regimes. The EU Cyber Resilience Act requirements are the more comprehensive set. - Support period: a published support period with an end date that meets the EU Cyber Resilience Act five-year minimum also satisfies the Australia Cyber Security Act 2024 defined support period requirement. - Design evidence: threat models, secure development lifecycle records, test reports, and architecture reviews can support both the Australian statement of compliance and the EU technical documentation file. - Secure defaults: products shipped without default passwords and with secure configuration settings satisfy both regimes. - Security update infrastructure: a reliable update delivery mechanism serves both the Australian support period commitment and the EU Cyber Resilience Act update obligation. ## Where compliance efforts must remain separate While shared engineering evidence is valuable, certain compliance activities remain specific to each regime and cannot be merged. Teams must maintain separate processes for these jurisdiction-specific obligations to avoid gaps in either market. The EU Cyber Resilience Act requires conformity assessment, CE marking, and an EU declaration of conformity. These concepts do not exist under the Australia Cyber Security Act 2024. Teams selling into the EU must complete the appropriate conformity assessment procedure (Module A for default products, or notified body assessment for higher-risk categories), affix the CE mark, and issue a formal declaration of conformity. None of these steps are required or recognised under Australian law. The Australia Cyber Security Act 2024 requires a specific statement of compliance that must be prepared by or on behalf of the manufacturer. This statement has prescribed content including the product type, batch identifier, manufacturer details, authorised representative details, the defined support period, and a signed declaration. This statement format is unique to the Australian regime and is not equivalent to an EU declaration of conformity. The EU Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities and severe incidents to ENISA starting 11 September 2026. The Australia Cyber Security Act 2024 does not require product-level vulnerability or incident reporting from manufacturers of smart devices. Instead, Australia has a separate ransomware payment reporting obligation that applies at the business entity level. The EU Cyber Resilience Act requires manufacturers to prepare and maintain an SBOM. The Australia Cyber Security Act 2024 does not currently require an SBOM. The EU Cyber Resilience Act imposes obligations on importers and distributors in the EU supply chain. The Australia Cyber Security Act 2024 imposes obligations on manufacturers and suppliers, using the Australian Consumer Law definitions of those terms. - EU only: conformity assessment procedure (Module A or notified body assessment), CE marking, and EU declaration of conformity. - EU only: vulnerability and incident reporting to ENISA within 24 and 72 hours. - EU only: SBOM preparation and maintenance. - EU only: obligations on importers and distributors in the EU supply chain. - Australia only: statement of compliance in the prescribed format with product type, batch identifier, manufacturer and authorised representative details, defined support period, and signed declaration. - Australia only: five-year retention obligation for the statement of compliance by both manufacturers and suppliers. - Australia only: ransomware payment reporting within 72 hours for qualifying business entities under Part 3. - Australia only: escalating enforcement pathway of compliance notice, stop notice, and recall notice with public disclosure for recall non-compliance. ## Practical dual compliance strategy for teams selling into both markets The most effective approach for teams that need to comply with both the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act is a layered compliance model with a shared engineering evidence base and separate legal and regulatory wrappers for each jurisdiction. The shared engineering evidence base should include secure product design documentation (threat models, architecture reviews, security design decisions), credential management evidence (how unique per-device passwords are generated, how default credentials are eliminated), vulnerability handling program documentation (intake process, triage criteria, remediation workflow, disclosure policy, contact information), security update infrastructure documentation (update delivery mechanism, support period commitments, end-of-support planning), test evidence (penetration test reports, security functional testing, regression testing), and secure development lifecycle records (code review processes, dependency management, build integrity checks). The Australian compliance wrapper should include the statement of compliance in the format prescribed by Section 9 of the Security Standards for Smart Devices Rules 2025, records showing that the product falls within the consumer grade relevant connectable product class (or a future class defined by additional rules), evidence of compliance with each of the three schedule requirements (passwords, vulnerability reporting contact, defined support period), supply chain documentation confirming that the statement of compliance accompanies the product when supplied in Australia, and records demonstrating the five-year retention of the statement of compliance. The EU compliance wrapper should include the technical documentation file required by the EU Cyber Resilience Act (covering all essential cybersecurity requirements in Annex I), the conformity assessment records (internal production control under Module A, or notified body assessment records for higher-risk products), the EU declaration of conformity, CE marking application records, the SBOM, the vulnerability and incident reporting procedures for ENISA notification, and the user notification procedures for actively exploited vulnerabilities. A single governance review before each product launch should verify that both the Australian and EU wrappers are complete and that the underlying engineering evidence base supports the claims made in each wrapper. This approach avoids duplication of engineering effort while ensuring that each jurisdiction's specific legal requirements are met. - Layer 1 (shared): secure design evidence, credential management, vulnerability handling, update infrastructure, test reports, and secure development lifecycle records. - Layer 2 (Australia): statement of compliance, product class analysis, schedule requirement evidence, supply documentation, and five-year retention records. - Layer 2 (EU): technical documentation file, conformity assessment records, EU declaration of conformity, CE marking, SBOM, ENISA reporting procedures, and user notification procedures. - Layer 3 (governance): a single pre-launch review that checks both jurisdiction wrappers against the shared evidence base. - Start with the EU Cyber Resilience Act requirements as the more comprehensive baseline. Map the Australian requirements against that baseline to confirm coverage. Add the Australian-specific documentation on top. - Maintain a compliance mapping table that traces each Australia Cyber Security Act 2024 requirement and each EU Cyber Resilience Act essential requirement to specific evidence artifacts in the shared engineering base. ## Comparison summary table: Australia Cyber Security Act 2024 versus EU Cyber Resilience Act The following summary captures the key comparison points between the Australia Cyber Security Act 2024 smart device regime and the EU Cyber Resilience Act. This table format is designed for product security, compliance, and legal teams that need a quick reference when planning dual-market product launches. - Product scope: Australia covers consumer grade relevant connectable products (excluding desktops, laptops, tablets, smartphones, therapeutic goods, and vehicles). The EU Cyber Resilience Act covers all products with digital elements including software, hardware, and remote data processing solutions. - Security requirements: Australia mandates three requirements (passwords, vulnerability contact, support period). The EU Cyber Resilience Act mandates comprehensive essential cybersecurity requirements covering design, development, production, vulnerability handling, updates, SBOM, and secure defaults. - Compliance documentation: Australia requires a statement of compliance retained for five years. The EU Cyber Resilience Act requires technical documentation, an EU declaration of conformity, and CE marking. - Conformity assessment: Australia uses a manufacturer self-declaration model. The EU Cyber Resilience Act uses self-assessment (Module A) for default products and notified body assessment for important Class II and critical products. - Incident reporting: Australia Part 2 (smart devices) has no product-level vulnerability or incident reporting. Australia Part 3 requires ransomware payment reporting within 72 hours. The EU Cyber Resilience Act requires vulnerability and incident reporting to ENISA within 24 and 72 hours. - Penalties: Australia uses civil penalties of 60 penalty units per contravention plus escalating enforcement notices. The EU Cyber Resilience Act uses fines of up to EUR 15,000,000 or 2.5% of global turnover. - Timeline: Australia smart device rules are enforceable from 4 March 2026. EU Cyber Resilience Act reporting obligations apply from 11 September 2026, and full requirements apply from 11 December 2027. - Evidence reuse potential: high for credential management, vulnerability handling, and support period transparency. Low for conformity assessment procedures, SBOM, and incident reporting to ENISA. *Recommended next step* *Placement: after the comparison section* ## Use Australia Cyber Security Act 2024 vs EU Cyber Resilience Act as a cited research workflow Research Copilot can take Australia Cyber Security Act 2024 vs EU Cyber Resilience Act from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on Australia Cyber Security Act 2024 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Australia Cyber Security Act 2024 vs EU Cyber Resilience Act](/solutions/research-copilot.md): Start from Australia Cyber Security Act 2024 vs EU Cyber Resilience Act and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Australia Cyber Security Act 2024](/contact.md): Review your current process, evidence gaps, and next steps for Australia Cyber Security Act 2024 vs EU Cyber Resilience Act. ## Primary sources - [Cyber Security Act 2024 (No. 98, 2024) official consolidated text](https://www.legislation.gov.au/C2024A00098/latest/text?ref=sorena.io) - Primary legislative source for the Australia Cyber Security Act 2024 covering smart device security standards, ransomware payment reporting, incident coordination, and the Cyber Incident Review Board. - [Cyber Security (Security Standards for Smart Devices) Rules 2025 official text](https://www.legislation.gov.au/F2025L00276/asmade/text?ref=sorena.io) - Subordinate legislation under the Australia Cyber Security Act 2024 prescribing the security standard for consumer grade relevant connectable products, including password, vulnerability reporting, and support period requirements. - [Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (EU Cyber Resilience Act)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Official EU Cyber Resilience Act text on EUR-Lex covering essential cybersecurity requirements, conformity assessment, vulnerability handling, incident reporting, and penalties for products with digital elements. ## Related Topic Guides - [Australia Cyber Security Act 2024 Applicability Test | Who Must Comply](/artifacts/apac/australia-cyber-security-act/applicability-test.md): Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations. - [Australia Cyber Security Act 2024 Compliance Checklist](/artifacts/apac/australia-cyber-security-act/checklist.md): Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting. - [Australia Cyber Security Act 2024 Compliance Guide | Implementation Playbook](/artifacts/apac/australia-cyber-security-act/compliance.md): A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements. - [Australia Cyber Security Act 2024 Compliance Templates | Statement of Compliance, Ransomware Report, Evidence Pack, Vulnerability Disclosure, Support Period](/artifacts/apac/australia-cyber-security-act/templates.md): Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field. - [Australia Cyber Security Act 2024 Deadlines and Compliance Calendar | Commencement Dates](/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar.md): Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent. - [Australia Cyber Security Act 2024 FAQ | Frequently Asked Questions](/artifacts/apac/australia-cyber-security-act/faq.md): Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024. - [Australia Cyber Security Act 2024 Requirements | Smart Device and Ransomware Reporting Obligations](/artifacts/apac/australia-cyber-security-act/requirements.md): Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure. - [Australia Cyber Security Act 2024 Timeline and Commencement Dates | Full Schedule](/artifacts/apac/australia-cyber-security-act/timeline-and-commencement.md): Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024. - [Australia Cyber Security Act 2024 vs UK PSTI Act | Product Security Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act.md): Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements. - [Australia Smart Device Compliance Checklist | Cyber Security Act 2024 | Sorena](/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist.md): Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure. - [Penalties and fines | Australia Cyber Security Act 2024 | 60 Penalty Units, Smart Device Enforcement, Ransomware Reporting](/artifacts/apac/australia-cyber-security-act/penalties-and-fines.md): Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals. - [Ransomware Payment Reporting in 72 Hours | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours.md): Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. - [Scope and Definitions | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/scope-and-definitions.md): Complete guide to the Australia Cyber Security Act 2024 scope and definitions. - [Smart device security standards | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/smart-device-security-standards.md): Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2. - [Statement of Compliance and Recordkeeping | Australia Cyber Security Act 2024 | Section 9, Section 10, 5 Year Retention](/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping.md): Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act --- --- title: "Australia Cyber Security Act 2024 vs UK PSTI Act" canonical_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act" source_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act" author: "Sorena AI" description: "Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "Australia Cyber Security Act 2024 vs UK PSTI Act" - "product security comparison Australia UK" - "connectable products Australia UK compliance" - "smart device security standard comparison" - "ETSI EN 303 645 Australia" - "statement of compliance Australia" - "Australia Cyber Security Act 2024 enforcement" - "UK PSTI Act penalties" - "dual compliance Australia UK product security" - "Australia Cyber Security Act 2024 password requirements" - "UK PSTI Act vulnerability disclosure" - "Australia Cyber Security Act 2024 support period" - "consumer grade relevant connectable products" - "product security comparison" - "consumer connectable products" - "smart device security standards" - "ETSI EN 303 645" - "dual compliance Australia UK" - "APAC product security" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Australia Cyber Security Act 2024 vs UK PSTI Act Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements. *Artifact Guide* *APAC* ## Australia Cyber Security Act 2024 Cyber Security Act vs UK PSTI Act A detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act for manufacturers and suppliers of connectable products. Both regimes target the same three baseline controls (passwords, vulnerability disclosure, and support periods) but differ in scope exclusions, enforcement mechanisms, statement of compliance requirements, and civil penalty structures. The Australia Cyber Security Act 2024 and the UK PSTI Act both establish mandatory product security baselines for consumer connectable products. Both regimes share a common origin in the ETSI EN 303 645 standard and require manufacturers to address the same three core controls: eliminating weak default passwords, publishing a vulnerability disclosure route, and declaring a defined support period. However, the Australia Cyber Security Act 2024 and the UK PSTI Act differ in important ways. They have different product scope exclusions, different enforcement escalation paths, different statement of compliance requirements, and different penalty structures. This product security comparison page explains exactly where the Australia Cyber Security Act 2024 and the UK PSTI Act overlap, where they diverge, and how manufacturers and suppliers can build one product security baseline that satisfies both markets with minimal rework. ## Shared ETSI EN 303 645 foundation for the Australia Cyber Security Act 2024 and the UK PSTI Act Both the Australia Cyber Security Act 2024 and the UK PSTI Act derive their technical security requirements from the first three provisions of the ETSI EN 303 645 standard (Cyber Security for Consumer Internet of Things: Baseline Requirements). The Australian Government Explanatory Statement confirms that Schedule 1, Part 1 of the Cyber Security (Security Standards for Smart Devices) Rules 2025 closely follows the Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023 (UK). This shared origin is the most important fact in any product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act. The three mandated ETSI EN 303 645 provisions are Provision 5.1 (no universal default passwords), Provision 5.2 (implement a means to manage reports of security vulnerabilities), and Provision 5.3 (keep software updated with a defined support period). UK modelling found that implementing these three provisions could reduce the probability of attacks on consumer smart devices by between 20 and 70 per cent. The Australian Signals Directorate confirmed these are also the highest priority technical controls for the Australian market. Product teams that already comply with the UK PSTI Act will find that most of their engineering controls transfer directly to the Australia Cyber Security Act 2024 product security comparison. The practical strategy is to build one shared evidence pack covering product design, testing, vulnerability handling, and update support, then add separate compliance documentation for each market. - Both the Australia Cyber Security Act 2024 and UK PSTI Act mandate ETSI EN 303 645 Provision 5.1: no universal default passwords. - Both regimes mandate ETSI EN 303 645 Provision 5.2: a published vulnerability disclosure policy with contact channels and response commitments. - Both regimes mandate ETSI EN 303 645 Provision 5.3: defined support periods for security updates with a fixed end date. - The Australian Explanatory Statement confirms the Smart Devices Rules 2025 closely follow the UK PSTI Regulations 2023. - UK modelling estimated a 20 to 70 per cent reduction in smart device attack probability from these three controls. - The Australian Signals Directorate confirmed the same three ETSI EN 303 645 provisions are the highest priority technical controls. ## Product scope: what the Australia Cyber Security Act 2024 and the UK PSTI Act each cover Both the Australia Cyber Security Act 2024 and the UK PSTI Act apply to products that can connect directly or indirectly to the internet. The Australia Cyber Security Act 2024 defines these as relevant connectable products and splits them into two categories. Internet-connectable products are products capable of connecting to the internet using a communication protocol that forms part of the internet protocol suite to send and receive data over the internet (Section 13(4) of the Act). Network-connectable products are products capable of both sending and receiving data by means of electrical or electromagnetic energy that are not internet-connectable products but that can connect directly to an internet-connectable product via an internet protocol or can connect directly to two or more products at the same time via a non-internet protocol and also to an internet-connectable product (Section 13(5) to (7) of the Act). The UK PSTI Act uses materially similar definitions for its two categories of connectable products. The Australia Cyber Security Act 2024 security standard applies specifically to consumer grade relevant connectable products. Under Section 8 of the Cyber Security (Security Standards for Smart Devices) Rules 2025, a consumer grade product is one that is intended by the manufacturer to be used, or is of a kind likely to be used, for personal, domestic or household use or consumption, and that is acquired in Australia by a consumer. The term consumer is defined by reference to section 3 of the Australian Consumer Law. The product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act becomes critical at the exclusion list. The Australia Cyber Security Act 2024 Rules exclude desktop computers, laptops, tablet computers, smartphones, therapeutic goods (under the Therapeutic Goods Act 1989), road vehicles, and road vehicle components (under the Road Vehicle Standards Act 2018). The UK PSTI Act has its own set of exceptions under the 2023 Regulations. Manufacturers must check both exclusion lists independently because a product excluded from the Australia Cyber Security Act 2024 may still be in scope for the UK PSTI Act, and the reverse. Consumer energy resources such as solar inverters and connected batteries are within scope of the Australia Cyber Security Act 2024, and the Australian Government found that all major CER original equipment manufacturers examined also supplied products to the UK market. - The Australia Cyber Security Act 2024 applies to relevant connectable products that are internet-connectable or network-connectable, manufactured or supplied (not second hand) on or after commencement of Part 2. - The Australia Cyber Security Act 2024 consumer grade security standard excludes desktops, laptops, tablets, smartphones, therapeutic goods, road vehicles, and road vehicle components. - The UK PSTI Act covers relevant connectable products in the UK market with its own separate exclusion list under the 2023 Regulations. - Consumer energy resources (solar inverters, batteries) are within scope of the Australia Cyber Security Act 2024. - Smart meters are outside scope in Australia because they are not acquired by consumers but supplied and installed by electricity retailers. - Manufacturers must maintain a product inventory that tags each SKU for Australia Cyber Security Act 2024 scope and UK PSTI Act scope independently. ## Password security requirements under the Australia Cyber Security Act 2024 vs UK PSTI Act Password security is the first shared requirement under both the Australia Cyber Security Act 2024 and the UK PSTI Act. Both regimes require that passwords for consumer smart devices must be either unique per product or defined by the user. Neither regime permits universal or factory default passwords that are the same across all units of a product model. Under the Australia Cyber Security Act 2024, Schedule 1 Clause 2 of the Smart Devices Rules 2025 specifies that passwords must be unique per product or user-defined. Passwords that are unique per product must not be based on incremental counters (such as password1 and password2), must not be based on or derived from publicly available information, must not be based on or derived from unique product identifiers (such as serial numbers) unless encrypted or hashed using an encryption method or keyed hashing algorithm that is accepted as part of good industry practice, and must not be otherwise guessable in a manner unacceptable under good industry practice. The Rules define specific terms: a keyed hashing algorithm means an algorithm that uses a data input and a secret key to produce a value which cannot be guessed or reproduced without knowledge of both. Good industry practice means the exercise of that degree of skill, diligence, prudence and foresight which would reasonably and ordinarily be expected from a skilled and experienced cryptographer engaged in the same type of activity. The password requirements under the Australia Cyber Security Act 2024 apply to passwords for hardware of the product when the product is not in factory default state, software that is preinstalled on the product at the point of consumer supply when the product is not in factory default state, and software that must be installed for all of the manufacturer's intended purposes. The UK PSTI Act Regulations 2023 contain equivalent requirements covering the same product and software categories. One password implementation can satisfy both the Australia Cyber Security Act 2024 and the UK PSTI Act simultaneously. - Both the Australia Cyber Security Act 2024 and the UK PSTI Act prohibit universal default passwords across product units. - Passwords must be unique per product or defined by the user under both product security frameworks. - Unique-per-product passwords must not be based on incremental counters (e.g., password1, password2) under the Australia Cyber Security Act 2024. - Passwords must not be derived from publicly available information or unencrypted product identifiers under the Australia Cyber Security Act 2024. - The Australia Cyber Security Act 2024 defines good industry practice by reference to the skill expected of an experienced cryptographer. - One password implementation designed for the UK PSTI Act will satisfy the Australia Cyber Security Act 2024. *Recommended next step* *Placement: after the comparison section* ## Use Australia Cyber Security Act 2024 Cyber Security Act vs UK PSTI Act as a cited research workflow Research Copilot can take Australia Cyber Security Act 2024 Cyber Security Act vs UK PSTI Act from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on Australia Cyber Security Act 2024 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Australia Cyber Security Act 2024 Cyber Security Act vs UK PSTI Act](/solutions/research-copilot.md): Start from Australia Cyber Security Act 2024 Cyber Security Act vs UK PSTI Act and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Australia Cyber Security Act 2024](/contact.md): Review your current process, evidence gaps, and next steps for Australia Cyber Security Act 2024 Cyber Security Act vs UK PSTI Act. ## Vulnerability disclosure requirements in the Australia Cyber Security Act 2024 vs UK PSTI Act Both the Australia Cyber Security Act 2024 and the UK PSTI Act require manufacturers to publish a vulnerability disclosure policy that tells security researchers and members of the public how to report security issues. This is the second shared ETSI EN 303 645 control in the product security comparison. Under the Australia Cyber Security Act 2024, Schedule 1 Clause 3 of the Smart Devices Rules 2025 requires the manufacturer to publish at least one point of contact for reporting security issues, and to state when a person who makes such a report will receive an acknowledgement of the receipt of the report and status updates until the resolution of the reported security issues. The vulnerability disclosure obligation covers hardware of the product, software that is preinstalled at the point of consumer supply, software that must be installed for all of the manufacturer's intended purposes, and software used for or in connection with any of the manufacturer's intended purposes of the product. The published vulnerability disclosure information under the Australia Cyber Security Act 2024 must be accessible, clear and transparent. It must be made available to a person without prior request, in English, free of charge, and without requesting personal information about the person. The UK PSTI Act contains equivalent vulnerability reporting requirements. For manufacturers already compliant with the UK PSTI Act, the same vulnerability disclosure policy, contact channels, and acknowledgement workflows will satisfy the Australia Cyber Security Act 2024 requirements. - Both the Australia Cyber Security Act 2024 and the UK PSTI Act require at least one published point of contact for security vulnerability reports. - Manufacturers must acknowledge receipt and provide status updates until resolution under both product security frameworks. - Vulnerability reporting information must be free, accessible, and available without requiring personal data under the Australia Cyber Security Act 2024. - Published information must be in English and accessible without prior request under the Australian Smart Devices Rules 2025. - Coverage extends to hardware, preinstalled software, installable software, and connected software under the Australia Cyber Security Act 2024. - The same vulnerability disclosure policy satisfies both the Australia Cyber Security Act 2024 and the UK PSTI Act. ## Support period and security update obligations under the Australia Cyber Security Act 2024 vs UK PSTI Act Both the Australia Cyber Security Act 2024 and the UK PSTI Act require manufacturers to publish a defined support period for security updates. Under the Australia Cyber Security Act 2024, Schedule 1 Clause 4 of the Smart Devices Rules 2025 defines a security update as a software update that protects or enhances the security of the product, including a software update that addresses a security issue which has been discovered by or reported to the manufacturer. The defined support period is the period, expressed as a period of time with an end date, for which security updates will be provided by or on behalf of the manufacturer. The Australia Cyber Security Act 2024 imposes specific rules on the defined support period. The manufacturer must not shorten the defined support period after it is published. If the manufacturer extends the defined support period, the new period must be published as soon as practicable. The defined support period information must be accessible, clear and transparent. It must be made available to a person without prior request, in English, free of charge, without requesting personal information, and in such a way that is understandable by a reader without prior technical knowledge. If the manufacturer offers to supply the product on its website or another website under its control, the Australia Cyber Security Act 2024 requires that the defined support period information must be prominently published with the other information intended to inform consumers' decisions to acquire the product. For each instance on the website where the main characteristics of the product are published, the support period must be published alongside or otherwise given equal prominence to the publication of the main characteristics. The UK PSTI Act contains comparable requirements for defined support period publication. One support period publication can serve both the Australia Cyber Security Act 2024 and the UK PSTI Act. - Both the Australia Cyber Security Act 2024 and the UK PSTI Act require a defined support period expressed as a time period with a fixed end date. - The defined support period must not be shortened once published but may be extended under both product security frameworks. - If extended, the new defined support period must be published as soon as practicable under the Australia Cyber Security Act 2024. - Support period information must be prominently displayed alongside product characteristics on manufacturer websites under the Australia Cyber Security Act 2024. - Information must be free, in English, and understandable without technical knowledge under the Australian Smart Devices Rules 2025. - Security updates are defined as software updates that protect or enhance product security under the Australia Cyber Security Act 2024. ## Statement of compliance: how the Australia Cyber Security Act 2024 differs from the UK PSTI Act The statement of compliance is where the product security comparison shows the most significant procedural difference between the Australia Cyber Security Act 2024 and the UK PSTI Act. Section 16 of the Australia Cyber Security Act 2024 requires manufacturers to provide a statement of compliance for every in-scope product supplied in Australia, and requires suppliers to supply each product accompanied by that statement. Both manufacturers and suppliers must retain a copy of the statement of compliance for the period specified in the Rules. Under Section 9 of the Cyber Security (Security Standards for Smart Devices) Rules 2025, the statement of compliance must be prepared by or on behalf of the manufacturer. It must include the product type and batch identifier, the name and address of the manufacturer, the name and address of an authorised representative of the manufacturer, the names and addresses of any other authorised representatives of the manufacturer that are in Australia, a declaration that the statement was prepared by or on behalf of the manufacturer, a declaration that in the opinion of the manufacturer the product was manufactured in compliance with the requirements of the security standard and the manufacturer has complied with any other obligations relating to the product in the security standard, the defined support period for the product at the date the statement of compliance is issued, the signature and name and function of the signatory of the manufacturer, and the place and date of issue of the statement of compliance. The retention period for the statement of compliance is 5 years under Section 10 of the Rules. This applies to both manufacturers (who must retain the statement they prepared) and suppliers (who must retain a copy of the statement that accompanied the product). The UK PSTI Act requires compliance documentation under its own regime, but the specific fields, format, and retention period differ. The Australian Government Explanatory Statement confirms that products supplied to the UK market under the UK PSTI Regulations 2023 can reuse the same information for the Australian statement of compliance as long as all Australian requirements are met. - The Australia Cyber Security Act 2024 requires a statement of compliance with prescribed fields including product type, batch identifier, manufacturer details, authorised representative details, compliance declarations, defined support period, signatory details, and date and place of issue. - Under the Australia Cyber Security Act 2024, manufacturers must retain the statement of compliance for 5 years. - Under the Australia Cyber Security Act 2024, suppliers must also retain a copy of the statement of compliance for 5 years. - The statement of compliance must be prepared by or on behalf of the manufacturer under Section 9 of the Smart Devices Rules 2025. - Products already compliant with the UK PSTI Act can reuse the same information for the Australian statement if all Australian requirements are met. - The UK PSTI Act has its own compliance documentation requirements with different prescribed fields. ## Enforcement escalation: compliance notice, stop notice, and recall notice under the Australia Cyber Security Act 2024 The Australia Cyber Security Act 2024 establishes a three-step enforcement escalation path for product security in Part 2, Division 3 of the Act. This enforcement model differs from the UK PSTI Act enforcement regime and is an important part of this product security comparison. The first step is a compliance notice under Section 17 of the Australia Cyber Security Act 2024. The Secretary of the Department of Home Affairs may issue a compliance notice if the Secretary is reasonably satisfied that an entity is not complying with its obligations under Section 15 (compliance with the security standard) or Section 16 (statement of compliance), or if the Secretary is aware of information that suggests the entity may not be complying. The compliance notice must set out the name of the entity, brief details of the non-compliance or possible non-compliance, specify action within the entity's control that the entity must take, specify a reasonable period for taking that action, and explain what may happen if the entity does not comply. Before issuing the compliance notice, the Secretary must notify the entity and give the entity at least 10 days to make representations. The second step is a stop notice under Section 18 of the Australia Cyber Security Act 2024. The Secretary may issue a stop notice if the entity has already been given a compliance notice and has not complied with it, or if the actions taken to address the non-compliance are inadequate. The stop notice can require the entity to take or refrain from taking specific actions within a reasonable period. The third step is a recall notice under Section 19 of the Australia Cyber Security Act 2024. The Secretary may issue a recall notice if the entity has already been given a stop notice and has not complied with it. The recall notice can require the entity to ensure the product is not acquired in Australia, ensure the product is not supplied to suppliers for supply in Australia, and arrange for the return of the product within a specified reasonable period. If the entity fails to comply with the recall notice, the Minister may publish the entity's identity, product details, non-compliance details, and the risks posed by the product under Section 20 of the Australia Cyber Security Act 2024. The UK PSTI Act is enforced by the Office for Product Safety and Standards (OPSS) and also uses compliance notices, stop notices, and recall notices. Under the Australia Cyber Security Act 2024, entities may apply for internal review of a decision to issue any notice within 30 days after the notice was given (Section 22). The decision-maker must review the decision and affirm, vary, or revoke it within 30 days of the application. - Australia Cyber Security Act 2024 enforcement Step 1: Compliance notice under Section 17 requiring the entity to address the non-compliance within a specified period, with at least 10 days to make representations before issuance. - Australia Cyber Security Act 2024 enforcement Step 2: Stop notice under Section 18 if the compliance notice was not followed or the response was inadequate. - Australia Cyber Security Act 2024 enforcement Step 3: Recall notice under Section 19 requiring the entity to stop supply and arrange product returns. - Failure to comply with a recall notice may result in public notification by the Minister under Section 20, including the entity's identity and product details. - The UK PSTI Act enforcement is administered by the Office for Product Safety and Standards (OPSS). - Under the Australia Cyber Security Act 2024, entities may apply for internal review of a notice decision within 30 days. ## Civil penalties and regulatory powers: Australia Cyber Security Act 2024 vs UK PSTI Act The Australia Cyber Security Act 2024 uses the Regulatory Powers (Standard Provisions) Act 2014 as its penalty and enforcement framework. Under Part 6 of the Australia Cyber Security Act 2024, each civil penalty provision is subject to monitoring powers (Part 2 of the Regulatory Powers Act), investigation powers (Part 3), civil penalty orders from a relevant court (Part 4), infringement notices (Part 5), enforceable undertakings (Part 6), and injunctions (Part 7). Sections 15 and 16 of the Australia Cyber Security Act 2024, which contain the core product security obligations (security standard compliance and statement of compliance), are specifically subject to monitoring and enforceable undertakings. The Secretary of the Department of Home Affairs may also engage an appropriately qualified and experienced expert to carry out an independent examination of any product to determine whether it complies with the security standard and whether the statement of compliance meets the requirements (Section 23 of the Australia Cyber Security Act 2024). The expert may open product packaging, operate the product, test or analyse the product using electronic equipment, read records or documents contained in the product, and take photographs or video recordings. An entity is entitled to reasonable compensation from the Commonwealth for complying with such a request. The UK PSTI Act empowers OPSS to impose financial penalties of up to GBP 10 million or 4% of qualifying worldwide revenue, whichever is greater, for each compliance failure. The UK PSTI Act also allows daily penalties of up to GBP 20,000 for ongoing non-compliance. In this product security comparison, the UK PSTI Act penalty structure is more explicitly quantified with specific maximum amounts, while the Australia Cyber Security Act 2024 relies on the general civil penalty regime of the Regulatory Powers Act, which calculates maximum penalties based on penalty units. - The Australia Cyber Security Act 2024 applies civil penalty orders, infringement notices, enforceable undertakings, and injunctions through the Regulatory Powers (Standard Provisions) Act 2014. - The Australia Cyber Security Act 2024 authorises the Secretary to commission independent product examinations by qualified experts under Section 23. - Independent examiners under the Australia Cyber Security Act 2024 may open, operate, test, analyse, and photograph products. - The UK PSTI Act allows financial penalties of up to GBP 10 million or 4% of qualifying worldwide revenue per compliance failure. - The UK PSTI Act also allows daily penalties of up to GBP 20,000 for ongoing non-compliance. - Both the Australia Cyber Security Act 2024 and the UK PSTI Act have meaningful penalty exposure, but the calculation methodology differs. ## Timeline comparison: when the Australia Cyber Security Act 2024 and the UK PSTI Act each apply The timeline differences in this product security comparison are critical for planning. The UK PSTI Act security requirements have been in force since 29 April 2024. Any manufacturer or supplier placing relevant connectable products on the UK market must already comply with the UK PSTI Act. The Australia Cyber Security Act 2024 received Royal Assent on 29 November 2024. Part 1 (preliminary provisions and definitions) commenced on 30 November 2024. Part 2 (security standards for smart devices) commenced on 29 November 2025. The substantive security standard is in the Cyber Security (Security Standards for Smart Devices) Rules 2025, which were registered on 4 March 2025 with a 12 month transition period. Part 2 of the Rules and Schedule 1, which contains the actual password, vulnerability disclosure, and defined support period requirements, commenced on 4 March 2026. Part 3 (ransomware reporting obligations) commenced on 29 May 2025. Part 4 (coordination of significant cyber security incidents) commenced on 30 November 2024. Part 5 (Cyber Incident Review Board) commenced on 29 May 2025. Parts 6 and 7 (regulatory powers and miscellaneous) commenced on 30 November 2024. This means that as of 4 March 2026, both the Australia Cyber Security Act 2024 and the UK PSTI Act are actively enforceable for their respective markets. Manufacturers that already comply with the UK PSTI Act should have most of the technical controls in place for the Australia Cyber Security Act 2024 and need to focus on the statement of compliance documentation, product scope analysis against the Australian exclusion list, and assessment of whether the broader business triggers ransomware reporting obligations under Part 3 of the Australia Cyber Security Act 2024. - UK PSTI Act: security requirements in force since 29 April 2024. - Australia Cyber Security Act 2024: Royal Assent 29 November 2024, Part 1 commenced 30 November 2024. - Australia Cyber Security Act 2024: Part 2 (security standards for smart devices) commenced 29 November 2025. - Australia Cyber Security Act 2024: Security Standards Rules registered 4 March 2025, Schedule 1 security standard commenced 4 March 2026. - Australia Cyber Security Act 2024: Ransomware reporting obligations (Part 3) commenced 29 May 2025. - Both the Australia Cyber Security Act 2024 and the UK PSTI Act are now actively enforceable in their respective markets. ## Broader statutory context: ransomware reporting under the Australia Cyber Security Act 2024 An important dimension of this product security comparison that does not exist in the UK PSTI Act is the ransomware reporting obligation in Part 3 of the Australia Cyber Security Act 2024. While the product security controls in Part 2 of the Australia Cyber Security Act 2024 apply to manufacturers and suppliers of consumer connectable products, Part 3 introduces separate reporting duties for any reporting business entity that makes a ransomware payment in connection with a cyber security incident. Under Section 26 of the Australia Cyber Security Act 2024, a reporting business entity is an entity carrying on a business in Australia with an annual turnover for the previous financial year that exceeds the prescribed threshold, that is not a Commonwealth body or State body, and that is not a responsible entity for a critical infrastructure asset. Alternatively, an entity that is a responsible entity for a critical infrastructure asset to which Part 2B of the Security of Critical Infrastructure Act 2018 applies is also a reporting business entity under the Australia Cyber Security Act 2024. If a reporting business entity provides or is aware that another entity has provided a ransomware payment to an extorting entity in connection with a cyber security incident, the entity must report the payment under Section 27 of the Australia Cyber Security Act 2024. Failure to report carries a civil penalty of 60 penalty units. Information in ransomware payment reports is protected under the Australia Cyber Security Act 2024. Ransomware payment reports may only be used or disclosed for permitted cyber security purposes (Section 29). Certain information is not admissible in evidence in proceedings against the reporting business entity (Section 32). This protection is designed to encourage reporting without exposing entities to additional legal risk. The UK PSTI Act does not contain any ransomware reporting obligation. Manufacturers entering the Australian market should assess whether their broader business, beyond product security, is captured by the ransomware reporting obligations of the Australia Cyber Security Act 2024. - The Australia Cyber Security Act 2024 Part 3 requires reporting business entities to report ransomware payments, with a civil penalty of 60 penalty units for non-compliance. - The UK PSTI Act does not contain any ransomware reporting obligation. - A reporting business entity under the Australia Cyber Security Act 2024 includes businesses carrying on a business in Australia with annual turnover above the prescribed threshold. - Responsible entities for critical infrastructure assets under Part 2B of the Security of Critical Infrastructure Act 2018 are also reporting business entities. - Information in ransomware payment reports is protected and may only be used for permitted cyber security purposes under the Australia Cyber Security Act 2024. - Manufacturers entering Australia should assess whether their business, beyond product security, is captured by the ransomware reporting obligations of the Australia Cyber Security Act 2024. ## Cross-market dual compliance strategy for the Australia Cyber Security Act 2024 and the UK PSTI Act Because the Australia Cyber Security Act 2024 and the UK PSTI Act both derive their core controls from ETSI EN 303 645, manufacturers can build one product security baseline that satisfies the technical requirements of both regimes. The practical dual compliance strategy has three layers: a shared engineering baseline, an Australia Cyber Security Act 2024 compliance wrapper, and a UK PSTI Act compliance wrapper. The shared engineering baseline should implement the three mandated controls. For password security, implement unique-per-product passwords or user-defined passwords and document the generation method, including the encryption or keyed hashing algorithm used. For vulnerability disclosure, publish a contact point, acknowledgement timeline, and status update commitment on the manufacturer's website in English, free of charge. For support period transparency, publish the defined support period with an end date alongside product characteristics on the manufacturer's website with equal prominence. Retain all design evidence, test reports, and published content centrally in one evidence repository. The Australia Cyber Security Act 2024 compliance wrapper should include the formal statement of compliance with all prescribed fields from Section 9 of the Smart Devices Rules 2025 (product type, batch identifier, manufacturer name and address, authorised representative details, compliance declarations, defined support period, signatory details, date and place of issue). Both the manufacturer and any supplier must retain the statement of compliance for 5 years. The wrapper should also include a regulatory response plan that addresses the compliance notice, stop notice, and recall notice escalation path under the Australia Cyber Security Act 2024, and an assessment of whether the business is a reporting business entity for ransomware reporting under Part 3. The UK PSTI Act compliance wrapper should include the required compliance documentation under the 2023 Regulations, a regulatory response plan that addresses OPSS enforcement actions, and financial penalty exposure analysis based on the UK PSTI Act penalty structure (up to GBP 10 million or 4% of qualifying worldwide revenue). Product teams should run a single governance review before each market launch that checks both the Australia Cyber Security Act 2024 and the UK PSTI Act compliance packs are complete and current. - Shared layer: one product security baseline implementing passwords, vulnerability disclosure, and defined support period controls from ETSI EN 303 645. - Shared layer: one evidence repository with design documents, test results, published vulnerability disclosure policy, and published support period information. - Australia wrapper: formal statement of compliance with all prescribed fields under the Cyber Security (Security Standards for Smart Devices) Rules 2025, plus 5 year retention by both manufacturers and suppliers. - Australia wrapper: regulatory response plan covering compliance notice, stop notice, and recall notice escalation under the Australia Cyber Security Act 2024. - UK wrapper: compliance documentation under the UK PSTI Act 2023 Regulations, OPSS enforcement response plan, and financial penalty exposure analysis. - Governance: single pre-launch review that signs off both the Australia Cyber Security Act 2024 and the UK PSTI Act compliance packs before product release. ## Summary of key differences in this product security comparison This product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act can be summarised across seven dimensions. On scope, both regimes cover consumer connectable products, but the Australia Cyber Security Act 2024 explicitly excludes desktops, laptops, tablets, smartphones, therapeutic goods, road vehicles, and road vehicle components, while the UK PSTI Act has its own exclusion list. On security requirements, both regimes mandate the same three ETSI EN 303 645 controls (passwords, vulnerability disclosure, support periods). On compliance documentation, the Australia Cyber Security Act 2024 requires a prescribed statement of compliance with specific fields and a 5 year retention period, while the UK PSTI Act has its own documentation requirements. On enforcement, the Australia Cyber Security Act 2024 uses a compliance notice, stop notice, recall notice escalation administered by the Secretary of the Department of Home Affairs, while the UK PSTI Act is enforced by the Office for Product Safety and Standards (OPSS). On penalties, the Australia Cyber Security Act 2024 applies civil penalties under the Regulatory Powers (Standard Provisions) Act 2014, while the UK PSTI Act allows fines of up to GBP 10 million or 4% of global revenue. On product examination, the Australia Cyber Security Act 2024 authorises independent expert examinations of products under Section 23. On broader obligations, the Australia Cyber Security Act 2024 includes ransomware reporting duties in Part 3 that have no equivalent in the UK PSTI Act. - Scope: both cover consumer connectable products, but exclusion lists differ between the Australia Cyber Security Act 2024 and the UK PSTI Act. - Security requirements: identical three-control baseline (passwords, vulnerability disclosure, support periods) derived from ETSI EN 303 645. - Compliance documentation: Australia Cyber Security Act 2024 requires a prescribed statement of compliance with 5 year retention; UK PSTI Act has its own documentation requirements. - Enforcement authority: Australia Cyber Security Act 2024 administered by the Secretary of the Department of Home Affairs; UK PSTI Act administered by OPSS. - Penalties: Australia Cyber Security Act 2024 uses civil penalty provisions under the Regulatory Powers Act; UK PSTI Act allows fines up to GBP 10 million or 4% of global revenue. - Product examination: the Australia Cyber Security Act 2024 authorises independent expert examinations of products under Section 23. - Broader obligations: the Australia Cyber Security Act 2024 includes ransomware reporting in Part 3 with a civil penalty of 60 penalty units, which has no equivalent in the UK PSTI Act. ## Primary sources - [Cyber Security Act 2024 (No. 98, 2024) official text](https://www.legislation.gov.au/C2024A00098/latest/text?ref=sorena.io) - Primary source for the Australia Cyber Security Act 2024 including Part 2 (security standards for smart devices), Part 3 (ransomware reporting), Part 6 (regulatory powers and civil penalties), and enforcement provisions (compliance notice, stop notice, recall notice). - [Cyber Security (Security Standards for Smart Devices) Rules 2025 official text](https://www.legislation.gov.au/F2025L00276/asmade/text?ref=sorena.io) - Primary source for the Australia Cyber Security Act 2024 security standard including Schedule 1 (password requirements, vulnerability disclosure requirements, defined support period requirements) and statement of compliance requirements with 5 year retention. - [Product Security and Telecommunications Infrastructure Act 2022 (UK) official text](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary UK legislation for the UK PSTI Act product security regime. - [Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023 (UK) official text](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - UK PSTI Act security requirements regulations in force since 29 April 2024, which the Australian Smart Devices Rules 2025 were modelled on. - [ETSI EN 303 645 (Cyber Security for Consumer Internet of Things: Baseline Requirements)](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - The European standard from which both the Australia Cyber Security Act 2024 and the UK PSTI Act derive their three core product security controls (Provisions 5.1, 5.2, and 5.3). ## Related Topic Guides - [Australia Cyber Security Act 2024 Applicability Test | Who Must Comply](/artifacts/apac/australia-cyber-security-act/applicability-test.md): Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations. - [Australia Cyber Security Act 2024 Compliance Checklist](/artifacts/apac/australia-cyber-security-act/checklist.md): Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting. - [Australia Cyber Security Act 2024 Compliance Guide | Implementation Playbook](/artifacts/apac/australia-cyber-security-act/compliance.md): A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements. - [Australia Cyber Security Act 2024 Compliance Templates | Statement of Compliance, Ransomware Report, Evidence Pack, Vulnerability Disclosure, Support Period](/artifacts/apac/australia-cyber-security-act/templates.md): Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field. - [Australia Cyber Security Act 2024 Deadlines and Compliance Calendar | Commencement Dates](/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar.md): Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent. - [Australia Cyber Security Act 2024 FAQ | Frequently Asked Questions](/artifacts/apac/australia-cyber-security-act/faq.md): Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024. - [Australia Cyber Security Act 2024 Requirements | Smart Device and Ransomware Reporting Obligations](/artifacts/apac/australia-cyber-security-act/requirements.md): Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure. - [Australia Cyber Security Act 2024 Timeline and Commencement Dates | Full Schedule](/artifacts/apac/australia-cyber-security-act/timeline-and-commencement.md): Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024. - [Australia Cyber Security Act 2024 vs EU Cyber Resilience Act | Full CRA Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act.md): Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements. - [Australia Smart Device Compliance Checklist | Cyber Security Act 2024 | Sorena](/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist.md): Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure. - [Penalties and fines | Australia Cyber Security Act 2024 | 60 Penalty Units, Smart Device Enforcement, Ransomware Reporting](/artifacts/apac/australia-cyber-security-act/penalties-and-fines.md): Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals. - [Ransomware Payment Reporting in 72 Hours | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours.md): Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. - [Scope and Definitions | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/scope-and-definitions.md): Complete guide to the Australia Cyber Security Act 2024 scope and definitions. - [Smart device security standards | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/smart-device-security-standards.md): Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2. - [Statement of Compliance and Recordkeeping | Australia Cyber Security Act 2024 | Section 9, Section 10, 5 Year Retention](/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping.md): Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act --- --- title: "Australia Cyber Security Act 2024 Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "Australia Cyber Security Act 2024 deadlines" - "Cyber Security Act 2024 commencement dates" - "smart device security standards 4 March 2026" - "ransomware payment reporting 72 hours Australia" - "Australia Cyber Security Act compliance calendar" - "Part 2 Part 3 Part 5 commencement dates" - "Cyber Incident Review Board 29 May 2025" - "PJCIS statutory review December 2027" - "APAC cyber security compliance calendar" - "Australia smart device compliance deadlines" - "compliance calendar" - "commencement dates" - "smart device rules 4 March 2026" - "ransomware reporting 72 hours Australia" - "Cyber Incident Review Board commencement" - "APAC cyber compliance calendar" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Australia Cyber Security Act 2024 Deadlines and Compliance Calendar Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent. *Artifact Guide* *APAC* ## Australia Cyber Security Act 2024 Deadlines and Compliance Calendar Every commencement date, backstop deadline, and recurring compliance checkpoint from the Australia Cyber Security Act 2024 and its subordinate Rules, organized into an operational compliance calendar your teams can follow for product launches, ransomware readiness, and governance. The Australia Cyber Security Act 2024 deadlines spread across four distinct commencement dates from November 2024 through March 2026, followed by a PJCIS statutory review starting in December 2027. A practical compliance calendar converts those legal anchors into recurring planning cycles. The Australia Cyber Security Act 2024 (No. 98, 2024) uses a staged commencement model. Section 2 of the Act sets out six rows in a commencement table, each tied either to the day after Royal Assent or to a Proclamation with a backstop period of six or twelve months. Two sets of subordinate Rules, the Cyber Security (Security Standards for Smart Devices) Rules 2025 (F2025L00276) and the Cyber Security (Ransomware Payment Reporting) Rules 2025 (F2025L00278), add their own commencement dates on top of the Act. This page lists every Australia Cyber Security Act 2024 deadline, explains the commencement dates for each Part, and provides a compliance calendar that product teams, incident response teams, and legal and governance functions can follow. ## Royal Assent and immediate commencement on 30 November 2024 The Australia Cyber Security Act 2024 (No. 98, 2024) received Royal Assent on 29 November 2024. The day after Royal Assent, 30 November 2024, triggered the first wave of commencement dates. Part 1 (Preliminary), Part 4 (Coordination of significant cyber security incidents), and Parts 6 and 7 (Enforcement and Miscellaneous) all commenced on 30 November 2024. These are the earliest Australia Cyber Security Act 2024 deadlines and they brought the foundational definitions, the National Cyber Security Coordinator framework, and the enforcement machinery into force. Part 1 of the Australia Cyber Security Act 2024 establishes core definitions that the rest of the Act relies on, including the meaning of cyber security incident (section 9), permitted cyber security purpose (section 10), relevant connectable product, reporting business entity, and ransomware payment. Part 4 created the framework for voluntary information sharing with the National Cyber Security Coordinator during significant cyber security incidents, together with safe harbour protections in Divisions 2 and 3 that limit secondary use and disclosure of shared information. Parts 6 and 7 activated the civil penalty provisions, enforceable undertakings, injunctions, monitoring and investigation powers, and infringement notices, meaning the enforcement apparatus was live from day one, even before the substantive obligations in Parts 2, 3, and 5 commenced. - 29 November 2024: Royal Assent for the Australia Cyber Security Act 2024 (No. 98, 2024). This is the baseline date from which all backstop periods are calculated. - 30 November 2024: Part 1 (Preliminary) commenced, bringing into force the definitions of cyber security incident, permitted cyber security purpose, relevant connectable product, reporting business entity, ransomware payment, and all other foundational terms in section 8. - 30 November 2024: Part 4 (Coordination of significant cyber security incidents) commenced. The voluntary information sharing framework with the National Cyber Security Coordinator became active. Safe harbour protections under sections 38 through 43 became available to impacted entities that voluntarily share information. - 30 November 2024: Parts 6 and 7 (Enforcement and Miscellaneous) commenced. Section 79 applies the Regulatory Powers (Standard Provisions) Act 2014 to civil penalty provisions, enforceable undertakings, and injunctions. Monitoring and investigation powers under Division 3 of Part 6 also became available. The Crown is not liable to a pecuniary penalty for breach of a civil penalty provision (subsection 79(8)). *Recommended next step* *Placement: after the timeline or milestone section* ## Turn Australia Cyber Security Act 2024 Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take Australia Cyber Security Act 2024 Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on Australia Cyber Security Act 2024 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Australia Cyber Security Act 2024 Deadlines and Compliance Calendar](/solutions/assessment.md): Start from Australia Cyber Security Act 2024 Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Australia Cyber Security Act 2024](/contact.md): Review your current process, evidence gaps, and next steps for Australia Cyber Security Act 2024 Deadlines and Compliance Calendar. ## Part 3 and Part 5 commencement on 29 May 2025 Part 3 (Ransomware reporting obligations) and Part 5 (Cyber Incident Review Board) of the Australia Cyber Security Act 2024 each used a conditional commencement model. Each Part was to commence on a single day fixed by Proclamation, but if no Proclamation was issued within 6 months of Royal Assent, both Parts would automatically commence on the day after the end of that period. Column 3 of the commencement table in section 2 records the backstop commencement date as 29 May 2025 for both Part 3 and Part 5. Part 3 of the Australia Cyber Security Act 2024 introduced Australia's first mandatory ransomware payment reporting obligation. Section 26 defines who is a reporting business entity and what constitutes a ransomware payment. Section 27 requires the reporting business entity to give the designated Commonwealth body a ransomware payment report within 72 hours of making the payment or becoming aware that the payment was made. The civil penalty for failing to report within 72 hours is 60 penalty units (section 27(5)). Part 5 established the Cyber Incident Review Board, which conducts no fault reviews of significant cyber security incidents. The Board Chair can request information (section 48) or require certain entities to produce documents (section 49) under a civil penalty of 60 penalty units for noncompliance. These commencement dates are essential entries in any Australia Cyber Security Act 2024 compliance calendar. - 29 May 2025: Part 3 (Ransomware reporting obligations) of the Australia Cyber Security Act 2024 commenced. The 72 hour reporting obligation under section 27(1) became enforceable from this date. - 29 May 2025: Part 5 (Cyber Incident Review Board) of the Australia Cyber Security Act 2024 commenced. The Board's powers to conduct no fault reviews and compel document production became active. - 29 May 2025: The Cyber Security (Ransomware Payment Reporting) Rules 2025 (F2025L00278) also commenced on this date because their commencement was tied to the later of registration (3 March 2025) and the commencement of Part 3 of the Act. - From 29 May 2025, any reporting business entity that makes a ransomware payment faces the 72 hour reporting deadline and a 60 penalty unit civil penalty for noncompliance. - From 29 May 2025, entities that receive a notice to produce documents from the Cyber Incident Review Board Chair under section 49 must comply or face a 60 penalty unit civil penalty. ## Part 2 commencement on 29 November 2025 for smart devices Part 2 (Security standards for smart devices) of the Australia Cyber Security Act 2024 used a 12 month backstop. If no Proclamation fixed an earlier date, Part 2 would automatically commence on the day after the end of the 12 month period beginning on the day of Royal Assent. Column 3 of the commencement table records this backstop commencement date as 29 November 2025. Part 2 of the Australia Cyber Security Act 2024 is the legislative foundation for the smart device security standard. Section 14 gives the rules the power to prescribe security standards for specified classes of relevant connectable products. Section 15 requires manufacturers to comply with the security standard and prohibits suppliers from supplying noncompliant products. Section 16 requires manufacturers to provide a statement of compliance and suppliers to supply the product with that statement. Both manufacturers and suppliers must retain the statement of compliance for the period specified in the rules (5 years under section 10 of the Smart Device Rules). The enforcement tools in Division 3 of Part 2, including compliance notices (section 17), stop notices (section 18), and recall notices (section 19), also became available from the 29 November 2025 commencement date. The compliance calendar should note that the enforcement escalation path runs from compliance notice to stop notice to recall notice to public notification of failure to comply with a recall notice (section 20). - 29 November 2025: Part 2 (Security standards for smart devices) of the Australia Cyber Security Act 2024 commenced. The power to prescribe security standards under section 14 became active. - 29 November 2025: Manufacturer and supplier compliance obligations under sections 15 and 16 commenced. Manufacturers must manufacture products in compliance with the security standard and provide a statement of compliance. Suppliers must not supply noncompliant products and must supply the product with a statement of compliance. - 29 November 2025: The enforcement tools in Division 3 of Part 2 became available to the Secretary: compliance notices (section 17), stop notices (section 18), recall notices (section 19), and public notification of recall noncompliance (section 20). - 29 November 2025: Internal review rights under section 22 became available. An entity that receives a compliance, stop, or recall notice may apply for internal review within 30 days of receiving the notice. - 29 November 2025: The Secretary's power to examine products and statements of compliance under section 23 to assess compliance with the security standard became active. ## Smart Device Rules full commencement on 4 March 2026 The Cyber Security (Security Standards for Smart Devices) Rules 2025 (F2025L00276) were signed by the Minister for Home Affairs on 27 February 2025 and registered on 4 March 2025. The Rules have their own two stage commencement table. Part 1 (Preliminary) commenced on the day the instrument was registered (4 March 2025). Part 2 (Security standards for smart devices) and Schedule 1 (Security standards) commence on 4 March 2026, which is the day after the end of the 12 month period beginning on the registration date. The 12 month gap between registration and the commencement of Part 2 and Schedule 1 of the Smart Device Rules was designed to give manufacturers time to update product designs, build password compliance into firmware, set up vulnerability disclosure channels, publish defined support periods, and prepare statements of compliance. The commencement date of 4 March 2026 is the most operationally significant of all Australia Cyber Security Act 2024 deadlines for manufacturers and suppliers of consumer grade relevant connectable products. From this date, all three security standard requirements in Part 1 of Schedule 1 and the statement of compliance obligation become enforceable. - 4 March 2025: Part 1 (Preliminary) of the Smart Device Rules commenced on registration day. This brought the definitions, authority provisions, and instrument name into force. - 4 March 2026: Part 2 and Schedule 1 of the Smart Device Rules commence. The full security standard for consumer grade relevant connectable products becomes enforceable. - 4 March 2026: Clause 2 of Schedule 1 requires that passwords be unique per product or defined by the user. Passwords must not be based on incremental counters, publicly available information, or unencrypted serial numbers. - 4 March 2026: Clause 3 of Schedule 1 requires manufacturers to publish at least one contact point for reporting security issues, along with timelines for acknowledgement and status updates. The information must be accessible, clear, transparent, in English, free of charge, and must not require personal information from the reporter. - 4 March 2026: Clause 4 of Schedule 1 requires manufacturers to publish the defined support period for security updates, expressed as a period of time with an end date. The manufacturer cannot shorten the defined support period after publication. - 4 March 2026: Section 9 of the Rules requires every statement of compliance to include the product type and batch identifier, manufacturer and representative details, compliance declarations, the defined support period at the date of issue, and the signatory's name, function, place, and date. - Section 10 of the Rules sets a 5 year retention period for statements of compliance. Both manufacturers and suppliers must retain copies under subsections 16(2) and 16(4) of the Act. - The security standard applies to consumer grade relevant connectable products only. Section 8 of the Rules excludes desktops, laptops, tablets, smartphones, therapeutic goods, road vehicles, and road vehicle components. ## Ransomware payment reporting deadlines under the Australia Cyber Security Act 2024 The 72 hour ransomware payment reporting obligation under section 27(1) of the Australia Cyber Security Act 2024 is event driven. The reporting clock starts when a reporting business entity makes a ransomware payment or becomes aware that a ransomware payment has been made on its behalf. The report must be submitted to the designated Commonwealth body within 72 hours of that trigger. This is one of the most demanding Australia Cyber Security Act 2024 deadlines because it can strike at any time and leaves minimal room for preparation. The Ransomware Reporting Rules 2025 (F2025L00278) define which businesses are caught by this obligation and what information the report must contain. Section 6 of the Rules sets the annual turnover threshold at $3 million. For businesses that operated for only part of the previous financial year, the threshold is prorated using the formula: $3 million multiplied by the number of days the business operated, divided by the total number of days in the financial year. Any responsible entity for a critical infrastructure asset under Part 2B of the Security of Critical Infrastructure Act 2018 is also a reporting business entity regardless of turnover. Section 7 of the Rules clarifies that information is only required to the extent that the reporting business entity knows or can discover through reasonable search or enquiry within the 72 hour period. - 72 hours: Maximum time allowed between making or becoming aware of a ransomware payment and submitting the ransomware payment report to the designated Commonwealth body under section 27(1) of the Act. - $3 million: Annual turnover threshold that determines whether a business qualifies as a reporting business entity under section 6 of the Ransomware Reporting Rules 2025. The threshold is prorated for partial year operations. - Critical infrastructure entities: Any responsible entity for a critical infrastructure asset under Part 2B of the Security of Critical Infrastructure Act 2018 is a reporting business entity regardless of annual turnover (section 26(2)(b) of the Act). - Report contents under section 7 of the Rules: the entity's ABN and address, the other entity's ABN and address, incident timing and impact on infrastructure and customers, ransomware variant and vulnerability details, demand amount and payment method, and a description of communications with the extorting entity including pre-payment negotiations. - Civil penalty for late reporting: 60 penalty units under section 27(5) of the Act. However, section 28 provides that a reporting entity is not liable for damages arising from good faith compliance with section 27. - Safe harbour: Information in a ransomware payment report may only be used or disclosed for permitted purposes (section 29). The report cannot be used against the reporting entity in most enforcement proceedings (section 32). ## PJCIS statutory review deadline in December 2027 Section 88 of the Australia Cyber Security Act 2024 requires the Parliamentary Joint Committee on Intelligence and Security (PJCIS) to review the operation of the Act. The PJCIS must begin this review as soon as practicable after 1 December 2027. This review will evaluate how well the Act and its subordinate rules are working and may recommend amendments to the security standard, the reporting thresholds, or the enforcement powers. Organizations should anticipate that the PJCIS review may result in changes to the Australia Cyber Security Act 2024 deadlines, the scope of the smart device security standard, the ransomware reporting turnover threshold, or the enforcement model. Start documenting compliance evidence, incident response metrics, and product compliance outcomes now so that your organization can contribute meaningfully to any consultation process and be prepared for regulatory changes that may follow the review. - 1 December 2027: Earliest date for the PJCIS to begin its statutory review of the Australia Cyber Security Act 2024 under section 88. - The review will assess the operation of the entire Act, including smart device security standards, ransomware reporting obligations, the Cyber Incident Review Board, and the National Cyber Security Coordinator framework. - Regulatory changes may follow the PJCIS review. Organizations should maintain complete compliance records from 2025 onward to support any submission and to be prepared for amended obligations. - Start preparing submission material, compliance metrics, and lessons learned at least 6 months before December 2027. ## Complete Australia Cyber Security Act 2024 compliance calendar The following compliance calendar consolidates every statutory commencement date from the Australia Cyber Security Act 2024 and its subordinate Rules into chronological order. This is the master list of Australia Cyber Security Act 2024 deadlines. Use it as the foundation for your internal compliance tracking and add your own operational milestones for product launches, incident readiness exercises, and governance reviews. Organizations building an Australia Cyber Security Act 2024 compliance calendar should record each of these commencement dates and map them to the specific obligations that become enforceable on that day. The timeline shows four distinct waves of obligations spreading across approximately 16 months from Royal Assent to the Smart Device Rules commencement, plus the PJCIS review date approximately three years after Royal Assent. - 29 November 2024: Royal Assent for the Australia Cyber Security Act 2024 (No. 98, 2024). Baseline date for all backstop period calculations. - 30 November 2024: Part 1 (Preliminary definitions), Part 4 (National Cyber Security Coordinator), Parts 6 and 7 (Enforcement and Miscellaneous) commenced. - 3 March 2025: Ransomware Reporting Rules (F2025L00278) registered on the Federal Register of Legislation. - 4 March 2025: Smart Device Rules (F2025L00276) registered. Part 1 (Preliminary) of the Smart Device Rules commenced. - 29 May 2025: Part 3 (Ransomware reporting obligations) commenced with the 6 month backstop date. The 72 hour reporting obligation under section 27 became enforceable. The Ransomware Reporting Rules also commenced on this date. - 29 May 2025: Part 5 (Cyber Incident Review Board) commenced with the 6 month backstop date. The Board's powers to conduct reviews and compel document production became active. - 29 November 2025: Part 2 (Security standards for smart devices) commenced with the 12 month backstop date. The enforcement tools (compliance notices, stop notices, recall notices) became available. - 4 March 2026: Part 2 and Schedule 1 of the Smart Device Rules commenced. The three security standard requirements (passwords, vulnerability reporting, defined support periods) and the statement of compliance obligation became enforceable for consumer grade relevant connectable products. - 1 December 2027: PJCIS statutory review of the Australia Cyber Security Act 2024 begins under section 88. ## Operational compliance calendar for product teams Product teams that manufacture or supply consumer grade relevant connectable products into Australia should build their compliance calendar around the 4 March 2026 commencement date for the Smart Device Rules. Treating 4 March 2026 as a single drop dead date is risky because the security standard requires changes to product design, firmware, manufacturing processes, website content, and supply chain documentation. The Australia Cyber Security Act 2024 deadlines are best managed by working backward from the commencement date and setting internal milestones at regular intervals. The compliance calendar below assumes a product that is already in development or on the market. If the product has not yet entered development, shift the milestones further back. All milestone dates are illustrative; the key point is that each workstream needs its own lead time and that the milestones should be tracked against the Australia Cyber Security Act 2024 deadlines. - Six months before 4 March 2026 (by September 2025): Conduct a scope analysis to confirm whether each product is a consumer grade relevant connectable product under section 8 of the Smart Device Rules. Identify any excluded product categories: desktops, laptops, tablets, smartphones, therapeutic goods under the Therapeutic Goods Act 1989, road vehicles and road vehicle components under the Road Vehicle Standards Act 2018. Document the assessment and retain it for audit. - Five months before 4 March 2026 (by October 2025): Review every product model for password compliance under clause 2 of Schedule 1. Passwords must be unique per product or defined by the user. Remove any factory default passwords that are shared across products, based on incremental counters, derived from publicly available information, or derived from serial numbers without encryption or a keyed hashing algorithm accepted as good industry practice. - Four months before 4 March 2026 (by November 2025): Set up a public vulnerability reporting contact point for each product as required by clause 3 of Schedule 1. The published information must include at least one contact point, along with timelines for receipt acknowledgement and status updates. The information must be accessible, clear, transparent, available without a prior request, published in English, provided free of charge, and must not require personal information from the reporter. - Three months before 4 March 2026 (by December 2025): Determine and publish the defined support period for security updates for each product as required by clause 4 of Schedule 1. The support period must be expressed as a period of time with an end date. Once published, the defined support period cannot be shortened. It can only be extended, and any extension must be published as soon as practicable. - Two months before 4 March 2026 (by January 2026): Draft statements of compliance for each product class. Under section 9 of the Rules, the statement must include the product type and batch identifier, the names and addresses of the manufacturer and all authorised representatives (including those in Australia), declarations that the statement was prepared by or on behalf of the manufacturer and that the product complies with the security standard, the defined support period at the date of issue, and the signatory's name, function, place, and date of issue. - One month before 4 March 2026 (by February 2026): Run an internal audit against all three security standard requirements and the statement of compliance requirements. Test that the statement template is complete, that the defined support period is published on product pages, that the vulnerability reporting page is live and includes acknowledgement timelines, and that passwords have been updated across all product batches. - 4 March 2026 (commencement day): All consumer grade relevant connectable products manufactured on or after this date, and all such products supplied (other than as second hand goods) on or after this date, must comply with the security standard. Every supply must include a statement of compliance. Begin the 5 year retention clock for each statement issued. - Quarterly after 4 March 2026: Review support period accuracy (no shortening; update the published end date if extended), confirm update delivery against the support period commitment, verify that the vulnerability reporting channel is operational and responding within published timelines, and archive copies of all statements of compliance for the 5 year retention period. ## Operational compliance calendar for ransomware incident readiness The 72 hour ransomware payment reporting obligation under the Australia Cyber Security Act 2024 is event driven rather than calendar driven. However, the compliance calendar should still include recurring readiness checks. A 72 hour deadline is extremely tight for preparing a report that must include incident details, demand details, payment details, entity information, ransomware variant details, vulnerability details, and a description of all communications with the extorting entity. Organizations that do not rehearse their reporting workflow will almost certainly struggle to meet the Australia Cyber Security Act 2024 deadlines for ransomware payment reporting. The compliance calendar for ransomware readiness should start from the commencement date of 29 May 2025 and continue indefinitely. The readiness activities below apply to any reporting business entity, meaning any entity carrying on a business in Australia with annual turnover exceeding $3 million (or the prorated amount for a partial year), and any responsible entity for a critical infrastructure asset under Part 2B of the Security of Critical Infrastructure Act 2018. - 29 May 2025 (commencement of Part 3 and the Ransomware Reporting Rules): Confirm whether the organization meets the reporting business entity definition. Review ABN details, annual turnover against the $3 million threshold, and any critical infrastructure asset responsibilities under the Security of Critical Infrastructure Act 2018. - Within one month of 29 May 2025 (by June 2025): Prepare a standing ransomware payment report template that includes all fields required by section 7 of the Ransomware Reporting Rules. The template should cover the entity's ABN and address, the other entity's ABN and address, when the incident occurred or is estimated to have occurred, when the entity became aware, the impact on infrastructure and customers, ransomware variants and malware used, vulnerabilities exploited, information that could assist response or mitigation, demand amount and method, payment amount and method, and the nature, timing, and description of communications with the extorting entity including pre-payment negotiations. - Quarterly from July 2025: Review the reporting business entity analysis. Turnover may change year to year, and critical infrastructure asset designations may be updated. Keep the threshold analysis current so there is no ambiguity about whether the 72 hour obligation applies. - At least annually (starting by May 2026): Run a tabletop exercise that walks through the full 72 hour reporting path. The exercise should include the decision to pay or not pay, the evidence capture process, the report preparation workflow, the role of external legal advisers (noting that legal professional privilege is preserved under section 31), and the submission method in the form approved by the Secretary. - After any real ransomware event: Conduct a post incident review of the reporting process. Verify that the 72 hour clock was correctly calculated from the time of payment or awareness of payment. Review evidence capture quality and completeness of the report. Update the standing template if any fields were difficult to complete under pressure. - Ongoing: Maintain a current field owner list for each section of the report template. Designate who is responsible for providing entity details, incident details, demand details, payment details, and communication records so that the 72 hour window is not consumed by internal confusion about data ownership. ## Compliance calendar for the Cyber Incident Review Board Part 5 of the Australia Cyber Security Act 2024 established the Cyber Incident Review Board with a commencement date of 29 May 2025. While Part 5 does not create recurring compliance deadlines for private sector entities in the same way as Parts 2 and 3, it does create the power for the Board Chair to request information (section 48) or require the production of documents (section 49). Failure to comply with a section 49 notice carries a civil penalty of 60 penalty units. Disclosure of information from a draft review report received under section 51 also carries a 60 penalty unit civil penalty (section 59). Organizations should include Board related readiness activities in their Australia Cyber Security Act 2024 compliance calendar. The Board conducts no fault reviews of significant cyber security incidents. The reviews produce recommendations for government and industry about actions that could prevent, detect, respond to, or minimize the impact of similar incidents in the future. Draft review reports are shared with affected entities before final reports are issued. Certain information must be redacted from published final reports (section 53). The compliance calendar should ensure that the organization has an internal process for handling Board requests and protecting confidential review materials. - 29 May 2025 (commencement of Part 5): Confirm that the organization has a process for receiving and responding to document production requests from the Cyber Incident Review Board Chair. - Annually from 29 May 2025: Review the internal handling procedure for Board document requests. Verify that the designated contact person is current, that legal professional privilege claims can be made promptly under section 57, and that confidential review materials will be stored securely. - If the organization receives a notice to produce documents under section 49: Respond within the timeframe specified in the notice. The civil penalty for noncompliance is 60 penalty units. Exceptions exist if production would prejudice the security, defence, or international relations of the Commonwealth, or the capabilities of an intelligence agency. - If the organization receives a draft review report under section 51: Do not disclose any information in the draft report. The civil penalty for unauthorized disclosure is 60 penalty units under section 59. Use the information only for the purpose of preparing a submission to the Board in accordance with section 51. ## Building your Australia Cyber Security Act 2024 compliance calendar An effective Australia Cyber Security Act 2024 compliance calendar combines all of the commencement dates listed above with recurring operational checkpoints. The commencement dates are the legal anchors, but the compliance calendar must also include internal milestones, periodic reviews, training refreshers, and governance reporting cycles. Without recurring reviews, governance meetings, and readiness exercises, the compliance program will decay between statutory deadlines. The Australia Cyber Security Act 2024 compliance calendar should be owned by a designated compliance function and reviewed at least quarterly. Each entry should have a responsible owner, a due date, and a clear deliverable. Treat missed compliance calendar entries the same way you treat missed audit findings: escalate, remediate, and track to closure. - Statutory dates: Enter all commencement dates (30 November 2024, 4 March 2025, 29 May 2025, 29 November 2025, 4 March 2026) and the PJCIS review date (1 December 2027) as fixed milestones in your compliance calendar. - Product scope assessments: Complete the relevant connectable product classification for every product before the first Australian launch after 4 March 2026. - Password, vulnerability reporting, and defined support period compliance reviews: Schedule these quarterly after 4 March 2026. - Statement of compliance preparation and issuance: Track issuance for each product class and start the 5 year retention clock on each statement. - Ransomware payment report template reviews: Schedule quarterly from 29 May 2025 to keep the template current with organizational changes and any updates to the Rules. - Tabletop exercises for 72 hour ransomware reporting: Schedule at least one annually starting by May 2026. - Reporting business entity threshold analysis: Update at the start of each financial year using the previous year's turnover against the $3 million threshold. - Cyber Incident Review Board document production readiness: Review annually to ensure the contact person, legal privilege procedures, and confidential storage are current. - Enforcement notice response procedures: Document the 30 day internal review window under section 22 and refresh the procedure annually. - Legal refresh: Review the Federal Register of Legislation at least quarterly for amendments to the Act, new or amended Rules, and updated guidance from the Department of Home Affairs. - Governance reporting: Schedule annual board of directors or senior leadership briefings on Australia Cyber Security Act 2024 compliance calendar status, open items, and any enforcement actions or Board reviews affecting the organization. ## Primary sources - [Cyber Security Act 2024 (Australia) official text](https://www.legislation.gov.au/C2024A00098/latest/text?ref=sorena.io) - Primary source for the section 2 commencement table, Part 2 smart device obligations (sections 14-24), Part 3 ransomware reporting (sections 26-32 including the 72 hour deadline and 60 penalty unit civil penalty), Part 4 National Cyber Security Coordinator (sections 33-44), Part 5 Cyber Incident Review Board (sections 45-77), Part 6 enforcement powers (sections 78-83), and the PJCIS statutory review (section 88). Replaced Authorised Version registered 28 January 2026. - [Cyber Security (Security Standards for Smart Devices) Rules 2025 (F2025L00276)](https://www.legislation.gov.au/F2025L00276/asmade/text?ref=sorena.io) - Primary source for the 4 March 2025 and 4 March 2026 commencement dates, the three Schedule 1 security standard requirements (clause 2 passwords, clause 3 vulnerability reporting, clause 4 defined support periods), the statement of compliance requirements (section 9), the 5 year retention period (section 10), and the excluded product categories (section 8). Authorised Version registered 4 March 2025. - [Cyber Security (Ransomware Payment Reporting) Rules 2025 (F2025L00278)](https://www.legislation.gov.au/F2025L00278/asmade/text?ref=sorena.io) - Primary source for the ransomware reporting commencement linkage to Part 3, the $3 million annual turnover threshold (section 6), the prorated threshold formula for partial year operations, and the detailed information requirements for ransomware payment reports (section 7). Authorised Version registered 3 March 2025. ## Related Topic Guides - [Australia Cyber Security Act 2024 Applicability Test | Who Must Comply](/artifacts/apac/australia-cyber-security-act/applicability-test.md): Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations. - [Australia Cyber Security Act 2024 Compliance Checklist](/artifacts/apac/australia-cyber-security-act/checklist.md): Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting. - [Australia Cyber Security Act 2024 Compliance Guide | Implementation Playbook](/artifacts/apac/australia-cyber-security-act/compliance.md): A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements. - [Australia Cyber Security Act 2024 Compliance Templates | Statement of Compliance, Ransomware Report, Evidence Pack, Vulnerability Disclosure, Support Period](/artifacts/apac/australia-cyber-security-act/templates.md): Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field. - [Australia Cyber Security Act 2024 FAQ | Frequently Asked Questions](/artifacts/apac/australia-cyber-security-act/faq.md): Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024. - [Australia Cyber Security Act 2024 Requirements | Smart Device and Ransomware Reporting Obligations](/artifacts/apac/australia-cyber-security-act/requirements.md): Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure. - [Australia Cyber Security Act 2024 Timeline and Commencement Dates | Full Schedule](/artifacts/apac/australia-cyber-security-act/timeline-and-commencement.md): Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024. - [Australia Cyber Security Act 2024 vs EU Cyber Resilience Act | Full CRA Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act.md): Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements. - [Australia Cyber Security Act 2024 vs UK PSTI Act | Product Security Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act.md): Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements. - [Australia Smart Device Compliance Checklist | Cyber Security Act 2024 | Sorena](/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist.md): Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure. - [Penalties and fines | Australia Cyber Security Act 2024 | 60 Penalty Units, Smart Device Enforcement, Ransomware Reporting](/artifacts/apac/australia-cyber-security-act/penalties-and-fines.md): Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals. - [Ransomware Payment Reporting in 72 Hours | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours.md): Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. - [Scope and Definitions | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/scope-and-definitions.md): Complete guide to the Australia Cyber Security Act 2024 scope and definitions. - [Smart device security standards | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/smart-device-security-standards.md): Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2. - [Statement of Compliance and Recordkeeping | Australia Cyber Security Act 2024 | Section 9, Section 10, 5 Year Retention](/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping.md): Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar --- --- title: "Australia Cyber Security Act 2024 FAQ" canonical_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/faq" source_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/faq" author: "Sorena AI" description: "Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "Australia Cyber Security Act 2024 FAQ" - "frequently asked questions Australia Cyber Security Act" - "smart device security FAQ" - "ransomware payment reporting FAQ Australia" - "statement of compliance FAQ" - "SOCI interaction FAQ" - "cyber security penalties Australia" - "compliance evidence FAQ" - "APAC cyber security FAQ" - "Australia Cyber Security Act commencement dates" - "Australia Cyber Security Act scope" - "frequently asked questions" - "ransomware reporting FAQ Australia" - "APAC compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Australia Cyber Security Act 2024 FAQ Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024. *Artifact Guide* *APAC* ## Australia Cyber Security Act 2024 FAQ Frequently asked questions about the Australia Cyber Security Act 2024. Find detailed answers on applicability, smart device obligations, ransomware payment reporting, penalties, deadlines, SOCI interaction, compliance evidence, and international comparisons. This Australia Cyber Security Act 2024 FAQ page is marked up with FAQPage structured data for search engine rich results. This Australia Cyber Security Act 2024 FAQ answers the questions implementation teams ask most often. Each answer references specific sections of the Act or the 2025 subordinate rules so you can trace the authority behind every statement. Use these frequently asked questions as a starting point, then validate the answers against your own products, legal entities, and incident response facts. ## What is the Australia Cyber Security Act 2024 and what are its main objectives The Australia Cyber Security Act 2024 (No. 98, 2024) is a federal law that received Royal Assent on 29 November 2024. Section 3 of the Act sets out five objectives. The first objective is to improve the cyber security of internet connectable products acquired in Australia by requiring manufacturers and suppliers to meet security standards specified in the rules. The second is to encourage reporting of ransomware payments by imposing mandatory reporting obligations. The third is to facilitate whole of Government coordination of significant cyber security incidents through the National Cyber Security Coordinator. The fourth is to establish the Cyber Incident Review Board to conduct reviews of certain incidents and recommend preventive actions. The fifth is to encourage voluntary information sharing by protecting reported data from being used as evidence against the reporting entity. For readers searching for the Australia Cyber Security Act 2024 FAQ, the key takeaway is that the Act creates three distinct compliance streams. Part 2 covers smart device security standards. Part 3 covers ransomware payment reporting. Part 4 covers voluntary incident coordination through the National Cyber Security Coordinator. Each stream has its own commencement date, its own set of obligations, and its own enforcement path. The Act applies both within and outside Australia under Section 5 and extends to every external Territory. Section 6 confirms the Act binds the Crown in all capacities. ## What are the key commencement dates for the Australia Cyber Security Act 2024 This frequently asked question about the Australia Cyber Security Act 2024 is essential for project planning. The commencement table in Section 2 sets out a staggered rollout across six provision groups. Parts 1, 4, 6, and 7 commenced on 30 November 2024, the day after Royal Assent. These parts cover definitions, coordination of significant cyber security incidents through the National Cyber Security Coordinator, regulatory powers, and miscellaneous provisions. Part 3 (ransomware payment reporting) and Part 5 (Cyber Incident Review Board) commenced on 29 May 2025, six months after Royal Assent. Part 2 (the Act level framework for smart device security standards) commenced on 29 November 2025, twelve months after Royal Assent. The Cyber Security (Security Standards for Smart Devices) Rules 2025 (F2025L00276) add a further layer. Part 1 of the Rules (preliminary provisions) was registered on 4 March 2025. Part 2 and Schedule 1 (the substantive security standards covering passwords, vulnerability disclosure, and support periods) commenced on 4 March 2026, twelve months after registration of the Rules. This means the enforceable compliance date for smart device manufacturers and suppliers under the Australia Cyber Security Act 2024 is 4 March 2026. The Cyber Security (Ransomware Payment Reporting) Rules 2025 (F2025L00278) commenced at the later of the day after registration (4 March 2025) and the commencement of Part 3 of the Act (29 May 2025), meaning 29 May 2025 is the effective date for ransomware reporting obligations. ## Does the Australia Cyber Security Act 2024 apply to every connected product sold in Australia No. This is one of the most frequently asked questions about the Australia Cyber Security Act 2024. The Act defines a broad concept of relevant connectable product in Section 13, covering any product that is an internet connectable product or a network connectable product. However, the Cyber Security (Security Standards for Smart Devices) Rules 2025 narrow the current scope to a single class: consumer grade relevant connectable products. Section 8 of the 2025 Rules defines this class as all relevant connectable products that are intended by the manufacturer to be used, or are of a kind likely to be used, for personal, domestic or household use or consumption. The Rules list six explicit exclusions from that class under Section 8(1)(b). Desktop computers and laptops are excluded. Tablet computers are excluded. Smartphones are excluded. Therapeutic goods within the meaning of the Therapeutic Goods Act 1989 are excluded. Road vehicles within the meaning of the Road Vehicle Standards Act 2018 are excluded. Road vehicle components within the meaning of the same Act are excluded. The specified circumstance is that the product will be acquired in Australia by a consumer, as defined by reference to Section 3 of the Australian Consumer Law. This means the Australia Cyber Security Act 2024 FAQ answer to the applicability question depends on two tests. First, is the product a consumer grade smart device that is not on the exclusion list? Second, will a consumer acquire the product in Australia? If both answers are yes, the product falls within the current scope of the enforceable security standards. ## What types of smart devices are covered by the security standards under the Australia Cyber Security Act 2024 The security standards under the Australia Cyber Security Act 2024 cover a wide range of consumer grade internet connectable and network connectable products. Examples include smart speakers, smart home hubs, connected cameras, connected doorbells, smart TVs, wearable fitness trackers, connected baby monitors, connected toys, smart appliances such as connected refrigerators and washing machines, smart lighting systems, connected routers, and IoT sensors intended for household use. A product qualifies as an internet connectable product under Section 13(4) of the Act if it is capable of connecting to the internet using a communication protocol that forms part of the internet protocol suite to send and receive data. A network connectable product under Section 13(5) is a product that can send and receive data through electrical or electromagnetic energy and can connect directly to an internet connectable product or to two or more other products via a protocol that is not part of the internet protocol suite. The breadth of these definitions in the Australia Cyber Security Act 2024 means that many devices not traditionally considered computers still fall within scope. This frequently asked question about the Australia Cyber Security Act 2024 matters for manufacturers who sell peripherals and accessories. A wireless keyboard and mouse set designed to facilitate the use of a computer may meet the network connectable product test under Sections 13(7) and 13(9) if each input product can connect wirelessly to a linking product that itself connects to an internet connectable product. ## Do suppliers have obligations or does the Australia Cyber Security Act 2024 only apply to manufacturers Suppliers have direct and independent obligations under the Australia Cyber Security Act 2024. This is a frequently asked question because many importers and distributors assume the regulatory burden sits entirely with the original manufacturer. Section 15(3) of the Act states that an entity must not supply a product in Australia if the product was not manufactured in compliance with the applicable security standard and the entity is aware, or could reasonably be expected to be aware, that the product will be acquired in Australia by a consumer. In addition, Section 16(3) requires every entity that supplies a relevant connectable product in Australia to supply the product accompanied by a statement of compliance that meets the requirements set out in the rules. Section 16(4) requires the supplier to retain a copy of the statement of compliance for the period specified in the rules, which the 2025 Smart Devices Rules set at five years under Section 10. For this Australia Cyber Security Act 2024 FAQ, the practical implication is that suppliers must obtain the statement of compliance from the manufacturer before importing or distributing the product. If the manufacturer cannot provide a valid statement, the supplier faces enforcement exposure including compliance notices, stop notices, and recall notices under Division 3 of Part 2. The term 'supplier' and 'supply' carry the same meaning as in the Australian Consumer Law, which means obligations extend across the entire distribution chain. ## What are the three mandatory security requirements for smart devices under the Australia Cyber Security Act 2024 Part 1 of Schedule 1 to the Cyber Security (Security Standards for Smart Devices) Rules 2025 prescribes three categories of mandatory requirements. This is one of the most important technical questions in the Australia Cyber Security Act 2024 FAQ. The first requirement relates to passwords. Clause 2 of Schedule 1 requires that passwords for hardware and for software (whether preinstalled or required for the manufacturer's intended purposes) must be either unique per product or defined by the user. Passwords that are unique per product must not be based on incremental counters such as 'password1' and 'password2'. They must not be based on or derived from publicly available information. They must not be based on unique product identifiers such as serial numbers unless encrypted with good industry practice. They must not be otherwise guessable in a manner unacceptable under good industry practice. The second requirement relates to reports of security issues. Clause 3 requires the manufacturer to publish at least one point of contact allowing any person to report security issues. The manufacturer must also publish the expected timeframe for acknowledging receipt and for providing status updates until resolution. This information must be accessible, clear, transparent, available in English, free of charge, and obtainable without requiring the person to provide personal information. The third requirement relates to defined support periods and security updates. Clause 4 requires the manufacturer to publish the defined support period, expressed as a period of time with an end date, during which the manufacturer will provide security updates. The defined support period must not be shortened after publication. If the support period is extended, the new period must be published as soon as practicable. If the manufacturer sells the product on its website, the support period must appear prominently alongside the main product characteristics. ## What must the statement of compliance include under the Australia Cyber Security Act 2024 The statement of compliance requirements are detailed in Section 9 of the Cyber Security (Security Standards for Smart Devices) Rules 2025. This is a frequently asked question in the Australia Cyber Security Act 2024 FAQ because the statement is the primary compliance document that must travel with every product. The statement must be prepared by, or on behalf of, the manufacturer. Section 9(3) lists seven categories of required content. The statement must include the product type and batch identifier to enable traceability. It must include the name and address of the manufacturer, the name and address of an authorised representative of the manufacturer, and the name and address of each additional authorised representative that is in Australia. It must include a declaration that the statement has been prepared by, or on behalf of, the manufacturer. It must include a declaration that, in the opinion of the manufacturer, the product has been manufactured in compliance with the requirements of the security standard and the manufacturer has complied with any other obligations in the security standard. It must include the defined support period for the product at the date the statement is issued. It must include the signature, name, and function of the signatory of the manufacturer. It must include the place and date of issue. Section 10 of the Rules sets the retention period for the statement of compliance at five years. Both manufacturers under Section 16(2) of the Act and suppliers under Section 16(4) must retain copies for this full period. ## Can a manufacturer shorten the published support period after launch No. Clause 4(4) of Schedule 1 to the 2025 Smart Devices Rules states that the manufacturer must not shorten the defined support period after it is published. This is an absolute prohibition with no exceptions or conditions. The rule is designed to protect consumers who rely on the published support period when making their purchase decision. If the manufacturer extends the defined support period, Clause 4(5) requires the manufacturer to publish the new defined support period as soon as is practicable. This frequently asked question in the Australia Cyber Security Act 2024 FAQ is important for product lifecycle planning. Manufacturers should set a support period they can realistically honour before publishing it, because once published the period can only become longer. Clause 4(7) adds a website prominence rule. If the manufacturer offers the product on its own website or another website under its control, the defined support period must be prominently published alongside the main product characteristics. Clause 4(7)(b) requires that for each instance on the website where the main characteristics of the product are published, the defined support period is given equal prominence. This prevents manufacturers from burying the support period in secondary pages or fine print. ## Who must report a ransomware payment under Part 3 of the Australia Cyber Security Act 2024 Only a reporting business entity has the Part 3 reporting duty. This is a critical distinction in the Australia Cyber Security Act 2024 FAQ. Section 26(2) defines two categories of reporting business entity. The first category under Section 26(2)(a) includes any entity that is carrying on a business in Australia with an annual turnover for the previous financial year that exceeds the turnover threshold, and that is not a Commonwealth body, a State body, or a responsible entity for a critical infrastructure asset. The Cyber Security (Ransomware Payment Reporting) Rules 2025 set this turnover threshold at 3 million Australian dollars under Section 6(1). For businesses that operated for only part of the previous financial year, Section 6(2) provides a proportional formula: 3 million dollars multiplied by the number of days the business operated, divided by the total number of days in the financial year. The second category under Section 26(2)(b) covers a responsible entity for a critical infrastructure asset to which Part 2B of the Security of Critical Infrastructure Act 2018 applies. Entities in this category are caught regardless of their annual turnover. This Australia Cyber Security Act 2024 FAQ answer means that small businesses with annual turnover below 3 million dollars and that do not hold a critical infrastructure asset under SOCI are currently outside the ransomware reporting obligation. However, businesses that crossed the 3 million dollar threshold in the previous financial year are caught regardless of their current year revenue. ## When does the 72 hour reporting deadline for ransomware payments start under the Australia Cyber Security Act 2024 Section 27(1) of the Australia Cyber Security Act 2024 states that the reporting business entity must give the designated Commonwealth body a ransomware payment report within 72 hours of making the ransomware payment or becoming aware that the ransomware payment has been made, whichever is applicable. The 72 hour clock therefore starts at the moment of payment or the moment of awareness, not at the moment the cyber security incident is first detected. Section 27(2) provides an important qualification that is central to this Australia Cyber Security Act 2024 FAQ answer. The report only needs to contain information that the reporting business entity knows or is able, by reasonable search or enquiry, to find out within the 72 hour period. This means the entity is not expected to have completed a full forensic investigation before filing the report. The note to Section 7(1) of the 2025 Ransomware Payment Reporting Rules repeats this qualification. For this frequently asked question about the Australia Cyber Security Act 2024, implementation teams should note two practical points. First, incident response playbooks should include a ransomware payment decision step that automatically triggers the 72 hour countdown. Second, the report must be given in the form approved by the Secretary and in any manner prescribed by the rules under Section 27(4), so teams should familiarise themselves with the approved form before an actual incident arises. ## What information must a ransomware payment report contain under the Australia Cyber Security Act 2024 Section 7 of the Cyber Security (Ransomware Payment Reporting) Rules 2025 prescribes detailed content requirements. This frequently asked question about the Australia Cyber Security Act 2024 matters because incomplete reports can still satisfy the obligation if the entity has performed a reasonable search within the 72 hour window. The report must include the reporting business entity's contact and business details, including the entity's ABN (if any) and address under Section 7(2). If another entity made the payment on behalf of the reporting entity, the other entity's contact details and ABN must also be included under Section 7(3). The report must include information about the cyber security incident and its impact under Section 7(4), covering when the incident occurred or is estimated to have occurred, when the reporting entity became aware of the incident, the impact on the entity's infrastructure, the impact on the entity's customers, what variants of ransomware or other malware were used, what vulnerabilities in the entity's system were exploited, and any information that could assist a Commonwealth body or State body in responding to or resolving the incident. The report must also describe the demand made by the extorting entity under Section 7(5), including the amount or quantum demanded and the method of provision demanded. It must describe the actual ransomware payment under Section 7(6), covering the amount or quantum paid and the method of provision used. Finally, Section 7(7) requires a description of communications with the extorting entity, including the nature and timing of any communications, a brief description of those communications, and a brief description of any pre-payment negotiations. ## What is the penalty for failing to report a ransomware payment under the Australia Cyber Security Act 2024 Under Section 27(5) of the Australia Cyber Security Act 2024, failure to make a required ransomware payment report exposes the entity to a civil penalty of 60 penalty units. Under the Crimes Act 1914, one penalty unit is currently set at 313 Australian dollars for individuals. For bodies corporate, the standard multiplier under the Regulatory Powers (Standard Provisions) Act 2014 can increase the maximum penalty to five times the amount applicable to an individual. This is a frequently asked question in the Australia Cyber Security Act 2024 FAQ because the penalty for failing to report is a civil penalty, not a criminal offence. The Act deliberately avoids criminalising ransomware payments themselves. Instead, the 60 penalty unit civil penalty targets only the failure to report the payment. This design encourages entities to report transparently without fear that the report itself will be used against them in unrelated civil or regulatory proceedings. Section 32 of the Act provides additional protection. Information in a ransomware payment report is not admissible in evidence against the reporting entity in criminal proceedings (except for false statements under Section 137.1 or 137.2 of the Criminal Code or obstruction under Section 149.1), civil penalty proceedings for other laws, proceedings for a breach of other laws, or tribunal proceedings. Section 29 restricts the designated Commonwealth body from using report data to investigate or enforce any civil or regulatory contravention by the reporting entity other than a contravention of Part 3 itself or a criminal offence. Section 28 confirms that entities and their officers, employees, and agents are not liable in damages for acts done in good faith in compliance with the reporting obligation. ## What enforcement tools does the Secretary have for smart device non-compliance under the Australia Cyber Security Act 2024 The Australia Cyber Security Act 2024 provides a staged enforcement path for smart device non-compliance under Division 3 of Part 2. This Australia Cyber Security Act 2024 FAQ answer walks through all three steps and the public notification power. The first step is a compliance notice under Section 17. The Secretary may issue a compliance notice if the Secretary is reasonably satisfied that the entity is not complying with an obligation under Section 15 or 16, or is aware of information suggesting possible non-compliance. The notice must set out the name of the entity, brief details of the non-compliance, specify corrective action, and set a reasonable period for completion. Before issuing the notice, the Secretary must give the entity at least 10 days to make representations under Section 17(3). Only one compliance notice may be given per instance of non-compliance. The second step is a stop notice under Section 18. The Secretary may issue a stop notice only if a compliance notice has already been given and the entity has either failed to comply or taken inadequate corrective action. The stop notice can require the entity to take or refrain from taking specified action. Again, the entity must receive at least 10 days to make representations before the notice is issued. The third step is a recall notice under Section 19. The Secretary may issue a recall notice only if a stop notice has already been given and the entity has failed to comply or taken inadequate corrective action. The recall notice can require the entity to prevent acquisition of the product in Australia, prevent supply to other suppliers, or arrange for the return of the product to the manufacturer. If the entity fails to comply with a recall notice, Section 20 allows the Minister to publish the identity of the entity, details of the product, details of the non-compliance, and the associated risks on the Department website or in any other way the Minister considers appropriate. Section 23 provides an additional tool. The Secretary may engage an independent expert to examine the product and determine whether it complies with the security standard and whether the statement of compliance meets the requirements. The entity is entitled to reasonable compensation from the Commonwealth for providing the product for testing. ## How does the Australia Cyber Security Act 2024 interact with the Security of Critical Infrastructure Act 2018 The Australia Cyber Security Act 2024 and the Security of Critical Infrastructure Act 2018 (SOCI) are designed to work together, not to replace each other. This is one of the most frequently asked questions in the Australia Cyber Security Act 2024 FAQ for entities that hold critical infrastructure assets. For ransomware payment reporting, Section 26(2)(b) of the Act explicitly includes a responsible entity for a critical infrastructure asset to which Part 2B of SOCI applies as a reporting business entity. This means SOCI regulated entities are automatically within scope for the ransomware reporting obligation regardless of their turnover. They do not need to satisfy the 3 million dollar threshold set in the Ransomware Payment Reporting Rules. For incident coordination, Part 4 of the Australia Cyber Security Act 2024 allows impacted entities to voluntarily share information with the National Cyber Security Coordinator. Section 35(1)(d) expressly covers entities that are responsible entities for critical infrastructure assets. Section 44 states that information provided under Part 4 does not discharge any separate obligation under SOCI or any other Commonwealth law. This means a SOCI regulated entity that voluntarily reports to the Coordinator must still comply with all SOCI Part 2B notification obligations independently. The Act also borrows several definitions directly from SOCI. The definition of cyber security incident in Section 9(1) incorporates the SOCI meaning. The definitions of critical infrastructure asset, responsible entity, and computer all have the same meaning as in SOCI. This alignment means that teams familiar with SOCI terminology will find the Australia Cyber Security Act 2024 definitions largely consistent. ## What compliance evidence should organisations retain for the Australia Cyber Security Act 2024 The Act and the 2025 subordinate rules create several explicit record retention obligations. This Australia Cyber Security Act 2024 FAQ answer consolidates them for implementation teams seeking to build a compliance evidence package. For smart device compliance, manufacturers and suppliers must each retain a copy of the statement of compliance for five years under Section 10 of the 2025 Smart Devices Rules. The statement itself must include the product type and batch identifier, manufacturer and authorised representative details, the required declarations of compliance, the defined support period at the date of issue, and the signatory details with place and date. Organisations should store these statements in a document management system that supports version control and audit trails. For ransomware payment reporting, the 72 hour report must be filed with the designated Commonwealth body using the Secretary's approved form. Organisations should retain a timestamped copy of every ransomware payment report and a record of the circumstances that triggered the 72 hour clock, including the exact date and time of the payment or the exact date and time of becoming aware that the payment was made. For voluntary incident sharing under Part 4, there is no mandatory retention period, but organisations should retain records of what was shared with the National Cyber Security Coordinator. Section 42 provides that voluntarily shared information is not admissible against the impacted entity, but this protection only applies to information actually provided under Subsection 35(2) or as referred to in Subsection 39(1). Maintaining clear records of what was shared and when helps the entity invoke these protections if they are ever needed in proceedings. ## Does the Australia Cyber Security Act 2024 apply outside Australian territory Yes. Section 5 of the Act states that the Act applies both within and outside Australia, and a note confirms that it extends to every external Territory. This is a frequently asked question in the Australia Cyber Security Act 2024 FAQ for overseas manufacturers that export consumer grade smart devices to the Australian market. For smart device standards, the trigger is whether the manufacturer is aware, or could reasonably be expected to be aware, that the product will be acquired in Australia by a consumer under Sections 15(1)(b) and 16(1)(b). A manufacturer based in China, Taiwan, the United States, or the European Union that sells directly to Australian consumers or through Australian distributors will need to comply with the security standards and provide a statement of compliance. For ransomware reporting, the trigger under Section 26(2)(a) is whether the entity is carrying on a business in Australia. An overseas entity with Australian operations that exceeds the 3 million dollar annual turnover threshold is subject to the reporting obligation. Section 15(5) provides a constitutional nexus exception: to the extent a security standard requirement does not relate to internet connectivity, internet usage, or protective measures against internet based attacks, compliance is only required for entities that are constitutional corporations or engaged in interstate or international trade. This frequently asked question about the Australia Cyber Security Act 2024 is particularly relevant for global supply chain teams managing multi-jurisdictional compliance. ## What role does the Cyber Incident Review Board play under the Australia Cyber Security Act 2024 Part 5 of the Australia Cyber Security Act 2024 establishes the Cyber Incident Review Board under Section 60. This Australia Cyber Security Act 2024 FAQ answer explains the Board's function for teams that may be subject to a review. The Board's primary function under Section 62 is to cause reviews to be conducted in relation to certain cyber security incidents and to make recommendations to government and industry about actions that could prevent, detect, respond to, or minimise the impact of similar incidents in the future. The Board is led by a Chair appointed by the Minister under Section 64 and includes standing members appointed under Section 66 and an Expert Panel established under Section 70. The Chair may request information or documents under Section 48 and may require certain entities to produce documents under Section 49. Failure to comply with a notice to produce documents carries a civil penalty of 60 penalty units under Section 50. Reviews result in a draft review report under Section 51 that is shared with affected entities for comment, and then a final review report under Section 52 that is published with redactions for sensitive review information under Section 53. Protected review reports containing unredacted sensitive information are not published. The Board must not perform a function at a particular time if doing so would prejudice the investigation of a criminal offence or a civil penalty contravention under Section 62(4). Section 88 provides for parliamentary oversight. The Parliamentary Joint Committee on Intelligence and Security may review the operation, effectiveness, and implications of the entire Australia Cyber Security Act 2024, with the review required to begin as soon as practicable after 1 December 2027. ## Is information shared with the National Cyber Security Coordinator protected from enforcement proceedings Yes. This is one of the most important safe harbour questions in the Australia Cyber Security Act 2024 FAQ. Section 38 provides that the National Cyber Security Coordinator may only use or disclose information voluntarily provided under Subsection 35(2) for the purpose of assisting the impacted entity to respond to the incident or for a permitted cyber security purpose as defined in Section 10. Section 38(2) explicitly prohibits the Coordinator from using the information to investigate or enforce any civil or regulatory contravention by the impacted entity, other than a contravention of Part 4 itself or a criminal offence. Section 42 further provides that voluntarily shared information is not admissible in evidence against the impacted entity in criminal proceedings (except for false statements or obstruction offences under the Criminal Code), civil penalty proceedings, breach proceedings, or tribunal proceedings. These protections were designed to overcome the reluctance of impacted entities to share incident data with government. However, the protections have boundaries. They do not extend to information the entity has also provided under Part 3 ransomware reporting, SOCI Part 2B, or the Telecommunications Act 1997 under Subsection 38(4). They do not cover information already lawfully available to the public. And the protections do not apply to coronial inquiries or Royal Commissions under Section 42(3). This Australia Cyber Security Act 2024 FAQ answer is essential for legal counsel advising on voluntary disclosure strategy. ## Can an entity seek internal review of an enforcement notice under the Australia Cyber Security Act 2024 Yes. Section 22 of the Act provides that an entity may apply in writing to the Secretary for internal review of a decision to issue a compliance notice under Section 17, a stop notice under Section 18, a recall notice under Section 19, or a variation of any such notice under Section 21. The application must be made within 30 days after the notice was given to the entity. The decision maker for the internal review is the Secretary or, if the Secretary made the original decision personally, a delegate who was not involved in the original decision under Section 22(3). The decision maker must complete the review within 30 days and must affirm, vary, or revoke the original decision under Section 22(4). A written statement of reasons must be provided as soon as practicable under Section 22(5). This frequently asked question in the Australia Cyber Security Act 2024 FAQ matters because the internal review mechanism is the first available avenue for challenging an enforcement decision. Before any enforcement notice is issued, the Secretary must give the entity at least 10 days to make representations under Sections 17(3), 18(3), and 19(3). This pre-notice consultation step, combined with the 30 day internal review right, provides two layers of procedural fairness before enforcement escalates. Only one compliance notice, stop notice, or recall notice may be issued per instance of non-compliance, ensuring enforcement actions are proportionate. ## How does the Australia Cyber Security Act 2024 compare to the UK Product Security and Telecommunications Infrastructure Act 2022 This is a frequently asked question in the Australia Cyber Security Act 2024 FAQ for manufacturers selling into multiple jurisdictions. The UK PSTI Act 2022 and the Australia Cyber Security Act 2024 share a common heritage in the ETSI EN 303 645 standard and both focus on the same three baseline requirements: unique or user defined passwords, a vulnerability disclosure mechanism, and a published support period. The key differences are in scope and enforcement. The UK PSTI Act covers all consumer connectable products and does not exclude smartphones and tablets to the same extent, whereas the current Australian rules explicitly exclude smartphones, tablets, laptops, desktop computers, therapeutic goods, road vehicles, and road vehicle components. The UK regime imposes penalties of up to 10 million British pounds or 4 percent of worldwide annual revenue, while the Australian regime uses a staged notice system (compliance, stop, recall) backed by civil penalties measured in penalty units. Both regimes require the manufacturer to publish the defined support period alongside the product's main characteristics when the product is sold online. Both prohibit shortening the support period after publication. The Australian regime adds a specific requirement under Clause 3 of Schedule 1 that security issue reporting information must be available in English and free of charge without requiring personal information from the reporter. Products already compliant with the UK PSTI requirements may be able to reuse much of their compliance evidence for the Australian market, but teams should verify every Australian specific requirement independently. ## How does the Australia Cyber Security Act 2024 compare to the EU Cyber Resilience Act The EU Cyber Resilience Act (CRA) and the Australia Cyber Security Act 2024 both regulate the cybersecurity of connected products, but the EU CRA is considerably broader in scope and more prescriptive in its technical requirements. This comparison is a frequently asked question in the Australia Cyber Security Act 2024 FAQ for multinational product teams managing compliance across multiple markets. The EU CRA applies to all products with digital elements placed on the EU market, including commercial and industrial products, and it introduces tiered conformity assessment categories (default, important Class I, important Class II, and critical). The Australia Cyber Security Act 2024 currently applies only to consumer grade relevant connectable products through the 2025 Smart Devices Rules and does not introduce risk based product tiers. The EU CRA imposes ongoing vulnerability handling obligations, mandatory incident reporting to ENISA within 24 hours of exploitation awareness, and CE marking requirements. The Australian regime focuses on three baseline requirements (passwords, vulnerability disclosure, and support periods) and does not require vulnerability reporting by manufacturers. However, Section 14 of the Australia Cyber Security Act 2024 gives the Minister broad rule making authority to expand security standards to additional product classes and to adopt external standards by reference, which could narrow the gap between the two regimes over time. *Recommended next step* *Placement: after the FAQ section* ## Use Australia Cyber Security Act 2024 FAQ as a cited research workflow Research Copilot can take Australia Cyber Security Act 2024 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on Australia Cyber Security Act 2024 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Australia Cyber Security Act 2024 FAQ](/solutions/research-copilot.md): Start from Australia Cyber Security Act 2024 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Australia Cyber Security Act 2024](/contact.md): Review your current process, evidence gaps, and next steps for Australia Cyber Security Act 2024 FAQ. ## Primary sources - [Cyber Security Act 2024 (Australia) official text](https://www.legislation.gov.au/C2024A00098/latest/text?ref=sorena.io) - Primary source for all Act level questions in this Australia Cyber Security Act 2024 FAQ, including Parts 1 through 7. - [Cyber Security (Security Standards for Smart Devices) Rules 2025 official text](https://www.legislation.gov.au/F2025L00276/asmade/text?ref=sorena.io) - Primary source for the three mandatory security standards, product exclusions, statement of compliance contents, and defined support period requirements. - [Cyber Security (Ransomware Payment Reporting) Rules 2025 official text](https://www.legislation.gov.au/F2025L00278/asmade/text?ref=sorena.io) - Primary source for the 3 million dollar turnover threshold, 72 hour reporting window, and ransomware payment report content requirements. ## Related Topic Guides - [Australia Cyber Security Act 2024 Applicability Test | Who Must Comply](/artifacts/apac/australia-cyber-security-act/applicability-test.md): Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations. - [Australia Cyber Security Act 2024 Compliance Checklist](/artifacts/apac/australia-cyber-security-act/checklist.md): Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting. - [Australia Cyber Security Act 2024 Compliance Guide | Implementation Playbook](/artifacts/apac/australia-cyber-security-act/compliance.md): A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements. - [Australia Cyber Security Act 2024 Compliance Templates | Statement of Compliance, Ransomware Report, Evidence Pack, Vulnerability Disclosure, Support Period](/artifacts/apac/australia-cyber-security-act/templates.md): Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field. - [Australia Cyber Security Act 2024 Deadlines and Compliance Calendar | Commencement Dates](/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar.md): Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent. - [Australia Cyber Security Act 2024 Requirements | Smart Device and Ransomware Reporting Obligations](/artifacts/apac/australia-cyber-security-act/requirements.md): Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure. - [Australia Cyber Security Act 2024 Timeline and Commencement Dates | Full Schedule](/artifacts/apac/australia-cyber-security-act/timeline-and-commencement.md): Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024. - [Australia Cyber Security Act 2024 vs EU Cyber Resilience Act | Full CRA Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act.md): Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements. - [Australia Cyber Security Act 2024 vs UK PSTI Act | Product Security Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act.md): Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements. - [Australia Smart Device Compliance Checklist | Cyber Security Act 2024 | Sorena](/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist.md): Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure. - [Penalties and fines | Australia Cyber Security Act 2024 | 60 Penalty Units, Smart Device Enforcement, Ransomware Reporting](/artifacts/apac/australia-cyber-security-act/penalties-and-fines.md): Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals. - [Ransomware Payment Reporting in 72 Hours | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours.md): Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. - [Scope and Definitions | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/scope-and-definitions.md): Complete guide to the Australia Cyber Security Act 2024 scope and definitions. - [Smart device security standards | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/smart-device-security-standards.md): Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2. - [Statement of Compliance and Recordkeeping | Australia Cyber Security Act 2024 | Section 9, Section 10, 5 Year Retention](/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping.md): Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/australia-cyber-security-act/faq --- --- title: "Penalties and fines" canonical_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/penalties-and-fines" author: "Sorena AI" description: "Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "Australia Cyber Security Act penalties" - "Cyber Security Act 2024 fines" - "60 penalty units AUD 19800" - "ransomware reporting penalty Australia" - "smart device compliance notice" - "stop notice recall notice Australia" - "civil penalty body corporate 300 penalty units" - "Regulatory Powers enforcement" - "Australia cyber enforcement framework" - "protected information penalty" - "compliance notice smart device" - "Part 2 enforcement path" - "penalty unit $330" - "SOCI Act penalties comparison" - "infringement notice cyber security" - "civil penalty 60 penalty units" - "ransomware reporting penalty" - "recall notice" - "APAC compliance enforcement" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Penalties and fines Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals. *Enforcement Guide* *APAC* ## Australia Cyber Security Act 2024 Penalties and Fines Six civil penalty provisions at 60 penalty units each (AUD 19,800 per individual contravention, up to AUD 99,000 for a body corporate), a staged smart device enforcement path, and the Regulatory Powers framework working behind both. The penalty number is only part of the picture. Compliance notices, stop notices, recall notices, investigations, monitoring powers, infringement notices, enforceable undertakings, and injunctions can all reach you before a court order is sought. The Australia Cyber Security Act 2024 uses two enforcement channels. Smart device (Part 2) failures escalate through compliance notices, stop notices, and recall notices. Ransomware reporting failures and protected information misuse carry express civil penalties of 60 penalty units per contravention, which equals AUD 19,800 for individuals and up to AUD 99,000 for bodies corporate under the 5x multiplier at the current penalty unit rate of AUD 330. The Regulatory Powers (Standard Provisions) Act 2014 adds monitoring, investigation, enforceable undertakings, injunctions, and infringement notices across all civil penalty provisions. This page maps every penalty provision, enforcement lever, penalty calculation method, procedural safeguard, and practical risk-reduction step teams should have in place. ## How penalty units work and what they mean in dollar terms The Australia Cyber Security Act 2024 penalties are expressed in penalty units, not dollar amounts. The value of one Commonwealth penalty unit is set by section 4AA of the Crimes Act 1914 and equals AUD 330 for contraventions occurring on or after 7 November 2024. The Cyber Security Act 2024 received Royal Assent on 29 November 2024, so every contravention under this Act uses the AUD 330 rate. That value is subject to indexation and may increase from 1 July 2026. The Act contains six express civil penalty provisions, all set at 60 penalty units. At AUD 330 per unit, 60 penalty units equals AUD 19,800 per contravention for an individual. Under section 82(5) of the Regulatory Powers (Standard Provisions) Act 2014, if the triggering legislation does not specify a separate body corporate penalty, the maximum for a body corporate is five times the stated amount. This multiplier raises the effective maximum to 300 penalty units or AUD 99,000 per contravention for a body corporate. These are maximum penalties. A court determines the actual amount based on circumstances, conduct, and harm. Section 87(2)(a) of the Act expressly prevents the rules from creating additional offences or civil penalties. Only the primary legislation can establish penalty provisions, so these six are the complete set. The penalty unit value applies to both civil penalty order proceedings and infringement notice calculations. An infringement notice penalty is typically one fifth of the maximum court penalty, meaning approximately 12 penalty units (AUD 3,960) for an individual per contravention. - One Commonwealth penalty unit equals AUD 330 from 7 November 2024 (Crimes Act 1914, section 4AA). This value is subject to indexation from 1 July 2026. - 60 penalty units equals AUD 19,800 for an individual and up to AUD 99,000 for a body corporate at the current rate. - The body corporate multiplier of five times applies under section 82(5) of the Regulatory Powers Act when the Act does not specify a separate body corporate amount. - An infringement notice penalty for a 60 penalty unit provision is approximately 12 penalty units (AUD 3,960 for an individual). - Section 27(5): Failure to report a ransomware payment within 72 hours carries a civil penalty of 60 penalty units (AUD 19,800 individual, up to AUD 99,000 body corporate). - Section 30(6): Prohibited secondary use or disclosure of ransomware payment report information carries a civil penalty of 60 penalty units. - Section 40(6): Prohibited secondary use or disclosure of information shared with the National Cyber Security Coordinator carries a civil penalty of 60 penalty units. - Section 50(1): Failure to comply with a Board document production notice carries a civil penalty of 60 penalty units. - Section 56(6): Prohibited secondary use or disclosure of Board review information carries a civil penalty of 60 penalty units. - Section 59(1): Disclosure of draft review reports from the Board carries a civil penalty of 60 penalty units. ## Smart device enforcement path under Part 2 of the Cyber Security Act For Part 2 product obligations, the Secretary operates a staged enforcement path. Each stage escalates the response and the consequences. Businesses that treat early notices as routine correspondence, rather than serious escalation events, risk finding themselves at the recall stage faster than expected. The Act limits each notice type to one per particular instance of non-compliance. This means the Secretary cannot issue multiple compliance notices for the same problem. But each new product or each new standard failure can start its own enforcement chain independently. - Step 1, Compliance Notice (section 17): The Secretary issues this when reasonably satisfied that an entity is not complying with sections 15 or 16, or is aware of information suggesting possible non-compliance. Must specify corrective action and set a reasonable compliance period - Step 2, Stop Notice (section 18): Follows when the entity has received a compliance notice and the Secretary is reasonably satisfied the entity has not complied or remedial actions are inadequate. Can specify actions the entity must take or must refrain from taking - Step 3, Recall Notice (section 19): Follows when the entity has received a stop notice and the Secretary is reasonably satisfied the entity has not complied. Can require the entity to ensure the product is not acquired in Australia, not supplied to suppliers, and arrange return of products - Step 4, Public Notification (section 20): If the entity fails to comply with a recall notice, the Minister may publish the entity identity, product details, non-compliance details, and risks posed by the product on the Department website or in any other manner considered appropriate *Recommended next step* *Placement: after the enforcement section* ## Use Australia Cyber Security Act 2024 Penalties and Fines as a cited research workflow Research Copilot can take Australia Cyber Security Act 2024 Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on Australia Cyber Security Act 2024 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Australia Cyber Security Act 2024 Penalties and Fines](/solutions/research-copilot.md): Start from Australia Cyber Security Act 2024 Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Australia Cyber Security Act 2024](/contact.md): Review your current process, evidence gaps, and next steps for Australia Cyber Security Act 2024 Penalties and Fines. ## Ransomware reporting penalties under the Australia Cyber Security Act 2024 The most significant Australia Cyber Security Act 2024 penalty for day-to-day operations is the 60 penalty unit fine for failure to submit a ransomware payment report within 72 hours (section 27). At the current rate, this penalty equals AUD 19,800 for an individual and up to AUD 99,000 for a body corporate. The reporting obligation applies to reporting business entities, which are entities carrying on business in Australia with annual turnover exceeding AUD 3 million in the previous financial year, or entities that are responsible for a critical infrastructure asset under Part 2B of the Security of Critical Infrastructure Act 2018. The Ransomware Payment Reporting Rules 2025 prescribe the AUD 3 million threshold. For partial-year businesses, the threshold is pro-rated using the formula: AUD 3 million multiplied by the number of days in operation divided by the total days in the financial year. The 72-hour clock starts from the moment the ransomware payment is made or the moment the reporting business entity becomes aware that the payment has been made, whichever is applicable. Importantly, section 27(6) disapplies subsection 93(2) of the Regulatory Powers Act for this contravention. This means the standard reasonable steps defence is not available for ransomware reporting failures under the Australia Cyber Security Act 2024. The entity cannot argue that it took reasonable steps to prevent the contravention. Section 28 provides a good faith safe harbour: an entity is not liable for damages for acts done or omitted in good faith in compliance with the reporting obligation, but this does not reduce the civil penalty itself. - The 72-hour reporting clock starts from the moment the entity makes the payment or becomes aware it was made. - Civil penalty for failure to report: 60 penalty units (AUD 19,800 individual, up to AUD 99,000 body corporate). - Information in the report must include entity ABN, incident timing, impact on infrastructure and customers, ransomware variants, vulnerabilities exploited, payment amount and method, and communications with the extorting entity. - Information is only required to the extent the entity knows or can find out by reasonable search within the 72-hour window. - The AUD 3 million turnover threshold captures approximately 6.56 percent of Australian businesses according to the Explanatory Statement. - Section 93(2) of the Regulatory Powers Act is disapplied for section 27, meaning the standard reasonable steps defence is not available for ransomware reporting failures. - Ransomware payment report information is not admissible against the reporting entity in most criminal, civil, or tribunal proceedings (section 32). - The good faith safe harbour under section 28 protects against damages claims but does not reduce the civil penalty for late or missed reporting. ## Protected information penalties and the information safeguard framework The Act creates civil penalties for unauthorized use or disclosure of protected information across three separate Parts. Each provision targets non-Commonwealth officers who handle sensitive, confidential, or commercially sensitive information obtained under the Act. Commonwealth officers who misuse protected information face criminal offences under the Criminal Code, not civil penalties. These civil penalty provisions are triggered when the information is sensitive information about an individual disclosed without consent, confidential or commercially sensitive information, or information whose disclosure would damage Commonwealth security, defence, or international relations. Understanding these categories is essential because the trigger is about the nature of the information, not just the act of disclosure. - Section 30(6) covers ransomware report information under Part 3, carrying a civil penalty of 60 penalty units - Section 40(6) covers information voluntarily shared with the National Cyber Security Coordinator under Part 4, carrying a civil penalty of 60 penalty units - Section 56(6) covers information provided to the Cyber Incident Review Board under Part 5, carrying a civil penalty of 60 penalty units - Section 59(1) covers unauthorized disclosure of a draft review report, with exceptions for preparing submissions, using the entity's own information, acting with Chair consent, or after information becomes lawfully public - No evidential burden falls on the entity claiming an exception under section 59(3), which shifts the practical proof requirement to the regulator ## Regulatory Powers enforcement framework behind the penalties The civil penalty provisions sit inside the Regulatory Powers (Standard Provisions) Act 2014, which gives enforcement authorities a toolkit well beyond the penalty amount itself. The Secretary and appointed SES employees can pursue civil penalty orders through the Federal Court of Australia, the Federal Circuit and Family Court (Division 2), and State or Territory courts with appropriate jurisdiction. Enforcement also extends to enforceable undertakings for all civil penalty provisions and for sections 15 and 16 (smart device security standards). This means the Secretary can accept formal compliance commitments even where no civil penalty has been imposed. Monitoring powers under Part 2 of the Regulatory Powers Act apply to all civil penalty provisions and smart device standards, but cannot be exercised against residential premises. - Civil penalty orders are sought by the Secretary or appointed CEO/SES employees of designated Commonwealth bodies through the Federal Court or Federal Circuit and Family Court - Enforceable undertakings cover all six civil penalty provisions and sections 15 and 16, allowing the Secretary to accept formal compliance commitments - Monitoring powers include entry and inspection of business premises by APS employees under a magistrate-issued warrant, but exclude residential premises - Investigation powers under Part 3 include search and seizure warrants issued by a magistrate for all civil penalty provisions - Infringement notices under Part 5 can be issued by SES employees or equivalent for all civil penalty provisions, though the Crown is not liable to receive them - Injunctions under Part 7 can restrain a person from contravening, or compel compliance with, any civil penalty provision ## Review rights and procedural safeguards for enforcement notices The Act builds in multiple procedural protections. Before issuing any enforcement notice (compliance, stop, or recall), the Secretary must notify the entity of the intent to issue the notice and provide at least 10 days for the entity to make representations. This pre-notice representation right applies to notice variations as well. Entities can apply for internal review of compliance, stop, and recall notices, and of notice variations. The application must be made in writing within 30 days of the notice being given. The reviewing decision-maker must decide within 30 days and can affirm, vary, or revoke the original decision. A written statement of reasons must be provided as soon as practicable after the decision. - Pre-notice representation period is at least 10 days before any compliance notice, stop notice, recall notice, or notice variation is issued - Internal review applications must be made in writing within 30 days of the notice being given - The reviewing decision-maker must complete the review within 30 days of receiving the application - If the Secretary made the original decision personally, a delegate who was not involved in the original decision must conduct the review - The Secretary may also engage an independent expert to examine a product for compliance under section 23, with the entity entitled to reasonable compensation from the Commonwealth for complying with examination requests ## Non-admissibility protections and safe harbours under the Cyber Security Act A major policy feature of the Australia Cyber Security Act 2024 is the set of non-admissibility protections designed to encourage reporting. Information in ransomware payment reports (section 32), information voluntarily provided to the National Cyber Security Coordinator (section 42), and information provided to the Cyber Incident Review Board (section 58) is not admissible against the reporting entity in criminal proceedings, civil penalty proceedings, or tribunal proceedings. Entities and their officers, employees, and agents also benefit from a liability safe harbour (section 28). They are not liable for damages for acts done in good faith in compliance with ransomware reporting obligations. The same protection extends under section 74 to entities complying with Board document production notices. Additionally, providing information under the Act does not waive legal professional privilege in proceedings, except for coronial inquiries and Royal Commissions. - Ransomware payment report information cannot be used against the reporting entity in criminal, civil penalty, or tribunal proceedings under section 32 - Information shared voluntarily with the National Cyber Security Coordinator cannot be used against the entity under section 42 - Information provided to the Cyber Incident Review Board cannot be used against the entity under section 58 - Narrow exceptions exist for false information offences under Criminal Code sections 137.1, 137.2, and obstruction under section 149.1 - Legal professional privilege is preserved when providing information under the Act, so disclosures to the regulator do not open the door to discovery in unrelated litigation ## Non-legal person liability and the accountable person rules Section 85 of the Australia Cyber Security Act 2024 extends penalty exposure to non-legal persons such as partnerships, trusts, and unincorporated associations. When an entity that is not a legal person contravenes the Act, the contravention is attributed to each accountable person who did the relevant act, aided or abetted the act, counselled or procured the act, or was in any way knowingly concerned in the act. This means that Australia Cyber Security Act 2024 fines and penalties can reach individuals who stand behind non-corporate structures. The definition of accountable person depends on the entity type. For a partnership with individual partners, the accountable person is the individual partner. For a partnership with body corporate partners, the accountable person is a director of that body corporate. For a trust with an individual trustee, the accountable person is the trustee. For a trust with a body corporate trustee, the accountable person is a director of that body corporate. For an unincorporated association, the accountable person is a member of the governing body. - Section 85 applies civil penalties to accountable persons within partnerships, trusts, and unincorporated associations. - Partners (individual or body corporate directors) are accountable persons for partnership contraventions. - Trustees (individual or body corporate directors) are accountable persons for trust contraventions. - Members of the governing body are accountable persons for unincorporated association contraventions. - Liability extends to anyone who did the act, aided it, counselled it, procured it, or was knowingly concerned in the contravention. - This provision ensures that Australia Cyber Security Act 2024 penalties cannot be avoided by using non-corporate entity structures. ## Comparison of Australia Cyber Security Act 2024 penalties with SOCI Act penalties Organisations that are responsible entities for critical infrastructure assets may face penalties under both the Australia Cyber Security Act 2024 and the Security of Critical Infrastructure Act 2018 (SOCI Act). Understanding the relationship between these two penalty regimes is essential for enforcement risk planning. The SOCI Act carries penalties of up to 200 penalty units (AUD 66,000 at the current rate) for failures relating to critical infrastructure risk management programs, 150 penalty units (AUD 49,500) for annual reporting failures, and 50 penalty units (AUD 16,500) for failure to notify the regulator about a cyber security incident. The Australia Cyber Security Act 2024 penalties for ransomware reporting failures (60 penalty units) are separate from and additional to any SOCI Act reporting obligations. A responsible entity for a critical infrastructure asset that makes a ransomware payment must comply with the 72-hour ransomware payment reporting obligation under the Cyber Security Act 2024 and may also need to report the underlying cyber security incident under Part 2B of the SOCI Act within 12 hours for critical incidents or 72 hours for other reportable incidents. Dual-regulated entities face penalty exposure under both Acts simultaneously. While the per-contravention penalty amounts under the Australia Cyber Security Act 2024 are lower than the highest SOCI Act penalties, the Cyber Security Act enforcement framework is broader in several respects. The Regulatory Powers Act integration gives the regulator monitoring, investigation, infringement notice, enforceable undertaking, and injunction powers for every civil penalty provision. Both Acts use the Regulatory Powers (Standard Provisions) Act 2014 for enforcement, so dual-regulated entities should map both penalty regimes against their operations and ensure that reporting workflows satisfy both Acts. - SOCI Act: up to 200 penalty units (AUD 66,000) for critical infrastructure risk management program failures. - SOCI Act: 150 penalty units (AUD 49,500) for annual reporting failures. - SOCI Act: 50 penalty units (AUD 16,500) for failure to notify about a cyber security incident. - Cyber Security Act 2024: 60 penalty units (AUD 19,800 individual, up to AUD 99,000 body corporate) for ransomware payment reporting failures. - Ransomware reporting under the Cyber Security Act 2024 is separate from SOCI Act incident reporting obligations. - A critical infrastructure entity that makes a ransomware payment may face penalty exposure under both Acts simultaneously. - Both Acts use the Regulatory Powers (Standard Provisions) Act 2014 for enforcement, including infringement notices, undertakings, and injunctions. ## How to reduce Australia Cyber Security Act 2024 penalty and enforcement risk The strongest defence against enforcement action is a current evidence trail that demonstrates diligence, control, and responsiveness. If your team can show how the product met the standard, how the statement of compliance was issued, how the ransomware reporting decision was handled, and how protected information is controlled, you are in a significantly better position than a business reconstructing facts after a notice arrives. Design your evidence model around the six civil penalty provisions and the three-stage smart device enforcement path. Assign owners to each obligation, define evidence collection points in your existing workflows, and test retrieval before a regulator asks. - Keep version-specific product evidence and issued statements of compliance together, with clear links between each product release and its conformity assessment - Retain screenshots or archived copies of the public support period declaration and vulnerability reporting pages for each smart device product - Maintain an incident chronology for any event involving extortion, unauthorized access, or a payment decision, including timestamps, decision-makers, and communications - Escalate notice receipt immediately to legal, executive, and product owners, and confirm receipt within the team within 24 hours - Run mock regulator requests at least annually so that evidence retrieval, approval paths, and representation drafting are tested under realistic conditions - Implement access controls and audit logs for all protected information received under the Act, so that any secondary use or disclosure can be traced and justified ## Primary sources - [Cyber Security Act 2024 (Australia) official text](https://www.legislation.gov.au/C2024A00098/latest/text?ref=sorena.io) - Primary source for all six civil penalty provisions (sections 27, 30, 40, 50, 56, 59), the smart device enforcement path (sections 17-20), internal review rights (section 22), non-admissibility protections (sections 32, 42, 58), non-legal person liability (section 85), and the Regulatory Powers framework (sections 79-83). - [Cyber Security (Security Standards for Smart Devices) Rules 2025 official text](https://www.legislation.gov.au/F2025L00276/asmade/text?ref=sorena.io) - Prescribes the smart device security standard. Failure against the prescribed standard can trigger the Part 2 enforcement path of compliance, stop, and recall notices. - [Cyber Security (Ransomware Payment Reporting) Rules 2025 official text](https://www.legislation.gov.au/F2025L00278/asmade/text?ref=sorena.io) - Sets the AUD 3 million annual turnover threshold for reporting business entities, the partial-year pro-rating formula, and the detailed information requirements for ransomware payment reports. - [Crimes Act 1914 (Cth), section 4AA: penalty unit value](https://www.legislation.gov.au/C1914A00012/latest/text?ref=sorena.io) - Defines the Commonwealth penalty unit value as AUD 330 from 7 November 2024, with indexation provisions. Used to calculate the dollar amount of all civil penalties in the Australia Cyber Security Act 2024. - [Regulatory Powers (Standard Provisions) Act 2014 official text](https://www.legislation.gov.au/C2014A00093/latest/text?ref=sorena.io) - Provides the enforcement framework for monitoring, investigation, civil penalty orders, infringement notices, enforceable undertakings, and injunctions referenced throughout Part 6 of the Cyber Security Act 2024. - [Security of Critical Infrastructure Act 2018 official text](https://www.legislation.gov.au/C2018A00029/latest/text?ref=sorena.io) - Used for comparison of penalty regimes. Critical infrastructure entities may face penalty exposure under both the SOCI Act and the Australia Cyber Security Act 2024. ## Related Topic Guides - [Australia Cyber Security Act 2024 Applicability Test | Who Must Comply](/artifacts/apac/australia-cyber-security-act/applicability-test.md): Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations. - [Australia Cyber Security Act 2024 Compliance Checklist](/artifacts/apac/australia-cyber-security-act/checklist.md): Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting. - [Australia Cyber Security Act 2024 Compliance Guide | Implementation Playbook](/artifacts/apac/australia-cyber-security-act/compliance.md): A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements. - [Australia Cyber Security Act 2024 Compliance Templates | Statement of Compliance, Ransomware Report, Evidence Pack, Vulnerability Disclosure, Support Period](/artifacts/apac/australia-cyber-security-act/templates.md): Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field. - [Australia Cyber Security Act 2024 Deadlines and Compliance Calendar | Commencement Dates](/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar.md): Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent. - [Australia Cyber Security Act 2024 FAQ | Frequently Asked Questions](/artifacts/apac/australia-cyber-security-act/faq.md): Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024. - [Australia Cyber Security Act 2024 Requirements | Smart Device and Ransomware Reporting Obligations](/artifacts/apac/australia-cyber-security-act/requirements.md): Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure. - [Australia Cyber Security Act 2024 Timeline and Commencement Dates | Full Schedule](/artifacts/apac/australia-cyber-security-act/timeline-and-commencement.md): Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024. - [Australia Cyber Security Act 2024 vs EU Cyber Resilience Act | Full CRA Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act.md): Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements. - [Australia Cyber Security Act 2024 vs UK PSTI Act | Product Security Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act.md): Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements. - [Australia Smart Device Compliance Checklist | Cyber Security Act 2024 | Sorena](/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist.md): Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure. - [Ransomware Payment Reporting in 72 Hours | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours.md): Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. - [Scope and Definitions | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/scope-and-definitions.md): Complete guide to the Australia Cyber Security Act 2024 scope and definitions. - [Smart device security standards | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/smart-device-security-standards.md): Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2. - [Statement of Compliance and Recordkeeping | Australia Cyber Security Act 2024 | Section 9, Section 10, 5 Year Retention](/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping.md): Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/australia-cyber-security-act/penalties-and-fines --- --- title: "Ransomware Payment Reporting in 72 Hours" canonical_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours" source_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours" author: "Sorena AI" description: "Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ransomware payment reporting Australia" - "72 hour ransomware reporting obligation" - "Cyber Security Act 2024 ransomware report" - "reporting business entity ransomware Australia" - "ransomware payment report contents" - "ransomware payment reporting rules 2025" - "ransomware reporting penalties Australia" - "protected information ransomware report" - "SOCI Act ransomware reporting" - "NDB scheme ransomware" - "ransomware payment reporting playbook" - "3 million turnover threshold ransomware" - "ransomware incident response Australia" - "Australia Cyber Security Act 2024 ransomware reporting" - "72 hour reporting" - "ransomware payment reporting" - "reporting business entity" - "ransomware payment report content" - "SOCI Act interaction" - "incident response playbook" - "APAC compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Ransomware Payment Reporting in 72 Hours Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. *Artifact Guide* *APAC* ## Australia Cyber Security Act 2024 Ransomware payment reporting in 72 hours Complete operational guide to the Australia Cyber Security Act 2024 ransomware reporting obligation, covering who must report, what the report must contain, how the 72 hour reporting window works, penalties for non compliance, and how to prepare your incident response team before an event occurs. Built for incident commanders, general counsel, CISOs, board members, insurers, and external advisers who need to understand Australia ransomware payment reporting from end to end. Part 3 of the Australia Cyber Security Act 2024 creates a mandatory ransomware payment reporting obligation. Any reporting business entity that makes a ransomware payment, or becomes aware that another entity has made a ransomware payment on its behalf, must submit a ransomware payment report to the designated Commonwealth body within 72 hours. The 72 hour reporting window starts from the moment the payment is made or the moment the entity becomes aware the payment was made, whichever applies. The obligation is triggered by the fact of a ransomware payment, not by forensic certainty about the attacker or the full scope of the breach. That means organisations must build the decision path, data collection model, and owner map before the incident happens. This guide explains every element of Australia Cyber Security Act 2024 ransomware reporting so your team can comply with confidence. ## Who Must Submit a Ransomware Payment Report Under the Reporting Business Entity Test The ransomware payment reporting obligation under the Australia Cyber Security Act 2024 applies only to a reporting business entity. Under section 26(2) of the Act, an entity qualifies as a reporting business entity if, at the time the ransomware payment is made, it meets one of two tests. The first test applies to any entity that is carrying on a business in Australia with an annual turnover for the previous financial year that exceeds the turnover threshold, and that is not a Commonwealth or State body, and is not a responsible entity for a critical infrastructure asset. The second test applies to any entity that is a responsible entity for a critical infrastructure asset to which Part 2B of the Security of Critical Infrastructure Act 2018 (SOCI Act) applies. The Cyber Security (Ransomware Payment Reporting) Rules 2025 set the turnover threshold at $3 million for the previous financial year. If a business was carried on for only part of the previous financial year, the threshold is calculated on a pro rata basis using the formula: $3 million multiplied by the number of days in the part divided by the number of days in the previous financial year. This $3 million threshold was selected to align with the Privacy Act 1988 small business threshold and captures approximately 6.56 percent of registered Australian businesses. Entities that are responsible entities for critical infrastructure assets under Part 2B of the SOCI Act are captured as reporting business entities regardless of their turnover. This means that a critical infrastructure responsible entity with turnover below $3 million must still comply with Australia Cyber Security Act 2024 ransomware reporting if it makes a ransomware payment. - Confirm whether your entity meets the reporting business entity definition before an incident occurs. Do not delay this assessment until a ransomware event is underway. - Check your annual turnover for the previous financial year against the $3 million threshold set in the Ransomware Payment Reporting Rules 2025. - If your business operated for only part of the previous financial year, apply the pro rata formula to determine your adjusted threshold. - If your entity is a responsible entity for a critical infrastructure asset under Part 2B of the SOCI Act, you are a reporting business entity regardless of turnover. - Commonwealth bodies, State bodies, and Territory bodies are excluded from the turnover based test but may still be captured through the SOCI Act route. - Document your reporting business entity status assessment, including the turnover figure and the financial year it applies to, and keep it accessible to the incident response team. ## What Constitutes a Ransomware Payment Under the Cyber Security Act 2024 Section 26(1) of the Australia Cyber Security Act 2024 defines a ransomware payment broadly. The obligation is triggered when five conditions line up. First, an incident has occurred, is occurring, or is imminent. Second, the incident is a cyber security incident. Third, the incident has had, is having, or could reasonably be expected to have a direct or indirect impact on a reporting business entity. Fourth, an extorting entity makes a demand of the reporting business entity or any other entity in order to benefit from the incident or the impact on the reporting business entity. Fifth, the reporting business entity provides, or is aware that another entity has provided on its behalf, a payment or benefit to the extorting entity that is directly related to the demand. The definition covers payments or benefits. That means monetary transfers such as cryptocurrency, wire transfers, or cash are covered, but non monetary benefits are also covered. If an entity provides any benefit to an extorting entity that is directly related to the demand arising from a cyber security incident, the ransomware payment reporting obligation under the Australia Cyber Security Act 2024 is triggered. Payments made by a third party on behalf of the reporting business entity are included. If an insurer, parent company, incident response firm, or negotiation service makes the payment on behalf of the reporting business entity, and the reporting business entity becomes aware of that payment, the 72 hour reporting clock starts from the moment of awareness. - A ransomware payment includes any payment or benefit, whether monetary or non monetary, provided to the extorting entity. - Cryptocurrency payments, wire transfers, cash payments, and any other method of provision are all covered. - Payments made by a third party on behalf of the reporting business entity trigger the same obligation. - The 72 hour reporting window begins when the entity makes the payment or when the entity becomes aware a third party made the payment on its behalf. - The incident does not need to be fully understood or attributed for the ransomware payment reporting obligation to apply. - Do not wait for forensic certainty. The trigger is the fact that a payment was made, not the completion of incident investigation. ## How the 72 Hour Ransomware Payment Reporting Window Works Section 27(1) of the Australia Cyber Security Act 2024 requires the reporting business entity to give the designated Commonwealth body a ransomware payment report within 72 hours. The clock starts from the earlier of two events: the moment the reporting business entity makes the ransomware payment, or the moment the reporting business entity becomes aware that the ransomware payment has been made by another entity on its behalf. The 72 hour reporting window is strict. There is no extension mechanism in the Act. However, the Act and the Ransomware Payment Reporting Rules 2025 recognise that not all information will be available within 72 hours. Section 27(2) specifies that the report must contain information that, at the time of making the report, the reporting business entity knows or is able, by reasonable search or enquiry, to find out. This means you should report what you know and what you can reasonably discover within 72 hours, rather than delaying the report to gather complete information. The designated Commonwealth body that receives the ransomware payment report is defined in section 8 of the Act. If no rules specify otherwise, the designated Commonwealth body is the Department of Home Affairs and the Australian Signals Directorate (ASD). In practice, the report should be submitted through the channels specified by the Department. - The 72 hour reporting clock starts from the moment of payment or the moment of awareness that a third party payment was made. - There is no statutory extension to the 72 hour window. The report must be submitted within that period. - You are only required to include information that you know or can find out by reasonable search or enquiry within the 72 hours. - Do not delay the report to wait for complete forensic analysis, full attribution, or final incident scoping. - The report must be given to the designated Commonwealth body, which defaults to the Department of Home Affairs and ASD. - The report must be given in the form approved by the Secretary (if any) and in the manner prescribed by the rules. - Define in advance who in your organisation is responsible for starting the clock and who submits the report. ## Required Ransomware Payment Report Content Under the Reporting Rules 2025 Section 27(2) of the Australia Cyber Security Act 2024 and section 7 of the Cyber Security (Ransomware Payment Reporting) Rules 2025 together define the required content of a ransomware payment report. The report must cover six categories of information. Each category has specific data points mandated by the Rules. The ransomware payment report is a structured factual submission, not a legal memo or a narrative summary. The first category is the contact and business details of the reporting business entity that made the ransomware payment. Under section 7(2) of the Rules, this must include the entity's Australian Business Number (ABN), if any, and its address. The second category applies when another entity made the ransomware payment on behalf of the reporting business entity. Under section 7(3) of the Rules, the other entity's contact details, ABN (if any), and address must be included. The third category is information about the cyber security incident and its impact on the reporting business entity. Section 7(4) of the Rules requires seven specific data points: when the incident occurred or is estimated to have occurred, when the reporting business entity became aware of the incident, the impact on the entity's infrastructure, the impact on the entity's customers, the variants of ransomware or other malware used (if known), the vulnerabilities exploited in the entity's systems (if known), and any information that could assist a Commonwealth or State body in responding to or resolving the incident. The fourth category is information about the demand made by the extorting entity. Section 7(5) of the Rules requires the amount or quantum of the ransomware payment demanded (or a description if non monetary) and the method of provision demanded. The fifth category is information about the ransomware payment itself. Section 7(6) of the Rules requires the actual amount or quantum of the payment (or a description if non monetary) and the actual method of provision. The sixth category is information about communications with the extorting entity. Section 7(7) of the Rules requires the nature and timing of communications, a brief description of those communications, and a brief description of any pre payment negotiations. - Category 1: Reporting business entity contact details, ABN (if any), and address. - Category 2: If another entity made the payment, that entity's contact details, ABN (if any), and address. - Category 3: Incident timing (actual or estimated), time of awareness, impact on infrastructure, impact on customers, ransomware or malware variants (if known), exploited vulnerabilities (if known), and any information useful for government response. - Category 4: Demand amount or description, and demanded method of provision. - Category 5: Actual payment amount or description, and actual method of provision. - Category 6: Nature and timing of communications with the extorting entity, a brief description of those communications, and a brief description of pre payment negotiations. - Information is required only to the extent that the entity knows it or can find it by reasonable search or enquiry within 72 hours. - The entity may also include other information about the cyber security incident in addition to the required fields. ## Penalties for Failing to Submit a Ransomware Payment Report Within 72 Hours Section 27(5) of the Australia Cyber Security Act 2024 creates a civil penalty for failure to submit a ransomware payment report within the 72 hour reporting window. The penalty is 60 penalty units. For a body corporate, the maximum civil penalty is five times that amount, which equates to 300 penalty units. The value of a Commonwealth penalty unit is set under the Crimes Act 1914 and is adjusted periodically. The civil penalty applies to any reporting business entity that contravenes the obligation under section 27(1). This includes failure to submit the report at all, failure to submit it within 72 hours, and failure to include the required information in the report. The Regulatory Powers (Standard Provisions) Act 2014 applies for enforcement, though section 27(6) disapplies subsection 93(2) of that Act for this particular provision. Non compliance with Australia Cyber Security Act 2024 ransomware reporting also carries reputational risk. If the Cyber Incident Review Board conducts a review of the incident under Part 5 of the Act, a failure to report may become part of the record. The government has stated an education first approach to compliance, but the civil penalty framework is in place from commencement. - Civil penalty for non compliance: 60 penalty units per contravention for individuals, up to 300 penalty units for bodies corporate. - The penalty applies to late reporting, non reporting, and materially incomplete reporting. - The Regulatory Powers (Standard Provisions) Act 2014 provides the enforcement mechanism. - The government has indicated an education first compliance posture, but the civil penalty is legally enforceable from the date the obligation commences. - Reputational consequences may also arise if the Cyber Incident Review Board reviews the incident. - Build compliance evidence to demonstrate good faith effort, even if some report fields are incomplete at the 72 hour mark. ## Protected Information, Privilege, and Admissibility Safeguards for Ransomware Payment Reports The Australia Cyber Security Act 2024 includes strong protections designed to encourage ransomware payment reporting rather than penalise it. Section 28 provides that an entity is not liable to an action or proceeding for damages for any act done or omitted in good faith in compliance with the reporting obligation. This good faith shield extends to officers, employees, and agents of the reporting business entity. Section 29 restricts how the designated Commonwealth body may use or disclose information from a ransomware payment report. The information may only be used for permitted purposes, such as assisting the entity to respond to the incident, performing regulatory functions under Part 3, supporting law enforcement for false information offences, performing functions of the National Cyber Security Coordinator, informing Ministers, and supporting intelligence agency functions. The designated Commonwealth body must not use ransomware payment report information to investigate or enforce any civil or regulatory contravention by the reporting business entity, except for contraventions of Part 3 itself or criminal offences. Section 31 preserves legal professional privilege. The fact that a reporting business entity included information in a ransomware payment report does not waive privilege over that information in other proceedings. Section 32 provides that information from a ransomware payment report is not admissible in evidence against the reporting business entity in criminal proceedings (other than false information offences), civil penalty proceedings (other than under Part 3), or proceedings before a tribunal. These protections mean that the ransomware payment reporting obligation under the Australia Cyber Security Act 2024 is designed as a safe harbour intelligence sharing mechanism, not a self incrimination tool. - Good faith immunity under section 28 protects the entity and its personnel from damages claims arising from compliance with the reporting duty. - Ransomware payment report information can only be used by the designated Commonwealth body for permitted purposes listed in section 29. - The designated Commonwealth body cannot use report information to pursue civil or regulatory enforcement against the reporting entity, except for Part 3 contraventions or criminal offences. - Legal professional privilege is preserved. Providing privileged information in a ransomware payment report does not waive privilege in other proceedings. - Report information is not admissible in evidence against the reporting business entity in criminal, civil penalty, or tribunal proceedings (with narrow exceptions for false information offences and Part 3 contraventions). - These protections apply to information obtained from ransomware payment reports and to secondary recipients under section 30. - The protection framework is intended to remove fear of self incrimination as a barrier to ransomware payment reporting under the Australia Cyber Security Act 2024. ## Parallel Reporting Obligations During a Ransomware Incident in Australia Section 44 of the Australia Cyber Security Act 2024 makes clear that information provided under one reporting regime does not discharge obligations under another. A ransomware incident in Australia can trigger up to three separate mandatory reporting obligations that run concurrently, each with its own trigger, timeline, recipient, and content requirements. Under Part 2B of the SOCI Act, responsible entities for critical infrastructure assets must report significant cyber security incidents within 12 hours of becoming aware that the incident is having a significant impact (section 30BC), and other cyber security incidents within 72 hours (section 30BD). These SOCI Act timelines are triggered by the impact of the incident on the critical infrastructure asset, regardless of whether a ransomware payment is made. The ransomware payment reporting obligation under Part 3 of the Cyber Security Act 2024 is triggered separately by the act of making or becoming aware of the ransomware payment. Under Part IIIC of the Privacy Act 1988, the Notifiable Data Breaches (NDB) scheme requires entities that experience unauthorised access to, disclosure of, or loss of personal information likely to result in serious harm to assess the breach within 30 days (section 26WH) and then notify the Office of the Australian Information Commissioner and affected individuals as soon as practicable. A ransomware incident involving exfiltration or encryption of personal data will typically trigger this NDB obligation in addition to the ransomware payment reporting requirement. For a critical infrastructure entity hit by a ransomware attack that involves personal data and a ransom payment, all three reporting obligations may run simultaneously. The SOCI incident notification is due first (12 hours for critical incidents), followed by the ransomware payment report under the Cyber Security Act 2024 (72 hours from payment), and then the NDB notification (30 day assessment period followed by notification as soon as practicable). Your incident response playbook must coordinate all three paths with separate timelines, owners, content requirements, and submission channels. - SOCI Act Part 2B requires 12 hour notification for critical cyber security incidents and 72 hour notification for other incidents affecting critical infrastructure assets - Cyber Security Act 2024 Part 3 requires a 72 hour ransomware payment report from the date of payment or the date the entity becomes aware a third party made the payment - Privacy Act 1988 Part IIIC (NDB scheme) requires a 30 day assessment period followed by notification as soon as practicable where personal data breach is likely to cause serious harm - Section 44 of the Cyber Security Act 2024 confirms that reporting under one regime does not satisfy obligations under another regime - Section 29(4)(a)(i) carves out information already provided under SOCI Act Part 2B from the ransomware payment report use restrictions, so the two pathways operate independently - Build your incident response playbook to address all three reporting pathways in a coordinated sequence with separate timelines, owners, content requirements, and submission channels ## Building Your Ransomware Payment Reporting Playbook Before an Incident The most common reason organisations fail to meet the 72 hour reporting window for ransomware payment reporting under the Australia Cyber Security Act 2024 is that they did not prepare the data collection model, decision authority, and submission path in advance. The report fields, the escalation chain, and the evidence preservation approach must be designed and tested before a ransomware event occurs. Start by building a pre approved ransomware payment report collection sheet that mirrors the six categories required by section 27(2) of the Act and section 7 of the Ransomware Payment Reporting Rules 2025. Assign each data point to the team or individual most likely to hold that information during an active incident. Contact and business details should come from legal or corporate affairs. Incident timing and impact should come from the incident response team. Malware variant and vulnerability information should come from the technical forensics lead. Demand and payment details should come from the party authorising or executing the payment. Communication logs should come from whoever manages the negotiation channel, whether that is an internal team, external counsel, or a specialist negotiation firm. Define the decision authority for two key moments. The first is the decision to make or authorise a ransomware payment. The second is the moment that awareness of a payment by a third party reaches the entity. Both of these moments start the 72 hour reporting clock. If the decision authority is unclear, or if there is a gap between payment authorisation and payment execution, your organisation risks starting the clock late and breaching the 72 hour window. Prepare the submission channel in advance. Identify the approved form (if the Secretary has published one) and the prescribed manner for submission. Keep contact details for the designated Commonwealth body (the Department of Home Affairs and ASD) in the incident response documentation, not in someone's personal contact list. - Build a pre approved collection sheet that maps every required report field to a data owner. - Assign entity contact details and ABN to legal or corporate affairs. - Assign incident timing, infrastructure impact, customer impact, malware variants, and vulnerability information to the incident response and forensics team. - Assign demand details and payment details to the party responsible for authorising or executing the payment. - Assign communication and negotiation logs to whoever manages the extortion channel, whether internal, external counsel, or a specialist negotiation firm. - Define who holds the authority to decide that a ransomware payment has been made and who is responsible for starting the 72 hour reporting clock. - Identify the submission form and channel for the designated Commonwealth body in advance. - Keep all submission instructions in the incident response runbook, not in a single person's knowledge. ## Evidence Preservation During the 72 Hour Ransomware Payment Reporting Window Evidence preservation is critical during a ransomware payment reporting event under the Australia Cyber Security Act 2024. The ransomware payment report must contain information about the incident, the demand, the payment, and communications with the extorting entity. If this evidence is lost, overwritten, or fragmented during the crisis response, the entity may be unable to comply with the reporting obligation or unable to defend the accuracy of its report. Create a controlled evidence folder structure before an incident occurs. The folder should have separate sections for incident timeline logs, infrastructure and customer impact records, malware samples and forensic artifacts, demand communications (screenshots, email headers, decryptor portal links, chat logs), payment authorisation records, payment execution records (wallet addresses, transaction hashes, wire confirmations), negotiation records, and internal decision records showing who authorised the payment and when. All evidence should be timestamped and stored in a manner that supports legal hold requirements. If the entity uses an external negotiation service, the contract with that service should include clauses requiring the negotiator to preserve and hand over communication logs and payment records within the 72 hour window. - Create a pre built evidence folder structure for ransomware payment reporting events with separate sections for each category of required report content. - Preserve incident timeline logs, including when the incident was detected, when the entity became aware, and when each escalation step occurred. - Capture and store all demand communications: screenshots of ransom notes, email headers, decryptor portal links, chat logs, and dark web page captures. - Record all payment details: wallet addresses, transaction hashes, wire transfer confirmations, and authorisation records. - Preserve negotiation records, including any pre payment negotiations, and note the nature and timing of each exchange. - Timestamp all evidence and apply legal hold to prevent accidental deletion. - If using an external negotiation firm or insurer, ensure contracts require evidence handover within the 72 hour reporting window. - After the report is submitted, continue preserving evidence in case the Cyber Incident Review Board conducts a post incident review under Part 5 of the Act. ## Common Mistakes That Cause Ransomware Payment Reporting Failures Most failures in Australia Cyber Security Act 2024 ransomware reporting happen because of organisational confusion rather than technical difficulty. The report content is factual and structured. The 72 hour reporting window is generous compared to many real time obligations. The failures come from delayed awareness, unclear decision authority, evidence loss, and internal disputes about scope. The most frequent mistake is starting the 72 hour reporting clock too late because internal teams disagree about whether a payment counts as a ransomware payment under the Act. The definition is broad: any payment or benefit to an extorting entity that is directly related to a demand arising from a cyber security incident. If there is doubt, start the clock and prepare the report while the legal analysis continues. The second most frequent mistake is failing to account for third party payments. If an insurer, parent company, or external negotiation firm makes the ransomware payment on behalf of the reporting business entity, the entity must still report. The 72 hour window starts from the moment the entity becomes aware the payment was made. Contracts with third parties must include notification obligations that allow the entity to start the reporting process immediately. - Starting the 72 hour clock too late because of internal debate about whether the payment qualifies as a ransomware payment. - Failing to capture or account for a ransomware payment made by a third party on behalf of the entity. - Delaying the report to wait for complete forensic analysis or full incident attribution when the Act only requires what can be found by reasonable search or enquiry within 72 hours. - Treating the ransomware payment report as a legal memo or narrative instead of a structured factual submission with specific required fields. - Losing evidence because communication logs, wallet details, negotiation records, or payment authorisations were not preserved in a controlled folder. - Failing to involve finance, external negotiators, or insurers early enough, leaving gaps in payment and demand information. - Not having a pre built report template that mirrors the six categories required by the Act and Rules. - Assigning the reporting task to a single individual without backup, creating a single point of failure during a high pressure incident. ## Tabletop Exercise Design for Ransomware Payment Reporting Readiness The best way to test your ability to meet the 72 hour reporting obligation under the Australia Cyber Security Act 2024 is to run a tabletop exercise that includes the payment decision, the clock start, the data collection, and the report submission. Many organisations run cyber incident tabletop exercises that stop at containment and recovery. To test ransomware payment reporting readiness, the exercise must continue through the payment decision, the evidence capture, and the report handoff. Design the exercise scenario so that the payment decision is contested. Include a scenario where an external negotiation firm makes the payment before the board has formally approved it, which forces the team to address the awareness trigger and the third party payment path. Include a scenario where the incident response team cannot determine the malware variant within 72 hours, which forces the team to submit the report with incomplete technical information and understand that this is acceptable under the reasonable search or enquiry standard. After the exercise, assess three things. First, how long it took from the payment decision to the submission of a complete report template. Second, whether all six categories of report content were populated with available information. Third, whether the evidence folder was maintained in a condition that would support a post incident review by the Cyber Incident Review Board. - Run a tabletop exercise at least once per year that extends through the ransomware payment decision and the 72 hour reporting process. - Include a scenario where a third party makes the payment without the entity's prior knowledge, triggering the awareness based clock start. - Include a scenario where technical details like malware variant or exploited vulnerability are unknown within 72 hours. - Measure time from payment decision to completed report template to identify bottlenecks. - Verify that all six categories of required report content can be populated from available sources during the exercise. - Test the evidence folder process to confirm that communication logs, payment records, and negotiation records are preserved and retrievable. - Include legal counsel, insurers, and external negotiation firms in the exercise where those parties are part of the real world response chain. - Document exercise findings and update the incident response playbook to close any gaps identified. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use Australia Cyber Security Act 2024 Ransomware payment reporting in 72 hours as a cited research workflow Research Copilot can take Australia Cyber Security Act 2024 Ransomware payment reporting in 72 hours from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on Australia Cyber Security Act 2024 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Australia Cyber Security Act 2024 Ransomware payment reporting in 72 hours](/solutions/research-copilot.md): Start from Australia Cyber Security Act 2024 Ransomware payment reporting in 72 hours and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Australia Cyber Security Act 2024](/contact.md): Review your current process, evidence gaps, and next steps for Australia Cyber Security Act 2024 Ransomware payment reporting in 72 hours. ## Primary sources - [Cyber Security Act 2024 (Australia) official text](https://www.legislation.gov.au/C2024A00098/latest/text?ref=sorena.io) - Part 3 (sections 25 to 32) establishes the ransomware payment reporting obligation, the 72 hour deadline, report content requirements under section 27, liability protection for good faith compliance under section 28, protected information restrictions under sections 29 to 30, admissibility safeguards under section 32, and preservation of legal professional privilege under section 31. - [Cyber Security (Ransomware Payment Reporting) Rules 2025 official text](https://www.legislation.gov.au/F2025L00278/asmade/text?ref=sorena.io) - Sets the $3 million turnover threshold (section 6), the pro rata formula for partial year businesses, and the detailed report content requirements across all six categories (section 7). - [Cyber Security (Ransomware Payment Reporting) Rules 2025 explanatory statement](https://www.legislation.gov.au/F2025L00278/explanatory-statement/text?ref=sorena.io) - Explains the policy intent behind the $3 million threshold, the compliance cost estimate of $276.80 per entity, the education first enforcement posture, and the government's objectives for ransomware intelligence gathering. - [Security of Critical Infrastructure Act 2018 details](https://www.legislation.gov.au/Details/C2018A00029?ref=sorena.io) - Part 2B contains the separate cyber incident notification requirements for critical infrastructure entities that run in parallel with the Australia Cyber Security Act 2024 ransomware payment reporting obligation. ## Related Topic Guides - [Australia Cyber Security Act 2024 Applicability Test | Who Must Comply](/artifacts/apac/australia-cyber-security-act/applicability-test.md): Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations. - [Australia Cyber Security Act 2024 Compliance Checklist](/artifacts/apac/australia-cyber-security-act/checklist.md): Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting. - [Australia Cyber Security Act 2024 Compliance Guide | Implementation Playbook](/artifacts/apac/australia-cyber-security-act/compliance.md): A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements. - [Australia Cyber Security Act 2024 Compliance Templates | Statement of Compliance, Ransomware Report, Evidence Pack, Vulnerability Disclosure, Support Period](/artifacts/apac/australia-cyber-security-act/templates.md): Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field. - [Australia Cyber Security Act 2024 Deadlines and Compliance Calendar | Commencement Dates](/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar.md): Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent. - [Australia Cyber Security Act 2024 FAQ | Frequently Asked Questions](/artifacts/apac/australia-cyber-security-act/faq.md): Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024. - [Australia Cyber Security Act 2024 Requirements | Smart Device and Ransomware Reporting Obligations](/artifacts/apac/australia-cyber-security-act/requirements.md): Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure. - [Australia Cyber Security Act 2024 Timeline and Commencement Dates | Full Schedule](/artifacts/apac/australia-cyber-security-act/timeline-and-commencement.md): Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024. - [Australia Cyber Security Act 2024 vs EU Cyber Resilience Act | Full CRA Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act.md): Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements. - [Australia Cyber Security Act 2024 vs UK PSTI Act | Product Security Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act.md): Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements. - [Australia Smart Device Compliance Checklist | Cyber Security Act 2024 | Sorena](/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist.md): Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure. - [Penalties and fines | Australia Cyber Security Act 2024 | 60 Penalty Units, Smart Device Enforcement, Ransomware Reporting](/artifacts/apac/australia-cyber-security-act/penalties-and-fines.md): Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals. - [Scope and Definitions | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/scope-and-definitions.md): Complete guide to the Australia Cyber Security Act 2024 scope and definitions. - [Smart device security standards | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/smart-device-security-standards.md): Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2. - [Statement of Compliance and Recordkeeping | Australia Cyber Security Act 2024 | Section 9, Section 10, 5 Year Retention](/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping.md): Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours --- --- title: "Australia Cyber Security Act 2024 Requirements" canonical_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/requirements" source_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/requirements" author: "Sorena AI" description: "Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "Australia Cyber Security Act 2024 requirements" - "Cyber Security Act 2024 obligations" - "smart device security requirements Australia" - "smart device password requirements" - "vulnerability disclosure requirements Australia" - "security update support period" - "statement of compliance requirements" - "ransomware payment reporting requirements Australia" - "72 hour ransomware reporting" - "reporting business entity" - "3 million turnover threshold" - "compliance notice requirements" - "stop notice recall notice" - "APAC cyber security compliance" - "connectable product requirements" - "ransomware payment reporting requirements" - "vulnerability disclosure requirements" - "security update support period requirements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Australia Cyber Security Act 2024 Requirements Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure. *Artifact Guide* *APAC* ## Australia Cyber Security Act 2024 Requirements Every requirement under the Australia Cyber Security Act 2024, from smart device password controls and vulnerability disclosure to the 72 hour ransomware payment report and enforcement notice powers. This guide breaks the legal requirements into practical actions your product, security, and compliance teams can assign, implement, and verify. The Australia Cyber Security Act 2024 creates three distinct sets of requirements. Part 2 requires manufacturers and suppliers of smart devices to meet mandatory security standards for passwords, vulnerability reporting, and support periods. Part 2 also requires a statement of compliance to accompany every product supplied in Australia. Part 3 requires reporting business entities to file a ransomware payment report within 72 hours when the statutory conditions are met. The enforcement architecture gives the Secretary powers to issue compliance notices, stop notices, and recall notices for smart device obligations, while civil penalties apply to failures in both the smart device and ransomware reporting requirements. ## Australia Cyber Security Act 2024 Requirements Overview The Australia Cyber Security Act 2024 does not impose a single blanket obligation. It establishes a chain of linked requirements across two core regulatory areas. Part 2 governs security standards for smart devices, requiring manufacturers to build compliant products and suppliers to ensure those products reach consumers accompanied by a valid statement of compliance. Part 3 governs ransomware payment reporting, requiring qualifying business entities to report payments made in response to cyber extortion within 72 hours. Each set of requirements has its own commencement date. Part 2 smart device security standard requirements commenced on 29 November 2025 for the Act provisions, with the detailed rules under the Cyber Security (Security Standards for Smart Devices) Rules 2025 applying from 4 March 2026. Part 3 ransomware payment reporting requirements commenced on 29 May 2025. Businesses operating in Australia must identify which requirements apply to their operations and prepare compliance controls accordingly. The Australia Cyber Security Act 2024 requirements apply to entities with a connection to Australia. For smart devices, the requirements apply where the manufacturer knows or could reasonably be expected to know that the products will be acquired in Australia. For ransomware reporting, the requirements apply to entities carrying on a business in Australia above the turnover threshold or to responsible entities for critical infrastructure assets. - Manufacturers must manufacture relevant connectable products in compliance with prescribed security standards when they know products will be acquired in Australia. - Suppliers must not supply non compliant products and must ensure each product is accompanied by a statement of compliance. - Reporting business entities must file a ransomware payment report within 72 hours of making the payment or becoming aware the payment was made. - The Secretary holds enforcement powers including compliance notices, stop notices, recall notices, and the ability to commission independent product examinations. - Civil penalties of 60 penalty units apply to failures in ransomware payment reporting obligations. - Good faith reporting of ransomware payments provides liability protection for the reporting entity and its officers, employees, and agents. *Recommended next step* *Placement: after the requirement breakdown* ## Turn Australia Cyber Security Act 2024 Requirements into an operational assessment Assessment Autopilot can take Australia Cyber Security Act 2024 Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on Australia Cyber Security Act 2024 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Australia Cyber Security Act 2024 Requirements](/solutions/assessment.md): Start from Australia Cyber Security Act 2024 Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Australia Cyber Security Act 2024](/contact.md): Review your current process, evidence gaps, and next steps for Australia Cyber Security Act 2024 Requirements. ## Smart Device Password Requirements Under the Cyber Security Act 2024 The Cyber Security (Security Standards for Smart Devices) Rules 2025 prescribe mandatory password requirements for consumer grade relevant connectable products. These password requirements apply to hardware when not in factory default state, to software pre installed at point of supply when not in factory default state, and to software that must be installed for all manufacturer intended purposes. Manufacturers must ensure every product meets these password requirements before the product is supplied in Australia. The password requirements under the Australia Cyber Security Act 2024 are designed to eliminate the use of default or easily guessable passwords that create security vulnerabilities in consumer smart devices. The requirements align with internationally recognised standards including ETSI EN 303 645 Provision 5.1, ensuring that Australian smart device password requirements are consistent with global security expectations. Products covered by these password requirements include all consumer grade relevant connectable products that are internet connectable or network connectable. Products excluded from the requirements include desktop computers, laptops, tablet computers, smartphones, therapeutic goods, road vehicles, and road vehicle components. The password requirements apply to products intended for personal, domestic, or household use. - Passwords must be unique per product or defined by the user of the product. - Unique per product passwords must not be based on incremental counters such as password1, password2. - Unique per product passwords must not be based on or derived from publicly available information. - Unique per product passwords must not be based on or derived from unique product identifiers like serial numbers unless processed using an encryption method or keyed hashing algorithm accepted as good industry practice. - Passwords must not be otherwise guessable in a manner unacceptable as part of good industry practice. - The password definition under the rules excludes cryptographic keys, PINs used for non internet protocol pairing, and application programming interface keys. ## Vulnerability Reporting Requirements for Smart Device Manufacturers The Australia Cyber Security Act 2024 requirements include a mandatory vulnerability reporting obligation for smart device manufacturers. Under the Cyber Security (Security Standards for Smart Devices) Rules 2025, manufacturers must publish information on how security researchers and the public can report security issues affecting the product. This vulnerability disclosure requirement covers hardware, pre installed software, software that must be installed for manufacturer intended purposes, and software used for or in connection with any manufacturer intended purposes. The published vulnerability reporting information must include at least one point of contact for reporting security issues to the manufacturer. It must also include when a person making a report will receive an acknowledgement of receipt and when they will receive status updates until the reported security issues are resolved. This requirement ensures manufacturers maintain an open and responsive channel for security issue reports. These vulnerability reporting requirements under the Australia Cyber Security Act 2024 align with ETSI EN 303 645 Provision 5.2, establishing a consistent framework for coordinated vulnerability disclosure across smart devices sold to Australian consumers. - Manufacturers must publish at least one point of contact for reporting security issues. - The published information must state when a reporter will receive an acknowledgement of receipt of their report. - The published information must state when a reporter will receive status updates until resolution of the reported security issues. - All vulnerability reporting information must be accessible, clear, and transparent. - The information must be available without prior request, published in English, and provided free of charge. - Manufacturers must not require personal information from the person reporting a security issue as a condition for submitting the report. ## Support Period and Security Update Requirements for Smart Devices The Australia Cyber Security Act 2024 requirements mandate that smart device manufacturers publish a defined support period for security updates. The defined support period must be expressed as a period of time with an end date, specifying how long the manufacturer will provide security updates for the product. A security update is defined as a software update that protects or enhances the security of the product, including updates addressing discovered or reported security issues. The support period and security update requirements apply to hardware capable of receiving security updates, pre installed software capable of receiving security updates, software that must be installed for manufacturer intended purposes and is capable of receiving security updates, and software developed by or on behalf of the manufacturer that is capable of receiving security updates and used for manufacturer intended purposes. These support period requirements under the Australia Cyber Security Act 2024 align with ETSI EN 303 645 Provision 5.3, ensuring that consumers can make informed purchasing decisions based on how long a smart device will receive security updates. Manufacturers must present this information prominently alongside consumer decision making information on their website. - Manufacturers must publish the defined support period expressed as a period of time with an end date for security updates. - Manufacturers must not shorten the defined support period after it has been published. - If a manufacturer extends the defined support period, the new period must be published as soon as practicable. - Support period information must be accessible, clear, transparent, available without prior request, in English, free of charge, and understandable without prior technical knowledge. - If the manufacturer offers the product on its website, support period information must be prominently published alongside consumer decision making information. - Support period information must be given equal prominence to the main product characteristics displayed on the manufacturer website. ## Statement of Compliance Requirements Under the Australia Cyber Security Act 2024 The Australia Cyber Security Act 2024 requirements include a mandatory statement of compliance that must accompany every relevant connectable product supplied in Australia. The statement must be prepared by or on behalf of the manufacturer. Manufacturers must provide the statement of compliance for the supply of the product, and suppliers must supply the product with the statement when they know or could reasonably be expected to know the product will be acquired in Australia. The statement of compliance requirements serve as the formal attestation mechanism under the Australia Cyber Security Act 2024. Each statement creates an auditable record that the manufacturer has assessed the product against the prescribed security standard and confirmed compliance. The Secretary may request the statement during an independent examination under Section 23 of the Act, making completeness and accuracy essential. Both manufacturers and suppliers must retain a copy of the statement of compliance for five years as prescribed by the Cyber Security (Security Standards for Smart Devices) Rules 2025. This retention requirement ensures that compliance evidence remains available for enforcement and audit purposes throughout the expected lifecycle of smart devices on the Australian market. - The statement must include the product type and batch identifier. - The statement must include the name and address of the manufacturer, an authorised representative, and each authorised representative in Australia. - The statement must include a declaration that the statement has been prepared by or on behalf of the manufacturer. - The statement must include a declaration that in the opinion of the manufacturer the product complies with the security standard requirements and the manufacturer has met all other obligations in the security standard. - The statement must include the defined support period for the product at the date the statement is issued. - The statement must include the signature, name, and function of the signatory, plus the place and date of issue, and must be retained for five years. ## Ransomware Payment Reporting Requirements Under the Australia Cyber Security Act 2024 Part 3 of the Australia Cyber Security Act 2024 creates a mandatory ransomware payment reporting requirement. When a reporting business entity is impacted by a cyber security incident and a ransomware payment is made to the extorting entity, the reporting business entity must give the designated Commonwealth body a ransomware payment report within 72 hours. The 72 hour window starts from the time the payment is made or the time the entity becomes aware the payment has been made, whichever applies. The ransomware payment reporting requirements under the Australia Cyber Security Act 2024 apply only when all five statutory conditions are met simultaneously. There must be a cyber security incident, the incident must impact a reporting business entity, an extorting entity must make a demand seeking to benefit from the incident, and the reporting business entity must make or become aware of a ransomware payment to that extorting entity. If any of these conditions is not present, the reporting obligation does not arise. Failure to comply with the ransomware payment reporting requirements carries a civil penalty of 60 penalty units. The ransomware payment report must be given in the approved form issued by the Secretary and in the manner prescribed by the rules. - The ransomware payment report must be filed within 72 hours of making the payment or becoming aware the payment was made. - The report must be given to the designated Commonwealth body in the approved form if one has been issued by the Secretary. - A civil penalty of 60 penalty units applies to any entity that fails to file the required ransomware payment report. - The reporting obligation applies regardless of whether the payment was made directly by the reporting business entity or by another entity on its behalf. - Information in the report is only required to the extent the entity knows or can find out by reasonable search or enquiry within the 72 hour reporting window. - The ransomware payment reporting requirements commenced on 29 May 2025 for all qualifying entities. ## Information Required in a Ransomware Payment Report The Cyber Security (Ransomware Payment Reporting) Rules 2025 prescribe six categories of information that a ransomware payment report must contain. The reporting business entity must provide this information to the extent that it knows the details or can discover them through reasonable search or enquiry within the 72 hour reporting window. This practical limitation means that the report must be as complete as possible given the circumstances, but incomplete information does not create a separate contravention if the entity acted reasonably. The ransomware payment report requirements under the Australia Cyber Security Act 2024 are designed to give the designated Commonwealth body enough information to assist the affected entity, understand the threat landscape, and coordinate a response. The report contents cover the identity and contact details of the affected entity, the nature and timing of the incident, the details of the extortion demand, the details of the payment itself, and the communications between the entity and the extorting party. Ransomware payment reports may only be used or disclosed for permitted purposes as defined in Section 29 of the Act. These purposes include assisting the reporting entity to respond to the incident, performing regulatory functions, national security purposes, and informing the Minister. The information must not be used for investigating or enforcing any civil or regulatory contravention other than a contravention of Part 3 itself or a criminal offence. - The report must contain the reporting entity contact and business details including ABN and address. - If another entity made the payment on behalf of the reporting entity, the report must include that entity contact details and ABN. - The report must describe when the cyber security incident occurred, its impact on infrastructure, and its impact on customers. - The report must identify ransomware or malware variants used and vulnerabilities exploited in the entity systems. - The report must state the amount or description of the ransomware demand, the payment actually made, and the payment method. - The report must describe the nature, timing, and content of communications with the extorting entity, including any pre payment negotiations. ## Reporting Business Entity Requirements and the 3 Million Dollar Threshold The ransomware payment reporting requirements under the Australia Cyber Security Act 2024 apply only to reporting business entities. An entity qualifies as a reporting business entity through one of two routes. The first route applies to entities carrying on a business in Australia with an annual turnover for the previous financial year exceeding 3 million dollars, provided the entity is not a Commonwealth body, a State body, or a responsible entity for a critical infrastructure asset. The second route applies to responsible entities for critical infrastructure assets to which Part 2B of the Security of Critical Infrastructure Act 2018 applies. The 3 million dollar turnover threshold is set by Section 6 of the Cyber Security (Ransomware Payment Reporting) Rules 2025. For businesses that operated for only part of the previous financial year, the threshold is prorated using the formula: 3 million dollars multiplied by the number of days the business operated, divided by the total number of days in the financial year. This prorating mechanism ensures that newer businesses are not excluded from the reporting requirements based solely on a short operating history. Determining whether your entity is a reporting business entity is the first step in assessing your ransomware payment reporting requirements under the Australia Cyber Security Act 2024. The turnover assessment should be completed before an incident occurs so that the entity can respond within the 72 hour window without needing to resolve threshold questions under time pressure. - Entities with annual turnover exceeding 3 million dollars in the previous financial year must report ransomware payments if they are not a Commonwealth body, State body, or critical infrastructure responsible entity. - Responsible entities for critical infrastructure assets subject to Part 2B of the Security of Critical Infrastructure Act 2018 must report ransomware payments regardless of turnover. - The 3 million dollar threshold is prorated for businesses that operated for only part of the previous financial year. - The turnover assessment is based on the previous financial year and should be reviewed annually to confirm reporting obligations. - Commonwealth bodies and State bodies are excluded from the reporting business entity definition under the first limb but may be captured under the critical infrastructure limb. - Pre incident planning should include a documented determination of whether the entity meets the reporting business entity threshold. ## Enforcement Powers and Compliance Notice Requirements The Australia Cyber Security Act 2024 gives the Secretary escalating enforcement powers for smart device requirements. The enforcement pathway follows a three stage escalation: compliance notice, then stop notice, then recall notice. Each stage requires the previous stage to have been issued and found insufficient before the next stage can be activated. Before issuing any notice, the Secretary must notify the entity and give at least 10 days for the entity to make representations. A compliance notice under Section 17 may be issued when the Secretary is reasonably satisfied that an entity is not complying with its smart device obligations, or is aware of information suggesting possible non compliance. The compliance notice must specify the action the entity must take and a reasonable period for taking that action. Only one compliance notice may be issued for a particular instance of non compliance. If a compliance notice proves inadequate, the Secretary may issue a stop notice under Section 18. If the stop notice also proves inadequate, the Secretary may issue a recall notice under Section 19 requiring the entity to prevent the product from being acquired or supplied in Australia and to arrange for returns. If the entity fails to comply with the recall notice, the Minister may publicly notify the entity identity, product details, non compliance details, and risks posed by the product. The Secretary may also commission an independent examination under Section 23, where a qualified expert can open, operate, test, and analyse products to verify compliance with the security standards. - The Secretary must give at least 10 days notice and allow representations before issuing any compliance, stop, or recall notice. - Only one compliance notice may be issued for a particular instance of non compliance with smart device requirements. - Stop notices can only be issued after a compliance notice has been given and found insufficient to address the non compliance. - Recall notices can only be issued after a stop notice has been given and found insufficient to address the non compliance. - The Minister may publicly identify entities that fail to comply with recall notices, including product details and risks posed. - Entities may seek internal review of a decision to issue or vary a compliance, stop, or recall notice within 30 days of receiving the notice. ## Liability Protection and Reporting Safeguards Under the Cyber Security Act 2024 The Australia Cyber Security Act 2024 provides important liability protections for entities that report ransomware payments in good faith. Section 28 provides that an entity is not liable to an action or other proceeding for damages for acts done or omitted in good faith in compliance with the reporting obligation. This protection extends to officers, employees, and agents of the reporting entity. The entity bears an evidential burden when seeking to rely on this safe harbour provision. Information provided in a ransomware payment report receives strong admissibility protections under Section 32 of the Act. The information is not admissible against the reporting business entity in criminal proceedings, civil penalty proceedings, proceedings for breach of other laws, or tribunal proceedings. Narrow exceptions exist for false or misleading information offences and obstruction of Commonwealth officials. These protections are designed to encourage honest and complete reporting without fear of self incrimination. Legal professional privilege is also preserved under the Australia Cyber Security Act 2024 requirements. Section 31 provides that the fact of reporting does not affect any claim of legal professional privilege that anyone may make in relation to the reported information. The combination of liability protection, admissibility safeguards, and privilege preservation creates a framework that incentivises timely and complete ransomware payment reporting. - Good faith reporting under Section 27 provides liability protection for the reporting entity against damages proceedings. - The liability protection extends to officers, employees, and agents of the reporting business entity. - Ransomware payment report information is generally not admissible against the reporting entity in criminal, civil, or tribunal proceedings. - Exceptions to admissibility protection are limited to false or misleading information offences and obstruction of Commonwealth officials. - Legal professional privilege is not waived by the act of filing a ransomware payment report. - Secondary use and disclosure of report information is restricted to permitted purposes, and unauthorised disclosure carries a civil penalty of 60 penalty units. ## Primary sources - [Cyber Security Act 2024 (No. 98, 2024) official text](https://www.legislation.gov.au/C2024A00098/latest/text?ref=sorena.io) - Primary legislation containing smart device requirements in Part 2, ransomware payment reporting requirements in Part 3, and the enforcement architecture in Parts 6 and 8. - Quote: "An Act relating to cyber security for Australians, and for other purposes." - [Cyber Security (Security Standards for Smart Devices) Rules 2025 official text](https://www.legislation.gov.au/F2025L00276/asmade/text?ref=sorena.io) - Subordinate legislation prescribing the mandatory security standard for consumer grade relevant connectable products, including password requirements, vulnerability disclosure requirements, and defined support period requirements. - [Cyber Security (Ransomware Payment Reporting) Rules 2025 official text](https://www.legislation.gov.au/F2025L00278/asmade/text?ref=sorena.io) - Subordinate legislation setting the 3 million dollar turnover threshold and prescribing the six categories of information required in a ransomware payment report. - [Security of Critical Infrastructure Act 2018 details](https://www.legislation.gov.au/Details/C2018A00029?ref=sorena.io) - Supports the reporting business entity analysis for entities that are responsible entities for critical infrastructure assets subject to Part 2B. ## Related Topic Guides - [Australia Cyber Security Act 2024 Applicability Test | Who Must Comply](/artifacts/apac/australia-cyber-security-act/applicability-test.md): Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations. - [Australia Cyber Security Act 2024 Compliance Checklist](/artifacts/apac/australia-cyber-security-act/checklist.md): Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting. - [Australia Cyber Security Act 2024 Compliance Guide | Implementation Playbook](/artifacts/apac/australia-cyber-security-act/compliance.md): A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements. - [Australia Cyber Security Act 2024 Compliance Templates | Statement of Compliance, Ransomware Report, Evidence Pack, Vulnerability Disclosure, Support Period](/artifacts/apac/australia-cyber-security-act/templates.md): Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field. - [Australia Cyber Security Act 2024 Deadlines and Compliance Calendar | Commencement Dates](/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar.md): Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent. - [Australia Cyber Security Act 2024 FAQ | Frequently Asked Questions](/artifacts/apac/australia-cyber-security-act/faq.md): Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024. - [Australia Cyber Security Act 2024 Timeline and Commencement Dates | Full Schedule](/artifacts/apac/australia-cyber-security-act/timeline-and-commencement.md): Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024. - [Australia Cyber Security Act 2024 vs EU Cyber Resilience Act | Full CRA Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act.md): Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements. - [Australia Cyber Security Act 2024 vs UK PSTI Act | Product Security Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act.md): Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements. - [Australia Smart Device Compliance Checklist | Cyber Security Act 2024 | Sorena](/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist.md): Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure. - [Penalties and fines | Australia Cyber Security Act 2024 | 60 Penalty Units, Smart Device Enforcement, Ransomware Reporting](/artifacts/apac/australia-cyber-security-act/penalties-and-fines.md): Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals. - [Ransomware Payment Reporting in 72 Hours | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours.md): Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. - [Scope and Definitions | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/scope-and-definitions.md): Complete guide to the Australia Cyber Security Act 2024 scope and definitions. - [Smart device security standards | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/smart-device-security-standards.md): Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2. - [Statement of Compliance and Recordkeeping | Australia Cyber Security Act 2024 | Section 9, Section 10, 5 Year Retention](/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping.md): Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/australia-cyber-security-act/requirements --- --- title: "Scope and Definitions" canonical_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/scope-and-definitions" source_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/scope-and-definitions" author: "Sorena AI" description: "Complete guide to the Australia Cyber Security Act 2024 scope and definitions." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "Australia Cyber Security Act 2024 scope" - "Australia Cyber Security Act 2024 definitions" - "relevant connectable product meaning" - "internet connectable product definition" - "network connectable product definition" - "consumer grade smart device" - "reporting business entity meaning" - "ransomware payment definition" - "cyber security incident definition" - "manufacturer definition Australia" - "supplier definition Australia" - "designated Commonwealth body" - "extraterritorial scope" - "statement of compliance" - "defined support period" - "turnover threshold 3 million" - "relevant connectable product" - "internet connectable product" - "network connectable product" - "reporting business entity" - "Australia smart device security standard" - "APAC cyber compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Scope and Definitions Complete guide to the Australia Cyber Security Act 2024 scope and definitions. *Artifact Guide* *APAC* ## Australia Cyber Security Act 2024 Scope and Definitions A comprehensive reference to every key definition in the Australia Cyber Security Act 2024, from relevant connectable product and consumer grade class to reporting business entity, cyber security incident, ransomware payment, and extraterritorial reach. Clean scope work is the foundation for compliance. If your teams do not share the same statutory vocabulary, product decisions, incident escalations, and reporting obligations will all drift. The Australia Cyber Security Act 2024 (No. 98, 2024) relies on a precise set of defined terms that determine which products must meet security standards (Part 2), which entities must report ransomware payments (Part 3), and how the Government coordinates significant cyber security incidents (Part 4). This page provides a detailed walkthrough of every definition that compliance professionals, product managers, legal counsel, and incident response teams need to operationalise the Australia Cyber Security Act 2024. Each section below quotes the statutory language from the Act or its subordinate Rules, explains the practical effect, and gives examples of how scope decisions play out. ## Extraterritorial Application of the Australia Cyber Security Act 2024 (Section 5) Section 5 of the Australia Cyber Security Act 2024 states: 'This Act applies both within and outside Australia.' The Act also extends to every external Territory. This means that a manufacturer based overseas who manufactures products that will be acquired in Australia by consumers must comply with the security standards in Part 2. Similarly, a foreign entity that makes a ransomware payment following an incident that impacts a reporting business entity carrying on business in Australia is within scope of the Part 3 reporting obligation. The extraterritorial reach of the Australia Cyber Security Act 2024 is important for global supply chains. If a manufacturer in Shenzhen or Seoul ships smart home devices to Australian retailers, that manufacturer has obligations under the Act as long as they are aware, or could reasonably be expected to be aware, that the product will be acquired in Australia. The Act also binds the Crown in each of its capacities (section 6), and operates concurrently with State and Territory laws (section 7), so there is no gap in coverage across jurisdictions. - Section 5: 'This Act applies both within and outside Australia.' It extends to every external Territory. - Section 6: The Act binds the Crown in each of its capacities, though the Crown (other than a Crown authority) is not liable to prosecution for an offence. - Section 7: The Act does not exclude or limit State or Territory laws that can operate concurrently. - Practical effect: overseas manufacturers and suppliers must comply if they know or should know their products will be acquired in Australia. - Constitutional heads of power in section 9(2) and section 15(5) limit some obligations to corporations, trade and commerce, and the telecommunications power, but the presumptions in section 26(4) broaden the practical reach of the ransomware provisions. ## Relevant Connectable Product Under the Australia Cyber Security Act 2024 (Section 13) The central scope term in Part 2 of the Australia Cyber Security Act 2024 is 'relevant connectable product.' Section 13(2) defines it as a product that is either an internet connectable product or a network connectable product, and that is not exempted under the rules. Part 2 applies to a relevant connectable product that is manufactured on or after the commencement of Part 2, or supplied (other than as second hand goods) on or after that commencement (section 13(1)). The rules may specify that classes of products or particular products are exempted (section 13(3)). At the time of writing, the Cyber Security (Security Standards for Smart Devices) Rules 2025 focus the first security standard on consumer grade relevant connectable products, with a defined set of exclusions (see section below). Products that are not internet connectable and not network connectable are entirely outside the scope of Part 2 of the Australia Cyber Security Act 2024. - Section 13(2): A relevant connectable product is a product that (a) is an internet connectable product or a network connectable product, and (b) is not exempted under the rules. - Section 13(1): Part 2 applies to products manufactured on or after commencement, or supplied (other than as second hand goods) on or after commencement. - Section 13(3): The rules may exempt classes of products or particular products. - Second hand goods are excluded from the supply trigger, so resale markets do not create new compliance obligations for the seller. - The scope of Part 2 may expand over time through new rules that add product classes or change the exemptions. ## Internet Connectable Product (Section 13(4)) Section 13(4) of the Australia Cyber Security Act 2024 defines an 'internet connectable product' as a product that is capable of connecting to the internet using a communication protocol that forms part of the internet protocol suite to send and receive data over the internet. This covers any product with a TCP/IP stack (or equivalent) that can exchange data with internet hosts. Common examples include smart speakers, smart TVs, IP cameras, Wi-Fi routers, smart home hubs, and connected appliances. The definition turns on capability, not on whether the product is always connected. A device that has a Wi-Fi module but ships in a disconnected state is still an internet connectable product under the Australia Cyber Security Act 2024 because it is 'capable' of connecting. Compliance professionals should map each product's connectivity features against this definition as the first step in a Part 2 scope assessment. - Section 13(4): 'An internet connectable product is a product that is capable of connecting to the internet using a communication protocol that forms part of the internet protocol suite to send and receive data over the internet.' - The test is capability, not active use. A product with a dormant internet module is still in scope. - Examples: smart speakers, IP cameras, smart TVs, connected home appliances, Wi-Fi enabled wearables, smart lighting bridges, connected printers. - Products that only communicate over Bluetooth, Zigbee, or Z-Wave without any internet protocol capability are not internet connectable products (though they may qualify as network connectable products). ## Network Connectable Product (Sections 13(5) to 13(10)) Section 13(5) of the Australia Cyber Security Act 2024 defines a 'network connectable product' as a product that (a) is capable of both sending and receiving data by means of a transmission involving electrical or electromagnetic energy, (b) is not an internet connectable product, and (c) meets the condition in subsection (6) or (7). This second category captures devices that do not directly use the internet protocol suite but connect indirectly to the internet through other devices. Under section 13(6), a product meets the condition if it is capable of connecting directly to an internet connectable product by means of a communication protocol that forms part of the internet protocol suite. Under section 13(7), a product meets the condition if it can connect directly to two or more products at the same time using a protocol outside the internet protocol suite, and can also connect directly to an internet connectable product through that protocol. This brings in hub devices that bridge between non-IP protocols and IP networks. Section 13(8) excludes a product consisting of a wire or cable that is used merely to connect one product to another. Section 13(9) handles multi-product sets designed to facilitate the use of a computer, such as a wireless keyboard and mouse set connected through a USB dongle. Section 13(10) clarifies that a wired connection does not prevent a product from being regarded as connecting 'directly' to another product. - Section 13(5): A network connectable product sends and receives data via electrical or electromagnetic energy, is not an internet connectable product, and meets section 13(6) or 13(7). - Section 13(6): Capable of connecting directly to an internet connectable product using the internet protocol suite. - Section 13(7): Capable of connecting to two or more products simultaneously via a non-IP protocol, and also capable of connecting directly to an internet connectable product. - Section 13(8): A wire or cable used merely to connect one product to another is excluded. - Section 13(9): Multi-product sets designed for use with a computer (e.g. wireless keyboard and dongle combinations) are handled through the 'linking product' and 'input product' framework. - Section 13(10): A wired connection does not prevent a product from qualifying as directly connected. - Examples: Zigbee sensors that pair through an internet connected hub, Bluetooth peripherals that relay data through a phone, Z-Wave home automation devices that communicate through a smart home bridge. ## Consumer Grade Class and Exclusions Under the Smart Device Rules 2025 The Cyber Security (Security Standards for Smart Devices) Rules 2025 prescribe the first security standard under the Australia Cyber Security Act 2024. Section 8(1) of the Rules defines the covered class as all relevant connectable products that are intended by the manufacturer to be used, or are of a kind likely to be used, for personal, domestic or household use or consumption. This is the 'consumer grade' class. Section 8(1)(b) of the Rules lists six product categories that are excluded from the consumer grade class even if they otherwise meet the definition: (i) a desktop computer or a laptop, (ii) a tablet computer, (iii) a smartphone, (iv) therapeutic goods within the meaning of the Therapeutic Goods Act 1989, (v) a road vehicle within the meaning of the Road Vehicle Standards Act 2018, and (vi) a road vehicle component within the meaning of the Road Vehicle Standards Act 2018. These exclusions recognise that those product types are already subject to other regulatory frameworks or have complexity that warrants separate treatment. The 'consumer' term itself is defined in section 6 of the Rules by reference to section 3 of the Australian Consumer Law. A person has acquired particular goods as a consumer if the person would be taken to have acquired the goods as a consumer under that provision. The specified circumstance for this class is that the products will be acquired in Australia by a consumer (section 8(2)). - Rules section 8(1)(a): Products intended by the manufacturer for personal, domestic or household use or consumption, or of a kind likely to be used for those purposes. - Excluded: desktop computers, laptops, tablet computers, smartphones, therapeutic goods, road vehicles, road vehicle components. - Rules section 6: 'Consumer' has the meaning from section 3 of the Australian Consumer Law. - Rules section 8(2): The specified circumstance is acquisition in Australia by a consumer. - Products used in commercial or industrial settings may still be in scope if they are 'of a kind likely to be used' for personal, domestic, or household use. A smart security camera marketed to both homeowners and small businesses is likely in scope. - Future rules under the Australia Cyber Security Act 2024 may add additional product classes beyond consumer grade. ## Manufacturer and Supplier Under the Australia Cyber Security Act 2024 (Section 8) Section 8 of the Australia Cyber Security Act 2024 defines 'manufacturer' as having the same meaning as in the Australian Consumer Law (ACL). Under the ACL, a manufacturer of goods includes the person who actually makes or assembles the goods, the person who holds themselves out as the manufacturer by applying their name or brand, a person who imports goods where the actual manufacturer has no place of business in Australia, and certain other parties. This broad ACL definition is critical because it determines who bears the obligation to manufacture products in compliance with the security standard (section 15) and to provide a statement of compliance (section 16). Section 8 also defines 'supply' as having the same meaning as in the Australian Consumer Law, and 'supplied' and 'supplier' have corresponding meanings. Under the ACL, supply includes sale, exchange, lease, hire, and hire purchase. For the Australia Cyber Security Act 2024, the supplier obligation under section 15(3) is that an entity must not supply a product in Australia that was not manufactured in compliance with the security standard, if the entity is aware or could reasonably be expected to be aware that the product will be acquired in Australia in the specified circumstances. Suppliers must also supply the product with a statement of compliance (section 16(3)). The awareness test is important. Both manufacturer obligations (section 15(1)(b)) and supplier obligations (section 15(3)(b)) turn on whether the entity 'is aware, or could reasonably be expected to be aware, that the product will be acquired in Australia' in the specified circumstances. This constructive knowledge standard means that a manufacturer who sells through a global distribution network cannot claim ignorance if their products routinely appear in Australian retail channels. - Section 8: 'Manufacturer' has the same meaning as in the Australian Consumer Law. - ACL manufacturer includes: the actual maker, a person who applies their name or brand, an importer where the actual manufacturer has no Australian presence. - Section 8: 'Supply' has the same meaning as in the Australian Consumer Law. 'Supplied' and 'supplier' have corresponding meanings. - ACL supply includes sale, exchange, lease, hire, and hire purchase. - Section 15(1)(b) and 15(3)(b): Obligations turn on awareness or constructive awareness that the product will be acquired in Australia. - Practical tip: document your supply chain mapping and market intelligence to demonstrate that you have assessed whether products reach Australian consumers. ## Statement of Compliance and Defined Support Period Two terms from Part 2 of the Australia Cyber Security Act 2024 and the Smart Device Rules 2025 have direct operational impact. The 'statement of compliance' is the document that manufacturers must provide for the supply of in scope products in Australia, and that suppliers must supply with the product. Section 9 of the Rules specifies that the statement must be prepared by, or on behalf of, the manufacturer and must include: the product type and batch identifier, the name and address of the manufacturer and any authorised representatives (including any in Australia), a declaration that the statement was prepared by or on behalf of the manufacturer, a declaration that the product was manufactured in compliance with the security standard, the defined support period at the date of issue, the signature and function of the manufacturer's signatory, and the place and date of issue. The 'defined support period' is defined in Schedule 1, clause 4(3) of the Rules as the period, expressed as a period of time with an end date, for which security updates will be provided by or on behalf of the manufacturer. The manufacturer must publish this defined support period. Clause 4(4) provides that the manufacturer must not shorten the defined support period after it is published. If the manufacturer extends the period, the new defined support period must be published as soon as is practicable (clause 4(5)). The defined support period information must be accessible, clear, transparent, available without prior request, in English, free of charge, and without requiring personal information from the reader (clause 4(6)). The retention period for a statement of compliance is 5 years (Rules section 10). Manufacturers and suppliers should treat the statement of compliance as a controlled regulatory document, not as marketing material. The support period is a binding commitment that must be backed by engineering capacity to deliver security updates for the entire published duration. - Rules section 9(3): Statement must include product type, batch identifier, manufacturer details, authorised representative details, compliance declaration, defined support period, signatory details, and date and place of issue. - Rules section 10: Retention period for statement of compliance is 5 years. - Schedule 1, clause 4(3): Defined support period is a period with an end date for which security updates will be provided. - Schedule 1, clause 4(4): The manufacturer must not shorten the defined support period after publication. - Schedule 1, clause 4(5): If extended, the new period must be published as soon as is practicable. - Schedule 1, clause 4(6)/(7): Support period information must be accessible, clear, transparent, in English, free, and prominently displayed alongside product characteristics on the manufacturer's website. - Practical tip: treat the defined support period as a contractual commitment. Align it with your engineering team's actual capacity to deliver security updates for the full duration. ## Reporting Business Entity Under the Australia Cyber Security Act 2024 (Section 26(2)) The ransomware reporting obligation in Part 3 of the Australia Cyber Security Act 2024 does not apply to every victim of a cyber security incident. It applies only to a 'reporting business entity.' Section 26(2) defines two routes into this status. Under route (a), an entity is a reporting business entity if, at the time the ransomware payment is made, it is carrying on a business in Australia with an annual turnover for the previous financial year that exceeds the turnover threshold, and it is not a Commonwealth body, a State body, or a responsible entity for a critical infrastructure asset. Under route (b), an entity is a reporting business entity if it is a responsible entity for a critical infrastructure asset to which Part 2B of the Security of Critical Infrastructure Act 2018 applies. The Cyber Security (Ransomware Payment Reporting) Rules 2025 set the turnover threshold at $3 million for the previous financial year (Rules section 6(1)). If a business has been carried on for only part of the previous financial year, the threshold is pro-rated using the formula: $3 million multiplied by the number of days in the part of the year, divided by the number of days in the full financial year (Rules section 6(2)). The 'business' term itself has the same meaning as in the Income Tax Assessment Act 1997 (section 8 of the Act). This two-track structure means that most mid-size and large businesses operating in Australia are captured either through the turnover route or the critical infrastructure route. Commonwealth bodies and State bodies are explicitly excluded from the turnover route, but responsible entities for critical infrastructure assets covered by SOCI Part 2B are captured regardless of their turnover. The test is assessed at the time the ransomware payment is made, not at the time the incident occurs. - Section 26(2)(a): Entity carrying on business in Australia, annual turnover exceeds threshold, not a Commonwealth body or State body, not a responsible entity for a critical infrastructure asset. - Section 26(2)(b): Entity is a responsible entity for a critical infrastructure asset to which Part 2B of the SOCI Act 2018 applies. - Rules section 6(1): Turnover threshold is $3 million for the previous financial year. - Rules section 6(2): Pro-rata formula for businesses operating for only part of the year. - Section 8: 'Business' has the same meaning as in the Income Tax Assessment Act 1997. - The test is applied at the time the ransomware payment is made. - Practical tip: check critical infrastructure status first because route (b) has no turnover minimum. Then check whether the entity carries on business in Australia with turnover above $3 million. Document the calculation method and source data used. ## Cyber Security Incident Under the Australia Cyber Security Act 2024 (Section 9) Section 9(1) of the Australia Cyber Security Act 2024 defines a 'cyber security incident' as one or more acts, events or circumstances (a) of a kind covered by the meaning of cyber security incident in the Security of Critical Infrastructure Act 2018, or (b) involving unauthorised impairment of electronic communication to or from a computer, within the meaning of that phrase in that Act, but as if that phrase did not exclude the mere interception of any such communication. The cross-reference to the SOCI Act anchors the definition in the existing critical infrastructure framework while expanding it slightly to include interception. Section 9(2) narrows the definition by requiring a constitutional nexus. An incident is only a cyber security incident for the purposes of the Australia Cyber Security Act 2024 if: (a) it involves a critical infrastructure asset, or (b) it involves the activities of a corporation to which paragraph 51(xx) of the Constitution applies, or (c) it is effected by means of a telegraphic, telephonic or other like service (including the internet), or (d) it is impeding or impairing the ability of a computer to connect to such a service, or (e) it has seriously prejudiced or is seriously prejudicing the social or economic stability of Australia, the defence of Australia, or national security. For the ransomware reporting obligation, section 26(4) creates a presumption: an incident is presumed to be a cyber security incident if it was probably effected by internet means, or probably impeded a computer's ability to connect to such a service, or probably seriously prejudiced national security, social stability, or defence. This lowers the evidentiary burden on the reporting entity and means that most ransomware scenarios will satisfy the cyber security incident definition without detailed constitutional analysis. - Section 9(1)(a): Incidents of a kind covered by the SOCI Act 2018 definition of cyber security incident. - Section 9(1)(b): Unauthorised impairment of electronic communication to or from a computer, including interception (which the SOCI Act otherwise excludes). - Section 9(2)(a): Involves a critical infrastructure asset. - Section 9(2)(b): Involves the activities of a constitutional corporation. - Section 9(2)(c): Effected by means of a telegraphic, telephonic, or like service, including the internet. - Section 9(2)(d): Impedes or impairs a computer's ability to connect to such a service. - Section 9(2)(e): Seriously prejudices social or economic stability, defence, or national security. - Section 26(4): Presumption lowers the evidentiary threshold for ransomware reporting. If the incident was probably internet-based, it is presumed to be a cyber security incident. - Practical tip: for incident response playbooks, assume any ransomware event delivered over the internet satisfies the definition. Spend your time gathering facts for the report, not debating whether the constitutional nexus is met. ## Ransomware Payment Under the Australia Cyber Security Act 2024 (Section 26(1)) Section 26(1)(d) and (e) of the Australia Cyber Security Act 2024 define the ransomware payment concept. The payment arises when an extorting entity makes a demand of the reporting business entity (or any other entity) in order to benefit from the incident or its impact on the reporting business entity, and the reporting business entity provides, or is aware that another entity has provided on their behalf, a payment or benefit that is directly related to the demand. The term 'benefit' is defined in section 8 to include any advantage and is not limited to property. This means that providing decryption keys, data restoration, or any other form of value to the extorting party counts. The 72-hour reporting clock starts from when the ransomware payment is made or when the reporting business entity becomes aware that the payment has been made, whichever is applicable (section 27(1)). The report must be given to the designated Commonwealth body, which by default means the Department of Home Affairs and ASD (section 8). The report must contain information about: the reporting entity's contact and business details, the other entity's details if a third party made the payment, the cyber security incident and its impact, the demand, the payment, and the communications with the extorting entity (section 27(2)). It is important that the reporting obligation is triggered even when another entity makes the payment on behalf of the reporting business entity. This means that if an insurer, a negotiation firm, or a parent company makes the payment, the reporting business entity must still file the report as long as it is aware the payment was made. The Australia Cyber Security Act 2024 thus prevents the reporting obligation from being circumvented through intermediaries. - Section 26(1)(d): An extorting entity makes a demand in order to benefit from the incident or its impact. - Section 26(1)(e): The reporting business entity provides, or is aware another entity has provided on their behalf, a payment or benefit directly related to the demand. - Section 8: 'Benefit' includes any advantage and is not limited to property. - Section 27(1): Report must be given within 72 hours of making the payment or becoming aware it was made. - Section 27(2): Report must cover: entity contact details, incident details, impact, the demand, the payment, and communications with the extorting entity. - Rules section 7(4): Incident information must include when it occurred, when the entity became aware, infrastructure impact, customer impact, ransomware or malware variants, exploited vulnerabilities, and information that could assist response or mitigation. - Rules section 7(5): Demand information must include amount or description and method of provision demanded. - Rules section 7(6): Payment information must include amount or description and method of provision. - Rules section 7(7): Communications information must include nature and timing of communications, brief description, and pre-payment negotiations. - Practical tip: establish escalation paths that include insurers, external negotiators, and legal advisors so that the 72-hour window is not lost while determining who actually made the payment. ## Designated Commonwealth Body (Section 8) Section 8 of the Australia Cyber Security Act 2024 defines 'designated Commonwealth body' as (a) a Department, or a body established by a law of the Commonwealth, specified in the rules, or (b) if no rules have been made for paragraph (a), the Department and ASD (the Australian Signals Directorate). As of the commencement of Part 3, no rules have been made specifying alternative bodies, so the designated Commonwealth body remains the Department of Home Affairs and ASD. This is the entity to which ransomware payment reports must be given under section 27. The definition is designed to be flexible. If the Government decides in the future to designate a different or additional body (for example, a dedicated cyber security reporting agency), it can do so through rules without amending the primary legislation. Compliance teams should monitor the Federal Register of Legislation for any rules made under this provision. - Section 8: Designated Commonwealth body means a Department or body specified in the rules, or if no rules exist, the Department (Home Affairs) and ASD. - ASD means the Australian Signals Directorate (section 8). - Ransomware payment reports under section 27 must be given to the designated Commonwealth body. - Practical tip: monitor the Federal Register of Legislation for any rules that change the designated body. Until then, submit reports to the Department of Home Affairs and ASD. ## Entity, Commonwealth Body, State Body, and Commonwealth Enforcement Body The Australia Cyber Security Act 2024 defines 'entity' broadly in section 8 to include an individual, a body corporate, a partnership, an unincorporated association that has a governing body, a trust, and an entity that is a responsible entity for a critical infrastructure asset. This broad definition means that natural persons, companies, partnerships, trusts, and critical infrastructure operators can all be subject to the Act's obligations. A 'Commonwealth body' means a Minister of the Commonwealth, a Department of State of the Commonwealth, or a body established for a public purpose by or under a law of the Commonwealth that is not an authority of the Crown. A 'State body' follows the same pattern for State and Territory Ministers, Departments, and statutory bodies. These definitions matter because Commonwealth bodies and State bodies are excluded from the turnover route into reporting business entity status (section 26(2)(a)(ii)). The 'Commonwealth enforcement body' definition lists specific agencies: the Australian Federal Police, APRA, ASIC, the Inspector of the National Anti-Corruption Commission, the Office of the Director of Public Prosecutions, the National Anti-Corruption Commissioner, Sport Integrity Australia, and any other Commonwealth body responsible for administering a law that imposes a criminal penalty or sanction. This list determines which bodies may receive information from ransomware payment reports for enforcement functions under the permitted cyber security purpose framework. - Section 8: 'Entity' includes individuals, body corporates, partnerships, unincorporated associations with a governing body, trusts, and responsible entities for critical infrastructure assets. - Section 8: 'Commonwealth body' includes Commonwealth Ministers, Departments, and public purpose statutory bodies (excluding Crown authorities). - Section 8: 'State body' includes State/Territory Ministers, Departments, and public purpose statutory bodies. - Section 8: 'Commonwealth enforcement body' includes the AFP, APRA, ASIC, NACC Inspector, DPP, NACC Commissioner, Sport Integrity Australia, and other criminal law agencies. - Commonwealth bodies and State bodies are excluded from the turnover-based route into reporting business entity status. - The enforcement body list determines who may receive ransomware report information for enforcement purposes. ## Permitted Cyber Security Purpose (Section 10) Section 10 of the Australia Cyber Security Act 2024 defines 'permitted cyber security purpose' for a cyber security incident. This concept controls how information from ransomware payment reports and voluntary information sharing can be used and disclosed. The permitted purposes are: (a) a Commonwealth body's functions relating to responding to, mitigating or resolving the incident, (b) a State body's equivalent functions, (c) the National Cyber Security Coordinator's Part 4 functions, (d) informing and advising the Minister and other Commonwealth Ministers, (e) preventing or mitigating material risks to social or economic stability, defence, or national security, (f) preventing or mitigating material risks to a critical infrastructure asset, (g) the functions of an intelligence agency, and (h) the functions of a Commonwealth enforcement body. The use restriction in section 29(2) prevents the designated Commonwealth body from using ransomware report information to investigate or enforce any contravention of a Commonwealth, State, or Territory law against the reporting entity, except for a contravention of Part 3 itself or a criminal offence. Section 32 further provides that information in a ransomware payment report is not admissible in evidence in most civil proceedings against the reporting entity. These protections are designed to encourage honest reporting by reducing the legal risk that comes with disclosing a ransomware payment. - Section 10(a)-(h): Permitted purposes cover incident response, Government coordination, national security, intelligence functions, and enforcement body functions. - Section 29(2): Ransomware report information cannot be used against the reporting entity for civil or regulatory enforcement, except for Part 3 contraventions or criminal offences. - Section 32: Ransomware report information is generally not admissible against the reporting entity in civil proceedings. - Section 28: An entity acting in good faith in compliance with section 27 is not liable for damages. - These protections are a deliberate incentive structure. The Australia Cyber Security Act 2024 wants entities to report, not to hide ransomware payments for fear of regulatory action. ## Significant Cyber Security Incident (Section 34) and Voluntary Information Sharing Part 4 of the Australia Cyber Security Act 2024 provides a separate framework for the coordination of significant cyber security incidents. Section 34 defines a 'significant cyber security incident' by reference to criteria set out in the Act and allows the National Cyber Security Coordinator to lead the whole of Government response. Under section 35, an entity impacted by a significant cyber security incident may voluntarily provide information to the National Cyber Security Coordinator. Section 36 also allows voluntary provision of information about other incidents or cyber security incidents more broadly. The voluntary information sharing provisions in Part 4 carry strong protections. Information provided under section 35 is subject to use and disclosure restrictions in sections 38 through 43. Section 42 makes voluntarily given information generally inadmissible against the entity, and section 43 provides that the National Cyber Security Coordinator is not compellable as a witness in relation to information provided under Part 4. These protections are separate from and additional to the ransomware reporting protections in Part 3. - Section 34: Defines 'significant cyber security incident' for the Part 4 coordination framework. - Section 35: Impacted entities may voluntarily provide information to the National Cyber Security Coordinator. - Section 37: The National Cyber Security Coordinator leads the whole of Government coordination and triaging of the response. - Sections 38-40: Use and disclosure restrictions on information provided in relation to significant cyber security incidents. - Section 42: Voluntarily given information is generally inadmissible against the entity. - Section 43: The National Cyber Security Coordinator is not compellable as a witness. ## Security Standard Obligations and Enforcement Under the Australia Cyber Security Act 2024 Part 2 of the Australia Cyber Security Act 2024 creates a three-tier enforcement framework for security standard non-compliance. If the Secretary is reasonably satisfied that an entity is not complying with its obligations under section 15 or 16, the Secretary may issue a compliance notice (section 17). If the entity fails to comply with the compliance notice, a stop notice may follow (section 18). If the entity fails to comply with the stop notice, a recall notice may follow (section 19). Each notice must give the entity at least 10 days to make representations before being issued. If an entity fails to comply with a recall notice, the Minister may publicly notify the failure, including the entity's identity, product details, non-compliance details, risks posed by the product, and any other matters prescribed by the rules (section 20). Entities may seek internal review of the decision to issue any notice (section 22), and the Secretary may engage independent experts to examine products for compliance (section 23). Part 6 provides additional regulatory powers including civil penalties, enforceable undertakings, injunctions, monitoring powers, and investigation powers. The civil penalty for failing to make a ransomware payment report under section 27 is 60 penalty units. However, section 28 provides that an entity is not liable for damages for acts done in good faith in compliance with section 27, giving legal shelter to entities that report honestly and promptly. - Section 17: Compliance notice for non-compliance with section 15 or 16. - Section 18: Stop notice if entity fails to comply with compliance notice. - Section 19: Recall notice if entity fails to comply with stop notice. - Section 20: Public notification of failure to comply with recall notice. - Section 22: Internal review within 30 days of notice being given. - Section 23: Secretary may engage independent experts for compliance examination. - Section 27(5): Civil penalty of 60 penalty units for failure to report a ransomware payment. - Section 28: Good faith liability protection for entities complying with the reporting obligation. - At least 10 days must be given for representations before any enforcement notice is issued. ## Other Key Definitions in the Australia Cyber Security Act 2024 Several additional definitions in section 8 of the Australia Cyber Security Act 2024 are relevant for compliance work. 'Computer' has the same meaning as in the Security of Critical Infrastructure Act 2018. 'Critical infrastructure asset' also has the same meaning as in SOCI 2018, tying the Act's scope directly to the existing critical infrastructure register. 'Responsible entity' for an asset has the same meaning as in SOCI 2018. 'Personal information' and 'sensitive information' have the same meanings as in the Privacy Act 1988. The Act establishes the Cyber Incident Review Board (CIRB) through section 60, with functions that include causing reviews of certain cyber security incidents and making recommendations to Government and industry (section 62). The Board operates independently (section 63) and produces draft review reports (section 51), final review reports (section 52), and protected review reports (section 54). Sensitive review information must be redacted from final reports (section 53). These definitions support the Part 5 framework for post-incident learning, which runs separately from the Part 3 reporting obligation. The 'National Cyber Security Coordinator' is defined in section 8 as the officer of the Department known by that title, together with the APS employees and officers whose services are made available in connection with the Coordinator's functions and powers. This definition ensures that the Coordinator has a supporting team, not just an individual role, for incident coordination under Part 4. - Section 8: 'Computer' has the same meaning as in the SOCI Act 2018. - Section 8: 'Critical infrastructure asset' has the same meaning as in the SOCI Act 2018. - Section 8: 'Responsible entity' has the same meaning as in the SOCI Act 2018. - Section 8: 'Personal information' and 'sensitive information' have the same meanings as in the Privacy Act 1988. - Section 60: Cyber Incident Review Board is established for post-incident reviews. - Section 8: 'National Cyber Security Coordinator' includes the named officer and supporting staff. - Section 8: 'Ransomware payment report' means a report given under subsection 27(1). - Section 8: 'Relevant connectable product' has the meaning given by subsection 13(2). - Section 8: 'Reporting business entity' has the meaning given by subsection 26(2). *Recommended next step* *Placement: after the scope or definition section* ## Use Australia Cyber Security Act 2024 Scope and Definitions as a cited research workflow Research Copilot can take Australia Cyber Security Act 2024 Scope and Definitions from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on Australia Cyber Security Act 2024 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Australia Cyber Security Act 2024 Scope and Definitions](/solutions/research-copilot.md): Start from Australia Cyber Security Act 2024 Scope and Definitions and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Australia Cyber Security Act 2024](/contact.md): Review your current process, evidence gaps, and next steps for Australia Cyber Security Act 2024 Scope and Definitions. ## Primary sources - [Cyber Security Act 2024 (No. 98, 2024) official text](https://www.legislation.gov.au/C2024A00098/latest/text?ref=sorena.io) - Primary legislation containing all scope definitions, Part 2 smart device standards, Part 3 ransomware reporting, Part 4 incident coordination, and Part 5 Cyber Incident Review Board. - [Cyber Security (Security Standards for Smart Devices) Rules 2025 official text](https://www.legislation.gov.au/F2025L00276/asmade/text?ref=sorena.io) - Subordinate instrument defining the consumer grade class, product exclusions, statement of compliance requirements, defined support period, security standard for passwords, vulnerability reporting, and security updates. - [Cyber Security (Ransomware Payment Reporting) Rules 2025 official text](https://www.legislation.gov.au/F2025L00278/asmade/text?ref=sorena.io) - Subordinate instrument setting the $3 million turnover threshold, pro-rata formula, and detailed content requirements for ransomware payment reports. - [Security of Critical Infrastructure Act 2018 (SOCI Act) details](https://www.legislation.gov.au/Details/C2018A00029?ref=sorena.io) - Cross-referenced Act for the definitions of cyber security incident, critical infrastructure asset, responsible entity, and computer used throughout the Australia Cyber Security Act 2024. - [Australian Consumer Law (Schedule 2 to the Competition and Consumer Act 2010)](https://www.legislation.gov.au/Details/C2024C00136?ref=sorena.io) - Source of the manufacturer, supplier, supply, and consumer definitions adopted by the Australia Cyber Security Act 2024. ## Related Topic Guides - [Australia Cyber Security Act 2024 Applicability Test | Who Must Comply](/artifacts/apac/australia-cyber-security-act/applicability-test.md): Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations. - [Australia Cyber Security Act 2024 Compliance Checklist](/artifacts/apac/australia-cyber-security-act/checklist.md): Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting. - [Australia Cyber Security Act 2024 Compliance Guide | Implementation Playbook](/artifacts/apac/australia-cyber-security-act/compliance.md): A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements. - [Australia Cyber Security Act 2024 Compliance Templates | Statement of Compliance, Ransomware Report, Evidence Pack, Vulnerability Disclosure, Support Period](/artifacts/apac/australia-cyber-security-act/templates.md): Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field. - [Australia Cyber Security Act 2024 Deadlines and Compliance Calendar | Commencement Dates](/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar.md): Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent. - [Australia Cyber Security Act 2024 FAQ | Frequently Asked Questions](/artifacts/apac/australia-cyber-security-act/faq.md): Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024. - [Australia Cyber Security Act 2024 Requirements | Smart Device and Ransomware Reporting Obligations](/artifacts/apac/australia-cyber-security-act/requirements.md): Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure. - [Australia Cyber Security Act 2024 Timeline and Commencement Dates | Full Schedule](/artifacts/apac/australia-cyber-security-act/timeline-and-commencement.md): Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024. - [Australia Cyber Security Act 2024 vs EU Cyber Resilience Act | Full CRA Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act.md): Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements. - [Australia Cyber Security Act 2024 vs UK PSTI Act | Product Security Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act.md): Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements. - [Australia Smart Device Compliance Checklist | Cyber Security Act 2024 | Sorena](/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist.md): Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure. - [Penalties and fines | Australia Cyber Security Act 2024 | 60 Penalty Units, Smart Device Enforcement, Ransomware Reporting](/artifacts/apac/australia-cyber-security-act/penalties-and-fines.md): Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals. - [Ransomware Payment Reporting in 72 Hours | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours.md): Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. - [Smart device security standards | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/smart-device-security-standards.md): Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2. - [Statement of Compliance and Recordkeeping | Australia Cyber Security Act 2024 | Section 9, Section 10, 5 Year Retention](/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping.md): Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/australia-cyber-security-act/scope-and-definitions --- --- title: "Australia Smart Device Compliance Checklist" canonical_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist" source_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist" author: "Sorena AI" description: "Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "Australia Cyber Security Act 2024 smart device compliance checklist" - "smart device compliance checklist Schedule 1" - "connectable product compliance checklist Australia" - "smart device release checklist Australia" - "statement of compliance checklist Australia" - "password compliance checklist smart devices" - "vulnerability disclosure checklist smart devices" - "defined support period checklist Australia" - "security update compliance checklist" - "smart device security standards checklist Australia" - "excluded products smart device rules" - "Section 8 excluded products" - "Section 9 statement of compliance" - "Section 10 recordkeeping" - "Clause 2 password requirements" - "Clause 3 vulnerability reporting" - "Clause 4 defined support period" - "connectable product compliance Australia" - "smart device password security checklist" - "statement of compliance Australia smart devices" - "smart device release gate Australia" - "APAC smart device compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Australia Smart Device Compliance Checklist Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure. *Artifact Guide* *APAC* ## Australia Cyber Security Act 2024 Smart Device Compliance Checklist A comprehensive, release-ready Australia Cyber Security Act 2024 smart device compliance checklist for manufacturers and suppliers of connectable products sold in Australia. Covers every requirement in Schedule 1 of the Cyber Security (Security Standards for Smart Devices) Rules 2025: password security under Clause 2, vulnerability disclosure under Clause 3, defined support period under Clause 4, statement of compliance under Section 9, recordkeeping under Section 10, and excluded products under Section 8. Built for product security engineers, compliance officers, product managers, legal counsel, and supply chain teams preparing smart devices for the Australian market. Part 2 and Schedule 1 of the Rules commenced on 4 March 2026, meaning every consumer grade connectable product supplied in Australia after that date must pass this Australia Cyber Security Act 2024 smart device compliance checklist. This Australia Cyber Security Act 2024 smart device compliance checklist translates the three mandatory security standards in Schedule 1 of the Smart Device Rules 2025, together with the statement of compliance and recordkeeping obligations in Part 2 of those Rules, into a practical, section by section release gate. Every checklist item maps directly to a clause in the Rules or a section of the Cyber Security Act 2024. Use this Australia Cyber Security Act 2024 smart device compliance checklist before manufacturing, before first supply, and at every product revision to confirm that your product meets the password security, vulnerability disclosure, and defined support period requirements. A product that passes every item on this checklist is ready for the Australian market. A product that fails any item should not be supplied until the gap is closed. The Rules closely follow the UK Product Security and Telecommunications Infrastructure (PSTI) Regulations 2023, so manufacturers already compliant with the UK PSTI framework can map their existing compliance evidence to this Australia Cyber Security Act 2024 smart device compliance checklist, provided all requirements set out in the Australian Rules are met. ## How to use this Australia Cyber Security Act 2024 smart device compliance checklist This Australia Cyber Security Act 2024 smart device compliance checklist is designed as a pre-supply release gate. Run through every section before a product enters the Australian distribution channel. Each checklist item corresponds to a specific clause in Schedule 1 of the Cyber Security (Security Standards for Smart Devices) Rules 2025 or a section in the Cyber Security Act 2024. The references are included so your legal and product teams can trace each requirement back to the official text. The Australia Cyber Security Act 2024 smart device compliance checklist is organized into eleven sections that mirror the structure of the Rules. Start with scope verification to confirm the product is covered. Then confirm the product does not fall into the excluded products list under Section 8. Move through each technical control: password security under Clause 2, vulnerability disclosure under Clause 3, and defined support period under Clause 4. After the technical controls, verify security update delivery capability, confirm public information accessibility, prepare the statement of compliance under Section 9, lock the evidence pack under Section 10, and complete supply chain readiness checks. If any item on this Australia Cyber Security Act 2024 smart device compliance checklist cannot be confirmed, stop the release process. Under Section 15 of the Act, manufacturers must manufacture in-scope products in compliance with the security standard if they are aware, or could reasonably be expected to be aware, that the product will be acquired in Australia. Under Section 16, suppliers must not supply a product in Australia if the product does not comply with the applicable security standard and the supplier is aware, or could reasonably be expected to be aware, of the non-compliance. Enforcement escalates from compliance notice (Section 17) to stop notice (Section 18) to recall notice (Section 19), with the Minister able to publish the failure publicly under Section 20. Each section of this Australia Cyber Security Act 2024 smart device compliance checklist includes practical testing criteria that describe how to verify each requirement. These testing criteria are not mandated by the Rules themselves, but they represent the evidence you would need to demonstrate compliance if the Secretary issues a compliance notice and you must respond within the minimum 10 day representation period provided under Section 17(3)(b) of the Act. *Recommended next step* *Placement: after the checklist block* ## Turn Australia Cyber Security Act 2024 Smart Device Compliance Checklist into an operational assessment Assessment Autopilot can take Australia Cyber Security Act 2024 Smart Device Compliance Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on Australia Cyber Security Act 2024 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Australia Cyber Security Act 2024 Smart Device Compliance Checklist](/solutions/assessment.md): Start from Australia Cyber Security Act 2024 Smart Device Compliance Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Australia Cyber Security Act 2024](/contact.md): Review your current process, evidence gaps, and next steps for Australia Cyber Security Act 2024 Smart Device Compliance Checklist. ## Product scope verification checklist for Australia Cyber Security Act 2024 smart devices The first step in the Australia Cyber Security Act 2024 smart device compliance checklist is to confirm whether the product falls within the scope of the Cyber Security (Security Standards for Smart Devices) Rules 2025. Section 8 of the Rules defines the class of products covered: all relevant connectable products that are intended by the manufacturer to be used, or are of a kind likely to be used, for personal, domestic or household use or consumption. The specified circumstance is that the products will be acquired in Australia by a consumer as defined under Section 3 of the Australian Consumer Law. Under Section 13 of the Cyber Security Act 2024, a relevant connectable product is a product that is an internet-connectable product or a network-connectable product and is not exempted under the Rules. An internet-connectable product can connect to the internet using a communication protocol that forms part of the internet protocol suite to send and receive data. A network-connectable product can send and receive data by electrical or electromagnetic energy and meets the conditions in Section 13(6) or 13(7) of the Act for indirect internet connectivity. This broad definition means that products communicating over Bluetooth, Zigbee, Z-Wave, or similar protocols to an internet-connected hub are still classified as relevant connectable products. The scope determination also depends on the Australian Consumer Law definition of consumer. Under Section 3 of the ACL, a person acquires goods as a consumer if the goods cost less than the prescribed threshold (currently $100,000 including GST), or the goods are of a kind ordinarily acquired for personal, domestic or household use and consumption regardless of cost, or the goods are a vehicle or trailer used primarily for transporting goods on public roads. Products that are not ordinarily acquired by consumers, such as smart meters installed by electricity retailers, fall outside the scope of this Australia Cyber Security Act 2024 smart device compliance checklist. Practical testing criteria for scope verification: Document the product's communication protocols and confirm whether it connects directly or indirectly to the internet. Record the manufacturer's intended use as stated on the label, in instructions, and in promotional materials. Confirm whether the product is of a kind ordinarily acquired by consumers. Check the price against the ACL threshold. Record the date of manufacture or first supply to confirm it falls on or after 4 March 2026. File the scope decision with a signature from the product compliance owner. - The product can connect directly or indirectly to the internet, making it a relevant connectable product under Section 13 of the Cyber Security Act 2024. Test by listing every communication protocol the product supports and confirming at least one provides a path to the internet. - The product is intended by the manufacturer for personal, domestic, or household use or consumption, or is of a kind likely to be used for those purposes, as required by Section 8(1)(a) of the Smart Device Rules 2025. Verify by reviewing the manufacturer's label, instructions for use, and all promotional or sales materials. - The product will be acquired in Australia by a consumer as defined under Section 3 of the Australian Consumer Law. Confirm price is below the $100,000 GST-inclusive threshold or that the product is of a kind ordinarily acquired for personal, domestic, or household use. - The product was manufactured on or after the commencement of Part 2 of the Cyber Security Act 2024, or will be supplied (other than as second hand goods) on or after that commencement date, as required by Section 13(1) of the Act - The legal entity (manufacturer or supplier), product model, product version, firmware version, and batch identifier are clearly documented for this Australia Cyber Security Act 2024 smart device compliance checklist review - A scope decision document has been prepared and signed by the compliance owner, explaining why the product is within the covered class under Section 8 of the Smart Device Rules 2025 ## Excluded products checklist under Section 8 of the Smart Device Rules 2025 Section 8(1)(b) of the Cyber Security (Security Standards for Smart Devices) Rules 2025 lists six categories of products that are explicitly excluded from the consumer grade class even if they are relevant connectable products intended for personal, domestic, or household use. These exclusions exist because the excluded products are covered by other regulatory frameworks or have component supply chains too complex for the current standard. If your product falls into one of the excluded categories, the Australia Cyber Security Act 2024 smart device compliance checklist does not apply to that product. However, you must document your exclusion decision and retain it for at least five years alongside any related product records. The six excluded categories are: desktop computers and laptops; tablet computers; smartphones; therapeutic goods within the meaning of the Therapeutic Goods Act 1989; road vehicles within the meaning of the Road Vehicle Standards Act 2018; and road vehicle components within the meaning of the Road Vehicle Standards Act 2018. The Explanatory Statement for the Rules explains the rationale for each exclusion. Desktop computers, tablets, and smartphones are excluded due to the difficulty manufacturers of these products would face in complying because of the complex nature of the supply chains of product components. Medical devices are excluded because they are more strictly regulated by the Therapeutic Goods Administration. Road vehicles and road vehicle components are excluded because they are covered by the Road Vehicle Standards Act 2018. Practical testing criteria for exclusion verification: If you are claiming an exclusion, identify which of the six categories applies. Then confirm the product meets the legal definition of that excluded category under the relevant Act. For example, a product claimed as a therapeutic good must actually be registered or listed as a therapeutic good under the Therapeutic Goods Act 1989. A product claimed as a road vehicle component must meet the definition under the Road Vehicle Standards Act 2018. A borderline product that does not cleanly fit an exclusion category should be treated as within scope of this Australia Cyber Security Act 2024 smart device compliance checklist. Edge cases to evaluate carefully: Consumer energy resources such as smart solar inverters and home battery systems are within scope of the Rules and are not excluded. Point of sale and contactless payment devices are within scope provided they cost less than the ACL threshold. Smart accessories for smartphones, such as Bluetooth earbuds, are within scope even though the smartphone itself is excluded, because the accessory is a separate relevant connectable product in its own right. - The product is not a desktop computer or a laptop, as excluded by Section 8(1)(b)(i) of the Smart Device Rules 2025 - The product is not a tablet computer, as excluded by Section 8(1)(b)(ii) of the Smart Device Rules 2025 - The product is not a smartphone, as excluded by Section 8(1)(b)(iii) of the Smart Device Rules 2025 - The product is not a therapeutic good within the meaning of the Therapeutic Goods Act 1989, as excluded by Section 8(1)(b)(iv) of the Smart Device Rules 2025. If claiming this exclusion, record the ARTG registration or listing number. - The product is not a road vehicle within the meaning of the Road Vehicle Standards Act 2018, as excluded by Section 8(1)(b)(v) of the Smart Device Rules 2025 - The product is not a road vehicle component within the meaning of the Road Vehicle Standards Act 2018, as excluded by Section 8(1)(b)(vi) of the Smart Device Rules 2025 - If an exclusion is claimed, the exclusion decision has been documented with a reference to the specific legal definition under the relevant Act and retained in the evidence pack for at least five years - If no exclusion applies, the product is confirmed as within scope and the remainder of this Australia Cyber Security Act 2024 smart device compliance checklist must be completed in full ## Password security compliance checklist under Clause 2 of Schedule 1 Clause 2 of Schedule 1 of the Smart Device Rules 2025 sets out the password security requirements for the Australia Cyber Security Act 2024 smart device compliance checklist. These requirements apply to passwords used with the hardware of the product (when not in factory default state), pre-installed software, and any software that must be installed for the manufacturer's intended purposes. The password checklist items below cover both the unique per product model and the user-defined model. The definition of password in Clause 1 of Schedule 1 excludes cryptographic keys, personal identification numbers used for pairing in communication protocols that do not form part of the internet protocol suite, and application programming interface keys. The Rules define 'unique per product' as unique for each individual product of a given product class or type. This means every single manufactured unit must have a different password. The Rules also define several prohibited derivation methods in Clause 2(3). Passwords must not be based on incremental counters (such as 'password1' and 'password2'). Passwords must not be based on or derived from publicly available information. Passwords must not be based on or derived from unique product identifiers such as serial numbers, unless the derivation uses an encryption method or keyed hashing algorithm accepted as good industry practice. Passwords must not be otherwise guessable in a manner unacceptable as part of good industry practice. Good industry practice is defined in Clause 1 of Schedule 1 as the exercise of that degree of skill, diligence, prudence, and foresight which would reasonably and ordinarily be expected from a skilled and experienced cryptographer engaged in the same type of activity. This definition sets a high bar. A password generation scheme reviewed only by software developers, without input from a qualified cryptographer, may not meet this standard for this Australia Cyber Security Act 2024 smart device compliance checklist. If your product ships with no password and requires the user to set one during initial setup, the user-defined model under Clause 2(2)(b) applies and the prohibited derivation restrictions in Clause 2(3) do not apply. However, you must verify that the product cannot be used in any meaningful way without the user first setting a password. A product that can be operated, configured, or accessed over a network without authentication fails this section of the Australia Cyber Security Act 2024 smart device compliance checklist. Practical testing criteria for password security: Sample at least 20 units from different production batches. Extract the factory password from each unit and confirm every password is different. Verify no password follows an incremental counter pattern by checking for sequential characters across units. Confirm that no password can be derived from publicly visible information on the product packaging, label, or documentation. If passwords are derived from product identifiers, obtain the cryptographic design document and confirm a qualified cryptographer has reviewed the encryption method or keyed hashing algorithm. For the user-defined model, attempt to operate the product in a meaningful way without setting a password, including network access, configuration interfaces, and data retrieval. - Every password is either unique per product or defined by the user during setup, as required by Clause 2(2) of Schedule 1. Test by extracting default passwords from at least 20 units across multiple production batches and confirming every password is different. - No password is based on an incremental counter method, as prohibited by Clause 2(3)(a) of Schedule 1. Test by sorting all sampled passwords alphabetically and numerically and checking for sequential patterns such as 'password1', 'password2', or similar character rotation. - No password is based on or derived from publicly available information, as prohibited by Clause 2(3)(b) of Schedule 1. Test by cross-referencing each password against publicly visible information including MAC addresses, model numbers, packaging text, and any information available through unauthenticated network discovery. - No password is derived from unique product identifiers such as serial numbers, unless an encryption method or keyed hashing algorithm accepted as good industry practice is used, as required by Clause 2(3)(c) of Schedule 1. Test by collecting serial numbers from sampled units and confirming the password cannot be reconstructed from the serial number without knowledge of the secret key. - No password is otherwise guessable in a manner unacceptable as part of good industry practice, as required by Clause 2(3)(d) of Schedule 1. Test by running each sampled password against a common password dictionary and confirming no match is found. - The password generation process has been reviewed by a qualified cryptographer or security engineer against the good industry practice standard defined in Clause 1 of Schedule 1. Retain the cryptographic review report in the evidence pack. - Password compliance has been verified for all applicable components: hardware when not in factory default state, pre-installed software when not in factory default state, and software required for the manufacturer's intended purposes, as specified in Clause 2(1)(a), (b), and (c) of Schedule 1 - If the user-defined password model is used, the product cannot be operated, configured, accessed over a network, or used to retrieve data in any meaningful way without the user first setting a password. Test by powering on the product and attempting all functional pathways before password creation. ## Vulnerability disclosure compliance checklist under Clause 3 of Schedule 1 Clause 3 of Schedule 1 of the Smart Device Rules 2025 requires manufacturers to publish specific information about how security issues can be reported. This section of the Australia Cyber Security Act 2024 smart device compliance checklist verifies that the vulnerability disclosure process meets every requirement in the Rules. The reporting requirements apply to security issues in the hardware, pre-installed software, software required for the manufacturer's intended purposes, and any software used for or in connection with those purposes. This last category, Clause 3(1)(d), is broader than the password requirements in Clause 2 because it includes companion applications, cloud services, and any other software used in connection with the product's intended purpose. The published information must include at least one point of contact where a person can report security issues to the manufacturer. The manufacturer must also specify when a reporter will receive an acknowledgement of their report and when they will receive status updates until the security issue is resolved. This means you need a defined triage and response workflow, not just a contact email address. The word 'when' in Clause 3(2)(b) requires a stated timeframe, such as 'acknowledgement within 5 business days', not a vague commitment like 'as soon as possible'. Clause 3(3) of the Rules adds four accessibility requirements that are frequently missed during compliance reviews for this Australia Cyber Security Act 2024 smart device compliance checklist. The vulnerability disclosure information must be available without prior request, in English, free of charge, and without requiring the reporter to provide personal information to access the contact details. A vulnerability reporting page that sits behind a login wall or requires registration fails this section of the checklist. However, as the Explanatory Statement clarifies, once a person submits a report, the manufacturer may request reasonable contact information such as an email address for the purpose of providing the acknowledgement and status updates required under Clause 3(2)(b). Practical testing criteria for vulnerability disclosure: Open a browser in private or incognito mode (to simulate an anonymous visitor) and navigate to the manufacturer's vulnerability reporting page. Confirm the page loads without requiring login, registration, or submission of any personal information. Confirm the page is in English. Confirm no paywall or subscription is required. Confirm the page states at least one contact method (email address, web form, or phone number). Confirm the page states a specific timeframe for acknowledgement of receipt. Confirm the page states a specific timeframe or frequency for status updates until resolution. Then submit a test report and verify that the acknowledgement and status update process works within the published timeframes. - At least one point of contact for reporting security issues is published and accessible, as required by Clause 3(2)(a) of Schedule 1. Test by navigating to the published URL and confirming a contact method (email, web form, or phone number) is visible. - The published information states a specific timeframe for when reporters will receive an acknowledgement of their report, as required by Clause 3(2)(b)(i) of Schedule 1. Test by reading the published text and confirming a concrete period is stated (such as '5 business days'), not a vague commitment. - The published information states a specific timeframe or frequency for when reporters will receive status updates until the security issue is resolved, as required by Clause 3(2)(b)(ii) of Schedule 1. Test by confirming the published text includes an update interval or milestone schedule. - The vulnerability disclosure information is accessible, clear, and transparent, as required by Clause 3(3) of Schedule 1. Test by having a person unfamiliar with the product attempt to find and understand the reporting instructions without guidance. - The information is available without prior request from the person seeking it, as required by Clause 3(3)(a) of Schedule 1. Test by confirming the information is published on a web page that can be found through the manufacturer's website navigation or through a search engine query. - The information is published in English, as required by Clause 3(3)(b) of Schedule 1. Test by confirming all reporting instructions, timeframes, and contact details are displayed in English. - The information is available free of charge, as required by Clause 3(3)(c) of Schedule 1. Test by accessing the page without any payment, subscription, or premium membership. - The information can be accessed without providing personal information, as required by Clause 3(3)(d) of Schedule 1. Test by opening the page in a private browser session and confirming no login, registration, or personal data entry is required to view the contact details and reporting process. - An internal triage process exists that can receive, acknowledge, track, and resolve reported security issues within the published timeframes. Test by submitting a simulated security report and verifying the acknowledgement is received within the stated period. - The vulnerability disclosure process covers all four component categories listed in Clause 3(1): hardware, pre-installed software, software required for the manufacturer's intended purposes, and software used in connection with those purposes including companion applications and cloud services ## Defined support period compliance checklist under Clause 4 of Schedule 1 Clause 4 of Schedule 1 of the Smart Device Rules 2025 requires manufacturers to publish a defined support period for security updates. This is one of the most consequential items on the Australia Cyber Security Act 2024 smart device compliance checklist because the defined support period, once published, cannot be shortened under Clause 4(4). If the manufacturer extends the defined support period, Clause 4(5) requires the new period to be published as soon as is practicable. The defined support period must be expressed as a period of time with an end date, as required by Clause 4(3). The Explanatory Statement provides an example: 'no later than 30 June 2027'. A vague statement like 'updates provided for the life of the product' or 'updates until further notice' does not satisfy this requirement. The end date must be a calendar date that a consumer can understand without technical knowledge. Clause 4(1) lists four categories of components that require a published defined support period: hardware capable of receiving security updates; pre-installed software capable of receiving security updates; software that must be installed for the manufacturer's intended purposes and is capable of receiving security updates; and software developed by or on behalf of any manufacturer that is capable of receiving security updates and used for or in connection with the manufacturer's intended purposes. Each of these components may have a different support end date, and each must be published individually if they differ. Clause 4(2) defines a security update as a software update that protects or enhances the security of the product, including a software update that addresses a security issue which has been discovered by or reported to the manufacturer. The manufacturer must provide available security updates to the product while it is within its defined support period, as far as practicable and in line with good industry practice. The publication requirements for the defined support period are more demanding than most manufacturers expect when completing this Australia Cyber Security Act 2024 smart device compliance checklist. Clause 4(6) requires the information to be accessible, clear, and transparent. It must be in English. It must be free of charge. It must be available without prior request. It must be available without requiring personal information. And it must be understandable by a reader without prior technical knowledge. This last requirement, in Clause 4(6)(b)(v), is unique to the defined support period and does not appear in the vulnerability disclosure requirements. Practical testing criteria for the defined support period: Read the published support period statement. Confirm it includes a calendar end date. Confirm the end date is in the future at the time of first supply. Confirm the statement is in plain language a non-technical person can understand. For each of the four component categories in Clause 4(1), confirm whether the component is capable of receiving security updates. If it is, confirm a defined support period is published for that component. If the support end dates differ by component, confirm each is published separately. Check that the published period has not been shortened from any previously published version. - The defined support period is published for all hardware capable of receiving security updates, as required by Clause 4(1)(a) of Schedule 1. Test by identifying every hardware component that can receive firmware updates and confirming a support end date is published for each. - The defined support period is published for all pre-installed software capable of receiving security updates, as required by Clause 4(1)(b) of Schedule 1. Test by listing all pre-installed software modules and confirming a support end date is published for each that is updateable. - The defined support period is published for all required software capable of receiving security updates, as required by Clause 4(1)(c) of Schedule 1. Test by identifying any software the user must install for the manufacturer's intended purposes and confirming a support end date is published. - The defined support period is published for all manufacturer-developed software used for the product's intended purposes that is capable of receiving security updates, as required by Clause 4(1)(d) of Schedule 1. This includes companion mobile applications and cloud services developed by or on behalf of the manufacturer. - The defined support period is expressed with a fixed calendar end date, not an open-ended or vague commitment, as required by Clause 4(3) of Schedule 1. Test by reading the published text and confirming a specific date appears (such as 'no later than 30 June 2029'). - The manufacturer has confirmed the defined support period will not be shortened after publication, in compliance with Clause 4(4) of Schedule 1. If the period has been extended, confirm the new period was published as soon as practicable under Clause 4(5). - The published information is accessible, clear, transparent, in English, free of charge, and available without requiring personal information, as required by Clause 4(6)(a) and (b)(i) through (iv) of Schedule 1 - The published information is understandable by a reader without prior technical knowledge, as required by Clause 4(6)(b)(v) of Schedule 1. Test by having a non-technical person read the statement and confirm they understand when security updates will stop being provided. - If the product is sold on the manufacturer's website, the defined support period is prominently published with information intended to inform consumer purchasing decisions, as required by Clause 4(7)(a) of Schedule 1. Test by visiting every product listing, product comparison, and product purchase page and confirming the support period is visible. - If the product is sold on the manufacturer's website, the defined support period is given equal prominence with the main product characteristics wherever those characteristics appear, as required by Clause 4(7)(b) of Schedule 1. Test by comparing the font size, placement, and visibility of the support period against the product's features, benefits, and specifications on each page. ## Security update delivery compliance checklist for Australia Cyber Security Act 2024 smart devices While the Smart Device Rules 2025 focus on publishing the defined support period rather than prescribing a specific update mechanism, this section of the Australia Cyber Security Act 2024 smart device compliance checklist addresses the operational capability to deliver security updates throughout the published support period. Clause 4(2) of Schedule 1 defines a security update as a software update that protects or enhances the security of the product, including updates that address security issues discovered by or reported to the manufacturer. Once you publish a defined support period, you are committing to provide security updates for the entire duration of that period. The Explanatory Statement confirms that the manufacturer must provide an available security update to a product, while the product is within its defined support period, as far as practicable and in line with good industry practice. A product that cannot reliably receive updates, or that has an update path vulnerable to tampering, undermines the entire compliance framework of this Australia Cyber Security Act 2024 smart device compliance checklist. Test the update path end to end before the product is supplied in Australia. Confirm that updates can be delivered to the hardware, pre-installed software, and any required software components. Verify update integrity checks, rollback capabilities, and version traceability. These operational tests are not explicitly mandated by the Rules, but they provide the evidence that your defined support period commitment is credible and that you can meet the good industry practice standard referenced throughout Schedule 1. Practical testing criteria for security update delivery: Push a test update to at least five units from different production batches. Verify the update installs successfully on each unit. Verify the update's digital signature or checksum is validated before installation. Attempt to push a tampered update file and confirm the device rejects it. Simulate an interrupted update (such as a power loss during installation) and confirm the device recovers to a functional state. Record the firmware version before and after each test to confirm version traceability. - Security updates can be delivered to every hardware component covered by the defined support period. Test by pushing a firmware update to the hardware and confirming successful installation on multiple units. - Security updates can be delivered to every pre-installed software component covered by the defined support period. Test by pushing a software update and confirming successful installation on multiple units. - Security updates can be delivered to every required software component covered by the defined support period, including companion applications and cloud service components - The update delivery mechanism includes integrity verification to prevent tampering during transit. Test by modifying a legitimate update file and confirming the device rejects the tampered file. - The update process supports version traceability so each installed update can be identified and audited. Test by querying the device firmware version after an update and confirming it matches the intended version. - The update process has been tested for recoverability in case an update fails or corrupts the device. Test by interrupting an update in progress (simulating power loss or network disconnection) and confirming the device returns to a working state. - A process exists to identify, prioritize, develop, test, and deploy security updates within the published support period. Document the process with roles, responsibilities, and target timeframes for each stage. - The update delivery infrastructure (servers, CDN, signing keys, and certificates) is confirmed to remain operational and maintained for the full duration of the published defined support period ## Website and public information compliance checklist for Australia Cyber Security Act 2024 smart devices The Smart Device Rules 2025 treat public-facing information as part of the compliance obligation, not as a marketing activity. Both Clause 3 (vulnerability disclosure) and Clause 4 (defined support period) require information to be published in a way that meets specific accessibility standards. This section of the Australia Cyber Security Act 2024 smart device compliance checklist consolidates all the public information requirements into one verification pass. The key accessibility requirements appear in both Clause 3(3) and Clause 4(6) of Schedule 1: information must be accessible, clear, and transparent. It must be in English. It must be free of charge. It must be available without prior request. It must be available without requiring the person to provide personal information. For defined support period information, Clause 4(6)(b)(v) adds that the information must be understandable by a reader without prior technical knowledge. If the manufacturer sells the product on its own website, Clause 4(7) adds further requirements. The defined support period must appear alongside the main product characteristics and be given equal prominence. The Explanatory Statement explains that the defined support period must be published in any location on the website where either of two criteria are met: information intended to inform consumer acquisition decisions is published, or the main characteristics of the product are published. This may require the manufacturer to publish the defined support period in multiple locations on the website. The Explanatory Statement provides examples: product information pages, product purchase pages, and product comparison pages are likely to require the support period. Generic press releases, support articles, and accessory pages are not likely to require it. Practical testing criteria for public information: Visit the manufacturer's website in a private browser session. Locate the vulnerability disclosure page and the defined support period page. Confirm both are accessible without login, registration, or payment. Confirm both are in English. Confirm the defined support period is understandable by a non-technical reader. Then visit every product listing, product comparison, and product purchase page on the website and confirm the defined support period is displayed with equal prominence to the main product characteristics. - The vulnerability disclosure contact and process information is published on a public web page accessible without authentication - The defined support period with its calendar end date is published on a public web page accessible without authentication - All published compliance information is in English and free of charge, meeting the requirements of Clause 3(3)(b), Clause 3(3)(c), Clause 4(6)(b)(ii), and Clause 4(6)(b)(iii) of Schedule 1 - No login, registration, or personal information submission is required to view the compliance information, meeting the requirements of Clause 3(3)(d) and Clause 4(6)(b)(iv) of Schedule 1 - The language used in defined support period information is understandable by a reader without technical knowledge, meeting the additional requirement of Clause 4(6)(b)(v) of Schedule 1 - If the product is sold on the manufacturer's website, the defined support period appears on every page where information intended to inform consumer purchasing decisions is published, as required by Clause 4(7)(a) of Schedule 1 - If the product is sold on the manufacturer's website, the defined support period is given equal prominence with the main product characteristics on every page where those characteristics appear, as required by Clause 4(7)(b) of Schedule 1. Check product information pages, product purchase pages, and product comparison pages. - The defined support period is not published only in the statement of compliance or only in a regulatory section of the website if product characteristics and purchasing information appear elsewhere, as emphasized in the Explanatory Statement - Packaging and point of sale materials, where applicable, reference the published compliance information or include equivalent details ## Statement of compliance preparation checklist under Section 9 of the Smart Device Rules 2025 Section 9 of the Smart Device Rules 2025 specifies the mandatory contents for the statement of compliance. Under Section 16 of the Cyber Security Act 2024, manufacturers must provide a statement of compliance for the supply of in-scope products in Australia, and suppliers must supply the product accompanied by a statement of compliance that meets the requirements in the Rules. The statement must be prepared by, or on behalf of, the manufacturer. Do not issue the statement as a paperwork exercise at the end of the process. The statement is the final output of the Australia Cyber Security Act 2024 smart device compliance checklist and should only be completed when every preceding section has been passed. Section 9(3) of the Rules lists seven categories of required information. The statement must include: the product type and batch identifier; the name and address of the manufacturer, an authorised representative, and any other authorised representatives in Australia; a declaration that the statement was prepared by or on behalf of the manufacturer; a declaration that the product was manufactured in compliance with the security standard and that the manufacturer has complied with any other obligations; the defined support period at the date the statement is issued; the signature, name, and function of the signatory; and the place and date of issue. The statement of compliance is not required to be physically included with the product at the point of sale. As the Explanatory Statement confirms, the statement is primarily for the regulator to verify that the responsible entity has met its obligations under the Act and Rules. However, manufacturers and suppliers may choose to provide or publish the statement with their product. If you already comply with the UK PSTI statement of compliance requirements, you can use the same information for Australia, provided all the requirements in Section 9 of the Smart Device Rules 2025 are met. Practical testing criteria for statement of compliance: Prepare a draft statement and compare every field against the seven categories in Section 9(3). Verify the product type and batch identifier match the manufacturing records. Verify all names and addresses are current. Verify the defined support period in the statement matches the period published on the website. Have the signatory confirm they have the authority to sign on behalf of the manufacturer and document the approval chain. Record the place and date of issue. Then file the signed statement in the evidence pack before first supply in Australia. - The statement includes the product type and batch identifier, as required by Section 9(3)(a) of the Smart Device Rules. Test by cross-referencing the product type and batch identifier against manufacturing records to confirm accuracy. - The statement includes the name and address of the manufacturer, as required by Section 9(3)(b)(i) of the Smart Device Rules. Test by confirming the manufacturer's name and address match the current business registration. - The statement includes the name and address of an authorised representative of the manufacturer, as required by Section 9(3)(b)(ii) of the Smart Device Rules - The statement includes the name and address of each (if any) of the manufacturer's other authorised representatives in Australia, as required by Section 9(3)(b)(iii) of the Smart Device Rules - The statement includes a declaration that it has been prepared by, or on behalf of, the manufacturer, as required by Section 9(3)(c) of the Smart Device Rules - The statement includes a declaration that, in the opinion of the manufacturer, the product has been manufactured in compliance with the security standard and that the manufacturer has complied with any other obligations relating to the product in the security standard, as required by Section 9(3)(d) of the Smart Device Rules - The statement includes the defined support period for the product at the date the statement is issued, as required by Section 9(3)(e) of the Smart Device Rules. Test by confirming the period in the statement matches the period published on the website. - The statement includes the signature, name, and function of the signatory, as required by Section 9(3)(f) of the Smart Device Rules. Test by confirming the signatory has documented authority to sign on behalf of the manufacturer. - The statement includes the place and date of issue, as required by Section 9(3)(g) of the Smart Device Rules - The signatory has the authority to sign on behalf of the manufacturer, and the internal approval trail is documented and retained - If the same statement of compliance is used for both Australia and the UK PSTI regime, all seven categories in Section 9(3) of the Smart Device Rules have been verified independently for the Australian requirements ## Recordkeeping and evidence retention compliance checklist under Section 10 Section 10 of the Smart Device Rules 2025 specifies that statements of compliance must be retained for five years. This five year period applies to both manufacturers and suppliers. The period was reduced from the originally proposed ten years following stakeholder feedback during the public consultation, as noted in the Explanatory Statement. The Explanatory Statement states this reduction is consistent with the average lifespan of a relevant connectable product and reduces administrative burden on industry. A compliance checklist is only as strong as the evidence behind it. Every item on this Australia Cyber Security Act 2024 smart device compliance checklist should be backed by documented evidence that can be produced if the Secretary issues a compliance notice under Section 17, a stop notice under Section 18, or a recall notice under Section 19 of the Cyber Security Act 2024. Build your evidence pack as you work through the checklist, not after the product has been released. If the Secretary issues a compliance notice under Section 17 of the Act, the entity has a minimum of 10 days to make representations before the notice takes effect, as required by Section 17(3)(b). Having a complete evidence pack ready before this situation arises is the most effective way to respond quickly and demonstrate compliance. Under Section 23 of the Act, the Secretary may also request the manufacturer or supplier to provide the product, the statement of compliance, or both for the purposes of an independent audit to assess compliance. Practical testing criteria for recordkeeping: Confirm that a document management system or repository is in place and that it supports retention for at least five years. Confirm that every category of evidence listed below has been uploaded or filed before first supply in Australia. Assign a retention start date equal to the date of first supply. Set a calendar reminder for the five year retention expiry. Confirm that records can be retrieved within 48 hours if the Secretary requests them. - A scope decision document exists that explains why this product is (or is not) within the covered class under Section 8 of the Smart Device Rules. The document includes references to the product's communication protocols, intended use, and consumer classification. - Password design documentation includes the generation method, whether the unique per product or user-defined model is used, the cryptographic review findings from a qualified cryptographer, and test results from batch sampling - Vulnerability disclosure process documentation includes the published contact method, published acknowledgement timeline, published update frequency, internal resolution tracking workflow, and internal triage procedures - Defined support period publication evidence includes timestamped screenshots or web archive captures of every page where the support period is displayed, taken at the time of first supply in Australia - Security update capability test results demonstrate that updates can be delivered, verified with integrity checks, and installed on every covered component across multiple production batches - The signed statement of compliance is stored with the evidence pack in a system that supports the five year retention requirement under Section 10 of the Smart Device Rules - Website publication evidence is captured at the time of first supply and updated whenever the published information changes. Each capture includes the page URL, date, and a full page screenshot or web archive file. - All evidence is organized by product model, batch identifier, date of first supply in Australia, and the date the statement of compliance was issued - A retention policy document is in place that assigns responsibility for maintaining the evidence pack, sets the five year retention period, and describes the retrieval process if the Secretary issues a compliance notice or requests an audit under Section 23 of the Cyber Security Act 2024 - If the product is also sold in the UK under PSTI, the Australian evidence pack is maintained separately or contains clear mappings to Australian requirements to avoid confusion during a regulatory review ## Supply chain and distribution compliance checklist for Australia Cyber Security Act 2024 smart devices The Cyber Security Act 2024 places obligations on both manufacturers and suppliers. Under Section 15, manufacturers must manufacture in-scope products in compliance with the security standard if they are aware, or could reasonably be expected to be aware, that the product will be acquired in Australia in the specified circumstances. Under Section 16, suppliers must not supply non-compliant products and must ensure every product is accompanied by a compliant statement of compliance. The term 'supply' has the same meaning as in the Australian Consumer Law, which means obligations extend across the entire distribution chain in Australia. This section of the Australia Cyber Security Act 2024 smart device compliance checklist ensures that everyone in the supply chain understands their role. Distributors, importers, and retailers all qualify as suppliers under the Act if they supply the product in Australia. Each supplier must have access to the statement of compliance and must be able to confirm that the product they are supplying meets the security standard. Each supplier must also retain a copy of the statement of compliance for five years under Section 16(4) of the Act, as specified in Section 10 of the Rules. If a supplier becomes aware that a product is non-compliant, the supplier must stop supplying that product immediately. Build compliance communication into your distribution agreements. Every entity that supplies the product in Australia should know where to find the statement of compliance, how to verify it, and what to do if they receive a compliance notice, stop notice, or recall notice from the Secretary. Under Section 20 of the Act, the Minister may publicly notify failure to comply with a recall notice, including the identity of the entity, product details, and recommended consumer actions. Under Section 11 of the Rules, the Minister may also publish details of the recall notice and recommend actions such as destroying the product or taking extra precautions when using the product. Practical testing criteria for supply chain readiness: Contact each entity in the Australian distribution chain and confirm they have received a copy of the statement of compliance. Confirm each entity understands their obligation not to supply the product if they become aware of non-compliance. Confirm each entity has a process to escalate compliance concerns to the manufacturer. Confirm distribution agreements include clauses addressing obligations under the Cyber Security Act 2024 and Smart Device Rules 2025. - Every supplier in the Australian distribution chain has received and retained a copy of the current statement of compliance for the product, as required by Section 16(3) and 16(4) of the Cyber Security Act 2024 - Distribution agreements include compliance obligations under the Cyber Security Act 2024 and Smart Device Rules 2025, specifying each party's responsibilities for the statement of compliance, recordkeeping, and enforcement notice response - Suppliers understand that they must not supply the product in Australia if they are aware, or could reasonably be expected to be aware, that the product does not comply with the security standard, as required by Section 15(3) of the Act - A process exists to notify all Australian suppliers immediately if a compliance issue is discovered after first supply, including a documented escalation path and contact list - Contact details for the manufacturer's compliance team are available to every entity in the Australian supply chain, enabling rapid communication if the Secretary issues a notice - Procedures are documented for responding to compliance notices (Section 17), stop notices (Section 18), and recall notices (Section 19) issued by the Secretary, including the minimum 10 day representation period and the internal review rights under Section 22 of the Act - The manufacturer has identified its authorised representative and any other authorised representatives in Australia, and their contact details are included in the statement of compliance as required by Section 9(3)(b) of the Smart Device Rules - Each supplier in the Australian distribution chain is retaining their copy of the statement of compliance for the full five year period specified in Section 10 of the Smart Device Rules ## Primary sources - [Cyber Security (Security Standards for Smart Devices) Rules 2025 official text (F2025L00276)](https://www.legislation.gov.au/F2025L00276/asmade/text?ref=sorena.io) - Primary source for all three mandatory security standards (Schedule 1), statement of compliance requirements (Section 9), retention period (Section 10), product scope and exclusions (Section 8), and all checklist items on this page. Part 2 and Schedule 1 commenced 4 March 2026. - Quote: "Part 1 of Schedule 1 prescribes the security standard for the class of relevant connectable products that is all relevant connectable products that are intended by the manufacturer to be used, or are of a kind likely to be used, for personal, domestic or household use or consumption." - [Cyber Security Act 2024 (Australia) official text (No. 98, 2024)](https://www.legislation.gov.au/C2024A00098/latest/text?ref=sorena.io) - Primary source for manufacturer obligations (Section 15), supplier obligations (Section 16), enforcement notices (Sections 17-20), internal review rights (Section 22), independent audit powers (Section 23), and the definition of relevant connectable product (Section 13). - Quote: "An entity must not supply a product in Australia that was not manufactured in compliance with the requirements of the security standard for a class of relevant connectable product that will be acquired in Australia in specified circumstances." - [Explanatory Statement for Cyber Security (Security Standards for Smart Devices) Rules 2025](https://www.legislation.gov.au/F2025L00276/asmade/text?ref=sorena.io) - Provides policy rationale for product scope, exclusion categories, password requirements, vulnerability disclosure, defined support period website placement requirements, alignment with UK PSTI regulations, and the reduction of the retention period from ten years to five years following stakeholder consultation. - Quote: "Products already compliant with the UK PSTI requirements can provide the same statement of compliance for the Australian market, as long as all the requirements set out in this section are met." ## Related Topic Guides - [Australia Cyber Security Act 2024 Applicability Test | Who Must Comply](/artifacts/apac/australia-cyber-security-act/applicability-test.md): Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations. - [Australia Cyber Security Act 2024 Compliance Checklist](/artifacts/apac/australia-cyber-security-act/checklist.md): Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting. - [Australia Cyber Security Act 2024 Compliance Guide | Implementation Playbook](/artifacts/apac/australia-cyber-security-act/compliance.md): A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements. - [Australia Cyber Security Act 2024 Compliance Templates | Statement of Compliance, Ransomware Report, Evidence Pack, Vulnerability Disclosure, Support Period](/artifacts/apac/australia-cyber-security-act/templates.md): Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field. - [Australia Cyber Security Act 2024 Deadlines and Compliance Calendar | Commencement Dates](/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar.md): Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent. - [Australia Cyber Security Act 2024 FAQ | Frequently Asked Questions](/artifacts/apac/australia-cyber-security-act/faq.md): Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024. - [Australia Cyber Security Act 2024 Requirements | Smart Device and Ransomware Reporting Obligations](/artifacts/apac/australia-cyber-security-act/requirements.md): Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure. - [Australia Cyber Security Act 2024 Timeline and Commencement Dates | Full Schedule](/artifacts/apac/australia-cyber-security-act/timeline-and-commencement.md): Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024. - [Australia Cyber Security Act 2024 vs EU Cyber Resilience Act | Full CRA Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act.md): Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements. - [Australia Cyber Security Act 2024 vs UK PSTI Act | Product Security Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act.md): Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements. - [Penalties and fines | Australia Cyber Security Act 2024 | 60 Penalty Units, Smart Device Enforcement, Ransomware Reporting](/artifacts/apac/australia-cyber-security-act/penalties-and-fines.md): Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals. - [Ransomware Payment Reporting in 72 Hours | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours.md): Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. - [Scope and Definitions | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/scope-and-definitions.md): Complete guide to the Australia Cyber Security Act 2024 scope and definitions. - [Smart device security standards | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/smart-device-security-standards.md): Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2. - [Statement of Compliance and Recordkeeping | Australia Cyber Security Act 2024 | Section 9, Section 10, 5 Year Retention](/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping.md): Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist --- --- title: "Smart device security standards" canonical_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/smart-device-security-standards" source_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/smart-device-security-standards" author: "Sorena AI" description: "Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "Australia Cyber Security Act 2024 smart device security standards" - "Schedule 1 security standards for consumer grade relevant connectable products" - "password requirements connectable products Australia" - "vulnerability reporting smart devices Australia" - "defined support period security updates Australia" - "ETSI EN 303 645 alignment" - "statement of compliance smart devices" - "Cyber Security Smart Devices Rules 2025" - "smart device password unique per product" - "security issue reporting manufacturer obligation" - "support period end date publication" - "good industry practice cryptographer" - "recall notice smart devices Australia" - "compliance notice stop notice" - "password requirements connectable products" - "defined support period security updates" - "ETSI EN 303 645 alignment Australia" - "Schedule 1 Smart Devices Rules 2025" - "consumer grade relevant connectable products" - "APAC compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Smart device security standards Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2. *Artifact Guide* *APAC* ## Australia Cyber Security Act 2024 Smart device security standards Detailed technical guide to all three mandatory security standards under Schedule 1 of the Cyber Security (Security Standards for Smart Devices) Rules 2025: password security (Clause 2), vulnerability reporting (Clause 3), and defined support periods (Clause 4). These Australia Cyber Security Act 2024 smart device security standards took effect on 4 March 2026 and apply to all consumer grade relevant connectable products acquired by a consumer in Australia. The Australia Cyber Security Act 2024 smart device security standards are defined in Schedule 1, Part 1 of the Cyber Security (Security Standards for Smart Devices) Rules 2025. They target a small set of controls that are visible, testable, and critical for consumer risk reduction. The three mandatory standards cover password security (Clause 2), security issue reporting (Clause 3), and defined support periods for security updates (Clause 4). These three controls were selected because the Australian Cyber Security Centre identified them as the highest priority technical controls from the ETSI EN 303 645 standard. UK impact analysis modelled that a standard consisting of these three ETSI EN 303 645 principles could reduce the probability of attacks on smart devices by between 20 and 70 per cent. The Australia Cyber Security Act 2024 smart device security standards apply from 4 March 2026 to all consumer grade relevant connectable products that will be acquired by a consumer in Australia, with the exception of desktop computers, laptops, tablets, smartphones, therapeutic goods, road vehicles, and road vehicle components. The 12 month transition period from registration to enforcement matches the approach taken under the UK Product Security and Telecommunications Infrastructure Act 2022. Manufacturers with products already in the UK market should already be meeting equivalent requirements. ## Products in scope and products excluded from the Australia Cyber Security Act 2024 smart device security standards The Australia Cyber Security Act 2024 smart device security standards apply to the class of relevant connectable products defined in Section 8 of the Rules. A relevant connectable product is any product that can connect directly or indirectly to the internet. The specified class is all relevant connectable products that are intended by the manufacturer to be used, or are of a kind likely to be used, for personal, domestic, or household use or consumption. The specified circumstance is that the product will be acquired in Australia by a consumer as defined under section 3 of the Australian Consumer Law. Consumer energy resources including rooftop solar inverters and home batteries were added to the scope through a supplementary impact analysis prepared by the Department of Climate Change, Energy, the Environment and Water. This addition recognises that an estimated 35 per cent of the consumer energy resource fleet will be internet connected by 2027 and that these devices face the same market failure that drives insecure consumer smart devices generally. Section 8(1)(b) of the Rules excludes six categories from the scope of the Australia Cyber Security Act 2024 smart device security standards. Desktop computers and laptops are exempt. Tablet computers are exempt. Smartphones are exempt. Therapeutic goods within the meaning of the Therapeutic Goods Act 1989 are excluded because they are regulated under a separate framework administered by the Therapeutic Goods Administration. Road vehicles and road vehicle components within the meaning of the Road Vehicle Standards Act 2018 are also excluded. The Explanatory Statement confirms that computers, tablets and smartphones were excluded because of the difficulty manufacturers would face in complying due to the complex nature of supply chains for product components. These same product categories were excluded from the UK PSTI framework. The Explanatory Statement provides specific examples to help manufacturers assess whether their products fall within scope of the Australia Cyber Security Act 2024 smart device security standards. Smart meters are not considered within scope because their primary purpose is supply, installation, and use by electricity retailers, not acquisition by a consumer. Contactless payment devices are in scope because they meet at least one of the business consumer guarantee conditions under the Australian Consumer Law. Smart TVs, smart watches, home assistants, baby monitors, smart speakers, connected cameras, smart doorbells, smart lighting, smart thermostats, and similar consumer devices are all in scope. - Consumer grade relevant connectable products intended for personal, domestic or household use are in scope of the Australia Cyber Security Act 2024 smart device security standards. - Products must be acquired in Australia by a consumer as defined under section 3 of the Australian Consumer Law. - Smart TVs, smart watches, home assistants, baby monitors, connected cameras, smart speakers, smart doorbells, smart lighting, smart thermostats, and consumer energy resources are all covered. - Consumer energy resources such as solar inverters and home batteries were explicitly added through a supplementary impact analysis. - Desktop computers, laptops, tablets and smartphones are exempt from the Australia Cyber Security Act 2024 smart device security standards due to complex supply chain considerations. - Therapeutic goods, road vehicles and road vehicle components are regulated separately and are exempt. - Smart meters are not in scope because they are not ordinarily acquired by consumers. - Contactless payment devices are in scope because they meet the consumer acquisition test under the Australian Consumer Law. - Each product's companion application and associated cloud services are within scope to the extent they fall within the definitions in Schedule 1. ## Standard 1: Password security requirements under Clause 2 of Schedule 1 Clause 2 of Schedule 1 sets the password security requirements under the Australia Cyber Security Act 2024 smart device security standards. This clause ensures that every consumer grade relevant connectable product either uses a password that is unique per product or requires the user to define the password. The standard prohibits shared default passwords across a product class or product type. Clause 2 applies to passwords used with the product in three contexts defined by Subclause 2(1). First, hardware of the product when the product is not in the factory default state. Second, software that is pre-installed on the product at the point of supply to a consumer when the product is not in the factory default state. Third, software that is not pre-installed but must be installed on the product for all of the manufacturer's intended purposes of the product that use hardware, pre-installed software, or installable software. This third category covers companion applications and software updates installed after sale that require additional password controls. Under Subclause 2(2), every password that falls within scope must satisfy one of two options under the Australia Cyber Security Act 2024 smart device security standards. Option A requires the password to be unique per product, which means unique for each individual product of a given product class or type. Option B requires the password to be defined by the user. The choice between these two options belongs to the manufacturer. If the manufacturer chooses Option A, the password is further subject to the four prohibitions in Subclause 2(3). Subclause 2(3) sets four specific prohibitions for passwords that are unique per product under the Australia Cyber Security Act 2024 smart device security standards. First, the password must not be based on incremental counters. The Rules define an incremental counter as a method of password generation in which multiple passwords are the same except for a small number of characters that change per password to make them unique, such as 'password1' and 'password2'. Second, the password must not be based on or derived from publicly available information, which includes any data that a third party could look up or discover without privileged access, including marketing materials, product listings, or publicly accessible databases. Third, the password must not be based on or derived from unique product identifiers such as serial numbers, MAC addresses, or other hardware identifiers, unless the derivation uses an encryption method or keyed hashing algorithm that is accepted as part of good industry practice. Fourth, the password must not be otherwise guessable in a manner unacceptable as part of good industry practice. The term 'good industry practice' is defined in Clause 1 of Schedule 1 as the exercise of that degree of skill, diligence, prudence and foresight which would reasonably and ordinarily be expected from a skilled and experienced cryptographer engaged in the same type of activity. This definition sets a professional standard, not a general consumer standard. It means that password generation must be assessed against the expectations of a qualified cryptographer, not against the knowledge of an average product designer. The Explanatory Statement confirms that the intention of Subclause 2(3) is to ensure that manufacturers employ all parts of good industry practice to ensure default passwords are not unacceptably guessable by any party. The definition of 'password' in Schedule 1 Clause 1 explicitly excludes three categories from the scope of the Australia Cyber Security Act 2024 smart device security standards. Cryptographic keys, defined as data used to encrypt and decrypt data, are excluded. Personal identification numbers used for pairing in communication protocols that do not form part of the internet protocol suite are excluded. Application programming interface keys, defined as strings of characters used to identify and authenticate a particular user, product, or application for API access, are excluded. This means that Bluetooth Low Energy pairing PINs and Zigbee network keys are not subject to the password requirements, but Wi-Fi passwords, web interface login credentials, and mobile application login passwords are in scope. - All passwords must be unique per product or defined by the user of the product. Shared default passwords across a product class are prohibited under the Australia Cyber Security Act 2024 smart device security standards. - Passwords must not use incremental counter methods such as 'device001', 'device002', or 'password1', 'password2' to generate per-product passwords. - Passwords must not derive from publicly available information including product documentation, marketing materials, or any information accessible without privileged access. - Passwords must not derive from serial numbers, MAC addresses, or other unique product identifiers unless the derivation uses an encryption method or keyed hashing algorithm that meets good industry practice as judged by a skilled and experienced cryptographer. - Passwords must not be otherwise guessable in a manner unacceptable as part of good industry practice, including short passwords, dictionary words, or predictable patterns. - Verify that the password model remains compliant after factory reset by confirming the product returns to a state that does not expose a weak or shared credential. - Test companion application flows, onboarding sequences, and firmware update paths to confirm that no default password is silently reintroduced at any lifecycle stage. - Document the password generation method, the entropy source, and the hashing or encryption algorithm used so that compliance with the Australia Cyber Security Act 2024 smart device security standards can be demonstrated through evidence rather than assertion. ## ETSI EN 303 645 alignment and international equivalence The Explanatory Statement to the Rules confirms that the security standards in Schedule 1 closely follow the Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023 (UK), which themselves implement the first three provisions of ETSI EN 303 645. These three provisions are: no universal default passwords (Provision 5.1), implement a means to manage reports of security vulnerabilities (Provision 5.2), and keep software updated (Provision 5.3). The Australia Cyber Security Act 2024 smart device security standards therefore represent a deliberate policy choice to focus on the three most impactful controls rather than the full 13 provisions of ETSI EN 303 645. The Australian Government's Impact Analysis found that the UK modelled the probability of attacks on smart devices could be reduced by between 20 and 70 per cent through a standard consisting of these first three principles. The Australian Cyber Security Centre confirmed that these three principles are the highest priority technical controls. The IoT Security Foundation found that 78.4 per cent of smart device manufacturers do not have a readily detectable vulnerability disclosure policy, demonstrating the scale of the gap that these standards are designed to close. For manufacturers already compliant with the UK PSTI Act 2022, compliance with the Australia Cyber Security Act 2024 smart device security standards will require minimal additional effort. The Explanatory Statement confirms that responsible entities operating across other jurisdictions with similar compliance frameworks can provide the same statement of compliance for the Australian market, as long as all the requirements set out in Section 9 of the Rules are met. Products carrying a Singapore Cybersecurity Labelling Scheme rating at Level 1 or above will have addressed the same password and vulnerability reporting requirements and should map their existing evidence to the Australian clause structure. Manufacturers should retain records that show which ETSI EN 303 645 provisions their product meets, so that future extensions of the Australian standard can be addressed without starting from scratch. During Strategy consultation, industry groups and manufacturers tended to support initially mandating only the first three ETSI principles as a way of balancing security with cost to industry. Consumer advocates and some cyber security companies advocated for adoption of the entire 13-provision standard. The Australian Government may revisit the scope in a post-implementation review no later than two years after the enforcement date. - ETSI EN 303 645 Provision 5.1-1 requires passwords to be unique per device. The Australia Cyber Security Act 2024 smart device security standards use the term 'unique per product', defined as unique for each individual product of a given product class or type. - ETSI EN 303 645 Provision 5.1-2 prohibits passwords based on incremental counters, derived from publicly available information, derived from device identifiers unless using a sufficiently secure encryption scheme, or otherwise easily guessable. Schedule 1 Subclause 2(3) mirrors these four prohibitions exactly. - ETSI EN 303 645 Provision 5.2 requires a means to manage reports of security vulnerabilities. Clause 3 of Schedule 1 implements this requirement with specific accessibility and transparency obligations. - ETSI EN 303 645 Provision 5.3 requires keeping software updated. Clause 4 of Schedule 1 implements this by requiring publication of a defined support period with a fixed end date. - Products already certified under the UK PSTI Act or carrying a Singapore CLS rating at Level 1 or above should map existing evidence to the Australian clause structure. - A post-implementation review of the Australia Cyber Security Act 2024 smart device security standards is expected no later than two years after enforcement, which may expand the scope to additional ETSI EN 303 645 provisions. ## Standard 2: Security issue reporting requirements under Clause 3 of Schedule 1 Clause 3 of Schedule 1 sets the security issue reporting requirements under the Australia Cyber Security Act 2024 smart device security standards. This clause obligates the manufacturer to publish information on how a person can report security issues in relation to the product. The scope of Subclause 3(1) covers four categories of product components. First, the hardware of the product. Second, software that is pre-installed on the product at the point of supply to a consumer. Third, software that must be installed on the product for all of the manufacturer's intended purposes of the product that use hardware, pre-installed software, or installable software. Fourth, software used for or in connection with any of the manufacturer's intended purposes of the product. This fourth category is broader than the password scope in Clause 2 and captures companion applications, cloud services, and backend systems that the manufacturer provides for the product's operation. Under Subclause 3(2), the manufacturer must publish two categories of information under the Australia Cyber Security Act 2024 smart device security standards. Subclause 3(2)(a) requires the manufacturer to publish at least one point of contact that allows a person to report security issues to the manufacturer. Subclause 3(2)(b) requires the manufacturer to publish information about when a person who makes a report will receive an acknowledgement of receipt of the report and when they will receive status updates until the resolution of the reported security issues. This means the manufacturer cannot simply publish an email address. The manufacturer must also explain the expected timelines for acknowledgement and for ongoing updates. This creates a feedback loop between the reporter and the manufacturer that persists until the issue is resolved. Subclause 3(3) imposes four accessibility requirements on the published information under the Australia Cyber Security Act 2024 smart device security standards. The information must be accessible, clear, and transparent. It must be made available without prior request, meaning it cannot be hidden behind a login, a support ticket system, or require the person to contact the manufacturer before seeing the reporting path. It must be published in English. It must be provided free of charge. And it must be accessible without requesting the provision of personal information about the person seeking the reporting information. This last point means the manufacturer cannot require a name, email address, phone number, or account registration merely to view the reporting instructions. The Explanatory Statement clarifies an important distinction under the Australia Cyber Security Act 2024 smart device security standards. While the manufacturer cannot require personal information for a person to access the published reporting information, the manufacturer may request reasonable contact information such as an email address from the person who actually submits a report. This request is permitted for the purpose of providing the required acknowledgement and status updates under Subclause 3(2)(b). Any collection, use, or disclosure of personal information by the manufacturer in this context remains subject to the Privacy Act 1988. This is one of the most visible obligations under the Australia Cyber Security Act 2024 smart device security standards because researchers, consumers, and regulators can directly verify whether the required information is published, whether it is accessible without login, and whether it states the expected timelines for acknowledgement and status updates. The IoT Security Foundation found that 78.4 per cent of smart device manufacturers do not have a readily detectable vulnerability disclosure policy, which demonstrates that this requirement addresses a widespread gap in the current market. - Publish at least one contact method such as an email address, a web form URL, or a security.txt file that allows any person to report security issues to the manufacturer. - Publish in English, in a location accessible without login, account creation, or any request for personal information from the person viewing the reporting information. - State the expected time within which the manufacturer will acknowledge receipt of a security issue report, for example 'within 5 business days'. - State the expected frequency or conditions under which the manufacturer will provide status updates to the reporter until the issue is resolved. - Ensure the published process accurately reflects the actual triage workflow used by the security or engineering team, so that the published timelines are realistic and achievable. - Do not require any form of non-disclosure agreement or legal waiver as a precondition for viewing the reporting information or for submitting a report. - Consider publishing a security.txt file at the /.well-known/ path on the manufacturer's website, following RFC 9116, to make the contact point discoverable by automated scanners and security researchers. - Keep evidence of the published reporting information, including periodic web page captures with timestamps, to demonstrate ongoing compliance with the Australia Cyber Security Act 2024 smart device security standards. ## Standard 3: Defined support period and security update requirements under Clause 4 of Schedule 1 Clause 4 of Schedule 1 sets the defined support period and security update requirements under the Australia Cyber Security Act 2024 smart device security standards. This clause obligates the manufacturer to publish the period during which security updates will be provided for the product. Subclause 4(1) defines the scope of coverage across four categories. First, hardware of the product that is capable of receiving security updates. Second, software that is pre-installed on the product at the point of supply and is capable of receiving security updates. Third, software that must be installed for the manufacturer's intended purposes and is capable of receiving security updates. Fourth, software developed by or on behalf of any manufacturer that is capable of receiving security updates and is used for or in connection with the manufacturer's intended purposes of the product. Subclause 4(2) defines 'security update' under the Australia Cyber Security Act 2024 smart device security standards as a software update that protects or enhances the security of the product, including a software update that addresses a security issue which has been discovered by or reported to the manufacturer. This definition is broad. It covers patches for known vulnerabilities, proactive security improvements, and updates that address issues found through the manufacturer's own testing or through the reporting mechanism required by Clause 3. Subclause 4(3) defines 'defined support period' as the period, expressed as a period of time with an end date, for which the security updates will be provided by or on behalf of the manufacturer of the product. The Explanatory Statement emphasises that the defined support period must include a fixed end date, not an open-ended promise. The specific example given is 'no later than 30 June 2027'. A statement such as 'supported for at least two years' would not satisfy this requirement under the Australia Cyber Security Act 2024 smart device security standards because it does not include an end date. A statement such as 'security updates provided until end of life' would also fail because 'end of life' is not a date. Subclause 4(4) provides that the manufacturer must not shorten the defined support period after it is published under the Australia Cyber Security Act 2024 smart device security standards. Once a date is committed, it is binding. Under Subclause 4(5), if the manufacturer extends the defined support period, the new period must be published by or on behalf of the manufacturer as soon as is practicable. The Explanatory Statement clarifies that during the defined support period, the manufacturer must provide available security updates to the product as far as practicable and in line with good industry practice. This means the obligation is not merely to publish a date but also to actually deliver patches during the committed period. Subclause 4(6) imposes publication requirements that are more extensive than those for security issue reporting under the Australia Cyber Security Act 2024 smart device security standards. The information must be accessible, clear, and transparent. It must be available without prior request, in English, free of charge, and without requesting personal information. Crucially, it must also be presented in a way that is understandable by a reader without prior technical knowledge. This plain language requirement is unique to Clause 4 and does not appear in Clause 3. It means the support period information must be written in everyday language that a non-technical consumer can understand, avoiding jargon, firmware version numbers, and acronyms. Subclause 4(7) adds additional requirements that apply when the manufacturer offers to supply the product on its own website or another website under its control under the Australia Cyber Security Act 2024 smart device security standards. In that scenario, the manufacturer must satisfy two conditions. First, the defined support period must be prominently published alongside other information on the website that is intended to inform consumers' decisions to acquire the product. This applies in each instance on the website where such information appears. Second, for each instance on the website where the main characteristics of the product are published, the defined support period must be published alongside or given equal prominence to those main characteristics. The Explanatory Statement provides detailed guidance on how to interpret these website prominence requirements. Product information pages, product purchase pages, and product comparison pages are all locations where the defined support period is likely required. Generic press releases, support articles, and accessory purchase pages are not likely to trigger the requirement. The Explanatory Statement states that a consumer should not need to know that the Cyber Security Act 2024 or its Rules exist in order to discover the defined support period. The information must be findable through normal browsing of product information. It should not be buried in a statement of compliance or in a regulatory section of a website if product characteristics appear elsewhere. - Publish the defined support period as a specific end date, not as a duration without a date. For example, publish 'security updates until 31 December 2030', not 'supported for 5 years'. - Publish the support period for every software and hardware component of the product that is capable of receiving security updates, including companion applications and cloud services developed by or on behalf of the manufacturer. - Do not shorten the defined support period after publication under the Australia Cyber Security Act 2024 smart device security standards. Plan conservatively and commit only to dates the organisation can deliver. - If the support period is extended, publish the new end date as soon as practicable. Keep records of the original publication and every subsequent update. - Write the support period information in plain language that a person without technical knowledge can understand. Avoid jargon, acronyms, firmware version numbers, and references to internal product codes. - On every product information page, product purchase page, and product comparison page on the manufacturer's website or any website under the manufacturer's control, publish the defined support period alongside or with equal prominence to the main product characteristics. - Do not hide the support period information behind a login, a registration form, a non-disclosure agreement, or a request for personal information. - Ensure the support period information is published in English and is accessible free of charge to any person without a prior request. - Match the published support period to the organisation's actual capability to deliver security patches across the committed timeframe. Publish only what the engineering and operations teams can sustain. ## Statement of compliance requirements under the Australia Cyber Security Act 2024 smart device security standards Beyond the three technical standards in Schedule 1, the Australia Cyber Security Act 2024 smart device security standards framework includes mandatory statement of compliance requirements under Division 3 of Part 2 of the Rules. Section 16 of the Act requires manufacturers to provide a statement of compliance for the supply of the product in Australia, and requires suppliers to supply the product accompanied by that statement. Section 9 of the Rules specifies the detailed content requirements for the statement. The statement must be prepared by or on behalf of the manufacturer and must include the following fields under the Australia Cyber Security Act 2024 smart device security standards: the product type and batch identifier; the name and address of the manufacturer; the name and address of an authorised representative of the manufacturer; the name and address of each of the manufacturer's other authorised representatives in Australia (if any); a declaration that the statement was prepared by or on behalf of the manufacturer; a declaration that in the opinion of the manufacturer the product was manufactured in compliance with the security standard and the manufacturer has complied with all other obligations in the standard; the defined support period for the product at the date the statement is issued; the signature, name, and function of the signatory of the manufacturer; and the place and date of issue of the statement. Section 10 sets the retention period for statements of compliance at five years for both manufacturers and suppliers under the Australia Cyber Security Act 2024 smart device security standards. This five-year period was reduced from the originally proposed ten years following stakeholder consultation, on the basis that five years is consistent with the average lifespan of a relevant connectable product and reduces administrative burden on industry. The statement is primarily for the regulator's use to verify compliance. Statements are not required to be provided with the product at point of sale, but must be available for the regulator on request. Products that already comply with the UK Product Security and Telecommunications Infrastructure Regulations 2023 can provide the same statement of compliance for the Australian market under the Australia Cyber Security Act 2024 smart device security standards, provided all requirements in Section 9 are met. Manufacturers operating across both jurisdictions should verify that their UK statement includes the defined support period as at the date the statement is issued and includes the name and address of any authorised representatives in Australia. - The statement of compliance must be prepared by or on behalf of the manufacturer of the product before supply in Australia. - Include the product type, batch identifier, manufacturer name and address, authorised representative details including any representatives in Australia, compliance declarations, defined support period at the date of issue, signatory details, and place and date of issue. - The signatory must provide their signature, name, and function within the manufacturer's organisation. - Retain the statement of compliance for a minimum of five years. Both the manufacturer and the supplier must retain copies. - UK PSTI compliant statements may satisfy Australian requirements under the Australia Cyber Security Act 2024 smart device security standards if every field required by Section 9 is present. - The statement is for the regulator and is not required to be provided to the consumer at point of sale, though the manufacturer may choose to publish it. ## Key definitions in Schedule 1 of the Australia Cyber Security Act 2024 smart device security standards Clause 1 of Schedule 1 defines several terms that manufacturers must understand when applying the Australia Cyber Security Act 2024 smart device security standards. 'Good industry practice' means the exercise of that degree of skill, diligence, prudence, and foresight which would reasonably and ordinarily be expected from a skilled and experienced cryptographer engaged in the same type of activity. This standard of care applies to password generation and encryption decisions under Clause 2 and is the benchmark for assessing whether a password is 'otherwise guessable' under Subclause 2(3)(d). 'Factory default state' means the state of the product after factory reset or after final production or assembly. 'Hardware' means a physical electronic information system, or parts thereof, capable of processing, storing, or transmitting digital data. 'Incremental counter' means a method of password generation in which multiple passwords are the same save for a small number of characters that change per password to make them unique. 'Keyed hashing algorithm' means an algorithm that uses a data input and a secret key to produce a value that cannot be guessed or reproduced without knowledge of both the data input and the secret key. 'Manufacturer's intended purpose' of a product means the use for which the product is intended according to the data provided by the manufacturer, including on the label, in the instructions for use, or in promotional or sales materials or statements. The Explanatory Statement clarifies that the manufacturer's intended purpose remains consistent even if a user does not use the product for that purpose. 'Unique per product' means unique for each individual product of a given product class or type. 'Secret key' means a cryptographic key intended to be known only by the person who encrypted or authorised the encrypting of the data, and any person authorised by that person. 'Consumer' is defined by reference to section 3 of the Australian Consumer Law. - Good industry practice means the standard expected from a skilled and experienced cryptographer engaged in the same type of activity. - Factory default state means the state after factory reset or after final production or assembly. - Hardware means a physical electronic information system capable of processing, storing, or transmitting digital data. - Incremental counter means passwords that differ only by a small number of characters. - Keyed hashing algorithm uses a data input and a secret key to produce a value that cannot be reproduced without both inputs. - Manufacturer's intended purpose is defined by labels, instructions, and promotional materials, and remains consistent regardless of actual user behaviour. - Unique per product means unique for each individual unit of a given product class or type. - Password excludes cryptographic keys, pairing PINs for non-internet-protocol communications, and API keys. ## Enforcement framework for the Australia Cyber Security Act 2024 smart device security standards The Cyber Security Act 2024 establishes a graduated enforcement framework that applies when a responsible entity is suspected of non-compliance with the Australia Cyber Security Act 2024 smart device security standards. The framework operates through three types of notices under Division 3 of Part 2 of the Act, supported by additional regulatory powers under Part 6. Section 17 authorises the Secretary to issue a compliance notice if the Secretary is reasonably satisfied that an entity is not complying with an obligation under Section 15 (manufacturer compliance) or Section 16 (statement of compliance), or is aware of information that suggests that the entity may not be complying with the obligation. The compliance notice must set out the name of the entity, brief details of the non-compliance or possible non-compliance, the corrective action within the entity's control, a reasonable period for completion, and an explanation of what may happen if the entity does not comply. This is the first step in the enforcement ladder under the Australia Cyber Security Act 2024 smart device security standards. Section 18 authorises a stop notice, which can halt the supply of non-compliant products. Section 19 authorises a recall notice, which can require the removal of products from the Australian market. A recall notice is the most severe enforcement action and is used when other measures have not resolved the non-compliance. Under Section 20, the Minister may publicly notify failure to comply with a recall notice on the Department's website or through another method. Section 11 of the Rules specifies that the public notification may include details of the recall notice and recommended actions for consumers, such as destroying the product or taking extra precautions during continued use. Part 6 of the Act provides additional regulatory powers including civil penalty provisions, enforceable undertakings, injunctions, monitoring and investigation powers, and infringement notices. These provisions give the regulator a graduated enforcement toolkit for addressing non-compliance with the Australia Cyber Security Act 2024 smart device security standards. Section 22 of the Act provides for internal review of decisions to issue compliance, stop, or recall notices. Both manufacturers and suppliers carry distinct obligations under the enforcement framework. Manufacturers who are aware, or could reasonably be expected to be aware, that a product will be acquired in Australia must manufacture the product in compliance with the Australia Cyber Security Act 2024 smart device security standards and must comply with all other obligations in the standard. Suppliers who are aware, or could reasonably be expected to be aware, that a product will be acquired in Australia must not supply a non-compliant product and must accompany the product with a valid statement of compliance. - Compliance notices under Section 17 may be issued on the basis of reasonable satisfaction of non-compliance or even information suggesting possible non-compliance. - Stop notices under Section 18 can halt supply of non-compliant products in Australia. - Recall notices under Section 19 can require removal of products from the Australian market. - Failure to comply with a recall notice may result in public notification by the Minister, including the identity of the entity and full product details. - Public notification may recommend that consumers destroy the product or take extra precautions during use. - Civil penalty provisions, enforceable undertakings, injunctions, and infringement notices under Part 6 provide additional enforcement mechanisms. - Decisions to issue compliance, stop, or recall notices are subject to internal review under Section 22 of the Act. - Both manufacturers and suppliers carry distinct obligations under the enforcement framework of the Australia Cyber Security Act 2024 smart device security standards. ## How to operationalise compliance with the Australia Cyber Security Act 2024 smart device security standards Teams that comply successfully with the Australia Cyber Security Act 2024 smart device security standards build a single release gate that checks the password model against all four Subclause 2(3) prohibitions, verifies the vulnerability reporting page meets the Subclause 3(3) accessibility requirements, confirms the support period publication on every required website location under Subclause 4(7), and validates the update delivery path. The release gate should also verify that the statement of compliance has been prepared with all Section 9 fields, signed by the appropriate signatory, and stored in a system that will maintain the record for the five-year retention period. A product can meet the letter of the Australia Cyber Security Act 2024 smart device security standards and still be difficult to defend in an enforcement action if the evidence is fragmented. Build the evidence trail while the product is in development, not after launch. Capture screenshots of the published vulnerability reporting page with timestamps. Generate test reports confirming the password generation method meets good industry practice standards. Capture screenshots of every website location where the defined support period is published alongside product characteristics. Store these artifacts in a central compliance repository with clear version history so that the compliance state at any point in time can be reconstructed. For manufacturers already compliant with the UK PSTI Act, the primary additional work to meet the Australia Cyber Security Act 2024 smart device security standards involves confirming that the statement of compliance includes all Section 9 fields (including authorised representatives in Australia), that the defined support period publication satisfies the Australian website prominence rules under Clause 4(7), and that the security issue reporting information is accessible in English without requesting personal information. Map existing UK evidence to the Australian clause structure and fill any gaps. Train customer support and security triage teams on the published reporting process so that incoming vulnerability reports are handled within the timelines stated on the public page. If the published page states that acknowledgement will be provided within 5 business days and status updates will be provided monthly, the internal workflow must be configured to meet those commitments. Retest compliance after every firmware update, companion application update, account system change, or update mechanism change. - Create a clause level control matrix mapped to each subclause of Schedule 1, with columns for evidence type, responsible owner, test method, and last verification date. - Keep screenshots, test reports, web page captures, and signed statements as evidence. Date every piece of evidence and store it in a central repository. - Assign an approval step before the statement of compliance is issued. The signatory should verify that all three standards in Schedule 1 are met before signing. - Retest compliance with the Australia Cyber Security Act 2024 smart device security standards after firmware updates, companion application updates, account system changes, or update mechanism changes. - For products sold through the manufacturer's website, audit every product information page, purchase page, and comparison page to verify the defined support period is published with equal prominence to the main product characteristics. - Train customer support and security triage teams on the published reporting process so incoming vulnerability reports are handled within the published timelines. - Retain all statements of compliance for at least five years and maintain a record of every published support period and every extension. - Reuse UK PSTI evidence where it meets all Australian Section 9 requirements, and fill gaps for Australia-specific fields such as authorised representatives in Australia. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use Australia Cyber Security Act 2024 Smart device security standards as a cited research workflow Research Copilot can take Australia Cyber Security Act 2024 Smart device security standards from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on Australia Cyber Security Act 2024 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Australia Cyber Security Act 2024 Smart device security standards](/solutions/research-copilot.md): Start from Australia Cyber Security Act 2024 Smart device security standards and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Australia Cyber Security Act 2024](/contact.md): Review your current process, evidence gaps, and next steps for Australia Cyber Security Act 2024 Smart device security standards. ## Primary sources - [Cyber Security (Security Standards for Smart Devices) Rules 2025 - Schedule 1 security standards](https://www.legislation.gov.au/F2025L00276/asmade/text?ref=sorena.io) - Primary source for all three Australia Cyber Security Act 2024 smart device security standards (password, reporting, support period) and statement of compliance requirements. Authorised Version F2025L00276 registered 04/03/2025, Schedule 1 effective 4 March 2026. - Quote: "Part 1 of Schedule 1 prescribes the security standard for the class of relevant connectable products that is all relevant connectable products that are intended by the manufacturer to be used, or are of a kind likely to be used, for personal, domestic or household use or consumption." - [Cyber Security Act 2024 (No. 98, 2024) - Part 2 Security standards for smart devices](https://www.legislation.gov.au/C2024A00098/latest/text?ref=sorena.io) - Contains the statutory obligations on manufacturers (Section 15) and suppliers (Section 16), enforcement notice powers under Sections 17, 18, 19 and 20, and civil penalty provisions under Part 6. - [Explanatory Statement for the Cyber Security (Security Standards for Smart Devices) Rules 2025](https://www.legislation.gov.au/F2025L00276/asmade/explanatory-statement/text?ref=sorena.io) - Clause by clause commentary on Schedule 1, including guidance on website prominence for the defined support period, consumer definition, privacy implications, and the relationship to the UK PSTI Regulations. - Quote: "The security standards in Schedule 1, Part 1 of the Rules closely follows the Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023 (UK)." - [Impact Analysis: Mandatory security standards for consumer grade smart devices (OIA23-05027)](https://www.legislation.gov.au/F2025L00276/asmade/supplementary-explanatory-statement/text?ref=sorena.io) - Documents the policy rationale for selecting the first three ETSI EN 303 645 principles, the UK modelling showing a 20 to 70 per cent reduction in attack probability, cost estimates to industry, and the supplementary analysis for consumer energy resources. - [ETSI EN 303 645 - Cyber Security for Consumer Internet of Things: Baseline Requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - The international baseline standard that the Australia Cyber Security Act 2024 smart device security standards closely follow for Provisions 5.1 (passwords), 5.2 (vulnerability disclosure), and 5.3 (software updates). ## Related Topic Guides - [Australia Cyber Security Act 2024 Applicability Test | Who Must Comply](/artifacts/apac/australia-cyber-security-act/applicability-test.md): Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations. - [Australia Cyber Security Act 2024 Compliance Checklist](/artifacts/apac/australia-cyber-security-act/checklist.md): Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting. - [Australia Cyber Security Act 2024 Compliance Guide | Implementation Playbook](/artifacts/apac/australia-cyber-security-act/compliance.md): A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements. - [Australia Cyber Security Act 2024 Compliance Templates | Statement of Compliance, Ransomware Report, Evidence Pack, Vulnerability Disclosure, Support Period](/artifacts/apac/australia-cyber-security-act/templates.md): Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field. - [Australia Cyber Security Act 2024 Deadlines and Compliance Calendar | Commencement Dates](/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar.md): Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent. - [Australia Cyber Security Act 2024 FAQ | Frequently Asked Questions](/artifacts/apac/australia-cyber-security-act/faq.md): Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024. - [Australia Cyber Security Act 2024 Requirements | Smart Device and Ransomware Reporting Obligations](/artifacts/apac/australia-cyber-security-act/requirements.md): Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure. - [Australia Cyber Security Act 2024 Timeline and Commencement Dates | Full Schedule](/artifacts/apac/australia-cyber-security-act/timeline-and-commencement.md): Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024. - [Australia Cyber Security Act 2024 vs EU Cyber Resilience Act | Full CRA Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act.md): Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements. - [Australia Cyber Security Act 2024 vs UK PSTI Act | Product Security Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act.md): Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements. - [Australia Smart Device Compliance Checklist | Cyber Security Act 2024 | Sorena](/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist.md): Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure. - [Penalties and fines | Australia Cyber Security Act 2024 | 60 Penalty Units, Smart Device Enforcement, Ransomware Reporting](/artifacts/apac/australia-cyber-security-act/penalties-and-fines.md): Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals. - [Ransomware Payment Reporting in 72 Hours | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours.md): Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. - [Scope and Definitions | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/scope-and-definitions.md): Complete guide to the Australia Cyber Security Act 2024 scope and definitions. - [Statement of Compliance and Recordkeeping | Australia Cyber Security Act 2024 | Section 9, Section 10, 5 Year Retention](/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping.md): Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/australia-cyber-security-act/smart-device-security-standards --- --- title: "Statement of Compliance and Recordkeeping" canonical_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping" source_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping" author: "Sorena AI" description: "Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "Australia Cyber Security Act 2024 statement of compliance" - "statement of compliance requirements Section 9" - "statement of compliance retention 5 years Section 10" - "smart device statement of compliance Australia" - "manufacturer statement of compliance obligations" - "supplier statement of compliance obligations" - "statement of compliance template Australia" - "statement of compliance evidence pack" - "statement of compliance audit preparation" - "statement of compliance recordkeeping Australia" - "defined support period statement of compliance" - "signatory requirements statement of compliance" - "authorised representative statement of compliance" - "compliance notice statement of compliance" - "recall notice statement failure" - "enforcement statement of compliance Australia" - "statement of compliance recordkeeping" - "smart device statement of compliance" - "Section 9 statement requirements" - "Section 10 five year retention" - "manufacturer statement of compliance" - "supplier statement of compliance" - "APAC compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Statement of Compliance and Recordkeeping Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025. *Compliance Guide* *APAC* ## Australia Cyber Security Act 2024 Statement of Compliance and Recordkeeping Every in-scope smart device supplied in Australia must be accompanied by a statement of compliance prepared by or on behalf of the manufacturer. The Australia Cyber Security Act 2024 statement of compliance must include all fields prescribed by Section 9(3) of the Security Standards for Smart Devices Rules 2025, and both manufacturers and suppliers must retain a copy for 5 years under Section 10. The Australia Cyber Security Act 2024 statement of compliance is a controlled legal artifact that connects product identity, manufacturer declarations, the defined support period, and signatory accountability into one document. Getting the statement of compliance wrong can trigger compliance notices, stop notices, recall notices, and public notification of failure. The Australia Cyber Security Act 2024 statement of compliance is the central documentary obligation for smart devices under the Act. Section 16(1) of the Cyber Security Act 2024 requires manufacturers to provide a statement of compliance for every relevant connectable product supplied in Australia. Section 16(3) requires suppliers to supply the product with the Australia Cyber Security Act 2024 statement of compliance. Both manufacturers and suppliers must retain their copy for 5 years under Section 10 of the Security Standards for Smart Devices Rules 2025. The Australia Cyber Security Act 2024 statement of compliance is not a marketing document. It is the primary evidence that the regulator uses to verify that a manufacturer has met its obligations under the Act and Rules. The Secretary may engage an independent expert under Section 23 to examine whether the product complies with the security standard and whether the Australia Cyber Security Act 2024 statement of compliance itself meets the requirements of Section 16. This page covers every prescribed element, who must prepare and retain the statement of compliance, the 5 year retention period, evidence pack structure, template design, audit preparation, common mistakes, and enforcement consequences. ## What the Australia Cyber Security Act 2024 statement of compliance must contain under Section 9(3) Section 9(3) of the Cyber Security (Security Standards for Smart Devices) Rules 2025 prescribes seven mandatory elements that every Australia Cyber Security Act 2024 statement of compliance must include. The statement of compliance must be prepared by, or on behalf of, the manufacturer of the product under Section 9(2). There is no prescribed format or template, but every Australia Cyber Security Act 2024 statement of compliance must include all seven elements to satisfy the Rules. Omitting any single element means the statement of compliance does not meet the requirements, which means the product is not lawfully supplied with a compliant document. The Explanatory Statement for the Rules clarifies the purpose of each element. Product type and batch identifier are required to differentiate between products that may appear similar. For example, two products with different manufacturing dates may have different security updates installed by default. The manufacturer details provide the regulator with a point of contact if there are concerns with the Australia Cyber Security Act 2024 statement of compliance. The defined support period at the date of issue locks the manufacturer into a commitment that cannot be shortened after publication. - Element (a): Product type and batch identifier. This links the Australia Cyber Security Act 2024 statement of compliance to the specific product configuration in the market and distinguishes it from similar products with different manufacturing dates or firmware versions. - Element (b): Name and address of the manufacturer, an authorised representative of the manufacturer, and each (if any) of the manufacturer's other authorised representatives that are in Australia. All authorised representatives located in Australia must be listed. - Element (c): A declaration that the Australia Cyber Security Act 2024 statement of compliance has been prepared by, or on behalf of, the manufacturer of the product. - Element (d): A declaration that, in the opinion of the manufacturer, the product has been manufactured in compliance with the requirements of the security standard and the manufacturer has complied with any other obligations relating to the product in the security standard. This covers password controls, security issue reporting, and defined support period obligations. - Element (e): The defined support period for the product at the date the Australia Cyber Security Act 2024 statement of compliance is issued. The Explanatory Statement specifies that this should include a fixed end date, for example 'no later than 30 June 2027'. - Element (f): The signature, name, and function of the signatory of the manufacturer. The signatory must be identified by full name, job title or role, and must sign the document. - Element (g): The place and date of issue of the Australia Cyber Security Act 2024 statement of compliance. Both the location where the document was issued and the exact date must appear. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep Australia Cyber Security Act 2024 Statement of Compliance and Recordkeeping in one governed evidence system SSOT can take Australia Cyber Security Act 2024 Statement of Compliance and Recordkeeping from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on Australia Cyber Security Act 2024 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for Australia Cyber Security Act 2024 Statement of Compliance and Recordkeeping](/solutions/ssot.md): Start from Australia Cyber Security Act 2024 Statement of Compliance and Recordkeeping and keep documents, evidence, and control records in one governed system. - [Talk through Australia Cyber Security Act 2024](/contact.md): Review your current process, evidence gaps, and next steps for Australia Cyber Security Act 2024 Statement of Compliance and Recordkeeping. ## Manufacturer obligations for the Australia Cyber Security Act 2024 statement of compliance Section 16(1) of the Australia Cyber Security Act 2024 places the primary statement of compliance obligation on manufacturers. An entity that manufactures a relevant connectable product must provide, for the supply of the product in Australia, a statement of compliance with the security standard. This obligation applies when the product is included in a class covered by the Rules and the manufacturer is aware, or could reasonably be expected to be aware, that the product will be acquired in Australia in the specified circumstances. Section 9(2) of the Rules reinforces that the Australia Cyber Security Act 2024 statement of compliance must be prepared by, or on behalf of, the manufacturer. This means the manufacturer can delegate the preparation of the statement of compliance to an authorised representative or other agent, but the manufacturer remains responsible for the accuracy and completeness of the document. The declaration in Element (c) explicitly attributes the Australia Cyber Security Act 2024 statement of compliance to the manufacturer regardless of who drafted it. The compliance declaration in Element (d) of Section 9(3) requires the manufacturer to state their opinion that the product was manufactured in compliance with the security standard and that the manufacturer has complied with any other obligations in the security standard. This means the manufacturer must have verified all three pillars of the smart device security standard before signing the Australia Cyber Security Act 2024 statement of compliance: password controls are correct, the security issue reporting channel is published and accessible, and the defined support period is published with an end date. Manufacturers operating across multiple jurisdictions should note that the Australia Cyber Security Act 2024 statement of compliance is for the use of the regulator to ensure the responsible entity has met its obligations under the Act and Rules. The Explanatory Statement confirms that statements of compliance are not required to be provided with the product at point of sale. However, responsible entities may provide or publish statements of compliance with their product if they wish. - The manufacturer bears the primary obligation to provide an Australia Cyber Security Act 2024 statement of compliance under Section 16(1) of the Act. - The manufacturer must retain a copy of every Australia Cyber Security Act 2024 statement of compliance for at least 5 years under Section 16(2). - The Australia Cyber Security Act 2024 statement of compliance must be prepared by, or on behalf of, the manufacturer under Section 9(2) of the Rules. - Delegation of statement preparation to an authorised representative does not transfer responsibility from the manufacturer. - Before signing the Australia Cyber Security Act 2024 statement of compliance, verify password compliance, security issue reporting publication, and defined support period publication. - Do not shorten a published defined support period after it appears in a statement of compliance. The Rules prohibit shortening the defined support period after publication under Clause 4(4) of Schedule 1. - The Australia Cyber Security Act 2024 statement of compliance is not required at point of sale. It is primarily for regulator use to verify compliance. ## Supplier obligations for the Australia Cyber Security Act 2024 statement of compliance Section 16(3) of the Australia Cyber Security Act 2024 creates a separate obligation for suppliers. An entity that supplies a relevant connectable product in Australia must supply the product with the Australia Cyber Security Act 2024 statement of compliance. This obligation applies when the product is included in a class covered by the security standard and the supplier is aware, or could reasonably be expected to be aware, that the product will be acquired in Australia in the specified circumstances. Section 16(4) requires the supplier to retain a copy of the Australia Cyber Security Act 2024 statement of compliance for the period specified in the Rules. Under Section 10 of the Rules, the retention period for suppliers is the same as for manufacturers: 5 years. This means every entity in the Australian supply chain that handles the product has an independent obligation to retain the Australia Cyber Security Act 2024 statement of compliance for 5 years. A supplier who is aware, or could reasonably be expected to be aware, that the product will be acquired in Australia by a consumer cannot lawfully supply a product that was not manufactured in compliance with the security standard under Section 15(3) of the Act. This means the supplier should have a process to confirm that the Australia Cyber Security Act 2024 statement of compliance exists, that it covers the correct product type and batch, and that the defined support period and declarations appear complete before the product enters the Australian supply chain. Supply chain contracts should address statement of compliance handoff, verification, and retention responsibilities explicitly. - Section 16(3) requires every supplier of a relevant connectable product in Australia to supply the product with the Australia Cyber Security Act 2024 statement of compliance. - Section 16(4) requires every supplier to retain a copy of the Australia Cyber Security Act 2024 statement of compliance for 5 years. - The supplier retention obligation is independent of the manufacturer retention obligation. Both must hold their own copies. - Do not rely on verbal assurances from the manufacturer. Obtain and inspect the actual Australia Cyber Security Act 2024 statement of compliance document before supply. - If a product variant or new batch is shipped, verify that the statement of compliance covers that specific variant or batch. A statement of compliance issued for a different product configuration does not satisfy the supply obligation. - Build a receiving checklist that verifies the presence and completeness of the Australia Cyber Security Act 2024 statement of compliance at goods inward or import clearance. - Supply chain contracts should specify statement of compliance handoff procedures, verification steps, and retention responsibilities. ## Defined support period declaration in the Australia Cyber Security Act 2024 statement of compliance Element (e) of Section 9(3) requires the Australia Cyber Security Act 2024 statement of compliance to include the defined support period for the product at the date the statement of compliance is issued. The defined support period is the period, expressed as a period of time with an end date, for which the manufacturer will provide security updates for the product. The Explanatory Statement specifies that the defined support period should include a fixed end date rather than just a duration, for example 'no later than 30 June 2027'. Schedule 1, Clause 4 of the Rules governs the defined support period. The manufacturer must publish the defined support period in a location that is accessible, free of charge, does not require the creation of an account, is in English, and does not require the provision of personal information. If the manufacturer offers the product on its website, the defined support period must be prominently published alongside the main product characteristics with equal prominence. Once published, the manufacturer must not shorten the defined support period under Clause 4(4). If the manufacturer extends the defined support period, the new period must be published as soon as practicable under Clause 4(5). The Australia Cyber Security Act 2024 statement of compliance locks the defined support period at the date of issue. If the statement of compliance declares a support period ending 30 June 2027, the manufacturer cannot later reduce that commitment. The support period on the manufacturer's public website must match the support period declared in the Australia Cyber Security Act 2024 statement of compliance. Any mismatch between these two records is a compliance failure that the regulator can identify through a straightforward comparison. - The defined support period in the Australia Cyber Security Act 2024 statement of compliance must include a fixed end date, not just a duration. - The manufacturer must publish the defined support period in a location that is accessible, free of charge, in English, and does not require account creation or personal information. - If the product is sold on the manufacturer's website, the defined support period must appear alongside the main product characteristics with equal prominence. - The manufacturer must not shorten the defined support period after publication under Clause 4(4) of Schedule 1. - Extensions to the defined support period must be published as soon as practicable under Clause 4(5). - The support period on the public website must match the support period in the Australia Cyber Security Act 2024 statement of compliance at the date of issue. - A mismatch between the published support period and the Australia Cyber Security Act 2024 statement of compliance is one of the most easily detected compliance failures. ## Signatory and authorised representative requirements for the Australia Cyber Security Act 2024 statement of compliance Element (f) of Section 9(3) requires the Australia Cyber Security Act 2024 statement of compliance to include the signature, name, and function of the signatory of the manufacturer. This creates personal accountability within the manufacturer's organization. The signatory must be identified by full name and by their role or job title, and must sign the Australia Cyber Security Act 2024 statement of compliance. The Explanatory Statement acknowledges that the signatory's personal information will be disclosed in the statement of compliance, and accepts this as a proportionate limitation on privacy rights given the public safety purpose of the smart device regime. Element (b) requires the Australia Cyber Security Act 2024 statement of compliance to include the name and address of the manufacturer, an authorised representative of the manufacturer, and each (if any) of the manufacturer's other authorised representatives that are in Australia. This means the statement of compliance must identify all authorised representatives, not just one. Manufacturers with multiple authorised representatives in Australia must list each one. The authorised representative details give the regulator alternative contact points within the Australian jurisdiction. Manufacturers should define internal signatory authority rules that specify which individuals are authorised to sign the Australia Cyber Security Act 2024 statement of compliance on behalf of the manufacturer. The signatory register should be maintained as a controlled document, updated when personnel changes occur. If the signatory has left the organisation or changed roles, the register should be updated and future statements of compliance should be signed by a currently authorised person. - The Australia Cyber Security Act 2024 statement of compliance must include the signature, name, and function (role or title) of the manufacturer's signatory. - The signatory's personal information will be disclosed in the Australia Cyber Security Act 2024 statement of compliance as acknowledged in the Explanatory Statement. - The statement of compliance must list the name and address of the manufacturer. - The statement of compliance must list the name and address of an authorised representative of the manufacturer. - The statement of compliance must list each authorised representative located in Australia, if any exist. - Manufacturers should maintain an internal signatory authority register that specifies who can sign the Australia Cyber Security Act 2024 statement of compliance. - Update the signatory register when personnel leave or change roles. Verify current authority before each statement of compliance is signed. ## Recordkeeping and the 5 year retention period under Section 10 Section 10 of the Cyber Security (Security Standards for Smart Devices) Rules 2025 sets the retention period for the Australia Cyber Security Act 2024 statement of compliance at 5 years. This period applies to both manufacturers under Section 16(2) of the Act and suppliers under Section 16(4) of the Act. The obligation to retain the Australia Cyber Security Act 2024 statement of compliance for 5 years applies equally across the supply chain. The 5 year retention period was reduced from a proposed 10 years following industry consultation. The Explanatory Statement records that stakeholders recommended reducing the retention period to 5 years because it is consistent with the average lifespan of a relevant connectable product and reduces administrative burden on industry. This recommendation was accepted and incorporated into the final Rules. Retaining the Australia Cyber Security Act 2024 statement of compliance alone is necessary but may not be sufficient for a robust compliance position. The statement of compliance declares that the product meets the security standard and states the defined support period. If the regulator or an independent expert under Section 23 examines the statement of compliance, the manufacturer should be able to produce the evidence that supported the declarations at the time of issue. This means test reports, vulnerability assessment records, support period publication evidence, and signatory approval records should all be retained alongside the Australia Cyber Security Act 2024 statement of compliance. The 5 year retention period for the Australia Cyber Security Act 2024 statement of compliance should be reflected in the organisation's document retention schedule and records management system. The obligation is not just to store the statement of compliance. The obligation is to be able to retrieve it on demand. If the Secretary requests the Australia Cyber Security Act 2024 statement of compliance under Section 23 of the Act, the entity must be able to produce the document within the period specified in the written notice. - Manufacturers must retain each Australia Cyber Security Act 2024 statement of compliance for at least 5 years under Section 16(2) of the Act and Section 10 of the Rules. - Suppliers must retain each Australia Cyber Security Act 2024 statement of compliance for at least 5 years under Section 16(4) of the Act and Section 10 of the Rules. - The 5 year retention period was reduced from a proposed 10 years after industry consultation confirmed it aligns with the average smart device lifespan. - Record the start date and expected disposal date for each Australia Cyber Security Act 2024 statement of compliance in the retention schedule. - Store the statement of compliance in a system that supports immutable records or locked copies so the document cannot be altered after issue. - Retain the product test evidence, support period publication records, and signatory approval evidence alongside each Australia Cyber Security Act 2024 statement of compliance. - Test retrieval procedures so the business can produce both the Australia Cyber Security Act 2024 statement of compliance and its supporting evidence promptly on request. - If statements of compliance are stored across different business units or geographies, maintain a central index mapping each product type, batch, and statement of compliance to its storage location. ## Evidence pack structure for each Australia Cyber Security Act 2024 statement of compliance The Australia Cyber Security Act 2024 statement of compliance is a declaration document. The evidence pack is the technical and operational record that proves the declarations in the statement of compliance were justified at the time of issue. A complete evidence pack for each Australia Cyber Security Act 2024 statement of compliance should cover all three pillars of the smart device security standard in Schedule 1 of the Rules: password controls, security issue reporting, and defined support period and security updates. Each pillar should have its own section within the evidence pack. The evidence pack should also include records related to the signatory, the product identity, and the date alignment between the defined support period in the statement of compliance and the published defined support period on the manufacturer's website. If the regulator or an independent expert under Section 23 asks why the manufacturer declared compliance in the Australia Cyber Security Act 2024 statement of compliance, the answer should be a retrievable evidence pack, not a recollection or a verbal explanation. Organisations should assign a unique reference number to each Australia Cyber Security Act 2024 statement of compliance and use the same reference number to identify the corresponding evidence pack. This linkage ensures that the statement of compliance and its evidence can always be retrieved together. The evidence pack should be retained for the same 5 year period as the statement of compliance itself. - Password evidence: test reports confirming passwords are unique per product or user defined, test reports confirming factory default passwords are not based on incremental counters or public information, and test reports confirming that serial number derivation (if used) uses accepted encryption or keyed hashing as required by good industry practice. - Security issue reporting evidence: archive copies or screenshots of the published security issue reporting page, confirmation that the page includes at least one contact point, confirmation that the page explains when the reporter will receive acknowledgement and status updates, and confirmation that the page is accessible without prior request, in English, free of charge, and without requiring personal information. - Defined support period evidence: archive copies or screenshots of the published defined support period page, confirmation that the support period is expressed as a period of time with an end date, confirmation that the page is accessible and free of charge and in English and does not require personal information, and if the product is offered for sale on the manufacturer's website confirmation that the support period is published alongside the main product characteristics with equal prominence. - Date alignment evidence: confirmation that the defined support period in the Australia Cyber Security Act 2024 statement of compliance matches the defined support period published on the manufacturer's website on the date of issue. - Signatory authority evidence: the internal approval record showing that the signatory was authorised to sign the Australia Cyber Security Act 2024 statement of compliance on behalf of the manufacturer, including any delegation of authority documents. - Product identity evidence: the product specification sheet, model number, hardware revision, firmware version, and batch or lot identifier that corresponds to the product type and batch identifier in the Australia Cyber Security Act 2024 statement of compliance. - Assign a unique reference number to each Australia Cyber Security Act 2024 statement of compliance and use it to link the statement to its evidence pack for joint retrieval. ## Template guidance for the Australia Cyber Security Act 2024 statement of compliance Organisations should use a single approved template for the Australia Cyber Security Act 2024 statement of compliance. The template should contain all mandatory fields from Section 9(3) of the Rules as labelled placeholders. Teams should not modify the wording or layout without compliance review. The template itself should be a controlled document with its own version number and approval record so that all issued statements of compliance can be traced back to the template version in force at the time of issue. The template for the Australia Cyber Security Act 2024 statement of compliance should be connected to the product release or supply approval workflow. The statement of compliance should not be issued until the evidence pack is complete, the defined support period page is live and verified, and the signatory has reviewed and approved the content. Automating the generation of the Australia Cyber Security Act 2024 statement of compliance from approved source data (product database, legal entity register, defined support period system) reduces the risk of transcription errors, stale data, and inconsistencies across product families. If the organisation manufactures multiple product families, maintain one master template for the Australia Cyber Security Act 2024 statement of compliance and populate it from a central product data source rather than maintaining separate templates per product. This approach ensures consistency and simplifies template governance. - Include a labelled field for every Section 9(3) requirement: product type, batch identifier, manufacturer name and address, authorised representative name and address, additional Australian authorised representatives, preparation declaration, compliance declaration, defined support period with end date, signatory signature, signatory name, signatory function, place of issue, and date of issue. - Add a template version number and a template approval date to the footer of the Australia Cyber Security Act 2024 statement of compliance template. - Add a validation step that compares the defined support period in the Australia Cyber Security Act 2024 statement of compliance against the live published defined support period page before the document is signed. - Add a validation step that confirms the product type and batch identifier in the statement of compliance match the product records in the manufacturer's system. - Require digital or wet ink signature from an authorised signatory listed on the current signatory register. The template should not allow the Australia Cyber Security Act 2024 statement of compliance to be finalised without a signature. - Store a final locked copy of each issued Australia Cyber Security Act 2024 statement of compliance with immutable metadata (hash, timestamp, signatory identity) where the organisation's systems support it. - Do not allow teams to freestyle the wording of declarations. Use the exact language required by Section 9(3)(c) and Section 9(3)(d) for the preparation and compliance declarations. ## Connecting the Australia Cyber Security Act 2024 statement of compliance to release and supply controls The Australia Cyber Security Act 2024 statement of compliance should not be treated as an afterthought that happens outside the product release process. It should be gated into the release approval or supply approval workflow so that no product enters the Australian market without a valid statement of compliance. For manufacturers, the statement of compliance issue step should sit after final test approval and after the defined support period page is confirmed live. For suppliers and importers, the Australia Cyber Security Act 2024 statement of compliance verification step should sit at goods inward or import clearance before the product is released into Australian distribution. Automated validation should check product version, batch identifier, legal entity name, authorised representative details, defined support period consistency, and signatory authority before the Australia Cyber Security Act 2024 statement of compliance is finalised. A manual process creates opportunities for mismatched identifiers, stale support period data, and unauthorized signatories. If a product variant or firmware update changes the security posture of the product, the organisation should assess whether a new Australia Cyber Security Act 2024 statement of compliance is required for the updated configuration. - Block product release to the Australian market if the evidence pack is incomplete or if any of the three security standard pillars (password, security issue reporting, defined support period) have not been verified. - Block Australia Cyber Security Act 2024 statement of compliance issue if the defined support period published on the manufacturer's website does not match the defined support period listed in the statement. - Block statement of compliance issue if the signatory is not listed on the current authorised signatory register. - For suppliers: block product receipt into Australian inventory if the Australia Cyber Security Act 2024 statement of compliance is missing, if the product type and batch do not match, or if any required field is blank. - Log every issue event with the statement of compliance reference number, the product batch, the signatory identity, and a timestamp. This log becomes part of the recordkeeping evidence. - If a product variant or firmware update changes the security posture, assess whether a new Australia Cyber Security Act 2024 statement of compliance is required for the updated configuration. ## Audit preparation for the Australia Cyber Security Act 2024 statement of compliance Section 23 of the Cyber Security Act 2024 gives the Secretary the power to engage an appropriately qualified and experienced expert to carry out an independent examination of a product to determine whether the product complies with the security standard and whether the Australia Cyber Security Act 2024 statement of compliance complies with the requirements of Section 16. The Secretary can issue a written notice under Section 23(3) requesting the entity to provide the product, the statement of compliance, or both. The written notice under Section 23(4) must specify the product, the manufacturer of the product (if known to the Secretary), a reasonable period within which the entity must respond, the period for which the product will be retained for testing, the requirements of the security standard the product will be tested against, and the kind of testing or analysis that will be performed. The expert may examine the product by opening packaging, operating the product, testing or analysing the product using electronic equipment, reading records or documents contained in the product, and taking photographs or video recordings. Entities are entitled to reasonable compensation from the Commonwealth for complying with an examination request under Section 23(5). Audit preparation for the Australia Cyber Security Act 2024 statement of compliance means being able to respond to a Section 23 notice quickly and completely. The organisation should be able to locate the correct statement of compliance for any product batch, produce the supporting evidence pack, and explain the compliance declaration and the defined support period declaration without delay. Organisations should run an internal rehearsal at least once per year to test their readiness. Select a product at random, locate its Australia Cyber Security Act 2024 statement of compliance, pull the corresponding evidence pack, confirm the defined support period still matches the published page, verify the signatory was authorised at the date of issue, and measure the total time from request to production. If the process takes more than a few business days, the retrieval workflow needs improvement. - Maintain an index of all issued Australia Cyber Security Act 2024 statements of compliance, mapped to product type, batch identifier, date of issue, signatory name, and evidence pack location. - Store the Australia Cyber Security Act 2024 statement of compliance and its evidence pack in the same retrieval system or link them with a shared reference number so they can be produced together. - Confirm that the records management system retains all documents for at least 5 years and that automated disposal rules do not delete statements of compliance or evidence packs before the retention period expires. - Train the compliance and product security teams on the Section 23 examination process so they know what the Secretary can request and what response timeframe is expected. - Include the Australia Cyber Security Act 2024 statement of compliance in the scope of internal compliance audits. Verify that every product currently supplied in Australia has a valid statement of compliance on file. - Run an internal retrieval rehearsal at least once per year. Simulate a Section 23 request for a randomly selected product and measure response time. - If the organisation receives a compliance notice (Section 17) related to the Australia Cyber Security Act 2024 statement of compliance, the response should include the statement of compliance, the evidence pack, and a description of corrective actions taken. Prepare a response template in advance. - Keep contact details for the authorised signatory current. If the signatory has left the organisation, update the signatory register and confirm that future statements of compliance are signed by a currently authorised person. ## Cross-jurisdictional recognition of UK PSTI statements of compliance The Explanatory Statement for the Rules confirms that responsible entities operating across jurisdictions with similar compliance frameworks can reuse the same information for the Australian statement of compliance. The most significant example is the United Kingdom. Products supplied to the UK market under the Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023 can provide the same statement of compliance for the Australian market, provided all requirements in Section 9 of the Australian Rules are met. This cross-jurisdictional recognition reduces the compliance burden for manufacturers who already sell into the UK market. The Australian security standards in Schedule 1, Part 1 of the Rules closely follow the UK PSTI Regulations, which are themselves based on the first three provisions of ETSI EN 303 645. Because the underlying security requirements are substantially aligned, a UK PSTI statement of compliance may already contain most of the information required by Section 9(3) of the Australian Rules. Manufacturers should verify that the UK statement includes all seven Australian elements, particularly the Australian authorised representative details and the place and date of issue. - The Explanatory Statement confirms that UK PSTI statements of compliance can be reused for the Australian market if all Section 9 requirements are met. - The Australian security standards closely follow the UK PSTI Regulations, both based on ETSI EN 303 645 provisions. - Manufacturers already selling into the UK should verify their UK statement covers all seven elements required by Section 9(3) of the Australian Rules. - Australian authorised representative details (Element (b)) may need to be added to a UK statement of compliance for it to qualify as a valid Australia Cyber Security Act 2024 statement of compliance. - The defined support period format should be verified against the Australian requirement for a fixed end date. ## Common mistakes with the Australia Cyber Security Act 2024 statement of compliance Most failures with the Australia Cyber Security Act 2024 statement of compliance are process failures, not template failures. The template may contain all seven required elements, but the data populating those elements may be wrong, stale, or inconsistent. Fixing these weaknesses requires process design, not legal drafting. Teams should audit the data sources feeding the Australia Cyber Security Act 2024 statement of compliance and verify that handoff controls between manufacturing, product security, legal, and supply chain functions are reliable. Every mistake listed below can lead to a non-compliant Australia Cyber Security Act 2024 statement of compliance, which means the product is not lawfully supplied with a compliant document. Under the enforcement provisions of the Act, this can trigger a compliance notice (Section 17), a stop notice (Section 18), or a recall notice (Section 19). The most detectable failure is a mismatch between the defined support period published on the manufacturer's website and the defined support period declared in the statement of compliance, because the regulator can identify this failure through a simple comparison without requesting any internal records. - Defined support period mismatch: the support period on the public website does not match the support period in the Australia Cyber Security Act 2024 statement of compliance. This is the most easily detected failure. - Premature issuance: the Australia Cyber Security Act 2024 statement of compliance is issued before final test results or conformity assessment results are approved, leaving the compliance declaration unsupported. - Product variant mismatch: a product variant ships under an Australia Cyber Security Act 2024 statement of compliance that was issued for a different configuration, batch, or firmware version. - Missing authorised representatives: the statement of compliance does not list all authorised representatives in Australia as required by Element (b) of Section 9(3). - Supply chain handoff failure: suppliers cannot demonstrate that the Australia Cyber Security Act 2024 statement of compliance accompanied the product when supplied in Australia. - Orphaned statement: the Australia Cyber Security Act 2024 statement of compliance is stored but the supporting test evidence, signatory approval, and support period records cannot be located. - Signatory authority gap: the statement of compliance is signed by an individual who was not authorised to sign on behalf of the manufacturer at the date of issue. - Missing place or date of issue: the Australia Cyber Security Act 2024 statement of compliance does not include the place of issue or the date of issue as required by Element (g) of Section 9(3). - Template inconsistency: multiple teams in different regions issue Australia Cyber Security Act 2024 statements of compliance using different templates or different wording, creating inconsistencies across the same product family. - Non-retrievable format: the Australia Cyber Security Act 2024 statement of compliance is stored as a scanned image that is not searchable or quickly retrievable from the records management system. ## Enforcement consequences for non-compliant Australia Cyber Security Act 2024 statements of compliance Division 3 of Part 2 of the Cyber Security Act 2024 provides a graduated enforcement model for failures related to the Australia Cyber Security Act 2024 statement of compliance. The Act does not impose a direct monetary penalty for statement of compliance deficiencies. Instead, the Secretary operates a staged enforcement escalation that can result in compliance notices, stop notices, recall notices, and public notification of failure. Before issuing any notice, the Secretary must notify the entity and provide at least 10 days for the entity to make representations. This pre-notice representation right applies at every stage of the enforcement path. The enforcement path begins when the Secretary is reasonably satisfied that an entity is not complying with Section 15 (security standards) or Section 16 (Australia Cyber Security Act 2024 statement of compliance obligations), or becomes aware of information suggesting possible non-compliance. Section 23 gives the Secretary the separate power to engage an independent expert to examine whether the product complies with the security standard and whether the Australia Cyber Security Act 2024 statement of compliance complies with the requirements of Section 16. This examination power can be used at any time, not only after a notice has been issued. If the entity fails to comply with a recall notice, the Minister may publish the entity's identity, details of the product, details of the non-compliance, and the risks posed by the product on the Department's website or in any other way the Minister considers appropriate under Section 20 of the Act. Monitoring powers under Part 2 of the Regulatory Powers (Standard Provisions) Act 2014 also apply to Sections 15 and 16, and enforceable undertakings under Part 6 of the Regulatory Powers Act allow the Secretary to accept formal compliance commitments. - Compliance notice (Section 17): the Secretary issues a written notice specifying the non-compliance and requiring corrective action within a reasonable period. The entity must be given at least 10 days to make representations before the compliance notice is issued. - Stop notice (Section 18): issued after a compliance notice if the entity has not complied or if corrective actions are inadequate. The stop notice can require the entity to take or refrain from taking specified actions. - Recall notice (Section 19): issued after a stop notice if the entity still has not complied. The recall notice can require the entity to ensure the product is not acquired in Australia, not supplied to suppliers, and is returned to the manufacturer. - Public notification (Section 20): if the entity fails to comply with a recall notice, the Minister may publish the identity of the entity, product details, non-compliance details, and risks posed by the product. - Independent examination (Section 23): the Secretary can request the product and the Australia Cyber Security Act 2024 statement of compliance for expert examination at any time. - Monitoring powers under Part 2 of the Regulatory Powers Act apply to Sections 15 and 16, including entry and inspection of business premises. - Enforceable undertakings under Part 6 of the Regulatory Powers Act apply to Sections 15 and 16, allowing the Secretary to accept formal compliance commitments from entities. ## Primary sources - [Cyber Security (Security Standards for Smart Devices) Rules 2025 official text](https://www.legislation.gov.au/F2025L00276/asmade/text?ref=sorena.io) - Section 9 prescribes the required contents of the Australia Cyber Security Act 2024 statement of compliance. Section 10 sets the 5 year retention period. Schedule 1 Part 1 sets the security standard. - [Explanatory Statement for the Security Standards for Smart Devices Rules 2025](https://www.legislation.gov.au/F2025L00276/asmade/explanatory-statement/text?ref=sorena.io) - Detailed explanation of statement of compliance requirements, cross-jurisdictional recognition with UK PSTI, the reduction of the retention period from 10 years to 5 years following consultation, and confirmation that the statement is for regulator use. - [Cyber Security Act 2024 (Australia) official text](https://www.legislation.gov.au/C2024A00098/latest/text?ref=sorena.io) - Section 16 creates the obligation for manufacturers and suppliers regarding the Australia Cyber Security Act 2024 statement of compliance. Sections 17 to 20 set out the enforcement powers. Section 23 authorises examination of products and statements of compliance. ## Related Topic Guides - [Australia Cyber Security Act 2024 Applicability Test | Who Must Comply](/artifacts/apac/australia-cyber-security-act/applicability-test.md): Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations. - [Australia Cyber Security Act 2024 Compliance Checklist](/artifacts/apac/australia-cyber-security-act/checklist.md): Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting. - [Australia Cyber Security Act 2024 Compliance Guide | Implementation Playbook](/artifacts/apac/australia-cyber-security-act/compliance.md): A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements. - [Australia Cyber Security Act 2024 Compliance Templates | Statement of Compliance, Ransomware Report, Evidence Pack, Vulnerability Disclosure, Support Period](/artifacts/apac/australia-cyber-security-act/templates.md): Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field. - [Australia Cyber Security Act 2024 Deadlines and Compliance Calendar | Commencement Dates](/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar.md): Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent. - [Australia Cyber Security Act 2024 FAQ | Frequently Asked Questions](/artifacts/apac/australia-cyber-security-act/faq.md): Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024. - [Australia Cyber Security Act 2024 Requirements | Smart Device and Ransomware Reporting Obligations](/artifacts/apac/australia-cyber-security-act/requirements.md): Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure. - [Australia Cyber Security Act 2024 Timeline and Commencement Dates | Full Schedule](/artifacts/apac/australia-cyber-security-act/timeline-and-commencement.md): Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024. - [Australia Cyber Security Act 2024 vs EU Cyber Resilience Act | Full CRA Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act.md): Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements. - [Australia Cyber Security Act 2024 vs UK PSTI Act | Product Security Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act.md): Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements. - [Australia Smart Device Compliance Checklist | Cyber Security Act 2024 | Sorena](/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist.md): Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure. - [Penalties and fines | Australia Cyber Security Act 2024 | 60 Penalty Units, Smart Device Enforcement, Ransomware Reporting](/artifacts/apac/australia-cyber-security-act/penalties-and-fines.md): Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals. - [Ransomware Payment Reporting in 72 Hours | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours.md): Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. - [Scope and Definitions | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/scope-and-definitions.md): Complete guide to the Australia Cyber Security Act 2024 scope and definitions. - [Smart device security standards | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/smart-device-security-standards.md): Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping --- --- title: "Australia Cyber Security Act 2024 Compliance Templates" canonical_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/templates" source_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/templates" author: "Sorena AI" description: "Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "Australia Cyber Security Act 2024 compliance templates" - "statement of compliance template Australia Section 9" - "ransomware payment report template Australia Section 7" - "smart device evidence pack template" - "product classification register template" - "vulnerability disclosure page template" - "support period publication template" - "APAC compliance templates" - "Schedule 1 security standard requirements" - "72 hour ransomware reporting template" - "statement of compliance template Australia" - "ransomware payment report template Australia" - "APAC cyber compliance templates" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Australia Cyber Security Act 2024 Compliance Templates Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field. *Artifact Guide* *APAC* ## Australia Cyber Security Act 2024 Compliance Templates Six Australia Cyber Security Act 2024 compliance templates covering every required field from the Act, the Cyber Security (Security Standards for Smart Devices) Rules 2025, and the Cyber Security (Ransomware Payment Reporting) Rules 2025. Each Australia Cyber Security Act 2024 compliance template on this page lists every mandatory field, identifies the legal source, and provides practical guidance on how to fill every entry so your team can produce accurate records on the first attempt. A useful Australia Cyber Security Act 2024 compliance template does two things at once: it removes friction from the compliance process and it enforces accuracy by listing every legally required field. This page provides six Australia Cyber Security Act 2024 compliance templates that together cover the full lifecycle of obligations under the Act and its subsidiary Rules. The first Australia Cyber Security Act 2024 compliance template addresses the statement of compliance required for smart devices under Section 9 of the Smart Devices Rules. The second covers the ransomware payment report required after a ransomware payment under Section 7 of the Ransomware Reporting Rules. The third provides the evidence pack structure that supports each statement of compliance. The fourth establishes the product classification register that tracks scope decisions across all product lines. The fifth sets out the vulnerability disclosure page that satisfies the security issue reporting requirement under Schedule 1 Clause 3. The sixth covers the support period publication that satisfies the defined support period requirement under Schedule 1 Clause 4. Each Australia Cyber Security Act 2024 compliance template below lists every required field, identifies the exact section or clause of the law, and provides practical guidance on how to fill the field correctly. ## Statement of compliance template (Smart Devices Rules Section 9) The statement of compliance is the most formally prescribed document in the Australia Cyber Security Act 2024 compliance templates set. Section 9 of the Cyber Security (Security Standards for Smart Devices) Rules 2025 lists exactly seven categories of information that every statement must contain. Section 16 of the Act requires manufacturers to provide the statement and suppliers to supply the product with the statement. Both manufacturers and suppliers must retain copies for five years under Section 10 of the Rules. The statement must be prepared by, or on behalf of, the manufacturer of the product. Responsible entities operating across jurisdictions with similar frameworks, such as the UK Product Security and Telecommunications Infrastructure Regulations 2023, can use the same statement for the Australian market as long as all Section 9 requirements are met. Statements of compliance are not required to be provided with the product at the point of sale, but the regulator may request them at any time to verify compliance. The statement is for the use of the regulator to ensure the responsible entity has met its obligations under the Act and the Rules. Below is every required field from Section 9(3) of the Smart Devices Rules, together with practical guidance on how to fill each field in your Australia Cyber Security Act 2024 compliance templates. - Field 1 as required by Section 9(3)(a): Product type and batch identifier. Record the formal product type name and the batch identifier that uniquely identifies the specific group of products manufactured or processed together. Use the same product type name that appears on packaging and marketing materials. The batch identifier should allow traceability back to manufacturing records for the specific production run. - Field 2 as required by Section 9(3)(b)(i): Name and address of the manufacturer of the product. Provide the full legal entity name and registered business address of the manufacturer. If the manufacturer is a sole trader, note that the personal information of the individual (name and address) will appear on the statement. The Explanatory Statement to the Rules acknowledges this privacy limitation as reasonable and necessary to ensure accountability for compliance with the security standard. - Field 3 as required by Section 9(3)(b)(ii): Name and address of an authorised representative of the manufacturer. Provide the full legal entity name and registered business address of the authorised representative designated by the manufacturer to act on their behalf. If the manufacturer is based outside Australia, this field identifies the representative who can receive regulatory correspondence. - Field 4 as required by Section 9(3)(b)(iii): Name and address of each of the manufacturer's other authorised representatives that are in Australia. List every additional authorised representative located in Australia with the full legal entity name and address. If there are no additional authorised representatives in Australia, state that fact explicitly so the field is not left ambiguous. - Field 5 as required by Section 9(3)(c): Declaration that the statement has been prepared by, or on behalf of, the manufacturer of the product. Include a declaration in controlled wording such as: 'This statement of compliance has been prepared by [or on behalf of] [manufacturer name].' Keep the wording consistent across all products to reduce the risk of accidental omission. - Field 6 as required by Section 9(3)(d): Declaration that, in the opinion of the manufacturer, (i) the product has been manufactured in compliance with the requirements of the security standard in Part 1 of Schedule 1 to the Rules, and (ii) the manufacturer has complied with any other obligations relating to the product in the security standard. This is a dual declaration. The first part covers product manufacturing compliance. The second part covers the manufacturer's process obligations including the obligation to publish security issue reporting information under Schedule 1 Clause 3 and the obligation to publish the defined support period under Schedule 1 Clause 4. - Field 7 as required by Section 9(3)(e): The defined support period for the product at the date the statement of compliance is issued. State the defined support period as a period of time with an explicit end date. For example, write 'Security updates will be provided until no later than 30 June 2031.' The end date format recommended by the Explanatory Statement is a specific calendar date. The manufacturer must not shorten this period after publication under Schedule 1 Clause 4(4). - Field 8 as required by Section 9(3)(f): The signature, name, and function of the signatory of the manufacturer. Record the handwritten or electronic signature, the full name of the signatory, and the job function or title of the signatory within the manufacturer organisation. The signatory should have authority to bind the manufacturer. The Explanatory Statement notes that including signatory details provides the regulator with a point of contact if there are concerns with the statement. - Field 9 as required by Section 9(3)(g): The place and date of issue of the statement of compliance. Record the city and country where the statement was signed and the calendar date of issue. Use an unambiguous date format such as DD Month YYYY to prevent confusion between date conventions. - Document control fields (operational best practice for your Australia Cyber Security Act 2024 compliance templates). Although not required by Section 9, add an internal document number, a revision history table, and a storage location reference. These fields make it easier to demonstrate version control during the five year retention period under Section 10 and to manage updates when the defined support period is extended. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep Australia Cyber Security Act 2024 Compliance Templates in one governed evidence system SSOT can take Australia Cyber Security Act 2024 Compliance Templates from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on Australia Cyber Security Act 2024 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for Australia Cyber Security Act 2024 Compliance Templates](/solutions/ssot.md): Start from Australia Cyber Security Act 2024 Compliance Templates and keep documents, evidence, and control records in one governed system. - [Talk through Australia Cyber Security Act 2024](/contact.md): Review your current process, evidence gaps, and next steps for Australia Cyber Security Act 2024 Compliance Templates. ## Ransomware payment report template (Ransomware Reporting Rules Section 7) Part 3 of the Australia Cyber Security Act 2024 requires a reporting business entity to give the designated Commonwealth body a ransomware payment report within 72 hours of making the payment or becoming aware that the payment was made. Section 7 of the Cyber Security (Ransomware Payment Reporting) Rules 2025 prescribes exactly what information the report must contain. Information is only required to the extent that the reporting business entity knows or is able, by reasonable search or enquiry, to find out within the 72 hour window. A reporting business entity is one that is either a responsible entity for a critical infrastructure asset under Part 2B of the Security of Critical Infrastructure Act 2018 or is carrying on a business in Australia with annual turnover exceeding $3 million in the previous financial year under Section 6 of the Rules. If the business operated for only part of the previous financial year, the threshold is prorated using the formula: $3 million multiplied by the number of days in the part divided by the number of days in the previous financial year. The report must be given in the form approved by the Secretary (if any) and in the manner prescribed by the rules under Section 27(4) of the Act. Below is every required field from Section 7 of the Ransomware Reporting Rules, mapped to the corresponding paragraph of Section 27(2) of the Act, together with practical guidance for your Australia Cyber Security Act 2024 compliance templates. Preparing this template in advance is critical because 72 hours is too short to build a reporting process during an active incident. - Field group A: Reporting business entity contact and business details, required by Section 7(2) and mapping to Section 27(2)(a) of the Act. The Rules require the entity's ABN (if any) and address. In your Australia Cyber Security Act 2024 compliance templates, also capture the entity name, primary contact person name, phone number, and email address. These fields should be filled in advance and reviewed quarterly so they are ready during a crisis. - Field group B: Other paying entity contact and business details, required by Section 7(3) and mapping to Section 27(2)(b) of the Act. If another entity made the ransomware payment on behalf of the reporting business entity, the Rules require that other entity's ABN (if any) and address. If the reporting business entity made the payment directly, record that fact and mark this section as not applicable. - Field group C1: Date and time when the incident occurred or is estimated to have occurred, required by Section 7(4)(a) and mapping to Section 27(2)(c) of the Act. Provide the best available estimate of when the cyber security incident began. Use UTC timestamps where possible and note any uncertainty in the estimate. - Field group C2: Date and time when the reporting business entity became aware of the incident, required by Section 7(4)(b). Record the exact date and time, or the best estimate, when the entity first became aware that a cyber security incident had occurred. - Field group C3: Impact of the incident on the reporting business entity's infrastructure, required by Section 7(4)(c). Describe which systems, networks, or infrastructure components were affected. Include the number and type of endpoints compromised, the operational impact, and any service disruptions. - Field group C4: Impact of the incident on the reporting business entity's customers, required by Section 7(4)(d). Describe how customers were affected. Include estimates of the number of customers impacted, the types of customer data potentially exposed, and any service outages visible to customers. - Field group C5: Ransomware or malware variants used, required by Section 7(4)(e). Identify which variants of ransomware or other malware were used in the incident. If the variant is unknown at the time of reporting, state that fact and provide any available indicators of compromise such as file hashes or network signatures. - Field group C6: Vulnerabilities exploited in the reporting business entity's system, required by Section 7(4)(f). Identify which vulnerabilities were exploited. Use CVE identifiers where available. If the vulnerability is not yet identified, describe the attack vector to the extent known within the 72 hour window. - Field group C7: Information to assist response, mitigation, or resolution by a Commonwealth body or State body, required by Section 7(4)(g). Provide any additional information that could assist a Commonwealth body or State body in responding to, mitigating, or resolving the cyber security incident. This may include indicators of compromise, threat actor tactics, techniques, and procedures, or network diagrams. Note that ransomware payment reports may only be used or disclosed for permitted purposes under Section 29 of the Act, and the information must not be disclosed to a State body unless a Minister of the State or Territory has consented under Section 11 of the Act. - Field group D1: Amount or quantum of the ransom demanded, required by Section 7(5)(a) and mapping to Section 27(2)(d) of the Act. Record the amount of the ransomware payment demanded. If the demand was for a benefit that is not monetary, provide a description of that benefit. Include the currency and any cryptocurrency wallet addresses if applicable. - Field group D2: Method of provision demanded by the extorting entity, required by Section 7(5)(b). Record the method of payment demanded, for example cryptocurrency transfer, wire transfer, or another mechanism. - Field group E1: Amount or quantum of the payment actually made, required by Section 7(6)(a) and mapping to Section 27(2)(e) of the Act. Record the amount of the ransomware payment actually provided. If the payment was a benefit that is not monetary, describe it. Include transaction identifiers and cryptocurrency wallet addresses where available. - Field group E2: Method of provision of the payment, required by Section 7(6)(b). Record how the payment was actually made, including the payment platform, transaction reference, and date and time of the transfer. - Field group F1: Nature and timing of communications with the extorting entity, required by Section 7(7)(a) and mapping to Section 27(2)(f) of the Act. Record the nature of each communication (email, chat, voice, or other channel) and the date and time it occurred. - Field group F2: Brief description of those communications, required by Section 7(7)(b). Provide a factual summary of each communication between the reporting business entity and the extorting entity. Keep descriptions brief as required by the Rules. - Field group F3: Brief description of any negotiations before the payment, required by Section 7(7)(c). Provide a factual summary of any negotiations that took place before the ransomware payment was made, including any changes to the original demand amount or method of provision. - Submission method and timestamp (operational best practice for your Australia Cyber Security Act 2024 compliance templates). Record the method used to submit the report to the designated Commonwealth body, the exact submission date and time, the name of the person who authorised the submission, and retain a copy of the submitted report. Section 27(4) of the Act requires the report to be given in the form approved by the Secretary if one has been issued, so check for an approved form before submission. ## Smart device evidence pack template (operational support for the statement of compliance) The statement of compliance declares that the product meets the security standard, but the evidence pack is what proves it. The evidence pack is the Australia Cyber Security Act 2024 compliance template that collects all supporting evidence for a single product model or controlled version. Build one evidence pack per product model or per controlled firmware version. The pack should contain test results, screenshots, process records, and approval sheets that support each requirement of the security standard in Part 1 of Schedule 1 to the Smart Devices Rules 2025. During an examination under Section 23 of the Act, the Secretary may request the manufacturer or supplier to provide the product and the statement of compliance for the purposes of an audit. The evidence pack will be the foundation of your response to any such request. Below are the evidence categories to include in your Australia Cyber Security Act 2024 compliance templates evidence pack, mapped to the relevant Schedule 1 clauses. - Product identity record. Record the product type name, model number, internal product code, hardware revision, firmware version, batch identifiers covered by this evidence pack, manufacturing location, and the date range of manufacture. These details must match the product type and batch identifier recorded in Field 1 of the statement of compliance under Section 9(3)(a). - Password design evidence supporting Schedule 1 Clause 2. For each password category identified in Clause 2(1), document whether the password is unique per product under Clause 2(2)(a) or defined by the user under Clause 2(2)(b). The three password categories are: hardware of the product when the product is not in the factory default state (Clause 2(1)(a)), software that is installed on the product at the point of supply when the product is not in the factory default state (Clause 2(1)(b)), and software that is not installed at supply but must be installed for all of the manufacturer's intended purposes (Clause 2(1)(c)). If passwords are unique per product, provide evidence that they are not based on incremental counters (Clause 2(3)(a)), not based on or derived from publicly available information (Clause 2(3)(b)), not based on or derived from unique product identifiers such as serial numbers unless encrypted or hashed using a method accepted as good industry practice (Clause 2(3)(c)), and not otherwise guessable in a manner unacceptable as part of good industry practice (Clause 2(3)(d)). Include cryptographic design documents, test reports showing password uniqueness across a sample batch, and penetration test results. - Security issue reporting page evidence supporting Schedule 1 Clause 3. Capture a dated screenshot or PDF archive of the published page that provides at least one point of contact for reporting security issues (Clause 3(2)(a)). Confirm the page states when a reporter will receive an acknowledgement of receipt (Clause 3(2)(b)(i)) and when they will receive status updates until resolution (Clause 3(2)(b)(ii)). Verify that the published information meets the quality requirements: accessible, clear, and transparent (Clause 3(3)(a)), available without prior request (Clause 3(3)(b)), published in English (Clause 3(3)(c)), free of charge (Clause 3(3)(d)), and does not require the provision of personal information to access (Clause 3(3)(e)). Record the URL, the capture date, and the name of the person who verified compliance. - Defined support period publication evidence supporting Schedule 1 Clause 4. Capture a dated screenshot or PDF archive of each location where the defined support period is published. The period must be expressed as a period of time with an explicit end date under Clause 4(3), for example 'Security updates will be provided until no later than 30 June 2031.' Verify that the publication meets the quality requirements: accessible, clear, transparent, available without prior request, in English, free of charge, does not require personal information, and is understandable by a reader without prior technical knowledge (Clause 4(6)). If the manufacturer offers to supply the product on its own website or another website under its control, capture evidence that the support period is prominently published with information intended to inform consumer purchasing decisions and is published alongside or given equal prominence to the main characteristics of the product (Clause 4(7)). This may require screenshots from multiple locations including product information pages, product purchase pages, and product comparison pages. Record each URL, the support period stated, the end date, and the verification date. - Security update delivery evidence supporting the ongoing obligation under Schedule 1 Clause 4. Document how security updates are delivered during the defined support period. Include release notes for each security update issued, the date the update was made available, and the delivery mechanism. This evidence demonstrates that the manufacturer is meeting the ongoing obligation to provide security updates as far as practicable and in line with good industry practice. - Final approval sheet. Record the name and function of the person who reviewed the evidence pack, the date of approval, the assessment conclusion for each clause of the security standard (pass or fail with reasons), and the document reference number of the statement of compliance that was issued on the basis of this evidence pack. This sheet closes the loop between evidence and declaration in your Australia Cyber Security Act 2024 compliance templates. ## Product classification register template (scope tracking for all product lines and entities) The product classification register is the Australia Cyber Security Act 2024 compliance template that records the scope decision for every product and legal entity. The register tracks which products are relevant connectable products under Section 13 of the Act, which fall within the specified class of consumer grade products under Section 8 of the Smart Devices Rules, which are exempt under Section 8(1)(b), and which trigger the obligation to prepare a statement of compliance under Section 16 of the Act. The register also captures the turnover and critical infrastructure assessment for ransomware reporting obligations under Part 3 of the Act. Without a register, organisations risk missing products that enter scope when hardware revisions change or when new software is added. Below are the fields to include in your product classification register as part of your Australia Cyber Security Act 2024 compliance templates. - Legal entity name, ABN, and business address. Identify the entity that manufactures or supplies the product. This field also supports the ransomware reporting threshold assessment because the turnover threshold under Section 6 of the Ransomware Reporting Rules is assessed at the entity level. - Product model name, internal product code, and current firmware version. Use the same naming convention that appears on packaging and on the statement of compliance. - Relevant connectable product assessment under Section 13 of the Act. Record whether the product can directly or indirectly connect to the internet. If yes, the product is a relevant connectable product and further classification is required. - Consumer grade classification under Section 8(1)(a) of the Smart Devices Rules. Record whether the product is intended by the manufacturer to be used, or is of a kind likely to be used, for personal, domestic, or household consumption under the Australian Consumer Law. Section 6 of the Rules defines consumer by reference to Section 3 of the Australian Consumer Law. If the product would be taken to have been acquired as a consumer under the ACL, it falls within the specified class. - Exemption assessment under Section 8(1)(b) of the Smart Devices Rules. Record whether the product falls into any of the six excluded categories: a desktop computer, a laptop, a tablet computer, a smartphone, a therapeutic good within the meaning of the Therapeutic Goods Act 1989, a road vehicle within the meaning of the Road Vehicle Standards Act 2018, or a road vehicle component within the meaning of the Road Vehicle Standards Act 2018. If the product matches an exemption, record the exemption category and the reasoning. The Explanatory Statement notes that these exemptions exist because of existing regulatory frameworks or because of the complexity of component supply chains. - Specified circumstance assessment under Section 8(2) of the Smart Devices Rules. Record whether the product could reasonably be expected to be acquired in Australia by a consumer. This is the circumstance that triggers the security standard in Part 1 of Schedule 1. - Final scope conclusion. Record whether the product is in scope or out of scope for the security standard. If in scope, record the date when the statement of compliance must be prepared and the date when compliance with the security standard is required. Part 2 and Schedule 1 of the Smart Devices Rules commenced 12 months after registration, which is 4 March 2026. - Ransomware reporting applicability assessment. For each legal entity, record whether the entity is a responsible entity for a critical infrastructure asset under Part 2B of the Security of Critical Infrastructure Act 2018 or whether it carries on a business in Australia with annual turnover exceeding the $3 million threshold under Section 6 of the Ransomware Reporting Rules. If the entity carried on business for only part of the previous financial year, calculate the prorated threshold using the formula in Section 6(2) of the Rules. - Review trigger and next reassessment date. Define the events that would trigger a reassessment of the classification, such as a new product release, a hardware revision, a change in supply market, a change in legal entity structure, or a change in annual turnover. Set a calendar date for the next scheduled review. This field ensures the register stays current as your Australia Cyber Security Act 2024 compliance templates are updated over time. ## Vulnerability disclosure page template (Schedule 1 Clause 3 of the Smart Devices Rules) Schedule 1 Clause 3 of the Smart Devices Rules requires manufacturers to publish information on how a person can report security issues relating to the product. This publication requirement is one of the three core obligations in the security standard and is referenced in the compliance declaration within the statement of compliance (Section 9(3)(d)(ii)). A properly designed vulnerability disclosure page satisfies the legal requirement and also reduces the risk of uncoordinated public disclosure of security issues. The page must be accessible without prior request, published in English, free of charge, and must not require the provision of personal information for a person to access the reporting information. This template is a critical component of the Australia Cyber Security Act 2024 compliance templates set because the manufacturer's compliance with this requirement is part of the dual declaration in the statement of compliance. Below are the required and recommended fields for your vulnerability disclosure page template as part of your Australia Cyber Security Act 2024 compliance templates. - Point of contact for reporting security issues, required by Schedule 1 Clause 3(2)(a). Publish at least one point of contact that allows any person to report security issues to the manufacturer. This could be a dedicated security email address (for example security@manufacturer.example), a web form, or both. The contact must cover security issues relating to the hardware of the product (Clause 3(1)(a)), software that is installed on the product at the point of supply (Clause 3(1)(b)), software that must be installed for the manufacturer's intended purposes (Clause 3(1)(c)), and software used for or in connection with any of the manufacturer's intended purposes (Clause 3(1)(d)). - Acknowledgement timeline, required by Schedule 1 Clause 3(2)(b)(i). State when a person who reports a security issue will receive an acknowledgement of receipt. Publish a specific timeframe, for example 'We will acknowledge receipt of your report within 5 business days.' The Explanatory Statement to the Rules confirms that the manufacturer must ensure the person receives an acknowledgement. - Status update policy, required by Schedule 1 Clause 3(2)(b)(ii). State when and how the reporter will receive status updates until the resolution of the reported security issues. Publish a specific cadence, for example 'We will provide status updates at least every 30 calendar days until the issue is resolved.' - Accessibility requirement, required by Schedule 1 Clause 3(3)(a). The published information must be accessible, clear, and transparent. Use plain language, avoid jargon, and ensure the page is reachable from the main website navigation or product support section. - Availability without prior request, required by Schedule 1 Clause 3(3)(b). The page must be available to any person without requiring a prior request. Do not place the reporting information behind a login, an account registration, or a support ticket. - English language requirement, required by Schedule 1 Clause 3(3)(c). The information must be published in English. Additional languages may be provided but the English version must be present. - Free of charge requirement, required by Schedule 1 Clause 3(3)(d). The information must be available free of charge. Do not require a purchase, subscription, or payment to access the reporting page. - No personal information requirement for access, required by Schedule 1 Clause 3(3)(e). Accessing the published reporting information must not require the person to provide personal information. Note that the Explanatory Statement clarifies the manufacturer may request reasonable contact information (such as an email address) from a person who actually submits a report, for the purpose of providing acknowledgement and status updates. Any collection of personal information remains subject to the Privacy Act 1988. - Covered products (operational best practice). List the product models and product families covered by this disclosure page. If a single page covers multiple products, group them by product family for clarity. - Safe harbor statement (operational best practice). Although not required by the Act, publishing a safe harbor statement encourages security researchers to report issues by assuring them that the manufacturer will not pursue legal action against researchers who act in good faith and follow responsible disclosure practices. - Page review and evidence capture schedule (operational best practice for your Australia Cyber Security Act 2024 compliance templates). Record the URL of the published page, the date it was last reviewed, and the next scheduled review date. Capture a dated screenshot or PDF archive for the evidence pack each time the page is created, reviewed, or updated. ## Support period publication template (Schedule 1 Clause 4 of the Smart Devices Rules) Schedule 1 Clause 4 of the Smart Devices Rules requires manufacturers to publish the defined support period for security updates. The defined support period must be expressed as a period of time with an explicit end date under Clause 4(3) and must not be shortened after publication under Clause 4(4), although it may be extended under Clause 4(5). If the manufacturer offers to supply the product on its own website or another website under its control, the support period must be prominently published alongside information intended to inform consumer purchasing decisions and alongside the main characteristics of the product under Clause 4(7). A complete support period publication template is a required part of any Australia Cyber Security Act 2024 compliance templates set because the defined support period also appears as Field 7 of the statement of compliance under Section 9(3)(e). The Explanatory Statement to the Rules provides detailed guidance on the prominence requirements. Product information pages, product purchase pages, and product comparison pages are examples of locations where the support period is likely required. Generic press releases, support articles, and accessory purchase pages are not likely to contain information intended to inform consumer purchasing decisions. Below are the required and recommended fields for your support period publication template as part of your Australia Cyber Security Act 2024 compliance templates. - Product model name and identifier. Use the same naming convention as the statement of compliance and the evidence pack. Include the hardware and software components covered by the defined support period as described in Schedule 1 Clause 4(1): hardware capable of receiving security updates (Clause 4(1)(a)), software installed at the point of supply that is capable of receiving security updates (Clause 4(1)(b)), required installable software capable of receiving security updates (Clause 4(1)(c)), and software developed by or on behalf of the manufacturer that is capable of receiving security updates and used for any of the manufacturer's intended purposes (Clause 4(1)(d)). - Defined support period statement with explicit end date, required by Schedule 1 Clause 4(1) and Clause 4(3). State the period and the end date. For example, 'Security updates for [product name] will be provided until no later than 30 June 2031.' The Explanatory Statement specifies that the period should include a fixed end date rather than an open ended period of time. - Original publication date. Record the date the defined support period was first published. This date anchors the rule in Clause 4(4) that the manufacturer must not shorten the defined support period after publication. - Accessibility and quality requirements, required by Schedule 1 Clause 4(6). The published support period must be accessible, clear, and transparent (Clause 4(6)(a)). It must be made available without prior request (Clause 4(6)(b)(i)), in English (Clause 4(6)(b)(ii)), free of charge (Clause 4(6)(b)(iii)), without requiring personal information (Clause 4(6)(b)(iv)), and in a way that is understandable by a reader without prior technical knowledge (Clause 4(6)(b)(v)). Confirm compliance with each of these six requirements. - Website prominence requirements, required by Schedule 1 Clause 4(7) if the manufacturer offers to supply the product on its website or another website under its control. The defined support period must be prominently published with other information on the website that is intended to inform consumer decisions to acquire the product. The defined support period must also be published alongside or given equal prominence to the main characteristics of the product. This may require the support period to appear in multiple locations on the website, for example the product information page, the product purchase page, and any product comparison page. - Extension publication record, required by Schedule 1 Clause 4(5). If the manufacturer extends the defined support period, the new period must be published as soon as is practicable. Record the original period and end date, the extended period and new end date, the date the extension was published, and the URLs where the updated period was published. - Publication locations and URLs. List every URL where the support period is published. For each URL, record the date the content was last verified and capture a dated screenshot or PDF archive for the evidence pack. - Statement of compliance cross reference (operational best practice for your Australia Cyber Security Act 2024 compliance templates). Record the document reference number of the statement of compliance that contains the same defined support period in Field 7 under Section 9(3)(e). This cross reference ensures consistency between the published page and the regulatory statement. Any discrepancy between the two would undermine the dual declaration in the statement of compliance. ## How to implement Australia Cyber Security Act 2024 compliance templates so teams use them consistently Australia Cyber Security Act 2024 compliance templates only reduce risk if teams actually use them for every product and every incident. The most common failure mode is optional adoption: one team uses the template while another team writes a document from scratch that misses required fields. The solution is to embed the templates into your tooling and workflow gates so that no statement, report, or evidence pack can be completed without filling every required field. Below are practical steps for rolling out Australia Cyber Security Act 2024 compliance templates across your organisation. - Convert each Australia Cyber Security Act 2024 compliance template into a structured digital form with required fields, validation rules, and selection menus for enumerated values. Use a document management system or GRC platform rather than standalone word processing files. - Require a completed evidence pack link before the statement of compliance can be approved. The approval workflow should block signature until the evidence pack contains a passing assessment for every clause of the security standard in Schedule 1. - Fill in the ransomware payment report template with entity details (ABN, address, contact person) now, before any incident occurs. During a 72 hour reporting window, teams should spend their time on incident specific fields, not on looking up business details. - Schedule quarterly reviews of the product classification register. Use the review trigger field to flag products that need reassessment because of hardware revisions, new software integrations, changes in supply market, or changes in annual turnover. - Store all Australia Cyber Security Act 2024 compliance templates, completed records, and evidence captures in a single system of record with retention rules set to at least five years for statements of compliance under Section 10 of the Smart Devices Rules. Set a conservative baseline of at least seven years for ransomware payment reports. - Train every team member who touches an Australia Cyber Security Act 2024 compliance template on the purpose of each field and the legal source of the requirement. A trained team fills fields accurately on the first attempt, which reduces review cycles and the risk of incomplete submissions. - Monitor the Federal Register of Legislation at least quarterly for amendments to the Cyber Security Act 2024 (C2024A00098), the Smart Devices Rules (F2025L00276), and the Ransomware Reporting Rules (F2025L00278). Update all Australia Cyber Security Act 2024 compliance templates when the law changes. The Act includes a PJCIS statutory review under Section 88 beginning in December 2027, which may lead to amendments. ## Primary sources - [Cyber Security Act 2024 (Australia) official text](https://www.legislation.gov.au/C2024A00098/latest/text?ref=sorena.io) - Primary legislation establishing the statement of compliance obligation (Section 16), the ransomware payment reporting obligation (Section 27), the examination power (Section 23), the safe harbour protections (Sections 28 through 32), and the definitions of relevant connectable product, reporting business entity, and ransomware payment. Authoritative foundation for all Australia Cyber Security Act 2024 compliance templates on this page. - [Cyber Security (Security Standards for Smart Devices) Rules 2025 (F2025L00276)](https://www.legislation.gov.au/F2025L00276/asmade/text?ref=sorena.io) - Source for the statement of compliance required fields (Section 9), the five year retention period (Section 10), the consumer grade product scope and exemptions (Section 8), and the three Schedule 1 security standard requirements: password compliance (Clause 2), security issue reporting (Clause 3), and defined support period publication (Clause 4). Authorised Version registered 4 March 2025. - [Cyber Security (Ransomware Payment Reporting) Rules 2025 (F2025L00278)](https://www.legislation.gov.au/F2025L00278/asmade/text?ref=sorena.io) - Source for the $3 million annual turnover threshold (Section 6), the prorated threshold formula for partial year operations (Section 6(2)), and the detailed ransomware payment report field requirements (Section 7) including entity details, incident information, demand information, payment information, and communications with the extorting entity. Authorised Version registered 3 March 2025. - [Explanatory Statement for the Cyber Security (Security Standards for Smart Devices) Rules 2025](https://www.legislation.gov.au/F2025L00276/asmade/explanatory%20statement/text?ref=sorena.io) - Interpretive guidance on the statement of compliance requirements, the scope of consumer grade products, the six exemption categories, the website prominence requirements for defined support period publication, the privacy implications for sole trader manufacturers, and the alignment with UK PSTI Act requirements. Source for the Australia Cyber Security Act 2024 compliance templates design rationale. ## Related Topic Guides - [Australia Cyber Security Act 2024 Applicability Test | Who Must Comply](/artifacts/apac/australia-cyber-security-act/applicability-test.md): Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations. - [Australia Cyber Security Act 2024 Compliance Checklist](/artifacts/apac/australia-cyber-security-act/checklist.md): Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting. - [Australia Cyber Security Act 2024 Compliance Guide | Implementation Playbook](/artifacts/apac/australia-cyber-security-act/compliance.md): A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements. - [Australia Cyber Security Act 2024 Deadlines and Compliance Calendar | Commencement Dates](/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar.md): Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent. - [Australia Cyber Security Act 2024 FAQ | Frequently Asked Questions](/artifacts/apac/australia-cyber-security-act/faq.md): Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024. - [Australia Cyber Security Act 2024 Requirements | Smart Device and Ransomware Reporting Obligations](/artifacts/apac/australia-cyber-security-act/requirements.md): Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure. - [Australia Cyber Security Act 2024 Timeline and Commencement Dates | Full Schedule](/artifacts/apac/australia-cyber-security-act/timeline-and-commencement.md): Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024. - [Australia Cyber Security Act 2024 vs EU Cyber Resilience Act | Full CRA Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act.md): Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements. - [Australia Cyber Security Act 2024 vs UK PSTI Act | Product Security Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act.md): Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements. - [Australia Smart Device Compliance Checklist | Cyber Security Act 2024 | Sorena](/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist.md): Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure. - [Penalties and fines | Australia Cyber Security Act 2024 | 60 Penalty Units, Smart Device Enforcement, Ransomware Reporting](/artifacts/apac/australia-cyber-security-act/penalties-and-fines.md): Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals. - [Ransomware Payment Reporting in 72 Hours | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours.md): Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. - [Scope and Definitions | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/scope-and-definitions.md): Complete guide to the Australia Cyber Security Act 2024 scope and definitions. - [Smart device security standards | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/smart-device-security-standards.md): Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2. - [Statement of Compliance and Recordkeeping | Australia Cyber Security Act 2024 | Section 9, Section 10, 5 Year Retention](/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping.md): Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/australia-cyber-security-act/templates --- --- title: "Australia Cyber Security Act 2024 Timeline and Commencement Dates" canonical_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/timeline-and-commencement" source_url: "https://www.sorena.io/artifacts/apac/australia-cyber-security-act/timeline-and-commencement" author: "Sorena AI" description: "Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "Australia Cyber Security Act 2024 timeline" - "Australia Cyber Security Act 2024 commencement dates" - "Australia Cyber Security Act commencement schedule" - "smart device rules commencement Australia 4 March 2026" - "ransomware reporting commencement Australia 29 May 2025" - "Cyber Incident Review Board Rules commencement" - "Part 2 commencement backstop 29 November 2025" - "Part 3 commencement backstop 29 May 2025" - "Part 5 commencement backstop 29 May 2025" - "PJCIS statutory review 1 December 2027" - "Royal Assent 29 November 2024" - "F2025L00276 smart devices rules" - "F2025L00278 ransomware payment reporting rules" - "F2025L00277 incident review board rules" - "APAC cyber compliance timeline" - "Australia cyber regulation implementation" - "Australia Cyber Security Act commencement dates" - "smart device rules commencement 4 March 2026" - "ransomware reporting commencement 29 May 2025" - "PJCIS statutory review 2027" - "Australia cyber security regulation schedule" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Australia Cyber Security Act 2024 Timeline and Commencement Dates Complete Australia Cyber Security Act 2024 timeline with every commencement date from Royal Assent on 29 November 2024. *Artifact Guide* *APAC* ## Australia Cyber Security Act 2024 Timeline and commencement dates The Australia Cyber Security Act 2024 uses a staged commencement model across seven Parts, three subordinate rule sets, and a future statutory review. This guide maps every commencement date, explains the legal trigger for each, and identifies what each milestone requires from product, compliance, and incident response teams. Dates span from 30 November 2024 (Royal Assent plus one day) through 4 March 2026 (smart device operative standard) and out to 1 December 2027 when the Parliamentary Joint Committee on Intelligence and Security must begin its statutory review of the Act. The Australia Cyber Security Act 2024 (No. 98, 2024) received Royal Assent on 29 November 2024, but its seven Parts did not all commence on the same day. The commencement table in section 2 of the Act splits the Australia Cyber Security Act 2024 timeline into three waves: Parts 1, 4, 6, and 7 commenced immediately on 30 November 2024; Parts 3 and 5 had a six month backstop landing on 29 May 2025; and Part 2 had a twelve month backstop landing on 29 November 2025. Three sets of subordinate rules registered in March 2025 add further commencement dates and conditions, with the most significant being 4 March 2026 when the operative smart device security standard became enforceable. Section 88 of the Act then requires the Parliamentary Joint Committee on Intelligence and Security to begin a statutory review after 1 December 2027. This guide walks through every commencement date in the Australia Cyber Security Act 2024 timeline, explains the legal mechanism behind each trigger, and provides practical readiness guidance for each milestone. ## Royal Assent and immediate commencement on 30 November 2024 The Australia Cyber Security Act 2024 received Royal Assent on 29 November 2024. According to the commencement table in section 2 of the Act, Part 1 and anything not elsewhere covered commenced the day after Royal Assent, which was 30 November 2024. Part 4 (Coordination of significant cyber security incidents) also commenced on 30 November 2024 under the same trigger. Parts 6 and 7, which cover miscellaneous provisions and consequential amendments, likewise commenced on 30 November 2024. This means that from 30 November 2024 onward, the definitions in Part 1 of the Australia Cyber Security Act 2024 have been operative. Section 8 definitions, the meaning of cyber security incident under section 9, and the meaning of permitted cyber security purpose under section 10 all became binding from that date. Part 4 activated the voluntary information sharing framework with the National Cyber Security Coordinator, including the information protection provisions in sections 38 through 43. For compliance teams, the immediate commencement of Part 4 meant that any organisation experiencing a significant cyber security incident from 30 November 2024 onward could voluntarily share information with the National Cyber Security Coordinator and receive the statutory protections against secondary use and disclosure set out in Division 3 of Part 4. The simultaneous commencement of Part 6 on 30 November 2024 also activated the full enforcement toolkit, including monitoring powers under section 80, investigation powers under section 81, civil penalty provisions under section 79, enforceable undertakings, injunctions, and infringement notices under section 82. These enforcement mechanisms apply across the Act, so they were ready to support any obligation that commenced later in the Australia Cyber Security Act 2024 timeline. - 29 November 2024: Royal Assent date for the Australia Cyber Security Act 2024 (No. 98, 2024) - 30 November 2024: Part 1 (Preliminary), Part 4 (Significant incident coordination), Parts 6 and 7 (Miscellaneous and consequential amendments) all commenced - Section 8 definitions became operative on 30 November 2024, establishing the legal vocabulary for all subsequent Parts - Section 34 definition of significant cyber security incident became active, setting the threshold for voluntary sharing under Part 4 - Section 37 established the role of the National Cyber Security Coordinator as the designated contact for incident coordination from 30 November 2024 - Sections 38 through 43 activated information protection and admissibility safeguards for entities that voluntarily share incident data *Recommended next step* *Placement: after the timeline or milestone section* ## Turn Australia Cyber Security Act 2024 Timeline and commencement dates into an operational assessment Assessment Autopilot can take Australia Cyber Security Act 2024 Timeline and commencement dates from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on Australia Cyber Security Act 2024 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Australia Cyber Security Act 2024 Timeline and commencement dates](/solutions/assessment.md): Start from Australia Cyber Security Act 2024 Timeline and commencement dates and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Australia Cyber Security Act 2024](/contact.md): Review your current process, evidence gaps, and next steps for Australia Cyber Security Act 2024 Timeline and commencement dates. ## Part 3 commencement: ransomware reporting from 29 May 2025 Part 3 of the Australia Cyber Security Act 2024 covers ransomware reporting obligations. According to the commencement table, Part 3 starts on a single day to be fixed by Proclamation. If no proclamation commenced Part 3 within six months of Royal Assent, the provisions automatically commence the day after that six month period ends. With Royal Assent on 29 November 2024, the six month backstop date was 29 May 2025. Once Part 3 commenced, section 27(1) of the Australia Cyber Security Act 2024 required reporting business entities to give the designated Commonwealth body a ransomware payment report within 72 hours of making a ransomware payment or becoming aware that a ransomware payment had been made. Section 26 defines which entities fall within scope: the application test considers the annual turnover of the entity, with a threshold of $3 million for the previous financial year as prescribed by the Ransomware Payment Reporting Rules 2025. The Part 3 commencement also activated the information protection provisions in Division 3, including section 29 (permitted purpose limitation), section 30 (secondary use and disclosure restrictions), section 31 (legal professional privilege preservation), and section 32 (admissibility restrictions against the reporting entity). These protections were designed to encourage reporting by reducing the risk that disclosed information would be used against the reporting entity in enforcement or litigation. The ransomware payment report must contain seven categories of information as prescribed by section 7 of the Ransomware Payment Reporting Rules 2025: the reporting business entity's ABN and address; the other entity's ABN and address; when the incident occurred or is estimated to have occurred and when the entity became aware of it; the impact on the entity's infrastructure and customers; variants of ransomware or other malware used; vulnerabilities exploited; the amount or quantum of the demand and the method of provision demanded; the amount or quantum of the payment and the method of provision; and the nature, timing, and description of communications with the extorting entity including any pre-payment negotiations. All of these report fields became required from 29 May 2025, making that commencement date a critical deadline in the Australia Cyber Security Act 2024 timeline for incident response teams. - 29 May 2025: backstop commencement date for Part 3 of the Australia Cyber Security Act 2024 (ransomware reporting obligations) - Section 27(1): reporting business entities must submit a ransomware payment report within 72 hours of making or becoming aware of a ransomware payment - $3 million turnover threshold for the previous financial year, as prescribed by section 6 of the Ransomware Payment Reporting Rules 2025 (F2025L00278) - Section 29: ransomware payment reports may only be used or disclosed for permitted cyber security purposes as defined in section 10 of the Act - Section 31: legal professional privilege is preserved and cannot be abrogated by the reporting obligation - Section 32: information in a ransomware payment report is not admissible against the reporting business entity in most proceedings - The 72 hour reporting window only requires information the entity knows or can find through reasonable search within that window ## Part 5 commencement: Cyber Incident Review Board from 29 May 2025 Part 5 of the Australia Cyber Security Act 2024 establishes the Cyber Incident Review Board (CIRB). Like Part 3, Part 5 starts on a day fixed by Proclamation with a six month backstop. Because Royal Assent was 29 November 2024, the backstop date for Part 5 was also 29 May 2025. The CIRB is an independent body with the function of causing reviews to be conducted into significant cyber security incidents under section 46 of the Act. The Board comprises a Chair appointed under section 64, standing members appointed under section 66, and an Expert Panel constituted under section 70. Section 63 requires the Board to perform its functions independently of the Minister and the Department. Once Part 5 commenced, the Board gained the power to require certain entities to produce documents under section 49, with a civil penalty for non compliance under section 50. Review reports follow a draft and final process under sections 51 and 52, with mandatory redaction of sensitive information under section 53 and protection of review reports under section 54. For organisations that may be subject to a CIRB review, the Part 5 commencement date marks the point at which document retention and incident record keeping become directly relevant to a statutory review process. - 29 May 2025: backstop commencement date for Part 5 of the Australia Cyber Security Act 2024 (Cyber Incident Review Board) - Section 46: the Board must cause reviews to be conducted into significant cyber security incidents - Section 49: the Chair may require certain entities to produce documents relevant to a review - Section 50: civil penalty of 60 penalty units for failing to comply with a document production notice - Section 63: the Board must perform its functions independently - Section 53: certain information must be redacted from final review reports before publication - Section 54: protected review reports contain the unredacted material and are subject to access restrictions ## Part 2 commencement: smart device security standards backstop on 29 November 2025 Part 2 of the Australia Cyber Security Act 2024 addresses security standards for smart devices. The commencement table provides that Part 2 starts on a day fixed by Proclamation, with a twelve month backstop. Because Royal Assent was 29 November 2024, the fallback date for Part 2 was 29 November 2025. Part 2 contains four Divisions. Division 1 sets out the preliminary application rules under section 13. Division 2 establishes the power to make security standards for relevant connectable products under section 14, the compliance requirement under section 15, and the obligation to provide and supply products with a statement of compliance under section 16. Division 3 provides the enforcement toolkit: compliance notices under section 17, stop notices under section 18, recall notices under section 19, and public notification of recall failures under section 20. Division 4 covers internal review under section 22 and examination powers under section 23. The Part 2 commencement date is the point at which the Secretary gains the power to make security standards and the enforcement mechanism becomes available. However, the operative security requirements that product teams must meet are specified in the Smart Devices Rules rather than in the Act itself. This means that even after Part 2 commences, the practical compliance burden depends on the separate commencement schedule of the Smart Devices Rules. Section 13 of the Act specifies that Part 2 applies to a relevant connectable product that is manufactured on or after the commencement of Part 2, or supplied (other than as second hand goods) on or after the commencement of Part 2. This means the commencement date of 29 November 2025 marks the product manufacture and supply date threshold in the Australia Cyber Security Act 2024 timeline. Products manufactured before 29 November 2025 that are not supplied after that date fall outside Part 2 scope. Products manufactured before 29 November 2025 but supplied for the first time after that date are within scope. - 29 November 2025: backstop commencement date for Part 2 of the Australia Cyber Security Act 2024 (smart device security standards) - Section 14: the Secretary may determine security standards for classes of relevant connectable products - Section 15: manufacturers must ensure relevant connectable products comply with applicable security standards - Section 16: manufacturers and suppliers must provide and supply products with a statement of compliance, retained for 5 years under section 16(2) and (4) - Section 17: the Secretary may issue a compliance notice directing a manufacturer to take specified actions - Section 18: the Secretary may issue a stop notice prohibiting supply of non compliant products - Section 19: the Secretary may issue a recall notice requiring retrieval of products already supplied ## Smart Devices Rules 2025: registration on 4 March 2025 and operative date of 4 March 2026 The Cyber Security (Security Standards for Smart Devices) Rules 2025 were registered on the Federal Register of Legislation on 4 March 2025 as instrument F2025L00276. The commencement table in the Rules specifies a two stage activation. Part 1 and anything not elsewhere covered commenced on the day of registration, 4 March 2025. Part 2 and Schedule 1 commence the day after the end of 12 months from registration, which is 4 March 2026. Schedule 1 of the Smart Devices Rules defines the security standards that relevant connectable products must meet. The 12 month delay between registration and the operative date for Part 2 and Schedule 1 was designed to give manufacturers time to redesign products, update firmware, and build the statement of compliance workflow required by section 16 of the Australia Cyber Security Act 2024. Two obligations became binding from registration on 4 March 2025. First, section 10 of the Rules requires manufacturers to retain statements of compliance for a period of 5 years. Second, Schedule 1 clause 4(4) provides that a manufacturer must not shorten a published defined support period for security updates. If a manufacturer extends a defined support period, the new period must be published as soon as is practicable under clause 4(5). These obligations apply from 4 March 2025, well before the operative security standard takes effect on 4 March 2026. The Schedule 1 security standard that became enforceable on 4 March 2026 contains three core requirements. Clause 2 requires that passwords for hardware and software of the product be either unique per product (not based on incremental counters, not based on or derived from publicly available information, not based on unique product identifiers unless encrypted using good industry practice, and not otherwise guessable in a manner unacceptable as part of good industry practice) or defined by the user. Clause 3 requires manufacturers to publish at least one contact point for reporting security issues, with timelines for acknowledgement and status updates, in English, free of charge, without requiring personal information, and without requiring a prior request. Clause 4 requires manufacturers to publish a defined support period for security updates expressed as a time period with an end date, and prohibits shortening that period after publication. The consumer grade relevant connectable products covered by the Schedule 1 security standard are those intended for personal, domestic, or household use that will be acquired in Australia by a consumer. Section 8 of the Smart Devices Rules excludes desktop computers, laptops, tablet computers, smartphones, therapeutic goods, road vehicles, and road vehicle components from the Schedule 1 standard. For product teams, the 4 March 2026 commencement date in the Australia Cyber Security Act 2024 timeline is the hard deadline for ensuring that all in scope products comply with these three requirements. Teams should work backward from 4 March 2026 to allow time for password redesign, vulnerability disclosure channel publication, defined support period publication, firmware update processes, and statement of compliance automation. - 4 March 2025: Smart Devices Rules 2025 (F2025L00276) registered on the Federal Register of Legislation - 4 March 2025: Part 1 commenced on the day of registration, activating the 5 year retention period for statements of compliance - 4 March 2025: the obligation not to shorten a published defined support period for security updates took effect under Schedule 1 clause 4(4) - 4 March 2026: Part 2 and Schedule 1 of the Smart Devices Rules become operative, activating the full security standard for relevant connectable products - 12 months between registration and operative date: product teams received a build window for redesign, testing, and statement of compliance preparation - Schedule 1 clause 4(5): if a manufacturer extends the defined support period, the extension must be published as soon as is practicable - 5 year retention period: statements of compliance must be retained for 5 years from the date the product is supplied - Section 9 of the Smart Devices Rules: statement of compliance must include product type and batch identifier, manufacturer name and address, authorised representative details, manufacturer declaration of compliance, defined support period at date of issue, signatory name and function, and place and date of issue ## Ransomware Payment Reporting Rules 2025: commencement linked to Part 3 The Cyber Security (Ransomware Payment Reporting) Rules 2025 were registered on 3 March 2025 as instrument F2025L00278. The commencement table in the Rules provides that the whole instrument commences on the later of: (a) the start of the day after registration, and (b) the same time that Part 3 of the Australia Cyber Security Act 2024 commences. Because Part 3 commenced on 29 May 2025 under its six month backstop, the Ransomware Reporting Rules also commenced on 29 May 2025. Section 6 of the Ransomware Reporting Rules prescribes the turnover threshold at $3 million for the previous financial year. This threshold determines whether an entity is a reporting business entity under section 26(3)(b) of the Act. Section 7 of the Rules specifies the information required in a ransomware payment report, with a note clarifying that information is only required to the extent the reporting entity knows or can find through reasonable search within the 72 hour reporting window. Section 6(2) of the Rules also provides a pro rata formula for businesses that operated for only part of the previous financial year. The threshold is calculated as $3 million multiplied by the number of days in the part year divided by the number of days in the full financial year. This ensures that newly established businesses are subject to a proportionate threshold rather than the full $3 million amount. The linkage between the Rules commencement and Part 3 commencement means that the operational reporting obligation and the threshold definition activated simultaneously. Organisations did not face a gap where the Act obligation existed but the Rules threshold had not yet commenced. In addition to the turnover test, an entity is a reporting business entity if it is a responsible entity for a critical infrastructure asset to which Part 2B of the Security of Critical Infrastructure Act 2018 applies, regardless of turnover. This means critical infrastructure operators were captured by the ransomware reporting obligation from 29 May 2025 in the Australia Cyber Security Act 2024 timeline even if their turnover fell below $3 million. - 3 March 2025: Ransomware Payment Reporting Rules 2025 (F2025L00278) registered on the Federal Register - 29 May 2025: Rules commenced simultaneously with Part 3 of the Australia Cyber Security Act 2024 - Section 6 of the Rules: turnover threshold of $3 million for the previous financial year - Section 7 of the Rules: specifies report content requirements, limited to what is known or discoverable within 72 hours - Commencement trigger: the later of (a) the day after registration and (b) Part 3 commencement date - No gap between Act obligation and Rules threshold: both activated on 29 May 2025 ## Cyber Incident Review Board Rules 2025: commencement linked to Part 5 The Cyber Security (Cyber Incident Review Board) Rules 2025 were registered on 3 March 2025 as instrument F2025L00277. The commencement table provides that the whole instrument commences on the later of: (a) the start of the day after registration, and (b) the same time that Part 5 of the Australia Cyber Security Act 2024 commences. Because Part 5 commenced on 29 May 2025, the CIRB Rules also commenced on that date. The CIRB Rules underwent public consultation before registration as required by subsection 87(3) of the Act. The Explanatory Statement records that draft Rules were published on the Department of Home Affairs website on 16 December 2024, with submissions closing on 14 February 2025. The Department received 37 submissions, the majority of which were broadly supportive. The Department also hosted 7 deep dive sessions in January and February 2025 for all three rule sets, with over 900 attendees cumulatively and an average of 130 attendees per session. The CIRB deep dive sessions specifically drew over 180 attendees across two sessions. The Rules were then registered on 3 March 2025. Section 11(1) of the Rules requires the Board to publish notification of a review as soon as practicable after deciding to conduct one. This operational timing requirement became binding on 29 May 2025. For organisations that operate critical infrastructure or handle significant volumes of personal data, the CIRB Rules commencement date is the point from which a statutory review of a significant cyber security incident can be initiated and document production powers can be exercised. - 3 March 2025: Cyber Incident Review Board Rules 2025 (F2025L00277) registered on the Federal Register - 29 May 2025: Rules commenced simultaneously with Part 5 of the Australia Cyber Security Act 2024 - 16 December 2024: draft CIRB Rules published for public consultation - 14 February 2025: public consultation period closed for submissions - Section 11(1): the Board must publish review notification as soon as practicable after deciding to conduct a review - Commencement trigger: the later of (a) the day after registration and (b) Part 5 commencement date ## PJCIS statutory review from 1 December 2027 under section 88 Section 88 of the Australia Cyber Security Act 2024 requires the Parliamentary Joint Committee on Intelligence and Security (PJCIS) to begin a statutory review of the Act as soon as practicable after 1 December 2027. This review will examine the operation, effectiveness, and scope of the Act approximately three years after Royal Assent. The statutory review is significant for compliance planning because it may result in amendments to the Act, changes to penalty levels, expansion of scope to additional product categories, or modifications to the ransomware reporting threshold. Organisations should expect that any evidence of compliance gaps identified between commencement and the review period may inform the PJCIS recommendations. For compliance teams maintaining ongoing assurance programs, the 1 December 2027 date serves as a planning horizon. Records of compliance activities, incident reports, and enforcement interactions from the commencement period through to the review will form the evidence base that the PJCIS uses to evaluate whether the Act has achieved its stated objects under section 3. Those objects include improving cyber security of internet connectable products through mandatory security standards, encouraging ransomware payment information sharing through reporting obligations, facilitating whole of Government response to significant incidents through the National Cyber Security Coordinator, preventing and minimising the impact of incidents through the Cyber Incident Review Board review and recommendation process, and encouraging voluntary information sharing through statutory use and disclosure protections. The Australia Cyber Security Act 2024 timeline therefore extends from 29 November 2024 Royal Assent through to the PJCIS review after 1 December 2027 and any resulting legislative amendments. - 1 December 2027: earliest date for the PJCIS to begin the statutory review under section 88 of the Australia Cyber Security Act 2024 - Section 88 requires the review to begin as soon as practicable after 1 December 2027 - The review will assess the operation, effectiveness, and scope of the Act - Approximately three years of operational data from commencement will inform the review - Potential outcomes include amendments to penalty levels, scope expansion, threshold changes, or process modifications - Compliance records maintained from 30 November 2024 onward will serve as the evidence base for the review ## Complete Australia Cyber Security Act 2024 commencement schedule The following summary consolidates every commencement date in the Australia Cyber Security Act 2024 timeline, covering the Act itself, all three subordinate rule sets, and the statutory review trigger. Teams can use this consolidated schedule to align internal project milestones, board reporting dates, and assurance review cycles with the legal commencement sequence. The commencement schedule spans more than three years, from 30 November 2024 through to 1 December 2027. Within that window, the most operationally significant dates for product teams are 4 March 2026 (smart device operative standard) and for incident response teams are 29 May 2025 (ransomware reporting activation). Governance teams should plan for ongoing assurance from mid 2025 onward and prepare documentation for the statutory review starting from late 2027. - 29 November 2024: Royal Assent for the Australia Cyber Security Act 2024 - 30 November 2024: Part 1, Part 4, Parts 6 and 7 commenced - 16 December 2024: draft CIRB Rules published for public consultation - 14 February 2025: CIRB Rules consultation submissions closed - 3 March 2025: Ransomware Payment Reporting Rules (F2025L00278) and Cyber Incident Review Board Rules (F2025L00277) registered - 4 March 2025: Smart Devices Rules (F2025L00276) registered; Part 1 of the Rules commenced - 29 May 2025: Part 3 (ransomware reporting), Part 5 (CIRB), Ransomware Rules, and CIRB Rules all commenced - 29 November 2025: Part 2 (smart device security standards) backstop commencement date - 4 March 2026: Part 2 and Schedule 1 of the Smart Devices Rules became operative - 1 December 2027: PJCIS statutory review of the Australia Cyber Security Act 2024 must begin as soon as practicable after this date under section 88 ## Practical readiness checklist for each commencement milestone Each commencement date in the Australia Cyber Security Act 2024 timeline corresponds to a set of operational obligations that compliance, product, and incident response teams should have completed before that date. Planning backward from each hard date ensures that internal processes are tested and operational before the legal obligation activates. For the 29 May 2025 ransomware reporting milestone, incident response teams should have completed a reporting entity assessment (confirming whether the $3 million turnover threshold is met or whether the entity is a responsible entity for a critical infrastructure asset under the Security of Critical Infrastructure Act 2018), mapped all seven categories of information required in a ransomware payment report under section 7 of the Ransomware Payment Reporting Rules 2025 (entity details and ABN, incident timing and discovery date, infrastructure and customer impact, malware variants, exploited vulnerabilities, demand amount and method, payment amount and method, and communications timeline), established a reporting workflow with the designated Commonwealth body, and conducted a tabletop exercise simulating a 72 hour reporting scenario. For the 4 March 2026 smart device operative date, product teams should have completed default credential elimination and unique per product password implementation (or user defined password flows), published a vulnerability disclosure contact point meeting the accessibility requirements of Schedule 1 clause 3, published a defined support period for security updates with an end date meeting the requirements of Schedule 1 clause 4, prepared statement of compliance templates containing all fields required by section 9 of the Smart Devices Rules (product type and batch identifier, manufacturer details, authorised representative details, manufacturer declaration, defined support period, signatory details, and place and date of issue), and conducted a pre market compliance audit against all three Schedule 1 requirements. After all commencement dates have passed, the compliance program should transition from project mode to recurring assurance mode. This includes scheduled reviews of compliance status, periodic tabletop exercises for ransomware reporting readiness, firmware update process audits, and evidence packaging for the eventual PJCIS statutory review. - Before 29 May 2025: complete ransomware payment reporting entity assessment, report field mapping, workflow establishment, and tabletop exercise - Before 29 May 2025: confirm document retention processes are in place for potential CIRB review document production requests - Before 4 March 2026: complete password design review, default credential elimination, and defined support period publication for all relevant connectable products - Before 4 March 2026: prepare and test statement of compliance templates and automate compliance documentation generation - Before 4 March 2026: conduct a pre market compliance audit against Schedule 1 of the Smart Devices Rules - After all milestones: transition from project mode to recurring assurance mode with scheduled reviews, exercises, and evidence packaging - Before 1 December 2027: compile and organise all compliance evidence for the PJCIS statutory review ## Primary sources - [Cyber Security Act 2024 (Australia) official text](https://www.legislation.gov.au/C2024A00098/latest/text?ref=sorena.io) - Primary source for the commencement table in section 2, Part structure (Parts 1 through 7), definitions in section 8, ransomware reporting obligations in section 27, Cyber Incident Review Board provisions in Part 5 (sections 46 through 70), smart device security standards in Part 2 (sections 12 through 24), and the PJCIS statutory review requirement in section 88. Replaced Authorised Version registered 28 January 2026. - [Cyber Security (Security Standards for Smart Devices) Rules 2025 (F2025L00276) official text](https://www.legislation.gov.au/F2025L00276/asmade/text?ref=sorena.io) - Primary source for the Smart Devices Rules commencement table, the 12 month delayed commencement for Part 2 and Schedule 1, the 5 year statement of compliance retention period in section 10, the defined support period obligations in Schedule 1 clause 4(4) and 4(5), and the operative security standard requirements. Registered 4 March 2025. - [Cyber Security (Ransomware Payment Reporting) Rules 2025 (F2025L00278) official text](https://www.legislation.gov.au/F2025L00278/asmade/text?ref=sorena.io) - Primary source for the Ransomware Reporting Rules commencement linkage to Part 3, the $3 million turnover threshold in section 6, and the report content requirements and 72 hour information availability note in section 7. Registered 3 March 2025. - [Cyber Security (Cyber Incident Review Board) Rules 2025 (F2025L00277) official text](https://www.legislation.gov.au/F2025L00277/asmade/text?ref=sorena.io) - Primary source for the CIRB Rules commencement linkage to Part 5, the review notification publication requirement in section 11(1), and the consultation timeline (draft published 16 December 2024, submissions closed 14 February 2025). Registered 3 March 2025. ## Related Topic Guides - [Australia Cyber Security Act 2024 Applicability Test | Who Must Comply](/artifacts/apac/australia-cyber-security-act/applicability-test.md): Complete Australia Cyber Security Act 2024 applicability test covering smart device security standards, ransomware payment reporting obligations. - [Australia Cyber Security Act 2024 Compliance Checklist](/artifacts/apac/australia-cyber-security-act/checklist.md): Comprehensive Australia Cyber Security Act 2024 compliance checklist covering smart device security standards, ransomware payment reporting. - [Australia Cyber Security Act 2024 Compliance Guide | Implementation Playbook](/artifacts/apac/australia-cyber-security-act/compliance.md): A detailed Australia Cyber Security Act 2024 compliance guide covering smart device security standards, statement of compliance requirements. - [Australia Cyber Security Act 2024 Compliance Templates | Statement of Compliance, Ransomware Report, Evidence Pack, Vulnerability Disclosure, Support Period](/artifacts/apac/australia-cyber-security-act/templates.md): Comprehensive Australia Cyber Security Act 2024 compliance templates with every required field. - [Australia Cyber Security Act 2024 Deadlines and Compliance Calendar | Commencement Dates](/artifacts/apac/australia-cyber-security-act/deadlines-and-compliance-calendar.md): Complete Australia Cyber Security Act 2024 deadlines and compliance calendar with all commencement dates: 30 November 2024 Royal Assent. - [Australia Cyber Security Act 2024 FAQ | Frequently Asked Questions](/artifacts/apac/australia-cyber-security-act/faq.md): Get detailed answers to frequently asked questions about the Australia Cyber Security Act 2024. - [Australia Cyber Security Act 2024 Requirements | Smart Device and Ransomware Reporting Obligations](/artifacts/apac/australia-cyber-security-act/requirements.md): Complete guide to Australia Cyber Security Act 2024 requirements covering smart device password rules, vulnerability disclosure. - [Australia Cyber Security Act 2024 vs EU Cyber Resilience Act | Full CRA Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-eu-cyber-resilience-act.md): Detailed comparison of the Australia Cyber Security Act 2024 and the EU Cyber Resilience Act covering scope, product categories, security requirements. - [Australia Cyber Security Act 2024 vs UK PSTI Act | Product Security Comparison](/artifacts/apac/australia-cyber-security-act/cyber-security-act-vs-uk-psti-act.md): Detailed product security comparison of the Australia Cyber Security Act 2024 and the UK PSTI Act covering scope, ETSI EN 303 645, password requirements. - [Australia Smart Device Compliance Checklist | Cyber Security Act 2024 | Sorena](/artifacts/apac/australia-cyber-security-act/smart-device-compliance-checklist.md): Complete Australia Cyber Security Act 2024 smart device compliance checklist covering Schedule 1 password security, vulnerability disclosure. - [Penalties and fines | Australia Cyber Security Act 2024 | 60 Penalty Units, Smart Device Enforcement, Ransomware Reporting](/artifacts/apac/australia-cyber-security-act/penalties-and-fines.md): Australia Cyber Security Act 2024 penalties explained: 60 penalty units (AUD 19,800) per contravention for individuals. - [Ransomware Payment Reporting in 72 Hours | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/ransomware-payment-reporting-72-hours.md): Complete guide to the 72 hour ransomware payment reporting obligation under Part 3 of the Australia Cyber Security Act 2024. - [Scope and Definitions | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/scope-and-definitions.md): Complete guide to the Australia Cyber Security Act 2024 scope and definitions. - [Smart device security standards | Australia Cyber Security Act 2024](/artifacts/apac/australia-cyber-security-act/smart-device-security-standards.md): Complete technical guide to the three Australia Cyber Security Act 2024 smart device security standards: password security under Clause 2. - [Statement of Compliance and Recordkeeping | Australia Cyber Security Act 2024 | Section 9, Section 10, 5 Year Retention](/artifacts/apac/australia-cyber-security-act/statement-of-compliance-and-recordkeeping.md): Australia Cyber Security Act 2024 statement of compliance explained: all mandatory fields under Section 9(3) of the Smart Device Rules 2025. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/australia-cyber-security-act/timeline-and-commencement --- --- title: "Singapore PDPA Applicability Test" canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/applicability-test" source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/applicability-test" author: "Sorena AI" description: "Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Singapore PDPA applicability test" - "does PDPA apply to my company" - "Singapore PDPA scope" - "Singapore Personal Data Protection Act scope" - "Singapore PDPA organisation definition" - "PDPA data intermediary obligations" - "PDPA excluded organisations" - "PDPA personal domestic exemption" - "PDPA public agency exclusion" - "PDPA employee exclusion" - "PDPA business contact information" - "Singapore PDPA extraterritorial scope" - "PDPA inbound data transfers" - "Singapore DNC registry applicability" - "PDPA cross-border transfer obligations" - "PDPA Transfer Limitation Obligation" - "PDPA sector-specific guidelines Singapore" - "PDPA healthcare Singapore" - "PDPA financial sector Singapore" - "PDPA telecom Singapore" - "PDPC enforcement" - "Singapore PDPA compliance checklist" - "PDPA applicability workflow" - "Singapore data protection compliance" - "PDPA consent obligation" - "PDPA data breach notification" - "PDPA accountability obligation" - "PDPA protection obligation" - "Singapore PDPA compliance guide" - "Singapore PDPA applicability framework" - "Singapore PDPA applicability assessment" - "does Singapore PDPA apply" - "Singapore PDPA for foreign companies" - "Singapore PDPA data intermediary test" - "Singapore PDPA" - "Personal Data Protection Act" - "PDPA applicability" - "APAC privacy" - "data protection Singapore" - "PDPC guidelines" - "Singapore data intermediary" - "DNC registry Singapore" - "PDPA scope" - "PDPA compliance guide" - "Singapore PDPA compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Singapore PDPA Applicability Test Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation. *Artifact Guide* *APAC* ## Singapore PDPA Applicability Test Step-by-step Singapore PDPA applicability test to determine whether the Personal Data Protection Act applies to your organisation, which role you hold under the PDPA, and which data protection obligations attach to your processing activities. Run this Singapore PDPA applicability test before product launches, vendor onboarding, and market-entry planning so scope decisions are documented, repeatable, and defensible under PDPC Advisory Guidelines. The Singapore Personal Data Protection Act (PDPA) governs the collection, use, and disclosure of personal data by organisations in Singapore. However, not every entity and not every processing activity falls within the Singapore PDPA scope. Before building a compliance programme, teams must first answer a foundational question: does the Singapore PDPA apply to what we do, and if so, which obligations are triggered? This Singapore PDPA applicability test provides an implementation-focused framework grounded in the PDPA statute (Personal Data Protection Act 2012) and the Personal Data Protection Commission (PDPC) Advisory Guidelines on Key Concepts, revised 16 May 2022. It is written for product, legal, security, and operations teams who need a repeatable, auditable framework for scoping Singapore PDPA coverage across their processing activities, vendor relationships, and cross-border data flows. The PDPA was first enacted in 2012, revised in 2020, and its amendments took effect in phases from 1 February 2021. The PDPC is established under the PDPA with key functions including promoting awareness of data protection in Singapore and administering and enforcing the Act. ## Singapore PDPA applicability test: quick decision framework The Singapore PDPA applies to every organisation that collects, uses, or discloses personal data in Singapore unless a specific exclusion applies. Section 2(1) of the PDPA defines 'organisation' broadly to include any individual, company, association, or body of persons, whether incorporated or not, and whether formed or recognised under Singapore law or not. This means foreign entities that handle personal data in Singapore are also within the scope of this Singapore PDPA applicability test. The PDPA's purpose, stated in section 3, is to govern the collection, use, and disclosure of personal data by organisations in a manner that recognises both the right of individuals to protect their personal data and the need of organisations to collect, use, or disclose personal data for purposes that a reasonable person would consider appropriate in the circumstances. Before diving into detailed analysis, use the following rapid triage questions from this Singapore PDPA applicability test to determine whether your processing activities are likely subject to the Act. If you answer 'yes' to any of the questions below, continue through the remaining sections of this guide to identify your exact obligations. If you answer 'no' to all questions, document your reasoning and retain it as evidence of your Singapore PDPA applicability assessment. The PDPC has stated that organisations should be able to adduce evidence to establish and demonstrate compliance with obligations under the PDPA in the event of an investigation. Keep in mind that the Singapore PDPA covers personal data stored in both electronic and non-electronic formats. Even paper records containing personal data about identifiable individuals fall within scope. Under the PDPA, personal data is defined as data, whether true or not, about an individual who can be identified from that data alone or from that data and other information to which the organisation has or is likely to have access. The term 'personal data' is not intended to be narrowly construed and may cover different types of data about an individual regardless of whether the data exists in electronic or other form. The PDPC applies a 'practicability' threshold when determining whether an organisation is likely to have access to other data that will identify an individual. An organisation will not be considered to have access to other information if it is not practicable to obtain it, even though it is theoretically or technically possible. When running this Singapore PDPA applicability test, organisations should therefore assess identifiability based on data they actually hold or are likely to hold, not on theoretical possibilities. - Does your entity (company, sole proprietorship, partnership, association, or individual acting in a business capacity) collect, use, or disclose personal data in Singapore? If yes, the Singapore PDPA likely applies. - Is the data about a natural person (living or deceased for 10 years or less) who can be identified from the data alone or from the data combined with other information you have or are likely to have access to? The PDPA requires at least two data elements before individuals can typically be identified. - Are you handling data in the course of business or commercial activity rather than in a purely personal or domestic capacity? Only entities acting in a business or commercial capacity are subject to the Singapore PDPA Data Protection Provisions. - Does your entity operate in Singapore, or does it process personal data that is located in or transferred into Singapore, even if the entity itself is based overseas? The Singapore PDPA has extraterritorial reach for processing activities involving personal data in Singapore. - Do any of your processing activities involve sending marketing messages to Singapore telephone numbers, triggering Do Not Call (DNC) Registry obligations under Parts 9 and 9A of the PDPA? - Do you transfer personal data outside Singapore to data centres, cloud providers, or group companies in other jurisdictions? The Singapore PDPA Transfer Limitation Obligation under section 26 applies to all outbound transfers. - Have you confirmed that none of the Singapore PDPA exclusions (public agency, personal or domestic use, employee acting in the course of employment, business contact information) fully remove your processing from scope? - Does your organisation process derived personal data, such as data created through mathematical, logical, statistical, or algorithmic methods applied to other personal data? Derived personal data remains within Singapore PDPA scope. *Recommended next step* *Placement: after the applicability result* ## Turn Singapore PDPA Applicability Test into an operational assessment Assessment Autopilot can take Singapore PDPA Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on Singapore PDPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Singapore PDPA Applicability Test](/solutions/assessment.md): Start from Singapore PDPA Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Singapore PDPA](/contact.md): Review your current process, evidence gaps, and next steps for Singapore PDPA Applicability Test. ## Singapore PDPA organisation vs data intermediary: roles and obligations A core step in the Singapore PDPA applicability test is determining whether your entity acts as an 'organisation' (comparable to a data controller under the GDPR) or as a 'data intermediary' (comparable to a data processor). The PDPA defines a data intermediary as an organisation that processes personal data on behalf of another organisation but does not include an employee of that other organisation. As the PDPC explains, data intermediaries process data not on their own behalf but on behalf of other organisations, often their business customers. In that capacity, a data intermediary often will not interact directly with individuals, making it important that consumer-facing requirements are not applied directly to data intermediaries. Organisations that determine the purposes and means of processing personal data bear the full weight of all eleven Singapore PDPA obligations: (1) Accountability, to demonstrate responsibility through proper management and protection of personal data; (2) Notification, to notify individuals of the purposes of collecting, using, and disclosing their personal data; (3) Consent, to collect, use, or disclose personal data for purposes for which consent has been given and allow individuals to withdraw consent; (4) Purpose Limitation, to collect, use, or disclose personal data for reasonable purposes; (5) Accuracy, to ensure personal data is accurate and complete; (6) Access and Correction, to provide individuals with access to their personal data and correct errors; (7) Protection, to make reasonable security arrangements; (8) Retention Limitation, to keep personal data only as long as needed; (9) Transfer Limitation, to transfer personal data overseas according to regulatory requirements; (10) Data Breach Notification, to notify the PDPC and affected individuals of notifiable breaches; and (11) Data Portability (under development), to transmit data to another organisation in a machine-readable format. Data intermediaries under the Singapore PDPA are subject only to the Protection Obligation, the Retention Limitation Obligation, and the obligation to notify the organisation of data breaches without undue delay. This reduced set of obligations reflects the importance of creating role-based obligations for companies that process personal data. However, a data intermediary that processes personal data under a written contract must operate within the scope authorised by the organisation. If a data intermediary uses or discloses personal data beyond the scope of what the organisation has authorised, the intermediary becomes an organisation for that processing and must comply with all Data Protection Provisions. In practice, many companies act as both an organisation and a data intermediary across different processing activities under the Singapore PDPA. A payroll outsourcing firm, for example, is a data intermediary when processing employee data on behalf of its clients, but it is an organisation when processing its own employees' personal data. The PDPC's Advisory Guidelines on Key Concepts (Chapter 6) emphasise that an organisation cannot escape its PDPA obligations by engaging a data intermediary. Section 4(3) of the PDPA provides that an organisation has the same obligations in respect of personal data processed on its behalf by a data intermediary as if the personal data were processed by the organisation itself. This means organisations must conduct due diligence on their data intermediaries and include contractual clauses that specify the intermediary's scope of work, security obligations, and breach notification duties. - Map every processing activity (collection, use, disclosure, storage, transfer) to determine whether your entity acts as the organisation or the data intermediary for that activity under the Singapore PDPA. - Organisations bear all eleven Singapore PDPA obligations; data intermediaries bear only Protection, Retention Limitation, and Data Breach Notification (to the organisation, not the PDPC directly). - If a data intermediary uses personal data beyond the scope authorised by the organisation, the intermediary becomes an organisation for that processing and must comply with all Singapore PDPA Data Protection Provisions. - Written contracts with data intermediaries must clearly specify the scope of processing, security standards, data retention policies, and breach notification timelines. The PDPC recommends including contractual clauses to ensure the data intermediary's scope of work and level of responsibilities are clear. - Section 4(3) of the Singapore PDPA makes the organisation vicariously liable for data intermediary processing, so due diligence before engagement is not optional. Organisations are responsible for personal data collected, used, and disclosed by the data intermediary regardless of whether the data was actually transmitted to the organisation. - Agents (such as insurance agents or property agents) may qualify as data intermediaries under the Singapore PDPA depending on whether they process personal data on behalf of another organisation under a written contract. The PDPA treats agents the same as any other organisation when determining data intermediary status. - Within a corporate group, one entity can act as a data intermediary for other group members (for example, centralised payroll or HR processing), and the parent or engaging entity retains full Singapore PDPA obligations for that processing. - Network service providers that merely act as conduits for the transmission of personal data are protected under section 67(2) of the PDPA, which amends the Electronic Transactions Act to exclude liability for third-party material in the form of electronic records to which the provider merely provides access. ## Singapore PDPA excluded processing: personal, domestic, employee, and public agency exemptions The Singapore PDPA does not impose Data Protection Provisions obligations on three categories of entities: individuals acting in a personal or domestic capacity, employees acting in the course of employment, and public agencies. Understanding these exclusions is essential for any Singapore PDPA applicability test because they determine whether certain activities are outside scope entirely or whether obligations still apply to other parties in the same transaction. The commercial entity on the other side of a transaction with an excluded individual remains fully subject to the Singapore PDPA. An individual acts in a personal capacity when undertaking activities for his or her own purposes. The Singapore PDPA defines 'domestic' as 'related to home or family,' so activities such as booking a family holiday, managing personal finances, opening joint bank accounts between family members, or purchasing life insurance policies for a child are excluded from scope. However, the organisation on the other side of the transaction remains fully subject to the Singapore PDPA. For example, the PDPC Advisory Guidelines illustrate that when Tom books a travel package and provides his wife Jane's personal data to the travel agency, Tom is excluded because he is acting in a personal or domestic capacity, but the travel agency must comply with all Data Protection Provisions regarding both Tom's and Jane's data. The travel agency can collect Jane's personal data without her consent because the exception in paragraph 8 under Part 3 of the First Schedule applies, but it must still comply with all other obligations. The employee exclusion under the Singapore PDPA means that an individual employee acting in the course of employment with an organisation is not separately subject to the Data Protection Provisions. The PDPA defines 'employee' to include volunteers, so individuals who undertake work without an expectation of payment also fall within this exclusion. However, organisations remain primarily responsible for the actions of their employees and volunteers that result in contraventions of the Data Protection Provisions. This exclusion does not reduce the organisation's own Singapore PDPA compliance obligations; it simply means the employee is not individually liable under the PDPA for actions taken as part of their job. Public agencies, including the Government (any ministry, department, agency, or organ of State), tribunals appointed under any written law, and statutory bodies specified by the Minister by notice in the Gazette, are excluded from the Singapore PDPA Data Protection Provisions. The gazetted notifications of statutory bodies specified as public agencies can be accessed through the PDPC website. Organisations that provide services to public agencies are not themselves excluded and must determine whether they operate as organisations or data intermediaries in that relationship. This distinction is critical for the Singapore PDPA applicability test when assessing government contracts. - Personal or domestic capacity: individuals handling data for their own personal or family purposes are not subject to the Singapore PDPA Data Protection Provisions, but the commercial entity on the other side of the transaction remains in scope and must comply with all applicable obligations. - Employee exclusion: employees (including volunteers) acting in the course of employment are not individually liable under the Singapore PDPA, but their employer organisation remains primarily responsible for any contravention of the Data Protection Provisions caused by the employee's actions. - Public agency exclusion: the Government (including ministries, departments, agencies, and organs of State), statutory bodies gazetted by the Minister, and tribunals appointed under written law are excluded from the Singapore PDPA Data Protection Provisions. - Business contact information (name, position, business phone, business email, business address, business fax) is excluded from the Singapore PDPA Data Protection Provisions when it is not provided solely for personal purposes. Contact information on business or name cards is generally considered business contact information by the PDPC. - If an individual provides business contact information solely for personal purposes (for example, providing a business card to a gym for a personal membership), that information is not business contact information under the Singapore PDPA and the Data Protection Provisions apply. - Personal data in records that have been in existence for at least 100 years is excluded from the Singapore PDPA entirely. - Personal data of a deceased individual who has been dead for more than 10 years is excluded from the Singapore PDPA; for the first 10 years after death, limited obligations (disclosure and protection) still apply to minimise adverse impact on family members. - None of these exclusions remove the obligation to comply with the Singapore PDPA Do Not Call Provisions or other written laws that may apply to the same data. DNC applicability must be assessed independently. ## Singapore PDPA extraterritorial scope and inbound data transfers The Singapore PDPA definition of 'organisation' is deliberately broad in its extraterritorial reach. It covers any individual, company, association, or body of persons 'whether or not formed or recognised under the law of Singapore; or resident, or having an office or a place of business, in Singapore.' This means that a foreign entity that processes personal data in Singapore, or that transfers personal data into Singapore for processing, is within the Singapore PDPA scope for those Singapore-based activities. This aspect of the Singapore PDPA applicability test is critical for multinational companies and overseas service providers. Chapter 11 of the PDPC Advisory Guidelines on Key Concepts addresses inbound data transfers specifically. Where personal data is collected overseas and subsequently transferred into Singapore, the Singapore PDPA Data Protection Provisions apply in respect of the activities involving the personal data in Singapore. The exact obligations depend on whether the receiving entity in Singapore acts as an organisation or as a data intermediary. If the Singapore entity is a data intermediary hosting data on behalf of a foreign organisation under a written contract, the intermediary is subject to the Protection, Retention Limitation, and Data Breach Notification Obligations. If the Singapore entity collects the data for its own purposes, all Data Protection Provisions under the Singapore PDPA apply. For organisations based overseas that transfer personal data into Singapore for their own use, the Singapore PDPA applies from the time the data enters Singapore. The PDPC has stated it will take into account the manner in which personal data was collected in compliance with the data protection laws of the country in which it was originally collected when assessing Consent and Notification Obligation compliance. However, relying on foreign consent alone is not sufficient for the Singapore PDPA applicability test; you must verify that the consent meets Singapore PDPA standards and that the purposes for which the data was originally collected are compatible with your intended use in Singapore. Any organisation in Singapore that subsequently transfers personal data outside Singapore must comply with the Transfer Limitation Obligation under section 26 of the Singapore PDPA, regardless of whether the data originated in Singapore or was first transferred in from overseas. This creates a chain of accountability across borders that must be documented and managed. The organisation will separately have to determine the applicable laws in respect of the data activities involving personal data overseas, as the PDPC notes in its Advisory Guidelines. - Foreign entities that handle personal data in Singapore are subject to the Singapore PDPA for those Singapore-based processing activities, even if the entity has no office or residence in Singapore. This is a key finding in any Singapore PDPA applicability test for multinational companies. - Personal data collected overseas and transferred into Singapore triggers Singapore PDPA obligations from the point of entry into Singapore. The Data Protection Provisions apply in respect of activities involving the personal data in Singapore. - A foreign organisation using a Singapore-based data hosting company as a data intermediary subjects the hosting company to Protection, Retention Limitation, and Data Breach Notification Obligations under the Singapore PDPA. - A Singapore organisation that collects overseas-origin data for its own purposes must comply with all Singapore PDPA Data Protection Provisions, including obtaining valid consent that meets PDPA standards. - The PDPC will consider whether consent was obtained in compliance with the originating country's data protection laws, but this does not replace the need for Singapore PDPA-compliant consent and notification. - If personal data that entered Singapore is later transferred out again, the Transfer Limitation Obligation under section 26 of the Singapore PDPA applies to the outbound transfer, creating a chain of compliance obligations. - Document the origin, routing, and processing jurisdiction of all personal data flows to support extraterritorial applicability assessments under the Singapore PDPA. - Organisations must separately determine the applicable data protection laws in respect of data activities involving personal data overseas, as the Singapore PDPA governs only the Singapore-based processing activities. ## Singapore PDPA sector-specific applicability considerations The Singapore PDPA provides a baseline standard of protection for personal data in Singapore. It complements rather than replaces sector-specific legislative and regulatory frameworks. Organisations in regulated industries must assess Singapore PDPA applicability alongside their sector-specific requirements, because certain activities may be governed by both the PDPA and another Act, or may be partially exempted from the PDPA where the sector-specific law provides equivalent or greater protection. This sector-specific analysis is an important component of any comprehensive Singapore PDPA applicability test. In the healthcare sector, the PDPC has published sector-specific advisory guidelines that address the collection, use, and disclosure of patient data by healthcare providers. The Personal Data Protection (Prescribed Healthcare Bodies) Notification 2015 designates certain healthcare bodies as having specific obligations under the Singapore PDPA. Healthcare organisations must assess whether their processing of patient data falls under the PDPA, the applicable healthcare legislation, or both. Medical records, insurance claims, clinical trial data, and telehealth consultations all require careful applicability mapping. The Singapore PDPA applicability test for healthcare entities should cover both the organisation's own patient data processing and any data intermediary arrangements with laboratories, imaging centres, or third-party clinical systems. In the financial sector, the Banking Act and Insurance Act provide their own data handling requirements. The Singapore PDPA explicitly notes that it complements these sector-specific frameworks. Financial institutions must determine where the Singapore PDPA adds obligations beyond what is already required by MAS (Monetary Authority of Singapore) regulations and guidelines. Common overlapping areas include customer due diligence data, credit assessment records, insurance claim information, and anti-money laundering records. When running the Singapore PDPA applicability test for financial services, organisations should map each data processing activity to both PDPA and MAS regulatory requirements and apply the stricter standard where they overlap. In the telecommunications sector, telecom service providers handle large volumes of personal data, including location data and call records. The PDPC has noted that organisations such as telecom providers can require consent for collecting personal data that is reasonably necessary to supply subscribed services, including location data. Telecom companies must also assess DNC Registry obligations under the Singapore PDPA for any marketing messages sent to Singapore telephone numbers. The Singapore PDPA applicability test for telecom providers should include an assessment of whether location data, call detail records, and subscriber information are processed as an organisation or through data intermediary arrangements with network equipment vendors. - Healthcare: assess Singapore PDPA applicability alongside sector-specific healthcare legislation and the Personal Data Protection (Prescribed Healthcare Bodies) Notification 2015 for patient data handling. Map data intermediary relationships with laboratories, imaging centres, and clinical systems. - Financial services: the Singapore PDPA complements the Banking Act, Insurance Act, and MAS regulations. Map obligations from both regimes and apply the stricter standard where they overlap. Common areas include customer due diligence, credit assessments, and insurance claims. - Telecommunications: personal data including location data and call records is subject to the Singapore PDPA. Consent to collect data reasonably necessary for service provision can be required as a condition of the service. DNC obligations apply to marketing messages. - Education: schools and educational institutions processing student and parent data must comply with the Singapore PDPA unless they qualify as a public agency (for example, government-funded schools that are gazetted statutory bodies). - Real estate: property agents and managing agents handle tenant and buyer personal data and must determine whether they act as organisations or data intermediaries under the Singapore PDPA for each processing activity. - Technology and SaaS: cloud service providers based in Singapore that process data on behalf of clients are likely data intermediaries under the Singapore PDPA and must comply with Protection, Retention Limitation, and Data Breach Notification Obligations. They must also comply with the Transfer Limitation Obligation when data is transferred overseas. - The PDPC publishes sector-specific advisory guidelines and practical guidance documents on its website. Check the PDPC website for the latest guidance relevant to your industry before finalising your Singapore PDPA applicability assessment. - Organisations in regulated industries should document where sector-specific legislation overlaps with the Singapore PDPA and maintain a compliance register that maps each processing activity to both regimes. ## Singapore PDPA Do Not Call (DNC) Registry: applicability triggers The Singapore PDPA Do Not Call (DNC) Provisions, set out in Parts 9 and 9A of the PDPA, operate alongside but are separate from the Data Protection Provisions. Even if certain personal data is excluded from the Data Protection Provisions (for example, business contact information), the DNC Provisions under the Singapore PDPA may still apply to marketing messages sent to Singapore telephone numbers. Organisations must assess DNC applicability independently from their Data Protection Provision analysis as a distinct component of the Singapore PDPA applicability test. The DNC Registry comprises three separate registers maintained by the PDPC under section 39 of the Singapore PDPA, covering telephone calls, text messages, and faxes. Users and subscribers may register their Singapore telephone numbers on one or more of these registers depending on their preferences for receiving marketing messages. Before sending any marketing message to a Singapore telephone number, organisations must check the relevant DNC Register(s) to confirm whether the number is listed. Organisations also have obligations to provide information identifying the individual or organisation who sent or authorised the sending of the marketing message, and must not conceal or withhold the calling line identity. Organisations are not required to check the DNC Registers under the Singapore PDPA in certain circumstances. If the user or subscriber of a Singapore telephone number has given clear and unambiguous consent in written or other accessible form to the sending of the marketing message to that number, the DNC check is not required. Organisations in an ongoing relationship with individuals may also be exempt from checking the DNC Registry before sending certain messages related to the subject of that ongoing relationship. However, verbal consent alone is insufficient for DNC purposes under the Singapore PDPA; consent must be evidenced in written or other accessible form. The Singapore PDPA also prohibits organisations from sending messages to telephone numbers generated or obtained through address-harvesting software, and from using dictionary attacks or similar automated means to send messages indiscriminately. These prohibitions apply regardless of whether the number is on the DNC Registry. The Data Protection Provisions and the DNC Provisions under the Singapore PDPA are intended to operate in conjunction. Accordingly, organisations are required to comply with both sets of provisions when collecting and using Singapore telephone numbers that form part of individuals' personal data. - Singapore PDPA DNC Provisions apply to any organisation sending marketing telephone calls, text messages, or faxes to Singapore telephone numbers, regardless of whether the Data Protection Provisions also apply to the data. - Before sending marketing messages, organisations must check the relevant DNC Register(s) under the Singapore PDPA unless the individual has given clear, unambiguous, written (or otherwise accessible) consent. - The Singapore PDPA DNC Registry has three registers: telephone calls, text messages, and faxes. Organisations must check the register(s) matching their intended message channel before sending marketing messages. - Marketing messages under the Singapore PDPA must identify the sender or the entity that authorised the sending, and must not conceal or withhold the calling line identity of the sender. - Ongoing-relationship exceptions under the Singapore PDPA may exempt organisations from DNC checks for messages related to the subject of the existing relationship with the individual. - Address-harvesting software and dictionary-attack methods for sending marketing messages are prohibited outright under the Singapore PDPA, regardless of DNC Registry status. - Singapore PDPA DNC non-compliance can result in enforcement action by the PDPC separately from Data Protection Provision enforcement. Financial penalties apply independently. - If Singapore telephone numbers form part of an individual's personal data, organisations must comply with both the Singapore PDPA Data Protection Provisions and the DNC Provisions for those numbers. ## Singapore PDPA cross-border transfer applicability: the Transfer Limitation Obligation The Transfer Limitation Obligation under section 26 of the Singapore PDPA prohibits organisations from transferring personal data to a country or territory outside Singapore except in accordance with prescribed requirements. This obligation is triggered whenever personal data under your control or in your possession is transferred overseas, whether directly by your organisation or by a data intermediary acting on your behalf. Assessing cross-border transfer applicability is a key step in any Singapore PDPA applicability test for organisations that use international cloud services, overseas vendors, or multinational group companies. The Singapore PDPA requires that personal data transferred overseas is protected to a standard comparable with the Data Protection Provisions in the PDPA. The onus is on the transferring organisation to undertake appropriate due diligence and obtain assurances from the receiving party. The PDPC Advisory Guidelines describe several compliance avenues: obtaining the individual's consent for the transfer, ensuring contractual protection through binding data processing agreements with clauses that provide a comparable standard of protection, relying on the recipient being bound by comparable legal obligations, or transferring data to a jurisdiction with data protection laws deemed comparable by the PDPC. In undertaking due diligence, organisations may rely on data intermediaries' extant protection policies and practices, including their assurances of compliance with relevant industry standards or certification. When an organisation engages a data intermediary to process personal data and the intermediary transfers data overseas as part of that processing, the organisation remains responsible for Transfer Limitation Obligation compliance under the Singapore PDPA. The PDPC Advisory Guidelines provide clear examples: if you use a cloud storage provider based in Singapore that mirrors data to servers in London and Hong Kong, your organisation must ensure the Transfer Limitation Obligation is satisfied for those transfers, even though the cloud provider initiates the actual data movement. The cloud provider will nonetheless remain responsible for compliance with the Protection, Retention Limitation, and Data Breach Notification Obligations in respect of the personal data it transfers. Organisations should map all cross-border data flows, document the legal basis for each transfer, and maintain records of the due diligence conducted on overseas recipients as part of their Singapore PDPA applicability test. This mapping should cover not only first-tier transfers (to direct vendors) but also onward transfers by vendors to their own sub-processors. The PDPC Advisory Guidelines provide examples of how this chain of accountability works in practice, including cloud services, courier services, and payment processing scenarios. Failure to comply with the Transfer Limitation Obligation can result in PDPC enforcement directions and financial penalties. - Any transfer of personal data outside Singapore triggers the Transfer Limitation Obligation under section 26 of the Singapore PDPA, regardless of whether the transfer is made directly or through a data intermediary. - The transferring organisation must ensure that the overseas recipient provides a standard of protection comparable to the Singapore PDPA Data Protection Provisions. The onus for due diligence and assurance falls on the transferring organisation. - Compliance avenues for the Singapore PDPA Transfer Limitation Obligation include: individual consent, contractual clauses providing comparable protection, binding corporate rules, comparable-jurisdiction determination, or any other prescribed method. - When using a Singapore-based data intermediary that transfers data overseas, the organisation (not the intermediary) bears primary responsibility for Transfer Limitation Obligation compliance under the Singapore PDPA. - Due diligence should include reviewing the data intermediary's security policies, industry certifications (such as ISO 27701 or APEC Cross Border Privacy Rules), and assurances of compliance with relevant data protection standards. - Map and document all cross-border data flows, including onward transfers by vendors to sub-processors, to ensure complete chain-of-accountability coverage under the Singapore PDPA. - Failure to comply with the Singapore PDPA Transfer Limitation Obligation can result in PDPC enforcement directions and financial penalties of up to SGD 1 million, or 10% of annual turnover for organisations with turnover exceeding SGD 10 million. - Data in transit through Singapore (where the data is not accessed, used, or stored in Singapore beyond what is necessary for transmission) may be treated differently. The PDPC Advisory Guidelines address data in transit as a distinct scenario. ## Practical step-by-step Singapore PDPA applicability workflow Use the following eight-step workflow to conduct a comprehensive Singapore PDPA applicability test for your organisation. This workflow is designed to be repeatable across new products, vendor engagements, market expansions, and corporate restructurings. Completing it produces a documented record that serves as evidence of your Singapore PDPA applicability analysis if the PDPC investigates your processing activities. Every organisation is required to comply with the PDPA in respect of activities relating to the collection, use, and disclosure of personal data in Singapore unless they fall within an excluded category. Step 1: Identify the entity. Confirm the legal identity of the entity under assessment. Is it an individual, company, partnership, association, or other body of persons? If it is a public agency (the Government, a statutory body gazetted by the Minister, or a tribunal appointed under written law), it is excluded from the Singapore PDPA Data Protection Provisions. Document the entity's legal form, jurisdiction of incorporation or registration, and whether it has an office or place of business in Singapore. Step 2: Identify the data. Determine whether the data being processed is 'personal data' as defined by the Singapore PDPA. Data is personal data if it is about a natural person (living or deceased for 10 years or less) who can be identified from the data alone or from the data combined with other information the organisation has or is likely to have access to. Apply the PDPC's identifiability threshold: at least two data elements are generally needed before individuals can be identified, and use the 'practicability' standard for assessing access to other information. Exclude business contact information that was not provided solely for personal purposes, data in records over 100 years old, and data about individuals deceased for more than 10 years. Step 3: Determine the capacity. Assess whether the entity is acting in a personal or domestic capacity, as an employee in the course of employment (including volunteers), or in a business or commercial capacity. Only entities acting in a business or commercial capacity are subject to the Singapore PDPA Data Protection Provisions. Document the capacity determination for each processing activity. Step 4: Assign the role. For each processing activity, determine whether the entity acts as an organisation (deciding the purposes and means of processing) or as a data intermediary (processing on behalf of another organisation under a written contract) under the Singapore PDPA. Create a processing activity register that maps each activity to its role. Remember that an entity can hold both roles simultaneously for different processing activities. Step 5: Assess extraterritorial scope. If the entity is based overseas but processes personal data in Singapore, or if personal data is transferred into Singapore, confirm that Singapore PDPA obligations apply to the Singapore-based activities. Document the data flows and identify the point at which PDPA obligations attach. Note that the PDPC will consider compliance with the originating country's data protection laws when assessing consent and notification compliance. Step 6: Check DNC Registry triggers. If the entity sends or plans to send marketing messages (telephone calls, text messages, or faxes) to Singapore telephone numbers, assess Singapore PDPA DNC Registry obligations. Determine whether consent has been obtained in written or accessible form, or whether an ongoing-relationship exception applies. DNC obligations apply independently of the Data Protection Provisions. Step 7: Map cross-border transfers. Identify all transfers of personal data outside Singapore, including transfers by data intermediaries acting on your behalf. Document the legal basis for each transfer and the due diligence conducted on overseas recipients. Include onward transfers by vendors to their own sub-processors to ensure complete chain-of-accountability coverage under the Singapore PDPA. Step 8: Document and review. Compile the Singapore PDPA applicability assessment into a formal record. Include the entity identification, data classification, capacity determination, role assignment, extraterritorial analysis, DNC assessment, and cross-border transfer mapping. Schedule periodic reviews (at least annually or when processing activities change significantly) to keep the assessment current. The PDPC requires organisations to be able to adduce evidence demonstrating compliance in the event of an investigation. - Step 1 - Entity identification: confirm legal form, jurisdiction, and whether the entity qualifies as a public agency (excluded from Singapore PDPA Data Protection Provisions). - Step 2 - Data classification: determine whether each dataset contains personal data as defined by the Singapore PDPA, applying the identifiability test (at least two data elements, practicability threshold) and excluding business contact information, 100-year-old records, and data of individuals deceased for more than 10 years. - Step 3 - Capacity determination: classify each processing activity as personal/domestic (excluded), employee in course of employment including volunteers (excluded), or business/commercial (in scope of Singapore PDPA). - Step 4 - Role assignment: map each processing activity to the organisation role (all eleven Singapore PDPA obligations) or data intermediary role (Protection, Retention Limitation, Data Breach Notification only). Note that entities can hold both roles for different activities. - Step 5 - Extraterritorial scope: assess whether overseas processing activities involve personal data in Singapore and document where Singapore PDPA obligations attach. Consider originating country compliance for consent assessment. - Step 6 - DNC Registry check: determine whether marketing messages to Singapore telephone numbers trigger Singapore PDPA DNC Provisions and verify written consent or exemptions. Assess DNC independently from Data Protection Provisions. - Step 7 - Cross-border transfer mapping: identify all outbound data flows and document compliance with the Singapore PDPA Transfer Limitation Obligation for each transfer, including onward transfers by sub-processors. - Step 8 - Documentation and review: compile the completed Singapore PDPA applicability assessment as a formal compliance record and schedule periodic reviews at least annually. Retain evidence to demonstrate compliance to the PDPC. ## Primary sources - [Personal Data Protection Act 2012 (Singapore) - official text](https://sso.agc.gov.sg/Act/PDPA2012?ref=sorena.io) - Primary legislation governing collection, use, disclosure, protection, retention, transfer, and accountability for personal data in Singapore. Section 2(1) defines 'organisation,' 'data intermediary,' 'personal data,' and 'business contact information.' Parts 3-6A contain the Data Protection Provisions; Parts 9-9A contain the Do Not Call Provisions. Section 26 sets out the Transfer Limitation Obligation. - [PDPC - PDPA overview](https://www.pdpc.gov.sg/overview-of-pdpa/pdpa-overview?ref=sorena.io) - Official PDPC overview covering scope of the PDPA (electronic and non-electronic data), excluded categories (personal/domestic, employee, public agency, business contact information), data protection obligations, DNC Registry, and development timeline from 2013 establishment through 2021 amendments. - [PDPC - Advisory Guidelines on Key Concepts in the PDPA (Revised 16 May 2022)](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-the-personal-data-protection-act?ref=sorena.io) - Core interpretation guidance revised 16 May 2022. Chapters 3-9 cover important terms (individuals, personal data, organisations, data intermediaries, collection/use/disclosure, purposes, reasonableness). Chapter 6 covers data intermediary obligations and considerations. Chapter 11 addresses applicability to inbound data transfers. Chapters 12-21 cover all Data Protection Obligations including Consent, Purpose Limitation, Notification, Access and Correction, Accuracy, Protection, Retention Limitation, Transfer Limitation, Data Breach Notification, and Accountability. - [PDPC - The Distinction between Organisations and Data Intermediaries and Why It Matters](https://www.pdpc.gov.sg/the-distinction-between-organisations-and-data-intermediaries-and-why-it-matters?ref=sorena.io) - PDPC guidance explaining the distinction between organisations (controllers) and data intermediaries (processors) under the Singapore PDPA. Covers all eleven obligations for organisations, the three obligations for data intermediaries (Protection, Retention Limitation, Data Breach Notification), practical examples, and alignment with international privacy standards including GDPR, ISO 27701, and APEC Cross Border Privacy Rules. - [PDPC - Enforcement advisory guidelines](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-enforcement-of-data-protection-provisions?ref=sorena.io) - Enforcement approach, directions, financial penalties (up to SGD 1 million or 10% of annual turnover for organisations with turnover exceeding SGD 10 million), and undertakings. Relevant to understanding the consequences of incorrect applicability assessment under the Singapore PDPA. - [PDPC - Guide to Managing Data Intermediaries](https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Other-Guides/Guide-to-Managing-Data-Intermediaries--2020.pdf?ref=sorena.io) - Comprehensive PDPC guidance for organisations on managing data intermediary relationships, including due diligence, contractual provisions, security requirements, and breach notification. Essential reference for the organisation/data intermediary role determination step in the Singapore PDPA applicability test. - [Personal Data Protection Regulations 2021](https://sso.agc.gov.sg/SL-Supp/S63-2021/Published/20210129?ref=sorena.io) - Subsidiary legislation under the PDPA setting out detailed regulatory requirements that came into effect from 1 February 2021 as part of the PDPA amendments. - [Personal Data Protection (Notification of Data Breaches) Regulations 2021](https://sso.agc.gov.sg/SL-Supp/S64-2021/Published/20210129?ref=sorena.io) - Subsidiary legislation governing the mandatory data breach notification regime under the Singapore PDPA, including notification thresholds, timeframes (three calendar days after assessment), and required content. ## Related Topic Guides - [Singapore PDPA Breach Notification Playbook - Complete Guide](/artifacts/apac/singapore-pdpa/breach-notification-playbook.md): Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline. - [Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026)](/artifacts/apac/singapore-pdpa/checklist.md): Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules. - [Singapore PDPA Compliance Deadlines and Calendar](/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar.md): Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows. - [Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM](/artifacts/apac/singapore-pdpa/compliance.md): Complete Singapore PDPA compliance guide for organisations. - [Singapore PDPA Consent and Notification Obligations Guide](/artifacts/apac/singapore-pdpa/consent-notification-and-purposes.md): Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception. - [Singapore PDPA Cross-Border Transfer Rules | Section 26 Data Transfer Compliance](/artifacts/apac/singapore-pdpa/cross-border-transfers.md): Complete guide to Singapore PDPA cross-border transfer compliance under Section 26. - [Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide](/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages.md): Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses. - [Singapore PDPA FAQ | Frequently Asked Questions on Personal Data Protection Act Compliance](/artifacts/apac/singapore-pdpa/faq.md): Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements. - [Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions](/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases.md): Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover. - [Singapore PDPA Penalties and Fines | SGD 1M or 10% Turnover Cap + PDPC Enforcement Guide](/artifacts/apac/singapore-pdpa/penalties-and-fines.md): Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions. - [Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide](/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template.md): Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions. - [Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC)](/artifacts/apac/singapore-pdpa/requirements.md): Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18). - [Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations](/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries.md): Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion. - [Singapore PDPA Vendor Outsourcing and Contracts Guide](/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts.md): Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence. - [Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties](/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr.md): Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/singapore-pdpa/applicability-test --- --- title: "Singapore PDPA Breach Notification Playbook - Complete Guide" canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/breach-notification-playbook" source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/breach-notification-playbook" author: "Sorena AI" description: "Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Singapore PDPA breach notification" - "Singapore PDPA breach notification playbook" - "PDPA data breach notification guide" - "Singapore data breach notification" - "notifiable data breach Singapore" - "PDPC data breach reporting" - "PDPA 3 day notification deadline" - "significant harm data breach Singapore" - "500 individuals threshold PDPA" - "PDPC breach report form" - "PDPA C.A.R.E. framework" - "breach containment Singapore PDPA" - "data breach management plan PDPA" - "breach notification to affected individuals Singapore" - "PDPA post-breach review" - "data breach self-assessment PDPC" - "PDP DBN Regulations 2021" - "PDPA breach remediation" - "Part 6A PDPA notification obligation" - "prescribed personal data PDPA" - "Singapore PDPA compliance" - "Personal Data Protection Act Singapore" - "Singapore PDPA requirements" - "Singapore PDPA checklist" - "PDPC guidelines" - "Singapore PDPA compliance guide" - "Singapore PDPA compliance checklist" - "PDPA compliance guide Singapore" - "PDPC e-service portal breach notification" - "Singapore PDPA breach management plan template" - "Singapore PDPA" - "Personal Data Protection Act" - "data breach notification playbook" - "PDPC breach reporting" - "C.A.R.E. framework" - "APAC privacy compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Singapore PDPA Breach Notification Playbook - Complete Guide Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline. *Artifact Guide* *APAC* ## Singapore PDPA Breach Notification Playbook Complete Singapore PDPA breach notification playbook: notifiable breach criteria under Part 6A, the 3-calendar-day PDPC reporting deadline, the C.A.R.E. containment framework, prescribed personal data categories, PDPC self-assessment checklist, notification templates for affected individuals, and post-breach review procedures. Grounded in the official PDPC Guide on Managing and Notifying Data Breaches (revised 15 March 2021) and the PDP (Notification of Data Breaches) Regulations 2021. Reduce time-to-decision with PDPC-grounded thresholds, pre-built escalation paths, and rehearsed Singapore PDPA breach notification workflows. This Singapore PDPA breach notification playbook provides an implementation-focused guide for handling data breaches under the Personal Data Protection Act (PDPA). It is written for Data Protection Officers (DPOs), incident response teams, legal counsel, security engineers, and compliance managers who must assess, contain, report, and remediate personal data breaches within the mandatory timelines set by the Personal Data Protection Commission (PDPC). The Singapore PDPA breach notification obligation, introduced under Part 6A of the PDPA and effective from 1 February 2021, requires organisations to notify the PDPC within three calendar days of determining that a breach is notifiable, and to notify affected individuals as soon as practicable. The guidance below is grounded in the PDPC Guide on Managing and Notifying Data Breaches (revised 15 March 2021), the Personal Data Protection (Notification of Data Breaches) Regulations 2021 (PDP (DBN) Regulations 2021), the PDPC Advisory Guidelines on Key Concepts in the PDPA, and the PDPC online self-assessment tool. Tailor every workflow, template, and threshold in this Singapore PDPA breach notification playbook to your organisation's data processing context, business operations, and risk profile. ## What counts as a notifiable data breach under the Singapore PDPA Under Part 6A of the Singapore PDPA, a data breach is defined as any unauthorised access, collection, use, disclosure, copying, modification, or disposal of personal data. It also includes the loss of any storage medium or device containing personal data where unauthorised access, collection, use, disclosure, copying, modification, or disposal of the personal data is likely to occur. Data breaches under the Singapore PDPA can result from malicious activities such as hacking, ransomware attacks, and distributed denial of service incidents, from human errors like misdirected emails, lost devices, and improper disposal of records, or from computer system weaknesses including unpatched software, misconfigured databases, and bugs in web applications. Understanding the full scope of what constitutes a data breach is the first step in any Singapore PDPA breach notification assessment. Not every data breach triggers a mandatory Singapore PDPA breach notification. The PDPA requires notification to the PDPC only when a breach meets one of two independent criteria. The first criterion is significant harm: the data breach involves prescribed personal data that, if compromised, is likely to result in significant harm to affected individuals. The PDP (Notification of Data Breaches) Regulations 2021 prescribe the specific categories of personal data that are deemed to cause significant harm when compromised. Significant harm under the Singapore PDPA includes physical safety harm, psychological and emotional harm, identity theft and fraud, financial loss, loss of business or employment opportunities, and damage to reputation. A reasonable person test applies: if a reasonable person would identify the harm as a possible outcome of the breach, the harm is significant. The second criterion for a Singapore PDPA breach notification is significant scale: the breach involves the personal data of 500 or more individuals, regardless of the type of data compromised. When a data breach affects 500 or more individuals, the organisation must notify the PDPC even if the breach does not involve any of the prescribed personal data categories listed in the PDP (DBN) Regulations 2021. If the organisation cannot determine the exact number of affected individuals at the time of assessment, it should notify the PDPC when it has reason to believe that the number is at least 500, based on an initial appraisal. The organisation may subsequently update the PDPC with the actual number once it is established. Organisations must understand that the two criteria for Singapore PDPA breach notification operate independently. A breach that meets either criterion is notifiable. A breach involving prescribed personal data of even a single individual is notifiable if significant harm is likely. A breach affecting 500 or more individuals is notifiable regardless of the data type. Compliance teams should maintain a reference list of prescribed personal data categories from the PDP (DBN) Regulations 2021 and include it in the breach response toolkit. Context matters in the assessment: consider whether the data was encrypted, anonymised, publicly available before the breach, or accessed by parties with malicious intent, as these factors affect the likelihood of harm. - Significant harm criterion: the Singapore PDPA breach notification is required when a breach involves prescribed personal data (such as NRIC numbers, financial account details, health data, or authentication credentials) likely to cause significant harm to individuals. - Significant scale criterion: the Singapore PDPA breach notification is required when a breach affects the personal data of 500 or more individuals, regardless of the data type involved. - The two criteria are independent: meeting either one triggers the mandatory Singapore PDPA breach notification obligation to the PDPC. - If the exact count of affected individuals is unknown, notify the PDPC based on the estimated number from the initial appraisal and update later when the actual count is established. - Prescribed personal data categories are defined in the PDP (Notification of Data Breaches) Regulations 2021 and include NRIC numbers, passport numbers, financial account information, and health-related data. - Significant harm includes physical safety, psychological harm, identity theft, fraud, financial loss, loss of employment opportunities, and reputational damage as assessed by a reasonable person test. - Context matters: consider whether data was encrypted, anonymised, publicly available, or accessed by parties with malicious intent when assessing the likelihood of significant harm. - Maintain a quick-reference card listing all prescribed data categories in your incident response binder for rapid Singapore PDPA breach notification assessment. ## Singapore PDPA breach notification: the 3-calendar-day PDPC reporting deadline The Singapore PDPA breach notification deadline is strict and non-negotiable. Once an organisation determines that a data breach is notifiable under the PDPA, it must notify the PDPC as soon as practicable, but no later than three (3) calendar days. The countdown begins on the day after the organisation makes the determination. For example, if the organisation determines on 1 January that a breach is notifiable, the Singapore PDPA breach notification must reach the PDPC by 4 January. Any unreasonable delay in providing the Singapore PDPA breach notification constitutes a breach of the Data Breach Notification (DBN) Obligation and exposes the organisation to enforcement action, including financial penalties imposed by the PDPC. Before the 3-day clock starts, organisations have a duty to assess whether the breach is notifiable under the Singapore PDPA. This assessment must be conducted with reasonable and expeditious steps. The PDPC expects the assessment to be completed within 30 calendar days from the time the organisation has credible grounds to believe that a breach has occurred. Credible grounds can arise from self-discovery, an alert from the public, or notification by a data intermediary that processes personal data on behalf of the organisation. If the assessment takes longer than 30 days, the organisation should be prepared to explain the delay to the PDPC with supporting documentation. An unreasonable delay in the assessment phase itself is a contravention of the Singapore PDPA breach notification obligation. Organisations must document all steps taken during the assessment process for Singapore PDPA breach notification compliance. This documentation serves two important purposes. First, it demonstrates that the organisation took reasonable and expeditious steps as required by the PDPA. Second, it may be requested by the PDPC as part of the notification submission or during any subsequent investigation. The PDPC may require the organisation to produce supporting documentation on the steps taken for its assessment of the data breach. Failure to document the assessment process can itself constitute a contravention of the DBN Obligation and weaken the organisation's position in any enforcement proceedings. To meet the Singapore PDPA breach notification 3-day deadline consistently, organisations should pre-designate a breach assessment team with clear roles and contact details, pre-draft decision trees for common breach scenarios such as ransomware attacks, misdirected emails, and lost devices, and maintain updated contact details for the PDPC reporting portal and the PDPC phone line (+65 6377 3131) for urgent notification of major cases. The team should rehearse the assessment-to-notification pipeline at least annually through tabletop exercises and breach simulation drills. Organisations that invest in this preparation will find the Singapore PDPA breach notification process manageable even under the pressure of an active incident. - 3 calendar days: the maximum time from determination of notifiability to Singapore PDPA breach notification to the PDPC. - Day count starts on the day after the determination, not the day of the determination itself. If you determine notifiability on Monday, the deadline is Thursday. - Assessment must be conducted with reasonable and expeditious steps within 30 calendar days of credible grounds that a breach has occurred. - Credible grounds include self-discovery, public alerts, notification from a data intermediary, or reports from affected individuals. - Document every step of the assessment: dates, people involved, evidence reviewed, conclusions reached, and the reasoning behind the notifiability determination. - Late Singapore PDPA breach notifications must include reasons for the delay with supporting evidence; lateness is a contravention factor in penalty assessment by the PDPC. - Submit notifications via the PDPC e-service portal at https://eservice.pdpc.gov.sg/case/db. - For urgent notification of major cases, also contact the PDPC directly at +65 6377 3131 during working hours. - Run annual tabletop exercises to verify the team can complete the assessment-to-notification cycle within the Singapore PDPA breach notification deadline. *Recommended next step* *Placement: after the workflow or playbook section* ## Turn Singapore PDPA Breach Notification Playbook into an operational assessment Assessment Autopilot can take Singapore PDPA Breach Notification Playbook from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on Singapore PDPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Singapore PDPA Breach Notification Playbook](/solutions/assessment.md): Start from Singapore PDPA Breach Notification Playbook and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Singapore PDPA](/contact.md): Review your current process, evidence gaps, and next steps for Singapore PDPA Breach Notification Playbook. ## Singapore PDPA breach notification to affected individuals: requirements and best practices When a data breach involves prescribed personal data likely to cause significant harm, the Singapore PDPA breach notification obligation requires the organisation to notify affected individuals as well as the PDPC. The notification to affected individuals must happen as soon as practicable, and it must occur at the same time as or after the PDPC notification. Organisations must never notify affected individuals before notifying the PDPC. For data breaches likely to attract widespread public attention or media interest, the PDPC strongly encourages organisations to notify the Commission first and seek guidance before notifying affected individuals or issuing any public or media statements. This sequencing is a critical aspect of Singapore PDPA breach notification compliance. The Singapore PDPA breach notification to affected individuals must be clear, easily understood, and must include specific categories of information mandated by the PDP (DBN) Regulations 2021. The organisation must disclose the circumstances in which it first became aware that the breach occurred, the personal data or classes of personal data affected, the potential harm to the individual as a result of the breach, the actions taken or planned to eliminate or mitigate harm and address root causes, the steps the individual can take to protect themselves and prevent misuse of their personal data, and contact details for at least one authorised representative whom the individual can reach for further information or assistance. Every element is required; omitting any one weakens the notification and may constitute a separate contravention. Effective Singapore PDPA breach notification empowers individuals to take protective action. For example, individuals can change account passwords, cancel compromised credit cards, monitor bank statements for unusual transactions, enable two-factor authentication, or watch for phishing attempts that exploit the compromised data. Organisations should tailor protective recommendations to the specific data types involved. If financial account data was exposed, recommend card replacement, account monitoring, and contacting the relevant bank. If identity document numbers such as NRIC numbers were involved, suggest credit monitoring, fraud alerts, and vigilance against impersonation. If authentication credentials were exposed, recommend immediate password changes and enabling multi-factor authentication across all accounts that used the same credentials. Where the Singapore PDPA breach notification involves personal data related to minors, the organisation should notify parents or guardians rather than the minors themselves. Where the breach involves information related to adoption matters or the identification of vulnerable individuals, the organisation should notify the PDPC first for guidance on how to approach the notification to affected individuals. Organisations may customise the format and channel of their notification (email, letter, phone, or SMS) as long as it includes all required content. Keep a record of every notification sent, including the date, channel, recipient count, and the content provided, as this documentation may be required by the PDPC during enforcement proceedings. - Notify affected individuals as soon as practicable, at the same time as or after notifying the PDPC under the Singapore PDPA breach notification obligation. - Never notify individuals before the PDPC; seek PDPC guidance first for data breaches likely to attract widespread public attention or media interest. - Required content: circumstances of discovery, data types affected, potential harm, mitigation actions taken, self-help steps for the individual, and representative contact details. - Tailor recommended protective actions to the data types involved: password changes for credential breaches, card cancellation for financial data, credit monitoring for identity document exposure. - Notify parents or guardians when a minor's personal data is compromised under the Singapore PDPA breach notification process. - Consult the PDPC before notifying individuals when adoption matters or vulnerable individual data is involved. - Keep a record of every notification sent: date, channel, recipient count, and content provided for Singapore PDPA breach notification compliance documentation. - The authorised representative in the notification to individuals need not be the DPO or the same person listed in the PDPC notification. ## Singapore PDPA breach notification self-assessment checklist The PDPC provides an online self-assessment tool to help organisations determine whether a data breach is notifiable under the Singapore PDPA breach notification obligation. The tool walks through a structured set of questions about the nature of the breach, the types of personal data involved, the number of affected individuals, and the likelihood of significant harm. The PDPC states that organisations may use this self-assessment tool to assist with the determination of whether a data breach incident is notifiable, and encourages organisations to err on the side of caution if they are unsure which answer to choose. However, the tool is advisory only. The PDPC explicitly states that the result is not definitive in the assessment of any decision not to notify, and it is not a substitute for the organisation's own assessment obligations under the Singapore PDPA. Beyond the PDPC online tool, organisations should build an internal self-assessment checklist tailored to their data environment for Singapore PDPA breach notification readiness. The checklist should first establish the facts: what data was compromised, how many individuals are affected (or estimated), whether the data is prescribed under the PDP (DBN) Regulations 2021, and whether the breach is ongoing or contained. Next, the checklist should evaluate the context: was the data encrypted or anonymised, was it publicly available before the breach, who accessed it (malicious actors, unintended recipients, or internal staff), and how long was the data exposed before containment. These contextual factors are directly referenced in the PDPC Guide on Managing and Notifying Data Breaches as relevant to the Singapore PDPA breach notification assessment. The assessment must also consider the ease of identifying individuals from the compromised data. The PDPC guidance states that the ease with which an affected individual can be identified from the compromised data increases the likelihood of harm to the individual. A dataset containing full names, NRIC numbers, and phone numbers is far more identifiable than one containing only membership IDs and postal codes. The more identifiers present and the more unique they are, the higher the risk of significant harm under the Singapore PDPA breach notification criteria. The duration of exposure also matters: data that was publicly accessible for weeks before discovery carries higher risk than data that was exposed for minutes before containment. Document the answers to every question in the self-assessment for Singapore PDPA breach notification compliance. Record who performed the assessment, when each step was completed, what evidence was reviewed, and the reasoning behind the final determination. This documentation may be required by the PDPC as part of the notification or during an investigation. The PDPC may require the organisation to produce supporting documentation on the steps taken for its assessment of the data breach. An organisation that cannot produce assessment records faces a higher risk of enforcement action for failing to take reasonable and expeditious steps as required by the Singapore PDPA. - Use the PDPC online self-assessment tool at https://www.pdpc.gov.sg/report-data-breach/self-assessment as a first-pass filter for Singapore PDPA breach notification assessment. - The PDPC states this tool is advisory only: the result does not replace the organisation's own assessment obligations under the Singapore PDPA. - Internal checklist question 1: Does the breach involve prescribed personal data under the PDP (DBN) Regulations 2021 (NRIC numbers, passport numbers, financial accounts, health data, authentication credentials)? - Internal checklist question 2: Is significant harm (physical, financial, identity theft, reputational, emotional) a likely outcome for affected individuals based on the reasonable person test? - Internal checklist question 3: Are 500 or more individuals affected or estimated to be affected, triggering the significant scale criterion? - Internal checklist question 4: Was the data encrypted, anonymised, or otherwise protected at the time of the breach, reducing the likelihood of harm? - Internal checklist question 5: How easily can individuals be identified from the compromised dataset based on the number and uniqueness of identifiers? - Internal checklist question 6: Was the breach caused by malicious actors with intent to exploit the data (higher risk) or by accidental misdirection to a recipient without malicious intent (lower risk)? - Internal checklist question 7: How long was the data exposed before containment, and has it been made publicly accessible during that period? - Document every answer: assessor name, date, evidence reviewed, and the final determination with reasoning for Singapore PDPA breach notification compliance. ## Singapore PDPA breach containment and remediation using the C.A.R.E. framework The PDPC recommends the C.A.R.E. framework as the baseline operational framework for responding to data breaches under the Singapore PDPA. The acronym stands for Contain, Assess, Report, and Evaluate. These four steps provide a structured approach that helps organisations respond swiftly, minimise harm, meet the Singapore PDPA breach notification obligations, and learn from each incident. The C.A.R.E. framework is jointly developed by the Cyber Security Agency of Singapore (CSA) and the Personal Data Protection Commission. It is meant to guide organisations in stressful and high-pressured situations to contain and recover from an incident quickly and effectively. Every data breach response must be tailored to the circumstances, but the C.A.R.E. sequence should serve as the standard playbook for all breach incidents. Contain: Act immediately when a data breach is suspected or confirmed under the Singapore PDPA. Activate the data breach management team and assign the designated incident response handler. Conduct an initial appraisal to determine severity: what data is involved, how many individuals are affected, which systems are compromised, and whether the breach is still ongoing. Execute containment actions such as isolating compromised systems from the Internet or network by disconnecting all affected systems, re-routing or filtering network traffic, firewall filtering, closing particular ports or mail servers, disabling affected user accounts, resetting passwords, and recalling misdirected communications where possible. Record all containment actions in an incident log with timestamps. Obtain forensic copies and logs of the affected IT systems for follow-up investigations, incident resolution, and legal proceedings purposes before restoring or wiping any affected systems. Assess: After initial containment, conduct a thorough assessment to support the Singapore PDPA breach notification determination. Determine the root cause of the breach and evaluate whether containment actions are effective. Identify all affected data subjects and data categories. Evaluate the likelihood of significant harm by considering the context, the ease of identification, and the circumstances of the breach. Determine whether the breach is notifiable to the PDPC under the significant harm or significant scale criteria. Gather and preserve evidence including forensic copies, system logs, incident indicators, and network traffic records for potential legal proceedings. This assessment phase must be completed with reasonable and expeditious steps within 30 calendar days of credible grounds. Report: If the breach is notifiable, submit the Singapore PDPA breach notification to the PDPC within 3 calendar days via the e-service portal at https://eservice.pdpc.gov.sg/case/db. For urgent notification of major cases, also contact the PDPC at +65 6377 3131 during working hours. Notify affected individuals as soon as practicable after or at the same time as notifying the PDPC. Also consider whether other regulators (Monetary Authority of Singapore, Ministry of Health, Cyber Security Agency of Singapore) or law enforcement need to be notified under their respective frameworks. Alert the Singapore Police Force if criminal activity such as hacking, theft, or unauthorised system access is suspected. Contact SingCERT (Singapore Computer Emergency Response Team) for cyber incidents. Evaluate: After the breach is resolved, conduct a post-breach review as part of the Singapore PDPA breach notification lifecycle. Analyse the root cause, the effectiveness of the response, and the adequacy of existing controls. Review whether the data breach management plan was followed correctly and whether responders understood their roles. Develop a prevention plan with specific, measurable actions. Update the data breach management plan, security policies, training programmes, and vendor contracts based on lessons learned. Run audits to verify that corrective measures have been implemented. This evaluation phase is not optional: the PDPC expects organisations to demonstrate continuous improvement in their data protection practices. - Contain: isolate compromised systems, disable breached accounts, reset passwords, filter traffic, recall misdirected data, and log all actions with timestamps. - Assess: determine root cause, evaluate containment effectiveness, identify affected individuals and data categories, and determine notifiability under the Singapore PDPA breach notification criteria. - Report: submit the Singapore PDPA breach notification to the PDPC within 3 calendar days, notify affected individuals as soon as practicable, and alert police and SingCERT if criminal activity or cyber incidents are involved. - Evaluate: conduct root cause analysis, update the breach management plan, revise policies and training, audit corrective measures, and review vendor responsibilities. - The C.A.R.E. framework was jointly developed by the Cyber Security Agency of Singapore and the PDPC for use in stressful, high-pressure breach response situations. - Activate the breach management team immediately upon detection of a suspected or confirmed breach under the Singapore PDPA. - Preserve forensic copies, system logs, and incident indicators before restoring or wiping affected systems to support investigations and legal proceedings. - Consider alerting the Monetary Authority of Singapore, Ministry of Health, or CSA if sector-specific reporting requirements apply alongside the Singapore PDPA breach notification. ## Cyber incident response checklist for Singapore PDPA data breach response The Cyber Security Agency of Singapore (CSA) and the Personal Data Protection Commission (PDPC) jointly developed a cyber incident response checklist to guide organisations through stressful, high-pressure Singapore PDPA data breach situations. This checklist follows the C.A.R.E. framework and is designed to improve response time and minimise damages. Organisations should integrate this checklist into their data breach management plan and use it both during active Singapore PDPA data breach incidents and when developing or testing incident response procedures. During the Contain phase of a Singapore PDPA data breach, the checklist requires organisations to alert the incident response team (including the incident response handler, incident response service provider, and product or service vendors), consider alerting regulatory bodies, law enforcement agencies, SingCERT, and business clients. Organisations must identify investigation resources: a list of key assets and data with their locations, network diagrams, the current baseline of IT systems activities, documentation of IT systems and software versions, and backups of important data. Recognise possible attack vectors: poorly designed web applications, misconfigured systems, internet downloads, poor cyber hygiene practices (such as use of weak or default passwords and outdated software), human lapses, and authorised third parties. The checklist also covers reviewing possible sources of precursors and indicators for the Singapore PDPA data breach: security software (Intrusion Detection Systems, Security Information and Events Management Systems, anti-virus software, third-party monitoring services), logs (operating system, service and application, network device, netflow), publicly available information (SingCERT alerts and advisories, vendor vulnerability advisories), and reports from people within your organisation. Correlate events against the baseline to determine if an incident has occurred. Check incidents against known threat precursors and indicators. Make an initial assessment of the scope and nature of the incident, particularly whether it is a malicious act or a technological glitch. Prioritise incident handling activities, including whether to activate crisis management and communications plans. During the Assess phase of the Singapore PDPA data breach, gather evidence for both incident resolution and potential legal proceedings: incident summary, incident indicators, system events, actions taken during the incident, logs of affected systems, and forensic copies of affected systems. Eradicate the threat: wipe malware, disable breached user accounts, and patch exploited vulnerabilities across all affected hosts within the organisation. Take recovery steps: restore systems from backups, rebuild systems from scratch, install patches, change all passwords (both administrators and users), tighten network perimeter security, and confirm the integrity of business systems and controls. During the Report phase, notify relevant stakeholders and affected parties: the Board of Directors, regulators and law enforcement (SPF, PDPC, CSA, SGX), clients, and media as appropriate. During the Evaluate phase, continue monitoring the network for any anomalous activity or signs of intrusion. Depending on the incident, consider higher levels of system logging or network monitoring. Conduct a post-incident review: identify and resolve deficiencies in systems and processes that led to the incident, identify and resolve deficiencies in the incident response plan, assess if additional security measures are needed, and communicate lessons learned. Revise all related plans: prevention and detection plans, containment and recovery plans, crisis management and communications plans, and business continuity plans. - The cyber incident response checklist was jointly developed by CSA and the PDPC for Singapore PDPA data breach response situations. - Contain: alert incident response team, identify investigation resources (asset lists, network diagrams, system baselines, software documentation, backups). - Recognise attack vectors: poorly designed web applications, misconfigured systems, poor cyber hygiene, internet downloads, human lapses, authorised third parties. - Review precursors and indicators: security software (IDS, SIEM, anti-virus), system logs, SingCERT advisories, vendor vulnerability alerts, internal reports. - Make an initial assessment: correlate events against baseline, check against known threat indicators, determine if the incident is malicious or a system glitch. - Containment strategies for Singapore PDPA data breaches: isolate compromised networks, re-route traffic, apply firewall filtering, close vulnerable ports, block unauthorised access. - Evidence gathering: incident summary, indicators, system events, actions taken, logs of affected systems, and forensic copies for incident resolution and legal proceedings. - Eradication: wipe malware, disable breached user accounts, patch exploited vulnerabilities across all affected hosts in the organisation. - Recovery: restore from backups, rebuild systems, install patches, change all passwords (administrators and users), tighten network perimeter, confirm business system integrity. - Report: notify Board of Directors, regulators (PDPC, MAS, CSA), law enforcement (SPF), clients, and media as appropriate for the Singapore PDPA data breach. - Evaluate: monitor for anomalous activity, consider higher logging levels, conduct post-incident review, resolve deficiencies, and revise all related plans. ## Singapore PDPA breach notification: data breach management plan template Having a data breach management plan in place before a breach occurs is essential for Singapore PDPA breach notification readiness. The PDPC emphasises that organisations without a plan will find it chaotic and challenging to respond effectively during an actual breach. Planning to manage a data breach is best done early. The plan should be developed proactively, reviewed at least annually, and updated whenever business operations change. Key stakeholders, including the DPO, senior management, IT security, legal counsel, and communications staff, should be familiar with their roles through periodic walkthroughs and tabletop exercises. Response time is a key factor in minimising impact from data breaches, and a well-rehearsed plan directly supports the organisation's ability to meet the Singapore PDPA breach notification deadline. The data breach management plan should begin with a clear definition of what constitutes a data breach in the organisation's context, covering both suspected and confirmed incidents. The Singapore PDPA defines a breach broadly: any unauthorised access, collection, use, disclosure, copying, modification, or disposal of personal data, and the loss of any storage medium or device containing personal data where unauthorised access is likely to occur. The plan should specify the internal reporting chain: when an employee becomes aware of a potential breach, who do they contact, and through what channels. Include names, roles, phone numbers, and email addresses for the data breach management team, the DPO, senior management, external legal counsel, forensic specialists, and the PDPC reporting contact. The response procedures section should detail containment strategies for common breach scenarios relevant to your organisation: ransomware attack, misdirected email, lost device, insider access, and vendor compromise. Each scenario should map to specific containment actions, assessment criteria, and notification decision trees that support rapid Singapore PDPA breach notification determination. Include pre-drafted templates for PDPC notifications and affected individual notifications. Pre-drafting these templates reduces time pressure during an active incident and ensures all required fields mandated by the PDP (DBN) Regulations 2021 are covered. Templates should include placeholders for the facts of the breach, breach handling details, and contact details. The plan should also address communication protocols for Singapore PDPA breach notification scenarios. Define when and how to brief the board of directors, media, clients, and business partners. Establish clear rules about who is authorised to make public statements. The PDPC strongly encourages organisations to notify the Commission before issuing any public or media statements for data breaches likely to attract widespread public attention. Finally, the plan should include a post-breach review section with checklists for root cause analysis, corrective actions, and plan revision. Train all employees on breach identification and the internal reporting procedure during onboarding and at regular intervals to ensure that the first-response link in the Singapore PDPA breach notification chain is strong. - Define what constitutes a data breach under the Singapore PDPA: unauthorised access, collection, use, disclosure, copying, modification, disposal, or loss of storage media where unauthorised access is likely. - Specify the internal reporting chain: employee discovery to DPO to breach management team to senior management for Singapore PDPA breach notification assessment. - Include a contact directory with names, roles, phone numbers, and emails for all key responders, external advisors, and the PDPC reporting contact. - Map containment strategies to common scenarios: ransomware, misdirected email, lost device, insider access, and vendor compromise. - Pre-draft PDPC notification and affected individual notification templates with all required fields from the PDP (DBN) Regulations 2021. - Define communication protocols for the board, media, clients, and business partners during a Singapore PDPA breach notification event. - Establish rules for public statements: the PDPC must be notified before any public or media disclosure for high-profile breaches. - Schedule annual reviews, tabletop exercises, and post-breach plan revisions to keep the data breach management plan current. - Train all employees on breach identification and the internal reporting procedure during onboarding and at regular intervals. ## Singapore PDPA breach notification: PDPC reporting form and submission process Organisations submit Singapore PDPA breach notifications to the PDPC through the online e-service portal at https://eservice.pdpc.gov.sg/case/db. For urgent notification of major cases, organisations may also contact the PDPC at +65 6377 3131 during working hours. The portal collects structured information about the breach, the organisation's response, and the remediation plan. Preparing this information in advance, using a pre-populated worksheet that mirrors the PDPC form fields, significantly reduces the time needed to complete the submission and helps the organisation stay within the 3-calendar-day Singapore PDPA breach notification deadline. The Singapore PDPA breach notification to the PDPC must include three categories of information. The first category covers the facts of the breach: the date on which and the circumstances in which the organisation first became aware that the breach occurred, information on how the notifiable data breach occurred, the number of affected individuals, the personal data or classes of personal data compromised, and the potential harm to affected individuals. The second category covers data breach handling: a chronological account of all steps taken after discovery, including the assessment that the breach is notifiable, actions taken or planned to eliminate or mitigate harm to affected individuals, actions taken to address or remedy root causes and shortcomings, and the plan (if any) to notify affected individuals or the public. The third category of the Singapore PDPA breach notification form is contact details. The organisation must provide contact information for at least one authorised representative. This representative does not need to be the DPO or a person assuming the DPO's responsibilities. If the Singapore PDPA breach notification is submitted late (after the 3-day window), the organisation must also include the reasons for the delay with supporting evidence. The PDPC will consider the reasons for lateness when evaluating the severity of the organisation's contravention of the DBN Obligation and consequently the nature and severity of any penalties imposed. Where the organisation decides not to notify affected individuals (for example, based on an exemption under section 26D(5) or (6)(a) of the PDPA, or a prohibition or restriction under other written law), the Singapore PDPA breach notification to the PDPC must additionally specify the grounds for not notifying individuals. Organisations should prepare a standardised internal worksheet that mirrors the PDPC form fields so the breach management team can collect the required information in parallel with containment and assessment activities. Keep a copy of every Singapore PDPA breach notification submitted to the PDPC, including the submission timestamp and any reference numbers received, as part of the compliance documentation trail. - Submit the Singapore PDPA breach notification via the PDPC e-service portal: https://eservice.pdpc.gov.sg/case/db. - For urgent notification of major cases, also contact the PDPC at +65 6377 3131 during working hours. - Facts of the breach: discovery date, circumstances, method of breach, number of affected individuals, personal data types compromised, and potential harm. - Breach handling: chronological account of steps taken, assessment process, mitigation actions, root cause remediation, and affected individual notification plan. - Contact details: at least one authorised representative (does not need to be the DPO) with contact information for PDPC follow-up. - Late Singapore PDPA breach notification: must include reasons for delay with supporting evidence; lateness is a factor in penalty severity assessment by the PDPC. - If individuals will not be notified, state the legal grounds (PDPA section 26D(5) or (6)(a) exemptions or other written law prohibitions) in the PDPC notification. - Pre-populate a worksheet that mirrors the PDPC form fields to accelerate submission during an active incident. - Keep a copy of every Singapore PDPA breach notification submitted, including the timestamp, content, and any reference numbers received from the PDPC. ## Post-breach review and continuous improvement under the Singapore PDPA The PDPC expects organisations to learn from every data breach and improve their data protection practices to prevent recurrence. The post-breach review is a critical component of the Singapore PDPA breach notification lifecycle and should begin as soon as the immediate incident is resolved. This review should cover root cause analysis, response effectiveness, and systemic improvements. Conducting a thorough post-breach review is not just best practice; it is a concrete way to demonstrate accountability to the PDPC if the organisation faces future breaches or enforcement actions. The PDPC may consider the organisation's track record of learning from past breaches when determining enforcement responses. The root cause analysis should trace the breach back to its origin. Determine the chronological timeline of events that led up to the incident, identify the weakness exploited (system vulnerability, procedural gap, or human error), and establish whether the issue was previously known. Assess whether existing monitoring tools, access controls, and security measures detected the breach in a timely manner and whether the containment actions were effective. Review whether the data breach management plan was followed correctly, whether responders understood and properly executed their roles, and whether the Singapore PDPA breach notification deadlines were met. Evaluate whether there was a clear line of responsibility and communication during the management of the breach. Based on the findings, develop a prevention plan with specific, measurable actions. This may include patching system vulnerabilities, implementing new access controls, enhancing encryption, updating software, tightening network perimeter security, revising vendor contracts to clearly define responsibilities for personal data handling, or redesigning data handling workflows. Assign owners and deadlines for each action item. Conduct follow-up audits to verify that the prevention plan has been fully implemented and that the changes are effective. This audit step ensures that lessons learned are translated into tangible improvements rather than remaining as recommendations on paper. The review should also address organisational and training issues identified during the Singapore PDPA breach notification process. Were employees aware of security best practices and breach identification procedures? Was the DPO adequately resourced? Did the breach management team have enough personnel, tools, and authority? Should external specialists such as forensic investigators or specialised legal counsel be engaged for future incidents? Update training programmes with lessons learned from the breach and communicate the findings across the organisation so all staff understand the risks and the improvements being made. Finally, revise all related plans: the data breach management plan, crisis communications plan, business continuity plan, and prevention and detection plans. Maintain a breach register that tracks every incident, the assessment outcome, the Singapore PDPA breach notification status, response actions, and lessons learned for audit and accountability purposes. - Conduct root cause analysis: determine the chronological timeline, the weakness exploited, whether the issue was previously known, and whether monitoring detected the breach in a timely manner. - Evaluate response effectiveness: was the data breach management plan followed, were responders clear on their roles, and were containment actions and Singapore PDPA breach notification deadlines met? - Develop a prevention plan: patch vulnerabilities, update access controls, enhance encryption, revise vendor contracts, and redesign workflows based on findings. - Assign owners and deadlines for every corrective action and conduct follow-up audits to confirm full implementation. - Review operational issues: was the breach management team adequately resourced, and should external specialists be engaged for future incidents? - Update employee training programmes with lessons learned and communicate findings across the organisation. - Revise all related plans: data breach management plan, crisis communications plan, business continuity plan, and prevention and detection plans. - Consider whether higher levels of system logging, network monitoring, or intrusion detection are needed after the incident. - Maintain a breach register that tracks every incident, the assessment outcome, the Singapore PDPA breach notification status, response actions, and lessons learned for audit purposes. ## Primary sources - [Personal Data Protection Act 2012 (Singapore) - official text](https://sso.agc.gov.sg/Act/PDPA2012?ref=sorena.io) - Primary legislation governing collection, use, disclosure, protection, retention, transfer, and accountability for personal data in Singapore. Part 6A sets out the Data Breach Notification Obligation that underpins all Singapore PDPA breach notification requirements. - [PDPC - Guide on Managing and Notifying Data Breaches under the PDPA (revised 15 March 2021)](https://www.pdpc.gov.sg/help-and-resources/2021/01/data-breach-management-guide?ref=sorena.io) - Official breach handling guidance covering the C.A.R.E. framework, data breach management plans, notification requirements, timelines, and post-breach evaluation. This is the primary reference for the Singapore PDPA breach notification playbook. - [PDPC - Report a data breach](https://www.pdpc.gov.sg/report-data-breach?ref=sorena.io) - Official reporting entry point with links to the self-assessment tool and the e-service portal at https://eservice.pdpc.gov.sg/case/db for Singapore PDPA breach notification submission. - [PDPC - Self-assessment for organisations experiencing data breaches](https://www.pdpc.gov.sg/report-data-breach/self-assessment?ref=sorena.io) - Online self-assessment tool to help organisations determine whether a data breach is notifiable under the Singapore PDPA breach notification obligation. Advisory only; does not replace the organisation's own assessment. - [PDPC - Advisory Guidelines on Key Concepts in the PDPA](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-the-personal-data-protection-act?ref=sorena.io) - Core interpretation guidance including the DBN Obligation section covering Singapore PDPA breach notification criteria, timelines, and information requirements. - [PDPC - Advisory Guidelines on Enforcement of Data Protection Provisions](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-enforcement-of-data-protection-provisions?ref=sorena.io) - Enforcement approach, directions, financial penalties, and undertakings. Relevant to understanding the consequences of failing to comply with Singapore PDPA breach notification obligations. - [PDPC - PDPA overview](https://www.pdpc.gov.sg/overview-of-pdpa/pdpa-overview?ref=sorena.io) - Official PDPC overview of PDPA obligations, key concepts, and updates relevant to Singapore PDPA breach notification compliance. ## Related Topic Guides - [Singapore PDPA Applicability Test | Does the PDPA Apply to Your Organisation?](/artifacts/apac/singapore-pdpa/applicability-test.md): Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation. - [Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026)](/artifacts/apac/singapore-pdpa/checklist.md): Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules. - [Singapore PDPA Compliance Deadlines and Calendar](/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar.md): Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows. - [Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM](/artifacts/apac/singapore-pdpa/compliance.md): Complete Singapore PDPA compliance guide for organisations. - [Singapore PDPA Consent and Notification Obligations Guide](/artifacts/apac/singapore-pdpa/consent-notification-and-purposes.md): Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception. - [Singapore PDPA Cross-Border Transfer Rules | Section 26 Data Transfer Compliance](/artifacts/apac/singapore-pdpa/cross-border-transfers.md): Complete guide to Singapore PDPA cross-border transfer compliance under Section 26. - [Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide](/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages.md): Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses. - [Singapore PDPA FAQ | Frequently Asked Questions on Personal Data Protection Act Compliance](/artifacts/apac/singapore-pdpa/faq.md): Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements. - [Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions](/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases.md): Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover. - [Singapore PDPA Penalties and Fines | SGD 1M or 10% Turnover Cap + PDPC Enforcement Guide](/artifacts/apac/singapore-pdpa/penalties-and-fines.md): Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions. - [Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide](/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template.md): Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions. - [Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC)](/artifacts/apac/singapore-pdpa/requirements.md): Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18). - [Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations](/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries.md): Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion. - [Singapore PDPA Vendor Outsourcing and Contracts Guide](/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts.md): Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence. - [Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties](/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr.md): Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/singapore-pdpa/breach-notification-playbook --- --- title: "Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026)" canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/checklist" source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/checklist" author: "Sorena AI" description: "Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Singapore PDPA compliance checklist" - "Personal Data Protection Act checklist" - "PDPA audit checklist" - "Singapore data protection management programme" - "DPMP checklist" - "PDPA consent management" - "PDPA purpose limitation" - "PDPA notification obligation" - "PDPA data accuracy" - "PDPA protection obligation" - "PDPA retention limitation" - "PDPA access request workflow" - "PDPA correction request workflow" - "Singapore cross-border data transfer" - "PDPA breach notification" - "Singapore DNC registry compliance" - "PDPA accountability" - "PDPC advisory guidelines" - "Data Protection Officer Singapore" - "DPO appointment PDPA" - "PDPA deemed consent" - "PDPA legitimate interests" - "PDPA business improvement exception" - "Data Protection Trustmark DPTM" - "PDPA data intermediary" - "PDPA vendor management" - "Singapore PDPA compliance guide" - "PDPA enterprise risk management" - "PDPA data protection impact assessment" - "DPIA Singapore" - "PDPA enforcement penalties" - "PDPA annual review checklist" - "PDPA compliance checklist 2026" - "Singapore PDPA checklist for organisations" - "PDPA compliance audit" - "PDPA compliance requirements" - "Personal Data Protection Act" - "DPMP" - "PDPC guidelines" - "data protection audit" - "breach notification" - "DNC registry" - "APAC privacy" - "Singapore PDPA checklist" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026) Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules. *Checklist* *APAC* ## Singapore PDPA Compliance Checklist A complete Singapore PDPA compliance checklist designed for audit readiness: DPMP governance, consent and notification, protection controls, retention schedules, access and correction workflows, breach notification readiness, cross-border transfer safeguards, DNC registry processes, and annual accountability reviews. Use this Singapore PDPA compliance checklist as a quarterly control review, a release gate for high-risk features, and a baseline for PDPC enforcement readiness. The Singapore Personal Data Protection Act (PDPA) requires organisations to build a working system of policies, processes, and evidence -- not just documentation. This Singapore PDPA compliance checklist translates PDPA obligations and PDPC guidance into owned work items with measurable acceptance criteria. It follows the four-step Data Protection Management Programme (DPMP) framework published by the PDPC: governance and risk assessment, policies and practices, processes, and maintenance. Organisations that collect, use, or disclose personal data are required to develop and implement policies and practices necessary for PDPA compliance. Having an established DPMP helps an organisation demonstrate accountability, provides confidence to stakeholders, and fosters higher-trust relationships with customers and business partners. Use this Singapore PDPA compliance checklist to build a compliance programme that holds up under enforcement scrutiny, supports the Data Protection Trustmark (DPTM) certification journey, and can be exported as evidence at any time. ## 1) Singapore PDPA Data Protection Management Programme (DPMP) setup The PDPC's Guide to Developing a Data Protection Management Programme outlines a four-step framework that forms the backbone of every Singapore PDPA compliance checklist: governance and risk assessment, policies and practices, processes, and maintenance. Every organisation that collects, uses, or discloses personal data must develop and implement policies and practices necessary for PDPA compliance. The DPMP is the single most referenced structure in PDPC enforcement decisions, and establishing one is the first step in your Singapore PDPA compliance checklist. Building a DPMP is not a one-time project. It requires senior management commitment, a designated Data Protection Officer (DPO), allocated budget and manpower, and integration into the organisation's existing corporate governance and enterprise risk management (ERM) framework. The PDPC has stated that having an established DPMP helps an organisation demonstrate accountability in data protection, provides confidence to stakeholders, and fosters higher-trust relationships with customers and business partners for business competitiveness. Organisations should benchmark their existing data protection policies and practices against the PDPC's DPMP guide and identify gaps. The DPO should have a direct reporting line to senior management and should be empowered to drive data protection initiatives across the organisation. If the DPO function is outsourced, a member of senior management must remain responsible for oversight. The DPO Competency Framework and Training Roadmap published by the PDPC provides a structured path for DPOs to build the core competencies needed for this Singapore PDPA compliance checklist role. - Appoint at least one Data Protection Officer (DPO) as required by the Singapore PDPA. Register the DPO with the PDPC and publish the DPO's business contact information so individuals can reach the DPO for queries and complaints. - Secure senior management commitment: define strategic corporate values for data protection, allocate budget and manpower, approve the DPMP, and commission Data Protection Impact Assessments (DPIAs) for new and existing systems. - Integrate data protection into your enterprise risk management (ERM) framework. Include personal data protection risks in the corporate risk register and ensure the board oversees risk governance as recommended in the Board Risk Committee Guide developed by the Singapore Institute of Directors. - Establish a governance structure with board-level or senior-management-level oversight of data protection. The DPO should report directly to senior management to ensure personal data protection issues receive appropriate attention and resources. - Conduct a Data Protection Impact Assessment (DPIA) on existing systems and operations to identify baseline risks, personal data flows, and compliance gaps. The DPIA should cover confidentiality, integrity, and availability risks for all personal data categories. - Create a data inventory map documenting all personal data: collection purposes, data owners, data sources, collection medium, users, access controls, storage locations, disclosure to third parties, retention periods, and disposal methods. The PDPC provides a Sample Personal Data Inventory Map Template. - Develop a data flow diagram showing how personal data moves through collection, storage, use, disclosure, transfer, and disposal across all departments and systems. This diagram should cover both digital and physical data flows. - Document the DPMP formally: governance structure, risk assessment results, policies, processes, training plan, review schedule, and escalation paths. Communicate the DPMP to all internal stakeholders and relevant external parties. - Maintain a risk register that identifies risks associated with the nature of personal data and the context in which it is collected, used, and disclosed throughout the data lifecycle. Update the risk register after each DPIA and during periodic reviews. ## 2) Singapore PDPA consent collection and management checklist Consent is one of the primary legal bases for collecting, using, and disclosing personal data under the Singapore PDPA. Organisations must obtain valid consent before or at the time of collection. The PDPA also recognises deemed consent, where an individual voluntarily provides personal data for a purpose that a reasonable person would consider appropriate. Since the 2021 amendments, the Singapore PDPA also provides for deemed consent by notification and deemed consent by contractual necessity, expanding the lawful bases available to organisations. Organisations completing this Singapore PDPA compliance checklist should design consent mechanisms that are clear, specific, and easy for individuals to understand. Consent clauses must be separated from other terms and conditions so that individuals know exactly what they are agreeing to. The PDPC recommends dynamic consent, where consent is obtained at appropriate touchpoints along the customer journey rather than in a single bundled clause at the start of the relationship. A consent registry is a critical operational tool for Singapore PDPA compliance. It records what consent each individual has provided, for which purposes, under which version of the consent clause, and whether consent has been withdrawn. The PDPC provides a Sample Consent Registry Template that organisations can adapt. As an organisation updates its consent clauses, the consent registry helps track what is permitted for each version and which version each customer has agreed to. - Map every collection, use, and disclosure activity to a valid legal basis under the Singapore PDPA: express consent, deemed consent, deemed consent by notification, deemed consent by contractual necessity, or a recognised exception (e.g., legitimate interests, business improvement, research). - Design consent forms with clear, specific, and separate consent clauses for each purpose. Do not bundle consent for unrelated purposes into a single clause. Use the PDPC's sample clauses on obtaining and withdrawing consent as a starting template. - Implement dynamic consent at appropriate touchpoints in the customer journey rather than relying on a single upfront consent for all purposes. This approach aligns with PDPC guidance on transparency and accountability. - Maintain a consent registry that records: individual identity, date of consent, version of consent clause, purposes consented to, method of collection, and withdrawal status. Update the registry whenever consent clauses are revised. - Build and test a consent withdrawal mechanism that is as easy to use as the consent collection mechanism. Process withdrawals within a reasonable time and inform the individual of the likely consequences of withdrawal before completing the process. - Document all exceptions relied upon (legitimate interests, business improvement, research) with the reasoning, risk assessment, and any conditions attached. Keep this documentation as part of your Singapore PDPA compliance checklist evidence pack. - Review consent clauses whenever purposes change, new data types are collected, or new third-party disclosures are introduced. Update the consent registry to track which individuals consented under which version. - Train front-line staff on how to obtain valid consent, how to handle consent withdrawal requests, and how to escalate edge cases to the DPO. Include consent handling in onboarding training and annual refresher courses. *Recommended next step* *Placement: after the checklist block* ## Turn Singapore PDPA Compliance Checklist into an operational assessment Assessment Autopilot can take Singapore PDPA Compliance Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on Singapore PDPA Compliance can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Singapore PDPA Compliance Checklist](/solutions/assessment.md): Start from Singapore PDPA Compliance Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Singapore PDPA Compliance](/contact.md): Review your current process, evidence gaps, and next steps for Singapore PDPA Compliance Checklist. ## 3) Singapore PDPA purpose limitation and notification checklist The Singapore PDPA Notification Obligation requires organisations to inform individuals of the purposes for collecting, using, or disclosing their personal data. The Purpose Limitation Obligation restricts organisations to collecting, using, or disclosing personal data only for the purposes that a reasonable person would consider appropriate and that the individual has been notified of or has consented to. Both obligations are central to any Singapore PDPA compliance checklist. Data protection notices are the primary mechanism for meeting the Singapore PDPA Notification Obligation. Notices must be written in clear, simple language and placed in prominent, easily accessible locations. The PDPC provides a Data Protection Notice Generator tool that organisations can use to create template notices and customise them for their specific collection contexts. Organisations should communicate policies to customers clearly and upfront to demonstrate accountability. Purpose limitation under the Singapore PDPA is not just a documentation exercise. Organisations must have operational controls that prevent personal data from being used for purposes that were not communicated to the individual. This means implementing access controls, data tagging, and workflow restrictions that enforce purpose boundaries across systems and teams. Staff interactions with customers should also reflect the organisation's commitment to using personal data only for notified purposes. - Draft data protection notices for every collection channel (website, mobile app, physical forms, email, phone, kiosk) as part of your Singapore PDPA compliance checklist. Use the PDPC's Data Protection Notice Generator as a starting point. - Each notice must state: what personal data is collected, the purposes of collection, use, and disclosure, any third parties to whom data may be disclosed, and how to contact the DPO for queries or complaints. - Publish notices in prominent locations that are easily accessible before or at the point of collection. For websites, link the privacy notice from every page footer and from every data collection form. - Implement purpose tagging in your data systems so that each record of personal data is linked to the specific purposes for which it was collected. This enables automated enforcement of purpose limitation controls. - Restrict access to personal data based on purpose: only staff and systems that need the data for its stated purpose should be able to access it. Apply the principle of least privilege across all departments. - When new purposes arise, issue a fresh notice to affected individuals and obtain new consent if the new purpose was not covered by the original notification. Document the change and update your data protection notices. - Communicate policy updates clearly and separately from marketing messages. Keep a version history of all data protection notices with dates and a record of how updates were communicated to individuals. - Review notices at least annually and whenever there are changes to purposes, data types, third-party disclosures, or regulatory requirements. Include notice reviews as a recurring item in your Singapore PDPA compliance checklist. ## 4) Singapore PDPA data accuracy and protection checklist The Singapore PDPA Accuracy Obligation requires organisations to make a reasonable effort to ensure that personal data collected is accurate and complete, especially if the data is likely to be used to make a decision that affects the individual or is likely to be disclosed to another organisation. The Protection Obligation requires organisations to make reasonable security arrangements to protect personal data from unauthorised access, collection, use, disclosure, copying, modification, disposal, or similar risks. Security measures under the Singapore PDPA must be proportionate to the sensitivity of the data, the volume of data, the possible harm from a breach, and the state of available technology. Organisations should adopt a Data Protection by Design (DPbD) approach where data protection is considered from the earliest design stage of any project and throughout its operational lifecycle. The PDPC's Guide to Data Protection by Design for ICT Systems provides detailed principles that organisations should incorporate into this section of their Singapore PDPA compliance checklist. Both digital and non-digital controls are necessary for Singapore PDPA compliance. Encryption, access controls, and logging protect data in electronic systems, while physical security measures such as locked cabinets, secure rooms, and access passes protect data in physical formats. Organisations must protect data when it is in transit, at rest, and during processing. Controls adopted should correspond to the risk level and nature of the data as identified in the DPIA. - Implement data validation at collection points to reduce errors: input validation, format checks, and verification steps for critical data fields. Accurate data is a core requirement of the Singapore PDPA compliance checklist. - Establish processes for individuals to update their personal data, and train staff to flag and correct inaccuracies when they are identified during normal business operations. - Conduct a security risk assessment to identify threats to personal data across all systems, processes, and physical locations. Map the results against your risk register and DPIA findings. - Implement access controls based on the principle of least privilege: staff and systems should only access the personal data needed for their specific roles and purposes. Review access rights periodically and when staff change roles. - Apply encryption to personal data at rest and in transit. Use industry-standard encryption protocols and manage encryption keys securely. Ensure encryption covers all storage media including backups and archives. - Implement logging and monitoring for all access to personal data. Maintain audit trails that record who accessed what data, when, and for what purpose. Review logs regularly to detect unauthorised access. - Secure physical records: use locked cabinets in secured rooms, control access with passes or keys, and maintain visitor logs for areas where personal data is stored. - Adopt Data Protection by Design (DPbD): embed data protection measures into system design, development, and the full software development lifecycle rather than retrofitting them. Refer to the PDPC's Guide to Data Protection by Design for ICT Systems. ## 5) Singapore PDPA retention limitation checklist The Singapore PDPA Retention Limitation Obligation requires organisations to stop retaining personal data, or remove the means by which it can be associated with particular individuals, as soon as it is reasonable to assume that the purpose for which the data was collected is no longer being served and retention is no longer necessary for legal or business purposes. This obligation is a critical component of any Singapore PDPA compliance checklist because retaining data beyond its useful life increases both compliance risk and the impact of a potential data breach. A retention schedule is the operational backbone of this Singapore PDPA compliance checklist section. The schedule should list every category of personal data, the retention period, the legal or business justification for the retention period, the disposal method, and the responsible department. Without a formal retention schedule, organisations risk holding data indefinitely, which contradicts the PDPA's retention limitation principle. Disposal methods must be secure and irreversible. For electronic data, this means using cleanup software or secure deletion methods that prevent recovery. For physical records, shredding is the standard approach. Organisations should maintain disposal logs that record what was destroyed, when, by whom, and using what method. When personal data is shared with data intermediaries, the contractual agreement should address retention and disposal requirements as recommended in the PDPC's Guide to Managing Data Intermediaries. - Create a retention schedule that maps every category of personal data to a specific retention period with a documented legal or business justification. This is a foundational element of the Singapore PDPA compliance checklist. - Implement automated deletion workflows or reminders that trigger when retention periods expire. Do not rely solely on manual processes for data disposal. - Define secure disposal methods for each data format: secure deletion software for electronic data, shredding for physical records, and certified destruction for hardware containing personal data. - Maintain disposal logs that record: what data was destroyed, the date of destruction, the disposal method, and the individual or vendor responsible for carrying out the disposal. - Review the retention schedule at least annually and whenever there are changes to legal requirements, business purposes, or data collection practices. Update retention periods based on new regulatory guidance. - When personal data is shared with third parties or data intermediaries, ensure that retention and disposal requirements are covered in the contractual agreement and that the intermediary adheres to the PDPA's Retention Limitation Obligation. - Anonymise or de-identify personal data if there is a legitimate need to retain the information for analytics or research purposes beyond the original retention period. - Audit a sample of records against the retention schedule quarterly to verify that disposal workflows are operating correctly and that no data is being retained beyond its scheduled period. ## 6) Singapore PDPA access and correction request handling checklist The Singapore PDPA Access Obligation requires organisations to provide individuals with access to their personal data and information about how it has been used or disclosed in the past year, upon request. The Correction Obligation requires organisations to correct errors or omissions in personal data upon the request of the individual. Under PDP Regulation 3(1), a request must be made in writing with sufficient detail to identify the applicant and the data requested. Access and correction handling is a key operational area in any Singapore PDPA compliance checklist. Organisations must respond to access requests as soon as reasonably possible, and in any case within 30 days. If the organisation cannot respond within 30 days, it must inform the individual in writing of the expected timeframe. Organisations may charge a reasonable fee to recover incremental costs of responding to access requests, but the fee must be communicated in writing before processing begins. The PDPC may review a fee on application of the complainant and may confirm, reduce, or disallow the fee. A well-designed access and correction request workflow includes clear intake channels, identity verification procedures, a search playbook covering all relevant systems, response templates, escalation procedures for complex cases, and a documentation process for every request received. The PDPC's Advisory Guidelines on Key Concepts in the PDPA (Chapter 15) and the Guide to Handling Access Requests provide detailed guidance on exceptions, prohibitions, and best practices. For correction requests, the organisation must correct the data and send the corrected data to every organisation that received the uncorrected data in the past year, unless that organisation no longer needs the data for any legal or business purpose. This forwarding obligation ensures data accuracy across the entire ecosystem of organisations holding the individual's personal data. - Establish clear, accessible channels for individuals to submit access and correction requests (e.g., email, web form, postal mail). Publish these channels in your data protection notice and on your website. - Create a standard access request form that collects the information needed to identify the applicant and locate the requested data. Make the form available on your website and at service counters. - Implement identity verification procedures to confirm the identity of the individual making the request, including procedures for requests made on behalf of another individual by an authorised representative. - Develop a search playbook that lists all systems, databases, and physical locations where personal data may be stored, and the steps to search each one. Include both electronic and non-electronic records. - Set up SLA tracking to ensure all requests are responded to within 30 days as required by the Singapore PDPA. If an extension is needed, notify the individual in writing with the revised timeline. - Define and document the process for assessing whether any exceptions or prohibitions apply (e.g., threats to safety, legal privilege, ongoing investigations). Record the reasoning for any refusal in your request log. - If charging an access fee, provide a written estimate to the individual before processing. Ensure the fee is reasonable and reflects actual incremental costs. The PDPC may review fees upon complaint. - For correction requests, correct the data and send the corrected data to every organisation that received the uncorrected data in the past year, unless that organisation no longer needs the data. - Maintain a log of all access and correction requests: date received, identity of applicant, data requested, actions taken, response date, any fees charged, and any exceptions applied. ## 7) Singapore PDPA cross-border transfer compliance checklist The Singapore PDPA Transfer Limitation Obligation restricts organisations from transferring personal data outside Singapore unless the recipient country or territory provides a comparable standard of protection, or the organisation takes steps to ensure that the data will receive a standard of protection comparable to the PDPA. This requirement applies to all transfers, whether to a parent company, a subsidiary, a cloud service provider, or any other third party located outside Singapore. Cross-border transfer controls are a mandatory element of your Singapore PDPA compliance checklist. Organisations have several mechanisms available for lawful cross-border transfers under the Singapore PDPA. These include transfers to countries with comparable data protection laws, transfers governed by binding contractual arrangements (such as those using the ASEAN Model Contractual Clauses), transfers to recipients certified under the APEC Cross Border Privacy Rules (CBPR) or Privacy Recognition for Processors (PRP) systems, and transfers with the consent of the individual. A transfer map is the essential operational tool for this section of the Singapore PDPA compliance checklist. It should document every cross-border data flow: the exporting entity, the receiving entity, the destination country, the data categories, the purposes, the transfer mechanism relied upon, and the contractual safeguards in place. The PDPC's Guide on Data Protection Clauses for Agreements Relating to the Processing of Personal Data and the Guidance for Use of ASEAN Model Contractual Clauses provide detailed templates and standard clauses that organisations should use. - Create and maintain a transfer map that documents every cross-border personal data flow: exporter, importer, destination country, data categories, purposes, and transfer mechanism relied upon. - For each transfer, identify and document the legal mechanism relied upon under the Singapore PDPA: comparable jurisdiction, contractual arrangements, CBPR or PRP certification, consent, or another PDPA-recognised mechanism. - Use the ASEAN Model Contractual Clauses or equivalent contractual safeguards for transfers to jurisdictions without comparable data protection laws. Ensure clauses are signed and in force before any transfer takes place. - When using cloud service providers or data intermediaries that store or process data outside Singapore, verify the locations of all data centres and any sub-processors involved. Include this verification in your Singapore PDPA compliance checklist evidence pack. - Include data protection clauses in all cross-border contracts that require the recipient to protect personal data to a standard comparable to the Singapore PDPA. Refer to the PDPC's Guide on Data Protection Clauses for standard templates. - Monitor changes in the data protection laws of destination countries and update transfer mechanisms if the level of protection changes. Document all monitoring activities and decisions. - Document all cross-border transfer decisions, including the risk assessment and the justification for the chosen transfer mechanism. Retain this documentation as evidence for enforcement readiness. - Review the transfer map at least annually and whenever new vendors, sub-processors, or data flows are introduced. Update contractual safeguards as needed. ## 8) Singapore PDPA breach notification readiness checklist The mandatory data breach notification obligation under the Singapore PDPA requires organisations to notify the PDPC and affected individuals when a data breach is assessed to be a notifiable data breach. A data breach is notifiable if it results in, or is likely to result in, significant harm to affected individuals, or if it is of a significant scale (affecting 500 or more individuals). Organisations must conduct this assessment within 30 calendar days of becoming aware of the breach. Breach readiness is one of the most scrutinised areas in any Singapore PDPA compliance checklist. The PDPC recommends a structured breach management process following the CARE framework: Contain the breach, Assess the risk, Report the incident, and Evaluate the response to prevent future breaches. The DPO should maintain an incident record log and actively engage data intermediaries to define responsibilities for reporting, investigating, and taking remedial actions. The PDPC provides a downloadable Incident Record Log template that organisations can adapt. Having a documented and tested breach management plan is also relevant to enforcement outcomes under the Singapore PDPA. Under the PDPC's Active Enforcement Framework, organisations that can demonstrate accountable practices including monitoring and remediation plans may qualify for an undertaking option rather than a full investigation, resulting in a better enforcement outcome. This is why breach notification readiness is a high-priority section of your Singapore PDPA compliance checklist. - Develop a written data breach management plan that covers containment, assessment, notification, and post-incident review. Assign roles and responsibilities for each phase of the CARE framework. - Define the criteria for identifying a notifiable data breach under the Singapore PDPA: significant harm to individuals (e.g., identity theft, financial loss, physical safety) or significant scale (500 or more individuals affected). - Establish an internal escalation path: frontline staff report to the DPO, the DPO assesses the breach, and senior management is notified for decisions on PDPC and individual notification. - Create notification templates for the PDPC and for affected individuals. Include the nature of the breach, types of personal data involved, likely consequences, and remedial measures taken or proposed. - Set up a breach assessment timeline tracker: organisations must assess whether a breach is notifiable within 30 calendar days of becoming aware of it. Track this deadline from the moment awareness is established. - Notify the PDPC as soon as practicable if the breach is assessed as notifiable, and no later than 3 calendar days after completing the assessment. Notify affected individuals at the same time or as soon as practicable. - Maintain an incident record log that documents every data incident (including near-misses and unconfirmed breaches): date detected, description, assessment steps taken, notification decisions, remediation actions, and lessons learned. - Conduct post-incident reviews after every breach or significant data incident. Update the breach management plan, security controls, and training based on findings. Document all improvements made. - Test the breach management plan at least annually through tabletop exercises or simulated breach scenarios. Document the results and any improvements made as part of your Singapore PDPA compliance checklist evidence. - Ensure contracts with data intermediaries include breach notification obligations: the intermediary must notify your organisation within a defined timeframe and cooperate fully in the investigation and remediation. ## 9) Singapore PDPA Do Not Call (DNC) registry compliance checklist The Do Not Call (DNC) provisions of the Singapore PDPA establish a national registry where individuals can register their Singapore telephone numbers to opt out of receiving telemarketing messages. Organisations that send telemarketing messages (voice calls, text messages, or fax messages) to Singapore telephone numbers must check the DNC registry before each campaign and must not send messages to numbers that are registered. DNC compliance is a distinct and enforceable component of the Singapore PDPA compliance checklist. The DNC provisions apply to all organisations that send or cause to be sent specified messages to Singapore telephone numbers, regardless of where the organisation is located. There are three DNC registers: the No Voice Call Register, the No Text Message Register, and the No Fax Message Register. Organisations must check the relevant register for the type of message they intend to send. The DNC Registry provisions came into force on 2 January 2014, and the PDPC actively enforces compliance. Organisations completing this Singapore PDPA compliance checklist should also maintain their own internal do-not-call list for individuals who have directly requested not to receive marketing communications. This internal list should be checked in addition to the national DNC registry. Exceptions exist for messages sent with clear and unambiguous consent, or where the recipient has an ongoing relationship with the sender and has been given a reasonable opportunity to opt out. - Register as a user of the DNC registry on the PDPC's DNC portal before sending any telemarketing messages. This is a mandatory first step in the Singapore PDPA compliance checklist for marketing teams. - Check the relevant DNC register (No Voice Call, No Text Message, No Fax Message) within 30 days before each telemarketing campaign. Document each check with a timestamp and retain the evidence. - Maintain an internal do-not-call list for individuals who have directly opted out of marketing communications. Check this list in addition to the national DNC registry before every campaign. - If relying on the consent exception, document clear and unambiguous consent from the individual to receive the specific type of marketing message. Maintain evidence of when and how consent was obtained. - If relying on the ongoing relationship exception, ensure the individual has been given a reasonable opportunity to opt out and that the message is related to the subject of the existing relationship. - Include a working opt-out mechanism in every telemarketing message. Process opt-out requests within a reasonable timeframe and update both your internal list and campaign suppression files. - Train marketing and sales teams on DNC obligations under the Singapore PDPA, the penalties for non-compliance, and the procedures for checking registers and maintaining the internal opt-out list. - Review DNC compliance processes at least quarterly. Audit a sample of campaigns to verify that registry checks were performed and documented before messages were sent. ## 10) Singapore PDPA annual review, accountability, and certification checklist The Singapore PDPA requires organisations to keep their data protection policies and practices relevant and up to date. The PDPC recommends both periodic reviews at regular intervals and immediate (ad-hoc) reviews triggered by major incidents, legislative amendments, or organisational changes such as mergers, acquisitions, or restructuring. A formal annual review cycle ensures that your DPMP remains aligned with the regulatory environment, the organisation's operations, and evolving technology risks. This final section of the Singapore PDPA compliance checklist ensures ongoing compliance rather than point-in-time certification. Audit structures are a core component of accountability under the Singapore PDPA. Organisations should conduct internal audits on a periodic basis, ad-hoc walk-through inspections, and consider engaging an external party to evaluate implementation. The PDPC's PDPA Assessment Tool for Organisations (PATO) is a self-assessment tool that organisations should use to assess residual gaps from their systems-based and process controls and to monitor the implementation of those controls. Organisations that want to validate their DPMP externally can pursue the Data Protection Trustmark (DPTM) certification, which is now part of the national Singapore Standards (SS 714:2025). DPTM certification demonstrates to customers, business partners, and the regulator that the organisation has robust data protection policies and practices. Under the PDPC's Active Enforcement Framework, DPTM certification may serve as a mitigating factor in enforcement proceedings and may allow the organisation to qualify for an undertaking process rather than a full investigation. A culture of accountability towards data protection is crucial for sustaining Singapore PDPA compliance. This includes awareness and alertness to data protection issues among all staff, which depends on education, training, and buy-in from senior management. Personal data protection cuts across roles, functions, and hierarchy, and should be recognised and practised by all levels in the organisation including volunteers, agents, and contract staff. - Conduct a formal annual review of all data protection policies, practices, and processes as the capstone of your Singapore PDPA compliance checklist. Document findings, gaps identified, and remediation actions taken. - Use the PDPC's PDPA Assessment Tool for Organisations (PATO) to conduct a self-assessment and identify any residual compliance gaps. Base remediation plans on the PATO assessment report. - Review the DPMP governance structure: verify that the DPO appointment is current, the reporting line to senior management is active, and budget allocations remain adequate for the coming year. - Review and update the data inventory map, data flow diagram, consent registry, and risk register to reflect any changes in operations, systems, vendors, or data types during the review period. - Monitor the external environment: changes to the PDPA and PDP Regulations, new PDPC advisory guidelines, enforcement decisions, sector-specific regulations, technological changes, and data breaches reported at other organisations. - Monitor the internal environment: new systems or processes that handle personal data, new business models or engagements, feedback from customers and stakeholders, and any data incidents that occurred during the review period. - Conduct or update Data Protection Impact Assessments (DPIAs) for any new or significantly changed systems or processes that handle personal data. - Deliver refresher data protection training to all staff at least annually. Provide targeted training for staff in high-risk roles (e.g., HR, sales, marketing, IT). Document attendance, training content, and competency assessments. - Conduct at least one internal audit of data protection controls during the review period. Consider engaging an external auditor for an independent assessment of your Singapore PDPA compliance posture. - Consider pursuing DPTM certification (SS 714:2025) to validate your data protection practices against national standards. DPTM-certified organisations benefit from increased business competitiveness and potential mitigation in enforcement actions. - Report the results of the annual review to senior management or the board. Include a refreshed risk profile, a summary of risk remediation plans, and recommendations for the coming year. - Notify all stakeholders of any changes to data protection policies or practices through the organisation's training and communication plan. Update the organisation's website, intranet, and customer-facing notices. ## Singapore PDPA compliance checklist evidence index The goal of a Singapore PDPA compliance checklist evidence index is to export proof of compliance quickly and consistently when the PDPC, an auditor, or a business partner requests it. The index should map each PDPA obligation to the specific documents, logs, and artifacts that demonstrate compliance. Aim for coherence and traceability rather than volume. Under the PDPC's Active Enforcement Framework, organisations that can demonstrate accountable practices through documented evidence may qualify for better enforcement outcomes. Organisations should maintain evidence in a centralised and accessible repository. Each piece of evidence should be version-controlled, dated, and linked to the specific obligation it supports. Regular internal checks should verify that evidence is current and complete. This evidence index is the final deliverable of your Singapore PDPA compliance checklist and serves as the single source of truth during any enforcement inquiry or DPTM certification assessment. - DPMP documentation: governance structure, DPO appointment record, senior management approvals, budget allocations, and DPMP review history. - Data inventory map, data flow diagram, and risk register: current versions with revision dates and change logs. - Consent registry: individual consent records, consent clause versions, withdrawal records, and exception documentation. - Data protection notices: all current and historical versions across all collection channels, with publication dates and distribution records. - Access and correction request log: every request received, identity verification steps, search actions taken, response packages, fees charged, exceptions applied, and response dates. - Retention schedule and disposal logs: retention periods by data category, disposal records with dates and methods, and quarterly audit results. - Cross-border transfer map and contractual safeguards: transfer mechanisms, signed contract copies, CBPR or PRP certifications, and risk assessments for each destination. - Breach management plan and incident record log: breach reports, assessment timelines, notification records, remediation actions, post-incident review findings, and tabletop exercise results. - DNC compliance records: registry check timestamps, campaign records, internal opt-out list, consent evidence for exceptions, and opt-out processing logs. - Training records: attendance logs, training materials, training schedule, competency assessments for the DPO and staff, and records of annual refresher sessions. - Audit reports: internal audit findings, PATO self-assessment results, external audit reports, DPIA reports, and DPTM certification status. - Stakeholder communication records: policy update notifications, customer communications, vendor data protection correspondence, and board or senior management reports. ## Primary sources - [Personal Data Protection Act 2012 (Singapore) -- official text](https://sso.agc.gov.sg/Act/PDPA2012?ref=sorena.io) - Primary legislation governing collection, use, disclosure, protection, retention, transfer, and accountability for personal data in Singapore. - [PDPC -- PDPA overview](https://www.pdpc.gov.sg/overview-of-pdpa/pdpa-overview?ref=sorena.io) - Official PDPC overview of PDPA obligations, key concepts, scope, and legislative development history. - [PDPC -- Key Concepts advisory guidelines](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-the-personal-data-protection-act?ref=sorena.io) - Core interpretation guidance for consent, purposes, notification, access and correction, accuracy, protection, retention, transfers, and accountability under the Singapore PDPA. - [PDPC -- Enforcement advisory guidelines](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-enforcement-of-data-protection-provisions?ref=sorena.io) - Enforcement approach, directions, financial penalties, undertakings, and the Active Enforcement Framework. - [PDPC -- Guide to Developing a Data Protection Management Programme (DPMP)](https://www.pdpc.gov.sg/help-and-resources/2019/07/guide-to-developing-a-data-protection-management-programme?ref=sorena.io) - Four-step DPMP framework: governance and risk assessment, policies and practices, processes, and maintenance. Includes data inventory map templates, consent registry templates, DPO governance guidance, and audit structure recommendations. - [PDPC -- Guide on Managing and Notifying Data Breaches Under the PDPA](https://www.pdpc.gov.sg/help-and-resources/2021/01/data-breach-management-guide?ref=sorena.io) - Detailed guidance on the CARE framework for breach management: contain, assess, report, and evaluate. Covers the 30-day assessment and 3-day notification timelines. - [PDPC -- Accountability Within an Organisation](https://www.pdpc.gov.sg/help-and-resources/2021/09/accountability/accountability-within-an-organisation?ref=sorena.io) - PDPC's accountability resources including the four steps of accountability, templates, sample clauses, incident record log, consent registry, and tools for DPMP implementation. - [PDPC -- Guide to Accountability under the Personal Data Protection Act](https://www.pdpc.gov.sg/help-and-resources/2019/07/guide-to-accountability-under-the-personal-data-protection-act?ref=sorena.io) - Explains the accountability principle and how organisations should shift from a compliance-based to an accountability-based approach to managing personal data. - [PDPC -- Data Protection Trustmark (DPTM) SS 714:2025](https://www.pdpc.gov.sg/overview-of-pdpa/data-protection/business-owner/data-protection-trustmark?ref=sorena.io) - Voluntary enterprise-wide certification under Singapore Standards. Demonstrates accountable data protection practices and may serve as a mitigating factor in enforcement. - [Personal Data Protection (Notification of Data Breaches) Regulations 2021](https://sso.agc.gov.sg/SL-Supp/S64-2021/Published/20210129?ref=sorena.io) - Subsidiary legislation specifying the mandatory data breach notification requirements, timelines, and assessment criteria under the Singapore PDPA. - [Personal Data Protection Regulations 2021](https://sso.agc.gov.sg/SL-Supp/S63-2021/Published/20210129?ref=sorena.io) - Subsidiary legislation covering access request procedures, fee provisions, correction obligations, and other operational requirements under the Singapore PDPA. ## Related Topic Guides - [Singapore PDPA Applicability Test | Does the PDPA Apply to Your Organisation?](/artifacts/apac/singapore-pdpa/applicability-test.md): Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation. - [Singapore PDPA Breach Notification Playbook - Complete Guide](/artifacts/apac/singapore-pdpa/breach-notification-playbook.md): Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline. - [Singapore PDPA Compliance Deadlines and Calendar](/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar.md): Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows. - [Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM](/artifacts/apac/singapore-pdpa/compliance.md): Complete Singapore PDPA compliance guide for organisations. - [Singapore PDPA Consent and Notification Obligations Guide](/artifacts/apac/singapore-pdpa/consent-notification-and-purposes.md): Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception. - [Singapore PDPA Cross-Border Transfer Rules | Section 26 Data Transfer Compliance](/artifacts/apac/singapore-pdpa/cross-border-transfers.md): Complete guide to Singapore PDPA cross-border transfer compliance under Section 26. - [Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide](/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages.md): Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses. - [Singapore PDPA FAQ | Frequently Asked Questions on Personal Data Protection Act Compliance](/artifacts/apac/singapore-pdpa/faq.md): Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements. - [Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions](/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases.md): Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover. - [Singapore PDPA Penalties and Fines | SGD 1M or 10% Turnover Cap + PDPC Enforcement Guide](/artifacts/apac/singapore-pdpa/penalties-and-fines.md): Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions. - [Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide](/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template.md): Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions. - [Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC)](/artifacts/apac/singapore-pdpa/requirements.md): Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18). - [Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations](/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries.md): Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion. - [Singapore PDPA Vendor Outsourcing and Contracts Guide](/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts.md): Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence. - [Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties](/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr.md): Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/singapore-pdpa/checklist --- --- title: "Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM" canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/compliance" source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/compliance" author: "Sorena AI" description: "Complete Singapore PDPA compliance guide for organisations." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Singapore PDPA compliance" - "Personal Data Protection Act Singapore" - "PDPA compliance guide" - "PDPA compliance checklist" - "PDPA compliance requirements" - "Singapore PDPA compliance programme" - "data protection management programme" - "DPMP Singapore" - "PDPA DPO appointment" - "Singapore PDPA DPO requirements" - "PDPA consent obligation" - "PDPA notification obligation" - "PDPA purpose limitation" - "PDPA protection obligation" - "PDPA retention limitation obligation" - "PDPA transfer limitation obligation" - "PDPA data breach notification" - "PDPA access request" - "PDPA correction request" - "PDPA accountability obligation" - "DPTM certification" - "Data Protection Trustmark" - "SS 714:2025" - "PDPC guidelines" - "PDPC advisory guidelines" - "Singapore data protection law" - "PDPA enforcement penalties" - "PDPA deemed consent" - "PDPA deemed consent by notification" - "PDPA legitimate interests exception" - "PDPA business improvement exception" - "Singapore cross border data transfer" - "Singapore DNC registry compliance" - "PDPA data intermediary obligations" - "PDPA privacy policy" - "PDPA data inventory" - "PDPA compliance programme Singapore" - "Singapore PDPA data protection officer" - "PDPA data protection impact assessment" - "PDPA DPIA" - "Singapore PDPA penalties SGD 1 million" - "PDPA 10 percent annual turnover" - "PDPA notifiable data breach 500 individuals" - "PDPA mandatory breach notification 3 days" - "Personal Data Protection Act" - "DPMP" - "Data Protection Officer" - "APAC privacy" - "Singapore data protection" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM Complete Singapore PDPA compliance guide for organisations. *Compliance Playbook* *APAC* ## Singapore PDPA Compliance Guide A practical, implementation-ready Singapore PDPA compliance guide covering every obligation under the Personal Data Protection Act: DPMP governance, DPO appointment, consent and notification management, protection controls, retention and disposal policies, data breach notification, cross-border transfers, and DPTM certification under SS 714:2025. Built from PDPC advisory guidelines, the official DPMP guide, and the accountability framework. Designed for compliance officers, DPOs, and security teams who need a repeatable Singapore PDPA compliance programme with measurable controls and exportable evidence. The Singapore Personal Data Protection Act (PDPA) provides a baseline standard of protection for personal data across all sectors in Singapore. Enacted in 2012 and significantly amended in 2020-2021, the PDPA governs how organisations collect, use, disclose, and care for personal data in both electronic and non-electronic formats. Singapore PDPA compliance requires organisations to address eleven data protection obligations covering the entire data lifecycle from collection through disposal. This Singapore PDPA compliance guide translates those statutory obligations into a structured, implementation-ready programme grounded in official PDPC advisory guidelines and the Guide to Developing a Data Protection Management Programme. It is designed for compliance officers, Data Protection Officers, product teams, security professionals, and operations managers who need to build a Singapore PDPA compliance programme with repeatable workflows, measurable controls, and exportable evidence. Use the PDPA statute, PDPC advisory guidelines, and the official DPMP guide as your authoritative references, and tailor the details to your organisation's specific processing context, risk profile, and industry sector. ## Singapore PDPA compliance framework: understanding the eleven data protection obligations Singapore PDPA compliance begins with a thorough understanding of the eleven data protection obligations that every organisation handling personal data in Singapore must address. These obligations are defined in Parts 3 to 6A of the PDPA and cover the full data lifecycle from collection through disposal. They apply to personal data stored in both electronic and non-electronic formats, and they require organisations to implement policies, processes, and controls that are proportionate to the sensitivity and volume of data they handle. The PDPA recognises both the right of individuals to protect their personal data and the need of organisations to collect, use, or disclose personal data for purposes that a reasonable person would consider appropriate. As stated in section 3 of the Act, Singapore PDPA compliance is not about blocking data flows but about managing them responsibly with proper safeguards, documentation, and accountability. This balanced approach means organisations must invest in structured compliance programmes rather than ad-hoc measures. The scope of Singapore PDPA compliance covers any organisation that collects, uses, or discloses personal data in Singapore. The PDPA generally does not apply to individuals acting in a personal or domestic capacity, employees acting in the course of employment with an organisation, public agencies in relation to the collection, use, or disclosure of personal data, and business contact information such as business email addresses, titles, and business telephone numbers. Understanding these exclusions helps compliance teams focus their Singapore PDPA compliance efforts on the data flows that actually require attention. Amendments passed in November 2020 and phased in from February 2021 significantly strengthened the Singapore PDPA compliance landscape. These changes introduced mandatory data breach notification, expanded deemed consent provisions (including deemed consent by notification and deemed consent by contractual necessity), increased financial penalties up to SGD 1 million or 10 percent of annual turnover (whichever is higher) for organisations with annual turnover exceeding SGD 10 million, and strengthened the accountability framework. These amendments make a structured Singapore PDPA compliance programme more important than ever for organisations operating in Singapore. - Consent Obligation (sections 13-17): obtain valid consent before collecting, using, or disclosing personal data, unless an exception under the First, Second, Third, or Fourth Schedules applies. Singapore PDPA compliance requires consent to be obtained for each specific purpose. - Purpose Limitation Obligation (section 18): collect, use, or disclose personal data only for purposes that a reasonable person would consider appropriate in the circumstances and that the individual has been informed about. - Notification Obligation (section 20): inform individuals of the purposes for which their personal data will be collected, used, or disclosed before or at the time of collection. This is a foundational requirement for Singapore PDPA compliance. - Access and Correction Obligations (sections 21, 22, 22A): provide individuals access to their personal data held by the organisation and correct errors or omissions upon request. Organisations must respond as soon as reasonably possible. - Accuracy Obligation (section 23): make reasonable effort to ensure personal data collected is accurate and complete if it will be used to make a decision affecting the individual or disclosed to another organisation. - Protection Obligation (section 24): protect personal data in your possession or control with reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal, or similar risks. - Retention Limitation Obligation (section 25): cease retaining personal data, or remove the means by which it can be associated with particular individuals, when retention is no longer necessary for any business or legal purpose. - Transfer Limitation Obligation (section 26): ensure personal data transferred outside Singapore receives a comparable standard of protection as under the PDPA, using contractual clauses, binding corporate rules, or APEC CBPR/PRP certification. *Recommended next step* *Placement: after the compliance steps* ## Turn Singapore PDPA Compliance Guide into an operational assessment Assessment Autopilot can take Singapore PDPA Compliance Guide from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on Singapore PDPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Singapore PDPA Compliance Guide](/solutions/assessment.md): Start from Singapore PDPA Compliance Guide and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Singapore PDPA](/contact.md): Review your current process, evidence gaps, and next steps for Singapore PDPA Compliance Guide. ## Building a Singapore PDPA compliance programme with a Data Protection Management Programme (DPMP) The PDPC's Guide to Developing a Data Protection Management Programme provides the official blueprint for structuring your Singapore PDPA compliance efforts. A DPMP is not a single document but a comprehensive system of policies, processes, and practices that embed data protection into your organisation's daily operations. According to the PDPC, accountability requires organisations to undertake measures to manage and protect personal data in order to meet their obligations under the PDPA, including adapting legal requirements into policies and practices, utilising monitoring mechanisms and controls, and building an organisational culture of responsibility through training and awareness programmes. A well-structured Singapore PDPA compliance programme should follow the DPMP's four-step cycle. Step 1 is Governance and Risk Assessment, where you establish a governance structure, define values, and identify risks with organisational leadership. Step 2 is Policy and Practices, where you develop data protection policies and communicate them to internal and external stakeholders. Step 3 is Processes, where you design operational processes for risk identification, mapping, remediation, controls, monitoring, and reporting. Step 4 is Maintenance, where you review, audit, and update your data protection policies and practices to keep them relevant. This iterative approach ensures your Singapore PDPA compliance programme matures over time rather than remaining a static set of documents. The DPMP should be tailored to the size and nature of your organisation, the volume and sensitivity of personal data you handle, and the risks associated with your processing activities. A startup handling basic customer contact details will have a different DPMP than a healthcare provider processing sensitive medical records or a financial institution subject to additional sector-specific requirements under the Banking Act or Insurance Act. The key is proportionality: your Singapore PDPA compliance controls should match your risk level. Implementation of your Singapore PDPA compliance programme should be phased to avoid overwhelming teams. The PDPC's guide recommends benchmarking your existing practices against the DPMP framework to identify gaps and prioritise remediation. Begin with the foundational elements that create the most compliance value, then progressively add more sophisticated controls. Having an established DPMP helps an organisation demonstrate accountability in data protection, which provides confidence to stakeholders and fosters higher-trust relationships with customers and business partners. - Phase 1 - Foundation: appoint a DPO, create a personal data inventory, draft a baseline data protection notice (using the PDPC's Data Protection Notice Generator), establish a processing register documenting all data flows, and classify vendors by data access level. - Phase 2 - Operational workflows: build access and correction request handling procedures with defined response timeframes, implement a retention schedule with secure disposal processes, create a data breach assessment and notification runbook aligned with the 3-day PDPC notification requirement, and establish consent collection and withdrawal mechanisms. - Phase 3 - Advanced controls: implement cross-border transfer safeguards with contractual protections or APEC CBPR/PRP certification, set up DNC registry compliance checks for marketing operations, introduce Data Protection Impact Assessments (DPIAs) for high-risk processing, and build anonymisation protocols for analytics use cases. - Phase 4 - Assurance and improvement: schedule quarterly DPMP reviews with management reporting, conduct annual compliance audits, run tabletop breach exercises using the CARE framework (Contain, Assess, Report, Evaluate), update policies based on PDPC enforcement decisions, and prepare evidence packs for regulatory inquiries. - Create a DPMP governance document that maps each PDPA obligation to a specific policy, process owner, evidence artifact, and last review date. This master index is the backbone of your Singapore PDPA compliance evidence. - Maintain a centralised compliance dashboard that tracks the status of all DPMP components, upcoming review dates, open remediation items, and key performance indicators such as access request response times and training completion rates. - Use PDPC-provided tools to accelerate your Singapore PDPA compliance programme: the Data Protection Notice Generator for compliant notices, the PATO self-assessment tool for gap analysis, the DPOinBox for programme management, and the Data Protection Starter Kit Checklist for initial gap identification. ## Appointing a Data Protection Officer for Singapore PDPA compliance: role, responsibilities, and governance Under the PDPA's Accountability Obligation, every organisation must designate at least one individual as its Data Protection Officer (DPO). The DPO serves as the primary point of contact for data protection matters within the organisation and acts as the liaison with the PDPC. This appointment is mandatory for Singapore PDPA compliance regardless of your organisation's size or the volume of personal data you process. The DPO is a key management function within the oversight and governance structure required for effective Singapore PDPA compliance. According to the PDPC's Guide to Developing a DPMP, a DPO should ideally be an appointment within the organisation's senior management. If the DPO is not appointed from the ranks of senior management, they should have a direct line of reporting to senior management. The DPO's key responsibilities for Singapore PDPA compliance include driving the development and review of data protection policies and processes, ensuring compliance with the PDPA, fostering a personal data protection culture, identifying and alerting management to data protection risks, handling access and correction requests, managing queries and complaints, and engaging with the PDPC on personal data protection matters. The DPO does not need to hold that title exclusively and may hold other roles within the organisation, but they must have sufficient authority, resources, and access to senior management to fulfil their Singapore PDPA compliance responsibilities effectively. In larger organisations, the DPO should be supported by a dedicated data protection team that may include department representatives, communications staff, access and correction request handlers, and incident response personnel. Some organisations may outsource the DPO function, but a member of senior management must remain responsible to oversee and work with the outsourced DPO. The DPO's business contact information must be made available to the public as part of your Singapore PDPA compliance obligations. This is typically done by publishing the DPO's contact details on the organisation's website, in its data protection notice, and on request. The PDPC also strongly encourages DPOs to use the DPO Competency Framework and Training Roadmap to build core competencies and achieve the proficiency levels set out for the role. - Designate a DPO by name and role within your organisational chart. Document the appointment in your DPMP governance records as evidence of Singapore PDPA compliance with the Accountability Obligation. - Define and document the DPO's core responsibilities: overseeing PDPA compliance, managing data protection policies, handling access and correction requests, coordinating breach response using the CARE framework, training staff, and liaising with the PDPC. - Publish the DPO's business contact information on your website, in your data protection notice, and in employee-facing communications. This transparency is a mandatory requirement for Singapore PDPA compliance. - Establish a reporting line that gives the DPO direct access to senior management or the board for escalation of significant data protection issues. The PDPC recommends that data protection have board and senior management level oversight. - Allocate a dedicated budget for data protection activities including training, tools such as DPOinBox and PATO, external assessments, and incident response resources. - Schedule regular reporting from the DPO to senior management covering changes to data protection policies, DPIA results, risk updates, audit plans, and key data protection issues. The PDPC suggests quarterly and annual reporting cadences. - Invest in ongoing professional development for the DPO through PDPC events, the PDPC E-Learning Programme, sectoral briefings, and professional certifications such as the Certified Information Privacy Manager or Certified Information Privacy Professional Asia. ## Data inventory and mapping for Singapore PDPA compliance: know what you hold A comprehensive personal data inventory is the foundation of every Singapore PDPA compliance obligation. You cannot protect, limit retention of, or respond to access requests for data you do not know you have. The PDPC's DPMP guide emphasises that known risks should be managed through a good understanding of the lifecycle and flow of personal data in your organisation. This can be done through documenting the personal data handled using data inventory maps, data flow diagrams, risk registers, and consent registers. Data mapping goes beyond inventory by documenting the flow of personal data through your organisation: where it enters, how it moves between systems and departments, who has access, whether it is transferred overseas, and when it is scheduled for disposal. The PDPC provides a Sample Personal Data Inventory Map Template and Data Flow Illustration tool to help organisations visualise and manage these flows. This end-to-end visibility is essential for identifying Singapore PDPA compliance gaps, especially around the Transfer Limitation Obligation, the Protection Obligation, and data breach risk assessment. The PDPA defines personal data as data about an individual who can be identified from that data, or from that data combined with other information to which the organisation has or is likely to have access. This broad definition means your Singapore PDPA compliance inventory should cover not just obviously identifiable records like names and NRIC numbers but also indirect identifiers like IP addresses, device IDs, and location data that could identify someone when combined with other datasets. Your inventory should also classify the risk level of data in the context that it is collected, used, and disclosed throughout the data lifecycle, considering confidentiality, integrity, and availability risks. Your data inventory should be treated as a living document that is updated whenever new processing activities are introduced, systems change, or business relationships evolve. Stale inventories create blind spots that undermine Singapore PDPA compliance, especially during breach investigations and access request fulfilment. The PDPC recommends conducting a DPIA as part of the inventory process to identify data protection risks and address them through policy, technical, or process measures. - Catalogue every personal data element by category (identity, contact, financial, health, employment, behavioural, technical identifiers) and link each to a business purpose and lawful basis for processing under the PDPA. - Map data flows end-to-end using the PDPC's recommended format: collection point, internal systems, third-party recipients, overseas transfers, retention periods, and disposal mechanisms. The data inventory map and data flow diagram are core tools for Singapore PDPA compliance. - Identify and document all data intermediaries (processors) that handle personal data on your behalf. Under the PDPA, data intermediaries must adhere to the Protection, Retention Limitation, and Data Breach Notification Obligations. Use binding contractual agreements that highlight data processing responsibilities. - Record where personal data is stored physically and logically, including databases, file shares, SaaS applications, backup systems, and paper records. Apply need-to-know access controls as recommended by the PDPC. - Flag high-risk processing activities such as large-scale profiling, automated decision-making, processing of NRIC numbers and other sensitive data, and cross-border transfers for enhanced controls and DPIA assessment. - Create and maintain a consent register that records consent provided by individuals for the collection, use, and disclosure of their personal data for each specific purpose. Track consent versions so you know which consent clause each customer agreed to. - Assign a data owner for each processing activity who is responsible for maintaining inventory accuracy, reviewing retention compliance, and coordinating with the DPO on changes. Conduct a full inventory refresh at least annually. - Use PDPC-provided tools to support your Singapore PDPA compliance inventory: the Sample Personal Data Inventory Map Template, the Data Flow Illustration tool, the DPOinBox programme management tool, and the OneTrust Software for PDPA Compliance. ## Consent and notification management under Singapore PDPA compliance: getting the legal basis right The Consent Obligation is central to the Singapore PDPA compliance framework. Under sections 13 to 17 of the PDPA, organisations must obtain consent from individuals before collecting, using, or disclosing their personal data, unless a specific exception applies. Section 14(1) states how an individual gives consent under the PDPA: consent must be obtained for each purpose, and individuals must be informed of those purposes before or at the time of collection through the Notification Obligation under section 20. The 2021 amendments expanded the consent framework significantly, creating new pathways for Singapore PDPA compliance. Deemed consent by notification (section 15A) allows organisations to collect, use, or disclose personal data without express consent if they notify the individual, give a reasonable opportunity to opt out, and the purposes meet certain conditions. Deemed consent by contractual necessity (section 15) applies when the collection, use, or disclosure is reasonably necessary for the performance of a contract between the organisation and the individual. These mechanisms reduce the burden of obtaining express consent while still maintaining compliant Singapore PDPA compliance practices. The PDPA also provides exceptions to consent under the First, Second, Third, and Fourth Schedules. These include the business improvement exception (allowing use of personal data for improving goods, services, or business processes), the research exception (allowing use for research with a clear public benefit), vital interests, national interests, publicly available data, and the legitimate interests exception (section 13(2)). Understanding when these exceptions apply helps organisations avoid over-consenting while maintaining robust Singapore PDPA compliance. The PDPC's Advisory Guidelines on Key Concepts provide detailed interpretation guidance on each exception. Withdrawal of consent is a fundamental right under the PDPA. Organisations pursuing Singapore PDPA compliance must allow individuals to withdraw consent at any time with reasonable notice. Upon withdrawal, the organisation must inform the individual of the likely consequences and cease collecting, using, or disclosing the personal data unless an exception applies. Organisations must not prohibit or penalise individuals for withdrawing consent beyond the natural consequences of withdrawal. - Design consent collection mechanisms that are clear, specific, and granular: each purpose should be separately identifiable so individuals can make informed choices. This is a core requirement for Singapore PDPA compliance. - Implement the Notification Obligation by issuing a data protection notice before or at the time of collection that covers: the purposes of collection, use, and disclosure; categories of third parties to whom data may be disclosed; and the DPO's contact details. Use the PDPC's Data Protection Notice Generator to create compliant notices. - Build a consent record system that logs when consent was given, for which purposes, through which channel, the version of the consent clause agreed to, and any subsequent modifications or withdrawals. This consent registry is essential evidence for Singapore PDPA compliance. - Implement deemed consent by notification workflows where appropriate: send a clear notification describing the intended purpose, provide a reasonable opt-out period, document the notification and opt-out window, and proceed only after the opt-out period expires without objection. - Map each processing activity to its legal basis: express consent, deemed consent (by conduct, by notification, or by contractual necessity), or a specific exception under the Schedules. Document this mapping as part of your Singapore PDPA compliance records. - Establish a consent withdrawal process with a documented procedure: acknowledge the request, inform the individual of likely consequences within a reasonable timeframe, cease processing, and log the withdrawal in your consent management system. - Review consent mechanisms and data protection notices at least quarterly, and update them whenever you add new processing purposes, change how you disclose personal data, or when PDPC advisory guidelines are revised. - For Singapore PDPA compliance with the legitimate interests exception, conduct and document the required assessment before relying on this basis. The assessment must demonstrate that the legitimate interest outweighs any adverse effect on the individual. ## Protection Obligation and data breach notification: securing personal data under Singapore PDPA compliance The Protection Obligation under section 24 of the PDPA requires organisations to implement reasonable security arrangements to protect personal data from unauthorised access, collection, use, disclosure, copying, modification, disposal, or similar risks. Singapore PDPA compliance demands that the standard of protection be proportionate to the sensitivity of the data, the volume of data held, the potential harm from a breach, and the cost of implementing safeguards. The PDPC has published guidance on data protection practices for ICT systems and enforcement decisions that illustrate what constitutes adequate and inadequate protection measures. Reasonable security arrangements for Singapore PDPA compliance encompass administrative, physical, and technical safeguards. Administrative safeguards include security policies, access control procedures, staff training, and vendor management. Physical safeguards cover restricted access to offices, secure disposal of physical records, and environmental controls. Technical safeguards include encryption, role-based access controls, network segmentation, intrusion detection, vulnerability management, and secure development practices. The PDPC's Guide to Data Protection by Design for ICT Systems provides detailed guidance on embedding data protection into systems from the earliest design stage. The 2021 amendments introduced mandatory data breach notification requirements that are central to Singapore PDPA compliance. A notifiable data breach occurs when it results in, or is likely to result in, significant harm to the affected individuals, or it is of a significant scale (affecting 500 or more individuals). You must notify the PDPC as soon as practicable, and no later than 3 calendar days after assessing the breach as notifiable. The 3-day period starts the day after the organisation makes the determination. If the breach is likely to result in significant harm to individuals, you must also notify those affected individuals. The PDPC's DPMP guide recommends that organisations establish a breach management process following the CARE framework: Contain the breach, Assess the risk, Report the incident to the PDPC and affected individuals where required, and Evaluate the response and recovery to prevent future breaches. Organisations must conduct the assessment of whether a breach is notifiable within 30 calendar days of becoming aware of the breach. Documenting the steps taken demonstrates that the organisation has been reasonable and expeditious in its Singapore PDPA compliance response. - Implement role-based access controls (RBAC) across all systems containing personal data, with the principle of least privilege and need-to-know access as recommended by the PDPC. Conduct regular access reviews as part of your Singapore PDPA compliance programme. - Encrypt personal data at rest and in transit using industry-standard encryption protocols. Ensure encryption key management follows documented procedures and is included in your data protection policy. - Deploy network segmentation, firewalls, and intrusion detection/prevention systems to protect systems that store or process personal data. The PDPC's Guide to Data Protection by Design for ICT Systems provides detailed technical guidance. - Establish a vulnerability management programme with regular scanning, patching cadence, and penetration testing of systems handling personal data. Document all activities as evidence of Singapore PDPA compliance with the Protection Obligation. - Train all staff who handle personal data on security awareness, phishing prevention, and the organisation's data protection policies at onboarding and at least annually. The PDPC recommends designing training by role, function, and hierarchy as outlined in the DPMP guide's Annex B. - Build a data breach response plan using the CARE framework: Contain the breach and prevent further exposure, Assess notifiability (significant harm or 500+ individuals affected), Report to the PDPC within 3 calendar days after determination and notify affected individuals where required, and Evaluate the response for continuous improvement. - Conduct tabletop breach exercises at least twice a year to test your response plan, measure time-to-detect and time-to-notify, and identify process gaps. Engage data intermediaries in exercises and delineate responsibilities for reporting and remediation. - Maintain security incident logs, patch records, access review records, breach assessment documentation (including non-notifiable breaches), and training completion records as evidence of ongoing Singapore PDPA compliance with the Protection Obligation. ## Retention, disposal, and cross-border transfers: completing your Singapore PDPA compliance controls The Retention Limitation Obligation under section 25 of the PDPA requires organisations to cease retaining personal data, or remove the means by which it can be associated with particular individuals, as soon as it is reasonable to assume that the purpose for which the data was collected is no longer being served by retention and retention is no longer necessary for any business or legal purpose. This obligation is a critical component of Singapore PDPA compliance because it prevents organisations from accumulating personal data indefinitely and reduces risk exposure in the event of a data breach. Building an effective retention framework for Singapore PDPA compliance requires mapping each category of personal data to a specific retention period justified by its business or legal purpose. The PDPC's advisory guidelines note that retention of personal data for analytics and research is valid only when there is an immediate and demonstrable intent to perform analysis or conduct research. Organisations should establish clear policies for when retention periods begin, how they are calculated, what triggers disposal, and which disposal method is appropriate for each data category and media type. The Transfer Limitation Obligation under section 26 of the PDPA requires organisations to ensure that personal data transferred outside Singapore receives a comparable standard of protection as under the PDPA. Singapore PDPA compliance with this obligation can be achieved through several mechanisms: binding contractual arrangements with the overseas recipient, certification of the overseas recipient under the APEC Cross Border Privacy Rules (CBPR) or Privacy Recognition for Processors (PRP) systems, ensuring the recipient is subject to comparable data protection law, or obtaining the individual's consent after informing them of the risks. The PDPC's Guidance for Use of ASEAN Model Contractual Clauses provides a standardised approach for cross-border transfers within ASEAN. Organisations should pay special attention to data held in backup systems, archive storage, and third-party systems when implementing Singapore PDPA compliance retention controls. These secondary copies are often overlooked in retention and disposal programmes but still contain personal data subject to the PDPA's obligations. Your retention policy should explicitly address how backups are managed within the retention schedule and how expired data is removed from backup sets. - Create a retention schedule that maps every personal data category to a defined retention period, legal or business justification, disposal method, and responsible data owner. This schedule is a core artifact for Singapore PDPA compliance. - Implement automated retention enforcement where possible: configure database TTLs, file lifecycle policies, and SaaS platform retention settings to automatically flag or delete data when its retention period expires. - Document the legal bases for retention periods (for example, statutory requirements under the Companies Act, Employment Act, Income Tax Act, or contractual obligations) and review them annually for changes in law or business need. - Establish a secure disposal procedure that covers all media types: electronic deletion with verification, physical destruction with certificates of destruction, and third-party disposal service agreements with data protection clauses. - For Singapore PDPA compliance with the Transfer Limitation Obligation, maintain a register of all cross-border transfers that documents the recipient, destination country, legal basis for transfer (contractual clauses, CBPR/PRP certification, comparable law, or consent), and the date of last review. - Include data protection clauses in all contracts with overseas recipients and data intermediaries. The PDPC's Guide on Data Protection Clauses for Agreements Relating to the Processing of Personal Data provides model clauses. - Address backup and archive data explicitly in your retention policy: define how long backups are kept, when personal data in backups expires, and how expired data is removed from backup sets. Consider anonymisation as an alternative to deletion for datasets with ongoing analytical value. - Conduct an annual retention audit to identify data held beyond its retention period and enforce disposal. Document audit findings and remediation actions as evidence of Singapore PDPA compliance. ## Accountability, documentation, and evidence engineering for Singapore PDPA compliance The PDPC's Guide to Accountability explains that organisations should shift from a compliance-based approach to an accountability-based approach in managing personal data. Accountability for Singapore PDPA compliance means not just following the rules but being able to demonstrate that you have taken responsibility for and can show evidence of your data protection practices. This proactive stance strengthens trust with the public, enhances business competitiveness, and provides greater assurance to customers, all of which are necessary factors for organisations to thrive in Singapore's digital economy. Under the PDPA's Accountability Obligation, organisations must develop and implement policies and practices necessary to meet their obligations under the Act, communicate these policies to staff, and make information about them available to individuals on request. Singapore PDPA compliance documentation should include a comprehensive data protection policy, acceptable use policy, breach response plan, retention schedule, vendor management policy, cross-border transfer policy, DNC compliance procedures, and consent management procedures. Each policy should be approved by management, communicated to all relevant parties, and reviewed regularly. Evidence engineering is the discipline of creating, maintaining, and exporting proof of Singapore PDPA compliance. Every policy, procedure, training session, audit, and incident response should generate a documented artifact that can be produced on request by the PDPC or during legal proceedings. The goal is to reduce the time between a regulatory inquiry and a complete evidence export to the minimum possible. A master evidence index should map every PDPA obligation to its corresponding policy document, process owner, evidence artifact, and last review date. Accountability also plays a direct role in enforcement outcomes. The PDPC's Active Enforcement Framework recognises that organisations with demonstrable accountability practices may receive more favourable treatment during enforcement proceedings. DPTM-certified organisations or those that can show responsible data protection practices may be able to initiate an undertaking process rather than face a full investigation and formal enforcement action. This makes strong Singapore PDPA compliance documentation a strategic investment in risk mitigation. - Build a master evidence index that maps every PDPA obligation to its corresponding policy document, process owner, evidence artifact, and last review date. This index is the central navigation tool for your Singapore PDPA compliance evidence. - Document all data protection policies in a structured, versioned format: data protection policy, acceptable use policy, breach response plan (CARE framework), retention schedule, vendor management policy, cross-border transfer policy, and DNC compliance procedures. - Maintain logs of all access and correction requests received, response timelines, outcomes, and any applicable exceptions or prohibitions invoked. The PDPC's Advisory Guidelines on Key Concepts Chapter 15 provides detailed guidance on handling access requests. - Keep records of all consent collection events, notifications issued, deemed consent assessments, and consent withdrawals processed, with timestamps, channel details, and consent clause versions. - Document all data protection training delivered, including content, attendees, completion dates, and assessment results. The DPMP guide's Annex B provides a model training and communication plan aligned to a typical employment journey. - Archive all data breach assessments (including breaches determined to be non-notifiable), notifications sent to the PDPC and affected individuals, remediation actions, root cause analyses, and the 30-day assessment documentation. - Conduct and document periodic compliance reviews and internal audits, capturing findings, remediation plans, completion status, and management sign-off. Use the PDPC's PATO self-assessment tool to identify residual gaps. - Store all evidence artifacts in a secure, searchable repository with access controls and audit trails to ensure integrity and availability for Singapore PDPA compliance demonstrations. ## Data Protection Trustmark (DPTM) certification: elevating your Singapore PDPA compliance The Data Protection Trustmark (DPTM) Certification was developed by the PDPC and the Infocomm Media Development Authority (IMDA) to help organisations demonstrate Singapore PDPA compliance in a verifiable, externally validated way. The DPTM is now part of the national Singapore Standards as SS 714:2025, which elevates the level of recognition for DPTM-certified organisations and positions the certification as a benchmark for data protection maturity in the APAC region. Getting DPTM certified provides several tangible benefits for organisations pursuing Singapore PDPA compliance. The DPTM serves as an accountability tool to demonstrate to customers, business partners, and the regulator that your organisation adopts responsible data protection practices. For data intermediaries and third-party service providers, DPTM certification assures clients of sound data protection policies. The DPTM may serve as a mitigating factor against enforcement action in the event of a data breach, and under the PDPC's Active Enforcement Framework, DPTM-certified organisations that demonstrate accountable practices may initiate an undertaking process rather than face full investigation. The revised DPTM under SS 714:2025 offers a streamlined certification experience designed to support organisations in staying future-ready. Organisations work with one IMDA-appointed certification body throughout their certification journey. Professional assessments are conducted by bodies overseen by the Singapore Accreditation Council. Annual surveillance audits enhance confidence in ongoing data protection practices and demonstrate continued commitment to Singapore PDPA compliance. This structure means certification is not a one-time exercise but an ongoing assurance programme that validates your organisation's data protection posture year after year. Preparing for DPTM certification is a natural extension of building a mature Singapore PDPA compliance programme through a DPMP. If you have implemented the governance structures, policies, processes, and evidence practices described in this guide, you are well-positioned to pursue certification. The certification assessment evaluates your organisation's data protection practices against the SS 714:2025 requirements, which align closely with the PDPA's obligations and the PDPC's accountability expectations. - Review the Data Protection Trustmark SS 714:2025 standard, available from the Singapore Standards e-shop, to understand the certification requirements and how they map to your existing DPMP and Singapore PDPA compliance programme. - Conduct an internal gap assessment comparing your current data protection practices against the DPTM certification criteria before engaging a certification body. Use the PATO self-assessment tool and your master evidence index to identify areas needing improvement. - Select an IMDA-appointed certification body to conduct the formal assessment. The list of appointed bodies is available on the IMDA website at imda.gov.sg/dptm. - Prepare your evidence portfolio for certification: the certification body will evaluate your policies, procedures, training records, incident response capabilities, vendor management practices, data protection governance structures, and overall Singapore PDPA compliance posture. - Address any gaps identified during the assessment within the remediation timeline provided by the certification body. Document all remediation actions as evidence of continuous improvement. - Plan for annual surveillance audits after initial certification: maintain all evidence artifacts, continue regular DPMP reviews, keep your data protection practices current with PDPC regulatory changes, and ensure your Singapore PDPA compliance programme remains operational. - Publicise your DPTM certification to customers, partners, and stakeholders as a mark of trust and competitive differentiation in the APAC market. - Use the certification cycle as an opportunity to benchmark your Singapore PDPA compliance practices against industry peers and identify areas for continuous improvement in data protection maturity. ## Ongoing monitoring and maintenance of your Singapore PDPA compliance programme Singapore PDPA compliance is not a project with a finish date but an ongoing programme that must adapt to changes in your business, technology, regulatory guidance, and threat landscape. The PDPC regularly publishes enforcement decisions, advisory guidelines, sector-specific guidance, and practical guidance that may affect your compliance posture. The DPMP guide emphasises that organisations need to keep abreast of changes and developments both within and outside the organisation to ensure that data protection policies and practices remain relevant and updated. A governance rhythm prevents surprises and keeps evidence fresh. The PDPC recommends both immediate (ad-hoc) reviews triggered by major incidents, legislative amendments, or organisational changes, and periodic reviews at regular intervals to ensure policies and processes remain relevant. Your Singapore PDPA compliance programme should define a minimum cadence for reviews, exercises, and audits that ensures every DPMP component is examined at least annually, with more frequent reviews for high-risk areas. Monitoring your Singapore PDPA compliance programme should include tracking changes in your own organisation. New products, services, business units, vendors, systems, and data flows all introduce potential compliance gaps. The PDPC recommends conducting a DPIA on systems and processes that are newly designed or undergoing major changes. A change management process that triggers a data protection review whenever significant changes occur is essential for maintaining continuous Singapore PDPA compliance. Invest in metrics that tell you whether your Singapore PDPA compliance programme is working. Track response times for access and correction requests (target: as soon as reasonably possible, within 30 days), breach detection-to-notification timelines (target: assessment within 30 days, PDPC notification within 3 days of determination), training completion rates across all staff levels, consent management accuracy, and evidence index completeness. These operational metrics provide early warning of programme degradation and support continuous improvement. - Weekly: review open access and correction requests, monitor active security incidents, check consent withdrawal queue processing times, and verify DNC registry compliance for any marketing campaigns sent. - Monthly: review vendor and third-party changes (new vendors, sub-processor changes, new data sharing arrangements), update the data inventory for any new processing activities, and review incident logs for potential data protection issues. - Quarterly: conduct a DPMP component review covering policies, data protection notices, and procedures. Refresh the data inventory and retention schedule. Review PDPC enforcement decisions for lessons learned. Update training materials. Report to senior management on Singapore PDPA compliance status, risk updates, and remediation plans. - Semi-annually: run tabletop exercises for data breach response testing detection, assessment, notification, and remediation workflows. Conduct access request surge scenarios. Review cross-border transfer safeguards and overseas recipient assessments. Engage data intermediaries in joint exercises. - Annually: conduct a comprehensive DPMP audit and gap assessment using the PATO tool. Review and update all policies and procedures. Refresh staff training programme content across all levels per the DPMP guide's training roadmap. Assess the need for DPTM certification or re-certification. Produce an annual Singapore PDPA compliance report for senior management and the board. - Track key performance indicators: average access request response time (target under 30 days), breach assessment completion time (target under 30 days), PDPC notification time (target under 3 days after determination), consent withdrawal processing time, training completion rate by staff level, evidence index completeness percentage, and open remediation item count. - Subscribe to PDPC announcements, enforcement decisions, and advisory guideline updates through DPO Connect and the PDPC website to stay current with evolving Singapore PDPA compliance expectations. - Assign clear ownership for each monitoring activity, document findings in a compliance log, and escalate unresolved items to the DPO and senior management. Use the compliance log as ongoing evidence of your organisation's commitment to Singapore PDPA compliance. ## Primary sources - [Personal Data Protection Act 2012 (Singapore) - official text](https://sso.agc.gov.sg/Act/PDPA2012?ref=sorena.io) - Primary legislation governing collection, use, disclosure, protection, retention, transfer, and accountability for personal data in Singapore. The authoritative legal basis for all Singapore PDPA compliance obligations. - [PDPC - PDPA overview](https://www.pdpc.gov.sg/overview-of-pdpa/pdpa-overview?ref=sorena.io) - Official PDPC overview of PDPA obligations, key concepts, scope, exclusions, and the 2020-2021 amendments. - [PDPC - Advisory Guidelines on Key Concepts in the PDPA (Revised 16 May 2022)](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-the-personal-data-protection-act?ref=sorena.io) - Detailed interpretation guidance for consent, deemed consent, purpose limitation, notification, access and correction, accuracy, protection, retention, transfers, accountability, and data breach notification under the PDPA. - [PDPC - Guide to Developing a Data Protection Management Programme (DPMP)](https://www.pdpc.gov.sg/help-and-resources/2019/07/guide-to-developing-a-data-protection-management-programme?ref=sorena.io) - Official four-step DPMP blueprint covering governance and risk assessment, policy and practices, processes, and maintenance. Includes annexes on DPO structure, training roadmap, and data inventory templates. - [PDPC - Guide to Accountability under the Personal Data Protection Act](https://www.pdpc.gov.sg/help-and-resources/2019/07/guide-to-accountability-under-the-personal-data-protection-act?ref=sorena.io) - Guidance on shifting from compliance-based to accountability-based data protection management, including the Active Enforcement Framework and its implications for organisations. - [PDPC - Data Protection Trustmark (DPTM) and SS 714:2025](https://www.pdpc.gov.sg/overview-of-pdpa/data-protection/business-owner/data-protection-trustmark?ref=sorena.io) - Information on DPTM certification under the national Singapore Standards SS 714:2025, certification benefits, the streamlined process, and annual surveillance audits. - [PDPC - Enforcement advisory guidelines](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-enforcement-of-data-protection-provisions?ref=sorena.io) - Enforcement approach, directions, financial penalties (up to SGD 1 million or 10% of annual turnover), and undertakings under the PDPC's Active Enforcement Framework. ## Related Topic Guides - [Singapore PDPA Applicability Test | Does the PDPA Apply to Your Organisation?](/artifacts/apac/singapore-pdpa/applicability-test.md): Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation. - [Singapore PDPA Breach Notification Playbook - Complete Guide](/artifacts/apac/singapore-pdpa/breach-notification-playbook.md): Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline. - [Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026)](/artifacts/apac/singapore-pdpa/checklist.md): Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules. - [Singapore PDPA Compliance Deadlines and Calendar](/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar.md): Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows. - [Singapore PDPA Consent and Notification Obligations Guide](/artifacts/apac/singapore-pdpa/consent-notification-and-purposes.md): Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception. - [Singapore PDPA Cross-Border Transfer Rules | Section 26 Data Transfer Compliance](/artifacts/apac/singapore-pdpa/cross-border-transfers.md): Complete guide to Singapore PDPA cross-border transfer compliance under Section 26. - [Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide](/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages.md): Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses. - [Singapore PDPA FAQ | Frequently Asked Questions on Personal Data Protection Act Compliance](/artifacts/apac/singapore-pdpa/faq.md): Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements. - [Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions](/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases.md): Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover. - [Singapore PDPA Penalties and Fines | SGD 1M or 10% Turnover Cap + PDPC Enforcement Guide](/artifacts/apac/singapore-pdpa/penalties-and-fines.md): Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions. - [Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide](/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template.md): Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions. - [Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC)](/artifacts/apac/singapore-pdpa/requirements.md): Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18). - [Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations](/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries.md): Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion. - [Singapore PDPA Vendor Outsourcing and Contracts Guide](/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts.md): Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence. - [Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties](/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr.md): Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/singapore-pdpa/compliance --- --- title: "Singapore PDPA Consent and Notification Obligations Guide" canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/consent-notification-and-purposes" source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/consent-notification-and-purposes" author: "Sorena AI" description: "Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Singapore PDPA consent" - "Singapore PDPA notification" - "Singapore PDPA consent obligation" - "Singapore PDPA notification obligation" - "PDPA deemed consent by conduct" - "PDPA deemed consent by notification" - "PDPA deemed consent by contractual necessity" - "PDPA express consent requirements" - "PDPA purpose limitation obligation" - "Singapore PDPA legitimate interests exception" - "Singapore PDPA business improvement exception" - "Singapore PDPA withdrawal of consent" - "PDPA consent management Singapore" - "Singapore personal data protection consent" - "PDPC advisory guidelines consent" - "Singapore PDPA compliance" - "PDPA section 13 consent" - "PDPA section 14 requirements" - "PDPA section 15 deemed consent" - "PDPA section 15A deemed consent notification" - "PDPA section 16 withdrawal" - "PDPA section 17 exceptions" - "PDPA section 18 purpose limitation" - "PDPA section 20 notification" - "Singapore PDPA consent framework" - "Singapore data protection consent guide" - "PDPA opt-out mechanism" - "Singapore PDPA direct marketing consent" - "PDPA assessment checklist" - "PDPA data protection officer" - "PDPA accountability obligation" - "Singapore PDPA compliance checklist" - "Singapore PDPA consent for marketing" - "PDPA Annex B checklist" - "PDPA Annex C checklist" - "Singapore PDPA balancing test" - "Singapore PDPA adverse effect assessment" - "Personal Data Protection Act" - "PDPA consent obligation" - "PDPA deemed consent" - "PDPA notification obligation" - "PDPA purpose limitation" - "PDPA legitimate interests" - "PDPA business improvement exception" - "Singapore PDPA express consent" - "Singapore PDPA deemed consent by notification" - "APAC privacy" - "data protection Singapore" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Singapore PDPA Consent and Notification Obligations Guide Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception. *Artifact Guide* *APAC* ## Singapore PDPA Consent, Notification, and Purpose Limitation A comprehensive guide to Singapore PDPA consent and Singapore PDPA notification obligations covering express consent, deemed consent by conduct and by notification, legitimate interests and business improvement exceptions, purpose limitation, and consent withdrawal procedures under the Personal Data Protection Act. Grounded in PDPC advisory guidelines (revised 16 May 2022) and official assessment checklists. Built for product, legal, and compliance teams implementing defensible Singapore PDPA consent management. This page provides a detailed, implementation-focused guide to the Singapore PDPA consent and Singapore PDPA notification obligations under the Personal Data Protection Act (PDPA). It is written for product managers, legal counsel, data protection officers, and operations teams who need to build a defensible Singapore PDPA consent management program with auditable evidence. The guidance draws directly from the PDPA statute (sections 13 through 20), the PDPC Advisory Guidelines on Key Concepts (revised 16 May 2022), the PDPC Advisory Guidelines on the PDPA for Selected Topics (revised 23 May 2024), and the official PDPC assessment checklists at Annex B (deemed consent by notification) and Annex C (legitimate interests exception). Each section below maps a specific Singapore PDPA consent or Singapore PDPA notification requirement to practical steps, documentation artifacts, and enforcement lessons. Tailor the details to your specific processing context, data inventory, and organisational structure. ## Singapore PDPA consent framework overview The Singapore PDPA consent framework establishes a multi-layered system that governs how organisations collect, use, and disclose personal data. Section 13 of the PDPA sets out the core principle: organisations may only collect, use, or disclose an individual's personal data if the individual gives Singapore PDPA consent for those purposes. This Singapore PDPA consent obligation operates alongside the purpose limitation obligation (section 18) and the Singapore PDPA notification obligation (section 20) to form the foundation of lawful data processing in Singapore. The Singapore PDPA recognises that requiring express consent for every data activity would be impractical and could impede legitimate business operations. The framework therefore provides multiple mechanisms beyond express consent: deemed consent by conduct (section 15(1)), deemed consent by contractual necessity (section 15(3)), deemed consent by notification (section 15A), and several exceptions to consent including the legitimate interests exception (paragraph 1, Part 3, First Schedule), the business improvement exception (Part 5, First Schedule), and the research exception (Division 3, Part 2, Second Schedule). Organisations must determine which mechanism applies to each data processing activity and document that determination as part of their Singapore PDPA consent management program. The Singapore PDPA consent framework follows a decision hierarchy that the PDPC has set out in Annex A of the advisory guidelines. First, the organisation should assess whether the data is personal data at all, because anonymised or aggregated data falls outside the PDPA. Second, it should check whether any written law requires or authorises the collection, use, or disclosure. Third, it should determine whether any exception to consent applies, such as vital interests, legitimate interests, business improvement, or research. Only if none of these apply does the organisation proceed to rely on Singapore PDPA consent, choosing the appropriate form from deemed consent or express consent. Understanding this hierarchy is essential for building a defensible Singapore PDPA consent program. Over-relying on express consent where an exception applies creates unnecessary user friction and consent fatigue. Conversely, relying on an exception without proper documentation exposes the organisation to enforcement risk. The PDPC expects organisations to match the correct legal basis to each processing activity, maintain auditable records of that matching, and review the mapping periodically as business activities change. - Section 13 of the PDPA establishes the Singapore PDPA consent obligation as the default legal basis for collecting, using, or disclosing personal data in Singapore. - The framework provides four Singapore PDPA consent mechanisms: express consent, deemed consent by conduct (section 15(1)), deemed consent by contractual necessity (section 15(3)), and deemed consent by notification (section 15A). - Exceptions to Singapore PDPA consent are enumerated in the First and Second Schedules. Key exceptions include legitimate interests (paragraph 1, Part 3, First Schedule), business improvement (Part 5, First Schedule), research (Division 3, Part 2, Second Schedule), vital interests, and public interest. - Annex A of the PDPC advisory guidelines provides a flowchart for determining the correct provision to rely on when collecting, using, or disclosing personal data under the Singapore PDPA consent framework. - Organisations should build a purpose register that maps each data processing activity to its Singapore PDPA consent legal basis and records the supporting documentation. - The Singapore PDPA consent obligation does not apply where collection, use, or disclosure is required or authorised under the PDPA or any other written law. - Anonymised or aggregated data that cannot identify any individual falls outside the PDPA entirely and does not require Singapore PDPA consent. ## Singapore PDPA express consent requirements and collection methods Express consent is the clearest and most defensible form of Singapore PDPA consent. Section 14(1) of the PDPA establishes two mandatory conditions for valid Singapore PDPA consent: the individual must be notified of the purposes for which personal data will be collected, used, or disclosed (satisfying the Singapore PDPA notification requirement), and the individual must provide consent for those specific purposes. Singapore PDPA consent obtained without proper purpose notification is invalid. The PDPC advisory guidelines emphasise that these two elements -- notification and agreement -- must both be present for consent to be valid under the Singapore PDPA consent framework. The Singapore PDPA does not prescribe a specific format for consent. Written consent or consent recorded in an accessible form provides the strongest evidence and is referred to in the PDPC guidelines as 'express consent.' The PDPC recommends this form wherever practical. Verbal consent is permissible where it is impractical to obtain written Singapore PDPA consent, but the PDPC advises confirming verbal consent in writing afterward or making a written note of the verbal consent as documentary evidence for any future dispute. Organisations should design their Singapore PDPA consent collection processes to capture evidence that can be retrieved and presented during a PDPC investigation. Section 14(2) of the PDPA imposes additional constraints on how Singapore PDPA consent is obtained. An organisation providing a product or service must not require the individual to consent to the collection, use, or disclosure of personal data beyond what is reasonable to provide that product or service. This anti-bundling rule is a critical safeguard: Singapore PDPA consent obtained by tying non-essential data processing to service delivery is not valid consent. The PDPA also prohibits obtaining Singapore PDPA consent through false or misleading information or deceptive practices; consent obtained in violation of these rules is invalid under section 14(3). For marketing purposes, the PDPC has set a higher bar for Singapore PDPA consent. Organisations should obtain express consent through an opt-in method, such as requiring the individual to check an unchecked box. The PDPC does not consider pre-checked opt-out boxes appropriate for marketing consent under the Singapore PDPA consent rules. This standard also applies to clear and unambiguous consent required under the Do Not Call Provisions for sending specified messages to Singapore telephone numbers. When collecting personal data through forms, it is good practice to mark which fields are compulsory and which are optional, and to state the purposes for each field. Organisations may collect personal data for purposes beyond what is reasonable for providing the product or service, but only if the individual's Singapore PDPA consent is obtained separately and is not made a condition of receiving the product or service. - Valid Singapore PDPA consent requires two elements: notification of purposes and the individual's agreement to those purposes (PDPA section 14(1)). Both must be present. - Written or electronically recorded consent provides the strongest evidence of Singapore PDPA consent and should be used wherever practical. - For verbal Singapore PDPA consent, confirm in writing afterward or create a documented record to protect the organisation against disputes and to satisfy PDPC evidence requirements. - Organisations must not bundle Singapore PDPA consent for non-essential purposes as a condition of providing a product or service (section 14(2)(a)). Optional and necessary purposes must be separated. - Singapore PDPA consent obtained through false, misleading, or deceptive information is invalid and cannot be relied upon (section 14(3)). - Marketing consent under the Singapore PDPA should use opt-in mechanisms (unchecked boxes). Pre-checked opt-out boxes are not considered appropriate by the PDPC. - When using forms to collect Singapore PDPA consent, clearly separate compulsory from optional data fields and state the purpose for each category of data collected. - An individual can provide Singapore PDPA consent on behalf of another person where that person is validly acting on behalf of the individual (section 14(4)). ## Singapore PDPA deemed consent by conduct and contractual necessity Sections 15 and 15A of the Singapore PDPA establish three forms of deemed consent. Deemed consent by conduct and deemed consent by contractual necessity are defined in section 15, while deemed consent by notification is defined in section 15A. These Singapore PDPA consent mechanisms address situations where obtaining express consent would be impractical or unnecessary given the context of the data processing. Organisations must document which form of Singapore PDPA deemed consent applies to each data flow and retain that documentation for potential PDPC review. Singapore PDPA deemed consent by conduct applies when an individual voluntarily provides personal data to an organisation. Under section 15(1), the individual is deemed to have consented by the act of providing the data. However, this Singapore PDPA consent extends only to purposes that are objectively obvious and reasonably appropriate from the surrounding circumstances. The PDPC uses a reasonable person standard to assess whether a purpose falls within the scope of deemed consent by conduct. For example, handing a credit card to a cashier constitutes Singapore PDPA deemed consent for processing the payment transaction, but not for enrolling the individual in a marketing program or sharing their details with unrelated third parties. Singapore PDPA deemed consent by contractual necessity under section 15(3) addresses situations where an individual provides personal data to one organisation (A) for a transaction, and it is reasonably necessary for A to disclose that data to another organisation (B) to conclude or perform the transaction. This Singapore PDPA consent mechanism extends downstream through the processing chain. If B must further disclose to organisation C, and that disclosure is reasonably necessary to fulfil the original contract between the individual and A, Singapore PDPA deemed consent by contractual necessity covers that downstream disclosure as well. Where one organisation (A) discloses personal data to another (B) with the individual's deemed consent, the individual is also deemed to have given Singapore PDPA consent to B's collection of that data for the same purpose. Common examples of Singapore PDPA deemed consent by contractual necessity include payment processing chains (the individual provides credit card details to a merchant, which discloses them to its acquiring bank, the card network, and the individual's issuing bank), delivery logistics (an e-commerce platform shares the buyer's address with a courier company), and charitable donation processing (a charity shares donor details with its bank for GIRO deductions and with the tax authority for tax relief). In each case, the disclosure must be reasonably necessary to fulfil the original transaction. Organisations should map their data flows to identify where Singapore PDPA deemed consent by conduct or contractual necessity applies and document the analysis for each data flow. - Singapore PDPA deemed consent by conduct (section 15(1)) applies when an individual voluntarily provides personal data and the purposes are objectively obvious from the circumstances. - The scope of Singapore PDPA deemed consent by conduct is limited to what a reasonable person would consider appropriate. Marketing use of data voluntarily provided for a transaction is generally not covered. - Singapore PDPA deemed consent by contractual necessity (section 15(3)) allows disclosure to third parties where reasonably necessary to conclude or perform a contract between the individual and the primary organisation. - Singapore PDPA deemed consent by contractual necessity extends downstream through the processing chain. If B must disclose to C to fulfil the contract between the individual and A, deemed consent covers that disclosure. - Payment processing, delivery logistics, and GIRO deductions are common scenarios where Singapore PDPA deemed consent by contractual necessity applies. - Where one organisation discloses personal data to another with Singapore PDPA deemed consent, the receiving organisation is also deemed to have consent for collecting that data for the same purpose. - Document every Singapore PDPA deemed consent determination including the triggering action, the purposes covered, the downstream organisations involved, and the reasoning for why the purpose is objectively obvious or contractually necessary. ## Singapore PDPA deemed consent by notification mechanism Singapore PDPA deemed consent by notification under section 15A allows an organisation to collect, use, or disclose personal data for a new purpose if the individual has been notified and has not opted out within a specified period. This Singapore PDPA consent mechanism is particularly useful when an organisation wants to use existing data for secondary purposes that differ from the original collection purpose, and no exception to consent (such as business improvement or research) is available. Organisations considering this mechanism must follow a structured assessment process before issuing any notification. To rely on Singapore PDPA deemed consent by notification, the organisation must satisfy three conditions set out in the PDPC advisory guidelines. First, it must conduct an assessment to determine that the proposed collection, use, or disclosure is not likely to have an adverse effect on the individual. The PDPC's Assessment Checklist for Deemed Consent by Notification (Annex B) provides a structured five-step template for this assessment: Step 1 defines the context and purpose, Step 2 assesses the appropriateness of the notification approach and the reasonableness of the opt-out period, Step 3 evaluates whether there is any likely adverse effect on the individual, Step 4 assesses residual adverse effects after applying mitigating measures, and Step 5 documents the decision outcome. Second, the organisation must take reasonable steps to bring the Singapore PDPA notification to the individual's attention, including the organisation's intention, the purpose, and a reasonable opt-out period and method. Third, the organisation must provide a reasonable period for the individual to opt out before proceeding. The PDPC does not prescribe a specific notification method for Singapore PDPA deemed consent by notification but requires the notification to be adequate and effective. Organisations should consider the usual mode of communication with the individual, whether direct channels such as email, SMS, or push notifications are available, and the number of individuals to be notified. For large populations where direct channels are not effective, mass communication channels such as a dedicated microsite, social media notices, or print media may be appropriate. The PDPC recommends using multiple Singapore PDPA notification channels to increase the likelihood that individuals actually see the notification. The opt-out period must be reasonable given the circumstances: factors include the nature and frequency of interaction with the individual, the communication channels used, and the ease of the opt-out method. There is an important limitation on Singapore PDPA deemed consent by notification: it cannot be used for the purpose of sending direct marketing messages. The Personal Data Protection Regulations 2021 explicitly exclude this purpose. Organisations must obtain express Singapore PDPA consent through opt-in methods for direct marketing. Additionally, if the Annex B assessment finds likely residual adverse effects to the individual after applying mitigating measures, the organisation cannot rely on Singapore PDPA deemed consent by notification and must seek alternative legal bases. The organisation must retain a copy of its assessment throughout the period it relies on this mechanism and provide the assessment to the PDPC on request. However, the organisation is not required to share the assessment with individuals, as it may contain commercially sensitive information. After the opt-out period expires, individuals who did not opt out are deemed to have given Singapore PDPA consent, but they can still withdraw consent at any time under section 16. - Singapore PDPA deemed consent by notification (section 15A) applies when an individual is notified of a new purpose and does not opt out within the specified period. - Three conditions must be met for Singapore PDPA deemed consent by notification: conduct an adverse effect assessment (Annex B), provide adequate notification, and allow a reasonable opt-out period. - Use the PDPC's Annex B Assessment Checklist to structure the assessment: Step 1 defines context and purpose, Step 2 defines notification approach and opt-out period, Step 3 assesses adverse effects, Step 4 evaluates residual effects, and Step 5 records the decision outcome. - Singapore PDPA notification for deemed consent must be adequate and effective. Consider the usual communication mode, availability of direct channels, and population size when choosing notification methods. - The opt-out period for Singapore PDPA deemed consent by notification must be reasonable. Factors include interaction frequency, communication channel effectiveness, and ease of opting out. For monthly push notifications, the opt-out period should not be shorter than one month. - Singapore PDPA deemed consent by notification cannot be used for sending direct marketing messages. Express opt-in Singapore PDPA consent is required for marketing under the Personal Data Protection Regulations 2021. - If residual adverse effects remain after applying mitigating measures, Singapore PDPA deemed consent by notification cannot be relied upon. The organisation must seek an alternative legal basis. - Retain the Annex B assessment for as long as the organisation relies on Singapore PDPA deemed consent by notification. Provide it to the PDPC on request but it need not be shared with individuals. ## Singapore PDPA legitimate interests exception framework The Singapore PDPA legitimate interests exception in paragraph 1 under Part 3 of the First Schedule allows organisations to collect, use, or disclose personal data without Singapore PDPA consent where the identified legitimate interests outweigh any adverse effect on the individual. This is the broadest exception under the Singapore PDPA consent framework because it covers all three data activities -- collection, use, and disclosure -- and can be applied to a wide range of purposes where other specific exceptions do not fit. Organisations that rely on this exception must follow a structured assessment process and maintain documentation that the PDPC can request at any time. To rely on the Singapore PDPA legitimate interests exception, an organisation must follow three steps defined in the PDPC advisory guidelines. First, it must identify and clearly articulate the legitimate interests, specifying the benefits, the beneficiaries, and whether those benefits are real and present rather than purely speculative. Benefits can include tangible outcomes such as increased business efficiency and cost savings, as well as intangible outcomes such as improved customer experience or enhanced security. Beneficiaries may include the organisation itself, other organisations, the wider public, or specific segments such as customers or employees. Second, the organisation must conduct a formal assessment before collecting, using, or disclosing the personal data. The PDPC's Assessment Checklist for the Legitimate Interests Exception (Annex C) provides a structured five-step template: Step 1 defines the context and purpose, Step 2 identifies the benefits, Step 3 assesses adverse effects, Step 4 evaluates residual adverse effects after mitigating measures, and Step 5 conducts the balancing test to determine whether the legitimate interests outweigh the residual adverse effects. Third, the organisation must take reasonable steps to disclose to individuals that it is relying on the Singapore PDPA legitimate interests exception instead of Singapore PDPA consent. This disclosure can be made through the organisation's public data protection policy. The organisation must also provide business contact information for a person who can address individual queries about the reliance on the exception, typically the Data Protection Officer. The organisation does not need to make the Annex C assessment itself available to individuals or the public, but must provide it to the PDPC upon request. The PDPC has emphasised that the balancing test in the Annex C assessment should not be a mere count of whether affirmative responses outnumber negative ones, but rather a substantive evaluation with documented justifications for each response. Common examples of Singapore PDPA legitimate interests include fraud detection and prevention, IT and network security, prevention of misuse of services, corporate due diligence during mergers and acquisitions, and physical security of premises through CCTV. These purposes are often incompatible with Singapore PDPA consent because individuals who intend to engage in fraud or misuse of services would simply withhold consent. The PDPC has endorsed joint assessments where multiple organisations collaborate on a shared legitimate interest, such as hotels sharing a blacklist of guests who repeatedly fail to pay. There is one firm exclusion: organisations cannot rely on the Singapore PDPA legitimate interests exception to send direct marketing messages. Express Singapore PDPA consent is always required for marketing. - The Singapore PDPA legitimate interests exception (paragraph 1, Part 3, First Schedule) allows collection, use, and disclosure of personal data without Singapore PDPA consent when legitimate interests outweigh adverse effects. - Three requirements for the Singapore PDPA legitimate interests exception: identify and articulate the legitimate interests, conduct a formal Annex C assessment including a balancing test, and disclose reliance on the exception to individuals. - Use the PDPC's Annex C Assessment Checklist: Step 1 defines purpose, Step 2 identifies benefits, Step 3 assesses adverse effects, Step 4 evaluates residual effects after mitigation, and Step 5 conducts the balancing test. - Benefits relied upon for the Singapore PDPA legitimate interests exception must be real and present, not purely speculative. Include both tangible benefits (cost savings, efficiency) and intangible benefits (security, customer experience). - The balancing test is not a simple numerical count of affirmative versus negative responses. It requires a substantive evaluation with documented justifications, as the PDPC has emphasised. - Disclose reliance on the Singapore PDPA legitimate interests exception in your public data protection policy and provide DPO contact details for individual queries. - Common legitimate interests under the Singapore PDPA: fraud detection, IT security, prevention of service misuse, corporate due diligence, and physical security via CCTV monitoring. - Joint assessments may be conducted by multiple organisations sharing a Singapore PDPA legitimate interest. Retain all Annex C assessments and provide them to the PDPC on request. - Direct marketing messages cannot rely on the Singapore PDPA legitimate interests exception. Express Singapore PDPA consent is always required for marketing. ## Singapore PDPA business improvement exception The Singapore PDPA business improvement exception under Part 5 of the First Schedule and Division 2 under Part 2 of the Second Schedule enables organisations to use personal data, without Singapore PDPA consent, that they have already collected in accordance with the Data Protection Provisions. This exception recognises that organisations often need to use personal data to improve products, services, and operations in ways that benefit both the organisation and its customers. Unlike the Singapore PDPA legitimate interests exception, the business improvement exception is primarily focused on the use of data rather than its collection or disclosure. The Singapore PDPA business improvement exception covers four categories of purpose: (a) improving, enhancing, or developing new goods or services; (b) improving, enhancing, or developing new methods or processes for business operations; (c) learning or understanding the behaviour and preferences of individuals or groups, including customer segmentation; and (d) identifying goods or services that may be suitable for individuals, or personalising and customising goods or services. Two conditions must be met: the purpose cannot reasonably be achieved without using the data in individually identifiable form, and the use must be one that a reasonable person would consider appropriate in the circumstances. The PDPC's advisory guidelines on selected topics (revised 23 May 2024) provide worked examples demonstrating how these conditions apply in practice, such as a telecommunications provider analysing customer data to improve network quality and a company analysing emergency contact data to identify potential customers for adventure camp services. The Singapore PDPA business improvement exception also extends to the sharing of personal data between entities within a group of related corporations, which the PDPA defines by reference to the Companies Act (Cap. 50). For intra-group sharing, the data must relate to existing or prospective customers of the receiving organisation. Additional conditions apply: the organisations involved must be bound by a contract, agreement, or binding corporate rules requiring the recipient to implement and maintain appropriate safeguards for the personal data. This allows related companies such as a supermarket and a restaurant within the same group to share customer shopping propensity data for product development purposes, provided the safeguard conditions are met. Like the Singapore PDPA legitimate interests exception, the business improvement exception cannot be used to send direct marketing messages without Singapore PDPA consent. However, organisations may use the exception for preparatory marketing activities, such as data analytics and market research to derive insights about existing customers, as long as those activities stop short of actually sending marketing messages to individuals. This distinction between preparatory marketing analytics (permitted without Singapore PDPA consent under the business improvement exception) and actual marketing communication (always requires express Singapore PDPA consent) is important for organisations planning customer engagement strategies. - The Singapore PDPA business improvement exception allows use of previously collected personal data without Singapore PDPA consent for improving products, services, processes, and customer understanding. - Four permitted purposes under the Singapore PDPA business improvement exception: develop new goods or services, improve business operations, learn customer behaviour and preferences, and identify or personalise suitable goods or services. - Two conditions must be met: the purpose cannot reasonably be achieved without individually identifiable data, and the use must be reasonable in the circumstances as assessed by the PDPC. - Intra-group sharing between related corporations is permitted under the Singapore PDPA business improvement exception, but the data must relate to existing or prospective customers of the receiving entity. - Intra-group sharing under the Singapore PDPA business improvement exception requires the recipient to be bound by contract, agreement, or binding corporate rules to maintain appropriate safeguards. - Common use cases under the Singapore PDPA business improvement exception include credit risk modelling, customer segmentation analysis, machine learning model training, network quality improvement, and product development feedback loops. - Direct marketing messages cannot rely on the Singapore PDPA business improvement exception. Express Singapore PDPA consent is always required for marketing. - Preparatory marketing activities such as analytics, segmentation, and market research are permitted under the Singapore PDPA business improvement exception, but the actual sending of marketing messages is not. ## Singapore PDPA purpose limitation and notification obligations The Singapore PDPA purpose limitation obligation under section 18 restricts organisations to collecting, using, and disclosing personal data only for purposes that a reasonable person would consider appropriate in the circumstances and, where applicable, that have been notified to the individual under the Singapore PDPA notification obligation. Together, these two obligations ensure that organisations do not collect more data than needed, do not use data for purposes that go beyond what the individual was informed about, and maintain transparency about how personal data is processed. The reasonableness test under the Singapore PDPA purpose limitation obligation is objective. The PDPC assesses whether a purpose is appropriate by reference to what a reasonable person would consider acceptable given the specific circumstances. A purpose that violates the law or would harm the individual is unlikely to be considered reasonable. Open-ended purpose statements such as 'any other purpose that the organisation deems fit' are not considered reasonable by the PDPC and will not satisfy the Singapore PDPA purpose limitation obligation. The PDPC expects organisations to state their purposes with enough specificity that individuals can understand why their data is being collected and how it will be used, without requiring a listing of every internal processing activity. The Singapore PDPA notification obligation under section 20 requires organisations to inform individuals of the purposes for which their personal data will be collected, used, or disclosed. The Singapore PDPA notification must be given on or before the collection of personal data. If the organisation later wishes to use or disclose data for a purpose not previously notified, it must provide Singapore PDPA notification to the individual before that new use or disclosure begins. The Singapore PDPA notification obligation does not apply where deemed consent applies under sections 15 or 15A, or where the organisation is relying on a consent exception under section 17. Written notifications are best practice because they create a clear record that both parties can reference in a dispute. Good practice for Singapore PDPA notification includes writing in clear and accessible language rather than legal jargon, using a layered notice approach where summary information is presented prominently and detailed information is available on a website or linked document, highlighting purposes that may be unexpected to the individual, and reviewing notification practices regularly for effectiveness. Organisations may use their Data Protection Policy (privacy policy) as one vehicle for Singapore PDPA notification, but should provide the most relevant portions directly to the individual at the point of collection. If an organisation wants to use or disclose personal data for a purpose different from the original collection purpose, it must first determine whether the new purpose falls within the scope of previously notified purposes, whether deemed consent applies, or whether an exception from consent applies. If none of these cover the new purpose, the organisation must obtain fresh Singapore PDPA consent after providing Singapore PDPA notification of the new purpose. - Section 18 of the Singapore PDPA (purpose limitation) restricts data processing to purposes that are reasonable and, where applicable, notified to the individual under the Singapore PDPA notification obligation. - Open-ended purpose statements ('any purpose we deem fit') are not reasonable and do not satisfy the Singapore PDPA purpose limitation obligation. The PDPC expects appropriate specificity. - Section 20 of the Singapore PDPA (notification) requires informing individuals of purposes on or before collecting personal data. New purposes must be notified through the Singapore PDPA notification process before use or disclosure. - The Singapore PDPA notification obligation is not required when deemed consent applies (sections 15 and 15A) or when an exception under section 17 is used. - Written Singapore PDPA notification is best practice. Use a Data Protection Policy for general purposes but provide specific, relevant excerpts at the point of collection. - Adopt layered notices for Singapore PDPA notification: summary of key purposes at the point of transaction, with detailed information available on the organisation's website. - Highlight purposes in your Singapore PDPA notification that may be unexpected to the individual given the context of the transaction. - State purposes in your Singapore PDPA notification with enough specificity for the individual to understand the reasons for data collection. Avoid vague or overly broad language. - Review Singapore PDPA notification practices regularly for effectiveness, clarity, and relevance to current data processing activities. - For new purposes not originally notified, assess whether existing Singapore PDPA consent, deemed consent, or an exception covers the use before seeking fresh consent. ## Singapore PDPA withdrawal of consent process and obligations Section 16 of the Singapore PDPA gives individuals the right to withdraw Singapore PDPA consent at any time, whether that consent was expressly given or deemed. This right applies to any Singapore PDPA consent for the collection, use, or disclosure of personal data for any purpose. Organisations must not prohibit individuals from withdrawing Singapore PDPA consent, even though the withdrawal may trigger legal consequences such as early termination charges under a service contract. The right to withdraw Singapore PDPA consent is a fundamental individual right under the PDPA and organisations must design processes that respect and facilitate it. The withdrawal process under the Singapore PDPA involves specific obligations on both the individual and the organisation. The individual must give reasonable notice of withdrawal to the organisation. On receiving this notice, the organisation must inform the individual of the likely consequences of withdrawing Singapore PDPA consent. The PDPC considers a withdrawal notice of at least ten (10) business days to be reasonable notice. If the organisation requires more time, it should inform the individual of the timeframe by which the withdrawal will take effect. Organisations must design and maintain a clear, easily accessible Singapore PDPA consent withdrawal policy that advises individuals on the form and manner for submitting a withdrawal notice, identifies the person or channel to which the notice should be submitted, and distinguishes between purposes that are necessary for providing the product or service and optional purposes. A critical requirement of the Singapore PDPA consent withdrawal process is that individuals must be able to withdraw Singapore PDPA consent for optional purposes without also withdrawing consent for necessary purposes. Inflexible withdrawal policies that bundle all purposes together or that restrict or prevent withdrawal of Singapore PDPA consent are not compliant with the PDPA. The PDPC has stated that organisations must allow granular withdrawal, enabling individuals to selectively withdraw Singapore PDPA consent for marketing or data sharing while retaining consent for core service delivery. Upon receiving a valid withdrawal notice, the organisation must cease collecting, using, or disclosing the personal data for the specified purpose. It must also instruct its data intermediaries and agents to cease processing for that purpose. However, the organisation is not required to inform other third parties to which it has already disclosed the data; the individual can use an access request to find out which other organisations received the data and approach them separately. Importantly, withdrawal of Singapore PDPA consent does not require the organisation to delete the personal data. The organisation may retain data in its records in accordance with the retention limitation obligation. If the individual later provides fresh Singapore PDPA consent, the organisation may resume collecting, using, or disclosing personal data within the scope of the new consent. When an unsubscribe mechanism such as an email link is used, the scope of the withdrawal is limited to the channel through which the notice was sent unless the individual indicates otherwise. - Section 16 of the Singapore PDPA provides individuals the right to withdraw Singapore PDPA consent at any time for any purpose, whether consent was express or deemed. - Organisations must not prohibit withdrawal of Singapore PDPA consent, though legal consequences (such as early termination charges) arising from withdrawal are not affected by the PDPA. - The individual must give reasonable notice of withdrawal. The PDPC considers ten (10) business days as a reasonable benchmark for processing Singapore PDPA consent withdrawal requests. - On receiving a withdrawal notice, inform the individual of the likely consequences of withdrawing Singapore PDPA consent, even if those consequences are stated elsewhere such as in the service contract. - Design a clear, accessible Singapore PDPA consent withdrawal policy that specifies the form, manner, and recipient for withdrawal notices and distinguishes between necessary and optional purposes. - Allow withdrawal of Singapore PDPA consent for optional purposes without requiring withdrawal of consent for purposes necessary to provide the product or service. Bundled withdrawal policies violate the PDPA. - Upon withdrawal of Singapore PDPA consent, cease data collection, use, or disclosure for the specified purpose and instruct data intermediaries and agents to do the same. - Withdrawal of Singapore PDPA consent does not require deletion of personal data. The organisation may retain data in accordance with the retention limitation obligation. ## Practical Singapore PDPA consent management implementation Building a defensible Singapore PDPA consent management program requires operational artifacts that teams can use across product development, marketing, vendor management, and customer service. The starting point is a purpose register that lists every data processing activity, the corresponding purpose, the Singapore PDPA consent legal basis (express consent, deemed consent type, or exception), the data categories involved, and the disclosure recipients. Each entry should have a change log recording who approved purpose changes and when. This register is the central record that the PDPC will examine during an investigation and it must be kept current as the organisation's data processing activities evolve. For express Singapore PDPA consent, implement a consent log schema that records each consent event with the individual's identifier, the timestamp, the exact text or screen shown to the individual, the version of the consent notice, the channel used, and the individual's response. This evidence trail is critical during PDPC investigations. For Singapore PDPA deemed consent by conduct, document the analysis of why the purposes fall within the scope of what was objectively obvious from the individual's voluntary provision of data. For Singapore PDPA deemed consent by notification, complete the Annex B Assessment Checklist before initiating the notification, record the assessment outcome, the notification method and content, the opt-out period and method, and the date the opt-out period expired. Track which individuals opted out and ensure their data is excluded from the new purpose. For the Singapore PDPA legitimate interests exception, complete the Annex C Assessment Checklist including the five-step process and the balancing test, and update your public data protection policy to disclose reliance on the exception and provide DPO contact details. Integrate Singapore PDPA consent management into your product development lifecycle: before launching a new feature that processes personal data, require the product team to identify the Singapore PDPA consent legal basis and update the purpose register. Run automated checks against the consent log to confirm that Singapore PDPA consent or a valid exception exists before data is processed. Design UI components that present Singapore PDPA consent requests clearly, separate compulsory from optional data fields, and make opt-out and withdrawal easy to execute. Train customer-facing staff and your data protection officer on the Singapore PDPA consent framework. Customer service agents must know how to process Singapore PDPA consent withdrawal requests within the ten business day benchmark, how to inform individuals of consequences, and how to escalate edge cases. Conduct periodic audits of Singapore PDPA consent records to verify completeness and accuracy. Verify that Singapore PDPA consent or a valid exception exists before any data is processed. Review and update your Data Protection Policy at least annually, or whenever you add new data processing purposes. Ensure that your Singapore PDPA notification practices remain effective by testing whether individuals actually see and understand the notifications. - Build a purpose register mapping every data processing activity to its Singapore PDPA consent legal basis, data categories, purposes, and disclosure recipients. Maintain a change log for audit readiness. - Implement a consent log schema capturing event identifier, timestamp, consent text shown, version, channel, and individual response for every Singapore PDPA consent event. - For Singapore PDPA deemed consent by conduct, document why the purpose is objectively obvious and reasonable from the circumstances of the individual's voluntary data provision. - For Singapore PDPA deemed consent by notification, complete the Annex B Assessment Checklist (all five steps) and record notification content, method, opt-out period, expiration date, and opt-out tracking. - For the Singapore PDPA legitimate interests exception, complete the Annex C Assessment Checklist including all five steps and the balancing test. Disclose reliance in the Data Protection Policy. - Require product teams to identify the Singapore PDPA consent legal basis and update the purpose register before launching features that process personal data. - Design UI for Singapore PDPA consent requests with clear language, separation of compulsory and optional fields, and easy opt-out and withdrawal paths. - Train customer service staff and the DPO on the Singapore PDPA consent framework, including the ten business day withdrawal benchmark, consequence notification, and escalation procedures. - Conduct periodic audits of Singapore PDPA consent records for completeness. Verify that consent or a valid exception exists before data is processed. - Review and update the Data Protection Policy at least annually or whenever new processing purposes are introduced. Test that Singapore PDPA notification practices remain effective. ## Common Singapore PDPA consent mistakes and enforcement lessons PDPC enforcement decisions reveal recurring patterns of Singapore PDPA consent non-compliance that organisations should actively avoid. One of the most common failures is bundled Singapore PDPA consent, where organisations require individuals to agree to data processing purposes well beyond what is necessary for the product or service as a condition of providing that product or service. Under section 14(2)(a), this renders the Singapore PDPA consent invalid. The PDPC expects organisations to separate Singapore PDPA consent for core service delivery from consent for optional purposes such as marketing or data sharing with third parties. Vague or overly broad purpose statements are another frequent issue that undermines both the Singapore PDPA notification obligation and the Singapore PDPA purpose limitation obligation. Clauses such as 'we may use your data for any purpose we see fit' or 'for valid business purposes' do not satisfy either obligation. The PDPC requires organisations to state their purposes with enough specificity that individuals can understand why their data is being collected and how it will be processed. At the same time, organisations need not list every single internal processing activity; the goal is an appropriate level of detail that enables meaningful understanding of how personal data will be used. Failure to provide workable Singapore PDPA consent withdrawal mechanisms has also attracted enforcement attention. Organisations that make it unreasonably difficult to withdraw Singapore PDPA consent, require withdrawal of all purposes (including necessary ones) as a package, or fail to process withdrawal requests in a timely manner violate their obligations under section 16. The PDPC expects organisations to provide accessible withdrawal channels and to allow individuals to withdraw Singapore PDPA consent for optional purposes while retaining consent for purposes necessary to deliver the product or service. Organisations should test their withdrawal processes periodically to ensure they remain functional and accessible. Relying on Singapore PDPA deemed consent by notification or the Singapore PDPA legitimate interests exception without conducting and documenting the required assessment is a significant compliance gap. The PDPC can request Annex B or Annex C assessments at any time, and failure to produce them undermines the organisation's position. The assessments should cover all the elements specified in the PDPC's checklists: purpose definition, adverse effect analysis, mitigating measures, residual effect evaluation, and (for legitimate interests) the balancing test. Other common Singapore PDPA consent mistakes include failing to provide Singapore PDPA notification before or at the point of data collection, collecting personal data from third-party sources without conducting due diligence on whether the third party obtained valid Singapore PDPA consent, using opt-out methods for marketing consent instead of opt-in, and not informing individuals of the consequences of Singapore PDPA consent withdrawal. - Bundled Singapore PDPA consent that ties non-essential processing to product or service delivery is invalid under section 14(2)(a). Separate optional from necessary consent. - Vague purpose statements ('any purpose we deem fit') do not satisfy the Singapore PDPA notification or purpose limitation obligations. State purposes with appropriate specificity. - Singapore PDPA consent withdrawal mechanisms must be accessible and allow withdrawal of optional purposes without withdrawing consent for necessary purposes. - Always complete and document the required Annex B or Annex C assessment before relying on Singapore PDPA deemed consent by notification or the legitimate interests exception. - Assessments must cover purpose definition, adverse effects, mitigating measures, residual effects, and (for the Singapore PDPA legitimate interests exception) the balancing test. - Provide Singapore PDPA notification to individuals before or at the point of data collection. Failure to provide timely notification is a standalone violation of section 20. - When collecting data from third-party sources, conduct due diligence to verify that the third party obtained valid Singapore PDPA consent or has a lawful basis for disclosure. - Use opt-in (unchecked box) methods for marketing Singapore PDPA consent. Pre-checked opt-out boxes are not considered appropriate by the PDPC. - Always inform individuals of the consequences of Singapore PDPA consent withdrawal, even if those consequences are already stated in the service contract. - Use the PDPC's advisory guidelines and Annex B and C checklists as operational templates. Build Singapore PDPA consent compliance checks into product development and vendor management processes. *Recommended next step* *Placement: after the scope or definition section* ## Use Singapore PDPA Consent, Notification, and Purpose Limitation as a cited research workflow Research Copilot can take Singapore PDPA Consent, Notification, and Purpose Limitation from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on Singapore PDPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Singapore PDPA Consent, Notification, and Purpose Limitation](/solutions/research-copilot.md): Start from Singapore PDPA Consent, Notification, and Purpose Limitation and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Singapore PDPA](/contact.md): Review your current process, evidence gaps, and next steps for Singapore PDPA Consent, Notification, and Purpose Limitation. ## Primary sources - [Personal Data Protection Act 2012 (Singapore) - official text](https://sso.agc.gov.sg/Act/PDPA2012?ref=sorena.io) - Primary legislation governing collection, use, disclosure, protection, retention, transfer, and accountability for personal data in Singapore. Contains the statutory provisions for Singapore PDPA consent (sections 13-17), purpose limitation (section 18), and notification (section 20). - [PDPC Advisory Guidelines on Key Concepts in the PDPA (revised 16 May 2022)](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-the-personal-data-protection-act?ref=sorena.io) - Core interpretation guidance for Singapore PDPA consent, purposes, notification, access/correction, accuracy, protection, retention, transfers, and accountability. Includes Annex A (consent framework flowchart), Annex B (deemed consent by notification checklist), and Annex C (legitimate interests checklist). - [PDPC Advisory Guidelines on the PDPA for Selected Topics (revised 23 May 2024)](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-selected-topics?ref=sorena.io) - Guidance on applying Singapore PDPA consent obligations to specific scenarios including analytics, research, anonymisation, photography, CCTVs, employment, online activities, minors, and cloud services. Includes worked examples of the business improvement and research exceptions. - [PDPC Advisory Guidelines on Enforcement of Data Protection Provisions](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-enforcement-of-data-protection-provisions?ref=sorena.io) - Enforcement approach, directions, financial penalties, and undertakings related to Singapore PDPA consent and notification violations. - [PDPC - PDPA overview](https://www.pdpc.gov.sg/overview-of-pdpa/pdpa-overview?ref=sorena.io) - Official PDPC overview of Singapore PDPA obligations, key concepts, and updates to the consent and notification framework. ## Related Topic Guides - [Singapore PDPA Applicability Test | Does the PDPA Apply to Your Organisation?](/artifacts/apac/singapore-pdpa/applicability-test.md): Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation. - [Singapore PDPA Breach Notification Playbook - Complete Guide](/artifacts/apac/singapore-pdpa/breach-notification-playbook.md): Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline. - [Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026)](/artifacts/apac/singapore-pdpa/checklist.md): Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules. - [Singapore PDPA Compliance Deadlines and Calendar](/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar.md): Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows. - [Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM](/artifacts/apac/singapore-pdpa/compliance.md): Complete Singapore PDPA compliance guide for organisations. - [Singapore PDPA Cross-Border Transfer Rules | Section 26 Data Transfer Compliance](/artifacts/apac/singapore-pdpa/cross-border-transfers.md): Complete guide to Singapore PDPA cross-border transfer compliance under Section 26. - [Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide](/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages.md): Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses. - [Singapore PDPA FAQ | Frequently Asked Questions on Personal Data Protection Act Compliance](/artifacts/apac/singapore-pdpa/faq.md): Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements. - [Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions](/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases.md): Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover. - [Singapore PDPA Penalties and Fines | SGD 1M or 10% Turnover Cap + PDPC Enforcement Guide](/artifacts/apac/singapore-pdpa/penalties-and-fines.md): Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions. - [Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide](/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template.md): Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions. - [Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC)](/artifacts/apac/singapore-pdpa/requirements.md): Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18). - [Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations](/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries.md): Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion. - [Singapore PDPA Vendor Outsourcing and Contracts Guide](/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts.md): Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence. - [Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties](/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr.md): Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/singapore-pdpa/consent-notification-and-purposes --- --- title: "Singapore PDPA Cross-Border Transfer Rules" canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/cross-border-transfers" source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/cross-border-transfers" author: "Sorena AI" description: "Complete guide to Singapore PDPA cross-border transfer compliance under Section 26." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Singapore PDPA cross-border transfer" - "Singapore PDPA data transfer" - "PDPA Transfer Limitation Obligation" - "Section 26 PDPA" - "Singapore cross border data transfer compliance" - "ASEAN Model Contractual Clauses Singapore" - "ASEAN MCCs PDPA" - "APEC CBPR Singapore" - "APEC PRP certification Singapore" - "binding corporate rules Singapore PDPA" - "PDPA comparable standard of protection" - "PDPA consent-based transfer" - "PDPC transfer guidance" - "PDPA vendor transfer compliance" - "cloud vendor PDPA transfer" - "SaaS PDPA compliance Singapore" - "PDPA transfer impact assessment" - "cross-border transfer register PDPA" - "EU SCC ASEAN MCC interoperability" - "Joint Guide ASEAN MCC EU SCC" - "PDPA data intermediary transfer" - "PDPA transfer record-keeping" - "Singapore data protection international transfer" - "PDPA contractual clauses template" - "PDPA transfer limitation examples" - "Personal Data Protection Regulations 2021 transfer" - "PDPA overseas data processing" - "Singapore PDPA data transfer requirements" - "Singapore PDPA cross-border data transfer rules" - "PDPA Section 26 overseas transfer" - "Singapore personal data transfer overseas" - "Personal Data Protection Act" - "Transfer Limitation Obligation" - "ASEAN Model Contractual Clauses" - "APEC PRP certification" - "binding corporate rules PDPA" - "PDPC transfer guidelines" - "Singapore data protection" - "APAC privacy compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Singapore PDPA Cross-Border Transfer Rules Complete guide to Singapore PDPA cross-border transfer compliance under Section 26. *Artifact Guide* *APAC* ## Singapore PDPA Cross-Border Data Transfers Complete compliance guide for Singapore PDPA cross-border transfer obligations under Section 26. Every approved Singapore PDPA data transfer mechanism explained, from ASEAN MCCs and APEC CBPR certification to binding corporate rules and consent-based alternatives. Practical, enforceable guidance you can demonstrate to the PDPC -- not one-time contract clauses, but repeatable, auditable Singapore PDPA data transfer processes. This page is a comprehensive implementation guide to the Singapore PDPA cross-border transfer rules under the Transfer Limitation Obligation. It is written for legal, compliance, product, and operations teams who need to transfer personal data outside Singapore in a repeatable, auditable manner. The guide covers every Singapore PDPA data transfer mechanism recognised by the Personal Data Protection Commission (PDPC), including ASEAN Model Contractual Clauses, APEC Cross-Border Privacy Rules, binding corporate rules, and consent-based alternatives specified in the Personal Data Protection Regulations 2021. Whether you are engaging an overseas cloud vendor, sharing customer data with a group company, or transferring personal data to an ASEAN or EU partner, this guide walks you through the legal requirements, practical implementation steps, and record-keeping obligations for each Singapore PDPA cross-border transfer scenario. Use the PDPA statute, the Personal Data Protection Regulations 2021, and the PDPC advisory guidelines linked in the sources section below, and tailor the details to your specific processing context. ## Singapore PDPA Cross-Border Transfer Obligation Under Section 26 Section 26(1) of the Singapore PDPA prohibits an organisation from transferring personal data to a country or territory outside Singapore unless the transfer complies with the requirements prescribed under the Act. This core Singapore PDPA cross-border transfer rule is known as the Transfer Limitation Obligation. It triggers whenever an organisation relinquishes possession or direct control of personal data by sending it to another organisation overseas -- whether the recipient is a group company, a client, a data intermediary, or any other overseas entity. Every Singapore PDPA data transfer to an overseas recipient must satisfy at least one of the prescribed conditions before the transfer takes place. The Transfer Limitation Obligation is a direct extension of the Accountability Obligation under PDPA sections 11 and 12. When both the sender and the receiver operate inside Singapore, the PDPA governs both parties. When the receiver is outside Singapore, the receiver is not directly subject to the PDPA. Section 26 therefore requires the transferring organisation to take steps to ensure the overseas recipient will protect the data to a standard comparable to what the PDPA requires. The PDPC Advisory Guidelines on Key Concepts (Chapter 19) state: 'the Accountability Obligation requires that the transferring organisation takes steps to ensure that the recipient organisation will continue to protect the personal data that it has received to a standard that is comparable to that established in PDPA.' The Personal Data Protection Regulations 2021 list several conditions under which an organisation may lawfully complete a Singapore PDPA cross-border transfer. These conditions fall into two broad categories: (a) ensuring the recipient is bound by legally enforceable obligations or specified certifications, and (b) relying on alternative grounds such as individual consent, contractual necessity, vital interests, data in transit, or publicly available data. The PDPC recommends that organisations rely on legally enforceable obligations or certifications as the primary mechanism for any Singapore PDPA data transfer, and treat the alternative grounds as fallback options. If an organisation retains direct possession or control of personal data while it is overseas -- for example, an employee travelling with a laptop containing customer data, or data stored on the organisation's own servers in a foreign data centre -- the full set of Data Protection Provisions applies directly. The Singapore PDPA cross-border transfer rules under Section 26 specifically address the scenario where the organisation relinquishes control to a separate overseas entity. Failure to comply with the Transfer Limitation Obligation can lead to PDPC enforcement directions and financial penalties. - Section 26(1) PDPA: organisations must not transfer personal data outside Singapore except in accordance with prescribed requirements. This is the foundation of every Singapore PDPA cross-border transfer. - The Singapore PDPA data transfer obligation triggers whenever the organisation relinquishes possession or direct control of personal data to an overseas recipient. - Transfers to group companies for centralised functions (e.g. HR, payroll, CRM) are in scope and require a recognised Singapore PDPA cross-border transfer mechanism. - Transfers to overseas data intermediaries (processors) are in scope and must be covered by legally enforceable obligations under the Singapore PDPA data transfer rules. - The PDPC views the Transfer Limitation Obligation as a manifestation of the Accountability Obligation (PDPA sections 11 and 12). - Where the organisation retains direct control of overseas data (e.g. its own foreign servers or employee laptops), the full Data Protection Provisions apply instead of the Singapore PDPA cross-border transfer rules. - The Personal Data Protection Regulations 2021 prescribe the specific conditions under which a Singapore PDPA data transfer to an overseas recipient is lawful. - Failure to comply with Section 26 can lead to PDPC enforcement directions, financial penalties, and reputational damage. ## Singapore PDPA Comparable Standard of Protection for Data Transfers The core principle behind every Singapore PDPA cross-border transfer is that personal data transferred overseas must continue to receive a standard of protection comparable to the protection under the PDPA. This does not mean the overseas country must have an identical data protection law. It means the overseas recipient must be bound -- through legally enforceable obligations or certifications -- to treat the transferred data in a manner that provides equivalent safeguards across the key Data Protection Provisions. The comparable protection requirement applies regardless of which Singapore PDPA data transfer mechanism the organisation selects. The PDPC Advisory Guidelines on Key Concepts (Chapter 19, paragraph 19.9) set out the minimum areas of protection that contractual clauses must cover to satisfy the Singapore PDPA cross-border transfer comparable protection requirement. For transfers to a recipient acting as an organisation (not a data intermediary), the clauses must address: (1) purpose of collection, use and disclosure, (2) accuracy, (3) protection (security), (4) retention limitation, (5) policies on personal data protection, (6) access, (7) correction, and (8) data breach notification. For transfers to a data intermediary, the clauses must at minimum cover: (1) protection, (2) retention limitation, and (3) data breach notification. The comparable protection assessment for a Singapore PDPA data transfer focuses on the specific obligations imposed on the recipient, not on the overall legal regime of the destination country. This means an organisation can transfer data to a country without a comprehensive data protection law if the contractual or certification-based obligations on the recipient are sufficient to provide PDPA-comparable safeguards. The PDPC Advisory Guidelines confirm that the transferring organisation should be able to demonstrate how the obligations binding the specific recipient compare to the PDPA's requirements. Data breach notification clauses deserve special attention in any Singapore PDPA cross-border transfer arrangement. Under Part 6A of the PDPA, data intermediaries must notify the organisation without undue delay when they have credible grounds to believe a breach has occurred. Organisations must then assess whether the breach is notifiable and notify the PDPC within three calendar days of making that determination. When setting up contractual clauses for a Singapore PDPA data transfer, the organisation should specify these notification time frames explicitly and allocate responsibility for contacting affected individuals. - Comparable protection means equivalent safeguards to the PDPA's Data Protection Provisions, not an identical data protection law in the destination country. This is the standard for every Singapore PDPA cross-border transfer. - For organisation recipients: contractual clauses supporting a Singapore PDPA data transfer must cover purpose limitation, accuracy, protection, retention, policies, access, correction, and data breach notification. - For data intermediary recipients: contractual clauses must at minimum cover protection, retention limitation, and data breach notification under the Singapore PDPA cross-border transfer rules. - Data breach notification clauses should require data intermediaries to notify the organisation without undue delay, and require the organisation to notify the PDPC within three calendar days of determining a breach is notifiable. - The comparable protection assessment for a Singapore PDPA data transfer focuses on the obligations binding the specific recipient, not the overall legal framework of the destination country. - Organisations must document their assessment of how the recipient's obligations compare to the PDPA's requirements for each Singapore PDPA cross-border transfer. - For data intermediary relationships, the PDPC expects the processing contract to impose obligations covering protection, retention, and breach notification even though the PDPA does not directly impose all Data Protection Provisions on intermediaries. - Include clauses allocating responsibility for contacting individuals affected by data breaches, as recommended in the PDPC Singapore guidance for use of ASEAN MCCs. ## ASEAN Model Contractual Clauses for Singapore PDPA Cross-Border Transfers The ASEAN Model Contractual Clauses (ASEAN MCCs) were approved on 22 January 2021 at the 1st ASEAN Digital Ministers' Meeting (ADGMIN). They were developed by the Working Group on Digital Data Governance, chaired by Singapore. The ASEAN MCCs are template contractual terms that set out baseline responsibilities, required personal data protection measures, and related obligations of the parties. They are based on the principles of the ASEAN Framework on Personal Data Protection (2016). The PDPC recognises and encourages the use of the ASEAN MCCs to fulfil the Singapore PDPA cross-border transfer obligation. The MCCs can also be used for transfers to countries with data protection regimes based on the APEC Privacy Framework or the OECD Privacy Guidelines, because the principles in the ASEAN Framework are aligned with those international frameworks. The ASEAN MCCs adopt a modular approach with two modules: Module 1 for controller-to-processor transfers, and Module 2 for controller-to-controller transfers. Parties should select the module that matches their Singapore PDPA data transfer scenario and delete the irrelevant module. Businesses may adapt the clauses for transfers between organisations within Singapore or to countries outside ASEAN. The MCCs are voluntary, and organisations may continue using their own preferred contractual templates for Singapore PDPA cross-border transfers, provided those templates comply with the PDPA's requirements. When using the ASEAN MCCs for a Singapore PDPA cross-border transfer, the PDPC recommends specific clarifications and amendments as set out in the PDPC Guidance for Use of ASEAN MCCs (published 22 January 2021). First, parties may wish to specify that the definition of 'data subject' includes persons living or deceased, because the PDPA covers data of deceased individuals under Section 4(4). Second, parties should specify a time frame for notifying each other of data breaches: data intermediaries must notify the organisation without undue delay, and organisations must notify the PDPC as soon as practicable but no later than three calendar days. Third, parties should include clauses allocating responsibility for contacting individuals affected by data breaches. The PDPC guidance also clarifies that the Addendum of Additional Terms to the ASEAN MCCs is not required under the PDPA. Parties may modify the MCCs in accordance with the ASEAN Framework principles or as required by ASEAN Member State law, and may add clauses appropriate for their commercial arrangements. However, any amendments to the ASEAN MCCs and any added clauses must not contradict or nullify the core data protection obligations set out in the MCCs. For organisations conducting their first Singapore PDPA data transfer to an ASEAN partner, the ASEAN MCCs provide the most straightforward, regulator-endorsed contractual framework. - The ASEAN MCCs were approved on 22 January 2021 and are based on the ASEAN Framework on Personal Data Protection (2016). The PDPC recognises them as a valid mechanism for Singapore PDPA cross-border transfers. - Module 1 covers controller-to-processor Singapore PDPA data transfers; Module 2 covers controller-to-controller Singapore PDPA data transfers. - For Singapore PDPA cross-border transfer use, specify that 'data subject' includes living and deceased persons (PDPA Section 4(4)). - Include data breach notification time frames: data intermediary notifies organisation without undue delay; organisation notifies PDPC within three calendar days of determining a breach is notifiable. - Parties may also include clauses allocating responsibility for contacting individuals affected by data breaches, as recommended by the PDPC for Singapore PDPA data transfers. - The ASEAN MCCs Addendum of Additional Terms is not required under the PDPA for Singapore PDPA cross-border transfers. - Parties may modify the MCCs within the ASEAN Framework principles, but must not contradict or nullify the core data protection obligations. - The ASEAN MCCs are voluntary. Organisations may use their own compliant contractual templates for Singapore PDPA data transfers instead. ## APEC CBPR and PRP Certifications for Singapore PDPA Data Transfers The Asia Pacific Economic Cooperation Cross Border Privacy Rules (APEC CBPR) system and the APEC Privacy Recognition for Processors (APEC PRP) system are recognised under the Personal Data Protection Regulations 2021 as 'specified certifications' for the purpose of Singapore PDPA cross-border transfers. When an overseas recipient holds one of these certifications, the transferring organisation is taken to have satisfied the Transfer Limitation Obligation without needing to impose additional contractual obligations. This makes APEC certification one of the most streamlined paths for Singapore PDPA data transfer compliance. Which certification satisfies the Singapore PDPA cross-border transfer obligation depends on the role of the recipient. If the recipient is receiving personal data as an organisation (i.e. as a controller that determines the purposes of processing), a valid APEC CBPR certification is sufficient. If the recipient is receiving personal data as a data intermediary (processor), a valid APEC PRP certification or a valid APEC CBPR certification, or both, will satisfy the obligation. Critically, if the recipient is an organisation (not a data intermediary) and holds only an APEC PRP certification but not a CBPR certification, the PRP certification alone does not satisfy the Transfer Limitation Obligation for that Singapore PDPA data transfer. The PDPC recommends that transferring organisations carry out due diligence to verify the recipient's certification status before relying on the certification for a Singapore PDPA cross-border transfer. The PDPC Advisory Guidelines (Chapter 19) specifically direct organisations to confirm APEC CBPR and PRP certifications by checking the list of certified organisations on the APEC website (www.cbprs.org). The PDPC has also published a recommended sample clause for contracts with APEC CBPR or PRP certified recipients. The clause states that the certified party is bound by a legally enforceable set of obligations providing comparable protection to the PDPA, and that the receiving party must maintain its certification during the agreement term and promptly notify the disclosing party of any change in certification status. For organisations that deal with multiple overseas recipients, APEC CBPR and PRP certifications offer a scalable approach to Singapore PDPA data transfer compliance. The certifications are assessed by an approved accountability agent and enforced by the relevant national privacy enforcement authority. This multi-layered enforcement model gives the PDPC confidence in the comparable standard of protection. APEC CBPR covers all nine APEC Privacy Framework principles -- accountability, preventing harm, notice, collection limitation, use limitation, choice, integrity, security, and access/correction -- providing broad alignment with the PDPA's Data Protection Provisions. - APEC CBPR and APEC PRP are 'specified certifications' under the Personal Data Protection Regulations 2021 for Singapore PDPA cross-border transfers. - Organisation (controller) recipients: a valid APEC CBPR certification satisfies the Singapore PDPA data transfer obligation. - Data intermediary (processor) recipients: a valid APEC PRP or CBPR certification satisfies the Singapore PDPA cross-border transfer obligation. - Organisation recipients with only APEC PRP (no CBPR) do not satisfy the Singapore PDPA data transfer obligation for non-intermediary transfers. - Verify certifications by checking the APEC website (www.cbprs.org) before relying on the certification for any Singapore PDPA cross-border transfer. - Include the PDPC sample clause requiring the recipient to maintain certification and notify the sender of any certification status change. - APEC CBPR covers all nine APEC Privacy Framework principles: accountability, preventing harm, notice, collection limitation, use limitation, choice, integrity, security, and access/correction. - APEC PRP focuses on the obligations of data processors (intermediaries), including security, data integrity, and controls on onward Singapore PDPA data transfers. ## Binding Corporate Rules for Singapore PDPA Group-Level Data Transfers Binding corporate rules (BCRs) are an approved mechanism under the Personal Data Protection Regulations 2021 for Singapore PDPA cross-border transfers between related organisations within a corporate group. BCRs are particularly useful for multinational companies that need to transfer personal data regularly between group entities for centralised functions such as human resources, payroll, finance, customer relationship management, and IT support. Under the Regulations, BCRs must meet three conditions to support a lawful Singapore PDPA data transfer. First, the binding corporate rules must require every recipient of the transferred personal data to provide a standard of protection comparable to the PDPA. Second, the BCRs must specify the recipients to which they apply and the countries and territories to which the personal data may be transferred. Third, the BCRs must specify the rights and obligations they provide. The recipient must be related to the transferring organisation -- meaning either the recipient controls the transferring organisation, the transferring organisation controls the recipient, or both are under the control of a common person. These requirements ensure that every Singapore PDPA cross-border transfer within the corporate group is traceable and enforceable. Unlike the EU GDPR approach, the Singapore PDPA does not require organisations to submit BCRs for approval by the PDPC before relying on them for a Singapore PDPA data transfer. Organisations are responsible for self-assessing whether their BCRs meet the requirements of the Regulations. However, organisations should retain documentation of their BCR assessment and be prepared to demonstrate compliance if the PDPC requests it during an audit or investigation. This self-assessment model gives organisations flexibility but also places the full burden of demonstrating compliance on the transferring entity. Organisations that already have EU-style BCRs in place may be able to leverage those to satisfy the Singapore PDPA cross-border transfer obligation, provided they review the BCRs against the specific PDPA requirements. Key areas to verify include coverage of deceased individuals' data under Section 4(4), alignment of data breach notification time frames with the PDPA's three-calendar-day requirement, and coverage of all eight areas of protection listed in the PDPC's Chapter 19 guidance (purpose, accuracy, protection, retention, policies, access, correction, and breach notification). Adapting existing EU BCRs for Singapore PDPA data transfer compliance can significantly reduce implementation time for multinational organisations. - BCRs apply to Singapore PDPA cross-border transfers between related organisations (parent-subsidiary, common control) within a corporate group. - BCRs must require comparable PDPA-level protection from every recipient and specify which recipients and countries are covered for each Singapore PDPA data transfer. - BCRs must specify the rights and obligations they provide, including protections across purpose limitation, accuracy, protection, retention, policies, access, correction, and breach notification. - No pre-approval from the PDPC is required for BCRs supporting Singapore PDPA cross-border transfers. Organisations self-assess and document their compliance. - The 'related organisation' test requires a control relationship: the recipient controls the transferring organisation, the transferring organisation controls the recipient, or a common person controls both. - Organisations with existing EU-style BCRs should cross-check them against Singapore PDPA data transfer requirements, including coverage of deceased persons' data and the three-calendar-day breach notification time frame. - Maintain a register of group entities covered by the BCRs and the personal data categories transferred under each Singapore PDPA cross-border transfer arrangement. ## Consent-Based Singapore PDPA Cross-Border Transfers and Alternative Grounds The Personal Data Protection Regulations 2021 provide several alternative grounds for Singapore PDPA cross-border transfers that do not require the recipient to be bound by legally enforceable obligations or certifications. The PDPC recommends that these alternative grounds be treated as fallback options. Organisations should rely on enforceable obligations or certifications as the primary mechanism for any Singapore PDPA data transfer, because those approaches provide better accountability and stronger protections for individuals. The PDPC Advisory Guidelines (Chapter 19, paragraph 19.7) state that organisations are 'encouraged to rely on these circumstances only if they are unable to rely on legally enforceable obligations or specified certifications.' The most common alternative ground for a Singapore PDPA cross-border transfer is individual consent. An organisation may transfer personal data overseas if the individual gives consent after being informed about how the personal data will be protected in the destination country. To rely on this ground, the organisation must provide the individual with a reasonable summary in writing of the extent to which the personal data will be protected to a standard comparable to the PDPA in the countries to which it will be transferred. This written-summary requirement makes consent-based Singapore PDPA data transfers more operationally demanding than contract-based or certification-based approaches. A second alternative for a Singapore PDPA cross-border transfer is deemed consent for contractual necessity. An individual is deemed to have consented to the transfer if the transfer is reasonably necessary for the conclusion or performance of a contract between the organisation and the individual. The PDPC Advisory Guidelines illustrate this with the example of a travel agency transferring a customer's passport and booking details to an overseas hotel to fulfil a travel package. The transfer must be directly related to the contract's performance -- the Singapore PDPA data transfer must be genuinely necessary for the contractual obligation, not merely convenient. Additional alternative grounds for Singapore PDPA cross-border transfers include: transfers necessary to respond to an emergency threatening life, health, or safety (vital interests); transfers necessary for a use or disclosure in the national interest; personal data in transit through Singapore without being accessed or used beyond transportation purposes; and personal data that is publicly available in Singapore at the time of transfer. For vital interest and national interest Singapore PDPA data transfers, the transferring organisation must take reasonable steps to ensure the recipient will not use or disclose the personal data for any other purpose. Organisations should always document which alternative ground they relied upon and retain that documentation in their transfer register. - The PDPC recommends enforceable obligations and certifications as the primary Singapore PDPA cross-border transfer mechanism. Alternative grounds are fallback options only. - Consent-based Singapore PDPA data transfers: the individual must be informed in writing about how data will be protected in the destination country before giving consent. - Deemed consent for contractual necessity: the Singapore PDPA cross-border transfer must be reasonably necessary for the conclusion or performance of a contract between the organisation and the individual. - Vital interests: Singapore PDPA data transfers necessary to respond to emergencies threatening life, health, or safety. Reasonable steps must be taken to prevent misuse. - National interest: Singapore PDPA cross-border transfers necessary for a use or disclosure in the national interest. Reasonable steps must prevent use for other purposes. - Data in transit: personal data passing through Singapore servers en route to another country, without being accessed or used in Singapore beyond transportation purposes. - Publicly available data: personal data that is publicly available in Singapore at the time of the Singapore PDPA data transfer. - Document the alternative ground relied upon, the justification, and any written summaries provided to individuals for each Singapore PDPA cross-border transfer. ## Joint Guide on ASEAN MCCs and EU SCCs for Singapore PDPA Data Transfer Interoperability The Joint Guide to ASEAN Model Contractual Clauses and EU Standard Contractual Clauses was endorsed at the 3rd ASEAN Digital Ministers' Meeting (ADGMIN) in February 2023, published in May 2023, and updated on 31 January 2024. It was developed by ASEAN and the European Commission to help businesses operating across both regions understand the similarities and differences between the two sets of contractual clauses, and to facilitate compliance with both Singapore PDPA cross-border transfer requirements and EU GDPR Chapter V requirements in a single contractual arrangement. The Joint Guide consists of two parts. The Reference Guide (Part 1) compares the ASEAN MCCs and EU SCCs across key areas including entering into the clauses, interpretation, definitions, data protection safeguards (lawfulness, purpose limitation, accuracy, data minimisation, security, retention, and breach notification), and obligations for both controller-to-controller and controller-to-processor transfers. The Implementation Guide (Part 2) provides non-exhaustive examples of best practices for operationalising the safeguards required under both sets of clauses. For organisations that need to satisfy both Singapore PDPA data transfer requirements and GDPR requirements, the Joint Guide is the authoritative reference. The ASEAN MCCs and EU SCCs share a high degree of convergence in their definitions and core requirements. Key differences relevant to Singapore PDPA cross-border transfers include: the modular structure (ASEAN MCCs have two modules -- controller-to-processor and controller-to-controller; EU SCCs have four modules including processor-to-processor and processor-to-controller); the flexibility to modify the clauses (ASEAN MCCs can be varied within the ASEAN Framework principles; EU SCCs may not be altered beyond module selection and appendix completion); and the governing law clause (ASEAN MCCs allow parties to select applicable law; EU SCCs require the law of an EU Member State). Organisations that already use EU SCCs for GDPR transfers can use the Joint Guide to identify which additional measures or contractual terms are needed to satisfy the Singapore PDPA cross-border transfer obligation when transferring data from Singapore. Conversely, ASEAN-based companies receiving data from EU partners can use the Joint Guide to understand what additional requirements the EU SCCs impose beyond the ASEAN MCCs. For organisations routing Singapore PDPA data transfers through the EU or receiving EU data into Singapore, a combined ASEAN MCC and EU SCC contractual arrangement is the most efficient approach to dual compliance. - The Joint Guide was endorsed at the 3rd ASEAN Digital Ministers' Meeting (ADGMIN) in February 2023, published May 2023, and updated on 31 January 2024. - Part 1 (Reference Guide): side-by-side comparison of ASEAN MCCs and EU SCCs across definitions, safeguards, and obligations relevant to Singapore PDPA cross-border transfers. - Part 2 (Implementation Guide): best-practice examples for operationalising both sets of clauses for Singapore PDPA data transfer and GDPR compliance. - ASEAN MCCs have two modules (controller-to-processor and controller-to-controller); EU SCCs have four modules (including processor-to-processor and processor-to-controller). - ASEAN MCCs may be varied within the ASEAN Framework principles; EU SCCs may not be altered beyond module selection and appendix completion. - Both sets of clauses require an appendix describing the parties, data categories, purposes, and transfer details for each Singapore PDPA cross-border transfer. - Organisations transferring data between Singapore and the EU should consider using both MCCs and SCCs in a combined contractual arrangement for dual compliance. - The Joint Guide helps EU-based companies understand Singapore PDPA data transfer requirements and helps Singapore-based companies understand EU SCC requirements. ## Singapore PDPA Cross-Border Transfer Impact Assessment Steps Before completing any Singapore PDPA cross-border transfer, organisations should conduct a structured transfer impact assessment to verify that the chosen transfer mechanism provides comparable protection. While the PDPA does not prescribe a specific transfer impact assessment format, conducting one is a best practice that supports the Accountability Obligation under PDPA sections 11 and 12 and demonstrates defensible compliance to the PDPC. A documented transfer impact assessment is the strongest evidence an organisation can present to prove it has taken the Singapore PDPA data transfer obligation seriously. A practical Singapore PDPA cross-border transfer impact assessment should begin with mapping the transfer. Identify the categories of personal data being transferred, the purposes of the transfer, the identity and location of the overseas recipient, and whether the recipient is acting as an organisation or a data intermediary. Determine whether the Singapore PDPA data transfer is one-time or ongoing, and whether the recipient will make onward transfers to additional parties or countries. This mapping forms the foundation for selecting and documenting the appropriate transfer mechanism under the Singapore PDPA cross-border transfer rules. Next, select and assess the transfer mechanism. For each Singapore PDPA data transfer, determine which of the recognised grounds applies: legally enforceable obligations under contract, binding corporate rules, specified certifications (APEC CBPR or PRP), individual consent, deemed consent for contractual necessity, vital interests, national interest, data in transit, or publicly available data. Document why the chosen mechanism is appropriate and how it provides comparable protection across the relevant Data Protection Provisions. The assessment should specifically address each of the eight areas of protection listed in the PDPC Chapter 19 guidance. Finally, evaluate the recipient's ability to honour the obligations in practice. Review the recipient's data protection policies, security certifications (such as ISO 27001 or SOC 2 Type II), sub-processor arrangements, and track record with the relevant enforcement authority. For certification-based Singapore PDPA cross-border transfers, verify the certification status on the APEC website (www.cbprs.org). For contract-based Singapore PDPA data transfers, confirm that the clauses cover all required areas of protection. Record the assessment outcome, the date of the assessment, and the next review date. Repeat the assessment periodically and whenever there is a material change in the transfer arrangement -- such as a new sub-processor, a change in data processing location, or a certification lapse. - Step 1 - Map the Singapore PDPA cross-border transfer: identify data categories, purposes, recipient identity and location, recipient role (organisation or data intermediary), and onward transfer chains. - Step 2 - Select the transfer mechanism: choose from enforceable obligations, BCRs, APEC CBPR/PRP, consent, contractual necessity, vital interests, national interest, data in transit, or publicly available data. - Step 3 - Assess comparable protection: verify that the mechanism covers all eight areas of protection required by the PDPC (purpose, accuracy, protection, retention, policies, access, correction, breach notification). - Step 4 - Evaluate the recipient: review security certifications, data protection policies, sub-processor governance, and enforcement track record relevant to the Singapore PDPA data transfer. - Step 5 - Document the assessment: record the Singapore PDPA cross-border transfer details, mechanism chosen, justification, assessment date, and next review date. - Step 6 - Review periodically: reassess whenever there is a material change (new sub-processor, new country, policy change, certification lapse) or at a defined interval (e.g. annually). - Maintain transfer impact assessments in a central register alongside the organisation's data protection management programme documentation. ## Cloud and SaaS Vendor Compliance for Singapore PDPA Data Transfers Cloud computing and SaaS services are among the most common triggers for the Singapore PDPA cross-border transfer obligation. When an organisation uses a cloud-based CRM, HR system, analytics platform, or any other SaaS tool that stores or processes personal data on servers located outside Singapore, the organisation is making a Singapore PDPA data transfer. The PDPC Advisory Guidelines (Chapter 19) specifically reference this scenario: 'Company A uses a CRM cloud service that is offered by a service provider from the US. In using this service, Company A has to transfer personal data to the US. Company A must comply with the Transfer Limitation Obligation by ensuring that the service provider is able to afford adequate protection to the personal data transferred.' Organisations should first determine whether the cloud or SaaS vendor is acting as a data intermediary (processor) or as an independent organisation (controller) for the purpose of the Singapore PDPA cross-border transfer. Most cloud infrastructure and SaaS vendors operate as data intermediaries, processing personal data on behalf of and for the purposes of the subscribing organisation. For data intermediary relationships, the contractual clauses supporting the Singapore PDPA data transfer must at minimum cover protection (security), retention limitation, and data breach notification. For added assurance, organisations should also include purpose limitation, accuracy, access facilitation, and correction facilitation clauses. When evaluating a cloud or SaaS vendor's ability to provide comparable protection for a Singapore PDPA cross-border transfer, assess the vendor's security certifications (such as ISO 27001, SOC 2 Type II, or CSA STAR), its data processing locations, its sub-processor list and governance model, its data breach notification procedures, and its data deletion and return capabilities at contract termination. Many major cloud vendors publish Data Processing Agreements (DPAs) that can be reviewed against the PDPA's requirements. If the vendor holds an APEC CBPR or PRP certification, the certification itself satisfies the Singapore PDPA data transfer obligation without the need for additional contractual clauses. Organisations must also address the sub-processor chain in every cloud-based Singapore PDPA cross-border transfer. Cloud vendors frequently engage sub-processors in various countries. The contractual arrangement should require the vendor to notify the organisation of new sub-processors, to impose comparable data protection obligations on sub-processors, and to remain liable for the sub-processor's compliance. This mirrors the approach in both the ASEAN MCCs and the EU SCCs, and is critical for maintaining the comparable standard of protection throughout the entire processing chain of a Singapore PDPA data transfer. - Cloud and SaaS usage is one of the most common triggers for the Singapore PDPA cross-border transfer obligation. Any overseas storage or processing of personal data is a Singapore PDPA data transfer. - Determine whether the vendor acts as a data intermediary (processor) or an independent organisation (controller) for the purpose of the Singapore PDPA cross-border transfer. - For data intermediary vendors, contractual clauses supporting the Singapore PDPA data transfer must cover protection, retention, and data breach notification at minimum. - Check if the vendor holds APEC CBPR or PRP certification, which satisfies the Singapore PDPA cross-border transfer obligation directly without additional contractual clauses. - Review the vendor's DPA against the PDPA's comparable protection requirements listed in PDPC Chapter 19 guidance for all eight areas of protection. - Assess sub-processor governance: require notification of new sub-processors, comparable obligations on sub-processors, and vendor liability for sub-processor compliance in every Singapore PDPA data transfer arrangement. - Evaluate the vendor's security certifications (ISO 27001, SOC 2 Type II, CSA STAR) as evidence of the protection obligation for the Singapore PDPA cross-border transfer. - Address data deletion and return procedures at contract termination to satisfy retention limitation requirements for the Singapore PDPA data transfer. - Maintain a register of all cloud and SaaS vendors that process personal data overseas, including their Singapore PDPA cross-border transfer mechanism and assessment status. ## Record-Keeping for Singapore PDPA Cross-Border Transfer Documentation The PDPA's Accountability Obligation (sections 11 and 12) requires organisations to implement policies and procedures to meet their obligations and to make information about those policies publicly available. For Singapore PDPA cross-border transfers, this translates into maintaining comprehensive records that demonstrate compliance with the Transfer Limitation Obligation. While the PDPA does not prescribe a specific record-keeping format, organisations should build a Singapore PDPA data transfer register as a core component of their data protection management programme. Consistent record-keeping is the strongest evidence an organisation can present to the PDPC to demonstrate it takes the Singapore PDPA cross-border transfer obligation seriously. A Singapore PDPA cross-border transfer register should document, for each transfer: the categories of personal data transferred, the purpose of the transfer, the identity and location of the overseas recipient, whether the recipient acts as an organisation or a data intermediary, the transfer mechanism relied upon (contract, BCR, APEC CBPR/PRP, consent, or other alternative ground), a reference to the supporting documentation (e.g. signed contract, BCR document, certification verification record, consent record), the date the Singapore PDPA data transfer commenced, and the date of the most recent transfer impact assessment. Supporting documentation for each Singapore PDPA cross-border transfer should include: copies of signed contractual clauses (ASEAN MCCs, bespoke clauses, or vendor DPAs); BCR documents with the list of covered group entities; APEC CBPR or PRP certification verification records (including screenshots from www.cbprs.org and the date of verification); written summaries provided to individuals for consent-based Singapore PDPA data transfers; and transfer impact assessment records with the assessment outcome, justification, and next review date. For contract-based Singapore PDPA cross-border transfers, retain the full executed contract, not just the data protection clauses, because the PDPC may need to understand the commercial context. Organisations should review and update their Singapore PDPA cross-border transfer register at least annually, and whenever a material change occurs (such as a new vendor, a change in data processing location, or a certification lapse). The register should be accessible to the organisation's Data Protection Officer and be available for inspection by the PDPC if requested during an audit or investigation. Aligning the Singapore PDPA data transfer register with the organisation's broader data inventory and data flow mapping ensures consistency and reduces the effort required to respond to PDPC inquiries or enforcement actions. - Build a Singapore PDPA cross-border transfer register as part of your data protection management programme. This is the foundation of accountable Singapore PDPA data transfer compliance. - For each Singapore PDPA cross-border transfer, record: data categories, purpose, recipient identity and location, recipient role, transfer mechanism, supporting documentation reference, commencement date, and last assessment date. - Retain copies of signed ASEAN MCCs, bespoke contractual clauses, vendor DPAs, and BCR documents supporting each Singapore PDPA data transfer. - For APEC CBPR/PRP-based Singapore PDPA cross-border transfers, keep certification verification records with screenshots from www.cbprs.org and verification dates. - For consent-based Singapore PDPA data transfers, retain the written summaries provided to individuals and the consent records. - Keep transfer impact assessment records with the assessment outcome, justification, date, and next review date for each Singapore PDPA cross-border transfer. - Review and update the Singapore PDPA data transfer register at least annually and whenever a material change occurs (new vendor, new country, certification lapse, policy change). - Make the register accessible to the Data Protection Officer and available for PDPC inspection. - Align the Singapore PDPA cross-border transfer register with the organisation's broader data inventory and data flow mapping for consistency. *Recommended next step* *Placement: after the scope or definition section* ## Use Singapore PDPA Cross-Border Data Transfers as a cited research workflow Research Copilot can take Singapore PDPA Cross-Border Data Transfers from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on Singapore PDPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Singapore PDPA Cross-Border Data Transfers](/solutions/research-copilot.md): Start from Singapore PDPA Cross-Border Data Transfers and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Singapore PDPA](/contact.md): Review your current process, evidence gaps, and next steps for Singapore PDPA Cross-Border Data Transfers. ## Primary sources - [Personal Data Protection Act 2012 (Singapore) - official text](https://sso.agc.gov.sg/Act/PDPA2012?ref=sorena.io) - Primary legislation governing collection, use, disclosure, protection, retention, transfer, and accountability for personal data in Singapore. Section 26 establishes the Transfer Limitation Obligation for Singapore PDPA cross-border transfers. - [PDPC - PDPA overview](https://www.pdpc.gov.sg/overview-of-pdpa/pdpa-overview?ref=sorena.io) - Official PDPC overview of Singapore PDPA obligations, key concepts, and updates relevant to Singapore PDPA data transfer compliance. - [PDPC - Advisory Guidelines on Key Concepts in the PDPA (revised 16 May 2022)](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-the-personal-data-protection-act?ref=sorena.io) - Chapter 19 covers the Transfer Limitation Obligation for Singapore PDPA cross-border transfers, conditions for overseas transfer, scope of contractual clauses, comparable protection requirements, and data in transit. - [PDPC - Enforcement advisory guidelines](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-enforcement-of-data-protection-provisions?ref=sorena.io) - Enforcement approach, directions, financial penalties, and undertakings applicable to failures in Singapore PDPA data transfer compliance. - [PDPC - ASEAN Data Management Framework and Model Contractual Clauses](https://www.pdpc.gov.sg/help-and-resources/2021/01/asean-data-management-framework-and-model-contractual-clauses-on-cross-border-data-flows?ref=sorena.io) - Overview of the ASEAN DMF and MCCs approved on 22 January 2021. Links to the full ASEAN MCCs text and Singapore-specific guidance for Singapore PDPA cross-border transfers. - [PDPC - Singapore Guidance for Use of ASEAN MCCs (22 January 2021)](https://www.pdpc.gov.sg/help-and-resources/2021/01/asean-data-management-framework-and-model-contractual-clauses-on-cross-border-data-flows?ref=sorena.io) - PDPC guidance on adapting the ASEAN MCCs for Singapore PDPA cross-border transfers, including recommended amendments for deceased persons' data, breach notification time frames, and the Addendum. - [PDPC - Sample clause for APEC CBPR/PRP transfers](https://www.pdpc.gov.sg/help-and-resources/2020/06/sample-clause-for-data-transfers-to-apec-cbpr-and-prp-certified-organisations?ref=sorena.io) - Recommended contract clause for Singapore PDPA data transfers to organisations holding APEC CBPR or PRP certifications. - [Joint Guide to ASEAN MCCs and EU SCCs (updated 31 January 2024)](https://commission.europa.eu/document/download/e5e7758b-81fc-4c01-aa86-ebeb8d792c81_en?ref=sorena.io) - Reference Guide and Implementation Guide comparing ASEAN MCCs and EU SCCs for businesses operating across both regions. Essential for dual Singapore PDPA cross-border transfer and GDPR compliance. - [Personal Data Protection Regulations 2021](https://sso.agc.gov.sg/SL/PDPA2012-S63-2021?ref=sorena.io) - Subsidiary legislation prescribing the conditions for lawful Singapore PDPA cross-border transfers, specified certifications (APEC CBPR and PRP), binding corporate rules requirements, and alternative transfer grounds. ## Related Topic Guides - [Singapore PDPA Applicability Test | Does the PDPA Apply to Your Organisation?](/artifacts/apac/singapore-pdpa/applicability-test.md): Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation. - [Singapore PDPA Breach Notification Playbook - Complete Guide](/artifacts/apac/singapore-pdpa/breach-notification-playbook.md): Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline. - [Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026)](/artifacts/apac/singapore-pdpa/checklist.md): Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules. - [Singapore PDPA Compliance Deadlines and Calendar](/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar.md): Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows. - [Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM](/artifacts/apac/singapore-pdpa/compliance.md): Complete Singapore PDPA compliance guide for organisations. - [Singapore PDPA Consent and Notification Obligations Guide](/artifacts/apac/singapore-pdpa/consent-notification-and-purposes.md): Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception. - [Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide](/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages.md): Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses. - [Singapore PDPA FAQ | Frequently Asked Questions on Personal Data Protection Act Compliance](/artifacts/apac/singapore-pdpa/faq.md): Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements. - [Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions](/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases.md): Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover. - [Singapore PDPA Penalties and Fines | SGD 1M or 10% Turnover Cap + PDPC Enforcement Guide](/artifacts/apac/singapore-pdpa/penalties-and-fines.md): Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions. - [Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide](/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template.md): Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions. - [Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC)](/artifacts/apac/singapore-pdpa/requirements.md): Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18). - [Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations](/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries.md): Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion. - [Singapore PDPA Vendor Outsourcing and Contracts Guide](/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts.md): Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence. - [Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties](/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr.md): Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/singapore-pdpa/cross-border-transfers --- --- title: "Singapore PDPA Compliance Deadlines and Calendar" canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Singapore PDPA compliance deadlines" - "Singapore PDPA calendar" - "PDPA breach notification 3 days" - "PDPA access request 30 days" - "PDPA correction request deadline" - "PDPA consent withdrawal timeline" - "DNC registry check frequency" - "PDPA data retention review" - "PDPA DPIA schedule" - "PDPA vendor contract review" - "Personal Data Protection Act Singapore" - "PDPC guidelines deadlines" - "Singapore data breach notification deadline" - "PDPA accountability programme" - "data protection management programme" - "PDPA enforcement penalties" - "PDPA compliance checklist" - "Singapore PDPA compliance guide" - "PDPA annual review calendar" - "PDPA operating cadence" - "Singapore PDPA compliance calendar" - "PDPA statutory deadline" - "PDPA legislative timeline" - "Singapore data protection deadlines" - "PDPA 3 calendar days PDPC" - "PDPA Section 26D notification" - "PDPA Section 21 access" - "PDPA Section 22 correction" - "PDPA Section 16 consent withdrawal" - "PDPA Section 25 retention" - "PDPA Part 6A data breach" - "PDPA quarterly review schedule" - "PDPA breach notification deadline" - "PDPA compliance calendar" - "PDPA annual review" - "PDPA DNC check frequency" - "PDPA retention review schedule" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Singapore PDPA Compliance Deadlines and Calendar Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows. *Artifact Guide* *APAC* ## Singapore PDPA Compliance Deadlines and Calendar Every Singapore PDPA compliance deadline mapped to a practical calendar: the 3-calendar-day PDPC breach notification window, 30-day access request response, correction and consent withdrawal timelines, DNC registry check cadences, quarterly retention reviews, annual DPIA cycles, and vendor contract renewal milestones. Use this Singapore PDPA calendar to build a repeatable compliance programme with defensible evidence for every statutory and recommended deadline. This Singapore PDPA compliance deadlines page maps every time-bound obligation in the Personal Data Protection Act 2012 (PDPA) to a concrete calendar entry. The Singapore PDPA calendar covers statutory deadlines that carry direct enforcement risk -- including the 3-calendar-day breach notification to the PDPC, the 30-day access request response window, correction request timelines, and consent withdrawal handling periods -- as well as recommended cadences for activities the PDPC expects organisations to perform on a recurring basis, such as retention reviews, DNC registry checks, DPIA refreshes, and vendor contract audits. Whether you are a Data Protection Officer, compliance manager, legal counsel, or operations lead in Singapore, this page gives you a single reference for building an annual Singapore PDPA compliance calendar with provable deadlines, owners, and evidence trails. All dates and deadlines are grounded in the PDPA text (Act 26 of 2012, as amended by Act 40 of 2020 and Act 19 of 2025), the Personal Data Protection (Notification of Data Breaches) Regulations 2021, and PDPC advisory guidelines. ## Singapore PDPA Legislative Timeline: Key Effective Dates for Your Compliance Calendar Building a Singapore PDPA compliance calendar starts with understanding when each part of the Act came into force, because different obligations have different effective dates. The Personal Data Protection Act 2012 (Act 26 of 2012) was enacted by Parliament but its provisions took effect in phases over several years. Organisations that processed personal data before a given effective date must still meet the Singapore PDPA compliance deadlines for that data if they continue to hold or use it today. The Personal Data Protection Commission (PDPC) was established on 2 January 2013 as the regulator responsible for administering and enforcing the Singapore PDPA. The Do Not Call (DNC) Registry provisions came into force on 2 January 2014, while the main data protection obligations -- consent, purpose limitation, notification, access, correction, accuracy, protection, retention, and transfer limitation (Parts III to VII) -- took effect on 2 July 2014. This phased rollout gave organisations a transition window to prepare policies, notices, and consent mechanisms before enforcement began. Major amendments to the Singapore PDPA were passed by Parliament on 2 November 2020 and took effect in phases from 1 February 2021. These amendments introduced the mandatory data breach notification regime (Part 6A, Sections 26A-26E), added new legal bases including the legitimate interests exception and the business improvement exception, introduced deemed consent by notification (Section 15A), and raised enforcement powers. On 1 October 2022, further enforcement amendments took effect, including the PDPC's power to accept voluntary undertakings (Section 48L) and the increased financial penalty cap of 10% of annual local turnover for organisations with annual turnover exceeding S$10 million, or S$1 million, whichever is higher (Section 48J). Most recently, Act 19 of 2025 introduced additional amendments effective from 5 December 2025. Every compliance team maintaining a Singapore PDPA calendar should keep a legislative timeline register that records which provisions were in force at each point in time. This register serves as an audit trail when the PDPC reviews past processing activities and answers the question of whether a specific Singapore PDPA compliance deadline existed at the time a particular data-handling decision was made. - 2 January 2013: PDPC established as Singapore's data protection authority under Part 2 of the PDPA. - 2 January 2014: DNC Registry provisions (Part 9, Sections 36-48) came into force, requiring organisations to check the registry before sending marketing messages to Singapore telephone numbers. - 2 July 2014: main data protection obligations took effect (Parts III-VII), including consent, purpose limitation, notification, access, correction, accuracy, protection, retention, and transfer limitation. - 2 November 2020: Parliament passed amendments (Act 40 of 2020) adding mandatory breach notification, new legal bases, deemed consent by notification, and higher penalties. - 1 February 2021: first phase of amendments took effect, including mandatory data breach notification to PDPC and affected individuals under Part 6A (Sections 26A-26E). - 1 October 2022: enforcement amendments took effect, including voluntary undertakings (Section 48L) and the increased financial penalty cap -- 10% of annual local turnover or S$1 million, whichever is higher (Section 48J). - 5 December 2025: amendments under Act 19 of 2025 took effect, further updating the Singapore PDPA framework. - Maintain a legislative timeline register in your Singapore PDPA compliance calendar that records effective dates and maps each date to the obligations that commenced. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn Singapore PDPA Compliance Deadlines and Calendar into an operational assessment Assessment Autopilot can take Singapore PDPA Compliance Deadlines and Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on Singapore PDPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Singapore PDPA Compliance Deadlines and Calendar](/solutions/assessment.md): Start from Singapore PDPA Compliance Deadlines and Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Singapore PDPA](/contact.md): Review your current process, evidence gaps, and next steps for Singapore PDPA Compliance Deadlines and Calendar. ## Singapore PDPA Breach Notification Deadline: 3 Calendar Days to PDPC The most time-critical entry in any Singapore PDPA compliance calendar is the mandatory data breach notification deadline. Under Part 6A of the PDPA (Section 26D), organisations must notify the PDPC as soon as practicable, but in any case no later than 3 calendar days after the organisation determines that a notifiable data breach has occurred. This Singapore PDPA compliance deadline of 3 calendar days is absolute -- it runs from the date the organisation completes its assessment (under Section 26C), not from the date the breach was first discovered. The Personal Data Protection (Notification of Data Breaches) Regulations 2021 prescribe the detailed notification requirements. A data breach is notifiable under the Singapore PDPA if it results in, or is likely to result in, significant harm to affected individuals, or if it involves 500 or more affected individuals (Section 26B), even where significant harm is unlikely. The PDPC's Guide to Managing and Notifying Data Breaches (updated 15 March 2021) provides detailed guidance on assessing whether a breach meets the notification threshold. Organisations must also notify affected individuals as soon as practicable, either at the same time as or after notifying the PDPC (Section 26D(4)). To meet this 3-calendar-day Singapore PDPA compliance deadline, organisations need a pre-built breach assessment workflow. Without one, the time spent convening a response team, gathering facts, and debating whether the breach is notifiable can easily consume the entire window. The assessment must answer three questions: (1) what personal data was involved, (2) how many individuals were affected, and (3) whether significant harm is likely. If the answer to question 2 is 500 or more, or the answer to question 3 is yes, the breach is notifiable to the PDPC. Evidence of the assessment and the full timeline of events must be preserved as part of your Singapore PDPA calendar records. The PDPC expects organisations to document when the breach was discovered, when the assessment was completed, when notification was sent, and what containment steps were taken. Late notification or failure to notify is itself a breach of the Data Breach Notification Obligation and can result in directions and financial penalties under Section 48I and Section 48J. - 3 calendar days: the Singapore PDPA compliance deadline to notify the PDPC after the organisation determines a breach is notifiable (Section 26D(1)). - As soon as practicable: the Singapore PDPA deadline to notify affected individuals, at the same time as or after PDPC notification (Section 26D(4)). - 500 or more affected individuals triggers mandatory notification regardless of whether significant harm is likely (Section 26B(1)(b)). - Significant harm to any number of individuals also triggers mandatory notification under Section 26B(1)(a). - Section 26C requires organisations to conduct an assessment of a suspected data breach as soon as practicable after becoming aware of it. - Maintain a pre-built breach response runbook with roles, escalation paths, and template notification forms aligned to this Singapore PDPA calendar entry. - Document the full timeline: discovery date, assessment completion date, PDPC notification date, individual notification date, and containment actions. - Conduct breach tabletop exercises at least twice per year to pressure-test the 3-calendar-day Singapore PDPA compliance deadline. ## Singapore PDPA Access Request Deadline: 30 Calendar Days to Respond The Access Obligation under Section 21 of the Singapore PDPA requires organisations to respond to an individual's access request as soon as reasonably possible. The PDPC's Advisory Guidelines on Key Concepts in the PDPA indicate that organisations should respond within 30 calendar days from the date the request is received. This 30-day window is one of the most frequently tested Singapore PDPA compliance deadlines in PDPC enforcement decisions, making it a critical entry in every Singapore PDPA calendar. An access request asks the organisation to provide the individual with their personal data that is in the organisation's possession or control, and information about how that data has been used or disclosed in the preceding year (Section 21(1)). The organisation may charge a reasonable fee for responding but must not set a fee that is excessive or designed to discourage individuals from exercising their rights. If the organisation cannot respond within 30 days, it must inform the requestor of the expected timeline and the reasons for the delay. Operational readiness for meeting this Singapore PDPA compliance deadline requires a documented intake process, a data inventory that maps where personal data is stored across all systems, and a workflow for compiling and reviewing the response before release. Organisations must also have a redaction process to remove third-party personal data or information protected by exceptions in the Fifth Schedule before providing the response to the individual. Failure to respond within a reasonable time, or providing an incomplete response, can result in a complaint to the PDPC. The PDPC has the power under Part 9C to investigate, issue directions (Section 48I), and impose financial penalties (Section 48J). Tracking access requests in a register with dates, handler assignments, status updates, and response timelines is essential evidence of Singapore PDPA compliance calendar adherence. - 30 calendar days: the recommended Singapore PDPA compliance deadline to respond to an access request from date of receipt. - If unable to respond within 30 days, inform the requestor of the reason and the expected timeline for the response. - The response must include the individual's personal data held by the organisation and usage/disclosure information for the preceding year (Section 21(1)). - Organisations may charge a reasonable fee but must not set fees that discourage individuals from exercising access rights under the Singapore PDPA. - Build a documented intake workflow: log the request date, assign a handler, compile data from all systems, redact third-party data under Fifth Schedule exceptions, and send the response. - Maintain an access request register with columns for request date, assigned handler, response date, fee charged, and outcome as part of your Singapore PDPA calendar. - Review the Fifth Schedule (exceptions from access requirement) to identify categories of data that may be withheld from the response. - Audit the access request register quarterly to verify that all requests were closed within the 30-day Singapore PDPA compliance deadline. ## Singapore PDPA Correction Request Deadlines and Downstream Notification Under the Correction Obligation (Section 22 of the Singapore PDPA), an individual may request that an organisation correct an error or omission in their personal data. The organisation must correct the data and send the corrected data to every other organisation to which the data was disclosed within a year before the correction was made, unless that other organisation does not need the corrected data for any legal or business purpose. This downstream notification requirement makes correction requests one of the more operationally complex Singapore PDPA compliance deadlines to manage. The Singapore PDPA does not prescribe a specific number of days for correction, but PDPC advisory guidelines indicate that corrections should be made as soon as practicable. In practice, organisations should aim to complete corrections within 30 calendar days to align with the access request deadline and to demonstrate a consistent standard of responsiveness. This 30-day operational target should be recorded in your Singapore PDPA compliance calendar alongside the statutory access request deadline. If the organisation decides not to make a correction, Section 22(5) requires it to inform the individual of the refusal, the reasons for it, and how the individual can escalate the matter. The organisation must also annotate the personal data with the individual's requested correction so that the disputed information is flagged in its records. This annotation must remain for as long as the data is retained. Building a correction request workflow that mirrors the access request workflow reduces operational complexity and keeps your Singapore PDPA calendar consistent. Use the same intake form, tracking register, and escalation paths. Add a step for downstream notification to third parties who received the original data. Document each correction with the date it was completed, the fields corrected, and the list of third parties that were notified of the correction. - As soon as practicable: the statutory standard under Section 22 of the Singapore PDPA for completing a correction request. - Aim for 30 calendar days as an operational target in your Singapore PDPA compliance calendar to match the access request deadline. - Corrected data must be sent to every organisation to which it was disclosed in the preceding year, unless not needed for legal or business purposes (Section 22(3)). - If correction is refused, annotate the personal data with the individual's requested correction under Section 22(5). - Inform the individual of the refusal, the reasons, and available escalation options including complaint to the PDPC. - Use the same intake workflow and register as access requests to reduce process duplication across your Singapore PDPA calendar. - Log each correction with the completion date, corrected fields, and a list of third-party notifications sent. ## Singapore PDPA Consent Withdrawal Handling Timeline Section 16 of the Singapore PDPA gives individuals the right to withdraw consent for the collection, use, or disclosure of their personal data at any time by giving reasonable notice. The organisation must inform the individual of the likely consequences of withdrawal and must cease the relevant processing within a reasonable period after receiving the withdrawal notice. Although the Singapore PDPA does not specify a fixed number of days, this consent withdrawal timeline is an important entry in any Singapore PDPA compliance calendar. The PDPC expects organisations to process consent withdrawals within a reasonable timeframe. As an operational benchmark aligned to other Singapore PDPA compliance deadlines, organisations should aim to process consent withdrawals within 10 business days. This gives sufficient time to update internal systems, stop downstream data flows to third parties, and confirm the change to the individual, while staying well within what the PDPC would consider reasonable. The Singapore PDPA requires that the withdrawal mechanism must not be made unnecessarily difficult. The mechanism for withdrawal should be at least as easy as the mechanism by which consent was originally given. If consent was obtained through a single click on a web form, withdrawal should not require a phone call, postal letter, or in-person visit. The PDPC has flagged overly burdensome withdrawal processes in enforcement decisions. Organisations must also consider the downstream impact of consent withdrawal on their Singapore PDPA compliance calendar. If personal data was shared with data intermediaries, marketing partners, or other third parties, the organisation must ensure that those parties also cease the relevant processing. Documenting the withdrawal event, the date processing stopped, confirmation sent to the individual, and downstream notifications creates the evidence trail needed for a defensible Singapore PDPA compliance position. - Reasonable notice by the individual is required under Section 16; the organisation must then act within a reasonable period. - Aim for 10 business days as an operational target in your Singapore PDPA compliance calendar to process consent withdrawals across all systems. - Inform the individual of the likely consequences of withdrawal before implementing the change (Section 16(3)). - The withdrawal mechanism must be at least as accessible as the original consent mechanism under Section 16(5). - Notify downstream third parties -- data intermediaries, marketing partners, processors -- to cease the relevant processing. - Log each withdrawal in your Singapore PDPA calendar with the request date, implementation date, systems updated, downstream notifications, and confirmation sent. - Review consent withdrawal logs quarterly to identify patterns that may indicate UX friction or non-compliant barriers. ## Singapore PDPA Annual Compliance Review Calendar and DPMP Refresh The Accountability Obligation under Section 12 of the Singapore PDPA requires organisations to implement policies and practices necessary to meet their obligations under the Act, and to make information about those policies and practices available on request. The PDPC's Guide to Developing a Data Protection Management Programme (DPMP) describes the components of an effective programme. An annual compliance review is the anchor event in any Singapore PDPA compliance calendar, providing the structure for all other recurring deadlines. The annual Singapore PDPA compliance review should cover every obligation under the Act: consent mechanisms (Sections 13-17), purpose specifications (Sections 18-20), notification wording (Section 20), access and correction workflows (Sections 21-22), protection measures (Section 24), retention schedules (Section 25), transfer mechanisms (Section 26), data breach notification readiness (Part 6A), and accountability documentation (Section 12). The review should also assess whether the organisation's DPMP remains aligned with current PDPC advisory guidelines and enforcement trends. Organisations subject to the Singapore PDPA should designate a Data Protection Officer (DPO) or equivalent role to own the annual review. The PDPC's Guide to Accountability recommends that the DPO produce a written report summarising findings, gaps, and remediation actions, with deadlines and owners assigned to each item. This report is a key piece of audit evidence on your Singapore PDPA compliance calendar and should be retained for at least 5 years to demonstrate ongoing accountability. The annual review should include a training refresh for all employees who handle personal data. The PDPC has stated in enforcement decisions that lack of training is an aggravating factor when assessing penalties. Annual training ensures that staff are aware of current policies, know how to handle access and correction requests within the Singapore PDPA compliance deadlines, and understand breach escalation procedures within the 3-calendar-day window. - Conduct a full Data Protection Management Programme (DPMP) review once per year as the anchor event in your Singapore PDPA compliance calendar. - Review PDPC enforcement decisions published in the preceding year to identify emerging risk areas relevant to your Singapore PDPA compliance deadlines. - Produce a written annual review report with findings, gaps, remediation actions, owners, and deadlines. - Refresh data protection training for all staff who collect, use, or disclose personal data under the Singapore PDPA. - Update privacy notices and consent mechanisms to reflect any changes in processing activities since the last Singapore PDPA calendar review. - Review and update the data inventory and purpose register to ensure accuracy against Sections 18-20. - Retain the annual review report and training records for at least 5 years as audit evidence for Singapore PDPA compliance. - Schedule the annual review for the same month each year to establish a predictable Singapore PDPA compliance calendar rhythm. ## Singapore PDPA DNC Registry Check Frequency and Marketing Compliance Calendar The Do Not Call (DNC) Registry provisions under Part 9 of the Singapore PDPA (in force since 2 January 2014) require organisations to check the DNC Registry before sending specified messages -- voice calls, text messages, or fax -- to Singapore telephone numbers. Section 43 imposes a duty to check the register, and an organisation that sends a marketing message to a number listed on the DNC Registry without a valid exemption commits an offence. The DNC check cadence is one of the most operationally demanding entries on any Singapore PDPA compliance calendar for marketing teams. The Singapore PDPA does not prescribe a specific frequency for DNC checks, but the obligation is effectively continuous: an organisation must not send a marketing message to a registered number. In practice, organisations should check the DNC Registry immediately before each campaign or batch of outbound marketing messages. For organisations that send marketing messages on a recurring schedule, a monthly check is the minimum defensible frequency to record in the Singapore PDPA compliance calendar. The PDPC has taken enforcement action against organisations that relied on outdated DNC check results. Results from DNC checks should be cached only for the duration of a specific campaign. Numbers may be added to or removed from the registry at any time, so relying on a stale check result creates enforcement risk. The PDPC's Advisory Guidelines on the DNC Provisions recommend that organisations treat each campaign as a fresh check event and record the results accordingly in their Singapore PDPA calendar. Organisations should also maintain an internal do-not-contact list that combines DNC Registry results with individual opt-out requests received through other channels such as email, web forms, or customer service calls. This internal list should be updated in real time as new opt-out requests arrive. A quarterly audit of the DNC checking process should verify correct API or bulk-check usage, confirm that results are applied before messages are sent, and confirm that records of each check are retained as Singapore PDPA compliance evidence. - Check the DNC Registry (Section 43) before every marketing campaign or batch of outbound messages as a standing entry on your Singapore PDPA compliance calendar. - For recurring campaigns, check at least monthly as the minimum defensible frequency under Singapore PDPA compliance deadlines. - Do not cache DNC check results beyond the duration of a single campaign -- numbers can be added or removed at any time. - Maintain an internal do-not-contact list that merges DNC Registry results with direct opt-out requests from all channels. - Update the internal list in real time as new opt-out requests arrive to stay current with Singapore PDPA requirements. - Retain records of each DNC check (date, numbers checked, results) as compliance evidence in your Singapore PDPA calendar. - Conduct a quarterly audit of the DNC checking process to verify correct implementation and record-keeping. - Train all marketing staff on DNC requirements under Part 9 and the consequences of sending messages to registered numbers. ## Singapore PDPA Data Retention Review Schedule Under Section 25 The Retention Limitation Obligation under Section 25 of the Singapore PDPA requires organisations to cease retaining personal data, or remove the means by which the data can be associated with a particular individual, as soon as it is reasonable to assume that the purpose for which the data was collected is no longer being served and retention is no longer necessary for legal or business purposes. This obligation makes the data retention review a recurring entry on every Singapore PDPA compliance calendar. Because the Singapore PDPA ties retention to purpose, organisations must maintain a retention schedule that maps each data category to its collection purpose and the maximum period for which retention is justified. When the purpose expires and no legal hold or regulatory requirement applies, the data must be deleted or anonymised. This is not a one-time exercise -- new data categories are introduced with every product release, and existing purposes may change or expire over time, requiring updates to the Singapore PDPA calendar. A quarterly retention review is the recommended cadence for your Singapore PDPA compliance calendar. During each review, the compliance team should compare the data inventory against the retention schedule, identify any data that has exceeded its retention period, and initiate deletion or anonymisation workflows. The review should also flag any new data categories introduced since the last review and ensure they have been added to the retention schedule with a defined purpose and maximum retention period. The PDPC has penalised organisations in enforcement decisions for retaining personal data longer than necessary in violation of Section 25. Common violations found in Singapore PDPA enforcement cases include keeping customer data after account closure without documented justification, storing backup tapes containing personal data beyond the retention period, and failing to delete test data that contains real personal information. Documenting each retention review -- including what was reviewed, what was deleted, and what was retained with justification -- creates the evidence trail the PDPC expects. - Maintain a data retention schedule mapping each data category to its collection purpose and maximum retention period under Section 25 of the Singapore PDPA. - Conduct a quarterly retention review as a recurring entry in your Singapore PDPA compliance calendar, comparing the data inventory to the retention schedule. - Identify and delete or anonymise any data that has exceeded its retention period with no ongoing legal or business justification. - Flag new data categories introduced since the last review and add them to the retention schedule with a defined purpose. - Include backup systems, archives, and test environments in the scope of every Singapore PDPA retention review. - Document each review cycle: date, reviewer, categories checked, deletions performed, and exceptions justified. - Retain deletion certificates or logs as evidence that data was destroyed in accordance with the Singapore PDPA calendar schedule. - Align the quarterly retention review with the quarterly vendor review to ensure third-party processors also comply with retention limits. ## Singapore PDPA DPIA and Risk Assessment Scheduling Although the Singapore PDPA does not use the term 'Data Protection Impact Assessment' (DPIA), the Accountability Obligation (Section 12) and the PDPC's Guide to Data Protection Impact Assessments effectively require organisations to assess risks before undertaking new or significantly changed processing activities. A DPIA that evaluates the impact on individuals and identifies mitigating controls is a core component of a defensible Singapore PDPA compliance calendar and demonstrates proactive accountability to the PDPC. Organisations should add a DPIA trigger to their Singapore PDPA compliance calendar for every new product, feature, or service that involves the collection, use, or disclosure of personal data. The assessment should also be triggered by material changes to existing processing, such as introducing a new data recipient, changing the purpose of processing, adopting new technology (such as AI, machine learning, or biometric systems), or expanding processing to new jurisdictions. The PDPC's Guide to Data Protection Impact Assessments provides a step-by-step methodology. In addition to event-driven assessments, organisations should schedule a periodic review of existing processing activities on their Singapore PDPA compliance calendar. An annual DPIA review cycle ensures that assessments completed in prior years are still accurate and that controls identified as mitigations are still in place and effective. This annual review should be timed to coincide with the annual DPMP review described in the previous section to reduce duplication of effort while maintaining comprehensive Singapore PDPA compliance deadline coverage. Each DPIA should produce a written record that includes the processing activity described, the categories of personal data involved, the risks identified, the mitigating controls, and the residual risk accepted by the accountable decision-maker. These records should be retained for at least 5 years as part of your Singapore PDPA calendar documentation. The PDPC considers the existence and quality of risk assessments when deciding enforcement outcomes, and organisations that can demonstrate a systematic DPIA process aligned to their Singapore PDPA compliance calendar are likely to receive more favourable treatment. - Conduct a DPIA before launching any new product, feature, or service that processes personal data, as a standing trigger in your Singapore PDPA compliance calendar. - Trigger a DPIA for material changes: new data recipients, new purposes, new technology (AI/ML/biometrics), or new jurisdictions. - Schedule an annual review of all existing DPIAs on your Singapore PDPA calendar to verify that assessments remain accurate and controls are effective. - Align the annual DPIA review with the DPMP review to reduce duplication while maintaining full Singapore PDPA compliance deadline coverage. - Each DPIA record should include: processing description, data categories, risks identified, mitigating controls, and residual risk acceptance. - Retain DPIA records for at least 5 years as audit and enforcement evidence under your Singapore PDPA compliance calendar. - Assign clear ownership for each DPIA to a named individual or team. - Track DPIA completion status in a register and report overdue assessments to the DPO monthly as part of Singapore PDPA calendar governance. ## Singapore PDPA Vendor Contract Review and Renewal Calendar The Protection Obligation (Section 24) and the Transfer Limitation Obligation (Section 26) of the Singapore PDPA make the organisation that collected personal data responsible for ensuring that any receiving organisation provides a comparable standard of protection. This applies to data intermediaries, cloud service providers, marketing partners, and any other third party that processes personal data on behalf of the organisation. Vendor contract management is therefore one of the most operationally significant recurring entries on the Singapore PDPA compliance calendar. The PDPC's Guide to Managing Data Intermediaries and the Guide on Data Protection Clauses for Agreements Relating to the Processing of Personal Data provide model clauses and best practices for vendor contracts under the Singapore PDPA. Vendor contracts should include data protection clauses that specify the purposes for which data may be processed, the security measures required, breach notification obligations aligned to the 3-calendar-day Singapore PDPA deadline, sub-processor restrictions, data return or deletion on termination, and audit rights. These clauses must be reviewed before each contract renewal to reflect current PDPC guidance. A quarterly vendor review cadence is the recommended entry on your Singapore PDPA compliance calendar. Each quarter, the compliance team should review the vendor register, verify that all active vendors have current contracts with adequate data protection clauses, check that any new vendors onboarded since the last review have been assessed, and follow up on any open remediation items from prior reviews. For high-risk vendors processing large volumes of personal data or sensitive data, an annual audit or assessment questionnaire should supplement the quarterly contract review. Contract renewal dates should be tracked in your Singapore PDPA calendar with alerts set at least 90 days before expiry. This gives sufficient time to renegotiate data protection clauses, conduct a fresh risk assessment if the vendor's scope has changed, and involve legal counsel in reviewing new terms. Letting a contract lapse or auto-renew without reviewing the data protection provisions creates a gap in Singapore PDPA compliance that the PDPC may scrutinise during an investigation. For cross-border data transfers, organisations must also verify that the vendor's jurisdiction provides adequate protection or that appropriate contractual safeguards (such as ASEAN Model Contractual Clauses) are in place under Section 26. - Include data protection clauses in every vendor contract: purpose limitation, security requirements, breach notification aligned to Singapore PDPA deadlines, sub-processor controls, data return/deletion, and audit rights. - Conduct a quarterly vendor register review as a recurring entry on your Singapore PDPA compliance calendar: verify current contracts, assess new vendors, and follow up on remediation items. - For high-risk vendors, supplement quarterly reviews with an annual audit or assessment questionnaire aligned to the PDPC's Guide to Managing Data Intermediaries. - Track contract renewal dates in your Singapore PDPA calendar with 90-day advance alerts to allow time for renegotiation. - Review and update data protection clauses at each renewal to reflect current PDPC guidance and any changes to Singapore PDPA compliance deadlines. - Conduct a fresh risk assessment if the vendor's processing scope has changed since the last review. - Retain vendor assessment records, contract copies, and audit reports for at least 5 years as Singapore PDPA compliance evidence. - For cross-border transfers, verify adequate protection or appropriate contractual safeguards under Section 26 as part of each vendor review on your Singapore PDPA calendar. ## Primary sources - [Personal Data Protection Act 2012 (Singapore) -- official text](https://sso.agc.gov.sg/Act/PDPA2012?ref=sorena.io) - Primary legislation (Act 26 of 2012, current version as at February 2026) governing collection, use, disclosure, protection, retention, transfer, breach notification, and accountability for personal data in Singapore. - [PDPC -- PDPA overview](https://www.pdpc.gov.sg/overview-of-pdpa/pdpa-overview?ref=sorena.io) - Official PDPC overview of Singapore PDPA obligations, legislative timeline, key concepts, and updates including the 2021 and 2022 amendments. - [PDPC -- Advisory Guidelines on Key Concepts in the PDPA](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-the-personal-data-protection-act?ref=sorena.io) - Core interpretation guidance for consent, purposes, notification, access/correction, accuracy, protection, retention, transfers, and accountability -- including the 30-day access request response recommendation. - [PDPC -- Advisory Guidelines on Enforcement of Data Protection Provisions](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-enforcement-of-data-protection-provisions?ref=sorena.io) - Enforcement approach, directions, financial penalties, voluntary undertakings, and the updated penalty cap effective 1 October 2022. - [Personal Data Protection (Notification of Data Breaches) Regulations 2021](https://sso.agc.gov.sg/SL-Supp/S64-2021/Published/20210129?DocDate=20210129&ref=sorena.io) - Subsidiary legislation prescribing the mandatory breach notification framework, including the 3-calendar-day deadline to the PDPC. - [PDPC -- Guide to Managing and Notifying Data Breaches under the PDPA](https://www.pdpc.gov.sg/help-and-resources/2021/01/data-breach-management-guide?ref=sorena.io) - Official guidance (updated 15 March 2021) on breach detection, assessment, containment, notification to PDPC and individuals, and post-incident review. - [PDPC -- Guide to Developing a Data Protection Management Programme](https://www.pdpc.gov.sg/help-and-resources/2019/07/guide-to-developing-a-data-protection-management-programme?ref=sorena.io) - PDPC guide for building a DPMP covering governance, policies, data inventory, risk assessment, and annual review cycles. - [PDPC -- Guide to Data Protection Impact Assessments](https://www.pdpc.gov.sg/help-and-resources/2017/11/guide-to-data-protection-impact-assessments?ref=sorena.io) - Step-by-step DPIA methodology for assessing risks to individuals from new or changed processing activities under the Singapore PDPA. ## Related Topic Guides - [Singapore PDPA Applicability Test | Does the PDPA Apply to Your Organisation?](/artifacts/apac/singapore-pdpa/applicability-test.md): Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation. - [Singapore PDPA Breach Notification Playbook - Complete Guide](/artifacts/apac/singapore-pdpa/breach-notification-playbook.md): Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline. - [Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026)](/artifacts/apac/singapore-pdpa/checklist.md): Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules. - [Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM](/artifacts/apac/singapore-pdpa/compliance.md): Complete Singapore PDPA compliance guide for organisations. - [Singapore PDPA Consent and Notification Obligations Guide](/artifacts/apac/singapore-pdpa/consent-notification-and-purposes.md): Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception. - [Singapore PDPA Cross-Border Transfer Rules | Section 26 Data Transfer Compliance](/artifacts/apac/singapore-pdpa/cross-border-transfers.md): Complete guide to Singapore PDPA cross-border transfer compliance under Section 26. - [Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide](/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages.md): Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses. - [Singapore PDPA FAQ | Frequently Asked Questions on Personal Data Protection Act Compliance](/artifacts/apac/singapore-pdpa/faq.md): Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements. - [Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions](/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases.md): Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover. - [Singapore PDPA Penalties and Fines | SGD 1M or 10% Turnover Cap + PDPC Enforcement Guide](/artifacts/apac/singapore-pdpa/penalties-and-fines.md): Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions. - [Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide](/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template.md): Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions. - [Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC)](/artifacts/apac/singapore-pdpa/requirements.md): Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18). - [Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations](/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries.md): Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion. - [Singapore PDPA Vendor Outsourcing and Contracts Guide](/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts.md): Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence. - [Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties](/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr.md): Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar --- --- title: "Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide" canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages" source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages" author: "Sorena AI" description: "Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Singapore PDPA Do Not Call" - "Singapore DNC Registry" - "Singapore PDPA DNC compliance" - "Do Not Call Registry Singapore" - "Singapore DNC Registry checking" - "Singapore PDPA specified message" - "Singapore telemarketing compliance" - "PDPC DNC advisory guidelines" - "Singapore DNC consent evidential form" - "Singapore No Voice Call Register" - "Singapore No Text Message Register" - "Singapore No Fax Message Register" - "Singapore DNC Registry business rules" - "Singapore DNC Registry account" - "Singapore DNC bulk filtering" - "Singapore PDPA marketing messages" - "Singapore DNC penalties" - "Singapore PDPA enforcement" - "Singapore DNC ongoing relationship exception" - "Singapore DNC B2B exception" - "Singapore PDPA caller identification" - "Singapore DNC opt-out obligations" - "Singapore DNC third-party checker" - "Singapore DNC Registry API" - "Singapore PDPA section 43" - "Singapore PDPA section 44" - "Singapore PDPA section 45" - "Singapore DNC 21-day validity" - "Singapore PDPA address harvesting prohibition" - "Singapore DNC WhatsApp compliance" - "Singapore DNC VoIP compliance" - "Singapore PDPA compliance guide" - "Singapore PDPA compliance checklist" - "PDPA Do Not Call provisions" - "Singapore PDPA" - "Singapore Do Not Call Registry" - "PDPC advisory guidelines" - "APAC privacy" - "data protection" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses. *Artifact Guide* *APAC* ## Singapore PDPA Do Not Call Registry and Marketing Messages Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses: registry checking obligations, consent requirements, caller identification rules, channel-specific rules, exceptions, penalties, and step-by-step marketing workflows. Grounded in PDPC Advisory Guidelines on the Do Not Call Provisions (revised 1 February 2021) and DNC Registry business rules at dnc.gov.sg. This guide covers every aspect of the Singapore PDPA Do Not Call (DNC) provisions that marketing, legal, compliance, and operations teams need to build a compliant outbound marketing process. The Singapore DNC Registry, operated by the Personal Data Protection Commission (PDPC) at www.dnc.gov.sg, allows individuals to register their Singapore telephone numbers to opt out of unsolicited telemarketing messages. The Singapore PDPA Do Not Call provisions are set out in Parts 9 and 9A of the Personal Data Protection Act 2012 and have been in force since 2 January 2014. They apply to any person or organisation that sends, causes to be sent, or authorises the sending of specified messages (telemarketing messages) to Singapore telephone numbers. Organisations must comply with both the Singapore DNC provisions and the Data Protection Provisions in Parts 3 to 6A of the PDPA. This page explains the three Singapore DNC registers, the 21-day checking obligation, consent in evidential form, caller identification requirements, Eighth Schedule exceptions, digital channel coverage, penalties, practical workflows, and Singapore DNC Registry business rules including account setup, fees, and bulk filtering. Use the PDPC advisory guidelines and DNC Registry sources linked below to tailor these requirements to your specific message types, channels, and vendor relationships. ## Singapore PDPA Do Not Call Registry: overview and legal basis The Singapore Do Not Call (DNC) Registry is established by the Personal Data Protection Commission (PDPC) under the Personal Data Protection Act 2012 (PDPA). The Singapore DNC Registry allows individuals in Singapore to register their telephone numbers to opt out of receiving unsolicited telemarketing messages. The Singapore PDPA Do Not Call provisions came into effect on 2 January 2014 and apply alongside the Data Protection Provisions in Parts 3 to 6A of the PDPA. Organisations are required to comply with both sets of provisions when conducting marketing activities in Singapore. The Singapore PDPA Do Not Call provisions apply broadly to any 'person' sending specified messages. Under section 2(1) of the Interpretation Act, 'person' includes natural persons as well as companies, associations, and other bodies of persons, whether corporate or unincorporated. This means sole proprietors, partnerships, and corporations operating in or targeting Singapore are all subject to Singapore DNC obligations when they send, cause to be sent, or authorise the sending of marketing messages to Singapore telephone numbers. The Singapore DNC Registry is operated at www.dnc.gov.sg as a Singapore Government agency service administered by the PDPC. A 'Singapore telephone number' is defined in section 36(1) of the PDPA as an eight-digit number beginning with 3, 6, 8, or 9 that conforms to the National Numbering Plan referred to in regulation 12A of the Telecommunications (Class Licence) Regulations. This definition covers mobile numbers, fixed-line numbers, residential numbers, and business numbers. The scope of the Singapore DNC Registry is comprehensive: any marketing message targeting these number formats must comply with the Singapore PDPA Do Not Call checking obligations unless a valid exception applies. The PDPC issued Advisory Guidelines on the Do Not Call Provisions (revised 1 February 2021) to provide detailed interpretation guidance on how the Singapore DNC provisions apply in different scenarios. The February 2021 revision introduced requirements for third-party DNC checkers under section 43A and strengthened prohibitions on dictionary attacks and address-harvesting software under section 48B. These guidelines are advisory and not legally binding, but they represent the Commission's stated interpretation of the Singapore PDPA Do Not Call provisions and are treated as the practical compliance standard. - Legal basis: Parts 9 and 9A of the Personal Data Protection Act 2012 (sections 36 through 48B) establish the Singapore PDPA Do Not Call provisions. - Effective date: Singapore DNC provisions have been in force since 2 January 2014; Data Protection Provisions since 2 July 2014. - Scope: applies to any person (individual, company, association, or body corporate) sending specified messages to Singapore telephone numbers. - Covered numbers: all eight-digit Singapore numbers starting with 3, 6, 8, or 9, including mobile, fixed-line, residential, and business lines. - Consumer registration: individuals can register at www.dnc.gov.sg online, by SMS (send 'DNC' to 78771), or by calling the toll-free number 1800 248 0771. Registration is free and does not expire. - Regulatory authority: the Personal Data Protection Commission (PDPC) administers and enforces the Singapore DNC Registry and DNC provisions. - Advisory guidelines: the PDPC issued Advisory Guidelines on the Do Not Call Provisions (revised 1 February 2021) to explain how the Singapore PDPA DNC provisions apply in different scenarios. - Dual compliance: organisations must comply with both the Singapore DNC provisions and the PDPA Data Protection Provisions (consent, purpose limitation, notification, protection, retention) when conducting marketing activities. ## Three Singapore DNC Registers: voice call, text message, and fax The Singapore DNC Registry consists of three separate registers, each covering a distinct communication channel. Individuals may choose to register their Singapore telephone numbers on one, two, or all three Singapore DNC registers depending on which types of telemarketing messages they wish to stop receiving. The No Voice Call Register covers opt-out from telemarketing calls. The No Text Message Register covers opt-out from telemarketing text messages. The No Fax Message Register covers opt-out from telemarketing fax messages. Organisations must check the relevant Singapore DNC register for the specific channel they intend to use before sending any marketing message. The No Voice Call Register under the Singapore DNC Registry covers voice or video calls sent by telephone service, data service, or any other electronic means. This includes traditional phone calls, VoIP calls, and calls made through data applications such as WhatsApp, iMessage, or Viber when they use a Singapore telephone number. The No Text Message Register covers any text, sound, or visual message that is not a voice call or fax, including SMS, MMS, and messages sent through messaging applications targeting a Singapore telephone number. The No Fax Message Register covers facsimile messages sent to Singapore telephone numbers. When an organisation checks telephone numbers against the Singapore DNC Registry, all three registers are checked simultaneously. The results indicate the registration status of each number on each register. Organisations must respect the registration status for each channel independently when planning Singapore DNC-compliant marketing campaigns. For example, a number may be registered on the No Text Message Register but not on the No Voice Call Register, allowing voice call marketing but blocking SMS marketing to that number. Each Singapore DNC register operates independently, and organisations must match the correct register to their intended message channel. - No Voice Call Register: opt out of receiving telemarketing calls (voice or video calls via telephone service, data service, or electronic means) under the Singapore DNC Registry. - No Text Message Register: opt out of receiving telemarketing text messages (SMS, MMS, and equivalent non-call, non-fax messages) under the Singapore DNC Registry. - No Fax Message Register: opt out of receiving telemarketing fax messages under the Singapore DNC Registry. - Each Singapore DNC register is independent: a number can be on one, two, or all three registers simultaneously. - Singapore DNC Registry checks return results for all three registers in a single query, showing each number's status per register. - Organisations must match the correct Singapore DNC register to their intended message channel before sending any specified message. - Data applications (WhatsApp, iMessage, Viber) that use Singapore telephone numbers are covered by the relevant Singapore DNC register for the message type (voice call or text message). - The three-register structure of the Singapore DNC Registry gives consumers granular control while requiring organisations to check the correct register for each marketing channel. ## Singapore DNC Registry checking obligations before sending marketing messages Under section 43 of the Singapore PDPA, before a person sends a specified message to a Singapore telephone number, they must check with the Singapore DNC Registry to confirm the number is not listed on the relevant DNC Register. The only exception to this Singapore DNC checking obligation is when the sender has already obtained clear and unambiguous consent in evidential form from the user or subscriber of the number. This is the core compliance obligation that every marketing team must build into their outbound workflow when targeting Singapore telephone numbers. The prescribed checking period for the Singapore DNC Registry is 21 days. This means a person must have made a checking application within 21 days before sending the specified message. Results returned from the Singapore DNC Registry are valid for up to 21 days from the date of receipt. Once this validity period lapses, the organisation must perform another Singapore DNC Registry check before continuing telemarketing activities. For example, if an organisation receives results on 2 February, those results are valid until 23 February. Organisations running campaigns longer than 21 days must schedule recurring Singapore DNC Registry checks to maintain compliance. There are two methods for submitting telephone numbers for checking against the Singapore DNC Registry. The Small Number Lookup method allows up to 10 numbers to be submitted at a time with immediate results displayed. The Bulk Filtering method requires uploading a CSV file containing a single column of eight-digit telephone numbers, with results available within 24 hours. The bulk filtering results from the Singapore DNC Registry include filtered numbers with their status on each register, a summary of the submission, an on-behalf list if checking for other organisations, and rejected numbers with reasons for rejection. Only eight-digit numbers starting with 3, 6, 8, or 9 are accepted by the Singapore DNC Registry system. Organisations that use third-party checkers for Singapore DNC Registry compliance should be aware that the PDPC does not endorse any third-party checker. Under section 43A of the PDPA (introduced 1 February 2021), a 'checker' who checks the Singapore DNC Registry on behalf of a sender must ensure the information provided is accurate and must include the date the results were received along with the expiry date. The liability for Singapore DNC infringements resulting from erroneous information falls on the third-party checker. However, the sending organisation remains liable if it had reason to believe the information was expired, false, or inaccurate. - Section 43 duty: check with the Singapore DNC Registry before sending any specified message, unless you hold clear and unambiguous consent in evidential form. - Validity period: Singapore DNC Registry check results are valid for 21 days from receipt (as of 1 February 2021 onwards). - Small Number Lookup: submit up to 10 numbers at a time to the Singapore DNC Registry with immediate results displayed. - Bulk Filtering: upload a CSV of eight-digit numbers to the Singapore DNC Registry; results delivered within 24 hours via email or SMS notification. - Only eight-digit numbers starting with 3, 6, 8, or 9 are accepted by the Singapore DNC Registry system. - Third-party checkers (section 43A): must provide accurate Singapore DNC Registry information and include the date of results and expiry; liability falls on the checker for erroneous data. - Re-check requirement: perform a new Singapore DNC Registry check every 21 days if telemarketing campaigns continue beyond the validity window. - Record retention: maintain logs of when Singapore DNC Registry checks were performed, the numbers checked, and the results received for compliance evidence. ## Singapore PDPA caller identification and contact information requirements Section 44 of the Singapore PDPA requires that every specified message sent to a Singapore telephone number must include clear and accurate identification information and contact information. This Singapore PDPA caller identification obligation applies to all specified messages regardless of channel -- voice calls, SMS, MMS, fax, and messages through data applications. The information must be reasonably likely to remain valid for at least 30 days after the message is sent. Failure to include proper identification and contact information is a separate violation from failure to check the Singapore DNC Registry. Identification information under the Singapore PDPA must allow the recipient to determine who sent or authorised the sending of the message. An organisation may use its legal name, a trading name, brand name, or a related name such as a retail outlet or property development name, as long as the recipient can identify the sender. The PDPC Advisory Guidelines on the Singapore DNC provisions make clear that generic pronouns such as 'me' or 'us', informal nicknames, and fictitious names are not acceptable as identification information. A website address may serve as identification if the sender can be identified from the URL text itself or from the landing page content. Contact information under the Singapore PDPA must enable the recipient to 'readily contact' the sender. The most straightforward approach is to include an operational Singapore telephone number that accepts incoming calls or text messages, or a valid email address that accepts incoming mail. The PDPC guidelines on the Singapore DNC provisions clarify that short codes and no-reply email addresses do not satisfy this requirement because they do not allow the recipient to directly communicate with the sender. A physical address alone is also insufficient because it requires the recipient to make a trip or send a letter, which does not meet the 'readily contact' standard set by the Singapore PDPA. For voice calls containing specified messages, section 45 of the Singapore PDPA adds a further obligation: the sender must not conceal or withhold the calling line identity from the recipient. The calling line identity is defined in section 36(1) as the telephone number or information identifying the sender. Organisations must ensure their telephony systems are configured to transmit the correct calling line identity for all outbound marketing calls to comply with the Singapore PDPA Do Not Call provisions. Concealing or withholding the calling line identity is a separate contravention under the Singapore PDPA even if the Singapore DNC Registry was properly checked. - Section 44: every specified message must include clear and accurate identification information (who sent it) and contact information (how to reach the sender) under the Singapore PDPA. - Validity requirement: identification and contact information must remain valid for at least 30 days after the message is sent. - Acceptable identification under Singapore PDPA: legal name, trading name, brand name, or related name (e.g., retail outlet, property development) that the recipient can link to the sender. - Unacceptable identification: generic pronouns ('me', 'us'), informal nicknames, fictitious names, or names that cannot be linked to the sender. - Website as identification: permitted under the Singapore PDPA if the sender is identifiable from the URL text or the landing page content. - Acceptable contact information: an operational Singapore telephone number receiving calls/texts, or a valid email address receiving incoming mail. - Unacceptable contact information: short codes, no-reply email addresses, physical addresses alone, or hyperlinks that do not display a URL or contact detail. - Section 45 (voice calls): the sender must not conceal or withhold the calling line identity; the caller ID must be displayed to the recipient under the Singapore PDPA. ## Singapore PDPA DNC exceptions: ongoing relationships and B2B messages The Eighth Schedule to the Singapore PDPA lists categories of messages that are excluded from the definition of 'specified message' and therefore not subject to Singapore DNC provisions. Understanding these Singapore PDPA DNC exceptions is critical for marketing teams because they determine which outbound communications can be sent without checking the Singapore DNC Registry or obtaining DNC-specific consent. However, organisations must still comply with the Data Protection Provisions of the Singapore PDPA for all communications, even those excluded from Singapore DNC requirements. The ongoing relationship exception under paragraph 1(e) of the Eighth Schedule excludes messages where the sender has an ongoing relationship with the recipient and the sole purpose of the message relates to the subject matter of that relationship. Under the Singapore PDPA, an 'ongoing relationship' means a relationship on an ongoing basis arising from the conduct of a business or activity by the sender. The PDPC Advisory Guidelines on the Singapore DNC provisions provide examples: retail memberships, media subscriptions, insurance policies, bank accounts, loans, and regular participation in an organisation's activities. Importantly, one-off transactions do not establish an ongoing relationship under the Singapore PDPA. The Commission considers factors such as continuity, regularity, and frequency when assessing whether an ongoing relationship exists for Singapore DNC exception purposes. The sole-purpose requirement for the Singapore PDPA ongoing relationship exception is strict. If a message serves a purpose beyond the subject matter of the ongoing relationship, it loses the exclusion and becomes a specified message subject to Singapore DNC provisions. For example, a message to an existing credit card holder promoting a new credit card of the same type may qualify under the Singapore PDPA DNC exception, but a message that promotes an unrelated product line would not. A message that combines a notification about a change in account terms with a marketing offer for a new product would also lose the Singapore DNC exclusion because its purpose is not solely related to the ongoing relationship. The B2B exception under paragraph 1(g) of the Eighth Schedule excludes messages sent to an organisation (other than an individual acting in a personal or domestic capacity) for any purpose of the receiving organisation. This Singapore PDPA DNC exception allows company-to-company marketing without checking the Singapore DNC Registry. However, the PDPC guidelines make clear that if a B2B call shifts to marketing a product for the individual's personal use, the Singapore DNC exception no longer applies, and the sender must comply with Singapore DNC provisions for that personal marketing component. Other Eighth Schedule exclusions include public agency non-commercial messages, personal/domestic messages, emergency messages, transaction confirmations, warranty and safety information, product updates under existing contracts, charitable cause solicitations without marketing elements, and messages whose sole purpose is market research or survey. - Ongoing relationship exception (paragraph 1(e)): excludes messages from Singapore DNC obligations where the sender and recipient have an ongoing business relationship and the message's sole purpose relates to the subject matter of that relationship. - Definition of ongoing relationship under Singapore PDPA: arising from continuous business conduct; includes subscriptions, memberships, accounts, loans, and regular participation in activities. - One-off transactions do not create an ongoing relationship under the Singapore PDPA; the PDPC assesses continuity, regularity, and frequency. - Sole-purpose test for Singapore DNC exception: the message must relate only to the subject matter of the ongoing relationship; mixing marketing for unrelated products removes the exclusion. - B2B exception (paragraph 1(g)): messages sent to organisations (not individuals in personal capacity) for the receiving organisation's purposes are excluded from Singapore DNC provisions. - B2B boundary: if a B2B call shifts to marketing for the individual's personal use, Singapore DNC obligations apply to the personal marketing portion. - Transaction and service messages (paragraph 1(d)): confirmations, warranty info, product recalls, safety info, and entitled upgrades/updates are excluded from Singapore DNC provisions if that is the sole purpose. - Market research exception (paragraph 1(f)): messages whose sole purpose is conducting market research or survey are excluded from Singapore DNC provisions; gifts as thanks for participation are acceptable but must not disguise specified messages. ## Singapore DNC consent management: obtaining and withdrawing consent in evidential form If an organisation holds clear and unambiguous consent in evidential form from the user or subscriber of a Singapore telephone number, it does not need to check the Singapore DNC Registry before sending specified messages to that number. This Singapore PDPA DNC consent must be specific: the individual must have been clearly and specifically notified that specified messages would be sent to their Singapore telephone number, and the individual must have given consent through a positive action. The PDPC Advisory Guidelines on the Singapore DNC provisions state that mere failure to opt out or inaction does not constitute clear and unambiguous consent. Consent for Singapore DNC purposes must be evidenced in written or other form so as to be accessible for subsequent reference (referred to as 'evidential form' in the PDPC Advisory Guidelines). Written form includes physical or electronic documents. If consent is not in written form, it must be captured in a manner that can be retrieved and reproduced later, such as an audio or video recording. For electronic consent used to satisfy Singapore DNC obligations, organisations should retain system logs capturing the individual's choice, date and time, the webpage or form presented, and the specific clauses consented to including applicable terms and conditions. This evidential form is a distinctive requirement of the Singapore PDPA Do Not Call regime. The Singapore PDPA prohibits organisations from requiring consent for telemarketing as a condition of providing goods or services beyond what is reasonable. Under section 46(1), an organisation must not require a consumer to agree to receive specified messages as a prerequisite for receiving goods, services, land, interest, or opportunity. Organisations should offer individuals the option to consent to Singapore DNC marketing messages without denying them products or services for declining. Additionally, consent obtained through false or misleading information or deceptive practices is not valid under the Singapore PDPA. The PDPC treats violations of section 46 as separate contraventions carrying their own penalties. Individuals can withdraw their consent for Singapore DNC marketing messages by giving notice to the organisation. Under section 47(3), the organisation must cease sending specified messages to the number within 21 days of receiving the withdrawal notice (the 'prescribed period'). The scope of withdrawal depends on the content and channel of the notice. Under the Singapore PDPA, a general withdrawal sent via SMS would typically apply to all specified messages sent by SMS only. If the individual wants to withdraw consent across all channels (voice, text, and fax), the individual should explicitly state that intention. Importantly, an individual's subsequent registration on the Singapore DNC Registry does not amount to withdrawal of consent previously given to a specific organisation. - Clear and unambiguous consent for Singapore DNC purposes: the individual must be specifically notified that specified messages will be sent to their Singapore telephone number and must give consent through positive action. - Evidential form: consent must be recorded in written form (physical or electronic) or another form accessible for subsequent reference (e.g., audio or video recording) to satisfy Singapore PDPA DNC requirements. - Electronic consent logging for Singapore DNC compliance: retain the individual's choice, date/time, the webpage or form presented, and the clauses and terms consented to. - No bundling under Singapore PDPA: section 46(1) prohibits requiring telemarketing consent as a condition of supplying goods or services beyond what is reasonable. - Invalid consent: consent obtained through false or misleading information or deceptive practices is void under the Singapore PDPA section 46. - Withdrawal of consent: the individual may withdraw consent by giving notice; the organisation has 21 days to stop sending specified messages under Singapore DNC provisions. - Scope of withdrawal: a withdrawal sent via one channel (e.g., SMS) typically applies to all specified messages on that channel only under the Singapore PDPA, unless the individual explicitly requests broader withdrawal. - Singapore DNC Registry registration is not withdrawal: if an individual granted consent to an organisation and later registers on the Singapore DNC Registry, the prior consent remains effective for that specific organisation. ## Singapore DNC compliance for digital marketing channels and data applications The Singapore PDPA Do Not Call provisions apply to all means by which a sender may send a specified message to a Singapore telephone number. Under section 36(1), 'send' includes the sending of a message, causing or authorising the sending, or making a voice call containing the message. A 'message' includes messages in sound, text, visual, or other form. This broad definition under the Singapore PDPA means that modern digital marketing channels are subject to Singapore DNC obligations whenever they target a Singapore telephone number, regardless of the technology or platform used. Messages sent through data applications such as WhatsApp, iMessage, or Viber are subject to Singapore DNC provisions when they use a Singapore telephone number to deliver the message. A voice call made through a VoIP application to a Singapore telephone number is treated the same as a traditional phone call for Singapore DNC purposes and must be checked against the No Voice Call Register of the Singapore DNC Registry. An SMS or rich media message sent through a messaging platform to a Singapore telephone number falls under the No Text Message Register. Organisations must check the appropriate Singapore DNC register before sending marketing messages through any of these digital channels. The Singapore PDPA Do Not Call provisions do not apply to specified messages that are not sent to a Singapore telephone number. This means location-based broadcasts pushed to mobile phones through data-enabled smart phone applications, or data applications that do not use a Singapore telephone number to identify the recipient, are not covered by Singapore DNC rules. However, the Data Protection Provisions of the Singapore PDPA may still apply to such communications, particularly regarding the collection, use, and disclosure of personal data. Email marketing is also not covered by Singapore DNC provisions because email is not sent to a Singapore telephone number, though the PDPA Data Protection Provisions and the Spam Control Act may apply separately. Section 48B of the Singapore PDPA prohibits persons from sending messages to telephone numbers generated or obtained through address-harvesting software, and from using dictionary attacks or similar automated means to send messages indiscriminately. This prohibition was strengthened in the February 2021 amendments to the Singapore PDPA. Organisations must ensure their telephone number acquisition practices rely on legitimate sources and properly documented consent, not automated harvesting tools. Violations of section 48B carry the same financial penalties as other Singapore DNC contraventions. - Broad channel coverage: Singapore DNC provisions apply to voice calls, SMS, MMS, fax, and messages sent through data applications (WhatsApp, iMessage, Viber, etc.) when targeting Singapore telephone numbers. - Data application rule under Singapore PDPA: if a messaging app uses a Singapore telephone number to send the message, the relevant Singapore DNC register applies. - VoIP calls: treated identically to traditional phone calls under the Singapore DNC provisions; check the No Voice Call Register before making marketing calls through VoIP. - Not covered by Singapore DNC: location-based broadcasts or data app messages that do not use a Singapore telephone number as the delivery address. - Data Protection Provisions still apply: even for channels not covered by Singapore DNC provisions, the PDPA's consent, purpose, and notification obligations govern personal data use. - Email marketing: email is not covered by Singapore DNC provisions because it is not sent to a Singapore telephone number; however, PDPA Data Protection Provisions and the Spam Control Act may apply. - Section 48B prohibition under Singapore PDPA: address-harvesting software, dictionary attacks, and similar automated means of generating or obtaining telephone numbers for indiscriminate messaging are prohibited. - February 2021 amendments: strengthened Singapore PDPA prohibitions on dictionary attacks and address-harvesting, and introduced requirements for third-party Singapore DNC checkers under section 43A. ## Singapore PDPA DNC penalties and enforcement for non-compliance The PDPC has enforcement authority over Singapore DNC violations and can issue directions, financial penalties, and undertakings against organisations that breach the Singapore PDPA Do Not Call provisions. The penalties framework was strengthened by the 2020 amendments to the Singapore PDPA, which came into force on 1 February 2021. Financial penalties for Singapore DNC violations can be significant and are designed to deter non-compliance and encourage organisations to invest in proper Singapore DNC compliance processes. Under the Singapore PDPA, the PDPC can impose a financial penalty of up to SGD 1 million per breach for violations of the Singapore DNC provisions. For organisations, the maximum financial penalty can reach up to 10% of annual turnover in Singapore, or SGD 1 million, whichever is higher (subject to the amended penalty framework). The PDPC considers factors such as the nature and seriousness of the Singapore DNC contravention, whether the contravention was deliberate or arose from negligence, the volume of unsolicited messages sent, the degree of cooperation with the investigation, and whether the organisation had Singapore DNC compliance policies in place. In addition to financial penalties for Singapore DNC violations, the PDPC can issue directions requiring the organisation to stop the contravening activity, destroy personal data collected in contravention of the Singapore PDPA, or take other corrective actions. The PDPC may also accept an undertaking from the organisation, which is a binding commitment to take specified steps to address the Singapore DNC breach. Enforcement decisions for Singapore DNC violations are published on the PDPC website and can cause significant reputational harm in addition to the financial penalty. Individuals also have the right to lodge complaints with the PDPC for unsolicited telemarketing messages received on Singapore telephone numbers registered with the Singapore DNC Registry. The PDPC investigates complaints through its Complaints and Reviews process and may initiate enforcement proceedings for Singapore DNC violations. Organisations should maintain complete records of their Singapore DNC Registry checking processes, consent records, and marketing message logs to defend against complaints and demonstrate compliance with the Singapore PDPA Do Not Call provisions. - Financial penalties for Singapore DNC violations: up to SGD 1 million per breach; up to 10% of annual Singapore turnover for organisations under the amended framework. - Enforcement powers: the PDPC can issue directions to stop Singapore DNC contraventions, destroy improperly collected data, or require corrective actions. - Undertakings: the PDPC may accept binding commitments from organisations to take specified remediation steps for Singapore DNC breaches. - Published decisions: PDPC enforcement decisions for Singapore DNC violations are publicly available and can cause reputational damage beyond the financial penalty. - Assessment factors for Singapore DNC penalties: nature and seriousness of the breach, whether deliberate or negligent, volume of messages sent, cooperation level, and existence of compliance policies. - Individual complaints: consumers can lodge complaints via the PDPC Complaints and Reviews process for unsolicited telemarketing messages received on Singapore DNC-registered numbers. - Third-party checker liability under Singapore PDPA: under section 43A, third-party checkers bear liability for Singapore DNC infringements resulting from erroneous information they provide. - Sender liability: the sender (including any person who caused or authorised the sending) remains liable for Singapore DNC violations even when using a marketing agency or third-party vendor. ## Practical Singapore DNC compliance workflow for marketing teams Building a compliant outbound marketing workflow under the Singapore PDPA Do Not Call provisions requires integrating Singapore DNC Registry checks, consent management, exception handling, and evidence retention into a single repeatable process. Marketing teams should not treat Singapore DNC compliance as a separate legal checkbox but as a core part of campaign operations. Every campaign brief should include a Singapore DNC compliance section that documents the message type, target channel, consent basis, and applicable exceptions under the Eighth Schedule. Step one is to classify the message under the Singapore PDPA. Determine whether the planned communication is a 'specified message' under section 37 of the PDPA. A message is a specified message if its purpose (or one of its purposes) is to advertise, promote, or offer goods, services, land, interests, or business/investment opportunities. If the message is purely a transaction confirmation, service notification, market survey, B2B communication, or falls under another Eighth Schedule exclusion, document the applicable Singapore DNC exception and the reasoning before proceeding without a Singapore DNC Registry check. Step two is to check consent records for Singapore DNC purposes. If you hold clear and unambiguous consent in evidential form from the recipient for the specific channel and message type, document the consent record (including the date obtained, the specific clause, and the evidence form) and proceed. If consent is not available or is uncertain, proceed to step three: perform the Singapore DNC Registry check. Submit the target telephone numbers via Small Number Lookup (up to 10 numbers, immediate results) or Bulk Filtering (CSV upload, results within 24 hours) at www.dnc.gov.sg. Record the date of the check, the numbers submitted, and the results received. Do not send specified messages to numbers registered on the relevant Singapore DNC Register. Ensure the Singapore DNC check was performed within 21 days of the planned send date. Step four is to prepare the message content compliant with Singapore PDPA requirements. Every specified message must include clear and accurate identification information (sender name) and contact information (operational phone number or valid email). For voice calls, ensure the calling line identity is not concealed as required by section 45 of the Singapore PDPA. Include opt-out instructions using the same medium as the message. Step five is to send and log: execute the campaign, retain logs of all messages sent (numbers, timestamps, message content), and maintain these records alongside Singapore DNC Registry check results and consent records for compliance evidence. Re-check the Singapore DNC Registry every 21 days if campaigns continue beyond the validity window. - Classify the message: determine if it is a 'specified message' under Singapore PDPA section 37 or falls under an Eighth Schedule exclusion from Singapore DNC obligations. - Check consent records: verify whether clear and unambiguous consent in evidential form exists for the recipient, channel, and message type as required by the Singapore PDPA. - Perform Singapore DNC Registry check: use Small Number Lookup (up to 10 numbers, immediate) or Bulk Filtering (CSV, within 24 hours) within 21 days of the planned send date. - Do not send to Singapore DNC-registered numbers: filter out any number listed on the relevant Singapore DNC Register (Voice Call, Text Message, or Fax) for the intended channel. - Prepare compliant message content: include sender identification, contact information, and opt-out instructions in every specified message as required by Singapore PDPA sections 44 and 45. - Voice call compliance under Singapore PDPA: display calling line identity and do not conceal or withhold the sender's number. - Log everything for Singapore DNC compliance: record DNC check dates, numbers checked, results, consent records, and message send details (numbers, timestamps, content). - Re-check the Singapore DNC Registry every 21 days: if campaigns continue beyond the validity window, perform a fresh Singapore DNC Registry check to maintain compliance. ## Singapore DNC Registry business rules: account setup, fees, and bulk filtering To use the Singapore DNC Registry, organisations must first create a DNC Registry account at www.dnc.gov.sg. Each organisation is allowed one main account, with the ability to create sub-accounts for multiple users. Singapore-registered organisations need a Unique Entity Number (UEN) and a representative's Singpass for Singapore DNC Registry registration. Overseas organisations not registered in Singapore must provide company registration information and a phone or utility bill. Individual users register using Singpass. Upon successful Singapore DNC account creation, an activation link is sent to the registered email address. Singapore DNC Registry account creation involves a one-time fee (inclusive of 9% GST): SGD 32.70 for a main account for Singapore-registered organisations (SGD 65.40 for overseas organisations), SGD 32.70 per sub-account, and SGD 32.70 for individual main accounts. Each main Singapore DNC Registry account receives 1,000 free credits annually (valid for one year). Sub-accounts do not receive free credits. These free credits are consumed first before purchased credits when performing Singapore DNC Registry checks. For organisations with high-volume Singapore DNC Registry checking needs, the Prepaid scheme allows purchasing credits in advance. One credit is consumed per telephone number checked against the Singapore DNC Registry. Purchased credits are valid for three years. Pricing tiers range from SGD 0.0218 per number (5,000 credits at SGD 109) down to SGD 0.0109 per number (1,000,000 credits at SGD 10,900). The Pay-per-use scheme charges per submission with a minimum of SGD 10. Rates are SGD 0.0273 per number for 1 to 4,999 numbers and SGD 0.0251 per number for 5,000 or more numbers. All Singapore DNC Registry prices include 9% GST. If your organisation checks the Singapore DNC Registry on behalf of other organisations, you must indicate those organisations on the declaration page during account creation. This list can be updated later. The Singapore DNC Registry Bulk Filtering results include an 'On Behalf List' file showing which organisations you checked on behalf of at the time of submission. Organisations should integrate Singapore DNC Registry checking into their marketing automation platform or CRM by scheduling regular bulk checks and applying filtered results as campaign suppression lists before execution. Payment can be made online via credit or direct debit cards; offline payment (bank transfer) is available for transactions of SGD 5,000 or more. - Account setup: create one main account per organisation at www.dnc.gov.sg; use UEN and Singpass (Singapore organisations) or company registration documents (overseas organisations) for Singapore DNC Registry access. - Sub-accounts: create additional Singapore DNC Registry sub-accounts (SGD 32.70 each) to allow multiple users to perform DNC checks. - Free credits: 1,000 free credits per year with each main Singapore DNC Registry account; consumed first before purchased credits. - Prepaid scheme: purchase Singapore DNC Registry credits in bulk (5,000 to 1,000,000); valid for three years; prices range from SGD 0.0109 to SGD 0.0218 per number (inclusive of 9% GST). - Pay-per-use scheme: SGD 0.0273 per number for 1-4,999 numbers; SGD 0.0251 per number for 5,000+ numbers; minimum charge SGD 10 per submission for Singapore DNC Registry checks. - Payment: online via credit or direct debit cards; offline (bank transfer) available for transactions of SGD 5,000 or more. - On-behalf checking: indicate the names of organisations you check on behalf of during Singapore DNC Registry account creation; update the list as needed. - Integration recommendation: automate Singapore DNC Registry checks within your CRM or marketing platform by scheduling regular bulk filtering and applying results as campaign suppression lists. *Recommended next step* *Placement: after the scope or definition section* ## Use Singapore PDPA Do Not Call Registry and Marketing Messages as a cited research workflow Research Copilot can take Singapore PDPA Do Not Call Registry and Marketing Messages from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on Singapore PDPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Singapore PDPA Do Not Call Registry and Marketing Messages](/solutions/research-copilot.md): Start from Singapore PDPA Do Not Call Registry and Marketing Messages and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Singapore PDPA](/contact.md): Review your current process, evidence gaps, and next steps for Singapore PDPA Do Not Call Registry and Marketing Messages. ## Primary sources - [Personal Data Protection Act 2012 (Singapore) - official text](https://sso.agc.gov.sg/Act/PDPA2012?ref=sorena.io) - Primary legislation governing the Singapore DNC provisions (Parts 9 and 9A), data protection obligations, and enforcement framework. - [PDPC - Advisory Guidelines on the Do Not Call Provisions (revised 1 February 2021)](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-the-do-not-call-provisions?ref=sorena.io) - Official PDPC interpretation guidance for the Singapore DNC provisions covering specified messages, checking obligations, consent requirements, identification rules, exclusions, and third-party checkers. - [PDPC - Do Not Call Registry and Your Business](https://www.pdpc.gov.sg/overview-of-pdpa/do-not-call-registry/business-owner/do-not-call-registry-and-your-business?ref=sorena.io) - Operational guidance for businesses on Singapore DNC obligations including sending marketing messages, exceptions, and third-party checker responsibilities. - [PDPC - Do Not Call Registry Business Rules](https://www.pdpc.gov.sg/overview-of-pdpa/do-not-call-registry/business-owner/do-not-call-registry-business-rules?ref=sorena.io) - Singapore DNC Registry account creation, checking methods (Small Number Lookup, Bulk Filtering), fees, credit schemes, and on-behalf checking rules. - [DNC Registry - official site (dnc.gov.sg)](https://www.dnc.gov.sg/?ref=sorena.io) - Official Singapore Do Not Call Registry site for consumer registration (online, SMS, phone) and organisation account management. - [PDPC - PDPA overview](https://www.pdpc.gov.sg/overview-of-pdpa/pdpa-overview?ref=sorena.io) - Official PDPC overview of Singapore PDPA obligations, key concepts, and updates relevant to DNC compliance. - [PDPC - Enforcement advisory guidelines](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-enforcement-of-data-protection-provisions?ref=sorena.io) - PDPC enforcement approach, directions, financial penalties, and undertakings for Singapore DNC and data protection violations. ## Related Topic Guides - [Singapore PDPA Applicability Test | Does the PDPA Apply to Your Organisation?](/artifacts/apac/singapore-pdpa/applicability-test.md): Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation. - [Singapore PDPA Breach Notification Playbook - Complete Guide](/artifacts/apac/singapore-pdpa/breach-notification-playbook.md): Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline. - [Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026)](/artifacts/apac/singapore-pdpa/checklist.md): Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules. - [Singapore PDPA Compliance Deadlines and Calendar](/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar.md): Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows. - [Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM](/artifacts/apac/singapore-pdpa/compliance.md): Complete Singapore PDPA compliance guide for organisations. - [Singapore PDPA Consent and Notification Obligations Guide](/artifacts/apac/singapore-pdpa/consent-notification-and-purposes.md): Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception. - [Singapore PDPA Cross-Border Transfer Rules | Section 26 Data Transfer Compliance](/artifacts/apac/singapore-pdpa/cross-border-transfers.md): Complete guide to Singapore PDPA cross-border transfer compliance under Section 26. - [Singapore PDPA FAQ | Frequently Asked Questions on Personal Data Protection Act Compliance](/artifacts/apac/singapore-pdpa/faq.md): Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements. - [Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions](/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases.md): Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover. - [Singapore PDPA Penalties and Fines | SGD 1M or 10% Turnover Cap + PDPC Enforcement Guide](/artifacts/apac/singapore-pdpa/penalties-and-fines.md): Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions. - [Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide](/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template.md): Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions. - [Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC)](/artifacts/apac/singapore-pdpa/requirements.md): Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18). - [Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations](/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries.md): Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion. - [Singapore PDPA Vendor Outsourcing and Contracts Guide](/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts.md): Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence. - [Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties](/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr.md): Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages --- --- title: "Singapore PDPA FAQ" canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/faq" source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/faq" author: "Sorena AI" description: "Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Singapore PDPA FAQ" - "Singapore PDPA frequently asked questions" - "Singapore PDPA compliance" - "Personal Data Protection Act Singapore FAQ" - "Singapore PDPA requirements" - "Singapore PDPA consent" - "Singapore PDPA deemed consent" - "Singapore PDPA breach notification" - "Singapore PDPA DPO requirement" - "Singapore PDPA penalties" - "Singapore PDPA cross-border transfer" - "Singapore PDPA NRIC guidelines" - "Singapore PDPA legitimate interests" - "Singapore PDPA business improvement exception" - "Singapore PDPA Do Not Call registry" - "Singapore PDPA accountability obligation" - "Singapore PDPA data intermediary" - "Singapore PDPA access request" - "Singapore PDPA correction request" - "PDPC advisory guidelines" - "Singapore PDPA vs GDPR" - "Singapore PDPA extraterritorial" - "Singapore PDPA scope" - "Singapore PDPA personal data definition" - "Singapore PDPA protection obligation" - "Singapore PDPA retention limitation" - "PDPA compliance guide Singapore" - "Singapore PDPA" - "Personal Data Protection Act FAQ" - "PDPC enforcement" - "Singapore data breach notification" - "deemed consent Singapore PDPA" - "DPO Singapore PDPA" - "NRIC PDPA guidelines" - "APAC data protection" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Singapore PDPA FAQ Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements. *Artifact Guide* *APAC* ## Singapore PDPA FAQ Frequently asked questions about the Singapore PDPA answered with practical compliance guidance covering scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements, NRIC restrictions, cross-border transfers, penalties, and GDPR comparison. This Singapore PDPA FAQ page is marked up with FAQPage structured data for search engine rich results. This Singapore PDPA FAQ page provides implementation-focused answers to the most common questions compliance, legal, product, and operations teams ask when building a Singapore PDPA compliance programme. The Singapore Personal Data Protection Act (PDPA) governs the collection, use, disclosure, and care of personal data by private-sector organisations in Singapore. Enacted in 2012 with main data protection rules taking effect on 2 July 2014 and significant amendments coming into force from 1 February 2021, the Singapore PDPA is administered and enforced by the Personal Data Protection Commission (PDPC). Each Singapore PDPA FAQ answer below is grounded in the official PDPA statute and the PDPC Advisory Guidelines on Key Concepts (revised 16 May 2022). Use the official sources linked at the bottom of this page and tailor the answers to your specific processing context and industry. ## What is the Singapore PDPA and who does it apply to? The Singapore PDPA (Personal Data Protection Act 2012) is Singapore's primary data protection law. According to the PDPC, the Singapore PDPA provides a baseline standard of protection for personal data across the private sector. It complements sector-specific legislation such as the Banking Act and Insurance Act rather than replacing those frameworks. The Singapore PDPA is administered and enforced by the Personal Data Protection Commission (PDPC), which was established on 2 January 2013. Section 3 of the Singapore PDPA states that its purpose is to govern the collection, use, and disclosure of personal data by organisations in a manner that recognises both the right of individuals to protect their personal data and the need of organisations to collect, use, or disclose personal data for purposes that a reasonable person would consider appropriate. The Singapore PDPA applies to all private-sector organisations that collect, use, or disclose personal data in Singapore, regardless of whether the organisation is incorporated or headquartered in Singapore. As defined in section 2(1) of the Singapore PDPA, an organisation means any individual, company, association, or body of persons, corporate or unincorporated, whether or not formed or recognised under Singapore law or resident or having an office in Singapore. The Singapore PDPA covers personal data stored in both electronic and non-electronic formats, so paper records containing personal data are also within scope of the Singapore PDPA. There are several important exclusions from the Singapore PDPA. The Data Protection Provisions do not apply to any individual acting in a personal or domestic capacity. They also do not apply to any employee acting in the course of employment with an organisation, because the employing organisation bears the Singapore PDPA obligations. Public agencies, including government ministries, departments, and statutory bodies specified by the Minister, are excluded from the Singapore PDPA data protection provisions. Business contact information -- defined as an individual's name, position, business telephone number, business address, business email, and business fax number not provided solely for personal purposes -- is also excluded from Singapore PDPA coverage. - The Singapore PDPA applies to all private-sector organisations collecting, using, or disclosing personal data in Singapore. - Coverage under the Singapore PDPA includes both electronic and non-electronic (paper) records containing personal data. - Public agencies are excluded from the Singapore PDPA data protection provisions. - Individuals acting in a personal or domestic capacity are not covered by the Singapore PDPA. - Business contact information (business name, title, work phone, work email, work address) is excluded from the Singapore PDPA. - Employees are not personally liable under the Singapore PDPA; the employing organisation bears the obligations. - The PDPC has administered and enforced the Singapore PDPA since January 2013. ## What counts as personal data under the Singapore PDPA? Under the Singapore PDPA, personal data means data, whether true or not, about an individual who can be identified from that data, or from that data and other information to which the organisation has or is likely to have access (section 2(1) of the PDPA). The PDPC Advisory Guidelines on Key Concepts (revised 16 May 2022) explain that the Singapore PDPA definition is not intended to be narrowly construed and covers different types of data from which an individual can be identified, regardless of whether the data is true or accurate. The Singapore PDPA applies to data in electronic or non-electronic form. The PDPC applies a two-part test to determine whether data is personal data under the Singapore PDPA. First, the data must be about an individual or relate to the individual. Second, the individual must be identifiable from the data alone or in combination with other information the organisation has or is likely to have access to. The PDPC uses a practicability threshold: an organisation is not considered to have access to other information if gaining such access would require unreasonable costs, time, or resources. As a rule of thumb, the PDPC states that at least two data elements are generally needed before individuals can be identified, though this depends on the specificity and nature of the data. Certain categories of data receive additional attention under the Singapore PDPA. NRIC numbers, Birth Certificate numbers, Foreign Identification Numbers, and Work Permit numbers are subject to specific PDPC Advisory Guidelines restricting their collection and use, effective 1 September 2019. Under these Singapore PDPA guidelines, private-sector organisations may only collect, use, or disclose NRIC numbers if required by law or if it is necessary to establish or verify identity to a high degree of accuracy. Anonymised data that cannot reasonably be re-identified falls outside the Singapore PDPA definition, but the organisation must ensure the anonymisation is effective. - The Singapore PDPA defines personal data as data about an individual who can be identified from that data alone or in combination with other accessible information. - Both direct identifiers (name, NRIC, passport number) and indirect identifiers (phone number, IP address when linkable) are covered by the Singapore PDPA. - The PDPC applies a practicability threshold when assessing whether data is personal data under the Singapore PDPA. - NRIC numbers and other national identification numbers are subject to additional PDPC advisory guidelines restricting collection under the Singapore PDPA. - Anonymised data that cannot reasonably be re-identified falls outside the Singapore PDPA definition. - Deceased persons' data is covered by the Singapore PDPA to a limited extent for up to 10 years after death. ## What are the main data protection obligations under the Singapore PDPA? The Singapore PDPA imposes ten data protection obligations on organisations that handle personal data, set out in Parts 3 to 6A of the Act. These Singapore PDPA obligations work together to create a comprehensive framework for responsible data handling. The PDPC Advisory Guidelines on Key Concepts summarise each obligation by reference to specific PDPA sections. Together, the Singapore PDPA obligations require organisations to build systematic data governance processes covering the entire data lifecycle. The Singapore PDPA Consent Obligation (sections 13-17) requires organisations to obtain the individual's consent before collecting, using, or disclosing personal data unless an exception applies. The Singapore PDPA Purpose Limitation Obligation (section 18) restricts organisations to handling personal data only for purposes that a reasonable person would consider appropriate in the circumstances. The Singapore PDPA Notification Obligation (section 20) requires organisations to inform individuals of the purposes for which their personal data will be collected, used, or disclosed on or before such handling occurs. The Singapore PDPA Access and Correction Obligations (sections 21, 22, and 22A) give individuals the right to request access to their personal data and correction of errors or omissions. The Singapore PDPA Accuracy Obligation (section 23) requires reasonable efforts to ensure data accuracy when it is likely to be used to make decisions or disclosed to another organisation. The Singapore PDPA Protection Obligation (section 24) mandates reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal, or loss of storage media. The Singapore PDPA Retention Limitation Obligation (section 25) requires organisations to stop retaining personal data when it is no longer needed for any business or legal purpose. The Singapore PDPA Transfer Limitation Obligation (section 26) governs overseas transfers and requires comparable protection. The Singapore PDPA Data Breach Notification Obligation (sections 26A-26E) requires assessment and notification of notifiable data breaches. The Singapore PDPA Accountability Obligation (sections 11 and 12) requires organisations to implement and document policies and practices and make information about them publicly available. - Singapore PDPA Consent Obligation: Obtain consent before collecting, using, or disclosing personal data (subject to exceptions). - Singapore PDPA Purpose Limitation Obligation: Only handle personal data for purposes a reasonable person would consider appropriate. - Singapore PDPA Notification Obligation: Inform individuals of purposes before or at collection. - Singapore PDPA Access and Correction Obligations: Provide access to data and correct errors on request. - Singapore PDPA Protection Obligation: Implement reasonable security arrangements against unauthorised access and risks. - Singapore PDPA Retention Limitation Obligation: Cease retention when data is no longer needed. - Singapore PDPA Transfer Limitation Obligation: Ensure overseas-transferred data receives comparable protection. - Singapore PDPA Data Breach Notification Obligation: Notify the PDPC and affected individuals of notifiable breaches. - Singapore PDPA Accountability Obligation: Implement and document policies and practices to meet all obligations. ## How does consent work under the Singapore PDPA? Under the Singapore PDPA Consent Obligation (sections 13-17), organisations must obtain the individual's consent before collecting, using, or disclosing personal data. Section 14(1) of the Singapore PDPA specifies how consent is given: it must be informed, meaning the individual must be told the purposes for which the data will be handled before or at the time of collection, and the consent must relate to those stated purposes. The Singapore PDPA prohibits organisations from requiring individuals to consent beyond what is reasonable to provide a product or service. Consent under the Singapore PDPA can be express or deemed. Express consent is a clear, affirmative indication of agreement, such as signing a consent form, ticking a checkbox, or verbally agreeing. The Singapore PDPA does not mandate a specific form for consent, but the organisation must be able to demonstrate that valid consent was obtained. The PDPC Advisory Guidelines on Key Concepts state that silence or inaction does not generally constitute consent under the Singapore PDPA unless the conditions for deemed consent are met. Section 14(4) of the Singapore PDPA also provides that consent may be given by any person validly acting on behalf of the individual. Individuals have the right to withdraw consent under the Singapore PDPA at any time by giving reasonable notice. Once an individual withdraws consent, the organisation must stop collecting, using, or disclosing the personal data for the relevant purpose. The Singapore PDPA requires organisations to inform the individual of the likely consequences of withdrawal but prohibits penalising the withdrawal itself. The PDPC Advisory Guidelines emphasise that organisations must allow and facilitate the withdrawal of consent and must take specific actions upon receiving a notice of withdrawal. Organisations should build consent management systems that track consent status per purpose and support withdrawal workflows under their Singapore PDPA compliance programme. - Singapore PDPA consent must be informed: individuals must know the purpose before or at the time of data collection. - Express consent under the Singapore PDPA can be written, electronic (checkbox, click-through), or verbal. - Organisations cannot bundle consent or require consent beyond what is reasonably needed under the Singapore PDPA. - Silence or inaction is not valid consent under the Singapore PDPA unless deemed consent conditions are satisfied. - Individuals may withdraw consent under the Singapore PDPA at any time with reasonable notice. - Organisations must inform individuals of the consequences of withdrawal but cannot penalise them under the Singapore PDPA. - Build consent logging systems that record the purpose, wording version, timestamp, and withdrawal status for Singapore PDPA compliance. ## What is deemed consent under the Singapore PDPA and when does it apply? Deemed consent is a mechanism under the Singapore PDPA that allows organisations to treat an individual as having consented in specific circumstances without requiring an express opt-in. The Singapore PDPA recognises three main forms of deemed consent: deemed consent by conduct, deemed consent by contractual necessity, and deemed consent by notification. Each form has distinct requirements that organisations must satisfy to rely on Singapore PDPA deemed consent as their legal basis for handling personal data. Singapore PDPA deemed consent by conduct applies when an individual voluntarily provides personal data to an organisation for a purpose and it is reasonable that the individual would consent to the collection, use, or disclosure for that purpose. For example, if a customer hands over a business card at a trade event for the purpose of receiving follow-up product information, the individual is deemed to have consented to that use under the Singapore PDPA. Singapore PDPA deemed consent by contractual necessity, introduced in the 2021 amendments, applies where the collection, use, or disclosure is reasonably necessary for the performance of a contract between the organisation and the individual, and the organisation has informed the individual of the purpose. Singapore PDPA deemed consent by notification applies where the organisation notifies the individual of the intended purpose and gives a reasonable period for the individual to opt out, but the individual does not opt out. Organisations using Singapore PDPA deemed consent by notification must conduct a prior assessment using the PDPC's Annex B assessment checklist before relying on this basis. The PDPC Advisory Guidelines on Key Concepts state that the opt-out mechanism must be clearly communicated and easy to use. Singapore PDPA deemed consent does not apply to purposes that the individual could not reasonably be expected to understand or accept. Organisations should document the legal basis (express consent vs. Singapore PDPA deemed consent) for each processing purpose in their data protection management programme. - Singapore PDPA deemed consent by conduct: the individual voluntarily provides data for a purpose and it is reasonable to infer consent. - Singapore PDPA deemed consent by contractual necessity: collection, use, or disclosure is reasonably necessary for contract performance. - Singapore PDPA deemed consent by notification: the organisation notifies the individual and provides a reasonable opt-out period with no opt-out exercised. - For Singapore PDPA deemed consent by notification, organisations must conduct a prior assessment using the PDPC's Annex B checklist. - The opt-out mechanism under Singapore PDPA deemed consent by notification must be clearly communicated and easy to use. - Singapore PDPA deemed consent does not apply to purposes the individual could not reasonably be expected to understand or accept. - Document the legal basis for each processing purpose in your Singapore PDPA data protection management programme. ## What is the legitimate interests exception under the Singapore PDPA? The Singapore PDPA legitimate interests exception was introduced by the 2020 amendments (effective 1 February 2021) and allows organisations to collect, use, or disclose personal data without consent where the processing is necessary for a legitimate interest that outweighs any adverse effect on the individual. This Singapore PDPA exception is similar in concept to the GDPR's legitimate interests basis under Article 6(1)(f), but the Singapore PDPA version has its own specific requirements and assessment framework defined by the PDPC. To rely on the Singapore PDPA legitimate interests exception, the organisation must conduct and document an assessment before beginning the processing. The PDPC has published Annex C (Assessment Checklist for Legitimate Interests Exception) to the Advisory Guidelines on Key Concepts to guide this evaluation. The assessment must identify the legitimate interest, evaluate whether the processing is necessary to achieve it, and weigh the benefit of the processing against any adverse effect on the individual whose data is being processed under the Singapore PDPA. Key conditions apply to the Singapore PDPA legitimate interests exception. The organisation must not process the data in a way that has an unjustified adverse effect on the individual. The organisation must implement reasonable safeguards such as limiting access to the data, putting in place data retention limits, and using technical measures to protect the data. The organisation must also provide the individual with a reasonable and accessible means to opt out of the processing where practicable. All Singapore PDPA legitimate interests assessment documentation must be retained and made available on request for audit and regulatory review. - The Singapore PDPA legitimate interests exception has been available since 1 February 2021 following the 2020 amendments. - Allows processing without consent under the Singapore PDPA where legitimate interest outweighs adverse effect on the individual. - Requires a documented assessment before processing begins, following the PDPC's Annex C checklist for the Singapore PDPA. - The assessment must identify the legitimate interest, confirm necessity, and balance benefits against adverse effects under the Singapore PDPA. - Organisations must implement reasonable safeguards including access limits, retention limits, and technical protection for Singapore PDPA compliance. - Provide individuals with a reasonable opt-out mechanism where practicable under the Singapore PDPA legitimate interests exception. - Retain the Singapore PDPA legitimate interests assessment documentation for audit and regulatory review. ## What is the business improvement exception under the Singapore PDPA? The Singapore PDPA business improvement exception, introduced by the 2020 amendments (effective 1 February 2021), permits organisations to use personal data without consent for the purpose of improving or developing their products, services, or business processes. This Singapore PDPA exception recognises that organisations often need to use existing customer data for analytics, service improvement, and operational efficiency without going back for fresh consent each time. The Singapore PDPA business improvement exception applies specifically to the use of personal data and does not extend to new collection or disclosure. The data must have been collected for another purpose under a valid legal basis, and the business improvement use must be related to the original collection purpose under the Singapore PDPA. The organisation must also ensure that the use does not have an adverse effect on the individual. Qualifying business improvement purposes under the Singapore PDPA include improving or developing new products and services, improving or developing operational processes and systems, and learning about and understanding the behaviour and preferences of individuals to personalise or customise products and services. The organisation must take reasonable steps to ensure that the personal data used is not individually identifiable where possible under the Singapore PDPA, and it must not use the data to make any decision that specifically affects the individual unless there is a separate legal basis for doing so. - The Singapore PDPA business improvement exception permits use (not collection or disclosure) of personal data without consent. - The data must have been originally collected under a valid legal basis in compliance with the Singapore PDPA. - The improvement purpose must be related to the original purpose of collection under the Singapore PDPA. - Covers product and service development, operational process improvement, and learning about user behaviour under the Singapore PDPA. - Must not produce an adverse effect on the individual whose data is used under the Singapore PDPA. - Where possible, use de-identified or aggregated data to minimise privacy risk under the Singapore PDPA. - Cannot be used to make decisions specifically affecting an identified individual without a separate Singapore PDPA legal basis. ## How do I handle access and correction requests under the Singapore PDPA? The Singapore PDPA gives individuals the right to request access to their personal data held by an organisation and to request correction of data that is inaccurate, incomplete, or out of date (sections 21, 22, and 22A). These Singapore PDPA access and correction rights are fundamental to the Act's framework, and organisations must build repeatable workflows to handle them within the prescribed timelines. The PDPC Advisory Guidelines on Key Concepts devote Chapter 15 to the detailed requirements for Singapore PDPA access and correction requests. For Singapore PDPA access requests, organisations must respond as soon as reasonably possible. If the organisation cannot respond within 30 days of receiving the request, the Singapore PDPA requires it to inform the individual in writing of the time by which it will respond. The organisation may charge a reasonable fee for Singapore PDPA access requests to recover the cost of responding, but the fee must not be excessive. The organisation must provide the data in a generally understandable form and must include information about how the data has been used or disclosed within the past year before the access request. For Singapore PDPA correction requests, the organisation must correct the data and send the corrected data to every other organisation to which the data was disclosed within the year before the correction was made, unless that other organisation does not need the corrected data for any legal or business purpose. There are specific exceptions under the Singapore PDPA that allow an organisation to refuse an access or correction request, such as where providing access could reveal confidential commercial information, where the data relates to an ongoing legal proceeding, or where the burden of providing access is disproportionate to the individual's interest. Organisations should build a standardised intake, tracking, and evidence workflow for all Singapore PDPA access and correction requests. - Individuals have the right to request access to personal data and correction of errors under the Singapore PDPA. - Respond to Singapore PDPA access requests as soon as reasonably possible; inform the individual in writing if it will take longer than 30 days. - A reasonable fee may be charged to recover costs for Singapore PDPA access requests, but it must not be excessive. - Provide data in a generally understandable form and include use and disclosure information from the past year under the Singapore PDPA. - For Singapore PDPA corrections, propagate corrected data to all organisations that received the data in the past year. - Exceptions under the Singapore PDPA apply where access would reveal confidential commercial information or affect ongoing legal proceedings. - Build a standardised intake, tracking, and evidence workflow for Singapore PDPA access and correction requests. ## What are the Singapore PDPA data breach notification requirements? The Singapore PDPA mandatory data breach notification obligation came into force on 1 February 2021 as part of the 2020 amendments (sections 26A-26E). Organisations must assess a data breach as soon as they have credible grounds to believe a breach has occurred and determine whether it qualifies as a notifiable data breach under the Singapore PDPA. A data breach is notifiable under the Singapore PDPA if it results in, or is likely to result in, significant harm to affected individuals, or if it involves personal data of 500 or more individuals regardless of harm. When a data breach is notifiable under the Singapore PDPA, the organisation must notify the PDPC as soon as practicable, and in any case no later than 3 calendar days after completing its assessment that the breach is notifiable. The PDPC Advisory Guidelines illustrate that if an organisation determines on 1 January that a data breach is notifiable, it must notify the PDPC by 4 January. If the Singapore PDPA breach is likely to result in significant harm to affected individuals, the organisation must also notify those individuals as soon as practicable. The notification to the PDPC must include details such as the nature of the breach, the number of affected individuals, the types of personal data involved, the measures taken in response, and the contact details of a designated person. Significant harm under the Singapore PDPA includes physical harm, harassment, identity theft or fraud, financial loss, damage to credit or reputation, loss of employment opportunities, and other serious adverse consequences. The PDPC considers factors such as the nature of the personal data breached (for example, NRIC numbers, financial data, or medical records), whether the data is publicly available, and whether security measures such as encryption were applied. Data intermediaries processing personal data on behalf of another organisation under the Singapore PDPA are required to notify that organisation of data breaches without undue delay. - A data breach is notifiable under the Singapore PDPA if it causes or is likely to cause significant harm, or involves 500 or more individuals. - Notify the PDPC no later than 3 calendar days after completing the Singapore PDPA notifiability assessment. - If significant harm is likely under the Singapore PDPA, notify affected individuals as soon as practicable in addition to the PDPC. - Singapore PDPA significant harm includes identity theft, financial loss, reputational damage, harassment, and physical harm. - The PDPC notification for a Singapore PDPA breach must include breach details, affected data types, number of individuals, remediation steps, and a contact person. - Data intermediaries under the Singapore PDPA must notify the engaging organisation of data breaches without undue delay. - Maintain a Singapore PDPA breach response plan and run tabletop exercises to test readiness. ## What are the penalties for non-compliance with the Singapore PDPA? The PDPC has broad enforcement powers under the Singapore PDPA. Following an investigation, the PDPC may issue directions to require the organisation to stop collecting, using, or disclosing personal data in breach of the Singapore PDPA, to destroy personal data collected in breach, to comply with specific obligations, or to pay a financial penalty. The 2020 amendments to the Singapore PDPA significantly increased the maximum financial penalties available to the PDPC, aligning with the global trend toward stronger enforcement of data protection laws. For organisations with an annual turnover of more than SGD 10 million in Singapore, the maximum Singapore PDPA financial penalty is 10% of the organisation's annual turnover in Singapore. For all other organisations, the maximum Singapore PDPA financial penalty is SGD 1 million per breach. These higher Singapore PDPA penalty caps took effect on 1 February 2021. The PDPC can also accept voluntary undertakings from organisations, which are enforceable commitments to take specific remedial actions under the Singapore PDPA. Beyond financial penalties, the Singapore PDPA provides for significant reputational consequences. The PDPC publishes enforcement decisions, meaning non-compliance under the Singapore PDPA becomes part of the public record. Individuals also have a private right of action under the Singapore PDPA and can bring civil proceedings against organisations for breaches that cause them loss or damage. Criminal offences under Part 9B of the Singapore PDPA include knowing or reckless unauthorised disclosure of personal data, use of personal data for wrongful gain or loss, and re-identification of anonymised data, with penalties including fines and imprisonment. - Maximum Singapore PDPA financial penalty: 10% of annual turnover in Singapore for organisations with turnover above SGD 10 million. - Maximum Singapore PDPA financial penalty for other organisations: SGD 1 million per breach. - The PDPC can direct organisations to stop processing, destroy data collected in breach, and implement specific Singapore PDPA compliance measures. - The PDPC may accept voluntary undertakings as enforceable commitments to remediate under the Singapore PDPA. - Singapore PDPA enforcement decisions are published, creating significant reputational risk. - Individuals have a private right of action under the Singapore PDPA for civil proceedings where they suffer loss or damage. - Criminal offences under Part 9B of the Singapore PDPA carry fines and potential imprisonment for knowing or reckless mishandling. ## Does the Singapore PDPA apply to overseas organisations? The Singapore PDPA has extraterritorial reach. The definition of 'organisation' in section 2(1) of the Singapore PDPA covers any individual, company, association, or body of persons whether or not formed or recognised under Singapore law or resident or having an office or place of business in Singapore. This means that the Singapore PDPA applies to organisations that are not established in Singapore but collect, use, or disclose personal data in Singapore. The PDPC Advisory Guidelines on Key Concepts explain that the Singapore PDPA Data Protection Provisions apply to organisations carrying out activities involving personal data in Singapore. Where personal data is collected overseas and subsequently transferred into Singapore, the Singapore PDPA Data Protection Provisions apply in respect of the activities involving the personal data in Singapore. If an overseas organisation has Singapore-based customers and collects their personal data through a website, mobile application, or service directed at the Singapore market, the Singapore PDPA will generally apply to that processing. For overseas organisations subject to the Singapore PDPA, all the data protection obligations apply in the same way as for Singapore-based organisations. This includes the Singapore PDPA consent obligation, notification obligation, protection obligation, breach notification obligation, and all other obligations. Overseas organisations should assess their Singapore PDPA exposure, appoint a local Data Protection Officer or representative where appropriate, and implement a Singapore PDPA compliance programme that covers their Singapore-related data processing activities. - The Singapore PDPA applies extraterritorially to any organisation collecting, using, or disclosing personal data in Singapore. - Foreign companies with no physical presence in Singapore may be covered by the Singapore PDPA if they process personal data of individuals in Singapore. - All Singapore PDPA data protection obligations apply equally to overseas organisations handling Singapore personal data. - Assessment of Singapore PDPA applicability is based on the facts of the data processing, not just the organisation's location. - Overseas organisations should appoint a DPO or local representative to manage Singapore PDPA compliance. ## What are the Singapore PDPA NRIC collection restrictions? NRIC numbers are a permanent and irreplaceable identifier issued by the Singapore Government primarily for public administration purposes. The PDPC Advisory Guidelines on the PDPA for NRIC and Other National Identification Numbers, which took effect on 1 September 2019, impose specific restrictions on how private-sector organisations may handle NRIC numbers under the Singapore PDPA. These Singapore PDPA NRIC restrictions recognise the high risk associated with collecting a permanent, government-issued identifier that cannot be changed if compromised. Under the Singapore PDPA NRIC guidelines, private-sector organisations are only allowed to collect, use, or disclose NRIC numbers or copies of the NRIC if the collection, use, or disclosure is required by law, or if it is necessary to establish or verify an individual's identity to a high degree of accuracy. The same treatment under the Singapore PDPA extends to Birth Certificate numbers, Foreign Identification Numbers, and Work Permit numbers. While passport numbers are periodically replaced, the PDPC advises that organisations should avoid collecting the full passport numbers of individuals unless justified. An individual's physical NRIC or other identification documents containing NRIC numbers can only be retained by an organisation under the Singapore PDPA if required by law. However, checking the physical NRIC, Foreign Identity card, or passport is allowed if the organisation needs to verify an individual's particulars under the Singapore PDPA. Organisations that previously relied on NRIC numbers as general-purpose identifiers for loyalty programmes, visitor registration, or event sign-ups must transition to alternative identifiers that comply with the Singapore PDPA NRIC restrictions. - Under the Singapore PDPA, NRIC numbers may only be collected if required by law or necessary for high-accuracy identity verification. - The Singapore PDPA NRIC restrictions extend to Birth Certificate numbers, Foreign Identification Numbers, and Work Permit numbers. - Physical NRIC cards can only be retained by organisations under the Singapore PDPA if retention is required by law. - Organisations may check physical identity documents under the Singapore PDPA to verify particulars without retaining them. - Passport number collection should be avoided unless justified under the Singapore PDPA NRIC guidelines. - The Singapore PDPA NRIC advisory guidelines took effect on 1 September 2019. ## What is the Do Not Call (DNC) Registry under the Singapore PDPA? The Do Not Call (DNC) Registry is a key component of the Singapore PDPA that allows individuals in Singapore to register their Singapore telephone numbers to opt out of receiving unwanted telemarketing messages. The Singapore PDPA DNC Registry provisions came into force on 2 January 2014 and are administered by the PDPC. The DNC provisions are set out in Parts 9 and 9A of the Singapore PDPA and operate in conjunction with the Data Protection Provisions, meaning organisations must comply with both sets of Singapore PDPA provisions. There are three DNC registers under the Singapore PDPA: the No Voice Call Register, the No Text Message Register, and the No Fax Message Register. Users and subscribers may register their Singapore telephone numbers on one or more of these Singapore PDPA DNC registers depending on their preferences. Organisations that wish to send telemarketing messages must check the Singapore PDPA DNC Registry before sending any voice calls, text messages (including SMS and MMS), or fax messages for marketing purposes. Organisations must check the relevant Singapore PDPA DNC register within 30 days before sending a telemarketing message. If the recipient's number is on the applicable register, the organisation must not send the message under the Singapore PDPA unless it has obtained the individual's clear and unambiguous consent in written or other accessible form, and that consent has not been withdrawn. The Singapore PDPA also prohibits organisations from sending messages to numbers generated through address-harvesting software or dictionary attacks. Penalties for Singapore PDPA DNC violations include financial penalties of up to SGD 1 million per breach. Organisations should integrate Singapore PDPA DNC checking into their CRM and marketing automation systems with audit logging. - The Singapore PDPA DNC Registry allows individuals to opt out of telemarketing calls, text messages, and faxes. - Three Singapore PDPA DNC registers: No Voice Call, No Text Message, and No Fax Message. - Organisations must check the Singapore PDPA DNC Registry within 30 days before sending any telemarketing message. - If a number is registered, the organisation must not contact it under the Singapore PDPA unless it has clear and unambiguous consent. - The Singapore PDPA prohibits sending messages to numbers obtained through address-harvesting software or dictionary attacks. - Penalties for Singapore PDPA DNC violations can reach SGD 1 million per breach. - Integrate Singapore PDPA DNC checking into CRM and marketing automation systems with audit logging. ## How do cross-border data transfers work under the Singapore PDPA? The Singapore PDPA Transfer Limitation Obligation (section 26) requires organisations to ensure that personal data transferred outside Singapore receives a standard of protection that is comparable to the protection under the Singapore PDPA. This Singapore PDPA obligation applies whenever an organisation sends or makes accessible personal data to a recipient outside Singapore, including transfers to cloud service providers, group companies, and third-party vendors in other jurisdictions. The PDPC Advisory Guidelines dedicate Chapter 19 to the detailed requirements for Singapore PDPA cross-border transfers. There are several mechanisms to satisfy the Singapore PDPA transfer limitation obligation. The most common are: ensuring the recipient is bound by legally enforceable obligations (such as a contract, binding corporate rules, or other legally binding instrument) to provide a comparable standard of protection; transferring to a jurisdiction that provides comparable protection; or obtaining the individual's consent after informing them of the risks of transfer to a jurisdiction without comparable protection under the Singapore PDPA. The onus is on the transferring organisation to undertake appropriate due diligence and obtain assurances. In practice, most organisations use contractual clauses to bind overseas recipients to Singapore PDPA-equivalent data protection standards. The contract should cover the purposes of processing, security measures, breach notification procedures, data retention and deletion requirements, and sub-processing controls. The PDPC Advisory Guidelines note that where an organisation engages a data intermediary that transfers data overseas, the organisation remains responsible for complying with the Singapore PDPA Transfer Limitation Obligation. Organisations should maintain a transfer map documenting all cross-border data flows, the recipient organisations and jurisdictions, the transfer mechanism used, and the contractual safeguards in place for Singapore PDPA compliance. - Personal data transferred outside Singapore must receive a comparable standard of protection to the Singapore PDPA. - Common Singapore PDPA transfer mechanisms: contractual obligations, binding corporate rules, or transfer to a jurisdiction with comparable protection. - Consent-based transfers under the Singapore PDPA require informing the individual of the destination jurisdiction's risks. - Contracts for Singapore PDPA transfers should cover processing purposes, security, breach notification, retention, deletion, and sub-processing. - Organisations remain responsible for Singapore PDPA transfer compliance even when using data intermediaries that transfer data overseas. - Maintain a transfer map of all cross-border data flows for Singapore PDPA compliance. - Cloud service providers in other jurisdictions are subject to the Singapore PDPA transfer limitation obligation. ## What is a Data Protection Officer (DPO) and is one required under the Singapore PDPA? Under the Singapore PDPA Accountability Obligation (sections 11 and 12), every organisation is required to designate at least one individual as its Data Protection Officer (DPO). This is a mandatory Singapore PDPA requirement -- unlike some other data protection laws where DPO appointment is conditional, the Singapore PDPA requires all organisations handling personal data to have a DPO. The PDPC Advisory Guidelines on Key Concepts address the DPO requirement in Chapter 21 on the Accountability Obligation. The Singapore PDPA DPO's role is to ensure the organisation meets its obligations under the Act. Responsibilities typically include developing and implementing data protection policies and practices, communicating those policies to staff and the public, handling Singapore PDPA access and correction requests, managing data breach responses, conducting or overseeing training programmes, and serving as the contact point for the PDPC and for individuals. The Singapore PDPA requires that the DPO's business contact information must be made available to the public. The Singapore PDPA does not prescribe specific qualifications for the DPO, but the individual should have sufficient knowledge of the Act and the organisation's data processing activities to carry out the role effectively. In smaller organisations, the Singapore PDPA DPO role may be filled by an existing staff member alongside other duties. In larger organisations, a dedicated DPO or data protection team may be needed. Organisations can outsource the Singapore PDPA DPO function to an external service provider, but the organisation retains legal responsibility for compliance regardless of whether the DPO function is outsourced. - Every organisation subject to the Singapore PDPA must designate at least one Data Protection Officer (DPO). - The Singapore PDPA DPO is responsible for ensuring compliance, managing requests, and coordinating breach responses. - The DPO's business contact information must be publicly available under the Singapore PDPA. - No specific qualifications are prescribed by the Singapore PDPA, but sufficient knowledge and operational understanding are expected. - The Singapore PDPA DPO role can be assigned to an existing staff member or outsourced to an external provider. - The organisation retains legal responsibility for Singapore PDPA compliance regardless of whether the DPO function is outsourced. - Publish the Singapore PDPA DPO's contact details on your website and in your privacy notice. ## How does the Singapore PDPA compare to the EU GDPR? The Singapore PDPA and the EU GDPR share the same foundational goal of protecting individuals' personal data, and they have several overlapping concepts. Both require a lawful basis for processing personal data, grant individuals rights of access and correction, impose data breach notification requirements, and require organisations to implement appropriate security measures. Both the Singapore PDPA and the GDPR also have extraterritorial reach, applying to organisations outside their respective jurisdictions when processing data of individuals within their territory. However, there are significant differences in scope, legal bases, and enforcement between the Singapore PDPA and the GDPR. The GDPR defines six lawful bases for processing (including consent, contract, legal obligation, vital interests, public task, and legitimate interests), while the Singapore PDPA primarily uses a consent-based model supplemented by exceptions such as deemed consent, the legitimate interests exception, and the business improvement exception. The GDPR includes a specific category of special categories of personal data (such as health, biometric, and racial data) with additional protections, while the Singapore PDPA does not formally define special categories but applies stricter practical expectations to sensitive data in PDPC enforcement decisions. On breach notification, the GDPR requires notification to the supervisory authority within 72 hours, while the Singapore PDPA requires notification within 3 calendar days after completing the assessment that the breach is notifiable. GDPR penalties can reach EUR 20 million or 4% of global annual turnover, while Singapore PDPA penalties reach SGD 1 million or 10% of Singapore turnover. The GDPR requires a Data Protection Impact Assessment (DPIA) for high-risk processing, while the Singapore PDPA does not have a formal DPIA requirement but does require assessments for deemed consent by notification (Annex B) and the legitimate interests exception (Annex C). Organisations operating in both jurisdictions should map the overlap between the Singapore PDPA and GDPR and build a unified compliance framework that satisfies both regimes. - Both the Singapore PDPA and GDPR require a lawful basis, individual rights, breach notification, and security measures. - GDPR has six lawful bases; the Singapore PDPA is consent-centric with specific exceptions (deemed consent, legitimate interests, business improvement). - GDPR defines special categories of data with extra protections; the Singapore PDPA does not formally define special categories. - GDPR breach notification: 72 hours to the authority; Singapore PDPA: 3 calendar days after completing the notifiability assessment. - GDPR penalties: up to EUR 20 million or 4% of global turnover; Singapore PDPA: up to SGD 1 million or 10% of Singapore turnover. - GDPR mandates DPIAs for high-risk processing; the Singapore PDPA requires assessments for deemed consent by notification and legitimate interests. - Build a unified compliance framework when operating under both the Singapore PDPA and GDPR to reduce duplication. *Recommended next step* *Placement: after the FAQ section* ## Use Singapore PDPA FAQ as a cited research workflow Research Copilot can take Singapore PDPA FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on Singapore PDPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Singapore PDPA FAQ](/solutions/research-copilot.md): Start from Singapore PDPA FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Singapore PDPA](/contact.md): Review your current process, evidence gaps, and next steps for Singapore PDPA FAQ. ## Primary sources - [Personal Data Protection Act 2012 (Singapore) -- official text](https://sso.agc.gov.sg/Act/PDPA2012?ref=sorena.io) - Primary legislation governing collection, use, disclosure, protection, retention, transfer, and accountability for personal data in Singapore. - [PDPC -- PDPA overview](https://www.pdpc.gov.sg/overview-of-pdpa/pdpa-overview?ref=sorena.io) - Official PDPC overview of PDPA obligations, key concepts, and development timeline. - [PDPC -- Advisory Guidelines on Key Concepts in the PDPA (revised 16 May 2022)](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-the-personal-data-protection-act?ref=sorena.io) - Core interpretation guidance for consent, deemed consent, legitimate interests, purpose limitation, notification, access/correction, accuracy, protection, retention, transfers, breach notification, and accountability. - [PDPC -- Advisory Guidelines on NRIC and Other National Identification Numbers](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-the-personal-data-protection-act-for-nric-and-other-national-identification-numbers?ref=sorena.io) - Restrictions on collection, use, disclosure, and retention of NRIC numbers, Birth Certificate numbers, Foreign Identification Numbers, and Work Permit numbers effective 1 September 2019. - [PDPC -- Enforcement advisory guidelines](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-enforcement-of-data-protection-provisions?ref=sorena.io) - Enforcement approach, directions, financial penalties, voluntary undertakings, and private right of action. ## Related Topic Guides - [Singapore PDPA Applicability Test | Does the PDPA Apply to Your Organisation?](/artifacts/apac/singapore-pdpa/applicability-test.md): Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation. - [Singapore PDPA Breach Notification Playbook - Complete Guide](/artifacts/apac/singapore-pdpa/breach-notification-playbook.md): Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline. - [Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026)](/artifacts/apac/singapore-pdpa/checklist.md): Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules. - [Singapore PDPA Compliance Deadlines and Calendar](/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar.md): Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows. - [Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM](/artifacts/apac/singapore-pdpa/compliance.md): Complete Singapore PDPA compliance guide for organisations. - [Singapore PDPA Consent and Notification Obligations Guide](/artifacts/apac/singapore-pdpa/consent-notification-and-purposes.md): Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception. - [Singapore PDPA Cross-Border Transfer Rules | Section 26 Data Transfer Compliance](/artifacts/apac/singapore-pdpa/cross-border-transfers.md): Complete guide to Singapore PDPA cross-border transfer compliance under Section 26. - [Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide](/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages.md): Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses. - [Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions](/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases.md): Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover. - [Singapore PDPA Penalties and Fines | SGD 1M or 10% Turnover Cap + PDPC Enforcement Guide](/artifacts/apac/singapore-pdpa/penalties-and-fines.md): Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions. - [Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide](/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template.md): Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions. - [Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC)](/artifacts/apac/singapore-pdpa/requirements.md): Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18). - [Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations](/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries.md): Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion. - [Singapore PDPA Vendor Outsourcing and Contracts Guide](/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts.md): Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence. - [Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties](/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr.md): Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/singapore-pdpa/faq --- --- title: "Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions" canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases" source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases" author: "Sorena AI" description: "Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Singapore PDPA penalties" - "Singapore PDPA enforcement" - "PDPC enforcement decisions" - "PDPA financial penalty" - "Singapore PDPA fines" - "PDPC directions" - "PDPA undertakings" - "PDPC investigation process" - "Singapore PDPA enforcement cases" - "PDPA section 48J" - "Singapore PDPA 10 percent turnover penalty" - "PDPC active enforcement" - "data protection appeal panel Singapore" - "PDPA criminal offences" - "PDPA expedited decision procedure" - "PDPC voluntary undertaking" - "PDPA mitigating factors" - "PDPA aggravating factors" - "PDPC breach findings" - "Singapore PDPA compliance guide" - "Singapore PDPA penalty framework" - "PDPC penalty calibration" - "Singapore data breach penalty" - "SingHealth PDPA penalty" - "IHiS PDPA fine" - "Aviva PDPA enforcement" - "PDPA SGD 1 million" - "PDPA turnover cap" - "PDPC enforcement outcomes" - "Singapore PDPA" - "PDPC fines" - "PDPA enforcement cases" - "APAC privacy" - "data protection Singapore" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover. *Artifact Guide* *APAC* ## Singapore PDPA Penalties and enforcement cases Singapore PDPA penalties and enforcement cases explained: financial penalty framework up to SGD 1 million or 10% of annual turnover, real PDPC enforcement decisions with penalty amounts, undertakings, and practical guidance on responding to Singapore PDPA investigations. Turn published PDPC enforcement lessons into concrete compliance controls and evidence improvements for your organisation. This guide covers Singapore PDPA penalties and enforcement cases in detail. It is written for compliance officers, data protection officers, legal counsel, and security teams who need to understand how the Personal Data Protection Commission (PDPC) enforces the Singapore Personal Data Protection Act (PDPA). You will find the financial penalty framework, real enforcement decisions with penalty amounts, the voluntary undertaking process, the Expedited Decision Procedure, penalty calibration factors with case examples, the appeals process, criminal offences, and step-by-step guidance on responding to a PDPC investigation. All content is grounded in the PDPC's Advisory Guidelines on Enforcement of Data Protection Provisions (revised 1 October 2022) and the Guide on Active Enforcement (revised 1 October 2022). Use these Singapore PDPA enforcement lessons to benchmark your own controls, policies, and evidence packs. ## Singapore PDPA financial penalty framework: up to SGD 1 million or 10% of annual turnover Under section 48J of the Singapore PDPA, the PDPC can impose financial penalties on any organisation that intentionally or negligently contravenes the Data Protection Provisions. Following the enforcement amendments that took effect on 1 October 2022, the maximum Singapore PDPA penalty is SGD 1 million or 10% of the organisation's annual turnover in Singapore, whichever is higher. The 10% turnover-based cap applies only where the organisation's annual local turnover exceeds SGD 10 million. For organisations below that revenue threshold, the fixed SGD 1 million ceiling remains the maximum Singapore PDPA penalty. The turnover-based Singapore PDPA penalty cap was introduced to close a gap that allowed very large organisations to treat the previous fixed SGD 1 million limit as a manageable cost of doing business. Under the revised Singapore PDPA enforcement framework, a multinational processing personal data at scale in Singapore faces meaningfully higher financial exposure that is proportionate to both its revenue and the volume of data it handles. The PDPC confirmed in its October 2022 announcement that the enhanced financial penalty cap strengthens deterrence and aligns Singapore PDPA enforcement with its data protection objectives. For contraventions of the Do Not Call (DNC) Provisions involving dictionary attacks or address-harvesting software, individuals face Singapore PDPA penalties of up to SGD 200,000 and organisations face penalties of up to SGD 1 million or 5% of annual turnover in Singapore (where turnover exceeds SGD 20 million), whichever is higher. Other DNC contraventions carry a maximum of SGD 200,000 for individuals and SGD 1 million for organisations. These separate DNC penalty ceilings sit alongside the Data Protection Provisions penalties. An organisation's annual turnover for the purpose of Singapore PDPA penalty calculation is determined from the most recent audited accounts available at the time the penalty is imposed, as specified in section 48J(5A) of the PDPA. Organisations should maintain up-to-date audited financial statements so that the PDPC can accurately assess the relevant turnover figure. Financial penalties under the Singapore PDPA are payable within a specified period, which will be no earlier than 28 days after the notice is issued. - Maximum Singapore PDPA penalty for Data Protection Provisions: SGD 1 million or 10% of Singapore annual turnover (whichever is higher), where turnover exceeds SGD 10 million. - Maximum Singapore PDPA penalty for DNC dictionary attacks / address harvesting: SGD 1 million or 5% of Singapore annual turnover (whichever is higher), where turnover exceeds SGD 20 million. - Individual DNC penalties under the Singapore PDPA can reach SGD 200,000. - Turnover is based on the most recent audited accounts at the time the Singapore PDPA penalty is imposed (section 48J(5A)). - Singapore PDPA financial penalty payment deadline is no earlier than 28 days after the notice. - The revised turnover-based penalty caps took effect on 1 October 2022. - The PDPC first considers whether directions without financial penalties are sufficient to remedy the breach before imposing a Singapore PDPA penalty. ## Singapore PDPA enforcement powers and PDPC directions The PDPC holds broad Singapore PDPA enforcement powers categorised into four types: powers relating to alternative dispute resolution, powers relating to reviews, powers relating to investigations, and powers relating to voluntary undertakings. When considering whether and how to exercise these Singapore PDPA enforcement powers, the PDPC is guided by two objectives: facilitating resolution of an individual's complaint, and ensuring that organisations comply with their obligations and take corrective measures in a timely manner. Under section 48I of the Singapore PDPA, the PDPC may issue directions to secure compliance. These directions typically fall into three categories under Singapore PDPA enforcement practice: directions to remedy the contravention (for example, requiring the organisation to cease using personal data collected without consent), directions to prevent or reduce harm to affected individuals, and directions to rectify the organisation's processes to bring it into compliance. The PDPC may also direct an organisation to stop collecting, using, or disclosing personal data in contravention of the PDPA, or to destroy personal data collected in breach of the Singapore PDPA. The Singapore PDPA enforcement process is structured to ensure procedural fairness. Before issuing a final decision, the PDPC issues a preliminary decision containing its preliminary findings, the evidence on which those findings are based, the reasons for the decision, and any proposed directions or financial penalty. The organisation then has 14 days to make written representations, supported by relevant documents. The PDPC will consider these representations before issuing its final decision. Extensions may be granted in exceptional circumstances upon written application. Directions issued by the PDPC under Singapore PDPA enforcement can be registered in the District Court under section 48M of the PDPA. A registered direction has the same force and effect as a court order. This means the PDPC can take legal proceedings to enforce compliance with its directions, giving the Singapore PDPA enforcement framework real legal teeth. The PDPC may also commence investigations of its own motion, not only upon receiving complaints. - Four categories of Singapore PDPA enforcement powers: alternative dispute resolution, reviews, investigations, and voluntary undertakings. - Section 48I directions can require organisations to stop collecting, using, or disclosing personal data, or to destroy personal data collected in breach of the Singapore PDPA. - Preliminary decision process gives organisations 14 days to make written representations before a final Singapore PDPA enforcement decision. - PDPC directions can be registered in the District Court for enforcement as court orders under Singapore PDPA section 48M. - The PDPC may commence Singapore PDPA investigations of its own motion, without a complaint. - Singapore PDPA investigation powers include requiring production of documents, oral examination under paragraph 1A of the Ninth Schedule, and entry of premises (with or without a warrant). - Organisations are advised to provide the PDPC with copies of any intended media releases about alleged breaches before publication to avoid hindering ongoing Singapore PDPA investigations. *Recommended next step* *Placement: after the enforcement section* ## Use Singapore PDPA Penalties and enforcement cases as a cited research workflow Research Copilot can take Singapore PDPA Penalties and enforcement cases from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on Singapore PDPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Singapore PDPA Penalties and enforcement cases](/solutions/research-copilot.md): Start from Singapore PDPA Penalties and enforcement cases and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Singapore PDPA](/contact.md): Review your current process, evidence gaps, and next steps for Singapore PDPA Penalties and enforcement cases. ## Singapore PDPA enforcement outcomes: undertakings as an alternative to formal investigation Under section 48L of the Singapore PDPA, the PDPC may accept a voluntary undertaking from an organisation that has not complied, is not complying, or is likely not to comply with the Data Protection Provisions. An undertaking allows the organisation to implement a remediation plan that addresses not only the immediate breach but also any systemic shortcomings. The execution of a voluntary undertaking does not amount to an admission of breach of the Singapore PDPA. The PDPC introduced this power as part of the enforcement amendments that took effect on 1 February 2021. The voluntary undertaking process under Singapore PDPA enforcement is designed for organisations that demonstrate good accountability practices and have an effective remediation plan ready. To be eligible, the organisation must generally show that it has accountable policies and practices in place (for example, IMDA Data Protection Trustmark certification or effective monitoring and breach management systems) and must present a remediation plan that explains the likely causes of the incident, the proposed steps to address those causes, and the targeted completion dates. The request must be made soon after the incident becomes known, typically upon commencement of or early in the investigation. As of January 2026, the PDPC has published over 100 voluntary undertakings on its website, covering organisations across sectors including technology, healthcare, finance, hospitality, retail, logistics, and professional services. Notable Singapore PDPA enforcement undertakings include Grabcar Pte Ltd (September 2020), HSBC Bank (Singapore) Limited (September 2020), Starbucks Coffee Singapore Pte Ltd (November 2023), Singhealth Polyclinics (June 2022), Shangri-La Hotel Ltd (September 2024), Coca-Cola Singapore Beverages Pte Ltd (August 2024), Ticketmaster Singapore Pte Ltd (May 2024), and Manulife (Singapore) Pte Ltd (April 2021). The PDPC is unlikely to accept a voluntary undertaking under Singapore PDPA enforcement if the organisation refutes responsibility for the incident, it is a repeat incident with similar causes, the remediation plan does not explain how compliance will be achieved, the organisation requests extended time to produce a remediation plan, or the breach is wilful or egregious. Non-compliance with undertaking terms can lead to the PDPC issuing directions to enforce the terms or instituting a full investigation that could result in directions and financial penalties. - Voluntary undertakings are governed by section 48L of the Singapore PDPA and do not constitute an admission of breach. - Eligibility requires accountable policies, effective monitoring systems, and a ready remediation plan submitted early in the investigation. - Over 100 voluntary undertakings have been published by the PDPC as of January 2026, spanning technology, healthcare, finance, hospitality, retail, and logistics sectors. - Notable undertakings include Grabcar, HSBC Bank Singapore, Starbucks Coffee Singapore, Singhealth Polyclinics, Shangri-La Hotel, Coca-Cola Singapore Beverages, Ticketmaster Singapore, and Manulife Singapore. - Non-compliance with undertaking terms can trigger PDPC directions enforcing the terms or a full investigation with potential Singapore PDPA penalties. - The PDPC may still publicise the voluntary undertaking while conducting a full investigation into the incident. - Estimated timeline for undertaking closure: 2-4 months, compared to 4-18 months for full investigations under Singapore PDPA enforcement. ## Singapore PDPA active enforcement framework and proactive investigations The PDPC's Active Enforcement Framework, revised on 1 October 2022, articulates how the PDPC deploys its Singapore PDPA enforcement powers to act effectively and efficiently on data breach incidents. The framework is guided by four key objectives: responding effectively to breaches that affect large groups of individuals or involve data likely to cause significant harm, being proportionate and consistent in enforcement actions, ensuring Singapore PDPA penalties serve as effective deterrents, and making sure organisations that breach the PDPA take proper corrective steps. Not all complaints and incidents receive a full investigation under Singapore PDPA enforcement. The PDPC uses a triage approach where low-impact incidents may result in discontinuation of the investigation and an advisory notice. Advisory notices are not findings of breach; they highlight areas where an organisation can improve its PDPA compliance. For example, the Guide on Active Enforcement illustrates that sending a mass email with addresses in the To field instead of Bcc, affecting a small group, may lead to an advisory notice rather than a formal finding if the impact is limited. For incidents assessed as high impact under Singapore PDPA enforcement, particularly those where a large number of individuals is affected or the personal data disclosed could cause significant harm, the PDPC will launch a full investigation immediately. Full investigations follow a structured process: fact-gathering (document production notices under paragraph 1 of the Ninth Schedule, interviews and statements under paragraph 1A, site visits), issuance of a preliminary decision, opportunity for the organisation to make representations, and issuance of the final decision. Full Singapore PDPA investigations can take from 4 to 18 months depending on the complexity and the level of cooperation from the organisation. The Expedited Decision Procedure (EDP) allows Singapore PDPA investigations to be completed in a significantly shorter timeframe of approximately 2 to 5 months. To use the EDP, an organisation must provide an upfront voluntary admission of liability at an early stage, supply all relevant facts and evidence of the incident including internal and external forensic reports, and confirm its willingness to comply with directions and any financial penalty. The PDPC considers voluntary admission of liability through the EDP as a favorable factor when determining the Singapore PDPA financial penalty, except where the organisation is a repeat offender. - Four objectives guide Singapore PDPA enforcement: effective response, proportionate action, effective deterrence, and corrective compliance. - Low-impact incidents may be discontinued with an advisory notice rather than a formal finding of breach under Singapore PDPA enforcement. - High-impact incidents involving many affected individuals or sensitive data trigger immediate full Singapore PDPA investigations. - Estimated investigation timelines: discontinuation (1-3 months), undertaking (2-4 months), expedited decision (2-5 months), full investigation (4-18 months). - The EDP requires voluntary admission of liability, full factual disclosure including forensic reports, and agreement to comply with the Singapore PDPA enforcement outcome. - The PDPC may refer matters to facilitation, mediation, or other regulatory authorities (MAS, MOH) before opening a formal Singapore PDPA investigation. - Singapore PDPA enforcement decisions are published on the PDPC website with confidential information redacted at the PDPC's discretion. ## Notable Singapore PDPA enforcement decisions and penalty amounts PDPC enforcement decisions serve as a practical library of Singapore PDPA compliance lessons. Each published decision explains the facts of the breach, the PDPA provisions contravened, the PDPC's reasoning, and the directions or financial penalties imposed. The SingHealth and Integrated Health Information Systems (IHiS) case ([2019] SGPDPC 3) remains the most significant Singapore PDPA enforcement decision. It involved the exfiltration of personal data of approximately 1.5 million patients, including outpatient dispensed medication records of certain individuals. The PDPC imposed the then-highest Singapore PDPA penalties: SGD 750,000 on IHiS and SGD 250,000 on SingHealth, totalling SGD 1 million. Key factors included the high number of affected individuals, the high sensitivity of health data, and serious security lapses by both organisations. In the Aviva Ltd case ([2018] SGPDPC 4), disclosure of sensitive personal data including medical conditions and insurance sums assured was treated as an aggravating factor under Singapore PDPA enforcement. The fact that Aviva had encountered a similar incident previously -- a breach involving Aviva Ltd and Toh-Shi Printing Singapore Pte Ltd ([2016] SGPDPC 15) within about a year before -- further increased the Singapore PDPA penalty. This illustrates that repeat breaches of a similar pattern are viewed very seriously and will result in escalated financial penalties under Singapore PDPA enforcement. Profiteering cases attract particularly harsh treatment under Singapore PDPA enforcement. In Sharon Assya Qadriyah Tang ([2018] SGPDPC 1), the sale of personal data for profit was taken as a significant aggravating factor. In Amicus Solutions Pte. Ltd. and Ivan Chua Lye Kiat ([2019] SGPDPC 33), the PDPC emphasised that profiting from the unauthorised sale of personal data without consent was the kind of activity the Singapore PDPA sought to curb and would be dealt with severely. The PDPC warned that any profits from the unauthorised sale of personal data may be taken into account in calculating the Singapore PDPA penalty. Several Singapore PDPA enforcement decisions highlight how security negligence drives penalties upward. In Ninja Logistics Pte Ltd ([2019] SGPDPC 39), the organisation was aware of the risks of unauthorised access through its tracking page but failed to resolve the vulnerability for more than 2 years -- treated as aggravating. In SPH Magazines Pte Ltd ([2020] SGPDPC 3), a compromised password unchanged for 10 years and undetected unauthorised access for approximately 2 years were both aggravating factors. These Singapore PDPA enforcement decisions demonstrate that the PDPC expects organisations to detect and remediate known vulnerabilities promptly. - SingHealth/IHiS ([2019] SGPDPC 3): SGD 750,000 penalty on IHiS and SGD 250,000 on SingHealth for the exfiltration of 1.5 million patient records -- the highest combined Singapore PDPA penalty at the time. - Aviva Ltd ([2018] SGPDPC 4): repeat breach with sensitive medical and insurance data disclosure treated as aggravating under Singapore PDPA enforcement, following a similar incident in [2016] SGPDPC 15. - Ninja Logistics ([2019] SGPDPC 39): failure to fix a known vulnerability for over 2 years was an aggravating factor in the Singapore PDPA penalty calibration. - SPH Magazines ([2020] SGPDPC 3): a compromised password unchanged for 10 years and undetected unauthorised access for 2 years were aggravating factors under Singapore PDPA enforcement. - Sharon Assya Qadriyah Tang ([2018] SGPDPC 1) and Amicus Solutions / Ivan Chua Lye Kiat ([2019] SGPDPC 33): profiteering from sale of personal data was a severe aggravating factor. - Option Gift ([2019] SGPDPC 10): a lower Singapore PDPA penalty was imposed where the breach affected 426 individuals and involved less sensitive data (email addresses, delivery addresses, mobile numbers). - Singapore Telecommunications ([2019] SGPDPC 49): prompt action to implement a temporary fix within 11 hours was treated as a mitigating factor in the Singapore PDPA penalty calibration. ## Factors the PDPC considers when determining Singapore PDPA penalties Section 48J(6) of the Singapore PDPA sets out the factors the PDPC must consider when determining the amount of a financial penalty. The PDPC follows a structured three-step approach grounded in the Advisory Guidelines on Enforcement and the Guide on Active Enforcement: first assess harm and culpability, then consider aggravating and mitigating factors, and finally adjust the Singapore PDPA penalty for proportionality and impact on the organisation. Harm under the Singapore PDPA penalty framework is assessed based on the number of affected individuals, the categories and sensitivity of the personal data involved, and the duration of the incident. A breach exposing NRIC numbers, medical records, or insurance details of thousands of individuals will attract a higher Singapore PDPA penalty than one involving email addresses of a small group. Culpability refers to the organisation's conduct in the incident, including the nature of the specific breach and the organisation's overall compliance posture with the PDPA. In Institute of Singapore Chartered Accountants ([2018] SGPDPC 28), unauthorised disclosure limited to a single recipient for 10 minutes was a mitigating factor. The PDPC then considers additional factors that may increase or decrease the Singapore PDPA penalty. These include whether the organisation took timely and effective action to mitigate the effects (Singapore Telecommunications: temporary fix within 11 hours was mitigating), whether it had previously failed to comply with the PDPA (Aviva Ltd: repeat breach pattern was aggravating), whether there was voluntary admission of liability through the EDP, whether the organisation cooperated with the PDPC during the investigation, and whether it is a first-time offender. Pre-existing compliance measures also receive credit: Propnex Realty ([2017] SGPDPC 1) had data protection policies known to staff and annual internal audits; ComGateway ([2017] SGPDPC 19) conducted regular penetration tests, vulnerability tests, and code reviews. Finally, the PDPC adjusts the Singapore PDPA penalty by considering its likely impact on the organisation, including the ability of the organisation to continue its usual activities. In O2 Advertising Pte. Ltd. ([2019] SGPDPC 32), the penalty was reduced after considering the organisation's massive financial loss of SGD 3.2 million due to fraud and the personal circumstances of its elderly 72-year-old sole owner. In Advance Home Tutors ([2019] SGPDPC 35), the penalty was reduced to avoid imposing a crushing burden on a small home business. These decisions show that the PDPC aims for proportionality in Singapore PDPA enforcement rather than maximum punishment. - Step 1 - Harm and culpability: assess the number of affected individuals, data sensitivity, duration, and the organisation's conduct under the Singapore PDPA penalty framework. - Step 2 - Aggravating factors: repeat offences (Aviva Ltd [2018] SGPDPC 4), failure to address known vulnerabilities (Ninja Logistics [2019] SGPDPC 39), profiteering from personal data (Sharon Assya Qadriyah Tang [2018] SGPDPC 1), prolonged non-compliance. - Step 2 - Mitigating factors: prompt remediation (Singapore Telecommunications: 11-hour fix), voluntary admission of liability via EDP, cooperation with the PDPC, first-time offender status, robust pre-existing compliance measures (Propnex Realty, ComGateway). - Step 3 - Proportionality: adjust the Singapore PDPA penalty considering its impact on the organisation's viability and whether it is effective for deterrence. - Institute of Singapore Chartered Accountants ([2018] SGPDPC 28): disclosure limited to one recipient for 10 minutes was mitigating. - O2 Advertising ([2019] SGPDPC 32): Singapore PDPA penalty reduced due to dire financial circumstances including SGD 3.2 million fraud loss. - DS Human Resource ([2019] SGPDPC 16): penalty maintained despite SME status, to convey that good data protection must be adopted from the onset of digitalisation. ## Appeals process under Singapore PDPA enforcement: Data Protection Appeal Panel and courts Section 48Q of the Singapore PDPA provides that an organisation or person aggrieved by a PDPC decision or direction may appeal to the Chairman of the Data Protection Appeal Panel. The appeal must be filed within 28 days of the issuance of the Singapore PDPA enforcement decision or direction. Before appealing, organisations may also apply to the PDPC for reconsideration of the decision under section 48N, which must also be filed within 28 days. The reconsideration process under Singapore PDPA enforcement is handled by the PDPC itself. The application must set out the grounds for reconsideration, identifying any error of fact, error of law, or dispute with the PDPC's exercise of discretion. The prescribed fee is SGD 25 for decisions under section 48H(2) (reviews) and SGD 250 for all other Singapore PDPA enforcement decisions. Making an application for reconsideration does not suspend the effect of the contested decision, except in respect of a financial penalty -- meaning organisations do not have to pay the Singapore PDPA penalty while reconsideration is pending. If reconsideration is sought, any pending appeal to the Data Protection Appeal Panel on the same Singapore PDPA enforcement decision is deemed withdrawn. The PDPC may affirm, revoke, or vary the contested decision upon reconsideration. There is no further reconsideration of a reconsideration decision, but the organisation may appeal the reconsideration outcome to the Data Protection Appeal Panel. The Data Protection Appeal Committee hearing a Singapore PDPA enforcement appeal may remit the matter to the PDPC, impose or revoke or vary a financial penalty, give any direction the PDPC could have given, or make any decision the PDPC could have made. Beyond that, appeals on a point of law or as to the amount of a Singapore PDPA financial penalty can be made to the General Division of the High Court under section 48R, and from the High Court to the Court of Appeal. This multi-tier system ensures that organisations have meaningful opportunities to challenge Singapore PDPA enforcement decisions. - Appeal to the Data Protection Appeal Panel must be filed within 28 days of the Singapore PDPA enforcement decision. - Reconsideration application to the PDPC is also within 28 days, with fees of SGD 25 (review decisions) or SGD 250 (all other Singapore PDPA decisions). - Filing a reconsideration application automatically withdraws any pending appeal on the same Singapore PDPA enforcement matter. - Singapore PDPA financial penalties are suspended while reconsideration or appeal is pending; other directions are not suspended unless the PDPC or Appeal Committee decides otherwise. - The Data Protection Appeal Committee can affirm, vary, or revoke PDPC decisions and Singapore PDPA penalties. - Further appeals to the High Court are available on a point of law or as to the Singapore PDPA financial penalty amount under section 48R. - High Court decisions on Singapore PDPA enforcement can be further appealed to the Court of Appeal under the Rules of Court. ## Criminal offences and private right of action under the Singapore PDPA The Singapore PDPA creates several criminal offences that can result in prosecution and carry personal liability for individuals. Any individual who obstructs or impedes the PDPC in the exercise of its investigation powers commits an offence under the Singapore PDPA. This includes refusing to comply with a notice to produce documents or information under paragraph 1 of the Ninth Schedule, refusing to attend before the PDPC when required under paragraph 1A, or refusing to answer questions during an oral examination. Knowingly or recklessly making a false statement to the PDPC is also a criminal offence under the Singapore PDPA, as is knowingly attempting to mislead the PDPC during an investigation. These provisions ensure that organisations and their officers cannot obstruct or undermine the Singapore PDPA investigation process without facing personal criminal liability, separate from any enforcement action against the organisation itself. Additionally, section 48O of the Singapore PDPA provides individuals with a private right of action. Any person who suffers loss or damage directly as a result of an organisation's contravention of the Data Protection Provisions may commence civil proceedings in the courts. The court may grant an injunction, a declaration, damages, or any other relief it considers appropriate. However, no private action under the Singapore PDPA may be brought while a PDPC decision on the same contravention is still subject to appeal or reconsideration. Organisations should train staff on their obligations during PDPC investigations to reduce the risk of Singapore PDPA criminal offences. All employees who may interact with PDPC inspectors or receive document production notices should understand that non-compliance or providing false information can lead to criminal charges against them personally. The PDPC's investigation powers include entry of premises without a warrant (with at least 2 working days' notice) and entry with a court warrant where there are grounds to suspect documents would be concealed, removed, tampered with, or destroyed. - Obstructing or impeding the PDPC during an investigation is a criminal offence under the Singapore PDPA. - Knowingly making false statements or attempting to mislead the PDPC is a criminal offence under the Singapore PDPA. - Non-compliance with document production notices or attendance requirements under the Singapore PDPA carries personal criminal liability. - Section 48O of the Singapore PDPA provides individuals with a private right of action for loss or damage caused by PDPA contraventions. - Courts in private actions under the Singapore PDPA can award injunctions, declarations, damages, and other relief. - No private action under the Singapore PDPA may be commenced until the PDPC's decision on the same contravention becomes final (no further right of appeal or reconsideration). - PDPC entry without a warrant requires at least 2 working days' notice; entry with a warrant can be authorised where documents may be concealed or destroyed. ## Singapore PDPA enforcement: mitigating factors, compliance credit, and penalty reduction The PDPC's Singapore PDPA enforcement decisions consistently show that organisations with strong pre-existing compliance measures receive credit in penalty calibration. In Propnex Realty Pte Ltd ([2017] SGPDPC 1), the PDPC considered that the organisation had a data protection policy known to agents and staff, and that its in-house compliance team with external consultants had been conducting annual internal audits to assess system access risk, data integrity risk, and configuration issues. In ComGateway (S) Pte. Ltd. ([2017] SGPDPC 19), regular penetration tests, vulnerability tests, and code reviews were treated as a mitigating factor in calibrating the Singapore PDPA penalty. Prompt and effective remediation after a breach is one of the most consistently recognized mitigating factors in Singapore PDPA enforcement. Singapore Telecommunications received credit for implementing a temporary fix within 11 hours in [2019] SGPDPC 49. XDEL Singapore received credit for quickly rectifying a code-checking function on its notification webpage in [2019] SGPDPC 37. In Creative Technology Ltd ([2020] SGPDPC 1), the PDPC treated the organisation's effort of going through email logs to determine the number of affected users -- even after deleting the database -- as mitigating. The key in Singapore PDPA enforcement is not just that the organisation acted, but that it acted promptly and effectively. Voluntary admission of liability, particularly through the Expedited Decision Procedure (EDP), is treated favorably in Singapore PDPA enforcement unless the organisation is a repeat offender. The EDP process allows investigations to close within approximately 2 to 5 months while still producing meaningful enforcement outcomes. Organisations that take this route demonstrate accountability and cooperation, both of which the PDPC values when calibrating Singapore PDPA penalties. The PDPC has also shown willingness to reduce Singapore PDPA penalties based on an organisation's financial circumstances. In O2 Advertising Pte. Ltd. ([2019] SGPDPC 32), the penalty was reduced after considering the organisation's massive financial loss of SGD 3.2 million due to fraud and the circumstances of its 72-year-old sole owner who intended to continue the business on a reduced scale. In Advance Home Tutors ([2019] SGPDPC 35), the penalty was reduced to avoid imposing a crushing burden on a small home business with limited revenue. In DS Human Resource ([2019] SGPDPC 16), however, the PDPC maintained the penalty despite the SME's representation, to convey that good data management must be adopted from the onset of digitalisation. - Pre-existing compliance measures receive credit in Singapore PDPA enforcement: data protection policies, annual audits (Propnex Realty), penetration testing (ComGateway), and vulnerability assessments. - Prompt remediation is consistently mitigating in Singapore PDPA enforcement: Singapore Telecommunications' 11-hour fix, XDEL Singapore's quick code rectification, Creative Technology's log review despite deleted database. - Voluntary admission of liability through the EDP reduces investigation timelines to 2-5 months and is viewed favorably in Singapore PDPA penalty calibration. - Cooperation with the PDPC during Singapore PDPA investigations, including timely production of documents and information, is treated as mitigating. - First-time offender status is mitigating under Singapore PDPA enforcement, while repeat offences of a similar pattern (Aviva Ltd) are aggravating. - Financial hardship can reduce Singapore PDPA penalties: O2 Advertising (SGD 3.2 million fraud loss, elderly sole owner) and Advance Home Tutors (small home business with limited revenue). - Organisations should document compliance efforts, audit history, penetration test results, and remediation actions as evidence for potential Singapore PDPA penalty mitigation. ## How to respond to a Singapore PDPA investigation by the PDPC When the PDPC commences a Singapore PDPA investigation, the organisation will typically receive a written notice under paragraph 1 of the Ninth Schedule requiring the production of documents and information. This notice will specify the documents or categories of documents required, the purpose for which they are needed, and the deadline for production. Organisations must comply fully and within the specified timeframe. Failure to comply with a Singapore PDPA investigation notice can lead to further enforcement action, criminal liability for individuals, and may be treated as an aggravating factor in penalty calibration. The PDPC's Singapore PDPA investigation powers are extensive. Beyond document production, the PDPC may require the attendance of persons for oral examination under paragraph 1A of the Ninth Schedule, enter premises without a warrant (with at least 2 working days' notice under paragraph 2), and in certain circumstances enter premises with a warrant issued by a court under paragraph 3. Inspectors may take copies of documents, require explanations, and seize equipment where necessary. Organisations should have a Singapore PDPA investigation response plan that designates a point of contact, typically the Data Protection Officer, and a process for locating and producing relevant documents quickly. During a Singapore PDPA investigation, organisations should maintain open communication with the PDPC. If intending to issue media releases or make public disclosures about the alleged breach, the organisation should consider whether the content could hinder ongoing investigations and provide the PDPC with a copy of the materials before release. Cooperation is not just good practice; it is a factor the PDPC considers favorably in Singapore PDPA enforcement when determining penalty outcomes. If the PDPC issues a preliminary decision in a Singapore PDPA enforcement case, the organisation has 14 days to make written representations. This is a critical window. Representations should address the facts, the legal analysis, and the proposed penalty or directions. The organisation should present all mitigating factors available under Singapore PDPA enforcement, including compliance measures in place at the time, remediation actions taken, cooperation provided, voluntary admission of liability via EDP, first-time offender status, and any financial hardship considerations. Extensions of time may be granted in exceptional circumstances upon written application. - Designate a Data Protection Officer or response lead as the primary point of contact for all Singapore PDPA investigation communications with the PDPC. - Establish a document preservation and production process before a Singapore PDPA investigation occurs to enable rapid compliance with PDPC notices. - Comply fully and promptly with all document production notices; non-compliance is a criminal offence and an aggravating factor in Singapore PDPA penalty calibration. - Consider the Expedited Decision Procedure if the organisation is prepared to admit liability, as this can reduce the Singapore PDPA investigation timeline to 2-5 months. - Consider requesting a voluntary undertaking early in the investigation if the organisation has accountable practices and a ready remediation plan. - Use the 14-day representation window to present all mitigating factors, compliance evidence, remediation actions, and financial circumstances relevant to Singapore PDPA enforcement. - Conduct internal tabletop exercises simulating a PDPC investigation to test your Singapore PDPA response plan, document retrieval speed, and staff readiness. - After the investigation concludes, update your Data Protection Management Programme (DPMP) based on the Singapore PDPA enforcement lessons learned. ## Primary sources - [Personal Data Protection Act 2012 (Singapore) -- official text](https://sso.agc.gov.sg/Act/PDPA2012?ref=sorena.io) - Primary legislation governing collection, use, disclosure, protection, retention, transfer, and accountability for personal data in Singapore. - [PDPC -- Advisory Guidelines on Enforcement of Data Protection Provisions (revised 1 October 2022)](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-enforcement-of-data-protection-provisions?ref=sorena.io) - Official PDPC enforcement approach covering alternative dispute resolution, reviews, investigations, voluntary undertakings, directions, financial penalties, reconsideration, and appeals under the Singapore PDPA. - [PDPC -- Guide on Active Enforcement (revised 1 October 2022)](https://www.pdpc.gov.sg/help-and-resources/2019/05/guide-on-active-enforcement?ref=sorena.io) - PDPC guide articulating the Active Enforcement Framework, investigation process, types of enforcement outcomes, financial penalty calibration, and expedited decision procedure for Singapore PDPA enforcement. - [PDPC -- Undertakings](https://www.pdpc.gov.sg/undertakings?ref=sorena.io) - Published list of over 100 voluntary undertakings accepted by the PDPC under Singapore PDPA enforcement, with links to full undertaking documents for each organisation. - [PDPC -- Enforcement decisions](https://www.pdpc.gov.sg/all-commissions-decisions?ref=sorena.io) - Official PDPC decisions repository with published Singapore PDPA enforcement decisions including findings, directions, and financial penalties. - [PDPC -- Amendments to enforcement under the PDPA (1 October 2022)](https://www.pdpc.gov.sg/news-and-events/announcements/2022/09/amendments-to-enforcement-under-the-personal-data-protection-act-in-updated-advisory-guidelines-and-guide?ref=sorena.io) - PDPC announcement on Singapore PDPA enforcement amendments including the revised financial penalty cap (10% turnover) and voluntary undertaking powers effective 1 October 2022. - [PDPC -- PDPA overview](https://www.pdpc.gov.sg/overview-of-pdpa/pdpa-overview?ref=sorena.io) - Official PDPC overview of Singapore PDPA obligations, key concepts, and updates. ## Related Topic Guides - [Singapore PDPA Applicability Test | Does the PDPA Apply to Your Organisation?](/artifacts/apac/singapore-pdpa/applicability-test.md): Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation. - [Singapore PDPA Breach Notification Playbook - Complete Guide](/artifacts/apac/singapore-pdpa/breach-notification-playbook.md): Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline. - [Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026)](/artifacts/apac/singapore-pdpa/checklist.md): Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules. - [Singapore PDPA Compliance Deadlines and Calendar](/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar.md): Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows. - [Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM](/artifacts/apac/singapore-pdpa/compliance.md): Complete Singapore PDPA compliance guide for organisations. - [Singapore PDPA Consent and Notification Obligations Guide](/artifacts/apac/singapore-pdpa/consent-notification-and-purposes.md): Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception. - [Singapore PDPA Cross-Border Transfer Rules | Section 26 Data Transfer Compliance](/artifacts/apac/singapore-pdpa/cross-border-transfers.md): Complete guide to Singapore PDPA cross-border transfer compliance under Section 26. - [Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide](/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages.md): Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses. - [Singapore PDPA FAQ | Frequently Asked Questions on Personal Data Protection Act Compliance](/artifacts/apac/singapore-pdpa/faq.md): Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements. - [Singapore PDPA Penalties and Fines | SGD 1M or 10% Turnover Cap + PDPC Enforcement Guide](/artifacts/apac/singapore-pdpa/penalties-and-fines.md): Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions. - [Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide](/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template.md): Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions. - [Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC)](/artifacts/apac/singapore-pdpa/requirements.md): Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18). - [Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations](/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries.md): Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion. - [Singapore PDPA Vendor Outsourcing and Contracts Guide](/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts.md): Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence. - [Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties](/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr.md): Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases --- --- title: "Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide" canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template" source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template" author: "Sorena AI" description: "Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Singapore PDPA privacy policy template" - "Singapore PDPA privacy policy" - "PDPA privacy policy template" - "PDPA privacy policy" - "Singapore PDPA compliance" - "Personal Data Protection Act Singapore" - "Singapore PDPA requirements" - "Singapore PDPA privacy policy drafting" - "PDPA privacy policy example" - "PDPA privacy policy required sections" - "PDPC advisory guidelines privacy policy" - "Singapore data protection policy template" - "PDPA notification obligation template" - "PDPA consent clause template" - "PDPA access request template" - "PDPA correction request template" - "PDPA retention clause template" - "PDPA cross-border transfer clause" - "PDPA DPO contact requirements" - "PDPA withdrawal of consent template" - "PDPA data breach notification clause" - "Singapore PDPA deemed consent" - "PDPA purpose limitation clause" - "Singapore privacy policy template" - "Singapore PDPA privacy policy guide" - "PDPA privacy policy checklist" - "PDPA data protection notice template" - "Singapore PDPA accountability obligation" - "PDPA privacy policy update procedure" - "PDPA complaint handling template" - "Singapore PDPA privacy policy best practices" - "PDPA privacy policy clause by clause" - "Singapore PDPA privacy policy sections" - "Singapore PDPA" - "Personal Data Protection Act" - "PDPA privacy policy drafting" - "APAC privacy" - "PDPC compliance" - "data protection notice Singapore" - "PDPA template" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions. *Artifact Guide* *APAC* ## Singapore PDPA Privacy Policy Template Singapore PDPA privacy policy template: a clause-by-clause drafting guide that covers all 10 Data Protection Provisions -- purposes, consent, notification, access, correction, accuracy, protection, retention, transfer, and breach notification. Build a Singapore PDPA privacy policy that matches your actual data processing and can be proven with internal evidence. This Singapore PDPA privacy policy template is a practical, clause-by-clause drafting guide for organisations that need a compliant privacy policy under the Personal Data Protection Act (PDPA). The Singapore PDPA privacy policy is the primary document through which organisations meet their Notification Obligation (section 20) and demonstrate accountability (sections 11 and 12). The PDPC Key Concepts advisory guidelines (paragraph 14.12) confirm that organisations may develop a Data Protection Policy -- also called a privacy policy -- to set out policies and procedures for complying with the PDPA, and may use this policy to notify individuals of the purposes for which personal data is collected, used, and disclosed. This Singapore PDPA privacy policy template is written for product, legal, security, and operations teams who need a repeatable drafting process with defensible evidence. Use the PDPA statute, PDPC guidance, and DPMP guide linked below, and tailor each clause of this Singapore PDPA privacy policy template to your specific processing context. ## Why every Singapore organisation needs a Singapore PDPA privacy policy Every organisation in Singapore that collects, uses, or discloses personal data must have a Singapore PDPA privacy policy unless it falls within an excluded category such as a public agency or an individual acting in a personal or domestic capacity. The Accountability Obligation under sections 11 and 12 of the PDPA requires organisations to develop and implement policies and practices and to make information about those policies publicly available. A Singapore PDPA privacy policy is the primary mechanism for meeting this accountability requirement, and the PDPC Key Concepts advisory guidelines (paragraph 14.12) expressly recognise the privacy policy as an accepted channel for providing notification of purposes to individuals. Beyond legal compliance, a well-drafted Singapore PDPA privacy policy serves as the public-facing evidence of your Data Protection Management Programme (DPMP). The PDPC Guide to Developing a DPMP recommends that organisations benchmark their personal data protection policies against the DPMP framework. In the DPMP guide, the PDPC lists twenty-one questions that a Singapore PDPA privacy policy should address, covering governance, purpose, third-party sharing, protection measures, retention, disposal, breach handling, and DPIAs. The privacy policy sits at the top of this programme, translating internal processes into clear disclosures that individuals can understand and act upon. The Notification Obligation under section 20 of the PDPA requires organisations to inform individuals of the purposes for which their personal data will be collected, used, or disclosed on or before such collection, use, or disclosure. The PDPC advisory guidelines (paragraph 14.12) confirm that organisations may choose to provide this notification through a Data Protection Policy. A Singapore PDPA privacy policy that is comprehensive, accurate, and accessible therefore serves double duty: it satisfies the notification requirement and demonstrates accountability to the PDPC. Failure to maintain an adequate Singapore PDPA privacy policy can result in enforcement action. Organisations that cannot demonstrate that they informed individuals of their data collection purposes or that they have policies and practices in place risk financial penalties of up to SGD 1 million or 10% of annual turnover (whichever is higher) under the amended PDPA. Publishing a complete and accurate Singapore PDPA privacy policy is one of the most cost-effective compliance measures available and the foundation of every defensible data protection programme. - The Accountability Obligation (PDPA sections 11 and 12) requires organisations to have policies and practices and to make information about them publicly available -- a Singapore PDPA privacy policy is the standard mechanism. - The Notification Obligation (PDPA section 20) requires informing individuals of purposes on or before collection, and the PDPC (paragraph 14.12) confirms a privacy policy is an accepted notification channel. - The PDPC Guide to Developing a DPMP lists 21 questions a Singapore PDPA privacy policy should answer, covering purpose, sharing, protection, retention, disposal, and breach handling. - Enforcement penalties can reach SGD 1 million or 10% of annual turnover for non-compliance with data protection provisions. - A Singapore PDPA privacy policy is the simplest way to demonstrate to the PDPC that your organisation has considered and addressed all ten Data Protection Provisions. - Organisations that use data intermediaries remain responsible for compliance and should reflect intermediary arrangements in the Singapore PDPA privacy policy. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep Singapore PDPA Privacy Policy Template in one governed evidence system SSOT can take Singapore PDPA Privacy Policy Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on Singapore PDPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for Singapore PDPA Privacy Policy Template](/solutions/ssot.md): Start from Singapore PDPA Privacy Policy Template and keep documents, evidence, and control records in one governed system. - [Talk through Singapore PDPA](/contact.md): Review your current process, evidence gaps, and next steps for Singapore PDPA Privacy Policy Template. ## Required elements in a Singapore PDPA privacy policy template The PDPA does not prescribe a standard template for privacy policies, but the PDPC advisory guidelines and enforcement decisions establish clear expectations about what a Singapore PDPA privacy policy must cover. At a minimum, your Singapore PDPA privacy policy template should address each of the ten Data Protection Provisions: Consent, Purpose Limitation, Notification, Access, Correction, Accuracy, Protection, Retention Limitation, Transfer Limitation, and Data Breach Notification. Paragraph 14.12 of the Key Concepts guidelines states that organisations may wish to develop a Data Protection Policy to set out policies and procedures for complying with the PDPA. The PDPC also operates a Data Protection Notice Generator that helps organisations create structured notices. While a Singapore PDPA privacy policy is broader than a notice, the generator's output provides a useful baseline. Your Singapore PDPA privacy policy template should go further by documenting how each obligation is operationalised and by providing the DPO's business contact information as required under the Accountability Obligation. The DPMP guide recommends that policies be approved by management, communicated to all relevant parties, and reviewed regularly to ensure they remain relevant. The PDPC recommends a layered notice approach for your Singapore PDPA privacy policy: a summary of the most important information presented prominently, with detailed information available for individuals who want to review it (paragraph 14.18(b)). When a policy sets out purposes in very general terms, organisations should provide a more specific description to individuals in particular situations (paragraph 14.13(b)). Consider organising your Singapore PDPA privacy policy template by data lifecycle stage or by obligation for maximum clarity. Your Singapore PDPA privacy policy should be written in plain language that avoids legalistic terminology. The PDPC's good practice considerations (paragraph 14.18(a)) recommend drafting notices that are easy to understand and appropriate to the intended audience, providing headings or clear indication of where individuals should look, and avoiding legalistic language or terminology that would confuse or mislead readers. Where your organisation operates in multiple languages, consider providing translations that match your customer base. - Cover all ten Data Protection Provisions in your Singapore PDPA privacy policy template: Consent, Purpose Limitation, Notification, Access, Correction, Accuracy, Protection, Retention, Transfer, and Data Breach Notification. - Include the business contact information of your Data Protection Officer (DPO) as required under the Accountability Obligation -- this is mandatory, not optional. - Use a layered notice approach as recommended by the PDPC (paragraph 14.18(b)): summary of key points presented prominently, with detailed sections for full review. - State purposes at an appropriate level of detail so individuals can understand the reasons and manner of collection, use, and disclosure (paragraph 14.15). - Write the Singapore PDPA privacy policy in plain language and avoid legalistic jargon that would confuse or mislead readers (paragraph 14.18(a)). - Indicate which data fields are compulsory and which are optional when collecting through forms (paragraph 12.14 of the Key Concepts guidelines). - Make the Singapore PDPA privacy policy available as a physical document at the point of collection and on your website (paragraph 14.13). - Review and update your Singapore PDPA privacy policy regularly to reflect changes in your data processing activities, as recommended in the DPMP guide. ## Singapore PDPA privacy policy template: purposes of collection, use, and disclosure The Purpose Limitation Obligation under section 18 of the PDPA limits an organisation to collecting, using, or disclosing personal data only for purposes that a reasonable person would consider appropriate in the circumstances. Your Singapore PDPA privacy policy template must include a clause that clearly states every purpose for which you collect, use, or disclose personal data. The PDPC has confirmed through enforcement decisions that vague references to 'any other purpose that it deems fit' are not considered reasonable (paragraph 13.3 example). Every purpose clause in your Singapore PDPA privacy policy must be specific enough for the individual to understand the reasons and manner of processing. Under the PDPA, 'purpose' refers to objectives or reasons, not to every specific activity. A retailer collecting delivery addresses can state the purpose as 'delivering products purchased by the customer' without listing every internal processing step such as entering the data into a CRM or printing delivery labels (paragraph 8.2). However, the purpose clause in your Singapore PDPA privacy policy template should be stated with enough specificity that the individual understands what the organisation intends to do. The PDPC guidelines (paragraph 14.16) set out five factors for determining the appropriate level of detail: clarity, whether the purpose is mandatory or optional, identification of recipient organisations, whether greater specificity helps or hinders understanding, and the organisation's business processes. Your Singapore PDPA privacy policy should separate mandatory purposes from optional purposes. Mandatory purposes are those required to provide the product or service. Optional purposes, such as marketing or analytics, should be presented separately so that individuals can consent to or decline them independently. Section 14(2)(a) of the PDPA prohibits requiring consent beyond what is reasonable to provide the product or service as a condition of providing that service. This separation is a critical design element of any Singapore PDPA privacy policy template. When purposes change, the organisation must inform individuals of the new purposes and obtain fresh consent before using or disclosing personal data for those new purposes, unless an exception applies (paragraphs 14.19 to 14.22). Your Singapore PDPA privacy policy should state the current purposes and describe the process by which individuals will be informed of changes. Include a clause explaining that the organisation will not use personal data for purposes beyond those stated in the Singapore PDPA privacy policy without prior notification and, where required, consent. - List every category of personal data collected and the specific purpose for each category in your Singapore PDPA privacy policy template. - State purposes at an appropriate level of detail: objectives and reasons, not every internal processing step (paragraph 14.15). - Separate mandatory purposes (required for service delivery) from optional purposes (marketing, analytics, third-party sharing) so individuals can consent independently. - Do not use catch-all phrases such as 'any other purpose' or 'for valid business purposes' -- the PDPC considers these non-compliant (paragraph 13.3). - Identify which third parties receive personal data and the purpose of each disclosure in the Singapore PDPA privacy policy. - Describe the process for informing individuals when purposes change and for obtaining fresh consent (paragraphs 14.19 to 14.22). - If the organisation relies on the business improvement exception (Part 5, First Schedule) for any use, state this clearly in the Singapore PDPA privacy policy. - Map disclosed data to specific recipient categories: affiliates, data intermediaries, service providers, regulators, and law enforcement. ## Singapore PDPA privacy policy template: consent and deemed consent clauses The Consent Obligation under sections 13 to 17 of the PDPA requires organisations to obtain consent before collecting, using, or disclosing personal data. Your Singapore PDPA privacy policy template should include a consent clause that explains how consent is obtained and describes the different forms of consent that apply to your processing activities. The PDPA recognises express consent (written or recorded), verbal consent, implied consent (inferred from conduct), deemed consent by conduct (section 15(1)), deemed consent by contractual necessity (section 15(3)), and deemed consent by notification (section 15A). Each form should be described in your Singapore PDPA privacy policy so individuals understand the legal basis for processing. Deemed consent by conduct applies when an individual voluntarily provides personal data and the purposes are reasonably obvious from the surrounding circumstances. Deemed consent by contractual necessity applies when personal data must be disclosed to a third party to conclude or perform a transaction between the individual and the organisation. Your Singapore PDPA privacy policy template should describe which categories of processing rely on each form of consent and provide practical examples so individuals can understand when deemed consent applies to their data. Deemed consent by notification (section 15A) allows organisations to use or disclose existing personal data for secondary purposes that were not part of the original collection, provided certain conditions are met. The organisation must conduct an assessment to determine that there is no likely adverse effect, provide adequate notification, and offer a reasonable opt-out period. Your Singapore PDPA privacy policy should disclose when deemed consent by notification is relied upon and describe the notification and opt-out process. This clause is particularly important for organisations that want to use existing customer data for new analytics or product improvement purposes. The PDPC's advisory guidelines (paragraph 12.28) state that organisations should generally use the opt-in method for obtaining consent for direct marketing messages. Pre-checked boxes do not constitute valid consent for marketing under the PDPA. Your Singapore PDPA privacy policy template should make this distinction clear and include a separate marketing consent clause that explains how marketing consent is managed independently from service-related consent. Additionally, disclose any reliance on the legitimate interests exception and provide business contact information for queries about that reliance (paragraph 12.60). - Explain in your Singapore PDPA privacy policy the different forms of consent your organisation relies on: express consent, deemed consent by conduct, deemed consent by contractual necessity, and deemed consent by notification. - Identify which data processing activities rely on each form of consent within the Singapore PDPA privacy policy template. - For deemed consent by notification (section 15A), describe the assessment process, notification method, and opt-out period. - State that marketing consent is obtained through opt-in (not pre-checked boxes) as recommended by the PDPC (paragraph 12.28). - Explain that consent must not be required beyond what is reasonable to provide a product or service (section 14(2)(a)). - Describe how the organisation handles consent from persons acting on behalf of individuals (section 14(4)), such as parents or legal representatives. - Disclose any reliance on the legitimate interests exception in your Singapore PDPA privacy policy and provide business contact information for queries (paragraph 12.60). - List exceptions to consent that the organisation relies on, such as collection for evaluative purposes, emergencies, or publicly available data. ## Singapore PDPA privacy policy template: access and correction request clauses The Access and Correction Obligations under sections 21, 22, and 22A of the PDPA give individuals the right to request access to their personal data and to request corrections to errors or omissions. Your Singapore PDPA privacy policy template must include clauses that describe how individuals can exercise these rights and what to expect from the process. The PDPC advisory guidelines (paragraph 15.53) confirm that while organisations may provide standard forms, they must accept all requests made in writing and sent to the DPO's business contact information. The DPMP guide provides a detailed checklist of considerations for access request handling that your Singapore PDPA privacy policy should reflect. For access requests, your Singapore PDPA privacy policy should explain what information will be provided: the personal data in the organisation's possession or under its control, and information about how the personal data has been used or disclosed within the past year (section 21(1)). The policy should state the expected response timeframe. Under the PDPA, organisations must provide access as soon as reasonably possible, and if they cannot respond within 30 calendar days, they must inform the individual of the timeframe within those 30 days. Include specific contact channels (email, postal address, online form) and the name or title of the DPO. For correction requests, the organisation must correct errors or omissions as soon as practicable and send corrected data to any other organisation that received the data within the past year, unless the other organisation does not need the corrected data for any legal or business purpose (section 22(2)). Your Singapore PDPA privacy policy template should note that no fee may be charged for corrections. For access requests, however, a reasonable fee may be charged for producing copies, and the PDPC may review fees upon application by the individual (PDP Regulation 7(1)). Your Singapore PDPA privacy policy should also describe identity verification steps the organisation uses before processing access or correction requests. The PDPC permits reasonable verification measures to confirm the identity of the requester, but these should not be so burdensome as to discourage individuals from exercising their rights. Include a clause explaining that if an access request is rejected, the organisation will inform the individual of the reasons and the individual's right to seek review by the PDPC. - State the contact channel for submitting access and correction requests in the Singapore PDPA privacy policy: DPO email address, postal address, or online form. - Explain that access requests will be fulfilled as soon as reasonably possible, with a written update if the response exceeds 30 calendar days. - Confirm that access includes personal data held and information about use or disclosure within the past year (section 21(1)). - State that correction requests will be processed at no charge to the individual (section 22). - Describe the identity verification process used before fulfilling requests in your Singapore PDPA privacy policy template. - Note that a reasonable fee may be charged for producing copies of personal data in response to access requests, subject to PDPC review (PDP Regulation 7(1)). - List any exceptions that may apply (e.g., Fifth Schedule exceptions for evaluative purpose data, legal proceedings, or data that could reveal another individual's personal data). - Explain that if an access request is rejected, the organisation will inform the individual of the reasons and their right to seek review by the PDPC. ## Singapore PDPA privacy policy template: retention and disposal clauses The Retention Limitation Obligation under section 25 of the PDPA requires organisations to stop retaining personal data, or to remove the means by which it can be associated with particular individuals, as soon as it is reasonable to assume that the purpose for which the data was collected is no longer being served and retention is no longer necessary for legal or business purposes. Your Singapore PDPA privacy policy template should include a retention clause that explains your approach to retention and disposal in clear terms. The PDPC advisory guidelines (paragraph 18.4(a)(ii)) explicitly state that personal data must not be retained 'just in case' for purposes that have not been notified to individuals. The PDPA does not prescribe specific retention periods, so each organisation must determine appropriate periods based on the purpose of collection and any legal or regulatory requirements that mandate minimum retention. For example, organisations may retain contract-related records for seven years based on the six-year limitation period under the Limitation Act (Cap. 163) plus an additional buffer for pending claims. Your Singapore PDPA privacy policy should describe these retention criteria in general terms without disclosing internal schedules that could be commercially sensitive. The DPMP guide recommends including retention schedules in third-party agreements as well. The PDPC advisory guidelines (paragraph 18.5) recommend that organisations review the personal data they hold on a regular basis to determine whether it is still needed. Organisations holding a large quantity of different types of personal data should implement varying retention periods for each type. Your Singapore PDPA privacy policy template should explain that the organisation conducts periodic reviews and describe the disposal methods used, such as secure deletion of electronic records and shredding of physical documents. Your Singapore PDPA privacy policy should also address the distinction between ceasing retention and anonymisation. Under the PDPA, an organisation may anonymise personal data instead of deleting it (paragraph 18.9). If your organisation uses anonymisation as part of its disposal process, the Singapore PDPA privacy policy should state this and confirm that anonymised data can no longer identify individuals. The PDPC Selected Topics guidelines describe anonymisation considerations in detail, including the 'motivated intruder' test for assessing re-identification risk. - State in your Singapore PDPA privacy policy that personal data is retained only as long as necessary for the purpose of collection and for legal or business purposes. - Describe the general criteria used to determine retention periods: purpose of collection, legal requirements, contractual obligations (e.g., Limitation Act Cap. 163). - Confirm that the organisation conducts periodic reviews of retained personal data as recommended by the PDPC (paragraph 18.5). - Explain the disposal methods used: secure deletion for electronic records, shredding for physical documents. - Note in the Singapore PDPA privacy policy template that anonymisation may be used as an alternative to deletion where appropriate, subject to re-identification risk assessment. - State that personal data is not retained indefinitely or 'just in case' for purposes that have not been notified to individuals (paragraph 18.4(a)(ii)). - Reference any industry-specific retention requirements that apply to your organisation's sector. - Describe how retention policies apply to data held by data intermediaries on the organisation's behalf, as the DPMP guide recommends including retention terms in third-party agreements. ## Singapore PDPA privacy policy template: cross-border transfer clauses The Transfer Limitation Obligation under section 26 of the PDPA prohibits organisations from transferring personal data to a country or territory outside Singapore except in accordance with prescribed requirements. Your Singapore PDPA privacy policy template must include a cross-border transfer clause that discloses whether personal data is transferred overseas, which countries or territories receive the data, and what safeguards are in place to protect the data to a standard comparable to the PDPA. This clause is essential for any Singapore PDPA privacy policy because most modern organisations use cloud services hosted outside Singapore. The PDPA provides several avenues for compliant cross-border transfers. These include obtaining the individual's written consent after providing a reasonable summary of the overseas protections; ensuring the recipient is bound by legally enforceable obligations providing comparable protection (such as contractual clauses or binding corporate rules); relying on the recipient's certification under the APEC Cross-Border Privacy Rules (CBPR) or Privacy Recognition for Processors (PRP) system; and transfers necessary for the performance of a contract (section 15(6)). Your Singapore PDPA privacy policy should identify which mechanism applies to each category of transfer. The PDPC encourages the use of ASEAN Model Contractual Clauses (MCCs) as a mechanism for ensuring comparable protection in cross-border transfers (paragraph 19.10). The DPMP guide also references the Guidance for Use of ASEAN Model Contractual Clauses for Cross-Border Data Flows as a key resource. Your Singapore PDPA privacy policy template should describe the safeguard mechanisms your organisation uses and provide sufficient information for individuals to understand how their personal data is protected when it leaves Singapore. Where your organisation uses cloud services, CRM systems, or other technology platforms hosted overseas, these constitute cross-border transfers even if the organisation itself is based in Singapore. The Singapore PDPA privacy policy should cover all such transfers, including those made by data intermediaries on the organisation's behalf. The organisation remains responsible for compliance with the Transfer Limitation Obligation regardless of whether the transfer is made directly or through a data intermediary (paragraph 6.22). Include a clause explaining what happens if an individual withholds consent for cross-border transfers and the impact on service delivery. - Disclose in your Singapore PDPA privacy policy whether personal data is transferred outside Singapore and identify the countries or territories involved. - Describe the safeguard mechanisms used: contractual clauses, binding corporate rules, APEC CBPR/PRP certification, or written consent with a reasonable summary. - Explain that the organisation ensures overseas recipients provide protection comparable to the PDPA. - Cover transfers made through cloud services, SaaS platforms, and other technology providers hosted outside Singapore in the Singapore PDPA privacy policy template. - State that the organisation remains responsible for data transferred to overseas data intermediaries (paragraph 6.22). - Reference use of ASEAN Model Contractual Clauses (MCCs) if applicable, as recommended by the PDPC and the DPMP guide. - Describe due diligence conducted on overseas recipients, including verification of certifications and review of data protection policies. - Explain what happens if an individual withholds consent for cross-border transfers and the impact on service delivery. ## Singapore PDPA privacy policy template: DPO contact and complaint handling clauses The Accountability Obligation requires every organisation to designate at least one individual as a Data Protection Officer (DPO) responsible for ensuring compliance with the PDPA (paragraph 21.1 of the Key Concepts guidelines). Your Singapore PDPA privacy policy template must include a dedicated clause with the DPO's business contact information. This is a mandatory requirement under the PDPA, not optional, and the PDPC has taken enforcement action against organisations that failed to designate a DPO or that did not make the DPO's contact information accessible. The DPMP guide confirms that it is mandatory for organisations to designate at least one individual to be the DPO. The DPO contact clause in your Singapore PDPA privacy policy should include at minimum an email address and a postal address. If your organisation has a dedicated data protection hotline or online contact form, include those as well. The PDPC expects that individuals should be able to reach the DPO through the published contact channels to submit access requests, correction requests, consent withdrawal notices, and complaints. Under PDP Regulation 3(1), requests to an organisation must be sent to the DPO in accordance with the business contact information provided under section 11(5) of the PDPA. Your Singapore PDPA privacy policy template should include a complaint handling clause that describes the process in clear steps. When an individual submits a complaint about the organisation's handling of personal data, the clause should explain what happens next: acknowledgment of the complaint, investigation steps, response timeline, and escalation paths. If the individual is not satisfied with the organisation's response, the Singapore PDPA privacy policy should inform them of their right to escalate the complaint to the PDPC. Good practice is to include a dedicated section in the Singapore PDPA privacy policy that provides the DPO's name or title, department, email address, postal address, and phone number. The DPMP guide also recommends that the DPO be empowered to handle major complaints and manage data breaches, with direction from senior management. Include a clause confirming that queries about the organisation's reliance on the legitimate interests exception can be directed to the DPO, as required by the PDPC guidelines (paragraph 12.60). - Provide the DPO's business contact information in your Singapore PDPA privacy policy: email address, postal address, and phone number (if available). - State the DPO's name or job title and the department responsible for data protection -- the DPMP guide confirms this designation is mandatory. - Describe the complaint handling process: how to submit a complaint, expected response time, and investigation steps. - Inform individuals of their right to escalate complaints to the PDPC if they are not satisfied with the organisation's response. - Confirm in the Singapore PDPA privacy policy template that the DPO handles access requests, correction requests, consent withdrawal notices, and general data protection inquiries. - Include a direct email address or web form for data protection inquiries prominently in the Singapore PDPA privacy policy. - Explain that queries about the organisation's reliance on the legitimate interests exception can be directed to the DPO (paragraph 12.60). - Consider providing a dedicated web form for data protection requests to streamline intake, tracking, and response time monitoring. ## Singapore PDPA privacy policy template: withdrawal of consent and policy update clauses Section 16 of the PDPA gives individuals the right to withdraw consent at any time for the collection, use, or disclosure of their personal data. Your Singapore PDPA privacy policy template must include a withdrawal of consent clause that explains how individuals can withdraw their consent and describes the consequences of withdrawal. The PDPC advisory guidelines (paragraph 12.42) recommend that organisations make an appropriate consent withdrawal policy that is clear and easily accessible. This clause is one of the most frequently reviewed sections during PDPC enforcement proceedings. The withdrawal of consent clause in your Singapore PDPA privacy policy should describe the form and manner for submitting a withdrawal notice, the person or channel through which the notice should be sent, and the distinction between mandatory and optional purposes. Individuals must be allowed to withdraw consent for optional purposes (such as marketing) without being required to also withdraw consent for mandatory purposes (such as service delivery). The PDPC guidelines (paragraph 12.42(c)) require this separation. Section 16(3) of the PDPA prohibits organisations from restricting or preventing individuals from withdrawing consent. Upon receiving a withdrawal notice, the organisation must inform the individual of the likely consequences of withdrawing consent (section 16(2)), even if these consequences are already stated in the service contract. The organisation must then cease collecting, using, or disclosing the personal data for the withdrawn purposes, and instruct its data intermediaries and agents to do the same (section 16(4)). Your Singapore PDPA privacy policy template should state that the PDPC considers a processing period of at least ten business days from receipt of the withdrawal notice as reasonable (paragraph 12.41). Your Singapore PDPA privacy policy should also include a policy update clause that describes how changes to the policy are communicated. When the organisation changes its data processing purposes, collection methods, or disclosure practices, the policy must be updated and individuals should be notified of material changes. Best practice is to publish a revision date on the Singapore PDPA privacy policy, maintain a version history, and use direct communication channels (email, app notification) to inform individuals of significant changes. Continuing to use the service after notification of changes may constitute deemed consent by notification for the updated purposes, but only if the conditions under section 15A are met. - Describe the channels for submitting a consent withdrawal notice in your Singapore PDPA privacy policy: email, online form, postal mail, or in-person. - Explain that individuals can withdraw consent for optional purposes without affecting consent for mandatory purposes (paragraph 12.42(c)). - State the expected processing time for withdrawal requests in the Singapore PDPA privacy policy template (PDPC recommends at least ten business days -- paragraph 12.41). - Confirm that the organisation will inform the individual of the likely consequences of withdrawal before processing the request (section 16(2)). - Describe how the organisation notifies individuals of material changes to the Singapore PDPA privacy policy. - Include a revision date and version number on the published Singapore PDPA privacy policy. - Explain that continuing to use services after notification of material changes may constitute deemed consent, subject to section 15A conditions. - State that the organisation will not prohibit individuals from withdrawing consent, as required by section 16(3) of the PDPA. ## Singapore PDPA privacy policy template: data breach notification clause The Data Breach Notification Obligation under sections 26A to 26E of the PDPA requires organisations to assess whether a data breach is notifiable and notify the PDPC and affected individuals where the breach is assessed to be notifiable. Your Singapore PDPA privacy policy template should include a data breach notification clause that explains how the organisation will respond if a breach occurs and how affected individuals will be informed. This clause demonstrates proactive accountability and reassures individuals that the organisation has a breach response plan in place. A data breach is notifiable under the PDPA if it results in, or is likely to result in, significant harm to the affected individuals, or if it is of a significant scale (affecting 500 or more individuals). The organisation must notify the PDPC within three calendar days after determining that the breach is notifiable. The three-day period starts on the day after the organisation makes the determination. Your Singapore PDPA privacy policy should state that the organisation maintains a data breach response plan and will notify the PDPC and affected individuals within the statutory timeframes. Your Singapore PDPA privacy policy template should describe the types of information that will be communicated to affected individuals in the event of a notifiable breach, including the nature of the breach, the types of personal data involved, what the organisation is doing to address the breach, and what steps individuals can take to protect themselves. The DPMP guide recommends that the DPO document data incidents and data breaches in an incident record log and actively engage data intermediaries to delineate responsibilities for reporting, investigating, and taking remedial actions. Including a data breach notification clause in your Singapore PDPA privacy policy also supports your organisation's accountability posture. The PDPC evaluates whether an organisation had adequate policies and processes in place when assessing enforcement action. A privacy policy that proactively describes breach response procedures demonstrates that the organisation takes data protection seriously. The PDPC Guide on Managing and Notifying Data Breaches provides detailed guidance on the notification process that should inform the drafting of this clause. - Include a data breach notification clause in your Singapore PDPA privacy policy template stating that the organisation maintains a breach response plan. - State that the PDPC will be notified within three calendar days after a breach is assessed as notifiable, as required by sections 26A to 26E. - Explain that affected individuals will be notified if the breach is likely to result in significant harm or affects 500 or more individuals. - Describe the types of information that will be communicated to affected individuals: nature of breach, data types involved, remedial actions, and self-protection steps. - Confirm that the DPO is responsible for managing the breach response process and coordinating with the PDPC. - State that data intermediaries and agents will be engaged to delineate breach reporting and remediation responsibilities, as recommended by the DPMP guide. ## Common Singapore PDPA privacy policy mistakes to avoid One of the most common mistakes in a Singapore PDPA privacy policy is using vague or overly broad purpose statements. The PDPC has consistently held that catch-all phrases like 'any other purpose that the organisation deems fit' or 'for valid business purposes' do not meet the Purpose Limitation or Notification Obligations. Each purpose in your Singapore PDPA privacy policy template must be stated at a level of detail that allows the individual to understand why their personal data is being collected and how it will be used or disclosed. The Key Concepts guidelines (paragraph 14.16) provide five factors for evaluating purpose specificity. Another frequent error is bundling consent for all purposes into a single opt-in. Under section 14(2)(a) of the PDPA, an organisation must not require consent beyond what is reasonable for providing the product or service as a condition of providing that product or service. In your Singapore PDPA privacy policy template, marketing consent, third-party sharing consent, and analytics consent should each be obtained separately so that individuals can make informed choices about each purpose. Using pre-checked boxes for marketing consent is not compliant -- the PDPC recommends the opt-in method (paragraph 12.28). Many organisations fail to keep their Singapore PDPA privacy policy up to date. A policy written at launch that does not reflect current data processing activities creates a gap between what individuals were told and what actually happens. The PDPC expects organisations to review and update their policies regularly, and enforcement decisions have found organisations in breach when their stated purposes did not match actual data processing. The DPMP guide recommends regular policy reviews and provides a maintenance framework. Schedule annual reviews at minimum, with additional reviews triggered by changes to products, services, or data flows. Organisations also frequently overlook the requirement to designate and publicise a DPO in their Singapore PDPA privacy policy. The PDPA requires every organisation to appoint at least one person as DPO and to make that person's business contact information publicly available. Failing to do so is a breach of the Accountability Obligation. Additionally, some organisations draft privacy policies that are excessively long and legalistic, making it difficult for individuals to find the information they need. The PDPC recommends using a layered notice approach with clear headings and plain language (paragraph 14.18). Your Singapore PDPA privacy policy template should balance comprehensiveness with readability. - Avoid vague purpose statements such as 'any other purpose' or 'for valid business purposes' in your Singapore PDPA privacy policy -- these are not compliant (paragraph 13.3). - Do not bundle consent for marketing, analytics, and third-party sharing into a single opt-in with service consent in the Singapore PDPA privacy policy template. - Do not use pre-checked boxes for marketing consent -- the PDPC considers the opt-out method inappropriate for direct marketing (paragraph 12.28). - Keep the Singapore PDPA privacy policy up to date with current data processing activities and review it at least annually as recommended by the DPMP guide. - Do not omit the DPO's contact information from the Singapore PDPA privacy policy -- this is a mandatory element under the Accountability Obligation. - Avoid excessively legalistic language that makes the Singapore PDPA privacy policy difficult for ordinary individuals to understand (paragraph 14.18(a)). - Do not state that individuals cannot withdraw consent -- section 16(3) of the PDPA prohibits this restriction. - Do not retain personal data indefinitely without a clear legal or business purpose -- this violates the Retention Limitation Obligation (paragraph 18.4(a)(ii)). - Do not ignore cross-border transfers through cloud services and SaaS providers in the Singapore PDPA privacy policy -- these are subject to the Transfer Limitation Obligation. - Do not copy a generic template without tailoring it to your specific data processing context, purposes, and disclosure practices -- the PDPC evaluates whether policies reflect actual operations. ## Primary sources - [Personal Data Protection Act 2012 (Singapore) -- official text](https://sso.agc.gov.sg/Act/PDPA2012?ref=sorena.io) - Primary legislation governing collection, use, disclosure, protection, retention, transfer, and accountability for personal data in Singapore. - [PDPC -- PDPA overview](https://www.pdpc.gov.sg/overview-of-pdpa/pdpa-overview?ref=sorena.io) - Official PDPC overview of PDPA obligations, key concepts, and updates. - [PDPC -- Key Concepts advisory guidelines (Revised 16 May 2022)](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-the-personal-data-protection-act?ref=sorena.io) - Core interpretation guidance for consent, purposes, notification, access/correction, accuracy, protection, retention, transfers, and accountability. Paragraphs 14.12 to 14.18 provide specific guidance on privacy policy drafting. - [PDPC -- Advisory Guidelines on the PDPA for Selected Topics (Revised 23 May 2024)](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-the-pdpa-for-selected-topics?ref=sorena.io) - Guidance on analytics, anonymisation, photography, CCTVs, and other selected topics under the PDPA. - [PDPC -- Enforcement advisory guidelines](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-enforcement-of-data-protection-provisions?ref=sorena.io) - Enforcement approach, directions, financial penalties, and undertakings. - [PDPC -- Guide to Developing a Data Protection Management Programme (August 2023)](https://www.pdpc.gov.sg/help-and-resources/2019/07/guide-to-developing-a-data-protection-management-programme?ref=sorena.io) - Four-step DPMP framework covering governance, policy, processes, and maintenance. Includes 21 policy questions and detailed guidance on communicating policies to customers. - [PDPC -- Data Protection Notice Generator](https://www.pdpc.gov.sg/help-and-resources/2020/02/data-protection-notice-generator?ref=sorena.io) - Online tool for generating structured data protection notices that can serve as a baseline for Singapore PDPA privacy policy drafting. - [PDPC -- Guide on Managing and Notifying Data Breaches Under the PDPA](https://www.pdpc.gov.sg/help-and-resources/2021/01/guide-on-managing-and-notifying-data-breaches-under-the-pdpa?ref=sorena.io) - Detailed guidance on data breach assessment, notification to the PDPC and affected individuals, and breach response planning. ## Related Topic Guides - [Singapore PDPA Applicability Test | Does the PDPA Apply to Your Organisation?](/artifacts/apac/singapore-pdpa/applicability-test.md): Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation. - [Singapore PDPA Breach Notification Playbook - Complete Guide](/artifacts/apac/singapore-pdpa/breach-notification-playbook.md): Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline. - [Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026)](/artifacts/apac/singapore-pdpa/checklist.md): Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules. - [Singapore PDPA Compliance Deadlines and Calendar](/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar.md): Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows. - [Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM](/artifacts/apac/singapore-pdpa/compliance.md): Complete Singapore PDPA compliance guide for organisations. - [Singapore PDPA Consent and Notification Obligations Guide](/artifacts/apac/singapore-pdpa/consent-notification-and-purposes.md): Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception. - [Singapore PDPA Cross-Border Transfer Rules | Section 26 Data Transfer Compliance](/artifacts/apac/singapore-pdpa/cross-border-transfers.md): Complete guide to Singapore PDPA cross-border transfer compliance under Section 26. - [Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide](/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages.md): Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses. - [Singapore PDPA FAQ | Frequently Asked Questions on Personal Data Protection Act Compliance](/artifacts/apac/singapore-pdpa/faq.md): Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements. - [Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions](/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases.md): Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover. - [Singapore PDPA Penalties and Fines | SGD 1M or 10% Turnover Cap + PDPC Enforcement Guide](/artifacts/apac/singapore-pdpa/penalties-and-fines.md): Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions. - [Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC)](/artifacts/apac/singapore-pdpa/requirements.md): Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18). - [Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations](/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries.md): Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion. - [Singapore PDPA Vendor Outsourcing and Contracts Guide](/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts.md): Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence. - [Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties](/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr.md): Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template --- --- title: "Singapore PDPA Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/penalties-and-fines" author: "Sorena AI" description: "Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Singapore PDPA penalties" - "Singapore PDPA fines" - "PDPA financial penalty" - "PDPC enforcement" - "PDPA fines Singapore" - "PDPA 10 percent turnover penalty" - "PDPA SGD 1 million fine" - "PDPC directions" - "Singapore data breach penalty" - "DNC registry fines Singapore" - "PDPA criminal offence" - "PDPA voluntary undertaking" - "PDPA aggravating factors" - "PDPA mitigating factors" - "PDPC enforcement decisions" - "PDPA penalty calculation" - "Singapore PDPA compliance" - "PDPA enforcement guide" - "PDPA penalty reduction" - "PDPA data protection management programme" - "PDPA section 48J" - "PDPA section 48I" - "PDPA enforcement framework" - "Singapore data protection enforcement" - "PDPA compliance checklist" - "PDPA penalty exposure" - "PDPC active enforcement" - "Singapore PDPA penalty cap" - "Singapore PDPA fine amount" - "PDPC financial penalty Singapore" - "Singapore data protection fines" - "PDPA compliance" - "DNC penalties Singapore" - "PDPA criminal offences" - "Singapore PDPA enforcement guide" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Singapore PDPA Penalties and Fines Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions. *Enforcement Guide* *APAC* ## Singapore PDPA Penalties and Fines Complete guide to Singapore PDPA penalties and fines: financial penalties up to SGD 1 million or 10% of annual Singapore turnover, PDPC enforcement directions, DNC fines, criminal offences, and practical controls to reduce penalty exposure under the Personal Data Protection Act. Understand every Singapore PDPA penalty type, how the PDPC calculates fines, what aggravating and mitigating factors apply, and how to build the evidence packs that measurably reduce enforcement risk. This page is a comprehensive guide to Singapore PDPA penalties and fines under the Personal Data Protection Act 2012. It covers every type of penalty the Personal Data Protection Commission (PDPC) can impose, from Singapore PDPA fines and compliance directions to criminal prosecution and private rights of action. The 2021 PDPA amendments, which took effect on 1 October 2022, introduced a turnover-based financial penalty cap and expanded voluntary undertaking powers, significantly increasing Singapore PDPA penalty exposure for large organisations. This guide is grounded in the PDPC's Advisory Guidelines on Enforcement of Data Protection Provisions (revised 1 October 2022) and the Guide on Active Enforcement. It is written for legal, compliance, security, and operations teams who need to understand Singapore PDPA fines exposure and build defensible evidence packs. Use the PDPA statute and PDPC advisory guidelines linked in the sources section below, and tailor the details to your organisation's processing context. ## Singapore PDPA penalties: maximum financial penalty framework The Singapore PDPA penalties framework was significantly strengthened by the 2021 amendments, which took effect on 1 October 2022. Under section 48J of the PDPA, the PDPC may require an organisation to pay a financial penalty for any intentional or negligent contravention of the Data Protection Provisions (Parts 3 through 6A of the PDPA). The Singapore PDPA penalty cap is the higher of SGD 1 million or 10% of the organisation's annual turnover in Singapore, where that turnover exceeds SGD 10 million. Before the 2021 amendments, the maximum Singapore PDPA fine was a fixed SGD 1 million regardless of organisation size. The turnover-based cap means that large organisations now face Singapore PDPA fines proportionate to their revenue. An organisation with SGD 200 million in annual Singapore turnover, for example, faces a theoretical maximum Singapore PDPA penalty of SGD 20 million. The annual turnover figure is drawn from the most recent audited accounts available at the time the penalty is imposed, as specified in section 48J(5A) of the PDPA. This ensures that Singapore PDPA fines reflect the organisation's current financial position rather than historical figures. It is important to note that these are maximum caps, not default Singapore PDPA penalty amounts. The PDPC exercises discretion in every case and has historically imposed Singapore PDPA fines well below the statutory maximum. The largest penalties before the 2021 amendments were SGD 750,000 against Integrated Health Information Systems and SGD 250,000 against Singapore Health Services in the 2018 SingHealth data breach case. Still, the higher Singapore PDPA penalty cap signals the PDPC's intent to impose fines that are proportionate, effective, and genuinely deterrent against non-compliance with the Personal Data Protection Act. The PDPC's Guide on Active Enforcement confirms that financial penalties under the Singapore PDPA are intended to achieve compliance and deter non-compliance. The PDPC will consider imposing a Singapore PDPA fine when it is necessary to reflect the seriousness of the breach. Singapore PDPA penalties apply only to intentional or negligent contraventions -- not to accidental breaches where the organisation exercised reasonable care. - Data Protection Provisions (Parts 3-6A): Singapore PDPA penalties up to SGD 1 million or 10% annual Singapore turnover, whichever is higher (turnover must exceed SGD 10 million for the percentage cap to apply). - Singapore PDPA fines apply only to intentional or negligent contraventions, not to accidental breaches where the organisation exercised reasonable care. - Annual turnover for Singapore PDPA penalty calculation is determined from the most recent audited accounts at the time the penalty is imposed (section 48J(5A)). - The PDPC has the power to register a Singapore PDPA financial penalty notice in the District Court under section 48M, giving it the same enforcement effect as a court order. - Before 1 October 2022, the maximum Singapore PDPA fine was a fixed SGD 1 million regardless of organisation size or revenue. - Organisations have at least 28 days after the notice is issued to make payment of the Singapore PDPA financial penalty. - The revised Singapore PDPA penalty caps took effect on 1 October 2022 as part of the enforcement amendments to the PDPA. - Singapore PDPA penalties serve two purposes under the PDPC's enforcement policy: achieving compliance and deterring non-compliance with the Personal Data Protection Act. *Recommended next step* *Placement: after the enforcement section* ## Use Singapore PDPA Penalties and Fines as a cited research workflow Research Copilot can take Singapore PDPA Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on Singapore PDPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Singapore PDPA Penalties and Fines](/solutions/research-copilot.md): Start from Singapore PDPA Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Singapore PDPA](/contact.md): Review your current process, evidence gaps, and next steps for Singapore PDPA Penalties and Fines. ## How the PDPC calculates Singapore PDPA fines The PDPC does not apply a fixed formula to calculate Singapore PDPA fines. Instead, it follows a structured assessment described in section 48J(6) of the PDPA and elaborated in the Advisory Guidelines on Enforcement of Data Protection Provisions (revised 1 October 2022) and the Guide on Active Enforcement. The Singapore PDPA penalty calculation involves two main stages: assessing harm and culpability, and then considering additional factors that may increase or decrease the penalty amount. The harm assessment for Singapore PDPA fines considers the number of individuals affected, the categories and sensitivity of personal data involved, and the duration of the incident. For example, a breach involving NRIC numbers and medical records of hundreds of thousands of individuals will attract a higher base amount than a disclosure of email addresses affecting a handful of people. The culpability assessment for Singapore PDPA penalties looks at the nature of the breach, whether the organisation acted intentionally or negligently, and the organisation's overall compliance posture at the time of the incident. After establishing a base amount from harm and culpability, the PDPC considers a range of statutory factors from section 48J(6) that can adjust Singapore PDPA fines upward or downward. These include whether the organisation took prompt and effective mitigation steps, whether it cooperated fully with the PDPC investigation, whether it had already implemented adequate data protection measures, and whether it had any history of prior contraventions. The PDPC also considers whether the organisation gained a financial benefit or avoided a financial loss from its non-compliance, and whether the final Singapore PDPA penalty amount is proportionate and effective in achieving compliance and deterrence. The PDPC's Guide on Active Enforcement adds that voluntary admission of liability, including admission through the Expedited Decision Procedure (EDP), is a factor the PDPC will consider favourably when determining Singapore PDPA fines. Cooperation with the PDPC during the course of investigation and whether the organisation is a first-time offender are also weighed. The PDPC then adjusts the Singapore PDPA penalty by considering its likely impact on the organisation, including the ability of the organisation to continue its usual activities. - Harm factors for Singapore PDPA fines: number of affected individuals, type and sensitivity of personal data, duration of the incident, and actual or potential harm to individuals. - Culpability factors for Singapore PDPA penalties: whether the contravention was intentional, negligent, or systemic; the organisation's overall PDPA compliance posture. - Financial benefit: whether the organisation profited from the contravention or avoided costs by not complying (treated as aggravating for Singapore PDPA fines). - Mitigation actions: timeliness and effectiveness of remediation steps taken after the incident directly affect Singapore PDPA penalty calibration. - Compliance history: whether the organisation has previously contravened the PDPA or failed to implement corrective measures from earlier cases. - Proportionality: Singapore PDPA fines must be proportionate and effective, considering the organisation's ability to continue its usual activities. - Prior measures: whether the organisation had adequate policies, processes, and technical measures in place before the incident mitigates Singapore PDPA penalties. - Voluntary admission through the Expedited Decision Procedure (EDP) is a factor the PDPC will consider favourably when setting Singapore PDPA fines. ## PDPC enforcement directions under section 48I of the Singapore PDPA Beyond Singapore PDPA fines, the PDPC has broad powers under section 48I of the PDPA to issue compliance directions. These directions are the primary enforcement tool and are issued more frequently than Singapore PDPA financial penalties. When the PDPC is satisfied that an organisation is not complying with any Data Protection Provision, it may give such directions as it thinks fit to bring the organisation into compliance with the Personal Data Protection Act. Section 48I(2) specifies three types of directions the PDPC may issue as part of Singapore PDPA enforcement: a direction to stop collecting, using, or disclosing personal data in contravention of the PDPA; a direction to destroy personal data collected in contravention of the PDPA; and a direction to comply with any prior direction the PDPC issued under section 48H(2). These directions can be combined with Singapore PDPA fines in serious cases, or issued on their own in less severe situations. The PDPC's Advisory Guidelines categorize directions into three practical types that complement Singapore PDPA penalties. First, directions to remedy the contravention, such as requiring an organisation to stop using personal data collected without valid consent. Second, directions to prevent or reduce harm to individuals affected by the breach, such as requiring the organisation to notify affected individuals or take protective measures. Third, directions to rectify an organisation's processes, such as requiring implementation of new security controls, staff training, or updated data protection policies. If an organisation fails to comply with a direction under section 48I, the PDPC can register it in the District Court under section 48M. Once registered, the direction has the same force and effect as a court order, and the PDPC can pursue enforcement through legal proceedings. Non-compliance with a registered direction effectively turns a Singapore PDPA enforcement action into a court enforcement matter. - Stop collection, use, or disclosure: the PDPC can order an organisation to immediately cease processing personal data that was collected or used in breach of the Singapore PDPA. - Destroy personal data: the PDPC can require destruction of personal data that was collected in contravention of the Singapore PDPA. - Comply with prior directions: the PDPC can direct an organisation to comply with a previously issued direction under section 48H(2) of the PDPA. - Remedy the contravention: correct the specific breach, such as removing improperly disclosed data from public access. - Prevent or reduce harm: require notification to affected individuals, credit monitoring, or other protective actions as part of Singapore PDPA enforcement. - Rectify processes: mandate changes to policies, security controls, staff training, access management, or vendor contracts to achieve Singapore PDPA compliance. - Directions can be registered in the District Court under section 48M and enforced as court orders, giving Singapore PDPA enforcement actions binding legal force. ## Singapore PDPA Do Not Call Registry penalties and fines The Singapore PDPA's Do Not Call (DNC) provisions in Part 9 carry their own penalty framework, separate from the Data Protection Provisions. Organisations and individuals who contravene the DNC Provisions face Singapore PDPA fines that vary depending on the type of contravention and whether the offender is an individual or an organisation. Understanding these separate Singapore PDPA penalty caps is essential for any organisation engaged in marketing communications to Singapore telephone numbers. For contraventions involving dictionary attacks and address-harvesting software under section 48B(1), the PDPC may impose a Singapore PDPA financial penalty of up to SGD 200,000 on an individual. For organisations, the cap is the higher of SGD 1 million or 5% of annual Singapore turnover, where that turnover exceeds SGD 20 million. Note that the turnover threshold for DNC dictionary-attack Singapore PDPA penalties (SGD 20 million) is higher than the threshold for Data Protection Provision penalties (SGD 10 million), and the percentage cap is lower (5% instead of 10%). For contraventions of other DNC provisions in Part 9 of the Singapore PDPA, the penalty cap for individuals is SGD 200,000, and for organisations it is a flat SGD 1 million. There is no turnover-based percentage for these other DNC Singapore PDPA fines. Common DNC violations that trigger Singapore PDPA penalties include sending marketing messages to phone numbers registered on the DNC registry, failing to check the DNC registry before sending messages, and failing to include unsubscribe options in marketing messages. - Dictionary attacks and address-harvesting software (section 48B(1)): Singapore PDPA fines up to SGD 200,000 for individuals; up to SGD 1 million or 5% annual Singapore turnover (whichever is higher) for organisations with turnover above SGD 20 million. - Other DNC contraventions (Part 9): Singapore PDPA penalties up to SGD 200,000 for individuals; up to SGD 1 million for organisations (no turnover-based cap). - The DNC Registry covers voice calls, text messages, and fax messages sent for marketing purposes under Singapore PDPA rules. - Organisations must check the DNC Registry before sending marketing messages to Singapore telephone numbers to avoid Singapore PDPA fines. - Failure to provide a functional unsubscribe option in marketing messages is a separate DNC contravention that attracts Singapore PDPA penalties. - The PDPC has published multiple enforcement decisions specifically for DNC violations, establishing a track record of Singapore PDPA fines for non-compliant telemarketing. ## Singapore PDPA criminal offences and individual liability The Singapore PDPA creates several criminal offences that can result in prosecution of individuals, not just organisations. Section 51 of the PDPA makes it an offence to obstruct or impede the PDPC in exercising its enforcement powers. Any individual who knowingly or recklessly makes a false statement to the PDPC, or who knowingly attempts to mislead the PDPC during an investigation, is guilty of an offence under the Singapore PDPA and is liable on conviction to a fine or imprisonment or both. The PDPC's Advisory Guidelines confirm that all organisations and individuals are required to comply with any notice or requirement imposed pursuant to the Commission's investigation powers. Individuals who contravene the DNC provisions face personal Singapore PDPA penalties of up to SGD 200,000. The PDPC has taken enforcement action against individuals who profited from the unauthorized sale of personal data. In the case of Sharon Assya Qadriyah Tang [2018] SGPDPC 1, the PDPC treated profiteering from the sale of personal data as an aggravating factor in calibrating the Singapore PDPA fine. In the Amicus Solutions case [2019] SGPDPC 33, the PDPC emphasized that profiting from the unauthorized sale of personal data is exactly the kind of activity the PDPA seeks to curb and warned that any profits from the unauthorised sale of personal data may be taken into account in calculating the Singapore PDPA penalty. The Singapore PDPA also provides individuals who suffer loss or damage from a contravention with a private right of action under section 48O. Any person who suffers loss or damage directly as a result of an organisation's contravention of Parts 4 through 6B, or of section 48B(1), may commence civil proceedings in the courts. A court hearing such an action may grant injunctions, declarations, damages, or any other relief it considers appropriate. This means organisations face dual exposure from Singapore PDPA enforcement: PDPC penalties and fines plus private lawsuits from affected individuals. - Obstruction of PDPC: knowingly making false statements, misleading the PDPC, or obstructing an investigation are criminal offences under section 51 of the Singapore PDPA. - Individual DNC penalties: Singapore PDPA fines up to SGD 200,000 for DNC violations by individuals, including for dictionary attacks and address harvesting. - Personal data trafficking: the PDPC has treated unauthorized sale of personal data as a severe aggravating factor, warning that profits may be factored into Singapore PDPA penalty calculations. - Private right of action (section 48O): individuals who suffer loss or damage can sue organisations in court for injunctions, damages, and other relief under the Singapore PDPA. - Civil proceedings are separate from PDPC enforcement and can proceed after the PDPC's decision becomes final, creating dual Singapore PDPA penalty exposure. - Non-compliance with PDPC investigation notices, including failing to produce documents or attend interviews, can constitute a criminal offence under the Singapore PDPA. ## Aggravating and mitigating factors for Singapore PDPA fines The PDPC's enforcement decisions reveal a consistent set of aggravating and mitigating factors drawn from section 48J(6) of the PDPA that directly affect Singapore PDPA penalty amounts. Understanding these factors is essential for any organisation that wants to minimize its Singapore PDPA fines exposure. The PDPC's Advisory Guidelines on Enforcement of Data Protection Provisions and the Guide on Active Enforcement provide detailed examples from past cases that illustrate how each factor works in practice when calibrating Singapore PDPA penalties. Key aggravating factors that increase Singapore PDPA fines include the sensitivity of the personal data involved (medical records, NRIC numbers, financial data), a large number of affected individuals, long duration of the breach before detection, prior contraventions of the PDPA by the same organisation, financial benefit derived from non-compliance, failure to implement corrective measures from earlier cases, and handling large volumes of personal data where disclosure could cause exceptional harm. In Ninja Logistics [2019] SGPDPC 39, the PDPC treated the organisation's failure to resolve a known vulnerability for over two years as aggravating for Singapore PDPA penalty calibration. In SPH Magazines [2020] SGPDPC 3, a compromised password unchanged for 10 years and inability to detect unauthorized access for about two years were both treated as aggravating factors for the Singapore PDPA fine. Key mitigating factors that reduce Singapore PDPA fines include prompt and effective remediation action, existing compliance measures and policies before the incident, cooperation with the PDPC investigation, limited scope of disclosure (few individuals, short duration), voluntary admission of liability through the Expedited Decision Procedure, and the organisation's financial circumstances. In Zero1 Pte. Ltd. and XDEL Singapore [2019] SGPDPC 37, XDEL's quick remedial action to fix a code vulnerability was treated as mitigating for the Singapore PDPA penalty. In Singapore Telecommunications [2019] SGPDPC 49, implementing a temporary fix within 11 hours was considered mitigating. The PDPC has also reduced Singapore PDPA fines for small businesses facing crushing financial burden, as in the Advance Home Tutors case [2019] SGPDPC 35. Repeat contraventions are a particularly significant aggravating factor for Singapore PDPA penalties. In Aviva Ltd [2018] SGPDPC 4, the PDPC treated the fact that the organisation had encountered a similar incident previously as aggravating. In Aviva Ltd and Toh-Shi Printing Singapore [2016] SGPDPC 15, the financial penalty took into account that this was the second time within about a year that a breach of the same case fact pattern had occurred. Organisations with prior Singapore PDPA enforcement history should expect increased fines if they fail to prevent recurrence. - Aggravating for Singapore PDPA fines: sensitive data categories (medical, NRIC, financial), large number of affected individuals, long undetected breach duration. - Aggravating for Singapore PDPA penalties: prior PDPA contraventions, prior similar incidents, failure to implement earlier corrective measures. - Aggravating for Singapore PDPA fines: financial benefit or avoided cost from non-compliance, deliberate profiteering from personal data sales. - Aggravating for Singapore PDPA penalties: handling large data volumes where disclosure could cause exceptional damage to individuals (Aviva Ltd [2018] SGPDPC 4). - Mitigating for Singapore PDPA fines: prompt remediation (hours or days, not weeks), effective technical fix, and proactive notification to affected individuals. - Mitigating for Singapore PDPA penalties: existing data protection policies, regular security audits, penetration testing, and staff training programs before the incident. - Mitigating for Singapore PDPA fines: full cooperation with the PDPC investigation, voluntary disclosure of the breach, voluntary admission of liability through the EDP, and financial hardship. - The PDPC has precedent for reducing Singapore PDPA penalties when the organisation demonstrates genuine inability to pay without being forced to cease operations. ## Voluntary undertakings as alternatives to Singapore PDPA penalties The 2021 PDPA amendments introduced a formal voluntary undertaking mechanism under section 48L as an alternative to Singapore PDPA fines and formal enforcement. The PDPC may accept a written voluntary undertaking from an organisation or person where it has reasonable grounds to believe the organisation has not complied, is not complying, or is likely not to comply with the Data Protection Provisions or DNC Provisions. Voluntary undertakings allow organisations to avoid Singapore PDPA penalties by implementing a remediation plan, but the PDPC retains the right to proceed with enforcement at any time. The PDPC's Guide on Active Enforcement explains that a voluntary undertaking request must be made soon after the incident is known, either upon commencement of investigations or in the early stages. Two conditions create the possibility of a voluntary undertaking as an alternative to Singapore PDPA fines: first, the organisation must demonstrate that it has accountable policies and practices in place (for example, IMDA Data Protection Trustmark certification or effective monitoring and breach management systems); second, the organisation must be ready with a remediation plan and committed to implement it immediately. The remediation plan should explain the likely causes of the incident, the proposed steps to address them, and the targeted completion dates. The PDPC will not accept voluntary undertakings in all circumstances where Singapore PDPA penalties might otherwise apply. The PDPC is unlikely to accept a voluntary undertaking when the organisation refutes responsibility, when it is a repeat incident with similar causes, when the remediation plan is inadequate, when the organisation requests extended time to produce a remediation plan, or when the breach is wilful or egregious. If an organisation fails to comply with the terms of an accepted voluntary undertaking, the PDPC may issue any direction it considers appropriate under section 48K to enforce the undertaking, or it may institute or resume a full investigation that could lead to Singapore PDPA fines and directions. Accepted voluntary undertakings are published by the PDPC, creating a form of public accountability even though no formal finding of breach is issued and no Singapore PDPA financial penalty is imposed. The organisation's execution of a voluntary undertaking does not amount to an admission of breach of the PDPA. However, if the organisation withdraws its request, the PDPC may proceed with a full investigation and impose any enforcement outcome, including Singapore PDPA penalties and fines. - Section 48L allows the PDPC to accept written voluntary undertakings instead of imposing Singapore PDPA fines or conducting a formal investigation. - Undertakings may require specific remediation actions within a specified timeframe, such as improving security controls or running penetration tests. - Two prerequisites for a voluntary undertaking: demonstrated accountability practices (such as IMDA Data Protection Trustmark) and a ready remediation plan. - The PDPC will generally not accept voluntary undertakings where non-compliance is willful or egregious -- Singapore PDPA penalties will be pursued instead. - Failure to comply with a voluntary undertaking empowers the PDPC to issue directions, resume investigation, or impose Singapore PDPA fines. - The PDPC publishes voluntary undertakings, creating public accountability even without a formal Singapore PDPA penalty finding. - Voluntary undertakings do not amount to an admission of breach of the Singapore PDPA. - If an organisation withdraws its voluntary undertaking request, the PDPC may proceed with full investigation and impose Singapore PDPA penalties and fines. ## Comparison of Singapore PDPA penalties with GDPR and other APAC frameworks Singapore PDPA penalties are moderate compared to the EU's GDPR but competitive within the APAC region. The GDPR allows administrative fines of up to EUR 20 million or 4% of global annual turnover, whichever is higher. Singapore PDPA fines cap at SGD 1 million or 10% of Singapore turnover and apply only to local revenue, making the effective Singapore PDPA penalty lower for multinational organisations that derive most of their revenue outside Singapore. Within APAC, Singapore PDPA penalties are broadly comparable to other mature frameworks. Australia's Privacy Act allows civil penalties of up to AUD 50 million, three times the benefit obtained from the contravention, or 30% of adjusted turnover, whichever is greatest. South Korea's PIPA allows fines of up to 3% of relevant revenue. Japan's APPI has historically had low monetary penalties but strengthened criminal sanctions in its 2022 amendments. The Philippines' Data Privacy Act allows fines of up to PHP 5 million (roughly SGD 120,000) plus imprisonment. A key difference between Singapore PDPA fines and GDPR fines is the fault requirement. The Singapore PDPA requires intentional or negligent conduct for a financial penalty, while the GDPR applies strict liability for administrative fines. This means that under the Singapore PDPA, an organisation that can demonstrate it took all reasonable steps to comply may avoid a financial penalty entirely, even if a breach occurred. This makes the quality of the organisation's data protection management programme (DPMP) and evidence of compliance particularly important for reducing Singapore PDPA penalty exposure. Another notable difference is the Singapore PDPA's explicit voluntary undertaking mechanism, which has no direct equivalent in GDPR enforcement. The PDPC's willingness to accept undertakings in appropriate cases provides an additional pathway for organisations to resolve enforcement matters without Singapore PDPA fines or formal directions. The GDPR does allow supervisory authorities to impose corrective measures without fines, but this is generally at the discretion of each national DPA rather than a structured framework like the Singapore PDPA's section 48L voluntary undertaking process. - GDPR: up to EUR 20 million or 4% of global annual turnover; strict liability; no voluntary undertaking framework. - Singapore PDPA penalties: up to SGD 1 million or 10% of Singapore turnover; requires intentional or negligent conduct; voluntary undertakings available. - Australia Privacy Act: up to AUD 50 million, 3x benefit, or 30% adjusted turnover; strict civil penalty regime -- higher maximum than Singapore PDPA fines. - South Korea PIPA: up to 3% of relevant revenue for data breach violations. - Japan APPI: lower monetary fines but strengthened criminal sanctions; imprisonment for certain violations. - Singapore PDPA penalties require fault (intent or negligence); GDPR fines do not -- a critical difference for enforcement exposure. - Singapore PDPA fines apply to Singapore revenue only; GDPR fines apply to global turnover -- important for multinationals comparing penalty exposure. - The Singapore PDPA's voluntary undertaking mechanism provides a structured alternative to formal enforcement and fines that most other frameworks lack. ## Reputational and business impact beyond Singapore PDPA fines Singapore PDPA penalties extend far beyond direct financial fines. The PDPC publishes most enforcement decisions on its website, naming the organisation involved and describing the facts of the case in detail. This publication practice, mandated under regulations 17 through 19 of the Enforcement Regulations, is explicitly intended to promote transparency and allow other organisations to learn from enforcement outcomes. The reputational damage from a published PDPC decision often exceeds the direct Singapore PDPA financial penalty imposed. A published PDPC decision typically describes the nature of the breach, the personal data involved, the number of affected individuals, the security weaknesses that led to the incident, and the organisation's response. The PDPC's Advisory Guidelines confirm that the Commission will generally publish a Decision relating to an organisation found to have contravened the Singapore PDPA, for reasons of transparency and so that other organisations may take preventive measures to avoid similar occurrences. This information is picked up by local and international media, industry analysts, and business partners, amplifying the consequences beyond the Singapore PDPA fine itself. Beyond reputation, Singapore PDPA enforcement actions create operational costs that can be substantial. Compliance directions may require organisations to overhaul security infrastructure, retrain staff, engage external consultants, conduct penetration testing, and rebuild processes. The PDPC's investigations themselves consume management time and legal resources over months or even years -- the Guide on Active Enforcement estimates full investigations can take up to 18 months. Organisations that face a private right of action from affected individuals under section 48O may also incur litigation costs and potential damages awards on top of the Singapore PDPA penalty. - The PDPC publishes most Singapore PDPA enforcement decisions by name, including full details of the breach, security weaknesses, and fine amount. - Published decisions serve transparency goals and provide guidance to other organisations, as mandated by regulations 17-19 of the Enforcement Regulations. - Media coverage of Singapore PDPA enforcement decisions amplifies reputational damage beyond the immediate financial penalty. - Compliance directions issued alongside Singapore PDPA fines can require costly infrastructure upgrades, process redesign, and staff retraining. - PDPC investigations consume significant management time and legal resources -- full investigations can take up to 18 months per the Active Enforcement Guide. - Private right of action under section 48O exposes organisations to additional litigation costs and potential damages on top of Singapore PDPA penalties. - Business partners and customers may reconsider relationships after a published Singapore PDPA enforcement decision. - Insurance, procurement, and vendor onboarding processes increasingly reference PDPC enforcement history and Singapore PDPA fines track records. ## Steps to reduce Singapore PDPA penalty exposure and build enforcement readiness The PDPC's enforcement decisions consistently show that organisations with a functioning Data Protection Management Programme (DPMP), documented policies, and proactive security measures receive lower Singapore PDPA fines. Building enforcement readiness is not about avoiding all breaches, which is unrealistic, but about demonstrating that you took reasonable and appropriate steps before an incident occurred and responded effectively when it did. Every mitigating factor the PDPC recognizes maps to a specific control or evidence item that reduces Singapore PDPA penalty exposure. Start with the fundamentals to minimize Singapore PDPA fines risk: appoint a data protection officer (DPO), develop and maintain a DPMP that covers all PDPA obligations, and document your compliance decisions. Record your lawful basis for each category of processing, your consent mechanisms, your retention schedules, and your data transfer safeguards. The PDPC has treated the existence of documented policies and regular audits as mitigating factors in multiple enforcement decisions, including PropNex Realty [2017] SGPDPC 1 and ComGateway [2017] SGPDPC 19, resulting in lower Singapore PDPA penalties. Invest in breach readiness to reduce Singapore PDPA penalty exposure when incidents occur. Run tabletop exercises and maintain incident response playbooks. Document your notification decision-making process and timelines. The 2021 PDPA amendments introduced mandatory data breach notification requirements, and the speed and quality of your response will directly affect Singapore PDPA fine outcomes. Ensure your vendor and intermediary contracts include data protection requirements under section 4(2) and audit rights, and conduct regular reviews of your vendor security posture. Finally, prepare an evidence pack that can be produced during a PDPC investigation to demonstrate compliance and mitigate Singapore PDPA penalties. The PDPC's investigation powers under the Ninth Schedule to the PDPA are extensive and include the power to require production of documents and information, require attendance and oral examination, enter premises without a warrant, and enter premises with a warrant. An organisation that can quickly produce organized evidence of its compliance programme, training records, security audit results, and incident response logs will be in a significantly better position to receive reduced Singapore PDPA fines than one that cannot. - Appoint a DPO and maintain a living DPMP with documented policies, training records, and review cadence to reduce Singapore PDPA penalty exposure. - Document all processing decisions: lawful basis, consent records, exception usage, and transfer safeguards as evidence against Singapore PDPA fines. - Conduct regular security assessments, penetration testing, and vulnerability scans, and retain the reports -- these are recognized mitigating factors for Singapore PDPA penalties. - Run breach response tabletop exercises at least annually and maintain incident response playbooks to demonstrate readiness during Singapore PDPA enforcement. - Ensure vendor and intermediary contracts include PDPA-compliant data protection clauses and audit rights to reduce Singapore PDPA penalty exposure. - Maintain a centralized evidence index covering scope, consent, access/correction requests, breach history, and vendor oversight for Singapore PDPA compliance. - Respond quickly and cooperate fully with any PDPC investigation -- prompt cooperation is a recognized mitigating factor that reduces Singapore PDPA fines. - Review PDPC published enforcement decisions regularly to identify emerging risk areas and update your compliance programme to avoid Singapore PDPA penalties. ## Primary sources - [Personal Data Protection Act 2012 (Singapore) - official text](https://sso.agc.gov.sg/Act/PDPA2012?ref=sorena.io) - Primary legislation governing Singapore PDPA penalties, fines, collection, use, disclosure, protection, retention, transfer, and accountability for personal data. - [PDPC - Advisory Guidelines on Enforcement of Data Protection Provisions (revised 1 October 2022)](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-enforcement-of-data-protection-provisions?ref=sorena.io) - Detailed enforcement approach for Singapore PDPA penalties: directions, financial fines, voluntary undertakings, aggravating and mitigating factors, reconsideration procedures, and investigation powers. - [PDPC - Guide on Active Enforcement (revised 1 October 2022)](https://www.pdpc.gov.sg/help-and-resources/2019/05/guide-on-active-enforcement?ref=sorena.io) - How the PDPC deploys enforcement powers on data breach incidents, including facilitation, mediation, investigation approaches, types of enforcement outcomes, and Singapore PDPA financial penalty calculation methodology. - [PDPC - Amendments to enforcement announcement (1 October 2022)](https://www.pdpc.gov.sg/news-and-events/announcements/2022/09/amendments-to-enforcement-under-the-personal-data-protection-act-in-updated-advisory-guidelines-and-guide?ref=sorena.io) - Official announcement of the enhanced Singapore PDPA financial penalty cap (10% turnover) and voluntary undertaking powers effective 1 October 2022. - [PDPC - PDPA overview](https://www.pdpc.gov.sg/overview-of-pdpa/pdpa-overview?ref=sorena.io) - Official PDPC overview of PDPA obligations, key concepts, and updates relevant to Singapore PDPA penalties and fines. - [PDPC - Key Concepts advisory guidelines](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-the-personal-data-protection-act?ref=sorena.io) - Core interpretation guidance for consent, purposes, notification, access/correction, accuracy, protection, retention, transfers, and accountability obligations under the Singapore PDPA. ## Related Topic Guides - [Singapore PDPA Applicability Test | Does the PDPA Apply to Your Organisation?](/artifacts/apac/singapore-pdpa/applicability-test.md): Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation. - [Singapore PDPA Breach Notification Playbook - Complete Guide](/artifacts/apac/singapore-pdpa/breach-notification-playbook.md): Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline. - [Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026)](/artifacts/apac/singapore-pdpa/checklist.md): Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules. - [Singapore PDPA Compliance Deadlines and Calendar](/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar.md): Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows. - [Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM](/artifacts/apac/singapore-pdpa/compliance.md): Complete Singapore PDPA compliance guide for organisations. - [Singapore PDPA Consent and Notification Obligations Guide](/artifacts/apac/singapore-pdpa/consent-notification-and-purposes.md): Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception. - [Singapore PDPA Cross-Border Transfer Rules | Section 26 Data Transfer Compliance](/artifacts/apac/singapore-pdpa/cross-border-transfers.md): Complete guide to Singapore PDPA cross-border transfer compliance under Section 26. - [Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide](/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages.md): Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses. - [Singapore PDPA FAQ | Frequently Asked Questions on Personal Data Protection Act Compliance](/artifacts/apac/singapore-pdpa/faq.md): Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements. - [Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions](/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases.md): Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover. - [Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide](/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template.md): Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions. - [Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC)](/artifacts/apac/singapore-pdpa/requirements.md): Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18). - [Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations](/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries.md): Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion. - [Singapore PDPA Vendor Outsourcing and Contracts Guide](/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts.md): Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence. - [Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties](/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr.md): Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/singapore-pdpa/penalties-and-fines --- --- title: "Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC)" canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/requirements" source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/requirements" author: "Sorena AI" description: "Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Singapore PDPA requirements" - "Singapore PDPA compliance" - "Personal Data Protection Act Singapore" - "Singapore PDPA obligations" - "Singapore PDPA consent obligation" - "Singapore PDPA deemed consent" - "Singapore PDPA notification obligation" - "Singapore PDPA purpose limitation" - "Singapore PDPA access request" - "Singapore PDPA correction request" - "Singapore PDPA protection obligation" - "Singapore PDPA retention limitation" - "Singapore PDPA transfer limitation" - "Singapore PDPA data breach notification" - "Singapore PDPA accountability obligation" - "Singapore PDPA data protection management programme" - "Singapore PDPA DNC registry" - "Singapore PDPA Do Not Call" - "Singapore PDPA data portability" - "Singapore PDPA checklist" - "Singapore PDPA evidence index" - "Singapore PDPA penalties" - "PDPC enforcement" - "PDPC guidelines" - "PDPA Section 24 security" - "PDPA Section 26 cross border transfer" - "PDPA Sections 26A-26E breach notification" - "PDPA legitimate interests exception" - "PDPA business improvement exception" - "PDPA data intermediary" - "Singapore personal data protection" - "Singapore privacy law" - "PDPA compliance guide" - "Singapore PDPA" - "Personal Data Protection Act" - "PDPA compliance" - "PDPA obligations" - "PDPA consent obligation" - "PDPA protection obligation" - "PDPA breach notification" - "PDPA evidence index" - "APAC privacy law" - "Singapore data protection" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC) Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18). *Requirements Guide* *APAC* ## Singapore PDPA Requirements A complete map of Singapore PDPA requirements -- covering all ten Data Protection Provisions, Do Not Call obligations, and the data portability framework. Translate every Singapore PDPA requirement into controls, owners, and evidence artifacts that make compliance defensible during PDPC inquiries. The Singapore Personal Data Protection Act (PDPA) defines the baseline standard of protection for personal data in Singapore. Understanding Singapore PDPA requirements is essential for every organisation that collects, uses, or discloses personal data -- whether in electronic or non-electronic form. The PDPA establishes ten core Data Protection Provisions, Do Not Call (DNC) rules under Part IX, and a data portability framework under Section 26H. This page maps every Singapore PDPA requirement to the controls, owners, and evidence artifacts your teams need to build. The PDPA was enacted in 2012, with the main data protection rules effective from 2 July 2014 and significant amendments taking effect in phases from 1 February 2021. Singapore PDPA requirements apply to all organisations in Singapore, with limited exceptions for individuals acting in a personal or domestic capacity, employees acting in the course of employment, public agencies, and business contact information. The Personal Data Protection Commission (PDPC) administers and enforces the PDPA, issuing advisory guidelines that clarify how Singapore PDPA requirements should be interpreted and applied in practice. ## Singapore PDPA Requirements for Accountability (Sections 11-12) The Accountability Obligation under Sections 11 and 12 is the foundation of all Singapore PDPA requirements. Every organisation must implement the policies and procedures necessary to meet its obligations under the PDPA and make information about those policies publicly available. This Singapore PDPA requirement ensures that organisations take a structured, proactive approach to data protection rather than treating compliance as an afterthought. Section 12 of the PDPA requires organisations to designate at least one Data Protection Officer (DPO) who is responsible for ensuring compliance with the PDPA. The DPO's business contact information must be made publicly available so individuals can direct inquiries, access requests, and complaints to a clearly identified person. This is one of the most visible Singapore PDPA requirements and is often the first thing the PDPC checks during an investigation. The PDPC's Guide to Developing a Data Protection Management Programme (DPMP) provides the authoritative framework for meeting Singapore PDPA requirements for accountability. A DPMP is a four-step programme covering governance and risk assessment, policies and practices, processes, and maintenance. Organisations that invest in a comprehensive DPMP find it significantly easier to demonstrate compliance during PDPC investigations or enforcement proceedings. Under the DPMP framework, senior management is responsible for defining strategic corporate values around data protection, allocating resources, appointing and empowering the DPO, monitoring data protection risks as part of corporate governance, and approving the organisation's data protection policies. This leadership commitment is central to meeting Singapore PDPA requirements for accountability. - Designate a DPO by name and publish their business contact information on your website, forms, and correspondence to satisfy Singapore PDPA requirements under Section 11(5). - Develop a Data Protection Management Programme (DPMP) covering governance structure, risk assessment, policies and practices, operational processes, and maintenance schedules. - Create and publish a Data Protection Policy (Privacy Policy) that explains your data protection practices in clear, accessible language. - Maintain a personal data inventory mapping every data category to its collection source, purpose, retention period, disclosure recipients, and transfer destinations. - Conduct regular Data Protection Impact Assessments (DPIAs) to identify gaps in data protection controls and prioritise remediation. - Implement a training programme so all employees understand the Singapore PDPA requirements relevant to their roles, with refresher training at least annually. - Document all data protection policies, decisions, and incident responses as evidence of compliance with Singapore PDPA requirements. - Review and update your DPMP at least annually or whenever there are significant changes to your data processing activities. *Recommended next step* *Placement: after the requirement breakdown* ## Turn Singapore PDPA Requirements into an operational assessment Assessment Autopilot can take Singapore PDPA Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on Singapore PDPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Singapore PDPA Requirements](/solutions/assessment.md): Start from Singapore PDPA Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Singapore PDPA](/contact.md): Review your current process, evidence gaps, and next steps for Singapore PDPA Requirements. ## Singapore PDPA Requirements for Consent (Sections 13-17) The Consent Obligation under Sections 13 to 17 is one of the most critical Singapore PDPA requirements. Organisations must obtain the consent of an individual before collecting, using, or disclosing their personal data. Consent is only valid when the individual has been notified of the purposes for collection, use, or disclosure and has provided consent for those specific purposes. If an organisation fails to notify the individual of the purposes before obtaining consent, any consent obtained is invalid under Section 14(1) of the PDPA. The PDPA recognises three forms of consent, and understanding each form is essential to meeting Singapore PDPA requirements. Express consent is obtained in writing or recorded in an accessible manner and provides the clearest proof. Deemed consent arises in three situations under the PDPA: deemed consent by conduct (Section 15), deemed consent by contractual necessity (Section 15(3)), and deemed consent by notification (Section 15A). Each form has specific conditions that organisations must understand and apply correctly to comply with Singapore PDPA requirements. Section 14(2) places important restrictions on how organisations may obtain consent under the PDPA. An organisation providing a product or service must not require consent beyond what is reasonable to provide that product or service. Organisations must not obtain consent through false or misleading information or deceptive practices. Any consent obtained in violation of these restrictions is invalid under Section 14(3). These restrictions are a key aspect of Singapore PDPA requirements that the PDPC actively enforces. Individuals have the right to withdraw consent at any time under Section 16 of the PDPA. Organisations must allow and facilitate the withdrawal of consent and inform the individual of the likely consequences of withdrawing consent. Upon receiving a withdrawal notice, the organisation must cease the relevant data processing within a reasonable timeframe. This withdrawal mechanism is one of the Singapore PDPA requirements that directly empowers individuals. - Build a consent capture system that records the purpose, timestamp, method of consent (express, deemed by conduct, deemed by contractual necessity, or deemed by notification), and the specific notification provided. - For express consent, use clear opt-in mechanisms such as checkboxes, signed forms, or recorded verbal confirmation followed by written confirmation. - For deemed consent by notification (Section 15A), conduct a documented assessment confirming no adverse effect on individuals, provide adequate notification, and allow a reasonable opt-out period. - Never require consent for purposes beyond what is reasonable to provide the product or service -- this violates Singapore PDPA requirements under Section 14(2). - Implement a consent withdrawal workflow that processes withdrawal requests, informs the individual of consequences, and ceases relevant data processing within a reasonable period. - Maintain a consent register logging the status (active, withdrawn, expired) of each consent record, linked to the corresponding purposes and processing activities. - Where consent exceptions apply (First and Second Schedules of the PDPA), document the specific exception relied upon and the reasoning for its application. - Use the PDPC's Assessment Checklist for Deemed Consent by Notification (Annex B of the Advisory Guidelines) as a template for your documented assessments. ## Singapore PDPA Requirements for Purpose Limitation (Section 18) The Purpose Limitation Obligation under Section 18 is a core Singapore PDPA requirement that restricts organisations to collecting, using, or disclosing personal data only for purposes that a reasonable person would consider appropriate in the circumstances. Where applicable, these purposes must also have been notified to the individual. This Singapore PDPA requirement works together with the Consent and Notification Obligations to prevent organisations from using personal data in ways individuals would not expect. Whether a purpose satisfies Singapore PDPA requirements depends on the reasonableness standard. A purpose that violates any law or that would be harmful to the individual is unlikely to be considered appropriate. Vague or open-ended purpose statements such as 'any other purpose that the organisation deems fit' do not meet Singapore PDPA requirements because they do not give the individual meaningful information about how their data will be used. When an organisation wants to use or disclose personal data for a new purpose not originally notified, it must assess whether the new purpose falls within the original scope, whether deemed consent applies, or whether a consent exception applies. If none of these apply, Singapore PDPA requirements mandate that the organisation obtain fresh consent from the individual before proceeding. - Create a purpose register mapping each data processing activity to one or more specific, clearly articulated purposes that satisfy Singapore PDPA requirements for reasonableness. - Review each stated purpose against the reasonableness standard: would a reasonable person consider this purpose appropriate given the context of data collection? - Avoid vague or overly broad purpose statements in notices and policies -- these do not meet Singapore PDPA requirements under Section 18. - When planning a new use of existing personal data, document your assessment of whether it falls within the original purposes, qualifies for deemed consent, or requires fresh consent. - Align your purpose register with consent records and notification documents to create a clear audit trail satisfying Singapore PDPA requirements. - Periodically review your stated purposes to ensure they remain relevant, reasonable, and compliant with Singapore PDPA requirements. ## Singapore PDPA Requirements for Notification (Section 20) The Notification Obligation under Section 20 is a foundational Singapore PDPA requirement that ensures individuals know why their personal data is being collected, used, or disclosed. Notification must happen on or before the collection of personal data, or before any new use or disclosure for a purpose not previously communicated. Without proper notification, consent cannot be meaningful -- making this one of the most interconnected Singapore PDPA requirements. The PDPA does not prescribe a specific manner or form for notification, but written notification is generally recommended because it provides clear documentation. Organisations may notify individuals through service agreements, data protection notices, privacy policies on their website, or a combination. The PDPC considers a layered notice approach to be good practice -- presenting the most important information prominently at the point of data collection while directing individuals to more detailed information elsewhere. Meeting Singapore PDPA requirements for notification requires organisations to map every data collection point and ensure a notification mechanism is in place at each one. This includes website forms, mobile applications, in-person interactions, telephone calls, and paper forms. Each notification must state purposes at an appropriate level of detail so individuals can understand why their data is being collected and how it will be used. - Map every data collection point (website forms, mobile apps, in-person interactions, telephone calls, paper forms) and confirm a notification mechanism exists at each one to meet Singapore PDPA requirements. - State purposes at an appropriate level of detail so individuals understand why their data is collected, how it will be used, and who it may be disclosed to. - Use a layered notice approach: provide a summary of key purposes and the DPO contact at the point of collection, with a link to the full Data Protection Policy. - Draft notices in plain language, highlighting any purposes that may be unexpected or of special concern to the individual. - Ensure notifications are provided before or at the time of data collection -- providing them after collection violates Singapore PDPA requirements. - When using personal data for a new purpose, provide fresh notification and obtain consent before proceeding as required by Singapore PDPA requirements. - Maintain a notification register recording which notice version was shown to which individuals and when, to provide evidence of compliance. - Review notification practices regularly and update notices when purposes change or new processing activities are introduced. ## Singapore PDPA Requirements for Access and Correction (Sections 21-22) The Access and Correction Obligations under Sections 21, 22, and 22A are Singapore PDPA requirements that give individuals the right to request access to their personal data held by an organisation, along with information about how that data has been used or disclosed in the past year. Individuals also have the right to request correction of errors or omissions. These Singapore PDPA requirements apply to data in the organisation's possession as well as data under its control, including data held by data intermediaries. For access requests, Singapore PDPA requirements mandate a response as soon as reasonably possible. If the organisation cannot respond within 30 calendar days, it must inform the individual in writing of when it expects to respond. Organisations may charge a reasonable fee reflecting the incremental cost of providing access, but a written estimate must be given before processing. The PDPA specifies exceptions where access may or must be refused, including situations that could threaten safety, reveal data about another individual, or be contrary to the national interest. For correction requests, Singapore PDPA requirements state that organisations must correct errors as soon as practicable and propagate corrections to every other organisation to which the data was disclosed in the past year. No fee may be charged for corrections. If an organisation declines to make a correction, it must annotate the data to note the requested correction that was not made. Section 22A requires organisations to preserve a complete and accurate copy of personal data if they refuse an access request. This preservation must last at least 30 calendar days after rejection, allowing the individual time to seek a review by the PDPC. This is one of the Singapore PDPA requirements designed to prevent organisations from destroying evidence before individuals can exercise their rights. - Build a standardised access and correction request workflow with intake forms, identity verification procedures, and response templates to meet Singapore PDPA requirements. - Implement identity verification procedures before responding to any request to prevent unauthorised disclosure of personal data. - Set internal SLA targets for responding within 30 calendar days, with an escalation process for requests requiring more time. - Create a fee schedule for access requests based on incremental costs and provide written estimates before processing begins. - Map all data repositories (databases, email archives, cloud storage, data intermediary systems) so you can locate requested personal data efficiently. - Document exceptions relied upon when refusing access or correction requests, and inform the individual of the reason for refusal. - Preserve a complete copy of withheld personal data for at least 30 calendar days after rejecting an access request. - When correcting personal data, propagate corrections to all organisations that received the data in the past year. ## Singapore PDPA Requirements for Accuracy (Section 23) The Accuracy Obligation under Section 23 is a Singapore PDPA requirement that organisations make a reasonable effort to ensure personal data is accurate and complete when it is likely to be used to make a decision affecting the individual or disclosed to another organisation. The standard is one of reasonable effort, not absolute accuracy, and the level of effort required depends on the circumstances. In determining what constitutes reasonable effort under Singapore PDPA requirements, organisations should consider the nature and significance of the data, the purpose for which it was collected, the reliability of the data source, how current the data is, and the potential impact on the individual if the data is inaccurate. Health records used for medical decisions require a higher standard of accuracy than general contact information used for marketing. When personal data is provided directly by the individual, organisations may generally presume it is accurate. However, when collecting from third-party sources, Singapore PDPA requirements call for greater care -- verifying the source's reliability, obtaining confirmation the data has been verified, or conducting independent verification. Organisations that derive personal data through analytics or profiling must also ensure the raw data is accurate and the derivation methods are correctly applied. - Identify which personal data categories are used for decision-making or disclosed to third parties -- these trigger the Accuracy Obligation under Singapore PDPA requirements. - Implement data quality checks at the point of collection, including validation rules for structured data fields and declarations from individuals confirming accuracy. - Establish processes for periodic review and update of personal data, especially data used for significant decisions about individuals. - When collecting personal data from third-party sources, verify the reliability of the source and consider independent confirmation as required by Singapore PDPA requirements. - For derived personal data (analytics, profiling, scoring), validate that raw input data is accurate and processing logic is correctly applied. - Document your data quality procedures and the reasonable efforts made to ensure accuracy as part of your overall accountability evidence. ## Singapore PDPA Requirements for Protection (Section 24) The Protection Obligation under Section 24 is one of the most scrutinised Singapore PDPA requirements. Organisations must protect personal data in their possession or under their control by making reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal, and loss of storage media or devices. There is no one-size-fits-all solution -- security arrangements must be reasonable and appropriate given the circumstances. In determining what security arrangements satisfy Singapore PDPA requirements, organisations should consider the nature and sensitivity of the personal data, the form in which it is stored (physical or electronic), the possible impact on individuals if the data is compromised, and the size of the organisation. Highly sensitive data such as financial records, health information, NRIC numbers, or employee appraisals requires stronger protections than general business contact information. The PDPC's advisory guidelines outline three categories of security measures that organisations should implement to meet Singapore PDPA requirements for protection: administrative measures (policies, procedures, training, confidentiality obligations), physical measures (locked cabinets, restricted access areas, secure disposal), and technical measures (encryption, access controls, network security, software updates). A comprehensive protection programme combines all three categories and scales controls to the sensitivity and volume of personal data held. Meeting Singapore PDPA requirements for protection also extends to data intermediaries and third-party service providers. Organisations must ensure through contractual obligations and periodic assessments that these parties maintain security arrangements at least comparable to their own. The PDPC's Guide to Managing Data Intermediaries provides detailed guidance on these contractual requirements. - Conduct a data protection risk assessment to identify the personal data you hold, its sensitivity, and the threats and vulnerabilities applicable to your environment. - Implement administrative measures: employee confidentiality clauses, data handling policies with disciplinary consequences, regular staff training, and data minimisation principles. - Implement physical measures: locked storage for confidential documents, restricted access on a need-to-know basis, secure disposal through shredding or certified destruction. - Implement technical measures: network security controls, role-based access control with strong authentication, encryption for data at rest and in transit, automatic screen locking, regular software updates, and secure data disposal on decommissioned devices. - Ensure data intermediaries maintain security arrangements comparable to your own through contractual clauses and periodic assessments as required by Singapore PDPA requirements. - Test your security arrangements regularly through vulnerability assessments, penetration testing, and security audits. - Consider adopting Data Protection by Design (DPbD) principles to embed data protection into systems from the earliest design stage. - Document all security measures, risk assessments, and remediation actions as evidence of compliance with Singapore PDPA requirements under Section 24. ## Singapore PDPA Requirements for Retention Limitation (Section 25) The Retention Limitation Obligation under Section 25 is a Singapore PDPA requirement that organisations stop retaining personal data -- or remove the means by which it can be associated with particular individuals -- as soon as it is reasonable to assume the original purpose is no longer served and retention is no longer necessary for any legal or business purpose. The PDPA does not prescribe fixed retention periods; duration is assessed on a standard of reasonableness. Retention periods under Singapore PDPA requirements depend on two factors: whether any original purposes remain valid, and whether other legal or business purposes require continued retention. Legal purposes include obligations under other laws (such as tax or employment legislation) and the need to retain records for potential legal proceedings within limitation periods. Business purposes include accounting, reporting, business improvement, and research. Organisations must not keep personal data 'just in case' it might be useful for unspecified purposes. When retention is no longer justified, Singapore PDPA requirements mandate that organisations either cease retaining the data or anonymise it so it can no longer be associated with identifiable individuals. Simply filing documents in a locked cabinet, warehousing them, or archiving electronic records does not constitute ceasing to retain. The data must be truly inaccessible -- physical documents should be securely shredded and electronic data permanently deleted or overwritten. - Create a personal data retention schedule mapping each data category to its original collection purpose, applicable legal retention requirements, and a defined retention period. - Review your retention schedule at least annually to ensure retention periods remain justified and no data is retained beyond its useful life under Singapore PDPA requirements. - Implement automated or scheduled deletion processes for data categories with defined expiry dates, and maintain deletion logs as evidence. - When ceasing to retain personal data, ensure it is truly inaccessible: shred physical documents and permanently delete or overwrite electronic data. - Consider anonymisation as an alternative to deletion where the data has analytical value but the association with individuals is no longer needed. - Do not retain personal data 'just in case' -- every retained dataset must be linked to a valid, documented purpose to satisfy Singapore PDPA requirements. - Ensure data intermediaries comply with your retention policies through contractual clauses and periodic verification. - Document your retention policy rationale, especially for longer retention periods, to demonstrate reasonableness if questioned by the PDPC. ## Singapore PDPA Requirements for Transfer Limitation (Section 26) The Transfer Limitation Obligation under Section 26 is a Singapore PDPA requirement restricting organisations from transferring personal data outside Singapore unless prescribed conditions are met. This obligation applies when an organisation relinquishes possession or direct control of personal data by sending it to another organisation overseas -- such as a group company for centralised functions or a data intermediary for processing. The Personal Data Protection Regulations 2021 specify several avenues for compliant cross-border transfers under Singapore PDPA requirements. The primary approach is ensuring the overseas recipient is bound by legally enforceable obligations providing protection comparable to the PDPA. This can be achieved through contracts, binding corporate rules, or other legally binding instruments. Organisations may also rely on APEC Cross-Border Privacy Rules (CBPR) certification for organisations and APEC Privacy Recognition for Processors (PRP) certification for data intermediaries. Alternative transfer mechanisms that satisfy Singapore PDPA requirements include obtaining informed consent after explaining how data will be protected overseas, deemed consent by contractual necessity, transfers necessary in the vital interests of individuals or the national interest, data in transit through Singapore, and publicly available data. The PDPC also encourages use of ASEAN Model Contract Clauses (MCCs) as a practical baseline for cross-border data protection agreements. Meeting Singapore PDPA requirements for cross-border transfers requires organisations to map all international data flows, document the legal mechanism for each transfer, and conduct due diligence on overseas recipients. The PDPC's Guidance for Use of ASEAN Model Contractual Clauses provides a practical template for these arrangements. - Map all cross-border data flows, identifying the destination country, recipient organisation, relationship (data intermediary or independent controller), and data categories transferred. - For each transfer, document the legal mechanism: contractual clauses, binding corporate rules, APEC CBPR/PRP certification, individual consent, or contractual necessity. - Ensure contractual clauses cover purpose limitation, accuracy, protection, retention limitation, data breach notification, and access and correction obligations. - Conduct due diligence on overseas recipients to verify their data protection certifications and capabilities before initiating transfers. - Consider adopting ASEAN Model Contract Clauses (MCCs) as a baseline for cross-border agreements to help meet Singapore PDPA requirements. - For transfers based on individual consent, provide a written summary explaining the extent to which data will be protected to a standard comparable to the PDPA. - Review cross-border transfer arrangements periodically, especially when recipient organisations change certification status or regulatory requirements change. - Maintain a transfer register documenting the legal basis, risk assessments, and contractual arrangements for every cross-border transfer. ## Singapore PDPA Requirements for Data Breach Notification (Sections 26A-26E) The Data Breach Notification Obligation under Sections 26A to 26E is one of the most operationally demanding Singapore PDPA requirements. Once an organisation has credible grounds to believe a data breach has occurred, it must take reasonable and expeditious steps to assess whether the breach is notifiable. The assessment should generally be completed within 30 calendar days, and any unreasonable delay can result in enforcement action by the PDPC. Under Singapore PDPA requirements, a data breach is notifiable in two situations. First, when the breach involves prescribed categories of personal data deemed likely to result in significant harm -- including the individual's full name or national identification number combined with financial information, insurance details, specified medical information, or private authentication keys. Second, when the breach affects 500 or more individuals regardless of the data type, because breaches at this scale may indicate systemic issues. When a breach is assessed as notifiable, Singapore PDPA requirements mandate notification to the PDPC as soon as practicable and within three calendar days after completing the assessment. The three-day clock starts the day after the determination. If the breach is likely to result in significant harm to affected individuals, the organisation must also notify those individuals so they can take protective steps such as changing passwords or monitoring accounts. Data intermediaries that discover a data breach while processing on behalf of another organisation must notify that organisation without undue delay under Singapore PDPA requirements. The data intermediary is not required to assess notifiability or notify the PDPC directly -- that responsibility remains with the engaging organisation. Clear breach notification procedures should be established in contracts with data intermediaries. - Develop and maintain a Data Breach Response Plan covering detection, containment, assessment, notification, remediation, and post-incident review. - Train relevant staff (IT, security, legal, DPO) to recognise data breaches and escalate them promptly through the established response chain. - Conduct a documented breach assessment within 30 calendar days, evaluating the types of personal data affected, the number of individuals impacted, and the potential for significant harm. - Notify the PDPC within three calendar days after determining a breach is notifiable, using the PDPC's breach notification portal. - Notify affected individuals as soon as practicable when the breach is likely to cause significant harm, providing clear information about what happened and what protective steps to take. - Document every step of the breach assessment process, including the timeline, evidence collected, decisions made, and notifications sent. - Include contractual clauses requiring data intermediaries to notify you of any data breach without undue delay, with clear escalation procedures. - Conduct a post-incident review after every data breach to identify root causes, improve security arrangements, and update the Breach Response Plan. ## Singapore PDPA Requirements for Do Not Call Compliance (Part IX) Part IX of the PDPA establishes Singapore's national Do Not Call (DNC) Registry, creating Singapore PDPA requirements that apply specifically to telemarketing. Individuals may register their Singapore telephone numbers on the DNC Registry to opt out of receiving unwanted telemarketing messages. The registry covers three categories of specified messages: voice calls, text messages (including SMS and MMS), and fax messages. Organisations sending marketing messages to Singapore telephone numbers must comply with these Singapore PDPA requirements in addition to the Data Protection Provisions. Before sending any specified message to a Singapore telephone number, Singapore PDPA requirements mandate that organisations check the relevant DNC Register to confirm whether the number is listed. If the number is registered, the organisation must not send the specified message unless the individual has given clear and unambiguous consent evidenced in written or other accessible form. Verbal consent alone is insufficient under Singapore PDPA requirements for DNC purposes. Singapore PDPA requirements also prohibit sending messages to telephone numbers obtained through address-harvesting software or generated through dictionary attacks or similar automated means. These prohibitions apply regardless of DNC registration status. Organisations should implement automated registry checks before each marketing campaign, maintain robust consent management systems, and conduct regular audits of telemarketing practices. - Before sending any marketing voice call, text, or fax to a Singapore telephone number, check the relevant DNC Register and document the result. - Obtain clear, unambiguous consent in written or accessible form before sending marketing messages to numbers registered on the DNC Registry. - Maintain records of all DNC Register checks, including the date, numbers checked, and results, as evidence of compliance with Singapore PDPA requirements. - Implement an internal DNC list (suppression list) for individuals who have directly requested not to receive marketing from your organisation. - Never use address-harvesting software, dictionary attacks, or automated means to generate or obtain telephone numbers for marketing. - Include unsubscribe or opt-out mechanisms in all marketing messages to allow recipients to easily withdraw consent. - Train marketing and sales teams on DNC compliance requirements, including the distinction between DNC consent and general PDPA consent. - Conduct periodic audits of telemarketing practices to ensure ongoing compliance with Singapore PDPA requirements under Part IX. ## Singapore PDPA Requirements for Data Portability (Section 26H) The Data Portability Obligation under Section 26H introduces Singapore PDPA requirements that give individuals the right to request that an organisation transmit a copy of their personal data to another organisation in a commonly used machine-readable format. These Singapore PDPA requirements support individual autonomy and promote competition by reducing switching costs between service providers. Singapore PDPA requirements for data portability apply to personal data in electronic form that is in the organisation's possession or under its control, and that was provided by the individual or created in the course of the individual's use of the organisation's products or services. The receiving organisation must be able to receive the data and have a presence in Singapore or be otherwise subject to the PDPA. Organisations may charge a reasonable fee for porting requests, but it must not be set so high as to effectively deny the right. Meeting Singapore PDPA requirements for data portability means organisations should ensure their systems can export personal data in commonly used formats such as CSV, JSON, or XML. They should also establish procedures for verifying identity, confirming the receiving organisation, and transmitting data securely. Preparing for data portability requests in advance avoids delays and helps organisations respond within required timeframes. - Identify which categories of personal data are subject to portability requests and ensure they can be exported in commonly used machine-readable formats (CSV, JSON, XML). - Build a porting request workflow that includes identity verification, receiving organisation confirmation, data extraction, format conversion, and secure transmission. - Set internal SLAs for responding to porting requests and track response times to satisfy Singapore PDPA requirements for timely compliance. - Implement secure transmission channels for transferring personal data, such as encrypted file transfer or authenticated API endpoints. - Document your fee schedule for porting requests, ensuring fees are reasonable and reflect actual incremental costs. - Coordinate with technical teams to maintain export capabilities as data systems evolve so Singapore PDPA requirements for portability can always be met. ## Singapore PDPA Requirements -- Exceptions, Business Improvement, and Legitimate Interests The PDPA provides several exceptions to the Consent Obligation through the First and Second Schedules. These exceptions are an important part of Singapore PDPA requirements because they allow organisations to collect, use, or disclose personal data without consent in specified circumstances -- such as when data is publicly available, when collection is necessary for evaluative purposes, when use is needed for business improvement, or when disclosure is required by law. The business improvement exception, introduced by the 2020 amendments, allows organisations to use personal data without consent for improving or enhancing goods and services, developing new offerings, or learning about individual behaviour and preferences. However, Singapore PDPA requirements prohibit using this exception for direct marketing. Organisations relying on the business improvement exception should document their reasoning and confirm the use meets statutory conditions. The legitimate interests exception allows collection, use, or disclosure without consent where the organisation has identified a legitimate interest, the benefit to the public clearly outweighs any adverse effect on the individual, and the individual would not reasonably be expected to withhold consent. Singapore PDPA requirements mandate a documented assessment for this exception. The PDPC provides an Assessment Checklist for the Legitimate Interests Exception (Annex C of the Advisory Guidelines) to guide organisations through this process. Understanding and correctly applying these exceptions is essential to a complete understanding of Singapore PDPA requirements. Relying on exceptions without proper documentation is a common compliance failure that the PDPC has addressed in multiple enforcement decisions. - Maintain a register of every instance where personal data is collected, used, or disclosed without consent, identifying the specific exception relied upon and the reasoning. - For the business improvement exception, document that the use is genuinely for improving products or services and not for direct marketing. - For the legitimate interests exception, complete a documented assessment covering: the identified legitimate interest, the benefit to the public, the adverse effect on individuals, and why the individual would not reasonably withhold consent. - Use the PDPC's Assessment Checklists (Annex B for deemed consent by notification, Annex C for legitimate interests) as templates for documented assessments. - Review reliance on exceptions periodically to ensure they remain valid as processing activities evolve and Singapore PDPA requirements are updated. - Train staff on the boundaries of each exception so they do not extend exception-based processing beyond its permitted scope under Singapore PDPA requirements. ## Evidence Pack -- What Singapore PDPA Requirements Look Like on Paper Defensible compliance with Singapore PDPA requirements demands a structured evidence pack demonstrating how your organisation meets each obligation. The evidence pack answers two core questions: what personal data you process and why, and what controls you operate to keep that processing lawful and safe. A well-organised evidence pack makes PDPC investigations, audits, and internal reviews straightforward because every Singapore PDPA requirement can be traced to a documented control and a responsible owner. Your evidence pack should be a living collection of documents, logs, and records updated as your data processing activities change. It should link policies to procedures, procedures to records, and records to specific Singapore PDPA requirements. Assign an owner to each evidence category and set review schedules so documentation stays current and accurate. The PDPC's enforcement decisions consistently show that organisations with comprehensive, well-maintained documentation receive more favourable outcomes -- including the possibility of undertakings rather than full investigations under the Active Enforcement Framework. Building a strong evidence pack is one of the most practical steps an organisation can take to demonstrate compliance with Singapore PDPA requirements. - Data Protection Management Programme (DPMP) document covering governance structure, DPO designation, policies, training plans, and review schedules. - Personal data inventory and processing register: data categories, collection sources, purposes, lawful bases, retention periods, disclosure recipients, and cross-border transfer destinations. - Notices and consent records: copies of all data protection notices, consent capture logs, deemed consent assessments, and withdrawal records. - Access and correction request log: request intake records, identity verification evidence, response packages, fee estimates, exception decisions, and preservation records. - Security controls documentation: risk assessment reports, administrative/physical/technical measures inventories, vendor security assessments, and penetration test results. - Retention schedule and deletion logs: documented retention periods per data category, deletion execution records, and anonymisation procedures. - Cross-border transfer register: destination countries, recipient organisations, legal mechanisms, contractual clauses, and due diligence records. - Data Breach Response Plan and breach register: response procedures, assessment records, notification evidence, post-incident review reports, and remediation actions. - DNC compliance records: registry check logs, marketing consent records, suppression lists, and campaign audit trails. - Training records: attendance logs, training materials, assessment results, and refresher schedules for all staff covering Singapore PDPA requirements. ## Primary sources - [Personal Data Protection Act 2012 (Singapore) -- official text](https://sso.agc.gov.sg/Act/PDPA2012?ref=sorena.io) - Primary legislation governing collection, use, disclosure, protection, retention, transfer, and accountability for personal data in Singapore. - [PDPC -- PDPA overview](https://www.pdpc.gov.sg/overview-of-pdpa/pdpa-overview?ref=sorena.io) - Official PDPC overview of PDPA obligations, key concepts, scope, and legislative history. - [PDPC -- Advisory Guidelines on Key Concepts in the PDPA (Revised 16 May 2022)](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-the-personal-data-protection-act?ref=sorena.io) - Authoritative interpretation guidance covering consent, purposes, notification, access/correction, accuracy, protection, retention, transfers, breach notification, and accountability. - [PDPC -- Guide to Developing a Data Protection Management Programme](https://www.pdpc.gov.sg/help-and-resources/2019/07/guide-to-developing-a-data-protection-management-programme?ref=sorena.io) - Four-step framework (governance, policies, processes, maintenance) for building a DPMP that satisfies Singapore PDPA requirements for accountability. - [PDPC -- Advisory Guidelines on Enforcement of Data Protection Provisions](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-enforcement-of-data-protection-provisions?ref=sorena.io) - Enforcement approach, directions, financial penalties, undertakings, and the Active Enforcement Framework. - [PDPC -- Guide to Accountability under the PDPA](https://www.pdpc.gov.sg/help-and-resources/2019/07/guide-to-accountability-under-the-personal-data-protection-act?ref=sorena.io) - Practical accountability controls and programme expectations for demonstrating compliance with Singapore PDPA requirements. - [PDPC -- Guidance for Use of ASEAN Model Contractual Clauses for Cross-Border Data Flows](https://www.pdpc.gov.sg/help-and-resources/2021/09/guidance-for-use-of-asean-model-contractual-clauses-for-cross-border-data-flows?ref=sorena.io) - Practical guidance on using ASEAN MCCs to satisfy Singapore PDPA requirements for cross-border personal data transfers. ## Related Topic Guides - [Singapore PDPA Applicability Test | Does the PDPA Apply to Your Organisation?](/artifacts/apac/singapore-pdpa/applicability-test.md): Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation. - [Singapore PDPA Breach Notification Playbook - Complete Guide](/artifacts/apac/singapore-pdpa/breach-notification-playbook.md): Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline. - [Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026)](/artifacts/apac/singapore-pdpa/checklist.md): Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules. - [Singapore PDPA Compliance Deadlines and Calendar](/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar.md): Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows. - [Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM](/artifacts/apac/singapore-pdpa/compliance.md): Complete Singapore PDPA compliance guide for organisations. - [Singapore PDPA Consent and Notification Obligations Guide](/artifacts/apac/singapore-pdpa/consent-notification-and-purposes.md): Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception. - [Singapore PDPA Cross-Border Transfer Rules | Section 26 Data Transfer Compliance](/artifacts/apac/singapore-pdpa/cross-border-transfers.md): Complete guide to Singapore PDPA cross-border transfer compliance under Section 26. - [Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide](/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages.md): Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses. - [Singapore PDPA FAQ | Frequently Asked Questions on Personal Data Protection Act Compliance](/artifacts/apac/singapore-pdpa/faq.md): Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements. - [Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions](/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases.md): Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover. - [Singapore PDPA Penalties and Fines | SGD 1M or 10% Turnover Cap + PDPC Enforcement Guide](/artifacts/apac/singapore-pdpa/penalties-and-fines.md): Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions. - [Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide](/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template.md): Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions. - [Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations](/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries.md): Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion. - [Singapore PDPA Vendor Outsourcing and Contracts Guide](/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts.md): Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence. - [Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties](/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr.md): Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/singapore-pdpa/requirements --- --- title: "Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations" canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries" source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries" author: "Sorena AI" description: "Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Singapore PDPA scope" - "Singapore PDPA data intermediary" - "PDPA scope of application" - "PDPA excluded organisations" - "PDPA personal domestic exclusion" - "PDPA employee exclusion" - "PDPA public agency exclusion" - "PDPA business contact information" - "Singapore PDPA data intermediary definition" - "Singapore PDPA data intermediary obligations" - "data intermediary vs organisation PDPA" - "managing data intermediaries Singapore" - "PDPA dual role data intermediary" - "PDPA publicly available data" - "PDPA scope assessment" - "PDPA vendor contracts" - "PDPC guidelines data intermediary" - "data intermediary management lifecycle" - "PDPA protection obligation" - "PDPA retention limitation obligation" - "PDPA data breach notification" - "PDPA accountability programme" - "Singapore PDPA compliance guide" - "PDPA scope checklist Singapore" - "Singapore Personal Data Protection Act scope" - "PDPA exemptions Singapore" - "Personal Data Protection Act" - "PDPA exclusions" - "APAC privacy" - "data protection Singapore" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion. *Artifact Guide* *APAC* ## Singapore PDPA Scope, Exclusions, and Data Intermediaries Determine whether the Singapore PDPA scope covers your processing activities. Classify every party as an organisation or a Singapore PDPA data intermediary, understand every exclusion, and structure your contracts accordingly. Build defensible role clarity so that contracts, notices, and breach workflows stay consistent across all vendor relationships under the Singapore Personal Data Protection Act. This page is a comprehensive, implementation-focused guide to Singapore PDPA scope, exclusions, and data intermediary obligations under the Personal Data Protection Act 2012. It covers the full Singapore PDPA scope of application, the three main categories of excluded entities (individuals acting in a personal or domestic capacity, employees acting in the course of employment, and public agencies), the business contact information exception, the statutory definition and reduced obligations of a Singapore PDPA data intermediary, practical guidance on managing data intermediary relationships across the full lifecycle, dual-role scenarios where a company is both an organisation and a Singapore PDPA data intermediary, the publicly available data consent exception, and a step-by-step Singapore PDPA scope assessment workflow. The content is grounded in the PDPA statute, the PDPC Advisory Guidelines on Key Concepts (Chapter 6), and the PDPC Guide to Managing Data Intermediaries (2020). It is written for data protection officers, product teams, legal counsel, and operations teams who need defensible evidence of role assignment across every processing activity. Use the PDPC sources linked in the sources section and tailor the details to your specific processing context. ## Singapore PDPA scope of application: who is covered The Singapore PDPA scope extends to every organisation that collects, uses, or discloses personal data in Singapore. The Personal Data Protection Act 2012 defines an organisation as 'any individual, company, association or body of persons, corporate or unincorporated whether or not formed or recognised under the law of Singapore; or resident, or having an office or a place of business, in Singapore' (Section 2(1)). This broad definition means the Singapore PDPA scope captures companies, associations, sole proprietorships, partnerships, and natural persons acting in a business capacity, regardless of where they are formed or whether they have a physical presence in Singapore. The Data Protection Provisions are contained in Parts 3 to 6A of the PDPA. They impose obligations on organisations covering Consent, Purpose Limitation, Notification, Access and Correction, Accuracy, Protection, Retention Limitation, Transfer Limitation, Data Breach Notification, and Accountability. Every organisation within the Singapore PDPA scope must comply with all of these obligations unless it falls within a category that is expressly excluded. An organisation should ensure that it is able to adduce evidence to establish and demonstrate compliance with the PDPA in the event of an investigation by the Personal Data Protection Commission (PDPC), as stated in paragraph 6.3 of the Advisory Guidelines on Key Concepts. Understanding the Singapore PDPA scope is the first step in any compliance programme. Getting the scope wrong means either over-investing in controls that do not apply or, more dangerously, missing obligations that do apply. The PDPA provides three main categories of exclusion -- individuals acting in a personal or domestic capacity, employees acting in the course of employment, and public agencies -- plus a partial exclusion for Singapore PDPA data intermediaries. Each exclusion has specific conditions, and none is absolute in every scenario. - The Singapore PDPA scope covers any organisation that collects, uses, or discloses personal data in Singapore, regardless of where the organisation is formed, registered, or based. - Personal data under the PDPA means data, whether true or not, about an individual who can be identified from that data alone or from that data combined with other information the organisation has or is likely to have access to. - The Data Protection Provisions impose obligations for Consent, Purpose Limitation, Notification, Access and Correction, Accuracy, Protection, Retention Limitation, Transfer Limitation, Data Breach Notification, and Accountability. - An organisation within the Singapore PDPA scope must be able to produce evidence of compliance in the event of a PDPC investigation (Advisory Guidelines, paragraph 6.3). - Where personal data is transferred into Singapore from overseas, the Data Protection Provisions apply to activities involving that data in Singapore. - The PDPA does not apply to personal data in records that have existed for at least 100 years, or about an individual who has been deceased for more than 10 years. - Organisations not within an excluded category must comply with the PDPA even when dealing with an excluded entity such as a public agency (Advisory Guidelines, paragraph 6.7). *Recommended next step* *Placement: after the scope or definition section* ## Use Singapore PDPA Scope, Exclusions, and Data Intermediaries as a cited research workflow Research Copilot can take Singapore PDPA Scope, Exclusions, and Data Intermediaries from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on Singapore PDPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Singapore PDPA Scope, Exclusions, and Data Intermediaries](/solutions/research-copilot.md): Start from Singapore PDPA Scope, Exclusions, and Data Intermediaries and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Singapore PDPA](/contact.md): Review your current process, evidence gaps, and next steps for Singapore PDPA Scope, Exclusions, and Data Intermediaries. ## Singapore PDPA scope exclusion: personal and domestic capacity The first major exclusion from the Singapore PDPA scope is for any individual acting in a personal or domestic capacity. The PDPA recognises that the Act is directed at organisations collecting and using personal data for business purposes, not at individuals managing their own personal or family affairs. Paragraph 6.8 of the PDPC Advisory Guidelines on Key Concepts confirms that individuals acting in a personal or domestic capacity benefit from a significant exclusion and are not required to comply with the Data Protection Provisions. An individual acts in a personal capacity if he or she undertakes activities for his or her own purposes (Advisory Guidelines, paragraph 6.9). The term 'domestic' is defined in the PDPA as 'related to home or family' (paragraph 6.10). Examples of domestic activities include opening joint bank accounts between family members, purchasing life insurance policies for a child, or booking a holiday for a spouse. In these cases, the individual providing personal data of another family member to a business is outside the Singapore PDPA scope. However, the organisation receiving the data must still comply with all obligations. The PDPC Advisory Guidelines illustrate this with a worked example: when Tom books a travel package for a family holiday and provides his wife Jane's personal data to the travel agency, Tom is acting in a personal or domestic capacity and is excluded from the Singapore PDPA scope. The travel agency, however, must comply with all Data Protection Provisions for both Tom's and Jane's personal data. The travel agency can collect Jane's data without her direct consent under paragraph 8 of Part 3 of the First Schedule, because the data was provided by Tom for his personal and domestic purposes. This exclusion from the Singapore PDPA scope does not apply to individuals who use personal data for mixed purposes. If a freelancer collects contact details for both personal networking and business development, the business-related processing falls within the Singapore PDPA scope. Organisations should include this distinction in their scope assessment to avoid treating personal-capacity data flows as excluded when they have a business element. - Any individual acting in a personal or domestic capacity is excluded from the Singapore PDPA scope and the Data Protection Provisions (Advisory Guidelines, paragraph 6.8). - Personal capacity means undertaking activities for one's own purposes. Domestic capacity means activities related to home or family (Advisory Guidelines, paragraphs 6.9-6.10). - The exclusion applies to the individual only. The organisation receiving the data must still comply with all Data Protection Provisions. - Example: if Tom books a holiday for his wife Jane at a travel agency, Tom is acting in a personal capacity and is outside the Singapore PDPA scope. The travel agency must comply with all obligations for both Tom's and Jane's personal data. - The travel agency can collect Jane's data without her direct consent under paragraph 8, Part 3 of the First Schedule, because it was provided by Tom for personal and domestic purposes. - Mixed-purpose activities (part personal, part business) are not fully excluded. The business component remains within the Singapore PDPA scope. ## Singapore PDPA scope exclusion: employees acting in the course of employment The second major exclusion from the Singapore PDPA scope applies to employees acting in the course of their employment with an organisation. The PDPA defines 'employee' broadly to include volunteers. Paragraph 6.11 of the Advisory Guidelines on Key Concepts confirms that individuals who undertake work without an expectation of payment fall within this exclusion. This means that employees and volunteers are not separately subject to the Data Protection Provisions for actions taken within the scope of their duties. Notwithstanding this exclusion, the employing organisation remains primarily responsible for any contravention of the Data Protection Provisions resulting from the actions of its employees or volunteers (Advisory Guidelines, paragraph 6.12). PDPC enforcement cases have repeatedly held organisations liable for employee errors, including accidental disclosures and improper disposal of personal data. Organisations must therefore train their staff, establish clear data handling procedures, and monitor compliance to stay within the Singapore PDPA scope requirements. This exclusion from the Singapore PDPA scope addresses a practical reality: employees handle personal data as part of their duties, and imposing separate compliance obligations on each individual employee would be impractical. The obligation to comply with the PDPA falls on the organisation, not on each individual employee or volunteer. The organisation bears responsibility for ensuring that its workforce understands the data protection rules and follows the correct procedures. - Employees (including volunteers) acting in the course of employment are excluded from the Singapore PDPA scope and the Data Protection Provisions (Advisory Guidelines, paragraph 6.11). - The PDPA defines employee broadly to include volunteers -- individuals who undertake work without an expectation of payment. - Despite the employee exclusion, the employing organisation remains primarily responsible for any data protection breach caused by its employees or volunteers (Advisory Guidelines, paragraph 6.12). - PDPC enforcement cases have held organisations liable for employee errors such as accidental disclosures and improper disposal of personal data. - Organisations must train staff, establish clear data handling procedures, and actively monitor compliance. - The employee exclusion recognises that imposing separate compliance obligations on each individual employee would be impractical under the Singapore PDPA scope framework. ## Singapore PDPA scope exclusion: business contact information The PDPA carves out business contact information from the Data Protection Provisions entirely. Under the Singapore PDPA scope rules, business contact information includes an individual's name, position or title, business telephone number, business address, business email address, and business fax number, provided that the individual did not supply it solely for personal purposes. Organisations do not need consent to collect, use, or disclose business contact information. They also do not need to comply with any other Data Protection Provision in relation to such information. The business contact information exclusion from the Singapore PDPA scope depends on the purpose for which the information was provided. If an individual hands over a business card at a corporate seminar to receive future event invitations, the information on the card is business contact information and falls outside the Singapore PDPA scope. If the same individual provides the same card to a gym for the purpose of signing up for a personal membership, the information is not business contact information and the PDPA applies in full. The PDPC Advisory Guidelines (paragraph 5.18) confirm that organisations are not required to obtain consent before collecting, using, or disclosing any business contact information. Contact information of sole proprietors and partners qualifies as business contact information when provided for business purposes. Organisations should document the purpose of collection to support a defensible classification of business contact information. When the same contact details could serve both business and personal purposes, the Singapore PDPA scope analysis should consider the context in which the information was originally provided. - Business contact information (name, title, business phone, business address, business email, business fax) is excluded from the Singapore PDPA scope and the Data Protection Provisions. - The exclusion depends on the purpose for which the information was provided -- it must not have been provided solely for personal purposes. - A business card provided at a corporate event for professional networking is business contact information. The same card provided to a gym for a personal membership is not. - Contact information of sole proprietors and partners qualifies as business contact information when provided for business purposes. - Organisations do not need consent to collect, use, or disclose business contact information (Advisory Guidelines, paragraph 5.18). - Organisations should document the purpose of collection to support defensible classification under the Singapore PDPA scope rules. ## Singapore PDPA scope exclusion: public agencies Public agencies are excluded from the application of the Data Protection Provisions under the Singapore PDPA scope rules. The PDPA defines a public agency to include the Government (including any ministry, department, agency, or organ of State), any tribunal appointed under any written law, and any statutory body specified by the Minister by notice in the Gazette (Advisory Guidelines, paragraph 6.13). The gazetted list of statutory bodies designated as public agencies is available on the PDPC website. Although public agencies themselves are excluded from the Singapore PDPA scope, organisations that provide services to public agencies are not automatically excluded. A private company that processes personal data on behalf of a government ministry may have obligations under the PDPA as a data controller or as a Singapore PDPA data intermediary (Advisory Guidelines, paragraph 6.14). The PDPC Guide to Managing Data Intermediaries notes that data intermediaries processing data on behalf of public agencies should refer to the Government's Third-Party Management Framework for additional requirements. Organisations dealing with public agencies must document the relationship clearly. If the public agency transfers personal data to the organisation for the organisation's own purposes, the organisation is a data controller within the Singapore PDPA scope and must comply with all Data Protection Provisions. If the organisation processes the data solely on behalf of and for the purposes of the public agency, it may qualify as a Singapore PDPA data intermediary with reduced obligations. - The Government (including ministries, departments, agencies, and organs of State) is excluded from the Singapore PDPA scope (Advisory Guidelines, paragraph 6.13). - Tribunals appointed under any written law are also excluded from the Singapore PDPA scope. - Statutory bodies designated by the Minister via notice in the Gazette are public agencies for PDPA purposes. - Private organisations providing services to public agencies are still within the Singapore PDPA scope as either organisations (data controllers) or Singapore PDPA data intermediaries (Advisory Guidelines, paragraph 6.14). - Singapore PDPA data intermediaries processing data for public agencies should follow both PDPA obligations and the Government's Third-Party Management Framework. - Organisations must document whether they are acting as data controllers or Singapore PDPA data intermediaries when working with public agencies. ## Singapore PDPA data intermediary: definition and statutory obligations The PDPA defines a Singapore PDPA data intermediary as 'an organisation that processes personal data on behalf of another organisation but does not include an employee of that other organisation' (Section 2(1); Advisory Guidelines, paragraph 6.15). A Singapore PDPA data intermediary processes data not for its own purposes but on behalf of and for the purposes of a data controller (referred to as the 'organisation' under the PDPA). The relationship must be documented in a contract that is evidenced or made in writing. A Singapore PDPA data intermediary is subject to a reduced set of obligations compared to a full organisation. Under paragraph 6.16 of the Advisory Guidelines, a Singapore PDPA data intermediary that processes personal data pursuant to a written contract is subject only to the Protection Obligation (Section 24), the Retention Limitation Obligation (Section 25), and the Data Breach Notification Obligation (notifying the engaging organisation of data breaches without undue delay). The Singapore PDPA data intermediary is not subject to the Consent, Purpose Limitation, Notification, Access and Correction, Accuracy, Transfer Limitation, or Accountability obligations for processing performed on behalf of the data controller. This reduced set of obligations reflects the Singapore PDPA data intermediary's limited role. Because data intermediaries act on instructions and typically do not interact directly with individuals, it would be inappropriate to impose consumer-facing obligations on them. As the PDPC explains, requiring a Singapore PDPA data intermediary to respond to access requests could create security risks (providing data to individuals the intermediary does not know) and privacy risks (requiring the intermediary to inspect data it is contractually prohibited from viewing). However, this partial exclusion is strictly limited. If a Singapore PDPA data intermediary uses or discloses personal data beyond the scope granted by the data controller, it will be treated as an organisation and must comply with all Data Protection Provisions (Advisory Guidelines, paragraph 6.25). For example, if a printing company engaged to produce event invitations uses the mailing list for its own marketing, it steps outside the Singapore PDPA data intermediary role and becomes subject to all obligations. - A Singapore PDPA data intermediary is an organisation that processes personal data on behalf of another organisation, excluding employees of that other organisation (Advisory Guidelines, paragraph 6.15). - The relationship must be documented in a contract that is evidenced or made in writing. - A Singapore PDPA data intermediary is subject to only three obligations: Protection (Section 24), Retention Limitation (Section 25), and Data Breach Notification (notifying the data controller of breaches without undue delay) (Advisory Guidelines, paragraph 6.16). - The remaining obligations -- Consent, Purpose Limitation, Notification, Access and Correction, Accuracy, Transfer Limitation, Accountability -- do not apply to a Singapore PDPA data intermediary for processing done on behalf of the data controller. - If a Singapore PDPA data intermediary uses or discloses personal data beyond the scope of the contract, it becomes subject to all Data Protection Provisions for that processing (Advisory Guidelines, paragraph 6.25). - Processing under the PDPA includes recording, holding, organisation, adaptation, alteration, retrieval, combination, transmission, erasure, and destruction of personal data (Advisory Guidelines, paragraph 6.18). - The data controller retains the same obligations under the PDPA for data processed by a Singapore PDPA data intermediary as if the data controller had processed it directly (Section 4(3); Advisory Guidelines, paragraph 6.20). ## Organisation vs Singapore PDPA data intermediary: how to tell them apart The distinction between organisations (data controllers) and Singapore PDPA data intermediaries (processors) is central to the Singapore PDPA scope analysis. The PDPC published detailed guidance on this distinction, including the article 'The Distinction between Organisations and Data Intermediaries and Why It Matters.' The key test is who determines the purpose and means of processing. If your company decides why and how personal data is collected or used, your company is the organisation. If your company processes data strictly on behalf of and for the purposes of another company, following that company's instructions, your company is the Singapore PDPA data intermediary. An organisation may be classified as a Singapore PDPA data intermediary even if the written contract between the parties does not explicitly use the term 'data intermediary.' The PDPA's definition applies based on the substance of the relationship, not the label used. Paragraph 6.24 of the Advisory Guidelines warns that the statutory definition applies to all organisations that process personal data on behalf of another, regardless of contractual wording. Both parties should include provisions in their written contracts that clearly set out each party's responsibilities and liabilities for the personal data in question. Practical examples from the Advisory Guidelines help clarify the distinction. A business that engages a printing company to produce addressed event invitations is the organisation (data controller). The printing company, which handles the personal data solely to fulfil the printing instructions, is the Singapore PDPA data intermediary. A courier company engaged to deliver a parcel using the recipient's name, address, and phone number is a Singapore PDPA data intermediary of the sender (Advisory Guidelines, paragraph 6.25). A market research firm that collects personal data exclusively for a client's use, producing a report for the client and returning all raw data, may also be a Singapore PDPA data intermediary even if the contract does not say so (Advisory Guidelines, paragraph 6.27). This distinction matters because it determines which obligations apply under the Singapore PDPA scope. Organisations face all obligations. Singapore PDPA data intermediaries face only three. Incorrect classification can result in non-compliance: a company that wrongly classifies itself as a Singapore PDPA data intermediary may fail to meet obligations it actually has, such as consent, notification, and access and correction. - The organisation (data controller) determines the purpose and means of processing. The Singapore PDPA data intermediary processes data on behalf of and for the purposes of the organisation. - The PDPA definition of Singapore PDPA data intermediary applies based on the substance of the relationship, not the label in the contract (Advisory Guidelines, paragraph 6.24). - A printing company that uses mailing list data only to print and address invitations is a Singapore PDPA data intermediary. If it uses the data for its own marketing, it becomes an organisation. - A courier company processing a recipient's name and address solely to deliver a parcel is a Singapore PDPA data intermediary of the sender (Advisory Guidelines, paragraph 6.25). - A company within a corporate group that administers payroll for other group companies is a Singapore PDPA data intermediary for that payroll processing (Advisory Guidelines, paragraph 6.28). - Both parties should include explicit provisions in their contracts clarifying responsibilities, liabilities, and the scope of processing. - Incorrect classification can lead to non-compliance. An entity that wrongly assumes Singapore PDPA data intermediary status may miss obligations like consent, notification, and access and correction. ## Managing a Singapore PDPA data intermediary: due diligence, contracts, and monitoring The PDPC published the Guide to Managing Data Intermediaries (2020) to help organisations manage the full lifecycle of Singapore PDPA data intermediary relationships. The guide covers four phases: Governance and Risk Assessment, Policies and Practices, Service Management, and Exit Management. Each phase includes specific actions that the data controller should take to ensure that personal data processed by the Singapore PDPA data intermediary is properly safeguarded. In the Governance and Risk Assessment phase, senior management of the data controller should establish the business objectives for the proposed outsourcing, determine the scale of data and its sensitivity, identify high-level risks, and set evaluation and selection criteria for potential Singapore PDPA data intermediaries. When evaluating candidates, the data controller should verify that the Singapore PDPA data intermediary has a data protection framework in place, including policies, practices, and staff training. The data controller may also check whether the Singapore PDPA data intermediary holds certifications such as the Data Protection Trustmark (DPTM), APEC Cross Border Privacy Rules (CBPR), or APEC Privacy Recognition for Processors (PRP). The Policies and Practices phase centres on contracting. The binding contractual agreement must set out clearly the obligations and responsibilities of all parties, particularly the Singapore PDPA data intermediary's responsibilities for processing personal data on behalf of the data controller. Key clauses should address prohibitions against unauthorised use or disclosure, required security measures, sub-contracting restrictions, incident reporting timelines, overseas transfer conditions, consent collection on behalf of the data controller, and data return or destruction upon contract completion. PDPC enforcement case Re Royal Caribbean Cruises (Asia) Pte. Ltd. [2020] SGPDPC 5 underscored that without clear contractual documentation, the risk of any omissions falls on the data controller. Service Management covers on-boarding, training, regular management meetings, proactive monitoring, audits, on-site inspections, and simulation exercises. For complex or high-volume processing, the data controller should consider periodic audits, database access monitoring, and table-top exercises to test incident response plans. Exit Management requires clear timeframes for the Singapore PDPA data intermediary to cease retaining personal data, documented handover of all work and documentation, and exit audits to verify that the Singapore PDPA data intermediary has destroyed or anonymised personal data as agreed. - The PDPC Guide to Managing Data Intermediaries covers four lifecycle phases: Governance and Risk Assessment, Policies and Practices, Service Management, and Exit Management. - Senior management of the data controller should approve outsourcing decisions and understand the data protection risks involved in engaging a Singapore PDPA data intermediary. - Evaluate potential Singapore PDPA data intermediaries for data protection frameworks, certifications (DPTM, CBPR, PRP), and track records before engagement. - The contractual agreement must clearly set out each party's obligations including prohibitions against unauthorised use, required security measures, sub-contracting rules, and incident reporting timelines. - Standard operating procedures (SOPs) should cover operational procedures, regular management reports, and ad-hoc incident reports for each Singapore PDPA data intermediary. - Service management activities include on-boarding briefings, structured training, regular meetings, proactive monitoring, audits, on-site inspections, and simulation exercises. - Exit management requires documented data return or destruction timelines, handover of documentation, and exit audits for every Singapore PDPA data intermediary relationship. - The data controller is ultimately responsible under the PDPA for personal data processed by its Singapore PDPA data intermediary, per Section 4(3) (Advisory Guidelines, paragraph 6.20). ## Dual-role scenarios: acting as both organisation and Singapore PDPA data intermediary A single company can simultaneously be an organisation (data controller) for some processing activities and a Singapore PDPA data intermediary for others. The PDPC Advisory Guidelines on Key Concepts (paragraph 6.29) explicitly confirm this. For example, a company that administers payroll on behalf of other companies within its corporate group is a Singapore PDPA data intermediary for that payroll processing. At the same time, the company is a full organisation for the personal data of its own employees and must comply with all Data Protection Provisions for that data. Dual-role scenarios require careful internal governance under the Singapore PDPA scope framework. The company must identify each processing activity and classify it as either data-controller processing or Singapore PDPA data intermediary processing. For data-controller processing, all PDPA obligations apply. For Singapore PDPA data intermediary processing, only the Protection, Retention Limitation, and Data Breach Notification obligations apply. Failure to maintain this distinction can lead to enforcement action. In the payroll example from the Advisory Guidelines, if the company fails to implement reasonable security arrangements for the other companies' employee records, it may be liable under the Protection Obligation even though it is acting as a Singapore PDPA data intermediary. Organisations should maintain a processing activity register that records the role played for each activity, the legal basis for processing, the data controller or Singapore PDPA data intermediary counterparty, and the contractual reference. This register serves as evidence of role clarity during any PDPC investigation. It also helps avoid confusion when the same personal data set is used for both data-controller purposes (for example, internal analytics) and Singapore PDPA data intermediary purposes (for example, processing on behalf of a client). Another common dual-role scenario involves technology platform providers. A SaaS company may process customer data as a Singapore PDPA data intermediary under client contracts, while simultaneously collecting analytics data about platform usage for its own product improvement purposes. For the client data, the SaaS company is a Singapore PDPA data intermediary. For the analytics data it collects for its own purposes, it is an organisation subject to all Data Protection Provisions. The contracts, privacy notices, and internal policies must reflect both roles under the Singapore PDPA scope. - A company can be a Singapore PDPA data intermediary for one set of processing activities and an organisation for another set, simultaneously (Advisory Guidelines, paragraph 6.29). - A payroll administrator processing other companies' employee data is a Singapore PDPA data intermediary for that payroll, but a full organisation for the personal data of its own employees. - Each processing activity must be classified separately as data-controller or Singapore PDPA data intermediary processing under the Singapore PDPA scope framework. - Maintain a processing activity register recording the role, legal basis, counterparty, and contractual reference for each activity. - SaaS providers commonly act as Singapore PDPA data intermediaries for client data and as organisations for their own analytics and product improvement data. - If a Singapore PDPA data intermediary uses personal data beyond the contracted scope (for its own purposes), it becomes an organisation for that processing and must comply with all obligations. - Contracts, privacy notices, and internal policies must clearly reflect dual-role arrangements under the Singapore PDPA scope. ## Publicly available data and the Singapore PDPA scope The PDPA contains a consent exception for personal data that is publicly available, which has important implications for the Singapore PDPA scope of consent obligations. Section 2(1) defines 'publicly available' as personal data that is generally available to the public, including personal data that can be observed by reasonably expected means at a location or event that is open to the public. This exception allows organisations within the Singapore PDPA scope to collect, use, and disclose publicly available personal data without obtaining the consent of the individual. Personal data is 'generally available to the public' if any member of the public can obtain or access it with few or no restrictions. The PDPC Advisory Guidelines note that the existence of some restrictions does not automatically prevent data from being publicly available. Data disclosed to an online group with open membership may be considered publicly available within the Singapore PDPA scope framework. Social media profiles that are publicly searchable are likely to contain publicly available personal data. Conversely, data shared within a close circle of family and friends, or profiles restricted to approved connections, are not publicly available. For personal data observed in public, two conditions must be met under the Singapore PDPA scope rules. First, the data must be observed by reasonably expected means -- individuals should reasonably expect their personal data to be collected in that manner at that location. Second, the location or event must be open to the public, meaning members of the public can enter with few or no restrictions. CCTV footage captured in a shopping mall for security purposes meets both conditions. However, private spaces within public spaces (such as a hired private room in a restaurant) are not considered open to the public. The PDPC takes the position that if personal data was publicly available at the time of collection, the consent exception continues to apply even if the data is no longer publicly available at the time of use or disclosure. This recognises that it would be excessively burdensome to require organisations within the Singapore PDPA scope to continuously verify that data remains publicly available. However, organisations must still comply with all other Data Protection Provisions, including the Purpose Limitation Obligation. Collecting publicly available data does not grant a blanket right to use it for any purpose under the Singapore PDPA scope. - The PDPA provides a consent exception for personal data that is publicly available at the time of collection, reducing consent obligations within the Singapore PDPA scope. - Publicly available means generally available to the public, including data observable by reasonably expected means at a public location or event. - Social media profiles with open, public-searchable settings likely contain publicly available personal data. Restricted profiles do not. - Data disclosed to an online group with open membership may be publicly available under the Singapore PDPA scope. Data shared within a close circle of family or friends is not. - CCTV footage in a shopping mall captures publicly available data because it is observed by reasonably expected means at a public location. - Private spaces within public spaces (for example, a reserved private dining room) are not open to the public for this exception. - If data was publicly available at the time of collection, the consent exception continues to apply even if the data is later made private. - The consent exception does not override other obligations within the Singapore PDPA scope. Organisations must still comply with the Purpose Limitation Obligation and all other Data Protection Provisions. ## Practical Singapore PDPA scope assessment workflow Every PDPA compliance programme should begin with a structured Singapore PDPA scope assessment. The goal is to classify every entity and every processing activity so that the correct obligations are identified and documented. A Singapore PDPA scope assessment produces a defensible record that can be presented to the PDPC during an investigation or audit. Without it, organisations risk applying the wrong controls or missing obligations entirely. Step 1: Inventory all entities involved in personal data processing. List every company, business unit, vendor, sub-contractor, and individual that handles personal data in connection with your operations. For each entity, determine whether it is an organisation within the Singapore PDPA scope, a Singapore PDPA data intermediary, a public agency, an individual acting in a personal or domestic capacity, or an employee. Record the legal basis for each classification. Step 2: Map processing activities to roles. For each processing activity (for example, customer data collection, payroll processing, marketing analytics, IT hosting), identify whether the entity acts as an organisation or a Singapore PDPA data intermediary. Note that the same entity may have different roles for different activities. Produce a processing activity register with columns for: activity description, entity name, role (organisation or Singapore PDPA data intermediary), personal data categories, data subjects, counterparty, contract reference, and applicable obligations. - Step 1: Inventory all entities that handle personal data (companies, vendors, sub-contractors, individuals) and classify each as organisation, Singapore PDPA data intermediary, public agency, personal-capacity individual, or employee. - Step 2: Map each processing activity to its role. Record the activity, entity, role, data categories, data subjects, counterparty, and contract reference in a processing activity register. - Step 3: Check exclusions for each activity. Assess whether business contact information, public agency, personal or domestic capacity, or publicly available data exclusions apply under the Singapore PDPA scope. Document the basis. - Step 4: Validate contracts for every Singapore PDPA data intermediary relationship. Ensure written contracts specify scope, protection, retention, breach notification, sub-contracting, and data disposal terms. - Step 5: Verify that all PDPA obligations have corresponding policies, procedures, and evidence for every activity where the entity acts as an organisation within the Singapore PDPA scope. - Step 6: Review the Singapore PDPA scope assessment annually and whenever business operations, vendor relationships, or data flows change. - Retain the Singapore PDPA scope assessment as evidence for PDPC investigations. A documented, current assessment demonstrates accountability under the PDPA. ## Primary sources - [Personal Data Protection Act 2012 (Singapore) - official text](https://sso.agc.gov.sg/Act/PDPA2012?ref=sorena.io) - Primary legislation governing collection, use, disclosure, protection, retention, transfer, and accountability for personal data in Singapore. Defines the Singapore PDPA scope, excluded entities, and data intermediary obligations. - [PDPC - PDPA overview](https://www.pdpc.gov.sg/overview-of-pdpa/pdpa-overview?ref=sorena.io) - Official PDPC overview of PDPA obligations, Singapore PDPA scope, key concepts, and updates. - [PDPC - Key Concepts advisory guidelines (revised 16 May 2022)](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-the-personal-data-protection-act?ref=sorena.io) - Core interpretation guidance for Singapore PDPA scope, consent, purposes, notification, access/correction, accuracy, protection, retention, transfers, and accountability. Chapter 6 covers organisations, excluded entities, and Singapore PDPA data intermediary obligations. - [PDPC - Enforcement advisory guidelines](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-enforcement-of-data-protection-provisions?ref=sorena.io) - Enforcement approach, directions, financial penalties, and undertakings under the Singapore PDPA scope. - [PDPC - Guide to managing data intermediaries (2020)](https://www.pdpc.gov.sg/help-and-resources/2020/09/guide-to-managing-data-intermediaries?ref=sorena.io) - Official guidance on Singapore PDPA data intermediary management lifecycle: governance and risk assessment, policies and practices, service management, and exit management. - [PDPC - Data intermediary contract clauses guide](https://www.pdpc.gov.sg/help-and-resources/2017/10/guide-on-data-protection-clauses-for-agreements-relating-to-the-processing-of-personal-data?ref=sorena.io) - Contract clauses and expectations for processing agreements between organisations and Singapore PDPA data intermediaries. - [PDPC - The distinction between organisations and data intermediaries](https://www.pdpc.gov.sg/the-distinction-between-organisations-and-data-intermediaries-and-why-it-matters?ref=sorena.io) - PDPC article explaining the practical importance of the organisation vs Singapore PDPA data intermediary distinction, with worked examples and international comparisons. ## Related Topic Guides - [Singapore PDPA Applicability Test | Does the PDPA Apply to Your Organisation?](/artifacts/apac/singapore-pdpa/applicability-test.md): Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation. - [Singapore PDPA Breach Notification Playbook - Complete Guide](/artifacts/apac/singapore-pdpa/breach-notification-playbook.md): Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline. - [Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026)](/artifacts/apac/singapore-pdpa/checklist.md): Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules. - [Singapore PDPA Compliance Deadlines and Calendar](/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar.md): Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows. - [Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM](/artifacts/apac/singapore-pdpa/compliance.md): Complete Singapore PDPA compliance guide for organisations. - [Singapore PDPA Consent and Notification Obligations Guide](/artifacts/apac/singapore-pdpa/consent-notification-and-purposes.md): Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception. - [Singapore PDPA Cross-Border Transfer Rules | Section 26 Data Transfer Compliance](/artifacts/apac/singapore-pdpa/cross-border-transfers.md): Complete guide to Singapore PDPA cross-border transfer compliance under Section 26. - [Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide](/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages.md): Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses. - [Singapore PDPA FAQ | Frequently Asked Questions on Personal Data Protection Act Compliance](/artifacts/apac/singapore-pdpa/faq.md): Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements. - [Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions](/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases.md): Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover. - [Singapore PDPA Penalties and Fines | SGD 1M or 10% Turnover Cap + PDPC Enforcement Guide](/artifacts/apac/singapore-pdpa/penalties-and-fines.md): Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions. - [Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide](/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template.md): Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions. - [Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC)](/artifacts/apac/singapore-pdpa/requirements.md): Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18). - [Singapore PDPA Vendor Outsourcing and Contracts Guide](/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts.md): Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence. - [Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties](/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr.md): Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries --- --- title: "Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties" canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr" source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr" author: "Sorena AI" description: "Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Singapore PDPA vs GDPR" - "PDPA vs GDPR comparison" - "Singapore PDPA vs GDPR scope" - "Singapore PDPA vs GDPR consent" - "Singapore PDPA vs GDPR penalties" - "Singapore PDPA vs GDPR breach notification" - "Singapore PDPA vs GDPR cross-border transfers" - "Singapore PDPA vs GDPR DPO" - "Singapore PDPA vs GDPR individual rights" - "Singapore PDPA deemed consent vs GDPR legitimate interests" - "PDPA data intermediary vs GDPR data processor" - "Singapore PDPA penalties vs GDPR fines" - "Singapore PDPC enforcement" - "PDPA GDPR dual compliance" - "ASEAN data protection" - "Singapore personal data protection obligations" - "PDPA accountability obligation" - "PDPA transfer limitation obligation" - "PDPA purpose limitation" - "GDPR Article 6 legal bases" - "multinational privacy compliance Singapore EU" - "Singapore PDPA vs EU GDPR guide" - "Singapore PDPA" - "GDPR" - "Singapore data protection" - "cross-border compliance" - "APAC privacy law" - "dual privacy compliance" - "PDPA consent vs GDPR consent" - "PDPA penalties vs GDPR fines" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements. *Artifact Guide* *APAC* ## Singapore PDPA vs GDPR Side-by-Side Comparison In-depth Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border data transfers, penalties, DPO requirements, individual rights, and data intermediary obligations. Designed to help multinational compliance teams map Singapore PDPA requirements against GDPR obligations, reuse existing GDPR evidence, and build one governance program that satisfies both the Singapore PDPA and the EU GDPR. This page delivers a comprehensive Singapore PDPA vs GDPR comparison for compliance officers, DPOs, legal teams, product managers, and operations staff. The Singapore Personal Data Protection Act (PDPA) was enacted in 2012, with its Data Protection Provisions taking effect on 2 July 2014 and significant amendments entering force from February 2021. The EU General Data Protection Regulation (GDPR), formally Regulation (EU) 2016/679, became enforceable on 25 May 2018. Both the Singapore PDPA and the GDPR share the goal of protecting personal data while enabling legitimate use, but they differ in scope, legal basis models, consent frameworks, enforcement architecture, penalty structures, individual rights, and cross-border transfer mechanisms. This Singapore PDPA vs GDPR guide maps every major dimension of these two frameworks so that organisations operating in both Singapore and the EU can identify overlaps, close gaps, and build a unified privacy program. Use the official PDPC statute texts and EU regulatory guidance linked in the sources section to ground every implementation decision. ## Singapore PDPA vs GDPR: origins, objectives, and regulatory architecture The Singapore PDPA was first enacted in 2012 and is administered by the Personal Data Protection Commission (PDPC), which was established on 2 January 2013. The Data Protection Provisions came into force on 2 July 2014, and the Do Not Call Registry provisions took effect on 2 January 2014. The PDPA underwent significant amendments passed on 2 November 2020, with changes taking effect in phases from 1 February 2021. These 2020 amendments introduced mandatory data breach notification, expanded deemed consent provisions, a legitimate interests exception, increased financial penalties, data portability rights, and criminal offences for egregious mishandling of personal data. The Singapore PDPA complements sector-specific legislation such as the Banking Act and Insurance Act. The EU General Data Protection Regulation (GDPR), formally Regulation (EU) 2016/679, was adopted in April 2016 and became enforceable on 25 May 2018. It replaced the 1995 Data Protection Directive (95/46/EC) and harmonised data protection law across all EU/EEA member states. The GDPR is enforced by independent supervisory authorities in each member state, coordinated through the European Data Protection Board (EDPB). The GDPR is widely regarded as the global benchmark for data protection regulation and has influenced laws in dozens of jurisdictions, including the Singapore PDPA's 2020 amendments. When comparing Singapore PDPA vs GDPR at the structural level, both frameworks share fundamental objectives: protecting individuals' personal data from misuse while recognising that organisations need to process personal data for legitimate purposes. However, the Singapore PDPA uses a single national regulator (PDPC) while the GDPR relies on decentralised enforcement across 27+ supervisory authorities coordinated by the EDPB. The Singapore PDPA includes a Do Not Call Registry for telemarketing that has no direct GDPR equivalent. These architectural differences shape how organisations experience compliance under each framework. - Singapore PDPA: enacted 2012, PDPC established 2 January 2013, Data Protection Provisions effective 2 July 2014, major amendments effective from February 2021. - GDPR: adopted April 2016, enforceable 25 May 2018, enforced by national supervisory authorities coordinated through the EDPB. - Singapore PDPA vs GDPR share the objective of balancing individual data protection rights with legitimate organisational needs for data processing. - The Singapore PDPA includes a Do Not Call Registry covering telephone calls, text messages, and faxes; the GDPR has no direct equivalent telemarketing registry at the EU level. - The GDPR applies directly across all 27 EU member states plus EEA countries (Iceland, Liechtenstein, Norway); the Singapore PDPA applies in Singapore only. - Singapore PDPA enforcement is centralised under PDPC; GDPR enforcement is decentralised across member state supervisory authorities with a one-stop-shop mechanism for cross-border cases. - Both frameworks have been shaped by successive revisions and regulatory guidance that organisations must track for ongoing Singapore PDPA vs GDPR compliance. *Recommended next step* *Placement: after the comparison section* ## Use Singapore PDPA vs GDPR Side-by-Side Comparison as a cited research workflow Research Copilot can take Singapore PDPA vs GDPR Side-by-Side Comparison from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on Singapore PDPA vs GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Singapore PDPA vs GDPR Side-by-Side Comparison](/solutions/research-copilot.md): Start from Singapore PDPA vs GDPR Side-by-Side Comparison and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Singapore PDPA vs GDPR](/contact.md): Review your current process, evidence gaps, and next steps for Singapore PDPA vs GDPR Side-by-Side Comparison. ## Singapore PDPA vs GDPR: scope and territorial application The Singapore PDPA governs the collection, use, and disclosure of personal data by organisations in Singapore. Under the Singapore PDPA, 'personal data' means data about an individual who can be identified from that data, or from that data combined with other information the organisation has or is likely to have access to. The Singapore PDPA covers personal data in both electronic and non-electronic formats. It does not apply to individuals acting in a personal or domestic capacity, employees acting in the course of employment (the employer bears responsibility), public agencies, or business contact information such as work email addresses and job titles. The GDPR applies to the processing of personal data by controllers or processors established in the EU/EEA, regardless of where the processing occurs. It also applies extraterritorially under Article 3(2) to organisations outside the EU that offer goods or services to EU residents or monitor their behaviour. 'Personal data' under the GDPR means any information relating to an identified or identifiable natural person, which includes online identifiers, location data, and factors specific to physical, physiological, genetic, mental, economic, cultural, or social identity. The GDPR's definition of personal data is broader than the Singapore PDPA's definition. A key difference in the Singapore PDPA vs GDPR scope comparison is territorial reach. The Singapore PDPA's territorial scope is primarily activity-based: it applies when organisations carry out activities involving personal data in Singapore, including when personal data is transferred into Singapore. However, the Singapore PDPA does not have an explicit extraterritorial provision equivalent to GDPR Article 3(2). In contrast, the GDPR reaches organisations worldwide when they target EU residents. A Singapore-based company offering goods or services to EU residents is subject to the GDPR even without an EU establishment. The Singapore PDPA's exclusion of business contact information is another important divergence in the Singapore PDPA vs GDPR comparison. An individual's name, position, business telephone number, business address, business email, and business fax number are not covered by the Singapore PDPA's Data Protection Provisions when provided for business purposes. The GDPR makes no such blanket exclusion -- work email addresses and other professional contact information are personal data under the GDPR and require a lawful basis for processing. - Singapore PDPA covers personal data in electronic and non-electronic form; GDPR covers personal data processed wholly or partly by automated means, or forming part of a filing system. - Singapore PDPA excludes public agencies, employees acting in their employment capacity, individuals acting in personal or domestic capacity, and business contact information. - GDPR has explicit extraterritorial reach under Article 3(2) for organisations targeting EU residents; the Singapore PDPA does not have a comparable extraterritorial clause. - Singapore PDPA applies to inbound data transfers: when personal data is transferred into Singapore, the Data Protection Provisions apply from the moment it enters. - GDPR defines personal data more broadly, including online identifiers and pseudonymised data; the Singapore PDPA uses a 'practicability' threshold to determine if data identifies an individual. - The Singapore PDPA explicitly excludes personal data in records over 100 years old and data of individuals deceased for more than 10 years. - Under the GDPR, the household exemption excludes only purely personal or household activities from scope. - Singapore PDPA vs GDPR scope: multinational organisations must map which data processing activities fall under each framework's territorial reach. ## Singapore PDPA vs GDPR: consent and legal bases for processing Under the Singapore PDPA, consent is the primary legal basis for collecting, using, or disclosing personal data. Section 13 of the Singapore PDPA provides that organisations may collect, use, or disclose personal data only with the individual's consent for specified purposes. Consent under the Singapore PDPA may be express (written or recorded), verbal, or implied from an individual's conduct. The Singapore PDPA also provides for deemed consent (by conduct, by contractual necessity, and by notification) and multiple exceptions to the consent requirement set out in the Schedules to the Act. The GDPR provides six lawful bases for processing under Article 6(1): consent, contractual necessity, legal obligation, vital interests, public interest or official authority, and legitimate interests. Consent under the GDPR must be freely given, specific, informed, and unambiguous, and for sensitive data under Article 9, explicit consent is required. In the Singapore PDPA vs GDPR consent comparison, the GDPR treats consent as one of several co-equal legal bases, whereas the Singapore PDPA positions consent as the default starting point with deemed consent and exceptions as alternatives. A significant practical difference in the Singapore PDPA vs GDPR comparison is that the Singapore PDPA does not have a standalone 'contractual necessity' legal basis equivalent to GDPR Article 6(1)(b). Instead, the Singapore PDPA addresses contractual necessity scenarios through its deemed consent by contractual necessity provision (Section 15A), introduced in the 2020 amendments. Similarly, the Singapore PDPA does not have a general 'legal obligation' basis comparable to GDPR Article 6(1)(c), though it provides exceptions where processing is required or authorised under any written law. Both the Singapore PDPA and the GDPR prohibit tying consent to service provision. The Singapore PDPA's Section 14(2) prevents organisations from requiring individuals to consent to processing beyond what is reasonable as a condition of providing a product or service. The GDPR similarly requires that consent must be freely given and must not be bundled. Both frameworks also require organisations to allow withdrawal of consent at any time, though the Singapore PDPA permits organisations to inform individuals of the consequences of withdrawal before acting on it. - Singapore PDPA: consent is the default legal basis, supplemented by deemed consent (by conduct, by contractual necessity, by notification) and statutory exceptions in the Schedules. - GDPR: six co-equal lawful bases under Article 6(1) -- consent, contractual necessity, legal obligation, vital interests, public interest, and legitimate interests. - Singapore PDPA consent may be express, verbal, or implied from conduct; GDPR consent must be unambiguous and demonstrable, with explicit consent required for special categories. - Singapore PDPA vs GDPR consent: the Singapore PDPA positions consent as the default; the GDPR treats it as one of six co-equal options. - Singapore PDPA Section 14(2) prohibits tying consent for unnecessary processing to service provision; GDPR similarly requires consent to be freely given. - Singapore PDPA does not recognise a standalone 'legal obligation' basis but provides exceptions where processing is required by written law. - Both frameworks require organisations to allow withdrawal of consent at any time; the Singapore PDPA allows organisations to explain consequences of withdrawal before acting. - Under the GDPR, switching from consent to another legal basis after collection is problematic; the Singapore PDPA allows relying on different bases for different processing activities. ## Singapore PDPA vs GDPR: deemed consent and legitimate interests One of the most distinctive features of the Singapore PDPA is its deemed consent framework, which has no direct equivalent in the GDPR. Sections 15 and 15A of the Singapore PDPA provide three forms of deemed consent. Deemed consent by conduct applies when an individual voluntarily provides personal data to an organisation for a purpose and it is reasonable for the individual to have done so. Deemed consent by contractual necessity applies when the collection, use, or disclosure is reasonably necessary to perform a contract between the organisation and the individual. Deemed consent by notification allows organisations to notify individuals of new purposes and proceed if the individual does not object within a reasonable period. The Singapore PDPA's 2020 amendments also introduced a legitimate interests exception (Section 13 read with Part 3 of the First Schedule), which is conceptually similar to GDPR Article 6(1)(f) but operates differently. Under the Singapore PDPA, an organisation may collect, use, or disclose personal data without consent if the processing is necessary for a 'legitimate interest' and the benefit to the organisation or public outweighs any adverse effect on the individual. Unlike the GDPR's legitimate interests basis, the Singapore PDPA's legitimate interests exception is available only for specific prescribed purposes and requires the organisation to conduct and document an assessment using the PDPC's checklist (Annex C of the Advisory Guidelines on Key Concepts). Under the GDPR, legitimate interests (Article 6(1)(f)) is one of six co-equal lawful bases. It requires a three-part test: the controller or a third party must have a legitimate interest, the processing must be necessary for that interest, and the interest must not be overridden by the individual's fundamental rights and freedoms. The GDPR legitimate interests basis is more flexible than the Singapore PDPA's version and can apply to a wide range of processing activities. However, public authorities cannot rely on legitimate interests under the GDPR for processing they carry out in the performance of their tasks. For organisations conducting a Singapore PDPA vs GDPR gap analysis, mapping GDPR legitimate interests activities to the appropriate Singapore PDPA mechanism is critical. Each GDPR legitimate interests processing activity should be matched to one of: Singapore PDPA deemed consent by conduct, deemed consent by contractual necessity, deemed consent by notification, the legitimate interests exception, or another statutory exception. This mapping exercise typically reveals that the Singapore PDPA provides workable alternatives for most common GDPR legitimate interests scenarios, but the documentation and assessment requirements differ. - Singapore PDPA deemed consent by conduct: individual voluntarily provides data for a purpose and it is reasonable that they did so; no direct GDPR equivalent. - Singapore PDPA deemed consent by contractual necessity: collection, use, or disclosure is reasonably necessary to perform a contract; similar to GDPR Article 6(1)(b) but structured as a consent mechanism. - Singapore PDPA deemed consent by notification: organisation notifies individual of a new purpose and individual does not object within a reasonable period; no direct GDPR equivalent. - Singapore PDPA legitimate interests exception: requires a documented assessment (using PDPC's Annex C checklist) showing benefit outweighs adverse effect; available for prescribed purposes only. - GDPR legitimate interests (Article 6(1)(f)): flexible standalone legal basis with a three-part balancing test; not limited to prescribed purposes. - The Singapore PDPA requires documented assessments using PDPC checklists (Annexes B and C of the Advisory Guidelines on Key Concepts) for deemed consent by notification and the legitimate interests exception. - Singapore PDPA vs GDPR: most GDPR legitimate interests scenarios can be mapped to a Singapore PDPA deemed consent mechanism or statutory exception. ## Singapore PDPA vs GDPR: individual rights and data subject rights The Singapore PDPA grants individuals the right to access their personal data held by an organisation and to request correction of errors or omissions. Under the Access Obligation (Section 21), organisations must upon request provide individuals with their personal data and information about how it was used or disclosed in the past year. Under the Correction Obligation (Section 22), organisations must correct inaccurate or incomplete personal data upon request. The Singapore PDPA's 2020 amendments also introduced a data portability right (Section 22A), allowing individuals to request that their data be transmitted to another organisation in a commonly used machine-readable format. The GDPR provides a broader set of individual rights than the Singapore PDPA: the right of access (Article 15), right to rectification (Article 16), right to erasure or 'right to be forgotten' (Article 17), right to restriction of processing (Article 18), right to data portability (Article 20), right to object to processing (Article 21), and rights related to automated decision-making and profiling (Article 22). The GDPR also provides detailed transparency requirements under Articles 13-14. This difference in the breadth of individual rights is one of the most significant distinctions in the Singapore PDPA vs GDPR comparison. A notable gap in the Singapore PDPA vs GDPR rights comparison is that the Singapore PDPA does not include a general right to erasure comparable to the GDPR's right to be forgotten. The Singapore PDPA's Retention Limitation Obligation (Section 25) requires organisations to stop retaining personal data when it is no longer needed for its original purpose, but this is an organisational obligation rather than an individual right exercisable on demand. Similarly, the Singapore PDPA does not provide a right to restrict processing or a right to object to processing. Response timeframes also differ in the Singapore PDPA vs GDPR comparison. The Singapore PDPA requires organisations to respond to access requests as soon as reasonably possible, with the PDPC generally expecting a response within 30 calendar days. The GDPR requires responses within one calendar month, extendable by two further months for complex requests. The Singapore PDPA allows reasonable fees for access requests more broadly, whereas the GDPR generally requires the first copy to be provided free of charge. - Both frameworks grant access and correction (rectification) rights; the Singapore PDPA requires disclosure of how data was used or disclosed in the past year. - GDPR includes a right to erasure ('right to be forgotten'); the Singapore PDPA has no equivalent individual right but imposes a Retention Limitation Obligation on organisations. - GDPR provides rights to restriction of processing, to object, and regarding automated decision-making; the Singapore PDPA does not include these rights. - Both frameworks now include data portability rights; the Singapore PDPA's version was added in the 2020 amendments. - Singapore PDPA allows reasonable fees for access requests; GDPR generally requires the first copy to be provided free of charge. - Singapore PDPA access request response: as soon as reasonably possible (PDPC expects within 30 days). GDPR: within one calendar month, extendable by two months. - Singapore PDPA vs GDPR rights gap: organisations with GDPR-compliant rights processes need to document that the Singapore PDPA does not require erasure, restriction, or objection rights. - The Singapore PDPA requires organisations to send corrected data to other organisations that received the data in the past year, if the individual requests it. ## Singapore PDPA vs GDPR: breach notification requirements The Singapore PDPA's mandatory data breach notification obligation was introduced in the 2020 amendments (Sections 26A-26E), taking effect on 1 February 2021. Under the Singapore PDPA, an organisation that has reason to believe a data breach has occurred must conduct an assessment to determine whether the breach is 'notifiable.' A data breach is notifiable under the Singapore PDPA if it results in, or is likely to result in, significant harm to affected individuals, or if it involves the personal data of 500 or more individuals. When a breach is notifiable, the organisation must notify the PDPC as soon as practicable, and no later than three calendar days after determining the breach is notifiable. Under the GDPR, a personal data breach must be notified to the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach (Article 33). The 72-hour window is not an outer limit but a target; delayed notifications must include reasons for the delay. Unlike the Singapore PDPA, the GDPR does not use a numeric threshold of 500 or more individuals. Instead, GDPR notification is required unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. The Singapore PDPA vs GDPR breach notification comparison shows different trigger mechanisms and clock-start definitions. Both frameworks require notification to affected individuals in certain circumstances, but the Singapore PDPA vs GDPR thresholds differ. Under the Singapore PDPA, affected individuals must be notified if the breach is likely to result in significant harm to them. Under the GDPR, individuals must be notified when the breach is likely to result in a 'high risk' to their rights and freedoms (Article 34), which is a higher threshold than the standard authority notification trigger. The GDPR also provides exceptions to individual notification when appropriate technical protections (such as encryption) have been applied or when individual notification would require disproportionate effort. Data intermediaries (Singapore PDPA) and data processors (GDPR) also have breach notification duties that flow to the controller or engaging organisation rather than directly to the regulator. Under the Singapore PDPA, a data intermediary must notify the engaging organisation without undue delay after it has credible grounds to believe a breach has occurred. Under the GDPR, a processor must notify the controller without undue delay. In the Singapore PDPA vs GDPR breach notification comparison, both frameworks require intermediaries and processors to escalate breach awareness promptly. - Singapore PDPA: notify PDPC within 3 calendar days after determining a breach is notifiable. GDPR: notify supervisory authority within 72 hours of becoming aware. - Singapore PDPA notification trigger: significant harm to individuals OR 500+ individuals affected. GDPR trigger: any breach likely to result in risk to rights and freedoms (no numeric threshold). - Singapore PDPA vs GDPR breach timing: the Singapore PDPA allows time for assessment before the notification clock starts; the GDPR starts the 72-hour clock from awareness. - Both require notification to affected individuals when harm thresholds are met; GDPR uses a 'high risk' standard, the Singapore PDPA uses 'significant harm.' - Both frameworks require data intermediaries/processors to notify the controlling organisation without undue delay. - GDPR requires breach documentation regardless of whether notification is made; the Singapore PDPA similarly expects documented assessments and decisions. - Under the Singapore PDPA, notification to affected individuals may be waived by the PDPC if it is in the public interest; the GDPR has no equivalent waiver mechanism. ## Singapore PDPA vs GDPR: cross-border data transfer mechanisms The Singapore PDPA's Transfer Limitation Obligation (Section 26) requires organisations to ensure that personal data transferred outside Singapore receives a comparable standard of protection. Organisations may satisfy this through contractual arrangements with the overseas recipient (such as using the ASEAN Model Contractual Clauses), binding corporate rules approved by the PDPC, or the individual's consent after being informed of the risks. In the Singapore PDPA vs GDPR transfer comparison, the Singapore PDPA's approach centres on achieving a 'comparable standard' rather than the GDPR's concept of 'adequate protection.' The GDPR provides a tiered system for cross-border transfers under Chapter V. The primary mechanisms are: adequacy decisions by the European Commission (Article 45), standard contractual clauses (SCCs) adopted by the Commission (Article 46(2)(c)), binding corporate rules (Article 47), and other safeguards such as codes of conduct and certification mechanisms. Following the Schrems II judgment, organisations using SCCs must also conduct a Transfer Impact Assessment to evaluate the recipient country's legal framework and may need supplementary measures. The Singapore PDPA does not have a formal Transfer Impact Assessment requirement, though the PDPC expects due diligence. The ASEAN-EU Joint Guide to ASEAN Model Contractual Clauses and EU Standard Contractual Clauses, updated 31 January 2024, provides a practical bridging tool for organisations transferring data between Singapore and the EU. For the Singapore PDPA vs GDPR transfer comparison, the key structural difference is that ASEAN MCCs offer two modules (controller-to-processor and controller-to-controller), while EU SCCs offer four modules (adding processor-to-processor and processor-to-controller). Parties may vary the ASEAN MCCs as long as amendments do not undermine ASEAN Data Protection Principles, whereas the EU SCCs may not be altered except for module selection and appendix completion. Onward transfer rules also differ in the Singapore PDPA vs GDPR comparison. Under the Singapore PDPA, organisations remain responsible for ensuring comparable protection when data is transferred further from the initial overseas recipient. Under the GDPR, the data importer under SCCs may only disclose personal data to a third party outside the EU if specific conditions are met, including adequacy decisions, additional SCCs, binding corporate rules, or explicit informed consent from the data subject. Both frameworks hold the data exporter responsible for protection after data leaves the jurisdiction. - Singapore PDPA: transfers must ensure a comparable standard of protection; mechanisms include contractual clauses, binding corporate rules, and informed consent. - GDPR: tiered transfer system with adequacy decisions, SCCs, binding corporate rules, codes of conduct, and certification mechanisms. - Singapore PDPA vs GDPR transfers: ASEAN MCCs have 2 modules (C2P and C2C); EU SCCs have 4 modules (C2C, C2P, P2P, P2C). - ASEAN MCCs may be amended if consistent with ASEAN Data Protection Principles; EU SCCs may not be altered in their core text. - GDPR requires a Transfer Impact Assessment post-Schrems II; the Singapore PDPA does not have an equivalent formal assessment but expects due diligence. - The ASEAN-EU Joint Guide (updated January 2024) helps organisations bridge both sets of clauses for Singapore PDPA vs GDPR cross-border transfer compliance. - Both frameworks hold the data exporter responsible for the protection of personal data after it leaves the jurisdiction. - The Singapore PDPA allows the PDPC to exempt organisations from the transfer limitation obligation in certain circumstances; the GDPR allows derogations under Article 49. ## Singapore PDPA vs GDPR: penalties and enforcement The PDPC enforces the Singapore PDPA and may issue directions to organisations to stop processing personal data in breach of the Act, to destroy collected data, or to pay financial penalties. Following the 2020 amendments, the maximum financial penalty under the Singapore PDPA was increased to SGD 1 million or 10% of the organisation's annual turnover in Singapore (whichever is higher) for organisations with annual turnover exceeding SGD 10 million. For organisations with turnover below this threshold, the Singapore PDPA cap remains at SGD 1 million. The Singapore PDPA vs GDPR penalty comparison shows a significant difference in maximum fine levels. The GDPR establishes a two-tier penalty structure. For less severe violations (such as failures relating to data protection by design, record-keeping, or breach notification), fines may reach up to EUR 10 million or 2% of global annual turnover, whichever is higher. For more severe violations (such as unlawful processing, violation of data subject rights, or non-compliant international transfers), fines may reach EUR 20 million or 4% of global annual turnover. In the Singapore PDPA vs GDPR penalty comparison, the GDPR's calculation is based on global group turnover, whereas the Singapore PDPA's is based on Singapore turnover only. The enforcement style also differs in the Singapore PDPA vs GDPR comparison. The PDPC publishes detailed enforcement decisions that provide concrete guidance on how the Singapore PDPA applies to specific fact patterns. This case-based approach gives organisations practical compliance insight. EU supervisory authorities also publish decisions, but the decentralised enforcement structure means interpretation can vary across member states despite the EDPB's consistency mechanism. The GDPR grants supervisory authorities broader investigative and corrective powers, including the ability to impose temporary or permanent processing bans. The Singapore PDPA's 2020 amendments introduced criminal offences for egregious mishandling of personal data (Part 9B), covering knowing or reckless unauthorised disclosure, use of personal data for wrongful gain or loss, and re-identification of anonymised data. The GDPR does not include criminal penalties at the EU level, though individual member states may introduce criminal sanctions under their national implementing legislation. This is a notable distinction in the Singapore PDPA vs GDPR enforcement comparison. - Singapore PDPA maximum financial penalty: SGD 1 million or 10% of Singapore annual turnover (whichever is higher) for large organisations; SGD 1 million cap for smaller organisations. - GDPR maximum fines: EUR 20 million or 4% of global annual turnover for severe violations; EUR 10 million or 2% for less severe violations. - Singapore PDPA vs GDPR penalties: Singapore PDPA is based on Singapore turnover; GDPR is based on worldwide group turnover. - Singapore PDPA introduced criminal offences for egregious mishandling in 2020; GDPR does not include EU-level criminal penalties but member states may add them. - PDPC publishes detailed enforcement decisions with practical compliance guidance; EU supervisory authorities publish decisions but interpretation may vary across member states. - Both frameworks allow regulators to issue corrective orders including requiring organisations to stop processing or delete data. - PDPC may accept undertakings as an alternative to formal enforcement; some EU supervisory authorities have similar powers. - The GDPR's one-stop-shop mechanism centralises cross-border enforcement through a lead supervisory authority; the Singapore PDPA has a single national regulator (PDPC). ## Singapore PDPA vs GDPR: DPO and accountability requirements Under the Singapore PDPA's Accountability Obligation (Sections 11 and 12), every organisation must designate at least one individual to be responsible for ensuring compliance with the Act. This designated Data Protection Officer (DPO) must have their business contact information made available to the public. The Singapore PDPA requires DPO designation for all organisations subject to the Data Protection Provisions, with no exemptions based on organisational size or the nature of processing activities. However, the Singapore PDPA does not prescribe specific qualifications, certifications, or independence requirements for the DPO. Under the GDPR, the appointment of a Data Protection Officer is mandatory only in specific circumstances defined in Article 37. A DPO must be designated when the processing is carried out by a public authority or body, when core activities require regular and systematic monitoring of data subjects on a large scale, or when core activities involve large-scale processing of special categories of data. Outside these cases, GDPR DPO appointment is optional. In the Singapore PDPA vs GDPR DPO comparison, the Singapore PDPA mandates DPO appointment universally while the GDPR applies DPO requirements selectively. The GDPR imposes more detailed requirements on the DPO role than the Singapore PDPA. The GDPR DPO must be independent, must not receive instructions regarding the exercise of their tasks, must report directly to the highest level of management, may not be dismissed or penalised for performing their duties, and must have access to necessary resources. The DPO's contact details must be published and communicated to the supervisory authority. None of these specific independence or reporting requirements exist under the Singapore PDPA. In the Singapore PDPA vs GDPR DPO comparison, the GDPR DPO role is more structured and protected. In practice, multinational organisations often appoint a single individual or team to fulfil DPO functions across both jurisdictions. This approach works because the Singapore PDPA's DPO role is less prescriptive and can be combined with the GDPR's more structured requirements. The Singapore PDPA's Accountability Obligation also requires organisations to develop and implement data protection policies and make information about these policies publicly available, which aligns with GDPR accountability principles under Article 5(2) and Article 24. - Singapore PDPA: DPO designation is mandatory for all organisations subject to the Data Protection Provisions, with no size or activity thresholds. - GDPR: DPO appointment is mandatory only for public authorities, organisations conducting large-scale systematic monitoring, or those processing special category data at scale. - Singapore PDPA vs GDPR DPO: the Singapore PDPA mandates universal DPO appointment; the GDPR applies DPO requirements selectively based on processing activities. - Singapore PDPA does not prescribe DPO qualifications, independence, or reporting lines; GDPR requires independence, direct reporting to top management, and freedom from conflicts of interest. - Both frameworks require that DPO contact information be made publicly available; the GDPR additionally requires notification of DPO details to the supervisory authority. - Singapore PDPA DPO role can be combined with other organisational roles without restriction; GDPR DPO must avoid conflicts of interest. - Multinational organisations can appoint a single DPO team that satisfies both Singapore PDPA and GDPR requirements by building to the higher GDPR standard. ## Singapore PDPA vs GDPR: data intermediary and data processor obligations The Singapore PDPA defines a 'data intermediary' as an organisation that processes personal data on behalf of another organisation but does not include an employee of that other organisation. This concept is broadly analogous to the GDPR's 'data processor,' but the regulatory treatment differs. Under the Singapore PDPA, a data intermediary that processes personal data on behalf of another organisation under a written contract is subject to only three of the ten Data Protection Provisions: the Protection Obligation, the Retention Limitation Obligation, and the Data Breach Notification Obligation (specifically, the duty to notify the engaging organisation of breaches without undue delay). All other obligations remain with the engaging organisation. Under the GDPR, data processors have a broader set of direct obligations. Article 28 requires a binding contract specifying the subject matter and duration of processing, the nature and purpose of processing, the type of personal data, and categories of data subjects. Processors must process data only on documented instructions from the controller, ensure confidentiality, implement appropriate security measures, assist with data subject requests, support breach notification, delete or return data after services end, and demonstrate compliance. In the Singapore PDPA vs GDPR processor comparison, GDPR processors carry significantly more direct obligations and are directly liable for violations. A critical difference in the Singapore PDPA vs GDPR comparison is how primary responsibility is allocated. Section 4(3) of the Singapore PDPA states that an organisation has the same obligations in respect of personal data processed on its behalf by a data intermediary as if it processed the data itself. This means the engaging organisation cannot delegate compliance obligations through outsourcing. The GDPR also holds controllers responsible but additionally imposes direct compliance obligations and potential liability on processors, creating a dual accountability model. When engaging data intermediaries for cross-border processing under the Singapore PDPA, the engaging organisation must comply with the Transfer Limitation Obligation regardless of whether the data intermediary performs the actual transfer. The PDPC Advisory Guidelines on Key Concepts recommend that organisations exercise appropriate due diligence when selecting data intermediaries, including evaluating their protection policies, practices, and compliance with relevant standards. - Singapore PDPA data intermediary obligations are limited to: Protection, Retention Limitation, and Data Breach Notification (notifying the engaging organisation). - GDPR processor obligations include: processing only on instructions, confidentiality, security, assisting with data subject requests, breach notification, data return or deletion, and compliance demonstration. - Singapore PDPA vs GDPR processor comparison: GDPR processors have direct liability and broader obligations; Singapore PDPA data intermediaries have limited direct obligations. - Singapore PDPA Section 4(3): the engaging organisation bears the same obligations as if it processed the data itself; cannot delegate compliance through outsourcing. - Both frameworks require written contracts between the controller/engaging organisation and the processor/data intermediary. - Singapore PDPA data intermediary contracts should specify scope, responsibilities, and liabilities; the GDPR mandates specific contract clauses under Article 28(3). - Sub-processing: GDPR requires prior specific or general written authorisation from the controller; the Singapore PDPA does not prescribe a formal sub-processing authorisation mechanism. - Organisations must exercise due diligence on data intermediary capabilities under both the Singapore PDPA and GDPR. ## Singapore PDPA vs GDPR: practical guidance for dual compliance Organisations operating in both Singapore and the EU should build a unified privacy governance framework that uses the higher standard as the baseline and adds jurisdiction-specific overlays where the Singapore PDPA vs GDPR requirements diverge. In most cases, the GDPR sets the higher bar for documentation, data subject rights, and breach notification timelines, so building to GDPR standards and adding Singapore PDPA-specific requirements is more efficient than maintaining two separate programs. However, the Singapore PDPA has unique requirements -- the DNC Registry, deemed consent mechanisms, the universal DPO mandate, and the business contact information exclusion -- that cannot be addressed through GDPR compliance alone. Start by creating a processing inventory that maps each processing activity to both Singapore PDPA obligations and GDPR lawful bases. For each activity, document the Singapore PDPA consent mechanism or exception relied upon alongside the GDPR Article 6 legal basis. This dual-mapped inventory becomes the foundation for both Singapore PDPA and GDPR compliance evidence and ensures that any changes to processing activities are evaluated against both frameworks simultaneously. The inventory should note where the Singapore PDPA's deemed consent provisions serve as the equivalent of GDPR's contractual necessity or legitimate interests bases. Vendor and data intermediary governance is another area where unified controls reduce duplication in the Singapore PDPA vs GDPR compliance program. A single vendor assessment questionnaire can cover both GDPR Article 28 processor requirements and Singapore PDPA data intermediary due diligence expectations. The contract template should include GDPR-compliant processor clauses (which exceed Singapore PDPA requirements) plus Singapore PDPA-specific provisions. For cross-border transfers, organisations can use the ASEAN-EU Joint Guide as a reference for implementing both ASEAN MCCs and EU SCCs in a coordinated manner. Incident response playbooks should account for both the Singapore PDPA vs GDPR notification timelines. The GDPR's 72-hour supervisory authority notification clock starts from awareness; the Singapore PDPA's 3-calendar-day clock starts from the determination that a breach is notifiable. In practice, the GDPR deadline may arrive earlier because the Singapore PDPA allows time for assessment before the clock starts. Design your incident response workflow to first assess the breach (serving both frameworks), then notify the relevant EU supervisory authority within 72 hours while completing the Singapore PDPA notifiability assessment and notifying the PDPC within 3 days of that determination. - Build to GDPR standards as the baseline and add Singapore PDPA-specific overlays for deemed consent, DNC Registry, and universal DPO requirements. - Create a dual-mapped processing inventory linking each activity to both Singapore PDPA consent mechanisms/exceptions and GDPR Article 6 legal bases. - Use a single vendor assessment template covering both GDPR Article 28 processor requirements and Singapore PDPA data intermediary due diligence. - Design contract templates with GDPR-compliant processor clauses plus Singapore PDPA-specific breach notification and retention provisions. - Align breach notification playbooks to the earlier GDPR timeline while maintaining the Singapore PDPA assessment-then-notify workflow. - Train staff on both frameworks through a unified training program, highlighting where the Singapore PDPA departs from GDPR assumptions (deemed consent, business contact information exclusion, DNC Registry). - Conduct quarterly cross-framework reviews with legal counsel in both jurisdictions to track regulatory updates from both the PDPC and relevant EU supervisory authorities. - Use the ASEAN-EU Joint Guide to ASEAN MCCs and EU SCCs as a bridge for cross-border transfer documentation between Singapore and EU entities. ## Singapore PDPA vs GDPR: key takeaways for multinational organisations The Singapore PDPA and the EU GDPR share a common philosophical foundation: both seek to protect personal data while enabling its responsible use for legitimate purposes. Organisations that already comply with one framework have a significant head start on the other. However, assuming full equivalence between the Singapore PDPA and the GDPR is a compliance risk. The differences in consent models, individual rights, enforcement structures, and cross-border transfer mechanisms require deliberate mapping and gap analysis. Treating the Singapore PDPA vs GDPR comparison as a single compliance challenge with regional variations is the most efficient and defensible approach. From a resource perspective, the biggest return on investment in Singapore PDPA vs GDPR compliance comes from building shared infrastructure: a single processing inventory, one incident response platform, unified vendor governance, and a common training program. Jurisdiction-specific work -- such as Singapore PDPA deemed consent assessments or GDPR Transfer Impact Assessments -- can be layered on top without duplicating the foundational effort. This modular approach also makes it easier to add further jurisdictions as the organisation expands, since the core framework accommodates additional regulatory overlays. Organisations should monitor regulatory developments in both jurisdictions for ongoing Singapore PDPA vs GDPR compliance. The PDPC regularly publishes enforcement decisions, advisory guidelines, and practical guidance. The EDPB, EU supervisory authorities, and the Court of Justice of the EU continue to refine GDPR interpretation through guidelines, decisions, and judgments. The ASEAN-EU data protection dialogue, including the Joint Guide to MCCs and SCCs, signals growing regulatory convergence that may simplify Singapore PDPA vs GDPR dual compliance over time. - Do not assume GDPR compliance automatically satisfies Singapore PDPA requirements; conduct an explicit gap analysis for deemed consent, DNC Registry, business contact information, and universal DPO obligations. - Build shared compliance infrastructure (processing inventory, incident response, vendor governance) and add jurisdiction-specific overlays for Singapore PDPA vs GDPR differences. - Map GDPR legitimate interests processing activities to appropriate Singapore PDPA mechanisms (deemed consent, exceptions, or the legitimate interests exception). - Account for the Singapore PDPA's exclusion of business contact information and public agency exemption, which have no GDPR equivalents. - Use the ASEAN-EU Joint Guide as a practical bridge for cross-border data transfers between Singapore and EU entities. - Track PDPC enforcement decisions and advisory guidelines alongside EDPB guidance and EU supervisory authority decisions for ongoing Singapore PDPA vs GDPR compliance. - Design your privacy program with a modular governance structure: shared baseline plus regulatory overlays for each jurisdiction. - Invest in organisational culture and staff training as the foundation for sustainable multi-jurisdictional Singapore PDPA vs GDPR compliance. ## Primary sources - [Personal Data Protection Act 2012 (Singapore) - official text](https://sso.agc.gov.sg/Act/PDPA2012?ref=sorena.io) - Primary legislation governing collection, use, disclosure, protection, retention, transfer, and accountability for personal data in Singapore. - [PDPC - PDPA overview](https://www.pdpc.gov.sg/overview-of-pdpa/pdpa-overview?ref=sorena.io) - Official PDPC overview of PDPA obligations, key concepts, Do Not Call Registry, and regulatory updates. - [PDPC - Advisory Guidelines on Key Concepts in the PDPA (Revised 16 May 2022)](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-the-personal-data-protection-act?ref=sorena.io) - Core interpretation guidance for consent, deemed consent, purpose limitation, notification, access/correction, accuracy, protection, retention, transfers, data breach notification, and accountability. - [PDPC - Advisory Guidelines on Enforcement of Data Protection Provisions](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-enforcement-of-data-protection-provisions?ref=sorena.io) - Enforcement approach, directions, financial penalties, undertakings, and criminal offences for egregious mishandling. - [ASEAN-EU Joint Guide to ASEAN Model Contractual Clauses and EU Standard Contractual Clauses (Updated 31 January 2024)](https://commission.europa.eu/document/download/6a40ea57-5994-4395-b5a0-d94c8ca1053b_en?ref=sorena.io) - Practical bridging tool mapping ASEAN MCCs and EU SCCs for cross-border data transfers between ASEAN (including Singapore) and the EU. - [Regulation (EU) 2016/679 (General Data Protection Regulation) - full text](https://eur-lex.europa.eu/eli/reg/2016/679/oj?ref=sorena.io) - Official consolidated text of the GDPR governing personal data processing in the EU/EEA. ## Related Topic Guides - [Singapore PDPA Applicability Test | Does the PDPA Apply to Your Organisation?](/artifacts/apac/singapore-pdpa/applicability-test.md): Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation. - [Singapore PDPA Breach Notification Playbook - Complete Guide](/artifacts/apac/singapore-pdpa/breach-notification-playbook.md): Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline. - [Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026)](/artifacts/apac/singapore-pdpa/checklist.md): Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules. - [Singapore PDPA Compliance Deadlines and Calendar](/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar.md): Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows. - [Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM](/artifacts/apac/singapore-pdpa/compliance.md): Complete Singapore PDPA compliance guide for organisations. - [Singapore PDPA Consent and Notification Obligations Guide](/artifacts/apac/singapore-pdpa/consent-notification-and-purposes.md): Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception. - [Singapore PDPA Cross-Border Transfer Rules | Section 26 Data Transfer Compliance](/artifacts/apac/singapore-pdpa/cross-border-transfers.md): Complete guide to Singapore PDPA cross-border transfer compliance under Section 26. - [Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide](/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages.md): Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses. - [Singapore PDPA FAQ | Frequently Asked Questions on Personal Data Protection Act Compliance](/artifacts/apac/singapore-pdpa/faq.md): Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements. - [Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions](/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases.md): Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover. - [Singapore PDPA Penalties and Fines | SGD 1M or 10% Turnover Cap + PDPC Enforcement Guide](/artifacts/apac/singapore-pdpa/penalties-and-fines.md): Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions. - [Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide](/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template.md): Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions. - [Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC)](/artifacts/apac/singapore-pdpa/requirements.md): Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18). - [Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations](/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries.md): Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion. - [Singapore PDPA Vendor Outsourcing and Contracts Guide](/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts.md): Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr --- --- title: "Singapore PDPA Vendor Outsourcing and Contracts Guide" canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts" source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts" author: "Sorena AI" description: "Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Singapore PDPA vendor" - "Singapore PDPA outsourcing" - "Singapore PDPA vendor management" - "Singapore PDPA data intermediary" - "Singapore PDPA vendor contracts" - "Singapore PDPA vendor due diligence" - "PDPA data intermediary obligations" - "PDPC contract clauses" - "Singapore PDPA sub-processor" - "Singapore PDPA cloud compliance" - "Singapore PDPA vendor audit" - "Singapore PDPA vendor exit management" - "Singapore PDPA cross-border transfer" - "PDPA Protection Obligation" - "PDPA Retention Limitation Obligation" - "PDPA Data Breach Notification" - "PDPA Transfer Limitation Obligation" - "PDPA vendor risk assessment" - "PDPA accountability obligation" - "data intermediary management lifecycle" - "PDPC Guide to Managing Data Intermediaries" - "PDPC data protection clauses" - "Singapore PDPA compliance" - "PDPA vendor monitoring" - "PDPA sub-contracting controls" - "Singapore PDPA SaaS compliance" - "PDPA DPTM certification" - "APEC CBPR Singapore" - "ASEAN Model Contractual Clauses" - "Singapore PDPA vendor onboarding" - "Singapore PDPA vendor checklist" - "Singapore PDPA" - "data intermediary contracts" - "APAC privacy" - "data protection" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Singapore PDPA Vendor Outsourcing and Contracts Guide Singapore PDPA vendor outsourcing guide covering data intermediary contracts, Singapore PDPA outsourcing obligations, vendor due diligence. *Artifact Guide* *APAC* ## Singapore PDPA Vendor Outsourcing and Contracts Singapore PDPA vendor outsourcing guide: data intermediary contracts, PDPC-recommended contract clauses, vendor due diligence, sub-processor controls, breach notification duties, cloud compliance, and exit management procedures. Grounded in the PDPC Guide to Managing Data Intermediaries and PDPC Guide on Data Protection Clauses to make Singapore PDPA outsourcing obligations enforceable in every vendor relationship. This page is an implementation-focused guide for managing Singapore PDPA vendor outsourcing and data intermediary contracts under the Personal Data Protection Act (PDPA). Singapore PDPA vendor management follows the four-stage data intermediary (DI) management lifecycle published by the Personal Data Protection Commission (PDPC): governance and risk assessment, policies and practices, service management, and exit management. Whether you are a data controller engaging Singapore PDPA vendors for IT services, cloud hosting, payroll processing, or marketing analytics, this guide explains how the PDPA allocates responsibility between your organisation and each data intermediary. Singapore PDPA outsourcing obligations require that you conduct due diligence, draft enforceable contracts with PDPC-recommended data protection clauses, monitor vendor performance, manage sub-processors, and handle vendor exit. Use the PDPA statute and PDPC guidance documents linked below, and tailor the details to your processing context, data sensitivity, and vendor risk profile. ## Singapore PDPA Vendor Responsibility: How the PDPA Allocates Outsourcing Obligations Under the Singapore PDPA, a data intermediary (DI) is an organisation that processes personal data on behalf of another organisation pursuant to a contract. Section 4(3) of the PDPA makes clear that a data controller has the same obligations under the PDPA in respect of personal data processed on its behalf by a Singapore PDPA vendor as if the personal data were processed by the organisation itself. This statutory provision is the foundation of all Singapore PDPA outsourcing accountability: even when processing is delegated to a vendor, the data controller retains full responsibility. The PDPC Advisory Guidelines on Key Concepts in the PDPA (Revised 16 May 2022) confirm in Chapter 6 that a Singapore PDPA vendor acting as a data intermediary is subject to three specific obligations: the Protection Obligation under Section 24 (reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, or disposal), the Retention Limitation Obligation under Section 25 (ceasing to retain personal data once the purpose is no longer served), and the Data Breach Notification Obligation (notifying the data controller of data breaches without undue delay). If a Singapore PDPA vendor uses or discloses personal data beyond the scope authorised by the data controller, the vendor must comply with all eleven Data Protection Provisions under the PDPA. The PDPC enforcement decision in Re Royal Caribbean Cruises (Asia) Pte. Ltd. [2020] SGPDPC 5 illustrates how Singapore PDPA vendor accountability works in practice. The PDPC stated: 'Without clarity, the risks of any omissions will fall on the Organisation, which as data controller is ultimately responsible.' This decision underscores that Singapore PDPA outsourcing arrangements without written contracts setting out vendor obligations expose the data controller to enforcement action. Organisations that act as Singapore PDPA vendors should also recognise that they may serve as a data controller for their own internal processing activities (such as handling employee data) while simultaneously serving as a data intermediary when processing personal data on behalf of their business customers. The PDPC Advisory Guidelines confirm that an organisation may be a data intermediary of another even if the written contract does not clearly identify it as such. Data protection officers must carefully map which role applies to each category of processing to ensure that Singapore PDPA outsourcing obligations are correctly assigned. - Under Section 4(3) of the PDPA, the data controller retains the same obligations for personal data processed by a Singapore PDPA vendor as if it processed the data itself. - A Singapore PDPA vendor acting as a data intermediary must comply with the Protection Obligation (Section 24), the Retention Limitation Obligation (Section 25), and the Data Breach Notification Obligation. - If a Singapore PDPA vendor uses personal data beyond the scope authorised by the data controller, the vendor must comply with all eleven PDPA obligations. - The PDPC has consistently held data controllers liable for failures in Singapore PDPA vendor oversight, including in Re Royal Caribbean Cruises and Re SCAL Academy. - A company may act as both a data controller and a Singapore PDPA vendor (data intermediary) depending on the processing activity. - Singapore PDPA outsourcing contracts must clearly document the DI relationship even if it is not explicitly labelled as such. ## Singapore PDPA Vendor Due Diligence Requirements The PDPC Guide to Managing Data Intermediaries establishes that data controllers must conduct proper due diligence before selecting a Singapore PDPA vendor. Good accountability practices begin with the organisation's leadership and governance structure. The decision to outsource data processing activities and the scope of such Singapore PDPA outsourcing should be determined by senior management. Senior management should understand the risks involved in outsourcing, which requires identifying and assessing personal data risks on a regular basis. At the governance and risk assessment stage of the Singapore PDPA vendor lifecycle, the data controller's roles include establishing business objectives and requirements for the proposed outsourcing, determining the scale and sensitivity of personal data involved, identifying potential high-level risks relevant to evaluation criteria, and identifying requirements that should be set out in the contract. Knowing the scale of Singapore PDPA outsourcing and the sensitivity of personal data helps the data controller ensure that any potential vendor has the ability to provide an appropriate standard of protection. The data controller should be satisfied that each Singapore PDPA vendor has the necessary data protection framework, including policies, practices, and training for its staff, as well as appropriate security arrangements. As part of exercising due diligence, the data controller should check the Singapore PDPA vendor's track record and consider whether the vendor's data protection practices are subject to regular external reviews and validation. Relevant certifications include the Data Protection Trustmark (DPTM), the APEC Cross Border Privacy Rules (CBPR) System, and the APEC Privacy Recognition for Processors (PRP) System. For high-volume or sensitive data processing, the PDPC recommends that data controllers consider engaging Singapore PDPA vendors that have obtained the DPTM Certification or equivalent certifications. The data controller should also require potential Singapore PDPA vendors to demonstrate security arrangements that are sufficiently robust and comprehensive to guard against intrusion or attack. Where appropriate, a Data Protection by Design approach should be adopted to ascertain the right measures and safeguards for every Singapore PDPA outsourcing arrangement. - Senior management should approve the decision to outsource and understand the associated personal data risks before engaging any Singapore PDPA vendor. - Assess each Singapore PDPA vendor candidate against its data protection framework, policies, staff training, and security arrangements. - Check the Singapore PDPA vendor's track record and consider certifications such as the DPTM, APEC CBPR, and APEC PRP. - Evaluate the Singapore PDPA vendor's ability to handle the volume and sensitivity of personal data to be processed. - Conduct or review Data Protection Impact Assessments (DPIAs) for Singapore PDPA outsourcing arrangements involving sensitive data. - Require potential Singapore PDPA vendors to demonstrate robust security arrangements, including penetration testing results and access control documentation. - Consider Data Protection by Design principles when scoping Singapore PDPA vendor requirements for ICT systems and software. ## PDPC-Recommended Data Protection Clauses for Singapore PDPA Vendor Contracts The PDPC has published a dedicated Guide on Data Protection Clauses for Agreements Relating to the Processing of Personal Data, updated 1 February 2021 to account for PDPA amendments. This guide provides sample data protection clauses that organisations may include in their service agreements when engaging Singapore PDPA vendors to provide services relating to the processing of personal data. The sample clauses should be adapted to suit the organisation's particular circumstances and the scope of Singapore PDPA outsourcing. A binding contractual agreement between the data controller and its Singapore PDPA vendor must set out clearly the obligations and responsibilities of all parties, particularly the vendor with regard to the processing of personal data on behalf of and for the purposes of the data controller. If the contract is not in writing, the key terms must at minimum be evidenced in writing. The PDPC has stated that it is a breach of the PDPA if there is no contractual agreement or document setting out the key obligations and responsibilities of the data intermediary. Singapore PDPA vendor contracts could also reference technical standards like ISO 27001 for cloud services, ISO/IEC 27018:2019 for protection of personally identifiable information in public clouds, or ISO/IEC 29100:2011 for privacy frameworks. Annex B of the PDPC Guide to Managing Data Intermediaries outlines specific contract considerations that every Singapore PDPA vendor agreement should address. These include: prohibition against unauthorised use or disclosure of personal data; specific data protection measures such as encryption and restrictions on storing full NRIC numbers; sub-contracting controls and approval requirements; incident reporting without undue delay; overseas transfer location controls and comparable protection standards; consent-gathering processes when the Singapore PDPA vendor collects consent on behalf of the data controller; SOP requirements and regular management meetings; audit and on-site inspection rights; and data return or destruction at contract end. In setting out Singapore PDPA vendor contracts, the data controller should also consider and review details like the schedules and administrative instructions outside the main contract. These could be developed in consultation with the Singapore PDPA vendor, as the vendor may have the requisite technical or operational expertise. However, the data controller must take all reasonable steps to communicate specific requirements. As stated in Re SCAL Academy Pte. Ltd. [2020] SGPDPC 22, organisations must articulate their business requirements, work with Singapore PDPA vendors on agreed technical measures, and follow through with proper testing based on risk scenarios derived from the business requirements. - Use the PDPC Guide on Data Protection Clauses as a starting template for every Singapore PDPA vendor contract and customise for your processing context. - Singapore PDPA vendor contracts must clearly state the scope of data processing activities and each party's obligations. - Include clauses prohibiting any use or disclosure of personal data by the Singapore PDPA vendor for unauthorised purposes. - Specify data protection measures in every Singapore PDPA vendor contract: encryption standards, access controls, restriction on storing full NRIC numbers. - Require Singapore PDPA vendor agreement to technical standards (ISO 27001, ISO/IEC 27018, ISO/IEC 29100) where applicable. - Address sub-contracting: require data controller approval before any sub-contracting of Singapore PDPA outsourcing activities. - Include rights for the data controller to audit, request independent audit reports, and conduct on-site inspections of Singapore PDPA vendors. - State timelines for data return or irreversible destruction, deletion, or anonymisation at the end of each Singapore PDPA vendor contract. ## Ongoing Singapore PDPA Vendor Monitoring and Auditing Obligations An accountable data controller not only develops and communicates data protection policies but also puts in place monitoring and reporting structures to manage every Singapore PDPA vendor throughout the engagement. The PDPC Guide to Managing Data Intermediaries covers service management in detail, recommending project management committees that report to the Board or senior management, regular meetings with Singapore PDPA vendors, periodic audits, on-site inspections, and proper onboarding with staff training. Onboarding is a critical step in the Singapore PDPA vendor management lifecycle. The data controller should brief key members of the vendor's project team on business requirements, data protection risks and mitigation measures, contractual arrangements including roles and responsibilities, and standard operating procedures including reporting expectations. For larger-scale Singapore PDPA outsourcing, a formal onboarding process is recommended. For smaller-scale activities, a kick-off meeting may serve the same purpose. When a data controller has multiple Singapore PDPA vendors with overlapping data processing activities, the onboarding process should ensure a clear understanding of each vendor's respective scope. Regular meetings with key members of the Singapore PDPA vendor's data processing team ensure steady information flow and allow the data controller to verify that operations follow contractual arrangements and agreed SOPs. Representatives from both the data controller and the Singapore PDPA vendor at these meetings should be sufficiently senior to make decisions when necessary. These meetings also serve as a forum for discussing management reports and addressing issues raised in incident reports. Audits and on-site inspections give the data controller the ability to verify that each Singapore PDPA vendor is properly carrying out its roles, particularly where the vendor processes large amounts of sensitive personal data over extended periods. The data controller should determine the necessity and frequency of audits based on the risk profile, the nature and extent of Singapore PDPA outsourcing activities, and the severity and likelihood of identified risks. The PDPC also recommends simulation and table-top exercises to test the effectiveness of ad-hoc incident reporting and remediation plans between the data controller and each Singapore PDPA vendor. - Conduct formal onboarding for every Singapore PDPA vendor at the start of each engagement, covering scope, risks, SOPs, and reporting chains. - Hold regular management meetings with Singapore PDPA vendor representatives at an appropriate seniority level. - Define format and frequency for Singapore PDPA vendor reporting: regular management reports and ad-hoc incident reports. - Conduct periodic audits and on-site inspections of Singapore PDPA vendors based on the risk profile of the outsourced processing. - Request independent audit reports for high-risk or large-scale Singapore PDPA outsourcing activities. - Run simulation and table-top exercises to test incident response and breach notification workflows with each Singapore PDPA vendor. - Require Singapore PDPA vendors to implement proactive monitoring including database access logs and system log reviews. - Document audit findings and track remediation of any identified data protection gaps in Singapore PDPA vendor operations. ## Sub-Processing and Chain Data Intermediary Management Under the Singapore PDPA When a Singapore PDPA vendor sub-contracts data processing activities to another entity, it creates a chain of data intermediaries that increases the risk of data breaches and loss of control over personal data. The PDPC Guide to Managing Data Intermediaries addresses sub-processing directly in Annex B, recommending that Singapore PDPA vendor contracts include either a prohibition against sub-contracting or a requirement that the data controller must approve any sub-contracting before it takes place. Where the data controller permits sub-contracting, the Singapore PDPA vendor's agreement with the sub-contractor must impose the same data protection obligations on the sub-contractor as those imposed on the vendor by the data controller. This ensures that the standard of protection flows down through the entire chain of Singapore PDPA outsourcing. The data controller should maintain visibility into who is processing its personal data and under what conditions, even when it is a sub-contractor rather than the primary Singapore PDPA vendor. Practical management of sub-processors in Singapore PDPA vendor arrangements requires a documented approach. The data controller should maintain a sub-processor register listing all entities that have access to personal data, the scope of their processing activities, the geographic locations where data is processed, and the contractual protections in place. The Singapore PDPA vendor should be contractually required to notify the data controller of any changes to its sub-processor arrangements, including new sub-processors or changes in the scope of existing sub-processing. - Include contractual clauses requiring data controller approval before any sub-contracting of Singapore PDPA outsourcing activities. - Where sub-contracting is allowed, require the Singapore PDPA vendor to impose equivalent data protection obligations on the sub-contractor. - Maintain a sub-processor register with entity names, processing scope, data locations, and contractual protections for every Singapore PDPA vendor chain. - Require the Singapore PDPA vendor to notify the data controller of any changes to sub-processor arrangements before they take effect. - Include rights for the data controller to audit or request audit reports from sub-processors in Singapore PDPA vendor chains. - Ensure data breach notification requirements flow down through the entire Singapore PDPA outsourcing sub-processing chain. - Specify that the primary Singapore PDPA vendor remains accountable to the data controller for any sub-processor non-compliance. ## Singapore PDPA Vendor Breach Notification and Incident Response Obligations The PDPA's Data Breach Notification obligation requires organisations to notify the PDPC and affected individuals as soon as practicable if there is a data breach that is likely to result in significant harm to individuals or is of significant scale. For Singapore PDPA vendor relationships, this creates a time-critical chain: the vendor must notify the data controller, and the data controller must then assess the breach and decide on notification to the PDPC and affected individuals. Any delay in the Singapore PDPA vendor-to-controller notification can compromise the entire timeline. The PDPC Advisory Guidelines on Key Concepts confirm that where a data breach is discovered by a Singapore PDPA vendor that is processing personal data on behalf and for the purposes of another organisation, the vendor is required to notify the organisation without undue delay from the time it has credible grounds to believe that the data breach has occurred. The PDPC Guide to Managing Data Intermediaries further recommends that data controllers establish an escalation process and a reporting chain for incident reporting to ensure Singapore PDPA vendors notify them without undue delay when vendors become aware of any data incidents. A practical enforcement example from the PDPC illustrates the risk of weak Singapore PDPA vendor incident procedures. In one case, an IT vendor managing a customer portal erroneously disclosed a customer's personal data to other customers and subsequently rectified the error but did not notify the data controller. The data controller only became aware of the incident through customer queries. This case demonstrates why contractual SOP requirements for Singapore PDPA vendor incident notification are essential, not optional. Singapore PDPA vendor contracts should specify the notification timeline, the information that must be included in an incident report, the escalation procedures, and the parties responsible for breach containment and remediation. The Singapore PDPA vendor should be required to preserve all evidence related to the incident, cooperate fully with the data controller's investigation, and assist with any required notifications to the PDPC or affected individuals. Data controllers should also put in place drawer plans (pre-prepared response plans) that Singapore PDPA vendors can activate immediately upon discovering a breach. - Require contractual notification from every Singapore PDPA vendor to the data controller without undue delay upon discovery of any data incident. - Define what constitutes a notifiable event in Singapore PDPA vendor contracts: not just confirmed breaches but also suspected incidents and near-misses. - Specify the content of Singapore PDPA vendor incident reports: timeline, systems affected, data categories, number of individuals, and containment actions. - Establish an escalation process with named contacts and backup contacts on both sides of the Singapore PDPA vendor relationship. - Require every Singapore PDPA vendor to preserve all evidence related to data incidents for investigation purposes. - Include drawer plans (pre-prepared response plans) that Singapore PDPA vendors can activate immediately upon discovering a breach. - Require Singapore PDPA vendor cooperation with the data controller's investigation and any required notifications to the PDPC or affected individuals. - Run regular simulation exercises to test the incident notification workflow between the data controller and each Singapore PDPA vendor. ## Cloud Service Provider and SaaS Compliance in Singapore PDPA Outsourcing Cloud service providers (CSPs) and Software-as-a-Service (SaaS) platforms present unique challenges for Singapore PDPA vendor compliance. The PDPC has issued Advisory Guidelines on the PDPA for Selected Topics that include a dedicated chapter on Cloud Services (Chapter 8). These guidelines address the shared responsibility model, where the CSP provides infrastructure security while the data controller retains responsibility for how personal data is used, stored, and accessed within the cloud environment. Every Singapore PDPA outsourcing arrangement involving cloud services must address this division of responsibility. When engaging a CSP as a Singapore PDPA vendor, the data controller should specify in the contract the geographic locations where personal data will be stored and processed. In one PDPC enforcement example, an organisation (ABC) contracted with a CSP (DEF) to store personal data in data centres in Singapore and Hong Kong, and included a contractual clause to bind the CSP to that commitment. The PDPC expects organisations to make an assessment of the risks of trans-border transfer and determine how identified risks can be addressed when selecting any Singapore PDPA vendor for cloud hosting. Technical standards play an important role in Singapore PDPA vendor compliance for cloud services. The PDPC Guide to Managing Data Intermediaries references several relevant standards: ISO 27001 for information security management, ISO/IEC 27018:2019 for protection of personally identifiable information in public clouds acting as PII processors, and the Multi-Tier Cloud Security (MTCS) Standard for Singapore (SS 584). Data controllers should consider requiring Singapore PDPA vendors providing cloud or SaaS services to demonstrate compliance with these standards or equivalent frameworks. - Apply the shared responsibility model: the CSP secures the infrastructure while the data controller secures the data and access controls in Singapore PDPA outsourcing arrangements. - Specify data storage and processing locations in every Singapore PDPA vendor cloud contract and include clauses to restrict transfers beyond approved jurisdictions. - Require Singapore PDPA vendor compliance with relevant standards: ISO 27001, ISO/IEC 27018, ISO/IEC 29100, or MTCS SS 584. - Evaluate SaaS configurations against Data Protection by Design principles: data minimisation, default privacy settings, and end-to-end encryption. - Verify that each Singapore PDPA vendor CSP provides database access monitoring and logging that supports the data controller's audit requirements. - Include the right to receive independent security audit reports (such as SOC 2 or equivalent) from every Singapore PDPA vendor providing cloud services. - Review Singapore PDPA vendor CSP incident response capabilities and confirm alignment with the data controller's breach notification timelines. - Assess whether the Singapore PDPA vendor CSP's sub-processor arrangements are transparent and subject to the same contractual obligations. ## Singapore PDPA Vendor Exit and Data Return or Deletion Procedures The PDPC Guide to Managing Data Intermediaries dedicates a section to exit management, recognising that the conclusion of a Singapore PDPA vendor engagement requires careful planning to ensure business continuity and proper handling of personal data. Under the Retention Limitation Obligation in Section 25 of the PDPA, organisations must cease to retain documents containing personal data once it is reasonable to assume that the purpose for which the data was collected is no longer served by its retention and retention is no longer necessary for legal or business purposes. Singapore PDPA vendor exit management plans should establish clear time frames for the vendor to cease retaining personal data after it has completed the processing activities. An organisation ceases to retain documents containing personal data when it no longer has access to those documents and the personal data they contain. Practical methods include destroying the documents (by shredding or appropriate disposal), or anonymising the personal data so that it can no longer be associated with particular individuals. Part of Singapore PDPA vendor exit management should include the requirement for vendors to ensure that all work done is fully documented and that all documentation is handed over to the data controller upon completion of the project. For IT-related Singapore PDPA outsourcing projects such as data migration, the documentation should include database mapping, extraction scripts, transformation and loading scripts, verification test scripts, and test results. This documentation ensures the data controller can verify the completeness of the handover and continue operations without the departing Singapore PDPA vendor. In the event of a change in Singapore PDPA vendor, the data controller must ensure that any data migration or transfer from one vendor to another is done in a secure manner. After the transition, the data controller should follow through with the same steps of the DI Management Lifecycle for the new Singapore PDPA vendor. Exit audits and checks should be conducted to verify that the departing vendor has complied with all data return and destruction requirements. - Establish written exit management plans covering data return, deletion, and business continuity before each Singapore PDPA vendor engagement begins. - Define clear time frames for every Singapore PDPA vendor to cease retaining all personal data after the contract ends. - Require each Singapore PDPA vendor to return all personal data and work documentation to the data controller upon project completion. - Specify acceptable methods of data destruction in Singapore PDPA vendor contracts: physical shredding, secure electronic deletion, or anonymisation. - For IT-related Singapore PDPA outsourcing projects, require handover documentation including database mappings, scripts, and test results. - Conduct exit audits and checks to verify each Singapore PDPA vendor has completed all data return and destruction activities. - Ensure secure data migration procedures when transitioning from one Singapore PDPA vendor to another. - Require the departing Singapore PDPA vendor to provide written confirmation that all personal data has been destroyed or returned. ## Cross-Border Singapore PDPA Vendor Engagement Requirements When a data controller engages a Singapore PDPA vendor located outside Singapore or when personal data is transferred overseas as part of the Singapore PDPA outsourcing arrangement, the Transfer Limitation Obligation under the PDPA applies. The PDPC Advisory Guidelines on Key Concepts confirm that the data controller is responsible for complying with the Transfer Limitation Obligation in respect of any overseas transfer of personal data, regardless of whether the personal data is transferred by the organisation to an overseas Singapore PDPA vendor or transferred overseas by a vendor in Singapore as part of its processing on behalf of the data controller. Organisations must not transfer personal data outside Singapore unless the recipient is bound by legally enforceable obligations to provide a standard of protection that is comparable to the protection under the PDPA. This applies regardless of whether the overseas recipient is the primary Singapore PDPA vendor or a sub-processor. The PDPC expects organisations to undertake appropriate due diligence and obtain assurances when engaging overseas Singapore PDPA vendors, including reliance on the vendor's extant protection policies, practices, and assurances of compliance with relevant industry standards or certification. Several mechanisms are available to satisfy the transfer limitation requirements when working with overseas Singapore PDPA vendors. These include the ASEAN Model Contractual Clauses (MCCs) for cross-border data flows, the APEC Cross Border Privacy Rules (CBPR) System, and the APEC Privacy Recognition for Processors (PRP) System. The data controller should evaluate which mechanism is most appropriate based on the destination jurisdiction and the nature of the Singapore PDPA outsourcing. For practical implementation, the data controller should map all cross-border data flows in its Singapore PDPA vendor arrangements, identify the jurisdictions involved, evaluate the data protection regime in each jurisdiction, select appropriate transfer safeguards, and document the assessment. This documentation becomes part of the evidence pack that demonstrates compliance with the Transfer Limitation Obligation for every Singapore PDPA vendor engagement involving cross-border transfers. - Identify all cross-border data flows in Singapore PDPA vendor arrangements, including indirect transfers through sub-processors. - Ensure overseas Singapore PDPA vendors are bound by legally enforceable obligations to provide comparable protection to the PDPA. - Use ASEAN Model Contractual Clauses (MCCs), APEC CBPR, or APEC PRP certifications as transfer safeguards for Singapore PDPA outsourcing. - Specify permitted data storage and processing locations in every Singapore PDPA vendor contract involving cross-border transfers. - Include contractual clauses restricting the Singapore PDPA vendor from transferring personal data beyond approved jurisdictions without data controller consent. - Assess the data protection regime in each destination jurisdiction and document the risk assessment for every overseas Singapore PDPA vendor. - Monitor changes in the data protection laws of jurisdictions where Singapore PDPA vendor processing takes place. - Maintain a transfer register documenting all cross-border data flows, safeguards applied, and supporting Singapore PDPA vendor contracts. ## Singapore PDPA Vendor Management Framework and Implementation Templates The PDPC Guide to Managing Data Intermediaries provides a comprehensive DI Management Lifecycle framework with four stages: (A) Governance and Risk Assessment, (B) Policies and Practices, (C) Service Management, and (D) Exit Management. Organisations should determine the appropriate measures to adopt for each Singapore PDPA vendor based on the data protection risk involved, considering the scale of outsourcing, the sensitivity of personal data, and the duration of the contract period. For complex Singapore PDPA outsourcing activities involving a significant scale of personal data, sensitive types of personal data, or a combination of these factors, the PDPC recommends more stringent measures. These include engaging Singapore PDPA vendors with DPTM or equivalent certification, detailed SOPs for reporting and operations, defined format and frequency for vendor reports, escalation processes and reporting chains for incidents, drawer plans for data breach management, formal onboarding processes, structured training plans, proactive monitoring by vendors, periodic audits and on-site inspections, and simulation exercises to test incident response. Building a practical Singapore PDPA vendor management programme requires translating these PDPC recommendations into actionable documents. The key templates and tools include: a vendor risk assessment questionnaire that evaluates the Singapore PDPA vendor's data protection framework, policies, and certifications; a data processing agreement based on the PDPC Guide on Data Protection Clauses; standard operating procedures covering data handling, reporting, and incident response; a vendor register tracking all Singapore PDPA vendors, their processing scope, contract dates, audit dates, and risk ratings; and an evidence pack structure that organises contracts, due diligence records, audit reports, training records, and incident logs. The PDPC also references the Government's Third-Party Management Framework, which applies to organisations working with public sector agencies. While this framework has additional requirements specific to government contracts, its four-stage approach (Evaluation and Selection, Contracting and Onboarding, Service Management, and Transition Out) closely mirrors the PDPC's DI Management Lifecycle and can serve as a useful benchmark for private sector organisations seeking to strengthen their Singapore PDPA vendor management practices. - Follow the four-stage PDPC DI Management Lifecycle for every Singapore PDPA vendor: Governance, Policies, Service Management, and Exit. - Create a vendor risk assessment questionnaire covering the Singapore PDPA vendor's data protection framework, policies, certifications, and track record. - Draft data processing agreements using the PDPC Guide on Data Protection Clauses as a starting template for each Singapore PDPA vendor. - Develop standard operating procedures for data handling, reporting, incident response, and breach notification across all Singapore PDPA vendor relationships. - Maintain a vendor register with all Singapore PDPA vendors, processing scope, data categories, contract dates, audit schedules, and risk ratings. - Build an evidence pack for each Singapore PDPA vendor: contracts, due diligence records, audit reports, training records, and incident logs. - Apply proportionate measures: higher-risk Singapore PDPA vendors require DPTM certification, periodic audits, and simulation exercises. - Review and update the Singapore PDPA vendor management framework at least annually or when significant changes occur in vendor arrangements. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep Singapore PDPA Vendor Outsourcing and Contracts in one governed evidence system SSOT can take Singapore PDPA Vendor Outsourcing and Contracts from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on Singapore PDPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for Singapore PDPA Vendor Outsourcing and Contracts](/solutions/ssot.md): Start from Singapore PDPA Vendor Outsourcing and Contracts and keep documents, evidence, and control records in one governed system. - [Talk through Singapore PDPA](/contact.md): Review your current process, evidence gaps, and next steps for Singapore PDPA Vendor Outsourcing and Contracts. ## Primary sources - [Personal Data Protection Act 2012 (Singapore) - official text](https://sso.agc.gov.sg/Act/PDPA2012?ref=sorena.io) - Primary legislation governing collection, use, disclosure, protection, retention, transfer, and accountability for personal data in Singapore. Section 4(3) establishes data controller responsibility for Singapore PDPA vendor processing. - [PDPC - Advisory Guidelines on Key Concepts in the PDPA (Revised 16 May 2022)](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-the-personal-data-protection-act?ref=sorena.io) - Chapter 6 provides authoritative clarifications on data intermediary definitions, obligations, and considerations for Singapore PDPA vendor arrangements including overseas transfers. - [PDPC - Guide to Managing Data Intermediaries](https://www.pdpc.gov.sg/help-and-resources/2020/09/guide-to-managing-data-intermediaries?ref=sorena.io) - Comprehensive guide covering the DI management lifecycle: governance and risk assessment, policies and practices, service management, and exit management for Singapore PDPA vendor relationships. - [PDPC - Guide on Data Protection Clauses for Agreements (updated 1 February 2021)](https://www.pdpc.gov.sg/help-and-resources/2017/10/guide-on-data-protection-clauses-for-agreements-relating-to-the-processing-of-personal-data?ref=sorena.io) - Sample data protection clauses for service agreements when engaging Singapore PDPA vendors, updated to reflect PDPA amendments. - [PDPC - Distinction between Organisations and Data Intermediaries](https://www.pdpc.gov.sg/the-distinction-between-organisations-and-data-intermediaries-and-why-it-matters?ref=sorena.io) - Explains the roles, obligations, and regulatory differences between data controllers and data intermediaries (Singapore PDPA vendors) under the PDPA. - [PDPC - Advisory Guidelines on Enforcement of Data Protection Provisions](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/02/advisory-guidelines-on-enforcement-of-data-protection-provisions?ref=sorena.io) - Enforcement approach, directions, financial penalties, and undertakings relevant to Singapore PDPA vendor compliance failures. - [PDPC - Guide to Data Protection by Design for ICT Systems](https://www.pdpc.gov.sg/help-and-resources/2019/05/guide-to-data-protection-by-design-for-ict-systems?ref=sorena.io) - Seven Data Protection by Design principles and more than 60 good practices for building privacy into software, systems, and websites used in Singapore PDPA vendor arrangements. - [PDPC - PDPA Overview](https://www.pdpc.gov.sg/overview-of-pdpa/pdpa-overview?ref=sorena.io) - Official PDPC overview of PDPA obligations, key concepts, and updates relevant to Singapore PDPA vendor outsourcing compliance. ## Related Topic Guides - [Singapore PDPA Applicability Test | Does the PDPA Apply to Your Organisation?](/artifacts/apac/singapore-pdpa/applicability-test.md): Complete Singapore PDPA applicability test with step-by-step framework to determine if the Personal Data Protection Act applies to your organisation. - [Singapore PDPA Breach Notification Playbook - Complete Guide](/artifacts/apac/singapore-pdpa/breach-notification-playbook.md): Singapore PDPA breach notification playbook with the 3-day PDPC reporting deadline. - [Singapore PDPA Compliance Checklist - Audit-Ready Guide (2026)](/artifacts/apac/singapore-pdpa/checklist.md): Complete Singapore PDPA compliance checklist covering DPMP governance, consent management, purpose limitation, data protection controls, retention schedules. - [Singapore PDPA Compliance Deadlines and Calendar](/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar.md): Complete Singapore PDPA compliance deadlines calendar: 3-day breach notification, 30-day access requests, correction timelines, consent withdrawal windows. - [Singapore PDPA Compliance Guide - Data Protection Management Programme, DPO, Consent, Protection, Retention, DPTM](/artifacts/apac/singapore-pdpa/compliance.md): Complete Singapore PDPA compliance guide for organisations. - [Singapore PDPA Consent and Notification Obligations Guide](/artifacts/apac/singapore-pdpa/consent-notification-and-purposes.md): Complete Singapore PDPA consent and notification guide covering express consent, deemed consent by conduct and notification, legitimate interests exception. - [Singapore PDPA Cross-Border Transfer Rules | Section 26 Data Transfer Compliance](/artifacts/apac/singapore-pdpa/cross-border-transfers.md): Complete guide to Singapore PDPA cross-border transfer compliance under Section 26. - [Singapore PDPA Do Not Call Registry and Marketing Messages Compliance Guide](/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages.md): Complete Singapore PDPA Do Not Call (DNC) Registry compliance guide for businesses. - [Singapore PDPA FAQ | Frequently Asked Questions on Personal Data Protection Act Compliance](/artifacts/apac/singapore-pdpa/faq.md): Singapore PDPA FAQ with detailed answers on scope, consent, deemed consent, legitimate interests, breach notification, DPO requirements. - [Singapore PDPA Penalties and Enforcement Cases - PDPC Fines and Decisions](/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases.md): Singapore PDPA penalties and enforcement cases: PDPC financial penalties up to SGD 1 million or 10% turnover. - [Singapore PDPA Penalties and Fines | SGD 1M or 10% Turnover Cap + PDPC Enforcement Guide](/artifacts/apac/singapore-pdpa/penalties-and-fines.md): Complete guide to Singapore PDPA penalties and fines: maximum financial penalties up to SGD 1 million or 10% annual turnover, PDPC enforcement directions. - [Singapore PDPA Privacy Policy Template - Clause-by-Clause Drafting Guide](/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template.md): Singapore PDPA privacy policy template with clause-by-clause drafting instructions for all 10 Data Protection Provisions. - [Singapore PDPA Requirements -- All Obligations Explained (Consent, Protection, Breach Notification, DNC)](/artifacts/apac/singapore-pdpa/requirements.md): Complete guide to Singapore PDPA requirements covering all Data Protection Provisions: consent obligation (Sections 13-17), purpose limitation (Section 18). - [Singapore PDPA Scope, Exclusions, and Data Intermediary Obligations](/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries.md): Complete guide to Singapore PDPA scope covering excluded organisations, the personal and domestic exception, business contact information exclusion. - [Singapore PDPA vs GDPR: Full Comparison of Scope, Consent, Penalties](/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr.md): Singapore PDPA vs GDPR comparison covering scope, consent models, deemed consent, breach notification, cross-border transfers, penalties, DPO requirements. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts --- --- title: "EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence" canonical_url: "https://www.sorena.io/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites" source_url: "https://www.sorena.io/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites" author: "Sorena AI" description: "Detailed EU Accessibility Act guide for e-commerce websites and apps." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU Accessibility Act e-commerce" - "e-commerce accessibility EU" - "European Accessibility Act e-commerce services" - "ecommerce website accessibility" - "ecommerce accessibility checklist" - "checkout accessibility" - "product page accessibility" - "mobile app accessibility ecommerce" - "EN 301 549 ecommerce" - "WCAG ecommerce" - "accessibility statement ecommerce" - "accessibility testing ecommerce" - "accessibility acceptance criteria ecommerce" - "consumer contract accessibility EU" - "EU Accessibility Act" - "e-commerce services" - "web accessibility" - "EN 301 549" - "WCAG" - "accessibility testing" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence Detailed EU Accessibility Act guide for e-commerce websites and apps. *Artifact Guide* *EU* ## EU Accessibility Act E-Commerce Websites Practical EU Accessibility Act guidance for e-commerce websites and apps, grounded in the fact that e-commerce services are in scope when consumers conclude contracts through digital channels. Focus first on search, product detail, basket, checkout, account, payment, and customer support journeys that make or break completion. Under Article 2 of Directive (EU) 2019/882, e-commerce services provided to consumers through websites and mobile device based services are in scope from 28 June 2025. In practice, that means teams cannot limit accessibility work to a marketing home page. The product listing flow, search, filters, product detail pages, basket, checkout, account creation, payment, order tracking, returns, and customer support contact paths all need to work for disabled users on equal terms. This page turns that scoping rule into a delivery plan that product, design, engineering, QA, and compliance teams can ship against. ## Why e-commerce websites are in scope under the EU Accessibility Act The directive defines e-commerce services as services provided at a distance, by electronic means, at the individual request of a consumer, with a view to concluding a consumer contract. If your website or app enables a consumer to compare offers, configure a purchase, enter account details, pay, or manage an order, you are in the centre of scope rather than at the edge of scope. Teams often miss adjacent user journeys that still affect the ability to conclude or manage a consumer contract. Support content, account recovery, authentication, delivery updates, returns, cancellation, and invoices can all become accessibility blockers even if the core checkout form passes a basic automated scan. - Treat the full conversion journey as in scope: search, filters, product details, basket, checkout, payment, account, order history, returns, and support. - Include mobile apps, embedded web views, PDFs, and service emails where they are part of the consumer transaction path. - Check accessibility of authentication, CAPTCHA alternatives, payment confirmation, and error recovery paths, not only the happy path. - If third party widgets are used for payment, chat, reviews, identity checks, or consent banners, put those vendors into your accessibility evidence scope. ## Implementation priorities for e-commerce teams For most e-commerce teams, the fastest path is to fix shared components before page specific issues. Buttons, inputs, dialogs, autocomplete controls, banners, tables, accordions, and focus management patterns affect dozens of templates at once. Once those are stable, move to transaction critical pages and then to content scale issues such as media, downloadable documents, and help content. EN 301 549 gives you a way to turn legal outcomes into engineering work. For web and app journeys, map applicable EN 301 549 clauses and WCAG success criteria to each user flow, then link those requirements to component level acceptance criteria, test cases, defect logs, and release sign off. - Build a journey register that lists every consumer contract step and the components that support it. - Prioritise keyboard operation, focus visibility, labels, instructions, error messaging, contrast, resize behaviour, and alternatives for non text content and time based media. - Add manual testing with keyboard, screen reader, zoom, and mobile assistive technologies for basket, checkout, and payment journeys in every release cycle. - Publish an accessibility statement or equivalent service level disclosure that explains scope, known limitations, contact routes, and review date. - Retain evidence for each release: test dates, tools, environments, defects found, fixes shipped, retests, and ownership. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU Accessibility Act E-Commerce Websites as a cited research workflow Research Copilot can take EU Accessibility Act E-Commerce Websites from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU Accessibility Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Accessibility Act E-Commerce Websites](/solutions/research-copilot.md): Start from EU Accessibility Act E-Commerce Websites and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Accessibility Act](/contact.md): Review your current process, evidence gaps, and next steps for EU Accessibility Act E-Commerce Websites. ## Primary sources - [European Accessibility Act (Directive (EU) 2019/882) - official text](https://eur-lex.europa.eu/eli/dir/2019/882/oj?ref=sorena.io) - Primary legal text for scope, Annex I requirements, Article 14 exceptions, Annex IV technical documentation, and market surveillance measures. - [European Commission - European Accessibility Act policy page](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en?ref=sorena.io) - Official implementation overview and policy context for the Act and its entry into application on 28 June 2025. - [AccessibleEU - Guidance on accessibility legislation in Europe](https://accessible-eu-centre.ec.europa.eu/guidelines-and-support-materials?ref=sorena.io) - Implementation guidance summarising covered products and services, practical obligations, and standard references for teams building compliance programmes. - [ETSI - EN 301 549 overview](https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility?ref=sorena.io) - Official ETSI overview of EN 301 549, the European accessibility standard used to operationalise ICT requirements across web, software, hardware, documents, and communications. - [Commission Notice - Blue Guide on EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A52022XC0629%2804%29&ref=sorena.io) - Primary EU guidance on manufacturer, importer, distributor, declaration of conformity, CE marking, and market surveillance concepts. - [European Commission - Daily News on EAA application in June 2025](https://ec.europa.eu/commission/presscorner/detail/en/mex_25_1650?ref=sorena.io) - Official Commission notice confirming the entry into application on 28 June 2025. ## Related Topic Guides - [EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use](/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping.md): Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way. - [EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence](/artifacts/eu/accessibility-act/accessibility-conformance-statement-template.md): Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method. - [EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs](/artifacts/eu/accessibility-act/applicability-test.md): Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter. - [EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence](/artifacts/eu/accessibility-act/checklist.md): Audit ready EU Accessibility Act compliance checklist for products and services. - [EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence](/artifacts/eu/accessibility-act/compliance.md): Build an EU Accessibility Act compliance programme with this practical playbook. - [EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates](/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar.md): Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025. - [EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly](/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden.md): Understand EU Accessibility Act exceptions correctly. - [EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions](/artifacts/eu/accessibility-act/faq.md): Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549. - [EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk](/artifacts/eu/accessibility-act/penalties-and-fines.md): Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products. - [EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce](/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria.md): Draft procurement ready accessibility language under the EU Accessibility Act. - [EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact](/artifacts/eu/accessibility-act/products-and-services-in-scope.md): Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications. - [EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations](/artifacts/eu/accessibility-act/requirements.md): Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation. - [EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep](/artifacts/eu/accessibility-act/testing-and-conformance-evidence.md): Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements. - [EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness](/artifacts/eu/accessibility-act/deadlines-and-transition-plan.md): Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates. - [EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences](/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508.md): Compare the EU Accessibility Act with the ADA and Section 508 in practical terms. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites --- --- title: "EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences" canonical_url: "https://www.sorena.io/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508" source_url: "https://www.sorena.io/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508" author: "Sorena AI" description: "Compare the EU Accessibility Act with the ADA and Section 508 in practical terms." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU Accessibility Act vs ADA" - "EU Accessibility Act vs Section 508" - "EAA ADA comparison" - "EAA Section 508 comparison" - "EN 301 549 vs WCAG" - "accessibility procurement EU" - "accessibility compliance comparison" - "accessibility conformance evidence" - "accessibility statement comparison" - "market surveillance accessibility" - "EU Accessibility Act" - "ADA" - "Section 508" - "accessibility procurement" - "EN 301 549" - "WCAG" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences Compare the EU Accessibility Act with the ADA and Section 508 in practical terms. *Artifact Guide* *EU* ## EU Accessibility Act vs ADA and Section 508 A practical comparison of the EU Accessibility Act, the ADA, and Section 508 so multinational teams can reuse accessibility work without collapsing different legal triggers into one checklist. The common mistake is to assume WCAG coverage alone answers every product, procurement, and evidence question. It does not. Teams that work across the EU and the United States usually want one accessibility operating model. That is sensible, but the legal triggers are different. The EU Accessibility Act is a market access regime for defined products and consumer services in the EU single market. Section 508 is a US federal procurement rule. The ADA is a civil rights framework that often shapes digital accessibility expectations through enforcement and litigation. The practical answer is to reuse testing and remediation work where possible, while keeping separate scoping and evidence layers for each framework. ## Where the frameworks overlap and where they do not All three frameworks reward the same basic engineering discipline: semantic structure, keyboard support, perceivable media, clear labels and instructions, robust forms, and documented testing. That is why WCAG based testing often remains a shared execution layer across jurisdictions. The divergence appears at the legal edge. The EU Accessibility Act names covered product and service categories, creates manufacturer and importer duties for products, uses conformity style documentation for products, and gives market surveillance authorities power to require corrective action or restrict products. Section 508 is driven by procurement relationships, and ADA exposure is usually framed around equal access and discrimination risk rather than CE style documentation. - Reuse design system fixes, test scripts, and defect taxonomy across all frameworks. - Keep separate scoping memos for EAA market scope, Section 508 procurement scope, and ADA service exposure. - Do not assume a US VPAT or a generic WCAG report is enough for an EAA product evidence pack. - For products in EAA scope, include operator role, technical documentation, declaration of conformity status, and any Article 14 assessment. ## How to build one delivery model without losing legal precision A workable multinational model has three layers. First, one shared engineering baseline for components, user journeys, and assistive technology testing. Second, a jurisdiction layer for scope, timelines, and evidence artefacts. Third, a governance layer that decides what gets published externally and what gets retained for procurement, customer diligence, or regulatory review. For EU work, add explicit records for in-scope categories, EN 301 549 use, product versus service obligations, and transitional decisions. For US work, keep procurement artefacts and customer facing statements aligned to the relevant contract or litigation risk. This preserves reuse while avoiding false equivalence. - Create one requirement library that maps shared accessibility outcomes to WCAG and, where relevant, EN 301 549 clauses. - Use jurisdiction specific templates for statements, procurement responses, and audit packages. - Track exceptions separately. Article 14 disproportionate burden is not the same thing as a US business hardship argument. - Review published claims carefully so marketing language does not overstate coverage across regions. *Recommended next step* *Placement: after the comparison section* ## Use EU Accessibility Act vs ADA and Section 508 as a cited research workflow Research Copilot can take EU Accessibility Act vs ADA and Section 508 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Accessibility Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Accessibility Act vs ADA and Section 508](/solutions/research-copilot.md): Start from EU Accessibility Act vs ADA and Section 508 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Accessibility Act](/contact.md): Review your current process, evidence gaps, and next steps for EU Accessibility Act vs ADA and Section 508. ## Primary sources - [European Accessibility Act (Directive (EU) 2019/882) - official text](https://eur-lex.europa.eu/eli/dir/2019/882/oj?ref=sorena.io) - Primary legal text for scope, Annex I requirements, Article 14 exceptions, Annex IV technical documentation, and market surveillance measures. - [European Commission - European Accessibility Act policy page](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en?ref=sorena.io) - Official implementation overview and policy context for the Act and its entry into application on 28 June 2025. - [AccessibleEU - Guidance on accessibility legislation in Europe](https://accessible-eu-centre.ec.europa.eu/guidelines-and-support-materials?ref=sorena.io) - Implementation guidance summarising covered products and services, practical obligations, and standard references for teams building compliance programmes. - [ETSI - EN 301 549 overview](https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility?ref=sorena.io) - Official ETSI overview of EN 301 549, the European accessibility standard used to operationalise ICT requirements across web, software, hardware, documents, and communications. - [Commission Notice - Blue Guide on EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A52022XC0629%2804%29&ref=sorena.io) - Primary EU guidance on manufacturer, importer, distributor, declaration of conformity, CE marking, and market surveillance concepts. - [European Commission - Daily News on EAA application in June 2025](https://ec.europa.eu/commission/presscorner/detail/en/mex_25_1650?ref=sorena.io) - Official Commission notice confirming the entry into application on 28 June 2025. ## Related Topic Guides - [EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use](/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping.md): Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way. - [EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence](/artifacts/eu/accessibility-act/accessibility-conformance-statement-template.md): Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method. - [EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs](/artifacts/eu/accessibility-act/applicability-test.md): Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter. - [EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence](/artifacts/eu/accessibility-act/checklist.md): Audit ready EU Accessibility Act compliance checklist for products and services. - [EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence](/artifacts/eu/accessibility-act/compliance.md): Build an EU Accessibility Act compliance programme with this practical playbook. - [EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates](/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar.md): Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025. - [EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly](/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden.md): Understand EU Accessibility Act exceptions correctly. - [EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions](/artifacts/eu/accessibility-act/faq.md): Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549. - [EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence](/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites.md): Detailed EU Accessibility Act guide for e-commerce websites and apps. - [EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk](/artifacts/eu/accessibility-act/penalties-and-fines.md): Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products. - [EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce](/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria.md): Draft procurement ready accessibility language under the EU Accessibility Act. - [EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact](/artifacts/eu/accessibility-act/products-and-services-in-scope.md): Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications. - [EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations](/artifacts/eu/accessibility-act/requirements.md): Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation. - [EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep](/artifacts/eu/accessibility-act/testing-and-conformance-evidence.md): Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements. - [EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness](/artifacts/eu/accessibility-act/deadlines-and-transition-plan.md): Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508 --- --- title: "EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence" canonical_url: "https://www.sorena.io/artifacts/eu/accessibility-act/accessibility-conformance-statement-template" source_url: "https://www.sorena.io/artifacts/eu/accessibility-act/accessibility-conformance-statement-template" author: "Sorena AI" description: "Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU Accessibility Act statement template" - "accessibility conformance statement template" - "EAA accessibility statement" - "EN 301 549 statement" - "accessibility evidence template" - "Article 14 statement" - "market surveillance evidence" - "procurement accessibility statement" - "EU Accessibility Act" - "accessibility conformance statement" - "EN 301 549" - "accessibility evidence" - "market surveillance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method. *Artifact Guide* *EU* ## EU Accessibility Act Conformance Statement Template A practical accessibility conformance statement template for EU Accessibility Act teams that need a document procurement, sales, and compliance teams can actually use. The statement should identify scope, standards, evidence, exceptions, and update ownership. It should never read like empty marketing copy. The directive does not require one universal public statement format for every offering, but teams still need a consistent way to describe what is covered, how accessibility was assessed, what remains open, and who owns updates. For products, the formal Annex IV documentation and EU declaration of conformity are central. For services, customers and procurement teams still expect a clear conformance statement or accessibility disclosure. This template gives you a structure that stays useful across audits, customer due diligence, and internal release control. ## Core fields every accessibility conformance statement should contain Start with identification. Name the product or service, version or release, channels covered, and the legal entity responsible. Then state the exact scope. A statement that says a company is accessible in general is not useful. A statement that says the consumer banking web app and iOS app release 4.8 were assessed against defined requirements is useful. Next, explain the technical basis. Identify the standards or requirements used, such as applicable Annex I outcomes and EN 301 549 clauses. If only part of a standard was applied, say that directly. If Article 14 was relied on for a specific requirement, identify which requirement and summarise the documented rationale. - Product or service name, version, channels, countries, and responsible legal entity. - In-scope features and out-of-scope features with reasons. - Requirements and standards used, including EN 301 549 and any WCAG mapping where relevant. - Test methodology: dates, environments, assistive technologies, sample pages or journeys, and known limitations. - Summary of findings, remediation status, and open issues with target dates. - Contact route, owner, approval date, and next review date. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Accessibility Act Conformance Statement Template in one governed evidence system SSOT can take EU Accessibility Act Conformance Statement Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Accessibility Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Accessibility Act Conformance Statement Template](/solutions/ssot.md): Start from EU Accessibility Act Conformance Statement Template and keep documents, evidence, and control records in one governed system. - [Talk through EU Accessibility Act](/contact.md): Review your current process, evidence gaps, and next steps for EU Accessibility Act Conformance Statement Template. ## How to keep the statement defensible Treat the statement as the front page of an evidence pack, not as the evidence pack itself. Each claim should link back to a test record, design decision, remediation ticket, procurement response, or operator assessment. If the statement says voice interaction has a non voice alternative, you should be able to point to the tested feature and the result. For products, align the public or customer facing statement with Annex IV technical documentation and the EU declaration of conformity so that different teams are not publishing conflicting compliance claims. For services, align the statement with internal release gates and customer support procedures so that known issues and workarounds are not hidden. - Update the statement on every material release or scope change. - Keep older versions archived so you can answer questions about what was true at a specific point in time. - Record who approved the statement and which evidence bundle supported the approval. - Do not claim full conformance if exceptions, partial scope, or unresolved critical defects still exist. ## Primary sources - [European Accessibility Act (Directive (EU) 2019/882) - official text](https://eur-lex.europa.eu/eli/dir/2019/882/oj?ref=sorena.io) - Primary legal text for scope, Annex I requirements, Article 14 exceptions, Annex IV technical documentation, and market surveillance measures. - [European Commission - European Accessibility Act policy page](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en?ref=sorena.io) - Official implementation overview and policy context for the Act and its entry into application on 28 June 2025. - [AccessibleEU - Guidance on accessibility legislation in Europe](https://accessible-eu-centre.ec.europa.eu/guidelines-and-support-materials?ref=sorena.io) - Implementation guidance summarising covered products and services, practical obligations, and standard references for teams building compliance programmes. - [ETSI - EN 301 549 overview](https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility?ref=sorena.io) - Official ETSI overview of EN 301 549, the European accessibility standard used to operationalise ICT requirements across web, software, hardware, documents, and communications. - [Commission Notice - Blue Guide on EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A52022XC0629%2804%29&ref=sorena.io) - Primary EU guidance on manufacturer, importer, distributor, declaration of conformity, CE marking, and market surveillance concepts. - [European Commission - Daily News on EAA application in June 2025](https://ec.europa.eu/commission/presscorner/detail/en/mex_25_1650?ref=sorena.io) - Official Commission notice confirming the entry into application on 28 June 2025. ## Related Topic Guides - [EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use](/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping.md): Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way. - [EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs](/artifacts/eu/accessibility-act/applicability-test.md): Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter. - [EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence](/artifacts/eu/accessibility-act/checklist.md): Audit ready EU Accessibility Act compliance checklist for products and services. - [EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence](/artifacts/eu/accessibility-act/compliance.md): Build an EU Accessibility Act compliance programme with this practical playbook. - [EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates](/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar.md): Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025. - [EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly](/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden.md): Understand EU Accessibility Act exceptions correctly. - [EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions](/artifacts/eu/accessibility-act/faq.md): Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549. - [EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence](/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites.md): Detailed EU Accessibility Act guide for e-commerce websites and apps. - [EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk](/artifacts/eu/accessibility-act/penalties-and-fines.md): Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products. - [EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce](/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria.md): Draft procurement ready accessibility language under the EU Accessibility Act. - [EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact](/artifacts/eu/accessibility-act/products-and-services-in-scope.md): Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications. - [EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations](/artifacts/eu/accessibility-act/requirements.md): Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation. - [EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep](/artifacts/eu/accessibility-act/testing-and-conformance-evidence.md): Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements. - [EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness](/artifacts/eu/accessibility-act/deadlines-and-transition-plan.md): Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates. - [EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences](/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508.md): Compare the EU Accessibility Act with the ADA and Section 508 in practical terms. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/accessibility-act/accessibility-conformance-statement-template --- --- title: "EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs" canonical_url: "https://www.sorena.io/artifacts/eu/accessibility-act/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/accessibility-act/applicability-test" author: "Sorena AI" description: "Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU Accessibility Act applicability test" - "EAA scope test" - "European Accessibility Act scope" - "manufacturer importer distributor service provider" - "Article 2 EAA" - "Article 14 EAA" - "microenterprise EAA" - "EAA scope register" - "EAA service scope" - "EAA product scope" - "EU Accessibility Act" - "applicability test" - "scope" - "manufacturer" - "service provider" - "Article 14" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter. *Artifact Guide* *EU* ## EU Accessibility Act Applicability Test A grounded EU Accessibility Act applicability test for deciding product and service scope, economic operator role, transition treatment, and evidence outputs. Use it to reach one of three answers: in scope, out of scope, or in scope with limited requirements and documented exceptions. The fastest way to waste time on the EU Accessibility Act is to start remediating without a scoping memo. The directive only applies to named products placed on the market after 28 June 2025 and named services provided to consumers after 28 June 2025, subject to specific exclusions and transitional rules. This applicability test turns Article 2, Article 14, and the transition provisions into a repeatable sequence that product, legal, accessibility, and commercial teams can reuse. ## Step by step applicability test Start with category, not with technology. Ask whether the offering is one of the listed products or services. Covered products include consumer general purpose computer hardware and operating systems, specified self service terminals, consumer terminal equipment used for electronic communications services, consumer terminal equipment used for audiovisual media services, and e-readers. Covered services include electronic communications services, services providing access to audiovisual media services, defined elements of passenger transport services, consumer banking services, and e-commerce services. Then identify role. A manufacturer, importer, distributor, and service provider do not carry the same obligations or evidence burden. Product roles trigger technical documentation, conformity assessment, EU declaration of conformity, and CE related workflows. Service providers need operating controls, accessible information, and a defensible service evidence pack. - Confirm whether the offering is placed on the market or provided to consumers after 28 June 2025. - Check exclusions for pre recorded media published before 28 June 2025, office files published before that date, and archived web or app content not updated after that date. - Identify every user facing interface that affects use of the product or service: hardware UI, software, web, mobile, documentation, support, packaging, and installation information. - Test whether a transition rule applies for pre existing service contracts or self service terminals already lawfully in use. - If an exception is considered, decide whether it is a microenterprise rule or an Article 14 assessment, and record the supporting facts. *Recommended next step* *Placement: after the applicability result* ## Turn EU Accessibility Act Applicability Test into an operational assessment Assessment Autopilot can take EU Accessibility Act Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU Accessibility Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Accessibility Act Applicability Test](/solutions/assessment.md): Start from EU Accessibility Act Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Accessibility Act](/contact.md): Review your current process, evidence gaps, and next steps for EU Accessibility Act Applicability Test. ## Deliverable: scope register and decision memo The output should be more than a yes or no answer. Build a scope register that names each offering, the exact in-scope category, role, channels, applicable requirements set, evidence owner, and next review trigger. This stops teams from re-debating scope every quarter. Attach a short decision memo that records what was considered, what was excluded, what transitional allowance was used if any, and which documents prove the conclusion. That memo becomes the anchor for procurement responses, release gating, and market surveillance readiness. - Store one row per offering with category, role, country coverage, channels, and evidence owner. - List exclusions and transitional rules with article references and review dates. - Record whether the offering relies on harmonised standards, internal specifications, or both. - Re-run the test when scope changes, new channels launch, or a third party dependency becomes user facing. ## Primary sources - [European Accessibility Act (Directive (EU) 2019/882) - official text](https://eur-lex.europa.eu/eli/dir/2019/882/oj?ref=sorena.io) - Primary legal text for scope, Annex I requirements, Article 14 exceptions, Annex IV technical documentation, and market surveillance measures. - [European Commission - European Accessibility Act policy page](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en?ref=sorena.io) - Official implementation overview and policy context for the Act and its entry into application on 28 June 2025. - [AccessibleEU - Guidance on accessibility legislation in Europe](https://accessible-eu-centre.ec.europa.eu/guidelines-and-support-materials?ref=sorena.io) - Implementation guidance summarising covered products and services, practical obligations, and standard references for teams building compliance programmes. - [ETSI - EN 301 549 overview](https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility?ref=sorena.io) - Official ETSI overview of EN 301 549, the European accessibility standard used to operationalise ICT requirements across web, software, hardware, documents, and communications. - [Commission Notice - Blue Guide on EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A52022XC0629%2804%29&ref=sorena.io) - Primary EU guidance on manufacturer, importer, distributor, declaration of conformity, CE marking, and market surveillance concepts. - [European Commission - Daily News on EAA application in June 2025](https://ec.europa.eu/commission/presscorner/detail/en/mex_25_1650?ref=sorena.io) - Official Commission notice confirming the entry into application on 28 June 2025. ## Related Topic Guides - [EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use](/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping.md): Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way. - [EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence](/artifacts/eu/accessibility-act/accessibility-conformance-statement-template.md): Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method. - [EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence](/artifacts/eu/accessibility-act/checklist.md): Audit ready EU Accessibility Act compliance checklist for products and services. - [EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence](/artifacts/eu/accessibility-act/compliance.md): Build an EU Accessibility Act compliance programme with this practical playbook. - [EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates](/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar.md): Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025. - [EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly](/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden.md): Understand EU Accessibility Act exceptions correctly. - [EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions](/artifacts/eu/accessibility-act/faq.md): Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549. - [EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence](/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites.md): Detailed EU Accessibility Act guide for e-commerce websites and apps. - [EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk](/artifacts/eu/accessibility-act/penalties-and-fines.md): Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products. - [EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce](/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria.md): Draft procurement ready accessibility language under the EU Accessibility Act. - [EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact](/artifacts/eu/accessibility-act/products-and-services-in-scope.md): Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications. - [EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations](/artifacts/eu/accessibility-act/requirements.md): Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation. - [EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep](/artifacts/eu/accessibility-act/testing-and-conformance-evidence.md): Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements. - [EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness](/artifacts/eu/accessibility-act/deadlines-and-transition-plan.md): Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates. - [EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences](/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508.md): Compare the EU Accessibility Act with the ADA and Section 508 in practical terms. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/accessibility-act/applicability-test --- --- title: "EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence" canonical_url: "https://www.sorena.io/artifacts/eu/accessibility-act/checklist" source_url: "https://www.sorena.io/artifacts/eu/accessibility-act/checklist" author: "Sorena AI" description: "Audit ready EU Accessibility Act compliance checklist for products and services." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU Accessibility Act checklist" - "EAA checklist" - "European Accessibility Act compliance checklist" - "Annex I accessibility checklist" - "EN 301 549 checklist" - "accessibility evidence checklist" - "Article 14 checklist" - "procurement accessibility checklist" - "market surveillance checklist" - "EAA service checklist" - "EAA product checklist" - "EU Accessibility Act" - "compliance checklist" - "Annex I" - "EN 301 549" - "technical documentation" - "procurement" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence Audit ready EU Accessibility Act compliance checklist for products and services. *Artifact Guide* *EU* ## EU Accessibility Act Compliance Checklist An audit ready EU Accessibility Act checklist that converts legal scope and accessibility outcomes into owned work items, evidence, and release gates. Use one version for delivery teams and one filtered view for procurement and regulatory response. A useful EU Accessibility Act checklist is not a list of abstract principles. It is a working control sheet tied to exact offerings, operator roles, interfaces, standards, tests, documents, and sign off owners. This checklist is organised so teams can use it as a release gate, an internal audit script, and a procurement evidence index without duplicating effort. ## Scope and governance checklist Before any remediation work starts, confirm what is in scope and who owns it. Many accessibility programmes fail because engineering assumes legal has done the scoping and legal assumes product has done it. The checklist needs named owners for each layer. For products, document the manufacturer, importer, distributor, or authorised representative role and the expected conformity documents. For services, identify the service owner, accessibility lead, and operational support owner. - Scope register approved for each product or service in Article 2 scope. - Operator roles assigned with named owners and escalation routes. - Channels and interfaces listed, including packaging, installation information, customer support, websites, apps, and interactive terminals where relevant. - Transition rules and exclusions checked and recorded. - Review cadence defined for releases, new countries, and material UX changes. *Recommended next step* *Placement: after the checklist block* ## Turn EU Accessibility Act Compliance Checklist into an operational assessment Assessment Autopilot can take EU Accessibility Act Compliance Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Accessibility Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Accessibility Act Compliance Checklist](/solutions/assessment.md): Start from EU Accessibility Act Compliance Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Accessibility Act](/contact.md): Review your current process, evidence gaps, and next steps for EU Accessibility Act Compliance Checklist. ## Requirements, testing, and evidence checklist Once scope is fixed, map the applicable Annex I outcomes to measurable acceptance criteria. For ICT heavy offerings, EN 301 549 is the most practical bridge between the directive and engineering work. Every mapped requirement should have a test method and an evidence owner. Close the loop by linking findings to remediation, retesting, and release approval. A green audit result without traceable evidence does not help when procurement teams or authorities ask what changed and when. - Annex I outcomes mapped to applicable EN 301 549 clauses and test cases. - Manual and automated testing completed with environment details and assistive technology coverage. - Defects classified, remediated, retested, and linked to release notes. - Technical documentation prepared for products and service evidence pack prepared for services. - Conformance statement or declaration workflow defined and reviewed by the right owner. - Article 14 assessments, if any, documented and retained for the required period. - Procurement response pack prepared with measurable acceptance criteria and evidence links. ## Primary sources - [European Accessibility Act (Directive (EU) 2019/882) - official text](https://eur-lex.europa.eu/eli/dir/2019/882/oj?ref=sorena.io) - Primary legal text for scope, Annex I requirements, Article 14 exceptions, Annex IV technical documentation, and market surveillance measures. - [European Commission - European Accessibility Act policy page](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en?ref=sorena.io) - Official implementation overview and policy context for the Act and its entry into application on 28 June 2025. - [AccessibleEU - Guidance on accessibility legislation in Europe](https://accessible-eu-centre.ec.europa.eu/guidelines-and-support-materials?ref=sorena.io) - Implementation guidance summarising covered products and services, practical obligations, and standard references for teams building compliance programmes. - [ETSI - EN 301 549 overview](https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility?ref=sorena.io) - Official ETSI overview of EN 301 549, the European accessibility standard used to operationalise ICT requirements across web, software, hardware, documents, and communications. - [Commission Notice - Blue Guide on EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A52022XC0629%2804%29&ref=sorena.io) - Primary EU guidance on manufacturer, importer, distributor, declaration of conformity, CE marking, and market surveillance concepts. - [European Commission - Daily News on EAA application in June 2025](https://ec.europa.eu/commission/presscorner/detail/en/mex_25_1650?ref=sorena.io) - Official Commission notice confirming the entry into application on 28 June 2025. ## Related Topic Guides - [EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use](/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping.md): Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way. - [EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence](/artifacts/eu/accessibility-act/accessibility-conformance-statement-template.md): Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method. - [EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs](/artifacts/eu/accessibility-act/applicability-test.md): Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter. - [EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence](/artifacts/eu/accessibility-act/compliance.md): Build an EU Accessibility Act compliance programme with this practical playbook. - [EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates](/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar.md): Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025. - [EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly](/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden.md): Understand EU Accessibility Act exceptions correctly. - [EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions](/artifacts/eu/accessibility-act/faq.md): Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549. - [EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence](/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites.md): Detailed EU Accessibility Act guide for e-commerce websites and apps. - [EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk](/artifacts/eu/accessibility-act/penalties-and-fines.md): Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products. - [EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce](/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria.md): Draft procurement ready accessibility language under the EU Accessibility Act. - [EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact](/artifacts/eu/accessibility-act/products-and-services-in-scope.md): Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications. - [EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations](/artifacts/eu/accessibility-act/requirements.md): Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation. - [EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep](/artifacts/eu/accessibility-act/testing-and-conformance-evidence.md): Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements. - [EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness](/artifacts/eu/accessibility-act/deadlines-and-transition-plan.md): Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates. - [EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences](/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508.md): Compare the EU Accessibility Act with the ADA and Section 508 in practical terms. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/accessibility-act/checklist --- --- title: "EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence" canonical_url: "https://www.sorena.io/artifacts/eu/accessibility-act/compliance" source_url: "https://www.sorena.io/artifacts/eu/accessibility-act/compliance" author: "Sorena AI" description: "Build an EU Accessibility Act compliance programme with this practical playbook." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU Accessibility Act compliance playbook" - "EAA compliance guide" - "European Accessibility Act compliance programme" - "accessibility operating model" - "market surveillance readiness" - "accessibility evidence pack" - "EN 301 549 implementation" - "accessibility governance" - "accessibility release gates" - "EU Accessibility Act" - "compliance playbook" - "operating model" - "market surveillance" - "EN 301 549" - "evidence pack" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence Build an EU Accessibility Act compliance programme with this practical playbook. *Artifact Guide* *EU* ## EU Accessibility Act Compliance Playbook A grounded compliance playbook for turning the EU Accessibility Act into operating controls, delivery standards, and evidence that survives procurement and regulatory review. The objective is repeatable accessibility delivery, not a one time remediation sprint. The EU Accessibility Act should be run as an operating model that connects legal scope, design standards, engineering execution, QA evidence, procurement response, and customer support. The directive is broad enough that isolated accessibility audits are not enough. Teams need a programme that survives release pressure, vendor changes, new channels, and authority questions. ## Build the accessibility operating model around role and scope Start with an inventory of in-scope offerings and the role the business plays for each. Product obligations and service obligations overlap, but they are not identical. A product workflow needs technical documentation, conformity assessment, declaration management, and traceability through the supply chain. A service workflow needs accessible service information, supportable user journeys, and operational controls for changes over time. Then set governance. Accessibility should sit inside release management, design system ownership, procurement review, and incident style escalation when a critical barrier is discovered after launch. - Create one owner for scope, one owner for testing standards, and one owner for evidence retention. - Bake accessibility checks into design review, sprint definition of done, and release approval. - Set vendor review rules for components or services that expose user facing barriers. - Keep support and complaint routes aligned with published accessibility statements and known issues. ## Control set for delivery, evidence, and response Your baseline control set should include requirements mapping, test planning, defect triage, remediation verification, published or customer facing conformance information, and evidence retention. For products, also include technical documentation under Annex IV and the related declaration process. For services, include content governance, support process, and service change reviews. Finally, prepare for challenge. Procurement teams may ask for measurable acceptance criteria. Customers may ask what standards were used. Authorities may ask for Article 14 assessments, technical documentation, or corrective action records. A compliance playbook is complete only when those requests can be answered quickly. - Maintain a traceability matrix from requirement to test to evidence artifact. - Retain dated test reports, issue logs, and approvals by release. - Run recurring regression tests on critical journeys and high reuse components. - Define a corrective action workflow for newly discovered barriers with clear severity thresholds. - Review statements, declarations, and procurement claims before publication or submission. *Recommended next step* *Placement: after the compliance steps* ## Turn EU Accessibility Act Compliance Playbook into an operational assessment Assessment Autopilot can take EU Accessibility Act Compliance Playbook from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Accessibility Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Accessibility Act Compliance Playbook](/solutions/assessment.md): Start from EU Accessibility Act Compliance Playbook and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Accessibility Act](/contact.md): Review your current process, evidence gaps, and next steps for EU Accessibility Act Compliance Playbook. ## Primary sources - [European Accessibility Act (Directive (EU) 2019/882) - official text](https://eur-lex.europa.eu/eli/dir/2019/882/oj?ref=sorena.io) - Primary legal text for scope, Annex I requirements, Article 14 exceptions, Annex IV technical documentation, and market surveillance measures. - [European Commission - European Accessibility Act policy page](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en?ref=sorena.io) - Official implementation overview and policy context for the Act and its entry into application on 28 June 2025. - [AccessibleEU - Guidance on accessibility legislation in Europe](https://accessible-eu-centre.ec.europa.eu/guidelines-and-support-materials?ref=sorena.io) - Implementation guidance summarising covered products and services, practical obligations, and standard references for teams building compliance programmes. - [ETSI - EN 301 549 overview](https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility?ref=sorena.io) - Official ETSI overview of EN 301 549, the European accessibility standard used to operationalise ICT requirements across web, software, hardware, documents, and communications. - [Commission Notice - Blue Guide on EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A52022XC0629%2804%29&ref=sorena.io) - Primary EU guidance on manufacturer, importer, distributor, declaration of conformity, CE marking, and market surveillance concepts. - [European Commission - Daily News on EAA application in June 2025](https://ec.europa.eu/commission/presscorner/detail/en/mex_25_1650?ref=sorena.io) - Official Commission notice confirming the entry into application on 28 June 2025. ## Related Topic Guides - [EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use](/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping.md): Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way. - [EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence](/artifacts/eu/accessibility-act/accessibility-conformance-statement-template.md): Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method. - [EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs](/artifacts/eu/accessibility-act/applicability-test.md): Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter. - [EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence](/artifacts/eu/accessibility-act/checklist.md): Audit ready EU Accessibility Act compliance checklist for products and services. - [EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates](/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar.md): Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025. - [EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly](/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden.md): Understand EU Accessibility Act exceptions correctly. - [EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions](/artifacts/eu/accessibility-act/faq.md): Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549. - [EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence](/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites.md): Detailed EU Accessibility Act guide for e-commerce websites and apps. - [EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk](/artifacts/eu/accessibility-act/penalties-and-fines.md): Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products. - [EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce](/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria.md): Draft procurement ready accessibility language under the EU Accessibility Act. - [EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact](/artifacts/eu/accessibility-act/products-and-services-in-scope.md): Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications. - [EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations](/artifacts/eu/accessibility-act/requirements.md): Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation. - [EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep](/artifacts/eu/accessibility-act/testing-and-conformance-evidence.md): Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements. - [EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness](/artifacts/eu/accessibility-act/deadlines-and-transition-plan.md): Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates. - [EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences](/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508.md): Compare the EU Accessibility Act with the ADA and Section 508 in practical terms. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/accessibility-act/compliance --- --- title: "EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates" canonical_url: "https://www.sorena.io/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU Accessibility Act deadlines" - "EAA calendar" - "28 June 2025 accessibility" - "28 June 2022 transposition" - "self service terminal transition" - "service contract transition EAA" - "accessibility review calendar" - "Article 14 review" - "accessibility evidence retention" - "EU Accessibility Act" - "deadlines" - "compliance calendar" - "transition" - "self-service terminals" - "service contracts" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025. *Artifact Guide* *EU* ## EU Accessibility Act Deadlines and Compliance Calendar The EU Accessibility Act dates that matter for launch planning, transition decisions, evidence retention, and recurring compliance review. Teams usually remember 28 June 2025. They often miss the transition logic and the dates needed to govern evidence after launch. A useful EU Accessibility Act calendar has both statutory dates and operating dates. The statutory dates tell you when the directive had to be transposed and when it applied. The operating dates tell you when to refresh scope, review exceptions, re-run tests, and update statements or technical documentation. This page puts those dates into one planning view. ## Statutory dates and transition windows Member States had to adopt and publish transposition measures by 28 June 2022 and apply those measures from 28 June 2025. That 2025 date is the key market date for products placed on the market and services provided to consumers within scope. The directive also contains two important transition rules. Service contracts agreed before 28 June 2025 may continue without alteration until they expire, but not for more than five years from that date. Self service terminals lawfully used before 28 June 2025 may continue until the end of their economically useful life, but not for more than 20 years after entry into use if a Member State allows that path. - 28 June 2022: transposition deadline for Member States. - 28 June 2025: application date for covered products and services. - Up to 28 June 2030: outer limit for pre existing service contracts if they continue without alteration. - Up to 20 years from entry into use: possible outer limit for legacy self service terminals used in services, depending on Member State implementation. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU Accessibility Act Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take EU Accessibility Act Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Accessibility Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Accessibility Act Deadlines and Compliance Calendar](/solutions/assessment.md): Start from EU Accessibility Act Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Accessibility Act](/contact.md): Review your current process, evidence gaps, and next steps for EU Accessibility Act Deadlines and Compliance Calendar. ## Recurring dates teams should own internally The directive does not prescribe a universal monthly or quarterly review cadence, but a serious programme still needs one. Scope drift, new channels, third party component changes, and updated accessibility findings all create compliance risk if no one owns review dates. Set recurring checkpoints for scope review, regression testing, statement updates, technical documentation refreshes, procurement pack review, and Article 14 reassessment when circumstances change. The goal is to avoid a situation where a launch date arrives before the evidence pack is ready. - Review scope and role assignment at least on every major release or product launch. - Re-run testing on conversion critical and legally material journeys before each production release. - Review published statements and procurement responses on a defined cadence, such as quarterly or at each major version. - Reassess Article 14 decisions when costs, design options, usage patterns, or assistive technology support changes. - Retain Article 14 assessment outputs and product documentation for the required five year window. ## Primary sources - [European Accessibility Act (Directive (EU) 2019/882) - official text](https://eur-lex.europa.eu/eli/dir/2019/882/oj?ref=sorena.io) - Primary legal text for scope, Annex I requirements, Article 14 exceptions, Annex IV technical documentation, and market surveillance measures. - [European Commission - European Accessibility Act policy page](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en?ref=sorena.io) - Official implementation overview and policy context for the Act and its entry into application on 28 June 2025. - [AccessibleEU - Guidance on accessibility legislation in Europe](https://accessible-eu-centre.ec.europa.eu/guidelines-and-support-materials?ref=sorena.io) - Implementation guidance summarising covered products and services, practical obligations, and standard references for teams building compliance programmes. - [ETSI - EN 301 549 overview](https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility?ref=sorena.io) - Official ETSI overview of EN 301 549, the European accessibility standard used to operationalise ICT requirements across web, software, hardware, documents, and communications. - [Commission Notice - Blue Guide on EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A52022XC0629%2804%29&ref=sorena.io) - Primary EU guidance on manufacturer, importer, distributor, declaration of conformity, CE marking, and market surveillance concepts. - [European Commission - Daily News on EAA application in June 2025](https://ec.europa.eu/commission/presscorner/detail/en/mex_25_1650?ref=sorena.io) - Official Commission notice confirming the entry into application on 28 June 2025. ## Related Topic Guides - [EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use](/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping.md): Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way. - [EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence](/artifacts/eu/accessibility-act/accessibility-conformance-statement-template.md): Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method. - [EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs](/artifacts/eu/accessibility-act/applicability-test.md): Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter. - [EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence](/artifacts/eu/accessibility-act/checklist.md): Audit ready EU Accessibility Act compliance checklist for products and services. - [EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence](/artifacts/eu/accessibility-act/compliance.md): Build an EU Accessibility Act compliance programme with this practical playbook. - [EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly](/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden.md): Understand EU Accessibility Act exceptions correctly. - [EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions](/artifacts/eu/accessibility-act/faq.md): Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549. - [EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence](/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites.md): Detailed EU Accessibility Act guide for e-commerce websites and apps. - [EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk](/artifacts/eu/accessibility-act/penalties-and-fines.md): Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products. - [EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce](/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria.md): Draft procurement ready accessibility language under the EU Accessibility Act. - [EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact](/artifacts/eu/accessibility-act/products-and-services-in-scope.md): Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications. - [EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations](/artifacts/eu/accessibility-act/requirements.md): Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation. - [EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep](/artifacts/eu/accessibility-act/testing-and-conformance-evidence.md): Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements. - [EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness](/artifacts/eu/accessibility-act/deadlines-and-transition-plan.md): Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates. - [EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences](/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508.md): Compare the EU Accessibility Act with the ADA and Section 508 in practical terms. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar --- --- title: "EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness" canonical_url: "https://www.sorena.io/artifacts/eu/accessibility-act/deadlines-and-transition-plan" source_url: "https://www.sorena.io/artifacts/eu/accessibility-act/deadlines-and-transition-plan" author: "Sorena AI" description: "Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU Accessibility Act transition plan" - "EAA rollout plan" - "28 June 2025 readiness" - "EAA remediation plan" - "accessibility rollout" - "service contract transition EAA" - "self service terminal transition" - "accessibility programme plan" - "EU Accessibility Act" - "transition plan" - "28 June 2025" - "remediation plan" - "self-service terminals" - "service contracts" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates. *Artifact Guide* *EU* ## EU Accessibility Act Transition Plan A transition plan for moving from generic accessibility intent to documented EU Accessibility Act readiness across products, services, and procurement. This is most useful for organisations with legacy channels, multiple vendors, or mixed product and service portfolios. The transition challenge under the EU Accessibility Act is not only remediation. It is sequencing. Teams must decide what is in scope, what can rely on a transition rule, what needs redesign, what needs vendor pressure, and what evidence must exist before launch or renewal. This page lays out a practical plan for doing that work in the right order. ## Phase 1: scope, transition decisions, and risk ranking Start by splitting the portfolio into four buckets: clearly in scope now, in scope but covered by a transition rule, likely out of scope with rationale, and uncertain items needing legal review. This avoids wasting engineering time on assets that are archived or otherwise excluded while leaving real blockers unresolved. Risk rank the in-scope items by user harm, revenue impact, procurement exposure, complaint likelihood, and the amount of design or vendor dependency involved. Self service terminals, payment flows, and customer account functions often move to the front of the queue. - Document pre 28 June 2025 service contracts that may continue temporarily and note their expiry date. - Create an inventory of terminals already lawfully in use and record entry into use dates if the organisation relies on terminal transition treatment. - Flag products placed on the market after 28 June 2025 that need immediate conformity and documentation work. - Assign each in-scope item an executive owner, delivery owner, and evidence owner. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU Accessibility Act Transition Plan into an operational assessment Assessment Autopilot can take EU Accessibility Act Transition Plan from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Accessibility Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Accessibility Act Transition Plan](/solutions/assessment.md): Start from EU Accessibility Act Transition Plan and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Accessibility Act](/contact.md): Review your current process, evidence gaps, and next steps for EU Accessibility Act Transition Plan. ## Phase 2: remediation, evidence, and go live control Once the roadmap is set, run remediation and evidence in parallel. Accessibility fixes without test evidence create a documentation gap. Evidence work without product fixes creates a false sense of readiness. Pair each remediation epic with required tests, statement updates, procurement language changes, and technical document updates. Use a go live control list that blocks release where critical barriers remain in core journeys or where the required evidence is missing. The best transition plan is one that prevents a non compliant release from becoming a commercial commitment. - Tie each remediation item to a requirement, test method, and release decision. - Update contracts and procurement materials so new purchases or renewals do not reintroduce inaccessible solutions. - Schedule retesting after each major fix and before each major release. - Publish or refresh accessibility statements and internal support guidance before launch. - Keep a final readiness memo that summarises open risks, transition use, and approval status. ## Primary sources - [European Accessibility Act (Directive (EU) 2019/882) - official text](https://eur-lex.europa.eu/eli/dir/2019/882/oj?ref=sorena.io) - Primary legal text for scope, Annex I requirements, Article 14 exceptions, Annex IV technical documentation, and market surveillance measures. - [European Commission - European Accessibility Act policy page](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en?ref=sorena.io) - Official implementation overview and policy context for the Act and its entry into application on 28 June 2025. - [AccessibleEU - Guidance on accessibility legislation in Europe](https://accessible-eu-centre.ec.europa.eu/guidelines-and-support-materials?ref=sorena.io) - Implementation guidance summarising covered products and services, practical obligations, and standard references for teams building compliance programmes. - [ETSI - EN 301 549 overview](https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility?ref=sorena.io) - Official ETSI overview of EN 301 549, the European accessibility standard used to operationalise ICT requirements across web, software, hardware, documents, and communications. - [Commission Notice - Blue Guide on EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A52022XC0629%2804%29&ref=sorena.io) - Primary EU guidance on manufacturer, importer, distributor, declaration of conformity, CE marking, and market surveillance concepts. - [European Commission - Daily News on EAA application in June 2025](https://ec.europa.eu/commission/presscorner/detail/en/mex_25_1650?ref=sorena.io) - Official Commission notice confirming the entry into application on 28 June 2025. ## Related Topic Guides - [EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use](/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping.md): Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way. - [EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence](/artifacts/eu/accessibility-act/accessibility-conformance-statement-template.md): Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method. - [EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs](/artifacts/eu/accessibility-act/applicability-test.md): Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter. - [EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence](/artifacts/eu/accessibility-act/checklist.md): Audit ready EU Accessibility Act compliance checklist for products and services. - [EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence](/artifacts/eu/accessibility-act/compliance.md): Build an EU Accessibility Act compliance programme with this practical playbook. - [EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates](/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar.md): Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025. - [EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly](/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden.md): Understand EU Accessibility Act exceptions correctly. - [EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions](/artifacts/eu/accessibility-act/faq.md): Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549. - [EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence](/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites.md): Detailed EU Accessibility Act guide for e-commerce websites and apps. - [EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk](/artifacts/eu/accessibility-act/penalties-and-fines.md): Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products. - [EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce](/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria.md): Draft procurement ready accessibility language under the EU Accessibility Act. - [EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact](/artifacts/eu/accessibility-act/products-and-services-in-scope.md): Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications. - [EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations](/artifacts/eu/accessibility-act/requirements.md): Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation. - [EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep](/artifacts/eu/accessibility-act/testing-and-conformance-evidence.md): Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements. - [EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences](/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508.md): Compare the EU Accessibility Act with the ADA and Section 508 in practical terms. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/accessibility-act/deadlines-and-transition-plan --- --- title: "EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use" canonical_url: "https://www.sorena.io/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping" source_url: "https://www.sorena.io/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping" author: "Sorena AI" description: "Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EN 301 549 WCAG mapping" - "EU Accessibility Act EN 301 549" - "EN 301 549 accessibility requirements" - "WCAG mapping EU" - "accessibility acceptance criteria" - "accessibility testing clauses" - "EN 301 549 v3.2.1" - "ICT accessibility standard" - "EU Accessibility Act" - "EN 301 549" - "WCAG" - "accessibility requirements" - "engineering acceptance criteria" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way. *Artifact Guide* *EU* ## EU Accessibility Act EN 301 549 and WCAG Mapping Use EN 301 549 and WCAG as an engineering bridge between broad EU Accessibility Act outcomes and concrete testable requirements. The key point is that EN 301 549 covers more than web pages. It also covers software, hardware, documents, communications, and assistive technology interaction. The directive states the legal outcomes. EN 301 549 gives teams the technical structure needed to design, build, and test against those outcomes. For web content, the mapping to WCAG is familiar and useful. For products, communications features, software, documents, and hardware, EN 301 549 reaches beyond standard web checks and gives broader ICT coverage. That is why strong EU Accessibility Act programmes map from Annex I to EN 301 549 first, then to WCAG where it applies. ## How to use EN 301 549 without reducing everything to WCAG EN 301 549 v3.2.1 is the currently referenced version in the local source pack and the ETSI overview notes that a later revision is planned to support the EAA more directly. It already gives a practical functional structure for web content, software, documents, hardware, two way voice communication, video capabilities, and related ICT features. This matters because many EAA offerings are not just websites. Payment terminals, e-readers, media access devices, consumer communication equipment, and service kiosks all require requirements that go beyond a simple web template audit. A mapping table should therefore preserve the product or service surface that each clause applies to. - Map each user facing surface separately: web, native app, downloadable document, software UI, terminal hardware, voice path, and media controls. - Use WCAG mappings where the clause truly applies to web content, not as a shortcut for every ICT requirement. - Keep clause level references in your evidence so engineers, auditors, and procurement teams are looking at the same requirement library. - Track standard version used and the date it was applied in case future revisions change the mapping. ## What the mapping should produce in practice A strong mapping output is a requirement matrix, not a slide. For each product or service surface, record the Annex I outcome, the EN 301 549 clause or clause group, any linked WCAG criterion, the engineering acceptance criterion, the test method, and the owner. This turns the legal text into something teams can build and QA can verify. The AccessibleEU guidance in the grounding pack also points to practical clause examples for text alternatives, heading structure, keyboard accessibility, captions, audio description, voice alternatives, real time text, contrast, flash limits, and clear instructions. Those are good anchors for building your initial clause library. - Include sample clause groups for non text alternatives, structure, keyboard access, media alternatives, contrast, and clear instructions. - Add non web requirements where relevant, such as alternatives to voice only interaction or hardware interaction limits. - Link each mapped item to a reusable test case and evidence slot. - Review the mapping whenever standards or product surfaces change. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Accessibility Act EN 301 549 and WCAG Mapping in one governed evidence system SSOT can take EU Accessibility Act EN 301 549 and WCAG Mapping from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Accessibility Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Accessibility Act EN 301 549 and WCAG Mapping](/solutions/ssot.md): Start from EU Accessibility Act EN 301 549 and WCAG Mapping and keep documents, evidence, and control records in one governed system. - [Talk through EU Accessibility Act](/contact.md): Review your current process, evidence gaps, and next steps for EU Accessibility Act EN 301 549 and WCAG Mapping. ## Primary sources - [European Accessibility Act (Directive (EU) 2019/882) - official text](https://eur-lex.europa.eu/eli/dir/2019/882/oj?ref=sorena.io) - Primary legal text for scope, Annex I requirements, Article 14 exceptions, Annex IV technical documentation, and market surveillance measures. - [European Commission - European Accessibility Act policy page](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en?ref=sorena.io) - Official implementation overview and policy context for the Act and its entry into application on 28 June 2025. - [AccessibleEU - Guidance on accessibility legislation in Europe](https://accessible-eu-centre.ec.europa.eu/guidelines-and-support-materials?ref=sorena.io) - Implementation guidance summarising covered products and services, practical obligations, and standard references for teams building compliance programmes. - [ETSI - EN 301 549 overview](https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility?ref=sorena.io) - Official ETSI overview of EN 301 549, the European accessibility standard used to operationalise ICT requirements across web, software, hardware, documents, and communications. - [Commission Notice - Blue Guide on EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A52022XC0629%2804%29&ref=sorena.io) - Primary EU guidance on manufacturer, importer, distributor, declaration of conformity, CE marking, and market surveillance concepts. - [European Commission - Daily News on EAA application in June 2025](https://ec.europa.eu/commission/presscorner/detail/en/mex_25_1650?ref=sorena.io) - Official Commission notice confirming the entry into application on 28 June 2025. ## Related Topic Guides - [EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence](/artifacts/eu/accessibility-act/accessibility-conformance-statement-template.md): Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method. - [EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs](/artifacts/eu/accessibility-act/applicability-test.md): Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter. - [EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence](/artifacts/eu/accessibility-act/checklist.md): Audit ready EU Accessibility Act compliance checklist for products and services. - [EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence](/artifacts/eu/accessibility-act/compliance.md): Build an EU Accessibility Act compliance programme with this practical playbook. - [EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates](/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar.md): Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025. - [EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly](/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden.md): Understand EU Accessibility Act exceptions correctly. - [EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions](/artifacts/eu/accessibility-act/faq.md): Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549. - [EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence](/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites.md): Detailed EU Accessibility Act guide for e-commerce websites and apps. - [EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk](/artifacts/eu/accessibility-act/penalties-and-fines.md): Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products. - [EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce](/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria.md): Draft procurement ready accessibility language under the EU Accessibility Act. - [EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact](/artifacts/eu/accessibility-act/products-and-services-in-scope.md): Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications. - [EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations](/artifacts/eu/accessibility-act/requirements.md): Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation. - [EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep](/artifacts/eu/accessibility-act/testing-and-conformance-evidence.md): Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements. - [EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness](/artifacts/eu/accessibility-act/deadlines-and-transition-plan.md): Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates. - [EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences](/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508.md): Compare the EU Accessibility Act with the ADA and Section 508 in practical terms. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping --- --- title: "EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly" canonical_url: "https://www.sorena.io/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden" source_url: "https://www.sorena.io/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden" author: "Sorena AI" description: "Understand EU Accessibility Act exceptions correctly." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU Accessibility Act disproportionate burden" - "Article 14 EAA" - "fundamental alteration EAA" - "microenterprise exemption EAA" - "Annex VI EAA" - "accessibility exception documentation" - "market surveillance Article 14" - "EAA authority notification" - "EU Accessibility Act" - "Article 14" - "disproportionate burden" - "fundamental alteration" - "microenterprise" - "Annex VI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly Understand EU Accessibility Act exceptions correctly. *Artifact Guide* *EU* ## EU Accessibility Act Exemptions and Disproportionate Burden A practical guide to Article 14 so teams document exceptions defensibly instead of treating them as a shortcut around accessibility work. The directive allows narrow relief. It does not reward vague hardship claims or undocumented tradeoffs. The two Article 14 concepts that matter are fundamental alteration and disproportionate burden. They are not blanket exemptions from the directive. They are requirement by requirement assessments that must be tied to the offering, the specific accessibility outcome, the options considered, and the evidence retained. The directive also gives special treatment to microenterprises, and teams often misunderstand the difference between microenterprise relief and a full Article 14 assessment. ## What Article 14 actually allows An operator may conclude that a specific requirement would fundamentally alter the basic nature of the product or service, or would impose a disproportionate burden when assessed against Annex VI criteria. That conclusion must be reasoned, specific, and documented. It is not enough to say accessibility is expensive or difficult. The assessment should show what requirement is at issue, what design or implementation options were explored, what costs and benefits were considered, and whether partial compliance can reduce burden while still materially improving access. For services involving self service terminals, the directive explicitly expects operators to consider whether a limited number of fully accessible terminals or a limited level of accessibility can avoid a disproportionate burden while still moving toward compliance. - Assess one requirement or requirement set at a time, not the whole directive in one sentence. - Use Annex VI criteria and keep the reasoning tied to actual facts, costs, benefits, scale, and alternatives. - Review whether partial implementation or different design choices can remove the burden argument. - Retain the assessment and all relevant results for five years from the last making available of the product or the last provision of the service. ## Microenterprise treatment and authority notification A microenterprise under the directive employs fewer than 10 people and has annual turnover not exceeding EUR 2 million or annual balance sheet total not exceeding EUR 2 million. Microenterprises providing services within scope are exempt from the directive requirements and obligations. Microenterprises dealing with products get lighter treatment, but they are not free to make unsupported claims if they rely on Article 14. Where economic operators rely on Article 14 for a specific product or service, they generally have to send information to the relevant authority in the Member State where the product is placed on the market or the service is provided. The directive states that this notification duty does not apply to microenterprises. Teams should still keep their records clean because authorities may ask for supporting facts. - Confirm enterprise size before invoking any microenterprise rule. - Do not confuse exemption from documentation with exemption from having facts. - Set a review trigger when enterprise size, revenue, product design, or available technology changes. - Align public statements and procurement claims with the exact scope of the Article 14 decision. *Recommended next step* *Placement: after the scope or definition section* ## Use EU Accessibility Act Exemptions and Disproportionate Burden as a cited research workflow Research Copilot can take EU Accessibility Act Exemptions and Disproportionate Burden from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Accessibility Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Accessibility Act Exemptions and Disproportionate Burden](/solutions/research-copilot.md): Start from EU Accessibility Act Exemptions and Disproportionate Burden and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Accessibility Act](/contact.md): Review your current process, evidence gaps, and next steps for EU Accessibility Act Exemptions and Disproportionate Burden. ## Primary sources - [European Accessibility Act (Directive (EU) 2019/882) - official text](https://eur-lex.europa.eu/eli/dir/2019/882/oj?ref=sorena.io) - Primary legal text for scope, Annex I requirements, Article 14 exceptions, Annex IV technical documentation, and market surveillance measures. - [European Commission - European Accessibility Act policy page](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en?ref=sorena.io) - Official implementation overview and policy context for the Act and its entry into application on 28 June 2025. - [AccessibleEU - Guidance on accessibility legislation in Europe](https://accessible-eu-centre.ec.europa.eu/guidelines-and-support-materials?ref=sorena.io) - Implementation guidance summarising covered products and services, practical obligations, and standard references for teams building compliance programmes. - [ETSI - EN 301 549 overview](https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility?ref=sorena.io) - Official ETSI overview of EN 301 549, the European accessibility standard used to operationalise ICT requirements across web, software, hardware, documents, and communications. - [Commission Notice - Blue Guide on EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A52022XC0629%2804%29&ref=sorena.io) - Primary EU guidance on manufacturer, importer, distributor, declaration of conformity, CE marking, and market surveillance concepts. - [European Commission - Daily News on EAA application in June 2025](https://ec.europa.eu/commission/presscorner/detail/en/mex_25_1650?ref=sorena.io) - Official Commission notice confirming the entry into application on 28 June 2025. ## Related Topic Guides - [EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use](/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping.md): Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way. - [EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence](/artifacts/eu/accessibility-act/accessibility-conformance-statement-template.md): Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method. - [EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs](/artifacts/eu/accessibility-act/applicability-test.md): Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter. - [EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence](/artifacts/eu/accessibility-act/checklist.md): Audit ready EU Accessibility Act compliance checklist for products and services. - [EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence](/artifacts/eu/accessibility-act/compliance.md): Build an EU Accessibility Act compliance programme with this practical playbook. - [EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates](/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar.md): Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025. - [EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions](/artifacts/eu/accessibility-act/faq.md): Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549. - [EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence](/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites.md): Detailed EU Accessibility Act guide for e-commerce websites and apps. - [EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk](/artifacts/eu/accessibility-act/penalties-and-fines.md): Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products. - [EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce](/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria.md): Draft procurement ready accessibility language under the EU Accessibility Act. - [EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact](/artifacts/eu/accessibility-act/products-and-services-in-scope.md): Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications. - [EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations](/artifacts/eu/accessibility-act/requirements.md): Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation. - [EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep](/artifacts/eu/accessibility-act/testing-and-conformance-evidence.md): Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements. - [EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness](/artifacts/eu/accessibility-act/deadlines-and-transition-plan.md): Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates. - [EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences](/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508.md): Compare the EU Accessibility Act with the ADA and Section 508 in practical terms. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden --- --- title: "EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions" canonical_url: "https://www.sorena.io/artifacts/eu/accessibility-act/faq" source_url: "https://www.sorena.io/artifacts/eu/accessibility-act/faq" author: "Sorena AI" description: "Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU Accessibility Act FAQ" - "EAA questions" - "what products are in scope EAA" - "what services are in scope EAA" - "EN 301 549 FAQ" - "Article 14 FAQ" - "market surveillance FAQ" - "accessibility procurement FAQ" - "EU Accessibility Act" - "FAQ" - "EN 301 549" - "procurement" - "Article 14" - "market surveillance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549. *Artifact Guide* *EU* ## EU Accessibility Act FAQ Practical answers to the recurring EU Accessibility Act questions from product, legal, design, procurement, and compliance teams. Use this page to reduce repeat scope debates and to point stakeholders to the right evidence question quickly. Most EU Accessibility Act confusion comes from six recurring topics: whether an offering is in scope, what the 28 June 2025 date changes, whether WCAG alone is enough, what documents are needed for products, how Article 14 works, and what happens if authorities challenge the offering. This FAQ answers those questions in practical terms so teams can make faster decisions. ## Common scope and timing questions The first questions are usually about category and date. The directive applies to listed products placed on the market after 28 June 2025 and listed services provided to consumers after 28 June 2025, subject to exclusions and transition rules. That means teams need both an inventory and a date aware release history. The second common question is whether old content or systems are automatically in scope. The answer is not always. Archived content, older office files, pre recorded media published before 28 June 2025, and certain legacy service arrangements can fall under exclusions or transition treatment. The details matter, so record them. - Products in scope include defined consumer computing equipment, certain self service terminals, media access devices, communications equipment, and e-readers. - Services in scope include e-commerce, consumer banking, electronic communications, access to audiovisual media services, and defined transport service elements. - Some older content and some legacy service arrangements may be treated differently, but that requires documentation. - Scope should be reviewed whenever offerings, channels, or customer journeys change. ## Common evidence and enforcement questions Another frequent question is whether a one time audit is enough. It is not. Product teams need technical documentation and declaration processes. Service teams need a living evidence pack that ties scope, requirements, tests, and statements together. Both need a way to answer procurement and authority questions quickly. Teams also ask what happens if they fail. The directive leaves penalties to Member States, but for products it clearly gives market surveillance authorities power to require corrective action and, if necessary, restrict, prohibit, or withdraw non compliant products. Documentation failures are part of that risk. - Use EN 301 549 as a technical implementation framework where it fits the offering. - Keep dated test results, remediation records, and sign off evidence by release. - Document Article 14 decisions and retain them for the required five year period. - Prepare procurement language and customer facing statements before they are requested in a live deal. *Recommended next step* *Placement: after the FAQ section* ## Use EU Accessibility Act FAQ as a cited research workflow Research Copilot can take EU Accessibility Act FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU Accessibility Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Accessibility Act FAQ](/solutions/research-copilot.md): Start from EU Accessibility Act FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Accessibility Act](/contact.md): Review your current process, evidence gaps, and next steps for EU Accessibility Act FAQ. ## Primary sources - [European Accessibility Act (Directive (EU) 2019/882) - official text](https://eur-lex.europa.eu/eli/dir/2019/882/oj?ref=sorena.io) - Primary legal text for scope, Annex I requirements, Article 14 exceptions, Annex IV technical documentation, and market surveillance measures. - [European Commission - European Accessibility Act policy page](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en?ref=sorena.io) - Official implementation overview and policy context for the Act and its entry into application on 28 June 2025. - [AccessibleEU - Guidance on accessibility legislation in Europe](https://accessible-eu-centre.ec.europa.eu/guidelines-and-support-materials?ref=sorena.io) - Implementation guidance summarising covered products and services, practical obligations, and standard references for teams building compliance programmes. - [ETSI - EN 301 549 overview](https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility?ref=sorena.io) - Official ETSI overview of EN 301 549, the European accessibility standard used to operationalise ICT requirements across web, software, hardware, documents, and communications. - [Commission Notice - Blue Guide on EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A52022XC0629%2804%29&ref=sorena.io) - Primary EU guidance on manufacturer, importer, distributor, declaration of conformity, CE marking, and market surveillance concepts. - [European Commission - Daily News on EAA application in June 2025](https://ec.europa.eu/commission/presscorner/detail/en/mex_25_1650?ref=sorena.io) - Official Commission notice confirming the entry into application on 28 June 2025. ## Related Topic Guides - [EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use](/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping.md): Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way. - [EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence](/artifacts/eu/accessibility-act/accessibility-conformance-statement-template.md): Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method. - [EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs](/artifacts/eu/accessibility-act/applicability-test.md): Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter. - [EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence](/artifacts/eu/accessibility-act/checklist.md): Audit ready EU Accessibility Act compliance checklist for products and services. - [EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence](/artifacts/eu/accessibility-act/compliance.md): Build an EU Accessibility Act compliance programme with this practical playbook. - [EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates](/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar.md): Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025. - [EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly](/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden.md): Understand EU Accessibility Act exceptions correctly. - [EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence](/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites.md): Detailed EU Accessibility Act guide for e-commerce websites and apps. - [EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk](/artifacts/eu/accessibility-act/penalties-and-fines.md): Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products. - [EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce](/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria.md): Draft procurement ready accessibility language under the EU Accessibility Act. - [EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact](/artifacts/eu/accessibility-act/products-and-services-in-scope.md): Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications. - [EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations](/artifacts/eu/accessibility-act/requirements.md): Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation. - [EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep](/artifacts/eu/accessibility-act/testing-and-conformance-evidence.md): Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements. - [EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness](/artifacts/eu/accessibility-act/deadlines-and-transition-plan.md): Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates. - [EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences](/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508.md): Compare the EU Accessibility Act with the ADA and Section 508 in practical terms. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/accessibility-act/faq --- --- title: "EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk" canonical_url: "https://www.sorena.io/artifacts/eu/accessibility-act/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/accessibility-act/penalties-and-fines" author: "Sorena AI" description: "Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU Accessibility Act penalties" - "EAA fines" - "EAA enforcement" - "market surveillance accessibility" - "corrective action accessibility" - "product withdrawal accessibility" - "accessibility documentation risk" - "declaration of conformity accessibility" - "EU Accessibility Act" - "penalties" - "market surveillance" - "corrective action" - "documentation risk" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products. *Artifact Guide* *EU* ## EU Accessibility Act Penalties and Enforcement A practical view of EU Accessibility Act enforcement risk, with focus on market surveillance, corrective action, and documentation gaps that turn into commercial and regulatory exposure. The biggest mistake is to look only for a fine table. The real risk often starts earlier with blocked deals, authority questions, and corrective action orders. The directive requires Member States to set penalties, so the exact fine framework depends on national law. But the enforcement picture is still clear from the directive itself. Authorities can evaluate products, require corrective action, and if the operator fails to act, restrict or prohibit the product from being made available or withdraw it from the market. That makes evidence quality and response speed central parts of compliance, not afterthoughts. ## What authorities can do when they find non compliance For products, market surveillance authorities can investigate where they have reason to believe the offering does not comply. They can require the relevant economic operator to bring the product into conformity within a prescribed period that matches the nature of the non compliance. If the operator does not take adequate corrective action, authorities can move to restrict, prohibit, or withdraw the product. The directive also makes clear that documentation failures matter. Missing or incomplete technical documentation, a missing declaration of conformity, or an incorrect declaration are themselves part of the compliance problem. In practice, that means a product can be commercially weak even when underlying engineering work exists but is not properly recorded. - Expect authorities to ask for product identification, origin, nature of non compliance, and supporting documents. - Treat missing technical documentation and declaration errors as first class risks, not admin tasks. - Build a corrective action process with owners, deadlines, and evidence of closure. - Preserve the ability to answer authority questions quickly across product, legal, and support teams. ## How to reduce enforcement risk before it becomes a case The best penalty mitigation is early evidence discipline. If scope, testing, remediation, and operator records are current, teams can answer customer, procurement, and authority questions without improvisation. If those records are missing, even a manageable defect can escalate into a governance failure. For services, the pressure often arrives through complaints, procurement review, or customer escalation before it arrives through formal enforcement. A mature programme therefore treats accessibility response as part of commercial readiness as well as legal compliance. - Keep one evidence index per offering with tests, findings, fixes, statements, and decisions. - Review public claims and sales responses so they match the real state of the product or service. - Escalate critical accessibility barriers like any other severe release blocker. - Monitor Member State implementation because penalty levels and procedures are national. *Recommended next step* *Placement: after the enforcement section* ## Use EU Accessibility Act Penalties and Enforcement as a cited research workflow Research Copilot can take EU Accessibility Act Penalties and Enforcement from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Accessibility Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Accessibility Act Penalties and Enforcement](/solutions/research-copilot.md): Start from EU Accessibility Act Penalties and Enforcement and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Accessibility Act](/contact.md): Review your current process, evidence gaps, and next steps for EU Accessibility Act Penalties and Enforcement. ## Primary sources - [European Accessibility Act (Directive (EU) 2019/882) - official text](https://eur-lex.europa.eu/eli/dir/2019/882/oj?ref=sorena.io) - Primary legal text for scope, Annex I requirements, Article 14 exceptions, Annex IV technical documentation, and market surveillance measures. - [European Commission - European Accessibility Act policy page](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en?ref=sorena.io) - Official implementation overview and policy context for the Act and its entry into application on 28 June 2025. - [AccessibleEU - Guidance on accessibility legislation in Europe](https://accessible-eu-centre.ec.europa.eu/guidelines-and-support-materials?ref=sorena.io) - Implementation guidance summarising covered products and services, practical obligations, and standard references for teams building compliance programmes. - [ETSI - EN 301 549 overview](https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility?ref=sorena.io) - Official ETSI overview of EN 301 549, the European accessibility standard used to operationalise ICT requirements across web, software, hardware, documents, and communications. - [Commission Notice - Blue Guide on EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A52022XC0629%2804%29&ref=sorena.io) - Primary EU guidance on manufacturer, importer, distributor, declaration of conformity, CE marking, and market surveillance concepts. - [European Commission - Daily News on EAA application in June 2025](https://ec.europa.eu/commission/presscorner/detail/en/mex_25_1650?ref=sorena.io) - Official Commission notice confirming the entry into application on 28 June 2025. ## Related Topic Guides - [EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use](/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping.md): Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way. - [EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence](/artifacts/eu/accessibility-act/accessibility-conformance-statement-template.md): Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method. - [EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs](/artifacts/eu/accessibility-act/applicability-test.md): Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter. - [EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence](/artifacts/eu/accessibility-act/checklist.md): Audit ready EU Accessibility Act compliance checklist for products and services. - [EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence](/artifacts/eu/accessibility-act/compliance.md): Build an EU Accessibility Act compliance programme with this practical playbook. - [EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates](/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar.md): Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025. - [EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly](/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden.md): Understand EU Accessibility Act exceptions correctly. - [EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions](/artifacts/eu/accessibility-act/faq.md): Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549. - [EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence](/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites.md): Detailed EU Accessibility Act guide for e-commerce websites and apps. - [EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce](/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria.md): Draft procurement ready accessibility language under the EU Accessibility Act. - [EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact](/artifacts/eu/accessibility-act/products-and-services-in-scope.md): Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications. - [EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations](/artifacts/eu/accessibility-act/requirements.md): Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation. - [EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep](/artifacts/eu/accessibility-act/testing-and-conformance-evidence.md): Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements. - [EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness](/artifacts/eu/accessibility-act/deadlines-and-transition-plan.md): Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates. - [EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences](/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508.md): Compare the EU Accessibility Act with the ADA and Section 508 in practical terms. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/accessibility-act/penalties-and-fines --- --- title: "EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce" canonical_url: "https://www.sorena.io/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria" source_url: "https://www.sorena.io/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria" author: "Sorena AI" description: "Draft procurement ready accessibility language under the EU Accessibility Act." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU Accessibility Act procurement language" - "accessibility procurement clauses" - "accessibility acceptance criteria" - "Annex I procurement" - "EN 301 549 procurement" - "supplier accessibility clauses" - "accessibility tender requirements" - "accessibility evidence request" - "EU Accessibility Act" - "procurement" - "acceptance criteria" - "EN 301 549" - "Annex I" - "supplier clauses" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce Draft procurement ready accessibility language under the EU Accessibility Act. *Artifact Guide* *EU* ## EU Accessibility Act Procurement Language and Acceptance Criteria Use procurement language that turns accessibility from a general promise into measurable acceptance criteria and evidence obligations. This matters on both the buy side and the sell side because weak contract language usually creates weak accountability. The directive explicitly states that the accessibility requirements in Annex I are mandatory accessibility requirements for the purposes of the main EU public procurement directives. That makes procurement language a real control point, not a side issue. Good clauses help buyers define what they need and help suppliers avoid over claiming while still showing the exact evidence they can provide. ## What procurement language should require Start from measurable outcomes. A clause that says the solution should be accessible is too vague to test. A clause that requires conformance against the applicable accessibility requirements, identified channels, named test methods, and evidence outputs gives the buyer something enforceable and gives the supplier a clear delivery target. For ICT heavy solutions, procurement language should identify the standards or requirement sets used, the environments tested, and the evidence that must be delivered at contract award, implementation, and acceptance. For services, it should also cover support channels, updates, and issue resolution after go live. - Define the exact product or service scope and channels covered by the clause. - Require a requirement matrix or equivalent mapping from legal outcome to technical test criteria. - Require dated test evidence, issue logs, remediation status, and known limitations. - Require notice and approval before user facing scope changes that may reduce accessibility. - Require support contact routes and issue escalation for accessibility defects. ## How to make acceptance criteria testable Acceptance criteria should be tied to user journeys and observable behaviours, not only to a supplier statement. For example, the buyer should be able to test keyboard completion of a checkout flow, screen reader navigation through core steps, or the ability to activate media access services or non voice alternatives where relevant. Where a supplier relies on an exception or limited scope, procurement language should force disclosure of that decision and its boundaries. Buyers should not discover after signature that a key journey or feature was never intended to comply. - Write acceptance tests around core tasks users need to complete, not around abstract accessibility labels. - Require disclosure of out of scope features, temporary workarounds, and Article 14 reliance where applicable. - Reserve the right to reject or require remediation for critical barriers found during buyer testing. - Keep the evidence bundle updated at major releases and renewals, not only at initial delivery. *Recommended next step* *Placement: after the scope or definition section* ## Use EU Accessibility Act Procurement Language and Acceptance Criteria as a cited research workflow Research Copilot can take EU Accessibility Act Procurement Language and Acceptance Criteria from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Accessibility Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Accessibility Act Procurement Language and Acceptance Criteria](/solutions/research-copilot.md): Start from EU Accessibility Act Procurement Language and Acceptance Criteria and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Accessibility Act](/contact.md): Review your current process, evidence gaps, and next steps for EU Accessibility Act Procurement Language and Acceptance Criteria. ## Primary sources - [European Accessibility Act (Directive (EU) 2019/882) - official text](https://eur-lex.europa.eu/eli/dir/2019/882/oj?ref=sorena.io) - Primary legal text for scope, Annex I requirements, Article 14 exceptions, Annex IV technical documentation, and market surveillance measures. - [European Commission - European Accessibility Act policy page](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en?ref=sorena.io) - Official implementation overview and policy context for the Act and its entry into application on 28 June 2025. - [AccessibleEU - Guidance on accessibility legislation in Europe](https://accessible-eu-centre.ec.europa.eu/guidelines-and-support-materials?ref=sorena.io) - Implementation guidance summarising covered products and services, practical obligations, and standard references for teams building compliance programmes. - [ETSI - EN 301 549 overview](https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility?ref=sorena.io) - Official ETSI overview of EN 301 549, the European accessibility standard used to operationalise ICT requirements across web, software, hardware, documents, and communications. - [Commission Notice - Blue Guide on EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A52022XC0629%2804%29&ref=sorena.io) - Primary EU guidance on manufacturer, importer, distributor, declaration of conformity, CE marking, and market surveillance concepts. - [European Commission - Daily News on EAA application in June 2025](https://ec.europa.eu/commission/presscorner/detail/en/mex_25_1650?ref=sorena.io) - Official Commission notice confirming the entry into application on 28 June 2025. ## Related Topic Guides - [EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use](/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping.md): Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way. - [EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence](/artifacts/eu/accessibility-act/accessibility-conformance-statement-template.md): Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method. - [EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs](/artifacts/eu/accessibility-act/applicability-test.md): Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter. - [EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence](/artifacts/eu/accessibility-act/checklist.md): Audit ready EU Accessibility Act compliance checklist for products and services. - [EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence](/artifacts/eu/accessibility-act/compliance.md): Build an EU Accessibility Act compliance programme with this practical playbook. - [EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates](/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar.md): Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025. - [EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly](/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden.md): Understand EU Accessibility Act exceptions correctly. - [EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions](/artifacts/eu/accessibility-act/faq.md): Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549. - [EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence](/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites.md): Detailed EU Accessibility Act guide for e-commerce websites and apps. - [EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk](/artifacts/eu/accessibility-act/penalties-and-fines.md): Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products. - [EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact](/artifacts/eu/accessibility-act/products-and-services-in-scope.md): Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications. - [EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations](/artifacts/eu/accessibility-act/requirements.md): Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation. - [EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep](/artifacts/eu/accessibility-act/testing-and-conformance-evidence.md): Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements. - [EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness](/artifacts/eu/accessibility-act/deadlines-and-transition-plan.md): Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates. - [EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences](/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508.md): Compare the EU Accessibility Act with the ADA and Section 508 in practical terms. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria --- --- title: "EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact" canonical_url: "https://www.sorena.io/artifacts/eu/accessibility-act/products-and-services-in-scope" source_url: "https://www.sorena.io/artifacts/eu/accessibility-act/products-and-services-in-scope" author: "Sorena AI" description: "Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU Accessibility Act products in scope" - "EU Accessibility Act services in scope" - "EAA scope categories" - "e-commerce services EAA" - "consumer banking EAA" - "self service terminals EAA" - "e-readers EAA" - "communications services accessibility" - "audiovisual media services accessibility" - "EU Accessibility Act" - "products in scope" - "services in scope" - "manufacturer" - "service provider" - "e-commerce" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications. *Artifact Guide* *EU* ## EU Accessibility Act Products and Services in Scope A practical scope guide to the product and service categories named in the EU Accessibility Act, with the definitions and role consequences teams need for real delivery planning. Scope is the highest leverage decision in the entire programme. Document it once, then reuse it everywhere. Article 2 of the directive does not apply to all digital products and services. It names specific product and service categories. Good scope work therefore starts with the category list and the supporting definitions, then moves to user facing interfaces and operator roles. This page gives a working scope view that product teams, procurement teams, and legal reviewers can all use. ## Products in scope under Article 2 Covered products placed on the market after 28 June 2025 include consumer general purpose computer hardware systems and their operating systems, specified self service terminals such as payment terminals and ATMs, consumer terminal equipment with interactive computing capability used for electronic communications services, consumer terminal equipment used for accessing audiovisual media services, and e-readers. The directive definitions matter. Consumer general purpose computer hardware systems explicitly include personal computers and, in the directive text, examples such as desktops, notebooks, smartphones, and tablets. Teams should therefore use the legal category rather than improvised product marketing labels when scoping. - Separate consumer hardware in scope from business only or non covered equipment. - Check whether the product has packaging, installation information, or support materials that also need accessibility treatment. - For self service terminals, distinguish payment terminals from terminals used in covered services and record transition status if legacy units remain in use. - Assign manufacturer, importer, distributor, and representative duties early because document obligations differ by role. *Recommended next step* *Placement: after the scope or definition section* ## Use EU Accessibility Act Products and Services in Scope as a cited research workflow Research Copilot can take EU Accessibility Act Products and Services in Scope from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Accessibility Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Accessibility Act Products and Services in Scope](/solutions/research-copilot.md): Start from EU Accessibility Act Products and Services in Scope and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Accessibility Act](/contact.md): Review your current process, evidence gaps, and next steps for EU Accessibility Act Products and Services in Scope. ## Services in scope under Article 2 Covered services provided to consumers after 28 June 2025 include electronic communications services, services providing access to audiovisual media services, defined elements of passenger transport services, consumer banking services, and e-commerce services. The transport category includes websites, mobile services, electronic tickets and ticketing services, transport information, and relevant interactive self service terminals. The practical scoping question is usually not whether the company sells software. It is whether the company is providing one of these consumer services and which customer facing channels are used to deliver it. That is why service inventories should list every consumer interaction channel, not just the main website. - Map each service to the channels consumers actually use: web, mobile, kiosk, tickets, statements, help content, and customer support. - Check adjacent content and features that users need to complete the service, such as onboarding, authentication, and account management. - Apply exclusions carefully for older media, old office files, and archive content that is not updated after 28 June 2025. - Keep a separate note for mixed offerings where one channel is in scope and another is not. ## Primary sources - [European Accessibility Act (Directive (EU) 2019/882) - official text](https://eur-lex.europa.eu/eli/dir/2019/882/oj?ref=sorena.io) - Primary legal text for scope, Annex I requirements, Article 14 exceptions, Annex IV technical documentation, and market surveillance measures. - [European Commission - European Accessibility Act policy page](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en?ref=sorena.io) - Official implementation overview and policy context for the Act and its entry into application on 28 June 2025. - [AccessibleEU - Guidance on accessibility legislation in Europe](https://accessible-eu-centre.ec.europa.eu/guidelines-and-support-materials?ref=sorena.io) - Implementation guidance summarising covered products and services, practical obligations, and standard references for teams building compliance programmes. - [ETSI - EN 301 549 overview](https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility?ref=sorena.io) - Official ETSI overview of EN 301 549, the European accessibility standard used to operationalise ICT requirements across web, software, hardware, documents, and communications. - [Commission Notice - Blue Guide on EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A52022XC0629%2804%29&ref=sorena.io) - Primary EU guidance on manufacturer, importer, distributor, declaration of conformity, CE marking, and market surveillance concepts. - [European Commission - Daily News on EAA application in June 2025](https://ec.europa.eu/commission/presscorner/detail/en/mex_25_1650?ref=sorena.io) - Official Commission notice confirming the entry into application on 28 June 2025. ## Related Topic Guides - [EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use](/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping.md): Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way. - [EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence](/artifacts/eu/accessibility-act/accessibility-conformance-statement-template.md): Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method. - [EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs](/artifacts/eu/accessibility-act/applicability-test.md): Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter. - [EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence](/artifacts/eu/accessibility-act/checklist.md): Audit ready EU Accessibility Act compliance checklist for products and services. - [EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence](/artifacts/eu/accessibility-act/compliance.md): Build an EU Accessibility Act compliance programme with this practical playbook. - [EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates](/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar.md): Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025. - [EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly](/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden.md): Understand EU Accessibility Act exceptions correctly. - [EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions](/artifacts/eu/accessibility-act/faq.md): Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549. - [EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence](/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites.md): Detailed EU Accessibility Act guide for e-commerce websites and apps. - [EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk](/artifacts/eu/accessibility-act/penalties-and-fines.md): Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products. - [EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce](/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria.md): Draft procurement ready accessibility language under the EU Accessibility Act. - [EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations](/artifacts/eu/accessibility-act/requirements.md): Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation. - [EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep](/artifacts/eu/accessibility-act/testing-and-conformance-evidence.md): Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements. - [EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness](/artifacts/eu/accessibility-act/deadlines-and-transition-plan.md): Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates. - [EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences](/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508.md): Compare the EU Accessibility Act with the ADA and Section 508 in practical terms. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/accessibility-act/products-and-services-in-scope --- --- title: "EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations" canonical_url: "https://www.sorena.io/artifacts/eu/accessibility-act/requirements" source_url: "https://www.sorena.io/artifacts/eu/accessibility-act/requirements" author: "Sorena AI" description: "Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU Accessibility Act requirements" - "Annex I accessibility requirements" - "EAA requirements" - "European Accessibility Act Annex I" - "EN 301 549 implementation" - "accessibility product requirements" - "accessibility service requirements" - "technical documentation accessibility" - "declaration of conformity accessibility" - "EU Accessibility Act" - "requirements" - "Annex I" - "EN 301 549" - "technical documentation" - "service evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation. *Artifact Guide* *EU* ## EU Accessibility Act Requirements A grounded view of the EU Accessibility Act requirements that matter in delivery: Annex I outcomes, role based duties, and the evidence needed to prove work was done. The requirement set is broader than web accessibility alone. It covers product information, interfaces, support, and service delivery conditions. The directive is outcome based, but teams still need an implementation structure. The right approach is to separate three layers: first, the Annex I accessibility outcomes that apply to the offering; second, the duties that attach to the business role for that offering; third, the evidence needed to prove the requirement was addressed. That is what this page is designed to help you do. ## Annex I requirements in practical terms Annex I requires that information, user interfaces, and supporting features be accessible so disabled users can perceive, operate, understand, and benefit from the offering. For products, that can reach the product itself, packaging information, instructions, and interfaces. For services, it reaches the information about the service and the digital channels through which the service is delivered. The local grounding pack also shows that specific categories receive more detailed functional requirements. For example, e-readers are expected to provide text to speech technology, communications services require alternatives to voice only interaction and synchronised emergency communications features where applicable, and media access services must preserve accessibility components such as subtitles and audio description. - Identify which Annex I sections apply to the exact category in scope. - Cover information, instructions, labels, controls, and support features, not only the main UI. - Translate each requirement into a measurable behaviour or acceptance criterion. - Use plain language, clear instructions, and accessible interaction patterns across all user facing materials. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU Accessibility Act Requirements into an operational assessment Assessment Autopilot can take EU Accessibility Act Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Accessibility Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Accessibility Act Requirements](/solutions/assessment.md): Start from EU Accessibility Act Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Accessibility Act](/contact.md): Review your current process, evidence gaps, and next steps for EU Accessibility Act Requirements. ## Role duties and evidence expectations Product roles create specific legal duties. Manufacturers need technical documentation under Annex IV, conformity assessment, and an EU declaration of conformity, which then supports the product being placed on the market. Importers must verify the manufacturer has done that work and keep a copy of the declaration for five years while ensuring the technical documentation can be made available. Distributors must not make products available when they know or have reason to believe they are not compliant. Services do not follow the same declaration workflow, but they still need a disciplined evidence pack. That pack should show scope, requirements, standards used, tests run, barriers identified, remediations completed, any exceptions relied on, and the owner responsible for keeping the record current. - For products, prepare Annex IV documentation and declaration processes before launch. - For services, maintain a traceable evidence pack by channel and release. - Keep five year retention rules in mind for product documentation and Article 14 records. - Make sure procurement statements, sales claims, and support scripts all reflect the same requirement position. ## Primary sources - [European Accessibility Act (Directive (EU) 2019/882) - official text](https://eur-lex.europa.eu/eli/dir/2019/882/oj?ref=sorena.io) - Primary legal text for scope, Annex I requirements, Article 14 exceptions, Annex IV technical documentation, and market surveillance measures. - [European Commission - European Accessibility Act policy page](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en?ref=sorena.io) - Official implementation overview and policy context for the Act and its entry into application on 28 June 2025. - [AccessibleEU - Guidance on accessibility legislation in Europe](https://accessible-eu-centre.ec.europa.eu/guidelines-and-support-materials?ref=sorena.io) - Implementation guidance summarising covered products and services, practical obligations, and standard references for teams building compliance programmes. - [ETSI - EN 301 549 overview](https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility?ref=sorena.io) - Official ETSI overview of EN 301 549, the European accessibility standard used to operationalise ICT requirements across web, software, hardware, documents, and communications. - [Commission Notice - Blue Guide on EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A52022XC0629%2804%29&ref=sorena.io) - Primary EU guidance on manufacturer, importer, distributor, declaration of conformity, CE marking, and market surveillance concepts. - [European Commission - Daily News on EAA application in June 2025](https://ec.europa.eu/commission/presscorner/detail/en/mex_25_1650?ref=sorena.io) - Official Commission notice confirming the entry into application on 28 June 2025. ## Related Topic Guides - [EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use](/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping.md): Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way. - [EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence](/artifacts/eu/accessibility-act/accessibility-conformance-statement-template.md): Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method. - [EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs](/artifacts/eu/accessibility-act/applicability-test.md): Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter. - [EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence](/artifacts/eu/accessibility-act/checklist.md): Audit ready EU Accessibility Act compliance checklist for products and services. - [EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence](/artifacts/eu/accessibility-act/compliance.md): Build an EU Accessibility Act compliance programme with this practical playbook. - [EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates](/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar.md): Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025. - [EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly](/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden.md): Understand EU Accessibility Act exceptions correctly. - [EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions](/artifacts/eu/accessibility-act/faq.md): Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549. - [EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence](/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites.md): Detailed EU Accessibility Act guide for e-commerce websites and apps. - [EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk](/artifacts/eu/accessibility-act/penalties-and-fines.md): Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products. - [EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce](/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria.md): Draft procurement ready accessibility language under the EU Accessibility Act. - [EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact](/artifacts/eu/accessibility-act/products-and-services-in-scope.md): Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications. - [EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep](/artifacts/eu/accessibility-act/testing-and-conformance-evidence.md): Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements. - [EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness](/artifacts/eu/accessibility-act/deadlines-and-transition-plan.md): Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates. - [EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences](/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508.md): Compare the EU Accessibility Act with the ADA and Section 508 in practical terms. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/accessibility-act/requirements --- --- title: "EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep" canonical_url: "https://www.sorena.io/artifacts/eu/accessibility-act/testing-and-conformance-evidence" source_url: "https://www.sorena.io/artifacts/eu/accessibility-act/testing-and-conformance-evidence" author: "Sorena AI" description: "Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU Accessibility Act testing" - "accessibility conformance evidence" - "EAA evidence pack" - "Annex IV technical documentation" - "accessibility testing evidence" - "EN 301 549 testing" - "procurement accessibility evidence" - "market surveillance documentation" - "EU Accessibility Act" - "testing" - "conformance evidence" - "Annex IV" - "EN 301 549" - "accessibility statement" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Accessibility Act Testing and Conformance Evidence - What to Test and What to Keep Build a defensible EU Accessibility Act evidence pack with the right testing methods, release records, Annex IV documents, accessibility statements. *Artifact Guide* *EU* ## EU Accessibility Act Testing and Conformance Evidence A practical guide to the tests and evidence that make EU Accessibility Act work defensible across releases, procurement reviews, and regulatory challenge. The goal is not a giant archive. The goal is a clean, queryable record of scope, tests, findings, fixes, and approvals. Accessibility work becomes fragile when test results, remediation history, and formal documents live in different systems with no common index. Under the EU Accessibility Act, that fragmentation matters because procurement teams, customers, and authorities may ask different questions about the same offering. This page shows what an evidence pack should contain and how to keep it useful. ## What to test Testing should match the interfaces users actually rely on. That usually means a combination of automated checks, manual keyboard review, screen reader testing, zoom and reflow checks, colour and contrast review, media access review, and category specific hardware or communication testing where relevant. For services, test core user journeys first because they are where harm and abandonment show up fastest. For products, test the user interface, setup flow, instructions, packaging information where relevant, and any linked app or service needed to use the product. - Write one test plan per product or service surface with environments and assistive technologies listed. - Test critical tasks end to end, not only isolated components. - Retest after remediation and record version, date, and tester. - Keep known limitations visible so support and procurement teams are not surprised. ## What the evidence pack should contain For products, the evidence pack should align with Annex IV technical documentation and the declaration of conformity workflow. That means design and operation information, the standards or specifications applied in full or in part, and the records needed to assess conformity. For services, the pack should include scope records, requirement mappings, test methodology, findings, fixes, statement copies, and exception records. Keep the evidence indexed by offering and release. When someone asks whether a specific app version, checkout flow, or terminal model was assessed, the answer should be available in minutes, not reconstructed from chat messages and slide decks. - Maintain a dated requirement matrix, test plan, test reports, defect log, and remediation proof. - Store declarations, statements, and Article 14 assessments with version history. - Link procurement responses and customer facing claims back to the evidence that supports them. - Keep retention and access rules clear so records survive team changes and product sunsets. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Accessibility Act Testing and Conformance Evidence in one governed evidence system SSOT can take EU Accessibility Act Testing and Conformance Evidence from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Accessibility Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Accessibility Act Testing and Conformance Evidence](/solutions/ssot.md): Start from EU Accessibility Act Testing and Conformance Evidence and keep documents, evidence, and control records in one governed system. - [Talk through EU Accessibility Act](/contact.md): Review your current process, evidence gaps, and next steps for EU Accessibility Act Testing and Conformance Evidence. ## Primary sources - [European Accessibility Act (Directive (EU) 2019/882) - official text](https://eur-lex.europa.eu/eli/dir/2019/882/oj?ref=sorena.io) - Primary legal text for scope, Annex I requirements, Article 14 exceptions, Annex IV technical documentation, and market surveillance measures. - [European Commission - European Accessibility Act policy page](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en?ref=sorena.io) - Official implementation overview and policy context for the Act and its entry into application on 28 June 2025. - [AccessibleEU - Guidance on accessibility legislation in Europe](https://accessible-eu-centre.ec.europa.eu/guidelines-and-support-materials?ref=sorena.io) - Implementation guidance summarising covered products and services, practical obligations, and standard references for teams building compliance programmes. - [ETSI - EN 301 549 overview](https://www.etsi.org/human-factors-accessibility/en-301-549-v3-the-harmonized-european-standard-for-ict-accessibility?ref=sorena.io) - Official ETSI overview of EN 301 549, the European accessibility standard used to operationalise ICT requirements across web, software, hardware, documents, and communications. - [Commission Notice - Blue Guide on EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A52022XC0629%2804%29&ref=sorena.io) - Primary EU guidance on manufacturer, importer, distributor, declaration of conformity, CE marking, and market surveillance concepts. - [European Commission - Daily News on EAA application in June 2025](https://ec.europa.eu/commission/presscorner/detail/en/mex_25_1650?ref=sorena.io) - Official Commission notice confirming the entry into application on 28 June 2025. ## Related Topic Guides - [EN 301 549 and WCAG Mapping for the EU Accessibility Act - Practical Engineering Use](/artifacts/eu/accessibility-act/en-301-549-and-wcag-mapping.md): Map EU Accessibility Act requirements to EN 301 549 and WCAG in a practical way. - [EU Accessibility Act Accessibility Conformance Statement Template - Structure, Fields, and Evidence](/artifacts/eu/accessibility-act/accessibility-conformance-statement-template.md): Use this EU Accessibility Act accessibility conformance statement template to document product or service scope, standards used, test method. - [EU Accessibility Act Applicability Test - Scope, Roles, Dates, Exceptions, and Outputs](/artifacts/eu/accessibility-act/applicability-test.md): Use this EU Accessibility Act applicability test to decide whether your product or service is in scope, which operator role applies, what dates matter. - [EU Accessibility Act Compliance Checklist - Scope, Annex I, EN 301 549, and Evidence](/artifacts/eu/accessibility-act/checklist.md): Audit ready EU Accessibility Act compliance checklist for products and services. - [EU Accessibility Act Compliance Playbook - Operating Model, Controls, and Evidence](/artifacts/eu/accessibility-act/compliance.md): Build an EU Accessibility Act compliance programme with this practical playbook. - [EU Accessibility Act Deadlines and Compliance Calendar - 2022, 2025, Transition, and Review Dates](/artifacts/eu/accessibility-act/deadlines-and-compliance-calendar.md): Track the EU Accessibility Act dates that matter: transposition by 28 June 2022, application from 28 June 2025. - [EU Accessibility Act Exemptions and Disproportionate Burden - Article 14 Done Properly](/artifacts/eu/accessibility-act/exemptions-and-disproportionate-burden.md): Understand EU Accessibility Act exceptions correctly. - [EU Accessibility Act FAQ - Scope, Dates, Evidence, EN 301 549, and Exceptions](/artifacts/eu/accessibility-act/faq.md): Answer the practical questions teams ask about the EU Accessibility Act, including scope, dates, products and services covered, evidence, EN 301 549. - [EU Accessibility Act for E-Commerce Websites - Scope, Checkout, Product Pages, and Evidence](/artifacts/eu/accessibility-act/accessibility-act-for-ecommerce-websites.md): Detailed EU Accessibility Act guide for e-commerce websites and apps. - [EU Accessibility Act Penalties and Enforcement - Market Surveillance and Corrective Action Risk](/artifacts/eu/accessibility-act/penalties-and-fines.md): Understand EU Accessibility Act enforcement risk. Covers market surveillance powers, corrective action, restriction or withdrawal of non compliant products. - [EU Accessibility Act Procurement Language and Acceptance Criteria - Clauses Buyers Can Enforce](/artifacts/eu/accessibility-act/procurement-language-and-acceptance-criteria.md): Draft procurement ready accessibility language under the EU Accessibility Act. - [EU Accessibility Act Products and Services in Scope - Categories, Definitions, and Role Impact](/artifacts/eu/accessibility-act/products-and-services-in-scope.md): Detailed scope guide to the products and services covered by the EU Accessibility Act, including consumer hardware, self service terminals, communications. - [EU Accessibility Act Requirements - Annex I Outcomes, Role Duties, and Evidence Expectations](/artifacts/eu/accessibility-act/requirements.md): Detailed EU Accessibility Act requirements guide covering Annex I outcomes, product and service duties, EN 301 549 implementation. - [EU Accessibility Act Transition Plan - From Scope Review to 28 June 2025 Readiness](/artifacts/eu/accessibility-act/deadlines-and-transition-plan.md): Build a practical EU Accessibility Act transition plan with scoping, remediation, testing, procurement updates. - [EU Accessibility Act vs ADA and Section 508 - Scope, Evidence, and Delivery Differences](/artifacts/eu/accessibility-act/accessibility-act-vs-ada-and-section-508.md): Compare the EU Accessibility Act with the ADA and Section 508 in practical terms. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/accessibility-act/testing-and-conformance-evidence --- --- title: "EU AI Act Applicability and Roles" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/applicability-and-roles" source_url: "https://www.sorena.io/artifacts/eu/ai-act/applicability-and-roles" author: "Sorena AI" description: "Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer." keywords: - "EU AI Act applicability" - "EU AI Act roles" - "provider deployer importer distributor EU AI Act" - "authorised representative AI Act" - "output used in the Union AI Act" - "substantial modification AI Act" - "free and open source AI Act scope" - "EU AI Act" - "Applicability" - "Provider" - "Deployer" - "Importer" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Applicability and Roles Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. *EU AI Act* *Scoping guide* ## EU AI Act (Regulation (EU) 2024/1689) Applicability and roles Classify the system, then classify your role. Both decisions need evidence. This guide turns Article 2 scope and operator definitions into a practical role matrix for product, legal, procurement, and engineering teams. The most common AI Act failure is not a missed policy. It is a bad scoping record. Teams often know they use AI, but they cannot show which system was assessed, whether the output is used in the Union, who is the provider, and when a distributor or deployer becomes a provider because of branding or substantial modification. This page focuses on that first layer of compliance. ## When the EU AI Act applies Start with the unit you are assessing. Record the AI system or general purpose AI model, its intended purpose, the user group, the deployment context, and whether the output is intended to be used in the Union. Article 2 is wider than simple place of establishment. A provider or deployer outside the EU can still be in scope when the system output is intended for use in the Union. Also document the carve outs. The Act excludes AI used only for military, defence, or national security purposes, systems and models developed only for scientific research and development before market placement or service use, and certain free and open source releases. That open source carve out does not protect systems that fall under Article 5, Article 50, or high risk categories. - Record whether the system is placed on the market, put into service, or only tested in research settings. - Record whether output is used by an EU business process, customer, public body, or downstream integrator. - Document why an exclusion applies instead of assuming it does. - Set a retest trigger for new use cases, new geographies, major model upgrades, or new user claims. ## How to assign operator roles Assign roles per system and per use case. You may be a deployer for one internal workflow, a provider for a customer facing feature, and an importer or distributor for a third party system you place on the Union market. The role drives the evidence you must hold and the obligations you must perform. The provider role is not limited to the original developer. Under the Act, a distributor, importer, deployer, or another third party can become the provider if it puts its name or trademark on a high risk AI system, makes a substantial modification, or changes the intended purpose so that a previously non high risk system becomes high risk. - Provider: technical documentation, conformity work, quality management, post market monitoring, and system level instructions. - Deployer: use according to instructions, assign human oversight, keep logs under your control, perform FRIA where required, and inform affected persons in relevant Annex III decisions. - Importer and distributor: traceability, cooperation, and corrective action support. - Authorised representative: mandatory for certain non EU providers of high risk systems and GPAI providers established outside the Union. ## Role changes that teams often miss The role can change after launch. A fine tune that materially alters the intended purpose, a white label arrangement, or a substantial modification can shift responsibility. If your commercial model allows reselling or downstream customization, your contract and evidence model must anticipate that role shift. Product manufacturers also need attention. Where an AI system is a safety component of a product covered by Union harmonisation legislation, the product manufacturer may carry provider obligations for the embedded AI component. - Check whether your branding on a third party system makes you the provider in the Union chain. - Check whether post deployment learning or customer specific tuning changes the intended purpose. - Check whether a connected product route under Annex I changes who owns conformity work. - Check whether your procurement process captures the upstream model provider and the downstream system provider separately. ## Minimum evidence pack for applicability and roles A good scoping file is short, versioned, and attributable. It should show why the Act applies or does not apply, which exclusions were considered, which role each operator holds, and what event would force reassessment. This file is also the backbone for procurement, sales diligence, internal approvals, and regulator questions. Without it, later work on transparency, high risk controls, or GPAI obligations will drift. - AI register entry with intended purpose, geography, user group, owner, and last review date. - Role matrix naming provider, deployer, importer, distributor, and authorised representative where relevant. - Substantial modification and reclassification triggers with approvers. - Supplier clauses covering documentation, incident notice, version changes, and cooperation with authority requests. *Recommended next step* *Placement: after the applicability result* ## Use EU AI Act (Regulation (EU) 2024/1689) Applicability and roles as a cited research workflow Research Copilot can take EU AI Act (Regulation (EU) 2024/1689) Applicability and roles from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU AI Act (Regulation (EU) 2024/1689) Applicability and roles](/solutions/research-copilot.md): Start from EU AI Act (Regulation (EU) 2024/1689) Applicability and roles and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Applicability and roles. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - AI Act Explorer](https://ai-act-service-desk.ec.europa.eu/en/ai-act-explorer?ref=sorena.io) - Official article and annex navigator maintained for implementation support. - [European Commission - Decision establishing the European AI Office](https://digital-strategy.ec.europa.eu/en/library/commission-decision-establishing-european-ai-office?ref=sorena.io) - Official governance source for AI Office responsibilities. - [European Commission - AI Act enters into force on 1 August 2024](https://commission.europa.eu/news-and-media/news/ai-act-enters-force-2024-08-01_en?ref=sorena.io) - Commission implementation overview and key dates. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. ## Related Topic Guides - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/applicability-and-roles --- --- title: "EU AI Act Applicability and Roles" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/applicability-and-roles" source_url: "https://www.sorena.io/artifacts/eu/ai-act/applicability-and-roles" author: "Sorena AI" description: "Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer." keywords: - "EU AI Act applicability" - "EU AI Act roles" - "provider deployer importer distributor EU AI Act" - "authorised representative AI Act" - "output used in the Union AI Act" - "substantial modification AI Act" - "free and open source AI Act scope" - "EU AI Act" - "Applicability" - "Provider" - "Deployer" - "Importer" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Applicability and Roles Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. *EU AI Act* *Scoping guide* ## EU AI Act (Regulation (EU) 2024/1689) Applicability and roles Classify the system, then classify your role. Both decisions need evidence. This guide turns Article 2 scope and operator definitions into a practical role matrix for product, legal, procurement, and engineering teams. The most common AI Act failure is not a missed policy. It is a bad scoping record. Teams often know they use AI, but they cannot show which system was assessed, whether the output is used in the Union, who is the provider, and when a distributor or deployer becomes a provider because of branding or substantial modification. This page focuses on that first layer of compliance. ## When the EU AI Act applies Start with the unit you are assessing. Record the AI system or general purpose AI model, its intended purpose, the user group, the deployment context, and whether the output is intended to be used in the Union. Article 2 is wider than simple place of establishment. A provider or deployer outside the EU can still be in scope when the system output is intended for use in the Union. Also document the carve outs. The Act excludes AI used only for military, defence, or national security purposes, systems and models developed only for scientific research and development before market placement or service use, and certain free and open source releases. That open source carve out does not protect systems that fall under Article 5, Article 50, or high risk categories. - Record whether the system is placed on the market, put into service, or only tested in research settings. - Record whether output is used by an EU business process, customer, public body, or downstream integrator. - Document why an exclusion applies instead of assuming it does. - Set a retest trigger for new use cases, new geographies, major model upgrades, or new user claims. ## How to assign operator roles Assign roles per system and per use case. You may be a deployer for one internal workflow, a provider for a customer facing feature, and an importer or distributor for a third party system you place on the Union market. The role drives the evidence you must hold and the obligations you must perform. The provider role is not limited to the original developer. Under the Act, a distributor, importer, deployer, or another third party can become the provider if it puts its name or trademark on a high risk AI system, makes a substantial modification, or changes the intended purpose so that a previously non high risk system becomes high risk. - Provider: technical documentation, conformity work, quality management, post market monitoring, and system level instructions. - Deployer: use according to instructions, assign human oversight, keep logs under your control, perform FRIA where required, and inform affected persons in relevant Annex III decisions. - Importer and distributor: traceability, cooperation, and corrective action support. - Authorised representative: mandatory for certain non EU providers of high risk systems and GPAI providers established outside the Union. ## Role changes that teams often miss The role can change after launch. A fine tune that materially alters the intended purpose, a white label arrangement, or a substantial modification can shift responsibility. If your commercial model allows reselling or downstream customization, your contract and evidence model must anticipate that role shift. Product manufacturers also need attention. Where an AI system is a safety component of a product covered by Union harmonisation legislation, the product manufacturer may carry provider obligations for the embedded AI component. - Check whether your branding on a third party system makes you the provider in the Union chain. - Check whether post deployment learning or customer specific tuning changes the intended purpose. - Check whether a connected product route under Annex I changes who owns conformity work. - Check whether your procurement process captures the upstream model provider and the downstream system provider separately. ## Minimum evidence pack for applicability and roles A good scoping file is short, versioned, and attributable. It should show why the Act applies or does not apply, which exclusions were considered, which role each operator holds, and what event would force reassessment. This file is also the backbone for procurement, sales diligence, internal approvals, and regulator questions. Without it, later work on transparency, high risk controls, or GPAI obligations will drift. - AI register entry with intended purpose, geography, user group, owner, and last review date. - Role matrix naming provider, deployer, importer, distributor, and authorised representative where relevant. - Substantial modification and reclassification triggers with approvers. - Supplier clauses covering documentation, incident notice, version changes, and cooperation with authority requests. *Recommended next step* *Placement: after the applicability result* ## Use EU AI Act (Regulation (EU) 2024/1689) Applicability and roles as a cited research workflow Research Copilot can take EU AI Act (Regulation (EU) 2024/1689) Applicability and roles from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU AI Act (Regulation (EU) 2024/1689) Applicability and roles](/solutions/research-copilot.md): Start from EU AI Act (Regulation (EU) 2024/1689) Applicability and roles and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Applicability and roles. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - AI Act Explorer](https://ai-act-service-desk.ec.europa.eu/en/ai-act-explorer?ref=sorena.io) - Official article and annex navigator maintained for implementation support. - [European Commission - Decision establishing the European AI Office](https://digital-strategy.ec.europa.eu/en/library/commission-decision-establishing-european-ai-office?ref=sorena.io) - Official governance source for AI Office responsibilities. - [European Commission - AI Act enters into force on 1 August 2024](https://commission.europa.eu/news-and-media/news/ai-act-enters-force-2024-08-01_en?ref=sorena.io) - Commission implementation overview and key dates. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. ## Related Topic Guides - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/applicability-and-roles --- --- title: "EU AI Act Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/ai-act/applicability-test" author: "Sorena AI" description: "Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers." keywords: - "EU AI Act applicability test" - "EU AI Act scope test" - "AI Act high risk test" - "Article 5 test" - "Article 50 test" - "GPAI obligations test" - "output used in the Union AI Act" - "EU AI Act" - "Applicability test" - "High risk" - "Transparency" - "GPAI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Applicability Test Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. *EU AI Act* *Applicability test* ## EU AI Act (Regulation (EU) 2024/1689) Applicability test Run one intake test, then route the work to the right compliance track. This workflow is designed for product intake, change review, procurement, and launch governance. Treat applicability as a repeatable intake control, not an ad hoc legal memo. The test below is designed so that product, legal, security, procurement, and model teams can reach a documented answer using the same structure every time a new AI feature or model enters the portfolio. ## Step 1: define the object you are testing Assess each AI system and each general purpose AI model separately. A single product can contain multiple AI systems, multiple model suppliers, and multiple intended purposes. If you test the product at too high a level, you will miss obligations that attach only to one component. Capture intended purpose, target users, decision impact, deployment channel, and whether the output is intended to be used in the Union. That final point matters even when the provider or deployer sits outside the EU. - Name the system or model version under review. - Record the intended purpose in one sentence. - Record the business process or customer decision the output influences. - Record upstream model dependencies and any downstream resellers or integrators. ## Step 2: test exclusions before you classify obligations Check whether the system falls outside the Act because it is used only for military, defence, or national security purposes, or because it is still in pure research and development before being placed on the market or put into service. Document the reason and the evidence. Exclusions should be provable, not assumed. Check the free and open source position carefully. The broad open source carve out does not apply where the system is high risk or where Article 5 or Article 50 duties are triggered. Teams often over rely on open source language and miss downstream obligations. - Document the exclusion and the article basis. - Identify what event would end the exclusion, such as launch to customers or internal production use. - Flag any open source system that could still trigger prohibited practice, transparency, or high risk obligations. - Route mixed purpose systems for manual review where civilian and excluded uses overlap. ## Step 3: assign the operator role Decide whether you are acting as provider, deployer, importer, distributor, authorised representative, or product manufacturer for the specific system. You can hold more than one role in the same supply chain. The provider role can shift if you rebrand, substantially modify, or change intended purpose. If the system will be placed on the Union market by a provider outside the EU, check whether an authorised representative is required. If the system uses a third party model, split model provider obligations from system provider obligations. - Assign one accountable owner for each role decision. - Attach the procurement owner where a third party supplier is involved. - Record whether branding, white labelling, or substantial modification could shift provider status. - Record whether the product safety route under Annex I applies. ## Step 4: route to the right obligation layer Check prohibited practices first. If Article 5 is triggered, the right answer is stop, redesign, or narrow the use case before launch. If not prohibited, test high risk status under Article 6 and Annex III or the product safety route. Then check transparency under Article 50 and model level duties under Chapter V for GPAI. Do not treat these as mutually exclusive. A high risk system can also trigger transparency duties. A deployer using a third party GPAI model can still need upstream documentation to satisfy its own system level obligations. - Article 5 screen complete and signed off. - Article 6 and Annex III analysis complete, including any derogation analysis and profiling check. - Article 50 disclosure triggers and machine readable marking triggers mapped to product surfaces. - Chapter V check complete for any GPAI model provider or systemic risk scenario. ## Step 5: produce the minimum decision record The output of the test should be a one page decision record with links to evidence, not a vague conclusion. It should show the system or model, article triggers considered, outcome, owner, date, sources used, and the next review trigger. This record should be stored where release, procurement, and governance teams can actually find it. A hidden spreadsheet is not an effective compliance control. - Outcome field: out of scope, prohibited, high risk, transparency only, GPAI provider, or mixed case. - Evidence links: architecture note, supplier docs, policy approvals, and release gate outcome. - Review triggers: new geography, new model, new intended purpose, substantial modification, or major incident. - Approvals: product owner, legal or compliance reviewer, and security or risk reviewer where required. *Recommended next step* *Placement: after the applicability result* ## Turn EU AI Act (Regulation (EU) 2024/1689) Applicability test into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) Applicability test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) Applicability test](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) Applicability test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Applicability test. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - AI Act Explorer](https://ai-act-service-desk.ec.europa.eu/en/ai-act-explorer?ref=sorena.io) - Official article and annex navigator maintained for implementation support. - [AI Act Service Desk - Annex III high risk use cases](https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3?ref=sorena.io) - Official annex landing page for high risk use cases. - [AI Act Service Desk - Article 50 transparency obligations](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50?ref=sorena.io) - Official support page for interaction, disclosure, and deepfake duties. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/applicability-test --- --- title: "EU AI Act Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/ai-act/applicability-test" author: "Sorena AI" description: "Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers." keywords: - "EU AI Act applicability test" - "EU AI Act scope test" - "AI Act high risk test" - "Article 5 test" - "Article 50 test" - "GPAI obligations test" - "output used in the Union AI Act" - "EU AI Act" - "Applicability test" - "High risk" - "Transparency" - "GPAI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Applicability Test Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. *EU AI Act* *Applicability test* ## EU AI Act (Regulation (EU) 2024/1689) Applicability test Run one intake test, then route the work to the right compliance track. This workflow is designed for product intake, change review, procurement, and launch governance. Treat applicability as a repeatable intake control, not an ad hoc legal memo. The test below is designed so that product, legal, security, procurement, and model teams can reach a documented answer using the same structure every time a new AI feature or model enters the portfolio. ## Step 1: define the object you are testing Assess each AI system and each general purpose AI model separately. A single product can contain multiple AI systems, multiple model suppliers, and multiple intended purposes. If you test the product at too high a level, you will miss obligations that attach only to one component. Capture intended purpose, target users, decision impact, deployment channel, and whether the output is intended to be used in the Union. That final point matters even when the provider or deployer sits outside the EU. - Name the system or model version under review. - Record the intended purpose in one sentence. - Record the business process or customer decision the output influences. - Record upstream model dependencies and any downstream resellers or integrators. ## Step 2: test exclusions before you classify obligations Check whether the system falls outside the Act because it is used only for military, defence, or national security purposes, or because it is still in pure research and development before being placed on the market or put into service. Document the reason and the evidence. Exclusions should be provable, not assumed. Check the free and open source position carefully. The broad open source carve out does not apply where the system is high risk or where Article 5 or Article 50 duties are triggered. Teams often over rely on open source language and miss downstream obligations. - Document the exclusion and the article basis. - Identify what event would end the exclusion, such as launch to customers or internal production use. - Flag any open source system that could still trigger prohibited practice, transparency, or high risk obligations. - Route mixed purpose systems for manual review where civilian and excluded uses overlap. ## Step 3: assign the operator role Decide whether you are acting as provider, deployer, importer, distributor, authorised representative, or product manufacturer for the specific system. You can hold more than one role in the same supply chain. The provider role can shift if you rebrand, substantially modify, or change intended purpose. If the system will be placed on the Union market by a provider outside the EU, check whether an authorised representative is required. If the system uses a third party model, split model provider obligations from system provider obligations. - Assign one accountable owner for each role decision. - Attach the procurement owner where a third party supplier is involved. - Record whether branding, white labelling, or substantial modification could shift provider status. - Record whether the product safety route under Annex I applies. ## Step 4: route to the right obligation layer Check prohibited practices first. If Article 5 is triggered, the right answer is stop, redesign, or narrow the use case before launch. If not prohibited, test high risk status under Article 6 and Annex III or the product safety route. Then check transparency under Article 50 and model level duties under Chapter V for GPAI. Do not treat these as mutually exclusive. A high risk system can also trigger transparency duties. A deployer using a third party GPAI model can still need upstream documentation to satisfy its own system level obligations. - Article 5 screen complete and signed off. - Article 6 and Annex III analysis complete, including any derogation analysis and profiling check. - Article 50 disclosure triggers and machine readable marking triggers mapped to product surfaces. - Chapter V check complete for any GPAI model provider or systemic risk scenario. ## Step 5: produce the minimum decision record The output of the test should be a one page decision record with links to evidence, not a vague conclusion. It should show the system or model, article triggers considered, outcome, owner, date, sources used, and the next review trigger. This record should be stored where release, procurement, and governance teams can actually find it. A hidden spreadsheet is not an effective compliance control. - Outcome field: out of scope, prohibited, high risk, transparency only, GPAI provider, or mixed case. - Evidence links: architecture note, supplier docs, policy approvals, and release gate outcome. - Review triggers: new geography, new model, new intended purpose, substantial modification, or major incident. - Approvals: product owner, legal or compliance reviewer, and security or risk reviewer where required. *Recommended next step* *Placement: after the applicability result* ## Turn EU AI Act (Regulation (EU) 2024/1689) Applicability test into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) Applicability test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) Applicability test](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) Applicability test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Applicability test. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - AI Act Explorer](https://ai-act-service-desk.ec.europa.eu/en/ai-act-explorer?ref=sorena.io) - Official article and annex navigator maintained for implementation support. - [AI Act Service Desk - Annex III high risk use cases](https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3?ref=sorena.io) - Official annex landing page for high risk use cases. - [AI Act Service Desk - Article 50 transparency obligations](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50?ref=sorena.io) - Official support page for interaction, disclosure, and deepfake duties. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/applicability-test --- --- title: "EU AI Act Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/checklist" source_url: "https://www.sorena.io/artifacts/eu/ai-act/checklist" author: "Sorena AI" description: "Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging." keywords: - "EU AI Act checklist" - "AI Act compliance checklist" - "Article 5 checklist" - "Article 50 checklist" - "high risk AI checklist" - "GPAI checklist" - "Annex IV checklist" - "EU AI Act" - "Checklist" - "High risk" - "Article 50" - "GPAI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Checklist Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. *EU AI Act* *Checklist* ## EU AI Act (Regulation (EU) 2024/1689) Compliance checklist A useful checklist is a list of outputs, owners, and review points. This checklist is structured so teams can move from scoping to evidence instead of collecting generic policy language. The AI Act does not reward broad statements about responsible AI. It rewards accurate classification, complete evidence, and operating controls that still work after launch. Use this checklist by system and by model, then track gaps in the same delivery tooling you use for security and product work. ## Portfolio and scoping foundation Before you touch technical controls, make sure the system is registered, scoped, and assigned to the right role owners. Every later obligation depends on this layer being correct. This is also the point where many teams catch shadow AI use, unapproved model APIs, and downstream resale arrangements that were never reflected in the compliance record. - AI system register complete with intended purpose, owner, deployment context, and model dependencies. - Role matrix complete for provider, deployer, importer, distributor, and authorised representative where relevant. - Exclusions and open source position documented with article basis. - Reassessment triggers documented for model changes, new uses, and substantial modification. ## Article 5 and AI literacy controls The earliest live obligations are not optional extras. Prohibited practice screening and AI literacy should be operating controls, not one time training slides. The screening outcome should be attached to release approvals and high impact design reviews. - Article 5 screening completed before launch and on material changes. - Escalation path exists for manipulative techniques, vulnerability exploitation, prohibited biometrics, and social scoring concerns. - Article 4 AI literacy training is assigned to product, operations, support, and oversight roles. - Training completion and role specific guidance are retained as evidence. ## High risk system controls If a system is high risk, the evidence standard changes completely. You need a lifecycle assurance set built around Articles 9 to 15 and the provider and deployer duties that sit around them. Do not stop at a risk register. High risk evidence has to cover technical documentation, human oversight, logging, post market monitoring, and authority facing records. - Article 9 risk management system documented and maintained across the lifecycle. - Article 10 data governance controls and data quality evidence complete. - Article 11 Annex IV technical documentation plan complete and version linked to releases. - Articles 12 to 15 logging, instructions, human oversight, accuracy, robustness, and cybersecurity controls evidenced. - FRIA, affected person notices, EU database registration, conformity route, and CE marking checked where applicable. ## Transparency and user disclosure controls Article 50 work belongs in product delivery, content operations, accessibility review, and analytics. If users interact with AI or receive synthetic content, the disclosure logic must be built into the interface and into the release process. Where machine readable marking is required, product teams should treat it as a technical feature with QA evidence, not as marketing copy. - Direct interaction notices mapped to all relevant product surfaces. - Synthetic image, audio, video, and text marking triggers documented. - Deepfake and public interest publication disclosures reviewed with editorial owners. - Display evidence, screenshots, and privacy minimised logging retained. ## GPAI provider and supplier controls Chapter V applies at model level. If you provide a GPAI model, you need technical documentation, downstream information, a copyright policy, and a public summary of training content. If you rely on a third party GPAI provider, you need contract and evidence demands that let your system level compliance continue to work. Systemic risk scenarios need a higher state of readiness because notification, safety and security, and serious incident reporting duties tighten. - Article 53 technical documentation and downstream documentation workflow in place. - Copyright policy maintained and linked to data sourcing governance. - Public summary of training content prepared using the AI Office template where required. - Article 52 systemic risk notification path and Article 55 serious incident reporting process defined. - Supplier clauses require version notices, technical documentation extracts, and incident cooperation. ## Authority ready evidence pack Your final test is simple: if a buyer, regulator, or partner asks for evidence tomorrow, can you produce a coherent file without rebuilding the story from scratch? The evidence pack should be kept current and tied to actual versions, not abstract program material. - Decision records for applicability, high risk status, transparency, and GPAI duties. - Release linked technical documentation, instructions, and test records. - Incident, complaint, and corrective action workflow records. - Named owners, last review dates, and next review triggers for every major artifact. *Recommended next step* *Placement: after the checklist block* ## Turn EU AI Act (Regulation (EU) 2024/1689) Compliance checklist into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) Compliance checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) Compliance checklist](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) Compliance checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Compliance checklist. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Implementation timeline](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act?ref=sorena.io) - Official staging reference for phased application dates. - [AI Act Service Desk - Article 50 transparency obligations](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50?ref=sorena.io) - Official support page for interaction, disclosure, and deepfake duties. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. - [European Commission - Explanatory notice and template for the public summary of training content](https://digital-strategy.ec.europa.eu/en/library/explanatory-notice-and-template-public-summary-training-content-general-purpose-ai-models?ref=sorena.io) - Official Article 53(1)(d) template and implementation notice. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/checklist --- --- title: "EU AI Act Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/checklist" source_url: "https://www.sorena.io/artifacts/eu/ai-act/checklist" author: "Sorena AI" description: "Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging." keywords: - "EU AI Act checklist" - "AI Act compliance checklist" - "Article 5 checklist" - "Article 50 checklist" - "high risk AI checklist" - "GPAI checklist" - "Annex IV checklist" - "EU AI Act" - "Checklist" - "High risk" - "Article 50" - "GPAI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Checklist Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. *EU AI Act* *Checklist* ## EU AI Act (Regulation (EU) 2024/1689) Compliance checklist A useful checklist is a list of outputs, owners, and review points. This checklist is structured so teams can move from scoping to evidence instead of collecting generic policy language. The AI Act does not reward broad statements about responsible AI. It rewards accurate classification, complete evidence, and operating controls that still work after launch. Use this checklist by system and by model, then track gaps in the same delivery tooling you use for security and product work. ## Portfolio and scoping foundation Before you touch technical controls, make sure the system is registered, scoped, and assigned to the right role owners. Every later obligation depends on this layer being correct. This is also the point where many teams catch shadow AI use, unapproved model APIs, and downstream resale arrangements that were never reflected in the compliance record. - AI system register complete with intended purpose, owner, deployment context, and model dependencies. - Role matrix complete for provider, deployer, importer, distributor, and authorised representative where relevant. - Exclusions and open source position documented with article basis. - Reassessment triggers documented for model changes, new uses, and substantial modification. ## Article 5 and AI literacy controls The earliest live obligations are not optional extras. Prohibited practice screening and AI literacy should be operating controls, not one time training slides. The screening outcome should be attached to release approvals and high impact design reviews. - Article 5 screening completed before launch and on material changes. - Escalation path exists for manipulative techniques, vulnerability exploitation, prohibited biometrics, and social scoring concerns. - Article 4 AI literacy training is assigned to product, operations, support, and oversight roles. - Training completion and role specific guidance are retained as evidence. ## High risk system controls If a system is high risk, the evidence standard changes completely. You need a lifecycle assurance set built around Articles 9 to 15 and the provider and deployer duties that sit around them. Do not stop at a risk register. High risk evidence has to cover technical documentation, human oversight, logging, post market monitoring, and authority facing records. - Article 9 risk management system documented and maintained across the lifecycle. - Article 10 data governance controls and data quality evidence complete. - Article 11 Annex IV technical documentation plan complete and version linked to releases. - Articles 12 to 15 logging, instructions, human oversight, accuracy, robustness, and cybersecurity controls evidenced. - FRIA, affected person notices, EU database registration, conformity route, and CE marking checked where applicable. ## Transparency and user disclosure controls Article 50 work belongs in product delivery, content operations, accessibility review, and analytics. If users interact with AI or receive synthetic content, the disclosure logic must be built into the interface and into the release process. Where machine readable marking is required, product teams should treat it as a technical feature with QA evidence, not as marketing copy. - Direct interaction notices mapped to all relevant product surfaces. - Synthetic image, audio, video, and text marking triggers documented. - Deepfake and public interest publication disclosures reviewed with editorial owners. - Display evidence, screenshots, and privacy minimised logging retained. ## GPAI provider and supplier controls Chapter V applies at model level. If you provide a GPAI model, you need technical documentation, downstream information, a copyright policy, and a public summary of training content. If you rely on a third party GPAI provider, you need contract and evidence demands that let your system level compliance continue to work. Systemic risk scenarios need a higher state of readiness because notification, safety and security, and serious incident reporting duties tighten. - Article 53 technical documentation and downstream documentation workflow in place. - Copyright policy maintained and linked to data sourcing governance. - Public summary of training content prepared using the AI Office template where required. - Article 52 systemic risk notification path and Article 55 serious incident reporting process defined. - Supplier clauses require version notices, technical documentation extracts, and incident cooperation. ## Authority ready evidence pack Your final test is simple: if a buyer, regulator, or partner asks for evidence tomorrow, can you produce a coherent file without rebuilding the story from scratch? The evidence pack should be kept current and tied to actual versions, not abstract program material. - Decision records for applicability, high risk status, transparency, and GPAI duties. - Release linked technical documentation, instructions, and test records. - Incident, complaint, and corrective action workflow records. - Named owners, last review dates, and next review triggers for every major artifact. *Recommended next step* *Placement: after the checklist block* ## Turn EU AI Act (Regulation (EU) 2024/1689) Compliance checklist into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) Compliance checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) Compliance checklist](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) Compliance checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Compliance checklist. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Implementation timeline](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act?ref=sorena.io) - Official staging reference for phased application dates. - [AI Act Service Desk - Article 50 transparency obligations](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50?ref=sorena.io) - Official support page for interaction, disclosure, and deepfake duties. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. - [European Commission - Explanatory notice and template for the public summary of training content](https://digital-strategy.ec.europa.eu/en/library/explanatory-notice-and-template-public-summary-training-content-general-purpose-ai-models?ref=sorena.io) - Official Article 53(1)(d) template and implementation notice. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/checklist --- --- title: "EU AI Act Compliance Program" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/compliance" source_url: "https://www.sorena.io/artifacts/eu/ai-act/compliance" author: "Sorena AI" description: "Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work." keywords: - "EU AI Act compliance program" - "AI Act implementation program" - "AI Act governance" - "AI Act operating model" - "EU AI Act post market monitoring" - "EU AI Act evidence pack" - "EU AI Act" - "Compliance program" - "Governance" - "High risk" - "GPAI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Compliance Program Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. *EU AI Act* *Operating model* ## EU AI Act (Regulation (EU) 2024/1689) Compliance program A workable AI Act program connects legal duties to product delivery and operations. This page sets out how to structure governance, owners, evidence, and steady state reviews so compliance survives beyond one launch cycle. A publication grade AI Act program is not a single policy and it is not only for legal teams. It is a cross functional operating model that decides scope, classifies obligations, turns those obligations into build work, and then keeps the resulting evidence current as systems, models, and markets change. ## Program architecture Build the program around a shared AI inventory, a role matrix, and a classification workflow. Every system and model should move through the same logic: scope, Article 5 screening, high risk analysis, transparency analysis, GPAI analysis, and release controls. Make one team accountable for the operating model, but keep execution distributed. Product owns intended purpose and release. Engineering owns implementation and evidence. Security owns threat and resilience controls. Legal and compliance own classification review and authority response. - Single AI register across products, internal tools, and supplier dependencies. - Formal review forum for ambiguous scope and classification decisions. - Named owner for each evidence artifact and each release gate. - Escalation path for prohibited practice, systemic risk, serious incident, and authority notice events. ## Phasing by legal date The dates matter because the obligation mix changes over time. Entry into force was 1 August 2024. From 2 February 2025, the general provisions, prohibited practices, and AI literacy requirements apply. From 2 August 2025, Chapter V for GPAI, governance provisions, and penalties provisions begin to matter. The main application date is 2 August 2026, with later special dates for some product safety and transition scenarios. A mature program turns each date into deliverables. That means owners, acceptance criteria, artifact templates, and review calendars tied to the applicable phase. - Before 2 February 2025: inventory, Article 5 gate, AI literacy, and role mapping live. - Before 2 August 2025: GPAI provider workflow, AI Office readiness, and supplier evidence demands live. - Before 2 August 2026: high risk system controls, FRIA process, and transparency product components live. - Before 2 August 2027 and 31 December 2030: transition cases tracked and revalidated. ## Core control stack The control stack should be simple to describe and strong enough to survive challenge. The minimum set is inventory, classification, approvals, evidence retention, incident response, corrective action, and recurring review. Everything else should attach to those foundations. Where possible, connect the AI Act program to existing release, security, procurement, and audit processes. Standalone AI governance tools often fail because they drift away from the systems that actually govern shipping. - Release gate for Article 5, Article 50, and high risk checks. - Supplier onboarding gate for model level documentation and incident terms. - Evidence repository with version control and retention logic. - Complaint, redress, and serious incident handling flow with named responders. - Quarterly review of system changes, model upgrades, and open findings. ## High risk and GPAI specialist workstreams Some systems need deeper specialist tracks. High risk systems need Annex IV planning, conformity work, human oversight design, logging design, post market monitoring, and, in certain contexts, FRIA and EU database registration. GPAI providers need model level documentation, copyright policy, training content summary publication, and systemic risk response readiness. Do not bury these specialist tracks inside generic AI governance. They need named SMEs, templates, and evidence standards of their own. - High risk workstream with provider and deployer playbooks. - GPAI workstream with Article 53 to 55 artifact templates. - Transparency workstream with design system components and QA evidence standards. - Authority response workstream for requests, market surveillance, and corrective action. ## What good program evidence looks like A strong program can prove both design intent and actual operation. That means training records, meeting outcomes, release gates, technical documentation, and monitoring results all point to the same current system state. If your evidence is only narrative and not version linked, your program will look stronger on paper than it is in practice. - Current inventory and role assignments. - Decision records and signed approvals for major classification outcomes. - Version linked product and model evidence, including release notes and test outputs. - Incident and corrective action records that show the program is operating, not dormant. *Recommended next step* *Placement: after the compliance steps* ## Turn EU AI Act (Regulation (EU) 2024/1689) Compliance program into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) Compliance program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) Compliance program](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) Compliance program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Compliance program. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Implementation timeline](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act?ref=sorena.io) - Official staging reference for phased application dates. - [European Commission - Decision establishing the European AI Office](https://digital-strategy.ec.europa.eu/en/library/commission-decision-establishing-european-ai-office?ref=sorena.io) - Official governance source for AI Office responsibilities. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. - [European Commission - AI Act enters into force on 1 August 2024](https://commission.europa.eu/news-and-media/news/ai-act-enters-force-2024-08-01_en?ref=sorena.io) - Commission implementation overview and key dates. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/compliance --- --- title: "EU AI Act Compliance Program" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/compliance" source_url: "https://www.sorena.io/artifacts/eu/ai-act/compliance" author: "Sorena AI" description: "Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work." keywords: - "EU AI Act compliance program" - "AI Act implementation program" - "AI Act governance" - "AI Act operating model" - "EU AI Act post market monitoring" - "EU AI Act evidence pack" - "EU AI Act" - "Compliance program" - "Governance" - "High risk" - "GPAI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Compliance Program Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. *EU AI Act* *Operating model* ## EU AI Act (Regulation (EU) 2024/1689) Compliance program A workable AI Act program connects legal duties to product delivery and operations. This page sets out how to structure governance, owners, evidence, and steady state reviews so compliance survives beyond one launch cycle. A publication grade AI Act program is not a single policy and it is not only for legal teams. It is a cross functional operating model that decides scope, classifies obligations, turns those obligations into build work, and then keeps the resulting evidence current as systems, models, and markets change. ## Program architecture Build the program around a shared AI inventory, a role matrix, and a classification workflow. Every system and model should move through the same logic: scope, Article 5 screening, high risk analysis, transparency analysis, GPAI analysis, and release controls. Make one team accountable for the operating model, but keep execution distributed. Product owns intended purpose and release. Engineering owns implementation and evidence. Security owns threat and resilience controls. Legal and compliance own classification review and authority response. - Single AI register across products, internal tools, and supplier dependencies. - Formal review forum for ambiguous scope and classification decisions. - Named owner for each evidence artifact and each release gate. - Escalation path for prohibited practice, systemic risk, serious incident, and authority notice events. ## Phasing by legal date The dates matter because the obligation mix changes over time. Entry into force was 1 August 2024. From 2 February 2025, the general provisions, prohibited practices, and AI literacy requirements apply. From 2 August 2025, Chapter V for GPAI, governance provisions, and penalties provisions begin to matter. The main application date is 2 August 2026, with later special dates for some product safety and transition scenarios. A mature program turns each date into deliverables. That means owners, acceptance criteria, artifact templates, and review calendars tied to the applicable phase. - Before 2 February 2025: inventory, Article 5 gate, AI literacy, and role mapping live. - Before 2 August 2025: GPAI provider workflow, AI Office readiness, and supplier evidence demands live. - Before 2 August 2026: high risk system controls, FRIA process, and transparency product components live. - Before 2 August 2027 and 31 December 2030: transition cases tracked and revalidated. ## Core control stack The control stack should be simple to describe and strong enough to survive challenge. The minimum set is inventory, classification, approvals, evidence retention, incident response, corrective action, and recurring review. Everything else should attach to those foundations. Where possible, connect the AI Act program to existing release, security, procurement, and audit processes. Standalone AI governance tools often fail because they drift away from the systems that actually govern shipping. - Release gate for Article 5, Article 50, and high risk checks. - Supplier onboarding gate for model level documentation and incident terms. - Evidence repository with version control and retention logic. - Complaint, redress, and serious incident handling flow with named responders. - Quarterly review of system changes, model upgrades, and open findings. ## High risk and GPAI specialist workstreams Some systems need deeper specialist tracks. High risk systems need Annex IV planning, conformity work, human oversight design, logging design, post market monitoring, and, in certain contexts, FRIA and EU database registration. GPAI providers need model level documentation, copyright policy, training content summary publication, and systemic risk response readiness. Do not bury these specialist tracks inside generic AI governance. They need named SMEs, templates, and evidence standards of their own. - High risk workstream with provider and deployer playbooks. - GPAI workstream with Article 53 to 55 artifact templates. - Transparency workstream with design system components and QA evidence standards. - Authority response workstream for requests, market surveillance, and corrective action. ## What good program evidence looks like A strong program can prove both design intent and actual operation. That means training records, meeting outcomes, release gates, technical documentation, and monitoring results all point to the same current system state. If your evidence is only narrative and not version linked, your program will look stronger on paper than it is in practice. - Current inventory and role assignments. - Decision records and signed approvals for major classification outcomes. - Version linked product and model evidence, including release notes and test outputs. - Incident and corrective action records that show the program is operating, not dormant. *Recommended next step* *Placement: after the compliance steps* ## Turn EU AI Act (Regulation (EU) 2024/1689) Compliance program into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) Compliance program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) Compliance program](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) Compliance program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Compliance program. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Implementation timeline](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act?ref=sorena.io) - Official staging reference for phased application dates. - [European Commission - Decision establishing the European AI Office](https://digital-strategy.ec.europa.eu/en/library/commission-decision-establishing-european-ai-office?ref=sorena.io) - Official governance source for AI Office responsibilities. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. - [European Commission - AI Act enters into force on 1 August 2024](https://commission.europa.eu/news-and-media/news/ai-act-enters-force-2024-08-01_en?ref=sorena.io) - Commission implementation overview and key dates. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/compliance --- --- title: "EU AI Act Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/ai-act/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025." keywords: - "EU AI Act deadlines" - "EU AI Act calendar" - "2 February 2025 AI Act" - "2 August 2025 AI Act" - "2 August 2026 AI Act" - "2 August 2027 GPAI deadline" - "31 December 2030 AI Act" - "EU AI Act" - "Deadlines" - "Timeline" - "GPAI" - "High risk" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Deadlines and Compliance Calendar Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. *EU AI Act* *Calendar* ## EU AI Act (Regulation (EU) 2024/1689) Deadlines and calendar Use the legal dates to plan real work, not to build a passive timeline. Each milestone below includes the practical deliverables that should be complete by that date. The AI Act is phased. If your program treats 2 August 2026 as the only relevant date, you will miss early obligations and transition rules that already shape what teams should be doing. This calendar translates Article 113 and Article 111 into a delivery sequence. ## 1 August 2024: entry into force The Regulation entered into force on 1 August 2024. This was the correct point to launch inventory, role mapping, budget planning, and portfolio triage. Teams that waited for later dates often lost a year of preparation time. Program level work should already have started here even if the main body of obligations applied later. - Create the AI system and model inventory. - Set the owner model and approval forum. - Identify likely Article 5, Annex III, and GPAI exposure. - Build the evidence repository and template set. ## 2 February 2025: prohibitions and general provisions apply From 2 February 2025, the general provisions and the prohibited practices framework apply. This is also the point at which Article 4 AI literacy becomes a live obligation. Release controls should therefore be active before this date, not after it. If your program cannot show Article 5 screening and role based AI literacy from this date forward, it will look immature even if later controls are strong. - Article 5 screening gate live in product and model review. - AI literacy content assigned by role and retained as evidence. - Escalation owners named for high impact or ambiguous use cases. - Board or executive reporting established for material findings. ## 2 August 2025: GPAI rules, governance, and penalties provisions become active Chapter V obligations for providers of general purpose AI models apply from 2 August 2025. Governance provisions, notified body and authority setup, and penalties provisions also begin around this phase. For GPAI providers, this is the date by which Article 53 obligations become operational, even though Commission enforcement powers on fines start later. Providers of models that meet the systemic risk threshold need notification readiness without delay and in any event within two weeks after the threshold is met or known to be met. - GPAI technical documentation and downstream documentation workflow live. - Copyright policy and training content summary process live. - Systemic risk threshold monitoring and notification process live. - Supplier contract refresh completed for downstream integrators. ## 2 August 2026: main application date This is the main application date for most of the Regulation. By this point, high risk system controls, transparency components, deployer operating procedures, and authority ready evidence should all be functioning. Commission enforcement powers for GPAI providers also start from this date. If a GPAI provider is not compliant on 2 August 2026, the first year of grace on enforcement is over. - High risk Articles 9 to 15 controls evidenced. - FRIA process active for the deployers that must perform it. - Article 50 disclosures and machine readable marking in production. - Incident, complaint, and corrective action workflows tested. ## 2 August 2027 and 31 December 2030: transition deadlines Article 111 creates later deadlines for specific legacy cases. Providers of GPAI models placed on the market before 2 August 2025 must comply by 2 August 2027. Article 6(1) obligations tied to certain product safety routes also apply from 2 August 2027. Large scale IT systems listed in Annex X and certain public authority deployments have longer transition periods, with some compliance reaching 31 December 2030. These later dates are not excuses to delay current portfolio review. They are tracking duties for transitional cases that should already be named and monitored. - Register every legacy GPAI model and assign a 2027 remediation plan. - Track public authority high risk systems that must comply by 2 August 2030. - Track Annex X large scale IT systems with the 31 December 2030 date. - Reassess any pre 2026 high risk system once significant design changes occur. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU AI Act (Regulation (EU) 2024/1689) Deadlines and calendar into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) Deadlines and calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) Deadlines and calendar](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) Deadlines and calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Deadlines and calendar. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Implementation timeline](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act?ref=sorena.io) - Official staging reference for phased application dates. - [European Commission - AI Act enters into force on 1 August 2024](https://commission.europa.eu/news-and-media/news/ai-act-enters-force-2024-08-01_en?ref=sorena.io) - Commission implementation overview and key dates. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/deadlines-and-compliance-calendar --- --- title: "EU AI Act Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/ai-act/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025." keywords: - "EU AI Act deadlines" - "EU AI Act calendar" - "2 February 2025 AI Act" - "2 August 2025 AI Act" - "2 August 2026 AI Act" - "2 August 2027 GPAI deadline" - "31 December 2030 AI Act" - "EU AI Act" - "Deadlines" - "Timeline" - "GPAI" - "High risk" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Deadlines and Compliance Calendar Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. *EU AI Act* *Calendar* ## EU AI Act (Regulation (EU) 2024/1689) Deadlines and calendar Use the legal dates to plan real work, not to build a passive timeline. Each milestone below includes the practical deliverables that should be complete by that date. The AI Act is phased. If your program treats 2 August 2026 as the only relevant date, you will miss early obligations and transition rules that already shape what teams should be doing. This calendar translates Article 113 and Article 111 into a delivery sequence. ## 1 August 2024: entry into force The Regulation entered into force on 1 August 2024. This was the correct point to launch inventory, role mapping, budget planning, and portfolio triage. Teams that waited for later dates often lost a year of preparation time. Program level work should already have started here even if the main body of obligations applied later. - Create the AI system and model inventory. - Set the owner model and approval forum. - Identify likely Article 5, Annex III, and GPAI exposure. - Build the evidence repository and template set. ## 2 February 2025: prohibitions and general provisions apply From 2 February 2025, the general provisions and the prohibited practices framework apply. This is also the point at which Article 4 AI literacy becomes a live obligation. Release controls should therefore be active before this date, not after it. If your program cannot show Article 5 screening and role based AI literacy from this date forward, it will look immature even if later controls are strong. - Article 5 screening gate live in product and model review. - AI literacy content assigned by role and retained as evidence. - Escalation owners named for high impact or ambiguous use cases. - Board or executive reporting established for material findings. ## 2 August 2025: GPAI rules, governance, and penalties provisions become active Chapter V obligations for providers of general purpose AI models apply from 2 August 2025. Governance provisions, notified body and authority setup, and penalties provisions also begin around this phase. For GPAI providers, this is the date by which Article 53 obligations become operational, even though Commission enforcement powers on fines start later. Providers of models that meet the systemic risk threshold need notification readiness without delay and in any event within two weeks after the threshold is met or known to be met. - GPAI technical documentation and downstream documentation workflow live. - Copyright policy and training content summary process live. - Systemic risk threshold monitoring and notification process live. - Supplier contract refresh completed for downstream integrators. ## 2 August 2026: main application date This is the main application date for most of the Regulation. By this point, high risk system controls, transparency components, deployer operating procedures, and authority ready evidence should all be functioning. Commission enforcement powers for GPAI providers also start from this date. If a GPAI provider is not compliant on 2 August 2026, the first year of grace on enforcement is over. - High risk Articles 9 to 15 controls evidenced. - FRIA process active for the deployers that must perform it. - Article 50 disclosures and machine readable marking in production. - Incident, complaint, and corrective action workflows tested. ## 2 August 2027 and 31 December 2030: transition deadlines Article 111 creates later deadlines for specific legacy cases. Providers of GPAI models placed on the market before 2 August 2025 must comply by 2 August 2027. Article 6(1) obligations tied to certain product safety routes also apply from 2 August 2027. Large scale IT systems listed in Annex X and certain public authority deployments have longer transition periods, with some compliance reaching 31 December 2030. These later dates are not excuses to delay current portfolio review. They are tracking duties for transitional cases that should already be named and monitored. - Register every legacy GPAI model and assign a 2027 remediation plan. - Track public authority high risk systems that must comply by 2 August 2030. - Track Annex X large scale IT systems with the 31 December 2030 date. - Reassess any pre 2026 high risk system once significant design changes occur. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU AI Act (Regulation (EU) 2024/1689) Deadlines and calendar into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) Deadlines and calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) Deadlines and calendar](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) Deadlines and calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Deadlines and calendar. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Implementation timeline](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act?ref=sorena.io) - Official staging reference for phased application dates. - [European Commission - AI Act enters into force on 1 August 2024](https://commission.europa.eu/news-and-media/news/ai-act-enters-force-2024-08-01_en?ref=sorena.io) - Commission implementation overview and key dates. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/deadlines-and-compliance-calendar --- --- title: "EU AI Act vs ISO 42001" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001" source_url: "https://www.sorena.io/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001" author: "Sorena AI" description: "Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information." keywords: - "EU AI Act vs ISO 42001" - "ISO 42001 AI Act mapping" - "ISO 42001 compliance EU AI Act" - "AI management system vs AI regulation" - "ISO 42001 Article 50 Annex III Article 53" - "EU AI Act" - "ISO 42001" - "AI management system" - "Governance" - "Compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act vs ISO 42001 Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. *EU AI Act* *Comparison* ## EU AI Act (Regulation (EU) 2024/1689) EU AI Act and ISO 42001 ISO 42001 can strengthen your operating system. It does not replace the law. Use ISO 42001 to structure governance and evidence, then layer AI Act specific classification and legal duties on top. This comparison uses a fair use approach. It does not reproduce standard text. Instead, it focuses on the functions that ISO/IEC 42001 describes at management system level and explains where those functions help with the binding obligations in the EU AI Act. ## What each instrument is designed to do The EU AI Act is binding law. It classifies AI systems and models, creates operator duties, and gives authorities enforcement powers. It answers legal questions such as whether a use case is prohibited, whether a system is high risk, when Article 50 disclosures apply, and what a GPAI provider must publish or keep available. ISO/IEC 42001 is a management system standard. Based on the official ISO description and the table of contents in the local source pack, it is built around AI policy, roles and responsibilities, AI risk assessment, AI risk treatment, AI system impact assessment, documented information, monitoring, internal audit, management review, and continual improvement. - AI Act answer: what is required by law for this system or model. - ISO 42001 answer: how the organization should structure governance and documented processes. - AI Act is enforceable by authorities and linked to penalties. - ISO 42001 is voluntary and often used to structure governance, audits, and certification activities. ## Where ISO 42001 helps the most ISO 42001 is useful when you need a stable operating model. The standard covers the kinds of organizational machinery that AI Act programs need anyway: policy ownership, recurring risk assessment, impact assessment, documented information, internal audits, monitoring, and management review. In practice, organizations often use ISO 42001 to reduce chaos across teams. It gives a home for AI policy, evidence retention, approval discipline, and continual improvement, which helps the AI Act program stay alive after the first implementation wave. - AI policy and role assignment support Article 4 literacy, operator accountability, and internal governance. - AI risk assessment and treatment support high risk and transparency planning. - AI system impact assessment supports the habit of structured impact review, even though Article 27 FRIA is a separate legal test. - Documented information, monitoring, internal audit, and management review strengthen evidence quality and repeatability. ## Where the EU AI Act still needs separate work ISO 42001 does not answer the legal classification questions. It does not tell you whether a system is prohibited under Article 5, whether Annex III applies, whether a derogation can be used, whether a system must be registered in the EU database, or whether a provider must carry out conformity assessment and CE marking work. It also does not replace Chapter V obligations for GPAI. Training content summaries, copyright policy, Article 52 systemic risk notification, and Article 55 serious incident handling remain AI Act specific duties. - No substitute for Article 5 screening. - No substitute for Article 6 and Annex III classification analysis. - No substitute for Article 50 interaction and deepfake disclosures. - No substitute for Annex IV technical documentation, Article 49 registration, or Chapter V GPAI artifacts. ## Practical adoption model The best combined model is simple. Use ISO 42001 as the governance backbone and AI Act controls as the legal overlay. Put the inventory, approvals, risk reviews, documented information, and audits inside the management system. Put Article 5, Annex III, Article 50, and Chapter V decision logic into the legal overlay and release controls. This keeps the program efficient. It also avoids a common failure mode where teams pursue certification like it automatically solves legal classification and market obligations. - Map AI policy to AI Act governance and literacy duties. - Map ISO risk assessment and impact assessment to high risk and transparency intake. - Add AI Act only controls for classification, disclosures, conformity, registration, and GPAI outputs. - Audit the combined program against both the management system and the legal obligations. *Recommended next step* *Placement: after the comparison section* ## Use EU AI Act (Regulation (EU) 2024/1689) EU AI Act and ISO 42001 as a cited research workflow Research Copilot can take EU AI Act (Regulation (EU) 2024/1689) EU AI Act and ISO 42001 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU AI Act (Regulation (EU) 2024/1689) EU AI Act and ISO 42001](/solutions/research-copilot.md): Start from EU AI Act (Regulation (EU) 2024/1689) EU AI Act and ISO 42001 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) EU AI Act and ISO 42001. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [ISO - ISO/IEC 42001:2023 AI management systems](https://www.iso.org/standard/81230.html?ref=sorena.io) - Official standard page describing ISO/IEC 42001 as an AI management system standard. - [ISO - AI management systems: what businesses need to know](https://www.iso.org/artificial-intelligence/ai-management-systems?ref=sorena.io) - Official ISO explainer on the management system model and PDCA structure. - [AI Act Service Desk - Implementation timeline](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act?ref=sorena.io) - Official staging reference for phased application dates. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001 --- --- title: "EU AI Act vs ISO 42001" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001" source_url: "https://www.sorena.io/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001" author: "Sorena AI" description: "Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information." keywords: - "EU AI Act vs ISO 42001" - "ISO 42001 AI Act mapping" - "ISO 42001 compliance EU AI Act" - "AI management system vs AI regulation" - "ISO 42001 Article 50 Annex III Article 53" - "EU AI Act" - "ISO 42001" - "AI management system" - "Governance" - "Compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act vs ISO 42001 Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. *EU AI Act* *Comparison* ## EU AI Act (Regulation (EU) 2024/1689) EU AI Act and ISO 42001 ISO 42001 can strengthen your operating system. It does not replace the law. Use ISO 42001 to structure governance and evidence, then layer AI Act specific classification and legal duties on top. This comparison uses a fair use approach. It does not reproduce standard text. Instead, it focuses on the functions that ISO/IEC 42001 describes at management system level and explains where those functions help with the binding obligations in the EU AI Act. ## What each instrument is designed to do The EU AI Act is binding law. It classifies AI systems and models, creates operator duties, and gives authorities enforcement powers. It answers legal questions such as whether a use case is prohibited, whether a system is high risk, when Article 50 disclosures apply, and what a GPAI provider must publish or keep available. ISO/IEC 42001 is a management system standard. Based on the official ISO description and the table of contents in the local source pack, it is built around AI policy, roles and responsibilities, AI risk assessment, AI risk treatment, AI system impact assessment, documented information, monitoring, internal audit, management review, and continual improvement. - AI Act answer: what is required by law for this system or model. - ISO 42001 answer: how the organization should structure governance and documented processes. - AI Act is enforceable by authorities and linked to penalties. - ISO 42001 is voluntary and often used to structure governance, audits, and certification activities. ## Where ISO 42001 helps the most ISO 42001 is useful when you need a stable operating model. The standard covers the kinds of organizational machinery that AI Act programs need anyway: policy ownership, recurring risk assessment, impact assessment, documented information, internal audits, monitoring, and management review. In practice, organizations often use ISO 42001 to reduce chaos across teams. It gives a home for AI policy, evidence retention, approval discipline, and continual improvement, which helps the AI Act program stay alive after the first implementation wave. - AI policy and role assignment support Article 4 literacy, operator accountability, and internal governance. - AI risk assessment and treatment support high risk and transparency planning. - AI system impact assessment supports the habit of structured impact review, even though Article 27 FRIA is a separate legal test. - Documented information, monitoring, internal audit, and management review strengthen evidence quality and repeatability. ## Where the EU AI Act still needs separate work ISO 42001 does not answer the legal classification questions. It does not tell you whether a system is prohibited under Article 5, whether Annex III applies, whether a derogation can be used, whether a system must be registered in the EU database, or whether a provider must carry out conformity assessment and CE marking work. It also does not replace Chapter V obligations for GPAI. Training content summaries, copyright policy, Article 52 systemic risk notification, and Article 55 serious incident handling remain AI Act specific duties. - No substitute for Article 5 screening. - No substitute for Article 6 and Annex III classification analysis. - No substitute for Article 50 interaction and deepfake disclosures. - No substitute for Annex IV technical documentation, Article 49 registration, or Chapter V GPAI artifacts. ## Practical adoption model The best combined model is simple. Use ISO 42001 as the governance backbone and AI Act controls as the legal overlay. Put the inventory, approvals, risk reviews, documented information, and audits inside the management system. Put Article 5, Annex III, Article 50, and Chapter V decision logic into the legal overlay and release controls. This keeps the program efficient. It also avoids a common failure mode where teams pursue certification like it automatically solves legal classification and market obligations. - Map AI policy to AI Act governance and literacy duties. - Map ISO risk assessment and impact assessment to high risk and transparency intake. - Add AI Act only controls for classification, disclosures, conformity, registration, and GPAI outputs. - Audit the combined program against both the management system and the legal obligations. *Recommended next step* *Placement: after the comparison section* ## Use EU AI Act (Regulation (EU) 2024/1689) EU AI Act and ISO 42001 as a cited research workflow Research Copilot can take EU AI Act (Regulation (EU) 2024/1689) EU AI Act and ISO 42001 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU AI Act (Regulation (EU) 2024/1689) EU AI Act and ISO 42001](/solutions/research-copilot.md): Start from EU AI Act (Regulation (EU) 2024/1689) EU AI Act and ISO 42001 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) EU AI Act and ISO 42001. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [ISO - ISO/IEC 42001:2023 AI management systems](https://www.iso.org/standard/81230.html?ref=sorena.io) - Official standard page describing ISO/IEC 42001 as an AI management system standard. - [ISO - AI management systems: what businesses need to know](https://www.iso.org/artificial-intelligence/ai-management-systems?ref=sorena.io) - Official ISO explainer on the management system model and PDCA structure. - [AI Act Service Desk - Implementation timeline](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act?ref=sorena.io) - Official staging reference for phased application dates. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001 --- --- title: "EU AI Act vs NIST AI RMF" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf" source_url: "https://www.sorena.io/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf" author: "Sorena AI" description: "Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure." keywords: - "EU AI Act vs NIST AI RMF" - "NIST AI RMF AI Act mapping" - "Govern Map Measure Manage AI Act" - "voluntary AI RMF vs EU AI law" - "ETSI NIST AI RMF AI Act" - "EU AI Act" - "NIST AI RMF" - "Govern" - "Map" - "Measure" - "Manage" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act vs NIST AI RMF Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. *EU AI Act* *Comparison* ## EU AI Act (Regulation (EU) 2024/1689) EU AI Act and NIST AI RMF NIST AI RMF helps you manage AI risk. The AI Act tells you which legal duties still apply. The strongest model uses AI RMF for governance and risk discipline, then overlays AI Act specific legal checks and evidence. NIST AI RMF 1.0 is explicitly voluntary. The AI Act is not. That difference matters. Teams that already use AI RMF should keep it, but they should stop short of treating it as a substitute for EU legal classification, operator duties, and authority facing evidence. ## What NIST AI RMF contributes NIST describes the AI RMF as a voluntary framework to help organizations designing, developing, deploying, or using AI systems manage risk and support trustworthy AI. The core uses four functions: Govern, Map, Measure, and Manage. That structure is useful because it gives product and risk teams a common language that is broader than model safety alone. The playbook and related NIST resources are especially helpful when an organization needs a repeatable way to define purpose, identify context, measure risks, prioritize responses, and keep improving over time. - Govern helps assign policy, oversight, roles, and accountability. - Map helps define context, stakeholders, intended purpose, and risk factors. - Measure helps test, evaluate, and monitor risk signals and controls. - Manage helps prioritize responses, accept residual risk, and track remediation. ## What the EU AI Act adds that AI RMF does not The AI Act adds legal routing. It asks whether the system is prohibited, high risk, transparency triggered, or connected to GPAI provider duties. It also assigns obligations to specific operator roles and attaches penalties to non compliance. NIST AI RMF does not make those legal classifications for you. This is why a good AI RMF program can still miss core AI Act obligations if it never runs Article 5 screening, Annex III classification, Article 50 product disclosure analysis, or Chapter V model level documentation checks. - AI RMF does not determine whether Annex III applies. - AI RMF does not create Article 50 disclosure duties or machine readable marking duties. - AI RMF does not replace Annex IV technical documentation or conformity assessment work. - AI RMF does not replace Article 53 to 55 duties for GPAI providers. ## How to combine them in practice Use AI RMF as the operating logic for governance and risk management. Then insert AI Act checkpoints inside each function. Govern should include operator role ownership and AI literacy. Map should include EU scope, intended purpose, and affected persons. Measure should include Article 5 screening, Article 50 design review, and high risk testing evidence. Manage should include launch decisions, residual risk treatment, incident handling, and corrective action. This combined model is also consistent with the ETSI material in the local source pack, which references the NIST AI RMF as part of a structured risk and governance approach for AI systems. - Govern plus AI Act: assign provider and deployer duties and approval authority. - Map plus AI Act: identify scope, intended purpose, Annex III exposure, and affected persons. - Measure plus AI Act: test disclosures, performance, robustness, logging, and oversight. - Manage plus AI Act: approve launch, track incidents, update documentation, and close corrective actions. ## Evidence reuse without false equivalence You can reuse a large share of your evidence. Risk registers, role assignments, impact review outputs, control test results, and monitoring reports all carry over. What you cannot reuse is the claim that a completed AI RMF cycle equals AI Act compliance. Keep one evidence pack with a clear legal appendix. That appendix should show the AI Act classifications, article triggers, and any mandatory artifacts such as FRIA, Annex IV planning, Article 50 evidence, or Chapter V model outputs. - Reuse governance records, risk review outputs, and monitoring evidence. - Add AI Act only decision records and mandatory legal artifacts. - Tie every evidence item to a system or model version. - Review the combined pack on the same cadence as product and model change control. *Recommended next step* *Placement: after the comparison section* ## Use EU AI Act (Regulation (EU) 2024/1689) EU AI Act and NIST AI RMF as a cited research workflow Research Copilot can take EU AI Act (Regulation (EU) 2024/1689) EU AI Act and NIST AI RMF from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU AI Act (Regulation (EU) 2024/1689) EU AI Act and NIST AI RMF](/solutions/research-copilot.md): Start from EU AI Act (Regulation (EU) 2024/1689) EU AI Act and NIST AI RMF and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) EU AI Act and NIST AI RMF. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [NIST - Artificial Intelligence Risk Management Framework (AI RMF 1.0)](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10) - Official NIST publication for the voluntary AI RMF 1.0. - [NIST - AI RMF Playbook](https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook) - Official playbook describing the Govern, Map, Measure, and Manage functions. - [ETSI TR 104 128 - Guide to cyber security for AI models and systems](https://www.etsi.org/deliver/etsi_tr/104100_104199/104128/01.01.01_60/tr_104128v010101p.pdf) - ETSI material in the local source pack that references NIST AI RMF and operational AI controls. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf --- --- title: "EU AI Act vs NIST AI RMF" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf" source_url: "https://www.sorena.io/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf" author: "Sorena AI" description: "Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure." keywords: - "EU AI Act vs NIST AI RMF" - "NIST AI RMF AI Act mapping" - "Govern Map Measure Manage AI Act" - "voluntary AI RMF vs EU AI law" - "ETSI NIST AI RMF AI Act" - "EU AI Act" - "NIST AI RMF" - "Govern" - "Map" - "Measure" - "Manage" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act vs NIST AI RMF Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. *EU AI Act* *Comparison* ## EU AI Act (Regulation (EU) 2024/1689) EU AI Act and NIST AI RMF NIST AI RMF helps you manage AI risk. The AI Act tells you which legal duties still apply. The strongest model uses AI RMF for governance and risk discipline, then overlays AI Act specific legal checks and evidence. NIST AI RMF 1.0 is explicitly voluntary. The AI Act is not. That difference matters. Teams that already use AI RMF should keep it, but they should stop short of treating it as a substitute for EU legal classification, operator duties, and authority facing evidence. ## What NIST AI RMF contributes NIST describes the AI RMF as a voluntary framework to help organizations designing, developing, deploying, or using AI systems manage risk and support trustworthy AI. The core uses four functions: Govern, Map, Measure, and Manage. That structure is useful because it gives product and risk teams a common language that is broader than model safety alone. The playbook and related NIST resources are especially helpful when an organization needs a repeatable way to define purpose, identify context, measure risks, prioritize responses, and keep improving over time. - Govern helps assign policy, oversight, roles, and accountability. - Map helps define context, stakeholders, intended purpose, and risk factors. - Measure helps test, evaluate, and monitor risk signals and controls. - Manage helps prioritize responses, accept residual risk, and track remediation. ## What the EU AI Act adds that AI RMF does not The AI Act adds legal routing. It asks whether the system is prohibited, high risk, transparency triggered, or connected to GPAI provider duties. It also assigns obligations to specific operator roles and attaches penalties to non compliance. NIST AI RMF does not make those legal classifications for you. This is why a good AI RMF program can still miss core AI Act obligations if it never runs Article 5 screening, Annex III classification, Article 50 product disclosure analysis, or Chapter V model level documentation checks. - AI RMF does not determine whether Annex III applies. - AI RMF does not create Article 50 disclosure duties or machine readable marking duties. - AI RMF does not replace Annex IV technical documentation or conformity assessment work. - AI RMF does not replace Article 53 to 55 duties for GPAI providers. ## How to combine them in practice Use AI RMF as the operating logic for governance and risk management. Then insert AI Act checkpoints inside each function. Govern should include operator role ownership and AI literacy. Map should include EU scope, intended purpose, and affected persons. Measure should include Article 5 screening, Article 50 design review, and high risk testing evidence. Manage should include launch decisions, residual risk treatment, incident handling, and corrective action. This combined model is also consistent with the ETSI material in the local source pack, which references the NIST AI RMF as part of a structured risk and governance approach for AI systems. - Govern plus AI Act: assign provider and deployer duties and approval authority. - Map plus AI Act: identify scope, intended purpose, Annex III exposure, and affected persons. - Measure plus AI Act: test disclosures, performance, robustness, logging, and oversight. - Manage plus AI Act: approve launch, track incidents, update documentation, and close corrective actions. ## Evidence reuse without false equivalence You can reuse a large share of your evidence. Risk registers, role assignments, impact review outputs, control test results, and monitoring reports all carry over. What you cannot reuse is the claim that a completed AI RMF cycle equals AI Act compliance. Keep one evidence pack with a clear legal appendix. That appendix should show the AI Act classifications, article triggers, and any mandatory artifacts such as FRIA, Annex IV planning, Article 50 evidence, or Chapter V model outputs. - Reuse governance records, risk review outputs, and monitoring evidence. - Add AI Act only decision records and mandatory legal artifacts. - Tie every evidence item to a system or model version. - Review the combined pack on the same cadence as product and model change control. *Recommended next step* *Placement: after the comparison section* ## Use EU AI Act (Regulation (EU) 2024/1689) EU AI Act and NIST AI RMF as a cited research workflow Research Copilot can take EU AI Act (Regulation (EU) 2024/1689) EU AI Act and NIST AI RMF from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU AI Act (Regulation (EU) 2024/1689) EU AI Act and NIST AI RMF](/solutions/research-copilot.md): Start from EU AI Act (Regulation (EU) 2024/1689) EU AI Act and NIST AI RMF and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) EU AI Act and NIST AI RMF. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [NIST - Artificial Intelligence Risk Management Framework (AI RMF 1.0)](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10) - Official NIST publication for the voluntary AI RMF 1.0. - [NIST - AI RMF Playbook](https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook) - Official playbook describing the Govern, Map, Measure, and Manage functions. - [ETSI TR 104 128 - Guide to cyber security for AI models and systems](https://www.etsi.org/deliver/etsi_tr/104100_104199/104128/01.01.01_60/tr_104128v010101p.pdf) - ETSI material in the local source pack that references NIST AI RMF and operational AI controls. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf --- --- title: "EU AI Act FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/faq" source_url: "https://www.sorena.io/artifacts/eu/ai-act/faq" author: "Sorena AI" description: "Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency." keywords: - "EU AI Act FAQ" - "when does EU AI Act apply" - "what is high risk AI under EU AI Act" - "provider vs deployer AI Act" - "GPAI obligations FAQ" - "EU AI Act penalties FAQ" - "EU AI Act" - "FAQ" - "High risk" - "Transparency" - "GPAI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act FAQ Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. *EU AI Act* *FAQ* ## EU AI Act (Regulation (EU) 2024/1689) FAQ Short answers, exact dates, and the points teams most often misunderstand. Use these answers as a quick orientation, then move to the deeper guides when you need implementation detail. This FAQ is grounded in the local source pack and focuses on operational questions teams ask during scoping, procurement, launch planning, and remediation. Dates are stated explicitly so there is no ambiguity about which phase of the Act is in view. ## When does the EU AI Act apply? The Regulation entered into force on 1 August 2024. The prohibitions, the general provisions, and AI literacy apply from 2 February 2025. The GPAI rules in Chapter V apply from 2 August 2025. Most of the remaining rules apply from 2 August 2026, with some transition dates extending to 2 August 2027 and 31 December 2030. That means the answer depends on the obligation. Teams should map each system or model to the exact date that matters for its obligation set. ## How do we know whether a system is high risk? Check Article 6 and both high risk routes. One route covers AI systems that are safety components of products under listed Union harmonisation laws. The other route covers the Annex III use cases. Even within Annex III, there is a derogation where the system does not pose a significant risk of harm and does not materially influence decision making, but the provider must document that conclusion and register the system if relying on it. If the system performs profiling of natural persons in an Annex III use case, it is always treated as high risk. ## What is the difference between provider and deployer? The provider is the operator making the system available or otherwise carrying provider status under the Act. The deployer uses the system under its authority. The same company can be a provider in one context and a deployer in another. Role is assigned per system and per use case, not once for the whole company. A distributor, importer, or deployer can become the provider if it rebrands a high risk system, makes a substantial modification, or changes the intended purpose so that a system becomes high risk. ## Do we still have duties if we only use a third party model API? Yes. Using a third party model does not remove your own system level duties. You may still be the deployer or even the provider of the system that wraps the model. If the system is high risk, your obligations continue. If Article 50 applies, your disclosures still have to work. You also need supplier evidence that supports your own compliance record. The upstream model provider and the downstream system provider should be recorded separately in the role matrix. ## What do transparency obligations mean in practice? Article 50 requires more than a policy statement. Users interacting directly with an AI system must be informed unless it is obvious. Providers of systems generating synthetic audio, image, video, or text must ensure the outputs are marked in a machine readable and detectable way where the article requires it. Deployers of deepfake systems and certain text publication uses have their own disclosure duties. Teams should treat this as product work with design review, accessibility review, QA evidence, and change control. ## What must GPAI providers prepare? Article 53 requires technical documentation, downstream documentation for system providers, a copyright compliance policy, and a sufficiently detailed public summary of training content using the AI Office template. If a model is a GPAI model with systemic risk, Articles 52 to 55 add notification, evaluation cooperation, risk mitigation, and serious incident reporting duties. Providers of GPAI models placed on the market before 2 August 2025 have until 2 August 2027 to comply with the Chapter V obligations. ## What are the penalty tiers? Article 99 sets the main operator penalty tiers. Non compliance with Article 5 prohibited practices can reach EUR 35,000,000 or 7 percent of worldwide annual turnover. Other listed operator and notified body duties can reach EUR 15,000,000 or 3 percent. Supplying incorrect, incomplete, or misleading information can reach EUR 7,500,000 or 1 percent. For GPAI providers, the Commission also has a separate fine power that can reach EUR 15,000,000 or 3 percent under Article 101. *Recommended next step* *Placement: after the FAQ section* ## Use EU AI Act (Regulation (EU) 2024/1689) FAQ as a cited research workflow Research Copilot can take EU AI Act (Regulation (EU) 2024/1689) FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU AI Act (Regulation (EU) 2024/1689) FAQ](/solutions/research-copilot.md): Start from EU AI Act (Regulation (EU) 2024/1689) FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) FAQ. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Implementation timeline](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act?ref=sorena.io) - Official staging reference for phased application dates. - [AI Act Service Desk - Article 50 transparency obligations](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50?ref=sorena.io) - Official support page for interaction, disclosure, and deepfake duties. - [AI Act Service Desk - Article 99 penalties](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-99?ref=sorena.io) - Official support page for penalty structure and enforcement context. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/faq --- --- title: "EU AI Act FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/faq" source_url: "https://www.sorena.io/artifacts/eu/ai-act/faq" author: "Sorena AI" description: "Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency." keywords: - "EU AI Act FAQ" - "when does EU AI Act apply" - "what is high risk AI under EU AI Act" - "provider vs deployer AI Act" - "GPAI obligations FAQ" - "EU AI Act penalties FAQ" - "EU AI Act" - "FAQ" - "High risk" - "Transparency" - "GPAI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act FAQ Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. *EU AI Act* *FAQ* ## EU AI Act (Regulation (EU) 2024/1689) FAQ Short answers, exact dates, and the points teams most often misunderstand. Use these answers as a quick orientation, then move to the deeper guides when you need implementation detail. This FAQ is grounded in the local source pack and focuses on operational questions teams ask during scoping, procurement, launch planning, and remediation. Dates are stated explicitly so there is no ambiguity about which phase of the Act is in view. ## When does the EU AI Act apply? The Regulation entered into force on 1 August 2024. The prohibitions, the general provisions, and AI literacy apply from 2 February 2025. The GPAI rules in Chapter V apply from 2 August 2025. Most of the remaining rules apply from 2 August 2026, with some transition dates extending to 2 August 2027 and 31 December 2030. That means the answer depends on the obligation. Teams should map each system or model to the exact date that matters for its obligation set. ## How do we know whether a system is high risk? Check Article 6 and both high risk routes. One route covers AI systems that are safety components of products under listed Union harmonisation laws. The other route covers the Annex III use cases. Even within Annex III, there is a derogation where the system does not pose a significant risk of harm and does not materially influence decision making, but the provider must document that conclusion and register the system if relying on it. If the system performs profiling of natural persons in an Annex III use case, it is always treated as high risk. ## What is the difference between provider and deployer? The provider is the operator making the system available or otherwise carrying provider status under the Act. The deployer uses the system under its authority. The same company can be a provider in one context and a deployer in another. Role is assigned per system and per use case, not once for the whole company. A distributor, importer, or deployer can become the provider if it rebrands a high risk system, makes a substantial modification, or changes the intended purpose so that a system becomes high risk. ## Do we still have duties if we only use a third party model API? Yes. Using a third party model does not remove your own system level duties. You may still be the deployer or even the provider of the system that wraps the model. If the system is high risk, your obligations continue. If Article 50 applies, your disclosures still have to work. You also need supplier evidence that supports your own compliance record. The upstream model provider and the downstream system provider should be recorded separately in the role matrix. ## What do transparency obligations mean in practice? Article 50 requires more than a policy statement. Users interacting directly with an AI system must be informed unless it is obvious. Providers of systems generating synthetic audio, image, video, or text must ensure the outputs are marked in a machine readable and detectable way where the article requires it. Deployers of deepfake systems and certain text publication uses have their own disclosure duties. Teams should treat this as product work with design review, accessibility review, QA evidence, and change control. ## What must GPAI providers prepare? Article 53 requires technical documentation, downstream documentation for system providers, a copyright compliance policy, and a sufficiently detailed public summary of training content using the AI Office template. If a model is a GPAI model with systemic risk, Articles 52 to 55 add notification, evaluation cooperation, risk mitigation, and serious incident reporting duties. Providers of GPAI models placed on the market before 2 August 2025 have until 2 August 2027 to comply with the Chapter V obligations. ## What are the penalty tiers? Article 99 sets the main operator penalty tiers. Non compliance with Article 5 prohibited practices can reach EUR 35,000,000 or 7 percent of worldwide annual turnover. Other listed operator and notified body duties can reach EUR 15,000,000 or 3 percent. Supplying incorrect, incomplete, or misleading information can reach EUR 7,500,000 or 1 percent. For GPAI providers, the Commission also has a separate fine power that can reach EUR 15,000,000 or 3 percent under Article 101. *Recommended next step* *Placement: after the FAQ section* ## Use EU AI Act (Regulation (EU) 2024/1689) FAQ as a cited research workflow Research Copilot can take EU AI Act (Regulation (EU) 2024/1689) FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU AI Act (Regulation (EU) 2024/1689) FAQ](/solutions/research-copilot.md): Start from EU AI Act (Regulation (EU) 2024/1689) FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) FAQ. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Implementation timeline](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act?ref=sorena.io) - Official staging reference for phased application dates. - [AI Act Service Desk - Article 50 transparency obligations](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50?ref=sorena.io) - Official support page for interaction, disclosure, and deepfake duties. - [AI Act Service Desk - Article 99 penalties](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-99?ref=sorena.io) - Official support page for penalty structure and enforcement context. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/faq --- --- title: "EU AI Act GPAI and Foundation Model Obligations" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/gpai-and-foundation-model-obligations" source_url: "https://www.sorena.io/artifacts/eu/ai-act/gpai-and-foundation-model-obligations" author: "Sorena AI" description: "Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy." keywords: - "EU AI Act GPAI obligations" - "foundation model obligations EU AI Act" - "Article 53 AI Act" - "Article 55 AI Act" - "public summary of training content" - "systemic risk GPAI" - "AI Office template" - "EU AI Act" - "GPAI" - "Foundation models" - "Article 53" - "Article 55" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act GPAI and Foundation Model Obligations Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. *EU AI Act* *Chapter V* ## EU AI Act (Regulation (EU) 2024/1689) GPAI obligations Chapter V is model level law. Treat it as a production workflow, not as a one off filing task. This guide explains which providers are in scope, what they must maintain, and how systemic risk changes the operating model. The AI Act uses the term general purpose AI model. In practice, this is where many foundation model discussions land. The obligations are not limited to one document. They require a standing workflow for documentation, downstream information, copyright compliance, publication, and regulator cooperation. ## When GPAI obligations apply Chapter V obligations apply from 2 August 2025. If a provider placed a GPAI model on the market before 2 August 2025, Article 111 gives that provider until 2 August 2027 to take the necessary steps to comply. The obligations still exist from 2 August 2025 for providers placing models on the market from that date onward. The Commission guidance in the local source pack makes clear that the absence of immediate enforcement fines in the first year does not suspend the legal applicability of Chapter V. - 2 August 2025: Chapter V applies. - 2 August 2026: Commission enforcement powers on GPAI fines begin. - 2 August 2027: legacy GPAI models placed before 2 August 2025 must be compliant. - Use a dated model registry so you can prove which transition rule applies. ## Core Article 53 deliverables Article 53 requires four pillars. First, technical documentation for the model and its training, testing, and evaluation process. Second, downstream information and documentation that lets AI system providers understand capabilities and limitations and comply with their own obligations. Third, a copyright policy that addresses Union copyright and related rights, including reservation of rights under the text and data mining rules. Fourth, a sufficiently detailed public summary of the content used for training, using the AI Office template. These are living artifacts. They have to stay current as the model, training approach, or release strategy changes. - Maintain an internal model documentation workflow tied to releases. - Prepare downstream integration documentation that is usable by system providers. - Maintain and review the copyright policy against data sourcing practice. - Publish and update the public summary of training content using the official template and explanatory notice. ## Open source and authorised representative points Article 53 contains a limited exception for providers releasing models under a free and open source licence where the parameters, architecture information, and model usage information are made publicly available. That exception does not apply to GPAI models with systemic risk. Article 54 requires providers established outside the Union to appoint an authorised representative in the Union before placing a GPAI model on the Union market, unless the open source exception applies and the model does not present systemic risk. - Do not assume open source status removes all GPAI duties. - Check whether the model could still be systemic risk. - Check whether a Union authorised representative is required. - Keep the mandate and contact details available for the AI Office and national authorities. ## Systemic risk obligations and incident handling A GPAI model is presumed to have high impact capabilities when the cumulative training compute exceeds the Article 51 threshold. Once that threshold is met or known to be met, the provider must notify the Commission without delay and in any event within two weeks. The Commission can also designate systemic risk on its own decision basis. Systemic risk providers need stronger safety, security, and serious incident readiness under Article 55. The local source pack also includes the Commission reporting template and the code of practice materials that help structure this work. - Track compute and maintain evidence for threshold analysis. - Prepare the Article 52 notification path and responsible contacts. - Define what counts as a serious incident and how evidence is captured. - Run drills for exfiltration, major safety event, and severe downstream harm scenarios. ## What downstream integrators should demand Even if you are not the GPAI provider, you need upstream material that supports your own compliance. Integrators should not accept a black box relationship where capabilities, limitations, and incident obligations are unknown. The downstream package should be usable by product, legal, security, and procurement teams, not only by machine learning engineers. - Versioned technical and downstream documentation extracts. - Known limitations, evaluation coverage, and unsafe use boundaries. - Change notices for model upgrades and major policy changes. - Incident notice commitments and escalation contacts. - Training content summary and copyright policy references where required. *Recommended next step* *Placement: after the scope or definition section* ## Use EU AI Act (Regulation (EU) 2024/1689) GPAI obligations as a cited research workflow Research Copilot can take EU AI Act (Regulation (EU) 2024/1689) GPAI obligations from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU AI Act (Regulation (EU) 2024/1689) GPAI obligations](/solutions/research-copilot.md): Start from EU AI Act (Regulation (EU) 2024/1689) GPAI obligations and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) GPAI obligations. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. - [European Commission - General purpose AI Code of Practice](https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai?ref=sorena.io) - Official code of practice page published on 10 July 2025. - [European Commission - Explanatory notice and template for the public summary of training content](https://digital-strategy.ec.europa.eu/en/library/explanatory-notice-and-template-public-summary-training-content-general-purpose-ai-models?ref=sorena.io) - Official Article 53(1)(d) template and implementation notice. - [European Commission - Reporting template for serious incidents involving GPAI models with systemic risk](https://digital-strategy.ec.europa.eu/en/library/ai-act-commission-publishes-reporting-template-serious-incidents-involving-general-purpose-ai?ref=sorena.io) - Official reporting template support page for Article 55 incident handling. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/gpai-and-foundation-model-obligations --- --- title: "EU AI Act GPAI and Foundation Model Obligations" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/gpai-and-foundation-model-obligations" source_url: "https://www.sorena.io/artifacts/eu/ai-act/gpai-and-foundation-model-obligations" author: "Sorena AI" description: "Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy." keywords: - "EU AI Act GPAI obligations" - "foundation model obligations EU AI Act" - "Article 53 AI Act" - "Article 55 AI Act" - "public summary of training content" - "systemic risk GPAI" - "AI Office template" - "EU AI Act" - "GPAI" - "Foundation models" - "Article 53" - "Article 55" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act GPAI and Foundation Model Obligations Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. *EU AI Act* *Chapter V* ## EU AI Act (Regulation (EU) 2024/1689) GPAI obligations Chapter V is model level law. Treat it as a production workflow, not as a one off filing task. This guide explains which providers are in scope, what they must maintain, and how systemic risk changes the operating model. The AI Act uses the term general purpose AI model. In practice, this is where many foundation model discussions land. The obligations are not limited to one document. They require a standing workflow for documentation, downstream information, copyright compliance, publication, and regulator cooperation. ## When GPAI obligations apply Chapter V obligations apply from 2 August 2025. If a provider placed a GPAI model on the market before 2 August 2025, Article 111 gives that provider until 2 August 2027 to take the necessary steps to comply. The obligations still exist from 2 August 2025 for providers placing models on the market from that date onward. The Commission guidance in the local source pack makes clear that the absence of immediate enforcement fines in the first year does not suspend the legal applicability of Chapter V. - 2 August 2025: Chapter V applies. - 2 August 2026: Commission enforcement powers on GPAI fines begin. - 2 August 2027: legacy GPAI models placed before 2 August 2025 must be compliant. - Use a dated model registry so you can prove which transition rule applies. ## Core Article 53 deliverables Article 53 requires four pillars. First, technical documentation for the model and its training, testing, and evaluation process. Second, downstream information and documentation that lets AI system providers understand capabilities and limitations and comply with their own obligations. Third, a copyright policy that addresses Union copyright and related rights, including reservation of rights under the text and data mining rules. Fourth, a sufficiently detailed public summary of the content used for training, using the AI Office template. These are living artifacts. They have to stay current as the model, training approach, or release strategy changes. - Maintain an internal model documentation workflow tied to releases. - Prepare downstream integration documentation that is usable by system providers. - Maintain and review the copyright policy against data sourcing practice. - Publish and update the public summary of training content using the official template and explanatory notice. ## Open source and authorised representative points Article 53 contains a limited exception for providers releasing models under a free and open source licence where the parameters, architecture information, and model usage information are made publicly available. That exception does not apply to GPAI models with systemic risk. Article 54 requires providers established outside the Union to appoint an authorised representative in the Union before placing a GPAI model on the Union market, unless the open source exception applies and the model does not present systemic risk. - Do not assume open source status removes all GPAI duties. - Check whether the model could still be systemic risk. - Check whether a Union authorised representative is required. - Keep the mandate and contact details available for the AI Office and national authorities. ## Systemic risk obligations and incident handling A GPAI model is presumed to have high impact capabilities when the cumulative training compute exceeds the Article 51 threshold. Once that threshold is met or known to be met, the provider must notify the Commission without delay and in any event within two weeks. The Commission can also designate systemic risk on its own decision basis. Systemic risk providers need stronger safety, security, and serious incident readiness under Article 55. The local source pack also includes the Commission reporting template and the code of practice materials that help structure this work. - Track compute and maintain evidence for threshold analysis. - Prepare the Article 52 notification path and responsible contacts. - Define what counts as a serious incident and how evidence is captured. - Run drills for exfiltration, major safety event, and severe downstream harm scenarios. ## What downstream integrators should demand Even if you are not the GPAI provider, you need upstream material that supports your own compliance. Integrators should not accept a black box relationship where capabilities, limitations, and incident obligations are unknown. The downstream package should be usable by product, legal, security, and procurement teams, not only by machine learning engineers. - Versioned technical and downstream documentation extracts. - Known limitations, evaluation coverage, and unsafe use boundaries. - Change notices for model upgrades and major policy changes. - Incident notice commitments and escalation contacts. - Training content summary and copyright policy references where required. *Recommended next step* *Placement: after the scope or definition section* ## Use EU AI Act (Regulation (EU) 2024/1689) GPAI obligations as a cited research workflow Research Copilot can take EU AI Act (Regulation (EU) 2024/1689) GPAI obligations from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU AI Act (Regulation (EU) 2024/1689) GPAI obligations](/solutions/research-copilot.md): Start from EU AI Act (Regulation (EU) 2024/1689) GPAI obligations and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) GPAI obligations. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. - [European Commission - General purpose AI Code of Practice](https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai?ref=sorena.io) - Official code of practice page published on 10 July 2025. - [European Commission - Explanatory notice and template for the public summary of training content](https://digital-strategy.ec.europa.eu/en/library/explanatory-notice-and-template-public-summary-training-content-general-purpose-ai-models?ref=sorena.io) - Official Article 53(1)(d) template and implementation notice. - [European Commission - Reporting template for serious incidents involving GPAI models with systemic risk](https://digital-strategy.ec.europa.eu/en/library/ai-act-commission-publishes-reporting-template-serious-incidents-involving-general-purpose-ai?ref=sorena.io) - Official reporting template support page for Article 55 incident handling. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/gpai-and-foundation-model-obligations --- --- title: "EU AI Act High Risk AI Use Cases by Industry" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry" source_url: "https://www.sorena.io/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry" author: "Sorena AI" description: "See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration." keywords: - "EU AI Act high risk use cases" - "Annex III examples" - "high risk AI by industry" - "employment AI Act" - "education AI Act" - "law enforcement AI Act" - "critical infrastructure AI Act" - "justice AI Act" - "EU AI Act" - "High risk" - "Annex III" - "Industry use cases" - "Article 6" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act High Risk AI Use Cases by Industry See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. *EU AI Act* *Use cases* ## EU AI Act (Regulation (EU) 2024/1689) High risk use cases High risk classification depends on context, purpose, and decision impact. This page translates Annex III and the product safety route into examples teams can actually recognize. High risk classification is one of the most misunderstood parts of the AI Act because teams often look only at model capability. The Act instead focuses on the use case, the protected interests at stake, and in some routes the product law context. These examples are not legal advice, but they reflect the structure of Annex III and Article 6. ## Biometrics, law enforcement, migration, justice, and democracy The most sensitive categories sit close to state power, identity, and rights. Annex III covers several biometric, law enforcement, migration and border, justice, and democratic process uses. Many of these uses also carry strong transparency, record keeping, or restricted access rules because of their impact on individuals and on public trust. Examples include biometric identification and categorisation uses that are permitted rather than prohibited, law enforcement risk assessment or profiling tools, border management credibility or risk tools, and systems supporting judicial decision processes or electoral influence analysis. - Remote biometric identification can be prohibited or highly restricted depending on context. - Profiling within Annex III law enforcement use cases is always high risk. - Justice and democratic process tools need especially careful review because they affect core rights. - Law enforcement, migration, and justice cases often involve special registration and confidentiality rules. ## Education, employment, and essential services Many private sector organizations meet high risk status through Annex III even when they do not think of themselves as regulated AI providers. Education admissions, testing, and evaluation tools can be high risk. Employment tools for recruitment, selection, evaluation, promotion, and termination can be high risk. Essential service decisions in credit, insurance, benefits, and similar contexts can be high risk. The practical common factor is simple: the system materially influences access to opportunity, income, public services, or comparable rights. - Hiring and worker evaluation systems are a frequent enterprise exposure point. - Admissions and exam scoring tools can trigger high risk review. - Creditworthiness and access to essential private services are core Annex III examples. - Public service allocation and benefits eligibility tools should be screened early. ## Critical infrastructure and product safety routes Some systems become high risk because they are safety components of products regulated under Union harmonisation law. Others are high risk because they are used in critical infrastructure where failure could endanger health or safety. Medical devices, machinery, vehicles, and aviation linked products need this route checked carefully. This is where engineering, safety, and product compliance teams need to work together. The AI Act does not replace sector law. It layers AI specific duties onto those environments. - Check Annex I and product safety law where AI is embedded in regulated products. - Check critical infrastructure uses for energy, transport, water, and similar operations. - Map AI specific hazards separately from existing product law hazards. - Plan one joined technical documentation approach where the product route requires it. ## Using the Annex III derogation carefully Article 6 allows a derogation where an Annex III system does not pose a significant risk of harm and does not materially influence decision making. The Act gives examples of narrow procedural tasks and preparatory tasks that may fit this path. But the provider must document the assessment before placing the system on the market or putting it into service and remains subject to registration duties. This is not a shortcut for weak cases. If the system profiles natural persons, the derogation is unavailable. If the system meaningfully shapes the outcome, the derogation is also unlikely to hold. - Document the assessment before market placement or service use. - Check whether the system only performs a narrow procedural or preparatory task. - Reject the derogation if the system materially influences the decision outcome. - Reject the derogation if the system performs profiling of natural persons. *Recommended next step* *Placement: after the main workflow section* ## Turn EU AI Act (Regulation (EU) 2024/1689) High risk use cases into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) High risk use cases from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) High risk use cases](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) High risk use cases and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) High risk use cases. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Annex III high risk use cases](https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3?ref=sorena.io) - Official annex landing page for high risk use cases. - [AI Act Service Desk - Article 27 fundamental rights impact assessment](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-27?ref=sorena.io) - Official support page for deployer FRIA duties. - [AI Act Service Desk - AI Act Explorer](https://ai-act-service-desk.ec.europa.eu/en/ai-act-explorer?ref=sorena.io) - Official article and annex navigator maintained for implementation support. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry --- --- title: "EU AI Act High Risk AI Use Cases by Industry" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry" source_url: "https://www.sorena.io/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry" author: "Sorena AI" description: "See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration." keywords: - "EU AI Act high risk use cases" - "Annex III examples" - "high risk AI by industry" - "employment AI Act" - "education AI Act" - "law enforcement AI Act" - "critical infrastructure AI Act" - "justice AI Act" - "EU AI Act" - "High risk" - "Annex III" - "Industry use cases" - "Article 6" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act High Risk AI Use Cases by Industry See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. *EU AI Act* *Use cases* ## EU AI Act (Regulation (EU) 2024/1689) High risk use cases High risk classification depends on context, purpose, and decision impact. This page translates Annex III and the product safety route into examples teams can actually recognize. High risk classification is one of the most misunderstood parts of the AI Act because teams often look only at model capability. The Act instead focuses on the use case, the protected interests at stake, and in some routes the product law context. These examples are not legal advice, but they reflect the structure of Annex III and Article 6. ## Biometrics, law enforcement, migration, justice, and democracy The most sensitive categories sit close to state power, identity, and rights. Annex III covers several biometric, law enforcement, migration and border, justice, and democratic process uses. Many of these uses also carry strong transparency, record keeping, or restricted access rules because of their impact on individuals and on public trust. Examples include biometric identification and categorisation uses that are permitted rather than prohibited, law enforcement risk assessment or profiling tools, border management credibility or risk tools, and systems supporting judicial decision processes or electoral influence analysis. - Remote biometric identification can be prohibited or highly restricted depending on context. - Profiling within Annex III law enforcement use cases is always high risk. - Justice and democratic process tools need especially careful review because they affect core rights. - Law enforcement, migration, and justice cases often involve special registration and confidentiality rules. ## Education, employment, and essential services Many private sector organizations meet high risk status through Annex III even when they do not think of themselves as regulated AI providers. Education admissions, testing, and evaluation tools can be high risk. Employment tools for recruitment, selection, evaluation, promotion, and termination can be high risk. Essential service decisions in credit, insurance, benefits, and similar contexts can be high risk. The practical common factor is simple: the system materially influences access to opportunity, income, public services, or comparable rights. - Hiring and worker evaluation systems are a frequent enterprise exposure point. - Admissions and exam scoring tools can trigger high risk review. - Creditworthiness and access to essential private services are core Annex III examples. - Public service allocation and benefits eligibility tools should be screened early. ## Critical infrastructure and product safety routes Some systems become high risk because they are safety components of products regulated under Union harmonisation law. Others are high risk because they are used in critical infrastructure where failure could endanger health or safety. Medical devices, machinery, vehicles, and aviation linked products need this route checked carefully. This is where engineering, safety, and product compliance teams need to work together. The AI Act does not replace sector law. It layers AI specific duties onto those environments. - Check Annex I and product safety law where AI is embedded in regulated products. - Check critical infrastructure uses for energy, transport, water, and similar operations. - Map AI specific hazards separately from existing product law hazards. - Plan one joined technical documentation approach where the product route requires it. ## Using the Annex III derogation carefully Article 6 allows a derogation where an Annex III system does not pose a significant risk of harm and does not materially influence decision making. The Act gives examples of narrow procedural tasks and preparatory tasks that may fit this path. But the provider must document the assessment before placing the system on the market or putting it into service and remains subject to registration duties. This is not a shortcut for weak cases. If the system profiles natural persons, the derogation is unavailable. If the system meaningfully shapes the outcome, the derogation is also unlikely to hold. - Document the assessment before market placement or service use. - Check whether the system only performs a narrow procedural or preparatory task. - Reject the derogation if the system materially influences the decision outcome. - Reject the derogation if the system performs profiling of natural persons. *Recommended next step* *Placement: after the main workflow section* ## Turn EU AI Act (Regulation (EU) 2024/1689) High risk use cases into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) High risk use cases from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) High risk use cases](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) High risk use cases and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) High risk use cases. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Annex III high risk use cases](https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3?ref=sorena.io) - Official annex landing page for high risk use cases. - [AI Act Service Desk - Article 27 fundamental rights impact assessment](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-27?ref=sorena.io) - Official support page for deployer FRIA duties. - [AI Act Service Desk - AI Act Explorer](https://ai-act-service-desk.ec.europa.eu/en/ai-act-explorer?ref=sorena.io) - Official article and annex navigator maintained for implementation support. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry --- --- title: "EU AI Act High Risk Requirements Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/high-risk-requirements-checklist" source_url: "https://www.sorena.io/artifacts/eu/ai-act/high-risk-requirements-checklist" author: "Sorena AI" description: "Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions." keywords: - "EU AI Act high risk checklist" - "Article 9 Article 10 Article 11 Article 12 Article 13 Article 14 Article 15 checklist" - "Annex IV checklist" - "FRIA checklist" - "AI Act post market monitoring" - "EU AI Act" - "High risk" - "Articles 9 to 15" - "Annex IV" - "FRIA" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act High Risk Requirements Checklist Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. *EU AI Act* *High risk* ## EU AI Act (Regulation (EU) 2024/1689) High risk checklist High risk compliance is a lifecycle system with evidence at every stage. This checklist covers both the core requirements and the surrounding provider and deployer duties that make them real. High risk systems require more than principles. They require structured controls, technical and organizational evidence, and release discipline that remains valid after deployment. This page maps the key requirements to the outputs teams should be able to show. ## Articles 9 and 10: risk management and data governance Article 9 requires a continuous and iterative risk management system. It should cover known and reasonably foreseeable risks across the lifecycle, not only risks at initial design. Article 10 requires data governance and data quality measures appropriate to the system and its intended purpose. This is where many high risk programs rise or fall. If the training, validation, and testing record is thin, later claims about performance and oversight will also be weak. - Lifecycle risk register linked to design changes, testing, and post market events. - Documented assumptions about intended purpose, users, and environment. - Training, validation, and testing data governance evidence, including relevance and known limitations. - Bias, representativeness, and error handling controls appropriate to the use case. ## Articles 11 to 13: technical documentation, logging, and instructions Article 11 requires technical documentation with the Annex IV content needed to demonstrate compliance. Article 12 requires automatic logging capabilities. Article 13 requires instructions for use that let deployers understand capabilities, limitations, expected performance, and required oversight. This is not paperwork for paperwork sake. These materials allow deployers, notified bodies, and authorities to understand how the system should be used and where the limits are. - Annex IV plan complete and linked to the specific system version. - Logging design supports traceability, incident review, and required retention. - Instructions for use include intended purpose, precluded uses, performance limits, and oversight needs. - Provider and deployer teams agree on how instructions are operationalized in production. ## Articles 14 and 15: human oversight, accuracy, robustness, and cybersecurity Article 14 requires human oversight measures that fit the system and its context. The assigned natural persons need competence, training, authority, and practical means to intervene. Article 15 requires an appropriate level of accuracy, robustness, and cybersecurity in light of intended purpose and state of the art. Oversight and performance should be designed together. A strong oversight model fails if operators cannot understand outputs or if the system degrades without usable monitoring. - Oversight role assigned to trained persons with authority to pause or stop use. - Escalation and fallback actions documented for abnormal outputs or degraded performance. - Accuracy, robustness, and cybersecurity acceptance criteria defined and tested. - Known limitations, failure modes, and residual risks documented for deployers. ## Provider and deployer duties around the core requirements Core requirements only work if the surrounding duties are also in place. Providers need quality management, conformity assessment, retention, registration, and post market monitoring. Deployers need to use the system according to instructions, assign oversight, keep logs under their control, inform affected persons in relevant cases, and perform FRIA where Article 27 requires it. This is why high risk readiness is always broader than Articles 9 to 15 alone. - Technical documentation retained for 10 years where the Act requires it. - Logs under provider or deployer control retained for at least six months unless other law changes the period. - Article 49 registration checked for relevant Annex III systems. - Article 27 FRIA workflow active for public bodies, private entities providing public services, and the listed Annex III finance cases. - Affected person notices and complaint handling path defined where decisions concern natural persons. ## Release and post market checklist A high risk system is not done at first release. Post market monitoring, serious incident handling, corrective action, and change review all need named owners and templates. Learning systems and major updates also need careful review to determine whether the change was already assessed or becomes substantial. Your release checklist should therefore be paired with a steady state monitoring checklist. - Conformity route confirmed and completed before placement on the market or putting into service. - CE marking applied where required. - Post market monitoring plan created and linked to production telemetry and support channels. - Serious incident and corrective action workflow tested. - Material changes reviewed against substantial modification criteria. *Recommended next step* *Placement: after the checklist block* ## Turn EU AI Act (Regulation (EU) 2024/1689) High risk checklist into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) High risk checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) High risk checklist](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) High risk checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) High risk checklist. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Annex III high risk use cases](https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3?ref=sorena.io) - Official annex landing page for high risk use cases. - [AI Act Service Desk - Article 27 fundamental rights impact assessment](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-27?ref=sorena.io) - Official support page for deployer FRIA duties. - [AI Act Service Desk - AI Act Explorer](https://ai-act-service-desk.ec.europa.eu/en/ai-act-explorer?ref=sorena.io) - Official article and annex navigator maintained for implementation support. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/high-risk-requirements-checklist --- --- title: "EU AI Act High Risk Requirements Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/high-risk-requirements-checklist" source_url: "https://www.sorena.io/artifacts/eu/ai-act/high-risk-requirements-checklist" author: "Sorena AI" description: "Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions." keywords: - "EU AI Act high risk checklist" - "Article 9 Article 10 Article 11 Article 12 Article 13 Article 14 Article 15 checklist" - "Annex IV checklist" - "FRIA checklist" - "AI Act post market monitoring" - "EU AI Act" - "High risk" - "Articles 9 to 15" - "Annex IV" - "FRIA" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act High Risk Requirements Checklist Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. *EU AI Act* *High risk* ## EU AI Act (Regulation (EU) 2024/1689) High risk checklist High risk compliance is a lifecycle system with evidence at every stage. This checklist covers both the core requirements and the surrounding provider and deployer duties that make them real. High risk systems require more than principles. They require structured controls, technical and organizational evidence, and release discipline that remains valid after deployment. This page maps the key requirements to the outputs teams should be able to show. ## Articles 9 and 10: risk management and data governance Article 9 requires a continuous and iterative risk management system. It should cover known and reasonably foreseeable risks across the lifecycle, not only risks at initial design. Article 10 requires data governance and data quality measures appropriate to the system and its intended purpose. This is where many high risk programs rise or fall. If the training, validation, and testing record is thin, later claims about performance and oversight will also be weak. - Lifecycle risk register linked to design changes, testing, and post market events. - Documented assumptions about intended purpose, users, and environment. - Training, validation, and testing data governance evidence, including relevance and known limitations. - Bias, representativeness, and error handling controls appropriate to the use case. ## Articles 11 to 13: technical documentation, logging, and instructions Article 11 requires technical documentation with the Annex IV content needed to demonstrate compliance. Article 12 requires automatic logging capabilities. Article 13 requires instructions for use that let deployers understand capabilities, limitations, expected performance, and required oversight. This is not paperwork for paperwork sake. These materials allow deployers, notified bodies, and authorities to understand how the system should be used and where the limits are. - Annex IV plan complete and linked to the specific system version. - Logging design supports traceability, incident review, and required retention. - Instructions for use include intended purpose, precluded uses, performance limits, and oversight needs. - Provider and deployer teams agree on how instructions are operationalized in production. ## Articles 14 and 15: human oversight, accuracy, robustness, and cybersecurity Article 14 requires human oversight measures that fit the system and its context. The assigned natural persons need competence, training, authority, and practical means to intervene. Article 15 requires an appropriate level of accuracy, robustness, and cybersecurity in light of intended purpose and state of the art. Oversight and performance should be designed together. A strong oversight model fails if operators cannot understand outputs or if the system degrades without usable monitoring. - Oversight role assigned to trained persons with authority to pause or stop use. - Escalation and fallback actions documented for abnormal outputs or degraded performance. - Accuracy, robustness, and cybersecurity acceptance criteria defined and tested. - Known limitations, failure modes, and residual risks documented for deployers. ## Provider and deployer duties around the core requirements Core requirements only work if the surrounding duties are also in place. Providers need quality management, conformity assessment, retention, registration, and post market monitoring. Deployers need to use the system according to instructions, assign oversight, keep logs under their control, inform affected persons in relevant cases, and perform FRIA where Article 27 requires it. This is why high risk readiness is always broader than Articles 9 to 15 alone. - Technical documentation retained for 10 years where the Act requires it. - Logs under provider or deployer control retained for at least six months unless other law changes the period. - Article 49 registration checked for relevant Annex III systems. - Article 27 FRIA workflow active for public bodies, private entities providing public services, and the listed Annex III finance cases. - Affected person notices and complaint handling path defined where decisions concern natural persons. ## Release and post market checklist A high risk system is not done at first release. Post market monitoring, serious incident handling, corrective action, and change review all need named owners and templates. Learning systems and major updates also need careful review to determine whether the change was already assessed or becomes substantial. Your release checklist should therefore be paired with a steady state monitoring checklist. - Conformity route confirmed and completed before placement on the market or putting into service. - CE marking applied where required. - Post market monitoring plan created and linked to production telemetry and support channels. - Serious incident and corrective action workflow tested. - Material changes reviewed against substantial modification criteria. *Recommended next step* *Placement: after the checklist block* ## Turn EU AI Act (Regulation (EU) 2024/1689) High risk checklist into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) High risk checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) High risk checklist](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) High risk checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) High risk checklist. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Annex III high risk use cases](https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3?ref=sorena.io) - Official annex landing page for high risk use cases. - [AI Act Service Desk - Article 27 fundamental rights impact assessment](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-27?ref=sorena.io) - Official support page for deployer FRIA duties. - [AI Act Service Desk - AI Act Explorer](https://ai-act-service-desk.ec.europa.eu/en/ai-act-explorer?ref=sorena.io) - Official article and annex navigator maintained for implementation support. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/high-risk-requirements-checklist --- --- title: "EU AI Act Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/ai-act/penalties-and-fines" author: "Sorena AI" description: "Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent." keywords: - "EU AI Act penalties" - "AI Act fines" - "Article 99 fines" - "Article 101 GPAI fines" - "7 percent turnover AI Act" - "3 percent turnover AI Act" - "EU AI Act" - "Penalties" - "Article 99" - "Article 101" - "Enforcement" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Penalties and Fines Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. *EU AI Act* *Enforcement* ## EU AI Act (Regulation (EU) 2024/1689) Penalties and fines Penalty exposure follows from bad classification, weak controls, and poor evidence. The numbers matter, but so do the behaviors that create enforcement attention. Penalty analysis is useful only if it improves behavior. The AI Act penalty structure should be read as a signal about what regulators and authorities consider most serious: prohibited practices, failure of core operator duties, bad information to authorities, and non compliant GPAI provider conduct. ## Main Article 99 tiers Article 99 creates three main operator fine levels. The highest tier is reserved for prohibited practices under Article 5. The middle tier applies to listed operator and notified body duties, including provider, authorised representative, importer, distributor, deployer, notified body, and Article 50 transparency obligations. The lower tier applies to incorrect, incomplete, or misleading information supplied to notified bodies or national competent authorities. The Act also says Member States must make penalties effective, proportionate, and dissuasive, while taking account of the interests and economic viability of SMEs, including start ups. - Article 5: up to EUR 35,000,000 or 7 percent of worldwide annual turnover. - Listed operator and notified body duties: up to EUR 15,000,000 or 3 percent. - Incorrect, incomplete, or misleading information: up to EUR 7,500,000 or 1 percent. - For SMEs and start ups, the lower of the percentage or fixed amount applies. ## GPAI provider fine exposure The GPAI regime has a separate Commission fine power. Under Article 101, the Commission may impose fines on providers of general purpose AI models up to EUR 15,000,000 or 3 percent of annual worldwide turnover when the provider intentionally or negligently breaches the relevant obligations. This matters because GPAI providers answer directly to the Commission and the AI Office for Chapter V matters, not only to national enforcement channels. - Article 101 sits alongside, not inside, the main Article 99 operator ladder. - Commission enforcement powers for GPAI fines start from 2 August 2026. - Weak technical documentation, missing summaries, or failed cooperation can become enforcement issues. - Systemic risk cases attract higher supervisory attention because of potential scale. ## What authorities look at when setting the amount Article 99 says authorities should consider all relevant circumstances of the case. The Act specifically points to the nature, gravity, duration, and consequences of the infringement, the number of affected persons, prior fines, the size and market position of the operator, cooperation, and the technical and organizational measures that were implemented. That means evidence quality is not cosmetic. A weak paper trail can make an otherwise contained issue look reckless or unmanaged. - Nature, gravity, duration, and consequences of the infringement. - Number of affected persons and level of damage. - Prior fines for the same or related conduct. - Operator size, turnover, market share, cooperation, and implemented controls. ## How to lower enforcement risk in practice The best penalty reduction strategy is not a last minute legal memo. It is an operating record that shows the organization actually assessed the system, assigned the right role, implemented relevant controls, monitored outcomes, and acted quickly when issues appeared. This is especially important for transparency duties and high risk system operations, where it is easy for authorities to compare what the organization claimed with what the product actually did. - Keep signed decision records for Article 5, Annex III, Article 50, and GPAI obligations. - Retain version linked documentation, logs, and incident records. - Show prompt corrective action and cooperation when issues are found. - Do not provide incomplete or optimistic answers to authority requests. *Recommended next step* *Placement: after the enforcement section* ## Use EU AI Act (Regulation (EU) 2024/1689) Penalties and fines as a cited research workflow Research Copilot can take EU AI Act (Regulation (EU) 2024/1689) Penalties and fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU AI Act (Regulation (EU) 2024/1689) Penalties and fines](/solutions/research-copilot.md): Start from EU AI Act (Regulation (EU) 2024/1689) Penalties and fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Penalties and fines. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Article 99 penalties](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-99?ref=sorena.io) - Official support page for penalty structure and enforcement context. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/penalties-and-fines --- --- title: "EU AI Act Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/ai-act/penalties-and-fines" author: "Sorena AI" description: "Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent." keywords: - "EU AI Act penalties" - "AI Act fines" - "Article 99 fines" - "Article 101 GPAI fines" - "7 percent turnover AI Act" - "3 percent turnover AI Act" - "EU AI Act" - "Penalties" - "Article 99" - "Article 101" - "Enforcement" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Penalties and Fines Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. *EU AI Act* *Enforcement* ## EU AI Act (Regulation (EU) 2024/1689) Penalties and fines Penalty exposure follows from bad classification, weak controls, and poor evidence. The numbers matter, but so do the behaviors that create enforcement attention. Penalty analysis is useful only if it improves behavior. The AI Act penalty structure should be read as a signal about what regulators and authorities consider most serious: prohibited practices, failure of core operator duties, bad information to authorities, and non compliant GPAI provider conduct. ## Main Article 99 tiers Article 99 creates three main operator fine levels. The highest tier is reserved for prohibited practices under Article 5. The middle tier applies to listed operator and notified body duties, including provider, authorised representative, importer, distributor, deployer, notified body, and Article 50 transparency obligations. The lower tier applies to incorrect, incomplete, or misleading information supplied to notified bodies or national competent authorities. The Act also says Member States must make penalties effective, proportionate, and dissuasive, while taking account of the interests and economic viability of SMEs, including start ups. - Article 5: up to EUR 35,000,000 or 7 percent of worldwide annual turnover. - Listed operator and notified body duties: up to EUR 15,000,000 or 3 percent. - Incorrect, incomplete, or misleading information: up to EUR 7,500,000 or 1 percent. - For SMEs and start ups, the lower of the percentage or fixed amount applies. ## GPAI provider fine exposure The GPAI regime has a separate Commission fine power. Under Article 101, the Commission may impose fines on providers of general purpose AI models up to EUR 15,000,000 or 3 percent of annual worldwide turnover when the provider intentionally or negligently breaches the relevant obligations. This matters because GPAI providers answer directly to the Commission and the AI Office for Chapter V matters, not only to national enforcement channels. - Article 101 sits alongside, not inside, the main Article 99 operator ladder. - Commission enforcement powers for GPAI fines start from 2 August 2026. - Weak technical documentation, missing summaries, or failed cooperation can become enforcement issues. - Systemic risk cases attract higher supervisory attention because of potential scale. ## What authorities look at when setting the amount Article 99 says authorities should consider all relevant circumstances of the case. The Act specifically points to the nature, gravity, duration, and consequences of the infringement, the number of affected persons, prior fines, the size and market position of the operator, cooperation, and the technical and organizational measures that were implemented. That means evidence quality is not cosmetic. A weak paper trail can make an otherwise contained issue look reckless or unmanaged. - Nature, gravity, duration, and consequences of the infringement. - Number of affected persons and level of damage. - Prior fines for the same or related conduct. - Operator size, turnover, market share, cooperation, and implemented controls. ## How to lower enforcement risk in practice The best penalty reduction strategy is not a last minute legal memo. It is an operating record that shows the organization actually assessed the system, assigned the right role, implemented relevant controls, monitored outcomes, and acted quickly when issues appeared. This is especially important for transparency duties and high risk system operations, where it is easy for authorities to compare what the organization claimed with what the product actually did. - Keep signed decision records for Article 5, Annex III, Article 50, and GPAI obligations. - Retain version linked documentation, logs, and incident records. - Show prompt corrective action and cooperation when issues are found. - Do not provide incomplete or optimistic answers to authority requests. *Recommended next step* *Placement: after the enforcement section* ## Use EU AI Act (Regulation (EU) 2024/1689) Penalties and fines as a cited research workflow Research Copilot can take EU AI Act (Regulation (EU) 2024/1689) Penalties and fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU AI Act (Regulation (EU) 2024/1689) Penalties and fines](/solutions/research-copilot.md): Start from EU AI Act (Regulation (EU) 2024/1689) Penalties and fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Penalties and fines. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Article 99 penalties](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-99?ref=sorena.io) - Official support page for penalty structure and enforcement context. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/penalties-and-fines --- --- title: "EU AI Act Prohibited AI Practices" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/prohibited-ai-practices" source_url: "https://www.sorena.io/artifacts/eu/ai-act/prohibited-ai-practices" author: "Sorena AI" description: "Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities." keywords: - "EU AI Act prohibited AI practices" - "Article 5 AI Act" - "manipulative AI prohibited" - "social scoring AI Act" - "facial image scraping AI Act" - "emotion recognition workplace education AI Act" - "EU AI Act" - "Article 5" - "Prohibited practices" - "Biometrics" - "Screening" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Prohibited AI Practices Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. *EU AI Act* *Article 5* ## EU AI Act (Regulation (EU) 2024/1689) Prohibited practices Article 5 is a stop or redesign test, not a drafting exercise. Teams should run prohibited practice screening before product build hardens and again before material changes ship. Article 5 is the earliest and most severe operational gate in the AI Act. If a use case falls into a prohibited category, the answer is not better documentation. The answer is to stop, narrow, or redesign the use case. That makes early product review essential. ## What Article 5 is trying to prevent The prohibited practices target AI uses that create unacceptable risk to health, safety, or fundamental rights. The core logic is not whether the model is advanced. It is whether the use case distorts autonomy, exploits vulnerability, creates abusive surveillance or categorisation, or applies AI in especially harmful law enforcement or social control settings. This is why the screening must focus on actual use context, affected persons, and downstream actions rather than only on model type. - Manipulative or deceptive techniques causing significant harm. - Exploitation of vulnerabilities due to age, disability, or specific social or economic situation. - Social scoring that leads to detrimental or disproportionate treatment. - Certain biometric, emotion recognition, and criminal risk uses listed in Article 5. ## The prohibited practice categories teams should know cold The practical screening list should include the categories most likely to surface in design or procurement. These include manipulative or deceptive systems, exploitation of vulnerability, social scoring, certain individual criminal offence risk assessments based only on profiling or personality traits, untargeted scraping of facial images from the internet or CCTV to create facial recognition databases, and biometric categorisation that infers sensitive attributes. The Act also prohibits certain emotion recognition uses in workplace and education settings and tightly restricts real time remote biometric identification in public spaces for law enforcement, subject to narrow exception pathways. - Check for systems that steer users in ways they cannot reasonably resist or understand. - Check for use of sensitive biometric inference or facial scraping as a dataset strategy. - Check workplace and education tools for emotion recognition functions. - Check any public space biometric law enforcement scenario with specialist review. ## How to build a usable screening gate The gate should run early in product design, at procurement for external systems, and again on material changes. It should ask a short set of hard questions on affected persons, vulnerable groups, biometric features, decision consequences, and deception or manipulation risk. If any answer is high concern, the feature should not progress without formal review. This works best when product, legal, risk, and security review together. Article 5 issues are usually visible in the intended purpose, the data strategy, the user journey, or the target deployment environment. - Attach the gate to feature approval and procurement onboarding. - Use screenshots, prompts, and workflow maps as part of the review input. - Record the rationale for a not prohibited conclusion. - Block launch where a redesign decision is still open. ## Evidence and escalation Evidence for Article 5 should be simple and clear. Keep the screening result, the facts reviewed, the people who approved the decision, and any design changes made because of the review. If the use case is rejected, keep the rejection record too. That is proof that the control actually works. Escalation should be mandatory where biometrics, vulnerable groups, law enforcement use, education, workplace monitoring, or synthetic manipulation of public audiences is involved. - Decision record with date, approvers, and supporting evidence. - Blocked or redesigned feature log for high concern cases. - Escalation roster with named legal, risk, and product owners. - Periodic review of near misses to improve the screening questions. *Recommended next step* *Placement: after the scope or definition section* ## Use EU AI Act (Regulation (EU) 2024/1689) Prohibited practices as a cited research workflow Research Copilot can take EU AI Act (Regulation (EU) 2024/1689) Prohibited practices from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU AI Act (Regulation (EU) 2024/1689) Prohibited practices](/solutions/research-copilot.md): Start from EU AI Act (Regulation (EU) 2024/1689) Prohibited practices and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Prohibited practices. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - AI Act Explorer](https://ai-act-service-desk.ec.europa.eu/en/ai-act-explorer?ref=sorena.io) - Official article and annex navigator maintained for implementation support. - [AI Act Service Desk - Article 99 penalties](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-99?ref=sorena.io) - Official support page for penalty structure and enforcement context. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/prohibited-ai-practices --- --- title: "EU AI Act Prohibited AI Practices" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/prohibited-ai-practices" source_url: "https://www.sorena.io/artifacts/eu/ai-act/prohibited-ai-practices" author: "Sorena AI" description: "Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities." keywords: - "EU AI Act prohibited AI practices" - "Article 5 AI Act" - "manipulative AI prohibited" - "social scoring AI Act" - "facial image scraping AI Act" - "emotion recognition workplace education AI Act" - "EU AI Act" - "Article 5" - "Prohibited practices" - "Biometrics" - "Screening" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Prohibited AI Practices Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. *EU AI Act* *Article 5* ## EU AI Act (Regulation (EU) 2024/1689) Prohibited practices Article 5 is a stop or redesign test, not a drafting exercise. Teams should run prohibited practice screening before product build hardens and again before material changes ship. Article 5 is the earliest and most severe operational gate in the AI Act. If a use case falls into a prohibited category, the answer is not better documentation. The answer is to stop, narrow, or redesign the use case. That makes early product review essential. ## What Article 5 is trying to prevent The prohibited practices target AI uses that create unacceptable risk to health, safety, or fundamental rights. The core logic is not whether the model is advanced. It is whether the use case distorts autonomy, exploits vulnerability, creates abusive surveillance or categorisation, or applies AI in especially harmful law enforcement or social control settings. This is why the screening must focus on actual use context, affected persons, and downstream actions rather than only on model type. - Manipulative or deceptive techniques causing significant harm. - Exploitation of vulnerabilities due to age, disability, or specific social or economic situation. - Social scoring that leads to detrimental or disproportionate treatment. - Certain biometric, emotion recognition, and criminal risk uses listed in Article 5. ## The prohibited practice categories teams should know cold The practical screening list should include the categories most likely to surface in design or procurement. These include manipulative or deceptive systems, exploitation of vulnerability, social scoring, certain individual criminal offence risk assessments based only on profiling or personality traits, untargeted scraping of facial images from the internet or CCTV to create facial recognition databases, and biometric categorisation that infers sensitive attributes. The Act also prohibits certain emotion recognition uses in workplace and education settings and tightly restricts real time remote biometric identification in public spaces for law enforcement, subject to narrow exception pathways. - Check for systems that steer users in ways they cannot reasonably resist or understand. - Check for use of sensitive biometric inference or facial scraping as a dataset strategy. - Check workplace and education tools for emotion recognition functions. - Check any public space biometric law enforcement scenario with specialist review. ## How to build a usable screening gate The gate should run early in product design, at procurement for external systems, and again on material changes. It should ask a short set of hard questions on affected persons, vulnerable groups, biometric features, decision consequences, and deception or manipulation risk. If any answer is high concern, the feature should not progress without formal review. This works best when product, legal, risk, and security review together. Article 5 issues are usually visible in the intended purpose, the data strategy, the user journey, or the target deployment environment. - Attach the gate to feature approval and procurement onboarding. - Use screenshots, prompts, and workflow maps as part of the review input. - Record the rationale for a not prohibited conclusion. - Block launch where a redesign decision is still open. ## Evidence and escalation Evidence for Article 5 should be simple and clear. Keep the screening result, the facts reviewed, the people who approved the decision, and any design changes made because of the review. If the use case is rejected, keep the rejection record too. That is proof that the control actually works. Escalation should be mandatory where biometrics, vulnerable groups, law enforcement use, education, workplace monitoring, or synthetic manipulation of public audiences is involved. - Decision record with date, approvers, and supporting evidence. - Blocked or redesigned feature log for high concern cases. - Escalation roster with named legal, risk, and product owners. - Periodic review of near misses to improve the screening questions. *Recommended next step* *Placement: after the scope or definition section* ## Use EU AI Act (Regulation (EU) 2024/1689) Prohibited practices as a cited research workflow Research Copilot can take EU AI Act (Regulation (EU) 2024/1689) Prohibited practices from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU AI Act (Regulation (EU) 2024/1689) Prohibited practices](/solutions/research-copilot.md): Start from EU AI Act (Regulation (EU) 2024/1689) Prohibited practices and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Prohibited practices. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - AI Act Explorer](https://ai-act-service-desk.ec.europa.eu/en/ai-act-explorer?ref=sorena.io) - Official article and annex navigator maintained for implementation support. - [AI Act Service Desk - Article 99 penalties](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-99?ref=sorena.io) - Official support page for penalty structure and enforcement context. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/prohibited-ai-practices --- --- title: "EU AI Act Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/requirements" source_url: "https://www.sorena.io/artifacts/eu/ai-act/requirements" author: "Sorena AI" description: "Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems." keywords: - "EU AI Act requirements" - "AI Act obligations overview" - "Article 5 Article 6 Article 50 Chapter V" - "high risk requirements" - "GPAI requirements" - "transparency requirements" - "EU AI Act" - "Requirements" - "Article 5" - "Article 50" - "Chapter V" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Requirements Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. *EU AI Act* *Overview* ## EU AI Act (Regulation (EU) 2024/1689) Requirements overview The Act routes systems and models into obligation sets. Compliance starts with correct routing. This page summarizes the four main requirement tracks and the evidence each one drives. A good AI Act implementation begins with a simple question: which requirement track applies to this system or model? The Regulation is not one flat checklist. It imposes different obligations depending on whether the system is prohibited, high risk, subject to transparency duties, or connected to GPAI provider obligations. ## Track one: prohibited practices If Article 5 applies, the correct operational outcome is prevention. These are not use cases you mitigate into compliance through documentation alone. Product and procurement teams need an active gate that screens for manipulation, exploitation of vulnerability, social scoring, prohibited biometric practices, and other listed categories. Because Article 5 infringements carry the highest penalties, this track should be visible at executive level. - Key output: screening record and stop or redesign decision. - Key owners: product, legal, risk, security. - Key evidence: use case rationale, user journey, data and biometric review. - Key review timing: intake, procurement, and material changes. ## Track two: high risk systems High risk obligations apply through the product safety route in Article 6(1) or the Annex III route in Article 6(2). Once a system is high risk, the provider and deployer evidence standard increases sharply. Articles 9 to 15 set the technical and organizational core, but the surrounding duties on conformity, registration, monitoring, retention, and user information matter just as much. This track is where most enterprise implementation work sits because it touches architecture, data governance, testing, human oversight, and post market operations. - Key output: Annex IV aligned technical documentation and control evidence. - Key owners: provider, deployer, engineering, risk, quality, operations. - Key evidence: risk management, data governance, logging, oversight, accuracy, cybersecurity, FRIA where applicable. - Key review timing: design, pre release, and post market monitoring. ## Track three: transparency duties Article 50 creates obligations where natural persons interact directly with AI systems, where synthetic outputs must be machine readable and detectable, where emotion recognition or biometric categorisation systems are used, and where deepfakes or certain AI generated text are deployed. This work belongs inside product, design, accessibility, editorial, and QA processes. Transparency is not solved by a generic footer. The notice has to appear in the right interface, at the right moment, and often with technical marking or logging behind it. - Key output: disclosure and marking design across product surfaces. - Key owners: product, design, content, engineering, QA. - Key evidence: copy library, screenshots, machine readable marking logic, and display logs. - Key review timing: feature design, release, and model or content pipeline changes. ## Track four: GPAI provider obligations Chapter V applies to providers of general purpose AI models. It requires model level technical documentation, downstream documentation, a copyright policy, and a public summary of training content. Systemic risk adds compute threshold monitoring, notification, mitigation, and serious incident response expectations. Even organizations that are not GPAI providers need to understand this track because they often depend on upstream model suppliers for evidence and contractual support. - Key output: Article 53 to 55 artifact set and supplier evidence model. - Key owners: model provider, legal, security, documentation, operations. - Key evidence: training content summary, copyright policy, technical documentation, notification and incident records. - Key review timing: before market placement, on major model changes, and during systemic risk monitoring. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU AI Act (Regulation (EU) 2024/1689) Requirements overview into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) Requirements overview from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) Requirements overview](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) Requirements overview and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Requirements overview. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Annex III high risk use cases](https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3?ref=sorena.io) - Official annex landing page for high risk use cases. - [AI Act Service Desk - Article 50 transparency obligations](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50?ref=sorena.io) - Official support page for interaction, disclosure, and deepfake duties. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/requirements --- --- title: "EU AI Act Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/requirements" source_url: "https://www.sorena.io/artifacts/eu/ai-act/requirements" author: "Sorena AI" description: "Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems." keywords: - "EU AI Act requirements" - "AI Act obligations overview" - "Article 5 Article 6 Article 50 Chapter V" - "high risk requirements" - "GPAI requirements" - "transparency requirements" - "EU AI Act" - "Requirements" - "Article 5" - "Article 50" - "Chapter V" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Requirements Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. *EU AI Act* *Overview* ## EU AI Act (Regulation (EU) 2024/1689) Requirements overview The Act routes systems and models into obligation sets. Compliance starts with correct routing. This page summarizes the four main requirement tracks and the evidence each one drives. A good AI Act implementation begins with a simple question: which requirement track applies to this system or model? The Regulation is not one flat checklist. It imposes different obligations depending on whether the system is prohibited, high risk, subject to transparency duties, or connected to GPAI provider obligations. ## Track one: prohibited practices If Article 5 applies, the correct operational outcome is prevention. These are not use cases you mitigate into compliance through documentation alone. Product and procurement teams need an active gate that screens for manipulation, exploitation of vulnerability, social scoring, prohibited biometric practices, and other listed categories. Because Article 5 infringements carry the highest penalties, this track should be visible at executive level. - Key output: screening record and stop or redesign decision. - Key owners: product, legal, risk, security. - Key evidence: use case rationale, user journey, data and biometric review. - Key review timing: intake, procurement, and material changes. ## Track two: high risk systems High risk obligations apply through the product safety route in Article 6(1) or the Annex III route in Article 6(2). Once a system is high risk, the provider and deployer evidence standard increases sharply. Articles 9 to 15 set the technical and organizational core, but the surrounding duties on conformity, registration, monitoring, retention, and user information matter just as much. This track is where most enterprise implementation work sits because it touches architecture, data governance, testing, human oversight, and post market operations. - Key output: Annex IV aligned technical documentation and control evidence. - Key owners: provider, deployer, engineering, risk, quality, operations. - Key evidence: risk management, data governance, logging, oversight, accuracy, cybersecurity, FRIA where applicable. - Key review timing: design, pre release, and post market monitoring. ## Track three: transparency duties Article 50 creates obligations where natural persons interact directly with AI systems, where synthetic outputs must be machine readable and detectable, where emotion recognition or biometric categorisation systems are used, and where deepfakes or certain AI generated text are deployed. This work belongs inside product, design, accessibility, editorial, and QA processes. Transparency is not solved by a generic footer. The notice has to appear in the right interface, at the right moment, and often with technical marking or logging behind it. - Key output: disclosure and marking design across product surfaces. - Key owners: product, design, content, engineering, QA. - Key evidence: copy library, screenshots, machine readable marking logic, and display logs. - Key review timing: feature design, release, and model or content pipeline changes. ## Track four: GPAI provider obligations Chapter V applies to providers of general purpose AI models. It requires model level technical documentation, downstream documentation, a copyright policy, and a public summary of training content. Systemic risk adds compute threshold monitoring, notification, mitigation, and serious incident response expectations. Even organizations that are not GPAI providers need to understand this track because they often depend on upstream model suppliers for evidence and contractual support. - Key output: Article 53 to 55 artifact set and supplier evidence model. - Key owners: model provider, legal, security, documentation, operations. - Key evidence: training content summary, copyright policy, technical documentation, notification and incident records. - Key review timing: before market placement, on major model changes, and during systemic risk monitoring. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU AI Act (Regulation (EU) 2024/1689) Requirements overview into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) Requirements overview from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) Requirements overview](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) Requirements overview and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Requirements overview. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Annex III high risk use cases](https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3?ref=sorena.io) - Official annex landing page for high risk use cases. - [AI Act Service Desk - Article 50 transparency obligations](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50?ref=sorena.io) - Official support page for interaction, disclosure, and deepfake duties. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/requirements --- --- title: "EU AI Act Timeline and Phasing Roadmap" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/timeline-and-phasing-roadmap" source_url: "https://www.sorena.io/artifacts/eu/ai-act/timeline-and-phasing-roadmap" author: "Sorena AI" description: "Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations." keywords: - "EU AI Act roadmap" - "AI Act phasing roadmap" - "AI Act implementation roadmap" - "2025 2026 2027 AI Act roadmap" - "GPAI roadmap" - "high risk roadmap" - "EU AI Act" - "Roadmap" - "Timeline" - "GPAI" - "High risk" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Timeline and Phasing Roadmap Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. *EU AI Act* *Roadmap* ## EU AI Act (Regulation (EU) 2024/1689) Timeline and roadmap Use the phase dates to sequence evidence, owners, and build work. This roadmap focuses on what should be operational in each phase, not only what the law says. A strong AI Act roadmap should reduce surprise. That means using the legal phasing to bring the right controls live in the right order: early prohibitions and literacy first, GPAI documentation next, and full high risk and transparency operating controls by the main application date. ## Phase 1: build the foundation Start with inventory, roles, and classification. Without a clean register and a role matrix, every downstream workstream becomes slow and error prone. Foundation work also includes the evidence repository, the approval forum, and the first supplier documentation requests. This phase should start as early as possible and should not wait for the first major legal date. - AI system and model inventory live. - Applicability and role workflow live. - Supplier evidence requests defined. - Decision record template and repository live. ## Phase 2: early obligations and guardrails The first hard operating gates are Article 5 and AI literacy. Product teams, operations teams, and oversight roles should all understand what they are screening for and where escalation is mandatory. This phase also sets the tone for authority ready evidence later on. If the foundation exists but the Article 5 gate does not, the program still has a dangerous hole. - Article 5 gate attached to intake and release. - AI literacy training assigned by role. - Escalation path documented for high concern cases. - Board or program level reporting on blocked or redesigned cases. ## Phase 3: GPAI and supplier readiness This phase prepares for the 2 August 2025 Chapter V start date. Model providers need their Article 53 workflow and any systemic risk path. Integrators need contract and evidence leverage over upstream model suppliers. Do not treat GPAI work as relevant only to frontier model labs. Many product teams rely on upstream models and still need supplier documentation, version notices, and incident support. - Article 53 documentation and publication workflow live. - Training content summary and copyright policy governance live. - Systemic risk threshold and notification path defined. - Upstream supplier clauses updated and tracked. ## Phase 4: high risk and transparency buildout This is the deepest implementation phase because it reaches engineering design, testing, deployment, and operations. High risk systems need Articles 9 to 15 evidence, FRIA where required, and post market readiness. Transparency duties need actual product components, machine readable marking logic, QA evidence, and release review discipline. By the time this phase ends, the organization should be able to show how the law is implemented in live systems, not only in policy documents. - High risk technical documentation and testing evidence complete. - FRIA and affected person information process live where required. - Article 50 components, copy, and marking logic in production. - Incident and corrective action workflows tested. ## Phase 5: transition cases and steady state operation After the main application date, the roadmap becomes a portfolio management problem. Legacy GPAI models, public authority deployments, and Annex X transition cases need explicit tracking. At the same time, all production systems need recurring review because the Act is sensitive to changes in intended purpose, risk profile, and system design. This is also where the program should mature into regular audit, management review, and corrective action loops. - Legacy GPAI models assigned to 2027 remediation plans. - Public authority and Annex X transition cases tracked to their longer deadlines. - Quarterly portfolio review linked to product and model change control. - Annual evidence readiness review and remediation plan. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Turn EU AI Act (Regulation (EU) 2024/1689) Timeline and roadmap into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) Timeline and roadmap from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) Timeline and roadmap](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) Timeline and roadmap and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Timeline and roadmap. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Implementation timeline](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act?ref=sorena.io) - Official staging reference for phased application dates. - [European Commission - AI Act enters into force on 1 August 2024](https://commission.europa.eu/news-and-media/news/ai-act-enters-force-2024-08-01_en?ref=sorena.io) - Commission implementation overview and key dates. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/timeline-and-phasing-roadmap --- --- title: "EU AI Act Timeline and Phasing Roadmap" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/timeline-and-phasing-roadmap" source_url: "https://www.sorena.io/artifacts/eu/ai-act/timeline-and-phasing-roadmap" author: "Sorena AI" description: "Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations." keywords: - "EU AI Act roadmap" - "AI Act phasing roadmap" - "AI Act implementation roadmap" - "2025 2026 2027 AI Act roadmap" - "GPAI roadmap" - "high risk roadmap" - "EU AI Act" - "Roadmap" - "Timeline" - "GPAI" - "High risk" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Timeline and Phasing Roadmap Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. *EU AI Act* *Roadmap* ## EU AI Act (Regulation (EU) 2024/1689) Timeline and roadmap Use the phase dates to sequence evidence, owners, and build work. This roadmap focuses on what should be operational in each phase, not only what the law says. A strong AI Act roadmap should reduce surprise. That means using the legal phasing to bring the right controls live in the right order: early prohibitions and literacy first, GPAI documentation next, and full high risk and transparency operating controls by the main application date. ## Phase 1: build the foundation Start with inventory, roles, and classification. Without a clean register and a role matrix, every downstream workstream becomes slow and error prone. Foundation work also includes the evidence repository, the approval forum, and the first supplier documentation requests. This phase should start as early as possible and should not wait for the first major legal date. - AI system and model inventory live. - Applicability and role workflow live. - Supplier evidence requests defined. - Decision record template and repository live. ## Phase 2: early obligations and guardrails The first hard operating gates are Article 5 and AI literacy. Product teams, operations teams, and oversight roles should all understand what they are screening for and where escalation is mandatory. This phase also sets the tone for authority ready evidence later on. If the foundation exists but the Article 5 gate does not, the program still has a dangerous hole. - Article 5 gate attached to intake and release. - AI literacy training assigned by role. - Escalation path documented for high concern cases. - Board or program level reporting on blocked or redesigned cases. ## Phase 3: GPAI and supplier readiness This phase prepares for the 2 August 2025 Chapter V start date. Model providers need their Article 53 workflow and any systemic risk path. Integrators need contract and evidence leverage over upstream model suppliers. Do not treat GPAI work as relevant only to frontier model labs. Many product teams rely on upstream models and still need supplier documentation, version notices, and incident support. - Article 53 documentation and publication workflow live. - Training content summary and copyright policy governance live. - Systemic risk threshold and notification path defined. - Upstream supplier clauses updated and tracked. ## Phase 4: high risk and transparency buildout This is the deepest implementation phase because it reaches engineering design, testing, deployment, and operations. High risk systems need Articles 9 to 15 evidence, FRIA where required, and post market readiness. Transparency duties need actual product components, machine readable marking logic, QA evidence, and release review discipline. By the time this phase ends, the organization should be able to show how the law is implemented in live systems, not only in policy documents. - High risk technical documentation and testing evidence complete. - FRIA and affected person information process live where required. - Article 50 components, copy, and marking logic in production. - Incident and corrective action workflows tested. ## Phase 5: transition cases and steady state operation After the main application date, the roadmap becomes a portfolio management problem. Legacy GPAI models, public authority deployments, and Annex X transition cases need explicit tracking. At the same time, all production systems need recurring review because the Act is sensitive to changes in intended purpose, risk profile, and system design. This is also where the program should mature into regular audit, management review, and corrective action loops. - Legacy GPAI models assigned to 2027 remediation plans. - Public authority and Annex X transition cases tracked to their longer deadlines. - Quarterly portfolio review linked to product and model change control. - Annual evidence readiness review and remediation plan. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Turn EU AI Act (Regulation (EU) 2024/1689) Timeline and roadmap into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) Timeline and roadmap from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) Timeline and roadmap](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) Timeline and roadmap and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Timeline and roadmap. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Implementation timeline](https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act?ref=sorena.io) - Official staging reference for phased application dates. - [European Commission - AI Act enters into force on 1 August 2024](https://commission.europa.eu/news-and-media/news/ai-act-enters-force-2024-08-01_en?ref=sorena.io) - Commission implementation overview and key dates. - [European Commission - Guidelines for providers of general purpose AI models](https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers?ref=sorena.io) - Official guidance on Chapter V scope, timelines, and AI Office expectations. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Transparency, Labeling, and User Disclosures | Article 50 Guide](/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures.md): Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/timeline-and-phasing-roadmap --- --- title: "EU AI Act Transparency, Labeling, and User Disclosures" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures" source_url: "https://www.sorena.io/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures" author: "Sorena AI" description: "Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures." keywords: - "EU AI Act transparency" - "Article 50 guide" - "AI generated content labeling EU AI Act" - "deepfake disclosure AI Act" - "machine readable marking AI Act" - "user disclosure AI Act" - "EU AI Act" - "Article 50" - "Transparency" - "Deepfake" - "AI generated content" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Transparency, Labeling, and User Disclosures Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. *EU AI Act* *Article 50* ## EU AI Act (Regulation (EU) 2024/1689) Transparency and labeling Article 50 is product work, design work, and evidence work. Teams need to know where disclosures appear, when machine readable marking is required, and what proof to keep. Transparency is one of the most visible parts of the AI Act because users, deployers, buyers, and authorities can all see when it fails. The law covers several different situations, so the first implementation step is to map each trigger to the product or content surface where it actually appears. ## Interaction notices and exposed person notices Article 50 requires providers of AI systems intended to interact directly with natural persons to inform those persons that they are interacting with an AI system, unless the use is obvious from the perspective of a reasonably well informed and observant person in context. This is a user journey question, not a generic site footer question. Deployers of emotion recognition systems and biometric categorisation systems also have to inform natural persons exposed to their operation, subject to the law enforcement exception structure in the Regulation. - Map every surface where a user could reasonably mistake an AI interaction for a human one. - Check exposed person notices for biometric categorisation and emotion recognition deployments. - Review accessibility, localization, and timing of the notice. - Store screenshots and version history for each notice location. ## Machine readable marking of synthetic outputs Providers of systems generating synthetic audio, image, video, or text content must ensure outputs are marked in a machine readable format and detectable as artificially generated or manipulated, where the article requires it. The law also says the technical solution should be effective, interoperable, robust, and reliable as far as technically feasible, taking account of content type, implementation cost, and the state of the art. This is a technical implementation problem as much as a legal one. Teams should define where the marking is created, how it survives downstream handling, and how QA verifies it. - Document the marking method for each modality. - Test detectability after normal export and platform handling. - Record where an assistive or non substantial edit exception is being relied on. - Keep release notes when marking logic changes. ## Deepfakes and public interest text Deployers of systems that generate or manipulate image, audio, or video content constituting a deepfake must disclose that the content has been artificially generated or manipulated. For artistic, satirical, fictional, or analogous works, the disclosure must still exist but can be adapted so it does not undermine the normal display or enjoyment of the work. AI generated or manipulated text published to inform the public on matters of public interest also needs disclosure unless it has undergone human review or editorial control and a natural or legal person holds editorial responsibility for the publication. - Identify every deepfake capable workflow across product, marketing, and content teams. - Define the disclosure treatment for creative or fictional works. - Define editorial responsibility checks for public interest text workflows. - Keep approval records for exceptions based on human review and editorial control. ## Evidence, change control, and UX quality The strongest transparency programs treat disclosures as reusable interface components with design system rules, accessibility review, and regression testing. That improves consistency and reduces the risk that a new feature quietly removes or hides a required notice. Evidence should show where the disclosure appears, which copy version is live, what technical marking is used, and what event triggers re review. - Disclosure component library with design and content ownership. - Release checklist requiring Article 50 review on model and feature changes. - QA scripts that verify notices and marking across key flows and devices. - Privacy minimised evidence showing notice display and control effectiveness. *Recommended next step* *Placement: near the end of the main content before related guides* ## Turn EU AI Act (Regulation (EU) 2024/1689) Transparency and labeling into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) Transparency and labeling from turning this guidance into an operational assessment workflow to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) Transparency and labeling](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) Transparency and labeling and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Transparency and labeling. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Article 50 transparency obligations](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50?ref=sorena.io) - Official support page for interaction, disclosure, and deepfake duties. - [European Commission - Code of practice on marking and labelling of AI generated content](https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content?ref=sorena.io) - Official implementation aid for machine readable marking and public disclosures. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures --- --- title: "EU AI Act Transparency, Labeling, and User Disclosures" canonical_url: "https://www.sorena.io/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures" source_url: "https://www.sorena.io/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures" author: "Sorena AI" description: "Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures." keywords: - "EU AI Act transparency" - "Article 50 guide" - "AI generated content labeling EU AI Act" - "deepfake disclosure AI Act" - "machine readable marking AI Act" - "user disclosure AI Act" - "EU AI Act" - "Article 50" - "Transparency" - "Deepfake" - "AI generated content" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU AI Act Transparency, Labeling, and User Disclosures Implement EU AI Act Article 50 transparency duties for direct interaction notices, machine readable marking of synthetic outputs, deepfake disclosures. *EU AI Act* *Article 50* ## EU AI Act (Regulation (EU) 2024/1689) Transparency and labeling Article 50 is product work, design work, and evidence work. Teams need to know where disclosures appear, when machine readable marking is required, and what proof to keep. Transparency is one of the most visible parts of the AI Act because users, deployers, buyers, and authorities can all see when it fails. The law covers several different situations, so the first implementation step is to map each trigger to the product or content surface where it actually appears. ## Interaction notices and exposed person notices Article 50 requires providers of AI systems intended to interact directly with natural persons to inform those persons that they are interacting with an AI system, unless the use is obvious from the perspective of a reasonably well informed and observant person in context. This is a user journey question, not a generic site footer question. Deployers of emotion recognition systems and biometric categorisation systems also have to inform natural persons exposed to their operation, subject to the law enforcement exception structure in the Regulation. - Map every surface where a user could reasonably mistake an AI interaction for a human one. - Check exposed person notices for biometric categorisation and emotion recognition deployments. - Review accessibility, localization, and timing of the notice. - Store screenshots and version history for each notice location. ## Machine readable marking of synthetic outputs Providers of systems generating synthetic audio, image, video, or text content must ensure outputs are marked in a machine readable format and detectable as artificially generated or manipulated, where the article requires it. The law also says the technical solution should be effective, interoperable, robust, and reliable as far as technically feasible, taking account of content type, implementation cost, and the state of the art. This is a technical implementation problem as much as a legal one. Teams should define where the marking is created, how it survives downstream handling, and how QA verifies it. - Document the marking method for each modality. - Test detectability after normal export and platform handling. - Record where an assistive or non substantial edit exception is being relied on. - Keep release notes when marking logic changes. ## Deepfakes and public interest text Deployers of systems that generate or manipulate image, audio, or video content constituting a deepfake must disclose that the content has been artificially generated or manipulated. For artistic, satirical, fictional, or analogous works, the disclosure must still exist but can be adapted so it does not undermine the normal display or enjoyment of the work. AI generated or manipulated text published to inform the public on matters of public interest also needs disclosure unless it has undergone human review or editorial control and a natural or legal person holds editorial responsibility for the publication. - Identify every deepfake capable workflow across product, marketing, and content teams. - Define the disclosure treatment for creative or fictional works. - Define editorial responsibility checks for public interest text workflows. - Keep approval records for exceptions based on human review and editorial control. ## Evidence, change control, and UX quality The strongest transparency programs treat disclosures as reusable interface components with design system rules, accessibility review, and regression testing. That improves consistency and reduces the risk that a new feature quietly removes or hides a required notice. Evidence should show where the disclosure appears, which copy version is live, what technical marking is used, and what event triggers re review. - Disclosure component library with design and content ownership. - Release checklist requiring Article 50 review on model and feature changes. - QA scripts that verify notices and marking across key flows and devices. - Privacy minimised evidence showing notice display and control effectiveness. *Recommended next step* *Placement: near the end of the main content before related guides* ## Turn EU AI Act (Regulation (EU) 2024/1689) Transparency and labeling into an operational assessment Assessment Autopilot can take EU AI Act (Regulation (EU) 2024/1689) Transparency and labeling from turning this guidance into an operational assessment workflow to a reusable workflow inside Sorena. Teams working on EU AI Act (Regulation (EU) 2024/1689) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU AI Act (Regulation (EU) 2024/1689) Transparency and labeling](/solutions/assessment.md): Start from EU AI Act (Regulation (EU) 2024/1689) Transparency and labeling and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU AI Act (Regulation (EU) 2024/1689)](/contact.md): Review your current process, evidence gaps, and next steps for EU AI Act (Regulation (EU) 2024/1689) Transparency and labeling. ## Primary sources - [Regulation (EU) 2024/1689 (EU AI Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal text for scope, obligations, annexes, transition rules, and penalties. - [AI Act Service Desk - Article 50 transparency obligations](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50?ref=sorena.io) - Official support page for interaction, disclosure, and deepfake duties. - [European Commission - Code of practice on marking and labelling of AI generated content](https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content?ref=sorena.io) - Official implementation aid for machine readable marking and public disclosures. ## Related Topic Guides - [EU AI Act Applicability and Roles | Provider, Deployer, Importer Guide](/artifacts/eu/ai-act/applicability-and-roles.md): Determine whether the EU AI Act applies, when output used in the Union brings a system into scope, and how to assign provider, deployer, importer. - [EU AI Act Applicability Test | Scope, Role, and Obligation Routing](/artifacts/eu/ai-act/applicability-test.md): Run a practical EU AI Act applicability test that checks scope, exclusions, operator role, prohibited practices, high risk status, transparency triggers. - [EU AI Act Checklist | Practical Compliance Checklist by Obligation](/artifacts/eu/ai-act/checklist.md): Use a detailed EU AI Act checklist covering inventory, role mapping, Article 5 screening, high risk controls, Article 50 disclosures, GPAI evidence, logging. - [EU AI Act Compliance Program | Build an Operational AI Act Program](/artifacts/eu/ai-act/compliance.md): Build an EU AI Act compliance program that covers inventory, governance, AI literacy, prohibited practice gates, high risk controls, Article 50 product work. - [EU AI Act Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/ai-act/deadlines-and-compliance-calendar.md): Track the exact EU AI Act dates, including entry into force on 1 August 2024, early obligations from 2 February 2025, GPAI obligations from 2 August 2025. - [EU AI Act FAQ | Dates, High Risk, GPAI, Transparency, and Penalties](/artifacts/eu/ai-act/faq.md): Get grounded answers to common EU AI Act questions on application dates, high risk status, provider versus deployer roles, transparency. - [EU AI Act GPAI and Foundation Model Obligations | Chapter V Guide](/artifacts/eu/ai-act/gpai-and-foundation-model-obligations.md): Understand EU AI Act obligations for general purpose AI model providers, including Article 53 documentation, copyright policy. - [EU AI Act High Risk AI Use Cases by Industry | Annex III and Product Routes](/artifacts/eu/ai-act/high-risk-ai-use-cases-by-industry.md): See how EU AI Act high risk status appears across biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration. - [EU AI Act High Risk Requirements Checklist | Articles 9 to 15 and Beyond](/artifacts/eu/ai-act/high-risk-requirements-checklist.md): Use a detailed high risk AI checklist covering Article 9 risk management, Article 10 data governance, Annex IV technical documentation, logging, instructions. - [EU AI Act Penalties and Fines | Article 99 and GPAI Fine Exposure](/artifacts/eu/ai-act/penalties-and-fines.md): Understand EU AI Act penalty tiers, including Article 5 fines up to EUR 35,000,000 or 7 percent. - [EU AI Act Prohibited AI Practices | Article 5 Screening Guide](/artifacts/eu/ai-act/prohibited-ai-practices.md): Screen AI systems against EU AI Act Article 5 prohibited practices, including manipulative and deceptive techniques, exploitation of vulnerabilities. - [EU AI Act Requirements | Prohibited, High Risk, Transparency, and GPAI](/artifacts/eu/ai-act/requirements.md): Get a grounded overview of EU AI Act requirements across Article 5 prohibited practices, Article 6 and Annex III high risk systems. - [EU AI Act Timeline and Phasing Roadmap | Practical Implementation Roadmap](/artifacts/eu/ai-act/timeline-and-phasing-roadmap.md): Follow a practical EU AI Act roadmap that aligns workstreams to the phased application dates for prohibited practices, AI literacy, GPAI obligations. - [EU AI Act vs ISO 42001 | What ISO 42001 Covers and What It Does Not](/artifacts/eu/ai-act/eu-ai-act-vs-iso-42001.md): Compare the EU AI Act with ISO/IEC 42001:2023. Learn where ISO 42001 helps with AI policy, roles, risk assessment, impact assessment, documented information. - [EU AI Act vs NIST AI RMF | How to Use AI RMF Without Missing AI Act Duties](/artifacts/eu/ai-act/eu-ai-act-vs-nist-ai-rmf.md): Compare the EU AI Act with NIST AI RMF 1.0. Learn how the voluntary NIST AI RMF functions Govern, Map, Measure. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/ai-act/transparency-labeling-and-user-disclosures --- --- title: "EU Batteries Regulation Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/applicability-test" author: "Sorena AI" description: "Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Batteries Regulation applicability test" - "Regulation (EU) 2023/1542 applicability" - "battery category test" - "portable LMT SLI industrial EV battery test" - "battery passport applicability" - "carbon footprint applicability" - "due diligence applicability" - "EU Batteries Regulation" - "Applicability test" - "Battery category" - "Battery passport" - "Due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Batteries Regulation Applicability Test Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV. *EU Batteries Regulation* *Applicability test* ## EU Batteries Regulation (Regulation (EU) 2023/1542) Applicability test Decide the battery category first, then route the battery to the right legal track. This test is designed for product owners, importers, compliance teams, and supplier managers who need a consistent scope record. The Batteries Regulation is broad enough that category mistakes have a cascading effect. If the battery is misclassified, the wrong label rules, wrong passport timeline, wrong due diligence assumptions, and wrong waste obligations will follow. Use this intake workflow per battery model and per manufacturing configuration, not only per commercial product family. ## Step 1: define the battery model under review Record the exact battery model, chemistry, intended use, weight, capacity, manufacturing plant, and whether the battery is sold standalone or incorporated into a product. Article 7 and Article 8 are plant specific for several declarations, so one trade name is not enough for the compliance record. If the battery will be repurposed, remanufactured, or sold in multiple formats, keep those routes separate. The Regulation treats some lifecycle changes as new compliance events. - Record model identifier, plant, chemistry, and capacity. - Record whether the battery is sold standalone, in an appliance, in a vehicle, or in an energy storage system. - Record whether the operator is manufacturer, importer, distributor, producer, repurposer, or remanufacturer. - Set a reclassification trigger for new use cases, new suppliers, new plant, or repurposing. ## Step 2: classify the battery category using the legal definitions The weight thresholds matter. A portable battery is sealed, 5 kg or less, not specifically designed for industrial use, and not an EV, LMT, or SLI battery. An LMT battery is sealed, 25 kg or less, and specifically designed for traction in light means of transport. An EV battery is specifically designed for traction in category L vehicles when it weighs more than 25 kg or for category M, N, or O vehicles. An industrial battery covers batteries specifically designed for industrial uses, repurposed batteries intended for industrial uses, and any other battery weighing more than 5 kg that does not fit EV, LMT, or SLI. Do not use marketing language alone. Use the legal definition plus the actual intended use. For example, a domestic storage battery can still be an industrial battery for the Regulation. - Portable: sealed, 5 kg or less, non industrial, non EV, non LMT, non SLI. - LMT: sealed, 25 kg or less, traction battery for light means of transport. - SLI: specifically designed for starting, lighting, or ignition. - Industrial: industrial use, repurposed industrial use, or over 5 kg if no other category fits. - EV: traction battery for eligible road vehicles and the heavier category L route. ## Step 3: map date driven obligations to the category Once the category is fixed, the timeline becomes clearer. The Regulation applies from 18 February 2024, but some provisions start later. Chapter VIII due diligence starts on 18 August 2025. Article 11 removability starts on 18 February 2027. QR code marking and battery passport obligations also start on 18 February 2027, but battery passport applies only to LMT batteries, industrial batteries above 2 kWh, and EV batteries. Carbon footprint, recycled content, and collection obligations also split by category and date. These are not one size fits all requirements. - Carbon footprint declaration: EV from 18 February 2025, industrial above 2 kWh from 18 February 2026, LMT from 18 August 2028, industrial with external storage from 18 August 2030. - Battery passport: LMT, EV, and industrial batteries above 2 kWh from 18 February 2027. - Article 14 state of health data: stationary battery energy storage systems, LMT, and EV from 18 August 2024. - Article 8 recycled content disclosure and minimum share duties depend on category and much later dates. - Portable and LMT collection targets sit in the waste chapter and should be mapped by producer role and Member State. ## Step 4: produce the minimum scope record A useful scope record is one page long and versioned. It should show the category decision, role decision, obligations triggered, dates that matter, and the evidence owner for each track. This record is the basis for label design, passport build, supplier due diligence, and market surveillance readiness. - Category rationale with weight, intended use, and exclusions noted. - Role map showing who owns the battery label, QR, passport, due diligence, and waste reporting. - Date matrix showing the first live obligation date for this model. - Review trigger list for plant change, repurposing, chemistry change, and new market placement. *Recommended next step* *Placement: after the applicability result* ## Operationalize EU Batteries Regulation (Regulation (EU) 2023/1542) Applicability test across ESG workflows ESG Compliance can take EU Batteries Regulation (Regulation (EU) 2023/1542) Applicability test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU Batteries Regulation (Regulation (EU) 2023/1542) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Batteries Regulation (Regulation (EU) 2023/1542) Applicability test](/solutions/esg-compliance.md): Start from EU Batteries Regulation (Regulation (EU) 2023/1542) Applicability test and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Batteries Regulation (Regulation (EU) 2023/1542)](/contact.md): Review your current process, evidence gaps, and next steps for EU Batteries Regulation (Regulation (EU) 2023/1542) Applicability test. ## Primary sources - [Regulation (EU) 2023/1542 - Official Journal](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Primary legal text for scope, categories, dates, economic operator duties, waste obligations, and battery passport rules. - [Regulation (EU) 2023/1542 - Consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R1542&ref=sorena.io) - Useful article and annex reference for implementation teams. - [European Commission - Batteries overview](https://environment.ec.europa.eu/topics/waste-and-recycling/batteries_en?ref=sorena.io) - Commission implementation page for Batteries Regulation updates and related acts. - [Commission Notice C/2025/214 - removability and replaceability guidelines](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:C_202500214&ref=sorena.io) - Official guidance on how Article 11 removability and replaceability should be interpreted. ## Related Topic Guides - [Battery Carbon Footprint Declarations | Article 7 Implementation Guide](/artifacts/eu/batteries-regulation/carbon-footprint-declarations.md): Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations. - [Battery Due Diligence Program | Articles 48 to 52 Implementation Guide](/artifacts/eu/batteries-regulation/due-diligence-program.md): Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability. - [Battery Due Diligence Supplier Questionnaire | EU Batteries Regulation](/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire.md): Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542. - [Battery Labeling and Consumer Information | Article 13 and Article 74 Guide](/artifacts/eu/batteries-regulation/labeling-and-consumer-information.md): Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol. - [Battery Passport Data Model Template | Annex XIII Ready Structure](/artifacts/eu/batteries-regulation/battery-passport-data-model-template.md): Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data. - [Battery Passport Implementation | Article 77 and Article 78 Guide](/artifacts/eu/batteries-regulation/battery-passport-implementation.md): Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model. - [Battery Recycled Content and Recovery Targets | Article 8 and Annex XII Guide](/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets.md): Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII. - [EU Batteries Regulation Battery Categories and Scope | Portable, LMT, SLI, Industrial, EV](/artifacts/eu/batteries-regulation/battery-categories-and-scope.md): Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Checklist | Practical Compliance Checklist by Battery Category](/artifacts/eu/batteries-regulation/checklist.md): Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations. - [EU Batteries Regulation Compliance Program | Build an Operational Batteries Program](/artifacts/eu/batteries-regulation/compliance.md): Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations. - [EU Batteries Regulation Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar.md): Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024. - [EU Batteries Regulation FAQ | Dates, Categories, Passport, Due Diligence, and Waste Duties](/artifacts/eu/batteries-regulation/faq.md): Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts. - [EU Batteries Regulation Penalties and Enforcement | Article 93 Guide](/artifacts/eu/batteries-regulation/penalties-and-fines.md): Understand the penalty and enforcement structure in Regulation (EU) 2023/1542. - [EU Batteries Regulation Requirements | Article by Article Requirement Map](/artifacts/eu/batteries-regulation/requirements.md): Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability. - [EU Batteries Regulation vs ESPR | Battery Passport vs Digital Product Passport](/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr.md): Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/batteries-regulation/applicability-test --- --- title: "EU Batteries Regulation vs ESPR" canonical_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr" source_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr" author: "Sorena AI" description: "Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Batteries Regulation vs ESPR" - "battery passport vs digital product passport" - "Article 77 battery passport" - "Article 78 interoperability" - "ESPR DPP comparison" - "battery passport access rights" - "EU Batteries Regulation" - "ESPR" - "Battery passport" - "Digital Product Passport" - "Interoperability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Batteries Regulation vs ESPR Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model. *EU Batteries Regulation* *Comparison* ## EU Batteries Regulation (Regulation (EU) 2023/1542) Batteries Regulation and ESPR The battery passport is a sector specific product passport. ESPR is the wider cross sector framework. The right architecture treats the battery passport as the first product passport on a reusable platform, not as a throwaway standalone build. Many teams assume the battery passport is a special case that can be hard coded. Article 78 points in the opposite direction. The passport must be interoperable with other digital product passports required by Union law, must use open standards, and must avoid vendor lock in. That makes the battery passport an early implementation of a broader product data architecture. ## What overlaps between the two regimes Both the Batteries Regulation and ESPR are built around persistent product data, access control, traceable updates, and machine readable exchange. For the battery passport, Article 78 already requires open standards, structured and searchable data, and an open interoperable data exchange network without vendor lock in. That means the core technical services can and should be shared: identifier resolution, schema management, access rights, logging, and long term persistence. - Persistent identifiers and resolution services. - Structured, searchable, machine readable data. - Role based access and audit logs. - Interoperability across technical, semantic, and organizational layers. - Continuity even if the original operator stops operating in the Union. ## What is battery specific The battery passport is more than a generic product passport. Annex XIII defines battery model fields, restricted fields for persons with a legitimate interest, authority only test report fields, and individual battery fields such as state of health, status, cycles, accidents, and operating conditions. The battery passport also has battery specific lifecycle rules. A repurposed or remanufactured battery needs a new passport linked to the original passport, and the passport ceases to exist after recycling. - Battery specific public data on chemistry, recycled content, and responsible sourcing. - Restricted dismantling, spare part, and safety information. - Individual battery data such as state of health, charge cycles, and change of status. - Battery specific lifecycle linkages for re use, repurposing, remanufacturing, and recycling. ## Architecture recommendation Build one passport platform with a reusable core and product specific schema modules. The core should handle identifier issuance, QR resolution, authentication and authorization, schema versioning, audit logging, and availability. The battery module should implement Annex XIII fields, Article 77 access tiers, and lifecycle update logic. This avoids the common failure mode where a battery team builds a narrow portal that later cannot satisfy ESPR interoperability expectations or support another product passport category. - Reusable core for identity, resolver, access rights, logging, and schema versioning. - Battery module for Annex XIII data and Article 77 role logic. - Connector layer for declarations, conformity records, and waste information. - Lifecycle event layer for repurposing, remanufacturing, and recycling closure. ## Governance and rollout sequence The practical rollout is battery first but architecture aware. Start with the battery categories that will need passports from 18 February 2027. Use those early models to harden the resolver, access model, data validation, and supplier onboarding process, then generalize those services for future DPP obligations. This creates a stronger investment case and avoids rebuilding the same infrastructure twice. - Pilot with one in scope passport category and one manufacturing plant. - Separate product specific data from platform services from day one. - Test legitimate interest access and authority only access before broader rollout. - Document migration rules for repurposed and remanufactured batteries. *Recommended next step* *Placement: after the comparison section* ## Use EU Batteries Regulation (Regulation (EU) 2023/1542) Batteries Regulation and ESPR as a cited research workflow Research Copilot can take EU Batteries Regulation (Regulation (EU) 2023/1542) Batteries Regulation and ESPR from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Batteries Regulation (Regulation (EU) 2023/1542) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Batteries Regulation (Regulation (EU) 2023/1542) Batteries Regulation and ESPR](/solutions/research-copilot.md): Start from EU Batteries Regulation (Regulation (EU) 2023/1542) Batteries Regulation and ESPR and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Batteries Regulation (Regulation (EU) 2023/1542)](/contact.md): Review your current process, evidence gaps, and next steps for EU Batteries Regulation (Regulation (EU) 2023/1542) Batteries Regulation and ESPR. ## Primary sources - [Regulation (EU) 2023/1542 - Official Journal](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Primary legal text for scope, categories, dates, economic operator duties, waste obligations, and battery passport rules. - [Regulation (EU) 2024/1781 - Ecodesign for Sustainable Products Regulation](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Official legal source for the broader Digital Product Passport framework. - [European Commission - Ecodesign for Sustainable Products Regulation overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Commission overview of ESPR and Digital Product Passport implementation. - [Commission Standardisation Request M/579](https://ec.europa.eu/growth/tools-databases/enorm/mandate/579_en?ref=sorena.io) - Standardisation request supporting implementation of Regulation (EU) 2023/1542. ## Related Topic Guides - [Battery Carbon Footprint Declarations | Article 7 Implementation Guide](/artifacts/eu/batteries-regulation/carbon-footprint-declarations.md): Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations. - [Battery Due Diligence Program | Articles 48 to 52 Implementation Guide](/artifacts/eu/batteries-regulation/due-diligence-program.md): Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability. - [Battery Due Diligence Supplier Questionnaire | EU Batteries Regulation](/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire.md): Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542. - [Battery Labeling and Consumer Information | Article 13 and Article 74 Guide](/artifacts/eu/batteries-regulation/labeling-and-consumer-information.md): Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol. - [Battery Passport Data Model Template | Annex XIII Ready Structure](/artifacts/eu/batteries-regulation/battery-passport-data-model-template.md): Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data. - [Battery Passport Implementation | Article 77 and Article 78 Guide](/artifacts/eu/batteries-regulation/battery-passport-implementation.md): Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model. - [Battery Recycled Content and Recovery Targets | Article 8 and Annex XII Guide](/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets.md): Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII. - [EU Batteries Regulation Applicability Test | Category, Scope, and Obligation Routing](/artifacts/eu/batteries-regulation/applicability-test.md): Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Battery Categories and Scope | Portable, LMT, SLI, Industrial, EV](/artifacts/eu/batteries-regulation/battery-categories-and-scope.md): Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Checklist | Practical Compliance Checklist by Battery Category](/artifacts/eu/batteries-regulation/checklist.md): Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations. - [EU Batteries Regulation Compliance Program | Build an Operational Batteries Program](/artifacts/eu/batteries-regulation/compliance.md): Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations. - [EU Batteries Regulation Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar.md): Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024. - [EU Batteries Regulation FAQ | Dates, Categories, Passport, Due Diligence, and Waste Duties](/artifacts/eu/batteries-regulation/faq.md): Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts. - [EU Batteries Regulation Penalties and Enforcement | Article 93 Guide](/artifacts/eu/batteries-regulation/penalties-and-fines.md): Understand the penalty and enforcement structure in Regulation (EU) 2023/1542. - [EU Batteries Regulation Requirements | Article by Article Requirement Map](/artifacts/eu/batteries-regulation/requirements.md): Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr --- --- title: "EU Batteries Regulation Battery Categories and Scope" canonical_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/battery-categories-and-scope" source_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/battery-categories-and-scope" author: "Sorena AI" description: "Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Batteries Regulation battery categories" - "portable battery definition" - "LMT battery definition" - "SLI battery definition" - "industrial battery definition" - "EV battery definition" - "battery scope Regulation (EU) 2023/1542" - "EU Batteries Regulation" - "Battery categories" - "Scope" - "Portable" - "Industrial" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Batteries Regulation Battery Categories and Scope Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV. *EU Batteries Regulation* *Scope* ## EU Batteries Regulation (Regulation (EU) 2023/1542) Battery categories and scope Category classification is the routing decision for the whole program. Use the legal definitions, not internal product labels, to determine which requirements and dates apply. The category rules are not a marketing taxonomy. They are the legal gateway to passport timing, carbon footprint obligations, removability rules, state of health data, collection duties, and later recycled content requirements. Teams should therefore document the classification decision per model and keep it reviewable. ## The five main categories in the Regulation Article 3 sets out the working definitions. Portable batteries are sealed, 5 kg or less, and not specifically designed for industrial use or for EV, LMT, or SLI use. LMT batteries are sealed, 25 kg or less, and specifically designed for traction in light means of transport. SLI batteries are specifically designed for starting, lighting, or ignition. Industrial batteries include batteries specifically designed for industrial uses, repurposed batteries intended for industrial uses, and any other battery over 5 kg that does not fall into another category. EV batteries are traction batteries for eligible road vehicle categories, including category L batteries above 25 kg. These weight thresholds and intended use tests are the place where many classification errors occur. - Portable: sealed, 5 kg or less, not industrial, not EV, not LMT, not SLI. - LMT: sealed, 25 kg or less, traction for light means of transport. - SLI: specifically designed for starting, lighting, or ignition, including auxiliary or backup uses in vehicles or machinery. - Industrial: industrial use, repurposed industrial use, or over 5 kg where no other category fits. - EV: traction battery for category L above 25 kg or category M, N, or O vehicles. ## Borderline cases that need documentation Borderline cases are usually driven by intended use, weight, or lifecycle change. Domestic storage batteries are still industrial batteries. Repurposed batteries intended for industrial uses also fall into the industrial category even if they were originally designed for something else. A multi use battery sold across different channels may need separate route analysis if the intended use changes the category outcome. Where the same battery is incorporated into another product, also document which economic operator controls the battery specific compliance artifacts. - Document why a battery over 5 kg is not being routed into industrial if another category is claimed. - Document whether category L traction means EV or LMT based on the 25 kg threshold. - Document repurposed and remanufactured batteries as new compliance objects where relevant. - Document the operator responsible for labels, QR, passport, and waste reporting when the battery is incorporated into a product. ## What category changes in practice Category drives the date map and the artifact set. LMT, EV, and industrial batteries above 2 kWh move into battery passport obligations on 18 February 2027. Stationary battery energy storage systems, LMT batteries, and EV batteries must expose state of health and expected lifetime data from 18 August 2024. Portable batteries trigger the Article 11 removability and replaceability rules from 18 February 2027. Waste collection targets also differ between portable and LMT categories. The category therefore determines who needs to be involved. Some batteries need deep product engineering work. Others are dominated by waste and producer responsibility obligations. - Portable route: Article 11, Article 13, Article 59, and consumer information duties. - LMT route: Article 11, Article 14, Article 60, Article 77, and later carbon footprint duties. - EV and industrial route: Article 7, Article 8, Article 14 for the relevant systems, Article 77, and Annex VIII technical documentation. - SLI route: labeling, due diligence, recycled content, and waste obligations without the battery passport route unless another category rule applies. ## Minimum evidence for category classification Keep the evidence short and verifiable. The record should show the model, weight, intended use, applicable article references, the final category, and the review trigger. That is enough to make later controls much easier to manage. If the category decision changes after repurposing or redesign, retain both the old and new records and link them. - Model sheet with weight, chemistry, capacity, and intended use. - Category decision memo with article references and rationale. - Named owner and review date. - Trigger list for redesign, repurposing, or new distribution channels. *Recommended next step* *Placement: after the scope or definition section* ## Use EU Batteries Regulation (Regulation (EU) 2023/1542) Battery categories and scope as a cited research workflow Research Copilot can take EU Batteries Regulation (Regulation (EU) 2023/1542) Battery categories and scope from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Batteries Regulation (Regulation (EU) 2023/1542) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Batteries Regulation (Regulation (EU) 2023/1542) Battery categories and scope](/solutions/research-copilot.md): Start from EU Batteries Regulation (Regulation (EU) 2023/1542) Battery categories and scope and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Batteries Regulation (Regulation (EU) 2023/1542)](/contact.md): Review your current process, evidence gaps, and next steps for EU Batteries Regulation (Regulation (EU) 2023/1542) Battery categories and scope. ## Primary sources - [Regulation (EU) 2023/1542 - Official Journal](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Primary legal text for scope, categories, dates, economic operator duties, waste obligations, and battery passport rules. - [Regulation (EU) 2023/1542 - Consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R1542&ref=sorena.io) - Useful article and annex reference for implementation teams. - [Commission Notice C/2025/214 - removability and replaceability guidelines](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:C_202500214&ref=sorena.io) - Official guidance on how Article 11 removability and replaceability should be interpreted. ## Related Topic Guides - [Battery Carbon Footprint Declarations | Article 7 Implementation Guide](/artifacts/eu/batteries-regulation/carbon-footprint-declarations.md): Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations. - [Battery Due Diligence Program | Articles 48 to 52 Implementation Guide](/artifacts/eu/batteries-regulation/due-diligence-program.md): Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability. - [Battery Due Diligence Supplier Questionnaire | EU Batteries Regulation](/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire.md): Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542. - [Battery Labeling and Consumer Information | Article 13 and Article 74 Guide](/artifacts/eu/batteries-regulation/labeling-and-consumer-information.md): Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol. - [Battery Passport Data Model Template | Annex XIII Ready Structure](/artifacts/eu/batteries-regulation/battery-passport-data-model-template.md): Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data. - [Battery Passport Implementation | Article 77 and Article 78 Guide](/artifacts/eu/batteries-regulation/battery-passport-implementation.md): Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model. - [Battery Recycled Content and Recovery Targets | Article 8 and Annex XII Guide](/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets.md): Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII. - [EU Batteries Regulation Applicability Test | Category, Scope, and Obligation Routing](/artifacts/eu/batteries-regulation/applicability-test.md): Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Checklist | Practical Compliance Checklist by Battery Category](/artifacts/eu/batteries-regulation/checklist.md): Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations. - [EU Batteries Regulation Compliance Program | Build an Operational Batteries Program](/artifacts/eu/batteries-regulation/compliance.md): Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations. - [EU Batteries Regulation Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar.md): Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024. - [EU Batteries Regulation FAQ | Dates, Categories, Passport, Due Diligence, and Waste Duties](/artifacts/eu/batteries-regulation/faq.md): Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts. - [EU Batteries Regulation Penalties and Enforcement | Article 93 Guide](/artifacts/eu/batteries-regulation/penalties-and-fines.md): Understand the penalty and enforcement structure in Regulation (EU) 2023/1542. - [EU Batteries Regulation Requirements | Article by Article Requirement Map](/artifacts/eu/batteries-regulation/requirements.md): Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability. - [EU Batteries Regulation vs ESPR | Battery Passport vs Digital Product Passport](/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr.md): Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/batteries-regulation/battery-categories-and-scope --- --- title: "Battery Due Diligence Supplier Questionnaire" canonical_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire" source_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire" author: "Sorena AI" description: "Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "battery due diligence supplier questionnaire" - "EU Batteries Regulation supplier questionnaire" - "Article 48 Article 49 Article 50 Article 51 Article 52 supplier evidence" - "battery raw material traceability questionnaire" - "EU Batteries Regulation" - "Due diligence" - "Supplier questionnaire" - "Traceability" - "Notified body" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Battery Due Diligence Supplier Questionnaire Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542. *EU Batteries Regulation* *Supplier controls* ## EU Batteries Regulation (Regulation (EU) 2023/1542) Supplier due diligence questionnaire A supplier questionnaire is only useful if it collects the evidence your notified body and downstream customers will actually need. This version is organized around Articles 49 to 52, not around generic ESG prompts. Articles 48 to 52 make supplier evidence the critical path for battery due diligence. A weak questionnaire creates false comfort because it collects policy language but not the traceability, risk, audit, and remediation material that the economic operator must maintain for 10 years after the last battery under the policy is placed on the market. ## Section 1: supplier identity and covered materials Start by fixing the scope. Ask the supplier which raw materials listed in Annex X are relevant to the batteries or active materials supplied, which facilities are involved, and which exact products or model families are covered by the response. If the supplier cannot identify the covered facilities or materials, the later answers will not be reliable enough for Article 49 traceability. - Legal entity name, site list, and contact owner for due diligence. - Covered battery models, cell components, or raw materials. - Country of origin and processing route for each covered raw material. - Immediate supplier chain and upstream actor identification where available. ## Section 2: management system and policy controls Ask for the documented due diligence policy, the standards used to shape it, the top management owner, the grievance mechanism, and the contract clauses used with upstream suppliers. Article 49 is explicit that the management system must be tied to top management oversight, contract controls, traceability, and grievance handling. This is also where you test whether the supplier policy is battery specific or merely a generic supplier code. - Battery due diligence policy and date of last review. - Top management owner and governance route for escalations. - Supplier contract clauses covering traceability, mitigation, and cooperation. - Grievance, early warning, and remediation mechanism description. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Batteries Regulation (Regulation (EU) 2023/1542) Supplier due diligence questionnaire in one governed evidence system SSOT can take EU Batteries Regulation (Regulation (EU) 2023/1542) Supplier due diligence questionnaire from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Batteries Regulation (Regulation (EU) 2023/1542) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Batteries Regulation (Regulation (EU) 2023/1542) Supplier due diligence questionnaire](/solutions/ssot.md): Start from EU Batteries Regulation (Regulation (EU) 2023/1542) Supplier due diligence questionnaire and keep documents, evidence, and control records in one governed system. - [Talk through EU Batteries Regulation (Regulation (EU) 2023/1542)](/contact.md): Review your current process, evidence gaps, and next steps for EU Batteries Regulation (Regulation (EU) 2023/1542) Supplier due diligence questionnaire. ## Section 3: traceability and chain of custody evidence Article 49 requires a chain of custody or traceability system identifying upstream actors in the supply chain. Ask for actual evidence fields, not only process descriptions. The minimum useful response covers the material type, supplier identity, country of origin, transaction chain, quantities, and any third party verification reports already available. Where material comes from conflict affected or high risk areas and third party reports are not available, ask for the additional OECD style information the Regulation points to. - Material name, trade name, and type. - Supplier name and address for the supplied material. - Country of origin and transaction path from extraction to immediate supplier. - Quantities present in the supplied battery or component. - Existing third party verification reports or equivalent evidence. ## Section 4: risk assessment, mitigation, and verification Article 50 requires risk identification, risk assessment, measurable mitigation, monitoring, and reporting back to top management. Ask for the current risk register, active mitigation plan, supplier escalation criteria, and how failed mitigation triggers suspension or disengagement. Also ask for any notified body verification or supplier level verification reports the operator may rely on. The goal is to see whether the supplier can support the operator own risk management plan, not merely state that it complies with OECD guidance. - Current risk register for Annex X social and environmental risk categories. - Measurable mitigation plan with owners and dates. - Evidence of stakeholder consultation where mitigation is ongoing. - Notified body or other verification reports and latest audit outcomes. - Corrective actions open, overdue, and closed in the last reporting cycle. ## Section 5: downstream disclosure support Article 52 requires annual public reporting and downstream information sharing. Suppliers should therefore be asked which data can be passed to immediate downstream purchasers, which information is confidential, and how changes will be communicated. A supplier that cannot support downstream disclosure will create recurring remediation work. This section also helps align the questionnaire with the operator public report and customer diligence requests. - Information available for downstream purchasers. - Confidentiality limits and approved disclosure boundaries. - Update cadence for material changes or significant adverse impacts. - Named contact for urgent authority or customer follow up questions. ## Primary sources - [Regulation (EU) 2023/1542 - Official Journal](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Primary legal text for scope, categories, dates, economic operator duties, waste obligations, and battery passport rules. - [SMCS or NANDO notified bodies search](https://webgate.ec.europa.eu/single-market-compliance-space/notified-bodies/free-search?ref=sorena.io) - Official search entry for notified bodies relevant to Regulation (EU) 2023/1542. - [European Commission - Batteries overview](https://environment.ec.europa.eu/topics/waste-and-recycling/batteries_en?ref=sorena.io) - Commission implementation page for Batteries Regulation updates and related acts. ## Related Topic Guides - [Battery Carbon Footprint Declarations | Article 7 Implementation Guide](/artifacts/eu/batteries-regulation/carbon-footprint-declarations.md): Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations. - [Battery Due Diligence Program | Articles 48 to 52 Implementation Guide](/artifacts/eu/batteries-regulation/due-diligence-program.md): Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability. - [Battery Labeling and Consumer Information | Article 13 and Article 74 Guide](/artifacts/eu/batteries-regulation/labeling-and-consumer-information.md): Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol. - [Battery Passport Data Model Template | Annex XIII Ready Structure](/artifacts/eu/batteries-regulation/battery-passport-data-model-template.md): Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data. - [Battery Passport Implementation | Article 77 and Article 78 Guide](/artifacts/eu/batteries-regulation/battery-passport-implementation.md): Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model. - [Battery Recycled Content and Recovery Targets | Article 8 and Annex XII Guide](/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets.md): Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII. - [EU Batteries Regulation Applicability Test | Category, Scope, and Obligation Routing](/artifacts/eu/batteries-regulation/applicability-test.md): Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Battery Categories and Scope | Portable, LMT, SLI, Industrial, EV](/artifacts/eu/batteries-regulation/battery-categories-and-scope.md): Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Checklist | Practical Compliance Checklist by Battery Category](/artifacts/eu/batteries-regulation/checklist.md): Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations. - [EU Batteries Regulation Compliance Program | Build an Operational Batteries Program](/artifacts/eu/batteries-regulation/compliance.md): Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations. - [EU Batteries Regulation Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar.md): Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024. - [EU Batteries Regulation FAQ | Dates, Categories, Passport, Due Diligence, and Waste Duties](/artifacts/eu/batteries-regulation/faq.md): Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts. - [EU Batteries Regulation Penalties and Enforcement | Article 93 Guide](/artifacts/eu/batteries-regulation/penalties-and-fines.md): Understand the penalty and enforcement structure in Regulation (EU) 2023/1542. - [EU Batteries Regulation Requirements | Article by Article Requirement Map](/artifacts/eu/batteries-regulation/requirements.md): Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability. - [EU Batteries Regulation vs ESPR | Battery Passport vs Digital Product Passport](/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr.md): Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire --- --- title: "Battery Passport Data Model Template" canonical_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/battery-passport-data-model-template" source_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/battery-passport-data-model-template" author: "Sorena AI" description: "Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "battery passport data model template" - "Annex XIII battery passport schema" - "Article 77 data model" - "Article 78 battery passport design" - "legitimate interest battery passport data" - "individual battery passport data" - "EU Batteries Regulation" - "Battery passport" - "Annex XIII" - "Data model" - "Article 77" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Battery Passport Data Model Template Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data. *EU Batteries Regulation* *Template* ## EU Batteries Regulation (Regulation (EU) 2023/1542) Battery passport data model template Annex XIII is not one flat table. It is a tiered access model with model level and instance level data. Use the template below to build a schema that matches the Regulation and survives future lifecycle events. The battery passport data model should be organized around access and lifecycle, not only around a list of fields. Article 77 and Annex XIII split the information into public data, legitimate interest data, authority only data, and individual battery data. If the schema ignores that structure, access control and update workflows become fragile. ## Public model level fields The public layer should cover the Part A Annex VI information, chemistry and hazardous substances other than mercury, cadmium, or lead, critical raw materials, carbon footprint information, responsible sourcing information from the due diligence report, recycled content information, renewable content share, and key performance values such as rated capacity, voltage, power capability, expected lifetime, and warranty period. This layer is the part most likely to be reused across customer portals, QR landing pages, and later product passport ecosystems. - Model identifier and public label fields. - Chemistry, critical raw materials, and relevant hazardous substance information. - Carbon footprint and recycled content references. - Performance and lifetime values required by Annex XIII point 1. - Waste prevention and waste management information references. ## Legitimate interest model level fields Annex XIII point 2 covers the model data that should not be fully public. This includes detailed composition, replacement spare part contact details, dismantling information such as exploded diagrams and disassembly sequences, and safety measures. Model this as a restricted dataset with granular field permissions instead of a single binary locked document. - Detailed cathode, anode, and electrolyte composition. - Spare part identifiers and replacement source contacts. - Disassembly sequence, fastening types, tool requirements, and warnings. - Safety handling notes for repair, remanufacturing, and recycling actors. ## Authority and notified body layer Annex XIII point 3 reserves test report results proving compliance to notified bodies, market surveillance authorities, and the Commission. This should be kept as a controlled evidence layer linked to the battery model and relevant conformity or verification event. Do not flatten this into the public passport dataset. Keep it referenceable but separately permissioned. - Test report references and files. - Conformity evidence links and validity dates. - Authority facing metadata on the compliance event. - Access logs for restricted evidence retrieval. ## Individual battery layer Annex XIII point 4 covers the individual battery record. This includes performance and durability parameters when the battery is placed on the market and when its status changes, Article 14 state of health information, status values such as original or repurposed, and use generated data such as cycles, accidents, environmental conditions, and state of charge. This is the layer that often forces teams to decide whether the passport is static or operational. The Regulation clearly expects it to be operational for in scope batteries. - Instance identifier linked to the model and QR unique identifier. - State of health and expected lifetime data references. - Status field: original, re used, repurposed, remanufactured, or waste. - Operational history fields for cycles, accidents, and periodic operating conditions. ## Lifecycle and governance rules For repurposed or remanufactured batteries, Article 77 requires a new battery passport linked to the original passport or passports. The data model must therefore support lineage. It must also support closure, because the passport ceases to exist after the battery is recycled. Governance should cover field ownership, validation, update rights, and retention of historical changes. - Lineage link for repurposed and remanufactured batteries. - Closure state for recycled batteries. - Field ownership and validation rules per access tier. - Version history and audit log for every material update. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Batteries Regulation (Regulation (EU) 2023/1542) Battery passport data model template in one governed evidence system SSOT can take EU Batteries Regulation (Regulation (EU) 2023/1542) Battery passport data model template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Batteries Regulation (Regulation (EU) 2023/1542) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Batteries Regulation (Regulation (EU) 2023/1542) Battery passport data model template](/solutions/ssot.md): Start from EU Batteries Regulation (Regulation (EU) 2023/1542) Battery passport data model template and keep documents, evidence, and control records in one governed system. - [Talk through EU Batteries Regulation (Regulation (EU) 2023/1542)](/contact.md): Review your current process, evidence gaps, and next steps for EU Batteries Regulation (Regulation (EU) 2023/1542) Battery passport data model template. ## Primary sources - [Regulation (EU) 2023/1542 - Official Journal](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Primary legal text for scope, categories, dates, economic operator duties, waste obligations, and battery passport rules. - [Regulation (EU) 2023/1542 - Consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R1542&ref=sorena.io) - Useful article and annex reference for implementation teams. - [Commission Standardisation Request M/579](https://ec.europa.eu/growth/tools-databases/enorm/mandate/579_en?ref=sorena.io) - Standardisation request supporting implementation of Regulation (EU) 2023/1542. ## Related Topic Guides - [Battery Carbon Footprint Declarations | Article 7 Implementation Guide](/artifacts/eu/batteries-regulation/carbon-footprint-declarations.md): Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations. - [Battery Due Diligence Program | Articles 48 to 52 Implementation Guide](/artifacts/eu/batteries-regulation/due-diligence-program.md): Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability. - [Battery Due Diligence Supplier Questionnaire | EU Batteries Regulation](/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire.md): Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542. - [Battery Labeling and Consumer Information | Article 13 and Article 74 Guide](/artifacts/eu/batteries-regulation/labeling-and-consumer-information.md): Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol. - [Battery Passport Implementation | Article 77 and Article 78 Guide](/artifacts/eu/batteries-regulation/battery-passport-implementation.md): Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model. - [Battery Recycled Content and Recovery Targets | Article 8 and Annex XII Guide](/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets.md): Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII. - [EU Batteries Regulation Applicability Test | Category, Scope, and Obligation Routing](/artifacts/eu/batteries-regulation/applicability-test.md): Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Battery Categories and Scope | Portable, LMT, SLI, Industrial, EV](/artifacts/eu/batteries-regulation/battery-categories-and-scope.md): Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Checklist | Practical Compliance Checklist by Battery Category](/artifacts/eu/batteries-regulation/checklist.md): Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations. - [EU Batteries Regulation Compliance Program | Build an Operational Batteries Program](/artifacts/eu/batteries-regulation/compliance.md): Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations. - [EU Batteries Regulation Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar.md): Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024. - [EU Batteries Regulation FAQ | Dates, Categories, Passport, Due Diligence, and Waste Duties](/artifacts/eu/batteries-regulation/faq.md): Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts. - [EU Batteries Regulation Penalties and Enforcement | Article 93 Guide](/artifacts/eu/batteries-regulation/penalties-and-fines.md): Understand the penalty and enforcement structure in Regulation (EU) 2023/1542. - [EU Batteries Regulation Requirements | Article by Article Requirement Map](/artifacts/eu/batteries-regulation/requirements.md): Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability. - [EU Batteries Regulation vs ESPR | Battery Passport vs Digital Product Passport](/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr.md): Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/batteries-regulation/battery-passport-data-model-template --- --- title: "Battery Passport Implementation" canonical_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/battery-passport-implementation" source_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/battery-passport-implementation" author: "Sorena AI" description: "Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "battery passport implementation" - "Article 77 battery passport" - "Article 78 battery passport" - "QR battery passport" - "legitimate interest access battery passport" - "repurposed battery new passport" - "EU Batteries Regulation" - "Battery passport" - "Article 77" - "Article 78" - "QR code" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Battery Passport Implementation Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model. *EU Batteries Regulation* *Implementation* ## EU Batteries Regulation (Regulation (EU) 2023/1542) Battery passport implementation The battery passport is an operating system for product data, not a static document. Build it around the legal access tiers, QR resolution, lifecycle updates, and interoperability requirements that apply from day one. Article 77 makes the battery passport mandatory from 18 February 2027 for each LMT battery, each industrial battery over 2 kWh, and each electric vehicle battery placed on the market or put into service. The implementation challenge is not only publishing data. It is building a durable resolver, permissions model, and lifecycle update process that remain valid when the battery changes status or the original operator disappears. ## Scope and timeline for implementation The passport obligation begins on 18 February 2027 for the in scope categories. The same date also matters for QR code access under Article 13(6). Before then, teams should already have model and instance identifiers, data ownership, and plant specific declaration integrations prepared. Do not wait for the final quarter before go live. The passport depends on labeling, data model, supplier inputs, and system design choices that take time to stabilize. - In scope categories: LMT, EV, and industrial batteries above 2 kWh. - Go live date: 18 February 2027. - Related dependency: QR marking from Article 13(6). - Related dependency: carbon footprint, recycled content, and due diligence data feeds where applicable. ## Identifier and QR architecture Article 77 requires the battery passport to be accessible through the QR code referred to in Article 13(6), linked to a unique identifier attributed by the economic operator placing the battery on the market. The Regulation points to ISO or IEC identifier standards for the QR code and unique identifier route. Design the resolver as an infrastructure service. The QR should resolve predictably, survive supplier changes, and keep working even if the business model or storage provider changes. - Unique identifier issuance per battery instance. - Stable QR resolution service with version aware redirects if needed. - Fallback and continuity plan if the responsible operator ceases activity in the Union. - Monitoring for link failures, stale data, and unauthorized changes. ## Access rights and restricted data handling The passport is not fully public. Public users, persons with a legitimate interest, notified bodies, market surveillance authorities, and the Commission do not see the same information. The architecture therefore needs granular access control, clear lawful purpose handling, and audit logging on restricted fields. The Commission will further specify legitimate interest access in an implementing act, so the access model should be flexible enough to absorb later detail without redesign. - Public access for the Annex XIII public layer. - Restricted model and instance access for persons with a legitimate interest. - Authority only access for test reports and equivalent restricted evidence. - Audit trail for every privileged access, update, and download event. ## Lifecycle events and lineage Article 77 transfers responsibility to the economic operator that places on the market or puts into service a battery after preparation for re use, preparation for repurposing, repurposing, or remanufacturing. That battery must have a new passport linked to the original passport or passports. The passport ceases to exist after recycling. That means your implementation needs a status model, lineage graph, and closure logic. Without these, second life operations will be error prone. - Status transitions for original, re used, repurposed, remanufactured, and waste. - Linked passport history for batteries that change status. - Owner reassignment workflow for the new responsible economic operator. - Closure and archive logic when the battery is recycled. ## Article 78 technical design requirements Article 78 adds the architectural standards. The passport must be fully interoperable with other Union digital product passports, free of charge to the relevant users within their access rights, stored by the responsible operator or its authorized service provider, protected against unauthorized reuse of the data by service providers, and designed to ensure security, privacy, and fraud prevention. These are product requirements, not just legal niceties. They should appear in the system specification and the vendor contract. - Open standards and no vendor lock in. - Machine readable, structured, searchable data. - Role based access to introduce, modify, and update information. - Security, privacy, and fraud prevention controls built into the platform. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU Batteries Regulation (Regulation (EU) 2023/1542) Battery passport implementation across ESG workflows ESG Compliance can take EU Batteries Regulation (Regulation (EU) 2023/1542) Battery passport implementation from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU Batteries Regulation (Regulation (EU) 2023/1542) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Batteries Regulation (Regulation (EU) 2023/1542) Battery passport implementation](/solutions/esg-compliance.md): Start from EU Batteries Regulation (Regulation (EU) 2023/1542) Battery passport implementation and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Batteries Regulation (Regulation (EU) 2023/1542)](/contact.md): Review your current process, evidence gaps, and next steps for EU Batteries Regulation (Regulation (EU) 2023/1542) Battery passport implementation. ## Primary sources - [Regulation (EU) 2023/1542 - Official Journal](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Primary legal text for scope, categories, dates, economic operator duties, waste obligations, and battery passport rules. - [Regulation (EU) 2023/1542 - Consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R1542&ref=sorena.io) - Useful article and annex reference for implementation teams. - [Commission Standardisation Request M/579](https://ec.europa.eu/growth/tools-databases/enorm/mandate/579_en?ref=sorena.io) - Standardisation request supporting implementation of Regulation (EU) 2023/1542. - [European Commission - Batteries overview](https://environment.ec.europa.eu/topics/waste-and-recycling/batteries_en?ref=sorena.io) - Commission implementation page for Batteries Regulation updates and related acts. ## Related Topic Guides - [Battery Carbon Footprint Declarations | Article 7 Implementation Guide](/artifacts/eu/batteries-regulation/carbon-footprint-declarations.md): Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations. - [Battery Due Diligence Program | Articles 48 to 52 Implementation Guide](/artifacts/eu/batteries-regulation/due-diligence-program.md): Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability. - [Battery Due Diligence Supplier Questionnaire | EU Batteries Regulation](/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire.md): Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542. - [Battery Labeling and Consumer Information | Article 13 and Article 74 Guide](/artifacts/eu/batteries-regulation/labeling-and-consumer-information.md): Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol. - [Battery Passport Data Model Template | Annex XIII Ready Structure](/artifacts/eu/batteries-regulation/battery-passport-data-model-template.md): Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data. - [Battery Recycled Content and Recovery Targets | Article 8 and Annex XII Guide](/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets.md): Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII. - [EU Batteries Regulation Applicability Test | Category, Scope, and Obligation Routing](/artifacts/eu/batteries-regulation/applicability-test.md): Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Battery Categories and Scope | Portable, LMT, SLI, Industrial, EV](/artifacts/eu/batteries-regulation/battery-categories-and-scope.md): Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Checklist | Practical Compliance Checklist by Battery Category](/artifacts/eu/batteries-regulation/checklist.md): Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations. - [EU Batteries Regulation Compliance Program | Build an Operational Batteries Program](/artifacts/eu/batteries-regulation/compliance.md): Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations. - [EU Batteries Regulation Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar.md): Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024. - [EU Batteries Regulation FAQ | Dates, Categories, Passport, Due Diligence, and Waste Duties](/artifacts/eu/batteries-regulation/faq.md): Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts. - [EU Batteries Regulation Penalties and Enforcement | Article 93 Guide](/artifacts/eu/batteries-regulation/penalties-and-fines.md): Understand the penalty and enforcement structure in Regulation (EU) 2023/1542. - [EU Batteries Regulation Requirements | Article by Article Requirement Map](/artifacts/eu/batteries-regulation/requirements.md): Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability. - [EU Batteries Regulation vs ESPR | Battery Passport vs Digital Product Passport](/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr.md): Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/batteries-regulation/battery-passport-implementation --- --- title: "Battery Carbon Footprint Declarations" canonical_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/carbon-footprint-declarations" source_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/carbon-footprint-declarations" author: "Sorena AI" description: "Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "battery carbon footprint declarations" - "Article 7 Batteries Regulation" - "carbon footprint declaration EV battery" - "LMT battery carbon footprint declaration" - "industrial battery carbon footprint declaration" - "carbon footprint performance class batteries" - "EU Batteries Regulation" - "Carbon footprint" - "Article 7" - "Annex II" - "Technical documentation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Battery Carbon Footprint Declarations Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations. *EU Batteries Regulation* *Article 7* ## EU Batteries Regulation (Regulation (EU) 2023/1542) Carbon footprint declarations Article 7 is a staged program with plant specific declarations, performance classes, and later thresholds. Treat the declaration as a controlled data product tied to the battery model, the manufacturing plant, and Annex VIII evidence. Carbon footprint compliance is often reduced to a life cycle assessment report. Article 7 is stricter than that. It requires a declaration for each battery model per manufacturing plant, a public supporting study link, later performance class labels, and later maximum threshold compliance, all on dates that differ by category. ## What the declaration must contain Article 7 requires administrative information about the manufacturer, battery model information, plant location, the life cycle carbon footprint per kWh over expected service life, the breakdown by life cycle stage, the EU declaration of conformity identification number, and a web link to a public version of the supporting study. The declaration is plant specific. The Regulation does not allow sampling across plants producing the same battery model. That design point should shape your data model from the start. - Manufacturer and battery model details. - Manufacturing plant location. - Total carbon footprint per kWh over expected service life. - Life cycle stage breakdown. - EU declaration of conformity identifier. - Public link to the supporting study. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Batteries Regulation (Regulation (EU) 2023/1542) Carbon footprint declarations in one governed evidence system SSOT can take EU Batteries Regulation (Regulation (EU) 2023/1542) Carbon footprint declarations from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Batteries Regulation (Regulation (EU) 2023/1542) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Batteries Regulation (Regulation (EU) 2023/1542) Carbon footprint declarations](/solutions/ssot.md): Start from EU Batteries Regulation (Regulation (EU) 2023/1542) Carbon footprint declarations and keep documents, evidence, and control records in one governed system. - [Talk through EU Batteries Regulation (Regulation (EU) 2023/1542)](/contact.md): Review your current process, evidence gaps, and next steps for EU Batteries Regulation (Regulation (EU) 2023/1542) Carbon footprint declarations. ## Exact application dates by category The dates are not uniform. For EV batteries the declaration applies from 18 February 2025 or 12 months after the delegated and implementing acts enter into force, whichever is later. For rechargeable industrial batteries above 2 kWh except those with exclusively external storage, it applies from 18 February 2026 or 18 months after those acts, whichever is later. For LMT batteries it applies from 18 August 2028 or 18 months after those acts, whichever is later. For rechargeable industrial batteries with external storage, it applies from 18 August 2030 or 18 months after those acts, whichever is later. Until the declaration becomes accessible through the QR code, it must accompany the battery. - EV declaration date: 18 February 2025 or later trigger. - Industrial above 2 kWh, except external storage: 18 February 2026 or later trigger. - LMT: 18 August 2028 or later trigger. - Industrial with external storage: 18 August 2030 or later trigger. ## Performance classes and threshold planning Article 7 does not stop with a declaration. It later requires a label showing the carbon footprint performance class and later requires technical documentation to show that the declared life cycle carbon footprint sits below the maximum threshold for the relevant category. Those dates also differ by category. Program teams should therefore plan three phases: declaration, performance class labeling, and threshold compliance. - Performance class label starts for EV from 18 August 2026 or later trigger. - Performance class label starts for industrial above 2 kWh except external storage from 18 August 2027 or later trigger. - Performance class label starts for LMT from 18 February 2030 or later trigger. - Maximum threshold starts for EV from 18 February 2028, for industrial above 2 kWh except external storage from 18 February 2029, for LMT from 18 August 2031, and for external storage from 18 August 2033, each subject to the delegated act timing rule. ## Governance and evidence model The carbon footprint workflow should be controlled like regulated product data. Keep the source bill of materials, energy data, plant data, calculation assumptions, supporting study, review approvals, and publication link under version control. Also link the result to the Annex VIII technical documentation because the Regulation explicitly uses that documentation to prove compliance with Article 7. This is especially important where the same battery model is made at multiple sites or where the plant energy mix changes materially. - Per plant, per model declaration register. - Versioned supporting study and sign off history. - Recalculation triggers for plant, process, material, or energy mix changes. - Link from the declaration to QR and passport flows where required. ## Primary sources - [Regulation (EU) 2023/1542 - Official Journal](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Primary legal text for scope, categories, dates, economic operator duties, waste obligations, and battery passport rules. - [Regulation (EU) 2023/1542 - Consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R1542&ref=sorena.io) - Useful article and annex reference for implementation teams. - [Commission draft on the carbon footprint declaration format](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=PI_COM:Ares(2024)3131449&ref=sorena.io) - Draft format referenced in the local grounding pack for the Article 7 declaration fields. - [European Commission - Batteries overview](https://environment.ec.europa.eu/topics/waste-and-recycling/batteries_en?ref=sorena.io) - Commission implementation page for Batteries Regulation updates and related acts. ## Related Topic Guides - [Battery Due Diligence Program | Articles 48 to 52 Implementation Guide](/artifacts/eu/batteries-regulation/due-diligence-program.md): Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability. - [Battery Due Diligence Supplier Questionnaire | EU Batteries Regulation](/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire.md): Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542. - [Battery Labeling and Consumer Information | Article 13 and Article 74 Guide](/artifacts/eu/batteries-regulation/labeling-and-consumer-information.md): Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol. - [Battery Passport Data Model Template | Annex XIII Ready Structure](/artifacts/eu/batteries-regulation/battery-passport-data-model-template.md): Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data. - [Battery Passport Implementation | Article 77 and Article 78 Guide](/artifacts/eu/batteries-regulation/battery-passport-implementation.md): Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model. - [Battery Recycled Content and Recovery Targets | Article 8 and Annex XII Guide](/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets.md): Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII. - [EU Batteries Regulation Applicability Test | Category, Scope, and Obligation Routing](/artifacts/eu/batteries-regulation/applicability-test.md): Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Battery Categories and Scope | Portable, LMT, SLI, Industrial, EV](/artifacts/eu/batteries-regulation/battery-categories-and-scope.md): Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Checklist | Practical Compliance Checklist by Battery Category](/artifacts/eu/batteries-regulation/checklist.md): Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations. - [EU Batteries Regulation Compliance Program | Build an Operational Batteries Program](/artifacts/eu/batteries-regulation/compliance.md): Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations. - [EU Batteries Regulation Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar.md): Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024. - [EU Batteries Regulation FAQ | Dates, Categories, Passport, Due Diligence, and Waste Duties](/artifacts/eu/batteries-regulation/faq.md): Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts. - [EU Batteries Regulation Penalties and Enforcement | Article 93 Guide](/artifacts/eu/batteries-regulation/penalties-and-fines.md): Understand the penalty and enforcement structure in Regulation (EU) 2023/1542. - [EU Batteries Regulation Requirements | Article by Article Requirement Map](/artifacts/eu/batteries-regulation/requirements.md): Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability. - [EU Batteries Regulation vs ESPR | Battery Passport vs Digital Product Passport](/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr.md): Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/batteries-regulation/carbon-footprint-declarations --- --- title: "EU Batteries Regulation Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/checklist" source_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/checklist" author: "Sorena AI" description: "Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Batteries Regulation checklist" - "batteries regulation compliance checklist" - "battery passport checklist" - "battery due diligence checklist" - "carbon footprint checklist" - "EPR battery checklist" - "EU Batteries Regulation" - "Checklist" - "Battery passport" - "Due diligence" - "Waste batteries" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Batteries Regulation Checklist Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations. *EU Batteries Regulation* *Checklist* ## EU Batteries Regulation (Regulation (EU) 2023/1542) Compliance checklist The useful checklist is the one that produces evidence, not slogans. This version is organized around the artifacts and controls most often requested by customers, authorities, and notified bodies. Use this checklist per battery model and, where relevant, per manufacturing plant. The Batteries Regulation combines product rules, lifecycle data, waste duties, and due diligence in one regime. The easiest way to implement it is to track one evidence list with category specific routes. ## Category and scope controls Everything starts with classification. Make sure the legal category and role are fixed before you build labels, passports, or due diligence claims. This is also where you capture whether the battery is incorporated into a product and who owns the battery specific compliance artifacts. - Battery model register complete with category, intended use, weight, capacity, and plant. - Role matrix complete for manufacturer, importer, producer, distributor, repurposer, and remanufacturer where relevant. - Date matrix for Article 7, Article 11, Article 13, Article 14, Article 48, Article 59, Article 60, and Article 77 as applicable. - Review triggers recorded for redesign, repurposing, new suppliers, and new markets. ## Product, label, and QR controls The label set is phased. The separate collection symbol applies from 18 August 2025. The broader labels under Article 13 paragraphs 1 to 3 apply from 18 August 2026 or 18 months after the implementing act, whichever is later. The QR code applies from 18 February 2027. Use one controlled label library tied to model data and QR destinations. - Separate collection symbol implemented and sized correctly where required. - Capacity, non rechargeable, and other label rules applied by category. - Chemical symbols Cd and Pb added where thresholds are exceeded. - QR resolution tested and linked to the correct public and restricted destinations. ## Battery passport and state of health controls LMT, EV, and industrial batteries above 2 kWh need battery passports from 18 February 2027. Stationary battery energy storage systems, LMT batteries, and EV batteries need Article 14 state of health and expected lifetime data in the battery management system from 18 August 2024. These are operational systems, not paperwork fields. - Passport schema and access control aligned to Annex XIII. - Unique identifier and QR linkage in place. - Article 14 state of health data accessible on a read only basis to the permitted actors. - Status change workflow and linked new passport process for repurposed and remanufactured batteries. ## Carbon footprint and recycled content controls Article 7 and Article 8 require plant specific evidence. Carbon footprint declarations and later recycled content documentation should therefore be handled per battery model per manufacturing plant, not only at product family level. The timing and coverage are category specific, so the checklist should point to the relevant date for each model. - Article 7 declaration workflow live for the relevant category and date. - Performance class and threshold planning tracked where not yet in force. - Article 8 disclosure and minimum share roadmap tracked by category and material. - Annex VIII technical documentation updated with the supporting evidence. ## Due diligence and supplier controls From 18 August 2025, the due diligence chapter becomes live. Operators need a due diligence policy, management system, traceability, risk assessment and mitigation, third party verification by a notified body, annual public reporting, and long retention of evidence. Supplier evidence is the bottleneck, so the checklist should cover onboarding, contracts, verification, and remediation. - Battery due diligence policy approved and published. - Supplier traceability data and risk assessments collected. - Notified body verification and periodic audit route in place. - Annual public report and downstream information sharing process in place. - Ten year retention policy applied to due diligence records. ## Waste battery, collection, and reporting controls Producer responsibility and waste duties are not secondary tasks. Portable and LMT collection systems, collection targets, treatment, and reporting all need named owners and Member State specific execution. Portable batteries must hit 45 percent by 31 December 2023, 63 percent by 31 December 2027, and 73 percent by 31 December 2030. LMT batteries must hit 51 percent by 31 December 2028 and 61 percent by 31 December 2031. - Producer registrations and authorizations completed where required. - Portable and LMT collection networks documented and funded. - Recycler and treatment contracts aligned to Article 70 and Annex XII requirements. - Reporting process aligned to the Commission implementing format and local authority expectations. *Recommended next step* *Placement: after the checklist block* ## Operationalize EU Batteries Regulation (Regulation (EU) 2023/1542) Compliance checklist across ESG workflows ESG Compliance can take EU Batteries Regulation (Regulation (EU) 2023/1542) Compliance checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Batteries Regulation (Regulation (EU) 2023/1542) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Batteries Regulation (Regulation (EU) 2023/1542) Compliance checklist](/solutions/esg-compliance.md): Start from EU Batteries Regulation (Regulation (EU) 2023/1542) Compliance checklist and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Batteries Regulation (Regulation (EU) 2023/1542)](/contact.md): Review your current process, evidence gaps, and next steps for EU Batteries Regulation (Regulation (EU) 2023/1542) Compliance checklist. ## Primary sources - [Regulation (EU) 2023/1542 - Official Journal](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Primary legal text for scope, categories, dates, economic operator duties, waste obligations, and battery passport rules. - [Regulation (EU) 2023/1542 - Consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R1542&ref=sorena.io) - Useful article and annex reference for implementation teams. - [Commission Implementing Regulation (EU) 2025/2289](https://eur-lex.europa.eu/eli/reg_impl/2025/2289/oj/eng?ref=sorena.io) - Official reporting format and operational conditions for collection and treatment data. - [European Commission - Batteries overview](https://environment.ec.europa.eu/topics/waste-and-recycling/batteries_en?ref=sorena.io) - Commission implementation page for Batteries Regulation updates and related acts. ## Related Topic Guides - [Battery Carbon Footprint Declarations | Article 7 Implementation Guide](/artifacts/eu/batteries-regulation/carbon-footprint-declarations.md): Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations. - [Battery Due Diligence Program | Articles 48 to 52 Implementation Guide](/artifacts/eu/batteries-regulation/due-diligence-program.md): Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability. - [Battery Due Diligence Supplier Questionnaire | EU Batteries Regulation](/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire.md): Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542. - [Battery Labeling and Consumer Information | Article 13 and Article 74 Guide](/artifacts/eu/batteries-regulation/labeling-and-consumer-information.md): Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol. - [Battery Passport Data Model Template | Annex XIII Ready Structure](/artifacts/eu/batteries-regulation/battery-passport-data-model-template.md): Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data. - [Battery Passport Implementation | Article 77 and Article 78 Guide](/artifacts/eu/batteries-regulation/battery-passport-implementation.md): Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model. - [Battery Recycled Content and Recovery Targets | Article 8 and Annex XII Guide](/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets.md): Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII. - [EU Batteries Regulation Applicability Test | Category, Scope, and Obligation Routing](/artifacts/eu/batteries-regulation/applicability-test.md): Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Battery Categories and Scope | Portable, LMT, SLI, Industrial, EV](/artifacts/eu/batteries-regulation/battery-categories-and-scope.md): Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Compliance Program | Build an Operational Batteries Program](/artifacts/eu/batteries-regulation/compliance.md): Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations. - [EU Batteries Regulation Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar.md): Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024. - [EU Batteries Regulation FAQ | Dates, Categories, Passport, Due Diligence, and Waste Duties](/artifacts/eu/batteries-regulation/faq.md): Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts. - [EU Batteries Regulation Penalties and Enforcement | Article 93 Guide](/artifacts/eu/batteries-regulation/penalties-and-fines.md): Understand the penalty and enforcement structure in Regulation (EU) 2023/1542. - [EU Batteries Regulation Requirements | Article by Article Requirement Map](/artifacts/eu/batteries-regulation/requirements.md): Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability. - [EU Batteries Regulation vs ESPR | Battery Passport vs Digital Product Passport](/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr.md): Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/batteries-regulation/checklist --- --- title: "EU Batteries Regulation Compliance Program" canonical_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/compliance" source_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/compliance" author: "Sorena AI" description: "Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Batteries Regulation compliance program" - "batteries regulation implementation program" - "battery passport program" - "battery due diligence program" - "producer responsibility batteries program" - "EU Batteries Regulation" - "Compliance program" - "Battery passport" - "Due diligence" - "Waste batteries" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Batteries Regulation Compliance Program Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations. *EU Batteries Regulation* *Operating model* ## EU Batteries Regulation (Regulation (EU) 2023/1542) Compliance program The Batteries Regulation needs one program with several specialist workstreams. Treat it as a lifecycle compliance system that starts at design and runs through waste treatment and reporting. A batteries compliance program fails when it is split into unrelated projects. The product team builds labels, a sustainability team builds declarations, a procurement team handles raw material diligence, and a waste team handles producer responsibility, all with different identifiers and no shared evidence repository. Regulation (EU) 2023/1542 requires a more joined approach. ## Program structure that reflects the Regulation Use one control framework with six workstreams: classification and scope, product and technical documentation, data and declarations, due diligence and supplier controls, battery passport and digital services, and waste and reporting. This reflects how the Regulation itself stretches from product rules into lifecycle and waste management. Each workstream should be connected to one shared battery model register and one owner matrix. - Shared battery model and plant register. - Shared role matrix across product, import, producer responsibility, and repurposing routes. - Central evidence repository with version control. - Escalation route for market surveillance, notified body findings, supplier failures, and data quality issues. ## Date based phasing The program should be sequenced by the legal dates. Baseline application starts on 18 February 2024. Article 14 state of health and Chapter VI timing start from 18 August 2024. Due diligence and penalties readiness start from 18 August 2025. Broader labels start on 18 August 2026, removability and QR and passport on 18 February 2027, then later carbon footprint and recycled content phases continue into the 2030s. Turning those dates into milestones avoids the common mistake of waiting for the battery passport and missing the earlier operating duties. - Early phase: category register, Article 14 readiness, and technical documentation quality. - Middle phase: due diligence policy, notified body route, and separate collection symbol. - Passport phase: QR architecture, Annex XIII data model, and lifecycle update workflow. - Long tail phase: carbon threshold, recycled content, collection target, and recycling target reviews. ## Evidence first implementation The strongest program can answer simple questions quickly. What category is this battery. Which plant made it. Which article triggered the declaration. Who owns the due diligence policy. Which passport record is current. Which waste target applies in this Member State. Those answers should come from maintained evidence, not from memory. An evidence first model also makes external diligence easier, because enterprise customers and authorities usually ask for the same records. - Per model evidence pack linked to the correct plant and category. - Product evidence linked to label, declaration, and passport versions. - Supplier evidence linked to due diligence reports and remediation items. - Waste and reporting evidence linked to collection networks, recycler outputs, and authority filings. ## What to audit regularly The program should include recurring review. At minimum, review category decisions, supplier changes, declaration inputs, passport availability, and producer responsibility reporting. Also review whether implemented acts and delegated acts have changed the data or evidence requirements. If no recurring audit exists, the program will drift from the legal text quickly. - Quarterly review of model changes and new plants. - Quarterly review of supplier risk and due diligence findings. - Ongoing checks on QR resolution, passport uptime, and label accuracy. - Annual review of waste performance, reporting, and collection target trajectory. *Recommended next step* *Placement: after the compliance steps* ## Operationalize EU Batteries Regulation (Regulation (EU) 2023/1542) Compliance program across ESG workflows ESG Compliance can take EU Batteries Regulation (Regulation (EU) 2023/1542) Compliance program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Batteries Regulation (Regulation (EU) 2023/1542) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Batteries Regulation (Regulation (EU) 2023/1542) Compliance program](/solutions/esg-compliance.md): Start from EU Batteries Regulation (Regulation (EU) 2023/1542) Compliance program and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Batteries Regulation (Regulation (EU) 2023/1542)](/contact.md): Review your current process, evidence gaps, and next steps for EU Batteries Regulation (Regulation (EU) 2023/1542) Compliance program. ## Primary sources - [Regulation (EU) 2023/1542 - Official Journal](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Primary legal text for scope, categories, dates, economic operator duties, waste obligations, and battery passport rules. - [European Commission - Batteries overview](https://environment.ec.europa.eu/topics/waste-and-recycling/batteries_en?ref=sorena.io) - Commission implementation page for Batteries Regulation updates and related acts. - [Commission Implementing Regulation (EU) 2025/2289](https://eur-lex.europa.eu/eli/reg_impl/2025/2289/oj/eng?ref=sorena.io) - Official reporting format and operational conditions for collection and treatment data. - [SMCS or NANDO notified bodies search](https://webgate.ec.europa.eu/single-market-compliance-space/notified-bodies/free-search?ref=sorena.io) - Official search entry for notified bodies relevant to Regulation (EU) 2023/1542. ## Related Topic Guides - [Battery Carbon Footprint Declarations | Article 7 Implementation Guide](/artifacts/eu/batteries-regulation/carbon-footprint-declarations.md): Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations. - [Battery Due Diligence Program | Articles 48 to 52 Implementation Guide](/artifacts/eu/batteries-regulation/due-diligence-program.md): Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability. - [Battery Due Diligence Supplier Questionnaire | EU Batteries Regulation](/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire.md): Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542. - [Battery Labeling and Consumer Information | Article 13 and Article 74 Guide](/artifacts/eu/batteries-regulation/labeling-and-consumer-information.md): Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol. - [Battery Passport Data Model Template | Annex XIII Ready Structure](/artifacts/eu/batteries-regulation/battery-passport-data-model-template.md): Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data. - [Battery Passport Implementation | Article 77 and Article 78 Guide](/artifacts/eu/batteries-regulation/battery-passport-implementation.md): Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model. - [Battery Recycled Content and Recovery Targets | Article 8 and Annex XII Guide](/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets.md): Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII. - [EU Batteries Regulation Applicability Test | Category, Scope, and Obligation Routing](/artifacts/eu/batteries-regulation/applicability-test.md): Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Battery Categories and Scope | Portable, LMT, SLI, Industrial, EV](/artifacts/eu/batteries-regulation/battery-categories-and-scope.md): Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Checklist | Practical Compliance Checklist by Battery Category](/artifacts/eu/batteries-regulation/checklist.md): Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations. - [EU Batteries Regulation Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar.md): Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024. - [EU Batteries Regulation FAQ | Dates, Categories, Passport, Due Diligence, and Waste Duties](/artifacts/eu/batteries-regulation/faq.md): Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts. - [EU Batteries Regulation Penalties and Enforcement | Article 93 Guide](/artifacts/eu/batteries-regulation/penalties-and-fines.md): Understand the penalty and enforcement structure in Regulation (EU) 2023/1542. - [EU Batteries Regulation Requirements | Article by Article Requirement Map](/artifacts/eu/batteries-regulation/requirements.md): Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability. - [EU Batteries Regulation vs ESPR | Battery Passport vs Digital Product Passport](/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr.md): Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/batteries-regulation/compliance --- --- title: "EU Batteries Regulation Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Batteries Regulation deadlines" - "batteries regulation calendar" - "18 February 2024 batteries" - "18 August 2025 due diligence batteries" - "18 February 2027 battery passport" - "18 August 2026 battery labels" - "EU Batteries Regulation" - "Deadlines" - "Calendar" - "Battery passport" - "Due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Batteries Regulation Deadlines and Compliance Calendar Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024. *EU Batteries Regulation* *Calendar* ## EU Batteries Regulation (Regulation (EU) 2023/1542) Deadlines and calendar The regulation is phased. The dates should drive your delivery plan. This calendar shows what should be operational by each date, not only what the law text says. The Batteries Regulation is easy to misread as one go live event. It is not. Product duties, due diligence, labels, QR, passport, carbon footprint, recycled content, collection targets, and recycling targets all have their own milestones. A good calendar turns those dates into named work packages and owners. ## 18 February 2024: baseline application date The Regulation applies from 18 February 2024, except where Article 96 or specific provisions say otherwise. This is the date from which the baseline compliance system should have been in motion. By this point, teams should already have a category register, role map, and article based routing logic. - Create and maintain the battery model register. - Map categories, plants, and roles. - Start technical documentation and evidence structure work. - Begin tracking delegated and implementing acts that will activate later obligations. ## 18 August 2024: Article 14 and Chapter VI timing From 18 August 2024, Article 17 and Chapter VI apply, and Article 14 state of health and expected lifetime data requirements go live for stationary battery energy storage systems, LMT batteries, and EV batteries. Rechargeable industrial batteries above 2 kWh, LMT batteries, and certain other categories also start meeting some sustainability timing in this broader phase. This is the first point where digital system capability becomes visible, especially around battery management system data and technical documentation. - Article 14 read only state of health access capability live for the relevant systems. - Chapter VI producer responsibility readiness and registration planning underway. - Technical documentation updated for the relevant 2024 requirements. - Restricted substance and safety timing tracked where applicable. ## 18 August 2025: due diligence, penalties, and separate collection symbol This is one of the most important dates in the regime. Chapter VIII due diligence applies from 18 August 2025. Member States must also have penalties rules in place by that date, and Directive 2006/66 or EC is repealed with effect from that date. Article 13 separate collection symbol marking also applies from 18 August 2025. If a batteries program is not operational by this point on supplier diligence and label basics, the later passport project will not save it. - Battery due diligence policy and notified body route live. - Annual public reporting workflow prepared. - Separate collection symbol applied across affected batteries. - Member State penalty tracking and authority response plan prepared. ## 18 August 2026 and 18 February 2027: labels, removability, QR, and passport From 18 August 2026 or 18 months after the implementing act, the broader Article 13 label obligations apply. From 18 February 2027, Article 11 removability and replaceability applies, and all batteries must bear the QR code. The battery passport becomes mandatory on the same date for LMT batteries, industrial batteries above 2 kWh, and EV batteries. These dates bring together physical product changes and digital service changes, which is why they should be planned as one integrated milestone. - Article 13 label library complete and production tested. - Article 11 product and spare parts readiness complete where applicable. - QR generation and resolver live. - Battery passport live for the in scope categories. ## Later milestones through 2036 The regulation keeps evolving after the early launch dates. Carbon footprint declarations, performance classes, thresholds, recycled content disclosure and minimum shares, collection target increases, recycling efficiency targets, and recovery targets all continue into the late 2020s and 2030s. Your calendar should therefore include a long tail roadmap rather than closing the project after the first passport launch. - 31 December 2027 and 31 December 2030 portable collection target milestones. - 31 December 2028 and 31 December 2031 LMT collection target milestones. - 31 December 2025 and 31 December 2030 recycling efficiency target milestones. - 31 December 2027 and 31 December 2031 material recovery target milestones. - 18 August 2031 and 18 August 2036 recycled content minimum share milestones for the relevant categories. *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU Batteries Regulation (Regulation (EU) 2023/1542) Deadlines and calendar across ESG workflows ESG Compliance can take EU Batteries Regulation (Regulation (EU) 2023/1542) Deadlines and calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Batteries Regulation (Regulation (EU) 2023/1542) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Batteries Regulation (Regulation (EU) 2023/1542) Deadlines and calendar](/solutions/esg-compliance.md): Start from EU Batteries Regulation (Regulation (EU) 2023/1542) Deadlines and calendar and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Batteries Regulation (Regulation (EU) 2023/1542)](/contact.md): Review your current process, evidence gaps, and next steps for EU Batteries Regulation (Regulation (EU) 2023/1542) Deadlines and calendar. ## Primary sources - [Regulation (EU) 2023/1542 - Official Journal](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Primary legal text for scope, categories, dates, economic operator duties, waste obligations, and battery passport rules. - [Regulation (EU) 2023/1542 - Consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R1542&ref=sorena.io) - Useful article and annex reference for implementation teams. - [European Commission - Batteries overview](https://environment.ec.europa.eu/topics/waste-and-recycling/batteries_en?ref=sorena.io) - Commission implementation page for Batteries Regulation updates and related acts. - [Commission Implementing Regulation (EU) 2025/2289](https://eur-lex.europa.eu/eli/reg_impl/2025/2289/oj/eng?ref=sorena.io) - Official reporting format and operational conditions for collection and treatment data. ## Related Topic Guides - [Battery Carbon Footprint Declarations | Article 7 Implementation Guide](/artifacts/eu/batteries-regulation/carbon-footprint-declarations.md): Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations. - [Battery Due Diligence Program | Articles 48 to 52 Implementation Guide](/artifacts/eu/batteries-regulation/due-diligence-program.md): Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability. - [Battery Due Diligence Supplier Questionnaire | EU Batteries Regulation](/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire.md): Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542. - [Battery Labeling and Consumer Information | Article 13 and Article 74 Guide](/artifacts/eu/batteries-regulation/labeling-and-consumer-information.md): Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol. - [Battery Passport Data Model Template | Annex XIII Ready Structure](/artifacts/eu/batteries-regulation/battery-passport-data-model-template.md): Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data. - [Battery Passport Implementation | Article 77 and Article 78 Guide](/artifacts/eu/batteries-regulation/battery-passport-implementation.md): Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model. - [Battery Recycled Content and Recovery Targets | Article 8 and Annex XII Guide](/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets.md): Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII. - [EU Batteries Regulation Applicability Test | Category, Scope, and Obligation Routing](/artifacts/eu/batteries-regulation/applicability-test.md): Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Battery Categories and Scope | Portable, LMT, SLI, Industrial, EV](/artifacts/eu/batteries-regulation/battery-categories-and-scope.md): Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Checklist | Practical Compliance Checklist by Battery Category](/artifacts/eu/batteries-regulation/checklist.md): Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations. - [EU Batteries Regulation Compliance Program | Build an Operational Batteries Program](/artifacts/eu/batteries-regulation/compliance.md): Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations. - [EU Batteries Regulation FAQ | Dates, Categories, Passport, Due Diligence, and Waste Duties](/artifacts/eu/batteries-regulation/faq.md): Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts. - [EU Batteries Regulation Penalties and Enforcement | Article 93 Guide](/artifacts/eu/batteries-regulation/penalties-and-fines.md): Understand the penalty and enforcement structure in Regulation (EU) 2023/1542. - [EU Batteries Regulation Requirements | Article by Article Requirement Map](/artifacts/eu/batteries-regulation/requirements.md): Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability. - [EU Batteries Regulation vs ESPR | Battery Passport vs Digital Product Passport](/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr.md): Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar --- --- title: "Battery Due Diligence Program" canonical_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/due-diligence-program" source_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/due-diligence-program" author: "Sorena AI" description: "Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "battery due diligence program" - "Article 48 Article 49 Article 50 Article 51 Article 52 batteries" - "EU Batteries Regulation due diligence" - "notified body battery due diligence" - "battery raw materials due diligence" - "EU Batteries Regulation" - "Due diligence" - "Article 48" - "Article 49" - "Article 51" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Battery Due Diligence Program Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability. *EU Batteries Regulation* *Chapter VIII* ## EU Batteries Regulation (Regulation (EU) 2023/1542) Due diligence program Chapter VIII is a management system, a verification route, and a public reporting duty. The program has to operate continuously from 18 August 2025 and retain records for 10 years after the last battery covered by the policy is placed on the market. The due diligence chapter is sometimes treated as an ESG appendix. That is a mistake. Articles 48 to 52 create an operational program with top management ownership, chain of custody controls, supplier contract clauses, grievance mechanisms, risk mitigation planning, notified body verification, periodic audits, and annual public reporting. ## Article 48 foundation and timing From 18 August 2025, economic operators placing batteries on the market or putting them into service must fulfil the due diligence obligations in Article 48 paragraphs 2 and 3 and in Articles 49, 50, and 52, and must set up and implement battery due diligence policies. Those policies must be verified by a notified body and periodically audited by that notified body. The retention rule is long. Documentation demonstrating fulfilment must be kept for 10 years after the last battery manufactured under the relevant policy has been placed on the market. - Go live date: 18 August 2025. - Verification route: notified body third party verification and periodic audit. - Retention rule: 10 years after the last covered battery is placed on the market. - Possible collaboration through due diligence schemes does not remove the operator own responsibility. ## Article 49 management system requirements Article 49 requires a management system, not only a public statement. The operator must adopt and communicate a battery due diligence policy, align it with recognized instruments, assign top management oversight, maintain chain of custody or traceability information, incorporate due diligence clauses into supplier contracts, and operate a grievance and remediation mechanism. This means procurement, legal, and sustainability teams all have to work from the same control framework. - Top management owner and governance route. - Chain of custody or traceability system identifying upstream actors. - Supplier contract clauses covering risk management and cooperation. - Grievance, early warning, and remediation mechanism. - Record retention embedded into the management system. ## Article 50 risk management requirements Article 50 requires actual risk identification, assessment, mitigation, monitoring, and escalation. The operator must identify risks in the supply chain linked to the Annex X risk categories, design and implement a risk response strategy, monitor mitigation efforts, report findings back to top management, and consider suspension or discontinuation where mitigation fails. Where trade continues during mitigation, the operator must consult suppliers and relevant stakeholders before establishing the measurable risk mitigation strategy. - Risk register tied to the Annex X risk categories. - Measurable risk mitigation plan with owners and dates. - Escalation to top management and supplier action route. - Follow up assessments after changes in circumstances or failed mitigation. ## Article 51 verification and Article 52 disclosure The notified body verification is not ceremonial. Article 51 says the verification should cover all activities, processes, and systems used to fulfil the due diligence obligations, and it should identify areas of potential improvement. The notified body issues a verification report and, where the policy conforms, an approval decision. Article 52 then turns the program outward. The operator must provide verification materials to authorities on request, make relevant information available to immediate downstream purchasers, and annually publish a public report on the due diligence policy and significant adverse impacts and how they were addressed. - Prepare the verification evidence room before the first notified body review. - Track approval decisions, audit reports, and open improvements. - Publish the annual public report in a way that clearly identifies the batteries concerned. - Prepare a downstream information sharing package with confidentiality boundaries. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU Batteries Regulation (Regulation (EU) 2023/1542) Due diligence program across ESG workflows ESG Compliance can take EU Batteries Regulation (Regulation (EU) 2023/1542) Due diligence program from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU Batteries Regulation (Regulation (EU) 2023/1542) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Batteries Regulation (Regulation (EU) 2023/1542) Due diligence program](/solutions/esg-compliance.md): Start from EU Batteries Regulation (Regulation (EU) 2023/1542) Due diligence program and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Batteries Regulation (Regulation (EU) 2023/1542)](/contact.md): Review your current process, evidence gaps, and next steps for EU Batteries Regulation (Regulation (EU) 2023/1542) Due diligence program. ## Primary sources - [Regulation (EU) 2023/1542 - Official Journal](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Primary legal text for scope, categories, dates, economic operator duties, waste obligations, and battery passport rules. - [European Commission - Batteries overview](https://environment.ec.europa.eu/topics/waste-and-recycling/batteries_en?ref=sorena.io) - Commission implementation page for Batteries Regulation updates and related acts. - [SMCS or NANDO notified bodies search](https://webgate.ec.europa.eu/single-market-compliance-space/notified-bodies/free-search?ref=sorena.io) - Official search entry for notified bodies relevant to Regulation (EU) 2023/1542. ## Related Topic Guides - [Battery Carbon Footprint Declarations | Article 7 Implementation Guide](/artifacts/eu/batteries-regulation/carbon-footprint-declarations.md): Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations. - [Battery Due Diligence Supplier Questionnaire | EU Batteries Regulation](/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire.md): Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542. - [Battery Labeling and Consumer Information | Article 13 and Article 74 Guide](/artifacts/eu/batteries-regulation/labeling-and-consumer-information.md): Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol. - [Battery Passport Data Model Template | Annex XIII Ready Structure](/artifacts/eu/batteries-regulation/battery-passport-data-model-template.md): Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data. - [Battery Passport Implementation | Article 77 and Article 78 Guide](/artifacts/eu/batteries-regulation/battery-passport-implementation.md): Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model. - [Battery Recycled Content and Recovery Targets | Article 8 and Annex XII Guide](/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets.md): Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII. - [EU Batteries Regulation Applicability Test | Category, Scope, and Obligation Routing](/artifacts/eu/batteries-regulation/applicability-test.md): Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Battery Categories and Scope | Portable, LMT, SLI, Industrial, EV](/artifacts/eu/batteries-regulation/battery-categories-and-scope.md): Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Checklist | Practical Compliance Checklist by Battery Category](/artifacts/eu/batteries-regulation/checklist.md): Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations. - [EU Batteries Regulation Compliance Program | Build an Operational Batteries Program](/artifacts/eu/batteries-regulation/compliance.md): Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations. - [EU Batteries Regulation Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar.md): Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024. - [EU Batteries Regulation FAQ | Dates, Categories, Passport, Due Diligence, and Waste Duties](/artifacts/eu/batteries-regulation/faq.md): Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts. - [EU Batteries Regulation Penalties and Enforcement | Article 93 Guide](/artifacts/eu/batteries-regulation/penalties-and-fines.md): Understand the penalty and enforcement structure in Regulation (EU) 2023/1542. - [EU Batteries Regulation Requirements | Article by Article Requirement Map](/artifacts/eu/batteries-regulation/requirements.md): Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability. - [EU Batteries Regulation vs ESPR | Battery Passport vs Digital Product Passport](/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr.md): Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/batteries-regulation/due-diligence-program --- --- title: "EU Batteries Regulation FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/faq" source_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/faq" author: "Sorena AI" description: "Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Batteries Regulation FAQ" - "when does Batteries Regulation apply" - "battery passport FAQ" - "Article 11 removability FAQ" - "Article 14 state of health FAQ" - "due diligence FAQ batteries" - "EU Batteries Regulation" - "FAQ" - "Battery passport" - "Due diligence" - "Collection targets" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Batteries Regulation FAQ Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts. *EU Batteries Regulation* *FAQ* ## EU Batteries Regulation (Regulation (EU) 2023/1542) FAQ Short answers, exact dates, and the parts teams most often get wrong. Use these answers for orientation, then move to the deeper pages for implementation detail. This FAQ focuses on operational questions that come up during product launch, procurement, and portfolio review. Dates are stated explicitly because the Batteries Regulation is phased and the wrong date is one of the most common sources of implementation error. ## When does the Regulation apply? The Regulation applies from 18 February 2024, except where Article 96 or specific provisions set a later date. Article 14 state of health and Chapter VI timing start from 18 August 2024. Chapter VIII due diligence starts from 18 August 2025. Article 11 removability, Article 13 QR marking, and Article 77 battery passport start from 18 February 2027 for the relevant cases. ## Which batteries need a battery passport? From 18 February 2027, each LMT battery, each industrial battery with a capacity greater than 2 kWh, and each electric vehicle battery placed on the market or put into service must have a battery passport. Portable batteries and SLI batteries do not fall into the Article 77 passport requirement unless another rule changes the picture. ## Which batteries need state of health and expected lifetime data? From 18 August 2024, up to date Annex VII parameter data must be contained in the battery management system of stationary battery energy storage systems, LMT batteries, and electric vehicle batteries. Read only access must be provided on a non discriminatory basis to the legally permitted actors for the listed purposes in Article 14. ## How does Article 11 removability actually work? Article 11 applies from 18 February 2027. Products incorporating portable batteries must allow the batteries to be readily removable and replaceable by the end user, subject to the listed derogations and exclusions. Products incorporating LMT batteries must allow the batteries and individual cells in the battery pack to be readily removable and replaceable by an independent professional. Spare parts availability for portable and LMT batteries lasts at least five years after the last unit of the equipment model is placed on the market. ## When does battery due diligence start? Battery due diligence obligations start from 18 August 2025. Economic operators in scope must set up and implement a due diligence policy, have it verified and periodically audited by a notified body, keep evidence for 10 years after the last covered battery is placed on the market, and publish an annual public report. ## What collection targets should producers know? Portable battery collection targets are 45 percent by 31 December 2023, 63 percent by 31 December 2027, and 73 percent by 31 December 2030. LMT battery collection targets are 51 percent by 31 December 2028 and 61 percent by 31 December 2031. These are producer responsibility obligations and require actual collection systems and reporting. ## What are the main recycling and recycled content milestones? Recycling efficiency targets apply by 31 December 2025 and rise by 31 December 2030. Material recovery targets for cobalt, copper, lead, lithium, and nickel apply by 31 December 2027 and rise by 31 December 2031. Article 8 recycled content disclosure for certain categories starts from 18 August 2028 and minimum recycled content shares start from 18 August 2031, with higher levels from 18 August 2036 and later coverage for LMT batteries. *Recommended next step* *Placement: after the FAQ section* ## Use EU Batteries Regulation (Regulation (EU) 2023/1542) FAQ as a cited research workflow Research Copilot can take EU Batteries Regulation (Regulation (EU) 2023/1542) FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU Batteries Regulation (Regulation (EU) 2023/1542) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Batteries Regulation (Regulation (EU) 2023/1542) FAQ](/solutions/research-copilot.md): Start from EU Batteries Regulation (Regulation (EU) 2023/1542) FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Batteries Regulation (Regulation (EU) 2023/1542)](/contact.md): Review your current process, evidence gaps, and next steps for EU Batteries Regulation (Regulation (EU) 2023/1542) FAQ. ## Primary sources - [Regulation (EU) 2023/1542 - Official Journal](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Primary legal text for scope, categories, dates, economic operator duties, waste obligations, and battery passport rules. - [Regulation (EU) 2023/1542 - Consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R1542&ref=sorena.io) - Useful article and annex reference for implementation teams. - [European Commission - Batteries overview](https://environment.ec.europa.eu/topics/waste-and-recycling/batteries_en?ref=sorena.io) - Commission implementation page for Batteries Regulation updates and related acts. - [European Commission - New rules to boost recycling efficiency of waste batteries](https://environment.ec.europa.eu/news/new-rules-boost-recycling-efficiency-waste-batteries-2025-07-04_en?ref=sorena.io) - Commission summary of Delegated Regulation (EU) 2025/606 and the recycling and recovery targets. ## Related Topic Guides - [Battery Carbon Footprint Declarations | Article 7 Implementation Guide](/artifacts/eu/batteries-regulation/carbon-footprint-declarations.md): Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations. - [Battery Due Diligence Program | Articles 48 to 52 Implementation Guide](/artifacts/eu/batteries-regulation/due-diligence-program.md): Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability. - [Battery Due Diligence Supplier Questionnaire | EU Batteries Regulation](/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire.md): Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542. - [Battery Labeling and Consumer Information | Article 13 and Article 74 Guide](/artifacts/eu/batteries-regulation/labeling-and-consumer-information.md): Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol. - [Battery Passport Data Model Template | Annex XIII Ready Structure](/artifacts/eu/batteries-regulation/battery-passport-data-model-template.md): Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data. - [Battery Passport Implementation | Article 77 and Article 78 Guide](/artifacts/eu/batteries-regulation/battery-passport-implementation.md): Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model. - [Battery Recycled Content and Recovery Targets | Article 8 and Annex XII Guide](/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets.md): Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII. - [EU Batteries Regulation Applicability Test | Category, Scope, and Obligation Routing](/artifacts/eu/batteries-regulation/applicability-test.md): Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Battery Categories and Scope | Portable, LMT, SLI, Industrial, EV](/artifacts/eu/batteries-regulation/battery-categories-and-scope.md): Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Checklist | Practical Compliance Checklist by Battery Category](/artifacts/eu/batteries-regulation/checklist.md): Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations. - [EU Batteries Regulation Compliance Program | Build an Operational Batteries Program](/artifacts/eu/batteries-regulation/compliance.md): Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations. - [EU Batteries Regulation Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar.md): Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024. - [EU Batteries Regulation Penalties and Enforcement | Article 93 Guide](/artifacts/eu/batteries-regulation/penalties-and-fines.md): Understand the penalty and enforcement structure in Regulation (EU) 2023/1542. - [EU Batteries Regulation Requirements | Article by Article Requirement Map](/artifacts/eu/batteries-regulation/requirements.md): Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability. - [EU Batteries Regulation vs ESPR | Battery Passport vs Digital Product Passport](/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr.md): Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/batteries-regulation/faq --- --- title: "Battery Labeling and Consumer Information" canonical_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/labeling-and-consumer-information" source_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/labeling-and-consumer-information" author: "Sorena AI" description: "Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "battery labeling EU Batteries Regulation" - "Article 13 batteries" - "QR code battery label" - "separate collection symbol batteries" - "Article 74 consumer information batteries" - "EU Batteries Regulation" - "Labeling" - "QR code" - "Article 13" - "Consumer information" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Battery Labeling and Consumer Information Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol. *EU Batteries Regulation* *Article 13* ## EU Batteries Regulation (Regulation (EU) 2023/1542) Labeling and consumer information Labeling in the Batteries Regulation is a controlled product artifact, not just packaging artwork. The label, QR code, declaration links, and waste information should be managed as one connected information system. Article 13 creates a phased label regime. Article 74 adds waste prevention and management information that also has to reach end users and distributors. The practical challenge is to keep the physical mark, the digital destination, and the underlying product data aligned over time. ## The phased label schedule From 18 August 2025, all batteries must be marked with the separate collection symbol. From 18 August 2026 or 18 months after the implementing act, whichever is later, batteries must bear the broader labels in Article 13 paragraphs 1 to 3. From 18 February 2027, all batteries must be marked with a QR code as described in Part C of Annex VI. These dates should be reflected in packaging change control and release calendars. - 18 August 2025: separate collection symbol. - 18 August 2026 or later trigger: general label information, capacity, and non rechargeable labels as applicable. - 18 February 2027: QR code for all batteries. - 18 August 2025: harmonized label specifications expected through implementing acts. ## What the QR code must lead to The destination changes by category. For LMT batteries, industrial batteries above 2 kWh, and EV batteries, the QR code must give access to the battery passport under Article 77. For other batteries, it must provide the applicable label information, the declaration of conformity, the battery due diligence report under Article 52(3), and the Article 74 information on prevention and management of waste batteries. For SLI batteries it must also provide the recycled content information required by Article 8. This means one QR pattern can serve all categories only if the resolver knows the category and routes to the correct content set. - Passport route for in scope passport categories. - Declaration and waste information route for other categories. - Article 52(3) due diligence report linkage where applicable. - SLI recycled content linkage where Article 8 data applies. ## Usability and accessibility The Regulation expects labels and QR codes to be visible, legible, indelible, and accessible. The recitals also point to accessibility for persons with disabilities. Treat this as a UX and accessibility problem, not only a print problem. The QR landing page should be easy to navigate, stable over time, and not hide basic required information behind unnecessary gates. - Readable contrast and size for the QR code and physical labels. - Persistent digital destination with minimal failure risk. - Accessible landing page structure and plain language copy. - Version control linking physical label versions to digital content versions. ## Article 74 information package Article 74 requires information for end users and distributors regarding prevention and management of waste batteries. This includes collection arrangements, prevention measures, preparation for re use and repurposing where relevant, the role of end users, and the meaning of labels and symbols. The QR route is the most efficient way to keep that information current, but the content still needs an owner and review cycle. A well managed Article 74 information package reduces waste handling mistakes and also helps enterprise customers understand the lifecycle expectations. - Explain where and how waste batteries can be returned. - Explain the role of end users in separate collection. - Explain the meaning of the labels and symbols. - Keep the information aligned with Member State collection arrangements where relevant. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU Batteries Regulation (Regulation (EU) 2023/1542) Labeling and consumer information across ESG workflows ESG Compliance can take EU Batteries Regulation (Regulation (EU) 2023/1542) Labeling and consumer information from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU Batteries Regulation (Regulation (EU) 2023/1542) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Batteries Regulation (Regulation (EU) 2023/1542) Labeling and consumer information](/solutions/esg-compliance.md): Start from EU Batteries Regulation (Regulation (EU) 2023/1542) Labeling and consumer information and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Batteries Regulation (Regulation (EU) 2023/1542)](/contact.md): Review your current process, evidence gaps, and next steps for EU Batteries Regulation (Regulation (EU) 2023/1542) Labeling and consumer information. ## Primary sources - [Regulation (EU) 2023/1542 - Official Journal](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Primary legal text for scope, categories, dates, economic operator duties, waste obligations, and battery passport rules. - [Regulation (EU) 2023/1542 - Consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R1542&ref=sorena.io) - Useful article and annex reference for implementation teams. - [Commission Notice C/2025/214 - removability and replaceability guidelines](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:C_202500214&ref=sorena.io) - Official guidance on how Article 11 removability and replaceability should be interpreted. - [European Commission - Batteries overview](https://environment.ec.europa.eu/topics/waste-and-recycling/batteries_en?ref=sorena.io) - Commission implementation page for Batteries Regulation updates and related acts. ## Related Topic Guides - [Battery Carbon Footprint Declarations | Article 7 Implementation Guide](/artifacts/eu/batteries-regulation/carbon-footprint-declarations.md): Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations. - [Battery Due Diligence Program | Articles 48 to 52 Implementation Guide](/artifacts/eu/batteries-regulation/due-diligence-program.md): Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability. - [Battery Due Diligence Supplier Questionnaire | EU Batteries Regulation](/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire.md): Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542. - [Battery Passport Data Model Template | Annex XIII Ready Structure](/artifacts/eu/batteries-regulation/battery-passport-data-model-template.md): Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data. - [Battery Passport Implementation | Article 77 and Article 78 Guide](/artifacts/eu/batteries-regulation/battery-passport-implementation.md): Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model. - [Battery Recycled Content and Recovery Targets | Article 8 and Annex XII Guide](/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets.md): Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII. - [EU Batteries Regulation Applicability Test | Category, Scope, and Obligation Routing](/artifacts/eu/batteries-regulation/applicability-test.md): Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Battery Categories and Scope | Portable, LMT, SLI, Industrial, EV](/artifacts/eu/batteries-regulation/battery-categories-and-scope.md): Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Checklist | Practical Compliance Checklist by Battery Category](/artifacts/eu/batteries-regulation/checklist.md): Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations. - [EU Batteries Regulation Compliance Program | Build an Operational Batteries Program](/artifacts/eu/batteries-regulation/compliance.md): Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations. - [EU Batteries Regulation Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar.md): Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024. - [EU Batteries Regulation FAQ | Dates, Categories, Passport, Due Diligence, and Waste Duties](/artifacts/eu/batteries-regulation/faq.md): Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts. - [EU Batteries Regulation Penalties and Enforcement | Article 93 Guide](/artifacts/eu/batteries-regulation/penalties-and-fines.md): Understand the penalty and enforcement structure in Regulation (EU) 2023/1542. - [EU Batteries Regulation Requirements | Article by Article Requirement Map](/artifacts/eu/batteries-regulation/requirements.md): Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability. - [EU Batteries Regulation vs ESPR | Battery Passport vs Digital Product Passport](/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr.md): Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/batteries-regulation/labeling-and-consumer-information --- --- title: "EU Batteries Regulation Penalties and Enforcement" canonical_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/penalties-and-fines" author: "Sorena AI" description: "Understand the penalty and enforcement structure in Regulation (EU) 2023/1542." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Batteries Regulation penalties" - "Article 93 Batteries Regulation" - "batteries enforcement" - "market surveillance batteries EU" - "battery passport enforcement" - "due diligence enforcement batteries" - "EU Batteries Regulation" - "Penalties" - "Enforcement" - "Market surveillance" - "Article 93" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Batteries Regulation Penalties and Enforcement Understand the penalty and enforcement structure in Regulation (EU) 2023/1542. *EU Batteries Regulation* *Enforcement* ## EU Batteries Regulation (Regulation (EU) 2023/1542) Penalties and enforcement Penalty exposure under the Batteries Regulation is driven by evidence quality and operational failures. The Regulation leaves the specific fine rules to Member States, but it still defines the enforcement shape and the date by which those rules must exist. Article 93 is short, but it matters. Member States had to lay down their penalties rules by 18 August 2025, and those penalties must be effective, proportionate, and dissuasive. For operators, that means the practical defense is a working control system with complete evidence, not a last minute legal memo. ## What the Regulation requires on penalties Article 93 requires Member States to lay down rules on penalties applicable to infringements of the Regulation and to take all measures necessary to ensure that they are implemented by 18 August 2025. The Member States must notify the Commission of those rules and any later amendments. This means enforcement detail can vary by country, so businesses placing batteries across the Union should track national implementations rather than relying on one penalty assumption. - Penalty rules had to be in place by 18 August 2025. - Penalty rules can vary by Member State. - The legal standard is effective, proportionate, and dissuasive. - Operators need a country aware enforcement map if they sell across multiple Member States. *Recommended next step* *Placement: after the enforcement section* ## Use EU Batteries Regulation (Regulation (EU) 2023/1542) Penalties and enforcement as a cited research workflow Research Copilot can take EU Batteries Regulation (Regulation (EU) 2023/1542) Penalties and enforcement from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Batteries Regulation (Regulation (EU) 2023/1542) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Batteries Regulation (Regulation (EU) 2023/1542) Penalties and enforcement](/solutions/research-copilot.md): Start from EU Batteries Regulation (Regulation (EU) 2023/1542) Penalties and enforcement and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Batteries Regulation (Regulation (EU) 2023/1542)](/contact.md): Review your current process, evidence gaps, and next steps for EU Batteries Regulation (Regulation (EU) 2023/1542) Penalties and enforcement. ## What typically increases enforcement risk The largest risk areas are the ones where the Regulation combines a visible product obligation with a deeper evidence duty. Examples are inaccurate labels, broken or incomplete QR content, stale or inaccessible battery passport data, missing due diligence records, weak supplier traceability, and underdeveloped producer responsibility systems. A second risk driver is inconsistency across systems. If the label, the declaration, the passport, and the due diligence report refer to different model or plant realities, the operator will look uncontrolled. - No defensible category or role classification record. - QR or passport content that is incomplete, inaccurate, or unavailable. - Due diligence program that exists on paper but lacks verification, audit, or public reporting. - Waste and collection systems that do not support the legal targets and reporting claims. - Technical documentation that cannot support Article 7, Article 8, or safety claims. ## What evidence lowers exposure A good enforcement posture is simple to describe. The operator can show what category the battery is in, which dates apply, which technical and lifecycle obligations were triggered, who owns them, and where the current evidence is stored. This helps for market surveillance, customer diligence, and notified body interactions. Evidence quality also matters because the Regulation uses technical documentation and reports repeatedly as the proof layer for compliance. - Battery register with category, plant, and model versioning. - Label and QR test results and controlled templates. - Passport access logs, uptime records, and update history. - Due diligence verification reports, approval decisions, audit reports, and annual public reports. - Producer responsibility, collection, recycler, and reporting records. ## Enforcement readiness actions Teams should prepare for authority questions before they arrive. That means knowing which national authorities, notified bodies, and producer responsibility channels matter in each market, and having one owner who can coordinate a response quickly. The quality of that response often depends on whether the evidence repository has been kept current during normal operations. - Track national penalty implementations in all selling markets. - Maintain an authority and notified body contact matrix. - Run periodic evidence room reviews against the current battery portfolio. - Tie corrective actions to root cause and closure evidence. ## Primary sources - [Regulation (EU) 2023/1542 - Official Journal](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Primary legal text for scope, categories, dates, economic operator duties, waste obligations, and battery passport rules. - [Regulation (EU) 2023/1542 - Consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R1542&ref=sorena.io) - Useful article and annex reference for implementation teams. - [European Commission - Batteries overview](https://environment.ec.europa.eu/topics/waste-and-recycling/batteries_en?ref=sorena.io) - Commission implementation page for Batteries Regulation updates and related acts. - [SMCS or NANDO notified bodies search](https://webgate.ec.europa.eu/single-market-compliance-space/notified-bodies/free-search?ref=sorena.io) - Official search entry for notified bodies relevant to Regulation (EU) 2023/1542. ## Related Topic Guides - [Battery Carbon Footprint Declarations | Article 7 Implementation Guide](/artifacts/eu/batteries-regulation/carbon-footprint-declarations.md): Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations. - [Battery Due Diligence Program | Articles 48 to 52 Implementation Guide](/artifacts/eu/batteries-regulation/due-diligence-program.md): Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability. - [Battery Due Diligence Supplier Questionnaire | EU Batteries Regulation](/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire.md): Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542. - [Battery Labeling and Consumer Information | Article 13 and Article 74 Guide](/artifacts/eu/batteries-regulation/labeling-and-consumer-information.md): Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol. - [Battery Passport Data Model Template | Annex XIII Ready Structure](/artifacts/eu/batteries-regulation/battery-passport-data-model-template.md): Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data. - [Battery Passport Implementation | Article 77 and Article 78 Guide](/artifacts/eu/batteries-regulation/battery-passport-implementation.md): Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model. - [Battery Recycled Content and Recovery Targets | Article 8 and Annex XII Guide](/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets.md): Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII. - [EU Batteries Regulation Applicability Test | Category, Scope, and Obligation Routing](/artifacts/eu/batteries-regulation/applicability-test.md): Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Battery Categories and Scope | Portable, LMT, SLI, Industrial, EV](/artifacts/eu/batteries-regulation/battery-categories-and-scope.md): Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Checklist | Practical Compliance Checklist by Battery Category](/artifacts/eu/batteries-regulation/checklist.md): Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations. - [EU Batteries Regulation Compliance Program | Build an Operational Batteries Program](/artifacts/eu/batteries-regulation/compliance.md): Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations. - [EU Batteries Regulation Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar.md): Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024. - [EU Batteries Regulation FAQ | Dates, Categories, Passport, Due Diligence, and Waste Duties](/artifacts/eu/batteries-regulation/faq.md): Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts. - [EU Batteries Regulation Requirements | Article by Article Requirement Map](/artifacts/eu/batteries-regulation/requirements.md): Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability. - [EU Batteries Regulation vs ESPR | Battery Passport vs Digital Product Passport](/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr.md): Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/batteries-regulation/penalties-and-fines --- --- title: "Battery Recycled Content and Recovery Targets" canonical_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets" source_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets" author: "Sorena AI" description: "Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "battery recycled content targets" - "Article 8 Batteries Regulation" - "battery recovery targets Annex XII" - "recycling efficiency targets batteries" - "material recovery targets cobalt copper lithium nickel lead" - "recycled content minimum share batteries" - "EU Batteries Regulation" - "Recycled content" - "Recovery targets" - "Article 8" - "Annex XII" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Battery Recycled Content and Recovery Targets Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII. *EU Batteries Regulation* *Circularity* ## EU Batteries Regulation (Regulation (EU) 2023/1542) Recycled content and recovery targets The circularity duties split into two different tracks: battery content rules and waste treatment performance rules. Keep those tracks distinct in your program, then join them through shared evidence and supplier and recycler governance. This page covers two obligations that are often mixed together. Article 8 deals with recycled content in new batteries. Annex XII and the related delegated act deal with recycling efficiency and material recovery from waste batteries. Both are central to the circularity logic of the Regulation, but they sit at different points in the lifecycle and involve different evidence owners. ## Article 8 recycled content roadmap Article 8 first starts with disclosure. From 18 August 2028, or 24 months after the delegated act enters into force, industrial batteries above 2 kWh except those with exclusively external storage, EV batteries, and SLI batteries containing cobalt, lead, lithium, or nickel in active materials must be accompanied by documentation on the recovered share of those materials. LMT batteries enter this disclosure stage later, from 18 August 2033. The minimum share stage comes later. From 18 August 2031, the covered industrial batteries above 2 kWh, EV batteries, and SLI batteries must meet the minimum shares. From 18 August 2036, higher minimum shares apply and LMT batteries join the scope for the later stage. - Disclosure stage from 18 August 2028 for industrial above 2 kWh except external storage, EV, and SLI. - Disclosure stage from 18 August 2033 for LMT. - Minimum shares from 18 August 2031: 16 percent cobalt, 85 percent lead, 6 percent lithium, 6 percent nickel. - Higher shares from 18 August 2036: 26 percent cobalt, 85 percent lead, 12 percent lithium, 15 percent nickel. ## What the recycled content evidence must show Article 8 is plant and model specific. The technical documentation in Annex VIII must show the percentage share recovered from battery manufacturing waste or post consumer waste for the relevant materials. That means the sourcing and calculation evidence must be specific enough to support a battery model per year and per manufacturing plant. This is not a generic corporate recycled content claim. It is product evidence. - Per model and per plant recovered content calculation. - Material provenance and calculation inputs. - Supporting study and technical documentation linkage. - Review trigger when sourcing or process changes affect the share. ## Recycling efficiency and material recovery targets The waste side uses Annex XII targets. By 31 December 2025, recycling must achieve at least 75 percent by average weight for lead acid batteries, 65 percent for lithium based batteries, 80 percent for nickel cadmium batteries, and 50 percent for other waste batteries. By 31 December 2030, the lead acid target rises to 80 percent and the lithium based target rises to 70 percent. Material recovery targets are separate. By 31 December 2027, recycling must achieve at least 90 percent for cobalt, copper, lead, and nickel and 50 percent for lithium. By 31 December 2031, those targets rise to 95 percent for cobalt, copper, lead, and nickel and 80 percent for lithium. - 31 December 2025: first recycling efficiency target set. - 31 December 2030: higher lead acid and lithium based efficiency targets. - 31 December 2027: first critical material recovery target set. - 31 December 2031: higher critical material recovery target set. ## Operating model for circularity evidence Most organizations need two evidence chains. The first chain covers recycled content claims for new batteries and is usually owned by procurement, materials, manufacturing, and technical documentation teams. The second chain covers recycling and recovery performance and is usually owned by producer responsibility, recycler management, and reporting teams. Both chains should still connect in one central evidence room so the operator can explain the full circularity story from sourcing through end of life. - Supplier and plant data controls for Article 8. - Recycler contract and KPI controls for Annex XII. - Delegated and implementing act tracking for methodology changes. - Annual review of target progress and corrective actions. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU Batteries Regulation (Regulation (EU) 2023/1542) Recycled content and recovery targets across ESG workflows ESG Compliance can take EU Batteries Regulation (Regulation (EU) 2023/1542) Recycled content and recovery targets from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU Batteries Regulation (Regulation (EU) 2023/1542) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Batteries Regulation (Regulation (EU) 2023/1542) Recycled content and recovery targets](/solutions/esg-compliance.md): Start from EU Batteries Regulation (Regulation (EU) 2023/1542) Recycled content and recovery targets and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Batteries Regulation (Regulation (EU) 2023/1542)](/contact.md): Review your current process, evidence gaps, and next steps for EU Batteries Regulation (Regulation (EU) 2023/1542) Recycled content and recovery targets. ## Primary sources - [Regulation (EU) 2023/1542 - Official Journal](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Primary legal text for scope, categories, dates, economic operator duties, waste obligations, and battery passport rules. - [Commission Delegated Regulation (EU) 2025/606](https://eur-lex.europa.eu/eli/reg_del/2025/606/oj/eng?ref=sorena.io) - Official methodology for calculating and verifying recycling efficiency and recovery of materials from waste batteries. - [European Commission - New rules to boost recycling efficiency of waste batteries](https://environment.ec.europa.eu/news/new-rules-boost-recycling-efficiency-waste-batteries-2025-07-04_en?ref=sorena.io) - Commission summary of Delegated Regulation (EU) 2025/606 and the recycling and recovery targets. - [Commission Implementing Regulation (EU) 2025/2289](https://eur-lex.europa.eu/eli/reg_impl/2025/2289/oj/eng?ref=sorena.io) - Official reporting format and operational conditions for collection and treatment data. ## Related Topic Guides - [Battery Carbon Footprint Declarations | Article 7 Implementation Guide](/artifacts/eu/batteries-regulation/carbon-footprint-declarations.md): Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations. - [Battery Due Diligence Program | Articles 48 to 52 Implementation Guide](/artifacts/eu/batteries-regulation/due-diligence-program.md): Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability. - [Battery Due Diligence Supplier Questionnaire | EU Batteries Regulation](/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire.md): Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542. - [Battery Labeling and Consumer Information | Article 13 and Article 74 Guide](/artifacts/eu/batteries-regulation/labeling-and-consumer-information.md): Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol. - [Battery Passport Data Model Template | Annex XIII Ready Structure](/artifacts/eu/batteries-regulation/battery-passport-data-model-template.md): Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data. - [Battery Passport Implementation | Article 77 and Article 78 Guide](/artifacts/eu/batteries-regulation/battery-passport-implementation.md): Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model. - [EU Batteries Regulation Applicability Test | Category, Scope, and Obligation Routing](/artifacts/eu/batteries-regulation/applicability-test.md): Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Battery Categories and Scope | Portable, LMT, SLI, Industrial, EV](/artifacts/eu/batteries-regulation/battery-categories-and-scope.md): Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Checklist | Practical Compliance Checklist by Battery Category](/artifacts/eu/batteries-regulation/checklist.md): Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations. - [EU Batteries Regulation Compliance Program | Build an Operational Batteries Program](/artifacts/eu/batteries-regulation/compliance.md): Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations. - [EU Batteries Regulation Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar.md): Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024. - [EU Batteries Regulation FAQ | Dates, Categories, Passport, Due Diligence, and Waste Duties](/artifacts/eu/batteries-regulation/faq.md): Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts. - [EU Batteries Regulation Penalties and Enforcement | Article 93 Guide](/artifacts/eu/batteries-regulation/penalties-and-fines.md): Understand the penalty and enforcement structure in Regulation (EU) 2023/1542. - [EU Batteries Regulation Requirements | Article by Article Requirement Map](/artifacts/eu/batteries-regulation/requirements.md): Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability. - [EU Batteries Regulation vs ESPR | Battery Passport vs Digital Product Passport](/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr.md): Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets --- --- title: "EU Batteries Regulation Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/requirements" source_url: "https://www.sorena.io/artifacts/eu/batteries-regulation/requirements" author: "Sorena AI" description: "Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Batteries Regulation requirements" - "Regulation (EU) 2023/1542 requirements" - "battery passport requirements" - "carbon footprint requirements" - "due diligence requirements" - "battery labeling requirements" - "producer responsibility batteries" - "EU Batteries Regulation" - "Requirements" - "Battery passport" - "Due diligence" - "Waste batteries" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Batteries Regulation Requirements Get a practical map of the main requirements in Regulation (EU) 2023/1542, including category rules, carbon footprint, recycled content, removability. *EU Batteries Regulation* *Overview* ## EU Batteries Regulation (Regulation (EU) 2023/1542) Requirements overview The Batteries Regulation is easier to implement when you treat it as requirement tracks, not one long list. This page routes the main articles into workstreams and evidence outputs so teams know what to build first. The Regulation touches product design, technical documentation, data access, responsible sourcing, labels, waste collection, treatment, and reporting. A useful implementation model groups those duties into tracks that can be owned and audited. ## Track 1: category and product route The first requirement track is classification. Teams must determine whether the battery is portable, LMT, SLI, industrial, or EV, and whether it is incorporated into another product. This route decides which later duties apply and when they start. Without a current category record, every other requirement becomes unstable. - Key outputs: category memo, model register, role map. - Key articles: Article 3 and Article 96. - Key teams: product, engineering, compliance, import or trade teams. ## Track 2: sustainability and technical documentation This track covers Article 7 carbon footprint, Article 8 recycled content, and the Annex VIII technical documentation used to prove those claims and other product duties. For several categories, the evidence is model and plant specific and then later moves into performance classes and threshold or minimum share tests. Teams should treat this track as a controlled product data program rather than one off declarations. - Key outputs: declaration files, supporting studies, plant specific technical documentation. - Key articles: Articles 7 and 8, Annex II, Annex VIII. - Key teams: sustainability, manufacturing, quality, product compliance. ## Track 3: product usability, labels, and digital information This track covers removability and replaceability, labels, QR, state of health data, and the battery passport. It blends physical product design and digital service design. The same model and identifier need to stay consistent across the battery, the packaging, the QR landing page, and the passport. For in scope categories, this becomes one of the most visible parts of the regulation because users, recyclers, and authorities all interact with it. - Key outputs: removability evidence, label templates, QR resolver, Article 14 access, passport schema. - Key articles: Articles 11, 13, 14, 77, and 78. - Key teams: product engineering, packaging, digital, service, repair, and data governance teams. ## Track 4: due diligence and supplier governance The due diligence track starts on 18 August 2025 and creates a management system, traceability, risk management, notified body verification, and disclosure model focused on Annex X raw materials and risks. This is not optional for the operators it covers and requires supplier cooperation to work. Because of the ten year retention rule and annual public report duty, this track needs strong records management. - Key outputs: due diligence policy, traceability records, risk register, verification reports, public report. - Key articles: Articles 48 to 52. - Key teams: procurement, legal, sustainability, supplier quality, internal audit. ## Track 5: producer responsibility, waste, and reporting The waste track covers EPR and authorizations, collection systems, treatment, recycling efficiency, recovery targets, and reporting. Portable and LMT collection targets are direct operational obligations, and recycler and treatment evidence becomes important for end of life performance and reporting. This track is often managed separately from product compliance, but it should still use the same model and category master data. - Key outputs: registrations, collection network records, treatment contracts, recycler KPI reports, authority submissions. - Key articles: Articles 54 to 76 and Annex XI and Annex XII. - Key teams: producer responsibility, logistics, waste operations, reporting, public affairs. *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU Batteries Regulation (Regulation (EU) 2023/1542) Requirements overview across ESG workflows ESG Compliance can take EU Batteries Regulation (Regulation (EU) 2023/1542) Requirements overview from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Batteries Regulation (Regulation (EU) 2023/1542) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Batteries Regulation (Regulation (EU) 2023/1542) Requirements overview](/solutions/esg-compliance.md): Start from EU Batteries Regulation (Regulation (EU) 2023/1542) Requirements overview and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Batteries Regulation (Regulation (EU) 2023/1542)](/contact.md): Review your current process, evidence gaps, and next steps for EU Batteries Regulation (Regulation (EU) 2023/1542) Requirements overview. ## Primary sources - [Regulation (EU) 2023/1542 - Official Journal](https://eur-lex.europa.eu/eli/reg/2023/1542/oj/eng?ref=sorena.io) - Primary legal text for scope, categories, dates, economic operator duties, waste obligations, and battery passport rules. - [Regulation (EU) 2023/1542 - Consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R1542&ref=sorena.io) - Useful article and annex reference for implementation teams. - [European Commission - Batteries overview](https://environment.ec.europa.eu/topics/waste-and-recycling/batteries_en?ref=sorena.io) - Commission implementation page for Batteries Regulation updates and related acts. - [Commission Delegated Regulation (EU) 2025/606](https://eur-lex.europa.eu/eli/reg_del/2025/606/oj/eng?ref=sorena.io) - Official methodology for calculating and verifying recycling efficiency and recovery of materials from waste batteries. ## Related Topic Guides - [Battery Carbon Footprint Declarations | Article 7 Implementation Guide](/artifacts/eu/batteries-regulation/carbon-footprint-declarations.md): Implement the carbon footprint declaration requirements in Article 7 of Regulation (EU) 2023/1542 with plant specific battery model declarations. - [Battery Due Diligence Program | Articles 48 to 52 Implementation Guide](/artifacts/eu/batteries-regulation/due-diligence-program.md): Build a battery due diligence program for Regulation (EU) 2023/1542 with an Article 48 policy, Article 49 management system and traceability. - [Battery Due Diligence Supplier Questionnaire | EU Batteries Regulation](/artifacts/eu/batteries-regulation/battery-due-diligence-supplier-questionnaire.md): Use a practical supplier questionnaire for the battery due diligence obligations in Articles 48 to 52 of Regulation (EU) 2023/1542. - [Battery Labeling and Consumer Information | Article 13 and Article 74 Guide](/artifacts/eu/batteries-regulation/labeling-and-consumer-information.md): Implement battery labeling, QR code, and consumer information duties under Regulation (EU) 2023/1542, including the separate collection symbol. - [Battery Passport Data Model Template | Annex XIII Ready Structure](/artifacts/eu/batteries-regulation/battery-passport-data-model-template.md): Design a battery passport data model for Regulation (EU) 2023/1542 using the Annex XIII access tiers for public model data, legitimate interest data. - [Battery Passport Implementation | Article 77 and Article 78 Guide](/artifacts/eu/batteries-regulation/battery-passport-implementation.md): Implement the EU battery passport for LMT batteries, industrial batteries above 2 kWh, and EV batteries with a compliant QR resolver, Annex XIII data model. - [Battery Recycled Content and Recovery Targets | Article 8 and Annex XII Guide](/artifacts/eu/batteries-regulation/recycled-content-and-recovery-targets.md): Understand the recycled content roadmap in Article 8 and the recycling efficiency and material recovery targets in Annex XII. - [EU Batteries Regulation Applicability Test | Category, Scope, and Obligation Routing](/artifacts/eu/batteries-regulation/applicability-test.md): Run a grounded applicability test for Regulation (EU) 2023/1542 by checking whether the battery is portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Battery Categories and Scope | Portable, LMT, SLI, Industrial, EV](/artifacts/eu/batteries-regulation/battery-categories-and-scope.md): Use the legal category definitions in Regulation (EU) 2023/1542 to classify batteries as portable, LMT, SLI, industrial, or EV. - [EU Batteries Regulation Checklist | Practical Compliance Checklist by Battery Category](/artifacts/eu/batteries-regulation/checklist.md): Use a detailed checklist for Regulation (EU) 2023/1542 covering battery classification, labeling, QR, battery passport, carbon footprint declarations. - [EU Batteries Regulation Compliance Program | Build an Operational Batteries Program](/artifacts/eu/batteries-regulation/compliance.md): Build a practical compliance program for Regulation (EU) 2023/1542 covering battery classification, technical documentation, carbon footprint declarations. - [EU Batteries Regulation Deadlines and Compliance Calendar | Exact Dates and Workplan](/artifacts/eu/batteries-regulation/deadlines-and-compliance-calendar.md): Track the exact dates in Regulation (EU) 2023/1542, including application from 18 February 2024, Article 14 and Chapter VI timing from 18 August 2024. - [EU Batteries Regulation FAQ | Dates, Categories, Passport, Due Diligence, and Waste Duties](/artifacts/eu/batteries-regulation/faq.md): Get grounded answers to common questions on Regulation (EU) 2023/1542, including the main application date, when battery passport starts. - [EU Batteries Regulation Penalties and Enforcement | Article 93 Guide](/artifacts/eu/batteries-regulation/penalties-and-fines.md): Understand the penalty and enforcement structure in Regulation (EU) 2023/1542. - [EU Batteries Regulation vs ESPR | Battery Passport vs Digital Product Passport](/artifacts/eu/batteries-regulation/batteries-regulation-vs-espr.md): Compare the battery passport in Regulation (EU) 2023/1542 with the broader ESPR Digital Product Passport model. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/batteries-regulation/requirements --- --- title: "EU CSDDD Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/csddd/applicability-test" author: "Sorena AI" description: "Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules." keywords: - "EU CSDDD applicability test" - "CSDDD scope threshold" - "Directive (EU) 2024/1760 scope" - "CSDDD 1000 employees 450 million" - "CSDDD non-EU company scope" - "CSDDD franchising licensing royalties" - "CSDDD start date 2028 2029" - "EU CSDDD" - "Applicability test" - "Thresholds" - "CS3D" - "Scope" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Applicability Test Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. *EU CSDDD* *Scope Test* ## EU CSDDD (Directive (EU) 2024/1760) Applicability test A decision ready scope test for legal, finance, ESG, and procurement teams. Use one memo to lock thresholds, group structure, non-EU nexus, and the right application wave before you launch implementation. The first CSDDD control is a defensible scope position. You need a record that explains which entity is in scope, why the thresholds are met or not met, whether a group parent can perform duties on behalf of subsidiaries, and when the obligation starts under the amended Article 37 timing. ## Step 1: test the main EU company threshold Article 2 brings EU formed companies into scope when they had more than 1000 employees on average and net worldwide turnover above EUR 450 million in the last financial year for which annual financial statements have been or should have been adopted. Do not treat this as a one line finance check. Preserve the employee methodology, the turnover source, and the legal entity perimeter used for the decision because supervisory questions usually start there. - Keep the average employee calculation and the period used. - Retain the annual financial statements and the turnover reconciliation used for the test. - Record whether the entity is an operating company or an ultimate parent company. ## Step 2: test the franchising and licensing route separately The Directive also captures companies and groups that operate through franchising or licensing models in return for royalties where the agreements create a common identity, a common business concept, and uniform business methods. That route applies when royalties are above EUR 22.5 million and turnover is above EUR 80 million. This catches models that may miss the general threshold but still exert strong control over how the network operates. - Royalty trigger: more than EUR 22.5 million. - Turnover trigger: more than EUR 80 million. - Document the contracts, royalty calculations, and network model used for the analysis. ## Step 3: test non-EU companies with EU turnover Third-country companies come into scope based on net turnover generated in the Union rather than employee count. The main threshold is more than EUR 450 million in Union turnover in the financial year preceding the last financial year. Where the non-EU company operates in a Member State, Article 23 also requires an authorized representative established or domiciled in a Member State where the company operates. - No employee threshold applies to third-country companies for the scope test. - Keep the Union turnover calculation and the Member State allocation logic. - Prepare authorized representative details early if the company is in scope. ## Step 4: decide who performs the duties in a group The Directive allows parent companies to fulfil Articles 7 to 11 and Article 22 on behalf of in-scope subsidiaries if this ensures effective compliance. That does not eliminate the subsidiary from the enforcement map or from civil liability exposure where the conditions are met. An ultimate parent that mainly holds shares and does not take management, operational, or financial decisions may be exempted, but only if a Union established operational subsidiary is designated and given the means and legal authority to perform the duties. - Write down whether duties are handled centrally or entity by entity. - Document the designated subsidiary arrangement if a holding parent relies on the exemption route. - Do not confuse group performance of duties with immunity from subsidiary supervision or civil liability. ## Step 5: assign the right application wave Directive (EU) 2025/794 changed the original rollout. Member States now transpose by 26 July 2027. The first wave applies from 26 July 2028 for the largest companies, and broader application follows from 26 July 2029. Use the amended timing, not outdated 2026 and 2027 summaries. If your internal roadmap still assumes the original first wave, it is already wrong. - 26 July 2028: EU companies with more than 5000 employees and more than EUR 1.5 billion turnover, and non-EU companies with more than EUR 1.5 billion Union turnover. - 26 July 2029: all other in-scope companies, including the EUR 450 million threshold cohort and qualifying franchising or licensing groups. - Record the exact article basis for the chosen wave in the scoping memo. *Recommended next step* *Placement: after the applicability result* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Applicability test across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Applicability test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Applicability test](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Applicability test and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Applicability test. ## Primary sources - [Directive (EU) 2024/1760 - Official Journal](https://eur-lex.europa.eu/eli/dir/2024/1760/oj/eng?ref=sorena.io) - Primary legal text for Articles 2 to 29, the Annex, and the original implementation architecture. - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. ## Related Topic Guides - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/applicability-test --- --- title: "EU CSDDD Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/csddd/applicability-test" author: "Sorena AI" description: "Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules." keywords: - "EU CSDDD applicability test" - "CSDDD scope threshold" - "Directive (EU) 2024/1760 scope" - "CSDDD 1000 employees 450 million" - "CSDDD non-EU company scope" - "CSDDD franchising licensing royalties" - "CSDDD start date 2028 2029" - "EU CSDDD" - "Applicability test" - "Thresholds" - "CS3D" - "Scope" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Applicability Test Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. *EU CSDDD* *Scope Test* ## EU CSDDD (Directive (EU) 2024/1760) Applicability test A decision ready scope test for legal, finance, ESG, and procurement teams. Use one memo to lock thresholds, group structure, non-EU nexus, and the right application wave before you launch implementation. The first CSDDD control is a defensible scope position. You need a record that explains which entity is in scope, why the thresholds are met or not met, whether a group parent can perform duties on behalf of subsidiaries, and when the obligation starts under the amended Article 37 timing. ## Step 1: test the main EU company threshold Article 2 brings EU formed companies into scope when they had more than 1000 employees on average and net worldwide turnover above EUR 450 million in the last financial year for which annual financial statements have been or should have been adopted. Do not treat this as a one line finance check. Preserve the employee methodology, the turnover source, and the legal entity perimeter used for the decision because supervisory questions usually start there. - Keep the average employee calculation and the period used. - Retain the annual financial statements and the turnover reconciliation used for the test. - Record whether the entity is an operating company or an ultimate parent company. ## Step 2: test the franchising and licensing route separately The Directive also captures companies and groups that operate through franchising or licensing models in return for royalties where the agreements create a common identity, a common business concept, and uniform business methods. That route applies when royalties are above EUR 22.5 million and turnover is above EUR 80 million. This catches models that may miss the general threshold but still exert strong control over how the network operates. - Royalty trigger: more than EUR 22.5 million. - Turnover trigger: more than EUR 80 million. - Document the contracts, royalty calculations, and network model used for the analysis. ## Step 3: test non-EU companies with EU turnover Third-country companies come into scope based on net turnover generated in the Union rather than employee count. The main threshold is more than EUR 450 million in Union turnover in the financial year preceding the last financial year. Where the non-EU company operates in a Member State, Article 23 also requires an authorized representative established or domiciled in a Member State where the company operates. - No employee threshold applies to third-country companies for the scope test. - Keep the Union turnover calculation and the Member State allocation logic. - Prepare authorized representative details early if the company is in scope. ## Step 4: decide who performs the duties in a group The Directive allows parent companies to fulfil Articles 7 to 11 and Article 22 on behalf of in-scope subsidiaries if this ensures effective compliance. That does not eliminate the subsidiary from the enforcement map or from civil liability exposure where the conditions are met. An ultimate parent that mainly holds shares and does not take management, operational, or financial decisions may be exempted, but only if a Union established operational subsidiary is designated and given the means and legal authority to perform the duties. - Write down whether duties are handled centrally or entity by entity. - Document the designated subsidiary arrangement if a holding parent relies on the exemption route. - Do not confuse group performance of duties with immunity from subsidiary supervision or civil liability. ## Step 5: assign the right application wave Directive (EU) 2025/794 changed the original rollout. Member States now transpose by 26 July 2027. The first wave applies from 26 July 2028 for the largest companies, and broader application follows from 26 July 2029. Use the amended timing, not outdated 2026 and 2027 summaries. If your internal roadmap still assumes the original first wave, it is already wrong. - 26 July 2028: EU companies with more than 5000 employees and more than EUR 1.5 billion turnover, and non-EU companies with more than EUR 1.5 billion Union turnover. - 26 July 2029: all other in-scope companies, including the EUR 450 million threshold cohort and qualifying franchising or licensing groups. - Record the exact article basis for the chosen wave in the scoping memo. *Recommended next step* *Placement: after the applicability result* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Applicability test across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Applicability test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Applicability test](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Applicability test and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Applicability test. ## Primary sources - [Directive (EU) 2024/1760 - Official Journal](https://eur-lex.europa.eu/eli/dir/2024/1760/oj/eng?ref=sorena.io) - Primary legal text for Articles 2 to 29, the Annex, and the original implementation architecture. - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. ## Related Topic Guides - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/applicability-test --- --- title: "EU CSDDD Chain of Activities and Supplier Scope" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/chain-of-activities-and-suppliers" source_url: "https://www.sorena.io/artifacts/eu/csddd/chain-of-activities-and-suppliers" author: "Sorena AI" description: "Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners." keywords: - "EU CSDDD chain of activities" - "CSDDD upstream downstream" - "CSDDD direct and indirect business partners" - "CSDDD supplier scope" - "CSDDD disposal exclusion" - "CSDDD financial undertaking downstream exclusion" - "EU CSDDD" - "Chain of activities" - "Suppliers" - "Business partners" - "Scope" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Chain of Activities and Supplier Scope Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. *EU CSDDD* *Scope Boundary* ## EU CSDDD (Directive (EU) 2024/1760) Chain of activities and supplier scope This is the page to use when internal teams argue about what the Directive actually covers. Get the perimeter right first. Otherwise your mapping, supplier questionnaires, complaint routes, and corrective actions will all be inconsistent. The Directive does not cover every commercial relationship. It uses the defined term chain of activities, and that perimeter has sharp boundaries. A good implementation separates what is legally inside the chain from what may still be relevant as business risk but is outside the due diligence duty in Directive terms. ## Upstream coverage: more than tier one and more than sourcing only Upstream chain-of-activities coverage includes activities of business partners related to the production of goods or provision of services by the company. The recitals and Article 3 definition point to design, extraction, sourcing, manufacture, transport, storage, supply of raw materials, products or parts, and development of the product or service. That is why a weak mapping limited to direct suppliers is not enough. The legal question is not whether the partner signs your contract, but whether the activity is connected to the company product or service in the covered part of the chain. - Include direct and indirect business partners where the activity is related to the covered production or service chain. - Capture production design and development steps, not only physical supply. - Use risk based depth so the most severe and likely impacts get more granular analysis. ## Downstream coverage: narrow for products and excluded for service distribution Downstream coverage is much narrower than many teams assume. The Directive covers downstream business partners related to distribution, transport, and storage of the product where those activities are carried out for the company or on its behalf. It does not cover disposal of the product. It also does not include downstream business partners related to the services of the company. That distinction matters for software, platforms, logistics, and service heavy business models. - Product distribution, transport, and storage can be in scope if performed for the company or on its behalf. - Product disposal is outside the chain-of-activities definition. - Downstream services are outside the definition, even if commercially important. ## Direct and indirect business partners: what changes in practice The Directive allows companies to use contractual assurances and verification not only with direct business partners but, in certain situations, with indirect business partners as well. That is one reason the chain map has to distinguish contractual reach from factual risk exposure. A practical operating model keeps one partner register with fields for direct versus indirect, activity type, product or service link, geography, sector, leverage level, and current risk score. - Tag each partner as direct or indirect, but do not stop the analysis there. - Record the activity performed and why it falls inside or outside the chain definition. - Use the same register for prioritization, corrective action plans, and complaints intake routing. ## Special rule for regulated financial undertakings For regulated financial undertakings, the downstream part of the chain is carved back even further. The definition does not include downstream business partners that receive their services and products. That means financial institutions still need upstream analysis, but the customer side is not pulled into the Directive through a generic downstream concept. - Do not copy a manufacturing perimeter into a regulated financial undertaking without checking this rule. - Explain the upstream only downstream treatment in the scope memo. - Coordinate the legal perimeter with any broader voluntary ESG or sector risk work so teams know which controls are legally required and which are discretionary. ## Boundary decisions that should be written down Every CSDDD program should maintain a boundary log. This is where you explain why a distributor, warehouse, licensee, platform operator, service reseller, recycler, or logistics partner was treated as inside or outside the chain of activities. That log becomes critical when complaints arrive, when a supervisory authority asks why a partner was not prioritized, or when legal teams need to defend the scope of an investigation. - Create one boundary memo per material business model or product family. - Cross reference the boundary memo to supplier questionnaires, contract clauses, and grievance channels. - Review the log whenever the business model, product route, or distribution structure changes. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Chain of activities and supplier scope across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Chain of activities and supplier scope from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Chain of activities and supplier scope](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Chain of activities and supplier scope and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Chain of activities and supplier scope. ## Primary sources - [Directive (EU) 2024/1760 - Official Journal](https://eur-lex.europa.eu/eli/dir/2024/1760/oj/eng?ref=sorena.io) - Primary legal text for Articles 2 to 29, the Annex, and the original implementation architecture. - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [OECD Due Diligence Guidance for Responsible Business Conduct](https://www.oecd.org/content/dam/oecd/en/publications/reports/2018/05/oecd-due-diligence-guidance-for-responsible-business-conduct_81f92357/81f92357-en.pdf?ref=sorena.io) - Useful operating model reference because the Directive is built around risk based due diligence. - [UN Guiding Principles on Business and Human Rights](https://www.ohchr.org/sites/default/files/documents/publications/guidingprinciplesbusinesshr_en.pdf?ref=sorena.io) - Reference point for complaints design, remedy logic, and legitimate stakeholder engagement. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/chain-of-activities-and-suppliers --- --- title: "EU CSDDD Chain of Activities and Supplier Scope" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/chain-of-activities-and-suppliers" source_url: "https://www.sorena.io/artifacts/eu/csddd/chain-of-activities-and-suppliers" author: "Sorena AI" description: "Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners." keywords: - "EU CSDDD chain of activities" - "CSDDD upstream downstream" - "CSDDD direct and indirect business partners" - "CSDDD supplier scope" - "CSDDD disposal exclusion" - "CSDDD financial undertaking downstream exclusion" - "EU CSDDD" - "Chain of activities" - "Suppliers" - "Business partners" - "Scope" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Chain of Activities and Supplier Scope Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. *EU CSDDD* *Scope Boundary* ## EU CSDDD (Directive (EU) 2024/1760) Chain of activities and supplier scope This is the page to use when internal teams argue about what the Directive actually covers. Get the perimeter right first. Otherwise your mapping, supplier questionnaires, complaint routes, and corrective actions will all be inconsistent. The Directive does not cover every commercial relationship. It uses the defined term chain of activities, and that perimeter has sharp boundaries. A good implementation separates what is legally inside the chain from what may still be relevant as business risk but is outside the due diligence duty in Directive terms. ## Upstream coverage: more than tier one and more than sourcing only Upstream chain-of-activities coverage includes activities of business partners related to the production of goods or provision of services by the company. The recitals and Article 3 definition point to design, extraction, sourcing, manufacture, transport, storage, supply of raw materials, products or parts, and development of the product or service. That is why a weak mapping limited to direct suppliers is not enough. The legal question is not whether the partner signs your contract, but whether the activity is connected to the company product or service in the covered part of the chain. - Include direct and indirect business partners where the activity is related to the covered production or service chain. - Capture production design and development steps, not only physical supply. - Use risk based depth so the most severe and likely impacts get more granular analysis. ## Downstream coverage: narrow for products and excluded for service distribution Downstream coverage is much narrower than many teams assume. The Directive covers downstream business partners related to distribution, transport, and storage of the product where those activities are carried out for the company or on its behalf. It does not cover disposal of the product. It also does not include downstream business partners related to the services of the company. That distinction matters for software, platforms, logistics, and service heavy business models. - Product distribution, transport, and storage can be in scope if performed for the company or on its behalf. - Product disposal is outside the chain-of-activities definition. - Downstream services are outside the definition, even if commercially important. ## Direct and indirect business partners: what changes in practice The Directive allows companies to use contractual assurances and verification not only with direct business partners but, in certain situations, with indirect business partners as well. That is one reason the chain map has to distinguish contractual reach from factual risk exposure. A practical operating model keeps one partner register with fields for direct versus indirect, activity type, product or service link, geography, sector, leverage level, and current risk score. - Tag each partner as direct or indirect, but do not stop the analysis there. - Record the activity performed and why it falls inside or outside the chain definition. - Use the same register for prioritization, corrective action plans, and complaints intake routing. ## Special rule for regulated financial undertakings For regulated financial undertakings, the downstream part of the chain is carved back even further. The definition does not include downstream business partners that receive their services and products. That means financial institutions still need upstream analysis, but the customer side is not pulled into the Directive through a generic downstream concept. - Do not copy a manufacturing perimeter into a regulated financial undertaking without checking this rule. - Explain the upstream only downstream treatment in the scope memo. - Coordinate the legal perimeter with any broader voluntary ESG or sector risk work so teams know which controls are legally required and which are discretionary. ## Boundary decisions that should be written down Every CSDDD program should maintain a boundary log. This is where you explain why a distributor, warehouse, licensee, platform operator, service reseller, recycler, or logistics partner was treated as inside or outside the chain of activities. That log becomes critical when complaints arrive, when a supervisory authority asks why a partner was not prioritized, or when legal teams need to defend the scope of an investigation. - Create one boundary memo per material business model or product family. - Cross reference the boundary memo to supplier questionnaires, contract clauses, and grievance channels. - Review the log whenever the business model, product route, or distribution structure changes. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Chain of activities and supplier scope across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Chain of activities and supplier scope from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Chain of activities and supplier scope](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Chain of activities and supplier scope and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Chain of activities and supplier scope. ## Primary sources - [Directive (EU) 2024/1760 - Official Journal](https://eur-lex.europa.eu/eli/dir/2024/1760/oj/eng?ref=sorena.io) - Primary legal text for Articles 2 to 29, the Annex, and the original implementation architecture. - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [OECD Due Diligence Guidance for Responsible Business Conduct](https://www.oecd.org/content/dam/oecd/en/publications/reports/2018/05/oecd-due-diligence-guidance-for-responsible-business-conduct_81f92357/81f92357-en.pdf?ref=sorena.io) - Useful operating model reference because the Directive is built around risk based due diligence. - [UN Guiding Principles on Business and Human Rights](https://www.ohchr.org/sites/default/files/documents/publications/guidingprinciplesbusinesshr_en.pdf?ref=sorena.io) - Reference point for complaints design, remedy logic, and legitimate stakeholder engagement. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/chain-of-activities-and-suppliers --- --- title: "EU CSDDD Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/checklist" source_url: "https://www.sorena.io/artifacts/eu/csddd/checklist" author: "Sorena AI" description: "Use this CSDDD checklist to move from scope to execution." keywords: - "EU CSDDD checklist" - "CSDDD implementation checklist" - "CSDDD compliance checklist" - "CSDDD due diligence program" - "CSDDD annual statement checklist" - "CSDDD climate transition plan checklist" - "EU CSDDD" - "Checklist" - "Due diligence" - "Compliance" - "Implementation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Checklist Use this CSDDD checklist to move from scope to execution. *EU CSDDD* *Checklist* ## EU CSDDD (Directive (EU) 2024/1760) Implementation checklist A checklist built for execution, not for slideware. Use it to assign owners, set evidence standards, and see quickly where your program is still weak. A good CSDDD checklist is not just a list of articles. It is a list of outputs. Each item below should exist as a controlled artifact, have a named owner, and be linked to the chain-of-activities register and the current scope memo. ## Checklist track 1: scope, governance, and ownership Confirm whether the relevant entity or group is in scope, document the application wave, and assign accountable owners across legal, procurement, ESG, compliance, and risk functions. If a parent performs duties on behalf of subsidiaries, write down how that works, what data subsidiaries must provide, and which subsidiary remains exposed to local supervision and civil liability risk. - Scope memo approved and version controlled. - RACI for Articles 7 to 16 and Article 22. - Boundary log for chain-of-activities decisions. *Recommended next step* *Placement: after the checklist block* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Implementation checklist across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Implementation checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Implementation checklist](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Implementation checklist and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Implementation checklist. ## Checklist track 2: Article 7 to 9 foundation Create the due diligence policy, code of conduct, mapping methodology, and prioritization method before you ask suppliers for more data. These articles set the logic that later actions must follow. The prioritization model should record severity and likelihood, and should explain how company, geographic, sector, product, and purchasing-practice risk factors are assessed. - Due diligence policy updated at least every 24 months and after significant change. - Mapping of operations, subsidiaries, and business partners completed for high risk areas. - Prioritization register and documented scoring method in place. ## Checklist track 3: prevention, corrective action, and remediation For potential impacts, maintain prevention action plans, contractual assurances, verification methods, and escalation routes. For actual impacts, maintain corrective action plans and clear criteria for when suspension or termination is considered. Where the company caused or jointly caused an actual adverse impact, make sure remediation workflows can restore or compensate affected persons, communities, or the environment proportionately to the company implication. - Prevention and corrective action plan templates approved. - Responsible disengagement analysis template available. - Remediation governance and funding path documented. ## Checklist track 4: stakeholders, complaints, and monitoring Set up stakeholder engagement points across mapping, prioritization, action planning, remediation, and monitoring. Complaints need to be fair, publicly available, accessible, predictable, and transparent. Monitoring must happen at least every 12 months and after significant change. Keep the indicators, reviews, and management decisions in one place. - Complaint and notification channels live and published. - Stakeholder engagement log and anti-retaliation controls in place. - Annual and trigger based monitoring reviews scheduled. ## Checklist track 5: communication, climate plan, and enforcement readiness If the annual statement under Article 16 applies, set up data collection, approval, publication, and later ESAP submission processes. If CSRD reporting already covers the company, confirm the annual statement exemption but still keep the underlying due diligence evidence. For Article 22, adopt and put into effect a transition plan with 2030 and five-year targets to 2050, investment assumptions, key actions, and governance roles. Also prepare for supervisory requests, substantiated concerns, penalties, and civil liability disputes. - Annual statement process or documented CSRD exemption position in place. - Article 22 climate transition plan adopted, updated, and linked to implementation actions. - Supervisory response pack, document retention standard, and litigation hold logic prepared. ## Primary sources - [Directive (EU) 2024/1760 - Official Journal](https://eur-lex.europa.eu/eli/dir/2024/1760/oj/eng?ref=sorena.io) - Primary legal text for Articles 2 to 29, the Annex, and the original implementation architecture. - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. - [OECD Due Diligence Guidance for Responsible Business Conduct](https://www.oecd.org/content/dam/oecd/en/publications/reports/2018/05/oecd-due-diligence-guidance-for-responsible-business-conduct_81f92357/81f92357-en.pdf?ref=sorena.io) - Useful operating model reference because the Directive is built around risk based due diligence. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/checklist --- --- title: "EU CSDDD Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/checklist" source_url: "https://www.sorena.io/artifacts/eu/csddd/checklist" author: "Sorena AI" description: "Use this CSDDD checklist to move from scope to execution." keywords: - "EU CSDDD checklist" - "CSDDD implementation checklist" - "CSDDD compliance checklist" - "CSDDD due diligence program" - "CSDDD annual statement checklist" - "CSDDD climate transition plan checklist" - "EU CSDDD" - "Checklist" - "Due diligence" - "Compliance" - "Implementation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Checklist Use this CSDDD checklist to move from scope to execution. *EU CSDDD* *Checklist* ## EU CSDDD (Directive (EU) 2024/1760) Implementation checklist A checklist built for execution, not for slideware. Use it to assign owners, set evidence standards, and see quickly where your program is still weak. A good CSDDD checklist is not just a list of articles. It is a list of outputs. Each item below should exist as a controlled artifact, have a named owner, and be linked to the chain-of-activities register and the current scope memo. ## Checklist track 1: scope, governance, and ownership Confirm whether the relevant entity or group is in scope, document the application wave, and assign accountable owners across legal, procurement, ESG, compliance, and risk functions. If a parent performs duties on behalf of subsidiaries, write down how that works, what data subsidiaries must provide, and which subsidiary remains exposed to local supervision and civil liability risk. - Scope memo approved and version controlled. - RACI for Articles 7 to 16 and Article 22. - Boundary log for chain-of-activities decisions. *Recommended next step* *Placement: after the checklist block* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Implementation checklist across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Implementation checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Implementation checklist](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Implementation checklist and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Implementation checklist. ## Checklist track 2: Article 7 to 9 foundation Create the due diligence policy, code of conduct, mapping methodology, and prioritization method before you ask suppliers for more data. These articles set the logic that later actions must follow. The prioritization model should record severity and likelihood, and should explain how company, geographic, sector, product, and purchasing-practice risk factors are assessed. - Due diligence policy updated at least every 24 months and after significant change. - Mapping of operations, subsidiaries, and business partners completed for high risk areas. - Prioritization register and documented scoring method in place. ## Checklist track 3: prevention, corrective action, and remediation For potential impacts, maintain prevention action plans, contractual assurances, verification methods, and escalation routes. For actual impacts, maintain corrective action plans and clear criteria for when suspension or termination is considered. Where the company caused or jointly caused an actual adverse impact, make sure remediation workflows can restore or compensate affected persons, communities, or the environment proportionately to the company implication. - Prevention and corrective action plan templates approved. - Responsible disengagement analysis template available. - Remediation governance and funding path documented. ## Checklist track 4: stakeholders, complaints, and monitoring Set up stakeholder engagement points across mapping, prioritization, action planning, remediation, and monitoring. Complaints need to be fair, publicly available, accessible, predictable, and transparent. Monitoring must happen at least every 12 months and after significant change. Keep the indicators, reviews, and management decisions in one place. - Complaint and notification channels live and published. - Stakeholder engagement log and anti-retaliation controls in place. - Annual and trigger based monitoring reviews scheduled. ## Checklist track 5: communication, climate plan, and enforcement readiness If the annual statement under Article 16 applies, set up data collection, approval, publication, and later ESAP submission processes. If CSRD reporting already covers the company, confirm the annual statement exemption but still keep the underlying due diligence evidence. For Article 22, adopt and put into effect a transition plan with 2030 and five-year targets to 2050, investment assumptions, key actions, and governance roles. Also prepare for supervisory requests, substantiated concerns, penalties, and civil liability disputes. - Annual statement process or documented CSRD exemption position in place. - Article 22 climate transition plan adopted, updated, and linked to implementation actions. - Supervisory response pack, document retention standard, and litigation hold logic prepared. ## Primary sources - [Directive (EU) 2024/1760 - Official Journal](https://eur-lex.europa.eu/eli/dir/2024/1760/oj/eng?ref=sorena.io) - Primary legal text for Articles 2 to 29, the Annex, and the original implementation architecture. - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. - [OECD Due Diligence Guidance for Responsible Business Conduct](https://www.oecd.org/content/dam/oecd/en/publications/reports/2018/05/oecd-due-diligence-guidance-for-responsible-business-conduct_81f92357/81f92357-en.pdf?ref=sorena.io) - Useful operating model reference because the Directive is built around risk based due diligence. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/checklist --- --- title: "EU CSDDD Climate Transition Plan" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/climate-transition-plan" source_url: "https://www.sorena.io/artifacts/eu/csddd/climate-transition-plan" author: "Sorena AI" description: "Understand the Article 22 climate transition plan duty under the CSDDD." keywords: - "EU CSDDD climate transition plan" - "Article 22 CSDDD" - "CSDDD 1.5 C plan" - "CSDDD climate targets 2030 2050" - "CSDDD scope 1 scope 2 scope 3" - "CSDDD best efforts climate plan" - "EU CSDDD" - "Climate transition plan" - "Article 22" - "1.5 C" - "Governance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Climate Transition Plan Understand the Article 22 climate transition plan duty under the CSDDD. *EU CSDDD* *Article 22* ## EU CSDDD (Directive (EU) 2024/1760) Climate transition plan Article 22 is a governance and implementation duty, not just a narrative climate statement. Use this page to structure a plan that supervisory authorities can read and management can actually operate. Article 22 requires in-scope companies to adopt and put into effect a climate transition plan aimed, through best efforts, at making the business model and strategy compatible with the transition to a sustainable economy and with limiting global warming to 1.5 C in line with the Paris Agreement and the European Climate Law targets. ## What Article 22 actually requires The Directive does not ask for a generic sustainability statement. It asks for a transition plan with explicit climate direction and implementation substance. The plan must also address exposure to coal, oil, and gas related activities where relevant. The duty is framed as an obligation of means, not a guaranteed result. That matters because the plan has to be credible, current, evidence based, and put into effect, even if market conditions or technology constraints later change what is reasonably achievable. - Aim: compatibility with 1.5 C and climate neutrality objectives. - Approach: best efforts, with operational follow through. - Scope: business model, strategy, and relevant fossil exposure. ## Required plan elements Article 22 requires time bound climate targets for 2030 and in five year steps up to 2050 based on conclusive scientific evidence. Where appropriate, the plan should include absolute emission reduction targets for scope 1, scope 2, and scope 3 emissions for each significant category. The plan also needs implementation actions, an explanation and quantification of the investments and funding that support the plan, and a description of the role of the administrative, management, and supervisory bodies. - Targets: 2030 plus five year steps to 2050. - Coverage: scope 1, 2, and 3 where appropriate. - Support: actions, investments, funding, and governance roles. ## How to make the plan usable in practice A good Article 22 plan ties each target to operational levers such as supplier changes, product redesign, sourcing shifts, energy decisions, logistics choices, and capital allocation. Without this link, the plan reads well but does not change conduct. Use one implementation table that ties each material target to owner, deadline, funding assumption, dependency, and KPI. That makes updates and board review much easier. - Link every target to an action owner and a measurable implementation step. - Cross reference the plan to procurement and product decisions where scope 3 is material. - Keep the assumptions used for scientific alignment and funding choices. ## Interaction with CSRD reporting Companies that report a climate transition plan under the CSRD are deemed to have complied with the obligation to adopt a plan under Article 22. That deeming rule does not remove the duty to put the plan into effect and to update it every 12 months with progress information. If a subsidiary is included in the parent undertaking plan reported under the CSRD, that subsidiary can also be deemed to have complied with the adoption obligation, but implementation still has to reflect the subsidiary business model and strategy. - CSRD can satisfy the adoption step, not the implementation burden. - Annual updates remain necessary. - Subsidiaries should show how the group plan translates into local execution. ## What supervisory authorities will care about Supervisory authorities must at least supervise adoption and design of the plan and its updates. That means they will look for whether the plan has the required elements, whether it is current, and whether it appears connected to the actual business model. The fastest way to create risk here is to publish a climate plan in one channel and run procurement, investment, and product decisions in a different direction. - Check consistency between the plan, governance minutes, and budget decisions. - Retain the evidence supporting target choice and annual progress updates. - Use a review calendar that aligns legal, sustainability, finance, and board reporting cycles. *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Climate transition plan across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Climate transition plan from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Climate transition plan](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Climate transition plan and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Climate transition plan. ## Primary sources - [Directive (EU) 2024/1760 - Official Journal](https://eur-lex.europa.eu/eli/dir/2024/1760/oj/eng?ref=sorena.io) - Primary legal text for Articles 2 to 29, the Annex, and the original implementation architecture. - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2022/2464 - CSRD](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal source for the sustainability reporting regime that overlaps with CSDDD annual statement mechanics. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/climate-transition-plan --- --- title: "EU CSDDD Climate Transition Plan" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/climate-transition-plan" source_url: "https://www.sorena.io/artifacts/eu/csddd/climate-transition-plan" author: "Sorena AI" description: "Understand the Article 22 climate transition plan duty under the CSDDD." keywords: - "EU CSDDD climate transition plan" - "Article 22 CSDDD" - "CSDDD 1.5 C plan" - "CSDDD climate targets 2030 2050" - "CSDDD scope 1 scope 2 scope 3" - "CSDDD best efforts climate plan" - "EU CSDDD" - "Climate transition plan" - "Article 22" - "1.5 C" - "Governance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Climate Transition Plan Understand the Article 22 climate transition plan duty under the CSDDD. *EU CSDDD* *Article 22* ## EU CSDDD (Directive (EU) 2024/1760) Climate transition plan Article 22 is a governance and implementation duty, not just a narrative climate statement. Use this page to structure a plan that supervisory authorities can read and management can actually operate. Article 22 requires in-scope companies to adopt and put into effect a climate transition plan aimed, through best efforts, at making the business model and strategy compatible with the transition to a sustainable economy and with limiting global warming to 1.5 C in line with the Paris Agreement and the European Climate Law targets. ## What Article 22 actually requires The Directive does not ask for a generic sustainability statement. It asks for a transition plan with explicit climate direction and implementation substance. The plan must also address exposure to coal, oil, and gas related activities where relevant. The duty is framed as an obligation of means, not a guaranteed result. That matters because the plan has to be credible, current, evidence based, and put into effect, even if market conditions or technology constraints later change what is reasonably achievable. - Aim: compatibility with 1.5 C and climate neutrality objectives. - Approach: best efforts, with operational follow through. - Scope: business model, strategy, and relevant fossil exposure. ## Required plan elements Article 22 requires time bound climate targets for 2030 and in five year steps up to 2050 based on conclusive scientific evidence. Where appropriate, the plan should include absolute emission reduction targets for scope 1, scope 2, and scope 3 emissions for each significant category. The plan also needs implementation actions, an explanation and quantification of the investments and funding that support the plan, and a description of the role of the administrative, management, and supervisory bodies. - Targets: 2030 plus five year steps to 2050. - Coverage: scope 1, 2, and 3 where appropriate. - Support: actions, investments, funding, and governance roles. ## How to make the plan usable in practice A good Article 22 plan ties each target to operational levers such as supplier changes, product redesign, sourcing shifts, energy decisions, logistics choices, and capital allocation. Without this link, the plan reads well but does not change conduct. Use one implementation table that ties each material target to owner, deadline, funding assumption, dependency, and KPI. That makes updates and board review much easier. - Link every target to an action owner and a measurable implementation step. - Cross reference the plan to procurement and product decisions where scope 3 is material. - Keep the assumptions used for scientific alignment and funding choices. ## Interaction with CSRD reporting Companies that report a climate transition plan under the CSRD are deemed to have complied with the obligation to adopt a plan under Article 22. That deeming rule does not remove the duty to put the plan into effect and to update it every 12 months with progress information. If a subsidiary is included in the parent undertaking plan reported under the CSRD, that subsidiary can also be deemed to have complied with the adoption obligation, but implementation still has to reflect the subsidiary business model and strategy. - CSRD can satisfy the adoption step, not the implementation burden. - Annual updates remain necessary. - Subsidiaries should show how the group plan translates into local execution. ## What supervisory authorities will care about Supervisory authorities must at least supervise adoption and design of the plan and its updates. That means they will look for whether the plan has the required elements, whether it is current, and whether it appears connected to the actual business model. The fastest way to create risk here is to publish a climate plan in one channel and run procurement, investment, and product decisions in a different direction. - Check consistency between the plan, governance minutes, and budget decisions. - Retain the evidence supporting target choice and annual progress updates. - Use a review calendar that aligns legal, sustainability, finance, and board reporting cycles. *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Climate transition plan across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Climate transition plan from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Climate transition plan](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Climate transition plan and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Climate transition plan. ## Primary sources - [Directive (EU) 2024/1760 - Official Journal](https://eur-lex.europa.eu/eli/dir/2024/1760/oj/eng?ref=sorena.io) - Primary legal text for Articles 2 to 29, the Annex, and the original implementation architecture. - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2022/2464 - CSRD](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal source for the sustainability reporting regime that overlaps with CSDDD annual statement mechanics. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/climate-transition-plan --- --- title: "EU CSDDD Compliance Guide" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/compliance" source_url: "https://www.sorena.io/artifacts/eu/csddd/compliance" author: "Sorena AI" description: "Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping." keywords: - "EU CSDDD compliance" - "CSDDD operating model" - "CSDDD implementation guide" - "CSDDD evidence" - "CSDDD due diligence program" - "CSDDD readiness" - "EU CSDDD" - "Compliance" - "Operating model" - "Evidence" - "Readiness" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Compliance Guide Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. *EU CSDDD* *Compliance* ## EU CSDDD (Directive (EU) 2024/1760) Compliance guide This page shows what compliance should look like after the legal summary ends. Use it to align legal interpretation with supplier operations, stakeholder engagement, and evidence design. CSDDD compliance is a management system problem. The Directive asks companies to integrate due diligence into policies and risk management, use a risk based method, take appropriate prevention and corrective measures, enable complaints, provide remediation where required, monitor effectiveness, communicate annually, and maintain a climate transition plan. Those duties only work if the program is designed as one connected system. ## Program layer 1: governance and policy Start with scope, ownership, and the Article 7 due diligence policy. The policy should connect code of conduct expectations, implementation processes, and verification logic. It should also fit the real group structure rather than an idealized organization chart. Board or equivalent oversight should be visible in minutes, delegations, and reporting packs. If nobody can show where difficult tradeoffs are decided, the program is not mature enough. - Approved scope memo and ownership matrix. - Article 7 policy and code of conduct integrated into the control framework. - Board or committee reporting cadence for material due diligence issues. ## Program layer 2: chain mapping and prioritization Article 8 and Article 9 require companies to identify and assess actual and potential impacts, then prioritize where not all impacts can be addressed at once. This is where the chain-of-activities register and the scoring method become core infrastructure. The program should be able to explain why one geography, site, supplier cluster, or product route was investigated more deeply than another. If the logic is not documented, it will look arbitrary later. - Chain-of-activities register covering operations, subsidiaries, and business partners. - Severity and likelihood scoring linked to company, sector, geography, product, and purchasing practice factors. - Change triggers for mergers, new regions, new products, and major incidents. ## Program layer 3: prevention, correction, and remedy Articles 10 to 12 move the company from analysis to action. Potential impacts need prevention and mitigation. Actual impacts need corrective action and, when the company caused or jointly caused the impact, remediation. This is the part of the program where contract clauses, supplier action plans, leverage strategies, suspension decisions, and remediation funding all need to connect cleanly. - Action plan templates with deadlines, owners, and verification steps. - Responsible disengagement decision framework with manifestly more severe impact assessment. - Remediation workflow with legal, operational, and financial escalation paths. ## Program layer 4: complaints, monitoring, and communication Articles 13 to 17 require meaningful stakeholder engagement, a complaints procedure, periodic monitoring, annual communication, and later ESAP publication mechanics where applicable. These duties are often underbuilt because teams focus only on suppliers. The complaints process must be usable by affected people and organizations, not just by employees with access to a hotline. The annual communication process must be designed before the first reporting cycle, not during it. - Public complaints and notification channels with confidentiality and anti-retaliation safeguards. - At least annual monitoring reviews plus event driven reassessments. - Annual statement workflow or documented CSRD exemption position with supporting evidence. ## Program layer 5: climate and enforcement readiness Article 22 climate planning and Articles 24 to 29 enforcement rules have to be treated as part of compliance, not as separate ESG side projects. Supervisory authorities can investigate, order remedial action, and impose penalties. Civil liability sits beside that regime, not behind it. A mature program keeps a response pack ready with the current scope memo, policy, chain map, prioritization rationale, action plans, complaint logs, monitoring outputs, annual communication files, and climate transition plan updates. - Article 22 plan kept current and tied to implementation actions. - Supervisory response pack maintained and tested. - Litigation hold and document retention rules aligned to complaint and remediation workflows. *Recommended next step* *Placement: after the compliance steps* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Compliance guide across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Compliance guide from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Compliance guide](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Compliance guide and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Compliance guide. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. - [OECD Due Diligence Guidance for Responsible Business Conduct](https://www.oecd.org/content/dam/oecd/en/publications/reports/2018/05/oecd-due-diligence-guidance-for-responsible-business-conduct_81f92357/81f92357-en.pdf?ref=sorena.io) - Useful operating model reference because the Directive is built around risk based due diligence. - [UN Guiding Principles on Business and Human Rights](https://www.ohchr.org/sites/default/files/documents/publications/guidingprinciplesbusinesshr_en.pdf?ref=sorena.io) - Reference point for complaints design, remedy logic, and legitimate stakeholder engagement. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/compliance --- --- title: "EU CSDDD Compliance Guide" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/compliance" source_url: "https://www.sorena.io/artifacts/eu/csddd/compliance" author: "Sorena AI" description: "Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping." keywords: - "EU CSDDD compliance" - "CSDDD operating model" - "CSDDD implementation guide" - "CSDDD evidence" - "CSDDD due diligence program" - "CSDDD readiness" - "EU CSDDD" - "Compliance" - "Operating model" - "Evidence" - "Readiness" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Compliance Guide Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. *EU CSDDD* *Compliance* ## EU CSDDD (Directive (EU) 2024/1760) Compliance guide This page shows what compliance should look like after the legal summary ends. Use it to align legal interpretation with supplier operations, stakeholder engagement, and evidence design. CSDDD compliance is a management system problem. The Directive asks companies to integrate due diligence into policies and risk management, use a risk based method, take appropriate prevention and corrective measures, enable complaints, provide remediation where required, monitor effectiveness, communicate annually, and maintain a climate transition plan. Those duties only work if the program is designed as one connected system. ## Program layer 1: governance and policy Start with scope, ownership, and the Article 7 due diligence policy. The policy should connect code of conduct expectations, implementation processes, and verification logic. It should also fit the real group structure rather than an idealized organization chart. Board or equivalent oversight should be visible in minutes, delegations, and reporting packs. If nobody can show where difficult tradeoffs are decided, the program is not mature enough. - Approved scope memo and ownership matrix. - Article 7 policy and code of conduct integrated into the control framework. - Board or committee reporting cadence for material due diligence issues. ## Program layer 2: chain mapping and prioritization Article 8 and Article 9 require companies to identify and assess actual and potential impacts, then prioritize where not all impacts can be addressed at once. This is where the chain-of-activities register and the scoring method become core infrastructure. The program should be able to explain why one geography, site, supplier cluster, or product route was investigated more deeply than another. If the logic is not documented, it will look arbitrary later. - Chain-of-activities register covering operations, subsidiaries, and business partners. - Severity and likelihood scoring linked to company, sector, geography, product, and purchasing practice factors. - Change triggers for mergers, new regions, new products, and major incidents. ## Program layer 3: prevention, correction, and remedy Articles 10 to 12 move the company from analysis to action. Potential impacts need prevention and mitigation. Actual impacts need corrective action and, when the company caused or jointly caused the impact, remediation. This is the part of the program where contract clauses, supplier action plans, leverage strategies, suspension decisions, and remediation funding all need to connect cleanly. - Action plan templates with deadlines, owners, and verification steps. - Responsible disengagement decision framework with manifestly more severe impact assessment. - Remediation workflow with legal, operational, and financial escalation paths. ## Program layer 4: complaints, monitoring, and communication Articles 13 to 17 require meaningful stakeholder engagement, a complaints procedure, periodic monitoring, annual communication, and later ESAP publication mechanics where applicable. These duties are often underbuilt because teams focus only on suppliers. The complaints process must be usable by affected people and organizations, not just by employees with access to a hotline. The annual communication process must be designed before the first reporting cycle, not during it. - Public complaints and notification channels with confidentiality and anti-retaliation safeguards. - At least annual monitoring reviews plus event driven reassessments. - Annual statement workflow or documented CSRD exemption position with supporting evidence. ## Program layer 5: climate and enforcement readiness Article 22 climate planning and Articles 24 to 29 enforcement rules have to be treated as part of compliance, not as separate ESG side projects. Supervisory authorities can investigate, order remedial action, and impose penalties. Civil liability sits beside that regime, not behind it. A mature program keeps a response pack ready with the current scope memo, policy, chain map, prioritization rationale, action plans, complaint logs, monitoring outputs, annual communication files, and climate transition plan updates. - Article 22 plan kept current and tied to implementation actions. - Supervisory response pack maintained and tested. - Litigation hold and document retention rules aligned to complaint and remediation workflows. *Recommended next step* *Placement: after the compliance steps* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Compliance guide across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Compliance guide from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Compliance guide](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Compliance guide and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Compliance guide. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. - [OECD Due Diligence Guidance for Responsible Business Conduct](https://www.oecd.org/content/dam/oecd/en/publications/reports/2018/05/oecd-due-diligence-guidance-for-responsible-business-conduct_81f92357/81f92357-en.pdf?ref=sorena.io) - Useful operating model reference because the Directive is built around risk based due diligence. - [UN Guiding Principles on Business and Human Rights](https://www.ohchr.org/sites/default/files/documents/publications/guidingprinciplesbusinesshr_en.pdf?ref=sorena.io) - Reference point for complaints design, remedy logic, and legitimate stakeholder engagement. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/compliance --- --- title: "EU CSDDD vs CSRD" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/csddd-vs-csrd" source_url: "https://www.sorena.io/artifacts/eu/csddd/csddd-vs-csrd" author: "Sorena AI" description: "Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting." keywords: - "EU CSDDD vs CSRD" - "CSDDD compared with CSRD" - "due diligence vs sustainability reporting" - "Directive (EU) 2024/1760 vs Directive (EU) 2022/2464" - "CSDDD annual statement vs CSRD reporting" - "EU CSDDD" - "CSRD" - "Due diligence" - "Reporting" - "ESRS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD vs CSRD Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. *EU CSDDD* *Comparison* ## EU CSDDD (Directive (EU) 2024/1760) Compared with CSRD These laws overlap, but they do not do the same job. Use this page to stop mixing operational due diligence duties with disclosure duties. CSDDD is about conduct. CSRD is about reporting. The two regimes should share data and governance where possible, but a company cannot comply with CSDDD by publishing a strong report alone, and it cannot satisfy CSRD by building a due diligence process without the required disclosures. ## Core difference: act versus disclose CSDDD requires companies to integrate due diligence into policies and risk management, identify and prioritize adverse human rights and environmental impacts, take appropriate preventive or corrective measures, enable complaints, provide remediation where relevant, monitor effectiveness, and maintain a climate transition plan. CSRD requires companies to report sustainability information in accordance with the corporate sustainability reporting framework. It is a disclosure regime aimed at decision useful reporting, not a standalone operating duty to prevent or remediate impacts. - CSDDD asks what the company must do. - CSRD asks what the company must disclose. - Both need evidence, but the evidence serves different legal functions. *Recommended next step* *Placement: after the comparison section* ## Use EU CSDDD (Directive (EU) 2024/1760) Compared with CSRD as a cited research workflow Research Copilot can take EU CSDDD (Directive (EU) 2024/1760) Compared with CSRD from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSDDD (Directive (EU) 2024/1760) Compared with CSRD](/solutions/research-copilot.md): Start from EU CSDDD (Directive (EU) 2024/1760) Compared with CSRD and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Compared with CSRD. ## Where the regimes connect The connection matters most in the annual statement and climate plan. Article 16 of the CSDDD exempts companies already subject to CSRD sustainability reporting from the standalone CSDDD annual statement obligation. Article 22 also deems companies that report a climate transition plan under the CSRD to have complied with the obligation to adopt such a plan under the CSDDD, although they still need to put it into effect and update it. - CSRD can remove the separate CSDDD annual statement burden. - CSRD can satisfy the adoption step for the Article 22 plan. - Neither deeming rule removes the need for real due diligence operations. ## How to build one program for both The efficient approach is to use one source of truth for scope, chain-of-activities mapping, material impact assessment, action plans, complaints, monitoring outputs, and climate plan data. Then map those records into the disclosure requirements under the CSRD and the conduct duties under the CSDDD. What you should not do is let the reporting team build one view of impacts while procurement and compliance teams build another. That creates inconsistent claims and can become evidence against you. - Use one impact register feeding both due diligence and reporting. - Keep one governance calendar for management review, board oversight, and publication. - Tag each record for operational use, disclosure use, or both. ## Typical mistake patterns The first common mistake is treating a strong CSRD report as proof that the company has done enough operational due diligence. The second is treating a supplier code and a few assessments as enough for CSRD quality disclosure. A third mistake is ignoring timing. The CSDDD application calendar now follows the 2025 timing amendment, while the CSRD has its own phased reporting path and separate amendment activity. - Do not let disclosure maturity hide operational gaps. - Do not let operational activity run without disclosure controls. - Use a law by law calendar and tie every date to the actual current legal text. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [Directive (EU) 2022/2464 - CSRD](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal source for the sustainability reporting regime that overlaps with CSDDD annual statement mechanics. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/csddd-vs-csrd --- --- title: "EU CSDDD vs CSRD" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/csddd-vs-csrd" source_url: "https://www.sorena.io/artifacts/eu/csddd/csddd-vs-csrd" author: "Sorena AI" description: "Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting." keywords: - "EU CSDDD vs CSRD" - "CSDDD compared with CSRD" - "due diligence vs sustainability reporting" - "Directive (EU) 2024/1760 vs Directive (EU) 2022/2464" - "CSDDD annual statement vs CSRD reporting" - "EU CSDDD" - "CSRD" - "Due diligence" - "Reporting" - "ESRS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD vs CSRD Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. *EU CSDDD* *Comparison* ## EU CSDDD (Directive (EU) 2024/1760) Compared with CSRD These laws overlap, but they do not do the same job. Use this page to stop mixing operational due diligence duties with disclosure duties. CSDDD is about conduct. CSRD is about reporting. The two regimes should share data and governance where possible, but a company cannot comply with CSDDD by publishing a strong report alone, and it cannot satisfy CSRD by building a due diligence process without the required disclosures. ## Core difference: act versus disclose CSDDD requires companies to integrate due diligence into policies and risk management, identify and prioritize adverse human rights and environmental impacts, take appropriate preventive or corrective measures, enable complaints, provide remediation where relevant, monitor effectiveness, and maintain a climate transition plan. CSRD requires companies to report sustainability information in accordance with the corporate sustainability reporting framework. It is a disclosure regime aimed at decision useful reporting, not a standalone operating duty to prevent or remediate impacts. - CSDDD asks what the company must do. - CSRD asks what the company must disclose. - Both need evidence, but the evidence serves different legal functions. *Recommended next step* *Placement: after the comparison section* ## Use EU CSDDD (Directive (EU) 2024/1760) Compared with CSRD as a cited research workflow Research Copilot can take EU CSDDD (Directive (EU) 2024/1760) Compared with CSRD from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSDDD (Directive (EU) 2024/1760) Compared with CSRD](/solutions/research-copilot.md): Start from EU CSDDD (Directive (EU) 2024/1760) Compared with CSRD and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Compared with CSRD. ## Where the regimes connect The connection matters most in the annual statement and climate plan. Article 16 of the CSDDD exempts companies already subject to CSRD sustainability reporting from the standalone CSDDD annual statement obligation. Article 22 also deems companies that report a climate transition plan under the CSRD to have complied with the obligation to adopt such a plan under the CSDDD, although they still need to put it into effect and update it. - CSRD can remove the separate CSDDD annual statement burden. - CSRD can satisfy the adoption step for the Article 22 plan. - Neither deeming rule removes the need for real due diligence operations. ## How to build one program for both The efficient approach is to use one source of truth for scope, chain-of-activities mapping, material impact assessment, action plans, complaints, monitoring outputs, and climate plan data. Then map those records into the disclosure requirements under the CSRD and the conduct duties under the CSDDD. What you should not do is let the reporting team build one view of impacts while procurement and compliance teams build another. That creates inconsistent claims and can become evidence against you. - Use one impact register feeding both due diligence and reporting. - Keep one governance calendar for management review, board oversight, and publication. - Tag each record for operational use, disclosure use, or both. ## Typical mistake patterns The first common mistake is treating a strong CSRD report as proof that the company has done enough operational due diligence. The second is treating a supplier code and a few assessments as enough for CSRD quality disclosure. A third mistake is ignoring timing. The CSDDD application calendar now follows the 2025 timing amendment, while the CSRD has its own phased reporting path and separate amendment activity. - Do not let disclosure maturity hide operational gaps. - Do not let operational activity run without disclosure controls. - Use a law by law calendar and tie every date to the actual current legal text. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [Directive (EU) 2022/2464 - CSRD](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal source for the sustainability reporting regime that overlaps with CSDDD annual statement mechanics. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/csddd-vs-csrd --- --- title: "EU CSDDD vs German LkSG" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/csddd-vs-german-lksg" source_url: "https://www.sorena.io/artifacts/eu/csddd/csddd-vs-german-lksg" author: "Sorena AI" description: "Compare the EU CSDDD with the German LkSG using official sources." keywords: - "EU CSDDD vs German LkSG" - "CSDDD compared with Lieferkettensorgfaltspflichtengesetz" - "CSDDD and LkSG differences" - "CSDDD scope vs LkSG scope" - "CSDDD climate plan vs LkSG" - "EU CSDDD" - "German LkSG" - "Supply chain due diligence" - "Comparison" - "Enforcement" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD vs German LkSG Compare the EU CSDDD with the German LkSG using official sources. *EU CSDDD* *Comparison* ## EU CSDDD (Directive (EU) 2024/1760) Compared with German LkSG Many German organizations already have an LkSG program. The question is what must change for the EU regime. This page focuses on the structural deltas that matter for scope, chain mapping, governance, and enforcement. The German LkSG gave many companies a head start on risk analysis, policy statements, complaint mechanisms, and supplier measures. The CSDDD does not replace the value of that work, but it uses different scope tests, a different chain definition, a Union wide supervisory model, and an explicit climate transition plan duty. ## Scope and who is covered The LkSG applies to companies with a certain employee count in Germany. The threshold moved to 1000 employees from 1 January 2024. The CSDDD uses different triggers: more than 1000 employees plus more than EUR 450 million worldwide turnover for EU companies, and more than EUR 450 million Union turnover for non-EU companies, plus separate franchising and licensing triggers. So an LkSG scope memo is not enough to answer the CSDDD scope question, especially for groups with non-German entities, heavy franchise models, or large Union turnover outside Germany. - LkSG: German employee threshold regime. - CSDDD: employee plus turnover or Union turnover, plus royalties route. - CSDDD also has an amended phased application calendar at EU level. ## Chain perimeter and business partner logic Both regimes are risk based and supplier focused, but the CSDDD uses the defined chain-of-activities concept with specific upstream and downstream boundaries. That definition includes certain downstream product distribution activities but excludes product disposal and excludes downstream services. A German program built around the LkSG supply chain concept should be remapped against the CSDDD chain definition rather than copied without review. - Check where downstream distribution is treated differently. - Retest indirect partner coverage against the CSDDD legal perimeter. - Update supplier registers to show which legal regime each field supports. ## Climate planning and communication The CSDDD introduces an explicit Article 22 transition plan duty aligned with 1.5 C and climate neutrality objectives. The LkSG does not contain the same standalone climate transition plan requirement. The CSDDD also has its own annual statement and ESAP mechanics, although companies already reporting under the CSRD can be exempt from the standalone annual statement. - Expect a climate governance uplift when moving from LkSG only to CSDDD readiness. - Check whether the group already has a CSRD climate plan that can serve the adoption step. - Build communication controls that work across both German and EU level obligations. ## Enforcement and liability profile The CSDDD creates a Union supervisory cooperation framework, allows substantiated concerns to be raised with supervisory authorities, requires penalties with a maximum cap not less than 5 percent of net worldwide turnover, and includes civil liability rules. Those features make the EU regime broader than a simple copy of existing German compliance routines. An LkSG program remains valuable, but it needs to be hardened for cross border supervision, Article 29 civil liability analysis, and greater focus on the design and traceability of due diligence decisions. - Prepare for Union level supervisory coordination under the CSDDD. - Retain records that can explain prioritization and disengagement decisions. - Treat complaints, remediation, and litigation support as first class controls. *Recommended next step* *Placement: after the comparison section* ## Use EU CSDDD (Directive (EU) 2024/1760) Compared with German LkSG as a cited research workflow Research Copilot can take EU CSDDD (Directive (EU) 2024/1760) Compared with German LkSG from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSDDD (Directive (EU) 2024/1760) Compared with German LkSG](/solutions/research-copilot.md): Start from EU CSDDD (Directive (EU) 2024/1760) Compared with German LkSG and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Compared with German LkSG. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [German LkSG - official legal text](https://www.gesetze-im-internet.de/lksg/BJNR295910021.html) - Primary legal source for the German Supply Chain Due Diligence Act. - [BAFA - LkSG overview and FAQs](https://www.bafa.de/DE/Lieferketten/FAQ/haeufig_gestellte_fragen.html) - Official enforcement and implementation context for the German regime. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/csddd-vs-german-lksg --- --- title: "EU CSDDD vs German LkSG" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/csddd-vs-german-lksg" source_url: "https://www.sorena.io/artifacts/eu/csddd/csddd-vs-german-lksg" author: "Sorena AI" description: "Compare the EU CSDDD with the German LkSG using official sources." keywords: - "EU CSDDD vs German LkSG" - "CSDDD compared with Lieferkettensorgfaltspflichtengesetz" - "CSDDD and LkSG differences" - "CSDDD scope vs LkSG scope" - "CSDDD climate plan vs LkSG" - "EU CSDDD" - "German LkSG" - "Supply chain due diligence" - "Comparison" - "Enforcement" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD vs German LkSG Compare the EU CSDDD with the German LkSG using official sources. *EU CSDDD* *Comparison* ## EU CSDDD (Directive (EU) 2024/1760) Compared with German LkSG Many German organizations already have an LkSG program. The question is what must change for the EU regime. This page focuses on the structural deltas that matter for scope, chain mapping, governance, and enforcement. The German LkSG gave many companies a head start on risk analysis, policy statements, complaint mechanisms, and supplier measures. The CSDDD does not replace the value of that work, but it uses different scope tests, a different chain definition, a Union wide supervisory model, and an explicit climate transition plan duty. ## Scope and who is covered The LkSG applies to companies with a certain employee count in Germany. The threshold moved to 1000 employees from 1 January 2024. The CSDDD uses different triggers: more than 1000 employees plus more than EUR 450 million worldwide turnover for EU companies, and more than EUR 450 million Union turnover for non-EU companies, plus separate franchising and licensing triggers. So an LkSG scope memo is not enough to answer the CSDDD scope question, especially for groups with non-German entities, heavy franchise models, or large Union turnover outside Germany. - LkSG: German employee threshold regime. - CSDDD: employee plus turnover or Union turnover, plus royalties route. - CSDDD also has an amended phased application calendar at EU level. ## Chain perimeter and business partner logic Both regimes are risk based and supplier focused, but the CSDDD uses the defined chain-of-activities concept with specific upstream and downstream boundaries. That definition includes certain downstream product distribution activities but excludes product disposal and excludes downstream services. A German program built around the LkSG supply chain concept should be remapped against the CSDDD chain definition rather than copied without review. - Check where downstream distribution is treated differently. - Retest indirect partner coverage against the CSDDD legal perimeter. - Update supplier registers to show which legal regime each field supports. ## Climate planning and communication The CSDDD introduces an explicit Article 22 transition plan duty aligned with 1.5 C and climate neutrality objectives. The LkSG does not contain the same standalone climate transition plan requirement. The CSDDD also has its own annual statement and ESAP mechanics, although companies already reporting under the CSRD can be exempt from the standalone annual statement. - Expect a climate governance uplift when moving from LkSG only to CSDDD readiness. - Check whether the group already has a CSRD climate plan that can serve the adoption step. - Build communication controls that work across both German and EU level obligations. ## Enforcement and liability profile The CSDDD creates a Union supervisory cooperation framework, allows substantiated concerns to be raised with supervisory authorities, requires penalties with a maximum cap not less than 5 percent of net worldwide turnover, and includes civil liability rules. Those features make the EU regime broader than a simple copy of existing German compliance routines. An LkSG program remains valuable, but it needs to be hardened for cross border supervision, Article 29 civil liability analysis, and greater focus on the design and traceability of due diligence decisions. - Prepare for Union level supervisory coordination under the CSDDD. - Retain records that can explain prioritization and disengagement decisions. - Treat complaints, remediation, and litigation support as first class controls. *Recommended next step* *Placement: after the comparison section* ## Use EU CSDDD (Directive (EU) 2024/1760) Compared with German LkSG as a cited research workflow Research Copilot can take EU CSDDD (Directive (EU) 2024/1760) Compared with German LkSG from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSDDD (Directive (EU) 2024/1760) Compared with German LkSG](/solutions/research-copilot.md): Start from EU CSDDD (Directive (EU) 2024/1760) Compared with German LkSG and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Compared with German LkSG. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [German LkSG - official legal text](https://www.gesetze-im-internet.de/lksg/BJNR295910021.html) - Primary legal source for the German Supply Chain Due Diligence Act. - [BAFA - LkSG overview and FAQs](https://www.bafa.de/DE/Lieferketten/FAQ/haeufig_gestellte_fragen.html) - Official enforcement and implementation context for the German regime. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/csddd-vs-german-lksg --- --- title: "EU CSDDD Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/csddd/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline." keywords: - "EU CSDDD deadlines" - "CSDDD calendar" - "Directive (EU) 2025/794" - "CSDDD 26 July 2027" - "CSDDD 26 July 2028" - "CSDDD 26 July 2029" - "CSDDD Article 16 annual statement" - "CSDDD ESAP" - "EU CSDDD" - "Deadlines" - "Calendar" - "Implementation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Deadlines and Compliance Calendar Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. *EU CSDDD* *Calendar* ## EU CSDDD (Directive (EU) 2024/1760) Deadlines and compliance calendar This is the current legal calendar, not the original 2024 adoption calendar repeated on older summaries. Use it to sequence transposition tracking, policy rollout, supplier work, communication controls, and board oversight. The timing changed in 2025. If your roadmap still assumes a 26 July 2026 transposition deadline or a 26 July 2027 first application wave, it needs correction. The amendment in Directive (EU) 2025/794 postponed both the transposition deadline and the first wave of application by one year. ## 25 July 2024: Directive enters into force Directive (EU) 2024/1760 entered into force on 25 July 2024. That matters because the Commission guideline and delegated act timetable runs from the legal framework created by the Directive, even though company level application is phased later. This is also the anchor date for internal legal inventories and for deciding whether older internal summaries are still current. - Use this as the baseline legal act date in policy registers. - Archive earlier draft based project plans separately from current implementation planning. - Reference the amended consolidated text for current operations. ## 26 January 2027 and 31 March 2027: support tools before application Article 19 requires Commission guidance on voluntary model contractual clauses by 26 January 2027. Article 16 requires the Commission to adopt delegated acts on annual statement content and criteria by 31 March 2027. These dates matter because they shape how companies should build supplier clauses and annual communication processes before the first wave applies. - Refresh contract clause libraries when the guidance is issued. - Build the annual statement process around the delegated act once published. - Do not wait for application day to design these controls. ## 26 July 2027: Member State transposition deadline Directive (EU) 2025/794 moved the transposition deadline to 26 July 2027. By then, Member States must adopt and publish the national measures needed to comply with the Directive. Your legal tracking should therefore switch from abstract directive analysis to concrete national implementation monitoring during 2027. - Maintain a transposition tracker for key Member States. - Watch for local supervisory authority designations and procedural differences. - Update complaints and investigation response plans once national channels are clearer. *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Deadlines and compliance calendar across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Deadlines and compliance calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Deadlines and compliance calendar](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Deadlines and compliance calendar and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Deadlines and compliance calendar. ## 26 July 2028: first application wave The first application wave now starts on 26 July 2028. This wave covers EU companies with more than 5000 employees and more than EUR 1.5 billion net worldwide turnover, and non-EU companies with more than EUR 1.5 billion net turnover in the Union. For these companies, the measures necessary to comply with Article 16 apply for financial years starting on or after 1 January 2028. That means reporting design cannot be treated as a later stage project. - Use 2027 and early 2028 for burn-in of complaints, remediation, and monitoring workflows. - Treat annual communication readiness as part of wave one preparation. - Retest scope at year end if turnover or group structure moved materially. ## 26 July 2029 and 1 January 2029: broader application and ESAP Broader application begins on 26 July 2029 for the remaining in-scope companies, including the more than 1000 employees and more than EUR 450 million turnover cohort and the qualifying franchising or licensing route. Article 16 measures for that broader cohort apply for financial years starting on or after 1 January 2029. Article 17 also brings ESAP submission into play from 1 January 2029 for annual statements that must be made available through the European Single Access Point. - Prepare metadata, publication, and extraction controls for ESAP workflows. - Do not assume a company outside wave one can postpone all design work until 2029. - Run at least one dry run of the annual statement and supporting evidence pack before the first live cycle. ## Keep one note on the pending Omnibus simplification proposal The Commission also issued a separate 2025 proposal to simplify parts of the Directive beyond timing. As of 6 March 2026, that proposal is not the same thing as the timing amendment already in force. Treat it as pending until it is adopted and published in the Official Journal. This distinction matters because teams often confuse the enacted date changes with proposed substantive duty changes. - Use enacted law for dates now. - Track the simplification proposal separately as a pending change item. - Avoid rewriting procedures around proposals that are not yet law. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/deadlines-and-compliance-calendar --- --- title: "EU CSDDD Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/csddd/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline." keywords: - "EU CSDDD deadlines" - "CSDDD calendar" - "Directive (EU) 2025/794" - "CSDDD 26 July 2027" - "CSDDD 26 July 2028" - "CSDDD 26 July 2029" - "CSDDD Article 16 annual statement" - "CSDDD ESAP" - "EU CSDDD" - "Deadlines" - "Calendar" - "Implementation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Deadlines and Compliance Calendar Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. *EU CSDDD* *Calendar* ## EU CSDDD (Directive (EU) 2024/1760) Deadlines and compliance calendar This is the current legal calendar, not the original 2024 adoption calendar repeated on older summaries. Use it to sequence transposition tracking, policy rollout, supplier work, communication controls, and board oversight. The timing changed in 2025. If your roadmap still assumes a 26 July 2026 transposition deadline or a 26 July 2027 first application wave, it needs correction. The amendment in Directive (EU) 2025/794 postponed both the transposition deadline and the first wave of application by one year. ## 25 July 2024: Directive enters into force Directive (EU) 2024/1760 entered into force on 25 July 2024. That matters because the Commission guideline and delegated act timetable runs from the legal framework created by the Directive, even though company level application is phased later. This is also the anchor date for internal legal inventories and for deciding whether older internal summaries are still current. - Use this as the baseline legal act date in policy registers. - Archive earlier draft based project plans separately from current implementation planning. - Reference the amended consolidated text for current operations. ## 26 January 2027 and 31 March 2027: support tools before application Article 19 requires Commission guidance on voluntary model contractual clauses by 26 January 2027. Article 16 requires the Commission to adopt delegated acts on annual statement content and criteria by 31 March 2027. These dates matter because they shape how companies should build supplier clauses and annual communication processes before the first wave applies. - Refresh contract clause libraries when the guidance is issued. - Build the annual statement process around the delegated act once published. - Do not wait for application day to design these controls. ## 26 July 2027: Member State transposition deadline Directive (EU) 2025/794 moved the transposition deadline to 26 July 2027. By then, Member States must adopt and publish the national measures needed to comply with the Directive. Your legal tracking should therefore switch from abstract directive analysis to concrete national implementation monitoring during 2027. - Maintain a transposition tracker for key Member States. - Watch for local supervisory authority designations and procedural differences. - Update complaints and investigation response plans once national channels are clearer. *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Deadlines and compliance calendar across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Deadlines and compliance calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Deadlines and compliance calendar](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Deadlines and compliance calendar and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Deadlines and compliance calendar. ## 26 July 2028: first application wave The first application wave now starts on 26 July 2028. This wave covers EU companies with more than 5000 employees and more than EUR 1.5 billion net worldwide turnover, and non-EU companies with more than EUR 1.5 billion net turnover in the Union. For these companies, the measures necessary to comply with Article 16 apply for financial years starting on or after 1 January 2028. That means reporting design cannot be treated as a later stage project. - Use 2027 and early 2028 for burn-in of complaints, remediation, and monitoring workflows. - Treat annual communication readiness as part of wave one preparation. - Retest scope at year end if turnover or group structure moved materially. ## 26 July 2029 and 1 January 2029: broader application and ESAP Broader application begins on 26 July 2029 for the remaining in-scope companies, including the more than 1000 employees and more than EUR 450 million turnover cohort and the qualifying franchising or licensing route. Article 16 measures for that broader cohort apply for financial years starting on or after 1 January 2029. Article 17 also brings ESAP submission into play from 1 January 2029 for annual statements that must be made available through the European Single Access Point. - Prepare metadata, publication, and extraction controls for ESAP workflows. - Do not assume a company outside wave one can postpone all design work until 2029. - Run at least one dry run of the annual statement and supporting evidence pack before the first live cycle. ## Keep one note on the pending Omnibus simplification proposal The Commission also issued a separate 2025 proposal to simplify parts of the Directive beyond timing. As of 6 March 2026, that proposal is not the same thing as the timing amendment already in force. Treat it as pending until it is adopted and published in the Official Journal. This distinction matters because teams often confuse the enacted date changes with proposed substantive duty changes. - Use enacted law for dates now. - Track the simplification proposal separately as a pending change item. - Avoid rewriting procedures around proposals that are not yet law. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/deadlines-and-compliance-calendar --- --- title: "EU CSDDD Due Diligence Steps Playbook" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/due-diligence-steps-playbook" source_url: "https://www.sorena.io/artifacts/eu/csddd/due-diligence-steps-playbook" author: "Sorena AI" description: "Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action." keywords: - "EU CSDDD due diligence steps" - "CSDDD playbook" - "Articles 7 to 15 CSDDD" - "CSDDD prevention corrective action remediation" - "CSDDD complaints and monitoring" - "EU CSDDD" - "Playbook" - "Due diligence" - "Articles 7 to 15" - "Implementation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Due Diligence Steps Playbook Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. *EU CSDDD* *Playbook* ## EU CSDDD (Directive (EU) 2024/1760) Due diligence steps playbook This is the order of work that usually produces the least rework. Start with scope and policy, then build the records that later support action, complaints, and reporting. The Directive lists duties article by article, but implementation works better in steps. The sequence below follows the logic of the law while reflecting how procurement, legal, ESG, and operations teams actually need to coordinate. ## Step 1: lock scope, chain boundaries, and ownership Before Article 7 policy drafting, confirm which entity is in scope, whether a parent performs duties for subsidiaries, and which activities are inside the chain of activities. Otherwise later controls attach to the wrong perimeter. Use one scope memo and one chain boundary log so every team works from the same assumptions. - Scope memo completed. - Chain-of-activities boundary log completed. - Named owners assigned across legal, procurement, ESG, and risk. ## Step 2: integrate due diligence into policy and risk management Article 7 requires a due diligence policy and integration into relevant policies and risk management systems. This is where you establish the code of conduct and the implementation process that later supplier and remediation work depends on. If the policy is vague, teams will improvise thresholds and action standards later. - Due diligence policy approved. - Code of conduct linked to subsidiaries and business partners. - Review cycle set for at least every 24 months and after significant change. ## Step 3: identify and prioritize impacts Article 8 requires mapping and assessment. Article 9 requires prioritization when not all impacts can be addressed at once. Use quantitative and qualitative information and keep a clear rationale for why one area was escalated ahead of another. This is the foundation for defensible supplier requests and for later supervisory explanations. - High risk areas mapped. - In depth assessments performed where impacts are most severe and likely. - Severity and likelihood prioritization recorded. ## Step 4: prevent potential impacts and correct actual impacts Article 10 focuses on prevention and mitigation of potential impacts. Article 11 focuses on bringing actual impacts to an end or minimizing their extent. Both need action plans, leverage strategy, and verification rather than generic supplier promises. Contractual assurances help, but the law expects verification and measured follow through. - Prevention and corrective action plans issued and tracked. - Verification methods tied to the relevant partner and risk level. - Responsible disengagement analysis available where leverage is failing. ## Step 5: enable remediation, stakeholders, complaints, and monitoring Article 12 remediation, Article 13 stakeholder engagement, Article 14 complaints, and Article 15 monitoring should be built together. Complaints feed identification. Monitoring tests whether action plans are working. Stakeholder engagement informs all three. This is also where many programs become credible or fail. If the complaint route is weak and the monitoring cycle is not real, the rest of the program looks cosmetic. - Remediation workflow approved. - Complaint and notification channels live. - Annual and event driven monitoring cycle operating. *Recommended next step* *Placement: after the workflow or playbook section* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Due diligence steps playbook across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Due diligence steps playbook from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Due diligence steps playbook](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Due diligence steps playbook and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Due diligence steps playbook. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [OECD Due Diligence Guidance for Responsible Business Conduct](https://www.oecd.org/content/dam/oecd/en/publications/reports/2018/05/oecd-due-diligence-guidance-for-responsible-business-conduct_81f92357/81f92357-en.pdf?ref=sorena.io) - Useful operating model reference because the Directive is built around risk based due diligence. - [UN Guiding Principles on Business and Human Rights](https://www.ohchr.org/sites/default/files/documents/publications/guidingprinciplesbusinesshr_en.pdf?ref=sorena.io) - Reference point for complaints design, remedy logic, and legitimate stakeholder engagement. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/due-diligence-steps-playbook --- --- title: "EU CSDDD Due Diligence Steps Playbook" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/due-diligence-steps-playbook" source_url: "https://www.sorena.io/artifacts/eu/csddd/due-diligence-steps-playbook" author: "Sorena AI" description: "Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action." keywords: - "EU CSDDD due diligence steps" - "CSDDD playbook" - "Articles 7 to 15 CSDDD" - "CSDDD prevention corrective action remediation" - "CSDDD complaints and monitoring" - "EU CSDDD" - "Playbook" - "Due diligence" - "Articles 7 to 15" - "Implementation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Due Diligence Steps Playbook Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. *EU CSDDD* *Playbook* ## EU CSDDD (Directive (EU) 2024/1760) Due diligence steps playbook This is the order of work that usually produces the least rework. Start with scope and policy, then build the records that later support action, complaints, and reporting. The Directive lists duties article by article, but implementation works better in steps. The sequence below follows the logic of the law while reflecting how procurement, legal, ESG, and operations teams actually need to coordinate. ## Step 1: lock scope, chain boundaries, and ownership Before Article 7 policy drafting, confirm which entity is in scope, whether a parent performs duties for subsidiaries, and which activities are inside the chain of activities. Otherwise later controls attach to the wrong perimeter. Use one scope memo and one chain boundary log so every team works from the same assumptions. - Scope memo completed. - Chain-of-activities boundary log completed. - Named owners assigned across legal, procurement, ESG, and risk. ## Step 2: integrate due diligence into policy and risk management Article 7 requires a due diligence policy and integration into relevant policies and risk management systems. This is where you establish the code of conduct and the implementation process that later supplier and remediation work depends on. If the policy is vague, teams will improvise thresholds and action standards later. - Due diligence policy approved. - Code of conduct linked to subsidiaries and business partners. - Review cycle set for at least every 24 months and after significant change. ## Step 3: identify and prioritize impacts Article 8 requires mapping and assessment. Article 9 requires prioritization when not all impacts can be addressed at once. Use quantitative and qualitative information and keep a clear rationale for why one area was escalated ahead of another. This is the foundation for defensible supplier requests and for later supervisory explanations. - High risk areas mapped. - In depth assessments performed where impacts are most severe and likely. - Severity and likelihood prioritization recorded. ## Step 4: prevent potential impacts and correct actual impacts Article 10 focuses on prevention and mitigation of potential impacts. Article 11 focuses on bringing actual impacts to an end or minimizing their extent. Both need action plans, leverage strategy, and verification rather than generic supplier promises. Contractual assurances help, but the law expects verification and measured follow through. - Prevention and corrective action plans issued and tracked. - Verification methods tied to the relevant partner and risk level. - Responsible disengagement analysis available where leverage is failing. ## Step 5: enable remediation, stakeholders, complaints, and monitoring Article 12 remediation, Article 13 stakeholder engagement, Article 14 complaints, and Article 15 monitoring should be built together. Complaints feed identification. Monitoring tests whether action plans are working. Stakeholder engagement informs all three. This is also where many programs become credible or fail. If the complaint route is weak and the monitoring cycle is not real, the rest of the program looks cosmetic. - Remediation workflow approved. - Complaint and notification channels live. - Annual and event driven monitoring cycle operating. *Recommended next step* *Placement: after the workflow or playbook section* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Due diligence steps playbook across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Due diligence steps playbook from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Due diligence steps playbook](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Due diligence steps playbook and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Due diligence steps playbook. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [OECD Due Diligence Guidance for Responsible Business Conduct](https://www.oecd.org/content/dam/oecd/en/publications/reports/2018/05/oecd-due-diligence-guidance-for-responsible-business-conduct_81f92357/81f92357-en.pdf?ref=sorena.io) - Useful operating model reference because the Directive is built around risk based due diligence. - [UN Guiding Principles on Business and Human Rights](https://www.ohchr.org/sites/default/files/documents/publications/guidingprinciplesbusinesshr_en.pdf?ref=sorena.io) - Reference point for complaints design, remedy logic, and legitimate stakeholder engagement. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/due-diligence-steps-playbook --- --- title: "EU CSDDD FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/faq" source_url: "https://www.sorena.io/artifacts/eu/csddd/faq" author: "Sorena AI" description: "Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works." keywords: - "EU CSDDD FAQ" - "CSDDD questions" - "CSDDD current dates" - "CSDDD scope questions" - "CSDDD annual statement" - "CSDDD penalties and liability" - "EU CSDDD" - "FAQ" - "Dates" - "Scope" - "Penalties" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD FAQ Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. *EU CSDDD* *FAQ* ## EU CSDDD (Directive (EU) 2024/1760) Frequently asked questions These are the questions that usually create delay or rework. The answers below use the current directive text and the 2025 timing amendment, not outdated project notes. Most CSDDD confusion comes from three places: outdated dates, weak understanding of the chain-of-activities boundary, and confusion between reporting duties and operational due diligence duties. Use the answers below as a grounded starting point and validate them against your structure and national transposition rules. ## When does the CSDDD apply now? The Directive entered into force on 25 July 2024, but company level application is phased. After Directive (EU) 2025/794, Member States transpose by 26 July 2027, the first wave applies from 26 July 2028, and broader application follows from 26 July 2029. If you still have internal material showing a 26 July 2026 transposition deadline or a 26 July 2027 first wave, update it. - 25 July 2024: in force. - 26 July 2027: transposition deadline. - 26 July 2028 and 26 July 2029: application waves. ## Who is in scope? EU companies are mainly captured when they have more than 1000 employees and more than EUR 450 million worldwide turnover. Non-EU companies are captured mainly through more than EUR 450 million Union turnover. There is also a separate franchising and licensing route using EUR 22.5 million royalties and EUR 80 million turnover. Group structure matters because ultimate parent companies and designated subsidiaries can be relevant to how duties are performed. - Do not rely on employee count alone. - Test the royalties route separately. - Keep a written scope memo with the exact article basis used. ## Does the Directive cover all downstream partners? No. The chain of activities includes certain downstream distribution, transport, and storage activities for products where the partner acts for the company or on its behalf. It does not include product disposal and it does not include downstream partners related to the services of the company. That boundary should be recorded clearly because it shapes supplier outreach and complaint routing. - Product downstream can be partly in scope. - Service downstream is excluded. - Product disposal is excluded. ## If we already report under CSRD, do we still need to do CSDDD work? Yes. CSRD reporting can remove the separate Article 16 annual statement burden and can satisfy the adoption step of the Article 22 transition plan, but it does not remove the operational due diligence duties under Articles 7 to 15 or the duty to put the transition plan into effect. In short, reporting can reduce duplication, but it does not replace the due diligence program. - Annual statement may be exempted. - Climate plan adoption may be deemed satisfied. - Operational due diligence duties still apply. ## What are the penalty and liability risks? Member States must provide penalties that are effective, proportionate, and dissuasive. When pecuniary penalties are imposed, the maximum limit must be at least 5 percent of net worldwide turnover. The Directive also includes civil liability rules where a company intentionally or negligently fails to comply with certain obligations and that failure causes damage to a natural or legal person. A company cannot be held liable if the damage was caused only by its business partners. National law will still matter heavily once Member States transpose the Directive. - At least 5 percent maximum turnover cap for fines. - Civil liability sits alongside supervisory enforcement. - Transposition details will shape procedure and forum risk. *Recommended next step* *Placement: after the FAQ section* ## Use EU CSDDD (Directive (EU) 2024/1760) Frequently asked questions as a cited research workflow Research Copilot can take EU CSDDD (Directive (EU) 2024/1760) Frequently asked questions from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSDDD (Directive (EU) 2024/1760) Frequently asked questions](/solutions/research-copilot.md): Start from EU CSDDD (Directive (EU) 2024/1760) Frequently asked questions and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Frequently asked questions. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. - [Directive (EU) 2022/2464 - CSRD](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal source for the sustainability reporting regime that overlaps with CSDDD annual statement mechanics. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/faq --- --- title: "EU CSDDD FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/faq" source_url: "https://www.sorena.io/artifacts/eu/csddd/faq" author: "Sorena AI" description: "Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works." keywords: - "EU CSDDD FAQ" - "CSDDD questions" - "CSDDD current dates" - "CSDDD scope questions" - "CSDDD annual statement" - "CSDDD penalties and liability" - "EU CSDDD" - "FAQ" - "Dates" - "Scope" - "Penalties" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD FAQ Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. *EU CSDDD* *FAQ* ## EU CSDDD (Directive (EU) 2024/1760) Frequently asked questions These are the questions that usually create delay or rework. The answers below use the current directive text and the 2025 timing amendment, not outdated project notes. Most CSDDD confusion comes from three places: outdated dates, weak understanding of the chain-of-activities boundary, and confusion between reporting duties and operational due diligence duties. Use the answers below as a grounded starting point and validate them against your structure and national transposition rules. ## When does the CSDDD apply now? The Directive entered into force on 25 July 2024, but company level application is phased. After Directive (EU) 2025/794, Member States transpose by 26 July 2027, the first wave applies from 26 July 2028, and broader application follows from 26 July 2029. If you still have internal material showing a 26 July 2026 transposition deadline or a 26 July 2027 first wave, update it. - 25 July 2024: in force. - 26 July 2027: transposition deadline. - 26 July 2028 and 26 July 2029: application waves. ## Who is in scope? EU companies are mainly captured when they have more than 1000 employees and more than EUR 450 million worldwide turnover. Non-EU companies are captured mainly through more than EUR 450 million Union turnover. There is also a separate franchising and licensing route using EUR 22.5 million royalties and EUR 80 million turnover. Group structure matters because ultimate parent companies and designated subsidiaries can be relevant to how duties are performed. - Do not rely on employee count alone. - Test the royalties route separately. - Keep a written scope memo with the exact article basis used. ## Does the Directive cover all downstream partners? No. The chain of activities includes certain downstream distribution, transport, and storage activities for products where the partner acts for the company or on its behalf. It does not include product disposal and it does not include downstream partners related to the services of the company. That boundary should be recorded clearly because it shapes supplier outreach and complaint routing. - Product downstream can be partly in scope. - Service downstream is excluded. - Product disposal is excluded. ## If we already report under CSRD, do we still need to do CSDDD work? Yes. CSRD reporting can remove the separate Article 16 annual statement burden and can satisfy the adoption step of the Article 22 transition plan, but it does not remove the operational due diligence duties under Articles 7 to 15 or the duty to put the transition plan into effect. In short, reporting can reduce duplication, but it does not replace the due diligence program. - Annual statement may be exempted. - Climate plan adoption may be deemed satisfied. - Operational due diligence duties still apply. ## What are the penalty and liability risks? Member States must provide penalties that are effective, proportionate, and dissuasive. When pecuniary penalties are imposed, the maximum limit must be at least 5 percent of net worldwide turnover. The Directive also includes civil liability rules where a company intentionally or negligently fails to comply with certain obligations and that failure causes damage to a natural or legal person. A company cannot be held liable if the damage was caused only by its business partners. National law will still matter heavily once Member States transpose the Directive. - At least 5 percent maximum turnover cap for fines. - Civil liability sits alongside supervisory enforcement. - Transposition details will shape procedure and forum risk. *Recommended next step* *Placement: after the FAQ section* ## Use EU CSDDD (Directive (EU) 2024/1760) Frequently asked questions as a cited research workflow Research Copilot can take EU CSDDD (Directive (EU) 2024/1760) Frequently asked questions from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSDDD (Directive (EU) 2024/1760) Frequently asked questions](/solutions/research-copilot.md): Start from EU CSDDD (Directive (EU) 2024/1760) Frequently asked questions and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Frequently asked questions. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. - [Directive (EU) 2022/2464 - CSRD](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal source for the sustainability reporting regime that overlaps with CSDDD annual statement mechanics. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/faq --- --- title: "EU CSDDD Grievance and Remediation Workflows" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/grievance-and-remediation-workflows" source_url: "https://www.sorena.io/artifacts/eu/csddd/grievance-and-remediation-workflows" author: "Sorena AI" description: "Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14." keywords: - "EU CSDDD complaints procedure" - "CSDDD grievance workflow" - "CSDDD remediation" - "Article 12 remediation" - "Article 14 complaints" - "CSDDD anti retaliation" - "CSDDD notification mechanism" - "EU CSDDD" - "Complaints" - "Remediation" - "Grievance" - "Stakeholders" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Grievance and Remediation Workflows Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. *EU CSDDD* *Workflow* ## EU CSDDD (Directive (EU) 2024/1760) Grievance and remediation workflows This is where the Directive becomes visible to affected people, not just to internal control owners. A weak workflow here creates both supervisory and civil liability risk very quickly. Articles 12 to 14 require more than a hotline. Companies need a fair and accessible complaints procedure, a usable notification mechanism, meaningful stakeholder engagement, and a way to provide remediation where the company caused or jointly caused the actual adverse impact. ## Complaints versus notifications: build both routes The Directive expects companies to provide the possibility for persons and organizations to submit complaints where they have legitimate concerns regarding actual or potential adverse impacts. It also expects a notification mechanism for persons and organizations that have information or concerns regarding actual or potential adverse impacts. Do not collapse both concepts into one mailbox without workflow rules. You need intake categories, confidentiality controls, routing rules, and response expectations. - Create intake categories for complaint, notification, and urgent escalation. - Allow access for affected persons, their representatives, trade unions, workers representatives, and relevant civil society organizations. - Track whether the submission creates an Article 8 identification trigger. ## Design the Article 14 procedure around accessibility and fairness The complaints procedure should be fair, publicly available, accessible, predictable, and transparent. These are not decorative words. They should drive channel design, language availability, response timing, explanation quality, and meeting access. The workflow should also include confidentiality and anti-retaliation measures, especially where workers, trade unions, community representatives, or human rights defenders are involved. - Publish the procedure in understandable language. - Define who can ask for follow up and who can meet company representatives. - Document anti-retaliation and confidentiality measures. ## When remediation is required Article 12 requires remediation where the company caused or jointly caused the actual adverse impact. Remediation means restoring the affected person, community, or environment to a situation equivalent or as close as possible to the situation that would have existed without the impact, proportionate to the company implication. Where the business partner caused the impact alone, the company may still support or enable remediation through leverage, but the legal posture is different. Your workflow should capture this distinction clearly. - Triage causation: caused, jointly caused, or partner only. - Set a path for financial and non-financial remediation options. - Retain evidence explaining the chosen remedy and the company role. ## Stakeholder engagement should not be an afterthought Stakeholder engagement is required across multiple stages, including mapping, prioritization, action planning, remediation, and monitoring. That means your grievance workflow should be able to hand off information into these other processes and receive updates back. Use one case file that records stakeholders consulted, concerns raised, actions taken, and whether further meetings or communications are needed. - Keep stakeholder contact and representation logic consistent with local law. - Link the grievance file to the partner, geography, and impact category in the due diligence register. - Escalate severe cases to senior management with documented rationale. ## Evidence to keep for supervisory and court scenarios A complaint workflow is only defensible if the company can later show what it received, how it assessed the issue, what follow up occurred, and how any remediation decision was made. This evidence is important for supervisory reviews and can matter in Article 29 litigation scenarios as well. Keep the file structured. Long email chains are not a control system. - Case chronology, participants, and decision record. - Basis for founded or unfounded assessment. - Remediation decision, actions taken, and monitoring follow up. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Grievance and remediation workflows across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Grievance and remediation workflows from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Grievance and remediation workflows](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Grievance and remediation workflows and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Grievance and remediation workflows. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [OECD Due Diligence Guidance for Responsible Business Conduct](https://www.oecd.org/content/dam/oecd/en/publications/reports/2018/05/oecd-due-diligence-guidance-for-responsible-business-conduct_81f92357/81f92357-en.pdf?ref=sorena.io) - Useful operating model reference because the Directive is built around risk based due diligence. - [UN Guiding Principles on Business and Human Rights](https://www.ohchr.org/sites/default/files/documents/publications/guidingprinciplesbusinesshr_en.pdf?ref=sorena.io) - Reference point for complaints design, remedy logic, and legitimate stakeholder engagement. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/grievance-and-remediation-workflows --- --- title: "EU CSDDD Grievance and Remediation Workflows" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/grievance-and-remediation-workflows" source_url: "https://www.sorena.io/artifacts/eu/csddd/grievance-and-remediation-workflows" author: "Sorena AI" description: "Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14." keywords: - "EU CSDDD complaints procedure" - "CSDDD grievance workflow" - "CSDDD remediation" - "Article 12 remediation" - "Article 14 complaints" - "CSDDD anti retaliation" - "CSDDD notification mechanism" - "EU CSDDD" - "Complaints" - "Remediation" - "Grievance" - "Stakeholders" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Grievance and Remediation Workflows Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. *EU CSDDD* *Workflow* ## EU CSDDD (Directive (EU) 2024/1760) Grievance and remediation workflows This is where the Directive becomes visible to affected people, not just to internal control owners. A weak workflow here creates both supervisory and civil liability risk very quickly. Articles 12 to 14 require more than a hotline. Companies need a fair and accessible complaints procedure, a usable notification mechanism, meaningful stakeholder engagement, and a way to provide remediation where the company caused or jointly caused the actual adverse impact. ## Complaints versus notifications: build both routes The Directive expects companies to provide the possibility for persons and organizations to submit complaints where they have legitimate concerns regarding actual or potential adverse impacts. It also expects a notification mechanism for persons and organizations that have information or concerns regarding actual or potential adverse impacts. Do not collapse both concepts into one mailbox without workflow rules. You need intake categories, confidentiality controls, routing rules, and response expectations. - Create intake categories for complaint, notification, and urgent escalation. - Allow access for affected persons, their representatives, trade unions, workers representatives, and relevant civil society organizations. - Track whether the submission creates an Article 8 identification trigger. ## Design the Article 14 procedure around accessibility and fairness The complaints procedure should be fair, publicly available, accessible, predictable, and transparent. These are not decorative words. They should drive channel design, language availability, response timing, explanation quality, and meeting access. The workflow should also include confidentiality and anti-retaliation measures, especially where workers, trade unions, community representatives, or human rights defenders are involved. - Publish the procedure in understandable language. - Define who can ask for follow up and who can meet company representatives. - Document anti-retaliation and confidentiality measures. ## When remediation is required Article 12 requires remediation where the company caused or jointly caused the actual adverse impact. Remediation means restoring the affected person, community, or environment to a situation equivalent or as close as possible to the situation that would have existed without the impact, proportionate to the company implication. Where the business partner caused the impact alone, the company may still support or enable remediation through leverage, but the legal posture is different. Your workflow should capture this distinction clearly. - Triage causation: caused, jointly caused, or partner only. - Set a path for financial and non-financial remediation options. - Retain evidence explaining the chosen remedy and the company role. ## Stakeholder engagement should not be an afterthought Stakeholder engagement is required across multiple stages, including mapping, prioritization, action planning, remediation, and monitoring. That means your grievance workflow should be able to hand off information into these other processes and receive updates back. Use one case file that records stakeholders consulted, concerns raised, actions taken, and whether further meetings or communications are needed. - Keep stakeholder contact and representation logic consistent with local law. - Link the grievance file to the partner, geography, and impact category in the due diligence register. - Escalate severe cases to senior management with documented rationale. ## Evidence to keep for supervisory and court scenarios A complaint workflow is only defensible if the company can later show what it received, how it assessed the issue, what follow up occurred, and how any remediation decision was made. This evidence is important for supervisory reviews and can matter in Article 29 litigation scenarios as well. Keep the file structured. Long email chains are not a control system. - Case chronology, participants, and decision record. - Basis for founded or unfounded assessment. - Remediation decision, actions taken, and monitoring follow up. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Grievance and remediation workflows across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Grievance and remediation workflows from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Grievance and remediation workflows](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Grievance and remediation workflows and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Grievance and remediation workflows. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [OECD Due Diligence Guidance for Responsible Business Conduct](https://www.oecd.org/content/dam/oecd/en/publications/reports/2018/05/oecd-due-diligence-guidance-for-responsible-business-conduct_81f92357/81f92357-en.pdf?ref=sorena.io) - Useful operating model reference because the Directive is built around risk based due diligence. - [UN Guiding Principles on Business and Human Rights](https://www.ohchr.org/sites/default/files/documents/publications/guidingprinciplesbusinesshr_en.pdf?ref=sorena.io) - Reference point for complaints design, remedy logic, and legitimate stakeholder engagement. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/grievance-and-remediation-workflows --- --- title: "EU CSDDD Liability and Penalties" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/liability-and-penalties" source_url: "https://www.sorena.io/artifacts/eu/csddd/liability-and-penalties" author: "Sorena AI" description: "Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD." keywords: - "EU CSDDD liability" - "CSDDD penalties" - "Article 27 fines" - "Article 29 civil liability" - "CSDDD 5 percent turnover" - "CSDDD limitation period five years" - "EU CSDDD" - "Civil liability" - "Penalties" - "Article 27" - "Article 29" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Liability and Penalties Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. *EU CSDDD* *Enforcement* ## EU CSDDD (Directive (EU) 2024/1760) Liability and penalties Supervisory penalties and civil liability are related, but they are not the same thing. This page shows how the two tracks interact so controls and records are built for both. The CSDDD uses two distinct but connected pressure points: supervisory enforcement under Articles 24 to 28 and civil liability under Article 29. Companies need to understand both because a program that is built only for supervisory reporting may still perform poorly in litigation, and vice versa. ## Supervisory action comes first more often than companies expect Each Member State must designate one or more supervisory authorities. Those authorities can require information, carry out investigations, and order cessation of infringements, remedial action, or penalties. Substantiated concerns can trigger attention even before a full investigation starts. A practical program therefore needs clear files for scope, prioritization, action plans, complaint handling, and remediation decisions. - Supervisory authorities can act on their own initiative or after substantiated concerns. - Cross border cooperation runs through the European Network of Supervisory Authorities. - Penalties do not block remedial orders and remedial orders do not remove civil liability risk. ## Article 27 penalties: the turnover point that boards notice Member States must set penalties that are effective, proportionate, and dissuasive. When pecuniary penalties are imposed, the maximum limit must be not less than 5 percent of the company net worldwide turnover in the financial year preceding the decision to impose the fine. For certain group structures, the calculation has to consider the consolidated turnover reported by the ultimate parent company. Penalty decisions also have to be published and stay publicly available for at least five years. - At least 5 percent maximum turnover cap for fines. - Publication of penalty decisions for at least five years. - Group turnover can matter for certain categories of company. *Recommended next step* *Placement: after the enforcement section* ## Use EU CSDDD (Directive (EU) 2024/1760) Liability and penalties as a cited research workflow Research Copilot can take EU CSDDD (Directive (EU) 2024/1760) Liability and penalties from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSDDD (Directive (EU) 2024/1760) Liability and penalties](/solutions/research-copilot.md): Start from EU CSDDD (Directive (EU) 2024/1760) Liability and penalties and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Liability and penalties. ## Article 29 civil liability: when damage claims arise Civil liability can arise where a company intentionally or negligently failed to comply with the obligations to prevent potential impacts or bring actual impacts to an end and that failure caused damage to a natural or legal person. The Directive gives a right to full compensation, but not overcompensation. The Directive also says a company cannot be held liable if the damage was caused only by its business partners in the chain of activities. That causation boundary matters when documenting leverage, action, and remediation decisions. - Focus records on causation, company role, and measures taken. - Keep evidence of why a severe impact was prioritized or not prioritized at a given time. - Document why suspension or termination was chosen or not chosen. ## Limitation periods and evidence retention Member States must ensure that limitation periods for damages actions are at least five years and are not more restrictive than the national general civil liability regime. That means a short lived document practice is a bad fit for the Directive. Preserve decision records, complaint files, supplier action plans, monitoring outputs, and remediation documents in a way that survives management turnover and business reorganizations. - Use retention periods that account for litigation horizon, not just supplier contract life. - Preserve drafts and approvals where they explain key due diligence choices. - Coordinate document retention and legal hold workflows early. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2024/1760 - Official Journal](https://eur-lex.europa.eu/eli/dir/2024/1760/oj/eng?ref=sorena.io) - Primary legal text for Articles 2 to 29, the Annex, and the original implementation architecture. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/liability-and-penalties --- --- title: "EU CSDDD Liability and Penalties" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/liability-and-penalties" source_url: "https://www.sorena.io/artifacts/eu/csddd/liability-and-penalties" author: "Sorena AI" description: "Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD." keywords: - "EU CSDDD liability" - "CSDDD penalties" - "Article 27 fines" - "Article 29 civil liability" - "CSDDD 5 percent turnover" - "CSDDD limitation period five years" - "EU CSDDD" - "Civil liability" - "Penalties" - "Article 27" - "Article 29" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Liability and Penalties Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. *EU CSDDD* *Enforcement* ## EU CSDDD (Directive (EU) 2024/1760) Liability and penalties Supervisory penalties and civil liability are related, but they are not the same thing. This page shows how the two tracks interact so controls and records are built for both. The CSDDD uses two distinct but connected pressure points: supervisory enforcement under Articles 24 to 28 and civil liability under Article 29. Companies need to understand both because a program that is built only for supervisory reporting may still perform poorly in litigation, and vice versa. ## Supervisory action comes first more often than companies expect Each Member State must designate one or more supervisory authorities. Those authorities can require information, carry out investigations, and order cessation of infringements, remedial action, or penalties. Substantiated concerns can trigger attention even before a full investigation starts. A practical program therefore needs clear files for scope, prioritization, action plans, complaint handling, and remediation decisions. - Supervisory authorities can act on their own initiative or after substantiated concerns. - Cross border cooperation runs through the European Network of Supervisory Authorities. - Penalties do not block remedial orders and remedial orders do not remove civil liability risk. ## Article 27 penalties: the turnover point that boards notice Member States must set penalties that are effective, proportionate, and dissuasive. When pecuniary penalties are imposed, the maximum limit must be not less than 5 percent of the company net worldwide turnover in the financial year preceding the decision to impose the fine. For certain group structures, the calculation has to consider the consolidated turnover reported by the ultimate parent company. Penalty decisions also have to be published and stay publicly available for at least five years. - At least 5 percent maximum turnover cap for fines. - Publication of penalty decisions for at least five years. - Group turnover can matter for certain categories of company. *Recommended next step* *Placement: after the enforcement section* ## Use EU CSDDD (Directive (EU) 2024/1760) Liability and penalties as a cited research workflow Research Copilot can take EU CSDDD (Directive (EU) 2024/1760) Liability and penalties from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSDDD (Directive (EU) 2024/1760) Liability and penalties](/solutions/research-copilot.md): Start from EU CSDDD (Directive (EU) 2024/1760) Liability and penalties and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Liability and penalties. ## Article 29 civil liability: when damage claims arise Civil liability can arise where a company intentionally or negligently failed to comply with the obligations to prevent potential impacts or bring actual impacts to an end and that failure caused damage to a natural or legal person. The Directive gives a right to full compensation, but not overcompensation. The Directive also says a company cannot be held liable if the damage was caused only by its business partners in the chain of activities. That causation boundary matters when documenting leverage, action, and remediation decisions. - Focus records on causation, company role, and measures taken. - Keep evidence of why a severe impact was prioritized or not prioritized at a given time. - Document why suspension or termination was chosen or not chosen. ## Limitation periods and evidence retention Member States must ensure that limitation periods for damages actions are at least five years and are not more restrictive than the national general civil liability regime. That means a short lived document practice is a bad fit for the Directive. Preserve decision records, complaint files, supplier action plans, monitoring outputs, and remediation documents in a way that survives management turnover and business reorganizations. - Use retention periods that account for litigation horizon, not just supplier contract life. - Preserve drafts and approvals where they explain key due diligence choices. - Coordinate document retention and legal hold workflows early. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2024/1760 - Official Journal](https://eur-lex.europa.eu/eli/dir/2024/1760/oj/eng?ref=sorena.io) - Primary legal text for Articles 2 to 29, the Annex, and the original implementation architecture. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/liability-and-penalties --- --- title: "EU CSDDD Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/csddd/penalties-and-fines" author: "Sorena AI" description: "Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means." keywords: - "EU CSDDD penalties" - "CSDDD fines" - "Article 27 CSDDD" - "CSDDD 5 percent turnover fine" - "CSDDD supervisory penalty publication" - "EU CSDDD" - "Penalties" - "Fines" - "Article 27" - "Supervisory authorities" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Penalties and Fines Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. *EU CSDDD* *Article 27* ## EU CSDDD (Directive (EU) 2024/1760) Penalties and fines A focused read on the administrative penalty side of the Directive. Use this when boards or legal teams ask what the fine exposure language actually means. Article 27 does not create one EU wide fine schedule. It obliges Member States to set national penalty rules that meet minimum characteristics and certain minimum severity requirements. The most important of those is the turnover linked maximum cap for pecuniary penalties. ## What Member States must provide Member States must lay down rules on penalties, including pecuniary penalties, for infringements of national law adopted under the Directive. Those penalties must be effective, proportionate, and dissuasive. This means the exact procedural details will differ by Member State after transposition, but the high level structure cannot be purely symbolic. - Expect national procedural variation. - Do not expect low consequence transposition only. - Track the national law in the Member State with the competent supervisory authority. ## The turnover benchmark that sets the ceiling floor When pecuniary penalties are imposed, the maximum limit must be not less than 5 percent of the company net worldwide turnover in the financial year preceding the decision to impose the fine. That is a floor for the national maximum cap, not the automatic fine in every case. For companies in certain parent company categories, the turnover basis must take into account consolidated turnover reported by the ultimate parent company. - The Directive sets the minimum severity of the national cap. - The actual fine will depend on national law and case facts. - Group structure can affect the turnover reference base. ## Factors that influence penalty level Article 27 requires Member States to take account of relevant circumstances when deciding whether to impose penalties and at what level. In practice, that means effort, cooperation, remediation, and prior conduct can matter once national laws are in place. The operational implication is simple: retain evidence of what the company did, when it did it, and how it responded once concerns were identified. - Keep chronology and decision records. - Record remediation and cooperation steps clearly. - Maintain evidence showing whether failures were isolated or systemic. ## Publication of penalty decisions Member States must ensure that supervisory authority decisions concerning penalties are published, remain publicly available for at least five years, and are sent to the European Network of Supervisory Authorities. That makes penalty exposure a reputational issue as well as a financial one. Companies should therefore prepare an external communications plan that aligns with the legal response plan. - Published decisions can shape investor and customer reactions. - Prepare response lines before a case arises. - Coordinate legal, compliance, and communications owners. *Recommended next step* *Placement: after the enforcement section* ## Use EU CSDDD (Directive (EU) 2024/1760) Penalties and fines as a cited research workflow Research Copilot can take EU CSDDD (Directive (EU) 2024/1760) Penalties and fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSDDD (Directive (EU) 2024/1760) Penalties and fines](/solutions/research-copilot.md): Start from EU CSDDD (Directive (EU) 2024/1760) Penalties and fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Penalties and fines. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2024/1760 - Official Journal](https://eur-lex.europa.eu/eli/dir/2024/1760/oj/eng?ref=sorena.io) - Primary legal text for Articles 2 to 29, the Annex, and the original implementation architecture. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/penalties-and-fines --- --- title: "EU CSDDD Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/csddd/penalties-and-fines" author: "Sorena AI" description: "Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means." keywords: - "EU CSDDD penalties" - "CSDDD fines" - "Article 27 CSDDD" - "CSDDD 5 percent turnover fine" - "CSDDD supervisory penalty publication" - "EU CSDDD" - "Penalties" - "Fines" - "Article 27" - "Supervisory authorities" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Penalties and Fines Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. *EU CSDDD* *Article 27* ## EU CSDDD (Directive (EU) 2024/1760) Penalties and fines A focused read on the administrative penalty side of the Directive. Use this when boards or legal teams ask what the fine exposure language actually means. Article 27 does not create one EU wide fine schedule. It obliges Member States to set national penalty rules that meet minimum characteristics and certain minimum severity requirements. The most important of those is the turnover linked maximum cap for pecuniary penalties. ## What Member States must provide Member States must lay down rules on penalties, including pecuniary penalties, for infringements of national law adopted under the Directive. Those penalties must be effective, proportionate, and dissuasive. This means the exact procedural details will differ by Member State after transposition, but the high level structure cannot be purely symbolic. - Expect national procedural variation. - Do not expect low consequence transposition only. - Track the national law in the Member State with the competent supervisory authority. ## The turnover benchmark that sets the ceiling floor When pecuniary penalties are imposed, the maximum limit must be not less than 5 percent of the company net worldwide turnover in the financial year preceding the decision to impose the fine. That is a floor for the national maximum cap, not the automatic fine in every case. For companies in certain parent company categories, the turnover basis must take into account consolidated turnover reported by the ultimate parent company. - The Directive sets the minimum severity of the national cap. - The actual fine will depend on national law and case facts. - Group structure can affect the turnover reference base. ## Factors that influence penalty level Article 27 requires Member States to take account of relevant circumstances when deciding whether to impose penalties and at what level. In practice, that means effort, cooperation, remediation, and prior conduct can matter once national laws are in place. The operational implication is simple: retain evidence of what the company did, when it did it, and how it responded once concerns were identified. - Keep chronology and decision records. - Record remediation and cooperation steps clearly. - Maintain evidence showing whether failures were isolated or systemic. ## Publication of penalty decisions Member States must ensure that supervisory authority decisions concerning penalties are published, remain publicly available for at least five years, and are sent to the European Network of Supervisory Authorities. That makes penalty exposure a reputational issue as well as a financial one. Companies should therefore prepare an external communications plan that aligns with the legal response plan. - Published decisions can shape investor and customer reactions. - Prepare response lines before a case arises. - Coordinate legal, compliance, and communications owners. *Recommended next step* *Placement: after the enforcement section* ## Use EU CSDDD (Directive (EU) 2024/1760) Penalties and fines as a cited research workflow Research Copilot can take EU CSDDD (Directive (EU) 2024/1760) Penalties and fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSDDD (Directive (EU) 2024/1760) Penalties and fines](/solutions/research-copilot.md): Start from EU CSDDD (Directive (EU) 2024/1760) Penalties and fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Penalties and fines. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2024/1760 - Official Journal](https://eur-lex.europa.eu/eli/dir/2024/1760/oj/eng?ref=sorena.io) - Primary legal text for Articles 2 to 29, the Annex, and the original implementation architecture. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/penalties-and-fines --- --- title: "EU CSDDD Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/requirements" source_url: "https://www.sorena.io/artifacts/eu/csddd/requirements" author: "Sorena AI" description: "Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization." keywords: - "EU CSDDD requirements" - "CSDDD article by article" - "Article 7 policy" - "Article 8 identification" - "Article 9 prioritization" - "Article 14 complaints" - "Article 22 climate transition plan" - "EU CSDDD" - "Requirements" - "Articles 7 to 17" - "Article 22" - "Compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Requirements Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. *EU CSDDD* *Requirements* ## EU CSDDD (Directive (EU) 2024/1760) Requirements overview Use this page when you need the shortest route from article text to implementation workstream. The goal is not to list every recital. It is to map the operative duties to what teams must build. The Directive is easiest to operate when it is broken into requirement tracks. The article map below shows what each major cluster requires, what it produces, and which internal teams usually own it. ## Track 1: scope, policy, and structure Article 2 sets scope. Article 6 and Article 7 shape how obligations can be performed at group level and how due diligence must be integrated into policies and risk management. This track decides who is responsible and what the program architecture looks like. Without this track, later measures drift because teams are not using the same entity perimeter or governance model. - Outputs: scope memo, group performance model, due diligence policy, code of conduct. - Key articles: Articles 2, 6, and 7. - Core teams: legal, governance, compliance, ESG. ## Track 2: impact identification and prioritization Articles 8 and 9 require identification, assessment, and prioritization of actual and potential adverse impacts. The work must use quantitative and qualitative information and should reflect severity and likelihood where not all impacts can be addressed at once. This is the analytical core of the Directive and the basis for later supplier action and remediation decisions. - Outputs: chain-of-activities register, risk map, in depth assessments, prioritization register. - Key articles: Articles 8 and 9. - Core teams: procurement, ESG, operations, risk, internal audit. ## Track 3: prevention, correction, and remediation Articles 10 to 12 are where the Directive expects visible action. Potential impacts need prevention and mitigation. Actual impacts need corrective action, and in some cases remediation. Contractual assurances are relevant but must be backed by verification and action logic. This track is where supplier plans, leverage strategy, responsible disengagement, and remediation governance should all connect. - Outputs: prevention plans, corrective action plans, contract clauses, remediation files. - Key articles: Articles 10, 11, and 12. - Core teams: procurement, legal, supplier quality, operations. ## Track 4: stakeholders, complaints, monitoring, and communication Articles 13 to 17 require stakeholder engagement, a complaints procedure, monitoring, annual communication, and ESAP related publication mechanics. These duties create a public and reviewable interface to the program. Weakness here often signals that the company built a supplier assessment process but not a full due diligence system. - Outputs: stakeholder log, complaints workflow, annual review, annual statement, ESAP process. - Key articles: Articles 13 to 17. - Core teams: compliance, legal, communications, ESG, reporting. ## Track 5: climate and enforcement architecture Article 22 requires the climate transition plan. Articles 23 to 29 create the authorized representative, supervisory authority, penalty, network cooperation, and civil liability architecture around the due diligence duty. This track tells you how the program will be scrutinized and what kinds of failures will create legal consequences. - Outputs: Article 22 plan, supervisory response pack, retention and litigation support controls. - Key articles: Articles 22 to 29. - Core teams: sustainability, legal, compliance, finance, executive leadership. *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Requirements overview across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Requirements overview from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Requirements overview](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Requirements overview and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Requirements overview. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/requirements --- --- title: "EU CSDDD Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/requirements" source_url: "https://www.sorena.io/artifacts/eu/csddd/requirements" author: "Sorena AI" description: "Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization." keywords: - "EU CSDDD requirements" - "CSDDD article by article" - "Article 7 policy" - "Article 8 identification" - "Article 9 prioritization" - "Article 14 complaints" - "Article 22 climate transition plan" - "EU CSDDD" - "Requirements" - "Articles 7 to 17" - "Article 22" - "Compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Requirements Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. *EU CSDDD* *Requirements* ## EU CSDDD (Directive (EU) 2024/1760) Requirements overview Use this page when you need the shortest route from article text to implementation workstream. The goal is not to list every recital. It is to map the operative duties to what teams must build. The Directive is easiest to operate when it is broken into requirement tracks. The article map below shows what each major cluster requires, what it produces, and which internal teams usually own it. ## Track 1: scope, policy, and structure Article 2 sets scope. Article 6 and Article 7 shape how obligations can be performed at group level and how due diligence must be integrated into policies and risk management. This track decides who is responsible and what the program architecture looks like. Without this track, later measures drift because teams are not using the same entity perimeter or governance model. - Outputs: scope memo, group performance model, due diligence policy, code of conduct. - Key articles: Articles 2, 6, and 7. - Core teams: legal, governance, compliance, ESG. ## Track 2: impact identification and prioritization Articles 8 and 9 require identification, assessment, and prioritization of actual and potential adverse impacts. The work must use quantitative and qualitative information and should reflect severity and likelihood where not all impacts can be addressed at once. This is the analytical core of the Directive and the basis for later supplier action and remediation decisions. - Outputs: chain-of-activities register, risk map, in depth assessments, prioritization register. - Key articles: Articles 8 and 9. - Core teams: procurement, ESG, operations, risk, internal audit. ## Track 3: prevention, correction, and remediation Articles 10 to 12 are where the Directive expects visible action. Potential impacts need prevention and mitigation. Actual impacts need corrective action, and in some cases remediation. Contractual assurances are relevant but must be backed by verification and action logic. This track is where supplier plans, leverage strategy, responsible disengagement, and remediation governance should all connect. - Outputs: prevention plans, corrective action plans, contract clauses, remediation files. - Key articles: Articles 10, 11, and 12. - Core teams: procurement, legal, supplier quality, operations. ## Track 4: stakeholders, complaints, monitoring, and communication Articles 13 to 17 require stakeholder engagement, a complaints procedure, monitoring, annual communication, and ESAP related publication mechanics. These duties create a public and reviewable interface to the program. Weakness here often signals that the company built a supplier assessment process but not a full due diligence system. - Outputs: stakeholder log, complaints workflow, annual review, annual statement, ESAP process. - Key articles: Articles 13 to 17. - Core teams: compliance, legal, communications, ESG, reporting. ## Track 5: climate and enforcement architecture Article 22 requires the climate transition plan. Articles 23 to 29 create the authorized representative, supervisory authority, penalty, network cooperation, and civil liability architecture around the due diligence duty. This track tells you how the program will be scrutinized and what kinds of failures will create legal consequences. - Outputs: Article 22 plan, supervisory response pack, retention and litigation support controls. - Key articles: Articles 22 to 29. - Core teams: sustainability, legal, compliance, finance, executive leadership. *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU CSDDD (Directive (EU) 2024/1760) Requirements overview across ESG workflows ESG Compliance can take EU CSDDD (Directive (EU) 2024/1760) Requirements overview from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSDDD (Directive (EU) 2024/1760) Requirements overview](/solutions/esg-compliance.md): Start from EU CSDDD (Directive (EU) 2024/1760) Requirements overview and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Requirements overview. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/requirements --- --- title: "EU CSDDD Scope Thresholds and In Scope Groups" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups" source_url: "https://www.sorena.io/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups" author: "Sorena AI" description: "Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers." keywords: - "EU CSDDD thresholds" - "CSDDD in scope groups" - "CSDDD 1000 employees 450 million" - "CSDDD royalties 22.5 million 80 million" - "CSDDD 2028 2029 waves" - "EU CSDDD" - "Scope thresholds" - "In scope groups" - "Directive (EU) 2025/794" - "Applicability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Scope Thresholds and In Scope Groups Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. *EU CSDDD* *Scope* ## EU CSDDD (Directive (EU) 2024/1760) Scope thresholds and in scope groups This page is for the exact thresholds and group categories, not the general summary. Use it to build the scope section of your legal memo and the cover sheet for the due diligence program. The Directive creates three main scope routes that matter in practice: the main EU company threshold, the non-EU Union turnover threshold, and the franchising or licensing route. The current rollout dates also depend on which threshold band the company falls into. ## Main scope cohort: EU companies and EU headed groups The general EU threshold is more than 1000 employees on average and more than EUR 450 million net worldwide turnover. The same logic can apply at ultimate parent group level where the group as a whole reaches the conditions. This is the default route most large operating groups will analyze first. - Employee threshold: more than 1000 on average. - Turnover threshold: more than EUR 450 million worldwide. - Relevant both for operating companies and certain ultimate parent structures. *Recommended next step* *Placement: after the scope or definition section* ## Use EU CSDDD (Directive (EU) 2024/1760) Scope thresholds and in scope groups as a cited research workflow Research Copilot can take EU CSDDD (Directive (EU) 2024/1760) Scope thresholds and in scope groups from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSDDD (Directive (EU) 2024/1760) Scope thresholds and in scope groups](/solutions/research-copilot.md): Start from EU CSDDD (Directive (EU) 2024/1760) Scope thresholds and in scope groups and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Scope thresholds and in scope groups. ## Non-EU companies with sufficient Union turnover Third-country companies are tested by Union turnover rather than employee count. The main trigger is more than EUR 450 million net turnover generated in the Union in the relevant lookback period. This is why non-EU headquartered groups with strong EU sales should not assume the Directive is only for Union incorporated companies. - Employee count is not the decisive trigger here. - Union turnover methodology should be documented carefully. - Authorized representative obligations can follow. ## Franchising and licensing route The Directive separately captures companies and groups where franchising or licensing agreements in the Union create a common identity, a common business concept, and uniform business methods, with royalties above EUR 22.5 million and turnover above EUR 80 million. This route matters for consumer brand, retail, and network models that otherwise look smaller on an employee basis. - Royalties threshold: more than EUR 22.5 million. - Turnover threshold: more than EUR 80 million. - Check both the economic numbers and the contractual business model features. ## Current application waves after the 2025 amendment The amended timing now has a first wave from 26 July 2028 and broader application from 26 July 2029. The first wave covers the largest EU and non-EU turnover bands. The remaining in-scope categories follow from 26 July 2029. Use the amended dates in all planning documents and mark the original dates as superseded. - 26 July 2028: more than 5000 employees and more than EUR 1.5 billion turnover, and the matching non-EU EU-turnover band. - 26 July 2029: all other in-scope companies including the EUR 450 million band and the qualifying royalties route. - 26 July 2027 remains the transposition deadline, not the first company application date. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups --- --- title: "EU CSDDD Scope Thresholds and In Scope Groups" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups" source_url: "https://www.sorena.io/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups" author: "Sorena AI" description: "Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers." keywords: - "EU CSDDD thresholds" - "CSDDD in scope groups" - "CSDDD 1000 employees 450 million" - "CSDDD royalties 22.5 million 80 million" - "CSDDD 2028 2029 waves" - "EU CSDDD" - "Scope thresholds" - "In scope groups" - "Directive (EU) 2025/794" - "Applicability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Scope Thresholds and In Scope Groups Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. *EU CSDDD* *Scope* ## EU CSDDD (Directive (EU) 2024/1760) Scope thresholds and in scope groups This page is for the exact thresholds and group categories, not the general summary. Use it to build the scope section of your legal memo and the cover sheet for the due diligence program. The Directive creates three main scope routes that matter in practice: the main EU company threshold, the non-EU Union turnover threshold, and the franchising or licensing route. The current rollout dates also depend on which threshold band the company falls into. ## Main scope cohort: EU companies and EU headed groups The general EU threshold is more than 1000 employees on average and more than EUR 450 million net worldwide turnover. The same logic can apply at ultimate parent group level where the group as a whole reaches the conditions. This is the default route most large operating groups will analyze first. - Employee threshold: more than 1000 on average. - Turnover threshold: more than EUR 450 million worldwide. - Relevant both for operating companies and certain ultimate parent structures. *Recommended next step* *Placement: after the scope or definition section* ## Use EU CSDDD (Directive (EU) 2024/1760) Scope thresholds and in scope groups as a cited research workflow Research Copilot can take EU CSDDD (Directive (EU) 2024/1760) Scope thresholds and in scope groups from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSDDD (Directive (EU) 2024/1760) Scope thresholds and in scope groups](/solutions/research-copilot.md): Start from EU CSDDD (Directive (EU) 2024/1760) Scope thresholds and in scope groups and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Scope thresholds and in scope groups. ## Non-EU companies with sufficient Union turnover Third-country companies are tested by Union turnover rather than employee count. The main trigger is more than EUR 450 million net turnover generated in the Union in the relevant lookback period. This is why non-EU headquartered groups with strong EU sales should not assume the Directive is only for Union incorporated companies. - Employee count is not the decisive trigger here. - Union turnover methodology should be documented carefully. - Authorized representative obligations can follow. ## Franchising and licensing route The Directive separately captures companies and groups where franchising or licensing agreements in the Union create a common identity, a common business concept, and uniform business methods, with royalties above EUR 22.5 million and turnover above EUR 80 million. This route matters for consumer brand, retail, and network models that otherwise look smaller on an employee basis. - Royalties threshold: more than EUR 22.5 million. - Turnover threshold: more than EUR 80 million. - Check both the economic numbers and the contractual business model features. ## Current application waves after the 2025 amendment The amended timing now has a first wave from 26 July 2028 and broader application from 26 July 2029. The first wave covers the largest EU and non-EU turnover bands. The remaining in-scope categories follow from 26 July 2029. Use the amended dates in all planning documents and mark the original dates as superseded. - 26 July 2028: more than 5000 employees and more than EUR 1.5 billion turnover, and the matching non-EU EU-turnover band. - 26 July 2029: all other in-scope companies including the EUR 450 million band and the qualifying royalties route. - 26 July 2027 remains the transposition deadline, not the first company application date. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [Directive (EU) 2025/794 - timing amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the postponed transposition deadline and postponed first wave of application. - [European Commission - Corporate sustainability due diligence](https://commission.europa.eu/business-economy-euro/doing-business-eu/sustainability-due-diligence-responsible-business/corporate-sustainability-due-diligence_en?ref=sorena.io) - Official implementation overview, including the status of the 2025 Omnibus proposals. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Supplier Human Rights Risk Scoring Template | Severity and Likelihood Model](/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template.md): Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups --- --- title: "EU CSDDD Supplier Human Rights Risk Scoring Template" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template" source_url: "https://www.sorena.io/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template" author: "Sorena AI" description: "Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector." keywords: - "EU CSDDD supplier risk scoring" - "CSDDD severity likelihood template" - "CSDDD human rights risk scoring" - "CSDDD prioritization model" - "Articles 8 and 9 CSDDD" - "EU CSDDD" - "Risk scoring" - "Supplier due diligence" - "Severity and likelihood" - "Prioritization" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Supplier Human Rights Risk Scoring Template Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. *EU CSDDD* *Template* ## EU CSDDD (Directive (EU) 2024/1760) Supplier human rights risk scoring template This page gives you the scoring logic the Directive expects, not a generic vendor scorecard. Use it to justify prioritization decisions and to direct deeper assessment where it matters most. Article 8 requires identification and assessment of actual and potential adverse impacts. Article 9 requires prioritization where not every impact can be addressed at once. That means the scoring method has to be risk based, evidence linked, and capable of explaining why some suppliers or activity clusters received immediate attention. ## Score block 1: severity Severity should capture scale, scope, and irremediable character. The question is not just how likely a problem is, but how serious the consequence would be for the affected people if it occurs or continues. Use a written scale that forces the assessor to explain why a case is low, medium, high, or critical rather than just assigning numbers. - Scale: how grave the harm could be. - Scope: how many people or communities could be affected. - Irremediable character: how hard it would be to restore the situation. ## Score block 2: likelihood Likelihood should consider the probability that an impact exists already or may arise, based on available evidence and risk indicators. This includes partner history, sector exposures, geographic context, public reporting, grievance data, and the strength of local law enforcement. Do not treat missing data as low risk. Missing data is often a reason to increase scrutiny, not to lower the score. - Use both current incident evidence and forward looking risk signals. - Record data quality and uncertainty separately from the main score. - Escalate where multiple weak signals point in the same direction. ## Score block 3: contextual modifiers The recitals point to several risk factor categories companies should consider, including company level, business operation, geographic, product and service, and sectoral risk factors. Purchasing and pricing practices can also matter where they contribute to pressure in the chain. These factors should not replace severity and likelihood. They should help explain why the same raw signal may be more worrying in one context than another. - Company level: maturity, past incidents, and cooperation quality. - Geographic and sectoral: enforcement environment and known structural risks. - Commercial pressure: pricing, lead times, and purchasing behavior that can drive abuse. ## Template outputs you should keep The scoring template should produce more than a red amber green label. It should show the chain activity involved, the rationale for the score, the current evidence base, and the required next action such as deeper assessment, corrective action, increased monitoring, or remediation review. That way the prioritization register can stand up to internal challenge and external review. - Partner or activity identifier and chain-of-activities link. - Severity score, likelihood score, and narrative rationale. - Required next action and review date. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Use EU CSDDD (Directive (EU) 2024/1760) Supplier human rights risk scoring template as a cited research workflow Research Copilot can take EU CSDDD (Directive (EU) 2024/1760) Supplier human rights risk scoring template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSDDD (Directive (EU) 2024/1760) Supplier human rights risk scoring template](/solutions/research-copilot.md): Start from EU CSDDD (Directive (EU) 2024/1760) Supplier human rights risk scoring template and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Supplier human rights risk scoring template. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [OECD Due Diligence Guidance for Responsible Business Conduct](https://www.oecd.org/content/dam/oecd/en/publications/reports/2018/05/oecd-due-diligence-guidance-for-responsible-business-conduct_81f92357/81f92357-en.pdf?ref=sorena.io) - Useful operating model reference because the Directive is built around risk based due diligence. - [UN Guiding Principles on Business and Human Rights](https://www.ohchr.org/sites/default/files/documents/publications/guidingprinciplesbusinesshr_en.pdf?ref=sorena.io) - Reference point for complaints design, remedy logic, and legitimate stakeholder engagement. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template --- --- title: "EU CSDDD Supplier Human Rights Risk Scoring Template" canonical_url: "https://www.sorena.io/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template" source_url: "https://www.sorena.io/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template" author: "Sorena AI" description: "Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector." keywords: - "EU CSDDD supplier risk scoring" - "CSDDD severity likelihood template" - "CSDDD human rights risk scoring" - "CSDDD prioritization model" - "Articles 8 and 9 CSDDD" - "EU CSDDD" - "Risk scoring" - "Supplier due diligence" - "Severity and likelihood" - "Prioritization" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSDDD Supplier Human Rights Risk Scoring Template Use this practical CSDDD risk scoring template to prioritize supplier and partner risk based on severity, likelihood, geographic factors, sector. *EU CSDDD* *Template* ## EU CSDDD (Directive (EU) 2024/1760) Supplier human rights risk scoring template This page gives you the scoring logic the Directive expects, not a generic vendor scorecard. Use it to justify prioritization decisions and to direct deeper assessment where it matters most. Article 8 requires identification and assessment of actual and potential adverse impacts. Article 9 requires prioritization where not every impact can be addressed at once. That means the scoring method has to be risk based, evidence linked, and capable of explaining why some suppliers or activity clusters received immediate attention. ## Score block 1: severity Severity should capture scale, scope, and irremediable character. The question is not just how likely a problem is, but how serious the consequence would be for the affected people if it occurs or continues. Use a written scale that forces the assessor to explain why a case is low, medium, high, or critical rather than just assigning numbers. - Scale: how grave the harm could be. - Scope: how many people or communities could be affected. - Irremediable character: how hard it would be to restore the situation. ## Score block 2: likelihood Likelihood should consider the probability that an impact exists already or may arise, based on available evidence and risk indicators. This includes partner history, sector exposures, geographic context, public reporting, grievance data, and the strength of local law enforcement. Do not treat missing data as low risk. Missing data is often a reason to increase scrutiny, not to lower the score. - Use both current incident evidence and forward looking risk signals. - Record data quality and uncertainty separately from the main score. - Escalate where multiple weak signals point in the same direction. ## Score block 3: contextual modifiers The recitals point to several risk factor categories companies should consider, including company level, business operation, geographic, product and service, and sectoral risk factors. Purchasing and pricing practices can also matter where they contribute to pressure in the chain. These factors should not replace severity and likelihood. They should help explain why the same raw signal may be more worrying in one context than another. - Company level: maturity, past incidents, and cooperation quality. - Geographic and sectoral: enforcement environment and known structural risks. - Commercial pressure: pricing, lead times, and purchasing behavior that can drive abuse. ## Template outputs you should keep The scoring template should produce more than a red amber green label. It should show the chain activity involved, the rationale for the score, the current evidence base, and the required next action such as deeper assessment, corrective action, increased monitoring, or remediation review. That way the prioritization register can stand up to internal challenge and external review. - Partner or activity identifier and chain-of-activities link. - Severity score, likelihood score, and narrative rationale. - Required next action and review date. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Use EU CSDDD (Directive (EU) 2024/1760) Supplier human rights risk scoring template as a cited research workflow Research Copilot can take EU CSDDD (Directive (EU) 2024/1760) Supplier human rights risk scoring template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU CSDDD (Directive (EU) 2024/1760) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSDDD (Directive (EU) 2024/1760) Supplier human rights risk scoring template](/solutions/research-copilot.md): Start from EU CSDDD (Directive (EU) 2024/1760) Supplier human rights risk scoring template and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSDDD (Directive (EU) 2024/1760)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSDDD (Directive (EU) 2024/1760) Supplier human rights risk scoring template. ## Primary sources - [Directive (EU) 2024/1760 - Consolidated text as of 17 April 2025](https://eur-lex.europa.eu/eli/dir/2024/1760/2025-04-17/eng?ref=sorena.io) - Best source for the current operative wording after the 2025 timing amendment. - [OECD Due Diligence Guidance for Responsible Business Conduct](https://www.oecd.org/content/dam/oecd/en/publications/reports/2018/05/oecd-due-diligence-guidance-for-responsible-business-conduct_81f92357/81f92357-en.pdf?ref=sorena.io) - Useful operating model reference because the Directive is built around risk based due diligence. - [UN Guiding Principles on Business and Human Rights](https://www.ohchr.org/sites/default/files/documents/publications/guidingprinciplesbusinesshr_en.pdf?ref=sorena.io) - Reference point for complaints design, remedy logic, and legitimate stakeholder engagement. ## Related Topic Guides - [EU CSDDD Applicability Test | Thresholds, Group Scope, and Start Dates](/artifacts/eu/csddd/applicability-test.md): Use this CSDDD applicability test to check the 1000 employee and EUR 450 million threshold, franchising and licensing triggers, non-EU EU-turnover rules. - [EU CSDDD Chain of Activities and Supplier Scope | Upstream, Downstream, and Boundary Rules](/artifacts/eu/csddd/chain-of-activities-and-suppliers.md): Map the CSDDD chain of activities correctly. This guide explains upstream and downstream coverage, direct and indirect business partners. - [EU CSDDD Checklist | Practical Due Diligence Checklist by Workstream](/artifacts/eu/csddd/checklist.md): Use this CSDDD checklist to move from scope to execution. - [EU CSDDD Climate Transition Plan | Article 22 Requirements and Practical Structure](/artifacts/eu/csddd/climate-transition-plan.md): Understand the Article 22 climate transition plan duty under the CSDDD. - [EU CSDDD Compliance Guide | Operating Model, Evidence, and Readiness](/artifacts/eu/csddd/compliance.md): Build a real CSDDD compliance program. This guide explains how to turn Directive (EU) 2024/1760 into a due diligence operating model across policy, mapping. - [EU CSDDD Deadlines and Compliance Calendar | Current Dates after Directive (EU) 2025/794](/artifacts/eu/csddd/deadlines-and-compliance-calendar.md): Track the current CSDDD rollout dates, including the 25 July 2024 entry into force, 26 July 2027 transposition deadline, 31 March 2027 reporting act deadline. - [EU CSDDD Due Diligence Steps Playbook | Articles 7 to 15 in Practical Order](/artifacts/eu/csddd/due-diligence-steps-playbook.md): Follow the CSDDD due diligence steps in the order teams actually need to execute them: policy, chain mapping, prioritization, prevention, corrective action. - [EU CSDDD FAQ | Current Answers on Scope, Dates, Complaints, Penalties, and Climate Plans](/artifacts/eu/csddd/faq.md): Get grounded answers to common CSDDD questions, including the current application dates, who is in scope, how the chain of activities works. - [EU CSDDD Grievance and Remediation Workflows | Articles 12 to 14 in Practice](/artifacts/eu/csddd/grievance-and-remediation-workflows.md): Design a CSDDD grievance and remediation workflow that fits Articles 12 to 14. - [EU CSDDD Liability and Penalties | Civil Liability, Fines, and Supervisory Action](/artifacts/eu/csddd/liability-and-penalties.md): Understand how Article 27 penalties and Article 29 civil liability interact under the CSDDD. - [EU CSDDD Penalties and Fines | Article 27 Explained Clearly](/artifacts/eu/csddd/penalties-and-fines.md): Focus on Article 27 of the CSDDD. This page explains how Member States must structure penalties, what the at least 5 percent maximum turnover cap means. - [EU CSDDD Requirements | Article by Article Requirement Map](/artifacts/eu/csddd/requirements.md): Map the main CSDDD requirements by article, including Article 7 policy, Article 8 identification, Article 9 prioritization. - [EU CSDDD Scope Thresholds and In Scope Groups | Current Thresholds and Waves](/artifacts/eu/csddd/scope-thresholds-and-in-scope-groups.md): Review the current CSDDD scope thresholds, in scope company groups, franchising and licensing rules, non-EU turnover triggers. - [EU CSDDD vs CSRD | Due Diligence Duties versus Sustainability Reporting](/artifacts/eu/csddd/csddd-vs-csrd.md): Compare the EU CSDDD and CSRD the right way. This guide explains how due diligence duties under Directive (EU) 2024/1760 differ from sustainability reporting. - [EU CSDDD vs German LkSG | Scope, Chain Rules, and Enforcement Differences](/artifacts/eu/csddd/csddd-vs-german-lksg.md): Compare the EU CSDDD with the German LkSG using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csddd/supplier-human-rights-risk-scoring-template --- --- title: "EU CSRD Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/csrd/applicability-test" author: "Sorena AI" description: "Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies." keywords: - "EU CSRD applicability test" - "CSRD scope" - "CSRD wave 1 wave 2 wave 3" - "Directive (EU) 2025/794 CSRD" - "CSRD listed SME" - "CSRD third country undertaking" - "EU CSRD" - "Applicability test" - "Reporting wave" - "Scope" - "ESRS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Applicability Test Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. *EU CSRD* *Scope Test* ## EU CSRD (Directive (EU) 2022/2464) Applicability test A scope test designed to produce a real decision memo, not just a yes or no. Use one file to record entity category, group position, exemption logic, and the first reporting year that actually applies. The CSRD scope question is not only about whether an entity is large or listed. You also need to test whether it was already in the legacy NFRD population, whether it is an issuer on a regulated market, whether a parent level exemption applies, whether the entity is a listed SME with an opt out, and whether a third-country undertaking reporting path could apply later. ## Step 1: classify the entity correctly before you touch the wave chart Start with the Accounting Directive definitions. Distinguish large undertakings, small and medium sized undertakings, micro undertakings, public interest entities, and parent undertakings of large groups. The answer will drive both scope and the management report structure that is expected. Do this at legal entity and group level. The most common CSRD mistake is mixing a group conclusion with a subsidiary conclusion and assuming the same answer applies to both. - Keep the large undertaking and group classification calculation. - Record whether the entity is a public interest entity and whether securities are admitted to trading on a regulated market. - Note whether the entity sits inside a parent reporting perimeter that could support an exemption route. ## Step 2: assign the current reporting wave, not the original one Wave one still covers the legacy NFRD style population for financial years starting on or after 1 January 2024. The stop the clock amendment changed the later waves. The second wave now starts with financial years beginning on or after 1 January 2027. The listed SME wave now starts with financial years beginning on or after 1 January 2028. If your internal roadmap still shows 1 January 2025 and 1 January 2026 for those later waves, it is already out of date. - Wave 1: financial years starting on or after 1 January 2024 for large public interest entities exceeding 500 employees and the matching parent group category. - Wave 2: financial years starting on or after 1 January 2027 for other large undertakings and other parent undertakings of large groups. - Wave 3: financial years starting on or after 1 January 2028 for listed SMEs that are not micro undertakings, certain small and non-complex institutions, and certain captive insurance categories. ## Step 3: decide whether the listed SME opt out is relevant Listed SMEs have a transitional opt out period. That may delay the obligation in practice, but it should still be treated as a strategic choice rather than a default shortcut. Capital markets, lenders, and group level information demands may still force preparation work well before the last possible date. A good memo records whether the opt out is legally available, whether management plans to use it, and what data preparation will continue anyway. - Document opt out availability and the current end of the transition period under the amended law. - Keep a board or management decision if the opt out is used. - Separate legal deferral from operational readiness choices. ## Step 4: test the exemption and third-country routes separately The exemption analysis and the third-country undertaking route should not be mixed into the main scope decision. Group exemptions depend on parent reporting conditions and access to the relevant reports and assurance opinions. The third-country route has its own threshold logic and later reporting timetable. Treat both as separate workstreams in the memo, even if the current answer is not applicable. - Write down whether a parent reporting exemption is being used and why it is valid. - Track the third-country undertaking route for groups with material EU turnover, branches, or large EU subsidiaries. - Link the scope memo to publication, assurance, and digital filing obligations. *Recommended next step* *Placement: after the applicability result* ## Operationalize EU CSRD (Directive (EU) 2022/2464) Applicability test across ESG workflows ESG Compliance can take EU CSRD (Directive (EU) 2022/2464) Applicability test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSRD (Directive (EU) 2022/2464) Applicability test](/solutions/esg-compliance.md): Start from EU CSRD (Directive (EU) 2022/2464) Applicability test and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Applicability test. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Directive (EU) 2025/794 - stop the clock amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the two year postponement of the second and third CSRD reporting waves. - [Directive 2013/34/EU - Accounting Directive](https://eur-lex.europa.eu/eli/dir/2013/34/oj/eng?ref=sorena.io) - Source for large undertaking, group, and management report definitions that the CSRD amends. - [European Commission - Corporate sustainability reporting](https://finance.ec.europa.eu/capital-markets-union-and-financial-markets/company-reporting-and-auditing/company-reporting/corporate-sustainability-reporting_en?ref=sorena.io) - Official implementation overview for the CSRD, ESRS, quick fix, and related Omnibus developments. ## Related Topic Guides - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/applicability-test --- --- title: "EU CSRD Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/csrd/applicability-test" author: "Sorena AI" description: "Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies." keywords: - "EU CSRD applicability test" - "CSRD scope" - "CSRD wave 1 wave 2 wave 3" - "Directive (EU) 2025/794 CSRD" - "CSRD listed SME" - "CSRD third country undertaking" - "EU CSRD" - "Applicability test" - "Reporting wave" - "Scope" - "ESRS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Applicability Test Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. *EU CSRD* *Scope Test* ## EU CSRD (Directive (EU) 2022/2464) Applicability test A scope test designed to produce a real decision memo, not just a yes or no. Use one file to record entity category, group position, exemption logic, and the first reporting year that actually applies. The CSRD scope question is not only about whether an entity is large or listed. You also need to test whether it was already in the legacy NFRD population, whether it is an issuer on a regulated market, whether a parent level exemption applies, whether the entity is a listed SME with an opt out, and whether a third-country undertaking reporting path could apply later. ## Step 1: classify the entity correctly before you touch the wave chart Start with the Accounting Directive definitions. Distinguish large undertakings, small and medium sized undertakings, micro undertakings, public interest entities, and parent undertakings of large groups. The answer will drive both scope and the management report structure that is expected. Do this at legal entity and group level. The most common CSRD mistake is mixing a group conclusion with a subsidiary conclusion and assuming the same answer applies to both. - Keep the large undertaking and group classification calculation. - Record whether the entity is a public interest entity and whether securities are admitted to trading on a regulated market. - Note whether the entity sits inside a parent reporting perimeter that could support an exemption route. ## Step 2: assign the current reporting wave, not the original one Wave one still covers the legacy NFRD style population for financial years starting on or after 1 January 2024. The stop the clock amendment changed the later waves. The second wave now starts with financial years beginning on or after 1 January 2027. The listed SME wave now starts with financial years beginning on or after 1 January 2028. If your internal roadmap still shows 1 January 2025 and 1 January 2026 for those later waves, it is already out of date. - Wave 1: financial years starting on or after 1 January 2024 for large public interest entities exceeding 500 employees and the matching parent group category. - Wave 2: financial years starting on or after 1 January 2027 for other large undertakings and other parent undertakings of large groups. - Wave 3: financial years starting on or after 1 January 2028 for listed SMEs that are not micro undertakings, certain small and non-complex institutions, and certain captive insurance categories. ## Step 3: decide whether the listed SME opt out is relevant Listed SMEs have a transitional opt out period. That may delay the obligation in practice, but it should still be treated as a strategic choice rather than a default shortcut. Capital markets, lenders, and group level information demands may still force preparation work well before the last possible date. A good memo records whether the opt out is legally available, whether management plans to use it, and what data preparation will continue anyway. - Document opt out availability and the current end of the transition period under the amended law. - Keep a board or management decision if the opt out is used. - Separate legal deferral from operational readiness choices. ## Step 4: test the exemption and third-country routes separately The exemption analysis and the third-country undertaking route should not be mixed into the main scope decision. Group exemptions depend on parent reporting conditions and access to the relevant reports and assurance opinions. The third-country route has its own threshold logic and later reporting timetable. Treat both as separate workstreams in the memo, even if the current answer is not applicable. - Write down whether a parent reporting exemption is being used and why it is valid. - Track the third-country undertaking route for groups with material EU turnover, branches, or large EU subsidiaries. - Link the scope memo to publication, assurance, and digital filing obligations. *Recommended next step* *Placement: after the applicability result* ## Operationalize EU CSRD (Directive (EU) 2022/2464) Applicability test across ESG workflows ESG Compliance can take EU CSRD (Directive (EU) 2022/2464) Applicability test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSRD (Directive (EU) 2022/2464) Applicability test](/solutions/esg-compliance.md): Start from EU CSRD (Directive (EU) 2022/2464) Applicability test and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Applicability test. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Directive (EU) 2025/794 - stop the clock amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the two year postponement of the second and third CSRD reporting waves. - [Directive 2013/34/EU - Accounting Directive](https://eur-lex.europa.eu/eli/dir/2013/34/oj/eng?ref=sorena.io) - Source for large undertaking, group, and management report definitions that the CSRD amends. - [European Commission - Corporate sustainability reporting](https://finance.ec.europa.eu/capital-markets-union-and-financial-markets/company-reporting-and-auditing/company-reporting/corporate-sustainability-reporting_en?ref=sorena.io) - Official implementation overview for the CSRD, ESRS, quick fix, and related Omnibus developments. ## Related Topic Guides - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/applicability-test --- --- title: "EU CSRD Assurance Ready Controls and Evidence" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/assurance-ready-controls-and-evidence" source_url: "https://www.sorena.io/artifacts/eu/csrd/assurance-ready-controls-and-evidence" author: "Sorena AI" description: "Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence." keywords: - "EU CSRD assurance ready" - "CSRD limited assurance" - "CSRD evidence pack" - "CSRD controls" - "Article 34 sustainability reporting assurance" - "1 October 2026 assurance standards" - "EU CSRD" - "Assurance" - "Limited assurance" - "Controls" - "Evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Assurance Ready Controls and Evidence Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. *EU CSRD* *Assurance* ## EU CSRD (Directive (EU) 2022/2464) Assurance ready controls and evidence This page is about what the assurance opinion will actually lean on. A mature CSRD program controls data, narrative, methodology, markup, and sign off together, not as separate workstreams. CSRD assurance starts at a limited assurance level, but the workload is still serious. The assurance opinion covers compliance with the CSRD and ESRS requirements, the process used to identify the information reported, the markup requirement, and the related Article 8 Taxonomy disclosures where applicable. That means the evidence model must be broader than a spreadsheet archive. ## Control set 1: reporting boundary and materiality governance Auditors and other assurance providers will start by asking how the entity boundary, group boundary, and materiality process were established. If these are unstable, every downstream disclosure becomes fragile. Keep an approved reporting boundary memo, a double materiality methodology, threshold logic, interview records, and a final IRO decision log. - Approved reporting boundary memo. - Materiality methodology with thresholds and governance approvals. - Final list of material matters tied to ESRS and entity specific disclosures. ## Control set 2: data lineage and calculation evidence Every reported metric should have a clear path back to source systems, transformations, assumptions, and reviewer sign off. This is especially important for value chain estimates, scenario based narratives, and any metric built from multiple source systems. Do not allow manual last mile changes without a controlled log. Those changes become almost impossible to defend later. - Source system record and extraction evidence. - Calculation logic, assumptions, and version history. - Reviewer approval and exception log. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU CSRD (Directive (EU) 2022/2464) Assurance ready controls and evidence in one governed evidence system SSOT can take EU CSRD (Directive (EU) 2022/2464) Assurance ready controls and evidence from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU CSRD (Directive (EU) 2022/2464) Assurance ready controls and evidence](/solutions/ssot.md): Start from EU CSRD (Directive (EU) 2022/2464) Assurance ready controls and evidence and keep documents, evidence, and control records in one governed system. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Assurance ready controls and evidence. ## Control set 3: narrative claims, policies, and actions Many assurance findings come from narrative disclosures that are not fully supported by evidence. If the report says a policy applies group wide, an action is implemented, or a target is monitored, there should be approved documentation behind that statement. Narrative control should therefore sit beside metric control, not outside it. - Policy library linked to disclosures that reference policies. - Action plan records linked to claims about implementation progress. - Management review evidence for major narrative statements and estimates. ## Control set 4: markup and publication The assurance opinion also looks at the requirement to mark up sustainability reporting. Markup cannot be treated as a final formatting step performed without content owners. Tagging choices, package validation, and publication quality checks need their own controls. Where ESEF or XHTML publication rules apply, the final report package should be rehearsed before close. - Disclosure to tag mapping with sign off. - Validation log for XHTML, Inline XBRL, and package checks where applicable. - Final publication checklist covering management report, assurance report, and links. ## Assurance standards calendar The Commission must adopt limited assurance standards by 1 October 2026 and may later move toward reasonable assurance standards, with a target date no later than 1 October 2028 for delegated acts if feasible. Until Union assurance standards are in force for a subject, Member States may apply national assurance standards, procedures, or requirements. That means you should build a control system strong enough for current limited assurance and flexible enough to mature further if the assurance depth increases. - Track national assurance requirements until Union standards take over. - Design controls so they can survive a higher testing burden later. - Run pre assurance dry runs with evidence requests and walk throughs. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [European Commission - Corporate sustainability reporting](https://finance.ec.europa.eu/capital-markets-union-and-financial-markets/company-reporting-and-auditing/company-reporting/corporate-sustainability-reporting_en?ref=sorena.io) - Official implementation overview for the CSRD, ESRS, quick fix, and related Omnibus developments. - [ESMA - ESEF Reporting Manual](https://www.esma.europa.eu/sites/default/files/library/esma32-60-254_esef_reporting_manual.pdf?ref=sorena.io) - Primary source for XHTML, Inline XBRL, and filing-quality expectations relevant to digital annual reporting. - [Commission Delegated Regulation (EU) 2021/2178 - Taxonomy Article 8 disclosures](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Primary source for turnover, CapEx, OpEx, and financial undertaking Taxonomy KPI disclosures. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/assurance-ready-controls-and-evidence --- --- title: "EU CSRD Assurance Ready Controls and Evidence" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/assurance-ready-controls-and-evidence" source_url: "https://www.sorena.io/artifacts/eu/csrd/assurance-ready-controls-and-evidence" author: "Sorena AI" description: "Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence." keywords: - "EU CSRD assurance ready" - "CSRD limited assurance" - "CSRD evidence pack" - "CSRD controls" - "Article 34 sustainability reporting assurance" - "1 October 2026 assurance standards" - "EU CSRD" - "Assurance" - "Limited assurance" - "Controls" - "Evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Assurance Ready Controls and Evidence Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. *EU CSRD* *Assurance* ## EU CSRD (Directive (EU) 2022/2464) Assurance ready controls and evidence This page is about what the assurance opinion will actually lean on. A mature CSRD program controls data, narrative, methodology, markup, and sign off together, not as separate workstreams. CSRD assurance starts at a limited assurance level, but the workload is still serious. The assurance opinion covers compliance with the CSRD and ESRS requirements, the process used to identify the information reported, the markup requirement, and the related Article 8 Taxonomy disclosures where applicable. That means the evidence model must be broader than a spreadsheet archive. ## Control set 1: reporting boundary and materiality governance Auditors and other assurance providers will start by asking how the entity boundary, group boundary, and materiality process were established. If these are unstable, every downstream disclosure becomes fragile. Keep an approved reporting boundary memo, a double materiality methodology, threshold logic, interview records, and a final IRO decision log. - Approved reporting boundary memo. - Materiality methodology with thresholds and governance approvals. - Final list of material matters tied to ESRS and entity specific disclosures. ## Control set 2: data lineage and calculation evidence Every reported metric should have a clear path back to source systems, transformations, assumptions, and reviewer sign off. This is especially important for value chain estimates, scenario based narratives, and any metric built from multiple source systems. Do not allow manual last mile changes without a controlled log. Those changes become almost impossible to defend later. - Source system record and extraction evidence. - Calculation logic, assumptions, and version history. - Reviewer approval and exception log. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU CSRD (Directive (EU) 2022/2464) Assurance ready controls and evidence in one governed evidence system SSOT can take EU CSRD (Directive (EU) 2022/2464) Assurance ready controls and evidence from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU CSRD (Directive (EU) 2022/2464) Assurance ready controls and evidence](/solutions/ssot.md): Start from EU CSRD (Directive (EU) 2022/2464) Assurance ready controls and evidence and keep documents, evidence, and control records in one governed system. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Assurance ready controls and evidence. ## Control set 3: narrative claims, policies, and actions Many assurance findings come from narrative disclosures that are not fully supported by evidence. If the report says a policy applies group wide, an action is implemented, or a target is monitored, there should be approved documentation behind that statement. Narrative control should therefore sit beside metric control, not outside it. - Policy library linked to disclosures that reference policies. - Action plan records linked to claims about implementation progress. - Management review evidence for major narrative statements and estimates. ## Control set 4: markup and publication The assurance opinion also looks at the requirement to mark up sustainability reporting. Markup cannot be treated as a final formatting step performed without content owners. Tagging choices, package validation, and publication quality checks need their own controls. Where ESEF or XHTML publication rules apply, the final report package should be rehearsed before close. - Disclosure to tag mapping with sign off. - Validation log for XHTML, Inline XBRL, and package checks where applicable. - Final publication checklist covering management report, assurance report, and links. ## Assurance standards calendar The Commission must adopt limited assurance standards by 1 October 2026 and may later move toward reasonable assurance standards, with a target date no later than 1 October 2028 for delegated acts if feasible. Until Union assurance standards are in force for a subject, Member States may apply national assurance standards, procedures, or requirements. That means you should build a control system strong enough for current limited assurance and flexible enough to mature further if the assurance depth increases. - Track national assurance requirements until Union standards take over. - Design controls so they can survive a higher testing burden later. - Run pre assurance dry runs with evidence requests and walk throughs. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [European Commission - Corporate sustainability reporting](https://finance.ec.europa.eu/capital-markets-union-and-financial-markets/company-reporting-and-auditing/company-reporting/corporate-sustainability-reporting_en?ref=sorena.io) - Official implementation overview for the CSRD, ESRS, quick fix, and related Omnibus developments. - [ESMA - ESEF Reporting Manual](https://www.esma.europa.eu/sites/default/files/library/esma32-60-254_esef_reporting_manual.pdf?ref=sorena.io) - Primary source for XHTML, Inline XBRL, and filing-quality expectations relevant to digital annual reporting. - [Commission Delegated Regulation (EU) 2021/2178 - Taxonomy Article 8 disclosures](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Primary source for turnover, CapEx, OpEx, and financial undertaking Taxonomy KPI disclosures. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/assurance-ready-controls-and-evidence --- --- title: "EU CSRD Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/checklist" source_url: "https://www.sorena.io/artifacts/eu/csrd/checklist" author: "Sorena AI" description: "Use this CSRD checklist to move from scope to report delivery." keywords: - "EU CSRD checklist" - "CSRD reporting checklist" - "ESRS checklist" - "double materiality checklist" - "CSRD assurance checklist" - "CSRD filing checklist" - "EU CSRD" - "Checklist" - "ESRS" - "Reporting" - "Assurance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Checklist Use this CSRD checklist to move from scope to report delivery. *EU CSRD* *Checklist* ## EU CSRD (Directive (EU) 2022/2464) Implementation checklist A checklist built for controlled reporting, not for generic ESG program tracking. Every item below should end in a file, a system record, or a signed decision. The fastest way to lose control of a CSRD project is to treat it like a one time drafting exercise. Use the checklist below to tie the report to real deliverables, named owners, and evidence that can survive audit committee, assurance, and investor review. ## Checklist track 1: scope and boundary Confirm the entity classification, current reporting wave, group exemption logic, and management report boundary before drafting begins. Lock the value chain perimeter and the list of entities covered by the report. Keep one boundary memo and update it if group structure changes. - Scope memo approved. - Current reporting wave confirmed under the stop the clock amendment. - Boundary memo and value chain perimeter documented. *Recommended next step* *Placement: after the checklist block* ## Operationalize EU CSRD (Directive (EU) 2022/2464) Implementation checklist across ESG workflows ESG Compliance can take EU CSRD (Directive (EU) 2022/2464) Implementation checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSRD (Directive (EU) 2022/2464) Implementation checklist](/solutions/esg-compliance.md): Start from EU CSRD (Directive (EU) 2022/2464) Implementation checklist and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Implementation checklist. ## Checklist track 2: double materiality and ESRS architecture Document the materiality method, evidence inputs, interview outputs, thresholds, and final IRO decisions. Then map those decisions into ESRS 2, topical ESRS, and any entity specific disclosures that remain necessary. If the materiality method is weak, the whole report becomes vulnerable. - Materiality method and thresholds approved. - IRO register completed. - ESRS disclosure map and data owner matrix completed. ## Checklist track 3: data, value chain, and Taxonomy links Build a controlled data inventory for metrics and narratives. Where value chain data is incomplete, document the efforts made, the gaps, and the estimation method. Link Taxonomy Article 8 KPIs where they apply so the sustainability statement and Taxonomy disclosures do not drift apart. Keep one data lineage record that covers source, transform, estimate, review, and final report location. - Metric inventory and data lineage records complete. - Value chain estimation method documented. - Taxonomy turnover, CapEx, and OpEx linkage checked where relevant. ## Checklist track 4: assurance, markup, and publication Prepare limited assurance files, management sign off, digital markup logic, and publication controls. The report package needs the same discipline as the content. Run a dry close before the live reporting cycle if the entity is entering CSRD for the first time. - Assurance evidence pack assembled. - Markup and publication checklist approved. - Dry run issues logged and remediated. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Directive (EU) 2025/794 - stop the clock amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the two year postponement of the second and third CSRD reporting waves. - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [Commission Delegated Regulation (EU) 2025/1416 - ESRS quick fix](https://eur-lex.europa.eu/eli/reg_del/2025/1416/oj/eng?ref=sorena.io) - Current law for the temporary wave one ESRS reliefs introduced in July 2025. - [Commission Delegated Regulation (EU) 2021/2178 - Taxonomy Article 8 disclosures](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Primary source for turnover, CapEx, OpEx, and financial undertaking Taxonomy KPI disclosures. - [ESMA - ESEF Reporting Manual](https://www.esma.europa.eu/sites/default/files/library/esma32-60-254_esef_reporting_manual.pdf?ref=sorena.io) - Primary source for XHTML, Inline XBRL, and filing-quality expectations relevant to digital annual reporting. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/checklist --- --- title: "EU CSRD Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/checklist" source_url: "https://www.sorena.io/artifacts/eu/csrd/checklist" author: "Sorena AI" description: "Use this CSRD checklist to move from scope to report delivery." keywords: - "EU CSRD checklist" - "CSRD reporting checklist" - "ESRS checklist" - "double materiality checklist" - "CSRD assurance checklist" - "CSRD filing checklist" - "EU CSRD" - "Checklist" - "ESRS" - "Reporting" - "Assurance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Checklist Use this CSRD checklist to move from scope to report delivery. *EU CSRD* *Checklist* ## EU CSRD (Directive (EU) 2022/2464) Implementation checklist A checklist built for controlled reporting, not for generic ESG program tracking. Every item below should end in a file, a system record, or a signed decision. The fastest way to lose control of a CSRD project is to treat it like a one time drafting exercise. Use the checklist below to tie the report to real deliverables, named owners, and evidence that can survive audit committee, assurance, and investor review. ## Checklist track 1: scope and boundary Confirm the entity classification, current reporting wave, group exemption logic, and management report boundary before drafting begins. Lock the value chain perimeter and the list of entities covered by the report. Keep one boundary memo and update it if group structure changes. - Scope memo approved. - Current reporting wave confirmed under the stop the clock amendment. - Boundary memo and value chain perimeter documented. *Recommended next step* *Placement: after the checklist block* ## Operationalize EU CSRD (Directive (EU) 2022/2464) Implementation checklist across ESG workflows ESG Compliance can take EU CSRD (Directive (EU) 2022/2464) Implementation checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSRD (Directive (EU) 2022/2464) Implementation checklist](/solutions/esg-compliance.md): Start from EU CSRD (Directive (EU) 2022/2464) Implementation checklist and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Implementation checklist. ## Checklist track 2: double materiality and ESRS architecture Document the materiality method, evidence inputs, interview outputs, thresholds, and final IRO decisions. Then map those decisions into ESRS 2, topical ESRS, and any entity specific disclosures that remain necessary. If the materiality method is weak, the whole report becomes vulnerable. - Materiality method and thresholds approved. - IRO register completed. - ESRS disclosure map and data owner matrix completed. ## Checklist track 3: data, value chain, and Taxonomy links Build a controlled data inventory for metrics and narratives. Where value chain data is incomplete, document the efforts made, the gaps, and the estimation method. Link Taxonomy Article 8 KPIs where they apply so the sustainability statement and Taxonomy disclosures do not drift apart. Keep one data lineage record that covers source, transform, estimate, review, and final report location. - Metric inventory and data lineage records complete. - Value chain estimation method documented. - Taxonomy turnover, CapEx, and OpEx linkage checked where relevant. ## Checklist track 4: assurance, markup, and publication Prepare limited assurance files, management sign off, digital markup logic, and publication controls. The report package needs the same discipline as the content. Run a dry close before the live reporting cycle if the entity is entering CSRD for the first time. - Assurance evidence pack assembled. - Markup and publication checklist approved. - Dry run issues logged and remediated. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Directive (EU) 2025/794 - stop the clock amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the two year postponement of the second and third CSRD reporting waves. - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [Commission Delegated Regulation (EU) 2025/1416 - ESRS quick fix](https://eur-lex.europa.eu/eli/reg_del/2025/1416/oj/eng?ref=sorena.io) - Current law for the temporary wave one ESRS reliefs introduced in July 2025. - [Commission Delegated Regulation (EU) 2021/2178 - Taxonomy Article 8 disclosures](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Primary source for turnover, CapEx, OpEx, and financial undertaking Taxonomy KPI disclosures. - [ESMA - ESEF Reporting Manual](https://www.esma.europa.eu/sites/default/files/library/esma32-60-254_esef_reporting_manual.pdf?ref=sorena.io) - Primary source for XHTML, Inline XBRL, and filing-quality expectations relevant to digital annual reporting. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/checklist --- --- title: "EU CSRD Compliance Guide" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/compliance" source_url: "https://www.sorena.io/artifacts/eu/csrd/compliance" author: "Sorena AI" description: "Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage." keywords: - "EU CSRD compliance" - "CSRD reporting system" - "ESRS implementation guide" - "CSRD controls" - "CSRD delivery model" - "CSRD assurance and filing" - "EU CSRD" - "Compliance" - "Reporting system" - "Controls" - "ESRS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Compliance Guide Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. *EU CSRD* *Compliance* ## EU CSRD (Directive (EU) 2022/2464) Compliance guide CSRD compliance is a reporting system problem, not a year end writing problem. Use this page to connect scope, ESRS, Taxonomy, assurance, and digital publication into one operating model. The CSRD asks for a sustainability statement in the management report, but the real workload sits behind that statement: reporting boundary choices, double materiality, value chain information, Taxonomy links, management review, limited assurance, and digital file quality. A good compliance model joins these pieces rather than assigning them to disconnected teams. ## Program layer 1: scope, governance, and boundaries Start with a controlled scope memo and a reporting boundary memo. Then assign a governance model that aligns finance, ESG, legal, internal audit, and business owners. If the management report boundary, value chain boundary, and consolidation logic are not aligned, the report will contradict itself. This is also where wave timing should be locked using the current law, not legacy rollout charts. - Current wave and entity coverage agreed. - Management report and value chain boundaries documented. - Board, audit committee, and executive review points scheduled. ## Program layer 2: materiality and disclosure architecture Double materiality is the gate into the ESRS disclosure set. The process needs evidence inputs, stakeholder interviews, impact and financial materiality thresholds, judgment records, and a final IRO output that can be reviewed later. Once the materiality output is stable, map it into ESRS 2, topical ESRS, entity specific needs, and linked Taxonomy disclosures. - Materiality method and IRO register controlled. - Disclosure map from IROs to ESRS requirements completed. - Entity specific and Taxonomy dependencies identified. ## Program layer 3: data, estimates, and narratives A working CSRD model treats narratives and metrics as equally controlled. Policies, actions, targets, incidents, and value chain assumptions should each have supporting records and review logic. Where data is incomplete, especially in the value chain, the company should document efforts made, reasons for remaining gaps, and the plan to improve future collection. - Metric lineage and narrative evidence model in place. - Value chain estimate method documented. - Known gaps and improvement plan tracked centrally. ## Program layer 4: assurance and publication The assurance opinion reaches into the reporting process, not just the final PDF. It touches ESRS compliance, the materiality process, markup, and Article 8 Taxonomy reporting where relevant. The publication workflow should therefore be rehearsed in the same way as the data workflow. - Assurance request and response workflow defined. - Markup and package validation process established. - Publication ownership and archive process confirmed. *Recommended next step* *Placement: after the compliance steps* ## Operationalize EU CSRD (Directive (EU) 2022/2464) Compliance guide across ESG workflows ESG Compliance can take EU CSRD (Directive (EU) 2022/2464) Compliance guide from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSRD (Directive (EU) 2022/2464) Compliance guide](/solutions/esg-compliance.md): Start from EU CSRD (Directive (EU) 2022/2464) Compliance guide and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Compliance guide. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Directive (EU) 2025/794 - stop the clock amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the two year postponement of the second and third CSRD reporting waves. - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [Commission Delegated Regulation (EU) 2025/1416 - ESRS quick fix](https://eur-lex.europa.eu/eli/reg_del/2025/1416/oj/eng?ref=sorena.io) - Current law for the temporary wave one ESRS reliefs introduced in July 2025. - [European Commission - Corporate sustainability reporting](https://finance.ec.europa.eu/capital-markets-union-and-financial-markets/company-reporting-and-auditing/company-reporting/corporate-sustainability-reporting_en?ref=sorena.io) - Official implementation overview for the CSRD, ESRS, quick fix, and related Omnibus developments. - [ESMA - ESEF Reporting Manual](https://www.esma.europa.eu/sites/default/files/library/esma32-60-254_esef_reporting_manual.pdf?ref=sorena.io) - Primary source for XHTML, Inline XBRL, and filing-quality expectations relevant to digital annual reporting. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/compliance --- --- title: "EU CSRD Compliance Guide" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/compliance" source_url: "https://www.sorena.io/artifacts/eu/csrd/compliance" author: "Sorena AI" description: "Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage." keywords: - "EU CSRD compliance" - "CSRD reporting system" - "ESRS implementation guide" - "CSRD controls" - "CSRD delivery model" - "CSRD assurance and filing" - "EU CSRD" - "Compliance" - "Reporting system" - "Controls" - "ESRS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Compliance Guide Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. *EU CSRD* *Compliance* ## EU CSRD (Directive (EU) 2022/2464) Compliance guide CSRD compliance is a reporting system problem, not a year end writing problem. Use this page to connect scope, ESRS, Taxonomy, assurance, and digital publication into one operating model. The CSRD asks for a sustainability statement in the management report, but the real workload sits behind that statement: reporting boundary choices, double materiality, value chain information, Taxonomy links, management review, limited assurance, and digital file quality. A good compliance model joins these pieces rather than assigning them to disconnected teams. ## Program layer 1: scope, governance, and boundaries Start with a controlled scope memo and a reporting boundary memo. Then assign a governance model that aligns finance, ESG, legal, internal audit, and business owners. If the management report boundary, value chain boundary, and consolidation logic are not aligned, the report will contradict itself. This is also where wave timing should be locked using the current law, not legacy rollout charts. - Current wave and entity coverage agreed. - Management report and value chain boundaries documented. - Board, audit committee, and executive review points scheduled. ## Program layer 2: materiality and disclosure architecture Double materiality is the gate into the ESRS disclosure set. The process needs evidence inputs, stakeholder interviews, impact and financial materiality thresholds, judgment records, and a final IRO output that can be reviewed later. Once the materiality output is stable, map it into ESRS 2, topical ESRS, entity specific needs, and linked Taxonomy disclosures. - Materiality method and IRO register controlled. - Disclosure map from IROs to ESRS requirements completed. - Entity specific and Taxonomy dependencies identified. ## Program layer 3: data, estimates, and narratives A working CSRD model treats narratives and metrics as equally controlled. Policies, actions, targets, incidents, and value chain assumptions should each have supporting records and review logic. Where data is incomplete, especially in the value chain, the company should document efforts made, reasons for remaining gaps, and the plan to improve future collection. - Metric lineage and narrative evidence model in place. - Value chain estimate method documented. - Known gaps and improvement plan tracked centrally. ## Program layer 4: assurance and publication The assurance opinion reaches into the reporting process, not just the final PDF. It touches ESRS compliance, the materiality process, markup, and Article 8 Taxonomy reporting where relevant. The publication workflow should therefore be rehearsed in the same way as the data workflow. - Assurance request and response workflow defined. - Markup and package validation process established. - Publication ownership and archive process confirmed. *Recommended next step* *Placement: after the compliance steps* ## Operationalize EU CSRD (Directive (EU) 2022/2464) Compliance guide across ESG workflows ESG Compliance can take EU CSRD (Directive (EU) 2022/2464) Compliance guide from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSRD (Directive (EU) 2022/2464) Compliance guide](/solutions/esg-compliance.md): Start from EU CSRD (Directive (EU) 2022/2464) Compliance guide and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Compliance guide. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Directive (EU) 2025/794 - stop the clock amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the two year postponement of the second and third CSRD reporting waves. - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [Commission Delegated Regulation (EU) 2025/1416 - ESRS quick fix](https://eur-lex.europa.eu/eli/reg_del/2025/1416/oj/eng?ref=sorena.io) - Current law for the temporary wave one ESRS reliefs introduced in July 2025. - [European Commission - Corporate sustainability reporting](https://finance.ec.europa.eu/capital-markets-union-and-financial-markets/company-reporting-and-auditing/company-reporting/corporate-sustainability-reporting_en?ref=sorena.io) - Official implementation overview for the CSRD, ESRS, quick fix, and related Omnibus developments. - [ESMA - ESEF Reporting Manual](https://www.esma.europa.eu/sites/default/files/library/esma32-60-254_esef_reporting_manual.pdf?ref=sorena.io) - Primary source for XHTML, Inline XBRL, and filing-quality expectations relevant to digital annual reporting. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/compliance --- --- title: "EU CSRD vs IFRS S1 and S2" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2" source_url: "https://www.sorena.io/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2" author: "Sorena AI" description: "Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources." keywords: - "EU CSRD vs IFRS S1 and S2" - "ESRS compared with ISSB" - "double materiality vs financial materiality" - "CSRD IFRS S2 climate comparison" - "ESRS interoperability" - "EU CSRD" - "IFRS S1" - "IFRS S2" - "ESRS" - "Double materiality" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD vs IFRS S1 and S2 Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. *EU CSRD* *Comparison* ## EU CSRD (Directive (EU) 2022/2464) Compared with IFRS S1 and S2 These frameworks are related, but they do not ask the same question. Use this page to separate investor focused sustainability disclosure from the broader double materiality model used by the CSRD and ESRS. IFRS S1 and IFRS S2 focus on sustainability related financial information for capital market users. The CSRD and ESRS require double materiality and reach broader environmental, social, and governance impacts. That difference shapes scope, data architecture, and governance even where many underlying datapoints overlap. ## Core difference: double materiality versus investor focused financial materiality The CSRD and ESRS ask companies to report material impacts, risks, and opportunities. That means the report can be triggered by impacts on people or the environment even where the financial effect on the undertaking is not yet dominant. IFRS S1 and S2 focus on sustainability related financial information relevant to primary users of general purpose financial reports. This is the main legal and operational difference. It affects topic selection, evidence gathering, and the way interviews and thresholds are designed. - CSRD and ESRS: impact materiality plus financial materiality. - IFRS S1 and S2: investor focused financial materiality. - Do not claim full equivalence between the two approaches. *Recommended next step* *Placement: after the comparison section* ## Use EU CSRD (Directive (EU) 2022/2464) Compared with IFRS S1 and S2 as a cited research workflow Research Copilot can take EU CSRD (Directive (EU) 2022/2464) Compared with IFRS S1 and S2 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSRD (Directive (EU) 2022/2464) Compared with IFRS S1 and S2](/solutions/research-copilot.md): Start from EU CSRD (Directive (EU) 2022/2464) Compared with IFRS S1 and S2 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Compared with IFRS S1 and S2. ## Where the frameworks align There is still meaningful overlap. Governance, strategy, risk management, and metrics and targets are familiar structures across both systems. Many climate, workforce, governance, and supply chain datapoints can support both reports if the company keeps one source of truth. EFRAG implementation guidance also notes that an ESRS materiality assessment should put an undertaking in a position to identify sustainability related financial risks and opportunities relevant to IFRS Sustainability Disclosure Standards. - Shared building blocks include governance, strategy, metrics, and controls. - One data model can serve both if it preserves the extra ESRS impact logic. - Use reconciliation notes where topic coverage diverges. ## Climate depth and topic breadth IFRS S2 is a climate standard. The ESRS climate standard sits inside a wider ESRS suite covering environmental, social, and governance topics. That means the CSRD reporting system usually needs broader topic governance than an ISSB only implementation. The practical result is that a climate mature company can still be far from CSRD ready if workforce, human rights, consumers, or governance reporting is weak. - IFRS S2 gives a climate pillar, not a complete ESRS suite. - CSRD requires a wider topic map once material matters are identified. - A climate first program needs expansion before it becomes CSRD grade. ## Best way to run both without duplication Build one reporting architecture with shared source systems, a common control framework, and one calendar for management review. Then layer the materiality logic and report outputs differently for ESRS and IFRS disclosures. This avoids duplicated interviews, contradictory metrics, and mismatched climate narratives. - One source of truth, two reporting lenses. - Shared controls, separate materiality decisions where needed. - Document the reconciliation between investor focused and double materiality outputs. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [IFRS S1 - General Requirements for Disclosure of Sustainability-related Financial Information](https://www.ifrs.org/issued-standards/ifrs-sustainability-standards-navigator/ifrs-s1-general-requirements-for-disclosure-of-sustainability-related-financial-information/?ref=sorena.io) - Official IFRS Foundation page for IFRS S1. - [IFRS S2 - Climate-related Disclosures](https://www.ifrs.org/issued-standards/ifrs-sustainability-standards-navigator/ifrs-s2-climate-related-disclosures/?ref=sorena.io) - Official IFRS Foundation page for IFRS S2. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2 --- --- title: "EU CSRD vs IFRS S1 and S2" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2" source_url: "https://www.sorena.io/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2" author: "Sorena AI" description: "Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources." keywords: - "EU CSRD vs IFRS S1 and S2" - "ESRS compared with ISSB" - "double materiality vs financial materiality" - "CSRD IFRS S2 climate comparison" - "ESRS interoperability" - "EU CSRD" - "IFRS S1" - "IFRS S2" - "ESRS" - "Double materiality" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD vs IFRS S1 and S2 Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. *EU CSRD* *Comparison* ## EU CSRD (Directive (EU) 2022/2464) Compared with IFRS S1 and S2 These frameworks are related, but they do not ask the same question. Use this page to separate investor focused sustainability disclosure from the broader double materiality model used by the CSRD and ESRS. IFRS S1 and IFRS S2 focus on sustainability related financial information for capital market users. The CSRD and ESRS require double materiality and reach broader environmental, social, and governance impacts. That difference shapes scope, data architecture, and governance even where many underlying datapoints overlap. ## Core difference: double materiality versus investor focused financial materiality The CSRD and ESRS ask companies to report material impacts, risks, and opportunities. That means the report can be triggered by impacts on people or the environment even where the financial effect on the undertaking is not yet dominant. IFRS S1 and S2 focus on sustainability related financial information relevant to primary users of general purpose financial reports. This is the main legal and operational difference. It affects topic selection, evidence gathering, and the way interviews and thresholds are designed. - CSRD and ESRS: impact materiality plus financial materiality. - IFRS S1 and S2: investor focused financial materiality. - Do not claim full equivalence between the two approaches. *Recommended next step* *Placement: after the comparison section* ## Use EU CSRD (Directive (EU) 2022/2464) Compared with IFRS S1 and S2 as a cited research workflow Research Copilot can take EU CSRD (Directive (EU) 2022/2464) Compared with IFRS S1 and S2 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSRD (Directive (EU) 2022/2464) Compared with IFRS S1 and S2](/solutions/research-copilot.md): Start from EU CSRD (Directive (EU) 2022/2464) Compared with IFRS S1 and S2 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Compared with IFRS S1 and S2. ## Where the frameworks align There is still meaningful overlap. Governance, strategy, risk management, and metrics and targets are familiar structures across both systems. Many climate, workforce, governance, and supply chain datapoints can support both reports if the company keeps one source of truth. EFRAG implementation guidance also notes that an ESRS materiality assessment should put an undertaking in a position to identify sustainability related financial risks and opportunities relevant to IFRS Sustainability Disclosure Standards. - Shared building blocks include governance, strategy, metrics, and controls. - One data model can serve both if it preserves the extra ESRS impact logic. - Use reconciliation notes where topic coverage diverges. ## Climate depth and topic breadth IFRS S2 is a climate standard. The ESRS climate standard sits inside a wider ESRS suite covering environmental, social, and governance topics. That means the CSRD reporting system usually needs broader topic governance than an ISSB only implementation. The practical result is that a climate mature company can still be far from CSRD ready if workforce, human rights, consumers, or governance reporting is weak. - IFRS S2 gives a climate pillar, not a complete ESRS suite. - CSRD requires a wider topic map once material matters are identified. - A climate first program needs expansion before it becomes CSRD grade. ## Best way to run both without duplication Build one reporting architecture with shared source systems, a common control framework, and one calendar for management review. Then layer the materiality logic and report outputs differently for ESRS and IFRS disclosures. This avoids duplicated interviews, contradictory metrics, and mismatched climate narratives. - One source of truth, two reporting lenses. - Shared controls, separate materiality decisions where needed. - Document the reconciliation between investor focused and double materiality outputs. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [IFRS S1 - General Requirements for Disclosure of Sustainability-related Financial Information](https://www.ifrs.org/issued-standards/ifrs-sustainability-standards-navigator/ifrs-s1-general-requirements-for-disclosure-of-sustainability-related-financial-information/?ref=sorena.io) - Official IFRS Foundation page for IFRS S1. - [IFRS S2 - Climate-related Disclosures](https://www.ifrs.org/issued-standards/ifrs-sustainability-standards-navigator/ifrs-s2-climate-related-disclosures/?ref=sorena.io) - Official IFRS Foundation page for IFRS S2. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2 --- --- title: "EU CSRD vs SEC Climate Disclosure Rule" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule" source_url: "https://www.sorena.io/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule" author: "Sorena AI" description: "Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources." keywords: - "EU CSRD vs SEC climate disclosure rule" - "ESRS compared with SEC climate rule" - "CSRD SEC climate rule status" - "double materiality vs investor disclosure" - "multinational climate reporting" - "EU CSRD" - "SEC climate rule" - "Comparison" - "ESRS" - "Climate disclosure" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD vs SEC Climate Disclosure Rule Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. *EU CSRD* *Comparison* ## EU CSRD (Directive (EU) 2022/2464) Compared with the SEC climate disclosure rule This comparison only works if you start with the current SEC status and the much broader scope of the CSRD. Use it to avoid presenting a US climate filing program as if it already covers a full ESRS reporting obligation. The CSRD and ESRS create a broad sustainability reporting regime. The SEC climate disclosure rule is narrower in topic scope and remains in litigation. As of 6 March 2026, the SEC rule should be treated as a separate and currently unstable reference point, not as a substitute for the CSRD or ESRS reporting model. ## First difference: current legal status The SEC adopted its climate disclosure rule in March 2024, but the rule was stayed during litigation. In March 2025 the SEC announced that it would end its defense of the rule. That means US planning teams should not speak about the SEC rule as a settled and fully live baseline in the same way they speak about the CSRD. The CSRD and ESRS, by contrast, are in force and already shape live reporting obligations in the Union. - SEC climate rule status is still litigation affected. - CSRD and ESRS obligations are current law. - Multinationals should keep a status note on US rule uncertainty. *Recommended next step* *Placement: after the comparison section* ## Use EU CSRD (Directive (EU) 2022/2464) Compared with the SEC climate disclosure rule as a cited research workflow Research Copilot can take EU CSRD (Directive (EU) 2022/2464) Compared with the SEC climate disclosure rule from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSRD (Directive (EU) 2022/2464) Compared with the SEC climate disclosure rule](/solutions/research-copilot.md): Start from EU CSRD (Directive (EU) 2022/2464) Compared with the SEC climate disclosure rule and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Compared with the SEC climate disclosure rule. ## Second difference: sustainability breadth The SEC rule is climate specific. The CSRD and ESRS can cover climate, pollution, water, biodiversity, workforce, workers in the value chain, affected communities, consumers, and governance topics depending on materiality outcomes. A company that is organized only for climate disclosure is therefore not CSRD ready by default. - SEC: climate only. - CSRD and ESRS: broad sustainability suite based on material matters. - Topic governance needs to be wider under the CSRD. ## Third difference: materiality model The CSRD and ESRS use double materiality. The SEC rule follows a capital markets disclosure logic focused on investor decision making and material climate information under US securities law. That leads to different threshold decisions and different disclosure populations. This is why a climate control that is enough for a securities filing may still be too narrow for an ESRS report. - ESRS asks about impacts, risks, and opportunities. - SEC asks for investor focused climate disclosure under securities law logic. - The same datapoint can appear in both, but the report architecture is different. ## Best operating model for multinationals Keep one climate data spine, but do not collapse the reporting rules into one template. Run a shared climate evidence set, then layer EU and US reporting logic on top according to the current legal status of each regime. This keeps the program efficient without pretending the regimes are the same. - Shared climate data and controls. - Separate legal analyses for EU and US outputs. - Current status tracker for litigation and amendments. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [SEC - The Enhancement and Standardization of Climate-Related Disclosures for Investors](https://www.sec.gov/rules/final/2024/33-11275.pdf) - Official SEC final rule text issued in March 2024. - [SEC - Statement on climate-related disclosure rule litigation](https://www.sec.gov/newsroom/press-releases/2025-57) - Official SEC status update showing the rule remains in litigation and that the Commission ended its defense of the rule in 2025. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule --- --- title: "EU CSRD vs SEC Climate Disclosure Rule" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule" source_url: "https://www.sorena.io/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule" author: "Sorena AI" description: "Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources." keywords: - "EU CSRD vs SEC climate disclosure rule" - "ESRS compared with SEC climate rule" - "CSRD SEC climate rule status" - "double materiality vs investor disclosure" - "multinational climate reporting" - "EU CSRD" - "SEC climate rule" - "Comparison" - "ESRS" - "Climate disclosure" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD vs SEC Climate Disclosure Rule Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. *EU CSRD* *Comparison* ## EU CSRD (Directive (EU) 2022/2464) Compared with the SEC climate disclosure rule This comparison only works if you start with the current SEC status and the much broader scope of the CSRD. Use it to avoid presenting a US climate filing program as if it already covers a full ESRS reporting obligation. The CSRD and ESRS create a broad sustainability reporting regime. The SEC climate disclosure rule is narrower in topic scope and remains in litigation. As of 6 March 2026, the SEC rule should be treated as a separate and currently unstable reference point, not as a substitute for the CSRD or ESRS reporting model. ## First difference: current legal status The SEC adopted its climate disclosure rule in March 2024, but the rule was stayed during litigation. In March 2025 the SEC announced that it would end its defense of the rule. That means US planning teams should not speak about the SEC rule as a settled and fully live baseline in the same way they speak about the CSRD. The CSRD and ESRS, by contrast, are in force and already shape live reporting obligations in the Union. - SEC climate rule status is still litigation affected. - CSRD and ESRS obligations are current law. - Multinationals should keep a status note on US rule uncertainty. *Recommended next step* *Placement: after the comparison section* ## Use EU CSRD (Directive (EU) 2022/2464) Compared with the SEC climate disclosure rule as a cited research workflow Research Copilot can take EU CSRD (Directive (EU) 2022/2464) Compared with the SEC climate disclosure rule from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSRD (Directive (EU) 2022/2464) Compared with the SEC climate disclosure rule](/solutions/research-copilot.md): Start from EU CSRD (Directive (EU) 2022/2464) Compared with the SEC climate disclosure rule and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Compared with the SEC climate disclosure rule. ## Second difference: sustainability breadth The SEC rule is climate specific. The CSRD and ESRS can cover climate, pollution, water, biodiversity, workforce, workers in the value chain, affected communities, consumers, and governance topics depending on materiality outcomes. A company that is organized only for climate disclosure is therefore not CSRD ready by default. - SEC: climate only. - CSRD and ESRS: broad sustainability suite based on material matters. - Topic governance needs to be wider under the CSRD. ## Third difference: materiality model The CSRD and ESRS use double materiality. The SEC rule follows a capital markets disclosure logic focused on investor decision making and material climate information under US securities law. That leads to different threshold decisions and different disclosure populations. This is why a climate control that is enough for a securities filing may still be too narrow for an ESRS report. - ESRS asks about impacts, risks, and opportunities. - SEC asks for investor focused climate disclosure under securities law logic. - The same datapoint can appear in both, but the report architecture is different. ## Best operating model for multinationals Keep one climate data spine, but do not collapse the reporting rules into one template. Run a shared climate evidence set, then layer EU and US reporting logic on top according to the current legal status of each regime. This keeps the program efficient without pretending the regimes are the same. - Shared climate data and controls. - Separate legal analyses for EU and US outputs. - Current status tracker for litigation and amendments. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [SEC - The Enhancement and Standardization of Climate-Related Disclosures for Investors](https://www.sec.gov/rules/final/2024/33-11275.pdf) - Official SEC final rule text issued in March 2024. - [SEC - Statement on climate-related disclosure rule litigation](https://www.sec.gov/newsroom/press-releases/2025-57) - Official SEC status update showing the rule remains in litigation and that the Commission ended its defense of the rule in 2025. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule --- --- title: "EU CSRD vs Taxonomy Alignment" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/csrd-vs-taxonomy-alignment" source_url: "https://www.sorena.io/artifacts/eu/csrd/csrd-vs-taxonomy-alignment" author: "Sorena AI" description: "Compare CSRD reporting with EU Taxonomy alignment disclosures." keywords: - "EU CSRD vs Taxonomy alignment" - "ESRS versus Article 8 KPIs" - "CSRD Taxonomy turnover CapEx OpEx" - "Taxonomy eligible vs aligned" - "sustainability statement and Taxonomy disclosures" - "EU CSRD" - "EU Taxonomy" - "Article 8" - "ESRS" - "Alignment" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD vs Taxonomy Alignment Compare CSRD reporting with EU Taxonomy alignment disclosures. *EU CSRD* *Comparison* ## EU CSRD (Directive (EU) 2022/2464) Compared with Taxonomy alignment These disclosures sit next to each other in many reports, but they answer different questions. Use this page to stop the common mistake of treating strong ESRS narrative coverage as proof of Taxonomy alignment. The CSRD gives the reporting framework for the sustainability statement. The EU Taxonomy Article 8 rules require specific KPI disclosures about taxonomy eligible and taxonomy aligned economic activities. A company can have broad ESRS coverage and still show low Taxonomy alignment, and the reverse can also be true. ## Main difference: report on sustainability matters versus quantify aligned activities The CSRD and ESRS ask for sustainability information across governance, strategy, IROs, actions, metrics, and targets. Taxonomy Article 8 asks certain undertakings to quantify how and to what extent activities are associated with environmentally sustainable economic activities and to disclose the prescribed KPIs. These are different legal outputs. One is a broad reporting system. The other is a specific environmentally sustainable activity disclosure regime. - CSRD and ESRS: broad sustainability reporting architecture. - Taxonomy Article 8: prescribed activity linked KPIs. - Strong narrative disclosure does not equal high alignment. *Recommended next step* *Placement: after the comparison section* ## Use EU CSRD (Directive (EU) 2022/2464) Compared with Taxonomy alignment as a cited research workflow Research Copilot can take EU CSRD (Directive (EU) 2022/2464) Compared with Taxonomy alignment from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSRD (Directive (EU) 2022/2464) Compared with Taxonomy alignment](/solutions/research-copilot.md): Start from EU CSRD (Directive (EU) 2022/2464) Compared with Taxonomy alignment and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Compared with Taxonomy alignment. ## KPI logic is more rigid under the Taxonomy For non-financial undertakings, the Article 8 delegated regulation uses turnover, CapEx, and OpEx KPIs. For financial undertakings, it defines different KPIs such as GAR and other sector specific measures. This is a calculation regime, not a general reporting concept. That is why Taxonomy work should sit close to finance and technical eligibility assessments, even if the output is disclosed beside the sustainability statement. - Non-financial undertakings use turnover, CapEx, and OpEx KPIs. - Financial undertakings use sector specific KPI structures. - Calculation and technical screening logic need dedicated controls. ## How the two should interact in one report The efficient approach is to maintain one activity inventory, one environmental objective mapping, and one source data layer that feeds both the sustainability statement and the Taxonomy note. Then reconcile narrative claims about transition or environmental strategy with the actual KPI outputs. Investors notice quickly when a report describes strong sustainability performance while Taxonomy KPIs remain unexplained or inconsistent. - Use one activity inventory across ESRS and Taxonomy work. - Explain low or changing alignment clearly in narrative sections. - Keep KPI assumptions and technical screening assessments reviewable. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [Regulation (EU) 2020/852 - EU Taxonomy Regulation](https://eur-lex.europa.eu/eli/reg/2020/852/oj/eng?ref=sorena.io) - Primary legal text for Taxonomy eligibility and alignment disclosures. - [Commission Delegated Regulation (EU) 2021/2178 - Taxonomy Article 8 disclosures](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Primary source for turnover, CapEx, OpEx, and financial undertaking Taxonomy KPI disclosures. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/csrd-vs-taxonomy-alignment --- --- title: "EU CSRD vs Taxonomy Alignment" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/csrd-vs-taxonomy-alignment" source_url: "https://www.sorena.io/artifacts/eu/csrd/csrd-vs-taxonomy-alignment" author: "Sorena AI" description: "Compare CSRD reporting with EU Taxonomy alignment disclosures." keywords: - "EU CSRD vs Taxonomy alignment" - "ESRS versus Article 8 KPIs" - "CSRD Taxonomy turnover CapEx OpEx" - "Taxonomy eligible vs aligned" - "sustainability statement and Taxonomy disclosures" - "EU CSRD" - "EU Taxonomy" - "Article 8" - "ESRS" - "Alignment" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD vs Taxonomy Alignment Compare CSRD reporting with EU Taxonomy alignment disclosures. *EU CSRD* *Comparison* ## EU CSRD (Directive (EU) 2022/2464) Compared with Taxonomy alignment These disclosures sit next to each other in many reports, but they answer different questions. Use this page to stop the common mistake of treating strong ESRS narrative coverage as proof of Taxonomy alignment. The CSRD gives the reporting framework for the sustainability statement. The EU Taxonomy Article 8 rules require specific KPI disclosures about taxonomy eligible and taxonomy aligned economic activities. A company can have broad ESRS coverage and still show low Taxonomy alignment, and the reverse can also be true. ## Main difference: report on sustainability matters versus quantify aligned activities The CSRD and ESRS ask for sustainability information across governance, strategy, IROs, actions, metrics, and targets. Taxonomy Article 8 asks certain undertakings to quantify how and to what extent activities are associated with environmentally sustainable economic activities and to disclose the prescribed KPIs. These are different legal outputs. One is a broad reporting system. The other is a specific environmentally sustainable activity disclosure regime. - CSRD and ESRS: broad sustainability reporting architecture. - Taxonomy Article 8: prescribed activity linked KPIs. - Strong narrative disclosure does not equal high alignment. *Recommended next step* *Placement: after the comparison section* ## Use EU CSRD (Directive (EU) 2022/2464) Compared with Taxonomy alignment as a cited research workflow Research Copilot can take EU CSRD (Directive (EU) 2022/2464) Compared with Taxonomy alignment from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSRD (Directive (EU) 2022/2464) Compared with Taxonomy alignment](/solutions/research-copilot.md): Start from EU CSRD (Directive (EU) 2022/2464) Compared with Taxonomy alignment and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Compared with Taxonomy alignment. ## KPI logic is more rigid under the Taxonomy For non-financial undertakings, the Article 8 delegated regulation uses turnover, CapEx, and OpEx KPIs. For financial undertakings, it defines different KPIs such as GAR and other sector specific measures. This is a calculation regime, not a general reporting concept. That is why Taxonomy work should sit close to finance and technical eligibility assessments, even if the output is disclosed beside the sustainability statement. - Non-financial undertakings use turnover, CapEx, and OpEx KPIs. - Financial undertakings use sector specific KPI structures. - Calculation and technical screening logic need dedicated controls. ## How the two should interact in one report The efficient approach is to maintain one activity inventory, one environmental objective mapping, and one source data layer that feeds both the sustainability statement and the Taxonomy note. Then reconcile narrative claims about transition or environmental strategy with the actual KPI outputs. Investors notice quickly when a report describes strong sustainability performance while Taxonomy KPIs remain unexplained or inconsistent. - Use one activity inventory across ESRS and Taxonomy work. - Explain low or changing alignment clearly in narrative sections. - Keep KPI assumptions and technical screening assessments reviewable. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [Regulation (EU) 2020/852 - EU Taxonomy Regulation](https://eur-lex.europa.eu/eli/reg/2020/852/oj/eng?ref=sorena.io) - Primary legal text for Taxonomy eligibility and alignment disclosures. - [Commission Delegated Regulation (EU) 2021/2178 - Taxonomy Article 8 disclosures](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Primary source for turnover, CapEx, OpEx, and financial undertaking Taxonomy KPI disclosures. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/csrd-vs-taxonomy-alignment --- --- title: "EU CSRD Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/csrd/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix." keywords: - "EU CSRD deadlines" - "CSRD stop the clock" - "CSRD quick fix" - "CSRD wave 2 2027" - "CSRD wave 3 2028" - "30 June 2026 ESRS" - "1 October 2026 assurance standards" - "EU CSRD" - "Deadlines" - "Directive (EU) 2025/794" - "Quick fix" - "Assurance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Deadlines and Compliance Calendar Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. *EU CSRD* *Calendar* ## EU CSRD (Directive (EU) 2022/2464) Deadlines and compliance calendar This is the current CSRD calendar, not the original launch calendar repeated across older summaries. Use it to sequence materiality, data, assurance, and publication work against the current law. The CSRD calendar changed in 2025. Wave one remained live, but the later waves moved. The ESRS quick fix also changed what some first wave reporters had to disclose in the early years. If your planning does not separate these legal changes, it will produce unnecessary work or miss actual deadlines. ## Financial years starting on or after 1 January 2024: wave one Wave one covers the legacy NFRD population of large public interest entities exceeding 500 employees and the matching parent group category. These undertakings are already in the live reporting cycle. In July 2025, the quick fix delegated regulation introduced temporary relief for certain ESRS datapoints for these first wave reporters. That relief should be built into the reporting plan rather than treated as an informal tolerance. - Wave one timing remains unchanged. - Check the 2025 quick fix before finalizing the datapoint backlog. - Use reliefs carefully and document where they are applied. ## Financial years starting on or after 1 January 2027: current wave two Directive (EU) 2025/794 postponed the second wave by two years. The other large undertakings and other parent undertakings of large groups now move into CSRD reporting for financial years beginning on or after 1 January 2027. This is a legal change, not only a political proposal. Planning documents should be updated accordingly. - 1 January 2027 is the current wave two start year. - Do not rely on old 1 January 2025 wave charts. - Use the delay to harden materiality, value chain, and assurance design rather than to pause the program completely. ## Financial years starting on or after 1 January 2028: current wave three and third-country route The listed SME and certain special category wave now starts with financial years beginning on or after 1 January 2028. The third-country undertaking reporting route also remains tied to the financial year 2028 framework. If a listed SME is likely to use a transitional opt out, record that choice explicitly and keep readiness work moving where investors or group reporting still require it. - 1 January 2028 is the current listed SME wave start year. - Third-country undertaking planning still matters for 2028 based reporting. - Treat opt out decisions as governance decisions, not silent defaults. ## 30 June 2026 and 1 October 2026: support acts and assurance deadline Directive (EU) 2024/1306 moved the deadline for sector-specific and third-country ESRS delegated acts to 30 June 2026. Separately, the Commission must adopt limited assurance standards by 1 October 2026. These dates matter because they affect both disclosure architecture and external review planning. - 30 June 2026: sector-specific and third-country ESRS delegated act deadline. - 1 October 2026: limited assurance standards deadline. - 1 October 2028: reasonable assurance delegated acts target if feasible. *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU CSRD (Directive (EU) 2022/2464) Deadlines and compliance calendar across ESG workflows ESG Compliance can take EU CSRD (Directive (EU) 2022/2464) Deadlines and compliance calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSRD (Directive (EU) 2022/2464) Deadlines and compliance calendar](/solutions/esg-compliance.md): Start from EU CSRD (Directive (EU) 2022/2464) Deadlines and compliance calendar and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Deadlines and compliance calendar. ## Keep one separate note on pending Omnibus simplification There is still a difference between enacted timing changes and broader pending simplification proposals. Use enacted law for reporting waves today, and track wider Omnibus discussions as pending change management items until formally adopted and published. This avoids the common failure mode where teams redesign the report around proposals that are not yet binding. - Use binding acts for live deadlines. - Track proposals separately from law in the project register. - Review the calendar again when new binding acts are published. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Directive (EU) 2025/794 - stop the clock amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the two year postponement of the second and third CSRD reporting waves. - [Commission Delegated Regulation (EU) 2025/1416 - ESRS quick fix](https://eur-lex.europa.eu/eli/reg_del/2025/1416/oj/eng?ref=sorena.io) - Current law for the temporary wave one ESRS reliefs introduced in July 2025. - [Directive (EU) 2024/1306 - ESRS sector-specific and third-country deadline delay](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024L1306&ref=sorena.io) - Moved the deadline for sector-specific and third-country ESRS delegated acts to 30 June 2026. - [European Commission - Corporate sustainability reporting](https://finance.ec.europa.eu/capital-markets-union-and-financial-markets/company-reporting-and-auditing/company-reporting/corporate-sustainability-reporting_en?ref=sorena.io) - Official implementation overview for the CSRD, ESRS, quick fix, and related Omnibus developments. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/deadlines-and-compliance-calendar --- --- title: "EU CSRD Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/csrd/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix." keywords: - "EU CSRD deadlines" - "CSRD stop the clock" - "CSRD quick fix" - "CSRD wave 2 2027" - "CSRD wave 3 2028" - "30 June 2026 ESRS" - "1 October 2026 assurance standards" - "EU CSRD" - "Deadlines" - "Directive (EU) 2025/794" - "Quick fix" - "Assurance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Deadlines and Compliance Calendar Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. *EU CSRD* *Calendar* ## EU CSRD (Directive (EU) 2022/2464) Deadlines and compliance calendar This is the current CSRD calendar, not the original launch calendar repeated across older summaries. Use it to sequence materiality, data, assurance, and publication work against the current law. The CSRD calendar changed in 2025. Wave one remained live, but the later waves moved. The ESRS quick fix also changed what some first wave reporters had to disclose in the early years. If your planning does not separate these legal changes, it will produce unnecessary work or miss actual deadlines. ## Financial years starting on or after 1 January 2024: wave one Wave one covers the legacy NFRD population of large public interest entities exceeding 500 employees and the matching parent group category. These undertakings are already in the live reporting cycle. In July 2025, the quick fix delegated regulation introduced temporary relief for certain ESRS datapoints for these first wave reporters. That relief should be built into the reporting plan rather than treated as an informal tolerance. - Wave one timing remains unchanged. - Check the 2025 quick fix before finalizing the datapoint backlog. - Use reliefs carefully and document where they are applied. ## Financial years starting on or after 1 January 2027: current wave two Directive (EU) 2025/794 postponed the second wave by two years. The other large undertakings and other parent undertakings of large groups now move into CSRD reporting for financial years beginning on or after 1 January 2027. This is a legal change, not only a political proposal. Planning documents should be updated accordingly. - 1 January 2027 is the current wave two start year. - Do not rely on old 1 January 2025 wave charts. - Use the delay to harden materiality, value chain, and assurance design rather than to pause the program completely. ## Financial years starting on or after 1 January 2028: current wave three and third-country route The listed SME and certain special category wave now starts with financial years beginning on or after 1 January 2028. The third-country undertaking reporting route also remains tied to the financial year 2028 framework. If a listed SME is likely to use a transitional opt out, record that choice explicitly and keep readiness work moving where investors or group reporting still require it. - 1 January 2028 is the current listed SME wave start year. - Third-country undertaking planning still matters for 2028 based reporting. - Treat opt out decisions as governance decisions, not silent defaults. ## 30 June 2026 and 1 October 2026: support acts and assurance deadline Directive (EU) 2024/1306 moved the deadline for sector-specific and third-country ESRS delegated acts to 30 June 2026. Separately, the Commission must adopt limited assurance standards by 1 October 2026. These dates matter because they affect both disclosure architecture and external review planning. - 30 June 2026: sector-specific and third-country ESRS delegated act deadline. - 1 October 2026: limited assurance standards deadline. - 1 October 2028: reasonable assurance delegated acts target if feasible. *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU CSRD (Directive (EU) 2022/2464) Deadlines and compliance calendar across ESG workflows ESG Compliance can take EU CSRD (Directive (EU) 2022/2464) Deadlines and compliance calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSRD (Directive (EU) 2022/2464) Deadlines and compliance calendar](/solutions/esg-compliance.md): Start from EU CSRD (Directive (EU) 2022/2464) Deadlines and compliance calendar and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Deadlines and compliance calendar. ## Keep one separate note on pending Omnibus simplification There is still a difference between enacted timing changes and broader pending simplification proposals. Use enacted law for reporting waves today, and track wider Omnibus discussions as pending change management items until formally adopted and published. This avoids the common failure mode where teams redesign the report around proposals that are not yet binding. - Use binding acts for live deadlines. - Track proposals separately from law in the project register. - Review the calendar again when new binding acts are published. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Directive (EU) 2025/794 - stop the clock amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the two year postponement of the second and third CSRD reporting waves. - [Commission Delegated Regulation (EU) 2025/1416 - ESRS quick fix](https://eur-lex.europa.eu/eli/reg_del/2025/1416/oj/eng?ref=sorena.io) - Current law for the temporary wave one ESRS reliefs introduced in July 2025. - [Directive (EU) 2024/1306 - ESRS sector-specific and third-country deadline delay](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024L1306&ref=sorena.io) - Moved the deadline for sector-specific and third-country ESRS delegated acts to 30 June 2026. - [European Commission - Corporate sustainability reporting](https://finance.ec.europa.eu/capital-markets-union-and-financial-markets/company-reporting-and-auditing/company-reporting/corporate-sustainability-reporting_en?ref=sorena.io) - Official implementation overview for the CSRD, ESRS, quick fix, and related Omnibus developments. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/deadlines-and-compliance-calendar --- --- title: "EU CSRD Double Materiality Interview Question Bank" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/double-materiality-interview-question-bank" source_url: "https://www.sorena.io/artifacts/eu/csrd/double-materiality-interview-question-bank" author: "Sorena AI" description: "Use this CSRD question bank to run a stronger double materiality process." keywords: - "EU CSRD double materiality interview questions" - "ESRS stakeholder interview questions" - "impact materiality questions" - "financial materiality questions" - "IRO interview bank" - "EU CSRD" - "Double materiality" - "Interview questions" - "IROs" - "ESRS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Double Materiality Interview Question Bank Use this CSRD question bank to run a stronger double materiality process. *EU CSRD* *Question Bank* ## EU CSRD (Directive (EU) 2022/2464) Double materiality interview question bank The quality of the materiality process depends on the quality of the questions asked. Use this bank to get beyond generic ESG workshops and into evidence that supports real ESRS decisions. Materiality interviews should help the undertaking identify and assess impacts, risks, and opportunities across its own operations and upstream and downstream value chain. That requires questions that surface severity, scale, scope, irremediability, financial effect, timing, and uncertainty. The prompts below are designed for that job. ## Question set 1: impact materiality These questions should probe actual and potential impacts on people and the environment, including the value chain. The goal is to understand scale, scope, and whether a harmful outcome can realistically be remedied. Ask for concrete examples, not values statements. - Where do the most severe actual or potential impacts arise in operations or the value chain? - Which stakeholder groups or ecosystems are affected, and how broadly? - If the impact occurs, how difficult would it be to restore the affected people or environment? ## Question set 2: financial materiality These questions should test how sustainability matters can affect development, financial position, performance, cash flows, access to finance, or cost of capital over different time horizons. Ask management to explain the pathway from sustainability matter to financial effect, not just whether the matter feels relevant. - Which sustainability matters could change revenue, costs, asset values, or financing conditions? - Over what time horizon would the effect likely appear? - What assumptions or external signals support the assessment? ## Question set 3: value chain and dependencies The value chain should not be treated as an appendix. Use questions that surface upstream and downstream dependencies, bottlenecks, data gaps, and where the undertaking relies on partners for environmental or social performance. This is often where hidden material matters become visible. - Which upstream or downstream relationships create the strongest impact or risk profile? - Where is information weak or heavily estimated today? - Which partners, geographies, or products require deeper review? ## Question set 4: governance and response quality Ask what policies, targets, controls, and action plans exist today, and whether they are actually used in decisions. Materiality is easier to defend when the undertaking can show how identified matters connect to governance and action. These questions also reveal where the report may overstate maturity. - Which decisions are already influenced by this sustainability matter? - What targets, controls, or escalation routes exist today? - What evidence could support a narrative claim about this topic? *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU CSRD (Directive (EU) 2022/2464) Double materiality interview question bank across ESG workflows ESG Compliance can take EU CSRD (Directive (EU) 2022/2464) Double materiality interview question bank from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSRD (Directive (EU) 2022/2464) Double materiality interview question bank](/solutions/esg-compliance.md): Start from EU CSRD (Directive (EU) 2022/2464) Double materiality interview question bank and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Double materiality interview question bank. ## Primary sources - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [European Commission - FAQ on CSRD implementation](https://finance.ec.europa.eu/publications/frequently-asked-questions-implementation-eu-corporate-sustainability-reporting-rules_en?ref=sorena.io) - Official Commission answers on practical interpretation and rollout questions. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/double-materiality-interview-question-bank --- --- title: "EU CSRD Double Materiality Interview Question Bank" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/double-materiality-interview-question-bank" source_url: "https://www.sorena.io/artifacts/eu/csrd/double-materiality-interview-question-bank" author: "Sorena AI" description: "Use this CSRD question bank to run a stronger double materiality process." keywords: - "EU CSRD double materiality interview questions" - "ESRS stakeholder interview questions" - "impact materiality questions" - "financial materiality questions" - "IRO interview bank" - "EU CSRD" - "Double materiality" - "Interview questions" - "IROs" - "ESRS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Double Materiality Interview Question Bank Use this CSRD question bank to run a stronger double materiality process. *EU CSRD* *Question Bank* ## EU CSRD (Directive (EU) 2022/2464) Double materiality interview question bank The quality of the materiality process depends on the quality of the questions asked. Use this bank to get beyond generic ESG workshops and into evidence that supports real ESRS decisions. Materiality interviews should help the undertaking identify and assess impacts, risks, and opportunities across its own operations and upstream and downstream value chain. That requires questions that surface severity, scale, scope, irremediability, financial effect, timing, and uncertainty. The prompts below are designed for that job. ## Question set 1: impact materiality These questions should probe actual and potential impacts on people and the environment, including the value chain. The goal is to understand scale, scope, and whether a harmful outcome can realistically be remedied. Ask for concrete examples, not values statements. - Where do the most severe actual or potential impacts arise in operations or the value chain? - Which stakeholder groups or ecosystems are affected, and how broadly? - If the impact occurs, how difficult would it be to restore the affected people or environment? ## Question set 2: financial materiality These questions should test how sustainability matters can affect development, financial position, performance, cash flows, access to finance, or cost of capital over different time horizons. Ask management to explain the pathway from sustainability matter to financial effect, not just whether the matter feels relevant. - Which sustainability matters could change revenue, costs, asset values, or financing conditions? - Over what time horizon would the effect likely appear? - What assumptions or external signals support the assessment? ## Question set 3: value chain and dependencies The value chain should not be treated as an appendix. Use questions that surface upstream and downstream dependencies, bottlenecks, data gaps, and where the undertaking relies on partners for environmental or social performance. This is often where hidden material matters become visible. - Which upstream or downstream relationships create the strongest impact or risk profile? - Where is information weak or heavily estimated today? - Which partners, geographies, or products require deeper review? ## Question set 4: governance and response quality Ask what policies, targets, controls, and action plans exist today, and whether they are actually used in decisions. Materiality is easier to defend when the undertaking can show how identified matters connect to governance and action. These questions also reveal where the report may overstate maturity. - Which decisions are already influenced by this sustainability matter? - What targets, controls, or escalation routes exist today? - What evidence could support a narrative claim about this topic? *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU CSRD (Directive (EU) 2022/2464) Double materiality interview question bank across ESG workflows ESG Compliance can take EU CSRD (Directive (EU) 2022/2464) Double materiality interview question bank from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSRD (Directive (EU) 2022/2464) Double materiality interview question bank](/solutions/esg-compliance.md): Start from EU CSRD (Directive (EU) 2022/2464) Double materiality interview question bank and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Double materiality interview question bank. ## Primary sources - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [European Commission - FAQ on CSRD implementation](https://finance.ec.europa.eu/publications/frequently-asked-questions-implementation-eu-corporate-sustainability-reporting-rules_en?ref=sorena.io) - Official Commission answers on practical interpretation and rollout questions. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/double-materiality-interview-question-bank --- --- title: "EU CSRD Double Materiality Method" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/double-materiality-method" source_url: "https://www.sorena.io/artifacts/eu/csrd/double-materiality-method" author: "Sorena AI" description: "Build a reviewable double materiality method for the CSRD and ESRS." keywords: - "EU CSRD double materiality method" - "ESRS materiality methodology" - "impact materiality and financial materiality" - "IRO method" - "value chain materiality method" - "EU CSRD" - "Double materiality" - "Method" - "ESRS" - "IRO register" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Double Materiality Method Build a reviewable double materiality method for the CSRD and ESRS. *EU CSRD* *Method* ## EU CSRD (Directive (EU) 2022/2464) Double materiality method A strong report starts with a method that can survive challenge. Use this page to structure the process, evidence, and governance behind material topic selection. A double materiality method should do three things well: identify material impacts, risks, and opportunities across the value chain, apply thresholds and judgment transparently, and create a direct bridge into the sustainability statement. If it does not do all three, the report becomes a drafting exercise rather than a reporting system. ## Method step 1: define scope, value chain perimeter, and time horizons Before scoring anything, define the reporting entity, the value chain perimeter, and the time horizons used. The ESRS materiality process should consider own operations plus upstream and downstream value chain effects. These choices should be explicit because they shape what enters the IRO universe and what is left out. - Reporting entity and group perimeter defined. - Value chain perimeter documented. - Short, medium, and long term horizons documented. ## Method step 2: build the universe of sustainability matters and IROs Start with ESRS sustainability matters, industry and business model specifics, prior incidents, stakeholder inputs, strategy documents, and known dependencies. Then identify actual and potential impacts plus financial risks and opportunities. This universe should be broad at first and narrowed only after threshold application and review. - Use documentary sources, interviews, and quantitative data together. - Track matters at a level that can later be tied to disclosures. - Keep one master register of candidate IROs. ## Method step 3: apply impact and financial thresholds Impact materiality should consider severity dimensions such as scale, scope, and irremediability, with likelihood for potential impacts. Financial materiality should test whether the matter triggers or could reasonably be expected to trigger material financial effects over time. The method should record both the threshold logic and the evidence used to support each judgment. - Keep threshold definitions written and approved. - Document judgments where qualitative evidence drives the result. - Explain how impact and financial materiality interact where both apply. ## Method step 4: approve, disclose, and refresh A materiality method is not complete until the governance path, disclosure logic, and refresh triggers are defined. The undertaking should be able to show how the outcome informs ESRS disclosures and when the assessment will be refreshed or challenged again. Use the method as a yearly operating process, not as a one off kickoff exercise. - Final approval owner identified. - Link from material matters to disclosure requirements maintained. - Refresh triggers for acquisitions, new geographies, incidents, or strategy shifts documented. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU CSRD (Directive (EU) 2022/2464) Double materiality method across ESG workflows ESG Compliance can take EU CSRD (Directive (EU) 2022/2464) Double materiality method from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSRD (Directive (EU) 2022/2464) Double materiality method](/solutions/esg-compliance.md): Start from EU CSRD (Directive (EU) 2022/2464) Double materiality method and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Double materiality method. ## Primary sources - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [European Commission - FAQ on CSRD implementation](https://finance.ec.europa.eu/publications/frequently-asked-questions-implementation-eu-corporate-sustainability-reporting-rules_en?ref=sorena.io) - Official Commission answers on practical interpretation and rollout questions. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/double-materiality-method --- --- title: "EU CSRD Double Materiality Method" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/double-materiality-method" source_url: "https://www.sorena.io/artifacts/eu/csrd/double-materiality-method" author: "Sorena AI" description: "Build a reviewable double materiality method for the CSRD and ESRS." keywords: - "EU CSRD double materiality method" - "ESRS materiality methodology" - "impact materiality and financial materiality" - "IRO method" - "value chain materiality method" - "EU CSRD" - "Double materiality" - "Method" - "ESRS" - "IRO register" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Double Materiality Method Build a reviewable double materiality method for the CSRD and ESRS. *EU CSRD* *Method* ## EU CSRD (Directive (EU) 2022/2464) Double materiality method A strong report starts with a method that can survive challenge. Use this page to structure the process, evidence, and governance behind material topic selection. A double materiality method should do three things well: identify material impacts, risks, and opportunities across the value chain, apply thresholds and judgment transparently, and create a direct bridge into the sustainability statement. If it does not do all three, the report becomes a drafting exercise rather than a reporting system. ## Method step 1: define scope, value chain perimeter, and time horizons Before scoring anything, define the reporting entity, the value chain perimeter, and the time horizons used. The ESRS materiality process should consider own operations plus upstream and downstream value chain effects. These choices should be explicit because they shape what enters the IRO universe and what is left out. - Reporting entity and group perimeter defined. - Value chain perimeter documented. - Short, medium, and long term horizons documented. ## Method step 2: build the universe of sustainability matters and IROs Start with ESRS sustainability matters, industry and business model specifics, prior incidents, stakeholder inputs, strategy documents, and known dependencies. Then identify actual and potential impacts plus financial risks and opportunities. This universe should be broad at first and narrowed only after threshold application and review. - Use documentary sources, interviews, and quantitative data together. - Track matters at a level that can later be tied to disclosures. - Keep one master register of candidate IROs. ## Method step 3: apply impact and financial thresholds Impact materiality should consider severity dimensions such as scale, scope, and irremediability, with likelihood for potential impacts. Financial materiality should test whether the matter triggers or could reasonably be expected to trigger material financial effects over time. The method should record both the threshold logic and the evidence used to support each judgment. - Keep threshold definitions written and approved. - Document judgments where qualitative evidence drives the result. - Explain how impact and financial materiality interact where both apply. ## Method step 4: approve, disclose, and refresh A materiality method is not complete until the governance path, disclosure logic, and refresh triggers are defined. The undertaking should be able to show how the outcome informs ESRS disclosures and when the assessment will be refreshed or challenged again. Use the method as a yearly operating process, not as a one off kickoff exercise. - Final approval owner identified. - Link from material matters to disclosure requirements maintained. - Refresh triggers for acquisitions, new geographies, incidents, or strategy shifts documented. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU CSRD (Directive (EU) 2022/2464) Double materiality method across ESG workflows ESG Compliance can take EU CSRD (Directive (EU) 2022/2464) Double materiality method from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSRD (Directive (EU) 2022/2464) Double materiality method](/solutions/esg-compliance.md): Start from EU CSRD (Directive (EU) 2022/2464) Double materiality method and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Double materiality method. ## Primary sources - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [European Commission - FAQ on CSRD implementation](https://finance.ec.europa.eu/publications/frequently-asked-questions-implementation-eu-corporate-sustainability-reporting-rules_en?ref=sorena.io) - Official Commission answers on practical interpretation and rollout questions. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/double-materiality-method --- --- title: "EU CSRD ESRS Structure and Data Model" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/esrs-structure-and-data-model" source_url: "https://www.sorena.io/artifacts/eu/csrd/esrs-structure-and-data-model" author: "Sorena AI" description: "Understand how to organize ESRS reporting under the CSRD." keywords: - "EU CSRD ESRS structure" - "ESRS data model" - "ESRS 1 ESRS 2 topical standards" - "CSRD data points" - "ESRS drafting model" - "ESRS markup model" - "EU CSRD" - "ESRS" - "Data model" - "ESRS 1" - "ESRS 2" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD ESRS Structure and Data Model Understand how to organize ESRS reporting under the CSRD. *EU CSRD* *Data Model* ## EU CSRD (Directive (EU) 2022/2464) ESRS structure and data model The report gets easier once the ESRS architecture is visible in one model. Use this page to connect material matters, disclosure requirements, data owners, narratives, metrics, and tags. ESRS reporting becomes manageable when it is converted into a data model instead of handled as a long list of disconnected paragraphs. A good model starts from material matters, routes them into ESRS 2 and relevant topical standards, records the required datapoints, and then links each datapoint to ownership, evidence, and markup. ## Layer 1: ESRS 1 and ESRS 2 as the frame ESRS 1 sets general requirements and reporting concepts. ESRS 2 provides general disclosures. Together they form the reporting frame for the sustainability statement and should be built before the topical layers are drafted. If this layer is weak, topical disclosures become inconsistent because governance, scope, and method are not stable. - Use ESRS 1 for principles, boundary, and reporting logic. - Use ESRS 2 for general disclosures that support the whole statement. - Tie both layers to the materiality method and the reporting boundary memo. ## Layer 2: topical standards and entity specific additions Topical ESRS disclosures should be activated from the final materiality outcome, not from a generic all topics template. Where material information is not fully captured by ESRS, entity specific disclosure may still be needed. This is where an IRO register becomes operationally valuable. - Map each material matter to the relevant topical ESRS requirements. - Record why a topical standard is in or out. - Add entity specific disclosures only where they are genuinely needed. ## Layer 3: datapoints, owners, and evidence Once the disclosure list is fixed, create one register for datapoints, owners, evidence sources, estimation methods, review requirements, and markup mapping. This is the bridge between the legal text and the reporting engine. The model should cover both quantitative and qualitative datapoints. - One datapoint register with owner and evidence fields. - Separate flags for measured, estimated, and narrative based datapoints. - Version and change controls built in from the start. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU CSRD (Directive (EU) 2022/2464) ESRS structure and data model in one governed evidence system SSOT can take EU CSRD (Directive (EU) 2022/2464) ESRS structure and data model from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU CSRD (Directive (EU) 2022/2464) ESRS structure and data model](/solutions/ssot.md): Start from EU CSRD (Directive (EU) 2022/2464) ESRS structure and data model and keep documents, evidence, and control records in one governed system. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) ESRS structure and data model. ## Layer 4: drafting, markup, and assurance handoff The data model should end in a document and a file package, not in a spreadsheet only. That means drafting structure, review workflow, markup, and assurance handoff should be part of the model design. If the data model ignores the final publication format, the team will recreate logic late in the process. - Link each disclosure to draft owner, reviewer, and final approver. - Map the final disclosure output to markup and filing needs. - Use the same register to answer assurance requests quickly. ## Primary sources - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [Commission Delegated Regulation (EU) 2025/1416 - ESRS quick fix](https://eur-lex.europa.eu/eli/reg_del/2025/1416/oj/eng?ref=sorena.io) - Current law for the temporary wave one ESRS reliefs introduced in July 2025. - [ESMA - ESEF Reporting Manual](https://www.esma.europa.eu/sites/default/files/library/esma32-60-254_esef_reporting_manual.pdf?ref=sorena.io) - Primary source for XHTML, Inline XBRL, and filing-quality expectations relevant to digital annual reporting. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/esrs-structure-and-data-model --- --- title: "EU CSRD ESRS Structure and Data Model" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/esrs-structure-and-data-model" source_url: "https://www.sorena.io/artifacts/eu/csrd/esrs-structure-and-data-model" author: "Sorena AI" description: "Understand how to organize ESRS reporting under the CSRD." keywords: - "EU CSRD ESRS structure" - "ESRS data model" - "ESRS 1 ESRS 2 topical standards" - "CSRD data points" - "ESRS drafting model" - "ESRS markup model" - "EU CSRD" - "ESRS" - "Data model" - "ESRS 1" - "ESRS 2" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD ESRS Structure and Data Model Understand how to organize ESRS reporting under the CSRD. *EU CSRD* *Data Model* ## EU CSRD (Directive (EU) 2022/2464) ESRS structure and data model The report gets easier once the ESRS architecture is visible in one model. Use this page to connect material matters, disclosure requirements, data owners, narratives, metrics, and tags. ESRS reporting becomes manageable when it is converted into a data model instead of handled as a long list of disconnected paragraphs. A good model starts from material matters, routes them into ESRS 2 and relevant topical standards, records the required datapoints, and then links each datapoint to ownership, evidence, and markup. ## Layer 1: ESRS 1 and ESRS 2 as the frame ESRS 1 sets general requirements and reporting concepts. ESRS 2 provides general disclosures. Together they form the reporting frame for the sustainability statement and should be built before the topical layers are drafted. If this layer is weak, topical disclosures become inconsistent because governance, scope, and method are not stable. - Use ESRS 1 for principles, boundary, and reporting logic. - Use ESRS 2 for general disclosures that support the whole statement. - Tie both layers to the materiality method and the reporting boundary memo. ## Layer 2: topical standards and entity specific additions Topical ESRS disclosures should be activated from the final materiality outcome, not from a generic all topics template. Where material information is not fully captured by ESRS, entity specific disclosure may still be needed. This is where an IRO register becomes operationally valuable. - Map each material matter to the relevant topical ESRS requirements. - Record why a topical standard is in or out. - Add entity specific disclosures only where they are genuinely needed. ## Layer 3: datapoints, owners, and evidence Once the disclosure list is fixed, create one register for datapoints, owners, evidence sources, estimation methods, review requirements, and markup mapping. This is the bridge between the legal text and the reporting engine. The model should cover both quantitative and qualitative datapoints. - One datapoint register with owner and evidence fields. - Separate flags for measured, estimated, and narrative based datapoints. - Version and change controls built in from the start. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU CSRD (Directive (EU) 2022/2464) ESRS structure and data model in one governed evidence system SSOT can take EU CSRD (Directive (EU) 2022/2464) ESRS structure and data model from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU CSRD (Directive (EU) 2022/2464) ESRS structure and data model](/solutions/ssot.md): Start from EU CSRD (Directive (EU) 2022/2464) ESRS structure and data model and keep documents, evidence, and control records in one governed system. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) ESRS structure and data model. ## Layer 4: drafting, markup, and assurance handoff The data model should end in a document and a file package, not in a spreadsheet only. That means drafting structure, review workflow, markup, and assurance handoff should be part of the model design. If the data model ignores the final publication format, the team will recreate logic late in the process. - Link each disclosure to draft owner, reviewer, and final approver. - Map the final disclosure output to markup and filing needs. - Use the same register to answer assurance requests quickly. ## Primary sources - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [Commission Delegated Regulation (EU) 2025/1416 - ESRS quick fix](https://eur-lex.europa.eu/eli/reg_del/2025/1416/oj/eng?ref=sorena.io) - Current law for the temporary wave one ESRS reliefs introduced in July 2025. - [ESMA - ESEF Reporting Manual](https://www.esma.europa.eu/sites/default/files/library/esma32-60-254_esef_reporting_manual.pdf?ref=sorena.io) - Primary source for XHTML, Inline XBRL, and filing-quality expectations relevant to digital annual reporting. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/esrs-structure-and-data-model --- --- title: "EU CSRD FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/faq" source_url: "https://www.sorena.io/artifacts/eu/csrd/faq" author: "Sorena AI" description: "Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs." keywords: - "EU CSRD FAQ" - "CSRD wave dates" - "stop the clock CSRD FAQ" - "ESRS quick fix FAQ" - "CSRD assurance FAQ" - "Taxonomy and CSRD FAQ" - "EU CSRD" - "FAQ" - "Waves" - "ESRS" - "Assurance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD FAQ Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. *EU CSRD* *FAQ* ## EU CSRD (Directive (EU) 2022/2464) Frequently asked questions These are the questions that usually create timing errors or unnecessary work. The answers below use the current legal position, not the original launch calendar alone. Most CSRD confusion comes from three places: stale wave dates, weak understanding of how ESRS materiality works, and poor separation between the sustainability statement, Taxonomy KPIs, and assurance mechanics. Use these answers as a grounded starting point. ## When do the reporting waves start now? Wave one remains tied to financial years starting on or after 1 January 2024. The stop the clock amendment moved the second wave to 1 January 2027 and the listed SME wave to 1 January 2028. If you still see 2025 and 2026 as the later start years, that summary is outdated. - 1 January 2024: wave one. - 1 January 2027: current wave two. - 1 January 2028: current wave three. ## What did the July 2025 quick fix change? The quick fix delegated regulation introduced temporary reliefs for some first wave reporters under ESRS Set 1. The point was to reduce immediate pressure on certain datapoints while the broader reform debate continued. It did not remove the wave one reporting obligation itself. - Quick fix relief is about some datapoints, not about scope. - Wave one entities still report. - Use the delegated act directly rather than relying on informal summaries. ## Does CSRD mean every ESRS topic must be reported? No. The report is driven by double materiality. ESRS 2 applies generally, while topical standards depend on the final materiality outcome. Entity specific information may also still be required where material information is not fully covered by ESRS. That means the materiality process is the legal gateway into the topic set. - Do not start from an all topics drafting template. - Do start from a controlled materiality method. - Keep the decision trail for included and excluded topics. ## Is assurance only about the final report text? No. The assurance opinion covers compliance with ESRS, the process used to identify the information reported, the markup requirement, and relevant Article 8 Taxonomy reporting. That is why the methodology and data model matter as much as the final text. A polished report without control evidence is still weak. - Method, data, and markup all matter for assurance. - Evidence has to support narrative and metrics together. - Limited assurance does not mean light documentation. ## How does the CSRD interact with the EU Taxonomy? The sustainability statement and Taxonomy Article 8 KPIs often appear together, but they answer different legal questions. The CSRD and ESRS provide the reporting framework. The Taxonomy delegated regulation prescribes separate KPI calculations for eligibility and alignment. You need consistency across both, but one does not replace the other. - Treat Taxonomy as a linked disclosure stream, not a substitute for ESRS. - Reconcile narrative claims with KPI results. - Keep one shared activity inventory where possible. *Recommended next step* *Placement: after the FAQ section* ## Use EU CSRD (Directive (EU) 2022/2464) Frequently asked questions as a cited research workflow Research Copilot can take EU CSRD (Directive (EU) 2022/2464) Frequently asked questions from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSRD (Directive (EU) 2022/2464) Frequently asked questions](/solutions/research-copilot.md): Start from EU CSRD (Directive (EU) 2022/2464) Frequently asked questions and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Frequently asked questions. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Directive (EU) 2025/794 - stop the clock amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the two year postponement of the second and third CSRD reporting waves. - [Commission Delegated Regulation (EU) 2025/1416 - ESRS quick fix](https://eur-lex.europa.eu/eli/reg_del/2025/1416/oj/eng?ref=sorena.io) - Current law for the temporary wave one ESRS reliefs introduced in July 2025. - [Commission Delegated Regulation (EU) 2021/2178 - Taxonomy Article 8 disclosures](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Primary source for turnover, CapEx, OpEx, and financial undertaking Taxonomy KPI disclosures. - [European Commission - Corporate sustainability reporting](https://finance.ec.europa.eu/capital-markets-union-and-financial-markets/company-reporting-and-auditing/company-reporting/corporate-sustainability-reporting_en?ref=sorena.io) - Official implementation overview for the CSRD, ESRS, quick fix, and related Omnibus developments. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/faq --- --- title: "EU CSRD FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/faq" source_url: "https://www.sorena.io/artifacts/eu/csrd/faq" author: "Sorena AI" description: "Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs." keywords: - "EU CSRD FAQ" - "CSRD wave dates" - "stop the clock CSRD FAQ" - "ESRS quick fix FAQ" - "CSRD assurance FAQ" - "Taxonomy and CSRD FAQ" - "EU CSRD" - "FAQ" - "Waves" - "ESRS" - "Assurance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD FAQ Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. *EU CSRD* *FAQ* ## EU CSRD (Directive (EU) 2022/2464) Frequently asked questions These are the questions that usually create timing errors or unnecessary work. The answers below use the current legal position, not the original launch calendar alone. Most CSRD confusion comes from three places: stale wave dates, weak understanding of how ESRS materiality works, and poor separation between the sustainability statement, Taxonomy KPIs, and assurance mechanics. Use these answers as a grounded starting point. ## When do the reporting waves start now? Wave one remains tied to financial years starting on or after 1 January 2024. The stop the clock amendment moved the second wave to 1 January 2027 and the listed SME wave to 1 January 2028. If you still see 2025 and 2026 as the later start years, that summary is outdated. - 1 January 2024: wave one. - 1 January 2027: current wave two. - 1 January 2028: current wave three. ## What did the July 2025 quick fix change? The quick fix delegated regulation introduced temporary reliefs for some first wave reporters under ESRS Set 1. The point was to reduce immediate pressure on certain datapoints while the broader reform debate continued. It did not remove the wave one reporting obligation itself. - Quick fix relief is about some datapoints, not about scope. - Wave one entities still report. - Use the delegated act directly rather than relying on informal summaries. ## Does CSRD mean every ESRS topic must be reported? No. The report is driven by double materiality. ESRS 2 applies generally, while topical standards depend on the final materiality outcome. Entity specific information may also still be required where material information is not fully covered by ESRS. That means the materiality process is the legal gateway into the topic set. - Do not start from an all topics drafting template. - Do start from a controlled materiality method. - Keep the decision trail for included and excluded topics. ## Is assurance only about the final report text? No. The assurance opinion covers compliance with ESRS, the process used to identify the information reported, the markup requirement, and relevant Article 8 Taxonomy reporting. That is why the methodology and data model matter as much as the final text. A polished report without control evidence is still weak. - Method, data, and markup all matter for assurance. - Evidence has to support narrative and metrics together. - Limited assurance does not mean light documentation. ## How does the CSRD interact with the EU Taxonomy? The sustainability statement and Taxonomy Article 8 KPIs often appear together, but they answer different legal questions. The CSRD and ESRS provide the reporting framework. The Taxonomy delegated regulation prescribes separate KPI calculations for eligibility and alignment. You need consistency across both, but one does not replace the other. - Treat Taxonomy as a linked disclosure stream, not a substitute for ESRS. - Reconcile narrative claims with KPI results. - Keep one shared activity inventory where possible. *Recommended next step* *Placement: after the FAQ section* ## Use EU CSRD (Directive (EU) 2022/2464) Frequently asked questions as a cited research workflow Research Copilot can take EU CSRD (Directive (EU) 2022/2464) Frequently asked questions from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSRD (Directive (EU) 2022/2464) Frequently asked questions](/solutions/research-copilot.md): Start from EU CSRD (Directive (EU) 2022/2464) Frequently asked questions and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Frequently asked questions. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Directive (EU) 2025/794 - stop the clock amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the two year postponement of the second and third CSRD reporting waves. - [Commission Delegated Regulation (EU) 2025/1416 - ESRS quick fix](https://eur-lex.europa.eu/eli/reg_del/2025/1416/oj/eng?ref=sorena.io) - Current law for the temporary wave one ESRS reliefs introduced in July 2025. - [Commission Delegated Regulation (EU) 2021/2178 - Taxonomy Article 8 disclosures](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Primary source for turnover, CapEx, OpEx, and financial undertaking Taxonomy KPI disclosures. - [European Commission - Corporate sustainability reporting](https://finance.ec.europa.eu/capital-markets-union-and-financial-markets/company-reporting-and-auditing/company-reporting/corporate-sustainability-reporting_en?ref=sorena.io) - Official implementation overview for the CSRD, ESRS, quick fix, and related Omnibus developments. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/faq --- --- title: "EU CSRD Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/csrd/penalties-and-fines" author: "Sorena AI" description: "Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement." keywords: - "EU CSRD penalties" - "CSRD fines" - "CSRD enforcement" - "CSRD national penalties" - "CSRD assurance exposure" - "CSRD filing failures" - "EU CSRD" - "Penalties" - "Enforcement" - "National law" - "Assurance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Penalties and Fines Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. *EU CSRD* *Enforcement* ## EU CSRD (Directive (EU) 2022/2464) Penalties and fines CSRD penalty risk is real, but it does not work like a single harmonized turnover cap regime. Use this page to understand how national reporting, filing, and assurance enforcement actually create exposure. The CSRD is implemented through amendments to the Accounting Directive, the Audit Directive, and related transparency and publication rules. That means penalty exposure depends heavily on Member State transposition, filing rules, and the enforcement powers tied to annual reporting, assurance, and market publication. Companies should not expect one clean Union wide fine schedule. ## Why there is no single EU wide CSRD fine formula Unlike some newer Union regulations, the CSRD does not create one harmonized turnover based penalty cap across the Union. Instead, Member States implement the reporting and assurance framework through national laws and enforcement structures that already sit around accounting, audit, and issuer reporting. That means the legal exposure must be assessed country by country. - Check the Member State that governs the reporting entity and filing route. - Track both accounting law and securities market publication rules where relevant. - Do not rely on one generic pan EU penalty statement. ## Where exposure usually appears first In practice, CSRD exposure often appears through failures in the management report, incomplete or misleading sustainability statements, weak assurance support, missing publication requirements, or inconsistent Taxonomy reporting. Issuers may also face market disclosure pressure if the annual report package is defective. This means the operational control environment matters just as much as the legal memo. - Management report defects. - Assurance support failures. - Publication, markup, or filing defects. ## Penalty preparation is mostly a controls problem The best defense is a reviewable record showing how scope, materiality, estimates, and publication decisions were made. Weak documentation turns ordinary reporting judgment into enforcement risk very quickly. Keep one response pack ready for regulator, auditor, or market operator questions. - Scope and wave memo. - Materiality method and IRO register. - Evidence pack for metrics, narratives, Taxonomy KPIs, and markup. *Recommended next step* *Placement: after the enforcement section* ## Use EU CSRD (Directive (EU) 2022/2464) Penalties and fines as a cited research workflow Research Copilot can take EU CSRD (Directive (EU) 2022/2464) Penalties and fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSRD (Directive (EU) 2022/2464) Penalties and fines](/solutions/research-copilot.md): Start from EU CSRD (Directive (EU) 2022/2464) Penalties and fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Penalties and fines. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Directive 2013/34/EU - Accounting Directive](https://eur-lex.europa.eu/eli/dir/2013/34/oj/eng?ref=sorena.io) - Source for large undertaking, group, and management report definitions that the CSRD amends. - [European Commission - FAQ on CSRD implementation](https://finance.ec.europa.eu/publications/frequently-asked-questions-implementation-eu-corporate-sustainability-reporting-rules_en?ref=sorena.io) - Official Commission answers on practical interpretation and rollout questions. - [ESMA - ESEF Reporting Manual](https://www.esma.europa.eu/sites/default/files/library/esma32-60-254_esef_reporting_manual.pdf?ref=sorena.io) - Primary source for XHTML, Inline XBRL, and filing-quality expectations relevant to digital annual reporting. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/penalties-and-fines --- --- title: "EU CSRD Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/csrd/penalties-and-fines" author: "Sorena AI" description: "Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement." keywords: - "EU CSRD penalties" - "CSRD fines" - "CSRD enforcement" - "CSRD national penalties" - "CSRD assurance exposure" - "CSRD filing failures" - "EU CSRD" - "Penalties" - "Enforcement" - "National law" - "Assurance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Penalties and Fines Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. *EU CSRD* *Enforcement* ## EU CSRD (Directive (EU) 2022/2464) Penalties and fines CSRD penalty risk is real, but it does not work like a single harmonized turnover cap regime. Use this page to understand how national reporting, filing, and assurance enforcement actually create exposure. The CSRD is implemented through amendments to the Accounting Directive, the Audit Directive, and related transparency and publication rules. That means penalty exposure depends heavily on Member State transposition, filing rules, and the enforcement powers tied to annual reporting, assurance, and market publication. Companies should not expect one clean Union wide fine schedule. ## Why there is no single EU wide CSRD fine formula Unlike some newer Union regulations, the CSRD does not create one harmonized turnover based penalty cap across the Union. Instead, Member States implement the reporting and assurance framework through national laws and enforcement structures that already sit around accounting, audit, and issuer reporting. That means the legal exposure must be assessed country by country. - Check the Member State that governs the reporting entity and filing route. - Track both accounting law and securities market publication rules where relevant. - Do not rely on one generic pan EU penalty statement. ## Where exposure usually appears first In practice, CSRD exposure often appears through failures in the management report, incomplete or misleading sustainability statements, weak assurance support, missing publication requirements, or inconsistent Taxonomy reporting. Issuers may also face market disclosure pressure if the annual report package is defective. This means the operational control environment matters just as much as the legal memo. - Management report defects. - Assurance support failures. - Publication, markup, or filing defects. ## Penalty preparation is mostly a controls problem The best defense is a reviewable record showing how scope, materiality, estimates, and publication decisions were made. Weak documentation turns ordinary reporting judgment into enforcement risk very quickly. Keep one response pack ready for regulator, auditor, or market operator questions. - Scope and wave memo. - Materiality method and IRO register. - Evidence pack for metrics, narratives, Taxonomy KPIs, and markup. *Recommended next step* *Placement: after the enforcement section* ## Use EU CSRD (Directive (EU) 2022/2464) Penalties and fines as a cited research workflow Research Copilot can take EU CSRD (Directive (EU) 2022/2464) Penalties and fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSRD (Directive (EU) 2022/2464) Penalties and fines](/solutions/research-copilot.md): Start from EU CSRD (Directive (EU) 2022/2464) Penalties and fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Penalties and fines. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Directive 2013/34/EU - Accounting Directive](https://eur-lex.europa.eu/eli/dir/2013/34/oj/eng?ref=sorena.io) - Source for large undertaking, group, and management report definitions that the CSRD amends. - [European Commission - FAQ on CSRD implementation](https://finance.ec.europa.eu/publications/frequently-asked-questions-implementation-eu-corporate-sustainability-reporting-rules_en?ref=sorena.io) - Official Commission answers on practical interpretation and rollout questions. - [ESMA - ESEF Reporting Manual](https://www.esma.europa.eu/sites/default/files/library/esma32-60-254_esef_reporting_manual.pdf?ref=sorena.io) - Primary source for XHTML, Inline XBRL, and filing-quality expectations relevant to digital annual reporting. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/penalties-and-fines --- --- title: "EU CSRD Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/requirements" source_url: "https://www.sorena.io/artifacts/eu/csrd/requirements" author: "Sorena AI" description: "Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage." keywords: - "EU CSRD requirements" - "CSRD reporting requirements" - "ESRS requirements" - "limited assurance requirements" - "CSRD markup requirements" - "Article 8 taxonomy linkage" - "EU CSRD" - "Requirements" - "ESRS" - "Assurance" - "Markup" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Requirements Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. *EU CSRD* *Requirements* ## EU CSRD (Directive (EU) 2022/2464) Requirements overview The easiest way to run CSRD is to break it into requirement tracks that map to real owners. Use this page when you need the shortest route from law to reporting workstream. The CSRD is a reporting framework, but reporting quality depends on how the underlying workstreams are organized. The tracks below convert the legal requirements into manageable reporting, evidence, and assurance units. ## Track 1: scope, boundary, and management report architecture The first track determines whether the entity is in scope, which wave applies, whether an exemption can be used, and how the sustainability statement fits inside the management report. This track also determines group versus entity reporting logic. Without this track, all later work is unstable. - Outputs: scope memo, wave assignment, reporting boundary memo. - Key sources: CSRD and Accounting Directive definitions. - Core teams: finance, legal, reporting, corporate secretariat. ## Track 2: ESRS and double materiality The second track covers the materiality process, the IRO register, ESRS 1 and ESRS 2 framing, topical ESRS activation, and entity specific disclosure logic where needed. This is the analytical core of the sustainability statement. If this track is weak, the report becomes template driven rather than entity specific. - Outputs: materiality method, interview records, IRO register, disclosure map. - Key sources: ESRS 1 and ESRS 2, EFRAG implementation guidance. - Core teams: ESG, finance, strategy, risk, legal. ## Track 3: data, value chain, and Taxonomy linkage The third track covers metrics, qualitative datapoints, value chain information, estimation methods, and any Article 8 Taxonomy disclosures that connect to the sustainability statement. This is where source systems and calculation quality matter most. The report should explain gaps and efforts where full value chain data is not yet available. - Outputs: metric inventory, value chain method, data lineage, Taxonomy KPI files. - Key sources: ESRS Set 1 and Taxonomy Article 8 delegated regulation. - Core teams: finance, ESG data, operations, procurement. ## Track 4: assurance, markup, and publication The fourth track covers limited assurance readiness, markup, digital filing, publication timing, and archiving. The assurance opinion reaches into the process used to identify the information reported and the compliance of the markup and Taxonomy disclosures where relevant. This is why publication and assurance should be designed as a continuation of the reporting process, not as a final wrap up. - Outputs: assurance pack, markup map, validation logs, publication checklist. - Key sources: CSRD assurance provisions and ESMA filing guidance. - Core teams: finance, reporting operations, audit, IT, legal. *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU CSRD (Directive (EU) 2022/2464) Requirements overview across ESG workflows ESG Compliance can take EU CSRD (Directive (EU) 2022/2464) Requirements overview from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSRD (Directive (EU) 2022/2464) Requirements overview](/solutions/esg-compliance.md): Start from EU CSRD (Directive (EU) 2022/2464) Requirements overview and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Requirements overview. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Directive (EU) 2025/794 - stop the clock amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the two year postponement of the second and third CSRD reporting waves. - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [Commission Delegated Regulation (EU) 2021/2178 - Taxonomy Article 8 disclosures](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Primary source for turnover, CapEx, OpEx, and financial undertaking Taxonomy KPI disclosures. - [ESMA - ESEF Reporting Manual](https://www.esma.europa.eu/sites/default/files/library/esma32-60-254_esef_reporting_manual.pdf?ref=sorena.io) - Primary source for XHTML, Inline XBRL, and filing-quality expectations relevant to digital annual reporting. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/requirements --- --- title: "EU CSRD Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/requirements" source_url: "https://www.sorena.io/artifacts/eu/csrd/requirements" author: "Sorena AI" description: "Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage." keywords: - "EU CSRD requirements" - "CSRD reporting requirements" - "ESRS requirements" - "limited assurance requirements" - "CSRD markup requirements" - "Article 8 taxonomy linkage" - "EU CSRD" - "Requirements" - "ESRS" - "Assurance" - "Markup" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Requirements Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. *EU CSRD* *Requirements* ## EU CSRD (Directive (EU) 2022/2464) Requirements overview The easiest way to run CSRD is to break it into requirement tracks that map to real owners. Use this page when you need the shortest route from law to reporting workstream. The CSRD is a reporting framework, but reporting quality depends on how the underlying workstreams are organized. The tracks below convert the legal requirements into manageable reporting, evidence, and assurance units. ## Track 1: scope, boundary, and management report architecture The first track determines whether the entity is in scope, which wave applies, whether an exemption can be used, and how the sustainability statement fits inside the management report. This track also determines group versus entity reporting logic. Without this track, all later work is unstable. - Outputs: scope memo, wave assignment, reporting boundary memo. - Key sources: CSRD and Accounting Directive definitions. - Core teams: finance, legal, reporting, corporate secretariat. ## Track 2: ESRS and double materiality The second track covers the materiality process, the IRO register, ESRS 1 and ESRS 2 framing, topical ESRS activation, and entity specific disclosure logic where needed. This is the analytical core of the sustainability statement. If this track is weak, the report becomes template driven rather than entity specific. - Outputs: materiality method, interview records, IRO register, disclosure map. - Key sources: ESRS 1 and ESRS 2, EFRAG implementation guidance. - Core teams: ESG, finance, strategy, risk, legal. ## Track 3: data, value chain, and Taxonomy linkage The third track covers metrics, qualitative datapoints, value chain information, estimation methods, and any Article 8 Taxonomy disclosures that connect to the sustainability statement. This is where source systems and calculation quality matter most. The report should explain gaps and efforts where full value chain data is not yet available. - Outputs: metric inventory, value chain method, data lineage, Taxonomy KPI files. - Key sources: ESRS Set 1 and Taxonomy Article 8 delegated regulation. - Core teams: finance, ESG data, operations, procurement. ## Track 4: assurance, markup, and publication The fourth track covers limited assurance readiness, markup, digital filing, publication timing, and archiving. The assurance opinion reaches into the process used to identify the information reported and the compliance of the markup and Taxonomy disclosures where relevant. This is why publication and assurance should be designed as a continuation of the reporting process, not as a final wrap up. - Outputs: assurance pack, markup map, validation logs, publication checklist. - Key sources: CSRD assurance provisions and ESMA filing guidance. - Core teams: finance, reporting operations, audit, IT, legal. *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU CSRD (Directive (EU) 2022/2464) Requirements overview across ESG workflows ESG Compliance can take EU CSRD (Directive (EU) 2022/2464) Requirements overview from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSRD (Directive (EU) 2022/2464) Requirements overview](/solutions/esg-compliance.md): Start from EU CSRD (Directive (EU) 2022/2464) Requirements overview and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Requirements overview. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Directive (EU) 2025/794 - stop the clock amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the two year postponement of the second and third CSRD reporting waves. - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [Commission Delegated Regulation (EU) 2021/2178 - Taxonomy Article 8 disclosures](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Primary source for turnover, CapEx, OpEx, and financial undertaking Taxonomy KPI disclosures. - [ESMA - ESEF Reporting Manual](https://www.esma.europa.eu/sites/default/files/library/esma32-60-254_esef_reporting_manual.pdf?ref=sorena.io) - Primary source for XHTML, Inline XBRL, and filing-quality expectations relevant to digital annual reporting. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/requirements --- --- title: "EU CSRD Scope and Phasing by Company Type" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/scope-and-phasing-by-company-type" source_url: "https://www.sorena.io/artifacts/eu/csrd/scope-and-phasing-by-company-type" author: "Sorena AI" description: "Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings." keywords: - "EU CSRD scope and phasing" - "CSRD company type waves" - "CSRD public interest entity wave" - "CSRD listed SME wave" - "CSRD third country undertaking wave" - "stop the clock CSRD phasing" - "EU CSRD" - "Scope" - "Phasing" - "Company type" - "Directive (EU) 2025/794" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Scope and Phasing by Company Type Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. *EU CSRD* *Phasing* ## EU CSRD (Directive (EU) 2022/2464) Scope and phasing by company type This page is for teams that need the cleanest possible wave map by entity category. Use it to build the cover note for the reporting program and the reporting calendar. The current CSRD phasing logic only makes sense when company types are separated correctly. The categories below are the ones that matter most in practice for assigning the first reporting year under the current law. ## Category 1: legacy NFRD style public interest entities These entities entered first. They include large public interest entities exceeding 500 employees and the matching parent undertaking category. Their reporting already starts with financial years beginning on or after 1 January 2024. They should also check the 2025 quick fix because the relief affects their early ESRS cycles. - Current start year: 1 January 2024. - This wave was not postponed. - Quick fix may reduce some datapoint burden temporarily. ## Category 2: other large undertakings and other large groups This is the delayed second wave. Under the stop the clock amendment, these entities now start for financial years beginning on or after 1 January 2027. This group should use the extra time to harden the reporting system rather than to postpone all preparation. - Current start year: 1 January 2027. - Original earlier wave timing is superseded. - Scope and reporting boundary work should still start well before first live reporting. ## Category 3: listed SMEs and certain special financial or insurance categories The listed SME wave now starts with financial years beginning on or after 1 January 2028. This category also includes certain small and non-complex institutions and certain captive insurance or reinsurance undertakings where the legal conditions are met. A listed SME may have transitional options, but that does not remove the need for governance and data planning. - Current start year: 1 January 2028. - Check opt out availability and how it interacts with group or market expectations. - Keep a separate file for listed status and market publication needs. ## Category 4: third-country undertaking route The third-country undertaking route is separate from the Union incorporated wave map. It applies to certain non-EU undertakings with significant Union turnover and the required subsidiary or branch link. The reporting path is tied to the financial year 2028 framework. Treat this as its own scoping project because publication responsibility and standards logic differ from the main entity wave map. - Track third-country turnover and EU presence separately. - Identify the responsible EU subsidiary or branch early. - Watch for third-country ESRS delegated acts and equivalent reporting developments. *Recommended next step* *Placement: after the timeline or milestone section* ## Use EU CSRD (Directive (EU) 2022/2464) Scope and phasing by company type as a cited research workflow Research Copilot can take EU CSRD (Directive (EU) 2022/2464) Scope and phasing by company type from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSRD (Directive (EU) 2022/2464) Scope and phasing by company type](/solutions/research-copilot.md): Start from EU CSRD (Directive (EU) 2022/2464) Scope and phasing by company type and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Scope and phasing by company type. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Directive (EU) 2025/794 - stop the clock amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the two year postponement of the second and third CSRD reporting waves. - [Directive (EU) 2024/1306 - ESRS sector-specific and third-country deadline delay](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024L1306&ref=sorena.io) - Moved the deadline for sector-specific and third-country ESRS delegated acts to 30 June 2026. - [European Commission - Corporate sustainability reporting](https://finance.ec.europa.eu/capital-markets-union-and-financial-markets/company-reporting-and-auditing/company-reporting/corporate-sustainability-reporting_en?ref=sorena.io) - Official implementation overview for the CSRD, ESRS, quick fix, and related Omnibus developments. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/scope-and-phasing-by-company-type --- --- title: "EU CSRD Scope and Phasing by Company Type" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/scope-and-phasing-by-company-type" source_url: "https://www.sorena.io/artifacts/eu/csrd/scope-and-phasing-by-company-type" author: "Sorena AI" description: "Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings." keywords: - "EU CSRD scope and phasing" - "CSRD company type waves" - "CSRD public interest entity wave" - "CSRD listed SME wave" - "CSRD third country undertaking wave" - "stop the clock CSRD phasing" - "EU CSRD" - "Scope" - "Phasing" - "Company type" - "Directive (EU) 2025/794" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Scope and Phasing by Company Type Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. *EU CSRD* *Phasing* ## EU CSRD (Directive (EU) 2022/2464) Scope and phasing by company type This page is for teams that need the cleanest possible wave map by entity category. Use it to build the cover note for the reporting program and the reporting calendar. The current CSRD phasing logic only makes sense when company types are separated correctly. The categories below are the ones that matter most in practice for assigning the first reporting year under the current law. ## Category 1: legacy NFRD style public interest entities These entities entered first. They include large public interest entities exceeding 500 employees and the matching parent undertaking category. Their reporting already starts with financial years beginning on or after 1 January 2024. They should also check the 2025 quick fix because the relief affects their early ESRS cycles. - Current start year: 1 January 2024. - This wave was not postponed. - Quick fix may reduce some datapoint burden temporarily. ## Category 2: other large undertakings and other large groups This is the delayed second wave. Under the stop the clock amendment, these entities now start for financial years beginning on or after 1 January 2027. This group should use the extra time to harden the reporting system rather than to postpone all preparation. - Current start year: 1 January 2027. - Original earlier wave timing is superseded. - Scope and reporting boundary work should still start well before first live reporting. ## Category 3: listed SMEs and certain special financial or insurance categories The listed SME wave now starts with financial years beginning on or after 1 January 2028. This category also includes certain small and non-complex institutions and certain captive insurance or reinsurance undertakings where the legal conditions are met. A listed SME may have transitional options, but that does not remove the need for governance and data planning. - Current start year: 1 January 2028. - Check opt out availability and how it interacts with group or market expectations. - Keep a separate file for listed status and market publication needs. ## Category 4: third-country undertaking route The third-country undertaking route is separate from the Union incorporated wave map. It applies to certain non-EU undertakings with significant Union turnover and the required subsidiary or branch link. The reporting path is tied to the financial year 2028 framework. Treat this as its own scoping project because publication responsibility and standards logic differ from the main entity wave map. - Track third-country turnover and EU presence separately. - Identify the responsible EU subsidiary or branch early. - Watch for third-country ESRS delegated acts and equivalent reporting developments. *Recommended next step* *Placement: after the timeline or milestone section* ## Use EU CSRD (Directive (EU) 2022/2464) Scope and phasing by company type as a cited research workflow Research Copilot can take EU CSRD (Directive (EU) 2022/2464) Scope and phasing by company type from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU CSRD (Directive (EU) 2022/2464) Scope and phasing by company type](/solutions/research-copilot.md): Start from EU CSRD (Directive (EU) 2022/2464) Scope and phasing by company type and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Scope and phasing by company type. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Directive (EU) 2025/794 - stop the clock amendment](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current law for the two year postponement of the second and third CSRD reporting waves. - [Directive (EU) 2024/1306 - ESRS sector-specific and third-country deadline delay](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024L1306&ref=sorena.io) - Moved the deadline for sector-specific and third-country ESRS delegated acts to 30 June 2026. - [European Commission - Corporate sustainability reporting](https://finance.ec.europa.eu/capital-markets-union-and-financial-markets/company-reporting-and-auditing/company-reporting/corporate-sustainability-reporting_en?ref=sorena.io) - Official implementation overview for the CSRD, ESRS, quick fix, and related Omnibus developments. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Value Chain Data and Estimation | Practical Method for ESRS Reporting](/artifacts/eu/csrd/value-chain-data-and-estimation.md): Build a defensible CSRD value chain method using ESRS rules and official guidance. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/scope-and-phasing-by-company-type --- --- title: "EU CSRD Value Chain Data and Estimation" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/value-chain-data-and-estimation" source_url: "https://www.sorena.io/artifacts/eu/csrd/value-chain-data-and-estimation" author: "Sorena AI" description: "Build a defensible CSRD value chain method using ESRS rules and official guidance." keywords: - "EU CSRD value chain data" - "ESRS value chain estimation" - "CSRD best efforts value chain" - "upstream downstream value chain reporting" - "CSRD data gaps and estimates" - "EU CSRD" - "Value chain" - "Estimation" - "ESRS" - "Data quality" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Value Chain Data and Estimation Build a defensible CSRD value chain method using ESRS rules and official guidance. *EU CSRD* *Value Chain* ## EU CSRD (Directive (EU) 2022/2464) Value chain data and estimation Value chain data is usually the hardest part of the first CSRD cycles. Use this page to build a method that is defendable, reviewable, and designed to improve each cycle. The ESRS expect undertakings to consider upstream and downstream value chain effects. The law does not require perfect information on day one, but it does require a disciplined approach to collecting what is available, estimating what is not yet available, and explaining the efforts made, the remaining gaps, and the improvement path. ## Start with a value chain perimeter, not with a supplier survey The first step is to define which upstream and downstream activities are relevant to the reporting boundary and the material matters identified. Only then should the company design data requests and evidence logic. A survey first approach usually produces a lot of low value data and weak coverage of the real risks and impacts. - Define upstream and downstream perimeter linked to material matters. - Identify the highest value data dependencies first. - Separate mandatory data from useful but optional enrichment data. ## Use a clear data hierarchy A practical hierarchy starts with internal systems and controlled partner data, then moves to credible third-party datasets and structured estimation where direct data is missing. The hierarchy should be disclosed internally so reviewers know what they are looking at. Do not mix measured and estimated data without labels. - Priority 1: internal and controlled direct partner data. - Priority 2: external verified or credible dataset inputs. - Priority 3: documented estimation models with assumptions and validation checks. ## Document best efforts and remaining gaps Where not all necessary value chain information is available, the report should explain the efforts made to obtain it, why the information could not be fully obtained, and how the company plans to improve availability in the future. This is a legal disclosure point, not just a project management note. That means the collection log matters. - Keep outreach records and response rates. - Record why data gaps remain after outreach. - Publish the improvement path in a controlled way. ## Review estimates like financial reporting estimates Estimated value chain information should be reviewed with the same seriousness as significant financial reporting estimates. That means clear assumptions, validation, sensitivity awareness where relevant, and management review. Treating value chain estimates as informal ESG placeholders is a direct route to assurance issues. - Document assumptions, calculation logic, and validation steps. - Flag where estimates carry higher uncertainty. - Retain reviewer and approver sign off. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU CSRD (Directive (EU) 2022/2464) Value chain data and estimation across ESG workflows ESG Compliance can take EU CSRD (Directive (EU) 2022/2464) Value chain data and estimation from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSRD (Directive (EU) 2022/2464) Value chain data and estimation](/solutions/esg-compliance.md): Start from EU CSRD (Directive (EU) 2022/2464) Value chain data and estimation and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Value chain data and estimation. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [European Commission - FAQ on CSRD implementation](https://finance.ec.europa.eu/publications/frequently-asked-questions-implementation-eu-corporate-sustainability-reporting-rules_en?ref=sorena.io) - Official Commission answers on practical interpretation and rollout questions. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/value-chain-data-and-estimation --- --- title: "EU CSRD Value Chain Data and Estimation" canonical_url: "https://www.sorena.io/artifacts/eu/csrd/value-chain-data-and-estimation" source_url: "https://www.sorena.io/artifacts/eu/csrd/value-chain-data-and-estimation" author: "Sorena AI" description: "Build a defensible CSRD value chain method using ESRS rules and official guidance." keywords: - "EU CSRD value chain data" - "ESRS value chain estimation" - "CSRD best efforts value chain" - "upstream downstream value chain reporting" - "CSRD data gaps and estimates" - "EU CSRD" - "Value chain" - "Estimation" - "ESRS" - "Data quality" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU CSRD Value Chain Data and Estimation Build a defensible CSRD value chain method using ESRS rules and official guidance. *EU CSRD* *Value Chain* ## EU CSRD (Directive (EU) 2022/2464) Value chain data and estimation Value chain data is usually the hardest part of the first CSRD cycles. Use this page to build a method that is defendable, reviewable, and designed to improve each cycle. The ESRS expect undertakings to consider upstream and downstream value chain effects. The law does not require perfect information on day one, but it does require a disciplined approach to collecting what is available, estimating what is not yet available, and explaining the efforts made, the remaining gaps, and the improvement path. ## Start with a value chain perimeter, not with a supplier survey The first step is to define which upstream and downstream activities are relevant to the reporting boundary and the material matters identified. Only then should the company design data requests and evidence logic. A survey first approach usually produces a lot of low value data and weak coverage of the real risks and impacts. - Define upstream and downstream perimeter linked to material matters. - Identify the highest value data dependencies first. - Separate mandatory data from useful but optional enrichment data. ## Use a clear data hierarchy A practical hierarchy starts with internal systems and controlled partner data, then moves to credible third-party datasets and structured estimation where direct data is missing. The hierarchy should be disclosed internally so reviewers know what they are looking at. Do not mix measured and estimated data without labels. - Priority 1: internal and controlled direct partner data. - Priority 2: external verified or credible dataset inputs. - Priority 3: documented estimation models with assumptions and validation checks. ## Document best efforts and remaining gaps Where not all necessary value chain information is available, the report should explain the efforts made to obtain it, why the information could not be fully obtained, and how the company plans to improve availability in the future. This is a legal disclosure point, not just a project management note. That means the collection log matters. - Keep outreach records and response rates. - Record why data gaps remain after outreach. - Publish the improvement path in a controlled way. ## Review estimates like financial reporting estimates Estimated value chain information should be reviewed with the same seriousness as significant financial reporting estimates. That means clear assumptions, validation, sensitivity awareness where relevant, and management review. Treating value chain estimates as informal ESG placeholders is a direct route to assurance issues. - Document assumptions, calculation logic, and validation steps. - Flag where estimates carry higher uncertainty. - Retain reviewer and approver sign off. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU CSRD (Directive (EU) 2022/2464) Value chain data and estimation across ESG workflows ESG Compliance can take EU CSRD (Directive (EU) 2022/2464) Value chain data and estimation from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU CSRD (Directive (EU) 2022/2464) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU CSRD (Directive (EU) 2022/2464) Value chain data and estimation](/solutions/esg-compliance.md): Start from EU CSRD (Directive (EU) 2022/2464) Value chain data and estimation and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU CSRD (Directive (EU) 2022/2464)](/contact.md): Review your current process, evidence gaps, and next steps for EU CSRD (Directive (EU) 2022/2464) Value chain data and estimation. ## Primary sources - [Directive (EU) 2022/2464 - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Primary legal text for scope, phased application, management report sustainability statements, assurance, and digital markup requirements. - [Commission Delegated Regulation (EU) 2023/2772 - ESRS Set 1](https://eur-lex.europa.eu/eli/reg_del/2023/2772/oj/eng?ref=sorena.io) - Primary legal text for ESRS 1, ESRS 2, and the topical ESRS reporting architecture. - [European Commission - FAQ on CSRD implementation](https://finance.ec.europa.eu/publications/frequently-asked-questions-implementation-eu-corporate-sustainability-reporting-rules_en?ref=sorena.io) - Official Commission answers on practical interpretation and rollout questions. ## Related Topic Guides - [EU CSRD Applicability Test | Current Scope and Reporting Waves](/artifacts/eu/csrd/applicability-test.md): Use this CSRD applicability test to determine whether your entity is in scope, whether a group exemption applies. - [EU CSRD Assurance Ready Controls and Evidence | Limited Assurance Preparation](/artifacts/eu/csrd/assurance-ready-controls-and-evidence.md): Prepare CSRD reporting for limited assurance with controls that tie metrics, narratives, markup, and Taxonomy KPIs back to evidence. - [EU CSRD Checklist | Practical Reporting and ESRS Checklist](/artifacts/eu/csrd/checklist.md): Use this CSRD checklist to move from scope to report delivery. - [EU CSRD Compliance Guide | Reporting System, Controls, and Delivery Model](/artifacts/eu/csrd/compliance.md): Build a publication grade CSRD reporting system with the right scope memo, materiality process, ESRS data model, value chain logic, Taxonomy linkage. - [EU CSRD Deadlines and Compliance Calendar | Current Waves, Quick Fix, and Assurance Dates](/artifacts/eu/csrd/deadlines-and-compliance-calendar.md): Track the current CSRD reporting waves, the July 2025 stop the clock amendment, the July 2025 ESRS quick fix. - [EU CSRD Double Materiality Interview Question Bank | Practical Stakeholder Questions](/artifacts/eu/csrd/double-materiality-interview-question-bank.md): Use this CSRD question bank to run a stronger double materiality process. - [EU CSRD Double Materiality Method | Building a Reviewable ESRS Methodology](/artifacts/eu/csrd/double-materiality-method.md): Build a reviewable double materiality method for the CSRD and ESRS. - [EU CSRD ESRS Structure and Data Model | How to Organize ESRS Reporting](/artifacts/eu/csrd/esrs-structure-and-data-model.md): Understand how to organize ESRS reporting under the CSRD. - [EU CSRD FAQ | Current Answers on Waves, ESRS, Assurance, and Taxonomy](/artifacts/eu/csrd/faq.md): Get grounded answers to common CSRD questions, including the current reporting waves after the stop the clock amendment, ESRS quick-fix reliefs. - [EU CSRD Penalties and Fines | National Enforcement and Reporting Exposure](/artifacts/eu/csrd/penalties-and-fines.md): Understand how CSRD enforcement works in practice. This guide explains the role of national transposition, accounting and transparency law enforcement. - [EU CSRD Requirements | Article by Article Reporting and Assurance Map](/artifacts/eu/csrd/requirements.md): Map the core CSRD requirements by workstream, including the sustainability statement, ESRS, double materiality, value chain reporting, Taxonomy linkage. - [EU CSRD Scope and Phasing by Company Type | Current Wave Map by Entity Category](/artifacts/eu/csrd/scope-and-phasing-by-company-type.md): Review current CSRD phasing by company type, including wave one public interest entities, wave two large undertakings. - [EU CSRD vs IFRS S1 and S2 | Double Materiality versus Investor Focused Disclosure](/artifacts/eu/csrd/csrd-vs-ifrs-s1-and-s2.md): Compare the EU CSRD and ESRS with IFRS S1 and IFRS S2 using official sources. - [EU CSRD vs SEC Climate Disclosure Rule | Scope, Status, and Reporting Logic](/artifacts/eu/csrd/csrd-vs-sec-climate-disclosure-rule.md): Compare the EU CSRD and ESRS with the SEC climate disclosure rule using official sources. - [EU CSRD vs Taxonomy Alignment | ESRS Reporting versus Article 8 KPIs](/artifacts/eu/csrd/csrd-vs-taxonomy-alignment.md): Compare CSRD reporting with EU Taxonomy alignment disclosures. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/csrd/value-chain-data-and-estimation --- --- title: "Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/applicability-test" author: "Sorena AI" description: "Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification." published_at: "2026-03-04" updated_at: "2026-03-11" keywords: - "CRA applicability test" - "products with digital elements test" - "CRA scope test" - "CRA remote data processing test" - "CRA important critical products" - "CRA commercial activity" - "CRA operator roles" - "EU compliance" - "Cyber Resilience Act" - "CRA compliance" - "Applicability Test" - "Products with digital elements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Applicability Test Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. *Artifact Guide* *EU* ## EU Cyber Resilience Act, CRA Product Security and CE Marking Applicability Test Grounded implementation guidance for legal, product, and engineering teams. Use official CRA sources to translate obligations into owners, evidence, and shipping decisions. Use this page to reach a defensible yes or no answer for each product line. The output should be a short written record covering scope, exclusions, remote data processing, operator role, whether the product is default, important, or critical, and which dates matter. ## CRA applicability test step 1, define the product and the connectivity model Article 2 applies to products with digital elements made available on the market when their intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Start with the product boundary, not the brand name. List the hardware, software, firmware, and any remote data processing solution that is designed by the manufacturer, or under the manufacturer's responsibility, and whose absence would stop one of the product's functions. - Record whether the item is hardware, software, firmware, or a component placed on the market separately - Describe the direct or indirect connection to a device or network - Document which remote functions are required for the product to work and who controls that remote processing - Keep version, model, and deployment mode separate because CRA decisions are product specific *Recommended next step* *Placement: after the applicability result* ## Turn EU Cyber Resilience Act, CRA Product Security and CE Marking Applicability Test into an operational assessment Assessment Autopilot can take EU Cyber Resilience Act, CRA Product Security and CE Marking Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU Cyber Resilience Act, CRA Product Security and CE Marking can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Cyber Resilience Act, CRA Product Security and CE Marking Applicability Test](/solutions/assessment.md): Start from EU Cyber Resilience Act, CRA Product Security and CE Marking Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Cyber Resilience Act, CRA Product Security and CE Marking](/contact.md): Review your current process, evidence gaps, and next steps for EU Cyber Resilience Act, CRA Product Security and CE Marking Applicability Test. ## CRA applicability test step 2, test the exclusions before you do deeper work Some products are outside the CRA because other Union legislation already governs them or because Article 2 excludes them. Missing an exclusion creates wasted work and wrong declarations. You should also record when the product is a spare part replacing an identical component made to the same specifications, or when it is developed exclusively for national security or defence purposes. - Check medical devices, in vitro diagnostic medical devices, and whole vehicle type approval products listed in Article 2(2) - Check products certified under Regulation (EU) 2018/1139 and marine equipment under Directive 2014/90/EU - Check whether a delegated act under Article 2(5) limits or excludes CRA because sectoral rules address the same cybersecurity risks - Check spare parts and defence specific products under Article 2(6) and Article 2(7) ## CRA applicability test step 3, decide whether the product is made available on the Union market in commercial activity The CRA focuses on making available on the market. The Commission FAQ also clarifies that free and open source software is only in scope when it is made available on the market in the course of a commercial activity. Testing builds and public archives need special care. The FAQ confirms that manufacturers may maintain public software archives, but users should be informed about risks linked to unsupported software. - Document the distribution channel, monetisation model, and whether the product is supplied for distribution or use in the Union - For open source, record whether the release is commercial, who monetises it, and whether a steward or manufacturer role exists - For archive or test versions, document whether they are market offerings or controlled pre release builds - If the product was already placed on the market, note whether only Article 14 reporting will apply before the full CRA date ## CRA applicability test step 4, map the operator role and the reporting route Most CRA duties sit with manufacturers, but importers, distributors, authorised representatives, and open source software stewards also have defined obligations. You need this role map before building compliance ownership. For reporting, the main establishment in the Union is the Member State where decisions related to the cybersecurity of the products are predominantly taken. If there is no Union main establishment, the CRA uses a fallback order based on representatives, importers, distributors, and user location. - Confirm whether you act as manufacturer, importer, distributor, authorised representative, or open source software steward - Name the legal entity that takes cybersecurity decisions for the product - Decide which CSIRT designated as coordinator will be used for Article 14 submissions - Record escalation owners for legal, security, product, and customer communication ## CRA applicability test step 5, classify the product and map the dates Products whose core functionality matches Annex III are important products with digital elements. Annex IV covers critical products. The Commission FAQ stresses that integrating an important or critical component does not automatically make the whole finished product important or critical. The dates matter. Chapter IV on notified bodies applies from 11 June 2026. Article 14 reporting applies from 11 September 2026. The broader CRA obligations apply from 11 December 2027. - Check Annex III and Annex IV category fit using the product's core functionality, not incidental features - Record whether harmonised standards, common specifications, or certification schemes fully cover the relevant requirements - Flag products already on the market because Article 14 also applies to pre 11 December 2027 products that are in scope - Store the scoping decision in the technical documentation so later conformity work starts from the same assumptions ## Primary sources - [Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng?ref=sorena.io) - Primary legal text for scope, manufacturer duties, reporting, conformity assessment, technical documentation, market surveillance, and penalties. - [European Commission FAQ on the Cyber Resilience Act, version 1.2, January 2026](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Practical implementation clarifications on scope, open source, support period, conformity assessment, reporting, and transition issues. - [European Commission Cyber Resilience Act policy page](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act?ref=sorena.io) - Official timeline overview and implementation context. ## Related Topic Guides - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/applicability-test --- --- title: "Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/checklist" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/checklist" author: "Sorena AI" description: "Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations." published_at: "2026-03-04" updated_at: "2026-03-11" keywords: - "CRA checklist" - "Cyber Resilience Act checklist" - "CRA CE marking checklist" - "CRA Annex I checklist" - "CRA Article 14 checklist" - "CRA technical documentation checklist" - "CRA support period checklist" - "EU compliance" - "Cyber Resilience Act" - "CRA compliance" - "Checklist" - "Products with digital elements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Checklist Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. *Artifact Guide* *EU* ## EU Cyber Resilience Act, CRA Product Security and CE Marking Checklist Grounded implementation guidance for legal, product, and engineering teams. Use official CRA sources to translate obligations into owners, evidence, and shipping decisions. This checklist is meant to drive delivery. Every item should have an owner, a due date, an evidence link, and a review cadence. If you cannot point to evidence, assume the work is not yet done. ## Portfolio and classification checklist Start with inventory and product boundary decisions. This prevents teams from building controls around the wrong scope or applying one classification to every product in a family. The classification decision also drives your conformity route and the level of notified body engagement you may need. - List every product with digital elements, each version family, and each relevant deployment mode - Document any remote data processing solution that is necessary for product functions - Check Article 2 exclusions and any sector specific overlap - Assign each item to default, important class I, important class II, or critical product status *Recommended next step* *Placement: after the checklist block* ## Turn EU Cyber Resilience Act, CRA Product Security and CE Marking Checklist into an operational assessment Assessment Autopilot can take EU Cyber Resilience Act, CRA Product Security and CE Marking Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Cyber Resilience Act, CRA Product Security and CE Marking can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Cyber Resilience Act, CRA Product Security and CE Marking Checklist](/solutions/assessment.md): Start from EU Cyber Resilience Act, CRA Product Security and CE Marking Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Cyber Resilience Act, CRA Product Security and CE Marking](/contact.md): Review your current process, evidence gaps, and next steps for EU Cyber Resilience Act, CRA Product Security and CE Marking Checklist. ## CRA Annex I Part I product checklist Part I is about the product you place on the market. The risk assessment decides which Part I requirements are relevant, but you need an explicit record for every requirement, including justified non applicability. Release gates should test these controls before placing the product on the market. - No known exploitable vulnerabilities at release - Secure by default configuration with reset capability where applicable - Ability to provide security updates, with automatic installation enabled by default where applicable and a clear opt out - Controls for unauthorised access, confidentiality, integrity, availability, attack surface reduction, exploitation mitigation, logging, and secure data removal as relevant ## CRA Annex I Part II operations checklist Part II applies throughout the support period. It is the operating system for vulnerability handling, testing, disclosure, and secure update distribution. These are ongoing duties, not a single pre launch task. - Machine readable SBOM at least covering top level dependencies - Regular tests and reviews of product security - Coordinated vulnerability disclosure policy and clearly visible reporting contact - Security updates disseminated without delay and free of charge unless a tailor made business arrangement says otherwise ## CRA documentation and CE marking checklist Before placing the product on the market, draw up the technical documentation, complete the chosen conformity assessment procedure, issue the declaration of conformity, and then affix the CE marking. The support period is generally at least five years, unless the product is expected to be in use for less than five years, in which case it matches the expected use time. The technical documentation and declaration of conformity must be kept for at least ten years after placing on the market or for the support period, whichever is longer. - Technical documentation includes product description, risk assessment, support period rationale, standards used, alternative solutions, and test reports - Declaration of conformity is ready and version controlled - CE marking placement is defined for hardware or software products - Importer and distributor checklists confirm the declaration, CE marking, and user instructions are present ## CRA reporting and authority readiness checklist Article 14 starts before the rest of the CRA. Treat reporting as a live incident capability, not a future legal project. You also need an authority response pack for market surveillance questions and potential corrective actions. - Twenty four hour early warning template for actively exploited vulnerabilities and severe incidents - Seventy two hour notification templates plus final report workflows - User notification templates for impacted users and all users where appropriate - Authority response index for documentation, declarations, SBOM requests, and corrective action decisions ## Primary sources - [Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng?ref=sorena.io) - Primary legal text for scope, manufacturer duties, reporting, conformity assessment, technical documentation, market surveillance, and penalties. - [European Commission FAQ on the Cyber Resilience Act, version 1.2, January 2026](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Practical implementation clarifications on scope, open source, support period, conformity assessment, reporting, and transition issues. - [European Commission Cyber Resilience Act policy page](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act?ref=sorena.io) - Official timeline overview and implementation context. ## Related Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/checklist --- --- title: "Compliance Program" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/compliance" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/compliance" author: "Sorena AI" description: "Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting." published_at: "2026-03-04" updated_at: "2026-03-11" keywords: - "CRA compliance program" - "Cyber Resilience Act program" - "CRA governance" - "CRA engineering controls" - "CRA support period" - "CRA market surveillance" - "CRA reporting readiness" - "EU compliance" - "Cyber Resilience Act" - "CRA compliance" - "Compliance Program" - "Products with digital elements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Compliance Program Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. *Artifact Guide* *EU* ## EU Cyber Resilience Act, CRA Product Security and CE Marking Compliance Program Grounded implementation guidance for legal, product, and engineering teams. Use official CRA sources to translate obligations into owners, evidence, and shipping decisions. A workable CRA program connects law, engineering, release management, and support. The regulation does not ask for a policy shelf. It asks for secure products, documented evidence, and a vulnerability handling system that works for the full support period. ## CRA program design principle, manage by product, not by policy binder The CRA applies per product with digital elements. A portfolio program should therefore be a controlled set of product files, release controls, and support workflows, not one generic corporate statement. Create a single owner per product line and a central rule set for shared methods such as risk assessment, SBOM generation, disclosure, and reporting. - Product owner for scope, classification, and release decisions - Security owner for threat analysis, testing, vulnerability handling, and reporting escalation - Legal or compliance owner for declaration, authority response, and documentation retention - Operations owner for update distribution, support period notices, and customer communication ## CRA engineering workstream, map Annex I into release controls Annex I Part I should become measurable product controls. Annex I Part II should become recurring operating procedures. The strongest CRA programs use build pipelines, release checks, and ticket workflows to create evidence automatically. Do not leave requirement interpretation inside slide decks. Put it into tests, checklists, and documented decisions. - Release criterion for known exploitable vulnerabilities and secure by default configuration - SBOM production and dependency review as part of each release - Testing strategy that matches the threat model and risk level of the product - Update channels that preserve integrity, support rollback, and produce distribution logs ## CRA support-period workstream, plan for the years after launch The CRA support period is at least five years unless expected use is shorter. During that period, vulnerabilities in the product and in integrated components must be handled effectively. This means your product roadmap, resourcing model, and customer messaging need to include security maintenance, not just feature delivery. - Support period rationale stored in the technical documentation - End date of support period disclosed at purchase and retained in user information - Policy for unsupported archive releases and end of support notifications where technically feasible - Component life cycle review so third party component end of support does not break CRA compliance ## CRA reporting and authority-response workstream Article 14 reporting starts on 11 September 2026 and applies to pre 11 December 2027 products that fall in scope. The reporting process should be linked to incident response, vulnerability management, communications, and legal review. Market surveillance requests also need a ready response path because incomplete documentation is itself an enforcement risk. - Single reporting platform access and CSIRT routing decision - Decision tree for actively exploited vulnerability versus severe incident - Template pack for early warning, notification, final report, and user communications - Authority response pack including declaration of conformity, technical documentation index, and product history ## Executive metrics that show real CRA compliance Measure the quality of the operating system, not just the existence of documents. Good metrics tell you whether products remain compliant throughout the support period. Each metric should be attributable to a product family and reviewed on a regular cadence. - Percentage of in scope products with approved scope and classification records - Percentage of releases with current SBOM, risk assessment update, and test evidence - Time from awareness to escalation for potential Article 14 events - Support period coverage for third party components that provide core functions *Recommended next step* *Placement: after the compliance steps* ## Turn EU Cyber Resilience Act, CRA Product Security and CE Marking Compliance Program into an operational assessment Assessment Autopilot can take EU Cyber Resilience Act, CRA Product Security and CE Marking Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Cyber Resilience Act, CRA Product Security and CE Marking can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Cyber Resilience Act, CRA Product Security and CE Marking Compliance Program](/solutions/assessment.md): Start from EU Cyber Resilience Act, CRA Product Security and CE Marking Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Cyber Resilience Act, CRA Product Security and CE Marking](/contact.md): Review your current process, evidence gaps, and next steps for EU Cyber Resilience Act, CRA Product Security and CE Marking Compliance Program. ## Primary sources - [Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng?ref=sorena.io) - Primary legal text for scope, manufacturer duties, reporting, conformity assessment, technical documentation, market surveillance, and penalties. - [European Commission FAQ on the Cyber Resilience Act, version 1.2, January 2026](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Practical implementation clarifications on scope, open source, support period, conformity assessment, reporting, and transition issues. - [European Commission Cyber Resilience Act policy page](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act?ref=sorena.io) - Official timeline overview and implementation context. ## Related Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/compliance --- --- title: "Conformity Assessment and CE Marking" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking" author: "Sorena AI" description: "Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file." published_at: "2026-03-04" updated_at: "2026-03-11" keywords: - "CRA conformity assessment" - "CRA Module A" - "CRA Module B C" - "CRA Module H" - "CRA CE marking" - "CRA declaration of conformity" - "CRA notified bodies" - "EU compliance" - "Cyber Resilience Act" - "CRA compliance" - "Conformity Assessment and CE Marking" - "Products with digital elements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Conformity Assessment and CE Marking Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. *Artifact Guide* *EU* ## EU Cyber Resilience Act, CRA Product Security and CE Marking Conformity Assessment and CE Marking Grounded implementation guidance for legal, product, and engineering teams. Use official CRA sources to translate obligations into owners, evidence, and shipping decisions. Conformity assessment is where product classification, standards coverage, and evidence quality converge. The question is not only which route is legally available. The question is whether your route matches the product category, the standards actually applied, and the evidence you can defend. ## Choose the CRA conformity-assessment route from Article 32, not from preference Article 32 provides the main routes. Default products can use internal control under Module A. Important class I products can stay on that path only when harmonised standards, common specifications, or an appropriate certification scheme are fully applied for the relevant requirements. Important class II and critical products move into stronger routes. That usually means Module B plus C or Module H, with notified body involvement unless a specific certification route later applies. - Module A, internal control, is the baseline route in Article 32(1) - Important class I products move to Module B plus C or Module H when relevant standards or schemes are missing or only partly applied - Important class II products use Module B plus C or Module H - Critical products use the routes in Article 32(3) unless a future certification requirement under Article 8 applies ## What the CRA notified body will actually examine Notified body review is not a paperwork exercise. Annex VIII expects a technical design and development review, supporting evidence, risk analysis, and an assessment of the vulnerability handling process against Annex I Part II. Weak traceability between requirements, design choices, and test results is one of the fastest ways to create delay. - Technical documentation that specifies the applicable CRA requirements and how compliance is reached - Cybersecurity risk assessment with assumptions, intended purpose, foreseeable use, misuse, and support period logic - Evidence for both product properties in Annex I Part I and vulnerability handling processes in Annex I Part II - A change control process that flags modifications affecting conformity or the validity of an examination certificate ## CRA declaration of conformity and CE marking rules Once conformity is demonstrated, the manufacturer draws up the EU declaration of conformity under Article 28 and then affixes the CE marking under Article 30. For software products, the CE marking may be placed on the declaration of conformity or on the website accompanying the software product, provided the relevant section of the site is easily and directly accessible to consumers. - Use the Annex V model structure for the declaration of conformity - Keep the declaration and technical documentation for ten years after placing on the market or for the support period, whichever is longer - Make sure the declaration is available in the languages required by the Member State where the product is placed or made available on the market - If you provide a simplified declaration with the product, include the exact internet address for the full declaration ## Two CRA timing rules that change project planning Chapter IV on notification of conformity assessment bodies applies from 11 June 2026. That matters for planning notified body capacity and documentation readiness before the main CRA date. The Commission FAQ also notes that important and critical product categories received technical descriptions through Implementing Regulation (EU) 2025/2392, so category interpretation should be based on those descriptions and not only on plain language labels. - Reserve notified body lead time early if you have important or critical products - Use the technical category descriptions, not internal marketing language, when classifying products - Do not assume integration of an important or critical component changes the finished product category - Review whether a single technical file can cover CRA and other applicable Union product laws *Recommended next step* *Placement: after the main workflow section* ## Turn EU Cyber Resilience Act, CRA Product Security and CE Marking Conformity Assessment and CE Marking into an operational assessment Assessment Autopilot can take EU Cyber Resilience Act, CRA Product Security and CE Marking Conformity Assessment and CE Marking from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on EU Cyber Resilience Act, CRA Product Security and CE Marking can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Cyber Resilience Act, CRA Product Security and CE Marking Conformity Assessment and CE Marking](/solutions/assessment.md): Start from EU Cyber Resilience Act, CRA Product Security and CE Marking Conformity Assessment and CE Marking and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Cyber Resilience Act, CRA Product Security and CE Marking](/contact.md): Review your current process, evidence gaps, and next steps for EU Cyber Resilience Act, CRA Product Security and CE Marking Conformity Assessment and CE Marking. ## Primary sources - [Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng?ref=sorena.io) - Primary legal text for scope, manufacturer duties, reporting, conformity assessment, technical documentation, market surveillance, and penalties. - [European Commission FAQ on the Cyber Resilience Act, version 1.2, January 2026](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Practical implementation clarifications on scope, open source, support period, conformity assessment, reporting, and transition issues. - [Blue Guide 2022 on the implementation of EU product rules](https://op.europa.eu/en/publication-detail/-/publication/91a50d92-f745-11ec-b94a-01aa75ed71a1/language-en?ref=sorena.io) - Useful background on conformity assessment, CE marking, and technical documentation practice across Union product rules. ## Related Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking --- --- title: "CRA vs RED Cybersecurity Delegated Act" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act" author: "Sorena AI" description: "Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply." published_at: "2026-03-04" updated_at: "2026-03-11" keywords: - "CRA vs RED cybersecurity delegated act" - "Cyber Resilience Act vs RED" - "radio equipment cybersecurity CRA" - "Delegated Regulation 2022 30" - "EN 18031" - "CRA transition" - "EU compliance" - "Cyber Resilience Act" - "CRA compliance" - "Products with digital elements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA vs RED Cybersecurity Delegated Act Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. *Artifact Guide* *EU* ## EU Cyber Resilience Act, CRA Product Security and CE Marking CRA vs RED Cybersecurity Delegated Act Grounded implementation guidance for legal, product, and engineering teams. Use official CRA sources to translate obligations into owners, evidence, and shipping decisions. These two regimes both address cybersecurity in connected products, but they are not the same tool. The RED delegated act is a targeted regime for certain categories of radio equipment. The CRA is a horizontal product security regulation for products with digital elements across much of the internal market. ## Scope difference, RED radio equipment versus CRA horizontal product security The RED delegated act applies through Directive 2014/53/EU to specific radio equipment categories and to essential requirements linked to network protection, fraud protection, and privacy related safeguards. The CRA applies more broadly to products with digital elements with direct or indirect logical or physical data connection to a device or network. If your product is radio equipment, the first question is whether it falls within the delegated act category set. If it is wider software or hardware outside that set, the CRA analysis becomes more important. - RED delegated act is category specific and tied to radio equipment - CRA is horizontal and applies to software and hardware products with digital elements - RED focuses on Article 3(3)(d), (e), and (f) requirements under the Radio Equipment Directive - CRA adds support period, vulnerability handling, technical documentation, reporting, and market surveillance structure ## Date difference, the current CRA versus RED transition picture Delegated Regulation (EU) 2022/30 became applicable from 1 August 2025 because Delegated Regulation (EU) 2023/2444 deferred the original date. The CRA reporting obligations apply from 11 September 2026 and the wider CRA applies from 11 December 2027. The Commission FAQ states that the Commission aims to repeal the RED delegated act as of 11 December 2027 for legal clarity. That statement is implementation guidance, not a substitute for checking the law in force when you place a product on the market. - Products placed on the market from 1 August 2025 to 10 December 2027 may face RED cybersecurity delegated act obligations if they are in scope - Products placed on the market on or after 11 December 2027 should be assessed against the CRA position then in force - Do not assume a future repeal without checking the legal text applicable on the market entry date - Keep market entry date and legal basis in the product file for each release ## Requirements difference, RED targeted cybersecurity baseline versus the CRA product life cycle regime RED compliance is usually organised around essential requirements and harmonised standards such as the EN 18031 series. The CRA goes further into lifecycle duties, including SBOM, coordinated vulnerability disclosure, support period, user instructions, and mandatory reporting of actively exploited vulnerabilities and severe incidents. That means a team used to RED should expect broader operational obligations under the CRA even when the technical control themes overlap. - RED does not create the same Article 14 reporting system to ENISA and the CSIRT network - CRA requires support period determination and disclosure - CRA includes explicit Annex I Part II vulnerability handling duties - CRA creates dedicated conformity routes for important and critical products with digital elements ## Planning rule for mixed CRA and RED portfolios If you sell connected devices that are radio equipment, create a dual track transition plan. Use the RED delegated act for products entering the market before the CRA main application date where the delegated act still governs. Prepare the CRA operating model in parallel because reporting starts earlier than full application. The practical mistake to avoid is waiting for the CRA main date before building vulnerability handling and authority response capabilities. - Track each product by legal basis and market entry date - Map current standards coverage and future CRA evidence gaps - Prepare a single evidence architecture where possible, even if legal routes differ - Review the transition again before every major release window *Recommended next step* *Placement: after the comparison section* ## Use EU Cyber Resilience Act, CRA Product Security and CE Marking CRA vs RED Cybersecurity Delegated Act as a cited research workflow Research Copilot can take EU Cyber Resilience Act, CRA Product Security and CE Marking CRA vs RED Cybersecurity Delegated Act from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Cyber Resilience Act, CRA Product Security and CE Marking can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Cyber Resilience Act, CRA Product Security and CE Marking CRA vs RED Cybersecurity Delegated Act](/solutions/research-copilot.md): Start from EU Cyber Resilience Act, CRA Product Security and CE Marking CRA vs RED Cybersecurity Delegated Act and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Cyber Resilience Act, CRA Product Security and CE Marking](/contact.md): Review your current process, evidence gaps, and next steps for EU Cyber Resilience Act, CRA Product Security and CE Marking CRA vs RED Cybersecurity Delegated Act. ## Primary sources - [Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng?ref=sorena.io) - Primary legal text for scope, manufacturer duties, reporting, conformity assessment, technical documentation, market surveillance, and penalties. - [European Commission FAQ on the Cyber Resilience Act, version 1.2, January 2026](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Practical implementation clarifications on scope, open source, support period, conformity assessment, reporting, and transition issues. - [Commission Delegated Regulation (EU) 2022/30 under the Radio Equipment Directive](https://eur-lex.europa.eu/eli/reg_del/2022/30/oj/eng?ref=sorena.io) - Legal text for the RED cybersecurity delegated act. - [Commission Delegated Regulation (EU) 2023/2444](https://eur-lex.europa.eu/eli/reg_del/2023/2444/oj/eng?locale=en) - Defers the application of the RED cybersecurity delegated act to 1 August 2025. ## Related Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act --- --- title: "CRA vs UK PSTI Act" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act" author: "Sorena AI" description: "Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule." published_at: "2026-03-04" updated_at: "2026-03-11" keywords: - "CRA vs UK PSTI" - "Cyber Resilience Act vs PSTI" - "EU CRA UK product security" - "PSTI statement of compliance" - "CRA support period" - "CRA CE marking" - "EU compliance" - "Cyber Resilience Act" - "CRA compliance" - "CRA vs UK PSTI Act" - "Products with digital elements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA vs UK PSTI Act Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. *Artifact Guide* *EU* ## EU Cyber Resilience Act, CRA Product Security and CE Marking CRA vs UK PSTI Act Grounded implementation guidance for legal, product, and engineering teams. Use official CRA sources to translate obligations into owners, evidence, and shipping decisions. The CRA and the UK PSTI regime are related in policy direction, but they are not interchangeable. The CRA is a broad Union product cybersecurity regime. The UK PSTI regime is a narrower consumer connectable product regime built around a small set of baseline security requirements. ## Scope difference, broad product coverage in the Union, narrower consumer scope in the UK The CRA applies to products with digital elements across software and hardware where the use includes a direct or indirect connection to a device or network, subject to the Article 2 exclusions. The UK PSTI regime focuses on relevant connectable products and the designated supply chain actors in the UK market. In practice, a business selling consumer smart devices in both markets may face both regimes, but the scope analysis should be done separately. - CRA covers a wider set of software and hardware products with digital elements - PSTI targets relevant connectable consumer products and designated supply chain roles - A product can be in scope of both regimes if it is sold in both markets - Do not rely on one market assessment to answer the other market's scope question *Recommended next step* *Placement: after the comparison section* ## Use EU Cyber Resilience Act, CRA Product Security and CE Marking CRA vs UK PSTI Act as a cited research workflow Research Copilot can take EU Cyber Resilience Act, CRA Product Security and CE Marking CRA vs UK PSTI Act from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Cyber Resilience Act, CRA Product Security and CE Marking can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Cyber Resilience Act, CRA Product Security and CE Marking CRA vs UK PSTI Act](/solutions/research-copilot.md): Start from EU Cyber Resilience Act, CRA Product Security and CE Marking CRA vs UK PSTI Act and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Cyber Resilience Act, CRA Product Security and CE Marking](/contact.md): Review your current process, evidence gaps, and next steps for EU Cyber Resilience Act, CRA Product Security and CE Marking CRA vs UK PSTI Act. ## Requirement difference, three UK PSTI baseline requirements versus the CRA life cycle model The UK product security regime is built around three baseline requirements reflected in the 2023 Regulations and official guidance: no universal default passwords, a vulnerability reporting route, and published information on the minimum security update period. The CRA goes much further. It adds risk based product properties in Annex I Part I, mandatory vulnerability handling duties in Annex I Part II, technical documentation, declaration of conformity, CE marking, and Article 14 reporting. - PSTI requires a statement of compliance, not CRA style CE marking and declaration of conformity - PSTI does not create the same mandatory ENISA and CSIRT reporting path - CRA sets a minimum five year support period unless expected use is shorter, while PSTI requires clear publication of the minimum update period - CRA includes importer and distributor duties tied to Union product law style conformity architecture ## Timeline difference between the CRA and the UK PSTI Act, and operational planning The UK regime came into force on 29 April 2024. CRA reporting starts on 11 September 2026 and the main CRA obligations apply from 11 December 2027. Teams that sell into both markets should not wait for 2027 to improve vulnerability intake, support disclosures, and update mechanisms because those same capabilities support PSTI today. - Use PSTI work to strengthen the CRA support period and disclosure foundation - Do not assume PSTI compliance is enough for CRA market entry - Add Union specific declaration, technical documentation, and reporting workstreams for CRA - Maintain separate legal evidence packs even where engineering controls overlap ## Best way to run dual CRA and UK PSTI compliance The efficient approach is a shared product security baseline with jurisdiction specific evidence layers. Engineering should not run two different security programs. Legal and market entry teams should, however, keep distinct records for the EU and the UK requirements. This gives you one product security pipeline but two regulatory output packs. - Shared controls, password management, update pipeline, vulnerability intake, and advisory process - EU specific CRA files for risk assessment, Annex I mapping, declaration, CE marking, and Article 14 reporting - UK specific PSTI files for statement of compliance and consumer facing update period disclosures - Market entry checklist that checks the right evidence before each regional release ## Primary sources - [Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng?ref=sorena.io) - Primary legal text for scope, manufacturer duties, reporting, conformity assessment, technical documentation, market surveillance, and penalties. - [UK product security regime guidance](https://www.gov.uk/government/publications/the-uk-product-security-and-telecommunications-infrastructure-product-security-regime) - Official GOV.UK guidance on the UK product security regime, requirements, and the 29 April 2024 start date. - [Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents/made) - UK statutory instrument specifying the security requirements. - [PSTI Act explanatory notes, product security provisions](https://www.legislation.gov.uk/ukpga/2022/46/notes/division/6/index.htm) - Explains the intent of the three initial security requirements. ## Related Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act --- --- title: "Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date." published_at: "2026-03-04" updated_at: "2026-03-11" keywords: - "CRA deadlines" - "Cyber Resilience Act timeline" - "CRA reporting date" - "CRA 11 September 2026" - "CRA 11 December 2027" - "CRA compliance calendar" - "EU compliance" - "Cyber Resilience Act" - "CRA compliance" - "Deadlines and Compliance Calendar" - "Products with digital elements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Deadlines and Compliance Calendar Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. *Artifact Guide* *EU* ## EU Cyber Resilience Act, CRA Product Security and CE Marking Deadlines and Compliance Calendar Grounded implementation guidance for legal, product, and engineering teams. Use official CRA sources to translate obligations into owners, evidence, and shipping decisions. The CRA timeline is staggered. Good programs use that stagger to front load scoping, reporting, and evidence design instead of waiting for 2027. This page turns the dates into workstreams you can assign now, and it also flags the March 2026 draft-guidance milestone that many teams should use for implementation planning. ## The four CRA dates that matter most The CRA entered into force on 10 December 2024. That did not mean every obligation applied immediately, but it started the implementation clock for manufacturers, authorities, and standards bodies. The next two dates matter for operating capability and external assurance, and the final date matters for placing products on the market under the full regime. - 10 December 2024, regulation entered into force - 11 June 2026, Chapter IV on notification of conformity assessment bodies applies - 11 September 2026, Article 14 reporting obligations apply - 11 December 2027, the wider CRA obligations apply ## Why the March 2026 CRA draft guidance matters On 3 March 2026, the Commission published draft CRA guidance for feedback. It is not yet final law, but it is the clearest current Commission statement on remote data processing, open source software, support periods, and the interaction between CRA duties and other Union product rules. The feedback period runs until 31 March 2026. Teams should use this draft guidance to pressure-test product scoping, reporting ownership, and support-period rationale, while still anchoring final legal positions in the regulation itself until the guidance is formally adopted. - 3 March 2026, draft Commission guidance published for feedback - 31 March 2026, feedback period closes - Use the draft guidance to review scope, support period, and Article 14 processes before the June and September 2026 milestones - Do not treat the draft guidance as binding until the Commission formally adopts it ## What should be complete before 11 June 2026 under the CRA By the time the notified body framework is live, important and critical product teams should already know which product families may need external conformity assessment and what evidence will be expected. This is also the stage to stabilise classification and technical documentation structures. - Product inventory and classification complete - Conformity route chosen for each important and critical product family - Technical documentation repository structure agreed - Budget and lead time planning in place for notified body engagement if needed ## What should be complete before 11 September 2026 under the CRA Article 14 is an operational milestone, not a legal note in a tracker. By this date you need reporting templates, routing, user communication workflows, and incident escalation that can distinguish an actively exploited vulnerability from a severe incident. Remember that the CRA makes Article 14 applicable to all in scope products placed on the market before 11 December 2027 as well. - Single reporting platform access plan and CSIRT routing decision - Twenty four hour, seventy two hour, and final report templates approved - User communication and customer support workflows tested - Legacy in market products mapped to reporting ownership ## What should be complete before 11 December 2027 under the CRA This is the full market entry date. Products placed on the market from this date need the full CRA stack, including Annex I controls, support period determination, user information, technical documentation, declaration of conformity, and CE marking. The worst possible plan is to start building the technical file in late 2027. Most of the evidence should already be flowing from your normal release and support process. - Risk assessment and Annex I mapping complete for every in scope product - Support period determined, documented, and disclosed at purchase - Declaration of conformity ready and CE marking rules implemented - Importer and distributor checks ready for market launch ## CRA calendar rule for long-support products The calendar does not stop at market entry. The support period can run for years, and the CRA keeps applying throughout that period. Product calendars should therefore include recurring reviews, update availability checks, component support reviews, and end of support communication milestones. If your product remains in use for a long time, those recurring dates may create more work than the launch date itself. - Quarterly component and dependency support review - Recurring review of testing coverage and threat assumptions - Update availability retention for at least ten years or the remainder of the support period, whichever is longer - End of support communication planning before the final support date *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU Cyber Resilience Act, CRA Product Security and CE Marking Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take EU Cyber Resilience Act, CRA Product Security and CE Marking Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Cyber Resilience Act, CRA Product Security and CE Marking can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Cyber Resilience Act, CRA Product Security and CE Marking Deadlines and Compliance Calendar](/solutions/assessment.md): Start from EU Cyber Resilience Act, CRA Product Security and CE Marking Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Cyber Resilience Act, CRA Product Security and CE Marking](/contact.md): Review your current process, evidence gaps, and next steps for EU Cyber Resilience Act, CRA Product Security and CE Marking Deadlines and Compliance Calendar. ## Primary sources - [Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng?ref=sorena.io) - Primary legal text for scope, manufacturer duties, reporting, conformity assessment, technical documentation, market surveillance, and penalties. - [European Commission FAQ on the Cyber Resilience Act, version 1.2, January 2026](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Practical implementation clarifications on scope, open source, support period, conformity assessment, reporting, and transition issues. - [European Commission Cyber Resilience Act policy page](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act?ref=sorena.io) - Official timeline overview and implementation context. - [Commission publishes for feedback draft guidance to assist companies in applying the Cyber Resilience Act, 3 March 2026](https://digital-strategy.ec.europa.eu/en/news/commission-publishes-feedback-draft-guidance-assist-companies-applying-cyber-resilience-act?ref=sorena.io) - Official Commission announcement of the draft CRA guidance, including the feedback window and the focus on scope, open source software, remote data processing, and support periods. ## Related Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar --- --- title: "Essential Cybersecurity Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements" author: "Sorena AI" description: "Understand the CRA essential cybersecurity requirements in Annex I." published_at: "2026-03-04" updated_at: "2026-03-11" keywords: - "CRA Annex I" - "CRA essential cybersecurity requirements" - "CRA Part I" - "CRA Part II" - "CRA secure by default" - "CRA vulnerability handling requirements" - "EU compliance" - "Cyber Resilience Act" - "CRA compliance" - "Essential Cybersecurity Requirements" - "Products with digital elements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Essential Cybersecurity Requirements Understand the CRA essential cybersecurity requirements in Annex I. *Artifact Guide* *EU* ## EU Cyber Resilience Act, CRA Product Security and CE Marking Essential Cybersecurity Requirements Grounded implementation guidance for legal, product, and engineering teams. Use official CRA sources to translate obligations into owners, evidence, and shipping decisions. Annex I is the heart of the CRA. Part I covers the product properties that follow from the cybersecurity risk assessment. Part II covers the vulnerability handling obligations that apply throughout the support period. Treat them differently, but design them to work together. ## CRA Annex I Part I, risk based product requirements Part I is not a checklist where every item applies to every product in the same way. The CRA and the Commission FAQ make clear that the risk assessment determines which Part I requirements are relevant, and where a requirement is not applicable the manufacturer must justify that in the technical documentation. The practical consequence is that you need a requirement by requirement applicability record, not a vague statement that the product is low risk. - No known exploitable vulnerabilities when the product is placed on the market - Secure by default configuration, including reset capability where relevant - Security updates, including automatic security updates by default where applicable with a clear opt out - Controls for access, confidentiality, integrity, data minimisation, availability, attack surface reduction, exploitation mitigation, logging, and secure removal of data and settings where relevant *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU Cyber Resilience Act, CRA Product Security and CE Marking Essential Cybersecurity Requirements into an operational assessment Assessment Autopilot can take EU Cyber Resilience Act, CRA Product Security and CE Marking Essential Cybersecurity Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Cyber Resilience Act, CRA Product Security and CE Marking can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Cyber Resilience Act, CRA Product Security and CE Marking Essential Cybersecurity Requirements](/solutions/assessment.md): Start from EU Cyber Resilience Act, CRA Product Security and CE Marking Essential Cybersecurity Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Cyber Resilience Act, CRA Product Security and CE Marking](/contact.md): Review your current process, evidence gaps, and next steps for EU Cyber Resilience Act, CRA Product Security and CE Marking Essential Cybersecurity Requirements. ## CRA Annex I Part II, mandatory life cycle duties Part II is different. These obligations are not optional and do not switch off because the product category looks simple. They apply from placing on the market and throughout the support period. This is where CRA becomes an operating system for product security rather than a launch only review. - Identify and document vulnerabilities and components, including through an SBOM in a commonly used machine readable format - Address and remediate vulnerabilities without delay, including by providing security updates - Run effective and regular tests and reviews of security - Put in place coordinated vulnerability disclosure, a reporting contact, secure update distribution, and free security updates unless a tailor made business arrangement says otherwise ## How to turn CRA Annex I into engineering work The right model is to map each Annex I point to a design decision, a control owner, a test method, and an evidence artifact. This gives you a traceable technical file and makes market surveillance responses much faster. Avoid long prose only narratives. Reviewers need to see how a requirement was satisfied or why it was not relevant. - Requirement mapping table with applicability, control, test, evidence link, and owner - Threat model and risk assessment linked to Part I applicability decisions - Release checks linked to no known exploitable vulnerabilities and secure by default settings - Support workflows linked to Part II duties such as testing, update release, and public vulnerability information ## Evidence CRA authorities will expect Technical documentation under Article 31 and Annex VII should make the Annex I story visible. Good evidence is versioned, timestamped, and linked to a controlled process. The Commission FAQ also highlights that the risk assessment should be updated when relevant information emerges from tests, reviews, or third party information. - Current cybersecurity risk assessment - Release evidence for secure defaults and vulnerability status at market entry - Testing outputs and review records during the support period - Advisories, update records, and user information linked to fixed vulnerabilities ## Primary sources - [Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng?ref=sorena.io) - Primary legal text for scope, manufacturer duties, reporting, conformity assessment, technical documentation, market surveillance, and penalties. - [European Commission FAQ on the Cyber Resilience Act, version 1.2, January 2026](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Practical implementation clarifications on scope, open source, support period, conformity assessment, reporting, and transition issues. - [European Commission Cyber Resilience Act policy page](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act?ref=sorena.io) - Official timeline overview and implementation context. ## Related Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements --- --- title: "CRA Blue Guide Concepts FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts" author: "Sorena AI" description: "CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA Blue Guide FAQ" - "placing on the market CRA" - "making available on the market CRA" - "CRA distance sales" - "CRA imported products" - "CRA transition stock" - "CRA unfinished software testing" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" - "CRA Blue Guide concepts FAQ" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Blue Guide Concepts FAQ CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Blue Guide Concepts Understand the market-access concepts that drive CRA timing, compliance cutoffs, and transition decisions, including placing on the market, making available, imports, online sales, and unfinished software testing. Built for legal, compliance, product, and operations teams that need defensible CRA timing decisions. This FAQ focuses on the Blue Guide concepts that matter most for CRA implementation. If your team is arguing about placement dates, distance sales, warehouse stock, imports, transition inventory, or whether unfinished software can be tested before full compliance, these are the concepts you need to get right. ## Why does the Blue Guide matter for CRA interpretation? Because the CRA sits within the New Legislative Framework product-law architecture and uses the same core concepts that the Blue Guide explains, including placing on the market, making available on the market, CE marking, technical documentation, declarations of conformity, notified bodies, and market surveillance. The Commission's CRA FAQ repeatedly relies on the Blue Guide when explaining those concepts, and the draft Commission guidance expressly describes the CRA as being built on the NLF. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 1.2, 2.2 to 2.8, 4.3, 4.4 and 7 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 1.4, 4.1.7, 4.1.8, 6.6, 6.8 and 7.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - introduction and section 2.1 ## What is "placing on the market" for CRA purposes? It is the first making available of an individual product on the Union market. That is the decisive timing point for CRA compliance, because the applicable requirements are assessed when the individual product is first placed on the market. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(21), Article 6 and Article 13 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 1.4 and 7.2 ## What must already be complete when a product is placed on the market? The required compliance work must already be complete at that point. The Blue Guide says that, by the time of placing on the market, the manufacturer must have completed the design work against the applicable requirements, the relevant risk and conformity assessment, the declaration of conformity, the marking steps and the technical file. The CRA aligns with that logic by requiring the technical documentation to be drawn up before placement on the market and the cybersecurity risk assessment to be included in it. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3, including footnote 55 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(4), Article 13(12), Article 28, Article 30 and Article 31 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.6, 6.7 and 6.8 ## What is "making available on the market"? It is the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge. Once a product has already been placed on the market, later supplies in the distribution chain are usually cases of making available, not new placing-on-the-market events. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 2.2 and 2.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(22) ## Does placing on the market happen once per model or once per individual unit? Once per individual product. The Blue Guide explains that placing on the market refers to each individual product, not to a model or type. That is why units of an existing model first placed on the market after new requirements apply must comply with the new rules. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.2 ## Does placing on the market require payment? No. The Blue Guide explains that the first supply can be for payment or free of charge. What matters is that the product is complete and supplied for distribution, consumption or use on the Union market. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## Does placing on the market require physical handover of the product? No. The Blue Guide says placing on the market requires a completed product and an offer or agreement transferring ownership, possession or another property right, but it does not require physical handover. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## Does stock in a manufacturer's or importer's warehouse count as placing on the market? No, not by itself. Products kept in the stock of the manufacturer, the authorised representative or the importer are not yet placed on the market if they have not yet been supplied for distribution, consumption or use. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## Can an internal transfer within the manufacturer's own distribution structure count as placing on the market? Yes. The first supply for distribution on the Union market can still be a placing-on-the-market event even if it happens through the manufacturer's own commercial chain rather than through an unrelated distributor. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## If the manufacturer first supplies the product to an importer, distributor or end user, which transaction matters for placing on the market? The first one. For the individual product, the legal placing-on-the-market event is the first supply for distribution, consumption or use on the Union market, whether that first supply is to an importer, a distributor or directly to the end user. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## Does a pre-order or contract signed before manufacture is complete count as placing on the market? No. The Blue Guide explains that placing on the market requires the manufacturing stage to be complete. An offer or agreement concluded before the product is finished is not yet placing on the market. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## How do distance sales and online sales affect CRA timing? They can bring a product into EU product-law scope before physical delivery to the customer. If an online or distance offer is targeted at Union end users, the product is deemed to be made available on the Union market for market-surveillance purposes. The Blue Guide says that whether an offer targets Union end users must be assessed case by case, taking into account factors such as dispatch areas, ordering languages and payment possibilities; mere website accessibility is not enough. Where the product is already manufactured and ready to be shipped, a direct distance sale to an EU end user can also be the placing-on-the-market event for that individual product. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.4 and example 5 in section 2.12 ## Does an online offer targeting EU customers mean the product is already placed on the market? Not necessarily. The Blue Guide distinguishes between products being deemed made available on the Union market for market-surveillance purposes and the actual placing-on-the-market event for the individual product. The latter still depends on the distribution chain and on whether the product is already manufactured and supplied for distribution or use. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.4 ## When do imported products count as placed on the Union market? Often at release for free circulation, but not always. The Blue Guide says products declared for release for free circulation can generally be treated as placed on the market, while also making clear that in practice placing on the market may happen before or after that customs step depending on the distribution chain. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.5 and examples 2 and 7 in section 2.12 ## Are products in transit, free zones or temporary storage already placed on the market? No. The Blue Guide says placing on the market is considered not to take place where products are introduced into the EU customs territory in transit, placed in free zones, temporary storage, warehouses or other special customs procedures. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 2.3 and 2.5 ## If a consumer buys a product in a third country while physically present there and brings it into the EU for personal use, is that placing on the market? No. The Blue Guide treats that situation as outside placing on the market. It also distinguishes it from products bought online and shipped into the EU, which do not fall under that carve-out. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3, including footnote 50 ## Does manufacturing for one's own use count as placing on the market under the CRA? Usually no. The Blue Guide says placing on the market does not occur where a product is manufactured for one's own use unless the legislation in question expressly treats own use as an equivalent trigger. The Commission's CRA FAQ applies that logic to the CRA and explains that products developed only for the manufacturer's own use are outside scope unless they are separately placed on the market. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.5 ## What is "putting into service," and does it usually matter under the CRA? The Blue Guide defines it as the first use of a product within the Union by the end user for its intended purpose. That concept matters in some Union product laws, but the CRA's general trigger structure is built around placing on the market and making available on the market, not a separate general putting-into-service trigger. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.6 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(21), Article 3(22), Article 6 and Article 13 ## If a product was lawfully placed on the market before new CRA rules applied, can it still be sold later? Yes, in principle. The Blue Guide explains that once a compliant product has been placed on the market, it may continue to be made available later in the distribution chain even if the law changes afterward or the relevant harmonised standards are revised, unless the new legislation provides otherwise. The Commission's CRA FAQ applies the same logic to the CRA transition. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 2.3, 2.10 and 4.1.2.5 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 1.4 and 7.2 ## If stock was already lawfully placed on the market, can it stay in a distributor warehouse and still be sold after the CRA legal change date? Yes. The relevant question is whether the individual product had already been placed on the market before the new rules applied. If it had, later storage and resale within the distribution chain do not create a new placing-on-the-market event. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 2.3 and 2.10 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.2 ## Does repeated renting create a new placing-on-the-market event? No. The Blue Guide says repeated renting of the same product does not create a new placing-on-the-market event. The compliance moment remains the first renting or other first supply of that individual product. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## Are prototypes or pre-production units shown at trade fairs or demonstrations already placed on the market? No, provided the Blue Guide and CRA conditions are met. The Blue Guide treats products displayed or operated under controlled conditions at trade fairs, exhibitions or demonstrations as not yet placed on the market, as long as they are clearly identified as non-compliant and not yet available for placing on the market. The CRA contains the same type of carve-out for products, including prototypes, presented or used at such events. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 4(2) and recital 36 ## Can unfinished software be made available for testing before full CRA compliance? Yes, but only under a narrow CRA exception. Article 4(3) allows unfinished software such as alpha versions, beta versions or release candidates to be made available on the market for the limited period required for testing, provided it carries a visible sign stating that it does not comply and is not available for purposes other than testing. Recital 37 also says manufacturers should not force users to upgrade to versions released only for testing purposes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 4(3) and recital 37 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 2.3, including footnote 7 ## Why does the Blue Guide matter for technical documentation and declarations of conformity under the CRA? Because the CRA uses the same NLF documentation logic. The Blue Guide explains the role of technical documentation and the possibility of a single declaration of conformity dossier across several Union acts. The Commission's CRA FAQ relies on that same logic when explaining what technical documentation must contain and how the declaration of conformity works under the CRA. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 4.3 and 4.4 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 28(3), Article 31 and Annex VII - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.8, 6.6 and 6.8 ## Why does the Blue Guide matter for intended purpose and reasonably foreseeable use under the CRA? Because the CRA uses the same product-law logic that compliance cannot be assessed only against the manufacturer's preferred use case. The Commission's CRA FAQ relies on Blue Guide concepts to explain that the cybersecurity risk assessment must take account of intended purpose, reasonably foreseeable use and reasonably foreseeable misuse, and that those choices also affect the user information that has to be provided. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 2.8 and 3.1 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.4, 4.1.5, 4.1.7 and 4.1.8 ## How are Blue Guide market-placement concepts applied to standalone software supplied digitally? For software, the CRA follows the same NLF concepts, but the draft Commission guidance explains how they work in a digital delivery model. According to the draft guidance, once the software manufacturing phase is complete and a given software product is first offered for distribution or use on the Union market in the course of a commercial activity, that software product is regarded as placed on the market. Later downloads or remote access to that same unchanged software product are instances of making available rather than fresh placing-on-the-market events. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(21) and Article 3(22) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 2.1, points 10 to 14 ## Does a later software version that is not a substantial modification get a new placing-on-the-market date? No. The draft guidance says later iterations that do not qualify as substantial modifications do not trigger a new conformity assessment and do not change the software product's date of placement on the market. A new placing-on-the-market date arises only where the later iteration qualifies as a substantial modification. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(30) and recital 41 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 2.1, points 15 and 16 ## Does the same software-placement rule apply where software is supplied on physical media or combined with hardware? No. The draft guidance says the "first offering creates the placing-on-the-market date" logic applies only to standalone software supplied via digital means. If the software is supplied on a USB flash drive or other physical medium, the physical item is the product supplied for distribution. If software is necessary for hardware to perform its intended functions, the hardware and that software together form the product placed on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 2.1, point 16, and section 2.2, points 17 to 19 ## Primary sources - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 1.2, 2.2 to 2.8, 4.3, 4.4 and 7 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 1.4, 4.1.7, 4.1.8, 6.6, 6.8 and 7.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - introduction and section 2.1 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(21), Article 6 and Article 13 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 1.4 and 7.2 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3, including footnote 55 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(4), Article 13(12), Article 28, Article 30 and Article 31 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.6, 6.7 and 6.8 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 2.2 and 2.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(22) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.2 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.4 and example 5 in section 2.12 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.4 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.5 and examples 2 and 7 in section 2.12 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 2.3 and 2.5 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3, including footnote 50 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.5 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.6 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(21), Article 3(22), Article 6 and Article 13 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 2.3, 2.10 and 4.1.2.5 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 2.3 and 2.10 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 4(2) and recital 36 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 4(3) and recital 37 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 2.3, including footnote 7 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 4.3 and 4.4 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 28(3), Article 31 and Annex VII - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.8, 6.6 and 6.8 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 2.8 and 3.1 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.4, 4.1.5, 4.1.7 and 4.1.8 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(21) and Article 3(22) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 2.1, points 10 to 14 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(30) and recital 41 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 2.1, points 15 and 16 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 2.1, point 16, and section 2.2, points 17 to 19 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after the FAQ section* ## Use Blue Guide Concepts FAQ as a cited research workflow Research Copilot can turn this blue guide concepts FAQ into a reusable cited workflow for product, legal, engineering, and compliance teams working through CRA decisions. - [Open Research Copilot](/solutions/research-copilot.md): Start from the blue guide concepts questions that block launch, review, and evidence workflows. - [Talk through your CRA implementation](/contact.md): Review evidence gaps, ownership, and next steps for your current product portfolio. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts --- --- title: "CRA CE Marking FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/ce-marking" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/ce-marking" author: "Sorena AI" description: "CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA CE marking FAQ" - "CE marking CRA software" - "CRA website CE marking" - "CRA notified body number" - "CRA declaration of conformity" - "CRA importer distributor CE checks" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA CE Marking FAQ CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ CE Marking Use this CRA CE marking FAQ to understand what the mark means, when it can be affixed, where it must appear for hardware and software, and what importers, distributors, and notified-body routes change in practice. Built for teams preparing conformity assessment, launch readiness, packaging, software distribution, and market-access controls. CE marking under the CRA is not just a label question. It sits on top of conformity assessment, technical documentation, declarations of conformity, launch timing, and operator responsibilities. This FAQ isolates the issues that usually create avoidable mistakes before release. ## What does the CE marking mean under the CRA? Under the CRA, the CE marking is the manufacturer's visible indication that the product with digital elements, and the processes put in place by the manufacturer, conform to the CRA's essential cybersecurity requirements and to any other applicable Union harmonisation legislation that also provides for CE marking. It is the visible consequence of the conformity-assessment process. It is not a separate licence or approval stamp issued by authorities. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(31), Article 29, Article 30 and recital 89 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.7 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.1 and Annex 5 FAQ ## What legal effect does the CE marking have for market access? It supports free circulation by signalling presumed compliance with the applicable CE-marking legislation. The Blue Guide explains that products bearing the CE marking are presumed to comply with the applicable Union harmonisation legislation and therefore benefit from free circulation. The CRA follows the same logic: Member States must not impede the making available on the market of products that comply with the Regulation, and recital 36 links that free movement function to CRA CE marking. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 4(1), Article 30(5) and recital 36 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.1 and Annex 5 FAQ ## Is CE marking mandatory for products in scope of the CRA? Yes, as the general rule for products with digital elements that are placed on the Union market under the CRA. The manufacturer must affix the CE marking before placing the product on the market, after the applicable conformity assessment has been completed. The Blue Guide also makes clear that products not covered by Union legislation providing for CE marking must not bear the CE marking. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.7 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.6 and Annex 5 FAQ ## Does the CE marking mean the product was tested or approved by an authority? No, not as a general rule. The CE marking remains the manufacturer's declaration of conformity on its sole responsibility. Some CRA conformity-assessment routes involve a notified body, but the CE marking does not by itself mean that a public authority approved the product. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.4.2, 5.4.3 and 6.7 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.1 and Annex 5 FAQ ## Does the CE marking mean the product was made in the EU? No. The CE marking indicates conformity with the applicable legislation. It is not a mark of origin and does not show where the product was manufactured. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.1 and Annex 5 FAQ ## Who may affix the CE marking under the CRA? The manufacturer may affix it, and the Blue Guide also recognises affixing by an authorised representative acting on the manufacturer's behalf. Even where an authorised representative is used, the manufacturer remains ultimately responsible for conformity and for the CE marking. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12), Article 29 and Article 30 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.3 and Annex 5 FAQ ## Can someone other than the original manufacturer become responsible for CE marking? Yes. Under the CRA, an importer or distributor that places a product on the market under its own name or trademark, or that carries out a substantial modification, is treated as the manufacturer. A different natural or legal person that substantially modifies a product and makes it available on the market can also become the manufacturer for the affected product or part. The Blue Guide reflects the same general NLF logic. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 21 and Article 22 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.3 and Annex 5 FAQ ## When must the CE marking be affixed? Before the product with digital elements is placed on the market. That means the manufacturer cannot defer CE marking until after launch or leave it to later stages in the distribution chain. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(3) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.4 and section 4.5.1.6 ## Can the CE marking be affixed before the conformity assessment is complete? No. The manufacturer must first complete the applicable conformity assessment procedure with a positive result. The CRA FAQ states this directly, and the Blue Guide says the CE marking may not, in principle, be affixed until the conformity assessment has been completed. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12) and Article 30(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.7 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.4 and Annex 5 FAQ ## Where must the CE marking be placed on a physical product? As a rule, it must be affixed visibly, legibly and indelibly to the product itself. If that is not possible or not warranted because of the nature of the product, the CRA requires it to be affixed to the packaging and to the EU declaration of conformity accompanying the product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(1) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.4 and Annex 5 FAQ ## Can the CE marking be moved to the packaging just because the product design would look cleaner without it? No. The Blue Guide is clear that moving the CE marking off the product cannot be justified on purely aesthetic grounds. The exception is only for cases where affixing it to the product is not possible or not warranted because of the product's nature. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.7 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.4 ## Can a physical product rely on a website-only CE marking? No. Under Article 30(1), the CRA gives the website option only for products with digital elements in the form of software. For other products, the rule is product first, with packaging and accompanying EU declaration of conformity as the fallback where the nature of the product justifies it. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(1) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.4 ## Where does the CE marking go for software products? For software products, the CE marking must be affixed either to the EU declaration of conformity or on the website accompanying the software product. If the website option is used, the relevant section must be easily and directly accessible to consumers. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.7 ## What size and visibility rules apply to the CE marking? It must be visible, legible and indelible. The height may be below 5 mm only where the nature of the product justifies that and the mark still remains visible and legible. The CRA FAQ adds that reduced size cannot be justified by aesthetics alone and that the mark should not be placed where it is not easily visible in the product's intended use. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(1) and Article 30(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.7 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.4 ## Can a physical product use only an electronic label or on-screen CE marking? Not as a purely electronic-only substitute. The Blue Guide says electronic labelling only is not allowed. At the same time, it notes that some on-product technological solutions, such as certain LCD displays, can be acceptable where they still satisfy the visibility, legibility and indelibility requirements. For software, the CRA separately allows the CE marking on the accompanying website or EU declaration of conformity. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(1) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.4, including footnote 237 ## Can other markings appear next to the CE marking? Yes, but only within limits. Under the CRA, the CE marking may be followed by a pictogram or other mark indicating a special cybersecurity risk or use if such markings are set out in implementing acts. More generally, the Blue Guide allows additional markings only where they serve a different function, do not create confusion with the CE marking, and do not reduce its visibility or legibility. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(3) and Article 30(6) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.7 and Annex 5 FAQ ## When must the notified body's identification number follow the CE marking? Under the CRA, only where the conformity assessment procedure is based on full quality assurance under module H. That is different from module B+C. Under module B+C, the manufacturer affixes the CE marking after obtaining the EU-type certificate, but Article 30(4) does not require the notified body's identification number to follow the CE marking for that route. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(4) and Annex VIII Part IV, point 5.1 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.4.2 and 5.4.3 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.5 ## Can the CE marking and notified body number be affixed outside the EU? Yes. The Blue Guide explains that the CE marking and, where relevant, the notified body's identification number do not need to be affixed within the Union. They may also be affixed in a third country, for example where the product is manufactured there. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.5 ## Can an open-source software steward affix the CE marking? No. The CRA recital on open-source software stewards says they should not be permitted to affix the CE marking to the products with digital elements whose development they support, because that light-touch steward regime does not make them subject to the same obligations as manufacturers. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 19 ## Does a CE-marked component automatically mean the final product is CE-compliant? No. The Blue Guide says CE-marked components or parts do not automatically guarantee that the finished product complies. The manufacturer of the finished product must still verify the finished product as such. The CRA FAQ makes the same practical point from the component-due-diligence angle: CE-marked components can support the manufacturer's compliance work, but the CRA does not require manufacturers to integrate only CE-marked components. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.1 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.4.1 and 4.4.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 34 and recital 35 ## What if the product is also subject to other EU laws that require CE marking? The same CE marking indicates that the product also meets those other applicable Union harmonisation acts. That is also why the CRA requires a single EU declaration of conformity when multiple applicable Union acts apply to the same product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 28(3) and Article 30(5) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.1 and section 4.5.1.6 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.7 and 6.8 ## What do importers and distributors need to check in practice about CRA CE marking? Importers must ensure before placing the product on the market that the product bears the CE marking and is accompanied by the EU declaration of conformity and the required user information. Distributors must verify before making the product available that the product bears the CE marking and that the specified manufacturer and importer obligations have been met. So CE marking is not only a manufacturer-side issue. Other economic operators are expected to check for it as part of their own CRA duties. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 19(2)(c) and Article 20(2) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - Annex 5 FAQ ## Can a non-compliant product be shown without CE marking at a trade fair or demonstration? Yes, if it is not yet being made available on the market. The CRA allows the presentation or use of a non-compliant product, including a prototype, at trade fairs, exhibitions, demonstrations or similar events, provided that it carries a visible sign clearly stating that it does not comply and will not be made available on the market until it does. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 4(2) and recital 36 ## Can unfinished software be distributed for testing without full CRA compliance and CE marking? Yes, but only within the CRA's specific testing exception. Article 4(3) allows unfinished software to be made available for a limited period required for testing purposes if it carries a visible sign stating that it does not comply with the CRA and is not available for purposes other than testing. Recital 37 and the Commission FAQ explain that this covers alpha, beta and release candidate software, that manufacturers should perform a risk assessment and comply to the extent possible with the relevant security and vulnerability-handling requirements, and that they should not force users to upgrade to testing versions. Article 4(4) excludes certain safety components from this exception. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 4(3), Article 4(4) and recital 37 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.6 ## Does affixing the CE marking end the manufacturer's CRA responsibilities? No. CE marking comes after conformity assessment, but the manufacturer still has continuing obligations under the CRA, including vulnerability handling, support-period duties, corrective actions, and keeping the technical documentation and declaration of conformity available for the required period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7) to 13(13), Article 28, Article 31(2) and Annex I Part II ## What happens if the CE-marking rules are not met? Missing or improper CE marking is treated as formal non-compliance under the CRA. Market surveillance authorities must require the relevant manufacturer to end the non-compliance. If the problem persists, Member States must take appropriate measures to restrict or prohibit the product from being made available on the market or to ensure recall or withdrawal. In addition, non-compliance with Article 30(1) to (4) can trigger administrative fines under Article 64(3). Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 58(1) to (2) and Article 64(3) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.8 ## Primary sources - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(31), Article 29, Article 30 and recital 89 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.7 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.1 and Annex 5 FAQ - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 4(1), Article 30(5) and recital 36 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(3) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.6 and Annex 5 FAQ - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.4.2, 5.4.3 and 6.7 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12), Article 29 and Article 30 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.3 and Annex 5 FAQ - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 21 and Article 22 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.4 and section 4.5.1.6 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12) and Article 30(3) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.4 and Annex 5 FAQ - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(1) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.4 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(1) and Article 30(2) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.4, including footnote 237 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(3) and Article 30(6) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.7 and Annex 5 FAQ - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(4) and Annex VIII Part IV, point 5.1 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.4.2 and 5.4.3 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.5 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 19 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.1 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.4.1 and 4.4.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 34 and recital 35 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 28(3) and Article 30(5) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.1 and section 4.5.1.6 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.7 and 6.8 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 19(2)(c) and Article 20(2) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - Annex 5 FAQ - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 4(2) and recital 36 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 4(3), Article 4(4) and recital 37 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.6 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7) to 13(13), Article 28, Article 31(2) and Annex I Part II - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 58(1) to (2) and Article 64(3) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.5.1.8 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after the FAQ section* ## Use CE Marking FAQ as a cited research workflow Research Copilot can turn this ce marking FAQ into a reusable cited workflow for product, legal, engineering, and compliance teams working through CRA decisions. - [Open Research Copilot](/solutions/research-copilot.md): Start from the ce marking questions that block launch, review, and evidence workflows. - [Talk through your CRA implementation](/contact.md): Review evidence gaps, ownership, and next steps for your current product portfolio. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/ce-marking --- --- title: "CRA Component Due Diligence FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/component-due-diligence" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/component-due-diligence" author: "Sorena AI" description: "CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA component due diligence FAQ" - "CRA third-party components" - "CRA FOSS components" - "CRA SBOM due diligence" - "CRA upstream vulnerability reporting" - "CRA component support period" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Component Due Diligence FAQ CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Component Due Diligence Use this CRA FAQ to understand what due diligence the manufacturer owes when integrating third-party software, hardware, open-source components, and dependency-backed product functions. Built for product security, engineering, supply chain, legal, and compliance teams managing component risk under Article 13. Component due diligence is one of the easiest CRA obligations to underestimate. The manufacturer remains responsible for the finished product, even when the risk originates in third-party software, hardware, FOSS, or dependency-backed services. This FAQ turns the abstract duty into operational checks and evidence expectations. ## What does the CRA require when a manufacturer integrates third-party components? The manufacturer must exercise due diligence so that third-party components do not compromise the cybersecurity of the finished product. This obligation sits inside Article 13 and supports the manufacturer's broader duty to ensure that the product is designed, developed and produced in accordance with the CRA's essential cybersecurity requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(1) and Article 13(5) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.4.1 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 7.3, points 151 to 157 ## Does component due diligence apply only to components that are themselves CRA products? No. The CRA expressly says the obligation also covers free and open-source software components that were not made available on the market in the course of a commercial activity. The Commission's FAQ also confirms that manufacturers may integrate components that are outside the CRA, pre-date CRA application, or have not been placed on the market, but they still have to ensure those components do not compromise the finished product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(5), recital 34 and recital 35 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.4.1, 4.4.3 and 4.4.4 ## Is the same level of due diligence required for every component? No. The CRA materials make this a risk-based obligation. The appropriate level of due diligence depends on the nature and level of cybersecurity risk associated with the component, and the product's cybersecurity risk assessment also informs how much checking is appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 34 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.4.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 7.3, points 154 to 157 ## What kinds of checks can CRA component due diligence include? The CRA materials give a non-exhaustive set of examples. Depending on the component and the level of risk, due diligence can include: - checking whether the component already bears the CE marking - checking whether the component manufacturer has demonstrated conformity with the CRA - verifying that the component receives regular security updates, for example by checking its update history - checking the European vulnerability database or other publicly accessible vulnerability databases for applicable vulnerabilities - carrying out additional security testing - performing software composition analysis - reviewing the component's SBOM when available - checking the component's support period - verifying that the component's intended purpose fits the integrating manufacturer's use - assessing the security posture of the component manufacturer Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 34 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.4.2 ## What kinds of additional security testing are mentioned specifically for CRA component due diligence? The Commission's FAQ gives examples such as fuzz testing, penetration testing, firmware analysis, side-channel analysis, red-team exercises, network traffic analysis, and sensor spoofing. Those are examples, not a mandatory checklist. The right testing depth still depends on the component's role and risk. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.4.2 ## Does a component have to bear the CE marking before it can be integrated? No. The CRA does not require manufacturers to integrate only CE-marked components. Components that were not placed on the market, were placed on the market before the CRA applies, or fall outside the CRA can still be integrated, provided the integrating manufacturer exercises due diligence so they do not compromise the finished product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(5) and recital 35 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.4.1 and 4.4.3 ## If a component does bear the CE marking, can the manufacturer rely on that? Yes, but only as supporting evidence. The Commission's FAQ says that when integrating components that bear the CE marking, manufacturers may rely on the component's EU declaration of conformity and accompanying documentation to support their own compliance. That still does not remove the integrating manufacturer's own obligation to make sure the component is suitable for the finished product and does not compromise its cybersecurity. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.4.1 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 7.3, point 155 ## What if the component was integrated before the CRA became applicable and cannot yet be checked for CRA conformity? The CRA anticipated that situation. Recital 35 says that immediately after the transition period a manufacturer may not yet be able to verify, for example by checking CE marking, that a previously integrated component's manufacturer has demonstrated conformity with the CRA. In that case, the manufacturer should exercise due diligence through other means. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 35 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.4.1 ## How is component due diligence different from the CRA cybersecurity risk assessment? They are distinct but complementary obligations. The draft Commission guidance explains that the cybersecurity risk assessment under Article 13(2) covers the risks affecting the product as a whole, including external dependencies and operating context. Due diligence under Article 13(5) focuses more specifically on third-party components that form part of the product and on verifying, in a risk-based way, that those components match the product's cybersecurity needs. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2) to Article 13(5) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 7.3, points 151 to 157 ## What kind of evidence can support CRA component due diligence in practice? The draft Commission guidance says evidence may consist of documentation obtained from the component manufacturer, such as technical specifications, security documentation, or relevant conformity or assurance documentation. Where appropriate, the manufacturer may also carry out functional tests on the component. The CRA also requires manufacturers to systematically document relevant cybersecurity aspects and to keep technical documentation showing conformity, so this material will normally form part of the broader compliance record for the product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Article 31 and Annex VII - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 7.3, point 155 ## Does the CRA require the manufacturer to make the component SBOM public? No. The CRA encourages identification and documentation of components, including by drawing up an SBOM, and the Commission's FAQ lists review of a component SBOM, when available, as one possible due-diligence step. But the CRA recital also says manufacturers should not be obliged to make the SBOM public. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 77, Annex I Part II point 1, and Annex VII point 6(b) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.4.2 ## What happens if the manufacturer identifies a vulnerability in an integrated component? The manufacturer must report the vulnerability to the person or entity manufacturing or maintaining the component and must address and remediate it in line with the CRA's vulnerability-handling requirements. The draft guidance adds two important limits: the upstream-reporting obligation concerns the version of the component that the manufacturer actually integrates, and it covers vulnerabilities that exist in the integrated component itself, not vulnerabilities caused only by the manufacturer's own integration choices. If the manufacturer develops a software or hardware modification to address the vulnerability in that component, it must share the relevant code or documentation with the person or entity manufacturing or maintaining the component, where appropriate in a machine-readable format. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.6 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 9.2.1, points 201 to 205 ## Can the integrating manufacturer rely on the component manufacturer's own vulnerability handling? Often yes, but not completely. Where the component itself was placed on the market after the CRA applies, the integrating manufacturer can benefit from the component manufacturer's own vulnerability-handling obligations. But the integrating manufacturer still remains responsible for the finished product and must continue to meet its own vulnerability-handling duties for that product as a whole. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.6 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) to Article 13(8) ## If the manufacturer contributes code to an upstream FOSS component, does that make it responsible for that component's own CRA compliance? No, not by itself. The draft guidance says that manufacturers integrating FOSS components do not become responsible for those components' individual CRA compliance merely because they contribute source code to their maintenance. The status of that FOSS component depends on whether the entity that publishes it places it on the market. The integrating manufacturer still remains responsible for its own product and must still perform due diligence on the FOSS component it uses. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 18 and Article 13(5) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 3.4, points 80 to 83 ## How does due diligence work for open-source components that are outside the CRA manufacturer regime? The same due-diligence obligation still applies. Manufacturers may integrate open-source components that are outside the CRA because they were not made available on the market in the course of a commercial activity, but they still have to apply risk-based due diligence. The CRA also empowers the Commission to establish voluntary security attestation programmes that could help manufacturers assess such open-source components. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(5), Article 25 and recital 34 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.4.4 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 3.4, points 81 to 83 ## How should manufacturers treat integrated third-party SaaS, PaaS or similar solutions that are necessary for product functions but are not designed or developed by the manufacturer? The draft guidance says those solutions should be treated like third-party components. Where the solution is necessary for the product to perform one of its functions but is not designed and developed by the manufacturer or under its responsibility, the manufacturer should assess the integration risks in the cybersecurity risk assessment, mitigate them through product-level measures, and exercise due diligence on that third-party solution. The guidance gives this logic for examples such as third-party SaaS support chat, PaaS notification environments and SaaS storage services. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 8.2.1, points 185 and 186, and section 8.3.1 to 8.3.3 ## Does every external dependency need Article 13(5) due diligence? No. The draft guidance distinguishes between integrated third-party components and mere communication or connectivity enablers. For example, a cellular network that a smartphone uses for connectivity is not treated like a third-party component, because there is no software integrated into the product from that network provider. In that scenario, the guidance says it is not necessary to exercise due diligence obligations toward the network provider. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 8.3.5 ## Must the manufacturer report upstream if the component no longer has a maintainer or if the manufacturer maintains an independent fork? Not necessarily. The draft guidance says manufacturers are not required to report upstream where the component no longer has a maintainer. It also says upstream reporting is not required where the manufacturer has duplicated a FOSS component and no longer relies on the original maintainer for new versions or security fixes. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 9.2.1, point 203 ## If the manufacturer shares a security fix upstream, must it ensure that the maintainer accepts or merges it? No. The draft guidance says the CRA requires the manufacturer to share the fix, where appropriate, but not to ensure that the maintainer accepts it or integrates it into the component's codebase. It also does not require the manufacturer to accept a fix proposed by the maintainer if the manufacturer prefers another suitable mitigation. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 9.2.1, points 205 to 207 ## Does the support period of integrated components matter for CRA component due diligence? Yes. The Commission's FAQ expressly lists the support period of a component as one of the due-diligence checks manufacturers may undertake, and Article 13(8) allows manufacturers to take into account the support periods of third-party integrated components that provide core functions when determining the support period for their own product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.4.2 and 4.3.7 ## Does due diligence mean proving that every component is perfect or vulnerability-free before integration? No. The CRA sets a due-diligence obligation aimed at ensuring that integrated components do not compromise the finished product's cybersecurity. The Commission's FAQ and draft guidance both describe a risk-based process of verification, testing, mitigation and remediation, not a requirement to prove that every component is free of all flaws in every context. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(5) to Article 13(8) and recital 34 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.6, 4.4.2 and 4.4.3 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 7.3, points 154 to 157 ## Primary sources - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(1) and Article 13(5) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.4.1 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 7.3, points 151 to 157 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(5), recital 34 and recital 35 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.4.1, 4.4.3 and 4.4.4 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 34 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.4.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 7.3, points 154 to 157 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(5) and recital 35 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.4.1 and 4.4.3 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 7.3, point 155 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 35 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2) to Article 13(5) - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Article 31 and Annex VII - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 77, Annex I Part II point 1, and Annex VII point 6(b) - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.6 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 9.2.1, points 201 to 205 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) to Article 13(8) - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 18 and Article 13(5) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 3.4, points 80 to 83 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(5), Article 25 and recital 34 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.4.4 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 3.4, points 81 to 83 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 8.2.1, points 185 and 186, and section 8.3.1 to 8.3.3 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 8.3.5 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 9.2.1, point 203 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 9.2.1, points 205 to 207 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.4.2 and 4.3.7 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(5) to Article 13(8) and recital 34 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.6, 4.4.2 and 4.4.3 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after the FAQ section* ## Use Component Due Diligence FAQ as a cited research workflow Research Copilot can turn this component due diligence FAQ into a reusable cited workflow for product, legal, engineering, and compliance teams working through CRA decisions. - [Open Research Copilot](/solutions/research-copilot.md): Start from the component due diligence questions that block launch, review, and evidence workflows. - [Talk through your CRA implementation](/contact.md): Review evidence gaps, ownership, and next steps for your current product portfolio. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/component-due-diligence --- --- title: "CRA Conformity Assessment Routes FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes" author: "Sorena AI" description: "CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA conformity assessment routes FAQ" - "CRA module A" - "CRA module B+C" - "CRA module H" - "CRA important products route" - "CRA critical products route" - "CRA Article 32" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Conformity Assessment Routes FAQ CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Conformity Assessment Routes Use this CRA FAQ to understand which conformity assessment route applies, when module A is enough, when module B+C or module H is required, and how standards, certification schemes, and product classification affect the answer. Built for compliance, certification, product, legal, and engineering teams planning CRA market access. Conformity assessment route selection is where CRA classification turns into real launch obligations. This FAQ focuses on the route logic under Article 32, the practical meaning of module A, module B+C and module H, and the edge cases that change whether third-party assessment is required. ## What conformity assessment routes does the CRA recognise? The CRA recognises four ways to demonstrate conformity with the essential cybersecurity requirements: - internal control based on module A - EU-type examination based on module B followed by conformity to EU-type based on module C - full quality assurance based on module H - where available and applicable, a European cybersecurity certification scheme specified under Article 27(9) Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1) and Annex VIII - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6 ## What decides which CRA conformity assessment route a manufacturer has to use? The starting point is the product's classification under the CRA. Manufacturers first need to determine whether the product is in the default category, an important product of class I, an important product of class II, or a critical product. That depends on the product's core functionality, not simply on the fact that it includes components that are themselves important or critical products. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 7(1), Article 8(1) and Article 32 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 3.1, 3.2 and 6 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 121 to 123 and 126 ## Which CRA conformity assessment route applies to products in the default category? Products in the default category can always use module A. They may also use module B+C or module H if the manufacturer chooses, because Article 32(1) makes those routes generally available. The key point is that the CRA does not require third-party conformity assessment for default-category products. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.1 and section 6.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 122 ## When can an important product of class I use module A? An important product of class I can use module A if, in assessing compliance, the manufacturer has applied relevant harmonised standards, common specifications, or European cybersecurity certification schemes at assurance level at least substantial. If those instruments have not been applied, have been applied only in part, or do not exist, Article 32(2) requires the relevant essential cybersecurity requirements to be covered through module B+C or module H instead. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27 and Article 32(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.1 and 6.2 ## What if a harmonised standard covers the core functionality of an important class I product, but not every cybersecurity risk of the full product? The draft Commission guidance takes the view that the manufacturer may still use internal control if the harmonised standard covers the product's core functionality. But that does not mean the whole product automatically benefits from a full presumption of conformity. The guidance explains that the manufacturer still has to address additional risks presented by broader product scope or additional functions, and the presumption of conformity extends only to the parts covered by the standard. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(1), Article 27(5), Article 32(2) and Annex VII point 5 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 132 to 139 ## Which routes apply to important products of class II? Important products of class II must use one of these routes: - module B+C - module H - where available and applicable, a European cybersecurity certification scheme specified under Article 27(9) at assurance level at least substantial Outside the free and open-source software exception in Article 32(5), module A is not available for class II products. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(3) and Article 32(5) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.1 and 6.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 132 ## Which routes apply to critical products with digital elements? Critical products listed in Annex IV must use: - a European cybersecurity certification scheme where Article 8(1) requires one, or - if the conditions in Article 8(1) are not met, one of the class II routes in Article 32(3) So critical products do not automatically have to use the same third-party route in every case. The legal answer depends first on whether a certification scheme has been made mandatory under Article 8(1). Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 8(1) and Article 32(4) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.2 ## Does integrating an important or critical component automatically force the finished product into the corresponding route? No. The CRA and the Commission FAQ both say that integrating an important or critical product into another product does not by itself make the finished product subject to the conformity assessment regime for that component category. The decisive factor is the core functionality of the finished product as a whole. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 7(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 3.2 and 3.4 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 136 ## Does the CRA provide a special route for free and open-source software in Annex III categories? Yes. Manufacturers of products qualifying as free and open-source software that fall under Annex III categories may use any of the Article 32(1) procedures, including module A, provided that the technical documentation is made available to the public at the time of placing the product on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(5) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.1 and 6.2 ## Can a manufacturer choose a stricter CRA conformity assessment route than the minimum route required by law? Yes. The CRA sets minimum route requirements for certain product categories, but the manufacturer can still choose a more demanding route. For example, a default-category product may still go through module B+C or module H, and a class I product that could rely on module A may still opt for third-party assessment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.1, 6.2 and 6.3 ## What does module A mean in practice? Module A is the internal control route. Under this route, the manufacturer verifies that the product complies with the CRA, draws up the technical documentation, performs the necessary testing or equivalent verification, and declares compliance on its sole responsibility. No notified body participates. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part I - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.1 ## What does module B+C mean in practice? Module B+C combines notified-body examination of the design and development phase with manufacturer responsibility for conformity to the approved type in production. The notified body examines the design, technical documentation, supporting evidence and specimens under module B. The manufacturer then ensures under module C that the manufactured units conform to the approved type and remains responsible for production conformity. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Parts II and III - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.2 ## What does module H mean in practice? Module H is full quality assurance. Under this route, the manufacturer operates an approved quality system covering design, development, production, final inspection and testing, and a notified body assesses and surveils that system. This is why module H can be attractive for manufacturers with larger product portfolios or products subject to frequent updates. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.3 ## Do CRA conformity assessment routes assess only the product, or also the manufacturer's processes? They assess both. Article 32 requires conformity assessment of the product with digital elements and the processes put in place by the manufacturer. That is why the Annex VIII procedures also cover vulnerability handling processes and, depending on the route, production controls or quality-system controls. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1) and Annex VIII - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.1, 6.2 and 6.3 ## How do high-risk AI systems affect CRA route selection? As a rule, Article 12 says the relevant conformity assessment procedure under the AI Act applies to products that are both CRA products and high-risk AI systems, for the cybersecurity requirements addressed by the CRA. But the CRA creates an important derogation. Important and critical CRA products that are also high-risk AI systems, and that would otherwise only be subject to AI Act internal control, must still follow the CRA conformity assessment procedures for the CRA cybersecurity requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 12(2) and Article 12(3) ## Can existing certificates issued under other EU product laws still be used during the CRA transition? Yes, but only within limits. Article 69(1) says EU-type examination certificates and approval decisions issued regarding cybersecurity requirements under other Union harmonisation legislation remain valid until 11 June 2028 unless they expire earlier or the other legislation says otherwise. The draft Commission guidance adds that manufacturers may rely on those certificates only for the cybersecurity risks and corresponding requirements they actually cover, and that even if the other legislation gives a longer validity period, reliance for CRA purposes does not continue beyond 11 June 2028. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(1) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 222 to 224 and 227 ## Do products designed before 11 December 2027 still need a CRA conformity assessment if new units are placed on the market later? Yes. The CRA applies to individual products placed on the market from 11 December 2027 onward, not only to newly designed product types. The draft Commission guidance explains, however, that for products designed before the CRA applied, the manufacturer can demonstrate compliance through a current cybersecurity risk assessment and technical documentation and is not automatically expected to recreate historical design-phase evidence that would not improve the product's security. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12) and Article 69(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.4 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 32 to 35 ## Can an important product of class I rely on a harmonised standard before its reference is published in the Official Journal? No. For CRA presumption of conformity and for the Article 32(2) route logic, a harmonised standard counts only once its reference has been published in the Official Journal of the European Union. The Commission FAQ also says that after the European standardisation organisations adopt a harmonised standard, the Commission still has to assess it before publication in the Official Journal. Until then, a manufacturer may still refer to it in its technical documentation as part of the technical solution it relies on, but it does not have the legal effect of a published harmonised standard under Article 27. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(1), Article 27(6), Article 32(2) and Annex VII point 5 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.10 ## Do common specifications and European cybersecurity certification schemes play the same role as harmonised standards for important class I route selection? Broadly yes, where the CRA makes them available for that purpose. Article 32(2) does not rely only on harmonised standards. It also refers to common specifications and European cybersecurity certification schemes at assurance level at least substantial as referred to in Article 27. The draft Commission guidance says that, although it discusses harmonised standards for brevity, the same logic extends to common specifications and to European cybersecurity certification schemes specified by the Commission under Article 27(9). That means they can support the internal control route for important class I products only to the extent that they cover the relevant requirements. For certification schemes, the CRA also says that a European cybersecurity certificate at assurance level at least substantial removes the need for third-party CRA assessment only for the corresponding requirements, not automatically for everything else. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(5), Article 27(8), Article 27(9) and Article 32(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 137 to 139 and footnote 20 ## For important or critical products, does the conformity assessment look only at the listed core functionality? No. The core functionality determines which conformity assessment route applies, but the conformity assessment itself covers the product as a whole. The draft guidance says the manufacturer needs to ensure that the whole product undergoes the applicable conformity assessment procedure, taking into account integrated components or additional functions as appropriate. The Commission FAQ says the notified body in module B+C examines the whole product and all relevant essential requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1) to Article 32(4) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 131, 135 and 136 ## Is module B just a documentation review? No. Under Annex VIII, module B includes examination of the technical documentation and supporting evidence, but also examination of specimens of one or more critical parts of the product. The notified body must carry out appropriate examinations and tests, or have them carried out. The Commission FAQ also states that the notified body does not only perform a documentation-based assessment and may perform the necessary tests itself or through an external laboratory. Separately, the manufacturer may use its own laboratory or another laboratory on its behalf and under its responsibility for supporting evidence. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II points 2, 3.4 and 4.1 to 4.5 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.2 and 6.5 ## What happens to a module B+C certificate if the product changes after certification? Changes that may affect conformity or the certificate's validity need notified-body involvement. Annex VIII requires the manufacturer to inform the notified body of modifications to the approved type or vulnerability handling processes that may affect conformity with Annex I or the conditions for validity of the EU-type examination certificate. Those changes require additional approval as an addition to the original certificate. The Commission FAQ adds that substantial modifications require a new assessment by the same or a different notified body, while changes that do not affect CRA compliance are not subject to reassessment. Module B also includes periodic audits by the notified body to ensure the vulnerability handling processes are implemented adequately. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II points 6 to 8 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.2 ## Can module H cover more than one product or product category, and does that remove future notified-body involvement? It can cover products or product categories, but it does not eliminate ongoing notified-body control. Annex VIII says module H can apply to the products with digital elements or product categories concerned, and the application must include technical documentation for one model of each intended category. But the manufacturer still has to keep the notified body informed of intended changes to the quality system, and the notified body must decide whether the modified system remains acceptable or needs reassessment. The Commission FAQ also says the quality system can be extended to new or substantially modified products, but that extension remains subject to a new assessment by the same notified body. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV points 1, 3.1, 3.5 and 4.3 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.3 ## Are there CRA measures to reduce the conformity assessment burden for microenterprises and SMEs? Yes. The CRA says fees for conformity assessment procedures must take account of the specific interests and needs of microenterprises and SMEs and be reduced proportionately. It also requires notified bodies to carry out conformity assessments proportionately and without unnecessary burden. Beyond fees, Member States are to support awareness, advice, testing and conformity assessment activities where appropriate, may establish cyber resilience regulatory sandboxes, and microenterprises and small enterprises may use a simplified technical documentation format once specified by the Commission. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(6), Article 33, Article 39(12), Article 47(2) and Article 33(5) ## If the Commission later reclassifies a product or mandates certification for a critical category, does the new CRA conformity assessment route apply immediately? Not necessarily. If the Commission amends Annex III to add, move or withdraw an important-product category, the delegated act should, where appropriate, provide a minimum transitional period of 12 months before the new Article 32(2) or 32(3) routes apply, unless urgency justifies a shorter period. If the Commission makes European cybersecurity certification mandatory for a critical category under Article 8(1), the delegated act must provide a minimum transitional period of six months, unless imperative urgency justifies a shorter one. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 7(3) and Article 8(1) ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Conformity Assessment Routes as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Conformity Assessment Routes into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Conformity Assessment Routes and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes --- --- title: "CRA Core Functionality FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/core-functionality" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/core-functionality" author: "Sorena AI" description: "CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA core functionality FAQ" - "CRA important products classification" - "CRA critical products classification" - "CRA Annex III categories" - "CRA Annex IV categories" - "CRA product classification" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Core Functionality FAQ CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Core Functionality Use this CRA FAQ to understand how core functionality determines whether a product is in the default category, an important-product category, or a critical-product category. Built for compliance, product, certification, legal, and engineering teams deciding CRA classification and conformity routes. Core functionality is the classification hinge for CRA conformity assessment. This FAQ focuses on how manufacturers should determine what a product mainly is, how to distinguish core functionality from ancillary functions, and how to avoid category mistakes that change the applicable route under Article 32. ## What is "core functionality" under the CRA? The CRA does not define the term expressly in the regulation itself, but the draft Commission guidance explains it as the product's main features and technical capabilities, without which it would not be able to meet its intended purpose. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 123 and 124 ## Why does core functionality matter under the CRA? It determines whether the product is in the default category, is an important product of class I or class II, or is a critical product, and therefore which conformity assessment regime applies. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 7(1), Article 8(1) and Article 32 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 3.1 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 122 and 123 ## How should a manufacturer determine a product's core functionality? The draft Commission guidance says the manufacturer should assess the product's main features and technical capabilities in light of its intended purpose, specific context and conditions of use. The guidance also says that this assessment can be supported by the instructions for use, promotional or sales materials, manufacturer statements and the technical documentation. That aligns with the CRA definitions of intended purpose and reasonably foreseeable use. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 124 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(23), Article 3(24) and Annex VII ## Is core functionality about the whole product or about one component inside it? It is about the product as a whole. The CRA and the Commission FAQ make clear that the integration of a product or component with important or critical functionality does not by itself determine the classification of the finished product. The key question is the core functionality of the finished product itself. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 7(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 3.1 and 3.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 123 and 136 ## Can a product perform many functions but still have only one core functionality for CRA classification? Yes. The draft Commission guidance says a product may not have more than one core functionality for the purpose of determining the applicable conformity assessment regime, even if it has many additional or ancillary features. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 125 and 128 ## Do additional or ancillary functions automatically change the CRA core-functionality classification? No. The Commission FAQ and the draft guidance both explain that the presence of additional functions does not by itself mean that the product loses the core functionality of a listed category or moves into another category. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 3.4 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 125 and 131 ## If a product can perform the functions of an important or critical category, does that automatically mean it has that core functionality? No. The draft Commission guidance says a product may be capable of performing functions associated with an important or critical category and still have a different core functionality. The assessment should focus on what the product mainly is, not on whether one feature overlaps with a listed category. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 3.4 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 126 and 127 ## If a product integrates an operating system, browser, firewall or secure element, does that decide the product's own core functionality? No. The Commission FAQ gives concrete examples: integrating an embedded browser into a news app does not make the app a browser for CRA classification, and integrating a secure element into a laptop does not make the laptop a secure element product. The same logic applies more broadly to other integrated listed components. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 7(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 3.2 and 3.4 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 126 and 136 ## Can a product fall outside a listed category because it goes beyond that category's core functionality? Yes. The Commission FAQ and the draft guidance use SOAR software as an example. Even though a SOAR tool may perform SIEM-like functions, it is generally not treated as having the core functionality of a SIEM if its own core functionality is different. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 3.4 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 127 and Example 50 ## Can a product fall outside a listed category because it falls short of that category's core functionality? Yes. The draft Commission guidance gives the example of security-related tools that collect and visualise logs but do not perform the full analytical and actionable functions associated with SIEM systems. Partial overlap is not enough by itself. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 127 and Example 51 ## Are partial similarities in domain, purpose or deployment context enough to classify a product as important or critical? No. The draft Commission guidance says the assessment should focus on the product's actual features and technical capabilities, as reflected in its intended purpose, rather than on vague product groupings, shared market context or partially overlapping functions. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 127 ## Must the manufacturer document the chosen core functionality? Yes. The draft Commission guidance says the product's core functionality should be clearly identified so that the applicable conformity assessment regime can be determined and checked. That fits with the CRA's broader documentation framework, including the need to describe the product's intended purpose and the conformity assessment procedure followed. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 128 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VII and Annex V ## Can a manufacturer describe the product strategically to avoid being classified as important or critical? No. The draft Commission guidance says a manufacturer may not misrepresent its product's core functionality in order to avoid the applicable conformity assessment regime. Clear inconsistencies between promotional materials, instructions for use and technical documentation can indicate that kind of misrepresentation. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 129 ## Does core functionality determine only the conformity route, or also the scope of compliance? It determines the route, but the whole product still has to comply. The draft Commission guidance explains that core functionality is the classification tool. It does not limit the product's broader compliance obligations. The conformity assessment and the manufacturer's risk assessment still have to address the product as a whole. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2) to Article 13(4) and Article 32 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 131 and 134 to 136 ## If a harmonised standard covers the product's core functionality, does that automatically give full presumption of conformity for the whole product? No. The draft Commission guidance explains that a harmonised standard may support the use of internal control for an important class I product where it covers the core functionality, but the presumption of conformity extends only to the parts whose risks are actually covered by that standard. Additional functions and additional risks may still need to be addressed through other means. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(1), Article 27(5) and Article 32(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 133 to 139 ## What should manufacturers use as the main reference for deciding whether a product matches a listed CRA category by core functionality? The Commission FAQ says the technical descriptions of the important and critical product categories are laid down in Commission Implementing Regulation (EU) 2025/2392, and the draft Commission guidance also relies on those descriptions. So in practice, manufacturers should not classify products only by label or market intuition. They should compare the product's real features and technical capabilities against the category descriptions referred to in the CRA materials. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 3.1 and 3.4 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - footnote 15 and Examples 48 to 53 ## What if a product's core functionality does not match any Annex III or Annex IV category? Then it falls into the default category. The CRA does not use the term "default category" in the legal text itself, but the draft Commission guidance uses it for products whose core functionality does not match a category in Annex III or Annex IV. Those products follow the general conformity-assessment regime in Article 32(1), rather than the special routes for important or critical products. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 7(1), Article 8(1) and Article 32(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 3.1 and 6.1 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 122 and footnote 16 ## Are product names, marketing labels, or sales positioning enough to determine core functionality? No. The relevant question is whether the product's actual features and technical capabilities match the technical description of a listed category. Marketing and sales materials do matter as evidence of intended purpose and context of use, but they do not replace the underlying feature and capability analysis. If those materials conflict with the instructions for use or the technical documentation, the draft guidance treats that as a warning sign that the manufacturer may be misrepresenting the product's core functionality. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 3.1 and 3.4 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(23) and Annex VII - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 124, 127 and 129 ## Does use in a critical or sensitive environment by itself make a product important or critical? No. Classification turns on core functionality, not on deployment environment alone. A product's operating context can still matter greatly for the cybersecurity risk assessment and for the measures the manufacturer must implement, but it does not by itself change a product into an important or critical category if the product's own core functionality does not match one of the listed categories. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 3.1 and 3.3 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 127 ## If two products have the same core functionality, can they still require different cybersecurity measures? Yes. The Commission FAQ gives this directly with two different VPN products. Both may have the same core functionality and therefore the same CRA category, but the manufacturer still has to perform a product-specific cybersecurity risk assessment. A VPN intended for critical infrastructure may require more demanding measures than a VPN intended only for residential use, even though both remain VPN products for classification purposes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2) and Article 13(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 3.3 ## What is an example of a product that does have the core functionality of a listed category? The draft Commission guidance gives a positive example for operating systems. A software product that provides an abstraction layer over hardware, manages the execution of software components, handles process and memory management, input-output control, scheduling, resource allocation, and exposes system services and APIs so that applications can reliably run on the platform is treated in the guidance as having the core functionality of an operating system. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 124 and Example 48 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Core Functionality as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Core Functionality into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Core Functionality and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/core-functionality --- --- title: "CRA Cybersecurity Risk Assessment FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment" author: "Sorena AI" description: "CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA cybersecurity risk assessment FAQ" - "CRA Article 13 risk assessment" - "CRA threat modelling" - "CRA intended purpose" - "CRA foreseeable misuse" - "CRA variant risk assessment" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Cybersecurity Risk Assessment FAQ CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Cybersecurity Risk Assessment Use this CRA FAQ to understand what Article 13 requires from the cybersecurity risk assessment, what it must cover, when it must be updated, and how it should deal with constraints, dependencies, variants, and foreseeable misuse. Built for product security, engineering, legal, certification, and compliance teams documenting CRA risk decisions. The CRA cybersecurity risk assessment is the foundation for product compliance under Article 13. This FAQ focuses on what the assessment must cover, how it interacts with Annex I and technical documentation, and how manufacturers should handle constraints, external dependencies, lifecycle changes, and product variants. ## What does the CRA require from a manufacturer's cybersecurity risk assessment? The CRA requires manufacturers to carry out a cybersecurity risk assessment for each product with digital elements and to use the outcome of that assessment throughout the product lifecycle. It is the basis for deciding how the manufacturer will plan, design, develop, produce, deliver and maintain the product so that it meets the CRA's essential cybersecurity requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.1 ## Does the risk assessment obligation apply only to important or critical products? No. The CRA risk assessment obligation applies to all products with digital elements in scope. Whether a product is in the default category or is classified as important or critical does not remove or replace the need for a comprehensive cybersecurity risk assessment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 3.3, section 4.1.1 ## At what stage must the manufacturer use the cybersecurity risk assessment? Across the full lifecycle covered by Article 13(2). The CRA says the manufacturer must take the outcome of the cybersecurity risk assessment into account during the planning, design, development, production, delivery and maintenance phases of the product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.1 ## Must the cybersecurity risk assessment cover the whole product, including remote data processing and supporting functions? Yes. The Commission FAQ says the manufacturer's cybersecurity risk assessment must cover the entire product with digital elements. That includes remote data processing when it is in scope, as well as supporting functions that form part of the product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1), Article 13(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.1 ## Does the CRA mandate a specific cybersecurity risk assessment methodology? No. The CRA does not prescribe a single methodology. Manufacturers may choose the method they use, but it must allow them to identify, assess, treat and document the relevant cybersecurity risks in a way that supports compliance with the CRA. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.2 ## Must the threat model reflect the product's intended purpose and deployment context? Yes. The Commission FAQ says manufacturers should use a threat-modelling approach that reflects the threats and resulting risks associated with the product's intended purpose and reasonably foreseeable use. That means the assessment may differ for the same type of product depending on where and how it is expected to be used, for example in a residential environment or in critical infrastructure. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3), Article 3(24) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 3.3, section 4.1.2, section 4.1.4 ## What must the cybersecurity risk assessment analyse? The CRA requires the assessment to analyse the cybersecurity risks associated with the product based on: - the product's intended purpose - its reasonably foreseeable use - the conditions of use - the time the product is expected to be in use The Commission FAQ adds that the conditions of use can include the operational environment and the assets to be protected. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.4, section 4.1.6 ## Must the risk assessment cover reasonably foreseeable misuse as well as intended use? Yes. The CRA definition of reasonably foreseeable use covers use that is likely to result from reasonably foreseeable human behaviour or technical operations or interactions. The Commission FAQ also explains that manufacturers must take reasonably foreseeable misuse into account and communicate significant resulting risks to users where relevant. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(24), Annex II, point 5 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.5 ## Must the manufacturer identify which Annex I requirements apply and how they are implemented? Yes. Article 13(3) requires the cybersecurity risk assessment to indicate whether and, if so, how the security requirements relating to product properties in Annex I, Part I, point (2) apply to the product and how they are implemented. It must also indicate how the manufacturer applies Annex I, Part I, point (1) and the vulnerability-handling requirements in Annex I, Part II. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.1 ## What if a manufacturer concludes that a specific essential cybersecurity requirement is not applicable? The manufacturer can conclude that a specific requirement is not applicable, but it must justify that conclusion clearly in the technical documentation. That is not a shortcut around the risk assessment. The Commission FAQ and the draft guidance make clear that if relevant risks still exist, the manufacturer must address them through other appropriate measures and explain the resulting limitations, assumptions or conditions of use. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(4), recital 55 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.3 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 28-29 ## Can a manufacturer rely on user instructions instead of product-level security measures? No, not as a substitute for product security. The March 2026 draft guidance says cybersecurity risks must be addressed through product-level measures. Information and instructions can support secure installation, deployment and use, but they do not cure a design shortcoming if the product itself does not achieve the required level of cybersecurity. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 141-147 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(3), Annex II ## Can a manufacturer decide acceptability based only on internal risk appetite, cost, or commercial strategy? No. The March 2026 draft guidance says residual cybersecurity risk must be assessed against the CRA's regulatory threshold, not only against the manufacturer's internal risk tolerance, cost targets or commercial preferences. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 141-147 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(3) ## Can harmonised standards replace the cybersecurity risk assessment? No. Harmonised standards, common specifications or certification schemes can support compliance, but they do not replace the manufacturer's duty to identify and assess the relevant cybersecurity risks for the specific product. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.7 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(3), Annex VII ## Can one risk assessment be used for the CRA and other EU legislation? Yes, if it still shows compliance with each legal instrument separately. The Commission FAQ says manufacturers may carry out a single risk assessment covering the needs of different legislation or separate assessments. What matters is that they remain able to demonstrate compliance with each applicable instrument. The CRA also gives an express example for certain products covered by other Union legal acts. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.1 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(4) ## When must the cybersecurity risk assessment be documented and updated? It must be included in the technical documentation when the product is placed on the market, and it must then be updated as appropriate during the support period. After placement on the market, the manufacturer must also systematically document relevant cybersecurity aspects concerning the product, including vulnerabilities it becomes aware of and relevant information provided by third parties, and update the risk assessment where applicable. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3), Article 13(4), Article 13(7) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ## What kinds of events should trigger an update to the CRA cybersecurity risk assessment? The CRA does not publish a closed list, but the legal text and Commission materials clearly point to updates when relevant cybersecurity aspects change. That includes, for example: - newly identified vulnerabilities - evidence from tests or reviews - relevant information received from third parties - changes in dependencies, product variants or operating assumptions that affect cybersecurity - changes in intended purpose, reasonably foreseeable use or deployment environment Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3), Article 13(7), Annex I, Part II, point 3 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 158-161 ## What must the technical documentation include regarding the cybersecurity risk assessment? The technical documentation must include the risk assessment itself and enough supporting information to show how the product complies with the CRA. Depending on the product, that can include: - the product's intended purpose - system architecture and the relationship between hardware and software elements - relevant information used to determine the support period - vulnerability-handling processes - coordinated vulnerability disclosure information - technical solutions for secure update distribution - software bills of materials where applicable - the standards, specifications or other technical solutions used to meet the essential requirements Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31, Annex VII - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ## Does the CRA require the manufacturer to assess risks from external systems and dependencies too? Yes. The risk assessment is not limited to threats originating entirely inside the product. The draft guidance explains that manufacturers also need to consider cybersecurity risks arising from external networks, remote services, third-party solutions and other dependencies that can affect the product. The CRA still regulates the product's response to those risks. It does not turn the manufacturer into the controller of the entire outside environment. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 151-157, 177, 185-186 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(5) ## Does the CRA risk assessment also have to consider the impact of cybersecurity issues on health and safety? Yes. Article 13(2) says the manufacturer must use the risk assessment to minimise cybersecurity risks, prevent incidents and minimise their impact, including in relation to the health and safety of users. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.1 ## If a product is intended to be integrated into another system, must the manufacturer explain its security assumptions and conditions of use in the CRA cybersecurity risk assessment and user information? Yes. The Commission FAQ says manufacturers should inform users and integrators about assumptions and requirements relevant to secure installation, operation and use. That follows from the CRA's focus on intended purpose, reasonably foreseeable use, conditions of use and the user information required by Annex II. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3), Annex II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.4 ## If interoperability or technical constraints prevent the most secure option, can the manufacturer still comply? Yes, but only if the constraint is identified and justified in the risk assessment and the associated risks are mitigated by other appropriate measures. The draft guidance explains that some products need to interoperate with existing systems or dependencies that limit which security measures can be applied. In those cases, manufacturers still need to assess the resulting risks, document the constraint, implement compensatory measures where needed, and reassess the position over time. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3)-(4), recital 55 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 28-29, Example 6 ## For a product designed before the CRA applies, is a current cybersecurity risk assessment still required? Yes. The March 2026 draft guidance says a manufacturer may place a product designed before the CRA's application date on the market without redesign if it carries out a current cybersecurity risk assessment and can show that the existing design already addresses the relevant risks. The manufacturer is not required to recreate historical design evidence that does not add security value, but it still must document a current assessment and demonstrate compliance with the CRA before placement on the market. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 30-35 and Example 7 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(4), Article 31 ## Can the manufacturer rely on assumptions about professional deployment or controlled environments? Yes, but only where those assumptions are reasonable for the product's intended purpose and reasonably foreseeable use, and are communicated clearly. The Commission FAQ says the conditions of use considered in the risk assessment may include supervision, assistance, or other measures normally present in certain professional settings. But the manufacturer cannot ignore other reasonably foreseeable user groups. If the product is likely to be used by consumers or low-skilled users, the risk assessment and the accompanying instructions must reflect that too. Where secure deployment depends on assumptions such as a trusted environment or secure network, the manufacturer should make that clear and warn about significant resulting risks under reasonably foreseeable misuse. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(23)-(25), Article 13(3), Article 13(18), Annex II, points 4, 5 and 8 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.4 and section 4.1.5 ## Must the cybersecurity risk assessment look ahead over the product's expected lifetime, not just conditions at launch? Yes. The CRA requires the manufacturer to take into account the length of time the product is expected to be in use, and to keep the risk assessment updated as appropriate during the support period. The Commission FAQ adds that the manufacturer should prepare the product so that vulnerabilities, including vulnerabilities in components, can be handled effectively throughout that period, and may consider reasonable projections about changes in the threat landscape. Where certain risks are addressed partly through user information and instructions, those materials should be updated too. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3), Article 13(7)-(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.6 ## Is Annex I, Part I, point (1) a separate extra requirement even if the other product-property requirements already cover the relevant risks? Not necessarily. The March 2026 draft guidance explains that Annex I, Part I, point (1) works as a catch-all for additional cybersecurity risks that are not otherwise adequately addressed through the other applicable product-property requirements. If the risk assessment shows that all relevant cybersecurity risks are already treated through adequate measures implementing the other applicable requirements in Annex I, Part I, point (1) is deemed fulfilled. But if additional risks remain, the manufacturer still has to implement appropriate product-level measures to address them. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3), Annex I, Part I, point 1 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 7.2, points 148 to 150 ## Can one cybersecurity risk assessment cover several variants or models? Yes, but only where the variants genuinely share the same cybersecurity profile. The March 2026 draft guidance says a manufacturer may rely on a single cybersecurity risk assessment, a single set of technical documentation, and a single conformity assessment where the relevant variants share the same architecture, security-relevant design, intended purpose, and cybersecurity risks. Differences such as housing, colour, form factor, or other non-security-relevant characteristics do not by themselves require separate treatment. But differences that affect communication interfaces, software stacks, update mechanisms, remote connectivity, or other cybersecurity-relevant properties must be reflected in the risk assessment and documentation, and the file must be updated when a new variant changes those properties. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(4), Article 31(2), Annex VII - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 7.4, points 158 to 161 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Cybersecurity Risk Assessment as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Cybersecurity Risk Assessment into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Cybersecurity Risk Assessment and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment --- --- title: "CRA Declaration of Conformity FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity" author: "Sorena AI" description: "CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA declaration of conformity FAQ" - "CRA simplified declaration" - "CRA Annex V declaration" - "CRA Annex VI declaration" - "CRA declaration languages" - "CRA declaration update" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Declaration of Conformity FAQ CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Declaration of Conformity Use this CRA FAQ to understand what the EU declaration of conformity is, what it must contain, when the simplified form can be used, and what manufacturers, importers, distributors, and authorised representatives must do. Built for compliance, legal, certification, product, and launch teams preparing CRA market-access documentation. The EU declaration of conformity is a core CRA market-access document. This FAQ focuses on the two allowed formats, mandatory contents, language and retention rules, update triggers, and what happens when declaration requirements are missed. ## What is the CRA EU declaration of conformity? It is the document in which the manufacturer states that fulfilment of the applicable CRA essential cybersecurity requirements has been demonstrated and assumes responsibility for the product's compliance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 28(1) and 28(4) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.8 ## Can a product be placed on the market without a declaration of conformity? No. Under the CRA, the manufacturer must first complete the relevant conformity assessment with a positive result and then draw up the EU declaration of conformity before placing the product on the market. The product must also be accompanied by either the full declaration or the simplified declaration. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12), Article 13(20), Article 28(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.8 ## What CRA declaration of conformity formats are allowed? Two formats are allowed: - the full EU declaration of conformity using the Annex V structure - the simplified EU declaration of conformity using the Annex VI wording and an internet address where the full text can be accessed Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(20), Article 28(2), Annex V, Annex VI - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.8 ## What must the full declaration of conformity contain? Annex V requires at least: - the product name, type and identifying information - the manufacturer or authorised representative name and address - a statement of sole responsibility - identification of the product that is the object of the declaration - a statement of conformity with the relevant Union harmonisation legislation - references to relevant harmonised standards, common specifications or cybersecurity certification used - where applicable, the notified body's name and number, the conformity assessment procedure performed, and the certificate identification - any additional information, plus place, date, name, function and signature details Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex V ## What must the simplified declaration contain? The simplified declaration must follow the Annex VI wording. It states that the named product type is in compliance with Regulation (EU) 2024/2847 and must include the exact internet address where the full text of the EU declaration of conformity is available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(20), Annex VI ## In what languages must the CRA declaration of conformity be available? Both the full and simplified declaration must be made available in the language or languages required by the Member State in which the product is placed on the market or made available on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 28(2) - [The Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.4 ## Who draws up the declaration, and who is responsible for it? Under the CRA, the manufacturer draws up the EU declaration of conformity. By doing so, the manufacturer assumes responsibility for the product's compliance. Even where a notified body has been involved in the conformity assessment, the declaration remains the manufacturer's document. An authorised representative may keep it and provide it to authorities if the mandate allows that, but the CRA does not shift the manufacturer's underlying responsibility. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 18(2)-(3), Article 28(1) and 28(4) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.8 ## Do importers and distributors have declaration-related duties too? Yes. Importers must ensure that the product is accompanied by the declaration required by Article 13(20), and they must keep a copy of the full EU declaration of conformity at the disposal of market surveillance authorities for at least 10 years after placement on the market or for the support period, whichever is longer. Distributors must verify that the manufacturer and importer have complied with the relevant documentation obligations before making the product available on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 19(2)(c), Article 19(6), Article 20(2)(b) ## If several EU product laws apply, do you need several declarations? Not necessarily. Where more than one Union legal act requires an EU declaration of conformity, the CRA requires a single EU declaration of conformity covering all those acts. The Commission FAQ and the Blue Guide add that, for administrative reasons, this single declaration may be organised as a dossier containing the relevant individual declarations. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 28(3), recital 88 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.8 - [The Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.4 ## Does the declaration need the unique identifier of each individual unit? No, not necessarily. The declaration has to identify the product sufficiently for traceability, but the Commission FAQ says it is not necessary for the declaration to include the unique identifier of each unit. In practice, the same version of a declaration can apply to many products manufactured in series, provided the declaration still correctly identifies the products covered by it. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex V, points 1 and 4 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.8 - [The Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.4 ## When does the declaration of conformity need to be updated? It must be updated whenever one of its relevant elements changes. That can include, for example: - a new product version or other change that affects the conformity basis - a substantial modification that leads to a new conformity assessment - changes in the applicable Union legislation cited - changes in the harmonised standards, common specifications or certificate references relied on - changes in the manufacturer or authorised representative details stated in the declaration Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(14), Article 28(2), Annex V - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.8 - [The Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.4 ## What happens if a product is substantially modified or put on the market under another person's name or trademark? In those cases, the person who becomes the manufacturer for CRA purposes must take over the corresponding conformity obligations, including the declaration of conformity. That means a new declaration may be required for the modified product, even where some existing tests or technical documentation can still be reused for unaffected aspects. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 21, Article 22, Article 28 - [The Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.1 ## How long must the CRA declaration of conformity be kept, and by whom? Manufacturers must keep the EU declaration of conformity at the disposal of market surveillance authorities for at least 10 years after the product has been placed on the market or for the support period, whichever is longer. Where applicable, the authorised representative must be able to keep it under its mandate, and importers must also keep a copy for the same period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 18(3)(a), Article 19(6), Article 13(13), Annex VIII Part I point 4.2 - [The Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.4 ## Does the full text have to be accessible online if the simplified declaration is used? Yes. If the manufacturer provides the simplified declaration with the product, it must contain the exact internet address at which the full EU declaration of conformity can be accessed. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(20), Annex VI ## If the simplified declaration is used, does the manufacturer still have to draw up the full EU declaration of conformity? Yes. The CRA still requires the manufacturer to draw up the EU declaration of conformity under Article 28 before the product is placed on the market. Article 13(20) only gives the manufacturer a choice about what accompanies the product: either a copy of the full declaration or the simplified declaration. The simplified declaration is therefore not a substitute for creating the full declaration in the first place. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12), Article 13(20), Article 28(1)-(2), Annex VI - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.8 ## If several EU product laws apply, can the declaration mention only the CRA and leave the others out? No. Where the product is subject to more than one Union legal act requiring an EU declaration of conformity, the CRA requires a single declaration covering all of them. That declaration must identify the Union legal acts concerned, including their publication references. The single declaration may still be organised as a dossier containing the relevant individual declarations. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 28(3), recital 88 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.8 - [The Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.4 ## Does citing a harmonised standard or other conformity basis in the declaration itself create presumption of conformity? No. The declaration records the basis on which conformity is declared, but presumption of conformity comes from the underlying legal conformity route, such as correctly applying a relevant harmonised standard whose reference is published in the Official Journal, a common specification, or a qualifying European cybersecurity certification scheme. The Blue Guide expressly says that merely referencing a harmonised standard in the EU declaration of conformity without actually applying that standard, or the relevant parts of it, does not create presumption of conformity. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27, Annex V point 6 - [The Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.1.2.2 and footnote 188 ## What happens if the EU declaration of conformity is missing or drawn up incorrectly? Under the CRA, that is formal non-compliance. Article 58 says the market surveillance authority must require the manufacturer to put an end to the non-compliance where the EU declaration of conformity has not been drawn up or has not been drawn up correctly. If the non-compliance persists, the Member State must take appropriate measures to restrict or prohibit the product from being made available on the market or ensure that it is recalled or withdrawn. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 58(1)(c)-(d) and Article 58(2) ## Can an authorised representative do anything declaration-related on the manufacturer's behalf? Yes, but only within the limits of the CRA mandate rules. Article 18 requires the mandate to allow the authorised representative at least to keep the EU declaration of conformity and provide it to market surveillance authorities. In addition, Annex VIII expressly allows the authorised representative, in certain conformity assessment procedures, to fulfil the declaration and CE-marking obligations on the manufacturer's behalf and under its responsibility if the mandate says so. But the CRA does not transfer the manufacturer's underlying responsibility for compliance, and Article 18(2) still makes the core Article 13(12), first-subparagraph obligations non-delegable. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 18(2)-(3), Article 28(4), Annex VIII Part I point 5, Annex VIII Part III point 4 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Declaration of Conformity as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Declaration of Conformity into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Declaration of Conformity and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity --- --- title: "CRA Economic Operators FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/economic-operators" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/economic-operators" author: "Sorena AI" description: "CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA economic operators FAQ" - "CRA manufacturer importer distributor" - "CRA authorised representative" - "CRA responsible operator" - "CRA importer obligations" - "CRA distributor obligations" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Economic Operators FAQ CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Economic Operators Use this CRA FAQ to understand who counts as a manufacturer, authorised representative, importer, distributor, or other responsible operator, and what each role must do before and after placing products on the Union market. Built for legal, compliance, supply-chain, marketplace, and go-to-market teams allocating CRA responsibilities. CRA economic-operator rules determine who must handle conformity, documentation, traceability, and authority-facing obligations across the Union supply chain. This FAQ focuses on operator roles, handoffs, due-care checks, role changes, and the extra EU-based responsible-operator requirement for non-EU products. ## What is an economic operator under the CRA? Under the CRA, an economic operator means the manufacturer, authorised representative, importer, distributor, or another natural or legal person that is subject to obligations relating to the manufacture of products with digital elements or to their making available on the market under the Regulation. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(12) ## How does the CRA distinguish manufacturers, authorised representatives, importers and distributors? The CRA defines them as separate roles: - the manufacturer develops, manufactures, or has the product designed, developed or manufactured, and markets it under its own name or trademark - the authorised representative is an EU-established person with a written mandate from the manufacturer to act on specified tasks - the importer is an EU-established person who places on the market a product bearing the name or trademark of a person established outside the Union - the distributor is a person in the supply chain, other than the manufacturer or importer, who makes the product available on the Union market without affecting its properties Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(13), Article 3(15)-(17) ## Can the same company have different CRA roles for different products or sales channels? Yes. The CRA recognises that the same business can perform different functions depending on the product and the service it provides. A business that only provides online intermediation for one product may not be a CRA economic operator for that product, while the same business could still be a distributor or a manufacturer for other products that it actually sells or brands. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 78 ## If a company sells a product under its own brand, is it the manufacturer even if someone else designed or built it? Yes. Under the CRA definition, what matters is not only who physically developed or assembled the product, but also who markets it under its own name or trademark. If a business places the product on the market under its own brand, it takes the manufacturer role for CRA purposes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(13), recital 78 - [The Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 3.1 ## Is an authorised representative mandatory under the CRA? Not in every case. Article 18 says a manufacturer may appoint an authorised representative by written mandate, so the appointment is optional under the CRA itself. But where the manufacturer is established outside the Union, a CRA-covered product can only be placed on the Union market if there is an EU-established operator performing the tasks required by Article 4 of Regulation (EU) 2019/1020. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 18(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.6.1 ## Can a third-country manufacturer place CRA products on the Union market without any EU-based operator? No. The Commission FAQ explains that a non-EU manufacturer needs an economic operator established in the Union to perform the Article 4 tasks under Regulation (EU) 2019/1020. Depending on the setup, that can be an importer, an authorised representative or, where no other such operator exists, a fulfilment service provider. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.6.1 ## What can an authorised representative do under the CRA? The authorised representative performs the tasks specified in the written mandate from the manufacturer. At minimum, that mandate must allow it to: - keep the EU declaration of conformity and technical documentation at the disposal of market surveillance authorities - provide the relevant information and documentation to market surveillance authorities on request The authorised representative must also provide a copy of its mandate to market surveillance authorities on request. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 18(3) ## What can an authorised representative not take over from the manufacturer? The authorised representative cannot take over the manufacturer's core product-compliance obligations listed in Article 13(1) to (11), Article 13(12), first subparagraph, and Article 13(14). That means the authorised representative can help with documentation and authority-facing tasks, but it does not replace the manufacturer for the core design, risk assessment, conformity assessment and ongoing compliance duties that the CRA keeps with the manufacturer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 18(2)-(3) ## What are the importer's key CRA checks before placing a product on the market? Before placing a product on the market, the importer must ensure that: - the manufacturer carried out the appropriate conformity assessment - the manufacturer drew up the technical documentation - the product bears the CE marking and is accompanied by the declaration of conformity and Annex II information and instructions in an understandable language - the manufacturer complied with the identification, contact-detail and support-period-end-date obligations in Article 13(15), (16) and (19) Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 19(1)-(2) ## What must an importer do under the CRA if it doubts compliance or learns of a vulnerability? If the importer considers or has reason to believe that the product or the manufacturer's processes are not in conformity, it must not place the product on the market until conformity is restored. If the product presents a significant cybersecurity risk, the importer must inform the manufacturer and the market surveillance authorities. After placement on the market, if the importer becomes aware of a vulnerability, it must inform the manufacturer without undue delay and, where there is a significant cybersecurity risk, also inform the relevant market surveillance authorities. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 19(3), Article 19(5) ## What must an importer keep and provide to authorities under the CRA? The importer must keep a copy of the EU declaration of conformity at the disposal of market surveillance authorities for at least 10 years after placement on the market or for the support period, whichever is longer. It must also ensure that the technical documentation can be made available and must provide the necessary information and documentation further to a reasoned request. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 19(6)-(7) ## What are the distributor's key CRA checks before making a product available on the market? Before making a product available on the market, the distributor must verify that: - the product bears the CE marking - the manufacturer and the importer complied with the documentation and traceability obligations listed in Article 20(2) - the necessary documents have been provided to the distributor The distributor must also act with due care in relation to the CRA's requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 20(1)-(2) ## What must a distributor do under the CRA if it suspects non-compliance or learns of a vulnerability? If the distributor considers or has reason to believe that the product or the manufacturer's processes are not in conformity, it must not make the product available until conformity is restored. If the distributor later knows or has reason to believe that a product it has made available is not in conformity, it must make sure that corrective measures, withdrawal or recall are taken as appropriate. Upon becoming aware of a vulnerability, it must inform the manufacturer without undue delay and, where there is a significant cybersecurity risk, immediately inform the relevant market surveillance authorities. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 20(3)-(4) ## What must a distributor provide to authorities under the CRA, and what if the manufacturer ceases operations? Further to a reasoned request, the distributor must provide the information and documentation necessary to demonstrate conformity and cooperate with the market surveillance authority on measures to eliminate cybersecurity risks. If the distributor becomes aware that the manufacturer has ceased operations and can no longer comply with the CRA, it must inform the relevant market surveillance authorities without undue delay and, to the extent possible, also inform the users of the products placed on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 20(5)-(6) ## When does an importer or distributor become the manufacturer under the CRA? An importer or distributor becomes the manufacturer for CRA purposes if it: - places the product on the market under its own name or trademark, or - carries out a substantial modification of a product already placed on the market In that case it becomes subject to Articles 13 and 14 as manufacturer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 21 - [The Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 3.1, section 3.3, section 3.4 ## What if a company that is not the manufacturer, importer or distributor substantially modifies the product? A natural or legal person other than the manufacturer, importer or distributor that carries out a substantial modification and makes the product available on the market is also treated as the manufacturer. That person becomes subject to the CRA manufacturer obligations for the affected part of the product or, if the substantial modification affects the cybersecurity of the product as a whole, for the entire product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 22 ## What traceability information must economic operators keep? On request, economic operators must provide the market surveillance authorities with the name and address of the operator who supplied them with the product and, where available, the operator to whom they supplied it. They must be able to present that information for 10 years after they were supplied with the product and for 10 years after they supplied it. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 23 ## Is a fulfilment service provider an economic operator under the CRA itself? Not as a named CRA operator category in Articles 18 to 23. But the Commission FAQ explains that, for CRA-covered products, a fulfilment service provider established in the Union can act as the Article 4 responsible operator under Regulation (EU) 2019/1020 where there is no Union manufacturer, importer or authorised representative. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(12), Articles 18-23 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.6.1 ## Does running an online marketplace automatically make a business a distributor or another CRA economic operator? No. The CRA says that where an entity only provides online intermediation services for a given product and is merely a provider of an online marketplace, it does not qualify as one of the CRA economic operators for that product. But if the same entity also distributes that product, sells it under its own brand, or otherwise acts in an economic-operator role, it must comply with the obligations of that role. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 78 ## Does hosting software on a repository or package manager automatically make the platform a distributor? No. The CRA says the sole act of hosting products with digital elements on open repositories, package managers or collaboration platforms does not by itself amount to making them available on the market. A provider of such a service is treated as a distributor only if it actually makes the software available on the Union market in the course of a commercial activity. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 19 ## When do the CRA operator obligations for authorised representatives, importers and distributors start applying? As a rule, they apply from 11 December 2027. That is the CRA's general application date for the main economic-operator obligations in Chapter II. Earlier application dates in Article 71 concern other parts of the Regulation, such as notified bodies and reporting obligations, not the ordinary importer, distributor and authorised representative obligations as such. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Articles 18-23, Article 71(2) ## If a third-country manufacturer sells directly to an EU end user, must there still be an EU-based responsible operator? Yes. The CRA FAQ explains that a product with digital elements can be placed on the Union market only if there is an economic operator established in the Union performing the Article 4 tasks under Regulation (EU) 2019/1020. In direct third-country sales there may be no traditional importer in the usual commercial sense, but that does not remove the requirement. Depending on the setup, the role can be fulfilled by an authorised representative or, if none exists, a fulfilment service provider established in the Union. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.6.1 - [The Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.4 and section 3.6 ## Does a distributor have to keep its own 10-year copy of the declaration of conformity like an importer does? No, not as a general CRA retention duty. Under the CRA, the explicit long-term declaration-retention duty is imposed on manufacturers, authorised representatives within their mandate, and importers. Distributors must verify before making the product available that the required marking and documentation obligations have been met, and they must provide necessary information and documentation to authorities further to a reasoned request, but Article 20 does not impose the same express 10-year copy-retention duty on distributors that Article 19(6) imposes on importers. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(13), Article 18(3)(a), Article 19(6)-(7), Article 20(2) and Article 20(5) - [The Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 3.4 and footnotes 143 and 149 ## Must importers and distributors redo the manufacturer's full CRA assessment themselves? No. Importers and distributors have real due-care and verification duties, but the CRA does not turn them into second manufacturers by default. Importers must check that the manufacturer has carried out the conformity assessment, drawn up the technical documentation, affixed the CE marking, and supplied the required declaration and Annex II information. Distributors must verify the marking and the listed documentation and traceability elements before making the product available. Those roles must react when they have reason to believe there is non-compliance, but they are not required by Articles 19 or 20 to repeat the manufacturer's risk assessment or conformity assessment from scratch. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 19(2)-(3), Article 20(1)-(3) - [The Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 3.3, section 3.4 and footnote 143 ## Can an authorised representative become the importer if it actually supplies the product in the Union? Yes. The Blue Guide explains that an authorised representative of a third-country manufacturer is no longer acting merely as an authorised representative if it supplies the product to a distributor or directly to a consumer within the Union. In that case it becomes the importer and is subject to the importer's obligations. Sources for this answer: - [The Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.5 ## Are distributors required to bring into CRA compliance products that were already placed on the market before 11 December 2027? No, unless they substantially modify them. The Commission FAQ says products with digital elements placed on the market before 11 December 2027 are not subject to the CRA requirements, apart from the earlier reporting obligation timing rules, unless they are substantially modified. A distributor is therefore not required to retrofit those pre-application products into CRA compliance merely because it continues making them available on or after 11 December 2027. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.5 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 71(2) ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Economic Operators as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Economic Operators into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Economic Operators and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/economic-operators --- --- title: "CRA Essential Cybersecurity Requirements FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements" author: "Sorena AI" description: "CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA essential cybersecurity requirements FAQ" - "CRA Annex I Part I" - "CRA Annex I Part II" - "CRA essential requirements" - "CRA product-level cybersecurity" - "CRA vulnerability handling" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Essential Cybersecurity Requirements FAQ CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Essential Cybersecurity Requirements Use this CRA FAQ to understand how Annex I Part I and Part II work, what applies to every in-scope product, and how manufacturers must justify, document, and evidence compliance. Built for product security, engineering, legal, certification, and compliance teams interpreting the CRA's core technical requirements. The CRA's essential cybersecurity requirements are the core compliance baseline for products with digital elements. This FAQ focuses on how Annex I Part I and Part II differ, when requirements apply, how manufacturers justify inapplicability, and what evidence is needed to show conformity at product level. ## What are the CRA's essential cybersecurity requirements? The CRA splits the essential cybersecurity requirements into two parts: - Part I of Annex I covers the cybersecurity properties the product itself must have - Part II of Annex I covers the vulnerability-handling processes the manufacturer must put in place Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 6, Annex I ## Do products with digital elements need to comply with both Part I and Part II of Annex I? Yes. Under Article 6, products may only be made available on the market where the product meets the Part I requirements and the manufacturer's processes comply with the Part II requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 6, Article 13(1) ## Do Part I and Part II work in exactly the same way over time? No. Part I focuses on the product as placed on the market. Part II contains vulnerability-handling obligations that manufacturers must comply with when the product is placed on the market and throughout the support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 6, Article 13(1), Article 13(7)-(9), Annex I - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.3 ## Does the CRA prescribe one fixed technical checklist or one mandatory methodology for meeting the essential cybersecurity requirements? No. The requirements are objective-oriented and technology-neutral. The CRA does not mandate one specific cybersecurity risk-assessment methodology. Manufacturers can choose their methodology, but it must support identifying, evaluating and treating the relevant risks and documenting how the essential requirements are met. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(4), Annex I - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.2, section 4.2.1 ## Are all Annex I requirements mandatory for every product in exactly the same way? Not in exactly the same way. For Part II, manufacturers need to comply with all vulnerability-handling requirements. For Part I, Article 13(3) requires the manufacturer to determine through the cybersecurity risk assessment which point (2) requirements are applicable to the product and how they are implemented. If a specific requirement is not applicable, the manufacturer must include a clear justification in the technical documentation. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3)-(4), Annex I - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.3 ## What does Annex I Part I, point (1) mean in practice? It is the general product-level requirement to ensure an appropriate level of cybersecurity based on the risks. The March 2026 draft guidance explains that this point is meant to catch additional cybersecurity risks identified by the risk assessment that are not otherwise adequately addressed by the other specific Part I requirements. In most cases, complying with the other applicable Part I requirements will also satisfy point (1), but if additional relevant risks remain, the manufacturer still has to address them at product level. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(3), Annex I Part I, point (1) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 148-150 ## Does the CRA require products to be free from all vulnerabilities? No. The CRA does not require a product to be free from all vulnerabilities. For placement on the market, the relevant product requirement is that, on the basis of the cybersecurity risk assessment and where applicable, the product is made available without known exploitable vulnerabilities. After placement on the market, the manufacturer must address and remediate relevant vulnerabilities without delay in line with Part II of Annex I. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I, point (2)(a), Annex I Part II, point (2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.2, section 4.3.1 ## Can a manufacturer rely on its own risk appetite, product strategy or cost constraints to leave cybersecurity risks untreated? No. The draft guidance says residual cybersecurity risk is assessed against the CRA's regulatory threshold, not against the manufacturer's internal risk tolerance, commercial strategy or cost preferences. If identified risks are not adequately addressed, the product cannot simply be placed on the market anyway. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(3), Annex I Part I, point (1) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 141-147 ## Can user instructions compensate for product design shortcomings? No. The CRA requires manufacturers to place a compliant product on the market. Information and instructions can support secure installation, operation, integration and deployment, but the draft guidance says they cannot be used to compensate for product-design shortcomings or to justify leaving incompatible risks untreated. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(18), Annex II - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 145-147 ## How should Annex I Part I be read in practice? Part I, point (2) is a structured set of product-security outcomes that the manufacturer must apply where relevant on the basis of the cybersecurity risk assessment. It covers, among other things: - no known exploitable vulnerabilities at placement on the market - secure-by-default configuration - the ability to address vulnerabilities through security updates - protection from unauthorised access - confidentiality and integrity protection - data minimisation - protection of essential and basic functions, including after incidents - attack-surface reduction - exploitation-mitigation techniques - security-related logging and monitoring - secure removal and transfer of data and settings Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.3, section 4.2.1 ## Do the essential requirements apply only to the local device, or to the whole product as placed on the market? They apply to the whole product. The Commission FAQ says the cybersecurity risk assessment must cover the entire product with digital elements, including remote data processing when it is in scope and supporting functions that form part of the product. The draft guidance likewise explains that risks from external services, networks and other dependencies may need to be addressed through product-level measures so that the product as a whole complies. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1), Article 13(2)-(5), Annex I - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.1 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 151-157, 162 ## What if a specific essential requirement is incompatible with interoperability needs or with other Union law? The CRA recognises that this can happen, but it is not a free pass. If a requirement is not applicable because of the nature of the product, the manufacturer must clearly justify that in the technical documentation. Recital 55 and the Commission FAQ give interoperability as an example. If cybersecurity risks still arise in relation to that inapplicable requirement, the manufacturer must address those risks by other appropriate means. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(4), recital 55 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.3 ## Do harmonised standards define the only acceptable way to meet the essential requirements? No. Harmonised standards are voluntary and do not replace the manufacturer's own duty to assess risks and demonstrate compliance. They can support conformity, but manufacturers may also use other technical means if they document how the applicable essential requirements are met. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27, Article 31, Annex I - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.7, section 4.2.1 ## How do CRA Annex I and Annex II work together on the essential cybersecurity requirements and user information? Annex I sets the substantive cybersecurity outcomes and processes that the product and manufacturer must meet. Annex II requires the manufacturer to give users the information they need to install, operate, update, integrate and decommission the product securely. That includes, among other things, the intended purpose, security properties, significant cybersecurity-risk circumstances, support-period information, update information, secure decommissioning information, and information needed by downstream integrators. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(18)-(19), Annex I, Annex II ## How is a manufacturer expected to show that the CRA essential cybersecurity requirements are actually met? The CRA does not prescribe one evidence format, but it does require the manufacturer to document how the applicable essential requirements are met. That means the manufacturer needs to show in the cybersecurity risk assessment and technical documentation: - which Part I requirements are applicable - how they are implemented - how Part I point (1) and Part II are applied - what technical means, standards, specifications or other solutions are used - what testing, review or other evidence supports those conclusions Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3)-(4), Article 31, Annex VII - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.1, section 4.2.1 ## Do the essential cybersecurity requirements apply only to important or critical products? No. The essential cybersecurity requirements in Annex I apply horizontally to all products with digital elements that are in scope. The important or critical classification affects the conformity-assessment route, not whether the Annex I requirements apply in the first place. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 6, Article 7, Article 8 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.1 ## Do the essential cybersecurity requirements apply to each individual unit placed on the market, even when products are manufactured in series? Yes. Recital 38 makes clear that the essential cybersecurity requirements, including the vulnerability-handling requirements, apply to each individual product with digital elements when it is placed on the market, whether the product is manufactured as an individual unit or in series. The recital gives a practical example: each individual product placed on the market should already have received all security patches or updates available to address relevant security issues at that time. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 38, Article 13(1) ## Can a manufacturer transfer responsibility for meeting the essential cybersecurity requirements to users, integrators or other third parties? No. The March 2026 draft guidance says the CRA does not allow the manufacturer to transfer cybersecurity risk or responsibility to users or third parties. Information and instructions can support secure deployment, operation or integration, and can inform users about residual risks, but the obligation to place a secure product on the market and demonstrate conformity with the essential cybersecurity requirements remains with the manufacturer. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 145-146 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(18), Annex II ## If identified cybersecurity risks cannot be adequately addressed through appropriate measures, can the product still be placed on the market with warnings or accepted residual risk? No. The draft guidance says that where identified risks cannot be adequately addressed through appropriate measures, compliance may require changes to the product's design, functionality or intended purpose. Cost or commercial feasibility alone is not a sufficient reason to leave such risks untreated, and warnings cannot justify placing a product on the market where the remaining risks are incompatible with the essential cybersecurity requirements. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 147 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(4), Annex I Part I, point (1) ## If interoperability requires a less secure measure or protocol, what do the essential cybersecurity requirements expect? The CRA allows justified constraints, but not an automatic downgrade. Where a product must interoperate with existing systems that only support an older or less secure approach, the manufacturer may rely on that approach only if it is necessary for interoperability, the associated risks are identified and documented, and other appropriate mitigation measures are implemented. The draft guidance adds that if it is technically feasible to support both the secure and the less secure option, the secure option is expected to be implemented and enabled by default, while the less secure option should be used only where interoperability requires it. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(4), recital 55 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 29 and Example 6 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Essential Cybersecurity Requirements as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Essential Cybersecurity Requirements into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Essential Cybersecurity Requirements and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements --- --- title: "CRA Hardware and Software Boundaries FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries" author: "Sorena AI" description: "CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA hardware software boundaries FAQ" - "CRA combined product" - "CRA standalone software" - "CRA source code" - "CRA companion app" - "CRA remote data processing boundary" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" - "CRA hardware and software boundaries FAQ" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Hardware and Software Boundaries FAQ CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Hardware and Software Boundaries Use this CRA FAQ to understand when hardware and software form one product, when software is standalone, and how the CRA treats source code, apps, remote functions, and hosting infrastructure. Built for product, platform, firmware, cloud, legal, and compliance teams defining CRA product scope. CRA compliance depends on drawing the product boundary correctly. This FAQ focuses on when hardware and software form a single product with digital elements, when software stands alone, and how to treat source code, companion apps, remote data processing, and third-party hosted functions. ## Can hardware and software together constitute a single product with digital elements? Yes. The CRA definition is broad enough to cover hardware and software supplied together as one product, including cases where the hardware and software are supplied separately but are intended to operate together as a single product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 17-19 ## What is the key CRA boundary test for deciding whether software forms part of a hardware product? The draft guidance says the key question is whether the software is necessary for the product to perform its intended functions in light of the product's intended purpose and reasonably foreseeable use. The delivery channel is not decisive on its own. What matters is whether the hardware is designed to operate together with that software as part of one product concept. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 19 ## Does the delivery channel decide whether software is part of the same CRA product boundary? No. Software can still be part of the same product even if it is obtained through a separate channel such as an app store, a manufacturer website or another digital link after the hardware is supplied. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 19 ## Can software that is not preloaded on the hardware still be part of the same product? Yes. The Commission FAQ expressly lists software placed on the market together with hardware even where it is not preloaded, such as printer drivers, laptop operating systems and tools used to design and program FPGAs. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 ## Are printer drivers part of the same CRA product as the printer? They can be. The Commission FAQ gives printer drivers as an example of software that may be placed on the market together with hardware. The draft guidance then makes the point more explicit: where the printer cannot fulfil its intended purpose without the drivers, the printer and the drivers together constitute a single product with digital elements. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Example 3 ## Can a companion mobile app be part of the same CRA product as a hardware device? Yes, if it is necessary for the product's intended functionality. The draft guidance gives the example of a fitness wearable and a companion smartphone app that together form one product because they are designed and intended to operate together to deliver the product's functionality. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Example 4 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 ## If an app is genuinely optional and the device can still perform its intended functions without it, is it automatically part of the same product? Not automatically. The draft guidance points to necessity as the decisive factor. If the device can still perform its intended functions without the app, that points away from treating the app as part of the same combined product, although the exact answer still depends on intended purpose and reasonably foreseeable use. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 19 ## When is software more likely to be treated as standalone software rather than part of a CRA hardware product boundary? It is more likely to be treated as standalone software when it is supplied as software in its own right and is not necessary for a hardware product to perform its intended functions. The Commission FAQ confirms that standalone downloadable software can itself be a product with digital elements. The draft guidance then distinguishes that case from software that forms part of a hardware-software product. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 13-19 ## Does the standalone-software placement logic also apply when software forms part of a hardware-software product? No. The draft guidance says its specific explanation for digitally supplied standalone software applies only to standalone software. It does not govern cases where the software is combined with hardware as part of one product. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 16 ## If software is supplied on a USB device or other physical medium, is the CRA analysis the same as for digitally delivered standalone software? No. The draft guidance distinguishes software supplied via physical means from standalone software supplied digitally. In that case, the physical carrier with the software on it is treated as the product supplied for distribution. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 16 ## Is source code capable of being a software product under the CRA? Yes. The CRA defines software as computer code, and the draft guidance explains that this can include both machine code and source code. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 20-22 ## Does source code fall outside the CRA just because it still has to be compiled or interpreted? No. The draft guidance says whether code is uncompiled, compiled or interpreted is not relevant to whether it is software within the CRA. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 20-22 ## If a manufacturer supplies source code to customers as part of a commercial activity, is that code considered placed on the market? Yes. The draft guidance says that where a manufacturer provides customers with computer code as part of its commercial activity, that code is considered to be placed on the market regardless of whether it is machine code or source code. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 22 ## If source code is licensed to a customer for later adaptation, who is responsible for what under the CRA? The draft guidance says the original supplier is responsible for the code it placed on the market. The customer's later adaptations and compilation are a separate matter. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Example 5 ## Are sample code snippets, tutorial code or demo code automatically treated as products placed on the market? No. The draft guidance says sample or demo code provided as part of tutorials or training materials is not considered placed on the market. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 21 ## Is unfinished code shared during design and development automatically treated as a product placed on the market? No. The draft guidance says unfinished code shared during design and development is not considered placed on the market because its manufacturing phase is not complete. Separately, Article 4(3) deals with unfinished software intentionally made available for testing under specific conditions. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 21 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 4(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.6 ## Are separately marketed software or hardware components still products in their own right under the CRA? Yes. Article 3(1) expressly includes software or hardware components placed on the market separately. The Commission FAQ gives firmware, embedded software, integrated circuits, motherboards and sensors as examples. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 ## Are websites or SaaS offerings automatically products with digital elements? No. The Commission FAQ says websites that do not support the functionality of a product are not themselves products with digital elements. It also says standalone SaaS or other cloud solutions designed and developed outside the responsibility of a manufacturer are not themselves products with digital elements. Where such elements meet the definition of remote data processing, they may instead fall within scope on that basis. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(2), recital 12 ## Can a complex system composed of multiple hardware and software elements be a single CRA product? Yes. The draft guidance says complex systems can constitute a single product where the system is placed on the market as one product. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 26 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1) ## Do long development cycles, legacy architectures or interoperability constraints take a complex system outside the CRA? No. The draft guidance says those characteristics do not in themselves exclude a complex system from the CRA. They affect how the CRA's risk-based compliance analysis is applied, not whether the product is in scope. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 27-29 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(4), recital 55 ## Can remote data processing solutions be part of the same CRA product boundary? Yes. The CRA definition of a product with digital elements includes its remote data processing solutions. Whether a specific remote function qualifies depends on the separate Article 3(2) test, but the product boundary is not limited to the local hardware or software alone. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1), Article 3(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 ## Can external engineering or programming tools still form part of the same CRA product boundary? Yes. The Commission FAQ gives tools used to design and program FPGAs as an example of software placed on the market together with hardware. Read together with the draft guidance, this shows that relevant software does not need to be preloaded on the hardware or run on the hardware itself. If, in light of the intended purpose and reasonably foreseeable use, the software is necessary for the hardware product to perform its intended functions or to be meaningfully used, it can form part of the same product boundary. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 19 ## If a required app runs on a user's separate smartphone or computer, does that host device automatically become part of the same CRA product? Not automatically. The cited sources identify the wearable and the manufacturer-provided smartphone application as together constituting a single product because they are designed and intended to operate together. At the same time, the Commission FAQ separately recognises mobile apps and smartphones or laptops as products with digital elements in their own right. Taken together, those examples indicate that the necessary app can fall within the combined product boundary without automatically absorbing the user's general-purpose host device into that same boundary. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 19, Example 4 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 ## Can remote software developed by an external provider still be part of the CRA product boundary? Yes, if it is designed and developed under the manufacturer's responsibility. The draft guidance explains that remote data processing can qualify as part of the product not only when it is developed fully in-house, but also when an external provider develops it solely on behalf of the manufacturer, based on the manufacturer's designs and specifications. In that situation, the remote software can still fall within the product boundary as remote data processing. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1), Article 3(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 179 ## Does the CRA product boundary extend to the remote servers or cloud hardware on which a remote function runs? No, not as such. The draft guidance explains that remote data processing is defined as the software elements of data processing at a distance. It is not meant to include, as part of the product boundary, the hardware that the remote data processing relies on. So the relevant remote software may fall within the product boundary, but the entire hosting infrastructure does not automatically do so as hardware. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(2), Article 3(4), Article 3(5) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 164 ## If a product depends on a third-party SaaS, PaaS or IaaS element that the manufacturer did not design, does that element automatically become part of the product as remote data processing? No. For remote functionality to qualify as remote data processing, the software must be designed and developed by the manufacturer or under its responsibility. The draft guidance says standard third-party SaaS, and comparable third-party elements in PaaS or IaaS stacks, do not meet that test merely because the product depends on them. Instead, they should be treated similarly to third-party components: the manufacturer must assess the resulting risks and address them through product-level measures and due diligence. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(2), Article 13(5) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 179, 184-185 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Hardware and Software Boundaries as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Hardware and Software Boundaries into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Hardware and Software Boundaries and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries --- --- title: "CRA Harmonised Standards and Common Specifications FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications" author: "Sorena AI" description: "CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA harmonised standards FAQ" - "CRA common specifications" - "CRA presumption of conformity" - "CRA Official Journal standards" - "CRA certification schemes" - "CRA Article 27" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Harmonised Standards and Common Specifications FAQ CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Harmonised Standards and Common Specifications Use this CRA FAQ to understand when harmonised standards, common specifications, and certification schemes create presumption of conformity, and how they affect route selection and documentation. Built for engineering, certification, legal, and compliance teams managing CRA conformity evidence. The CRA gives harmonised standards, common specifications, and certain European cybersecurity certification schemes a specific legal role in demonstrating conformity. This FAQ focuses on when those tools matter, what limits their legal effect, and how manufacturers should document and monitor their use. ## What are harmonised standards, common specifications, and European cybersecurity certification schemes under the CRA? They are the CRA's main technical conformity tools. Article 27 gives harmonised standards, common specifications, and certain European cybersecurity certification schemes a specific legal role in demonstrating conformity with the CRA's essential cybersecurity requirements. They do not change the requirements themselves, but they can create a presumption of conformity for the requirements they cover. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(1)-(9) ## Are harmonised standards mandatory under the CRA? No. The CRA does not require manufacturers to use harmonised standards. They are a voluntary means of demonstrating conformity. If the manufacturer does not use them, it still has to show compliance with the essential cybersecurity requirements by other technical means and document that approach in the technical documentation. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(1), Annex VII point 5 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.7 and 6.10 - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629(04)&ref=sorena.io) - sections 4.1.2.2 and 4.1.3 ## Does every European, ISO, IEC, or ETSI standard automatically give CRA presumption of conformity? No. For harmonised standards, the legal effect depends on publication of the reference in the Official Journal of the European Union. If the reference is not published there, the standard does not create a CRA presumption of conformity. The Blue Guide also explains that the legal effect attaches to the relevant European version published by reference in the Official Journal, not simply to the existence of an ISO or IEC base standard. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(1) - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629(04)&ref=sorena.io) - sections 4.1.2.2 and 4.1.2.3 ## What does CRA presumption of conformity mean in practice? It means the product and the manufacturer's processes are presumed to comply with the specific CRA essential cybersecurity requirements covered by the relevant harmonised standard, common specification, or certification scheme. That presumption is limited. It applies only to the requirements, or parts of requirements, that the conformity tool actually covers. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(1), Article 27(5), Article 27(8) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 137-139 ## Do harmonised standards replace the manufacturer's cybersecurity risk assessment? No. The Commission FAQ, drawing on the Blue Guide, states that harmonised standards do not replace the legally binding requirements and do not remove the manufacturer's duty to assess the product's risks and determine which CRA requirements are relevant. The manufacturer still has to check whether the standard actually covers the risks of the product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(4), Article 27(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.7 - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629(04)&ref=sorena.io) - section 4.1.2.2 ## What if a harmonised standard covers only part of the product or only part of the relevant requirements? Then the presumption of conformity extends only to the covered part. The manufacturer still has to address the remaining risks and requirements through other measures and describe that in the technical documentation. The same logic applies where the manufacturer applies only part of a harmonised standard rather than all of the relevant provisions. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(1), Annex VII point 5 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.7 - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629(04)&ref=sorena.io) - sections 4.1.2.2 and 4.1.3 ## For an important product of class I, is it enough if the harmonised standard covers only the product's core functionality? Potentially, yes for route selection, but not automatically for full product-wide presumption of conformity. The draft guidance says an important product of class I can remain eligible for the internal control procedure if all applicable requirements of the relevant conformity tool are applied and its scope covers at least the risks related to the product's core functionality. But where the product has additional functions with additional risks, the manufacturer still has to address those risks separately, and the presumption of conformity remains limited to the parts actually covered. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 132-139 ## What is the difference between horizontal and vertical harmonised standards in the CRA context? According to the Commission FAQ, horizontal standards are product-agnostic standards intended to provide a generic framework, methodology, and taxonomy for CRA compliance. Vertical standards are product-specific and are meant to address the risks associated with particular intended purposes and reasonably foreseeable uses, especially for Annex III and Annex IV categories. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.10 ## What happens under the CRA if no relevant harmonised standard exists yet? The absence of a harmonised standard does not prevent CRA compliance. Manufacturers can still demonstrate conformity through other technical means. In parallel, Article 27 allows the Commission to adopt common specifications in certain fallback situations, and for important products of class I the absence of the relevant conformity tools can affect which conformity assessment route is available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(2), Article 32(2), Annex VII point 5 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.10 - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629(04)&ref=sorena.io) - section 4.1.3 ## When can the Commission adopt CRA common specifications? Only in the fallback situations set out in Article 27. The CRA allows common specifications where the Commission has already requested harmonised standards and the request was not accepted, the standards were not delivered on time, or the standards do not comply with the request, and no relevant Official Journal reference exists or is expected within a reasonable period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(2)-(4) ## Do common specifications stay in place once a harmonised standard is published? Not for the overlapping subject matter. When the reference of a harmonised standard is published in the Official Journal, the Commission must repeal overlapping common specifications, or overlapping parts of them, that cover the same essential cybersecurity requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(6) ## Can a manufacturer rely on non-harmonised standards or its own technical specifications instead? Yes. The Blue Guide explains that conformity can also be demonstrated through other standards or technical specifications, including international standards, European standards whose references are not published in the Official Journal, or the manufacturer's own specifications. But those routes do not create a presumption of conformity, so the manufacturer has to demonstrate compliance more directly in the technical documentation. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VII point 5 - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629(04)&ref=sorena.io) - section 4.1.3 ## How do European cybersecurity certification schemes interact with the CRA? They can support CRA conformity in two ways. First, Article 27(8) gives a presumption of conformity insofar as the EU statement of conformity or certificate under the scheme covers the relevant CRA requirements. Second, where the Commission specifies a scheme under Article 27(9), a European cybersecurity certificate at assurance level at least substantial eliminates the obligation to carry out a separate third-party CRA conformity assessment for the corresponding requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(8)-(9), Article 32(2)-(4) ## Can important or critical products be compliant even if they do not use harmonised standards? Yes. The use of harmonised standards is voluntary. Important and critical products can still be compliant without them, but that can affect the conformity assessment route. In particular, important products of class I move out of the internal control route when the relevant harmonised standards, common specifications, or specified certification schemes are not applied or do not exist. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27, Article 32(2)-(4) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.4 ## Can a manufacturer integrate important or critical components that were not designed in accordance with harmonised standards? Yes. The Commission FAQ says manufacturers are free to integrate important or critical components that do not follow harmonised standards. Harmonised standards are one way to demonstrate compliance, not a condition for integrating a component. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.4 ## What must the technical documentation say about harmonised standards, common specifications, or certification schemes? It must identify what was applied and what was not. Annex VII requires the manufacturer to list the harmonised standards, common specifications, and European cybersecurity certification schemes applied in full or in part. If they were only partly applied, the documentation must specify which parts were used. If they were not applied, the documentation must describe the other solutions adopted and list other relevant technical specifications used to meet the CRA requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VII point 5 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.7 ## What happens if the relevant harmonised standards, common specifications, or certification schemes change after a product is already in series production? The manufacturer has to take those changes into account. Article 13(14) requires manufacturers to ensure that series products remain in conformity and to adequately take account of changes in the standards, common specifications, or certification schemes by reference to which conformity is declared or verified. The Blue Guide also explains that revised harmonised standards can involve coexistence periods and that manufacturers should monitor Official Journal publications and assess whether updates are needed. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(14) - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629(04)&ref=sorena.io) - sections 4.1.2.3, 4.1.2.5 and 4.4 ## Does relying on harmonised standards, common specifications, or certification schemes prevent CRA enforcement action? No. The CRA expressly allows enforcement action where a product's non-compliance is attributed to shortcomings in harmonised standards, common specifications, or certification schemes. In those cases, the Commission can trigger the relevant safeguard or amendment process for the conformity tool itself. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 54(6)(b), Article 55(3)-(5) ## Does the CRA standardisation request, or a harmonised standard that is still unpublished in the Official Journal, already create CRA presumption of conformity? No. The standardisation request starts the standards-development process, but it does not itself create presumption of conformity. Even after a European standard is adopted by the ESOs, Article 27(6) requires the Commission to assess it before publishing its reference in the Official Journal. The Blue Guide explains that the publication of the reference in the Official Journal is what starts the presumption of conformity, and that publication is not automatic. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(1), Article 27(6) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.10 - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629(04)&ref=sorena.io) - sections 4.1.2.2 and 4.1.2.3 ## Are common specifications a general mandatory substitute for harmonised standards under the CRA? No. Common specifications are an exceptional fallback tool, not a general first-line or automatically mandatory substitute for harmonised standards. Under Article 27(2), the Commission may adopt them only after a standardisation request has already been made and that process has failed, been delayed or not complied with the request, and only where no relevant Official Journal reference has been published or is expected within a reasonable period. Recital 85 explains that this reasonable period should not exceed one year after the drafting deadline. If a manufacturer does not apply the common specifications, it must document what other solutions it uses to meet the CRA requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 84, recital 85, recital 87, Article 27(2)-(5), Annex VII point 5 ## For an important product of class I, can a manufacturer keep the internal control route if it applies only some of the applicable provisions of the relevant harmonised standard, common specification or certification scheme? No. Article 32(2) says that if the manufacturer has not applied, or has applied only in part, the relevant harmonised standards, common specifications or European cybersecurity certification schemes, the product and the manufacturer's processes must be submitted for the corresponding requirements to one of the third-party conformity assessment routes. The draft guidance adds that, to remain eligible for internal control, all applicable requirements of the relevant harmonised standard need to be applied and its scope needs to cover at least the risks related to the product's core functionality. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 132-133 ## Does any EU cybersecurity certificate or EU statement of conformity under a European certification scheme automatically have CRA legal effect? No. Under the draft guidance, the certification-scheme route in Article 27 has CRA effect only where the Commission has specified the relevant European cybersecurity certification scheme by delegated act under Article 27(9). Even then, any presumption of conformity is limited to the requirements actually covered by the certificate or EU statement of conformity. And only the issuance of a European cybersecurity certificate at assurance level at least substantial removes the obligation to carry out a separate third-party CRA conformity assessment for the corresponding requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(8)-(9), Article 32(2)-(3) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 137-139 ## Can a harmonised standard under another EU product law, or the ISO/IEC source text behind a European standard, automatically give CRA presumption of conformity? No. As an inference from Article 27 and the Blue Guide, CRA presumption of conformity attaches to the European standard version whose reference is published in the Official Journal for the relevant legal coverage. A standard harmonised under another Union act, or an ISO or IEC base text on its own, can still be used as another technical specification, but it does not automatically create CRA presumption of conformity under the CRA. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(1) - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629(04)&ref=sorena.io) - sections 4.1.2.3 and 4.1.3 ## What happens if a harmonised standard is revised, published with restrictions, or withdrawn from the Official Journal? The legal effect can narrow or end. The Blue Guide explains that the Commission may publish a reference with restrictions, or later maintain, restrict or withdraw the reference after the relevant objection procedures. When a standard is revised, the Official Journal often sets a coexistence period during which both the old and revised references still give presumption of conformity. After the withdrawal date, only the revised standard continues to do so. Manufacturers therefore need to monitor Official Journal publications and take account of those changes for future conformity work and for ongoing series production. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(14) - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629(04)&ref=sorena.io) - sections 4.1.2.3, 4.1.2.4 and 4.1.2.5 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Harmonised Standards and Common Specifications as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Harmonised Standards and Common Specifications into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Harmonised Standards and Common Specifications and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications --- --- title: "CRA Important and Critical Products FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products" author: "Sorena AI" description: "CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA important and critical products FAQ" - "CRA Annex III" - "CRA Annex IV" - "CRA core functionality" - "CRA important class I class II" - "CRA critical products" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Important and Critical Products FAQ CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Important and Critical Products Use this CRA FAQ to understand Annex III and Annex IV classification, what core functionality means in practice, and how important or critical status changes the applicable conformity assessment route. Built for product, legal, certification, and compliance teams classifying products under the CRA. Important and critical classification under the CRA changes the conformity-assessment route, but only when a product's core functionality actually matches Annex III or Annex IV. This FAQ focuses on category matching, route consequences, product-wide assessment scope, and the limits of special rules such as the Annex III FOSS derogation. ## What are important and critical products with digital elements under the CRA? Under the CRA, a product is important or critical if it has the core functionality of a category listed in Annex III or Annex IV. Products with the core functionality of a category in Annex III are important products. Products with the core functionality of a category in Annex IV are critical products. Important products are divided into class I and class II. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 7(1), Article 8(1), Annex III, Annex IV - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 3.1 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 121 ## What is the main practical CRA consequence of being classified as an important or critical product? The main consequence is the conformity assessment route. Products outside Annex III and Annex IV follow Article 32(1). Important products of class I follow Article 32(2) when its trigger is met. Important products of class II follow Article 32(3). Critical products follow Article 32(4). Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1)-(4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 122 ## Is "default category" an official CRA term? No. The March 2026 draft guidance uses that expression as a practical label for products that do not have the core functionality of an Annex III or Annex IV category and therefore remain under the Article 32(1) conformity assessment regime. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - footnote 16 to point 122 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1) ## Which product categories are listed in Annex III class I? Annex III class I lists these categories: - identity management systems and privileged access management software and hardware, including authentication and access control readers, including biometric readers - standalone and embedded browsers - password managers - software that searches for, removes, or quarantines malicious software - products with digital elements with the function of virtual private network (VPN) - network management systems - security information and event management (SIEM) systems - boot managers - public key infrastructure and digital certificate issuance software - physical and virtual network interfaces - operating systems - routers, modems intended for the connection to the internet, and switches - microprocessors with security-related functionalities - microcontrollers with security-related functionalities - application specific integrated circuits (ASIC) and field-programmable gate arrays (FPGA) with security-related functionalities - smart home general purpose virtual assistants - smart home products with security functionalities, including smart door locks, security cameras, baby monitoring systems and alarm systems - internet connected toys covered by Directive 2009/48/EC that have social interactive features or location-tracking features - personal wearable products with a health-monitoring purpose outside the MDR and IVDR regimes, and certain personal wearable products for children Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex III, Class I ## Which product categories are listed in Annex III class II? Annex III class II lists these categories: - hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments - firewalls, intrusion detection systems and intrusion prevention systems - tamper-resistant microprocessors - tamper-resistant microcontrollers Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex III, Class II ## Which product categories are listed in Annex IV? Annex IV lists these critical-product categories: - hardware devices with security boxes - smart meter gateways within smart metering systems and other devices for advanced security purposes, including for secure cryptoprocessing - smartcards or similar devices, including secure elements Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex IV ## Why does the CRA treat these categories as important or critical? For important products, Article 7(2) says the listed categories meet at least one of two criteria: they primarily perform functions critical to the cybersecurity of other products, networks or services, or they perform a function carrying a significant risk of adverse effects through disruption, control, or damage. For critical products, Article 8(2) adds a higher-threshold logic linked to critical dependency by essential entities or serious disruption of critical supply chains. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 7(2), Article 8(2) - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recitals 44 to 47 ## What determines whether a specific product really belongs in one of those CRA important or critical categories? The key question is the product's core functionality. The Commission FAQ and draft guidance both say manufacturers should assess the product's real features and technical capabilities, reflected in its intended purpose, against the relevant technical descriptions. Classification is not decided by product labels alone. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 3.1 and 3.4 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 124-129 ## Can a product have more than one core functionality for CRA classification purposes? No. The draft guidance says a product may not have more than one core functionality for the purpose of determining the applicable conformity assessment regime. The core functionality should therefore be identified clearly in the technical documentation. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 128 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VII ## Does having extra or ancillary functions stop a product from being important or critical? No. The Commission FAQ and the draft guidance both explain that products often have additional functions beyond their core functionality. That does not by itself stop the product from having the core functionality of an important or critical category. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 3.4 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 125 ## What if a product looks similar to a listed category but its functionality is broader or narrower? Similarity is not enough on its own. The draft guidance says a product may substantially exceed or substantially fall short of the core functionality of a listed category. In those cases, partial overlap in domain, purpose, or deployment context is not enough to treat it as important or critical. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 3.4 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 127-128 ## If a product integrates an important or critical component, does that automatically make the full product important or critical? No. Article 7(1) expressly says that integrating an Annex III product does not in itself make the larger product important. The Commission FAQ gives examples such as an embedded browser inside a news app or a secure element inside a laptop. The draft guidance applies the same logic to critical products: the classification turns on the core functionality of the product as a whole. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 7(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 3.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 126 and 136 ## Does classification as important or critical change the need for a cybersecurity risk assessment? No. All in-scope products need a CRA cybersecurity risk assessment. Classification mainly affects the conformity assessment route, not whether the manufacturer must assess and document the cybersecurity risks of the product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(4), Article 32 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 3.3 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 122 and 131 ## Can a manufacturer of a non-Annex III or non-Annex IV product still choose a stricter conformity assessment route? Yes. Article 32(1) allows manufacturers in that situation to use module A, module B plus C, module H, or, where available and applicable, a relevant European cybersecurity certification scheme. The draft guidance also notes that a manufacturer can always choose a more rigorous route. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - footnote 17 to point 122 ## When can an important product of class I use internal control under module A? An important class I product can remain on the internal-control path only if Article 32(2) is not triggered. The draft guidance adds that, for that path to remain available, all applicable requirements of the relevant harmonised standards, common specifications, or specified certification scheme must be applied, and the scope must cover at least the risks related to the product's core functionality. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1)-(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 132-135 ## What happens if an important class I manufacturer has not applied the relevant harmonised standards, has applied them only in part, or no relevant conformity tool exists? Then Article 32(2) applies. In that case, the product must go through either EU-type examination followed by conformity to type based on internal production control, or full quality assurance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 132 ## What conformity assessment routes apply to important class II products? Important class II products must use one of the Article 32(3) procedures: - module B plus C - module H - where available and applicable, a European cybersecurity certification scheme at assurance level at least substantial Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(3) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 132 ## What conformity assessment routes apply to critical products? Critical products follow Article 32(4). That means a European cybersecurity certification scheme under Article 8(1), if the Commission has adopted the relevant delegated act and an applicable scheme is available. If not, the product falls back to one of the Article 32(3) procedures. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 8(1), Article 32(4) ## Do important and critical products always need third-party conformity assessment? Important class II products always do, and important class I products do whenever Article 32(2) is triggered. For critical products, the route is also third-party in practice, either through Article 8(1) certification if that delegated-act route exists, or through Article 32(3) if it does not. The draft guidance describes important class II and critical products as subject to mandatory third-party conformity assessment, and says the same for important class I when the internal-control path is unavailable. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 8(1), Article 32(2)-(4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 132 ## Is there a special rule for important products qualifying as free and open-source software? Yes. Article 32(5) says that manufacturers of products qualifying as free and open-source software and falling under Annex III may use one of the Article 32(1) procedures, provided that the technical documentation is made available to the public at the time of placing on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(5) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 122 and 132 ## Does being classified as important or critical mean that only the core function is assessed? No. The draft guidance says that once the core functionality has been identified and the route selected, the conformity assessment still has to cover the product as a whole. Additional or ancillary functions can create additional risks that still need to be addressed. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(4), Article 32 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 131 and 134-139 ## If a harmonised standard covers only the core functionality of an important class I product, does the whole product automatically get presumption of conformity? No. The draft guidance explains that a harmonised standard may support the use of internal control for an important class I product where it covers the core functionality, but the presumption of conformity extends only to the parts whose risks are actually covered by that standard. Additional functions and additional risks may still need to be addressed through other means. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(1), Article 27(5), Article 32(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 133-139 ## What should manufacturers use as the main reference for deciding whether a product matches a listed CRA important or critical category? The CRA itself points to a Commission implementing act that sets the technical descriptions, and the Commission FAQ says those descriptions are now laid down in Implementing Regulation (EU) 2025/2392. So in practice, manufacturers should compare the product's actual features and technical capabilities against those technical descriptions, not classify the product only by marketing label or broad product family. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 7(4) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 3.1 and 3.4 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - footnote 15 and examples 48 to 53 ## Can the Annex III and Annex IV lists change over time? Yes. The CRA empowers the Commission to amend Annex III and Annex IV by delegated act. For Annex III changes, the CRA generally requires a minimum transitional period of 12 months where appropriate. For Article 8 delegated acts and Annex IV changes, the CRA generally requires a minimum transitional period of six months. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 7(3), Article 8(1)-(2) ## How does the CRA work for important or critical products that are also high-risk AI systems? The CRA contains a special overlap rule. As a rule, Article 12(2) points to the relevant AI Act conformity assessment procedure for products covered by both regimes. But Article 12(3) creates a derogation for certain important and critical CRA products that are also high-risk AI systems and use the AI Act's internal-control route. In that situation, the CRA's own conformity assessment procedures still apply for the CRA essential cybersecurity requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 12(2)-(3) - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 52 ## Can a manufacturer downplay or overstate the core functionality to avoid the stricter regime? No. The draft guidance says a manufacturer may not misrepresent the product's core functionality in order to escape the conformity assessment regime applicable to important or critical products. It gives the example of inconsistencies between promotional materials, instructions for use, and technical documentation. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 129 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32, Annex VII ## Does being classified as important or critical create a separate set of CRA essential cybersecurity requirements? No. The core CRA essential cybersecurity requirements still come from Article 6, Article 13 and Annex I. The classification as default, important class I, important class II or critical mainly determines which conformity assessment route applies before the product is placed on the market. The Commission FAQ's risk-assessment section likewise explains that manufacturers of all products with digital elements must implement the essential requirements in a way proportionate to the product's risks. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 6, Article 13, Article 32, Annex I - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 3.3 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 122 and 131 ## Can a product move into a stricter class just because one version is intended for a more sensitive environment or presents higher deployment risk? No, not by itself. Classification still turns on the product's core functionality against the Annex III or Annex IV category descriptions. The Commission FAQ's VPN example shows that two products with the same core functionality can present different risk levels because of their intended deployment and therefore require different risk treatment measures, but that does not by itself change whether they are an important, critical or default-category product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 7(1)-(2), Article 8(1)-(2), Article 13(2)-(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 3.1 and 3.3 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 124-128 ## Does the Article 32(5) free-and-open-source-software rule apply to critical products? No. Article 32(5) is expressly limited to products qualifying as free and open-source software that fall under the categories set out in Annex III. So that special route can apply to important products in Annex III, subject to the public-technical-documentation condition, but it does not extend the same derogation to Annex IV critical products. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(4)-(5) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 122 and 132 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 91 ## If the Commission later adds, removes, or reclassifies an Annex III or Annex IV category, does that automatically retroactively change products already placed on the market? Not automatically. Read together, the CRA's delegated-act transition rules and the Blue Guide's placing-on-the-market principle mean that the new classification matters for products placed on the market after the new rules start applying, while products already placed on the market are not automatically reclassified just because the legislation is later revised. For Annex III changes, the CRA generally requires a transitional period of at least 12 months where appropriate. For Article 8 delegated acts and Annex IV changes, the CRA generally requires at least six months, unless urgency justifies less. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 7(3), Article 8(1)-(2) - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629(04)&ref=sorena.io) - section 2.3 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Important and Critical Products as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Important and Critical Products into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Important and Critical Products and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products --- --- title: "CRA Integrated Components and Dependencies FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies" author: "Sorena AI" description: "CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA integrated components FAQ" - "CRA dependencies FAQ" - "CRA due diligence components" - "CRA RDPS dependencies" - "CRA third-party components" - "CRA FOSS dependencies" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Integrated Components and Dependencies FAQ CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Integrated Components and Dependencies Use this CRA FAQ to understand how the finished-product manufacturer must treat third-party components, remote data processing, cloud services, and FOSS dependencies under the CRA. Built for product security, platform, procurement, engineering, and compliance teams managing dependency risk. CRA compliance for a finished product does not stop at first-party code. This FAQ focuses on component due diligence, vulnerability handling across integrated components, the boundary between RDPS and outside dependencies, and how manufacturers should handle third-party cloud and FOSS dependencies. ## What is the difference between an integrated component, a remote data processing solution, and an external dependency? Under the CRA, an integrated component is a software or hardware component that forms part of the product with digital elements. A remote data processing solution can also form part of the product where it meets the Article 3(2) definition. Other outside systems or services may remain external dependencies rather than part of the product itself. The consequence is different in each case: - integrated components are part of the product and trigger due diligence under Article 13(5) - remote data processing solutions that meet the CRA definition are also part of the product - outside systems may remain external dependencies, but their risks still have to be considered in the cybersecurity risk assessment and mitigated through product-level measures Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1)-(2), Article 13(2), Article 13(5), recitals 11 and 12 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 151-157 and 162-192 ## Does the manufacturer remain responsible for the cybersecurity of the whole product when it integrates third-party components? Yes. The CRA places the compliance obligation on the manufacturer of the finished product. The Commission FAQ is explicit that vulnerability-handling obligations apply to the product in its entirety, including integrated components. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(1), Article 13(5)-(8), recital 34 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.6 and 4.3.7 - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629(04)&ref=sorena.io) - section 2.1 ## Are CRA cybersecurity risk assessment and component due diligence the same obligation? No. The draft guidance treats them as distinct but complementary obligations. The cybersecurity risk assessment covers risks affecting the product, including risks originating outside the product. Due diligence under Article 13(5) is the additional obligation to verify, in a risk-based way, that third-party integrated components do not undermine the product's compliance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2), Article 13(5) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 151-157 ## What does due diligence mean when integrating third-party components? It means taking appropriate, risk-based steps so that the integrated components do not compromise the cybersecurity of the product. Recital 34 and the Commission FAQ give examples such as checking whether the component already bears the CE marking, checking whether it receives regular security updates, checking relevant vulnerability databases, and carrying out additional security tests where appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(5), recital 34 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.4.1 ## Does a CE-marked component automatically make the finished product compliant? No. The Blue Guide explains that CE-marked components do not automatically guarantee that the finished product also complies. In the CRA context, a CE-marked component can support the integrating manufacturer's assessment, but the integrating manufacturer still has to ensure that the finished product complies as a whole. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.4.1 and 4.4.3 - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629(04)&ref=sorena.io) - section 2.1 ## Can a manufacturer integrate components that are not CE-marked under the CRA? Yes. The CRA does not require manufacturers to integrate only CE-marked components. Manufacturers can integrate components that are outside the CRA, that were placed on the market before the CRA applies, or that were never placed on the market as CRA products. But they still have to exercise due diligence and ensure that the finished product complies. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(5), recital 35 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.4.1 and 4.4.3 ## Can the integrating manufacturer rely on the component manufacturer's own CRA work? Partly, but not completely. The Commission FAQ says that where the component is itself subject to the CRA, the integrating manufacturer can rely in part on the component manufacturer's lifecycle work, such as its vulnerability handling and conformity documentation. But that does not transfer the finished-product manufacturer's own obligations. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.6, 4.3.7 and 4.4.1 - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629(04)&ref=sorena.io) - section 2.1 ## Do vulnerability-handling obligations extend to integrated components? Yes. Recital 34 and the Commission FAQ say that the CRA vulnerability-handling obligations apply to the product in its entirety, including all integrated components. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 34, Article 13(7)-(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.6 and 4.3.7 ## If the manufacturer finds a vulnerability in an integrated component, what must it do? The CRA expects more than just recording the issue. Article 13(6) and recital 34 require the manufacturer to inform the person or entity manufacturing or maintaining the component, address and remediate the vulnerability, and, where applicable, provide that person or entity with the applied security fix. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), recital 34 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.6 ## What if an integrated component stops receiving support before the finished CRA product's support period ends? That does not end the finished-product manufacturer's duties. The Commission FAQ says the manufacturer must comply with the vulnerability-handling obligations for the duration of the product's own support period, for the product in its entirety, including integrated components. If the upstream component is no longer supported, the manufacturer may still need to patch it, replace it, disable affected functions, or mitigate the risk through other means. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), recital 34 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.7 ## Must the risk assessment also consider risks from outside systems that are not themselves part of the product? Yes. The draft guidance says the cybersecurity risk assessment must cover relevant risks that originate outside the product itself, such as external networks, environmental factors, infrastructure, or other systems on which the product relies. The CRA then requires those risks to be mitigated through product-level measures rather than by imposing obligations on the outside environment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(3) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 152-153 and 156 ## How should a manufacturer treat third-party SaaS or cloud services that the product relies on? It depends on whether the service qualifies as a remote data processing solution. If the relevant software is designed and developed by the manufacturer or under its responsibility, and its absence would prevent the product from performing one of its functions, it can be part of the product as RDPS. If that second condition is met but the software is a third-party solution not designed and developed by the manufacturer or under its responsibility, the draft guidance says it should be treated similarly to a third-party component: the manufacturer must assess the integration risk and exercise due diligence. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(2), recitals 11 and 12 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 179-186 ## If a product relies on a cellular network or general internet connectivity, does the manufacturer have to exercise component-style due diligence toward the network provider? Not necessarily. The draft guidance's cellular-network example says such a network does not qualify as RDPS and should not be treated like a third-party component where no provider software is integrated into the product. The manufacturer still has to assess the network-related risks and address them through product-level controls. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 152-153 and section 8.3 use case on cellular networks ## Can the manufacturer shift CRA responsibility to a component supplier or cloud provider by contract? No. The draft guidance says the CRA does not provide for transfer of cybersecurity risk or responsibility to users or third parties. Contracts, service levels, and supplier commitments can support compliance and due diligence, but the obligation to place a compliant product on the market remains with the manufacturer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(1), Article 13(5)-(8) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 145 and 192 ## Must the technical documentation describe integrated components, remote data processing, or reliance on third-party cloud solutions? Yes, where relevant. Annex VII requires technical documentation to contain enough information to assess compliance, including the vulnerability-handling processes and the cybersecurity risk assessment. The draft guidance adds that manufacturers should indicate in the technical documentation whether the product has RDPS or relies on third-party cloud solutions and should describe those solutions. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31, Annex VII - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 188-190 ## If no upstream fix is available for a vulnerable integrated component, can the manufacturer still be expected to act? Yes. The Commission FAQ says that if a vulnerability in an integrated component cannot be adequately addressed by the original component supplier, the integrating manufacturer still has to remediate it by other means, for example by switching out the component, developing a patch itself, or disabling the affected functionality where that is the appropriate product-level remedy. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6)-(8), recital 34 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.6 and 4.3.7 ## If the CRA product is meant to be integrated into a larger system, do deployment assumptions and outside interfaces still matter? Yes. The Commission FAQ says intended purpose, reasonably foreseeable use, and conditions of use can include direct or indirect logical or physical connections to devices or networks. That means the manufacturer has to take the integration context into account in the risk assessment and provide users with the information needed for secure deployment and operation. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(3), Annex II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.4 ## If a manufacturer contributes code or funding to a FOSS dependency that it integrates, does that make it responsible for that dependency's own CRA compliance? No, not by itself. The draft guidance says manufacturers integrating FOSS components do not become responsible for those components' individual CRA compliance merely because they contribute source code to their maintenance. The same logic applies where manufacturers provide financial support to keep a dependency viable. The integrating manufacturer still remains responsible for its own product and still has to exercise due diligence toward the integrated dependency. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 18, recital 19, Article 13(5), Article 3(14) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 3.4, points 80-83, and examples 21-27 ## Does integrating a FOSS dependency into a commercial product make that dependency itself a CRA product? No. The draft guidance says the fact that other manufacturers integrate a FOSS component into monetised products does not by itself change the status of that component under the CRA. Whether the CRA applies to the dependency itself depends on whether the entity publishing it places it on the market. A FOSS component published for integration by other manufacturers can therefore remain outside the manufacturer regime, or fall under the steward regime, if the publisher does not monetise that component. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 18, recital 19, Article 3(14) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 3.2.7, points 64-65, and section 3.4, points 81-82 ## Can the publisher of an integrated FOSS dependency be a steward rather than a manufacturer? Yes. Where a legal person publishes a FOSS dependency intended for commercial activities but does not place that specific dependency on the market, it may be an open-source software steward rather than a manufacturer. The draft guidance also says the same legal entity can be a manufacturer for one FOSS and a steward for another, including being a manufacturer for a paid version and a steward for a free or community version. That changes the publisher's own CRA role, but it does not remove the integrating manufacturer's obligations for the finished product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(13)-(14), Article 24, recital 19 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 3.3, points 66-71 and 73-75, and examples 22-24 ## Does a package repository or hosting platform automatically become responsible for every dependency it hosts? No. The draft guidance's package-repository example says that merely hosting a FOSS library in a public repository does not by itself give the repository CRA obligations for that dependency. More generally, hosting or infrastructure support does not automatically make a legal person responsible for every project it hosts. A legal person may become a steward only for specific FOSS where it systematically provides sustained support and ensures that project's viability. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(14), Article 24, recital 19 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 3.3.1, points 72 and 75-76, and example 28 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Integrated Components and Dependencies as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Integrated Components and Dependencies into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Integrated Components and Dependencies and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies --- --- title: "CRA Interplay With Other EU Laws FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws" author: "Sorena AI" description: "CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA interplay with other EU laws FAQ" - "CRA RED AI Act GDPR Data Act" - "CRA EHDS Machinery GPSR" - "CRA exclusions vehicles aviation marine" - "CRA single declaration" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Interplay With Other EU Laws FAQ CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Interplay With Other EU Laws Use this CRA FAQ to understand where the CRA overlaps with other EU regimes, where products are excluded, and how declarations, assessments, and certificates interact across frameworks. Built for legal, compliance, certification, and product teams navigating multi-framework EU obligations. The CRA is a horizontal cybersecurity regime, but many products also fall under other EU laws. This FAQ focuses on when the CRA applies alongside those frameworks, when products are excluded instead, and how declarations, assessments, certificates, and notified-body roles interact across overlapping regimes. ## Does the CRA replace other EU laws that may apply to the same product? No. The CRA is a horizontal product-cybersecurity regime. It adds mandatory cybersecurity rules for products with digital elements, but it does not generally replace other Union acts that regulate the same product from another angle, such as product safety, machinery, data protection, health-data systems, or AI. Depending on the product, the CRA may apply alongside those other acts, unless the CRA itself excludes the product or a later delegated act limits the CRA for a specific product framework. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recitals 3, 6, 28, 31, 32, 33 and 53; Article 2(2)-(5); Article 11; Article 12 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 2.4.1, 2.5.1, 2.7.1, 2.8.1 and 2.9.1 ## Can one product be subject to the CRA and another EU law at the same time? Yes. That is a normal CRA scenario. The Commission FAQ gives machinery, radio equipment, EHR systems, and connected products that are also subject to the Data Act as examples of products that may have to comply with more than one Union framework at once. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 2.4.1, 2.6.1, 2.7.1 and 2.9.1 ## When is a product excluded from the CRA rather than merely overlapping with another EU law? The starting point is the CRA's express exclusions and any delegated acts adopted under Article 2(5). Some products are excluded directly by Article 2, including products to which the medical-device and in vitro-diagnostic frameworks apply, products to which Regulation (EU) 2019/2144 applies, products certified under the civil-aviation framework, and marine equipment in scope of Directive 2014/90/EU. In addition, Delegated Regulation (EU) 2025/1535 excludes products falling within the scope of Regulation (EU) No 168/2013, except L1e category vehicles designed to pedal. More generally, Article 2(5) allows the Commission to limit or exclude the CRA for products covered by other Union rules that address the same risks, but only where that is consistent with the overall framework and delivers the same or a higher level of protection. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recitals 25, 27 and 28; Article 2(2)-(5) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.9 ## How does the CRA relate to NIS2 and the Cybersecurity Act? The CRA complements them; it does not duplicate them. Recital 3 says existing Union cybersecurity law, including Regulation (EU) 2019/881 and Directive (EU) 2022/2555, does not directly cover mandatory security requirements for products with digital elements. Recital 24 adds that the CRA is intended to facilitate compliance by digital infrastructure providers with NIS2 supply-chain requirements by making the products they use more secure and better supported. The CRA also operates without prejudice to Union-level NIS2 supply-chain risk assessments. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recitals 3, 24, 48 and 52 ## How does the CRA interact with the eIDAS framework for European Digital Identity Wallets? Where a wallet product falls within the CRA's scope, both frameworks apply. Recital 33 says providers of European Digital Identity Wallets should comply with both the CRA's horizontal essential cybersecurity requirements and the specific security requirements in Article 5a of Regulation (EU) No 910/2014. The same recital also says that, where the Commission has specified a presumption of conformity, a European cybersecurity certification scheme under Regulation (EU) 2019/881 may be used to help demonstrate compliance with both frameworks for the covered requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 33 ## What is the CRA's relationship with the EU Product Liability Directive? They are complementary, but they do not serve the same function. The Product Liability Directive deals with compensation for damage caused by defective products. The CRA sets ex ante cybersecurity obligations for products placed on the market. The Commission FAQ explains that CRA duties such as security-update obligations can become relevant when defectiveness and damage are assessed under the Product Liability Directive. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 31 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 2.3.1 ## How does the CRA interact with the Machinery Regulation? A product can fall under both. The CRA covers essential cybersecurity requirements for products with digital elements. The Machinery Regulation covers essential health and safety requirements for machinery and related products, including some cybersecurity-related safety issues. Recital 53 and the Commission FAQ both say manufacturers of products in scope of both regimes need to comply with both sets of requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 53 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 2.4.1 and 2.4.2 ## If the CRA and the Machinery Regulation both apply, is compliance with one enough? No. The Commission FAQ says compliance with only one regime cannot automatically be treated as full compliance with the other. There may be synergies where the same technical work addresses similar cybersecurity risks, but the manufacturer still has to demonstrate that on the basis of a risk assessment and the applicable standards or technical specifications. The applicable conformity assessment procedures under both frameworks also remain relevant. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 53 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 2.4.2 and 2.4.3 ## How does the CRA interact with the General Product Safety Regulation? They cover different kinds of risks. The CRA addresses cybersecurity risks for products with digital elements. The GPSR addresses product safety for consumer products. Article 11 of the CRA says the GPSR continues to apply to aspects and risks not covered by the CRA, unless those risks are already governed by another specific Union harmonisation law. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 50; Article 11 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 2.5.1 and 2.5.2 ## Does a CRA product sometimes still have to comply with the GPSR? Yes. If the product also presents safety risks that are not covered by the CRA, and those risks are not already addressed by a more specific Union product regime, the GPSR may still apply to those safety aspects. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 50; Article 11 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 2.5.2 ## How does the CRA interact with the Radio Equipment Directive and Delegated Regulation (EU) 2022/30? The key issue is timing. The Commission FAQ says that, for the categories of radio equipment covered by Delegated Regulation (EU) 2022/30, the RED cybersecurity requirements apply to products placed on the market from 1 August 2025 until 10 December 2027. For those same products placed on the market on or after 11 December 2027, the CRA applies instead for the relevant cybersecurity requirements. The FAQ also says a repeal of the RED delegated act from 11 December 2027 would not undo RED market-surveillance treatment for products already placed on the market during the RED period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 30 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 2.6.1 ## How does the CRA interact with the AI Act for high-risk AI systems? Article 12 sets a specific coordination rule. Where a product is both a CRA product and a high-risk AI system, compliance with the CRA can satisfy the AI Act's cybersecurity requirement in Article 15 to the extent covered by the CRA declaration of conformity. As a rule, the AI Act conformity assessment procedure applies for those cybersecurity requirements. But Article 12(3) preserves the CRA's stricter conformity assessment routes for important and critical CRA products where the AI Act would otherwise rely on internal control. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 51; Article 12(1)-(3) ## How does the CRA interact with the European Health Data Space Regulation? A product may need to comply with both. The Commission FAQ says a product may be both a product with digital elements under the CRA and an EHR system under the EHDS Regulation. In that case, both sets of requirements can apply. The same FAQ also says the CRA cybersecurity risk assessment may form part of the EHDS risk assessment, and that, for the covered EHR-system scenario, the EHDS conformity assessment route applies instead of the CRA route because the EHDS introduced Article 32(5a) into the CRA. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(4); Article 28(3); Article 31(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 2.7.1, 2.7.2, 2.7.3 and 2.7.4 ## How does the CRA interact with the GDPR? They are different legal regimes. The CRA regulates products placed on the market. The GDPR regulates the processing of personal data by controllers and processors. They can support similar security outcomes, but the CRA does not replace the GDPR and the GDPR does not replace the CRA. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 32 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 2.8.1 ## Does CRA compliance prove GDPR compliance? No. The Commission FAQ says CRA compliance has no formal effect on the separate GDPR tools used to demonstrate compliance with data-protection law. The two frameworks may reinforce each other in practice, but they are not interchangeable. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 32 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 2.8.1 ## How does the CRA interact with the Data Act? The two regimes address different issues, but one product may fall under both. The CRA is about the making available of products with digital elements and their cybersecurity. The Data Act is about access to and sharing of product data and related service data. The Commission FAQ says manufacturers should take relevant Data Act data-access obligations into account in the CRA risk assessment where those obligations apply to the same product. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 2.9.1 and 2.9.2 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 6; Article 13(2)-(4) ## Does the Data Act by itself force a redesign of all legacy CRA products? No, not as a general rule in the CRA materials. The Commission FAQ says the Data Act does not create a standalone rule that all already marketed products must be redesigned solely because of the Data Act. It also explains that CRA cybersecurity requirements apply fully from 11 December 2027, while products already placed on the market before that date are generally brought into those requirements only if they are substantially modified after that date. The same FAQ adds that CRA reporting obligations apply more broadly. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 2.9.2 and 2.9.3 ## Are medical devices, IVDs, vehicles, certified aviation products, and marine equipment still covered by the CRA? Not in the same way, and sometimes not at all. Article 2 excludes products to which the medical-device and in vitro-diagnostic frameworks apply, products to which Regulation (EU) 2019/2144 applies, products certified under the civil-aviation framework, and marine equipment within Directive 2014/90/EU. Separately, Delegated Regulation (EU) 2025/1535 excludes products falling within the scope of Regulation (EU) No 168/2013, except L1e category vehicles designed to pedal. The Commission FAQ adds an important aviation nuance: products that fall within the aviation framework but are not certified under Regulation (EU) 2018/1139 may still be covered by the CRA, and separately marketed components intended for certified aviation products may also remain in scope if those components are not themselves certified under that framework. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recitals 25 and 27; Article 2(2)-(4) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 1.9, 2.1.1 and 2.2.1 ## Are dual-use products excluded from the CRA? No, not merely because they can also be used for defence or national-security purposes. The CRA excludes products developed or modified exclusively for national security or defence purposes and products specifically designed to process classified information. The Commission FAQ adds that dual-use products with both civilian and defence applications remain subject to the CRA unless they are modified exclusively for national security or defence purposes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 26; Article 2(7)-(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.8 ## If more than one EU product law applies, can the manufacturer issue one EU declaration of conformity? Yes. Article 28(3) requires a single EU declaration of conformity where more than one Union act requiring such a declaration applies to the product. The Commission FAQ confirms the same logic for overlapping CRA and EHDS scenarios. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 28(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 2.7.4 and 6.8 ## Can one technical-documentation set or one risk-assessment workflow support the CRA and more than one other EU law? Often yes, but the manufacturer still has to prove compliance with each law separately. For CRA Article 12 products that are also subject to other Union acts with technical-documentation requirements, Article 31(3) requires a single technical-documentation set. Article 13(4) also allows the CRA cybersecurity risk assessment to form part of the risk assessment required by those other Union acts. The Commission FAQ adds that manufacturers may use one combined risk assessment or separate risk assessments, but they must be able to demonstrate compliance with each applicable regime. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(4); Article 31(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 2.7.2 and 4.1.1 ## Does the mere existence of another Union product law with some cybersecurity rules automatically displace the CRA? No. Outside the CRA's express exclusions and specific delegated acts adopted under Article 2(5), the existence of sector-specific cybersecurity requirements does not by itself switch the CRA off. Recital 28 makes clear that limitation or exclusion for other Union rules requires an additional Commission act and depends on the overall framework addressing the same risks at the same or a higher level of protection. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 28 and Article 2(5) ## If a component is intended for use in aviation, marine, or vehicle products that are excluded or partially excluded, is that component automatically outside the CRA? No. The Commission FAQ says components intended for certified aviation products may still be covered where the component itself is not certified under Regulation (EU) 2018/1139, and the same logic applies to components intended for marine equipment where the component itself is not within Directive 2014/90/EU. The draft guidance adds a more specific rule for vehicle frameworks: components designed and constructed exclusively for integration into vehicles covered by Regulation (EU) 2019/2144 or Regulation (EU) No 168/2013 can stay outside the CRA, but generic components that can also be used elsewhere remain in scope. It also says distribution facts matter: if a non-exclusive component is offered through channels open beyond the automotive supply chain, such as general retail or public online sales, it falls within the CRA regardless of intended-use statements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(2)-(4) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 2.1.1 and 2.2.1 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 9.3.1, points 216-221 ## Can a manufacturer rely on existing EU type-examination certificates or approval decisions issued under other Union product laws once the CRA starts applying? Partly, for a limited time and only for the risks those certificates actually cover. Article 69(1) says EU type-examination certificates and approval decisions issued regarding cybersecurity requirements under other Union harmonisation legislation remain valid until 11 June 2028, unless they expire earlier or that other legislation provides otherwise. The draft guidance explains that this does not amount to full CRA compliance. It only means the manufacturer does not need to reassess or re-demonstrate compliance for the already covered cybersecurity risks during that period. The manufacturer must still perform the CRA cybersecurity risk assessment and address any additional risks not covered by the earlier certificate, including where the prior certificate was issued under the RED cybersecurity regime or the Machinery Regulation. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 2.6.1 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 9.3.2, points 222-232 ## In high-risk AI cases, can an AI Act notified body also assess the CRA cybersecurity requirements? Yes, in the Article 12 coordination setup. Article 12(2) says that, for products with digital elements that are also high-risk AI systems, the relevant AI Act conformity assessment procedure applies for the covered cybersecurity requirements. For that assessment, notified bodies that are competent under the AI Act may also assess conformity with the CRA Annex I requirements, provided their compliance with the CRA notified-body requirements in Article 39 has been assessed in the AI Act notification context. Article 12(3) then preserves the CRA's own stricter routes for important and critical CRA products where the AI Act would otherwise use internal control. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 12(2)-(3) ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Interplay With Other EU Laws as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Interplay With Other EU Laws into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Interplay With Other EU Laws and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws --- --- title: "CRA Known Exploitable Vulnerabilities at Launch FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch" author: "Sorena AI" description: "CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA known exploitable vulnerabilities FAQ" - "CRA launch vulnerabilities" - "CRA CVE launch rule" - "CRA exploitability at launch" - "CRA late-stage vulnerability" - "CRA Article 4(3) testing exception" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Known Exploitable Vulnerabilities at Launch FAQ CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Known Exploitable Vulnerabilities at Launch Use this CRA FAQ to understand what the CRA launch-time rule requires, when a vulnerability counts as known and exploitable, and how manufacturers should handle late-stage discoveries before placement on the market. Built for product security, release, engineering, legal, and compliance teams making CRA launch decisions. The CRA does not require products to be free from all vulnerabilities, but it does bar placing products on the market with known exploitable vulnerabilities. This FAQ focuses on what counts as known and exploitable, how published reports and CVEs should be assessed, and how the launch-time rule differs from the CRA's later vulnerability-handling regime. ## Does the CRA require a product to be free from all vulnerabilities before launch? No. The CRA does not require a product to be free from all vulnerabilities. It requires that, on the basis of the cybersecurity risk assessment and where applicable, the product be made available on the market without known exploitable vulnerabilities. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(a); Article 13(1)-(3); Article 3(40)-(41) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.2 ## What is an exploitable vulnerability under the CRA? The CRA defines an exploitable vulnerability as a vulnerability that has the potential to be effectively used by an adversary under practical operational conditions. That means the issue is not just whether a weakness exists in the abstract, but whether it can actually be used against the product in the conditions in which the product is expected to operate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(40)-(41) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.2 ## What makes a vulnerability "known" for the launch-time rule? The CRA does not define "known" separately in Article 3, but the draft Commission guidance gives a practical interpretation. It says an exploitable vulnerability should be regarded as known when it is listed in relevant publicly accessible vulnerability databases, such as the European vulnerability database under NIS2 or other prominent databases such as the CVE List. It may also be known through non-public information, such as coordinated disclosure by a security researcher or the manufacturer's own internal testing and analysis, and through prominent reporting in reliable media outlets. At the same time, the manufacturer still has to verify whether the reported vulnerability is real and actually applicable to its own product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8); Article 13(17); Annex I Part II points (5) and (6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 9.2.2, points 210-213 ## Does every published CVE or component issue automatically mean the product cannot be launched? No. The Commission FAQ says not all vulnerabilities are exploitable under practical operational conditions. Whether a vulnerability is exploitable has to be assessed case by case, taking into account the product's actual operational and technical conditions. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(a); Article 3(41) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.2 ## Can a vulnerability remain in the product at launch if it is only theoretical or depends on unrealistic conditions? Potentially yes. The Commission FAQ explains that some vulnerabilities are only exploitable in theoretical conditions, such as a lab or simulation, or only under conditions that would not occur in the product's operational environment. In those cases, the manufacturer may conclude on the basis of the risk assessment that the issue is not an exploitable vulnerability for CRA purposes. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.2 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(3); Article 3(41) ## Can compensating controls or mitigations matter when deciding whether a vulnerability is exploitable at launch? Yes. The Commission FAQ says exploitability has to be assessed case by case and expressly lists existing compensating controls as one of the relevant factors. So a weakness is not assessed in isolation; the manufacturer may take account of controls already in place when determining whether the product would still be placed on the market with a known exploitable vulnerability. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.2 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(3) ## Does the CRA launch-time rule on known exploitable vulnerabilities apply only at the moment of placing the product on the market? Yes. The Commission FAQ states that the obligation to make the product available on the market without known exploitable vulnerabilities applies at the moment of placement on the market. After that point, the manufacturer remains subject to the separate vulnerability-handling obligations that apply during the support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(1); Article 13(8); Annex I Part I point (2)(a); Annex I Part II point (2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.2.3 and 4.3.1 ## What if a new exploitable vulnerability is discovered after placement on the market but before the product reaches the final user? The Commission FAQ says the manufacturer is not expected to fix that newly discovered vulnerability before the product reaches the final user, because the Annex I Part I launch-time obligation already applied at placement on the market. But the manufacturer still has to comply with the vulnerability-handling obligations during the support period. Depending on the risk, that can mean providing a security update or other remedy without delay once the product is in use. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8); Annex I Part II point (2) ## Can a manufacturer rely on a plan to patch later instead of dealing with a known exploitable vulnerability before launch? No, not if the vulnerability is already known and exploitable at placement on the market. Inference from the CRA text and the Commission FAQ: Annex I Part I point (2)(a) sets a launch-time condition, and section 4.2.3 of the FAQ makes clear that the later vulnerability-handling obligations are a separate regime that applies after placement on the market. So a post-launch patch plan does not cure a product that was already being placed on the market with a known exploitable vulnerability. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(1)-(3); Annex I Part I point (2)(a); Annex I Part II point (2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.2.2 and 4.2.3 ## Does the launch-time rule cover vulnerabilities in integrated components as well? Yes. The manufacturer's responsibilities apply to the product as a whole, including integrated components. The CRA requires due diligence when integrating third-party components, and both the CRA text and the Commission FAQ make clear that vulnerability handling applies to the product in its entirety, including all integrated components. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 34; Article 13(5)-(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.2.2 and 4.3.6 ## Does the CRA launch-time rule require proof that the vulnerability is already being actively exploited in the wild? No. The launch-time rule is about known exploitable vulnerabilities. The separate concept of an actively exploited vulnerability appears in Article 14 reporting and uses a different definition. A vulnerability can therefore be relevant to launch compliance even if there is no reliable evidence yet that it has already been exploited by a malicious actor. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(41)-(42); Article 14(1); Annex I Part I point (2)(a) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.2.2 and 5.2 ## Does zero-day status create an exception to the launch-time rule? No. The Commission FAQ discusses zero-days only in the context of Article 14 reporting and explains that they become reportable when there is reliable evidence of malicious exploitation. The CRA does not create a separate launch-time carve-out for vulnerabilities merely because no patch is yet available. The relevant launch question remains whether the vulnerability is known and exploitable when the product is placed on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(1)-(2); Annex I Part I point (2)(a) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.2.2 and 5.2 ## Does the CRA require the manufacturer to have a way to receive and process vulnerability information before launch? Yes. The CRA requires appropriate policies and procedures to process and remediate potential vulnerabilities reported from internal or external sources. It also requires a coordinated vulnerability disclosure policy, measures to facilitate sharing information about potential vulnerabilities, and a single point of contact for vulnerability reporting. Those obligations are broader than launch alone, but they are also part of how a manufacturer can know whether the product is being placed on the market with a known exploitable vulnerability. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 63; recital 76; Article 13(8); Article 13(17); Annex I Part II points (5) and (6); Annex II point (2) ## What if the manufacturer realises after placement on the market that the product was not in CRA conformity because of a known exploitable vulnerability? The CRA requires corrective action without delay. Article 13(21) says that, from placing on the market and for the support period, manufacturers who know or have reason to believe that the product is not in conformity with Annex I must immediately take the corrective measures necessary to bring it into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 4.3.4 ## Does a public database entry, CVE, or media report automatically make every product or variant non-compliant at launch? No. The draft guidance says that the mere fact a vulnerability is reported as exploitable does not by itself prove that it is exploitable in practice or applicable to the specific product concerned. The manufacturer still needs to investigate the veracity of the report and its applicability to its own product, including the actual operational conditions and any relevant mitigations. A limited period may therefore elapse between the first report and confirmation, but the guidance stresses prompt investigation and reaction. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(41), Article 13(7)-(8), Annex I Part I point (2)(a) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 9.2.2, points 211-213 ## What if a potentially exploitable vulnerability is discovered shortly before the product is placed on the market? The manufacturer has to make a risk-based launch decision. The draft guidance says that late-stage discoveries can happen during the final stages of development, including shortly before the product enters the distribution chain. In that situation, the manufacturer must determine, on the basis of the cybersecurity risk assessment, whether the product can still be securely placed on the market in compliance with the CRA or whether the vulnerability needs to be fixed before launch. The guidance says that decision should take into account the vulnerability's severity, exploitability, potential impact, and the risks arising for the product once in use. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(1)-(3), Annex I Part I point (2)(a) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 9.2.2, points 214-215 ## Can unfinished alpha, beta, or release-candidate software be made available for testing even if it is not yet fully compliant? Yes, under the CRA's specific testing exception. Article 4(3) says Member States must not prevent the making available on the market of unfinished software that does not comply with the CRA, provided that it is made available only for the limited period required for testing, carries a visible sign stating that it does not comply, and is not made available for purposes other than testing. Recital 37 and the Commission FAQ add that the manufacturer should still perform a risk assessment, comply to the extent possible with the product-property security requirements, and implement vulnerability handling to the extent possible. Article 4(4) adds an important limit: this exception does not apply to safety components covered by Union harmonisation legislation other than the CRA. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 4(3)-(4), recital 37 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.6 ## If a product type is manufactured in series, can later individual units still be placed on the market without already available relevant patches? No. Recital 38 says the essential cybersecurity requirements apply to each individual product when placed on the market, not just to the product type in the abstract. It gives the example that, for a product type, each individual product should have received all security patches or updates available to address relevant security issues when it is placed on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 38 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Known Exploitable Vulnerabilities at Launch as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Known Exploitable Vulnerabilities at Launch into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Known Exploitable Vulnerabilities at Launch and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch --- --- title: "CRA Legacy Products FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/legacy-products" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/legacy-products" author: "Sorena AI" description: "CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA legacy products FAQ" - "CRA pre-2027 products" - "CRA grandfathering" - "CRA Article 14 legacy reporting" - "CRA substantial modification legacy products" - "CRA legacy firmware" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Legacy Products FAQ CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Legacy Products Use this CRA FAQ to understand what happens to products placed on the market before 11 December 2027, what reporting obligations still apply, and when legacy products are brought into the full CRA regime. Built for legal, product, support, compliance, and lifecycle-management teams handling pre-CRA products. The CRA does not generally apply in full to products already placed on the market before 11 December 2027, but it does create important exceptions and limits. This FAQ focuses on grandfathering, Article 14 reporting for older products, substantial modification triggers, and how legacy hardware, spare parts, and separately marketed firmware or software should be treated. ## Does the CRA apply in full to products placed on the market before 11 December 2027? No. Article 69(2) says products with digital elements placed on the market before 11 December 2027 are subject to the CRA requirements only if, from that date, they are subject to a substantial modification. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.4 ## Is there any CRA obligation that still applies to pre-11 December 2027 products even if they are not substantially modified? Yes. Article 69(3) creates a specific derogation for reporting. It says Article 14 applies to all in-scope products that were placed on the market before 11 December 2027, and Article 71(2) says Article 14 starts to apply on 11 September 2026. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(3); Article 71(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 5.3 ## If a product was already placed on the market before 11 December 2027, can it continue to be sold or otherwise made available after that date? Yes. The Commission FAQ explains that individual products placed on the market before 11 December 2027 do not need to be brought into CRA conformity simply because they remain in the distribution chain after that date. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 1.4, 7.2 and 7.5 - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629%2804%29&ref=sorena.io) - sections 2.2 and 2.3 ## Do products have to reach the final user before 11 December 2027 in order to count as legacy products? No. The Commission FAQ gives a direct example: units already placed on the market before 11 December 2027 do not need to be brought into CRA compliance even if they have not yet reached the final user. The legal question is whether the individual product was placed on the market, not whether it was already sold to the final customer or put into service. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.2 - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629%2804%29&ref=sorena.io) - sections 2.3 and 2.6 ## If a manufacturer designed a product type before the CRA applies, can it keep placing newly manufactured units of that type on the market after 11 December 2027? No, not unless those newly placed units comply with the CRA. The Commission FAQ stresses that Union harmonisation legislation, including the CRA, applies to individual products, not to abstract product types or models. So a product is not grandfathered just because an earlier unit of the same type was placed on the market before 11 December 2027. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.4 and 7.2 - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629%2804%29&ref=sorena.io) - sections 2.2 and 2.3 ## What happens if a pre-11 December 2027 product is substantially modified after that date? Then the CRA starts to apply to that product. Article 69(2) makes substantial modification the trigger. The CRA definition in Article 3(30) covers changes made after placing on the market that affect compliance with the essential cybersecurity requirements in Annex I Part I or change the intended purpose for which the product was assessed. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2); Article 3(30); recital 41 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.4 ## If a legacy product receives a bug-fix or security update after 11 December 2027, does that automatically bring the product into the CRA? No. The Commission FAQ gives a direct example: a smart TV placed on the market before 11 December 2027 does not become subject to full CRA requirements merely because it receives a later bug-fix update. Recital 39 of the CRA also says that a security update designed to decrease cybersecurity risk, without modifying intended purpose, is not considered a substantial modification. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 39; Article 3(30); Article 69(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.4 ## What is an example of a post-2027 change that would bring a legacy product into the CRA? The Commission FAQ gives an example where a smart TV placed on the market before 11 December 2027 later receives an update enabling smart-home control. The FAQ treats that as a substantial modification. That result is consistent with recital 39, which says feature updates that modify original intended functions or the type or performance of the product and increase cybersecurity risk should be treated as substantial modifications. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.4 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 39; Article 3(30) ## Do maintenance, repair, or refurbishment of legacy products automatically count as substantial modifications under the CRA? No. Recital 42 says refurbishment, maintenance, and repair do not necessarily lead to a substantial modification. That will depend on whether the intended purpose and functionalities change and whether the level of risk remains unaffected. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 42 ## If a legacy product becomes substantially modified, who is treated as the manufacturer of the modified product? The person who carries out the substantial modification and makes the product available on the market is treated as the manufacturer for CRA purposes. That can be the original manufacturer, but it can also be an importer, distributor, or another natural or legal person. Article 21 covers importers and distributors, and Article 22 covers other persons that substantially modify products and make them available on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 21; Article 22(1) ## If a legacy product is substantially modified, does the CRA apply only to the changed feature or to the product more broadly? That depends on the impact of the modification. Article 22(2) says the person carrying out the substantial modification is subject to Articles 13 and 14 for the part of the product affected by the substantial modification or, if the substantial modification has an impact on the cybersecurity of the product as a whole, for the entire product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 22(2) ## If a distributor is selling pre-11 December 2027 stock after the CRA applies, does the distributor have to bring that stock into compliance? No, not on that basis alone. The Commission FAQ says distributors are not required to bring into compliance products that were already placed on the market before 11 December 2027, unless they themselves carry out a substantial modification. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.5 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 21; Article 69(2) ## Do identical spare parts for legacy products fall outside the CRA? Often yes. Article 2(6) excludes spare parts made available on the market to replace identical components in products with digital elements where the spare parts are manufactured according to the same specifications as the components they are intended to replace. Recital 29 adds that this exemption is meant to cover spare parts used to repair legacy products made available before the CRA's date of application. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(6); recital 29 ## If the replacement part is not identical, is it automatically a substantial modification of the old product? Not automatically. Inference from the CRA text: Article 2(6) only answers whether the identical spare-parts exemption applies. Whether installing a non-identical replacement part becomes a substantial modification is a separate question that still turns on Article 3(30), meaning whether the change affects Annex I Part I compliance or changes the intended purpose for which the product was assessed. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(6); Article 3(30); recital 42 ## For CRA legacy products placed on the market before 11 December 2027, when do the reporting obligations start in practice? They start on 11 September 2026. That is the date Article 14 begins to apply under Article 71(2). The Commission FAQ confirms that, from that date, Article 14 applies even to in-scope products that had been placed on the market before 11 December 2027. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(3); Article 71(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.3 and 7.1 ## For those legacy products, do the early reporting rules mean the manufacturer must also bring the whole product into full CRA conformity? No. The Commission FAQ says that, for products placed on the market before 11 December 2027, manufacturers are required to comply with the Article 14 reporting obligations, but those products are not otherwise brought into the full CRA regime unless they are substantially modified. Article 69(3) is a derogation specifically for Article 14. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2)-(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 1.4 and 5.3 ## If units were already manufactured before 11 December 2027 but were not first placed on the market until after that date, are they legacy products? No. The Commission FAQ says Union harmonisation legislation, including the CRA, applies to individual products, not abstract product types. It also says only individual products that have been placed on the market before 11 December 2027 escape the full CRA regime. So manufacturing, warehousing, or holding stock before that date is not enough by itself if the unit is first placed on the market on or after 11 December 2027. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.2 - [Blue Guide 2022](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022XC0629%2804%29&ref=sorena.io) - sections 2.2 and 2.3 ## If a legacy-era product was designed before the CRA applies but is first placed on the market after 11 December 2027, does the manufacturer have to recreate historical design and test files? No, not necessarily. The draft guidance says a product designed before the CRA's date of application can still be placed on the market after the CRA starts applying, provided the manufacturer can demonstrate current compliance through the cybersecurity risk assessment and technical documentation. Where it is not possible to show how the original design phase took the risk assessment into account, the manufacturer may document a current risk assessment and explain how the existing design mitigates the identified risks. The guidance expressly says the manufacturer is not required to recreate historical design or test documentation just for that purpose. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(4), Article 13(12), Annex VII - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 2.6, points 34-36 ## For legacy products covered only by the Article 14 derogation, when does the reporting obligation arise in time? It applies from 11 September 2026 and, according to the Commission FAQ, upon becoming aware following that date. Article 71(2) brings Article 14 into application on 11 September 2026. The Commission FAQ then says that, for pre-11 December 2027 products, the obligation to notify applies upon becoming aware following the entry into application of the reporting requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(3), Article 71(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 5.3 ## If a legacy product is old enough that the manufacturer can no longer realistically investigate or patch it, what still has to be done under the CRA? The Commission FAQ still expects notification under Article 14 and user information where applicable, but not the full vulnerability-handling regime solely because of Article 69(3). The FAQ gives examples such as missing tooling, unavailable build environments, incompatible dependencies, or departed staff. In that situation, for products placed on the market before 11 December 2027, the manufacturer is still required to notify the vulnerability or incident and Article 14(8) may still require informing impacted users. But the FAQ also says those products are not required, on that basis alone, to comply with other CRA obligations such as vulnerability handling. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14, Article 69(3), Article 71(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 5.3 ## If legacy hardware remains outside full CRA application, can its firmware or software still fall under the CRA when placed on the market separately? Yes. The Commission FAQ's legacy-product example includes an explicit note that firmware referred to in those examples may still fall in scope when placed on the market separately. That reflects the CRA's product-by-product approach: a legacy hardware unit can stay outside the full CRA regime unless substantially modified, while separately marketed software or firmware may still be assessed on its own placement on the market. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.4 and footnote 1 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 2.1, points 10-14 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Legacy Products as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Legacy Products into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Legacy Products and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/legacy-products --- --- title: "CRA Manufacturer Obligations FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations" author: "Sorena AI" description: "CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA manufacturer obligations FAQ" - "CRA Article 13 duties" - "CRA support period" - "CRA vulnerability handling" - "CRA manufacturer reporting" - "CRA technical documentation" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Manufacturer Obligations FAQ CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Manufacturer Obligations Use this CRA FAQ to understand what Article 13 requires from manufacturers before launch, during the support period, and when vulnerabilities, incidents, or authority requests arise. Built for product security, engineering, legal, certification, and compliance teams responsible for CRA manufacturer duties. CRA manufacturer obligations span the full product lifecycle. This FAQ focuses on Article 13 duties, risk assessment, support-period decisions, vulnerability handling, documentation, declarations, user information, reporting, and corrective action obligations that remain with the manufacturer even when work is outsourced. ## Who is the manufacturer under the CRA? Under the CRA, the manufacturer is the natural or legal person who develops or manufactures a product with digital elements, or has it designed, developed, or manufactured, and markets it under its own name or trademark, whether for payment, monetisation, or free of charge. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(13) ## What are the manufacturer's core duties under the CRA? The manufacturer has two central duties. First, when placing a product with digital elements on the market, it must ensure that the product has been designed, developed, and produced in accordance with the essential cybersecurity requirements in Annex I Part I. Second, when placing the product on the market and for the support period, it must ensure that vulnerabilities of the product, including its components, are handled effectively in accordance with Annex I Part II. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(1); Article 13(8) ## Do the manufacturer's CRA duties stop once the product is launched? No. Article 13 requires the manufacturer to take the cybersecurity risk assessment into account during planning, design, development, production, delivery, and maintenance. The CRA therefore covers both pre-market design and post-market vulnerability handling. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2); Article 13(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.1 ## Must the manufacturer carry out a cybersecurity risk assessment? Yes. The manufacturer must undertake a cybersecurity risk assessment for the product and use it to minimise cybersecurity risks, prevent incidents, and minimise their impact, including in relation to users' health and safety. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(4) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.1 ## Does the CRA prescribe one mandatory risk-assessment methodology? No. The CRA does not mandate a single methodology. The manufacturer may choose its approach, but it still has to identify the relevant risks, document how those risks were treated, and be able to demonstrate compliance to market surveillance authorities. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.2 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(4) ## What must the manufacturer's risk assessment cover? At minimum, it must analyse cybersecurity risks based on the intended purpose, reasonably foreseeable use, the conditions of use such as the operational environment or assets to be protected, and the length of time the product is expected to be in use. It must also indicate whether and how Annex I Part I point (2) applies, how those requirements are implemented, and how the manufacturer applies Annex I Part I point (1) and Annex I Part II. The Commission FAQ also states that the risk assessment needs to cover the entire product with digital elements, including remote data processing when in scope and supporting functions that form part of the product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.1 ## Does the manufacturer need to update the risk assessment after launch? Yes. The CRA says the risk assessment must be documented and updated as appropriate during the support period. The manufacturer must also systematically document relevant cybersecurity aspects, including vulnerabilities it becomes aware of and relevant information provided by third parties, and update the risk assessment where applicable. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3); Article 13(7) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ## Must the manufacturer implement every essential cybersecurity requirement in Annex I Part I in the same way for every product? No. The manufacturer must determine, on the basis of the cybersecurity risk assessment, which Annex I Part I requirements are relevant to the product. Where certain essential cybersecurity requirements are not applicable, the manufacturer must include a clear justification in the technical documentation. By contrast, the vulnerability-handling requirements in Annex I Part II apply throughout the support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3)-(4); Article 13(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.3 ## If interoperability needs or other constraints make an Annex I Part I requirement not fully applicable, can the manufacturer just ignore it? No. Article 13(4) allows justified non-applicability, but recital 55 and the Commission FAQ make clear that the manufacturer still has to assess the resulting risks and address them by other means where needed, for example through limits on intended use or user information. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(4); recital 55 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.3 ## Does the manufacturer have to exercise due diligence on third-party components? Yes. The manufacturer must exercise due diligence when integrating third-party components so those components do not compromise the cybersecurity of the product. This expressly includes free and open-source software components that were not made available on the market in the course of a commercial activity. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(5); recital 34 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.4.1 and 4.4.3 ## Does due diligence mean the manufacturer can only use CE-marked components? No. The Commission FAQ says manufacturers can integrate components that do not bear the CE marking, but they still have to exercise due diligence to ensure those components do not compromise the cybersecurity of the finished product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(5); recital 34; recital 35 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.4.1 and 4.4.3 ## What must the manufacturer do if it finds a vulnerability in an integrated component? The manufacturer must report the vulnerability to the person or entity manufacturing or maintaining that component and must address and remediate the vulnerability in accordance with Annex I Part II. If the manufacturer developed a software or hardware modification to address the vulnerability, it must share the relevant code or documentation with the component manufacturer or maintainer where appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6); Article 13(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.6 ## How does the manufacturer determine the support period? The support period must reflect the length of time during which the product is expected to be in use. Article 13(8) says the manufacturer must take into account, in particular, reasonable user expectations, the nature of the product including its intended purpose, and relevant Union law determining product lifetime. It may also take into account the support periods of similar products, the availability of the operating environment, the support periods of core third-party components, and relevant ADCO or Commission guidance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.1 ## Is there a minimum support period? Yes, in most cases. Article 13(8) says the support period must be at least five years, unless the product is expected to be in use for less than five years, in which case the support period corresponds to that expected use time. Where the product is reasonably expected to be in use for longer than five years, the support period should be longer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8); recital 60 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.2 ## What does the manufacturer have to do during the CRA support period? It must ensure effective vulnerability handling for the product, including its components, in line with Annex I Part II. That includes addressing and remediating vulnerabilities without delay in relation to the risks posed, applying regular tests and reviews, maintaining coordinated vulnerability disclosure arrangements, facilitating vulnerability reporting, and securely distributing updates. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8); Annex I Part II ## Must the manufacturer patch every vulnerability it discovers? No. The Commission FAQ says the CRA does not require a dedicated patch for every vulnerability. The manufacturer must assess the relevance and risk of the vulnerability and ensure that an appropriate remedy is put in place without delay. Depending on the risk, that remedy might be a patch, a mitigation, updated instructions, or another corrective measure. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.1 ## Is the manufacturer responsible if users do not install security updates? Not in that sense. The Commission FAQ says the manufacturer's duty is to make security updates available and to provide the mechanisms required by the CRA, including automatic installation where applicable, user notification, and secure distribution. But the CRA does not make the manufacturer responsible where a user does not install available updates, for example after opting out. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 6; Annex I Part I point (2)(c); Annex I Part II points (7) and (8); recital 56 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## Must the manufacturer keep security updates available after release? Yes. Each security update made available during the support period must remain available for at least 10 years after issuance or for the remainder of the support period, whichever is longer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(9) ## Can the manufacturer support only the latest substantially modified software version? In some cases, yes. Where the manufacturer has placed subsequent substantially modified versions of a software product on the market, it may ensure compliance with Annex I Part II point (2) only for the latest version it placed on the market, provided that users of earlier versions have access to that latest version free of charge and without additional hardware or software adjustment costs. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(10); recital 40 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.2 ## Can the manufacturer keep a public CRA software archive of old versions? Yes. The CRA allows public software archives that improve access to historical versions. If the manufacturer does this, users must be clearly informed in an easily accessible manner about the risks associated with using unsupported software. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(11) ## What must the manufacturer do before placing the product on the market? Before placing the product on the market, the manufacturer must draw up the technical documentation, carry out the applicable conformity assessment procedure or have it carried out, draw up the EU declaration of conformity once conformity is demonstrated, and affix the CE marking. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12); Article 28; Article 30; Article 32 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.6 and 6.8 ## How long must the manufacturer keep the technical documentation and EU declaration of conformity? For at least 10 years after placing the product on the market or for the support period, whichever is longer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(13) ## Does the manufacturer have to keep series production in conformity? Yes. The manufacturer must ensure that procedures are in place so products that are part of a series of production remain in conformity. It must adequately take into account changes in development, production, design, product characteristics, and relevant harmonised standards, certification schemes, or common specifications. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(14) ## What product identification and contact information must the manufacturer provide? The manufacturer must ensure that the product bears a type, batch, serial number, or other identifying element. It must also indicate its name, trade name or trademark, and postal address and email address or other digital contact details and, where applicable, website, on the product, packaging, or accompanying document. That same contact information must also be included in the information and instructions to the user. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(15)-(16); Annex II point (1) ## Must the manufacturer provide a single point of contact for vulnerability reporting? Yes. The manufacturer must designate a single point of contact so users can communicate directly and rapidly with it, including for vulnerability reporting. The single point of contact must be easily identifiable, must let users choose their preferred means of communication, and must not limit communication to automated tools. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17); Annex II point (2); recital 63 ## Must the manufacturer provide information and instructions to users? Yes. The manufacturer must ensure that the product is accompanied by the Annex II information and instructions, in paper or electronic form, in a language easily understood by users and market surveillance authorities. They must be clear, understandable, intelligible, and legible and must allow secure installation, operation, and use. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(18); Annex II ## Must the manufacturer disclose the support-period end date to buyers? Yes. The manufacturer must clearly and understandably specify the end date of the support period, at least month and year, at the time of purchase in an easily accessible manner and, where applicable, on the product, packaging, or by digital means. Where technically feasible, it must also notify users when the product has reached the end of its support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(19); Annex II point (7); recital 56 ## Must the manufacturer include the EU declaration of conformity with the product? Yes, either in full or in simplified form. The manufacturer must provide either a copy of the full EU declaration of conformity or a simplified EU declaration of conformity with the product. If the simplified version is used, it must contain the exact internet address where the full declaration can be accessed. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(20) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.8 ## Must the manufacturer report actively exploited vulnerabilities and severe incidents? Yes. Under Article 14, the manufacturer must notify actively exploited vulnerabilities and severe incidents having an impact on the security of the product. The key CRA deadlines are an early warning within 24 hours of becoming aware and a fuller notification within 72 hours. After that, the final report deadline differs: for an actively exploited vulnerability it is no later than 14 days after a corrective or mitigating measure is available, while for a severe incident it is within one month after the incident notification. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(1)-(4) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.2 and 5.3 ## After becoming aware of an actively exploited vulnerability or severe incident, must the manufacturer also inform users? Yes. Article 14(8) requires the manufacturer to inform impacted users, and where appropriate all users, of the vulnerability or incident and any risk-mitigation or corrective measures users can deploy. If the manufacturer does not inform users in a timely manner, the notified CSIRTs may do so where necessary and proportionate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 5.3 ## Can the manufacturer shift its core Article 13 duties to an authorised representative? No. Article 18(2) says the obligations in Article 13(1) to (11), Article 13(12) first subparagraph, and Article 13(14) cannot form part of the authorised representative's mandate. Those remain the manufacturer's own responsibilities. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 18(2) ## What must the manufacturer do if it knows or has reason to believe the product is not in conformity? From placing on the market and for the support period, the manufacturer must immediately take the corrective measures necessary to bring the product or the manufacturer's processes into conformity, or withdraw or recall the product as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ## What must the manufacturer do if a market surveillance authority asks for evidence? The manufacturer must provide, in paper or electronic form and in a language easily understood by the authority, all information and documentation necessary to demonstrate conformity. It must also cooperate with the authority on measures taken to eliminate cybersecurity risks posed by the product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(22) ## What happens under the CRA if the manufacturer is going to cease operations? Before the cessation takes effect, the manufacturer must inform the relevant market surveillance authorities and, by any means available and to the extent possible, the users of the relevant products placed on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(23) ## Can the manufacturer use one risk assessment for the CRA and other applicable EU product laws? Yes. The Commission FAQ says the manufacturer may carry out a single risk assessment covering different applicable legislation or separate assessments for each instrument. What matters is that the manufacturer remains able to demonstrate compliance with each individual act. For CRA purposes, the assessment still has to cover the entire product with digital elements, including any in-scope remote data processing and supporting functions that form part of the product. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.1 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(4) ## If the manufacturer outsources design, development, assembly, or similar work, can it shift its CRA responsibility to the subcontractor? No. Under the CRA definition, a manufacturer can still be the manufacturer where it has the product designed, developed, or manufactured and places it on the market under its own name or trademark. The Blue Guide adds that where subcontracting takes place, the manufacturer must retain overall control and cannot discharge its responsibilities to an authorised representative, distributor, user, or subcontractor. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(13) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 3.1 ## Must the manufacturer have procedures to process vulnerability reports coming from internal and external sources? Yes. Article 13(8) expressly requires appropriate policies and procedures, including coordinated vulnerability disclosure policies, to process and remediate potential vulnerabilities reported from internal or external sources. The March 2026 draft guidance repeats that requirement when explaining how manufacturers are expected to organise their handling of potential vulnerabilities. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 210 ## If the manufacturer provides the user information and instructions online, what extra obligation applies? They must stay accessible, user-friendly, and available online for at least 10 years after the product is placed on the market or for the support period, whichever is longer. So the CRA does not only require the manufacturer to provide Annex II information once. If those materials are hosted online, the manufacturer has an ongoing availability obligation for the same long-term period that applies to keeping them at the disposal of users and market surveillance authorities. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(18); Annex II ## Must the manufacturer document how it determined the support period? Yes. Article 13(8) requires the manufacturer to include in the technical documentation the information taken into account to determine the support period. Annex VII repeats that requirement, so the support-period decision has to be documented, not just decided internally. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8); Annex VII point (4) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.1 ## Can products already placed on the market continue to be made available after their support period has expired? Yes. The Commission FAQ says products already placed on the market can continue to be made available after the support period expires. But if the manufacturer later places additional units of that product on the market, it still has to determine the support period for those newly placed units in accordance with Article 13(8). Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8) ## If a product was designed before the CRA applied, must the manufacturer redesign it or recreate historical design and test files before placing it on the market? Not necessarily. The March 2026 draft guidance says a product designed before the CRA applies may still be placed on the market without redesign if the manufacturer carries out a current cybersecurity risk assessment and can show through the technical documentation that the existing design already addresses the relevant risks. Where the manufacturer cannot show how the original design phase took the risk assessment into account, the guidance says it is not required to recreate historical design or test documentation that would not improve the product's cybersecurity. But the manufacturer still has to complete the CRA's current obligations before placement on the market, including the conformity assessment, declaration of conformity, and CE marking steps. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 30-35 and Example 7 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2); Article 13(12) ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Manufacturer Obligations as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Manufacturer Obligations into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Manufacturer Obligations and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations --- --- title: "CRA Market Surveillance and Enforcement FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement" author: "Sorena AI" description: "CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA market surveillance FAQ" - "CRA enforcement FAQ" - "CRA safeguard procedure" - "CRA formal non-compliance" - "CRA sweeps" - "CRA fines and penalties" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Market Surveillance and Enforcement FAQ CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Market Surveillance and Enforcement Use this CRA FAQ to understand how Member State authorities enforce the CRA, what investigations and safeguards look like, and how sweeps, formal non-compliance, and Union-level interventions work. Built for legal, compliance, certification, regulatory, and product teams managing CRA enforcement risk. The CRA relies on the Union market-surveillance framework rather than creating a separate enforcement system from scratch. This FAQ focuses on who enforces the CRA, what can trigger investigations, how safeguard procedures and formal non-compliance work, and how sweeps, joint activities, confidentiality, and fines fit into the enforcement model. ## Who enforces the CRA on the market? Member States do, through their designated market surveillance authorities. The CRA requires each Member State to designate one or more market surveillance authorities, and it makes the general Union market-surveillance framework in Regulation (EU) 2019/1020 applicable to products within the CRA's scope. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 52(1)-(2) ## Does the CRA create a separate enforcement system from general EU market-surveillance law? No. The CRA uses the existing Union market-surveillance framework rather than creating a completely standalone enforcement system. Article 52(1) expressly makes Regulation (EU) 2019/1020 applicable to products with digital elements covered by the CRA. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 52(1) ## Who is responsible for CRA market surveillance when the product is also a high-risk AI system? For those products, the market-surveillance authorities designated under the AI Act are responsible for the CRA market-surveillance activities. They still have to cooperate, as appropriate, with the market-surveillance authorities designated under the CRA and, for Article 14 reporting supervision, with the CSIRTs designated as coordinators and ENISA. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 52(14) ## Are open-source software stewards also supervised through CRA market surveillance? Yes. The authorities designated under Article 52 are also responsible for market-surveillance activities relating to the obligations imposed on open-source software stewards under Article 24. If a steward is non-compliant, the authority must require appropriate corrective action. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 24, Article 52(3) ## Do CRA market-surveillance authorities have to cooperate with other regulators? Yes. The CRA requires cooperation, where relevant, with national cybersecurity certification authorities, CSIRTs designated as coordinators, ENISA, market-surveillance authorities under other Union product laws, and authorities supervising Union data-protection law. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 52(4)-(7) ## Can complaints, vulnerability reports, or other outside signals trigger enforcement attention? Yes. The CRA requires authorities to inform consumers where to submit complaints indicating possible non-compliance and where and how to access mechanisms for reporting vulnerabilities, incidents, and cyber threats affecting products with digital elements. Because the CRA applies the Union market-surveillance framework in Regulation (EU) 2019/1020, the Blue Guide also states that complaints must be followed up appropriately and that consumer complaints, media reports, incidents, and similar information can feed the authorities' risk-based choice of online and offline checks. But a complaint or report does not by itself establish infringement. Any corrective or restrictive measure still has to rest on the legal findings required under the CRA procedures. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 52(1) and (11), Articles 54, 57 and 58 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 7.3.3 and 7.4.1 ## Can CRA market-surveillance authorities provide guidance as well as enforce? Yes. The CRA expressly allows market-surveillance authorities to provide guidance and advice to economic operators on implementation, with support from the Commission and, where appropriate, CSIRTs and ENISA. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 52(10) ## What can trigger a formal CRA product evaluation by a national authority? A national authority can open the Article 54 procedure where it has sufficient reason to consider that a product with digital elements, including its vulnerability handling, presents a significant cybersecurity risk. The evaluation concerns compliance with all CRA requirements, not just one suspected defect. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 54(1) ## Does "significant cybersecurity risk" include non-technical factors? Yes. When determining the significance of a cybersecurity risk, authorities must also consider non-technical risk factors, in particular those identified through Union-level coordinated security risk assessments of critical supply chains under NIS 2. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 54(2), Article 56(2) ## What must economic operators do during a CRA investigation? They must cooperate with the market-surveillance authority as necessary. The CRA also allows authorities to request technical support from a CSIRT designated as coordinator or from ENISA when implementing or enforcing the Regulation and when evaluating compliance under Article 54. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 52(5), Article 54(1) ## Can authorities ask for internal documentation and data, not just the public-facing compliance file? Yes. On a reasoned request, authorities must be granted access to the data needed to assess design, development, production, and vulnerability handling, including related internal documentation of the relevant economic operator. The documentation must be accessible in a language easily understood by the authority. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 53 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ## Can data-protection authorities also access CRA documentation? Yes, where they need that documentation for the fulfilment of their own tasks. Article 52(7) gives authorities supervising Union data-protection law the power to request and access documentation created or maintained under the CRA, while also requiring them to inform the designated CRA market-surveillance authorities of the Member State concerned. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 52(7) ## Do market-surveillance authorities have to test a product in the same way as the manufacturer? Not necessarily. The Commission FAQ says authorities may consider using the same methodology as the manufacturer, especially where that methodology is part of a harmonised standard supporting the CRA, but they may use a different methodology on a justified basis. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.6 ## What measures can a national authority require after it finds CRA non-compliance? It can require the relevant economic operator to bring the product into compliance, withdraw it from the market, or recall it. The deadline must be reasonable and proportionate to the nature of the cybersecurity risk. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 54(1) ## If a CRA problem is found in one Member State, does the corrective action stop there? No. If the product has been made available across the Union, the economic operator must ensure that appropriate corrective action is taken for all affected products throughout the Union. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 54(3)-(4) ## What happens if the operator does not take adequate corrective action? The national authority must take appropriate provisional measures itself. Those measures can include prohibiting or restricting the product from being made available on the national market, withdrawing it, or recalling it. The authority must then notify the Commission and the other Member States without delay. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 54(5)-(6) ## When does a national provisional measure become "deemed justified" at Union level? If no Member State and the Commission object within three months after the Article 54(5) notification, the measure is deemed justified. That deeming rule does not prejudice the economic operator's procedural rights under Regulation (EU) 2019/1020. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 54(8)-(9) ## What is the CRA Union safeguard procedure? It is the Commission review process that applies when another Member State objects to a notified national measure or when the Commission considers that measure contrary to Union law. The Commission must consult the relevant Member State and the economic operator, evaluate the national measure, and decide within nine months from the Article 54(5) notification whether the measure is justified. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 55(1)-(2) ## What if the underlying CRA enforcement problem comes from a harmonised standard, a certification scheme, or a common specification? The safeguard procedure still applies, but the Commission may also need to act on the conformity tool itself. If the justified national measure is linked to shortcomings in a harmonised standard, the Commission applies the standards safeguard procedure. If it is linked to shortcomings in a European cybersecurity certification scheme or in common specifications, the Commission must consider whether to amend or repeal the CRA act that gave that tool presumption-of-conformity effect. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 54(6)(b), Article 55(3)-(5) ## Can a product still be restricted even if it complies with the CRA? Yes. Article 57 covers products that are compliant with the CRA but still present a significant cybersecurity risk together with a risk to health or safety, fundamental-rights compliance, the availability, authenticity, integrity or confidentiality of services offered by essential entities, or other aspects of public-interest protection. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 57(1)-(5) ## Can the Commission intervene directly in exceptional cases? Yes. If immediate intervention is justified to preserve the proper functioning of the internal market, and effective national measures have not been taken, the Commission may carry out its own evaluation, may request ENISA analysis, and may adopt Union-level implementing acts requiring corrective or restrictive measures, including withdrawal or recall. The CRA provides this type of Union-level intervention both for non-compliant products that present a significant cybersecurity risk and for compliant products that still present the risks covered by Article 57. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 56(3)-(7), Article 57(6)-(10) ## What role do CSIRTs and ENISA play in CRA enforcement? They support enforcement, but they are not the primary market-surveillance authorities. Authorities may ask CSIRTs designated as coordinators or ENISA for technical advice and compliance-support analysis. ENISA can also propose joint activities and identify product categories for sweeps. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 52(4)-(5), Article 56(3), Article 57(7), Article 59(2), Article 60(3) ## Does a notified-body certificate or other third-party conformity evidence block CRA market-surveillance action? No. The CRA still allows market-surveillance authorities to investigate, require corrective action, adopt restrictive measures, and address formal non-compliance. Where an Article 54 investigation leads to corrective action, the authority must also inform the relevant notified body. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 54(1), Article 57, Article 58 ## What is "formal non-compliance" under the CRA? It covers certain documentary or marking failures even before the authority proves a deeper substantive breach of Annex I. Article 58 lists the relevant cases: CE marking missing or wrongly affixed, the EU declaration of conformity missing or incorrect, the notified-body identification number missing where required, or technical documentation unavailable or incomplete. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 58(1) ## What happens under the CRA if formal non-compliance is not fixed? The Member State concerned must take appropriate measures to restrict or prohibit the product from being made available on the market or to ensure that it is recalled or withdrawn. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 58(2) ## What are joint activities under the CRA? They are coordinated actions that market-surveillance authorities may carry out with other relevant authorities for specific products or categories of products, especially where those products are often found to present cybersecurity risks. The Commission or ENISA may propose joint activities based on indications of potential non-compliance across several Member States, and the agreement on joint activities must be made public. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 59 ## What are CRA sweeps? Sweeps are simultaneous coordinated control actions for particular products or product categories to check compliance or detect infringements. They may include inspections of products acquired under a cover identity. Unless the participating authorities agree otherwise, sweeps are coordinated by the Commission, and ENISA may propose categories of products for which sweeps should be organised. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 60 ## Can CRA market surveillance focus on support-period decisions as well as immediate vulnerabilities? Yes. Authorities must monitor how manufacturers applied the Article 13(8) criteria when determining support periods. ADCO must publish relevant statistics, including average support periods, and may issue recommendations to focus surveillance on product categories where support periods appear inadequate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 52(16) ## Is CRA enforcement subject to confidentiality protections? Yes. The CRA protects intellectual property, confidential business information, trade secrets, source code, the effectiveness of inspections and investigations, public and national security interests, and the integrity of criminal or administrative proceedings. Information exchanged confidentially between authorities and the Commission is also protected against onward disclosure without the originating authority's agreement. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 63 ## How do CRA penalties and administrative fines work? Member States must lay down the national penalty rules, but Article 64 sets Union-level caps for certain infringements. The highest cap applies to non-compliance with Annex I and with Articles 13 and 14: up to EUR 15 000 000 or, for an undertaking, up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. Article 64 also sets lower caps for other listed obligations and for supplying incorrect, incomplete, or misleading information. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(1)-(4) ## Can administrative fines be added on top of other CRA measures? Yes. The CRA expressly allows administrative fines, depending on the circumstances, to be imposed in addition to other corrective or restrictive measures applied for the same infringement. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(9) ## Is supplying misleading information to market-surveillance authorities a separate sanctionable issue? Yes. Supplying incorrect, incomplete, or misleading information to notified bodies or market-surveillance authorities in reply to a request has its own fine category, with a cap of up to EUR 5 000 000 or, for an undertaking, up to 1% of total worldwide annual turnover for the preceding financial year, whichever is higher. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(4) ## Do market-surveillance authorities report enforcement outcomes beyond the immediate case? Yes. They must report the outcomes of relevant market-surveillance activities to the Commission on an annual basis. They must also report without delay any information identified during market-surveillance activities that may be of potential interest for the application of Union competition law. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 52(13) ## Does every CRA enforcement case follow the same legal track? No. The CRA uses different enforcement routes depending on the problem. Article 54, together with Article 55, covers products that present a significant cybersecurity risk and are found non-compliant. Article 57 covers products that comply with the CRA but still present the additional risks listed there. Article 58 covers formal non-compliance such as missing or incorrect CE-marking, declaration, or technical-documentation elements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Articles 54, 55, 57 and 58 ## Does the economic operator get a chance to present its position and keep procedural rights during safeguard action? Yes. Article 54(6) requires the notifying authority to include the arguments put forward by the relevant economic operator. Article 54(8) also preserves the operator's procedural rights under Regulation (EU) 2019/1020, and Article 55(1) requires the Commission to consult the relevant economic operator during the Union safeguard procedure. The Blue Guide likewise explains that safeguard decisions are binding legal measures and can be subject to appeal under the applicable framework. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 54(6) and (8), Article 55(1) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 7.6.2 ## Can information gathered in a CRA joint activity be used later in a national investigation? Yes. Article 59(4) expressly allows a market-surveillance authority to use information obtained through joint activities as part of any investigation it undertakes. So joint activities are not limited to one-off coordination exercises with no later evidentiary value. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 59(4) ## During a CRA sweep, can authorities use their ordinary investigation powers and involve Commission officials? Yes. Article 60 says sweeps may include inspections of products acquired under a cover identity. It also says that, when conducting sweeps, market-surveillance authorities may use the investigation powers in Articles 52 to 58 and any additional powers conferred by national law. They may also invite Commission officials and other persons authorised by the Commission to participate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 60(1), (4) and (5) ## Can ADCO trigger a Union-wide dependency assessment that leads to SBOM requests? Yes. Article 13(25) allows ADCO to decide to conduct a Union-wide dependency assessment for specific categories of products with digital elements. For that purpose, market-surveillance authorities may request manufacturers of those categories to provide the relevant SBOMs. The authorities may then provide ADCO only anonymised and aggregated information about software dependencies. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(25) ## Can CRA market-surveillance authorities formally cooperate with researchers, scientific bodies, or consumer organisations? Yes. Article 52(12) requires market-surveillance authorities to facilitate, where relevant, cooperation with relevant stakeholders, including scientific, research, and consumer organisations. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 52(12) ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Market Surveillance and Enforcement as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Market Surveillance and Enforcement into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Market Surveillance and Enforcement and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement --- --- title: "CRA Module A FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/module-a" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/module-a" author: "Sorena AI" description: "CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA module A FAQ" - "CRA internal control" - "CRA self-assessment" - "CRA module A eligibility" - "CRA class I module A" - "CRA Article 32 module A" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Module A FAQ CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Module A Use this CRA FAQ to understand the internal-control route under module A, when it is available, what evidence it still requires, and how it interacts with harmonised standards, FOSS exceptions, and later modifications. Built for product, engineering, certification, and compliance teams using the CRA self-assessment route. Module A is the CRA's internal-control conformity-assessment route, but it is not a shortcut around real compliance work. This FAQ focuses on who can use module A, when Article 32 blocks it, what documentation and evidence it still requires, and how it behaves for FOSS, updates, and later substantial modifications. ## What is module A under the CRA? Module A is the internal control conformity-assessment procedure. Under this route, the manufacturer itself ensures and declares, on its sole responsibility, that the product satisfies the essential cybersecurity requirements in Part I of Annex I and that the manufacturer meets the vulnerability-handling requirements in Part II of Annex I. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1)(a), Annex VIII Part I point 1 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.1 ## Is a notified body involved in module A? No. Module A is the CRA's self-assessment route. The Commission FAQ states expressly that no notified body participates in this procedure. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part I - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.1 ## Is module A the default CRA conformity-assessment route? Yes, for products that are not pushed by Article 32 into a stricter route. Article 32(1) lists module A as one of the CRA's general conformity-assessment procedures. In practice, it is the route available unless the product falls into the specific cases where Article 32(2), 32(3), or 32(4) require another procedure. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1)-(4) ## Which CRA products can use module A? Module A is available for: - products that are not important products or critical products - important products of class I where Article 32(2) does not force a third-party route - important products of class I or II that qualify as free and open-source software, if the technical documentation is made public at the time of placing on the market Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1), Article 32(2), Article 32(5) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.1 ## Can a manufacturer choose module A even when module B+C or module H would also be available? Yes, where Article 32 does not make a stricter route mandatory. For products covered by Article 32(1), the manufacturer may demonstrate conformity by using module A, module B+C, module H, or, where available and applicable, a qualifying European cybersecurity certification scheme. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1) ## When is module A no longer enough for an important product of class I? Module A is no longer enough for the essential cybersecurity requirements for which the manufacturer has not applied, or has only partly applied, the relevant harmonised standards, common specifications, or qualifying European cybersecurity certification schemes, or where those tools do not exist. In that situation, Article 32(2) requires module B+C or module H for those requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(2) ## If a class I product uses harmonised standards only in part, can module A still be used for the rest? Only in a limited sense. Inference from Article 32(2): where a class I product relies only partly on the relevant harmonised standards, common specifications, or qualifying certification schemes, the remaining essential cybersecurity requirements must go through module B+C or module H. Article 32(2) is framed requirement-by-requirement, not as an automatic all-or-nothing ban on all use of module A. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(2) ## Can an important product of class II use module A? Not as a general rule. Important products of class II must use the procedures listed in Article 32(3), unless the product qualifies for the specific free-and-open-source-software exception in Article 32(5). Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(3), Article 32(5) ## Can a critical product use module A? No. Critical products listed in Annex IV must use the procedures in Article 32(4), which do not include module A. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(4) ## What is special about the Article 32(5) free and open-source software exception for module A? It is a narrow exception for products qualifying as free and open-source software that fall under Annex III. Article 32(5) allows those products to use one of the procedures listed in Article 32(1), including module A, provided that the technical documentation under Article 31 is made available to the public at the time the product is placed on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(5) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.1 and 6.6 ## Does module A still require technical documentation? Yes. Under Annex VIII Part I point 2, the manufacturer must draw up the technical documentation described in Annex VII. More broadly, Article 31 requires technical documentation that shows how the product and the manufacturer's processes comply with Annex I. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31, Annex VII, Annex VIII Part I point 2 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.6 ## Does module A still require testing or other evidence? Yes. Module A is not a paperwork-only route. The manufacturer still has to verify that the product complies with the relevant essential cybersecurity requirements and be able to demonstrate that through technical documentation and supporting evidence. The CRA does not mandate a single evaluation methodology. The Commission FAQ says manufacturers may verify conformity through testing or other mechanisms. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12), Article 31(1), Annex VII point 5, Annex VIII Part I point 1 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.1 and 6.5 ## Can the manufacturer use internal or external laboratories under module A? Yes. The Commission FAQ says the manufacturer may perform the relevant tests in its own laboratories, if available, or in external laboratories. Under module A, the manufacturer still remains solely responsible for the conformity assessment. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.5 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part I point 1 ## Does module A cover only design, or also production and vulnerability handling? It covers design, development, production, and vulnerability handling. Annex VIII Part I point 3 is broader than a design-only check. It requires the manufacturer to take all measures necessary so that the relevant processes, and their monitoring, ensure compliance of both the product and the manufacturer's processes with Annex I. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part I point 3 ## Does module A require the manufacturer to control serial production consistency? Yes. The Commission FAQ explains that, under module A, the manufacturer must ensure that production of the different units does not alter compliance with the CRA essential cybersecurity requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part I point 3 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.1 ## What has to happen before the manufacturer can affix the CE marking under module A? The manufacturer must first be in a position to demonstrate that the product complies with the CRA. After that, the manufacturer affixes the CE marking to each individual compliant product and draws up the written EU declaration of conformity. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 28, Article 30, Annex VIII Part I point 4 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.1, 6.7 and 6.8 ## Is the declaration of conformity under module A linked to the product, not just to the route? Yes. Annex VIII Part I point 4.2 requires a written EU declaration of conformity for each product with digital elements, and the declaration must identify the product for which it has been drawn up. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 28, Annex VIII Part I point 4.2 ## What records must be kept under module A, and for how long? The manufacturer must keep the technical documentation and the EU declaration of conformity at the disposal of the authorities for at least 10 years after the product has been placed on the market or for the support period, whichever is longer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(13), Annex VIII Part I point 4.2 ## Does module A mean the technical documentation has to be public? No, not in general. The Commission FAQ states that there is no general obligation to make the technical documentation public. The exception relevant here is the Article 32(5) rule for important free-and-open-source software using the Annex III exception. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.6 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(5) ## Can an authorised representative handle all module A obligations? No. Under Annex VIII Part I point 5, the authorised representative may fulfil only the manufacturer's obligations under point 4, on the manufacturer's behalf and under the manufacturer's responsibility, if the mandate expressly covers those obligations. That means the CE-marking and declaration steps can be mandated, but the wider manufacturer obligations that underpin module A are not generally transferred. Article 17(2) reinforces that the obligations in Article 13(1) to (11), Article 13(12) first subparagraph, and Article 13(14) cannot form part of the authorised representative's mandate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 17(2), Annex VIII Part I point 5 ## Does module A protect the manufacturer from later market-surveillance scrutiny? No. Products assessed under module A remain subject to market surveillance. Authorities may request the technical documentation and related internal documentation, evaluate compliance, and act if they find non-compliance or formal non-compliance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 53, Article 54, Article 58 ## What usually makes a CRA module A file defensible in practice? A defensible file is one that clearly shows how the manufacturer reached its compliance conclusion. Grounded in Article 31, Annex VII, and the Commission FAQ, that usually means the documentation clearly identifies the applicable essential cybersecurity requirements, explains any justified non-applicability, records the cybersecurity risk assessment, and shows the technical means, standards, specifications, tests, or other evidence used to demonstrate conformity. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(4), Article 31, Annex VII - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.8, 6.1, 6.5 and 6.6 ## Can a default-category product still use module A even if no CRA harmonised standards, common specifications, or qualifying certification schemes exist yet? Yes. For default-category products, Article 32(1) makes module A available without conditioning it on the existence of harmonised standards, common specifications, or qualifying certification schemes. The stricter no-standard rule in Article 32(2) is specific to important products of class I. The Commission FAQ also says harmonised standards are voluntary and manufacturers may demonstrate conformity through other technical means, provided those means are documented in the technical documentation. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27, Article 32(1)-(2), Annex VII point (5) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.7, 6.1 and 6.6 ## Does choosing module A by itself give the product presumption of conformity? No. Module A is only a conformity-assessment route. Presumption of conformity comes from the Article 27 tools, such as harmonised standards, common specifications, or qualifying European cybersecurity certification schemes, to the extent they cover the relevant requirements. If the manufacturer does not use those means, it may still use module A where the product is eligible, but it must explain in the technical documentation how compliance is reached otherwise. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(1), (5) and (8), Annex VII point (5) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.7 and 6.6 ## If the finished product integrates an important or critical component that does not follow harmonised standards, does that automatically block module A for the finished product? No. The Commission FAQ states that manufacturers are free to integrate important or critical components that were not designed in accordance with harmonised standards, regardless of whether such standards exist. It also explains that integrating an important or critical product into another product does not automatically render the finished product subject to the conformity-assessment procedures for that important or critical category. So the finished product's own core functionality still determines whether module A remains available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 7(1), Article 32 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 3 and 7.4 ## For the Article 32(5) free-and-open-source-software exception, does making the technical documentation public replace the rest of the module A work? No. Making the technical documentation public is an extra condition for important class I or class II products qualifying as free and open-source software to keep access to the Article 32(1) routes, including module A. It does not replace the ordinary module A activities. The manufacturer still has to perform the risk-based compliance work, verify conformity, draw up the technical documentation, and only then affix the CE marking and sign the declaration of conformity. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(5), Annex VIII Part I - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.1 and 6.6 ## If a later software update does not qualify as a substantial modification, does the manufacturer still need to update the module A documentation? Yes. The March 2026 draft guidance says non-substantial updates do not trigger a new conformity assessment procedure or change the original placing-on-the-market date. But regardless of whether an update is substantial, manufacturers must keep the risk assessment and technical documentation accurate, complete, and continuously up to date. Article 31(2) also requires the technical documentation to be continuously updated where appropriate, at least during the support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Article 31(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 15 and 106 ## If a product is substantially modified later, can the manufacturer re-use module A? Sometimes, yes. The March 2026 draft guidance says a substantially modified product is treated as a new product and is newly placed on the market, so a new conformity assessment is required before that modified product is placed on the market. The same guidance also says existing documentation and tests may be re-used for unchanged parts. If the substantially modified product still falls in a category for which Article 32 allows module A, module A can be used again; if the modified product falls into a category that requires a stricter route, the applicable Article 32 route must be used instead. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1)-(4) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.8 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 107-110 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Module A as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Module A into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Module A and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/module-a --- --- title: "CRA Module B+C FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/module-b-c" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/module-b-c" author: "Sorena AI" description: "CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA module B+C FAQ" - "CRA EU-type examination" - "CRA conformity to type" - "CRA notified body module B+C" - "CRA module B certificate" - "CRA module C production control" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Module B+C FAQ CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Module B+C Use this CRA FAQ to understand the two-step module B+C route, what the notified body examines, what production-control duties remain with the manufacturer, and when post-certificate changes require further approval. Built for certification, engineering, legal, and compliance teams using or reviewing the CRA type-examination route. Module B+C combines notified-body type examination with manufacturer-led production control. This FAQ focuses on what must be submitted for EU-type examination, what the certificate covers, what module C adds, and how later changes, language rules, CE marking, and audits work under this route. ## What is module B+C under the CRA? Module B+C is a two-step conformity-assessment route. Module B is EU-type examination by a notified body. Module C is conformity to the approved type based on the manufacturer's internal production control. Together, they cover both the examination of the product type and the manufacturer's obligation to keep actual production in line with that approved type. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1)(b), Annex VIII Parts II and III - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.2 ## When is module B+C mandatory? Module B+C is one of the mandatory third-party routes for: - important products of class I where Article 32(2) requires third-party assessment for the relevant requirements - important products of class II - critical products, unless the applicable certification route under Article 8(1) applies Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(2)-(4) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.2 ## Can a manufacturer also choose module B+C voluntarily? Yes. Article 32(1) allows manufacturers to use module B+C for products generally covered by paragraph 1, even where module A would also be available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.2 ## Does module B+C always involve a notified body? Yes. Module B is the notified-body part of the route. Module C then follows with the manufacturer's own internal production control against the approved type. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Parts II and III ## How many notified bodies can be involved in one module B application? Only one. The manufacturer must lodge the EU-type examination application with a single notified body of its choice and must declare that the same application has not been lodged with any other notified body. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II point 3, point 3.2 ## What does the manufacturer have to submit for module B? The application must include: - the manufacturer details and, where relevant, the authorised representative's details - a declaration that the same application has not been lodged with another notified body - technical documentation that allows conformity to be assessed, including an adequate analysis and assessment of the risks - supporting evidence for the adequacy of the technical design, development solutions, and vulnerability-handling processes Where necessary, the supporting evidence must include test results from the manufacturer's own laboratory or another testing laboratory acting on its behalf and under its responsibility. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II point 3.1-3.4 ## Does module B cover only the product's technical design, or also vulnerability handling? It covers both. EU-type examination is not limited to the product's technical design and development. The notified body also examines the vulnerability-handling processes put in place by the manufacturer against Part II of Annex I. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II points 1, 3.3, and 4.1 ## Does the notified body assess only documents, or also specimens and tests? It assesses both. Annex VIII Part II requires examination of the technical documentation and supporting evidence, plus examination of specimens of one or more critical parts of the product. The notified body must also carry out appropriate examinations and tests, or have them carried out. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II points 2 and 4.1-4.5 ## What exactly does the notified body check during module B? The notified body checks: - whether the technical documentation and supporting evidence are adequate - whether the examined specimens match the documentation - which elements were designed and developed using relevant harmonised standards or technical specifications and which were not - whether the manufacturer's chosen solutions satisfy the applicable essential cybersecurity requirements Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II points 4.1-4.4 ## Can module B tests be carried out at the manufacturer's site or elsewhere? Yes. Annex VIII Part II point 4.5 says the notified body and the manufacturer agree on the location where the examinations and tests will be carried out. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II point 4.5 ## What does the manufacturer receive if module B is successful? The manufacturer receives an EU-type examination certificate. The certificate identifies the approved type and the vulnerability-handling processes, and it records the conclusions of the examination and any validity conditions. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II point 6 ## What happens if the notified body concludes that the type does not comply? It must refuse to issue the EU-type examination certificate and give detailed reasons for the refusal. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II point 6 ## Does the EU-type examination certificate approve only the type, or also the manufacturer's vulnerability-handling processes? It covers both. Annex VIII Part II point 6 ties the certificate to both the approved type and the examined vulnerability-handling processes. That is why later modifications to either can matter for certificate validity. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II point 6 ## What does module C add after module B? Module C is the production-control step. After obtaining the EU-type examination certificate, the manufacturer must ensure and declare that the products actually manufactured remain in conformity with the approved type and continue to satisfy the essential cybersecurity requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part III points 1-2 ## Does module C mean the notified body supervises the production phase directly? Not in the way module H does. Under module C, the manufacturer itself must take the necessary measures so that production and its monitoring ensure conformity with the approved type. The Commission FAQ makes the same point: the manufacturer cannot rely on an approved design if actual production drifts into non-compliance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part III point 2 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.2 ## What must the manufacturer do under module C before placing products on the market? The manufacturer must: - ensure that production conforms to the approved type - affix the CE marking to each individual compliant product - draw up a written declaration of conformity for the product model Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part III points 2 and 3 ## Under module C, is the declaration of conformity for each individual product or for the product model? It is for the product model. Annex VIII Part III point 3.2 requires a written declaration of conformity for a product model. That differs from module A wording, which refers to each product with digital elements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part III point 3.2 ## Does the CE marking still have to go on each individual product under B+C? Yes. Even though the declaration under module C is for the product model, the CE marking must still be affixed to each individual product with digital elements that conforms to the approved type. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part III point 3.1 ## What happens if the approved type or vulnerability-handling processes change after certification? The manufacturer must inform the notified body that holds the technical documentation relating to the certificate of any modifications that may affect conformity or the conditions for validity of the certificate. Those modifications require additional approval in the form of an addition to the original EU-type examination certificate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II point 7 ## Is module B+C reassessment required only for "substantial modifications"? Not only for that label. Annex VIII Part II point 7 is framed more broadly: the trigger is any modification to the approved type or the vulnerability-handling processes that may affect conformity with Annex I or the conditions for validity of the certificate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II point 7 ## Does module B+C include surveillance after the certificate is issued? Yes, but it is limited. The notified body must carry out periodic audits to ensure that the vulnerability-handling processes in Part II of Annex I are implemented adequately. This is not the same as the broader quality-system surveillance under module H. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II point 8 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.2 ## Who gets informed about issued, refused, withdrawn, suspended, or restricted EU-type examination certificates? The notified body must inform its notifying authorities and the other notified bodies about those certificate outcomes. The Commission and Member States can also obtain copies of the certificates and, on request, copies of the technical documentation and examination results. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II point 9 ## How long must the manufacturer keep B+C records? The manufacturer must keep: - the EU-type examination certificate, its annexes and additions, together with the technical documentation - the declaration of conformity for the product model Those records must be kept at the disposal of national authorities for 10 years after the product is placed on the market or for the support period, whichever is longer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II point 10, Annex VIII Part III point 3.2 ## Can an authorised representative handle some module B+C steps? Yes, but only where the mandate expressly covers them. Under Annex VIII Part II point 11, the authorised representative may lodge the module B application and fulfil the obligations relating to modifications and record retention. Under Annex VIII Part III point 4, the authorised representative may fulfil the declaration obligations in module C. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II point 11, Annex VIII Part III point 4 ## Can important free-and-open-source software still use module B+C? Yes. Article 32(5) allows manufacturers of Annex III products qualifying as free and open-source software to use one of the procedures listed in Article 32(1), provided the technical documentation is made public at the time of placing on the market. That means they may use module A, but they may also choose module B+C. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1), Article 32(5) ## Do older EU-type certificates issued under other Union product laws automatically disappear on 11 December 2027? No. Article 69(1) provides a transition rule: EU-type examination certificates and approval decisions issued regarding cybersecurity requirements for products with digital elements under other Union harmonisation legislation remain valid until 11 June 2028, unless they expire earlier or that other legislation specifies otherwise. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.1 ## What usually makes a CRA module B+C file workable in practice? A workable file is one that lets the notified body trace the compliance claim, the supporting design choice, the evidence, and the tested specimen without gaps. Grounded in Annex VIII Part II and Annex VII, that usually means the application clearly identifies the applicable requirements, includes the risk analysis and assessment, explains any reliance on or departure from harmonised standards or technical specifications, and contains the supporting evidence and test results needed for the notified body's examination. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VII, Annex VIII Part II points 3 and 4 ## Does module B+C require the notified body's identification number next to the CE marking? No. Under Article 30(4), the CE marking is followed by the notified body's identification number only where that body is involved in the conformity assessment procedure based on module H. Under module B+C, the manufacturer still affixes the CE marking to each individual compliant product under module C, but the CRA does not require a notified-body number next to that marking. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(4), Annex VIII Part III point 3.1 ## In what language can module B+C technical documentation and correspondence be submitted to the notified body? They must be in an official language of the Member State where the notified body is established, or in another language acceptable to that body. That rule applies to the technical documentation and correspondence relating to any CRA conformity assessment procedure, including module B+C. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31(4) ## Does every change after certification have to go back to the notified body? No. The legal trigger in Annex VIII Part II point 7 is any modification to the approved type or the vulnerability-handling processes that may affect conformity with Annex I or the conditions for validity of the certificate. Those changes require additional approval from the notified body in the form of an addition to the original certificate. The Commission FAQ adds a practical split: substantial modifications require a new assessment by the same or a different notified body and may lead to revision of the certificate, while modifications that do not affect compliance with the CRA requirements are not subject to reassessment by the notified body. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II point 7 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.2 ## After a substantial modification, does the new module B+C assessment have to start from scratch for unchanged parts? Not necessarily. The March 2026 draft guidance says a substantially modified product is treated as a new product and is newly placed on the market. But it also says existing documentation and tests may be re-used for aspects not impacted by the substantial modification, and that where a third-party conformity assessment is performed it should focus on the substantially modified parts. The person placing the substantially modified product on the market still has to justify why unchanged parts can rely on the existing evidence. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 107-110 - [Blue Guide on the implementation of EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52022XC0629%2804%29&ref=sorena.io) - section 2.1 ## Do the periodic audits under module B+C cover the whole production system in the same way as module H? No. Under Annex VIII Part II point 8, the periodic audit duty is specifically to ensure that the vulnerability-handling processes in Part II of Annex I are implemented adequately. Module C separately leaves production conformity control to the manufacturer. So this is narrower than a module H full-quality-assurance assessment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part II point 8, Annex VIII Part III point 2 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.2 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Module B+C as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Module B+C into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Module B+C and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/module-b-c --- --- title: "CRA Module H FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/module-h" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/module-h" author: "Sorena AI" description: "CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA module H FAQ" - "CRA full quality assurance" - "CRA notified body surveillance" - "CRA quality system module H" - "CRA module H CE marking" - "CRA module H scope changes" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Module H FAQ CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Module H Use this CRA FAQ to understand the full-quality-assurance route under module H, what the approved quality system must cover, and how notified-body surveillance, scope extensions, and CE marking work. Built for certification, engineering, legal, and compliance teams using the CRA quality-system route. Module H is the CRA's full-quality-assurance route. This FAQ focuses on what the quality system must cover, what the notified body assesses and surveils, how scope changes are handled, and how CE marking, declarations, records, and language rules work under this procedure. ## What is module H under the CRA? Module H is the conformity-assessment procedure based on full quality assurance. Under this route, the manufacturer operates an approved quality system for design, development, final product inspection and testing, and vulnerability handling, and a notified body assesses and surveils that system. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1)(c), Annex VIII Part IV points 1-2 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.3 ## When can module H be used? Module H is available as one of the general Article 32(1) conformity-assessment procedures. It is also one of the mandatory third-party options for important products of class I where Article 32(2) requires third-party assessment, for important products of class II, and for critical products where the Article 8(1) certification route does not apply. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1)-(4) ## Can a manufacturer choose module H voluntarily? Yes. Where Article 32(1) applies, the manufacturer may choose module H instead of module A or module B+C. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.3 ## Does module H cover one product, a product category, or both? It can cover products with digital elements or product categories concerned by the approved quality system. That is one reason module H can be attractive for manufacturers with many products or frequent changes, provided the notified body approves the system and its scope. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV point 1 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.3 ## Does module H always involve a notified body? Yes. The quality system must be assessed by a notified body, and the manufacturer remains under notified-body surveillance after approval. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV points 3 and 4 ## What does the approved quality system have to cover? It must ensure compliance of the covered products with Part I of Annex I and compliance of the manufacturer's vulnerability-handling processes with Part II of Annex I. It must also cover the relevant lifecycle stages, including design, development, final product inspection and testing, and vulnerability handling, and it must remain effective throughout the support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV points 1, 2, and 3.2 ## What has to be submitted in a module H application? The application to the notified body must include: - the manufacturer details and, where relevant, the authorised representative's details - the technical documentation for one model of each category of products intended to be manufactured or developed - the quality-system documentation - a declaration that the same application has not been lodged with any other notified body Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV point 3.1 ## Does module H still require technical documentation? Yes. Module H does not replace the Article 31 and Annex VII documentation duties. The application must include technical documentation for one model of each covered product category, and the Commission FAQ notes that this documentation may form part of the quality-system documentation. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31, Annex VII, Annex VIII Part IV point 3.1(b) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.8 and 6.6 ## What has to be in the quality-system documentation? The quality-system documentation must systematically describe, among other things: - quality objectives and management responsibilities - the standards and specifications to be applied - the means used where relevant harmonised standards or technical specifications are not applied in full - design and development controls and verification techniques - production, quality-control, and quality-assurance techniques - examinations and tests and how often they are carried out - quality records - how the manufacturer monitors the effective operation of the quality system Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV point 3.2 ## Does module H distinguish between product requirements and vulnerability-handling process requirements? Yes. Annex VIII Part IV point 3.2 distinguishes between the technical design and development specifications relevant to Part I of Annex I and the procedural specifications relevant to Part II of Annex I. In practice, module H covers both product compliance and the manufacturer's vulnerability-handling processes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV point 3.2(b)-(d) ## How does the notified body assess a module H quality system? The notified body assesses whether the quality system satisfies the CRA requirements in Annex VIII Part IV point 3.2. The audit team must include at least one member experienced in the relevant product field and technology, and the audit must include an assessment visit to the manufacturer's premises where such premises exist. The auditing team also reviews the submitted technical documentation to verify the manufacturer's ability to identify the applicable CRA requirements and carry out the necessary examinations. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV point 3.3 ## Does compliance with a quality-management standard automatically satisfy module H? No. The CRA allows the notified body to presume conformity for elements of the quality system that comply with the corresponding specifications of the national standard implementing the relevant harmonised standard or technical specification. But the notified body still has to assess and approve the system under module H. The Commission FAQ also says that accreditation against the ISO 9000 series does not by itself entitle a manufacturer to use module H without CRA notified-body involvement. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV point 3.3 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.3 ## What happens if the CRA module H quality system is approved? The manufacturer must undertake to fulfil the obligations arising from the approved quality system and maintain it so that it remains adequate and efficient. The notified body's notification to the manufacturer must contain the conclusions of the audit and the reasoned assessment decision. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV points 3.3-3.4 ## What if the manufacturer wants to change the quality system? The manufacturer must keep the notified body informed of any intended change to the quality system. The notified body then evaluates the proposed changes and decides whether the modified system still satisfies the requirements or whether reassessment is necessary. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV point 3.5 ## Does module H help when a manufacturer has many product types or frequent updates? Often yes, but only within an approved quality-system framework. The Commission FAQ says module H may be particularly considered by manufacturers that place numerous product types on the market or products subject to frequent updates, because it provides a more versatile framework than module B+C. That does not remove the need for notified-body assessment of the system and later changes to it. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV point 3.5 ## What surveillance happens after module H approval? The notified body must carry out surveillance to make sure the manufacturer fulfils the obligations arising from the approved quality system. For that purpose, the manufacturer must allow access to the relevant design, development, production, inspection, testing, and storage sites and provide the quality-system documentation and quality records needed for assessment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV points 4.1-4.2 ## Are periodic audits part of module H surveillance? Yes. The notified body must carry out periodic audits to make sure the manufacturer maintains and applies the quality system, and it must provide the manufacturer with an audit report. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV point 4.3 ## Does module H replace the manufacturer's own responsibility for conformity? No. Even under module H, the manufacturer ensures and declares on its sole responsibility that the covered products or product categories satisfy the applicable requirements. The notified body assesses and surveils the quality system, but the manufacturer's legal responsibility remains. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV point 1 ## How is CE marking handled under module H? Under module H, the manufacturer affixes the CE marking to each individual compliant product and the notified body's identification number follows the CE marking. The identification number is affixed by the notified body itself or under its instructions. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(4), Annex VIII Part IV point 5.1 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.3 ## Under module H, is the declaration of conformity tied to each product or to the product model? It is tied to each product model. Annex VIII Part IV point 5.2 requires a written declaration of conformity for each product model, and the declaration must identify the product model for which it has been drawn up. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV point 5.2 ## What records must the manufacturer keep under module H, and for how long? The manufacturer must keep, at the disposal of national authorities, for at least 10 years after placing on the market or for the support period, whichever is longer: - the technical documentation - the quality-system documentation - approved changes to the quality system - the notified body's decisions and reports - the declaration of conformity for each product model Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV points 5.2 and 6 ## Who gets informed about quality-system approvals under module H? The notified body must inform its notifying authorities about quality-system approvals issued or withdrawn, and it must also inform other notified bodies about approvals it has refused, suspended, or withdrawn and, on request, about approvals it has issued. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV point 7 ## Can an authorised representative handle some module H obligations? Yes, but only where the mandate expressly covers them. Under Annex VIII Part IV point 8, the authorised representative may fulfil the manufacturer's obligations relating to the application, quality-system changes, declaration, and record-retention steps on the manufacturer's behalf and under the manufacturer's responsibility. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV point 8 ## Can important free-and-open-source software use module H? Yes. Article 32(5) allows manufacturers of Annex III products qualifying as free and open-source software to use one of the procedures in Article 32(1), provided that the technical documentation is made public at the time of placing on the market. That means module H remains available for those products. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(1), Article 32(5) ## Are CRA fee reductions for SMEs relevant to module H? Yes. Article 32(6) requires the specific interests and needs of microenterprises and small and medium-sized enterprises, including start-ups, to be taken into account when setting conformity-assessment fees, and those fees must be reduced proportionately. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(6) ## What usually makes a CRA module H system workable in practice? A workable module H system is one that lets the notified body see, in a consistent and documented way, how the manufacturer controls design, development, testing, production, vulnerability handling, and later changes across the approved scope. Grounded in Annex VIII Part IV, that usually means the quality-system documentation is specific enough to show who is responsible, which standards and specifications are used, how non-full use of them is handled, what examinations and tests are performed, what records are kept, and how the effectiveness of the system is monitored. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV points 3.2-4.3 ## Does module H issue an EU-type examination certificate like module B+C? No. Unlike module B+C, module H is not built around an EU-type examination certificate for a representative specimen. Under the CRA, module H is built around approval of the manufacturer's quality system, later decisions on changes to that system, and ongoing surveillance. That is why the retained records under Part IV are the quality-system documentation, approved changes, and notified-body decisions and reports, rather than an EU-type certificate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV points 3.3-4.3 and 6 - [Blue Guide on the implementation of EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52022XC0629%2804%29&ref=sorena.io) - section 5.1.6 ## Under module H, does the notified body perform the product risk-assessment, testing, and documentation work instead of the manufacturer? No. The notified body assesses and surveils the quality system, but the manufacturer still carries out the product-level compliance work within that system. The Commission FAQ says the manufacturer, based on the quality system, implements the necessary cybersecurity mitigation measures following the risk assessment, tests the product, draws up the technical documentation, and ensures that production of the different units does not alter compliance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV points 1-3.2 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.3 ## Can an approved module H system automatically cover any new or substantially modified product without further notified-body assessment? No. The Commission FAQ says the manufacturer can extend the scope of the quality system to new or substantially modified products, but the quality system must be updated to document the new scope, new standards may need to be applied, and new tests may need to be performed. That extension is subject to a new assessment by the same notified body that performed the original assessment. Annex VIII Part IV point 3.5 also requires the manufacturer to keep that notified body informed of intended changes to the quality system. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV point 3.5 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.3 ## In what language can module H technical documentation and correspondence be submitted to the notified body? They must be in an official language of the Member State where the notified body is established, or in another language acceptable to that body. That rule applies to technical documentation and correspondence for any CRA conformity assessment procedure, including module H. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31(4) ## If software uses module H, where does the notified body's identification number go? It follows the CE marking wherever the CRA allows that CE marking to be placed for software. For software products, Article 30(1) says the CE marking is affixed either to the EU declaration of conformity or on the website accompanying the software product. Article 30(4) then says that, where module H is used, the CE marking is followed by the notified body's identification number. So the CRA does not create a separate location rule for software under module H; the number follows the CE marking in the place where that marking is lawfully affixed. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(1) and (4) ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Module H as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Module H into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Module H and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/module-h --- --- title: "CRA Notified Bodies FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/notified-bodies" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/notified-bodies" author: "Sorena AI" description: "CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA notified bodies FAQ" - "CRA NANDO" - "CRA notified body scope" - "CRA accreditation notified body" - "CRA Article 39" - "CRA cross-border notified body" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Notified Bodies FAQ CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Notified Bodies Use this CRA FAQ to understand what notified bodies are, when they are needed, how their scope and competence are defined, and how manufacturers should assess a CRA notification listing. Built for certification, legal, compliance, and product teams selecting or reviewing CRA notified bodies. CRA notified bodies are central to the third-party conformity-assessment routes, but their role and scope are tightly defined. This FAQ focuses on notification, competence, independence, public listing, cross-border selection, scope limits, certificate handling, and how CRA rules interact with other Union notification frameworks. ## What is a notified body under the CRA? A notified body is a conformity assessment body that has been designated and notified under the CRA to carry out notified-body conformity assessment activities. The Commission assigns it an identification number and makes the list of notified bodies and their notified activities publicly available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(29), Article 43, Article 44 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.9 ## Is every conformity assessment body automatically a CRA notified body? No. A body becomes a notified body for CRA purposes only after it has been notified in accordance with Article 43 and the objection period has passed without objection. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 42, Article 43(5) ## When does a manufacturer need a notified body under the CRA? A notified body is needed where the applicable CRA route is module B+C or module H. That typically means important products of class I where Article 32(2) requires third-party assessment, important products of class II unless a qualifying certification route applies, and critical products where the Article 8(1) certification route does not apply. Module A does not involve a notified body. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(2)-(4), Annex VIII ## What does a notified body do under module B+C? Under module B, the notified body examines the product's technical design and development and the manufacturer's vulnerability-handling processes, reviews the technical documentation and supporting evidence, verifies specimens, and carries out or arranges the necessary examinations and tests. If the outcome is positive, it issues the EU-type examination certificate. Under module C, the manufacturer remains responsible for production conformity. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Parts II and III - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.2 ## What does a notified body do under module H? Under module H, the notified body assesses and approves the manufacturer's quality system, reviews technical documentation for representative models, and then surveils the approved quality system through periodic audits. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VIII Part IV points 3 and 4 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.3 ## Who designates and monitors CRA notified bodies? Each Member State designates a notifying authority for that purpose. The notifying authority is responsible for the assessment, designation, notification, and monitoring of conformity assessment bodies, including compliance with the CRA rules on subsidiaries and subcontracting. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 36(1) ## Can the notifying authority use a national accreditation body or another body? Yes, under conditions. Member States may decide that assessment and monitoring are carried out by a national accreditation body under Regulation (EC) No 765/2008. If the notifying authority delegates assessment, notification, or monitoring to a non-governmental body, that body must meet the CRA requirements applicable to notifying authorities and the notifying authority keeps full responsibility for the delegated tasks. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 36(2)-(4) ## What independence requirements apply to notifying authorities? They must be organised to avoid conflicts of interest and preserve objectivity and impartiality. The CRA also requires that decisions on notification are taken by competent persons different from those who carried out the assessment, and it prohibits the notifying authority from offering conformity-assessment activities or consultancy services on a commercial or competitive basis. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 37 ## What independence requirements apply to notified bodies themselves? They must be third-party bodies independent from the organisation and the product with digital elements they assess. They and their relevant personnel must not be the designer, developer, manufacturer, supplier, importer, distributor, installer, purchaser, owner, user, or maintainer of the assessed products, and they must not engage in activities that conflict with their independence of judgment or integrity. The CRA states expressly that this applies in particular to consultancy services. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 39(3)-(5) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.9 ## Can a body belonging to an industry association still qualify as a notified body? Possibly, yes. Article 39(3) allows a body belonging to a business association or professional federation to be treated as a third-party body if its independence and the absence of conflicts of interest are demonstrated. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 39(3) ## What competence and organisational capabilities must a notified body have? It must be capable of carrying out all the conformity-assessment tasks for which it is notified and must have the necessary personnel, procedures, means, equipment, and facilities. Its personnel must also have the required training, knowledge of the CRA requirements, harmonised standards and common specifications, and the ability to draw up certificates, records, and reports showing that assessments were carried out. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 39(6)-(7) ## Do notified bodies have to protect impartiality and confidentiality? Yes. The CRA requires impartiality, bans remuneration structures tied to assessment numbers or results, requires liability insurance unless public liability arrangements apply, and imposes professional secrecy obligations with documented procedures to protect confidential information. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 39(8)-(10) ## Must notified bodies participate in coordination and standardisation activities? Yes. They must participate in, or ensure their assessment personnel are informed of, the relevant standardisation activities and the work of the notified body coordination group established under Article 51, and they must use that group's administrative decisions and documents as general guidance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 39(11), Article 51 ## Does the CRA say anything about fee levels and SME burden? Yes. Notified bodies must operate on consistent, fair, proportionate, and reasonable terms and conditions while avoiding unnecessary burden for economic operators, taking particular account of the interests of microenterprises and SMEs in relation to fees. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 39(12) ## How can a conformity assessment body show it meets CRA notified-body requirements? One route is through relevant harmonised standards. Article 40 gives a presumption of conformity with Article 39 where the body demonstrates conformity with the relevant harmonised standards, insofar as those standards cover the applicable requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 40 ## Can a notified body use subcontractors or subsidiaries? Yes, but only under conditions. The notified body must ensure that the subcontractor or subsidiary meets the Article 39 requirements, inform the notifying authority, take full responsibility for the outsourced tasks, and obtain the manufacturer's agreement. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 41 ## What does a body have to submit when applying to become a notified body? It must submit an application to the notifying authority of the Member State where it is established. That application must include a description of the conformity-assessment activities, the procedures, and the products for which it claims competence and, where applicable, an accreditation certificate. If there is no accreditation certificate, the body must provide documentary evidence showing compliance with Article 39. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 42 ## When can a body start acting as a CRA notified body? Only after the Article 43 notification procedure is complete. If the notification is based on an accreditation certificate, the body may operate if no objection is raised within two weeks. If the notification is not based on accreditation, the no-objection period is two months. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 43(4)-(5) ## How are CRA notified bodies listed publicly? The Commission assigns each notified body a single identification number and publishes an up-to-date public list of notified bodies, their identification numbers, and the activities for which they have been notified. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 44 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.9 ## What happens if a notified body no longer meets the CRA requirements? The notifying authority must restrict, suspend, or withdraw the notification, depending on the seriousness of the problem. If the notification is restricted, suspended, or withdrawn, or the notified body stops activity, the notifying Member State must ensure that the body's files are either handled by another notified body or kept available for the responsible notifying and market-surveillance authorities. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 45 ## Can the Commission challenge the competence of a notified body? Yes. The Commission must investigate cases where it doubts, or is told to doubt, the competence of a notified body or its continued fulfilment of the applicable requirements. If the Commission concludes that the body no longer meets the requirements for notification, it requests corrective measures from the notifying Member State, including de-notification if necessary. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 46 ## What operational obligations apply once a body is already notified? It must carry out conformity assessments in accordance with Article 32 and Annex VIII, in a proportionate way that avoids unnecessary burden but still preserves the required degree of rigour and protection. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 47(1)-(3) ## What must a notified body do if it finds non-compliance before issuing a certificate? It must require appropriate corrective measures and must not issue the certificate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 47(4) ## What must a notified body do if it finds non-compliance after a certificate has already been issued? It must require corrective measures and, if necessary, suspend or withdraw the certificate. If corrective measures are not taken or do not have the required effect, it must restrict, suspend, or withdraw the certificate as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 47(5)-(6) ## Can a manufacturer appeal a notified body's decision? Yes. Member States must ensure that an appeal procedure against decisions of notified bodies is available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 48 ## What information must notified bodies share with notifying authorities? They must inform the notifying authority about refusals, restrictions, suspensions, or withdrawals of certificates, circumstances affecting the scope or conditions of notification, certain information requests from market-surveillance authorities, and, on request, information about their conformity-assessment activities, including cross-border activities and subcontracting. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 49(1) ## What information must notified bodies share with other notified bodies? They must provide other notified bodies carrying out similar conformity-assessment activities for the same products with relevant information on negative results and, on request, positive results. Annex VIII adds more specific certificate-sharing duties for module B and module H approvals. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 49(2), Annex VIII Part II point 9, Annex VIII Part IV point 7 ## What does the Commission do at system level for CRA notified bodies? The Commission must organise exchange of experience between national authorities responsible for notification policy and ensure appropriate coordination and cooperation between notified bodies through a cross-sectoral group of notified bodies. Member States must ensure that their notified bodies participate in that group, directly or through designated representatives. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 50, Article 51 ## Did the CRA's notified-body framework apply before the rest of the CRA? Yes. Chapter IV, which includes Articles 35 to 51 on notified bodies and notification, applies from 11 June 2026, even though most CRA obligations apply later. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 71(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.1 ## Can AI Act notified bodies also assess CRA cybersecurity requirements for certain high-risk AI systems? Yes, where the CRA's conditions are met. Article 12(2) says that notified bodies competent under the AI Act may also control conformity of high-risk AI systems falling within the CRA, provided their compliance with the CRA's Article 39 requirements has been assessed in the AI Act notification procedure. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 12(2) ## Does a manufacturer have to choose a CRA notified body from its own Member State? No. Where the CRA requires a notified body, the relevant procedures let the manufacturer apply to a single notified body of its choice. The CRA also states that notified bodies may offer their services throughout the Union. In practice, the key legal limit is not the manufacturer's location but whether the chosen body's notification covers the relevant CRA procedure and product scope. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 104, Annex VIII Part II point 3, Annex VIII Part IV point 3.1, Article 44 ## Does a body's presence on NANDO mean it can assess any CRA product or module? No. The CRA notification must specify the conformity-assessment activities, the module or modules, and the product or products with digital elements for which the body is competent. The public list likewise shows the activities for which the body has been notified. So a manufacturer should check that the body's CRA notification actually covers the relevant module and product scope. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 43(3), Article 44(2) ## Is accreditation mandatory for a body to become a CRA notified body? No. Accreditation is the preferred means of demonstrating competence, and an accreditation certificate can accompany the notification application. But the CRA also allows notification without accreditation if the body provides the documentary evidence needed to verify compliance with Article 39. In that case, the notifying authority must supply that evidence to the Commission and the other Member States, and the no-objection period is two months rather than two weeks. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recitals 99-101, Article 42(2)-(3), Article 43(4)-(5) ## If a body is already notified under another EU law with similar rules, does it automatically count as a CRA notified body? No. The CRA says bodies accredited and notified under other Union frameworks with similar requirements should still be newly assessed and notified under the CRA. Synergies may be used to avoid unnecessary burden where requirements overlap, but the body becomes a CRA notified body only once the CRA notification procedure is completed. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 100, Article 43(5) ## Does a notified body get a different identification number for each Union act? No. Article 44 says the Commission assigns a single identification number even where the body is notified under several Union legal acts. The Blue Guide adds that this NANDO number is an administrative identifier for managing the lists of notified bodies; it does not itself confer substantive rights or scope beyond the published notification. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 44(1) - [Blue Guide on the implementation of EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52022XC0629%2804%29&ref=sorena.io) - section 5.3.3 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Notified Bodies as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Notified Bodies into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Notified Bodies and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/notified-bodies --- --- title: "CRA Open-Source Software FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/open-source-software" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/open-source-software" author: "Sorena AI" description: "CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA open-source software FAQ" - "CRA FOSS" - "CRA commercial activity FOSS" - "CRA open-source steward" - "CRA paid support FOSS" - "CRA paid vs community edition" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Open-Source Software FAQ CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Open-Source Software Use this CRA FAQ to understand when free and open-source software falls within the CRA, how commercial activity is assessed, and how steward, contributor, and manufacturer roles differ. Built for open-source maintainers, legal teams, foundations, platform operators, and manufacturers integrating FOSS. The CRA gives free and open-source software special treatment, but not a blanket exemption. This FAQ focuses on when FOSS is in scope, how commercial activity is assessed, what makes someone a steward rather than a manufacturer, and how paid editions, donations, support models, and hosting platforms are treated. ## What counts as free and open-source software under the CRA? Under the CRA, free and open-source software means software whose source code is openly shared and which is made available under a licence that provides the rights to make it freely accessible, usable, modifiable, and redistributable. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(48), recital 18 ## Does the CRA apply to all open-source software? No. For the economic operators covered by the CRA, only free and open-source software made available on the market, meaning supplied for distribution or use on the Union market in the course of a commercial activity, falls under the full CRA product regime. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(22), recital 18 ## Does the open-source label itself keep software outside the CRA? No. Open-source status does not by itself decide the issue. The key CRA question is whether the software is supplied on the Union market in the course of a commercial activity. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(22), recital 18 ## What does "commercial activity" mean for open-source software under the CRA? The CRA does not reduce it to a single formal test. Recital 15 gives practical indicators. Commercial activity may be characterised not only by charging a price for the software itself, but also by charging for technical support where that does not merely recover actual costs, by an intention to monetise, by using the software to monetise other services, by requiring personal-data processing as a condition of use for reasons other than security, compatibility, or interoperability, or by accepting donations exceeding the costs associated with the software's design, development, and provision. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 15 ## If the software is open source but sold for a price, is it in scope? Yes, in principle. If the software is supplied on the Union market in the course of a commercial activity, open-source status does not prevent it from being treated as a product with digital elements under the CRA. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(22), recital 18 ## Can open-source software still be commercial even if the download is free? Yes. The CRA makes clear that commercial activity is not limited to charging a price for the software itself. It can also arise from monetisation of related services or from the other commercial indicators listed in recital 15. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 15 ## Do donations automatically make open-source software commercial? No. The CRA says that accepting donations without the intention of making a profit should not be considered a commercial activity. The March 2026 draft guidance adds that a FOSS project funded only through voluntary donations is unlikely to be treated as placed on the market where access to the software, source code, and updates is not conditioned on donating. But donations can still amount to commercial activity where, in practice, they function like the price of access, for example if releases, binaries, updates, or other essential benefits are available only to donors, or if the donation model is organised to generate systematic profit rather than sustain the project. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 15 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 3.2.4 ## Does outside funding or sponsorship automatically make an open-source project commercial? No. The CRA says that the circumstances in which the software was developed, and how its development was financed, should not by themselves determine whether the activity is commercial or non-commercial. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 18 ## Do regular releases or active maintenance automatically make an open-source project commercial? No. The CRA expressly says that the mere presence of regular releases should not in itself lead to the conclusion that free and open-source software is supplied in the course of a commercial activity. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 18 ## Do optional paid support services always make open-source software commercial? No. The March 2026 draft guidance says the decisive factor is whether access to the FOSS itself, including its maintenance and support, is conditioned on remuneration. If the FOSS can be downloaded and installed freely and users can separately buy consultancy or support, that does not by itself mean the FOSS is placed on the market. But where a specific edition or version is supplied only under a paid arrangement that includes support or performance optimisation, that provision is monetised and is treated as being placed on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 15, recital 18 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 3.2.3 ## What if the open-source software itself is not monetised by its manufacturer under the CRA? Then the CRA says that should not be treated as a commercial activity on that basis alone. Recital 18 states that products with digital elements qualifying as free and open-source software that are not monetised by their manufacturers should not be considered to involve a commercial activity. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 18 ## Does not-for-profit status automatically keep open-source software outside the CRA? Not automatically, but the CRA gives not-for-profit organisations a specific rule. For the purposes of the CRA, development and publication of free and open-source software by a not-for-profit organisation should not be considered a commercial activity if the organisation is set up so that all earnings after costs are used to achieve not-for-profit objectives. The March 2026 draft guidance adds that this can remain true even where the FOSS is directly monetised, for example through search-engine partnerships, as long as the organisation meets that not-for-profit condition. If such a legal person also meets the Article 3(14) criteria, it may be a steward rather than a manufacturer for that FOSS. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 18, Article 3(14) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - sections 3.2.6 and 3.3.1 ## Are contributors to an open-source project automatically subject to CRA obligations for that project? No. The CRA says it does not apply to natural or legal persons who contribute source code to free and open-source software that is not under their responsibility. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 18 ## If a free and open-source component is intended for integration into other products, is it automatically treated as being made available on the market? No. The CRA says a free and open-source software component intended for integration by other manufacturers is considered to be made available on the market only if that component is monetised by its original manufacturer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 18 ## Does hosting open-source code on GitHub, a package manager, or another public repository make it available on the market by itself? No. The CRA says the sole act of hosting products with digital elements on open repositories, including package managers or collaboration platforms, does not in itself constitute making them available on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 19 ## Are repository operators or package-manager providers distributors under the CRA just because they host code? No. Under recital 19, providers of repositories, package managers, and collaboration platforms are distributors only if they actually make the software available on the market, meaning they supply it for distribution or use on the Union market in the course of a commercial activity. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 19 ## What is an open-source software steward under the CRA? An open-source software steward is a legal person, other than a manufacturer, that systematically provides support on a sustained basis for the development of specific free and open-source software intended for commercial activities and ensures the viability of those products. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(14), recital 19 ## Can a natural person be an open-source software steward? No. The Article 3(14) definition is limited to a legal person. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(14) ## Does every legal person supporting an open-source project become a steward? No. Steward status is narrower. The legal person must systematically provide support on a sustained basis, the software must be intended for commercial activities, and the legal person must ensure the software's viability. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(14), recital 19 ## What kinds of support can count toward CRA open-source software steward status? The CRA gives broad examples. Recital 19 says that sustained support may include hosting and managing software-development collaboration platforms, hosting source code or software, governing or managing free and open-source software products, and steering their development. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 19 ## Can the same organisation be a manufacturer for one open-source product and a steward for another? Yes. The March 2026 draft guidance says this assessment is specific to each FOSS product. A legal person may be the manufacturer for a specific FOSS that it places on the market, while being the steward for another specific FOSS that it publishes without placing on the market. The same split can also arise between a monetised version and a free or community version of related software. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(13), Article 3(14), recital 19 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - sections 3.3 and 3.3.1 ## What obligations do open-source software stewards have under the CRA? They have a lighter, tailored regime under Article 24. Stewards must put in place and document, in a verifiable manner, a cybersecurity policy that fosters secure development, effective vulnerability handling, voluntary reporting of vulnerabilities, and sharing of vulnerability information within the open-source community. They must also cooperate with market-surveillance authorities and, on a reasoned request, provide the documented policy to the authority. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 24(1)-(2) ## Do open-source software stewards have any CRA reporting obligations? Yes, but only to the limited extent set out in Article 24(3). Article 14(1) applies to stewards only to the extent that they are involved in development of the products. Article 14(3) and 14(8) apply only to the extent that severe incidents affect network and information systems provided by the steward for the development of those products. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 24(3) ## Can an open-source software steward affix the CE marking? No. Recital 19 makes clear that open-source software stewards should not be permitted to affix the CE marking to the products whose development they support. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 19 ## Are stewards subject to market surveillance? Yes. The market-surveillance authorities designated under Article 52 are also responsible for activities relating to steward obligations under Article 24. If a steward does not comply, the authority must require appropriate corrective action. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 52(3) ## Are open-source software stewards exposed to CRA administrative fines? Not to the administrative fines referred to in Article 64(3) to (9). Article 64(10)(b) expressly says those administrative fines do not apply to infringements of the Regulation by open-source software stewards. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(10)(b) ## If a manufacturer integrates non-commercial open-source components into its own product, what does the CRA require? The manufacturer still has due-diligence obligations for its own product. Article 13(5) requires manufacturers to exercise due diligence when integrating third-party components, including free and open-source software components that have not been made available on the market in the course of a commercial activity, so those components do not compromise the cybersecurity of the final product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(5), recital 34 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.4.4 ## If a manufacturer finds a vulnerability in an integrated open-source component, what must it do? It must report the vulnerability upstream and remediate it in its own product. Article 13(6) says that where manufacturers identify a vulnerability in an integrated component, including an open-source component, they must report it to the person or entity manufacturing or maintaining the component, address and remediate it in accordance with the CRA vulnerability-handling requirements, and share the relevant fix or documentation where appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), recital 34 ## Does open-source status reduce the manufacturer's CRA obligations if the software is actually placed on the market? No, not in general. If a manufacturer places open-source software on the market in the course of a commercial activity, the ordinary CRA manufacturer regime applies to that product. The main special rule is Article 32(5), which preserves access to the Article 32(1) conformity-assessment procedures for Annex III products qualifying as free and open-source software if the technical documentation is made public at the time of placing on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 18, Article 32(5) ## Can manufacturers of important open-source products use internal control instead of a third-party conformity assessment? In one specific case, yes. Article 32(5) allows manufacturers of Annex III products qualifying as free and open-source software to use one of the Article 32(1) procedures, including module A, provided the technical documentation referred to in Article 31 is made available to the public at the time of placing on the market. The Commission FAQ explains this as preserving the possibility of module A for important class I and class II free and open-source software when that public-documentation condition is met. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(5) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 6.1 and 6.6 ## Does the CRA provide for voluntary security attestation programmes for open-source software? Yes. Article 25 empowers the Commission to establish voluntary security attestation programmes for free and open-source software, in particular to facilitate the due-diligence obligation for manufacturers integrating such components. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 25 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.4.4 ## When do the CRA open-source software steward rules start to apply? The timing is split. Article 24(3), because it links to Article 14 reporting obligations, becomes relevant from 11 September 2026 when Article 14 starts to apply. The rest of the Regulation, including the main Article 24 obligations, applies from 11 December 2027. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 24(3), Article 71(2) ## Is software still "free and open-source software" for CRA purposes if the source code is shared only with paying customers or a limited group of users? No. Article 3(48) requires both a qualifying free and open-source licence and that the source code be openly shared. The March 2026 draft guidance says "openly shared" means publicly available, not merely shared on a restricted or conditional basis. So software whose source code is available only to paying customers or a limited user group is not FOSS within the CRA's definition. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(48), recital 18 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 41-43 ## Who is considered responsible for a FOSS project under the CRA: contributors or maintainers? Responsibility lies with those who publish the FOSS and exercise primary control over its development, releases, and distribution decisions. The March 2026 draft guidance says contributors who merely submit code are not responsible on that basis alone, even if they have technical permissions such as commit access. Responsibility is tied to publishing and control over releases, roadmaps, or governance decisions. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 18 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 45-46 ## Does the CRA treat a paid edition and a free or community edition of the same FOSS as the same product? No. The March 2026 draft guidance says that a monetised version and a free or community version should be treated as different products for CRA purposes. The paid version is placed on the market if it is monetised. The free or community version is not placed on the market on that basis alone. If the publisher is a legal person, that same entity may still be the steward for the free or community version if the steward conditions are met. If the publisher is a natural person, the free or community version may instead fall outside the CRA. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 49-50 and 69-74 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(14) ## Can a natural person charge only to recover actual costs and still stay outside the CRA product regime? Yes, potentially. The March 2026 draft guidance says that, particularly for natural persons publishing FOSS, bundled support does not by itself amount to commercial activity where the price serves only to recover actual costs. It adds that those actual costs can include design, development, and maintenance costs, including reasonable living expenses and fair remuneration for the person. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 15 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 55 ## Does a consultant or service provider place a FOSS on the market just by helping customers install or support it? No, not on that basis alone. The March 2026 draft guidance says a person offering technical support services for a FOSS that is not under its responsibility is not deemed to be placing that FOSS on the market, unless it substantially modifies the FOSS as part of delivering those services. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 22 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 56 ## Does a foundation or collaboration platform become a steward for every FOSS project it hosts? No. The March 2026 draft guidance says steward status is assessed project by project. A foundation can be a steward for specific FOSS intended for commercial activities where it provides sustained support and ensures viability. But merely hosting other FOSS projects, without systematic support, a viability role, or software intended for commercial activities, does not make it the steward for those other projects. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(14), recital 19 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 75-76 ## Do all stewards have the same CRA reporting duties regardless of the kind of support they provide? No. All stewards must comply with the policy and cooperation duties in Article 24(1) and (2). But the March 2026 draft guidance explains that the Article 24(3) reporting duties vary with the kind of support provided. A steward that only provides non-technical support is not, on that basis alone, required to report actively exploited vulnerabilities or severe incidents. A steward that provides development infrastructure may need to notify severe incidents affecting those systems. A steward that also provides engineering resources may need to notify actively exploited vulnerabilities that it becomes aware of and, where appropriate, inform users. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 24(1)-(3), Article 15 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 76-79 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Open-Source Software as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Open-Source Software into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Open-Source Software and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/open-source-software --- --- title: "CRA Over-the-Air Updates FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates" author: "Sorena AI" description: "CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA OTA updates FAQ" - "CRA automatic security updates" - "CRA secure update distribution" - "CRA offline update path" - "CRA OTA reporting incident" - "CRA screenless device updates" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" - "CRA over-the-air updates FAQ" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Over-the-Air Updates FAQ CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Over-the-Air Updates Use this CRA FAQ to understand how OTA updates fit into the CRA, when automatic security updates must be enabled by default, and how secure update distribution can also work through gateways, companion apps, or offline paths. Built for product, firmware, IoT, mobile, and compliance teams designing update delivery and rollout mechanisms under the CRA. The CRA does not create a separate OTA legal regime, but OTA delivery is one common way to satisfy the Regulation's secure update-distribution requirements. This FAQ explains how OTA relates to automatic security updates, what secure distribution requires, how screenless or intermittently connected products can comply, and when OTA infrastructure failures can trigger CRA reporting duties. ## Does the CRA use or define the term "over-the-air update"? No. The CRA speaks about security updates, automatic security updates where applicable, and mechanisms to securely distribute updates. It does not create a separate legal definition of "over-the-air" or "OTA". The ETSI smart-device standards in the local CRA corpus do use the term OTA for updates delivered over a network interface. So, in CRA practice, OTA is best understood as one possible way to implement the CRA's update obligations, not as a separate legal category. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(c), Annex I Part II point (7) - [ETSI TS 103 927 V1.1.1](https://www.etsi.org/deliver/etsi_ts/103900_103999/103927/01.01.01_60/ts_103927v010101p.pdf?ref=sorena.io) - term "OTA" ## Does the CRA require OTA update capability for every product with digital elements? No express OTA mandate appears in the CRA. What the CRA requires is that vulnerabilities can be addressed through security updates and that the manufacturer provides mechanisms to securely distribute updates. It also requires automatic security updates only where applicable. That means OTA is one potentially compliant implementation route, rather than a universally mandated delivery channel. This is an inference from the CRA's functional wording. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(c), Annex I Part II points (2), (7), and (8), recital 56 ## Is an OTA update the same thing as an automatic security update? No. OTA describes how the update is delivered, typically over a network. Automatic update describes how the update is installed or applied. A product can receive updates OTA but still require user approval before installation. Conversely, the CRA's legal trigger for default enablement is not "OTA" but "automatic security updates" where applicable. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(c), Annex I Part II point (7), recital 56 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 - [ETSI TS 103 927 V1.1.1](https://www.etsi.org/deliver/etsi_ts/103900_103999/103927/01.01.01_60/ts_103927v010101p.pdf?ref=sorena.io) - term "OTA" ## If a product uses automatic OTA security updates, must they be enabled by default and user-controllable? Yes, where automatic security updates are applicable. Annex I Part I point (2)(c) requires automatic security updates, where applicable, to be enabled as a default setting, with a clear and easy-to-use opt-out mechanism, notification of available updates to users, and the option to temporarily postpone them. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(c), Annex II point 8(e), recital 56 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## Does the CRA require completely silent OTA installation with no final user approval step? No. Recital 56 says manufacturers should also provide the possibility to approve the download and installation of security updates as a final step. So even where automatic updates are used, the CRA materials do not point toward an unconditional "silent install only" model. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 56 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## Are automatic OTA updates expected for all product categories? No. Recital 56 says the automatic-update expectations do not apply to products primarily intended to be integrated as components into other products. It also says they do not apply to products for which users would not reasonably expect automatic updates, including products used in professional ICT networks and especially in critical and industrial environments where automatic updates could interfere with operations. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(c), recital 56 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## If a product has no screen, can CRA update notices or approval be handled through a paired app or companion device? Potentially, yes. The CRA requires notification of available updates to users and clear user information, but it does not prescribe one specific interface. ETSI TS 103 927 gives a concrete example for a screenless smart voice-controlled device: a paired phone or app can be used to notify the user about security updates, obtain consent, and display update-related information. That means a paired app is one potentially compliant implementation pattern for screenless products. This is an inference from the CRA's interface-neutral wording together with the ETSI example. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(c), Article 13(18), Annex II point 8(c)-(e) - [ETSI TS 103 927 V1.1.1](https://www.etsi.org/deliver/etsi_ts/103900_103999/103927/01.01.01_60/ts_103927v010101p.pdf?ref=sorena.io) - Example 2 in update-related provisions ## If a product uses OTA updates, what does the CRA require from the security of that mechanism? The CRA requires the OTA path to be secure enough to distribute updates so vulnerabilities are fixed or mitigated in a timely manner. It does not prescribe one single technical architecture, but it does require secure update-distribution mechanisms. Read together with the CRA's requirements to protect commands, programs and configuration against unauthorised manipulation, the OTA channel and package handling cannot be left unsecured. The ETSI standards in the local corpus make this more concrete for OTA implementations by pointing to secure channels and authenticity and integrity verification of updates. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(f), Annex I Part II point (7) - [ETSI TS 103 645 V2.1.2](https://www.etsi.org/deliver/etsi_ts/103600_103699/103645/02.01.02_60/ts_103645v020102p.pdf?ref=sorena.io) - provisions 5.3-9 and 5.3-10 - [ETSI TS 103 927 V1.1.1](https://www.etsi.org/deliver/etsi_ts/103900_103999/103927/01.01.01_60/ts_103927v010101p.pdf?ref=sorena.io) - provisions SVD 5.3-7 and SVD 5.3-9 ## Does the CRA allow an OTA release to bundle a security fix with a feature change? Only where separation is not technically feasible. The CRA's rule does not change just because the update is delivered OTA. Where technically feasible, new security updates must be provided separately from functionality updates. The Commission FAQ explains that bundling can still be acceptable where the security fix itself necessarily changes functionality. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (2), recital 57 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.5 ## Can an OTA security update itself amount to a substantial modification? Sometimes, but not usually. The March 2026 draft guidance says security updates are generally not substantial modifications where their purpose is to reduce cybersecurity risk and they do not change the product's intended purpose or introduce new cybersecurity risks. But a security-driven update can still become a substantial modification if it changes the intended purpose beyond what was foreseen or introduces new dependencies, new interfaces, or other new risks not covered by the original risk assessment. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 101-106 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 39, Article 3(30) ## For products placed on the market before 11 December 2027, do later OTA updates automatically bring those products into the full CRA regime? No. For legacy products, the question is whether the later update amounts to a substantial modification. The March 2026 draft guidance says security updates are generally not substantial modifications, and Article 69(2) makes substantial modification the trigger for bringing pre-11 December 2027 products into the CRA's full product regime. The same draft guidance also says manufacturers should be able to demonstrate, if asked, that later updates do not amount to substantial modifications. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2), recital 39 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 101, 106, and 112 ## Is the manufacturer responsible under the CRA if a user refuses an OTA update or leaves the device unupdated? No, not for the user's refusal or opt-out. The manufacturer must design the product and its processes so that security updates can be notified, distributed, and installed as required. But the Commission FAQ says the manufacturer is not responsible under the CRA if the user does not install the update, including where the user opts out of automatic updates. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 6, Annex I Part I point (2)(c), Annex I Part II points (7) and (8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## Must OTA security updates be free of charge and accompanied by user-facing messages? Yes, unless the tailor-made exception applies. The CRA requires security updates addressing identified security issues to be disseminated without delay and free of charge, unless otherwise agreed for a tailor-made product with a business user. It also requires advisory messages with the relevant information, including on potential action users should take. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (8), recital 64 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.2.5 and 4.3.3 ## Once an OTA security update has been released, must it remain available later? Yes. Article 13(9) applies to each security update made available during the support period. It must remain available for at least 10 years after issuance or for the remainder of the support period, whichever is longer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(9) ## Can a manufacturer stop patching older OTA software branches once users can move to the latest version? Sometimes. Article 13(10) allows the manufacturer, under strict conditions, to ensure compliance with the remediation obligation only for the latest substantially modified version it has placed on the market. That is allowed only if users of earlier versions can access the latest version free of charge and without additional costs to adjust their hardware or software environment. So an OTA upgrade path can support that approach, but only if those Article 13(10) conditions are actually met. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(10), recital 40 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 118-120 ## If an OTA update cannot adequately fix the vulnerability or restore conformity, can the CRA require withdrawal or recall? Yes, in exceptional cases. The CRA does not assume that every vulnerability can always be solved through an OTA patch. If the product or the manufacturer's processes are not in conformity and the necessary corrective measures cannot adequately bring the product back into conformity, Article 13(21) allows the consequence to be withdrawal or recall, as appropriate. The Commission FAQ makes the same point expressly: in exceptional cases, particularly for hardware products, a vulnerability may present such a significant risk of compromise that it cannot be adequately addressed and remediated, in which case withdrawal or recall may be required. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ## Can compromise of the OTA release channel itself trigger CRA reporting obligations? Yes. Recital 68 gives a direct example of a severe incident having an impact on the security of the product: an attacker successfully introducing malicious code into the release channel via which the manufacturer releases security updates to users. Once the manufacturer becomes aware of such an incident, Article 14 reporting and user-information duties become relevant. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 68, Article 14(3), Article 14(8) ## Are OTA backends, CI/CD pipelines, or update-distribution systems automatically part of the CRA product or its remote data processing solution? Not necessarily. The March 2026 draft guidance says the CRA is not intended to treat the manufacturer's whole IT infrastructure as part of the product. It gives examples including CI/CD pipelines and the distribution of security updates to edge locations as systems that should not be considered RDPS. But that does not make them irrelevant, and it does not transfer the manufacturer's CRA responsibilities away from the manufacturer. The same draft guidance says manufacturers must apply risk-based security measures and due diligence when relying on third-party cloud service providers. The draft guidance and the CRA's incident rules also show that compromise of those systems can still matter for the product's cybersecurity risk profile and can amount to a reportable severe incident where the security of the product is affected. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 162, 166, and 192 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (7), recital 68, Article 14(3) ## Can a locally delivered update path such as USB or a web-upload mechanism satisfy the CRA instead of OTA? Potentially, yes. The CRA requires that vulnerabilities can be addressed through security updates and that manufacturers provide mechanisms to securely distribute updates. It does not say that every compliant update path has to be wireless, cloud-delivered, or continuously remote. The ETSI materials in the local CRA corpus make that practical point explicit. ETSI EN 303 645 says update mechanisms can range from direct download from a remote server to delivery via a mobile application or transfer over a USB or other physical interface. ETSI TR 103 621 gives concrete examples of signed updates delivered from a manufacturer-prepared USB stick and of constrained devices accepting firmware uploaded through a user interface after signature verification. So OTA is one compliant implementation pattern, not the only one. This is an inference from the CRA's functional wording together with the ETSI examples. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(c), Annex I Part II point (7) - [ETSI EN 303 645 V3.1.3](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf?ref=sorena.io) - provisions 5.3-2 and 5.3-3 - [ETSI TR 103 621 V2.1.1](https://www.etsi.org/deliver/etsi_tr/103600_103699/103621/02.01.01_60/tr_103621v020101p.pdf?ref=sorena.io) - sections 6.10 Example 2, 6.11 Example 3, and 6.15 Example 3 ## Can a gateway, controller, companion app, or associated service handle update checks or validation on behalf of the device? Potentially, yes. The CRA does not say that each individual device must itself poll update servers or personally validate every update package. What it requires is that vulnerabilities can be addressed through security updates and that update-distribution mechanisms are secure. ETSI EN 303 645 says that, for some products, it can be more appropriate for an associated service rather than the device itself to check whether security updates are available. The same ETSI material also explains that, where updates are delivered over a network interface, authenticity and integrity can be verified through a trust relationship, and that for constrained devices verification can be performed by another trusted device. ETSI TR 103 621 gives a concrete example of a smart home controller that validates update signatures and then transmits the trusted update to sensors and actuators over a trustworthy channel. So gateway- or app-mediated update handling can fit the CRA, provided the trust model and security controls are robust enough. This is an inference from the CRA's functional wording together with the ETSI examples. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(c), Annex I Part II point (7) - [ETSI EN 303 645 V3.1.3](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf?ref=sorena.io) - provisions 5.3-5 and 5.3-10 - [ETSI TR 103 621 V2.1.1](https://www.etsi.org/deliver/etsi_tr/103600_103699/103621/02.01.01_60/tr_103621v020101p.pdf?ref=sorena.io) - sections 6.13 Example 3 and 6.18 Example 4 ## Does the CRA require default automatic installation for functionality updates too? No. The CRA's default-enable, opt-out, notification, and postponement rule is about automatic security updates where applicable. Separately, Annex I Part II point (2) says new security updates should, where technically feasible, be provided separately from functionality updates. So the CRA does not create a general rule that feature or functionality changes must be installed automatically by default. If a functionality change is itself necessary to deliver the security fix, bundling may still be allowed, but that does not turn functionality updates as a category into mandatory default automatic updates. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(c), Annex I Part II point (2), recital 57 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.3 and 4.3.5 ## Can CRA automatic security updates be postponed until a suitable maintenance window or unmetered network? Yes. Annex I Part I point (2)(c) expressly requires the option to temporarily postpone automatic security updates where automatic security updates are applicable. The CRA therefore does not require every automatic update to install at the first possible moment regardless of operational context. The ETSI guidance in the local CRA corpus gives practical examples of this, including user-defined installation times and postponing download and installation until the product is connected to an unmetered network, while still allowing an override for security updates. That does not remove the CRA's requirement that updates be disseminated without delay and that vulnerabilities be fixed or mitigated in a timely manner. It means the update flow can still accommodate controlled postponement. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(c), Annex I Part II points (7) and (8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 - [ETSI TR 103 621 V2.1.1](https://www.etsi.org/deliver/etsi_tr/103600_103699/103621/02.01.01_60/tr_103621v020101p.pdf?ref=sorena.io) - sections 6.12A Example 1, 6.12B Example 2, and 6.14A Example 3 ## Must the manufacturer document how its OTA or other update-distribution mechanism is secured? Yes. The CRA technical-documentation rules do not treat secure update distribution as just an operational detail. Annex VII requires the technical documentation to include the necessary information and specifications of the manufacturer's vulnerability-handling processes, including a description of the technical solutions chosen for the secure distribution of updates. So the manufacturer needs more than a working update channel. It also needs documentation showing what secure update-distribution approach it chose for the product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31(1), Annex VII point 2(b) ## Is using TLS or another protected transport channel by itself enough to make an OTA or update mechanism "secure"? Not automatically. The CRA itself speaks at a higher level and requires mechanisms to securely distribute updates. The ETSI materials in the local CRA corpus make clear that protected transport can be one valid part of the trust model, but that secure update handling is about the overall mechanism resisting misuse and ensuring appropriate authenticity and integrity for the use case. ETSI EN 303 645 explains that valid trust relationships can include authenticated communication channels, but it also points to verifying authenticity and integrity of updates and to anti-rollback measures. ETSI TS 103 701 says secure update mechanisms need security guarantees appropriate to the use case and that at least integrity and authenticity are required. ETSI TR 103 621 gives an example using TLS plus mutual authentication and digitally signed, versioned firmware packages. So a protected channel may be part of a compliant design, but it is not a shortcut that removes the need to ensure the update itself is trusted and protected against misuse. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (7) - [ETSI EN 303 645 V3.1.3](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf?ref=sorena.io) - provisions 5.3-2, 5.3-7, 5.3-9, and 5.3-10 - [ETSI TS 103 701 V1.1.1](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/01.01.01_60/ts_103701v010101p.pdf?ref=sorena.io) - test group 5.3-7 - [ETSI TR 103 621 V2.1.1](https://www.etsi.org/deliver/etsi_tr/103600_103699/103621/02.01.01_60/tr_103621v020101p.pdf?ref=sorena.io) - sections 6.10 Example 1 and 6.18 Example 1 ## Can a product that is mostly offline or only intermittently connected still comply with the CRA's update obligations? Potentially, yes. The CRA does not say that a product must be permanently online. It requires that vulnerabilities can be addressed through security updates and that manufacturers provide mechanisms to securely distribute those updates. The ETSI examples in the local CRA corpus show several models that fit that basic pattern: a smart kitchen appliance that can be initialized and used offline and checks for updates when first connected; a limited-bandwidth device that is securely updated via a manufacturer-prepared USB stick; and a smart tracker that only downloads updates when in range of a paired mobile device. So intermittent connectivity does not by itself make a product non-compliant, provided the manufacturer still ensures an update path that is secure and suitable to timely remediation. This is an inference from the CRA's functional wording together with the ETSI examples. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(c), Annex I Part II points (7) and (8) - [ETSI TR 103 621 V2.1.1](https://www.etsi.org/deliver/etsi_tr/103600_103699/103621/02.01.01_60/tr_103621v020101p.pdf?ref=sorena.io) - sections 8.2.4A Example 2, 8.2.5 Example 1, and 8.2.6A Example 2 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Over-the-Air Updates as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Over-the-Air Updates into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Over-the-Air Updates and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates --- --- title: "CRA Penalties and Fines FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines" author: "Sorena AI" description: "CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA penalties and fines FAQ" - "CRA Article 64" - "CRA turnover fine cap" - "CRA SME reporting carve-out" - "CRA steward fine exemption" - "CRA penalties revenues" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Penalties and Fines FAQ CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Penalties and Fines Use this CRA FAQ to understand the Article 64 fine tiers, how turnover-based caps work, what SME and steward carve-outs exist, and how fines relate to other enforcement measures. Built for legal, compliance, executive, and regulatory teams assessing CRA enforcement exposure. The CRA sets EU-level fine categories and maximum ceilings, but Member States still implement the detailed penalty system in national law. This FAQ focuses on Article 64 fine tiers, turnover-based caps, SME and steward carve-outs, cumulative fines, non-undertaking cases, and how fines interact with other CRA enforcement measures. ## Does the CRA itself provide for penalties, or does it leave penalties entirely to Member States? It does both. Article 64 requires each Member State to lay down and enforce penalty rules, but the CRA itself also fixes the main administrative-fine categories and maximum ceilings. National law still determines the detailed enforcement setup, provided the penalties are effective, proportionate, and dissuasive. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(1) to (4) ## Are CRA penalties fully harmonised across the EU? No. The CRA harmonises the main fine tiers and maximum caps, but not every procedural and institutional detail. Member States still decide how penalties are implemented in national law, who imposes them, and whether public bodies can be fined. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(1), Article 64(7), Article 64(8) ## What is the highest CRA fine tier? The highest fine tier applies to: - non-compliance with the essential cybersecurity requirements in Annex I - non-compliance with the obligations in Articles 13 and 14 The maximum is EUR 15,000,000 or, if the offender is an undertaking, 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(2) ## What does the middle CRA fine tier cover? The middle tier covers a broad set of obligations for economic operators, conformity assessment, notified bodies, and authority access. Article 64(3) lists the relevant provisions directly, including Articles 18 to 23, Article 28, Article 30(1) to (4), Article 31(1) to (4), Article 32(1) to (3), Article 33(5), and Articles 39, 41, 47, 49 and 53. The maximum is EUR 10,000,000 or, if the offender is an undertaking, 2% of total worldwide annual turnover for the preceding financial year, whichever is higher. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(3) ## What CRA fine applies for incorrect, incomplete, or misleading information? Supplying incorrect, incomplete, or misleading information in reply to a request from a notified body or a market-surveillance authority can lead to fines of up to EUR 5,000,000 or, if the offender is an undertaking, 1% of total worldwide annual turnover for the preceding financial year, whichever is higher. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(4) ## Does the CRA set the exact fine amount automatically? No. The CRA sets maximum ceilings, not automatic penalty amounts. The final amount in an individual case depends on the national system and the case-specific factors in Article 64(5). Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(5) ## What factors affect the amount of a CRA fine in a specific case? Article 64(5) says authorities must take all relevant circumstances into account and give due regard at least to: - the nature, gravity, duration, and consequences of the infringement - whether similar fines have already been applied by the same or other market-surveillance authorities to the same operator - the size and market share of the operator, including whether it is a microenterprise, SME, or start-up Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(5) ## Can several Member States fine the same operator for the same type of CRA infringement? Potentially yes, but not without limits. Article 64(5)(b) requires authorities to take earlier fines by the same or other market-surveillance authorities into account, and Article 64(6) requires authorities that apply fines to communicate that through the Union information system. Recital 120 adds that cumulative fines across several Member States for the same type of infringement must still respect proportionality. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(5)(b), Article 64(6), Recital 120 ## Are microenterprises and small enterprises exempt from all CRA fines? No. The derogation is narrow. As corrected by the 2 July 2025 corrigendum, Article 64(10)(a) removes the Article 64(2) to (9) administrative-fine regime only for manufacturers that qualify as microenterprises or small enterprises, and only with regard to a failure to meet the 24-hour deadline in Article 14(2)(a) or Article 14(4)(a). That is not a general exemption from CRA penalties or from other CRA obligations. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(2)(a), Article 14(4)(a), Article 64(10)(a) ## Can Member States still impose some other pecuniary penalty on those exempt small manufacturers for that reporting-delay breach? The CRA recital points the other way. Recital 120 says that, given the Article 64 carve-out for microenterprises and small enterprises for that 24-hour reporting deadline failure, Member States should not impose other kinds of penalties with pecuniary character on those entities for that situation. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Recital 120 ## Are open-source software stewards exposed to CRA administrative fines? No, not under the Article 64 administrative-fine regime. As corrected by the 2 July 2025 corrigendum, Article 64(10)(b) removes the administrative fines referred to in Article 64(2) to (9) for infringements of the CRA by open-source software stewards. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(10)(b) ## Does that mean open-source software stewards are outside CRA enforcement altogether? No. Article 52(3) still makes market-surveillance authorities responsible for supervising steward obligations under Article 24 and for requiring corrective action where a steward does not comply. Recital 120 also says Member States should not replace the exempted administrative fines with other pecuniary penalties for stewards. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 24, Article 52(3), Recital 120, Article 64(10)(b) ## Can public authorities or public bodies be fined under the CRA? That depends on national law. Article 64(7) says each Member State must decide whether, and to what extent, administrative fines may be imposed on public authorities and public bodies established in that Member State. Recital 121 points the same way. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(7), Recital 121 ## Do CRA fines have to be imposed by administrative authorities, or can courts be involved? Either can be involved. Article 64(8) says Member States may structure the system so fines are imposed by competent national courts or by other bodies, as long as the national system has equivalent effect. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(8) ## Can importers, distributors, authorised representatives, and notified bodies also be fined, or only manufacturers? They can also be exposed. Article 64(3) covers many obligations that apply beyond the manufacturer, including importer, distributor, authorised-representative, and notified-body obligations. The real question is not the actor's label but which CRA obligation that actor has breached. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 18 to Article 23, Article 39, Article 41, Article 47, Article 49, Article 64(3) ## Can CRA fines be imposed in addition to recalls, withdrawals, or other corrective measures? Yes. Article 64(9) expressly says administrative fines may be imposed in addition to other corrective or restrictive measures for the same infringement. In practice, that means a product can face recall, withdrawal, restrictions, or other corrective action as well as a fine. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 54 to Article 58, Article 64(9) ## When can CRA penalties and fine exposure begin in practice? It follows the CRA's staggered application dates. The CRA generally applies from 11 December 2027. However, Article 14 applies earlier, from 11 September 2026, and Chapter IV on notified bodies applies from 11 June 2026. Penalty exposure follows the obligations that are already applicable. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 71(2) ## Are fines the only CRA consequence of non-compliance? No. Beyond fines, the CRA also allows corrective and restrictive market-surveillance measures and applies the EU representative-actions regime to qualifying consumer cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 54 to Article 58, Article 65 ## If the offender is an undertaking, is the turnover percentage just an alternative national option? No. For the main CRA fine tiers, the Regulation sets the ceiling as the fixed euro amount or, if the offender is an undertaking, the stated percentage of total worldwide annual turnover for the preceding financial year, whichever is higher. So the percentage is not a softer optional substitute; it can raise the applicable maximum above the fixed euro cap. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(2) to (4) ## How should CRA fines be approached where the offender is a person that is not an undertaking? The fixed euro ceiling applies, but the authority should also take account of that person's situation. Recital 121 says that where administrative fines are imposed on a person that is not an undertaking, the competent authority should consider the general level of income in the Member State and the economic situation of that person when setting the amount. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(2) to (5), Recital 121 ## Does the small-manufacturer carve-out cover any Article 14 reporting failure? No. It is limited to failure to meet the 24-hour deadline for the early warning notification in Article 14(2)(a) or Article 14(4)(a). It does not create a general immunity for microenterprise or small-enterprise manufacturers from other Article 14 duties, from other CRA obligations, or from the separate fine tier for supplying incorrect, incomplete, or misleading information. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(2)(a), Article 14(4)(a), Article 64(4), Article 64(10)(a), Recital 120 ## Can Member States attach criminal sanctions to serious CRA infringements? Yes, potentially. The CRA itself requires Member States to lay down effective, proportionate, and dissuasive penalty rules, while fixing the main administrative-fine ceilings. The Blue Guide explains more generally for Union product law that national penalties may include criminal sanctions for serious infringements. So the CRA does not prevent Member States from adding criminal-law consequences in their national enforcement systems where national law provides for them. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 64(1) - [Blue Guide on the implementation of EU product rules (2022)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52022XC0629%2804%29&ref=sorena.io) - section 4.5.1.7 ## Does the CRA say anything about what Member States may do with penalty revenues? Yes, at recital level. Recital 122 says Member States should examine, taking national circumstances into account, the possibility of using revenues from CRA penalties, or their financial equivalent, to support cybersecurity policies and raise the level of cybersecurity in the Union, including through skills, SME capacity building, and public awareness. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Recital 122 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Penalties and Fines as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Penalties and Fines into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Penalties and Fines and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines --- --- title: "CRA Product Families FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/product-families" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/product-families" author: "Sorena AI" description: "CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA product families FAQ" - "CRA variants family file" - "CRA representative testing" - "CRA shared risk assessment variants" - "CRA product family conformity" - "CRA later variants" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Product Families FAQ CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Product Families Use this CRA FAQ to understand when similar variants can share one CRA assessment and documentation set, when differences force updates, and how family reuse interacts with placing on the market and conformity duties. Built for product, certification, engineering, and compliance teams managing variants and family-wide CRA evidence. The CRA does not define "product family" in the regulation text, but the draft guidance explains when similar variants can share one risk assessment, documentation set, and conformity assessment. This FAQ focuses on the limits of family-wide reuse, representative testing, later variants, and the continued obligation to keep each series product in conformity. ## Does the CRA itself define a "product family"? Not expressly in the regulation text. The CRA itself requires manufacturers to document and assess the conformity of the relevant product with digital elements. The more specific idea that similar variants, models, or configurations can in some cases be handled together as a product family is explained in the Commission's March 2026 draft guidance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2), Article 31, Annex VII, Annex VIII - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 7.4, points 158 to 161 ## When can one CRA assessment cover more than one product variant? Where the variants are similar in the ways that matter for cybersecurity. The draft guidance says reuse is possible where products in the same family share the same architecture, security-relevant design, and intended purpose, and are exposed to the same cybersecurity risks. In that case, the manufacturer may rely on a single cybersecurity risk assessment, a single set of technical documentation, and a single conformity assessment, as long as all variants are adequately covered. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 158 to 159 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2), Article 31 ## What is the decisive CRA test for deciding whether variants belong in the same product family? The decisive test is whether the differences between the variants are relevant to cybersecurity. The guidance makes clear that commercial similarity alone is not enough. The question is whether the differences affect cybersecurity properties, exposure to threats, or the way the essential cybersecurity requirements are implemented. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 160 to 161 ## What kinds of differences usually do not require separate CRA family treatment? Differences that do not affect cybersecurity properties usually do not require separate risk assessments or separate conformity assessments. The draft guidance gives examples such as: - physical housing - colour - form factor - memory size - other characteristics that are not security-relevant Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 160 ## What kinds of differences usually do require separate assessment or documentation updates? Differences that change the cybersecurity profile usually do. The draft guidance gives examples such as different communication interfaces, software stacks, update mechanisms, or remote connectivity. Those differences can affect threat exposure or the implementation of the essential requirements, so they must be reflected in the risk assessment and, where necessary, in the conformity assessment and technical documentation. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 160 to 161 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2), Article 31(2) ## Can a manufacturer use representative test evidence for a product family instead of testing every variant separately? Yes, where the variants are based on the same design and share the same risk profile. The March 2026 draft guidance says manufacturers are not expected to provide test evidence for every variant in that situation. It gives that clarification especially for products designed before the CRA applies, but the logic is tied to the shared design and shared risk profile rather than to a purely commercial grouping. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 34 to 35, Example 6, points 158 to 161 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12), Annex VII point 6, Annex VIII ## Does a product family approach remove the need to identify the relevant model or version in the documentation? No. Even where documentation is reused across a family, the CRA still requires product identification and traceability. Annex VII requires information enabling unique identification, Annex V requires the declaration's object to identify the product, and Annex VIII requires the declaration to identify the relevant product or product model. The Commission FAQ also says technical documentation must reflect redesigns, changes, and how versions can be identified. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex V point 4, Annex VII point 1, Annex VIII Part I point 4.2, Annex VIII Part IV point 5.2 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 and section 6.8 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.3 ## If a new variant changes the cybersecurity profile, can the manufacturer keep relying on the old family file without updates? No. Where a new variant introduces new cybersecurity risks or changes how the essential cybersecurity requirements are implemented, the existing risk assessment and conformity documentation must be updated. The CRA itself also requires the technical documentation to be kept up to date. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 161 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31(2) ## If the same remote data processing solution supports several products, can the RDPS documentation be reused? Yes, but the RDPS still needs to be declared in each affected product's technical documentation. The March 2026 draft guidance says documentation concerning the same RDPS can be reused across product conformity assessments, but each product's documentation must still indicate that the product has RDPS or relies on relevant third-party cloud solutions and must describe them. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 188 to 190 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31, Annex VII ## Does calling several variants a product family mean they count as one product for placing on the market? No. The family concept is about reusing assessment and documentation where that is justified. Product-law concepts like placing on the market still apply to each individual product. The CRA and the Blue Guide both treat placing on the market and compliance timing at the level of the individual product, not just the type or family. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Recital 38, Article 3(21), Article 6 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## If the manufacturer later places more units of the same model or series on the market, can it simply rely on the old CRA support-period position? Not automatically. The Commission FAQ explains that units already placed on the market can continue to be made available after the support period expires, but if the manufacturer later places additional units of the same model or series on the market, it still has to set the support period for those newly placed units in accordance with Article 13(8). Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 5.1 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8) ## Can a whole commercial range be treated as one CRA product family just because the products share branding or platform marketing? No. Shared branding, industrial design, or platform naming does not by itself justify one CRA family file. The relevant question remains whether the products share the same security-relevant design, intended purpose, and cybersecurity risk profile. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 158 to 161 ## If variants are similar enough, is the manufacturer required to use one family-wide CRA file? No. The draft guidance says manufacturers may rely on a single cybersecurity risk assessment, a single set of technical documentation, and a single conformity assessment where the family conditions are met. That means reuse is permitted, not mandatory. A manufacturer can still keep separate files if it prefers. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 159 ## Can a manufacturer add a later variant to an existing CRA product family instead of starting from scratch? Sometimes, yes. The March 2026 draft guidance allows reliance on a single risk assessment, technical documentation set, and conformity assessment where the variants share the same architecture, security-relevant design, intended purpose, and cybersecurity risks, and all variants are adequately covered. So a later variant can remain within the same family if it still fits those conditions. But where the later variant introduces new cybersecurity risks or changes how the essential cybersecurity requirements are implemented, the existing risk assessment and conformity documentation must be updated accordingly. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 158 to 161 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31(2) ## Does using a product-family approach remove the manufacturer's duty to keep series production in conformity? No. Article 13(14) still requires manufacturers to ensure that products that are part of a series of production remain in conformity with the CRA. They must adequately take into account changes in the development and production process, in the design or characteristics of the product, and in the standards, certification schemes, or common specifications used to verify conformity. So a family-based file does not freeze compliance. It still has to track changes that matter for products being placed on the market later. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(14) - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 3.1 and section 4.4 ## Can variants with different intended purposes or different applicable conformity-assessment routes still be treated as one CRA product family? Not usually. The draft guidance makes same intended purpose one of the conditions for family reuse. Annex VII also requires the technical documentation to identify the product's intended purpose, and the draft guidance elsewhere says the product's core functionality should be clearly identified so the correct conformity-assessment regime can be determined. Inference from those sources: if variants differ so much in intended purpose or core functionality that they lead to a different applicable CRA route, a single family-wide conformity assessment would normally not be the right approach. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 128 and 158 to 161 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VII points 1 and 4, Article 32 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Product Families as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Product Families into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Product Families and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/product-families --- --- title: "CRA Remote Data Processing Solutions FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions" author: "Sorena AI" description: "CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA RDPS FAQ" - "CRA remote data processing solutions" - "CRA Article 3(2)" - "CRA third-party SaaS RDPS" - "CRA cloud service due diligence" - "CRA backend RDPS scope" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" - "CRA remote data processing solutions FAQ" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Remote Data Processing Solutions FAQ CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Remote Data Processing Solutions Use this CRA FAQ to understand when remote software counts as RDPS, where backend and cloud-service boundaries sit, and what that changes for risk assessment, documentation, and lifecycle duties. Built for product, cloud, engineering, and compliance teams assessing CRA scope for connected software and services. The CRA treats certain manufacturer-controlled remote software as part of the product with digital elements. This FAQ explains the Article 3(2) RDPS test, the limits of backend scope, how third-party SaaS and cloud services fit into the analysis, and what manufacturers must document and assess when RDPS is in scope. ## What is a remote data processing solution under the CRA? Article 3(2) defines remote data processing as data processing at a distance for which the software is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions. That matters because a product with digital elements includes its remote data processing solutions. Recital 11 gives a concrete example: if a mobile application needs a manufacturer-provided API or database service to perform one of its functions, that service can fall within scope as RDPS. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1), Article 3(2), Recital 11, Recital 12 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 ## What are the main legal tests for deciding whether something is an RDPS? The March 2026 draft guidance breaks the definition into three elements: - the data processing is at a distance - its absence would prevent the product from performing one of its functions - the software is designed and developed by the manufacturer, or under its responsibility If one of those elements is missing, the solution is not RDPS within the CRA meaning. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 168 to 172 ## Does the remote processing have to support the product's core function only? No. The draft guidance says the relevant "functions" are not limited to core functionality or intended purpose in a narrow sense. They can also include supporting functions that the product offers, such as onboarding, configuration, synchronisation, remote commands, updates, and identity and access management. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 173 to 175 ## Can remote processing still be RDPS if the user can also perform the same function manually or locally? Yes. The draft guidance says a manual or local alternative does not by itself take the remote processing outside Article 3(2). If remote performance is one of the functions the product offers, the related remote processing can still qualify as RDPS. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 175 ## What does "at a distance" mean in practice? It is a case-by-case concept. The draft guidance says remote processing can take place through wired or wireless connections, in public cloud, private cloud, edge environments, or on local servers on the manufacturer's premises. The key point is that the relevant data processing happens remotely rather than only on the user's device. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 169 to 171 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Recital 11 ## Does RDPS cover the whole back-end or cloud infrastructure behind a product? No. The CRA covers the relevant software parts of remote data processing, not the manufacturer's network and information systems as a whole. The draft guidance also says the underlying hardware infrastructure remains outside the product scope, even though the related risks still need to be assessed. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Recital 11, Article 3(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 164 to 167, points 188 to 190 ## Does every backend system behind a product become RDPS? No. The draft guidance says only the parts of the system that directly interact with the product, and where data necessary for the product to perform one of its functions is stored or processed, fall within the relevant CRA conformity scope. In its banking-app example, the API layer can be RDPS while segregated account-management or ledger systems remain outside RDPS, even though the manufacturer still has to assess and mitigate the risks they create for the product. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 189, section 8.3.1 ## Are ordinary websites or web pages remote data processing solutions? Usually no. A product redirecting users to a webpage that only provides information or instructions does not make that site RDPS. But a website or portal can fall within scope if it actually enables or supports a product function, such as an authentication function, and the Article 3(2) criteria are met. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Recital 12 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 178 ## What does "under the responsibility of the manufacturer" mean for CRA RDPS? The draft guidance treats it as broader than in-house development, but narrower than simply licensing an existing third-party service. It refers to remote processing solutions that are tailor-made for the manufacturer, built solely on its behalf, and based on its designs and specifications. A general-purpose third-party SaaS offering normally does not meet that test. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 179 ## Does it matter who operates the remote solution day to day? Not decisively. The draft guidance says the decisive issue is who designed and developed the relevant software, not who operates the environment. A manufacturer can remain responsible even where operation is outsourced. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 180 ## How does the CRA treat IaaS, PaaS, and SaaS in RDPS analysis? The cloud model does not decide the outcome by itself, but it helps explain who designed and developed what. The draft guidance says: - on third-party IaaS, the manufacturer's own software running on that infrastructure may qualify as RDPS - on third-party PaaS, the manufacturer's application layer may qualify as RDPS, while the provider's platform functions do not - a third-party SaaS application that the manufacturer did not design or commission is generally not RDPS Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Recital 12 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 181 to 185 ## If a product relies on third-party SaaS that is necessary for one of its functions, is that SaaS automatically RDPS? No. If the service is necessary for a function but was not designed and developed by the manufacturer or under its responsibility, the guidance says it should be treated more like a third-party component. The manufacturer still has to assess the resulting risks and exercise due diligence, but the service is not RDPS. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 184 to 186 ## If remote processing is used only for analytics, statistics, or future product development, is it usually RDPS? Usually no. The draft guidance says processing of that kind is not RDPS where its absence would not prevent the product from performing one of its functions. But the manufacturer may still need to assess and mitigate any risks that the related remote communications create for the product. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 176 to 177 ## Are internal systems like HR, payroll, CRM, CI/CD, security-update distribution to edge locations, pentesting, threat hunting, or red-team tooling usually RDPS? Usually no. The draft guidance says those kinds of internal or organisational systems should not be treated as RDPS for the product, even though they may matter to the manufacturer's broader security posture. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 165 to 167 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Recital 11 ## What does CRA RDPS status change for risk assessment and conformity? It means the manufacturer has to assess the product as a whole, including RDPS when it is in scope. The Commission FAQ says the cybersecurity risk assessment needs to cover the entire product with digital elements, including remote data processing where relevant and any supporting functions that may form part of the product. The draft guidance adds that the conformity assessment should focus on the parts of the system where the relevant product data is stored or processed, not the whole surrounding environment. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 162, 187 to 190 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2), Article 31, Annex VII ## What must the manufacturer document when a product has RDPS or relies on third-party cloud solutions? The draft guidance says the technical documentation should indicate whether the product has RDPS or relies on third-party cloud solutions, and should describe them. If the same RDPS supports several products, it still needs to be declared in each product's documentation, even though the underlying documentation may be reused. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 188 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31, Annex VII ## What kinds of third-party assurance evidence may help under the CRA when a product relies on cloud services? The draft guidance says that, as relevant, the manufacturer may re-use certain evidence in support of its conformity assessment and/or due diligence for third-party cloud services. The listed examples are: - CE marking of components, if those components are still within their support period - evidence of fulfilment of obligations under Commission Implementing Regulation (EU) 2024/2690 - evidence of fulfilment of obligations under DORA - statements of conformity or certificates under a European cybersecurity certification scheme - evidence of conformity with ISO/IEC 27017:2015 or ISO/IEC 27001:2022 Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 191 ## Do RDPS-related obligations matter only at launch, or also during the support period? They also matter later. The draft guidance says RDPS must be taken into account not only for the initial conformity analysis but also for lifecycle obligations, including reporting of actively exploited vulnerabilities and severe incidents under Article 14. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 162 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14 ## Is a cellular network or general connectivity provider itself an RDPS? No, not just because the product relies on connectivity. The draft guidance's cellular-network example says a network is only a communication channel in that scenario, not remote data processing whose absence would prevent the product from performing its function in the Article 3(2) sense. It also says such a network should not be treated like a third-party component where no provider software is integrated into the product. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 8.3.5 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(2) ## Can manufacturers use contracts or SLAs with third-party cloud providers to help manage CRA risks? Yes, as one support tool. The draft guidance says the manufacturer should combine product-level security controls with verification of the provider's own security measures. It adds that security guarantees in SLAs can help, including assurances about vulnerability handling, and says manufacturers are encouraged to ensure third-party providers keep them adequately informed about changes to their solutions. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 192 ## If a third-party cloud provider changes its own service, is that automatically a substantial modification of the product? Not automatically. The draft guidance says major changes in third-party cloud solutions should not by themselves qualify as substantial modification of the product where those solutions are not under the manufacturer's responsibility. The manufacturer still needs to manage the resulting risks through risk assessment and due diligence. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 192 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Remote Data Processing Solutions as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Remote Data Processing Solutions into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Remote Data Processing Solutions and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions --- --- title: "CRA Repairs and Spare Parts FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts" author: "Sorena AI" description: "CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA repairs FAQ" - "CRA spare parts FAQ" - "CRA Article 2(6)" - "CRA identical spare part exemption" - "CRA refurbishment substantial modification" - "CRA compatibility replacement parts" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" - "CRA repairs and spare parts FAQ" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Repairs and Spare Parts FAQ CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Repairs and Spare Parts Use this CRA FAQ to understand when repairs or upgrades become substantial modifications, how the spare-part exemption works, and what happens when compatibility constraints prevent a fully modern replacement design. Built for repair, manufacturing, refurbishment, engineering, and compliance teams managing legacy products and replacement parts. The CRA does not treat every repair, maintenance action, or replacement part as a new CRA product assessment. This FAQ explains the Article 2(6) spare-part exemption, the separate substantial-modification analysis for repairs and upgrades, and how compatibility constraints and legacy products affect CRA compliance duties. ## Do repair, maintenance, or refurbishment automatically count as substantial modifications under the CRA? No. The CRA says those operations do not necessarily lead to a substantial modification. The real question is whether the change affects compliance with the essential cybersecurity requirements or changes the intended purpose for which the product was assessed. Recital 42 also makes clear that a manufacturer-led "upgrade" can still become substantial if it changes the product's design and development in a way that affects intended purpose or compliance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(30), Recital 38, Recital 42 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 85 to 90 ## How should a physical repair be assessed under the CRA? Case by case. The draft guidance says refurbishment, maintenance, or repair that physically changes a product does not automatically become a substantial modification. The assessment should ask whether the physical change affects compliance with Annex I Part I or changes the intended purpose covered by the cybersecurity risk assessment. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 88 to 90 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(30) ## If a defective part is replaced with a better-performing part, does that automatically make the repaired product substantially modified? No. The draft guidance says replacing defective or worn parts with parts that perform better does not in itself trigger substantial modification. It only does so if the change affects compliance with the essential requirements or changes the intended purpose in a way not covered by the original risk assessment. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 90, Examples 29 and 30 ## Are identical spare parts excluded from the CRA? Yes. Article 2(6) excludes spare parts made available to replace identical components, where they are manufactured according to the same specifications as the components they replace. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(6), Recital 29 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 91 to 92 ## Does the CRA identical-spare-part exemption also cover legacy products placed on the market before 11 December 2027? Yes. Recital 29 and the draft guidance both say the exemption covers spare parts for legacy products placed on the market before the CRA applies, as well as spare parts for products that have already gone through CRA conformity assessment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Recital 29 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 91 to 92 ## What if the replacement part is not identical to the original component? Then the spare part is itself subject to the CRA as a product in its own right. The draft guidance says compliance must then be assessed in light of that spare part's intended purpose, including its role in ensuring compatibility or interoperability with the existing product. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 93 ## If the spare part is not identical, does installing it automatically mean the repaired product has been substantially modified? No. The draft guidance says the repair does not in itself amount to a substantial modification, provided the repaired product's intended purpose and cybersecurity risk profile remain unchanged. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 94, Examples 32 and 34 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(30) ## What if a non-identical spare part cannot fully meet every CRA requirement because it has to stay compatible with an older product? The manufacturer must reflect those constraints in the cybersecurity risk assessment and implement appropriate alternative or compensatory risk-mitigation measures. The draft guidance also says the technical documentation and user information should transparently describe the constraints, the associated risks, and the measures taken. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 29, point 93 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3), Article 13(18), Article 31(2), Annex II ## Can software fixes or security updates be treated like maintenance rather than substantial modification? Yes, often. The CRA says security updates that are designed to reduce cybersecurity risk and that do not modify the intended purpose are generally not substantial modifications. The Commission FAQ gives the example of a bug-fix update for a pre-CRA smart TV that does not bring the product into CRA compliance because it does not substantially modify it. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Recital 39 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.4 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 101 to 106 ## When can a software update become a substantial modification? When it changes the intended purpose or introduces new or increased cybersecurity risks not covered by the original risk assessment. The CRA recital and the draft guidance both make clear that the label "security update" is not decisive by itself. A software change can still qualify as substantial modification if it materially changes the product's trust model, dependencies, data flows, or risk profile. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Recital 39 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 96 to 105 ## What happens if a repair or update does qualify as a substantial modification? The modified product is treated as a new product for CRA purposes. That means the act of making the substantially modified product available on the market becomes a new placing on the market. The person carrying out the substantial modification may become the manufacturer under Article 21 or Article 22. Under Article 22(2), the CRA obligations apply to the affected part of the product, or to the whole product if the modification impacts the cybersecurity of the product as a whole. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 21, Article 22, Article 69(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 86, 107 to 108 ## Does a substantial modification always require a complete rebuild of all documentation and testing? No. The draft guidance says existing documentation and tests may be reused for aspects not impacted by the substantial modification. The conformity assessment should focus on the substantially modified parts. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 109 to 110 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.1 and section 4.3 ## How do repairs and updates affect products that were placed on the market before 11 December 2027? For those products, the CRA generally applies only if, from 11 December 2027 onward, they are substantially modified. The Commission FAQ says a non-substantial bug-fix update on a legacy product does not trigger CRA compliance for that product. But Article 14 reporting obligations apply more broadly even to products placed on the market before 11 December 2027. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2), Article 69(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.4 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 111 to 112 ## Are distributors required to bring old products into CRA compliance just because they continue to sell or repair them after 11 December 2027? No, not unless they carry out a substantial modification. The Commission FAQ says distributors are not required to bring products placed on the market before 11 December 2027 into CRA compliance merely because they continue making them available after that date. That changes only if they themselves carry out a substantial modification. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.5 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 21, Article 69(2) ## Does CRA Article 2(6) exempt only the spare part itself, or does it automatically settle the repair analysis too? It exempts the spare part itself. Whether the repair amounts to a substantial modification is a separate question. The draft guidance's spare-part examples show that an identical-specification replacement usually does not amount to a substantial modification, but that conclusion still rests on the repair analysis rather than on Article 2(6) alone. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(6), Article 3(30) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 91 to 94, Examples 31 and 33 ## Is it enough that a replacement part performs the same function, uses the same protocols, or uses the same security mechanisms? No. For the Article 2(6) exemption, the part must replace an identical component and be manufactured according to the same specifications. The draft guidance's Example 34 shows the opposite case: a replacement module may preserve the same function, communication protocols, and security mechanisms, yet still fall outside the exemption if it is based on a different chipset or updated firmware. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 91 to 94, Example 34 ## If a product is temporarily exported outside the Union for repair and then returned, does that alone trigger a new conformity assessment? No. The Blue Guide says repaired products that are not considered new products do not need to undergo conformity assessment again, whether the original product was placed on the market before or after the legislation entered into force. It says that remains true even if the product was temporarily exported to a third country for the repair operation. Under the CRA, the key issue remains whether the repair is substantial. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.1 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 88 to 90 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(30), Recital 42 ## If compatibility constraints justify a less-than-ideal replacement design, can the manufacturer just leave those CRA repair constraints in place for the rest of the support period? Not automatically. The draft guidance says the manufacturer must document the constraints, assess the associated risks, and implement compensatory measures. It also says such constraints should be periodically reassessed during the support period, and where they can be reduced or lifted over time, the product should be updated so it can move towards state-of-the-art cybersecurity. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 29, point 93 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3), Article 31(2), Annex II ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Repairs and Spare Parts as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Repairs and Spare Parts into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Repairs and Spare Parts and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts --- --- title: "CRA Reporting Obligations FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/reporting-obligations" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/reporting-obligations" author: "Sorena AI" description: "CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA reporting obligations FAQ" - "CRA Article 14 reporting" - "CRA CSIRT notification" - "CRA actively exploited vulnerability reporting" - "CRA severe incident reporting" - "CRA legacy product reporting" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Reporting Obligations FAQ CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Reporting Obligations Use this CRA FAQ to understand what must be reported under Article 14, when the reporting clock starts, where filings go, and how user notices and legacy-product reporting work. Built for incident response, product security, legal, and compliance teams managing CRA reporting workflows. The CRA creates mandatory reporting duties for actively exploited vulnerabilities and severe incidents, with earlier application than most other CRA obligations. This FAQ explains Article 14 reporting triggers, deadlines, CSIRT routing, user-notice duties, voluntary reporting, and how the regime applies to older products already on the market. ## What does the CRA require manufacturers to report, and from when? From 11 September 2026, Article 14 requires manufacturers to notify two things: - any actively exploited vulnerability contained in the product with digital elements - any severe incident having an impact on the security of the product with digital elements Those notifications must be made simultaneously to the relevant CSIRT designated as coordinator and to ENISA via the single reporting platform. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(1), Article 14(3), Article 16(1), Article 71(2), Recital 65, Recital 126 ## What is an "actively exploited vulnerability" for CRA reporting purposes? Article 3(42) defines it as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner. That means the reporting trigger is not just that a flaw exists. The Commission FAQ says a vulnerability found in good-faith testing, a lab, or a bug-bounty context is not subject to mandatory notification unless there is reliable evidence of malicious exploitation. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(42), Recital 68, Article 14(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 5.2 ## What is a severe incident under the CRA? Article 14(5) says an incident is severe where either: - it negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions - it has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the user's network and information systems Recital 68 adds that this can include incidents affecting the manufacturer's development, production, or maintenance processes in a way that increases risk for users. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(3) to (5), Recital 68 ## What are the reporting deadlines for actively exploited vulnerabilities? For an actively exploited vulnerability, the manufacturer must submit: - an early warning without undue delay and in any event within 24 hours of becoming aware - a vulnerability notification without undue delay and in any event within 72 hours of becoming aware - a final report no later than 14 days after a corrective or mitigating measure is available Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(2) ## What are the reporting deadlines for severe incidents? For a severe incident, the manufacturer must submit: - an early warning without undue delay and in any event within 24 hours of becoming aware - an incident notification without undue delay and in any event within 72 hours of becoming aware - a final report within one month after submission of the incident notification Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(4) ## What information has to be included in CRA reporting notifications and reports? The CRA stages the information. For an actively exploited vulnerability: - the early warning identifies the vulnerability and, where applicable, the Member States where the product is known to have been made available - the 72-hour notification adds general information about the product, the exploit and vulnerability, corrective or mitigating measures already taken, measures users can take, and, where applicable, the sensitivity of the information - the final report adds the vulnerability description, severity and impact, information about the malicious actor where available, and details of the security update or other corrective measures For a severe incident: - the early warning includes at least whether the incident is suspected of being caused by unlawful or malicious acts and, where applicable, the relevant Member States - the 72-hour notification adds general information about the nature of the incident, an initial assessment, corrective or mitigating measures already taken, measures users can take, and, where applicable, the sensitivity of the information - the final report adds the detailed description, severity and impact, the likely threat type or root cause, and the applied and ongoing mitigation measures Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(2), Article 14(4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 197 ## When does the CRA reporting clock start? It starts when the manufacturer becomes aware of the actively exploited vulnerability or severe incident. The March 2026 draft guidance says a manufacturer is to be regarded as aware when, after an initial assessment, it has a reasonable degree of certainty that a vulnerability is being actively exploited or that a severe incident has occurred and has compromised the security of the product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(1) to (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 193 to 197 ## Does the CRA require specific monitoring channels in order to become aware? No. The Commission FAQ says the CRA does not prescribe how a manufacturer must become aware. It gives examples such as customer reports, partner reports, threat intelligence, researchers, telemetry, honeypots, and internal monitoring, but it also says those examples do not create a legal duty to use all of them. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 5.1 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14 ## Do zero-day vulnerabilities always have to be reported? No. They are subject to mandatory reporting only when the manufacturer has reliable evidence that a malicious actor has exploited them. If a zero-day is discovered without evidence of malicious exploitation, the manufacturer can still report it voluntarily under Article 15. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 5.2 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 15 ## If an actively exploited vulnerability is in an integrated third-party component, does the finished-product manufacturer have to notify it? Yes, if that vulnerability is actively exploited in the finished product. The Commission FAQ says the finished-product manufacturer must notify any actively exploited vulnerability contained in its product, even if the weakness originates in an integrated component. If the component manufacturer also placed that component on the market, it may have its own notification obligation as well. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 5.4 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(1), Article 13(6) ## What if the component vulnerability exists, but cannot be exploited in the finished product? Then it is not an actively exploited vulnerability for that finished product, so Article 14 mandatory reporting is not triggered on that basis. The Commission FAQ says voluntary reporting under Article 15 may still be appropriate, and Article 13(6) still requires reporting upstream to the person or entity manufacturing or maintaining the component. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 5.4 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 15, Article 13(6) ## Where does the manufacturer file the CRA notification? The notification is submitted via the single reporting platform using the electronic notification end-point of the relevant CSIRT designated as coordinator. It is simultaneously accessible to ENISA. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(7), Article 16(1), Recital 65, Recital 69 ## Which Member State's CSIRT is the right one for reporting? If the manufacturer has a main establishment in the Union, the report goes to the CSIRT of that Member State. For CRA reporting, the main establishment is the Member State where decisions related to the cybersecurity of the manufacturer's products are predominantly taken. If that cannot be determined, it is the Member State with the establishment having the highest number of employees in the Union. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(7) ## What if the manufacturer has no main establishment in the Union? Article 14(7) provides a fallback order. The manufacturer reports to the CSIRT of the Member State determined, in order, by: - the authorised representative acting for the highest number of the manufacturer's products - the importer placing on the market the highest number of those products - the distributor making available the highest number of those products - the Member State where the highest number of users are located If the last fallback is used, the manufacturer may keep reporting later events to that same CSIRT. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(7) ## Can the CSIRT ask for more information after the initial CRA reports? Yes. Article 14(6) says the CSIRT initially receiving the notification may request an intermediate report on relevant status updates. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(6) ## Does the CRA also require user notification? Yes. After becoming aware of an actively exploited vulnerability or severe incident, the manufacturer must inform impacted users and, where appropriate, all users, including any risk-mitigation and corrective measures they can deploy. The CRA adds that this should, where appropriate, be provided in a structured, machine-readable format that is easily automatically processable. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Recital 67 ## Does CRA user notification always mean public disclosure to everyone? Not automatically. The March 2026 draft guidance says the Article 14(8) duty should be applied in a risk-based and proportionate way. It does not necessarily require indiscriminate public disclosure in every case, especially for sensitive products or contexts where wider disclosure could itself increase cybersecurity risk. Once the vulnerability has been adequately addressed or mitigated, broader disclosure may become appropriate, but the timing and level of detail should still remain proportionate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198 to 200 ## What if the manufacturer does not inform users in time under the CRA? Then the notified CSIRTs may provide that information to users where that is proportionate and necessary to prevent or mitigate the impact. For severe incidents, Article 17(2) also allows the relevant CSIRT, after consulting the manufacturer and where appropriate in cooperation with ENISA, to inform the public or require the manufacturer to do so where public awareness is necessary or otherwise in the public interest. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Article 17(2) ## Can dissemination of a notification be delayed because the information is sensitive? Yes, in exceptional circumstances and only for the period strictly necessary. Article 16 allows the CSIRT initially receiving the notification to delay dissemination on justified cybersecurity-related grounds, including coordinated vulnerability disclosure cases. The CRA also provides an additional regime for particularly exceptional vulnerability cases involving exploitation limited to one Member State, essential national interests, or imminent high cybersecurity risk from further dissemination. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 16(2), Article 16(6), Recital 70 ## What if no fix is available yet for CRA reporting purposes? The reporting obligation still applies. The 24-hour and 72-hour deadlines are triggered by awareness, not by the availability of a corrective measure. The final vulnerability report is due after a corrective or mitigating measure becomes available. Article 16(5) also recognises the case where no corrective or mitigating measure is yet available and requires secure, need-to-know handling on the reporting platform. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(2), Article 16(5) ## Do products placed on the market before 11 December 2027 still have to be reported under Article 14? Yes. Article 69(3) says Article 14 applies to all products with digital elements in scope, including products placed on the market before 11 December 2027. The Commission FAQ adds that these reporting obligations start applying on 11 September 2026. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(3), Article 71(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 5.3 ## For those pre-11 December 2027 products, do the broader CRA vulnerability-handling obligations also apply automatically? No. The Commission FAQ says manufacturers may still have to report actively exploited vulnerabilities and severe incidents for those older products, but the broader CRA obligations do not apply to them on that basis alone unless the product is substantially modified. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2), Article 69(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 5.3 ## What if the product is so old that the manufacturer can no longer investigate or remediate it properly? The reporting obligation can still apply. The Commission FAQ expressly notes that, for older products, tooling, build environments, dependencies, or staff knowledge may no longer be available. That practical difficulty does not remove the Article 14 reporting duty for in-scope pre-11 December 2027 products. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 5.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(3) ## Can CRA reporting be done voluntarily even where Article 14 does not require it? Yes. Article 15 allows manufacturers and other natural or legal persons to notify vulnerabilities, cyber threats affecting a product's risk profile, incidents, and near misses on a voluntary basis. The CSIRT may prioritise mandatory notifications over voluntary ones. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 15(1) to (3) ## What happens under the CRA if someone other than the manufacturer submits a report? If another natural or legal person reports an actively exploited vulnerability or severe incident under Article 15, the CSIRT designated as coordinator must inform the manufacturer without undue delay. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 15(4) ## Does CRA reporting itself increase liability? No. The CRA expressly says the mere act of notification under Article 14 or Article 15 does not subject the notifying natural or legal person to increased liability. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 17(4) ## What happens under the CRA after a vulnerability is reported and a corrective measure becomes available? After a security update or another corrective or mitigating measure is available, ENISA must, in agreement with the manufacturer, add the publicly known vulnerability notified under Article 14(1) or Article 15(1) to the European vulnerability database. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 17(5) ## Do open-source software stewards have the same reporting obligations as manufacturers? Not in full. Article 24(3) applies Article 14(1) to stewards only to the extent they are involved in development of the products. It applies Article 14(3) and Article 14(8) only to the extent that severe incidents affect network and information systems the stewards provide for the development of those products. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 24(3) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 76 to 79 ## Is there any specific CRA reporting relief for microenterprises and small enterprises? There is only a narrow one. The CRA does not remove the reporting obligation itself, but Article 64 and Recital 120 provide that microenterprises and small enterprises are exempt from the administrative fines tied to failure to meet the 24-hour early-warning deadline in Article 14(2)(a) or Article 14(4)(a). Article 17(6) also says CSIRTs shall provide helpdesk support, in particular for microenterprises and SMEs. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 17(6), Article 64(10)(a), Recital 120 ## If the manufacturer had already become aware of the issue before 11 September 2026, does Article 14 retroactively require notification on that date? No, not just because that date arrived. The Commission FAQ says the obligation to notify applies upon becoming aware following the entry into application of the reporting requirements. So Article 14 starts applying on 11 September 2026, but the trigger is still awareness under that reporting regime rather than a retroactive duty caused by earlier awareness alone. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 71(2), Article 14(1) to (4) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 5.3 ## Can a manufacturer satisfy the mandatory Article 14 duty by notifying only ENISA? No. Mandatory notifications must be submitted via the single reporting platform using the electronic notification end-point of the relevant CSIRT designated as coordinator. ENISA gets simultaneous access through that mechanism, but Article 14 does not make direct ENISA-only filing the mandatory route. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(7), Article 16(1), Recital 65, Recital 69 ## If dissemination is delayed under Article 16, does that let the manufacturer delay its own notification? No. The CRA's delay mechanism applies after the CSIRT designated as coordinator has received the notification and concerns onward dissemination through the single reporting platform. On that basis, it does not change the manufacturer's own Article 14 deadlines, which still run from becoming aware. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(2), Article 14(4), Article 16(2), Article 16(6) ## Are importers or distributors the Article 14 reporters instead of the manufacturer? No. Article 14 places the mandatory CRA reporting duty on the manufacturer. Importers and distributors have their own related duties: if they become aware of a vulnerability, they must inform the manufacturer without undue delay, and if the product presents a significant cybersecurity risk, they must immediately inform the relevant market surveillance authorities. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(1) to (4), Article 19(5), Article 20(4) ## Does voluntary reporting create extra obligations for the notifier, and is it handled confidentially? Not in itself. Article 15(5) says CSIRTs designated as coordinators and ENISA must ensure confidentiality and appropriate protection of the information provided by a voluntary notifier. It also says voluntary reporting does not create additional obligations that the notifying person would not otherwise have had. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 15(5) ## Does CRA reporting also feed market-surveillance action? Yes. Article 16(3) says CSIRTs designated as coordinators must provide their national market surveillance authorities with the notified information necessary for those authorities to fulfil their CRA tasks. Recital 69 states the same reporting flow as part of the single-platform design. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 16(3), Recital 69 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Reporting Obligations as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Reporting Obligations into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Reporting Obligations and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/reporting-obligations --- --- title: "CRA Scope FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements" author: "Sorena AI" description: "CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA scope FAQ" - "CRA products with digital elements" - "CRA standalone software scope" - "CRA indirect connection" - "CRA source code product with digital elements" - "CRA exclusions FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Scope FAQ CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Scope and Products with Digital Elements Use this CRA FAQ to determine when hardware, software, source code, and connected systems fall within CRA scope, what kinds of connections count, and which exclusions apply. Built for product, legal, engineering, and compliance teams assessing whether an offering is a CRA product with digital elements. The CRA applies only where a product with digital elements is made available on the EU market and has the required direct or indirect data connection in its intended purpose or reasonably foreseeable use. This FAQ explains the scope tests, software and firmware coverage, connection concepts, exclusions, source-code edge cases, and multi-element system boundaries. ## When is a product in scope of the CRA? A product is in scope when three elements are present together: - it is a product with digital elements - it is made available on the EU market - its intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network The Article 2 exclusions must then also be checked. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(1)-(7) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.1 ## What is a product with digital elements under the CRA? A product with digital elements is a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 ## Are stand-alone software products covered by the CRA? Yes. The Commission FAQ expressly lists standalone software, such as downloadable mobile apps and programs, as examples of products with digital elements. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1), Article 3(4) ## Is firmware covered by the CRA scope? Yes. Firmware falls within the CRA when it is software placed on the market, including when it is supplied separately for integration into hardware devices. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1), Article 3(4), Article 3(6) ## Are hardware components and foundational electronics covered if they are placed on the market separately? Yes. The Commission FAQ lists integrated circuits, motherboards, and sensors as examples of hardware that can be products with digital elements when the other scope conditions are met. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1), Article 3(5), Article 3(6), Article 3(7) ## Can hardware and separately supplied software still form one product with digital elements? Yes. The draft guidance says the delivery channel does not decide the product boundary by itself. If a hardware device is designed to operate together with specific software so that it can perform its intended functions, the hardware and that software together constitute the product with digital elements even if the software is downloaded later through a separate channel such as a website or app store. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 19 and Examples 3-4 ## Does every electronic product with embedded firmware automatically fall within the CRA? No. The product must also have a direct or indirect logical or physical data connection to a device or network in its intended purpose or reasonably foreseeable use. The Commission FAQ gives examples such as offline dishwashers, calculators, toys, coffee machines, and electric toothbrushes that are outside scope despite embedded firmware. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.3 ## What counts as a logical connection under the CRA? A logical connection is a virtual representation of a data connection implemented through a software interface. The Commission FAQ gives examples such as network sockets, pipes, files, APIs, browsers establishing HTTPS sessions, and email clients initiating IMAP or SMTP exchanges. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.3 ## What counts as a physical connection under the CRA? A physical connection is a connection between electronic information systems or components implemented using physical means, including electrical, optical, mechanical, wired, or radio-based interfaces. The Commission FAQ gives examples such as USB, Ethernet, fibre, copper fieldbus, Wi-Fi, Bluetooth, and NFC. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(9) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.3 ## Can a product still be in scope if it is only indirectly connected to a device or network? Yes. The CRA expressly covers indirect logical or physical connections. The Commission FAQ explains that even products only indirectly connected through a larger system can serve as attack vectors and therefore fall within scope. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(1), Article 3(10), recital 9 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.3 ## Is a product outside scope if it has electronics but does not exchange digital data? Generally yes. The March 2026 draft guidance says the scope boundary is not the mere presence of electronics, but the product's capacity to exchange digital information. Signals used only to power or trigger a function, without conveying digitally encoded information, do not amount to a data connection for CRA purposes. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 23-25 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(1), Article 3(7)-(10) ## Are websites themselves CRA products with digital elements? Not necessarily. The Commission FAQ says websites that do not support the functionality of a product with digital elements are not themselves products with digital elements. If a website supports the functionality of a product and meets the definition of remote data processing, it may fall within scope on that basis. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1), Article 3(2), recital 12 ## Is standalone SaaS itself a product with digital elements under the CRA? No, not by itself. The Commission FAQ says standalone SaaS and other cloud solutions designed and developed outside the responsibility of a manufacturer of a product with digital elements are not themselves products with digital elements. Where such a service meets the definition of remote data processing for a product, it can fall within scope on that basis. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.2 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(2), recital 11, recital 12 ## Are products manufactured only for the manufacturer's own use in CRA scope? Generally no. The CRA applies to products made available on the market. The Commission FAQ relies on the Blue Guide to explain that placing on the market does not take place where a product is manufactured for one's own use. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.5 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(21), Article 3(22) ## Are internal development, configuration, or programming tools built only for the manufacturer's own use in scope? Generally no, unless they are separately placed on the market. The Commission FAQ gives this example directly for development and configuration tools. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.5 ## Can a manufacturer release unfinished or non-compliant software for testing purposes under the CRA? Yes, under specific conditions. Article 4(3) allows unfinished software that does not comply with the CRA to be made available for the limited period required for testing, provided it carries a visible sign stating that it does not comply and is not being made available for purposes other than testing. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 4(3), recital 37 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.6 ## What if a product was designed before 11 December 2027 but is first placed on the market on or after that date for CRA scope purposes? It can still be in scope. The March 2026 draft guidance explains that the CRA applies based on placement on the market, not on when the product was originally designed. So a product designed before 11 December 2027 can still fall within the CRA if it is first placed on the EU market on or after 11 December 2027. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - section 2.6 and Example 7 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(1), Article 3(21), Article 71(2) ## Do products placed on the market before 11 December 2027 fall under the CRA? As a rule, only if they are substantially modified from that date onward. Article 69(2) says products placed on the market before 11 December 2027 are subject to the CRA only if, from that date, they are substantially modified. Article 14 reporting obligations are the express exception, and the Commission FAQ says those obligations start applying on 11 September 2026. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2)-(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.4 ## Does the CRA apply to products developed or modified exclusively for national security or defence purposes? No. Those products are excluded, as are products specifically designed to process classified information. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(7) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.8 ## Are dual-use products excluded from the CRA just because they can also be used in defence contexts? No. The Commission FAQ says dual-use products remain subject to the CRA when made available on the market unless they are developed or modified exclusively for national security or defence purposes. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.8 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(7) ## Which products are expressly excluded because other Union legislation already applies? The CRA does not apply to: - products to which Regulation (EU) 2017/745 on medical devices applies - products to which Regulation (EU) 2017/746 on in vitro diagnostic medical devices applies - products to which Regulation (EU) 2019/2144 on vehicle type approval applies - products certified in accordance with Regulation (EU) 2018/1139 on civil aviation - equipment within the scope of Directive 2014/90/EU on marine equipment Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(2)-(4) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.9 ## Does the current grounding also identify an additional vehicle-related exclusion outside the core Article 2 list? Yes. The Commission FAQ says Delegated Regulation (EU) 2025/1535 also excludes products with digital elements falling within the scope of Regulation (EU) No 168/2013 on two- or three-wheel vehicles and quadricycles, except L1e category vehicles designed to pedal. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.9 ## Are there other products that may later be limited or excluded because sectoral rules already cover the same risks? Yes. Article 2(5) allows the Commission to adopt delegated acts limiting or excluding the CRA for products covered by other Union rules that address all or some of the same risks, where the regulatory framework remains coherent and the sectoral rules achieve the same or a higher level of protection. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(5) ## Are identical spare parts excluded from the CRA scope? Yes. The CRA excludes spare parts made available to replace identical components in products with digital elements where those spare parts are manufactured according to the same specifications as the components they replace. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(6) ## Can Member States still impose additional cybersecurity requirements when procuring or using CRA products for specific purposes? Yes. The CRA does not prevent Member States from setting additional cybersecurity requirements for procurement or use for specific purposes, including national security or defence procurement or use, as long as those requirements are consistent with Union law and are necessary and proportionate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 5(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.8 ## Can source code itself be a product with digital elements when it is supplied commercially? Yes. The draft guidance says it does not matter whether the code is uncompiled, compiled, or interpreted. If a manufacturer provides computer code to customers as part of a commercial activity, that code is placed on the market for CRA purposes even if the customer still has to adapt or compile it before use. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 20 to 22, Example 5 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(4) ## Is publicly shared source code, unfinished review code, or tutorial and demo code automatically in scope as a CRA product? No. The draft guidance says public sharing of free and open-source computer code in repositories is not by itself placing that code on the market. It also says unfinished code shared during design and development, and sample or demo code provided in tutorials or training materials, is not considered placed on the market. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 21 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(22), Article 4(3) ## Can software that is offline by itself still be indirectly connected and therefore in scope? Yes. The Commission FAQ gives the example of an offline text editor or calculator that does not itself initiate communications but runs on a host operating system that does. In that situation, the software can still be indirectly connected within the CRA meaning. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(10), recital 9 ## Does wireless charging or a simple electrical on/off signal count as a CRA data connection? Not by itself. The draft guidance says a data connection requires digital information to be deliberately encoded and capable of being decoded as data at the destination. Signals used only to power or trigger a function do not create a CRA data connection. The Commission FAQ's electric-toothbrush example illustrates the same boundary. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 23 to 25 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(1), Article 3(7) to Article 3(10) ## Can a complex system made up of multiple hardware and software elements still be one CRA product? Yes. The draft guidance says systems composed of multiple hardware and software elements that operate together to perform a certain function can be a single product with digital elements where that system is placed on the market as a single product. Their complexity, long lifecycle, or reliance on older components does not exclude them from scope by itself. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 26 to 29 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(1), Article 13(3) ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Scope and Products with Digital Elements as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Scope and Products with Digital Elements into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Scope and Products with Digital Elements and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements --- --- title: "CRA Secure-by-Default FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/secure-by-default" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/secure-by-default" author: "Sorena AI" description: "CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA secure by default FAQ" - "CRA Annex I point 2b" - "CRA automatic security updates default" - "CRA tailor-made exception" - "CRA default configuration" - "CRA Article 13(4) justification" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Secure-by-Default FAQ CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Secure by Default Use this CRA FAQ to understand what secure by default means under Annex I, when automatic security updates must be enabled by default, and how the narrow tailor-made exception works. Built for product, security, firmware, and compliance teams deciding default configurations and update behavior under the CRA. The CRA requires products with digital elements to be placed on the market with a secure-by-default configuration grounded in the manufacturer's cybersecurity risk assessment. This FAQ explains what that means in practice, how automatic security updates fit into the rule, when non-applicability can be justified, and why the tailor-made exception is narrow. ## What does the CRA's secure-by-default requirement mean? The CRA requires products with digital elements to be made available on the market with a secure-by-default configuration, based on the manufacturer's cybersecurity risk assessment and in light of the product's intended purpose and reasonably foreseeable use. This is not a generic slogan. It is a concrete Annex I requirement. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(3), Annex I Part I, point (2)(b) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.4 ## Does secure by default mean the same default settings for every product? No. The default configuration has to be determined through the risk assessment for the specific product. What is secure by default for one product category may not be secure by default for another. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(3), Annex I Part I, point (2)(b) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.4 ## Does secure by default mean the product always has to ship in the most restrictive technically possible state? No. The CRA ties the default configuration to the product's intended purpose, reasonably foreseeable use, and the manufacturer's cybersecurity risk assessment. So the legal test is not whether the product is maximally locked down in the abstract, but whether its default configuration is secure for the way the product is meant and reasonably expected to be used. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2)-(3), Annex I Part I, point (2)(b) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.4 ## What kinds of settings or product states may need to be secure by default under the CRA? That depends on the product, but the CRA and Commission materials point toward defaults that reduce cybersecurity risk at first use. The Commission FAQ gives examples such as insecure or deprecated cryptographic algorithms being disabled by default, certificate validation being enabled by default, or network interfaces being disabled by default until needed. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I, points (2)(b), (2)(d), (2)(e), (2)(j), (2)(k) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.4 ## Does the secure-by-default requirement include a reset function? Yes. Annex I Part I, point (2)(b) expressly includes the possibility to reset the product to its original state. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I, point (2)(b) ## Does the CRA require automatic security updates to be enabled by default? Where applicable, yes. Annex I Part I, point (2)(c) says vulnerabilities must be addressable through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe and enabled as a default setting. That default setting must come with a clear and easy-to-use opt-out mechanism and the option to postpone updates temporarily. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I, point (2)(c) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## Can users turn off CRA automatic security updates? Yes. The CRA requires a clear and easy-to-use opt-out mechanism and an option to postpone updates temporarily. Annex II also requires instructions on how the default automatic-installation setting can be turned off. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I, point (2)(c), Annex II point 8(e), recital 56 ## Are CRA automatic security updates required for every product? No. Recital 56 says the automatic-update expectations do not apply to products primarily intended to be integrated as components into other products. It also says they do not apply to products for which users would not reasonably expect automatic updates, including products intended for use in professional ICT networks and especially in critical and industrial environments where automatic updates could interfere with operations. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 56, Annex I Part I, point (2)(c) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## If CRA automatic updates are not appropriate, does the manufacturer still have update obligations? Yes. Recital 56 says that irrespective of whether a product is designed to receive automatic updates, the manufacturer should inform users about vulnerabilities and make security updates available without delay. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 56, Annex I Part II, points (7) and (8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## If a user opts out of CRA automatic updates, is the manufacturer then compliant automatically? Not automatically, but the manufacturer is not responsible under the CRA for the user's refusal to install updates. The Commission FAQ says the manufacturer is not responsible if the user does not install security updates, including where the user opts out. But the manufacturer still must design the product and its processes so updates can be distributed, notified, and installed as required. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 6, Annex I Part I, point (2)(c), Annex I Part II, points (7) and (8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## How does CRA secure by default work for components sold for integration into other products? The component manufacturer is responsible for the configuration in which the component is placed on the market separately. The component manufacturer is not responsible for how an integrating manufacturer later reconfigures or deploys that component. The Commission FAQ gives this directly for products such as cryptographic libraries and microcontrollers sold for integration. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I, point (2)(b) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.4 ## Can a manufacturer rely on setup instructions instead of shipping the product in a secure default state? No. The CRA requires a secure-by-default configuration at placement on the market. The March 2026 draft guidance also says that information to users cannot be used to compensate for product-design shortcomings or to justify leaving incompatible risks untreated. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I, point (2)(b), Annex II - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 145-147 ## Can the secure-by-default requirement ever be inapplicable to a product? Yes, but only on a documented, risk-based basis. If the manufacturer concludes that a requirement is not applicable, Article 13(4) requires a clear justification in the technical documentation. The Commission FAQ says this can be the case where the requirement is incompatible with the nature of the product or where the risk assessment shows no relevant risks requiring that mitigation. But if the manufacturer still identifies cybersecurity risks in relation to that requirement, it has to address those risks by other means, for example by limiting the intended purpose to trusted environments or informing users about the risks. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3)-(4), recital 55 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.3 and 4.2.4 ## Is there any exception to the secure-by-default requirement? Yes, but it is narrow. Annex I allows deviation only where the product is tailor-made, fitted to a particular purpose for a particular business user, and the manufacturer and that user have explicitly agreed to different contractual terms. That exception does not create a general enterprise-product carve-out. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I, point (2)(b), recital 64 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 ## Are ordinary enterprise products or lightly customised products automatically "tailor-made" for this exception? No. The Commission FAQ says a product is not tailor-made merely because it undergoes minor customisations before sale. It gives examples such as a CRM platform sold to multiple businesses, or platforms customised through plugins or APIs while remaining fundamentally the same product for every customer. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 ## Does the tailor-made carve-out let the manufacturer deviate from any CRA requirement it wants? No. The Commission FAQ says the CRA allows deviation only from two essential requirements in this context: secure-by-default configuration in Annex I Part I point (2)(b), and the requirement to provide security updates free of charge in Annex I Part II point (8). It is not a general waiver from other Annex I requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I, point (2)(b), Annex I Part II, point (8), recital 64 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 ## If secure by default is not applicable because of the product's nature or interoperability needs, can the manufacturer simply omit equivalent safeguards? No. Where an essential cybersecurity requirement is not applicable but related cybersecurity risks still exist, the CRA materials say the manufacturer should address those risks by other means. The examples given are limiting the intended purpose to trusted environments or informing users about the risks. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(4), recital 55 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.3 ## What does the manufacturer need to document about secure by default? The manufacturer needs to document how the product complies with the relevant essential cybersecurity requirements, including the secure-by-default requirement where it applies. If the manufacturer concludes that the requirement is not applicable, that justification must be documented. If the manufacturer relies on the tailor-made exception, the technical documentation should also contain relevant evidence showing that the product is genuinely tailor-made. That matters because secure by default is not just a design aspiration. It forms part of the manufacturer's conformity case under Article 13(4) and Article 31. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(4), Article 31, Annex I Part I, point (2)(b) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.3 and 4.2.5 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Secure by Default as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Secure by Default into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Secure by Default and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/secure-by-default --- --- title: "CRA Security Updates vs Functionality Updates FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates" author: "Sorena AI" description: "CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA security updates FAQ" - "CRA functionality updates FAQ" - "CRA Annex I Part II point 2" - "CRA Article 13(10)" - "CRA free security updates" - "CRA substantial modification update" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" - "CRA security updates vs functionality updates FAQ" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Security Updates vs Functionality Updates FAQ CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Security Updates vs Functionality Updates Use this CRA FAQ to understand when security updates must be separated from functionality changes, when combined releases are allowed, and how update choices interact with Article 13(10) and substantial-modification analysis. Built for product, release, engineering, and compliance teams managing secure update strategies under the CRA. The CRA distinguishes between vulnerability remediation and broader functionality changes, but it does not ban every combined release. This FAQ explains when security updates must be provided separately, when combined releases are allowed, what Article 13(10) means for version support, and how update-related changes interact with substantial-modification analysis. ## Does the CRA require manufacturers to patch every vulnerability they discover during the support period? No. The CRA requires manufacturers to address and remediate vulnerabilities without delay in relation to the risks posed. The Commission FAQ explains that this does not mean every vulnerability must receive a dedicated patch. The response depends on the risk assessment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.1 ## If not every vulnerability needs a dedicated patch, what other remedies can satisfy the CRA? The Commission FAQ says remedies can take different forms depending on the risk. These can include immediate patches, advisories on workarounds, configuration guidance, updates to user manuals, later software updates, or other mitigation measures. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 4.3.4 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (2), Article 13(21) ## Must security updates be provided separately from functionality updates? Yes, where technically feasible. That is the rule in Annex I Part II point (2). Recital 57 explains that the purpose is to avoid forcing users to install functionality changes just to receive the latest security fix. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (2), recital 57 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.5 ## Why does the CRA push for separation between security and functionality updates? To improve transparency and to ensure users are not required to install new functionality updates for the sole purpose of receiving the latest security updates. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 57 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.5 ## Can a manufacturer still combine a security update with a functionality change? Yes, if separation is not technically feasible. The Commission FAQ gives the example of a vulnerability fix that requires replacing a parser with a safer one that changes some functionality. In that situation, the CRA does not require strict separation. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.5 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (2) ## Can a functionality change itself be the security fix? Yes. The Commission FAQ explains that disabling or changing a vulnerable function can itself be the security update. The key point is whether the change is needed to address the vulnerability. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.5 ## Must CRA security updates be disseminated without delay? Yes. Annex I Part II point (8) requires manufacturers to ensure that available security updates are disseminated without delay. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## Must CRA security updates be free of charge? Yes, unless otherwise agreed between the manufacturer and a business user for a tailor-made product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.2.5 and 4.3.3 ## Must CRA security updates come with user-facing guidance? Yes. When security updates are available to address identified security issues, they must be accompanied by advisory messages with the relevant information, including potential action users should take. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (8) ## Does the CRA require secure update-distribution mechanisms? Yes. Manufacturers must provide mechanisms to securely distribute updates so that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (7) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## Are CRA automatic security updates always required for every product? No. The CRA requires products, where applicable, to support automatic security updates with default enablement, an opt-out mechanism, notifications, and the option to postpone. Recital 56 and the Commission FAQ explain that automatic updates are not always applicable, especially for components and for products where users would not reasonably expect automatic updates, including some professional and industrial environments. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(c), recital 56 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## If CRA automatic updates are used, must users still be able to opt out or postpone installation? Yes. Annex I Part I point (2)(c) requires a clear and easy-to-use opt-out mechanism and the option to temporarily postpone updates. Recital 56 adds that users should retain the ability to deactivate automatic updates. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(c), recital 56 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## Is the manufacturer responsible under the CRA if a user refuses or fails to install a security update? No. The Commission FAQ states this directly. The manufacturer must make the update available through the required mechanisms and keep users informed, but is not responsible under the CRA if the user does not install the update. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(c), Annex I Part II points (7)-(8) ## If a vulnerability cannot be fixed adequately, can withdrawal or recall become necessary? Yes, in exceptional cases. Article 13(21) requires corrective measures to bring the product or the manufacturer's processes into conformity, or withdrawal or recall as appropriate. The Commission FAQ explains that this may become necessary where a serious vulnerability cannot be adequately remediated. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ## Even when CRA automatic updates are not applicable, must the manufacturer still inform users about vulnerabilities and make security updates available? Yes. Recital 56 states this expressly. Even where a product is not designed to receive automatic updates, the manufacturer should still inform users about vulnerabilities and make security updates available without delay. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 56 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## Must a manufacturer keep delivering security fixes for every historical version of a software product? Not always. Article 13(10) allows the manufacturer, under specific conditions, to ensure compliance with the remediation obligation only for the latest substantially modified version it has placed on the market. That is allowed only if users of the earlier versions can access that latest version free of charge and without additional costs to adjust their hardware or software environment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(10), recital 40 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.2 ## If earlier versions can move to the latest substantially modified version, does that end all obligations for the older versions? No. Recital 40 says the manufacturer may limit remediation to the latest substantially modified version only under the Article 13(10) conditions, but other vulnerability-handling obligations still continue for all subsequent substantially modified versions placed on the market. The same recital also says minor security or functionality updates that do not amount to a substantial modification may be provided only for the latest version or sub-version that has not been substantially modified. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(10), Annex I Part II points (5) to (8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.2 ## What if a hardware product cannot run the latest software version? The CRA does not let the manufacturer stop there. Recital 40 says that where a hardware product is not compatible with the latest version of the operating system it was originally delivered with, the manufacturer should continue to provide security updates at least for the latest compatible version for the support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 40 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.2 ## If a release is labelled a security update, does that automatically mean it is not a substantial modification? No. Recital 39 and the March 2026 draft guidance say security updates are generally not substantial modifications when they only reduce cybersecurity risk, do not change the product's intended purpose, and do not introduce new cybersecurity risks. But a security-driven change can still be substantial if it changes the intended purpose beyond what was originally foreseen or introduces new interfaces, dependencies, data flows, or other risks that were not covered in the original risk assessment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 39 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 101-102 ## Are later functionality updates automatically substantial modifications? No. The March 2026 draft guidance says later functionality updates are not substantial modifications just because they add or activate features. If the original risk assessment already foresaw those later functions, already assessed their risks, and already accounted for the needed mitigation measures, the later rollout should not be treated as a substantial modification. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 99 ## Can a small-looking feature update still become a substantial modification? Yes. Recital 39 and the March 2026 draft guidance both make clear that the scale of the feature is not the legal test. Even a limited update can be substantial if it modifies the original intended functions or type or performance of the product in a way that increases cybersecurity risk, or if it introduces new or increased risks that were not covered in the original risk assessment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 39 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 100 ## Does it matter for substantial-modification analysis whether the feature change was shipped separately or bundled with a security update? No. Recital 39 says that when assessing whether a feature update is a substantial modification, it is not relevant whether the feature update is provided separately or in combination with a security update. What matters is the effect on intended purpose and cybersecurity risk, not the packaging of the release. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 39 ## When Article 13(10) says users must not incur additional costs to move to the latest version, what does that cover? The March 2026 draft guidance says this should be interpreted practically and proportionately. Reasonable operational effort does not itself count as additional costs. The guidance gives examples such as personnel time, routine testing, configuration adjustments, and upgrades of underlying software dependencies that are necessary to address end-of-life components or known vulnerabilities. By contrast, additional costs mean burdens going beyond normal software maintenance, such as mandatory purchases of new hardware, infrastructure replacement, or fundamental changes to the operating environment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(10) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 118-120 ## If an update is not a substantial modification, can the manufacturer leave the CRA documentation unchanged? No. The March 2026 draft guidance says that regardless of whether a software update qualifies as a substantial modification, manufacturers remain responsible for the security of the update and of the product during the support period. It also says the cybersecurity risk assessment and technical documentation must remain accurate, complete, and continuously up to date. That aligns with Articles 13(7) and 31(2). Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Article 31(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 106 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Security Updates vs Functionality Updates as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Security Updates vs Functionality Updates into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Security Updates vs Functionality Updates and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates --- --- title: "CRA Substantial Modification FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/substantial-modification" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/substantial-modification" author: "Sorena AI" description: "CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA substantial modification FAQ" - "CRA Article 3(30)" - "CRA new manufacturer modification" - "CRA legacy products substantial modification" - "CRA software update substantial modification" - "CRA conformity reassessment" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Substantial Modification FAQ CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Substantial Modification Use this CRA FAQ to understand when software changes, repairs, refurbishments, or replacement parts become substantial modifications and what that changes for manufacturer status, conformity assessment, and legacy products. Built for product, engineering, repair, legal, and compliance teams assessing post-market changes under the CRA. The CRA does not treat every post-market change as a new product, but substantial modifications can trigger major legal consequences. This FAQ explains the Article 3(30) test, how software and repair changes are assessed, when a new conformity assessment is needed, and how substantial modification affects legacy products placed on the market before 11 December 2027. ## What is a substantial modification under the CRA? A substantial modification is a change made to a product with digital elements after it has been placed on the market that either affects compliance with the essential cybersecurity requirements in Annex I Part I or changes the intended purpose for which the product was assessed. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(30) ## Why does the concept of substantial modification matter so much? Because it changes who is treated as the manufacturer, whether a new conformity assessment may be needed, whether a modified product is treated as newly placed on the market, and whether pre-11 December 2027 products fall into the CRA after that date. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 21, Article 22, Article 69(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 86 ## Is every post-market change a substantial modification? No. The assessment is case by case. Repairs, maintenance, refurbishment, and ordinary updates do not necessarily amount to substantial modification. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 42 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 88-90 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.1 ## What is the core test for deciding whether a software update is a substantial modification? The key question is whether the update changes the product's intended purpose or introduces new or increased cybersecurity risks that were not foreseen and addressed in the original risk assessment, so that compliance with the essential requirements is affected. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(30), recital 39 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 96-97 ## If a manufacturer adds new functions that were not covered in the original risk assessment, is that likely to be a substantial modification? Yes. The draft guidance says that where new functionality changes the product's intended purpose or introduces risks not covered in the original risk assessment, the update will generally qualify as a substantial modification. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 98 and 100 ## If the original risk assessment already foresaw later functions, can those later activations avoid being substantial modifications? Yes. The draft guidance says that where the original risk assessment already covered the later functionality and its risks, and the appropriate mitigation measures were already built in, a later update implementing those foreseen functions should not be treated as a substantial modification. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 99 ## Can a small-looking feature change still be a substantial modification? Yes. The draft guidance says the scale of the feature is not the legal test. Even a limited change can be substantial if it introduces new risks or affects compliance with the essential requirements. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 100 ## Are security updates usually substantial modifications? No. The CRA recitals and the draft guidance both point the other way. A security update that only reduces cybersecurity risk and does not change intended purpose or introduce new risks is generally not a substantial modification. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 39 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 101 ## Can a security update still become a substantial modification? Yes. A security-driven change can still be substantial if it changes the product's intended purpose beyond what was originally foreseen or introduces new cybersecurity risks that were not covered in the original risk assessment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 39 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 102 ## What practical factors should manufacturers look at when assessing whether a software change is a substantial modification? The March 2026 draft guidance says manufacturers may consider whether the update: - introduces new threat vectors such as interfaces, communication channels, execution environments, or external dependencies - enables new attack scenarios - changes the likelihood of previously identified attack scenarios - changes the impact of previously identified attack scenarios Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 103 ## If a modification is a substantial modification, is the modified product treated as a new product? Yes. The draft guidance says a substantially modified product is treated as a new product for CRA purposes. Making that modified product available on the market is therefore a new placing-on-the-market event. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 107-108 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.1 ## Who becomes the manufacturer when a substantial modification is carried out? The person carrying out the substantial modification and making the modified product available on the market is treated as the manufacturer for CRA purposes. That can be the original manufacturer, an importer, a distributor, or another third party depending on the case. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 21, Article 22 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 108 ## If a third party substantially modifies a product but does not make the modified product available on the market, does Article 22 automatically make that person the CRA manufacturer? Not on that basis. Article 22(1) applies to a natural or legal person other than the manufacturer, importer or distributor that carries out a substantial modification and makes the modified product available on the market. So the CRA manufacturer trigger for those third parties is tied to both the substantial modification and a new making-available event. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 22(1) ## If only part of the product is affected, do the new manufacturer's obligations cover only that part? Sometimes. Article 22 says the person making the substantial modification is subject to the CRA obligations for the part affected by the modification or, if the modification affects the cybersecurity of the product as a whole, for the entire product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 22(2) ## Does a substantial modification trigger a new conformity assessment? Yes, where the modification affects compliance or changes intended purpose. The CRA recitals state that in such situations compliance should be verified again and, where applicable, the product should undergo a new conformity assessment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 41 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 107-110 ## Must the whole technical file and all tests be redone after a substantial modification? Not necessarily. The Blue Guide and the draft guidance both say unchanged parts can rely on existing tests and documentation. The updating work should focus on the parts affected by the substantial modification, but the person placing the modified product on the market remains responsible for the modified product's conformity. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.1 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 109-110 ## How does CRA substantial modification affect products placed on the market before 11 December 2027? A product placed on the market before 11 December 2027 falls under the CRA after that date only if it undergoes a substantial modification. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 111-113 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.4 ## If a pre-2027 product receives a non-substantial software update after 11 December 2027, does that alone make the product subject to the CRA? No. The Commission FAQ gives this directly. A post-2027 update that does not qualify as a substantial modification does not pull the legacy product into full CRA compliance. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.4 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2) ## Even where a software update is not a substantial modification, does the manufacturer still have CRA obligations during the support period? Yes. The draft guidance says that regardless of whether an update is substantial, manufacturers remain responsible for the security of updates and for keeping the risk assessment and technical documentation accurate, complete, and updated during the support period. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 106 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Article 31(2), Annex I Part II ## Is the legal definition of substantial modification tied to Annex I Part I or also to Annex I Part II? The legal definition itself is tied to Annex I Part I and intended purpose. Article 3(30) defines substantial modification by reference to a change that affects compliance with the essential cybersecurity requirements in Annex I Part I, or that changes the intended purpose for which the product was assessed. The draft guidance adds that, regardless of that qualification, the Annex I Part II vulnerability-handling obligations still continue during the support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(30) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 85 and 106 ## Does it matter for substantial-modification analysis whether a feature update was shipped separately or bundled with a security update? No. Recital 39 says that when assessing whether a feature update is a substantial modification, it is not relevant whether the feature update is provided separately or in combination with a security update. The legal question is the effect on intended purpose and cybersecurity risk, not the packaging of the release. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 39 ## If a later software iteration is not a substantial modification, does it trigger a new conformity assessment or a new placing-on-the-market date? No. The March 2026 draft guidance says later software iterations that do not qualify as substantial modifications do not require a new conformity assessment procedure and do not change the software product's date of placement on the market. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 15 and Example 2 ## Do importers and distributors become manufacturers under the same substantial-modification rule as other third parties? No. The CRA uses different provisions. Article 21 covers importers and distributors that carry out a substantial modification of a product already placed on the market. Article 22 covers other natural or legal persons, but only where they carry out the substantial modification and make the modified product available on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 21, Article 22 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 86 ## For a product placed on the market before 11 December 2027, should the manufacturer be able to show why a later update is not a substantial modification? Yes. The March 2026 draft guidance says manufacturers that did not apply the CRA when the product was first placed on the market must be able, on request from a market surveillance authority, to demonstrate that later updates do not constitute a substantial modification. The guidance adds that a cybersecurity risk assessment covering the Article 13(2) elements, with documented demonstration of compliance, should make that easier. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 112 ## If a product placed on the market before 11 December 2027 is later substantially modified, does the manufacturer then have to comply with the CRA in full? Yes. The draft guidance says that where a later update constitutes a substantial modification, the manufacturer must comply with the CRA in its entirety before placing the substantially modified product on the market, and then for the duration of that product's support period. The Commission FAQ illustrates the same result with the smart-TV example where a later update adds smart-home-control functionality. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 113 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.4 ## Does replacing a defective part with a better-performing part automatically count as a substantial modification? No. The March 2026 draft guidance says replacing defective or worn items with parts that perform better does not in itself trigger a substantial modification. It becomes substantial only if the change affects compliance with the essential requirements or changes the intended purpose that was covered by the original risk assessment. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 89-90 and Examples 29-30 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 42 ## If a replacement spare part is not identical to the original one, does that automatically mean the repaired product was substantially modified? No. The March 2026 draft guidance says a non-identical replacement part may itself be a product subject to the CRA, because it does not fall within the identical-spare-parts exemption in Article 2(6). But the repair of the host product still does not in itself amount to a substantial modification if the host product's intended purpose and cybersecurity risk profile remain unchanged. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 2(6), Article 3(30) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 91-94 and Example 32 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Substantial Modification as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Substantial Modification into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Substantial Modification and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/substantial-modification --- --- title: "CRA Support Period FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/support-period" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/support-period" author: "Sorena AI" description: "CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA support period FAQ" - "CRA Article 13(8)" - "CRA placing on the market support period" - "CRA standalone software support period" - "CRA update availability Article 13(9)" - "CRA support period legacy products" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Support Period FAQ CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Support Period Use this CRA FAQ to understand how support periods are set, when they start, how they work for hardware and standalone software, and how they differ from update-retention and documentation-retention duties. Built for product, legal, engineering, and compliance teams setting support-period policies and placement-on-the-market rules under the CRA. The CRA support period is a vulnerability-handling obligation tied to placing a product on the market, not simply a warranty or manufacturing date. This FAQ explains how Article 13(8) works, how support periods are set for physical products and standalone software, how later placements and substantial modifications affect timing, and how support periods interact with update availability, documentation retention, and legacy products. ## What is the CRA support period? The CRA defines the support period as the period during which the manufacturer must ensure that vulnerabilities of a product with digital elements are handled effectively and in line with Annex I, Part II. This obligation applies to the product in its entirety, including integrated components. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(20), Article 13(8), recital 34 ## Is the support period always five years? No. Five years is the minimum in normal cases, not the automatic answer for every product. The CRA says the support period must be at least five years unless the product is expected to be in use for less than five years. If the product is reasonably expected to remain in use for longer than five years, the support period should be longer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), recital 60 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 114-115 ## What factors must a manufacturer consider when setting the support period? The CRA requires manufacturers to consider: - reasonable user expectations - the nature of the product, including its intended purpose - relevant Union law determining the product's lifetime The CRA also allows manufacturers to take into account: - support periods of similar products - availability of the operating environment - support periods of third-party integrated components that provide core functions - guidance from ADCO and the Commission These factors must be applied proportionately. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.1 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 114 ## Does the CRA itself expressly say when the support period starts? Not in one sentence using the words "the support period starts on X date". But the combined reading of the CRA, the Commission FAQ, the draft guidance, and the Blue Guide points to placing on the market as the operative starting point. Why: - Article 13(8) requires vulnerability handling when placing the product on the market and for the support period. - Article 13(19) requires the end date to be disclosed at the time of purchase. - The Commission FAQ gives a hardware example counting from units placed on the market in January 2028 to January 2033. - The draft guidance gives an example of eight years from the date of placement on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), Article 13(19) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.3 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Example 46 ## Is the support period tied to a product type or to each individual unit? For physical products, it is tied to each individual product, not to the abstract model or type. The Blue Guide says placing on the market refers to each individual product, not to a type of product, whether it is manufactured individually or in series. The Commission FAQ then applies that logic to CRA support periods for hardware. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.5.3 and 7.2 ## If a manufacturer places more units of the same model on the market later, do the later units get their own support period? Yes. The Commission FAQ gives this directly. Units of a hardware model placed on the market in January 2028 with a five-year support period can remain supported until January 2033. If more units of the same model are placed on the market on 1 January 2030, the manufacturer must set the support period for those newly placed units too. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.3 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## Can units already placed on the market continue to be sold after their support period ends? Yes. The Commission FAQ says products already placed on the market can continue to be made available after the support period expires. But if new units of that product are placed on the market later, the manufacturer must set the support period for those newly placed units. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.3 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 2.2-2.3 ## Does the CRA support-period clock start on the manufacturing date? No. For physical products, manufacturing must be complete before placing on the market can happen, but manufacturing completion alone is not enough. There must also be a first supply for distribution or use on the Union market. For standalone software supplied digitally, the draft guidance also rejects manufacturing completion alone as enough. Placement occurs when the completed software is first supplied for distribution or use on the EU market. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 13-14 ## Does placing on the market require physical handover? No. The Blue Guide says placing on the market requires an offer or agreement for transfer of ownership, possession, or another property right after manufacturing is complete. It expressly says physical handover is not required. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## If the manufacturer first supplies the product to a distributor, is that the placing-on-the-market event? Usually yes. The Blue Guide says that when a manufacturer or importer first supplies a product to a distributor or an end-user, that first supply is placing on the market. Later transactions further down the chain are making available, not a new placing event. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## If a distributor later sells the same unit to the final customer, does that create a new support-period start date? No. Once that individual unit has already been placed on the market, later distributor-to-distributor or distributor-to-end-user transactions are only later instances of making the product available on the market. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.3 ## Does the support clock start on first installation, activation, commissioning, or first use? No. The CRA support-period logic is anchored to placing on the market, not first use. The Blue Guide treats placing on the market and putting into service as different concepts. The CRA materials on support periods use placing on the market as the reference point. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 2.3 and 2.6 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Example 46 ## Is putting into service the same thing as placing on the market for CRA support-period purposes? No. The Blue Guide treats them as distinct concepts. Some Union legislation uses both concepts, or treats own use as equivalent. The CRA support-period rules and the available Commission materials are built around placing on the market, not putting into service. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 2.3 and 2.6 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8) ## Does a product get placed on the market separately in each Member State? No. The Blue Guide says placing on the Union market can happen only once for each individual product across the EU and does not happen separately in each Member State. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## If a product is made only for the manufacturer's internal use, is that placing on the market? Generally no. The Blue Guide says placing on the market does not occur where a product is manufactured for one's own use, unless the relevant Union legislation also covers own use. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## If a product is offered or contracted before manufacturing is complete, has it already been placed on the market? No. The Blue Guide says an offer or agreement concluded before manufacture is finalised cannot be treated as placing on the market. Manufacturing must be complete first. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## What if the product is already manufactured and a direct customer order is confirmed for that specific unit for CRA placing-on-the-market purposes? That can be the placing-on-the-market event. The Blue Guide explains that for direct distance sales from outside the EU to an EU end user, the product is placed on the market when the order is placed and confirmed for a specific product that is already manufactured and ready to be shipped. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## How do warehouses, fulfilment centres, and distance selling affect placing on the market? They can change the answer. The Blue Guide says: - products offered online to EU end users are deemed made available if the offer targets the Union - but the actual placing-on-the-market event depends on the distribution chain - if products are shipped into the EU and stored with a fulfilment service provider for EU delivery, they are considered placed on the market when released for free circulation - if a specific already-manufactured product is sold directly from outside the EU to an EU end user, placement occurs when the order is placed and confirmed for that specific product Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 2.3-2.4 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.3 ## If products are in customs transit, free zones, temporary storage, or other special customs procedures, are they already placed on the EU market? No. The Blue Guide treats those situations as different from placing on the Union market. Compliance with Union product rules applies when the product is actually placed on the market. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## If an online offer targets EU end users, is the product automatically placed on the market at that point? Not always. The Blue Guide distinguishes between: - being deemed made available for market-surveillance purposes when the offer targets EU end users, and - the actual placing-on-the-market event for the individual product, which depends on the distribution chain So the targeted offer matters, but the placement date still depends on how that individual product reaches the EU market. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.4 ## What if the product is placed on the market but stays in the distribution chain for months before the final user receives it for CRA support-period purposes? That does not delay the placement date. The Commission FAQ recognizes this situation directly. A product may sit in the manufacturer's distribution branch, in fulfilment arrangements, or on a retailer shelf before reaching the user. It was still placed on the market earlier. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.3 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## If a known exploitable vulnerability is discovered after placement on the market but before the final user receives the product, must the manufacturer re-open the placement decision? No. The Commission FAQ says the Article 13(1) obligation to deliver products without known exploitable vulnerabilities applies at the moment of placement on the market. Once the product has already been placed on the market, the manufacturer is not expected to fix newly discovered vulnerabilities before the product reaches the final user. But the manufacturer still has vulnerability-handling obligations during the support period and may need to provide a security update as soon as the product is put into operation by its user. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(1), Article 13(8) ## For hardware sold together with software, should the support period be analyzed per hardware unit or per separate software delivery date? Usually per combined product, not by a separate software-delivery date. The draft guidance says that where software is necessary for the hardware to perform its intended functions, the hardware and that software together constitute the product placed on the market. The key question is not how or when the software is delivered, but whether it is necessary for the product's intended functions. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 19 and Examples 3-4 ## If a driver, app, or configuration tool is downloaded later through another channel, can it still be part of the same product? Yes, if it is necessary to operate, configure, control, or meaningfully use the device. The draft guidance expressly says necessary software remains part of the same product even if it is obtained later through an app store, a download link, or another digital channel after the hardware has already been placed on the market. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 19 and Examples 3-4 ## Does the standalone-software timing rule apply to software that is necessary for a hardware product to function? No. The draft guidance says the special rule for standalone software supplied digitally applies only to standalone software. It does not apply where software is supplied on physical media or where software forms part of a combined hardware-software product. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 16 and 19 ## How is standalone software placed on the market if it is supplied digitally? Current Commission draft guidance says a standalone software product supplied digitally should be considered placed on the market when: - its manufacturing phase is complete, and - that software is first supplied for distribution or use on the EU market in the course of a commercial activity Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 13-14 ## For standalone software, does each later download create a fresh support-period clock? Current Commission draft guidance says no. The draft says all copies of the same unchanged version are considered placed on the market at the same time, namely when that version is first offered on the EU market. Later downloads or remote access to that unchanged version are later instances of making it available. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 13-15 and Examples 1-2 ## If standalone software receives a minor update that is not a substantial modification, does that reset the support-period clock? No. The draft guidance says iterations that do not qualify as substantial modifications do not require a new conformity assessment and do not modify the software's placement date. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 15 and Example 2 ## If a software product is substantially modified, does that create a new placing-on-the-market event and a new support-period determination? Yes. Where a modification qualifies as a substantial modification, the modified product is treated as a new product for CRA purposes. That means a new placing-on-the-market event and a new support-period determination for that substantially modified version. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(30), recital 41 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 113, 117, and 120 ## For continuously evolving software, does each substantially modified version need its own declared support period? Current Commission draft guidance says yes. The draft guidance says each substantially modified version placed on the market must have a declared support period that complies with Article 13(8). Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 117 and Example 47 ## Can a manufacturer stop patching earlier substantially modified software versions once a later version exists? Sometimes, but only within the conditions of Article 13(10). If the manufacturer has placed subsequent substantially modified versions of a software product on the market, it may comply with the remediation obligation in Annex I, Part II, point (2) only for the latest placed version, provided that users of earlier versions can access the latest version: - free of charge - without additional costs to adjust their hardware or software environment This does not remove the manufacturer's other vulnerability-handling obligations for the support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(10), recital 40 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 118-120 ## If a hardware product cannot run the newest operating-system version, can the manufacturer stop supporting that hardware? Not automatically. Recital 40 says that where a hardware product is not compatible with the latest version of the operating system it was originally delivered with, the manufacturer must continue to provide security updates at least for the latest compatible version for the support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 40 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Example 46 ## Can the support period ever be less than five years? Yes, but only where the product is expected to be in use for less than five years. This is an exception, not a business preference. The Commission materials give examples such as a contact-tracing application for a pandemic and some software that is no longer available and no longer in use once a subscription expires. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), recital 60 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 115 ## Is five years a safe default for long-lived products if a manufacturer wants one simple rule? No. The Commission FAQ and the draft guidance both say five years is only a safeguard. It is not the default for products reasonably expected to be used longer. The Commission materials specifically mention longer-lived hardware components, network devices, software such as operating systems or video-editing tools, and industrial systems. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 60 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 115 ## Can the support period be defined solely by the support period of a key integrated component? No. The support period of integrated core components is only one factor the manufacturer may take into account. It does not automatically cap the manufacturer's support obligation for the finished product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.7 and 4.5.1 ## What if an integrated component's support period ends before the finished product's support period ends? The finished-product manufacturer still remains responsible for the finished product. The Commission FAQ says the finished product must comply in its entirety during its own support period. If an integrated component is no longer supported and a vulnerability cannot be adequately handled by mitigations, the manufacturer of the finished product may need to switch out the component, develop a patch itself, disable compromised functions, or otherwise remediate by other means. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 34, Article 13(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.6 and 4.3.7 ## Does the support period cover only the manufacturer's own code, or also integrated components? It covers the product in its entirety, including integrated components. The CRA and the Commission FAQ are explicit on this point. The manufacturer must handle vulnerabilities affecting the whole product, including vulnerabilities found in integrated third-party components. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 34, Article 13(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.6 ## If the integrated component was placed on the market separately under the CRA, can the finished-product manufacturer rely on the component manufacturer's support? Partly, but not completely. The Commission FAQ says the finished-product manufacturer may benefit from the component manufacturer's own CRA obligations, for example where the component manufacturer develops a security update. But the finished-product manufacturer still remains responsible for its own product's compliance and vulnerability handling. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(5)-(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.6 ## If the integrated component was never placed on the market, or was placed before the CRA applies, does that remove the finished-product manufacturer's obligations? No. The Commission FAQ says that even where the component maker is not subject to CRA vulnerability-handling obligations, the integrating manufacturer must still ensure its own product complies in its entirety and must remediate vulnerabilities by other means if necessary. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.6 and 4.3.7 ## What must be disclosed to users about the support period? The manufacturer must clearly and understandably specify the end date of the support period, at least month and year, at the time of purchase, in an easily accessible manner. Where appropriate, this may also be shown on the product, the packaging, or by digital means. Where technically feasible, the manufacturer must also notify users when the product has reached the end of its support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(19), recital 56 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 116 ## Must the manufacturer document how it determined the support period? Yes. The CRA requires the manufacturer to include in the technical documentation the information taken into account to determine the support period. Annex VII expressly requires this information. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), Article 31, Annex VII point 4 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.1 ## Must the technical documentation already exist when the product is placed on the market? Yes. The CRA requires the technical documentation to be drawn up before placement on the market and to be continuously updated where appropriate, at least during the support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12), Article 31(1)-(2) ## Must technical documentation and user instructions be kept after placement on the market, and is that the same as the support period? They must be kept, but this is a separate retention rule. The CRA says technical documentation and the EU declaration of conformity must be kept for at least 10 years after placement on the market or for the support period, whichever is longer. It applies the same 10-years-or-support-period rule to user instructions and their online availability. This does not mean the support period is always 10 years. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(13), Article 13(18) ## Must each CRA security update remain available after it is issued? Yes. This is a separate rule from the length of the support period itself. Each security update made available during the support period must remain available for at least 10 years after issuance or for the remainder of the support period, whichever is longer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(9) ## If the CRA support period is five years, can update availability still last longer than five years? Yes. Article 13(9) is separate from Article 13(8). A product might have a five-year support period, but updates issued during that period may still need to remain available for longer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8)-13(9) ## What happens to products placed on the market before 11 December 2027? As a rule, they are subject to the CRA only if they undergo a substantial modification on or after 11 December 2027. Article 14 reporting obligations are the main express exception and apply more broadly. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2)-(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.4 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 111-113 ## If a manufacturer developed a product type before 11 December 2027, can it keep producing identical new units after that date without CRA compliance? No. The Commission FAQ says the CRA applies to individual units placed on the market after the application date. Old product types or models are not grandfathered for newly placed units. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.2 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## If units of a pre-CRA product were already placed on the market before 11 December 2027 but are still in the channel afterward, do they have to be retrofitted to CRA requirements? Generally no. If those units were already placed on the market before 11 December 2027, they are not subject to the CRA cybersecurity requirements merely because they remain in distribution afterward, unless they are substantially modified. Reporting obligations are the main exception. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2)-(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 1.4 and 7.2 ## Do reporting obligations still apply to products placed on the market before 11 December 2027? Yes. Article 69(3) makes Article 14 apply to in-scope products placed on the market before that date as well. The Commission FAQ says manufacturers must notify actively exploited vulnerabilities and severe incidents for those legacy products even though other CRA obligations may not apply to them. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 5.3 ## Can software sold on a subscription basis ever have a support period below five years? Yes. The CRA and the Commission FAQ allow support periods below five years where the product is genuinely expected to be in use for less than five years. Recital 60 gives software that becomes unavailable and no longer in use once the subscription expires as an example of that kind of case. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), Article 13(19), recital 60 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 115 ## What is the cleanest practical rule for manufacturers when determining the CRA support period? Use this rule set: - For physical products, including hardware plus software that is part of that product, determine the support period at the level of each individual unit when that unit is first placed on the EU market. - Do not use manufacturing date as the support-period start date. - Do not use later distributor sale, activation, installation, or first use as the support-period start date. - Treat stock already in the distribution chain as already placed if the first EU supply event has already occurred. - For direct online sales, determine the placement date from the actual distribution model, not from marketing language alone. - For standalone software delivered digitally, the current Commission draft guidance points to the first EU offering of the unchanged version as the placement date. - If a software or product change is a substantial modification, treat the modified product as a new product with a new placement event and a new support-period determination. - Track component support periods, but do not treat them as automatic caps on the finished product's support period. - Track Article 13(9) separately: each security update issued during the support period must remain available for at least 10 years after issuance or for the remainder of the support period, whichever is longer. - Record in the technical documentation exactly what factors were used to justify the support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8)-13(10), Article 13(19) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.2.3, 4.5.1, 4.5.3, 7.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 13-19 and 114-120 - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 2.3-2.4 ## Can a product be placed on the market even if it is supplied free of charge or under loan, hire, lease, or gift arrangements? Yes. The Blue Guide says the transfer can be for payment or free of charge and gives sale, loan, hire, leasing, and gift as examples. What matters is the first making available on the Union market after manufacture is complete. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 2.2-2.3 ## Does repeated renting or leasing of the same unit create a new placing-on-the-market event each time? No. The Blue Guide says repeated renting of the same product does not create a new placing-on-the-market event. The relevant compliance moment remains the first placing-on-the-market event for that unit. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## Is a transfer from a third-country manufacturer to its authorised representative in the Union a placing-on-the-market event? No. The Blue Guide expressly says placing on the market does not take place where a product is transferred from the manufacturer in a third country to an authorised representative in the Union engaged to help ensure compliance. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## Are products that are still in the manufacturer's, authorised representative's, or importer's stock already placed on the market? No, not if they have not yet been supplied for distribution, consumption, or use. The Blue Guide says products in those stocks are not yet placed on the market where they are not yet made available. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## Are trade-fair, exhibition, demonstration, or pre-production test units automatically considered placed on the market? No. The Blue Guide says products displayed or operated under controlled conditions at trade fairs, exhibitions, or demonstrations are not placed on the market. The same is true for transfers for testing or validating pre-production units that are still in the stage of manufacture. Sources for this answer: - [Blue Guide 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## Is the support period the same thing as a product's abstract lifetime or physical durability? No. Under the CRA, the support period is a cybersecurity support obligation: it is the period during which vulnerabilities must be handled effectively. It is not simply another label for abstract product lifetime, physical durability, or a general commercial warranty period. But the manufacturer must set the support period so that it reflects how long the product is expected to be in use. Expected use and product lifetime therefore matter because they are inputs into the support-period decision. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), Article 3(20) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.6 and 4.5.1 ## Does the expected-use analysis affect only the support period, or also the cybersecurity risk assessment? It affects both. Article 13(3) requires the cybersecurity risk assessment to take into account the length of time the product is expected to be in use. The Commission FAQ then links that same expected-use analysis to the support period under Article 13(8). Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(3), Article 13(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.6 ## Must the manufacturer think about expected use and lifetime already at the design and development stage? Yes. The Commission FAQ says the manufacturer should consider the product's lifetime during design and development and prepare the product so that vulnerabilities, including component vulnerabilities, can be handled effectively throughout the support period. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.6 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), Annex I Part II ## If the risk assessment depends on user instructions or operating assumptions, must those materials be updated during the support period? Yes, where appropriate. The CRA requires the risk assessment to be documented and updated where appropriate during the support period. The Commission FAQ adds that where the risk assessment relies on information and instructions to users to address certain risks, those materials should be updated accordingly. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Article 31(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.6 ## Can relevant Union law affect the support period even if the manufacturer would otherwise choose a shorter period? Yes. Article 13(8) expressly requires the manufacturer to take into account relevant Union law determining the lifetime of products with digital elements. So the support-period analysis is not based only on internal policy or market preference. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.1 ## What happens if a manufacturer stops operating before the support period ends? The CRA does not let the manufacturer stay silent. If a manufacturer ceases operations and therefore cannot comply with the CRA, it must inform the relevant market surveillance authorities before the cessation takes effect and must also inform users of the affected products, by any available means and to the extent possible. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(23) ## Can market surveillance authorities review whether a manufacturer's support period is too short? Yes. The CRA says market surveillance authorities must monitor how manufacturers applied the Article 13(8) criteria when determining support periods. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 52(16) ## Will there be public CRA support-period benchmarks by product category? Yes. The CRA says ADCO must publish relevant statistics on categories of products with digital elements, including average support periods determined by manufacturers, and provide guidance with indicative support periods for product categories. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 52(16) ## Can the Commission later set minimum support periods for specific product categories? Yes. Article 13(8) allows the Commission to adopt delegated acts specifying minimum support periods for specific product categories where market-surveillance data suggests inadequate support periods. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8) ## Can the manufacturer disclose the support period only as "five years from purchase" or another relative formula instead of a fixed end date? No. Article 13(19) requires the end date of the support period to be specified at the time of purchase, including at least the month and year. So the disclosure has to give users an actual end date, not only a relative formula such as "five years from purchase" or "five years from activation". Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(19) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 116 ## Must the manufacturer simply set the support period equal to the expected use time in every case? No. Article 13(8) says the support period must reflect the length of time during which the product is expected to be in use, but the January 2026 Commission FAQ adds that manufacturers are not expected to apply that as a simple one-factor shortcut. Except where the expected use time is less than five years, the manufacturer must determine the support period by taking the Article 13(8) criteria into account proportionately. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.1 ## If the product is genuinely expected to be in use for less than five years, must the manufacturer still weigh the other Article 13(8) factors to set a longer support period? No. The January 2026 Commission FAQ says that where the product is expected to be in use for less than five years, the support period must correspond to that expected use time without further consideration of the other criteria listed in Article 13(8). That is the CRA's specific exception to the normal five-year minimum. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), recital 60 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.2 ## Do ADCO averages or indicative support periods automatically become binding legal minimums? No. Article 52(16) says ADCO publishes statistics, including average support periods, and guidance with indicative support periods for product categories. Those are not themselves the same thing as binding minimum support periods. Binding category-specific minimums arise only if the Commission later adopts a delegated act under Article 13(8). Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), Article 52(16) ## What if free and open-source software placed on the market is monetised only through paid support subscriptions? The January 2026 Commission FAQ treats that as a specific support-period scenario. The FAQ says that some free and open-source software placed on the market may be monetised only through paid support services offered on a subscription basis. Because that software may remain in use after the user stops paying for support, the FAQ says the manufacturer is required to ensure a support period equal to the duration of the active subscription. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.5.2 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), recital 60 ## Can Article 13(10) leave an earlier substantially modified software version with a shorter effective support period than a later one? Yes. The March 2026 draft guidance says that for continuously evolving software, the manufacturer may rely on Article 13(10) to stop addressing and remediating vulnerabilities for earlier substantially modified versions once users can upgrade to a later version free of charge and without additional costs. The guidance expressly notes that this may result in a shorter effective support period for those earlier versions, while the other vulnerability-handling obligations still continue. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(10), recital 40 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 118-120 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Support Period as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Support Period into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Support Period and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/support-period --- --- title: "CRA Tailor-Made Products FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/tailor-made-products" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/tailor-made-products" author: "Sorena AI" description: "CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA tailor-made products FAQ" - "CRA recital 64" - "CRA business user exception" - "CRA paid security updates tailor-made" - "CRA secure by default tailor-made" - "CRA explicit contractual terms" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Tailor-Made Products FAQ CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Tailor-Made Products Use this CRA FAQ to understand the narrow tailor-made carve-out, which CRA requirements it affects, what evidence is needed, and why ordinary B2B products usually do not qualify. Built for legal, product, sales, and compliance teams assessing whether a business-specific offering can genuinely qualify as tailor-made under the CRA. The CRA contains a narrow carve-out for genuinely tailor-made products fitted to a particular purpose for a particular business user under explicit different contractual terms. This FAQ explains what that carve-out changes, what it does not change, and why ordinary enterprise products, minor customisations, and standard support contracts usually do not qualify. ## What is a tailor-made product under the CRA? The CRA does not create a broad general definition section for tailor-made products, but recital 64 and the Commission FAQ give the working test. A tailor-made product is a product with digital elements fitted to a particular purpose for a particular business user, where the manufacturer and that business user have explicitly agreed different contractual terms. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 64, Annex I Part I point (2)(b), Annex I Part II point (8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 ## Which CRA requirements can be deviated from for a tailor-made product? Only two essential requirements are expressly subject to the tailor-made carve-out: - secure-by-default configuration in Annex I Part I point (2)(b) - free-of-charge dissemination of security updates in Annex I Part II point (8) The carve-out does not remove the rest of the CRA. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part I point (2)(b), Annex I Part II point (8), recital 64 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 ## Does a tailor-made product escape the CRA's general risk-assessment and security obligations? No. The manufacturer still has to comply with the CRA generally, including the cybersecurity risk assessment, technical documentation, conformity assessment, and the other applicable Annex I requirements. The tailor-made carve-out is limited to the two expressly identified requirements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 6, Article 13(1)-(4), Annex I - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 ## Can a consumer product be treated as tailor-made under the CRA tailor-made carve-out? Not on the terms set out in recital 64 and Annex I. The CRA carve-out is framed around a manufacturer and a business user agreeing different contractual terms. That makes this a business-user exception, not a consumer-product exception. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 64, Annex I Part I point (2)(b), Annex I Part II point (8) ## Is an enterprise product automatically tailor-made just because it is sold B2B? No. A B2B product is not tailor-made merely because the customer is a business. The product must be fitted to a particular purpose for a particular business user, and the parties must explicitly agree different contractual terms. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 64 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 ## Do minor customisations, plugins, APIs, or standard configuration options make a product tailor-made? No. The Commission FAQ says a product is not tailor-made where it undergoes minor customisations before sale without specific contractual terms or arrangements. It gives examples such as CRM platforms sold to multiple businesses and platforms that allow customisation through plugins or APIs while remaining fundamentally the same product for every customer. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 ## What kinds of products may qualify as tailor-made? The Commission FAQ gives examples such as custom-developed hardware or software built for the needs of a specific business user, or products developed for integration into a specific customer's highly controlled environment, such as a closed or air-gapped environment, where specific contractual terms apply. That does not create an automatic rule for all closed or industrial environments. The particular-purpose, particular-business-user, and explicit-contract criteria still have to be met. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 64 ## Does deployment in a closed, air-gapped, or otherwise highly controlled environment automatically make a product tailor-made? No. The Commission FAQ gives such environments only as examples of cases that may qualify where the product is developed for integration into a specific customer's environment and specific contractual terms apply. The environment by itself does not satisfy the CRA test. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 64 ## Must the CRA tailor-made contractual deviation be explicit? Yes. Recital 64 and the Commission FAQ both say the manufacturer and the business user must explicitly agree a different set of contractual terms. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 64 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 ## Can a manufacturer charge for security updates for a tailor-made product? Yes, but only because Annex I Part II point (8) allows deviation for tailor-made products where the manufacturer and a business user have otherwise agreed. Without that explicit tailor-made agreement, security updates addressing identified security issues must be disseminated free of charge. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (8), recital 64 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 ## Can a tailor-made product ship without a secure default configuration? It can deviate from the secure-by-default requirement only within the tailor-made carve-out. That means the deviation must be tied to the particular-purpose, particular-business-user, and explicit-contractual-terms conditions. It does not remove the manufacturer's broader obligation to place a compliant product on the market under the CRA. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 6, Annex I Part I point (2)(b), recital 64 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 ## What documentation should a manufacturer keep to support a CRA tailor-made classification? The Commission FAQ says the manufacturer is expected to include in the technical documentation all relevant data or details showing compliance with the applicable essential requirements, including appropriate evidence that the product is tailor-made. That means the documentation should support the particular-purpose, particular-business-user, and explicit-contractual-deviation elements. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(4), Annex VII - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 ## Do tailor-made products still need to give users the required information and instructions? Yes. The CRA does not create a general Annex II exemption for tailor-made products. Manufacturers still need to comply with Article 13(18) and provide the required information and instructions to the user, unless a specific CRA provision says otherwise. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(18), Annex II ## Does a tailor-made agreement let the manufacturer stop providing security updates altogether? No. The tailor-made carve-out does not remove the CRA's general vulnerability-handling regime. It only allows deviation from the free-of-charge element of Annex I Part II point (8) where the tailor-made conditions are met. The manufacturer still remains subject to the broader CRA obligations, including handling vulnerabilities during the support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), Annex I Part II point (8), recital 64 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 ## If security updates are paid for under a valid tailor-made agreement, must they still be disseminated without delay and accompanied by advisory messages? Yes. Annex I Part II point (8) still requires security updates to be disseminated without delay and accompanied by advisory messages with the relevant information, including potential action users should take. The tailor-made exception changes the free-of-charge requirement where otherwise agreed, but it does not remove those other parts of point (8). Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.2.5 and 4.3.3 ## Are generic enterprise terms, negotiated pricing, or a support contract by themselves enough to make a product tailor-made? No. Inference from the CRA text and the Commission FAQ: the material requires more than the existence of a commercial contract. The product must be fitted to a particular purpose for a particular business user, and the parties must explicitly agree a different set of contractual terms. The FAQ's negative examples show that ordinary multi-customer business products with only minor customisation do not become tailor-made on that basis alone. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 64 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 ## If the same fundamentally unchanged product is sold to multiple business users with only customer-specific setup or configuration, is that enough for the CRA tailor-made exception? No, not on that fact alone. Inference from the Commission FAQ: where the product remains fundamentally the same product for every customer, the tailor-made exception does not apply merely because each customer has its own configuration, plugin set, API use, or minor pre-sale customisation. The CRA materials point the other way unless the product is genuinely fitted to a particular purpose for a particular business user under explicit different contractual terms. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.2.5 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 64 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Tailor-Made Products as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Tailor-Made Products into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Tailor-Made Products and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/tailor-made-products --- --- title: "CRA Technical Documentation FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/technical-documentation" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/technical-documentation" author: "Sorena AI" description: "CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA technical documentation FAQ" - "CRA Annex VII" - "CRA Article 31" - "CRA technical file language" - "CRA authority access documentation" - "CRA technical documentation updates" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Technical Documentation FAQ CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Technical Documentation Use this CRA FAQ to understand what Annex VII requires, when technical documentation must exist, how it must be kept up to date, and what authorities or notified bodies may request. Built for compliance, engineering, certification, and legal teams preparing and maintaining CRA technical files. CRA technical documentation is the evidence package behind the manufacturer's conformity case. This FAQ explains what Annex VII requires, when the documentation must exist, how it must be updated during the support period, when documentation can be reused across products or laws, and how language and authority-access rules work in practice. ## What is CRA technical documentation? CRA technical documentation is the evidence package that shows how the manufacturer ensured that the product and the manufacturer's processes comply with the applicable essential cybersecurity requirements. It must contain all relevant data or details of the means used by the manufacturer to ensure compliance and must at least contain the elements listed in Annex VII. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31(1), Annex VII - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.6 ## When does the technical documentation have to exist? It must be drawn up before the product is placed on the market. It must then be continuously updated, where appropriate, at least during the support period. The Commission FAQ adds that it has to be available when the product is placed on the market, regardless of where it is physically stored. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12), Article 31(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ## What has to be in the technical documentation? Annex VII requires, as applicable: - a general description of the product, including intended purpose, compliance-relevant software versions, hardware images or illustrations where relevant, and user information and instructions - a description of design, development, production, and vulnerability handling processes - the cybersecurity risk assessment and applicability of Annex I Part I requirements - the information used to determine the support period - the list of harmonised standards, common specifications, or certification schemes applied, and descriptions of alternative solutions where they were not applied - test reports - a copy of the EU declaration of conformity - where applicable, the software bill of materials Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VII ## Does the technical documentation have to include the cybersecurity risk assessment? Yes. Article 13(4) requires the manufacturer to include the cybersecurity risk assessment in the technical documentation when placing the product on the market. The same provision also requires a clear justification where certain essential cybersecurity requirements are not applicable to the product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(4), Annex VII point 3 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ## Does the technical documentation have to explain the support period and software versions? Yes. Annex VII expressly requires: - versions of software affecting compliance with essential cybersecurity requirements - relevant information taken into account to determine the support period under Article 13(8) Those are not optional extras. They are part of the minimum CRA documentation set where applicable. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VII points 1(b) and 4 ## How must CRA technical documentation deal with harmonised standards, common specifications, and alternative solutions? The technical documentation must identify the harmonised standards, common specifications, and relevant certification schemes used in full or in part. Where they were not applied, the documentation must describe the solutions adopted to meet the essential requirements and list any other relevant technical specifications used. If they were applied only in part, the documentation must specify which parts were applied. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex VII point 5 ## Can one set of technical documentation cover more than one EU product law? Yes, where Article 12 applies. For CRA products that are also subject to other Union legal acts requiring technical documentation, Article 31(3) allows a single set of technical documentation containing both the CRA information and the information required by those other acts. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31(3) ## Can the technical documentation be part of the module H quality-system documentation? Yes. The Commission FAQ says technical documentation may form part of the quality-system documentation where the manufacturer uses a quality-system-based conformity assessment route such as module H. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31, Annex VIII Part IV point 3.1(b) ## In what language can the technical documentation be written? Article 31(4) says the technical documentation and correspondence relating to a conformity assessment procedure must be drawn up in an official language of the Member State in which the notified body is established or in a language acceptable to that body. The Commission FAQ adds that the technical documentation can be written in any language, but if a market surveillance authority requests it, it needs to be provided in a language easily understood by that authority. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31(4), Article 13(22), Article 53 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.6 ## Does the technical documentation have to be public or customer-facing? No, as a rule it does not. The Commission FAQ states that there is no general obligation to make the technical documentation available to customers or the public. The specific CRA exception is Article 32(5), where a manufacturer of qualifying free and open-source software in an Annex III category relies on the CRA's special Article 32(5) rule and therefore has to make the technical documentation public at the time of placing on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 32(5) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.6 ## What can CRA market surveillance authorities request beyond the core technical-documentation file? Manufacturers must, on reasoned request, provide authorities with the information and documentation necessary to demonstrate conformity. Article 53 goes further and says authorities may be granted access to the data needed to assess design, development, production, and vulnerability handling, including related internal documentation. For SBOMs, the CRA does not require public release, but Annex VII and Annex I make them part of the documentation framework and market surveillance authorities may request them where necessary to check compliance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(22), Article 53, Annex I Part II point 1, Annex VII points 2(b) and 8, recital 77 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ## Does the technical documentation have to be updated when the product changes? Yes. Article 31(2) requires continuous updating where appropriate, at least during the support period. The March 2026 draft guidance adds that technical documentation must remain accurate, complete, and up to date even where updates do not amount to substantial modifications. For substantial modifications, the draft guidance, relying on the Blue Guide, says the documentation has to be updated to the extent the modification affects the applicable requirements, and unchanged aspects do not need to be retested or redocumented. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31(2) - [Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.3 and section 2.1 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 106, 109-110 ## Do products designed before the CRA applied need full historic design records recreated? Not necessarily. The March 2026 draft guidance says that for products designed before the CRA's application date, the obligation to provide evidence in the conformity assessment should not be read as requiring the manufacturer to recreate original design and development test evidence where that would not improve the product's security. The manufacturer still has to demonstrate current compliance through the cybersecurity risk assessment and technical documentation. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12), Article 31, Annex VII point 6 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 34-35 ## Is there a simplified technical documentation format for smaller companies? Yes. Article 33(5) says microenterprises and small enterprises may provide the Annex VII elements using a simplified format once the Commission specifies that form by implementing act. Notified bodies must accept that form for conformity assessment purposes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 33(5) ## Does the CRA require one fixed template for technical documentation? No. The CRA prescribes what the technical documentation must contain, mainly through Annex VII, but it does not impose one mandatory template or filing structure. What matters is that the file contains the required content and is clear enough to let a notified body or market surveillance authority assess conformity. In practice, that means the manufacturer has flexibility in how the file is organised, but not in whether the required elements are actually present and kept up to date. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31, Annex VII - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.6 ## Does the technical documentation need to distinguish product versions and redesigns? Yes. The Commission FAQ says that where a product has been redesigned or reassessed, the technical documentation must reflect all versions of the product, describe the changes made, explain how the versions can be identified, and include information on the relevant conformity assessment. That matters in practice because the CRA documentation is meant to remain usable throughout the product's life. A manufacturer cannot keep only the newest file if that makes it impossible to tell which documentation applies to which version placed on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31(2), Annex VII point 1 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 - [Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 4.3 ## Can a manufacturer automatically use one technical-documentation set for every product variant in a family? Not automatically. The March 2026 draft guidance allows a single set of technical documentation where the variants share the same architecture, security-relevant design, intended purpose, and cybersecurity risks, and where all relevant risks and essential requirements are adequately covered. If differences between variants affect cybersecurity properties, those differences must be reflected in the technical documentation and, where necessary, the conformity assessment. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 158-161 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31, Annex VII ## If the same remote data processing solution supports several products, can the related documentation be reused? Yes, but each product still needs its own declaration of that reliance. The March 2026 draft guidance says manufacturers should indicate in the technical documentation that the product has RDPS or relies on relevant third-party cloud solutions, and describe those solutions. If the same RDPS supports several products, the RDPS must be declared in each product's technical documentation, even though the RDPS documentation itself may be reused across product conformity assessments. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 188 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31, Annex VII ## Does the fact that technical documentation is not generally public mean authorities are limited to the Annex VII file only? No. The January 2026 Commission FAQ and Article 53 make clear that, where necessary to assess conformity, market surveillance authorities may be granted access to the data needed to assess design, development, production, and vulnerability handling, including related internal documentation of the relevant economic operator. So the non-public character of the technical documentation does not cap authority access at the bare Annex VII file. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 53 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.8 and 6.6 ## Can a manufacturer keep CRA technical documentation split across different internal systems or suppliers, as long as the full set can be produced? Yes, in principle. Inference from the CRA text and Commission FAQ: the legal requirement is that the technical documentation be drawn up, contain the required Annex VII content, be available when the product is placed on the market, and be provided to authorities on reasoned request. The CRA does not prescribe one storage location or one physical dossier, but the manufacturer remains responsible for being able to assemble and provide a coherent, complete set when needed. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12), Article 13(22), Article 31(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.8 and 6.6 ## If a notified body accepts one language for CRA conformity-assessment documentation, does that automatically settle the language issue for market-surveillance requests? No. Article 31(4) deals with the language of technical documentation and correspondence relating to a conformity assessment procedure, especially for notified-body interactions. Separately, Article 13(22) requires manufacturers to provide the necessary information and documentation to market-surveillance authorities in a language that can be easily understood by the requesting authority. The Commission FAQ makes the same distinction. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 31(4), Article 13(22) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.6 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Technical Documentation as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Technical Documentation into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Technical Documentation and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/technical-documentation --- --- title: "CRA Transition Period FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/transition-period" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/transition-period" author: "Sorena AI" description: "CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA transition period FAQ" - "CRA 11 December 2027" - "CRA 11 September 2026" - "CRA legacy products transition" - "CRA pre-existing certificates" - "CRA standalone software transition" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Transition Period FAQ CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Transition Period Use this CRA FAQ to understand the phased application dates, what happens to legacy products, how stock and customs situations are treated, and when standalone software or later versions become newly placed on the market. Built for legal, product, certification, and compliance teams planning CRA readiness across the 2026 to 2027 transition window. The CRA does not switch on all at once: notified-body rules start first, reporting starts earlier than the main application date, and legacy products are treated differently from products first placed on the market after 11 December 2027. This FAQ explains the phased dates, stock and customs edge cases, standalone software timing, and how earlier certificates and sectoral regimes fit into the transition. ## When did the CRA enter into force? The CRA entered into force on 10 December 2024. The Regulation itself says it enters into force on the twentieth day following its publication in the Official Journal. The Commission FAQ uses the concrete date 10 December 2024. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 71(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 7.1 and 7.2 ## When does the CRA generally start applying? The CRA generally applies from 11 December 2027. But the Regulation also has two earlier phased dates: - Chapter IV, covering the notification of conformity assessment bodies, applies from 11 June 2026 - Article 14 reporting obligations apply from 11 September 2026 Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 71(2) ## What starts under the CRA on 11 June 2026? Chapter IV of the CRA starts to apply on 11 June 2026. That chapter covers notifying authorities and conformity assessment bodies, including designation, notification, operation, and oversight of notified bodies. The Commission FAQ explains that Member States must have their notifying-authority arrangements in place by that date. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 71(2), Articles 35-51 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.1 ## What starts under the CRA on 11 September 2026? Article 14 starts to apply on 11 September 2026. From that date, manufacturers must report actively exploited vulnerabilities and severe incidents having an impact on the security of their products through the CRA reporting system. That early date also matters for open-source software stewards, because Article 24(3) ties some of their reporting obligations to Article 14. So, from 11 September 2026, the limited steward reporting hooks become relevant as well, even though the rest of the CRA still applies later. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14, Article 24(3), Article 71(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.1 ## What starts under the CRA on 11 December 2027? That is the general date of application of the CRA. From 11 December 2027, the manufacturer obligations, essential cybersecurity requirements, conformity assessment rules, CE marking framework, market surveillance rules, and the rest of the CRA apply, except for the earlier-starting provisions that already applied before that date. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 71(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.1 ## If a product is developed during the transition period but first placed on the market on or after 11 December 2027, does it have to comply with the CRA? Yes. The CRA turns on placement on the market of the individual product, not on the date the project started. The Commission FAQ makes this explicit by explaining that individual products first placed on the market on or after 11 December 2027 must comply, even if the product type or earlier units existed before then. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 71(2), Article 69(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.2 - [Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## Can a manufacturer continue placing non-CRA-compliant products on the market during the transition period before 11 December 2027? Yes, subject to any other applicable Union legislation. The CRA's main product-compliance obligations do not apply until 11 December 2027. The transition problem is not whether the product must already bear CRA CE evidence before that date, but how the manufacturer prepares so that products first placed on the market on or after that date will comply. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 71(2) ## During the transition period, can a manufacturer integrate components that do not yet bear CRA CE marking? Yes. The Commission FAQ says this directly. During the transition period, manufacturers may integrate third-party components that do not yet bear CRA CE marking, because those component manufacturers may not yet be under the CRA's full application date. The integrating manufacturer must still exercise due diligence through other means so the component does not compromise the cybersecurity of the finished product. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.3 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(5), recital 35 ## Does the transition period mean manufacturers can ignore due diligence on components until 11 December 2027? No. Article 13(5) is part of the manufacturer obligations that apply from 11 December 2027, but the Commission FAQ's transition guidance is clear about the practical point: manufacturers preparing products for post-application placement should expect to exercise due diligence even where CRA CE marking is not yet available on integrated components. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(5), recital 35 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.3 ## During the transition period, can a manufacturer integrate important or critical components that do not follow harmonised standards? Yes. The Commission FAQ says manufacturers are free to integrate components, including important or critical products with digital elements, even where those components were not designed in accordance with harmonised standards. Harmonised standards are a route to presumption of conformity, not a mandatory condition for integration. That point matters during the transition because the absence of harmonised standards, or the fact that a component does not follow them, does not by itself block integration. The manufacturer still has to assess and manage the resulting risks. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 27(1), Article 13(5) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.4 ## What happens to existing EU type-examination certificates or approval decisions issued under other Union legislation for cybersecurity requirements? Article 69(1) says those certificates and approval decisions remain valid until 11 June 2028, unless they expire earlier or the other Union legislation says otherwise. The March 2026 draft guidance explains that this can include certificates or approval decisions issued under legislation such as the RED cybersecurity delegated act or the Machinery Regulation, but only for the cybersecurity risks actually covered by those instruments. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(1) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.1 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 223, 228-231 ## Does a valid pre-existing certificate under another EU law prove full CRA compliance until 11 June 2028? No. The March 2026 draft guidance says those certificates or approval decisions remain relevant only for the cybersecurity risks they actually cover. Manufacturers still have to assess and address any remaining CRA-relevant risks that fall outside the scope of the earlier certificate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(1), Article 13(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 228-232 ## How does the CRA transition interact with the RED cybersecurity delegated regulation? The Commission FAQ says the Commission aims to repeal Delegated Regulation (EU) 2022/30 with effect from 11 December 2027. That means the timing of placing on the market matters: - products placed on the market between 1 August 2025 and 10 December 2027 can remain subject to the RED cybersecurity essential requirements made applicable by that delegated regulation - products first placed on the market on 11 December 2027 or later are subject to the CRA instead The FAQ also says repealing the RED delegated regulation from 11 December 2027 does not affect market-surveillance treatment of radio equipment that was placed on the market during the earlier RED window. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 2.6.1 ## If a product was placed on the market before 11 December 2027, does the manufacturer have to retrofit it for full CRA compliance on that date? No, unless the product is substantially modified from that date. Article 69(2) preserves the pre-existing status of products already placed on the market, while Article 69(3) separately keeps Article 14 reporting obligations applicable. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2)-(3) ## Can pre-11 December 2027 products still be reported under the CRA even before the rest of the CRA applies? Yes. This is the specific consequence of the phased dates. Article 14 starts on 11 September 2026, and Article 69(3) extends it to in-scope products already placed on the market before 11 December 2027. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(3), Article 71(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 5.3 ## Are distributors required to bring into compliance products that were already placed on the market before 11 December 2027? No. The Commission FAQ says distributors are not required to bring such products into CRA compliance merely because the general application date has passed. The key transition point is still whether the individual product was placed on the market before 11 December 2027. The main exception remains reporting under Article 14, and a separate trigger exists if someone substantially modifies the product after that date. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 21, Article 69(2)-(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.5 ## Does the transition period create a grace period for products first placed on the market after 11 December 2027? No. Once 11 December 2027 arrives, products first placed on the market on or after that date must comply with the CRA as applicable. The transition period helps manufacturers prepare, but it does not create an extra post-application grace period for newly placed products. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 71(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.2 ## What is the practical CRA transition question for manufacturers developing now? The practical transition question is not whether the CRA already applies to the product today, but when the individual product will first be placed on the market and what evidence will be needed by that date. The CRA phased dates and the Commission FAQ together point to a simple planning structure: - be ready for Article 14 reporting from 11 September 2026 - be ready for full CRA compliance for products first placed on the market from 11 December 2027 - treat existing third-party certificates only as partial evidence for the risks they actually cover, and only within their validity window Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14, Article 69(1), Article 69(3), Article 71(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.3, 7.1, 7.2, 7.3 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 223, 228-232 ## If units are only sitting in the manufacturer's or importer's stock on 11 December 2027, are they already grandfathered under the CRA transition? No. The Blue Guide says products in the stocks of the manufacturer or importer are not yet placed on the market if they have not yet been supplied for distribution, consumption, or use on the Union market. The Commission FAQ then applies that logic specifically to the CRA transition: only individual products actually placed on the market before 11 December 2027 avoid the CRA's full application, while later-placed units of the same type must comply. So manufacturing a unit before 11 December 2027 is not enough by itself. If that unit is first placed on the market on or after 11 December 2027, it must comply with the CRA as applicable. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2), Article 71(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.2 - [Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## If goods are still in transit, in a free zone, or in customs warehousing on 11 December 2027, are they treated as already placed on the market? No. The Blue Guide says products introduced from a third country but still in transit, in free zones, in warehouses, in temporary storage, or under other special customs procedures are not yet placed on the Union market. The CRA transition therefore does not turn on the shipment date or on the fact that the goods have already entered the customs territory. The relevant question is when they are first made available on the Union market. If those goods are only released for free circulation and first supplied on the Union market on or after 11 December 2027, the CRA timing is assessed at that later moment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2), Article 71(2) - [Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - section 2.3 ## For standalone software supplied digitally, is the relevant transition date the first EU offering or each later download? For standalone software supplied digitally, the relevant date is the first offering for distribution or use on the EU market. The March 2026 draft guidance says a standalone software version is placed on the market when its manufacturing phase is complete and that version is first supplied for distribution or use on the EU market in the course of a commercial activity. Later downloads or remote access to the same version are instances of making that software available, not new placements on the market. The same is true for later iterations that do not qualify as substantial modifications. That means a standalone software version first offered before 11 December 2027 is not newly placed on the market again merely because users download that unchanged or non-substantially modified version after that date. But if a later iteration is a substantial modification, that later version is treated as newly placed on the market and must comply accordingly. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 69(2), Article 71(2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 13-16, 107-113 ## Does signing a contract before 11 December 2027 let a product be placed later without CRA compliance? No. The CRA transition does not grandfather products merely because the commercial contract, procurement cycle, or development project started before 11 December 2027. The legal trigger remains when the individual product is first placed on the market. The March 2026 draft guidance expressly notes that some complex systems may involve contracts signed before the CRA applies, but the manufacturer must still ensure before placement on the market that the conformity assessment has been carried out, the EU declaration of conformity has been drawn up, and the CE marking affixed. The same draft guidance also explains that products designed before the CRA applies may still be placed on the market after 11 December 2027 without redesign, but only if the manufacturer can demonstrate compliance through the cybersecurity risk assessment and technical documentation. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(2), Article 13(12), Article 69(2), Article 71(2) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 7.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 27, 32-35 ## Can products already lawfully placed on the market before 11 December 2027 continue to be sold or put into service after that date? Yes, unless they are substantially modified from that date. Article 69(2) preserves the status of products already placed on the market before 11 December 2027. The March 2026 draft guidance states that products placed on the market before that date remain subject to the Union legislation applicable at the time of their placing on the market and, if they were compliant then, they can continue to be sold and put into operation unless they are substantially modified on or after 11 December 2027. The main CRA exception is Article 14 reporting, which still applies to in-scope products already placed on the market before 11 December 2027. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14, Article 69(2)-(3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.3, 7.2, 7.5 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 223 and footnote 25 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Transition Period as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Transition Period into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Transition Period and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/transition-period --- --- title: "CRA Update Availability and Archives FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives" author: "Sorena AI" description: "CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA update availability FAQ" - "CRA software archives FAQ" - "CRA Article 13(9)" - "CRA Article 13(11)" - "CRA historical versions" - "CRA retained security updates" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" - "CRA update availability and archives FAQ" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Update Availability and Archives FAQ CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Update Availability and Archives Use this CRA FAQ to understand how long issued security updates must remain available, when historical software archives are optional, and what Article 13(10) does and does not allow. Built for release, product, engineering, and compliance teams managing retained updates, historical versions, and archive policies under the CRA. The CRA separates vulnerability-support duties from retained-update availability and from optional public software archives. This FAQ explains Article 13(9), Article 13(10), and Article 13(11), including how long issued security updates must remain available, when historical versions may appear in archives, and why optional archives do not replace mandatory update-retention rules. ## Must each CRA security update remain available after it is issued? Yes. The CRA requires each security update that was made available during the support period to remain available after issuance for at least 10 years or for the remainder of the support period, whichever is longer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(9) ## Is CRA update availability the same thing as the support period? No. The support period is the period during which the manufacturer must handle vulnerabilities effectively. Update availability is a separate rule that keeps already-issued security updates accessible for a minimum period after issuance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 3(20), Article 13(8), Article 13(9) ## Does the 10-year availability rule apply only to updates issued during the support period? Yes. Article 13(9) applies to each security update that has been made available to users during the support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(9) ## Does the CRA require only the latest security update to stay available? No. Article 13(9) is framed at the level of each security update made available during the support period, not only the latest one. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(9) ## Can CRA update availability last longer than the support period itself? Yes. A product might have a shorter support period, but a security update issued during that period may still need to remain available for at least 10 years after issuance if that is longer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), Article 13(9) ## Does keeping old updates available mean the manufacturer must keep issuing new security updates after the support period ends? Not necessarily. The obligation to handle vulnerabilities runs through the support period. Article 13(9) separately preserves access to security updates that were already issued during that period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), Article 13(9) ## Are public software archives mandatory under the CRA? No. The CRA says manufacturers may maintain public software archives. That means archives are allowed, not required. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(11) ## What can CRA public software archives contain? The CRA allows archives that enhance user access to historical versions. The Commission FAQ explains this as historical versions of products with digital elements that are no longer made available on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(11) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.5 ## What warning must be given if a manufacturer keeps a CRA public archive of unsupported software? Users must be clearly informed, in an easily accessible manner, about the risks associated with using unsupported software. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(11) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.5 ## Must the manufacturer disclose the end date of the support period at the time of purchase? Yes. The end date of the support period, at least month and year, must be clearly and understandably specified at the time of purchase in an easily accessible manner. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(19) ## Must users be notified when the support period has ended? Yes, where technically feasible in light of the nature of the product. The CRA requires a notification informing users that the product has reached the end of its support period where that is technically feasible. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(19), recital 56 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 116 ## Must user instructions and support information remain available after placement on the market? Yes. The CRA requires the information and instructions to the user to remain at users' and authorities' disposal for at least 10 years after placing on the market or for the support period, whichever is longer. If they are provided online, they must stay accessible and available online for the same period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(18) ## Must the technical documentation and declaration of conformity also be retained after placement on the market? Yes. The technical documentation and EU declaration of conformity must be kept at the disposal of market surveillance authorities for at least 10 years after placing on the market or for the support period, whichever is longer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(13) ## Once a security update has been made available, must the manufacturer disclose information about the fixed vulnerability? Yes. Annex I Part II point (4) requires the manufacturer, once a security update has been made available, to share and publicly disclose information about fixed vulnerabilities, including the affected product, impacts, severity, and information helping users remediate the issue. In duly justified cases, publication may be delayed until users have had the possibility to apply the patch. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ## If the manufacturer stops remediating earlier software versions under Article 13(10), should users who stay on the older version be informed? Yes. The March 2026 draft guidance says that where remediation of earlier versions is discontinued, users who have not upgraded to the newest version are expected to be informed. That sits alongside the CRA rule requiring end-of-support notifications where technically feasible. Sources for this answer: - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 118-120 and footnote 14 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(19) ## Does keeping an unsupported version in a public software archive mean it is still supported under the CRA? No. Article 13(11) treats public software archives as a way to enhance access to historical versions. It does not convert unsupported software back into supported software, and it requires users to be warned about the risks of using unsupported software. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(11) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.5 ## Can a manufacturer rely on Article 13(10) only if users of older versions can move to the latest version free of charge? Yes. Article 13(10) allows a manufacturer of a software product with subsequent substantially modified versions to comply with the remediation obligation only for the latest placed version, but only if users of the earlier versions can access that latest version free of charge. That means the CRA does not let the manufacturer stop remediating older versions while putting the fix path behind a paid upgrade. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(10), recital 40 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 118 ## Can the manufacturer rely on Article 13(10) if users need new hardware or fundamental environment changes to get the latest version? No. Recital 40 says the manufacturer may shift remediation to the latest placed software version only if users of the previous versions can access that latest version free of charge and do not incur additional costs to adjust the hardware and software environment in which they use the original version. The March 2026 draft guidance adds that this should be interpreted practically and proportionately, but it does not cover costs such as buying new hardware or making fundamental infrastructure changes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(10), recital 40 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 118-120 ## If the manufacturer relies on Article 13(10) and stops remediating earlier versions, do the other vulnerability-handling duties disappear too? No. Recital 40 and the March 2026 draft guidance both make the same point: Article 13(10) gives flexibility only for the obligation to address and remediate vulnerabilities for earlier versions. The manufacturer remains subject to the other vulnerability-handling requirements for the support period, such as coordinated vulnerability disclosure and measures to facilitate information sharing about potential vulnerabilities. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(10), Annex I Part II point (2), recital 40 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 118-120 ## Is the mandatory update-retention rule the same thing as keeping a public software archive? No. Article 13(9) creates a mandatory duty to keep each security update made available during the support period available after issuance. Article 13(11) is a separate, optional rule that allows manufacturers to maintain public software archives to enhance access to historical versions. The Commission FAQ describes those archives as a way to provide access to historical versions of products that are no longer made available on the market. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(9), Article 13(11) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.7 ## Does the CRA require every historical software version to remain downloadable? No. The mandatory rule in Article 13(9) applies to each security update made available during the support period. By contrast, Article 13(11) says manufacturers may maintain public software archives for historical versions. So the CRA imposes a mandatory retention rule for issued security updates, but it does not impose a general duty to keep every historical software version downloadable as such. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(9), Article 13(11) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.7 ## If a manufacturer relies on Article 13(10) and stops remediating older versions, do earlier security updates already issued for those versions still need to remain available? Yes. Article 13(10) gives flexibility only for the obligation in Annex I Part II point (2) to address and remediate vulnerabilities for earlier versions. Article 13(9) separately requires each security update that was made available during the support period to remain available after issuance. The March 2026 draft guidance treats Article 13(10) as a limited exception for remediation of earlier versions, not as a cancellation of the separate update-retention rule. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(9), Article 13(10), Annex I Part II point (2) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 118-120 ## If a hardware product cannot run the latest software version, can the manufacturer stop offering any supported security-update path for that product? No. Recital 40 says that where a hardware product, such as a smartphone, is not compatible with the latest version of the operating system it was originally delivered with, the manufacturer should continue to provide security updates at least for the latest compatible version for the support period. So Article 13(10) does not let the manufacturer point users to an upgrade path that the hardware cannot actually use and then stop supporting the compatible branch. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 40 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 118-120 ## Must retained CRA security updates be published in a public archive open to anyone? Not necessarily. Inference from Articles 13(9) and 13(11): the mandatory rule is to keep security updates available to users, while public software archives are only an optional way to enhance access to historical versions. The CRA therefore does not state that every retained security update must be published in a public archive open to anyone, even though a manufacturer may choose to make updates available that way. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(9), Article 13(11) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 1.7 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Update Availability and Archives as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Update Availability and Archives into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Update Availability and Archives and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives --- --- title: "CRA User Information and Transparency FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency" author: "Sorena AI" description: "CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA Annex II FAQ" - "CRA user information FAQ" - "CRA transparency FAQ" - "CRA support period disclosure" - "CRA end of support notice" - "CRA vulnerability user notice" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" - "CRA user information and transparency FAQ" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA User Information and Transparency FAQ CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ User Information and Transparency Use this CRA FAQ to understand what Annex II requires, what support and update information users must receive, when user notices are required, and what the CRA does not require to be published. Built for product, legal, UX, support, and compliance teams preparing CRA user information, notices, and transparency materials. The CRA requires specific user-facing information, instructions, notices, and support disclosures, but it does not require every internal security document or vulnerability detail to be made public. This FAQ explains Annex II, support-period disclosure, end-of-support notices, Article 14(8) user notices, advisory messages, and the limits of mandatory transparency. ## Does the CRA require products to be accompanied by user information and instructions? Yes. Article 13(18) requires manufacturers to accompany products with the Annex II information and instructions to the user, in paper or electronic form. Those materials must be clear, understandable, intelligible, legible, and sufficient for secure installation, operation, and use. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(18), Annex II ## In what language must CRA user information be provided? It must be in a language that can be easily understood by users and market surveillance authorities. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(16), Article 13(18) ## Can the CRA information and instructions be provided electronically or online? Yes. The CRA allows the information and instructions to be provided in paper or electronic form. If they are provided online, the manufacturer must ensure they are accessible, user-friendly, and remain available online for at least 10 years after placing on the market or for the support period, whichever is longer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(18) ## What information must Annex II include at a minimum? Annex II requires, at minimum: - manufacturer identity and contact details - the single point of contact for vulnerability reporting and the location of the coordinated vulnerability disclosure policy - product identification information - intended purpose, essential functionalities, and security properties - known or foreseeable circumstances that may lead to significant cybersecurity risks - the declaration-of-conformity web address where applicable - the type of security support offered and the end date of the support period - instructions for secure commissioning, use, updates, and decommissioning - instructions on how to turn off automatic security updates where applicable - integration information for integrators where applicable - SBOM access information if the manufacturer decides to make the SBOM available to users Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex II ## Does the CRA require the manufacturer to disclose the support period to buyers before purchase? Yes. Article 13(19) requires the end date of the support period, at least month and year, to be clearly and understandably specified at the time of purchase in an easily accessible manner. Annex II also requires the product to be accompanied by information on the type of technical security support offered and the end date of the support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(19), Annex II, point 7 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 116 ## Does the CRA require an end-of-support notice to existing users? Yes, where technically feasible in light of the nature of the product. Article 13(19) says manufacturers must display a notification to users informing them that the product has reached the end of its support period where this is technically feasible. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(19) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 116 and 118-120 ## What contact information must be visible to users? Users must be given the manufacturer's name, trade name or trademark, and postal address and email address or other digital contact details and, where applicable, website. That information must appear on the product, packaging, or accompanying document and must also be included in the Annex II information and instructions. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(16), Annex II, point 1 ## What is the single point of contact and what must users be able to do with it? The single point of contact is the channel through which users can communicate directly and rapidly with the manufacturer, including to report vulnerabilities. It must be easily identifiable, must let users choose their preferred means of communication, and must not limit communication to automated tools. Annex II also requires users to be told where the manufacturer's coordinated vulnerability disclosure policy can be found. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex II, point 2, recital 63 ## Must the manufacturer tell users the product's intended purpose and security properties? Yes. Annex II requires the intended purpose of the product, including the security environment provided by the manufacturer, as well as the product's essential functionalities and information about its security properties. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex II, point 4 ## Must the manufacturer warn users about foreseeable misuse and significant cybersecurity risks? Yes. Annex II requires information about any known or foreseeable circumstance related to intended use or reasonably foreseeable misuse that may lead to significant cybersecurity risks. The Commission FAQ gives examples such as deployment on insecure networks or use outside the expected professional setting. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex II, point 5 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.3 to 4.1.5 ## If the manufacturer's risk assessment assumes the product will be used only in a secure environment, does that need to be reflected in the instructions? Yes. The Commission FAQ says that where the risk assessment relies on assumptions or requirements needed for secure installation, integration, or operation, those assumptions must be communicated through the information and instructions to the user. This includes deployment conditions such as use on a secure network or use by trained professional users. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.4 and 4.1.5 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(18), Annex II, points 4, 5, and 8 ## If a product is intended for professionals but might reasonably be used by less-skilled users, do the instructions need to take that into account? Yes. The Commission FAQ, relying on the Blue Guide, says manufacturers must consider reasonably foreseeable use and the expected audience for installation and operation. If non-professional or low-skilled users are a foreseeable audience, the instructions must be adapted accordingly. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.4 - [Blue Guide on the implementation of EU product rules 2022](https://ec.europa.eu/docsroom/documents/44906/attachments/2/translations/en/renditions/native?ref=sorena.io) - sections 2.8 and 3.1 ## What CRA update-related instructions must users receive? Users must receive information on how security-relevant updates can be installed. Where the product has a default setting enabling automatic installation of security updates, Annex II also requires instructions on how that setting can be turned off. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex II, point 8(c)-(e) ## Does the CRA require decommissioning instructions? Yes. Annex II requires information on secure decommissioning of the product, including how user data can be securely removed. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex II, point 8(d) ## What if the product is intended for integration into another product? Then the manufacturer must provide the information necessary for the integrator to comply with the essential cybersecurity requirements and the documentation requirements in Annex VII. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex II, point 8(f) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.4 ## Does the CRA require the manufacturer to give users access to the full technical documentation? No, not generally. The CRA requires the manufacturer to prepare and retain technical documentation for authorities, but the Commission FAQ says there is no general obligation to make the technical documentation available to customers or to the public. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(12)-(13), Article 31 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.6 ## Does the CRA require the manufacturer to give users the EU declaration of conformity? Yes, either in full or in simplified form. If the manufacturer provides a simplified EU declaration of conformity, it must contain the exact internet address where the full declaration can be accessed. Annex II also requires the internet address to be included where applicable. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(20), Annex II, point 6 ## Must the manufacturer tell users what kind of security support they will receive? Yes. Annex II requires the type of technical security support offered by the manufacturer and the end date of the support period during which users can expect vulnerabilities to be handled and receive security updates. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex II, point 7 ## If the manufacturer decides to make the software bill of materials available to users, does the CRA say anything about that? Yes. If the manufacturer decides to make the SBOM available to the user, Annex II requires information on where the SBOM can be accessed. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex II, point 9 ## How long must the manufacturer keep CRA user information available? For at least 10 years after placing the product on the market or for the support period, whichever is longer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(18) ## Must the manufacturer inform users about actively exploited vulnerabilities and severe incidents? Yes. After becoming aware of an actively exploited vulnerability or a severe incident having an impact on the security of the product, the manufacturer must inform the impacted users and, where appropriate, all users, of that vulnerability or incident and of any corrective or mitigating measures users can take. The CRA adds that this information should, where appropriate, be provided in a structured, machine-readable format that is easily automatically processable. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8) ## When security updates are available, must they come with user-facing advisory messages? Yes. Annex I Part II point (8) requires available security updates to be disseminated without delay and, unless the tailor-made exception applies, free of charge. It also requires those updates to be accompanied by advisory messages providing users with the relevant information, including on potential action to be taken. So the CRA's transparency duties are not limited to giving users access to the update package itself. They also include the user-facing information needed to understand and apply the update safely. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (8) ## If a manufacturer ceases operations, do users have to be informed? Yes. Article 13(23) says that if a manufacturer ceases operations and, as a result, cannot comply with the CRA, it must inform the relevant market surveillance authorities before the cessation takes effect and must also inform users of the relevant products, by any available means and to the extent possible. That is a specific CRA transparency duty aimed at letting users understand that the manufacturer may no longer be able to maintain compliance or provide the expected support. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(23) ## For iterative software, does the CRA support-period information need to match the specific version being placed on the market? Yes. The March 2026 draft guidance says that each version of a software product placed on the market has to have its own declared support period complying with Article 13(8). That matters for transparency because Article 13(19) requires the end date of the support period to be clearly specified at the time of purchase. So for substantially modified software versions, the support-period information must track the specific version being placed on the market, not just a generic family-wide date. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), Article 13(19) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 116-120 ## Does Article 14(8) mean vulnerability or incident information always has to be made public to everyone? No. The March 2026 draft guidance says the Article 14(8) duty to inform users is risk-based and proportionate. It does not mean the information must always be made public or disclosed indiscriminately. Where appropriate, manufacturers may limit detailed disclosure to the relevant affected users or customers, especially for products used in sensitive or essential environments where wider public disclosure could itself increase cybersecurity risks. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## Does the CRA require the manufacturer to publish every known vulnerability or the full cybersecurity risk assessment to users? No. The CRA requires several specific disclosures, not a blanket publication of all security analysis. Users may need to be informed about significant cybersecurity risks under Annex II point 5, about actively exploited vulnerabilities or severe incidents under Article 14(8), and about fixed vulnerabilities once a security update is available under Annex I Part II point (4). But the Commission FAQ also says there is no general obligation to make the technical documentation available to customers or to the public. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4), Annex II point 5 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 6.6 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## If a product has optional modes, legacy-compatibility settings, or technical capabilities that can create significant cybersecurity risk in foreseeable misuse, must that be explained to users? Yes, where those circumstances may lead to significant cybersecurity risks. The Commission FAQ explains that even where a function or capability sits outside the intended purpose, the information and instructions may need to mention it if reasonably foreseeable misuse could create significant cybersecurity risks. The same logic applies where manufacturers allow users to alter configurations, remove security functionality, or downgrade security measures for legacy compatibility. In those cases, the risks should be treated in the risk assessment and explicitly reflected in user information where Annex II point 5 is engaged. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex II point 5, Article 13(18) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.1.3 to 4.1.5 ## Does the CRA itself already require a standard security label, pictogram, or score to be shown to users? No fixed format is required by the Regulation text itself. Article 30(6) allows the Commission to adopt implementing acts laying down technical specifications for labels, pictograms, or other marks related to product security and support periods. But the CRA text itself does not already prescribe one mandatory standard label or scoring format that manufacturers must use in Annex II information. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 30(6) ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ User Information and Transparency as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ User Information and Transparency into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ User Information and Transparency and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency --- --- title: "CRA Vulnerability Handling FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling" author: "Sorena AI" description: "CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA vulnerability handling FAQ" - "CRA Annex I Part II" - "CRA component vulnerability handling" - "CRA upstream fix sharing" - "CRA fixed vulnerability disclosure" - "CRA Article 14 vs Article 13" - "Cyber Resilience Act" - "CRA FAQ" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA Vulnerability Handling FAQ CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. *FAQ* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Vulnerability Handling Use this CRA FAQ to understand the lifecycle vulnerability-handling duties in Annex I Part II, what manufacturers must do for component vulnerabilities, and how disclosure and upstream-fix sharing rules work. Built for product security, engineering, legal, and compliance teams managing vulnerability handling and disclosure under the CRA. The CRA requires more than just patching: manufacturers must document vulnerabilities, assess risks, handle component issues, maintain disclosure and reporting channels, and keep update distribution working across the support period. This FAQ explains the Annex I Part II lifecycle duties, the limits of Article 13(6) upstream duties, and how vulnerability handling differs from the narrower Article 14 incident-reporting regime. ## What does the CRA require manufacturers to do for vulnerability handling over the product lifecycle? Annex I Part II requires manufacturers to: - identify and document vulnerabilities and components, including a software bill of materials - address and remediate vulnerabilities without delay, including through security updates - apply effective and regular security tests and reviews - disclose information about fixed vulnerabilities once a security update is available, subject to a limited justified delay option - enforce a coordinated vulnerability disclosure policy - facilitate vulnerability reporting, including for third-party components in the product - provide secure update-distribution mechanisms and, where applicable, automatic security updates - disseminate security updates without delay and, unless the tailor-made exception applies, free of charge Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6)-(11), Annex I Part II ## Does the CRA require a patch for every vulnerability discovered during the support period? No. The Commission FAQ says the CRA does not require a patch for every vulnerability. The manufacturer must assess the risk the vulnerability poses and ensure that remedies are put in place without delay. Depending on the risk, the right remedy may be an immediate patch, a mitigation, configuration guidance, an advisory, documentation changes, or another appropriate measure. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (2), Article 13(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.1 ## What does "without delay" mean in practice for CRA vulnerability handling? The CRA does not define one universal deadline for remediation under Annex I Part II point (2). The Commission FAQ treats it as risk-based. High-risk vulnerabilities may require immediate patching, while lower-risk issues may be handled through other timely remedies. What matters is that the manufacturer assesses the vulnerability promptly and takes an appropriate remediation or mitigation path without unjustified delay. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (2), Article 13(8) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.1 ## Must CRA security updates be separate from functionality updates? Where technically feasible, yes. The CRA says new security updates must be provided separately from functionality updates where technically feasible. Recital 57 explains that this is meant to avoid forcing users to install feature changes just to receive security fixes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (2), recital 57 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.5 ## Can a security update and a functionality update be combined in one release? Yes, where separation is not technically feasible. The Commission FAQ gives examples where a security fix necessarily changes functionality, such as replacing an unsafe parser with a safer one that changes product behaviour, or disabling a vulnerable interface. In those cases, the CRA does not require artificial separation. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.5 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (2) ## Do vulnerability-handling obligations apply only when the product is first sold? No. Manufacturers must ensure, when placing the product on the market and for the support period, that vulnerabilities of the product, including its components, are handled effectively and in accordance with Annex I Part II. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), recital 34 ## Do vulnerability-handling obligations cover integrated components too? Yes. The CRA and the Commission FAQ both state that the vulnerability-handling obligations apply to the product in its entirety, including integrated components. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 13(8), recital 34 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.6 and 4.3.7 ## What must the manufacturer do if it finds a vulnerability in an integrated component? The manufacturer must report the vulnerability to the person or entity manufacturing or maintaining the component, address and remediate the vulnerability in its own product, and share the relevant code or documentation if it developed a hardware or software modification to fix the component vulnerability. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), recital 34 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.6 ## Can the integrating manufacturer rely on the component manufacturer to fix component vulnerabilities? Sometimes, but not completely. If the component is itself subject to CRA obligations, the integrating manufacturer can rely in part on the component manufacturer's vulnerability-handling work. But the integrating manufacturer still has to fulfil the CRA obligations for its own product, including keeping users informed and ensuring the overall product remains compliant. If the component is not subject to CRA vulnerability-handling obligations, the integrating manufacturer must still handle the issue in its own product, including by other means if necessary. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.6 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 13(8), recital 34 ## What if the integrated component is no longer supported by its own developer? That does not remove the product manufacturer's CRA duty. The Commission FAQ says that if a product still has an active support period and a vulnerability in an integrated component can no longer be addressed through the component's own support path, the manufacturer of the product must remediate the issue by other means, such as switching out the component or developing a patch autonomously. Sources for this answer: - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.6 and 4.3.7 - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), Annex I Part II point (2) ## Does the manufacturer need to support every version of a software product? Not always. Article 13(10) allows the manufacturer, under specific conditions, to ensure compliance with the remediation obligation only for the latest substantially modified version it has placed on the market. That is allowed only if users of earlier versions can access the latest version free of charge and without additional costs to adjust their hardware or software environment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(10), recital 40 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.2 - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 118 ## If a hardware product cannot run the latest software version, can the manufacturer stop updating it? No. Recital 40 says that where a hardware product is not compatible with the latest version of the operating system it was originally delivered with, the manufacturer should continue to provide security updates at least for the latest compatible version for the support period. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - recital 40 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.2 ## Is the manufacturer responsible for users actually installing CRA security updates? No, but the manufacturer is responsible for making the update path work properly. The CRA requires mechanisms for secure distribution, automatic security updates where applicable, notification to users, and dissemination without delay. The Commission FAQ says the manufacturer is not responsible under the CRA if a user does not install updates, for example because the user opted out. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 6, Annex I Part I point (2)(c), Annex I Part II points (7) and (8), recital 56 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.3 ## Must CRA security updates be free of charge? Yes, unless the tailor-made exception applies. Annex I Part II point (8) requires that security updates addressing identified security issues be disseminated without delay and free of charge, unless otherwise agreed between the manufacturer and a business user in relation to a tailor-made product. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (8), recital 64 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.2.5 and 4.3.3 ## Must each CRA security update remain available after release? Yes. Article 13(9) says each security update made available during the support period must remain available for at least 10 years after it is issued or for the remainder of the support period, whichever is longer. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(9) ## Can a manufacturer keep public software archives of older unsupported versions? Yes. Article 13(11) says manufacturers may maintain public software archives enhancing user access to historical versions. If they do, users must be clearly informed in an easily accessible manner about the risks associated with using unsupported software. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(11) ## Must manufacturers test and review product security regularly? Yes. Annex I Part II point (3) requires effective and regular tests and reviews of the security of the product. Article 13(7) also requires the manufacturer to systematically document relevant cybersecurity aspects and, where applicable, update the cybersecurity risk assessment. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (3), Article 13(7) ## Must manufacturers publicly disclose information about fixed vulnerabilities? Yes, once a security update has been made available. Annex I Part II point (4) requires disclosure of information about fixed vulnerabilities, including the vulnerability description, affected products, impact, severity, and clear remediation information. The CRA allows delay only in duly justified cases where publication risk outweighs publication benefit until users have had the possibility to apply the patch. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ## Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact? Yes. Annex I Part II points (5) and (6) require a coordinated vulnerability disclosure policy and measures to facilitate sharing of information about potential vulnerabilities, including a contact address. Article 13(17) and Annex II also require a single point of contact for users. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ## What happens if a vulnerability cannot be fixed adequately? The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. The Commission FAQ says recall or withdrawal is likely to be exceptional, but it can be required where a very significant vulnerability cannot be adequately addressed, especially for hardware products. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ## Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary? Yes. Article 13(7) requires the manufacturer to systematically document, in a manner proportionate to the nature and cybersecurity risks, relevant cybersecurity aspects concerning the product, including vulnerabilities of which it becomes aware and relevant information provided by third parties. Where applicable, it must also update the cybersecurity risk assessment. The Commission FAQ adds that this includes updating the risk assessment where relevant information about the product's cybersecurity emerges from regular tests and reviews. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ## Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14? Yes. Vulnerability handling under Article 13 and Annex I Part II applies more broadly during the support period. It covers identifying, documenting, assessing, remediating, testing, updating, disclosing fixed vulnerabilities, and handling component vulnerabilities. Article 14 is narrower. It applies only when the manufacturer becomes aware of an actively exploited vulnerability or of a severe incident having an impact on the security of the product. So not every vulnerability-handling event triggers mandatory CRA reporting, even though it may still require remediation or other action under Annex I Part II. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ## Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply? Yes. Article 15 provides for voluntary notification of actively exploited vulnerabilities and severe incidents. The Commission FAQ also gives examples where mandatory reporting does not apply, such as a zero-day vulnerability with no reliable evidence of malicious exploitation, or a vulnerability in an integrated component that is not exploitable in the manufacturer's own product. In those cases, voluntary reporting remains possible. That does not replace the manufacturer's ordinary vulnerability-handling duties. For example, where the issue concerns an integrated component, Article 13(6) still requires reporting the vulnerability to the person or entity manufacturing or maintaining that component. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ## Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports? Yes. Article 13(8) requires appropriate policies and procedures to process and remediate potential vulnerabilities reported from internal or external sources. So the CRA does not treat internal testing, internal security reviews, researcher disclosures, customer reports, and similar outside inputs as separate optional tracks. The handling process has to be able to deal with both. ISO/IEC 30111 in the local CRA corpus points in the same direction as practical implementation guidance: it treats vulnerability handling as covering internally found vulnerabilities, externally reported vulnerabilities, and publicly disclosed vulnerabilities that reach the vendor from outside. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ## Does Article 13(6) require upstream reporting for every security issue involving an integrated component? No. The March 2026 draft guidance says manufacturers are required to report upstream only the vulnerabilities that exist in the integrated component itself, and only for the version of that component that they actually integrate. They are not required to report upstream vulnerabilities that arise only from the way the manufacturer integrated that component with its own code or with other components. The same draft guidance adds that where integration reveals useful security-relevant information about the component that was not apparent in isolation, manufacturers are encouraged to share that information upstream, but that is framed as good practice rather than as the strict Article 13(6) duty. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ## Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork? Not in those cases. The March 2026 draft guidance says upstream reporting is not required where the component no longer has a maintainer, or where the manufacturer has duplicated a free and open-source component and no longer relies on the original maintainer for new versions or security fixes. But the same guidance also warns that a manufacturer is not treated as maintaining an independent fork if it still relies on the upstream project for new versions or security fixes, for example by regularly synchronising local copies with upstream. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ## Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it? The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. The March 2026 draft guidance says a manufacturer sharing an upstream fix should, where appropriate, share it in a machine-readable format, such as a merge request, in a way that can be verified and integrated by the maintainer. For free and open-source components, the fix should be shared in a way compatible with the component's licence, and manufacturers should generally follow the maintainer's guidelines on how fixes should be shared. But the same guidance is explicit that the CRA does not require manufacturers to ensure that their fixes are accepted or integrated upstream, and it does not require manufacturers to accept a maintainer's proposed fix if they prefer another suitable mitigation. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ## Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT? A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Recital 76 says coordinated vulnerability disclosure policies should facilitate the reporting of vulnerabilities either directly to the manufacturer or indirectly and, where requested, anonymously via CSIRTs designated as coordinators under Directive (EU) 2022/2555. The same recital says manufacturers should be able to use bug bounty programmes as part of those policies, but it does not make bug bounties compulsory. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ## Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation? No. Annex I Part II point (4) concerns fixed vulnerabilities: once a security update has been made available, the manufacturer must share and publicly disclose information about those fixed vulnerabilities, subject to the limited justified delay option. Article 14(8), by contrast, concerns actively exploited vulnerabilities and severe incidents and requires manufacturers to inform impacted users and, where appropriate, all users. The March 2026 draft guidance adds that Article 14(8) is risk-based and proportionate. It does not require indiscriminate public disclosure in every case, and detailed information may in some situations be limited to the relevant affected users or customers. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Recommended next step* *Placement: after key answers* ## Use EU Cyber Resilience Act FAQ Vulnerability Handling as a cited research workflow Research Copilot can turn EU Cyber Resilience Act FAQ Vulnerability Handling into a reusable cited workflow for teams implementing EU Cyber Resilience Act FAQ. - [Open Research Copilot](/solutions/research-copilot.md): Start from EU Cyber Resilience Act FAQ Vulnerability Handling and move to source-backed decisions and evidence workflows. - [Talk through your EU Cyber Resilience Act FAQ implementation](/contact.md): Review evidence gaps, ownership, and next steps for EU Cyber Resilience Act FAQ. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/penalties-and-fines" author: "Sorena AI" description: "Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure." published_at: "2026-03-04" updated_at: "2026-03-11" keywords: - "CRA penalties" - "CRA fines" - "Cyber Resilience Act Article 64" - "CRA enforcement" - "CRA administrative fines" - "EU compliance" - "Cyber Resilience Act" - "CRA compliance" - "Penalties and Fines" - "Products with digital elements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Penalties and Fines Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. *Artifact Guide* *EU* ## EU Cyber Resilience Act, CRA Product Security and CE Marking Penalties and Fines Grounded implementation guidance for legal, product, and engineering teams. Use official CRA sources to translate obligations into owners, evidence, and shipping decisions. The CRA penalty structure is not abstract. Article 64 ties the highest fine tier to Annex I non compliance and to Articles 13 and 14, which means insecure products, weak support operations, and missed reporting can sit in the same top bracket. Member States set national penalty rules, but the regulation fixes the maximum administrative fine tiers. ## The three CRA fine tiers in Article 64 Article 64 creates three maximum administrative fine brackets. For undertakings, the percentage of worldwide annual turnover is compared with the fixed amount and the higher figure applies. The practical message is simple. The closer an issue is to Annex I, Article 13, or Article 14, the more urgent it becomes. - Up to EUR 15 000 000 or 2.5 percent of worldwide annual turnover for non compliance with Annex I and Articles 13 and 14 - Up to EUR 10 000 000 or 2 percent of worldwide annual turnover for non compliance with Articles 18 to 23, Article 28, Article 30(1) to (4), Article 31(1) to (4), Article 32(1) to (3), Article 33(5), and Articles 39, 41, 47, 49, and 53 - Up to EUR 5 000 000 or 1 percent of worldwide annual turnover for incorrect, incomplete, or misleading information supplied to notified bodies or market surveillance authorities ## What tends to drive the top CRA fine bracket The top bracket combines product weaknesses and process failures. A team can be exposed because the product was not secure by default, because vulnerabilities were not handled during the support period, or because an actively exploited vulnerability or severe incident was not reported on time. The cleanest way to reduce this exposure is to build a technical file and support workflow that show diligence before an authority asks for it. - Known exploitable vulnerabilities at market entry - Weak or undocumented vulnerability handling during the support period - Missing or late Article 14 reports - No clear support period, user information, or corrective action path ## How authorities determine the CRA fine amount Article 64 says authorities should consider the nature, gravity, duration, and consequences of the infringement, whether similar fines were already applied, and the size and market share of the economic operator. This means repeat failures and poor remediation posture make a bad situation materially worse. - Nature, gravity, duration, and consequences of the infringement - Prior similar fines applied by the same or other market surveillance authorities - Size and market share, including proportionality for microenterprises and small and medium sized enterprises ## Important CRA derogations and edge cases Article 64(10), as corrected by the July 2025 corrigendum, creates specific derogations. The administrative fines referred to in paragraphs 2 to 9 do not apply to manufacturers that qualify as microenterprises or small enterprises with regard to failure to meet the twenty four hour early warning deadline in Article 14(2)(a) or Article 14(4)(a). The same derogation excludes those administrative fines for open source software stewards. Do not overread this. It is a narrow derogation, not a general exemption from CRA duties. - Micro and small manufacturers still need a reporting process - Open source software stewards still have obligations under Article 24 - Misleading information to authorities remains a separate enforcement risk ## Evidence that actually reduces CRA enforcement exposure Good evidence does not eliminate risk, but it changes the conversation. Authorities look more favourably on operators that can show traceability, prompt remediation, and disciplined reporting. The most useful evidence is generated as part of the normal release and support process. - Risk assessment with clear Annex I applicability logic - Technical documentation index and declaration of conformity history - SBOM, vulnerability intake, triage, remediation, and advisory records - Article 14 timeline pack with awareness timestamp, reports, user notices, and corrective action evidence *Recommended next step* *Placement: after the enforcement section* ## Use EU Cyber Resilience Act, CRA Product Security and CE Marking Penalties and Fines as a cited research workflow Research Copilot can take EU Cyber Resilience Act, CRA Product Security and CE Marking Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Cyber Resilience Act, CRA Product Security and CE Marking can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Cyber Resilience Act, CRA Product Security and CE Marking Penalties and Fines](/solutions/research-copilot.md): Start from EU Cyber Resilience Act, CRA Product Security and CE Marking Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Cyber Resilience Act, CRA Product Security and CE Marking](/contact.md): Review your current process, evidence gaps, and next steps for EU Cyber Resilience Act, CRA Product Security and CE Marking Penalties and Fines. ## Primary sources - [Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng?ref=sorena.io) - Primary legal text for scope, manufacturer duties, reporting, conformity assessment, technical documentation, market surveillance, and penalties. ## Related Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/penalties-and-fines --- --- title: "Products with Digital Elements Scope" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope" author: "Sorena AI" description: "Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes." published_at: "2026-03-04" updated_at: "2026-03-11" keywords: - "products with digital elements" - "CRA scope" - "CRA remote data processing" - "CRA software scope" - "CRA hardware scope" - "CRA exclusions" - "EU compliance" - "Cyber Resilience Act" - "CRA compliance" - "Products with Digital Elements Scope" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Products with Digital Elements Scope Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. *Artifact Guide* *EU* ## EU Cyber Resilience Act, CRA Product Security and CE Marking Products with Digital Elements Scope Grounded implementation guidance for legal, product, and engineering teams. Use official CRA sources to translate obligations into owners, evidence, and shipping decisions. Most CRA mistakes start with the wrong boundary. Teams either treat everything connected to a product as in scope or they carve out remote functions and integrated components too aggressively. The regulation gives a narrower and more useful test, and the Commission's March 2026 draft guidance adds practical examples that help with the hardest scope calls. ## The CRA products-with-digital-elements core definition in Article 3 A product with digital elements is a software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately. That definition captures more than consumer devices. It can include standalone software, firmware, embedded components, and complex industrial products. The definition should be read together with Article 2, which requires the intended purpose or reasonably foreseeable use to include a direct or indirect logical or physical data connection to a device or network. - Standalone software can be a product with digital elements - Hardware products with firmware or software can be products with digital elements - Components sold separately can be in scope - Indirect connection can still satisfy the scope rule ## CRA remote data processing, when the cloud is part of the product Remote data processing is in scope only when it is designed and developed by the manufacturer, or under the manufacturer's responsibility, and its absence would prevent the product from performing one of its functions. That is a functional dependency test, not a broad reference to every online service related to the product. This is one of the most important boundaries to document in the technical file. - Ask whether the remote processing is necessary for a product function, not merely helpful or supportive - Record who designs and controls the remote processing - Keep evidence of the product function that would fail without the remote processing - Exclude unrelated cloud services and websites that do not support product functionality ## What the March 2026 CRA draft guidance adds on products with digital elements The draft Commission guidance reinforces that remote data processing is in scope only where the manufacturer designs it or controls it under its responsibility and the product cannot perform a function without it. That supports a documented functional-dependency test rather than a vague reference to anything hosted in the cloud. The same draft guidance also supports a narrower reading for websites, support portals, and other surrounding online assets that do not enable a product function. It further shows that some sector exclusions still require careful cross-checking against the specific sector law, so teams should document those exclusions directly against Article 2 and the relevant Union regime. - Use a function-by-function dependency test for remote data processing - Record whether the manufacturer designs or controls the remote processing under its responsibility - Separate websites, portals, and support content that do not provide a product function - For sector exclusions, keep a written legal cross-reference to the specific excluded regime instead of relying on shorthand labels ## What is commonly out of CRA scope for products with digital elements The Commission FAQ helps on common border cases. Websites that do not support product functionality are not products with digital elements. Standalone SaaS or other cloud solutions developed outside the responsibility of the product manufacturer are not themselves products with digital elements unless they meet the remote data processing definition. Article 2 also excludes several categories outright, including certain medical, aviation, marine, vehicle, defence, and identical spare part situations. - Support websites and marketing sites that do not enable product functionality - Cloud services outside the manufacturer's product responsibility - Identical spare parts manufactured to the same specifications for replacement purposes - Products in excluded legal regimes listed in Article 2 ## CRA market-entry edge cases teams should document for products with digital elements The CRA analysis should also record whether the product is being made available on the market, whether the activity is commercial, and whether the product is a current supported release or an archive. The Commission FAQ makes clear that public archives can exist, but unsupported software should carry clear user information about the associated risks. Documenting these cases prevents later confusion during incidents or authority review. - Commercial activity logic for free and open source software - Difference between test builds, betas, archives, and market offerings - Date the product was first placed on the market - Version and model identifiers linked to the scope decision *Recommended next step* *Placement: after the scope or definition section* ## Use EU Cyber Resilience Act, CRA Product Security and CE Marking Products with Digital Elements Scope as a cited research workflow Research Copilot can take EU Cyber Resilience Act, CRA Product Security and CE Marking Products with Digital Elements Scope from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Cyber Resilience Act, CRA Product Security and CE Marking can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Cyber Resilience Act, CRA Product Security and CE Marking Products with Digital Elements Scope](/solutions/research-copilot.md): Start from EU Cyber Resilience Act, CRA Product Security and CE Marking Products with Digital Elements Scope and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Cyber Resilience Act, CRA Product Security and CE Marking](/contact.md): Review your current process, evidence gaps, and next steps for EU Cyber Resilience Act, CRA Product Security and CE Marking Products with Digital Elements Scope. ## Primary sources - [Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng?ref=sorena.io) - Primary legal text for scope, manufacturer duties, reporting, conformity assessment, technical documentation, market surveillance, and penalties. - [European Commission FAQ on the Cyber Resilience Act, version 1.2, January 2026](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Practical implementation clarifications on scope, open source, support period, conformity assessment, reporting, and transition issues. - [European Commission Cyber Resilience Act policy page](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act?ref=sorena.io) - Official timeline overview and implementation context. - [Draft Commission guidance on the application of the Cyber Resilience Act, March 2026 draft](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Draft Commission guidance with practical scope explanations on remote data processing, open source software, support periods, and selected exclusions. Use as persuasive guidance until formally adopted. ## Related Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope --- --- title: "Reporting Obligations" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/reporting-obligations" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/reporting-obligations" author: "Sorena AI" description: "Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing." published_at: "2026-03-04" updated_at: "2026-03-11" keywords: - "CRA reporting obligations" - "Article 14 reporting" - "CRA 24 hours 72 hours" - "CRA actively exploited vulnerability" - "CRA severe incident" - "ENISA single reporting platform" - "EU compliance" - "Cyber Resilience Act" - "CRA compliance" - "Reporting Obligations" - "Products with digital elements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Reporting Obligations Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. *Artifact Guide* *EU* ## EU Cyber Resilience Act, CRA Product Security and CE Marking Reporting Obligations Grounded implementation guidance for legal, product, and engineering teams. Use official CRA sources to translate obligations into owners, evidence, and shipping decisions. Article 14 is the first CRA obligation most teams will feel in real time. Reporting starts on 11 September 2026 and it applies to in scope products already on the market. The critical discipline is to define awareness, route the event quickly, and reuse your incident and vulnerability data so deadlines are achievable. ## Two CRA reportable event types, do not mix them up Article 14 creates mandatory reporting for actively exploited vulnerabilities and for severe incidents having an impact on the security of the product with digital elements. The reporting packages and final report timelines differ slightly, so the triage step needs to classify the event correctly. The Commission FAQ is also useful on what is not mandatory. A zero day found in good faith without evidence of malicious exploitation is not, by itself, a mandatory Article 14 notification. - Actively exploited vulnerability, exploitation in the wild is the trigger - Severe incident affecting product security, including incidents affecting availability, authenticity, integrity, or confidentiality of important data or functions - Document why the event falls into one track or the other - Keep a record when the team decides the event is not reportable ## The CRA reporting deadlines in Article 14 For both tracks, the first clock is the same. The manufacturer must send an early warning without undue delay and in any event within twenty four hours of becoming aware. The next notification is due within seventy two hours of awareness unless the relevant information has already been provided. The final deadline then depends on the event type. - Actively exploited vulnerability, final report no later than fourteen days after a corrective or mitigating measure is available - Severe incident, final report within one month after the incident notification - The CSIRT designated as coordinator may request intermediate reports - Awareness timestamp discipline is essential because every later deadline depends on it ## Where the CRA report goes and how routing works Notifications go through the single reporting platform established by ENISA. They are submitted using the electronic notification end point of the CSIRT designated as coordinator in the Member State of the manufacturer's Union main establishment and are simultaneously accessible to ENISA. If there is no Union main establishment, Article 14 uses a fallback order based on authorised representative, importer, distributor, and then user location. - Define the Union main establishment based on where cybersecurity decisions are predominantly taken - Record the fallback logic for non Union manufacturers - Keep submission credentials, contact lists, and alternates current - Test the routing decision before the first real event ## CRA user information is part of the reporting duty, not an optional courtesy Article 14(8) requires the manufacturer to inform impacted users, and where appropriate all users, of the vulnerability or incident and any mitigating or corrective measures they can take. The information should be structured and machine readable where appropriate and easy to process automatically. If the manufacturer fails to inform users in a timely manner, the notified CSIRTs may do so when necessary and proportionate. - Maintain templates for impacted user notice and broad user notice - Reuse the same product and version identifiers that appear in advisories and support content - Keep records of when, how, and to whom the information was sent - Coordinate product support, incident response, legal, and communications on a single timeline ## CRA reportable events involving integrated components The Commission FAQ notes that if an actively exploited vulnerability sits in a third party component, both the component manufacturer and the final product manufacturer may need to notify where each has placed an affected product on the market. This means component visibility and product genealogy are essential for Article 14 readiness. - Map component exposure to shipped product versions - Store component maintainer contacts and escalation channels - Know whether your product was placed on the market in affected Member States - Prepare to coordinate public communication with upstream and downstream parties *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU Cyber Resilience Act, CRA Product Security and CE Marking Reporting Obligations as a cited research workflow Research Copilot can take EU Cyber Resilience Act, CRA Product Security and CE Marking Reporting Obligations from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU Cyber Resilience Act, CRA Product Security and CE Marking can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Cyber Resilience Act, CRA Product Security and CE Marking Reporting Obligations](/solutions/research-copilot.md): Start from EU Cyber Resilience Act, CRA Product Security and CE Marking Reporting Obligations and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Cyber Resilience Act, CRA Product Security and CE Marking](/contact.md): Review your current process, evidence gaps, and next steps for EU Cyber Resilience Act, CRA Product Security and CE Marking Reporting Obligations. ## Primary sources - [Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng?ref=sorena.io) - Primary legal text for scope, manufacturer duties, reporting, conformity assessment, technical documentation, market surveillance, and penalties. - [European Commission FAQ on the Cyber Resilience Act, version 1.2, January 2026](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Practical implementation clarifications on scope, open source, support period, conformity assessment, reporting, and transition issues. - [European Commission Cyber Resilience Act policy page](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act?ref=sorena.io) - Official timeline overview and implementation context. ## Related Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/reporting-obligations --- --- title: "Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/requirements" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/requirements" author: "Sorena AI" description: "Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting." published_at: "2026-03-04" updated_at: "2026-03-11" keywords: - "CRA requirements" - "Cyber Resilience Act obligations" - "CRA manufacturer obligations" - "CRA importer obligations" - "CRA distributor obligations" - "CRA support period requirements" - "EU compliance" - "Cyber Resilience Act" - "CRA compliance" - "Requirements" - "Products with digital elements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Requirements Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. *Artifact Guide* *EU* ## EU Cyber Resilience Act, CRA Product Security and CE Marking Requirements Grounded implementation guidance for legal, product, and engineering teams. Use official CRA sources to translate obligations into owners, evidence, and shipping decisions. The CRA requirement set is broader than Annex I alone. Article 13 creates the main manufacturer obligations. Articles 18 to 23 distribute duties across importers, distributors, and authorised representatives. Article 24 adds obligations for open source software stewards. Article 14 adds reporting. Article 31 and Article 28 bring the file and declaration duties together. ## CRA manufacturer requirements in Article 13 Manufacturers carry the heaviest load. They must assess cybersecurity risks, determine which Annex I Part I requirements are relevant, justify non applicability, exercise due diligence when integrating components, determine and disclose a support period, draw up technical documentation, complete conformity assessment, and issue the declaration before affixing the CE marking. They also need a single point of contact for vulnerability communication, user instructions under Annex II, corrective action procedures, and cooperation with authorities. - Risk assessment and Annex I applicability logic - Component due diligence, vulnerability handling, and support period management - Technical documentation, declaration of conformity, and CE marking before market entry - User information, single point of contact, corrective action, and authority cooperation *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU Cyber Resilience Act, CRA Product Security and CE Marking Requirements into an operational assessment Assessment Autopilot can take EU Cyber Resilience Act, CRA Product Security and CE Marking Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Cyber Resilience Act, CRA Product Security and CE Marking can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Cyber Resilience Act, CRA Product Security and CE Marking Requirements](/solutions/assessment.md): Start from EU Cyber Resilience Act, CRA Product Security and CE Marking Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Cyber Resilience Act, CRA Product Security and CE Marking](/contact.md): Review your current process, evidence gaps, and next steps for EU Cyber Resilience Act, CRA Product Security and CE Marking Requirements. ## CRA importer, distributor, and authorised representative requirements The CRA does not let the rest of the supply chain ignore conformity. Importers and distributors must verify key conditions before making products available and must not proceed where they know or have reason to believe the product is not compliant. Authorised representatives act within the mandate they receive, but their role still matters for Union routing, authority contact, and record keeping. - Importers check the declaration of conformity, CE marking, and required user information - Importers must be able to make technical documentation available upon request and keep a copy of the declaration - Distributors must act with due care and avoid making non compliant products available - Authorised representatives hold specified tasks under the manufacturer mandate and may matter for Article 14 routing where no Union establishment exists ## CRA open source software steward obligations Article 24 creates a separate and lighter obligation set for open source software stewards. These entities are not treated identically to manufacturers, but they are not outside the regime entirely. The details matter if your organisation funds or coordinates open source development that supports commercial products. - Document the steward role and the limits of responsibility - Check Article 14 obligations that apply to stewards involved in development or affected network and information systems - Prepare documentation that can be produced to market surveillance authorities on request ## CRA user information and support requirements Annex II is operationally important because it decides what users need to know in order to install, operate, update, and eventually decommission the product securely. Missing or weak user information makes later incidents and authority inquiries harder to manage. The support period end date must be clearly and understandably specified at the time of purchase in an easily accessible manner. - Single point of contact and coordinated vulnerability disclosure location - Intended purpose, security environment, and known significant risk circumstances - Support period end date and security update instructions - Secure decommissioning information and, where applicable, how to turn off automatic security updates ## CRA corrective action and market surveillance requirements If a manufacturer knows or has reason to believe a product or its processes are not in conformity, Article 13 requires immediate corrective measures, withdrawal, or recall as appropriate. This is where technical evidence and product history become critical. Market surveillance authorities can request information and documentation, and incomplete files or misleading answers create a separate penalty risk. - Maintain a current product history and release record - Keep corrective action criteria documented - Prepare authority response packs in a language authorities can understand - Make sure legal, security, and product owners share the same facts and evidence set ## Primary sources - [Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng?ref=sorena.io) - Primary legal text for scope, manufacturer duties, reporting, conformity assessment, technical documentation, market surveillance, and penalties. - [European Commission FAQ on the Cyber Resilience Act, version 1.2, January 2026](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Practical implementation clarifications on scope, open source, support period, conformity assessment, reporting, and transition issues. - [European Commission Cyber Resilience Act policy page](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act?ref=sorena.io) - Official timeline overview and implementation context. ## Related Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/requirements --- --- title: "SBOM and Vulnerability Management Template" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template" author: "Sorena AI" description: "Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence." published_at: "2026-03-04" updated_at: "2026-03-11" keywords: - "CRA SBOM template" - "CRA vulnerability management template" - "Cyber Resilience Act SBOM" - "CRA dependency management" - "CRA advisory workflow" - "EU compliance" - "Cyber Resilience Act" - "CRA compliance" - "SBOM and Vulnerability Management Template" - "Products with digital elements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # SBOM and Vulnerability Management Template Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. *Artifact Guide* *EU* ## EU Cyber Resilience Act, CRA Product Security and CE Marking SBOM and Vulnerability Management Template Grounded implementation guidance for legal, product, and engineering teams. Use official CRA sources to translate obligations into owners, evidence, and shipping decisions. The CRA does not ask for an SBOM as a decoration. It asks manufacturers to identify and document vulnerabilities and components, and to run a vulnerability handling system that can survive the full support period. This page gives you a practical template structure that can be implemented in tooling and linked into the technical file. ## CRA template section 1, the minimum SBOM record Annex I Part II requires an SBOM in a commonly used and machine readable format covering at least the top level dependencies. The format may later be specified further by Commission implementing acts, but you do not need to wait to define the minimum fields you rely on operationally. Keep the SBOM tied to a specific released version so you can answer exposure questions quickly. - Product name, model, version, build identifier, and release date - Top level software components and core hardware components, with supplier or maintainer where known - Component version, license, provenance, and support status - Link from each component to evidence such as scan results, integrity checks, or approval records *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Cyber Resilience Act, CRA Product Security and CE Marking SBOM and Vulnerability Management Template in one governed evidence system SSOT can take EU Cyber Resilience Act, CRA Product Security and CE Marking SBOM and Vulnerability Management Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Cyber Resilience Act, CRA Product Security and CE Marking can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Cyber Resilience Act, CRA Product Security and CE Marking SBOM and Vulnerability Management Template](/solutions/ssot.md): Start from EU Cyber Resilience Act, CRA Product Security and CE Marking SBOM and Vulnerability Management Template and keep documents, evidence, and control records in one governed system. - [Talk through EU Cyber Resilience Act, CRA Product Security and CE Marking](/contact.md): Review your current process, evidence gaps, and next steps for EU Cyber Resilience Act, CRA Product Security and CE Marking SBOM and Vulnerability Management Template. ## CRA template section 2, vulnerability intake and triage Your vulnerability management template should capture far more than a ticket title. It should store awareness timing, exploit status, affected versions, component links, and the initial decision on whether Article 14 may be triggered. This is the information that later feeds advisories, user notices, and authority responses. - Report source, time received, time triaged, and awareness timestamp - Affected product versions and affected components - Exploit status, severity, exposure, and business or safety impact - Decision on patch, mitigation, workaround, or no immediate change with documented rationale ## CRA template section 3, remediation and release evidence The CRA expects vulnerabilities to be addressed without delay in relation to the risks posed. Your template should therefore capture the corrective action path and the evidence that the action was actually shipped. Keep remediation records linked to release notes, package signing, and update distribution logs. - Fix owner, due date, and release vehicle - Security update identifier and rollout date - Testing evidence for the fix and any regression checks - Status of user advisory publication and update availability retention ## CRA template section 4, integrated component governance The CRA expects due diligence when integrating third party components and requires manufacturers to report component vulnerabilities to maintainers and share fixes where appropriate. Your template therefore needs explicit upstream and downstream coordination fields. This is especially important when a component support period ends before your product support period ends. - Component maintainer contact and disclosure status - Whether the manufacturer shared a fix or documentation upstream - Alternative remediation if upstream support is unavailable - Decision on replacement, isolation, or continued support at product level ## CRA template section 5, reporting and audit linkage A useful SBOM and vulnerability template should feed directly into Article 14 reporting and Article 31 technical documentation. If it does not, you will end up re typing the same facts under time pressure. Build the template so every record can point to the declaration, technical file, advisory, and any Article 14 report identifiers. - Link to the relevant technical documentation section and product risk assessment - Link to advisory, user notices, and support knowledge base article - Link to any ENISA and CSIRT submission records - Retention rule for at least ten years after placing on the market or the support period, whichever is longer, when the record forms part of the technical file ## Primary sources - [Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng?ref=sorena.io) - Primary legal text for scope, manufacturer duties, reporting, conformity assessment, technical documentation, market surveillance, and penalties. - [European Commission FAQ on the Cyber Resilience Act, version 1.2, January 2026](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Practical implementation clarifications on scope, open source, support period, conformity assessment, reporting, and transition issues. - [ENISA vulnerability disclosure topic page](https://www.enisa.europa.eu/topics/vulnerability-disclosure?ref=sorena.io) - Useful support material for building coordinated vulnerability disclosure processes. ## Related Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template --- --- title: "Technical Documentation and Audit File" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file" author: "Sorena AI" description: "Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence." published_at: "2026-03-04" updated_at: "2026-03-11" keywords: - "CRA technical documentation" - "CRA audit file" - "CRA Article 31" - "CRA Annex VII" - "CRA declaration of conformity" - "CRA evidence pack" - "EU compliance" - "Cyber Resilience Act" - "CRA compliance" - "Technical Documentation and Audit File" - "Products with digital elements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Technical Documentation and Audit File Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. *Artifact Guide* *EU* ## EU Cyber Resilience Act, CRA Product Security and CE Marking Technical Documentation and Audit File Grounded implementation guidance for legal, product, and engineering teams. Use official CRA sources to translate obligations into owners, evidence, and shipping decisions. The CRA technical file should tell a coherent story from product definition to support period operations. Article 31 says it must be drawn up before the product is placed on the market and continuously updated, where appropriate, at least during the support period. That makes the file a living repository, not a one time binder. ## What CRA Article 31 and Annex VII require The technical documentation must contain all relevant data or details of the means used by the manufacturer to ensure that the product and the manufacturer's processes comply with Annex I. Annex VII lists the minimum elements. The file should therefore make it easy to identify the product, the applicable requirements, the risk basis, the standards or alternative solutions used, and the evidence supporting conformity. - General description of the product and intended purpose - Cybersecurity risk assessment, including why certain requirements are or are not applicable - Information used to determine the support period - List of harmonised standards, common specifications, certification schemes, or alternative technical solutions used ## A practical CRA technical-documentation file structure that works during the support period The most efficient structure is a stable index plus linked evidence repositories. That lets engineering update tests and advisories without rebuilding the entire file every release. Keep the structure consistent across products so legal, product, and engineering teams can all navigate it quickly. - Section for product definition and versions - Section for architecture, connectivity, remote data processing, and component inventory - Section for Annex I mapping, test results, update mechanisms, and vulnerability handling procedures - Section for declaration of conformity, user information, and authority communication records ## Continuous CRA technical-documentation update discipline The Commission FAQ explains that technical documentation should reflect relevant redesigns, re assessments, and cybersecurity information that emerges after placement on the market. That includes vulnerability findings, test results, and changes in the product or its processes. A product that evolves during the support period should therefore have file updates tied to releases, incidents, and major architectural change. - Update the file when a release changes risk, architecture, dependencies, or security controls - Update the risk assessment when tests, reviews, or third party information reveal relevant cybersecurity information - Keep a version history that shows what changed and why - Store references to advisories, security updates, and Article 14 reports where relevant ## CRA technical-documentation retention and authority access Manufacturers must keep the technical documentation and the declaration of conformity at the disposal of market surveillance authorities for at least ten years after the product has been placed on the market or for the support period, whichever is longer. Importers also need to keep a copy of the declaration and ensure the technical documentation can be made available on request. This is a record retention and retrieval problem as much as a writing problem. - Set a retention rule that tracks the later of ten years after market entry or the support period - Keep the file readable by the relevant authority and easy to produce on request - Make sure importer and authorised representative workflows can locate the correct declaration and file version - Check that links to external artifacts remain valid over time *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Cyber Resilience Act, CRA Product Security and CE Marking Technical Documentation and Audit File in one governed evidence system SSOT can take EU Cyber Resilience Act, CRA Product Security and CE Marking Technical Documentation and Audit File from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Cyber Resilience Act, CRA Product Security and CE Marking can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Cyber Resilience Act, CRA Product Security and CE Marking Technical Documentation and Audit File](/solutions/ssot.md): Start from EU Cyber Resilience Act, CRA Product Security and CE Marking Technical Documentation and Audit File and keep documents, evidence, and control records in one governed system. - [Talk through EU Cyber Resilience Act, CRA Product Security and CE Marking](/contact.md): Review your current process, evidence gaps, and next steps for EU Cyber Resilience Act, CRA Product Security and CE Marking Technical Documentation and Audit File. ## Primary sources - [Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng?ref=sorena.io) - Primary legal text for scope, manufacturer duties, reporting, conformity assessment, technical documentation, market surveillance, and penalties. - [European Commission FAQ on the Cyber Resilience Act, version 1.2, January 2026](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Practical implementation clarifications on scope, open source, support period, conformity assessment, reporting, and transition issues. - [Blue Guide 2022 on the implementation of EU product rules](https://op.europa.eu/en/publication-detail/-/publication/91a50d92-f745-11ec-b94a-01aa75ed71a1/language-en?ref=sorena.io) - Useful background on technical documentation practice across Union product frameworks. ## Related Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Vulnerability Handling and Disclosure | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file --- --- title: "Vulnerability Handling and Disclosure" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure" author: "Sorena AI" description: "Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates." published_at: "2026-03-04" updated_at: "2026-03-11" keywords: - "CRA vulnerability handling" - "CRA disclosure" - "CRA Annex I Part II" - "CRA coordinated vulnerability disclosure" - "CRA security updates" - "CRA integrated components" - "EU compliance" - "Cyber Resilience Act" - "CRA compliance" - "Vulnerability Handling and Disclosure" - "Products with digital elements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Vulnerability Handling and Disclosure Build a CRA vulnerability handling system that covers SBOM, intake, triage, remediation, coordinated vulnerability disclosure, secure updates. *Artifact Guide* *EU* ## EU Cyber Resilience Act, CRA Product Security and CE Marking Vulnerability Handling and Disclosure Grounded implementation guidance for legal, product, and engineering teams. Use official CRA sources to translate obligations into owners, evidence, and shipping decisions. The CRA turns vulnerability handling into a regulated product function. Annex I Part II expects manufacturers to know their components, handle vulnerabilities during the support period, maintain a coordinated vulnerability disclosure process, distribute updates securely, and tell users what was fixed and what action they should take. ## The mandatory CRA vulnerability-handling operating model in Annex I Part II Part II is a live operations requirement. It asks manufacturers to identify components and vulnerabilities, address and remediate vulnerabilities without delay, perform regular security tests and reviews, disclose fixed vulnerabilities, run coordinated vulnerability disclosure, provide a reporting contact, and distribute security updates securely and without delay. This model needs real tooling, roles, and decision records. - SBOM plus component and vulnerability visibility - Triage and remediation linked to product risk, not only scanner output - Public information on fixed vulnerabilities with justified delay only in limited cases - Secure update distribution and free security updates unless a tailor made business arrangement says otherwise ## How to interpret "without delay" in CRA vulnerability handling practice The Commission FAQ says the CRA does not require a patch for every vulnerability, but it does require manufacturers to assess the risk and ensure remedies are put in place without delay. That means you need a documented method for deciding whether the correct response is a patch, another corrective measure, a mitigation, or if necessary a withdrawal or recall. A good program separates speed from guesswork. Fast response should still be traceable. - Define service levels by severity, exploitability, and exposure - Record risk acceptance or no patch decisions with technical reasoning - Escalate actively exploited vulnerabilities immediately into the Article 14 track - Treat recurring deferrals as a governance issue, not a normal state ## CRA integrated components and upstream coordination Component risk is still product risk. Article 13(6) requires manufacturers to report vulnerabilities in integrated components to the component maker or maintainer and, where appropriate, to share the security fix upstream. The March 2026 draft guidance adds practical limits: the duty concerns the integrated version of the component and the vulnerability must exist in the component itself, not only in the way the manufacturer combined it with other code. The draft guidance also explains that manufacturers do not have to report upstream where the component no longer has a maintainer or where the manufacturer maintains an independent fork and no longer relies on upstream for new versions or security fixes. Where a fix is shared upstream, it should be in a form the maintainer can assess and integrate, but the CRA does not require the maintainer to accept it. - Track which version of the component is integrated into each shipped product version - Differentiate a component vulnerability from an integration defect in your own product architecture - Store maintainer status, fork status, and the rationale if upstream reporting is not required - Share upstream fixes in a verifiable machine-readable form where appropriate and keep the submission record ## What a good CRA vulnerability disclosure package contains Once a security update or other corrective or mitigating measure is available, the CRA expects information about fixed vulnerabilities to be shared publicly with enough detail for users to identify the affected product, understand the impact, and remediate. If publication would create greater security risk, publication may be delayed, but that decision needs a documented and time bounded justification. Use the same identifiers across the advisory, support content, and any Article 14 reporting. - Affected product and version identifiers - Description, impact, severity, and exploitation status where known - Fix availability, mitigation steps, and customer action - Publication date and links to update artifacts and support content ## Useful external process baselines for CRA vulnerability handling The CRA does not mandate ISO or ENISA process models, but ISO/IEC 29147 and ISO/IEC 30111 are useful fair use reference points for disclosure and handling workflow design. ENISA guidance is also useful for building a disclosure policy that researchers can actually use. Use these sources as process references, not as a substitute for the CRA text. - Use ISO/IEC 29147 for public disclosure structure - Use ISO/IEC 30111 for intake, verification, triage, and remediation workflow - Use ENISA material for policy design and stakeholder communication - Always map the final workflow back to Annex I Part II and Article 13 *Recommended next step* *Placement: near the end of the main content before related guides* ## Turn EU Cyber Resilience Act, CRA Product Security and CE Marking Vulnerability Handling and Disclosure into an operational assessment Assessment Autopilot can take EU Cyber Resilience Act, CRA Product Security and CE Marking Vulnerability Handling and Disclosure from turning this guidance into an operational assessment workflow to a reusable workflow inside Sorena. Teams working on EU Cyber Resilience Act, CRA Product Security and CE Marking can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Cyber Resilience Act, CRA Product Security and CE Marking Vulnerability Handling and Disclosure](/solutions/assessment.md): Start from EU Cyber Resilience Act, CRA Product Security and CE Marking Vulnerability Handling and Disclosure and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Cyber Resilience Act, CRA Product Security and CE Marking](/contact.md): Review your current process, evidence gaps, and next steps for EU Cyber Resilience Act, CRA Product Security and CE Marking Vulnerability Handling and Disclosure. ## Primary sources - [Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng?ref=sorena.io) - Primary legal text for scope, manufacturer duties, reporting, conformity assessment, technical documentation, market surveillance, and penalties. - [European Commission FAQ on the Cyber Resilience Act, version 1.2, January 2026](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - Practical implementation clarifications on scope, open source, support period, conformity assessment, reporting, and transition issues. - [Draft Commission guidance on the application of the Cyber Resilience Act, March 2026 draft](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - Draft Commission guidance with additional interpretation on Article 13(6) upstream reporting, independent forks, maintainer status, and vulnerability handling expectations. - [ENISA vulnerability disclosure topic page](https://www.enisa.europa.eu/topics/vulnerability-disclosure?ref=sorena.io) - Practical supporting material for coordinated vulnerability disclosure design. - [ISO/IEC 29147:2018, Vulnerability disclosure](https://www.iso.org/standard/72311.html?ref=sorena.io) - Process reference point for disclosure design, used here only as fair use background. - [ISO/IEC 30111:2019, Vulnerability handling processes](https://www.iso.org/standard/69725.html?ref=sorena.io) - Process reference point for intake, triage, and remediation design, used here only as fair use background. ## Related Topic Guides - [Applicability Test | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/applicability-test.md): Use this CRA applicability test to confirm product scope, exclusions, remote data processing boundaries, operator role, product classification. - [Checklist | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): Use this Cyber Resilience Act checklist to assign owners, deadlines, evidence, and release gates for scope, Annex I controls, support period operations. - [Compliance Program | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/compliance.md): Build a CRA compliance program that covers product scope, governance, engineering controls, support period operations, Article 14 reporting. - [Conformity Assessment and CE Marking | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): Choose the right CRA conformity route, prepare the declaration of conformity, structure the technical file. - [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - [CRA FAQ Hub | Blue Guide Concepts, CE Marking, Component Due Diligence](/artifacts/eu/cyber-resilience-act/faq.md): Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. - [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md): CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md): CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md): CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - [CRA vs RED Cybersecurity Delegated Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): Compare the Cyber Resilience Act with the RED cybersecurity delegated act so you can decide which products fall under which rule, what dates apply. - [CRA vs UK PSTI Act | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare the EU Cyber Resilience Act with the UK PSTI product security regime so your team can plan dual market compliance without mixing two different rule. - [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - [Deadlines and Compliance Calendar | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the CRA entry into force date, the notified body date, the reporting start date, and the main application date. - [Essential Cybersecurity Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): Understand the CRA essential cybersecurity requirements in Annex I. - [Penalties and Fines | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): Understand the CRA administrative fine tiers in Article 64, the conduct that attracts the highest penalties, and the evidence that reduces enforcement exposure. - [Products with Digital Elements Scope | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Understand what counts as a product with digital elements under the CRA, how remote data processing fits, and where the scope boundary usually causes mistakes. - [Reporting Obligations | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Prepare for CRA Article 14 reporting, including the twenty four hour early warning, the seventy two hour notification, final reports, CSIRT routing. - [Requirements | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/requirements.md): Review the full CRA requirement set, including manufacturer duties, operator duties, support period rules, user information, corrective action, reporting. - [SBOM and Vulnerability Management Template | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Use this CRA SBOM and vulnerability management template to structure dependency records, triage, remediation, advisory publication, and support period evidence. - [Technical Documentation and Audit File | EU Cyber Resilience Act, CRA Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build a CRA technical documentation file that covers product definition, risk assessment, support period, Annex I mapping, standards use, test evidence. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure --- --- title: "Access Rights and Portability" canonical_url: "https://www.sorena.io/artifacts/eu/data-act/access-rights-and-portability" source_url: "https://www.sorena.io/artifacts/eu/data-act/access-rights-and-portability" author: "Sorena AI" description: "EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, \"readily available\" data." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU Data Act access rights" - "Data Act portability IoT real time" - "direct access vs indirect access Data Act" - "readily available data access" - "user request share data to third party Data Act" - "Data Act Chapter II Articles 3 4 5" - "EU compliance" - "data-act compliance" - "Access Rights and Portability" - "compliance timeline" - "compliance decision flow" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Access Rights and Portability EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, "readily available" data. *Artifact Guide* *EU* ## EU Data Act: Fair Access to Connected Product Data and Cloud Switching Access Rights and Portability Operational workflow: requests, identity, response, logging. This guide supports implementation for EU Data Act: Fair Access to Connected Product Data and Cloud Switching using source grounded analysis and execution oriented recommendations. The EU Data Act creates enhanced access and portability rights for IoT-style data. Users can access and port data generated by connected products and related services (personal and non-personal), and can request sharing with third parties. The implementation challenge is building secure, auditable workflows that work for consumers and business users and that coordinate cleanly with GDPR when personal data is involved. ## Pre-contract transparency (Article 3) - set expectations before the sale Before users commit (buy/rent/lease), the Data Act requires transparency about what data is generated, who the data holder is, and how access works. This is a legal obligation and a UX requirement. Treat transparency as part of product onboarding: it reduces disputes and makes later access requests predictable. - Publish: what product/related service data is generated and what "readily available" means for your product - Identify: the data holder(s) and contact channel(s) users can use - Explain: direct access vs portal request workflows and expected response times ## Direct vs indirect access (a design decision with big cost impact) The Data Act FAQs describe two patterns: direct access (technical means to stream/download without asking the data holder) and indirect access (request via portal/approval process). Direct access usually reduces operational load but increases product security responsibility; indirect access increases operational load but can simplify sensitive data handling. - Direct access: user-controlled interface to extract/stream data (API/device interface) - Indirect access: user submits request; data holder fulfills via a controlled process - Choose per data sensitivity and threat model; document rationale per product line ## Portability in the IoT context (Data Act complements GDPR Article 20) Under GDPR, portability is limited to personal data and specific legal bases. The Data Act creates an enhanced portability right for IoT contexts, enabling access and porting of both personal and non-personal data generated by use of a connected product or related service, and (where applicable) in real time. Operationally, this means export formats, streaming interfaces, and a clear separation of personal data controls from non-personal data sharing. - Provide exportable formats and stable identifiers for time-series/device data - Support "where applicable" real-time portability via streaming or near-real-time APIs - Add GDPR controls for personal data: identity verification, legal basis checks, and data subject alignment ## User-to-third-party sharing workflow (Articles 4-6 patterns) A key Data Act use case is enabling users to share data with a third party (repair, maintenance, analytics, insurance, optimization). Build a workflow that is secure, traceable, and revocable. Treat third-party sharing as delegated access: define the scope, duration, and permitted use, and log what is shared. - Identity and authority: confirm who is the user and who can act on behalf of the user (B2B operators, fleets, rentals) - Scope and duration: dataset selection, time window, and revocation/expiry rules - Security controls: authentication, encryption, rate limits, and abuse detection - Audit evidence: request record, approval record, data delivered, and recipient identity ## Evidence pack (what to keep for disputes and audits) Disputes are likely when scope or identity is unclear. Keep evidence that shows you delivered what was requested, under what authority, and with what safeguards. Prefer immutable logs and pipeline-generated artifacts. - Product scope memo + data dictionary for exportable datasets - Access portal screenshots/spec + API documentation and schemas - Access logs: request timestamps, identity verification, and data delivery confirmations - Security controls evidence: encryption, authN/authZ model, and abuse monitoring *Recommended next step* *Placement: after the scope or definition section* ## Use EU Data Act: Fair Access to Connected Product Data and Cloud Switching Access Rights and Portability as a cited research workflow Research Copilot can take EU Data Act: Fair Access to Connected Product Data and Cloud Switching Access Rights and Portability from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Data Act: Fair Access to Connected Product Data and Cloud Switching can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Access Rights and Portability](/solutions/research-copilot.md): Start from EU Data Act: Fair Access to Connected Product Data and Cloud Switching Access Rights and Portability and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/contact.md): Review your current process, evidence gaps, and next steps for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Access Rights and Portability. ## Primary sources - [Regulation (EU) 2023/2854 (Data Act) - Official Journal (ELI)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Chapter II transparency, access, and user sharing rules (Articles 3-6) and application dates (Article 50). - [European Commission - Data Act FAQs (library page)](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-frequently-asked-questions-about-data-act?ref=sorena.io) - Direct vs indirect access and how the Data Act complements GDPR portability in IoT contexts. ## Related Topic Guides - [Applicability Test | EU Data Act: Connected Products, B2B Data Sharing, B2G Exceptional Need, Cloud Switching](/artifacts/eu/data-act/applicability-test.md): A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services). - [B2B Data Sharing Contract Clauses | EU Data Act: Mandatory Sharing, Unfair Terms, Trade Secrets](/artifacts/eu/data-act/b2b-data-sharing-contract-clauses.md): EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security. - [B2B Data Sharing Contract Template | EU Data Act: Data Access and Use Agreement (Drafting Checklist)](/artifacts/eu/data-act/b2b-data-sharing-contract-template.md): A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use. - [B2G Exceptional Need Requests | EU Data Act: Public Emergency Data Requests, Safeguards, Compensation](/artifacts/eu/data-act/b2g-exceptional-need-requests.md): EU Data Act Chapter V B2G 'exceptional need' requests made practical. - [Cloud Switching and Exit Plans | EU Data Act Chapter VI: Switch Providers, Port Data, Remove Egress Barriers](/artifacts/eu/data-act/cloud-switching-and-exit-plans.md): EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition. - [Cloud Switching Compliance Checklist | EU Data Act Chapter VI: Contracts, Exportable Data, Fees, Transparency](/artifacts/eu/data-act/cloud-switching-compliance-checklist.md): A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period). - [Compliance Program | EU Data Act Implementation Playbook: Governance, Controls, Evidence, Operating Cadence](/artifacts/eu/data-act/compliance.md): Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access. - [Deadlines and Compliance Calendar | EU Data Act](/artifacts/eu/data-act/deadlines-and-compliance-calendar.md): Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025. - [EU Data Act Checklist | Chapter II Access, B2B Sharing, Unfair Terms, B2G Requests, Cloud Switching](/artifacts/eu/data-act/checklist.md): A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access). - [EU Data Act vs GDPR | Differences, Overlap, Portability, Lawful Basis, Implementation Playbook](/artifacts/eu/data-act/data-act-vs-gdpr.md): EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights. - [FAQ | EU Data Act Explained: Key Dates, Access Rights, Trade Secrets, B2G Requests, Cloud Switching](/artifacts/eu/data-act/faq.md): EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access. - [Penalties and Fines | EU Data Act Enforcement: Member State Penalties, GDPR-Linked Fines, Risk Controls](/artifacts/eu/data-act/penalties-and-fines.md): EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider. - [Requirements | EU Data Act Obligations Explained: Chapter II Access, Chapter IV Unfair Terms, Chapter V B2G, Chapter VI Switching](/artifacts/eu/data-act/requirements.md): A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows. - [Scope, Connected Products and Data Types | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/scope-connected-products-and-data-types.md): EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data. - [Trade Secrets and Protection | EU Data Act: Confidentiality Measures, Withholding Rules, Evidence Pack](/artifacts/eu/data-act/trade-secrets-and-protection.md): EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act/access-rights-and-portability --- --- title: "Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/data-act/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/data-act/applicability-test" author: "Sorena AI" description: "A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services)." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU Data Act applicability test" - "EU Data Act scope test" - "Data Act in scope checklist" - "connected product related service Data Act" - "data holder definition EU Data Act" - "B2B data sharing EU Data Act Chapter III" - "unfair contractual terms Data Act Chapter IV" - "B2G exceptional need Data Act Chapter V" - "cloud switching Data Act Chapter VI" - "Data Act applies 12 September 2025 Article 50" - "EU compliance" - "data-act compliance" - "Applicability Test" - "compliance timeline" - "compliance decision flow" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Applicability Test A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services). *Artifact Guide* *EU* ## EU Data Act: Fair Access to Connected Product Data and Cloud Switching Applicability Test Decide what applies (and what doesn't), per product and per contract. Outputs: chapter mapping, roles (user/data holder/data recipient/cloud provider), and the evidence you'll need to implement without rescoping later. Treat EU Data Act applicability as a repeatable scoping exercise. You're rarely "in scope" for everything: the same organization can be a data holder for connected products, a data recipient in B2B sharing, and a customer of cloud services (with switching rights). The Data Act applies from 12 September 2025, with additional triggers such as the connected-product design duty for products placed on the market after 12 September 2026 (Article 50). ## Fast result - which chapters are you likely dealing with? Use this as your first-pass chapter map. Then confirm with the steps below and write a one-page scope memo per product line and per contract type. - Chapter II (Articles 3-6): connected products/related services -> transparency + user access + third-party sharing workflows - Chapter III (B2B access rules) (Articles 5-12): mandatory sharing with data recipients in B2B scenarios -> operational sharing + safeguards + compensation logic - Chapter IV (Article 13): enterprise-to-enterprise terms unilaterally imposed and unfair -> terms may be non binding (risk concentrates in click through B2B terms) - Chapter V (Articles 14-22): B2G requests based on an 'exceptional need' -> request validation, minimisation, secure disclosure, compensation handling - Chapter VI (Articles 23-31): cloud/data processing services -> switching and exit rights (customers) and switching/portability obligations (providers) ## Step 0 - gather minimum inputs (don't guess) Most scoping errors come from missing inputs. Collect product definitions, contracts, and data architecture facts before you decide scope. Applicability is scenario-based: the same company can be in scope for some activities and out of scope for others. - Portfolio: connected products + related services; EU market placement model; versions and deployment modes - Data map: product data vs related service data; "readily available" extraction path; personal vs non-personal fields - Contracts: B2B data sharing agreements; platform/API terms; cloud contracts; long-duration legacy agreements - Roles: who is the user; who controls access (data holder); who receives data (data recipient/third party) ## Step 1 - connected products + related services: is Chapter II triggered? Start with concrete product definitions and a data map. Chapter II becomes implementable only when you can name the dataset generated by use, define what is "readily available", and specify the delivery mechanism (direct vs indirect access). If you operate in automotive, the Commission's vehicle data guidance is a helpful grounded example of how Chapter II obligations translate into dataset definitions and access rules. - Inventory: connected products and related services placed on the EU market - Dataset definition: product data and related service data; metadata needed to interpret/use the data - Delivery decision: direct access vs indirect request portal; identity verification and security model - GDPR coordination where personal data is involved (lawful basis, roles, privacy notices) ## Step 2 - identify roles: user, data holder, data recipient, third party A single ecosystem can have multiple data holders. Identify who controls access to the dataset the user is entitled to, per scenario, because that entity must implement the workflow. Then document who the user is (consumer or business), who may receive data (data recipients or third parties chosen by the user), and how you authenticate them. - User: owns/rents/leases the connected product or receives the related service - Data holder: controls access to the readily available data (often the platform/API operator) - Data recipient/third party: receives data via user instruction; needs technical + legal onboarding - Evidence: role mapping memo + "who can request what" access control matrix ## Step 3 - B2B sharing and contracts: Chapter III and Chapter IV triggers If your business uses contracts to control data access, check two things: (1) are you obliged to share data B2B under Chapter III, and (2) do you have unilaterally imposed terms that can be unfair under Chapter IV (and therefore non binding). Operationally, this is the contract layer: remedies, liability, trade secret safeguards, pricing/compensation, and dispute handling. - Chapter III: data sharing agreements and mandatory sharing obligations in B2B relations - Chapter IV (Article 13): unilaterally imposed enterprise terms that grossly deviate from good commercial practice, contrary to good faith and fair dealing - High-risk clauses: exclusive interpretation rights, unilateral price changes, limitations on remedies, restrictions on copying/using one's own generated data - Deliverable: contract clause matrix (clause -> Data Act risk -> remediation text) ## Step 4 - cloud/data processing services: Chapter VI switching obligations Chapter VI applies to providers of data processing services and creates enforceable customer switching rights and provider obligations. Even if you're not a provider, use Chapter VI as a vendor governance instrument in procurement and renewals. A fast signal: if you offer cloud-like services (IaaS/PaaS/SaaS) from a service catalog, you must review switching notice periods, transitional periods, exportable data definitions, and switching charges. - Contract gates: maximum notice period = 30 days - Fees: reduced switching charges permitted 11 Jan 2024-12 Jan 2027; no switching charges from 12 Jan 2027 - Transparency: online register of exportable data structures/formats and website disclosures on jurisdiction and measures against conflicting international access ## Step 5 - B2G 'exceptional need' requests: could a public body ask you for data? Chapter V is not a general data access right. It is limited to an 'exceptional need' that is limited in time and scope, and the request must meet specific content requirements (what data, why, safeguards, sharing, deadlines). If you hold high-value datasets (mobility, energy, telecom, financial risk signals, supply chain), build a triage playbook now: it's faster than improvising under time pressure. - Exceptional need lanes: public emergency vs non-emergency statutory task (non-personal data only) - SME carve-out: non-emergency lane does not apply to microenterprises and small enterprises - Operational outputs: secure extraction, minimisation, transfer channel, deletion/erasure plan, compensation calculation ## Deliverable - the 1-page scope memo (the thing that prevents rework) When teams skip the scope memo, they ship the wrong workflow: they build portals for data they don't control, they miss unfair terms risk, or they underestimate cloud switching obligations. Write one memo per product line and per contract type and keep it versioned like product documentation. - Chapters that apply and why (include the specific product/service/contract trigger) - Roles per scenario (user, data holder, data recipient, cloud provider/customer) - Dataset definition + extraction method (including metadata, format, and security controls) - Contract remediation list (what clauses must change, owners, and date gates) - Evidence pack (logs, portal specs, security controls, compensation model, dispute playbook) *Recommended next step* *Placement: after the applicability result* ## Turn EU Data Act: Fair Access to Connected Product Data and Cloud Switching Applicability Test into an operational assessment Assessment Autopilot can take EU Data Act: Fair Access to Connected Product Data and Cloud Switching Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU Data Act: Fair Access to Connected Product Data and Cloud Switching can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Applicability Test](/solutions/assessment.md): Start from EU Data Act: Fair Access to Connected Product Data and Cloud Switching Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/contact.md): Review your current process, evidence gaps, and next steps for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Applicability Test. ## Primary sources - [Regulation (EU) 2023/2854 (Data Act) - Official Journal (ELI)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Chapter II (access), Chapter IV (unfair terms), Chapter V (B2G exceptional need), Chapter VI (cloud switching) and application dates (Article 50). - [European Commission - Data Act policy page](https://digital-strategy.ec.europa.eu/en/policies/data-act?ref=sorena.io) - Plain-language overview of what the EU Data Act is intended to achieve and who it affects. - [European Commission - Data Act FAQs (library page)](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-frequently-asked-questions-about-data-act?ref=sorena.io) - Implementation clarifications used for scoping (direct vs indirect access, portability vs GDPR, trade secrets safeguards). - [Commission Communication C/2025/5026 - Guidance on vehicle data accompanying the Data Act (ELI)](https://data.europa.eu/eli/C/2025/5026/oj?ref=sorena.io) - Sector-specific example of how Chapter II access obligations become implementable (dataset definition + access rules). ## Related Topic Guides - [Access Rights and Portability | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/access-rights-and-portability.md): EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, "readily available" data. - [B2B Data Sharing Contract Clauses | EU Data Act: Mandatory Sharing, Unfair Terms, Trade Secrets](/artifacts/eu/data-act/b2b-data-sharing-contract-clauses.md): EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security. - [B2B Data Sharing Contract Template | EU Data Act: Data Access and Use Agreement (Drafting Checklist)](/artifacts/eu/data-act/b2b-data-sharing-contract-template.md): A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use. - [B2G Exceptional Need Requests | EU Data Act: Public Emergency Data Requests, Safeguards, Compensation](/artifacts/eu/data-act/b2g-exceptional-need-requests.md): EU Data Act Chapter V B2G 'exceptional need' requests made practical. - [Cloud Switching and Exit Plans | EU Data Act Chapter VI: Switch Providers, Port Data, Remove Egress Barriers](/artifacts/eu/data-act/cloud-switching-and-exit-plans.md): EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition. - [Cloud Switching Compliance Checklist | EU Data Act Chapter VI: Contracts, Exportable Data, Fees, Transparency](/artifacts/eu/data-act/cloud-switching-compliance-checklist.md): A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period). - [Compliance Program | EU Data Act Implementation Playbook: Governance, Controls, Evidence, Operating Cadence](/artifacts/eu/data-act/compliance.md): Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access. - [Deadlines and Compliance Calendar | EU Data Act](/artifacts/eu/data-act/deadlines-and-compliance-calendar.md): Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025. - [EU Data Act Checklist | Chapter II Access, B2B Sharing, Unfair Terms, B2G Requests, Cloud Switching](/artifacts/eu/data-act/checklist.md): A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access). - [EU Data Act vs GDPR | Differences, Overlap, Portability, Lawful Basis, Implementation Playbook](/artifacts/eu/data-act/data-act-vs-gdpr.md): EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights. - [FAQ | EU Data Act Explained: Key Dates, Access Rights, Trade Secrets, B2G Requests, Cloud Switching](/artifacts/eu/data-act/faq.md): EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access. - [Penalties and Fines | EU Data Act Enforcement: Member State Penalties, GDPR-Linked Fines, Risk Controls](/artifacts/eu/data-act/penalties-and-fines.md): EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider. - [Requirements | EU Data Act Obligations Explained: Chapter II Access, Chapter IV Unfair Terms, Chapter V B2G, Chapter VI Switching](/artifacts/eu/data-act/requirements.md): A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows. - [Scope, Connected Products and Data Types | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/scope-connected-products-and-data-types.md): EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data. - [Trade Secrets and Protection | EU Data Act: Confidentiality Measures, Withholding Rules, Evidence Pack](/artifacts/eu/data-act/trade-secrets-and-protection.md): EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act/applicability-test --- --- title: "B2B Data Sharing Contract Clauses" canonical_url: "https://www.sorena.io/artifacts/eu/data-act/b2b-data-sharing-contract-clauses" source_url: "https://www.sorena.io/artifacts/eu/data-act/b2b-data-sharing-contract-clauses" author: "Sorena AI" description: "EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU Data Act contract clauses" - "EU Data Act B2B data sharing agreement" - "Data Act Chapter III contract terms" - "Data Act Article 13 unfair contractual terms" - "Data Act trade secrets clauses" - "Data Act reasonable compensation clauses" - "data access and use agreement EU" - "EU compliance" - "data-act compliance" - "B2B data sharing" - "contract clauses" - "unfair terms" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # B2B Data Sharing Contract Clauses EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security. *Artifact Guide* *EU* ## EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2B Data Sharing Contract Clauses A clause library you can use to fix real B2B data contracts-without creating unfair-terms risk. Focus: Chapter III data sharing and Chapter IV unfair contractual terms (Article 13) for enterprise-to-enterprise agreements. The EU Data Act turns "data access" into a contract discipline. For B2B data sharing, your agreements need to do two things at once: enable lawful, secure access and reuse (Chapter III) and avoid unilaterally imposed unfair terms that can become non binding (Chapter IV, Article 13). This page gives a practical clause library and drafting notes you can apply to APIs, portals, data feeds, and platform terms. ## 1) Start with the non-negotiable: unfair terms can become non binding (Article 13) Article 13 targets contractual terms concerning access/use of data (and liability/remedies) that are unilaterally imposed on another enterprise and are unfair. If a term is unfair, it is not binding on the other enterprise. This changes your drafting strategy: remove 'gross deviation' clauses (exclusive interpretation rights, extreme remedy limits, one-sided termination, etc.) and document negotiation for key terms. - Red flags: limiting your liability for intentional acts or gross negligence; excluding remedies for non-performance - Red flags: giving one party the exclusive right to decide if data is conforming or to interpret terms - Presumptively unfair patterns: preventing termination within a reasonable period; blocking access to copies of the other party's generated/provided data - Proof point: keep a negotiation trail for contested clauses to rebut "unilaterally imposed" claims ## 2) Data scope clause - define exactly what is shared (and what isn't) Most disputes are scope disputes. The contract must define the dataset, the metadata needed to interpret it, the delivery method, and any limits that are consistent with the Data Act. Draft like an API spec: versioned schemas, formats, and a change-control process. - Dataset definition: fields, units, timestamps, identifiers, and metadata necessary to interpret/use the data - Delivery mode: API endpoints, files, streaming, or portal downloads; frequency and latency expectations - Data quality: completeness, refresh cadence, and error handling (and what counts as a defect) - Change control: schema versioning, deprecation windows, and change notifications ## 3) Purpose and permitted use clause - limit use without killing value Purpose limitation is the core control for reuse. It should be specific enough to protect the data holder and trade secrets, but broad enough to avoid becoming an unfair restriction. Avoid 'catch-all' prohibitions. Describe allowed use cases and prohibited competitive behaviors explicitly. - Allowed use: named product/service purposes, analytics categories, and permitted outputs/derivatives - Prohibited use: reverse engineering, re-identification, and use outside the agreed purpose - Onward sharing: conditions for sub-processors/sub-recipients; flow-down obligations and approvals - Retention: retention periods tied to purpose + deletion obligations upon termination where applicable ## 4) Compensation clause - design a defensible pricing model (and document it) Compensation disputes are common. Even where the Data Act expects fairness and non-discrimination, you still need a practical cost model and billing mechanics. Write the clause so finance and engineers can execute: cost drivers, fee caps, reporting, and dispute handling. - Cost drivers: extraction, transformation, security controls, support, and infrastructure costs - Commercial structure: subscription, per-call, per-export, or tiered pricing; how bursts are handled - Invoice transparency: what gets itemized; how switching/termination fees are treated (avoid hidden fees) - Dispute process: escalation path, timelines, and interim payment handling ## 5) Trade secrets and confidentiality clause - 'share with safeguards' Trade secret protection is not a blanket refusal strategy. It is a safeguard strategy: classify trade secret fields and require enforceable confidentiality and security measures. Make confidentiality operational: access protocol, minimum security controls, and auditability. - Trade secret marking: define what is considered trade secret in the dataset and how it is labeled - Confidentiality: NDA or confidentiality terms, purpose limitation, and restrictions on onward sharing - Security: encryption, access control, secure storage, and incident notification obligations - Auditability: logging requirements, right to request evidence, and remediation obligations for breaches ## 6) Security and integrity clause - prevent 'data sharing' from becoming a breach Security terms are not boilerplate in Data Act data sharing. They are core compliance controls. Write security terms as verifiable requirements: authentication, authorization, monitoring, and incident response. - Access control: identity verification, role-based access, least privilege, and key management - Transport and storage: encryption in transit and at rest; integrity validation (hashes/checksums) - Abuse monitoring: rate limits, anomaly detection, and misuse response - Incident response: notification timelines, containment cooperation, and post-incident evidence ## 7) Liability and remedies clause - avoid unfair terms and keep enforceability Liability and remedies are explicitly within the Article 13 unfair-terms scope. Draft for balance and clarity. Avoid one-sided limitations that remove remedies for non-performance or that attempt to eliminate accountability for gross negligence. - Remedies: service credits, cure periods, specific performance for data delivery failures - Liability carve-outs: avoid excluding liability for intentional acts or gross negligence - IP and confidentiality breaches: clear consequences and injunctive relief where appropriate - Termination: reasonable notice and clear data return/deletion outcomes ## Evidence checklist - what to keep for disputes and enforcement Contract disputes under the Data Act become evidence disputes. Keep artifacts that show the dataset, the controls, and the fairness of the terms. This also improves procurement readiness: buyers increasingly ask for proof, not promises. - Executed contract + negotiation trail for key terms (to rebut unilateral imposition claims) - Dataset manifest: schema, formats, metadata, and change log - Security evidence: access control model, logs, encryption configuration, and incident playbooks - Compensation model: documented cost drivers, fee schedule, and billing audit trail - Trade secret register + safeguards acceptance (NDA/terms acknowledgements) *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2B Data Sharing Contract Clauses in one governed evidence system SSOT can take EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2B Data Sharing Contract Clauses from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Data Act: Fair Access to Connected Product Data and Cloud Switching can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2B Data Sharing Contract Clauses](/solutions/ssot.md): Start from EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2B Data Sharing Contract Clauses and keep documents, evidence, and control records in one governed system. - [Talk through EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/contact.md): Review your current process, evidence gaps, and next steps for EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2B Data Sharing Contract Clauses. ## Primary sources - [Regulation (EU) 2023/2854 (Data Act) - Official Journal (ELI)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Chapter III B2B sharing rules and Chapter IV unfair contractual terms in Article 13. - [European Commission draft recommendation on model contractual terms and standard contractual clauses](https://digital-strategy.ec.europa.eu/en/library/draft-recommendation-non-binding-model-contractual-terms-data-access-and-use-and-non-binding?ref=sorena.io) - Official Commission drafting aid for model contract language and cloud clauses. ## Related Topic Guides - [Access Rights and Portability | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/access-rights-and-portability.md): EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, "readily available" data. - [Applicability Test | EU Data Act: Connected Products, B2B Data Sharing, B2G Exceptional Need, Cloud Switching](/artifacts/eu/data-act/applicability-test.md): A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services). - [B2B Data Sharing Contract Template | EU Data Act: Data Access and Use Agreement (Drafting Checklist)](/artifacts/eu/data-act/b2b-data-sharing-contract-template.md): A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use. - [B2G Exceptional Need Requests | EU Data Act: Public Emergency Data Requests, Safeguards, Compensation](/artifacts/eu/data-act/b2g-exceptional-need-requests.md): EU Data Act Chapter V B2G 'exceptional need' requests made practical. - [Cloud Switching and Exit Plans | EU Data Act Chapter VI: Switch Providers, Port Data, Remove Egress Barriers](/artifacts/eu/data-act/cloud-switching-and-exit-plans.md): EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition. - [Cloud Switching Compliance Checklist | EU Data Act Chapter VI: Contracts, Exportable Data, Fees, Transparency](/artifacts/eu/data-act/cloud-switching-compliance-checklist.md): A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period). - [Compliance Program | EU Data Act Implementation Playbook: Governance, Controls, Evidence, Operating Cadence](/artifacts/eu/data-act/compliance.md): Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access. - [Deadlines and Compliance Calendar | EU Data Act](/artifacts/eu/data-act/deadlines-and-compliance-calendar.md): Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025. - [EU Data Act Checklist | Chapter II Access, B2B Sharing, Unfair Terms, B2G Requests, Cloud Switching](/artifacts/eu/data-act/checklist.md): A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access). - [EU Data Act vs GDPR | Differences, Overlap, Portability, Lawful Basis, Implementation Playbook](/artifacts/eu/data-act/data-act-vs-gdpr.md): EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights. - [FAQ | EU Data Act Explained: Key Dates, Access Rights, Trade Secrets, B2G Requests, Cloud Switching](/artifacts/eu/data-act/faq.md): EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access. - [Penalties and Fines | EU Data Act Enforcement: Member State Penalties, GDPR-Linked Fines, Risk Controls](/artifacts/eu/data-act/penalties-and-fines.md): EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider. - [Requirements | EU Data Act Obligations Explained: Chapter II Access, Chapter IV Unfair Terms, Chapter V B2G, Chapter VI Switching](/artifacts/eu/data-act/requirements.md): A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows. - [Scope, Connected Products and Data Types | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/scope-connected-products-and-data-types.md): EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data. - [Trade Secrets and Protection | EU Data Act: Confidentiality Measures, Withholding Rules, Evidence Pack](/artifacts/eu/data-act/trade-secrets-and-protection.md): EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act/b2b-data-sharing-contract-clauses --- --- title: "B2B Data Sharing Contract Template" canonical_url: "https://www.sorena.io/artifacts/eu/data-act/b2b-data-sharing-contract-template" source_url: "https://www.sorena.io/artifacts/eu/data-act/b2b-data-sharing-contract-template" author: "Sorena AI" description: "A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU Data Act contract template" - "EU Data Act B2B data sharing agreement template" - "data access and use agreement EU" - "Data Act Chapter III template" - "trade secrets NDA template data sharing" - "reasonable compensation clause template" - "Article 13 unfair terms contract template" - "EU compliance" - "data-act compliance" - "contract template" - "B2B data sharing" - "trade secrets" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # B2B Data Sharing Contract Template A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use. *Artifact Guide* *EU* ## EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2B Data Sharing Contract Template A drafting-ready structure you can tailor to APIs, portals, or data feeds. Designed to prevent scope disputes, enforce safeguards, and reduce Article 13 unfair-terms risk. Use this as a practical template outline for an EU Data Act-aligned B2B data access and use agreement. It is not a substitute for legal advice, but it is structured so that engineering, security, and finance can execute the contract: dataset definition, delivery method, permitted use, compensation, trade secret safeguards, and audit evidence all live in explicit annexes. ## 1) Parties, roles, and definitions (make the role map explicit) Start by naming the roles the Data Act cares about (e.g., data holder, data recipient) and tying them to the product/service context. Ambiguity here causes disputes later. Definitions should reference the annexes (dataset, formats, access method), not free-text descriptions. - Define: data holder, data recipient, user (if applicable), and authorized recipients/sub-processors - Define: dataset(s), export formats, metadata, delivery method (API/portal/files), and service levels - Define: trade secrets handling approach and what counts as a trade secret for the dataset ## 2) Scope of data and access method (Annex A: Dataset Manifest) Your strongest risk reducer is a versioned Dataset Manifest. Treat it as a contract-controlled API/data spec. Include the metadata necessary to interpret and use the data, not just the raw fields. - Dataset Manifest: schema, units, timestamps, identifiers, metadata, and field-level classification - Formats: structured, commonly used, machine-readable formats; versioning and deprecation policy - Access method: endpoint list, auth model, rate limits, export workflow, and availability targets ## 3) Purpose, permitted use, and restrictions (avoid 'unfair' overreach) Purpose limitation is essential, but extreme restrictions can create unfair-terms risk and business friction. Write allowed uses explicitly; write prohibited uses narrowly and defensibly. - Allowed use cases: named products/services, analytics categories, and permissible outputs - Prohibited behaviors: re-identification, reverse engineering, security bypass, misuse of credentials - Onward sharing rules: approvals, flow-down obligations, and conditions for sub-processors - Retention and deletion: retention periods tied to purpose + termination outcomes ## 4) Compensation and billing (Annex B: Cost and Fee Schedule) Compensation should be operational: define cost drivers, fee structure, invoice transparency, and dispute handling. Avoid hidden termination or switching-style fees that undermine trust and create compliance risk. - Fee model: subscription, per-call, per-export, or tiered; handling of burst use - Cost drivers: extraction, transformation, security controls, support, infrastructure - Invoice transparency: itemization requirements; audit rights for billing data - Dispute mechanism: escalation path, response times, interim payment rules ## 5) Trade secrets and confidentiality (Annex C: Confidentiality + Access Protocol) Treat trade secret protection as 'share with safeguards'. The contract should operationalize confidentiality: access protocol, minimum security controls, and auditability. Annex C is where security teams should spend their time. - Trade secret marking: dataset fields identified as trade secret and the handling rules - Confidentiality: NDA-style obligations, use limitation, onward sharing restrictions - Technical protocol: encryption, access control, logging, and incident response - Breach consequences: remediation timeline, notification, and suspension conditions ## 6) Security, integrity, and availability (Annex D: Security and SLA Controls) Security clauses need to be measurable. Write requirements as verifiable controls rather than aspirational language. Add integrity validation and abuse monitoring obligations to reduce operational and legal risk. - AuthN/AuthZ: identity verification, least privilege, key rotation, and access review cadence - Integrity: checksums/hashes for exports; reconciliation procedures; error handling - Monitoring: rate limits, anomaly detection, and misuse response - Availability targets: uptime, maintenance windows, and incident communications ## 7) Liability, remedies, and termination (Article 13 risk zone) Article 13 explicitly covers liability and remedies in the unfair-terms test. Draft for balance and enforceability. Avoid terms that remove remedies for non-performance or that attempt to eliminate accountability for gross negligence. - Remedies: cure periods, credits, and specific performance for repeated delivery failures - Liability carve-outs: avoid excluding liability for intentional acts or gross negligence - Termination: reasonable notice; clean exit with data return/deletion outcomes - Survival: confidentiality, audit rights, and dispute provisions survive termination ## 8) Audit evidence pack (Annex E: Evidence and Reporting) Bake evidence into the contract. If it's not asked for, you won't get it when you need it. Annex E should be short and concrete: what artifacts exist, who produces them, and how often. - Dataset evidence: schema versions, change log, and export samples - Security evidence: access logs, key management evidence, and incident reports - Billing evidence: invoice itemization, cost driver reporting, and sampling rights - Governance: owner list, review cadence, and escalation contacts *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2B Data Sharing Contract Template in one governed evidence system SSOT can take EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2B Data Sharing Contract Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Data Act: Fair Access to Connected Product Data and Cloud Switching can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2B Data Sharing Contract Template](/solutions/ssot.md): Start from EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2B Data Sharing Contract Template and keep documents, evidence, and control records in one governed system. - [Talk through EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/contact.md): Review your current process, evidence gaps, and next steps for EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2B Data Sharing Contract Template. ## Primary sources - [Regulation (EU) 2023/2854 (Data Act) - Official Journal (ELI)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Chapter III B2B data sharing framework and Chapter IV unfair terms rules in Article 13. - [European Commission Data Act FAQ page](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-frequently-asked-questions-about-data-act?ref=sorena.io) - Practical clarifications on roles, trade secret protection, and user access patterns that affect drafting choices. - [European Commission draft recommendation on model contractual terms and standard contractual clauses](https://digital-strategy.ec.europa.eu/en/library/draft-recommendation-non-binding-model-contractual-terms-data-access-and-use-and-non-binding?ref=sorena.io) - Official Commission drafting aid for data access and cloud switching contract language. ## Related Topic Guides - [Access Rights and Portability | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/access-rights-and-portability.md): EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, "readily available" data. - [Applicability Test | EU Data Act: Connected Products, B2B Data Sharing, B2G Exceptional Need, Cloud Switching](/artifacts/eu/data-act/applicability-test.md): A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services). - [B2B Data Sharing Contract Clauses | EU Data Act: Mandatory Sharing, Unfair Terms, Trade Secrets](/artifacts/eu/data-act/b2b-data-sharing-contract-clauses.md): EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security. - [B2G Exceptional Need Requests | EU Data Act: Public Emergency Data Requests, Safeguards, Compensation](/artifacts/eu/data-act/b2g-exceptional-need-requests.md): EU Data Act Chapter V B2G 'exceptional need' requests made practical. - [Cloud Switching and Exit Plans | EU Data Act Chapter VI: Switch Providers, Port Data, Remove Egress Barriers](/artifacts/eu/data-act/cloud-switching-and-exit-plans.md): EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition. - [Cloud Switching Compliance Checklist | EU Data Act Chapter VI: Contracts, Exportable Data, Fees, Transparency](/artifacts/eu/data-act/cloud-switching-compliance-checklist.md): A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period). - [Compliance Program | EU Data Act Implementation Playbook: Governance, Controls, Evidence, Operating Cadence](/artifacts/eu/data-act/compliance.md): Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access. - [Deadlines and Compliance Calendar | EU Data Act](/artifacts/eu/data-act/deadlines-and-compliance-calendar.md): Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025. - [EU Data Act Checklist | Chapter II Access, B2B Sharing, Unfair Terms, B2G Requests, Cloud Switching](/artifacts/eu/data-act/checklist.md): A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access). - [EU Data Act vs GDPR | Differences, Overlap, Portability, Lawful Basis, Implementation Playbook](/artifacts/eu/data-act/data-act-vs-gdpr.md): EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights. - [FAQ | EU Data Act Explained: Key Dates, Access Rights, Trade Secrets, B2G Requests, Cloud Switching](/artifacts/eu/data-act/faq.md): EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access. - [Penalties and Fines | EU Data Act Enforcement: Member State Penalties, GDPR-Linked Fines, Risk Controls](/artifacts/eu/data-act/penalties-and-fines.md): EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider. - [Requirements | EU Data Act Obligations Explained: Chapter II Access, Chapter IV Unfair Terms, Chapter V B2G, Chapter VI Switching](/artifacts/eu/data-act/requirements.md): A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows. - [Scope, Connected Products and Data Types | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/scope-connected-products-and-data-types.md): EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data. - [Trade Secrets and Protection | EU Data Act: Confidentiality Measures, Withholding Rules, Evidence Pack](/artifacts/eu/data-act/trade-secrets-and-protection.md): EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act/b2b-data-sharing-contract-template --- --- title: "B2G Exceptional Need Requests" canonical_url: "https://www.sorena.io/artifacts/eu/data-act/b2g-exceptional-need-requests" source_url: "https://www.sorena.io/artifacts/eu/data-act/b2g-exceptional-need-requests" author: "Sorena AI" description: "EU Data Act Chapter V B2G 'exceptional need' requests made practical." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU Data Act B2G exceptional need" - "EU Data Act public emergency data request" - "Article 15 exceptional need test" - "Article 17 data request requirements" - "Article 20 compensation exceptional need" - "Article 21 sharing with research organisations" - "Data Act Chapter V explained" - "B2G data sharing EU Data Act" - "EU compliance" - "data-act compliance" - "B2G Exceptional Need Requests" - "compliance timeline" - "compliance decision flow" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # B2G Exceptional Need Requests EU Data Act Chapter V B2G 'exceptional need' requests made practical. *Artifact Guide* *EU* ## EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2G Exceptional Need Requests Respond to Chapter V requests fast-without over-sharing, breaking GDPR, or leaking trade secrets. A playbook for data holders: validate the request, scope the dataset, apply safeguards, calculate compensation, and create an audit trail. EU Data Act Chapter V is a narrow, high stakes mechanism: a public sector body (and certain EU bodies) can request data from a private data holder only when an 'exceptional need' is demonstrated and the request is duly reasoned. Your goal is to comply without creating new risks: minimise the dataset, document the legal basis and purpose, apply trade secret and GDPR safeguards, and keep an evidence trail that shows proportionality and security. ## 1) The 'exceptional need' test (Article 15) - two lanes, different rules Article 15 creates two distinct lanes. Treat them differently from day one because they have different constraints and compensation expectations. A strong response starts by forcing the request into one of the lanes and documenting why. - Lane A (public emergency): data is necessary to respond to a public emergency and cannot be obtained by alternative means in time under equivalent conditions - Lane B (non-emergency statutory task): limited to non-personal data; requester must show a specific public-interest task set by law and that all other means were exhausted (including offering market rates to purchase data) - SME carve-out: Lane B does not apply to microenterprises and small enterprises ## 2) What a 'complete request' must contain (Article 17) - your acceptance checklist Article 17 is your control: it specifies what the requester must include. Use it as an intake form and do not proceed until the request is complete and proportionate. Missing request fields almost always translate into operational risk later. - Exact data + metadata requested (granularity, volume, and frequency must be proportionate) - Purpose, intended use, duration of use, and whether third parties will process the data - If personal data: which safeguards are required (e.g., pseudonymisation) and whether anonymisation can be applied by the data holder - Erasure expectations (when the data should be erased by all parties) and security measures for transfer/storage - Justification for selecting you as the data holder and identification of any planned onward sharing - Deadlines: when the data must be made available and the deadline by which you may decline or seek modification ## 3) Data holder triage workflow - a 72-hour playbook Even if the request allows more time, your internal window for safe decision-making is short. Use a standard playbook so you can respond under pressure and still be proportionate and secure. Treat the output as a case file: request versioning, decisions, approvals, dataset definition, and delivery evidence. - Validate: requester identity, legal basis, and which Article 15 lane applies (A emergency vs B non-emergency) - Minimise: define dataset, time window, and metadata strictly necessary; document exclusions and why - Safeguard: trade secret marking + confidentiality controls; GDPR safeguards; secure transfer; access restriction - Compensation: calculate costs (including anonymisation/pseudonymisation/aggregation/technical adaptation) and margin where applicable - Deliver + close: delivery receipt, integrity checksums, retrieval window, deletion milestones, and final closure memo ## 4) Trade secrets and confidentiality - 'share, but protect' Chapter V explicitly expects trade secret protection. Requests must respect the legitimate aims of the data holder and commit to safeguards, and disclosure should only occur with appropriate technical and organisational measures in place. In practice: your data package must include a confidentiality and use protocol, not just a file export. - Mark trade secret content in the dataset and metadata; document necessity and proportionality - Limit onward sharing and require equivalent safeguards for any third party receiving data - Use secure transfer + storage, strict access control, and audit logs that prove who accessed what and when ## 5) Compensation (Article 20) - when it's free and when it's paid Compensation differs by lane. For emergencies, the data necessary to respond is provided free of charge (subject to the Chapter V rules). For non-emergency statutory tasks, data holders are entitled to fair compensation that covers technical and organisational costs plus a reasonable margin. Build a repeatable cost model now (time, compute, anonymisation, engineering, security) so you can respond quickly and defend your numbers. - Emergency: data necessary to respond to a public emergency is provided free of charge; you may request public acknowledgement - Non-emergency: fair compensation covers costs (including anonymisation/pseudonymisation/aggregation/technical adaptation) and a reasonable margin; be ready to explain the calculation basis - Dispute path: requester can complain to the competent authority if it disagrees with compensation level ## 6) Sharing with researchers and statistics bodies (Article 21) - keep purpose control The requester may share Chapter V data with research organisations or statistical bodies under conditions, including purpose compatibility and restrictions designed to prevent preferential access by commercial undertakings. Operationally: require notification details and capture them in your case file. - Confirm purpose compatibility and recipient eligibility conditions - Ensure onward recipients follow the same security/confidentiality obligations as the requester - Log notifications: identity, purpose, usage period, and safeguards for each onward disclosure ## Evidence pack - what to keep for audits and disputes Because Chapter V is exceptional and sensitive, expect scrutiny. Keep a complete evidence pack: decision basis, minimisation rationale, safeguard implementation, compensation calculation, and delivery receipts. Use immutable logs and a consistent case file structure so you can answer regulator or counterparty questions quickly. - Request packet: original request + clarifications + final accepted scope and deadlines - Decision memo: exceptional need lane, proportionality, and safeguards (trade secrets + GDPR) - Dataset manifest: schema, transformations, minimisation notes, and access restrictions - Delivery receipts: transfer channel, hashes/checksums, access logs, and acknowledgements - Deletion/erasure proof: confirmations, retention exceptions, and closure memo *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2G Exceptional Need Requests as a cited research workflow Research Copilot can take EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2G Exceptional Need Requests from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU Data Act: Fair Access to Connected Product Data and Cloud Switching can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2G Exceptional Need Requests](/solutions/research-copilot.md): Start from EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2G Exceptional Need Requests and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/contact.md): Review your current process, evidence gaps, and next steps for EU Data Act: Fair Access to Connected Product Data and Cloud Switching B2G Exceptional Need Requests. ## Primary sources - [Regulation (EU) 2023/2854 (Data Act) - Official Journal (ELI)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Chapter V exceptional need rules (Articles 14-22), including request requirements (Article 17), safeguards, and compensation (Article 20). - [European Commission - Data Act FAQs (library page)](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-frequently-asked-questions-about-data-act?ref=sorena.io) - Implementation clarifications and practical framing for Data Act obligations and safeguards. ## Related Topic Guides - [Access Rights and Portability | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/access-rights-and-portability.md): EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, "readily available" data. - [Applicability Test | EU Data Act: Connected Products, B2B Data Sharing, B2G Exceptional Need, Cloud Switching](/artifacts/eu/data-act/applicability-test.md): A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services). - [B2B Data Sharing Contract Clauses | EU Data Act: Mandatory Sharing, Unfair Terms, Trade Secrets](/artifacts/eu/data-act/b2b-data-sharing-contract-clauses.md): EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security. - [B2B Data Sharing Contract Template | EU Data Act: Data Access and Use Agreement (Drafting Checklist)](/artifacts/eu/data-act/b2b-data-sharing-contract-template.md): A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use. - [Cloud Switching and Exit Plans | EU Data Act Chapter VI: Switch Providers, Port Data, Remove Egress Barriers](/artifacts/eu/data-act/cloud-switching-and-exit-plans.md): EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition. - [Cloud Switching Compliance Checklist | EU Data Act Chapter VI: Contracts, Exportable Data, Fees, Transparency](/artifacts/eu/data-act/cloud-switching-compliance-checklist.md): A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period). - [Compliance Program | EU Data Act Implementation Playbook: Governance, Controls, Evidence, Operating Cadence](/artifacts/eu/data-act/compliance.md): Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access. - [Deadlines and Compliance Calendar | EU Data Act](/artifacts/eu/data-act/deadlines-and-compliance-calendar.md): Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025. - [EU Data Act Checklist | Chapter II Access, B2B Sharing, Unfair Terms, B2G Requests, Cloud Switching](/artifacts/eu/data-act/checklist.md): A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access). - [EU Data Act vs GDPR | Differences, Overlap, Portability, Lawful Basis, Implementation Playbook](/artifacts/eu/data-act/data-act-vs-gdpr.md): EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights. - [FAQ | EU Data Act Explained: Key Dates, Access Rights, Trade Secrets, B2G Requests, Cloud Switching](/artifacts/eu/data-act/faq.md): EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access. - [Penalties and Fines | EU Data Act Enforcement: Member State Penalties, GDPR-Linked Fines, Risk Controls](/artifacts/eu/data-act/penalties-and-fines.md): EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider. - [Requirements | EU Data Act Obligations Explained: Chapter II Access, Chapter IV Unfair Terms, Chapter V B2G, Chapter VI Switching](/artifacts/eu/data-act/requirements.md): A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows. - [Scope, Connected Products and Data Types | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/scope-connected-products-and-data-types.md): EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data. - [Trade Secrets and Protection | EU Data Act: Confidentiality Measures, Withholding Rules, Evidence Pack](/artifacts/eu/data-act/trade-secrets-and-protection.md): EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act/b2g-exceptional-need-requests --- --- title: "EU Data Act Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/data-act/checklist" source_url: "https://www.sorena.io/artifacts/eu/data-act/checklist" author: "Sorena AI" description: "A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access)." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU Data Act checklist" - "EU Data Act compliance checklist" - "Data Act Chapter II checklist" - "Data Act B2B sharing checklist Chapter III" - "unfair terms checklist Article 13" - "B2G exceptional need checklist Chapter V" - "cloud switching checklist Chapter VI" - "EU Data Act evidence checklist" - "EU compliance" - "data-act compliance" - "checklist" - "IoT data access" - "cloud switching" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Data Act Checklist A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access). *Artifact Guide* *EU* ## EU Data Act: Fair Access to Connected Product Data and Cloud Switching Checklist An evidence-first implementation checklist across Chapters II-VI. Use this to drive delivery: scope decisions, contracts, access workflows, cloud switching, and B2G readiness. Use this checklist to run EU Data Act implementation like a delivery program. It's organized by chapter and by the workstream that actually owns the outcome (product/engineering/security/legal/procurement/finance). The goal is not to "be compliant in theory"-it's to ship workflows, contract terms, and evidence that stand up in disputes and audits. ## 0) Scope and ownership (do this once per product line) Start with a scope memo per product line and per contract type. If you don't define the dataset and the data holder, you will build the wrong workflow. Make ownership explicit: most failures are cross-functional gaps. - Chapter mapping: which chapters apply (II-VI) and why, per scenario - Role mapping: user, data holder, data recipient, third party; cloud provider vs customer - Dataset definition: what is 'readily available', including metadata, format, and delivery method - Ownership map: product/engineering/security/legal/procurement/finance owners per obligation ## 1) Chapter II - connected product data access and portability Chapter II is the user-facing layer: transparency before purchase and an operational access/portability workflow (direct or indirect access). Treat this as a product feature with security and audit trails. - Transparency content: what data is generated and how access works (pre-contract) - Access workflow: direct access vs indirect request portal; identity verification and SLAs - Third-party sharing: onboarding requirements and secure delivery path - GDPR coordination: personal vs non-personal filtering and lawful basis approach - Evidence: request logs, dataset manifests, delivery receipts, and security controls ## 2) Chapter III - B2B data sharing operations For B2B sharing, the contract must be executable. Scope disputes and trade secrets are the common failure points. Build repeatable packaging: dataset manifest, confidentiality protocol, and billing mechanics. - Contract annexes: dataset manifest (schema/formats/metadata), security protocol, and SLA - Compensation model: cost drivers, fee schedule, invoice transparency, dispute handling - Trade secret safeguards: classification and enforceable confidentiality measures - Security controls: access control model, monitoring, incident response - Evidence: exports samples, change logs, security evidence, and billing audit trail ## 3) Chapter IV - unfair contractual terms risk (Article 13) Article 13 can make unilaterally imposed unfair terms non binding. Treat this as a contract hygiene project, especially for click through B2B terms and platform contracts. Document negotiation for key terms to reduce "unilaterally imposed" exposure. - Audit: identify unilaterally imposed terms on data access/use and liability/remedies - Remove red flags: exclusive interpretation rights, extreme remedy limits, one-sided termination traps - Preserve balance: reasonable termination rights and access to copies of generated/provided data - Evidence: clause matrix, negotiation trail, and remediation releases ## 4) Chapter V - B2G exceptional need readiness Chapter V is rare but urgent when it happens. Build a triage workflow now: exceptional need validation, minimisation, safeguards, and compensation logic. Treat each request as a case file with immutable logs. - Intake checklist: Article 15 lane (emergency vs non-emergency), SME carve-out check, legal basis - Article 17 request completeness: data + metadata, purpose, duration, erasure, safeguards, deadlines - Safeguards: trade secret marking, GDPR controls, secure transfer, access restrictions - Compensation model (Article 20): cost calculation and margin where applicable - Evidence: request packet, decision memo, dataset manifest, delivery receipts, deletion proof ## 5) Chapter VI - cloud switching and exit readiness Chapter VI is both compliance and procurement. Providers must remove switching obstacles; customers should require proof before renewing contracts. Treat it as a controlled exit plan per service type. - Article 25 contract clauses: notice period = 30 days - Article 26 online register: exportable data schemas/formats/standards + known limitations - Article 28 disclosures: jurisdiction + measures against conflicting international access - Article 29 charges: reduced charges only until 12 Jan 2027; none from 12 Jan 2027 - Evidence: switching runbook, drill reports, register snapshots, and billing controls ## 6) The minimum evidence pack (what to keep ready for disputes and audits) EU Data Act compliance becomes an evidence problem under pressure: a dispute with a counterparty, a regulator inquiry, or a procurement request. Keep the minimum pack ready and current. - Scope memo + role mapping per product line - Dataset manifests and schema change logs - Access workflow logs and delivery receipts (direct/indirect access) - Contract clause matrices (Chapter III/IV/VI) and remediation releases - Security evidence: access controls, encryption, monitoring, incident response - Switching and B2G case file templates + completed drill artifacts *Recommended next step* *Placement: after the checklist block* ## Turn EU Data Act: Fair Access to Connected Product Data and Cloud Switching Checklist into an operational assessment Assessment Autopilot can take EU Data Act: Fair Access to Connected Product Data and Cloud Switching Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Data Act: Fair Access to Connected Product Data and Cloud Switching can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Checklist](/solutions/assessment.md): Start from EU Data Act: Fair Access to Connected Product Data and Cloud Switching Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/contact.md): Review your current process, evidence gaps, and next steps for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Checklist. ## Primary sources - [Regulation (EU) 2023/2854 (Data Act) - Official Journal (ELI)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Binding obligations across Chapters II-VI, including Article 13 unfair terms, Chapter V exceptional need, and Chapter VI cloud switching. - [European Commission - Data Act FAQs (library page)](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-frequently-asked-questions-about-data-act?ref=sorena.io) - Implementation clarifications (direct vs indirect access, portability framing, trade secrets safeguards). ## Related Topic Guides - [Access Rights and Portability | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/access-rights-and-portability.md): EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, "readily available" data. - [Applicability Test | EU Data Act: Connected Products, B2B Data Sharing, B2G Exceptional Need, Cloud Switching](/artifacts/eu/data-act/applicability-test.md): A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services). - [B2B Data Sharing Contract Clauses | EU Data Act: Mandatory Sharing, Unfair Terms, Trade Secrets](/artifacts/eu/data-act/b2b-data-sharing-contract-clauses.md): EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security. - [B2B Data Sharing Contract Template | EU Data Act: Data Access and Use Agreement (Drafting Checklist)](/artifacts/eu/data-act/b2b-data-sharing-contract-template.md): A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use. - [B2G Exceptional Need Requests | EU Data Act: Public Emergency Data Requests, Safeguards, Compensation](/artifacts/eu/data-act/b2g-exceptional-need-requests.md): EU Data Act Chapter V B2G 'exceptional need' requests made practical. - [Cloud Switching and Exit Plans | EU Data Act Chapter VI: Switch Providers, Port Data, Remove Egress Barriers](/artifacts/eu/data-act/cloud-switching-and-exit-plans.md): EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition. - [Cloud Switching Compliance Checklist | EU Data Act Chapter VI: Contracts, Exportable Data, Fees, Transparency](/artifacts/eu/data-act/cloud-switching-compliance-checklist.md): A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period). - [Compliance Program | EU Data Act Implementation Playbook: Governance, Controls, Evidence, Operating Cadence](/artifacts/eu/data-act/compliance.md): Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access. - [Deadlines and Compliance Calendar | EU Data Act](/artifacts/eu/data-act/deadlines-and-compliance-calendar.md): Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025. - [EU Data Act vs GDPR | Differences, Overlap, Portability, Lawful Basis, Implementation Playbook](/artifacts/eu/data-act/data-act-vs-gdpr.md): EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights. - [FAQ | EU Data Act Explained: Key Dates, Access Rights, Trade Secrets, B2G Requests, Cloud Switching](/artifacts/eu/data-act/faq.md): EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access. - [Penalties and Fines | EU Data Act Enforcement: Member State Penalties, GDPR-Linked Fines, Risk Controls](/artifacts/eu/data-act/penalties-and-fines.md): EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider. - [Requirements | EU Data Act Obligations Explained: Chapter II Access, Chapter IV Unfair Terms, Chapter V B2G, Chapter VI Switching](/artifacts/eu/data-act/requirements.md): A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows. - [Scope, Connected Products and Data Types | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/scope-connected-products-and-data-types.md): EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data. - [Trade Secrets and Protection | EU Data Act: Confidentiality Measures, Withholding Rules, Evidence Pack](/artifacts/eu/data-act/trade-secrets-and-protection.md): EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act/checklist --- --- title: "Cloud Switching and Exit Plans" canonical_url: "https://www.sorena.io/artifacts/eu/data-act/cloud-switching-and-exit-plans" source_url: "https://www.sorena.io/artifacts/eu/data-act/cloud-switching-and-exit-plans" author: "Sorena AI" description: "EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU Data Act cloud switching" - "EU Data Act Chapter VI" - "switch cloud provider EU Data Act" - "cloud exit plan EU Data Act" - "switching charges 12 January 2027" - "maximum notice period two months Data Act" - "30 day transitional period Data Act" - "exportable data definition Data Act" - "functional equivalence cloud switching" - "EU compliance" - "data-act compliance" - "Cloud Switching and Exit Plans" - "compliance timeline" - "compliance decision flow" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Cloud Switching and Exit Plans EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition. *Artifact Guide* *EU* ## EU Data Act: Fair Access to Connected Product Data and Cloud Switching Cloud Switching and Exit Plans Turn Chapter VI into an executable exit plan: contracts, portability, fees, and evidence. Focus: switching between providers of data processing services and moves to on-premises ICT infrastructure. EU Data Act Chapter VI is about removing switching barriers and making exit rights real. If you provide data processing services, you must remove contractual/technical/organisational obstacles and publish specific transparency information. If you buy cloud services, Chapter VI gives you a requirements checklist you can use to renegotiate exit terms and validate whether your vendor's switching process is compliant (including switching charges disappearing from 12 January 2027). ## 1) Decide your posture: provider obligations vs customer leverage Chapter VI directly binds providers of data processing services, but customers should treat it as a vendor governance instrument. Your exit plan must be service-specific: obligations differ by service type and by what is actually under the provider's control. A good exit plan starts with a service inventory and a "same service type" mapping: what you're switching from, and what you'll consider an equivalent destination. - Provider: remove switching obstacles (Article 23) and deliver contract + technical obligations (Articles 25-30) - Customer: require proof (contract clauses, switching drill results, register content) before renewal/commitments - Service inventory: classify services you buy/sell and define what "same service type" means in your architecture ## 2) Article 23 obstacle removal - what 'lock-in' looks like in real systems Article 23 requires providers to remove pre-commercial, commercial, technical, contractual and organisational obstacles that inhibit switching. Convert that into measurable requirements and testable outcomes. Think in stages: terminate, port data/assets, achieve functional equivalence, and unbundle where feasible. - Termination support: contract termination after maximum notice period and switching completion - Portability: customer can port exportable data and digital assets (including after free-tier usage) - Functional equivalence: provider must facilitate functional equivalence for the new service in a different provider environment - Unbundling: decouple switching-relevant services from unrelated bundled services where technically feasible ## 3) Article 25 contract requirements - the must-have clause list Article 25 makes switching contractual. If the contract doesn't include the required clauses, your exit plan is brittle even if the vendor claims to support exports. The operational numbers to lock down: maximum notice period = 30 days. - Switching right: switch to another provider or to on-prem; assistance + continuity + security throughout the process - Exit strategy support: provider must support the customer's exit strategy and provide relevant information - Portability scope: exhaustive list of exportable data + digital assets; exemptions for provider internal-functioning data must not impede switching - Timing: maximum notice period = 30 days - Exception handling: if 30 days is technically unfeasible, provider notifies within 14 working days and proposes alternative period <= 7 months ## 4) Article 26 transparency - procedures + the online register Article 26 requires two deliverables: clear information on switching procedures/methods/formats/limitations and a reference to an up-to-date online register with data structures/formats and relevant standards/open specs in which exportable data is available. As a customer: treat the online register as a due diligence artifact. If it's missing, you are buying lock-in. - Online register: schemas, formats, and the standards/open interoperability specs used for exportable data - Known limitations: restrictions and technical limitations disclosed up front - Evidence: register snapshots and change history; contracts pointing to the register URL ## 5) Article 28 international access transparency - jurisdiction + conflict mitigation measures Article 28 adds a procurement-relevant disclosure obligation: providers must publish which jurisdiction their service infrastructure is subject to and a general description of measures to prevent conflicting international governmental access to non-personal data held in the Union. Make this operational: a public web page, referenced in contracts, with versioned change history. - Publish per-service: jurisdiction information + measures description; keep it up to date - Reference in contracts: the web pages listed in all relevant service contracts - Evidence: internal review cadence, approvals, and change log for updates ## 6) Article 29 switching charges - bake the dates into pricing and billing Article 29 has hard commercial outcomes. Reduced switching charges are allowed only in a limited window and must be cost-based. After the phase-out date, switching charges are prohibited. Treat this as a billing + contracting project: update pricing, disclosures, and internal billing controls. - Reduced switching charges permitted 11 Jan 2024-12 Jan 2027; capped to costs directly linked to switching - No switching charges from 12 Jan 2027 - Pre-contract disclosure: standard fees, early termination penalties, and any reduced switching charges ## Exit plan template - a vendor-neutral structure you can run Your exit plan should exist even when you don't plan to switch. It reduces renewal lock-in, accelerates incident response, and creates negotiating leverage before long commitments. Maintain one exit plan per critical service and rehearse it annually. - Scope: service type, workloads, data domains, digital assets, and dependencies - Portability: exportable data manifest, formats, tooling, and time-to-export SLOs - Security: encryption, access control, integrity validation, and logging during switching - Continuity: cutover testing, rollback plan, and transitional period runbook - Commercial: fees/penalties/switching charges policy (with the 12 Jan 2027 hard stop) - Evidence: contract clause checklist, register snapshots, and switching rehearsal test reports *Recommended next step* *Placement: near the end of the main content before related guides* ## Turn EU Data Act: Fair Access to Connected Product Data and Cloud Switching Cloud Switching and Exit Plans into an operational assessment Assessment Autopilot can take EU Data Act: Fair Access to Connected Product Data and Cloud Switching Cloud Switching and Exit Plans from turning this guidance into an operational assessment workflow to a reusable workflow inside Sorena. Teams working on EU Data Act: Fair Access to Connected Product Data and Cloud Switching can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Cloud Switching and Exit Plans](/solutions/assessment.md): Start from EU Data Act: Fair Access to Connected Product Data and Cloud Switching Cloud Switching and Exit Plans and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/contact.md): Review your current process, evidence gaps, and next steps for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Cloud Switching and Exit Plans. ## Primary sources - [Regulation (EU) 2023/2854 (Data Act) - Official Journal (ELI)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Chapter VI switching obligations (Articles 23-31), including contract requirements (Article 25), online register (Article 26), jurisdiction transparency (Article 28), switching charges (Article 29), and technical aspects (Article 30). ## Related Topic Guides - [Access Rights and Portability | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/access-rights-and-portability.md): EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, "readily available" data. - [Applicability Test | EU Data Act: Connected Products, B2B Data Sharing, B2G Exceptional Need, Cloud Switching](/artifacts/eu/data-act/applicability-test.md): A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services). - [B2B Data Sharing Contract Clauses | EU Data Act: Mandatory Sharing, Unfair Terms, Trade Secrets](/artifacts/eu/data-act/b2b-data-sharing-contract-clauses.md): EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security. - [B2B Data Sharing Contract Template | EU Data Act: Data Access and Use Agreement (Drafting Checklist)](/artifacts/eu/data-act/b2b-data-sharing-contract-template.md): A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use. - [B2G Exceptional Need Requests | EU Data Act: Public Emergency Data Requests, Safeguards, Compensation](/artifacts/eu/data-act/b2g-exceptional-need-requests.md): EU Data Act Chapter V B2G 'exceptional need' requests made practical. - [Cloud Switching Compliance Checklist | EU Data Act Chapter VI: Contracts, Exportable Data, Fees, Transparency](/artifacts/eu/data-act/cloud-switching-compliance-checklist.md): A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period). - [Compliance Program | EU Data Act Implementation Playbook: Governance, Controls, Evidence, Operating Cadence](/artifacts/eu/data-act/compliance.md): Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access. - [Deadlines and Compliance Calendar | EU Data Act](/artifacts/eu/data-act/deadlines-and-compliance-calendar.md): Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025. - [EU Data Act Checklist | Chapter II Access, B2B Sharing, Unfair Terms, B2G Requests, Cloud Switching](/artifacts/eu/data-act/checklist.md): A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access). - [EU Data Act vs GDPR | Differences, Overlap, Portability, Lawful Basis, Implementation Playbook](/artifacts/eu/data-act/data-act-vs-gdpr.md): EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights. - [FAQ | EU Data Act Explained: Key Dates, Access Rights, Trade Secrets, B2G Requests, Cloud Switching](/artifacts/eu/data-act/faq.md): EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access. - [Penalties and Fines | EU Data Act Enforcement: Member State Penalties, GDPR-Linked Fines, Risk Controls](/artifacts/eu/data-act/penalties-and-fines.md): EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider. - [Requirements | EU Data Act Obligations Explained: Chapter II Access, Chapter IV Unfair Terms, Chapter V B2G, Chapter VI Switching](/artifacts/eu/data-act/requirements.md): A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows. - [Scope, Connected Products and Data Types | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/scope-connected-products-and-data-types.md): EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data. - [Trade Secrets and Protection | EU Data Act: Confidentiality Measures, Withholding Rules, Evidence Pack](/artifacts/eu/data-act/trade-secrets-and-protection.md): EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act/cloud-switching-and-exit-plans --- --- title: "Cloud Switching Compliance Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/data-act/cloud-switching-compliance-checklist" source_url: "https://www.sorena.io/artifacts/eu/data-act/cloud-switching-compliance-checklist" author: "Sorena AI" description: "A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period)." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU Data Act cloud switching checklist" - "EU Data Act Chapter VI checklist" - "Article 25 switching clauses checklist" - "exportable data online register Article 26" - "international access transparency Article 28" - "switching charges 12 January 2027 Article 29" - "open interfaces portability Article 30" - "EU compliance" - "data-act compliance" - "Cloud Switching Compliance Checklist" - "compliance timeline" - "compliance decision flow" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Cloud Switching Compliance Checklist A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period). *Artifact Guide* *EU* ## EU Data Act: Fair Access to Connected Product Data and Cloud Switching Cloud Switching Compliance Checklist A procurement- and audit ready checklist for Chapter VI switching obligations. Use it as a vendor due diligence list (customer) or an implementation checklist (provider). EU Data Act Chapter VI requires providers of data processing services to remove switching obstacles and make portability real. This checklist translates Articles 23-30 into concrete controls and evidence. If you're a customer, use it to validate vendors before renewal. If you're a provider, use it to build an audit ready switching posture and to avoid "we support exports" claims that don't survive scrutiny. ## A) Contract checklist (Article 25) - must-have clauses and numbers Start with contracts. If the contract doesn't contain the required rights and obligations, switching becomes a discretionary support request instead of a guaranteed process. Maintain a clause matrix per service type and publish a customer-facing summary aligned to the contract. - Switching right: to another provider (same service type) or to on-prem, without undue delay - Maximum notice period: <= 2 months to initiate the switching process - Transitional period: mandatory maximum of 30 calendar days (with a limited technical unfeasibility exception) - Retrieval period: minimum of 30 calendar days after termination - Assistance + continuity: reasonable assistance, continuity, and security maintained throughout switching - Exit strategy support: explicit obligation to support the customer's exit strategy with relevant information - Portability scope: exhaustive list of exportable data + digital assets (per service), including formats and tooling - Exemptions: internal-functioning data exemptions justified by trade secret risk and must not impede switching - If 30 days is technically unfeasible: provider notifies within 14 working days and proposes an alternative period <= 7 months *Recommended next step* *Placement: after the checklist block* ## Turn EU Data Act: Fair Access to Connected Product Data and Cloud Switching Cloud Switching Compliance Checklist into an operational assessment Assessment Autopilot can take EU Data Act: Fair Access to Connected Product Data and Cloud Switching Cloud Switching Compliance Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Data Act: Fair Access to Connected Product Data and Cloud Switching can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Cloud Switching Compliance Checklist](/solutions/assessment.md): Start from EU Data Act: Fair Access to Connected Product Data and Cloud Switching Cloud Switching Compliance Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/contact.md): Review your current process, evidence gaps, and next steps for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Cloud Switching Compliance Checklist. ## B) Process checklist (Articles 23 + 27) - switching workflow and cooperation A compliant switching posture requires a real workflow: owners, SLAs, and a runbook. Article 27 explicitly requires parties to cooperate in good faith to make switching effective and timely. Procurement will ask for proof. Build a switching rehearsal program and keep artifacts. - Published switching procedure: intake, verification, scoping, execution, escalation, and closure - Operational SLAs: acknowledgement, dataset export, interface availability, cutover support, and closure - Runbook: security controls, integrity validation, and rollback plan - Evidence: switching drill report per service type (date, scope, duration, issues, remediation) ## C) Article 26 online register - exportable data transparency you can't fake Article 26 requires an up-to-date online register with the data structures and formats (and relevant standards/open interoperability specifications) used for exportable data. Treat this as a customer-facing exportability specification and keep a change log. - Register content: schemas/data structures, formats, and relevant standards/open specs for exportable data - Accessibility: publicly accessible or easily accessible to customers; referenced in contracts - Limitations: restrictions and technical limitations documented and kept up to date - Evidence: snapshots and change history (versioning) ## D) Article 28 international access transparency - website disclosures Providers must publish jurisdiction information and a general description of measures designed to prevent conflicting international governmental access to or transfer of non-personal data held in the Union. Operationally: keep a dedicated web page per service and reference it in contracts. - Per-service jurisdiction disclosure for the ICT infrastructure used for data processing - Measures description (technical/organisational/contractual) published and kept up to date - Contracts list the website(s) containing Article 28 info - Evidence: review cadence, approvals, and change log ## E) Article 29 switching charges - pricing and billing controls Switching charges have a hard phase-out: from 12 January 2027, switching charges are prohibited. In the interim period, reduced charges are allowed only if they are cost-based. Implement billing controls so invoices don't accidentally reintroduce prohibited switching charges. - Reduced charges only 11 Jan 2024-12 Jan 2027; capped at costs directly linked to switching - No switching charges from 12 Jan 2027 - Pre-contract disclosure: standard fees, early termination penalties, and reduced switching charges (if any) - Evidence: price list history and invoice sampling ## F) Article 30 technical portability - open interfaces and formats Article 30 requires open interfaces (free of charge) for portability and interoperability, and compatibility with common specifications or harmonised standards once published in the central repository (with a compliance window after publication). If standards/specs aren't available yet for a service type, exportable data must still be exportable in structured, commonly used, machine-readable formats on request. - Open interfaces available to customers and destination providers free of charge (where applicable) - Documentation sufficient to develop software to communicate with the service for portability/interoperability - Compatibility plan with common specs/harmonised standards after publication in the central repository - Fallback export formats when no common specs exist (structured, commonly used, machine-readable) - Evidence: API specs, interface docs, export samples, and conformance test results ## Evidence pack - what procurement and auditors will ask for Treat Chapter VI as both compliance and sales. Most enterprise buyers will request proof: contract language, registers, drill outcomes, and public disclosures. Keep a standard evidence pack per service type and keep it current. - Article 25 clause matrix (per service) + contract excerpts - Switching runbook + drill reports per service type - Online register URL + snapshots + change log (Article 26) - Jurisdiction + measures disclosure pages + change log (Article 28) - Billing controls evidence + invoice sampling for switching charges (Article 29) ## Primary sources - [Regulation (EU) 2023/2854 (Data Act) - Official Journal (ELI)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Chapter VI switching obligations (Articles 23-31), including contract requirements (Article 25), online register (Article 26), jurisdiction transparency (Article 28), switching charges (Article 29), and technical aspects (Article 30). ## Related Topic Guides - [Access Rights and Portability | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/access-rights-and-portability.md): EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, "readily available" data. - [Applicability Test | EU Data Act: Connected Products, B2B Data Sharing, B2G Exceptional Need, Cloud Switching](/artifacts/eu/data-act/applicability-test.md): A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services). - [B2B Data Sharing Contract Clauses | EU Data Act: Mandatory Sharing, Unfair Terms, Trade Secrets](/artifacts/eu/data-act/b2b-data-sharing-contract-clauses.md): EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security. - [B2B Data Sharing Contract Template | EU Data Act: Data Access and Use Agreement (Drafting Checklist)](/artifacts/eu/data-act/b2b-data-sharing-contract-template.md): A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use. - [B2G Exceptional Need Requests | EU Data Act: Public Emergency Data Requests, Safeguards, Compensation](/artifacts/eu/data-act/b2g-exceptional-need-requests.md): EU Data Act Chapter V B2G 'exceptional need' requests made practical. - [Cloud Switching and Exit Plans | EU Data Act Chapter VI: Switch Providers, Port Data, Remove Egress Barriers](/artifacts/eu/data-act/cloud-switching-and-exit-plans.md): EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition. - [Compliance Program | EU Data Act Implementation Playbook: Governance, Controls, Evidence, Operating Cadence](/artifacts/eu/data-act/compliance.md): Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access. - [Deadlines and Compliance Calendar | EU Data Act](/artifacts/eu/data-act/deadlines-and-compliance-calendar.md): Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025. - [EU Data Act Checklist | Chapter II Access, B2B Sharing, Unfair Terms, B2G Requests, Cloud Switching](/artifacts/eu/data-act/checklist.md): A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access). - [EU Data Act vs GDPR | Differences, Overlap, Portability, Lawful Basis, Implementation Playbook](/artifacts/eu/data-act/data-act-vs-gdpr.md): EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights. - [FAQ | EU Data Act Explained: Key Dates, Access Rights, Trade Secrets, B2G Requests, Cloud Switching](/artifacts/eu/data-act/faq.md): EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access. - [Penalties and Fines | EU Data Act Enforcement: Member State Penalties, GDPR-Linked Fines, Risk Controls](/artifacts/eu/data-act/penalties-and-fines.md): EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider. - [Requirements | EU Data Act Obligations Explained: Chapter II Access, Chapter IV Unfair Terms, Chapter V B2G, Chapter VI Switching](/artifacts/eu/data-act/requirements.md): A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows. - [Scope, Connected Products and Data Types | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/scope-connected-products-and-data-types.md): EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data. - [Trade Secrets and Protection | EU Data Act: Confidentiality Measures, Withholding Rules, Evidence Pack](/artifacts/eu/data-act/trade-secrets-and-protection.md): EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act/cloud-switching-compliance-checklist --- --- title: "Compliance Program" canonical_url: "https://www.sorena.io/artifacts/eu/data-act/compliance" source_url: "https://www.sorena.io/artifacts/eu/data-act/compliance" author: "Sorena AI" description: "Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU Data Act compliance program" - "EU Data Act implementation playbook" - "Data Act compliance roadmap" - "Data Act evidence pack" - "Data Act Chapter II access workflow implementation" - "Data Act Chapter VI cloud switching compliance" - "Data Act Chapter V B2G readiness" - "EU compliance" - "data-act compliance" - "implementation playbook" - "governance" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Compliance Program Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access. *Artifact Guide* *EU* ## EU Data Act: Fair Access to Connected Product Data and Cloud Switching Compliance Program Turn Data Act obligations into shippable work with owners, controls, and evidence. This page is a program playbook: governance, milestones, and artifacts across Chapters II-VI. EU Data Act compliance succeeds when it is run as a cross-functional delivery program: product UX for access rights, engineering for export pipelines, security for safeguards, legal/procurement for contract remediation, and finance for compensation and billing controls. The most reliable approach is evidence-first: design workflows and controls that automatically produce logs and artifacts you can use in disputes, audits, and procurement. ## 1) Program setup: scope memo, owners, and risk model (week 1-2) Start with a scope memo per product line and per contract type: which chapters apply, who the roles are, and what dataset is in scope. This prevents building portals for data you don't control. Assign owners by workstream, not by chapter: product, engineering, security, legal, procurement, finance. - Scope memo: chapter mapping (II-VI), role mapping, and dataset definition (including metadata and formats) - Ownership map: named accountable owner per workstream with escalation path - Risk model: prioritize by user volume, data sensitivity, trade secret exposure, and switching/B2G likelihood ## 2) Chapter II delivery: user access and portability as a product feature (weeks 2-8) Chapter II work is user-facing: transparency before purchase, access mechanism (direct or indirect), and secure delivery. Treat this like a product launch with security gates. Build a single request pipeline that can handle mixed personal and non-personal data safely. - Direct vs indirect access decision and UX design (identity binding, abuse prevention) - Export pipeline: dataset manifest, formats, minimisation filters, and delivery receipts - Third-party sharing workflow: recipient onboarding + security requirements + logging - Evidence: request logs, dataset manifests, delivery receipts, and security control artifacts ## 3) Contracts workstream: Chapter III sharing terms + Chapter IV unfair terms (weeks 4-10) Chapter III/IV work is contract-heavy. If you don't fix contract structure and annexes, the engineering work won't be usable in disputes. Treat unfair terms as a remediation project for click through B2B terms and platform contracts. - Clause matrix: dataset scope, purpose limits, compensation, trade secrets safeguards, security, remedies - Annexes: dataset manifest, security protocol, SLA, cost/fee schedule, audit evidence annex - Unfair terms remediation: remove red flags and document negotiation for key terms ## 4) Chapter V readiness: B2G exceptional need intake and secure disclosure (weeks 6-12) Chapter V requests are exceptional but urgent. Build the intake workflow now: validate exceptional need, check request completeness, minimise and secure the dataset, and calculate compensation where applicable. Treat each request as a case file with immutable logs. - Intake checklist: Article 15 lane (emergency vs non-emergency) + SME carve-out check - Request completeness: Article 17 fields; deadlines; safeguards (pseudonymisation/anonymisation) - Disclosure pipeline: secure transfer, access restriction, trade secret marking, deletion milestones - Compensation model: cost drivers, margin rules, and dispute handling ## 5) Chapter VI posture: cloud switching and exit as procurement-grade evidence (weeks 4-12) Chapter VI is both compliance and procurement. Providers must remove switching obstacles; customers should require proof before signing long commitments. Make switching a testable capability: contracts, an online register, public disclosures, and drills. - Contract terms: notice = 30 days; security maintained during switching - Online register: schemas/formats/standards for exportable data + known limitations - International access transparency: jurisdiction + measures description published and referenced in contracts - Charges: enforce Article 29 switching charges phase-out in billing controls - Evidence: switching runbook + drill report per service type ## 6) Operating cadence: controls, metrics, and continuous evidence You'll be judged on your ability to operate the program, not just publish a policy. Build an operating cadence that produces evidence continuously. Metrics should be operational (response time, export success rate, switching drill success), not just "policy exists". - Monthly: access request metrics, exceptions, disputes, and remediation backlog - Quarterly: schema change reviews; trade secret register review; contract template updates - Annually: switching rehearsal drills per service type; B2G tabletop exercise - Evidence automation: immutable logs, standardized case files, and snapshot-able registers *Recommended next step* *Placement: after the compliance steps* ## Turn EU Data Act: Fair Access to Connected Product Data and Cloud Switching Compliance Program into an operational assessment Assessment Autopilot can take EU Data Act: Fair Access to Connected Product Data and Cloud Switching Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Data Act: Fair Access to Connected Product Data and Cloud Switching can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Compliance Program](/solutions/assessment.md): Start from EU Data Act: Fair Access to Connected Product Data and Cloud Switching Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/contact.md): Review your current process, evidence gaps, and next steps for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Compliance Program. ## Primary sources - [European Commission - Data Act policy page](https://digital-strategy.ec.europa.eu/en/policies/data-act?ref=sorena.io) - Policy context and goals for the Data Act implementation program. - [European Commission - Data Act Legal Helpdesk announcement](https://digital-strategy.ec.europa.eu/en/news/commission-launches-data-act-legal-helpdesk?ref=sorena.io) - Commission support tools for practical implementation questions (including SMEs). - [Regulation (EU) 2023/2854 (Data Act) - Official Journal (ELI)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Binding obligations and application dates used to structure the compliance program. ## Related Topic Guides - [Access Rights and Portability | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/access-rights-and-portability.md): EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, "readily available" data. - [Applicability Test | EU Data Act: Connected Products, B2B Data Sharing, B2G Exceptional Need, Cloud Switching](/artifacts/eu/data-act/applicability-test.md): A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services). - [B2B Data Sharing Contract Clauses | EU Data Act: Mandatory Sharing, Unfair Terms, Trade Secrets](/artifacts/eu/data-act/b2b-data-sharing-contract-clauses.md): EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security. - [B2B Data Sharing Contract Template | EU Data Act: Data Access and Use Agreement (Drafting Checklist)](/artifacts/eu/data-act/b2b-data-sharing-contract-template.md): A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use. - [B2G Exceptional Need Requests | EU Data Act: Public Emergency Data Requests, Safeguards, Compensation](/artifacts/eu/data-act/b2g-exceptional-need-requests.md): EU Data Act Chapter V B2G 'exceptional need' requests made practical. - [Cloud Switching and Exit Plans | EU Data Act Chapter VI: Switch Providers, Port Data, Remove Egress Barriers](/artifacts/eu/data-act/cloud-switching-and-exit-plans.md): EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition. - [Cloud Switching Compliance Checklist | EU Data Act Chapter VI: Contracts, Exportable Data, Fees, Transparency](/artifacts/eu/data-act/cloud-switching-compliance-checklist.md): A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period). - [Deadlines and Compliance Calendar | EU Data Act](/artifacts/eu/data-act/deadlines-and-compliance-calendar.md): Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025. - [EU Data Act Checklist | Chapter II Access, B2B Sharing, Unfair Terms, B2G Requests, Cloud Switching](/artifacts/eu/data-act/checklist.md): A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access). - [EU Data Act vs GDPR | Differences, Overlap, Portability, Lawful Basis, Implementation Playbook](/artifacts/eu/data-act/data-act-vs-gdpr.md): EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights. - [FAQ | EU Data Act Explained: Key Dates, Access Rights, Trade Secrets, B2G Requests, Cloud Switching](/artifacts/eu/data-act/faq.md): EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access. - [Penalties and Fines | EU Data Act Enforcement: Member State Penalties, GDPR-Linked Fines, Risk Controls](/artifacts/eu/data-act/penalties-and-fines.md): EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider. - [Requirements | EU Data Act Obligations Explained: Chapter II Access, Chapter IV Unfair Terms, Chapter V B2G, Chapter VI Switching](/artifacts/eu/data-act/requirements.md): A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows. - [Scope, Connected Products and Data Types | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/scope-connected-products-and-data-types.md): EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data. - [Trade Secrets and Protection | EU Data Act: Confidentiality Measures, Withholding Rules, Evidence Pack](/artifacts/eu/data-act/trade-secrets-and-protection.md): EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act/compliance --- --- title: "EU Data Act vs GDPR" canonical_url: "https://www.sorena.io/artifacts/eu/data-act/data-act-vs-gdpr" source_url: "https://www.sorena.io/artifacts/eu/data-act/data-act-vs-gdpr" author: "Sorena AI" description: "EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU Data Act vs GDPR" - "Data Act portability vs GDPR portability" - "connected product data access GDPR" - "Data Act Chapter II personal data" - "direct access vs indirect access Data Act" - "lawful basis sharing personal data Data Act" - "Data Act user request workflow" - "EU compliance" - "data-act compliance" - "GDPR" - "data portability" - "IoT data access" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Data Act vs GDPR EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights. *Artifact Guide* *EU* ## EU Data Act: Fair Access to Connected Product Data and Cloud Switching Data Act vs GDPR Build one access workflow that is Data Act-compliant and GDPR-safe. Focus: connected product data access and portability where datasets often contain mixed personal and non-personal data. Many EU Data Act datasets are mixed: sensor streams and device logs can contain both personal and non-personal data. The EU Data Act does not replace the GDPR. It adds specific access and portability rules for connected product and related service data, and you must implement them in a way that respects GDPR principles (lawfulness, minimisation, security, transparency). This page explains how to design a single operational workflow that satisfies both regimes without over-sharing or building duplicate processes. ## 1) What is the Data Act doing that GDPR doesn't? GDPR is a fundamental-rights regime for personal data. The EU Data Act is a market and fairness regime for access to and use of data (including non-personal data), with a specific focus on connected products, related services, and cloud switching. The key operational impact: the Data Act can require access/portability mechanisms for datasets that are not purely personal data and that have multiple actors (user, data holder, third party). - GDPR: rights and obligations tied to personal data and controller/processor roles - Data Act (Chapter II): access/portability for connected product/related service data for the user, including sharing with third parties chosen by the user - Data Act adds: direct vs indirect access design patterns and product UX obligations (transparency before purchase) ## 2) Portability: Data Act vs GDPR portability (don't conflate them) GDPR portability is a data subject right for personal data under specific conditions. Data Act portability is designed for IoT-style operational data, often near real-time, with a focus on enabling switching and innovation. Practically, teams should implement one export and sharing pipeline that can produce (a) GDPR portability packages for personal data and (b) Data Act exportable datasets for connected products. - Data Act portability: operational, often continuous or near real-time, and includes non-personal data generated by use - GDPR portability: personal-data-only conditions and format obligations; typically request/response rather than streams - Engineering implication: build a shared data export service with policy-based filtering and purpose/recipient controls *Recommended next step* *Placement: after the comparison section* ## Use EU Data Act: Fair Access to Connected Product Data and Cloud Switching Data Act vs GDPR as a cited research workflow Research Copilot can take EU Data Act: Fair Access to Connected Product Data and Cloud Switching Data Act vs GDPR from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Data Act: Fair Access to Connected Product Data and Cloud Switching can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Data Act vs GDPR](/solutions/research-copilot.md): Start from EU Data Act: Fair Access to Connected Product Data and Cloud Switching Data Act vs GDPR and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/contact.md): Review your current process, evidence gaps, and next steps for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Data Act vs GDPR. ## 3) Direct vs indirect access: privacy engineering consequences The Commission's FAQs describe direct access (self-service technical means) and indirect access (request via the data holder). Both can be compliant; they create different privacy and security risks. Direct access pushes more security responsibility into product design. Indirect access increases operational load but can simplify sensitive-data minimisation. - Direct access: strong identity binding, secure client design, rate limits, and fraud/abuse monitoring - Indirect access: request intake, identity verification, policy checks (personal vs non-personal), and auditable delivery receipts - For mixed datasets: implement field-level classification and recipient-specific filtering ## 4) Sharing to third parties: lawful basis and safeguards (when personal data is included) When the dataset includes personal data, GDPR still governs lawfulness and safeguards. The Data Act's sharing mechanisms must be implemented with GDPR principles: minimisation, purpose limitation, security, and transparency. Operationally: you need a consistent way to verify who the requester is, who the recipient is, and what data is being shared. - Define a recipient onboarding path: identity verification, security requirements, and permitted use attestations - Use a policy engine: field-level filters, redaction, aggregation, and purpose-based access decisions - Keep evidence: request logs, identity checks, dataset manifests, and delivery receipts ## 5) A combined implementation blueprint (single workflow, two legal lenses) Avoid building separate "GDPR portal" and "Data Act portal". Build a single request and delivery workflow with two decision layers: (1) Data Act chapter/role eligibility and (2) GDPR personal-data safeguards. This also improves UX: users get one consistent experience and you avoid inconsistent exports. - Step A: scope memo per product/service (what is 'readily available', who is data holder, direct vs indirect access) - Step B: data classification (personal vs non-personal) + disclosure policy and filters - Step C: secure delivery pipeline (export formats, encryption, integrity checks, logs) - Step D: evidence pack (requests, decisions, outputs, incidents, disputes) ## Primary sources - [European Commission - Data Act FAQs (library page)](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-frequently-asked-questions-about-data-act?ref=sorena.io) - Clarifications on how the Data Act complements GDPR portability and the direct vs indirect access patterns. - [Commission Communication C/2025/5026 - Guidance on vehicle data accompanying the Data Act (ELI)](https://data.europa.eu/eli/C/2025/5026/oj?ref=sorena.io) - Example of Chapter II implementation framing in a sector where datasets often mix personal and non-personal signals. - [Regulation (EU) 2023/2854 (Data Act) - Official Journal (ELI)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Binding legal text for Chapter II access and sharing and its interaction with other EU law (including GDPR references). ## Related Topic Guides - [Access Rights and Portability | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/access-rights-and-portability.md): EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, "readily available" data. - [Applicability Test | EU Data Act: Connected Products, B2B Data Sharing, B2G Exceptional Need, Cloud Switching](/artifacts/eu/data-act/applicability-test.md): A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services). - [B2B Data Sharing Contract Clauses | EU Data Act: Mandatory Sharing, Unfair Terms, Trade Secrets](/artifacts/eu/data-act/b2b-data-sharing-contract-clauses.md): EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security. - [B2B Data Sharing Contract Template | EU Data Act: Data Access and Use Agreement (Drafting Checklist)](/artifacts/eu/data-act/b2b-data-sharing-contract-template.md): A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use. - [B2G Exceptional Need Requests | EU Data Act: Public Emergency Data Requests, Safeguards, Compensation](/artifacts/eu/data-act/b2g-exceptional-need-requests.md): EU Data Act Chapter V B2G 'exceptional need' requests made practical. - [Cloud Switching and Exit Plans | EU Data Act Chapter VI: Switch Providers, Port Data, Remove Egress Barriers](/artifacts/eu/data-act/cloud-switching-and-exit-plans.md): EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition. - [Cloud Switching Compliance Checklist | EU Data Act Chapter VI: Contracts, Exportable Data, Fees, Transparency](/artifacts/eu/data-act/cloud-switching-compliance-checklist.md): A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period). - [Compliance Program | EU Data Act Implementation Playbook: Governance, Controls, Evidence, Operating Cadence](/artifacts/eu/data-act/compliance.md): Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access. - [Deadlines and Compliance Calendar | EU Data Act](/artifacts/eu/data-act/deadlines-and-compliance-calendar.md): Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025. - [EU Data Act Checklist | Chapter II Access, B2B Sharing, Unfair Terms, B2G Requests, Cloud Switching](/artifacts/eu/data-act/checklist.md): A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access). - [FAQ | EU Data Act Explained: Key Dates, Access Rights, Trade Secrets, B2G Requests, Cloud Switching](/artifacts/eu/data-act/faq.md): EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access. - [Penalties and Fines | EU Data Act Enforcement: Member State Penalties, GDPR-Linked Fines, Risk Controls](/artifacts/eu/data-act/penalties-and-fines.md): EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider. - [Requirements | EU Data Act Obligations Explained: Chapter II Access, Chapter IV Unfair Terms, Chapter V B2G, Chapter VI Switching](/artifacts/eu/data-act/requirements.md): A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows. - [Scope, Connected Products and Data Types | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/scope-connected-products-and-data-types.md): EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data. - [Trade Secrets and Protection | EU Data Act: Confidentiality Measures, Withholding Rules, Evidence Pack](/artifacts/eu/data-act/trade-secrets-and-protection.md): EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act/data-act-vs-gdpr --- --- title: "Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/data-act/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/data-act/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU Data Act deadlines" - "Regulation (EU) 2023/2854 timeline" - "Data Act applies 12 September 2025" - "Article 3(1) applies 12 September 2026" - "switching charges banned 12 January 2027" - "Data Act Chapter IV applies 12 September 2027" - "EU Data Act compliance calendar" - "EU compliance" - "data-act compliance" - "Deadlines and Compliance Calendar" - "compliance timeline" - "compliance decision flow" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Deadlines and Compliance Calendar Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025. *Artifact Guide* *EU* ## EU Data Act Deadlines and Compliance Calendar Deadline tracker and compliance calendar page for upcoming milestones and reporting dates. Use official sources to map obligations to owners, evidence, and staged deadlines. The EU Data Act is phased. Treat each legal date as a release gate: scope decisions, role mapping (user/data holder/data recipient), contract updates, API/data-access workflows, and evidence. This page turns the Data Act's application and transitional rules into a calendar you can run with owners and deliverables. ## The dates that drive your roadmap (Article 50 + cloud switching pricing) The general application date is 12 September 2025, but several obligations have their own triggers (notably the connected-product design duty and the legacy unfair-terms extension). Cloud switching pricing rules also have fixed milestones. Plan the earliest gate you cannot miss: if you provide data processing services, switching charges phase out on a hard date (12 January 2027). - 11 January 2024 - entered into force (baseline for certain transitional provisions) - 12 September 2025 - Regulation applies (most obligations become enforceable) - 12 September 2026 - Article 3(1) design duty applies for connected products/related services placed after this date - 12 September 2027 - Chapter IV legacy extension applies for certain long-running pre-2025 contracts - 12 January 2027 - switching charges banned (Article 29) ## By 12 September 2025 - core readiness (scope, roles, contracts, interfaces) By the application date, you need a defensible scope boundary and a working access workflow. Most implementation failures come from unclear definitions (product vs related service data, readily available data) and unclear role mapping (who is data holder). Treat this gate as "operational readiness": request intake, identity verification, data delivery mechanisms, trade secret safeguards, and contract templates. - Scope memo per product line: product data, related service data, readily available data, and exclusions (inferred/derived) - Role mapping: user vs data holder vs data recipient; outsource/related service provider data holder cases - User access + sharing workflow: direct access vs portal requests, authentication/authorization, audit logs - Trade secrets safeguards: confidentiality measures + escalation path ("handbrake" process) - B2B contract baseline: FRAND terms, compensation approach, liability/remedies, termination, security requirements ## By 12 September 2026 - connected-product design duty (Article 3(1)) for new products Article 3(1) has a forward-looking trigger: it applies to connected products and related services placed on the market after 12 September 2026. In practice, you need a product architecture pattern that can expose data access safely and consistently. Build a reference implementation so new product lines inherit compliant design by default. - Design patterns: data capture layer, event schema, export formats, and "readily available" extraction path - Security and privacy controls: access control, encryption, logging, and GDPR coordination for personal data - Developer experience: internal APIs/SDKs, documentation, and test harnesses for portability and sharing requests - Evidence: architecture diagrams, interface specs, and test evidence for data access workflows ## By 12 September 2027 - legacy unfair-terms exposure (Chapter IV extension) Chapter IV applies to contracts concluded after 12 September 2025. From 12 September 2027 it also applies to certain earlier contracts (indefinite duration or expiring at least 10 years from 11 January 2024). This is a commercial/legal gate: you need a contract inventory and a remediation plan for "take-it-or-leave-it" clauses covering data access and use, and related liability/remedy terms. - Contract inventory: identify data-sharing-related terms in pre-2025 B2B contracts that may fall into the extension criteria - Remediation plan: clause library, negotiation playbook, and fallbacks if a clause is voided as unfair - Governance: sales/legal enablement and a change-control process for standard terms ## Cloud switching pricing milestones (Article 29) - hard dates If you provide data processing services, Article 29 sets a clear pricing ramp-down for switching charges. Reduced switching charges are allowed only during a fixed window; from 12 January 2027, switching charges are prohibited. This is a product + finance change: pricing, billing systems, and contract templates must match the legal timeline. - 11 Jan 2024 -> 12 Jan 2027: reduced switching charges allowed (capped at directly linked costs) - From 12 Jan 2027: no switching charges - Customer disclosures: pre-contract clarity on fees, early termination penalties, and switching charges during the reduced-charge window *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU Data Act Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take EU Data Act Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Data Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Data Act Deadlines and Compliance Calendar](/solutions/assessment.md): Start from EU Data Act Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Data Act](/contact.md): Review your current process, evidence gaps, and next steps for EU Data Act Deadlines and Compliance Calendar. ## Primary sources - [Regulation (EU) 2023/2854 (Data Act) - Official Journal (ELI)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Article 50 (application + transitional rules) and Article 29 (switching charges phase-out). - [Commission Communication C/2025/5026, Guidance on vehicle data accompanying the Data Act](https://eur-lex.europa.eu/eli/C/2025/5026/oj/eng?ref=sorena.io) - Sector specific official guidance that helps explain Chapter II application in connected vehicle contexts. - [European Commission - Data Act (policy page)](https://digital-strategy.ec.europa.eu/en/policies/data-act?ref=sorena.io) - Commission overview and key rollout dates. - [European Commission - Data Act FAQs (library page)](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-frequently-asked-questions-about-data-act?ref=sorena.io) - FAQs supporting implementation (definitions and practical examples). - [European Commission - Data Act Legal Helpdesk (announcement)](https://digital-strategy.ec.europa.eu/en/news/commission-launches-data-act-legal-helpdesk?ref=sorena.io) - Commission support channel for implementation questions. ## Related Topic Guides - [Access Rights and Portability | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/access-rights-and-portability.md): EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, "readily available" data. - [Applicability Test | EU Data Act: Connected Products, B2B Data Sharing, B2G Exceptional Need, Cloud Switching](/artifacts/eu/data-act/applicability-test.md): A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services). - [B2B Data Sharing Contract Clauses | EU Data Act: Mandatory Sharing, Unfair Terms, Trade Secrets](/artifacts/eu/data-act/b2b-data-sharing-contract-clauses.md): EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security. - [B2B Data Sharing Contract Template | EU Data Act: Data Access and Use Agreement (Drafting Checklist)](/artifacts/eu/data-act/b2b-data-sharing-contract-template.md): A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use. - [B2G Exceptional Need Requests | EU Data Act: Public Emergency Data Requests, Safeguards, Compensation](/artifacts/eu/data-act/b2g-exceptional-need-requests.md): EU Data Act Chapter V B2G 'exceptional need' requests made practical. - [Cloud Switching and Exit Plans | EU Data Act Chapter VI: Switch Providers, Port Data, Remove Egress Barriers](/artifacts/eu/data-act/cloud-switching-and-exit-plans.md): EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition. - [Cloud Switching Compliance Checklist | EU Data Act Chapter VI: Contracts, Exportable Data, Fees, Transparency](/artifacts/eu/data-act/cloud-switching-compliance-checklist.md): A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period). - [Compliance Program | EU Data Act Implementation Playbook: Governance, Controls, Evidence, Operating Cadence](/artifacts/eu/data-act/compliance.md): Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access. - [EU Data Act Checklist | Chapter II Access, B2B Sharing, Unfair Terms, B2G Requests, Cloud Switching](/artifacts/eu/data-act/checklist.md): A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access). - [EU Data Act vs GDPR | Differences, Overlap, Portability, Lawful Basis, Implementation Playbook](/artifacts/eu/data-act/data-act-vs-gdpr.md): EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights. - [FAQ | EU Data Act Explained: Key Dates, Access Rights, Trade Secrets, B2G Requests, Cloud Switching](/artifacts/eu/data-act/faq.md): EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access. - [Penalties and Fines | EU Data Act Enforcement: Member State Penalties, GDPR-Linked Fines, Risk Controls](/artifacts/eu/data-act/penalties-and-fines.md): EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider. - [Requirements | EU Data Act Obligations Explained: Chapter II Access, Chapter IV Unfair Terms, Chapter V B2G, Chapter VI Switching](/artifacts/eu/data-act/requirements.md): A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows. - [Scope, Connected Products and Data Types | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/scope-connected-products-and-data-types.md): EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data. - [Trade Secrets and Protection | EU Data Act: Confidentiality Measures, Withholding Rules, Evidence Pack](/artifacts/eu/data-act/trade-secrets-and-protection.md): EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act/deadlines-and-compliance-calendar --- --- title: "FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/data-act/faq" source_url: "https://www.sorena.io/artifacts/eu/data-act/faq" author: "Sorena AI" description: "EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU Data Act FAQ" - "EU Data Act explained" - "Data Act key dates Article 50" - "direct access vs indirect access Data Act" - "readily available data definition Data Act" - "trade secrets handbrake Data Act" - "B2G exceptional need request Data Act" - "cloud switching charges 12 January 2027" - "EU compliance" - "data-act compliance" - "FAQ" - "IoT data access" - "cloud switching" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FAQ EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access. *Artifact Guide* *EU* ## EU Data Act: Fair Access to Connected Product Data and Cloud Switching FAQ Fast answers to the questions teams ask right before they ship (or get stuck). Focus: dates, access workflows, trade secrets, B2G exceptional need, and cloud switching. This FAQ focuses on implementation questions that cause real delays: what applies when, what data must be made available, how to design direct vs indirect access, how to coordinate with GDPR for mixed datasets, how trade secret safeguards work, how B2G requests are validated, and what Chapter VI cloud switching means for contracts and fees. ## When does the EU Data Act apply? The Data Act applies from 12 September 2025. Article 50 also sets specific timing gates for certain obligations (for example, a connected-product design duty tied to products placed on the market after 12 September 2026) and clarifies how some contract-related rules apply based on contract dates. - Baseline application date: 12 September 2025 (Article 50) - Cloud switching charges: no switching charges from 12 January 2027 (Article 29) - Treat dates as release gates: scope memo -> contract remediation -> workflow launch -> evidence pack ## What is the difference between direct and indirect access? The Commission's FAQs describe two patterns. Direct access means the user can access/port data via technical means without requesting the data holder each time. Indirect access means the user requests access via the data holder (e.g., a portal) and the data holder delivers the data. Both can be compliant. The choice affects security, operational cost, and how you handle sensitive fields. - Direct access: lower operational load; higher product security responsibility - Indirect access: higher operational load; can simplify sensitive data minimisation and logging - Either way: build an auditable workflow (identity, decision, delivery, logs) ## What data is 'in scope' for Chapter II access rights? Chapter II focuses on data generated by use of connected products and related services, including the metadata needed to interpret and use the data. Implementation depends on what is "readily available" for the data holder to provide. Operationally, the scoping deliverable is a dataset manifest: fields, formats, metadata, and delivery method. - Define the dataset and metadata, not just the concept of "data" - Document extraction path and latency constraints (batch exports vs near real-time) - Keep a schema change log so exports stay consistent ## How does the EU Data Act interact with GDPR? The Data Act does not replace GDPR. Many connected product datasets are mixed (personal + non-personal). When personal data is involved, GDPR principles still govern lawfulness, minimisation, transparency, and security. The safest implementation is one workflow with two decision layers: Data Act eligibility + GDPR safeguards. - Classify data at field-level: personal vs non-personal and apply filters accordingly - Design recipient onboarding: verify third parties and require security + purpose commitments - Keep evidence: request logs, decision records, and delivery receipts ## Can we refuse access because parts of the dataset are trade secrets? Trade secret protection is handled through safeguards, not blanket refusals. The Data Act expects confidentiality measures such as agreements, strict access protocols, and technical controls. Withholding/suspension is a targeted mechanism when the necessary measures cannot be agreed or are breached. - Build a trade secret register and mark fields in dataset manifests - Require enforceable confidentiality + security measures before disclosure - If safeguards fail: use targeted withholding/suspension with a documented case file ## What is a B2G 'exceptional need' request and how do we validate it? Chapter V allows certain public sector bodies (and EU bodies) to request data from private data holders only when an 'exceptional need' is demonstrated and the request is duly reasoned. Article 15 defines the exceptional need lanes. Your intake workflow should validate: lane selection, completeness (Article 17), safeguards, and deadlines. - Two lanes: public emergency vs non-emergency statutory task (non-personal data only) - SME carve-out: the non-emergency lane does not apply to micro and small enterprises - Operational output: case file with minimisation, safeguards, delivery receipts, and deletion proof ## Do we get compensated for B2G requests? Compensation depends on the lane. For public emergencies, the required data is provided free of charge. For non-emergency statutory tasks, data holders are entitled to fair compensation covering costs (including safeguards work) and a reasonable margin (Article 20). Build a repeatable cost model so you can respond quickly and defend it. - Emergency: free of charge; you may request public acknowledgement - Non-emergency: fair compensation for technical/organisational costs plus margin - Disputes: requester can complain to the competent authority if it disagrees with compensation level ## What does Chapter VI require for cloud switching and exit? Chapter VI requires providers of data processing services to remove switching obstacles and to support customer switching to another provider (same service type) or to on-prem infrastructure. Article 25 sets required contract terms and timing gates. Even if you're only a customer, Chapter VI is a procurement checklist: require proof before renewal. - Contract gates: notice period = 30 days - Transparency: online register of exportable data structures/formats and known limitations - Fees: reduced switching charges only until 12 Jan 2027; none from 12 Jan 2027 ## What evidence should we keep to avoid disputes and reduce enforcement risk? Most disputes are about what you delivered, under what authority, with what safeguards. Build an evidence pack that is generated automatically by your workflows. Evidence is also procurement fuel: buyers increasingly ask for proof of exit readiness and switching posture. - Scope memo + role mapping per product line - Dataset manifests + schema change logs - Request logs + identity verification + delivery receipts - Trade secret safeguard agreements + technical control evidence - Cloud switching: contract clause matrix + online register snapshots + drill reports *Recommended next step* *Placement: after the FAQ section* ## Use EU Data Act: Fair Access to Connected Product Data and Cloud Switching FAQ as a cited research workflow Research Copilot can take EU Data Act: Fair Access to Connected Product Data and Cloud Switching FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU Data Act: Fair Access to Connected Product Data and Cloud Switching can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Data Act: Fair Access to Connected Product Data and Cloud Switching FAQ](/solutions/research-copilot.md): Start from EU Data Act: Fair Access to Connected Product Data and Cloud Switching FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/contact.md): Review your current process, evidence gaps, and next steps for EU Data Act: Fair Access to Connected Product Data and Cloud Switching FAQ. ## Primary sources - [European Commission - Data Act FAQs (library page)](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-frequently-asked-questions-about-data-act?ref=sorena.io) - Practical clarifications used in this FAQ (direct vs indirect access, portability framing, trade secrets safeguards). - [Regulation (EU) 2023/2854 (Data Act) - Official Journal (ELI)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Binding legal text for Article 50 application dates, Chapter V exceptional need, and Chapter VI switching charges (Article 29). ## Related Topic Guides - [Access Rights and Portability | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/access-rights-and-portability.md): EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, "readily available" data. - [Applicability Test | EU Data Act: Connected Products, B2B Data Sharing, B2G Exceptional Need, Cloud Switching](/artifacts/eu/data-act/applicability-test.md): A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services). - [B2B Data Sharing Contract Clauses | EU Data Act: Mandatory Sharing, Unfair Terms, Trade Secrets](/artifacts/eu/data-act/b2b-data-sharing-contract-clauses.md): EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security. - [B2B Data Sharing Contract Template | EU Data Act: Data Access and Use Agreement (Drafting Checklist)](/artifacts/eu/data-act/b2b-data-sharing-contract-template.md): A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use. - [B2G Exceptional Need Requests | EU Data Act: Public Emergency Data Requests, Safeguards, Compensation](/artifacts/eu/data-act/b2g-exceptional-need-requests.md): EU Data Act Chapter V B2G 'exceptional need' requests made practical. - [Cloud Switching and Exit Plans | EU Data Act Chapter VI: Switch Providers, Port Data, Remove Egress Barriers](/artifacts/eu/data-act/cloud-switching-and-exit-plans.md): EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition. - [Cloud Switching Compliance Checklist | EU Data Act Chapter VI: Contracts, Exportable Data, Fees, Transparency](/artifacts/eu/data-act/cloud-switching-compliance-checklist.md): A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period). - [Compliance Program | EU Data Act Implementation Playbook: Governance, Controls, Evidence, Operating Cadence](/artifacts/eu/data-act/compliance.md): Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access. - [Deadlines and Compliance Calendar | EU Data Act](/artifacts/eu/data-act/deadlines-and-compliance-calendar.md): Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025. - [EU Data Act Checklist | Chapter II Access, B2B Sharing, Unfair Terms, B2G Requests, Cloud Switching](/artifacts/eu/data-act/checklist.md): A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access). - [EU Data Act vs GDPR | Differences, Overlap, Portability, Lawful Basis, Implementation Playbook](/artifacts/eu/data-act/data-act-vs-gdpr.md): EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights. - [Penalties and Fines | EU Data Act Enforcement: Member State Penalties, GDPR-Linked Fines, Risk Controls](/artifacts/eu/data-act/penalties-and-fines.md): EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider. - [Requirements | EU Data Act Obligations Explained: Chapter II Access, Chapter IV Unfair Terms, Chapter V B2G, Chapter VI Switching](/artifacts/eu/data-act/requirements.md): A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows. - [Scope, Connected Products and Data Types | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/scope-connected-products-and-data-types.md): EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data. - [Trade Secrets and Protection | EU Data Act: Confidentiality Measures, Withholding Rules, Evidence Pack](/artifacts/eu/data-act/trade-secrets-and-protection.md): EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act/faq --- --- title: "Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/data-act/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/data-act/penalties-and-fines" author: "Sorena AI" description: "EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU Data Act penalties" - "EU Data Act fines" - "Data Act enforcement Article 40" - "GDPR supervisory authority Data Act fines" - "Article 83(5) GDPR fines Data Act" - "Data Act Chapter II III V penalties" - "EU Data Act enforcement risk" - "EU compliance" - "data-act compliance" - "enforcement" - "penalties" - "fines" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Penalties and Fines EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider. *Artifact Guide* *EU* ## EU Data Act: Fair Access to Connected Product Data and Cloud Switching Penalties and Fines Understand the enforcement model and build evidence that reduces penalty risk. Focus: Article 40 penalties framework and the GDPR-linked administrative fines route for Chapter II/III/V infringements. EU Data Act enforcement is not a single Union fine table. Article 40 requires Member States to set penalty rules and implement them, and it lists the non exhaustive criteria authorities should consider when imposing penalties. In addition, for infringements of Chapters II, III, and V, GDPR supervisory authorities may impose administrative fines within their competence in line with GDPR Article 83 and up to the levels in GDPR Article 83(5). The practical takeaway is that enforcement risk is largely an evidence and operating model problem. ## 1) The baseline: Member States must set penalty rules (Article 40(1)-(3)) Article 40 requires Member States to lay down penalty rules for infringements and to ensure they are implemented. Penalties must be effective, proportionate, and dissuasive. Member States were required to notify the Commission of their rules by 12 September 2025, and the Commission maintains a public register of those measures. - Expect local variation: enforcement mechanisms and penalty levels are set nationally - Cross-border reality: your exposure depends on establishment and where requests/users are located - Compliance implication: keep a per-Member-State enforcement tracker for your primary markets ## 2) The criteria authorities consider (Article 40(3)) - build your evidence around them Article 40 lists non-exhaustive criteria authorities should consider when imposing penalties. Treat this as a roadmap for your evidence pack. You can't control every factor, but you can control your remediation speed, documentation quality, and operational discipline. - Nature, gravity, scale, and duration of the infringement - Mitigation/remediation actions taken to reduce harm - Previous infringements (repeat offender risk) - Financial benefits gained or losses avoided (where establishable) - Other aggravating/mitigating factors and the party's EU turnover ## 3) GDPR-linked administrative fines for Chapters II, III, and V (Article 40(4)) Article 40(4) creates a direct bridge: for infringements of obligations in Chapter II, III and V, GDPR supervisory authorities responsible for monitoring GDPR can impose administrative fines within their competence under GDPR Article 83 and up to the amount in GDPR Article 83(5). Operationally, this means personal-data-heavy Data Act failures can converge into familiar GDPR enforcement patterns when the supervisory authority is acting within its competence. - Treat mixed personal/non-personal datasets as higher enforcement risk: you must show GDPR safeguards and Data Act access compliance simultaneously - Build a combined evidence pack: request logs, identity checks, dataset manifests, filtering decisions, and security controls - Have a remediation playbook: ability to fix access workflows, contract terms, or cloud switching disclosures quickly *Recommended next step* *Placement: after the enforcement section* ## Use EU Data Act: Fair Access to Connected Product Data and Cloud Switching Penalties and Fines as a cited research workflow Research Copilot can take EU Data Act: Fair Access to Connected Product Data and Cloud Switching Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Data Act: Fair Access to Connected Product Data and Cloud Switching can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Penalties and Fines](/solutions/research-copilot.md): Start from EU Data Act: Fair Access to Connected Product Data and Cloud Switching Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/contact.md): Review your current process, evidence gaps, and next steps for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Penalties and Fines. ## 4) Risk-reduction controls (what to implement now) Penalty risk is reduced by predictable operations and strong audit trails. Most enforcement questions become: what did you do, when, under what authority, and with what safeguards? Build controls that produce evidence automatically. - Scope memo and role mapping (user/data holder/data recipient; chapter applicability per product/service) - Access workflow: direct/indirect access design, identity verification, response SLAs, and immutable logs - Trade secrets playbook: field classification, safeguard agreements, and targeted withholding/suspension case files - Cloud switching posture: contract clauses, online register, jurisdiction disclosures, and switching drill reports - B2G readiness: intake/triage workflow, minimisation protocol, and compensation model (where applicable) ## Evidence pack checklist - what you want on the table first If you're investigated, speed and clarity matter. Assemble a standard evidence pack so you can respond consistently and demonstrate good faith. Structure it around Article 40 criteria: remediation actions, duration, scale, and prevention controls. - Request logs: timestamps, identity verification, decisions, and delivery receipts - Dataset manifests: schema versions, "readily available" definition, and export formats - Security evidence: access control model, encryption, monitoring, incident reports - Contract evidence: clause matrices for Chapter IV unfair terms and Chapter VI switching - Remediation evidence: fixes shipped, customer comms, and preventive changes ## Primary sources - [Regulation (EU) 2023/2854 (Data Act) - Official Journal (ELI)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Article 40 penalties framework and the GDPR-linked administrative fines route for Chapter II/III/V infringements. ## Related Topic Guides - [Access Rights and Portability | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/access-rights-and-portability.md): EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, "readily available" data. - [Applicability Test | EU Data Act: Connected Products, B2B Data Sharing, B2G Exceptional Need, Cloud Switching](/artifacts/eu/data-act/applicability-test.md): A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services). - [B2B Data Sharing Contract Clauses | EU Data Act: Mandatory Sharing, Unfair Terms, Trade Secrets](/artifacts/eu/data-act/b2b-data-sharing-contract-clauses.md): EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security. - [B2B Data Sharing Contract Template | EU Data Act: Data Access and Use Agreement (Drafting Checklist)](/artifacts/eu/data-act/b2b-data-sharing-contract-template.md): A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use. - [B2G Exceptional Need Requests | EU Data Act: Public Emergency Data Requests, Safeguards, Compensation](/artifacts/eu/data-act/b2g-exceptional-need-requests.md): EU Data Act Chapter V B2G 'exceptional need' requests made practical. - [Cloud Switching and Exit Plans | EU Data Act Chapter VI: Switch Providers, Port Data, Remove Egress Barriers](/artifacts/eu/data-act/cloud-switching-and-exit-plans.md): EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition. - [Cloud Switching Compliance Checklist | EU Data Act Chapter VI: Contracts, Exportable Data, Fees, Transparency](/artifacts/eu/data-act/cloud-switching-compliance-checklist.md): A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period). - [Compliance Program | EU Data Act Implementation Playbook: Governance, Controls, Evidence, Operating Cadence](/artifacts/eu/data-act/compliance.md): Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access. - [Deadlines and Compliance Calendar | EU Data Act](/artifacts/eu/data-act/deadlines-and-compliance-calendar.md): Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025. - [EU Data Act Checklist | Chapter II Access, B2B Sharing, Unfair Terms, B2G Requests, Cloud Switching](/artifacts/eu/data-act/checklist.md): A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access). - [EU Data Act vs GDPR | Differences, Overlap, Portability, Lawful Basis, Implementation Playbook](/artifacts/eu/data-act/data-act-vs-gdpr.md): EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights. - [FAQ | EU Data Act Explained: Key Dates, Access Rights, Trade Secrets, B2G Requests, Cloud Switching](/artifacts/eu/data-act/faq.md): EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access. - [Requirements | EU Data Act Obligations Explained: Chapter II Access, Chapter IV Unfair Terms, Chapter V B2G, Chapter VI Switching](/artifacts/eu/data-act/requirements.md): A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows. - [Scope, Connected Products and Data Types | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/scope-connected-products-and-data-types.md): EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data. - [Trade Secrets and Protection | EU Data Act: Confidentiality Measures, Withholding Rules, Evidence Pack](/artifacts/eu/data-act/trade-secrets-and-protection.md): EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act/penalties-and-fines --- --- title: "Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/data-act/requirements" source_url: "https://www.sorena.io/artifacts/eu/data-act/requirements" author: "Sorena AI" description: "A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU Data Act requirements" - "EU Data Act obligations" - "Data Act Chapter II requirements" - "Data Act Article 13 unfair contractual terms requirements" - "Data Act Chapter V exceptional need requirements" - "Data Act Chapter VI switching requirements" - "EU Data Act requirements checklist" - "EU compliance" - "data-act compliance" - "requirements" - "IoT data access" - "cloud switching" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Requirements A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows. *Artifact Guide* *EU* ## EU Data Act: Fair Access to Connected Product Data and Cloud Switching Requirements A chapter-by-chapter obligations map with a practical evidence checklist. Use this as the backbone for your requirements doc, backlog, and audit pack. EU Data Act requirements are easiest to implement when you map them to owners and artifacts. This page breaks down obligations across the most operational chapters (II-VI), then lists the evidence artifacts you should be able to produce on demand: dataset manifests, contract clause matrices, online registers, switching drill reports, and case files for exceptional-need requests. ## Chapter II - connected products and related services: transparency + access workflows Chapter II is the user-facing access layer for connected product and related service data. The operational requirements are: (1) transparency before purchase and (2) an access and portability mechanism that works securely and predictably. Your implementation must be specific to the product: define the dataset, the delivery method, and the safeguards. - Transparency: publish what data is generated, who the data holder is, and how access works - Access workflow: direct access vs indirect request portal; identity verification and secure delivery - Third-party sharing: recipient onboarding and secure data sharing mechanisms - Evidence: dataset manifest, portal/API specs, request logs, and delivery receipts ## Chapters III-IV - B2B data sharing terms and unfair contractual terms controls In B2B relations, the Data Act's contract layer is where most compliance failures happen: unclear dataset scope, weak safeguards, and unfair terms that become non binding. Treat this as contract engineering: move critical controls into annexes that are executable by technical teams. - Dataset scope annex: schemas, formats, metadata, and change-control process - Purpose and permitted use: allowed use cases, prohibited uses, retention and deletion - Compensation: cost drivers, fee schedule, and dispute mechanics - Unfair terms risk (Article 13): avoid one-sided liability/remedies, exclusive interpretation rights, termination traps - Evidence: clause matrices, negotiation trail for key terms, and annex version history ## Chapter V - B2G 'exceptional need': validated requests, minimisation, safeguards, compensation Chapter V requires data holders (legal persons, other than public sector bodies) to make data available upon a duly reasoned request where an exceptional need exists. Exceptional need is limited in time and scope (Article 15). Implementation is an intake and disclosure workflow: validate the request, define and minimise the dataset, apply trade secret/GDPR safeguards, and calculate compensation where applicable. - Validate exceptional need lane (emergency vs non-emergency statutory task) and SME carve-outs - Require request completeness per Article 17 (data + metadata, purpose, safeguards, deadlines, sharing) - Safeguards: trade secret marking, pseudonymisation/anonymisation where needed, secure transfer and access control - Compensation: free for emergency requests; fair compensation for non-emergency lane (Article 20) - Evidence: case file with request packet, decision memo, delivery receipts, deletion proof ## Chapter VI - cloud switching and exit: contract terms, transparency, charges, technical portability Chapter VI removes obstacles to switching between providers of data processing services and to on-prem infrastructure. It is contract-heavy (Article 25) and evidence-heavy (Article 26 register, Article 28 disclosures, Article 29 charges, Article 30 interfaces). Treat this as procurement-grade exit readiness with regular drills. - Contract terms: notice = 30 days; maintain security throughout switching - Article 26 online register: data structures/formats/standards for exportable data and known limitations - Article 28 disclosures: jurisdiction + measures to prevent conflicting international access - Article 29 switching charges: reduced charges only 11 Jan 2024-12 Jan 2027; none from 12 Jan 2027 - Article 30: open interfaces and portability formats; compatibility with common specs/standards after publication ## Evidence mapping - requirement -> artifact (the 'audit pack' backbone) Use this as a minimal evidence map. If you can produce these artifacts quickly, you can usually resolve disputes without re-building history. Automate evidence generation where possible (logs, snapshots, drill reports). - Scope decisions -> scope memo + role map + dataset inventory - Access rights (Chapter II) -> portal/API specs + request logs + delivery receipts - B2B sharing (Chapters III-IV) -> contract clause matrix + annexes + negotiation trail - Trade secrets -> trade secret register + safeguard agreements + technical control evidence - B2G (Chapter V) -> case file template + minimisation rationale + compensation calculation - Cloud switching (Chapter VI) -> contract checklist + online register snapshots + jurisdiction page + drill reports *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU Data Act: Fair Access to Connected Product Data and Cloud Switching Requirements into an operational assessment Assessment Autopilot can take EU Data Act: Fair Access to Connected Product Data and Cloud Switching Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Data Act: Fair Access to Connected Product Data and Cloud Switching can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Requirements](/solutions/assessment.md): Start from EU Data Act: Fair Access to Connected Product Data and Cloud Switching Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/contact.md): Review your current process, evidence gaps, and next steps for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Requirements. ## Primary sources - [Regulation (EU) 2023/2854 (Data Act) - Official Journal (ELI)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Binding chapter requirements used in this breakdown, including Article 13 unfair terms, Chapter V exceptional need, and Chapter VI switching obligations and charges. - [European Commission - Data Act FAQs (library page)](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-frequently-asked-questions-about-data-act?ref=sorena.io) - Implementation framing for access patterns, trade secret safeguards, and portability concepts. ## Related Topic Guides - [Access Rights and Portability | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/access-rights-and-portability.md): EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, "readily available" data. - [Applicability Test | EU Data Act: Connected Products, B2B Data Sharing, B2G Exceptional Need, Cloud Switching](/artifacts/eu/data-act/applicability-test.md): A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services). - [B2B Data Sharing Contract Clauses | EU Data Act: Mandatory Sharing, Unfair Terms, Trade Secrets](/artifacts/eu/data-act/b2b-data-sharing-contract-clauses.md): EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security. - [B2B Data Sharing Contract Template | EU Data Act: Data Access and Use Agreement (Drafting Checklist)](/artifacts/eu/data-act/b2b-data-sharing-contract-template.md): A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use. - [B2G Exceptional Need Requests | EU Data Act: Public Emergency Data Requests, Safeguards, Compensation](/artifacts/eu/data-act/b2g-exceptional-need-requests.md): EU Data Act Chapter V B2G 'exceptional need' requests made practical. - [Cloud Switching and Exit Plans | EU Data Act Chapter VI: Switch Providers, Port Data, Remove Egress Barriers](/artifacts/eu/data-act/cloud-switching-and-exit-plans.md): EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition. - [Cloud Switching Compliance Checklist | EU Data Act Chapter VI: Contracts, Exportable Data, Fees, Transparency](/artifacts/eu/data-act/cloud-switching-compliance-checklist.md): A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period). - [Compliance Program | EU Data Act Implementation Playbook: Governance, Controls, Evidence, Operating Cadence](/artifacts/eu/data-act/compliance.md): Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access. - [Deadlines and Compliance Calendar | EU Data Act](/artifacts/eu/data-act/deadlines-and-compliance-calendar.md): Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025. - [EU Data Act Checklist | Chapter II Access, B2B Sharing, Unfair Terms, B2G Requests, Cloud Switching](/artifacts/eu/data-act/checklist.md): A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access). - [EU Data Act vs GDPR | Differences, Overlap, Portability, Lawful Basis, Implementation Playbook](/artifacts/eu/data-act/data-act-vs-gdpr.md): EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights. - [FAQ | EU Data Act Explained: Key Dates, Access Rights, Trade Secrets, B2G Requests, Cloud Switching](/artifacts/eu/data-act/faq.md): EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access. - [Penalties and Fines | EU Data Act Enforcement: Member State Penalties, GDPR-Linked Fines, Risk Controls](/artifacts/eu/data-act/penalties-and-fines.md): EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider. - [Scope, Connected Products and Data Types | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/scope-connected-products-and-data-types.md): EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data. - [Trade Secrets and Protection | EU Data Act: Confidentiality Measures, Withholding Rules, Evidence Pack](/artifacts/eu/data-act/trade-secrets-and-protection.md): EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act/requirements --- --- title: "Scope, Connected Products and Data Types" canonical_url: "https://www.sorena.io/artifacts/eu/data-act/scope-connected-products-and-data-types" source_url: "https://www.sorena.io/artifacts/eu/data-act/scope-connected-products-and-data-types" author: "Sorena AI" description: "EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU Data Act scope connected products" - "product data vs related service data" - "readily available data definition" - "inferred derived data excluded Data Act" - "Data Act Chapter II scope" - "Data Act data holder definition" - "Data Act user rights IoT data" - "EU compliance" - "data-act compliance" - "Scope Connected Products and DATA Types" - "compliance timeline" - "compliance decision flow" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Scope, Connected Products and Data Types EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data. *Artifact Guide* *EU* ## EU Data Act: Fair Access to Connected Product Data and Cloud Switching Scope, Connected Products and Data Types Clarify what is in scope and how to decide quickly. This guide supports implementation for EU Data Act: Fair Access to Connected Product Data and Cloud Switching using source grounded analysis and execution oriented recommendations. Scope is the hardest part of the EU Data Act. Your obligations depend on whether you have a connected product or a related service, and whether the data is product data/related service data that is "readily available" to the data holder. This page gives you a practical classification method, with examples and a scope memo template you can reuse per product line. ## The four scope terms you must get right (Chapter II) Chapter II access rights apply to specific kinds of data generated by the use of connected products and related services. The Data Act FAQs summarize the core terms and how they fit together. Write these definitions into your internal scope memo and tie them to your architecture. - Connected product: generates data from use (IoT-style devices and systems) - Related service: a digital service linked to a connected product whose behaviour is influenced by data from that product - Product data and related service data: data relating to performance/use/environment, and data representing user actions/events during service provision - Readily available data: data a data holder can obtain without disproportionate effort going beyond a simple operation *Recommended next step* *Placement: after the scope or definition section* ## Use EU Data Act: Fair Access to Connected Product Data and Cloud Switching Scope, Connected Products and Data Types as a cited research workflow Research Copilot can take EU Data Act: Fair Access to Connected Product Data and Cloud Switching Scope, Connected Products and Data Types from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Data Act: Fair Access to Connected Product Data and Cloud Switching can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Scope, Connected Products and Data Types](/solutions/research-copilot.md): Start from EU Data Act: Fair Access to Connected Product Data and Cloud Switching Scope, Connected Products and Data Types and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/contact.md): Review your current process, evidence gaps, and next steps for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Scope, Connected Products and Data Types. ## What is typically in scope (raw and pre-processed data) vs out of scope (inferred/derived) In practice, Chapter II is about raw and pre-processed data that exists because of the product's technical design and that the data holder can access without disproportionate effort. A frequent mistake is treating analytics outputs and business intelligence as mandatory shareable data. The Act and FAQs draw a boundary: inferred/derived data is generally treated differently than raw and pre-processed data. - In scope: sensor readings, logs/events, operational metrics, device state, usage events (when readily available) - Often out of scope: inferred/derived insights created through complex analysis or enrichment (document your rationale) - Pre-contract transparency (Article 3): descriptive information "about" the product can still matter even if it is not product data ## Personal vs non-personal data (and why GDPR still governs processing) Users may be entitled to access data whether it is personal or non-personal. But personal data processing remains governed by GDPR rules, including legal basis and data subject rights. Operationally: build one access pipeline, then apply GDPR checks when personal data is involved (identity, legal basis, redaction where necessary). - Design your export so personal and non-personal fields can be handled separately where needed - Keep an audit log of access and sharing requests, approvals, and data delivered - Document "who is the data subject" vs "who is the user" in B2B scenarios (e.g., fleet/rental) ## Role mapping: user vs data holder vs data recipient Scope decisions and obligations depend on roles. A manufacturer is often the data holder, but not always: the Data Act allows the data holder role to be outsourced, and a related service provider can also be the data holder. Your scope memo should name the data holder(s) and explain how control over readily available data is exercised. - User: person/entity using/owning/renting/benefiting from the connected product or related service - Data holder: entity that controls access to the readily available data - Data recipient/third party: entity receiving data at the user's request (e.g., repair, analytics, maintenance providers) ## Scope memo template (audit ready output) Create one scope memo per product line. Keep it short, and link to evidence (architecture diagrams, interface specs, data schemas). This memo becomes your foundation for contract work, API implementation, and dispute handling. - Inventory: connected products + related services in scope; versions; EU market placement model - Data classification: product data vs related service data; readily available extraction path; exclusions (inferred/derived) - Role mapping: user/data holder/data recipient; outsourced data holder logic if applicable - Delivery design: direct access vs portal requests; export formats; security and privacy controls - Evidence links: schema registry, API docs, access logs, and test results for exports ## Primary sources - [Regulation (EU) 2023/2854 (Data Act) - Official Journal (ELI)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Legal definitions and Chapter II scope and access rights. - [European Commission - Data Act FAQs (library page)](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-frequently-asked-questions-about-data-act?ref=sorena.io) - Practical definitions: product data, related service data, readily available data, and examples of Chapter II in practice. - [European Commission - Data Act (policy page)](https://digital-strategy.ec.europa.eu/en/policies/data-act?ref=sorena.io) - Commission overview and implementation context. ## Related Topic Guides - [Access Rights and Portability | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/access-rights-and-portability.md): EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, "readily available" data. - [Applicability Test | EU Data Act: Connected Products, B2B Data Sharing, B2G Exceptional Need, Cloud Switching](/artifacts/eu/data-act/applicability-test.md): A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services). - [B2B Data Sharing Contract Clauses | EU Data Act: Mandatory Sharing, Unfair Terms, Trade Secrets](/artifacts/eu/data-act/b2b-data-sharing-contract-clauses.md): EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security. - [B2B Data Sharing Contract Template | EU Data Act: Data Access and Use Agreement (Drafting Checklist)](/artifacts/eu/data-act/b2b-data-sharing-contract-template.md): A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use. - [B2G Exceptional Need Requests | EU Data Act: Public Emergency Data Requests, Safeguards, Compensation](/artifacts/eu/data-act/b2g-exceptional-need-requests.md): EU Data Act Chapter V B2G 'exceptional need' requests made practical. - [Cloud Switching and Exit Plans | EU Data Act Chapter VI: Switch Providers, Port Data, Remove Egress Barriers](/artifacts/eu/data-act/cloud-switching-and-exit-plans.md): EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition. - [Cloud Switching Compliance Checklist | EU Data Act Chapter VI: Contracts, Exportable Data, Fees, Transparency](/artifacts/eu/data-act/cloud-switching-compliance-checklist.md): A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period). - [Compliance Program | EU Data Act Implementation Playbook: Governance, Controls, Evidence, Operating Cadence](/artifacts/eu/data-act/compliance.md): Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access. - [Deadlines and Compliance Calendar | EU Data Act](/artifacts/eu/data-act/deadlines-and-compliance-calendar.md): Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025. - [EU Data Act Checklist | Chapter II Access, B2B Sharing, Unfair Terms, B2G Requests, Cloud Switching](/artifacts/eu/data-act/checklist.md): A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access). - [EU Data Act vs GDPR | Differences, Overlap, Portability, Lawful Basis, Implementation Playbook](/artifacts/eu/data-act/data-act-vs-gdpr.md): EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights. - [FAQ | EU Data Act Explained: Key Dates, Access Rights, Trade Secrets, B2G Requests, Cloud Switching](/artifacts/eu/data-act/faq.md): EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access. - [Penalties and Fines | EU Data Act Enforcement: Member State Penalties, GDPR-Linked Fines, Risk Controls](/artifacts/eu/data-act/penalties-and-fines.md): EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider. - [Requirements | EU Data Act Obligations Explained: Chapter II Access, Chapter IV Unfair Terms, Chapter V B2G, Chapter VI Switching](/artifacts/eu/data-act/requirements.md): A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows. - [Trade Secrets and Protection | EU Data Act: Confidentiality Measures, Withholding Rules, Evidence Pack](/artifacts/eu/data-act/trade-secrets-and-protection.md): EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act/scope-connected-products-and-data-types --- --- title: "Trade Secrets and Protection" canonical_url: "https://www.sorena.io/artifacts/eu/data-act/trade-secrets-and-protection" source_url: "https://www.sorena.io/artifacts/eu/data-act/trade-secrets-and-protection" author: "Sorena AI" description: "EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU Data Act trade secrets" - "trade secrets confidentiality EU Data Act" - "trade secrets handbrake EU Data Act" - "withhold or suspend sharing trade secrets Data Act" - "confidentiality measures Data Act" - "Directive (EU) 2016/943 trade secrets" - "Chapter II access trade secrets" - "Chapter V B2G trade secrets safeguards" - "EU compliance" - "data-act compliance" - "Trade Secrets and Protection" - "compliance timeline" - "compliance decision flow" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Trade Secrets and Protection EU Data Act trade secrets protection made practical: how to identify trade secret fields before disclosure, how to agree confidentiality measures (NDAs. *Artifact Guide* *EU* ## EU Data Act: Fair Access to Connected Product Data and Cloud Switching Trade Secrets and Protection Share the data you must share-without giving away your trade secrets. A practical playbook: identify trade secret fields, agree safeguards, implement technical controls, and keep a defensible audit trail. The EU Data Act expects data holders to make certain data available even when parts of the dataset qualify as trade secrets. The compliance strategy is not "refuse to share"-it's "share with safeguards". That means: identify trade secret fields up front, agree the necessary confidentiality measures with the recipient, apply technical controls, and keep evidence. If the parties cannot agree the necessary measures, or if the recipient undermines confidentiality, the Data Act's trade secret mechanism allows withholding or suspension for the trade secret parts under specific conditions. ## 1) The core principle: 'share, but preserve trade secret protection' Trade secret protection still matters. The practical expectation is that data holders can require users and third parties to preserve confidentiality and can require measures that make that requirement enforceable. The implementation mistake is binary thinking (share everything vs refuse). The correct implementation is controlled disclosure with enforceable safeguards. - Identify trade secret fields/derivations before disclosure - Agree minimum necessary measures to preserve confidentiality (contractual + technical) - Disclose only what is necessary for the request purpose, with safeguards and audit logs ## 2) Build a trade secret classification workflow (so engineers can execute) Trade secret protection fails when it's ad hoc. Build a repeatable classification workflow that engineers can run, with business owner accountability and legal review triggers. Treat trade secret marking like data classification: predictable labels, consistent enforcement, and versioned decisions. - Field-level classification in the exportable dataset (trade secret / confidential / public) - Justification per trade secret field: why it qualifies and what harm disclosure would cause - Release rules: which fields are shareable by default vs requiring elevated approvals ## 3) Safeguards menu: contractual measures that actually work Your goal is enforceability: the recipient must be bound to confidentiality, and you must be able to prove what you required and what they accepted. Avoid vague clauses. Tie safeguards to concrete controls and evidence. - Confidentiality + use limitation: purpose restriction aligned to the request - Onward sharing controls: flow-down obligations and prohibited onward disclosure without approval - Security baseline: encryption, access control, secure storage, incident notification - Auditability: logging obligations and audit rights for suspected misuse ## 4) Safeguards menu: technical controls for controlled disclosure Technical controls are your strongest evidence. They make confidentiality measurable and reduce the blast radius of a mistake. Prefer least-privilege and data minimisation controls that can be proven with logs and configurations. - Minimisation: smallest dataset/time window that satisfies the request - Redaction/aggregation where compatible with the purpose - Secure delivery: encrypted export, short-lived links, per-request tokens, and rate limiting - Controlled environments for sensitive analytics (segmented storage and compute) - Traceability: checksums + immutable access logs (who accessed what, when, and why) ## 5) Withholding or suspension conditions - the 'handbrake' with an audit trail The trade secret mechanism is not a blanket refusal. It is a targeted control for trade secret parts of the dataset where safeguards are missing or breached. If you use it, you need a case file: what was requested, what measures were proposed, what failed, and what was withheld/suspended. - Trigger A: no agreement on necessary confidentiality measures - Trigger B: recipient fails to implement agreed measures or undermines confidentiality - Documentation: decision in writing without undue delay; keep a record suitable for regulator review - Scope control: withhold/suspend only the trade secret-identified parts, not unrelated data ## 6) Apply the same playbook to Chapter V (B2G) requests Chapter V requests explicitly expect trade secret protection and proportionate safeguards. Build trade secret marking and confidentiality controls into your B2G disclosure pipeline the same way you do for Chapter II/III disclosures. Public-sector disclosure still needs: minimisation, secure transfer, strict access, and logs. - Mark trade secret fields in the dataset manifest and metadata - Require confirmation of safeguards before disclosure - Log disclosure, access, onward sharing, and deletion/erasure outcomes ## Evidence pack - what to keep (and why it wins disputes) Trade secret disputes are evidence disputes. Keep artifacts that show you identified trade secrets, proposed measures, and shared responsibly. If you withheld or suspended sharing, keep the full case file and decision rationale. - Trade secret register: fields, rationale, owners, and review dates - Recipient safeguards: executed NDAs/terms, security attestations, and access protocol acknowledgements - Technical evidence: logs, access control configs, encryption settings, export manifests and checksums - Withholding/suspension case file: communications and decision memo *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU Data Act: Fair Access to Connected Product Data and Cloud Switching Trade Secrets and Protection as a cited research workflow Research Copilot can take EU Data Act: Fair Access to Connected Product Data and Cloud Switching Trade Secrets and Protection from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU Data Act: Fair Access to Connected Product Data and Cloud Switching can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Trade Secrets and Protection](/solutions/research-copilot.md): Start from EU Data Act: Fair Access to Connected Product Data and Cloud Switching Trade Secrets and Protection and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/contact.md): Review your current process, evidence gaps, and next steps for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Trade Secrets and Protection. ## Primary sources - [Regulation (EU) 2023/2854 (Data Act) - Official Journal (ELI)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng?ref=sorena.io) - Trade secret preservation approach and mechanisms referenced in the Regulation and recitals, plus Chapter V safeguards expectations for B2G access. - [European Commission - Data Act FAQs (library page)](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-frequently-asked-questions-about-data-act?ref=sorena.io) - Practical clarification often summarised as the 'trade secrets handbrake': share with safeguards, and use withholding/suspension only when safeguards aren't agreed or are breached. ## Related Topic Guides - [Access Rights and Portability | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/access-rights-and-portability.md): EU Data Act access rights and portability (Chapter II) made practical: direct vs indirect access, "readily available" data. - [Applicability Test | EU Data Act: Connected Products, B2B Data Sharing, B2G Exceptional Need, Cloud Switching](/artifacts/eu/data-act/applicability-test.md): A practical EU Data Act applicability test you can run in 15 minutes: determine if Chapter II IoT access rights apply (connected products + related services). - [B2B Data Sharing Contract Clauses | EU Data Act: Mandatory Sharing, Unfair Terms, Trade Secrets](/artifacts/eu/data-act/b2b-data-sharing-contract-clauses.md): EU Data Act contract clauses for B2B data sharing made practical: clause library for Chapter III access/use (purpose limits, compensation, security. - [B2B Data Sharing Contract Template | EU Data Act: Data Access and Use Agreement (Drafting Checklist)](/artifacts/eu/data-act/b2b-data-sharing-contract-template.md): A practical EU Data Act-aligned B2B data sharing contract template: sections, annexes, and drafting checklist for dataset definition, permitted use. - [B2G Exceptional Need Requests | EU Data Act: Public Emergency Data Requests, Safeguards, Compensation](/artifacts/eu/data-act/b2g-exceptional-need-requests.md): EU Data Act Chapter V B2G 'exceptional need' requests made practical. - [Cloud Switching and Exit Plans | EU Data Act Chapter VI: Switch Providers, Port Data, Remove Egress Barriers](/artifacts/eu/data-act/cloud-switching-and-exit-plans.md): EU Data Act Chapter VI cloud switching made practical: Article 23 obstacle removal, Article 25 required contract terms (max 2-month notice, 30-day transition. - [Cloud Switching Compliance Checklist | EU Data Act Chapter VI: Contracts, Exportable Data, Fees, Transparency](/artifacts/eu/data-act/cloud-switching-compliance-checklist.md): A detailed EU Data Act Chapter VI cloud switching compliance checklist: Article 25 contract terms (max notice period, 30-day transition, retrieval period). - [Compliance Program | EU Data Act Implementation Playbook: Governance, Controls, Evidence, Operating Cadence](/artifacts/eu/data-act/compliance.md): Turn the EU Data Act into an implementation program: chapter scoping, roles and ownership, product workflows for Chapter II access. - [Deadlines and Compliance Calendar | EU Data Act](/artifacts/eu/data-act/deadlines-and-compliance-calendar.md): Plan EU Data Act delivery with real dates: Regulation applies from 12 Sep 2025. - [EU Data Act Checklist | Chapter II Access, B2B Sharing, Unfair Terms, B2G Requests, Cloud Switching](/artifacts/eu/data-act/checklist.md): A comprehensive EU Data Act checklist organized by roles and chapters: Chapter II connected product data access (direct vs indirect access). - [EU Data Act vs GDPR | Differences, Overlap, Portability, Lawful Basis, Implementation Playbook](/artifacts/eu/data-act/data-act-vs-gdpr.md): EU Data Act vs GDPR made practical: how Chapter II access/portability for connected product data differs from GDPR data subject rights. - [FAQ | EU Data Act Explained: Key Dates, Access Rights, Trade Secrets, B2G Requests, Cloud Switching](/artifacts/eu/data-act/faq.md): EU Data Act FAQ with practical answers grounded in official sources: when the Data Act applies (Article 50), direct vs indirect access. - [Penalties and Fines | EU Data Act Enforcement: Member State Penalties, GDPR-Linked Fines, Risk Controls](/artifacts/eu/data-act/penalties-and-fines.md): EU Data Act penalties and fines made practical: how Member States set penalties (Article 40), the criteria authorities must consider. - [Requirements | EU Data Act Obligations Explained: Chapter II Access, Chapter IV Unfair Terms, Chapter V B2G, Chapter VI Switching](/artifacts/eu/data-act/requirements.md): A structured EU Data Act requirements breakdown across Chapters II-VI: connected product data transparency and access workflows. - [Scope, Connected Products and Data Types | EU Data Act: Fair Access to Connected Product Data and Cloud Switching](/artifacts/eu/data-act/scope-connected-products-and-data-types.md): EU Data Act scope explained: connected products vs related services, product data vs related service data, readily available data. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/data-act/trade-secrets-and-protection --- --- title: "Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/applicability-test" author: "Sorena AI" description: "A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator." published_at: "2026-02-22" updated_at: "2026-02-23" keywords: - "EUDR applicability test" - "EU Deforestation Regulation scope test" - "is my product in scope EUDR" - "Annex I relevant commodities and products" - "operator downstream operator trader EUDR" - "due diligence statement EUDR" - "geolocation requirements EUDR" - "EUDR applies 30 December 2026" - "EU compliance" - "EUDR compliance" - "Applicability Test" - "due diligence statement" - "geolocation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Applicability Test A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator. *Artifact Guide* *EU* ## EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Applicability Test Decide what applies (and what doesn't) per SKU and per supply chain path. Outputs: role mapping (operator/downstream operator/trader), date gates, and your evidence requirements. EUDR scoping is not a one-time yes/no decision. It is SKU- and supply-chain-specific: which Annex I commodity/product you sell, where it is produced, who places it on the market or exports it, and what evidence you can collect. Use this test to produce a scope memo that product, sourcing, legal, and operations can all execute. ## Step 0 - inventory the minimum inputs before you decide scope Most EUDR applicability failures come from missing data: teams don't know which SKUs map to Annex I, which supplier is the country of production, or who is the operator vs trader. Gather minimum facts before you decide scope. - SKU list + bill of materials: which commodities/products are relevant and which are derived products - Country of production and origin per batch/lot (not just supplier headquarters) - Supply chain role per transaction: who places on the market, who exports, who is downstream - Evidence availability: geolocation data, legality documents, and traceability identifiers ## Step 1 - is the product in Annex I (relevant commodities and derived products)? EUDR scope is anchored in Annex I: relevant commodities and the derived products listed in the Annex. Start here and document your mapping logic so it's repeatable. If you sell composite or multi-ingredient products, decide whether any relevant commodity triggers scope and whether derived products are explicitly listed. - Confirm whether your product is one of the Annex I commodities (e.g., cattle, cocoa, coffee, oil palm, rubber, soya, wood) or a derived product listed in Annex I - Create a SKU -> Annex I mapping table with owner, data source, and review cadence - Flag mixing/circumvention risks (multi-origin blends, bulk storage, repacking) for later risk assessment ## Step 2 - identify your role: operator, downstream operator, trader (Article 2 definitions) Your obligations depend heavily on your role. EUDR distinguishes between operators, downstream operators, and traders, and it also defines a micro/small primary operator concept with a simplified regime under specific conditions. Document role per product flow, not per legal entity. - Operator: places relevant products on the market or exports them (excluding downstream operators) - Downstream operator: places on the market or exports products made using relevant products already covered by a due diligence statement or simplified declaration - Trader: makes relevant products available on the market and is not an operator or downstream operator - Micro/small primary operator: special definition tied to low-risk classification and self-grown/harvested/raised products ## Step 3 - does the compliance test apply to your product flow (Article 3 trigger)? The Article 3 trigger is operational: relevant products must not be placed/made available on the market or exported unless they meet the core conditions and are covered by a due diligence statement (or simplified declaration where applicable). Translate this into a gate in your release/ship process: no reference number -> no ship. - Condition 1: deforestation-free (operational definition + evidence plan) - Condition 2: produced in accordance with relevant legislation of the country of production (legality evidence plan) - Condition 3: covered by a due diligence statement or simplified declaration via the information system ## Step 4 - can you use simplified due diligence (low-risk production) or a simplified regime? EUDR includes simplified pathways in specific situations, such as low-risk production under the benchmarking system (and special handling for micro/small primary operators). Even when simplified, you still need to control complexity and risks of circumvention or mixing. - Benchmarking: confirm whether the country/region is classified as low risk (and monitor updates) - If using simplified due diligence: document why circumvention/mixing risk remains negligible and keep evidence - If micro/small primary operator: confirm eligibility conditions and what data can be simplified (e.g., geolocation replacement rules) ## Step 5 - date gates: when do obligations start for your flow? EUDR has a main application date and a later application date for certain natural persons and micro or small undertakings established by 31 December 2024, subject to the conditions in the Regulation. Treat these dates as delivery deadlines for your data and due diligence workflows. - Main obligations apply from 30 December 2026 for large and medium operators and traders - Later application date is 30 June 2027 for certain natural persons and micro or small undertakings established by 31 December 2024 - If timber products were already in scope under the EU Timber Regulation, check the Article 38 exception because some micro and small operators still move to 30 December 2026 - Commission benchmarking and the information system are earlier dependencies, so plan readiness before the legal application dates ## Deliverable - the EUDR scope memo (copy/paste structure) The best output of this test is a one-page memo per SKU group/supply chain path. It prevents re-scoping and supports procurement, audits, and supplier onboarding. Write it once, keep it versioned, and reuse it in every due diligence statement workflow. - Products in scope (Annex I mapping) and excluded products (with rationale) - Role per flow (operator/downstream operator/trader) and responsible internal owner - Country of production/origin and traceability approach (batch/lot identifiers) - Evidence plan: geolocation, legality documents, deforestation-free proof, and retention - System plan: information system usage and due diligence statement reference number handling *Recommended next step* *Placement: after the applicability result* ## Operationalize EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Applicability Test across ESG workflows ESG Compliance can take EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Applicability Test](/solutions/esg-compliance.md): Start from EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Applicability Test and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence](/contact.md): Review your current process, evidence gaps, and next steps for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Applicability Test. ## Primary sources - [Consolidated EUDR (Regulation (EU) 2023/1115) - ELI (2025-12-26)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Consolidated text used for application dates, definitions, and Annex I scope references. - [EUDR key definitions and obligations (extracts) - Eur-Lex (ELI)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Extracted definitions (operator/downstream operator/trader) and due diligence structure (Articles 8-11) plus due diligence statement responsibilities. - [European Commission - EUDR overview page](https://environment.ec.europa.eu/topics/forests/deforestation/regulation-deforestation-free-products_en?ref=sorena.io) - High-level overview and application timing framing for EUDR. ## Related Topic Guides - [Compliance Program | EUDR Implementation Playbook: Governance, Controls, Supplier Onboarding, Evidence](/artifacts/eu/deforestation-regulation/compliance.md): Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline. - [Deadlines and Compliance Calendar | EUDR Key Dates 2024 to 2029](/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar.md): EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing. - [Deadlines, Phasing, and What to Do First | EUDR Implementation Plan (90 Days -> Go-Live)](/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first.md): A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence. - [Due Diligence Statement (DDS) and Evidence Pack | EUDR: What to Collect, Store, and Prove](/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence.md): EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream. - [EUDR Checklist | EU Deforestation Regulation Compliance Checklist (Scope -> DDS -> Evidence)](/artifacts/eu/deforestation-regulation/checklist.md): A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline. - [EUDR Due Diligence Statement Template | Copy/Paste DDS Structure and Evidence Checklist](/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template.md): A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data. - [EUDR vs CSDDD | What's Different, What Overlaps, and How to Build One Evidence Program](/artifacts/eu/deforestation-regulation/eudr-vs-csddd.md): EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions. - [FAQ | EUDR Explained: Scope, Roles, DDS Reference Numbers, Geolocation, Risk Mitigation, Penalties](/artifacts/eu/deforestation-regulation/faq.md): EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is. - [Geolocation Data Requirements | EUDR: Plots of Land, Establishments, Validation, Exceptions](/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements.md): EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments). - [Geolocation, Traceability, and Systems | EUDR Technical Architecture and Data Model](/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems.md): Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows. - [In-Scope Commodities and Products (Annex I) | EUDR Scope Mapping Guide](/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products.md): EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends. - [Penalties and Enforcement | EUDR Enforcement Actions, Corrective Measures, Interim Measures, Reporting](/artifacts/eu/deforestation-regulation/penalties-and-enforcement.md): How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension). - [Penalties and Fines | EUDR Penalty Framework (Article 25): Turnover-Based Fines and Other Measures](/artifacts/eu/deforestation-regulation/penalties-and-fines.md): EUDR penalties explained (Article 25): Member State penalty rules. - [Requirements | EU Deforestation Regulation (EUDR) Obligations: Due Diligence, Geolocation, Traceability, Roles](/artifacts/eu/deforestation-regulation/requirements.md): A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a. - [Risk Assessment and Mitigation | EUDR Due Diligence (Articles 10-11) Playbook](/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation.md): EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/deforestation-regulation/applicability-test --- --- title: "EUDR Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/checklist" source_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/checklist" author: "Sorena AI" description: "A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline." published_at: "2026-02-22" updated_at: "2026-02-23" keywords: - "EUDR checklist" - "EU Deforestation Regulation checklist" - "EUDR compliance checklist" - "due diligence statement checklist EUDR" - "EUDR geolocation checklist" - "EUDR evidence checklist" - "EUDR risk assessment mitigation checklist" - "EUDR supplier onboarding checklist" - "EU compliance" - "EUDR compliance" - "checklist" - "due diligence statement" - "geolocation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EUDR Checklist A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline. *Artifact Guide* *EU* ## EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Checklist An evidence-first checklist that teams can execute (and auditors can verify). Use this as a delivery backlog: scope -> data -> suppliers -> risk controls -> DDS operations -> enforcement readiness. EUDR readiness is a cross-functional delivery program. This checklist is organized by the workstreams that actually ship compliance: product master data, supplier onboarding, geolocation and evidence pipelines, risk assessment and mitigation, DDS operations and reference numbers, and enforcement readiness. The goal is not just to publish a policy. The goal is to prove compliance per lot and per shipment. ## 0) Scope and ownership (foundational) Before you build anything, remove ambiguity: which products are in scope and who is responsible as operator/downstream operator/trader for each flow. Write the scope memo and attach owners. Everything else depends on it. - SKU -> Annex I mapping table built and integrated into master data - Role mapping per flow (operator/downstream operator/trader) with named owners - Country of production/origin captured at lot level (not just supplier HQ) - Delivery gate designed: where DDS reference number will be required ## 1) Supplier onboarding and data contracts Treat supplier onboarding like an integration contract: define required fields, validation rules, and submission cadence. The goal is to make evidence collection predictable and complete. - Supplier data contract: geolocation + legality/deforestation-free evidence + traceability identifiers - Submission channel: portal/API/EDI with validation before acceptance - Update and correction workflow (versioned submissions and lot impact mapping) - SLAs: response time and completeness expectations, plus escalation path ## 2) Geolocation pipeline (Article 9 evidence input) Geolocation is a common blocker. Make it a pipeline with validations and exceptions, not a document dump. Link geolocation to lots so evidence retrieval is fast. - Geolocation dataset: plot/establishment IDs linked to supplier IDs and lots - Validation controls: format, completeness, mismatch detection, anomaly triggers - Exception register: documented eligibility where postal addresses are used (specific contexts) - Retention and retrieval: query by lot/shipment and export an evidence pack quickly ## 3) Evidence pack: deforestation-free + legality EUDR's core conditions require evidence. Build a structured evidence index for each lot and supplier, not a shared drive of PDFs. Evidence must be retrievable on request. - Deforestation-free evidence plan and verification outputs per supplier group - Legality evidence plan per country of production (permits, land tenure, etc.) - Evidence indexing: document IDs, owners, timestamps, and retention locations - Audit trail: immutable logs of evidence access and changes ## 4) Risk assessment and mitigation (Articles 10-11) Risk decisions must be auditable and repeatable. Define a risk model and a mitigation menu that teams can execute before placement/export. Benchmarking impacts risk posture but doesn't replace evidence quality controls. - Risk model inputs: origin risk, supplier risk, evidence quality, mixing/circumvention risk - Decision governance: who approves a 'negligible risk' outcome and how it is recorded - Mitigation actions: corrective actions, enhanced verification, segregation, monitoring - Reassessment: document post-mitigation outcome before release ## 5) DDS operations (Article 4): reference numbers as a hard gate Operators must not place on the market or export without prior submission of a DDS (or simplified declaration where applicable). That makes reference numbers an operational gate. Design for downstream propagation and retention. - Submission workflow designed (operator and authorised representative handling if used) - Reference numbers stored on lots/shipments/invoices and validated before release - Downstream propagation: structured handoff to customers/recipients - Retention: DDS references and linked evidence pack retrievable for years ## 6) Enforcement readiness (don't wait to test) Enforcement readiness means you can respond quickly: produce evidence, explain risk decisions, and demonstrate controls. Run drills: simulate a competent authority request and measure time-to-evidence. - Completed evidence retrieval drill per commodity group (time-to-evidence measured) - Corrective action playbook for non-compliance findings - Interim measures and shipment holds procedure (how to stop release fast) - Penalties awareness: financial and reputational impact model for major non-compliance *Recommended next step* *Placement: after the checklist block* ## Operationalize EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Checklist across ESG workflows ESG Compliance can take EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Checklist](/solutions/esg-compliance.md): Start from EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Checklist and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence](/contact.md): Review your current process, evidence gaps, and next steps for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Checklist. ## Primary sources - [EUDR key definitions and obligations (extracts) - Eur-Lex (ELI)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Scope trigger (Article 3), operator obligations and DDS reference handling (Article 4), downstream/trader duties (Article 5), and due diligence structure (Articles 8-11). - [Consolidated EUDR (Regulation (EU) 2023/1115) - ELI (2025-12-26)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Broader enforcement context and penalty framework in the consolidated text. ## Related Topic Guides - [Applicability Test | EU Deforestation Regulation (EUDR): In-Scope Products, Roles, Dates](/artifacts/eu/deforestation-regulation/applicability-test.md): A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator. - [Compliance Program | EUDR Implementation Playbook: Governance, Controls, Supplier Onboarding, Evidence](/artifacts/eu/deforestation-regulation/compliance.md): Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline. - [Deadlines and Compliance Calendar | EUDR Key Dates 2024 to 2029](/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar.md): EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing. - [Deadlines, Phasing, and What to Do First | EUDR Implementation Plan (90 Days -> Go-Live)](/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first.md): A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence. - [Due Diligence Statement (DDS) and Evidence Pack | EUDR: What to Collect, Store, and Prove](/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence.md): EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream. - [EUDR Due Diligence Statement Template | Copy/Paste DDS Structure and Evidence Checklist](/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template.md): A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data. - [EUDR vs CSDDD | What's Different, What Overlaps, and How to Build One Evidence Program](/artifacts/eu/deforestation-regulation/eudr-vs-csddd.md): EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions. - [FAQ | EUDR Explained: Scope, Roles, DDS Reference Numbers, Geolocation, Risk Mitigation, Penalties](/artifacts/eu/deforestation-regulation/faq.md): EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is. - [Geolocation Data Requirements | EUDR: Plots of Land, Establishments, Validation, Exceptions](/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements.md): EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments). - [Geolocation, Traceability, and Systems | EUDR Technical Architecture and Data Model](/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems.md): Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows. - [In-Scope Commodities and Products (Annex I) | EUDR Scope Mapping Guide](/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products.md): EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends. - [Penalties and Enforcement | EUDR Enforcement Actions, Corrective Measures, Interim Measures, Reporting](/artifacts/eu/deforestation-regulation/penalties-and-enforcement.md): How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension). - [Penalties and Fines | EUDR Penalty Framework (Article 25): Turnover-Based Fines and Other Measures](/artifacts/eu/deforestation-regulation/penalties-and-fines.md): EUDR penalties explained (Article 25): Member State penalty rules. - [Requirements | EU Deforestation Regulation (EUDR) Obligations: Due Diligence, Geolocation, Traceability, Roles](/artifacts/eu/deforestation-regulation/requirements.md): A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a. - [Risk Assessment and Mitigation | EUDR Due Diligence (Articles 10-11) Playbook](/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation.md): EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/deforestation-regulation/checklist --- --- title: "Compliance Program" canonical_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/compliance" source_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/compliance" author: "Sorena AI" description: "Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline." published_at: "2026-02-22" updated_at: "2026-02-23" keywords: - "EUDR compliance program" - "EUDR implementation playbook" - "EU Deforestation Regulation compliance roadmap" - "EUDR supplier onboarding program" - "EUDR evidence pack" - "EUDR geolocation pipeline" - "due diligence statement operations" - "EU compliance" - "EUDR compliance" - "implementation" - "governance" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Compliance Program Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline. *Artifact Guide* *EU* ## EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Compliance Program Run EUDR like a delivery program: owners, systems, evidence, and drills. This is not a policy page. It's a playbook for shipping geolocation, traceability, risk controls, and DDS operations. EUDR compliance is an evidence-driven supply chain program. Success requires aligned ownership across procurement, supply chain operations, product master data, engineering, security, and legal. The most reliable approach is evidence-first: design workflows and controls that automatically produce audit-ready artifacts such as scope mapping tables, geolocation datasets, risk case files, and DDS reference number logs. ## 1) Program setup: scope memo, owners, and control model Start with a scope memo per commodity group and supply chain path: which SKUs are in scope (Annex I mapping), who plays which role, and what evidence is required. Assign owners by workstream so delivery happens in parallel. - Scope mapping owner: SKU -> Annex I table and master data integration - Supplier onboarding owner: evidence requirements, SLAs, and escalation - Data/engineering owner: geolocation pipeline, evidence store, and DDS operations - Risk owner: risk model, decision governance, and mitigation playbook ## 2) Supplier onboarding and evidence pipeline (the core work) Most EUDR delays are supplier data delays. Treat supplier onboarding as a data contract with validations and versioning. Build an evidence pipeline that links documents and geolocation to lots and shipments. - Supplier data contract: geolocation + legality + deforestation-free evidence + traceability keys - Validation layer: completeness, format, mismatch detection, anomaly triggers - Evidence indexing: lot/shipment -> supplier -> production site -> evidence - Retention and retrieval design with immutable logs ## 3) Risk assessment and mitigation operating model (Articles 10-11) Risk decisions must be consistent and auditable. Build a risk model and a mitigation menu that teams can execute before release. Treat risk as a gate: no 'negligible risk' decision record -> no DDS packet -> no ship. - Risk model inputs: origin risk, supplier risk, evidence quality, mixing/circumvention risk - Decision governance: who approves and how decisions are stored and linked to lots - Mitigation actions: corrective actions, enhanced verification, segregation, monitoring - Reassessment: document post-mitigation outcome and approval ## 4) DDS operations (Article 4): reference numbers as a release gate DDS submission is an operational gate. It must be integrated into shipping/logistics and downstream customer handoffs. Build it as a production workflow with SLAs, access control, and audit logs. - Submission workflow via the information system and reference number storage fields - Release gate enforcement: no valid reference number -> no ship - Downstream propagation: structured reference number handoff to recipients - Retention: reference numbers and linked evidence packs retrievable for years ## 5) Operating cadence and drills (make audit readiness real) Compliance is an operating cadence. You should continuously test your ability to retrieve evidence and explain risk decisions. Drills prevent last-minute panic and reveal data gaps early. - Monthly: supplier data completeness metrics and exception backlog - Quarterly: scope mapping and master-data review, plus risk model tuning - Semiannual: evidence retrieval drill per commodity group (time-to-evidence measured) - Annual: end-to-end DDS workflow drill from supplier intake to reference number propagation *Recommended next step* *Placement: after the compliance steps* ## Operationalize EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Compliance Program across ESG workflows ESG Compliance can take EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Compliance Program](/solutions/esg-compliance.md): Start from EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Compliance Program and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence](/contact.md): Review your current process, evidence gaps, and next steps for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Compliance Program. ## Primary sources - [European Commission - EUDR overview page](https://environment.ec.europa.eu/topics/forests/deforestation/regulation-deforestation-free-products_en?ref=sorena.io) - High-level overview and program context for EUDR implementation. - [EUDR key definitions and obligations (extracts) - Eur-Lex (ELI)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Scope trigger, role definitions, due diligence steps (Articles 8-11), and DDS submission framing (Article 4). - [Commission Implementing Regulation (EU) 2024/3084 (EUDR information system) - CELEX](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R3084&ref=sorena.io) - Information system operational context for managing due diligence statements. ## Related Topic Guides - [Applicability Test | EU Deforestation Regulation (EUDR): In-Scope Products, Roles, Dates](/artifacts/eu/deforestation-regulation/applicability-test.md): A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator. - [Deadlines and Compliance Calendar | EUDR Key Dates 2024 to 2029](/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar.md): EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing. - [Deadlines, Phasing, and What to Do First | EUDR Implementation Plan (90 Days -> Go-Live)](/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first.md): A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence. - [Due Diligence Statement (DDS) and Evidence Pack | EUDR: What to Collect, Store, and Prove](/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence.md): EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream. - [EUDR Checklist | EU Deforestation Regulation Compliance Checklist (Scope -> DDS -> Evidence)](/artifacts/eu/deforestation-regulation/checklist.md): A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline. - [EUDR Due Diligence Statement Template | Copy/Paste DDS Structure and Evidence Checklist](/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template.md): A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data. - [EUDR vs CSDDD | What's Different, What Overlaps, and How to Build One Evidence Program](/artifacts/eu/deforestation-regulation/eudr-vs-csddd.md): EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions. - [FAQ | EUDR Explained: Scope, Roles, DDS Reference Numbers, Geolocation, Risk Mitigation, Penalties](/artifacts/eu/deforestation-regulation/faq.md): EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is. - [Geolocation Data Requirements | EUDR: Plots of Land, Establishments, Validation, Exceptions](/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements.md): EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments). - [Geolocation, Traceability, and Systems | EUDR Technical Architecture and Data Model](/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems.md): Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows. - [In-Scope Commodities and Products (Annex I) | EUDR Scope Mapping Guide](/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products.md): EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends. - [Penalties and Enforcement | EUDR Enforcement Actions, Corrective Measures, Interim Measures, Reporting](/artifacts/eu/deforestation-regulation/penalties-and-enforcement.md): How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension). - [Penalties and Fines | EUDR Penalty Framework (Article 25): Turnover-Based Fines and Other Measures](/artifacts/eu/deforestation-regulation/penalties-and-fines.md): EUDR penalties explained (Article 25): Member State penalty rules. - [Requirements | EU Deforestation Regulation (EUDR) Obligations: Due Diligence, Geolocation, Traceability, Roles](/artifacts/eu/deforestation-regulation/requirements.md): A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a. - [Risk Assessment and Mitigation | EUDR Due Diligence (Articles 10-11) Playbook](/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation.md): EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/deforestation-regulation/compliance --- --- title: "Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar" author: "Sorena AI" description: "EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing." published_at: "2026-02-22" updated_at: "2026-02-23" keywords: - "EUDR deadlines" - "EUDR compliance calendar" - "EUDR key dates" - "EUDR applies 30 December 2026" - "EUDR micro small 30 June 2027" - "due diligence statement information system Article 33" - "EUDR benchmarking list 2025" - "EU compliance" - "EUDR compliance" - "Deadlines and Compliance Calendar" - "due diligence statement" - "traceability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Deadlines and Compliance Calendar EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing. *Artifact Guide* *EU* ## EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Deadlines and Compliance Calendar Treat EUDR dates like release gates: data readiness, supplier onboarding, and due diligence statements. This calendar highlights the milestones that block go-live: information system, benchmarking, and application dates. EUDR implementation is constrained by a few hard dates and several dependency milestones. Use this calendar to plan data readiness, supplier onboarding and traceability rollout, and the operational gate for due diligence statement reference numbers. The main compliance date is 30 December 2026, with a later 30 June 2027 date for certain natural persons and micro or small undertakings established by 31 December 2024, subject to the conditions in the Regulation. ## Calendar overview - the dates that matter operationally This is the high-signal calendar: key obligations and dependency milestones you should reflect in your backlog and procurement deadlines. If you wait until the main application date to start evidence collection and system design, you will not catch up. - 30 Dec 2024: Commission must establish and maintain the information system for due diligence statements (Article 33) - 30 Jun 2025: Commission must publish the benchmarking list of low-risk and high-risk countries/regions (Article 29) - 30 Dec 2026: Core EUDR obligations apply for large and medium operators and traders and for micro and small operators already covered by the EU Timber Regulation - 30 Jun 2027: Later application date for certain natural persons and micro or small undertakings established by 31 Dec 2024 - 31 Dec 2029: Timber transition: for certain timber/timber products produced before 29 Jun 2023 and placed on the market from 30 Dec 2026, the EU Timber Regulation continues to apply until this date (under the conditions in the Regulation) *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Deadlines and Compliance Calendar across ESG workflows ESG Compliance can take EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Deadlines and Compliance Calendar](/solutions/esg-compliance.md): Start from EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Deadlines and Compliance Calendar and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence](/contact.md): Review your current process, evidence gaps, and next steps for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Deadlines and Compliance Calendar. ## Release gate 1 - scope and master data readiness (now) Scope mapping is your first release gate. It unlocks the rest: which products need geolocation, what supplier evidence to request, and who is responsible as operator vs trader. Make scope mapping a master-data deliverable, not a spreadsheet that dies in email. - Build a SKU -> Annex I mapping table with owners and review cadence - Define role per flow (operator/downstream operator/trader) and link to transaction types - Add flags in product master data that trigger EUDR workflows ## Release gate 2 - geolocation and evidence pipeline (before go-live) The due diligence system requires information and evidence collection, including geolocation of plots of land/establishments (with specific handling for certain micro/small primary operators). Treat geolocation as a pipeline: collection, validation, storage, and packaging per batch/lot. - Supplier onboarding to capture plot geolocation and legality/deforestation-free evidence - Data quality controls (completeness, format validation, mismatch detection) - Evidence retention and retrieval: be able to provide documentation to competent authorities on request ## Release gate 3 - due diligence statement operations and reference numbers Operators must not place on the market or export without prior submission of a due diligence statement, or a simplified declaration where the Regulation allows it. This creates an operational gate in your shipping and release flow. Design for reuse: reference numbers and identifiers must be communicated down the supply chain and retained for years. - Implement a no reference number, no ship control for relevant products - Store and retain due diligence statement references/identifiers for at least five years (and ensure downstream handoff) - Build exception handling: corrections, cancellations, and supplier non-response ## Release gate 4 - benchmarking and simplified due diligence decisions Benchmarking affects your risk posture and whether simplified due diligence may apply for low-risk production. Prepare to update decisions when the benchmarking list is published and as it changes. Even in low-risk contexts, you must control complexity and circumvention/mixing risk. - Implement a benchmarking watcher: classify origin regions and trigger re-assessment on list updates - Define a low-risk playbook: what evidence is still required and how mixing/circumvention is controlled - Document decisions and keep them auditable (who approved, when, and based on what evidence) ## Primary sources - [Consolidated EUDR (Regulation (EU) 2023/1115) - ELI (2025-12-26)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Timeline and application dates, including Article 33 information system milestone, Article 29 benchmarking date, and Article 38 application timing. - [European Commission - EUDR overview page](https://environment.ec.europa.eu/topics/forests/deforestation/regulation-deforestation-free-products_en?ref=sorena.io) - High-level timeline framing for EUDR application dates. ## Related Topic Guides - [Applicability Test | EU Deforestation Regulation (EUDR): In-Scope Products, Roles, Dates](/artifacts/eu/deforestation-regulation/applicability-test.md): A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator. - [Compliance Program | EUDR Implementation Playbook: Governance, Controls, Supplier Onboarding, Evidence](/artifacts/eu/deforestation-regulation/compliance.md): Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline. - [Deadlines, Phasing, and What to Do First | EUDR Implementation Plan (90 Days -> Go-Live)](/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first.md): A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence. - [Due Diligence Statement (DDS) and Evidence Pack | EUDR: What to Collect, Store, and Prove](/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence.md): EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream. - [EUDR Checklist | EU Deforestation Regulation Compliance Checklist (Scope -> DDS -> Evidence)](/artifacts/eu/deforestation-regulation/checklist.md): A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline. - [EUDR Due Diligence Statement Template | Copy/Paste DDS Structure and Evidence Checklist](/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template.md): A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data. - [EUDR vs CSDDD | What's Different, What Overlaps, and How to Build One Evidence Program](/artifacts/eu/deforestation-regulation/eudr-vs-csddd.md): EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions. - [FAQ | EUDR Explained: Scope, Roles, DDS Reference Numbers, Geolocation, Risk Mitigation, Penalties](/artifacts/eu/deforestation-regulation/faq.md): EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is. - [Geolocation Data Requirements | EUDR: Plots of Land, Establishments, Validation, Exceptions](/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements.md): EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments). - [Geolocation, Traceability, and Systems | EUDR Technical Architecture and Data Model](/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems.md): Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows. - [In-Scope Commodities and Products (Annex I) | EUDR Scope Mapping Guide](/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products.md): EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends. - [Penalties and Enforcement | EUDR Enforcement Actions, Corrective Measures, Interim Measures, Reporting](/artifacts/eu/deforestation-regulation/penalties-and-enforcement.md): How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension). - [Penalties and Fines | EUDR Penalty Framework (Article 25): Turnover-Based Fines and Other Measures](/artifacts/eu/deforestation-regulation/penalties-and-fines.md): EUDR penalties explained (Article 25): Member State penalty rules. - [Requirements | EU Deforestation Regulation (EUDR) Obligations: Due Diligence, Geolocation, Traceability, Roles](/artifacts/eu/deforestation-regulation/requirements.md): A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a. - [Risk Assessment and Mitigation | EUDR Due Diligence (Articles 10-11) Playbook](/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation.md): EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar --- --- title: "Deadlines, Phasing, and What to Do First" canonical_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first" source_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first" author: "Sorena AI" description: "A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence." published_at: "2026-02-22" updated_at: "2026-02-23" keywords: - "EUDR implementation plan" - "EUDR rollout plan" - "EUDR what to do first" - "EUDR due diligence statement process" - "EUDR geolocation data collection" - "EUDR supplier onboarding" - "EUDR risk assessment mitigation" - "EUDR applies 30 December 2026" - "EU compliance" - "EUDR compliance" - "implementation plan" - "due diligence" - "traceability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Deadlines, Phasing, and What to Do First A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence. *Artifact Guide* *EU* ## EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Phasing and What to Do First A staged rollout plan to reach go-live with real evidence, not last-minute paperwork. Sequence: scope mapping -> geolocation + evidence -> supplier onboarding -> risk controls -> due diligence statements. EUDR readiness is a supply chain and data engineering program. If you start with policies, you will finish with missing geolocation and non-operational due diligence statements. Start with master data and supplier onboarding, build an evidence pipeline, then operationalize due diligence statements as a hard gate so shipments do not move without a valid reference number. This page gives a practical sequence you can turn into a 90-day plan and a go-live roadmap toward 30 December 2026. ## Phase 1 (first 30 days): scope, roles, and product master data Your first month is about removing ambiguity. You can't collect the right evidence if you don't know which products are in scope or who is responsible as operator vs trader. Deliver master-data outputs, not slide decks. - Build a SKU -> Annex I mapping table and integrate it into product master data - Map roles per flow (operator/downstream operator/trader) and assign owners - Define evidence requirements per commodity and per supplier type (geolocation, legality, deforestation-free proof) - Design the shipment/release gate: where the DDS reference number will be required ## Phase 2 (days 30-60): supplier onboarding and geolocation pipeline EUDR due diligence is evidence-first. The hardest evidence to retrofit is geolocation and chain-of-custody traceability, so build it early. Treat suppliers as systems: define the data contract you need and validate it. - Supplier intake: geolocation data collection (plots/establishments) and document requirements - Traceability design: batch/lot identifiers that connect input commodity to finished goods - Data quality controls: completeness checks, format validation, mismatch detection - Retention and retrieval design: evidence must be retrievable on request and retained for years ## Phase 3 (days 60-90): risk assessment and mitigation controls Due diligence includes risk assessment and risk mitigation. Your controls should be repeatable and auditable, especially for high-risk origins and complex chains. Build a mitigation menu: actions you can actually take before placing products on the market. - Risk model inputs: origin risk, supplier history, mixing/circumvention risk, documentation quality - Mitigation actions: supplier corrective actions, enhanced verification, segregation, and monitoring - Decision governance: define who can approve 'negligible risk' outcomes and how evidence is stored - Prepare for benchmarking changes: update risk posture when low/high-risk lists change ## Phase 4 (go-live): due diligence statement operations as a hard gate Operators must not place on the market or export without prior submission of a due diligence statement (or simplified declaration where applicable). That means you need production-grade operations, not a spreadsheet workflow. Design for reuse and downstream handoff: reference numbers must flow through the chain and be retained. - Implement DDS submission workflow and reference number storage - Enforce the release gate in logistics: no valid reference number -> no ship - Communicate reference numbers downstream and keep evidence for at least five years - Run drills: simulate a competent authority request for evidence and time your response ## A minimal go-live evidence pack (what 'ready' looks like) EUDR readiness is provable. If you can assemble this pack quickly, you're usually operationally ready. Automate as much as possible (logs, snapshots, case files). - SKU -> Annex I mapping + change log + owners - Supplier data contracts + geolocation validation evidence - Risk assessment model + decision records + mitigation actions - DDS workflow evidence: submissions, reference number storage, and downstream handoff - Retention and retrieval proof: can you produce evidence for a specific lot quickly? *Recommended next step* *Placement: after the timeline or milestone section* ## Use EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Phasing and What to Do First as a cited research workflow Research Copilot can take EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Phasing and What to Do First from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Phasing and What to Do First](/solutions/research-copilot.md): Start from EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Phasing and What to Do First and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence](/contact.md): Review your current process, evidence gaps, and next steps for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Phasing and What to Do First. ## Primary sources - [Consolidated EUDR (Regulation (EU) 2023/1115) - ELI (2025-12-26)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Application dates and due diligence statement system dependencies referenced in the phasing plan. - [EUDR key definitions and obligations (extracts) - Eur-Lex (ELI)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Due diligence system structure (Articles 8-11) and the operator obligation to submit a due diligence statement before placement/export. ## Related Topic Guides - [Applicability Test | EU Deforestation Regulation (EUDR): In-Scope Products, Roles, Dates](/artifacts/eu/deforestation-regulation/applicability-test.md): A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator. - [Compliance Program | EUDR Implementation Playbook: Governance, Controls, Supplier Onboarding, Evidence](/artifacts/eu/deforestation-regulation/compliance.md): Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline. - [Deadlines and Compliance Calendar | EUDR Key Dates 2024 to 2029](/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar.md): EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing. - [Due Diligence Statement (DDS) and Evidence Pack | EUDR: What to Collect, Store, and Prove](/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence.md): EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream. - [EUDR Checklist | EU Deforestation Regulation Compliance Checklist (Scope -> DDS -> Evidence)](/artifacts/eu/deforestation-regulation/checklist.md): A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline. - [EUDR Due Diligence Statement Template | Copy/Paste DDS Structure and Evidence Checklist](/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template.md): A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data. - [EUDR vs CSDDD | What's Different, What Overlaps, and How to Build One Evidence Program](/artifacts/eu/deforestation-regulation/eudr-vs-csddd.md): EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions. - [FAQ | EUDR Explained: Scope, Roles, DDS Reference Numbers, Geolocation, Risk Mitigation, Penalties](/artifacts/eu/deforestation-regulation/faq.md): EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is. - [Geolocation Data Requirements | EUDR: Plots of Land, Establishments, Validation, Exceptions](/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements.md): EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments). - [Geolocation, Traceability, and Systems | EUDR Technical Architecture and Data Model](/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems.md): Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows. - [In-Scope Commodities and Products (Annex I) | EUDR Scope Mapping Guide](/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products.md): EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends. - [Penalties and Enforcement | EUDR Enforcement Actions, Corrective Measures, Interim Measures, Reporting](/artifacts/eu/deforestation-regulation/penalties-and-enforcement.md): How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension). - [Penalties and Fines | EUDR Penalty Framework (Article 25): Turnover-Based Fines and Other Measures](/artifacts/eu/deforestation-regulation/penalties-and-fines.md): EUDR penalties explained (Article 25): Member State penalty rules. - [Requirements | EU Deforestation Regulation (EUDR) Obligations: Due Diligence, Geolocation, Traceability, Roles](/artifacts/eu/deforestation-regulation/requirements.md): A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a. - [Risk Assessment and Mitigation | EUDR Due Diligence (Articles 10-11) Playbook](/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation.md): EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first --- --- title: "Due Diligence Statement (DDS) and Evidence Pack" canonical_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence" source_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence" author: "Sorena AI" description: "EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream." published_at: "2026-02-22" updated_at: "2026-02-23" keywords: - "EUDR due diligence statement" - "DDS EUDR reference number" - "EUDR evidence pack" - "EUDR geolocation evidence" - "EUDR legality documents" - "no reference number no ship EUDR" - "EUDR Article 33 information system" - "EU compliance" - "EUDR compliance" - "due diligence statement" - "evidence" - "geolocation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Due Diligence Statement (DDS) and Evidence Pack EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream. *Artifact Guide* *EU* ## EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence DDS and Evidence Pack Make due diligence statements operational: evidence in, reference number out, shipment released. Focus: operator responsibility, simplified declaration edge cases, evidence structure, retention, and downstream handoff of DDS references. Under EUDR, the due diligence statement is not a reporting afterthought. It is the operational gate that allows relevant products to be placed on the market or exported. Operators submit a DDS unless the Regulation gives them access to the simplified declaration route. Your job is to build an evidence pipeline that produces a defensible submission, stores the right artifacts for years, and makes DDS reference numbers or declaration identifiers flow downstream reliably. ## 1) What is a DDS and why it should be a hard shipping gate A DDS is the formal mechanism by which operators take responsibility for compliance for relevant products they intend to place on the market or export. Treat it as a hard gate in your process: no reference number, no ship. Design the gate so it is enforceable in ERP/logistics systems, not just in policy. - Define where the gate lives (purchase order release, warehouse picking, customs/export docs, etc.) - Store DDS reference numbers at batch/lot level and link them to shipments and invoices - Build exception handling: supplier non-response, data quality failures, corrections ## 2) Who submits and who remains responsible Operators may mandate an authorised representative to submit the DDS or simplified declaration on their behalf, but the operator retains responsibility for Article 3 compliance. Micro or small primary operators follow the simplified declaration route in Article 4a, while other operators still need the full DDS route. If you delegate submission, you still need the evidence and the internal approvals. - Document delegation: which role submits vs which role approves risk outcome - Document whether the flow uses a DDS reference number or a declaration identifier - Keep an internal approval trail: scope, risk decision, and mitigation actions - Ensure access controls and audit logs for the submission process ## 3) Evidence categories you should always be able to produce (Articles 9-11 structure) Due diligence includes information collection, risk assessment, and risk mitigation. Build your evidence pack around that structure so it's easy to defend. Geolocation and legality evidence are common blockers-design them as first-class artifacts. - Information collection: geolocation of plots/establishments (as applicable) and documentation demonstrating deforestation-free and legal production - Risk assessment: model inputs (origin, supplier, mixing/circumvention), decision record, and approval - Risk mitigation: actions taken when risk is not negligible and the reassessment outcome - Traceability: batch/lot linkage from input commodity to finished goods *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence DDS and Evidence Pack in one governed evidence system SSOT can take EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence DDS and Evidence Pack from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence DDS and Evidence Pack](/solutions/ssot.md): Start from EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence DDS and Evidence Pack and keep documents, evidence, and control records in one governed system. - [Talk through EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence](/contact.md): Review your current process, evidence gaps, and next steps for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence DDS and Evidence Pack. ## 4) Reference number handoff and Article 5 downstream duties Operators must keep a record of due diligence statements for five years and communicate DDS reference numbers or declaration identifiers further down the supply chain. Downstream operators and traders must keep the Article 5 information set for at least five years as well. Make this deterministic: downstream recipients should receive structured identifiers, not screenshots or PDFs. - Add DDS reference numbers to invoices, ASNs, and product passports/traceability records where relevant - Require structured handoff in B2B integrations (EDI/API fields, not free text) - Retain downstream recipient history showing who received which reference numbers or declaration identifiers and when ## 5) Retention and audit-readiness: make evidence retrievable fast Retention is not just storage-it's retrieval. Your evidence pack must be queryable by lot, shipment, supplier, and production site. Build a 'competent authority request drill': can you produce the evidence within hours, not weeks? - Retention policy aligned to the Regulation's retention expectations (DDS references and related evidence) - Indexing: lot/shipment -> supplier -> production site -> geolocation -> evidence documents - Immutable logs: who accessed/changed evidence and when ## Primary sources - [EUDR key definitions and obligations (extracts) - Eur-Lex (ELI)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Operator obligation to submit a DDS before placement or export, simplified declaration rules for Article 4a operators, and due diligence structure in Articles 8 to 11, including geolocation and evidence collection in Article 9 and retention and communication of identifiers. - [Commission Implementing Regulation (EU) 2024/3084 (EUDR information system) - CELEX](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R3084&ref=sorena.io) - Operational details on the information system used to submit and manage due diligence statements. ## Related Topic Guides - [Applicability Test | EU Deforestation Regulation (EUDR): In-Scope Products, Roles, Dates](/artifacts/eu/deforestation-regulation/applicability-test.md): A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator. - [Compliance Program | EUDR Implementation Playbook: Governance, Controls, Supplier Onboarding, Evidence](/artifacts/eu/deforestation-regulation/compliance.md): Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline. - [Deadlines and Compliance Calendar | EUDR Key Dates 2024 to 2029](/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar.md): EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing. - [Deadlines, Phasing, and What to Do First | EUDR Implementation Plan (90 Days -> Go-Live)](/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first.md): A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence. - [EUDR Checklist | EU Deforestation Regulation Compliance Checklist (Scope -> DDS -> Evidence)](/artifacts/eu/deforestation-regulation/checklist.md): A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline. - [EUDR Due Diligence Statement Template | Copy/Paste DDS Structure and Evidence Checklist](/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template.md): A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data. - [EUDR vs CSDDD | What's Different, What Overlaps, and How to Build One Evidence Program](/artifacts/eu/deforestation-regulation/eudr-vs-csddd.md): EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions. - [FAQ | EUDR Explained: Scope, Roles, DDS Reference Numbers, Geolocation, Risk Mitigation, Penalties](/artifacts/eu/deforestation-regulation/faq.md): EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is. - [Geolocation Data Requirements | EUDR: Plots of Land, Establishments, Validation, Exceptions](/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements.md): EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments). - [Geolocation, Traceability, and Systems | EUDR Technical Architecture and Data Model](/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems.md): Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows. - [In-Scope Commodities and Products (Annex I) | EUDR Scope Mapping Guide](/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products.md): EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends. - [Penalties and Enforcement | EUDR Enforcement Actions, Corrective Measures, Interim Measures, Reporting](/artifacts/eu/deforestation-regulation/penalties-and-enforcement.md): How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension). - [Penalties and Fines | EUDR Penalty Framework (Article 25): Turnover-Based Fines and Other Measures](/artifacts/eu/deforestation-regulation/penalties-and-fines.md): EUDR penalties explained (Article 25): Member State penalty rules. - [Requirements | EU Deforestation Regulation (EUDR) Obligations: Due Diligence, Geolocation, Traceability, Roles](/artifacts/eu/deforestation-regulation/requirements.md): A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a. - [Risk Assessment and Mitigation | EUDR Due Diligence (Articles 10-11) Playbook](/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation.md): EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence --- --- title: "EUDR Due Diligence Statement Template" canonical_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template" source_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template" author: "Sorena AI" description: "A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data." published_at: "2026-02-22" updated_at: "2026-02-23" keywords: - "EUDR due diligence statement template" - "DDS template EUDR" - "EUDR DDS evidence checklist" - "EUDR geolocation fields template" - "EUDR risk assessment template" - "EUDR mitigation actions template" - "due diligence statement reference number template" - "EU compliance" - "EUDR compliance" - "template" - "due diligence statement" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EUDR Due Diligence Statement Template A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data. *Artifact Guide* *EU* ## EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence DDS Template Standardize your DDS submissions with a repeatable structure and evidence checklist. Use this template as the internal 'approval packet' even if submission happens via the information system UI/API. This is an internal template outline to standardize how your teams prepare an EUDR due diligence statement. The goal is consistency and auditability: every DDS is backed by an evidence pack (geolocation, legality, deforestation-free proof), a risk decision, and mitigation actions where risk is not negligible. Tailor it per commodity and supplier group. ## 1) Header: DDS context (what product flow is being covered) Start by naming the product flow you're covering: SKU group, commodity type, and whether you're placing on the market or exporting. Link the DDS to the batch/lot identifiers that your logistics team actually uses. - Product group and Annex I mapping (commodity/derived product category) - Activity: placing on the market vs exporting (and from which Member State entity) - Batch/lot identifiers and shipment window covered - Owner and approver (operator responsibility owner) ## 2) Supply chain and origin (who supplied what, and where it was produced) EUDR evidence starts with origin and chain-of-custody. Capture it in structured fields, not free text. If origin is multi-region or changes by lot, record it per lot. - Supplier identity and upstream chain (as far as needed for traceability and risk) - Country of production and origin per lot/batch - Chain-of-custody model (segregation vs mass balance) and mixing controls - Downstream recipients (who will receive the DDS reference number) ## 3) Geolocation annex (the most common blocker) Geolocation is a key evidence category. Treat it as a validated annex: provenance, validation checks, and linkage to lots. For certain micro/small primary operator contexts, EUDR provides specific simplifications for geolocation fields. - Geolocation dataset: plot/establishment identifiers linked to lots - Validation: format checks, completeness, and mismatch detection - Provenance: who provided the geolocation and when; evidence of updates - Exception handling: what you do when geolocation is missing or inconsistent ## 4) Legality and deforestation-free evidence annex Your evidence pack should explicitly cover the two core conditions: deforestation-free and produced in accordance with relevant legislation of the country of production. Keep an evidence index with document IDs and storage locations. - Deforestation-free evidence: monitoring sources, supplier attestations, and verification outcomes - Legality evidence: permits, land tenure documentation, and compliance documents appropriate to the country of production - Document index: each artifact has an ID, owner, and retention location *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence DDS Template in one governed evidence system SSOT can take EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence DDS Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence DDS Template](/solutions/ssot.md): Start from EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence DDS Template and keep documents, evidence, and control records in one governed system. - [Talk through EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence](/contact.md): Review your current process, evidence gaps, and next steps for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence DDS Template. ## 5) Risk assessment (Article 10) summary (auditable decision record) Capture the risk decision explicitly: what factors were considered, what the outcome was, and who approved it. This should be reproducible if challenged. - Risk inputs: origin risk, supplier risk, mixing/circumvention risk, documentation quality - Decision: no/only negligible risk vs not negligible risk - Approver identity and decision timestamp - Rationale summary and links to evidence artifacts ## 6) Risk mitigation (Article 11) actions (if risk is not negligible) If risk is not negligible, document what you did before placing/exporting: corrective actions, verification, and reassessment. Mitigation should be measurable and time-bound. - Mitigation actions taken (supplier corrective actions, enhanced verification, segregation, monitoring) - Evidence produced by mitigation actions - Post-mitigation reassessment outcome and approval ## 7) Submission and reference number handling (the operational gate) Regardless of submission method (information system UI/API), you need a standard internal packet and a deterministic way to store and transmit reference numbers. Make the reference number part of your ERP/logistics data model. - Submission method and operator/authorised representative details (if applicable) - DDS reference number storage fields (lot, shipment, invoice, and downstream handoff records) - Retention: keep DDS references and evidence pack retrievable for years - Release gate: no valid reference number -> no ship ## Primary sources - [EUDR key definitions and obligations (extracts) - Eur-Lex (ELI)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - DDS obligation framing (Article 4) and due diligence steps (Articles 8-11), including geolocation and evidence collection (Article 9). - [Commission Implementing Regulation (EU) 2024/3084 (EUDR information system) - CELEX](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R3084&ref=sorena.io) - Information system context for submitting and managing due diligence statements. ## Related Topic Guides - [Applicability Test | EU Deforestation Regulation (EUDR): In-Scope Products, Roles, Dates](/artifacts/eu/deforestation-regulation/applicability-test.md): A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator. - [Compliance Program | EUDR Implementation Playbook: Governance, Controls, Supplier Onboarding, Evidence](/artifacts/eu/deforestation-regulation/compliance.md): Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline. - [Deadlines and Compliance Calendar | EUDR Key Dates 2024 to 2029](/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar.md): EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing. - [Deadlines, Phasing, and What to Do First | EUDR Implementation Plan (90 Days -> Go-Live)](/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first.md): A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence. - [Due Diligence Statement (DDS) and Evidence Pack | EUDR: What to Collect, Store, and Prove](/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence.md): EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream. - [EUDR Checklist | EU Deforestation Regulation Compliance Checklist (Scope -> DDS -> Evidence)](/artifacts/eu/deforestation-regulation/checklist.md): A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline. - [EUDR vs CSDDD | What's Different, What Overlaps, and How to Build One Evidence Program](/artifacts/eu/deforestation-regulation/eudr-vs-csddd.md): EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions. - [FAQ | EUDR Explained: Scope, Roles, DDS Reference Numbers, Geolocation, Risk Mitigation, Penalties](/artifacts/eu/deforestation-regulation/faq.md): EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is. - [Geolocation Data Requirements | EUDR: Plots of Land, Establishments, Validation, Exceptions](/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements.md): EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments). - [Geolocation, Traceability, and Systems | EUDR Technical Architecture and Data Model](/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems.md): Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows. - [In-Scope Commodities and Products (Annex I) | EUDR Scope Mapping Guide](/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products.md): EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends. - [Penalties and Enforcement | EUDR Enforcement Actions, Corrective Measures, Interim Measures, Reporting](/artifacts/eu/deforestation-regulation/penalties-and-enforcement.md): How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension). - [Penalties and Fines | EUDR Penalty Framework (Article 25): Turnover-Based Fines and Other Measures](/artifacts/eu/deforestation-regulation/penalties-and-fines.md): EUDR penalties explained (Article 25): Member State penalty rules. - [Requirements | EU Deforestation Regulation (EUDR) Obligations: Due Diligence, Geolocation, Traceability, Roles](/artifacts/eu/deforestation-regulation/requirements.md): A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a. - [Risk Assessment and Mitigation | EUDR Due Diligence (Articles 10-11) Playbook](/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation.md): EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template --- --- title: "Geolocation Data Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements" source_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements" author: "Sorena AI" description: "EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments)." published_at: "2026-02-22" updated_at: "2026-02-23" keywords: - "EUDR geolocation requirements" - "EUDR plot of land geolocation" - "EUDR geolocation evidence" - "geolocation validation EUDR" - "EUDR Article 9 geolocation" - "micro small primary operator geolocation postal address" - "EUDR traceability geolocation" - "EU compliance" - "EUDR compliance" - "geolocation" - "traceability" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Geolocation Data Requirements EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments). *Artifact Guide* *EU* ## EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Geolocation Requirements Build a geolocation pipeline that suppliers can satisfy and auditors can verify. Focus: geolocation evidence as part of due diligence information collection (Article 9). Geolocation is one of the most operationally demanding EUDR evidence categories. It is not enough to have coordinates in a file. You need plot or establishment location data that is validated, linked to lots and suppliers, handled through exceptions, and retained with proof. Treat geolocation as a pipeline with quality controls and an audit trail. ## 1) Where geolocation sits in EUDR due diligence (Article 9 evidence collection) EUDR due diligence includes information collection, which explicitly includes geolocation of plots of land/establishments (and supporting documentation). Operationally: geolocation is a required input to the risk assessment and to the DDS evidence pack. - Capture geolocation per production plot/establishment and link it to lots/batches - Store provenance: who provided it, when, and under what supplier contract terms - Keep it retrievable: geolocation evidence is only useful if you can produce it on request ## 2) Data model: minimum fields for a usable geolocation dataset A usable geolocation dataset is structured, validated, and linkable to procurement and logistics records. Avoid free-text attachments without indexing. Build it like master data with change control. - Plot/establishment identifier and supplier identifier - Geolocation data (coordinates/polygon as applicable) and coordinate reference assumptions - Country/region of production and applicable origin context - Lot/batch linkage keys and validity date range - Provenance and evidence links (supplier docs, maps, certifications) ## 3) Validation and quality controls (what 'good' looks like) Most geolocation failures are quality failures: missing fields, mismatched lots, wrong coordinate format, or unverifiable provenance. Build automated validations and human review triggers. - Completeness checks: no missing plot IDs, supplier IDs, or lot linkage - Format validation: coordinate format and range checks; polygon closure checks where applicable - Consistency checks: origin country/region matches supplier and shipping records - Anomaly triggers: sudden origin changes, inconsistent plot areas, duplicate plot IDs across suppliers ## 4) Exceptions and simplifications: micro/small primary operator scenarios EUDR includes a simplified regime for certain micro or small primary operators, and it includes a specific simplification: in a defined context, geolocation may be replaced by postal address of plots of land or the establishment. Do not generalize this. Treat it as an explicitly documented exception with eligibility checks. - Confirm eligibility conditions for the simplified regime before applying any simplification - Document the rationale: which rule you rely on, for which supplier, and for which lots - Maintain a path to upgrade: plan how you will obtain geolocation if conditions change ## Geolocation evidence checklist (audit-ready minimum) Use this as the minimum evidence pack for geolocation. If you can't produce these artifacts quickly, you are not operationally ready. Automate snapshots and indexing so retrieval is fast. - Validated geolocation dataset linked to lots and suppliers - Provenance evidence (supplier submission records and updates) - Quality control logs (validation results, anomalies, and resolutions) - Exception register (where postal addresses were used and why) - Retention and retrieval proof (ability to retrieve by shipment/lot) *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Geolocation Requirements across ESG workflows ESG Compliance can take EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Geolocation Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Geolocation Requirements](/solutions/esg-compliance.md): Start from EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Geolocation Requirements and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence](/contact.md): Review your current process, evidence gaps, and next steps for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Geolocation Requirements. ## Primary sources - [EUDR key definitions and obligations (extracts) - Eur-Lex (ELI)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Due diligence information collection (Article 9) includes geolocation, and the simplified handling note for certain micro/small primary operator contexts. ## Related Topic Guides - [Applicability Test | EU Deforestation Regulation (EUDR): In-Scope Products, Roles, Dates](/artifacts/eu/deforestation-regulation/applicability-test.md): A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator. - [Compliance Program | EUDR Implementation Playbook: Governance, Controls, Supplier Onboarding, Evidence](/artifacts/eu/deforestation-regulation/compliance.md): Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline. - [Deadlines and Compliance Calendar | EUDR Key Dates 2024 to 2029](/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar.md): EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing. - [Deadlines, Phasing, and What to Do First | EUDR Implementation Plan (90 Days -> Go-Live)](/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first.md): A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence. - [Due Diligence Statement (DDS) and Evidence Pack | EUDR: What to Collect, Store, and Prove](/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence.md): EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream. - [EUDR Checklist | EU Deforestation Regulation Compliance Checklist (Scope -> DDS -> Evidence)](/artifacts/eu/deforestation-regulation/checklist.md): A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline. - [EUDR Due Diligence Statement Template | Copy/Paste DDS Structure and Evidence Checklist](/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template.md): A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data. - [EUDR vs CSDDD | What's Different, What Overlaps, and How to Build One Evidence Program](/artifacts/eu/deforestation-regulation/eudr-vs-csddd.md): EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions. - [FAQ | EUDR Explained: Scope, Roles, DDS Reference Numbers, Geolocation, Risk Mitigation, Penalties](/artifacts/eu/deforestation-regulation/faq.md): EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is. - [Geolocation, Traceability, and Systems | EUDR Technical Architecture and Data Model](/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems.md): Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows. - [In-Scope Commodities and Products (Annex I) | EUDR Scope Mapping Guide](/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products.md): EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends. - [Penalties and Enforcement | EUDR Enforcement Actions, Corrective Measures, Interim Measures, Reporting](/artifacts/eu/deforestation-regulation/penalties-and-enforcement.md): How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension). - [Penalties and Fines | EUDR Penalty Framework (Article 25): Turnover-Based Fines and Other Measures](/artifacts/eu/deforestation-regulation/penalties-and-fines.md): EUDR penalties explained (Article 25): Member State penalty rules. - [Requirements | EU Deforestation Regulation (EUDR) Obligations: Due Diligence, Geolocation, Traceability, Roles](/artifacts/eu/deforestation-regulation/requirements.md): A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a. - [Risk Assessment and Mitigation | EUDR Due Diligence (Articles 10-11) Playbook](/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation.md): EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements --- --- title: "EUDR vs CSDDD" canonical_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/eudr-vs-csddd" source_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/eudr-vs-csddd" author: "Sorena AI" description: "EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions." published_at: "2026-02-22" updated_at: "2026-02-23" keywords: - "EUDR vs CSDDD" - "EUDR comparison CSDDD" - "due diligence statement vs corporate due diligence" - "EUDR geolocation vs CSDDD" - "supply chain due diligence EU" - "EUDR evidence program" - "CSDDD evidence program" - "EU compliance" - "EUDR compliance" - "CSDDD" - "due diligence" - "supply chain" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EUDR vs CSDDD EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions. *Artifact Guide* *EU* ## EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence EUDR vs CSDDD Build one supplier evidence backbone without confusing two different legal tests. Focus: practical overlap (supplier onboarding, risk, remediation) and key differences (lot-level gates, geolocation, DDS reference numbers). EUDR and CSDDD both force companies to operationalize supply chain due diligence, but they work at different levels. EUDR is product-and-lot specific and uses due diligence statements (DDS) and geolocation evidence as a gate for placing/exporting relevant products. CSDDD is an enterprise due diligence regime focused on identifying and addressing human rights and environmental impacts across operations and value chains. The best implementation strategy is to reuse one evidence backbone while keeping the legal tests and outputs distinct. ## 1) The core difference: lot-level gate vs enterprise due diligence program EUDR is operationally a 'release gate': relevant products cannot be placed/exported unless conditions are met and a DDS (or simplified declaration where applicable) exists. It is tightly tied to origin and geolocation evidence. CSDDD is a corporate due diligence system. It is not a per-shipment DDS gate; it is a management and risk system across human rights and environmental impacts. - EUDR: per product/lot/shipment evidence + DDS reference number controls - CSDDD: enterprise due diligence processes, governance, and remediation across impacts - Implementation implication: keep outputs separate (DDS packets vs due diligence reporting/artifacts) *Recommended next step* *Placement: after the comparison section* ## Use EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence EUDR vs CSDDD as a cited research workflow Research Copilot can take EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence EUDR vs CSDDD from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence EUDR vs CSDDD](/solutions/research-copilot.md): Start from EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence EUDR vs CSDDD and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence](/contact.md): Review your current process, evidence gaps, and next steps for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence EUDR vs CSDDD. ## 2) Overlap you should reuse (high leverage) Even with different legal tests, the operational overlap is significant. Reuse it to reduce cost and improve consistency. Build a shared supplier onboarding and evidence pipeline and feed different decision layers. - Supplier onboarding: data contracts, SLAs, and validation rules - Evidence storage: indexing, provenance, retention, and retrieval drills - Risk workflow: risk scoring inputs, decision governance, and corrective actions - Remediation: supplier corrective action plans and monitoring ## 3) EUDR-specific modules you cannot 'hand-wave' EUDR has specific evidence modules that require technical implementation: geolocation linked to plots/establishments and a DDS reference number workflow. Treat these as required product features in your compliance system. - SKU -> Annex I mapping and role mapping per flow - Geolocation pipeline linked to lots and suppliers (validated and retrievable) - DDS reference number gate integrated into ERP/logistics and downstream handoffs - Mixing/circumvention controls (traceability and reconciliation evidence) ## 4) A combined architecture: one evidence backbone, two decision layers The best strategy is a shared data backbone with separate decision/reporting layers. One pipeline collects and validates evidence; different outputs are generated for EUDR and for CSDDD. This prevents duplicated supplier asks and inconsistent records. - Shared: supplier portal + geolocation/evidence store + audit logs - EUDR layer: lot-level case files + DDS packet generation + reference number controls - CSDDD layer: enterprise risk registers, impact assessments, remediation tracking, and reporting artifacts - Governance: unified supplier engagement but separate legal sign-offs ## Primary sources - [Consolidated EUDR (Regulation (EU) 2023/1115) - ELI (2025-12-26)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - EUDR scope trigger and operational gate concept (relevant products must be covered by a DDS/simplified declaration). - [Corporate sustainability due diligence - Directive (EU) 2024/1760 (ELI summary page)](https://data.europa.eu/eli/dir/2024/1760/oj/eng?ref=sorena.io) - CSDDD high-level directive context used for the comparison framing. ## Related Topic Guides - [Applicability Test | EU Deforestation Regulation (EUDR): In-Scope Products, Roles, Dates](/artifacts/eu/deforestation-regulation/applicability-test.md): A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator. - [Compliance Program | EUDR Implementation Playbook: Governance, Controls, Supplier Onboarding, Evidence](/artifacts/eu/deforestation-regulation/compliance.md): Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline. - [Deadlines and Compliance Calendar | EUDR Key Dates 2024 to 2029](/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar.md): EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing. - [Deadlines, Phasing, and What to Do First | EUDR Implementation Plan (90 Days -> Go-Live)](/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first.md): A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence. - [Due Diligence Statement (DDS) and Evidence Pack | EUDR: What to Collect, Store, and Prove](/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence.md): EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream. - [EUDR Checklist | EU Deforestation Regulation Compliance Checklist (Scope -> DDS -> Evidence)](/artifacts/eu/deforestation-regulation/checklist.md): A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline. - [EUDR Due Diligence Statement Template | Copy/Paste DDS Structure and Evidence Checklist](/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template.md): A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data. - [FAQ | EUDR Explained: Scope, Roles, DDS Reference Numbers, Geolocation, Risk Mitigation, Penalties](/artifacts/eu/deforestation-regulation/faq.md): EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is. - [Geolocation Data Requirements | EUDR: Plots of Land, Establishments, Validation, Exceptions](/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements.md): EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments). - [Geolocation, Traceability, and Systems | EUDR Technical Architecture and Data Model](/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems.md): Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows. - [In-Scope Commodities and Products (Annex I) | EUDR Scope Mapping Guide](/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products.md): EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends. - [Penalties and Enforcement | EUDR Enforcement Actions, Corrective Measures, Interim Measures, Reporting](/artifacts/eu/deforestation-regulation/penalties-and-enforcement.md): How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension). - [Penalties and Fines | EUDR Penalty Framework (Article 25): Turnover-Based Fines and Other Measures](/artifacts/eu/deforestation-regulation/penalties-and-fines.md): EUDR penalties explained (Article 25): Member State penalty rules. - [Requirements | EU Deforestation Regulation (EUDR) Obligations: Due Diligence, Geolocation, Traceability, Roles](/artifacts/eu/deforestation-regulation/requirements.md): A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a. - [Risk Assessment and Mitigation | EUDR Due Diligence (Articles 10-11) Playbook](/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation.md): EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/deforestation-regulation/eudr-vs-csddd --- --- title: "FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/faq" source_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/faq" author: "Sorena AI" description: "EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is." published_at: "2026-02-22" updated_at: "2026-02-23" keywords: - "EUDR FAQ" - "EU Deforestation Regulation explained" - "EUDR in scope products Annex I" - "operator downstream operator trader EUDR" - "due diligence statement reference number EUDR" - "EUDR geolocation requirements" - "EUDR risk mitigation" - "EUDR penalties 4% turnover" - "EU compliance" - "EUDR compliance" - "FAQ" - "due diligence statement" - "geolocation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FAQ EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is. *Artifact Guide* *EU* ## EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence FAQ Fast answers to the questions that block implementation. Focus: scope, roles, DDS operations, geolocation evidence, risk controls, enforcement, and penalties. This FAQ focuses on the operational questions that delay EUDR readiness: how to scope Annex I products, how to map roles and responsibilities, how to implement DDS reference number gates, what geolocation and legality evidence to collect, how to run risk assessment and mitigation, and what enforcement and penalties can look like. ## When does EUDR apply? EUDR has a main application date and a later application date for certain natural persons and micro or small undertakings established by 31 December 2024. Teams should plan data readiness and supplier onboarding well before the legal application date that matches their flow. - Main application date: 30 December 2026 for large and medium operators and traders - Later application date: 30 June 2027 for certain natural persons and micro or small undertakings established by 31 December 2024 - If the flow involves timber products already covered by the EU Timber Regulation, check the Article 38 exception because some micro and small operators still move to 30 December 2026 - Dependencies such as the information system and benchmarking affect rollout, but they do not replace the legal application date ## How do I know if my products are in scope? EUDR scope is anchored in Annex I (relevant commodities and derived products). Build a SKU -> Annex I mapping table and integrate it into product master data so scoping is repeatable and auditable. - Map every SKU (and derived product) to Annex I status with rationale - Handle composites and blends explicitly and track mixing/circumvention risk - Treat scope mapping as master data with ownership and change control ## What is the difference between operator, downstream operator, and trader? EUDR uses role definitions to allocate obligations. The most important operational difference is where due diligence and DDS submission responsibilities sit. - Operator: places relevant products on the market or exports them (excluding downstream operators) - Downstream operator: places on the market or exports products made using relevant products already covered by a DDS or simplified declaration - Trader: makes relevant products available on the market and is not an operator or downstream operator ## What is a due diligence statement and why is it a shipping gate? A DDS is the formal mechanism by which operators take responsibility for compliance for relevant products they intend to place on the market or export. Operators must not place or export without prior submission of a DDS, unless the Regulation gives them access to the simplified declaration route. In practice: no DDS reference number, no ship. - Design a release gate in ERP/logistics that requires a valid reference number - Store reference numbers at lot/shipment level and propagate downstream - Retain DDS references, declaration identifiers where relevant, and the linked evidence pack for years ## What evidence do we need to collect (including geolocation)? EUDR due diligence includes information collection (Article 9), risk assessment (Article 10), and mitigation (Article 11). Information collection includes geolocation of plots/establishments and documentation demonstrating deforestation-free and legal production. Treat evidence as structured, queryable data linked to lots. - Geolocation dataset linked to suppliers and lots, with provenance and validations - Legality evidence appropriate to the country of production - Deforestation-free evidence and verification outcomes - Traceability linkage from inputs to outputs ## What happens if risk is not negligible? If risk assessment does not reveal no/only negligible risk, you must adopt risk mitigation measures before placing/exporting. Mitigation must be measurable and documented, with reassessment outcomes. Build a mitigation menu teams can execute (supplier corrective actions, enhanced verification, segregation, monitoring). - Define mitigation actions and evidence requirements per action - Escalate: block placement/export until mitigation evidence is complete - Keep a case file: inputs, decision, mitigation tasks, reassessment outcome ## What can enforcement actions and penalties look like? The Regulation provides for interim measures and corrective actions in cases of detected non-compliance, and it requires Member States to establish penalty rules. Penalties must be effective, proportionate, and dissuasive and can include turnover-based fines for legal persons. Treat enforcement readiness as evidence readiness: time-to-evidence matters. - Expect shipment holds and corrective action requirements if non-compliance is detected - Penalties can include fines and other measures; for legal persons, maximum fines must be at least 4% of total annual Union-wide turnover (as specified in the Regulation's penalties framework) - Run evidence retrieval drills and maintain a corrective action playbook *Recommended next step* *Placement: after the FAQ section* ## Use EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence FAQ as a cited research workflow Research Copilot can take EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence FAQ](/solutions/research-copilot.md): Start from EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence](/contact.md): Review your current process, evidence gaps, and next steps for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence FAQ. ## Primary sources - [Consolidated EUDR (Regulation (EU) 2023/1115) - ELI (2025-12-26)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Application dates (Article 38 context), enforcement measures, and penalties framework (Article 25) including turnover-based fines. - [EUDR key definitions and obligations (extracts) - Eur-Lex (ELI)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Role definitions (Article 2) and due diligence structure (Articles 8-11), including geolocation and evidence collection (Article 9). ## Related Topic Guides - [Applicability Test | EU Deforestation Regulation (EUDR): In-Scope Products, Roles, Dates](/artifacts/eu/deforestation-regulation/applicability-test.md): A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator. - [Compliance Program | EUDR Implementation Playbook: Governance, Controls, Supplier Onboarding, Evidence](/artifacts/eu/deforestation-regulation/compliance.md): Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline. - [Deadlines and Compliance Calendar | EUDR Key Dates 2024 to 2029](/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar.md): EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing. - [Deadlines, Phasing, and What to Do First | EUDR Implementation Plan (90 Days -> Go-Live)](/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first.md): A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence. - [Due Diligence Statement (DDS) and Evidence Pack | EUDR: What to Collect, Store, and Prove](/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence.md): EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream. - [EUDR Checklist | EU Deforestation Regulation Compliance Checklist (Scope -> DDS -> Evidence)](/artifacts/eu/deforestation-regulation/checklist.md): A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline. - [EUDR Due Diligence Statement Template | Copy/Paste DDS Structure and Evidence Checklist](/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template.md): A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data. - [EUDR vs CSDDD | What's Different, What Overlaps, and How to Build One Evidence Program](/artifacts/eu/deforestation-regulation/eudr-vs-csddd.md): EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions. - [Geolocation Data Requirements | EUDR: Plots of Land, Establishments, Validation, Exceptions](/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements.md): EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments). - [Geolocation, Traceability, and Systems | EUDR Technical Architecture and Data Model](/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems.md): Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows. - [In-Scope Commodities and Products (Annex I) | EUDR Scope Mapping Guide](/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products.md): EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends. - [Penalties and Enforcement | EUDR Enforcement Actions, Corrective Measures, Interim Measures, Reporting](/artifacts/eu/deforestation-regulation/penalties-and-enforcement.md): How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension). - [Penalties and Fines | EUDR Penalty Framework (Article 25): Turnover-Based Fines and Other Measures](/artifacts/eu/deforestation-regulation/penalties-and-fines.md): EUDR penalties explained (Article 25): Member State penalty rules. - [Requirements | EU Deforestation Regulation (EUDR) Obligations: Due Diligence, Geolocation, Traceability, Roles](/artifacts/eu/deforestation-regulation/requirements.md): A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a. - [Risk Assessment and Mitigation | EUDR Due Diligence (Articles 10-11) Playbook](/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation.md): EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/deforestation-regulation/faq --- --- title: "Geolocation, Traceability, and Systems" canonical_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems" source_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems" author: "Sorena AI" description: "Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows." published_at: "2026-02-22" updated_at: "2026-02-23" keywords: - "EUDR traceability system" - "EUDR geolocation pipeline" - "EUDR data model" - "EUDR chain of custody" - "segregation vs mass balance EUDR" - "EUDR evidence storage" - "DDS reference number ERP integration" - "EUDR supplier onboarding system" - "EU compliance" - "EUDR compliance" - "traceability" - "geolocation" - "systems" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Geolocation, Traceability, and Systems Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows. *Artifact Guide* *EU* ## EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Systems and Data Model A technical blueprint for EUDR data readiness: geolocation, traceability, evidence, and DDS operations. Focus: making due diligence evidence auditable and reference numbers operational in real business systems. EUDR compliance is constrained by what your systems can prove. You need (1) geolocation data linked to production plots/establishments, (2) traceability from input commodity to finished goods, (3) an evidence store that is queryable by lot and supplier, and (4) a DDS reference number workflow that acts as a release gate. This page outlines a pragmatic technical architecture you can implement without boiling the ocean. ## 1) Data domains you must support (minimum viable EUDR data model) Design around four data domains: scope mapping, origin/geolocation, traceability, and due diligence evidence + decisions. Build each domain as structured data with IDs and linkage keys, not as unindexed PDFs. - Scope mapping: SKU -> Annex I mapping + role mapping per flow - Origin/geolocation: plot/establishment IDs + geolocation data + provenance - Traceability: lot/batch identifiers linking inputs -> transformation -> outputs - Evidence and decisions: documents, risk assessment outcomes, mitigation actions, approvals *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Systems and Data Model in one governed evidence system SSOT can take EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Systems and Data Model from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Systems and Data Model](/solutions/ssot.md): Start from EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Systems and Data Model and keep documents, evidence, and control records in one governed system. - [Talk through EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence](/contact.md): Review your current process, evidence gaps, and next steps for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Systems and Data Model. ## 2) Chain-of-custody patterns (segregation vs mass balance) and mixing controls Mixing and circumvention risk is where audits fail. Pick a chain-of-custody model that matches your operations and document the controls that prevent non-compliant mixing. Even if you use mass balance, you need deterministic linkage and reconciliation. - Segregation: strongest defensibility; higher operational cost; simpler audits - Mass balance: lower operational cost; requires strong reconciliation and provenance controls - Mixing controls: lot integrity checks, warehouse controls, and exception workflows - Transformation mapping: bill-of-materials links from input lots to output lots ## 3) Supplier onboarding as a data contract Treat supplier onboarding like integrating an API: define required fields, validation rules, and submission cadence. Your supplier portal (or integration channel) should enforce validation before accepting submissions. - Required fields: origin, geolocation data, legality/deforestation-free evidence references - Validation: format checks, completeness, and mismatch detection vs purchase orders/shipments - Update rules: how corrections are handled and how downstream DDS packets are updated - Contractual leverage: make data submission a contractual deliverable with SLAs ## 4) DDS reference numbers and declaration identifiers in operational systems DDS reference numbers and, where Article 4a applies, declaration identifiers must be stored and communicated downstream. This is not optional if you want a reliable compliance posture. Design it as an ERP/logistics field with strict validation, not as an attachment. - Storage: lot, shipment, and invoice records include DDS reference number or declaration identifier fields - Validation: release blocked if reference number missing/invalid for relevant products - Propagation: structured handoff to downstream recipients (EDI/API fields) - Retention: keep references and the linked evidence pack retrievable for years ## 5) Evidence store and audit retrieval (make 'prove it' cheap) If retrieval is slow, you will fail under scrutiny. Build an evidence store with indexing and immutable logs so you can assemble an evidence pack quickly per lot. Automate snapshots and exports for audits and competent authority requests. - Indexing: by lot, supplier, production site, origin, and product category - Evidence integrity: checksums, immutable logs, and access control - Case file exports: one-click evidence pack generation per shipment/lot - Drills: simulate authority requests and measure time-to-evidence ## Primary sources - [EUDR key definitions and obligations (extracts) - Eur-Lex (ELI)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Due diligence structure in Articles 8 to 11, evidence collection including geolocation in Article 9, and identifier handling for due diligence statements and simplified declarations. - [Commission Implementing Regulation (EU) 2024/3084 (EUDR information system) - CELEX](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R3084&ref=sorena.io) - Information system context and operational workflow for DDS submission and management. ## Related Topic Guides - [Applicability Test | EU Deforestation Regulation (EUDR): In-Scope Products, Roles, Dates](/artifacts/eu/deforestation-regulation/applicability-test.md): A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator. - [Compliance Program | EUDR Implementation Playbook: Governance, Controls, Supplier Onboarding, Evidence](/artifacts/eu/deforestation-regulation/compliance.md): Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline. - [Deadlines and Compliance Calendar | EUDR Key Dates 2024 to 2029](/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar.md): EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing. - [Deadlines, Phasing, and What to Do First | EUDR Implementation Plan (90 Days -> Go-Live)](/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first.md): A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence. - [Due Diligence Statement (DDS) and Evidence Pack | EUDR: What to Collect, Store, and Prove](/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence.md): EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream. - [EUDR Checklist | EU Deforestation Regulation Compliance Checklist (Scope -> DDS -> Evidence)](/artifacts/eu/deforestation-regulation/checklist.md): A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline. - [EUDR Due Diligence Statement Template | Copy/Paste DDS Structure and Evidence Checklist](/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template.md): A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data. - [EUDR vs CSDDD | What's Different, What Overlaps, and How to Build One Evidence Program](/artifacts/eu/deforestation-regulation/eudr-vs-csddd.md): EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions. - [FAQ | EUDR Explained: Scope, Roles, DDS Reference Numbers, Geolocation, Risk Mitigation, Penalties](/artifacts/eu/deforestation-regulation/faq.md): EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is. - [Geolocation Data Requirements | EUDR: Plots of Land, Establishments, Validation, Exceptions](/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements.md): EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments). - [In-Scope Commodities and Products (Annex I) | EUDR Scope Mapping Guide](/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products.md): EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends. - [Penalties and Enforcement | EUDR Enforcement Actions, Corrective Measures, Interim Measures, Reporting](/artifacts/eu/deforestation-regulation/penalties-and-enforcement.md): How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension). - [Penalties and Fines | EUDR Penalty Framework (Article 25): Turnover-Based Fines and Other Measures](/artifacts/eu/deforestation-regulation/penalties-and-fines.md): EUDR penalties explained (Article 25): Member State penalty rules. - [Requirements | EU Deforestation Regulation (EUDR) Obligations: Due Diligence, Geolocation, Traceability, Roles](/artifacts/eu/deforestation-regulation/requirements.md): A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a. - [Risk Assessment and Mitigation | EUDR Due Diligence (Articles 10-11) Playbook](/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation.md): EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems --- --- title: "In-Scope Commodities and Products (Annex I)" canonical_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products" source_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products" author: "Sorena AI" description: "EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends." published_at: "2026-02-22" updated_at: "2026-02-23" keywords: - "EUDR Annex I scope" - "EUDR in scope commodities" - "EUDR in scope products" - "relevant commodities EUDR" - "derived products Annex I EUDR" - "map SKUs to Annex I EUDR" - "EUDR scope mapping table" - "EUDR composite products" - "EU compliance" - "EUDR compliance" - "Annex I" - "scope" - "traceability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # In-Scope Commodities and Products (Annex I) EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends. *Artifact Guide* *EU* ## EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence In-Scope Commodities and Products Turn Annex I into a SKU-level scope inventory you can operate and defend. Focus: relevant commodities and derived products in Annex I, and how to map them to your catalog. EUDR scope starts and ends with Annex I. That sounds simple until you face real catalogs: composite products, blends, contract manufacturing, repacked goods, and multi-origin inputs. The goal is to build a repeatable mapping method that produces a defensible SKU -> Annex I table, stays current with catalog changes, and feeds your due diligence statement workflow. ## 1) The scope anchor: Annex I 'relevant commodities' and 'relevant products' EUDR applies to the relevant commodities and the derived products listed in Annex I. Your first task is to interpret Annex I into something your systems can use. Do not rely on memory or ad hoc judgment. Build an explicit mapping policy. - Start by listing the core commodities called out in EUDR scope discussions: cattle, cocoa, coffee, oil palm, rubber, soya, and wood (plus derived products listed in Annex I) - Treat derived products as first-class: many obligations attach at derived-product level - Always preserve a link back to Annex I and the relevant product definition for audit defensibility *Recommended next step* *Placement: after the scope or definition section* ## Use EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence In-Scope Commodities and Products as a cited research workflow Research Copilot can take EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence In-Scope Commodities and Products from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence In-Scope Commodities and Products](/solutions/research-copilot.md): Start from EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence In-Scope Commodities and Products and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence](/contact.md): Review your current process, evidence gaps, and next steps for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence In-Scope Commodities and Products. ## 2) Build the SKU -> Annex I mapping table (minimum required fields) Your mapping table is the backbone of applicability and due diligence workflows. Without it, you can't consistently decide scope, role, or evidence requirements. Make it owned, versioned, and reviewable. - SKU identifier + description + product family - Annex I mapping: commodity/product category and rationale (and reference to the Annex entry) - Supply chain path: supplier(s), country of production, and typical origin scenarios - Role per flow: operator/downstream operator/trader ownership and responsible internal owner - Risk flags: blends/mixing risk, repacking risk, multi-origin, and documentation gaps ## 3) Composite products and blends: decide scope and control mixing risk Composite goods and multi-origin blends are where scope and risk meet. Even if you can map scope, you must also control circumvention and mixing risks to support due diligence decisions. Define a rule: when any Annex I relevant commodity is present, what does your program require? - Define 'trigger rules' for multi-ingredient goods (e.g., any Annex I relevant commodity present triggers EUDR workflow) - Use batch/lot traceability and origin segmentation for blends where possible - Document exceptions and why they are defensible (don't rely on unwritten practice) ## 4) Operational handoff: connect scope mapping to due diligence statements Scope mapping is only useful if it feeds the due diligence statement workflow. Build the handoff so that procurement and operations can execute it. The goal: for any shipment, you can answer 'is it in scope', 'who is responsible', and 'what evidence is required'. - Add a scope flag and Annex I mapping fields into product master data - Block shipment/release without required evidence pack and (where required) due diligence statement reference number - Maintain an audit trail: mapping decisions, changes, and approvals ## Primary sources - [Consolidated EUDR (Regulation (EU) 2023/1115) - ELI (2025-12-26)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Annex I scope and the Article 3 trigger that relevant products must not be placed/made available/exported unless conditions are met. - [European Commission - EUDR overview page](https://environment.ec.europa.eu/topics/forests/deforestation/regulation-deforestation-free-products_en?ref=sorena.io) - High-level overview and practical context for commodities/products in scope. ## Related Topic Guides - [Applicability Test | EU Deforestation Regulation (EUDR): In-Scope Products, Roles, Dates](/artifacts/eu/deforestation-regulation/applicability-test.md): A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator. - [Compliance Program | EUDR Implementation Playbook: Governance, Controls, Supplier Onboarding, Evidence](/artifacts/eu/deforestation-regulation/compliance.md): Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline. - [Deadlines and Compliance Calendar | EUDR Key Dates 2024 to 2029](/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar.md): EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing. - [Deadlines, Phasing, and What to Do First | EUDR Implementation Plan (90 Days -> Go-Live)](/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first.md): A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence. - [Due Diligence Statement (DDS) and Evidence Pack | EUDR: What to Collect, Store, and Prove](/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence.md): EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream. - [EUDR Checklist | EU Deforestation Regulation Compliance Checklist (Scope -> DDS -> Evidence)](/artifacts/eu/deforestation-regulation/checklist.md): A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline. - [EUDR Due Diligence Statement Template | Copy/Paste DDS Structure and Evidence Checklist](/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template.md): A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data. - [EUDR vs CSDDD | What's Different, What Overlaps, and How to Build One Evidence Program](/artifacts/eu/deforestation-regulation/eudr-vs-csddd.md): EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions. - [FAQ | EUDR Explained: Scope, Roles, DDS Reference Numbers, Geolocation, Risk Mitigation, Penalties](/artifacts/eu/deforestation-regulation/faq.md): EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is. - [Geolocation Data Requirements | EUDR: Plots of Land, Establishments, Validation, Exceptions](/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements.md): EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments). - [Geolocation, Traceability, and Systems | EUDR Technical Architecture and Data Model](/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems.md): Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows. - [Penalties and Enforcement | EUDR Enforcement Actions, Corrective Measures, Interim Measures, Reporting](/artifacts/eu/deforestation-regulation/penalties-and-enforcement.md): How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension). - [Penalties and Fines | EUDR Penalty Framework (Article 25): Turnover-Based Fines and Other Measures](/artifacts/eu/deforestation-regulation/penalties-and-fines.md): EUDR penalties explained (Article 25): Member State penalty rules. - [Requirements | EU Deforestation Regulation (EUDR) Obligations: Due Diligence, Geolocation, Traceability, Roles](/artifacts/eu/deforestation-regulation/requirements.md): A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a. - [Risk Assessment and Mitigation | EUDR Due Diligence (Articles 10-11) Playbook](/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation.md): EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products --- --- title: "Penalties and Enforcement" canonical_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/penalties-and-enforcement" source_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/penalties-and-enforcement" author: "Sorena AI" description: "How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension)." published_at: "2026-02-22" updated_at: "2026-02-23" keywords: - "EUDR enforcement" - "EUDR corrective action" - "EUDR interim measures seizure suspension" - "EUDR competent authority checks" - "EUDR penalties framework Article 25" - "EUDR enforcement readiness checklist" - "EUDR evidence pack audit" - "EU compliance" - "EUDR compliance" - "enforcement" - "corrective action" - "penalties" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Penalties and Enforcement How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension). *Artifact Guide* *EU* ## EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Penalties and Enforcement Be ready for checks: fast evidence retrieval, corrective action, and shipment holds. Focus: interim measures, corrective action workflows, annual reporting/oversight signals, and penalty exposure reduction. EUDR enforcement risk is operational risk: can you stop non-compliant goods, prove due diligence, and remediate quickly? The Regulation provides for interim measures (including seizure or suspension) when potential non-compliance is detected, and corrective actions when non-compliance is established. Member States must also implement a penalties regime. This page turns that into an enforcement readiness playbook. ## 1) Enforcement mindset: treat evidence retrieval as a production capability If you need days to assemble evidence, you are not ready. Enforcement scenarios compress timelines: you may need to prove lot-level compliance quickly. Design your program so evidence is generated by the workflow (scope mapping, geolocation, risk case files, DDS reference numbers). - Evidence is indexed by lot/shipment and retrievable in hours - DDS reference number gate is enforceable (no reference number -> no ship) - Corrective action playbook exists and is testable *Recommended next step* *Placement: after the enforcement section* ## Use EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Penalties and Enforcement as a cited research workflow Research Copilot can take EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Penalties and Enforcement from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Penalties and Enforcement](/solutions/research-copilot.md): Start from EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Penalties and Enforcement and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence](/contact.md): Review your current process, evidence gaps, and next steps for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Penalties and Enforcement. ## 2) Interim measures: how to operationalize shipment holds The Regulation foresees the possibility for competent authorities to take immediate interim measures when potential non-compliance is detected, including seizure of products or suspension of placing/making available/export. Your internal controls must mirror that: you need the ability to freeze lots, stop shipments, and notify stakeholders. - Lot quarantine capability in ERP/WMS (block picking and release) - Customer and supplier communication templates for holds - Escalation tree: who can stop release, who approves restart, who manages authority engagement ## 3) Corrective actions: what you must be ready to do when non-compliance is established When non-compliance is established, competent authorities can require appropriate and proportionate corrective actions to bring non-compliance to an end within set timelines. Operationally: you need a corrective action workflow tied to suppliers, lots, and the evidence pack. - Root cause analysis: scope mapping failure, evidence gap, mixing event, or supplier misrepresentation - Corrective actions: supplier corrective plans, enhanced verification, segregation upgrades, product withdrawal - Reassessment and closure memo: what changed, what evidence now exists, and why risk is negligible ## 4) Reporting and oversight signals: be ready to justify your controls The Regulation includes annual reporting/oversight expectations that create transparency on checks and outcomes. Expect your program to be evaluated relative to peers. Use this as motivation to build measurable controls and metrics. - Maintain internal metrics: number of in-scope lots, evidence completeness, exception backlog, time-to-evidence - Keep records of checks and internal audits and their outcomes - Document the risk criteria used in your internal plan of checks and mitigation strategy ## Enforcement readiness checklist (minimum viable) This is the minimum enforcement readiness pack: if you can produce these artifacts and execute these actions, you can respond effectively to scrutiny. Run drills quarterly to ensure it stays real. - Evidence pack export per lot/shipment (geolocation, legality, deforestation-free evidence, risk decision) - DDS reference number storage and downstream propagation proof - Interim measures playbook: quarantine, suspension, seizure-response procedures - Corrective action workflow: tasks, owners, deadlines, and closure evidence - Penalties awareness model: financial exposure, reputational impact, and escalation triggers ## Primary sources - [Consolidated EUDR (Regulation (EU) 2023/1115) - ELI (2025-12-26)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Enforcement framework including interim measures and corrective action concepts, plus the penalties framework that Member States must implement. ## Related Topic Guides - [Applicability Test | EU Deforestation Regulation (EUDR): In-Scope Products, Roles, Dates](/artifacts/eu/deforestation-regulation/applicability-test.md): A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator. - [Compliance Program | EUDR Implementation Playbook: Governance, Controls, Supplier Onboarding, Evidence](/artifacts/eu/deforestation-regulation/compliance.md): Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline. - [Deadlines and Compliance Calendar | EUDR Key Dates 2024 to 2029](/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar.md): EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing. - [Deadlines, Phasing, and What to Do First | EUDR Implementation Plan (90 Days -> Go-Live)](/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first.md): A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence. - [Due Diligence Statement (DDS) and Evidence Pack | EUDR: What to Collect, Store, and Prove](/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence.md): EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream. - [EUDR Checklist | EU Deforestation Regulation Compliance Checklist (Scope -> DDS -> Evidence)](/artifacts/eu/deforestation-regulation/checklist.md): A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline. - [EUDR Due Diligence Statement Template | Copy/Paste DDS Structure and Evidence Checklist](/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template.md): A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data. - [EUDR vs CSDDD | What's Different, What Overlaps, and How to Build One Evidence Program](/artifacts/eu/deforestation-regulation/eudr-vs-csddd.md): EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions. - [FAQ | EUDR Explained: Scope, Roles, DDS Reference Numbers, Geolocation, Risk Mitigation, Penalties](/artifacts/eu/deforestation-regulation/faq.md): EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is. - [Geolocation Data Requirements | EUDR: Plots of Land, Establishments, Validation, Exceptions](/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements.md): EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments). - [Geolocation, Traceability, and Systems | EUDR Technical Architecture and Data Model](/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems.md): Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows. - [In-Scope Commodities and Products (Annex I) | EUDR Scope Mapping Guide](/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products.md): EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends. - [Penalties and Fines | EUDR Penalty Framework (Article 25): Turnover-Based Fines and Other Measures](/artifacts/eu/deforestation-regulation/penalties-and-fines.md): EUDR penalties explained (Article 25): Member State penalty rules. - [Requirements | EU Deforestation Regulation (EUDR) Obligations: Due Diligence, Geolocation, Traceability, Roles](/artifacts/eu/deforestation-regulation/requirements.md): A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a. - [Risk Assessment and Mitigation | EUDR Due Diligence (Articles 10-11) Playbook](/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation.md): EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/deforestation-regulation/penalties-and-enforcement --- --- title: "Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/penalties-and-fines" author: "Sorena AI" description: "EUDR penalties explained (Article 25): Member State penalty rules." published_at: "2026-02-22" updated_at: "2026-02-23" keywords: - "EUDR penalties" - "EUDR fines" - "EUDR Article 25 penalties" - "EUDR 4% turnover fine" - "EUDR confiscation of products" - "EUDR exclusion from public procurement" - "EUDR publication of judgments" - "EUDR penalty risk reduction" - "EU compliance" - "EUDR compliance" - "penalties" - "fines" - "Article 25" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Penalties and Fines EUDR penalties explained (Article 25): Member State penalty rules. *Artifact Guide* *EU* ## EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Penalties and Fines Understand the penalty framework and build evidence that reduces exposure. Focus: Article 25 penalties (turnover-based fines, confiscation, exclusion) and what to implement to reduce risk. EUDR penalties are not soft. Article 25 requires Member States to lay down penalty rules and says those penalties must be effective, proportionate, and dissuasive. The Regulation also specifies a menu of penalty types, including turnover-based fines for legal persons and confiscation and exclusion measures. The practical takeaway is simple: penalty risk falls when you run an evidence-first program with solid scope mapping, geolocation controls, traceability controls, and auditable risk decisions. ## 1) The baseline: Member States must implement penalties (Article 25(1)-(2)) Member States must lay down rules on penalties applicable to infringements and ensure they are implemented. They must notify the Commission of those rules and measures and updates to them. Expect variation across Member States in procedures and enforcement intensity, but the minimum penalty types are anchored in the Regulation. - Maintain an enforcement tracker for your main markets (competent authority contacts and local penalty implementation) - Treat cross-border flows as higher risk: multiple authorities may be involved - Avoid 'paper compliance': penalties are designed to remove economic benefit from infringements *Recommended next step* *Placement: after the enforcement section* ## Use EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Penalties and Fines as a cited research workflow Research Copilot can take EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Penalties and Fines](/solutions/research-copilot.md): Start from EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence](/contact.md): Review your current process, evidence gaps, and next steps for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Penalties and Fines. ## 2) Fines: turnover-based maximums for legal persons (Article 25(2)(a)) Article 25 requires fines that are proportionate to environmental damage and the value of the goods and that deprive offenders of economic benefits, increasing for repeated infringements. For legal persons, the Regulation specifies that the maximum amount of such a fine must be at least 4% of total annual Union-wide turnover in the preceding financial year, and higher where necessary to exceed the potential economic benefit gained. - Model exposure: 4% Union-wide turnover is a board-level number - Design controls to prevent 'systematic' failures (scope mapping gaps, missing geolocation, weak mixing controls) - Keep remediation evidence: mitigation actions reduce duration and scale of infringement ## 3) Other penalties: confiscation, exclusion, publication of judgments The Regulation's penalty menu includes measures beyond fines. These can be operationally disruptive even without large monetary amounts. Plan for resilience: penalties can affect procurement eligibility and funding access. - Confiscation of non-compliant products - Confiscation of revenues gained from transactions with relevant products - Temporary exclusion (up to 12 months) from public procurement and access to public funding (including tendering, grants, and concessions) - Publication of judgments and penalties (reputational exposure) ## Risk-reduction checklist (controls that materially reduce penalty exposure) Penalties are designed to deter and remove economic benefit. Reduce exposure by building controls that prevent non-compliant placement/export and produce evidence automatically. Use these as your minimum controls baseline. - SKU -> Annex I mapping integrated into master data (no unknown scope) - Geolocation pipeline with validations and lot linkage (no unverifiable origin) - Mixing/circumvention controls with reconciliation evidence (no uncontrolled blends) - Risk case files: decisions, approvals, mitigation actions, reassessment outcomes - DDS reference number gate: no reference number -> no ship ## Primary sources - [Consolidated EUDR (Regulation (EU) 2023/1115) - ELI (2025-12-26)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Article 25 penalty framework for operators, downstream operators, and traders, including fines with a turnover based maximum for legal persons and other penalty types such as confiscation, exclusion, and publication of judgments. ## Related Topic Guides - [Applicability Test | EU Deforestation Regulation (EUDR): In-Scope Products, Roles, Dates](/artifacts/eu/deforestation-regulation/applicability-test.md): A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator. - [Compliance Program | EUDR Implementation Playbook: Governance, Controls, Supplier Onboarding, Evidence](/artifacts/eu/deforestation-regulation/compliance.md): Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline. - [Deadlines and Compliance Calendar | EUDR Key Dates 2024 to 2029](/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar.md): EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing. - [Deadlines, Phasing, and What to Do First | EUDR Implementation Plan (90 Days -> Go-Live)](/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first.md): A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence. - [Due Diligence Statement (DDS) and Evidence Pack | EUDR: What to Collect, Store, and Prove](/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence.md): EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream. - [EUDR Checklist | EU Deforestation Regulation Compliance Checklist (Scope -> DDS -> Evidence)](/artifacts/eu/deforestation-regulation/checklist.md): A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline. - [EUDR Due Diligence Statement Template | Copy/Paste DDS Structure and Evidence Checklist](/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template.md): A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data. - [EUDR vs CSDDD | What's Different, What Overlaps, and How to Build One Evidence Program](/artifacts/eu/deforestation-regulation/eudr-vs-csddd.md): EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions. - [FAQ | EUDR Explained: Scope, Roles, DDS Reference Numbers, Geolocation, Risk Mitigation, Penalties](/artifacts/eu/deforestation-regulation/faq.md): EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is. - [Geolocation Data Requirements | EUDR: Plots of Land, Establishments, Validation, Exceptions](/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements.md): EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments). - [Geolocation, Traceability, and Systems | EUDR Technical Architecture and Data Model](/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems.md): Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows. - [In-Scope Commodities and Products (Annex I) | EUDR Scope Mapping Guide](/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products.md): EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends. - [Penalties and Enforcement | EUDR Enforcement Actions, Corrective Measures, Interim Measures, Reporting](/artifacts/eu/deforestation-regulation/penalties-and-enforcement.md): How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension). - [Requirements | EU Deforestation Regulation (EUDR) Obligations: Due Diligence, Geolocation, Traceability, Roles](/artifacts/eu/deforestation-regulation/requirements.md): A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a. - [Risk Assessment and Mitigation | EUDR Due Diligence (Articles 10-11) Playbook](/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation.md): EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/deforestation-regulation/penalties-and-fines --- --- title: "Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/requirements" source_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/requirements" author: "Sorena AI" description: "A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a." published_at: "2026-02-22" updated_at: "2026-02-23" keywords: - "EUDR requirements" - "EU Deforestation Regulation obligations" - "Article 3 deforestation free legality due diligence statement" - "operator obligations Article 4 EUDR" - "downstream operator trader obligations Article 5 EUDR" - "due diligence system Article 8 9 10 11" - "geolocation requirements EUDR" - "EUDR information system Article 33" - "EU compliance" - "EUDR compliance" - "requirements" - "due diligence" - "geolocation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Requirements A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a. *Artifact Guide* *EU* ## EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Requirements A structured obligations map plus an evidence checklist you can execute. Use this as the backbone for your requirements doc, supplier onboarding pack, and due diligence statement workflows. EUDR compliance becomes manageable when you map obligations to roles and artifacts. The Regulation distinguishes operators, downstream operators and traders, and it organizes compliance around a due diligence system (information collection, risk assessment, risk mitigation) and a due diligence statement workflow. This page turns that into a practical requirements map and an evidence checklist. ## 1) The core gate (Article 3): no market placement/export unless three conditions are met EUDR's operational trigger is straightforward: you must not place, make available, or export relevant products unless they meet the core conditions and are covered by a due diligence statement (or simplified declaration where applicable). Treat this as a hard shipping/release control. - Deforestation-free condition: define your evidence approach and data sources - Legality condition: define what 'relevant legislation' evidence looks like for each country of production - DDS/simplified declaration condition: implement reference number controls and retention ## 2) Operator obligations (Article 4) - where the heavy lifting sits Operators must exercise due diligence before placing on the market or exporting to demonstrate compliance with Article 3, and they must not do so without prior submission of a due diligence statement unless Article 4a gives them access to the simplified declaration route. By making the due diligence statement available, or using a simplified declaration where the Regulation permits it, the operator assumes responsibility for Article 3 compliance. - Perform due diligence before placement/export (due diligence system in Articles 8-11) - Submit due diligence statement via the information system before placement/export - Retain due diligence statements and references for five years - Communicate due diligence statement reference numbers/identifiers downstream ## 3) Simplified declaration path for micro or small primary operators (Article 4a) Micro or small primary operators have a specific simplified declaration route. It is not a general shortcut for all small companies, so teams should document eligibility before using it. Where Article 4a applies, the operator receives a declaration identifier and may use the postal address simplification for Article 9(1)(d) geolocation. - Confirm the operator is established in a low risk country and fits the micro or small primary operator definition - Submit the one time simplified declaration before placing on the market or exporting - Store the declaration identifier and communicate it downstream just as carefully as a DDS reference number ## 4) Downstream operators and traders (Article 5) - traceability and information retention Downstream operators and traders must ensure they possess required information before placing/making available/exporting and must keep information for years and provide it to competent authorities on request. Non-SME downstream operators and non-SME traders have additional system registration requirements. - Collect and retain supply chain information, including supplier details and DDS reference numbers/identifiers where applicable - Retain Article 5 information for at least five years and provide it upon request - If new information indicates risk/non-compliance: inform competent authorities and downstream recipients - Non-SME downstream operators/traders: register in the information system before placing/making available/exporting ## 5) The due diligence system (Articles 8-11): information, risk assessment, mitigation EUDR due diligence has three operational steps: collect information and evidence, assess risk, and mitigate risk when it is not negligible. Design your workflow so that risk decisions are auditable and tied to evidence. - Information collection (Article 9): include evidence demonstrating deforestation-free and legal production and geolocation of plots/establishments (as applicable) - Risk assessment (Article 10): decide whether risk is no/only negligible before placing/exporting - Risk mitigation (Article 11): if risk is not negligible, implement mitigation before placing/exporting - Evidence: risk model inputs, decisions, mitigation actions, and post-mitigation reassessment ## 6) Simplified due diligence for low risk production EUDR includes simplified due diligence in low risk contexts under the benchmarking system, but teams must still control circumvention and mixing risks. This is different from the Article 4a simplified declaration route for micro or small primary operators. - Low-risk production: document why risk of circumvention/mixing remains negligible and keep evidence - Keep evidence showing why the supply chain complexity does not create circumvention or mixing risk - Even with simplified due diligence, keep your evidence pack audit ready ## 7) Evidence mapping - requirement -> artifact Most EUDR disputes are evidence disputes. Build an evidence pack that is produced by the workflow, not retrofitted later. Use this as a minimal mapping; expand per commodity and supplier risk profile. - Scope mapping -> SKU -> Annex I table + owner + change log - Operator gate -> DDS submission proof or simplified declaration record + identifier storage + retention - Geolocation -> validated plot data + provenance + batch/lot linkage - Risk assessment -> risk model inputs + decisions + approvals - Risk mitigation -> mitigation actions + supplier corrective actions + reassessment results - Downstream obligations -> reference number handoff + Article 5 information retention pack *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Requirements across ESG workflows ESG Compliance can take EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Requirements](/solutions/esg-compliance.md): Start from EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Requirements and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence](/contact.md): Review your current process, evidence gaps, and next steps for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Requirements. ## Primary sources - [EUDR key definitions and obligations (extracts) - Eur-Lex (ELI)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Definitions for operator, downstream operator, trader, and micro or small primary operator, plus Article 3 scope trigger, Article 4 and 4a submission duties, Article 5 downstream duties, and the due diligence structure in Articles 8 to 11. - [European Commission - EUDR overview page](https://environment.ec.europa.eu/topics/forests/deforestation/regulation-deforestation-free-products_en?ref=sorena.io) - High-level overview and implementation context for EUDR obligations. ## Related Topic Guides - [Applicability Test | EU Deforestation Regulation (EUDR): In-Scope Products, Roles, Dates](/artifacts/eu/deforestation-regulation/applicability-test.md): A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator. - [Compliance Program | EUDR Implementation Playbook: Governance, Controls, Supplier Onboarding, Evidence](/artifacts/eu/deforestation-regulation/compliance.md): Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline. - [Deadlines and Compliance Calendar | EUDR Key Dates 2024 to 2029](/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar.md): EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing. - [Deadlines, Phasing, and What to Do First | EUDR Implementation Plan (90 Days -> Go-Live)](/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first.md): A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence. - [Due Diligence Statement (DDS) and Evidence Pack | EUDR: What to Collect, Store, and Prove](/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence.md): EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream. - [EUDR Checklist | EU Deforestation Regulation Compliance Checklist (Scope -> DDS -> Evidence)](/artifacts/eu/deforestation-regulation/checklist.md): A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline. - [EUDR Due Diligence Statement Template | Copy/Paste DDS Structure and Evidence Checklist](/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template.md): A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data. - [EUDR vs CSDDD | What's Different, What Overlaps, and How to Build One Evidence Program](/artifacts/eu/deforestation-regulation/eudr-vs-csddd.md): EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions. - [FAQ | EUDR Explained: Scope, Roles, DDS Reference Numbers, Geolocation, Risk Mitigation, Penalties](/artifacts/eu/deforestation-regulation/faq.md): EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is. - [Geolocation Data Requirements | EUDR: Plots of Land, Establishments, Validation, Exceptions](/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements.md): EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments). - [Geolocation, Traceability, and Systems | EUDR Technical Architecture and Data Model](/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems.md): Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows. - [In-Scope Commodities and Products (Annex I) | EUDR Scope Mapping Guide](/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products.md): EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends. - [Penalties and Enforcement | EUDR Enforcement Actions, Corrective Measures, Interim Measures, Reporting](/artifacts/eu/deforestation-regulation/penalties-and-enforcement.md): How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension). - [Penalties and Fines | EUDR Penalty Framework (Article 25): Turnover-Based Fines and Other Measures](/artifacts/eu/deforestation-regulation/penalties-and-fines.md): EUDR penalties explained (Article 25): Member State penalty rules. - [Risk Assessment and Mitigation | EUDR Due Diligence (Articles 10-11) Playbook](/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation.md): EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/deforestation-regulation/requirements --- --- title: "Risk Assessment and Mitigation" canonical_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation" source_url: "https://www.sorena.io/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation" author: "Sorena AI" description: "EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier." published_at: "2026-02-22" updated_at: "2026-02-23" keywords: - "EUDR risk assessment" - "EUDR risk mitigation" - "EUDR Article 10 risk assessment" - "EUDR Article 11 mitigation measures" - "negligible risk EUDR" - "EUDR supplier risk scoring" - "EUDR mixing circumvention risk" - "EUDR due diligence playbook" - "EU compliance" - "EUDR compliance" - "risk assessment" - "risk mitigation" - "due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Risk Assessment and Mitigation EUDR due diligence risk assessment and mitigation made practical: how to structure Articles 10-11 decisions, what inputs to use (origin, supplier. *Artifact Guide* *EU* ## EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Risk Assessment and Mitigation A repeatable way to reach (and prove) 'no or only negligible risk'. Focus: due diligence risk assessment (Article 10) and mitigation actions (Article 11). EUDR due diligence is not complete after you collect documents. You must assess risk and, where risk is not negligible, mitigate it before placing products on the market or exporting. The practical challenge is consistency: teams need a repeatable decision process with auditable inputs, approvals, and evidence so that 'negligible risk' is a defensible conclusion, not an assumption. ## 1) The decision rule: you must reach 'no or only negligible risk' before placement/export EUDR due diligence requires a risk assessment step and a clear decision outcome. Operators should not place on the market or export unless the assessment reveals no or only negligible risk of non-compliance. Design this as a gate with required fields and approvals, not an informal judgment call. - Define risk outcomes (negligible vs not negligible) and what evidence supports each - Assign decision authority (who can approve a negligible risk outcome) - Keep a decision record tied to lots, suppliers, and geolocation evidence *Recommended next step* *Placement: after the main workflow section* ## Operationalize EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Risk Assessment and Mitigation across ESG workflows ESG Compliance can take EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Risk Assessment and Mitigation from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Risk Assessment and Mitigation](/solutions/esg-compliance.md): Start from EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Risk Assessment and Mitigation and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence](/contact.md): Review your current process, evidence gaps, and next steps for EU Deforestation Regulation (EUDR): Deforestation-Free Products and Due Diligence Risk Assessment and Mitigation. ## 2) Risk inputs (what to score and why) A practical risk model focuses on a few high-signal variables: origin risk, supplier risk, evidence quality, and mixing/circumvention risk. Benchmarking (low/high-risk classification) is an important input, but it is not the only input. - Origin risk: country/region classification, recent changes, and known enforcement weaknesses - Supplier risk: history, transparency, auditability, and corrective action responsiveness - Evidence quality: completeness, provenance, inconsistencies, and unverifiable documents - Mixing/circumvention risk: bulk handling, multi-origin blends, repacking, and transformations - Operational complexity: number of intermediaries and data handoffs ## 3) Mitigation actions (when risk is not negligible) When risk is not negligible, you must adopt risk mitigation measures before placing/exporting. The best mitigation actions are measurable and time-bound. Build a mitigation menu your teams can execute across commodities and supplier types. - Supplier corrective actions with deadlines and evidence requirements - Enhanced verification: additional documents, independent checks, or targeted audits - Segregation upgrades: move from mass balance to segregation for high-risk flows - Monitoring: increased sampling, anomaly detection, and origin change controls - Escalation: block placement/export until mitigation evidence is complete ## 4) Case file structure (what to store so it's auditable) Treat each risk decision as a case file linked to lots/shipments. This makes audits and authority requests cheaper and faster. Your case file should be reproducible: the same inputs should lead to the same decision. - Inputs: scope mapping, origin/geolocation evidence, supplier documents - Risk assessment: scoring factors, rationale, and approval - Mitigation actions (if any): tasks, evidence, and reassessment outcome - Outputs: DDS packet readiness and reference number storage fields ## Evidence checklist (minimum viable) If you can't produce these artifacts, your risk decisions are hard to defend. Automate generation where possible (logs, snapshots, and exports). - Risk model and documented scoring criteria - Lot-level decision records and approvals - Mitigation actions and evidence produced - Traceability and mixing controls evidence - Reassessment outcomes and release gate logs ## Primary sources - [EUDR key definitions and obligations (extracts) - Eur-Lex (ELI)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Due diligence structure: information collection (Article 9), risk assessment (Article 10), and risk mitigation (Article 11). - [Consolidated EUDR (Regulation (EU) 2023/1115) - ELI (2025-12-26)](https://eur-lex.europa.eu/eli/reg/2023/1115/2025-12-26/eng?ref=sorena.io) - Benchmarking system timing context and broader risk framing in the consolidated text. ## Related Topic Guides - [Applicability Test | EU Deforestation Regulation (EUDR): In-Scope Products, Roles, Dates](/artifacts/eu/deforestation-regulation/applicability-test.md): A 15-minute EUDR applicability test: confirm whether your commodities or products are in Annex I, determine if you are an operator, downstream operator. - [Compliance Program | EUDR Implementation Playbook: Governance, Controls, Supplier Onboarding, Evidence](/artifacts/eu/deforestation-regulation/compliance.md): Turn EUDR into an execution program: governance and ownership, SKU -> Annex I scope mapping, supplier onboarding data contracts, geolocation pipeline. - [Deadlines and Compliance Calendar | EUDR Key Dates 2024 to 2029](/artifacts/eu/deforestation-regulation/deadlines-and-compliance-calendar.md): EUDR deadline tracker with actionable milestones: information system readiness under Article 33, Commission benchmarking timing. - [Deadlines, Phasing, and What to Do First | EUDR Implementation Plan (90 Days -> Go-Live)](/artifacts/eu/deforestation-regulation/deadlines-phasing-and-what-to-do-first.md): A practical EUDR phasing guide: what to do first, what to build next, and how to sequence scope mapping, geolocation data collection, supplier evidence. - [Due Diligence Statement (DDS) and Evidence Pack | EUDR: What to Collect, Store, and Prove](/artifacts/eu/deforestation-regulation/due-diligence-statement-and-evidence.md): EUDR due diligence statements made practical: what a DDS is, when a simplified declaration applies, who submits it, how reference numbers flow downstream. - [EUDR Checklist | EU Deforestation Regulation Compliance Checklist (Scope -> DDS -> Evidence)](/artifacts/eu/deforestation-regulation/checklist.md): A practical EUDR checklist organized by workstream: scope mapping (Annex I), role mapping (operator/downstream operator/trader), geolocation pipeline. - [EUDR Due Diligence Statement Template | Copy/Paste DDS Structure and Evidence Checklist](/artifacts/eu/deforestation-regulation/eudr-due-diligence-statement-template.md): A practical EUDR due diligence statement (DDS) template outline: the fields and annexes you should prepare (product identification, supplier and origin data. - [EUDR vs CSDDD | What's Different, What Overlaps, and How to Build One Evidence Program](/artifacts/eu/deforestation-regulation/eudr-vs-csddd.md): EUDR vs CSDDD made practical: EUDR is product-and-lot specific with DDS reference numbers, geolocation, and deforestation-free/legality conditions. - [FAQ | EUDR Explained: Scope, Roles, DDS Reference Numbers, Geolocation, Risk Mitigation, Penalties](/artifacts/eu/deforestation-regulation/faq.md): EUDR FAQ with practical answers: what is in scope (Annex I), operator vs downstream operator vs trader, what a due diligence statement (DDS) is. - [Geolocation Data Requirements | EUDR: Plots of Land, Establishments, Validation, Exceptions](/artifacts/eu/deforestation-regulation/eudr-geolocation-data-requirements.md): EUDR geolocation requirements made practical: what geolocation data to collect (plots/establishments). - [Geolocation, Traceability, and Systems | EUDR Technical Architecture and Data Model](/artifacts/eu/deforestation-regulation/geolocation-traceability-and-systems.md): Build EUDR ready systems: geolocation pipeline, batch and lot traceability, evidence storage, and risk control workflows. - [In-Scope Commodities and Products (Annex I) | EUDR Scope Mapping Guide](/artifacts/eu/deforestation-regulation/in-scope-commodities-and-products.md): EUDR scope mapping guide for Annex I commodities and derived products: how to map SKUs to relevant commodities/products, handle composite goods and blends. - [Penalties and Enforcement | EUDR Enforcement Actions, Corrective Measures, Interim Measures, Reporting](/artifacts/eu/deforestation-regulation/penalties-and-enforcement.md): How EUDR enforcement works in practice: competent authority checks, interim measures (including seizure/suspension). - [Penalties and Fines | EUDR Penalty Framework (Article 25): Turnover-Based Fines and Other Measures](/artifacts/eu/deforestation-regulation/penalties-and-fines.md): EUDR penalties explained (Article 25): Member State penalty rules. - [Requirements | EU Deforestation Regulation (EUDR) Obligations: Due Diligence, Geolocation, Traceability, Roles](/artifacts/eu/deforestation-regulation/requirements.md): A structured EUDR requirements map: Article 3 core conditions, operator obligations in Article 4, simplified declaration rules in Article 4a. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/deforestation-regulation/risk-assessment-and-mitigation --- --- title: "DMA Applicability Test (Gatekeeper Scoping)" canonical_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/applicability-test" author: "Sorena AI" description: "A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "DMA applicability test" - "Digital Markets Act applicability" - "DMA gatekeeper designation" - "core platform service CPS" - "DMA thresholds 45 million" - "DMA thresholds 10" - "000 business users" - "DMA notification to Commission" - "DMA 45 working days designation" - "EU Digital Markets Act compliance" - "Digital Markets Act" - "gatekeeper designation" - "core platform services" - "EU platform regulation" - "DMA thresholds" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DMA Applicability Test (Gatekeeper Scoping) A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds. *Artifact Guide* *EU* ## EU Digital Markets Act (DMA) Applicability Test Scope core platform services (CPS), assess gatekeeper designation likelihood, and identify your first DMA workstreams. Grounded in Regulation (EU) 2022/1925: CPS definitions, gatekeeper thresholds, notification/designation timing, and the 6-month compliance clock. This DMA applicability test helps product, legal, compliance, and policy teams answer one question fast: are we (or a partner platform) likely to be a DMA gatekeeper for one or more core platform services in the EU, and if yes, what deadlines and obligations start to matter immediately? As of 6 March 2026, the Commission's public gatekeeper page lists 7 gatekeepers and 23 designated core platform services, which makes CPS-level scoping more important than company-level labels alone. ## Step 1: Are you providing a core platform service (CPS)? The DMA applies to core platform services (CPS) provided or offered by gatekeepers to business users established in the EU or end users established or located in the EU. Start by mapping your products to the CPS categories in the DMA definition. If you provide any CPS category at scale, you should treat DMA scoping as a product requirement and a compliance program. - CPS categories include: online intermediation services, online search engines, online social networking services, video-sharing platform services, number-independent interpersonal communications services, operating systems, web browsers, virtual assistants, cloud computing services, and online advertising services linked to those CPS categories. - Define CPS boundaries the way engineering ships them: user journeys, authentication, data flows, ranking and recommendation systems, ads stack, and developer interfaces. - Document "CPS vs non-CPS" calls with rationale; these decisions become evidence in Commission questions, stakeholder submissions, and compliance reports. ## Step 2: Gatekeeper presumption thresholds (Article 3(2)) An undertaking is presumed to meet the gatekeeper conditions when it hits quantitative thresholds on market impact, gateway role, and durability. Use this as a screening test for each CPS separately (for example: an app store CPS may qualify even if another CPS does not). - Market impact presumption: >= EUR 7.5B annual EU turnover in each of the last 3 financial years OR >= EUR 75B average market capitalisation/fair market value in the last financial year, and the same CPS in at least 3 Member States. - Gateway presumption: in the last financial year, the CPS has >= 45M monthly active end users established or located in the EU AND >= 10,000 yearly active business users established in the EU (calculated using the Annex methodology). - Durability presumption: the gateway thresholds are met in each of the last 3 financial years. ## Step 3: Notification, designation, and the compliance clock If you meet all presumption thresholds, the DMA expects a notification to the Commission quickly, with a strict back-and-forth timeline. This timing matters because the DMA's core obligations (Articles 5-7) must be complied with within 6 months after a CPS is listed in the designation decision. - Notify the Commission without delay and in any event within 2 months after the thresholds are met (including information per CPS). - Commission designation deadline: at the latest within 45 working days after receiving complete information. - Compliance deadline: obligations in Articles 5, 6, and 7 apply within 6 months after the CPS is listed in the designation decision. - Practical filing readiness: keep your case file, signatory workflow, and secure submission channel ready before thresholds are hit, because DMA submissions are handled digitally and delays usually come from incomplete information, not from the form itself. ## Step 4: What if you don't meet the thresholds (but still look like a gatekeeper)? The DMA also allows designation based on qualitative assessment when thresholds are not met but the three conditions (market impact, gateway role, durable position) appear satisfied. Treat "near-threshold" or "structural advantage" signals as early warning indicators and start designing DMA-ready controls before designation. - Qualitative factors include: size/market position, user and business user numbers, network effects and data advantages, scale and scope effects, lock-in and switching costs, and vertical integration/conglomerate structure. - Plan for evidence and defensibility: why a CPS should or should not be listed; what features are "essential" vs "optional"; what integrity/security measures are necessary and proportionate. - Use current Commission outcomes as calibration: the public gatekeeper list now shows 7 gatekeepers and 23 designated CPS, while Facebook Marketplace was undesignated on 23 April 2025 and Apple Ads and Apple Maps were not designated on 5 February 2026 after notification and review. - If you are a business user, competitor, or end user, you can submit information about potential non-compliance to national competent authorities or the Commission. ## DMA scoping deliverables (what to produce in week one) A strong DMA applicability test ends with artifacts that product and compliance teams can execute against - not just an "in scope / out of scope" label. These deliverables also shorten the path to a defensible compliance report if the CPS is designated. - CPS inventory: services, user journeys, APIs, and dependencies (per CPS). - Gatekeeper threshold workbook: EU turnover/market cap, Member State coverage, MAU/BAU methodology assumptions, and confidence ranges. - Owner map: product owners + policy owners for each obligation cluster (data use, ranking, interoperability, choice screens, app distribution, ads transparency). - Evidence plan: what logs, policies, screenshots, demos, and metrics you can produce on demand. *Recommended next step* *Placement: after the applicability result* ## Turn EU Digital Markets Act (DMA) Applicability Test into an operational assessment Assessment Autopilot can take EU Digital Markets Act (DMA) Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU Digital Markets Act (DMA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Digital Markets Act (DMA) Applicability Test](/solutions/assessment.md): Start from EU Digital Markets Act (DMA) Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Digital Markets Act (DMA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Markets Act (DMA) Applicability Test. ## Primary sources - [Regulation (EU) 2022/1925 (Digital Markets Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - Primary legal text for CPS definitions, gatekeeper thresholds, notification/designation procedure, and the 6-month compliance deadline (Articles 2-3). - [Commission Implementing Regulation (EU) 2023/814 - DMA procedural rules](https://eur-lex.europa.eu/eli/reg/2023/814/oj?ref=sorena.io) - Procedural regulation (forms, notifications, conduct of proceedings) supporting DMA implementation and submissions. - [European Commission - Gatekeepers list and designated core platform services](https://digital-markets-act.ec.europa.eu/gatekeepers_en?ref=sorena.io) - Concrete examples of designated gatekeepers, CPS listings, and designation dates used to calibrate applicability risk. - [European Commission - Further information about the DMA (Q&A)](https://digital-markets-act.ec.europa.eu/questions-and-answers/further-information-about-dma_en?ref=sorena.io) - Practical guidance on contacts, submissions, and how stakeholders interact with the Commission on DMA implementation. - [DG Competition - EU SEND secure document exchange platform](https://competition-policy.ec.europa.eu/index/it-tools/eu-send_en?ref=sorena.io) - How to securely transmit DMA-related documents to the Commission (useful when notifications or submissions are required). ## Related Topic Guides - [DMA Compliance Checklist (Execution-Ready) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/checklist.md): An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls. - [DMA Compliance Program & Monitoring (Compliance Function + Evidence)](/artifacts/eu/digital-markets-act/compliance-program-and-monitoring.md): How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness. - [DMA Deadlines & Compliance Calendar (Key Dates) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar.md): A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline. - [DMA Do's and Don'ts for Product Teams | EU Digital Markets Act](/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams.md): Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes. - [DMA Enforcement: Penalties, Remedies, and Process | EU Digital Markets Act](/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies.md): How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies. - [DMA Fines & Penalties (10% / 20% / 1% + 5% per day) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/penalties-and-fines.md): A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%. - [DMA Obligations List (Articles 5, 6, 7) - By Obligation | EU Digital Markets Act](/artifacts/eu/digital-markets-act/core-obligations-by-obligation.md): A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores. - [DMA Self-Preferencing Compliance Examples (Article 6(5)) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples.md): Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what "transparent, fair. - [DMA vs DSA: What's the Difference? (EU Platform Laws)](/artifacts/eu/digital-markets-act/dma-vs-dsa.md): A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations. - [EU Digital Markets Act (DMA) Requirements (Articles 5-7)](/artifacts/eu/digital-markets-act/requirements.md): A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution. - [EU DMA Compliance Guide (How to Comply) | Digital Markets Act (DMA)](/artifacts/eu/digital-markets-act/compliance.md): A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations. - [EU DMA FAQ (Gatekeepers, Obligations, Deadlines) | Digital Markets Act](/artifacts/eu/digital-markets-act/faq.md): EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7). - [EU DMA Timeline & Key Milestones | Digital Markets Act (2022/1925)](/artifacts/eu/digital-markets-act/timeline-and-key-milestones.md): A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones. - [Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11)](/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist.md): A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report. - [Gatekeeper Designation Guide (DMA Article 3) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/gatekeeper-designation-guide.md): A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-markets-act/applicability-test --- --- title: "DMA Compliance Checklist (Execution-Ready)" canonical_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/checklist" source_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/checklist" author: "Sorena AI" description: "An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "DMA compliance checklist" - "Digital Markets Act checklist" - "gatekeeper compliance checklist" - "DMA Article 5 checklist" - "DMA Article 6 checklist" - "DMA Article 7 interoperability checklist" - "Article 11 compliance report checklist" - "Article 28 compliance function checklist" - "DMA checklist" - "Digital Markets Act compliance checklist" - "gatekeeper compliance" - "Article 5" - "Article 6" - "Article 7" - "Article 11 compliance report" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DMA Compliance Checklist (Execution-Ready) An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls. *Artifact Guide* *EU* ## EU Digital Markets Act (DMA) Compliance Checklist A checklist you can run per core platform service (CPS) and ship against. Designed for the 6-month compliance clock and Article 11 reporting evidence. DMA compliance is a program, not a document. Use this checklist to turn the EU Digital Markets Act (DMA) into shipped product changes, monitored controls, and an evidence library that supports Article 11 compliance reporting and reduces enforcement risk. ## Checklist Part A - Scope and designation readiness (Article 2-3) Run this part first. Everything else depends on correct CPS boundaries and correct designation timing per CPS. Treat CPS scoping as an engineering artifact: if you can't draw boundaries, you can't implement obligations consistently. - Inventory CPS categories you provide (Article 2): intermediation, search, social networking, video-sharing, NICS, OS, browser, virtual assistant, cloud computing, and ads services linked to those CPS. - For each CPS: define boundaries, key user journeys, ranking surfaces, data-sharing points, developer APIs, and ads stack dependencies. - Run the gatekeeper presumption thresholds per CPS (Article 3(2)) and set internal "threshold met" trigger dates for the 2-month notification clock (Article 3(3)). - Build a designation readiness pack: metrics methodology, Member State coverage, and a defensible CPS listing proposal. *Recommended next step* *Placement: after the checklist block* ## Turn EU Digital Markets Act (DMA) Compliance Checklist into an operational assessment Assessment Autopilot can take EU Digital Markets Act (DMA) Compliance Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Digital Markets Act (DMA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Digital Markets Act (DMA) Compliance Checklist](/solutions/assessment.md): Start from EU Digital Markets Act (DMA) Compliance Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Digital Markets Act (DMA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Markets Act (DMA) Compliance Checklist. ## Checklist Part B - The 6-month compliance clock (Articles 5-7) Once a CPS is listed in a designation decision, the gatekeeper must comply with Articles 5, 6, and 7 within 6 months. Treat this as a release-train schedule: each obligation becomes deliverables + evidence capture milestones. - Create an obligation-to-feature map per CPS for Articles 5-7 with owners and acceptance criteria. - Prioritise high-impact obligations: consent/data combination (Article 5(2)), anti-steering (Article 5(3)-(4)), app distribution/defaults (Article 6(3)-(4)), ranking neutrality (Article 6(5)), OS feature interoperability (Article 6(7)), and portability/data access (Article 6(9)-(10)). - Define monitoring checks and regression tests before rollout (choice screen tests, uninstall flows, API access parity tests, ranking parity tests). - Plan for staged obligations: Article 7 interoperability timelines (0 / 2 years / 4 years) where applicable. ## Checklist Part C - Governance: compliance function + change control (Article 28) DMA requires gatekeepers to introduce an independent compliance function and management accountability for compliance governance. Governance prevents "compliance drift" when ranking parameters, UX, or access rules change. - Establish the DMA compliance function independent from operations; appoint a head of compliance with direct reporting to the management body. - Set a DMA change control gate for CPS changes (launch reviews, A/B experiments, ranking changes, policy changes). - Create an exceptions register (integrity/security restrictions) with necessity + proportionality justification and test evidence. ## Checklist Part D - Evidence library and Article 11 compliance reporting The Commission's Article 11 compliance report template is your evidence blueprint. Build the evidence library as you implement so reporting isn't a scramble. For each obligation, capture both what changed and how it achieves effective compliance, backed by data and documentation. - Per CPS and per obligation: compliance statement, exhaustive explanation, prior state, implementation date, scope (products/devices), geographic scope, and engineering/UX changes. - Attach supporting data and internal documents (including recorded demos where relevant). - Keep underlying raw data ready for Commission requests; store evidence in machine-readable formats where possible. ## Checklist Part E - Stakeholder and enforcement readiness DMA programs are stress-tested via stakeholder expectations: business users, developers, competitors, and end users. Prepare for information requests and enforcement-style questions by making evidence retrieval fast and repeatable. - Set up a single intake for DMA-related complaints and developer requests; tag by CPS + obligation + remediation owner. - Rehearse "Commission-style" requests: produce logs, data, and testing evidence quickly (days, not weeks). - Monitor Commission resources and Q&A updates that shape expectations (interoperability specifications and guidance). ## Primary sources - [Regulation (EU) 2022/1925 (Digital Markets Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - CPS definitions, designation process, 6-month compliance deadline, obligations (Articles 5-7), and compliance function requirements (Article 28). - [European Commission - Article 11 DMA Compliance Report Template (9 Oct 2023)](https://digital-markets-act.ec.europa.eu/about-dma/practical-information_en#templates?ref=sorena.io) - Evidence checklist for compliance reporting and annual update cadence. - [European Commission - Gatekeepers list and designated core platform services](https://digital-markets-act.ec.europa.eu/gatekeepers_en?ref=sorena.io) - CPS listings and designation examples for calibration. - [European Commission - Resources for businesses](https://digital-markets-act.ec.europa.eu/questions-and-answers/resources-businesses_en?ref=sorena.io) - Practical technical resources used for portability/interoperability requests. ## Related Topic Guides - [DMA Applicability Test (Gatekeeper Scoping) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/applicability-test.md): A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds. - [DMA Compliance Program & Monitoring (Compliance Function + Evidence)](/artifacts/eu/digital-markets-act/compliance-program-and-monitoring.md): How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness. - [DMA Deadlines & Compliance Calendar (Key Dates) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar.md): A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline. - [DMA Do's and Don'ts for Product Teams | EU Digital Markets Act](/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams.md): Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes. - [DMA Enforcement: Penalties, Remedies, and Process | EU Digital Markets Act](/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies.md): How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies. - [DMA Fines & Penalties (10% / 20% / 1% + 5% per day) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/penalties-and-fines.md): A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%. - [DMA Obligations List (Articles 5, 6, 7) - By Obligation | EU Digital Markets Act](/artifacts/eu/digital-markets-act/core-obligations-by-obligation.md): A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores. - [DMA Self-Preferencing Compliance Examples (Article 6(5)) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples.md): Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what "transparent, fair. - [DMA vs DSA: What's the Difference? (EU Platform Laws)](/artifacts/eu/digital-markets-act/dma-vs-dsa.md): A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations. - [EU Digital Markets Act (DMA) Requirements (Articles 5-7)](/artifacts/eu/digital-markets-act/requirements.md): A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution. - [EU DMA Compliance Guide (How to Comply) | Digital Markets Act (DMA)](/artifacts/eu/digital-markets-act/compliance.md): A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations. - [EU DMA FAQ (Gatekeepers, Obligations, Deadlines) | Digital Markets Act](/artifacts/eu/digital-markets-act/faq.md): EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7). - [EU DMA Timeline & Key Milestones | Digital Markets Act (2022/1925)](/artifacts/eu/digital-markets-act/timeline-and-key-milestones.md): A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones. - [Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11)](/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist.md): A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report. - [Gatekeeper Designation Guide (DMA Article 3) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/gatekeeper-designation-guide.md): A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-markets-act/checklist --- --- title: "DMA Compliance Program & Monitoring (Compliance Function + Evidence)" canonical_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/compliance-program-and-monitoring" source_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/compliance-program-and-monitoring" author: "Sorena AI" description: "How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "DMA compliance program" - "DMA monitoring" - "Article 28 compliance function" - "Article 11 compliance report template" - "DMA evidence pack" - "DMA audit readiness" - "Digital Markets Act compliance program" - "gatekeeper compliance monitoring" - "DMA compliance function" - "Article 11 compliance report" - "evidence library" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DMA Compliance Program & Monitoring (Compliance Function + Evidence) How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness. *Artifact Guide* *EU* ## EU Digital Markets Act (DMA) Compliance Program & Monitoring Design a DMA compliance function, evidence library, and monitoring layer that scales across CPS. Aligned to Articles 5-7 obligations and the Commission's Article 11 compliance report expectations. DMA compliance fails most often where governance is vague: unclear owners, missing evidence, and "one-off" product changes that drift over time. The DMA explicitly requires a compliance function (Article 28) and expects transparent, detailed reporting on measures for Articles 5-7. This guide shows how to build a DMA compliance program that stays correct as products evolve. ## Start with the DMA operating model: CPS-by-CPS compliance ownership DMA obligations attach to each core platform service (CPS) listed in the designation decision. Your compliance program should mirror that structure. Use a "CPS control plane" approach: one governance model, replicated per CPS, with shared evidence standards and monitoring patterns. - Create CPS owners: one product owner + one policy/legal owner per CPS. - Create obligation owners: data combination/consent, ranking and self-preferencing, app distribution and defaults, interoperability and APIs, ads transparency and measurement. - Maintain a single evidence standard across CPS (naming, retention, versioning, and exportability). *Recommended next step* *Placement: after the compliance steps* ## Turn EU Digital Markets Act (DMA) Compliance Program & Monitoring into an operational assessment Assessment Autopilot can take EU Digital Markets Act (DMA) Compliance Program & Monitoring from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Digital Markets Act (DMA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Digital Markets Act (DMA) Compliance Program & Monitoring](/solutions/assessment.md): Start from EU Digital Markets Act (DMA) Compliance Program & Monitoring and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Digital Markets Act (DMA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Markets Act (DMA) Compliance Program & Monitoring. ## Article 28 compliance function: what "independent" means in practice The DMA requires gatekeepers to introduce a compliance function independent from operational functions, composed of one or more compliance officers (including a head of compliance). The compliance function must have sufficient authority, stature, resources, and access to the management body to monitor compliance. - Reporting line: head of compliance reports directly to the management body and can raise concerns and warn of non-compliance risks. - Independence controls: separation of responsibilities, conflict-of-interest prevention, and protected removal conditions (head not removed without management approval). - Task list: organise/monitor/supervise DMA measures, advise employees, monitor binding commitments where relevant, and cooperate with the Commission. ## Article 11 compliance reporting: build the evidence library before you need it The Commission's Article 11 compliance report template is effectively a checklist for evidence. It expects a compliance statement and an exhaustive explanation per CPS and per applicable obligation (Articles 5-7). A good evidence library is engineering-grade: it includes both "what changed" and "why it is compliant", backed by data and internal documentation. - For each obligation: record prior state, implementation date, product/service/device scope, geographic scope, and the technical/engineering changes made. - Include supporting artifacts: data points, visual illustrations, recorded demos, API documentation, ranking parameter explanations, and security integrity justifications. - Store underlying raw data ready for Commission requests; keep the report, annexes, non-confidential summary, and exports machine-readable where possible. - Track retention policy explicitly because the Article 11 template expects gatekeepers to disclose document-retention treatment without undue delay. ## Monitoring layer: make compliance measurable and continuously testable DMA compliance is dynamic: ranking changes, consent screens drift, defaults regress, and APIs evolve. Monitoring is how you prevent "compliance decay." Design monitoring so a regulator question can be answered with: evidence -> metric -> control -> owner. - Control monitoring: automated checks for default-setting prompts, uninstall flows, app-store access rules, ranking neutrality tests, and data-sharing permission gates. - Change control: DMA review gates in product launch processes for CPS changes, A/B experiments, and policy updates. - KPI dashboards: track portability request volumes, interoperability request SLAs, consent refusal rates, ranking fairness audits, and business-user complaint themes. ## Regulator readiness: retention, audits, and third-party information The Commission can take actions to monitor effective implementation and compliance, including requiring retention of relevant documents and appointing independent experts/auditors to assist monitoring. Third parties can inform national competent authorities or the Commission directly about practices falling within the DMA scope. Treat stakeholder submissions as a predictable input stream. - Retention policy: define what you retain, for how long, and how quickly you can produce it (screens, logs, ranking parameters, API access rules). - Audit drills: run internal "Commission-style" reviews against a sample of obligations per CPS and produce the evidence pack as if requested tomorrow. - Issue intake: centralise business-user and end-user complaints related to DMA obligations; link them to obligations and remediation work items. ## Practical 30/60/90-day DMA compliance program plan Use this as a quick-start plan for building the compliance function, monitoring, and evidence library alongside product implementation. Adjust the sequence per CPS designation date and the 6-month compliance deadline. - 30 days: appoint compliance function leadership, define CPS inventory and owners, set evidence standards, and start obligation-to-feature mapping. - 60 days: implement monitoring checks for top-risk obligations (consent and data combination, ranking and self-preferencing, app distribution and defaults), and start compliance report drafting skeleton per CPS. - 90 days: run audit drills, refine KPIs, ensure machine-readable evidence exports, prepare the profiling-techniques description workstream if applicable, and publish an internal DMA playbook for product teams. ## Primary sources - [Regulation (EU) 2022/1925 (Digital Markets Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - Compliance function requirements (Article 28) and Commission monitoring powers (Article 26), plus obligations baseline (Articles 5-7). - [European Commission - Article 11 DMA Compliance Report Template (9 Oct 2023)](https://digital-markets-act.ec.europa.eu/about-dma/practical-information_en#templates?ref=sorena.io) - Evidence expectations for compliance reporting (per CPS and per obligation) and annual update cadence. - [European Commission - Further information about the DMA (Q&A)](https://digital-markets-act.ec.europa.eu/questions-and-answers/further-information-about-dma_en?ref=sorena.io) - Submission channels and stakeholder interaction patterns that feed monitoring and issue intake. - [European Commission - Gatekeepers list and designated core platform services](https://digital-markets-act.ec.europa.eu/gatekeepers_en?ref=sorena.io) - CPS-level scope and designation examples for building CPS-by-CPS governance. - [DG Competition - EU SEND secure document exchange platform](https://competition-policy.ec.europa.eu/index/it-tools/eu-send_en?ref=sorena.io) - Secure document submission mechanism often used in DMA-related exchanges. ## Related Topic Guides - [DMA Applicability Test (Gatekeeper Scoping) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/applicability-test.md): A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds. - [DMA Compliance Checklist (Execution-Ready) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/checklist.md): An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls. - [DMA Deadlines & Compliance Calendar (Key Dates) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar.md): A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline. - [DMA Do's and Don'ts for Product Teams | EU Digital Markets Act](/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams.md): Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes. - [DMA Enforcement: Penalties, Remedies, and Process | EU Digital Markets Act](/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies.md): How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies. - [DMA Fines & Penalties (10% / 20% / 1% + 5% per day) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/penalties-and-fines.md): A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%. - [DMA Obligations List (Articles 5, 6, 7) - By Obligation | EU Digital Markets Act](/artifacts/eu/digital-markets-act/core-obligations-by-obligation.md): A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores. - [DMA Self-Preferencing Compliance Examples (Article 6(5)) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples.md): Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what "transparent, fair. - [DMA vs DSA: What's the Difference? (EU Platform Laws)](/artifacts/eu/digital-markets-act/dma-vs-dsa.md): A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations. - [EU Digital Markets Act (DMA) Requirements (Articles 5-7)](/artifacts/eu/digital-markets-act/requirements.md): A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution. - [EU DMA Compliance Guide (How to Comply) | Digital Markets Act (DMA)](/artifacts/eu/digital-markets-act/compliance.md): A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations. - [EU DMA FAQ (Gatekeepers, Obligations, Deadlines) | Digital Markets Act](/artifacts/eu/digital-markets-act/faq.md): EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7). - [EU DMA Timeline & Key Milestones | Digital Markets Act (2022/1925)](/artifacts/eu/digital-markets-act/timeline-and-key-milestones.md): A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones. - [Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11)](/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist.md): A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report. - [Gatekeeper Designation Guide (DMA Article 3) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/gatekeeper-designation-guide.md): A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-markets-act/compliance-program-and-monitoring --- --- title: "EU DMA Compliance Guide (How to Comply)" canonical_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/compliance" source_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/compliance" author: "Sorena AI" description: "A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU DMA compliance" - "Digital Markets Act compliance guide" - "DMA compliance steps" - "gatekeeper compliance" - "DMA Article 5 compliance" - "DMA Article 6 compliance" - "DMA Article 7 interoperability compliance" - "Article 11 compliance report" - "Article 28 compliance function" - "Digital Markets Act compliance" - "Article 5" - "Article 6" - "Article 7" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DMA Compliance Guide (How to Comply) A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations. *Artifact Guide* *EU* ## EU Digital Markets Act (DMA) Compliance Guide A how-to guide for implementing DMA obligations per core platform service (CPS). Built for practitioners: workstreams, owners, evidence, and monitoring aligned to Commission expectations. DMA compliance starts with one reality: obligations attach to specific core platform services (CPS) listed in a gatekeeper designation decision, and the gatekeeper must comply with Articles 5-7 within 6 months after listing. This guide shows how to convert the DMA into shipped product changes and an evidence library that supports Article 11 reporting and reduces enforcement risk. ## Step 1 - Scope your CPS and map obligations per service Treat CPS scoping as an engineering artifact. Designation decisions list relevant CPS, and obligations attach to each listed CPS. Build a CPS inventory with boundaries, system maps, and user journeys; then map Articles 5-7 obligations to the surfaces that implement them. - Per CPS: identify ranking/discovery surfaces, default settings, distribution channels, APIs, and cross-service data sharing points. - Create an obligation-to-feature map for Articles 5-7 with owners and acceptance criteria per obligation. - Identify obligations that require "integrity/security" restrictions and prepare necessity + proportionality justification. ## Step 2 - Build the 0-6 month delivery plan (designation -> compliance deadline) After a CPS is listed in the designation decision, the gatekeeper must comply with Articles 5, 6, and 7 within 6 months. Break the 6 months into release milestones that ship functionality and evidence in parallel. - Month 0-1: finalise scope, implement consent/data combination controls (Article 5(2)), and design choice screens/default changes (Article 6(3)). - Month 1-3: implement app distribution and third-party app store enablement (Article 6(4)), ranking governance changes (Article 6(5)), and portability/data access tooling (Article 6(9)-(10)). - Month 3-6: harden monitoring, publish required terms/access conditions, validate interoperability and API access parity (Article 6(7)), and complete evidence pack for reporting. *Recommended next step* *Placement: after the compliance steps* ## Turn EU Digital Markets Act (DMA) Compliance Guide into an operational assessment Assessment Autopilot can take EU Digital Markets Act (DMA) Compliance Guide from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Digital Markets Act (DMA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Digital Markets Act (DMA) Compliance Guide](/solutions/assessment.md): Start from EU Digital Markets Act (DMA) Compliance Guide and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Digital Markets Act (DMA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Markets Act (DMA) Compliance Guide. ## Step 3 - Implement Article 5 obligations (data, anti-steering, and tying bans) Article 5 contains high-impact requirements that often require product and commercial changes. Implement these with concrete controls: permissions gates, policy changes, logging, and tests. - Consent and data combination: do not combine/cross-use personal data across CPS and other services unless end users have specific choice and consent; do not re-request more than once per year if refused/withdrawn. - Anti-steering: allow business users to offer different prices/conditions elsewhere; allow business users to communicate/promote offers and conclude contracts with end users acquired via the CPS. - No forced use of gatekeeper services: do not require gatekeeper identity, browser engine, payment services, or in-app payment technical services for business users' services. - Ads transparency: implement daily reporting for advertisers and publishers on prices/fees/remuneration and metric basis. ## Step 4 - Implement Article 6 obligations (choice, distribution, fairness, access) Article 6 obligations often require deep engineering work: uninstallability, default settings and choice screens, third-party app distribution, ranking neutrality, and continuous data access. Design for measurement and auditability because Article 6 obligations can be further specified under Article 8. - Enable uninstall and default changes; prompt end users at first use to choose search/assistant/browser providers where applicable. - Allow third-party apps and app stores using/interoperating with the OS, including access outside the gatekeeper CPS, subject to strictly necessary and proportionate integrity/security measures. - No self-preferencing in ranking/indexing/crawling; apply transparent, fair, non-discriminatory ranking conditions and implement ranking governance + parity tests. - Provide end-user data portability tools and continuous/real-time access; provide business-user continuous/real-time access to aggregated and non-aggregated data generated via CPS use (personal data with opt-in consent). ## Step 5 - Implement Article 7 (if applicable): staged messaging interoperability If you operate a designated number-independent interpersonal communications service (NICS), Article 7 introduces staged interoperability obligations relative to designation. Treat this as a multi-year engineering program with security assurance and operational SLAs for requests. - After listing: 1:1 text messaging and 1:1 file sharing interoperability (where offered). - Within 2 years: group messaging interoperability and group-to-individual file sharing interoperability. - Within 4 years: voice and video call interoperability (1:1 and group-to-individual). - Publish a reference offer within the 6-month period and comply with reasonable interoperability requests within 3 months. ## Step 6 - Governance and evidence: Article 28 compliance function + Article 11 reporting DMA requires an independent compliance function (Article 28). This is your "compliance engine" that maintains the program through product change. The Commission's Article 11 compliance report template clarifies what evidence you must be able to produce per CPS and per obligation. - Stand up the compliance function with direct reporting to the management body, sufficient resources, and clear task ownership. - Build an evidence library per CPS and per obligation: prior state, implementation date, scope, engineering changes, UX changes, and effectiveness metrics. - Keep underlying raw data ready and export evidence in machine-readable formats where possible. ## Primary sources - [Regulation (EU) 2022/1925 (Digital Markets Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - Core obligations (Articles 5-7), 6-month compliance deadline (Article 3(10)), and compliance function requirements (Article 28). - [European Commission - Article 11 DMA Compliance Report Template (9 Oct 2023)](https://digital-markets-act.ec.europa.eu/about-dma/practical-information_en#templates?ref=sorena.io) - Evidence expectations and reporting cadence for demonstrating effective compliance per CPS and per obligation. - [European Commission - Resources for businesses](https://digital-markets-act.ec.europa.eu/questions-and-answers/resources-businesses_en?ref=sorena.io) - Operational resources used for portability/interoperability access requests (useful for implementation). - [European Commission - Interoperability (Questions and Answers)](https://digital-markets-act.ec.europa.eu/questions-and-answers/interoperability_en?ref=sorena.io) - Practical interoperability examples and specification context for Article 6(7). ## Related Topic Guides - [DMA Applicability Test (Gatekeeper Scoping) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/applicability-test.md): A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds. - [DMA Compliance Checklist (Execution-Ready) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/checklist.md): An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls. - [DMA Compliance Program & Monitoring (Compliance Function + Evidence)](/artifacts/eu/digital-markets-act/compliance-program-and-monitoring.md): How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness. - [DMA Deadlines & Compliance Calendar (Key Dates) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar.md): A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline. - [DMA Do's and Don'ts for Product Teams | EU Digital Markets Act](/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams.md): Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes. - [DMA Enforcement: Penalties, Remedies, and Process | EU Digital Markets Act](/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies.md): How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies. - [DMA Fines & Penalties (10% / 20% / 1% + 5% per day) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/penalties-and-fines.md): A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%. - [DMA Obligations List (Articles 5, 6, 7) - By Obligation | EU Digital Markets Act](/artifacts/eu/digital-markets-act/core-obligations-by-obligation.md): A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores. - [DMA Self-Preferencing Compliance Examples (Article 6(5)) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples.md): Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what "transparent, fair. - [DMA vs DSA: What's the Difference? (EU Platform Laws)](/artifacts/eu/digital-markets-act/dma-vs-dsa.md): A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations. - [EU Digital Markets Act (DMA) Requirements (Articles 5-7)](/artifacts/eu/digital-markets-act/requirements.md): A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution. - [EU DMA FAQ (Gatekeepers, Obligations, Deadlines) | Digital Markets Act](/artifacts/eu/digital-markets-act/faq.md): EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7). - [EU DMA Timeline & Key Milestones | Digital Markets Act (2022/1925)](/artifacts/eu/digital-markets-act/timeline-and-key-milestones.md): A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones. - [Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11)](/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist.md): A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report. - [Gatekeeper Designation Guide (DMA Article 3) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/gatekeeper-designation-guide.md): A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-markets-act/compliance --- --- title: "DMA Obligations List (Articles 5, 6, 7) - By Obligation" canonical_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/core-obligations-by-obligation" source_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/core-obligations-by-obligation" author: "Sorena AI" description: "A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "DMA obligations list" - "Digital Markets Act obligations" - "Article 5 obligations" - "Article 6 obligations" - "Article 7 interoperability obligations" - "gatekeeper obligations checklist" - "DMA app store obligations" - "DMA self-preferencing obligations" - "DMA data portability obligations" - "DMA obligations" - "DMA Article 5" - "DMA Article 6" - "DMA Article 7" - "gatekeeper obligations" - "core platform services" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DMA Obligations List (Articles 5, 6, 7) - By Obligation A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores. *Artifact Guide* *EU* ## EU Digital Markets Act (DMA) Obligations (By Obligation) A practical breakdown of DMA obligations you can turn into controls and acceptance criteria. Built for mapping to product features, engineering workstreams, monitoring checks, and the Article 11 compliance report. DMA obligations attach to each core platform service (CPS) listed in a gatekeeper designation decision. Use this list to build an obligation-to-feature map per CPS, assign owners, and capture evidence as you implement. This page focuses on the core obligation set in Articles 5, 6, and 7. ## How to use this obligations list (execution format) For each CPS, convert every obligation into: (1) product requirement(s), (2) control(s), (3) monitoring check(s), and (4) evidence artifacts. The Commission's Article 11 compliance report template expects a detailed, transparent explanation per CPS and per applicable obligation - this list helps you build that structure. - Create a row per obligation: obligation text -> impacted surfaces -> owner -> acceptance criteria -> evidence. - Track "by design" obligations (e.g., ranking neutrality) separately from "by policy" obligations (e.g., anti-steering contract language). - Treat integrity/security restrictions as exceptions requiring necessity + proportionality justification and test evidence. ## Article 5 obligations (selected high-impact obligations) Article 5 contains obligations that restrict certain practices and require concrete operational and product controls. These are often high-impact because they touch ads systems, consent flows, and commercial terms with business users. - Personal data restrictions for advertising and cross-service combination: do not combine/cross-use personal data across CPS and other services unless the end user has specific choice and consent; do not re-prompt more than once per year if refused/withdrawn. - Anti-steering: do not prevent business users from offering different prices/conditions via other channels; allow business users to communicate/promote offers and conclude contracts with end users acquired via the CPS. - End-user access: allow end users to access content/subscriptions/features via a business user's app even if acquired outside the gatekeeper's CPS. - No retaliation for complaints: do not prevent or restrict business users/end users from raising non-compliance issues with public authorities and courts. - No tying to gatekeeper services: do not require gatekeeper identification services, browser engines, payment services, or in-app payment technical services in the context of business users' services using the CPS. - Ads transparency reporting: provide advertisers and publishers daily information on prices/fees/remuneration and the metrics used (subject to consent constraints). ## Article 6 obligations (susceptible of further specification under Article 8) Article 6 obligations are broad and often implemented through product changes, APIs, and transparent access conditions. They are also susceptible of further specification under Article 8, so design for adaptability. Below is an execution-oriented summary of the obligations that commonly drive engineering roadmaps. - No use of non-public business-user data to compete: including inferred/aggregated data such as click, search, view, and voice data generated via CPS use. - Uninstall + defaults + choice screens: allow easy uninstall of apps (except essential OS/device apps); allow easy default changes; prompt end users at first use to choose among main providers for search, virtual assistant, and browser where applicable. - Third-party apps and app stores: allow installation and effective use of third-party apps/app stores using or interoperating with the OS; allow access by means other than the gatekeeper's CPS; allow setting downloaded apps/app stores as default (subject to strictly necessary and proportionate integrity/security measures). - No self-preferencing in ranking/indexing/crawling: apply transparent, fair, non-discriminatory ranking conditions. - No switching restrictions: do not technically or otherwise restrict end users from switching between apps/services accessed using the CPS (including choice of internet access services). - OS/virtual assistant feature interoperability (Article 6(7)): allow free and effective interoperability and access for interoperability to the same hardware/software features available to gatekeeper services/hardware (subject to strictly necessary and proportionate integrity measures). - Ads verification: provide access to performance measuring tools and data needed for independent verification of ad inventory (aggregated and non-aggregated data). - Data portability for end users: provide effective portability of data provided by end users or generated through their activity, including continuous and real-time access and tools facilitating portability. - Data access for business users: provide effective, high-quality, continuous and real-time access to aggregated and non-aggregated data generated in CPS use by business users and their end users (personal data only with end-user opt-in consent). - Search data access: provide third-party search engines access on FRAND terms to ranking, query, click and view data for searches on the gatekeeper's search engine (personal data anonymised). - FRAND access terms and transparency: apply fair, reasonable, and non-discriminatory general conditions of access for business users to app stores, search engines, and social networks; publish conditions including alternative dispute settlement. - No disproportionate termination conditions: ensure termination conditions are proportionate and can be exercised without undue difficulty. ## Article 7 obligations (messaging interoperability with staged deadlines) Article 7 applies when a gatekeeper provides number-independent interpersonal communications services (NICS) listed in the designation decision. Interoperability is request-based, free of charge, and must preserve security (including end-to-end encryption where applicable). - After listing: make 1:1 end-to-end text messaging interoperable; and sharing of images/voice messages/videos/other files in 1:1 communication interoperable (where offered to your users). - Within 2 years from designation: group text messaging and group-to-individual file sharing interoperability. - Within 4 years from designation: voice and video calls interoperability (1:1 and group-to-individual). - Publish a reference offer with technical details/terms within the 6-month compliance period; comply with reasonable interoperability requests within 3 months. - Limit personal data exchange to what is strictly necessary and comply with EU data protection law. ## Obligation-to-control mapping: the minimum evidence set (Article 11 style) For each obligation you implement, capture evidence in a way that can be reused in the compliance report: what changed, when, and how it achieves effective compliance. This is the fastest way to avoid "compliance by assertion" and to reduce enforcement risk. - Prior state vs new state: UX screenshots, API docs, system diagrams, and change logs. - Implementation details: scope (products/devices), geography (EU vs global), and engineering details (data usage policies, ranking parameters, security measures). - Effectiveness proof: metrics, tests, and user/business-user impact monitoring. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU Digital Markets Act (DMA) Obligations (By Obligation) as a cited research workflow Research Copilot can take EU Digital Markets Act (DMA) Obligations (By Obligation) from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU Digital Markets Act (DMA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Digital Markets Act (DMA) Obligations (By Obligation)](/solutions/research-copilot.md): Start from EU Digital Markets Act (DMA) Obligations (By Obligation) and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Digital Markets Act (DMA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Markets Act (DMA) Obligations (By Obligation). ## Primary sources - [Regulation (EU) 2022/1925 (Digital Markets Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - Primary obligations in Articles 5, 6, and 7 (per CPS, after designation). - [European Commission - Article 11 DMA Compliance Report Template (9 Oct 2023)](https://digital-markets-act.ec.europa.eu/about-dma/practical-information_en#templates?ref=sorena.io) - Evidence expectations per obligation and per CPS for demonstrating effective compliance. - [European Commission - Interoperability (Questions and Answers)](https://digital-markets-act.ec.europa.eu/questions-and-answers/interoperability_en?ref=sorena.io) - Practical interoperability examples and specification context for Article 6(7). - [European Commission - Resources for businesses](https://digital-markets-act.ec.europa.eu/questions-and-answers/resources-businesses_en?ref=sorena.io) - Practical implementation resources and portals used by designated gatekeepers for portability/interoperability requests. ## Related Topic Guides - [DMA Applicability Test (Gatekeeper Scoping) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/applicability-test.md): A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds. - [DMA Compliance Checklist (Execution-Ready) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/checklist.md): An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls. - [DMA Compliance Program & Monitoring (Compliance Function + Evidence)](/artifacts/eu/digital-markets-act/compliance-program-and-monitoring.md): How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness. - [DMA Deadlines & Compliance Calendar (Key Dates) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar.md): A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline. - [DMA Do's and Don'ts for Product Teams | EU Digital Markets Act](/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams.md): Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes. - [DMA Enforcement: Penalties, Remedies, and Process | EU Digital Markets Act](/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies.md): How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies. - [DMA Fines & Penalties (10% / 20% / 1% + 5% per day) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/penalties-and-fines.md): A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%. - [DMA Self-Preferencing Compliance Examples (Article 6(5)) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples.md): Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what "transparent, fair. - [DMA vs DSA: What's the Difference? (EU Platform Laws)](/artifacts/eu/digital-markets-act/dma-vs-dsa.md): A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations. - [EU Digital Markets Act (DMA) Requirements (Articles 5-7)](/artifacts/eu/digital-markets-act/requirements.md): A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution. - [EU DMA Compliance Guide (How to Comply) | Digital Markets Act (DMA)](/artifacts/eu/digital-markets-act/compliance.md): A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations. - [EU DMA FAQ (Gatekeepers, Obligations, Deadlines) | Digital Markets Act](/artifacts/eu/digital-markets-act/faq.md): EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7). - [EU DMA Timeline & Key Milestones | Digital Markets Act (2022/1925)](/artifacts/eu/digital-markets-act/timeline-and-key-milestones.md): A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones. - [Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11)](/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist.md): A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report. - [Gatekeeper Designation Guide (DMA Article 3) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/gatekeeper-designation-guide.md): A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-markets-act/core-obligations-by-obligation --- --- title: "DMA Deadlines & Compliance Calendar (Key Dates)" canonical_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "DMA deadlines" - "Digital Markets Act compliance calendar" - "DMA timeline" - "DMA designation timeline" - "DMA notification 2 months" - "DMA designation 45 working days" - "DMA compliance 6 months" - "Article 11 compliance report" - "Article 7 interoperability 2 years 4 years" - "Digital Markets Act timeline" - "gatekeeper designation" - "Article 7 interoperability" - "EU platform regulation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DMA Deadlines & Compliance Calendar (Key Dates) A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline. *Artifact Guide* *EU* ## EU Digital Markets Act (DMA) Deadlines & Compliance Calendar Turn DMA timelines into calendar entries your teams can execute. Includes designation deadlines, the 6-month compliance clock, reporting cadence, and Article 7 staged interoperability timelines. The fastest DMA programs treat legal deadlines as delivery dates. This page converts the EU Digital Markets Act (DMA) timing rules into a practical compliance calendar: when you must notify the Commission, when designation must happen, when obligations must be met, and how to plan for ongoing reporting and staged interoperability. ## Baseline DMA timeline: application, designation, compliance The DMA has a general application date and a separate "designation -> compliance" clock that matters most for implementation teams. Your calendar should track three overlapping timelines: (1) regulation-level milestones, (2) CPS-level designation milestones, and (3) obligation-level delivery milestones. - DMA application date: 2 May 2023 (with some provisions applying earlier, including delegated-act powers starting 1 Nov 2022 and Articles 42 and 43 from 25 Jun 2023). - Notification deadline (threshold-based presumption): notify the Commission without delay and in any event within 2 months after thresholds are met. - Designation decision deadline: the Commission must designate without undue delay and at the latest within 45 working days after receiving complete information. - Compliance deadline: comply with Articles 5, 6, and 7 within 6 months after a CPS is listed in the designation decision. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU Digital Markets Act (DMA) Deadlines & Compliance Calendar into an operational assessment Assessment Autopilot can take EU Digital Markets Act (DMA) Deadlines & Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Digital Markets Act (DMA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Digital Markets Act (DMA) Deadlines & Compliance Calendar](/solutions/assessment.md): Start from EU Digital Markets Act (DMA) Deadlines & Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Digital Markets Act (DMA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Markets Act (DMA) Deadlines & Compliance Calendar. ## Calendar template: key entries to create for each CPS Create a calendar per listed core platform service (CPS). Each CPS can have different designation dates and therefore different compliance due dates. If you operate multiple CPS categories (e.g., OS + app store + browser + ads), you should expect different owners and evidence packs per CPS. - T0: internal threshold trigger date (when you believe thresholds were met) -> start 2-month notification countdown. - T0 + 2 months: notification deadline for threshold-based presumption cases (Article 3(3)). - T1: "complete information received" date (for Commission) -> start 45 working day designation countdown. - T2: designation decision date (CPS listed) -> start 6-month compliance countdown (Articles 5-7). - T2 + 6 months: Article 5/6/7 compliance due date per CPS; align release trains and evidence capture to this date. ## Article 11 compliance reporting: plan for evidence early DMA compliance is expected to be documented. The Commission provides a template for Article 11 compliance reporting and expects detailed, transparent explanations of measures, supported by data and internal documentation. Treat the compliance report as a product deliverable: it forces you to articulate how you comply per CPS and per obligation, and it is easier to write when evidence is captured as you implement. - Within 6 months after designation: provide a detailed compliance report and a non-confidential summary (Article 11 template guidance). - At least annually: update the compliance report; plan an annual "DMA evidence refresh" sprint. - Machine-readable format expectation: store the report, annexes, non-confidential summary, and underlying data in structured repositories that can be exported without manual reconstruction. - Raw data readiness: the Article 11 template expects the underlying raw data to be ready if the Commission requests it. ## Article 7 interoperability calendar (staged: 0 / 2 years / 4 years) If you provide a number-independent interpersonal communications service (NICS) listed in the designation decision, Article 7 introduces staged deadlines relative to the designation date. These milestones often require protocol work, security assurance, abuse prevention, and operational readiness for interoperability requests. - After listing: 1:1 interoperability for end-to-end text messaging and 1:1 file sharing (where offered to your users). - Within 2 years from designation: group text messaging and group-to-individual file sharing interoperability. - Within 4 years from designation: voice and video calls (1:1 and group-to-individual). - Operational SLA: comply with a reasonable interoperability request within 3 months after receiving the request; publish and maintain a reference offer. ## Real-world anchor dates (useful for planning cadence) Use public designation and enforcement dates as "cadence markers" to keep your DMA program current and benchmark your readiness against Commission activity. These dates do not replace your CPS-specific deadlines - they help you understand when the Commission has acted and how quickly programs may need to adapt. - 6 Sep 2023: first Commission designations (examples include Alphabet, Amazon, Apple, ByteDance, Meta, Microsoft). - 29 Apr 2024: Apple designated for iPadOS (tablet operating system) as a gatekeeper for that CPS. - 13 May 2024: Booking designated for its online intermediation service (Booking.com). - 23 Apr 2025: Meta was undesignated for Facebook Marketplace, which shows that CPS status can change over time. - 5 Feb 2026: the Commission concluded Apple Ads and Apple Maps should not be designated after Apple notified those services in Nov 2025. - 3 May 2026: Commission evaluation and reporting deadline, and subsequently every 3 years. ## Workstream planning: map deadlines to owners and evidence A DMA compliance calendar should not just list dates - it should map each date to owners, deliverables, and evidence outcomes. Use this mapping to drive weekly execution meetings: "What must ship by the next deadline, and what evidence must be captured?" - Obligation owner: assign a product owner and a policy/legal owner for each obligation cluster (data combination, app distribution, ranking, interoperability, ads transparency). - Evidence owner: assign a compliance evidence lead per CPS to ensure report-ready artifacts exist (demos, screenshots, logs, API docs). - Exception register: if you rely on integrity/security constraints, record justification and proportionality analysis with test results and risk assessments. ## Primary sources - [Regulation (EU) 2022/1925 (Digital Markets Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - Notification/designation deadlines (Article 3) and staged interoperability deadlines (Article 7). - [European Commission - Gatekeepers list and designated core platform services](https://digital-markets-act.ec.europa.eu/gatekeepers_en?ref=sorena.io) - Public designation dates and currently designated CPS used as anchor points for planning. - [European Commission - Article 11 DMA Compliance Report Template (9 Oct 2023)](https://digital-markets-act.ec.europa.eu/about-dma/practical-information_en#templates?ref=sorena.io) - Compliance report timing expectations (within 6 months of designation) and annual update cadence, plus evidence format guidance. - [Regulation (EU) 2022/1925 - Commission evaluation cycle (3 May 2026, then every 3 years)](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - Evaluation and reporting cycle that informs medium-term program planning and updates. - [European Commission - Further information about the DMA (Q&A)](https://digital-markets-act.ec.europa.eu/questions-and-answers/further-information-about-dma_en?ref=sorena.io) - Practical submission channels and stakeholder interactions that often drive time-sensitive work. ## Related Topic Guides - [DMA Applicability Test (Gatekeeper Scoping) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/applicability-test.md): A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds. - [DMA Compliance Checklist (Execution-Ready) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/checklist.md): An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls. - [DMA Compliance Program & Monitoring (Compliance Function + Evidence)](/artifacts/eu/digital-markets-act/compliance-program-and-monitoring.md): How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness. - [DMA Do's and Don'ts for Product Teams | EU Digital Markets Act](/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams.md): Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes. - [DMA Enforcement: Penalties, Remedies, and Process | EU Digital Markets Act](/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies.md): How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies. - [DMA Fines & Penalties (10% / 20% / 1% + 5% per day) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/penalties-and-fines.md): A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%. - [DMA Obligations List (Articles 5, 6, 7) - By Obligation | EU Digital Markets Act](/artifacts/eu/digital-markets-act/core-obligations-by-obligation.md): A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores. - [DMA Self-Preferencing Compliance Examples (Article 6(5)) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples.md): Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what "transparent, fair. - [DMA vs DSA: What's the Difference? (EU Platform Laws)](/artifacts/eu/digital-markets-act/dma-vs-dsa.md): A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations. - [EU Digital Markets Act (DMA) Requirements (Articles 5-7)](/artifacts/eu/digital-markets-act/requirements.md): A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution. - [EU DMA Compliance Guide (How to Comply) | Digital Markets Act (DMA)](/artifacts/eu/digital-markets-act/compliance.md): A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations. - [EU DMA FAQ (Gatekeepers, Obligations, Deadlines) | Digital Markets Act](/artifacts/eu/digital-markets-act/faq.md): EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7). - [EU DMA Timeline & Key Milestones | Digital Markets Act (2022/1925)](/artifacts/eu/digital-markets-act/timeline-and-key-milestones.md): A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones. - [Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11)](/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist.md): A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report. - [Gatekeeper Designation Guide (DMA Article 3) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/gatekeeper-designation-guide.md): A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar --- --- title: "DMA vs DSA: What's the Difference? (EU Platform Laws)" canonical_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/dma-vs-dsa" source_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/dma-vs-dsa" author: "Sorena AI" description: "A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "DMA vs DSA" - "difference between DMA and DSA" - "Digital Markets Act vs Digital Services Act" - "EU platform regulation" - "gatekeeper regulation" - "online safety regulation EU" - "DMA obligations Articles 5 6 7" - "DSA obligations content moderation" - "Digital Markets Act" - "Digital Services Act" - "gatekeeper obligations" - "online safety compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DMA vs DSA: What's the Difference? (EU Platform Laws) A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations. *Artifact Guide* *EU* ## EU Platform Laws DMA vs DSA DMA governs gatekeeper fairness and contestability; DSA governs online safety and platform accountability. Use this comparison to structure responsibilities across product, policy, trust & safety, privacy, and platform engineering. DMA and DSA are often discussed together because both regulate large digital platforms in the EU - but they solve different problems. The DMA (Regulation (EU) 2022/1925) targets contestability and fairness for core platform services operated by designated gatekeepers. The DSA (Regulation (EU) 2022/2065) targets illegal content, transparency, and systemic risk management for online intermediaries and platforms. Many companies need both compliance programs at once. ## DMA vs DSA in one sentence DMA: competition/fairness law for designated gatekeepers and their core platform services (CPS), with product and access obligations (Articles 5-7) and a 6-month compliance clock after CPS listing. DSA: online safety/accountability law for intermediaries and platforms, with obligations around notice-and-action, transparency, risk assessment/mitigation (for very large platforms), and governance. - DMA is about market structure and business-user/end-user choice. - DSA is about illegal content, user protection, and transparency of platform operations. - Both impose documentation and governance expectations, but the operational teams differ (platform engineering vs trust & safety vs legal). *Recommended next step* *Placement: after the comparison section* ## Use EU Platform Laws DMA vs DSA as a cited research workflow Research Copilot can take EU Platform Laws DMA vs DSA from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Platform Laws can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Platform Laws DMA vs DSA](/solutions/research-copilot.md): Start from EU Platform Laws DMA vs DSA and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Platform Laws](/contact.md): Review your current process, evidence gaps, and next steps for EU Platform Laws DMA vs DSA. ## Who is in scope DMA scope hinges on gatekeeper designation and the CPS list (intermediation, search, social networking, OS, browsers, virtual assistants, cloud, ads, etc.). DSA scope hinges on the role as an intermediary service and, for higher tiers, platform size and systemic impact (including very large online platforms/search engines). - DMA is "designation-first" and CPS-specific: obligations attach to the listed CPS. - DSA is "service-role-first" and often applies broadly across the service (with tiered obligations). - A company can be a DMA gatekeeper for some CPS and still have separate DSA obligations for platform moderation and transparency. ## Obligations: what teams actually build DMA obligations are often implemented in platform infrastructure: choice screens, default settings, third-party app distribution, ranking neutrality, data portability, and interoperability interfaces. DSA obligations are often implemented in trust & safety systems: reporting, moderation workflows, transparency reporting, ad transparency, user redress, and risk controls. - DMA engineering workstreams: consent and data separation (Article 5(2)), ranking neutrality/self-preferencing controls (Article 6(5)), app store and OS distribution/choice (Article 6(3)-(4)), interoperability and access (Article 6(7), Article 7), portability and access APIs (Article 6(9)-(10)). - DSA workstreams: notice-and-action pipelines, content moderation tooling and audits, transparency reports, risk assessments/mitigations for very large services, and crisis response where applicable. - Overlap zones: ad transparency, recommender systems, and user choice can create combined requirements. ## Enforcement model differences (why compliance programs feel different) DMA enforcement is tied to gatekeeper conduct and measurable obligations; penalties include turnover-based fines and periodic penalty payments to compel compliance. DSA enforcement is tied to content governance and systemic risk outcomes; the operational focus is often audits, reporting, and risk mitigation. - DMA: 6-month compliance deadline after CPS listing; enforcement can include preliminary findings, non-compliance decisions, fines, and ongoing monitoring. - DSA: ongoing obligations with tiered requirements; enforcement emphasises transparency, risk management processes, and operational effectiveness. - In practice: DMA compliance is heavily product/engineering driven; DSA compliance is heavily trust & safety, policy, and governance driven. ## How to run a combined DMA + DSA compliance program (practical operating model) The best combined program avoids duplicated governance by separating shared controls (documentation, evidence, change control) from domain-specific controls (ranking and access vs content moderation). Use a single evidence library with different "views" for DMA and DSA reporting, and align escalation paths so product changes don't break compliance. - Shared layer: change control, evidence standards, incident response for compliance regressions, and executive reporting. - DMA layer: CPS-by-CPS obligation mapping, interoperability/portability SLAs, ranking governance, and compliance report evidence (Article 11). - DSA layer: trust & safety operations, transparency reporting, risk assessment/mitigation (where applicable), and user redress workflows. - Cross-functional mapping: recommender and ad systems often touch both laws - treat them as shared technical domains. ## Primary sources - [Regulation (EU) 2022/1925 (Digital Markets Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - DMA legal basis: gatekeeper designation, CPS scope, and obligations (Articles 5-7). - [Regulation (EU) 2022/2065 (Digital Services Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/2065/oj?ref=sorena.io) - DSA legal basis: platform obligations around online intermediary services, transparency, and online safety. - [European Commission - Gatekeepers list and designated core platform services](https://digital-markets-act.ec.europa.eu/gatekeepers_en?ref=sorena.io) - Concrete DMA gatekeeper/CPS examples used to explain DMA scope in practice. ## Related Topic Guides - [DMA Applicability Test (Gatekeeper Scoping) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/applicability-test.md): A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds. - [DMA Compliance Checklist (Execution-Ready) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/checklist.md): An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls. - [DMA Compliance Program & Monitoring (Compliance Function + Evidence)](/artifacts/eu/digital-markets-act/compliance-program-and-monitoring.md): How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness. - [DMA Deadlines & Compliance Calendar (Key Dates) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar.md): A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline. - [DMA Do's and Don'ts for Product Teams | EU Digital Markets Act](/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams.md): Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes. - [DMA Enforcement: Penalties, Remedies, and Process | EU Digital Markets Act](/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies.md): How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies. - [DMA Fines & Penalties (10% / 20% / 1% + 5% per day) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/penalties-and-fines.md): A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%. - [DMA Obligations List (Articles 5, 6, 7) - By Obligation | EU Digital Markets Act](/artifacts/eu/digital-markets-act/core-obligations-by-obligation.md): A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores. - [DMA Self-Preferencing Compliance Examples (Article 6(5)) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples.md): Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what "transparent, fair. - [EU Digital Markets Act (DMA) Requirements (Articles 5-7)](/artifacts/eu/digital-markets-act/requirements.md): A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution. - [EU DMA Compliance Guide (How to Comply) | Digital Markets Act (DMA)](/artifacts/eu/digital-markets-act/compliance.md): A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations. - [EU DMA FAQ (Gatekeepers, Obligations, Deadlines) | Digital Markets Act](/artifacts/eu/digital-markets-act/faq.md): EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7). - [EU DMA Timeline & Key Milestones | Digital Markets Act (2022/1925)](/artifacts/eu/digital-markets-act/timeline-and-key-milestones.md): A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones. - [Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11)](/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist.md): A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report. - [Gatekeeper Designation Guide (DMA Article 3) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/gatekeeper-designation-guide.md): A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-markets-act/dma-vs-dsa --- --- title: "DMA Do's and Don'ts for Product Teams" canonical_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams" source_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams" author: "Sorena AI" description: "Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "DMA do and dont" - "DMA product teams" - "Digital Markets Act product requirements" - "choice screen DMA" - "default settings DMA" - "DMA self-preferencing" - "DMA third-party app stores" - "DMA data portability" - "Article 11 compliance report evidence" - "DMA product playbook" - "choice screen" - "self-preferencing" - "third-party app stores" - "data portability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DMA Do's and Don'ts for Product Teams Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes. *Artifact Guide* *EU* ## EU Digital Markets Act (DMA) Do's and Don'ts for Product Teams A practical playbook for building DMA compliance into product and engineering decisions. Optimised for teams shipping within the 6-month post-designation deadline and documenting evidence for Article 11. DMA compliance becomes real in product decisions: ranking changes, default settings, app distribution flows, consent prompts, and APIs. This playbook focuses on what product and engineering teams should do (and avoid) when building DMA changes per core platform service (CPS). ## Do: treat DMA as product requirements per CPS DMA obligations attach to each core platform service (CPS) listed in the designation decision. That means compliance must be implemented and tested per CPS surface, not just declared in policy. Use a CPS-by-CPS requirements doc that maps Articles 5-7 obligations to features, owners, and acceptance criteria. - Create an obligation-to-feature map per CPS and track it in your product backlog. - Define measurable acceptance criteria (e.g., default change succeeds, uninstall path works, portability export completes, request SLAs met). - Add a DMA review gate to launches that affect ranking, discovery, distribution, identity, payments, consent, and cross-service data flows. ## Don't: bury preferential treatment in ranking, indexing, or experiments DMA Article 6(5) prohibits self-preferencing in ranking and requires transparent, fair, non-discriminatory conditions. Self-preferencing often hides in "harmless" experiments and hand-tuned boosts. If you cannot explain ranking changes, you cannot defend them. - Avoid hard-coded boosts/whitelists for first-party content, services, or products. - Avoid asymmetric eligibility rules (faster indexing, looser quality thresholds) for first-party offerings. - Do build ranking governance: feature/parameter registry, experiment approvals, parity tests, and monitoring. ## Do: build real choice (defaults, uninstall, and distribution) DMA Article 6 includes obligations that drive UX and OS/app-store changes: uninstallability, default settings and choice prompts, and enabling third-party apps/app stores. These obligations are best implemented with testable flows and clear logging so you can prove effectiveness. - Implement easy uninstall of apps (except those essential to OS/device functioning). - Enable easy default changes; prompt end users at first use to choose among main providers for search engine, virtual assistant, and browser where applicable. - Enable installation and effective use of third-party apps and app stores using/interoperating with the OS, including access by means other than the gatekeeper CPS, subject to strictly necessary and proportionate integrity/security measures. ## Don't: treat consent/data combination as a UI problem only DMA Article 5(2) restricts combining/cross-using personal data across services without specific choice and consent; it also limits repeated requests if consent is refused or withdrawn. This is a systems problem: data pipelines, identity graphs, consent state storage, and enforcement in downstream processing. - Avoid "binary choice" designs that effectively force consent to combine data as a condition to use the service's core value. - Do implement consent enforcement in data systems (not just in UI): gating, audit logs, and testing of downstream usage. - Do design "less personalised but equivalent" experiences where relevant and measurable. ## Do: treat portability and access as APIs with SLAs Article 6 requires effective data portability for end users and continuous/real-time access to data, plus data access for business users (with consent constraints for personal data). Build this like a platform capability: APIs, documentation, rate limits, monitoring, and support processes. - Portability tooling: continuous and real-time access, export formats, and clear documentation. - Business-user data access: high-quality, continuous, real-time access to aggregated and non-aggregated data generated in CPS use; personal data sharing only with end-user opt-in consent. - Operational readiness: observability, error budgets, and an escalation path when portability/access fails. ## Do: capture evidence as you ship (Article 11 compliance report ready) The Commission's Article 11 compliance report template expects detailed explanations of measures per CPS and per obligation, supported by data, internal docs, and often recorded demos. If evidence capture is an afterthought, compliance becomes a documentation scramble. - Record prior state vs new state: screenshots, flows, API docs, and change logs. - Capture implementation metadata: implementation date, scope (products/devices), geographic scope, and engineering details (APIs, ranking parameters, security measures). - Keep underlying raw data ready and store evidence in machine-readable formats where possible. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU Digital Markets Act (DMA) Do's and Don'ts for Product Teams as a cited research workflow Research Copilot can take EU Digital Markets Act (DMA) Do's and Don'ts for Product Teams from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU Digital Markets Act (DMA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Digital Markets Act (DMA) Do's and Don'ts for Product Teams](/solutions/research-copilot.md): Start from EU Digital Markets Act (DMA) Do's and Don'ts for Product Teams and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Digital Markets Act (DMA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Markets Act (DMA) Do's and Don'ts for Product Teams. ## Primary sources - [Regulation (EU) 2022/1925 (Digital Markets Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - Obligations in Articles 5-7 that drive product and engineering requirements (choice, ranking, data, interoperability). - [European Commission - Article 11 DMA Compliance Report Template (9 Oct 2023)](https://digital-markets-act.ec.europa.eu/about-dma/practical-information_en#templates?ref=sorena.io) - Evidence expectations (engineering changes, UX changes, demos, and data) for compliance reporting. - [European Commission - Interoperability (Questions and Answers)](https://digital-markets-act.ec.europa.eu/questions-and-answers/interoperability_en?ref=sorena.io) - Example of how interoperability expectations can be specified in detail and tracked through timelines. - [European Commission - Resources for businesses](https://digital-markets-act.ec.europa.eu/questions-and-answers/resources-businesses_en?ref=sorena.io) - Practical developer/business resources relevant to implementing portability and interoperability flows. ## Related Topic Guides - [DMA Applicability Test (Gatekeeper Scoping) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/applicability-test.md): A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds. - [DMA Compliance Checklist (Execution-Ready) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/checklist.md): An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls. - [DMA Compliance Program & Monitoring (Compliance Function + Evidence)](/artifacts/eu/digital-markets-act/compliance-program-and-monitoring.md): How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness. - [DMA Deadlines & Compliance Calendar (Key Dates) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar.md): A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline. - [DMA Enforcement: Penalties, Remedies, and Process | EU Digital Markets Act](/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies.md): How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies. - [DMA Fines & Penalties (10% / 20% / 1% + 5% per day) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/penalties-and-fines.md): A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%. - [DMA Obligations List (Articles 5, 6, 7) - By Obligation | EU Digital Markets Act](/artifacts/eu/digital-markets-act/core-obligations-by-obligation.md): A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores. - [DMA Self-Preferencing Compliance Examples (Article 6(5)) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples.md): Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what "transparent, fair. - [DMA vs DSA: What's the Difference? (EU Platform Laws)](/artifacts/eu/digital-markets-act/dma-vs-dsa.md): A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations. - [EU Digital Markets Act (DMA) Requirements (Articles 5-7)](/artifacts/eu/digital-markets-act/requirements.md): A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution. - [EU DMA Compliance Guide (How to Comply) | Digital Markets Act (DMA)](/artifacts/eu/digital-markets-act/compliance.md): A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations. - [EU DMA FAQ (Gatekeepers, Obligations, Deadlines) | Digital Markets Act](/artifacts/eu/digital-markets-act/faq.md): EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7). - [EU DMA Timeline & Key Milestones | Digital Markets Act (2022/1925)](/artifacts/eu/digital-markets-act/timeline-and-key-milestones.md): A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones. - [Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11)](/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist.md): A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report. - [Gatekeeper Designation Guide (DMA Article 3) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/gatekeeper-designation-guide.md): A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams --- --- title: "DMA Enforcement: Penalties, Remedies, and Process" canonical_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies" source_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies" author: "Sorena AI" description: "How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "DMA enforcement" - "Digital Markets Act enforcement" - "DMA penalties" - "DMA fines 10% 20%" - "DMA periodic penalty payments 5% per day" - "DMA remedies" - "DMA interim measures" - "DMA commitments" - "non-compliance decision DMA" - "DMA fines" - "non-compliance decision" - "periodic penalty payments" - "Commission preliminary findings" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DMA Enforcement: Penalties, Remedies, and Process How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies. *Artifact Guide* *EU* ## EU Digital Markets Act (DMA) Enforcement, Penalties & Remedies Understand enforcement mechanics and what "effective compliance" looks like to the Commission. Built for practitioners: triggers, timelines, evidence expectations, and how fines/remedies escalate. DMA enforcement is not hypothetical: it is a structured process with information requests, preliminary findings, decisions, and escalating remedies. The safest compliance programs are designed backward from enforcement: what evidence can we produce, how quickly, and how do we prove our implementation is effective (not just documented)? ## Enforcement triggers: how DMA issues become cases DMA cases can start from gatekeeper notifications and compliance reporting, Commission monitoring, stakeholder submissions, or observable product practices. Third parties (business users, competitors, end users) can inform national competent authorities or the Commission about practices that fall within DMA scope. - Common trigger themes: consent/data combination (Article 5(2)), self-preferencing in ranking (Article 6(5)), app distribution and defaults (Article 6(3)-(4)), interoperability and access to OS features (Article 6(7)), and messaging interoperability (Article 7). - A single CPS listing can create multiple enforcement threads: one for each obligation cluster. - Design intake and triage: map every complaint to CPS + obligation + evidence gap. *Recommended next step* *Placement: after the enforcement section* ## Use EU Digital Markets Act (DMA) Enforcement, Penalties & Remedies as a cited research workflow Research Copilot can take EU Digital Markets Act (DMA) Enforcement, Penalties & Remedies from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Digital Markets Act (DMA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Digital Markets Act (DMA) Enforcement, Penalties & Remedies](/solutions/research-copilot.md): Start from EU Digital Markets Act (DMA) Enforcement, Penalties & Remedies and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Digital Markets Act (DMA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Markets Act (DMA) Enforcement, Penalties & Remedies. ## The enforcement workflow: from proceedings to non-compliance decisions The DMA includes a formal enforcement path where the Commission can open proceedings, communicate preliminary findings, consult third parties, and adopt a non-compliance decision ordering the gatekeeper to cease and desist within a deadline. The Commission endeavours to adopt a non-compliance decision within 12 months from the opening of proceedings. - Preliminary findings step: the Commission communicates preliminary findings and explains measures it is considering or expects the gatekeeper to take. - Non-compliance decision: can order the gatekeeper to stop the behaviour and explain how it will comply; gatekeeper must describe measures taken. - Commitments path: during proceedings, gatekeepers may offer commitments; the Commission may make them binding and close the case if satisfied. ## Tools before a final decision: monitoring and interim measures DMA enforcement is supported by monitoring powers and, in urgent cases, interim measures. These mechanisms matter because they influence what you must be able to produce quickly: documents, data, explanations, and operational controls. - Monitoring: the Commission can monitor implementation of obligations and decisions, including imposing document retention obligations and appointing independent experts/auditors. - Interim measures: in urgency (risk of serious and irreparable damage), the Commission may order interim measures via implementing act based on a prima facie finding of an infringement of Articles 5-7. - Inspections and information requests: be prepared for requests that require access to data, algorithms, and information about testing. ## Penalties: fines and periodic penalty payments (the money part) DMA penalties are designed to be material at gatekeeper scale. There are fines for non-compliance and separate fines for procedural failures (e.g., misleading information or failure to notify). Periodic penalty payments can be used to compel compliance on a daily basis. - Non-compliance fines: up to 10% of total worldwide turnover in the preceding financial year for failing to comply with obligations in Articles 5-7 (and related measures/remedies/interim measures/commitments). - Repeat infringements: up to 20% of total worldwide turnover if the same or similar infringement occurs within 8 years for the same CPS after a prior non-compliance decision. - Procedural fines: up to 1% of total worldwide turnover for failures such as not providing required information for designation, supplying incorrect/misleading information, or failing to notify under Article 3(3). - Periodic penalty payments: up to 5% of the average daily worldwide turnover per day to compel compliance with specific decisions and requests. ## Remedies: what "effective compliance" can require beyond toggles DMA remedies aim at effective compliance and contestability. A "paper compliance" program that does not change outcomes will be fragile under scrutiny. You should be able to explain-obligation by obligation-how your implementation achieves the DMA objective, what tradeoffs were made, and why any restrictions are necessary and proportionate. - Product remedies: redesign choice screens, ranking and recommendation policies, data-sharing controls, app distribution flows, and interoperability interfaces. - Commercial remedies: adjust terms, fees, access conditions, and dispute mechanisms for business users on app stores/search/social networks. - Operational remedies: improve monitoring, incident-style response for compliance regressions, and evidence capture aligned to the Article 11 report template. ## Systematic non-compliance: when DMA cases escalate into market investigation remedies Article 18 is the DMA escalation path for repeated failure. It is not just about another fine; it allows the Commission to investigate whether repeated infringements have maintained, strengthened, or extended gatekeeper power. This matters because a gatekeeper can move from obligation-level remediation into behavioral or structural remedies if the Commission sees a pattern rather than an isolated miss. - A gatekeeper is deemed to have engaged in systematic non-compliance where the Commission has issued at least 3 non-compliance decisions within 8 years in relation to any of its CPS. - The Commission aims to conclude that market investigation within 12 months, subject to limited extensions on objective grounds. - Possible remedies include behavioral measures and structural measures that are proportionate and necessary to ensure effective compliance. - The remedy toolkit can also include a temporary ban on certain concentrations in affected digital services where that is needed to restore fairness and contestability. ## How to prepare: enforcement-ready compliance evidence checklist The best defense is an evidence library that makes your compliance explainable, reproducible, and testable. Align your evidence to the Commission's Article 11 compliance report template: it anticipates the kinds of questions enforcement teams will ask. - Per CPS and per obligation: prior state, implementation date, scope, engineering changes, UX changes, and the business/user impact. - Proof of effectiveness: metrics and testing results (e.g., default setting changes actually take effect; portability APIs work; ranking neutrality tests pass). - Decision log: integrity/security restrictions with proportionality justification and alternatives considered. ## Primary sources - [Regulation (EU) 2022/1925 (Digital Markets Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - Enforcement procedure, monitoring powers, fines (Article 30), and periodic penalty payments (Article 31). - [European Commission - Preliminary findings example (Meta "Pay or Consent", 1 Jul 2024)](https://digital-markets-act.ec.europa.eu/commission-sends-preliminary-findings-meta-over-its-pay-or-consent-model-breach-digital-markets-act-2024-07-01_en?ref=sorena.io) - Example of the preliminary findings stage and enforcement narrative tied to Article 5(2) consent/data combination obligations. - [European Commission - Article 11 DMA Compliance Report Template (9 Oct 2023)](https://digital-markets-act.ec.europa.eu/about-dma/practical-information_en#templates?ref=sorena.io) - Evidence and reporting expectations that influence enforcement readiness. - [European Commission - Whistleblower Tool](https://digital-markets-act.ec.europa.eu/whistleblower-tool_en?ref=sorena.io) - Channel for reporting suspected DMA violations (relevant to enforcement triggers). ## Related Topic Guides - [DMA Applicability Test (Gatekeeper Scoping) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/applicability-test.md): A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds. - [DMA Compliance Checklist (Execution-Ready) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/checklist.md): An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls. - [DMA Compliance Program & Monitoring (Compliance Function + Evidence)](/artifacts/eu/digital-markets-act/compliance-program-and-monitoring.md): How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness. - [DMA Deadlines & Compliance Calendar (Key Dates) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar.md): A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline. - [DMA Do's and Don'ts for Product Teams | EU Digital Markets Act](/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams.md): Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes. - [DMA Fines & Penalties (10% / 20% / 1% + 5% per day) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/penalties-and-fines.md): A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%. - [DMA Obligations List (Articles 5, 6, 7) - By Obligation | EU Digital Markets Act](/artifacts/eu/digital-markets-act/core-obligations-by-obligation.md): A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores. - [DMA Self-Preferencing Compliance Examples (Article 6(5)) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples.md): Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what "transparent, fair. - [DMA vs DSA: What's the Difference? (EU Platform Laws)](/artifacts/eu/digital-markets-act/dma-vs-dsa.md): A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations. - [EU Digital Markets Act (DMA) Requirements (Articles 5-7)](/artifacts/eu/digital-markets-act/requirements.md): A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution. - [EU DMA Compliance Guide (How to Comply) | Digital Markets Act (DMA)](/artifacts/eu/digital-markets-act/compliance.md): A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations. - [EU DMA FAQ (Gatekeepers, Obligations, Deadlines) | Digital Markets Act](/artifacts/eu/digital-markets-act/faq.md): EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7). - [EU DMA Timeline & Key Milestones | Digital Markets Act (2022/1925)](/artifacts/eu/digital-markets-act/timeline-and-key-milestones.md): A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones. - [Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11)](/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist.md): A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report. - [Gatekeeper Designation Guide (DMA Article 3) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/gatekeeper-designation-guide.md): A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies --- --- title: "EU DMA FAQ (Gatekeepers, Obligations, Deadlines)" canonical_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/faq" source_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/faq" author: "Sorena AI" description: "EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7)." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU DMA FAQ" - "Digital Markets Act FAQ" - "what is a gatekeeper DMA" - "core platform service CPS definition" - "DMA obligations Article 5 6 7" - "DMA deadlines 2 months 45 working days 6 months" - "Article 11 compliance report" - "how to contact Commission DMA" - "DMA FAQ" - "gatekeeper designation" - "core platform services" - "DMA obligations" - "DMA deadlines" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DMA FAQ (Gatekeepers, Obligations, Deadlines) EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7). *Artifact Guide* *EU* ## EU Digital Markets Act (DMA) FAQ Fast answers to common DMA questions (scope, obligations, deadlines, reporting). Grounded in the legal text and Commission guidance pages and templates. This DMA FAQ focuses on the questions people actually search for: gatekeeper designation, what a core platform service is, what obligations apply, what the key deadlines are, what evidence is expected, and how to use official Commission resources and submission channels. ## What is a DMA gatekeeper? A gatekeeper is an undertaking providing core platform services (CPS) that is designated pursuant to DMA Article 3. Gatekeeper status is tied to specific CPS listed in the designation decision, not just the company in the abstract. - Designation hinges on market impact, gateway role, and an entrenched/durable position (Article 3). - Quantitative thresholds create a presumption (e.g., EUR 7.5B EU turnover / EUR 75B market cap, 45M monthly active end users, 10,000 yearly active business users). - The Commission publishes and updates a public list of designated gatekeepers and their listed CPS. ## What counts as a core platform service (CPS)? The DMA defines CPS categories explicitly (Article 2). CPS mapping is a practical engineering task: your CPS boundaries should match how systems ship and how users experience them. - CPS categories include: online intermediation services, online search engines, online social networking services, video-sharing platform services, number-independent interpersonal communications services, operating systems, web browsers, virtual assistants, cloud computing services, and online advertising services linked to those CPS categories. - Obligations apply per listed CPS - if you operate multiple CPS, implementation workstreams differ per CPS. - Document CPS boundaries and dependencies (ranking, ads stack, APIs, data sharing) for defensible compliance. ## What are the key DMA deadlines? Three deadlines drive most execution planning: notification (2 months), designation (45 working days), and compliance (6 months after listing). Messaging interoperability (Article 7) has additional staged timelines (2 years / 4 years) for certain functionalities. - Notify the Commission within 2 months after thresholds are met (Article 3(3)). - Commission designation deadline: within 45 working days after receiving complete information (Article 3(4)). - Compliance deadline: comply with Articles 5-7 within 6 months after the CPS is listed in the designation decision (Article 3(10)). - Article 7: staged interoperability deadlines within 2 years and 4 years from designation for group messaging and calling features. ## How many gatekeepers and core platform services are currently designated? As of 6 March 2026, the Commission's public DMA gatekeeper page lists 7 designated gatekeepers and 23 designated core platform services. That public list is useful because it shows that designation is service specific and can change over time as the Commission reviews evidence. - Initial designations on 6 Sep 2023 covered 6 gatekeepers. - Apple iPadOS was added on 29 Apr 2024 and Booking.com was added on 13 May 2024. - Meta's Facebook Marketplace was undesignated on 23 Apr 2025. - On 5 Feb 2026, the Commission concluded Apple Ads and Apple Maps should not be designated after Apple had notified those services. ## What are the main obligations under the DMA? The core obligation set for gatekeepers is in Articles 5, 6, and 7. In practice, these obligations translate into product requirements (choice screens, default settings), platform access requirements (third-party apps/app stores, API access), and data requirements (portability and data separation). - Article 5: constraints on personal data combination for ads (consent requirements), anti-steering obligations, and bans on tying to gatekeeper services (e.g., payment services). - Article 6: uninstall and default setting changes, enabling third-party app distribution/app stores, ranking neutrality (no self-preferencing), data portability and business-user data access, and interoperability/access to OS features (Article 6(7)). - Article 7: request-based interoperability for number-independent interpersonal communications services with staged feature timelines. ## What is the Article 11 compliance report and what evidence is expected? The Commission provides a template form for reporting pursuant to Article 11 (compliance report). It explains the minimum information gatekeepers should provide and expects detailed, transparent explanations. The template expects per CPS and per applicable obligation: a compliance statement and an exhaustive explanation, with supporting data and internal documents (often including demos and illustrations). - Plan evidence early: capture prior state, implementation dates, scope, and engineering/UX changes as you ship. - Keep underlying raw data ready for requests and store evidence in machine-readable formats where possible. - Update cadence: the template guidance states compliance reports are updated at least annually. ## How do I contact the Commission or submit DMA-related information? The Commission's DMA Q&A page provides practical contact guidance for questions, submissions, and meeting requests. For secure document transmission, the Commission references EU SEND as a secure exchange platform. - General DMA questions, submissions, and meeting requests: use the Commission contact guidance on the DMA Q&A page and the DMA registry details published on the practical information pages. - Secure document transmission: use EU SEND and include relevant DMA case references where applicable. - Stakeholder reports: third parties can inform national competent authorities or the Commission about practices that fall within DMA scope. *Recommended next step* *Placement: after the FAQ section* ## Use EU Digital Markets Act (DMA) FAQ as a cited research workflow Research Copilot can take EU Digital Markets Act (DMA) FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU Digital Markets Act (DMA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Digital Markets Act (DMA) FAQ](/solutions/research-copilot.md): Start from EU Digital Markets Act (DMA) FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Digital Markets Act (DMA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Markets Act (DMA) FAQ. ## Primary sources - [Regulation (EU) 2022/1925 (Digital Markets Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - Definitions (Article 2), gatekeeper designation timelines (Article 3), obligations (Articles 5-7), and compliance function (Article 28). - [European Commission - Further information about the DMA (Q&A)](https://digital-markets-act.ec.europa.eu/questions-and-answers/further-information-about-dma_en?ref=sorena.io) - Practical guidance on contacts, submissions, and secure transmission channels. - [European Commission - Gatekeepers list and designated core platform services](https://digital-markets-act.ec.europa.eu/gatekeepers_en?ref=sorena.io) - Public list of designated gatekeepers and CPS listings (helpful for scope examples). - [European Commission - Article 11 DMA Compliance Report Template (9 Oct 2023)](https://digital-markets-act.ec.europa.eu/about-dma/practical-information_en#templates?ref=sorena.io) - Compliance report structure and evidence expectations. - [DG Competition - EU SEND secure document exchange platform](https://competition-policy.ec.europa.eu/index/it-tools/eu-send_en?ref=sorena.io) - Secure document submission platform referenced for DMA-related exchanges. ## Related Topic Guides - [DMA Applicability Test (Gatekeeper Scoping) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/applicability-test.md): A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds. - [DMA Compliance Checklist (Execution-Ready) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/checklist.md): An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls. - [DMA Compliance Program & Monitoring (Compliance Function + Evidence)](/artifacts/eu/digital-markets-act/compliance-program-and-monitoring.md): How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness. - [DMA Deadlines & Compliance Calendar (Key Dates) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar.md): A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline. - [DMA Do's and Don'ts for Product Teams | EU Digital Markets Act](/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams.md): Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes. - [DMA Enforcement: Penalties, Remedies, and Process | EU Digital Markets Act](/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies.md): How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies. - [DMA Fines & Penalties (10% / 20% / 1% + 5% per day) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/penalties-and-fines.md): A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%. - [DMA Obligations List (Articles 5, 6, 7) - By Obligation | EU Digital Markets Act](/artifacts/eu/digital-markets-act/core-obligations-by-obligation.md): A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores. - [DMA Self-Preferencing Compliance Examples (Article 6(5)) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples.md): Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what "transparent, fair. - [DMA vs DSA: What's the Difference? (EU Platform Laws)](/artifacts/eu/digital-markets-act/dma-vs-dsa.md): A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations. - [EU Digital Markets Act (DMA) Requirements (Articles 5-7)](/artifacts/eu/digital-markets-act/requirements.md): A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution. - [EU DMA Compliance Guide (How to Comply) | Digital Markets Act (DMA)](/artifacts/eu/digital-markets-act/compliance.md): A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations. - [EU DMA Timeline & Key Milestones | Digital Markets Act (2022/1925)](/artifacts/eu/digital-markets-act/timeline-and-key-milestones.md): A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones. - [Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11)](/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist.md): A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report. - [Gatekeeper Designation Guide (DMA Article 3) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/gatekeeper-designation-guide.md): A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-markets-act/faq --- --- title: "Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11)" canonical_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist" source_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist" author: "Sorena AI" description: "A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "gatekeeper compliance checklist DMA" - "DMA gatekeeper checklist" - "Article 11 compliance report checklist" - "Article 28 compliance function" - "DMA 6 month compliance deadline" - "DMA obligations checklist Articles 5 6 7" - "CPS compliance checklist" - "gatekeeper compliance checklist" - "DMA compliance checklist" - "Article 11 compliance report" - "CPS compliance" - "DMA monitoring" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11) A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report. *Artifact Guide* *EU* ## EU Digital Markets Act (DMA) Gatekeeper Compliance Checklist A checklist for designated gatekeepers to deliver effective compliance per listed CPS. Optimised for the 6-month compliance clock and Article 11 evidence requirements. If you are designated as a DMA gatekeeper (for one or more core platform services), your biggest risks are timing and proof: implementing within the 6-month deadline and being able to demonstrate effective compliance with evidence. This checklist is designed to be run per CPS and aligned to the Commission's Article 11 compliance report template. ## Phase 0 - Immediately after designation: lock CPS scope and owners DMA obligations attach to the CPS listed in the designation decision. If CPS boundaries are unclear internally, compliance will be inconsistent and difficult to defend. Start by building a CPS-by-CPS accountability model: owners, impacted features, and an evidence library structure. - Confirm the list of designated CPS and map each CPS to technical systems, teams, and product surfaces. - Assign a product owner and a policy/legal owner per CPS; assign an evidence owner who manages artifacts for Article 11 reporting. - Create an obligation-to-feature map per CPS for Articles 5-7 and identify "high-impact obligations" that require product change. ## Phase 1 - Build the compliance program (Article 28) and reporting pipeline The DMA requires an independent compliance function with sufficient authority, resources, and direct reporting to the management body. Build the reporting pipeline early: the Article 11 compliance report is easiest when evidence is captured as changes ship. - Stand up the compliance function (independent from operations) with a head of compliance and clear responsibilities, reporting line, and annual review cadence. - Create a "DMA change control" gate for CPS changes: ranking parameters, default settings, app store policies, interoperability APIs, and ads measurement. - Adopt an evidence standard: machine-readable where possible, versioned, with clear mapping to CPS + obligation. ## Phase 2 - Deliver Articles 5-7 obligations within 6 months The 6-month compliance deadline is a delivery schedule. Break it into release milestones that ship functionality and evidence in parallel. Treat the obligations as clusters so teams can parallelise workstreams. - Data and consent cluster (Article 5(2), Article 6(2), Article 6(10)): data combination controls, opt-in gates, data access parity, and audit logs. - Choice and distribution cluster (Article 6(3)-(4)): uninstall flows, default-setting changes and choice prompts, third-party app stores and app distribution paths, integrity/security exceptions with justification. - Ranking fairness cluster (Article 6(5)): remove preferential treatment, implement ranking governance, create parity tests and monitoring. - Portability and access cluster (Article 6(9)-(10)): portability tools and continuous/real-time access, documentation, and operational support. - Interoperability cluster (Article 6(7), Article 7 where applicable): API access parity, request workflows, reference offers, and SLAs. ## Phase 3 - Article 11 compliance report: the minimum evidence pack The Commission's Article 11 compliance report template expects, per CPS and per applicable obligation, a compliance statement and an exhaustive explanation including supporting data and internal documents. Build your evidence pack to answer: what changed, when, where, why it is compliant, and how you ensure it stays compliant. - For each measure: prior state, implementation date, product/service/device scope, geographic scope, and technical/engineering changes (APIs, OS features, ranking parameters, security aspects). - For each measure: UX changes (choice screens, consent forms, warning messages, customer journey changes) with recorded demos where relevant. - Underlying data readiness: store raw data and metrics that support claims (e.g., default changes take effect; portability APIs succeed; interoperability requests meet SLAs). ## Phase 4 - Continuous monitoring and enforcement readiness The Commission can monitor implementation and may require retention of documents relevant to assessing compliance; it can also appoint independent experts/auditors. Your job is to prevent regressions and answer questions quickly with evidence, not ad hoc narratives. - Monitoring checks: automated tests for choice screens, uninstall flows, ranking neutrality, API access parity, portability output correctness, and consent gate enforcement. - Incident response for DMA: define how you triage, mitigate, roll back, and communicate compliance-impacting regressions. - Stakeholder intake: centralise developer/business-user requests (especially interoperability and access requests) and track them with clear SLAs and escalation paths. *Recommended next step* *Placement: after the checklist block* ## Turn EU Digital Markets Act (DMA) Gatekeeper Compliance Checklist into an operational assessment Assessment Autopilot can take EU Digital Markets Act (DMA) Gatekeeper Compliance Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Digital Markets Act (DMA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Digital Markets Act (DMA) Gatekeeper Compliance Checklist](/solutions/assessment.md): Start from EU Digital Markets Act (DMA) Gatekeeper Compliance Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Digital Markets Act (DMA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Markets Act (DMA) Gatekeeper Compliance Checklist. ## Primary sources - [Regulation (EU) 2022/1925 (Digital Markets Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - 6-month compliance deadline after CPS listing (Article 3(10)), obligations baseline (Articles 5-7), and compliance function requirements (Article 28). - [European Commission - Article 11 DMA Compliance Report Template (9 Oct 2023)](https://digital-markets-act.ec.europa.eu/about-dma/practical-information_en#templates?ref=sorena.io) - Detailed evidence expectations for measures demonstrating compliance per CPS and per obligation. - [European Commission - Resources for businesses](https://digital-markets-act.ec.europa.eu/questions-and-answers/resources-businesses_en?ref=sorena.io) - Technical resources and request portals that become operational compliance surfaces for gatekeepers. - [European Commission - Gatekeepers list and designated core platform services](https://digital-markets-act.ec.europa.eu/gatekeepers_en?ref=sorena.io) - CPS scope examples for setting up CPS-by-CPS ownership and evidence structures. ## Related Topic Guides - [DMA Applicability Test (Gatekeeper Scoping) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/applicability-test.md): A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds. - [DMA Compliance Checklist (Execution-Ready) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/checklist.md): An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls. - [DMA Compliance Program & Monitoring (Compliance Function + Evidence)](/artifacts/eu/digital-markets-act/compliance-program-and-monitoring.md): How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness. - [DMA Deadlines & Compliance Calendar (Key Dates) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar.md): A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline. - [DMA Do's and Don'ts for Product Teams | EU Digital Markets Act](/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams.md): Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes. - [DMA Enforcement: Penalties, Remedies, and Process | EU Digital Markets Act](/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies.md): How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies. - [DMA Fines & Penalties (10% / 20% / 1% + 5% per day) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/penalties-and-fines.md): A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%. - [DMA Obligations List (Articles 5, 6, 7) - By Obligation | EU Digital Markets Act](/artifacts/eu/digital-markets-act/core-obligations-by-obligation.md): A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores. - [DMA Self-Preferencing Compliance Examples (Article 6(5)) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples.md): Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what "transparent, fair. - [DMA vs DSA: What's the Difference? (EU Platform Laws)](/artifacts/eu/digital-markets-act/dma-vs-dsa.md): A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations. - [EU Digital Markets Act (DMA) Requirements (Articles 5-7)](/artifacts/eu/digital-markets-act/requirements.md): A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution. - [EU DMA Compliance Guide (How to Comply) | Digital Markets Act (DMA)](/artifacts/eu/digital-markets-act/compliance.md): A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations. - [EU DMA FAQ (Gatekeepers, Obligations, Deadlines) | Digital Markets Act](/artifacts/eu/digital-markets-act/faq.md): EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7). - [EU DMA Timeline & Key Milestones | Digital Markets Act (2022/1925)](/artifacts/eu/digital-markets-act/timeline-and-key-milestones.md): A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones. - [Gatekeeper Designation Guide (DMA Article 3) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/gatekeeper-designation-guide.md): A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist --- --- title: "Gatekeeper Designation Guide (DMA Article 3)" canonical_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/gatekeeper-designation-guide" source_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/gatekeeper-designation-guide" author: "Sorena AI" description: "A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B)." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "DMA gatekeeper designation guide" - "Digital Markets Act Article 3" - "DMA thresholds 45 million" - "DMA thresholds 10" - "000 business users" - "DMA notification within 2 months" - "DMA designation 45 working days" - "core platform services CPS" - "gatekeeper designation process EU" - "DMA gatekeeper designation" - "core platform services" - "DMA thresholds" - "Commission designation" - "DMA notification" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Gatekeeper Designation Guide (DMA Article 3) A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B). *Artifact Guide* *EU* ## EU Digital Markets Act (DMA) Gatekeeper Designation Guide How gatekeeper designation works under DMA Article 3 (and how to prepare). CPS boundaries, threshold screening, notification timeline, Commission designation decision, and the 6-month compliance clock. Gatekeeper designation is the pivot point for DMA implementation. Once a core platform service (CPS) is listed in a designation decision, the 6-month compliance clock starts for Articles 5-7. This guide helps you scope CPS boundaries, run the quantitative threshold test, prepare defensible submissions, and build an implementation timeline you can execute. ## 1) Define your core platform service (CPS) boundaries first DMA designation is not just about company size; it is about specific core platform services (CPS). The designation decision lists which CPS are covered, and obligations attach to each listed CPS. Start with a CPS inventory that matches how your systems ship: user journeys, authentication surfaces, ranking, ads stack components, developer APIs, and cross-service data sharing points. - CPS categories include: online intermediation services, online search engines, online social networking services, video-sharing platform services, number-independent interpersonal communications services, operating systems, web browsers, virtual assistants, cloud computing services, and online advertising services linked to those CPS categories. - Write an explicit boundary statement per CPS (what's included, what's excluded, and why). - Capture "where the CPS ends": off-platform payment flows, external identity, external ad measurement, third-party app stores, and partner integrations. ## 2) Run the presumption test (Article 3(2)) per CPS Article 3 sets three conditions for designation (market impact, gateway role, durable position) and provides quantitative thresholds that create a presumption the conditions are satisfied. Treat this as a repeatable screening model you can rerun quarterly. It helps you anticipate the notification requirement and the likely timing of a designation decision. - Market impact: >= EUR 7.5B annual EU turnover in each of the last 3 financial years OR >= EUR 75B average market capitalisation/fair market value in the last financial year, and the same CPS in at least 3 Member States. - Gateway role: in the last financial year, the CPS has >= 45M monthly active end users established or located in the EU AND >= 10,000 yearly active business users established in the EU (Annex methodology). - Durability: the gateway thresholds are met in each of the last 3 financial years. ## 3) Notification + Commission designation timeline (2 months -> 45 working days) If you meet all thresholds, the DMA requires notification to the Commission without delay and in any event within 2 months after the thresholds are met. After the Commission receives complete information, it must designate the undertaking as a gatekeeper without undue delay and at the latest within 45 working days. - Notification content matters: provide information for each CPS that meets the user/business-user thresholds. - Expect completeness questions: incomplete information can delay the "45 working day" clock. - Prepare a single source of truth: metrics definitions, EU location methodology, active user counting, and confidence ranges. ## 4) Rebuttal arguments and qualitative designation An undertaking can present sufficiently substantiated arguments that, exceptionally, although thresholds are met, it does not satisfy the designation requirements due to circumstances in which the CPS operates. Separately, the Commission can designate gatekeepers that do not meet thresholds based on qualitative assessment (size, network effects, data advantages, lock-in, vertical integration, and other structural characteristics). - If you plan to argue "exceptional circumstances", build a fact file that links the argument to CPS boundaries and market realities. - For near-threshold CPS, treat designation as "foreseeable" and begin building DMA-ready controls early (ranking fairness, data separation, portability tooling). - Track designation precedent: the Commission's published gatekeepers list is a living calibration dataset and, as of 6 March 2026, it shows 7 gatekeepers and 23 designated CPS after both designations and status changes. ## 5) The post-designation compliance clock (6 months) and what to do immediately After a CPS is listed in the designation decision, the gatekeeper must comply with Articles 5, 6, and 7 within 6 months. This is where teams tend to lose time: mapping obligations to product features, designing choice screens, changing default settings, updating ad transparency tooling, and building evidence. - Create an obligation-to-feature map per CPS (Articles 5-7), with owners and acceptance criteria. - Start the evidence library now: screenshots, recorded demos, API documentation, ranking parameter explanations, consent flows, and change logs. - Stand up the DMA compliance function (independent from operational functions) so reporting and monitoring are not bolted on later. - Prepare the Article 11 report workflow from day one, because the detailed report, non-confidential summary, and machine-readable supporting material are due within 6 months after designation. ## Quick checklist: what a strong designation readiness pack contains A designation readiness pack should reduce ambiguity for internal stakeholders and make it easy to respond quickly to Commission questions. If you are a business user (not a gatekeeper), the same pack helps you identify which obligations you can rely on and what "good compliance" should look like from your platform partner. - CPS inventory + boundary statements (per CPS). - Threshold workbook (EU turnover/market cap, Member State coverage, MAU/BAU methodology and assumptions). - Risk register: obligations most likely to change product behavior (self-preferencing, app distribution, consent/data combination, interoperability). - Implementation timeline: 0-6 months plan aligned to Articles 5-7 obligations, with evidence milestones. *Recommended next step* *Placement: after the scope or definition section* ## Use EU Digital Markets Act (DMA) Gatekeeper Designation Guide as a cited research workflow Research Copilot can take EU Digital Markets Act (DMA) Gatekeeper Designation Guide from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Digital Markets Act (DMA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Digital Markets Act (DMA) Gatekeeper Designation Guide](/solutions/research-copilot.md): Start from EU Digital Markets Act (DMA) Gatekeeper Designation Guide and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Digital Markets Act (DMA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Markets Act (DMA) Gatekeeper Designation Guide. ## Primary sources - [Regulation (EU) 2022/1925 (Digital Markets Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - Designation criteria and thresholds (Article 3), CPS definition (Article 2), and the 6-month compliance deadline after CPS listing (Article 3(10)). - [European Commission - Gatekeepers list and designated core platform services](https://digital-markets-act.ec.europa.eu/gatekeepers_en?ref=sorena.io) - Designation examples, designated undertakings, listed CPS, and key designation dates. - [Commission Implementing Regulation (EU) 2023/814 - DMA procedural rules](https://eur-lex.europa.eu/eli/reg/2023/814/oj?ref=sorena.io) - Procedural framework supporting notifications and conduct of proceedings (useful for designation readiness). - [European Commission - Further information about the DMA (Q&A)](https://digital-markets-act.ec.europa.eu/questions-and-answers/further-information-about-dma_en?ref=sorena.io) - Practical guidance on submissions and how stakeholders interact with the Commission for DMA implementation. - [DG Competition - EU SEND secure document exchange platform](https://competition-policy.ec.europa.eu/index/it-tools/eu-send_en?ref=sorena.io) - Secure document submission channel referenced in practical DMA interactions. ## Related Topic Guides - [DMA Applicability Test (Gatekeeper Scoping) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/applicability-test.md): A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds. - [DMA Compliance Checklist (Execution-Ready) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/checklist.md): An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls. - [DMA Compliance Program & Monitoring (Compliance Function + Evidence)](/artifacts/eu/digital-markets-act/compliance-program-and-monitoring.md): How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness. - [DMA Deadlines & Compliance Calendar (Key Dates) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar.md): A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline. - [DMA Do's and Don'ts for Product Teams | EU Digital Markets Act](/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams.md): Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes. - [DMA Enforcement: Penalties, Remedies, and Process | EU Digital Markets Act](/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies.md): How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies. - [DMA Fines & Penalties (10% / 20% / 1% + 5% per day) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/penalties-and-fines.md): A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%. - [DMA Obligations List (Articles 5, 6, 7) - By Obligation | EU Digital Markets Act](/artifacts/eu/digital-markets-act/core-obligations-by-obligation.md): A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores. - [DMA Self-Preferencing Compliance Examples (Article 6(5)) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples.md): Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what "transparent, fair. - [DMA vs DSA: What's the Difference? (EU Platform Laws)](/artifacts/eu/digital-markets-act/dma-vs-dsa.md): A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations. - [EU Digital Markets Act (DMA) Requirements (Articles 5-7)](/artifacts/eu/digital-markets-act/requirements.md): A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution. - [EU DMA Compliance Guide (How to Comply) | Digital Markets Act (DMA)](/artifacts/eu/digital-markets-act/compliance.md): A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations. - [EU DMA FAQ (Gatekeepers, Obligations, Deadlines) | Digital Markets Act](/artifacts/eu/digital-markets-act/faq.md): EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7). - [EU DMA Timeline & Key Milestones | Digital Markets Act (2022/1925)](/artifacts/eu/digital-markets-act/timeline-and-key-milestones.md): A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones. - [Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11)](/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist.md): A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-markets-act/gatekeeper-designation-guide --- --- title: "DMA Fines & Penalties (10% / 20% / 1% + 5% per day)" canonical_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/penalties-and-fines" author: "Sorena AI" description: "A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "DMA fines" - "DMA penalties" - "Article 30 fines" - "Article 31 periodic penalty payments" - "DMA 10% fine" - "DMA 20% repeat infringement fine" - "DMA 1% procedural fine" - "DMA 5% average daily turnover per day" - "Digital Markets Act penalties" - "10% turnover fine" - "20% repeat infringement" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DMA Fines & Penalties (10% / 20% / 1% + 5% per day) A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%. *Artifact Guide* *EU* ## EU Digital Markets Act (DMA) Fines & Penalties What DMA penalties look like and what triggers escalation. Use this to prioritise high-risk obligations and build evidence and monitoring that reduce enforcement exposure. DMA penalties are turnover-based and designed to be material at gatekeeper scale. The headline numbers matter (10% / 20% / 1% / 5% per day), but the practical risk is driven by how quickly you can demonstrate effective compliance per core platform service (CPS) and per obligation - and how you respond when the Commission asks for information or testing evidence. ## The DMA penalty framework at a glance (Articles 30-31) The DMA includes (1) fines for non-compliance with obligations and related decisions, (2) fines for procedural failures (information/notification failures), and (3) periodic penalty payments that can run daily to compel compliance. You should treat this as a risk model: each CPS + obligation has a compliance risk score, and each risk score maps to evidence and monitoring controls. - Non-compliance fines: up to 10% of total worldwide turnover in the preceding financial year for failing to comply with Articles 5-7 (and related measures). - Repeat infringements: up to 20% of total worldwide turnover for the same or similar infringement within 8 years for the same CPS after a prior non-compliance decision. - Procedural fines: up to 1% of total worldwide turnover for failures such as not providing required information for designation or failing to notify under Article 3(3). - Periodic penalty payments: up to 5% of average daily worldwide turnover per day to compel compliance with certain decisions and requests. - Systematic non-compliance risk: repeated non-compliance decisions can trigger an Article 18 market investigation and remedies in addition to monetary penalties. ## What typically triggers non-compliance fines (10% / 20%) The 10% (and 20% repeat) fine tiers are tied to failures to comply with obligations in Articles 5, 6, and 7 and certain related decisions/measures (remedies, interim measures, commitments). Practically, the risk rises when your implementation is incomplete, inconsistently applied across EU users, or not provably effective. - Article 5(2) consent/data combination failures (e.g., "pay or consent" patterns) can become enforcement narratives because they affect user choice directly. - Article 6 ranking and self-preferencing concerns are hard to defend without transparent rules, testing, and governance over ranking parameters and experiments. - Interoperability and access obligations (Article 6(7), Article 7) are often judged by outcomes and developer experience, not just policy statements. *Recommended next step* *Placement: after the enforcement section* ## Use EU Digital Markets Act (DMA) Fines & Penalties as a cited research workflow Research Copilot can take EU Digital Markets Act (DMA) Fines & Penalties from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Digital Markets Act (DMA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Digital Markets Act (DMA) Fines & Penalties](/solutions/research-copilot.md): Start from EU Digital Markets Act (DMA) Fines & Penalties and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Digital Markets Act (DMA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Markets Act (DMA) Fines & Penalties. ## Procedural fines (up to 1%): the avoidable penalties Procedural failures can be expensive and are often preventable with a strong submissions and data governance workflow. Build a single "Commission response" process: who owns requests, how you validate completeness and accuracy, and how you preserve internal documents and raw data. - Risk examples: supplying incorrect/incomplete/misleading information for gatekeeper assessment; failing to notify the Commission under Article 3(3); failing to provide access to requested data/algorithms/testing information. - Mitigation: establish data lineage for MAU/BAU calculations, EU location methodology, and CPS boundary definitions; enforce review gates before submission. - Operational control: use secure submission channels (EU SEND) and keep receipts and correspondence tied to CPS case numbers. ## Periodic penalty payments (up to 5% per day): why "speed to compliance" matters Periodic penalty payments can apply per day to compel compliance with specific Commission decisions or requests. This makes response-time and remediation-time a first-class KPI. Your compliance program should be able to ship a mitigation quickly and prove it worked, with evidence captured in parallel. - Build "hotfix pathways" for DMA issues (like security issues): expedited engineering, policy signoff, and monitored rollout. - Prepare test harnesses: ensure you can validate choice screens, uninstall flows, portability APIs, and interoperability endpoints quickly. - Keep evidence machine-readable and exportable so requests do not create multi-week data extraction projects. ## How to reduce penalty exposure: evidence, monitoring, and governance Penalty exposure is reduced when compliance is demonstrable and sustained: you can show what you implemented, when, why it is compliant, and how you prevent regressions. The Commission's Article 11 compliance report template is a practical guide to the evidence you should have ready. - Evidence library per CPS and per obligation: prior state, implementation date, scope, engineering changes, UX changes, and metrics demonstrating effectiveness. - Monitoring: automated checks for regressions and a governance process for ranking and experimentation changes. - Compliance function: independence, resources, and direct reporting to the management body (Article 28) so risks are surfaced early. - Escalation control: track whether any non-compliance decisions are accumulating across CPS, because 3 decisions in 8 years can open the door to Article 18 systematic non-compliance remedies. ## Primary sources - [Regulation (EU) 2022/1925 (Digital Markets Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - Fines (Article 30) and periodic penalty payments (Article 31), plus the obligations in Articles 5-7 that fines attach to. - [European Commission - Preliminary findings example (Meta "Pay or Consent", 1 Jul 2024)](https://digital-markets-act.ec.europa.eu/commission-sends-preliminary-findings-meta-over-its-pay-or-consent-model-breach-digital-markets-act-2024-07-01_en?ref=sorena.io) - Example enforcement narrative tied to Article 5(2) consent/data-combination requirements. - [European Commission - Article 11 DMA Compliance Report Template (9 Oct 2023)](https://digital-markets-act.ec.europa.eu/about-dma/practical-information_en#templates?ref=sorena.io) - Evidence expectations that reduce risk of "non-compliance by lack of proof." - [DG Competition - EU SEND secure document exchange platform](https://competition-policy.ec.europa.eu/index/it-tools/eu-send_en?ref=sorena.io) - Secure submission workflow that supports procedural compliance. ## Related Topic Guides - [DMA Applicability Test (Gatekeeper Scoping) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/applicability-test.md): A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds. - [DMA Compliance Checklist (Execution-Ready) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/checklist.md): An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls. - [DMA Compliance Program & Monitoring (Compliance Function + Evidence)](/artifacts/eu/digital-markets-act/compliance-program-and-monitoring.md): How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness. - [DMA Deadlines & Compliance Calendar (Key Dates) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar.md): A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline. - [DMA Do's and Don'ts for Product Teams | EU Digital Markets Act](/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams.md): Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes. - [DMA Enforcement: Penalties, Remedies, and Process | EU Digital Markets Act](/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies.md): How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies. - [DMA Obligations List (Articles 5, 6, 7) - By Obligation | EU Digital Markets Act](/artifacts/eu/digital-markets-act/core-obligations-by-obligation.md): A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores. - [DMA Self-Preferencing Compliance Examples (Article 6(5)) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples.md): Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what "transparent, fair. - [DMA vs DSA: What's the Difference? (EU Platform Laws)](/artifacts/eu/digital-markets-act/dma-vs-dsa.md): A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations. - [EU Digital Markets Act (DMA) Requirements (Articles 5-7)](/artifacts/eu/digital-markets-act/requirements.md): A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution. - [EU DMA Compliance Guide (How to Comply) | Digital Markets Act (DMA)](/artifacts/eu/digital-markets-act/compliance.md): A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations. - [EU DMA FAQ (Gatekeepers, Obligations, Deadlines) | Digital Markets Act](/artifacts/eu/digital-markets-act/faq.md): EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7). - [EU DMA Timeline & Key Milestones | Digital Markets Act (2022/1925)](/artifacts/eu/digital-markets-act/timeline-and-key-milestones.md): A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones. - [Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11)](/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist.md): A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report. - [Gatekeeper Designation Guide (DMA Article 3) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/gatekeeper-designation-guide.md): A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-markets-act/penalties-and-fines --- --- title: "EU Digital Markets Act (DMA) Requirements (Articles 5-7)" canonical_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/requirements" source_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/requirements" author: "Sorena AI" description: "A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU DMA requirements" - "Digital Markets Act requirements" - "DMA obligations Article 5" - "DMA obligations Article 6" - "DMA interoperability Article 7" - "gatekeeper compliance requirements" - "DMA app store requirements" - "DMA self-preferencing" - "DMA choice screen" - "DMA data portability" - "EU Digital Markets Act" - "DMA requirements" - "DMA obligations" - "Article 5" - "Article 6" - "Article 7" - "gatekeeper compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Digital Markets Act (DMA) Requirements (Articles 5-7) A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution. *Artifact Guide* *EU* ## EU Digital Markets Act (DMA) Requirements What a designated gatekeeper must do (and must not do) under DMA Articles 5-7. Built for implementation: product requirements, engineering changes, monitoring checks, and evidence for the Article 11 compliance report. DMA requirements are not "policy only". They translate into product requirements (choice screens, default settings, ranking), architecture requirements (data separation, portability tools), and operational requirements (compliance function, reporting, monitoring). Use this page as your EU Digital Markets Act (DMA) requirements baseline once a core platform service is listed in a gatekeeper designation decision. ## What changes after gatekeeper designation The DMA applies to core platform services (CPS) listed in the designation decision. For each listed CPS, the gatekeeper must comply with the obligations in Articles 5, 6, and 7 within 6 months after listing. In practice, DMA requirements become cross-functional work: legal interpretation, product requirement writing, engineering implementation, commercial terms updates, and evidence-building for regulator scrutiny. - Treat each CPS as its own compliance surface (app store, OS, browser, social network, ads stack, etc.). - Design for auditability: document the "why" behind choices, especially where integrity/security exceptions are relied on. - Plan evidence from day one: demos, screenshots, API docs, metrics, and change logs are part of compliance. ## Article 5 requirements (prohibited or tightly constrained practices) Article 5 contains obligations that often require immediate product and data-control changes, especially for advertising, consent, and business-user commercial terms. These requirements are frequently tested via complaints and enforcement narratives because they affect user choice and business-user steering directly. - Personal data combination/cross-use: do not combine personal data across CPS and other services unless the end user has a specific choice and consent; if refused/withdrawn, do not re-request for the same purpose more than once within a year. - Anti-steering for business users: do not prevent business users from offering different prices/conditions through other channels; allow business users to communicate/promote offers to end users and conclude contracts with end users acquired via the CPS. - No forced use of gatekeeper services: do not require the gatekeeper's identification service, browser engine, payment service, or in-app payment technical services for business users' services using the CPS. - Ads transparency: provide daily information to advertisers and publishers about prices/fees/remuneration and the metrics used (subject to the consent constraints described in the DMA). *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU Digital Markets Act (DMA) Requirements into an operational assessment Assessment Autopilot can take EU Digital Markets Act (DMA) Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Digital Markets Act (DMA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Digital Markets Act (DMA) Requirements](/solutions/assessment.md): Start from EU Digital Markets Act (DMA) Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Digital Markets Act (DMA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Markets Act (DMA) Requirements. ## Article 6 requirements (choice, access, ranking fairness, data access) Article 6 turns DMA compliance into "build and operate" workstreams: uninstallability, default settings and choice screens, app distribution, ranking neutrality, data portability, and continuous data access for business users. Many Article 6 obligations are susceptible of being further specified under Article 8, so your implementation should be measurable, testable, and explainable. - Data advantage controls: do not use non-public business-user data to compete against business users (including inferred aggregated data such as click, search, view, and voice data). - Choice and defaults: enable easy app uninstall (except essential OS/device apps); enable changing defaults; prompt end users at first use to choose among main providers for search engine, virtual assistant, and browser where applicable. - Third-party apps and app stores: allow installation and effective use of third-party apps/app stores using or interoperating with the OS; allow access by means other than the gatekeeper's CPS, subject to strictly necessary and proportionate integrity/security measures. - No self-preferencing: do not treat the gatekeeper's services more favourably in ranking/indexing/crawling; apply transparent, fair, non-discriminatory ranking conditions. - Portability and access: provide effective data portability tools and continuous/real-time access for end users; provide business users continuous/real-time access to aggregated and non-aggregated data generated in CPS use (with opt-in consent where personal data is involved). - FRAND access terms: apply fair, reasonable, and non-discriminatory conditions of access for business users to app stores, search engines, and social networking services; publish conditions including an alternative dispute settlement mechanism. ## Article 7 requirements (messaging interoperability and staged deadlines) If a gatekeeper provides number-independent interpersonal communications services (NICS) listed in the designation decision, Article 7 requires interoperability with other providers upon request, free of charge, while preserving security (including end-to-end encryption where applicable). Article 7 is explicitly staged over time: 1:1 messaging first, then groups, then voice/video calling. This affects protocol design, identity and consent, abuse prevention, and security assurance. - After listing: make end-to-end 1:1 text messaging interoperable; and sharing of images/voice messages/videos/other files in 1:1 communication (where the gatekeeper provides those features). - Within 2 years from designation: group text messaging and group-to-individual file sharing interoperability. - Within 4 years from designation: voice calls and video calls (1:1 and group-to-individual). - Publish a reference offer with technical details/terms; comply with reasonable interoperability requests within 3 months after receiving the request. ## Governance and reporting requirements (compliance function + Article 11 reporting) The DMA requires gatekeepers to introduce an independent compliance function with compliance officers and direct reporting to the management body, plus sufficient authority, resources, and management accountability. For reporting, the Commission's Article 11 compliance report template clarifies the minimum information expected: per CPS and per obligation, a compliance statement and an exhaustive explanation with supporting data, documents, and (often) demos. - Implement a DMA compliance function independent of operational functions; appoint a head of compliance with direct access to the management body. - Build an evidence library aligned to Article 11 reporting: product flows, consent screens, ranking logic explanations, APIs, security and integrity justifications, change logs per CPS, and machine-readable supporting data. - Plan adjacent post-designation deliverables as well: the detailed Article 11 compliance report within 6 months, at least annual updates, and the independently audited consumer-profiling description plus public overview that the DMA also requires after designation. - Set a recurring cadence: at least annual review of strategies and policies, annual compliance report updates, and evidence refreshes tied to product releases. ## Primary sources - [Regulation (EU) 2022/1925 (Digital Markets Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - Primary DMA requirements in Articles 5-7, plus the 6-month compliance deadline after a CPS is listed in the designation decision. - [European Commission - Article 11 DMA Compliance Report Template (9 Oct 2023)](https://digital-markets-act.ec.europa.eu/about-dma/practical-information_en#templates?ref=sorena.io) - Minimum information and evidence expectations for compliance reporting (per CPS and per obligation) and annual updates. - [European Commission - Gatekeepers list and designated core platform services](https://digital-markets-act.ec.europa.eu/gatekeepers_en?ref=sorena.io) - Current designated gatekeepers and their listed CPS (useful for scoping and examples). - [European Commission - Interoperability (Questions and Answers)](https://digital-markets-act.ec.europa.eu/questions-and-answers/interoperability_en?ref=sorena.io) - Practical examples of how Article 6(7) and specification decisions can shape interoperability requirements. - [DG Competition - EU SEND secure document exchange platform](https://competition-policy.ec.europa.eu/index/it-tools/eu-send_en?ref=sorena.io) - Submission mechanics commonly used in DMA-related interactions with the Commission. ## Related Topic Guides - [DMA Applicability Test (Gatekeeper Scoping) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/applicability-test.md): A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds. - [DMA Compliance Checklist (Execution-Ready) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/checklist.md): An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls. - [DMA Compliance Program & Monitoring (Compliance Function + Evidence)](/artifacts/eu/digital-markets-act/compliance-program-and-monitoring.md): How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness. - [DMA Deadlines & Compliance Calendar (Key Dates) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar.md): A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline. - [DMA Do's and Don'ts for Product Teams | EU Digital Markets Act](/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams.md): Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes. - [DMA Enforcement: Penalties, Remedies, and Process | EU Digital Markets Act](/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies.md): How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies. - [DMA Fines & Penalties (10% / 20% / 1% + 5% per day) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/penalties-and-fines.md): A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%. - [DMA Obligations List (Articles 5, 6, 7) - By Obligation | EU Digital Markets Act](/artifacts/eu/digital-markets-act/core-obligations-by-obligation.md): A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores. - [DMA Self-Preferencing Compliance Examples (Article 6(5)) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples.md): Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what "transparent, fair. - [DMA vs DSA: What's the Difference? (EU Platform Laws)](/artifacts/eu/digital-markets-act/dma-vs-dsa.md): A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations. - [EU DMA Compliance Guide (How to Comply) | Digital Markets Act (DMA)](/artifacts/eu/digital-markets-act/compliance.md): A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations. - [EU DMA FAQ (Gatekeepers, Obligations, Deadlines) | Digital Markets Act](/artifacts/eu/digital-markets-act/faq.md): EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7). - [EU DMA Timeline & Key Milestones | Digital Markets Act (2022/1925)](/artifacts/eu/digital-markets-act/timeline-and-key-milestones.md): A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones. - [Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11)](/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist.md): A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report. - [Gatekeeper Designation Guide (DMA Article 3) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/gatekeeper-designation-guide.md): A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-markets-act/requirements --- --- title: "DMA Self-Preferencing Compliance Examples (Article 6(5))" canonical_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples" source_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples" author: "Sorena AI" description: "Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what \"transparent, fair." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "DMA self-preferencing" - "Article 6(5) self-preferencing" - "Digital Markets Act self-preferencing" - "ranking neutrality DMA" - "app store ranking DMA" - "search ranking DMA" - "transparent fair non-discriminatory ranking" - "DMA compliance examples" - "Article 6(5)" - "ranking neutrality" - "app store ranking" - "search ranking" - "fair non-discriminatory conditions" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DMA Self-Preferencing Compliance Examples (Article 6(5)) Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what "transparent, fair. *Artifact Guide* *EU* ## EU Digital Markets Act (DMA) Self-Preferencing: Compliance Examples Design ranking and discovery systems that don't favour first-party services. Focused on Article 6(5): ranking/indexing/crawling fairness + the evidence you need to prove it. DMA Article 6(5) prohibits gatekeepers from treating their own services and products more favourably in ranking and related indexing/crawling than similar third-party services. Compliance is not just "remove a banner" - it requires ranking governance, experimentation controls, bias testing, and clear documentation of how ranking parameters are applied. ## What the DMA requires (Article 6(5)) Article 6(5) requires that the gatekeeper must not treat more favourably, in ranking and related indexing/crawling, services and products offered by the gatekeeper itself than similar services or products of a third party. It also requires transparent, fair, and non-discriminatory conditions for ranking. That implies governance, explainability, and repeatable testing. - Scope includes: search results, app store listings, marketplace listings, recommendations, "top picks", auto-suggest, and any surface where ranking or visibility is algorithmically controlled. - "Related indexing and crawling" matters for web and app discovery: coverage and freshness decisions can create de facto preference. - You need a defensible definition of "similar services/products" for each CPS context. ## Common self-preferencing patterns (and why they fail) Self-preferencing often hides in "defaults" and "UX shortcuts": pre-installed placements, privileged UI real estate, or algorithmic boosts that are not visible in policy docs. If you cannot explain and reproduce your ranking outcomes, you cannot reliably prove non-discrimination. - Hard-coded boosts for first-party services (e.g., multipliers, whitelists, hidden quality overrides). - Preferential UI treatment: pinned cards, "recommended by platform" labels, default filters favouring first-party categories. - Asymmetric eligibility rules: third parties face stricter review criteria, slower indexing, or higher friction for the same distribution outcome. ## Compliance design patterns that work (engineering + governance) The goal is not "no ranking" - it is ranking neutrality with consistent rules and measurable checks. Build a ranking governance model: parameter registry, change control, experiment approvals, and periodic bias testing. - Parameter registry: maintain a documented list of ranking features and how they are applied to first-party vs third-party items. - Eligibility parity: define consistent inclusion/exclusion rules and apply the same verification thresholds to first-party and third-party items. - Testing: run periodic "swap tests" and counterfactual checks to detect first-party advantage not explained by neutral features. - Transparency: publish a high-level ranking explanation that is stable across changes and does not rely on vague claims. *Recommended next step* *Placement: after the compliance steps* ## Turn EU Digital Markets Act (DMA) Self-Preferencing: Compliance Examples into an operational assessment Assessment Autopilot can take EU Digital Markets Act (DMA) Self-Preferencing: Compliance Examples from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Digital Markets Act (DMA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Digital Markets Act (DMA) Self-Preferencing: Compliance Examples](/solutions/assessment.md): Start from EU Digital Markets Act (DMA) Self-Preferencing: Compliance Examples and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Digital Markets Act (DMA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Markets Act (DMA) Self-Preferencing: Compliance Examples. ## Examples by CPS: app stores, search, marketplaces, and social discovery Use these examples as prompts to review your own ranking and discovery surfaces. For each, record the ranking rules, the UX treatment, and the evidence you can produce. The same pattern can show up in different CPS: a "featured" slot in an app store is structurally similar to a "top results" carousel in search. - App store: first-party apps placed above third-party apps for identical queries; first-party apps exempt from certain eligibility requirements; faster indexing for first-party updates. - Search: first-party vertical modules (shopping/maps/video) persistently outrank third-party results without neutral relevance justification; crawling/indexing coverage disfavors third-party categories. - Marketplace/intermediation: first-party offers receive better placement or badges; default sort prioritizes first-party fulfilment or services without clear user-choice toggles. - Social discovery: recommendation systems favour first-party services or formats; privileged distribution for first-party content or features. ## Evidence checklist (Article 11-style) for self-preferencing compliance Self-preferencing compliance is easiest to defend when you can show: rules -> implementation -> outcomes -> monitoring. The Commission's Article 11 reporting template expects detailed explanations and supporting data. Use the evidence checklist below to avoid "trust us" compliance. - Ranking documentation: parameter registry, eligibility rules, indexing/crawling policies, and change logs. - Outcome evidence: benchmark queries/tests showing parity, with statistical analysis and "why it ranked" explanation. - Experiment governance: approvals, guardrails, and monitoring for ranking changes. - Remediation playbook: how you respond when tests detect first-party advantage. ## Primary sources - [Regulation (EU) 2022/1925 (Digital Markets Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - Self-preferencing prohibition and ranking fairness requirement (Article 6(5)), plus related access and fairness obligations. - [European Commission - Article 11 DMA Compliance Report Template (9 Oct 2023)](https://digital-markets-act.ec.europa.eu/about-dma/practical-information_en#templates?ref=sorena.io) - Evidence expectations for explaining ranking measures, engineering changes, and effectiveness. - [European Commission - Gatekeepers list and designated core platform services](https://digital-markets-act.ec.europa.eu/gatekeepers_en?ref=sorena.io) - Which CPS categories are currently designated in practice (useful for scoping where ranking fairness applies). ## Related Topic Guides - [DMA Applicability Test (Gatekeeper Scoping) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/applicability-test.md): A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds. - [DMA Compliance Checklist (Execution-Ready) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/checklist.md): An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls. - [DMA Compliance Program & Monitoring (Compliance Function + Evidence)](/artifacts/eu/digital-markets-act/compliance-program-and-monitoring.md): How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness. - [DMA Deadlines & Compliance Calendar (Key Dates) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar.md): A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline. - [DMA Do's and Don'ts for Product Teams | EU Digital Markets Act](/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams.md): Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes. - [DMA Enforcement: Penalties, Remedies, and Process | EU Digital Markets Act](/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies.md): How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies. - [DMA Fines & Penalties (10% / 20% / 1% + 5% per day) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/penalties-and-fines.md): A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%. - [DMA Obligations List (Articles 5, 6, 7) - By Obligation | EU Digital Markets Act](/artifacts/eu/digital-markets-act/core-obligations-by-obligation.md): A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores. - [DMA vs DSA: What's the Difference? (EU Platform Laws)](/artifacts/eu/digital-markets-act/dma-vs-dsa.md): A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations. - [EU Digital Markets Act (DMA) Requirements (Articles 5-7)](/artifacts/eu/digital-markets-act/requirements.md): A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution. - [EU DMA Compliance Guide (How to Comply) | Digital Markets Act (DMA)](/artifacts/eu/digital-markets-act/compliance.md): A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations. - [EU DMA FAQ (Gatekeepers, Obligations, Deadlines) | Digital Markets Act](/artifacts/eu/digital-markets-act/faq.md): EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7). - [EU DMA Timeline & Key Milestones | Digital Markets Act (2022/1925)](/artifacts/eu/digital-markets-act/timeline-and-key-milestones.md): A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones. - [Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11)](/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist.md): A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report. - [Gatekeeper Designation Guide (DMA Article 3) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/gatekeeper-designation-guide.md): A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples --- --- title: "EU DMA Timeline & Key Milestones" canonical_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/timeline-and-key-milestones" source_url: "https://www.sorena.io/artifacts/eu/digital-markets-act/timeline-and-key-milestones" author: "Sorena AI" description: "A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones." published_at: "2026-02-21" updated_at: "2026-02-23" keywords: - "EU DMA timeline" - "Digital Markets Act timeline" - "DMA key milestones" - "gatekeeper designation dates" - "DMA compliance 6 months" - "DMA interoperability timeline" - "Article 7 interoperability 2 years 4 years" - "DMA enforcement milestones" - "Commission evaluation 3 May 2026" - "Digital Markets Act milestones" - "DMA compliance deadline" - "DMA enforcement" - "Article 7 interoperability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DMA Timeline & Key Milestones A grounded EU Digital Markets Act (DMA) timeline: application date, gatekeeper designations, compliance clocks, Article 7 staged interoperability milestones. *Artifact Guide* *EU* ## EU Digital Markets Act (DMA) Timeline & Key Milestones A practical, date-driven view of DMA application, designation, compliance, and enforcement. Designed for planning: convert milestones into release-train deadlines, reporting cadence, and evidence capture checkpoints. DMA timelines matter because the obligations in Articles 5-7 are anchored to designation decisions per core platform service (CPS). This timeline combines regulation-level dates (application and evaluation), designation milestones (who was designated and when), and obligation-level clocks (6-month compliance, Article 7 staged interoperability deadlines). ## Regulation-level milestones (application + evaluation cycle) The DMA has a general application date and an evaluation cycle that can drive future updates (including changes to CPS categories or obligations). Use these dates to plan "policy refresh" sprints and periodic risk reviews even if your CPS was designated earlier. - 1 Nov 2022: certain provisions applied earlier (including delegated-act powers for methodology adjustments). - 2 May 2023: DMA applies (general application date). - 3 May 2026: Commission must evaluate and report on the DMA, and subsequently every 3 years. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU Digital Markets Act (DMA) Timeline & Key Milestones into an operational assessment Assessment Autopilot can take EU Digital Markets Act (DMA) Timeline & Key Milestones from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Digital Markets Act (DMA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Digital Markets Act (DMA) Timeline & Key Milestones](/solutions/assessment.md): Start from EU Digital Markets Act (DMA) Timeline & Key Milestones and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Digital Markets Act (DMA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Markets Act (DMA) Timeline & Key Milestones. ## Designation milestones (public anchor dates) Designation happens per undertaking and results in a decision listing relevant CPS. The Commission publishes and updates a list of gatekeepers and their listed CPS on an ongoing basis. These public dates are useful for benchmarking program maturity and anticipating follow-on actions (specification, monitoring, enforcement). - 6 Sep 2023: first gatekeeper designations (examples include Alphabet, Amazon, Apple, ByteDance, Meta, Microsoft). - 29 Apr 2024: Apple designated for iPadOS (operating system for tablets). - 13 May 2024: Booking designated for its online intermediation service (Booking.com). - 23 Apr 2025: Meta undesignated for its online intermediation service Facebook Marketplace (example of status changes over time). - 5 Feb 2026: the Commission found Apple Ads and Apple Maps should not be designated under the DMA after Apple notified them in Nov 2025. ## The core implementation clock: designation -> 6-month compliance For implementation teams, the most important DMA timeline is: "CPS listed in designation decision" -> "6 months to comply with Articles 5, 6, and 7." This clock is CPS-specific: different services can have different listing dates and therefore different compliance due dates. - If thresholds are met, the undertaking must notify the Commission within 2 months after thresholds are met. - The Commission must designate at the latest within 45 working days after receiving complete information. - The gatekeeper must comply with Articles 5-7 within 6 months after the CPS is listed in the designation decision. ## Interoperability milestones: Article 7 staged deadlines (0 / 2 years / 4 years) Article 7 introduces staged interoperability obligations for number-independent interpersonal communications services (NICS) listed in the designation decision. Plan these as multi-year engineering programs with security assurance, abuse prevention, operational monitoring, and partner onboarding. - After listing: 1:1 end-to-end text messaging interoperability; 1:1 file sharing interoperability (where applicable). - Within 2 years: group messaging interoperability and group-to-individual file sharing interoperability. - Within 4 years: voice/video calling interoperability (1:1 and group-to-individual). - Operational SLA: comply with a reasonable interoperability request within 3 months; publish a reference offer within the 6-month compliance period. ## Enforcement and specification milestones (what triggers changes mid-flight) The DMA enforcement lifecycle often involves information requests, monitoring, and, where needed, specification decisions under Article 8 for obligations susceptible of further specification. Treat enforcement events as signals that "implementation expectations" can become more concrete over time; build your program to adapt without major rewrites. - Specification decisions can clarify measures required to achieve effective compliance (example: Article 6(7) interoperability specifications for iOS and iPadOS). - Preliminary findings are an enforcement step that can precede a non-compliance decision (example: Commission preliminary findings on a "pay or consent" model referenced to Article 5(2)). - Monitoring can involve document retention requirements and independent experts or auditors; design evidence capture as a continuous process. - A systematic non-compliance market investigation under Article 18 can lead to behavioral or structural remedies if the Commission sees repeated infringements and continued gatekeeper power. ## How to use this timeline in your DMA program A good DMA timeline is not a history lesson - it is a delivery plan. Convert each milestone into owners, outputs, and evidence requirements. If you operate in a gatekeeper ecosystem (as a business user), use the same timeline to set expectations for platform partners and to plan migration options (portability tools, alternative app stores, interoperability requests). - Create a "CPS-by-CPS" roadmap: designation date, 6-month compliance due date, reporting cycles, and expected specification/enforcement touchpoints. - Run quarterly "DMA delta" reviews: what changed in gatekeeper lists, compliance reports, specification decisions, and enforcement posture. - Maintain a living evidence library aligned to the Commission's Article 11 compliance report template and to the obligations in Articles 5-7. ## Primary sources - [Regulation (EU) 2022/1925 (Digital Markets Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - Application, designation deadlines, 6-month compliance deadline, Article 7 staged interoperability timeline, and evaluation cycle. - [European Commission - Gatekeepers list and designated core platform services](https://digital-markets-act.ec.europa.eu/gatekeepers_en?ref=sorena.io) - Public designation/undesignation dates and current list of designated gatekeepers and CPS. - [European Commission - Interoperability (Questions and Answers)](https://digital-markets-act.ec.europa.eu/questions-and-answers/interoperability_en?ref=sorena.io) - Example of interoperability specification proceedings and implementation timelines for Article 6(7). - [European Commission - Preliminary findings example (Meta "Pay or Consent", 1 Jul 2024)](https://digital-markets-act.ec.europa.eu/commission-sends-preliminary-findings-meta-over-its-pay-or-consent-model-breach-digital-markets-act-2024-07-01_en?ref=sorena.io) - Example enforcement milestone referenced to Article 5(2) and consent/data-combination obligations. ## Related Topic Guides - [DMA Applicability Test (Gatekeeper Scoping) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/applicability-test.md): A practical DMA applicability test for teams scoping EU Digital Markets Act exposure: core platform service (CPS) mapping, gatekeeper presumption thresholds. - [DMA Compliance Checklist (Execution-Ready) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/checklist.md): An execution-ready EU DMA checklist: CPS scoping, gatekeeper thresholds, designation readiness, Article 5-7 obligation mapping, product/engineering controls. - [DMA Compliance Program & Monitoring (Compliance Function + Evidence)](/artifacts/eu/digital-markets-act/compliance-program-and-monitoring.md): How to build an EU DMA compliance program that survives scrutiny: Article 28 compliance function design, monitoring readiness. - [DMA Deadlines & Compliance Calendar (Key Dates) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/deadlines-and-compliance-calendar.md): A calendar-ready DMA deadlines guide: application date, gatekeeper notification (2 months), designation (45 working days), 6-month compliance deadline. - [DMA Do's and Don'ts for Product Teams | EU Digital Markets Act](/artifacts/eu/digital-markets-act/dos-and-donts-for-product-teams.md): Practical DMA do's and don'ts for product and engineering teams: how to avoid self-preferencing, implement choice screens and default changes. - [DMA Enforcement: Penalties, Remedies, and Process | EU Digital Markets Act](/artifacts/eu/digital-markets-act/enforcement-penalties-and-remedies.md): How EU DMA enforcement works: information requests, monitoring, preliminary findings, non-compliance decisions, commitments, interim measures, remedies. - [DMA Fines & Penalties (10% / 20% / 1% + 5% per day) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/penalties-and-fines.md): A practitioner guide to DMA penalties: non-compliance fines up to 10% worldwide turnover, repeat infringement fines up to 20%, procedural fines up to 1%. - [DMA Obligations List (Articles 5, 6, 7) - By Obligation | EU Digital Markets Act](/artifacts/eu/digital-markets-act/core-obligations-by-obligation.md): A detailed, obligation-by-obligation breakdown of the EU Digital Markets Act (DMA): Article 5 restrictions, Article 6 obligations (choice screens, app stores. - [DMA Self-Preferencing Compliance Examples (Article 6(5)) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/self-preferencing-compliance-examples.md): Practical self-preferencing compliance guidance for DMA Article 6(5): what counts as self-preferencing in ranking/indexing/crawling, what "transparent, fair. - [DMA vs DSA: What's the Difference? (EU Platform Laws)](/artifacts/eu/digital-markets-act/dma-vs-dsa.md): A practical comparison of the EU Digital Markets Act (DMA) vs the Digital Services Act (DSA): what each law regulates, who is in scope, core obligations. - [EU Digital Markets Act (DMA) Requirements (Articles 5-7)](/artifacts/eu/digital-markets-act/requirements.md): A deep, execution-ready overview of EU DMA requirements for gatekeepers: Article 5 restrictions, Article 6 obligations (choice screens, app distribution. - [EU DMA Compliance Guide (How to Comply) | Digital Markets Act (DMA)](/artifacts/eu/digital-markets-act/compliance.md): A practical guide to EU Digital Markets Act (DMA) compliance: how to scope CPS, start the 6-month clock after designation, implement Articles 5-7 obligations. - [EU DMA FAQ (Gatekeepers, Obligations, Deadlines) | Digital Markets Act](/artifacts/eu/digital-markets-act/faq.md): EU Digital Markets Act (DMA) FAQ: what is a gatekeeper, what counts as a core platform service (CPS), what are the key obligations (Articles 5-7). - [Gatekeeper Compliance Checklist (DMA Articles 5-7 + Article 11)](/artifacts/eu/digital-markets-act/gatekeeper-compliance-checklist.md): A gatekeeper-focused DMA compliance checklist: what to implement within 6 months per listed CPS, how to structure the Article 11 compliance report. - [Gatekeeper Designation Guide (DMA Article 3) | EU Digital Markets Act](/artifacts/eu/digital-markets-act/gatekeeper-designation-guide.md): A practical guide to DMA gatekeeper designation: core platform service mapping, Article 3 thresholds (45M / 10,000 / EUR 7.5B / EUR 75B). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-markets-act/timeline-and-key-milestones --- --- title: "DPP Applicability Test (ESPR Scoping)" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/applicability-test" author: "Sorena AI" description: "A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "DPP applicability test" - "Digital Product Passport applicability" - "EU DPP scope" - "ESPR delegated act DPP" - "is DPP mandatory" - "model batch item DPP" - "DPP data carrier requirements" - "DPP distance selling" - "DPP applicability" - "ESPR scoping" - "delegated act" - "model batch item" - "data carrier" - "distance selling" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DPP Applicability Test (ESPR Scoping) A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act. *Artifact Guide* *EU* ## EU Digital Product Passport (DPP) Applicability Test Decide if you need a DPP (and what exactly you must implement) for your product group. Built around ESPR 2024/1781: delegated act coverage, DPP granularity, roles and pre-purchase access requirements. A DPP is not universally mandatory for every product today. Under ESPR (Regulation (EU) 2024/1781), DPP obligations are set by product-group delegated acts. This applicability test helps you make an "in-scope" decision that is accurate and implementation-ready. The current implementation baseline is the first ESPR working plan, adopted by 19 April 2025 for the 2025-2030 period, not a single cross-product DPP mandate. ## Step 1 - Is your product group covered by a delegated act? DPP requirements apply when a delegated act adopted under ESPR Article 4 sets information requirements that include DPP. That delegated act defines what data must be present, how it is accessed, and who can update it. Start by checking whether your product group is prioritised and covered in the Commission's working plan and by any adopted delegated act for your product category. - Current prioritisation anchor: the first ESPR working plan, adopted by 19 April 2025, prioritises iron and steel, aluminium, textiles with garments and footwear, furniture including mattresses, tyres, detergents, paints, lubricants, chemicals, ICT and other electronics, and energy-related products. - Confirm product group definition and commodity codes (delegated acts specify product group and may include commodity codes). - Check whether the delegated act requires a DPP and what data elements (from Annex III) are in scope. - If multiple laws apply (e.g., sector rules like batteries), determine whether DPP can be used to provide information under other EU law. ## Step 2 - What DPP level applies: model, batch, or item? Delegated acts specify whether the DPP must exist at model, batch, or item level. This decision drives ID strategy, labeling/marking, lifecycle updates, and cost. You should treat this as an architecture constraint, not a documentation choice. - Model-level: one DPP per model identifier (lower operational overhead, fewer lifecycle updates). - Batch-level: one DPP per production subset (useful when manufacturing context affects regulated characteristics). - Item-level: one DPP per unit (strong traceability; higher complexity; requires persistent unique product identifiers per item). ## Step 3 - Identify your role: who creates and who updates DPP data? Delegated acts must specify which actors create the DPP and which actors may introduce or update which data. In implementation terms, you need a data governance model: owners, sources, and an audit trail. - Economic operators include: manufacturers, authorised representatives, importers, distributors, dealers and fulfilment service providers. - Importers often have DPP-relevant identifiers (e.g., EORI) and documentation responsibilities; dealers must support customer access (including distance selling). - Design access rights: public vs restricted views, who can update what, and how updates are validated. ## Step 4 - Data carrier requirement: can you physically attach a carrier? A DPP must be connected through a data carrier to a persistent unique product identifier. The data carrier must be physically present on the product, its packaging, or documentation. If your product cannot physically carry a data carrier, your packaging and documentation pathways become critical - and must be validated against product-group rules. - Choose carrier type (QR/2D code, RFID/EPC, etc.) appropriate for environment, durability, and lifecycle (repair/refurbish/recycle). - Plan for distance selling: dealers and online marketplaces may need a digital copy of the carrier or unique identifier to provide pre-purchase access. - Validate standards alignment: Annex III references identifier and carrier standards (or equivalent) for compliance. ## Step 5 - Pre-purchase access: can customers access the DPP before buying? Delegated acts must specify how the DPP is made accessible to customers before they are bound by a contract - including in distance selling. This is where many implementations fail: they build a portal but don't integrate it into the purchase flow. - In-store: scanning a data carrier on product/packaging or via shelf/digital displays. - Online: exposing the unique identifier or DPP link on product pages (with the correct public fields). - Avoid forced apps and personal data collection for public DPP data; design GDPR-aligned optional flows for restricted views. ## Step 6 - Registry + customs readiness (future-proofing your scope decision) ESPR requires an EU registry and a portal and introduces customs controls for covered products under release for free circulation once systems are operational. Even if your product-group delegated act is not active yet, design your applicability decision with these system dependencies in mind. - Registry requirement: Commission to set up a registry storing at least unique identifiers by 19 July 2026; economic operators upload required data to the registry. - Customs: release for free circulation may require the unique registration identifier once the registry is operational. - Plan identifier lifecycle: linking DPP versions and maintaining availability even if the responsible operator ceases activity. ## Step 7 - Service-provider dependence: do you rely on an external DPP platform? The Commission's 9 April 2025 public consultation on the future DPP focused specifically on how data should be stored and managed by service providers and on whether a certification scheme for those providers is needed. If you plan to rely on a third-party DPP platform, treat provider governance as part of applicability and not as a later procurement detail. - Check whether your design depends on storage or processing by DPP service providers and whether migration is possible without reprinting carriers. - Plan contract controls now: data non-reuse, continuity, exportability, backup access, and evidence retention. - Assume service-provider rules may tighten further through delegated acts or follow-on Commission measures. ## Output: your DPP applicability decision (what 'done' looks like) A good applicability test ends with an implementation plan - not just a yes/no answer. Use the checklist below as your minimum "scope decision pack". - Product group + delegated act mapping, including commodity codes and the DPP data set required (Annex III subset). - DPP granularity decision: model/batch/item with rationale and identifier consequences. - Role map + RACI: who creates, who updates, and who verifies each data field. - Data carrier design + placement plan, plus distance-selling exposure plan. - Access control model: public vs restricted fields, authentication approach, and audit logging. - Evidence plan: how you ensure data is accurate, complete and up to date, with change history. *Recommended next step* *Placement: after the applicability result* ## Operationalize EU Digital Product Passport (DPP) Applicability Test across ESG workflows ESG Compliance can take EU Digital Product Passport (DPP) Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Digital Product Passport (DPP) Applicability Test](/solutions/esg-compliance.md): Start from EU Digital Product Passport (DPP) Applicability Test and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Digital Product Passport (DPP)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) Applicability Test. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Applicability is defined via delegated acts (Article 4) and DPP requirements in Articles 9-11 (availability, carriers, access rights, and pre-purchase access). - [European Commission - ESPR and Digital Product Passport overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Implementation context: working plan approach and high-level DPP purpose and use cases. - [CEN-CENELEC CWA 18186:2025 - DPP design guidance (granularity, portal access, searchability)](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Practical scoping guidance: portal setup, access rights, searchability, data longevity and availability. ## Related Topic Guides - [DPP Architecture & Integration (Open Standards, Registry, APIs) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/architecture-and-integration.md): An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers. - [DPP Data Carriers, Access Control & UX | QR Code, Identifier, Public vs Restricted Views](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers. - [DPP Data Governance RACI Template | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field. - [DPP Data Requirements & Fields (Annex III) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III). - [DPP Governance, Verification & Audit Readiness | EU Digital Product Passport](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9). - [DPP Implementation Playbook & Vendor Selection | EU Digital Product Passport](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers. - [DPP QR Code Implementation Guide | Data Carrier + Identifier Design](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10). - [DPP vs Traditional Product Passports (Labels, PDFs, EPREL) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals. - [ESPR / DPP Penalties & Fines | EU Digital Product Passport Enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective. - [EU Digital Product Passport (DPP) Checklist | Audit-Ready Implementation Steps](/artifacts/eu/digital-product-passport/checklist.md): An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID). - [EU Digital Product Passport (DPP) Compliance Guide | Implementation Playbook](/artifacts/eu/digital-product-passport/compliance.md): A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements. - [EU Digital Product Passport (DPP) Deadlines & Compliance Calendar | ESPR 2024/1781](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024). - [EU Digital Product Passport (DPP) FAQ | ESPR 2024/1781](/artifacts/eu/digital-product-passport/faq.md): Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III). - [EU Digital Product Passport (DPP) Requirements | ESPR Articles 9-15 + Annex III](/artifacts/eu/digital-product-passport/requirements.md): A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9). - [What Is a Digital Product Passport (DPP)? | EU ESPR 2024/1781](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/applicability-test --- --- title: "DPP Architecture & Integration (Open Standards, Registry, APIs)" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/architecture-and-integration" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/architecture-and-integration" author: "Sorena AI" description: "An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "DPP architecture" - "Digital Product Passport architecture" - "ESPR Article 10 open standards" - "no vendor lock-in DPP" - "DPP interoperability Article 11" - "DPP registry integration" - "unique registration identifier" - "DPP APIs" - "DPP integration PLM ERP" - "DPP resolver" - "open standards" - "no vendor lock-in" - "registry integration" - "knowledge graph" - "APIs" - "access control" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DPP Architecture & Integration (Open Standards, Registry, APIs) An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers. *Artifact Guide* *EU* ## EU Digital Product Passport (DPP) Architecture & Integration A reference architecture for building DPPs that are interoperable, secure, and audit-ready. Designed to meet ESPR requirements: open standards, no vendor lock-in, access rights, registry readiness, and customs workflows. DPP is an information system with legal constraints. ESPR requires persistent identifiers, physical data carriers, open standards and interoperable formats, differentiated access rights, security and integrity, and EU registry/portal/customs infrastructure. This page turns those requirements into architecture patterns you can implement without painting yourself into a vendor lock-in corner. ## Architecture principle 1: product-centric identity (the DPP starts with the identifier) ESPR requires a persistent unique product identifier connected through a data carrier. Architecturally, the identifier is the stable key that binds physical items/models to digital data across lifecycle updates. Design your DPP around resolution: scanning a carrier should reliably resolve to the correct DPP view (public or restricted) for the correct level (model/batch/item). - Define identifier scheme(s): unique product identifier + (where relevant) GTIN/commodity codes and operator identifiers referenced in Annex III. - Build a resolver service: stable URLs/URIs that map identifier -> DPP view -> access-controlled data. - Support version linking: if a new DPP is created, it must link to prior DPP(s) (Article 11). ## Architecture principle 2: open standards and no vendor lock-in (Article 10) Article 10 is explicit: DPP data should be based on open standards, developed with interoperable format, and be machine-readable/structured/searchable/transferable through an open interoperable data exchange network without vendor lock-in. This requirement should drive vendor selection and data modeling choices. - Choose interoperable formats: structured data (not only PDFs) for core fields; publish stable schemas and versioning. - Exportability: ensure you can export DPP data and history without proprietary tooling; test migration paths early. - API-first: design DPP as an API-backed dataset with multiple renderers (consumer UI, B2B view, authority view). ## Architecture principle 3: differentiated access rights (public vs restricted views) Delegated acts specify which actors have access to what data and who may update which fields. Your architecture must enforce this with least privilege and audit logs. Article 11 requires free and easy access based on access rights, and restriction of modification rights accordingly. - Public view: accessible without unnecessary friction (avoid forced apps and personal data collection for public fields). - Restricted view: strong authentication, role-based field access, and comprehensive audit logging for reads and writes. - Update workflow: validate and version changes; tie updates to actors and evidence; enforce data quality SLAs (accurate, complete, up to date). ## Architecture principle 4: security, integrity and trust (Article 11 + CWA guidance) Article 11 requires authentication, reliability and integrity of data, high security and privacy, and fraud avoidance. CWA guidance discusses practical security and trust mechanisms (encryption, signatures, governance). Treat DPP as a high-value target: it can be used for compliance verification and customs checks. - Integrity controls: signatures/hashes for key records; tamper detection; immutable audit trail for critical updates. - Privacy: do not store customer personal data without explicit consent; isolate sensitive data and encrypt at rest/in transit. - Carrier security: consider authentication for data carriers in high-risk contexts (anti-counterfeit, high-value goods). ## Registry + portal integration (Articles 13-15): build for the EU dependency chain ESPR requires an EU registry (by 19 July 2026) that stores at least unique identifiers and issues a unique registration identifier after upload. A web portal enables search/compare consistent with access rights. Customs controls use the registration identifier once operational. Architect these as integrations with explicit operational SLAs and failure modes. - Registry upload pipeline: unique identifiers and any delegated-act required registry fields; store the returned unique registration identifier and link it to the DPP identifier. - Portal readiness: ensure public fields are searchable/compareable; ensure restricted fields are only accessible within rights. - Customs workflow: be able to provide the unique registration identifier for release for free circulation when required; support automated verification. ## Integration blueprint: source systems -> canonical DPP layer -> views DPP data lives across multiple systems. The robust pattern is: authoritative sources feed a canonical DPP layer, which powers different views and exports. This minimizes duplication while preserving provenance and auditability. - Sources: PLM/PIM (specs, model data), ERP/SCM (batch/commodity, importer info), compliance repositories (DoC/technical docs), labeling systems (carrier generation), service/repair tools (where applicable). - Canonical DPP layer: normalized schema aligned to Annex III + delegated-act extensions; provenance metadata; versioning; access control. - Views: consumer UX (public), business partner portal (restricted), authority view (restricted), machine-readable API exports. ## Implementation checklist: architecture decisions you must lock early Most DPP rework comes from late decisions on granularity, identifiers and access rights. Lock these early and prototype end-to-end. Use this checklist to de-risk before large rollout. - Granularity: model vs batch vs item; ensure identifiers and carrier printing can support it. - Identifier and resolver design: stable, persistent, and version-linkable; test scanning across environments. - Access model: actor types, public/restricted fields, authentication, and audit logging. - Export and migration: prove no vendor lock-in with data export and schema evolution plan. - Registry readiness: map what you upload, what you store, and how customs and market surveillance flows are supported. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU Digital Product Passport (DPP) Architecture & Integration across ESG workflows ESG Compliance can take EU Digital Product Passport (DPP) Architecture & Integration from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Digital Product Passport (DPP) Architecture & Integration](/solutions/esg-compliance.md): Start from EU Digital Product Passport (DPP) Architecture & Integration and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Digital Product Passport (DPP)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) Architecture & Integration. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Architecture drivers: Article 10 (open standards, no vendor lock-in), Article 11 (interoperability, access rights, security), Article 13 (registry), Articles 14-15 (portal and customs), Annex III (identifiers and data). - [CIRPASS DPP System Architecture (D3.2, March 2024)](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - Reference architecture patterns: product-centric identifiers, decentralised approaches, and interoperability principles. - [CEN-CENELEC CWA 18186:2025 - DPP designer guidance (portal, searchability, security/trust)](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Implementation guidance for DPP portal setup, searchability (API patterns), data longevity/availability, access control and security/trust mechanisms. - [GS1 - Digital Product Passport (standards landscape)](https://www.gs1.org/standards/standards-emerging-regulations/DPP?ref=sorena.io) - Identifier and data standards context useful for interoperable DPP implementations. ## Related Topic Guides - [DPP Applicability Test (ESPR Scoping) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/applicability-test.md): A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act. - [DPP Data Carriers, Access Control & UX | QR Code, Identifier, Public vs Restricted Views](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers. - [DPP Data Governance RACI Template | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field. - [DPP Data Requirements & Fields (Annex III) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III). - [DPP Governance, Verification & Audit Readiness | EU Digital Product Passport](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9). - [DPP Implementation Playbook & Vendor Selection | EU Digital Product Passport](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers. - [DPP QR Code Implementation Guide | Data Carrier + Identifier Design](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10). - [DPP vs Traditional Product Passports (Labels, PDFs, EPREL) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals. - [ESPR / DPP Penalties & Fines | EU Digital Product Passport Enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective. - [EU Digital Product Passport (DPP) Checklist | Audit-Ready Implementation Steps](/artifacts/eu/digital-product-passport/checklist.md): An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID). - [EU Digital Product Passport (DPP) Compliance Guide | Implementation Playbook](/artifacts/eu/digital-product-passport/compliance.md): A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements. - [EU Digital Product Passport (DPP) Deadlines & Compliance Calendar | ESPR 2024/1781](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024). - [EU Digital Product Passport (DPP) FAQ | ESPR 2024/1781](/artifacts/eu/digital-product-passport/faq.md): Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III). - [EU Digital Product Passport (DPP) Requirements | ESPR Articles 9-15 + Annex III](/artifacts/eu/digital-product-passport/requirements.md): A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9). - [What Is a Digital Product Passport (DPP)? | EU ESPR 2024/1781](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/architecture-and-integration --- --- title: "EU Digital Product Passport (DPP) Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/checklist" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/checklist" author: "Sorena AI" description: "An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID)." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "EU Digital Product Passport checklist" - "DPP checklist" - "DPP compliance checklist" - "ESPR 2024/1781 checklist" - "Annex III data mapping checklist" - "DPP QR code checklist" - "DPP registry checklist" - "DPP customs readiness" - "DPP audit checklist" - "DPP implementation steps" - "Annex III data mapping" - "data carrier QR" - "registry readiness" - "customs controls" - "open standards" - "audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Digital Product Passport (DPP) Checklist An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID). *Artifact Guide* *EU* ## EU Digital Product Passport (DPP) Checklist A checklist you can run per product group and ship against. Built for implementation reality: identifiers, carriers, access rights, registry, evidence, and vendor lock-in avoidance. DPP compliance is a system rollout. This checklist is structured in the order teams actually execute: scope -> data -> identifiers/carriers -> access control -> registry/customs -> security/evidence -> operations. Run it per product group and per DPP granularity level (model/batch/item). ## Checklist A - Scope and applicability (delegated act + product group) DPP obligations are product-group specific and are set in delegated acts adopted under ESPR Article 4. Your first deliverable is an applicability decision pack you can defend. - Identify product group + commodity codes covered; confirm if/when a delegated act requires a DPP for your group. - Confirm DPP level required: model vs batch vs item; write the implications for IDs, labeling, and lifecycle updates. - Map actor roles: manufacturer, authorised representative, importer, distributor, dealer, online marketplace; decide who creates/updates which fields. *Recommended next step* *Placement: after the checklist block* ## Operationalize EU Digital Product Passport (DPP) Checklist across ESG workflows ESG Compliance can take EU Digital Product Passport (DPP) Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Digital Product Passport (DPP) Checklist](/solutions/esg-compliance.md): Start from EU Digital Product Passport (DPP) Checklist and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Digital Product Passport (DPP)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) Checklist. ## Checklist B - Data model (Annex III subset + delegated act extensions) Annex III enumerates the classes of data that delegated acts can require in the DPP. Treat your data model as a canonical schema with provenance, versioning, and access classification. - Build a DPP data dictionary: Annex III fields you expect + definitions + validation rules. - Map each field to an authoritative source system (PLM/ERP/compliance repository/labeling systems) and assign a data owner and update SLAs. - Define public vs restricted fields and ensure public data is accessible without unnecessary friction. ## Checklist C - Identifiers and data carriers (Article 10 + Annex III) A DPP must be connected through a data carrier to a persistent unique product identifier; the data carrier must be physically present on product/packaging/documentation. This is the engineering heart of the DPP. - Define persistent unique product identifier scheme (model/batch/item) and resolver strategy (stable URLs/URIs). - Select carrier type(s) and test durability + scan reliability across lifecycle environments. - Implement distance selling support: provide dealers/online marketplaces a digital copy of carrier/identifier or link where customers can't physically access the product. ## Checklist D - Access rights and update governance (Articles 9 and 11) Delegated acts specify access rights and update rights. Article 11 requires free and easy access based on rights and restriction of modification rights accordingly. Design access control and audit logging before you build UI. - Implement role-based access to fields; enforce least privilege for update rights; add audit logs for reads/writes on restricted data. - Implement update workflow: validation, versioning, dispute resolution and correction handling. - Ensure data is accurate, complete and up to date; build monitoring and exception handling. ## Checklist E - Registry and customs readiness (Articles 13-15) ESPR requires an EU DPP registry (by 19 July 2026) and introduces customs workflows using the unique registration identifier once operational. Plan these integrations as operational dependencies with explicit SLAs. - Design registry upload pipeline for unique identifiers and any additional registry data required by delegated acts; store returned unique registration identifier. - Build process to provide registration identifier for release for free circulation when required; support automated verification where possible. - Align DPP identity layer with commodity codes for customs and traceability contexts. ## Checklist F - Architecture, interoperability and vendor selection (Article 10/11 constraints) Article 10 requires open standards, interoperable formats and transferability through an open interoperable data exchange network without vendor lock-in. Vendor selection should be driven by these constraints and by your ability to export/migrate. - Prove data exportability: schema + data + audit history can be exported without proprietary tooling. - Implement API-first architecture: canonical DPP layer powering multiple views and machine-readable exports. - Confirm service provider constraints: providers must not sell/reuse/process DPP data beyond what is necessary unless specifically agreed. ## Checklist G - Security, integrity, and evidence (audit readiness) Article 11 requires authentication, reliability and integrity, high security/privacy, and fraud avoidance. Build evidence into the system: provenance, change logs, and integrity controls. - Implement integrity controls for critical fields (identifiers and compliance docs) and tamper-evident audit logs. - Privacy control: do not store customer personal data without explicit consent; minimize and protect sensitive fields. - Evidence pack: map each DPP requirement to screenshots, API docs, change logs, and validation test results. ## Checklist H - Operations: keep DPP correct after go-live DPP is a live service. Most failures happen after launch: drift, broken links, outdated documents, or access control regressions. Define a cadence and incident response playbook. - Monitoring: resolution uptime, scan success rates, data freshness checks, access control regression tests. - Incident response: broken carrier resolution is a compliance incident; define on-call paths and hotfix procedures. - Periodic reviews: quarterly access/security review; annual evidence refresh and sampling audits per product group. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Checklist basis: Articles 9-15 and Annex III (data fields, carriers, access rights, registry, portal and customs controls). - [CEN-CENELEC CWA 18186:2025 - DPP designer guidance](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Implementation and procurement guidance: portal setup, searchability, longevity/availability, security/trust, and GDPR-aligned design. - [CIRPASS DPP System Architecture (D3.2, March 2024)](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - Reference architecture: decentralised approaches and product-centric identity patterns. ## Related Topic Guides - [DPP Applicability Test (ESPR Scoping) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/applicability-test.md): A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act. - [DPP Architecture & Integration (Open Standards, Registry, APIs) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/architecture-and-integration.md): An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers. - [DPP Data Carriers, Access Control & UX | QR Code, Identifier, Public vs Restricted Views](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers. - [DPP Data Governance RACI Template | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field. - [DPP Data Requirements & Fields (Annex III) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III). - [DPP Governance, Verification & Audit Readiness | EU Digital Product Passport](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9). - [DPP Implementation Playbook & Vendor Selection | EU Digital Product Passport](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers. - [DPP QR Code Implementation Guide | Data Carrier + Identifier Design](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10). - [DPP vs Traditional Product Passports (Labels, PDFs, EPREL) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals. - [ESPR / DPP Penalties & Fines | EU Digital Product Passport Enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective. - [EU Digital Product Passport (DPP) Compliance Guide | Implementation Playbook](/artifacts/eu/digital-product-passport/compliance.md): A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements. - [EU Digital Product Passport (DPP) Deadlines & Compliance Calendar | ESPR 2024/1781](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024). - [EU Digital Product Passport (DPP) FAQ | ESPR 2024/1781](/artifacts/eu/digital-product-passport/faq.md): Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III). - [EU Digital Product Passport (DPP) Requirements | ESPR Articles 9-15 + Annex III](/artifacts/eu/digital-product-passport/requirements.md): A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9). - [What Is a Digital Product Passport (DPP)? | EU ESPR 2024/1781](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/checklist --- --- title: "EU Digital Product Passport (DPP) Compliance Guide" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/compliance" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/compliance" author: "Sorena AI" description: "A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "EU Digital Product Passport compliance" - "DPP compliance guide" - "ESPR 2024/1781 compliance" - "DPP implementation guide" - "Annex III DPP data" - "DPP registry integration" - "DPP customs readiness" - "DPP open standards no vendor lock-in" - "DPP access rights" - "ESPR 2024/1781" - "Annex III" - "registry integration" - "data carrier QR" - "open standards" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Digital Product Passport (DPP) Compliance Guide A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements. *Artifact Guide* *EU* ## EU Digital Product Passport (DPP) Compliance Guide How to comply with DPP requirements - as shipped systems and operating processes. Built from ESPR Articles 9-15 + Annex III and implementation guidance from CWA and CIRPASS. DPP compliance is achieved when: (1) your product group obligations are scoped correctly, (2) DPPs are available and accessible as required, (3) data is accurate/complete/up to date, (4) access rights and security are enforced, and (5) registry/customs dependencies are handled. This guide shows the end-to-end compliance program you can execute. ## Phase 1 - Scope: delegated act coverage and DPP granularity Start with the delegated act for your product group: it specifies what data is required, what carriers to use, who can access and update which fields, and whether DPP is model/batch/item level. Treat the granularity decision as a system requirement that drives ID strategy, labeling costs, and lifecycle updates. - Confirm product group definition and commodity codes; identify the required Annex III data elements for the product group. - Lock DPP level (model/batch/item) and define what "model" or "batch" means for your product family and production process. - Create a roles map: manufacturer/importer/distributor/dealer/marketplace and who creates/updates each field. ## Phase 2 - Data: Annex III mapping, governance and evidence Annex III provides a structured list of data elements that can be required in a DPP (IDs, compliance docs, manuals, operator IDs, facility IDs, importer EORI, service provider references). Your job is to implement a canonical DPP data model with provenance, versioning, and SLAs for freshness. - Build a canonical schema: structured, machine-readable fields for identity and compliance evidence; store document references and hashes/signatures where appropriate. - Map each field to a source system and owner; define update triggers and validation rules. - Implement data quality monitoring: "accurate, complete, up to date" as measurable requirements. ## Phase 3 - Identity and carriers: persistent identifiers + physical data carriers Article 10 requires a data carrier connected to a persistent unique product identifier and physical presence on the product/packaging/documentation. Implement this like a hardware rollout: print processes, placement specs, durability tests, and fallback access for distance selling. - Define identifier scheme(s) and a stable resolver; avoid vendor-specific URLs that break on migration. - Select carriers (QR/2D code, RFID/EPC, etc.) and validate scan reliability across lifecycle environments. - Enable distance selling: provide dealers/online marketplaces a digital copy of carrier/identifier or link where physical access isn't possible. ## Phase 4 - Access rights and UX: public vs restricted views Delegated acts define which actors can access what data and who can update what data. Article 11 requires free and easy access based on those rights. Build multiple views off one dataset: a public consumer view and restricted role-based views with audit logs. - Public view: pre-purchase access, including distance selling; avoid collecting personal data for public access. - Restricted view: authentication, role-based access, and audit logging; ensure update rights are restricted per delegated act. - Lifecycle linking: if a new DPP is created, link to original DPP(s) and preserve history. ## Phase 5 - Registry, portal and customs readiness ESPR requires an EU DPP registry (by 19 July 2026) and a web portal, and introduces customs workflows using the unique registration identifier once the registry is operational. Plan registry integration and customs flows early, even if your delegated act is not yet live. - Registry: build an upload pipeline for unique identifiers and additional delegated-act registry fields; store the unique registration identifier returned. - Portal: ensure public data is searchable/compareable and restricted data remains protected by rights. - Customs: be able to provide the unique registration identifier for release for free circulation; support automated verification flows where possible. ## Phase 6 - Architecture: open standards, interoperability and no vendor lock-in Article 10 requires open standards, interoperable formats and transferability through an open interoperable network without vendor lock-in. You should be able to migrate providers without reprinting labels or losing audit history. - API-first design: canonical DPP layer with stable schemas, exportability, and view renderers. - Interoperability: align technical, semantic and organisational aspects so DPP can interact across actors and product groups. - Service provider constraints: providers must not sell/reuse/process DPP data beyond what is necessary unless specifically agreed. ## Operate DPP as a service: monitoring and incident response The compliance target is long-lived availability and correctness. Broken resolution, stale docs, or access regressions become compliance issues. Run DPP with SLOs and an incident playbook. - SLOs: resolver uptime, scan success rates, freshness SLAs for key fields, and access control regression tests. - Audit drills: periodically produce evidence that DPP meets Article 10/11 requirements (IDs, carriers, access, security). - Continuous improvement: iterate based on stakeholder feedback (repairers, recyclers, authorities) and delegated act updates. *Recommended next step* *Placement: after the compliance steps* ## Operationalize EU Digital Product Passport (DPP) Compliance Guide across ESG workflows ESG Compliance can take EU Digital Product Passport (DPP) Compliance Guide from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Digital Product Passport (DPP) Compliance Guide](/solutions/esg-compliance.md): Start from EU Digital Product Passport (DPP) Compliance Guide and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Digital Product Passport (DPP)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) Compliance Guide. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Core compliance baseline: Articles 9-15 and Annex III (availability, essential requirements, access rights, registry, portal and customs controls). - [European Commission - ESPR overview page (DPP purpose and implementation)](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Implementation context, DPP purpose, and consumer/authority use cases. - [CEN-CENELEC CWA 18186:2025 - DPP designer guidance](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Implementation guidance for portal access, searchability, data availability, security/trust and procurement briefs. - [CIRPASS DPP System Architecture (D3.2, March 2024)](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - Reference architecture and interoperability patterns for DPP systems. ## Related Topic Guides - [DPP Applicability Test (ESPR Scoping) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/applicability-test.md): A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act. - [DPP Architecture & Integration (Open Standards, Registry, APIs) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/architecture-and-integration.md): An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers. - [DPP Data Carriers, Access Control & UX | QR Code, Identifier, Public vs Restricted Views](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers. - [DPP Data Governance RACI Template | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field. - [DPP Data Requirements & Fields (Annex III) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III). - [DPP Governance, Verification & Audit Readiness | EU Digital Product Passport](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9). - [DPP Implementation Playbook & Vendor Selection | EU Digital Product Passport](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers. - [DPP QR Code Implementation Guide | Data Carrier + Identifier Design](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10). - [DPP vs Traditional Product Passports (Labels, PDFs, EPREL) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals. - [ESPR / DPP Penalties & Fines | EU Digital Product Passport Enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective. - [EU Digital Product Passport (DPP) Checklist | Audit-Ready Implementation Steps](/artifacts/eu/digital-product-passport/checklist.md): An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID). - [EU Digital Product Passport (DPP) Deadlines & Compliance Calendar | ESPR 2024/1781](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024). - [EU Digital Product Passport (DPP) FAQ | ESPR 2024/1781](/artifacts/eu/digital-product-passport/faq.md): Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III). - [EU Digital Product Passport (DPP) Requirements | ESPR Articles 9-15 + Annex III](/artifacts/eu/digital-product-passport/requirements.md): A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9). - [What Is a Digital Product Passport (DPP)? | EU ESPR 2024/1781](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/compliance --- --- title: "DPP Data Carriers, Access Control & UX" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux" author: "Sorena AI" description: "A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "DPP data carrier" - "DPP QR code" - "Digital Product Passport QR code" - "unique product identifier DPP" - "DPP access control" - "public vs restricted DPP data" - "DPP UX" - "DPP distance selling" - "DPP pre-purchase access" - "DPP security and trust" - "unique product identifier" - "access control" - "public vs restricted data" - "distance selling" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DPP Data Carriers, Access Control & UX A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers. *Artifact Guide* *EU* ## EU Digital Product Passport (DPP) Data Carriers, Access Control & UX Make DPP scanning and access journeys compliant, usable, and audit-ready. Grounded in ESPR Articles 9-11 + CWA 18186 guidance: physical carriers, stable identifiers, differentiated access rights, and security/trust. The DPP's success depends on what happens in the first 10 seconds after scanning a code: does it resolve reliably, is the public information accessible before purchase, and are restricted fields protected by correct access rights? ESPR turns these UX questions into legal requirements (data carrier, identifier persistence, pre-purchase access, access rights, security and fraud prevention). ## Data carrier basics (Article 10): what must be true in the real world A DPP must be connected through a data carrier to a persistent unique product identifier. The data carrier must be physically present on the product, its packaging, or accompanying documentation, as specified by the applicable delegated act. - Carrier choice depends on environment and lifecycle: durability, abrasion, chemical exposure, heat, and end-of-life handling. - Carrier placement is a compliance requirement: delegated acts specify layout and positioning - build it into packaging and labeling workflows. - Plan for failures: damaged labels, offline environments, and secondary packaging loss should have fallback access paths. ## Identifier and resolution: build a DPP resolver you can trust Scanning must reliably resolve to the correct DPP view (model/batch/item), and it must remain resolvable for the availability period defined by the delegated act (at least expected lifetime). If DPP versions change, the new DPP must link to the original DPP(s). - Use stable, persistent identifiers; avoid embedding vendor-specific routing logic that breaks on migration. - Implement version linking and change history; ensure old identifiers still resolve to correct current information. - Support multi-channel access: scan -> URL; web search -> DPP; product page -> DPP (distance selling). ## Public vs restricted data: design differentiated access rights (Articles 9 and 11) Delegated acts define who can access which fields and who can update which fields. Article 11 requires free and easy access based on those access rights and restriction of modification rights accordingly. Architecturally, this means multiple views backed by a single canonical dataset with access control and audit logs. - Public view: optimized for consumers; no unnecessary authentication; avoid collecting personal data for public DPP access. - Restricted view: strong authentication, role-based field access, and audit logging for reads and writes. - Write access: enforce least privilege; validate updates; preserve provenance and version history; support dispute resolution and correction workflows. ## Pre-purchase access (including distance selling): don't bury DPP behind post-purchase flows Delegated acts must specify how the DPP is made accessible to customers before they are bound by a contract, including in distance selling. This is a UX + commerce integration requirement: your DPP needs a "consumer-ready" public view that is stable and accessible at the point of decision. - In-store: scanning a carrier should open the public view instantly; support accessibility and multilingual content where required. - Online marketplaces and dealers: they may need a digital copy of the carrier or unique identifier; build automated sharing and time-bound SLAs for requests. - No dark patterns: the DPP should support informed choice; ensure the "public view" includes required sustainability/compliance information. ## Security, privacy and anti-fraud design (Article 11 + CWA guidance) Article 11 requires data authentication, reliability and integrity, a high level of security and privacy, and fraud avoidance. CWA guidance highlights practical design choices: encryption for sensitive data, signatures for tamper detection, and identity mechanisms for controlled access. - Integrity: signed payloads or signed references for key fields (identifiers, compliance docs) + tamper-evident audit logs. - Privacy: do not store customers' personal data in DPP without explicit consent; isolate restricted data and encrypt at rest/in transit. - Carrier authentication: for high-risk categories, consider authenticated carriers (anti-counterfeit) and verified resolution endpoints. - Service providers: if DPP data is stored/processed by a service provider, the provider must not sell/reuse/process the data beyond what is necessary for the service unless specifically agreed. ## UX patterns that improve usability without breaking compliance A DPP UI is a "multi-audience document": consumers, repairers, recyclers, authorities. Avoid trying to show everything to everyone in one screen. Use progressive disclosure: public summary first, then role-based sections with clear labels and evidence links. - Public landing page: identity summary, sustainability highlights, safety warnings (where applicable), and "verify authenticity" indicators. - Role-based tabs/sections: repair, refurbish, recycle, compliance docs, authority-only fields (where allowed). - Searchability: provide stable URLs and machine-readable API endpoints for public data where appropriate (CWA guidance). *Recommended next step* *Placement: after the main workflow section* ## Operationalize EU Digital Product Passport (DPP) Data Carriers, Access Control & UX across ESG workflows ESG Compliance can take EU Digital Product Passport (DPP) Data Carriers, Access Control & UX from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Digital Product Passport (DPP) Data Carriers, Access Control & UX](/solutions/esg-compliance.md): Start from EU Digital Product Passport (DPP) Data Carriers, Access Control & UX and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Digital Product Passport (DPP)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) Data Carriers, Access Control & UX. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Data carrier + identifier requirements (Article 10), access rights and design/operation requirements (Articles 9 and 11), and availability requirements. - [CEN-CENELEC CWA 18186:2025 - DPP portal access, searchability, and security/trust guidance](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Practical UX and access guidance: public vs restricted access, information searchability, longevity/availability, security/trust and GDPR-aligned design. - [European Commission - ESPR overview (DPP rationale and customs checks)](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - High-level DPP purpose: support informed decisions and enable customs/authorities to perform checks. - [GS1 - Digital Product Passport (standards landscape)](https://www.gs1.org/standards/standards-emerging-regulations/DPP?ref=sorena.io) - Identifier and carrier standards ecosystem useful for interoperable carrier/ID implementations. ## Related Topic Guides - [DPP Applicability Test (ESPR Scoping) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/applicability-test.md): A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act. - [DPP Architecture & Integration (Open Standards, Registry, APIs) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/architecture-and-integration.md): An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers. - [DPP Data Governance RACI Template | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field. - [DPP Data Requirements & Fields (Annex III) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III). - [DPP Governance, Verification & Audit Readiness | EU Digital Product Passport](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9). - [DPP Implementation Playbook & Vendor Selection | EU Digital Product Passport](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers. - [DPP QR Code Implementation Guide | Data Carrier + Identifier Design](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10). - [DPP vs Traditional Product Passports (Labels, PDFs, EPREL) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals. - [ESPR / DPP Penalties & Fines | EU Digital Product Passport Enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective. - [EU Digital Product Passport (DPP) Checklist | Audit-Ready Implementation Steps](/artifacts/eu/digital-product-passport/checklist.md): An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID). - [EU Digital Product Passport (DPP) Compliance Guide | Implementation Playbook](/artifacts/eu/digital-product-passport/compliance.md): A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements. - [EU Digital Product Passport (DPP) Deadlines & Compliance Calendar | ESPR 2024/1781](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024). - [EU Digital Product Passport (DPP) FAQ | ESPR 2024/1781](/artifacts/eu/digital-product-passport/faq.md): Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III). - [EU Digital Product Passport (DPP) Requirements | ESPR Articles 9-15 + Annex III](/artifacts/eu/digital-product-passport/requirements.md): A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9). - [What Is a Digital Product Passport (DPP)? | EU ESPR 2024/1781](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux --- --- title: "DPP Data Requirements & Fields (Annex III)" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/data-requirements-and-fields" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/data-requirements-and-fields" author: "Sorena AI" description: "A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III)." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "DPP data requirements" - "Annex III Digital Product Passport" - "DPP data fields" - "DPP GTIN" - "DPP TARIC code" - "DPP EORI" - "DPP technical documentation" - "DPP declaration of conformity" - "DPP compliance documentation" - "DPP data model" - "DPP data governance" - "Annex III" - "GTIN" - "TARIC" - "EORI" - "technical documentation" - "declaration of conformity" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DPP Data Requirements & Fields (Annex III) A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III). *Artifact Guide* *EU* ## EU Digital Product Passport (DPP) Data Requirements & Fields Build the DPP data model that delegated acts will actually require - without guesswork. Grounded in ESPR Annex III and the DPP operating requirements in Articles 9-11. DPP implementations often fail because the data model is treated as "content". Under ESPR (Regulation (EU) 2024/1781), delegated acts specify which Annex III elements are required for a product group and who can access/update them. Use this page to build a canonical data model, map it to source systems, and set up governance for accuracy, completeness and lifecycle updates. ## Annex III in one view: the DPP data field universe Annex III lists the categories of data that delegated acts can require (or allow) in a DPP. Product-group rules then choose which elements apply and at what level (model/batch/item). A useful way to implement Annex III is to treat each element as a "field family" with: source system, owner, update frequency, and access classification (public vs restricted). - Identity + classification: unique product identifier, commodity codes (e.g., TARIC), and GTIN (ISO/IEC 15459-6 or equivalent) where applicable. - Compliance evidence: declaration of conformity, technical documentation, conformity certificates and other compliance documentation under EU law. - User information: manuals, instructions, warnings and safety information required under EU law. - Operator metadata: manufacturer/operator identifiers, importer info (including EORI), facility identifiers, and DPP service provider back-up reference. ## Field-by-field mapping: what Annex III contains (plain language) Below is a practical mapping of the Annex III items into implementation-ready language. Your product-group delegated act will select from this list. Treat this as your data dictionary baseline. - Other EU-law information requirements: any data required under ESPR information requirements or other EU law applicable to the product group. - Unique product identifier: the core key used by the data carrier to resolve the DPP, at the DPP level (model/batch/item). - GTIN: a globally standard product identifier (where relevant), enabling interoperability across supply chain systems. - Commodity code: classification for trade/customs contexts (supports customs checks when registry is operational). - Compliance documentation: declaration of conformity, technical documentation, and certificates needed for compliance verification. - Manuals and safety info: user manuals, instructions, warnings and safety information where required. - Manufacturer identity: operator identifier + contact information required under ESPR obligations. - Other operator identities: identifiers for other relevant actors (suppliers, authorised representatives, service providers) depending on delegated act design. - Facility identifiers: identifiers for facilities relevant to manufacturing/location metadata. - Importer data: importer identity and EORI number where relevant. - EU responsible operator: the EU-established operator responsible for tasks under market surveillance/product safety frameworks (where applicable). - DPP service provider reference: who hosts the back-up copy of the most up-to-date DPP version. ## Where the data lives: source systems you typically need DPP data is cross-domain: no single system has it all. The practical solution is a canonical DPP data layer fed by authoritative sources. The data carrier/identifier strategy determines how those sources are resolved into a stable DPP view. - PLM/PIM: model identifiers, product specs, BOM/material composition, variants and technical performance data. - ERP/SCM: batch context, facility metadata, supplier/operator references, trade classification inputs. - Compliance repository: declarations of conformity, certificates, test reports, and technical documentation references. - Labeling/packaging systems: carrier generation, placement rules, print files, and linking to unique identifiers. - Service and repair systems: repair logs, spare parts and maintenance instructions where required by product-group rules. ## Granularity changes everything: model vs batch vs item DPP data Delegated acts must specify whether the DPP is at model, batch or item level. Your data architecture must match that. Item-level DPP typically requires event-driven updates; model-level DPP can be release-driven. - Model-level: shared data set; focus on versioning, documentation updates, and consistent pre-purchase access. - Batch-level: add manufacturing and facility context; ensure batch identifiers map correctly to compliance and origin data. - Item-level: manage per-unit identifiers, ownership/service lifecycle, and linking across passport versions. ## Access control and update rights: data governance requirements ESPR requires that actors along the value chain have free and easy access to data based on their access rights, and that rights to modify/update data are restricted by those rights. You need to design public vs restricted data, authentication, and audit logs from the start. - Public data should be accessible without forcing app downloads or personal data collection; restricted data should use secure authentication and least-privilege access. - Implement an update workflow: who can change what, what validation rules apply, and how changes are audited and reversible. - Data quality controls: define SLAs for "accurate, complete, up to date", with monitoring and exception handling. *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU Digital Product Passport (DPP) Data Requirements & Fields across ESG workflows ESG Compliance can take EU Digital Product Passport (DPP) Data Requirements & Fields from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Digital Product Passport (DPP) Data Requirements & Fields](/solutions/esg-compliance.md): Start from EU Digital Product Passport (DPP) Data Requirements & Fields and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Digital Product Passport (DPP)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) Data Requirements & Fields. ## Audit-ready DPP data model: the minimum evidence you should store Auditors and authorities care about proof: where data came from, who changed it, and whether it was valid at the time a product was placed on the market. Build evidence into the data model: provenance, timestamps, signatures, and document references. - Provenance: source system and authoritative owner per field; document references for compliance fields. - Change history: timestamps, actors, and reason codes for updates (especially for restricted fields). - Integrity controls: authentication, signatures or hashes where appropriate; version linking when DPP is replaced. - Availability: ensure DPP remains available for the delegated act period, including after operator insolvency (service provider back-up strategy). ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Annex III (DPP data elements)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Annex III enumerates the DPP data elements that delegated acts can require (IDs, commodity codes, compliance docs, manuals, operator and facility identifiers, importer EORI, service provider references). - [CEN-CENELEC CWA 18186:2025 - DPP data portal, searchability and governance guidance](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Practical guidance on portal setup, searchability, access rights, longevity and availability of DPP data access, and security/trust. - [CIRPASS DPP Use Cases Report (D2.2, March 2024) - why certain data matters](https://doi.org/10.5281/zenodo.10974901?ref=sorena.io) - Use cases across batteries, electronics and textiles that highlight the value of DPP data for reuse, refurbishment and recycling outcomes. - [GS1 - Digital Product Passport (standards and emerging regulations)](https://www.gs1.org/standards/standards-emerging-regulations/DPP?ref=sorena.io) - Identifier and data standards landscape relevant for DPP interoperability (e.g., GTIN and related GS1 building blocks). ## Related Topic Guides - [DPP Applicability Test (ESPR Scoping) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/applicability-test.md): A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act. - [DPP Architecture & Integration (Open Standards, Registry, APIs) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/architecture-and-integration.md): An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers. - [DPP Data Carriers, Access Control & UX | QR Code, Identifier, Public vs Restricted Views](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers. - [DPP Data Governance RACI Template | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field. - [DPP Governance, Verification & Audit Readiness | EU Digital Product Passport](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9). - [DPP Implementation Playbook & Vendor Selection | EU Digital Product Passport](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers. - [DPP QR Code Implementation Guide | Data Carrier + Identifier Design](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10). - [DPP vs Traditional Product Passports (Labels, PDFs, EPREL) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals. - [ESPR / DPP Penalties & Fines | EU Digital Product Passport Enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective. - [EU Digital Product Passport (DPP) Checklist | Audit-Ready Implementation Steps](/artifacts/eu/digital-product-passport/checklist.md): An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID). - [EU Digital Product Passport (DPP) Compliance Guide | Implementation Playbook](/artifacts/eu/digital-product-passport/compliance.md): A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements. - [EU Digital Product Passport (DPP) Deadlines & Compliance Calendar | ESPR 2024/1781](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024). - [EU Digital Product Passport (DPP) FAQ | ESPR 2024/1781](/artifacts/eu/digital-product-passport/faq.md): Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III). - [EU Digital Product Passport (DPP) Requirements | ESPR Articles 9-15 + Annex III](/artifacts/eu/digital-product-passport/requirements.md): A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9). - [What Is a Digital Product Passport (DPP)? | EU ESPR 2024/1781](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/data-requirements-and-fields --- --- title: "EU Digital Product Passport (DPP) Deadlines & Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024)." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "EU Digital Product Passport deadlines" - "DPP compliance calendar" - "ESPR 2024/1781 timeline" - "DPP registry 19 July 2026" - "DPP entry into force 18 July 2024" - "DPP delegated acts 19 July 2025" - "DPP customs controls" - "DPP key dates" - "DPP deadlines" - "ESPR timeline" - "DPP registry 2026" - "delegated acts" - "customs controls" - "compliance calendar" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Digital Product Passport (DPP) Deadlines & Compliance Calendar A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024). *Artifact Guide* *EU* ## EU Digital Product Passport (DPP) Deadlines & Compliance Calendar Turn ESPR milestones into calendar entries your teams can ship against. Includes registry and customs readiness, delegated act timing constraints, and audit/evidence cadence planning. DPP timelines are product-group specific (driven by delegated acts), but ESPR provides hard anchors that your program should calendarize now: entry into force, working-plan sequencing, delegated act constraints, registry deadline, and the portal and customs system dependencies. This page turns those anchors into a compliance calendar template. ## Hard anchors from ESPR (dates you can put on a calendar today) Even before your product group is covered by a delegated act, ESPR sets baseline milestones that affect architecture and readiness planning. Use these anchors to plan platform capability build-out and supplier onboarding. - 18 Jul 2024: ESPR entered into force (20 days after publication in the Official Journal on 28 Jun 2024). - 19 Apr 2025: deadline for the Commission to adopt the first ESPR working plan. - Apr 2025: first ESPR working plan for 2025-2030 released, giving the first concrete signal on which product groups will move first. - 19 Jul 2025: the first delegated act adopted under ESPR Article 4 must not enter into force before this date (timing constraint on product-group rules). - By 19 Jul 2026: Commission must set up the EU digital product passport registry storing at least unique identifiers (and commodity codes for release-for-free-circulation products). *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU Digital Product Passport (DPP) Deadlines & Compliance Calendar across ESG workflows ESG Compliance can take EU Digital Product Passport (DPP) Deadlines & Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Digital Product Passport (DPP) Deadlines & Compliance Calendar](/solutions/esg-compliance.md): Start from EU Digital Product Passport (DPP) Deadlines & Compliance Calendar and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Digital Product Passport (DPP)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) Deadlines & Compliance Calendar. ## Current DPP program milestones (what changed after ESPR entered into force) The period after ESPR entry into force matters because the Commission has already started defining the operating model for DPP service-provider storage and governance. Use these dates as program-governance milestones, even if your delegated act is still pending. - 9 Apr 2025: the Commission launched a public consultation on future DPP rules for service providers. - 1 Jul 2025: deadline for feedback to that service-provider consultation. - 2028: the first ESPR working plan is expected to be reviewed and revised, which can shift product-group sequencing and DPP rollout expectations. ## Your DPP calendar template (per product group / per DPP level) Delegated acts specify DPP level (model/batch/item), carrier details, access rights, and availability period. Your calendar should mirror that. Create a calendar per product group and per DPP level - item-level DPP typically requires more lifecycle events. - T0: delegated act adopted (start "requirements finalization" and gap assessment). - T0 + internal lead time: data model freeze (Annex III subset), identifier scheme, and carrier design freeze. - T0 + implementation window: portal and access control build + integration with source systems (PLM/ERP/labeling/compliance docs). - Go-live readiness: pre-purchase access in store and distance selling; audit logging; evidence pack ready. - Ongoing: update workflows for new versions, repairs/refurbishment updates where required, and data quality monitoring. ## Registry readiness milestones (Article 13 + customs dependency chain) ESPR introduces an EU registry and a unique registration identifier associated with uploaded unique identifiers. That identifier becomes a compliance control surface for customs once operational. Treat registry integration like a payment integration: it affects go-live sequencing, error handling, and operational SLAs. - Plan upload pipeline: unique identifiers (and any additional registry data specified in delegated acts) must be uploaded by the economic operator placing the product on the market. - Plan for the unique registration identifier response: store it, version it, and expose it where required for customs workflows. - Customs: once registry operational, release for free circulation requires providing/making available the unique registration identifier; customs verify electronically and automatically when interconnections are operational. ## Customer access deadlines (pre-purchase access and distance selling) Delegated acts must specify how the DPP is made accessible to customers before they are bound by a contract - including distance selling. This requirement should be translated into explicit product deliverables and tests. - In-store: data carrier scannable and positioned per delegated act; public DPP view accessible without unnecessary friction. - Online: product pages must expose the DPP public view and unique identifier (or a link), with consistent access rights and stable URLs. - Operational control: ensure dealers/online marketplaces can receive a digital copy of the carrier/identifier or link quickly (Article 10 obligations). ## Audit and evidence cadence (how to stay compliant after launch) ESPR requires DPP data to be accurate, complete and up to date. That implies governance, monitoring, and periodic review. Treat this as an operating cadence: you don't "finish" a DPP - you operate it. - Monthly: data quality checks for high-risk fields (compliance docs, operator IDs, manuals, identifiers). - Quarterly: access rights review and security/privacy review, especially for restricted data and credentials. - Annually (or per delegated act): evidence refresh and sampling audits for traceability and authenticity (registry linkage, identifier resolvability). ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Entry into force, first delegated act constraint, DPP registry deadline (Article 13), and customs control mechanics (Article 15). - [European Commission - ESPR Working Plan 2025-2030 (implementation sequencing)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52025DC0187&ref=sorena.io) - Working plan context that helps anticipate when product groups may be prioritised for delegated acts and DPP requirements. - [European Commission - DPP service-provider consultation launch (9 Apr 2025)](https://single-market-economy.ec.europa.eu/news/commission-launches-consultation-digital-product-passport-2025-04-09_en?ref=sorena.io) - Current implementation milestone for storage, management, and possible certification rules for DPP service providers. - [European Commission - ESPR overview page (implementation approach)](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - High-level implementation process, stakeholder consultation, and DPP purpose for consumers and authorities. - [CEN-CENELEC CWA 18186:2025 - DPP design guidance (roadmaps and system dependencies)](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Practical DPP program sequencing guidance across product groups and system components. ## Related Topic Guides - [DPP Applicability Test (ESPR Scoping) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/applicability-test.md): A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act. - [DPP Architecture & Integration (Open Standards, Registry, APIs) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/architecture-and-integration.md): An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers. - [DPP Data Carriers, Access Control & UX | QR Code, Identifier, Public vs Restricted Views](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers. - [DPP Data Governance RACI Template | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field. - [DPP Data Requirements & Fields (Annex III) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III). - [DPP Governance, Verification & Audit Readiness | EU Digital Product Passport](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9). - [DPP Implementation Playbook & Vendor Selection | EU Digital Product Passport](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers. - [DPP QR Code Implementation Guide | Data Carrier + Identifier Design](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10). - [DPP vs Traditional Product Passports (Labels, PDFs, EPREL) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals. - [ESPR / DPP Penalties & Fines | EU Digital Product Passport Enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective. - [EU Digital Product Passport (DPP) Checklist | Audit-Ready Implementation Steps](/artifacts/eu/digital-product-passport/checklist.md): An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID). - [EU Digital Product Passport (DPP) Compliance Guide | Implementation Playbook](/artifacts/eu/digital-product-passport/compliance.md): A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements. - [EU Digital Product Passport (DPP) FAQ | ESPR 2024/1781](/artifacts/eu/digital-product-passport/faq.md): Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III). - [EU Digital Product Passport (DPP) Requirements | ESPR Articles 9-15 + Annex III](/artifacts/eu/digital-product-passport/requirements.md): A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9). - [What Is a Digital Product Passport (DPP)? | EU ESPR 2024/1781](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar --- --- title: "DPP Data Governance RACI Template" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template" author: "Sorena AI" description: "Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "DPP RACI template" - "Digital Product Passport governance template" - "DPP data governance" - "Annex III field ownership" - "DPP update workflow template" - "DPP access control governance" - "DPP data quality SLA" - "DPP audit evidence template" - "DPP template" - "RACI" - "data governance" - "Annex III fields" - "access rights" - "audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DPP Data Governance RACI Template Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field. *Template* *EU* ## EU Digital Product Passport (DPP) Data Governance RACI Template Assign owners for DPP data, access rights and lifecycle updates - the fastest way to avoid stale passports. Aligned to ESPR Articles 9-11 (data quality, access rights, restricted update rights, security and integrity). DPP governance is the difference between "a portal" and "a compliant DPP system". ESPR requires DPP data to be accurate, complete and up to date, and requires restricting update rights by actor type. Use the templates below to assign ownership, define update SLAs, and build an audit-ready operating model. ## How to use this template (recommended operating model) Run governance per product group and per DPP level (model/batch/item). One governance model rarely fits all product groups because delegated acts specify different fields and access rights. Use RACI at two layers: (1) data element ownership (Annex III fields), and (2) lifecycle event ownership (create/update/verify). - Step 1: paste Annex III field list and mark which fields are required by your delegated act. - Step 2: assign RACI for each required field: Responsible, Accountable, Consulted, Informed. - Step 3: define update triggers and SLAs per field; build monitoring for data freshness. - Step 4: define access rights governance: who approves roles and who audits rights. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Digital Product Passport (DPP) Data Governance RACI Template in one governed evidence system SSOT can take EU Digital Product Passport (DPP) Data Governance RACI Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Digital Product Passport (DPP) Data Governance RACI Template](/solutions/ssot.md): Start from EU Digital Product Passport (DPP) Data Governance RACI Template and keep documents, evidence, and control records in one governed system. - [Talk through EU Digital Product Passport (DPP)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) Data Governance RACI Template. ## RACI template: Annex III field ownership (copy/paste) Use this as a baseline and tailor to your org structure. The key is to assign one Accountable owner per field family. Roles below are illustrative. Replace with your teams. - Identity layer (unique product identifier, GTIN, commodity codes): R = Product data engineering; A = Product operations; C = Legal/compliance, Supply chain; I = Sales/retail partners. - Compliance documentation (DoC, technical documentation, certificates): R = Regulatory compliance; A = Legal; C = Engineering quality, External labs; I = Sales, Support. - Manuals/instructions/warnings: R = Technical publications; A = Product; C = Safety/legal; I = Support. - Operator identifiers (manufacturer/importer/responsible operator): R = Legal entity management; A = Legal; C = Supply chain; I = Product. - Facility identifiers: R = Manufacturing operations; A = Ops; C = Compliance; I = Product. - Service provider back-up reference: R = Platform engineering; A = Security; C = Legal/procurement; I = Compliance. ## Lifecycle RACI: create, update, verify (copy/paste) Delegated acts specify who can create/update fields. Your governance should add a verification layer and a correction workflow. Use the lifecycle RACI to avoid silent drift. - Create DPP: R = Product data engineering; A = Responsible economic operator (REO); C = Compliance; I = Dealers/marketplaces. - Update identity fields: R = Product data engineering; A = Product operations; C = Supply chain; I = Compliance. - Update compliance docs: R = Regulatory compliance; A = Legal; C = Engineering quality; I = Authorities (as applicable). - Verify updates: R = Compliance assurance; A = Compliance leadership; C = Security; I = Product. - Correct disputed data: R = Compliance; A = Legal; C = Engineering; I = Stakeholders affected. ## Data quality SLAs: define "accurate, complete and up to date" ESPR explicitly requires DPP data to be accurate, complete and up to date. Make those words measurable. Define SLAs per field family and enforce them with monitoring. - Accuracy: validation rules, allowed values, and cross-system consistency checks. - Completeness: required fields per delegated act; missing-field thresholds; launch gates. - Freshness: maximum age per field (e.g., compliance docs within X days of update, manuals within X days of release). - Evidence: change logs, actor IDs, timestamps, and approval records stored for audits. ## Access-rights governance (public vs restricted data) Article 11 requires access based on rights and restricts modification rights accordingly. Treat access as a governed asset. This template helps you define who can grant access and how access is reviewed. - Role catalog: define actor types (customer, repairer, recycler, authority, importer, dealer) and their allowed fields. - Approval workflow: who approves granting restricted access; how identity is verified; what evidence is retained. - Audit cadence: quarterly review of roles and access logs; automated anomaly detection for unusual access patterns. - Public access principle: public DPP data should be accessible without forced apps or personal data collection. ## Incident response template (broken links, stale docs, access regressions) DPP issues are compliance incidents. Define an incident playbook with severity levels and time-to-mitigate goals. Use this template to operationalise response. - Incidents: resolver outage, carrier misprint, wrong product mapping, outdated compliance doc, access rights bug, suspected fraud. - Actions: triage -> isolate -> hotfix -> verify -> record evidence -> post-incident review. - Metrics: mean time to detect, mean time to restore resolution, and number of impacted products/actors. - Evidence retention: incident ticket, root cause analysis, and remediation proof. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Data quality requirement (Article 9), access rights and restricted modification rights (Article 9(2) and Article 11), and security/integrity requirements (Article 11), plus Annex III data field classes. - [CEN-CENELEC CWA 18186:2025 - DPP designer guidance (governance, trust and security)](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Practical governance guidance: portal setup, access rights, searchability, longevity/availability, security and trust mechanisms. ## Related Topic Guides - [DPP Applicability Test (ESPR Scoping) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/applicability-test.md): A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act. - [DPP Architecture & Integration (Open Standards, Registry, APIs) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/architecture-and-integration.md): An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers. - [DPP Data Carriers, Access Control & UX | QR Code, Identifier, Public vs Restricted Views](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers. - [DPP Data Requirements & Fields (Annex III) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III). - [DPP Governance, Verification & Audit Readiness | EU Digital Product Passport](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9). - [DPP Implementation Playbook & Vendor Selection | EU Digital Product Passport](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers. - [DPP QR Code Implementation Guide | Data Carrier + Identifier Design](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10). - [DPP vs Traditional Product Passports (Labels, PDFs, EPREL) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals. - [ESPR / DPP Penalties & Fines | EU Digital Product Passport Enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective. - [EU Digital Product Passport (DPP) Checklist | Audit-Ready Implementation Steps](/artifacts/eu/digital-product-passport/checklist.md): An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID). - [EU Digital Product Passport (DPP) Compliance Guide | Implementation Playbook](/artifacts/eu/digital-product-passport/compliance.md): A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements. - [EU Digital Product Passport (DPP) Deadlines & Compliance Calendar | ESPR 2024/1781](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024). - [EU Digital Product Passport (DPP) FAQ | ESPR 2024/1781](/artifacts/eu/digital-product-passport/faq.md): Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III). - [EU Digital Product Passport (DPP) Requirements | ESPR Articles 9-15 + Annex III](/artifacts/eu/digital-product-passport/requirements.md): A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9). - [What Is a Digital Product Passport (DPP)? | EU ESPR 2024/1781](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template --- --- title: "DPP QR Code Implementation Guide" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide" author: "Sorena AI" description: "A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10)." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "DPP QR code implementation" - "Digital Product Passport QR code" - "DPP data carrier" - "unique product identifier QR" - "DPP QR code placement" - "DPP QR code durability" - "DPP resolver" - "DPP distance selling" - "DPP QR code security" - "DPP anti-counterfeit" - "DPP QR code" - "persistent identifier" - "resolver design" - "distance selling" - "anti-fraud" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DPP QR Code Implementation Guide A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10). *Artifact Guide* *EU* ## EU Digital Product Passport (DPP) QR Code Implementation Guide Design QR/data carrier implementations that stay resolvable for the product lifetime. Grounded in ESPR Article 10 + Annex III: data carrier, persistent unique product identifier, and standards-based IDs. A DPP QR code is not "just a link". Under ESPR, the data carrier must connect to a persistent unique product identifier, be physically present on the product/packaging/documentation, and support pre-purchase access. This guide focuses on the implementation details that prevent broken resolution, audit failures, and costly re-labeling programs. ## What ESPR requires from the data carrier (Article 10) A digital product passport must be connected through a data carrier to a persistent unique product identifier. The data carrier must be physically present on the product, its packaging or documentation accompanying the product, as specified by delegated acts. - Your carrier strategy must work across the entire lifecycle: manufacturing, logistics, retail, repair/refurbish, and end-of-life. - Delegated acts may specify layout and positioning - treat this as a packaging spec requirement. - Identifiers and carriers should comply with standards referenced in Annex III (or equivalent standards until harmonised references are published). ## Encoding strategy: what should a QR code contain? The safest QR strategy is to encode a stable resolver URL (or URI) that references the persistent unique product identifier, rather than embedding vendor-specific parameters. This allows you to change back-end providers without reprinting carriers and supports version linking. - Encode: a stable resolver URL that maps to the DPP identifier and selects the correct view (public vs restricted) based on access rights. - Avoid: embedding direct vendor URLs that you cannot migrate; avoid non-versioned endpoints that break when schemas evolve. - Support: model/batch/item resolution - the same QR pattern should support the DPP level required by delegated acts. ## Resolution and longevity: how to prevent "dead QR codes" Article 11 requires the DPP to remain available for the period specified in delegated acts, including after insolvency or cessation of activity. That means your resolution must be durable and independent of a single operator's uptime. - Use a domain and routing strategy you control (or that can be transferred) and prove continuity planning (back-up copies via service providers where applicable). - Implement health checks and monitoring: broken resolution is a compliance incident, not a marketing bug. - Version linking: if a new DPP is created, link to original DPP(s) and preserve audit history. ## Placement, durability and scan reliability (physical-world engineering) A QR/data carrier only works if it scans reliably in real environments. Treat carrier deployment like a hardware rollout: test materials, printing, and placement across the product lifecycle. - Durability tests: abrasion, chemicals, heat, UV, moisture; validate scan rates across device types. - Placement rules: avoid curved surfaces, seams, and areas likely to be removed; ensure packaging/documentation fallback exists. - Human factors: clear "scan me" UX cues and accessibility considerations. ## Distance selling and marketplaces: exposing DPP before purchase Delegated acts must specify how the DPP is accessible before customers are bound by a contract (including distance selling). Article 10 also requires operators to provide dealers and online marketplaces with digital copies of the carrier or identifier where customers cannot physically access the product. This typically requires: product page integration, stable public views, and automation for partner sharing. - Provide: public DPP URLs and identifiers for product listings; ensure the public view is complete and compliant. - Automate: distribution of digital copies to marketplaces/dealers with defined SLAs. - Validate: that restricted data remains restricted even when public links are widely shared. ## Security and anti-fraud patterns (Article 11 + CWA guidance) DPP systems should ensure authentication, reliability and integrity, high security and privacy, and fraud avoidance. For high-risk sectors, unauthenticated QR codes can be spoofed. Consider layered authenticity. - Integrity: signed payloads or signed references for critical compliance fields; tamper-evident logs. - Carrier authenticity: optional authenticated carrier strategies where counterfeiting risk is high. - Privacy: do not store customer personal data in the DPP without explicit consent; avoid collecting personal data for public scans. ## Implementation checklist (copy/paste into your rollout plan) Use this checklist to turn QR/data carrier work into a compliant rollout with measurable acceptance criteria. Each checklist item should have an owner and test evidence. - Identifier scheme documented (model/batch/item) + resolver URL format frozen. - Carrier type selected and tested for durability + scan reliability; placement spec approved. - Public view designed and tested for pre-purchase access; marketplace/dealer distribution path implemented. - Restricted access implemented with role-based rights and audit logs; no customer personal data stored without explicit consent. - Continuity plan for availability and provider migration (avoid vendor lock-in); version linking implemented. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU Digital Product Passport (DPP) QR Code Implementation Guide across ESG workflows ESG Compliance can take EU Digital Product Passport (DPP) QR Code Implementation Guide from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Digital Product Passport (DPP) QR Code Implementation Guide](/solutions/esg-compliance.md): Start from EU Digital Product Passport (DPP) QR Code Implementation Guide and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Digital Product Passport (DPP)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) QR Code Implementation Guide. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Data carrier + persistent unique product identifier requirement (Article 10), availability/security requirements (Article 11), and identifiers/standards context (Annex III). - [CEN-CENELEC CWA 18186:2025 - DPP designer guidance (portal, searchability, security)](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Implementation guidance on DPP portal setup, access, searchability (API patterns), longevity/availability, and security/trust mechanisms. - [GS1 General Specifications (identifier and carrier ecosystem)](https://ref.gs1.org?ref=sorena.io) - Reference context for barcode and identification ecosystem used in supply chain implementations (useful when aligning carriers and identifiers). ## Related Topic Guides - [DPP Applicability Test (ESPR Scoping) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/applicability-test.md): A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act. - [DPP Architecture & Integration (Open Standards, Registry, APIs) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/architecture-and-integration.md): An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers. - [DPP Data Carriers, Access Control & UX | QR Code, Identifier, Public vs Restricted Views](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers. - [DPP Data Governance RACI Template | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field. - [DPP Data Requirements & Fields (Annex III) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III). - [DPP Governance, Verification & Audit Readiness | EU Digital Product Passport](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9). - [DPP Implementation Playbook & Vendor Selection | EU Digital Product Passport](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers. - [DPP vs Traditional Product Passports (Labels, PDFs, EPREL) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals. - [ESPR / DPP Penalties & Fines | EU Digital Product Passport Enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective. - [EU Digital Product Passport (DPP) Checklist | Audit-Ready Implementation Steps](/artifacts/eu/digital-product-passport/checklist.md): An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID). - [EU Digital Product Passport (DPP) Compliance Guide | Implementation Playbook](/artifacts/eu/digital-product-passport/compliance.md): A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements. - [EU Digital Product Passport (DPP) Deadlines & Compliance Calendar | ESPR 2024/1781](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024). - [EU Digital Product Passport (DPP) FAQ | ESPR 2024/1781](/artifacts/eu/digital-product-passport/faq.md): Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III). - [EU Digital Product Passport (DPP) Requirements | ESPR Articles 9-15 + Annex III](/artifacts/eu/digital-product-passport/requirements.md): A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9). - [What Is a Digital Product Passport (DPP)? | EU ESPR 2024/1781](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide --- --- title: "DPP vs Traditional Product Passports (Labels, PDFs, EPREL)" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports" author: "Sorena AI" description: "A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "DPP vs traditional product passport" - "Digital Product Passport comparison" - "DPP vs labels" - "DPP vs PDF manual" - "DPP vs EPREL" - "digital labelling EU" - "DPP structured data" - "DPP access rights" - "DPP registry" - "DPP vs traditional" - "digital labelling" - "structured data" - "access rights" - "registry" - "customs" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DPP vs Traditional Product Passports (Labels, PDFs, EPREL) A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals. *Artifact Guide* *EU* ## EU Digital Product Passport (DPP) vs Traditional Product Passports What changes when product information becomes a structured, interoperable dataset - not just a PDF. Focused on practical differences: identity, data structure, access rights, registry/customs, and auditability. Many companies already have "product passports": manuals, datasheets, compliance folders, and labels. The EU DPP changes the operating model. It requires persistent identifiers connected via physical data carriers, structured interoperable data, differentiated access rights, and EU-level infrastructure (registry/portal/customs) - designed to support traceability and compliance verification across the value chain. ## Traditional product information (what most companies have today) Traditional approaches typically include physical labels, manuals (PDFs), product pages, and internal compliance repositories. They often lack: persistent resolution across lifecycle, structured machine-readable data, and differentiated access control by actor type. - Physical labels: limited space; hard to keep current; difficult to expose deep compliance evidence. - PDF/manual repositories: not inherently item/batch-aware; difficult to search/compare across products; prone to broken links. - Internal compliance folders: good for audits but not designed for multi-actor access or interoperability. ## What DPP adds (and why it's different) ESPR requires that DPP data be connected to a persistent unique product identifier through a data carrier physically present on product/packaging/documentation. It also pushes DPP toward open standards, interoperability and transferability without vendor lock-in. - Persistent identity: stable identifiers and resolvers that work for the product lifetime and across DPP versions (with linking). - Structured dataset: machine-readable, searchable, transferable data - not only documents. - Differentiated access rights: public vs restricted fields by actor type; restricted update rights aligned to delegated acts. - EU infrastructure: registry and web portal enabling authenticity checks and enabling customs workflows once operational. ## Operational differences: what teams must build DPP is not a single system; it's an integration layer across PLM/ERP/compliance repositories, plus carrier generation and access control. The biggest change is governance: you must keep data accurate, complete and up to date, with clear ownership. - Data engineering: canonical DPP schema + provenance + versioning; API-first architecture powering multiple views. - Packaging/labeling: carrier generation, placement specs, durability tests, and recall-safe update workflows. - Security/access: role-based access, authentication for restricted views, and audit logging. - Commerce: pre-purchase access requirements (including distance selling) integrated into product pages and dealer/marketplace workflows. *Recommended next step* *Placement: after the comparison section* ## Use EU Digital Product Passport (DPP) vs Traditional Product Passports as a cited research workflow Research Copilot can take EU Digital Product Passport (DPP) vs Traditional Product Passports from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Digital Product Passport (DPP) vs Traditional Product Passports](/solutions/research-copilot.md): Start from EU Digital Product Passport (DPP) vs Traditional Product Passports and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Digital Product Passport (DPP)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) vs Traditional Product Passports. ## How DPP relates to existing EU systems (labels and databases) ESPR recognises that other EU law already provides information systems for certain product groups. In some cases, DPP may not be required if other systems achieve the objectives of access and compliance verification. In other cases, DPP can complement or unify multiple information obligations across laws. - DPP can be used (where appropriate) to provide information required under other Union law, reducing duplication. - Some product groups may rely on existing labeling databases; delegated acts and Commission decisions determine whether DPP is required. - Plan interoperability: treat DPP as a layer that can reference or integrate with existing registries and documentation systems. ## What to reuse from "traditional passport" work (migration strategy) A DPP program does not start from zero. Your existing artifacts can be restructured into DPP fields and referenced documents. The key is to convert static documents into structured, versioned data with stable resolution. - Reuse: declarations of conformity, technical documentation, manuals, safety warnings - but add stable identifiers, hashes, and provenance. - Convert: internal product master data into a canonical DPP schema aligned to Annex III and delegated act requirements. - Add: access control and lifecycle updates; build DPP views for each actor type rather than one "PDF portal". ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - DPP requirements (Articles 9-15), open standards and no vendor lock-in (Article 10), and interoperability/access/security requirements (Article 11). - [European Commission - ESPR overview (Digital Product Passport overview)](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Plain-language DPP purpose and how it supports consumers and authorities. - [CEN-CENELEC CWA 18186:2025 - DPP designer guidance (digital portal and lifecycle access)](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Practical comparison points: portal access, searchability, longevity and availability of DPP information, and security/trust considerations. ## Related Topic Guides - [DPP Applicability Test (ESPR Scoping) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/applicability-test.md): A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act. - [DPP Architecture & Integration (Open Standards, Registry, APIs) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/architecture-and-integration.md): An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers. - [DPP Data Carriers, Access Control & UX | QR Code, Identifier, Public vs Restricted Views](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers. - [DPP Data Governance RACI Template | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field. - [DPP Data Requirements & Fields (Annex III) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III). - [DPP Governance, Verification & Audit Readiness | EU Digital Product Passport](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9). - [DPP Implementation Playbook & Vendor Selection | EU Digital Product Passport](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers. - [DPP QR Code Implementation Guide | Data Carrier + Identifier Design](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10). - [ESPR / DPP Penalties & Fines | EU Digital Product Passport Enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective. - [EU Digital Product Passport (DPP) Checklist | Audit-Ready Implementation Steps](/artifacts/eu/digital-product-passport/checklist.md): An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID). - [EU Digital Product Passport (DPP) Compliance Guide | Implementation Playbook](/artifacts/eu/digital-product-passport/compliance.md): A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements. - [EU Digital Product Passport (DPP) Deadlines & Compliance Calendar | ESPR 2024/1781](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024). - [EU Digital Product Passport (DPP) FAQ | ESPR 2024/1781](/artifacts/eu/digital-product-passport/faq.md): Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III). - [EU Digital Product Passport (DPP) Requirements | ESPR Articles 9-15 + Annex III](/artifacts/eu/digital-product-passport/requirements.md): A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9). - [What Is a Digital Product Passport (DPP)? | EU ESPR 2024/1781](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports --- --- title: "EU Digital Product Passport (DPP) FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/faq" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/faq" author: "Sorena AI" description: "Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III)." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "EU Digital Product Passport FAQ" - "DPP questions" - "is DPP mandatory" - "DPP scope" - "DPP Annex III data" - "DPP QR code" - "DPP data carrier" - "DPP registry 2026" - "DPP customs controls" - "DPP open standards vendor lock-in" - "DPP FAQ" - "ESPR 2024/1781" - "data carrier" - "Annex III" - "registry" - "customs" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Digital Product Passport (DPP) FAQ Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III). *Artifact Guide* *EU* ## EU Digital Product Passport (DPP) FAQ Fast answers: scope, data, carriers, access rights, registry, customs and implementation. Grounded in ESPR (Regulation (EU) 2024/1781) and implementation guidance. This FAQ focuses on real implementation questions: when DPP is mandatory, what fields are required, how QR/data carriers work, how access rights are enforced, and what "open standards and no vendor lock-in" means in practice. ## Is DPP mandatory for every product in the EU? No. Under ESPR, DPP obligations are set by product-group delegated acts adopted under Article 4. Delegated acts specify what data must be included, which carriers to use, who can access what, and who can update what. - Always start from the delegated act for your product group. - Some product groups may be exempt where technical specifications are not available or where other EU digital systems already meet the objectives. ## What is the current DPP implementation status in the EU? The EU already has the ESPR legal framework in force, but DPP rollout still depends on product-group delegated acts and supporting EU systems. As of 6 March 2026, the key implementation anchors are the first ESPR working plan for 2025-2030, the 19 July 2026 registry deadline, and the completed 2025 consultation on DPP service-provider rules. - 19 Apr 2025: deadline for adoption of the first ESPR working plan. - Apr 2025: first ESPR working plan released for 2025-2030. - 9 Apr 2025 to 1 Jul 2025: Commission consultation on DPP service-provider storage, management, and possible certification rules. - By 19 Jul 2026: Commission must set up the EU DPP registry. ## What exactly is a DPP under ESPR? A DPP is a set of data specific to a product, accessible electronically via a data carrier, including the information specified in the applicable delegated act. The DPP must be designed to support traceability, actor access, and compliance verification. - DPP quality requirement: data should be accurate, complete and up to date (Article 9). - DPP must remain available for the period specified by delegated acts (at least expected lifetime). ## Is a QR code required for DPP? ESPR requires a data carrier physically present on product/packaging/documentation that connects to a persistent unique product identifier. Delegated acts specify one or more data carriers. QR codes are common, but not the only possible carrier. - Choose carriers based on lifecycle environment and durability (repair/refurbish/recycle contexts). - Avoid dead links: use a stable resolver and a persistent identifier strategy. ## What is 'model vs batch vs item' DPP level and why does it matter? Delegated acts specify whether DPP is established at model, batch or item level. This drives your ID strategy and update workload. Item-level DPP implies per-unit identifiers; model-level implies shared identifiers across units. - Model-level: simpler operations; versioned updates. - Batch-level: manufacturing context-aware; requires batch identifiers and mappings. - Item-level: strongest traceability; highest complexity. ## What data fields are required in a DPP? The delegated act for your product group selects from Annex III data elements and may add product-specific ecodesign information. Annex III includes identifiers, commodity codes, compliance documentation, manuals/safety info, operator identifiers, facility identifiers, importer EORI, and service provider references. - Build a canonical data dictionary: field definition, owner, source system, update SLA, and access classification. - Keep evidence: compliance docs should have references and integrity controls (hash/signature) where appropriate. ## How does pre-purchase access work (including distance selling)? Delegated acts must specify how customers can access the DPP before being bound by a contract, including distance selling. Article 10 also requires the economic operator to provide dealers and online marketplaces with digital copies of the carrier/identifier (or a webpage link) where needed. - Public view: make required fields accessible on product pages and in-store scanning flows. - Restricted view: enforce access rights with authentication and audit logs. ## When does the EU DPP registry matter? ESPR requires the Commission to set up an EU digital registry by 19 July 2026 storing at least unique identifiers and issuing a unique registration identifier associated with uploaded identifiers. For release for free circulation, customs workflows can require providing that unique registration identifier once the registry is operational. - Plan registry integration early: upload pipeline, response storage, and customs data flows. - Treat registry as a compliance dependency with operational SLAs. ## Can DPP store customers' personal data? ESPR states that personal data relating to customers must not be stored in the DPP without explicit consent under GDPR. Best practice is to keep public DPP access free of personal data collection and only collect personal data where necessary and justified. - Public scans: avoid forcing apps or accounts; avoid collecting personal data for public access. - Restricted access: use secure credentials and least privilege; store minimal personal data with explicit consent where needed. ## What does 'open standards' and 'no vendor lock-in' mean in practice? Article 10 requires DPP data to be based on open standards and transferable through an open interoperable data exchange network without vendor lock-in. Practically, you should be able to migrate providers without reprinting carriers and without losing data or audit history. - Use stable resolver URLs you control; avoid vendor-specific domains embedded in QR codes. - Prove exportability: schema + data + history can be exported and rehydrated. - Contract for continuity: ensure service providers cannot sell/reuse data beyond what is necessary unless specifically agreed. *Recommended next step* *Placement: after the FAQ section* ## Use EU Digital Product Passport (DPP) FAQ as a cited research workflow Research Copilot can take EU Digital Product Passport (DPP) FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Digital Product Passport (DPP) FAQ](/solutions/research-copilot.md): Start from EU Digital Product Passport (DPP) FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Digital Product Passport (DPP)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) FAQ. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - FAQ basis: DPP requirements in Articles 9-15 and Annex III, including carriers, access rights, registry and customs controls. - [European Commission - ESPR overview (DPP explained)](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Plain-language DPP explanation and use cases. - [European Commission - DPP service-provider consultation launch (9 Apr 2025)](https://single-market-economy.ec.europa.eu/news/commission-launches-consultation-digital-product-passport-2025-04-09_en?ref=sorena.io) - Current implementation milestone covering DPP service-provider storage, management, and possible certification rules. - [CEN-CENELEC CWA 18186:2025 - DPP designer guidance](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Implementation guidance: portal setup, access rights, searchability and security/trust. ## Related Topic Guides - [DPP Applicability Test (ESPR Scoping) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/applicability-test.md): A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act. - [DPP Architecture & Integration (Open Standards, Registry, APIs) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/architecture-and-integration.md): An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers. - [DPP Data Carriers, Access Control & UX | QR Code, Identifier, Public vs Restricted Views](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers. - [DPP Data Governance RACI Template | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field. - [DPP Data Requirements & Fields (Annex III) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III). - [DPP Governance, Verification & Audit Readiness | EU Digital Product Passport](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9). - [DPP Implementation Playbook & Vendor Selection | EU Digital Product Passport](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers. - [DPP QR Code Implementation Guide | Data Carrier + Identifier Design](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10). - [DPP vs Traditional Product Passports (Labels, PDFs, EPREL) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals. - [ESPR / DPP Penalties & Fines | EU Digital Product Passport Enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective. - [EU Digital Product Passport (DPP) Checklist | Audit-Ready Implementation Steps](/artifacts/eu/digital-product-passport/checklist.md): An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID). - [EU Digital Product Passport (DPP) Compliance Guide | Implementation Playbook](/artifacts/eu/digital-product-passport/compliance.md): A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements. - [EU Digital Product Passport (DPP) Deadlines & Compliance Calendar | ESPR 2024/1781](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024). - [EU Digital Product Passport (DPP) Requirements | ESPR Articles 9-15 + Annex III](/artifacts/eu/digital-product-passport/requirements.md): A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9). - [What Is a Digital Product Passport (DPP)? | EU ESPR 2024/1781](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/faq --- --- title: "DPP Governance, Verification & Audit Readiness" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/governance-verification-and-audit" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/governance-verification-and-audit" author: "Sorena AI" description: "An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9)." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "DPP audit readiness" - "Digital Product Passport verification" - "DPP governance" - "DPP evidence pack" - "DPP data quality accurate complete up to date" - "DPP access rights audit" - "DPP integrity and security" - "DPP market surveillance" - "DPP customs checks" - "data quality" - "verification" - "access rights" - "integrity" - "market surveillance" - "customs" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DPP Governance, Verification & Audit Readiness An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9). *Artifact Guide* *EU* ## EU Digital Product Passport (DPP) Governance, Verification & Audit How to prove your DPP is correct, secure, and operated as a compliant service. Focused on audit evidence: data quality, provenance, access-rights enforcement, integrity, and continuity. A DPP is only as credible as its governance. ESPR requires DPP data to be accurate, complete and up to date, and requires authentication, reliability and integrity, high security/privacy, and restricted update rights. This page provides an audit-readiness blueprint: what to verify, what evidence to retain, and how to operate verification continuously. ## Audit target 1: data quality (Article 9 - accurate, complete, up to date) Article 9 explicitly requires DPP data to be accurate, complete and up to date. That must be operationalised as measurable controls. Auditors and authorities will ask: where did the data come from, who changed it, and was it valid at the time the product was placed on the market? - Accuracy controls: validation rules, cross-system consistency checks, and approval workflows for high-risk fields (compliance docs, identifiers). - Completeness controls: required-field gating per delegated act; launch gates; missing-field dashboards. - Freshness controls: SLAs per field; automated reminders; escalation when docs or IDs are stale. - Provenance: source system, owner, timestamps, and change reason codes stored per field. ## Audit target 2: access rights and restricted update rights (Article 11) Article 11 requires free and easy access based on access rights and restricts modification/update rights accordingly. Audit focus is not just "who can log in" - it's whether access is correctly enforced at field level and whether updates are traceable. - Role catalog: actor types and allowed fields; evidence of delegated act alignment. - Access enforcement: field-level RBAC/ABAC; audit logs for restricted reads/writes; periodic access reviews. - Update governance: validation, versioning, and dispute correction workflows; least privilege for write access. - Public access: public data should be accessible without forcing app downloads or personal data collection. ## Audit target 3: integrity, security, privacy, and fraud avoidance (Article 11) ESPR requires authentication, reliability and integrity of data, high security and privacy, and fraud avoidance. Treat DPP as a high-value system: it affects compliance verification and customs workflows. - Integrity mechanisms: signatures/hashes for critical fields and compliance docs; tamper-evident audit logs. - Security: encryption at rest/in transit for restricted data; monitoring for suspicious access and updates. - Privacy: no customer personal data stored without explicit consent; minimize and compartmentalize sensitive data. - Carrier security: where counterfeiting risk exists, consider authenticated carrier strategies and trusted resolution endpoints. ## Audit target 4: continuity and availability (lifetime availability requirement) Article 11 requires the DPP to remain available for the period specified in delegated acts, including after insolvency, liquidation, or cessation of activity in the EU of the responsible operator. Audit readiness means you can prove continuity planning and backups. - Back-up strategy: store and test back-up copies, including via DPP service providers where applicable. - Resolver durability: QR/data carriers should resolve long-term; avoid vendor-specific URLs embedded in carriers. - Operational monitoring: uptime SLOs for resolver and DPP views; alerting and incident response. ## Audit target 5: registry and customs readiness (Articles 13-15) The registry stores unique identifiers and provides a unique registration identifier after upload. Customs workflows can require the registration identifier for release for free circulation once the registry is operational. Verification requires end-to-end traceability: product identifier registry upload registration identifier DPP view. - Registry evidence: upload records, returned registration identifiers, and mapping to DPP identifiers. - Customs readiness: ability to provide registration identifiers and commodity codes; audit logs for customs-related data usage. - Authenticity checks: evidence of how registry/portal authenticity verification is supported. ## Evidence pack structure (recommended folder layout) A good evidence pack is navigable: per product group -> per DPP level -> per requirement theme -> evidence artifacts. The goal is fast answers to authority questions and fast internal verification. - Identity: identifier schemes, carrier specs, placement drawings, scan test results, and resolver architecture. - Data: Annex III field dictionary, source-system mapping, validation rules, and freshness dashboards. - Access/security: role catalog, access control tests, audit log samples, encryption/key management evidence. - Continuity: backup procedures, availability tests, and provider migration plan evidence. - Registry/customs: upload workflows, registration identifier mappings, and verification test evidence. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Digital Product Passport (DPP) Governance, Verification & Audit in one governed evidence system SSOT can take EU Digital Product Passport (DPP) Governance, Verification & Audit from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Digital Product Passport (DPP) Governance, Verification & Audit](/solutions/ssot.md): Start from EU Digital Product Passport (DPP) Governance, Verification & Audit and keep documents, evidence, and control records in one governed system. - [Talk through EU Digital Product Passport (DPP)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) Governance, Verification & Audit. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Audit drivers: data quality requirement (Article 9), access rights and security requirements (Article 11), and registry/customs controls (Articles 13-15). - [CEN-CENELEC CWA 18186:2025 - DPP security/trust and access guidance](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Practical guidance for portal access control, security, trust mechanisms, and GDPR-aligned design choices. ## Related Topic Guides - [DPP Applicability Test (ESPR Scoping) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/applicability-test.md): A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act. - [DPP Architecture & Integration (Open Standards, Registry, APIs) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/architecture-and-integration.md): An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers. - [DPP Data Carriers, Access Control & UX | QR Code, Identifier, Public vs Restricted Views](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers. - [DPP Data Governance RACI Template | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field. - [DPP Data Requirements & Fields (Annex III) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III). - [DPP Implementation Playbook & Vendor Selection | EU Digital Product Passport](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers. - [DPP QR Code Implementation Guide | Data Carrier + Identifier Design](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10). - [DPP vs Traditional Product Passports (Labels, PDFs, EPREL) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals. - [ESPR / DPP Penalties & Fines | EU Digital Product Passport Enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective. - [EU Digital Product Passport (DPP) Checklist | Audit-Ready Implementation Steps](/artifacts/eu/digital-product-passport/checklist.md): An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID). - [EU Digital Product Passport (DPP) Compliance Guide | Implementation Playbook](/artifacts/eu/digital-product-passport/compliance.md): A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements. - [EU Digital Product Passport (DPP) Deadlines & Compliance Calendar | ESPR 2024/1781](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024). - [EU Digital Product Passport (DPP) FAQ | ESPR 2024/1781](/artifacts/eu/digital-product-passport/faq.md): Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III). - [EU Digital Product Passport (DPP) Requirements | ESPR Articles 9-15 + Annex III](/artifacts/eu/digital-product-passport/requirements.md): A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9). - [What Is a Digital Product Passport (DPP)? | EU ESPR 2024/1781](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/governance-verification-and-audit --- --- title: "DPP Implementation Playbook & Vendor Selection" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection" author: "Sorena AI" description: "A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "DPP implementation playbook" - "Digital Product Passport implementation" - "DPP vendor selection" - "DPP platform vendor" - "open standards no vendor lock-in" - "DPP registry integration" - "DPP access control" - "DPP data model Annex III" - "DPP rollout plan" - "DPP implementation" - "vendor selection" - "open standards" - "no vendor lock-in" - "registry readiness" - "access control" - "audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DPP Implementation Playbook & Vendor Selection A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers. *Playbook* *EU* ## EU Digital Product Passport (DPP) Implementation Playbook & Vendor Selection A step-by-step DPP rollout plan plus a vendor checklist aligned to ESPR requirements. Optimised for real delivery: identifiers, carriers, access rights, registry readiness, evidence and monitoring. The fastest DPP implementations succeed because they treat DPP as an integration and governance program - not a website build. Use this playbook to sequence work, onboard suppliers, select vendors without lock-in, and produce audit-ready evidence for accuracy, access rights, integrity and continuity. The current rollout baseline is the first ESPR working plan for 2025-2030, the 19 July 2026 registry deadline, and the Commission's 2025 work on DPP service-provider rules. ## Step 1 - Scope the delegated act and lock the DPP level Start with the delegated act for your product group: required fields, carrier rules, access rights, update rights, DPP availability period, and granularity (model/batch/item). Granularity drives cost and architecture: lock it before selecting vendors. - Define product group + commodity codes + required Annex III subset. - Lock DPP level: model vs batch vs item; define identifiers and lifecycle update triggers. - Define actor model: who creates and updates which fields and who consumes which fields. - Check where your product group sits in the first ESPR working plan so implementation timing matches likely delegated-act sequencing. ## Step 2 - Build the canonical DPP data layer (Annex III mapping) Map Annex III fields to authoritative sources and create a canonical schema with provenance, versioning and access classifications. This canonical layer should power all UIs and exports. - Schema: structured identity fields + document references; machine-readable where appropriate. - Provenance: source system, owner, timestamps, and change reasons per field. - Data quality: SLAs and monitoring for "accurate, complete, up to date". ## Step 3 - Implement identifiers, carriers and resolvers (Article 10) Article 10 requires a data carrier connected to a persistent unique product identifier and physical presence on product/packaging/documentation. Avoid reprint risk: encode stable resolver URLs you control, not vendor-specific links. - Carrier selection: QR/2D code, RFID/EPC, etc.; test durability and scan success. - Resolver: stable URL/URI structure; support model/batch/item; support version linking. - Distance selling: provide dealers/marketplaces digital copies of carrier/identifier or link where needed. ## Step 4 - Access control + UX (public vs restricted views) Delegated acts define access rights; Article 11 requires free and easy access based on those rights and restricts modification rights accordingly. Build multiple views: public consumer view, role-based restricted views, authority view. - Public view: pre-purchase access, including distance selling; avoid collecting personal data for public access. - Restricted view: authentication, role-based field access, and audit logging; least privilege for write access. - Update workflow: validation and versioning; correction of disputed fields; audit trails. ## Step 5 - Registry readiness and customs workflows (Articles 13-15) The EU registry stores unique identifiers and returns a unique registration identifier after upload; customs workflows can depend on it once operational. Design this integration as a first-class dependency with operational SLAs. - Registry pipeline: upload identifiers (and delegated act required registry fields) and store registration identifiers. - Customs readiness: provide registration identifiers for release for free circulation when required; support automated verification flows where possible. - Evidence: logs and mappings proving authenticity and correct identifier relationships. *Recommended next step* *Placement: after the workflow or playbook section* ## Operationalize EU Digital Product Passport (DPP) Implementation Playbook & Vendor Selection across ESG workflows ESG Compliance can take EU Digital Product Passport (DPP) Implementation Playbook & Vendor Selection from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Digital Product Passport (DPP) Implementation Playbook & Vendor Selection](/solutions/esg-compliance.md): Start from EU Digital Product Passport (DPP) Implementation Playbook & Vendor Selection and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Digital Product Passport (DPP)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) Implementation Playbook & Vendor Selection. ## Step 6 - Security, integrity, continuity and audit evidence (Article 11) Article 11 requires authentication, reliability, integrity, security/privacy and fraud avoidance, plus lifetime availability even after insolvency/cessation. Build continuity and evidence into contracts and architecture. - Integrity: signed references/hashes for critical fields; tamper-evident audit logs. - Continuity: backups and tested restoration; avoid reliance on a single vendor domain in carriers. - Monitoring: resolver uptime, scan success, freshness SLAs, and access regression tests. ## Vendor selection checklist (ESPR-aligned) Select vendors against legal constraints - not feature checklists. The most important: open standards, interoperability, and no lock-in. Use this checklist for RFPs and proofs of concept. - Open standards + export: can you export full data + history in non-proprietary formats and run it elsewhere? - No vendor lock-in: can you keep the resolver stable if you change vendors (no forced reprint)? - Access control: field-level RBAC/ABAC + audit logs; supports actor-based rights defined in delegated acts. - Security: encryption, key management, signatures/hashes; evidence and monitoring support. - Service provider constraints: provider agrees not to sell, reuse, or process DPP data beyond what is necessary unless specifically agreed; supports backup copies and continuity planning. - Regulatory change readiness: provider can adapt to future Commission rules for DPP service providers and any certification-scheme requirements without redesigning your identifier and carrier layer. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Vendor constraints and program steps: Article 10 (open standards/no lock-in), Article 11 (security/continuity/access rights), Articles 13-15 (registry/portal/customs), and Annex III (data elements). - [CEN-CENELEC CWA 18186:2025 - DPP designer guidance (procurement brief and design options)](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Practical implementation guidance for DPP designers, including portal setup, searchability, security/trust and procurement framing. - [CIRPASS DPP-Related Initiatives Annex (D3.1 Annex, March 2024)](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - Context on the DPP solution landscape; useful for structuring vendor due diligence (note: CIRPASS does not endorse initiatives). ## Related Topic Guides - [DPP Applicability Test (ESPR Scoping) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/applicability-test.md): A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act. - [DPP Architecture & Integration (Open Standards, Registry, APIs) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/architecture-and-integration.md): An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers. - [DPP Data Carriers, Access Control & UX | QR Code, Identifier, Public vs Restricted Views](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers. - [DPP Data Governance RACI Template | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field. - [DPP Data Requirements & Fields (Annex III) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III). - [DPP Governance, Verification & Audit Readiness | EU Digital Product Passport](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9). - [DPP QR Code Implementation Guide | Data Carrier + Identifier Design](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10). - [DPP vs Traditional Product Passports (Labels, PDFs, EPREL) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals. - [ESPR / DPP Penalties & Fines | EU Digital Product Passport Enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective. - [EU Digital Product Passport (DPP) Checklist | Audit-Ready Implementation Steps](/artifacts/eu/digital-product-passport/checklist.md): An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID). - [EU Digital Product Passport (DPP) Compliance Guide | Implementation Playbook](/artifacts/eu/digital-product-passport/compliance.md): A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements. - [EU Digital Product Passport (DPP) Deadlines & Compliance Calendar | ESPR 2024/1781](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024). - [EU Digital Product Passport (DPP) FAQ | ESPR 2024/1781](/artifacts/eu/digital-product-passport/faq.md): Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III). - [EU Digital Product Passport (DPP) Requirements | ESPR Articles 9-15 + Annex III](/artifacts/eu/digital-product-passport/requirements.md): A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9). - [What Is a Digital Product Passport (DPP)? | EU ESPR 2024/1781](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection --- --- title: "ESPR / DPP Penalties & Fines" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/penalties-and-fines" author: "Sorena AI" description: "How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "DPP penalties" - "DPP fines" - "ESPR penalties Article 74" - "Digital Product Passport enforcement" - "DPP public procurement exclusion" - "ESPR fines" - "DPP non-compliance penalties" - "market surveillance penalties" - "ESPR penalties" - "fines" - "public procurement exclusion" - "enforcement" - "market surveillance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR / DPP Penalties & Fines How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective. *Artifact Guide* *EU* ## EU Digital Product Passport (DPP) Penalties & Fines What happens if you get DPP wrong - and how to reduce enforcement exposure. Grounded in ESPR Article 74 (penalties) and the DPP quality/access/security requirements in Articles 9-11. Penalties for ESPR infringements (including DPP-related infringements where applicable) are set by Member States - but ESPR sets baseline requirements: penalties must be effective, proportionate and dissuasive, and Member States must at least be able to impose fines and time-limited exclusion from public procurement procedures. This page explains the penalty framework and the risk controls that reduce exposure. ## Who sets penalties and what ESPR requires (Article 74) Member States lay down penalty rules for infringements of ESPR and must ensure they are implemented, and must notify the Commission of those rules and changes. ESPR specifies criteria that penalties should give due regard to, and minimum penalty types that must be available. - Penalty standards: effective, proportionate and dissuasive. - Minimum penalty types: at least fines and time-limited exclusion from public procurement procedures. - Notification duty: Member States notify the Commission of penalty rules and amendments. *Recommended next step* *Placement: after the enforcement section* ## Use EU Digital Product Passport (DPP) Penalties & Fines as a cited research workflow Research Copilot can take EU Digital Product Passport (DPP) Penalties & Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Digital Product Passport (DPP) Penalties & Fines](/solutions/research-copilot.md): Start from EU Digital Product Passport (DPP) Penalties & Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Digital Product Passport (DPP)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) Penalties & Fines. ## Penalty criteria (what influences severity) ESPR provides a non-exhaustive set of criteria Member States should consider when determining types and levels of penalties. From a compliance perspective, these criteria translate into a risk model: severity rises when infringements are longer, intentional, economically beneficial, or repeated. - Nature, gravity and duration of the infringement; intentional or negligent character. - Financial situation of the person responsible (e.g., turnover/income) and economic benefits derived from the infringement. - Environmental damage and mitigation/remediation actions taken. - Repetition vs single occurrence; other aggravating/mitigating factors. ## What DPP failures can look like in practice (common enforcement narratives) DPP failures usually show up as: missing or inaccessible passports, broken carriers/resolution, stale documentation, incorrect identifiers, or access-rights violations (restricted data exposed or updates untraceable). Because DPP is intended to support traceability and compliance verification, these failures can undermine market surveillance and customs processes. - Availability failures: DPP not available for covered products; broken links or dead QR codes. - Data quality failures: inaccurate, incomplete or stale Annex III data fields (DoC, technical docs, operator IDs). - Access/security failures: restricted data exposed; weak audit logs; insufficient integrity controls or fraud prevention. - Continuity failures: DPP disappears after operator cessation without backups. ## Risk reduction: the evidence controls that matter The best way to reduce penalty exposure is to make compliance provable: show your controls, logs, and remediation actions. Build a DPP evidence pack aligned to Articles 9-11 requirements. - Data quality SLAs and monitoring proving "accurate, complete, up to date". - Access control governance: role catalog + field-level enforcement + quarterly reviews + audit logs. - Integrity controls: hashes/signatures for key compliance docs; tamper-evident update history. - Incident response: documented response to broken links, stale docs, or misprints; remediation proof and prevention measures. ## Public procurement exposure: why DPP compliance affects sales ESPR explicitly requires Member States to be able to impose time-limited exclusion from public procurement procedures as a penalty. For businesses selling into public procurement, DPP compliance can become a sales blocker, not just a compliance issue. - Treat procurement teams as stakeholders: ensure they can produce DPP compliance evidence quickly. - Build a "DPP procurement pack": public view screenshots, evidence of availability, and data quality dashboards. - Run periodic procurement readiness drills and remediation rehearsals. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Article 74 (Penalties)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Penalty framework: Member State penalties, criteria for severity, and minimum penalty types (fines and time-limited exclusion from public procurement). - [Regulation (EU) 2024/1781 - DPP quality and security obligations (Articles 9-11)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Data quality (accurate/complete/up to date), access rights, integrity, security, and continuity requirements that reduce enforcement exposure when provably implemented. ## Related Topic Guides - [DPP Applicability Test (ESPR Scoping) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/applicability-test.md): A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act. - [DPP Architecture & Integration (Open Standards, Registry, APIs) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/architecture-and-integration.md): An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers. - [DPP Data Carriers, Access Control & UX | QR Code, Identifier, Public vs Restricted Views](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers. - [DPP Data Governance RACI Template | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field. - [DPP Data Requirements & Fields (Annex III) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III). - [DPP Governance, Verification & Audit Readiness | EU Digital Product Passport](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9). - [DPP Implementation Playbook & Vendor Selection | EU Digital Product Passport](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers. - [DPP QR Code Implementation Guide | Data Carrier + Identifier Design](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10). - [DPP vs Traditional Product Passports (Labels, PDFs, EPREL) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals. - [EU Digital Product Passport (DPP) Checklist | Audit-Ready Implementation Steps](/artifacts/eu/digital-product-passport/checklist.md): An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID). - [EU Digital Product Passport (DPP) Compliance Guide | Implementation Playbook](/artifacts/eu/digital-product-passport/compliance.md): A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements. - [EU Digital Product Passport (DPP) Deadlines & Compliance Calendar | ESPR 2024/1781](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024). - [EU Digital Product Passport (DPP) FAQ | ESPR 2024/1781](/artifacts/eu/digital-product-passport/faq.md): Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III). - [EU Digital Product Passport (DPP) Requirements | ESPR Articles 9-15 + Annex III](/artifacts/eu/digital-product-passport/requirements.md): A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9). - [What Is a Digital Product Passport (DPP)? | EU ESPR 2024/1781](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/penalties-and-fines --- --- title: "EU Digital Product Passport (DPP) Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/requirements" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/requirements" author: "Sorena AI" description: "A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9)." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "EU Digital Product Passport requirements" - "DPP requirements ESPR" - "Regulation 2024/1781 DPP" - "Article 9 digital product passport" - "Article 10 digital product passport requirements" - "Article 11 technical design" - "Article 12 unique identifiers" - "Article 13 DPP registry" - "Article 15 customs controls" - "Annex III DPP data" - "DPP requirements" - "ESPR 2024/1781" - "data carrier" - "unique product identifier" - "DPP registry" - "customs controls" - "Annex III" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Digital Product Passport (DPP) Requirements A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9). *Artifact Guide* *EU* ## EU Digital Product Passport (DPP) Requirements The rules you must implement: availability, identifiers, data carriers, access rights, security, registry and customs readiness. Grounded in ESPR (Regulation (EU) 2024/1781) Articles 9-15 and Annex III. DPP compliance is a technical and operational program: product identifiers, data carriers, open standards and interoperability, differentiated access rights, audit evidence, registry integration and customs workflows. Use this page as a baseline requirements spec you can map to systems and owners. In current practice, that baseline now sits alongside the first ESPR working plan for 2025-2030 and the Commission's follow-on work on DPP service-provider rules. ## Article 9 - When a DPP is required (market access rule) For product groups covered by delegated acts, the rules can require that products can only be placed on the market or put into service if a DPP is available in accordance with the delegated act and Articles 10 and 11. The regulation also sets an explicit quality requirement: DPP data must be accurate, complete and up to date. - Delegated acts must specify: the data fields (Annex III), data carrier(s), layout/positioning, granularity (model/batch/item), pre-purchase access (including distance selling), access rights, who can create/update, update arrangements, and availability period (at least expected lifetime). - DPP requirements must support: easy actor access/understanding, compliance verification by authorities, and improved traceability. - Exemptions are possible where technical specs are not available or other EU digital systems already achieve the objectives. ## Article 10 - Essential requirements (IDs, carriers, open standards, privacy) Article 10 sets the core technical requirements that should shape your system design and vendor selection. These requirements push DPP toward open standards and interoperability, explicitly aiming to avoid vendor lock-in. - Persistent unique product identifier connected through a data carrier; carrier must be physically present on the product, packaging, or accompanying documentation. - Standards-based identifiers and carriers: comply with standards referenced in Annex III (or equivalent standards until harmonised references are published). - Open standards + interoperability: data should be machine-readable, structured, searchable and transferable through an open interoperable data exchange network without vendor lock-in. - Personal data: customers' personal data must not be stored in DPP without explicit consent in line with GDPR. - Commercial enablement: the economic operator must provide dealers/online marketplaces a digital copy of the carrier or unique identifier to support customer access where physical access is not possible. *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU Digital Product Passport (DPP) Requirements across ESG workflows ESG Compliance can take EU Digital Product Passport (DPP) Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Digital Product Passport (DPP) Requirements](/solutions/esg-compliance.md): Start from EU Digital Product Passport (DPP) Requirements and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Digital Product Passport (DPP)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) Requirements. ## Article 11 - Technical design and operation (access rights, security, longevity) Article 11 is the operational backbone: access rights, storage models, lifecycle linking, and security requirements. Design for longevity: DPP must remain available for the product-group specified period, including after insolvency or cessation of activity. - Interoperability requirement: DPP must be fully interoperable with other DPPs (technical, semantic and organisational aspects of end-to-end communication and data transfer). - Access requirement: relevant actors must have free of charge and easy access based on their access rights in delegated acts. - Storage + lifecycle: stored by responsible economic operator or DPP service providers; new DPPs must link to prior DPPs; data modification rights are restricted per access rights. - Trust + security: authentication, reliability and integrity; high level of security and privacy; fraud avoidance. - Service provider constraint: if a DPP service provider stores/processes DPP data, it must not sell/reuse/process the data beyond what is necessary for the service unless specifically agreed. ## Article 12 - Unique identifiers (operators and facilities) Beyond the product identifier, ESPR anticipates unique operator and facility identifiers that can be referenced in the DPP. If an identifier is not available, the operator creating/updating the DPP may request it on behalf of the actor, after confirming it does not already exist. - Unique operator identifiers (manufacturer and other operators) and unique facility identifiers must comply with standards referenced in Annex III (or equivalent standards). - Plan governance for identifier issuance and lifecycle management (including the possibility of issuing agencies and operator-created identifiers via delegated acts). - Ensure identifiers are stable and resolvable, and record changes over time (ownership transfer, facility changes, operator role changes). ## Articles 13-15 - Registry, portal and customs controls ESPR introduces EU-level systems and customs workflows that DPP implementations should plan for early. This is where DPP becomes more than "information": it becomes a compliance control surface. - Registry: by 19 July 2026, the Commission must set up a digital registry storing at least unique identifiers (and commodity codes for release-for-free-circulation products). - Web portal: the Commission must set up a publicly accessible portal to search and compare DPP data consistent with access rights. - Customs: once the registry is operational, products under release for free circulation require providing the unique registration identifier; customs may verify identifier + commodity code electronically and automatically. ## Current implementation layer: working plan and service-provider rules The legal requirements in Articles 9-15 are now being translated into the actual DPP operating model through the first ESPR working plan and the Commission's work on service-provider governance. That matters because implementation timing, storage responsibilities, and provider controls are now part of practical DPP compliance planning. - First ESPR working plan: adopted by 19 Apr 2025 and released for the 2025-2030 period, giving the first product-group rollout signal. - Service-provider consultation: launched 9 Apr 2025 and closed 1 Jul 2025, focused on storage, management, and possible certification rules for DPP service providers. - Program implication: design your DPP so it remains compliant if the Commission tightens provider requirements, continuity expectations, or certification conditions. ## Annex III - DPP data elements (what delegated acts can require) Annex III lists the classes of data that delegated acts can require in the DPP. Use it to build your canonical data model and identify source systems. The fields cover identity, compliance documentation, manuals, and operator metadata (including importer EORI and service provider references). - Identity and classification: unique product identifier, commodity codes (e.g., TARIC), and GTIN (ISO/IEC 15459-6 or equivalent). - Compliance evidence: declaration of conformity, technical documentation, certificates, and other compliance information under EU law. - User information: manuals, instructions, warnings and safety information where required. - Operator metadata: manufacturer and other operator identifiers, importer info (including EORI), facility identifiers, and service provider back-up references. ## Implementation checklist (turn requirements into shipped work) Treat DPP requirements as a product spec: what must exist, for which actors, at which lifecycle stage, and with what evidence. The fastest path is a CPS-style mapping: requirement -> system component -> owner -> acceptance criteria -> evidence. - Map Annex III fields to master data, PLM, compliance docs, packaging/label systems, ERP and importer workflows. - Choose identifier and carrier standards; implement resolver and offline fallback for distance selling use cases. - Design access control and audit logging aligned to delegated act actor rights; keep public data accessible without forced apps or personal data collection. - Plan registry integration: unique identifiers upload, unique registration identifier retrieval, and customs data flows. - Select vendors against Article 10/11 constraints: open standards, interoperability, no vendor lock-in, and service provider non-reuse constraints. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary DPP requirements: Articles 9-15 and Annex III (including data carrier, unique identifiers, registry, portal and customs controls). - [European Commission - Ecodesign for Sustainable Products Regulation (ESPR) overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Plain-language overview of DPP goals, users and the customs/verification rationale. - [CEN-CENELEC CWA 18186:2025 - DPP design and procurement guidance](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Practical guidance: portal access, searchability APIs, longevity/availability, security/trust, and GDPR-aligned design choices. - [CIRPASS DPP System Architecture (D3.2, March 2024)](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - Reference architecture principles: product-centric identifiers, decentralised approaches, knowledge-graph/linked-data patterns and interoperability. ## Related Topic Guides - [DPP Applicability Test (ESPR Scoping) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/applicability-test.md): A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act. - [DPP Architecture & Integration (Open Standards, Registry, APIs) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/architecture-and-integration.md): An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers. - [DPP Data Carriers, Access Control & UX | QR Code, Identifier, Public vs Restricted Views](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers. - [DPP Data Governance RACI Template | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field. - [DPP Data Requirements & Fields (Annex III) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III). - [DPP Governance, Verification & Audit Readiness | EU Digital Product Passport](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9). - [DPP Implementation Playbook & Vendor Selection | EU Digital Product Passport](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers. - [DPP QR Code Implementation Guide | Data Carrier + Identifier Design](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10). - [DPP vs Traditional Product Passports (Labels, PDFs, EPREL) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals. - [ESPR / DPP Penalties & Fines | EU Digital Product Passport Enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective. - [EU Digital Product Passport (DPP) Checklist | Audit-Ready Implementation Steps](/artifacts/eu/digital-product-passport/checklist.md): An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID). - [EU Digital Product Passport (DPP) Compliance Guide | Implementation Playbook](/artifacts/eu/digital-product-passport/compliance.md): A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements. - [EU Digital Product Passport (DPP) Deadlines & Compliance Calendar | ESPR 2024/1781](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024). - [EU Digital Product Passport (DPP) FAQ | ESPR 2024/1781](/artifacts/eu/digital-product-passport/faq.md): Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III). - [What Is a Digital Product Passport (DPP)? | EU ESPR 2024/1781](/artifacts/eu/digital-product-passport/what-is-a-dpp.md): A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/requirements --- --- title: "What Is a Digital Product Passport (DPP)?" canonical_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/what-is-a-dpp" source_url: "https://www.sorena.io/artifacts/eu/digital-product-passport/what-is-a-dpp" author: "Sorena AI" description: "A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III)." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "what is a digital product passport" - "digital product passport definition" - "EU Digital Product Passport DPP" - "ESPR 2024/1781 DPP" - "DPP Annex III data" - "DPP QR code" - "data carrier" - "unique product identifier" - "DPP registry" - "DPP customs checks" - "DPP implementation" - "Digital Product Passport" - "DPP definition" - "ESPR 2024/1781" - "Annex III data" - "QR code" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # What Is a Digital Product Passport (DPP)? A deep explainer of the EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): definition, who uses it, what data it contains (Annex III). *Artifact Guide* *EU* ## EU Digital Product Passport (DPP) What It Is (and Why It Matters) A product-specific dataset accessible via a data carrier - built to support sustainability, circularity, and compliance. Grounded in ESPR (Regulation (EU) 2024/1781) Articles 9-15 and Annex III. A Digital Product Passport (DPP) is not a marketing microsite. Under ESPR (Regulation (EU) 2024/1781), it is a set of product-specific data - defined in product-group delegated acts - that must be accessible electronically through a data carrier (for example a QR/ID) and designed for differentiated access across the value chain. In practical terms, the DPP rollout is now shaped by the first ESPR working plan for 2025-2030 and the supporting EU registry and service-provider rules that are still being operationalised. ## The legal definition and where DPP requirements live Under ESPR, a DPP is a set of data specific to a product that includes the information specified in the applicable delegated act adopted under Article 4 and that is accessible via electronic means through a data carrier. In practice, DPP is a framework capability: the Commission sets product-group rules (delegated acts) that specify what data must be included, at what granularity (model/batch/item), who can access which fields, and who can create or update the data. - ESPR Chapter III (Articles 9-15) sets core DPP obligations: availability, essential requirements, registry, web portal and customs controls. - Product-specific delegated acts (Article 4) define the actual DPP content and access rights per product group. - Annex III provides the universe of DPP data elements that delegated acts can require (IDs, compliance docs, manuals, operator IDs, facility IDs, etc.). - The first ESPR working plan, released in April 2025 for the 2025-2030 period, is the current policy signal for which product groups will move first. *Recommended next step* *Placement: after the scope or definition section* ## Use EU Digital Product Passport (DPP) What It Is (and Why It Matters) as a cited research workflow Research Copilot can take EU Digital Product Passport (DPP) What It Is (and Why It Matters) from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Digital Product Passport (DPP) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Digital Product Passport (DPP) What It Is (and Why It Matters)](/solutions/research-copilot.md): Start from EU Digital Product Passport (DPP) What It Is (and Why It Matters) and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Digital Product Passport (DPP)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Product Passport (DPP) What It Is (and Why It Matters). ## Who the DPP is for (and why access must be differentiated) DPP is designed to serve many actors: customers, economic operators (manufacturer/importer/distributor/dealer), repair and circularity operators, market surveillance and customs authorities, and other stakeholders. Because DPP data includes both public consumer-facing information and restricted compliance/technical information, DPP must support differentiated access rights by stakeholder type. - Customers: easy, free access to the information they need before purchase (including distance selling). - Circularity operators: repair/refurbish/recycle information and identifiers to support life extension and end-of-life operations. - Authorities: faster compliance verification, authenticity checks, and improved traceability and market surveillance. ## What data is inside a DPP (Annex III, in plain language) DPP data fields are product-group specific, but the regulation already enumerates the kinds of data that may be required. A practical way to understand DPP data is to split it into four layers: identity, compliance, usage/circularity, and operator/facility metadata. - Identity layer: unique product identifier, commodity codes (e.g., TARIC), and (where applicable) a Global Trade Identification Number (GTIN). - Compliance layer: declaration of conformity, technical documentation, and conformity certificates where applicable under EU law. - Usage/circularity layer: user manuals, instructions, warnings and safety information (where required) and additional ecodesign information defined by delegated acts. - Operator/facility layer: manufacturer/operator identifiers, importer info (including EORI), facility identifiers, and reference to the DPP service provider hosting the back-up copy. ## Model vs batch vs item level: why granularity is a key design decision A DPP can be established at model, batch or item level depending on product-group rules. This directly affects architecture and cost: item-level DPP implies unique identifiers per unit; model-level implies shared identifiers with shared data. Delegated acts must specify the level and the definition of that level for the product group. - Model-level DPP: faster to implement; best when product units share identical regulated characteristics. - Batch-level DPP: useful when manufacturing context affects compliance-relevant characteristics. - Item-level DPP: strongest traceability; highest implementation complexity and lifecycle update needs. ## Data carrier + unique identifiers: the bridge between physical and digital A DPP must be connected through a data carrier to a persistent unique product identifier. The data carrier must be physically present on the product, packaging, or accompanying documentation, as specified by product-group rules. A DPP is designed to work with open standards and interoperability - to avoid vendor lock-in and to enable end-to-end traceability. - Data carrier examples: QR/2D codes, RFID/EPC, or other standardised carriers depending on the product and context. - Identifiers and carriers must comply with standards referenced in Annex III (or equivalent standards until harmonised references are published). - Personal data: the regulation explicitly restricts storing customers' personal data in the DPP without explicit consent under GDPR. ## EU systems: registry, web portal, and customs controls ESPR requires EU-level infrastructure to support DPP authenticity checks and automated controls. For implementation teams, this translates into: (1) registry integration, (2) public and restricted data views, and (3) customs/market surveillance readiness. - Digital product passport registry: the Commission must set up a registry that stores at least unique identifiers (with commodity codes for release-for-free-circulation products). - Web portal: a public portal should allow searching and comparing DPP data consistent with access rights. - Customs: for covered products placed under release for free circulation, the unique registration identifier must be provided when the registry is operational, and customs may verify it electronically. ## What is happening now: service-provider rules and rollout governance The legal framework already allows DPP data to be stored by responsible economic operators or by DPP service providers, but the operating model is still maturing. This is why storage architecture, backup access, continuity, and provider certification questions are not theoretical design issues. They are part of the Commission's active implementation agenda. - On 9 Apr 2025, the Commission launched a public consultation on how DPP data should be stored and managed by service providers and on whether a certification scheme is needed. - That consultation closed on 1 Jul 2025 and feeds the future rules for effective DPP system functioning. - If you depend on a DPP platform vendor, you should treat provider controls and migration rights as part of core compliance design. ## How to start: week-one deliverables that de-risk implementation A DPP program succeeds when it produces engineering-grade artifacts early: data maps, owners, identifier strategies, and evidence packages. Use these deliverables to avoid building a portal that cannot satisfy delegated acts, access rights, and audit requirements later. - DPP scope memo: product group(s), expected delegated act triggers, and the DPP granularity (model/batch/item) assumptions. - Annex III data map: fields -> source systems -> owners -> update frequency -> retention policy. - Identifier + carrier strategy: unique product identifier scheme, carrier choice, and fallback access for distance selling. - Access control model: public vs restricted fields; actor types; authentication approach; audit logging. - Evidence pack skeleton: declaration of conformity, technical documentation references, and how you keep DPP data accurate, complete and up to date. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary legal basis for DPP: Articles 9-15 (DPP requirements, registry, portal, customs) and Annex III (DPP data elements). - [European Commission - Ecodesign for Sustainable Products Regulation (ESPR) overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Plain-language description of ESPR and the Digital Product Passport concept and use cases (consumer information and customs checks). - [CEN-CENELEC CWA 18186:2025 - Guidelines to create a Digital Product Passport](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Practical DPP design guidance for portal access, searchability, access rights, longevity/availability, security/trust, and procurement briefs. - [CIRPASS DPP System Architecture (D3.2, March 2024) - product-centric architecture](https://doi.org/10.5281/zenodo.10949842?ref=sorena.io) - Reference architecture guidance: product-centric identifiers, decentralised approaches, and interoperability principles. - [GS1 - Digital Product Passport (standards and emerging regulations)](https://www.gs1.org/standards/standards-emerging-regulations/DPP?ref=sorena.io) - Identifier and data standards landscape relevant for DPP interoperability (e.g., GTIN and related GS1 building blocks). ## Related Topic Guides - [DPP Applicability Test (ESPR Scoping) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/applicability-test.md): A step-by-step applicability test for the EU Digital Product Passport (DPP): whether your product group is covered by an ESPR delegated act. - [DPP Architecture & Integration (Open Standards, Registry, APIs) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/architecture-and-integration.md): An advanced architecture guide for EU Digital Product Passport (DPP): product-centric identifiers and resolvers. - [DPP Data Carriers, Access Control & UX | QR Code, Identifier, Public vs Restricted Views](/artifacts/eu/digital-product-passport/data-carriers-access-control-and-ux.md): A deep guide to DPP data carriers and UX under ESPR 2024/1781: physical data carrier requirements (Article 10), persistent unique product identifiers. - [DPP Data Governance RACI Template | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-data-governance-raci-template.md): Copy/paste-ready governance templates for EU Digital Product Passport (DPP): RACI by Annex III field. - [DPP Data Requirements & Fields (Annex III) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/data-requirements-and-fields.md): A practitioner guide to EU DPP data requirements under ESPR (Regulation (EU) 2024/1781): what data fields can be required (Annex III). - [DPP Governance, Verification & Audit Readiness | EU Digital Product Passport](/artifacts/eu/digital-product-passport/governance-verification-and-audit.md): An audit-readiness guide for EU Digital Product Passport (DPP): how to prove DPP data is accurate, complete and up to date (Article 9). - [DPP Implementation Playbook & Vendor Selection | EU Digital Product Passport](/artifacts/eu/digital-product-passport/implementation-playbook-and-vendor-selection.md): A practical playbook for implementing EU Digital Product Passport (DPP): program steps, roles, supplier onboarding, data model and identifiers. - [DPP QR Code Implementation Guide | Data Carrier + Identifier Design](/artifacts/eu/digital-product-passport/dpp-qr-code-implementation-guide.md): A practical implementation guide for using QR codes (and other data carriers) for EU Digital Product Passports: what ESPR requires (Article 10). - [DPP vs Traditional Product Passports (Labels, PDFs, EPREL) | EU Digital Product Passport](/artifacts/eu/digital-product-passport/dpp-vs-traditional-product-passports.md): A deep comparison of the EU Digital Product Passport (DPP) vs traditional product information approaches: physical labels, PDFs/manuals. - [ESPR / DPP Penalties & Fines | EU Digital Product Passport Enforcement](/artifacts/eu/digital-product-passport/penalties-and-fines.md): How penalties work for EU Digital Product Passport obligations under ESPR (Regulation (EU) 2024/1781): Member States set effective. - [EU Digital Product Passport (DPP) Checklist | Audit-Ready Implementation Steps](/artifacts/eu/digital-product-passport/checklist.md): An audit-ready DPP checklist for ESPR 2024/1781: delegated act scoping, model/batch/item granularity, Annex III data mapping, data carriers (QR/ID). - [EU Digital Product Passport (DPP) Compliance Guide | Implementation Playbook](/artifacts/eu/digital-product-passport/compliance.md): A practical compliance guide for EU Digital Product Passport (DPP) under ESPR 2024/1781: how to scope delegated acts, implement Articles 9-15 requirements. - [EU Digital Product Passport (DPP) Deadlines & Compliance Calendar | ESPR 2024/1781](/artifacts/eu/digital-product-passport/deadlines-and-compliance-calendar.md): A calendar-ready timeline for EU Digital Product Passport (DPP) under ESPR (Regulation (EU) 2024/1781): entry into force (18 Jul 2024). - [EU Digital Product Passport (DPP) FAQ | ESPR 2024/1781](/artifacts/eu/digital-product-passport/faq.md): Answers to the most searched EU DPP questions: is DPP mandatory, which products are in scope, model vs batch vs item, what data is required (Annex III). - [EU Digital Product Passport (DPP) Requirements | ESPR Articles 9-15 + Annex III](/artifacts/eu/digital-product-passport/requirements.md): A detailed, execution-ready breakdown of EU Digital Product Passport (DPP) requirements under ESPR (Regulation (EU) 2024/1781): availability (Article 9). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-product-passport/what-is-a-dpp --- --- title: "DSA Ads & Recommender Systems" canonical_url: "https://www.sorena.io/artifacts/eu/digital-services-act/ads-and-recommender-systems" source_url: "https://www.sorena.io/artifacts/eu/digital-services-act/ads-and-recommender-systems" author: "Sorena AI" description: "A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "DSA advertising transparency" - "DSA ad transparency Article 26" - "DSA recommender system transparency Article 27" - "VLOP non profiling recommender option Article 38" - "VLOP ad repository Article 39" - "DSA minors advertising Article 28" - "DSA dark patterns Article 25" - "recommender transparency" - "Article 26" - "Article 27" - "VLOP ad repository" - "non-profiling recommender option" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DSA Ads & Recommender Systems A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27). *Artifact Guide* *EU* ## EU Digital Services Act (DSA) Ads & Recommender Systems How to implement DSA ad transparency and recommender transparency as real UX and data controls. Covers platform and VLOP/VLOSE layers: per-ad disclosures, recommender parameter transparency, ad repositories, and non-profiling options. DSA advertising and recommender obligations are user-facing controls. Compliance isn't a policy statement - it's UI behavior, logging, and the ability to prove what a user saw and why. This page translates Articles 25-28 and (for VLOPs/VLOSEs) Articles 38-39 into implementable requirements, UX patterns, and evidence expectations. ## Ads and recommenders: what the DSA is trying to achieve The DSA adds transparency and user control where ranking and targeting influence what people see. The obligations focus on: clear labeling, attribution (who benefits and who paid), meaningful targeting explanations, and user control over recommender parameters. - User clarity: recipients should be able to tell what is advertising and why they're seeing it. - Control: recipients should be able to influence ranking and recommendations where options exist. - Accountability: VLOPs/VLOSEs have additional public transparency (ad repositories and non-profiling options). ## Article 26 - Advertising transparency (per-ad, real-time disclosures) If you present advertisements on your online interface, Article 26 requires that for each specific ad and each recipient, they can identify certain information clearly, concisely, unambiguously and in real time. Treat this as a UI requirement plus an instrumentation requirement. - Labeling: clearly indicate that the information is an advertisement (prominent marking). - Beneficiary: identify the natural or legal person on whose behalf the ad is presented. - Payer: identify who paid for the ad if different from the beneficiary. - Targeting parameters: provide meaningful information directly and easily accessible from the ad about main parameters used to determine the recipient, and (where applicable) how to change those parameters. - Commercial communications declaration: provide a way for recipients posting content to declare commercial communications and label it accordingly (Article 26(2)). ## Article 27 - Recommender system transparency (parameters + user options) If you use recommender systems, Article 27 requires you to explain the main parameters in your terms and conditions, and describe options for recipients to modify or influence those parameters. In practice, this means "why am I seeing this?" plus a control surface (where options exist). - Explain "why suggested": criteria most significant in determining what is suggested and the reasons for their relative importance. - Document user options: how recipients can modify or influence parameters (e.g., following/interest signals, mute/hide, chronology vs relevance). - If multiple ranking options exist: provide a directly accessible functionality to select and modify preferred option from the prioritized section (Article 27(3)). ## Article 25 - Interface integrity (anti-dark-pattern duty) Article 25 prohibits designing/organising/operating interfaces in a way that deceives or manipulates recipients or materially impairs their ability to make free and informed decisions. Ads and recommender controls are common dark-pattern surfaces (consent, personalization toggles, cancellation flows). - Avoid: making cancellation harder than subscription; repeated coercive popups after choices are made; deceptive defaults. - Make controls discoverable: personalization controls should be easy to find, not hidden behind multi-step flows. - Prove compliance: run UX audits and store evidence (screenshots, user flows, change logs). ## Article 28 - Minors: privacy, safety, and ad restrictions If your platform is accessible to minors, Article 28 requires appropriate and proportionate measures to ensure a high level of privacy, safety, and security of minors on the service. Article 28 also restricts presenting ads to minors based on profiling when you are aware with reasonable certainty the recipient is a minor, without forcing additional personal data processing solely to assess age. - Define minors-accessibility: document how minors can access the service and what protections apply. - Ads: implement "no profiling-based ads to minors" control path where you can reasonably determine minor status. - Safety controls: consider defaults, friction, reporting mechanisms, and safeguards that reduce harmful exposure for minors. ## VLOP/VLOSE upgrade - Article 38: non-profiling option for each recommender system For VLOPs/VLOSEs that use recommender systems, Article 38 adds a specific requirement: provide at least one option for each recommender system that is not based on profiling (GDPR profiling definition referenced). This is a major product requirement: you need an alternative ranking mode and a control surface. - Identify "each recommender system": define the surfaces (feed, search ranking, suggested accounts, recommended products). - Provide a non-profiling option per surface: e.g., chronological ordering, contextual popularity, or explicit user-selected topics without profiling. - Make it selectable: integrate with Article 27 option-selection functionality. - Instrument it: log option selection and ensure the system actually runs without profiling for that option. ## VLOP/VLOSE upgrade - Article 39: ad repository + APIs (searchable, reliable, no personal data) Article 39 requires VLOPs/VLOSEs presenting ads to make a public repository available via a searchable tool (multi-criteria queries) and via APIs, covering the period the ad is shown and for one year after it was last shown. Build this as a product and data platform capability, with privacy protections. - Repository content includes: ad content/subject matter, beneficiary, payer (if different), period shown, and targeting parameters (including exclusion parameters) for intended groups. - Public access + API: provide a reliable search tool and APIs; design rate limits and abuse controls that do not undermine access. - Privacy: ensure repository does not contain personal data of recipients to whom the ad was/could be presented. - Quality: make reasonable efforts to keep repository information accurate and complete. ## Evidence pack (what to retain and how to prove compliance) Ads and recommender compliance is often challenged by "prove it" questions: what did the user see, what did it mean, and what options existed? Build evidence and testing into your release process. - UI evidence: ad labeling screenshots, "why this ad" disclosures, targeting parameter explanations, recommender option selectors. - Policy evidence: terms & conditions sections describing recommender parameters and user options (Article 27). - Data evidence: logs showing ad metadata and disclosures served per impression; recommender option selection and effect. - VLOP evidence: ad repository dataset schema, API docs, and validation checks; non-profiling option test results. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU Digital Services Act (DSA) Ads & Recommender Systems as a cited research workflow Research Copilot can take EU Digital Services Act (DSA) Ads & Recommender Systems from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU Digital Services Act (DSA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Digital Services Act (DSA) Ads & Recommender Systems](/solutions/research-copilot.md): Start from EU Digital Services Act (DSA) Ads & Recommender Systems and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Digital Services Act (DSA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Services Act (DSA) Ads & Recommender Systems. ## Primary sources - [Regulation (EU) 2022/2065 (Digital Services Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/2065/oj?ref=sorena.io) - Primary DSA text for ad transparency (Article 26), recommender transparency (Article 27), anti-manipulation interface duty (Article 25), minors protections (Article 28), VLOP recommender option (Article 38), and VLOP ad repository (Article 39). - [European Commission - Impact of the DSA on platforms and digital advertising](https://digital-strategy.ec.europa.eu/en/policies/dsa-impact-platforms?ref=sorena.io) - Commission overview of how DSA affects platform services, including advertising and transparency expectations. ## Related Topic Guides - [DSA Applicability Test | Is the EU Digital Services Act Applicable to You?](/artifacts/eu/digital-services-act/applicability-test.md): A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers. - [DSA Enforcement & Investigations | DSCs, Commission Powers, Audits & Procedures](/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations.md): A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services. - [DSA Notice & Action Workflow | Article 16 Requirements + Templates](/artifacts/eu/digital-services-act/notice-and-action-workflow.md): A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements. - [DSA Penalties & Fines | Digital Services Act Enforcement Exposure (6% / 1% / 5%)](/artifacts/eu/digital-services-act/penalties-and-fines.md): How DSA penalties work under Regulation (EU) 2022/2065. - [DSA Transparency Report Template | Article 15 + Article 24 + VLOP Article 42](/artifacts/eu/digital-services-act/dsa-transparency-report-template.md): Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835. - [DSA Transparency Reporting | Articles 15, 24 & 42 Reporting Requirements](/artifacts/eu/digital-services-act/transparency-reporting.md): A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24. - [DSA vs DMA | Digital Services Act vs Digital Markets Act (What's the Difference?)](/artifacts/eu/digital-services-act/dsa-vs-dma.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA. - [DSA vs UK Online Safety Act | EU vs UK Online Safety Compliance](/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users). - [EU Digital Services Act (DSA) Requirements | Obligations by Service Type & Tier](/artifacts/eu/digital-services-act/requirements.md): A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms. - [EU DSA Checklist | Digital Services Act Compliance Checklist (Audit-Ready)](/artifacts/eu/digital-services-act/checklist.md): An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency. - [EU DSA Compliance Guide | Digital Services Act Implementation Playbook](/artifacts/eu/digital-services-act/compliance.md): A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering. - [EU DSA Deadlines & Compliance Calendar | Key Dates, Cadence and Milestones](/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar.md): A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24. - [EU DSA FAQ | Digital Services Act Questions & Answers (Practical)](/artifacts/eu/digital-services-act/faq.md): Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what "hosting" and "online platform" mean. - [EU DSA Service Types & Scope | Hosting vs Platform vs Marketplace](/artifacts/eu/digital-services-act/service-types-and-scope.md): How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting). - [VLOP/VLOSE Systemic Risk Assessment (DSA) | Articles 34-36 + Mitigation](/artifacts/eu/digital-services-act/risk-assessments-and-mitigation.md): A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-services-act/ads-and-recommender-systems --- --- title: "DSA Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/digital-services-act/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/digital-services-act/applicability-test" author: "Sorena AI" description: "A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "DSA applicability test" - "is DSA applicable" - "EU Digital Services Act scope" - "Digital Services Act compliance" - "DSA hosting service" - "DSA online platform" - "DSA marketplace" - "VLOP threshold" - "VLOSE threshold" - "DSA applicability" - "DSA scope" - "intermediary services" - "online platform" - "online marketplace" - "VLOP/VLOSE" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DSA Applicability Test A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers. *Artifact Guide* *EU* ## EU Digital Services Act (DSA) Applicability Test A practical, defensible way to decide whether the DSA applies to you - and which layer applies. Use this test to create a scope memo and start a compliance program with the right workstreams. "Does the DSA apply to us?" is rarely a yes/no question. Most teams need a layered answer: which service type(s) are in scope (hosting/platform/marketplace/search), what obligations attach to each service, and whether VLOP/VLOSE systemic-risk obligations could apply. This applicability test walks you through the questions that produce an audit-ready output. ## Output you should produce (what "done" looks like) By the end of this applicability test you should have a 1-2 page scope memo per service, plus an obligation map you can hand to owners. That output becomes the backbone for your DSA checklist, roadmap, and reporting cadence. - Service list: which products/services you operate and which are offered to recipients in the EU. - Service type classification per service: intermediary service -> hosting -> online platform -> marketplace/search engine. - Tier outcome: whether you are likely to be designated as a VLOP/VLOSE and what that implies (risk assessment, audits, enhanced transparency). - Workstreams and owners: content moderation, user redress, transparency reporting, ad/recommender transparency, marketplace checks. - Evidence pack: where the supporting facts live (product specs, UX screenshots, policies, logs, reporting data). ## Step 1 - Do you offer the service in the EU? The DSA applies to services offered to recipients in the Union. For many companies, the "EU offering" determination is practical: can EU users access, use, or be targeted by the service? Document the facts that show EU offering (or lack thereof). - Access: can EU recipients sign up or access content? Are EU languages or currencies supported? - Targeting: do you market to EU recipients, run ads targeting EU, or ship goods/services to the EU? - Operational footprint: do you have an establishment in the EU or use EU-facing domain/localization? - If you're not established in the EU but offer services in the EU, plan for a legal representative (Article 13). ## Step 2 - Are you a provider of intermediary services (baseline layer)? If you transmit, cache, or host information provided by recipients, you're in intermediary service territory and inherit baseline obligations (e.g., terms transparency, points of contact). If you host user-provided information, you should plan for notice & action mechanisms. - Mere conduit: pass-through transmission (common for access providers). - Caching: temporary storage to improve performance (common in CDNs). - Hosting: storage of information provided by recipients at their request (UGC, listings, repositories, comments, file hosting). ## Step 3 - Do you host user-provided information? (hosting layer) Hosting services have a dedicated DSA layer that includes notice & action mechanisms (Article 16) and statements of reasons for restrictions (Article 17). This is often the first "real engineering work" layer. - If you take notices: design intake that is electronic, user-friendly, and captures required elements (Article 16(2)). - If you restrict content/accounts: plan for statement-of-reasons content and logging (Article 17). - If you become aware of certain serious criminal offence risks: plan notification procedures (Article 18). ## Step 4 - Is your hosting service an online platform? Online platforms typically involve dissemination of information to the public (or to other recipients) at the request of the user/recipient who provided it. Online platform status adds user redress and transparency obligations (e.g., Article 24 for platform transparency reporting). - UGC distribution: can a user post content that others can see/search/share? - Ranking and recommendations: do you prioritize content for recipients (recommender transparency duties can apply)? - Ads: if you present ads, ad transparency duties apply (Article 26). - Interface integrity: avoid dark patterns and manipulative design (Article 25). ## Step 5 - Are you an online marketplace (distance contracts with traders)? If consumers can conclude distance contracts with traders on your platform, you likely trigger marketplace obligations: trader traceability, compliance-by-design, and consumer notifications for illegal products/services. This is a high-risk area for enforcement because it directly affects consumer harm. - Trader onboarding: collect required trader identity info and self-certification (Article 30). - Best-effort verification: assess reliability/completeness using official databases and supporting docs (Article 30(2)). - Consumer-facing disclosures: show trader details and compliance statements on listings (Article 30(7)). - Product compliance interface: enable traders to provide safety/compliance information (Article 31). ## Step 6 - Could you be designated a VLOP/VLOSE? VLOP/VLOSE status is a designation outcome tied to average monthly active recipients (AMAR) in the EU and a Commission decision (Article 33). If you are near the threshold, build the systemic-risk layer early: it's the largest program expansion (risk assessment, mitigation, audit, enhanced transparency). - Threshold: AMAR in the Union >= 45 million (Article 33(1)). - Publication duty: publish AMAR at least every 6 months (Article 24(2)). - Systemic risk: annual risk assessment (Article 34) + mitigation measures (Article 35) + independent audits (Article 37) + enhanced transparency (Article 42). - Recommenders: for VLOPs/VLOSEs using recommender systems, offer at least one non-profiling option (Article 38). ## Step 7 - Micro/small enterprise exclusions (apply carefully) Some DSA sections exclude micro and small enterprises, but the exclusions are partial and have overrides for VLOPs/VLOSEs. Make this a documented legal determination and revisit it annually. - Transparency reporting (Article 15): not applicable to micro/small enterprises unless they are VLOPs/VLOSEs. - Marketplace Section 4: excluded for micro/small enterprises, with transition rules and an override for VLOPs (Article 29). - Exclusions do not remove the need for a scope memo, points of contact, and defensible policies for content moderation and user redress. *Recommended next step* *Placement: after the applicability result* ## Turn EU Digital Services Act (DSA) Applicability Test into an operational assessment Assessment Autopilot can take EU Digital Services Act (DSA) Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU Digital Services Act (DSA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Digital Services Act (DSA) Applicability Test](/solutions/assessment.md): Start from EU Digital Services Act (DSA) Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Digital Services Act (DSA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Services Act (DSA) Applicability Test. ## Primary sources - [Regulation (EU) 2022/2065 (Digital Services Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/2065/oj?ref=sorena.io) - Primary DSA legal text: layered obligations by service type and tier (Articles 12-18, 24-28, 29-33, 34-39, 42, 52). - [European Commission - The Digital Services Act (overview)](https://digital-strategy.ec.europa.eu/en/policies/digital-services-act?ref=sorena.io) - High-level overview of covered service types and compliance goals (safe and trustworthy online environment). ## Related Topic Guides - [DSA Ads & Recommender Systems | Article 26, 27, 38 & 39 Compliance](/artifacts/eu/digital-services-act/ads-and-recommender-systems.md): A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27). - [DSA Enforcement & Investigations | DSCs, Commission Powers, Audits & Procedures](/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations.md): A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services. - [DSA Notice & Action Workflow | Article 16 Requirements + Templates](/artifacts/eu/digital-services-act/notice-and-action-workflow.md): A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements. - [DSA Penalties & Fines | Digital Services Act Enforcement Exposure (6% / 1% / 5%)](/artifacts/eu/digital-services-act/penalties-and-fines.md): How DSA penalties work under Regulation (EU) 2022/2065. - [DSA Transparency Report Template | Article 15 + Article 24 + VLOP Article 42](/artifacts/eu/digital-services-act/dsa-transparency-report-template.md): Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835. - [DSA Transparency Reporting | Articles 15, 24 & 42 Reporting Requirements](/artifacts/eu/digital-services-act/transparency-reporting.md): A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24. - [DSA vs DMA | Digital Services Act vs Digital Markets Act (What's the Difference?)](/artifacts/eu/digital-services-act/dsa-vs-dma.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA. - [DSA vs UK Online Safety Act | EU vs UK Online Safety Compliance](/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users). - [EU Digital Services Act (DSA) Requirements | Obligations by Service Type & Tier](/artifacts/eu/digital-services-act/requirements.md): A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms. - [EU DSA Checklist | Digital Services Act Compliance Checklist (Audit-Ready)](/artifacts/eu/digital-services-act/checklist.md): An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency. - [EU DSA Compliance Guide | Digital Services Act Implementation Playbook](/artifacts/eu/digital-services-act/compliance.md): A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering. - [EU DSA Deadlines & Compliance Calendar | Key Dates, Cadence and Milestones](/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar.md): A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24. - [EU DSA FAQ | Digital Services Act Questions & Answers (Practical)](/artifacts/eu/digital-services-act/faq.md): Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what "hosting" and "online platform" mean. - [EU DSA Service Types & Scope | Hosting vs Platform vs Marketplace](/artifacts/eu/digital-services-act/service-types-and-scope.md): How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting). - [VLOP/VLOSE Systemic Risk Assessment (DSA) | Articles 34-36 + Mitigation](/artifacts/eu/digital-services-act/risk-assessments-and-mitigation.md): A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-services-act/applicability-test --- --- title: "EU DSA Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/digital-services-act/checklist" source_url: "https://www.sorena.io/artifacts/eu/digital-services-act/checklist" author: "Sorena AI" description: "An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU DSA checklist" - "DSA compliance checklist" - "Digital Services Act checklist" - "DSA audit checklist" - "notice and action checklist" - "statement of reasons checklist" - "DSA transparency report checklist" - "VLOP compliance checklist" - "marketplace DSA checklist" - "DSA checklist" - "notice and action" - "statement of reasons" - "transparency reporting" - "marketplace compliance" - "VLOP audit" - "systemic risk" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DSA Checklist An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency. *Checklist* *EU* ## EU Digital Services Act (DSA) Checklist A checklist you can run per service and tier - and reuse for audits and enforcement questions. Structured as teams execute: scope -> workflows -> reporting -> tier upgrades (marketplace, VLOP/VLOSE). DSA compliance is a program, not a one-time policy update. Use this checklist per service (you may operate multiple services) and per tier (intermediary/hosting/platform/marketplace/VLOP). Each checklist item should have an owner, acceptance criteria, and evidence you can retrieve later. ## Checklist A - Scope memo and tiering (the "defensible baseline") Before you build controls, lock your classification and tier assumptions. This prevents scope drift and ensures you implement the right obligation set. - Inventory each service: features, recipients, and EU offering facts. - Classify per service: intermediary -> hosting -> online platform -> marketplace/search engine. - Document micro/small status analysis (if claimed) and exceptions/overrides. - Define tier trigger metrics: AMAR calculation approach (Article 24) and VLOP/VLOSE threshold monitoring (Article 33). - Produce a requirements matrix: Article -> obligation -> control -> owner -> evidence -> reporting cadence. *Recommended next step* *Placement: after the checklist block* ## Turn EU Digital Services Act (DSA) Checklist into an operational assessment Assessment Autopilot can take EU Digital Services Act (DSA) Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Digital Services Act (DSA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Digital Services Act (DSA) Checklist](/solutions/assessment.md): Start from EU Digital Services Act (DSA) Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Digital Services Act (DSA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Services Act (DSA) Checklist. ## Checklist B - Terms, contact points, and operational readiness Baseline obligations are operational: recipients must be able to reach you and understand how moderation works. These are foundational because they appear in multiple reporting and redress pathways. - Single point of contact for recipients is user-friendly and not solely automated (Article 12). - If not established in the EU and offering services in the EU, designate a legal representative and publish contact details (Article 13). - Update terms and conditions to disclose content moderation policies, procedures, measures, and tools (including algorithmic decision-making + human review) in clear, plain, machine-readable format (Article 14). - Build change management: recipients are informed of significant terms changes (Article 14(2)); minors-friendly explanations where relevant (Article 14(3)). ## Checklist C - Hosting workflows: notice & action + statement of reasons If you host user-provided information, your first engineering deliverable is a notice & action system plus explainability for restrictions. Treat these as compliance workflows with SLAs, audit logs, and QA. - Notice intake mechanism is electronic, easy to access, user-friendly (Article 16(1)). - Notice form captures required elements (Article 16(2)): reasons, exact location (URLs), notifier identity (with narrow exception), and good-faith statement. - Processing is timely, diligent, non-arbitrary, objective; automation use is disclosed in notifications (Article 16(6)). - Notifiers receive receipt confirmation and decision notification with redress options (Article 16(4)-(5)). - Affected recipients receive a clear, specific statement of reasons for restrictions (Article 17) including grounds, facts, automation use, and redress options. - Criminal threat reporting process exists for serious suspected offences (Article 18). ## Checklist D - Platform layer: transparency reporting + interface integrity Online platforms carry additional transparency and integrity duties, often requiring data pipelines and UI changes. Make reporting a product: define data owners, validation, and sign-off. - Annual transparency report (Article 15) is produced and published; covers orders, notices, complaints, automated moderation, and error/accuracy indicators. - If you are an online platform: include Article 24 additions (out-of-court dispute settlement metrics, suspensions) and publish AMAR every 6 months (Article 24(2)). - Submit Article 17 statements of reasons for inclusion in the Commission database (Article 24(5)), ensuring no personal data is included. - Interface is designed to avoid manipulative patterns (Article 25): termination not harder than subscription, no repeated coercive popups, etc. - Ads transparency (Article 26) and recommender transparency (Article 27) controls are implemented if applicable. ## Checklist E - Marketplace layer (distance contracts with traders) If consumers can conclude distance contracts with traders, trader traceability and compliance-by-design become core controls. Plan for KYC-like onboarding, verification, suspension, retention and deletion. - Trader onboarding collects Article 30 information (identity/contact, register IDs, payment account details, self-certification). - Best-effort reliability checks are implemented using official databases and supporting documents (Article 30(2)). - Suspension workflow for missing/inaccurate trader info exists (Article 30(2)-(3)) and complaint path is documented (Article 30(4)). - Consumer-facing trader info is displayed on listings (Article 30(7)). - Interface enables traders to provide required product safety/compliance information (Article 31) and supports random illegality checks (Article 31(3)). - Consumer notification/redress workflow exists when illegal products/services are discovered (Article 32). ## Checklist F - VLOP/VLOSE layer (systemic risk, audits, and enhanced transparency) VLOP/VLOSE compliance is a governance and risk-management program with an annual audit cycle. If you could be designated, build the calendar and evidence model early. - AMAR methodology is defensible and published at least every 6 months (Article 24(2)); prepare for Commission requests (Article 24(3)). - Risk assessment is completed at designation application date and at least annually; repeated before major feature launches (Article 34). - Risk mitigation measures are defined, owned, and monitored (Article 35) with a clear measurement plan. - Independent audit is performed and an audit implementation report is produced (Article 37). - Enhanced transparency reporting cadence is established (Article 42): at least every 6 months plus publication of risk assessment, mitigation, audit and implementation reports (with confidentiality carve-outs). - Recommender non-profiling option exists for each recommender system (Article 38) and ad repository exists with search tool + APIs (Article 39). ## Checklist G - Enforcement readiness (the evidence pack) Enforcement risk drops when you can explain your decisions and produce evidence quickly. Build an evidence pack that maps to workflows and reporting outputs. - Policy evidence: terms transparency, moderation policies, redress policies, marketplace policies. - Workflow evidence: notice processing logs, decision timestamps, statement-of-reasons records, appeals outcomes. - Reporting evidence: dataset definitions, QA checks, sign-offs, and published reports. - Security and privacy: ensure DSA submissions (e.g., statement-of-reasons database) exclude personal data where required. - Governance: owners, RACI, review cadence, and change management for scope and control updates. ## Primary sources - [Regulation (EU) 2022/2065 (Digital Services Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/2065/oj?ref=sorena.io) - Primary legal text for obligations and evidence expectations referenced in this checklist (Articles 12-18, 15/24/42 reporting, 25-28 platform duties, 30-32 marketplace, 33-39 VLOP/VLOSE, 52 penalties). - [European Commission - The enforcement framework under the Digital Services Act](https://digital-strategy.ec.europa.eu/en/policies/dsa-enforcement?ref=sorena.io) - Commission overview of enforcement and supervision, including VLOP supervision, investigations, and transparency expectations. ## Related Topic Guides - [DSA Ads & Recommender Systems | Article 26, 27, 38 & 39 Compliance](/artifacts/eu/digital-services-act/ads-and-recommender-systems.md): A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27). - [DSA Applicability Test | Is the EU Digital Services Act Applicable to You?](/artifacts/eu/digital-services-act/applicability-test.md): A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers. - [DSA Enforcement & Investigations | DSCs, Commission Powers, Audits & Procedures](/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations.md): A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services. - [DSA Notice & Action Workflow | Article 16 Requirements + Templates](/artifacts/eu/digital-services-act/notice-and-action-workflow.md): A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements. - [DSA Penalties & Fines | Digital Services Act Enforcement Exposure (6% / 1% / 5%)](/artifacts/eu/digital-services-act/penalties-and-fines.md): How DSA penalties work under Regulation (EU) 2022/2065. - [DSA Transparency Report Template | Article 15 + Article 24 + VLOP Article 42](/artifacts/eu/digital-services-act/dsa-transparency-report-template.md): Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835. - [DSA Transparency Reporting | Articles 15, 24 & 42 Reporting Requirements](/artifacts/eu/digital-services-act/transparency-reporting.md): A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24. - [DSA vs DMA | Digital Services Act vs Digital Markets Act (What's the Difference?)](/artifacts/eu/digital-services-act/dsa-vs-dma.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA. - [DSA vs UK Online Safety Act | EU vs UK Online Safety Compliance](/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users). - [EU Digital Services Act (DSA) Requirements | Obligations by Service Type & Tier](/artifacts/eu/digital-services-act/requirements.md): A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms. - [EU DSA Compliance Guide | Digital Services Act Implementation Playbook](/artifacts/eu/digital-services-act/compliance.md): A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering. - [EU DSA Deadlines & Compliance Calendar | Key Dates, Cadence and Milestones](/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar.md): A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24. - [EU DSA FAQ | Digital Services Act Questions & Answers (Practical)](/artifacts/eu/digital-services-act/faq.md): Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what "hosting" and "online platform" mean. - [EU DSA Service Types & Scope | Hosting vs Platform vs Marketplace](/artifacts/eu/digital-services-act/service-types-and-scope.md): How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting). - [VLOP/VLOSE Systemic Risk Assessment (DSA) | Articles 34-36 + Mitigation](/artifacts/eu/digital-services-act/risk-assessments-and-mitigation.md): A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-services-act/checklist --- --- title: "EU DSA Compliance Guide" canonical_url: "https://www.sorena.io/artifacts/eu/digital-services-act/compliance" source_url: "https://www.sorena.io/artifacts/eu/digital-services-act/compliance" author: "Sorena AI" description: "A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU DSA compliance guide" - "Digital Services Act compliance" - "DSA implementation guide" - "DSA compliance program" - "notice and action implementation" - "statement of reasons implementation" - "DSA transparency reporting" - "VLOP compliance program" - "DSA marketplace compliance" - "DSA compliance" - "implementation playbook" - "notice and action" - "statement of reasons" - "transparency reporting" - "marketplace compliance" - "VLOP audit" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DSA Compliance Guide A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering. *Implementation Guide* *EU* ## EU Digital Services Act (DSA) Compliance Playbook A practical implementation playbook: controls, workflows, evidence and cadence. Designed for product, legal, security, data and trust & safety teams building DSA compliance together. The fastest way to implement DSA compliance is to build around high-leverage workflows that support multiple obligations at once: (1) notice & action + statement of reasons, and (2) transparency reporting pipelines. This playbook turns the DSA into an operating model with owners, artifacts, and an ongoing cadence. ## Step 1 - Lock scope and tier (write the scope memo) Start by classifying each service you operate. The DSA is layered; the obligations you must ship depend on your service type (hosting/platform/marketplace/search) and whether you may be designated as a VLOP/VLOSE. Treat scope as a living artifact and assign an owner for scope changes. - Inventory each service and map features (UGC, ranking, ads, trading, search). - Classify per service: intermediary -> hosting -> online platform -> marketplace/search engine. - Decide if you are near VLOP/VLOSE thresholds and define AMAR methodology (Article 24) and monitoring cadence. - Create a requirements matrix: Article -> obligation -> control -> owner -> evidence. ## Step 2 - Ship baseline controls (terms, contact points, legal rep) Baseline controls are prerequisites for later workflows: they define how users contact you, what your moderation rules are, and how regulators reach you if you're not established in the EU. Don't treat these as "legal-only" updates - they must be machine-readable and operationally correct. - Implement a recipient point of contact that's user-friendly and not solely automated (Article 12). - If relevant, appoint and publish a legal representative in the EU (Article 13). - Update terms and conditions to describe moderation policies/tools and internal complaint procedures in clear language and machine-readable format (Article 14). - Define change management: how you notify recipients of significant terms updates and how minors-facing explanations are delivered where applicable. ## Step 3 - Build the core compliance workflow: notice & action (Article 16) For hosting services, notice & action is the primary compliance workflow. Build it like a regulated intake system: precise, measurable, and auditable. The workflow should support both legal illegality analysis and terms-and-conditions enforcement - and record which was applied. - Design notice intake forms to capture Article 16(2) elements (reasons, exact location/URLs, identity details, good-faith statement). - Build triage: duplicate detection, queueing, escalation, and SLA tracking; measure timeliness and consistency. - Confirm receipt and communicate decisions with redress options (Article 16(4)-(5)). - If automation is used, record and disclose it in notifications (Article 16(6)). *Recommended next step* *Placement: after the compliance steps* ## Turn EU Digital Services Act (DSA) Compliance Playbook into an operational assessment Assessment Autopilot can take EU Digital Services Act (DSA) Compliance Playbook from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Digital Services Act (DSA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Digital Services Act (DSA) Compliance Playbook](/solutions/assessment.md): Start from EU Digital Services Act (DSA) Compliance Playbook and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Digital Services Act (DSA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Services Act (DSA) Compliance Playbook. ## Step 4 - Statement of reasons pipeline (Article 17) + public database submissions (Article 24(5)) Statement of reasons is compliance glue: it drives user trust, supports appeals, and supplies transparency reporting datasets. Make it a structured object, not a free-form email. - Create a statement-of-reasons data model: restriction type, content/account scope, duration, territorial scope, grounds (legal/contract), facts, automation use, redress options. - Enforce quality gates: statements must be clear, specific, and complete enough for recipients to exercise redress. - If you are an online platform, implement Article 24(5) submissions to the Commission database while excluding personal data. ## Step 5 - Transparency reporting as a data product (Articles 15 + 24 + 42) Transparency reports should be produced by a stable data pipeline with QA and sign-off, not assembled manually at the end of the year. Build reporting by mapping obligations to metrics and authoritative data sources. - Define metrics for Article 15: orders, notices, complaint counts/outcomes, own-initiative moderation, automated moderation usage, accuracy/error indicators. - If online platform: include Article 24 additions (out-of-court dispute settlement metrics, suspensions) and publish AMAR every 6 months (Article 24(2)). - If VLOP/VLOSE: implement Article 42 cadence (at least every 6 months) and publication of risk, mitigation, audit and implementation reports with confidentiality carve-outs. ## Step 6 - Platform UX duties: ads, recommenders, and interface integrity These obligations are UX-visible. Compliance requires both UI design and instrumentation. Treat them as product requirements with acceptance criteria and testing. - Ad transparency (Article 26): per-ad "this is an ad", beneficiary, payer (if different), and meaningful targeting parameters plus how to change them. - Recommender transparency (Article 27): disclose main parameters in terms and conditions and provide accessible controls to modify ranking options. - Anti-dark-pattern duty (Article 25): ensure flows don't manipulate recipients (e.g., cancellation not harder than subscription). - Minors protections (Article 28): privacy/safety/security measures and restrictions on profiling-based ads to minors. ## Step 7 - Marketplace controls (if applicable): trader traceability + compliance-by-design Marketplace obligations require operational controls and retention/deletion discipline. Build onboarding verification and suspension workflows that are measurable and enforceable. - Implement trader onboarding and verification (Article 30) with best-effort checks via official databases and reliable sources. - Display required trader information to consumers on listings (Article 30(7)). - Ensure UI lets traders provide product safety/compliance information (Article 31) and implement random checks for illegality (Article 31(3)). - Implement consumer notification/redress workflow for illegal products/services (Article 32). ## Step 8 - VLOP/VLOSE systemic-risk and audit readiness (if applicable) VLOP/VLOSE readiness is a risk management program: annual risk assessments, mitigation, independent audits, and publication duties. If you're near the threshold, build the calendar and evidence model early. - Systemic risk assessment process exists and is repeated at least annually (Article 34), including before major feature launches. - Mitigation measures are defined, measured, and governed (Article 35). - Independent audit process and remediation planning are integrated into the annual cycle (Article 37). - Recommender non-profiling option (Article 38) and ad repository (Article 39) are implemented where applicable. ## Step 9 - Governance, RACI, and enforcement evidence DSA programs fail when ownership is unclear or evidence is not retrievable. Build governance that survives staff changes and vendor changes. - RACI per workstream: moderation ops, appeals, reporting, ads/recommenders, marketplace onboarding, risk/audit. - Evidence retention policy for logs, statements of reasons, reporting datasets, and incident records. - Quarterly compliance review and annual "DSA report readiness" tabletop exercise. - Enforcement readiness playbook: how you respond to regulator questions and produce artifacts quickly. ## Primary sources - [Regulation (EU) 2022/2065 (Digital Services Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/2065/oj?ref=sorena.io) - Primary DSA obligations and workflows referenced (Articles 12-18, 15/24/42 reporting, 25-28, 30-33, 34-39). - [European Commission - The enforcement framework under the Digital Services Act](https://digital-strategy.ec.europa.eu/en/policies/dsa-enforcement?ref=sorena.io) - Commission overview of supervisory and enforcement framework, including VLOP investigations and enforcement actions. ## Related Topic Guides - [DSA Ads & Recommender Systems | Article 26, 27, 38 & 39 Compliance](/artifacts/eu/digital-services-act/ads-and-recommender-systems.md): A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27). - [DSA Applicability Test | Is the EU Digital Services Act Applicable to You?](/artifacts/eu/digital-services-act/applicability-test.md): A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers. - [DSA Enforcement & Investigations | DSCs, Commission Powers, Audits & Procedures](/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations.md): A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services. - [DSA Notice & Action Workflow | Article 16 Requirements + Templates](/artifacts/eu/digital-services-act/notice-and-action-workflow.md): A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements. - [DSA Penalties & Fines | Digital Services Act Enforcement Exposure (6% / 1% / 5%)](/artifacts/eu/digital-services-act/penalties-and-fines.md): How DSA penalties work under Regulation (EU) 2022/2065. - [DSA Transparency Report Template | Article 15 + Article 24 + VLOP Article 42](/artifacts/eu/digital-services-act/dsa-transparency-report-template.md): Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835. - [DSA Transparency Reporting | Articles 15, 24 & 42 Reporting Requirements](/artifacts/eu/digital-services-act/transparency-reporting.md): A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24. - [DSA vs DMA | Digital Services Act vs Digital Markets Act (What's the Difference?)](/artifacts/eu/digital-services-act/dsa-vs-dma.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA. - [DSA vs UK Online Safety Act | EU vs UK Online Safety Compliance](/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users). - [EU Digital Services Act (DSA) Requirements | Obligations by Service Type & Tier](/artifacts/eu/digital-services-act/requirements.md): A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms. - [EU DSA Checklist | Digital Services Act Compliance Checklist (Audit-Ready)](/artifacts/eu/digital-services-act/checklist.md): An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency. - [EU DSA Deadlines & Compliance Calendar | Key Dates, Cadence and Milestones](/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar.md): A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24. - [EU DSA FAQ | Digital Services Act Questions & Answers (Practical)](/artifacts/eu/digital-services-act/faq.md): Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what "hosting" and "online platform" mean. - [EU DSA Service Types & Scope | Hosting vs Platform vs Marketplace](/artifacts/eu/digital-services-act/service-types-and-scope.md): How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting). - [VLOP/VLOSE Systemic Risk Assessment (DSA) | Articles 34-36 + Mitigation](/artifacts/eu/digital-services-act/risk-assessments-and-mitigation.md): A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-services-act/compliance --- --- title: "EU DSA Deadlines & Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU DSA deadlines" - "DSA compliance calendar" - "Digital Services Act key dates" - "DSA applicability date 17 February 2024" - "DSA entry into force" - "Digital Services Coordinator deadline" - "AMAR publication every six months" - "VLOP designation timeline" - "DSA risk assessment annual" - "DSA audit annual" - "DSA deadlines" - "DSA key dates" - "VLOP/VLOSE timeline" - "transparency reporting cadence" - "risk assessment cycle" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DSA Deadlines & Compliance Calendar A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24. *Artifact Guide* *EU* ## EU Digital Services Act (DSA) Deadlines & Compliance Calendar Key dates and cadences you can plug into your governance calendar. Includes general applicability, the 2025 reporting-template transition, AMAR publication cadence, VLOP or VLOSE designation windows, and annual risk and audit cycles. DSA compliance is not just an initial rollout. It now runs on fixed cadences for transparency reporting, average monthly active recipients publication, and, for VLOPs and VLOSEs, systemic risk assessment and independent audits. Use this page to build a compliance calendar with owners, evidence checkpoints, and report-publication deadlines. ## Baseline dates: publication, entry into force, and general applicability The DSA was adopted in October 2022 and published in the Official Journal later that month. It enters into force on the twentieth day following publication, and it has a general date of applicability in February 2024. - Adoption: 19 October 2022 (Regulation (EU) 2022/2065). - Official Journal publication: 27 October 2022 (OJ L 277). - Entry into force: twentieth day following publication (commonly calculated as 16 November 2022 for the DSA). - General date of applicability: 17 February 2024. ## Regulator readiness milestones: Digital Services Coordinators (DSCs) National supervision is coordinated through Digital Services Coordinators (DSCs). Your compliance program should anticipate regulator questions and evidence requests once supervision is operational. DSC designation timing matters for enforcement expectations and cross-border cooperation. - DSC designation deadline: Member States designate DSCs by 17 February 2024. - Practical impact: build an evidence pack and a regulatory response playbook before "steady state" enforcement begins. - If you are not established in the EU but offer services in the EU: legal representative readiness (Article 13) should be in place early. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU Digital Services Act (DSA) Deadlines & Compliance Calendar into an operational assessment Assessment Autopilot can take EU Digital Services Act (DSA) Deadlines & Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Digital Services Act (DSA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Digital Services Act (DSA) Deadlines & Compliance Calendar](/solutions/assessment.md): Start from EU Digital Services Act (DSA) Deadlines & Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Digital Services Act (DSA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Services Act (DSA) Deadlines & Compliance Calendar. ## Always-on cadence: transparency reporting for intermediary services (Article 15) Transparency reporting is an ongoing requirement: at least once a year, publish a machine-readable report on content moderation activities, including orders, notices, complaints, own-initiative actions, and automation usage and accuracy indicators. Treat this as a recurring data product with QA and sign-off - not a one-off document. - Cadence: at least annually (unless excluded as micro/small enterprise and not a VLOP/VLOSE). - Build a "reporting close" calendar: data freeze -> QA -> approval -> publication -> archive evidence. - Keep supporting datasets and definitions (metrics dictionary, sampling, error indicators) for enforcement questions. ## Reporting templates and harmonized reporting periods under Implementing Regulation (EU) 2024/2835 The Commission adopted a reporting-template regulation in November 2024 to harmonize how Article 15, 24, and 42 transparency reports are structured and published. This matters operationally because 2025 includes a transitional reporting cycle and from 1 January 2026 the reporting periods are aligned across providers. - Implementing Regulation (EU) 2024/2835 was adopted on 4 November 2024 and published in the Official Journal on 5 November 2024. - Providers must use the Annex I templates as of 1 July 2025. - First annual transparency report under the DSA baseline cycle had to be published by 16 February 2025. - The second reporting cycle starts no later than 17 February 2025 and runs until 31 December 2025. - From 1 January 2026, providers follow the harmonized reporting periods in the implementing regulation and must publish each report no later than 2 months after the reporting period ends. - Published reports, including corrected versions, must remain publicly available for at least 5 years. ## Platform cadence: publish AMAR every 6 months (Article 24(2)) Online platforms and online search engines must publish the number of average monthly active recipients (AMAR) in the Union, calculated as an average over the past six months, at least once every six months. This cadence is also a VLOP/VLOSE risk indicator because designation thresholds are based on AMAR and a Commission decision (Article 33). - Cadence: by 17 February 2023 and at least every 6 months thereafter, publish AMAR for each platform/search engine. - Operationalize AMAR: define methodology, data sources, QA controls, and executive sign-off. - Threshold monitoring: if you approach 45 million AMAR in the EU, treat VLOP/VLOSE readiness as a program (not a scramble). ## VLOP/VLOSE designation windows (Article 33) and the "4 months after notification" rule VLOP/VLOSE obligations apply (or cease) from four months after the provider is notified of the Commission designation (or termination) decision. This creates a predictable "tier upgrade" timeline - but only if you have prebuilt capabilities. - Trigger: Commission decision designating a service as VLOP/VLOSE (based on AMAR and other information). - Effective window: obligations apply from four months after notification (and can be earlier than 17 February 2024 for designated services). - Preparation timeline: treat "4 months" as your final integration window, not your project start date. ## VLOP/VLOSE recurring cycles: systemic risk assessment + audits + publication (Articles 34, 37, 42) For VLOPs/VLOSEs, compliance becomes cyclical: annual risk assessments, mitigation measures, independent audits, and frequent transparency reporting. Plan a calendar that includes remediation time and the publication deadlines. - Systemic risk assessment: at designation application date and at least annually thereafter; also before deploying features likely to critically impact risks (Article 34). - Independent audit: performed at least once a year; if findings are not fully positive, plan remediation and an audit implementation report (Article 37). - Enhanced transparency reporting: at least every 6 months (Article 42) plus publication/transmission of risk assessment outputs, mitigation measures, audit report and audit implementation report within the required windows. ## Marketplace deadlines: trader data catch-up window (Article 30 transitional rule) Marketplaces must collect trader traceability information before allowing use - but the DSA also sets a catch-up window for traders already onboard at the general applicability date. This is a classic "data debt" program: plan it like a migration with enforcement gates. - Existing traders as of 17 February 2024: best efforts to obtain required trader information within 12 months (Article 30(2)). - If traders fail to provide required information within that window: suspend services until complete (Article 30(2)). - Plan enforcement-friendly communication: notices, deadlines, remediation help, and suspension policy evidence. ## Primary sources - [Regulation (EU) 2022/2065 (Digital Services Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/2065/oj?ref=sorena.io) - Primary legal text for DSA dates and cadences (entry into force clause, general applicability date, Article 24 AMAR cadence, Article 33 designation timing, Articles 34/37/42 cycles, and marketplace transitional rule in Article 30). - [European Commission - The enforcement framework under the Digital Services Act](https://digital-strategy.ec.europa.eu/en/policies/dsa-enforcement?ref=sorena.io) - Commission overview of applicability and enforcement, including designation and early application to VLOPs/VLOSEs. - [Commission Implementing Regulation (EU) 2024/2835 - Transparency reporting templates](https://eur-lex.europa.eu/eli/reg_impl/2024/2835/oj?ref=sorena.io) - Defines harmonized templates, transitional reporting cycles, publication deadlines, format rules, and retention and versioning for Articles 15, 24, and 42 reports. ## Related Topic Guides - [DSA Ads & Recommender Systems | Article 26, 27, 38 & 39 Compliance](/artifacts/eu/digital-services-act/ads-and-recommender-systems.md): A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27). - [DSA Applicability Test | Is the EU Digital Services Act Applicable to You?](/artifacts/eu/digital-services-act/applicability-test.md): A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers. - [DSA Enforcement & Investigations | DSCs, Commission Powers, Audits & Procedures](/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations.md): A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services. - [DSA Notice & Action Workflow | Article 16 Requirements + Templates](/artifacts/eu/digital-services-act/notice-and-action-workflow.md): A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements. - [DSA Penalties & Fines | Digital Services Act Enforcement Exposure (6% / 1% / 5%)](/artifacts/eu/digital-services-act/penalties-and-fines.md): How DSA penalties work under Regulation (EU) 2022/2065. - [DSA Transparency Report Template | Article 15 + Article 24 + VLOP Article 42](/artifacts/eu/digital-services-act/dsa-transparency-report-template.md): Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835. - [DSA Transparency Reporting | Articles 15, 24 & 42 Reporting Requirements](/artifacts/eu/digital-services-act/transparency-reporting.md): A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24. - [DSA vs DMA | Digital Services Act vs Digital Markets Act (What's the Difference?)](/artifacts/eu/digital-services-act/dsa-vs-dma.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA. - [DSA vs UK Online Safety Act | EU vs UK Online Safety Compliance](/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users). - [EU Digital Services Act (DSA) Requirements | Obligations by Service Type & Tier](/artifacts/eu/digital-services-act/requirements.md): A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms. - [EU DSA Checklist | Digital Services Act Compliance Checklist (Audit-Ready)](/artifacts/eu/digital-services-act/checklist.md): An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency. - [EU DSA Compliance Guide | Digital Services Act Implementation Playbook](/artifacts/eu/digital-services-act/compliance.md): A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering. - [EU DSA FAQ | Digital Services Act Questions & Answers (Practical)](/artifacts/eu/digital-services-act/faq.md): Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what "hosting" and "online platform" mean. - [EU DSA Service Types & Scope | Hosting vs Platform vs Marketplace](/artifacts/eu/digital-services-act/service-types-and-scope.md): How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting). - [VLOP/VLOSE Systemic Risk Assessment (DSA) | Articles 34-36 + Mitigation](/artifacts/eu/digital-services-act/risk-assessments-and-mitigation.md): A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar --- --- title: "DSA Transparency Report Template" canonical_url: "https://www.sorena.io/artifacts/eu/digital-services-act/dsa-transparency-report-template" source_url: "https://www.sorena.io/artifacts/eu/digital-services-act/dsa-transparency-report-template" author: "Sorena AI" description: "Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "DSA transparency report template" - "Digital Services Act report template" - "Article 15 transparency report template" - "Article 24 reporting template" - "VLOP transparency reporting Article 42" - "AMAR template" - "statement of reasons database reporting" - "DSA template" - "transparency report template" - "Article 15" - "Article 24" - "Article 42" - "AMAR" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DSA Transparency Report Template Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835. *Template* *EU* ## EU Digital Services Act (DSA) Transparency Report Template A reporting-ready template aligned to DSA Articles 15, 24 and 42. Built for clarity, metric definitions, reproducibility, and the current Commission reporting-template rules. DSA transparency reports should be machine-readable, metric-defined, and reproducible. Use this template as a structure for your annual Article 15 report, expand it with Article 24 modules if you are an online platform, and add Article 42 modules if you are a VLOP or VLOSE. Replace placeholders with your actual metrics, keep a metric dictionary appendix, and publish the final report using the current Commission template rules. ## How to use this template (recommended workflow) Treat this as a reporting workflow: data freeze -> QA -> sign-off -> publication -> archive evidence. Include a metric dictionary so anyone can reproduce the numbers from the same data sources. - Step 1: Decide your tier modules (Article 15 only vs add Article 24 vs add Article 42). - Step 2: Populate metric dictionary (definition, source system, counting rules, validation). - Step 3: Generate report from structured datasets (avoid manual spreadsheets). - Step 4: Run QA checks and keep a QA report as part of your evidence pack. - Step 5: Export the final report in the Commission template format and archive the publication bundle, including prior versions if you republish. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Digital Services Act (DSA) Transparency Report Template in one governed evidence system SSOT can take EU Digital Services Act (DSA) Transparency Report Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Digital Services Act (DSA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Digital Services Act (DSA) Transparency Report Template](/solutions/ssot.md): Start from EU Digital Services Act (DSA) Transparency Report Template and keep documents, evidence, and control records in one governed system. - [Talk through EU Digital Services Act (DSA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Services Act (DSA) Transparency Report Template. ## Template mechanics required by Implementing Regulation (EU) 2024/2835 The Commission templates do more than suggest a layout. They set the reporting periods, machine-readable publication format, retention period, and correction workflow. Build these mechanics into your reporting runbook before you start drafting sections. - Use the Annex I templates from 1 July 2025 onward for Articles 15, 24, and 42 reports. - Publish each report no later than 2 months after the reporting period ends. - Publish the completed report in ODF CSV format compliant with RFC 4180 and UTF-8 encoding. - Retain each published report, and every updated version of it, for at least 5 years. - If you update a report, clearly mark the version, explain the change, and keep all prior versions publicly available. ## Template - Executive summary (1 page) Purpose: explain what service(s) the report covers, time period, reporting scope assumptions, and a high-level moderation and safety summary. Keep it factual and metric-backed. - Service(s) covered, jurisdictional scope, reporting period, and contact point. - Content moderation overview: volumes, major categories, and notable changes vs prior period. - Automation and human review: what's automated, what's human-reviewed, and how accuracy is monitored. - Statement on data limitations and how you address them. ## Template - Article 15 core modules (annual report) Use the modules below to cover Article 15 reporting elements. Only include the modules that apply to your service type (intermediary vs hosting vs platform). For each module, include: definition, dataset, and median time calculations. - Module A: Orders from Member State authorities - volumes by illegal-content type and Member State; median times to acknowledge and act. - Module B: Hosting notices (Article 16) - volumes by alleged illegal-content type; trusted flagger volumes; action outcomes and grounds; automation usage; median time to action. - Module C: Own-initiative moderation - meaningful description of moderation; detection methods; restriction types; volumes by category. - Module D: Complaints and reversals - complaints through internal systems; bases; outcomes; median times; reversal counts. - Module E: Automated moderation - purpose, indicators of accuracy/error, and safeguards. ## Template - Article 24 modules (online platforms and search engines) If you are an online platform, add these modules to cover Article 24(1) additions and operational duties. Even when modules aren't published (e.g., AMAR methodology details), keep them internally for enforcement readiness. - Module F: Out-of-court dispute settlement - disputes submitted, outcomes, median completion time, implementation rate of decisions. - Module G: Suspensions under misuse protections - counts by suspension type (illegal content vs unfounded notices/complaints). - Module H: AMAR publication - AMAR in the Union (6-month average), methodology summary and QA checks (Article 24(2)). - Module I: Statement-of-reasons database submissions - process and QA controls to ensure submissions exclude personal data (Article 24(5)). ## Template - Article 42 modules (VLOPs/VLOSEs) If you are a VLOP/VLOSE, add the modules below to meet the enhanced transparency obligations and publication/transmission requirements. Plan for confidentiality carve-outs: publish redacted versions where allowed, but transmit full versions to authorities. - Module J: Six-month reporting cadence statement and calendar (Article 42(1)). - Module K: Moderation resources by Member State language - human resources, qualifications, training, support, and moderators with sufficient linguistic expertise. The implementing regulation uses CEFR and counts sufficient linguistic expertise from CEFR-B2 upward. - Module L: Accuracy/error indicators by language (Article 42(2)(c)). - Module M: AMAR by Member State (Article 42(3)). - Module N: Publication/transmission pack (Article 42(4)) - risk assessment report, mitigation measures, audit report, audit implementation report, and consultation information. ## Appendix - Metric dictionary (required for reproducibility) For each metric, include enough detail to reproduce it exactly for the same period. This appendix reduces enforcement risk and shortens audit cycles. - Metric name + DSA article mapping + definition. - Inclusions/exclusions and deduplication rules. - Source system(s), table names/fields (internal), and data owner. - Validation checks (range checks, reconciliation, anomaly detection). - Version history for metric definition changes. ## Appendix - QA checklist (run before publication) Run QA checks every reporting cycle and archive the results with the report. If you change counting rules, explain the change and provide comparability notes. - All required modules present for your tier and service types. - Median time calculations reproducible and well-defined. - Automation disclosures consistent with notifications sent to users/notifiers. - No prohibited personal data in public datasets/submissions. - Sign-off recorded (who approved publication and when). - Template completeness: do not omit mandatory template fields without an objective reason, because the published report can otherwise be treated as incomplete. ## Primary sources - [Regulation (EU) 2022/2065 (Digital Services Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/2065/oj?ref=sorena.io) - Primary reporting requirements in Articles 15, 24, and 42, plus the Article 24(5) statement-of-reasons database submission obligation. - [Commission Implementing Regulation (EU) 2024/2835 - Transparency reporting templates](https://eur-lex.europa.eu/eli/reg_impl/2024/2835/oj?ref=sorena.io) - Sets the Article 15, 24, and 42 reporting templates, publication-format rules, harmonized periods, retention period, and versioning expectations. ## Related Topic Guides - [DSA Ads & Recommender Systems | Article 26, 27, 38 & 39 Compliance](/artifacts/eu/digital-services-act/ads-and-recommender-systems.md): A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27). - [DSA Applicability Test | Is the EU Digital Services Act Applicable to You?](/artifacts/eu/digital-services-act/applicability-test.md): A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers. - [DSA Enforcement & Investigations | DSCs, Commission Powers, Audits & Procedures](/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations.md): A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services. - [DSA Notice & Action Workflow | Article 16 Requirements + Templates](/artifacts/eu/digital-services-act/notice-and-action-workflow.md): A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements. - [DSA Penalties & Fines | Digital Services Act Enforcement Exposure (6% / 1% / 5%)](/artifacts/eu/digital-services-act/penalties-and-fines.md): How DSA penalties work under Regulation (EU) 2022/2065. - [DSA Transparency Reporting | Articles 15, 24 & 42 Reporting Requirements](/artifacts/eu/digital-services-act/transparency-reporting.md): A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24. - [DSA vs DMA | Digital Services Act vs Digital Markets Act (What's the Difference?)](/artifacts/eu/digital-services-act/dsa-vs-dma.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA. - [DSA vs UK Online Safety Act | EU vs UK Online Safety Compliance](/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users). - [EU Digital Services Act (DSA) Requirements | Obligations by Service Type & Tier](/artifacts/eu/digital-services-act/requirements.md): A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms. - [EU DSA Checklist | Digital Services Act Compliance Checklist (Audit-Ready)](/artifacts/eu/digital-services-act/checklist.md): An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency. - [EU DSA Compliance Guide | Digital Services Act Implementation Playbook](/artifacts/eu/digital-services-act/compliance.md): A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering. - [EU DSA Deadlines & Compliance Calendar | Key Dates, Cadence and Milestones](/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar.md): A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24. - [EU DSA FAQ | Digital Services Act Questions & Answers (Practical)](/artifacts/eu/digital-services-act/faq.md): Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what "hosting" and "online platform" mean. - [EU DSA Service Types & Scope | Hosting vs Platform vs Marketplace](/artifacts/eu/digital-services-act/service-types-and-scope.md): How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting). - [VLOP/VLOSE Systemic Risk Assessment (DSA) | Articles 34-36 + Mitigation](/artifacts/eu/digital-services-act/risk-assessments-and-mitigation.md): A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-services-act/dsa-transparency-report-template --- --- title: "DSA vs DMA" canonical_url: "https://www.sorena.io/artifacts/eu/digital-services-act/dsa-vs-dma" source_url: "https://www.sorena.io/artifacts/eu/digital-services-act/dsa-vs-dma" author: "Sorena AI" description: "A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "DSA vs DMA" - "Digital Services Act vs Digital Markets Act" - "DSA compliance" - "DMA gatekeeper compliance" - "EU platform regulation" - "VLOP vs gatekeeper" - "EU digital regulation comparison" - "EU compliance" - "online platforms" - "gatekeepers" - "transparency" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DSA vs DMA A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA. *Comparison* *EU* ## EU Platform Regulation DSA vs DMA DSA is about online safety, transparency and systemic risk. DMA is about competition and gatekeepers. Use this page to align owners, controls and evidence across both programs. Teams often confuse the DSA and DMA because both target large platforms and both affect product design. They have different objectives and different "compliance objects": DSA regulates how intermediary services and platforms handle content, transparency and systemic risks; DMA regulates designated gatekeepers and how they behave in markets. This comparison focuses on what changes operationally for teams building controls and evidence. ## One-line difference (high-signal summary) DSA (Regulation (EU) 2022/2065): online safety and accountability - content moderation transparency, notice & action, user redress, advertising transparency, recommender transparency, and systemic risk programs for VLOPs/VLOSEs. DMA (Regulation (EU) 2022/1925): competition and contestability - obligations for designated gatekeepers to prevent unfair practices and ensure fair market access. - DSA asks: "How do you make the online environment safer and more transparent?" - DMA asks: "Are you a gatekeeper and do you abuse market power or restrict competition?" *Recommended next step* *Placement: after the comparison section* ## Use EU Platform Regulation DSA vs DMA as a cited research workflow Research Copilot can take EU Platform Regulation DSA vs DMA from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Platform Regulation can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Platform Regulation DSA vs DMA](/solutions/research-copilot.md): Start from EU Platform Regulation DSA vs DMA and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Platform Regulation](/contact.md): Review your current process, evidence gaps, and next steps for EU Platform Regulation DSA vs DMA. ## Who is in scope (DSA tiers vs DMA gatekeepers) DSA scope is layered by service type (intermediary/hosting/platform/marketplace/search) with an extra tier for VLOPs/VLOSEs based on AMAR thresholds and designation decisions. DMA scope is based on gatekeeper designation criteria and applies to core platform services. - DSA "large tier": VLOP/VLOSE designation (Article 33) and systemic risk obligations (Articles 34-39, 42). - DMA: gatekeeper designation and obligations tied to core platform services (e.g., app stores, search engines, social networks, advertising services). ## What the programs look like operationally (controls + artifacts) DSA compliance tends to be workflow- and reporting-heavy: you build notice intake, decision explainability, transparency reporting pipelines, and (for VLOPs) risk and audit cycles. DMA compliance tends to be product and business rule constraints: do/don't obligations, technical interfaces, and governance to prevent prohibited behaviors. - DSA artifacts: notice & action workflow spec, statement-of-reasons schema, transparency report templates, AMAR methodology memo, VLOP risk assessment and audit pack. - DMA artifacts: obligation mapping by core platform service, technical interface design decisions, monitoring and exception approvals, and evidence of non-discriminatory treatment. ## Overlap areas (where teams can share evidence and tooling) Some product surfaces are touched by both laws even though objectives differ. Sharing tooling can reduce compliance cost if you design for reuse. - Ads and transparency: DSA has explicit ad transparency duties; DMA can affect ad-tech behaviors and access/terms in gatekeeper ecosystems. - Ranking/recommenders: DSA requires transparency and user options; DMA can constrain self-preferencing and access conditions. - Governance and auditability: both benefit from structured decision logs, change management and an evidence pack. ## How to run both programs without duplicating work (recommended model) Treat DSA and DMA as two programs with shared governance and separate requirement matrices. Share the evidence platform: logging, change tracking, and reporting close procedures. - Create two matrices: DSA (workflow/reporting obligations) and DMA (behavioral/market obligations). - Use one governance layer: quarterly reviews, release gating for high-risk product changes, and a single evidence repository. - Keep separate owners: trust & safety (DSA) vs competition/commercial governance (DMA), with a shared platform engineering owner for tooling. ## Primary sources - [European Commission - The Digital Services Act (overview)](https://digital-strategy.ec.europa.eu/en/policies/digital-services-act?ref=sorena.io) - Commission overview notes that the DSA and DMA complement each other and covers service types regulated by the DSA. - [Regulation (EU) 2022/2065 (Digital Services Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/2065/oj?ref=sorena.io) - Primary DSA legal text for obligations and VLOP/VLOSE tier. - [Regulation (EU) 2022/1925 (Digital Markets Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/1925/oj?ref=sorena.io) - Primary DMA legal text for gatekeeper obligations. ## Related Topic Guides - [DSA Ads & Recommender Systems | Article 26, 27, 38 & 39 Compliance](/artifacts/eu/digital-services-act/ads-and-recommender-systems.md): A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27). - [DSA Applicability Test | Is the EU Digital Services Act Applicable to You?](/artifacts/eu/digital-services-act/applicability-test.md): A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers. - [DSA Enforcement & Investigations | DSCs, Commission Powers, Audits & Procedures](/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations.md): A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services. - [DSA Notice & Action Workflow | Article 16 Requirements + Templates](/artifacts/eu/digital-services-act/notice-and-action-workflow.md): A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements. - [DSA Penalties & Fines | Digital Services Act Enforcement Exposure (6% / 1% / 5%)](/artifacts/eu/digital-services-act/penalties-and-fines.md): How DSA penalties work under Regulation (EU) 2022/2065. - [DSA Transparency Report Template | Article 15 + Article 24 + VLOP Article 42](/artifacts/eu/digital-services-act/dsa-transparency-report-template.md): Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835. - [DSA Transparency Reporting | Articles 15, 24 & 42 Reporting Requirements](/artifacts/eu/digital-services-act/transparency-reporting.md): A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24. - [DSA vs UK Online Safety Act | EU vs UK Online Safety Compliance](/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users). - [EU Digital Services Act (DSA) Requirements | Obligations by Service Type & Tier](/artifacts/eu/digital-services-act/requirements.md): A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms. - [EU DSA Checklist | Digital Services Act Compliance Checklist (Audit-Ready)](/artifacts/eu/digital-services-act/checklist.md): An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency. - [EU DSA Compliance Guide | Digital Services Act Implementation Playbook](/artifacts/eu/digital-services-act/compliance.md): A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering. - [EU DSA Deadlines & Compliance Calendar | Key Dates, Cadence and Milestones](/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar.md): A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24. - [EU DSA FAQ | Digital Services Act Questions & Answers (Practical)](/artifacts/eu/digital-services-act/faq.md): Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what "hosting" and "online platform" mean. - [EU DSA Service Types & Scope | Hosting vs Platform vs Marketplace](/artifacts/eu/digital-services-act/service-types-and-scope.md): How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting). - [VLOP/VLOSE Systemic Risk Assessment (DSA) | Articles 34-36 + Mitigation](/artifacts/eu/digital-services-act/risk-assessments-and-mitigation.md): A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-services-act/dsa-vs-dma --- --- title: "DSA vs UK Online Safety Act" canonical_url: "https://www.sorena.io/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act" source_url: "https://www.sorena.io/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act" author: "Sorena AI" description: "A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "DSA vs UK Online Safety Act" - "EU online safety compliance" - "UK online safety compliance" - "DSA compliance" - "Ofcom online safety" - "Digital Services Act vs Online Safety Act" - "notice and action vs takedown process" - "EU vs UK" - "online safety" - "DSA" - "UK Online Safety Act" - "platform compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DSA vs UK Online Safety Act A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users). *Comparison* *EU/UK* ## Online Safety Compliance DSA vs UK Online Safety Act A practical comparison for teams operating in both the EU and the UK. Focus: what workflows you build, what evidence you keep, and how regulators supervise. If you operate platforms in both the EU and the UK, you need two compliance lenses: the DSA's layered obligations model for intermediary services and platforms in the EU, and the UK Online Safety Act's duties of care enforced by Ofcom. This page focuses on building shared workflows and a shared evidence platform while respecting differences in scope and regulator expectations. ## Scope: "where users are" and "what services are" The DSA applies to services offered to recipients in the Union and uses a layered service-type model (intermediary/hosting/platform/marketplace/search) with an extra tier for VLOPs/VLOSEs. The UK Online Safety Act is a UK regime aimed at online safety outcomes and is supervised by a single regulator (Ofcom) with risk-based expectations. - EU DSA: layered duties by service type and tier; strong transparency and explainability obligations (e.g., notice & action, statements of reasons, reporting). - UK OSA: risk-based compliance model; duties of care and regulator codes/guidance drive operational expectations for UK user safety. - Practical takeaway: design your compliance program around shared workflows (safety operations) and separate jurisdictional rule sets. ## Core workflows you can reuse across EU DSA and UK OSA Even when legal details differ, the operational building blocks for online safety are similar: intake, triage, action, explainability, appeals, monitoring, and reporting. Build these workflows once with jurisdictional "policy layers". - User reporting and notices: unified intake UX that captures required information; route to jurisdiction-specific triage rules. - Content actioning: consistent action taxonomy (remove, restrict, demote, account actions) with reason codes. - Explainability: structured decision logs (the DSA's statement-of-reasons model is a strong baseline). - Appeals and redress: internal complaint handling and dispute mechanisms, with jurisdiction-specific rules. - Risk management: periodic risk assessments and mitigations; keep evidence of effectiveness testing. ## Reporting and transparency (why DSA is "reporting-heavy") The DSA has explicit transparency reporting layers (Articles 15/24/42) and additional public transparency for VLOPs/VLOSEs (risk and audit publication, ad repository requirements). UK reporting expectations are risk-based and regulator-driven through codes and guidance, often emphasizing safety outcomes and operational effectiveness. - If you meet DSA tiers: build reporting pipelines as a data product with metric dictionaries and QA checks. - For UK: align reporting and evidence to Ofcom expectations and risk profiles (e.g., harm reduction, response effectiveness). - Shared approach: one evidence repository + two publication/filing "views". ## Regulators and enforcement: DSCs/Commission vs Ofcom In the EU, enforcement is split across national authorities (DSCs) and the Commission (for VLOPs/VLOSEs). In the UK, Ofcom is the central online safety regulator. - EU: expect cross-border coordination and tier-based supervision; VLOP/VLOSE enforcement can include Commission proceedings and audits. - UK: expect risk-based supervisory engagement and reliance on Ofcom codes and guidance. - Practical takeaway: maintain a regulator response playbook and evidence bundles ready for both. *Recommended next step* *Placement: after the comparison section* ## Use Online Safety Compliance DSA vs UK Online Safety Act as a cited research workflow Research Copilot can take Online Safety Compliance DSA vs UK Online Safety Act from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on Online Safety Compliance can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Online Safety Compliance DSA vs UK Online Safety Act](/solutions/research-copilot.md): Start from Online Safety Compliance DSA vs UK Online Safety Act and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Online Safety Compliance](/contact.md): Review your current process, evidence gaps, and next steps for Online Safety Compliance DSA vs UK Online Safety Act. ## Recommended operating model for dual compliance (EU + UK) The easiest way to reduce duplication is to build one "safety operating system" and map each obligation set to configuration and reporting layers. Use the DSA's structured artifacts (statement-of-reasons objects, reporting metrics) as a strong baseline. - One workflow engine: notices -> decisions -> reasons -> appeals -> metrics. - Two policy layers: EU DSA rulebook and UK OSA rulebook, with jurisdiction routing. - One evidence platform: logs, datasets, QA results, policy versions, and change history. - Quarterly governance: cross-jurisdiction review of incidents, risk assessments, and major product changes. ## Primary sources - [Regulation (EU) 2022/2065 (Digital Services Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/2065/oj?ref=sorena.io) - Primary DSA legal text for EU scope and layered obligations model. - [UK Online Safety Act - Legislation.gov.uk](https://www.legislation.gov.uk/ukpga/2023/50/contents?ref=sorena.io) - Primary UK Online Safety Act legal text (UK Parliament). ## Related Topic Guides - [DSA Ads & Recommender Systems | Article 26, 27, 38 & 39 Compliance](/artifacts/eu/digital-services-act/ads-and-recommender-systems.md): A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27). - [DSA Applicability Test | Is the EU Digital Services Act Applicable to You?](/artifacts/eu/digital-services-act/applicability-test.md): A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers. - [DSA Enforcement & Investigations | DSCs, Commission Powers, Audits & Procedures](/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations.md): A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services. - [DSA Notice & Action Workflow | Article 16 Requirements + Templates](/artifacts/eu/digital-services-act/notice-and-action-workflow.md): A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements. - [DSA Penalties & Fines | Digital Services Act Enforcement Exposure (6% / 1% / 5%)](/artifacts/eu/digital-services-act/penalties-and-fines.md): How DSA penalties work under Regulation (EU) 2022/2065. - [DSA Transparency Report Template | Article 15 + Article 24 + VLOP Article 42](/artifacts/eu/digital-services-act/dsa-transparency-report-template.md): Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835. - [DSA Transparency Reporting | Articles 15, 24 & 42 Reporting Requirements](/artifacts/eu/digital-services-act/transparency-reporting.md): A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24. - [DSA vs DMA | Digital Services Act vs Digital Markets Act (What's the Difference?)](/artifacts/eu/digital-services-act/dsa-vs-dma.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA. - [EU Digital Services Act (DSA) Requirements | Obligations by Service Type & Tier](/artifacts/eu/digital-services-act/requirements.md): A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms. - [EU DSA Checklist | Digital Services Act Compliance Checklist (Audit-Ready)](/artifacts/eu/digital-services-act/checklist.md): An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency. - [EU DSA Compliance Guide | Digital Services Act Implementation Playbook](/artifacts/eu/digital-services-act/compliance.md): A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering. - [EU DSA Deadlines & Compliance Calendar | Key Dates, Cadence and Milestones](/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar.md): A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24. - [EU DSA FAQ | Digital Services Act Questions & Answers (Practical)](/artifacts/eu/digital-services-act/faq.md): Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what "hosting" and "online platform" mean. - [EU DSA Service Types & Scope | Hosting vs Platform vs Marketplace](/artifacts/eu/digital-services-act/service-types-and-scope.md): How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting). - [VLOP/VLOSE Systemic Risk Assessment (DSA) | Articles 34-36 + Mitigation](/artifacts/eu/digital-services-act/risk-assessments-and-mitigation.md): A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act --- --- title: "DSA Enforcement & Investigations" canonical_url: "https://www.sorena.io/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations" source_url: "https://www.sorena.io/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations" author: "Sorena AI" description: "A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "DSA enforcement" - "Digital Services Coordinator enforcement" - "Commission DSA investigation" - "VLOP supervision" - "DSA formal proceedings 2023/1201" - "DSA independent audit 2024/436" - "DSA compliance investigation" - "DSA evidence pack" - "Digital Services Coordinator" - "Commission investigations" - "VLOP/VLOSE supervision" - "independent audit" - "formal proceedings" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DSA Enforcement & Investigations A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services. *Enforcement Guide* *EU* ## EU Digital Services Act (DSA) Enforcement & Investigations How the DSA is supervised and enforced - and how to be ready when questions arrive. Covers DSCs, Commission powers for VLOPs/VLOSEs, formal proceedings, audits, and evidence. The DSA's enforcement model is split: national authorities (Digital Services Coordinators and other competent authorities) supervise and enforce many obligations, while the Commission has supervisory and enforcement powers over designated VLOPs and VLOSEs. The best enforcement risk reduction strategy is not "better legal arguments" - it's a compliance system that produces evidence quickly: scope memo, decision logs, reporting datasets, and audit-ready controls. ## DSA enforcement model (two-track supervision) The DSA combines national supervision (DSCs and competent authorities) with direct Commission enforcement for VLOPs/VLOSEs. Your enforcement exposure depends on your tier and where you are established/offering services. - National layer: DSCs coordinate supervision and handle complaints; Member States set penalties and procedural rules within the DSA framework. - Commission layer: for designated VLOPs/VLOSEs, the Commission can run investigations and adopt non-compliance decisions and fines. - Practical takeaway: build evidence and reporting discipline for both tracks (DSC interactions and Commission investigations). *Recommended next step* *Placement: after the enforcement section* ## Use EU Digital Services Act (DSA) Enforcement & Investigations as a cited research workflow Research Copilot can take EU Digital Services Act (DSA) Enforcement & Investigations from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Digital Services Act (DSA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Digital Services Act (DSA) Enforcement & Investigations](/solutions/research-copilot.md): Start from EU Digital Services Act (DSA) Enforcement & Investigations and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Digital Services Act (DSA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Services Act (DSA) Enforcement & Investigations. ## Digital Services Coordinators (DSCs): what to expect operationally DSCs are the primary national contact and coordination point. They can receive complaints, coordinate cross-border actions, and request information through national procedures. Most companies experience DSC enforcement as information requests and follow-up questions on published transparency, moderation practices, and marketplace controls. - Have an external point of contact ready (Article 12) and, where applicable, a legal representative (Article 13). - Maintain a scope memo and requirements matrix that you can share (sanitized) to explain your approach. - Keep artifacts ready: transparency reports, notice & action metrics, statements-of-reasons samples, and marketplace onboarding controls. ## Commission supervision for VLOPs/VLOSEs (designation changes everything) Once designated as a VLOP/VLOSE, the Commission has a dedicated enforcement role including formal proceedings, interim measures and fines (in line with the DSA's procedural framework). Designation is tied to AMAR thresholds and a Commission decision (Article 33). - Designation trigger: AMAR in the Union >= 45 million + Commission decision (Article 33). - Obligations apply from four months after notification of the designation decision (Article 33(6)). - Build a VLOP readiness pack early: systemic risk assessment (Article 34), mitigation (Article 35), audit (Article 37), enhanced transparency (Article 42). ## Formal proceedings and investigation mechanics (Implementing Regulation (EU) 2023/1201) The DSA is supported by implementing rules that set out practical procedures for Commission proceedings (including inspections, monitoring and hearings). Even if you are not a VLOP/VLOSE today, understanding these mechanics helps you design a compliance system that can respond quickly. - Build an investigation response playbook: who responds, how data is extracted, who signs off, and how confidentiality is handled. - Keep data request readiness: metric dictionaries, dataset snapshots, and reproducible queries for transparency metrics and moderation workflows. - Maintain a single source of truth for policy versions and product changes affecting risk and moderation behavior. - Formal proceedings are not theoretical. The Commission used the DSA framework to open proceedings against TikTok on 17 December 2024 over suspected failures to assess and mitigate election-integrity risks linked to recommender systems and political advertising. ## Independent audits and how they show up in enforcement (Article 37 + Delegated Regulation (EU) 2024/436) For VLOPs/VLOSEs, independent audits are a recurring compliance mechanism, and audit outputs are part of transparency and accountability. The DSA also has delegated rules on audit performance, methodologies and templates. - Audit cycle: annual audit of compliance and (where applicable) code-of-conduct commitments; remediate and produce audit implementation report when findings are not fully positive. - Publication/transmission: audit report and audit implementation report are included in the Article 42 publication/transmission pack. - Evidence: audit readiness depends on your ability to produce control evidence (logs, policies, workflows) and show effectiveness of mitigation measures. ## Current enforcement signal: the TikTok election-risk proceedings The Commission opened formal proceedings against TikTok in December 2024 over suspected DSA failures linked to election integrity in Romania. The case focused on recommender-system risks and political advertising or paid political content. For compliance teams, the lesson is that Article 34 and 35 risk programs are not abstract governance exercises. The Commission expects evidence tied to concrete regional, linguistic, and product-system risks. - Date opened: 17 December 2024. - Focus areas identified by the Commission: recommender systems, coordinated manipulation risk, and policies on political advertising and paid political content. - Operational takeaway: keep risk-assessment files, mitigation decisions, product-change logs, and election-event escalation records organized by reporting period. ## What regulators ask first (and how to answer with evidence) Regulators and auditors often start with a small set of high-leverage questions that reveal whether your compliance system is real. Prepare evidence bundles for each question category. - Scope: which services are in scope and why; where do obligations attach per service? - Workflow: how do you process notices (Article 16) and issue statements of reasons (Article 17)? What are your SLAs and QA checks? - Reporting: how do you produce Article 15/24/42 transparency outputs? Can you reproduce metrics exactly? - Tier readiness: how do you monitor AMAR and plan for VLOP/VLOSE designation and systemic-risk obligations? - Governance: who owns each workstream and how do you handle change management and incidents? ## Enforcement risk reduction checklist (practical controls) Most enforcement risk is operational: inconsistent workflows, missing evidence, or inability to reproduce reporting. Use this checklist to reduce exposure before you receive formal questions. - Implement structured statement-of-reasons objects and store them with audit logs (supports Article 24(5) database submissions). - Build transparency reporting as a pipeline with QA and sign-off; archive datasets used for each publication period. - Maintain a VLOP readiness calendar even if you are below threshold: it reduces scramble risk. - Run annual enforcement tabletop exercises: simulate regulator questions and measure time-to-evidence. - Ensure privacy discipline: remove prohibited personal data from public submissions and publications where required. - Request-for-information readiness: keep designated owners, preservation steps, and response-review rules for Commission RFIs and inspection support, because incomplete or misleading responses can themselves trigger fines. ## Primary sources - [European Commission - The enforcement framework under the Digital Services Act](https://digital-strategy.ec.europa.eu/en/policies/dsa-enforcement?ref=sorena.io) - Commission overview of DSA enforcement and supervision, including VLOP/VLOSE supervision and investigations. - [Regulation (EU) 2022/2065 (Digital Services Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/2065/oj?ref=sorena.io) - Primary legal basis for supervision and enforcement; includes Commission fines for VLOPs/VLOSEs (Article 74) and Member State penalties (Article 52). - [Commission Implementing Regulation (EU) 2023/1201 - Proceedings rules (DSA)](https://eur-lex.europa.eu/eli/reg_impl/2023/1201/oj?ref=sorena.io) - Implementing rules on proceedings for Commission supervision and enforcement, including procedural elements used in investigations. - [Commission Delegated Regulation (EU) 2024/436 - Independent audit rules (DSA)](https://eur-lex.europa.eu/eli/reg_del/2024/436/oj?ref=sorena.io) - Delegated rules on independent audit methodologies and templates supporting Article 37 audits. - [European Commission - Formal proceedings against TikTok on election risks under the DSA](https://digital-strategy.ec.europa.eu/en/news/commission-opens-formal-proceedings-against-tiktok-election-risks-under-digital-services-act?ref=sorena.io) - Current example of the Commission using the DSA proceedings framework to investigate systemic-risk mitigation and election-integrity controls. ## Related Topic Guides - [DSA Ads & Recommender Systems | Article 26, 27, 38 & 39 Compliance](/artifacts/eu/digital-services-act/ads-and-recommender-systems.md): A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27). - [DSA Applicability Test | Is the EU Digital Services Act Applicable to You?](/artifacts/eu/digital-services-act/applicability-test.md): A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers. - [DSA Notice & Action Workflow | Article 16 Requirements + Templates](/artifacts/eu/digital-services-act/notice-and-action-workflow.md): A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements. - [DSA Penalties & Fines | Digital Services Act Enforcement Exposure (6% / 1% / 5%)](/artifacts/eu/digital-services-act/penalties-and-fines.md): How DSA penalties work under Regulation (EU) 2022/2065. - [DSA Transparency Report Template | Article 15 + Article 24 + VLOP Article 42](/artifacts/eu/digital-services-act/dsa-transparency-report-template.md): Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835. - [DSA Transparency Reporting | Articles 15, 24 & 42 Reporting Requirements](/artifacts/eu/digital-services-act/transparency-reporting.md): A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24. - [DSA vs DMA | Digital Services Act vs Digital Markets Act (What's the Difference?)](/artifacts/eu/digital-services-act/dsa-vs-dma.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA. - [DSA vs UK Online Safety Act | EU vs UK Online Safety Compliance](/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users). - [EU Digital Services Act (DSA) Requirements | Obligations by Service Type & Tier](/artifacts/eu/digital-services-act/requirements.md): A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms. - [EU DSA Checklist | Digital Services Act Compliance Checklist (Audit-Ready)](/artifacts/eu/digital-services-act/checklist.md): An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency. - [EU DSA Compliance Guide | Digital Services Act Implementation Playbook](/artifacts/eu/digital-services-act/compliance.md): A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering. - [EU DSA Deadlines & Compliance Calendar | Key Dates, Cadence and Milestones](/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar.md): A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24. - [EU DSA FAQ | Digital Services Act Questions & Answers (Practical)](/artifacts/eu/digital-services-act/faq.md): Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what "hosting" and "online platform" mean. - [EU DSA Service Types & Scope | Hosting vs Platform vs Marketplace](/artifacts/eu/digital-services-act/service-types-and-scope.md): How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting). - [VLOP/VLOSE Systemic Risk Assessment (DSA) | Articles 34-36 + Mitigation](/artifacts/eu/digital-services-act/risk-assessments-and-mitigation.md): A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations --- --- title: "EU DSA FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/digital-services-act/faq" source_url: "https://www.sorena.io/artifacts/eu/digital-services-act/faq" author: "Sorena AI" description: "Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what \"hosting\" and \"online platform\" mean." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU DSA FAQ" - "Digital Services Act FAQ" - "DSA questions and answers" - "DSA notice and action" - "DSA statement of reasons" - "DSA transparency reporting" - "AMAR DSA" - "VLOP designation" - "DSA penalties" - "DSA FAQ" - "Digital Services Act explained" - "notice and action" - "transparency reporting" - "VLOP/VLOSE" - "marketplace obligations" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DSA FAQ Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what "hosting" and "online platform" mean. *FAQ* *EU* ## EU Digital Services Act (DSA) FAQ Practical answers to the most common DSA compliance questions. Written for implementation teams: product, trust & safety, legal, security and data. This FAQ answers the questions teams ask when they turn DSA obligations into product controls and operating workflows. For deeper implementation guidance, use the linked topic guides (notice & action, transparency reporting, ads/recommenders, systemic risk, marketplace controls). ## Is the DSA applicable to non-EU companies? Yes - the DSA applies to services offered to recipients in the Union, including by providers not established in the EU. If you offer services in the EU but are not established there, you may need to designate a legal representative in the Union (Article 13). - Start with the applicability test and scope memo per service. - Implement a recipient point of contact (Article 12) and ensure terms transparency (Article 14). ## What's the difference between an intermediary service, hosting service, and online platform? The DSA is layered: you inherit more obligations as you move from intermediary -> hosting -> online platform. In practice, hosting is triggered when you store user-provided information at their request; online platform status is often associated with dissemination to the public (or to other recipients). - Use the service types and scope guide to classify each product surface you operate. - Treat classification as a living artifact; update it when features change. ## What does the DSA require for notice & action? Hosting services must provide electronic, user-friendly notice mechanisms (Article 16) that capture required elements and allow sufficiently precise, substantiated notices. Notifiers must receive confirmations and decision notifications (where contact info is available), and processing must be timely and objective. - A compliant notice form collects: reasons, exact location (URLs), notifier identity (with narrow exceptions), and good-faith statement (Article 16(2)). - If you use automation, you must disclose it in notifications (Article 16(6)). - Use the notice & action workflow guide for a full implementation blueprint. ## What is a "statement of reasons" and when do we have to provide it? If you impose restrictions because content is illegal or incompatible with your terms, hosting services must provide affected recipients a clear and specific statement of reasons (Article 17). It must include key details: what happened, why, whether automation was used, and how to seek redress. - Make statements of reasons structured objects (not free text) so they can feed reporting and audits. - Online platforms also have duties to submit statements of reasons for inclusion in a Commission database (Article 24(5)), ensuring no personal data is included. ## What is AMAR and why does it matter? AMAR is the number of average monthly active recipients of the service in the Union, published as an average over the past six months (Article 24(2)). It matters because VLOP/VLOSE designation thresholds are tied to AMAR and a Commission designation decision (Article 33). - Publish AMAR at least every six months (Article 24(2)) and keep methodology defensible. - Monitor AMAR as a tier risk indicator; build VLOP readiness early if you approach the threshold. ## What changes when we're designated as a VLOP/VLOSE? Designation triggers systemic-risk obligations: annual risk assessments (Article 34), risk mitigation (Article 35), independent audits (Article 37), and enhanced transparency reporting (Article 42). You may also need additional controls for recommender systems and advertising transparency (Articles 38-39). - Plan an annual risk/audit calendar and build an evidence model that supports publication/transmission duties. - Use the systemic risk and mitigation guide to design Article 34/35 programs. ## What changed for DSA transparency reporting in 2025 and 2026? The major change is Commission Implementing Regulation (EU) 2024/2835, which standardizes the reporting templates, reporting periods, publication timing, and versioning rules for Articles 15, 24, and 42 reports. That means teams now need a structured reporting pipeline, not just a narrative moderation report. - The first annual baseline report had to be published by 16 February 2025. - The second reporting cycle starts no later than 17 February 2025 and runs until 31 December 2025. - From 1 January 2026, providers follow the harmonized reporting periods in the implementing regulation. - Each transparency report is due no later than 2 months after the end of the reporting period. - Reports and corrected versions must stay publicly available for at least 5 years. ## Do we need to change our ads and recommender systems? If you present ads, Article 26 requires per-ad disclosures (ad labeling, beneficiary/payer, and targeting parameters). If you use recommender systems, Article 27 requires transparency on main parameters and user options; VLOPs/VLOSEs must also offer at least one non-profiling option per recommender system (Article 38) and may need a public ad repository with APIs (Article 39). - Treat these as product requirements with UX acceptance criteria and logging evidence. - Use the ads and recommender systems guide for implementation patterns. ## What are the penalty ceilings under the DSA? Member States must set penalties that are effective, proportionate and dissuasive, with maximum fine ceilings under Article 52. The Commission can impose fines on VLOPs/VLOSEs under Article 74 as part of its enforcement track. - Member State maximum fine for failure to comply with an obligation: up to 6% of annual worldwide turnover (Article 52(3)). - Member State maximum fine for certain information/inspection failures: up to 1% (Article 52(3)); periodic penalty payments up to 5% of average daily worldwide turnover per day (Article 52(4)). - Commission fines for VLOPs/VLOSEs: up to 6% (and up to 1% for certain procedural infringements) under Article 74. ## Where do we start (fastest path to real compliance)? Start with the controls that unlock multiple obligations: notice & action + statement of reasons + transparency reporting pipeline. Then add marketplace and VLOP layers as applicable. - Run the DSA applicability test and produce a scope memo per service. - Implement notice & action (Article 16) and structured statements of reasons (Article 17). - Build Article 15/24 reporting pipeline and a report template. - If near VLOP thresholds: build systemic risk and audit calendar early. *Recommended next step* *Placement: after the FAQ section* ## Use EU Digital Services Act (DSA) FAQ as a cited research workflow Research Copilot can take EU Digital Services Act (DSA) FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU Digital Services Act (DSA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Digital Services Act (DSA) FAQ](/solutions/research-copilot.md): Start from EU Digital Services Act (DSA) FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Digital Services Act (DSA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Services Act (DSA) FAQ. ## Primary sources - [European Commission - Digital Services Act Q&A](https://digital-strategy.ec.europa.eu/en/faqs/digital-services-act-questions-and-answers?ref=sorena.io) - Commission Q&A on practical DSA compliance topics. - [Regulation (EU) 2022/2065 (Digital Services Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/2065/oj?ref=sorena.io) - Primary legal text for referenced DSA obligations and penalties. - [Commission Implementing Regulation (EU) 2024/2835 - Transparency reporting templates](https://eur-lex.europa.eu/eli/reg_impl/2024/2835/oj?ref=sorena.io) - Explains the current reporting-template rules, harmonized periods, publication deadlines, and retention requirements for DSA transparency reports. ## Related Topic Guides - [DSA Ads & Recommender Systems | Article 26, 27, 38 & 39 Compliance](/artifacts/eu/digital-services-act/ads-and-recommender-systems.md): A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27). - [DSA Applicability Test | Is the EU Digital Services Act Applicable to You?](/artifacts/eu/digital-services-act/applicability-test.md): A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers. - [DSA Enforcement & Investigations | DSCs, Commission Powers, Audits & Procedures](/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations.md): A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services. - [DSA Notice & Action Workflow | Article 16 Requirements + Templates](/artifacts/eu/digital-services-act/notice-and-action-workflow.md): A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements. - [DSA Penalties & Fines | Digital Services Act Enforcement Exposure (6% / 1% / 5%)](/artifacts/eu/digital-services-act/penalties-and-fines.md): How DSA penalties work under Regulation (EU) 2022/2065. - [DSA Transparency Report Template | Article 15 + Article 24 + VLOP Article 42](/artifacts/eu/digital-services-act/dsa-transparency-report-template.md): Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835. - [DSA Transparency Reporting | Articles 15, 24 & 42 Reporting Requirements](/artifacts/eu/digital-services-act/transparency-reporting.md): A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24. - [DSA vs DMA | Digital Services Act vs Digital Markets Act (What's the Difference?)](/artifacts/eu/digital-services-act/dsa-vs-dma.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA. - [DSA vs UK Online Safety Act | EU vs UK Online Safety Compliance](/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users). - [EU Digital Services Act (DSA) Requirements | Obligations by Service Type & Tier](/artifacts/eu/digital-services-act/requirements.md): A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms. - [EU DSA Checklist | Digital Services Act Compliance Checklist (Audit-Ready)](/artifacts/eu/digital-services-act/checklist.md): An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency. - [EU DSA Compliance Guide | Digital Services Act Implementation Playbook](/artifacts/eu/digital-services-act/compliance.md): A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering. - [EU DSA Deadlines & Compliance Calendar | Key Dates, Cadence and Milestones](/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar.md): A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24. - [EU DSA Service Types & Scope | Hosting vs Platform vs Marketplace](/artifacts/eu/digital-services-act/service-types-and-scope.md): How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting). - [VLOP/VLOSE Systemic Risk Assessment (DSA) | Articles 34-36 + Mitigation](/artifacts/eu/digital-services-act/risk-assessments-and-mitigation.md): A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-services-act/faq --- --- title: "DSA Notice & Action Workflow" canonical_url: "https://www.sorena.io/artifacts/eu/digital-services-act/notice-and-action-workflow" source_url: "https://www.sorena.io/artifacts/eu/digital-services-act/notice-and-action-workflow" author: "Sorena AI" description: "A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "DSA notice and action" - "Article 16 notice and action" - "EU Digital Services Act notice handling" - "illegal content notice form" - "content moderation workflow" - "statement of reasons Article 17" - "DSA hosting service compliance" - "notice and action" - "Article 16" - "hosting services" - "illegal content" - "statement of reasons" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DSA Notice & Action Workflow A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements. *Workflow Guide* *EU* ## EU Digital Services Act (DSA) Notice & Action Workflow How to implement Article 16 notice & action in a way that is fast, fair, and auditable. Includes intake design, triage patterns, notification templates, and evidence logging expectations. For hosting services, DSA notice & action is the core compliance workflow. Article 16 requires easy, electronic notice submission mechanisms, specific notice elements, and timely, diligent, objective processing (with automation disclosures). This guide turns Article 16 into an implementation blueprint you can build and operate at scale. ## What Article 16 requires (minimum viable compliant workflow) Article 16 requires hosting services to provide a mechanism for any individual or entity to notify specific items of information they consider to be illegal content. The mechanism must be easy to access, user-friendly, and allow notices exclusively by electronic means. - Provide electronic notice submission (Article 16(1)) with a clear UI entry point. - Facilitate sufficiently precise and adequately substantiated notices by collecting required elements (Article 16(2)). - Confirm receipt (where contact info is provided) and notify decisions with redress information (Article 16(4)-(5)). - Process notices in a timely, diligent, non-arbitrary and objective manner; disclose automation use in the notification (Article 16(6)). ## Designing the notice form (Article 16(2) required elements) Your notice form should be "structured enough to be actionable" and "simple enough to be used". Article 16(2) specifies the minimum elements your mechanism must enable and facilitate. - Reasoned allegation: a sufficiently substantiated explanation of why the content is illegal. - Exact location: clear indication of electronic location (exact URL(s)); add fields for identifiers when URLs are not sufficient (e.g., post ID, listing ID). - Notifier identity: name and email address, with the narrow exception for certain child sexual abuse offences referenced by the DSA. - Good-faith statement: confirmation that allegations are accurate and complete to the best of the notifier's belief. - UX tip: include examples of "good notices" and validation errors to increase notice quality and reduce triage load. ## Triage and decisioning (timeliness + non-arbitrariness as controls) Article 16(6) sets the standard: timely, diligent, non-arbitrary, objective processing and decision-making. To meet that standard at scale, build triage as a control system with measurable outcomes. - Queueing: prioritize by severity, risk to life/safety, virality, and repeat patterns; document your prioritization policy. - Consistency checks: create decision guidelines and sampling reviews to detect drift between moderators/teams. - SLA metrics: time-to-receipt-confirmation, time-to-first-action, time-to-decision notification; segment by content type and market. - Training + support: ensure moderators understand legal vs terms grounds; track and reduce error drivers. ## Automation disclosures (when you use automated means) If you use automated means for processing or decision-making, Article 16 requires you to include information on such use in the decision notification. Treat automation disclosure as structured metadata, not vague language. - Record: whether automation was used in triage, detection, decision recommendation, or final decision. - Explain: which stage used automation and what the purpose was (e.g., spam filtering, similarity matching). - Safeguards: document human review triggers, overrides, and sampling QA; include these concepts in your transparency reporting metrics. ## Notifications to the notifier (receipt + decision) (Article 16(4)-(5)) If the notice includes electronic contact information, you must confirm receipt without undue delay and later notify your decision with redress information. These messages are part of your compliance evidence. - Receipt confirmation: include notice ID, timestamp, and a link to view status (without exposing personal data). - Decision notification: include outcome, action taken (if any), and how to appeal or seek redress. - Avoid over-disclosure: protect confidential information and personal data while still being clear and useful. ## Pairing notice & action with statement of reasons (Article 17) Notice handling often results in restrictions: removal, demotion, disabling access, account actions, or payment restrictions. Article 17 requires a clear and specific statement of reasons to affected recipients for those restrictions. - Create a shared decision object: notice -> assessment -> decision -> statement of reasons -> redress. - Include grounds: legal ground (illegal content) or contractual ground (terms) and explain why it applies. - Include facts and context: whether the decision followed an Article 16 notice or own-initiative investigation; disclose automation use. - Include redress options: internal complaints, out-of-court settlement and judicial redress where applicable. ## Criminal offence suspicions (Article 18) - escalation path If you become aware of information giving rise to a suspicion of certain serious criminal offences involving threats to life or safety, Article 18 requires prompt notification to law enforcement/judicial authorities. This requires a clear escalation and evidence handling path. - Define escalation triggers and who can invoke them (trust & safety, legal, security). - Record: what information created the suspicion, when it was discovered, and what was transmitted. - Privacy/security: maintain strict access control and logging for escalated cases. ## Evidence pack (what to retain for audits and enforcement) The fastest way to reduce enforcement risk is to be able to prove your workflow works and is applied consistently. Treat logs and templates as compliance artifacts. - Notice intake schema and validation rules (including Article 16(2) element capture). - Workflow logs: timestamps, queue states, reviewer assignments, decision outcomes, automation use flags. - Notification templates and samples; change history for templates. - Moderator guidance materials and QA sampling results. - Metrics used for transparency reporting (Article 15) and the definitions behind them. *Recommended next step* *Placement: near the end of the main content before related guides* ## Turn EU Digital Services Act (DSA) Notice & Action Workflow into an operational assessment Assessment Autopilot can take EU Digital Services Act (DSA) Notice & Action Workflow from turning this guidance into an operational assessment workflow to a reusable workflow inside Sorena. Teams working on EU Digital Services Act (DSA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Digital Services Act (DSA) Notice & Action Workflow](/solutions/assessment.md): Start from EU Digital Services Act (DSA) Notice & Action Workflow and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Digital Services Act (DSA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Services Act (DSA) Notice & Action Workflow. ## Primary sources - [Regulation (EU) 2022/2065 (Digital Services Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/2065/oj?ref=sorena.io) - Primary DSA workflow requirements for hosting services (Articles 16-18) and statement-of-reasons obligations (Article 17). ## Related Topic Guides - [DSA Ads & Recommender Systems | Article 26, 27, 38 & 39 Compliance](/artifacts/eu/digital-services-act/ads-and-recommender-systems.md): A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27). - [DSA Applicability Test | Is the EU Digital Services Act Applicable to You?](/artifacts/eu/digital-services-act/applicability-test.md): A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers. - [DSA Enforcement & Investigations | DSCs, Commission Powers, Audits & Procedures](/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations.md): A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services. - [DSA Penalties & Fines | Digital Services Act Enforcement Exposure (6% / 1% / 5%)](/artifacts/eu/digital-services-act/penalties-and-fines.md): How DSA penalties work under Regulation (EU) 2022/2065. - [DSA Transparency Report Template | Article 15 + Article 24 + VLOP Article 42](/artifacts/eu/digital-services-act/dsa-transparency-report-template.md): Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835. - [DSA Transparency Reporting | Articles 15, 24 & 42 Reporting Requirements](/artifacts/eu/digital-services-act/transparency-reporting.md): A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24. - [DSA vs DMA | Digital Services Act vs Digital Markets Act (What's the Difference?)](/artifacts/eu/digital-services-act/dsa-vs-dma.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA. - [DSA vs UK Online Safety Act | EU vs UK Online Safety Compliance](/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users). - [EU Digital Services Act (DSA) Requirements | Obligations by Service Type & Tier](/artifacts/eu/digital-services-act/requirements.md): A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms. - [EU DSA Checklist | Digital Services Act Compliance Checklist (Audit-Ready)](/artifacts/eu/digital-services-act/checklist.md): An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency. - [EU DSA Compliance Guide | Digital Services Act Implementation Playbook](/artifacts/eu/digital-services-act/compliance.md): A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering. - [EU DSA Deadlines & Compliance Calendar | Key Dates, Cadence and Milestones](/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar.md): A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24. - [EU DSA FAQ | Digital Services Act Questions & Answers (Practical)](/artifacts/eu/digital-services-act/faq.md): Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what "hosting" and "online platform" mean. - [EU DSA Service Types & Scope | Hosting vs Platform vs Marketplace](/artifacts/eu/digital-services-act/service-types-and-scope.md): How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting). - [VLOP/VLOSE Systemic Risk Assessment (DSA) | Articles 34-36 + Mitigation](/artifacts/eu/digital-services-act/risk-assessments-and-mitigation.md): A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-services-act/notice-and-action-workflow --- --- title: "DSA Penalties & Fines" canonical_url: "https://www.sorena.io/artifacts/eu/digital-services-act/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/digital-services-act/penalties-and-fines" author: "Sorena AI" description: "How DSA penalties work under Regulation (EU) 2022/2065." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "DSA fines" - "DSA penalties" - "Article 52 penalties" - "6% turnover fine DSA" - "1% fine DSA" - "5% daily penalty DSA" - "Commission fines Article 74" - "VLOP penalties" - "Digital Services Act enforcement penalties" - "Article 52" - "Article 74" - "6% turnover fine" - "periodic penalty payments" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DSA Penalties & Fines How DSA penalties work under Regulation (EU) 2022/2065. *Enforcement Guide* *EU* ## EU Digital Services Act (DSA) Penalties & Fines What DSA penalties look like in practice - and what evidence reduces exposure. Covers Member State penalties (Article 52) and Commission fines for VLOPs/VLOSEs (Article 74). DSA penalties are structured as a deterrence model: Member States must set effective, proportionate and dissuasive penalties for infringements within their competence (Article 52), and the Commission can impose fines on VLOPs/VLOSEs under its supervision (Article 74). This page explains the penalty ceilings and the practical controls that reduce enforcement exposure. ## Member State penalties (Article 52): the baseline penalty framework Article 52 requires Member States to lay down penalty rules and ensure they are implemented. The DSA sets maximum ceilings for certain penalty categories. - Penalty standard: penalties must be effective, proportionate and dissuasive; Member States notify the Commission of rules and amendments (Article 52(1)-(2)). - Max fine for failure to comply with an obligation under the DSA: up to 6% of annual worldwide turnover of the provider in the preceding financial year (Article 52(3)). - Max fine for incorrect/incomplete/misleading information, failure to reply/rectify, and failure to submit to an inspection: up to 1% of annual income or worldwide turnover (Article 52(3)). - Periodic penalty payments: maximum up to 5% of average daily worldwide turnover or income per day (Article 52(4)). *Recommended next step* *Placement: after the enforcement section* ## Use EU Digital Services Act (DSA) Penalties & Fines as a cited research workflow Research Copilot can take EU Digital Services Act (DSA) Penalties & Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Digital Services Act (DSA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Digital Services Act (DSA) Penalties & Fines](/solutions/research-copilot.md): Start from EU Digital Services Act (DSA) Penalties & Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Digital Services Act (DSA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Services Act (DSA) Penalties & Fines. ## Commission fines for VLOPs/VLOSEs (Article 74): additional exposure after designation For designated very large online platforms and very large online search engines, the DSA provides a Commission fining regime tied to non-compliance decisions and procedural infringements. This exposure is separate from, and in addition to, Member State penalties depending on the enforcement track. - Non-compliance fines: up to 6% of total worldwide annual turnover in the preceding financial year for relevant infringements and failures to comply with certain Commission decisions (Article 74(1)). - Procedural fines: up to 1% of total annual income or worldwide turnover for supplying incorrect/misleading information, failure to reply, failure to rectify, refusing inspections, and related procedural breaches (Article 74(2)). - Penalty sizing factors: nature, gravity, duration and recurrence (Article 74(4)). - Procedural exposure matters in practice: incorrect, incomplete, or misleading answers to Commission requests for information or inspection questions can independently support fines under Article 74(2). ## What triggers penalties in practice (operational root causes) Penalties are often the endpoint of operational failures: missing workflows, inconsistent enforcement, broken reporting, or inability to respond to information requests. The best mitigation is a compliance system that can prove it is working. - Missing or non-functional notice & action (Article 16) and statement-of-reasons workflows (Article 17). - Transparency reporting failures or inability to reproduce metrics (Articles 15/24/42). - AMAR publication failures (Article 24(2)) or inability to substantiate AMAR on request (Article 24(3)). - Marketplace onboarding gaps: incomplete trader traceability and failure to suspend non-compliant traders (Article 30). - VLOP systemic-risk program failures: missing risk assessment, mitigation, audit and publication packs (Articles 34-37, 42). - Broken investigation response processes: no preserved data extract, no review of RFI answers, or no correction path for incomplete inspection answers. ## Penalty risk reduction: controls that matter most To reduce penalty exposure, focus on controls that reduce harm and increase explainability and reproducibility. These controls also make audits cheaper and faster. - Structured decision logs: a statement-of-reasons object for each restriction (Article 17) with grounds, facts, automation use and redress links. - Transparency pipeline: metric dictionary + reproducible datasets + QA checks + sign-off for each reporting period. - Governance: clear owners for moderation ops, reporting, ads/recommenders, marketplace onboarding, and VLOP risk/audit workstreams. - Incident readiness: broken workflows and data quality regressions should be treated as compliance incidents with severity and timelines. - Evidence retention: archive policies, templates, logs, and published reports for fast regulatory responses. - Response governance: keep a written regulator-response playbook for RFIs, inspections, and corrections under the Commission proceedings rules. ## Primary sources - [Regulation (EU) 2022/2065 (Digital Services Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/2065/oj?ref=sorena.io) - Member State penalties and ceilings (Article 52) and Commission fines for VLOPs/VLOSEs (Article 74). - [European Commission - The enforcement framework under the Digital Services Act](https://digital-strategy.ec.europa.eu/en/policies/dsa-enforcement?ref=sorena.io) - Commission overview of enforcement mechanisms and supervision expectations. - [Commission Implementing Regulation (EU) 2023/1201 - Proceedings rules under the DSA](https://eur-lex.europa.eu/eli/reg_impl/2023/1201/oj?ref=sorena.io) - Shows how Commission proceedings, inspections, and correction opportunities work in practice, which is relevant to Article 74 procedural fine exposure. ## Related Topic Guides - [DSA Ads & Recommender Systems | Article 26, 27, 38 & 39 Compliance](/artifacts/eu/digital-services-act/ads-and-recommender-systems.md): A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27). - [DSA Applicability Test | Is the EU Digital Services Act Applicable to You?](/artifacts/eu/digital-services-act/applicability-test.md): A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers. - [DSA Enforcement & Investigations | DSCs, Commission Powers, Audits & Procedures](/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations.md): A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services. - [DSA Notice & Action Workflow | Article 16 Requirements + Templates](/artifacts/eu/digital-services-act/notice-and-action-workflow.md): A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements. - [DSA Transparency Report Template | Article 15 + Article 24 + VLOP Article 42](/artifacts/eu/digital-services-act/dsa-transparency-report-template.md): Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835. - [DSA Transparency Reporting | Articles 15, 24 & 42 Reporting Requirements](/artifacts/eu/digital-services-act/transparency-reporting.md): A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24. - [DSA vs DMA | Digital Services Act vs Digital Markets Act (What's the Difference?)](/artifacts/eu/digital-services-act/dsa-vs-dma.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA. - [DSA vs UK Online Safety Act | EU vs UK Online Safety Compliance](/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users). - [EU Digital Services Act (DSA) Requirements | Obligations by Service Type & Tier](/artifacts/eu/digital-services-act/requirements.md): A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms. - [EU DSA Checklist | Digital Services Act Compliance Checklist (Audit-Ready)](/artifacts/eu/digital-services-act/checklist.md): An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency. - [EU DSA Compliance Guide | Digital Services Act Implementation Playbook](/artifacts/eu/digital-services-act/compliance.md): A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering. - [EU DSA Deadlines & Compliance Calendar | Key Dates, Cadence and Milestones](/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar.md): A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24. - [EU DSA FAQ | Digital Services Act Questions & Answers (Practical)](/artifacts/eu/digital-services-act/faq.md): Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what "hosting" and "online platform" mean. - [EU DSA Service Types & Scope | Hosting vs Platform vs Marketplace](/artifacts/eu/digital-services-act/service-types-and-scope.md): How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting). - [VLOP/VLOSE Systemic Risk Assessment (DSA) | Articles 34-36 + Mitigation](/artifacts/eu/digital-services-act/risk-assessments-and-mitigation.md): A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-services-act/penalties-and-fines --- --- title: "EU Digital Services Act (DSA) Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/digital-services-act/requirements" source_url: "https://www.sorena.io/artifacts/eu/digital-services-act/requirements" author: "Sorena AI" description: "A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Digital Services Act requirements" - "DSA requirements" - "Digital Services Act obligations" - "DSA compliance requirements" - "notice and action Article 16" - "statement of reasons Article 17" - "DSA transparency reporting Article 15" - "Article 24" - "VLOP audit Article 37" - "systemic risk assessment Article 34" - "notice and action" - "statement of reasons" - "transparency reporting" - "online marketplace" - "VLOP/VLOSE" - "systemic risk assessment" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Digital Services Act (DSA) Requirements A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms. *Artifact Guide* *EU* ## EU Digital Services Act (DSA) Requirements A layered obligations map you can translate into workstreams, owners and evidence. Built around how the DSA is structured: intermediary -> hosting -> platform -> marketplace -> VLOP/VLOSE. The DSA's most important design feature is its layered obligation model: you inherit additional obligations as your service classification moves from intermediary services to hosting services to online platforms, with special rules for marketplaces and a systemic-risk tier for VLOPs/VLOSEs. Use this page as the backbone for your requirements matrix and your compliance roadmap. ## Layer 1 - Baseline obligations for intermediary services (start here) Baseline DSA requirements focus on operational accessibility, transparency and enforceability: clear terms and conditions, points of contact, and (where applicable) a legal representative in the Union. These are often "policy + product surface" tasks that require legal, UX and engineering alignment. - Single point of contact for recipients (Article 12): user-friendly electronic communications that do not rely solely on automated tools. - Legal representative (Article 13): required if you're not established in the EU but offer services in the EU (publish contact details). - Terms and conditions transparency (Article 14): disclose content moderation policies/procedures/tools (including algorithmic decision-making + human review) in clear language and machine-readable format. - Transparency reporting baseline (Article 15): annual reports on content moderation, including orders, notices, complaints, automated moderation use, and accuracy/error indicators (with micro/small exclusions). ## Layer 2 - Hosting services (illegal content handling + decision explainability) If you host information provided by recipients, you must implement notice & action mechanisms and explain key restriction decisions. This layer is where most "trust & safety engineering" work begins. - Notice & action mechanisms (Article 16): electronic, user-friendly intake; notices must allow a diligent host to identify illegality without detailed legal examination (when sufficiently precise/substantiated). - Confirmation + outcome notification to notifiers (Article 16(4)-(6)): receipt confirmation and decision notifications, including redress options. - Statement of reasons (Article 17): provide affected recipients with clear, specific reasons for restrictions (removal, demotion, account actions), including legal/contractual grounds and automation use. - Criminal offence suspicions (Article 18): promptly inform law enforcement/judicial authorities for certain serious threats. ## Layer 3 - Online platforms (user redress, interface integrity, additional transparency) Online platform status adds stronger recipient rights: complaints and dispute settlement pathways, protections against misuse, and expanded transparency and interface obligations. These requirements typically span policy operations, product UI/UX, and logging/reporting infrastructure. - Platform transparency reporting (Article 24): add dispute settlement volumes/outcomes and suspension metrics; publish AMAR at least every 6 months; submit statements of reasons for inclusion in the Commission database (Article 24(5)). - Online interface integrity (Article 25): do not design interfaces to deceive/manipulate recipients or materially impair free and informed decisions (anti-dark-pattern duty). - Advertising transparency (Article 26): per-ad disclosure that content is an ad, who benefits, who paid (if different), and meaningful targeting parameters plus how to change them; restrict certain profiling uses. - Recommender transparency (Article 27): disclose main parameters and user options to modify/influence them; provide a directly accessible option selector where multiple ranking options exist. - Online protection of minors (Article 28): appropriate measures for privacy, safety and security; restrictions on profiling-based ads to minors without requiring additional personal data processing solely for age estimation. ## Layer 4 - Online marketplaces (distance contracts with traders) Marketplaces have dedicated consumer-protection obligations focused on trader traceability and compliance-by-design interfaces. This layer is operationally heavy: KYC-like trader onboarding, evidence retention, and suspension workflows. - Trader traceability (Article 30): collect trader identity, registers, payment account details, and self-certification; make best efforts to assess reliability/completeness; store securely and delete after the retention period. - Compliance-by-design interface (Article 31): enable traders to provide required pre-contractual, compliance and product safety information; best-effort checks and random checks for illegality in official databases. - Right to information (Article 32): when aware of illegal products/services, inform impacted consumers (or publish accessible info) and provide redress paths. ## Layer 5 - VLOPs/VLOSEs (systemic-risk management, audits and enhanced transparency) VLOP/VLOSE obligations apply after Commission designation under Article 33 and are the highest bar: systemic risk assessments, risk mitigation measures, independent audits, additional ad transparency, and more frequent reporting. If you could be near the threshold, build the capabilities early: reporting pipelines, risk management governance, and audit evidence. - Designation threshold (Article 33): AMAR in the Union >= 45 million + Commission designation decision; obligations apply (or cease) from four months after notification. - Systemic risk assessment (Article 34): identify/analyse systemic risks stemming from design/functioning/use (illegal content, fundamental rights, civic discourse/elections, public security, minors and well-being), at least annually and before major feature deployments. - Independent audits (Article 37): annual independent audit of compliance and (where applicable) code-of-conduct commitments; publish/transmit audit reports and implementation reports under transparency reporting rules. - Recommender systems (Article 38): provide at least one option per recommender system that is not based on profiling (for VLOPs/VLOSEs that use recommenders). - Ad repository (Article 39): provide a searchable repository and API access for ads, while excluding personal data of recipients and keeping information accurate/complete. - Enhanced transparency reporting (Article 42): publish Article 15 reports within the specified timeframe and at least every six months; include language breakdown of moderation resources and publish risk assessment, mitigation and audit materials (with confidentiality carve-outs). ## How to turn requirements into an implementation plan (fast path) A good DSA requirements matrix is a work plan: each requirement has an owner, control design, acceptance criteria, evidence, and a reporting cadence. Use these steps to avoid "policy-only" compliance that fails under enforcement scrutiny. - Create a requirements matrix: Article -> obligation -> product/control -> owner -> evidence -> reporting cadence. - Build a statement-of-reasons pipeline first: it improves compliance, transparency reporting, and user redress workflows at once. - Implement notice intake + triage with SLA metrics and audit logs (include automation use disclosures). - Design transparency reporting as data engineering: define metrics, data sources, QA controls, and sign-off workflow. - If VLOP/VLOSE: build an annual risk assessment and audit calendar and reserve time for remediation and publication. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU Digital Services Act (DSA) Requirements into an operational assessment Assessment Autopilot can take EU Digital Services Act (DSA) Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Digital Services Act (DSA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Digital Services Act (DSA) Requirements](/solutions/assessment.md): Start from EU Digital Services Act (DSA) Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Digital Services Act (DSA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Services Act (DSA) Requirements. ## Primary sources - [Regulation (EU) 2022/2065 (Digital Services Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/2065/oj?ref=sorena.io) - Primary legal text for DSA obligations by service type and tier (Articles 12-18, 24-28, 29-39, 42, 52). - [European Commission - The Digital Services Act (overview)](https://digital-strategy.ec.europa.eu/en/policies/digital-services-act?ref=sorena.io) - Commission overview and links to guidance on key DSA obligations and enforcement. ## Related Topic Guides - [DSA Ads & Recommender Systems | Article 26, 27, 38 & 39 Compliance](/artifacts/eu/digital-services-act/ads-and-recommender-systems.md): A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27). - [DSA Applicability Test | Is the EU Digital Services Act Applicable to You?](/artifacts/eu/digital-services-act/applicability-test.md): A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers. - [DSA Enforcement & Investigations | DSCs, Commission Powers, Audits & Procedures](/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations.md): A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services. - [DSA Notice & Action Workflow | Article 16 Requirements + Templates](/artifacts/eu/digital-services-act/notice-and-action-workflow.md): A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements. - [DSA Penalties & Fines | Digital Services Act Enforcement Exposure (6% / 1% / 5%)](/artifacts/eu/digital-services-act/penalties-and-fines.md): How DSA penalties work under Regulation (EU) 2022/2065. - [DSA Transparency Report Template | Article 15 + Article 24 + VLOP Article 42](/artifacts/eu/digital-services-act/dsa-transparency-report-template.md): Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835. - [DSA Transparency Reporting | Articles 15, 24 & 42 Reporting Requirements](/artifacts/eu/digital-services-act/transparency-reporting.md): A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24. - [DSA vs DMA | Digital Services Act vs Digital Markets Act (What's the Difference?)](/artifacts/eu/digital-services-act/dsa-vs-dma.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA. - [DSA vs UK Online Safety Act | EU vs UK Online Safety Compliance](/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users). - [EU DSA Checklist | Digital Services Act Compliance Checklist (Audit-Ready)](/artifacts/eu/digital-services-act/checklist.md): An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency. - [EU DSA Compliance Guide | Digital Services Act Implementation Playbook](/artifacts/eu/digital-services-act/compliance.md): A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering. - [EU DSA Deadlines & Compliance Calendar | Key Dates, Cadence and Milestones](/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar.md): A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24. - [EU DSA FAQ | Digital Services Act Questions & Answers (Practical)](/artifacts/eu/digital-services-act/faq.md): Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what "hosting" and "online platform" mean. - [EU DSA Service Types & Scope | Hosting vs Platform vs Marketplace](/artifacts/eu/digital-services-act/service-types-and-scope.md): How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting). - [VLOP/VLOSE Systemic Risk Assessment (DSA) | Articles 34-36 + Mitigation](/artifacts/eu/digital-services-act/risk-assessments-and-mitigation.md): A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-services-act/requirements --- --- title: "VLOP/VLOSE Systemic Risk Assessment (DSA)" canonical_url: "https://www.sorena.io/artifacts/eu/digital-services-act/risk-assessments-and-mitigation" source_url: "https://www.sorena.io/artifacts/eu/digital-services-act/risk-assessments-and-mitigation" author: "Sorena AI" description: "A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "DSA systemic risk assessment" - "Article 34 risk assessment" - "DSA risk mitigation Article 35" - "VLOP risk assessment" - "VLOSE risk assessment" - "DSA audit readiness" - "DSA crisis response Article 36" - "DSA systemic risk categories" - "systemic risk assessment" - "Article 34" - "risk mitigation" - "Article 35" - "VLOP" - "VLOSE" - "audit readiness" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # VLOP/VLOSE Systemic Risk Assessment (DSA) A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency. *VLOP/VLOSE Guide* *EU* ## EU Digital Services Act (DSA) Systemic Risk & Mitigation How to run Article 34 systemic risk assessments and build Article 35 mitigation measures that stand up to audits. Designed for VLOP/VLOSE readiness, with a repeatable annual calendar and evidence pack. For VLOPs and VLOSEs, DSA compliance becomes a risk management lifecycle: systemic risk assessment (Article 34) -> mitigation measures (Article 35) -> independent audit (Article 37) -> publication/transmission (Article 42). This page is an implementation guide for the risk and mitigation phases, with concrete measures and evidence expectations. ## Who this applies to: VLOPs/VLOSEs and designation timing The systemic-risk obligations apply to online platforms and online search engines designated as very large under Article 33. If you are approaching the AMAR threshold, build the capability early - you'll need risk and audit outputs within months of designation. - Threshold: AMAR in the Union >= 45 million (Article 33(1)) plus Commission designation decision. - Obligations apply from four months after notification of the designation decision (Article 33(6)). - AMAR publication cadence: publish AMAR at least every six months (Article 24(2)). ## Article 34 - What you must assess (systemic risk categories) Article 34 requires VLOPs/VLOSEs to identify, analyse, and assess systemic risks stemming from design/functioning/use of the service and related systems (including algorithmic systems). The risk assessment is service-specific and proportionate, considering severity and probability. - Illegal content dissemination risk (Article 34(1)(a)). - Fundamental rights risks (Article 34(1)(b)), including privacy, data protection, freedom of expression, non-discrimination, and child rights. - Risks to civic discourse/electoral processes and public security (Article 34(1)(c)). - Risks related to gender-based violence, public health, minors, and physical/mental well-being (Article 34(1)(d)). *Recommended next step* *Placement: after the main workflow section* ## Turn EU Digital Services Act (DSA) Systemic Risk & Mitigation into an operational assessment Assessment Autopilot can take EU Digital Services Act (DSA) Systemic Risk & Mitigation from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on EU Digital Services Act (DSA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Digital Services Act (DSA) Systemic Risk & Mitigation](/solutions/assessment.md): Start from EU Digital Services Act (DSA) Systemic Risk & Mitigation and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Digital Services Act (DSA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Services Act (DSA) Systemic Risk & Mitigation. ## Article 34 - When and how often to assess (and what triggers an out-of-cycle update) Risk assessments must be completed by the date of application for the designated service and at least annually thereafter. They must also be performed prior to deploying functionalities likely to have a critical impact on identified risks. - Minimum frequency: annual. - Out-of-cycle triggers: major changes to ranking/recommenders, ad targeting, moderation systems, identity/account systems, or other features likely to critically impact risks. - Regional/language factors: incorporate regional or linguistic aspects, including Member State-specific issues (Article 34(2) guidance). ## Article 34 - What factors to consider (the "systems" lens) Article 34(2) pushes a systems perspective: how platform systems influence risks. This prevents "paper-only" risk assessments that ignore product design and operational reality. - Recommender and algorithmic systems effects (Article 34(2)(a)). - Content moderation systems and enforcement effects (Article 34(2)(b)). - Terms and conditions and their enforcement (Article 34(2)(c)). - Advertising systems effects (Article 34(2)(d)). - Data-related practices effects (Article 34(2)(e)). - Manipulation/inauthentic use and rapid amplification dynamics (Article 34(2) additional analysis). ## Documentation and retention (prove the assessment was real) The DSA explicitly requires preserving supporting documents for risk assessments for a minimum period and providing them on request. This means you need an evidence model: inputs, analysis, decisions, and approvals. - Preserve supporting documents for at least three years after performing the assessments (Article 34(3)). - Build an evidence pack: datasets, analysis notebooks, meeting minutes, decision logs, and sign-offs. - Ensure confidentiality and access controls for sensitive inputs while enabling auditability. ## Article 35 - Mitigation measures (what "reasonable, proportionate, effective" means) Article 35 requires reasonable, proportionate, and effective mitigation measures tailored to the specific systemic risks identified, with particular consideration for impacts on fundamental rights. This is where you translate the risk assessment into product, policy and operational changes. - Product changes: adapt design/features/online interface (Article 35(1)(a)). - Policy changes: adapt terms and enforcement (Article 35(1)(b)). - Moderation operations: adapt speed/quality of notice processing, decision processes, resources; expeditious removal where appropriate for certain content types (Article 35(1)(c)). - Algorithmic testing: test/adapt algorithmic systems and recommender systems (Article 35(1)(d)). - Ads system changes: adapt advertising systems and targeted measures to limit/adjust ad presentation (Article 35(1)(e)). - Governance: reinforce internal processes/resources/testing/documentation/supervision (Article 35(1)(f)). - Cooperation: adjust cooperation with trusted flaggers and dispute settlement bodies (Article 35(1)(g)). - Codes/crisis protocols: participate in codes of conduct and crisis protocols where applicable (Article 35(1)(h)). - Child protection measures: targeted measures including age verification/parental controls and reporting/support tooling for minors (Article 35(1)(j)). - Synthetic media marking: prominent markings + easy-to-use functionality to indicate manipulated/generated media (Article 35(1)(k)). ## Annual risk calendar (recommended operating cadence) A defensible VLOP/VLOSE program runs on a calendar with clear sequencing: assess -> decide -> implement -> measure -> audit -> publish. Build this calendar so you don't compress remediation into the audit window. - Q1: risk assessment planning, data collection, and risk workshops; update threat models and definitions. - Q2: complete Article 34 risk assessment; approve mitigation plan and KPIs; begin mitigation rollouts. - Q3: run measurement and effectiveness reviews; prepare audit evidence; address gaps before auditors arrive. - Q4: independent audit execution and remediation; prepare Article 42 publication/transmission pack. ## Evidence pack checklist (what to keep ready for Article 42 publication and audits) Under Article 42, VLOPs/VLOSEs must publish/transmit risk and audit materials. Make those outputs "exportable" by design. This checklist helps you build an evidence model that supports both audits and publication obligations. - Risk assessment report + supporting datasets and analysis artifacts. - Mitigation plan with owners, KPIs, rollout tracking, and effectiveness evaluation results. - Change logs for major algorithmic systems, recommender surfaces, ad systems, and moderation policy updates. - Audit-ready policies and procedures (moderation workflows, appeals, data access governance). - Redaction plan: how confidential/sensitive information is handled for public versions while full versions are transmitted to authorities. ## Primary sources - [Regulation (EU) 2022/2065 (Digital Services Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/2065/oj?ref=sorena.io) - Primary DSA systemic-risk obligations (Articles 33-36) and mitigation measures list (Article 35), including documentation retention (Article 34(3)). ## Related Topic Guides - [DSA Ads & Recommender Systems | Article 26, 27, 38 & 39 Compliance](/artifacts/eu/digital-services-act/ads-and-recommender-systems.md): A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27). - [DSA Applicability Test | Is the EU Digital Services Act Applicable to You?](/artifacts/eu/digital-services-act/applicability-test.md): A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers. - [DSA Enforcement & Investigations | DSCs, Commission Powers, Audits & Procedures](/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations.md): A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services. - [DSA Notice & Action Workflow | Article 16 Requirements + Templates](/artifacts/eu/digital-services-act/notice-and-action-workflow.md): A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements. - [DSA Penalties & Fines | Digital Services Act Enforcement Exposure (6% / 1% / 5%)](/artifacts/eu/digital-services-act/penalties-and-fines.md): How DSA penalties work under Regulation (EU) 2022/2065. - [DSA Transparency Report Template | Article 15 + Article 24 + VLOP Article 42](/artifacts/eu/digital-services-act/dsa-transparency-report-template.md): Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835. - [DSA Transparency Reporting | Articles 15, 24 & 42 Reporting Requirements](/artifacts/eu/digital-services-act/transparency-reporting.md): A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24. - [DSA vs DMA | Digital Services Act vs Digital Markets Act (What's the Difference?)](/artifacts/eu/digital-services-act/dsa-vs-dma.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA. - [DSA vs UK Online Safety Act | EU vs UK Online Safety Compliance](/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users). - [EU Digital Services Act (DSA) Requirements | Obligations by Service Type & Tier](/artifacts/eu/digital-services-act/requirements.md): A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms. - [EU DSA Checklist | Digital Services Act Compliance Checklist (Audit-Ready)](/artifacts/eu/digital-services-act/checklist.md): An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency. - [EU DSA Compliance Guide | Digital Services Act Implementation Playbook](/artifacts/eu/digital-services-act/compliance.md): A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering. - [EU DSA Deadlines & Compliance Calendar | Key Dates, Cadence and Milestones](/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar.md): A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24. - [EU DSA FAQ | Digital Services Act Questions & Answers (Practical)](/artifacts/eu/digital-services-act/faq.md): Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what "hosting" and "online platform" mean. - [EU DSA Service Types & Scope | Hosting vs Platform vs Marketplace](/artifacts/eu/digital-services-act/service-types-and-scope.md): How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-services-act/risk-assessments-and-mitigation --- --- title: "EU DSA Service Types & Scope" canonical_url: "https://www.sorena.io/artifacts/eu/digital-services-act/service-types-and-scope" source_url: "https://www.sorena.io/artifacts/eu/digital-services-act/service-types-and-scope" author: "Sorena AI" description: "How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Digital Services Act scope" - "DSA scope" - "DSA service type" - "intermediary service definition" - "hosting service DSA" - "online platform DSA" - "online marketplace DSA" - "online search engine DSA" - "VLOP threshold 45 million" - "DSA applicability" - "intermediary services" - "hosting services" - "online platform" - "online marketplace" - "online search engine" - "VLOP/VLOSE" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DSA Service Types & Scope How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting). *Artifact Guide* *EU* ## EU Digital Services Act (DSA) Service Types & Scope A defensible way to classify your service type and tier under Regulation (EU) 2022/2065. Use this page to produce a scope memo that product, legal, security and trust & safety can all execute against. DSA compliance starts with classification: what service type(s) you provide (intermediary services, hosting, online platform, online marketplace, online search engine) and whether you are in-scope for EU recipients. This page helps you turn "we think we're a platform" into a written scope decision you can defend and maintain as your product evolves. ## What DSA scope means in practice (why teams get it wrong) The DSA is structured as a layered obligation model: baseline obligations for intermediary services, extra obligations for hosting services, additional obligations for online platforms, special rules for online marketplaces, and the highest tier for VLOPs/VLOSEs. Misclassification creates two failure modes: (1) missing obligations you actually need to ship, or (2) building unnecessary controls that slow down your roadmap. - Treat scope as a living artifact: update it when features change (UGC, ranking, ads, trading, search, messaging). - If you operate multiple services, classify each service separately (DSA duties can attach per service). - Keep a written scope memo: service facts -> classification -> obligations -> owners -> evidence. *Recommended next step* *Placement: after the scope or definition section* ## Use EU Digital Services Act (DSA) Service Types & Scope as a cited research workflow Research Copilot can take EU Digital Services Act (DSA) Service Types & Scope from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Digital Services Act (DSA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Digital Services Act (DSA) Service Types & Scope](/solutions/research-copilot.md): Start from EU Digital Services Act (DSA) Service Types & Scope and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Digital Services Act (DSA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Services Act (DSA) Service Types & Scope. ## Step 1 - Are you a provider of intermediary services (baseline DSA layer)? The DSA applies to providers of intermediary services, including where you transmit, cache, or host information provided by recipients of the service. If your system stores information "at the request of a user" and makes it available to others, you are typically in hosting territory and will inherit notice & action duties. - Mere conduit: you transmit information without selecting or modifying it (common in access/network transit). - Caching: you store data for efficiency/performance (common in CDNs). - Hosting: you store information provided by a user/recipient at their request (UGC, listings, repositories, comments, file hosting). ## Step 2 - Hosting vs online platform (the "public distribution" trigger) The step from hosting -> online platform is the biggest obligation jump for product teams: it adds user redress duties, interface integrity obligations, and stricter transparency requirements. In practice, "online platform" often maps to user-to-user distribution: recipients provide information that is disseminated to the public (or at least to other users) at their request. - If users can post and other users can consume: expect platform duties to be relevant. - If your service only hosts private content for one user (e.g., personal storage with no distribution): platform triggers may not apply, but hosting duties still can. - Write down the dissemination surface: public pages, group access, search/indexing, recommendations, embeds, API feeds. ## Step 3 - Online marketplace rules (distance contracts with traders) If your online platform allows consumers to conclude distance contracts with traders, the DSA adds a dedicated obligation set for trader traceability and marketplace-by-design requirements. This layer is about preventing illegal goods/services and enabling consumer redress by requiring trader identity information, best-effort verification, and consumer notifications when illegal products/services are discovered. - Trader traceability (Article 30): collect trader identity/contact info, trade register identifiers, payment account details, and self-certification of EU law compliance; make best efforts to assess reliability. - Compliance by design (Article 31): ensure your interface lets traders provide required product safety/compliance information. - Right to information (Article 32): notify consumers when illegal products/services were sold and provide redress information (within the defined lookback window). ## Step 4 - Online search engine scope Search engines have DSA obligations, including transparency duties and VLOSE systemic-risk obligations when designated. If you provide search across the web or across a large corpus and rank results for recipients, treat scope conservatively and document your rationale. - Define the searchable corpus: web-wide vs vertical vs internal catalog vs enterprise/private search. - Document ranking and recommender behavior: algorithmic parameters, user controls, and ads placement. - If you publish average monthly active recipients, keep calculation methodology defensible (Article 24). ## Step 5 - EU offering triggers + operational setup (points of contact, legal rep) Scope is not just product taxonomy. The DSA contains operational requirements that affect how you run the service in the EU. At minimum, plan for points of contact and (where applicable) a legal representative in the Union. - Single point of contact for recipients (Article 12): user-friendly electronic communications that do not rely solely on automated tools. - Legal representative (Article 13): if you're not established in the Union but offer services in the Union, designate a representative and publish contact details. - Terms and conditions transparency (Article 14): content moderation policies, procedures, and tools must be clearly described and machine-readable. ## Micro/small enterprise exclusions (what you still must do) The DSA includes exclusions for micro and small enterprises for certain reporting and marketplace sections, but the exclusions are not universal and have exceptions (notably for VLOPs). Treat this as a legal determination with a documented basis (Recommendation 2003/361/EC thresholds and group/affiliate structure). - Transparency reporting baseline excludes micro/small enterprises unless they are VLOPs/VLOSEs (Article 15(2)). - Marketplace Section 4 excludes micro/small enterprises, with a 12-month transition after losing status and an override for VLOPs (Article 29). - Even with exclusions: document scope, maintain points of contact/terms transparency, and implement safe notice handling where hosting is involved. ## Scope memo checklist (evidence pack you can reuse across audits) A strong scope memo makes later implementation work cheaper. It lets you map obligations to owners and prevents "scope drift" from becoming an enforcement surprise. Use this checklist to produce a scope memo that's useful for product, legal, security and operations. - Service inventory: list each service and its key features (UGC, ads, ranking, trading, messaging, search). - Classification decision: hosting/platform/marketplace/search; write the rationale and counterarguments. - Tier decision: whether you may meet VLOP/VLOSE thresholds; record your AMAR calculation approach (Article 24). - Obligation map: link to your internal checklist and owners by workstream (moderation, user redress, transparency reports, marketplace compliance). - Change triggers: define what product changes require reclassification and who owns the update. ## Primary sources - [Regulation (EU) 2022/2065 (Digital Services Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/2065/oj?ref=sorena.io) - Primary legal text for DSA scope and layered obligations (intermediary services, hosting services, online platforms, online marketplaces, VLOPs/VLOSEs). - [European Commission - The Digital Services Act (overview)](https://digital-strategy.ec.europa.eu/en/policies/digital-services-act?ref=sorena.io) - Commission overview of service types covered (marketplaces, social media, app stores) and user rights and platform duties. - [European Commission - Digital Services Act Q&A](https://digital-strategy.ec.europa.eu/en/faqs/digital-services-act-questions-and-answers?ref=sorena.io) - Practical clarifications for scope and compliance concepts used by teams implementing DSA programs. ## Related Topic Guides - [DSA Ads & Recommender Systems | Article 26, 27, 38 & 39 Compliance](/artifacts/eu/digital-services-act/ads-and-recommender-systems.md): A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27). - [DSA Applicability Test | Is the EU Digital Services Act Applicable to You?](/artifacts/eu/digital-services-act/applicability-test.md): A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers. - [DSA Enforcement & Investigations | DSCs, Commission Powers, Audits & Procedures](/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations.md): A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services. - [DSA Notice & Action Workflow | Article 16 Requirements + Templates](/artifacts/eu/digital-services-act/notice-and-action-workflow.md): A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements. - [DSA Penalties & Fines | Digital Services Act Enforcement Exposure (6% / 1% / 5%)](/artifacts/eu/digital-services-act/penalties-and-fines.md): How DSA penalties work under Regulation (EU) 2022/2065. - [DSA Transparency Report Template | Article 15 + Article 24 + VLOP Article 42](/artifacts/eu/digital-services-act/dsa-transparency-report-template.md): Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835. - [DSA Transparency Reporting | Articles 15, 24 & 42 Reporting Requirements](/artifacts/eu/digital-services-act/transparency-reporting.md): A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24. - [DSA vs DMA | Digital Services Act vs Digital Markets Act (What's the Difference?)](/artifacts/eu/digital-services-act/dsa-vs-dma.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA. - [DSA vs UK Online Safety Act | EU vs UK Online Safety Compliance](/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users). - [EU Digital Services Act (DSA) Requirements | Obligations by Service Type & Tier](/artifacts/eu/digital-services-act/requirements.md): A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms. - [EU DSA Checklist | Digital Services Act Compliance Checklist (Audit-Ready)](/artifacts/eu/digital-services-act/checklist.md): An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency. - [EU DSA Compliance Guide | Digital Services Act Implementation Playbook](/artifacts/eu/digital-services-act/compliance.md): A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering. - [EU DSA Deadlines & Compliance Calendar | Key Dates, Cadence and Milestones](/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar.md): A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24. - [EU DSA FAQ | Digital Services Act Questions & Answers (Practical)](/artifacts/eu/digital-services-act/faq.md): Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what "hosting" and "online platform" mean. - [VLOP/VLOSE Systemic Risk Assessment (DSA) | Articles 34-36 + Mitigation](/artifacts/eu/digital-services-act/risk-assessments-and-mitigation.md): A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-services-act/service-types-and-scope --- --- title: "DSA Transparency Reporting" canonical_url: "https://www.sorena.io/artifacts/eu/digital-services-act/transparency-reporting" source_url: "https://www.sorena.io/artifacts/eu/digital-services-act/transparency-reporting" author: "Sorena AI" description: "A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "DSA transparency reporting" - "Digital Services Act transparency report" - "Article 15 transparency report" - "Article 24 transparency reporting" - "AMAR publication Article 24" - "statement of reasons database Article 24(5)" - "VLOP transparency report Article 42" - "DSA reporting template" - "DSA transparency report" - "Article 15" - "Article 24" - "Article 42" - "AMAR" - "statement of reasons database" - "VLOP reporting" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DSA Transparency Reporting A practical guide to EU Digital Services Act transparency reporting: what to publish for Article 15, what to add for Article 24. *Reporting Guide* *EU* ## EU Digital Services Act (DSA) Transparency Reporting What to publish, how often, and how to build a reporting pipeline that survives audits. Covers Article 15 (intermediary), Article 24 (platform/search), and Article 42 (VLOP/VLOSE). DSA transparency reporting should be treated like regulated financial reporting: defined metrics, controlled data sources, QA checks, executive sign-off, and a repeatable cadence. This page explains what each tier must publish and how to build the data model and workflow that makes reporting reliable and defensible. ## The reporting stack: Article 15 vs Article 24 vs Article 42 (who publishes what) The DSA uses a layered reporting model that mirrors the layered obligations model. You must first determine which layer(s) apply to each service you operate. - Article 15: baseline annual transparency report for providers of intermediary services (with micro/small exclusions unless VLOP/VLOSE). - Article 24: additional reporting obligations for online platforms (and AMAR publication obligations for online platforms and online search engines). - Article 42: enhanced transparency reporting obligations for VLOPs/VLOSEs (at least every 6 months) plus publication/transmission of risk, mitigation and audit materials. ## Article 15 - Annual transparency reports for intermediary services (minimum dataset) Article 15 requires providers of intermediary services to publish at least once a year a clear, easily comprehensible report on content moderation. The report must be machine-readable and easily accessible. - Orders from Member State authorities: volumes, type of illegal content, issuing Member State, and median response/action times (Article 15(1)(a)). - Hosting notices: volumes, type of alleged illegal content, notices from trusted flaggers, actions taken and grounds (law vs terms), automation use, and median action time (Article 15(1)(b)). - Own-initiative moderation: meaningful information on moderation performed on your initiative, including automation use, measures affecting availability/visibility, detection methods and restriction types (Article 15(1)(c)). - Complaints and reversals: counts, bases, decisions, median time, and reversal counts (Article 15(1)(d)). - Automation quality: qualitative description, purposes, accuracy/error indicators, safeguards (Article 15(1)(e)). ## Article 24 - Online platform transparency + AMAR publication (and statement-of-reasons database) Article 24 adds two high-impact requirements: (1) extra items in transparency reports for online platforms, and (2) publication of average monthly active recipients (AMAR) for online platforms and online search engines every six months. It also requires online platforms to submit Article 17 statements of reasons for inclusion in a Commission database. - Article 24(1) additions (online platforms): dispute settlement metrics and suspension metrics (Article 23 suspensions). - Article 24(2) AMAR: publish AMAR in the Union by 17 Feb 2023 and at least once every 6 months thereafter (calculated over the past 6 months). - Article 24(3): provide AMAR data and substantiation on request to the DSC of establishment and the Commission (no personal data). - Article 24(5): submit Article 17(1) statements of reasons for inclusion in the Commission's public, machine-readable database; ensure submissions do not contain personal data. - Practical takeaway: your statement-of-reasons pipeline is part of reporting infrastructure. ## Article 42 - VLOP/VLOSE enhanced reporting (six-month cadence + risk/audit publication) For VLOPs/VLOSEs, transparency reporting is more frequent (at least every 6 months) and includes publication/transmission of systemic risk and audit materials. This creates a public accountability loop: risk assessment -> mitigation -> audit -> publication. - Cadence: publish Article 15 reports within the specified window and at least every 6 months (Article 42(1)). - Content: include language breakdown of moderation resources, qualifications, training, support, and linguistic expertise by language; the implementing regulation uses CEFR as the benchmark and sets CEFR-B2 as the minimum threshold for sufficient linguistic expertise. - AMAR by Member State: include recipients per Member State (Article 42(3)). - Publish/transmit: risk assessment report, mitigation measures, audit report, and audit implementation report (Article 42(4)), with confidentiality carve-outs (Article 42(5)). ## Implementing Regulation (EU) 2024/2835: templates, periods, format, retention, and versioning The DSA reporting duty is no longer just a high level obligation in Articles 15, 24, and 42. Implementing Regulation (EU) 2024/2835 now defines the reporting templates, the harmonized periods, and the publication mechanics. If your reporting process still relies on ad hoc PDFs or inconsistent time windows, it is now out of step with the Commission reporting model. - Use the Annex I templates from 1 July 2025 onward for Articles 15, 24, and 42 reports. - Publish each transparency report no later than 2 months after the end of the relevant reporting period. - For the transition year, the second reporting cycle starts no later than 17 February 2025 and runs until 31 December 2025; harmonized periods apply from 1 January 2026. - Publish the completed templates in ODF CSV format, complying with RFC 4180 and UTF-8 encoding. - Keep every published report publicly available for at least 5 years. - If you correct errors or methodology changes, publish an updated version that is clearly labeled, dated, and explained, while keeping earlier versions available. ## Reporting data model (recommended schema you can implement) A reporting pipeline is easiest to build when you treat reporting as structured data, not a narrative document. Use this schema to define authoritative data sources and QA checks. - Metric dictionary: metric name, DSA article reference, definition, source systems, data owners, and validation checks. - Event logs: notice events, action events, restriction events, complaint events, dispute settlement events, suspension events. - Decision metadata: legal vs terms grounds, automated means flags, timestamps, and territorial scope/duration fields for restrictions. - Time-to-action metrics: median times for orders/notices/complaints, with segment breakdowns you can reproduce. - Publication pack: generated report + dataset snapshot + QA report + sign-off + version history. ## QA and defensibility checklist (what auditors/regulators ask first) Reporting failures are often data quality failures: missing definitions, inconsistent counting, or inability to reproduce results. Use this checklist to make reporting defensible. - Reproducibility: can you rerun the report for the same period and get the same results? - Completeness: do all required Article 15/24/42 elements exist (for your tier) and are they clearly labeled? - No personal data in public submissions where prohibited (e.g., statement-of-reasons database submissions). - Automation disclosures are complete and consistent across notifications and report numbers. - Governance: named owner, review cadence, and change management for metric definitions. - Format compliance: publish the report in the Commission template structure and machine-readable ODF CSV format, not as an unstructured narrative only. - Version control: if a report is corrected, keep the original public version, explain the changes, and preserve the full version history for the 5-year retention period. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU Digital Services Act (DSA) Transparency Reporting as a cited research workflow Research Copilot can take EU Digital Services Act (DSA) Transparency Reporting from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU Digital Services Act (DSA) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Digital Services Act (DSA) Transparency Reporting](/solutions/research-copilot.md): Start from EU Digital Services Act (DSA) Transparency Reporting and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Digital Services Act (DSA)](/contact.md): Review your current process, evidence gaps, and next steps for EU Digital Services Act (DSA) Transparency Reporting. ## Primary sources - [Regulation (EU) 2022/2065 (Digital Services Act) - Official Journal](https://eur-lex.europa.eu/eli/reg/2022/2065/oj?ref=sorena.io) - Primary reporting obligations in Articles 15, 24, and 42, including AMAR publication cadence and statement-of-reasons database submission requirements. - [European Commission - DSA guidance on publishing average monthly active recipients (AMAR)](https://digital-strategy.ec.europa.eu/en/library/dsa-guidance-requirement-publish-user-numbers?ref=sorena.io) - Commission guidance on the requirement to publish user numbers (AMAR) under the DSA. - [Commission Implementing Regulation (EU) 2024/2835 - Transparency reporting templates](https://eur-lex.europa.eu/eli/reg_impl/2024/2835/oj?ref=sorena.io) - Sets the harmonized reporting templates, reporting periods, publication deadlines, CSV format requirements, retention period, and versioning rules. ## Related Topic Guides - [DSA Ads & Recommender Systems | Article 26, 27, 38 & 39 Compliance](/artifacts/eu/digital-services-act/ads-and-recommender-systems.md): A deep compliance guide for DSA advertising and recommender system obligations: ad transparency (Article 26), recommender system transparency (Article 27). - [DSA Applicability Test | Is the EU Digital Services Act Applicable to You?](/artifacts/eu/digital-services-act/applicability-test.md): A step-by-step applicability test for the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): EU offering triggers. - [DSA Enforcement & Investigations | DSCs, Commission Powers, Audits & Procedures](/artifacts/eu/digital-services-act/enforcement-penalties-and-investigations.md): A practical guide to DSA enforcement (Regulation (EU) 2022/2065): how Digital Services Coordinators (DSCs) supervise services. - [DSA Notice & Action Workflow | Article 16 Requirements + Templates](/artifacts/eu/digital-services-act/notice-and-action-workflow.md): A deep implementation guide for DSA notice & action (Regulation (EU) 2022/2065, Article 16): intake design, required notice elements. - [DSA Penalties & Fines | Digital Services Act Enforcement Exposure (6% / 1% / 5%)](/artifacts/eu/digital-services-act/penalties-and-fines.md): How DSA penalties work under Regulation (EU) 2022/2065. - [DSA Transparency Report Template | Article 15 + Article 24 + VLOP Article 42](/artifacts/eu/digital-services-act/dsa-transparency-report-template.md): Copy and paste ready DSA transparency report template aligned to Regulation (EU) 2022/2065 and Implementing Regulation (EU) 2024/2835. - [DSA vs DMA | Digital Services Act vs Digital Markets Act (What's the Difference?)](/artifacts/eu/digital-services-act/dsa-vs-dma.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the EU Digital Markets Act (DMA. - [DSA vs UK Online Safety Act | EU vs UK Online Safety Compliance](/artifacts/eu/digital-services-act/dsa-vs-uk-online-safety-act.md): A practical comparison of the EU Digital Services Act (DSA, Regulation (EU) 2022/2065) and the UK Online Safety Act: scope (EU recipients vs UK users). - [EU Digital Services Act (DSA) Requirements | Obligations by Service Type & Tier](/artifacts/eu/digital-services-act/requirements.md): A practical breakdown of DSA requirements (Regulation (EU) 2022/2065): obligations for intermediary services, hosting services, online platforms. - [EU DSA Checklist | Digital Services Act Compliance Checklist (Audit-Ready)](/artifacts/eu/digital-services-act/checklist.md): An audit-ready EU Digital Services Act (DSA) compliance checklist for Regulation (EU) 2022/2065: scope memo, terms transparency. - [EU DSA Compliance Guide | Digital Services Act Implementation Playbook](/artifacts/eu/digital-services-act/compliance.md): A practical EU Digital Services Act (DSA) compliance guide for Regulation (EU) 2022/2065: scope memo and tiering. - [EU DSA Deadlines & Compliance Calendar | Key Dates, Cadence and Milestones](/artifacts/eu/digital-services-act/deadlines-and-compliance-calendar.md): A DSA compliance calendar for Regulation (EU) 2022/2065: entry into force, general applicability, Digital Services Coordinator designation, Article 15, 24. - [EU DSA FAQ | Digital Services Act Questions & Answers (Practical)](/artifacts/eu/digital-services-act/faq.md): Practical answers to the most searched EU Digital Services Act (DSA) questions: who is in scope, what "hosting" and "online platform" mean. - [EU DSA Service Types & Scope | Hosting vs Platform vs Marketplace](/artifacts/eu/digital-services-act/service-types-and-scope.md): How to classify your service under the EU Digital Services Act (DSA, Regulation (EU) 2022/2065): intermediary service types (mere conduit, caching, hosting). - [VLOP/VLOSE Systemic Risk Assessment (DSA) | Articles 34-36 + Mitigation](/artifacts/eu/digital-services-act/risk-assessments-and-mitigation.md): A deep guide to DSA systemic risk management for VLOPs/VLOSEs: how to run the Article 34 systemic risk assessment (risk categories, frequency. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/digital-services-act/transparency-reporting --- --- title: "DORA Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/dora/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/dora/applicability-test" author: "Sorena AI" description: "A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2." keywords: - "DORA applicability test" - "is DORA applicable" - "EU DORA scope" - "DORA covered entities" - "DORA Article 2" - "DORA proportionality" - "simplified ICT risk management framework DORA" - "DORA register of information" - "DORA TLPT" - "DORA applicability" - "DORA scope" - "financial entities" - "proportionality" - "TLPT" - "incident reporting" - "third-party risk" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA Applicability Test A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. *Artifact Guide* *EU* ## EU DORA Applicability Test A practical way to decide whether DORA applies - and what layer applies. Designed to output a scope memo you can defend in audits and supervisory discussions. DORA applicability is a structured decision: you classify each legal entity, map it to Article 2 scope, decide proportionality/simplification, and identify which obligations attach (controls, reporting, testing, third-party governance). This applicability test is written for implementation teams so the output is actionable, not just legal interpretation. ## Output you should produce (what "done" looks like) At the end of this test you should have a scope memo per regulated entity and a group summary. This memo becomes the backbone for your requirements matrix, roadmap, and evidence pack. Most teams fail by skipping this artifact and immediately building controls without tier clarity. - Entity-by-entity scope memo: covered category mapping (Article 2) + supervisor + perimeter. - Proportionality decision: simplified framework basis and what is scaled down. - Workstreams and owners: ICT risk controls, incident reporting, testing/TLPT, third-party risk + register of information. - Evidence map: where each required artifact lives (policies, procedures, logs, reports, registers). ## Step 1 - Are you a covered financial entity under Article 2? Start with legal facts: what regulated category are you, and what license/authorization do you hold? DORA scope is defined by the covered financial entity list in Article 2. - List your legal entities and licenses (banking, investment, payment services, insurance, market infrastructure, etc.). - Map each entity to Article 2 categories and record the competent authority. - If you operate in multiple Member States or have multiple authorizations, scope each entity separately and then create a consolidated group view. ## Step 2 - What's your DORA implementation layer (full vs proportional/simplified)? DORA requires applying the proportionality principle: controls and testing intensity can scale with size, complexity, and risk profile. Document your proportionality decision as a management body artifact and review it periodically. - Define your ICT dependency profile: critical/important functions, outsourcing model, and technology concentration. - Decide which parts of ICT risk management/testing are simplified and why the residual risk is acceptable. - Create an annual review cadence for proportionality (especially after major ICT or outsourcing changes). ## Step 3 - Which compliance workstreams apply to you? Once you're in scope, DORA becomes an implementation program across four main workstreams plus governance and cooperation. Use this as your workstream inventory and owner assignment checklist. - ICT risk management (Chapter II): governance, asset inventory/classification, protection/detection, response/recovery, business continuity and communications. - Incident management and reporting (Chapter III): record incidents and significant cyber threats, classify, and report major incidents (initial/intermediate/final). - Testing and TLPT (Chapter IV): annual testing programs; TLPT readiness for entities required to run threat-led penetration tests. - ICT third-party risk + register of information (Chapter V): third-party strategy, contractual clauses, concentration risk, exit strategies, and register maintenance. - Information sharing and cooperation: decide how you will participate in sector exercises and threat intelligence sharing. ## Step 4 - Group-level obligations: register and governance layers Some obligations, especially around ICT third-party risk, operate at entity level and also at sub-consolidated and consolidated levels. If you have centralized vendor management, ensure entity-level supervisory requests can still be answered quickly. - Maintain the register of information at entity level and, where relevant, sub-consolidated and consolidated levels (Article 28). - Define how group policies map to entity controls (policy ownership vs control execution). - Set up a supervisory response workflow: who can export register sections and incident reports on request. ## Step 5 - Are you an ICT third-party provider (and could you become critical)? Even if you're not a covered financial entity, you may be impacted as an ICT third-party provider supporting critical or important functions for in-scope entities. Financial entities will demand contract clauses aligned to DORA RTS; critical designation adds oversight exposure. - If you sell ICT services to financial entities: prepare for DORA-aligned contracts, audit/access rights, incident communications, and exit/portability support. - If you are large/systemic: understand the criteria for designation as a critical ICT third-party service provider and the oversight model. - Operational implication: treat "DORA-ready supplier" as a product capability (controls + evidence + contract positions). *Recommended next step* *Placement: after the applicability result* ## Turn EU DORA Applicability Test into an operational assessment Assessment Autopilot can take EU DORA Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU DORA Applicability Test](/solutions/assessment.md): Start from EU DORA Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Applicability Test. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary DORA scope (Article 2) and workstreams: ICT risk management (Chapter II), incident reporting (Chapter III), testing/TLPT (Chapter IV), ICT third-party risk and register of information (Chapter V). ## Related Topic Guides - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/applicability-test --- --- title: "DORA Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/dora/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/dora/applicability-test" author: "Sorena AI" description: "A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2." keywords: - "DORA applicability test" - "is DORA applicable" - "EU DORA scope" - "DORA covered entities" - "DORA Article 2" - "DORA proportionality" - "simplified ICT risk management framework DORA" - "DORA register of information" - "DORA TLPT" - "DORA applicability" - "DORA scope" - "financial entities" - "proportionality" - "TLPT" - "incident reporting" - "third-party risk" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA Applicability Test A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. *Artifact Guide* *EU* ## EU DORA Applicability Test A practical way to decide whether DORA applies - and what layer applies. Designed to output a scope memo you can defend in audits and supervisory discussions. DORA applicability is a structured decision: you classify each legal entity, map it to Article 2 scope, decide proportionality/simplification, and identify which obligations attach (controls, reporting, testing, third-party governance). This applicability test is written for implementation teams so the output is actionable, not just legal interpretation. ## Output you should produce (what "done" looks like) At the end of this test you should have a scope memo per regulated entity and a group summary. This memo becomes the backbone for your requirements matrix, roadmap, and evidence pack. Most teams fail by skipping this artifact and immediately building controls without tier clarity. - Entity-by-entity scope memo: covered category mapping (Article 2) + supervisor + perimeter. - Proportionality decision: simplified framework basis and what is scaled down. - Workstreams and owners: ICT risk controls, incident reporting, testing/TLPT, third-party risk + register of information. - Evidence map: where each required artifact lives (policies, procedures, logs, reports, registers). ## Step 1 - Are you a covered financial entity under Article 2? Start with legal facts: what regulated category are you, and what license/authorization do you hold? DORA scope is defined by the covered financial entity list in Article 2. - List your legal entities and licenses (banking, investment, payment services, insurance, market infrastructure, etc.). - Map each entity to Article 2 categories and record the competent authority. - If you operate in multiple Member States or have multiple authorizations, scope each entity separately and then create a consolidated group view. ## Step 2 - What's your DORA implementation layer (full vs proportional/simplified)? DORA requires applying the proportionality principle: controls and testing intensity can scale with size, complexity, and risk profile. Document your proportionality decision as a management body artifact and review it periodically. - Define your ICT dependency profile: critical/important functions, outsourcing model, and technology concentration. - Decide which parts of ICT risk management/testing are simplified and why the residual risk is acceptable. - Create an annual review cadence for proportionality (especially after major ICT or outsourcing changes). ## Step 3 - Which compliance workstreams apply to you? Once you're in scope, DORA becomes an implementation program across four main workstreams plus governance and cooperation. Use this as your workstream inventory and owner assignment checklist. - ICT risk management (Chapter II): governance, asset inventory/classification, protection/detection, response/recovery, business continuity and communications. - Incident management and reporting (Chapter III): record incidents and significant cyber threats, classify, and report major incidents (initial/intermediate/final). - Testing and TLPT (Chapter IV): annual testing programs; TLPT readiness for entities required to run threat-led penetration tests. - ICT third-party risk + register of information (Chapter V): third-party strategy, contractual clauses, concentration risk, exit strategies, and register maintenance. - Information sharing and cooperation: decide how you will participate in sector exercises and threat intelligence sharing. ## Step 4 - Group-level obligations: register and governance layers Some obligations, especially around ICT third-party risk, operate at entity level and also at sub-consolidated and consolidated levels. If you have centralized vendor management, ensure entity-level supervisory requests can still be answered quickly. - Maintain the register of information at entity level and, where relevant, sub-consolidated and consolidated levels (Article 28). - Define how group policies map to entity controls (policy ownership vs control execution). - Set up a supervisory response workflow: who can export register sections and incident reports on request. ## Step 5 - Are you an ICT third-party provider (and could you become critical)? Even if you're not a covered financial entity, you may be impacted as an ICT third-party provider supporting critical or important functions for in-scope entities. Financial entities will demand contract clauses aligned to DORA RTS; critical designation adds oversight exposure. - If you sell ICT services to financial entities: prepare for DORA-aligned contracts, audit/access rights, incident communications, and exit/portability support. - If you are large/systemic: understand the criteria for designation as a critical ICT third-party service provider and the oversight model. - Operational implication: treat "DORA-ready supplier" as a product capability (controls + evidence + contract positions). *Recommended next step* *Placement: after the applicability result* ## Turn EU DORA Applicability Test into an operational assessment Assessment Autopilot can take EU DORA Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU DORA Applicability Test](/solutions/assessment.md): Start from EU DORA Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Applicability Test. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary DORA scope (Article 2) and workstreams: ICT risk management (Chapter II), incident reporting (Chapter III), testing/TLPT (Chapter IV), ICT third-party risk and register of information (Chapter V). ## Related Topic Guides - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/applicability-test --- --- title: "EU DORA Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/dora/checklist" source_url: "https://www.sorena.io/artifacts/eu/dora/checklist" author: "Sorena AI" description: "An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline." keywords: - "EU DORA checklist" - "DORA compliance checklist" - "DORA audit checklist" - "Digital Operational Resilience Act checklist" - "ICT risk management checklist DORA" - "DORA incident reporting checklist" - "TLPT readiness checklist" - "DORA third party risk checklist" - "DORA register of information checklist" - "DORA contract clauses checklist" - "DORA checklist" - "ICT risk management" - "major incident reporting" - "TLPT" - "third-party risk" - "register of information" - "audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DORA Checklist An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. *Checklist* *EU* ## EU DORA Checklist A checklist you can run per entity - and reuse for audits and supervisory requests. Structured the way teams execute: scope -> controls -> reporting -> testing -> third parties -> evidence. DORA compliance is a system rollout. This checklist is built as a program plan you can run per regulated entity and per group layer. For each item: assign an owner, define acceptance criteria, and keep evidence that is exportable and reproducible. ## Checklist A - Scope memo and proportionality (do this before building controls) Your first deliverable should be a scope memo per entity (and a group summary) that maps DORA scope and proportionality to concrete workstreams and owners. This prevents scope drift and mismatched control builds. - Map each legal entity to Article 2 scope category; record competent authority and reporting perimeter. - Document proportionality decisions and any simplified framework usage; record management body approvals. - Identify critical or important functions and top ICT dependencies (including outsourced services). - Define workstreams and owners: ICT risk controls, incident reporting, testing/TLPT, third-party risk + register, governance cadence. - Create an evidence map: where each required artifact lives and how to export it quickly. *Recommended next step* *Placement: after the checklist block* ## Turn EU DORA Checklist into an operational assessment Assessment Autopilot can take EU DORA Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU DORA Checklist](/solutions/assessment.md): Start from EU DORA Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Checklist. ## Checklist B - ICT risk management control baseline (Chapter II + RTS) DORA expects a coherent ICT risk management framework: governance + asset inventory + control layers + continuity + communications. Build this baseline as a control library with acceptance criteria and evidence. - Governance: management body accountability, risk tolerance, and periodic reviews. - Asset inventory and dependency mapping: ICT-supported business functions, information assets, ICT assets, and criticality classification (review at least yearly). - Protection: access control, secure configuration, change management, vulnerability management, backup and resilience patterns for critical services. - Detection: monitoring, alerting, anomaly detection, and log integrity for critical functions. - Response and recovery: runbooks, containment procedures, restore objectives, and post-incident reviews. - Communications: internal escalation, external stakeholder communications, and crisis communications integration. ## Checklist C - Incident management + major incident reporting (Chapter III + RTS) This is both an operational workflow and a data pipeline. Build a repeatable process with structured outputs and QA. Your reporting capability is tested under stress; design it to work during outages. - Incident management process exists (Article 17): early warning indicators, tracking/logging/classification, roles and responsibilities, communications, response procedures. - All ICT incidents and significant cyber threats are recorded consistently; root causes are identified, documented and addressed. - Classification criteria and materiality thresholds are implemented (Article 18 + RTS). - Reporting pipeline can produce: initial notification, intermediate updates, and final report with root cause analysis and actual impact figures (Article 19 + RTS time limits). - Client communications workflow exists for major incidents impacting financial interests. - Evidence: incident register exports, report copies, timestamps, and decision logs. ## Checklist D - Testing program + TLPT readiness (Chapter IV) Testing should be planned, risk-based, and repeatable. TLPT is a specialized program: build the governance and supplier model early. Treat testing outputs as compliance evidence and as engineering backlog inputs. - Testing program (Article 24/25): annual plan, test coverage for critical or important functions, independent testing where required, remediation and validation methodology. - Penetration testing and scenario-based testing are scheduled and evidence retained. - TLPT readiness (Article 26): scoping methodology, production-safe testing controls, and authority interaction plan. - Tester selection and contracts satisfy suitability/independence and confidentiality requirements; professional indemnity coverage verified. - Evidence: test reports, remediation tracking, re-test evidence, management summaries. ## Checklist E - ICT third-party risk: strategy, contracts, concentration, exit, register (Chapter V + RTS) Third-party risk is a top enforcement focus because it compounds operational risk across the sector. Build a vendor governance system that produces contract posture and evidence on demand. - ICT third-party risk strategy exists and is reviewed periodically; includes policy for ICT services supporting critical or important functions (Article 28). - Register of information built and maintained (Article 28): entity + (where relevant) sub-consolidated/consolidated; exportable sections for supervisors. - Concentration/substitutability analysis performed for critical/important ICT services; multi-vendor strategy considered (Article 29). - Contract clause baseline implemented (Article 30 + RTS 2024/1773): audit/access, security, subcontracting transparency, incident cooperation, portability and exit rights. - Exit strategies and transition plans documented and tested for key critical/important services. ## Checklist F - Governance cadence and evidence pack (make compliance sustainable) DORA is not a one-off. Build a cadence that keeps controls and reporting accurate and current. Your objective is to reduce "scramble risk" when supervisors request evidence. - RACI per workstream (controls, incident reporting, testing, third-party governance). - Quarterly review: incident trends, control exceptions, vendor concentration, register accuracy. - Annual review: proportionality decisions, testing program effectiveness, TLPT readiness status. - Evidence repository: versioned policies, procedures, control tests, reports, register exports, management approvals. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary legal text for DORA workstreams: ICT risk management (Chapter II), incident reporting (Chapter III), testing/TLPT (Chapter IV), and ICT third-party risk + register of information (Chapter V). - [Commission Delegated Regulation (EU) 2024/1773 - Contractual arrangements for ICT services supporting critical or important functions (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - Level 2 RTS detailing DORA contractual clause expectations for critical/important ICT services. - [Commission Delegated Regulation (EU) 2024/1774 - ICT risk management tools and simplified framework (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng?ref=sorena.io) - Level 2 RTS specifying ICT risk management tools/methods/processes and the simplified framework. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/checklist --- --- title: "EU DORA Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/dora/checklist" source_url: "https://www.sorena.io/artifacts/eu/dora/checklist" author: "Sorena AI" description: "An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline." keywords: - "EU DORA checklist" - "DORA compliance checklist" - "DORA audit checklist" - "Digital Operational Resilience Act checklist" - "ICT risk management checklist DORA" - "DORA incident reporting checklist" - "TLPT readiness checklist" - "DORA third party risk checklist" - "DORA register of information checklist" - "DORA contract clauses checklist" - "DORA checklist" - "ICT risk management" - "major incident reporting" - "TLPT" - "third-party risk" - "register of information" - "audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DORA Checklist An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. *Checklist* *EU* ## EU DORA Checklist A checklist you can run per entity - and reuse for audits and supervisory requests. Structured the way teams execute: scope -> controls -> reporting -> testing -> third parties -> evidence. DORA compliance is a system rollout. This checklist is built as a program plan you can run per regulated entity and per group layer. For each item: assign an owner, define acceptance criteria, and keep evidence that is exportable and reproducible. ## Checklist A - Scope memo and proportionality (do this before building controls) Your first deliverable should be a scope memo per entity (and a group summary) that maps DORA scope and proportionality to concrete workstreams and owners. This prevents scope drift and mismatched control builds. - Map each legal entity to Article 2 scope category; record competent authority and reporting perimeter. - Document proportionality decisions and any simplified framework usage; record management body approvals. - Identify critical or important functions and top ICT dependencies (including outsourced services). - Define workstreams and owners: ICT risk controls, incident reporting, testing/TLPT, third-party risk + register, governance cadence. - Create an evidence map: where each required artifact lives and how to export it quickly. *Recommended next step* *Placement: after the checklist block* ## Turn EU DORA Checklist into an operational assessment Assessment Autopilot can take EU DORA Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU DORA Checklist](/solutions/assessment.md): Start from EU DORA Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Checklist. ## Checklist B - ICT risk management control baseline (Chapter II + RTS) DORA expects a coherent ICT risk management framework: governance + asset inventory + control layers + continuity + communications. Build this baseline as a control library with acceptance criteria and evidence. - Governance: management body accountability, risk tolerance, and periodic reviews. - Asset inventory and dependency mapping: ICT-supported business functions, information assets, ICT assets, and criticality classification (review at least yearly). - Protection: access control, secure configuration, change management, vulnerability management, backup and resilience patterns for critical services. - Detection: monitoring, alerting, anomaly detection, and log integrity for critical functions. - Response and recovery: runbooks, containment procedures, restore objectives, and post-incident reviews. - Communications: internal escalation, external stakeholder communications, and crisis communications integration. ## Checklist C - Incident management + major incident reporting (Chapter III + RTS) This is both an operational workflow and a data pipeline. Build a repeatable process with structured outputs and QA. Your reporting capability is tested under stress; design it to work during outages. - Incident management process exists (Article 17): early warning indicators, tracking/logging/classification, roles and responsibilities, communications, response procedures. - All ICT incidents and significant cyber threats are recorded consistently; root causes are identified, documented and addressed. - Classification criteria and materiality thresholds are implemented (Article 18 + RTS). - Reporting pipeline can produce: initial notification, intermediate updates, and final report with root cause analysis and actual impact figures (Article 19 + RTS time limits). - Client communications workflow exists for major incidents impacting financial interests. - Evidence: incident register exports, report copies, timestamps, and decision logs. ## Checklist D - Testing program + TLPT readiness (Chapter IV) Testing should be planned, risk-based, and repeatable. TLPT is a specialized program: build the governance and supplier model early. Treat testing outputs as compliance evidence and as engineering backlog inputs. - Testing program (Article 24/25): annual plan, test coverage for critical or important functions, independent testing where required, remediation and validation methodology. - Penetration testing and scenario-based testing are scheduled and evidence retained. - TLPT readiness (Article 26): scoping methodology, production-safe testing controls, and authority interaction plan. - Tester selection and contracts satisfy suitability/independence and confidentiality requirements; professional indemnity coverage verified. - Evidence: test reports, remediation tracking, re-test evidence, management summaries. ## Checklist E - ICT third-party risk: strategy, contracts, concentration, exit, register (Chapter V + RTS) Third-party risk is a top enforcement focus because it compounds operational risk across the sector. Build a vendor governance system that produces contract posture and evidence on demand. - ICT third-party risk strategy exists and is reviewed periodically; includes policy for ICT services supporting critical or important functions (Article 28). - Register of information built and maintained (Article 28): entity + (where relevant) sub-consolidated/consolidated; exportable sections for supervisors. - Concentration/substitutability analysis performed for critical/important ICT services; multi-vendor strategy considered (Article 29). - Contract clause baseline implemented (Article 30 + RTS 2024/1773): audit/access, security, subcontracting transparency, incident cooperation, portability and exit rights. - Exit strategies and transition plans documented and tested for key critical/important services. ## Checklist F - Governance cadence and evidence pack (make compliance sustainable) DORA is not a one-off. Build a cadence that keeps controls and reporting accurate and current. Your objective is to reduce "scramble risk" when supervisors request evidence. - RACI per workstream (controls, incident reporting, testing, third-party governance). - Quarterly review: incident trends, control exceptions, vendor concentration, register accuracy. - Annual review: proportionality decisions, testing program effectiveness, TLPT readiness status. - Evidence repository: versioned policies, procedures, control tests, reports, register exports, management approvals. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary legal text for DORA workstreams: ICT risk management (Chapter II), incident reporting (Chapter III), testing/TLPT (Chapter IV), and ICT third-party risk + register of information (Chapter V). - [Commission Delegated Regulation (EU) 2024/1773 - Contractual arrangements for ICT services supporting critical or important functions (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - Level 2 RTS detailing DORA contractual clause expectations for critical/important ICT services. - [Commission Delegated Regulation (EU) 2024/1774 - ICT risk management tools and simplified framework (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng?ref=sorena.io) - Level 2 RTS specifying ICT risk management tools/methods/processes and the simplified framework. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/checklist --- --- title: "EU DORA Compliance Guide" canonical_url: "https://www.sorena.io/artifacts/eu/dora/compliance" source_url: "https://www.sorena.io/artifacts/eu/dora/compliance" author: "Sorena AI" description: "A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline." keywords: - "EU DORA compliance guide" - "DORA implementation guide" - "DORA compliance program" - "ICT risk management DORA" - "DORA incident reporting implementation" - "TLPT implementation DORA" - "DORA third party risk implementation" - "DORA register of information implementation" - "DORA contract clauses" - "DORA compliance" - "implementation playbook" - "ICT risk management" - "incident reporting" - "TLPT" - "third-party risk" - "register of information" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DORA Compliance Guide A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. *Implementation Guide* *EU* ## EU DORA Compliance Playbook A step-by-step implementation playbook: controls, workflows, evidence and cadence. Designed for regulated entities: legal, security, IT, risk, and vendor management working together. DORA compliance succeeds when it's built as an operating model: a control baseline, a reporting pipeline, a testing program, and a vendor governance system - all tied together by an evidence pack. This playbook is a practical sequence you can execute per entity and scale to group level. ## Step 1 - Lock scope and proportionality (write the scope memo) Start with an entity-by-entity scope memo mapped to Article 2 categories, competent authorities, and group layers. Record proportionality/simplification decisions as management body artifacts and define when they are revisited. - Map each legal entity to Article 2 scope; identify supervisors and reporting routing. - Define critical or important functions and top ICT dependencies (including outsourced services). - Document proportionality decisions: what is simplified and why residual risk is acceptable. - Create the requirements matrix: Article -> obligation -> control -> owner -> evidence. ## Step 2 - Build the ICT risk management control baseline (Chapter II + RTS) Treat Chapter II as a control baseline: you need a coherent set of policies, controls and runbooks that cover the full lifecycle: protect -> detect -> respond -> recover. Define acceptance criteria and evidence for each control family. - Governance: risk tolerance, management body oversight, internal audit and independent reviews. - Asset inventory and classification: ICT-supported business functions, information assets, ICT assets, and dependency mapping (review at least yearly). - Protection controls: identity/access, secure configuration, change management, vulnerability management, backup and resilience patterns for critical functions. - Detection controls: monitoring, logging, anomaly detection, and alert QA for critical services. - Business continuity and recovery: response/recovery plans, switchover tests, restore objectives, and post-incident reviews. ## Step 3 - Ship the core workflow: major ICT incident reporting pipeline (Chapter III + RTS) Major incident reporting is a timed workflow: you need to classify, report, update, and produce a final root cause analysis output. Build it to function during outages: templates, alternate submission paths, and clear roles. - Incident management process (Article 17) implemented: recording, consistent handling, root cause analysis, and prevention improvements. - Classification implemented (Article 18 + RTS): thresholds, cross-border impact logic, and severity model. - Reporting artifacts implemented (Article 19 + RTS): initial notification, intermediate updates, final report; include cross-border impact information. - Client communications: notify clients without undue delay where their financial interests are impacted. - Evidence and QA: logs, timestamps, report copies, and periodic reporting drills. ## Step 4 - Build testing and TLPT readiness as a recurring program (Chapter IV) Testing is not a yearly checkbox. Build a program that generates remediation backlog and evidence. If TLPT is in scope for your entity, build the governance, supplier model and production-safe execution controls early. - Testing program (Articles 24-25): annual plan, coverage for critical/important functions, independent testing where required, remediation and validation methodology. - TLPT (Article 26): scope definition and authority validation process; multi-asset test coverage; production-safe controls. - Tester qualification and contracts (Article 27): suitability, independence, confidentiality, and indemnity. - Evidence: test reports, remediation tracking, retest evidence, and management summaries. ## Step 5 - Operationalize third-party risk: contract posture + register of information (Chapter V + RTS) DORA third-party risk is not a procurement memo. It's contracts, oversight rights, concentration risk analysis, exit planning, and a continuously updated register of information. Make vendor governance produce exportable evidence. - ICT third-party risk strategy and policy for critical/important ICT services exists and is reviewed periodically (Article 28). - Register of information implemented and updated (Article 28): entity and group layers; exportable sections for supervisors. - Concentration/substitutability analysis performed (Article 29), including subcontracting chains and third-country risk considerations. - Contract clause baseline implemented (Article 30 + RTS 2024/1773): audit/access rights, security requirements, incident cooperation, subcontractor transparency, portability and exit rights. - Exit strategies and transition plans documented and tested for high-criticality services. ## Step 6 - Governance cadence, KPIs, and evidence pack (sustaining compliance) DORA compliance is sustained by cadence: quarterly reviews, annual program planning, and evidence retention rules. Your goal is to make regulatory responses predictable and fast. - RACI for each workstream; escalation paths; approval authorities for exceptions. - Quarterly reviews: control exceptions, incident trends, vendor concentration, register accuracy. - Annual planning: testing calendar, TLPT readiness review, incident reporting drills. - Evidence pack: versioned policies, runbooks, logs, reports, test results, register exports, and management body approvals. *Recommended next step* *Placement: after the compliance steps* ## Turn EU DORA Compliance Playbook into an operational assessment Assessment Autopilot can take EU DORA Compliance Playbook from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU DORA Compliance Playbook](/solutions/assessment.md): Start from EU DORA Compliance Playbook and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Compliance Playbook. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary DORA obligations and program structure (Chapters II-V). DORA applies from 17 January 2025 (Article 64). - [Commission Delegated Regulation (EU) 2024/1773 - Contractual arrangements for ICT services supporting critical or important functions (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - Level 2 RTS for DORA contractual clauses: audit/access, security, subcontracting, incident cooperation, exit/portability and more. - [Commission Delegated Regulation (EU) 2024/1774 - ICT risk management tools and simplified framework (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng?ref=sorena.io) - Level 2 RTS that operationalizes the ICT risk management framework and simplified approach. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/compliance --- --- title: "EU DORA Compliance Guide" canonical_url: "https://www.sorena.io/artifacts/eu/dora/compliance" source_url: "https://www.sorena.io/artifacts/eu/dora/compliance" author: "Sorena AI" description: "A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline." keywords: - "EU DORA compliance guide" - "DORA implementation guide" - "DORA compliance program" - "ICT risk management DORA" - "DORA incident reporting implementation" - "TLPT implementation DORA" - "DORA third party risk implementation" - "DORA register of information implementation" - "DORA contract clauses" - "DORA compliance" - "implementation playbook" - "ICT risk management" - "incident reporting" - "TLPT" - "third-party risk" - "register of information" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DORA Compliance Guide A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. *Implementation Guide* *EU* ## EU DORA Compliance Playbook A step-by-step implementation playbook: controls, workflows, evidence and cadence. Designed for regulated entities: legal, security, IT, risk, and vendor management working together. DORA compliance succeeds when it's built as an operating model: a control baseline, a reporting pipeline, a testing program, and a vendor governance system - all tied together by an evidence pack. This playbook is a practical sequence you can execute per entity and scale to group level. ## Step 1 - Lock scope and proportionality (write the scope memo) Start with an entity-by-entity scope memo mapped to Article 2 categories, competent authorities, and group layers. Record proportionality/simplification decisions as management body artifacts and define when they are revisited. - Map each legal entity to Article 2 scope; identify supervisors and reporting routing. - Define critical or important functions and top ICT dependencies (including outsourced services). - Document proportionality decisions: what is simplified and why residual risk is acceptable. - Create the requirements matrix: Article -> obligation -> control -> owner -> evidence. ## Step 2 - Build the ICT risk management control baseline (Chapter II + RTS) Treat Chapter II as a control baseline: you need a coherent set of policies, controls and runbooks that cover the full lifecycle: protect -> detect -> respond -> recover. Define acceptance criteria and evidence for each control family. - Governance: risk tolerance, management body oversight, internal audit and independent reviews. - Asset inventory and classification: ICT-supported business functions, information assets, ICT assets, and dependency mapping (review at least yearly). - Protection controls: identity/access, secure configuration, change management, vulnerability management, backup and resilience patterns for critical functions. - Detection controls: monitoring, logging, anomaly detection, and alert QA for critical services. - Business continuity and recovery: response/recovery plans, switchover tests, restore objectives, and post-incident reviews. ## Step 3 - Ship the core workflow: major ICT incident reporting pipeline (Chapter III + RTS) Major incident reporting is a timed workflow: you need to classify, report, update, and produce a final root cause analysis output. Build it to function during outages: templates, alternate submission paths, and clear roles. - Incident management process (Article 17) implemented: recording, consistent handling, root cause analysis, and prevention improvements. - Classification implemented (Article 18 + RTS): thresholds, cross-border impact logic, and severity model. - Reporting artifacts implemented (Article 19 + RTS): initial notification, intermediate updates, final report; include cross-border impact information. - Client communications: notify clients without undue delay where their financial interests are impacted. - Evidence and QA: logs, timestamps, report copies, and periodic reporting drills. ## Step 4 - Build testing and TLPT readiness as a recurring program (Chapter IV) Testing is not a yearly checkbox. Build a program that generates remediation backlog and evidence. If TLPT is in scope for your entity, build the governance, supplier model and production-safe execution controls early. - Testing program (Articles 24-25): annual plan, coverage for critical/important functions, independent testing where required, remediation and validation methodology. - TLPT (Article 26): scope definition and authority validation process; multi-asset test coverage; production-safe controls. - Tester qualification and contracts (Article 27): suitability, independence, confidentiality, and indemnity. - Evidence: test reports, remediation tracking, retest evidence, and management summaries. ## Step 5 - Operationalize third-party risk: contract posture + register of information (Chapter V + RTS) DORA third-party risk is not a procurement memo. It's contracts, oversight rights, concentration risk analysis, exit planning, and a continuously updated register of information. Make vendor governance produce exportable evidence. - ICT third-party risk strategy and policy for critical/important ICT services exists and is reviewed periodically (Article 28). - Register of information implemented and updated (Article 28): entity and group layers; exportable sections for supervisors. - Concentration/substitutability analysis performed (Article 29), including subcontracting chains and third-country risk considerations. - Contract clause baseline implemented (Article 30 + RTS 2024/1773): audit/access rights, security requirements, incident cooperation, subcontractor transparency, portability and exit rights. - Exit strategies and transition plans documented and tested for high-criticality services. ## Step 6 - Governance cadence, KPIs, and evidence pack (sustaining compliance) DORA compliance is sustained by cadence: quarterly reviews, annual program planning, and evidence retention rules. Your goal is to make regulatory responses predictable and fast. - RACI for each workstream; escalation paths; approval authorities for exceptions. - Quarterly reviews: control exceptions, incident trends, vendor concentration, register accuracy. - Annual planning: testing calendar, TLPT readiness review, incident reporting drills. - Evidence pack: versioned policies, runbooks, logs, reports, test results, register exports, and management body approvals. *Recommended next step* *Placement: after the compliance steps* ## Turn EU DORA Compliance Playbook into an operational assessment Assessment Autopilot can take EU DORA Compliance Playbook from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU DORA Compliance Playbook](/solutions/assessment.md): Start from EU DORA Compliance Playbook and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Compliance Playbook. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary DORA obligations and program structure (Chapters II-V). DORA applies from 17 January 2025 (Article 64). - [Commission Delegated Regulation (EU) 2024/1773 - Contractual arrangements for ICT services supporting critical or important functions (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - Level 2 RTS for DORA contractual clauses: audit/access, security, subcontracting, incident cooperation, exit/portability and more. - [Commission Delegated Regulation (EU) 2024/1774 - ICT risk management tools and simplified framework (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng?ref=sorena.io) - Level 2 RTS that operationalizes the ICT risk management framework and simplified approach. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/compliance --- --- title: "EU DORA Deadlines & Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/dora/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/dora/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301." keywords: - "EU DORA deadlines" - "DORA compliance calendar" - "DORA key dates" - "DORA application date 17 January 2025" - "DORA RTS 2024/1773" - "DORA RTS 2024/1774" - "DORA incidents RTS 2024/1772" - "DORA reporting RTS 2025/301" - "DORA register of information template" - "TLPT frequency every 3 years" - "DORA deadlines" - "RTS" - "ITS" - "TLPT cycle" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DORA Deadlines & Compliance Calendar A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. *Artifact Guide* *EU* ## EU DORA Deadlines & Compliance Calendar Key dates and cadences you can plug into your governance calendar. Includes DORA application date, Level 2 RTS/ITS milestones, and recurring operating cycles. DORA compliance is both a deadline-driven rollout and a recurring operating model. This page lists the most important dates and the cadences teams should implement: incident reporting readiness, testing and TLPT cycles, and continuous third-party governance and register-of-information maintenance. ## Baseline dates: publication, entry into force, and application The DORA Regulation was adopted in December 2022 and published in the Official Journal shortly after. It enters into force 20 days after publication and applies from 17 January 2025. - Official Journal publication: OJ L 333, 27 December 2022. - Entry into force: twentieth day following publication (Article 64). - Application date: 17 January 2025 (Article 64). - Program implication: build your core workflows (incident reporting, register of information, testing cadence) as "run-ready" before the application date. ## Level 2 deliverables: what RTS/ITS change for implementation DORA is implemented through Level 2 technical standards and delegated regulations that specify detailed requirements and templates. Treat Level 2 as implementation spec: it affects forms, time limits, contract clause details, and control baselines. - Incident classification and materiality thresholds: Delegated Regulation (EU) 2024/1772 (RTS). - Contract clauses for critical/important ICT services: Delegated Regulation (EU) 2024/1773 (RTS). - ICT risk management tools and simplified framework: Delegated Regulation (EU) 2024/1774 (RTS). - Incident report content and time limits: Delegated Regulation (EU) 2025/301 (RTS). - Critical ICT provider designation criteria: Delegated Regulation (EU) 2024/1502. - Critical ICT provider oversight fees: Delegated Regulation (EU) 2024/1505. - Register of information templates: Implementing Regulation (EU) 2024/2956 (ITS), published on 29 November 2024. - Standard forms, templates, and procedures for major ICT incident reporting: Implementing Regulation (EU) 2025/302 (ITS). - Subcontracting assessment for ICT services supporting critical or important functions: Delegated Regulation (EU) 2025/532. - Criteria for identifying entities required to perform TLPT: Delegated Regulation (EU) 2025/1190. ## Post-application supervisory milestones that now matter in practice Once DORA applied on 17 January 2025, the focus shifted from legal readiness to supervisor-ready artifacts, templates, and oversight structures. The most important current milestones are the RoI template ITS, the incident-reporting ITS, and the first critical ICT provider designations. - Register of information ITS: Implementing Regulation (EU) 2024/2956, published on 29 November 2024, gives the standard B_01 to B_07 templates used for supervisory submissions. - Incident reporting ITS: Implementing Regulation (EU) 2025/302 sets the standard forms, templates, and procedures for major ICT incident reporting. - Critical ICT third-party provider designations: the ESAs published the first designated CTPP list on 18 November 2025. - Practical implication: firms now need export-ready RoI data, template-ready incident reporting, and vendor-governance playbooks that reflect whether a key provider has been designated as critical. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU DORA Deadlines & Compliance Calendar into an operational assessment Assessment Autopilot can take EU DORA Deadlines & Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU DORA Deadlines & Compliance Calendar](/solutions/assessment.md): Start from EU DORA Deadlines & Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Deadlines & Compliance Calendar. ## Recurring cadence: incident reporting readiness (always-on) Major incident reporting is not "file a report when something happens". It requires a prepared workflow and data model so you can report while systems are degraded. Build a recurring readiness cadence and run periodic drills. - Quarterly reporting drill: simulate a major incident and produce initial/intermediate/final report drafts using your actual data sources. - Metric QA: validate classification thresholds and cross-border impact logic (RTS 2024/1772) and ensure time limits workflows are realistic (RTS 2025/301). - Evidence retention: keep copies of reports, timestamps, and root-cause analysis artifacts. ## Recurring cadence: testing program and TLPT cycle DORA requires a testing program for ICT tools, systems and processes. For certain entities, TLPT must occur at least every three years. Treat testing as a product-quality loop: tests generate remediation backlog and evidence. - Annual testing plan: define scope, independence, and coverage of critical or important functions; include retesting of remediated issues. - TLPT program (where applicable): plan scoping, authority interactions, supplier selection, and production-safe controls well in advance. - Calendar management: reserve time for remediation and validation before audit or supervisory reviews. ## Recurring cadence: third-party governance and register of information Third-party governance is continuous: contracts change, services change, and subcontracting chains evolve. The register of information should be updated as part of procurement, not as an annual scramble. - Monthly/quarterly updates: reconcile new/changed vendor contracts, criticality flags, subcontractors, and service locations into the register. - Contract reviews: ensure DORA RTS clauses remain present in renewals and change orders (RTS 2024/1773). - Exit strategy reviews: periodically test portability, backups, and transition plans for critical/important services. - Supervisory export readiness: ensure you can export the full register or requested sections quickly (Article 28). ## Suggested rollout plan (fast but defensible) If you need a practical rollout plan, run DORA in four tracks with a shared evidence model. This sequencing tends to minimize rework and "late surprises". - Track 1: scope memo + proportionality + requirements matrix. - Track 2: incident management + reporting pipeline (templates, classification, time limits, drills). - Track 3: ICT risk management baseline controls + continuity + monitoring. - Track 4: third-party governance + contract clauses + register-of-information build + exit strategies. - Parallel: testing plan + TLPT readiness program for applicable entities. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - DORA application date (Article 64) and workstream obligations that drive program cadences. - [Commission Delegated Regulation (EU) 2024/1772 - Classification of ICT incidents and cyber threats (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - RTS for incident classification and materiality thresholds used in major incident reporting workflows. - [Commission Delegated Regulation (EU) 2025/301 - Incident reporting content and time limits (RTS)](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng?ref=sorena.io) - RTS specifying content and time limits for initial notifications and reports under DORA incident reporting. - [Commission Delegated Regulation (EU) 2024/1773 - Contractual arrangements for critical/important ICT services (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - RTS specifying contractual arrangements that drive third-party governance and register-of-information fields. - [Commission Implementing Regulation (EU) 2024/2956 - Register of information templates (ITS)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Defines the standard RoI templates used after DORA application, including the B_01 to B_07 structure. - [Commission Implementing Regulation (EU) 2025/302 - Major ICT incident reporting forms and templates (ITS)](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng?ref=sorena.io) - Defines the standard forms, templates, and procedures for reporting major ICT-related incidents. - [ESMA news - ESAs designate critical ICT third-party providers under DORA](https://www.esma.europa.eu/press-news/esma-news/european-supervisory-authorities-designate-critical-ict-third-party-providers?ref=sorena.io) - Confirms the first published list of designated critical ICT third-party providers on 18 November 2025. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/deadlines-and-compliance-calendar --- --- title: "EU DORA Deadlines & Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/dora/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/dora/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301." keywords: - "EU DORA deadlines" - "DORA compliance calendar" - "DORA key dates" - "DORA application date 17 January 2025" - "DORA RTS 2024/1773" - "DORA RTS 2024/1774" - "DORA incidents RTS 2024/1772" - "DORA reporting RTS 2025/301" - "DORA register of information template" - "TLPT frequency every 3 years" - "DORA deadlines" - "RTS" - "ITS" - "TLPT cycle" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DORA Deadlines & Compliance Calendar A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. *Artifact Guide* *EU* ## EU DORA Deadlines & Compliance Calendar Key dates and cadences you can plug into your governance calendar. Includes DORA application date, Level 2 RTS/ITS milestones, and recurring operating cycles. DORA compliance is both a deadline-driven rollout and a recurring operating model. This page lists the most important dates and the cadences teams should implement: incident reporting readiness, testing and TLPT cycles, and continuous third-party governance and register-of-information maintenance. ## Baseline dates: publication, entry into force, and application The DORA Regulation was adopted in December 2022 and published in the Official Journal shortly after. It enters into force 20 days after publication and applies from 17 January 2025. - Official Journal publication: OJ L 333, 27 December 2022. - Entry into force: twentieth day following publication (Article 64). - Application date: 17 January 2025 (Article 64). - Program implication: build your core workflows (incident reporting, register of information, testing cadence) as "run-ready" before the application date. ## Level 2 deliverables: what RTS/ITS change for implementation DORA is implemented through Level 2 technical standards and delegated regulations that specify detailed requirements and templates. Treat Level 2 as implementation spec: it affects forms, time limits, contract clause details, and control baselines. - Incident classification and materiality thresholds: Delegated Regulation (EU) 2024/1772 (RTS). - Contract clauses for critical/important ICT services: Delegated Regulation (EU) 2024/1773 (RTS). - ICT risk management tools and simplified framework: Delegated Regulation (EU) 2024/1774 (RTS). - Incident report content and time limits: Delegated Regulation (EU) 2025/301 (RTS). - Critical ICT provider designation criteria: Delegated Regulation (EU) 2024/1502. - Critical ICT provider oversight fees: Delegated Regulation (EU) 2024/1505. - Register of information templates: Implementing Regulation (EU) 2024/2956 (ITS), published on 29 November 2024. - Standard forms, templates, and procedures for major ICT incident reporting: Implementing Regulation (EU) 2025/302 (ITS). - Subcontracting assessment for ICT services supporting critical or important functions: Delegated Regulation (EU) 2025/532. - Criteria for identifying entities required to perform TLPT: Delegated Regulation (EU) 2025/1190. ## Post-application supervisory milestones that now matter in practice Once DORA applied on 17 January 2025, the focus shifted from legal readiness to supervisor-ready artifacts, templates, and oversight structures. The most important current milestones are the RoI template ITS, the incident-reporting ITS, and the first critical ICT provider designations. - Register of information ITS: Implementing Regulation (EU) 2024/2956, published on 29 November 2024, gives the standard B_01 to B_07 templates used for supervisory submissions. - Incident reporting ITS: Implementing Regulation (EU) 2025/302 sets the standard forms, templates, and procedures for major ICT incident reporting. - Critical ICT third-party provider designations: the ESAs published the first designated CTPP list on 18 November 2025. - Practical implication: firms now need export-ready RoI data, template-ready incident reporting, and vendor-governance playbooks that reflect whether a key provider has been designated as critical. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU DORA Deadlines & Compliance Calendar into an operational assessment Assessment Autopilot can take EU DORA Deadlines & Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU DORA Deadlines & Compliance Calendar](/solutions/assessment.md): Start from EU DORA Deadlines & Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Deadlines & Compliance Calendar. ## Recurring cadence: incident reporting readiness (always-on) Major incident reporting is not "file a report when something happens". It requires a prepared workflow and data model so you can report while systems are degraded. Build a recurring readiness cadence and run periodic drills. - Quarterly reporting drill: simulate a major incident and produce initial/intermediate/final report drafts using your actual data sources. - Metric QA: validate classification thresholds and cross-border impact logic (RTS 2024/1772) and ensure time limits workflows are realistic (RTS 2025/301). - Evidence retention: keep copies of reports, timestamps, and root-cause analysis artifacts. ## Recurring cadence: testing program and TLPT cycle DORA requires a testing program for ICT tools, systems and processes. For certain entities, TLPT must occur at least every three years. Treat testing as a product-quality loop: tests generate remediation backlog and evidence. - Annual testing plan: define scope, independence, and coverage of critical or important functions; include retesting of remediated issues. - TLPT program (where applicable): plan scoping, authority interactions, supplier selection, and production-safe controls well in advance. - Calendar management: reserve time for remediation and validation before audit or supervisory reviews. ## Recurring cadence: third-party governance and register of information Third-party governance is continuous: contracts change, services change, and subcontracting chains evolve. The register of information should be updated as part of procurement, not as an annual scramble. - Monthly/quarterly updates: reconcile new/changed vendor contracts, criticality flags, subcontractors, and service locations into the register. - Contract reviews: ensure DORA RTS clauses remain present in renewals and change orders (RTS 2024/1773). - Exit strategy reviews: periodically test portability, backups, and transition plans for critical/important services. - Supervisory export readiness: ensure you can export the full register or requested sections quickly (Article 28). ## Suggested rollout plan (fast but defensible) If you need a practical rollout plan, run DORA in four tracks with a shared evidence model. This sequencing tends to minimize rework and "late surprises". - Track 1: scope memo + proportionality + requirements matrix. - Track 2: incident management + reporting pipeline (templates, classification, time limits, drills). - Track 3: ICT risk management baseline controls + continuity + monitoring. - Track 4: third-party governance + contract clauses + register-of-information build + exit strategies. - Parallel: testing plan + TLPT readiness program for applicable entities. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - DORA application date (Article 64) and workstream obligations that drive program cadences. - [Commission Delegated Regulation (EU) 2024/1772 - Classification of ICT incidents and cyber threats (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - RTS for incident classification and materiality thresholds used in major incident reporting workflows. - [Commission Delegated Regulation (EU) 2025/301 - Incident reporting content and time limits (RTS)](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng?ref=sorena.io) - RTS specifying content and time limits for initial notifications and reports under DORA incident reporting. - [Commission Delegated Regulation (EU) 2024/1773 - Contractual arrangements for critical/important ICT services (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - RTS specifying contractual arrangements that drive third-party governance and register-of-information fields. - [Commission Implementing Regulation (EU) 2024/2956 - Register of information templates (ITS)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Defines the standard RoI templates used after DORA application, including the B_01 to B_07 structure. - [Commission Implementing Regulation (EU) 2025/302 - Major ICT incident reporting forms and templates (ITS)](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng?ref=sorena.io) - Defines the standard forms, templates, and procedures for reporting major ICT-related incidents. - [ESMA news - ESAs designate critical ICT third-party providers under DORA](https://www.esma.europa.eu/press-news/esma-news/european-supervisory-authorities-designate-critical-ict-third-party-providers?ref=sorena.io) - Confirms the first published list of designated critical ICT third-party providers on 18 November 2025. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/deadlines-and-compliance-calendar --- --- title: "DORA Register of Information (RoI) Template Guide" canonical_url: "https://www.sorena.io/artifacts/eu/dora/dora-register-of-information-template" source_url: "https://www.sorena.io/artifacts/eu/dora/dora-register-of-information-template" author: "Sorena AI" description: "A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956)." keywords: - "DORA register of information template" - "ITS 2024/2956 register templates" - "DORA RoI template B_01 B_02 B_03 B_04 B_05 B_06 B_07" - "DORA register of information schema" - "DORA outsourcing register template" - "DORA ICT third party register template" - "register of information template" - "ITS 2024/2956" - "B_01 B_02 B_03 B_04 B_05 B_06 B_07" - "relational keys" - "outsourcing register" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA Register of Information (RoI) Template Guide A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). *Template Guide* *EU* ## EU DORA RoI Template Guide Implement the ITS annex templates as a relational schema with stable identifiers and fast exports. Grounded in Implementing Regulation (EU) 2024/2956 (standard templates for the register of information). Implementing Regulation (EU) 2024/2956 defines standard templates for the DORA register of information and describes a relational structure that links open tables via specific keys (contract reference numbers, function identifiers, LEIs, provider identifiers). The fastest path to compliance is to treat the annex templates as a schema contract: define your identifiers, enforce referential integrity, and generate exports automatically - so you can produce supervisor-ready templates on demand. ## What the ITS templates are for (and why they're relational) The ITS templates enable consistent understanding of ICT dependencies across firms and groups, and they support effective supervision and oversight of critical ICT third-party providers. The ITS uses open tables (fixed columns, unlimited rows) and explicit relational keys to avoid ambiguous, non-comparable narrative registers. - Build once, export many: a governed dataset + exporter beats manual spreadsheet updates. - Identifier discipline is non-negotiable: contract reference numbers and function IDs must be stable and consistent. - Data quality is part of compliance: accuracy, consistency, regular review, and prompt error correction are explicit expectations. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU DORA RoI Template Guide in one governed evidence system SSOT can take EU DORA RoI Template Guide from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU DORA RoI Template Guide](/solutions/ssot.md): Start from EU DORA RoI Template Guide and keep documents, evidence, and control records in one governed system. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA RoI Template Guide. ## Template map (B_01-B_07) - a workable mental model The annex templates cover: reporting perimeter, contractual arrangements, signatories, providers, usage, supply chain, functions, and criticality assessment. Treat templates as views over one normalized model; avoid duplicating the same facts across multiple tables. - B_01.*: reporting perimeter (entity, consolidation, branches outside home country). - B_02.*: contractual arrangements (general + specific details + intra-group reconciliation where applicable). - B_03.*: parties who sign (contracting entities, direct ICT provider signatories, intra-group signatories). - B_04.*: entities using ICT services (consumption mapping). - B_05.*: providers + subcontractors and ICT service supply chain links. - B_06.*: function identification catalog (function IDs and descriptions). - B_07.*: assessment of ICT services supporting critical/important functions (or material parts thereof). ## Relational keys (define these first or exports will never reconcile) The ITS stresses identifier consistency (contract reference numbers, function identifiers, LEIs/provider identifiers) to ensure operability and comparability. Define these centrally, make them immutable, and validate them before every export. - Contractual arrangement reference number: immutable primary key for contractual arrangements (join backbone). - Function identifier: stable function catalog used for critical/important mapping and cross-template joins. - LEI/EUID: use valid and active LEIs where required; capture EUID where applicable and normalize provider identities. - Supply chain linkage keys: represent direct providers, intra-group providers, and external subcontractors consistently. ## Data quality rules (make "export-ready" a measurable state) Export readiness is not a feeling - it's a set of checks. Build a validation layer that blocks exports when joins or required fields fail. This turns RoI maintenance into a continuous-control process rather than a yearly scramble. - Completeness: required fields present for all contracts supporting critical/important functions and their underpinning supply chain. - Referential integrity: every foreign key resolves (contract->provider, contract->users, service->function, service->subcontractors). - Uniqueness: no duplicated/reused contract reference numbers, function IDs, or provider IDs across the reporting perimeter. - Consistency across levels: entity vs consolidated exports reconcile without conflicting identifiers. - Review cadence: evidence of regular review and prompt correction of discrepancies (audit trail). ## Why RoI data quality now has direct supervisory consequences The register of information is not just an internal inventory. The ESAs used RoI data from financial entities as part of the process that led to the first DORA critical ICT third-party provider designations. That means inconsistent identifiers, missing subcontractors, or weak critical-function mapping do not just create an internal cleanup problem. They affect how supervisors understand concentration and systemic dependency. - The first designated critical ICT third-party provider list was published on 18 November 2025. - Use that milestone as a quality threshold: your RoI should support provider concentration analysis, critical-function mapping, and group-level consistency without manual repair. - If a key provider becomes designated as critical, make sure your RoI, contract posture, monitoring, and exit planning all reconcile to the same provider and contract identifiers. ## Implementation checklist (fast path) Use this to implement quickly without building a brittle solution. Aim for a minimal viable RoI in 2-6 weeks, then iterate for coverage and automation. - Define identifier policy (contract reference numbers, function IDs, provider identity normalization). - Map service catalog -> functions and tag critical/important services (with approvals). - Integrate contract repository + procurement + vendor risk + CMDB/cloud inventory into one model. - Generate B_01-B_07 exports and run validation checks; fix root causes, not export outputs. - Run quarterly RoI drills: produce exports and answer supervisor-style questions from the dataset. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Article 28 establishes the register of information obligation and the ability for competent authorities to request the full register or specific sections. - [Commission Implementing Regulation (EU) 2024/2956 - Standard templates for the register of information (ITS)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Defines Annex templates (B_01-B_07), relational keys, and data quality expectations for maintaining and updating the register. - [ESMA news - ESAs designate critical ICT third-party providers under DORA](https://www.esma.europa.eu/press-news/esma-news/european-supervisory-authorities-designate-critical-ict-third-party-providers?ref=sorena.io) - Shows that RoI data feeds real supervisory decisions on critical ICT third-party provider designations. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/dora-register-of-information-template --- --- title: "DORA Register of Information (RoI) Template Guide" canonical_url: "https://www.sorena.io/artifacts/eu/dora/dora-register-of-information-template" source_url: "https://www.sorena.io/artifacts/eu/dora/dora-register-of-information-template" author: "Sorena AI" description: "A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956)." keywords: - "DORA register of information template" - "ITS 2024/2956 register templates" - "DORA RoI template B_01 B_02 B_03 B_04 B_05 B_06 B_07" - "DORA register of information schema" - "DORA outsourcing register template" - "DORA ICT third party register template" - "register of information template" - "ITS 2024/2956" - "B_01 B_02 B_03 B_04 B_05 B_06 B_07" - "relational keys" - "outsourcing register" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA Register of Information (RoI) Template Guide A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). *Template Guide* *EU* ## EU DORA RoI Template Guide Implement the ITS annex templates as a relational schema with stable identifiers and fast exports. Grounded in Implementing Regulation (EU) 2024/2956 (standard templates for the register of information). Implementing Regulation (EU) 2024/2956 defines standard templates for the DORA register of information and describes a relational structure that links open tables via specific keys (contract reference numbers, function identifiers, LEIs, provider identifiers). The fastest path to compliance is to treat the annex templates as a schema contract: define your identifiers, enforce referential integrity, and generate exports automatically - so you can produce supervisor-ready templates on demand. ## What the ITS templates are for (and why they're relational) The ITS templates enable consistent understanding of ICT dependencies across firms and groups, and they support effective supervision and oversight of critical ICT third-party providers. The ITS uses open tables (fixed columns, unlimited rows) and explicit relational keys to avoid ambiguous, non-comparable narrative registers. - Build once, export many: a governed dataset + exporter beats manual spreadsheet updates. - Identifier discipline is non-negotiable: contract reference numbers and function IDs must be stable and consistent. - Data quality is part of compliance: accuracy, consistency, regular review, and prompt error correction are explicit expectations. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU DORA RoI Template Guide in one governed evidence system SSOT can take EU DORA RoI Template Guide from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU DORA RoI Template Guide](/solutions/ssot.md): Start from EU DORA RoI Template Guide and keep documents, evidence, and control records in one governed system. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA RoI Template Guide. ## Template map (B_01-B_07) - a workable mental model The annex templates cover: reporting perimeter, contractual arrangements, signatories, providers, usage, supply chain, functions, and criticality assessment. Treat templates as views over one normalized model; avoid duplicating the same facts across multiple tables. - B_01.*: reporting perimeter (entity, consolidation, branches outside home country). - B_02.*: contractual arrangements (general + specific details + intra-group reconciliation where applicable). - B_03.*: parties who sign (contracting entities, direct ICT provider signatories, intra-group signatories). - B_04.*: entities using ICT services (consumption mapping). - B_05.*: providers + subcontractors and ICT service supply chain links. - B_06.*: function identification catalog (function IDs and descriptions). - B_07.*: assessment of ICT services supporting critical/important functions (or material parts thereof). ## Relational keys (define these first or exports will never reconcile) The ITS stresses identifier consistency (contract reference numbers, function identifiers, LEIs/provider identifiers) to ensure operability and comparability. Define these centrally, make them immutable, and validate them before every export. - Contractual arrangement reference number: immutable primary key for contractual arrangements (join backbone). - Function identifier: stable function catalog used for critical/important mapping and cross-template joins. - LEI/EUID: use valid and active LEIs where required; capture EUID where applicable and normalize provider identities. - Supply chain linkage keys: represent direct providers, intra-group providers, and external subcontractors consistently. ## Data quality rules (make "export-ready" a measurable state) Export readiness is not a feeling - it's a set of checks. Build a validation layer that blocks exports when joins or required fields fail. This turns RoI maintenance into a continuous-control process rather than a yearly scramble. - Completeness: required fields present for all contracts supporting critical/important functions and their underpinning supply chain. - Referential integrity: every foreign key resolves (contract->provider, contract->users, service->function, service->subcontractors). - Uniqueness: no duplicated/reused contract reference numbers, function IDs, or provider IDs across the reporting perimeter. - Consistency across levels: entity vs consolidated exports reconcile without conflicting identifiers. - Review cadence: evidence of regular review and prompt correction of discrepancies (audit trail). ## Why RoI data quality now has direct supervisory consequences The register of information is not just an internal inventory. The ESAs used RoI data from financial entities as part of the process that led to the first DORA critical ICT third-party provider designations. That means inconsistent identifiers, missing subcontractors, or weak critical-function mapping do not just create an internal cleanup problem. They affect how supervisors understand concentration and systemic dependency. - The first designated critical ICT third-party provider list was published on 18 November 2025. - Use that milestone as a quality threshold: your RoI should support provider concentration analysis, critical-function mapping, and group-level consistency without manual repair. - If a key provider becomes designated as critical, make sure your RoI, contract posture, monitoring, and exit planning all reconcile to the same provider and contract identifiers. ## Implementation checklist (fast path) Use this to implement quickly without building a brittle solution. Aim for a minimal viable RoI in 2-6 weeks, then iterate for coverage and automation. - Define identifier policy (contract reference numbers, function IDs, provider identity normalization). - Map service catalog -> functions and tag critical/important services (with approvals). - Integrate contract repository + procurement + vendor risk + CMDB/cloud inventory into one model. - Generate B_01-B_07 exports and run validation checks; fix root causes, not export outputs. - Run quarterly RoI drills: produce exports and answer supervisor-style questions from the dataset. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Article 28 establishes the register of information obligation and the ability for competent authorities to request the full register or specific sections. - [Commission Implementing Regulation (EU) 2024/2956 - Standard templates for the register of information (ITS)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Defines Annex templates (B_01-B_07), relational keys, and data quality expectations for maintaining and updating the register. - [ESMA news - ESAs designate critical ICT third-party providers under DORA](https://www.esma.europa.eu/press-news/esma-news/european-supervisory-authorities-designate-critical-ict-third-party-providers?ref=sorena.io) - Shows that RoI data feeds real supervisory decisions on critical ICT third-party provider designations. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/dora-register-of-information-template --- --- title: "DORA vs ISO/IEC 27001:2022" canonical_url: "https://www.sorena.io/artifacts/eu/dora/dora-vs-iso-27001" source_url: "https://www.sorena.io/artifacts/eu/dora/dora-vs-iso-27001" author: "Sorena AI" description: "A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations." keywords: - "DORA vs ISO 27001" - "ISO 27001 DORA mapping" - "ISO/IEC 27001:2022 DORA compliance" - "DORA ISMS" - "DORA audit readiness ISO 27001" - "DORA ICT risk management ISO 27001" - "DORA register of information ISO 27001" - "DORA TLPT ISO 27001" - "ISO/IEC 27001:2022" - "ISMS" - "audit readiness" - "evidence mapping" - "operational resilience" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA vs ISO/IEC 27001:2022 A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. *Comparison* *EU* ## EU DORA DORA vs ISO 27001 Use ISO 27001 as the management system backbone - then add DORA-specific reporting, RoI, and resilience testing. Map controls and evidence once, generate two audit views. ISO/IEC 27001:2022 is an information security management system (ISMS) standard that helps you run a repeatable risk and control program with auditability. DORA is an EU regulation that adds prescriptive operational resilience obligations for financial entities: structured incident reporting, ICT third-party dependency transparency (RoI), oversight expectations, and advanced testing (including TLPT in certain cases). The efficient approach is: ISO 27001 for the management system, DORA for the sector-specific "must ship" capabilities. ## What maps well (ISO 27001 as the operating system) ISO 27001 gives you the governance spine: risk assessment, control operation, internal audit, management review, and continual improvement. Those mechanisms translate well to DORA's expectation that ICT risk management is systematic, measured, and evidence-backed. - Risk management lifecycle: risk assessment, treatment plans, and acceptance decisions. - Policy system and control objectives with evidence trails (procedures, logs, test results). - Assurance cadence: internal audits, corrective actions, and management review outputs. ## Where DORA goes beyond ISO 27001 (DORA-specific deliverables) DORA includes operational resilience deliverables that are not "automatic" outcomes of an ISMS audit. You can still leverage ISO controls, but you must implement DORA-specific workflows, templates, and supervisory artifacts. - Major incident reporting: classification logic + staged regulatory reports with time limits and specified content (RTS/ITS). - Register of information: exportable RoI templates for ICT third-party contractual arrangements (Article 28 + ITS 2024/2956). - Third-party contracting clauses and subcontracting assessment (RTS 2024/1773 + RTS 2025/532). - Advanced testing: scenario-based testing and TLPT readiness where applicable (TLPT RTS and ECB TIBER-EU framework context). ## Practical mapping approach (build once, audit twice) Build a control-to-obligation mapping matrix and reuse evidence where it truly matches DORA intent and outputs. Treat gaps as product work: reporting pipeline, RoI exporter, testing program - and track them like engineering deliverables. - Map ISO controls -> DORA requirements and Level 2 RTS/ITS outputs where relevant. - Define DORA-only controls (RoI exports, regulator reporting templates/time limits, critical provider oversight readiness). - Create an evidence index: every DORA requirement points to a system-of-record artifact and a validation/test. ## Evidence pack strategy (what to show, not just what to say) ISO audits often accept "process + sampling". DORA supervision often asks for operational proof under stress: what happens during outages, what you report, and how you know the supply chain. Upgrade your evidence pack to be exportable and reproducible. - Incident reporting: classification decision logs + submitted reports + submission receipts + post-incident learning closure. - Third-party: clause mapping (RTS 2024/1773), subcontracting assessments (RTS 2025/532), and exit plan feasibility tests. - RoI: validated ITS exports (B_01-B_07) with stable identifiers and consolidation consistency. - Testing: results from resilience testing and TLPT readiness artifacts (where applicable). *Recommended next step* *Placement: after the comparison section* ## Use EU DORA DORA vs ISO 27001 as a cited research workflow Research Copilot can take EU DORA DORA vs ISO 27001 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU DORA DORA vs ISO 27001](/solutions/research-copilot.md): Start from EU DORA DORA vs ISO 27001 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA DORA vs ISO 27001. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - DORA obligations for ICT risk management, incident reporting, third-party risk, testing, and supervisory artifacts. - [ISO/IEC 27001:2022 - ISO](https://www.iso.org/standard/27001?ref=sorena.io) - ISO 27001 is an ISMS standard that provides governance and auditability foundations that can support DORA evidence expectations. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/dora-vs-iso-27001 --- --- title: "DORA vs ISO/IEC 27001:2022" canonical_url: "https://www.sorena.io/artifacts/eu/dora/dora-vs-iso-27001" source_url: "https://www.sorena.io/artifacts/eu/dora/dora-vs-iso-27001" author: "Sorena AI" description: "A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations." keywords: - "DORA vs ISO 27001" - "ISO 27001 DORA mapping" - "ISO/IEC 27001:2022 DORA compliance" - "DORA ISMS" - "DORA audit readiness ISO 27001" - "DORA ICT risk management ISO 27001" - "DORA register of information ISO 27001" - "DORA TLPT ISO 27001" - "ISO/IEC 27001:2022" - "ISMS" - "audit readiness" - "evidence mapping" - "operational resilience" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA vs ISO/IEC 27001:2022 A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. *Comparison* *EU* ## EU DORA DORA vs ISO 27001 Use ISO 27001 as the management system backbone - then add DORA-specific reporting, RoI, and resilience testing. Map controls and evidence once, generate two audit views. ISO/IEC 27001:2022 is an information security management system (ISMS) standard that helps you run a repeatable risk and control program with auditability. DORA is an EU regulation that adds prescriptive operational resilience obligations for financial entities: structured incident reporting, ICT third-party dependency transparency (RoI), oversight expectations, and advanced testing (including TLPT in certain cases). The efficient approach is: ISO 27001 for the management system, DORA for the sector-specific "must ship" capabilities. ## What maps well (ISO 27001 as the operating system) ISO 27001 gives you the governance spine: risk assessment, control operation, internal audit, management review, and continual improvement. Those mechanisms translate well to DORA's expectation that ICT risk management is systematic, measured, and evidence-backed. - Risk management lifecycle: risk assessment, treatment plans, and acceptance decisions. - Policy system and control objectives with evidence trails (procedures, logs, test results). - Assurance cadence: internal audits, corrective actions, and management review outputs. ## Where DORA goes beyond ISO 27001 (DORA-specific deliverables) DORA includes operational resilience deliverables that are not "automatic" outcomes of an ISMS audit. You can still leverage ISO controls, but you must implement DORA-specific workflows, templates, and supervisory artifacts. - Major incident reporting: classification logic + staged regulatory reports with time limits and specified content (RTS/ITS). - Register of information: exportable RoI templates for ICT third-party contractual arrangements (Article 28 + ITS 2024/2956). - Third-party contracting clauses and subcontracting assessment (RTS 2024/1773 + RTS 2025/532). - Advanced testing: scenario-based testing and TLPT readiness where applicable (TLPT RTS and ECB TIBER-EU framework context). ## Practical mapping approach (build once, audit twice) Build a control-to-obligation mapping matrix and reuse evidence where it truly matches DORA intent and outputs. Treat gaps as product work: reporting pipeline, RoI exporter, testing program - and track them like engineering deliverables. - Map ISO controls -> DORA requirements and Level 2 RTS/ITS outputs where relevant. - Define DORA-only controls (RoI exports, regulator reporting templates/time limits, critical provider oversight readiness). - Create an evidence index: every DORA requirement points to a system-of-record artifact and a validation/test. ## Evidence pack strategy (what to show, not just what to say) ISO audits often accept "process + sampling". DORA supervision often asks for operational proof under stress: what happens during outages, what you report, and how you know the supply chain. Upgrade your evidence pack to be exportable and reproducible. - Incident reporting: classification decision logs + submitted reports + submission receipts + post-incident learning closure. - Third-party: clause mapping (RTS 2024/1773), subcontracting assessments (RTS 2025/532), and exit plan feasibility tests. - RoI: validated ITS exports (B_01-B_07) with stable identifiers and consolidation consistency. - Testing: results from resilience testing and TLPT readiness artifacts (where applicable). *Recommended next step* *Placement: after the comparison section* ## Use EU DORA DORA vs ISO 27001 as a cited research workflow Research Copilot can take EU DORA DORA vs ISO 27001 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU DORA DORA vs ISO 27001](/solutions/research-copilot.md): Start from EU DORA DORA vs ISO 27001 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA DORA vs ISO 27001. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - DORA obligations for ICT risk management, incident reporting, third-party risk, testing, and supervisory artifacts. - [ISO/IEC 27001:2022 - ISO](https://www.iso.org/standard/27001?ref=sorena.io) - ISO 27001 is an ISMS standard that provides governance and auditability foundations that can support DORA evidence expectations. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/dora-vs-iso-27001 --- --- title: "DORA vs NIS2 (EU)" canonical_url: "https://www.sorena.io/artifacts/eu/dora/dora-vs-nis2" source_url: "https://www.sorena.io/artifacts/eu/dora/dora-vs-nis2" author: "Sorena AI" description: "A deep comparison of DORA and NIS2: who is in scope, what \"security measures\" mean, incident reporting differences, governance and enforcement posture." keywords: - "DORA vs NIS2" - "NIS2 vs DORA differences" - "DORA incident reporting vs NIS2 reporting" - "DORA ICT risk management vs NIS2 measures" - "financial sector DORA NIS2 overlap" - "DORA NIS2 compliance mapping" - "NIS2 incident reporting" - "DORA incident reporting" - "ICT risk management" - "third party risk" - "EU cybersecurity compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA vs NIS2 (EU) A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. *Comparison* *EU* ## EU DORA DORA vs NIS2 Build one cyber resilience operating model that satisfies both regimes without duplicate controls. Grounded in DORA (Regulation (EU) 2022/2554) and NIS2 (Directive (EU) 2022/2555). DORA is a sector-specific EU regulation for the financial sector focused on digital operational resilience (detailed controls, testing expectations, third-party dependency transparency, and structured incident reporting). NIS2 is an EU cybersecurity directive setting cross-sector baseline risk-management and reporting requirements through national transposition. Many organizations will interact with both regimes directly or indirectly. The right goal is not two programs - it's one control system with two evidence views. ## High-level differences (what to remember) DORA is a regulation that applies directly and is prescriptive for financial entities, including structured reporting, testing expectations, and a register of ICT third-party dependencies. NIS2 is a directive implemented through national law and applies to essential/important entities across many sectors; it sets baseline measures and reporting, with national process differences. - DORA goes deeper on operational resilience mechanics: control baseline, testing/TLPT, and ICT third-party oversight. - NIS2 emphasizes organizational measures, incident reporting to national authorities, and national enforcement mechanics. - Overlap lives in: governance, risk management measures, incident response/reporting workflows, and evidence discipline. *Recommended next step* *Placement: after the comparison section* ## Use EU DORA DORA vs NIS2 as a cited research workflow Research Copilot can take EU DORA DORA vs NIS2 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU DORA DORA vs NIS2](/solutions/research-copilot.md): Start from EU DORA DORA vs NIS2 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA DORA vs NIS2. ## Incident reporting: unify the workflow, customize the outputs Both regimes require incident reporting, but triggers, report stages, templates, and timelines are not identical. The compliance-friendly approach: build one incident data model and workflow, then generate regime-specific outputs (DORA templates vs NIS2 national portals). - One classification decision log that can justify "major" vs "reportable" decisions under each regime. - One reporting data schema (impact, timelines, affected services, dependencies) feeding both DORA and NIS2 reporting outputs. - One evidence pack: incident records, communications, post-incident reviews, and preventive improvements. ## Third-party risk and supply chain (DORA is typically stricter for finance) DORA explicitly requires an ICT third-party risk strategy and a register of information, and it establishes an EU oversight framework for critical ICT providers. NIS2 also addresses supply chain security, but the operationalization is often less template-driven than DORA. - Use DORA-grade contracting for ICT services supporting critical/important functions: audit/access rights, monitoring KPIs, and exit plans (RTS 2024/1773). - Maintain the RoI as a relational dataset you can export on request (Article 28 + ITS 2024/2956). - Adopt a single "supplier assurance" control set with regime-specific evidence mapping. ## Practical mapping checklist (one operating model) Use this checklist to design a combined program without duplicating controls. Build one control system, then map it to regime-specific requirements and reporting outputs. - Governance: management accountability, risk ownership, and measured control outcomes. - Controls: ICT risk management baseline + monitoring + secure change + BCP/DR testing evidence. - Reporting: single incident workflow + data model; DORA template outputs; NIS2 national reporting outputs. - Third-party: clause library + subcontracting governance; supplier assurance program; RoI exports. - Assurance: audit-ready evidence index and periodic readiness drills. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - DORA requirements for ICT risk management, incident reporting, third-party risk, testing, and cooperation provisions with NIS2 structures (Article 47). - [Directive (EU) 2022/2555 (NIS2) - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - NIS2 baseline cybersecurity risk-management and reporting framework (implemented via national transposition). ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/dora-vs-nis2 --- --- title: "DORA vs NIS2 (EU)" canonical_url: "https://www.sorena.io/artifacts/eu/dora/dora-vs-nis2" source_url: "https://www.sorena.io/artifacts/eu/dora/dora-vs-nis2" author: "Sorena AI" description: "A deep comparison of DORA and NIS2: who is in scope, what \"security measures\" mean, incident reporting differences, governance and enforcement posture." keywords: - "DORA vs NIS2" - "NIS2 vs DORA differences" - "DORA incident reporting vs NIS2 reporting" - "DORA ICT risk management vs NIS2 measures" - "financial sector DORA NIS2 overlap" - "DORA NIS2 compliance mapping" - "NIS2 incident reporting" - "DORA incident reporting" - "ICT risk management" - "third party risk" - "EU cybersecurity compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA vs NIS2 (EU) A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. *Comparison* *EU* ## EU DORA DORA vs NIS2 Build one cyber resilience operating model that satisfies both regimes without duplicate controls. Grounded in DORA (Regulation (EU) 2022/2554) and NIS2 (Directive (EU) 2022/2555). DORA is a sector-specific EU regulation for the financial sector focused on digital operational resilience (detailed controls, testing expectations, third-party dependency transparency, and structured incident reporting). NIS2 is an EU cybersecurity directive setting cross-sector baseline risk-management and reporting requirements through national transposition. Many organizations will interact with both regimes directly or indirectly. The right goal is not two programs - it's one control system with two evidence views. ## High-level differences (what to remember) DORA is a regulation that applies directly and is prescriptive for financial entities, including structured reporting, testing expectations, and a register of ICT third-party dependencies. NIS2 is a directive implemented through national law and applies to essential/important entities across many sectors; it sets baseline measures and reporting, with national process differences. - DORA goes deeper on operational resilience mechanics: control baseline, testing/TLPT, and ICT third-party oversight. - NIS2 emphasizes organizational measures, incident reporting to national authorities, and national enforcement mechanics. - Overlap lives in: governance, risk management measures, incident response/reporting workflows, and evidence discipline. *Recommended next step* *Placement: after the comparison section* ## Use EU DORA DORA vs NIS2 as a cited research workflow Research Copilot can take EU DORA DORA vs NIS2 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU DORA DORA vs NIS2](/solutions/research-copilot.md): Start from EU DORA DORA vs NIS2 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA DORA vs NIS2. ## Incident reporting: unify the workflow, customize the outputs Both regimes require incident reporting, but triggers, report stages, templates, and timelines are not identical. The compliance-friendly approach: build one incident data model and workflow, then generate regime-specific outputs (DORA templates vs NIS2 national portals). - One classification decision log that can justify "major" vs "reportable" decisions under each regime. - One reporting data schema (impact, timelines, affected services, dependencies) feeding both DORA and NIS2 reporting outputs. - One evidence pack: incident records, communications, post-incident reviews, and preventive improvements. ## Third-party risk and supply chain (DORA is typically stricter for finance) DORA explicitly requires an ICT third-party risk strategy and a register of information, and it establishes an EU oversight framework for critical ICT providers. NIS2 also addresses supply chain security, but the operationalization is often less template-driven than DORA. - Use DORA-grade contracting for ICT services supporting critical/important functions: audit/access rights, monitoring KPIs, and exit plans (RTS 2024/1773). - Maintain the RoI as a relational dataset you can export on request (Article 28 + ITS 2024/2956). - Adopt a single "supplier assurance" control set with regime-specific evidence mapping. ## Practical mapping checklist (one operating model) Use this checklist to design a combined program without duplicating controls. Build one control system, then map it to regime-specific requirements and reporting outputs. - Governance: management accountability, risk ownership, and measured control outcomes. - Controls: ICT risk management baseline + monitoring + secure change + BCP/DR testing evidence. - Reporting: single incident workflow + data model; DORA template outputs; NIS2 national reporting outputs. - Third-party: clause library + subcontracting governance; supplier assurance program; RoI exports. - Assurance: audit-ready evidence index and periodic readiness drills. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - DORA requirements for ICT risk management, incident reporting, third-party risk, testing, and cooperation provisions with NIS2 structures (Article 47). - [Directive (EU) 2022/2555 (NIS2) - Official Journal](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - NIS2 baseline cybersecurity risk-management and reporting framework (implemented via national transposition). ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/dora-vs-nis2 --- --- title: "DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk" canonical_url: "https://www.sorena.io/artifacts/eu/dora/faq" source_url: "https://www.sorena.io/artifacts/eu/dora/faq" author: "Sorena AI" description: "High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what \"critical or important functions\" means." keywords: - "DORA FAQ" - "what is DORA" - "when does DORA apply" - "DORA applies 17 January 2025" - "DORA scope financial entities" - "DORA major incident reporting" - "DORA register of information RoI" - "DORA third party risk RTS 2024/1773" - "DORA RoI templates ITS 2024/2956" - "DORA TLPT RTS 2025/1190" - "DORA applies date" - "DORA scope" - "DORA incident reporting" - "DORA register of information" - "DORA TLPT" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. *FAQ* *EU* ## EU DORA FAQ Fast answers to the real questions compliance, security, and product teams ask about DORA. Grounded in the Regulation and the key RTS/ITS for reporting, contracting, and RoI templates. This FAQ is designed to be operational: each answer points to what to implement next and what evidence to keep. For formal interpretation and edge cases, validate against the primary legal texts and your competent authority guidance. ## When does DORA apply? DORA applies from 17 January 2025 (Article 64). It entered into force 20 days after its publication in the Official Journal (OJ L 333, 27.12.2022). Most readiness work (RoI, reporting pipeline, third-party clauses, testing program) should be built as a program - not a last-minute checklist. - Practical timeline: 90-180 days to build core workflows + exports, then quarterly drills and continuous improvement. - If you can't export the RoI reliably, start there - it unlocks third-party supervision readiness. ## Who is in scope (and what does "critical or important functions" mean)? DORA covers a defined set of financial entities and sets stricter expectations for ICT services supporting critical or important functions. Operationally, treat "critical or important" as a service classification tag applied in your service catalog and architecture. It drives stricter contracting, monitoring, subcontracting governance, and exit planning. - Build a function catalog + service mapping so you can explain which ICT services support which functions. - Use that mapping to prioritize: third-party clause remediation, subcontracting assessments, and exit readiness work. ## What is the Register of Information (RoI) and why do supervisors care? The RoI is a DORA supervisory artifact: a register of contractual arrangements on ICT services from ICT third-party providers. Competent authorities can request the full register or specified sections. The ITS (Implementing Regulation (EU) 2024/2956) defines standard templates and a relational structure for consistent reporting and group consolidation. - Treat the RoI as a data product: stable identifiers + relational joins + validation + export pipeline. - Use the ITS templates (B_01-B_07) as the schema contract and generate exports automatically. ## How does DORA major incident reporting work? DORA incident reporting is a staged workflow: classification -> initial notification -> intermediate updates -> final report with root cause analysis and actual impact figures. The RTS specify classification thresholds (Delegated Regulation (EU) 2024/1772) and the content/time limits for reporting stages (Delegated Regulation (EU) 2025/301). - Implement reporting as a pipeline: one incident data model feeding DORA reporting outputs. - Keep a classification decision log and submission receipts - that's often what's requested first. ## Do we need TLPT (threat-led penetration testing)? Not every entity performs TLPT. The TLPT RTS (Delegated Regulation (EU) 2025/1190) specifies criteria for identifying entities required to perform TLPT. Even if you aren't in the first wave, TLPT readiness practices improve resilience and reduce incident/reporting risk. - Build a purple-team / red-team operating model and evidence trail so you can scale to TLPT if required. - Use an external framework like ECB TIBER-EU for realistic planning and governance where applicable. ## What changed in DORA supervision after application started? The main shift is that DORA is now operating through concrete supervisory artifacts and oversight tools, not just the core regulation text. The RoI ITS, the incident-reporting ITS, and the first critical ICT provider designations are now live reference points. That means firms need export-ready data, template-ready reporting, and third-party governance that can answer current supervisory questions. - RoI templates: ITS 2024/2956. - Incident reporting forms and procedures: ITS 2025/302, on top of RTS 2024/1772 and 2025/301. - Critical ICT third-party provider designations: first list published by the ESAs on 18 November 2025. - Fastest practical move: tighten incident-reporting data quality and RoI exports before trying to optimize everything else. *Recommended next step* *Placement: after the FAQ section* ## Use EU DORA FAQ as a cited research workflow Research Copilot can take EU DORA FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU DORA FAQ](/solutions/research-copilot.md): Start from EU DORA FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA FAQ. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary DORA legal text (application date in Article 64; register of information in Article 28; enforcement framework in Articles 50-55). - [Commission Implementing Regulation (EU) 2024/2956 - RoI standard templates (ITS)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Defines standard templates (B_01-B_07) for the register of information and its relational structure. - [Commission Delegated Regulation (EU) 2024/1772 - Incident classification RTS](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - Classification criteria and materiality thresholds for major ICT-related incidents and significant cyber threats. - [Commission Delegated Regulation (EU) 2025/301 - Reporting content and time limits RTS](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng?ref=sorena.io) - Content and time limits for initial and subsequent incident reports under DORA. - [Commission Delegated Regulation (EU) 2025/1190 - TLPT identification criteria RTS](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng?ref=sorena.io) - Criteria for identifying financial entities required to perform threat-led penetration testing. - [Commission Implementing Regulation (EU) 2025/302 - Major ICT incident reporting forms and templates (ITS)](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng?ref=sorena.io) - Defines the actual reporting forms and procedures used for major ICT incident submissions. - [ESMA news - ESAs designate critical ICT third-party providers under DORA](https://www.esma.europa.eu/press-news/esma-news/european-supervisory-authorities-designate-critical-ict-third-party-providers?ref=sorena.io) - Confirms the first published list of designated critical ICT third-party providers on 18 November 2025. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/faq --- --- title: "DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk" canonical_url: "https://www.sorena.io/artifacts/eu/dora/faq" source_url: "https://www.sorena.io/artifacts/eu/dora/faq" author: "Sorena AI" description: "High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what \"critical or important functions\" means." keywords: - "DORA FAQ" - "what is DORA" - "when does DORA apply" - "DORA applies 17 January 2025" - "DORA scope financial entities" - "DORA major incident reporting" - "DORA register of information RoI" - "DORA third party risk RTS 2024/1773" - "DORA RoI templates ITS 2024/2956" - "DORA TLPT RTS 2025/1190" - "DORA applies date" - "DORA scope" - "DORA incident reporting" - "DORA register of information" - "DORA TLPT" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. *FAQ* *EU* ## EU DORA FAQ Fast answers to the real questions compliance, security, and product teams ask about DORA. Grounded in the Regulation and the key RTS/ITS for reporting, contracting, and RoI templates. This FAQ is designed to be operational: each answer points to what to implement next and what evidence to keep. For formal interpretation and edge cases, validate against the primary legal texts and your competent authority guidance. ## When does DORA apply? DORA applies from 17 January 2025 (Article 64). It entered into force 20 days after its publication in the Official Journal (OJ L 333, 27.12.2022). Most readiness work (RoI, reporting pipeline, third-party clauses, testing program) should be built as a program - not a last-minute checklist. - Practical timeline: 90-180 days to build core workflows + exports, then quarterly drills and continuous improvement. - If you can't export the RoI reliably, start there - it unlocks third-party supervision readiness. ## Who is in scope (and what does "critical or important functions" mean)? DORA covers a defined set of financial entities and sets stricter expectations for ICT services supporting critical or important functions. Operationally, treat "critical or important" as a service classification tag applied in your service catalog and architecture. It drives stricter contracting, monitoring, subcontracting governance, and exit planning. - Build a function catalog + service mapping so you can explain which ICT services support which functions. - Use that mapping to prioritize: third-party clause remediation, subcontracting assessments, and exit readiness work. ## What is the Register of Information (RoI) and why do supervisors care? The RoI is a DORA supervisory artifact: a register of contractual arrangements on ICT services from ICT third-party providers. Competent authorities can request the full register or specified sections. The ITS (Implementing Regulation (EU) 2024/2956) defines standard templates and a relational structure for consistent reporting and group consolidation. - Treat the RoI as a data product: stable identifiers + relational joins + validation + export pipeline. - Use the ITS templates (B_01-B_07) as the schema contract and generate exports automatically. ## How does DORA major incident reporting work? DORA incident reporting is a staged workflow: classification -> initial notification -> intermediate updates -> final report with root cause analysis and actual impact figures. The RTS specify classification thresholds (Delegated Regulation (EU) 2024/1772) and the content/time limits for reporting stages (Delegated Regulation (EU) 2025/301). - Implement reporting as a pipeline: one incident data model feeding DORA reporting outputs. - Keep a classification decision log and submission receipts - that's often what's requested first. ## Do we need TLPT (threat-led penetration testing)? Not every entity performs TLPT. The TLPT RTS (Delegated Regulation (EU) 2025/1190) specifies criteria for identifying entities required to perform TLPT. Even if you aren't in the first wave, TLPT readiness practices improve resilience and reduce incident/reporting risk. - Build a purple-team / red-team operating model and evidence trail so you can scale to TLPT if required. - Use an external framework like ECB TIBER-EU for realistic planning and governance where applicable. ## What changed in DORA supervision after application started? The main shift is that DORA is now operating through concrete supervisory artifacts and oversight tools, not just the core regulation text. The RoI ITS, the incident-reporting ITS, and the first critical ICT provider designations are now live reference points. That means firms need export-ready data, template-ready reporting, and third-party governance that can answer current supervisory questions. - RoI templates: ITS 2024/2956. - Incident reporting forms and procedures: ITS 2025/302, on top of RTS 2024/1772 and 2025/301. - Critical ICT third-party provider designations: first list published by the ESAs on 18 November 2025. - Fastest practical move: tighten incident-reporting data quality and RoI exports before trying to optimize everything else. *Recommended next step* *Placement: after the FAQ section* ## Use EU DORA FAQ as a cited research workflow Research Copilot can take EU DORA FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU DORA FAQ](/solutions/research-copilot.md): Start from EU DORA FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA FAQ. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary DORA legal text (application date in Article 64; register of information in Article 28; enforcement framework in Articles 50-55). - [Commission Implementing Regulation (EU) 2024/2956 - RoI standard templates (ITS)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Defines standard templates (B_01-B_07) for the register of information and its relational structure. - [Commission Delegated Regulation (EU) 2024/1772 - Incident classification RTS](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - Classification criteria and materiality thresholds for major ICT-related incidents and significant cyber threats. - [Commission Delegated Regulation (EU) 2025/301 - Reporting content and time limits RTS](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng?ref=sorena.io) - Content and time limits for initial and subsequent incident reports under DORA. - [Commission Delegated Regulation (EU) 2025/1190 - TLPT identification criteria RTS](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng?ref=sorena.io) - Criteria for identifying financial entities required to perform threat-led penetration testing. - [Commission Implementing Regulation (EU) 2025/302 - Major ICT incident reporting forms and templates (ITS)](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng?ref=sorena.io) - Defines the actual reporting forms and procedures used for major ICT incident submissions. - [ESMA news - ESAs designate critical ICT third-party providers under DORA](https://www.esma.europa.eu/press-news/esma-news/european-supervisory-authorities-designate-critical-ict-third-party-providers?ref=sorena.io) - Confirms the first published list of designated critical ICT third-party providers on 18 November 2025. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/faq --- --- title: "DORA ICT Risk Management Control Baseline" canonical_url: "https://www.sorena.io/artifacts/eu/dora/ict-risk-management-control-baseline" source_url: "https://www.sorena.io/artifacts/eu/dora/ict-risk-management-control-baseline" author: "Sorena AI" description: "A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence." keywords: - "DORA ICT risk management" - "DORA Chapter II controls" - "ICT risk management framework DORA" - "DORA control baseline" - "DORA Article 8 inventory" - "DORA business continuity policy" - "ICT response and recovery plans DORA" - "RTS 2024/1774 ICT risk management" - "ICT risk management" - "DORA controls" - "control baseline" - "business continuity" - "recovery planning" - "RTS 2024/1774" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA ICT Risk Management Control Baseline A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. *Control Baseline* *EU* ## EU DORA ICT Risk Management Baseline A control library you can implement, test, and audit. Built from DORA Chapter II + the Level 2 RTS for ICT risk management tools and simplified framework. DORA Chapter II expects a coherent ICT risk management framework, not a stack of disconnected policies. The easiest way to ship compliance is to build a control baseline: control -> owner -> acceptance criteria -> evidence. This page provides an implementation-ready baseline you can adapt by proportionality and connect to incident reporting and testing programs. ## Baseline architecture: how to structure your DORA control library Build the library around control families that match how systems fail and how supervisors ask questions: inventory -> protect -> detect -> respond -> recover -> learn. Use one evidence model across all families: logs + reports + approvals + tests. - Control statement: what the control does and why it exists. - Acceptance criteria: measurable "done looks like" conditions. - Evidence: where proof lives and how it's exported (screenshots, tickets, logs, reports). - Cadence: how often the control is tested/reviewed. - Proportionality: what changes under simplified frameworks or microenterprise approaches. ## Family 1 - Governance and accountability (management body oversight) DORA ties ICT risk management to governance: management bodies define, approve and oversee the ICT risk framework and continuity planning. Treat governance controls as evidence-producing processes (not just policies). - Management body approves ICT risk management framework and reviews it periodically. - Risk tolerance for ICT risk is defined and tracked with KPIs (availability, recovery, control exceptions). - Internal audit/independent review exists for key ICT response and recovery plans (non-microenterprises). - RACI exists across ICT risk management, incident reporting, testing, and third-party governance. ## Family 2 - Inventories and dependency mapping (Article 8 foundation) Article 8 requires identifying, classifying and documenting ICT-supported business functions, information assets and ICT assets, and their roles/dependencies in relation to ICT risk - and reviewing at least yearly. This is the root of almost every other DORA control: you can't protect or recover what you can't list. - Inventory: ICT-supported business functions and owners; critical or important functions identified. - Asset classification: information assets and ICT assets are classified by criticality and data sensitivity. - Dependency map: key systems, integrations, and third-party services supporting critical/important functions are documented. - Review cadence: inventory and documentation reviewed at least annually (and after major changes). - Evidence: CMDB exports, architecture diagrams, service catalog, and third-party dependency register linkage. ## Family 3 - Protection and prevention (reduce probability of disruption) Protection controls reduce incident frequency and blast radius. DORA expects safeguards against intrusions and data misuse and preservation of availability, authenticity, integrity and confidentiality of data. Implement these controls as "standards + enforcement + verification". - Identity and access management: least privilege, privileged access controls, review cadence, and strong authentication for sensitive systems. - Secure configuration and hardening: baseline configs, drift detection, and environment segregation for critical functions. - Change management: risk-based approvals for changes affecting critical functions; rollback plans and change windows. - Vulnerability management: scanning, prioritization, patch SLAs, and exception governance for critical systems. - Data protection: encryption, key management governance, backup protection, and integrity controls for logs and critical data. ## Family 4 - Detection and monitoring (reduce time-to-detect) DORA expects prompt detection of anomalous activities and ICT-related incidents and identification of single points of failure. Make detection measurable: coverage, alert quality, and time-to-detect. - Monitoring coverage: critical functions have telemetry (availability, latency, errors, security signals). - Log integrity: critical logs are protected from tampering and retention supports investigations. - Alert quality: false positive management, escalation rules, and on-call coverage for critical services. - Evidence: monitoring dashboards, alert runbooks, incident timelines, and post-incident review outputs. *Recommended next step* *Placement: after the main workflow section* ## Turn EU DORA ICT Risk Management Baseline into an operational assessment Assessment Autopilot can take EU DORA ICT Risk Management Baseline from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU DORA ICT Risk Management Baseline](/solutions/assessment.md): Start from EU DORA ICT Risk Management Baseline and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA ICT Risk Management Baseline. ## Family 5 - Response and recovery planning (Articles 11-13) DORA requires a comprehensive ICT business continuity policy and associated ICT response and recovery plans. Treat response and recovery as practiced operations: runbooks + exercises + measured outcomes. - Business continuity policy exists and covers critical functions; integrates with overall BCP (Article 11). - Response and recovery plans exist and are exercised; include containment measures and tailored recovery procedures (Articles 11-12). - Testing includes cyber-attack and switchover scenarios between primary and redundant capacity where required. - Post-incident reviews occur after major incidents and result in documented improvements (Article 13). - Evidence: tabletop exercise reports, restore testing evidence, RTO/RPO achievements, and improvement tracking. ## Family 6 - Communications and crisis management DORA incident workflows explicitly include communication plans to staff, stakeholders and media and escalation to senior management and the management body for major incidents. This is a control surface: clarity and speed matter during outages. - Crisis communications plan exists: internal staff updates, external stakeholder communications, and media handling. - Major incident reporting to senior management and the management body is implemented with structured summaries and action plans. - Evidence: comms templates, escalation logs, and management briefings tied to incident records. ## Family 7 - Proportionality and simplified framework (RTS 2024/1774) DORA expects proportional application of controls and allows simplified frameworks for certain entities. The Level 2 RTS specifies tools, methods, processes and policies and the simplified approach. The mistake is treating "simplified" as "uncontrolled". Your simplified framework still needs evidence and review cadence. - Define what is simplified: which control families are reduced and why the residual risk is acceptable. - Keep minimum evidence: inventories, incident records, continuity plans, and periodic reviews. - Document supervisory rationale: basis for simplification, approval, and review cadence. ## Evidence pack checklist (exportable, audit-ready) If you can't export evidence quickly, you'll end up rebuilding it during supervisory requests or audits. Use this list as your "evidence readiness" acceptance criteria. - ICT risk management policy set + governance approvals and periodic review minutes. - Inventories: ICT-supported business functions, information assets, ICT assets, dependency maps (annual review evidence). - Control testing results: vuln scans, patch SLAs, access reviews, configuration drift reports, monitoring coverage reviews. - Continuity and recovery evidence: response/recovery plans, exercise reports, restore evidence, post-incident review outputs. - Linkage to incident reporting (Chapter III) and testing programs (Chapter IV) so evidence is consistent. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Chapter II ICT risk management requirements, including the inventory/classification foundation (Article 8) and continuity and response/recovery obligations (Articles 11-13). - [Commission Delegated Regulation (EU) 2024/1774 - ICT risk management tools and simplified framework (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng?ref=sorena.io) - RTS specifying detailed ICT risk management tools, methods, processes, policies, and the simplified framework. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/ict-risk-management-control-baseline --- --- title: "DORA ICT Risk Management Control Baseline" canonical_url: "https://www.sorena.io/artifacts/eu/dora/ict-risk-management-control-baseline" source_url: "https://www.sorena.io/artifacts/eu/dora/ict-risk-management-control-baseline" author: "Sorena AI" description: "A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence." keywords: - "DORA ICT risk management" - "DORA Chapter II controls" - "ICT risk management framework DORA" - "DORA control baseline" - "DORA Article 8 inventory" - "DORA business continuity policy" - "ICT response and recovery plans DORA" - "RTS 2024/1774 ICT risk management" - "ICT risk management" - "DORA controls" - "control baseline" - "business continuity" - "recovery planning" - "RTS 2024/1774" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA ICT Risk Management Control Baseline A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. *Control Baseline* *EU* ## EU DORA ICT Risk Management Baseline A control library you can implement, test, and audit. Built from DORA Chapter II + the Level 2 RTS for ICT risk management tools and simplified framework. DORA Chapter II expects a coherent ICT risk management framework, not a stack of disconnected policies. The easiest way to ship compliance is to build a control baseline: control -> owner -> acceptance criteria -> evidence. This page provides an implementation-ready baseline you can adapt by proportionality and connect to incident reporting and testing programs. ## Baseline architecture: how to structure your DORA control library Build the library around control families that match how systems fail and how supervisors ask questions: inventory -> protect -> detect -> respond -> recover -> learn. Use one evidence model across all families: logs + reports + approvals + tests. - Control statement: what the control does and why it exists. - Acceptance criteria: measurable "done looks like" conditions. - Evidence: where proof lives and how it's exported (screenshots, tickets, logs, reports). - Cadence: how often the control is tested/reviewed. - Proportionality: what changes under simplified frameworks or microenterprise approaches. ## Family 1 - Governance and accountability (management body oversight) DORA ties ICT risk management to governance: management bodies define, approve and oversee the ICT risk framework and continuity planning. Treat governance controls as evidence-producing processes (not just policies). - Management body approves ICT risk management framework and reviews it periodically. - Risk tolerance for ICT risk is defined and tracked with KPIs (availability, recovery, control exceptions). - Internal audit/independent review exists for key ICT response and recovery plans (non-microenterprises). - RACI exists across ICT risk management, incident reporting, testing, and third-party governance. ## Family 2 - Inventories and dependency mapping (Article 8 foundation) Article 8 requires identifying, classifying and documenting ICT-supported business functions, information assets and ICT assets, and their roles/dependencies in relation to ICT risk - and reviewing at least yearly. This is the root of almost every other DORA control: you can't protect or recover what you can't list. - Inventory: ICT-supported business functions and owners; critical or important functions identified. - Asset classification: information assets and ICT assets are classified by criticality and data sensitivity. - Dependency map: key systems, integrations, and third-party services supporting critical/important functions are documented. - Review cadence: inventory and documentation reviewed at least annually (and after major changes). - Evidence: CMDB exports, architecture diagrams, service catalog, and third-party dependency register linkage. ## Family 3 - Protection and prevention (reduce probability of disruption) Protection controls reduce incident frequency and blast radius. DORA expects safeguards against intrusions and data misuse and preservation of availability, authenticity, integrity and confidentiality of data. Implement these controls as "standards + enforcement + verification". - Identity and access management: least privilege, privileged access controls, review cadence, and strong authentication for sensitive systems. - Secure configuration and hardening: baseline configs, drift detection, and environment segregation for critical functions. - Change management: risk-based approvals for changes affecting critical functions; rollback plans and change windows. - Vulnerability management: scanning, prioritization, patch SLAs, and exception governance for critical systems. - Data protection: encryption, key management governance, backup protection, and integrity controls for logs and critical data. ## Family 4 - Detection and monitoring (reduce time-to-detect) DORA expects prompt detection of anomalous activities and ICT-related incidents and identification of single points of failure. Make detection measurable: coverage, alert quality, and time-to-detect. - Monitoring coverage: critical functions have telemetry (availability, latency, errors, security signals). - Log integrity: critical logs are protected from tampering and retention supports investigations. - Alert quality: false positive management, escalation rules, and on-call coverage for critical services. - Evidence: monitoring dashboards, alert runbooks, incident timelines, and post-incident review outputs. *Recommended next step* *Placement: after the main workflow section* ## Turn EU DORA ICT Risk Management Baseline into an operational assessment Assessment Autopilot can take EU DORA ICT Risk Management Baseline from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU DORA ICT Risk Management Baseline](/solutions/assessment.md): Start from EU DORA ICT Risk Management Baseline and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA ICT Risk Management Baseline. ## Family 5 - Response and recovery planning (Articles 11-13) DORA requires a comprehensive ICT business continuity policy and associated ICT response and recovery plans. Treat response and recovery as practiced operations: runbooks + exercises + measured outcomes. - Business continuity policy exists and covers critical functions; integrates with overall BCP (Article 11). - Response and recovery plans exist and are exercised; include containment measures and tailored recovery procedures (Articles 11-12). - Testing includes cyber-attack and switchover scenarios between primary and redundant capacity where required. - Post-incident reviews occur after major incidents and result in documented improvements (Article 13). - Evidence: tabletop exercise reports, restore testing evidence, RTO/RPO achievements, and improvement tracking. ## Family 6 - Communications and crisis management DORA incident workflows explicitly include communication plans to staff, stakeholders and media and escalation to senior management and the management body for major incidents. This is a control surface: clarity and speed matter during outages. - Crisis communications plan exists: internal staff updates, external stakeholder communications, and media handling. - Major incident reporting to senior management and the management body is implemented with structured summaries and action plans. - Evidence: comms templates, escalation logs, and management briefings tied to incident records. ## Family 7 - Proportionality and simplified framework (RTS 2024/1774) DORA expects proportional application of controls and allows simplified frameworks for certain entities. The Level 2 RTS specifies tools, methods, processes and policies and the simplified approach. The mistake is treating "simplified" as "uncontrolled". Your simplified framework still needs evidence and review cadence. - Define what is simplified: which control families are reduced and why the residual risk is acceptable. - Keep minimum evidence: inventories, incident records, continuity plans, and periodic reviews. - Document supervisory rationale: basis for simplification, approval, and review cadence. ## Evidence pack checklist (exportable, audit-ready) If you can't export evidence quickly, you'll end up rebuilding it during supervisory requests or audits. Use this list as your "evidence readiness" acceptance criteria. - ICT risk management policy set + governance approvals and periodic review minutes. - Inventories: ICT-supported business functions, information assets, ICT assets, dependency maps (annual review evidence). - Control testing results: vuln scans, patch SLAs, access reviews, configuration drift reports, monitoring coverage reviews. - Continuity and recovery evidence: response/recovery plans, exercise reports, restore evidence, post-incident review outputs. - Linkage to incident reporting (Chapter III) and testing programs (Chapter IV) so evidence is consistent. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Chapter II ICT risk management requirements, including the inventory/classification foundation (Article 8) and continuity and response/recovery obligations (Articles 11-13). - [Commission Delegated Regulation (EU) 2024/1774 - ICT risk management tools and simplified framework (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng?ref=sorena.io) - RTS specifying detailed ICT risk management tools, methods, processes, policies, and the simplified framework. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/ict-risk-management-control-baseline --- --- title: "DORA Major ICT Incident Reporting" canonical_url: "https://www.sorena.io/artifacts/eu/dora/major-incident-reporting" source_url: "https://www.sorena.io/artifacts/eu/dora/major-incident-reporting" author: "Sorena AI" description: "A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules." keywords: - "DORA major ICT incident reporting" - "DORA incident reporting" - "DORA Article 19 reporting" - "DORA Article 17 incident management process" - "DORA classification RTS 2024/1772" - "DORA reporting time limits RTS 2025/301" - "initial notification intermediate final report DORA" - "DORA significant cyber threat notification" - "major ICT incident reporting" - "incident classification" - "Article 17" - "Article 19" - "RTS 2024/1772" - "RTS 2025/301" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA Major ICT Incident Reporting A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. *Workflow Guide* *EU* ## EU DORA Major Incident Reporting Build an incident reporting workflow that works during outages and stands up to supervisory scrutiny. Covers the process (Article 17), classification thresholds (RTS 2024/1772), and report content + time limits (RTS 2025/301). DORA incident reporting is not just "send an email to a regulator". It's a regulated workflow with classification logic, timed reporting outputs, and evidence requirements. The fastest path to compliance is to treat reporting as a product: a structured data model, a workflow engine, and a reporting pack generator that produces initial notification, intermediate updates, and a final root cause analysis report. ## What DORA requires (minimum viable compliant reporting system) DORA requires financial entities to define, establish and implement an ICT-related incident management process to detect, manage and notify ICT-related incidents (Article 17). Financial entities must record all ICT-related incidents and significant cyber threats, classify incidents, and report major ICT-related incidents to competent authorities with specified report stages (Article 19). - Implement an incident management process with early warning indicators, tracking/logging/classification, roles and responsibilities, communications, and response procedures (Article 17). - Record all incidents and significant cyber threats; ensure consistent handling and root cause analysis and prevention improvements (Article 17(2)). - Report major ICT-related incidents: initial notification -> intermediate updates -> final report with RCA and actual impact figures (Article 19(4)). - Inform clients without undue delay where incidents impact clients' financial interests (Article 19(3)). ## Article 17 - Incident management process blueprint (control design) Article 17 tells you what the process must contain. Build it as an operational workflow with measured outcomes. The process must also support communications and management body reporting for major incidents. - Early warning indicators: define signals and thresholds for anomalous activities. - Tracking and logging: a single incident record with timestamps, severity, impacted services, and dependency links. - Classification: procedures to categorize and classify incidents by priority/severity and criticality of impacted services (ties to Article 18). - Roles and responsibilities: defined on-call and escalation model; crisis roles activated by scenario type. - Communications: staff + external stakeholder + media plan; internal escalation; customer complaint handling integration (Article 17(3)(d)). - Major incident reporting to management: structured briefings for senior management and management body (Article 17(3)(e)). *Recommended next step* *Placement: after the workflow or playbook section* ## Turn EU DORA Major Incident Reporting into an operational assessment Assessment Autopilot can take EU DORA Major Incident Reporting from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU DORA Major Incident Reporting](/solutions/assessment.md): Start from EU DORA Major Incident Reporting and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Major Incident Reporting. ## Classification and thresholds: Article 18 + RTS 2024/1772 Major incident reporting is triggered by classification. RTS 2024/1772 operationalizes the criteria and materiality thresholds for major incidents and cyber threats. Implement classification as code + governance: thresholds, decision logs, and QA sampling. - Define classification inputs: services impacted, criticality, clients affected, transaction impact, geographic/cross-border impact, and economic impact (RTS context). - Implement threshold evaluation: deterministic rules where possible, with documented judgment where required. - Keep a "classification decision log": why it was (or wasn't) major, with evidence links and sign-off. - QA: sample classifications quarterly and compare decisions across teams to reduce arbitrariness. ## Reporting pipeline: Article 19, RTS 2025/301, and ITS 2025/302 (stages, content, time limits, templates) Article 19 defines the reporting stages. RTS 2025/301 specifies the content and time limits, while ITS 2025/302 provides the standard forms, templates, and procedures used for actual submissions. Design your pipeline to work during degraded operations (e.g., alternate submission paths). - Initial notification: generate quickly with known facts and classification basis; include cross-border impact indicators. - Intermediate reports/updates: trigger on significant status changes; support updated notifications on request of competent authority. - Final report: include root cause analysis and actual impact figures replacing estimates; record remediation actions. - Technical fallback: if a technical impossibility prevents submission using the template, notify via alternative means and preserve evidence of the fallback (Article 19). - Template discipline: map your incident object to the ITS 2025/302 standard fields so initial, intermediate, and final reports can be generated consistently even during degraded operations. ## Why the ITS 2025/302 templates change implementation quality Many teams stop at classification and timing, but supervisors expect consistent use of the standard reporting forms and procedures. That is where the ITS matters. If your reporting workflow cannot populate the standard template fields directly from incident records, the process will fail when speed and accuracy matter most. - Treat the ITS forms as a schema contract for incident reporting, not as a document to fill in manually at the end. - Map every required reporting field to a system of record, owner, and validation rule. - Test fallback paths and submission logistics so template-based reporting still works when primary systems are degraded. - Keep submission receipts and exact report versions because supervisors often ask for the timeline of what was reported and when. ## Voluntary significant cyber threat notifications (when to use them) DORA allows financial entities to voluntarily notify significant cyber threats when relevant to the financial system, service users, or clients. Treat this as a governance decision with clear triggers and a redaction approach. - Define trigger conditions: threat relevance, likelihood, sector contagion risk, and client impact. - Build a redaction and confidentiality model: share what's needed without leaking sensitive defensive details. - Evidence: keep the threat record, analysis, and rationale for notification vs non-notification. ## Reporting data model (recommended schema you can implement) The easiest way to comply is to treat reporting outputs as structured objects generated from operational data. This schema supports reporting, transparency, audits, and post-incident improvements. - Incident core: ID, timestamps, impacted services and criticality, root cause hypothesis, status timeline. - Impact metrics: clients affected, transaction and service disruption metrics, economic impact (costs/losses), geographic footprint. - Response and recovery: containment actions, recovery milestones, external dependency actions (third-party providers). - Communications: client notification decisions and timestamps, external stakeholder communications, regulator submissions. - Evidence links: logs, alerts, tickets, post-incident review, test results from remediation validation. ## Evidence pack checklist (what supervisors ask for first) Reporting risk is usually evidence risk: you can't reproduce numbers or explain classification decisions later. Build these artifacts as part of normal operations. - Incident management policy and runbook aligned to Article 17; on-call and escalation schedules. - Classification decision logs aligned to RTS 2024/1772; quarterly QA sampling results. - Copies of submitted reports (initial/intermediate/final) with timestamps and submission receipts. - Client communications templates and samples for major incidents impacting financial interests. - Post-incident review reports and improvement tracking to show learning and prevention. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Incident management process requirements (Article 17) and major incident reporting stages and obligations (Article 19). - [Commission Delegated Regulation (EU) 2024/1772 - Classification of ICT incidents and cyber threats (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - RTS specifying classification criteria and materiality thresholds for major ICT-related incidents and significant cyber threats. - [Commission Delegated Regulation (EU) 2025/301 - Incident reporting content and time limits (RTS)](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng?ref=sorena.io) - RTS specifying the content and time limits for initial notifications and reports submitted under DORA incident reporting. - [Commission Implementing Regulation (EU) 2025/302 - Major ICT incident reporting forms and templates (ITS)](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng?ref=sorena.io) - Defines the standard forms, templates, and procedures that operationalize DORA major ICT-related incident reporting. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/major-incident-reporting --- --- title: "DORA Major ICT Incident Reporting" canonical_url: "https://www.sorena.io/artifacts/eu/dora/major-incident-reporting" source_url: "https://www.sorena.io/artifacts/eu/dora/major-incident-reporting" author: "Sorena AI" description: "A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules." keywords: - "DORA major ICT incident reporting" - "DORA incident reporting" - "DORA Article 19 reporting" - "DORA Article 17 incident management process" - "DORA classification RTS 2024/1772" - "DORA reporting time limits RTS 2025/301" - "initial notification intermediate final report DORA" - "DORA significant cyber threat notification" - "major ICT incident reporting" - "incident classification" - "Article 17" - "Article 19" - "RTS 2024/1772" - "RTS 2025/301" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA Major ICT Incident Reporting A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. *Workflow Guide* *EU* ## EU DORA Major Incident Reporting Build an incident reporting workflow that works during outages and stands up to supervisory scrutiny. Covers the process (Article 17), classification thresholds (RTS 2024/1772), and report content + time limits (RTS 2025/301). DORA incident reporting is not just "send an email to a regulator". It's a regulated workflow with classification logic, timed reporting outputs, and evidence requirements. The fastest path to compliance is to treat reporting as a product: a structured data model, a workflow engine, and a reporting pack generator that produces initial notification, intermediate updates, and a final root cause analysis report. ## What DORA requires (minimum viable compliant reporting system) DORA requires financial entities to define, establish and implement an ICT-related incident management process to detect, manage and notify ICT-related incidents (Article 17). Financial entities must record all ICT-related incidents and significant cyber threats, classify incidents, and report major ICT-related incidents to competent authorities with specified report stages (Article 19). - Implement an incident management process with early warning indicators, tracking/logging/classification, roles and responsibilities, communications, and response procedures (Article 17). - Record all incidents and significant cyber threats; ensure consistent handling and root cause analysis and prevention improvements (Article 17(2)). - Report major ICT-related incidents: initial notification -> intermediate updates -> final report with RCA and actual impact figures (Article 19(4)). - Inform clients without undue delay where incidents impact clients' financial interests (Article 19(3)). ## Article 17 - Incident management process blueprint (control design) Article 17 tells you what the process must contain. Build it as an operational workflow with measured outcomes. The process must also support communications and management body reporting for major incidents. - Early warning indicators: define signals and thresholds for anomalous activities. - Tracking and logging: a single incident record with timestamps, severity, impacted services, and dependency links. - Classification: procedures to categorize and classify incidents by priority/severity and criticality of impacted services (ties to Article 18). - Roles and responsibilities: defined on-call and escalation model; crisis roles activated by scenario type. - Communications: staff + external stakeholder + media plan; internal escalation; customer complaint handling integration (Article 17(3)(d)). - Major incident reporting to management: structured briefings for senior management and management body (Article 17(3)(e)). *Recommended next step* *Placement: after the workflow or playbook section* ## Turn EU DORA Major Incident Reporting into an operational assessment Assessment Autopilot can take EU DORA Major Incident Reporting from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU DORA Major Incident Reporting](/solutions/assessment.md): Start from EU DORA Major Incident Reporting and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Major Incident Reporting. ## Classification and thresholds: Article 18 + RTS 2024/1772 Major incident reporting is triggered by classification. RTS 2024/1772 operationalizes the criteria and materiality thresholds for major incidents and cyber threats. Implement classification as code + governance: thresholds, decision logs, and QA sampling. - Define classification inputs: services impacted, criticality, clients affected, transaction impact, geographic/cross-border impact, and economic impact (RTS context). - Implement threshold evaluation: deterministic rules where possible, with documented judgment where required. - Keep a "classification decision log": why it was (or wasn't) major, with evidence links and sign-off. - QA: sample classifications quarterly and compare decisions across teams to reduce arbitrariness. ## Reporting pipeline: Article 19, RTS 2025/301, and ITS 2025/302 (stages, content, time limits, templates) Article 19 defines the reporting stages. RTS 2025/301 specifies the content and time limits, while ITS 2025/302 provides the standard forms, templates, and procedures used for actual submissions. Design your pipeline to work during degraded operations (e.g., alternate submission paths). - Initial notification: generate quickly with known facts and classification basis; include cross-border impact indicators. - Intermediate reports/updates: trigger on significant status changes; support updated notifications on request of competent authority. - Final report: include root cause analysis and actual impact figures replacing estimates; record remediation actions. - Technical fallback: if a technical impossibility prevents submission using the template, notify via alternative means and preserve evidence of the fallback (Article 19). - Template discipline: map your incident object to the ITS 2025/302 standard fields so initial, intermediate, and final reports can be generated consistently even during degraded operations. ## Why the ITS 2025/302 templates change implementation quality Many teams stop at classification and timing, but supervisors expect consistent use of the standard reporting forms and procedures. That is where the ITS matters. If your reporting workflow cannot populate the standard template fields directly from incident records, the process will fail when speed and accuracy matter most. - Treat the ITS forms as a schema contract for incident reporting, not as a document to fill in manually at the end. - Map every required reporting field to a system of record, owner, and validation rule. - Test fallback paths and submission logistics so template-based reporting still works when primary systems are degraded. - Keep submission receipts and exact report versions because supervisors often ask for the timeline of what was reported and when. ## Voluntary significant cyber threat notifications (when to use them) DORA allows financial entities to voluntarily notify significant cyber threats when relevant to the financial system, service users, or clients. Treat this as a governance decision with clear triggers and a redaction approach. - Define trigger conditions: threat relevance, likelihood, sector contagion risk, and client impact. - Build a redaction and confidentiality model: share what's needed without leaking sensitive defensive details. - Evidence: keep the threat record, analysis, and rationale for notification vs non-notification. ## Reporting data model (recommended schema you can implement) The easiest way to comply is to treat reporting outputs as structured objects generated from operational data. This schema supports reporting, transparency, audits, and post-incident improvements. - Incident core: ID, timestamps, impacted services and criticality, root cause hypothesis, status timeline. - Impact metrics: clients affected, transaction and service disruption metrics, economic impact (costs/losses), geographic footprint. - Response and recovery: containment actions, recovery milestones, external dependency actions (third-party providers). - Communications: client notification decisions and timestamps, external stakeholder communications, regulator submissions. - Evidence links: logs, alerts, tickets, post-incident review, test results from remediation validation. ## Evidence pack checklist (what supervisors ask for first) Reporting risk is usually evidence risk: you can't reproduce numbers or explain classification decisions later. Build these artifacts as part of normal operations. - Incident management policy and runbook aligned to Article 17; on-call and escalation schedules. - Classification decision logs aligned to RTS 2024/1772; quarterly QA sampling results. - Copies of submitted reports (initial/intermediate/final) with timestamps and submission receipts. - Client communications templates and samples for major incidents impacting financial interests. - Post-incident review reports and improvement tracking to show learning and prevention. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Incident management process requirements (Article 17) and major incident reporting stages and obligations (Article 19). - [Commission Delegated Regulation (EU) 2024/1772 - Classification of ICT incidents and cyber threats (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng?ref=sorena.io) - RTS specifying classification criteria and materiality thresholds for major ICT-related incidents and significant cyber threats. - [Commission Delegated Regulation (EU) 2025/301 - Incident reporting content and time limits (RTS)](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng?ref=sorena.io) - RTS specifying the content and time limits for initial notifications and reports submitted under DORA incident reporting. - [Commission Implementing Regulation (EU) 2025/302 - Major ICT incident reporting forms and templates (ITS)](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng?ref=sorena.io) - Defines the standard forms, templates, and procedures that operationalize DORA major ICT-related incident reporting. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/major-incident-reporting --- --- title: "DORA Penalties, Fines, and Enforcement" canonical_url: "https://www.sorena.io/artifacts/eu/dora/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/dora/penalties-and-fines" author: "Sorena AI" description: "A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50)." keywords: - "DORA penalties" - "DORA fines" - "DORA enforcement" - "DORA administrative penalties Article 50" - "DORA publication of penalties Article 54" - "DORA criminal penalties Article 52" - "DORA periodic penalty payments critical ICT providers" - "DORA enforcement risk" - "Article 50" - "Article 54 publication" - "periodic penalty payments" - "critical ICT third-party providers" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA Penalties, Fines, and Enforcement A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). *Enforcement Guide* *EU* ## EU DORA Penalties & Enforcement Reduce enforcement risk by building evidence-first operational resilience. Covers Articles 50-55 and oversight penalty payments for critical ICT providers. DORA enforcement risk is usually evidence risk. Supervisors don't only assess whether a control exists; they assess whether it operates, whether management understands it, and whether your organization can reproduce decisions (classification, outsourcing approvals, exit plan feasibility) with traceable evidence. Use this page to understand DORA's penalty framework and to build the evidence that reduces both enforcement and reputational risk. ## Article 50 - What competent authorities can do Article 50 requires competent authorities to have the supervisory, investigatory, and sanctioning powers necessary to fulfil their duties under DORA. In practice: expect information requests, thematic reviews, on-site inspections, follow-up remediation tracking, and cross-authority coordination - not just a one-time audit. - Supervision is continuous: build an operating cadence (monitoring, testing, reporting drills) that keeps evidence current. - Remediation is a control: a credible closure process with validation evidence reduces escalation risk. - Narrative consistency matters: DORA includes cooperation mechanisms, making inconsistent answers across authorities riskier. ## Administrative penalties vs remedial measures (why "fix it fast" matters) DORA enforcement is not only about fines; it's also about getting the organization into a safe operating state. Remedial measures can require changes, not just payments. A fast, evidence-backed remediation program is often the difference between "finding closed" and "finding escalated". - Close gaps with measurable acceptance criteria (test evidence, monitoring coverage, operating metrics). - Preserve decision logs: incident classification decisions, outsourcing approvals, and exit feasibility assessments with sign-off. - Prove operations under stress: incident response drills, reporting pipeline outputs, and BCP/DR test results. *Recommended next step* *Placement: after the enforcement section* ## Use EU DORA Penalties & Enforcement as a cited research workflow Research Copilot can take EU DORA Penalties & Enforcement from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU DORA Penalties & Enforcement](/solutions/research-copilot.md): Start from EU DORA Penalties & Enforcement and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Penalties & Enforcement. ## Article 54 - Publication of penalties (reputational risk is part of enforcement) DORA includes publication provisions for administrative penalties, subject to proportionality and safeguards. This is why communications and evidence discipline matter: publication can amplify the cost of control failures. - Maintain a supervisor-ready narrative: what happened, what changed, how fixes were validated, and how recurrence is prevented. - Use one evidence index: policies, tests, incidents, and third-party records should be discoverable and reproducible. - Track remediation closure: owners, timelines, and validation proof (not just "we updated the policy"). ## Critical ICT third-party providers - oversight and periodic penalty payments DORA's oversight framework for critical ICT third-party providers includes enforcement levers at provider level, including periodic penalty payments for non-compliance with oversight-related obligations. As a financial entity, the practical impact is indirect but real: you must maintain accurate dependency transparency (RoI) and credible exits for critical services. - Monitor whether key providers are designated as critical and adjust board reporting, monitoring cadence, and contingency planning. - Ensure contracts and RoI enable fast disclosure of dependencies (including subcontractors for critical services). - Treat exit readiness as an enforcement risk control: weak exits increase systemic risk narratives and supervisory pressure. ## Reduce your enforcement risk - evidence checklist (do these first) If you only do one thing: build a coherent evidence system. That's what allows you to prove compliance without heroics. Use this checklist as your "first response" pack for supervisory questions. - ICT risk management framework: policies/procedures + KPIs/KRIs + control tests and monitoring outputs. - Incident reporting: classification decision logs, submitted reports, submission receipts, and post-incident improvement tracking. - Third-party risk: due diligence packs, contract clause mapping (RTS 2024/1773), subcontracting assessments (RTS 2025/532), and exit plans. - Register of information: validated ITS exports aligned to ITS 2024/2956 with stable identifiers and consolidation consistency. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Administrative penalties and remedial measures (Article 50), criminal penalties option (Article 52), notification duties (Article 53), publication of penalties (Article 54), and oversight framework including periodic penalty payments for critical ICT third-party providers. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/penalties-and-fines --- --- title: "DORA Penalties, Fines, and Enforcement" canonical_url: "https://www.sorena.io/artifacts/eu/dora/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/dora/penalties-and-fines" author: "Sorena AI" description: "A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50)." keywords: - "DORA penalties" - "DORA fines" - "DORA enforcement" - "DORA administrative penalties Article 50" - "DORA publication of penalties Article 54" - "DORA criminal penalties Article 52" - "DORA periodic penalty payments critical ICT providers" - "DORA enforcement risk" - "Article 50" - "Article 54 publication" - "periodic penalty payments" - "critical ICT third-party providers" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA Penalties, Fines, and Enforcement A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). *Enforcement Guide* *EU* ## EU DORA Penalties & Enforcement Reduce enforcement risk by building evidence-first operational resilience. Covers Articles 50-55 and oversight penalty payments for critical ICT providers. DORA enforcement risk is usually evidence risk. Supervisors don't only assess whether a control exists; they assess whether it operates, whether management understands it, and whether your organization can reproduce decisions (classification, outsourcing approvals, exit plan feasibility) with traceable evidence. Use this page to understand DORA's penalty framework and to build the evidence that reduces both enforcement and reputational risk. ## Article 50 - What competent authorities can do Article 50 requires competent authorities to have the supervisory, investigatory, and sanctioning powers necessary to fulfil their duties under DORA. In practice: expect information requests, thematic reviews, on-site inspections, follow-up remediation tracking, and cross-authority coordination - not just a one-time audit. - Supervision is continuous: build an operating cadence (monitoring, testing, reporting drills) that keeps evidence current. - Remediation is a control: a credible closure process with validation evidence reduces escalation risk. - Narrative consistency matters: DORA includes cooperation mechanisms, making inconsistent answers across authorities riskier. ## Administrative penalties vs remedial measures (why "fix it fast" matters) DORA enforcement is not only about fines; it's also about getting the organization into a safe operating state. Remedial measures can require changes, not just payments. A fast, evidence-backed remediation program is often the difference between "finding closed" and "finding escalated". - Close gaps with measurable acceptance criteria (test evidence, monitoring coverage, operating metrics). - Preserve decision logs: incident classification decisions, outsourcing approvals, and exit feasibility assessments with sign-off. - Prove operations under stress: incident response drills, reporting pipeline outputs, and BCP/DR test results. *Recommended next step* *Placement: after the enforcement section* ## Use EU DORA Penalties & Enforcement as a cited research workflow Research Copilot can take EU DORA Penalties & Enforcement from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU DORA Penalties & Enforcement](/solutions/research-copilot.md): Start from EU DORA Penalties & Enforcement and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Penalties & Enforcement. ## Article 54 - Publication of penalties (reputational risk is part of enforcement) DORA includes publication provisions for administrative penalties, subject to proportionality and safeguards. This is why communications and evidence discipline matter: publication can amplify the cost of control failures. - Maintain a supervisor-ready narrative: what happened, what changed, how fixes were validated, and how recurrence is prevented. - Use one evidence index: policies, tests, incidents, and third-party records should be discoverable and reproducible. - Track remediation closure: owners, timelines, and validation proof (not just "we updated the policy"). ## Critical ICT third-party providers - oversight and periodic penalty payments DORA's oversight framework for critical ICT third-party providers includes enforcement levers at provider level, including periodic penalty payments for non-compliance with oversight-related obligations. As a financial entity, the practical impact is indirect but real: you must maintain accurate dependency transparency (RoI) and credible exits for critical services. - Monitor whether key providers are designated as critical and adjust board reporting, monitoring cadence, and contingency planning. - Ensure contracts and RoI enable fast disclosure of dependencies (including subcontractors for critical services). - Treat exit readiness as an enforcement risk control: weak exits increase systemic risk narratives and supervisory pressure. ## Reduce your enforcement risk - evidence checklist (do these first) If you only do one thing: build a coherent evidence system. That's what allows you to prove compliance without heroics. Use this checklist as your "first response" pack for supervisory questions. - ICT risk management framework: policies/procedures + KPIs/KRIs + control tests and monitoring outputs. - Incident reporting: classification decision logs, submitted reports, submission receipts, and post-incident improvement tracking. - Third-party risk: due diligence packs, contract clause mapping (RTS 2024/1773), subcontracting assessments (RTS 2025/532), and exit plans. - Register of information: validated ITS exports aligned to ITS 2024/2956 with stable identifiers and consolidation consistency. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Administrative penalties and remedial measures (Article 50), criminal penalties option (Article 52), notification duties (Article 53), publication of penalties (Article 54), and oversight framework including periodic penalty payments for critical ICT third-party providers. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/penalties-and-fines --- --- title: "DORA Register of Information (RoI) - How to Build It" canonical_url: "https://www.sorena.io/artifacts/eu/dora/register-of-information-how-to-build" source_url: "https://www.sorena.io/artifacts/eu/dora/register-of-information-how-to-build" author: "Sorena AI" description: "Build an audit-ready DORA Register of Information (RoI): define scope and relational keys." keywords: - "DORA register of information" - "DORA RoI" - "DORA RoI how to build" - "DORA Article 28 register" - "DORA ICT third party register" - "outsourcing register DORA" - "ITS 2024/2956 register templates" - "DORA register of information template" - "register of information" - "RoI" - "Article 28" - "ITS 2024/2956" - "ICT third-party register" - "outsourcing register" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA Register of Information (RoI) - How to Build It Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. *Implementation Guide* *EU* ## EU DORA Register of Information (RoI) Build the RoI as a relational dataset you can export on demand - not a spreadsheet nobody trusts. Grounded in Article 28 and ITS 2024/2956 (standard templates for the register of information). DORA requires financial entities to maintain and update a register of information covering contractual arrangements for ICT services from ICT third-party providers, and to provide the full register or specified sections to competent authorities on request. The simplest way to comply (and stay consistent across entity/sub-consolidated/consolidated levels) is to treat the RoI as a data product: a relational model, governed identifiers, and an automated extraction + validation pipeline that can export ITS templates quickly and accurately. ## What the RoI is (and what it is not) The RoI is a supervisory artifact and an internal risk management instrument: a structured view of ICT third-party dependencies, linked to contracts and services. It's not a procurement vendor list. It's not a one-time spreadsheet. If you can't export it reliably and explain the joins, it won't survive supervision. - Scope: contractual arrangements on the use of ICT services provided by ICT third-party providers (Article 28). - Levels: maintain and update at entity level, and at sub-consolidated and consolidated levels where applicable (Article 28). - On request: be able to provide the full register or specified sections, plus supporting information for effective supervision (Article 28). ## RoI data model blueprint (contract -> service -> function -> provider -> supply chain) Implement the RoI as a normalized relational model with stable identifiers and explicit links between contracting entities, ICT services, functions, providers, and subcontractors. This aligns with the ITS approach: open tables linked by specific keys (contract reference numbers, function identifiers, LEIs/provider identifiers). - Contractual arrangement reference number: define one unique key per contract and never reuse it (your primary join key). - ICT service taxonomy: normalize service names and map each service to business functions and technical dependencies. - Function identifier catalog: define a stable function ID set for critical/important mapping and cross-template joins. - Provider identity normalization: use LEI/EUID where available; standardize naming, group relationships, and service ownership models. - Supply chain representation: model direct providers and relevant subcontractors that effectively underpin ICT services supporting critical/important functions. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU DORA Register of Information (RoI) in one governed evidence system SSOT can take EU DORA Register of Information (RoI) from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU DORA Register of Information (RoI)](/solutions/ssot.md): Start from EU DORA Register of Information (RoI) and keep documents, evidence, and control records in one governed system. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Register of Information (RoI). ## Extraction pipeline (systems-of-record -> RoI dataset -> ITS export) The RoI is an integration problem: procurement, vendor risk, CMDB/service catalog, IAM, cloud inventory, and contract repositories each contain part of the truth. Your target state is export-ready data - not hand-assembled files. - Ingest: contract metadata (legal), vendor + spend (procurement), due diligence (security/vendor risk), service mapping (CMDB/service catalog), locations + hosting (cloud inventory). - Transform: resolve entity/provider identities, enforce stable identifiers, and create relational links (contract->provider, contract->users, service->function, service->subcontractors). - Validate: completeness, uniqueness, and referential integrity checks block exports when critical joins fail. - Export: generate the ITS annex templates (B_01-B_07) from the same dataset so entity vs consolidated views reconcile. ## Governance + operating cadence (how to keep the RoI accurate) RoI compliance is a governance discipline: without clear ownership and change controls, it drifts immediately after launch. Define an operating cadence that makes updates automatic whenever contracts or service dependencies change. - RACI: procurement (vendor onboarding), legal (contract metadata), security (due diligence + monitoring), engineering (service/function mapping), compliance (export readiness). - Change control: provider changes (subcontractors, hosting locations, scope expansions) are treated as material changes and trigger RoI updates. - Quarterly RoI QA: sample critical/important services and verify the full supply chain + exit dependencies are current. - Supervisor readiness drill: timebox an RoI export request and measure speed + consistency across entity and consolidated exports. ## Common pitfalls (use these as acceptance criteria) Most RoI failures are predictable: missing keys, inconsistent naming, and invisible subcontracting chains for critical services. Fix the root causes in your model and pipeline - not in the export file. - No global contract reference key -> joins break across templates and entities. - No service/function mapping -> you can't prove which ICT services support which critical/important functions. - Subcontractors ignored -> supply chain risk and concentration risk are invisible. - Manual exports -> every request becomes a fire drill and produces inconsistent outputs. - Weak validation -> supervisors get different answers depending on who exports the register. ## Build for actual supervisory use, not just annual maintenance Supervisors use RoI data to understand concentration risk, critical-function support chains, and reliance on major providers across the sector. That is why RoI engineering should be treated as production data management, not as a once-a-year compliance exercise. - The first critical ICT third-party provider designation list published on 18 November 2025 shows the RoI now feeds real oversight decisions. - Make provider identity normalization and subcontractor coverage mandatory controls, because those are the records that determine whether systemic dependency is visible. - Run export drills against the ITS structure so entity and consolidated views produce the same provider, contract, and function relationships. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Article 28 establishes the register of information obligation at entity/sub-consolidated/consolidated levels and requires making it available to competent authorities on request. - [Commission Implementing Regulation (EU) 2024/2956 - Standard templates for the register of information (ITS)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Defines the RoI template structure (Annex templates B_01-B_07), relational keys, and data quality expectations for consistent reporting. - [Commission Delegated Regulation (EU) 2024/1773 - Contractual arrangements RTS](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - Due diligence, monitoring, audit/access, and exit planning expectations that should be reflected in RoI fields and evidence links. - [EBA press release - ESAs consult on first batch of DORA policy products](https://www.eba.europa.eu/publications-and-media/press-releases/esas-consult-first-batch-dora-policy-products?ref=sorena.io) - Regulatory activity context for DORA policy products, including register-of-information templates. - [ESMA news - ESAs designate critical ICT third-party providers under DORA](https://www.esma.europa.eu/press-news/esma-news/european-supervisory-authorities-designate-critical-ict-third-party-providers?ref=sorena.io) - Confirms that RoI submissions feed real criticality assessments at EU level. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/register-of-information-how-to-build --- --- title: "DORA Register of Information (RoI) - How to Build It" canonical_url: "https://www.sorena.io/artifacts/eu/dora/register-of-information-how-to-build" source_url: "https://www.sorena.io/artifacts/eu/dora/register-of-information-how-to-build" author: "Sorena AI" description: "Build an audit-ready DORA Register of Information (RoI): define scope and relational keys." keywords: - "DORA register of information" - "DORA RoI" - "DORA RoI how to build" - "DORA Article 28 register" - "DORA ICT third party register" - "outsourcing register DORA" - "ITS 2024/2956 register templates" - "DORA register of information template" - "register of information" - "RoI" - "Article 28" - "ITS 2024/2956" - "ICT third-party register" - "outsourcing register" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA Register of Information (RoI) - How to Build It Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. *Implementation Guide* *EU* ## EU DORA Register of Information (RoI) Build the RoI as a relational dataset you can export on demand - not a spreadsheet nobody trusts. Grounded in Article 28 and ITS 2024/2956 (standard templates for the register of information). DORA requires financial entities to maintain and update a register of information covering contractual arrangements for ICT services from ICT third-party providers, and to provide the full register or specified sections to competent authorities on request. The simplest way to comply (and stay consistent across entity/sub-consolidated/consolidated levels) is to treat the RoI as a data product: a relational model, governed identifiers, and an automated extraction + validation pipeline that can export ITS templates quickly and accurately. ## What the RoI is (and what it is not) The RoI is a supervisory artifact and an internal risk management instrument: a structured view of ICT third-party dependencies, linked to contracts and services. It's not a procurement vendor list. It's not a one-time spreadsheet. If you can't export it reliably and explain the joins, it won't survive supervision. - Scope: contractual arrangements on the use of ICT services provided by ICT third-party providers (Article 28). - Levels: maintain and update at entity level, and at sub-consolidated and consolidated levels where applicable (Article 28). - On request: be able to provide the full register or specified sections, plus supporting information for effective supervision (Article 28). ## RoI data model blueprint (contract -> service -> function -> provider -> supply chain) Implement the RoI as a normalized relational model with stable identifiers and explicit links between contracting entities, ICT services, functions, providers, and subcontractors. This aligns with the ITS approach: open tables linked by specific keys (contract reference numbers, function identifiers, LEIs/provider identifiers). - Contractual arrangement reference number: define one unique key per contract and never reuse it (your primary join key). - ICT service taxonomy: normalize service names and map each service to business functions and technical dependencies. - Function identifier catalog: define a stable function ID set for critical/important mapping and cross-template joins. - Provider identity normalization: use LEI/EUID where available; standardize naming, group relationships, and service ownership models. - Supply chain representation: model direct providers and relevant subcontractors that effectively underpin ICT services supporting critical/important functions. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU DORA Register of Information (RoI) in one governed evidence system SSOT can take EU DORA Register of Information (RoI) from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU DORA Register of Information (RoI)](/solutions/ssot.md): Start from EU DORA Register of Information (RoI) and keep documents, evidence, and control records in one governed system. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Register of Information (RoI). ## Extraction pipeline (systems-of-record -> RoI dataset -> ITS export) The RoI is an integration problem: procurement, vendor risk, CMDB/service catalog, IAM, cloud inventory, and contract repositories each contain part of the truth. Your target state is export-ready data - not hand-assembled files. - Ingest: contract metadata (legal), vendor + spend (procurement), due diligence (security/vendor risk), service mapping (CMDB/service catalog), locations + hosting (cloud inventory). - Transform: resolve entity/provider identities, enforce stable identifiers, and create relational links (contract->provider, contract->users, service->function, service->subcontractors). - Validate: completeness, uniqueness, and referential integrity checks block exports when critical joins fail. - Export: generate the ITS annex templates (B_01-B_07) from the same dataset so entity vs consolidated views reconcile. ## Governance + operating cadence (how to keep the RoI accurate) RoI compliance is a governance discipline: without clear ownership and change controls, it drifts immediately after launch. Define an operating cadence that makes updates automatic whenever contracts or service dependencies change. - RACI: procurement (vendor onboarding), legal (contract metadata), security (due diligence + monitoring), engineering (service/function mapping), compliance (export readiness). - Change control: provider changes (subcontractors, hosting locations, scope expansions) are treated as material changes and trigger RoI updates. - Quarterly RoI QA: sample critical/important services and verify the full supply chain + exit dependencies are current. - Supervisor readiness drill: timebox an RoI export request and measure speed + consistency across entity and consolidated exports. ## Common pitfalls (use these as acceptance criteria) Most RoI failures are predictable: missing keys, inconsistent naming, and invisible subcontracting chains for critical services. Fix the root causes in your model and pipeline - not in the export file. - No global contract reference key -> joins break across templates and entities. - No service/function mapping -> you can't prove which ICT services support which critical/important functions. - Subcontractors ignored -> supply chain risk and concentration risk are invisible. - Manual exports -> every request becomes a fire drill and produces inconsistent outputs. - Weak validation -> supervisors get different answers depending on who exports the register. ## Build for actual supervisory use, not just annual maintenance Supervisors use RoI data to understand concentration risk, critical-function support chains, and reliance on major providers across the sector. That is why RoI engineering should be treated as production data management, not as a once-a-year compliance exercise. - The first critical ICT third-party provider designation list published on 18 November 2025 shows the RoI now feeds real oversight decisions. - Make provider identity normalization and subcontractor coverage mandatory controls, because those are the records that determine whether systemic dependency is visible. - Run export drills against the ITS structure so entity and consolidated views produce the same provider, contract, and function relationships. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Article 28 establishes the register of information obligation at entity/sub-consolidated/consolidated levels and requires making it available to competent authorities on request. - [Commission Implementing Regulation (EU) 2024/2956 - Standard templates for the register of information (ITS)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2956&ref=sorena.io) - Defines the RoI template structure (Annex templates B_01-B_07), relational keys, and data quality expectations for consistent reporting. - [Commission Delegated Regulation (EU) 2024/1773 - Contractual arrangements RTS](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - Due diligence, monitoring, audit/access, and exit planning expectations that should be reflected in RoI fields and evidence links. - [EBA press release - ESAs consult on first batch of DORA policy products](https://www.eba.europa.eu/publications-and-media/press-releases/esas-consult-first-batch-dora-policy-products?ref=sorena.io) - Regulatory activity context for DORA policy products, including register-of-information templates. - [ESMA news - ESAs designate critical ICT third-party providers under DORA](https://www.esma.europa.eu/press-news/esma-news/european-supervisory-authorities-designate-critical-ict-third-party-providers?ref=sorena.io) - Confirms that RoI submissions feed real criticality assessments at EU level. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/register-of-information-how-to-build --- --- title: "EU DORA Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/dora/requirements" source_url: "https://www.sorena.io/artifacts/eu/dora/requirements" author: "Sorena AI" description: "A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II)." keywords: - "EU DORA requirements" - "DORA requirements" - "DORA obligations" - "DORA compliance requirements" - "ICT risk management DORA" - "major ICT incident reporting DORA" - "DORA testing requirements" - "TLPT DORA requirements" - "ICT third party risk DORA" - "DORA contractual clauses" - "DORA register of information" - "ICT risk management" - "incident reporting" - "TLPT" - "third-party risk" - "register of information" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DORA Requirements A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). *Artifact Guide* *EU* ## EU DORA Requirements A requirements map you can translate into controls, owners, and evidence. Structured by how teams implement DORA: controls, reporting, testing, and third-party governance. DORA is an implementation regulation. The fastest way to comply is to build a requirements matrix that maps each obligation to (1) a control or workflow, (2) an owner, (3) acceptance criteria, and (4) evidence you can export on demand. This page summarizes DORA requirements by workstream and highlights the artifacts teams usually miss (statement-of-work quality, register of information, and reporting pipelines). ## Workstream 1 - ICT risk management framework (Chapter II) DORA requires financial entities to have an internal governance and control framework that ensures effective and prudent management of ICT risk and a high level of digital operational resilience. Think "control baseline": governance, asset inventory, protection/detection, response/recovery, business continuity, and communications. - Management body accountability: define, approve, oversee and be responsible for arrangements related to ICT risk management (Article 5/6 context). - Asset inventory and classification: identify, classify and document ICT-supported business functions, information assets, and dependencies; review at least yearly (Article 8). - Protection and prevention controls: policies/tools to safeguard availability, authenticity, integrity and confidentiality of data and services (Chapter II control layers). - Detection and monitoring: mechanisms to detect anomalous activities and ICT-related incidents (Chapter II + Article 17 interface). - Business continuity and response/recovery plans: contain incidents, restore services, and run post-incident reviews to prevent recurrence (Articles 11-13). ## Workstream 2 - ICT incident management and reporting (Chapter III) DORA requires an ICT incident management process to detect, manage and notify incidents, record all ICT-related incidents and significant cyber threats, and report major ICT-related incidents to competent authorities. This is both an operational workflow and a data/reporting pipeline. - Incident management process: early warning indicators, tracking/logging/classification, roles and responsibilities, communication plans, and response procedures (Article 17). - Classification: classify incidents by priority/severity and criticality of services impacted; apply criteria and thresholds specified in DORA and RTS (Article 18 + RTS). - Reporting: submit initial notification, intermediate updates, and final report within RTS time limits; include information needed to assess significance and cross-border impacts (Article 19 + RTS). - Client communications: inform clients without undue delay where major incidents impact financial interests; inform potentially affected clients about protection measures for significant cyber threats where applicable (Article 19). ## Workstream 3 - Digital operational resilience testing and TLPT (Chapter IV) DORA requires an ongoing testing program for ICT tools, systems and processes, including vulnerability assessments, scenario-based tests, and penetration testing. For certain entities, DORA introduces advanced threat-led penetration testing (TLPT) on live production systems at least every three years. - Testing program: run tests appropriate to risk profile and criticality; ensure independence for non-microenterprises; remediate and validate weaknesses (Articles 24-25). - TLPT: advanced testing at least every 3 years for identified entities; cover critical or important functions; performed on live production systems; scope validated by competent authorities (Article 26). - Tester suitability: highest suitability and reputability; threat intelligence + penetration testing expertise; independence assurance; professional indemnity insurance (Article 27 context). ## Workstream 4 - ICT third-party risk management (Chapter V) DORA makes third-party risk a first-class compliance domain: financial entities remain fully responsible for compliance and must manage ICT third-party risk as part of ICT risk management. Operationally, this workstream is procurement/legal/security combined: contracts, oversight rights, exit plans, and evidence. - Third-party strategy: adopt and regularly review an ICT third-party risk strategy (with proportionality), including policy for ICT services supporting critical/important functions (Article 28). - Register of information: maintain and update a register covering all contractual arrangements for ICT services; provide the full register or sections on request (Article 28). - Concentration risk: assess substitutability and multi-vendor dependencies; consider subcontracting chains and third-country risks (Article 29). - Contract minimum clauses: allocate rights/obligations clearly in writing; include minimum contractual elements (Article 30) and RTS contractual arrangements requirements. ## Workstream 5 - Oversight of critical ICT third-party service providers DORA establishes an EU oversight framework for critical ICT third-party service providers (CTPPs) supporting the financial sector. For financial entities, the practical implication is stronger contract posture and exit strategy planning. For ICT providers, it's oversight readiness and evidence maturity. - Understand designation: criteria and process for designating ICT third-party providers as critical are specified in delegated regulation (Level 2). - Plan contractual adjustments: authorities can require adjustments to avoid resilience harms; build exit strategies and transition plans as standard artifacts. - Account for oversight costs: oversight fee methodologies apply to critical providers under delegated regulation. ## Evidence mapping model (requirement -> control -> evidence) Compliance becomes low-friction when evidence is designed-in. Use this mapping model to build an exportable evidence pack. Aim to make every requirement verifiable via a small set of repeatable artifacts. - Policies: ICT risk management policy set, incident management policy, testing policy, third-party risk strategy, exit strategy policy. - Procedures/runbooks: notice/reporting runbooks, escalation paths, TLPT runbooks, vendor onboarding/checklists, contract clause playbooks. - Records/logs: asset inventory, incident records, reports submitted, remediation tickets, test results, register of information exports. - Governance evidence: management body approvals, periodic reviews, proportionality decisions, and KPI dashboards. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU DORA Requirements into an operational assessment Assessment Autopilot can take EU DORA Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU DORA Requirements](/solutions/assessment.md): Start from EU DORA Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Requirements. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary DORA requirements across the four main workstreams: ICT risk management (Chapter II), incident reporting (Chapter III), testing/TLPT (Chapter IV), and ICT third-party risk including contract clauses and the register of information (Chapter V). - [Commission Delegated Regulation (EU) 2024/1774 - ICT risk management tools and simplified framework (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng?ref=sorena.io) - Level 2 RTS specifying ICT risk management tools, methods, processes, policies, and the simplified framework referenced by DORA. - [Commission Delegated Regulation (EU) 2024/1773 - Contractual arrangements for ICT services supporting critical or important functions (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - Level 2 RTS specifying detailed contractual requirements for ICT services supporting critical or important functions. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/requirements --- --- title: "EU DORA Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/dora/requirements" source_url: "https://www.sorena.io/artifacts/eu/dora/requirements" author: "Sorena AI" description: "A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II)." keywords: - "EU DORA requirements" - "DORA requirements" - "DORA obligations" - "DORA compliance requirements" - "ICT risk management DORA" - "major ICT incident reporting DORA" - "DORA testing requirements" - "TLPT DORA requirements" - "ICT third party risk DORA" - "DORA contractual clauses" - "DORA register of information" - "ICT risk management" - "incident reporting" - "TLPT" - "third-party risk" - "register of information" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DORA Requirements A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). *Artifact Guide* *EU* ## EU DORA Requirements A requirements map you can translate into controls, owners, and evidence. Structured by how teams implement DORA: controls, reporting, testing, and third-party governance. DORA is an implementation regulation. The fastest way to comply is to build a requirements matrix that maps each obligation to (1) a control or workflow, (2) an owner, (3) acceptance criteria, and (4) evidence you can export on demand. This page summarizes DORA requirements by workstream and highlights the artifacts teams usually miss (statement-of-work quality, register of information, and reporting pipelines). ## Workstream 1 - ICT risk management framework (Chapter II) DORA requires financial entities to have an internal governance and control framework that ensures effective and prudent management of ICT risk and a high level of digital operational resilience. Think "control baseline": governance, asset inventory, protection/detection, response/recovery, business continuity, and communications. - Management body accountability: define, approve, oversee and be responsible for arrangements related to ICT risk management (Article 5/6 context). - Asset inventory and classification: identify, classify and document ICT-supported business functions, information assets, and dependencies; review at least yearly (Article 8). - Protection and prevention controls: policies/tools to safeguard availability, authenticity, integrity and confidentiality of data and services (Chapter II control layers). - Detection and monitoring: mechanisms to detect anomalous activities and ICT-related incidents (Chapter II + Article 17 interface). - Business continuity and response/recovery plans: contain incidents, restore services, and run post-incident reviews to prevent recurrence (Articles 11-13). ## Workstream 2 - ICT incident management and reporting (Chapter III) DORA requires an ICT incident management process to detect, manage and notify incidents, record all ICT-related incidents and significant cyber threats, and report major ICT-related incidents to competent authorities. This is both an operational workflow and a data/reporting pipeline. - Incident management process: early warning indicators, tracking/logging/classification, roles and responsibilities, communication plans, and response procedures (Article 17). - Classification: classify incidents by priority/severity and criticality of services impacted; apply criteria and thresholds specified in DORA and RTS (Article 18 + RTS). - Reporting: submit initial notification, intermediate updates, and final report within RTS time limits; include information needed to assess significance and cross-border impacts (Article 19 + RTS). - Client communications: inform clients without undue delay where major incidents impact financial interests; inform potentially affected clients about protection measures for significant cyber threats where applicable (Article 19). ## Workstream 3 - Digital operational resilience testing and TLPT (Chapter IV) DORA requires an ongoing testing program for ICT tools, systems and processes, including vulnerability assessments, scenario-based tests, and penetration testing. For certain entities, DORA introduces advanced threat-led penetration testing (TLPT) on live production systems at least every three years. - Testing program: run tests appropriate to risk profile and criticality; ensure independence for non-microenterprises; remediate and validate weaknesses (Articles 24-25). - TLPT: advanced testing at least every 3 years for identified entities; cover critical or important functions; performed on live production systems; scope validated by competent authorities (Article 26). - Tester suitability: highest suitability and reputability; threat intelligence + penetration testing expertise; independence assurance; professional indemnity insurance (Article 27 context). ## Workstream 4 - ICT third-party risk management (Chapter V) DORA makes third-party risk a first-class compliance domain: financial entities remain fully responsible for compliance and must manage ICT third-party risk as part of ICT risk management. Operationally, this workstream is procurement/legal/security combined: contracts, oversight rights, exit plans, and evidence. - Third-party strategy: adopt and regularly review an ICT third-party risk strategy (with proportionality), including policy for ICT services supporting critical/important functions (Article 28). - Register of information: maintain and update a register covering all contractual arrangements for ICT services; provide the full register or sections on request (Article 28). - Concentration risk: assess substitutability and multi-vendor dependencies; consider subcontracting chains and third-country risks (Article 29). - Contract minimum clauses: allocate rights/obligations clearly in writing; include minimum contractual elements (Article 30) and RTS contractual arrangements requirements. ## Workstream 5 - Oversight of critical ICT third-party service providers DORA establishes an EU oversight framework for critical ICT third-party service providers (CTPPs) supporting the financial sector. For financial entities, the practical implication is stronger contract posture and exit strategy planning. For ICT providers, it's oversight readiness and evidence maturity. - Understand designation: criteria and process for designating ICT third-party providers as critical are specified in delegated regulation (Level 2). - Plan contractual adjustments: authorities can require adjustments to avoid resilience harms; build exit strategies and transition plans as standard artifacts. - Account for oversight costs: oversight fee methodologies apply to critical providers under delegated regulation. ## Evidence mapping model (requirement -> control -> evidence) Compliance becomes low-friction when evidence is designed-in. Use this mapping model to build an exportable evidence pack. Aim to make every requirement verifiable via a small set of repeatable artifacts. - Policies: ICT risk management policy set, incident management policy, testing policy, third-party risk strategy, exit strategy policy. - Procedures/runbooks: notice/reporting runbooks, escalation paths, TLPT runbooks, vendor onboarding/checklists, contract clause playbooks. - Records/logs: asset inventory, incident records, reports submitted, remediation tickets, test results, register of information exports. - Governance evidence: management body approvals, periodic reviews, proportionality decisions, and KPI dashboards. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU DORA Requirements into an operational assessment Assessment Autopilot can take EU DORA Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU DORA Requirements](/solutions/assessment.md): Start from EU DORA Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Requirements. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary DORA requirements across the four main workstreams: ICT risk management (Chapter II), incident reporting (Chapter III), testing/TLPT (Chapter IV), and ICT third-party risk including contract clauses and the register of information (Chapter V). - [Commission Delegated Regulation (EU) 2024/1774 - ICT risk management tools and simplified framework (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng?ref=sorena.io) - Level 2 RTS specifying ICT risk management tools, methods, processes, policies, and the simplified framework referenced by DORA. - [Commission Delegated Regulation (EU) 2024/1773 - Contractual arrangements for ICT services supporting critical or important functions (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - Level 2 RTS specifying detailed contractual requirements for ICT services supporting critical or important functions. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/requirements --- --- title: "EU DORA Scope & Covered Entities" canonical_url: "https://www.sorena.io/artifacts/eu/dora/scope-and-covered-entities" source_url: "https://www.sorena.io/artifacts/eu/dora/scope-and-covered-entities" author: "Sorena AI" description: "A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks." keywords: - "EU DORA scope" - "DORA covered entities" - "DORA Article 2" - "Digital Operational Resilience Act scope" - "DORA applicability" - "DORA proportionality" - "simplified ICT risk management framework" - "DORA register of information" - "DORA ICT third party risk" - "DORA scope" - "covered entities" - "financial entities" - "proportionality" - "ICT third-party providers" - "register of information" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DORA Scope & Covered Entities A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. *Artifact Guide* *EU* ## EU DORA Scope & Covered Entities A defensible way to decide if DORA applies to you - and what layer applies. Built for regulators and audits: scope memo, evidence inputs, and owner assignments. DORA scope is not a vibe-check. It's a written classification of (1) whether you are a covered financial entity under Article 2, (2) what proportionality/simplified framework applies, and (3) which services in your group are in scope (entity, sub-consolidated and consolidated). This page helps you produce a scope memo you can defend and maintain as your business evolves. ## What DORA covers (and why scope matters operationally) DORA is a sector-specific operational resilience regulation for the financial sector. Its workstreams are concrete: ICT risk management controls, ICT incident management and reporting, resilience testing including TLPT, and ICT third-party risk governance. Scope decisions drive the cost profile of compliance. For example: TLPT readiness, incident reporting pipelines, and register of information build-outs are not "optional" once in scope. - Treat scope as a living artifact: update it when entity type, licensing, or group structure changes. - Run scope per entity and per group layer: entity-level plus sub-consolidated/consolidated registers and governance where required. - Ship a scope memo: service facts -> classification -> obligations -> owners -> evidence. *Recommended next step* *Placement: after the scope or definition section* ## Use EU DORA Scope & Covered Entities as a cited research workflow Research Copilot can take EU DORA Scope & Covered Entities from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU DORA Scope & Covered Entities](/solutions/research-copilot.md): Start from EU DORA Scope & Covered Entities and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Scope & Covered Entities. ## Step 1 - Are you a covered financial entity (Article 2)? DORA's primary scope is financial entities listed in Article 2. Start by identifying your authorization/licensing category and map it to the Article 2 list. Many organizations have multiple regulated entities (bank + investment firm + payment services). Scope each regulated entity separately, then build a group view. - Identify your legal entities and licenses; map each to a covered category in Article 2. - Document competent authority and supervisory perimeter per entity (useful for incident reporting routing). - Record what you are not: if you're not a covered financial entity, you may still be impacted as an ICT third-party provider supporting critical or important functions. ## Step 2 - Proportionality and simplified frameworks (what can be scaled down) DORA is explicit about proportionality. Requirements are applied considering the nature, scale, complexity and risk profile of the entity and its ICT dependencies. Some entities can use simplified ICT risk management frameworks and reduced testing requirements; document the basis for the simplification. - Define your proportionality basis: size, business model, criticality of services, and ICT dependency profile. - Document simplified controls: what is simplified, what is not, and why the residual risk is acceptable. - Keep "proportionality evidence": risk assessments, management body decisions, and review cadence. ## Step 3 - Group-level scope: entity vs sub-consolidated vs consolidated DORA third-party risk governance and the register of information explicitly operate at multiple levels: entity level and (where relevant) sub-consolidated and consolidated levels. This is where programs fail if the operating model is unclear: procurement and vendor management often sit centrally while supervision is entity-based. - Define a group operating model: who owns the central policy vs entity-specific implementation. - Maintain the register of information at entity level and, where required, at sub-consolidated and consolidated levels. - Plan a supervisory response model: which authority asks for which register section and who can produce it quickly. ## Step 4 - ICT third-party providers and the "critical provider" layer DORA also creates an EU oversight framework for critical ICT third-party service providers (CTPPs). Even if you're not a financial entity, you can be impacted if you provide ICT services supporting critical or important functions for in-scope entities. Financial entities must manage third-party risk and maintain a register of information covering all contractual arrangements for ICT services. - Financial entities: implement ICT third-party risk strategy, contractual minimum clauses, concentration risk assessments, and exit plans; keep the register of information. - ICT providers: be prepared for contractual clauses aligned to DORA RTS and, if designated critical, oversight interactions and requirements. - Program implication: procurement/legal/security must align on contract playbooks and evidence artifacts. ## Scope memo template (copy/paste) A scope memo is a short document you update over time. It is your single source of truth for: what applies, to whom, and what program owners must deliver. Use this structure to avoid ambiguity and scope drift. - 1) Entity inventory: legal entities, licenses, supervisors, and covered category mapping (Article 2). - 2) Service inventory: critical/important functions and ICT-supported business functions; key ICT dependencies. - 3) Proportionality statement: simplified framework decisions and rationale. - 4) Obligation map: ICT risk controls (Chapter II), incident reporting (Chapter III), testing/TLPT (Chapter IV), third-party risk + register (Chapter V). - 5) Owner map: RACI for each workstream; evidence pack location and retrieval process. - 6) Change triggers: what changes force re-scoping (new product, new license, new outsourcing model). ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary legal text for DORA scope (Article 2) and the layered compliance workstreams: ICT risk management, incident reporting, testing/TLPT, and ICT third-party risk including the register of information (Article 28). ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/scope-and-covered-entities --- --- title: "EU DORA Scope & Covered Entities" canonical_url: "https://www.sorena.io/artifacts/eu/dora/scope-and-covered-entities" source_url: "https://www.sorena.io/artifacts/eu/dora/scope-and-covered-entities" author: "Sorena AI" description: "A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks." keywords: - "EU DORA scope" - "DORA covered entities" - "DORA Article 2" - "Digital Operational Resilience Act scope" - "DORA applicability" - "DORA proportionality" - "simplified ICT risk management framework" - "DORA register of information" - "DORA ICT third party risk" - "DORA scope" - "covered entities" - "financial entities" - "proportionality" - "ICT third-party providers" - "register of information" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU DORA Scope & Covered Entities A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. *Artifact Guide* *EU* ## EU DORA Scope & Covered Entities A defensible way to decide if DORA applies to you - and what layer applies. Built for regulators and audits: scope memo, evidence inputs, and owner assignments. DORA scope is not a vibe-check. It's a written classification of (1) whether you are a covered financial entity under Article 2, (2) what proportionality/simplified framework applies, and (3) which services in your group are in scope (entity, sub-consolidated and consolidated). This page helps you produce a scope memo you can defend and maintain as your business evolves. ## What DORA covers (and why scope matters operationally) DORA is a sector-specific operational resilience regulation for the financial sector. Its workstreams are concrete: ICT risk management controls, ICT incident management and reporting, resilience testing including TLPT, and ICT third-party risk governance. Scope decisions drive the cost profile of compliance. For example: TLPT readiness, incident reporting pipelines, and register of information build-outs are not "optional" once in scope. - Treat scope as a living artifact: update it when entity type, licensing, or group structure changes. - Run scope per entity and per group layer: entity-level plus sub-consolidated/consolidated registers and governance where required. - Ship a scope memo: service facts -> classification -> obligations -> owners -> evidence. *Recommended next step* *Placement: after the scope or definition section* ## Use EU DORA Scope & Covered Entities as a cited research workflow Research Copilot can take EU DORA Scope & Covered Entities from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU DORA Scope & Covered Entities](/solutions/research-copilot.md): Start from EU DORA Scope & Covered Entities and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Scope & Covered Entities. ## Step 1 - Are you a covered financial entity (Article 2)? DORA's primary scope is financial entities listed in Article 2. Start by identifying your authorization/licensing category and map it to the Article 2 list. Many organizations have multiple regulated entities (bank + investment firm + payment services). Scope each regulated entity separately, then build a group view. - Identify your legal entities and licenses; map each to a covered category in Article 2. - Document competent authority and supervisory perimeter per entity (useful for incident reporting routing). - Record what you are not: if you're not a covered financial entity, you may still be impacted as an ICT third-party provider supporting critical or important functions. ## Step 2 - Proportionality and simplified frameworks (what can be scaled down) DORA is explicit about proportionality. Requirements are applied considering the nature, scale, complexity and risk profile of the entity and its ICT dependencies. Some entities can use simplified ICT risk management frameworks and reduced testing requirements; document the basis for the simplification. - Define your proportionality basis: size, business model, criticality of services, and ICT dependency profile. - Document simplified controls: what is simplified, what is not, and why the residual risk is acceptable. - Keep "proportionality evidence": risk assessments, management body decisions, and review cadence. ## Step 3 - Group-level scope: entity vs sub-consolidated vs consolidated DORA third-party risk governance and the register of information explicitly operate at multiple levels: entity level and (where relevant) sub-consolidated and consolidated levels. This is where programs fail if the operating model is unclear: procurement and vendor management often sit centrally while supervision is entity-based. - Define a group operating model: who owns the central policy vs entity-specific implementation. - Maintain the register of information at entity level and, where required, at sub-consolidated and consolidated levels. - Plan a supervisory response model: which authority asks for which register section and who can produce it quickly. ## Step 4 - ICT third-party providers and the "critical provider" layer DORA also creates an EU oversight framework for critical ICT third-party service providers (CTPPs). Even if you're not a financial entity, you can be impacted if you provide ICT services supporting critical or important functions for in-scope entities. Financial entities must manage third-party risk and maintain a register of information covering all contractual arrangements for ICT services. - Financial entities: implement ICT third-party risk strategy, contractual minimum clauses, concentration risk assessments, and exit plans; keep the register of information. - ICT providers: be prepared for contractual clauses aligned to DORA RTS and, if designated critical, oversight interactions and requirements. - Program implication: procurement/legal/security must align on contract playbooks and evidence artifacts. ## Scope memo template (copy/paste) A scope memo is a short document you update over time. It is your single source of truth for: what applies, to whom, and what program owners must deliver. Use this structure to avoid ambiguity and scope drift. - 1) Entity inventory: legal entities, licenses, supervisors, and covered category mapping (Article 2). - 2) Service inventory: critical/important functions and ICT-supported business functions; key ICT dependencies. - 3) Proportionality statement: simplified framework decisions and rationale. - 4) Obligation map: ICT risk controls (Chapter II), incident reporting (Chapter III), testing/TLPT (Chapter IV), third-party risk + register (Chapter V). - 5) Owner map: RACI for each workstream; evidence pack location and retrieval process. - 6) Change triggers: what changes force re-scoping (new product, new license, new outsourcing model). ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary legal text for DORA scope (Article 2) and the layered compliance workstreams: ICT risk management, incident reporting, testing/TLPT, and ICT third-party risk including the register of information (Article 28). ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/scope-and-covered-entities --- --- title: "DORA Testing & TLPT Readiness" canonical_url: "https://www.sorena.io/artifacts/eu/dora/testing-and-tlpt-readiness" source_url: "https://www.sorena.io/artifacts/eu/dora/testing-and-tlpt-readiness" author: "Sorena AI" description: "A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation." keywords: - "DORA testing" - "DORA digital operational resilience testing" - "DORA Chapter IV testing" - "TLPT DORA" - "threat-led penetration testing DORA" - "DORA Article 26 TLPT" - "TIBER-EU framework TLPT" - "DORA penetration testing requirements" - "cyber stress test guidance ENISA" - "digital operational resilience testing" - "TLPT" - "threat-led penetration testing" - "TIBER-EU" - "resilience exercises" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA Testing & TLPT Readiness A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. *Testing Guide* *EU* ## EU DORA Testing & TLPT Readiness Build a repeatable testing program - and a TLPT capability that is production-safe and audit-ready. Grounded in DORA Chapter IV and aligned to the ECB's TIBER-EU execution guidance. DORA testing is a program, not a penetration test. Chapter IV expects a risk-based resilience testing programme that covers critical or important functions, produces remediation backlog, and validates fixes. For certain entities, DORA requires advanced testing via threat-led penetration testing (TLPT) on live production systems at least every three years. This guide shows how to build the program and evidence model, and how to use the ECB's TIBER-EU framework as an execution handbook. ## Testing program vs TLPT (how DORA structures testing) DORA distinguishes a general testing programme (Articles 24-25) from advanced TLPT (Article 26). Build the programme first; TLPT then becomes a specialized, governed test type within it. - Testing programme: continuous, risk-based testing across ICT systems and processes supporting critical or important functions. - TLPT: advanced, intelligence-led test on live production systems, covering several or all critical or important functions, with authority-validated scope. - Evidence model: both require test reports, remediation tracking, and validation that weaknesses are addressed. *Recommended next step* *Placement: after the main workflow section* ## Turn EU DORA Testing & TLPT Readiness into an operational assessment Assessment Autopilot can take EU DORA Testing & TLPT Readiness from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU DORA Testing & TLPT Readiness](/solutions/assessment.md): Start from EU DORA Testing & TLPT Readiness and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Testing & TLPT Readiness. ## Article 24 - Digital operational resilience testing programme (operating model) Your testing programme should define: what you test, how often, who tests (independence), how you remediate, and how you validate fixes. Treat tests as inputs to engineering and risk governance, not as compliance PDFs. - Annual testing plan: scope coverage for critical or important functions; include scenario-based and technical tests. - Independence: for non-microenterprises, ensure tests are performed by independent parties (internal or external) and conflicts are avoided. - Remediation governance: prioritize, classify and remedy issues; validate closure with retesting and evidence (Article 24(5)). - Coverage: ensure at least yearly appropriate tests on all ICT systems and applications supporting critical or important functions (Article 24(6)). ## Article 25 - Testing methods catalogue (make it measurable) Article 25 lists example test types: vulnerability assessments, open source analyses, network security assessments, gap analyses, physical security reviews, source code reviews, scenario-based tests, end-to-end tests, and penetration testing. Build a "test catalog" with acceptance criteria and evidence outputs per test type. - Create a test catalog: test type -> objective -> target systems -> cadence -> evidence output -> owner. - Define "critical function coverage": minimum test coverage per critical or important function. - Automate where possible: scanning and continuous controls reduce manual effort and improve cadence. - Link to incident learnings: post-incident reviews should adjust testing scope and priorities. ## Article 26 - TLPT program readiness (design before you test) TLPT is high-stakes because it runs on live production systems and mimics sophisticated attackers. Design the governance and safety controls before you select a vendor or define scope. - Scope definition: identify underlying ICT systems, processes and technologies supporting critical/important functions; decide which functions must be covered; scope validated by competent authorities (Article 26). - Production safety: define guardrails, kill-switches, and comms rules; isolate unacceptable business risks. - Authority interactions: plan timeline for scope validation, approvals, and reporting expectations. - Evidence: TLPT scope documents, approvals, safety plan, test outputs, and remediation validation. ## RTS 2025/1190: identify whether you are likely to enter the TLPT population The practical TLPT question is not only how to run a test. It is whether your entity is the kind of entity that competent authorities may identify for TLPT under the RTS. Use that as an early-readiness filter so you do not wait for a supervisory signal before building governance, procurement criteria, and production-safety controls. - Track your systemic importance, cross-border footprint, and dependency on ICT supporting critical or important functions. - Treat TLPT readiness as a staged capability even if you are not yet formally identified: scope inventories, control-team model, authority interaction plan, and provider due diligence. - If you are likely to enter scope, align early with TIBER-EU so the execution method does not become the bottleneck. ## Article 27 - Tester requirements (vendor selection acceptance criteria) DORA sets explicit expectations for TLPT testers: suitability, expertise, independence assurance, and insurance coverage. Make these requirements procurement gate criteria. - Suitability and reputability; technical and organizational capabilities; specific expertise in threat intelligence, penetration testing and red teaming. - Certification or adherence to formal codes of conduct/ethical frameworks. - Independent assurance or audit report on sound management of TLPT risks and protection of confidential information. - Professional indemnity insurance covering misconduct and negligence. - Internal testers: require authority approval and conflict-of-interest protections; threat intelligence provider must be external. ## Using TIBER-EU as an execution handbook (practical TLPT implementation) The ECB's TIBER-EU framework provides a structured, intelligence-led red teaming methodology and roles (blue team, threat intelligence provider, red team testers, control team, and oversight teams). Use it to implement TLPT with a consistent, controlled process aligned to DORA expectations. - Define roles: blue team vs control team separation; threat intelligence and red team provider governance. - Follow phased execution: threat intelligence -> testing execution -> closure and improvements. - Procurement guidance: use published procurement guidance to select service providers and structure deliverables. - Evidence: keep deliverables by phase (TTI report, attack narratives, findings, remediation plans, retest evidence). ## Evidence pack checklist (audit-ready testing artifacts) Testing evidence needs to show: coverage, independence, remediation, and learning. Use this checklist to ensure outputs are exportable and consistent across entities. - Testing policy + annual testing plan + coverage map for critical/important functions. - Test catalog definitions and evidence outputs per test type. - Remediation and validation artifacts: tickets, retest reports, closure evidence. - TLPT program artifacts (where applicable): scope validation, tester due diligence, safety plan, TLPT reports, remediation and retest evidence. - Linkage to incident management: post-incident reviews driving test plan adjustments. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - DORA Chapter IV testing programme requirements (Articles 24-25) and TLPT obligations and tester requirements (Articles 26-27). - [ECB - TIBER-EU framework (January 2025)](https://www.ecb.europa.eu/pub/pdf/other/ecb.tiber_eu_framework_2025~b32eff9a10.en.pdf?0309990e5e167a47ca4748370a949064&ref=sorena.io) - ECB execution guidance for threat intelligence-based ethical red teaming, commonly used as a structured TLPT implementation handbook in EU financial sector contexts. - [ENISA - Handbook for Cyber Stress Tests (May 2025)](https://www.enisa.europa.eu/publications/handbook-for-cyber-stress-tests?ref=sorena.io) - Supervisory guidance for cyber stress testing approaches referenced as useful under NIS2/DORA/CER contexts. - [Commission Delegated Regulation (EU) 2025/1190 - TLPT identification criteria (RTS)](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng?ref=sorena.io) - Specifies the criteria used to identify financial entities required to perform threat-led penetration testing. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/testing-and-tlpt-readiness --- --- title: "DORA Testing & TLPT Readiness" canonical_url: "https://www.sorena.io/artifacts/eu/dora/testing-and-tlpt-readiness" source_url: "https://www.sorena.io/artifacts/eu/dora/testing-and-tlpt-readiness" author: "Sorena AI" description: "A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation." keywords: - "DORA testing" - "DORA digital operational resilience testing" - "DORA Chapter IV testing" - "TLPT DORA" - "threat-led penetration testing DORA" - "DORA Article 26 TLPT" - "TIBER-EU framework TLPT" - "DORA penetration testing requirements" - "cyber stress test guidance ENISA" - "digital operational resilience testing" - "TLPT" - "threat-led penetration testing" - "TIBER-EU" - "resilience exercises" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA Testing & TLPT Readiness A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. *Testing Guide* *EU* ## EU DORA Testing & TLPT Readiness Build a repeatable testing program - and a TLPT capability that is production-safe and audit-ready. Grounded in DORA Chapter IV and aligned to the ECB's TIBER-EU execution guidance. DORA testing is a program, not a penetration test. Chapter IV expects a risk-based resilience testing programme that covers critical or important functions, produces remediation backlog, and validates fixes. For certain entities, DORA requires advanced testing via threat-led penetration testing (TLPT) on live production systems at least every three years. This guide shows how to build the program and evidence model, and how to use the ECB's TIBER-EU framework as an execution handbook. ## Testing program vs TLPT (how DORA structures testing) DORA distinguishes a general testing programme (Articles 24-25) from advanced TLPT (Article 26). Build the programme first; TLPT then becomes a specialized, governed test type within it. - Testing programme: continuous, risk-based testing across ICT systems and processes supporting critical or important functions. - TLPT: advanced, intelligence-led test on live production systems, covering several or all critical or important functions, with authority-validated scope. - Evidence model: both require test reports, remediation tracking, and validation that weaknesses are addressed. *Recommended next step* *Placement: after the main workflow section* ## Turn EU DORA Testing & TLPT Readiness into an operational assessment Assessment Autopilot can take EU DORA Testing & TLPT Readiness from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU DORA Testing & TLPT Readiness](/solutions/assessment.md): Start from EU DORA Testing & TLPT Readiness and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Testing & TLPT Readiness. ## Article 24 - Digital operational resilience testing programme (operating model) Your testing programme should define: what you test, how often, who tests (independence), how you remediate, and how you validate fixes. Treat tests as inputs to engineering and risk governance, not as compliance PDFs. - Annual testing plan: scope coverage for critical or important functions; include scenario-based and technical tests. - Independence: for non-microenterprises, ensure tests are performed by independent parties (internal or external) and conflicts are avoided. - Remediation governance: prioritize, classify and remedy issues; validate closure with retesting and evidence (Article 24(5)). - Coverage: ensure at least yearly appropriate tests on all ICT systems and applications supporting critical or important functions (Article 24(6)). ## Article 25 - Testing methods catalogue (make it measurable) Article 25 lists example test types: vulnerability assessments, open source analyses, network security assessments, gap analyses, physical security reviews, source code reviews, scenario-based tests, end-to-end tests, and penetration testing. Build a "test catalog" with acceptance criteria and evidence outputs per test type. - Create a test catalog: test type -> objective -> target systems -> cadence -> evidence output -> owner. - Define "critical function coverage": minimum test coverage per critical or important function. - Automate where possible: scanning and continuous controls reduce manual effort and improve cadence. - Link to incident learnings: post-incident reviews should adjust testing scope and priorities. ## Article 26 - TLPT program readiness (design before you test) TLPT is high-stakes because it runs on live production systems and mimics sophisticated attackers. Design the governance and safety controls before you select a vendor or define scope. - Scope definition: identify underlying ICT systems, processes and technologies supporting critical/important functions; decide which functions must be covered; scope validated by competent authorities (Article 26). - Production safety: define guardrails, kill-switches, and comms rules; isolate unacceptable business risks. - Authority interactions: plan timeline for scope validation, approvals, and reporting expectations. - Evidence: TLPT scope documents, approvals, safety plan, test outputs, and remediation validation. ## RTS 2025/1190: identify whether you are likely to enter the TLPT population The practical TLPT question is not only how to run a test. It is whether your entity is the kind of entity that competent authorities may identify for TLPT under the RTS. Use that as an early-readiness filter so you do not wait for a supervisory signal before building governance, procurement criteria, and production-safety controls. - Track your systemic importance, cross-border footprint, and dependency on ICT supporting critical or important functions. - Treat TLPT readiness as a staged capability even if you are not yet formally identified: scope inventories, control-team model, authority interaction plan, and provider due diligence. - If you are likely to enter scope, align early with TIBER-EU so the execution method does not become the bottleneck. ## Article 27 - Tester requirements (vendor selection acceptance criteria) DORA sets explicit expectations for TLPT testers: suitability, expertise, independence assurance, and insurance coverage. Make these requirements procurement gate criteria. - Suitability and reputability; technical and organizational capabilities; specific expertise in threat intelligence, penetration testing and red teaming. - Certification or adherence to formal codes of conduct/ethical frameworks. - Independent assurance or audit report on sound management of TLPT risks and protection of confidential information. - Professional indemnity insurance covering misconduct and negligence. - Internal testers: require authority approval and conflict-of-interest protections; threat intelligence provider must be external. ## Using TIBER-EU as an execution handbook (practical TLPT implementation) The ECB's TIBER-EU framework provides a structured, intelligence-led red teaming methodology and roles (blue team, threat intelligence provider, red team testers, control team, and oversight teams). Use it to implement TLPT with a consistent, controlled process aligned to DORA expectations. - Define roles: blue team vs control team separation; threat intelligence and red team provider governance. - Follow phased execution: threat intelligence -> testing execution -> closure and improvements. - Procurement guidance: use published procurement guidance to select service providers and structure deliverables. - Evidence: keep deliverables by phase (TTI report, attack narratives, findings, remediation plans, retest evidence). ## Evidence pack checklist (audit-ready testing artifacts) Testing evidence needs to show: coverage, independence, remediation, and learning. Use this checklist to ensure outputs are exportable and consistent across entities. - Testing policy + annual testing plan + coverage map for critical/important functions. - Test catalog definitions and evidence outputs per test type. - Remediation and validation artifacts: tickets, retest reports, closure evidence. - TLPT program artifacts (where applicable): scope validation, tester due diligence, safety plan, TLPT reports, remediation and retest evidence. - Linkage to incident management: post-incident reviews driving test plan adjustments. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - DORA Chapter IV testing programme requirements (Articles 24-25) and TLPT obligations and tester requirements (Articles 26-27). - [ECB - TIBER-EU framework (January 2025)](https://www.ecb.europa.eu/pub/pdf/other/ecb.tiber_eu_framework_2025~b32eff9a10.en.pdf?0309990e5e167a47ca4748370a949064&ref=sorena.io) - ECB execution guidance for threat intelligence-based ethical red teaming, commonly used as a structured TLPT implementation handbook in EU financial sector contexts. - [ENISA - Handbook for Cyber Stress Tests (May 2025)](https://www.enisa.europa.eu/publications/handbook-for-cyber-stress-tests?ref=sorena.io) - Supervisory guidance for cyber stress testing approaches referenced as useful under NIS2/DORA/CER contexts. - [Commission Delegated Regulation (EU) 2025/1190 - TLPT identification criteria (RTS)](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng?ref=sorena.io) - Specifies the criteria used to identify financial entities required to perform threat-led penetration testing. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA ICT Third-Party Risk Management + Contract Clauses | Article 28-30 + RTS 2024/1773 + RTS 2025/532](/artifacts/eu/dora/third-party-risk-and-contract-clauses.md): A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/testing-and-tlpt-readiness --- --- title: "DORA ICT Third-Party Risk Management + Contract Clauses" canonical_url: "https://www.sorena.io/artifacts/eu/dora/third-party-risk-and-contract-clauses" source_url: "https://www.sorena.io/artifacts/eu/dora/third-party-risk-and-contract-clauses" author: "Sorena AI" description: "A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring." keywords: - "DORA third party risk" - "DORA ICT third party risk management" - "DORA third party contract clauses" - "RTS 2024/1773 contract clauses" - "DORA audit rights cloud contract" - "DORA subcontracting RTS 2025/532" - "DORA exit strategy" - "DORA outsourcing register of information" - "DORA concentration risk cloud" - "ICT third-party risk" - "RTS 2024/1773" - "subcontracting RTS 2025/532" - "exit strategy" - "audit and access rights" - "DORA Article 28" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA ICT Third-Party Risk Management + Contract Clauses A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. *Contract Guide* *EU* ## EU DORA Third-Party Risk + Contract Clauses Make ICT third-party risk a controlled system: policy, due diligence, clauses, monitoring, and exit plans. Grounded in Article 28-30, RTS 2024/1773 contract RTS, and subcontracting RTS 2025/532. DORA's third-party requirements are designed to stop "outsourcing the risk". Your compliance posture depends on whether you can prove (1) you selected the provider with risk-based due diligence, (2) your contract gives you real audit and access rights, (3) you continuously monitor performance and security, (4) you understand the subcontracting chain for critical or important functions, and (5) you can execute a credible exit without breaking critical services. ## What DORA expects (plain language) DORA requires a strategic, management-body-owned approach to ICT third-party risk, plus operational controls for contracting, monitoring, and exit. Think of this as a "contract + evidence" program: the contract must enable supervision-grade access, and your operations must continuously generate auditable proof. - An ICT third-party risk strategy and policy covering planning, due diligence, approvals, monitoring, and exit (Article 28 + RTS 2024/1773). - Contractual clauses that are written, enforceable, and aligned to risk for ICT services supporting critical or important functions (RTS 2024/1773). - Subcontracting governance and assessment for chains supporting critical or important functions (RTS 2025/532). - A register of information that supervisors can request in full or in part (Article 28). ## Article 28 - Strategy + governance for ICT third-party risk Article 28 anchors the program: governance, strategy, and the requirement to maintain a register of information on contractual arrangements for ICT services. Treat the strategy as an operating model: roles, decisions, thresholds, and evidence, not a PDF that nobody can follow. - Define what "critical or important functions" mean in your service catalog and architecture (used to trigger stricter contract controls). - Set approval gates: when legal/security/outsourcing committee sign-off is mandatory (new provider, material change, critical service). - Define concentration risk indicators (provider, region, technology stack) and the escalation path when risk grows. - Connect the strategy to the register of information: if it's not in the register, assume it will be invisible to supervisors. ## RTS 2024/1773 - Due diligence you can defend RTS 2024/1773 operationalizes how financial entities should plan contractual arrangements and assess provider suitability before contracting. Design due diligence so you can show traceability: requirement -> evidence -> risk decision -> contract clause -> monitoring control. - Business reputation + financial and operational resilience of the provider (risk-based assessment). - Security posture and internal controls (policies, governance, technical safeguards, business continuity). - Human and technical resources to deliver critical services sustainably (including key subcontractors). - Document the "why this provider" decision and the compensating controls when gaps remain. ## Contract clause library (what to include for critical/important functions) For ICT services supporting critical or important functions, your contract must not be a generic SaaS agreement. Build a clause library aligned to DORA and RTS 2024/1773, then map each clause to: risk scenario, metric, evidence, and exit plan dependency. - Audit and access rights: your right (and supervisors'/appointed auditors' right) to inspect, access information, and execute audits in a risk-based manner (RTS 2024/1773). - Monitoring + reporting: periodic service delivery reports, incident reports, security reports, and business continuity testing evidence (RTS 2024/1773). - Security + resilience requirements: confidentiality, integrity, availability, authenticity of data; change management and secure operations. - Location and data-processing transparency: where services run, where data is stored/processed, and how changes are notified. - Incident notification obligations: notification triggers, timelines, and what information is provided to support DORA reporting (align with Articles 17-19). - Exit and termination: realistic exit plan, triggers, and operational feasibility with a planned implementation schedule (RTS 2024/1773). ## Audits in the cloud era (how to comply without "on-site audit theatre") RTS 2024/1773 anticipates real constraints: financial entities can use certifications and third-party audit reports, but must not rely on them blindly over time. Treat assurance as layered: baseline independent audits + scoped deep dives + pooled audits + your own testing in high-risk areas. - Assurance coverage mapping: ensure audit reports/certifications cover the systems and key controls you rely on (RTS 2024/1773). - Recency and scope governance: verify reports aren't obsolete and that future audit scopes include your key controls. - Contractual right to request scope changes and to perform individual and pooled audits within reasonable frequency (RTS 2024/1773). - Evidence: keep the assurance register (what you reviewed, findings, remediation commitments, and closure proof). ## Subcontracting controls - RTS 2025/532 (stop hidden supply-chain risk) Subcontracting can create long supply chains that undermine operational resilience. RTS 2025/532 specifies elements to assess when subcontracting ICT services supporting critical or important functions. Implement subcontracting governance as part of vendor management: visibility, approval, monitoring, and exit readiness. - Identify which subcontractors "effectively underpin" the ICT service supporting the critical/important function and track them in your register of information (ITS/Article 28 context). - Assess subcontracting changes as material changes: risk review, control impact, and exit dependency review. - Ensure flow-down obligations: audit/access, security controls, incident notification, and continuity requirements apply through the chain. - Monitor concentration risk at subcontractor level (region, platform, identity/monitoring stack) and define escalation triggers. ## What the 18 November 2025 critical-provider designations mean for vendor governance The first published list of designated critical ICT third-party providers turned DORA oversight from a future framework into an active supervisory regime. For financial entities, that changes the quality bar for provider inventories, contract mapping, monitoring cadence, and exit planning around major cloud and ICT dependencies. - Track whether a key provider or provider group appears on the designated CTPP list and reflect that in your risk register, board reporting, and contract governance. - Reconcile provider identifiers across contracts, RoI exports, assurance reports, and incident dependencies so oversight questions can be answered quickly. - If a designated provider underpins critical or important functions, test whether your exit and concentration-risk assumptions are still credible. ## Oversight of critical ICT providers (what changes when a provider is "critical") DORA establishes an EU oversight framework for ICT third-party providers designated as critical. This influences what supervisors expect your contracts and evidence to support. Prepare for increased transparency and request-response speed: you may need to provide register extracts and contract evidence quickly. - Current implementation fact: the ESAs published the first list of designated critical ICT third-party providers on 18 November 2025, so this oversight layer is now live rather than hypothetical. - Be ready to provide your register of information (full or sections) and related supervision information on request (Article 28). - Track whether key providers are designated as critical and adjust monitoring cadence and escalation accordingly. - For critical providers, note that the oversight framework includes powers and potential penalty payments for non-cooperation at provider level (DORA oversight provisions). ## Exit strategy playbook (what "credible exit" means) A DORA exit plan is not "we can cancel anytime". It's the ability to transition or replace the service without unacceptable disruption, even under stress. Design exits as engineering + procurement deliverables: data portability, infrastructure portability, and operational runbooks. - Define exit triggers: chronic SLA failures, security posture deterioration, regulatory constraints, concentration risk escalation. - Build a transition architecture: target state, migration plan, parallel run where feasible, rollback plan, and cutover criteria. - Contract for the exit: assistance obligations, data return/deletion, transition support, and access to logs/evidence for post-exit investigations. - Test exits: tabletop exercises for critical providers and "minimum viable migration" drills for key datasets and identities. ## Evidence pack checklist (what to have ready for supervisors) Third-party risk programs fail audits when evidence is fragmented across procurement, security, and engineering systems. Build a single evidence index that points to systems-of-record, not static attachments. - Management-body approved ICT third-party risk strategy and policy (Article 28 + RTS 2024/1773). - Due diligence pack for each critical/important service: evaluation, risk decision, compensating controls, and approvals. - Signed contract with DORA clause mapping (audit/access, monitoring, incident notice, BCP/DR testing, exit). - Subcontracting assessment record (RTS 2025/532) and subcontractor inventory for underpinning services. - Register-of-information export aligned to ITS 2024/2956 with relational keys and data quality checks. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU DORA Third-Party Risk + Contract Clauses in one governed evidence system SSOT can take EU DORA Third-Party Risk + Contract Clauses from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU DORA Third-Party Risk + Contract Clauses](/solutions/ssot.md): Start from EU DORA Third-Party Risk + Contract Clauses and keep documents, evidence, and control records in one governed system. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Third-Party Risk + Contract Clauses. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - ICT third-party risk strategy, register of information, oversight framework, and cooperation provisions (including linkages to NIS2 cooperation structures). - [Commission Delegated Regulation (EU) 2024/1773 - Contractual arrangements for ICT services supporting critical or important functions (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - RTS on due diligence, monitoring, audit/access rights, use of certifications/audit reports, and exit planning in contractual arrangements. - [Commission Delegated Regulation (EU) 2025/532 - Subcontracting elements assessment for critical/important ICT services (RTS)](https://eur-lex.europa.eu/eli/reg_del/2025/532/oj/eng?ref=sorena.io) - RTS specifying elements to determine and assess when subcontracting ICT services supporting critical or important functions. - [Commission Delegated Regulation (EU) 2024/1502 - Designation criteria for critical ICT third-party providers (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1502/oj/eng?ref=sorena.io) - Criteria for when ICT third-party providers may be designated as critical under DORA oversight. - [ESMA news - ESAs designate critical ICT third-party providers under DORA](https://www.esma.europa.eu/press-news/esma-news/european-supervisory-authorities-designate-critical-ict-third-party-providers?ref=sorena.io) - Official announcement of critical ICT provider designations; useful for monitoring and updating critical provider status in third-party risk programs. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/third-party-risk-and-contract-clauses --- --- title: "DORA ICT Third-Party Risk Management + Contract Clauses" canonical_url: "https://www.sorena.io/artifacts/eu/dora/third-party-risk-and-contract-clauses" source_url: "https://www.sorena.io/artifacts/eu/dora/third-party-risk-and-contract-clauses" author: "Sorena AI" description: "A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring." keywords: - "DORA third party risk" - "DORA ICT third party risk management" - "DORA third party contract clauses" - "RTS 2024/1773 contract clauses" - "DORA audit rights cloud contract" - "DORA subcontracting RTS 2025/532" - "DORA exit strategy" - "DORA outsourcing register of information" - "DORA concentration risk cloud" - "ICT third-party risk" - "RTS 2024/1773" - "subcontracting RTS 2025/532" - "exit strategy" - "audit and access rights" - "DORA Article 28" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # DORA ICT Third-Party Risk Management + Contract Clauses A deep guide to DORA ICT third-party risk: build the third-party risk strategy (Article 28), implement due diligence + ongoing monitoring. *Contract Guide* *EU* ## EU DORA Third-Party Risk + Contract Clauses Make ICT third-party risk a controlled system: policy, due diligence, clauses, monitoring, and exit plans. Grounded in Article 28-30, RTS 2024/1773 contract RTS, and subcontracting RTS 2025/532. DORA's third-party requirements are designed to stop "outsourcing the risk". Your compliance posture depends on whether you can prove (1) you selected the provider with risk-based due diligence, (2) your contract gives you real audit and access rights, (3) you continuously monitor performance and security, (4) you understand the subcontracting chain for critical or important functions, and (5) you can execute a credible exit without breaking critical services. ## What DORA expects (plain language) DORA requires a strategic, management-body-owned approach to ICT third-party risk, plus operational controls for contracting, monitoring, and exit. Think of this as a "contract + evidence" program: the contract must enable supervision-grade access, and your operations must continuously generate auditable proof. - An ICT third-party risk strategy and policy covering planning, due diligence, approvals, monitoring, and exit (Article 28 + RTS 2024/1773). - Contractual clauses that are written, enforceable, and aligned to risk for ICT services supporting critical or important functions (RTS 2024/1773). - Subcontracting governance and assessment for chains supporting critical or important functions (RTS 2025/532). - A register of information that supervisors can request in full or in part (Article 28). ## Article 28 - Strategy + governance for ICT third-party risk Article 28 anchors the program: governance, strategy, and the requirement to maintain a register of information on contractual arrangements for ICT services. Treat the strategy as an operating model: roles, decisions, thresholds, and evidence, not a PDF that nobody can follow. - Define what "critical or important functions" mean in your service catalog and architecture (used to trigger stricter contract controls). - Set approval gates: when legal/security/outsourcing committee sign-off is mandatory (new provider, material change, critical service). - Define concentration risk indicators (provider, region, technology stack) and the escalation path when risk grows. - Connect the strategy to the register of information: if it's not in the register, assume it will be invisible to supervisors. ## RTS 2024/1773 - Due diligence you can defend RTS 2024/1773 operationalizes how financial entities should plan contractual arrangements and assess provider suitability before contracting. Design due diligence so you can show traceability: requirement -> evidence -> risk decision -> contract clause -> monitoring control. - Business reputation + financial and operational resilience of the provider (risk-based assessment). - Security posture and internal controls (policies, governance, technical safeguards, business continuity). - Human and technical resources to deliver critical services sustainably (including key subcontractors). - Document the "why this provider" decision and the compensating controls when gaps remain. ## Contract clause library (what to include for critical/important functions) For ICT services supporting critical or important functions, your contract must not be a generic SaaS agreement. Build a clause library aligned to DORA and RTS 2024/1773, then map each clause to: risk scenario, metric, evidence, and exit plan dependency. - Audit and access rights: your right (and supervisors'/appointed auditors' right) to inspect, access information, and execute audits in a risk-based manner (RTS 2024/1773). - Monitoring + reporting: periodic service delivery reports, incident reports, security reports, and business continuity testing evidence (RTS 2024/1773). - Security + resilience requirements: confidentiality, integrity, availability, authenticity of data; change management and secure operations. - Location and data-processing transparency: where services run, where data is stored/processed, and how changes are notified. - Incident notification obligations: notification triggers, timelines, and what information is provided to support DORA reporting (align with Articles 17-19). - Exit and termination: realistic exit plan, triggers, and operational feasibility with a planned implementation schedule (RTS 2024/1773). ## Audits in the cloud era (how to comply without "on-site audit theatre") RTS 2024/1773 anticipates real constraints: financial entities can use certifications and third-party audit reports, but must not rely on them blindly over time. Treat assurance as layered: baseline independent audits + scoped deep dives + pooled audits + your own testing in high-risk areas. - Assurance coverage mapping: ensure audit reports/certifications cover the systems and key controls you rely on (RTS 2024/1773). - Recency and scope governance: verify reports aren't obsolete and that future audit scopes include your key controls. - Contractual right to request scope changes and to perform individual and pooled audits within reasonable frequency (RTS 2024/1773). - Evidence: keep the assurance register (what you reviewed, findings, remediation commitments, and closure proof). ## Subcontracting controls - RTS 2025/532 (stop hidden supply-chain risk) Subcontracting can create long supply chains that undermine operational resilience. RTS 2025/532 specifies elements to assess when subcontracting ICT services supporting critical or important functions. Implement subcontracting governance as part of vendor management: visibility, approval, monitoring, and exit readiness. - Identify which subcontractors "effectively underpin" the ICT service supporting the critical/important function and track them in your register of information (ITS/Article 28 context). - Assess subcontracting changes as material changes: risk review, control impact, and exit dependency review. - Ensure flow-down obligations: audit/access, security controls, incident notification, and continuity requirements apply through the chain. - Monitor concentration risk at subcontractor level (region, platform, identity/monitoring stack) and define escalation triggers. ## What the 18 November 2025 critical-provider designations mean for vendor governance The first published list of designated critical ICT third-party providers turned DORA oversight from a future framework into an active supervisory regime. For financial entities, that changes the quality bar for provider inventories, contract mapping, monitoring cadence, and exit planning around major cloud and ICT dependencies. - Track whether a key provider or provider group appears on the designated CTPP list and reflect that in your risk register, board reporting, and contract governance. - Reconcile provider identifiers across contracts, RoI exports, assurance reports, and incident dependencies so oversight questions can be answered quickly. - If a designated provider underpins critical or important functions, test whether your exit and concentration-risk assumptions are still credible. ## Oversight of critical ICT providers (what changes when a provider is "critical") DORA establishes an EU oversight framework for ICT third-party providers designated as critical. This influences what supervisors expect your contracts and evidence to support. Prepare for increased transparency and request-response speed: you may need to provide register extracts and contract evidence quickly. - Current implementation fact: the ESAs published the first list of designated critical ICT third-party providers on 18 November 2025, so this oversight layer is now live rather than hypothetical. - Be ready to provide your register of information (full or sections) and related supervision information on request (Article 28). - Track whether key providers are designated as critical and adjust monitoring cadence and escalation accordingly. - For critical providers, note that the oversight framework includes powers and potential penalty payments for non-cooperation at provider level (DORA oversight provisions). ## Exit strategy playbook (what "credible exit" means) A DORA exit plan is not "we can cancel anytime". It's the ability to transition or replace the service without unacceptable disruption, even under stress. Design exits as engineering + procurement deliverables: data portability, infrastructure portability, and operational runbooks. - Define exit triggers: chronic SLA failures, security posture deterioration, regulatory constraints, concentration risk escalation. - Build a transition architecture: target state, migration plan, parallel run where feasible, rollback plan, and cutover criteria. - Contract for the exit: assistance obligations, data return/deletion, transition support, and access to logs/evidence for post-exit investigations. - Test exits: tabletop exercises for critical providers and "minimum viable migration" drills for key datasets and identities. ## Evidence pack checklist (what to have ready for supervisors) Third-party risk programs fail audits when evidence is fragmented across procurement, security, and engineering systems. Build a single evidence index that points to systems-of-record, not static attachments. - Management-body approved ICT third-party risk strategy and policy (Article 28 + RTS 2024/1773). - Due diligence pack for each critical/important service: evaluation, risk decision, compensating controls, and approvals. - Signed contract with DORA clause mapping (audit/access, monitoring, incident notice, BCP/DR testing, exit). - Subcontracting assessment record (RTS 2025/532) and subcontractor inventory for underpinning services. - Register-of-information export aligned to ITS 2024/2956 with relational keys and data quality checks. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU DORA Third-Party Risk + Contract Clauses in one governed evidence system SSOT can take EU DORA Third-Party Risk + Contract Clauses from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU DORA Third-Party Risk + Contract Clauses](/solutions/ssot.md): Start from EU DORA Third-Party Risk + Contract Clauses and keep documents, evidence, and control records in one governed system. - [Talk through EU DORA](/contact.md): Review your current process, evidence gaps, and next steps for EU DORA Third-Party Risk + Contract Clauses. ## Primary sources - [Regulation (EU) 2022/2554 (DORA) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - ICT third-party risk strategy, register of information, oversight framework, and cooperation provisions (including linkages to NIS2 cooperation structures). - [Commission Delegated Regulation (EU) 2024/1773 - Contractual arrangements for ICT services supporting critical or important functions (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng?ref=sorena.io) - RTS on due diligence, monitoring, audit/access rights, use of certifications/audit reports, and exit planning in contractual arrangements. - [Commission Delegated Regulation (EU) 2025/532 - Subcontracting elements assessment for critical/important ICT services (RTS)](https://eur-lex.europa.eu/eli/reg_del/2025/532/oj/eng?ref=sorena.io) - RTS specifying elements to determine and assess when subcontracting ICT services supporting critical or important functions. - [Commission Delegated Regulation (EU) 2024/1502 - Designation criteria for critical ICT third-party providers (RTS)](https://eur-lex.europa.eu/eli/reg_del/2024/1502/oj/eng?ref=sorena.io) - Criteria for when ICT third-party providers may be designated as critical under DORA oversight. - [ESMA news - ESAs designate critical ICT third-party providers under DORA](https://www.esma.europa.eu/press-news/esma-news/european-supervisory-authorities-designate-critical-ict-third-party-providers?ref=sorena.io) - Official announcement of critical ICT provider designations; useful for monitoring and updating critical provider status in third-party risk programs. ## Related Topic Guides - [DORA Applicability Test | Is EU DORA Applicable to Your Entity?](/artifacts/eu/dora/applicability-test.md): A step-by-step EU DORA applicability test (Regulation (EU) 2022/2554): determine if you are a covered financial entity under Article 2. - [DORA FAQ (EU) - Scope, Deadlines, Reporting, TLPT, RoI, and Third-Party Risk](/artifacts/eu/dora/faq.md): High-signal answers to the most searched DORA questions: who is in scope, when DORA applies (17 Jan 2025), what "critical or important functions" means. - [DORA ICT Risk Management Control Baseline | Chapter II + RTS 2024/1774](/artifacts/eu/dora/ict-risk-management-control-baseline.md): A deep DORA ICT risk management baseline: how to implement Chapter II of Regulation (EU) 2022/2554 as controls with acceptance criteria and evidence. - [DORA Major ICT Incident Reporting | Articles 17-20 + RTS 2024/1772 + 2025/301](/artifacts/eu/dora/major-incident-reporting.md): A practical DORA major incident reporting guide: build the Article 17 and 19 workflow, apply RTS 2024/1772 classification and RTS 2025/301 timing rules. - [DORA Penalties, Fines, and Enforcement | Articles 50-55 + Oversight Penalty Payments](/artifacts/eu/dora/penalties-and-fines.md): A practical DORA enforcement guide: how competent authorities' supervisory/investigatory/sanctioning powers work (Article 50). - [DORA Register of Information (RoI) - How to Build It | Article 28 + ITS 2024/2956](/artifacts/eu/dora/register-of-information-how-to-build.md): Build an audit-ready DORA Register of Information (RoI): define scope and relational keys. - [DORA Register of Information (RoI) Template Guide | ITS 2024/2956 Annex Templates (B_01-B_07)](/artifacts/eu/dora/dora-register-of-information-template.md): A practical guide to the DORA Register of Information templates: understand the ITS schema (Implementing Regulation (EU) 2024/2956). - [DORA Testing & TLPT Readiness | Chapter IV + TIBER-EU Execution Guide](/artifacts/eu/dora/testing-and-tlpt-readiness.md): A deep DORA testing and TLPT readiness guide: build the Chapter IV testing program, prepare remediation and validation. - [DORA vs ISO/IEC 27001:2022 | Mapping Controls, Evidence, and Audit Readiness](/artifacts/eu/dora/dora-vs-iso-27001.md): A deep DORA vs ISO 27001 comparison: where ISO/IEC 27001:2022 helps satisfy DORA ICT risk management and evidence expectations. - [DORA vs NIS2 (EU) | Scope, Reporting, Controls, and Overlap for Financial Entities](/artifacts/eu/dora/dora-vs-nis2.md): A deep comparison of DORA and NIS2: who is in scope, what "security measures" mean, incident reporting differences, governance and enforcement posture. - [EU DORA Checklist | DORA Compliance Checklist (Audit-Ready)](/artifacts/eu/dora/checklist.md): An audit-ready EU DORA checklist (Regulation (EU) 2022/2554): scope memo and proportionality, ICT risk management control baseline. - [EU DORA Compliance Guide | DORA Implementation Playbook](/artifacts/eu/dora/compliance.md): A practical EU DORA compliance guide (Regulation (EU) 2022/2554): how to set up a DORA program, build an ICT risk management control baseline. - [EU DORA Deadlines & Compliance Calendar | Key Dates, RTS/ITS and Cadence](/artifacts/eu/dora/deadlines-and-compliance-calendar.md): A DORA compliance calendar for Regulation (EU) 2022/2554: publication, entry into force, application date, key RTS and ITS including 2024/2956, 2025/301. - [EU DORA Requirements | Obligations by Workstream (ICT Risk, Incidents, TLPT, Third Parties)](/artifacts/eu/dora/requirements.md): A practical breakdown of EU DORA (Regulation (EU) 2022/2554) requirements: ICT risk management framework (Chapter II). - [EU DORA Scope & Covered Entities | Who Is In Scope (Article 2)](/artifacts/eu/dora/scope-and-covered-entities.md): A practical scoping guide for EU DORA (Regulation (EU) 2022/2554): covered financial entities (Article 2), proportionality and simplified frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/dora/third-party-risk-and-contract-clauses --- --- title: "eIDAS Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/eidas/applicability-test" author: "Sorena AI" description: "A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer)." keywords: - "eIDAS applicability test" - "is eIDAS applicable" - "eIDAS scope" - "am I a QTSP" - "relying party eIDAS" - "EUDI wallet relying party" - "eIDAS 2.0 applicability" - "eIDAS applicability" - "eIDAS scope test" - "QTSP" - "relying party" - "EUDI wallet" - "attribute issuer" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS Applicability Test A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). *Applicability Test* *EU* ## EU eIDAS Applicability Test Identify your role(s), then build the right controls and evidence. Most organizations have multiple roles; this test helps you prioritize the correct workstreams. eIDAS obligations are role-dependent. Instead of asking "Does eIDAS apply?", ask "Which eIDAS role am I in this transaction?" Use this test to identify your role(s) and the implementation subpages to use next. ## Step 1 - Are you a relying party? You are a relying party if you accept or rely on electronic identification, wallet interactions, or trust services to make a decision (onboarding, authentication, contract signing, high-risk action). Relying parties need deterministic verification logic, logging, and user transparency controls. - Do you authenticate users online and need high assurance identity proofing? - Do you accept electronic signatures or seals and need to validate legal effect and certificate status? - Will you accept EUDI Wallet-based authentication or attribute presentation in user journeys? ## Step 2 - Are you a trust service provider (TSP) or qualified TSP (QTSP)? You are a TSP/QTSP if you provide trust services (signatures, seals, timestamps, registered delivery, website authentication) as a service. QTSP status introduces supervision and qualification expectations and typically requires strong alignment to standards and audits. - Do you issue certificates for signatures/seals, provide validation/preservation, or operate time stamping services? - Do you market or claim "qualified" services (QES/QSeal/QTimestamp/Qualified ERDS)? - Do you maintain a trust service operational platform (key management, HSMs, audit logs, incident response)? ## Step 3 - Are you building or operating EUDI Wallet capabilities? Wallet-related responsibilities may apply if you build wallet components, operate wallet services, or issue identity data/attributes to wallets. Even if you are not a wallet provider, you may be a relying party that must integrate wallet verification flows. - Do you provide a wallet app or wallet services (updates, security lifecycle, revocation/suspension handling)? - Do you issue identity data or electronic attestations of attributes to wallets? - Do you need interoperability and conformance testing across multiple wallet vendors and issuers? ## Step 4 - Choose your path (recommended next pages) Use your role to pick the right implementation workstreams. Don't build everything at once. Start with the highest risk/highest volume journey (e.g., onboarding, signing, or wallet-based authentication). - Relying party: start with electronic signatures legal effect + validation evidence, then wallet readiness. - QTSP/TSP: start with qualified trust services selection and a security + supervision evidence pack. - Wallet readiness: start with the technical architecture guide and interoperability test plan. - Program owners: start with checklist-and-evidence, then compliance playbook. *Recommended next step* *Placement: after the applicability result* ## Turn EU eIDAS Applicability Test into an operational assessment Assessment Autopilot can take EU eIDAS Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU eIDAS Applicability Test](/solutions/assessment.md): Start from EU eIDAS Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Applicability Test. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Definitions (including relying party) and trust services framework. - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Wallet-centric amendments and ecosystem role changes. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/applicability-test --- --- title: "eIDAS Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/eidas/applicability-test" author: "Sorena AI" description: "A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer)." keywords: - "eIDAS applicability test" - "is eIDAS applicable" - "eIDAS scope" - "am I a QTSP" - "relying party eIDAS" - "EUDI wallet relying party" - "eIDAS 2.0 applicability" - "eIDAS applicability" - "eIDAS scope test" - "QTSP" - "relying party" - "EUDI wallet" - "attribute issuer" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS Applicability Test A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). *Applicability Test* *EU* ## EU eIDAS Applicability Test Identify your role(s), then build the right controls and evidence. Most organizations have multiple roles; this test helps you prioritize the correct workstreams. eIDAS obligations are role-dependent. Instead of asking "Does eIDAS apply?", ask "Which eIDAS role am I in this transaction?" Use this test to identify your role(s) and the implementation subpages to use next. ## Step 1 - Are you a relying party? You are a relying party if you accept or rely on electronic identification, wallet interactions, or trust services to make a decision (onboarding, authentication, contract signing, high-risk action). Relying parties need deterministic verification logic, logging, and user transparency controls. - Do you authenticate users online and need high assurance identity proofing? - Do you accept electronic signatures or seals and need to validate legal effect and certificate status? - Will you accept EUDI Wallet-based authentication or attribute presentation in user journeys? ## Step 2 - Are you a trust service provider (TSP) or qualified TSP (QTSP)? You are a TSP/QTSP if you provide trust services (signatures, seals, timestamps, registered delivery, website authentication) as a service. QTSP status introduces supervision and qualification expectations and typically requires strong alignment to standards and audits. - Do you issue certificates for signatures/seals, provide validation/preservation, or operate time stamping services? - Do you market or claim "qualified" services (QES/QSeal/QTimestamp/Qualified ERDS)? - Do you maintain a trust service operational platform (key management, HSMs, audit logs, incident response)? ## Step 3 - Are you building or operating EUDI Wallet capabilities? Wallet-related responsibilities may apply if you build wallet components, operate wallet services, or issue identity data/attributes to wallets. Even if you are not a wallet provider, you may be a relying party that must integrate wallet verification flows. - Do you provide a wallet app or wallet services (updates, security lifecycle, revocation/suspension handling)? - Do you issue identity data or electronic attestations of attributes to wallets? - Do you need interoperability and conformance testing across multiple wallet vendors and issuers? ## Step 4 - Choose your path (recommended next pages) Use your role to pick the right implementation workstreams. Don't build everything at once. Start with the highest risk/highest volume journey (e.g., onboarding, signing, or wallet-based authentication). - Relying party: start with electronic signatures legal effect + validation evidence, then wallet readiness. - QTSP/TSP: start with qualified trust services selection and a security + supervision evidence pack. - Wallet readiness: start with the technical architecture guide and interoperability test plan. - Program owners: start with checklist-and-evidence, then compliance playbook. *Recommended next step* *Placement: after the applicability result* ## Turn EU eIDAS Applicability Test into an operational assessment Assessment Autopilot can take EU eIDAS Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU eIDAS Applicability Test](/solutions/assessment.md): Start from EU eIDAS Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Applicability Test. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Definitions (including relying party) and trust services framework. - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Wallet-centric amendments and ecosystem role changes. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/applicability-test --- --- title: "eIDAS Certificates and Authentication" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/certificates-and-authentication" source_url: "https://www.sorena.io/artifacts/eu/eidas/certificates-and-authentication" author: "Sorena AI" description: "A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates." keywords: - "eIDAS certificates" - "qualified certificate for electronic signature" - "qualified certificate for electronic seal" - "eIDAS certificate validation" - "QWAC eIDAS" - "revocation OCSP CRL eIDAS" - "trusted list eIDAS" - "relying party certificate verification" - "qualified certificates" - "QWAC" - "certificate validation" - "revocation" - "trusted lists" - "relying party" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS Certificates and Authentication A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. *Technical Guide* *EU* ## EU eIDAS Certificates + Authentication Build deterministic validation and authentication decisions with reproducible evidence. Designed for relying parties and teams integrating QTSP certificate-based trust services. Certificate handling is where eIDAS systems break in production: incorrect chain building, brittle revocation checks, ambiguous validation outcomes, and missing evidence when disputes happen. The solution is to treat certificate validation as a product capability: a verification pipeline with explicit policy, strong logging, and repeatable validation reports. ## What you must decide first (to avoid expensive rework) Certificate and authentication architecture depends on your assurance needs and your role: relying party vs TSP/QTSP vs wallet flows. Make these decisions explicitly and document them as architecture decisions with acceptance criteria. - Assurance level: advanced vs qualified signatures/seals; which journeys require which level. - Validation scope: what formats you validate, what certificate types you accept, and which trust anchors you use. - Evidence outputs: what reports and logs you keep to support audits and disputes. ## Validation pipeline blueprint (recommended architecture) Treat validation as a deterministic pipeline: input -> policy -> checks -> decision -> report -> evidence index. Your pipeline should produce both machine-readable and human-readable outputs. - Chain validation: deterministic chain building and policy evaluation. - Status checks: revocation/validity checks with safe failure modes and explicit reason codes. - Trusted lists integration: ensure your trust anchor source is current and versioned. - Reporting: validation reports with timestamps, policy version, and decision reasoning. ## Revocation and status handling (the most common production failure) Revocation and status checks create real-world failures: network dependency, caching bugs, and inconsistent time semantics. Build measurable controls: health checks, caching strategy, and incident playbooks for status service outages. - Caching strategy: timeboxed caching with clear refresh rules; record when status was checked. - Outage behavior: define acceptable fallback behavior and how you communicate to users. - Monitoring: status endpoint health, error rates, and validation failure trends. - Evidence: preserve status check metadata for dispute resolution. ## Implementation approach (use proven tooling, not bespoke crypto) Use standards-aligned tooling and libraries whenever possible. Most eIDAS implementation risk comes from bespoke validation logic and inconsistent policies. Open tooling like the Commission's Digital Signature Service (DSS) can accelerate validation and reporting workflows. - Select a validation engine that supports the signature formats you need and can produce rich reports. - Version your validation policy and record versions in decision logs. - Build contract tests: known-good and known-bad samples that must remain stable across releases. ## Evidence checklist (what to have ready) Prepare evidence that proves your certificate handling is correct and operationally resilient. This reduces audit time and dispute risk. - Validation policy document + mapping to product journeys. - Decision logs with reason codes and policy versions. - Interoperability and negative test results (revoked, expired, malformed). - Monitoring dashboards and incident playbooks for validation dependencies. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU eIDAS Certificates + Authentication as a cited research workflow Research Copilot can take EU eIDAS Certificates + Authentication from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU eIDAS Certificates + Authentication](/solutions/research-copilot.md): Start from EU eIDAS Certificates + Authentication and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Certificates + Authentication. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Primary legal framework for trust services and certificate-related concepts. - [European Commission - Digital Signature Service (DSS) (Digital Building Blocks)](https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467109107/Digital+Signature+Service+-+DSS?ref=sorena.io) - Implementation guidance and tooling context for signature creation and validation workflows. - [ETSI - Standards search (eIDAS-related trust service standards)](https://www.etsi.org/standards-search?ref=sorena.io) - Authoritative index for ETSI trust service standards used in eIDAS implementations. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/certificates-and-authentication --- --- title: "eIDAS Certificates and Authentication" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/certificates-and-authentication" source_url: "https://www.sorena.io/artifacts/eu/eidas/certificates-and-authentication" author: "Sorena AI" description: "A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates." keywords: - "eIDAS certificates" - "qualified certificate for electronic signature" - "qualified certificate for electronic seal" - "eIDAS certificate validation" - "QWAC eIDAS" - "revocation OCSP CRL eIDAS" - "trusted list eIDAS" - "relying party certificate verification" - "qualified certificates" - "QWAC" - "certificate validation" - "revocation" - "trusted lists" - "relying party" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS Certificates and Authentication A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. *Technical Guide* *EU* ## EU eIDAS Certificates + Authentication Build deterministic validation and authentication decisions with reproducible evidence. Designed for relying parties and teams integrating QTSP certificate-based trust services. Certificate handling is where eIDAS systems break in production: incorrect chain building, brittle revocation checks, ambiguous validation outcomes, and missing evidence when disputes happen. The solution is to treat certificate validation as a product capability: a verification pipeline with explicit policy, strong logging, and repeatable validation reports. ## What you must decide first (to avoid expensive rework) Certificate and authentication architecture depends on your assurance needs and your role: relying party vs TSP/QTSP vs wallet flows. Make these decisions explicitly and document them as architecture decisions with acceptance criteria. - Assurance level: advanced vs qualified signatures/seals; which journeys require which level. - Validation scope: what formats you validate, what certificate types you accept, and which trust anchors you use. - Evidence outputs: what reports and logs you keep to support audits and disputes. ## Validation pipeline blueprint (recommended architecture) Treat validation as a deterministic pipeline: input -> policy -> checks -> decision -> report -> evidence index. Your pipeline should produce both machine-readable and human-readable outputs. - Chain validation: deterministic chain building and policy evaluation. - Status checks: revocation/validity checks with safe failure modes and explicit reason codes. - Trusted lists integration: ensure your trust anchor source is current and versioned. - Reporting: validation reports with timestamps, policy version, and decision reasoning. ## Revocation and status handling (the most common production failure) Revocation and status checks create real-world failures: network dependency, caching bugs, and inconsistent time semantics. Build measurable controls: health checks, caching strategy, and incident playbooks for status service outages. - Caching strategy: timeboxed caching with clear refresh rules; record when status was checked. - Outage behavior: define acceptable fallback behavior and how you communicate to users. - Monitoring: status endpoint health, error rates, and validation failure trends. - Evidence: preserve status check metadata for dispute resolution. ## Implementation approach (use proven tooling, not bespoke crypto) Use standards-aligned tooling and libraries whenever possible. Most eIDAS implementation risk comes from bespoke validation logic and inconsistent policies. Open tooling like the Commission's Digital Signature Service (DSS) can accelerate validation and reporting workflows. - Select a validation engine that supports the signature formats you need and can produce rich reports. - Version your validation policy and record versions in decision logs. - Build contract tests: known-good and known-bad samples that must remain stable across releases. ## Evidence checklist (what to have ready) Prepare evidence that proves your certificate handling is correct and operationally resilient. This reduces audit time and dispute risk. - Validation policy document + mapping to product journeys. - Decision logs with reason codes and policy versions. - Interoperability and negative test results (revoked, expired, malformed). - Monitoring dashboards and incident playbooks for validation dependencies. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU eIDAS Certificates + Authentication as a cited research workflow Research Copilot can take EU eIDAS Certificates + Authentication from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU eIDAS Certificates + Authentication](/solutions/research-copilot.md): Start from EU eIDAS Certificates + Authentication and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Certificates + Authentication. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Primary legal framework for trust services and certificate-related concepts. - [European Commission - Digital Signature Service (DSS) (Digital Building Blocks)](https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467109107/Digital+Signature+Service+-+DSS?ref=sorena.io) - Implementation guidance and tooling context for signature creation and validation workflows. - [ETSI - Standards search (eIDAS-related trust service standards)](https://www.etsi.org/standards-search?ref=sorena.io) - Authoritative index for ETSI trust service standards used in eIDAS implementations. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/certificates-and-authentication --- --- title: "eIDAS Checklist and Evidence Pack" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/checklist-and-evidence" source_url: "https://www.sorena.io/artifacts/eu/eidas/checklist-and-evidence" author: "Sorena AI" description: "A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index." keywords: - "eIDAS evidence pack" - "eIDAS audit evidence" - "QTSP audit checklist" - "trust services evidence" - "electronic signature validation report" - "trusted list evidence" - "EUDI wallet evidence" - "eIDAS compliance artifacts" - "eIDAS evidence" - "audit checklist" - "QTSP evidence" - "signature validation reports" - "trusted lists" - "wallet readiness evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS Checklist and Evidence Pack A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. *Evidence Pack* *EU* ## EU eIDAS Checklist + Evidence Turn eIDAS requirements into proof: artifacts, logs, tests, and vendor evidence. Designed for relying parties, security/compliance teams, and QTSP selection programs. eIDAS compliance succeeds when evidence is reproducible. If your "evidence" is a folder of PDFs that no longer matches production, audits become chaos. The goal is an evidence index: requirements -> system-of-record artifacts -> tests -> operating metrics. This page shows what to keep and how to structure it so you can answer audits, supervision requests, and partner due diligence quickly. ## Evidence-first mindset (what "done" means) For eIDAS, "done" means you can prove what happened, why it was accepted, and what controls prevent abuse. Evidence should be generated by normal operations: validation pipelines, logging, monitoring, and controlled change management. - Single evidence index: a structured inventory linking obligations to living artifacts (not attachments). - Reproducibility: an auditor should be able to replay a signature validation decision using your logs and policies. - Freshness: evidence is current and versioned (what policy/version applied at the time of a decision). *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU eIDAS Checklist + Evidence in one governed evidence system SSOT can take EU eIDAS Checklist + Evidence from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU eIDAS Checklist + Evidence](/solutions/ssot.md): Start from EU eIDAS Checklist + Evidence and keep documents, evidence, and control records in one governed system. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Checklist + Evidence. ## Relying party evidence pack (signatures, seals, and attributes) Relying parties must prove they validate correctly and handle failures safely. This is usually more important than "having a vendor contract". Treat validation as code + policy + logs. - Validation policy: what you accept (AdES/QES), format support, and verification rules (revocation/status and chain validation). - Decision logs: per transaction, store pass/fail, reason codes, timestamps, and version identifiers - without storing unnecessary personal data. - Validation reports: machine-readable reports (for internal review) and human-readable summaries (for disputes and audits). - Operational monitoring: failure rates, revocation check outages, unusual patterns, and incident tickets. ## QTSP selection + oversight evidence pack (if you outsource qualified services) Outsourcing to a QTSP doesn't outsource your risk: you still need proof that the provider is qualified, secure, and operationally reliable. Build a due diligence binder that's updated annually and after incidents. - Qualification proof: trust list presence, service scope, and evidence of qualified status for the specific services you rely on. - Audit and conformity evidence: latest audit reports and conformity assessments relevant to the services and environments you use. - Security framework alignment: security controls and incident handling aligned to recognized guidance (e.g., ENISA TSP security). - Contract evidence: SLAs, incident notification duties, support commitments, data handling, audit rights (where applicable), and exit/continuity plan. ## Wallet readiness evidence (eIDAS 2.0) Wallet readiness evidence is largely about privacy and transparency: what you request, why, how you validate it, and what you store. Build verifiable proof: test results and logs tied to explicit policies and schema governance. - Verifier pipeline logs: authenticity/validity checks, status handling, decision outcomes, and monitoring dashboards. - Attribute schema governance: what you request and accept, retention limits, and disclosure policy controls. - Interoperability test evidence: multi-wallet/multi-issuer tests, negative tests, and release gates. - Privacy evidence: data minimization rules, separation of telemetry, deletion/retention tests, and incident handling procedures. ## How to organize the evidence index (recommended structure) Structure evidence the way audits happen: start from the question, not from the file system. Build it as a table (or database) with stable identifiers and links to systems-of-record. - Requirement ID -> Control ID -> Owner -> System-of-record -> Evidence link -> Last test date -> Result -> Next review date. - Separate "design evidence" (architecture, policies) from "operational evidence" (logs, tests, incidents). - Make evidence exportable: auditors should receive a timeboxed, scoped export without manual scraping. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Trust services framework, supervision concepts, and role definitions that drive evidence requirements. - [ENISA - Security framework for trust service providers](https://www.enisa.europa.eu/publications/tsp-security?ref=sorena.io) - Technical security guidance that informs practical control and evidence design for trust service providers. - [ENISA - Guidelines on supervision of qualified trust service providers](https://www.enisa.europa.eu/publications/tsp-supervision?ref=sorena.io) - Guidance on supervision practices and expectations for qualified trust service providers. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/checklist-and-evidence --- --- title: "eIDAS Checklist and Evidence Pack" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/checklist-and-evidence" source_url: "https://www.sorena.io/artifacts/eu/eidas/checklist-and-evidence" author: "Sorena AI" description: "A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index." keywords: - "eIDAS evidence pack" - "eIDAS audit evidence" - "QTSP audit checklist" - "trust services evidence" - "electronic signature validation report" - "trusted list evidence" - "EUDI wallet evidence" - "eIDAS compliance artifacts" - "eIDAS evidence" - "audit checklist" - "QTSP evidence" - "signature validation reports" - "trusted lists" - "wallet readiness evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS Checklist and Evidence Pack A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. *Evidence Pack* *EU* ## EU eIDAS Checklist + Evidence Turn eIDAS requirements into proof: artifacts, logs, tests, and vendor evidence. Designed for relying parties, security/compliance teams, and QTSP selection programs. eIDAS compliance succeeds when evidence is reproducible. If your "evidence" is a folder of PDFs that no longer matches production, audits become chaos. The goal is an evidence index: requirements -> system-of-record artifacts -> tests -> operating metrics. This page shows what to keep and how to structure it so you can answer audits, supervision requests, and partner due diligence quickly. ## Evidence-first mindset (what "done" means) For eIDAS, "done" means you can prove what happened, why it was accepted, and what controls prevent abuse. Evidence should be generated by normal operations: validation pipelines, logging, monitoring, and controlled change management. - Single evidence index: a structured inventory linking obligations to living artifacts (not attachments). - Reproducibility: an auditor should be able to replay a signature validation decision using your logs and policies. - Freshness: evidence is current and versioned (what policy/version applied at the time of a decision). *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU eIDAS Checklist + Evidence in one governed evidence system SSOT can take EU eIDAS Checklist + Evidence from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU eIDAS Checklist + Evidence](/solutions/ssot.md): Start from EU eIDAS Checklist + Evidence and keep documents, evidence, and control records in one governed system. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Checklist + Evidence. ## Relying party evidence pack (signatures, seals, and attributes) Relying parties must prove they validate correctly and handle failures safely. This is usually more important than "having a vendor contract". Treat validation as code + policy + logs. - Validation policy: what you accept (AdES/QES), format support, and verification rules (revocation/status and chain validation). - Decision logs: per transaction, store pass/fail, reason codes, timestamps, and version identifiers - without storing unnecessary personal data. - Validation reports: machine-readable reports (for internal review) and human-readable summaries (for disputes and audits). - Operational monitoring: failure rates, revocation check outages, unusual patterns, and incident tickets. ## QTSP selection + oversight evidence pack (if you outsource qualified services) Outsourcing to a QTSP doesn't outsource your risk: you still need proof that the provider is qualified, secure, and operationally reliable. Build a due diligence binder that's updated annually and after incidents. - Qualification proof: trust list presence, service scope, and evidence of qualified status for the specific services you rely on. - Audit and conformity evidence: latest audit reports and conformity assessments relevant to the services and environments you use. - Security framework alignment: security controls and incident handling aligned to recognized guidance (e.g., ENISA TSP security). - Contract evidence: SLAs, incident notification duties, support commitments, data handling, audit rights (where applicable), and exit/continuity plan. ## Wallet readiness evidence (eIDAS 2.0) Wallet readiness evidence is largely about privacy and transparency: what you request, why, how you validate it, and what you store. Build verifiable proof: test results and logs tied to explicit policies and schema governance. - Verifier pipeline logs: authenticity/validity checks, status handling, decision outcomes, and monitoring dashboards. - Attribute schema governance: what you request and accept, retention limits, and disclosure policy controls. - Interoperability test evidence: multi-wallet/multi-issuer tests, negative tests, and release gates. - Privacy evidence: data minimization rules, separation of telemetry, deletion/retention tests, and incident handling procedures. ## How to organize the evidence index (recommended structure) Structure evidence the way audits happen: start from the question, not from the file system. Build it as a table (or database) with stable identifiers and links to systems-of-record. - Requirement ID -> Control ID -> Owner -> System-of-record -> Evidence link -> Last test date -> Result -> Next review date. - Separate "design evidence" (architecture, policies) from "operational evidence" (logs, tests, incidents). - Make evidence exportable: auditors should receive a timeboxed, scoped export without manual scraping. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Trust services framework, supervision concepts, and role definitions that drive evidence requirements. - [ENISA - Security framework for trust service providers](https://www.enisa.europa.eu/publications/tsp-security?ref=sorena.io) - Technical security guidance that informs practical control and evidence design for trust service providers. - [ENISA - Guidelines on supervision of qualified trust service providers](https://www.enisa.europa.eu/publications/tsp-supervision?ref=sorena.io) - Guidance on supervision practices and expectations for qualified trust service providers. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/checklist-and-evidence --- --- title: "eIDAS Compliance Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/checklist" source_url: "https://www.sorena.io/artifacts/eu/eidas/checklist" author: "Sorena AI" description: "An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels." keywords: - "eIDAS checklist" - "eIDAS compliance checklist" - "qualified electronic signature checklist" - "QTSP selection checklist" - "eIDAS evidence checklist" - "EUDI wallet readiness checklist" - "eIDAS audit checklist" - "QTSP due diligence" - "electronic signatures checklist" - "trust services evidence" - "ETSI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS Compliance Checklist An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. *Checklist* *EU* ## EU eIDAS Checklist A practical eIDAS checklist optimized for real implementation and audit readiness. Use it to drive workstreams across product, security, and compliance. This checklist is designed to produce evidence, not just activity. Treat every checkbox as "done = verifiable". If you can't prove it with a test result, a log, or a signed artifact, it's not done. ## Scope and role mapping (week 0) Everything starts with role mapping. Your controls and evidence depend on whether you are a relying party, trust service provider/QTSP, wallet provider, or attribute issuer. Most organizations are multiple roles across different products. - Run the applicability test and document your roles per product/journey. - Inventory trust services you provide or rely on (signatures, seals, timestamps, delivery, website authentication). - Decide assurance level needs (advanced vs qualified) for each journey. ## Trust services implementation (build and prove) If you sign or validate, you need deterministic validation, revocation checks, and evidence retention that supports disputes and audits. Prefer standards-aligned formats and validation tooling to avoid interoperability failures. - Implement signature/seal validation with clear pass/fail reasoning and machine-readable reports. - Implement certificate status and revocation handling (including safe failure modes). - Define evidence retention and dispute-handling workflows (what logs you keep, for how long, and why). ## QTSP selection and vendor due diligence Most organizations outsource qualified trust services. That doesn't outsource your compliance risk. Treat QTSP selection as a security + audit decision with measurable acceptance criteria. - Create a QTSP requirements pack: service scope, SLAs, audit rights, incident notice, data handling, and evidence outputs. - Verify ETSI policy alignment (e.g., EN 319 401) and obtain audit reports / conformity assessment evidence. - Define fallback and exit strategy (provider change, certificate replacement, emergency signing continuity). ## EUDI Wallet readiness (eIDAS 2.0) If you authenticate users or rely on attributes, plan EUDI wallet flows as product capabilities with privacy and security controls. Interoperability and conformance testing are critical path items. - Define relying party acceptance strategy and user journeys to support wallet first. - Build verifier pipeline: authenticity/validity checks, status handling, decision logging, and monitoring. - Implement attribute schema governance and data minimization controls. - Run interoperability and negative test suites; gate releases on conformance. ## Evidence pack (what auditors and partners ask for first) Build an evidence index linking requirements to systems-of-record artifacts. Avoid static "evidence PDFs". Evidence should be reproducible and current. - Policies: trust service policy, security policy, incident response, change management, retention/deletion. - Tests: interoperability, revocation/status checks, negative testing, BC/DR drills. - Audits: QTSP audit reports, conformity assessments, and supervision-facing evidence where applicable. - Operational logs: validation decision logs, wallet interaction logs, incident records, remediation tracking. *Recommended next step* *Placement: after the checklist block* ## Turn EU eIDAS Checklist into an operational assessment Assessment Autopilot can take EU eIDAS Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU eIDAS Checklist](/solutions/assessment.md): Start from EU eIDAS Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Checklist. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Primary eIDAS legal framework for trust services and electronic identification. - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Wallet-centric amendments and ecosystem changes. - [ENISA - Security framework for trust service providers](https://www.enisa.europa.eu/publications/tsp-security?ref=sorena.io) - Technical security guidance supporting practical control design for trust services. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/checklist --- --- title: "eIDAS Compliance Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/checklist" source_url: "https://www.sorena.io/artifacts/eu/eidas/checklist" author: "Sorena AI" description: "An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels." keywords: - "eIDAS checklist" - "eIDAS compliance checklist" - "qualified electronic signature checklist" - "QTSP selection checklist" - "eIDAS evidence checklist" - "EUDI wallet readiness checklist" - "eIDAS audit checklist" - "QTSP due diligence" - "electronic signatures checklist" - "trust services evidence" - "ETSI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS Compliance Checklist An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. *Checklist* *EU* ## EU eIDAS Checklist A practical eIDAS checklist optimized for real implementation and audit readiness. Use it to drive workstreams across product, security, and compliance. This checklist is designed to produce evidence, not just activity. Treat every checkbox as "done = verifiable". If you can't prove it with a test result, a log, or a signed artifact, it's not done. ## Scope and role mapping (week 0) Everything starts with role mapping. Your controls and evidence depend on whether you are a relying party, trust service provider/QTSP, wallet provider, or attribute issuer. Most organizations are multiple roles across different products. - Run the applicability test and document your roles per product/journey. - Inventory trust services you provide or rely on (signatures, seals, timestamps, delivery, website authentication). - Decide assurance level needs (advanced vs qualified) for each journey. ## Trust services implementation (build and prove) If you sign or validate, you need deterministic validation, revocation checks, and evidence retention that supports disputes and audits. Prefer standards-aligned formats and validation tooling to avoid interoperability failures. - Implement signature/seal validation with clear pass/fail reasoning and machine-readable reports. - Implement certificate status and revocation handling (including safe failure modes). - Define evidence retention and dispute-handling workflows (what logs you keep, for how long, and why). ## QTSP selection and vendor due diligence Most organizations outsource qualified trust services. That doesn't outsource your compliance risk. Treat QTSP selection as a security + audit decision with measurable acceptance criteria. - Create a QTSP requirements pack: service scope, SLAs, audit rights, incident notice, data handling, and evidence outputs. - Verify ETSI policy alignment (e.g., EN 319 401) and obtain audit reports / conformity assessment evidence. - Define fallback and exit strategy (provider change, certificate replacement, emergency signing continuity). ## EUDI Wallet readiness (eIDAS 2.0) If you authenticate users or rely on attributes, plan EUDI wallet flows as product capabilities with privacy and security controls. Interoperability and conformance testing are critical path items. - Define relying party acceptance strategy and user journeys to support wallet first. - Build verifier pipeline: authenticity/validity checks, status handling, decision logging, and monitoring. - Implement attribute schema governance and data minimization controls. - Run interoperability and negative test suites; gate releases on conformance. ## Evidence pack (what auditors and partners ask for first) Build an evidence index linking requirements to systems-of-record artifacts. Avoid static "evidence PDFs". Evidence should be reproducible and current. - Policies: trust service policy, security policy, incident response, change management, retention/deletion. - Tests: interoperability, revocation/status checks, negative testing, BC/DR drills. - Audits: QTSP audit reports, conformity assessments, and supervision-facing evidence where applicable. - Operational logs: validation decision logs, wallet interaction logs, incident records, remediation tracking. *Recommended next step* *Placement: after the checklist block* ## Turn EU eIDAS Checklist into an operational assessment Assessment Autopilot can take EU eIDAS Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU eIDAS Checklist](/solutions/assessment.md): Start from EU eIDAS Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Checklist. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Primary eIDAS legal framework for trust services and electronic identification. - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Wallet-centric amendments and ecosystem changes. - [ENISA - Security framework for trust service providers](https://www.enisa.europa.eu/publications/tsp-security?ref=sorena.io) - Technical security guidance supporting practical control design for trust services. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/checklist --- --- title: "eIDAS Compliance Program" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/compliance" source_url: "https://www.sorena.io/artifacts/eu/eidas/compliance" author: "Sorena AI" description: "A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls." keywords: - "eIDAS compliance program" - "eIDAS implementation guide" - "trust services compliance" - "QTSP oversight program" - "EUDI wallet compliance readiness" - "eIDAS audit readiness" - "eIDAS controls and evidence" - "trust services governance" - "QTSP oversight" - "EUDI wallet readiness" - "interoperability testing" - "audit readiness" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS Compliance Program A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. *Program Playbook* *EU* ## EU eIDAS Compliance Program Build a durable operating model: controls, tests, vendors, and evidence that stays current. Designed for compliance owners and engineering teams shipping identity and trust features. eIDAS compliance is not a one-off certification - it's an operating model. If you sign, validate, rely on trust services, or integrate the EUDI wallet, you must continuously prove integrity, security, and correct validation decisions. Use this playbook to build a role-scoped program with owners, measurable controls, interoperability tests, vendor oversight, and an evidence index that auditors and supervisors can trust. ## Program structure (the minimum viable operating model) Start by building a program structure aligned to how eIDAS is enforced: role-based obligations, evidence, and supervision readiness where qualification applies. Keep it simple: a small set of workstreams with clear owners and measurable outputs. - Workstream A - Trust services (signing/validation, certificate lifecycle, status checks, long-term validation). - Workstream B - QTSP vendor governance (selection, due diligence, ongoing monitoring, exit readiness). - Workstream C - EUDI wallet readiness (verifier pipeline, attribute governance, privacy and transparency controls). - Workstream D - Evidence and assurance (evidence index, audits, monitoring, incident learnings). ## Governance and RACI (who owns what) eIDAS work fails when it is "owned by compliance" but implemented in product without control acceptance criteria. Define clear RACI and decision gates for assurance level and vendor decisions. - Compliance: scope decisions, evidence index, audit management, and policy approvals. - Security: threat modeling, crypto/key management controls, incident response, and continuous control testing. - Engineering: validation pipeline, logging, interoperability testing, and change management for spec updates. - Legal/procurement: QTSP contracting, SLAs, incident notice, and exit/continuity terms. ## Controls and tests (make compliance measurable) Controls must be testable. If you can't test it automatically or via repeatable procedures, you can't prove it reliably. Build a test and assurance cadence tied to releases. - Interoperability tests: multi-format signatures and cross-provider validation; gate releases on pass criteria. - Negative tests: revoked certificates, expired timestamps, malformed signatures, chain anomalies, and replay attempts. - Operational drills: status service outages, key rotations, and incident response for trust-service-related issues. - Monitoring: validation failure rates, revocation/status check health, and anomalous signing patterns. *Recommended next step* *Placement: after the compliance steps* ## Turn EU eIDAS Compliance Program into an operational assessment Assessment Autopilot can take EU eIDAS Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU eIDAS Compliance Program](/solutions/assessment.md): Start from EU eIDAS Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Compliance Program. ## QTSP governance (vendor oversight that actually reduces risk) Most organizations rely on QTSPs for qualified services. Governance should focus on operational reliability and evidence quality, not marketing claims. Update your due diligence annually and after incidents or material changes. - Qualification validation: confirm qualified status and service scope for the exact service you rely on. - Audit evidence collection: obtain up-to-date audit reports/conformity assessments relevant to your usage. - Contract controls: incident notice, support commitments, evidence outputs, and continuity/exit obligations. - Ongoing monitoring: SLA performance, incident history, change notifications, and periodic evidence refresh. ## Evidence index (stay audit-ready without heroics) Build an evidence index that links requirements to living artifacts: logs, tests, policies, and vendor evidence. The evidence index is what allows fast responses to audits, supervision requests, and partner due diligence. - Requirement->Control->Test->Artifact mapping with owners and review cadence. - Versioning: record policy versions and verifier logic versions at time of decisions. - Exportability: ability to produce timeboxed evidence exports quickly and consistently. - Continuous improvement: track findings, remediation, and validation proof. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Primary eIDAS legal framework for trust services, roles, and supervision concepts. - [ENISA - Security framework for trust service providers](https://www.enisa.europa.eu/publications/tsp-security?ref=sorena.io) - Security guidance used to operationalize controls and audit-ready evidence for trust service providers. - [ENISA - Guidelines on supervision of qualified trust service providers](https://www.enisa.europa.eu/publications/tsp-supervision?ref=sorena.io) - Supervision guidance that informs program readiness and evidence expectations. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/compliance --- --- title: "eIDAS Compliance Program" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/compliance" source_url: "https://www.sorena.io/artifacts/eu/eidas/compliance" author: "Sorena AI" description: "A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls." keywords: - "eIDAS compliance program" - "eIDAS implementation guide" - "trust services compliance" - "QTSP oversight program" - "EUDI wallet compliance readiness" - "eIDAS audit readiness" - "eIDAS controls and evidence" - "trust services governance" - "QTSP oversight" - "EUDI wallet readiness" - "interoperability testing" - "audit readiness" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS Compliance Program A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. *Program Playbook* *EU* ## EU eIDAS Compliance Program Build a durable operating model: controls, tests, vendors, and evidence that stays current. Designed for compliance owners and engineering teams shipping identity and trust features. eIDAS compliance is not a one-off certification - it's an operating model. If you sign, validate, rely on trust services, or integrate the EUDI wallet, you must continuously prove integrity, security, and correct validation decisions. Use this playbook to build a role-scoped program with owners, measurable controls, interoperability tests, vendor oversight, and an evidence index that auditors and supervisors can trust. ## Program structure (the minimum viable operating model) Start by building a program structure aligned to how eIDAS is enforced: role-based obligations, evidence, and supervision readiness where qualification applies. Keep it simple: a small set of workstreams with clear owners and measurable outputs. - Workstream A - Trust services (signing/validation, certificate lifecycle, status checks, long-term validation). - Workstream B - QTSP vendor governance (selection, due diligence, ongoing monitoring, exit readiness). - Workstream C - EUDI wallet readiness (verifier pipeline, attribute governance, privacy and transparency controls). - Workstream D - Evidence and assurance (evidence index, audits, monitoring, incident learnings). ## Governance and RACI (who owns what) eIDAS work fails when it is "owned by compliance" but implemented in product without control acceptance criteria. Define clear RACI and decision gates for assurance level and vendor decisions. - Compliance: scope decisions, evidence index, audit management, and policy approvals. - Security: threat modeling, crypto/key management controls, incident response, and continuous control testing. - Engineering: validation pipeline, logging, interoperability testing, and change management for spec updates. - Legal/procurement: QTSP contracting, SLAs, incident notice, and exit/continuity terms. ## Controls and tests (make compliance measurable) Controls must be testable. If you can't test it automatically or via repeatable procedures, you can't prove it reliably. Build a test and assurance cadence tied to releases. - Interoperability tests: multi-format signatures and cross-provider validation; gate releases on pass criteria. - Negative tests: revoked certificates, expired timestamps, malformed signatures, chain anomalies, and replay attempts. - Operational drills: status service outages, key rotations, and incident response for trust-service-related issues. - Monitoring: validation failure rates, revocation/status check health, and anomalous signing patterns. *Recommended next step* *Placement: after the compliance steps* ## Turn EU eIDAS Compliance Program into an operational assessment Assessment Autopilot can take EU eIDAS Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU eIDAS Compliance Program](/solutions/assessment.md): Start from EU eIDAS Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Compliance Program. ## QTSP governance (vendor oversight that actually reduces risk) Most organizations rely on QTSPs for qualified services. Governance should focus on operational reliability and evidence quality, not marketing claims. Update your due diligence annually and after incidents or material changes. - Qualification validation: confirm qualified status and service scope for the exact service you rely on. - Audit evidence collection: obtain up-to-date audit reports/conformity assessments relevant to your usage. - Contract controls: incident notice, support commitments, evidence outputs, and continuity/exit obligations. - Ongoing monitoring: SLA performance, incident history, change notifications, and periodic evidence refresh. ## Evidence index (stay audit-ready without heroics) Build an evidence index that links requirements to living artifacts: logs, tests, policies, and vendor evidence. The evidence index is what allows fast responses to audits, supervision requests, and partner due diligence. - Requirement->Control->Test->Artifact mapping with owners and review cadence. - Versioning: record policy versions and verifier logic versions at time of decisions. - Exportability: ability to produce timeboxed evidence exports quickly and consistently. - Continuous improvement: track findings, remediation, and validation proof. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Primary eIDAS legal framework for trust services, roles, and supervision concepts. - [ENISA - Security framework for trust service providers](https://www.enisa.europa.eu/publications/tsp-security?ref=sorena.io) - Security guidance used to operationalize controls and audit-ready evidence for trust service providers. - [ENISA - Guidelines on supervision of qualified trust service providers](https://www.enisa.europa.eu/publications/tsp-supervision?ref=sorena.io) - Supervision guidance that informs program readiness and evidence expectations. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/compliance --- --- title: "eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/eidas/deadlines-and-compliance-calendar" author: "Sorena AI" description: "An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment." keywords: - "eIDAS deadlines" - "eIDAS compliance calendar" - "eIDAS timeline" - "eIDAS 2.0 timeline" - "EUDI Wallet deadlines" - "when do relying parties have to accept EUDI wallet" - "eIDAS key dates" - "EU trust services deadlines" - "EUDI Wallet key dates" - "implementing acts" - "relying party acceptance" - "trust services calendar" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. *Calendar* *EU* ## EU eIDAS Deadlines + Compliance Calendar Plan eIDAS and EUDI Wallet workstreams with concrete milestones and evidence gates. Grounded in eIDAS (Regulation (EU) No 910/2014) and the eIDAS 2.0 amendment (Regulation (EU) 2024/1183). eIDAS timelines are easy to misunderstand because obligations are split across baseline rules, the 2024 amendment, and wallet-specific implementing acts. The best calendar is not a list of dates. It is a readiness plan tied to deliverables such as architecture, policies, tests, conformity evidence, and operating procedures so you can prove compliance when requirements become active. ## Anchor dates (the "never forget" milestones) Use these dates as fixed anchors for planning, budget, and executive communications. They remove most of the ambiguity around the amended framework. Always confirm any national guidance that affects supervision, wallet acceptance, or trust-service oversight in your Member State. - 1 July 2016: baseline eIDAS application date for Regulation (EU) No 910/2014, subject to the text's specific exceptions. - 30 April 2024: publication of Regulation (EU) 2024/1183 in the Official Journal, with the amendment applying after entry into force in May 2024. - 21 November 2024: Commission deadline in multiple amended articles to adopt wallet reference standards, certification procedures, and formats for wallet-related processes. - 28 November 2024 adoption and 4 December 2024 publication: Commission adoption of five wallet implementing regulations covering core functionalities, protocols and interfaces, person-identification data and electronic attestations of attributes, certification, and ecosystem notifications. - 21 May 2026: Commission review-report deadline and deadline for QTSPs qualified before 20 May 2024 to submit a conformity assessment report covering the amended Article 24 requirements. - By the end of 2026: Member States must provide at least one European Digital Identity Wallet under the amended framework. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU eIDAS Deadlines + Compliance Calendar into an operational assessment Assessment Autopilot can take EU eIDAS Deadlines + Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU eIDAS Deadlines + Compliance Calendar](/solutions/assessment.md): Start from EU eIDAS Deadlines + Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Deadlines + Compliance Calendar. ## EUDI Wallet acceptance timing (how to plan when the date depends on implementing acts) Some wallet-related obligations are tied to the entry into force of implementing acts rather than a single universal date. That means you should plan readiness as a capability, not a one-day launch. For many relying parties, the practical trigger is a combination of legal obligation to identify customers, the relevant wallet implementing acts, and Member State rollout by the end of 2026. - Build the relying-party integration in phases: discovery -> minimal verifier -> attribute flow -> production hardening. - Track the five wallet implementing regulations because they define the technical floor for core functionalities, protocols, PID and attribute handling, certification, and ecosystem notifications. - Treat interoperability, issuer trust, revocation or status checks, and privacy logging as critical-path items because they drive support load and incident risk. ## Milestone plan (recommended) This plan is designed to create real readiness and reusable evidence. It is optimized for product, security, identity, and compliance teams working together. Adjust cadence based on whether you are a relying party, QTSP, wallet provider, or issuer. - T-0: role mapping and service inventory covering trust services, relying-party journeys, wallet dependencies, and attribute use cases. - T-1: architecture blueprint covering verifier flows, trust model, logging, privacy boundaries, and integration points with QTSPs or issuers. - T-2: controls and evidence design covering policies, procedures, audit logging, identity-proofing methods, and conformity evidence. - T-3: interoperability and conformance testing covering multi-wallet or multi-issuer scenarios, negative tests, revocation, and degraded dependencies. - T-4: operational readiness covering monitoring, incident response, change management, supervisory response, and partner-onboarding playbooks. ## What to put on your internal calendar (deliverables, not dates) The best way to hit regulatory dates is to calendar the work that creates proof and reduces delivery risk. These deliverables also improve customer experience and reduce support overhead. - Wallet verifier MVP shipped with logs, revocation checks, and a measurable failure-rate target. - Attribute schema governance approved with acceptance rules, retention limits, and test coverage. - QTSP due-diligence pack refreshed with trust-list evidence, conformity reports, and transition-status review for Article 24 changes. - Quarterly wallet drills completed for revoked credentials, issuer key rotation, degraded network conditions, and audit-log sampling. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Consolidated text showing the 21 November 2024 implementing-act deadlines, the 21 May 2026 review and conformity deadlines, and the 9 April 2025 corrigendum. - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amending regulation published on 30 April 2024 that established the European Digital Identity Framework and the wallet-related deadline structure. - [European Commission - EUDI regulation policy page](https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation?ref=sorena.io) - Commission process page for the common toolbox and technical alignment work that supports implementing acts and interoperability. - [European Commission - EUDI wallet toolbox process](https://digital-strategy.ec.europa.eu/en/policies/eudi-wallet-toolbox?ref=sorena.io) - Commission information about the toolbox process that drives common specifications and implementation alignment. - [European Commission - Implementing regulation for European Digital Identity Wallets](https://digital-strategy.ec.europa.eu/en/library/implementing-regulation-european-digital-identity-wallets?ref=sorena.io) - Commission page confirming adoption of five wallet implementing regulations and summarizing their scope. ## Related Topic Guides - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/deadlines-and-compliance-calendar --- --- title: "eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/eidas/deadlines-and-compliance-calendar" author: "Sorena AI" description: "An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment." keywords: - "eIDAS deadlines" - "eIDAS compliance calendar" - "eIDAS timeline" - "eIDAS 2.0 timeline" - "EUDI Wallet deadlines" - "when do relying parties have to accept EUDI wallet" - "eIDAS key dates" - "EU trust services deadlines" - "EUDI Wallet key dates" - "implementing acts" - "relying party acceptance" - "trust services calendar" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. *Calendar* *EU* ## EU eIDAS Deadlines + Compliance Calendar Plan eIDAS and EUDI Wallet workstreams with concrete milestones and evidence gates. Grounded in eIDAS (Regulation (EU) No 910/2014) and the eIDAS 2.0 amendment (Regulation (EU) 2024/1183). eIDAS timelines are easy to misunderstand because obligations are split across baseline rules, the 2024 amendment, and wallet-specific implementing acts. The best calendar is not a list of dates. It is a readiness plan tied to deliverables such as architecture, policies, tests, conformity evidence, and operating procedures so you can prove compliance when requirements become active. ## Anchor dates (the "never forget" milestones) Use these dates as fixed anchors for planning, budget, and executive communications. They remove most of the ambiguity around the amended framework. Always confirm any national guidance that affects supervision, wallet acceptance, or trust-service oversight in your Member State. - 1 July 2016: baseline eIDAS application date for Regulation (EU) No 910/2014, subject to the text's specific exceptions. - 30 April 2024: publication of Regulation (EU) 2024/1183 in the Official Journal, with the amendment applying after entry into force in May 2024. - 21 November 2024: Commission deadline in multiple amended articles to adopt wallet reference standards, certification procedures, and formats for wallet-related processes. - 28 November 2024 adoption and 4 December 2024 publication: Commission adoption of five wallet implementing regulations covering core functionalities, protocols and interfaces, person-identification data and electronic attestations of attributes, certification, and ecosystem notifications. - 21 May 2026: Commission review-report deadline and deadline for QTSPs qualified before 20 May 2024 to submit a conformity assessment report covering the amended Article 24 requirements. - By the end of 2026: Member States must provide at least one European Digital Identity Wallet under the amended framework. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU eIDAS Deadlines + Compliance Calendar into an operational assessment Assessment Autopilot can take EU eIDAS Deadlines + Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU eIDAS Deadlines + Compliance Calendar](/solutions/assessment.md): Start from EU eIDAS Deadlines + Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Deadlines + Compliance Calendar. ## EUDI Wallet acceptance timing (how to plan when the date depends on implementing acts) Some wallet-related obligations are tied to the entry into force of implementing acts rather than a single universal date. That means you should plan readiness as a capability, not a one-day launch. For many relying parties, the practical trigger is a combination of legal obligation to identify customers, the relevant wallet implementing acts, and Member State rollout by the end of 2026. - Build the relying-party integration in phases: discovery -> minimal verifier -> attribute flow -> production hardening. - Track the five wallet implementing regulations because they define the technical floor for core functionalities, protocols, PID and attribute handling, certification, and ecosystem notifications. - Treat interoperability, issuer trust, revocation or status checks, and privacy logging as critical-path items because they drive support load and incident risk. ## Milestone plan (recommended) This plan is designed to create real readiness and reusable evidence. It is optimized for product, security, identity, and compliance teams working together. Adjust cadence based on whether you are a relying party, QTSP, wallet provider, or issuer. - T-0: role mapping and service inventory covering trust services, relying-party journeys, wallet dependencies, and attribute use cases. - T-1: architecture blueprint covering verifier flows, trust model, logging, privacy boundaries, and integration points with QTSPs or issuers. - T-2: controls and evidence design covering policies, procedures, audit logging, identity-proofing methods, and conformity evidence. - T-3: interoperability and conformance testing covering multi-wallet or multi-issuer scenarios, negative tests, revocation, and degraded dependencies. - T-4: operational readiness covering monitoring, incident response, change management, supervisory response, and partner-onboarding playbooks. ## What to put on your internal calendar (deliverables, not dates) The best way to hit regulatory dates is to calendar the work that creates proof and reduces delivery risk. These deliverables also improve customer experience and reduce support overhead. - Wallet verifier MVP shipped with logs, revocation checks, and a measurable failure-rate target. - Attribute schema governance approved with acceptance rules, retention limits, and test coverage. - QTSP due-diligence pack refreshed with trust-list evidence, conformity reports, and transition-status review for Article 24 changes. - Quarterly wallet drills completed for revoked credentials, issuer key rotation, degraded network conditions, and audit-log sampling. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Consolidated text showing the 21 November 2024 implementing-act deadlines, the 21 May 2026 review and conformity deadlines, and the 9 April 2025 corrigendum. - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amending regulation published on 30 April 2024 that established the European Digital Identity Framework and the wallet-related deadline structure. - [European Commission - EUDI regulation policy page](https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation?ref=sorena.io) - Commission process page for the common toolbox and technical alignment work that supports implementing acts and interoperability. - [European Commission - EUDI wallet toolbox process](https://digital-strategy.ec.europa.eu/en/policies/eudi-wallet-toolbox?ref=sorena.io) - Commission information about the toolbox process that drives common specifications and implementation alignment. - [European Commission - Implementing regulation for European Digital Identity Wallets](https://digital-strategy.ec.europa.eu/en/library/implementing-regulation-european-digital-identity-wallets?ref=sorena.io) - Commission page confirming adoption of five wallet implementing regulations and summarizing their scope. ## Related Topic Guides - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/deadlines-and-compliance-calendar --- --- title: "eIDAS vs E-SIGN Act vs UETA" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/eidas-vs-esign-and-ueta" source_url: "https://www.sorena.io/artifacts/eu/eidas/eidas-vs-esign-and-ueta" author: "Sorena AI" description: "A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect." keywords: - "eIDAS vs ESIGN" - "eIDAS vs UETA" - "EU vs US electronic signature law" - "qualified electronic signature vs ESIGN" - "cross border electronic signatures" - "eSignature compliance EU US" - "electronic signature evidence requirements" - "EU vs US electronic signatures" - "qualified electronic signature" - "audit evidence" - "cross-border contracting" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS vs E-SIGN Act vs UETA A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. *Comparison* *EU/US* ## eIDAS vs E-SIGN + UETA Understand the EU vs US differences and design one signing system that works cross-border. Focus: legal effect, assurance model, vendor ecosystem, and evidence you must retain. Cross-border eSignature programs fail when teams assume "an eSignature is an eSignature everywhere". eIDAS provides an EU trust services framework with concepts like qualified trust services, supervision, trust lists, and standardized profiles. US E-SIGN and UETA provide broad legal validity for electronic records and signatures, with a different structure and fewer standardized "qualified" constructs. The practical goal is to build a signing + validation capability that can produce the right evidence for each jurisdiction without duplicating the entire system. ## High-level differences (what engineers and GRC teams should remember) eIDAS is a regulatory framework that combines legal effect with a trust service provider ecosystem, supervision of qualified services, and a strong standards layer for interoperability. E-SIGN and UETA validate electronic records and signatures broadly but do not mirror the EU "qualified trust service" construct in the same way. - eIDAS: assurance tiers and "qualified" services (QES/QSeal/QTimestamp/qualified ERDS), plus trust lists and supervision expectations. - E-SIGN/UETA: broad validity of electronic signatures/records for transactions, subject to exceptions and process requirements. - Operational implication: EU programs often need stricter evidence packages and standards-aligned validation reports. *Recommended next step* *Placement: after the comparison section* ## Use eIDAS vs E-SIGN + UETA as a cited research workflow Research Copilot can take eIDAS vs E-SIGN + UETA from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for eIDAS vs E-SIGN + UETA](/solutions/research-copilot.md): Start from eIDAS vs E-SIGN + UETA and answer scope, timing, and interpretation questions with cited outputs. - [Talk through eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for eIDAS vs E-SIGN + UETA. ## Assurance model: "qualified" vs "good evidence" In practice, most disputes are evidence disputes: can you prove identity binding, intent, integrity, and time semantics? eIDAS formalizes higher-assurance trust services; US frameworks emphasize legal recognition and consent/retention concepts, with less centralized "qualified provider" machinery. - Design signing ceremonies with explicit intent and strong authentication when risk is high. - Build deterministic validation reports with reason codes and versioned policies. - Use a vendor due diligence binder for signature providers and certificate infrastructure, regardless of jurisdiction. ## What to build (one cross-border architecture) You don't need two systems - you need one system that can generate jurisdiction-specific evidence views. Treat signing as a capability with inputs (documents + identity) and outputs (signed artifacts + validation evidence + logs). - Signing layer: ceremony design + format strategy + timestamping decisions. - Validation layer: chain + status checks + policy evaluation + machine-readable reports. - Evidence layer: logs, audit trails, retention rules, and dispute-handling workflow. - Vendor layer: QTSP/CA selection, SLAs, incident notice, audit evidence, and exit strategy. ## Common pitfalls (EU/US) Most failures come from missing evidence and ambiguous validation decisions, not from the crypto. Avoid these pitfalls early to reduce customer support and legal escalation costs. - No deterministic validation report -> disputes become "we think it was valid". - Revocation/status handling isn't monitored -> signatures fail unpredictably in production. - Vendor qualification claims are not verified -> reliance posture becomes brittle. - Retention rules aren't testable -> you can't produce evidence years later. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - EU legal framework for trust services and electronic identification. - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amends eIDAS and introduces the EUDI wallet framework. - [Electronic Signatures in Global and National Commerce Act (E-SIGN Act) - GovInfo compilation PDF](https://www.govinfo.gov/content/pkg/COMPS-940/pdf/COMPS-940.pdf?ref=sorena.io) - US federal legal text compilation for the E-SIGN Act. - [Uniform Electronic Transactions Act (UETA) - Uniform Law Commission (final act)](https://www.uniformlaws.org/viewdocument/final-act-21?CommunityKey=2c04b76c-2b7d-4399-977e-d5876ba7e034&tab=librarydocuments&ref=sorena.io) - Uniform law text and supporting materials for UETA. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/eidas-vs-esign-and-ueta --- --- title: "eIDAS vs E-SIGN Act vs UETA" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/eidas-vs-esign-and-ueta" source_url: "https://www.sorena.io/artifacts/eu/eidas/eidas-vs-esign-and-ueta" author: "Sorena AI" description: "A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect." keywords: - "eIDAS vs ESIGN" - "eIDAS vs UETA" - "EU vs US electronic signature law" - "qualified electronic signature vs ESIGN" - "cross border electronic signatures" - "eSignature compliance EU US" - "electronic signature evidence requirements" - "EU vs US electronic signatures" - "qualified electronic signature" - "audit evidence" - "cross-border contracting" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS vs E-SIGN Act vs UETA A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. *Comparison* *EU/US* ## eIDAS vs E-SIGN + UETA Understand the EU vs US differences and design one signing system that works cross-border. Focus: legal effect, assurance model, vendor ecosystem, and evidence you must retain. Cross-border eSignature programs fail when teams assume "an eSignature is an eSignature everywhere". eIDAS provides an EU trust services framework with concepts like qualified trust services, supervision, trust lists, and standardized profiles. US E-SIGN and UETA provide broad legal validity for electronic records and signatures, with a different structure and fewer standardized "qualified" constructs. The practical goal is to build a signing + validation capability that can produce the right evidence for each jurisdiction without duplicating the entire system. ## High-level differences (what engineers and GRC teams should remember) eIDAS is a regulatory framework that combines legal effect with a trust service provider ecosystem, supervision of qualified services, and a strong standards layer for interoperability. E-SIGN and UETA validate electronic records and signatures broadly but do not mirror the EU "qualified trust service" construct in the same way. - eIDAS: assurance tiers and "qualified" services (QES/QSeal/QTimestamp/qualified ERDS), plus trust lists and supervision expectations. - E-SIGN/UETA: broad validity of electronic signatures/records for transactions, subject to exceptions and process requirements. - Operational implication: EU programs often need stricter evidence packages and standards-aligned validation reports. *Recommended next step* *Placement: after the comparison section* ## Use eIDAS vs E-SIGN + UETA as a cited research workflow Research Copilot can take eIDAS vs E-SIGN + UETA from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for eIDAS vs E-SIGN + UETA](/solutions/research-copilot.md): Start from eIDAS vs E-SIGN + UETA and answer scope, timing, and interpretation questions with cited outputs. - [Talk through eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for eIDAS vs E-SIGN + UETA. ## Assurance model: "qualified" vs "good evidence" In practice, most disputes are evidence disputes: can you prove identity binding, intent, integrity, and time semantics? eIDAS formalizes higher-assurance trust services; US frameworks emphasize legal recognition and consent/retention concepts, with less centralized "qualified provider" machinery. - Design signing ceremonies with explicit intent and strong authentication when risk is high. - Build deterministic validation reports with reason codes and versioned policies. - Use a vendor due diligence binder for signature providers and certificate infrastructure, regardless of jurisdiction. ## What to build (one cross-border architecture) You don't need two systems - you need one system that can generate jurisdiction-specific evidence views. Treat signing as a capability with inputs (documents + identity) and outputs (signed artifacts + validation evidence + logs). - Signing layer: ceremony design + format strategy + timestamping decisions. - Validation layer: chain + status checks + policy evaluation + machine-readable reports. - Evidence layer: logs, audit trails, retention rules, and dispute-handling workflow. - Vendor layer: QTSP/CA selection, SLAs, incident notice, audit evidence, and exit strategy. ## Common pitfalls (EU/US) Most failures come from missing evidence and ambiguous validation decisions, not from the crypto. Avoid these pitfalls early to reduce customer support and legal escalation costs. - No deterministic validation report -> disputes become "we think it was valid". - Revocation/status handling isn't monitored -> signatures fail unpredictably in production. - Vendor qualification claims are not verified -> reliance posture becomes brittle. - Retention rules aren't testable -> you can't produce evidence years later. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - EU legal framework for trust services and electronic identification. - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amends eIDAS and introduces the EUDI wallet framework. - [Electronic Signatures in Global and National Commerce Act (E-SIGN Act) - GovInfo compilation PDF](https://www.govinfo.gov/content/pkg/COMPS-940/pdf/COMPS-940.pdf?ref=sorena.io) - US federal legal text compilation for the E-SIGN Act. - [Uniform Electronic Transactions Act (UETA) - Uniform Law Commission (final act)](https://www.uniformlaws.org/viewdocument/final-act-21?CommunityKey=2c04b76c-2b7d-4399-977e-d5876ba7e034&tab=librarydocuments&ref=sorena.io) - Uniform law text and supporting materials for UETA. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/eidas-vs-esign-and-ueta --- --- title: "eIDAS 2.0 vs eIDAS" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/eidas2-vs-eidas" source_url: "https://www.sorena.io/artifacts/eu/eidas/eidas2-vs-eidas" author: "Sorena AI" description: "A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes." keywords: - "eIDAS 2.0 vs eIDAS" - "Regulation (EU) 2024/1183 vs 910/2014" - "EUDI Wallet vs eIDAS" - "what is new in eIDAS 2.0" - "electronic attestation of attributes eIDAS 2.0" - "relying party EUDI wallet acceptance" - "Regulation (EU) 2024/1183" - "EUDI wallet" - "electronic attestation of attributes" - "relying party" - "interoperability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS 2.0 vs eIDAS A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. *Comparison* *EU* ## EU eIDAS eIDAS 2.0 vs eIDAS eIDAS 2.0 introduces the EUDI Wallet and reshapes relying party and attribute ecosystems. Use this page to plan what to build and what evidence you'll need. eIDAS (Regulation (EU) No 910/2014) established EU trust services and cross-border eID recognition. The amended framework, as changed by Regulation (EU) 2024/1183 and corrected on 9 April 2025, keeps that foundation but expands the system in two important ways: it introduces European Digital Identity Wallets and it expands the trust-service perimeter to cover electronic attestations of attributes, electronic archiving, electronic ledgers, and management of remote electronic signature and seal creation devices. The practical takeaway is that many organizations now need new wallet-compatible flows, expanded trust-service scoping, and a stronger evidence program. ## What stayed the same (the eIDAS foundation still matters) Trust services remain core: electronic signatures, seals, timestamps, registered delivery, website authentication, and supervision of qualified trust services. If you already rely on qualified trust services (e.g., QES), you still need strong QTSP due diligence, evidence retention, and lifecycle governance. - Trust service categories and legal effects remain foundational for cross-border digital transactions. - Supervision and audit expectations for QTSPs remain central for high-assurance use cases. - Standards alignment, including ETSI signature, certificate, and policy profiles, still matters for interoperability. ## What changed (EUDI Wallet + attribute ecosystems) The amended framework adds wallet-centric capabilities and responsibilities, including wallet providers, relying-party acceptance concepts, and attribute issuance or verification pipelines. It also extends the trust-service perimeter. eIDAS is no longer only about signatures, seals, timestamps, delivery, and website authentication. - EUDI Wallet: identity and attribute container with security, certification, and user-transparency expectations, including transaction logs. - Electronic attestations of attributes: a new attribute layer that relying parties can request and verify with user-controlled disclosure. - Expanded trust services: electronic archiving, electronic ledgers, and management of remote electronic signature and seal creation devices. - Implementation layer: the Commission adopted five wallet implementing regulations in late 2024 to define core functionalities, interfaces, PID and attributes, certification, and ecosystem notifications. ## Operational impacts for relying parties If you authenticate users or rely on identity attributes, EUDI Wallet can become a new channel that must be integrated with privacy and security guardrails. Relying party readiness is not only technical: it affects product UX, data governance, and incident handling. - Acceptance planning: decide which journeys will support wallet-based authentication first and define safe fallback paths. - Verification pipeline: implement deterministic verification, revocation or status checks, and decision logs for wallets, signatures, and attribute attestations. - Data minimization and transparency: enforce minimal-attribute requests and provide clear user-facing explanations. - Roadmap timing: plan around the end-2026 wallet rollout and the late-2024 implementing acts rather than treating eIDAS 2.0 as a distant concept. ## Program strategy (build once, generate many evidence views) Do not build eIDAS compliance and wallet integration as separate programs. Build one identity and trust program with reusable evidence. Treat outputs as living artifacts: policies, architecture decisions, test results, conformity evidence, supervisory correspondence, and operational logs. - Control system: trust services governance + wallet flow controls + verification logging + change management. - Evidence system: a single evidence index that supports audits, regulators, and partner due diligence. - Testing cadence: interoperability tests + negative tests + operational drills (revocations, issuer key rotations). *Recommended next step* *Placement: after the comparison section* ## Use EU eIDAS eIDAS 2.0 vs eIDAS as a cited research workflow Research Copilot can take EU eIDAS eIDAS 2.0 vs eIDAS from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU eIDAS eIDAS 2.0 vs eIDAS](/solutions/research-copilot.md): Start from EU eIDAS eIDAS 2.0 vs eIDAS and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS eIDAS 2.0 vs eIDAS. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Consolidated eIDAS text showing the expanded trust-service scope and corrigendum status after the 2024 amendment. - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amending regulation that introduced the European Digital Identity Framework and expanded trust-service categories. - [European Commission - EUDI Wallet Architecture and Reference Framework (ARF)](https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-wallet-architecture-and-reference-framework?ref=sorena.io) - Reference framework used to drive interoperable wallet solutions and shared technical specifications. - [European Commission - Implementing regulation for European Digital Identity Wallets](https://digital-strategy.ec.europa.eu/en/library/implementing-regulation-european-digital-identity-wallets?ref=sorena.io) - Commission page summarizing the five wallet implementing regulations adopted in late 2024. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/eidas2-vs-eidas --- --- title: "eIDAS 2.0 vs eIDAS" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/eidas2-vs-eidas" source_url: "https://www.sorena.io/artifacts/eu/eidas/eidas2-vs-eidas" author: "Sorena AI" description: "A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes." keywords: - "eIDAS 2.0 vs eIDAS" - "Regulation (EU) 2024/1183 vs 910/2014" - "EUDI Wallet vs eIDAS" - "what is new in eIDAS 2.0" - "electronic attestation of attributes eIDAS 2.0" - "relying party EUDI wallet acceptance" - "Regulation (EU) 2024/1183" - "EUDI wallet" - "electronic attestation of attributes" - "relying party" - "interoperability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS 2.0 vs eIDAS A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. *Comparison* *EU* ## EU eIDAS eIDAS 2.0 vs eIDAS eIDAS 2.0 introduces the EUDI Wallet and reshapes relying party and attribute ecosystems. Use this page to plan what to build and what evidence you'll need. eIDAS (Regulation (EU) No 910/2014) established EU trust services and cross-border eID recognition. The amended framework, as changed by Regulation (EU) 2024/1183 and corrected on 9 April 2025, keeps that foundation but expands the system in two important ways: it introduces European Digital Identity Wallets and it expands the trust-service perimeter to cover electronic attestations of attributes, electronic archiving, electronic ledgers, and management of remote electronic signature and seal creation devices. The practical takeaway is that many organizations now need new wallet-compatible flows, expanded trust-service scoping, and a stronger evidence program. ## What stayed the same (the eIDAS foundation still matters) Trust services remain core: electronic signatures, seals, timestamps, registered delivery, website authentication, and supervision of qualified trust services. If you already rely on qualified trust services (e.g., QES), you still need strong QTSP due diligence, evidence retention, and lifecycle governance. - Trust service categories and legal effects remain foundational for cross-border digital transactions. - Supervision and audit expectations for QTSPs remain central for high-assurance use cases. - Standards alignment, including ETSI signature, certificate, and policy profiles, still matters for interoperability. ## What changed (EUDI Wallet + attribute ecosystems) The amended framework adds wallet-centric capabilities and responsibilities, including wallet providers, relying-party acceptance concepts, and attribute issuance or verification pipelines. It also extends the trust-service perimeter. eIDAS is no longer only about signatures, seals, timestamps, delivery, and website authentication. - EUDI Wallet: identity and attribute container with security, certification, and user-transparency expectations, including transaction logs. - Electronic attestations of attributes: a new attribute layer that relying parties can request and verify with user-controlled disclosure. - Expanded trust services: electronic archiving, electronic ledgers, and management of remote electronic signature and seal creation devices. - Implementation layer: the Commission adopted five wallet implementing regulations in late 2024 to define core functionalities, interfaces, PID and attributes, certification, and ecosystem notifications. ## Operational impacts for relying parties If you authenticate users or rely on identity attributes, EUDI Wallet can become a new channel that must be integrated with privacy and security guardrails. Relying party readiness is not only technical: it affects product UX, data governance, and incident handling. - Acceptance planning: decide which journeys will support wallet-based authentication first and define safe fallback paths. - Verification pipeline: implement deterministic verification, revocation or status checks, and decision logs for wallets, signatures, and attribute attestations. - Data minimization and transparency: enforce minimal-attribute requests and provide clear user-facing explanations. - Roadmap timing: plan around the end-2026 wallet rollout and the late-2024 implementing acts rather than treating eIDAS 2.0 as a distant concept. ## Program strategy (build once, generate many evidence views) Do not build eIDAS compliance and wallet integration as separate programs. Build one identity and trust program with reusable evidence. Treat outputs as living artifacts: policies, architecture decisions, test results, conformity evidence, supervisory correspondence, and operational logs. - Control system: trust services governance + wallet flow controls + verification logging + change management. - Evidence system: a single evidence index that supports audits, regulators, and partner due diligence. - Testing cadence: interoperability tests + negative tests + operational drills (revocations, issuer key rotations). *Recommended next step* *Placement: after the comparison section* ## Use EU eIDAS eIDAS 2.0 vs eIDAS as a cited research workflow Research Copilot can take EU eIDAS eIDAS 2.0 vs eIDAS from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU eIDAS eIDAS 2.0 vs eIDAS](/solutions/research-copilot.md): Start from EU eIDAS eIDAS 2.0 vs eIDAS and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS eIDAS 2.0 vs eIDAS. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Consolidated eIDAS text showing the expanded trust-service scope and corrigendum status after the 2024 amendment. - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amending regulation that introduced the European Digital Identity Framework and expanded trust-service categories. - [European Commission - EUDI Wallet Architecture and Reference Framework (ARF)](https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-wallet-architecture-and-reference-framework?ref=sorena.io) - Reference framework used to drive interoperable wallet solutions and shared technical specifications. - [European Commission - Implementing regulation for European Digital Identity Wallets](https://digital-strategy.ec.europa.eu/en/library/implementing-regulation-european-digital-identity-wallets?ref=sorena.io) - Commission page summarizing the five wallet implementing regulations adopted in late 2024. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/eidas2-vs-eidas --- --- title: "Electronic Signatures under eIDAS" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/electronic-signatures-and-legal-effect" source_url: "https://www.sorena.io/artifacts/eu/eidas/electronic-signatures-and-legal-effect" author: "Sorena AI" description: "A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing." keywords: - "eIDAS electronic signature" - "advanced electronic signature AdES" - "qualified electronic signature QES" - "AdES vs QES" - "eIDAS legal effect of electronic signatures" - "remote qualified signature" - "eIDAS signature validation report" - "long term validation eIDAS" - "electronic signatures" - "qualified electronic signature" - "advanced electronic signature" - "remote signing" - "signature validation" - "legal effect" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Electronic Signatures under eIDAS A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. *Deep Guide* *EU* ## EU eIDAS Electronic Signatures Decide AdES vs QES, then build signing + validation workflows with reproducible evidence. Designed for product teams shipping signing features and compliance teams owning dispute and audit readiness. Electronic signatures are a product capability with legal impact. Under eIDAS, the choices you make (advanced vs qualified signatures, remote signing, validation policy, long-term preservation) determine how defensible your signatures are in disputes and audits. This guide focuses on operational reality: how to implement signing ceremonies, validation pipelines, and evidence retention so outcomes are reproducible and interoperable. ## AdES vs QES (decision framework) Start with risk and legal requirements for your use case. Many journeys do not need QES, but some do (by law, policy, or business risk). Treat the choice as an architecture decision with acceptance criteria and evidence requirements. - Risk and regulatory requirement: what level is required (or expected) for enforceability and cross-border use? - User experience: how strong authentication and signing ceremony affect conversion and support costs. - Evidence and disputes: what you must prove later (identity binding, intent, integrity, timestamping). ## Signing ceremony design (what to implement, not just what to say) Signing disputes often come down to ceremony design: was the user authenticated, did they see what they signed, and can you prove it? Build the ceremony as a measurable workflow with logs and replayable evidence. - Authentication + intent: record what authentication was used and capture explicit intent signals. - Document integrity: canonicalize what is signed (hashes, rendering, and versioning). - Time semantics: ensure timestamps are consistent and explainable across systems and time zones. - Non-repudiation evidence: logs, validation reports, and evidence records for later disputes. ## Remote/cloud signing (what makes it hard) Remote signing can improve UX but increases reliance on external services, device binding, and identity proofing. Treat it as a vendor + architecture decision with explicit SLA, incident, and evidence outputs. - Vendor governance: ensure QTSP and remote signing services provide the audit evidence you need. - Key protection: understand where keys live and how signing authorization is enforced. - Failure handling: define how to handle provider outages without silent downgrades. ## Validation pipeline (how to make decisions defensible) Validation is not "check the signature once". It's a policy-driven decision system that must produce reproducible reports. Build a deterministic pipeline with explicit reason codes and versioned policies. - Certificate chain validation and trust anchor integration (trusted lists). - Revocation/status handling with safe failure modes and monitored dependencies. - Machine-readable validation reports plus human-readable summaries for disputes. - Long-term validation strategy: evidence records and preservation decisions. ## Implementation playbook (fast path) Avoid bespoke crypto. Use standards-aligned libraries and tooling that can produce the reports you need. The Commission's DSS project is a common reference for signature creation and validation workflows. - Pick supported formats and freeze a "supported matrix" per product journey. - Build a stable test suite: known-good and known-bad samples that must remain stable across releases. - Instrument everything: decision logs, reports, monitoring, and incident procedures. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU eIDAS Electronic Signatures as a cited research workflow Research Copilot can take EU eIDAS Electronic Signatures from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU eIDAS Electronic Signatures](/solutions/research-copilot.md): Start from EU eIDAS Electronic Signatures and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Electronic Signatures. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Defines electronic signatures (advanced and qualified) and legal effect framework. - [European Commission - Digital Signature Service (DSS) (Digital Building Blocks)](https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467109107/Digital+Signature+Service+-+DSS?ref=sorena.io) - Technical documentation and reference implementation guidance for signature creation and validation. - [ETSI press release - Cloud-based digital signature specifications](https://www.etsi.org/newsroom/press-releases/1573-2019-04-etsi-releases-three-specifications-for-cloud-based-digital-signatures?ref=sorena.io) - ETSI context on cloud-based/remote signature specifications. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/electronic-signatures-and-legal-effect --- --- title: "Electronic Signatures under eIDAS" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/electronic-signatures-and-legal-effect" source_url: "https://www.sorena.io/artifacts/eu/eidas/electronic-signatures-and-legal-effect" author: "Sorena AI" description: "A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing." keywords: - "eIDAS electronic signature" - "advanced electronic signature AdES" - "qualified electronic signature QES" - "AdES vs QES" - "eIDAS legal effect of electronic signatures" - "remote qualified signature" - "eIDAS signature validation report" - "long term validation eIDAS" - "electronic signatures" - "qualified electronic signature" - "advanced electronic signature" - "remote signing" - "signature validation" - "legal effect" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Electronic Signatures under eIDAS A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. *Deep Guide* *EU* ## EU eIDAS Electronic Signatures Decide AdES vs QES, then build signing + validation workflows with reproducible evidence. Designed for product teams shipping signing features and compliance teams owning dispute and audit readiness. Electronic signatures are a product capability with legal impact. Under eIDAS, the choices you make (advanced vs qualified signatures, remote signing, validation policy, long-term preservation) determine how defensible your signatures are in disputes and audits. This guide focuses on operational reality: how to implement signing ceremonies, validation pipelines, and evidence retention so outcomes are reproducible and interoperable. ## AdES vs QES (decision framework) Start with risk and legal requirements for your use case. Many journeys do not need QES, but some do (by law, policy, or business risk). Treat the choice as an architecture decision with acceptance criteria and evidence requirements. - Risk and regulatory requirement: what level is required (or expected) for enforceability and cross-border use? - User experience: how strong authentication and signing ceremony affect conversion and support costs. - Evidence and disputes: what you must prove later (identity binding, intent, integrity, timestamping). ## Signing ceremony design (what to implement, not just what to say) Signing disputes often come down to ceremony design: was the user authenticated, did they see what they signed, and can you prove it? Build the ceremony as a measurable workflow with logs and replayable evidence. - Authentication + intent: record what authentication was used and capture explicit intent signals. - Document integrity: canonicalize what is signed (hashes, rendering, and versioning). - Time semantics: ensure timestamps are consistent and explainable across systems and time zones. - Non-repudiation evidence: logs, validation reports, and evidence records for later disputes. ## Remote/cloud signing (what makes it hard) Remote signing can improve UX but increases reliance on external services, device binding, and identity proofing. Treat it as a vendor + architecture decision with explicit SLA, incident, and evidence outputs. - Vendor governance: ensure QTSP and remote signing services provide the audit evidence you need. - Key protection: understand where keys live and how signing authorization is enforced. - Failure handling: define how to handle provider outages without silent downgrades. ## Validation pipeline (how to make decisions defensible) Validation is not "check the signature once". It's a policy-driven decision system that must produce reproducible reports. Build a deterministic pipeline with explicit reason codes and versioned policies. - Certificate chain validation and trust anchor integration (trusted lists). - Revocation/status handling with safe failure modes and monitored dependencies. - Machine-readable validation reports plus human-readable summaries for disputes. - Long-term validation strategy: evidence records and preservation decisions. ## Implementation playbook (fast path) Avoid bespoke crypto. Use standards-aligned libraries and tooling that can produce the reports you need. The Commission's DSS project is a common reference for signature creation and validation workflows. - Pick supported formats and freeze a "supported matrix" per product journey. - Build a stable test suite: known-good and known-bad samples that must remain stable across releases. - Instrument everything: decision logs, reports, monitoring, and incident procedures. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU eIDAS Electronic Signatures as a cited research workflow Research Copilot can take EU eIDAS Electronic Signatures from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU eIDAS Electronic Signatures](/solutions/research-copilot.md): Start from EU eIDAS Electronic Signatures and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Electronic Signatures. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Defines electronic signatures (advanced and qualified) and legal effect framework. - [European Commission - Digital Signature Service (DSS) (Digital Building Blocks)](https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467109107/Digital+Signature+Service+-+DSS?ref=sorena.io) - Technical documentation and reference implementation guidance for signature creation and validation. - [ETSI press release - Cloud-based digital signature specifications](https://www.etsi.org/newsroom/press-releases/1573-2019-04-etsi-releases-three-specifications-for-cloud-based-digital-signatures?ref=sorena.io) - ETSI context on cloud-based/remote signature specifications. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/electronic-signatures-and-legal-effect --- --- title: "EUDI Wallet Readiness (eIDAS 2.0)" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/eudi-wallet-readiness" source_url: "https://www.sorena.io/artifacts/eu/eidas/eudi-wallet-readiness" author: "Sorena AI" description: "A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows." keywords: - "EUDI Wallet readiness" - "eIDAS 2.0 EUDI Wallet compliance" - "relying party EUDI Wallet" - "accept EUDI Wallet 36 months" - "EU Digital Identity Wallet integration" - "EUDI Wallet relying party obligations" - "electronic attestation of attributes EUDI" - "EUDI Wallet trust mark" - "eIDAS 2.0" - "relying party acceptance" - "electronic attestation of attributes" - "wallet trust mark" - "privacy by design" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EUDI Wallet Readiness (eIDAS 2.0) A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. *Readiness Guide* *EU* ## EU eIDAS EUDI Wallet Readiness Plan acceptance, integration, and evidence so the wallet becomes a product capability, not a compliance scramble. Covers relying parties, wallet providers, and identity/attribute flows under eIDAS as amended by Regulation (EU) 2024/1183. EUDI Wallet readiness is a combined compliance, architecture, and product problem. You need a relying-party acceptance strategy, wallet-compatible identity and attribute flows, and proof that your implementation respects privacy by design and user transparency. The fastest route is to build a single wallet capability backed by a traceable evidence pack: requirements, architecture decisions, tests, operational monitoring, and audit-ready outputs. ## What changed with eIDAS 2.0 (EUDI Wallet reality check) Regulation (EU) 2024/1183 amends eIDAS and introduces European Digital Identity Wallets with defined ecosystem roles for Member States, wallet providers, issuers, and relying parties. This is not just another login option. The Commission adopted five wallet implementing regulations in late 2024, and Member States must provide at least one wallet by the end of 2026. - Relying parties that are legally obliged to identify customers need a concrete wallet acceptance and verifier plan. - The wallet introduces electronic attestations of attributes, both qualified and non-qualified, and a user-centric disclosure model. - The wallet framework emphasizes transparency: users can access transaction logs and should be able to understand what data was shared and why. ## Relying party readiness (acceptance + UX + compliance) Relying parties should treat the wallet as a first-class channel because it affects UX, risk decisions, privacy handling, and data minimization. Build a clear product policy that says when the wallet is offered, what alternative flows exist, and how you prevent shadow data collection around wallet use. - Acceptance strategy: define which journeys will support wallet-based authentication and attribute presentation first, such as onboarding, account recovery, and high-risk actions. - Registration and trust setup: understand whether your relying-party role triggers registration, notification, or trust-list dependencies under wallet implementing acts. - Data minimization: request the minimum data needed and prove that you do not collect or combine wallet usage data beyond necessity. - User transparency: build UI patterns that explain what is requested and why, and preserve logs of disclosures and consent decisions. - Operational readiness: incident handling, rollback plan, and monitoring coverage for wallet flows. ## Attribute flows (electronic attestations of attributes) - what to design EUDI Wallet introduces stronger attribute ecosystems: users can receive and present attestations in a secured way, with user-controlled disclosure. Design attribute handling as an explicit schema + policy system so it is testable and auditable. - Attribute schema governance: define accepted attributes, validation rules, source expectations, and retention limits. - Disclosure policies: ensure the user understands what is shared, record decisions, and enforce least privilege at the API boundary. - Verification pipeline: verify authenticity and validity of the wallet and presented attestations, log outcomes, and preserve enough evidence for troubleshooting and audits. - Fallback and equivalence: define alternative methods for users who do not use the wallet because wallet use remains voluntary. ## Security-by-design (make it measurable) Wallet ecosystems depend on strong security assurances: integrity of flows, authenticity of credentials, and robust revocation/suspension behavior. Build security controls you can prove with tests, logs, and change control. - Threat modeling: focus on account takeover, credential replay, phishing, injection into relying party redirect flows, and attribute forgery. - Key management and crypto agility: choose cryptographic suites aligned with the ecosystem reference guidance and standards. - Revocation and suspension: implement revocation checks and ensure your relying party systems can handle revoked wallets/credentials safely. - Audit logging: store wallet interaction logs with tamper resistance and clear retention rules. ## Testing strategy (how to de-risk integration quickly) Wallet readiness fails when teams only run happy-path demos. Test the hard cases: expired attestations, partial disclosures, revocations, and degraded network conditions. Use a staged testing plan: contract tests -> end-to-end -> resilience drills -> privacy regression. - Interoperability tests: multi-wallet and multi-issuer scenarios aligned to the ARF and the wallet implementing regulations. - Negative testing: invalid signatures, mismatched audience, clock skew, replay attempts, revoked attestations, and consent bypass attempts. - Privacy tests: ensure logs do not leak sensitive attribute values and that retention or deletion workflows work. - Release gates: define a wallet readiness quality bar with measurable acceptance criteria and supervisory-response evidence. ## Evidence pack (what to prepare for audits and due diligence) Prepare an evidence pack that explains your design choices and proves operation: architecture, controls, and tests. Your goal is to answer: "What data do you request, why, how do you validate it, and how do you protect users?" - Architecture decision record: wallet flow diagrams, data schema, verification pipeline, and trust model assumptions. - Privacy and security controls: data minimization policy, retention/deletion rules, logging model, and DPIA-style risk analysis where applicable. - Test evidence: interoperability results, negative test suites, revocation/suspension handling tests, monitoring dashboards. - Operational procedures: incident response runbook for wallet incidents and change management for credential/issuer updates. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU eIDAS EUDI Wallet Readiness in one governed evidence system SSOT can take EU eIDAS EUDI Wallet Readiness from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU eIDAS EUDI Wallet Readiness](/solutions/ssot.md): Start from EU eIDAS EUDI Wallet Readiness and keep documents, evidence, and control records in one governed system. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS EUDI Wallet Readiness. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Consolidated eIDAS text showing relying-party concepts, wallet-related provisions, and the amended trust-service perimeter. - [Regulation (EU) 2024/1183 - eIDAS 2.0 (EUDI Wallet) amendment](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amending regulation that established the EUDI Wallet framework and the end-2026 Member State rollout target. - [European Commission - EUDI Regulation overview](https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation?ref=sorena.io) - Commission overview explaining that Member States must offer wallets by the end of 2026 and that service providers legally obliged to identify customers must accept the wallet for authentication. - [European Commission - EUDI Wallet Architecture and Reference Framework (ARF)](https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-wallet-architecture-and-reference-framework?ref=sorena.io) - Architecture and reference framework used to drive interoperable wallet solutions. - [European Commission - Implementing regulation for European Digital Identity Wallets](https://digital-strategy.ec.europa.eu/en/library/implementing-regulation-european-digital-identity-wallets?ref=sorena.io) - Commission page describing the five wallet implementing regulations adopted in late 2024. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/eudi-wallet-readiness --- --- title: "EUDI Wallet Readiness (eIDAS 2.0)" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/eudi-wallet-readiness" source_url: "https://www.sorena.io/artifacts/eu/eidas/eudi-wallet-readiness" author: "Sorena AI" description: "A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows." keywords: - "EUDI Wallet readiness" - "eIDAS 2.0 EUDI Wallet compliance" - "relying party EUDI Wallet" - "accept EUDI Wallet 36 months" - "EU Digital Identity Wallet integration" - "EUDI Wallet relying party obligations" - "electronic attestation of attributes EUDI" - "EUDI Wallet trust mark" - "eIDAS 2.0" - "relying party acceptance" - "electronic attestation of attributes" - "wallet trust mark" - "privacy by design" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EUDI Wallet Readiness (eIDAS 2.0) A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. *Readiness Guide* *EU* ## EU eIDAS EUDI Wallet Readiness Plan acceptance, integration, and evidence so the wallet becomes a product capability, not a compliance scramble. Covers relying parties, wallet providers, and identity/attribute flows under eIDAS as amended by Regulation (EU) 2024/1183. EUDI Wallet readiness is a combined compliance, architecture, and product problem. You need a relying-party acceptance strategy, wallet-compatible identity and attribute flows, and proof that your implementation respects privacy by design and user transparency. The fastest route is to build a single wallet capability backed by a traceable evidence pack: requirements, architecture decisions, tests, operational monitoring, and audit-ready outputs. ## What changed with eIDAS 2.0 (EUDI Wallet reality check) Regulation (EU) 2024/1183 amends eIDAS and introduces European Digital Identity Wallets with defined ecosystem roles for Member States, wallet providers, issuers, and relying parties. This is not just another login option. The Commission adopted five wallet implementing regulations in late 2024, and Member States must provide at least one wallet by the end of 2026. - Relying parties that are legally obliged to identify customers need a concrete wallet acceptance and verifier plan. - The wallet introduces electronic attestations of attributes, both qualified and non-qualified, and a user-centric disclosure model. - The wallet framework emphasizes transparency: users can access transaction logs and should be able to understand what data was shared and why. ## Relying party readiness (acceptance + UX + compliance) Relying parties should treat the wallet as a first-class channel because it affects UX, risk decisions, privacy handling, and data minimization. Build a clear product policy that says when the wallet is offered, what alternative flows exist, and how you prevent shadow data collection around wallet use. - Acceptance strategy: define which journeys will support wallet-based authentication and attribute presentation first, such as onboarding, account recovery, and high-risk actions. - Registration and trust setup: understand whether your relying-party role triggers registration, notification, or trust-list dependencies under wallet implementing acts. - Data minimization: request the minimum data needed and prove that you do not collect or combine wallet usage data beyond necessity. - User transparency: build UI patterns that explain what is requested and why, and preserve logs of disclosures and consent decisions. - Operational readiness: incident handling, rollback plan, and monitoring coverage for wallet flows. ## Attribute flows (electronic attestations of attributes) - what to design EUDI Wallet introduces stronger attribute ecosystems: users can receive and present attestations in a secured way, with user-controlled disclosure. Design attribute handling as an explicit schema + policy system so it is testable and auditable. - Attribute schema governance: define accepted attributes, validation rules, source expectations, and retention limits. - Disclosure policies: ensure the user understands what is shared, record decisions, and enforce least privilege at the API boundary. - Verification pipeline: verify authenticity and validity of the wallet and presented attestations, log outcomes, and preserve enough evidence for troubleshooting and audits. - Fallback and equivalence: define alternative methods for users who do not use the wallet because wallet use remains voluntary. ## Security-by-design (make it measurable) Wallet ecosystems depend on strong security assurances: integrity of flows, authenticity of credentials, and robust revocation/suspension behavior. Build security controls you can prove with tests, logs, and change control. - Threat modeling: focus on account takeover, credential replay, phishing, injection into relying party redirect flows, and attribute forgery. - Key management and crypto agility: choose cryptographic suites aligned with the ecosystem reference guidance and standards. - Revocation and suspension: implement revocation checks and ensure your relying party systems can handle revoked wallets/credentials safely. - Audit logging: store wallet interaction logs with tamper resistance and clear retention rules. ## Testing strategy (how to de-risk integration quickly) Wallet readiness fails when teams only run happy-path demos. Test the hard cases: expired attestations, partial disclosures, revocations, and degraded network conditions. Use a staged testing plan: contract tests -> end-to-end -> resilience drills -> privacy regression. - Interoperability tests: multi-wallet and multi-issuer scenarios aligned to the ARF and the wallet implementing regulations. - Negative testing: invalid signatures, mismatched audience, clock skew, replay attempts, revoked attestations, and consent bypass attempts. - Privacy tests: ensure logs do not leak sensitive attribute values and that retention or deletion workflows work. - Release gates: define a wallet readiness quality bar with measurable acceptance criteria and supervisory-response evidence. ## Evidence pack (what to prepare for audits and due diligence) Prepare an evidence pack that explains your design choices and proves operation: architecture, controls, and tests. Your goal is to answer: "What data do you request, why, how do you validate it, and how do you protect users?" - Architecture decision record: wallet flow diagrams, data schema, verification pipeline, and trust model assumptions. - Privacy and security controls: data minimization policy, retention/deletion rules, logging model, and DPIA-style risk analysis where applicable. - Test evidence: interoperability results, negative test suites, revocation/suspension handling tests, monitoring dashboards. - Operational procedures: incident response runbook for wallet incidents and change management for credential/issuer updates. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU eIDAS EUDI Wallet Readiness in one governed evidence system SSOT can take EU eIDAS EUDI Wallet Readiness from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU eIDAS EUDI Wallet Readiness](/solutions/ssot.md): Start from EU eIDAS EUDI Wallet Readiness and keep documents, evidence, and control records in one governed system. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS EUDI Wallet Readiness. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Consolidated eIDAS text showing relying-party concepts, wallet-related provisions, and the amended trust-service perimeter. - [Regulation (EU) 2024/1183 - eIDAS 2.0 (EUDI Wallet) amendment](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amending regulation that established the EUDI Wallet framework and the end-2026 Member State rollout target. - [European Commission - EUDI Regulation overview](https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation?ref=sorena.io) - Commission overview explaining that Member States must offer wallets by the end of 2026 and that service providers legally obliged to identify customers must accept the wallet for authentication. - [European Commission - EUDI Wallet Architecture and Reference Framework (ARF)](https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-wallet-architecture-and-reference-framework?ref=sorena.io) - Architecture and reference framework used to drive interoperable wallet solutions. - [European Commission - Implementing regulation for European Digital Identity Wallets](https://digital-strategy.ec.europa.eu/en/library/implementing-regulation-european-digital-identity-wallets?ref=sorena.io) - Commission page describing the five wallet implementing regulations adopted in late 2024. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/eudi-wallet-readiness --- --- title: "EUDI Wallet Technical Architecture Guide" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide" source_url: "https://www.sorena.io/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide" author: "Sorena AI" description: "A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows." keywords: - "EUDI wallet technical architecture" - "EUDI wallet ARF" - "EUDI wallet relying party integration" - "EUDI wallet verifier architecture" - "electronic attestation of attributes architecture" - "EUDI wallet transaction log dashboard" - "EUDI wallet interoperability guide" - "EUDI wallet architecture" - "ARF" - "relying party verification" - "electronic attestations of attributes" - "wallet logs and transparency" - "interoperability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EUDI Wallet Technical Architecture Guide A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. *Architecture Guide* *EU* ## EU eIDAS EUDI Wallet Architecture Turn the ARF and wallet implementing regulations into implementable components, flows, boundaries, keys, logs, and testable controls. Designed for relying parties, wallet providers, and teams building verifiers and attribute pipelines. The EUDI Wallet is an ecosystem: wallet software on user devices, issuance of person-identification data and attributes, verification by relying parties, and shared trust infrastructure. A working architecture must be secure, privacy-preserving, interoperable, and operationally supportable. Use this page as a technical blueprint that maps the amended eIDAS text, the ARF, and the five wallet implementing regulations into components, data flows, trust anchors, and prove-it-works controls. ## Ecosystem actors (architectural boundaries you must model) Start by identifying actors and responsibilities. Most architecture failures come from fuzzy ownership across product, identity, and compliance teams. eIDAS defines roles including relying parties and providers of European Digital Identity Wallets, and introduces wallet-specific obligations and capabilities. - Wallet provider: delivers and operates the wallet solution and its security lifecycle, including updates, revocation or suspension, and incident handling. - Issuers: issue person-identification data and electronic attestations of attributes, whether qualified or non-qualified. - Relying parties or verifiers: request and verify wallet-based claims and enforce data minimization, logging, and user transparency. - Conformity assessment and supervision: certification, notification, and oversight expectations influence your evidence model and release process. ## Core functional flows (the minimum set you should implement) Architect the wallet capability around a small set of canonical flows, then enforce consistency and testability across products and channels. The implementing regulations adopted in late 2024 define the common technical floor for core functionalities, interfaces, PID and attributes, certification, and ecosystem notifications. - Authentication flow: wallet-based authentication to relying parties with strong integrity and replay protections. - Attribute presentation flow: user shares electronic attestations of attributes with explicit disclosure and only the data necessary for the transaction. - Wallet-to-wallet or delegated verification patterns: only where the use case requires it and where trust boundaries are explicit. - User transparency flow: user accesses a log of wallet transactions or disclosures through a common dashboard for accountability and dispute handling. ## Trust model: keys, trust anchors, and verification pipeline Interoperability is a trust problem. Define how relying parties validate authenticity, integrity, and validity of wallets and presented claims. Implement verification as a deterministic pipeline with explicit decisions and logs (pass/fail/retry, reason codes). - Trust anchors: define authoritative sources for issuer keys, wallet authenticity, and certification status. - Signature verification: validate signatures on presented attestations and wallet assertions and handle algorithm agility and versioning. - Revocation and status: implement status checks and safe failure modes when status information is unavailable. - Decision logging: store verification outcomes, versions, and trust decisions without retaining unnecessary attribute values. ## Privacy-by-design architecture (what to enforce at system boundaries) Wallet ecosystems can accidentally create "surveillance by design" if you collect and link wallet usage data across services. Build privacy controls into your data plane: schemas, retention rules, and logging policies are architecture decisions. - Data minimization: enforce minimal-attribute requests and block expansions without explicit justification. - Separation of concerns: keep wallet usage telemetry logically separate from other business analytics unless the user explicitly consents and it's necessary. - Selective disclosure patterns: design APIs to request only what is necessary and to avoid "full credential disclosure" defaults. - Deletion and retention: implement deletion workflows and prove they work with tests and periodic audits. ## Security controls (make them testable) A wallet verifier is a high-value target. Implement hard controls and prove them with tests and monitoring. Your goal is not just security posture - it's demonstrable, repeatable resilience. - Threat model focus: phishing, credential replay, issuer compromise, verifier endpoint abuse, and downgrade attacks. - Secure update process: handle issuer key rotations and spec changes without breaking verification determinism. - Strong audit logging: tamper resistance, clear retention rules, and access controls aligned to least privilege. - Operational monitoring: error budgets for verification failures, revocation check outages, and unusual claim patterns. ## Interoperability and conformance strategy (how to avoid "demo-only" integrations) Wallet ecosystems only work when implementations interoperate across Member States and vendors. Treat interoperability as a continuous program with contract tests and conformance gates. Use the ARF, the Commission implementing regulations, and your supported issuer or wallet matrix as the backbone for shared assumptions. - Canonical test suite: cover multi-issuer scenarios, multiple wallets, revoked or expired credentials, and partial disclosure edge cases. - Spec version management: version your verifier logic and record which ARF or implementing-regulation assumptions each verification used. - Release gating: ship verifier changes only when interoperability tests pass across the supported set. - Evidence: keep conformance and interoperability test logs as audit-ready artifacts. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU eIDAS EUDI Wallet Architecture in one governed evidence system SSOT can take EU eIDAS EUDI Wallet Architecture from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU eIDAS EUDI Wallet Architecture](/solutions/ssot.md): Start from EU eIDAS EUDI Wallet Architecture and keep documents, evidence, and control records in one governed system. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS EUDI Wallet Architecture. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Legal framework for eID and trust services, including amended wallet-related definitions and requirements. - [Regulation (EU) 2024/1183 - eIDAS 2.0 (EUDI Wallet) amendment](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amends eIDAS and introduces EUDI Wallet obligations, including relying party acceptance concepts and wallet capabilities. - [European Commission - EUDI Wallet Architecture and Reference Framework (ARF)](https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-wallet-architecture-and-reference-framework?ref=sorena.io) - Architecture and reference framework used to drive interoperable EUDI wallet solutions. - [European Commission - Implementing regulation for EUDI wallets (library overview)](https://digital-strategy.ec.europa.eu/en/library/implementing-regulation-european-digital-identity-wallets?ref=sorena.io) - Commission page summarizing the five wallet implementing regulations for core functionalities, interfaces, PID and attributes, certification, and ecosystem notifications. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide --- --- title: "EUDI Wallet Technical Architecture Guide" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide" source_url: "https://www.sorena.io/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide" author: "Sorena AI" description: "A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows." keywords: - "EUDI wallet technical architecture" - "EUDI wallet ARF" - "EUDI wallet relying party integration" - "EUDI wallet verifier architecture" - "electronic attestation of attributes architecture" - "EUDI wallet transaction log dashboard" - "EUDI wallet interoperability guide" - "EUDI wallet architecture" - "ARF" - "relying party verification" - "electronic attestations of attributes" - "wallet logs and transparency" - "interoperability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EUDI Wallet Technical Architecture Guide A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. *Architecture Guide* *EU* ## EU eIDAS EUDI Wallet Architecture Turn the ARF and wallet implementing regulations into implementable components, flows, boundaries, keys, logs, and testable controls. Designed for relying parties, wallet providers, and teams building verifiers and attribute pipelines. The EUDI Wallet is an ecosystem: wallet software on user devices, issuance of person-identification data and attributes, verification by relying parties, and shared trust infrastructure. A working architecture must be secure, privacy-preserving, interoperable, and operationally supportable. Use this page as a technical blueprint that maps the amended eIDAS text, the ARF, and the five wallet implementing regulations into components, data flows, trust anchors, and prove-it-works controls. ## Ecosystem actors (architectural boundaries you must model) Start by identifying actors and responsibilities. Most architecture failures come from fuzzy ownership across product, identity, and compliance teams. eIDAS defines roles including relying parties and providers of European Digital Identity Wallets, and introduces wallet-specific obligations and capabilities. - Wallet provider: delivers and operates the wallet solution and its security lifecycle, including updates, revocation or suspension, and incident handling. - Issuers: issue person-identification data and electronic attestations of attributes, whether qualified or non-qualified. - Relying parties or verifiers: request and verify wallet-based claims and enforce data minimization, logging, and user transparency. - Conformity assessment and supervision: certification, notification, and oversight expectations influence your evidence model and release process. ## Core functional flows (the minimum set you should implement) Architect the wallet capability around a small set of canonical flows, then enforce consistency and testability across products and channels. The implementing regulations adopted in late 2024 define the common technical floor for core functionalities, interfaces, PID and attributes, certification, and ecosystem notifications. - Authentication flow: wallet-based authentication to relying parties with strong integrity and replay protections. - Attribute presentation flow: user shares electronic attestations of attributes with explicit disclosure and only the data necessary for the transaction. - Wallet-to-wallet or delegated verification patterns: only where the use case requires it and where trust boundaries are explicit. - User transparency flow: user accesses a log of wallet transactions or disclosures through a common dashboard for accountability and dispute handling. ## Trust model: keys, trust anchors, and verification pipeline Interoperability is a trust problem. Define how relying parties validate authenticity, integrity, and validity of wallets and presented claims. Implement verification as a deterministic pipeline with explicit decisions and logs (pass/fail/retry, reason codes). - Trust anchors: define authoritative sources for issuer keys, wallet authenticity, and certification status. - Signature verification: validate signatures on presented attestations and wallet assertions and handle algorithm agility and versioning. - Revocation and status: implement status checks and safe failure modes when status information is unavailable. - Decision logging: store verification outcomes, versions, and trust decisions without retaining unnecessary attribute values. ## Privacy-by-design architecture (what to enforce at system boundaries) Wallet ecosystems can accidentally create "surveillance by design" if you collect and link wallet usage data across services. Build privacy controls into your data plane: schemas, retention rules, and logging policies are architecture decisions. - Data minimization: enforce minimal-attribute requests and block expansions without explicit justification. - Separation of concerns: keep wallet usage telemetry logically separate from other business analytics unless the user explicitly consents and it's necessary. - Selective disclosure patterns: design APIs to request only what is necessary and to avoid "full credential disclosure" defaults. - Deletion and retention: implement deletion workflows and prove they work with tests and periodic audits. ## Security controls (make them testable) A wallet verifier is a high-value target. Implement hard controls and prove them with tests and monitoring. Your goal is not just security posture - it's demonstrable, repeatable resilience. - Threat model focus: phishing, credential replay, issuer compromise, verifier endpoint abuse, and downgrade attacks. - Secure update process: handle issuer key rotations and spec changes without breaking verification determinism. - Strong audit logging: tamper resistance, clear retention rules, and access controls aligned to least privilege. - Operational monitoring: error budgets for verification failures, revocation check outages, and unusual claim patterns. ## Interoperability and conformance strategy (how to avoid "demo-only" integrations) Wallet ecosystems only work when implementations interoperate across Member States and vendors. Treat interoperability as a continuous program with contract tests and conformance gates. Use the ARF, the Commission implementing regulations, and your supported issuer or wallet matrix as the backbone for shared assumptions. - Canonical test suite: cover multi-issuer scenarios, multiple wallets, revoked or expired credentials, and partial disclosure edge cases. - Spec version management: version your verifier logic and record which ARF or implementing-regulation assumptions each verification used. - Release gating: ship verifier changes only when interoperability tests pass across the supported set. - Evidence: keep conformance and interoperability test logs as audit-ready artifacts. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU eIDAS EUDI Wallet Architecture in one governed evidence system SSOT can take EU eIDAS EUDI Wallet Architecture from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU eIDAS EUDI Wallet Architecture](/solutions/ssot.md): Start from EU eIDAS EUDI Wallet Architecture and keep documents, evidence, and control records in one governed system. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS EUDI Wallet Architecture. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Legal framework for eID and trust services, including amended wallet-related definitions and requirements. - [Regulation (EU) 2024/1183 - eIDAS 2.0 (EUDI Wallet) amendment](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amends eIDAS and introduces EUDI Wallet obligations, including relying party acceptance concepts and wallet capabilities. - [European Commission - EUDI Wallet Architecture and Reference Framework (ARF)](https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-wallet-architecture-and-reference-framework?ref=sorena.io) - Architecture and reference framework used to drive interoperable EUDI wallet solutions. - [European Commission - Implementing regulation for EUDI wallets (library overview)](https://digital-strategy.ec.europa.eu/en/library/implementing-regulation-european-digital-identity-wallets?ref=sorena.io) - Commission page summarizing the five wallet implementing regulations for core functionalities, interfaces, PID and attributes, certification, and ecosystem notifications. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide --- --- title: "eIDAS FAQ (EU)" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/faq" source_url: "https://www.sorena.io/artifacts/eu/eidas/faq" author: "Sorena AI" description: "High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain." keywords: - "eIDAS FAQ" - "what is eIDAS" - "AdES vs QES" - "qualified electronic signature explained" - "QTSP meaning" - "how to choose a QTSP" - "eIDAS signature validation" - "EUDI wallet readiness" - "eIDAS deadlines" - "qualified electronic signature" - "QTSP" - "trust services" - "EUDI wallet" - "eIDAS evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS FAQ (EU) High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. *FAQ* *EU* ## EU eIDAS FAQ Clear answers to common eIDAS questions with practical next steps. Use this page to choose the right subpage for deep implementation guidance. This FAQ is built for implementation teams. Answers focus on what to do next: what to build, what to decide, what to test, and what evidence to retain. For formal interpretation, validate against the primary legal texts, implementing acts, and competent-authority guidance. ## What does eIDAS cover? eIDAS establishes the EU framework for electronic identification and trust services for electronic transactions in the internal market. After the 2024 amendment, that now includes not only signatures, seals, timestamps, delivery services, and website authentication, but also electronic archiving, electronic attestations of attributes, electronic ledgers, and the EUDI Wallet framework. - Start with /artifacts/eu/eidas/what-eidas-covers for the role map and expanded scope. - If you sign or validate, use the electronic signatures guide and certificate validation blueprint. ## Do we need a qualified electronic signature (QES)? The right level depends on legal requirements and risk. Many use cases can use advanced electronic signatures, but some require (or strongly benefit from) qualified signatures. The operational difference is mostly evidence and ecosystem: qualified services often imply QTSP dependencies and stricter supervision posture. - Decide by journey: onboarding vs high-risk contract signing vs internal approvals. - Treat the decision as an architecture decision with explicit acceptance criteria and evidence requirements. ## How do we select a QTSP? QTSP selection should be evidence-first: qualification proof, security controls, supervision evidence, interoperability tests, and exit readiness. Avoid "marketing qualification" and verify scope for the exact service you plan to use. - Use the QTSP selection guide for due-diligence questions, trust-list checks, and evidence request lists. - Check whether the provider must evidence updated Article 24 identity-proofing conformity by 21 May 2026 if it was qualified before 20 May 2024. ## What evidence do auditors and supervisors ask for first? Most audits start with operational proof: validation reports, decision logs, revocation/status handling, and vendor evidence for qualified services. Build an evidence index: requirements -> controls -> tests -> living artifacts. - Relying party: deterministic validation pipeline + logs + negative test results. - Vendor program: QTSP audit reports/conformity evidence + incident procedures + exit plan. - Wallet readiness: verifier logs + attribute governance + interoperability test evidence. ## What is EUDI Wallet readiness in practice? EUDI Wallet readiness means building wallet-compatible authentication and attribute-verification flows, with privacy-by-design and user-transparency controls. It also means planning against the real timeline: late-2024 wallet implementing regulations, current ARF assumptions, and Member State wallet availability by the end of 2026. - Start with the wallet readiness page, then use the technical architecture guide for component planning. - Prioritize interoperability, negative testing, and evidence design early to avoid late-stage integration failures. *Recommended next step* *Placement: after the FAQ section* ## Use EU eIDAS FAQ as a cited research workflow Research Copilot can take EU eIDAS FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU eIDAS FAQ](/solutions/research-copilot.md): Start from EU eIDAS FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS FAQ. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Primary legal text for eIDAS trust services and electronic identification. - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amends eIDAS to introduce the EUDI wallet framework. - [ENISA - Security framework for trust service providers](https://www.enisa.europa.eu/publications/tsp-security?ref=sorena.io) - Security guidance supporting practical implementation and evidence design for trust services. - [European Commission - Implementing regulation for European Digital Identity Wallets](https://digital-strategy.ec.europa.eu/en/library/implementing-regulation-european-digital-identity-wallets?ref=sorena.io) - Commission page describing the five wallet implementing regulations adopted in late 2024. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/faq --- --- title: "eIDAS FAQ (EU)" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/faq" source_url: "https://www.sorena.io/artifacts/eu/eidas/faq" author: "Sorena AI" description: "High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain." keywords: - "eIDAS FAQ" - "what is eIDAS" - "AdES vs QES" - "qualified electronic signature explained" - "QTSP meaning" - "how to choose a QTSP" - "eIDAS signature validation" - "EUDI wallet readiness" - "eIDAS deadlines" - "qualified electronic signature" - "QTSP" - "trust services" - "EUDI wallet" - "eIDAS evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS FAQ (EU) High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. *FAQ* *EU* ## EU eIDAS FAQ Clear answers to common eIDAS questions with practical next steps. Use this page to choose the right subpage for deep implementation guidance. This FAQ is built for implementation teams. Answers focus on what to do next: what to build, what to decide, what to test, and what evidence to retain. For formal interpretation, validate against the primary legal texts, implementing acts, and competent-authority guidance. ## What does eIDAS cover? eIDAS establishes the EU framework for electronic identification and trust services for electronic transactions in the internal market. After the 2024 amendment, that now includes not only signatures, seals, timestamps, delivery services, and website authentication, but also electronic archiving, electronic attestations of attributes, electronic ledgers, and the EUDI Wallet framework. - Start with /artifacts/eu/eidas/what-eidas-covers for the role map and expanded scope. - If you sign or validate, use the electronic signatures guide and certificate validation blueprint. ## Do we need a qualified electronic signature (QES)? The right level depends on legal requirements and risk. Many use cases can use advanced electronic signatures, but some require (or strongly benefit from) qualified signatures. The operational difference is mostly evidence and ecosystem: qualified services often imply QTSP dependencies and stricter supervision posture. - Decide by journey: onboarding vs high-risk contract signing vs internal approvals. - Treat the decision as an architecture decision with explicit acceptance criteria and evidence requirements. ## How do we select a QTSP? QTSP selection should be evidence-first: qualification proof, security controls, supervision evidence, interoperability tests, and exit readiness. Avoid "marketing qualification" and verify scope for the exact service you plan to use. - Use the QTSP selection guide for due-diligence questions, trust-list checks, and evidence request lists. - Check whether the provider must evidence updated Article 24 identity-proofing conformity by 21 May 2026 if it was qualified before 20 May 2024. ## What evidence do auditors and supervisors ask for first? Most audits start with operational proof: validation reports, decision logs, revocation/status handling, and vendor evidence for qualified services. Build an evidence index: requirements -> controls -> tests -> living artifacts. - Relying party: deterministic validation pipeline + logs + negative test results. - Vendor program: QTSP audit reports/conformity evidence + incident procedures + exit plan. - Wallet readiness: verifier logs + attribute governance + interoperability test evidence. ## What is EUDI Wallet readiness in practice? EUDI Wallet readiness means building wallet-compatible authentication and attribute-verification flows, with privacy-by-design and user-transparency controls. It also means planning against the real timeline: late-2024 wallet implementing regulations, current ARF assumptions, and Member State wallet availability by the end of 2026. - Start with the wallet readiness page, then use the technical architecture guide for component planning. - Prioritize interoperability, negative testing, and evidence design early to avoid late-stage integration failures. *Recommended next step* *Placement: after the FAQ section* ## Use EU eIDAS FAQ as a cited research workflow Research Copilot can take EU eIDAS FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU eIDAS FAQ](/solutions/research-copilot.md): Start from EU eIDAS FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS FAQ. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Primary legal text for eIDAS trust services and electronic identification. - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amends eIDAS to introduce the EUDI wallet framework. - [ENISA - Security framework for trust service providers](https://www.enisa.europa.eu/publications/tsp-security?ref=sorena.io) - Security guidance supporting practical implementation and evidence design for trust services. - [European Commission - Implementing regulation for European Digital Identity Wallets](https://digital-strategy.ec.europa.eu/en/library/implementing-regulation-european-digital-identity-wallets?ref=sorena.io) - Commission page describing the five wallet implementing regulations adopted in late 2024. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/faq --- --- title: "eIDAS Penalties, Liability, and Enforcement" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/eidas/penalties-and-fines" author: "Sorena AI" description: "A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services." keywords: - "eIDAS penalties" - "eIDAS enforcement" - "QTSP supervision" - "eIDAS liability" - "trust service provider liability" - "eIDAS audit" - "eIDAS compliance risk" - "liability" - "supervision" - "QTSP audits" - "risk reduction" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS Penalties, Liability, and Enforcement A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. *Enforcement Guide* *EU* ## EU eIDAS Penalties & Liability Reduce enforcement and dispute risk by building supervision-ready evidence and operations. Focus: audits, supervision, operational proof, and vendor governance. eIDAS risk is rarely about "getting fined out of nowhere". It's usually about being unable to prove what happened: a disputed signature, a certificate status failure, a provider incident, or missing audit evidence. For qualified trust services, supervision and audits are central, and liability can arise from failures to comply. Use this page to design an enforcement-resilient program: evidence-first controls, audit readiness, and vendor governance that reduces both regulatory and commercial risk. ## Where enforcement risk comes from (real-world) Enforcement risk is a combination of regulatory scrutiny (especially for qualified trust services) and commercial dispute risk (contracts, onboarding, high-risk actions). Most escalations start with operational failures: revocation checks, ambiguous validation outcomes, missing logs, or incident response gaps. - Validation failures: inconsistent outcomes or missing reason codes and report artifacts. - Status/revocation outages: fragile dependencies without monitoring and defined fallback behavior. - Vendor evidence gaps: QTSP can't provide current audit/conformity evidence or incident details. - Retention failures: you can't produce evidence months/years later. *Recommended next step* *Placement: after the enforcement section* ## Use EU eIDAS Penalties & Liability as a cited research workflow Research Copilot can take EU eIDAS Penalties & Liability from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU eIDAS Penalties & Liability](/solutions/research-copilot.md): Start from EU eIDAS Penalties & Liability and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Penalties & Liability. ## Supervision and audits (what to be ready for) Qualified trust services operate in a supervision ecosystem. Audit readiness requires both design evidence and operational evidence. Use supervision guidance to anticipate what evidence and operating procedures will be requested. - Audit pack: policies, process evidence, test results, and operational logs tied to specific services. - Change management: demonstrate control over changes to signing/validation logic and certificate infrastructure. - Incident handling: show notification and RCA practices and how controls were improved post-incident. - Cost and scope awareness: plan the audit evidence collection lifecycle so it is not a yearly scramble. ## Liability posture (how to reduce damages and dispute exposure) Liability risk is largely mitigated by clarity and evidence. If you can prove correct operation and decision-making, disputes are cheaper and outcomes are more defensible. Treat your evidence index and validation reports as legal risk controls. - Signing ceremony evidence: intent, authentication, and document integrity proofs. - Validation decision evidence: chain/status checks, policy versions, and reason codes. - Vendor evidence: QTSP audit reports, incident reports, and service scope proofs. - Retention strategy: testable retention/deletion rules and evidence export capability. ## Risk reduction checklist (do these first) These actions reduce both regulatory and commercial risk quickly. They also improve customer support outcomes and reduce incident impact. - Build deterministic validation reports + decision logs (machine-readable + human-readable). - Implement monitored revocation/status handling with documented outage behavior. - Create a QTSP vendor binder with annual refresh and incident-driven updates. - Maintain an evidence index (requirements -> controls -> tests -> artifacts) with owners and review cadence. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Primary eIDAS framework for trust services, supervision concepts, and liability provisions. - [ENISA - Guidelines on supervision of qualified trust service providers](https://www.enisa.europa.eu/publications/tsp-supervision?ref=sorena.io) - Guidance for supervision practices and evidence expectations for qualified trust service providers. - [ENISA - Security framework for trust service providers](https://www.enisa.europa.eu/publications/tsp-security?ref=sorena.io) - Security control guidance supporting implementation and audit readiness. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/penalties-and-fines --- --- title: "eIDAS Penalties, Liability, and Enforcement" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/eidas/penalties-and-fines" author: "Sorena AI" description: "A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services." keywords: - "eIDAS penalties" - "eIDAS enforcement" - "QTSP supervision" - "eIDAS liability" - "trust service provider liability" - "eIDAS audit" - "eIDAS compliance risk" - "liability" - "supervision" - "QTSP audits" - "risk reduction" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS Penalties, Liability, and Enforcement A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. *Enforcement Guide* *EU* ## EU eIDAS Penalties & Liability Reduce enforcement and dispute risk by building supervision-ready evidence and operations. Focus: audits, supervision, operational proof, and vendor governance. eIDAS risk is rarely about "getting fined out of nowhere". It's usually about being unable to prove what happened: a disputed signature, a certificate status failure, a provider incident, or missing audit evidence. For qualified trust services, supervision and audits are central, and liability can arise from failures to comply. Use this page to design an enforcement-resilient program: evidence-first controls, audit readiness, and vendor governance that reduces both regulatory and commercial risk. ## Where enforcement risk comes from (real-world) Enforcement risk is a combination of regulatory scrutiny (especially for qualified trust services) and commercial dispute risk (contracts, onboarding, high-risk actions). Most escalations start with operational failures: revocation checks, ambiguous validation outcomes, missing logs, or incident response gaps. - Validation failures: inconsistent outcomes or missing reason codes and report artifacts. - Status/revocation outages: fragile dependencies without monitoring and defined fallback behavior. - Vendor evidence gaps: QTSP can't provide current audit/conformity evidence or incident details. - Retention failures: you can't produce evidence months/years later. *Recommended next step* *Placement: after the enforcement section* ## Use EU eIDAS Penalties & Liability as a cited research workflow Research Copilot can take EU eIDAS Penalties & Liability from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU eIDAS Penalties & Liability](/solutions/research-copilot.md): Start from EU eIDAS Penalties & Liability and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Penalties & Liability. ## Supervision and audits (what to be ready for) Qualified trust services operate in a supervision ecosystem. Audit readiness requires both design evidence and operational evidence. Use supervision guidance to anticipate what evidence and operating procedures will be requested. - Audit pack: policies, process evidence, test results, and operational logs tied to specific services. - Change management: demonstrate control over changes to signing/validation logic and certificate infrastructure. - Incident handling: show notification and RCA practices and how controls were improved post-incident. - Cost and scope awareness: plan the audit evidence collection lifecycle so it is not a yearly scramble. ## Liability posture (how to reduce damages and dispute exposure) Liability risk is largely mitigated by clarity and evidence. If you can prove correct operation and decision-making, disputes are cheaper and outcomes are more defensible. Treat your evidence index and validation reports as legal risk controls. - Signing ceremony evidence: intent, authentication, and document integrity proofs. - Validation decision evidence: chain/status checks, policy versions, and reason codes. - Vendor evidence: QTSP audit reports, incident reports, and service scope proofs. - Retention strategy: testable retention/deletion rules and evidence export capability. ## Risk reduction checklist (do these first) These actions reduce both regulatory and commercial risk quickly. They also improve customer support outcomes and reduce incident impact. - Build deterministic validation reports + decision logs (machine-readable + human-readable). - Implement monitored revocation/status handling with documented outage behavior. - Create a QTSP vendor binder with annual refresh and incident-driven updates. - Maintain an evidence index (requirements -> controls -> tests -> artifacts) with owners and review cadence. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Primary eIDAS framework for trust services, supervision concepts, and liability provisions. - [ENISA - Guidelines on supervision of qualified trust service providers](https://www.enisa.europa.eu/publications/tsp-supervision?ref=sorena.io) - Guidance for supervision practices and evidence expectations for qualified trust service providers. - [ENISA - Security framework for trust service providers](https://www.enisa.europa.eu/publications/tsp-security?ref=sorena.io) - Security control guidance supporting implementation and audit readiness. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/penalties-and-fines --- --- title: "Qualified Trust Services and QTSP Selection" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection" source_url: "https://www.sorena.io/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection" author: "Sorena AI" description: "A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter." keywords: - "QTSP selection checklist" - "qualified trust service provider due diligence" - "eIDAS QTSP requirements" - "qualified electronic signature provider" - "qualified timestamp provider" - "qualified registered delivery provider" - "QTSP audit evidence" - "ENISA QTSP guidance" - "QTSP selection" - "qualified trust services" - "due diligence" - "ENISA guidance" - "ETSI standards" - "audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Qualified Trust Services and QTSP Selection A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. *Vendor Guide* *EU* ## EU eIDAS QTSP Selection Choose qualified trust services with evidence-first due diligence, transition awareness, and operational resilience checks. Designed for relying parties and procurement/security teams buying qualified trust services. QTSP selection is not a procurement exercise. It is a security, supervision, and evidence decision. The biggest failure mode is buying a qualified service that cannot actually produce the qualification proof, conformity evidence, interoperability, or exit support your product needs. Use this guide to evaluate QTSPs with measurable acceptance criteria: service scope, trust-list proof, security controls, transition status under the amended regulation, operational resilience, and exit readiness. ## Step 1: Define what you actually need (service + assurance + journeys) Start with a service inventory and the journeys that depend on it. Your QTSP requirements depend on which trust services you rely on and what legal effect and dispute posture you need. Make the decision explicit: AdES vs QES, and where qualified services are required or expected. - Service type: QES, qualified seals, qualified timestamps, qualified ERDS, website authentication certificates, validation/preservation. - Journey mapping: onboarding, contract signing, high-risk actions, document sealing, archival. - Evidence outputs: validation reports, status proofs, timestamp proofs, and long-term preservation artifacts. ## Step 2: Qualification and scope validation (avoid "marketing qualification") Qualification is service-specific. Ensure the provider is qualified for the exact service and scope you plan to use. Also confirm its transition status under the amended regulation if it was already qualified before 20 May 2024, because Article 24 identity-proofing evidence changes have a 21 May 2026 conformity deadline. - Qualification proof and scope: confirm qualified status for the specific service or services you plan to use. - Trust-list and supervisory evidence: capture current proof of listing, service status, and the supervising body. - Geographic or service coverage: confirm where the service is valid and how cross-border reliance works in practice. - Change notification: document how you are informed of certification-status changes, incidents, or service modifications. ## Step 3: Security and supervision evidence (what to request) Request evidence aligned to the provider's service and your risk profile. Don't accept "we are certified" without scope and recency validation. Use ENISA guidance to drive practical security controls and supervision expectations. - Security framework evidence: policies, secure operations, access control, incident procedures, and BC or DR testing outputs. - Audit evidence: latest relevant conformity assessments or audits, plus the provider's plan for ongoing refresh and the amended Article 24 deadline if applicable. - Key management and HSM controls: ceremonies, separation of duties, audit logs, and compromise handling. - Incident handling: notification timelines, root-cause deliverables, and joint customer-communications workflow. ## Step 4: Interoperability and integration (reduce product risk) Integration failure is the most common reason QTSP projects slip: certificate profiles, validation rules, and status endpoints behave differently. Treat integration as a test program, not an API call. - Format support matrix: document and test which signature formats and profiles you support end-to-end. - Validation reports: ensure you can generate reproducible validation outcomes with reason codes. - Status service reliability: monitor and test revocation and status checks; define outage behavior. - Support model: escalation paths and incident drills with the QTSP. ## Step 5: Exit strategy (don't get trapped) Your compliance posture depends on being able to change providers without breaking your product or losing evidentiary integrity. Define a migration path and test it. - Portability: validation evidence, audit logs, and certificate history must remain accessible after exit. - Transition plan: timeline and steps for certificate replacement, trust list dependencies, and customer communications. - Contingencies: emergency signing continuity and fallback procedures. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU eIDAS QTSP Selection as a cited research workflow Research Copilot can take EU eIDAS QTSP Selection from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU eIDAS QTSP Selection](/solutions/research-copilot.md): Start from EU eIDAS QTSP Selection and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS QTSP Selection. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Qualified trust services framework and role definitions. - [ENISA - Security framework for trust service providers](https://www.enisa.europa.eu/publications/tsp-security?ref=sorena.io) - Security guidance for trust service providers and practical control design. - [ENISA - Guidelines on supervision of qualified trust service providers](https://www.enisa.europa.eu/publications/tsp-supervision?ref=sorena.io) - Guidance on supervision practices and expectations for qualified trust service providers. - [ETSI - Standards search (trust services policy and profile standards)](https://www.etsi.org/standards-search?ref=sorena.io) - Authoritative index for ETSI standards used in qualified trust service programs (e.g., policy requirements and signature profiles). - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amended eIDAS identity-proofing and transition rules relevant to QTSP vendor due diligence and Article 24 conformity updates. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection --- --- title: "Qualified Trust Services and QTSP Selection" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection" source_url: "https://www.sorena.io/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection" author: "Sorena AI" description: "A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter." keywords: - "QTSP selection checklist" - "qualified trust service provider due diligence" - "eIDAS QTSP requirements" - "qualified electronic signature provider" - "qualified timestamp provider" - "qualified registered delivery provider" - "QTSP audit evidence" - "ENISA QTSP guidance" - "QTSP selection" - "qualified trust services" - "due diligence" - "ENISA guidance" - "ETSI standards" - "audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Qualified Trust Services and QTSP Selection A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. *Vendor Guide* *EU* ## EU eIDAS QTSP Selection Choose qualified trust services with evidence-first due diligence, transition awareness, and operational resilience checks. Designed for relying parties and procurement/security teams buying qualified trust services. QTSP selection is not a procurement exercise. It is a security, supervision, and evidence decision. The biggest failure mode is buying a qualified service that cannot actually produce the qualification proof, conformity evidence, interoperability, or exit support your product needs. Use this guide to evaluate QTSPs with measurable acceptance criteria: service scope, trust-list proof, security controls, transition status under the amended regulation, operational resilience, and exit readiness. ## Step 1: Define what you actually need (service + assurance + journeys) Start with a service inventory and the journeys that depend on it. Your QTSP requirements depend on which trust services you rely on and what legal effect and dispute posture you need. Make the decision explicit: AdES vs QES, and where qualified services are required or expected. - Service type: QES, qualified seals, qualified timestamps, qualified ERDS, website authentication certificates, validation/preservation. - Journey mapping: onboarding, contract signing, high-risk actions, document sealing, archival. - Evidence outputs: validation reports, status proofs, timestamp proofs, and long-term preservation artifacts. ## Step 2: Qualification and scope validation (avoid "marketing qualification") Qualification is service-specific. Ensure the provider is qualified for the exact service and scope you plan to use. Also confirm its transition status under the amended regulation if it was already qualified before 20 May 2024, because Article 24 identity-proofing evidence changes have a 21 May 2026 conformity deadline. - Qualification proof and scope: confirm qualified status for the specific service or services you plan to use. - Trust-list and supervisory evidence: capture current proof of listing, service status, and the supervising body. - Geographic or service coverage: confirm where the service is valid and how cross-border reliance works in practice. - Change notification: document how you are informed of certification-status changes, incidents, or service modifications. ## Step 3: Security and supervision evidence (what to request) Request evidence aligned to the provider's service and your risk profile. Don't accept "we are certified" without scope and recency validation. Use ENISA guidance to drive practical security controls and supervision expectations. - Security framework evidence: policies, secure operations, access control, incident procedures, and BC or DR testing outputs. - Audit evidence: latest relevant conformity assessments or audits, plus the provider's plan for ongoing refresh and the amended Article 24 deadline if applicable. - Key management and HSM controls: ceremonies, separation of duties, audit logs, and compromise handling. - Incident handling: notification timelines, root-cause deliverables, and joint customer-communications workflow. ## Step 4: Interoperability and integration (reduce product risk) Integration failure is the most common reason QTSP projects slip: certificate profiles, validation rules, and status endpoints behave differently. Treat integration as a test program, not an API call. - Format support matrix: document and test which signature formats and profiles you support end-to-end. - Validation reports: ensure you can generate reproducible validation outcomes with reason codes. - Status service reliability: monitor and test revocation and status checks; define outage behavior. - Support model: escalation paths and incident drills with the QTSP. ## Step 5: Exit strategy (don't get trapped) Your compliance posture depends on being able to change providers without breaking your product or losing evidentiary integrity. Define a migration path and test it. - Portability: validation evidence, audit logs, and certificate history must remain accessible after exit. - Transition plan: timeline and steps for certificate replacement, trust list dependencies, and customer communications. - Contingencies: emergency signing continuity and fallback procedures. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU eIDAS QTSP Selection as a cited research workflow Research Copilot can take EU eIDAS QTSP Selection from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU eIDAS QTSP Selection](/solutions/research-copilot.md): Start from EU eIDAS QTSP Selection and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS QTSP Selection. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal (as amended)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Qualified trust services framework and role definitions. - [ENISA - Security framework for trust service providers](https://www.enisa.europa.eu/publications/tsp-security?ref=sorena.io) - Security guidance for trust service providers and practical control design. - [ENISA - Guidelines on supervision of qualified trust service providers](https://www.enisa.europa.eu/publications/tsp-supervision?ref=sorena.io) - Guidance on supervision practices and expectations for qualified trust service providers. - [ETSI - Standards search (trust services policy and profile standards)](https://www.etsi.org/standards-search?ref=sorena.io) - Authoritative index for ETSI standards used in qualified trust service programs (e.g., policy requirements and signature profiles). - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amended eIDAS identity-proofing and transition rules relevant to QTSP vendor due diligence and Article 24 conformity updates. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection --- --- title: "eIDAS Requirements (EU)" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/requirements" source_url: "https://www.sorena.io/artifacts/eu/eidas/requirements" author: "Sorena AI" description: "An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties." keywords: - "eIDAS requirements" - "eIDAS compliance requirements" - "QTSP requirements" - "qualified trust service requirements" - "eIDAS 2.0 requirements" - "EUDI wallet requirements" - "eIDAS evidence checklist" - "ETSI EN 319 401 requirements" - "trust services requirements" - "eIDAS evidence" - "ETSI standards" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS Requirements (EU) An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. *Requirements Guide* *EU* ## EU eIDAS Requirements A requirements breakdown you can implement: controls, tests, evidence, and operating cadence. Optimized for teams building trust services and EUDI Wallet relying party readiness. eIDAS requirements vary by role, but the amended framework is more concrete than many teams realize. Trust-service providers, relying parties, wallet actors, and organizations that depend on qualified services need a live operating model tied to the consolidated regulation, current implementing acts, standards, and supervisory evidence. Use this page to map the legal text into build, run, monitor, and audit tasks. ## Requirements by role (start here) Your compliance program depends on whether you provide trust services (TSP/QTSP), rely on trust services (relying party), or build wallet-related flows (eIDAS 2.0). Most organizations need a combined view (e.g., relying party + QTSP customer + wallet readiness). - Relying party: validate signatures, certificates, wallets, and attestations; log decisions; and enforce data minimization and transparency. - TSP or QTSP: implement security, identity proofing, audit readiness, incident handling, and supervision-facing evidence for each service scope. - Wallet provider or issuer: implement wallet capabilities, certification readiness, person-identification data or attribute issuance controls, and interoperability testing. - Compliance and security owners: governance, vendor oversight, evidence indexing, and continuous control testing across the full stack. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU eIDAS Requirements into an operational assessment Assessment Autopilot can take EU eIDAS Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU eIDAS Requirements](/solutions/assessment.md): Start from EU eIDAS Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Requirements. ## Trust services workstream (what you must implement and prove) Trust services are not only cryptography - they are supervised, auditable services with lifecycle responsibilities. Implement trust services as a system: issuance, signing, validation, revocation, preservation, and customer support processes. - Signature and seal capability: supported formats, signing ceremonies, remote signing device management where relevant, and deterministic validation logic. - Certificate lifecycle: issuance, renewal, revocation, status publication, key-management controls, and audit traces. - Time stamping, registered delivery, archiving, and ledgers: integrity controls, evidence records, service-specific operating procedures, and retention rules. - Long-term validation or preservation: evidence records, archival strategy, migration plans, and export capability for disputes or audits. ## QTSP security + supervision expectations (what audits focus on) Qualified trust services bring a higher bar: supervision, periodic assessments, and strict operational controls. The amended regulation also creates a transition point. QTSPs granted qualified status before 20 May 2024 must submit a conformity assessment report covering Article 24(1), (1a), and (1b) by 21 May 2026, while some older identity-proofing methods continue only through the transitional window. - Security framework: policies, access control, secure operations, incident handling, and business continuity aligned to guidance. - Supervision readiness: evidence that controls operate and that you can respond quickly to audits and supervisory requests. - EU trust mark usage and service qualification communication: consistency and truthfulness of claims by service type. - Supplier and dependency assurance: crypto modules, HSMs, remote signing components, and critical vendors with due diligence and monitoring. ## EUDI Wallet (eIDAS 2.0) requirements (capabilities you may need) eIDAS 2.0 introduces EUDI Wallet obligations and ecosystem roles. Even if you are not a wallet provider, you may need relying-party readiness because the Commission adopted five core wallet implementing regulations in late 2024 and Member States must make at least one wallet available by the end of 2026. Treat wallet readiness as a capability: verifier pipeline, attribute governance, interoperability tests, privacy evidence, and change management tied to evolving implementing acts. - Verifier pipeline: authenticity and validity checks, revocation or status handling, deterministic decision outputs, and logs. - Attribute flows: schema governance, disclosure policies, minimal-attribute request patterns, and handling of qualified electronic attestations of attributes. - User transparency: user-facing explanations and traceable logs of transactions and data sharing. - Interoperability: conformance and compatibility tests aligned to Commission reference materials, ARF releases, and the wallet implementing regulations. ## Evidence mapping (requirement -> control -> test -> artifact) The fastest way to reduce compliance risk is to build an evidence index that is reproducible and always current. Avoid static PDFs as "evidence". Use systems-of-record artifacts plus test results and change logs. - Policy layer: trust service policy, security policy, incident response, and change management policies. - Control layer: access control, key management, signing/validation services, logging, monitoring, and BC/DR controls. - Test layer: interoperability tests, negative tests, audit sampling results, and periodic control effectiveness tests. - Artifact layer: trust list records, certificates, validation reports, audit reports, and supervisory communications. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Consolidated eIDAS text, including the amended Article 24 identity-proofing rules and transitional deadlines for pre-20 May 2024 QTSPs. - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amends eIDAS to add EUDI Wallet obligations, new trust-service categories, and new identity-proofing routes for qualified certificates and qualified electronic attestations of attributes. - [ENISA - Security framework for trust service providers](https://www.enisa.europa.eu/publications/tsp-security?ref=sorena.io) - Technical guidelines and security control expectations for trust service providers. - [ETSI EN 319 401 - General policy requirements for trust service providers](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Widely used policy requirement standard supporting trust service provider compliance programs. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/requirements --- --- title: "eIDAS Requirements (EU)" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/requirements" source_url: "https://www.sorena.io/artifacts/eu/eidas/requirements" author: "Sorena AI" description: "An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties." keywords: - "eIDAS requirements" - "eIDAS compliance requirements" - "QTSP requirements" - "qualified trust service requirements" - "eIDAS 2.0 requirements" - "EUDI wallet requirements" - "eIDAS evidence checklist" - "ETSI EN 319 401 requirements" - "trust services requirements" - "eIDAS evidence" - "ETSI standards" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # eIDAS Requirements (EU) An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. *Requirements Guide* *EU* ## EU eIDAS Requirements A requirements breakdown you can implement: controls, tests, evidence, and operating cadence. Optimized for teams building trust services and EUDI Wallet relying party readiness. eIDAS requirements vary by role, but the amended framework is more concrete than many teams realize. Trust-service providers, relying parties, wallet actors, and organizations that depend on qualified services need a live operating model tied to the consolidated regulation, current implementing acts, standards, and supervisory evidence. Use this page to map the legal text into build, run, monitor, and audit tasks. ## Requirements by role (start here) Your compliance program depends on whether you provide trust services (TSP/QTSP), rely on trust services (relying party), or build wallet-related flows (eIDAS 2.0). Most organizations need a combined view (e.g., relying party + QTSP customer + wallet readiness). - Relying party: validate signatures, certificates, wallets, and attestations; log decisions; and enforce data minimization and transparency. - TSP or QTSP: implement security, identity proofing, audit readiness, incident handling, and supervision-facing evidence for each service scope. - Wallet provider or issuer: implement wallet capabilities, certification readiness, person-identification data or attribute issuance controls, and interoperability testing. - Compliance and security owners: governance, vendor oversight, evidence indexing, and continuous control testing across the full stack. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU eIDAS Requirements into an operational assessment Assessment Autopilot can take EU eIDAS Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU eIDAS Requirements](/solutions/assessment.md): Start from EU eIDAS Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS Requirements. ## Trust services workstream (what you must implement and prove) Trust services are not only cryptography - they are supervised, auditable services with lifecycle responsibilities. Implement trust services as a system: issuance, signing, validation, revocation, preservation, and customer support processes. - Signature and seal capability: supported formats, signing ceremonies, remote signing device management where relevant, and deterministic validation logic. - Certificate lifecycle: issuance, renewal, revocation, status publication, key-management controls, and audit traces. - Time stamping, registered delivery, archiving, and ledgers: integrity controls, evidence records, service-specific operating procedures, and retention rules. - Long-term validation or preservation: evidence records, archival strategy, migration plans, and export capability for disputes or audits. ## QTSP security + supervision expectations (what audits focus on) Qualified trust services bring a higher bar: supervision, periodic assessments, and strict operational controls. The amended regulation also creates a transition point. QTSPs granted qualified status before 20 May 2024 must submit a conformity assessment report covering Article 24(1), (1a), and (1b) by 21 May 2026, while some older identity-proofing methods continue only through the transitional window. - Security framework: policies, access control, secure operations, incident handling, and business continuity aligned to guidance. - Supervision readiness: evidence that controls operate and that you can respond quickly to audits and supervisory requests. - EU trust mark usage and service qualification communication: consistency and truthfulness of claims by service type. - Supplier and dependency assurance: crypto modules, HSMs, remote signing components, and critical vendors with due diligence and monitoring. ## EUDI Wallet (eIDAS 2.0) requirements (capabilities you may need) eIDAS 2.0 introduces EUDI Wallet obligations and ecosystem roles. Even if you are not a wallet provider, you may need relying-party readiness because the Commission adopted five core wallet implementing regulations in late 2024 and Member States must make at least one wallet available by the end of 2026. Treat wallet readiness as a capability: verifier pipeline, attribute governance, interoperability tests, privacy evidence, and change management tied to evolving implementing acts. - Verifier pipeline: authenticity and validity checks, revocation or status handling, deterministic decision outputs, and logs. - Attribute flows: schema governance, disclosure policies, minimal-attribute request patterns, and handling of qualified electronic attestations of attributes. - User transparency: user-facing explanations and traceable logs of transactions and data sharing. - Interoperability: conformance and compatibility tests aligned to Commission reference materials, ARF releases, and the wallet implementing regulations. ## Evidence mapping (requirement -> control -> test -> artifact) The fastest way to reduce compliance risk is to build an evidence index that is reproducible and always current. Avoid static PDFs as "evidence". Use systems-of-record artifacts plus test results and change logs. - Policy layer: trust service policy, security policy, incident response, and change management policies. - Control layer: access control, key management, signing/validation services, logging, monitoring, and BC/DR controls. - Test layer: interoperability tests, negative tests, audit sampling results, and periodic control effectiveness tests. - Artifact layer: trust list records, certificates, validation reports, audit reports, and supervisory communications. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Consolidated eIDAS text, including the amended Article 24 identity-proofing rules and transitional deadlines for pre-20 May 2024 QTSPs. - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amends eIDAS to add EUDI Wallet obligations, new trust-service categories, and new identity-proofing routes for qualified certificates and qualified electronic attestations of attributes. - [ENISA - Security framework for trust service providers](https://www.enisa.europa.eu/publications/tsp-security?ref=sorena.io) - Technical guidelines and security control expectations for trust service providers. - [ETSI EN 319 401 - General policy requirements for trust service providers](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Widely used policy requirement standard supporting trust service provider compliance programs. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. - [What eIDAS Covers (EU) | Trust Services, eSignatures, Wallets, QTSPs, and Relying Parties](/artifacts/eu/eidas/what-eidas-covers.md): A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/requirements --- --- title: "What eIDAS Covers (EU)" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/what-eidas-covers" source_url: "https://www.sorena.io/artifacts/eu/eidas/what-eidas-covers" author: "Sorena AI" description: "A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes." keywords: - "what is eIDAS" - "eIDAS scope" - "eIDAS trust services explained" - "qualified electronic signature eIDAS" - "QTSP meaning" - "EUDI wallet eIDAS 2.0" - "eIDAS relying party" - "electronic seals timestamps registered delivery website authentication" - "trust services" - "qualified electronic signatures" - "QTSP" - "EUDI wallet" - "electronic identification" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # What eIDAS Covers (EU) A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. *Overview* *EU* ## EU eIDAS What It Covers A practical map of trust services, identification, wallets, and who must do what. Use this page to identify your role, then jump to the subpages to build audit-ready implementations. eIDAS (Regulation (EU) No 910/2014) establishes the EU framework for electronic identification and trust services for electronic transactions. The amended regulation, as updated by Regulation (EU) 2024/1183 and its 9 April 2025 corrigendum, now covers a wider trust-service perimeter that includes electronic archiving, electronic attestations of attributes, electronic ledgers, and management of remote electronic signature and seal creation devices. The fastest way to use eIDAS is to treat it as a role and service map: what service you provide or rely on, what evidence you must keep, and which implementing acts and standards shape your operating model. ## eIDAS in one sentence (what it's for) eIDAS is about making electronic transactions trustworthy across the EU internal market: who is on the other side, what was signed, and whether that signature or seal is legally effective across borders. It combines legal effect rules with technical and supervisory mechanisms (trust lists, supervision of qualified trust services, and common standards). - Cross-border eID: recognition of notified electronic identification schemes and the new EUDI Wallet framework. - Trust services: signatures, seals, timestamps, registered delivery, website authentication, electronic archiving, electronic attestations of attributes, electronic ledgers, and related preservation or validation services. - Supervision and qualification: qualified trust services and providers, EU trust mark usage, and audit or supervisory expectations. ## Trust services covered (what teams usually mean by "eIDAS compliance") Most private-sector implementations still touch trust services first. The amended text keeps the traditional services and expands the perimeter with new qualified and non-qualified services that matter for wallet ecosystems, long-term records, and high-assurance remote signing. Treat trust services as products with lifecycles: onboarding, identity proofing, issuance, signing, validation, preservation, incident handling, and withdrawal or migration. - Electronic signatures and seals: advanced or qualified flows, remote signing or sealing, validation reports, and long-term validation. - Electronic time stamps, registered delivery, and website authentication: integrity, evidence of sending or receiving, and authenticated web presence. - Electronic archiving and electronic ledgers: new trust-service categories under the amended regulation, with separate technical standards and operating evidence. - Electronic attestations of attributes: qualified and non-qualified attribute statements that connect issuers, wallets, and relying parties. ## eIDAS 2.0 adds the EUDI Wallet + attribute layer (what changes operationally) The EUDI Wallet introduces a user-centric identity and attribute container with mandatory Member State rollout by the end of 2026 and a technical implementation layer defined through Commission implementing regulations adopted in late 2024. Organizations may become relying parties, issuers of attributes, wallet providers, or customers of qualified trust services that now support wallet-related evidence flows. - Relying party readiness: wallet acceptance strategy, verifier architecture, data minimization controls, transparency logs, and registration or notification flows where required. - Electronic attestations of attributes: schema governance, disclosure policies, identity-proofing assumptions, and deterministic verification pipelines. - Interoperability: follow Commission reference materials, the ARF, and wallet implementing regulations to avoid demo-only integrations. ## Role map: which bucket are you in? Use this quick role map to decide which workstream matters most for you. Most organizations fit more than one bucket (e.g., relying party + QTSP customer + attribute issuer). - Relying party: you authenticate users or consume attributes/signatures and must validate and log decisions. - Trust service provider (TSP/QTSP): you provide trust services and must align to security + supervision expectations. - Product/platform team: you build signing, validation, or wallet integrations and need measurable security and interoperability tests. - Compliance/security: you own evidence, governance cadence, incident procedures, and vendor due diligence. ## Where to go next (best subpages) Use these pages to turn scope into implementation work. Each page is designed to be actionable: checklists, evidence packs, and architecture decisions. - EUDI Wallet readiness: relying party and verifier workstreams. - Electronic signatures and legal effect: decide AdES vs QES and design validation evidence. - Qualified trust services: select QTSPs and build a due diligence + audit evidence program. - Deadlines calendar: plan milestones tied to deliverables, not only dates. *Recommended next step* *Placement: after the scope or definition section* ## Use EU eIDAS What It Covers as a cited research workflow Research Copilot can take EU eIDAS What It Covers from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU eIDAS What It Covers](/solutions/research-copilot.md): Start from EU eIDAS What It Covers and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS What It Covers. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Consolidated eIDAS text showing the expanded trust-service scope after Regulation (EU) 2024/1183 and the 9 April 2025 corrigendum. - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amends eIDAS to introduce the EUDI Wallet framework and new trust-service categories, including electronic attestations of attributes, electronic archiving, and electronic ledgers. - [ENISA - Security framework for trust service providers](https://www.enisa.europa.eu/publications/tsp-security?ref=sorena.io) - Technical security guidelines and implementation considerations for trust service providers. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/what-eidas-covers --- --- title: "What eIDAS Covers (EU)" canonical_url: "https://www.sorena.io/artifacts/eu/eidas/what-eidas-covers" source_url: "https://www.sorena.io/artifacts/eu/eidas/what-eidas-covers" author: "Sorena AI" description: "A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes." keywords: - "what is eIDAS" - "eIDAS scope" - "eIDAS trust services explained" - "qualified electronic signature eIDAS" - "QTSP meaning" - "EUDI wallet eIDAS 2.0" - "eIDAS relying party" - "electronic seals timestamps registered delivery website authentication" - "trust services" - "qualified electronic signatures" - "QTSP" - "EUDI wallet" - "electronic identification" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # What eIDAS Covers (EU) A practical eIDAS overview covering electronic identification, trust services, qualified trust services, electronic attestations of attributes. *Overview* *EU* ## EU eIDAS What It Covers A practical map of trust services, identification, wallets, and who must do what. Use this page to identify your role, then jump to the subpages to build audit-ready implementations. eIDAS (Regulation (EU) No 910/2014) establishes the EU framework for electronic identification and trust services for electronic transactions. The amended regulation, as updated by Regulation (EU) 2024/1183 and its 9 April 2025 corrigendum, now covers a wider trust-service perimeter that includes electronic archiving, electronic attestations of attributes, electronic ledgers, and management of remote electronic signature and seal creation devices. The fastest way to use eIDAS is to treat it as a role and service map: what service you provide or rely on, what evidence you must keep, and which implementing acts and standards shape your operating model. ## eIDAS in one sentence (what it's for) eIDAS is about making electronic transactions trustworthy across the EU internal market: who is on the other side, what was signed, and whether that signature or seal is legally effective across borders. It combines legal effect rules with technical and supervisory mechanisms (trust lists, supervision of qualified trust services, and common standards). - Cross-border eID: recognition of notified electronic identification schemes and the new EUDI Wallet framework. - Trust services: signatures, seals, timestamps, registered delivery, website authentication, electronic archiving, electronic attestations of attributes, electronic ledgers, and related preservation or validation services. - Supervision and qualification: qualified trust services and providers, EU trust mark usage, and audit or supervisory expectations. ## Trust services covered (what teams usually mean by "eIDAS compliance") Most private-sector implementations still touch trust services first. The amended text keeps the traditional services and expands the perimeter with new qualified and non-qualified services that matter for wallet ecosystems, long-term records, and high-assurance remote signing. Treat trust services as products with lifecycles: onboarding, identity proofing, issuance, signing, validation, preservation, incident handling, and withdrawal or migration. - Electronic signatures and seals: advanced or qualified flows, remote signing or sealing, validation reports, and long-term validation. - Electronic time stamps, registered delivery, and website authentication: integrity, evidence of sending or receiving, and authenticated web presence. - Electronic archiving and electronic ledgers: new trust-service categories under the amended regulation, with separate technical standards and operating evidence. - Electronic attestations of attributes: qualified and non-qualified attribute statements that connect issuers, wallets, and relying parties. ## eIDAS 2.0 adds the EUDI Wallet + attribute layer (what changes operationally) The EUDI Wallet introduces a user-centric identity and attribute container with mandatory Member State rollout by the end of 2026 and a technical implementation layer defined through Commission implementing regulations adopted in late 2024. Organizations may become relying parties, issuers of attributes, wallet providers, or customers of qualified trust services that now support wallet-related evidence flows. - Relying party readiness: wallet acceptance strategy, verifier architecture, data minimization controls, transparency logs, and registration or notification flows where required. - Electronic attestations of attributes: schema governance, disclosure policies, identity-proofing assumptions, and deterministic verification pipelines. - Interoperability: follow Commission reference materials, the ARF, and wallet implementing regulations to avoid demo-only integrations. ## Role map: which bucket are you in? Use this quick role map to decide which workstream matters most for you. Most organizations fit more than one bucket (e.g., relying party + QTSP customer + attribute issuer). - Relying party: you authenticate users or consume attributes/signatures and must validate and log decisions. - Trust service provider (TSP/QTSP): you provide trust services and must align to security + supervision expectations. - Product/platform team: you build signing, validation, or wallet integrations and need measurable security and interoperability tests. - Compliance/security: you own evidence, governance cadence, incident procedures, and vendor due diligence. ## Where to go next (best subpages) Use these pages to turn scope into implementation work. Each page is designed to be actionable: checklists, evidence packs, and architecture decisions. - EUDI Wallet readiness: relying party and verifier workstreams. - Electronic signatures and legal effect: decide AdES vs QES and design validation evidence. - Qualified trust services: select QTSPs and build a due diligence + audit evidence program. - Deadlines calendar: plan milestones tied to deliverables, not only dates. *Recommended next step* *Placement: after the scope or definition section* ## Use EU eIDAS What It Covers as a cited research workflow Research Copilot can take EU eIDAS What It Covers from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU eIDAS can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU eIDAS What It Covers](/solutions/research-copilot.md): Start from EU eIDAS What It Covers and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU eIDAS](/contact.md): Review your current process, evidence gaps, and next steps for EU eIDAS What It Covers. ## Primary sources - [Regulation (EU) No 910/2014 (eIDAS) - Official Journal](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Consolidated eIDAS text showing the expanded trust-service scope after Regulation (EU) 2024/1183 and the 9 April 2025 corrigendum. - [Regulation (EU) 2024/1183 - eIDAS 2.0 amendment (EUDI Wallet)](https://eur-lex.europa.eu/eli/reg/2024/1183/oj?ref=sorena.io) - Amends eIDAS to introduce the EUDI Wallet framework and new trust-service categories, including electronic attestations of attributes, electronic archiving, and electronic ledgers. - [ENISA - Security framework for trust service providers](https://www.enisa.europa.eu/publications/tsp-security?ref=sorena.io) - Technical security guidelines and implementation considerations for trust service providers. ## Related Topic Guides - [eIDAS & eIDAS 2.0 Deadlines and Compliance Calendar | EUDI Wallet Key Dates + Readiness Plan](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): An eIDAS deadlines calendar with the dates that matter: 1 July 2016 baseline application, the 2024 eIDAS amendment. - [eIDAS 2.0 vs eIDAS | What Changed: EUDI Wallet, Attributes, Trust Services, Relying Parties](/artifacts/eu/eidas/eidas2-vs-eidas.md): A grounded eIDAS 2.0 vs eIDAS comparison covering what Regulation (EU) 2024/1183 changed: EUDI Wallets, electronic attestations of attributes. - [eIDAS Applicability Test | Are You a Relying Party, TSP/QTSP, Wallet Provider, or Attribute Issuer?](/artifacts/eu/eidas/applicability-test.md): A practical applicability test for eIDAS and eIDAS 2.0: identify your roles (relying party, trust service provider/QTSP, wallet provider, attribute issuer). - [eIDAS Certificates and Authentication | Qualified Certificates, QWACs, Validation, and Implementation](/artifacts/eu/eidas/certificates-and-authentication.md): A deep guide to eIDAS certificates and authentication: qualified certificates for signatures and seals, website authentication certificates. - [eIDAS Checklist and Evidence Pack | Audit-Ready Artifacts for Relying Parties and QTSP Programs](/artifacts/eu/eidas/checklist-and-evidence.md): A deep eIDAS evidence guide: what artifacts auditors and supervisors ask for first, how to structure an evidence index. - [eIDAS Compliance Checklist | Trust Services, QTSP Selection, Wallet Readiness, Evidence](/artifacts/eu/eidas/checklist.md): An audit-ready eIDAS checklist: scope your role (relying party vs QTSP vs wallet work), choose trust services and assurance levels. - [eIDAS Compliance Program | Operating Model, Controls, Tests, and Governance Cadence](/artifacts/eu/eidas/compliance.md): A deep eIDAS compliance playbook: build a role-scoped operating model for trust services and EUDI Wallet readiness, define owners and controls. - [eIDAS FAQ (EU) | QES, QTSP, Trust Services, EUDI Wallet, Evidence, and Deadlines](/artifacts/eu/eidas/faq.md): High-signal answers to the most searched eIDAS questions: what eIDAS covers, AdES vs QES, how to choose a QTSP, what evidence to retain. - [eIDAS Penalties, Liability, and Enforcement | Supervision, Audits, and Risk Reduction](/artifacts/eu/eidas/penalties-and-fines.md): A practical eIDAS enforcement guide: how supervision and audits work for trust service providers and qualified trust services. - [eIDAS Requirements (EU) | Trust Services, QTSP Controls, Wallet Obligations, Evidence Mapping](/artifacts/eu/eidas/requirements.md): An advanced eIDAS requirements breakdown: trust services obligations, QTSP security and supervision expectations, relying party validation duties. - [eIDAS vs E-SIGN Act vs UETA | EU vs US Electronic Signature Frameworks (Practical Comparison)](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): A practical comparison of EU eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) vs the US E-SIGN Act and UETA: legal effect. - [Electronic Signatures under eIDAS | Advanced vs Qualified (AdES vs QES), Legal Effect, Validation](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A deep eIDAS electronic signature guide: decide AdES vs QES, understand legal effect and evidentiary strength, design signing ceremonies and remote signing. - [EUDI Wallet Readiness (eIDAS 2.0) | Relying Party + Provider Checklist and Evidence Pack](/artifacts/eu/eidas/eudi-wallet-readiness.md): A deep EUDI Wallet readiness guide for product, security, and compliance teams: relying party acceptance strategy, identity + attribute flows. - [EUDI Wallet Technical Architecture Guide | ARF-Aligned Components, Flows, and Controls](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): A deep technical architecture guide for the EU Digital Identity (EUDI) Wallet ecosystem: wallet components, issuer + verifier flows. - [Qualified Trust Services and QTSP Selection | Due Diligence, Security, Supervision, Evidence](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): A deep guide to qualified trust services and QTSP selection under eIDAS: how qualification works in practice, what due diligence and contract clauses matter. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eidas/what-eidas-covers --- --- title: "EMC Directive Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/emc-directive/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/emc-directive/applicability-test" author: "Sorena AI" description: "A practical EMC Directive applicability test: decide scope for Directive 2014/30/EU, classify apparatus vs fixed installations." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EMC Directive applicability test" - "is EMC Directive applicable" - "Directive 2014/30/EU scope test" - "apparatus vs fixed installation test" - "EMC CE marking scope" - "EMC directive exclusions" - "EMC directive borderline cases" - "EMC Directive applicability" - "Directive 2014/30/EU" - "apparatus vs fixed installation" - "CE marking scope" - "emissions and immunity" - "harmonised standards" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EMC Directive Applicability Test A practical EMC Directive applicability test: decide scope for Directive 2014/30/EU, classify apparatus vs fixed installations. *Applicability Test* *EU* ## EU EMC Directive Applicability Test Decide scope fast, then generate the right test plan and documentation workstream. Outputs a practical next-step plan for CE marking readiness. Use this test to decide whether the EMC Directive applies to your product, how to classify it (apparatus vs fixed installation), and what you must build next (test plan, technical file, DoC, standards strategy). Save the outcome as a short decision record in your technical documentation. ## Step 1 - Are you placing equipment on the EU/EEA market? Scope starts with commercialization: placing on the market or putting into service in the EU/EEA. If you sell globally, you still need an EU-specific compliance view and evidence pack. - Is the product made available to end users or integrators in the EU/EEA? - Do you provide it as a finished unit or a combination marketed as a single functional unit? - Do you control the final configuration used in the field (variants, cables, accessories)? ## Step 2 - Does it have EMC-relevant behavior? The Directive focuses on equipment liable to generate electromagnetic disturbance or be affected by it. If you believe equipment is "inherently benign", you must justify that claim with evidence. - Does it include electrical/electronic parts that can emit or be susceptible? - Does it contain switching power supplies, radios, motors, digital interfaces, or high-speed clocks? - Could it be installed in residential environments (stricter expectations often apply)? ## Step 3 - Classify: apparatus or fixed installation? This classification changes your obligations, documentation, and test strategy. Use the Commission's EMCD Guide as the main interpretation layer. - Apparatus: finished appliance/combination made available as a single functional unit intended for end users. - Fixed installation: site-assembled combination intended to be used permanently at a predefined location. - Mobile installation: if intended to be moved and used in multiple locations, treat as apparatus in most cases. ## Step 4 - Check exclusions and overlaps (RED/LVD/vehicle) Overlap is common. EMC work still matters, but another directive can drive the route and documentation structure. Record overlap decisions in your technical file. - Radio products: review EMC vs RED. EMC requirements may be addressed via the radio equipment route. - Electrical safety: review EMC vs LVD (often both apply). - Vehicle equipment: review Commission guidance on EMCD vs vehicle legislation for aftermarket equipment. ## Step 5 - Your output plan (what to do next) Use your classification to choose the right deliverables. Don't start with lab testing until you define configuration and standards strategy. The goal is reproducible evidence: requirements -> test plan -> test results -> technical file -> EU DoC. - If apparatus: build an EMC test plan (emissions + immunity), run testing, compile technical documentation, issue EU Declaration of Conformity, and apply CE marking. - If fixed installation: define responsibility model and documentation approach; ensure essential requirements are met and evidence exists for installation-level EMC assessment. - Always: pick harmonised standards strategy and manage updates (superseded standards and cessation dates). *Recommended next step* *Placement: after the applicability result* ## Turn EU EMC Directive Applicability Test into an operational assessment Assessment Autopilot can take EU EMC Directive Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU EMC Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU EMC Directive Applicability Test](/solutions/assessment.md): Start from EU EMC Directive Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU EMC Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU EMC Directive Applicability Test. ## Primary sources - [Directive 2014/30/EU - EMC Directive (official text)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32014L0030&ref=sorena.io) - Primary legal text for scope and obligations. - [Guide for the EMCD (Directive 2014/30/EU) - Commission guidance (DocsRoom)](https://ec.europa.eu/docsroom/documents/33601?ref=sorena.io) - Commission guidance describing apparatus vs fixed installation classification and borderline concepts. - [European Commission - EMC Directive page (resources and guidance)](https://single-market-economy.ec.europa.eu/sectors/electrical-and-electronic-engineering-industries-eei/electromagnetic-compatibility-emc-directive_en?ref=sorena.io) - Official resource hub linking to Q&A and compliance templates. ## Related Topic Guides - [EMC Conformity Assessment + Documentation | Technical File, EU DoC, CE Marking, Language Rules](/artifacts/eu/emc-directive/conformity-assessment-and-documentation.md): A deep guide to EMC conformity assessment and documentation for Directive 2014/30/EU: how to structure the technical documentation/technical file. - [EMC Directive Compliance Checklist | CE Marking, Test Plan, Technical File, EU DoC](/artifacts/eu/emc-directive/checklist.md): An audit-ready EMC Directive checklist (Directive 2014/30/EU): scope and classification (apparatus vs fixed installation), standards strategy. - [EMC Directive Compliance Program | Operating Model, Controls, Testing Cadence, Evidence](/artifacts/eu/emc-directive/compliance.md): A deep EMC Directive compliance playbook: build a role-scoped operating model for manufacturers/importers/distributors. - [EMC Directive Deadlines + Compliance Calendar | CE Marking Milestones, Standards Updates, Language Gates](/artifacts/eu/emc-directive/deadlines-and-compliance-calendar.md): A practical EMC compliance calendar for Directive 2014/30/EU with the legal baseline dates, recurring standards reviews. - [EMC Directive Enforcement | Market Surveillance, Corrective Actions, Evidence to Reduce Risk](/artifacts/eu/emc-directive/penalties-and-fines.md): A practical EMC enforcement guide: how market surveillance works under EU product rules, what authorities typically request (technical file, test reports. - [EMC Directive FAQ | Scope, Testing, Technical File, EU DoC, Fixed Installations, Standards](/artifacts/eu/emc-directive/faq.md): High-signal answers to common EMC Directive questions: what is in scope, apparatus vs fixed installations, what to test (emissions + immunity). - [EMC Directive Requirements (2014/30/EU) | Essential Requirements, Operator Duties, Evidence Map](/artifacts/eu/emc-directive/requirements.md): An advanced EMC Directive requirements breakdown: essential requirements (emissions + immunity), obligations for manufacturers/importers/distributors. - [EMC Directive Scope + Borderline Cases | Apparatus vs Fixed Installations, Exclusions, "Inherently Benign"](/artifacts/eu/emc-directive/scope-and-borderline-cases.md): A deep scope guide for the EU EMC Directive (2014/30/EU): how to decide if your product is in scope. - [EMC Directive Timeline | Key Dates for Directive 2014/30/EU, Transition, Standards, Guidance](/artifacts/eu/emc-directive/timeline.md): A practical EMC Directive timeline: adoption and publication of Directive 2014/30/EU. - [EMC Directive vs Low Voltage Directive (LVD) | What Applies, What to Test, One Technical File](/artifacts/eu/emc-directive/emc-vs-low-voltage-directive.md): A practical comparison of the EU EMC Directive (2014/30/EU) vs the Low Voltage Directive (2014/35/EU): different objectives (EMC vs electrical safety). - [EMC Directive vs Radio Equipment Directive (RED) | Which Route Applies for Wireless Products?](/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive.md): A practical comparison of the EMC Directive (2014/30/EU) vs the Radio Equipment Directive (RED) (2014/53/EU): when wireless products fall under RED. - [EMC Essential Requirements + Testing | Emissions, Immunity, Test Configurations, Evidence](/artifacts/eu/emc-directive/essential-requirements-and-testing.md): A deep EMC testing guide for Directive 2014/30/EU: translate essential requirements into emissions + immunity test plans. - [EMC Harmonised Standards Strategy | Presumption of Conformity, OJEU References, Deviations](/artifacts/eu/emc-directive/harmonized-standards-and-deviations.md): A deep guide to harmonised standards under the EMC Directive: how presumption of conformity works. - [EMC Test Plan Template | Directive 2014/30/EU Emissions + Immunity Plan (Audit-Ready)](/artifacts/eu/emc-directive/emc-test-plan-template.md): A structured EMC test plan template you can copy and adapt for CE marking: scope and configuration matrix, standards selection. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/emc-directive/applicability-test --- --- title: "EMC Directive Compliance Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/emc-directive/checklist" source_url: "https://www.sorena.io/artifacts/eu/emc-directive/checklist" author: "Sorena AI" description: "An audit-ready EMC Directive checklist (Directive 2014/30/EU): scope and classification (apparatus vs fixed installation), standards strategy." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EMC Directive checklist" - "Directive 2014/30/EU checklist" - "EMC compliance checklist" - "EMC CE marking checklist" - "EMC technical file checklist" - "EU Declaration of Conformity template EMC" - "emissions immunity test checklist" - "harmonised standards checklist" - "EMC checklist" - "CE marking" - "technical file" - "EU Declaration of Conformity" - "emissions and immunity testing" - "harmonised standards" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EMC Directive Compliance Checklist An audit-ready EMC Directive checklist (Directive 2014/30/EU): scope and classification (apparatus vs fixed installation), standards strategy. *Checklist* *EU* ## EU EMC Directive Checklist A CE-marking-ready EMC checklist with acceptance criteria and evidence outputs. Optimized for hardware teams, compliance owners, and suppliers. This checklist is evidence-first: every item is only "done" when you can prove it with a controlled artifact (test report, decision record, DoC, labeling sample, or exportable evidence index). Use it to drive work across engineering, compliance, and manufacturing without last-minute retesting. ## 1) Scope and classification (week 0) Start with classification and configuration control. This prevents testing the wrong thing and losing weeks late in the cycle. Keep a short scope decision record in your technical file. - Decide if Directive 2014/30/EU applies and document overlaps (RED/LVD/vehicle). - Classify: apparatus vs fixed installation; document rationale and boundaries. - Define intended environment assumptions (residential/commercial/industrial). - Create a configuration matrix: SKUs, variants, accessories, cable sets, and firmware modes. ## 2) Standards strategy (presumption of conformity plan) Pick harmonised standards that match your product category and intended environment, and track their OJEU references and updates. Treat standards as dependencies with version control. - Select harmonised standards and record the selection rationale. - Record OJEU reference check date and owner; track superseded standards and cessation dates. - Create a deviation register for any non-standard approach and define compensating tests. ## 3) EMC assessment and test plan (before lab time) Do not book lab time before you have a controlled test plan and worst-case configuration definition. A good plan reduces retests and produces evidence that can be reused across variants. - Write an EMC test plan with emissions + immunity test cases and measurable functional criteria. - Define worst-case configurations: modes, cables, loads, enclosure versions. - Define retest triggers and change control rules (layout, PSU, clocks, firmware modes, connectors). ## 4) Testing execution and deviation handling Testing is an engineering loop. What matters is controlled iteration and clean evidence outputs. Capture deviations and retest results in a way you can explain later. - Run pre-compliance scans to reduce formal test failures. - Execute lab tests; collect photos, setup details, and calibration references. - Maintain a deviation register: root cause, mitigation, retest scope, and closure evidence. - Confirm final configuration matches what will be placed on the market. ## 5) Technical documentation + EU Declaration of Conformity Your technical file should be exportable and reproducible. The EU DoC should be correct, controlled, and linked to the evidence index. Use official templates and make document control part of release processes. - Compile technical documentation: product identity, design description, standards applied, test evidence, change control, and installation constraints. - Create EU DoC using a structured template; list directives and standards correctly (with versions). - Set retention rules and signatory authority; ensure the DoC maps to product variants. ## 6) CE marking, traceability, instructions, and language requirements Compliance fails in the last mile when labeling and instructions aren't consistent with the tested configuration and assumptions. Language requirements vary by Member State and can create market surveillance findings. - CE marking and labeling samples approved; model/type identification and manufacturer contact details present. - Traceability: packaging and documentation support importer/distributor obligations. - Instructions include EMC-relevant installation conditions (cabling, shielding, grounding) and any residential constraints. - Language matrix built for target markets; translations are version-controlled. *Recommended next step* *Placement: after the checklist block* ## Turn EU EMC Directive Checklist into an operational assessment Assessment Autopilot can take EU EMC Directive Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU EMC Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU EMC Directive Checklist](/solutions/assessment.md): Start from EU EMC Directive Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU EMC Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU EMC Directive Checklist. ## Primary sources - [European Commission - EMC Directive page (guidance + templates)](https://single-market-economy.ec.europa.eu/sectors/electrical-and-electronic-engineering-industries-eei/electromagnetic-compatibility-emc-directive_en?ref=sorena.io) - Official resource hub for EMCD Guide, DoC template, Q&A, and language requirements. - [Guide for the EMCD (Directive 2014/30/EU) - Commission guidance (DocsRoom)](https://ec.europa.eu/docsroom/documents/33601?ref=sorena.io) - Detailed guidance on scope, EMC assessment, documentation, CE marking information, and fixed installations. - [EU DoC template example - EMC ADCO (DocsRoom)](https://ec.europa.eu/docsroom/documents/23962/attachments/1/translations/en/renditions/native?ref=sorena.io) - Structured format for EU Declaration of Conformity. - [EU/EEA language requirements summary for EMCD 2014/30/EU (DocsRoom)](https://ec.europa.eu/docsroom/documents/26690?ref=sorena.io) - Country-by-country language requirements for documentation and user information. ## Related Topic Guides - [EMC Conformity Assessment + Documentation | Technical File, EU DoC, CE Marking, Language Rules](/artifacts/eu/emc-directive/conformity-assessment-and-documentation.md): A deep guide to EMC conformity assessment and documentation for Directive 2014/30/EU: how to structure the technical documentation/technical file. - [EMC Directive Applicability Test | Is Directive 2014/30/EU in Scope for Your Product?](/artifacts/eu/emc-directive/applicability-test.md): A practical EMC Directive applicability test: decide scope for Directive 2014/30/EU, classify apparatus vs fixed installations. - [EMC Directive Compliance Program | Operating Model, Controls, Testing Cadence, Evidence](/artifacts/eu/emc-directive/compliance.md): A deep EMC Directive compliance playbook: build a role-scoped operating model for manufacturers/importers/distributors. - [EMC Directive Deadlines + Compliance Calendar | CE Marking Milestones, Standards Updates, Language Gates](/artifacts/eu/emc-directive/deadlines-and-compliance-calendar.md): A practical EMC compliance calendar for Directive 2014/30/EU with the legal baseline dates, recurring standards reviews. - [EMC Directive Enforcement | Market Surveillance, Corrective Actions, Evidence to Reduce Risk](/artifacts/eu/emc-directive/penalties-and-fines.md): A practical EMC enforcement guide: how market surveillance works under EU product rules, what authorities typically request (technical file, test reports. - [EMC Directive FAQ | Scope, Testing, Technical File, EU DoC, Fixed Installations, Standards](/artifacts/eu/emc-directive/faq.md): High-signal answers to common EMC Directive questions: what is in scope, apparatus vs fixed installations, what to test (emissions + immunity). - [EMC Directive Requirements (2014/30/EU) | Essential Requirements, Operator Duties, Evidence Map](/artifacts/eu/emc-directive/requirements.md): An advanced EMC Directive requirements breakdown: essential requirements (emissions + immunity), obligations for manufacturers/importers/distributors. - [EMC Directive Scope + Borderline Cases | Apparatus vs Fixed Installations, Exclusions, "Inherently Benign"](/artifacts/eu/emc-directive/scope-and-borderline-cases.md): A deep scope guide for the EU EMC Directive (2014/30/EU): how to decide if your product is in scope. - [EMC Directive Timeline | Key Dates for Directive 2014/30/EU, Transition, Standards, Guidance](/artifacts/eu/emc-directive/timeline.md): A practical EMC Directive timeline: adoption and publication of Directive 2014/30/EU. - [EMC Directive vs Low Voltage Directive (LVD) | What Applies, What to Test, One Technical File](/artifacts/eu/emc-directive/emc-vs-low-voltage-directive.md): A practical comparison of the EU EMC Directive (2014/30/EU) vs the Low Voltage Directive (2014/35/EU): different objectives (EMC vs electrical safety). - [EMC Directive vs Radio Equipment Directive (RED) | Which Route Applies for Wireless Products?](/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive.md): A practical comparison of the EMC Directive (2014/30/EU) vs the Radio Equipment Directive (RED) (2014/53/EU): when wireless products fall under RED. - [EMC Essential Requirements + Testing | Emissions, Immunity, Test Configurations, Evidence](/artifacts/eu/emc-directive/essential-requirements-and-testing.md): A deep EMC testing guide for Directive 2014/30/EU: translate essential requirements into emissions + immunity test plans. - [EMC Harmonised Standards Strategy | Presumption of Conformity, OJEU References, Deviations](/artifacts/eu/emc-directive/harmonized-standards-and-deviations.md): A deep guide to harmonised standards under the EMC Directive: how presumption of conformity works. - [EMC Test Plan Template | Directive 2014/30/EU Emissions + Immunity Plan (Audit-Ready)](/artifacts/eu/emc-directive/emc-test-plan-template.md): A structured EMC test plan template you can copy and adapt for CE marking: scope and configuration matrix, standards selection. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/emc-directive/checklist --- --- title: "EMC Directive Compliance Program" canonical_url: "https://www.sorena.io/artifacts/eu/emc-directive/compliance" source_url: "https://www.sorena.io/artifacts/eu/emc-directive/compliance" author: "Sorena AI" description: "A deep EMC Directive compliance playbook: build a role-scoped operating model for manufacturers/importers/distributors." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EMC compliance program" - "EMC Directive 2014/30/EU compliance" - "CE marking EMC program" - "EMC standards management" - "EMC testing cadence" - "EMC technical file evidence index" - "market surveillance readiness EMC" - "CE marking program" - "testing cadence" - "standards management" - "technical file evidence index" - "market surveillance readiness" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EMC Directive Compliance Program A deep EMC Directive compliance playbook: build a role-scoped operating model for manufacturers/importers/distributors. *Program Playbook* *EU* ## EU EMC Directive Compliance Program Build a durable program: standards, testing, suppliers, and evidence that stays current. Designed for product orgs shipping hardware and compliance teams owning CE readiness. EMC compliance is a lifecycle program. If you treat it as "one lab test", you'll fail in production: variants drift, standards change, suppliers change components, and evidence becomes stale. The right approach is an operating model: controlled standards strategy, repeatable test cadence, robust configuration/change control, and an evidence index that can be exported on demand for audits and market surveillance. ## Minimum viable program structure (4 workstreams) Keep the program simple and measurable. Most organizations succeed with 4 workstreams that align to real operational risks. Each workstream has owners, acceptance criteria, and recurring cadence. - Workstream A - Scope and product governance: classification, environment assumptions, variant matrix, and overlap decisions. - Workstream B - Standards strategy: harmonised standards selection, OJEU monitoring, update impact assessments, deviations register. - Workstream C - Testing and engineering controls: test plans, lab execution, pre-compliance, mitigation loop, and retest triggers. - Workstream D - Documentation and evidence: technical file index, EU DoC control, labeling/instructions, language compliance. ## RACI (who owns what) EMC work fails when compliance owns the paperwork and engineering owns the reality. Define a clear RACI. Make change control and retest triggers explicit so releases don't ship out of compliance. - Engineering: test plan content, configuration control, mitigation design, and validation evidence. - Compliance: scope decisions, standards policy, DoC control, evidence index, and market surveillance responses. - Manufacturing/operations: labeling/traceability execution and control over BOM/variant changes. - Procurement/suppliers: component change notifications and supplier evidence collection (PSU, RF modules, cables). ## Testing cadence (how to stay compliant across releases) Define what is tested when. You don't need to retest everything every release, but you must be able to justify your decision. Use risk-based retesting rules linked to the change types that affect EMC. - Pre-compliance per hardware spin: bench scans and targeted immunity checks on changed subsystems. - Formal lab testing per major release/variant: emissions + immunity on worst-case configurations. - Supplier change review: PSUs, clocks, enclosures, cable shielding changes trigger targeted tests. - Quarterly standards review: assess OJEU updates and decide whether DoC/technical file must be updated. ## Evidence index (exportable, reproducible, always current) A technical file is not a folder - it's a curated evidence index that links obligations to living artifacts. Build it so it can be exported quickly when requested. - Requirement -> Standard clause -> Test case -> Evidence link -> Variant coverage -> Owner -> Last review date. - Version everything: test plans, firmware versions, and standards versions referenced by DoC. - Store configuration records and photos; ensure the "tested configuration" matches "shipped configuration". - Track deviations and closure evidence (mitigation + retest). *Recommended next step* *Placement: after the compliance steps* ## Turn EU EMC Directive Compliance Program into an operational assessment Assessment Autopilot can take EU EMC Directive Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU EMC Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU EMC Directive Compliance Program](/solutions/assessment.md): Start from EU EMC Directive Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU EMC Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU EMC Directive Compliance Program. ## Primary sources - [European Commission - EMC Directive page (guidance + resources)](https://single-market-economy.ec.europa.eu/sectors/electrical-and-electronic-engineering-industries-eei/electromagnetic-compatibility-emc-directive_en?ref=sorena.io) - Commission hub with guidance, templates, and key resources for EMCD implementation. - [Guide for the EMCD (Directive 2014/30/EU) - Commission guidance (DocsRoom)](https://ec.europa.eu/docsroom/documents/33601?ref=sorena.io) - Guidance on scope, EMC assessment, documentation, CE marking information, and fixed installations. - [European Commission - Harmonised standards for EMC (official references)](https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards/electromagnetic-compatibility-emc_en?ref=sorena.io) - Official references and updates for harmonised standards under the EMC Directive. ## Related Topic Guides - [EMC Conformity Assessment + Documentation | Technical File, EU DoC, CE Marking, Language Rules](/artifacts/eu/emc-directive/conformity-assessment-and-documentation.md): A deep guide to EMC conformity assessment and documentation for Directive 2014/30/EU: how to structure the technical documentation/technical file. - [EMC Directive Applicability Test | Is Directive 2014/30/EU in Scope for Your Product?](/artifacts/eu/emc-directive/applicability-test.md): A practical EMC Directive applicability test: decide scope for Directive 2014/30/EU, classify apparatus vs fixed installations. - [EMC Directive Compliance Checklist | CE Marking, Test Plan, Technical File, EU DoC](/artifacts/eu/emc-directive/checklist.md): An audit-ready EMC Directive checklist (Directive 2014/30/EU): scope and classification (apparatus vs fixed installation), standards strategy. - [EMC Directive Deadlines + Compliance Calendar | CE Marking Milestones, Standards Updates, Language Gates](/artifacts/eu/emc-directive/deadlines-and-compliance-calendar.md): A practical EMC compliance calendar for Directive 2014/30/EU with the legal baseline dates, recurring standards reviews. - [EMC Directive Enforcement | Market Surveillance, Corrective Actions, Evidence to Reduce Risk](/artifacts/eu/emc-directive/penalties-and-fines.md): A practical EMC enforcement guide: how market surveillance works under EU product rules, what authorities typically request (technical file, test reports. - [EMC Directive FAQ | Scope, Testing, Technical File, EU DoC, Fixed Installations, Standards](/artifacts/eu/emc-directive/faq.md): High-signal answers to common EMC Directive questions: what is in scope, apparatus vs fixed installations, what to test (emissions + immunity). - [EMC Directive Requirements (2014/30/EU) | Essential Requirements, Operator Duties, Evidence Map](/artifacts/eu/emc-directive/requirements.md): An advanced EMC Directive requirements breakdown: essential requirements (emissions + immunity), obligations for manufacturers/importers/distributors. - [EMC Directive Scope + Borderline Cases | Apparatus vs Fixed Installations, Exclusions, "Inherently Benign"](/artifacts/eu/emc-directive/scope-and-borderline-cases.md): A deep scope guide for the EU EMC Directive (2014/30/EU): how to decide if your product is in scope. - [EMC Directive Timeline | Key Dates for Directive 2014/30/EU, Transition, Standards, Guidance](/artifacts/eu/emc-directive/timeline.md): A practical EMC Directive timeline: adoption and publication of Directive 2014/30/EU. - [EMC Directive vs Low Voltage Directive (LVD) | What Applies, What to Test, One Technical File](/artifacts/eu/emc-directive/emc-vs-low-voltage-directive.md): A practical comparison of the EU EMC Directive (2014/30/EU) vs the Low Voltage Directive (2014/35/EU): different objectives (EMC vs electrical safety). - [EMC Directive vs Radio Equipment Directive (RED) | Which Route Applies for Wireless Products?](/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive.md): A practical comparison of the EMC Directive (2014/30/EU) vs the Radio Equipment Directive (RED) (2014/53/EU): when wireless products fall under RED. - [EMC Essential Requirements + Testing | Emissions, Immunity, Test Configurations, Evidence](/artifacts/eu/emc-directive/essential-requirements-and-testing.md): A deep EMC testing guide for Directive 2014/30/EU: translate essential requirements into emissions + immunity test plans. - [EMC Harmonised Standards Strategy | Presumption of Conformity, OJEU References, Deviations](/artifacts/eu/emc-directive/harmonized-standards-and-deviations.md): A deep guide to harmonised standards under the EMC Directive: how presumption of conformity works. - [EMC Test Plan Template | Directive 2014/30/EU Emissions + Immunity Plan (Audit-Ready)](/artifacts/eu/emc-directive/emc-test-plan-template.md): A structured EMC test plan template you can copy and adapt for CE marking: scope and configuration matrix, standards selection. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/emc-directive/compliance --- --- title: "EMC Conformity Assessment + Documentation" canonical_url: "https://www.sorena.io/artifacts/eu/emc-directive/conformity-assessment-and-documentation" source_url: "https://www.sorena.io/artifacts/eu/emc-directive/conformity-assessment-and-documentation" author: "Sorena AI" description: "A deep guide to EMC conformity assessment and documentation for Directive 2014/30/EU: how to structure the technical documentation/technical file." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EMC technical documentation" - "EMC technical file" - "EU Declaration of Conformity EMC template" - "CE marking EMC documentation" - "EMC traceability requirements" - "EMC instructions residential warning" - "EMC language requirements EU" - "Directive 2014/30/EU documentation" - "technical documentation" - "EU Declaration of Conformity" - "CE marking" - "traceability" - "language requirements" - "market surveillance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EMC Conformity Assessment + Documentation A deep guide to EMC conformity assessment and documentation for Directive 2014/30/EU: how to structure the technical documentation/technical file. *Documentation Guide* *EU* ## EU EMC Directive Conformity + Documentation Build the technical file, EU DoC, and CE marking documentation that survives audits. Optimized for engineering teams shipping hardware and compliance teams owning CE readiness. Documentation is your legal and operational defense. Market surveillance does not start by asking whether you tested. It asks whether you can prove conformity for the product placed on the market. The best approach is to build a technical file as an evidence index: scope decision, Annex II or Annex III route, standards strategy, EMC assessment, test plan, test results, change control, and the EU Declaration of Conformity. ## Conformity assessment (apparatus vs fixed installation) For apparatus, the normal legal routes are Annex II internal production control or Annex III EU-type examination followed by conformity to type based on internal production control. For fixed installations, you do not run the same CE-marking flow, but you still need evidence of meeting the essential requirements and of following good engineering practice. - Start with scope classification and configuration control for variants, ports, cables, intended environment, and any installation assumptions. - Choose the conformity-assessment route early: Annex II for the standard internal route, Annex III if a notified body will issue an EU-type examination certificate. - Define evidence outputs and owners before lab testing so reports, design notes, and declarations line up. ## Technical documentation / technical file (recommended structure) Build the technical file as an organized set of artifacts that can be exported quickly when requested. Make it reproducible: someone should be able to explain and re-run the assessment decisions years later. - Product identity: model or SKU mapping, variants, accessories, and the configuration matrix covered by testing. - Design description: block diagrams, PCB revisions, enclosure and cabling assumptions, interfaces and port list. - Standards and assessment: standards applied, version references, and the EMC assessment record required by Annex II. - Test evidence: test plan, lab reports, setups, photos, deviations and retest logs, and functional criteria definition. - Conformity-route evidence: Annex III EU-type examination certificate where applicable, plus change-control triggers for re-test. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU EMC Directive Conformity + Documentation in one governed evidence system SSOT can take EU EMC Directive Conformity + Documentation from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU EMC Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU EMC Directive Conformity + Documentation](/solutions/ssot.md): Start from EU EMC Directive Conformity + Documentation and keep documents, evidence, and control records in one governed system. - [Talk through EU EMC Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU EMC Directive Conformity + Documentation. ## EU Declaration of Conformity (DoC) (how to avoid common mistakes) A DoC is a legally meaningful statement by the manufacturer or authorized representative and must reference the correct directives and standards. Use the Commission template structure, version 2016/04/19, and treat the DoC as a controlled document linked to product variants and release states. - Identify the product unambiguously with model, type, and where relevant batch or serial patterns. - List the applicable EU harmonization legislation and the correct publication references. - List the harmonised standards applied and any other technical specifications used if harmonised standards were not applied fully. - Where applicable, identify the notified body and the EU-type examination certificate issued under Annex III. - Link the DoC to the technical-file evidence index and apply retention rules. ## CE marking + traceability + user information CE marking is not just a symbol. It comes with traceability expectations and information for safe and correct use. The Commission guidance highlights information obligations including identification, contact details, and instructions (including residential area caveats where compliance is not ensured). - Marking and labeling: CE marking placement and permanence, model or type identification, and manufacturer contact details. - Traceability: importers and distributors need enough documentation and product information to support authority requests. - Instructions: include installation conditions necessary for EMC, such as cabling, shielding, grounding, separation distances, and supported environments. - Residential warnings: where compliance is not ensured in residential areas, provide clear information and operating constraints. ## National language requirements (make it a release gate) Language requirements vary by Member State and often apply to instructions, contact details, and the EU DoC. Treat language compliance as a release gate for each country/market: it's a common reason for market surveillance findings. - Maintain a target-market language matrix for: instructions, safety information, contact details, and DoC availability. - Keep translation changes under document control (versioned, linked to product releases). - If you ship to many EU/EEA countries, automate DoC generation and packaging inserts. ## Primary sources - [Guide for the EMCD (Directive 2014/30/EU) - Commission guidance (DocsRoom)](https://ec.europa.eu/docsroom/documents/33601?ref=sorena.io) - Commission guidance on Annex II versus Annex III, technical-file contents, Article 15 DoC structure, Article 19 fixed-installation evidence, and user-information obligations. - [Example EU Declaration of Conformity (DoC) template - EMC ADCO (DocsRoom)](https://ec.europa.eu/docsroom/documents/23962/attachments/1/translations/en/renditions/native?ref=sorena.io) - Official EMC ADCO DoC template structure, version 2016/04/19. - [EU/EEA language requirements for products covered by EMCD 2014/30/EU (DocsRoom)](https://ec.europa.eu/docsroom/documents/26690?ref=sorena.io) - Country-by-country language requirements summary for technical documentation and user information. - [European Commission - CE marking (overview)](https://single-market-economy.ec.europa.eu/single-market/goods/ce-marking_en?ref=sorena.io) - General CE marking overview and economic operator roles context. ## Related Topic Guides - [EMC Directive Applicability Test | Is Directive 2014/30/EU in Scope for Your Product?](/artifacts/eu/emc-directive/applicability-test.md): A practical EMC Directive applicability test: decide scope for Directive 2014/30/EU, classify apparatus vs fixed installations. - [EMC Directive Compliance Checklist | CE Marking, Test Plan, Technical File, EU DoC](/artifacts/eu/emc-directive/checklist.md): An audit-ready EMC Directive checklist (Directive 2014/30/EU): scope and classification (apparatus vs fixed installation), standards strategy. - [EMC Directive Compliance Program | Operating Model, Controls, Testing Cadence, Evidence](/artifacts/eu/emc-directive/compliance.md): A deep EMC Directive compliance playbook: build a role-scoped operating model for manufacturers/importers/distributors. - [EMC Directive Deadlines + Compliance Calendar | CE Marking Milestones, Standards Updates, Language Gates](/artifacts/eu/emc-directive/deadlines-and-compliance-calendar.md): A practical EMC compliance calendar for Directive 2014/30/EU with the legal baseline dates, recurring standards reviews. - [EMC Directive Enforcement | Market Surveillance, Corrective Actions, Evidence to Reduce Risk](/artifacts/eu/emc-directive/penalties-and-fines.md): A practical EMC enforcement guide: how market surveillance works under EU product rules, what authorities typically request (technical file, test reports. - [EMC Directive FAQ | Scope, Testing, Technical File, EU DoC, Fixed Installations, Standards](/artifacts/eu/emc-directive/faq.md): High-signal answers to common EMC Directive questions: what is in scope, apparatus vs fixed installations, what to test (emissions + immunity). - [EMC Directive Requirements (2014/30/EU) | Essential Requirements, Operator Duties, Evidence Map](/artifacts/eu/emc-directive/requirements.md): An advanced EMC Directive requirements breakdown: essential requirements (emissions + immunity), obligations for manufacturers/importers/distributors. - [EMC Directive Scope + Borderline Cases | Apparatus vs Fixed Installations, Exclusions, "Inherently Benign"](/artifacts/eu/emc-directive/scope-and-borderline-cases.md): A deep scope guide for the EU EMC Directive (2014/30/EU): how to decide if your product is in scope. - [EMC Directive Timeline | Key Dates for Directive 2014/30/EU, Transition, Standards, Guidance](/artifacts/eu/emc-directive/timeline.md): A practical EMC Directive timeline: adoption and publication of Directive 2014/30/EU. - [EMC Directive vs Low Voltage Directive (LVD) | What Applies, What to Test, One Technical File](/artifacts/eu/emc-directive/emc-vs-low-voltage-directive.md): A practical comparison of the EU EMC Directive (2014/30/EU) vs the Low Voltage Directive (2014/35/EU): different objectives (EMC vs electrical safety). - [EMC Directive vs Radio Equipment Directive (RED) | Which Route Applies for Wireless Products?](/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive.md): A practical comparison of the EMC Directive (2014/30/EU) vs the Radio Equipment Directive (RED) (2014/53/EU): when wireless products fall under RED. - [EMC Essential Requirements + Testing | Emissions, Immunity, Test Configurations, Evidence](/artifacts/eu/emc-directive/essential-requirements-and-testing.md): A deep EMC testing guide for Directive 2014/30/EU: translate essential requirements into emissions + immunity test plans. - [EMC Harmonised Standards Strategy | Presumption of Conformity, OJEU References, Deviations](/artifacts/eu/emc-directive/harmonized-standards-and-deviations.md): A deep guide to harmonised standards under the EMC Directive: how presumption of conformity works. - [EMC Test Plan Template | Directive 2014/30/EU Emissions + Immunity Plan (Audit-Ready)](/artifacts/eu/emc-directive/emc-test-plan-template.md): A structured EMC test plan template you can copy and adapt for CE marking: scope and configuration matrix, standards selection. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/emc-directive/conformity-assessment-and-documentation --- --- title: "EMC Directive Deadlines + Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/emc-directive/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/emc-directive/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A practical EMC compliance calendar for Directive 2014/30/EU with the legal baseline dates, recurring standards reviews." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EMC compliance calendar" - "EMC Directive deadlines" - "CE marking EMC timeline" - "harmonised standards review cadence" - "EMC DoC update" - "EMC technical file milestones" - "EMC language requirements calendar" - "supplier change control EMC" - "CE marking milestones" - "harmonised standards updates" - "language requirements" - "supplier change control" - "technical file readiness" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EMC Directive Deadlines + Compliance Calendar A practical EMC compliance calendar for Directive 2014/30/EU with the legal baseline dates, recurring standards reviews. *Calendar* *EU* ## EU EMC Directive Deadlines + Calendar A calendar-driven plan for predictable CE marking readiness and continuous compliance. Optimized for teams shipping hardware with variants, supplier changes, and standards updates. The EMC Directive does not give you a one-time compliance deadline for current products. It creates a continuing obligation for each apparatus you place on the market and for each fixed installation you support. Your real deadlines are the dates that define the legal baseline and the recurring gates that keep the evidence current when standards, suppliers, environments, or product variants change. ## Anchor date (legal baseline) Directive 2014/30/EU was adopted on 26 February 2014, published on 29 March 2014, and became applicable from 20 April 2016, replacing Directive 2004/108/EC. For product planning, the real operational requirement is to maintain conformity for every product version placed on the market and to keep the evidence current for 10 years after placing apparatus on the market. - Use 20 April 2016 as the legal application-date anchor in your technical-file narrative and executive reporting. - Tie CE-marking evidence to the exact version placed on the market, including hardware, firmware, accessories, and installation assumptions. - Use 19 December 2018 as the Commission-guide milestone and 18 February 2025 as the vehicle-guidance milestone when those guidance documents affect your scope analysis. ## Recurring calendar items (quarterly / per release) These are the calendar items that prevent surprise retesting and market surveillance findings. Treat them as recurring compliance controls with owners. - Quarterly: harmonised-standards review and impact assessment covering superseded standards and cessation dates. - Per hardware revision: pre-compliance scans and targeted immunity checks on changed subsystems. - Per major release or variant: formal emissions and immunity testing on worst-case configuration sets, plus Annex II or Annex III record refresh. - Per supplier change: EMC impact review for PSUs, clocks, enclosures, cable shielding, connectors, and RF modules. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU EMC Directive Deadlines + Calendar into an operational assessment Assessment Autopilot can take EU EMC Directive Deadlines + Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU EMC Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU EMC Directive Deadlines + Calendar](/solutions/assessment.md): Start from EU EMC Directive Deadlines + Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU EMC Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU EMC Directive Deadlines + Calendar. ## Country launch gates (language and documentation readiness) Member States can have language requirements for instructions, DoC availability, and contact details. Make language readiness a gate in your release plan - not an afterthought. - Maintain target-market language matrix and update it when expanding to new countries. - Version-control translations and link them to product release identifiers. - Ensure packaging and instructions reflect tested installation assumptions (cabling, grounding, shielding). ## Documentation milestones (per product family) Treat technical file and DoC as living artifacts tied to releases. This reduces audit time and market surveillance response time. Make evidence export a measurable capability. - Pre-test: test plan approved, configuration matrix frozen, standards selection recorded, and conformity route chosen. - Post-test: test report package archived, deviations closed, and retest triggers updated. - Pre-ship: technical-file index exported and reviewed, EU DoC issued, labeling and instructions approved, and language pack checked. - Post-ship: monitoring and field feedback captured, supplier or design changes logged, and 10-year evidence-retention controls verified. ## Primary sources - [European Commission - Electromagnetic compatibility (EMC) overview](https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards/electromagnetic-compatibility-emc_en?ref=sorena.io) - Commission overview including the 20 April 2016 applicability date and links to harmonised-standards references. - [Guide for the EMCD (Directive 2014/30/EU) - Commission guidance (DocsRoom)](https://ec.europa.eu/docsroom/documents/33601?ref=sorena.io) - Commission guide dated 19 December 2018, widely used as the practical interpretation layer for scope, testing, documentation, and fixed installations. - [EU/EEA language requirements summary for EMCD 2014/30/EU (DocsRoom)](https://ec.europa.eu/docsroom/documents/26690?ref=sorena.io) - Country-by-country language requirements summary for documentation and user information. - [European Commission - EMC Directive page (includes 2025 vehicle-equipment guidance)](https://single-market-economy.ec.europa.eu/sectors/electrical-and-electronic-engineering-industries-eei/electromagnetic-compatibility-emc-directive_en?ref=sorena.io) - Official Commission EMC Directive page linking the current guidance set, including the 18 February 2025 after-market and vehicle-equipment guidance. ## Related Topic Guides - [EMC Conformity Assessment + Documentation | Technical File, EU DoC, CE Marking, Language Rules](/artifacts/eu/emc-directive/conformity-assessment-and-documentation.md): A deep guide to EMC conformity assessment and documentation for Directive 2014/30/EU: how to structure the technical documentation/technical file. - [EMC Directive Applicability Test | Is Directive 2014/30/EU in Scope for Your Product?](/artifacts/eu/emc-directive/applicability-test.md): A practical EMC Directive applicability test: decide scope for Directive 2014/30/EU, classify apparatus vs fixed installations. - [EMC Directive Compliance Checklist | CE Marking, Test Plan, Technical File, EU DoC](/artifacts/eu/emc-directive/checklist.md): An audit-ready EMC Directive checklist (Directive 2014/30/EU): scope and classification (apparatus vs fixed installation), standards strategy. - [EMC Directive Compliance Program | Operating Model, Controls, Testing Cadence, Evidence](/artifacts/eu/emc-directive/compliance.md): A deep EMC Directive compliance playbook: build a role-scoped operating model for manufacturers/importers/distributors. - [EMC Directive Enforcement | Market Surveillance, Corrective Actions, Evidence to Reduce Risk](/artifacts/eu/emc-directive/penalties-and-fines.md): A practical EMC enforcement guide: how market surveillance works under EU product rules, what authorities typically request (technical file, test reports. - [EMC Directive FAQ | Scope, Testing, Technical File, EU DoC, Fixed Installations, Standards](/artifacts/eu/emc-directive/faq.md): High-signal answers to common EMC Directive questions: what is in scope, apparatus vs fixed installations, what to test (emissions + immunity). - [EMC Directive Requirements (2014/30/EU) | Essential Requirements, Operator Duties, Evidence Map](/artifacts/eu/emc-directive/requirements.md): An advanced EMC Directive requirements breakdown: essential requirements (emissions + immunity), obligations for manufacturers/importers/distributors. - [EMC Directive Scope + Borderline Cases | Apparatus vs Fixed Installations, Exclusions, "Inherently Benign"](/artifacts/eu/emc-directive/scope-and-borderline-cases.md): A deep scope guide for the EU EMC Directive (2014/30/EU): how to decide if your product is in scope. - [EMC Directive Timeline | Key Dates for Directive 2014/30/EU, Transition, Standards, Guidance](/artifacts/eu/emc-directive/timeline.md): A practical EMC Directive timeline: adoption and publication of Directive 2014/30/EU. - [EMC Directive vs Low Voltage Directive (LVD) | What Applies, What to Test, One Technical File](/artifacts/eu/emc-directive/emc-vs-low-voltage-directive.md): A practical comparison of the EU EMC Directive (2014/30/EU) vs the Low Voltage Directive (2014/35/EU): different objectives (EMC vs electrical safety). - [EMC Directive vs Radio Equipment Directive (RED) | Which Route Applies for Wireless Products?](/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive.md): A practical comparison of the EMC Directive (2014/30/EU) vs the Radio Equipment Directive (RED) (2014/53/EU): when wireless products fall under RED. - [EMC Essential Requirements + Testing | Emissions, Immunity, Test Configurations, Evidence](/artifacts/eu/emc-directive/essential-requirements-and-testing.md): A deep EMC testing guide for Directive 2014/30/EU: translate essential requirements into emissions + immunity test plans. - [EMC Harmonised Standards Strategy | Presumption of Conformity, OJEU References, Deviations](/artifacts/eu/emc-directive/harmonized-standards-and-deviations.md): A deep guide to harmonised standards under the EMC Directive: how presumption of conformity works. - [EMC Test Plan Template | Directive 2014/30/EU Emissions + Immunity Plan (Audit-Ready)](/artifacts/eu/emc-directive/emc-test-plan-template.md): A structured EMC test plan template you can copy and adapt for CE marking: scope and configuration matrix, standards selection. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/emc-directive/deadlines-and-compliance-calendar --- --- title: "EMC Test Plan Template" canonical_url: "https://www.sorena.io/artifacts/eu/emc-directive/emc-test-plan-template" source_url: "https://www.sorena.io/artifacts/eu/emc-directive/emc-test-plan-template" author: "Sorena AI" description: "A structured EMC test plan template you can copy and adapt for CE marking: scope and configuration matrix, standards selection." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EMC test plan template" - "EMC test plan for CE marking" - "Directive 2014/30/EU test plan" - "emissions immunity test plan template" - "EMC functional criteria" - "EMC configuration matrix" - "EMC test evidence technical file" - "emissions test plan" - "immunity test plan" - "configuration matrix" - "functional criteria" - "technical file evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EMC Test Plan Template A structured EMC test plan template you can copy and adapt for CE marking: scope and configuration matrix, standards selection. *Template* *EU* ## EU EMC Directive EMC Test Plan Template A structured template for emissions + immunity testing with traceable evidence outputs. Use it to reduce retesting loops and to make technical file evidence reproducible. This template is designed to be filled, versioned, and attached to your technical documentation. The main goal is traceability: every test case should link to a requirement, a standard clause, a configuration, and an evidence artifact. If you keep this template current, audits and market surveillance responses become fast and consistent. ## 1) Scope and product definition Define exactly what is covered by the test plan. Ambiguity here causes most retesting. Keep this section aligned with labeling, SKUs, and what you place on the market. - Product name/model/SKU(s) and intended use environment (residential/commercial/industrial). - Ports and interfaces list (power, I/O, network, RF modules, accessory ecosystem). - Apparatus vs fixed installation classification and rationale (link to scope record). - Variant and accessory coverage statement: what is covered and what is excluded. ## 2) Configuration matrix (worst-case definition) Define the worst-case configurations you will test - operating modes, cables, loads, and enclosures. Make it easy for a lab to execute consistently. - Operating modes: maximum activity modes, high-speed interfaces, peak power states, firmware configuration. - Cables and accessories: lengths, shielding, grounding strategy, external modules, and typical installation routing assumptions. - Power conditions: PSU variants, loads, mains variants, battery/adapter modes. - Acceptance criteria per configuration: what "pass" means and allowed performance degradation (if any). ## 3) Standards strategy (presumption of conformity plan) List harmonised standards you apply and why they are appropriate. If you deviate, define the deviation and compensating tests explicitly. - Harmonised standards list (with versions) and mapping to essential requirements. - OJEU reference check date and responsibility owner. - Deviation register: clause not followed -> justification -> alternative method -> evidence artifact. ## 4) Emissions test cases (plan) Define emissions tests relevant to your ports and environment. Include test setups, limits, and evidence outputs. Keep test cases in a table format so it can be exported and tracked. - Test case table columns (recommended): ID, standard clause, setup, configuration, limit, pass/fail criteria, evidence output. - Required evidence: plots/results, configuration record, photos, equipment calibration references, deviations. - Retest triggers: what design changes require repeating which emissions cases. ## 5) Immunity test cases (plan) Define immunity tests and the functional criteria you will apply. Functional criteria must be product-specific and measurable. Plan for failure handling and engineering iteration loops. - Functional criteria: define acceptable behavior during and after disturbances (what user impact is allowed). - Test case table: ID, standard clause, disturbance level, setup, configuration, functional criteria, evidence output. - Failure protocol: how failures are recorded, triaged, mitigated, and retested. ## 6) Evidence outputs and technical file linkage Define what artifacts this test plan produces and where they live in the technical documentation. This makes the EU DoC and audit response fast and consistent. - Test report package: emissions + immunity results, configurations, photos, deviations and retest logs. - Technical documentation update list: what sections are updated after the test campaign. - EU DoC inputs: standards references and controlled document identifiers. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU EMC Directive EMC Test Plan Template in one governed evidence system SSOT can take EU EMC Directive EMC Test Plan Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU EMC Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU EMC Directive EMC Test Plan Template](/solutions/ssot.md): Start from EU EMC Directive EMC Test Plan Template and keep documents, evidence, and control records in one governed system. - [Talk through EU EMC Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU EMC Directive EMC Test Plan Template. ## Primary sources - [Guide for the EMCD (Directive 2014/30/EU) - Commission guidance (DocsRoom)](https://ec.europa.eu/docsroom/documents/33601?ref=sorena.io) - Commission guidance describing EMC assessment approach, documentation expectations, and test planning considerations. - [European Commission - Harmonised standards for EMC (official references)](https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards/electromagnetic-compatibility-emc_en?ref=sorena.io) - Official entry point for harmonised standards referenced under the EMC Directive. ## Related Topic Guides - [EMC Conformity Assessment + Documentation | Technical File, EU DoC, CE Marking, Language Rules](/artifacts/eu/emc-directive/conformity-assessment-and-documentation.md): A deep guide to EMC conformity assessment and documentation for Directive 2014/30/EU: how to structure the technical documentation/technical file. - [EMC Directive Applicability Test | Is Directive 2014/30/EU in Scope for Your Product?](/artifacts/eu/emc-directive/applicability-test.md): A practical EMC Directive applicability test: decide scope for Directive 2014/30/EU, classify apparatus vs fixed installations. - [EMC Directive Compliance Checklist | CE Marking, Test Plan, Technical File, EU DoC](/artifacts/eu/emc-directive/checklist.md): An audit-ready EMC Directive checklist (Directive 2014/30/EU): scope and classification (apparatus vs fixed installation), standards strategy. - [EMC Directive Compliance Program | Operating Model, Controls, Testing Cadence, Evidence](/artifacts/eu/emc-directive/compliance.md): A deep EMC Directive compliance playbook: build a role-scoped operating model for manufacturers/importers/distributors. - [EMC Directive Deadlines + Compliance Calendar | CE Marking Milestones, Standards Updates, Language Gates](/artifacts/eu/emc-directive/deadlines-and-compliance-calendar.md): A practical EMC compliance calendar for Directive 2014/30/EU with the legal baseline dates, recurring standards reviews. - [EMC Directive Enforcement | Market Surveillance, Corrective Actions, Evidence to Reduce Risk](/artifacts/eu/emc-directive/penalties-and-fines.md): A practical EMC enforcement guide: how market surveillance works under EU product rules, what authorities typically request (technical file, test reports. - [EMC Directive FAQ | Scope, Testing, Technical File, EU DoC, Fixed Installations, Standards](/artifacts/eu/emc-directive/faq.md): High-signal answers to common EMC Directive questions: what is in scope, apparatus vs fixed installations, what to test (emissions + immunity). - [EMC Directive Requirements (2014/30/EU) | Essential Requirements, Operator Duties, Evidence Map](/artifacts/eu/emc-directive/requirements.md): An advanced EMC Directive requirements breakdown: essential requirements (emissions + immunity), obligations for manufacturers/importers/distributors. - [EMC Directive Scope + Borderline Cases | Apparatus vs Fixed Installations, Exclusions, "Inherently Benign"](/artifacts/eu/emc-directive/scope-and-borderline-cases.md): A deep scope guide for the EU EMC Directive (2014/30/EU): how to decide if your product is in scope. - [EMC Directive Timeline | Key Dates for Directive 2014/30/EU, Transition, Standards, Guidance](/artifacts/eu/emc-directive/timeline.md): A practical EMC Directive timeline: adoption and publication of Directive 2014/30/EU. - [EMC Directive vs Low Voltage Directive (LVD) | What Applies, What to Test, One Technical File](/artifacts/eu/emc-directive/emc-vs-low-voltage-directive.md): A practical comparison of the EU EMC Directive (2014/30/EU) vs the Low Voltage Directive (2014/35/EU): different objectives (EMC vs electrical safety). - [EMC Directive vs Radio Equipment Directive (RED) | Which Route Applies for Wireless Products?](/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive.md): A practical comparison of the EMC Directive (2014/30/EU) vs the Radio Equipment Directive (RED) (2014/53/EU): when wireless products fall under RED. - [EMC Essential Requirements + Testing | Emissions, Immunity, Test Configurations, Evidence](/artifacts/eu/emc-directive/essential-requirements-and-testing.md): A deep EMC testing guide for Directive 2014/30/EU: translate essential requirements into emissions + immunity test plans. - [EMC Harmonised Standards Strategy | Presumption of Conformity, OJEU References, Deviations](/artifacts/eu/emc-directive/harmonized-standards-and-deviations.md): A deep guide to harmonised standards under the EMC Directive: how presumption of conformity works. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/emc-directive/emc-test-plan-template --- --- title: "EMC Directive vs Low Voltage Directive (LVD)" canonical_url: "https://www.sorena.io/artifacts/eu/emc-directive/emc-vs-low-voltage-directive" source_url: "https://www.sorena.io/artifacts/eu/emc-directive/emc-vs-low-voltage-directive" author: "Sorena AI" description: "A practical comparison of the EU EMC Directive (2014/30/EU) vs the Low Voltage Directive (2014/35/EU): different objectives (EMC vs electrical safety)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EMC Directive vs LVD" - "2014/30/EU vs 2014/35/EU" - "EMC and electrical safety CE marking" - "do I need EMC and LVD" - "one technical file EMC LVD" - "EU Declaration of Conformity EMC LVD" - "EMC vs LVD" - "Directive 2014/30/EU" - "Directive 2014/35/EU" - "CE marking" - "technical file" - "EU Declaration of Conformity" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EMC Directive vs Low Voltage Directive (LVD) A practical comparison of the EU EMC Directive (2014/30/EU) vs the Low Voltage Directive (2014/35/EU): different objectives (EMC vs electrical safety). *Comparison* *EU* ## EU EMC Directive vs Low Voltage Directive Two directives, different objectives - one product compliance program. Build one test plan and one evidence index that satisfies both without duplicated work. Many products must comply with both the EMC Directive and the Low Voltage Directive. The key is to understand that these directives solve different problems: EMC is about electromagnetic disturbance and immunity; LVD is about electrical safety. You can (and should) build one integrated compliance program: one configuration matrix, one evidence index, and one EU Declaration of Conformity referencing all applicable directives and standards. ## Core difference (what each directive is trying to prevent) EMC Directive: ensure equipment does not disturb other equipment and is not unduly affected by electromagnetic disturbance. LVD: ensure electrical equipment is safe within its voltage scope (hazards like electric shock, fire, and mechanical risks associated with electrical design). - EMC deliverables: emissions + immunity testing evidence, installation assumptions, and EMC-related instructions. - LVD deliverables: safety risk assessment, electrical safety test evidence, and safety instructions/markings. - Both: technical documentation + EU DoC + CE marking and traceability. *Recommended next step* *Placement: after the comparison section* ## Use EU EMC Directive vs Low Voltage Directive as a cited research workflow Research Copilot can take EU EMC Directive vs Low Voltage Directive from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU EMC Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU EMC Directive vs Low Voltage Directive](/solutions/research-copilot.md): Start from EU EMC Directive vs Low Voltage Directive and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU EMC Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU EMC Directive vs Low Voltage Directive. ## Overlap in practice (how to avoid duplicated work) The directives overlap in your product lifecycle even if their objectives differ: both require controlled design decisions, standards selection, testing, and documentation. Integrate the workstreams early so one set of product variants and configuration controls drives both EMC and safety evidence. - One configuration matrix: variants, cables, PSUs, firmware modes, and accessories that affect EMC and safety. - One standards strategy: EMC harmonised standards + LVD harmonised standards tracked together with version control. - One evidence index: requirement -> standard -> test -> artifact with owners and review cadence. ## Documentation and DoC strategy (one DoC, many directives) Your EU Declaration of Conformity should list all applicable EU harmonisation legislation for the product. The technical file should contain the evidence supporting each directive, organized so audits and market surveillance responses are fast. - DoC: list EMC Directive, LVD, and any other applicable directives (e.g., RED) and reference applied harmonised standards. - Technical documentation: separate evidence sections per directive but keep shared artifacts (configuration control, BOM, change control) centralized. - Change control: define retest triggers for EMC and for safety; keep them aligned to release gates. ## Common pitfalls (and how to avoid them) Most pitfalls come from treating CE marking as "paperwork after testing" rather than a controlled lifecycle. Avoid these early and you'll save weeks of rework. - Testing a non-final configuration (wrong PSU/cables/firmware) -> invalid evidence for both directives. - Referencing superseded standards without tracking cessation dates (EMC) -> losing presumption of conformity. - DoC inconsistency: directives referenced don't match the evidence set in the technical file. - Missing language readiness for instructions and DoC availability in target markets. ## Primary sources - [Directive 2014/30/EU - EMC Directive (official text)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32014L0030&ref=sorena.io) - EMC legal framework and essential requirements. - [Directive 2014/35/EU - Low Voltage Directive (official text)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32014L0035&ref=sorena.io) - LVD legal framework for electrical safety within voltage scope. - [EU Declaration of Conformity (DoC) template example - EMC ADCO (DocsRoom)](https://ec.europa.eu/docsroom/documents/23962/attachments/1/translations/en/renditions/native?ref=sorena.io) - Template illustrating a structured DoC format listing applicable directives and standards. ## Related Topic Guides - [EMC Conformity Assessment + Documentation | Technical File, EU DoC, CE Marking, Language Rules](/artifacts/eu/emc-directive/conformity-assessment-and-documentation.md): A deep guide to EMC conformity assessment and documentation for Directive 2014/30/EU: how to structure the technical documentation/technical file. - [EMC Directive Applicability Test | Is Directive 2014/30/EU in Scope for Your Product?](/artifacts/eu/emc-directive/applicability-test.md): A practical EMC Directive applicability test: decide scope for Directive 2014/30/EU, classify apparatus vs fixed installations. - [EMC Directive Compliance Checklist | CE Marking, Test Plan, Technical File, EU DoC](/artifacts/eu/emc-directive/checklist.md): An audit-ready EMC Directive checklist (Directive 2014/30/EU): scope and classification (apparatus vs fixed installation), standards strategy. - [EMC Directive Compliance Program | Operating Model, Controls, Testing Cadence, Evidence](/artifacts/eu/emc-directive/compliance.md): A deep EMC Directive compliance playbook: build a role-scoped operating model for manufacturers/importers/distributors. - [EMC Directive Deadlines + Compliance Calendar | CE Marking Milestones, Standards Updates, Language Gates](/artifacts/eu/emc-directive/deadlines-and-compliance-calendar.md): A practical EMC compliance calendar for Directive 2014/30/EU with the legal baseline dates, recurring standards reviews. - [EMC Directive Enforcement | Market Surveillance, Corrective Actions, Evidence to Reduce Risk](/artifacts/eu/emc-directive/penalties-and-fines.md): A practical EMC enforcement guide: how market surveillance works under EU product rules, what authorities typically request (technical file, test reports. - [EMC Directive FAQ | Scope, Testing, Technical File, EU DoC, Fixed Installations, Standards](/artifacts/eu/emc-directive/faq.md): High-signal answers to common EMC Directive questions: what is in scope, apparatus vs fixed installations, what to test (emissions + immunity). - [EMC Directive Requirements (2014/30/EU) | Essential Requirements, Operator Duties, Evidence Map](/artifacts/eu/emc-directive/requirements.md): An advanced EMC Directive requirements breakdown: essential requirements (emissions + immunity), obligations for manufacturers/importers/distributors. - [EMC Directive Scope + Borderline Cases | Apparatus vs Fixed Installations, Exclusions, "Inherently Benign"](/artifacts/eu/emc-directive/scope-and-borderline-cases.md): A deep scope guide for the EU EMC Directive (2014/30/EU): how to decide if your product is in scope. - [EMC Directive Timeline | Key Dates for Directive 2014/30/EU, Transition, Standards, Guidance](/artifacts/eu/emc-directive/timeline.md): A practical EMC Directive timeline: adoption and publication of Directive 2014/30/EU. - [EMC Directive vs Radio Equipment Directive (RED) | Which Route Applies for Wireless Products?](/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive.md): A practical comparison of the EMC Directive (2014/30/EU) vs the Radio Equipment Directive (RED) (2014/53/EU): when wireless products fall under RED. - [EMC Essential Requirements + Testing | Emissions, Immunity, Test Configurations, Evidence](/artifacts/eu/emc-directive/essential-requirements-and-testing.md): A deep EMC testing guide for Directive 2014/30/EU: translate essential requirements into emissions + immunity test plans. - [EMC Harmonised Standards Strategy | Presumption of Conformity, OJEU References, Deviations](/artifacts/eu/emc-directive/harmonized-standards-and-deviations.md): A deep guide to harmonised standards under the EMC Directive: how presumption of conformity works. - [EMC Test Plan Template | Directive 2014/30/EU Emissions + Immunity Plan (Audit-Ready)](/artifacts/eu/emc-directive/emc-test-plan-template.md): A structured EMC test plan template you can copy and adapt for CE marking: scope and configuration matrix, standards selection. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/emc-directive/emc-vs-low-voltage-directive --- --- title: "EMC Directive vs Radio Equipment Directive (RED)" canonical_url: "https://www.sorena.io/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive" source_url: "https://www.sorena.io/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive" author: "Sorena AI" description: "A practical comparison of the EMC Directive (2014/30/EU) vs the Radio Equipment Directive (RED) (2014/53/EU): when wireless products fall under RED." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EMC Directive vs RED" - "Radio Equipment Directive vs EMC Directive" - "wireless product CE marking route" - "RED EMC requirements" - "radio equipment emissions immunity testing" - "one technical file RED EMC" - "EMC vs RED" - "Radio Equipment Directive" - "wireless product compliance" - "CE marking" - "technical file" - "emissions immunity" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EMC Directive vs Radio Equipment Directive (RED) A practical comparison of the EMC Directive (2014/30/EU) vs the Radio Equipment Directive (RED) (2014/53/EU): when wireless products fall under RED. *Comparison* *EU* ## EU EMC Directive vs Radio Equipment Directive For wireless products, RED usually drives the route - but EMC evidence still matters. Build one testing and documentation program that covers radio and EMC behaviors. If your product includes radio functionality, the Radio Equipment Directive (RED) often becomes the primary route for CE marking. That doesn't eliminate EMC work - it changes how you structure it. The practical goal is a single technical file and evidence index: radio requirements, EMC behavior, and the chosen standards strategy are documented consistently without duplicating test and documentation work. ## When RED drives the route (wireless products) Wireless products are typically regulated under RED, which includes essential requirements relevant to EMC behavior and interference. Use Commission guidance to avoid double-classifying and double-documenting. - If the product is radio equipment, start from RED route assessment and then map EMC evidence into the same technical file. - Avoid separate "EMC file" and "RED file" unless your organization has a strong evidence index system; duplication creates inconsistencies. - Treat co-existence and interference risk as part of the functional safety and customer experience narrative. ## Testing strategy (what changes for radio products) Radio products need a broader testing view: emissions and immunity still matter, but radio performance, co-existence, and interference are often the hardest production problems. Plan worst-case configurations including antennas, cabling, and firmware radio modes. - Define radio operating modes and frequency bands; treat them as test configurations. - Test worst-case emissions configurations (ports, cables, antennas, enclosures, and power states). - Plan immunity and functional criteria that reflect radio service continuity and safe failure modes. - Keep evidence that links radio performance constraints to user instructions and installation guidance. ## Documentation strategy (one technical file, one DoC) Your DoC should reference all applicable directives and standards. For radio products, RED is usually the primary directive listed, but your evidence pack still contains EMC-relevant results and assumptions. The key is consistency: scope, configuration, standards versions, and test evidence must match. - One configuration matrix drives both EMC and radio test evidence (variants, antennas, accessories, firmware). - One evidence index links requirements to test reports and design decisions. - Instructions include installation constraints that are necessary to achieve EMC and radio performance. ## Common pitfalls Wireless products fail compliance programs when configuration control is weak or when radio-related assumptions aren't reflected in evidence and instructions. Avoid these early to prevent late-stage redesigns. - Testing a lab-only antenna configuration that doesn't match shipped product. - Ignoring firmware radio mode impact on emissions and immunity outcomes. - Not documenting installation constraints that are necessary for real-world EMC/radio performance. - Splitting evidence into multiple disconnected files that can't be reconciled during audits. *Recommended next step* *Placement: after the comparison section* ## Use EU EMC Directive vs Radio Equipment Directive as a cited research workflow Research Copilot can take EU EMC Directive vs Radio Equipment Directive from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU EMC Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU EMC Directive vs Radio Equipment Directive](/solutions/research-copilot.md): Start from EU EMC Directive vs Radio Equipment Directive and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU EMC Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU EMC Directive vs Radio Equipment Directive. ## Primary sources - [Directive 2014/53/EU - Radio Equipment Directive (RED) (official text)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32014L0053&ref=sorena.io) - Primary legal text for radio equipment and essential requirements impacting interference and EMC behavior. - [Directive 2014/30/EU - EMC Directive (official text)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32014L0030&ref=sorena.io) - EMC essential requirements and legal framework. - [Guide for the EMCD (Directive 2014/30/EU) - Commission guidance (DocsRoom)](https://ec.europa.eu/docsroom/documents/33601?ref=sorena.io) - Commission guidance that discusses scope boundaries and overlap concepts with other regimes. ## Related Topic Guides - [EMC Conformity Assessment + Documentation | Technical File, EU DoC, CE Marking, Language Rules](/artifacts/eu/emc-directive/conformity-assessment-and-documentation.md): A deep guide to EMC conformity assessment and documentation for Directive 2014/30/EU: how to structure the technical documentation/technical file. - [EMC Directive Applicability Test | Is Directive 2014/30/EU in Scope for Your Product?](/artifacts/eu/emc-directive/applicability-test.md): A practical EMC Directive applicability test: decide scope for Directive 2014/30/EU, classify apparatus vs fixed installations. - [EMC Directive Compliance Checklist | CE Marking, Test Plan, Technical File, EU DoC](/artifacts/eu/emc-directive/checklist.md): An audit-ready EMC Directive checklist (Directive 2014/30/EU): scope and classification (apparatus vs fixed installation), standards strategy. - [EMC Directive Compliance Program | Operating Model, Controls, Testing Cadence, Evidence](/artifacts/eu/emc-directive/compliance.md): A deep EMC Directive compliance playbook: build a role-scoped operating model for manufacturers/importers/distributors. - [EMC Directive Deadlines + Compliance Calendar | CE Marking Milestones, Standards Updates, Language Gates](/artifacts/eu/emc-directive/deadlines-and-compliance-calendar.md): A practical EMC compliance calendar for Directive 2014/30/EU with the legal baseline dates, recurring standards reviews. - [EMC Directive Enforcement | Market Surveillance, Corrective Actions, Evidence to Reduce Risk](/artifacts/eu/emc-directive/penalties-and-fines.md): A practical EMC enforcement guide: how market surveillance works under EU product rules, what authorities typically request (technical file, test reports. - [EMC Directive FAQ | Scope, Testing, Technical File, EU DoC, Fixed Installations, Standards](/artifacts/eu/emc-directive/faq.md): High-signal answers to common EMC Directive questions: what is in scope, apparatus vs fixed installations, what to test (emissions + immunity). - [EMC Directive Requirements (2014/30/EU) | Essential Requirements, Operator Duties, Evidence Map](/artifacts/eu/emc-directive/requirements.md): An advanced EMC Directive requirements breakdown: essential requirements (emissions + immunity), obligations for manufacturers/importers/distributors. - [EMC Directive Scope + Borderline Cases | Apparatus vs Fixed Installations, Exclusions, "Inherently Benign"](/artifacts/eu/emc-directive/scope-and-borderline-cases.md): A deep scope guide for the EU EMC Directive (2014/30/EU): how to decide if your product is in scope. - [EMC Directive Timeline | Key Dates for Directive 2014/30/EU, Transition, Standards, Guidance](/artifacts/eu/emc-directive/timeline.md): A practical EMC Directive timeline: adoption and publication of Directive 2014/30/EU. - [EMC Directive vs Low Voltage Directive (LVD) | What Applies, What to Test, One Technical File](/artifacts/eu/emc-directive/emc-vs-low-voltage-directive.md): A practical comparison of the EU EMC Directive (2014/30/EU) vs the Low Voltage Directive (2014/35/EU): different objectives (EMC vs electrical safety). - [EMC Essential Requirements + Testing | Emissions, Immunity, Test Configurations, Evidence](/artifacts/eu/emc-directive/essential-requirements-and-testing.md): A deep EMC testing guide for Directive 2014/30/EU: translate essential requirements into emissions + immunity test plans. - [EMC Harmonised Standards Strategy | Presumption of Conformity, OJEU References, Deviations](/artifacts/eu/emc-directive/harmonized-standards-and-deviations.md): A deep guide to harmonised standards under the EMC Directive: how presumption of conformity works. - [EMC Test Plan Template | Directive 2014/30/EU Emissions + Immunity Plan (Audit-Ready)](/artifacts/eu/emc-directive/emc-test-plan-template.md): A structured EMC test plan template you can copy and adapt for CE marking: scope and configuration matrix, standards selection. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive --- --- title: "EMC Essential Requirements + Testing" canonical_url: "https://www.sorena.io/artifacts/eu/emc-directive/essential-requirements-and-testing" source_url: "https://www.sorena.io/artifacts/eu/emc-directive/essential-requirements-and-testing" author: "Sorena AI" description: "A deep EMC testing guide for Directive 2014/30/EU: translate essential requirements into emissions + immunity test plans." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EMC testing" - "EMC emissions and immunity testing" - "Directive 2014/30/EU testing" - "EMC test plan" - "EMC worst case configuration" - "EMC technical documentation test evidence" - "EMC harmonised standards testing" - "EMC CE marking test report" - "emissions testing" - "immunity testing" - "harmonised standards" - "technical documentation" - "EU Declaration of Conformity" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EMC Essential Requirements + Testing A deep EMC testing guide for Directive 2014/30/EU: translate essential requirements into emissions + immunity test plans. *Testing Guide* *EU* ## EU EMC Directive Essential Requirements + Testing Translate essential requirements into a test plan that produces defensible evidence. Built from Directive 2014/30/EU + Commission guidance on EMC assessment and documentation. EMC compliance is not "run a lab test once". It's a controlled engineering process: define assumptions, pick standards, test worst-case configurations, capture deviations, and produce evidence that can be reproduced later. This page shows how to translate the EMC Directive's essential requirements into emissions + immunity testing and an audit-ready documentation pack. ## What the essential requirements mean (in test terms) The EMC Directive is outcome-focused. In practice, you implement it by proving two properties: your product's emissions are controlled, and your product is adequately immune to expected disturbances. Testing must match intended environment and installation assumptions; otherwise, results are not meaningful. - Emissions: conducted + radiated emissions relevant to your ports and intended use environment. - Immunity: ESD, radiated immunity, EFT/burst, surge, conducted immunity, voltage dips/interruptions (as applicable). - Functional criteria: define pass/fail criteria (A/B/C-style behavior) and document what constitutes "operates as intended". *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU EMC Directive Essential Requirements + Testing into an operational assessment Assessment Autopilot can take EU EMC Directive Essential Requirements + Testing from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU EMC Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU EMC Directive Essential Requirements + Testing](/solutions/assessment.md): Start from EU EMC Directive Essential Requirements + Testing and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU EMC Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU EMC Directive Essential Requirements + Testing. ## Configuration control (the #1 driver of retesting) Most "failures" happen because the lab tested a configuration that doesn't represent worst case (or doesn't match shipped product). Define a configuration matrix before testing and link it to SKUs and installation instructions. - Operating modes: max duty cycles, high-speed interfaces enabled, peak loads, worst-case firmware features. - Ports and cables: worst-case cable lengths, shield grounding strategy, cable routing assumptions, external accessories. - Power supplies and loads: final PSU variant, typical + worst-case loads, battery/adapter modes. - Enclosure and mechanical configuration: final enclosure, ventilation openings, optional modules and add-ons. ## Standards strategy (presumption of conformity vs custom justification) Using harmonised standards referenced in the Official Journal typically gives presumption of conformity for the corresponding essential requirements. If you don't (or can't) apply a harmonised standard, you need stronger justification and a more explicit EMC assessment record. - Pick standards that match your product category and intended environment (residential vs industrial). - Track standard versions and OJEU references; manage superseded standards and cessation dates in your compliance calendar. - If deviating: document why, what alternative technical solution you used, and how test evidence proves equivalence. ## Practical test workflow (fast path) Use this workflow to reduce iteration loops and avoid expensive late-stage surprises. Treat lab time as scarce: pre-compliance and test readiness pays for itself. - Pre-compliance: bench scans, cable/grounding experiments, firmware mode toggles, and early design mitigations. - Formal test plan: map each requirement -> standard clause -> setup -> acceptance criteria -> evidence artifact. - Lab execution: record config, photos, calibration references, and any deviations and retests. - Post-test: compile test report, deviation register, and update technical file and EU DoC references. ## Evidence pack (what market surveillance and customers ask for) Your defense is evidence. A pass report without configuration traceability is weak evidence. Build an evidence index that links requirements to test setups and final product variants. - EMC assessment record: risk analysis, assumptions, standards applied, and acceptance criteria. - Test reports: emissions + immunity results, configurations tested, photos, and deviation handling. - Technical documentation: design mitigations, variant coverage, and change control triggers for re-test. - EU Declaration of Conformity: correct directive references + harmonised standards references. ## Primary sources - [Directive 2014/30/EU - EMC Directive (official text)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32014L0030&ref=sorena.io) - Essential requirements and legal framework for EMC conformity. - [Guide for the EMCD (Directive 2014/30/EU) - Commission guidance (DocsRoom)](https://ec.europa.eu/docsroom/documents/33601?ref=sorena.io) - Commission guidance on EMC assessment, test planning, technical documentation, and compliance information. - [European Commission - Harmonised standards for EMC (references + updates)](https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards/electromagnetic-compatibility-emc_en?ref=sorena.io) - Official entry point for harmonised standards references under the EMC Directive. ## Related Topic Guides - [EMC Conformity Assessment + Documentation | Technical File, EU DoC, CE Marking, Language Rules](/artifacts/eu/emc-directive/conformity-assessment-and-documentation.md): A deep guide to EMC conformity assessment and documentation for Directive 2014/30/EU: how to structure the technical documentation/technical file. - [EMC Directive Applicability Test | Is Directive 2014/30/EU in Scope for Your Product?](/artifacts/eu/emc-directive/applicability-test.md): A practical EMC Directive applicability test: decide scope for Directive 2014/30/EU, classify apparatus vs fixed installations. - [EMC Directive Compliance Checklist | CE Marking, Test Plan, Technical File, EU DoC](/artifacts/eu/emc-directive/checklist.md): An audit-ready EMC Directive checklist (Directive 2014/30/EU): scope and classification (apparatus vs fixed installation), standards strategy. - [EMC Directive Compliance Program | Operating Model, Controls, Testing Cadence, Evidence](/artifacts/eu/emc-directive/compliance.md): A deep EMC Directive compliance playbook: build a role-scoped operating model for manufacturers/importers/distributors. - [EMC Directive Deadlines + Compliance Calendar | CE Marking Milestones, Standards Updates, Language Gates](/artifacts/eu/emc-directive/deadlines-and-compliance-calendar.md): A practical EMC compliance calendar for Directive 2014/30/EU with the legal baseline dates, recurring standards reviews. - [EMC Directive Enforcement | Market Surveillance, Corrective Actions, Evidence to Reduce Risk](/artifacts/eu/emc-directive/penalties-and-fines.md): A practical EMC enforcement guide: how market surveillance works under EU product rules, what authorities typically request (technical file, test reports. - [EMC Directive FAQ | Scope, Testing, Technical File, EU DoC, Fixed Installations, Standards](/artifacts/eu/emc-directive/faq.md): High-signal answers to common EMC Directive questions: what is in scope, apparatus vs fixed installations, what to test (emissions + immunity). - [EMC Directive Requirements (2014/30/EU) | Essential Requirements, Operator Duties, Evidence Map](/artifacts/eu/emc-directive/requirements.md): An advanced EMC Directive requirements breakdown: essential requirements (emissions + immunity), obligations for manufacturers/importers/distributors. - [EMC Directive Scope + Borderline Cases | Apparatus vs Fixed Installations, Exclusions, "Inherently Benign"](/artifacts/eu/emc-directive/scope-and-borderline-cases.md): A deep scope guide for the EU EMC Directive (2014/30/EU): how to decide if your product is in scope. - [EMC Directive Timeline | Key Dates for Directive 2014/30/EU, Transition, Standards, Guidance](/artifacts/eu/emc-directive/timeline.md): A practical EMC Directive timeline: adoption and publication of Directive 2014/30/EU. - [EMC Directive vs Low Voltage Directive (LVD) | What Applies, What to Test, One Technical File](/artifacts/eu/emc-directive/emc-vs-low-voltage-directive.md): A practical comparison of the EU EMC Directive (2014/30/EU) vs the Low Voltage Directive (2014/35/EU): different objectives (EMC vs electrical safety). - [EMC Directive vs Radio Equipment Directive (RED) | Which Route Applies for Wireless Products?](/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive.md): A practical comparison of the EMC Directive (2014/30/EU) vs the Radio Equipment Directive (RED) (2014/53/EU): when wireless products fall under RED. - [EMC Harmonised Standards Strategy | Presumption of Conformity, OJEU References, Deviations](/artifacts/eu/emc-directive/harmonized-standards-and-deviations.md): A deep guide to harmonised standards under the EMC Directive: how presumption of conformity works. - [EMC Test Plan Template | Directive 2014/30/EU Emissions + Immunity Plan (Audit-Ready)](/artifacts/eu/emc-directive/emc-test-plan-template.md): A structured EMC test plan template you can copy and adapt for CE marking: scope and configuration matrix, standards selection. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/emc-directive/essential-requirements-and-testing --- --- title: "EMC Directive FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/emc-directive/faq" source_url: "https://www.sorena.io/artifacts/eu/emc-directive/faq" author: "Sorena AI" description: "High-signal answers to common EMC Directive questions: what is in scope, apparatus vs fixed installations, what to test (emissions + immunity)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EMC Directive FAQ" - "apparatus vs fixed installation EMC" - "what EMC tests are required" - "emissions immunity testing EMC" - "EMC technical file contents" - "EU Declaration of Conformity EMC" - "harmonised standards EMC presumption of conformity" - "EMC CE marking" - "apparatus vs fixed installation" - "EMC testing" - "EU Declaration of Conformity" - "technical documentation" - "harmonised standards" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EMC Directive FAQ High-signal answers to common EMC Directive questions: what is in scope, apparatus vs fixed installations, what to test (emissions + immunity). *FAQ* *EU* ## EU EMC Directive FAQ Practical answers with clear next steps for CE marking readiness. Grounded in Directive 2014/30/EU and Commission guidance resources. This FAQ is for teams building and shipping products. Each answer focuses on what to do next and what evidence to keep. For formal interpretation, validate against the Directive, Commission guidance, and the competent authority position in your target market. ## Does the EMC Directive apply to my product? Most electrical/electronic equipment that can generate or be affected by electromagnetic disturbance is in scope unless excluded or covered primarily by another regime. Scope hinges on how the product is placed on the market and how it's used and installed. - Run the applicability test and save the outcome in the technical file. - Classify apparatus vs fixed installation early; it changes your obligations and documentation structure. ## What do we actually test for EMC? Operationally, essential requirements become emissions and immunity test workstreams, with product-specific functional criteria. Your test plan must define worst-case configurations (modes, cables, loads, enclosure versions). - Start from a standards strategy and test plan template before booking lab time. - Treat configuration control as a compliance control: it prevents invalid evidence. ## How do harmonised standards help (presumption of conformity)? Applying harmonised standards referenced in the Official Journal can give presumption of conformity for the covered essential requirements. Standards change; you must monitor updates and manage superseded standards and cessation dates. - Maintain an OJEU monitoring cadence and a standards update log. - If you deviate, document it and compensate with stronger EMC assessment evidence. ## What must be in the technical file and EU Declaration of Conformity (DoC)? Your technical file should be an evidence index: product identity, standards selection, EMC assessment, test evidence, conformity-assessment route, and change-control rules. Your EU DoC should list the applicable directives and standards correctly, and if Annex III is used it should line up with the notified-body certificate details. - Use the Commission DoC template structure and link it to the evidence index. - Retain the manufacturer technical documentation and EU DoC, and the importer copy of the DoC, for 10 years after the apparatus is placed on the market. - Make evidence export a measurable capability for market-surveillance requests. ## Do we need a notified body? Usually no. The EMC Directive does not require mandatory third-party involvement for the normal Annex II internal-production-control route. A notified body becomes relevant only if you choose Annex III, which adds EU-type examination followed by conformity to type based on internal production control. - Use Annex II when you can justify conformity through your own EMC assessment, standards strategy, and test evidence. - Use Annex III when you want a notified-body EU-type examination certificate because the case is complex or you are not fully relying on harmonised standards. ## Do language requirements matter? Yes. Language requirements vary by country and often apply to instructions, contact details, and DoC availability. Treat language readiness as a release gate per target market. - Maintain a target-market language matrix and version-control translations. - Ensure translated instructions match EMC installation assumptions and constraints. *Recommended next step* *Placement: after the FAQ section* ## Use EU EMC Directive FAQ as a cited research workflow Research Copilot can take EU EMC Directive FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU EMC Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU EMC Directive FAQ](/solutions/research-copilot.md): Start from EU EMC Directive FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU EMC Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU EMC Directive FAQ. ## Primary sources - [European Commission - EMC Directive page (guidance + templates)](https://single-market-economy.ec.europa.eu/sectors/electrical-and-electronic-engineering-industries-eei/electromagnetic-compatibility-emc-directive_en?ref=sorena.io) - Official hub for EMCD Guide, Q&A, DoC template, and language requirements. - [Guide for the EMCD (Directive 2014/30/EU) - Commission guidance (DocsRoom)](https://ec.europa.eu/docsroom/documents/33601?ref=sorena.io) - Detailed guidance on scope, Annex II versus Annex III, documentation, Article 19 fixed installations, and CE-marking information. - [European Commission - Harmonised standards for EMC (official references)](https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards/electromagnetic-compatibility-emc_en?ref=sorena.io) - Official references and updates for harmonised standards under the EMC Directive. ## Related Topic Guides - [EMC Conformity Assessment + Documentation | Technical File, EU DoC, CE Marking, Language Rules](/artifacts/eu/emc-directive/conformity-assessment-and-documentation.md): A deep guide to EMC conformity assessment and documentation for Directive 2014/30/EU: how to structure the technical documentation/technical file. - [EMC Directive Applicability Test | Is Directive 2014/30/EU in Scope for Your Product?](/artifacts/eu/emc-directive/applicability-test.md): A practical EMC Directive applicability test: decide scope for Directive 2014/30/EU, classify apparatus vs fixed installations. - [EMC Directive Compliance Checklist | CE Marking, Test Plan, Technical File, EU DoC](/artifacts/eu/emc-directive/checklist.md): An audit-ready EMC Directive checklist (Directive 2014/30/EU): scope and classification (apparatus vs fixed installation), standards strategy. - [EMC Directive Compliance Program | Operating Model, Controls, Testing Cadence, Evidence](/artifacts/eu/emc-directive/compliance.md): A deep EMC Directive compliance playbook: build a role-scoped operating model for manufacturers/importers/distributors. - [EMC Directive Deadlines + Compliance Calendar | CE Marking Milestones, Standards Updates, Language Gates](/artifacts/eu/emc-directive/deadlines-and-compliance-calendar.md): A practical EMC compliance calendar for Directive 2014/30/EU with the legal baseline dates, recurring standards reviews. - [EMC Directive Enforcement | Market Surveillance, Corrective Actions, Evidence to Reduce Risk](/artifacts/eu/emc-directive/penalties-and-fines.md): A practical EMC enforcement guide: how market surveillance works under EU product rules, what authorities typically request (technical file, test reports. - [EMC Directive Requirements (2014/30/EU) | Essential Requirements, Operator Duties, Evidence Map](/artifacts/eu/emc-directive/requirements.md): An advanced EMC Directive requirements breakdown: essential requirements (emissions + immunity), obligations for manufacturers/importers/distributors. - [EMC Directive Scope + Borderline Cases | Apparatus vs Fixed Installations, Exclusions, "Inherently Benign"](/artifacts/eu/emc-directive/scope-and-borderline-cases.md): A deep scope guide for the EU EMC Directive (2014/30/EU): how to decide if your product is in scope. - [EMC Directive Timeline | Key Dates for Directive 2014/30/EU, Transition, Standards, Guidance](/artifacts/eu/emc-directive/timeline.md): A practical EMC Directive timeline: adoption and publication of Directive 2014/30/EU. - [EMC Directive vs Low Voltage Directive (LVD) | What Applies, What to Test, One Technical File](/artifacts/eu/emc-directive/emc-vs-low-voltage-directive.md): A practical comparison of the EU EMC Directive (2014/30/EU) vs the Low Voltage Directive (2014/35/EU): different objectives (EMC vs electrical safety). - [EMC Directive vs Radio Equipment Directive (RED) | Which Route Applies for Wireless Products?](/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive.md): A practical comparison of the EMC Directive (2014/30/EU) vs the Radio Equipment Directive (RED) (2014/53/EU): when wireless products fall under RED. - [EMC Essential Requirements + Testing | Emissions, Immunity, Test Configurations, Evidence](/artifacts/eu/emc-directive/essential-requirements-and-testing.md): A deep EMC testing guide for Directive 2014/30/EU: translate essential requirements into emissions + immunity test plans. - [EMC Harmonised Standards Strategy | Presumption of Conformity, OJEU References, Deviations](/artifacts/eu/emc-directive/harmonized-standards-and-deviations.md): A deep guide to harmonised standards under the EMC Directive: how presumption of conformity works. - [EMC Test Plan Template | Directive 2014/30/EU Emissions + Immunity Plan (Audit-Ready)](/artifacts/eu/emc-directive/emc-test-plan-template.md): A structured EMC test plan template you can copy and adapt for CE marking: scope and configuration matrix, standards selection. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/emc-directive/faq --- --- title: "EMC Harmonised Standards Strategy" canonical_url: "https://www.sorena.io/artifacts/eu/emc-directive/harmonized-standards-and-deviations" source_url: "https://www.sorena.io/artifacts/eu/emc-directive/harmonized-standards-and-deviations" author: "Sorena AI" description: "A deep guide to harmonised standards under the EMC Directive: how presumption of conformity works." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EMC harmonised standards" - "presumption of conformity EMC" - "OJEU harmonised standards EMC Directive" - "Directive 2014/30/EU harmonised standards" - "EMC standards strategy residential industrial" - "superseded harmonised standard cessation date" - "deviate from harmonised standard EMC" - "harmonised standards" - "presumption of conformity" - "OJEU references" - "standard updates" - "deviations" - "technical documentation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EMC Harmonised Standards Strategy A deep guide to harmonised standards under the EMC Directive: how presumption of conformity works. *Standards Strategy* *EU* ## EU EMC Directive Harmonised Standards Use standards to get presumption of conformity - and manage updates without chaos. Covers OJEU references, standard version control, and how to document deviations defensibly. Harmonised standards are the fastest route to a defensible EMC compliance position because they can provide presumption of conformity for the corresponding essential requirements. But standards strategy is also where teams accidentally lose that presumption (by referencing the wrong version, ignoring cessation dates, or failing to update the EU DoC when a standard is superseded). This page gives you a practical approach to choosing, tracking, and justifying standards - including what to do when you must deviate. ## How presumption of conformity works (practical view) When you apply harmonised standards whose references are published in the Official Journal, you can benefit from presumption of conformity for the essential requirements covered by those standards. Operationally, that means your technical file should clearly show: which standards you applied, which version, and how your test evidence demonstrates compliance. - Choose standards mapped to your product category and installation environment. - Reference the correct standard version(s) in your technical documentation and EU DoC. - Maintain traceability: requirement -> standard clause -> test setup -> result -> conclusion. ## Selecting standards (residential vs industrial is not a footnote) Standards selection is really an "intended environment" decision. If your product can be used in residential areas, you often need stricter emissions assumptions and clearer user information. Make your environment assumptions explicit and reflect them in both test plan and instructions. - Define where the product is intended to be installed and operated: residential, commercial, light-industrial, industrial, or controlled environments. - Map ports and interfaces: power, I/O, network, cable lengths, accessories, and any RF modules or high-speed clocks. - Choose relevant product-family standards plus generic standards where needed, such as the EN 61000-6 series, and document why the selection covers the essential requirements. ## Standards lifecycle management (avoid losing presumption) Harmonised standards change. Some are superseded, and older versions can lose presumption of conformity after a cessation date published through Official Journal references. Treat standards as dependencies: monitor, assess impact, and update documentation, DoC references, and retest scope when required. - Monitor Official Journal references and the Commission harmonised-standards page for new publications, superseded standards, and cessation dates. - Define update triggers: new standard edition, new product variant, new environment claim, or significant design change. - Update pipeline: impact assessment -> decision record -> retest scope -> updated DoC and technical-file references. ## When you deviate (how to stay defensible) Sometimes you can't fully apply a harmonised standard (unique installation assumptions, novel technology, missing product-family standard). If you deviate, you must compensate with a stronger EMC assessment record and justification - and your evidence must be more explicit. - Write a deviation register: what clause/requirement you didn't follow, why, and what alternative control/test you used. - Run targeted tests to prove equivalence to essential requirements (emissions + immunity outcomes). - Document assumptions and boundaries: "valid only when installed with X cable shielding" is a product requirement that must appear in instructions and support docs. ## Evidence checklist (standards strategy pack) Market surveillance and customers will ask for standards evidence quickly. Keep a compact standards strategy pack. This also reduces retesting: you can quickly see what changes trigger new testing. - Standards selection rationale and environment assumptions. - OJEU reference snapshot (what was applicable when you made the decision). - Standards version control log and update impact assessments. - Deviation register + compensating tests + updated instructions where required. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU EMC Directive Harmonised Standards as a cited research workflow Research Copilot can take EU EMC Directive Harmonised Standards from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU EMC Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU EMC Directive Harmonised Standards](/solutions/research-copilot.md): Start from EU EMC Directive Harmonised Standards and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU EMC Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU EMC Directive Harmonised Standards. ## Primary sources - [European Commission - Harmonised standards for EMC (official references)](https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards/electromagnetic-compatibility-emc_en?ref=sorena.io) - Official entry point for harmonised-standards references and updates under the EMC Directive, including the current standards page and OJEU linkage. - [Directive 2014/30/EU - EMC Directive (official text)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32014L0030&ref=sorena.io) - Legal framework for essential requirements and conformity assessment. - [Standardisation request M/552 for EMC harmonised standards (DocsRoom)](https://ec.europa.eu/docsroom/documents/27441?ref=sorena.io) - Commission standardization request underpinning EMC harmonised-standards development and maintenance. ## Related Topic Guides - [EMC Conformity Assessment + Documentation | Technical File, EU DoC, CE Marking, Language Rules](/artifacts/eu/emc-directive/conformity-assessment-and-documentation.md): A deep guide to EMC conformity assessment and documentation for Directive 2014/30/EU: how to structure the technical documentation/technical file. - [EMC Directive Applicability Test | Is Directive 2014/30/EU in Scope for Your Product?](/artifacts/eu/emc-directive/applicability-test.md): A practical EMC Directive applicability test: decide scope for Directive 2014/30/EU, classify apparatus vs fixed installations. - [EMC Directive Compliance Checklist | CE Marking, Test Plan, Technical File, EU DoC](/artifacts/eu/emc-directive/checklist.md): An audit-ready EMC Directive checklist (Directive 2014/30/EU): scope and classification (apparatus vs fixed installation), standards strategy. - [EMC Directive Compliance Program | Operating Model, Controls, Testing Cadence, Evidence](/artifacts/eu/emc-directive/compliance.md): A deep EMC Directive compliance playbook: build a role-scoped operating model for manufacturers/importers/distributors. - [EMC Directive Deadlines + Compliance Calendar | CE Marking Milestones, Standards Updates, Language Gates](/artifacts/eu/emc-directive/deadlines-and-compliance-calendar.md): A practical EMC compliance calendar for Directive 2014/30/EU with the legal baseline dates, recurring standards reviews. - [EMC Directive Enforcement | Market Surveillance, Corrective Actions, Evidence to Reduce Risk](/artifacts/eu/emc-directive/penalties-and-fines.md): A practical EMC enforcement guide: how market surveillance works under EU product rules, what authorities typically request (technical file, test reports. - [EMC Directive FAQ | Scope, Testing, Technical File, EU DoC, Fixed Installations, Standards](/artifacts/eu/emc-directive/faq.md): High-signal answers to common EMC Directive questions: what is in scope, apparatus vs fixed installations, what to test (emissions + immunity). - [EMC Directive Requirements (2014/30/EU) | Essential Requirements, Operator Duties, Evidence Map](/artifacts/eu/emc-directive/requirements.md): An advanced EMC Directive requirements breakdown: essential requirements (emissions + immunity), obligations for manufacturers/importers/distributors. - [EMC Directive Scope + Borderline Cases | Apparatus vs Fixed Installations, Exclusions, "Inherently Benign"](/artifacts/eu/emc-directive/scope-and-borderline-cases.md): A deep scope guide for the EU EMC Directive (2014/30/EU): how to decide if your product is in scope. - [EMC Directive Timeline | Key Dates for Directive 2014/30/EU, Transition, Standards, Guidance](/artifacts/eu/emc-directive/timeline.md): A practical EMC Directive timeline: adoption and publication of Directive 2014/30/EU. - [EMC Directive vs Low Voltage Directive (LVD) | What Applies, What to Test, One Technical File](/artifacts/eu/emc-directive/emc-vs-low-voltage-directive.md): A practical comparison of the EU EMC Directive (2014/30/EU) vs the Low Voltage Directive (2014/35/EU): different objectives (EMC vs electrical safety). - [EMC Directive vs Radio Equipment Directive (RED) | Which Route Applies for Wireless Products?](/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive.md): A practical comparison of the EMC Directive (2014/30/EU) vs the Radio Equipment Directive (RED) (2014/53/EU): when wireless products fall under RED. - [EMC Essential Requirements + Testing | Emissions, Immunity, Test Configurations, Evidence](/artifacts/eu/emc-directive/essential-requirements-and-testing.md): A deep EMC testing guide for Directive 2014/30/EU: translate essential requirements into emissions + immunity test plans. - [EMC Test Plan Template | Directive 2014/30/EU Emissions + Immunity Plan (Audit-Ready)](/artifacts/eu/emc-directive/emc-test-plan-template.md): A structured EMC test plan template you can copy and adapt for CE marking: scope and configuration matrix, standards selection. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/emc-directive/harmonized-standards-and-deviations --- --- title: "EMC Directive Enforcement" canonical_url: "https://www.sorena.io/artifacts/eu/emc-directive/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/emc-directive/penalties-and-fines" author: "Sorena AI" description: "A practical EMC enforcement guide: how market surveillance works under EU product rules, what authorities typically request (technical file, test reports." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EMC Directive enforcement" - "EMC market surveillance" - "CE marking enforcement EMC" - "technical file request EMC" - "EU Declaration of Conformity request" - "EMC corrective actions recall" - "EMC compliance evidence pack" - "market surveillance" - "corrective actions" - "technical file" - "EU Declaration of Conformity" - "CE marking" - "enforcement risk" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EMC Directive Enforcement A practical EMC enforcement guide: how market surveillance works under EU product rules, what authorities typically request (technical file, test reports. *Enforcement Guide* *EU* ## EU EMC Directive Enforcement Market surveillance is evidence-driven. Reduce risk by making evidence exportable and current. Focus: what authorities ask for and how to avoid common findings. EMC enforcement risk is usually evidence risk. If you can't produce a coherent technical file, test evidence, and a correct EU Declaration of Conformity quickly, you increase the chance of corrective actions and reputational damage. The best defense is an evidence-first program: controlled standards strategy, repeatable testing, and exportable documentation that matches the product placed on the market. ## What market surveillance typically requests first Authorities often start with documentation and traceability. If your evidence pack is coherent, escalation risk drops. Build an export-ready pack so responses are fast and consistent. - EU Declaration of Conformity referencing correct directives and harmonised standards versions. - Technical documentation/technical file (evidence index) including test reports and configuration coverage. - Labeling/traceability and information for use (instructions, warnings, installation constraints). - Standards strategy record including OJEU reference monitoring and update decisions. ## Common failure modes (why findings happen) Most findings are operational: evidence doesn't match the shipped configuration, or documentation is inconsistent across variants and markets. Use these as preventive controls and release gates. - Wrong configuration tested: final PSU, cables, firmware modes, or enclosure differs from test evidence. - Outdated standards references: superseded standards and cessation dates not tracked; DoC not updated when required. - Missing or incorrect instructions: installation constraints required for EMC aren't communicated to users/installers. - Language non-compliance: instructions/DoC availability not aligned to target market language requirements. ## Corrective action playbook (how to respond without panic) If an issue is found, the goal is fast containment and proof-driven remediation. Treat this like an incident: triage, scope, fix, retest, and update documentation with traceability. - Triage: determine affected SKUs/variants and which evidence artifacts are impacted. - Contain: pause shipments of affected configurations where necessary; communicate internally and with partners. - Fix and validate: engineering mitigation + targeted retests; close deviations with evidence. - Update and prevent recurrence: update DoC/technical file, change control rules, and supplier change controls. ## Risk reduction checklist (do these first) These controls reduce both enforcement risk and engineering rework. They also improve customer due diligence responses. - Maintain a configuration matrix and retest triggers tied to change control. - Run quarterly harmonised standards OJEU reviews and document outcomes. - Keep DoC and technical file export-ready, versioned, and linked to product releases. - Maintain target-market language matrix and treat translations as controlled documents. *Recommended next step* *Placement: after the enforcement section* ## Use EU EMC Directive Enforcement as a cited research workflow Research Copilot can take EU EMC Directive Enforcement from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU EMC Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU EMC Directive Enforcement](/solutions/research-copilot.md): Start from EU EMC Directive Enforcement and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU EMC Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU EMC Directive Enforcement. ## Primary sources - [European Commission - EMC Directive page (guidance + resources)](https://single-market-economy.ec.europa.eu/sectors/electrical-and-electronic-engineering-industries-eei/electromagnetic-compatibility-emc-directive_en?ref=sorena.io) - Official Commission resources for EMCD, including guidance and templates used in evidence packs. - [Blue Guide on the implementation of EU product rules (2022/C 247/01) - Official Journal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AC%3A2022%3A247%3AFULL&ref=sorena.io) - Horizontal guidance on EU product rules, economic operators, CE marking, conformity assessment, and market surveillance concepts. - [EU/EEA language requirements summary for EMCD 2014/30/EU (DocsRoom)](https://ec.europa.eu/docsroom/documents/26690?ref=sorena.io) - Country-by-country language requirements summary affecting market surveillance readiness. ## Related Topic Guides - [EMC Conformity Assessment + Documentation | Technical File, EU DoC, CE Marking, Language Rules](/artifacts/eu/emc-directive/conformity-assessment-and-documentation.md): A deep guide to EMC conformity assessment and documentation for Directive 2014/30/EU: how to structure the technical documentation/technical file. - [EMC Directive Applicability Test | Is Directive 2014/30/EU in Scope for Your Product?](/artifacts/eu/emc-directive/applicability-test.md): A practical EMC Directive applicability test: decide scope for Directive 2014/30/EU, classify apparatus vs fixed installations. - [EMC Directive Compliance Checklist | CE Marking, Test Plan, Technical File, EU DoC](/artifacts/eu/emc-directive/checklist.md): An audit-ready EMC Directive checklist (Directive 2014/30/EU): scope and classification (apparatus vs fixed installation), standards strategy. - [EMC Directive Compliance Program | Operating Model, Controls, Testing Cadence, Evidence](/artifacts/eu/emc-directive/compliance.md): A deep EMC Directive compliance playbook: build a role-scoped operating model for manufacturers/importers/distributors. - [EMC Directive Deadlines + Compliance Calendar | CE Marking Milestones, Standards Updates, Language Gates](/artifacts/eu/emc-directive/deadlines-and-compliance-calendar.md): A practical EMC compliance calendar for Directive 2014/30/EU with the legal baseline dates, recurring standards reviews. - [EMC Directive FAQ | Scope, Testing, Technical File, EU DoC, Fixed Installations, Standards](/artifacts/eu/emc-directive/faq.md): High-signal answers to common EMC Directive questions: what is in scope, apparatus vs fixed installations, what to test (emissions + immunity). - [EMC Directive Requirements (2014/30/EU) | Essential Requirements, Operator Duties, Evidence Map](/artifacts/eu/emc-directive/requirements.md): An advanced EMC Directive requirements breakdown: essential requirements (emissions + immunity), obligations for manufacturers/importers/distributors. - [EMC Directive Scope + Borderline Cases | Apparatus vs Fixed Installations, Exclusions, "Inherently Benign"](/artifacts/eu/emc-directive/scope-and-borderline-cases.md): A deep scope guide for the EU EMC Directive (2014/30/EU): how to decide if your product is in scope. - [EMC Directive Timeline | Key Dates for Directive 2014/30/EU, Transition, Standards, Guidance](/artifacts/eu/emc-directive/timeline.md): A practical EMC Directive timeline: adoption and publication of Directive 2014/30/EU. - [EMC Directive vs Low Voltage Directive (LVD) | What Applies, What to Test, One Technical File](/artifacts/eu/emc-directive/emc-vs-low-voltage-directive.md): A practical comparison of the EU EMC Directive (2014/30/EU) vs the Low Voltage Directive (2014/35/EU): different objectives (EMC vs electrical safety). - [EMC Directive vs Radio Equipment Directive (RED) | Which Route Applies for Wireless Products?](/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive.md): A practical comparison of the EMC Directive (2014/30/EU) vs the Radio Equipment Directive (RED) (2014/53/EU): when wireless products fall under RED. - [EMC Essential Requirements + Testing | Emissions, Immunity, Test Configurations, Evidence](/artifacts/eu/emc-directive/essential-requirements-and-testing.md): A deep EMC testing guide for Directive 2014/30/EU: translate essential requirements into emissions + immunity test plans. - [EMC Harmonised Standards Strategy | Presumption of Conformity, OJEU References, Deviations](/artifacts/eu/emc-directive/harmonized-standards-and-deviations.md): A deep guide to harmonised standards under the EMC Directive: how presumption of conformity works. - [EMC Test Plan Template | Directive 2014/30/EU Emissions + Immunity Plan (Audit-Ready)](/artifacts/eu/emc-directive/emc-test-plan-template.md): A structured EMC test plan template you can copy and adapt for CE marking: scope and configuration matrix, standards selection. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/emc-directive/penalties-and-fines --- --- title: "EMC Directive Requirements (2014/30/EU)" canonical_url: "https://www.sorena.io/artifacts/eu/emc-directive/requirements" source_url: "https://www.sorena.io/artifacts/eu/emc-directive/requirements" author: "Sorena AI" description: "An advanced EMC Directive requirements breakdown: essential requirements (emissions + immunity), obligations for manufacturers/importers/distributors." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EMC Directive requirements" - "Directive 2014/30/EU requirements" - "EMC essential requirements" - "emissions immunity requirements" - "EMC technical documentation requirements" - "EU Declaration of Conformity EMC" - "EMC conformity assessment" - "fixed installation EMC requirements" - "Directive 2014/30/EU" - "essential requirements" - "emissions and immunity" - "technical documentation" - "EU Declaration of Conformity" - "fixed installations" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EMC Directive Requirements (2014/30/EU) An advanced EMC Directive requirements breakdown: essential requirements (emissions + immunity), obligations for manufacturers/importers/distributors. *Requirements Guide* *EU* ## EU EMC Directive Requirements A requirements breakdown you can implement: tests, documents, and evidence. Built from Directive 2014/30/EU + Commission guidance for apparatus and fixed installations. EMC compliance is a system: design assumptions, standards strategy, conformity-assessment route, test plan, test results, technical documentation, EU Declaration of Conformity, CE marking, and market-surveillance readiness. This page organizes Directive 2014/30/EU into practical workstreams and shows what evidence you need for apparatus, economic operators, and fixed installations. ## Essential requirements (the outcome you must achieve) The EMC Directive sets essential requirements in an outcome-focused way. Harmonised standards are the main route to presumption of conformity, but you can also use other technical solutions if you can justify them. Operationally, treat essential requirements as two test families: emissions and immunity. - Emissions: your equipment must not generate electromagnetic disturbance above a level that prevents other equipment from operating as intended. - Immunity: your equipment must have an adequate level of intrinsic immunity to expected disturbances so it operates as intended. - Environment matters: residential vs industrial installation assumptions drive limits and test setups. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU EMC Directive Requirements into an operational assessment Assessment Autopilot can take EU EMC Directive Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU EMC Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU EMC Directive Requirements](/solutions/assessment.md): Start from EU EMC Directive Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU EMC Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU EMC Directive Requirements. ## Economic operator obligations (who must do what) The Directive, aligned with the New Legislative Framework, assigns responsibilities to manufacturers, authorized representatives, importers, and distributors. Your compliance system should map each obligation to a control owner and a system-of-record evidence artifact. - Manufacturer: ensure conformity, perform the EMC assessment, compile technical documentation, issue the EU DoC, apply CE marking where required, and retain documentation for 10 years after placing apparatus on the market. - Importer: ensure only compliant apparatus is placed on the market, keep a copy of the EU DoC for 10 years, and be able to get the technical documentation for authorities on request. - Distributor: verify the presence of required markings, instructions, and documentation and avoid making non-compliant apparatus available. ## Conformity assessment for apparatus (what "done" looks like) For apparatus, the default route is Annex II internal production control. Annex III adds notified-body involvement through EU-type examination followed by conformity to type based on internal production control. Do not treat testing as the first step. Define configuration control, intended environment, and standards strategy before lab work. - Annex II: internal production control supported by an EMC assessment, test evidence, technical documentation, and the EU DoC. - Annex III: optional notified-body route when you want EU-type examination support, especially if harmonised standards are not fully applied or the case is complex. - Technical documentation: evidence index with test reports, design rationale, configuration coverage, and any EU-type examination certificate if Annex III is used. - Information for use: instructions and warnings, including residential-area limitations or installation conditions where relevant. ## Fixed installations (different obligations, same EMC outcomes) Fixed installations are treated differently from apparatus, but the essential requirements still apply through good engineering practice and installation-level control. Authorities may request evidence of compliance for a fixed installation where there are indications of non-compliance, so someone must own the installation evidence pack. - Define the responsible person or organization for the installation and keep a controlled documentation set. - Maintain evidence of good engineering practice, installation-level EMC assessment, and the manufacturer instructions used for the incorporated apparatus. - Control changes because replacement apparatus, cabling changes, grounding changes, and site modifications can change EMC behavior. ## Evidence mapping (requirement -> test -> artifact) Build an evidence index so market surveillance and customer audits are fast and consistent. Use "done looks like" acceptance criteria so engineering and compliance agree on closure. - Essential requirements -> test plan sections -> test results -> deviation handling -> final decision record. - Operator obligations -> owner -> artifact (DoC, labels, traceability, instructions, retention controls). - Standards changes -> review cadence -> updated DoC where required -> re-test triggers. ## Primary sources - [Directive 2014/30/EU - EMC Directive (official text)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32014L0030&ref=sorena.io) - Primary legal text defining essential requirements, Article 14 conformity-assessment routes, Article 15 DoC rules, Article 19 fixed-installation treatment, and economic-operator obligations. - [Guide for the EMCD (Directive 2014/30/EU) - Commission guidance (DocsRoom)](https://ec.europa.eu/docsroom/documents/33601?ref=sorena.io) - Commission guidance on Annex II versus Annex III, technical documentation, good engineering practice for fixed installations, and 10-year retention expectations. - [European Commission - EMC Directive page (templates and resources)](https://single-market-economy.ec.europa.eu/sectors/electrical-and-electronic-engineering-industries-eei/electromagnetic-compatibility-emc-directive_en?ref=sorena.io) - Official resource hub linking to DoC templates, Q&A, and language requirements. ## Related Topic Guides - [EMC Conformity Assessment + Documentation | Technical File, EU DoC, CE Marking, Language Rules](/artifacts/eu/emc-directive/conformity-assessment-and-documentation.md): A deep guide to EMC conformity assessment and documentation for Directive 2014/30/EU: how to structure the technical documentation/technical file. - [EMC Directive Applicability Test | Is Directive 2014/30/EU in Scope for Your Product?](/artifacts/eu/emc-directive/applicability-test.md): A practical EMC Directive applicability test: decide scope for Directive 2014/30/EU, classify apparatus vs fixed installations. - [EMC Directive Compliance Checklist | CE Marking, Test Plan, Technical File, EU DoC](/artifacts/eu/emc-directive/checklist.md): An audit-ready EMC Directive checklist (Directive 2014/30/EU): scope and classification (apparatus vs fixed installation), standards strategy. - [EMC Directive Compliance Program | Operating Model, Controls, Testing Cadence, Evidence](/artifacts/eu/emc-directive/compliance.md): A deep EMC Directive compliance playbook: build a role-scoped operating model for manufacturers/importers/distributors. - [EMC Directive Deadlines + Compliance Calendar | CE Marking Milestones, Standards Updates, Language Gates](/artifacts/eu/emc-directive/deadlines-and-compliance-calendar.md): A practical EMC compliance calendar for Directive 2014/30/EU with the legal baseline dates, recurring standards reviews. - [EMC Directive Enforcement | Market Surveillance, Corrective Actions, Evidence to Reduce Risk](/artifacts/eu/emc-directive/penalties-and-fines.md): A practical EMC enforcement guide: how market surveillance works under EU product rules, what authorities typically request (technical file, test reports. - [EMC Directive FAQ | Scope, Testing, Technical File, EU DoC, Fixed Installations, Standards](/artifacts/eu/emc-directive/faq.md): High-signal answers to common EMC Directive questions: what is in scope, apparatus vs fixed installations, what to test (emissions + immunity). - [EMC Directive Scope + Borderline Cases | Apparatus vs Fixed Installations, Exclusions, "Inherently Benign"](/artifacts/eu/emc-directive/scope-and-borderline-cases.md): A deep scope guide for the EU EMC Directive (2014/30/EU): how to decide if your product is in scope. - [EMC Directive Timeline | Key Dates for Directive 2014/30/EU, Transition, Standards, Guidance](/artifacts/eu/emc-directive/timeline.md): A practical EMC Directive timeline: adoption and publication of Directive 2014/30/EU. - [EMC Directive vs Low Voltage Directive (LVD) | What Applies, What to Test, One Technical File](/artifacts/eu/emc-directive/emc-vs-low-voltage-directive.md): A practical comparison of the EU EMC Directive (2014/30/EU) vs the Low Voltage Directive (2014/35/EU): different objectives (EMC vs electrical safety). - [EMC Directive vs Radio Equipment Directive (RED) | Which Route Applies for Wireless Products?](/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive.md): A practical comparison of the EMC Directive (2014/30/EU) vs the Radio Equipment Directive (RED) (2014/53/EU): when wireless products fall under RED. - [EMC Essential Requirements + Testing | Emissions, Immunity, Test Configurations, Evidence](/artifacts/eu/emc-directive/essential-requirements-and-testing.md): A deep EMC testing guide for Directive 2014/30/EU: translate essential requirements into emissions + immunity test plans. - [EMC Harmonised Standards Strategy | Presumption of Conformity, OJEU References, Deviations](/artifacts/eu/emc-directive/harmonized-standards-and-deviations.md): A deep guide to harmonised standards under the EMC Directive: how presumption of conformity works. - [EMC Test Plan Template | Directive 2014/30/EU Emissions + Immunity Plan (Audit-Ready)](/artifacts/eu/emc-directive/emc-test-plan-template.md): A structured EMC test plan template you can copy and adapt for CE marking: scope and configuration matrix, standards selection. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/emc-directive/requirements --- --- title: "EMC Directive Scope + Borderline Cases" canonical_url: "https://www.sorena.io/artifacts/eu/emc-directive/scope-and-borderline-cases" source_url: "https://www.sorena.io/artifacts/eu/emc-directive/scope-and-borderline-cases" author: "Sorena AI" description: "A deep scope guide for the EU EMC Directive (2014/30/EU): how to decide if your product is in scope." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EMC Directive scope" - "Directive 2014/30/EU scope" - "apparatus vs fixed installation EMC" - "EMC directive exclusions" - "inherently benign equipment EMC" - "mobile installation EMC" - "components sub-assemblies EMC" - "EMC CE marking scope" - "apparatus vs fixed installation" - "borderline cases" - "inherently benign equipment" - "components and sub-assemblies" - "CE marking" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EMC Directive Scope + Borderline Cases A deep scope guide for the EU EMC Directive (2014/30/EU): how to decide if your product is in scope. *Scope Guide* *EU* ## EU EMC Directive Scope + Borderline Cases Get scope right early to avoid late-stage CE marking surprises and retesting. Grounded in Directive 2014/30/EU and the Commission's EMCD Guide (apparatus vs fixed installations). Most EMC compliance failures are not technical. They are scoping mistakes. Teams test the wrong product configuration, treat a fixed installation like a CE-marked apparatus, or assume component CE marks automatically make a system compliant. Use this page to decide scope and document your reasoning in a way that survives audits, customer due diligence, and market-surveillance questions. ## What the EMC Directive covers (plain language) The EMC Directive harmonizes rules for electromagnetic compatibility: equipment should not generate excessive electromagnetic disturbance and should have adequate immunity so it works as intended. Scope decisions drive everything downstream: which conformity assessment route you use, what documentation you must keep, and whether CE marking applies to the product unit. - Scope is about the equipment as placed on the market/put into service, not only a lab prototype. - The Directive distinguishes between apparatus (typically CE-marked units) and fixed installations (site-assembled systems). - Borderline cases must be documented: components, sub-assemblies, mobile installations, and products intended for integration. *Recommended next step* *Placement: after the scope or definition section* ## Use EU EMC Directive Scope + Borderline Cases as a cited research workflow Research Copilot can take EU EMC Directive Scope + Borderline Cases from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU EMC Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU EMC Directive Scope + Borderline Cases](/solutions/research-copilot.md): Start from EU EMC Directive Scope + Borderline Cases and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU EMC Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU EMC Directive Scope + Borderline Cases. ## Apparatus vs fixed installations (the critical fork) The Commission's EMCD Guide describes how to classify equipment as apparatus or fixed installation and what provisions apply to each. Misclassification creates expensive rework: wrong test plan, wrong documentation, and wrong customer expectations. - Apparatus: a finished appliance or combination made available as a single functional unit for the end user and liable to generate disturbance or be affected by it. - Fixed installation: a particular combination of apparatus and devices assembled and intended to be used permanently at a predefined location. - Mobile installations: combinations intended to be moved and operated in multiple locations are generally treated as apparatus in Commission guidance. - Specific apparatus for a given fixed installation can have special treatment under Article 19(1) if it is otherwise not commercially available, but that exception must be justified and documented. ## Borderline scenarios (common real-world cases) Use these patterns to assess scope. Then capture the outcome in your technical file as a short decision record with evidence links. If you are unsure, treat it like apparatus and build the full evidence pack - that is the safer path for commercialization. - Combination of CE-marked devices: the system can still fail EMC; evaluate the combination as a whole when marketed as a single functional unit (Guide summary). - Components/sub-assemblies: often not intended for final use by end users; scope depends on intended use and how they're made available. - Custom-built evaluation kits: scope and obligations can differ; document intended purpose and distribution model. - Inherently benign equipment: where disturbance generation and susceptibility are not relevant due to inherent characteristics; justify with engineering evidence if you claim this. ## Exclusions and overlaps (when another regime dominates) Some products overlap with other EU harmonization legislation (e.g., radio equipment). Your EMC work still matters, but the applicable legal instrument and route may differ. Use this as a trigger to review the "vs" pages and update your conformity assessment plan. - Radio products: check the EMC versus Radio Equipment Directive page because RED often carries the legal route while EMC testing still matters. - Electrical safety: check EMC versus Low Voltage Directive because both often apply but with different objectives. - Vehicle-related equipment: use the 2024 to 2025 Commission guidance on EMCD versus vehicle legislation because aftermarket and vehicle-dedicated equipment can split across regimes. - Specific apparatus for a given fixed installation: check whether Article 19(1) changes CE-marking and DoC expectations. ## Evidence to keep (scope decision pack) Market surveillance and customers will ask "why do you think it's in/out of scope?". If you cannot answer, you will re-test and re-document. Keep these artifacts lightweight but explicit. - Product classification record: apparatus versus fixed installation decision and rationale, with diagrams where useful. - Intended use and end-user statement: who uses it, where, and under what installation assumptions. - Configuration control: what variants, accessories, cables, and ports were included in scope and in tests. - Overlap and Article 19 assessment: list other directives or sector rules that may apply and record the final decision. ## Primary sources - [Directive 2014/30/EU - EMC Directive (official text)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32014L0030&ref=sorena.io) - Primary legal text for the EU EMC Directive (definitions, scope, essential requirements, economic operator obligations). - [European Commission - EMC Directive page (guidance + resources)](https://single-market-economy.ec.europa.eu/sectors/electrical-and-electronic-engineering-industries-eei/electromagnetic-compatibility-emc-directive_en?ref=sorena.io) - Official Commission page linking to the EMCD Guide, Q&A, DoC template, language requirements, and sector guidance. - [Guide for the EMCD (Directive 2014/30/EU) - Commission guidance (DocsRoom)](https://ec.europa.eu/docsroom/documents/33601?ref=sorena.io) - Detailed Commission guidance on apparatus versus fixed installations, Article 19 special cases, and borderline concepts. ## Related Topic Guides - [EMC Conformity Assessment + Documentation | Technical File, EU DoC, CE Marking, Language Rules](/artifacts/eu/emc-directive/conformity-assessment-and-documentation.md): A deep guide to EMC conformity assessment and documentation for Directive 2014/30/EU: how to structure the technical documentation/technical file. - [EMC Directive Applicability Test | Is Directive 2014/30/EU in Scope for Your Product?](/artifacts/eu/emc-directive/applicability-test.md): A practical EMC Directive applicability test: decide scope for Directive 2014/30/EU, classify apparatus vs fixed installations. - [EMC Directive Compliance Checklist | CE Marking, Test Plan, Technical File, EU DoC](/artifacts/eu/emc-directive/checklist.md): An audit-ready EMC Directive checklist (Directive 2014/30/EU): scope and classification (apparatus vs fixed installation), standards strategy. - [EMC Directive Compliance Program | Operating Model, Controls, Testing Cadence, Evidence](/artifacts/eu/emc-directive/compliance.md): A deep EMC Directive compliance playbook: build a role-scoped operating model for manufacturers/importers/distributors. - [EMC Directive Deadlines + Compliance Calendar | CE Marking Milestones, Standards Updates, Language Gates](/artifacts/eu/emc-directive/deadlines-and-compliance-calendar.md): A practical EMC compliance calendar for Directive 2014/30/EU with the legal baseline dates, recurring standards reviews. - [EMC Directive Enforcement | Market Surveillance, Corrective Actions, Evidence to Reduce Risk](/artifacts/eu/emc-directive/penalties-and-fines.md): A practical EMC enforcement guide: how market surveillance works under EU product rules, what authorities typically request (technical file, test reports. - [EMC Directive FAQ | Scope, Testing, Technical File, EU DoC, Fixed Installations, Standards](/artifacts/eu/emc-directive/faq.md): High-signal answers to common EMC Directive questions: what is in scope, apparatus vs fixed installations, what to test (emissions + immunity). - [EMC Directive Requirements (2014/30/EU) | Essential Requirements, Operator Duties, Evidence Map](/artifacts/eu/emc-directive/requirements.md): An advanced EMC Directive requirements breakdown: essential requirements (emissions + immunity), obligations for manufacturers/importers/distributors. - [EMC Directive Timeline | Key Dates for Directive 2014/30/EU, Transition, Standards, Guidance](/artifacts/eu/emc-directive/timeline.md): A practical EMC Directive timeline: adoption and publication of Directive 2014/30/EU. - [EMC Directive vs Low Voltage Directive (LVD) | What Applies, What to Test, One Technical File](/artifacts/eu/emc-directive/emc-vs-low-voltage-directive.md): A practical comparison of the EU EMC Directive (2014/30/EU) vs the Low Voltage Directive (2014/35/EU): different objectives (EMC vs electrical safety). - [EMC Directive vs Radio Equipment Directive (RED) | Which Route Applies for Wireless Products?](/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive.md): A practical comparison of the EMC Directive (2014/30/EU) vs the Radio Equipment Directive (RED) (2014/53/EU): when wireless products fall under RED. - [EMC Essential Requirements + Testing | Emissions, Immunity, Test Configurations, Evidence](/artifacts/eu/emc-directive/essential-requirements-and-testing.md): A deep EMC testing guide for Directive 2014/30/EU: translate essential requirements into emissions + immunity test plans. - [EMC Harmonised Standards Strategy | Presumption of Conformity, OJEU References, Deviations](/artifacts/eu/emc-directive/harmonized-standards-and-deviations.md): A deep guide to harmonised standards under the EMC Directive: how presumption of conformity works. - [EMC Test Plan Template | Directive 2014/30/EU Emissions + Immunity Plan (Audit-Ready)](/artifacts/eu/emc-directive/emc-test-plan-template.md): A structured EMC test plan template you can copy and adapt for CE marking: scope and configuration matrix, standards selection. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/emc-directive/scope-and-borderline-cases --- --- title: "EMC Directive Timeline" canonical_url: "https://www.sorena.io/artifacts/eu/emc-directive/timeline" source_url: "https://www.sorena.io/artifacts/eu/emc-directive/timeline" author: "Sorena AI" description: "A practical EMC Directive timeline: adoption and publication of Directive 2014/30/EU." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EMC Directive timeline" - "Directive 2014/30/EU key dates" - "EMC Directive applies 20 April 2016" - "Directive 2004/108/EC repealed 2016" - "EMC harmonised standards timeline" - "EMC guidance documents" - "Directive 2014/30/EU" - "application date" - "harmonised standards" - "Commission guidance" - "CE marking" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EMC Directive Timeline A practical EMC Directive timeline: adoption and publication of Directive 2014/30/EU. *Timeline* *EU* ## EU EMC Directive Timeline Key dates and guidance milestones that affect EMC CE marking readiness. Use this as a planning input, then build deliverable-based milestones. The EMC Directive timeline matters because it drives the legal basis, transition expectations, and the standards and guidance ecosystem you should cite in your technical file. Use this page to anchor your compliance narrative and to plan workstreams: scope decision, standards selection, test plan, documentation, and market surveillance readiness. ## Core Directive timeline (Directive 2014/30/EU) Directive 2014/30/EU is the EMC Directive legal basis for electromagnetic compatibility in the EU internal market. It replaced the previous EMC Directive 2004/108/EC and became applicable from 20 April 2016 (Commission overview). - 26 February 2014: Directive 2014/30/EU adopted. - 29 March 2014: published in the Official Journal, OJ L 96. - 20 April 2016: application date, replacing Directive 2004/108/EC from this date. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU EMC Directive Timeline into an operational assessment Assessment Autopilot can take EU EMC Directive Timeline from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU EMC Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU EMC Directive Timeline](/solutions/assessment.md): Start from EU EMC Directive Timeline and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU EMC Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU EMC Directive Timeline. ## Guidance milestones (what you should cite in your technical file narrative) Commission guidance documents are not the law, but they are the best practical interpretation layer for scoping, documentation, and borderline cases. Use them to support consistent internal decisions and faster audit responses. - 28 April 2016: transition Q and A on 2004/108/EC to 2014/30/EU published. - 30 November 2016: standardization request M/552 adopted for EMC harmonised standards. - 13 July 2018: Commission communication 2018/C 246/01 published Official Journal references for EMC harmonised standards. - 19 December 2018: EMCD Guide published for scope, apparatus versus fixed installations, assessment, documentation, and CE-marking information. - 18 February 2025: Commission guidance on EMCD versus vehicle legislation published for current borderline analysis. ## Standards and references (why OJEU monitoring is continuous) Harmonised standards referenced in the Official Journal are the common route to presumption of conformity. Because references and versions evolve, standards monitoring should be a recurring compliance activity, not a one-time selection. - Monitor the Commission harmonised-standards page and record periodic review outcomes. - Track superseded standards and cessation dates and define update triggers for the DoC and retesting. - Keep a standards-selection rationale and update log in the technical file, especially for residential versus industrial environment assumptions. ## Planning view (deliverables timeline you control) Dates don't ship products - deliverables do. Use this to plan internal milestones that create defensible compliance outcomes. This also reduces late-stage lab retests and documentation crunch. - T-1: scope classification and configuration matrix complete for variants, cables, modes, and installation assumptions. - T-2: standards shortlist and Official Journal reference snapshot recorded, with a deviation register draft if needed. - T-3: EMC test plan approved with functional criteria, Annex II or Annex III route, and retest triggers. - T-4: lab tests completed and reports plus deviation register closed. - T-5: technical file and EU DoC finalized, labeling and instructions approved, and release evidence archived. ## Primary sources - [European Commission - EMC Directive overview page](https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards/electromagnetic-compatibility-emc_en?ref=sorena.io) - Commission overview including the 20 April 2016 application date and current EMC resources. - [European Commission - EMC Directive page (guidance + templates)](https://single-market-economy.ec.europa.eu/sectors/electrical-and-electronic-engineering-industries-eei/electromagnetic-compatibility-emc-directive_en?ref=sorena.io) - Official resource hub for Commission guidance and templates. - [Directive 2014/30/EU - EMC Directive (official text)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32014L0030&ref=sorena.io) - Primary legal text for the EMC Directive. - [European Commission - EMC Directive page (includes 2025 vehicle-equipment guidance)](https://single-market-economy.ec.europa.eu/sectors/electrical-and-electronic-engineering-industries-eei/electromagnetic-compatibility-emc-directive_en?ref=sorena.io) - Official Commission EMC Directive page linking the current guidance set, including the 18 February 2025 after-market and vehicle-equipment guidance. ## Related Topic Guides - [EMC Conformity Assessment + Documentation | Technical File, EU DoC, CE Marking, Language Rules](/artifacts/eu/emc-directive/conformity-assessment-and-documentation.md): A deep guide to EMC conformity assessment and documentation for Directive 2014/30/EU: how to structure the technical documentation/technical file. - [EMC Directive Applicability Test | Is Directive 2014/30/EU in Scope for Your Product?](/artifacts/eu/emc-directive/applicability-test.md): A practical EMC Directive applicability test: decide scope for Directive 2014/30/EU, classify apparatus vs fixed installations. - [EMC Directive Compliance Checklist | CE Marking, Test Plan, Technical File, EU DoC](/artifacts/eu/emc-directive/checklist.md): An audit-ready EMC Directive checklist (Directive 2014/30/EU): scope and classification (apparatus vs fixed installation), standards strategy. - [EMC Directive Compliance Program | Operating Model, Controls, Testing Cadence, Evidence](/artifacts/eu/emc-directive/compliance.md): A deep EMC Directive compliance playbook: build a role-scoped operating model for manufacturers/importers/distributors. - [EMC Directive Deadlines + Compliance Calendar | CE Marking Milestones, Standards Updates, Language Gates](/artifacts/eu/emc-directive/deadlines-and-compliance-calendar.md): A practical EMC compliance calendar for Directive 2014/30/EU with the legal baseline dates, recurring standards reviews. - [EMC Directive Enforcement | Market Surveillance, Corrective Actions, Evidence to Reduce Risk](/artifacts/eu/emc-directive/penalties-and-fines.md): A practical EMC enforcement guide: how market surveillance works under EU product rules, what authorities typically request (technical file, test reports. - [EMC Directive FAQ | Scope, Testing, Technical File, EU DoC, Fixed Installations, Standards](/artifacts/eu/emc-directive/faq.md): High-signal answers to common EMC Directive questions: what is in scope, apparatus vs fixed installations, what to test (emissions + immunity). - [EMC Directive Requirements (2014/30/EU) | Essential Requirements, Operator Duties, Evidence Map](/artifacts/eu/emc-directive/requirements.md): An advanced EMC Directive requirements breakdown: essential requirements (emissions + immunity), obligations for manufacturers/importers/distributors. - [EMC Directive Scope + Borderline Cases | Apparatus vs Fixed Installations, Exclusions, "Inherently Benign"](/artifacts/eu/emc-directive/scope-and-borderline-cases.md): A deep scope guide for the EU EMC Directive (2014/30/EU): how to decide if your product is in scope. - [EMC Directive vs Low Voltage Directive (LVD) | What Applies, What to Test, One Technical File](/artifacts/eu/emc-directive/emc-vs-low-voltage-directive.md): A practical comparison of the EU EMC Directive (2014/30/EU) vs the Low Voltage Directive (2014/35/EU): different objectives (EMC vs electrical safety). - [EMC Directive vs Radio Equipment Directive (RED) | Which Route Applies for Wireless Products?](/artifacts/eu/emc-directive/emc-vs-radio-equipment-directive.md): A practical comparison of the EMC Directive (2014/30/EU) vs the Radio Equipment Directive (RED) (2014/53/EU): when wireless products fall under RED. - [EMC Essential Requirements + Testing | Emissions, Immunity, Test Configurations, Evidence](/artifacts/eu/emc-directive/essential-requirements-and-testing.md): A deep EMC testing guide for Directive 2014/30/EU: translate essential requirements into emissions + immunity test plans. - [EMC Harmonised Standards Strategy | Presumption of Conformity, OJEU References, Deviations](/artifacts/eu/emc-directive/harmonized-standards-and-deviations.md): A deep guide to harmonised standards under the EMC Directive: how presumption of conformity works. - [EMC Test Plan Template | Directive 2014/30/EU Emissions + Immunity Plan (Audit-Ready)](/artifacts/eu/emc-directive/emc-test-plan-template.md): A structured EMC test plan template you can copy and adapt for CE marking: scope and configuration matrix, standards selection. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/emc-directive/timeline --- --- title: "EED Applicability Test (Directive (EU) 2023/1791)" canonical_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/applicability-test" author: "Sorena AI" description: "A practical applicability test for the EU Energy Efficiency Directive (EED." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Energy Efficiency Directive applicability test" - "EED applicability" - "Directive (EU) 2023/1791 Article 11" - "85 TJ energy management system" - "10 TJ energy audits" - "EN 16247 energy audit" - "ISO 50001 certified energy management system" - "EED public bodies obligation" - "data centre reporting 500 kW" - "Applicability Test" - "Directive (EU) 2023/1791" - "energy audits" - "energy management system" - "public bodies" - "data centres" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EED Applicability Test (Directive (EU) 2023/1791) A practical applicability test for the EU Energy Efficiency Directive (EED. *Applicability Test* *EU* ## EU Energy Efficiency Directive (EED) Applicability Test Decide which EED obligations apply and what route you must follow. Built around Directive (EU) 2023/1791 thresholds (85 TJ / 10 TJ) plus public bodies and data centre triggers. EED applicability is not a single yes/no question. Different obligations apply to different actors: enterprises above energy-consumption thresholds, public bodies (through Member State implementation), and data centre operators above the reporting trigger. Use this page to reach a defensible outcome and store an evidence-backed decision memo. ## Step 1: Identify which bucket you are in, enterprise, public body, or data centre Directive (EU) 2023/1791 contains different obligation tracks. Your first job is to classify your role in the real world, not just by legal-entity name. Many organizations fall into multiple buckets (e.g., an enterprise that also operates a data centre; a public authority that runs facilities and procurement). - Enterprise track: determine whether you exceed the EED energy-consumption thresholds that trigger a certified energy management system or energy audits. - Public bodies track: determine whether you are treated as a public body in your Member State's implementation and which reduction/building obligations are in scope for you. - Data centres track: determine whether your installed IT power demand meets the reporting trigger and whether you must publish/report Annex VII information annually. ## Step 2: Compute your enterprise 3-year average energy consumption For the enterprise thresholds, the key calculation is your average annual energy consumption over the previous three years, taking all energy carriers together. Treat this as a controlled calculation: define boundaries, sources of data, and how you handle missing or estimated values. - Define organizational boundary: which sites, subsidiaries, and operational units are included (and why). - Define data sources: utility invoices, energy management systems, metering, fleet fuel records, purchased heat/cooling. - Normalize and document: conversion factors, assumptions, and treatment of acquisitions/divestitures. - Compute: average annual TJ over the previous three years across all carriers. ## Step 3: Determine your route, 85 TJ EMS, 10 TJ audits, or below threshold The EED sets two key enterprise thresholds. Above the higher threshold you must implement a certified energy management system; above the lower threshold (but not implementing an EMS) you must undergo an energy audit. Even if you are below thresholds, you may still be in scope for other EED duties (e.g., data centre reporting) and you may choose voluntary audits or EMS for savings and governance. - If average annual consumption > 85 TJ, implement a certified energy management system, commonly aligned to EN ISO 50001, with the EMS in place by 11 October 2027. - If average annual consumption > 10 TJ and you do not implement an EMS, carry out a first energy audit by 11 October 2026 and then at least every four years, using Annex VI as the quality baseline. - If <= 10 TJ, store a decision memo and monitor material changes. Consider voluntary audits for cost-effective savings. ## Step 4: Data centres, check the 500 kW reporting trigger Data centre obligations are triggered by installed information technology (IT) power demand thresholds. If you meet the trigger, plan an annual reporting workflow: data collection, validation, publication, and change control. - If installed IT power demand >= 500 kW, prepare to publish Annex VII information annually, subject to confidentiality protections. - If installed IT power demand >= 500 kW, also plan the European database reporting workflow under Delegated Regulation (EU) 2024/1364. - If installed IT power demand >= 1 MW, plan for additional best-practice expectations and higher scrutiny. - Store evidence, boundary definition, IT power measurement approach, publication link, and database submission record. ## Output: an EED decision memo you can reuse The fastest way to reduce compliance and audit risk is to create a one-page decision memo and keep it updated. Make it exportable: auditors, investors, partners, and internal stakeholders should be able to understand the logic in minutes. - Scope statement: roles (enterprise/public body/data centre) and organizational boundaries. - Threshold calculation: inputs, conversion factors, and computed 3-year average consumption (TJ). - Route decision: EMS vs audit (or not mandatory) and owners/cadence. - Data centre trigger decision: installed IT power demand and publication workflow. - Next-step checklist: subpages to use and evidence folders to create. *Recommended next step* *Placement: after the applicability result* ## Operationalize EU Energy Efficiency Directive (EED) Applicability Test across ESG workflows ESG Compliance can take EU Energy Efficiency Directive (EED) Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU Energy Efficiency Directive (EED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Energy Efficiency Directive (EED) Applicability Test](/solutions/esg-compliance.md): Start from EU Energy Efficiency Directive (EED) Applicability Test and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Energy Efficiency Directive (EED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Energy Efficiency Directive (EED) Applicability Test. ## Primary sources - [Directive (EU) 2023/1791: Energy Efficiency Directive (recast) (official text)](https://eur-lex.europa.eu/eli/dir/2023/1791/oj?ref=sorena.io) - Threshold-based enterprise obligations, public-sector provisions, data centre reporting, and penalties framework. - [European Commission: Energy Efficiency Directive overview (EED hub)](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive_en?ref=sorena.io) - Official overview and links to guidance, targets, and sector pages. - [European Commission: Energy performance of data centres (EED sector page)](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive/energy-performance-data-centres_en?ref=sorena.io) - Commission overview of the data centre monitoring/reporting framework and supporting resources. - [Commission Delegated Regulation (EU) 2024/1364: data centre reporting scheme](https://eur-lex.europa.eu/eli/reg_del/2024/1364/oj/eng?ref=sorena.io) - European database reporting methodology for in-scope data centres. ## Related Topic Guides - [EED Checklist (Directive (EU) 2023/1791) | Audit-Ready Steps for Article 11, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/checklist.md): An audit-ready checklist for the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): scope and boundary memo, 85 TJ vs 10 TJ route decision. - [EED Compliance Program (Directive (EU) 2023/1791) | How to Operationalize Article 11, Audits, ISO 50001, Reporting](/artifacts/eu/energy-efficiency-directive/compliance.md): A practical EED compliance playbook: governance, scope control, threshold route decision (85 TJ / 10 TJ), energy audit program (Annex VI quality gates). - [EED Deadlines & Compliance Calendar (Directive (EU) 2023/1791) | Transposition 11 Oct 2025, Data Centres 15 May](/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED Energy Audits (Directive (EU) 2023/1791 Article 11) | Annex VI Minimum Criteria + Action Plan + Reporting](/artifacts/eu/energy-efficiency-directive/energy-audits.md): A deep-dive on EED energy audits: who must do them (>10 TJ 3-year average if no EMS), deadlines (first audit by 11 Oct 2026. - [EED Energy Management System (EMS) (Directive (EU) 2023/1791 Article 11) | 85 TJ Threshold + ISO 50001 Certification](/artifacts/eu/energy-efficiency-directive/energy-management-systems.md): A practical guide to the EED EMS obligation: who must implement a certified energy management system (>85 TJ 3-year average). - [EED Enforcement (Penalties) | Directive (EU) 2023/1791 Article 32 + How to Reduce Risk](/artifacts/eu/energy-efficiency-directive/penalties-and-fines.md): A practical enforcement guide for the Energy Efficiency Directive (EED): what the directive says about penalties (Article 32). - [EED FAQ (Directive (EU) 2023/1791) | Thresholds, Audits, ISO 50001, Action Plans, Data Centres](/artifacts/eu/energy-efficiency-directive/faq.md): High-signal answers to common EED questions: how to compute the 3-year average TJ. - [EED Reporting & Metrics (Directive (EU) 2023/1791) | Action Plans, Implementation Rate, Data Centres, Public Bodies](/artifacts/eu/energy-efficiency-directive/reporting-and-metrics.md): A practical reporting and metrics guide for EED compliance: what to track to support Article 11 thresholds and route decisions. - [EED Requirements (Directive (EU) 2023/1791) | Article 11 Thresholds, Annex VI Audit Criteria, Data Centres](/artifacts/eu/energy-efficiency-directive/requirements.md): A practical requirements breakdown of the EU Energy Efficiency Directive (EED. - [EED Scope: Who Must Comply (Directive (EU) 2023/1791) | Enterprises, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply.md): A grounded scope guide for the Energy Efficiency Directive (EED. - [EED Timeline | Key Dates for Directive (EU) 2023/1791 (Transposition, Audits, EMS, Data Centres)](/artifacts/eu/energy-efficiency-directive/timeline.md): A high-signal timeline guide for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED vs CSRD | How Energy Efficiency Compliance Feeds Sustainability Reporting (and What It Doesn't Replace)](/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd.md): A practical comparison of the Energy Efficiency Directive (EED, Directive (EU) 2023/1791) vs the Corporate Sustainability Reporting Directive (CSRD. - [Energy Audit Report Template (EED / EN 16247) | Annex VI-Aligned Structure + Acceptance Criteria](/artifacts/eu/energy-efficiency-directive/energy-audit-report-template.md): A practical energy audit report template aligned to the EED (Directive (EU) 2023/1791) and its Annex VI minimum criteria. - [ISO 50001 vs EED | How a Certified Energy Management System Satisfies EED Article 11 (and What EED Adds)](/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive.md): A practical comparison of ISO 50001 vs the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): ISO 50001 is the EMS standard. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/energy-efficiency-directive/applicability-test --- --- title: "EED Checklist (Directive (EU) 2023/1791)" canonical_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/checklist" source_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/checklist" author: "Sorena AI" description: "An audit-ready checklist for the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): scope and boundary memo, 85 TJ vs 10 TJ route decision." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Energy Efficiency Directive checklist" - "EED checklist" - "Directive (EU) 2023/1791 checklist" - "EED Article 11 compliance checklist" - "85 TJ energy management system checklist" - "10 TJ energy audit checklist" - "Annex VI energy audit criteria checklist" - "ISO 50001 EED" - "data centre reporting 500 kW checklist" - "Directive (EU) 2023/1791" - "energy audits" - "ISO 50001" - "data centres" - "public bodies" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EED Checklist (Directive (EU) 2023/1791) An audit-ready checklist for the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): scope and boundary memo, 85 TJ vs 10 TJ route decision. *Checklist* *EU* ## EU Energy Efficiency Directive (EED) Checklist A practical checklist for building a repeatable EED compliance program. Scope to route decision to audits/EMS to actions and reporting, with audit-ready evidence. Use this checklist as a program template. Your goal is to make EED compliance reproducible: the threshold route decision is traceable, audits meet Annex VI criteria, actions are tracked to measured savings, and recurring reporting (including data centres) runs on a calendar with clear owners. ## 1) Scope + boundary memo (do this first) Create a one-page scoping memo that you can export. It prevents the most common EED failure mode: inconsistent boundaries year-to-year. Treat this as a controlled artifact with approvals and version history. - Classify roles: enterprise / public body / data centre operator (you may be multiple). - Define organizational boundary (sites/entities included) and energy boundary (carriers included). - Compute 3-year average annual energy consumption (TJ) and store the calculation inputs and conversion factors. - Set change triggers (acquisitions/divestitures, new sites, major load changes) and review cadence (at least annually). ## 2) Route decision (Article 11): 85 TJ EMS vs 10 TJ audits Decide the route and store the decision. Don't start by buying audits or certifications without a controlled scope statement. Make the route decision a release gate for budgeting, procurement, and reporting. - > 85 TJ, 3 year average, implement a certified energy management system with the system in place by 11 October 2027. - > 10 TJ, 3 year average, and no EMS, carry out a first energy audit by 11 October 2026 and set the repeat cadence. - Define coverage, which sites and operations are included in EMS or audits and why. - Define owners, compliance or program owner, energy manager, facilities and operations leads, finance or controller, procurement lead. ## 3) Energy audit program (Annex VI quality gates) Annex VI minimum criteria is your audit QA checklist. Use it in the contract, kickoff, and acceptance review. Your acceptance criteria should be explicit: what data is required, what deliverables are required, and what is considered a "passed" audit. - Data readiness: measured, traceable operational data and (for electricity) load profiles are available and explainable. - Coverage: buildings, industrial operations/installations, and transport are reviewed where relevant. - Measures: report identifies efficiency measures and the potential for cost-effective renewable energy use/production. - Economics: life-cycle cost analysis used where possible; assumptions documented. - Storage: inputs and calculations are storable for historical tracking and year-over-year comparability. ## 4) Energy management system (EMS) implementation and certification If you're on the EMS route, treat certification scope as a control: it defines what is covered and what isn't. Run EMS and audits as a system: audits should feed actions; actions should feed measured savings and management review. - Define EMS scope statement (sites, operations, carriers, boundaries) and align it to the threshold memo. - Select certifier and plan audit schedule (stage 1 / stage 2 / surveillance) with evidence gates. - Set internal controls: training, roles/responsibilities, action tracking, management review cadence. - Maintain a structured evidence index (policies, procedures, records, internal audits, corrective actions). ## 5) Public bodies workstreams (link to national implementation) Public-sector obligations are implemented by Member States. Your operational control is to link the applicable national rules and align measurement and reporting. Treat reporting and building inventory duties as recurring workflows with clear owners. - Confirm public body status under national definition; document baseline and included consumption categories. - Set annual reduction planning and reporting workflow (data sources, QA, approvals, publication/reporting). - Public buildings: inventory ownership, update cadence, renovation planning evidence. - Procurement: add energy-efficiency criteria to procurement templates and approval flows where required. ## 6) Data centres: annual publication/reporting (>=500 kW installed IT demand) Treat data centre reporting like a compliance product: stable definitions, stable measurement method, and versioned publication output. Plan confidentiality handling so you can publish what is required without exposing protected information. - Determine whether installed IT power demand >= 500 kW, and document the measurement method and perimeter. - Set the annual calendar, data collection window, validation, publication date, European database submission, and retention policy. - Maintain publication history, submission confirmations, and year-over-year comparability notes. - If >= 1 MW, plan best-practice adoption and higher scrutiny readiness. *Recommended next step* *Placement: after the checklist block* ## Operationalize EU Energy Efficiency Directive (EED) Checklist across ESG workflows ESG Compliance can take EU Energy Efficiency Directive (EED) Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Energy Efficiency Directive (EED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Energy Efficiency Directive (EED) Checklist](/solutions/esg-compliance.md): Start from EU Energy Efficiency Directive (EED) Checklist and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Energy Efficiency Directive (EED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Energy Efficiency Directive (EED) Checklist. ## Primary sources - [Directive (EU) 2023/1791: Energy Efficiency Directive (official text)](https://eur-lex.europa.eu/eli/dir/2023/1791/oj?ref=sorena.io) - Article 11 thresholds, Annex VI audit criteria, data centre reporting obligations, and penalties framework. - [European Commission: Energy Efficiency Directive overview](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive_en?ref=sorena.io) - Official overview and links to guidance notes and sector pages. - [European Commission: Energy performance of data centres](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive/energy-performance-data-centres_en?ref=sorena.io) - Commission overview of the monitoring and reporting framework for data centres. - [Commission Delegated Regulation (EU) 2024/1364: data centre reporting scheme](https://eur-lex.europa.eu/eli/reg_del/2024/1364/oj/eng?ref=sorena.io) - Useful for the data centre portion of the compliance checklist. ## Related Topic Guides - [EED Applicability Test (Directive (EU) 2023/1791) | 85 TJ vs 10 TJ, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/applicability-test.md): A practical applicability test for the EU Energy Efficiency Directive (EED. - [EED Compliance Program (Directive (EU) 2023/1791) | How to Operationalize Article 11, Audits, ISO 50001, Reporting](/artifacts/eu/energy-efficiency-directive/compliance.md): A practical EED compliance playbook: governance, scope control, threshold route decision (85 TJ / 10 TJ), energy audit program (Annex VI quality gates). - [EED Deadlines & Compliance Calendar (Directive (EU) 2023/1791) | Transposition 11 Oct 2025, Data Centres 15 May](/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED Energy Audits (Directive (EU) 2023/1791 Article 11) | Annex VI Minimum Criteria + Action Plan + Reporting](/artifacts/eu/energy-efficiency-directive/energy-audits.md): A deep-dive on EED energy audits: who must do them (>10 TJ 3-year average if no EMS), deadlines (first audit by 11 Oct 2026. - [EED Energy Management System (EMS) (Directive (EU) 2023/1791 Article 11) | 85 TJ Threshold + ISO 50001 Certification](/artifacts/eu/energy-efficiency-directive/energy-management-systems.md): A practical guide to the EED EMS obligation: who must implement a certified energy management system (>85 TJ 3-year average). - [EED Enforcement (Penalties) | Directive (EU) 2023/1791 Article 32 + How to Reduce Risk](/artifacts/eu/energy-efficiency-directive/penalties-and-fines.md): A practical enforcement guide for the Energy Efficiency Directive (EED): what the directive says about penalties (Article 32). - [EED FAQ (Directive (EU) 2023/1791) | Thresholds, Audits, ISO 50001, Action Plans, Data Centres](/artifacts/eu/energy-efficiency-directive/faq.md): High-signal answers to common EED questions: how to compute the 3-year average TJ. - [EED Reporting & Metrics (Directive (EU) 2023/1791) | Action Plans, Implementation Rate, Data Centres, Public Bodies](/artifacts/eu/energy-efficiency-directive/reporting-and-metrics.md): A practical reporting and metrics guide for EED compliance: what to track to support Article 11 thresholds and route decisions. - [EED Requirements (Directive (EU) 2023/1791) | Article 11 Thresholds, Annex VI Audit Criteria, Data Centres](/artifacts/eu/energy-efficiency-directive/requirements.md): A practical requirements breakdown of the EU Energy Efficiency Directive (EED. - [EED Scope: Who Must Comply (Directive (EU) 2023/1791) | Enterprises, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply.md): A grounded scope guide for the Energy Efficiency Directive (EED. - [EED Timeline | Key Dates for Directive (EU) 2023/1791 (Transposition, Audits, EMS, Data Centres)](/artifacts/eu/energy-efficiency-directive/timeline.md): A high-signal timeline guide for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED vs CSRD | How Energy Efficiency Compliance Feeds Sustainability Reporting (and What It Doesn't Replace)](/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd.md): A practical comparison of the Energy Efficiency Directive (EED, Directive (EU) 2023/1791) vs the Corporate Sustainability Reporting Directive (CSRD. - [Energy Audit Report Template (EED / EN 16247) | Annex VI-Aligned Structure + Acceptance Criteria](/artifacts/eu/energy-efficiency-directive/energy-audit-report-template.md): A practical energy audit report template aligned to the EED (Directive (EU) 2023/1791) and its Annex VI minimum criteria. - [ISO 50001 vs EED | How a Certified Energy Management System Satisfies EED Article 11 (and What EED Adds)](/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive.md): A practical comparison of ISO 50001 vs the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): ISO 50001 is the EMS standard. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/energy-efficiency-directive/checklist --- --- title: "EED Compliance Program (Directive (EU) 2023/1791)" canonical_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/compliance" source_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/compliance" author: "Sorena AI" description: "A practical EED compliance playbook: governance, scope control, threshold route decision (85 TJ / 10 TJ), energy audit program (Annex VI quality gates)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EED compliance program" - "Energy Efficiency Directive compliance" - "Directive (EU) 2023/1791 compliance" - "EED Article 11 compliance" - "Annex VI energy audit criteria" - "ISO 50001 EED" - "energy audit cadence" - "EED evidence pack" - "data centre reporting 500 kW" - "EED compliance" - "energy audits" - "ISO 50001" - "program governance" - "data centres" - "public bodies" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EED Compliance Program (Directive (EU) 2023/1791) A practical EED compliance playbook: governance, scope control, threshold route decision (85 TJ / 10 TJ), energy audit program (Annex VI quality gates). *Compliance Playbook* *EU* ## EU Energy Efficiency Directive (EED) Compliance Program A repeatable program: route decision to audits/EMS to actions to reporting. Focus: evidence-first governance that survives turnover and scrutiny. The EED becomes manageable when you treat it as a program with controlled scope, clear owners, a calendar, and an evidence index. This page shows how to operationalize the directive across Article 11 thresholds, audit quality, EMS certification, public-sector workflows, and data centre reporting without building a bespoke process for every site. ## Program setup (week 1): define scope, owners, and the system of record Start with a controlled scope memo and a named program owner. Without this, audits and certifications drift across boundaries and create inconsistent evidence. Choose your system of record: where calculations, reports, certificates, and publications live, and how they are versioned. - Create a scope/boundary memo and approve it (enterprise/public body/data centre roles). - Assign owners: energy manager, facilities/ops leads, finance/controller, procurement lead, compliance lead. - Create an evidence index (a single table linking requirement to artifact to owner to location to review cadence). ## Route decision control: 85 TJ EMS vs 10 TJ audits (Article 11) Treat the route decision as a control. It must be reproducible: inputs, conversions, and the 3-year average TJ result are stored. Add retest triggers so you don't miss scope changes (M&A, new sites, major load changes). - Compute the 3 year average annual energy consumption across all carriers and store the calculation sheet. - Decide route, certified EMS above 85 TJ or energy audits above 10 TJ if no EMS is in place. - Document coverage, which sites and operations are included and why. - Refresh the route at least annually and whenever acquisition, divestiture, new site, or major load changes occur. ## Audit workstream: make Annex VI your QA gate Annex VI provides the minimum criteria for energy audits. Use it as your acceptance criteria in procurement and report review. Your best "risk reduction" move is to make the audit deliverables structured and storable for historical tracking. - Require measured, traceable operational data and electricity load profiles where relevant. - Require coverage across the relevant asset classes (buildings, processes, installations, transport). - Require life-cycle cost analysis where possible and documented assumptions. - Require a recommendations register with quantified savings potential and confidence level. ## EMS workstream: align certification scope to the threshold memo If you're on the EMS route, certification scope is your anchor. It must align with your enterprise boundary and energy boundary. Operate the EMS as a system: internal audits, corrective actions, management review, and action tracking tied to measured savings. - Write an EMS scope statement that matches the threshold memo and site coverage plan. - Plan certification: stage 1/stage 2 audits, surveillance cadence, and corrective action closure gates. - Track actions to outcomes: measured savings, operational changes, and verified implementation. ## Public bodies: convert "Member State obligations" into internal workflows Public-sector provisions are implemented nationally. Your operational goal is to create workflows for measurement, planning, and reporting that match national requirements. Treat inventory and renovation planning duties as recurring deliverables with owners and QA. - Maintain baseline definitions and included consumption categories (and document exclusions). - Run annual reduction planning and reporting as a calendar process with sign-offs. - Maintain public buildings inventory and renovation evidence and update cadence. ## Data centres: annual reporting is a product, build it like one If you meet the reporting trigger, the operational risk is inconsistency (changing definitions, changing boundaries, missing QA). Build one stable annual workflow from data collection to validation to publication to retention. - Document the installed IT power demand method and reporting perimeter, including sites, tenants, and shared services. - Define an annual reporting calendar and retention policy for publication and European database submissions. - Implement confidentiality review so you publish what is required without leaking protected data. - Track changes in methods or boundaries and explain how comparability is maintained. *Recommended next step* *Placement: after the compliance steps* ## Operationalize EU Energy Efficiency Directive (EED) Compliance Program across ESG workflows ESG Compliance can take EU Energy Efficiency Directive (EED) Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Energy Efficiency Directive (EED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Energy Efficiency Directive (EED) Compliance Program](/solutions/esg-compliance.md): Start from EU Energy Efficiency Directive (EED) Compliance Program and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Energy Efficiency Directive (EED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Energy Efficiency Directive (EED) Compliance Program. ## Primary sources - [Directive (EU) 2023/1791: Energy Efficiency Directive (official text)](https://eur-lex.europa.eu/eli/dir/2023/1791/oj?ref=sorena.io) - Enterprise thresholds (Article 11), Annex VI audit criteria, data centre reporting, and penalties framework. - [European Commission: Energy Efficiency Directive overview](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive_en?ref=sorena.io) - Official overview and links to guidance and sector obligations. - [European Commission: Energy performance of data centres](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive/energy-performance-data-centres_en?ref=sorena.io) - Commission overview of the monitoring and reporting framework for data centres. - [Commission Recommendation (EU) 2024/2002: Article 11 guidance](https://eur-lex.europa.eu/eli/reco/2024/2002/oj/eng?ref=sorena.io) - Useful for Article 11 program design and control expectations. - [Commission Delegated Regulation (EU) 2024/1364: data centre reporting scheme](https://eur-lex.europa.eu/eli/reg_del/2024/1364/oj/eng?ref=sorena.io) - Useful for designing the data centre reporting workflow. ## Related Topic Guides - [EED Applicability Test (Directive (EU) 2023/1791) | 85 TJ vs 10 TJ, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/applicability-test.md): A practical applicability test for the EU Energy Efficiency Directive (EED. - [EED Checklist (Directive (EU) 2023/1791) | Audit-Ready Steps for Article 11, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/checklist.md): An audit-ready checklist for the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): scope and boundary memo, 85 TJ vs 10 TJ route decision. - [EED Deadlines & Compliance Calendar (Directive (EU) 2023/1791) | Transposition 11 Oct 2025, Data Centres 15 May](/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED Energy Audits (Directive (EU) 2023/1791 Article 11) | Annex VI Minimum Criteria + Action Plan + Reporting](/artifacts/eu/energy-efficiency-directive/energy-audits.md): A deep-dive on EED energy audits: who must do them (>10 TJ 3-year average if no EMS), deadlines (first audit by 11 Oct 2026. - [EED Energy Management System (EMS) (Directive (EU) 2023/1791 Article 11) | 85 TJ Threshold + ISO 50001 Certification](/artifacts/eu/energy-efficiency-directive/energy-management-systems.md): A practical guide to the EED EMS obligation: who must implement a certified energy management system (>85 TJ 3-year average). - [EED Enforcement (Penalties) | Directive (EU) 2023/1791 Article 32 + How to Reduce Risk](/artifacts/eu/energy-efficiency-directive/penalties-and-fines.md): A practical enforcement guide for the Energy Efficiency Directive (EED): what the directive says about penalties (Article 32). - [EED FAQ (Directive (EU) 2023/1791) | Thresholds, Audits, ISO 50001, Action Plans, Data Centres](/artifacts/eu/energy-efficiency-directive/faq.md): High-signal answers to common EED questions: how to compute the 3-year average TJ. - [EED Reporting & Metrics (Directive (EU) 2023/1791) | Action Plans, Implementation Rate, Data Centres, Public Bodies](/artifacts/eu/energy-efficiency-directive/reporting-and-metrics.md): A practical reporting and metrics guide for EED compliance: what to track to support Article 11 thresholds and route decisions. - [EED Requirements (Directive (EU) 2023/1791) | Article 11 Thresholds, Annex VI Audit Criteria, Data Centres](/artifacts/eu/energy-efficiency-directive/requirements.md): A practical requirements breakdown of the EU Energy Efficiency Directive (EED. - [EED Scope: Who Must Comply (Directive (EU) 2023/1791) | Enterprises, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply.md): A grounded scope guide for the Energy Efficiency Directive (EED. - [EED Timeline | Key Dates for Directive (EU) 2023/1791 (Transposition, Audits, EMS, Data Centres)](/artifacts/eu/energy-efficiency-directive/timeline.md): A high-signal timeline guide for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED vs CSRD | How Energy Efficiency Compliance Feeds Sustainability Reporting (and What It Doesn't Replace)](/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd.md): A practical comparison of the Energy Efficiency Directive (EED, Directive (EU) 2023/1791) vs the Corporate Sustainability Reporting Directive (CSRD. - [Energy Audit Report Template (EED / EN 16247) | Annex VI-Aligned Structure + Acceptance Criteria](/artifacts/eu/energy-efficiency-directive/energy-audit-report-template.md): A practical energy audit report template aligned to the EED (Directive (EU) 2023/1791) and its Annex VI minimum criteria. - [ISO 50001 vs EED | How a Certified Energy Management System Satisfies EED Article 11 (and What EED Adds)](/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive.md): A practical comparison of ISO 50001 vs the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): ISO 50001 is the EMS standard. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/energy-efficiency-directive/compliance --- --- title: "EED Deadlines & Compliance Calendar (Directive (EU) 2023/1791)" canonical_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A practical compliance calendar for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Energy Efficiency Directive deadlines" - "EED compliance calendar" - "Directive (EU) 2023/1791 deadlines" - "EED transposition 11 October 2025" - "EED data centre reporting 15 May 2024" - "EED public buildings inventory 11 October 2025" - "EED timeline" - "EED deadlines" - "transposition" - "data centre reporting" - "public bodies" - "energy audits" - "ISO 50001" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EED Deadlines & Compliance Calendar (Directive (EU) 2023/1791) A practical compliance calendar for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. *Calendar* *EU* ## EU Energy Efficiency Directive (EED) Deadlines and Compliance Calendar Key dates plus a recurring compliance cadence you can run every year. Built from Directive (EU) 2023/1791 milestones, Article 11 deadlines, and the data centre reporting layer. The EED has a few hard dates and many recurring obligations. The practical trick is to convert the directive into a calendar you can execute: route decision review, audits/EMS checkpoints, public-body reporting and inventories, and data centre publication cycles. This page highlights the key dates and gives you a repeatable annual cadence. ## Hard dates (EU-level milestones you should anchor on) These dates come directly from the directive's provisions and are useful anchors even when national implementation details vary. Always validate national transposition details and sector-specific guidance for your Member State. - 10 October 2023, Directive (EU) 2023/1791 entered into force after publication in the Official Journal on 20 September 2023. - 15 May 2024, annual public availability obligation started for data centres meeting the >= 500 kW trigger. - 15 September 2024, first KPI submission deadline to the European database under Delegated Regulation (EU) 2024/1364. - 11 October 2025, Member States had to transpose the main recast provisions, and establish and publish the public buildings inventory required by Article 6. - 15 May 2025, the Commission had to assess the available data on data centre energy efficiency and report to Parliament and Council. - 11 October 2026, first energy audit deadline for enterprises on the audit route. - 11 October 2027, EMS must be in place for enterprises above 85 TJ, and the Commission must assess whether the Article 11 thresholds should be revised downward. - 11 October 2028, the Commission must report on that threshold assessment and may follow with legislative proposals. *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU Energy Efficiency Directive (EED) Deadlines and Compliance Calendar across ESG workflows ESG Compliance can take EU Energy Efficiency Directive (EED) Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Energy Efficiency Directive (EED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Energy Efficiency Directive (EED) Deadlines and Compliance Calendar](/solutions/esg-compliance.md): Start from EU Energy Efficiency Directive (EED) Deadlines and Compliance Calendar and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Energy Efficiency Directive (EED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Energy Efficiency Directive (EED) Deadlines and Compliance Calendar. ## Data centre compliance calendar (>=500 kW installed IT demand) If you are in scope for data centre reporting, build an annual reporting workflow with stable definitions and versioned outputs. This reduces year-over-year comparability issues and limits "surprise" publication scrambles. - T 10 weeks, confirm perimeter, installed IT power demand method, and which data sets must be published and submitted to the European database. - T 8 weeks, collect required metrics, validate completeness, and run confidentiality review. - T 4 weeks, finalize dataset and narrative, collect internal approvals, and prepare publication and database submission. - Publication and submission, publish the required Annex VII information and store the publication URL, database confirmation, and supporting calculations. - Post publication, review gaps, update SOPs, and set improvement actions for the next cycle. ## Enterprise calendar (Article 11): route decision, audits, EMS certification Enterprise obligations are threshold-driven. Convert them into a predictable yearly calendar to avoid drift. Even if your audits are every 4 years, you still need annual scope/control checks. - Annual Q1, refresh the boundary memo and 3 year average TJ calculation, and re confirm the Article 11 route. - Annual Q2, refresh the audit or EMS coverage plan for sites and carriers, and update provider or certifier schedules. - Annual Q3, run internal QA on data readiness, metering, invoices, and load profiles, and close gaps before audits or surveillance visits. - Annual Q4, run management review, approve the Action Plan budget, and prepare the annual report disclosure layer if you are on the audit route. - By 11 October 2026, complete the first audit if you are on the audit route. By 11 October 2027, have the EMS in place if you are on the EMS route. ## Public bodies calendar: reduction planning, inventories, renovation cadence Public-sector obligations depend on national implementation, but you can still create a reusable calendar pattern. Treat inventories and reporting as recurring deliverables, not one-time projects. - Annual, collect consumption data, run QA, and produce reduction planning or reporting outputs required by national law. - By 11 October 2025, establish the public buildings inventory, and update it at least every two years after that. - Through 11 October 2027, remember the Article 5 public-sector reduction target remains indicative at EU level while national implementation still applies. - Continuous, track renovation projects and procurement actions, and maintain the evidence folder and sign off trail. ## What to store (minimum evidence set) Calendars fail when evidence is missing. Make evidence exportable so you can respond to audits or authority questions quickly. Store evidence in a single index so you can answer what route applied, what was published, what changed, and who signed off. - Threshold route decision memo, including inputs, 3 year average TJ, outcome, and refresh date. - Audit reports meeting Annex VI criteria, plus the recommendations register, Action Plan, and implementation tracking. - EMS certification scope, certificates, surveillance schedule, and corrective action records. - Data centre publication outputs, European database submissions, calculations, approvals, and publication links. ## Primary sources - [Directive (EU) 2023/1791: Energy Efficiency Directive (official text)](https://eur-lex.europa.eu/eli/dir/2023/1791/oj?ref=sorena.io) - Source of transposition date, data centre publication cadence, public buildings inventory duty, and penalties notification deadline. - [European Commission: Energy performance of data centres](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive/energy-performance-data-centres_en?ref=sorena.io) - Commission guidance and context for the data centre monitoring/reporting framework. - [European Commission: Energy Efficiency Directive overview](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive_en?ref=sorena.io) - Official hub and links to guidance documents. - [Commission Recommendation (EU) 2024/2002: Article 11 guidance](https://eur-lex.europa.eu/eli/reco/2024/2002/oj/eng?ref=sorena.io) - Useful for planning Article 11 audit and EMS implementation steps and evidence expectations. - [Commission Delegated Regulation (EU) 2024/1364: data centre reporting scheme](https://eur-lex.europa.eu/eli/reg_del/2024/1364/oj/eng?ref=sorena.io) - Source for the European database reporting deadlines and KPI methodology for data centres. ## Related Topic Guides - [EED Applicability Test (Directive (EU) 2023/1791) | 85 TJ vs 10 TJ, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/applicability-test.md): A practical applicability test for the EU Energy Efficiency Directive (EED. - [EED Checklist (Directive (EU) 2023/1791) | Audit-Ready Steps for Article 11, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/checklist.md): An audit-ready checklist for the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): scope and boundary memo, 85 TJ vs 10 TJ route decision. - [EED Compliance Program (Directive (EU) 2023/1791) | How to Operationalize Article 11, Audits, ISO 50001, Reporting](/artifacts/eu/energy-efficiency-directive/compliance.md): A practical EED compliance playbook: governance, scope control, threshold route decision (85 TJ / 10 TJ), energy audit program (Annex VI quality gates). - [EED Energy Audits (Directive (EU) 2023/1791 Article 11) | Annex VI Minimum Criteria + Action Plan + Reporting](/artifacts/eu/energy-efficiency-directive/energy-audits.md): A deep-dive on EED energy audits: who must do them (>10 TJ 3-year average if no EMS), deadlines (first audit by 11 Oct 2026. - [EED Energy Management System (EMS) (Directive (EU) 2023/1791 Article 11) | 85 TJ Threshold + ISO 50001 Certification](/artifacts/eu/energy-efficiency-directive/energy-management-systems.md): A practical guide to the EED EMS obligation: who must implement a certified energy management system (>85 TJ 3-year average). - [EED Enforcement (Penalties) | Directive (EU) 2023/1791 Article 32 + How to Reduce Risk](/artifacts/eu/energy-efficiency-directive/penalties-and-fines.md): A practical enforcement guide for the Energy Efficiency Directive (EED): what the directive says about penalties (Article 32). - [EED FAQ (Directive (EU) 2023/1791) | Thresholds, Audits, ISO 50001, Action Plans, Data Centres](/artifacts/eu/energy-efficiency-directive/faq.md): High-signal answers to common EED questions: how to compute the 3-year average TJ. - [EED Reporting & Metrics (Directive (EU) 2023/1791) | Action Plans, Implementation Rate, Data Centres, Public Bodies](/artifacts/eu/energy-efficiency-directive/reporting-and-metrics.md): A practical reporting and metrics guide for EED compliance: what to track to support Article 11 thresholds and route decisions. - [EED Requirements (Directive (EU) 2023/1791) | Article 11 Thresholds, Annex VI Audit Criteria, Data Centres](/artifacts/eu/energy-efficiency-directive/requirements.md): A practical requirements breakdown of the EU Energy Efficiency Directive (EED. - [EED Scope: Who Must Comply (Directive (EU) 2023/1791) | Enterprises, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply.md): A grounded scope guide for the Energy Efficiency Directive (EED. - [EED Timeline | Key Dates for Directive (EU) 2023/1791 (Transposition, Audits, EMS, Data Centres)](/artifacts/eu/energy-efficiency-directive/timeline.md): A high-signal timeline guide for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED vs CSRD | How Energy Efficiency Compliance Feeds Sustainability Reporting (and What It Doesn't Replace)](/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd.md): A practical comparison of the Energy Efficiency Directive (EED, Directive (EU) 2023/1791) vs the Corporate Sustainability Reporting Directive (CSRD. - [Energy Audit Report Template (EED / EN 16247) | Annex VI-Aligned Structure + Acceptance Criteria](/artifacts/eu/energy-efficiency-directive/energy-audit-report-template.md): A practical energy audit report template aligned to the EED (Directive (EU) 2023/1791) and its Annex VI minimum criteria. - [ISO 50001 vs EED | How a Certified Energy Management System Satisfies EED Article 11 (and What EED Adds)](/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive.md): A practical comparison of ISO 50001 vs the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): ISO 50001 is the EMS standard. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar --- --- title: "Energy Audit Report Template (EED / EN 16247)" canonical_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/energy-audit-report-template" source_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/energy-audit-report-template" author: "Sorena AI" description: "A practical energy audit report template aligned to the EED (Directive (EU) 2023/1791) and its Annex VI minimum criteria." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "energy audit report template" - "EED energy audit report template" - "Annex VI energy audit criteria" - "EN 16247 audit report" - "life-cycle cost analysis energy audit" - "energy audit findings template" - "EED action plan template" - "EED" - "Annex VI" - "EN 16247" - "life-cycle cost" - "action plan" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Energy Audit Report Template (EED / EN 16247) A practical energy audit report template aligned to the EED (Directive (EU) 2023/1791) and its Annex VI minimum criteria. *Template* *EU* ## EU Energy Efficiency Directive (EED) Energy Audit Report Template A structured template that matches Annex VI expectations. Use this to standardize deliverables across sites and audit providers. Audit programs fail when reports are inconsistent and cannot be compared year to year. This template is designed to produce reports that meet EED minimum criteria in Annex VI, stay traceable back to measured data, and feed directly into a concrete and feasible Action Plan, management submission, and publishable reporting outputs. ## Template overview (what "good" looks like) A high-quality energy audit report is traceable (data-backed), comparable (stable structure), and actionable (clear measures with economics and feasibility). Use this template as a contract deliverable, not as an afterthought. - Traceability: measured, storable inputs; clear boundary definition; reproducible calculations. - Coverage: consumption profile review across relevant assets and carriers. - Actionability: measures ranked by feasibility, savings, and lifecycle economics. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Energy Efficiency Directive (EED) Energy Audit Report Template in one governed evidence system SSOT can take EU Energy Efficiency Directive (EED) Energy Audit Report Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Energy Efficiency Directive (EED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Energy Efficiency Directive (EED) Energy Audit Report Template](/solutions/ssot.md): Start from EU Energy Efficiency Directive (EED) Energy Audit Report Template and keep documents, evidence, and control records in one governed system. - [Talk through EU Energy Efficiency Directive (EED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Energy Efficiency Directive (EED) Energy Audit Report Template. ## Section 1: Executive summary Write for a decision-maker: the summary should stand alone and explain what is recommended and why. Keep sensitive details out of the summary if the report will be used for publication/reporting. - Audit scope and period (sites, carriers, boundary assumptions). - Top 5 measures (expected savings, investment range, implementation complexity). - Renewables potential summary (cost-effective opportunities). - Action Plan headline: timeline, owners, dependencies. ## Section 2: Scope, boundaries, and method This section defends the audit: what was covered, what was excluded, and why. If the boundary is unclear, everything downstream is vulnerable. - Organizational boundary: entities and sites included; treatment of acquisitions/divestitures. - Energy boundary: carriers included (electricity, fuels, purchased heat/cooling, transport fuels). - Method: standards used (e.g., EN 16247-1) and how Annex VI criteria are satisfied. - Limitations and data gaps: what was estimated and how uncertainty is handled. ## Section 3: Data and consumption profile (measured + traceable) Annex VI expects up-to-date, measured, traceable operational data and load profiles for electricity. This is the section auditors will challenge first. - Data sources: meters, invoices, BMS/EMS exports, fleet logs; include source identifiers. - Electricity load profiles: representative profiles and key peaks/constraints explained. - Consumption profile: breakdown by carrier, site, process, and time; identify material drivers. ## Section 4: Measures and savings (the recommendations register) Make measures comparable. Use a standard row format so you can aggregate across sites. Each measure should have a feasibility decision path (do/skip/defer) and a measurement approach. - Measure ID, description, affected assets, prerequisites/dependencies. - Expected savings (by carrier), confidence level, and verification method. - Costs: CAPEX/OPEX ranges and lifecycle economics (preferred to simple payback). - Risks: operational disruption, supply constraints, maintenance, safety. ## Section 5: Renewables potential (cost-effective use/production) Annex VI expects identification of potential for cost-effective renewable energy use or production. This section can be high-level but must be evidence-backed and bounded. - On-site generation potential and constraints, including space, grid, and permitting. - Electrification opportunities and impacts on load profile and peak demand. - Interaction with efficiency measures, do efficiency first so systems are right-sized. ## Section 6: Action Plan appendix (feasible delivery system) The EED links audits to a feasible Action Plan. Make the Action Plan exportable and owner-assigned. This appendix is the bridge between audit and implementation. - Recommendation, decision, rationale, owner, due date, budget, and measurement method. - Management submission record, sign offs, prioritization, and approved resources. - Implementation-rate tracking fields for annual report publication and public-availability controls. ## Primary sources - [Directive (EU) 2023/1791: Energy Efficiency Directive (official text)](https://eur-lex.europa.eu/eli/dir/2023/1791/oj?ref=sorena.io) - Annex VI minimum criteria and Article 11 audit obligations and Action Plan expectations. - [EN 16247-1:2022: Energy audits (catalog summary)](https://standards.iteh.ai/catalog/standards/cen/3fbb3fd5-0106-42d0-8b9f-cb546db8465a/en-16247-1-2022?ref=sorena.io) - Energy audit requirements, methodology, and deliverables. ## Related Topic Guides - [EED Applicability Test (Directive (EU) 2023/1791) | 85 TJ vs 10 TJ, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/applicability-test.md): A practical applicability test for the EU Energy Efficiency Directive (EED. - [EED Checklist (Directive (EU) 2023/1791) | Audit-Ready Steps for Article 11, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/checklist.md): An audit-ready checklist for the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): scope and boundary memo, 85 TJ vs 10 TJ route decision. - [EED Compliance Program (Directive (EU) 2023/1791) | How to Operationalize Article 11, Audits, ISO 50001, Reporting](/artifacts/eu/energy-efficiency-directive/compliance.md): A practical EED compliance playbook: governance, scope control, threshold route decision (85 TJ / 10 TJ), energy audit program (Annex VI quality gates). - [EED Deadlines & Compliance Calendar (Directive (EU) 2023/1791) | Transposition 11 Oct 2025, Data Centres 15 May](/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED Energy Audits (Directive (EU) 2023/1791 Article 11) | Annex VI Minimum Criteria + Action Plan + Reporting](/artifacts/eu/energy-efficiency-directive/energy-audits.md): A deep-dive on EED energy audits: who must do them (>10 TJ 3-year average if no EMS), deadlines (first audit by 11 Oct 2026. - [EED Energy Management System (EMS) (Directive (EU) 2023/1791 Article 11) | 85 TJ Threshold + ISO 50001 Certification](/artifacts/eu/energy-efficiency-directive/energy-management-systems.md): A practical guide to the EED EMS obligation: who must implement a certified energy management system (>85 TJ 3-year average). - [EED Enforcement (Penalties) | Directive (EU) 2023/1791 Article 32 + How to Reduce Risk](/artifacts/eu/energy-efficiency-directive/penalties-and-fines.md): A practical enforcement guide for the Energy Efficiency Directive (EED): what the directive says about penalties (Article 32). - [EED FAQ (Directive (EU) 2023/1791) | Thresholds, Audits, ISO 50001, Action Plans, Data Centres](/artifacts/eu/energy-efficiency-directive/faq.md): High-signal answers to common EED questions: how to compute the 3-year average TJ. - [EED Reporting & Metrics (Directive (EU) 2023/1791) | Action Plans, Implementation Rate, Data Centres, Public Bodies](/artifacts/eu/energy-efficiency-directive/reporting-and-metrics.md): A practical reporting and metrics guide for EED compliance: what to track to support Article 11 thresholds and route decisions. - [EED Requirements (Directive (EU) 2023/1791) | Article 11 Thresholds, Annex VI Audit Criteria, Data Centres](/artifacts/eu/energy-efficiency-directive/requirements.md): A practical requirements breakdown of the EU Energy Efficiency Directive (EED. - [EED Scope: Who Must Comply (Directive (EU) 2023/1791) | Enterprises, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply.md): A grounded scope guide for the Energy Efficiency Directive (EED. - [EED Timeline | Key Dates for Directive (EU) 2023/1791 (Transposition, Audits, EMS, Data Centres)](/artifacts/eu/energy-efficiency-directive/timeline.md): A high-signal timeline guide for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED vs CSRD | How Energy Efficiency Compliance Feeds Sustainability Reporting (and What It Doesn't Replace)](/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd.md): A practical comparison of the Energy Efficiency Directive (EED, Directive (EU) 2023/1791) vs the Corporate Sustainability Reporting Directive (CSRD. - [ISO 50001 vs EED | How a Certified Energy Management System Satisfies EED Article 11 (and What EED Adds)](/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive.md): A practical comparison of ISO 50001 vs the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): ISO 50001 is the EMS standard. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/energy-efficiency-directive/energy-audit-report-template --- --- title: "EED Energy Audits (Directive (EU) 2023/1791 Article 11)" canonical_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/energy-audits" source_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/energy-audits" author: "Sorena AI" description: "A deep-dive on EED energy audits: who must do them (>10 TJ 3-year average if no EMS), deadlines (first audit by 11 Oct 2026." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EED energy audits" - "Energy Efficiency Directive energy audit" - "Directive (EU) 2023/1791 Article 11 energy audit" - "Annex VI minimum criteria energy audits" - "EN 16247-1 energy audit" - "first energy audit 11 October 2026" - "energy audit every four years" - "EED action plan audit recommendations" - "EED annual report implementation rate" - "Directive (EU) 2023/1791" - "Annex VI" - "action plan" - "EN 16247" - "reporting" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EED Energy Audits (Directive (EU) 2023/1791 Article 11) A deep-dive on EED energy audits: who must do them (>10 TJ 3-year average if no EMS), deadlines (first audit by 11 Oct 2026. *Deep Dive* *EU* ## EU Energy Efficiency Directive (EED) Energy Audits How to run EED audits that withstand scrutiny and drive real savings. Focus: Article 11 audit obligation + Annex VI minimum criteria + Action Plan + reporting. An EED audit program is more than a one-off report. Directive (EU) 2023/1791 ties audits to (1) quality criteria (Annex VI), (2) deadlines and cadence, (3) a concrete Action Plan based on recommendations, and (4) publication/reporting expectations (subject to confidentiality protections). This page shows how to build an audit workflow that is defensible and operationally useful. ## Who must do EED energy audits (and when) The audit obligation is threshold-based. If your enterprise exceeds the 10 TJ threshold (3-year average annual consumption across all energy carriers) and you do not implement a certified energy management system, you are in the audit route. The directive specifies an initial deadline and a recurring cadence. - Trigger, > 10 TJ, 3 year average annual energy consumption across all carriers, and no EMS in place. - Deadline, first energy audit by 11 October 2026. - Cadence, subsequent audits at least every four years, with annual scope and data-readiness checks in between. - Annual authority visibility, where annual consumption is above the threshold in a given year, be ready to make that information available to the competent national authority. ## Annex VI minimum criteria (turn this into your QA checklist) Annex VI defines minimum criteria for energy audits (including those performed as part of an energy management system). The fastest way to reduce audit and enforcement risk is to embed these criteria in your audit contract and acceptance review. - Use up-to-date, measured, traceable operational data; include load profiles for electricity. - Review energy consumption profile across relevant assets (buildings, industrial operations/installations, transport). - Identify efficiency measures and potential for cost-effective renewables use/production. - Prefer life-cycle cost analysis over simple payback where possible; ensure data is storable for historical tracking. ## Audit scope design: coverage, boundaries, and worst-case pitfalls Most "bad audits" fail on scope: wrong boundary, missing carriers, missing operational data, or a report that can't be compared year-to-year. Design scope like a control: define what is covered, what isn't, and why. - Boundary memo: sites/entities included; carriers included; treatment of acquisitions/divestitures. - Data pack: invoices/metering sources, conversion factors, and audit-period timeline. - Coverage matrix: buildings/processes/transport reviewed; identify intentionally excluded items and rationale. - Deliverables: a recommendations register with quantified savings potential and confidence level. ## From recommendations to Action Plan (required operational output) Directive (EU) 2023/1791 expects enterprises to draw up a concrete and feasible Action Plan based on the audit recommendations, for measures that are technically or economically feasible. Treat the Action Plan like a delivery system with owners, milestones, budget, dependencies, measurement approach, and a management submission record. - Action Plan structure, recommendation, decision, rationale, owner, due date, expected savings, budget, and measurement method. - Management submission, store sign offs and resource allocation decisions, because the directive explicitly requires submission to management. - Implementation rate, define completion consistently, track it in the action register, and prepare the annual report disclosure layer. - Public availability, be ready to publish the Action Plan and recommendation implementation rate, subject to trade and business secret protections. ## Reporting and publication: plan confidentiality and versioning The directive links audit outcomes to annual reporting and public availability, subject to trade and business secret protections. Build a publication-ready summary that separates sensitive details from the required disclosures and from the evidence you may need to provide to national authorities. - Define what is publishable (e.g., high-level implementation rate and themes) vs confidential (site-specific vulnerabilities, cost details). - Version outputs: year, boundary, and method changes documented. - Store the published output link and the internal full evidence pack for audit readiness. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Energy Efficiency Directive (EED) Energy Audits in one governed evidence system SSOT can take EU Energy Efficiency Directive (EED) Energy Audits from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Energy Efficiency Directive (EED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Energy Efficiency Directive (EED) Energy Audits](/solutions/ssot.md): Start from EU Energy Efficiency Directive (EED) Energy Audits and keep documents, evidence, and control records in one governed system. - [Talk through EU Energy Efficiency Directive (EED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Energy Efficiency Directive (EED) Energy Audits. ## Primary sources - [Directive (EU) 2023/1791: Energy Efficiency Directive (official text)](https://eur-lex.europa.eu/eli/dir/2023/1791/oj?ref=sorena.io) - Article 11 audit obligation (thresholds, deadlines, cadence, Action Plan and publication) and Annex VI minimum criteria. - [EN 16247-1:2022: Energy audits (catalog summary)](https://standards.iteh.ai/catalog/standards/cen/3fbb3fd5-0106-42d0-8b9f-cb546db8465a/en-16247-1-2022?ref=sorena.io) - Practical framing of energy audit methodology and deliverables. - [European Commission: Energy Efficiency Directive overview](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive_en?ref=sorena.io) - Official overview and links to guidance notes. - [Commission Recommendation (EU) 2024/2002: Article 11 guidance](https://eur-lex.europa.eu/eli/reco/2024/2002/oj/eng?ref=sorena.io) - Commission guidance on energy audits, EMS, Action Plans, and publication expectations under Article 11. ## Related Topic Guides - [EED Applicability Test (Directive (EU) 2023/1791) | 85 TJ vs 10 TJ, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/applicability-test.md): A practical applicability test for the EU Energy Efficiency Directive (EED. - [EED Checklist (Directive (EU) 2023/1791) | Audit-Ready Steps for Article 11, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/checklist.md): An audit-ready checklist for the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): scope and boundary memo, 85 TJ vs 10 TJ route decision. - [EED Compliance Program (Directive (EU) 2023/1791) | How to Operationalize Article 11, Audits, ISO 50001, Reporting](/artifacts/eu/energy-efficiency-directive/compliance.md): A practical EED compliance playbook: governance, scope control, threshold route decision (85 TJ / 10 TJ), energy audit program (Annex VI quality gates). - [EED Deadlines & Compliance Calendar (Directive (EU) 2023/1791) | Transposition 11 Oct 2025, Data Centres 15 May](/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED Energy Management System (EMS) (Directive (EU) 2023/1791 Article 11) | 85 TJ Threshold + ISO 50001 Certification](/artifacts/eu/energy-efficiency-directive/energy-management-systems.md): A practical guide to the EED EMS obligation: who must implement a certified energy management system (>85 TJ 3-year average). - [EED Enforcement (Penalties) | Directive (EU) 2023/1791 Article 32 + How to Reduce Risk](/artifacts/eu/energy-efficiency-directive/penalties-and-fines.md): A practical enforcement guide for the Energy Efficiency Directive (EED): what the directive says about penalties (Article 32). - [EED FAQ (Directive (EU) 2023/1791) | Thresholds, Audits, ISO 50001, Action Plans, Data Centres](/artifacts/eu/energy-efficiency-directive/faq.md): High-signal answers to common EED questions: how to compute the 3-year average TJ. - [EED Reporting & Metrics (Directive (EU) 2023/1791) | Action Plans, Implementation Rate, Data Centres, Public Bodies](/artifacts/eu/energy-efficiency-directive/reporting-and-metrics.md): A practical reporting and metrics guide for EED compliance: what to track to support Article 11 thresholds and route decisions. - [EED Requirements (Directive (EU) 2023/1791) | Article 11 Thresholds, Annex VI Audit Criteria, Data Centres](/artifacts/eu/energy-efficiency-directive/requirements.md): A practical requirements breakdown of the EU Energy Efficiency Directive (EED. - [EED Scope: Who Must Comply (Directive (EU) 2023/1791) | Enterprises, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply.md): A grounded scope guide for the Energy Efficiency Directive (EED. - [EED Timeline | Key Dates for Directive (EU) 2023/1791 (Transposition, Audits, EMS, Data Centres)](/artifacts/eu/energy-efficiency-directive/timeline.md): A high-signal timeline guide for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED vs CSRD | How Energy Efficiency Compliance Feeds Sustainability Reporting (and What It Doesn't Replace)](/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd.md): A practical comparison of the Energy Efficiency Directive (EED, Directive (EU) 2023/1791) vs the Corporate Sustainability Reporting Directive (CSRD. - [Energy Audit Report Template (EED / EN 16247) | Annex VI-Aligned Structure + Acceptance Criteria](/artifacts/eu/energy-efficiency-directive/energy-audit-report-template.md): A practical energy audit report template aligned to the EED (Directive (EU) 2023/1791) and its Annex VI minimum criteria. - [ISO 50001 vs EED | How a Certified Energy Management System Satisfies EED Article 11 (and What EED Adds)](/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive.md): A practical comparison of ISO 50001 vs the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): ISO 50001 is the EMS standard. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/energy-efficiency-directive/energy-audits --- --- title: "EED vs CSRD" canonical_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd" source_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd" author: "Sorena AI" description: "A practical comparison of the Energy Efficiency Directive (EED, Directive (EU) 2023/1791) vs the Corporate Sustainability Reporting Directive (CSRD." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EED vs CSRD" - "Energy Efficiency Directive vs CSRD" - "Directive (EU) 2023/1791 vs Directive (EU) 2022/2464" - "energy audits CSRD reporting" - "ISO 50001 CSRD" - "EED action plan annual report" - "sustainability reporting energy efficiency" - "Directive (EU) 2023/1791" - "Directive (EU) 2022/2464" - "energy audits" - "ISO 50001" - "assurance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EED vs CSRD A practical comparison of the Energy Efficiency Directive (EED, Directive (EU) 2023/1791) vs the Corporate Sustainability Reporting Directive (CSRD. *Comparison* *EU* ## EU Energy Efficiency Directive vs CSRD EED is operational compliance. CSRD is sustainability reporting. Use EED evidence to strengthen CSRD disclosures, but do not confuse reporting with compliance duties. Teams often over-focus on reporting and under-invest in the operational systems that produce defensible numbers. The EED, Directive (EU) 2023/1791, creates concrete operational obligations, route decisions, audits or EMS, concrete and feasible Action Plans, annual report publication of the recommendation implementation rate for the audit route, and data centre publication. CSRD, Directive (EU) 2022/2464, is a reporting and assurance regime. The smart approach is to build one shared evidence index so EED artifacts feed CSRD reporting without confusing what each regime legally requires. ## Core difference: obligations vs disclosures EED: drives operational actions and recurring compliance deliverables (route decision, audits/EMS, Action Plans, and sector reporting like data centres). CSRD: drives what you must disclose and how disclosures are governed, assured, and reported. - EED asks what you must do and publish because of energy efficiency rules, route decision, audits or EMS, Action Plans, and data centre outputs. - CSRD asks what you must disclose about sustainability impacts, risks, opportunities, metrics, governance, and strategy. - CSRD does not replace EED obligations, and an ESRS disclosure cannot substitute for an Article 11 route memo or Action Plan workflow. *Recommended next step* *Placement: after the comparison section* ## Use EU Energy Efficiency Directive vs CSRD as a cited research workflow Research Copilot can take EU Energy Efficiency Directive vs CSRD from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Energy Efficiency Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Energy Efficiency Directive vs CSRD](/solutions/research-copilot.md): Start from EU Energy Efficiency Directive vs CSRD and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Energy Efficiency Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU Energy Efficiency Directive vs CSRD. ## Where EED evidence helps CSRD (high-leverage reuse) EED forces you to build data and governance around energy use, measures, and implementation, which is exactly the kind of traceability CSRD assurance benefits from. The key is to reuse artifacts, not to merge obligations. - Energy data traceability, metering and invoices, conversion factors, load profiles, and boundary definitions. - Measures pipeline, audit findings to Action Plans to implementation tracking to measured savings. - Governance, management review cadence, owner assignments, sign off trails, and annual report publication controls. - Data centre outputs, stable definitions, recurring publication workflows, and database submission records. ## What not to do (common mistakes) Most mistakes happen when teams treat CSRD as "make a report" and EED as "do an audit once". Avoid these and you'll reduce rework and assurance friction. - Publishing untraceable energy metrics with no boundary memo, QA record, or version history. - Treating audit recommendations as optional notes instead of feeding a concrete and feasible Action Plan and implementation-rate tracking. - Building separate systems, one for compliance and one for reporting, that cannot reconcile. - Leaking sensitive operational data because you did not separate internal evidence from publishable summaries. ## A shared evidence index model (works for both) Create one evidence index that links requirements/disclosure needs to artifacts and owners. This becomes your "single source of truth" for both compliance audits and reporting assurance. - Route decision memo (EED Article 11): 3-year average TJ inputs and outcome. - Audit reports + Annex VI QA checklist + recommendations register. - Action Plan tracker + implementation rate definition and aggregation method. - EMS certification evidence (if applicable) + management review outputs. - Publication outputs: annual report disclosure snippets and data centre annual publication package. ## Primary sources - [Directive (EU) 2023/1791: Energy Efficiency Directive (official text)](https://eur-lex.europa.eu/eli/dir/2023/1791/oj?ref=sorena.io) - Operational obligations for audits/EMS, Action Plans, and sector publication like data centres. - [Directive (EU) 2022/2464: Corporate Sustainability Reporting Directive (CSRD) (official text)](https://eur-lex.europa.eu/eli/dir/2022/2464/oj?ref=sorena.io) - Sustainability reporting and disclosure framework in EU law. - [European Commission: Energy Efficiency Directive overview](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive_en?ref=sorena.io) - Official overview and guidance resources. - [Commission Recommendation (EU) 2024/2002: Article 11 guidance](https://eur-lex.europa.eu/eli/reco/2024/2002/oj/eng?ref=sorena.io) - Useful for understanding the operational outputs the EED requires before any CSRD reuse. ## Related Topic Guides - [EED Applicability Test (Directive (EU) 2023/1791) | 85 TJ vs 10 TJ, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/applicability-test.md): A practical applicability test for the EU Energy Efficiency Directive (EED. - [EED Checklist (Directive (EU) 2023/1791) | Audit-Ready Steps for Article 11, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/checklist.md): An audit-ready checklist for the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): scope and boundary memo, 85 TJ vs 10 TJ route decision. - [EED Compliance Program (Directive (EU) 2023/1791) | How to Operationalize Article 11, Audits, ISO 50001, Reporting](/artifacts/eu/energy-efficiency-directive/compliance.md): A practical EED compliance playbook: governance, scope control, threshold route decision (85 TJ / 10 TJ), energy audit program (Annex VI quality gates). - [EED Deadlines & Compliance Calendar (Directive (EU) 2023/1791) | Transposition 11 Oct 2025, Data Centres 15 May](/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED Energy Audits (Directive (EU) 2023/1791 Article 11) | Annex VI Minimum Criteria + Action Plan + Reporting](/artifacts/eu/energy-efficiency-directive/energy-audits.md): A deep-dive on EED energy audits: who must do them (>10 TJ 3-year average if no EMS), deadlines (first audit by 11 Oct 2026. - [EED Energy Management System (EMS) (Directive (EU) 2023/1791 Article 11) | 85 TJ Threshold + ISO 50001 Certification](/artifacts/eu/energy-efficiency-directive/energy-management-systems.md): A practical guide to the EED EMS obligation: who must implement a certified energy management system (>85 TJ 3-year average). - [EED Enforcement (Penalties) | Directive (EU) 2023/1791 Article 32 + How to Reduce Risk](/artifacts/eu/energy-efficiency-directive/penalties-and-fines.md): A practical enforcement guide for the Energy Efficiency Directive (EED): what the directive says about penalties (Article 32). - [EED FAQ (Directive (EU) 2023/1791) | Thresholds, Audits, ISO 50001, Action Plans, Data Centres](/artifacts/eu/energy-efficiency-directive/faq.md): High-signal answers to common EED questions: how to compute the 3-year average TJ. - [EED Reporting & Metrics (Directive (EU) 2023/1791) | Action Plans, Implementation Rate, Data Centres, Public Bodies](/artifacts/eu/energy-efficiency-directive/reporting-and-metrics.md): A practical reporting and metrics guide for EED compliance: what to track to support Article 11 thresholds and route decisions. - [EED Requirements (Directive (EU) 2023/1791) | Article 11 Thresholds, Annex VI Audit Criteria, Data Centres](/artifacts/eu/energy-efficiency-directive/requirements.md): A practical requirements breakdown of the EU Energy Efficiency Directive (EED. - [EED Scope: Who Must Comply (Directive (EU) 2023/1791) | Enterprises, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply.md): A grounded scope guide for the Energy Efficiency Directive (EED. - [EED Timeline | Key Dates for Directive (EU) 2023/1791 (Transposition, Audits, EMS, Data Centres)](/artifacts/eu/energy-efficiency-directive/timeline.md): A high-signal timeline guide for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [Energy Audit Report Template (EED / EN 16247) | Annex VI-Aligned Structure + Acceptance Criteria](/artifacts/eu/energy-efficiency-directive/energy-audit-report-template.md): A practical energy audit report template aligned to the EED (Directive (EU) 2023/1791) and its Annex VI minimum criteria. - [ISO 50001 vs EED | How a Certified Energy Management System Satisfies EED Article 11 (and What EED Adds)](/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive.md): A practical comparison of ISO 50001 vs the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): ISO 50001 is the EMS standard. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd --- --- title: "EED Energy Management System (EMS) (Directive (EU) 2023/1791 Article 11)" canonical_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/energy-management-systems" source_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/energy-management-systems" author: "Sorena AI" description: "A practical guide to the EED EMS obligation: who must implement a certified energy management system (>85 TJ 3-year average)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EED energy management system" - "Energy Efficiency Directive EMS" - "Directive (EU) 2023/1791 Article 11 EMS" - "85 TJ ISO 50001 certification" - "certified energy management system EU" - "independent certification body ISO 50001" - "EED EMS deadline 11 October 2027" - "ISO 50001" - "certification" - "Article 11" - "program scope" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EED Energy Management System (EMS) (Directive (EU) 2023/1791 Article 11) A practical guide to the EED EMS obligation: who must implement a certified energy management system (>85 TJ 3-year average). *Deep Dive* *EU* ## EU Energy Efficiency Directive (EED) Energy Management Systems How to implement a certified EMS that matches your scope and produces measurable results. Focus: Article 11 85 TJ trigger, certification, evidence, and integration with audits and Action Plans. Directive (EU) 2023/1791 requires enterprises above the 85 TJ threshold to implement an energy management system and have it certified by an independent body in line with relevant standards, commonly ISO 50001. The hard part is not writing policies, it is scoping the EMS correctly, ensuring data quality, aligning the certification scope to the threshold calculation, and making the system drive actions and measurable savings year after year. ## Who needs a certified EMS (and by when) The EMS route is triggered by a 3-year average annual energy consumption threshold, across all energy carriers together. The directive also sets a latest date by which the EMS must be in place (as implemented by Member States). - Trigger, enterprises with average annual consumption > 85 TJ over the previous three years, across all carriers. - Certification, the EMS must be certified by an independent body in accordance with relevant European or international standards. - Timeline, Member States must ensure the EMS is in place by 11 October 2027. - Annual authority visibility, where annual consumption is above the threshold in a given year, be ready to make that information available to the national authority responsible for Article 11. ## Scope statement (the most important EMS control) Your EMS scope statement defines what is covered and drives certification credibility. Align it to the same boundaries used for the threshold calculation and any audit program coverage. - Sites and operations covered (and explicitly excluded) with rationale. - Energy carriers covered (electricity, fuels, purchased heat/cooling, transport fuels). - Operational boundaries (owned vs leased, shared services, tenants, outsourced operations). - Retest triggers and review cadence (M&A, new sites, major load changes). ## Data readiness: measured, traceable, and storable An EMS without strong data is a documentation exercise. Build measurement and traceability into the system from day one. Treat load profiles and metering as evidence, not just operational tooling. - Inventory data sources: meters, invoices, BMS/EMS exports, fleet fuel records; assign data owners. - Define QA gates: completeness checks, anomaly handling, and versioned conversion factors. - Store data for historical tracking and year-over-year comparability. ## Integrate audits + Action Plans into the EMS (so it drives outcomes) The EED does not let the EMS sit in isolation. Article 11 and the 2024 Commission guidance connect audits, recommendations, and Action Plans to a management and reporting workflow. Run audits as a feeder system for your EMS, findings to actions to verified implementation to measured savings to management review. - Maintain a recommendations register across sites and carriers with owners, due dates, and feasibility decisions. - Run management review on a set cadence and store the submission record for Action Plans, resource allocation, and savings verification. - Track implementation rate and prepare publishable summaries where required, while keeping sensitive operational detail internal. ## Certification evidence pack (what auditors typically expect) Certification audits move quickly when you have a single evidence index and can export artifacts. Build a structured evidence pack aligned to your EMS scope and processes. - Scope statement, boundary memo, and energy review summary. - Policies/procedures, roles and training records. - Internal audits and corrective actions tracking. - Action plans and savings tracking evidence (including measurement approach). - External certification reports and certificate(s), including surveillance schedule. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU Energy Efficiency Directive (EED) Energy Management Systems across ESG workflows ESG Compliance can take EU Energy Efficiency Directive (EED) Energy Management Systems from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU Energy Efficiency Directive (EED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Energy Efficiency Directive (EED) Energy Management Systems](/solutions/esg-compliance.md): Start from EU Energy Efficiency Directive (EED) Energy Management Systems and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Energy Efficiency Directive (EED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Energy Efficiency Directive (EED) Energy Management Systems. ## Primary sources - [Directive (EU) 2023/1791: Energy Efficiency Directive (official text)](https://eur-lex.europa.eu/eli/dir/2023/1791/oj?ref=sorena.io) - Article 11 EMS threshold, certification requirement, and latest date (11 October 2027). - [European Commission: Energy Efficiency Directive overview](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive_en?ref=sorena.io) - Official overview and guidance resources. - [Commission Recommendation (EU) 2024/2002: Article 11 guidance](https://eur-lex.europa.eu/eli/reco/2024/2002/oj/eng?ref=sorena.io) - Commission guidance on the Article 11 EMS route, threshold calculation, and certification interpretation. ## Related Topic Guides - [EED Applicability Test (Directive (EU) 2023/1791) | 85 TJ vs 10 TJ, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/applicability-test.md): A practical applicability test for the EU Energy Efficiency Directive (EED. - [EED Checklist (Directive (EU) 2023/1791) | Audit-Ready Steps for Article 11, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/checklist.md): An audit-ready checklist for the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): scope and boundary memo, 85 TJ vs 10 TJ route decision. - [EED Compliance Program (Directive (EU) 2023/1791) | How to Operationalize Article 11, Audits, ISO 50001, Reporting](/artifacts/eu/energy-efficiency-directive/compliance.md): A practical EED compliance playbook: governance, scope control, threshold route decision (85 TJ / 10 TJ), energy audit program (Annex VI quality gates). - [EED Deadlines & Compliance Calendar (Directive (EU) 2023/1791) | Transposition 11 Oct 2025, Data Centres 15 May](/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED Energy Audits (Directive (EU) 2023/1791 Article 11) | Annex VI Minimum Criteria + Action Plan + Reporting](/artifacts/eu/energy-efficiency-directive/energy-audits.md): A deep-dive on EED energy audits: who must do them (>10 TJ 3-year average if no EMS), deadlines (first audit by 11 Oct 2026. - [EED Enforcement (Penalties) | Directive (EU) 2023/1791 Article 32 + How to Reduce Risk](/artifacts/eu/energy-efficiency-directive/penalties-and-fines.md): A practical enforcement guide for the Energy Efficiency Directive (EED): what the directive says about penalties (Article 32). - [EED FAQ (Directive (EU) 2023/1791) | Thresholds, Audits, ISO 50001, Action Plans, Data Centres](/artifacts/eu/energy-efficiency-directive/faq.md): High-signal answers to common EED questions: how to compute the 3-year average TJ. - [EED Reporting & Metrics (Directive (EU) 2023/1791) | Action Plans, Implementation Rate, Data Centres, Public Bodies](/artifacts/eu/energy-efficiency-directive/reporting-and-metrics.md): A practical reporting and metrics guide for EED compliance: what to track to support Article 11 thresholds and route decisions. - [EED Requirements (Directive (EU) 2023/1791) | Article 11 Thresholds, Annex VI Audit Criteria, Data Centres](/artifacts/eu/energy-efficiency-directive/requirements.md): A practical requirements breakdown of the EU Energy Efficiency Directive (EED. - [EED Scope: Who Must Comply (Directive (EU) 2023/1791) | Enterprises, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply.md): A grounded scope guide for the Energy Efficiency Directive (EED. - [EED Timeline | Key Dates for Directive (EU) 2023/1791 (Transposition, Audits, EMS, Data Centres)](/artifacts/eu/energy-efficiency-directive/timeline.md): A high-signal timeline guide for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED vs CSRD | How Energy Efficiency Compliance Feeds Sustainability Reporting (and What It Doesn't Replace)](/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd.md): A practical comparison of the Energy Efficiency Directive (EED, Directive (EU) 2023/1791) vs the Corporate Sustainability Reporting Directive (CSRD. - [Energy Audit Report Template (EED / EN 16247) | Annex VI-Aligned Structure + Acceptance Criteria](/artifacts/eu/energy-efficiency-directive/energy-audit-report-template.md): A practical energy audit report template aligned to the EED (Directive (EU) 2023/1791) and its Annex VI minimum criteria. - [ISO 50001 vs EED | How a Certified Energy Management System Satisfies EED Article 11 (and What EED Adds)](/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive.md): A practical comparison of ISO 50001 vs the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): ISO 50001 is the EMS standard. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/energy-efficiency-directive/energy-management-systems --- --- title: "EED FAQ (Directive (EU) 2023/1791)" canonical_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/faq" source_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/faq" author: "Sorena AI" description: "High-signal answers to common EED questions: how to compute the 3-year average TJ." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EED FAQ" - "Energy Efficiency Directive FAQ" - "Directive (EU) 2023/1791 FAQ" - "85 TJ energy management system" - "10 TJ energy audit" - "Annex VI energy audit criteria" - "EED action plan" - "EED implementation rate annual report" - "data centre reporting 500 kW" - "Article 11" - "energy audits" - "ISO 50001" - "Annex VI" - "data centres" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EED FAQ (Directive (EU) 2023/1791) High-signal answers to common EED questions: how to compute the 3-year average TJ. *FAQ* *EU* ## EU Energy Efficiency Directive (EED) FAQ Fast answers with practical next steps and evidence guidance. Grounded in Directive (EU) 2023/1791 and Commission resources. This FAQ is written for teams implementing the EED in the real world. Each answer focuses on what to do next and what to store as evidence. Always validate against your Member State's implementation and any sector guidance. ## How do we compute the 85 TJ / 10 TJ thresholds? The thresholds are based on average annual energy consumption over the previous three years, taking all energy carriers together. Treat the calculation as a controlled artifact: boundary definition, data sources, conversion factors, and a reproducible spreadsheet. - Define organizational boundary (entities/sites included) and energy boundary (carriers included). - Use measured and traceable inputs where possible (invoices, metering, fleet logs). - Store the calculation sheet and retest triggers (M&A, new sites, major load changes). ## When do we need a certified EMS vs energy audits? Above 85 TJ (3-year average): the route is a certified energy management system (commonly aligned to ISO 50001). Above 10 TJ (3-year average) and not implementing an EMS: the route is energy audits with defined cadence and outputs. - EMS route, certified by an independent body, with the system in place by 11 October 2027. - Audit route, first audit by 11 October 2026 and at least every four years after that, with Annex VI minimum criteria. - Do not run both tracks as separate systems, integrate them under one evidence index and one boundary memo. ## What does Annex VI require for audit quality? Annex VI is your minimum criteria checklist. Use it in procurement and report acceptance. The main theme: measured and traceable data, sufficient coverage, and storable evidence. - Measured, traceable data and electricity load profiles where relevant. - Detailed consumption profile review (buildings, operations, transport where relevant). - Measures identified + renewables potential + lifecycle economics where possible. - Inputs and calculations storable for historical tracking. ## What is the Action Plan and what do we publish? For the audit route, the directive expects a concrete and feasible Action Plan based on audit recommendations. It also requires the Action Plans and the recommendation implementation rate to appear in the enterprise annual report and to be made publicly available, subject to confidentiality protections. - Action Plan: owners, due dates, budgets, dependencies, and savings verification method. - Implementation rate: define "implemented" consistently and track it in an action register. - Publishable layer: aggregated disclosure; keep sensitive operational details internal. ## How does the data centre 500 kW trigger work? Data centre obligations are triggered by installed IT power demand. Treat the measurement method and reporting perimeter as evidence. If triggered, plan an annual publication workflow with QA and versioning. - Determine whether installed IT power demand is >= 500 kW, and document the perimeter and method. - Set an annual calendar, data collection, validation, confidentiality review, publication, and database submission. - Store the publication URL, database confirmation, and internal raw dataset for traceability. - If you are >= 1 MW, plan for best-practice expectations and closer scrutiny on sustainability performance. *Recommended next step* *Placement: after the FAQ section* ## Use EU Energy Efficiency Directive (EED) FAQ as a cited research workflow Research Copilot can take EU Energy Efficiency Directive (EED) FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU Energy Efficiency Directive (EED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Energy Efficiency Directive (EED) FAQ](/solutions/research-copilot.md): Start from EU Energy Efficiency Directive (EED) FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Energy Efficiency Directive (EED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Energy Efficiency Directive (EED) FAQ. ## Primary sources - [Directive (EU) 2023/1791: Energy Efficiency Directive (official text)](https://eur-lex.europa.eu/eli/dir/2023/1791/oj?ref=sorena.io) - Article 11 thresholds and outputs; Annex VI minimum criteria; data centre annual publication cadence. - [European Commission: Energy Efficiency Directive overview](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive_en?ref=sorena.io) - Official overview and links to guidance notes. - [European Commission: Energy performance of data centres](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive/energy-performance-data-centres_en?ref=sorena.io) - Commission context and resources for data centre reporting. - [Commission Recommendation (EU) 2024/2002: Article 11 guidance](https://eur-lex.europa.eu/eli/reco/2024/2002/oj/eng?ref=sorena.io) - Commission guidance on threshold calculation, audits, EMS, and Article 11 outputs. ## Related Topic Guides - [EED Applicability Test (Directive (EU) 2023/1791) | 85 TJ vs 10 TJ, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/applicability-test.md): A practical applicability test for the EU Energy Efficiency Directive (EED. - [EED Checklist (Directive (EU) 2023/1791) | Audit-Ready Steps for Article 11, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/checklist.md): An audit-ready checklist for the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): scope and boundary memo, 85 TJ vs 10 TJ route decision. - [EED Compliance Program (Directive (EU) 2023/1791) | How to Operationalize Article 11, Audits, ISO 50001, Reporting](/artifacts/eu/energy-efficiency-directive/compliance.md): A practical EED compliance playbook: governance, scope control, threshold route decision (85 TJ / 10 TJ), energy audit program (Annex VI quality gates). - [EED Deadlines & Compliance Calendar (Directive (EU) 2023/1791) | Transposition 11 Oct 2025, Data Centres 15 May](/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED Energy Audits (Directive (EU) 2023/1791 Article 11) | Annex VI Minimum Criteria + Action Plan + Reporting](/artifacts/eu/energy-efficiency-directive/energy-audits.md): A deep-dive on EED energy audits: who must do them (>10 TJ 3-year average if no EMS), deadlines (first audit by 11 Oct 2026. - [EED Energy Management System (EMS) (Directive (EU) 2023/1791 Article 11) | 85 TJ Threshold + ISO 50001 Certification](/artifacts/eu/energy-efficiency-directive/energy-management-systems.md): A practical guide to the EED EMS obligation: who must implement a certified energy management system (>85 TJ 3-year average). - [EED Enforcement (Penalties) | Directive (EU) 2023/1791 Article 32 + How to Reduce Risk](/artifacts/eu/energy-efficiency-directive/penalties-and-fines.md): A practical enforcement guide for the Energy Efficiency Directive (EED): what the directive says about penalties (Article 32). - [EED Reporting & Metrics (Directive (EU) 2023/1791) | Action Plans, Implementation Rate, Data Centres, Public Bodies](/artifacts/eu/energy-efficiency-directive/reporting-and-metrics.md): A practical reporting and metrics guide for EED compliance: what to track to support Article 11 thresholds and route decisions. - [EED Requirements (Directive (EU) 2023/1791) | Article 11 Thresholds, Annex VI Audit Criteria, Data Centres](/artifacts/eu/energy-efficiency-directive/requirements.md): A practical requirements breakdown of the EU Energy Efficiency Directive (EED. - [EED Scope: Who Must Comply (Directive (EU) 2023/1791) | Enterprises, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply.md): A grounded scope guide for the Energy Efficiency Directive (EED. - [EED Timeline | Key Dates for Directive (EU) 2023/1791 (Transposition, Audits, EMS, Data Centres)](/artifacts/eu/energy-efficiency-directive/timeline.md): A high-signal timeline guide for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED vs CSRD | How Energy Efficiency Compliance Feeds Sustainability Reporting (and What It Doesn't Replace)](/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd.md): A practical comparison of the Energy Efficiency Directive (EED, Directive (EU) 2023/1791) vs the Corporate Sustainability Reporting Directive (CSRD. - [Energy Audit Report Template (EED / EN 16247) | Annex VI-Aligned Structure + Acceptance Criteria](/artifacts/eu/energy-efficiency-directive/energy-audit-report-template.md): A practical energy audit report template aligned to the EED (Directive (EU) 2023/1791) and its Annex VI minimum criteria. - [ISO 50001 vs EED | How a Certified Energy Management System Satisfies EED Article 11 (and What EED Adds)](/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive.md): A practical comparison of ISO 50001 vs the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): ISO 50001 is the EMS standard. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/energy-efficiency-directive/faq --- --- title: "ISO 50001 vs EED" canonical_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive" source_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive" author: "Sorena AI" description: "A practical comparison of ISO 50001 vs the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): ISO 50001 is the EMS standard." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "ISO 50001 vs EED" - "ISO 50001 Energy Efficiency Directive" - "EED ISO 50001 certified energy management system" - "Directive (EU) 2023/1791 Article 11 ISO 50001" - "85 TJ ISO 50001" - "certified EMS independent body" - "EED EMS deadline 11 October 2027" - "ISO 50001" - "EED" - "energy management system" - "certification" - "Article 11" - "compliance route" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 50001 vs EED A practical comparison of ISO 50001 vs the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): ISO 50001 is the EMS standard. *Comparison* *EU* ## ISO 50001 vs EED ISO 50001 is the EMS standard. The EED is the legal requirement. Use ISO 50001 as the operating system, and keep the EED triggers, deadlines, and outputs explicit. Most teams should not build a bespoke EED energy management system. The directive points to relevant European or international standards and requires certification by an independent body for the EMS route. In practice, ISO 50001 is the common way to operationalize the EED EMS requirement, but the EED still adds legal triggers, deadlines, authority-facing duties, and publication expectations that you must manage around the certified system. ## What each one is (and why they're often confused) ISO 50001: a management system standard for energy performance improvement and governance. EED (Directive (EU) 2023/1791): legal obligations with threshold triggers and specific deadlines and outputs. - ISO 50001 answers: how do we run an energy management system effectively? - EED answers: when is an EMS mandatory (85 TJ), when are audits mandatory (10 TJ if no EMS), and what must be reported/published? - A certified ISO 50001-aligned EMS is a strong way to satisfy the EED EMS route if scoped correctly. ## EED Article 11: where ISO 50001 fits The EED requires enterprises above the 85 TJ threshold to implement an energy management system and have it certified by an independent body in line with relevant standards. This aligns naturally with a certified ISO 50001 implementation. - Trigger, > 85 TJ 3 year average annual consumption across all carriers, means the certified EMS route. - Deadline, the EMS must be in place by 11 October 2027. - Control to get right, the EMS scope statement must align with the boundary used for the threshold calculation and with the evidence you may need to provide to national authorities. ## What the EED adds beyond the EMS standard Even with ISO 50001 in place, you still need to handle EED-specific outputs and adjacent obligations. Think of these as "compliance controls" wrapped around the EMS. - Threshold route decision memo, inputs, conversions, 3 year average TJ, outcome, and annual refresh cadence. - Authority-facing data, if annual consumption crosses the threshold in a given year, be ready to make that information available to the national authority responsible for Article 11. - Audit route obligations if you are not on the EMS route, first audit by 11 October 2026 and at least every four years, plus Action Plan and implementation-rate publication. - Data centre annual publication and public-sector workflows remain separate tracks if they apply. ## How to avoid duplicated systems (recommended architecture) The best pattern is one management system plus a thin EED compliance layer. Do not create separate ISO 50001 and EED systems, because they drift and cannot be reconciled. - One scope statement: used for ISO 50001 certification and EED route decisions. - One evidence index: links audits/records/actions/certificates to owners and review cadence. - One reporting layer: publishable summaries (implementation rates, themes) separated from internal sensitive evidence. *Recommended next step* *Placement: after the comparison section* ## Use ISO 50001 vs EED as a cited research workflow Research Copilot can take ISO 50001 vs EED from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on ISO 50001 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO 50001 vs EED](/solutions/research-copilot.md): Start from ISO 50001 vs EED and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO 50001](/contact.md): Review your current process, evidence gaps, and next steps for ISO 50001 vs EED. ## Primary sources - [Directive (EU) 2023/1791: Energy Efficiency Directive (official text)](https://eur-lex.europa.eu/eli/dir/2023/1791/oj?ref=sorena.io) - Article 11 threshold triggers and EMS certification requirement; audit deadlines; reporting expectations. - [European Commission: Study on minimum criteria for Energy Audits and Energy Management Systems](https://energy.ec.europa.eu/publications/study-guidance-member-states-minimum-criteria-energy-audits-and-energy-management-systems_en?ref=sorena.io) - Practical guidance background for minimum criteria and implementation patterns for audits and EMS. - [European Commission: Energy Efficiency Directive overview](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive_en?ref=sorena.io) - Official hub and links to guidance resources. - [Commission Recommendation (EU) 2024/2002: Article 11 guidance](https://eur-lex.europa.eu/eli/reco/2024/2002/oj/eng?ref=sorena.io) - Commission guidance on how Article 11 interacts with EMS certification and audits. ## Related Topic Guides - [EED Applicability Test (Directive (EU) 2023/1791) | 85 TJ vs 10 TJ, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/applicability-test.md): A practical applicability test for the EU Energy Efficiency Directive (EED. - [EED Checklist (Directive (EU) 2023/1791) | Audit-Ready Steps for Article 11, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/checklist.md): An audit-ready checklist for the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): scope and boundary memo, 85 TJ vs 10 TJ route decision. - [EED Compliance Program (Directive (EU) 2023/1791) | How to Operationalize Article 11, Audits, ISO 50001, Reporting](/artifacts/eu/energy-efficiency-directive/compliance.md): A practical EED compliance playbook: governance, scope control, threshold route decision (85 TJ / 10 TJ), energy audit program (Annex VI quality gates). - [EED Deadlines & Compliance Calendar (Directive (EU) 2023/1791) | Transposition 11 Oct 2025, Data Centres 15 May](/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED Energy Audits (Directive (EU) 2023/1791 Article 11) | Annex VI Minimum Criteria + Action Plan + Reporting](/artifacts/eu/energy-efficiency-directive/energy-audits.md): A deep-dive on EED energy audits: who must do them (>10 TJ 3-year average if no EMS), deadlines (first audit by 11 Oct 2026. - [EED Energy Management System (EMS) (Directive (EU) 2023/1791 Article 11) | 85 TJ Threshold + ISO 50001 Certification](/artifacts/eu/energy-efficiency-directive/energy-management-systems.md): A practical guide to the EED EMS obligation: who must implement a certified energy management system (>85 TJ 3-year average). - [EED Enforcement (Penalties) | Directive (EU) 2023/1791 Article 32 + How to Reduce Risk](/artifacts/eu/energy-efficiency-directive/penalties-and-fines.md): A practical enforcement guide for the Energy Efficiency Directive (EED): what the directive says about penalties (Article 32). - [EED FAQ (Directive (EU) 2023/1791) | Thresholds, Audits, ISO 50001, Action Plans, Data Centres](/artifacts/eu/energy-efficiency-directive/faq.md): High-signal answers to common EED questions: how to compute the 3-year average TJ. - [EED Reporting & Metrics (Directive (EU) 2023/1791) | Action Plans, Implementation Rate, Data Centres, Public Bodies](/artifacts/eu/energy-efficiency-directive/reporting-and-metrics.md): A practical reporting and metrics guide for EED compliance: what to track to support Article 11 thresholds and route decisions. - [EED Requirements (Directive (EU) 2023/1791) | Article 11 Thresholds, Annex VI Audit Criteria, Data Centres](/artifacts/eu/energy-efficiency-directive/requirements.md): A practical requirements breakdown of the EU Energy Efficiency Directive (EED. - [EED Scope: Who Must Comply (Directive (EU) 2023/1791) | Enterprises, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply.md): A grounded scope guide for the Energy Efficiency Directive (EED. - [EED Timeline | Key Dates for Directive (EU) 2023/1791 (Transposition, Audits, EMS, Data Centres)](/artifacts/eu/energy-efficiency-directive/timeline.md): A high-signal timeline guide for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED vs CSRD | How Energy Efficiency Compliance Feeds Sustainability Reporting (and What It Doesn't Replace)](/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd.md): A practical comparison of the Energy Efficiency Directive (EED, Directive (EU) 2023/1791) vs the Corporate Sustainability Reporting Directive (CSRD. - [Energy Audit Report Template (EED / EN 16247) | Annex VI-Aligned Structure + Acceptance Criteria](/artifacts/eu/energy-efficiency-directive/energy-audit-report-template.md): A practical energy audit report template aligned to the EED (Directive (EU) 2023/1791) and its Annex VI minimum criteria. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive --- --- title: "EED Enforcement (Penalties)" canonical_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/penalties-and-fines" author: "Sorena AI" description: "A practical enforcement guide for the Energy Efficiency Directive (EED): what the directive says about penalties (Article 32)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EED penalties" - "Energy Efficiency Directive fines" - "Directive (EU) 2023/1791 Article 32 penalties" - "EED enforcement" - "EED compliance evidence pack" - "EED audit enforcement" - "data centre reporting enforcement 500 kW" - "enforcement" - "Article 32" - "evidence pack" - "market scrutiny" - "reporting" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EED Enforcement (Penalties) A practical enforcement guide for the Energy Efficiency Directive (EED): what the directive says about penalties (Article 32). *Enforcement Guide* *EU* ## EU Energy Efficiency Directive (EED) Enforcement Enforcement risk is evidence risk. Reduce it by making your EED outputs exportable and current. Focus: national penalties + practical controls that prevent findings. Directive (EU) 2023/1791 requires Member States to lay down penalties for infringements of national provisions adopted under the directive. That means enforcement is primarily national, but your risk reduction strategy is universal: keep your route decision, audits/EMS evidence, Action Plans, and reporting outputs coherent and easy to produce on demand. ## What the directive says about penalties (and what it doesn't) The directive doesn't set a single EU-wide fine schedule. Instead, it requires Member States to define penalties in national law and ensure they are effective, proportionate, and dissuasive. In practice, this means your enforcement exposure depends on the Member State rules and the maturity of your evidence pack. - Penalties are set nationally (Member State rules). - Penalties must be effective, proportionate and dissuasive. - Member States must notify the Commission of penalty rules and measures by 11 October 2025. *Recommended next step* *Placement: after the enforcement section* ## Use EU Energy Efficiency Directive (EED) Enforcement as a cited research workflow Research Copilot can take EU Energy Efficiency Directive (EED) Enforcement from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Energy Efficiency Directive (EED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Energy Efficiency Directive (EED) Enforcement](/solutions/research-copilot.md): Start from EU Energy Efficiency Directive (EED) Enforcement and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Energy Efficiency Directive (EED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Energy Efficiency Directive (EED) Enforcement. ## High-risk failure modes (why organizations get findings) Most enforcement problems are operational: the organization can't prove what route applies, audits aren't defensible, or reporting/publication is inconsistent. Avoid these by treating EED obligations as controlled deliverables with QA and versioning. - Threshold decision not reproducible, missing inputs, changing boundaries, or unclear conversion factors. - Audit quality failures, Annex VI criteria not met, no measured data, missing load profiles, weak coverage, or no management submission record for the Action Plan. - Action Plans not feasible, no owners, budgets, measurement method, or management sign off. - Implementation-rate reporting inconsistent or unsupported by action tracking evidence. - Failure to make threshold information available to national authorities when required, or missed data centre publication or database submission deadlines. ## Risk reduction controls (do these before you scale audits/certifications) You can prevent most findings with a small set of controls that make evidence exportable and current. These controls also improve internal decision-making and ROI from efficiency measures. - One scope memo + one evidence index (single source of truth). - Annual boundary review and route decision refresh (with change triggers). - Annex VI QA checklist embedded in audit procurement and report acceptance. - Action Plan tracker with owners, due dates, and savings verification method. - Publication workflow for annual report disclosures and data centre outputs (with confidentiality review). ## If you get questioned: how to respond fast (without panic) Treat enforcement inquiries like an incident: triage scope, gather evidence, and respond with coherent documentation. Speed comes from having an evidence index and versioned outputs. - Triage: which obligations apply (route decision memo) and which sites/entities are affected. - Export: audit reports/EMS certificates/Action Plans + the evidence index showing where each artifact lives. - Explain: boundary and method decisions (why your numbers are comparable year-to-year). - Remediate: close gaps with targeted audits, updated Action Plans, and controlled reporting updates. ## Primary sources - [Directive (EU) 2023/1791: Energy Efficiency Directive (official text)](https://eur-lex.europa.eu/eli/dir/2023/1791/oj?ref=sorena.io) - Article 32 penalties framework and related compliance obligations that drive evidence expectations. - [European Commission: Energy Efficiency Directive overview](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive_en?ref=sorena.io) - Official overview and links to guidance and resources. ## Related Topic Guides - [EED Applicability Test (Directive (EU) 2023/1791) | 85 TJ vs 10 TJ, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/applicability-test.md): A practical applicability test for the EU Energy Efficiency Directive (EED. - [EED Checklist (Directive (EU) 2023/1791) | Audit-Ready Steps for Article 11, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/checklist.md): An audit-ready checklist for the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): scope and boundary memo, 85 TJ vs 10 TJ route decision. - [EED Compliance Program (Directive (EU) 2023/1791) | How to Operationalize Article 11, Audits, ISO 50001, Reporting](/artifacts/eu/energy-efficiency-directive/compliance.md): A practical EED compliance playbook: governance, scope control, threshold route decision (85 TJ / 10 TJ), energy audit program (Annex VI quality gates). - [EED Deadlines & Compliance Calendar (Directive (EU) 2023/1791) | Transposition 11 Oct 2025, Data Centres 15 May](/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED Energy Audits (Directive (EU) 2023/1791 Article 11) | Annex VI Minimum Criteria + Action Plan + Reporting](/artifacts/eu/energy-efficiency-directive/energy-audits.md): A deep-dive on EED energy audits: who must do them (>10 TJ 3-year average if no EMS), deadlines (first audit by 11 Oct 2026. - [EED Energy Management System (EMS) (Directive (EU) 2023/1791 Article 11) | 85 TJ Threshold + ISO 50001 Certification](/artifacts/eu/energy-efficiency-directive/energy-management-systems.md): A practical guide to the EED EMS obligation: who must implement a certified energy management system (>85 TJ 3-year average). - [EED FAQ (Directive (EU) 2023/1791) | Thresholds, Audits, ISO 50001, Action Plans, Data Centres](/artifacts/eu/energy-efficiency-directive/faq.md): High-signal answers to common EED questions: how to compute the 3-year average TJ. - [EED Reporting & Metrics (Directive (EU) 2023/1791) | Action Plans, Implementation Rate, Data Centres, Public Bodies](/artifacts/eu/energy-efficiency-directive/reporting-and-metrics.md): A practical reporting and metrics guide for EED compliance: what to track to support Article 11 thresholds and route decisions. - [EED Requirements (Directive (EU) 2023/1791) | Article 11 Thresholds, Annex VI Audit Criteria, Data Centres](/artifacts/eu/energy-efficiency-directive/requirements.md): A practical requirements breakdown of the EU Energy Efficiency Directive (EED. - [EED Scope: Who Must Comply (Directive (EU) 2023/1791) | Enterprises, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply.md): A grounded scope guide for the Energy Efficiency Directive (EED. - [EED Timeline | Key Dates for Directive (EU) 2023/1791 (Transposition, Audits, EMS, Data Centres)](/artifacts/eu/energy-efficiency-directive/timeline.md): A high-signal timeline guide for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED vs CSRD | How Energy Efficiency Compliance Feeds Sustainability Reporting (and What It Doesn't Replace)](/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd.md): A practical comparison of the Energy Efficiency Directive (EED, Directive (EU) 2023/1791) vs the Corporate Sustainability Reporting Directive (CSRD. - [Energy Audit Report Template (EED / EN 16247) | Annex VI-Aligned Structure + Acceptance Criteria](/artifacts/eu/energy-efficiency-directive/energy-audit-report-template.md): A practical energy audit report template aligned to the EED (Directive (EU) 2023/1791) and its Annex VI minimum criteria. - [ISO 50001 vs EED | How a Certified Energy Management System Satisfies EED Article 11 (and What EED Adds)](/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive.md): A practical comparison of ISO 50001 vs the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): ISO 50001 is the EMS standard. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/energy-efficiency-directive/penalties-and-fines --- --- title: "EED Reporting & Metrics (Directive (EU) 2023/1791)" canonical_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/reporting-and-metrics" source_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/reporting-and-metrics" author: "Sorena AI" description: "A practical reporting and metrics guide for EED compliance: what to track to support Article 11 thresholds and route decisions." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EED reporting" - "Energy Efficiency Directive reporting" - "Directive (EU) 2023/1791 reporting" - "EED action plan reporting" - "EED implementation rate annual report" - "data centre reporting 500 kW" - "EED metrics and KPIs" - "ISO 50001 reporting" - "EED public bodies reporting" - "implementation rate" - "action plan" - "data centres" - "public bodies" - "KPIs" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EED Reporting & Metrics (Directive (EU) 2023/1791) A practical reporting and metrics guide for EED compliance: what to track to support Article 11 thresholds and route decisions. *Ops Guide* *EU* ## EU Energy Efficiency Directive (EED) Reporting and Metrics What to track, what to publish, and how to keep it defensible. Focus: Article 11 Action Plans + implementation rate, plus data centre annual publication. EED reporting gets hard when teams mix internal evidence with external publication. The directive expects concrete outputs, Action Plans, annual report publication of the recommendation implementation rate for enterprises on the audit route, annual data centre publication, and in some cases authority-facing data submissions, while also protecting trade and business secrets. This page shows how to design reporting that is publishable, traceable, and repeatable across years. ## Reporting model: separate internal evidence from publishable outputs Build two layers: a full internal evidence pack (traceable inputs, calculations, site details) and an external disclosure layer (publishable summaries). This prevents the most common failure modes: (1) leaking sensitive data, or (2) publishing untraceable numbers. - Internal layer: threshold calculation sheet, audit reports, EMS evidence, action tracking, savings verification, approvals. - External layer: annual report disclosure fields and summaries; data centre publication outputs; public-body reports (as implemented nationally). - Link both layers through an evidence index and a versioning scheme. ## Article 11 outputs: Action Plans + implementation rate disclosures The directive expects enterprises on the audit route to produce a concrete and feasible Action Plan based on audit recommendations. It also requires the Action Plans and the recommendation implementation rate to be published in the enterprise annual report and made publicly available, subject to confidentiality protections. - Action Plan fields, recommendation, decision, rationale, owner, due date, budget, expected savings, and measurement method. - Implementation rate, define what counts as implemented and keep the definition stable from year to year. - Management submission, keep the record of when the Action Plan was submitted to management and which resources were approved. - Confidentiality handling, publish aggregated rates and themes, and keep site-level sensitive details internal. ## Data centres: annual publication outputs (>=500 kW installed IT demand) Treat data centre publication as a recurring compliance output with stable definitions, QA, versioning, and database submission controls. If you change boundaries or measurement methods, document why and how comparability is maintained. - Publication package, required Annex VII information, calculation notes, and the confidentiality review record. - Database submission, report the KPIs to the European database under Delegated Regulation (EU) 2024/1364, first by 15 September 2024 and then by 15 May each year from 2025. - Versioning, year, perimeter, definitions, publication URL, database confirmation, and internal raw dataset. - Quality gates, validation checks, anomaly handling, sign off workflow, and comparability notes. ## Suggested KPI set (make it comparable year-over-year) Choose KPIs you can sustain. If the KPI set changes every year, you lose comparability and trust. Use a small core set plus optional site-level deep dives. - Energy consumption, total by carrier and any normalized intensity metric that is meaningful for the operation. - Route decision, 3 year average TJ with data sources, conversion factors, and annual refresh date. - Measures, count of measures identified, accepted, implemented, estimated savings, verified savings, and lifecycle cost distribution. - Action Plan execution, on-time completion rate, budget variance, management approval date, and recurring benefits sustained. - Data centres, installed IT power demand band, publication completeness, database submission status, and year-over-year change explanations. ## Operating cadence (who runs what, when) Reporting works when it is a calendar process with clear owners and approvals. Assign one person accountable for the evidence index and publication schedule. - Q1, refresh the threshold calculation and boundary memo, and confirm the route and coverage. - Q2 to Q3, update audits and Action Plans, verify savings, and prepare EMS internal audits and management review. - Q4, prepare the annual report disclosure layer, aggregate the implementation rate, and finalize the data centre publication and database package if applicable. - One accountable owner, keep one person responsible for the evidence index, publication schedule, and version history. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU Energy Efficiency Directive (EED) Reporting and Metrics across ESG workflows ESG Compliance can take EU Energy Efficiency Directive (EED) Reporting and Metrics from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU Energy Efficiency Directive (EED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Energy Efficiency Directive (EED) Reporting and Metrics](/solutions/esg-compliance.md): Start from EU Energy Efficiency Directive (EED) Reporting and Metrics and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Energy Efficiency Directive (EED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Energy Efficiency Directive (EED) Reporting and Metrics. ## Primary sources - [Directive (EU) 2023/1791: Energy Efficiency Directive (official text)](https://eur-lex.europa.eu/eli/dir/2023/1791/oj?ref=sorena.io) - Article 11 Action Plan and annual report publication requirements; data centre annual publication obligation. - [European Commission: Energy performance of data centres](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive/energy-performance-data-centres_en?ref=sorena.io) - Commission context and resources for data centre reporting. - [European Commission: Energy Efficiency Directive overview](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive_en?ref=sorena.io) - Official overview and links to guidance documents. - [Commission Delegated Regulation (EU) 2024/1364: data centre reporting scheme](https://eur-lex.europa.eu/eli/reg_del/2024/1364/oj/eng?ref=sorena.io) - Source for the European database reporting layer and KPI methodology. - [Commission Recommendation (EU) 2024/2002: Article 11 guidance](https://eur-lex.europa.eu/eli/reco/2024/2002/oj/eng?ref=sorena.io) - Commission guidance on Action Plans, annual report publication, and Article 11 evidence expectations. ## Related Topic Guides - [EED Applicability Test (Directive (EU) 2023/1791) | 85 TJ vs 10 TJ, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/applicability-test.md): A practical applicability test for the EU Energy Efficiency Directive (EED. - [EED Checklist (Directive (EU) 2023/1791) | Audit-Ready Steps for Article 11, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/checklist.md): An audit-ready checklist for the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): scope and boundary memo, 85 TJ vs 10 TJ route decision. - [EED Compliance Program (Directive (EU) 2023/1791) | How to Operationalize Article 11, Audits, ISO 50001, Reporting](/artifacts/eu/energy-efficiency-directive/compliance.md): A practical EED compliance playbook: governance, scope control, threshold route decision (85 TJ / 10 TJ), energy audit program (Annex VI quality gates). - [EED Deadlines & Compliance Calendar (Directive (EU) 2023/1791) | Transposition 11 Oct 2025, Data Centres 15 May](/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED Energy Audits (Directive (EU) 2023/1791 Article 11) | Annex VI Minimum Criteria + Action Plan + Reporting](/artifacts/eu/energy-efficiency-directive/energy-audits.md): A deep-dive on EED energy audits: who must do them (>10 TJ 3-year average if no EMS), deadlines (first audit by 11 Oct 2026. - [EED Energy Management System (EMS) (Directive (EU) 2023/1791 Article 11) | 85 TJ Threshold + ISO 50001 Certification](/artifacts/eu/energy-efficiency-directive/energy-management-systems.md): A practical guide to the EED EMS obligation: who must implement a certified energy management system (>85 TJ 3-year average). - [EED Enforcement (Penalties) | Directive (EU) 2023/1791 Article 32 + How to Reduce Risk](/artifacts/eu/energy-efficiency-directive/penalties-and-fines.md): A practical enforcement guide for the Energy Efficiency Directive (EED): what the directive says about penalties (Article 32). - [EED FAQ (Directive (EU) 2023/1791) | Thresholds, Audits, ISO 50001, Action Plans, Data Centres](/artifacts/eu/energy-efficiency-directive/faq.md): High-signal answers to common EED questions: how to compute the 3-year average TJ. - [EED Requirements (Directive (EU) 2023/1791) | Article 11 Thresholds, Annex VI Audit Criteria, Data Centres](/artifacts/eu/energy-efficiency-directive/requirements.md): A practical requirements breakdown of the EU Energy Efficiency Directive (EED. - [EED Scope: Who Must Comply (Directive (EU) 2023/1791) | Enterprises, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply.md): A grounded scope guide for the Energy Efficiency Directive (EED. - [EED Timeline | Key Dates for Directive (EU) 2023/1791 (Transposition, Audits, EMS, Data Centres)](/artifacts/eu/energy-efficiency-directive/timeline.md): A high-signal timeline guide for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED vs CSRD | How Energy Efficiency Compliance Feeds Sustainability Reporting (and What It Doesn't Replace)](/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd.md): A practical comparison of the Energy Efficiency Directive (EED, Directive (EU) 2023/1791) vs the Corporate Sustainability Reporting Directive (CSRD. - [Energy Audit Report Template (EED / EN 16247) | Annex VI-Aligned Structure + Acceptance Criteria](/artifacts/eu/energy-efficiency-directive/energy-audit-report-template.md): A practical energy audit report template aligned to the EED (Directive (EU) 2023/1791) and its Annex VI minimum criteria. - [ISO 50001 vs EED | How a Certified Energy Management System Satisfies EED Article 11 (and What EED Adds)](/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive.md): A practical comparison of ISO 50001 vs the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): ISO 50001 is the EMS standard. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/energy-efficiency-directive/reporting-and-metrics --- --- title: "EED Requirements (Directive (EU) 2023/1791)" canonical_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/requirements" source_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/requirements" author: "Sorena AI" description: "A practical requirements breakdown of the EU Energy Efficiency Directive (EED." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Energy Efficiency Directive requirements" - "EED requirements" - "Directive (EU) 2023/1791 requirements" - "EED Article 11 energy audits" - "85 TJ energy management system" - "10 TJ energy audit" - "Annex VI minimum criteria energy audits" - "EN 16247 audit requirements" - "ISO 50001 certified energy management system" - "data centre reporting 500 kW" - "Directive (EU) 2023/1791" - "energy audits" - "EN 16247" - "ISO 50001" - "data centres" - "public bodies" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EED Requirements (Directive (EU) 2023/1791) A practical requirements breakdown of the EU Energy Efficiency Directive (EED. *Requirements Guide* *EU* ## EU Energy Efficiency Directive (EED) Requirements A requirements breakdown you can implement: thresholds, cadence, and evidence. Built from Directive (EU) 2023/1791, focusing on enterprise obligations, audit quality, and data centre reporting. EED compliance is easiest when you treat it like an operating system: define boundaries, determine which Article 11 route applies, run audits or EMS controls on a cadence, track actions and savings, and publish or report what the directive and national law require. This page translates the directive, the 2024 Commission guidance, and the data centre reporting layer into practical workstreams and an evidence map you can reuse across sites. ## Enterprise obligations (Article 11): 85 TJ vs 10 TJ thresholds The EED sets two energy-consumption thresholds based on your average annual energy consumption over the previous three years (all energy carriers together). They determine your required route. Treat the threshold calculation and route decision as controlled artifacts: reproducible inputs, documented conversions, and defined review triggers. - If the 3 year average is > 85 TJ, implement an energy management system and have it certified by an independent body, commonly aligned to EN ISO 50001, with the system in place by 11 October 2027. - If the 3 year average is > 10 TJ and you do not implement an EMS, carry out a first energy audit by 11 October 2026 and repeat at least every four years. - Keep boundary decisions explicit, including sites, entities, carriers, acquisitions, divestitures, and annual refresh triggers. - Where annual consumption is above the relevant threshold in a given year, be ready to make that information available to the national authority responsible for Article 11. ## Energy audit quality (Annex VI): minimum criteria Annex VI defines minimum criteria for energy audits (including those performed as part of an energy management system). Use these criteria as acceptance criteria for audit providers and as a QA checklist before you file and rely on the report. - Use up-to-date, measured, traceable operational data (including electricity load profiles). - Include a detailed review of the energy consumption profile across relevant assets (buildings, industrial operations/installations, and transport). - Identify energy efficiency measures and the potential for cost-effective renewable energy use/production. - Use life-cycle cost analysis where possible; keep data storable for historical analysis and tracking. ## Data centres: monitoring, publication, and annual cadence Separate from enterprise thresholds, the EED introduces data centre monitoring, database reporting, and public availability rules based on installed IT power demand. If triggered, treat this as a recurring reporting process with one stable perimeter, one measurement method, and versioned outputs. - Installed IT power demand >= 500 kW, publish Annex VII information annually, subject to confidentiality protections. - Under the delegated regulation, data centre operators report the required indicators to the European database, first by 15 September 2024 and then by 15 May 2025 and each year after that. - Installed IT power demand >= 1 MW, expect best-practice expectations linked to the European Code of Conduct and higher scrutiny around waste heat and sustainability performance. - Store the publication link, internal dataset, calculations, approvals, and any comparability notes when boundaries or methods change. ## Public bodies: exemplary role workstreams Many public-sector provisions are implemented by Member States, but public bodies still need operational workflows for measurement, planning, renovation and procurement actions, and reporting. Use the national implementation as your control source, while keeping the directive milestones and the 2024 public-sector recommendation in view. - Annual reduction planning and reporting for public sector final energy consumption, noting that the Article 5 target remains indicative through 11 October 2027. - Public buildings inventory and renovation planning, including the by 11 October 2025 inventory milestone and at least biennial updates. - Procurement, incorporate energy-efficiency criteria and evidence into purchasing and contracting where national implementation requires it. ## Evidence map (requirement to owner to artifact) Build an evidence index so each requirement is owned and has an exportable artifact. The goal is not volume, it is coherence. A good evidence pack answers what route applies, what was done, what the findings were, what actions were taken, what was published, and how results are tracked year over year. - Threshold route decision memo with inputs, conversions, 3 year average TJ, annual refresh date, and route outcome. - Audit or EMS coverage plan with sites, carriers, boundaries, schedule, provider or certifier, and QA gates. - Audit reports meeting Annex VI criteria, plus the recommendations register, concrete and feasible Action Plan, and implementation tracking. - EMS certification evidence, including certificate, scope statement, audit dates, corrective actions, and surveillance schedule. - Data centre publication and database package, including the dataset, calculations, publication URL, database submission, and approvals. *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU Energy Efficiency Directive (EED) Requirements across ESG workflows ESG Compliance can take EU Energy Efficiency Directive (EED) Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Energy Efficiency Directive (EED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Energy Efficiency Directive (EED) Requirements](/solutions/esg-compliance.md): Start from EU Energy Efficiency Directive (EED) Requirements and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Energy Efficiency Directive (EED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Energy Efficiency Directive (EED) Requirements. ## Primary sources - [Directive (EU) 2023/1791: Energy Efficiency Directive (official text)](https://eur-lex.europa.eu/eli/dir/2023/1791/oj?ref=sorena.io) - Enterprise thresholds (Article 11), audit criteria (Annex VI), data centre reporting, and penalties framework. - [European Commission: Energy Efficiency Directive overview](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive_en?ref=sorena.io) - Official overview and links to EED guidance notes and sector obligations. - [EN 16247-1:2022: Energy audits (catalog summary)](https://standards.iteh.ai/catalog/standards/cen/3fbb3fd5-0106-42d0-8b9f-cb546db8465a/en-16247-1-2022?ref=sorena.io) - Practical framing of energy audit methodology and expected deliverables referenced by the directive. - [European Commission: Energy performance of data centres](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive/energy-performance-data-centres_en?ref=sorena.io) - Commission overview of the monitoring and reporting framework for data centres. - [Commission Recommendation (EU) 2024/2002: Article 11 guidance](https://eur-lex.europa.eu/eli/reco/2024/2002/oj/eng?ref=sorena.io) - Commission guidance on interpreting Article 11, including threshold calculation, EMS certification, audits, and Action Plan expectations. - [Commission Delegated Regulation (EU) 2024/1364: data centre reporting scheme](https://eur-lex.europa.eu/eli/reg_del/2024/1364/oj/eng?ref=sorena.io) - Common Union reporting methodology and European database reporting details for data centres. ## Related Topic Guides - [EED Applicability Test (Directive (EU) 2023/1791) | 85 TJ vs 10 TJ, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/applicability-test.md): A practical applicability test for the EU Energy Efficiency Directive (EED. - [EED Checklist (Directive (EU) 2023/1791) | Audit-Ready Steps for Article 11, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/checklist.md): An audit-ready checklist for the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): scope and boundary memo, 85 TJ vs 10 TJ route decision. - [EED Compliance Program (Directive (EU) 2023/1791) | How to Operationalize Article 11, Audits, ISO 50001, Reporting](/artifacts/eu/energy-efficiency-directive/compliance.md): A practical EED compliance playbook: governance, scope control, threshold route decision (85 TJ / 10 TJ), energy audit program (Annex VI quality gates). - [EED Deadlines & Compliance Calendar (Directive (EU) 2023/1791) | Transposition 11 Oct 2025, Data Centres 15 May](/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED Energy Audits (Directive (EU) 2023/1791 Article 11) | Annex VI Minimum Criteria + Action Plan + Reporting](/artifacts/eu/energy-efficiency-directive/energy-audits.md): A deep-dive on EED energy audits: who must do them (>10 TJ 3-year average if no EMS), deadlines (first audit by 11 Oct 2026. - [EED Energy Management System (EMS) (Directive (EU) 2023/1791 Article 11) | 85 TJ Threshold + ISO 50001 Certification](/artifacts/eu/energy-efficiency-directive/energy-management-systems.md): A practical guide to the EED EMS obligation: who must implement a certified energy management system (>85 TJ 3-year average). - [EED Enforcement (Penalties) | Directive (EU) 2023/1791 Article 32 + How to Reduce Risk](/artifacts/eu/energy-efficiency-directive/penalties-and-fines.md): A practical enforcement guide for the Energy Efficiency Directive (EED): what the directive says about penalties (Article 32). - [EED FAQ (Directive (EU) 2023/1791) | Thresholds, Audits, ISO 50001, Action Plans, Data Centres](/artifacts/eu/energy-efficiency-directive/faq.md): High-signal answers to common EED questions: how to compute the 3-year average TJ. - [EED Reporting & Metrics (Directive (EU) 2023/1791) | Action Plans, Implementation Rate, Data Centres, Public Bodies](/artifacts/eu/energy-efficiency-directive/reporting-and-metrics.md): A practical reporting and metrics guide for EED compliance: what to track to support Article 11 thresholds and route decisions. - [EED Scope: Who Must Comply (Directive (EU) 2023/1791) | Enterprises, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply.md): A grounded scope guide for the Energy Efficiency Directive (EED. - [EED Timeline | Key Dates for Directive (EU) 2023/1791 (Transposition, Audits, EMS, Data Centres)](/artifacts/eu/energy-efficiency-directive/timeline.md): A high-signal timeline guide for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED vs CSRD | How Energy Efficiency Compliance Feeds Sustainability Reporting (and What It Doesn't Replace)](/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd.md): A practical comparison of the Energy Efficiency Directive (EED, Directive (EU) 2023/1791) vs the Corporate Sustainability Reporting Directive (CSRD. - [Energy Audit Report Template (EED / EN 16247) | Annex VI-Aligned Structure + Acceptance Criteria](/artifacts/eu/energy-efficiency-directive/energy-audit-report-template.md): A practical energy audit report template aligned to the EED (Directive (EU) 2023/1791) and its Annex VI minimum criteria. - [ISO 50001 vs EED | How a Certified Energy Management System Satisfies EED Article 11 (and What EED Adds)](/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive.md): A practical comparison of ISO 50001 vs the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): ISO 50001 is the EMS standard. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/energy-efficiency-directive/requirements --- --- title: "EED Scope: Who Must Comply (Directive (EU) 2023/1791)" canonical_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply" source_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply" author: "Sorena AI" description: "A grounded scope guide for the Energy Efficiency Directive (EED." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Energy Efficiency Directive scope" - "who must comply EED" - "Directive (EU) 2023/1791 Article 11 thresholds" - "85 TJ energy management system" - "10 TJ energy audit" - "public bodies energy efficiency obligation" - "data centre reporting 500 kW" - "EED compliance scope" - "Directive (EU) 2023/1791" - "energy audits" - "ISO 50001" - "public bodies" - "data centres" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EED Scope: Who Must Comply (Directive (EU) 2023/1791) A grounded scope guide for the Energy Efficiency Directive (EED. *Scope Guide* *EU* ## EU Energy Efficiency Directive (EED) Scope and Who Must Comply Identify which obligations apply to your organization and why. Focus: enterprise thresholds (85 TJ / 10 TJ), public bodies scope, and data centre reporting triggers. The EED is a package of obligations that apply to different actors. The most common scoping mistakes are mixing up Article 11 thresholds with older large-enterprise concepts, using inconsistent organizational boundaries for energy consumption, and ignoring the separate data centre reporting trigger. This page gives you a defensible scoping approach, grounded in Directive (EU) 2023/1791 and the 2024 Commission guidance, plus a checklist of evidence to retain. ## Directly obligated parties (the usual "must comply" buckets) Some EED obligations are placed on Member States, who then implement measures nationally. Others directly drive enterprise duties or sector reporting triggers. Start by classifying where you fit, then map the obligations to owners and evidence. - Enterprises above thresholds, if your 3 year average annual energy consumption across all carriers exceeds the Article 11 thresholds, you must implement a certified EMS above 85 TJ or carry out energy audits above 10 TJ if no EMS is in place. - Public bodies, via Member State implementation, obligations include the Article 5 final energy consumption reduction track, public building duties, and public procurement requirements. - Data centre operators, if installed IT power demand is >= 500 kW, the operator must publish or report the required Annex VII information each year, subject to confidentiality rules. ## Enterprise threshold scoping (how to avoid the common boundary trap) The thresholds are based on energy consumption, not headcount or turnover. That makes boundary definition the key control. Your scoping should withstand scrutiny: auditors should be able to reproduce your result from stored inputs. - Define the organizational boundary, which legal entities, sites, and operations are included, and keep the rationale in writing. - Define the energy boundary, which carriers and uses are included, and treat purchased electricity, fuels, purchased heat or cooling, and fleet fuels consistently. - Compute the 3 year average annual consumption in TJ and store the calculation inputs, conversion factors, and review sign off. - Set retest triggers, acquisition, divestiture, new site, and major load change, and review the route at least annually. - If annual consumption crosses the relevant threshold in a given year, be ready to make that information available to the competent national authority. *Recommended next step* *Placement: after the scope or definition section* ## Use EU Energy Efficiency Directive (EED) Scope and Who Must Comply as a cited research workflow Research Copilot can take EU Energy Efficiency Directive (EED) Scope and Who Must Comply from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Energy Efficiency Directive (EED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Energy Efficiency Directive (EED) Scope and Who Must Comply](/solutions/research-copilot.md): Start from EU Energy Efficiency Directive (EED) Scope and Who Must Comply and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Energy Efficiency Directive (EED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Energy Efficiency Directive (EED) Scope and Who Must Comply. ## Data centres: don't confuse installed IT demand with facility power The data centre trigger is tied to installed information technology (IT) power demand, not the broader facility power envelope. Treat measurement method and boundary as part of your compliance evidence, so year-over-year reporting stays consistent. - Confirm whether installed IT power demand is >= 500 kW, the reporting trigger, and whether you reach the >= 1 MW band where best-practice expectations intensify. - Define the reporting perimeter, data centre sites, colocation boundaries, and tenant responsibilities, and document who publishes and who submits to the European database. - Keep publication history, database submissions, and supporting calculation sheets under version control. ## Public bodies: treat national implementation as the control source Public-sector obligations are implemented through Member State measures and may have scope nuances (which entities count as public bodies, what consumption is included, and what exclusions apply). Your compliance workflow should explicitly link to the Member State implementation and assign owners for reporting and building inventory duties. - Determine whether your organization qualifies as a public body under the applicable national definition and how consumption is aggregated. - Identify the relevant obligations, reduction planning and reporting, public building inventories, renovation planning, and procurement energy-efficiency requirements. - Store the scope memo, baseline definition, reporting method, governance approvals, and links to the national implementation text and guidance. ## Primary sources - [Directive (EU) 2023/1791: Energy Efficiency Directive (official text)](https://eur-lex.europa.eu/eli/dir/2023/1791/oj?ref=sorena.io) - Primary scope, thresholds, enterprise duties, public-sector provisions, data centre reporting, and penalties framework. - [European Commission: Energy Efficiency Directive overview](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive_en?ref=sorena.io) - Official overview and links to EED guidance and sector pages. - [European Commission: Energy performance of data centres (EED sector page)](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive/energy-performance-data-centres_en?ref=sorena.io) - Commission overview of the monitoring and reporting framework for data centres. - [Commission Recommendation (EU) 2024/1716: public sector guidance](https://eur-lex.europa.eu/eli/reco/2024/1716/oj/eng?ref=sorena.io) - Commission guidance on Articles 5, 6, and 7 for public bodies, public buildings, and procurement. - [Commission Recommendation (EU) 2024/2002: Article 11 guidance](https://eur-lex.europa.eu/eli/reco/2024/2002/oj/eng?ref=sorena.io) - Commission guidance on threshold calculation, scope, and Article 11 implementation. ## Related Topic Guides - [EED Applicability Test (Directive (EU) 2023/1791) | 85 TJ vs 10 TJ, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/applicability-test.md): A practical applicability test for the EU Energy Efficiency Directive (EED. - [EED Checklist (Directive (EU) 2023/1791) | Audit-Ready Steps for Article 11, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/checklist.md): An audit-ready checklist for the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): scope and boundary memo, 85 TJ vs 10 TJ route decision. - [EED Compliance Program (Directive (EU) 2023/1791) | How to Operationalize Article 11, Audits, ISO 50001, Reporting](/artifacts/eu/energy-efficiency-directive/compliance.md): A practical EED compliance playbook: governance, scope control, threshold route decision (85 TJ / 10 TJ), energy audit program (Annex VI quality gates). - [EED Deadlines & Compliance Calendar (Directive (EU) 2023/1791) | Transposition 11 Oct 2025, Data Centres 15 May](/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED Energy Audits (Directive (EU) 2023/1791 Article 11) | Annex VI Minimum Criteria + Action Plan + Reporting](/artifacts/eu/energy-efficiency-directive/energy-audits.md): A deep-dive on EED energy audits: who must do them (>10 TJ 3-year average if no EMS), deadlines (first audit by 11 Oct 2026. - [EED Energy Management System (EMS) (Directive (EU) 2023/1791 Article 11) | 85 TJ Threshold + ISO 50001 Certification](/artifacts/eu/energy-efficiency-directive/energy-management-systems.md): A practical guide to the EED EMS obligation: who must implement a certified energy management system (>85 TJ 3-year average). - [EED Enforcement (Penalties) | Directive (EU) 2023/1791 Article 32 + How to Reduce Risk](/artifacts/eu/energy-efficiency-directive/penalties-and-fines.md): A practical enforcement guide for the Energy Efficiency Directive (EED): what the directive says about penalties (Article 32). - [EED FAQ (Directive (EU) 2023/1791) | Thresholds, Audits, ISO 50001, Action Plans, Data Centres](/artifacts/eu/energy-efficiency-directive/faq.md): High-signal answers to common EED questions: how to compute the 3-year average TJ. - [EED Reporting & Metrics (Directive (EU) 2023/1791) | Action Plans, Implementation Rate, Data Centres, Public Bodies](/artifacts/eu/energy-efficiency-directive/reporting-and-metrics.md): A practical reporting and metrics guide for EED compliance: what to track to support Article 11 thresholds and route decisions. - [EED Requirements (Directive (EU) 2023/1791) | Article 11 Thresholds, Annex VI Audit Criteria, Data Centres](/artifacts/eu/energy-efficiency-directive/requirements.md): A practical requirements breakdown of the EU Energy Efficiency Directive (EED. - [EED Timeline | Key Dates for Directive (EU) 2023/1791 (Transposition, Audits, EMS, Data Centres)](/artifacts/eu/energy-efficiency-directive/timeline.md): A high-signal timeline guide for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED vs CSRD | How Energy Efficiency Compliance Feeds Sustainability Reporting (and What It Doesn't Replace)](/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd.md): A practical comparison of the Energy Efficiency Directive (EED, Directive (EU) 2023/1791) vs the Corporate Sustainability Reporting Directive (CSRD. - [Energy Audit Report Template (EED / EN 16247) | Annex VI-Aligned Structure + Acceptance Criteria](/artifacts/eu/energy-efficiency-directive/energy-audit-report-template.md): A practical energy audit report template aligned to the EED (Directive (EU) 2023/1791) and its Annex VI minimum criteria. - [ISO 50001 vs EED | How a Certified Energy Management System Satisfies EED Article 11 (and What EED Adds)](/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive.md): A practical comparison of ISO 50001 vs the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): ISO 50001 is the EMS standard. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply --- --- title: "EED Timeline" canonical_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/timeline" source_url: "https://www.sorena.io/artifacts/eu/energy-efficiency-directive/timeline" author: "Sorena AI" description: "A high-signal timeline guide for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EED timeline" - "Energy Efficiency Directive timeline" - "Directive (EU) 2023/1791 key dates" - "EED transposition 11 October 2025" - "EED first energy audit 11 October 2026" - "EED EMS deadline 11 October 2027" - "EED data centre reporting 15 May 2024" - "transposition" - "energy audits" - "energy management system" - "data centres" - "public bodies" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EED Timeline A high-signal timeline guide for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. *Timeline* *EU* ## EU Energy Efficiency Directive (EED) Timeline Key dates and planning milestones for audits, EMS, reporting, and publication. Built from Directive (EU) 2023/1791 dates and cadence obligations. EED work is easiest when it is calendarized. Use this page to anchor planning around the directive's key milestones, then use the checklist and calendar subpages to turn dates into owners, deliverables, and evidence folders. This page does not modify the underlying timeline or dataflow artifacts, it explains how to use them. ## Milestone anchors (the dates most programs should plan around) The EED has a few EU-level milestones that affect how you plan enterprise compliance and reporting programs. National implementation details matter, but these anchors are still useful for planning. - 20 September 2023, Directive (EU) 2023/1791 was published in the Official Journal. - 10 October 2023, the directive entered into force. - 15 May 2024, annual public availability started for in-scope data centres at >= 500 kW installed IT power demand. - 15 September 2024, first database submission under Delegated Regulation (EU) 2024/1364. - 11 October 2025, Member States had to transpose the main recast provisions and establish the public buildings inventory. - 15 May 2025, Commission assessment deadline for the available data on data centre energy efficiency. - 11 October 2026, first energy audit deadline for enterprises on the audit route. - 11 October 2027, EMS in place deadline for enterprises above 85 TJ and Commission assessment deadline for possible Article 11 threshold revision. - 11 October 2028, Commission report to Parliament and Council on that threshold assessment. *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU Energy Efficiency Directive (EED) Timeline across ESG workflows ESG Compliance can take EU Energy Efficiency Directive (EED) Timeline from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Energy Efficiency Directive (EED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Energy Efficiency Directive (EED) Timeline](/solutions/esg-compliance.md): Start from EU Energy Efficiency Directive (EED) Timeline and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Energy Efficiency Directive (EED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Energy Efficiency Directive (EED) Timeline. ## How to use this timeline in practice A timeline does not create compliance. A cadence does. Convert milestones into internal checkpoints and QA gates. Make the route decision memo and evidence index the two artifacts that persist across years. - Q1 each year, refresh boundaries and the 3 year average TJ calculation, then confirm the route and coverage. - Before audits or surveillance visits, run Annex VI and data-readiness checks so the evidence pack is complete. - After audits, update the concrete and feasible Action Plan, management submission record, and implementation tracking. - For data centres, run one annual reporting calendar that covers validation, confidentiality review, publication, and database submission. - For public bodies, keep the buildings inventory and reduction-planning workflow on the same master calendar. ## Primary sources - [Directive (EU) 2023/1791: Energy Efficiency Directive (official text)](https://eur-lex.europa.eu/eli/dir/2023/1791/oj?ref=sorena.io) - Source for transposition, audit/EMS deadlines, and data centre annual publication cadence. - [European Commission: Energy performance of data centres](https://energy.ec.europa.eu/topics/energy-efficiency/energy-efficiency-targets-directive-and-rules/energy-efficiency-directive/energy-performance-data-centres_en?ref=sorena.io) - Commission context for the data centre monitoring/reporting framework. - [Commission Delegated Regulation (EU) 2024/1364: data centre reporting scheme](https://eur-lex.europa.eu/eli/reg_del/2024/1364/oj/eng?ref=sorena.io) - European database reporting deadlines and KPI methodology for the data centre layer. ## Related Topic Guides - [EED Applicability Test (Directive (EU) 2023/1791) | 85 TJ vs 10 TJ, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/applicability-test.md): A practical applicability test for the EU Energy Efficiency Directive (EED. - [EED Checklist (Directive (EU) 2023/1791) | Audit-Ready Steps for Article 11, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/checklist.md): An audit-ready checklist for the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): scope and boundary memo, 85 TJ vs 10 TJ route decision. - [EED Compliance Program (Directive (EU) 2023/1791) | How to Operationalize Article 11, Audits, ISO 50001, Reporting](/artifacts/eu/energy-efficiency-directive/compliance.md): A practical EED compliance playbook: governance, scope control, threshold route decision (85 TJ / 10 TJ), energy audit program (Annex VI quality gates). - [EED Deadlines & Compliance Calendar (Directive (EU) 2023/1791) | Transposition 11 Oct 2025, Data Centres 15 May](/artifacts/eu/energy-efficiency-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for the Energy Efficiency Directive, Directive (EU) 2023/1791: entry into force on 10 October 2023. - [EED Energy Audits (Directive (EU) 2023/1791 Article 11) | Annex VI Minimum Criteria + Action Plan + Reporting](/artifacts/eu/energy-efficiency-directive/energy-audits.md): A deep-dive on EED energy audits: who must do them (>10 TJ 3-year average if no EMS), deadlines (first audit by 11 Oct 2026. - [EED Energy Management System (EMS) (Directive (EU) 2023/1791 Article 11) | 85 TJ Threshold + ISO 50001 Certification](/artifacts/eu/energy-efficiency-directive/energy-management-systems.md): A practical guide to the EED EMS obligation: who must implement a certified energy management system (>85 TJ 3-year average). - [EED Enforcement (Penalties) | Directive (EU) 2023/1791 Article 32 + How to Reduce Risk](/artifacts/eu/energy-efficiency-directive/penalties-and-fines.md): A practical enforcement guide for the Energy Efficiency Directive (EED): what the directive says about penalties (Article 32). - [EED FAQ (Directive (EU) 2023/1791) | Thresholds, Audits, ISO 50001, Action Plans, Data Centres](/artifacts/eu/energy-efficiency-directive/faq.md): High-signal answers to common EED questions: how to compute the 3-year average TJ. - [EED Reporting & Metrics (Directive (EU) 2023/1791) | Action Plans, Implementation Rate, Data Centres, Public Bodies](/artifacts/eu/energy-efficiency-directive/reporting-and-metrics.md): A practical reporting and metrics guide for EED compliance: what to track to support Article 11 thresholds and route decisions. - [EED Requirements (Directive (EU) 2023/1791) | Article 11 Thresholds, Annex VI Audit Criteria, Data Centres](/artifacts/eu/energy-efficiency-directive/requirements.md): A practical requirements breakdown of the EU Energy Efficiency Directive (EED. - [EED Scope: Who Must Comply (Directive (EU) 2023/1791) | Enterprises, Public Bodies, Data Centres](/artifacts/eu/energy-efficiency-directive/scope-and-who-must-comply.md): A grounded scope guide for the Energy Efficiency Directive (EED. - [EED vs CSRD | How Energy Efficiency Compliance Feeds Sustainability Reporting (and What It Doesn't Replace)](/artifacts/eu/energy-efficiency-directive/energy-efficiency-directive-vs-csrd.md): A practical comparison of the Energy Efficiency Directive (EED, Directive (EU) 2023/1791) vs the Corporate Sustainability Reporting Directive (CSRD. - [Energy Audit Report Template (EED / EN 16247) | Annex VI-Aligned Structure + Acceptance Criteria](/artifacts/eu/energy-efficiency-directive/energy-audit-report-template.md): A practical energy audit report template aligned to the EED (Directive (EU) 2023/1791) and its Annex VI minimum criteria. - [ISO 50001 vs EED | How a Certified Energy Management System Satisfies EED Article 11 (and What EED Adds)](/artifacts/eu/energy-efficiency-directive/iso-50001-vs-energy-efficiency-directive.md): A practical comparison of ISO 50001 vs the EU Energy Efficiency Directive (EED, Directive (EU) 2023/1791): ISO 50001 is the EMS standard. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/energy-efficiency-directive/timeline --- --- title: "ePrivacy Applicability Test (Directive 2002/58/EC)" canonical_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/applicability-test" author: "Sorena AI" description: "A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "ePrivacy applicability test" - "ePrivacy Directive applicability" - "Directive 2002/58/EC scope" - "Article 5(3) cookie consent" - "terminal equipment access EU" - "cookie consent exemptions strictly necessary" - "ePrivacy direct marketing Article 13" - "ePrivacy metadata rules" - "Directive 2002/58/EC" - "Article 5(3)" - "cookies" - "consent" - "direct marketing" - "metadata" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ePrivacy Applicability Test (Directive 2002/58/EC) A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting. *Applicability Test* *EU* ## EU ePrivacy Directive Applicability Test Decide which ePrivacy obligations apply to your product, tracking stack, and marketing. Scope cookies/SDKs (Article 5(3)), communications confidentiality, and direct marketing (Article 13). ePrivacy isn't one yes/no question. Different obligations apply based on what you do: (1) storing/accessing information on user devices (cookies/SDKs/fingerprinting), (2) handling electronic communications content/metadata, and (3) sending direct marketing. Use this page to reach a defensible outcome and store an evidence-backed decision memo. ## Step 1 - Do you store/access information on "terminal equipment" (Article 5(3))? If your product stores or accesses information on a user's device, ePrivacy Article 5(3) logic is usually your first gate. This includes cookies, local storage, mobile SDK identifiers, and similar tracking techniques. The hard part is mapping each item to consent vs an exemption. - Inventory: cookies, pixels, SDKs, local storage, device identifiers, and fingerprinting-like techniques. - For each item: purpose, data collected, lifespan, who sets it, who receives data, and where it runs (web/app). - Decision: consent required vs exemption ("strictly necessary" / transmission) with documented reasoning. ## Step 2 - Are you an electronic communications service/provider (content + metadata)? If you provide communications functionality (including modern OTT messaging/voice), you also need to treat communications confidentiality and metadata as a distinct compliance track. Even when the GDPR applies, ePrivacy can particularize and complement privacy requirements for communications data. - Classify data: communications content vs communications metadata (time, recipients, location, routing, etc.). - List use cases: delivery, spam/security, analytics, product improvement, advertising, and lawful access requests. - Define retention and access controls per use case; keep an evidence trail for why each use is allowed. ## Step 3 - Do you send direct marketing by email/SMS/IM (Article 13)? If you send direct marketing via electronic communications, ePrivacy's unsolicited communications rules are a dedicated workstream. Treat this like an operational system: consent capture, proof, opt-out, and suppression lists. - Identify channels: email, SMS, push/IM, automated calling, and similar. - Define legal model: consent vs soft opt-in (where applicable) + opt-out mechanics per message. - Evidence: consent logs, timestamp, source, wording/version, withdrawal logs, and suppression list controls. ## Step 4 - Where does GDPR fit (the "after the cookie" layer)? A common compliance failure is mixing ePrivacy and GDPR layers. As a simplified model: ePrivacy often governs the device access/reading layer; GDPR often governs subsequent processing of personal data. Your documentation should explicitly separate these layers and show how you ensure consent validity and information duties. - Document the split: (A) placement/reading (ePrivacy national law) vs (B) subsequent processing (GDPR). - Map which authority/enforcement model applies and whether one-stop-shop mechanisms apply (often not for ePrivacy). - Align consent UX with GDPR consent conditions and information requirements where GDPR is the legal basis. ## Output: an exportable ePrivacy decision memo Make your outcome auditable: a 1 - 2 page memo that explains what applies, why, and what you did about it. Keep it updated as your tracking stack and marketing workflows change. - Scope: products, domains/apps, audiences, markets, vendors, and tracking technologies. - Article 5(3) mapping: tracker-by-tracker consent vs exemption decisions with reasoning. - Banner/CMP design choices and evidence strategy (logs, versions, tests). - Direct marketing model and evidence pack (consent, opt-out, suppression). - Links to deeper subpages for implementation and enforcement readiness. *Recommended next step* *Placement: after the applicability result* ## Turn EU ePrivacy Directive Applicability Test into an operational assessment Assessment Autopilot can take EU ePrivacy Directive Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU ePrivacy Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU ePrivacy Directive Applicability Test](/solutions/assessment.md): Start from EU ePrivacy Directive Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU ePrivacy Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU ePrivacy Directive Applicability Test. ## Primary sources - [Directive 2002/58/EC (ePrivacy Directive) - consolidated text (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02002L0058-20091219&ref=sorena.io) - Core ePrivacy Directive framework (including Article 5(3) terminal equipment access and Article 13 direct marketing rules). - [WP29 Opinion 04/2012 on Cookie Consent Exemption (WP194)](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf?ref=sorena.io) - Practical test for consent exemptions: transmission and strictly necessary cookies. - [EDPB Report - Cookie Banner Taskforce (Jan 2023)](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Enforcement learnings and common denominator positions for cookie banner complaints. - [EDPB Guidelines 05/2020 on consent under GDPR](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_202005_consent_en.pdf?ref=sorena.io) - Consent conditions relevant when GDPR consent is used for subsequent processing (including cookie-wall discussion). - [EDPB Opinion 5/2019 on ePrivacy Directive and GDPR interplay](https://edpb.europa.eu/sites/edpb/files/files/file1/201905_edpb_opinion_eprivacydir_gdpr_interplay_en.pdf?ref=sorena.io) - Interplay model: ePrivacy particularizes/complements GDPR and affects enforcement/competence. ## Related Topic Guides - [Confidentiality of Communications (ePrivacy Directive) | Traffic Data, Location Data, Content, and the OTT Gap](/artifacts/eu/eprivacy-directive/confidentiality-of-communications.md): A practical guide to communications confidentiality under the current ePrivacy Directive, Directive 2002/58/EC: how to classify content, traffic data. - [Cookies & Consent (ePrivacy Directive Article 5(3)) | Exemptions Test, Analytics, CMP Implementation](/artifacts/eu/eprivacy-directive/cookies-and-consent.md): An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage. - [Direct Marketing Consent Checklist (ePrivacy Article 13) | Proof, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist.md): A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control. - [Direct Marketing Rules (ePrivacy Directive Article 13) | Consent, Soft Opt-In, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-rules.md): A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed. - [ePrivacy Checklist (Directive 2002/58/EC) | Cookie Banner, Consent Logs, Exemptions, Marketing Evidence](/artifacts/eu/eprivacy-directive/checklist.md): An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions). - [ePrivacy Compliance Program | Cookies, Consent UX, Evidence, Marketing Controls (Directive 2002/58/EC)](/artifacts/eu/eprivacy-directive/compliance.md): A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design. - [ePrivacy Deadlines and Compliance Calendar | Directive Baseline, Banner Audits, Marketing Audits](/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar.md): A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment. - [ePrivacy Directive Enforcement (Cookies + Marketing) | How Regulators Assess Cookie Banners, Consent, and Evidence](/artifacts/eu/eprivacy-directive/enforcement-and-fines.md): An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX. - [ePrivacy Directive Penalties and Fines | What "Effective, Proportionate, Dissuassive" Means + Risk Reduction Controls](/artifacts/eu/eprivacy-directive/penalties-and-fines.md): Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC). - [ePrivacy Directive Requirements (2002/58/EC) | Article 5(3) Cookies, Article 13 Marketing, Metadata + Evidence Map](/artifacts/eu/eprivacy-directive/requirements.md): A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3)). - [ePrivacy Directive vs GDPR | Which Law Applies to Cookies, Tracking, Communications Metadata, and Marketing?](/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr.md): A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality. - [ePrivacy FAQ (Directive 2002/58/EC) | Cookies, Consent Exemptions, Cookie Walls, Marketing, Enforcement](/artifacts/eu/eprivacy-directive/faq.md): High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194). - [ePrivacy vs GDPR (Cookie Stack Blueprint) | Align Consent UX, Tag Firing, Processing Purposes, and Evidence](/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr.md): A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing. - [EU Cookie Banner Requirements | ePrivacy Directive + GDPR Consent (EDPB) | UX Patterns + Test Cases](/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements.md): A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eprivacy-directive/applicability-test --- --- title: "ePrivacy Checklist (Directive 2002/58/EC)" canonical_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/checklist" source_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/checklist" author: "Sorena AI" description: "An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "ePrivacy checklist" - "ePrivacy Directive checklist" - "cookie banner checklist EU" - "cookie consent checklist Article 5(3)" - "strictly necessary cookies checklist" - "consent log schema" - "direct marketing consent checklist Article 13" - "CMP configuration checklist" - "cookie banner" - "consent logs" - "Article 5(3)" - "Article 13" - "enforcement" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ePrivacy Checklist (Directive 2002/58/EC) An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions). *Checklist* *EU* ## EU ePrivacy Directive Checklist A practical checklist for building an audit-ready consent and marketing evidence program. Scope -> decide consent vs exemptions -> implement banner UX -> prove outcomes with logs. Use this checklist as a program template. Your goal is to make ePrivacy compliance reproducible: every tracker has a documented consent/exemption decision, the banner behaves as specified, consent logs are exportable, withdrawals are honored, and direct marketing uses a provable consent/soft opt-in model with suppression lists. ## 1) Build a tracker inventory + decision table (Article 5(3)) If you can't list your trackers, you can't comply. Start with a complete inventory and map each item to consent or an exemption. Treat the decision table as a controlled artifact (approvals + version history). - Inventory: cookies, pixels, local storage, SDKs, device IDs, fingerprinting techniques. - Fields: purpose, category, lifetime, setter, recipients, markets, and where it runs (web/app). - Decision: consent required vs exemption (transmission / strictly necessary) with reasoning. - Change triggers: new vendor, new tag, new purpose, new SDK version -> must update table. ## 2) Cookie banner UX + CMP configuration (design for proof) Your banner isn't just UI. It's a compliance control that must produce auditable outcomes. Make "reject" and "withdraw" easy, and version banner behavior so you can prove what a user saw. - UX spec: accept/reject parity, granularity, clear purposes, no pre-ticked boxes, no hidden vendor lists. - Default state: no non-exempt storage/access before consent outcome is recorded. - CMP export: store configuration snapshots and vendor/purpose mapping per version. - Regression tests: automated tests for critical flows across locales and devices. ## 3) Consent and withdrawal evidence (what you must be able to export) Enforcement is evidence-driven. Logs must be exportable and tie to banner versions and decisions. Build a logging schema that supports investigations and partner due diligence. - Consent event: timestamp, locale, purposes, vendors, banner version, decision (accept/reject/granular). - Withdrawal event: timestamp, what changed, and how propagation was enforced. - Proof: link user-level decisions to tracker firing behavior (tag manager logs and network-level tests). ## 4) Direct marketing controls (Article 13) - consent/soft opt-in + suppression lists Marketing compliance is an operational system. Your most important artifact is a suppression list you never override without evidence. Build "one-click opt-out" per channel and make it measurable. - Define legal model per channel and market (consent vs soft opt-in where applicable). - Store consent wording versions and capture flows; ensure opt-out is present in every message. - Suppression list governance: access controls, audit logs, and vendor enforcement. - Vendor controls: DPAs and contracts for email/SMS providers; ensure suppression propagation. ## 5) Enforcement readiness (your response pack) If you get a complaint or inquiry, speed and coherence matter. Build an export pack and rehearse it. - Export the tracker decision table + CMP config snapshot + consent log schema + sample exports. - Provide banner UX spec and test results for critical flows. - Provide direct marketing evidence (consent model + opt-out + suppression governance). *Recommended next step* *Placement: after the checklist block* ## Turn EU ePrivacy Directive Checklist into an operational assessment Assessment Autopilot can take EU ePrivacy Directive Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU ePrivacy Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU ePrivacy Directive Checklist](/solutions/assessment.md): Start from EU ePrivacy Directive Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU ePrivacy Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU ePrivacy Directive Checklist. ## Primary sources - [Directive 2002/58/EC (ePrivacy Directive) - consolidated text (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02002L0058-20091219&ref=sorena.io) - Directive framework including Article 5(3) and Article 13 obligations. - [WP29 Opinion 04/2012 on Cookie Consent Exemption (WP194)](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf?ref=sorena.io) - Exemptions test for transmission and strictly necessary cookies. - [EDPB Report - Cookie Banner Taskforce (Jan 2023)](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Enforcement patterns and common denominator positions for cookie banner complaints. ## Related Topic Guides - [Confidentiality of Communications (ePrivacy Directive) | Traffic Data, Location Data, Content, and the OTT Gap](/artifacts/eu/eprivacy-directive/confidentiality-of-communications.md): A practical guide to communications confidentiality under the current ePrivacy Directive, Directive 2002/58/EC: how to classify content, traffic data. - [Cookies & Consent (ePrivacy Directive Article 5(3)) | Exemptions Test, Analytics, CMP Implementation](/artifacts/eu/eprivacy-directive/cookies-and-consent.md): An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage. - [Direct Marketing Consent Checklist (ePrivacy Article 13) | Proof, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist.md): A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control. - [Direct Marketing Rules (ePrivacy Directive Article 13) | Consent, Soft Opt-In, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-rules.md): A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed. - [ePrivacy Applicability Test (Directive 2002/58/EC) | Cookies Article 5(3), Marketing Article 13, Metadata](/artifacts/eu/eprivacy-directive/applicability-test.md): A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting. - [ePrivacy Compliance Program | Cookies, Consent UX, Evidence, Marketing Controls (Directive 2002/58/EC)](/artifacts/eu/eprivacy-directive/compliance.md): A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design. - [ePrivacy Deadlines and Compliance Calendar | Directive Baseline, Banner Audits, Marketing Audits](/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar.md): A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment. - [ePrivacy Directive Enforcement (Cookies + Marketing) | How Regulators Assess Cookie Banners, Consent, and Evidence](/artifacts/eu/eprivacy-directive/enforcement-and-fines.md): An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX. - [ePrivacy Directive Penalties and Fines | What "Effective, Proportionate, Dissuassive" Means + Risk Reduction Controls](/artifacts/eu/eprivacy-directive/penalties-and-fines.md): Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC). - [ePrivacy Directive Requirements (2002/58/EC) | Article 5(3) Cookies, Article 13 Marketing, Metadata + Evidence Map](/artifacts/eu/eprivacy-directive/requirements.md): A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3)). - [ePrivacy Directive vs GDPR | Which Law Applies to Cookies, Tracking, Communications Metadata, and Marketing?](/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr.md): A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality. - [ePrivacy FAQ (Directive 2002/58/EC) | Cookies, Consent Exemptions, Cookie Walls, Marketing, Enforcement](/artifacts/eu/eprivacy-directive/faq.md): High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194). - [ePrivacy vs GDPR (Cookie Stack Blueprint) | Align Consent UX, Tag Firing, Processing Purposes, and Evidence](/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr.md): A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing. - [EU Cookie Banner Requirements | ePrivacy Directive + GDPR Consent (EDPB) | UX Patterns + Test Cases](/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements.md): A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eprivacy-directive/checklist --- --- title: "ePrivacy Compliance Program" canonical_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/compliance" source_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/compliance" author: "Sorena AI" description: "A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "ePrivacy compliance program" - "cookie consent governance" - "CMP configuration governance" - "tracker inventory program" - "Article 5(3) compliance" - "cookie banner audit evidence" - "direct marketing compliance Article 13" - "consent log evidence pack" - "ePrivacy compliance" - "cookie banner" - "CMP" - "consent logs" - "change management" - "direct marketing" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ePrivacy Compliance Program A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design. *Compliance Playbook* *EU* ## EU ePrivacy Directive Compliance Program A repeatable operating cadence for cookies, consent UX, and direct marketing evidence. Focus: evidence-first governance and change control for your tracking stack. ePrivacy compliance breaks when trackers change faster than governance. The best programs treat the banner/CMP and tracker inventory as controlled systems with QA gates, automated tests, and exportable evidence. This playbook shows how to operationalize Article 5(3) and Article 13 controls across product teams, marketing, and vendors. ## Program setup: define scope, owners, and the system of record Start with clear owners and a single system-of-record for tracker decisions, CMP config, and evidence exports. Most "non-compliance" starts as an ownership problem. - Assign owners: privacy lead, web/app engineering lead, marketing ops, tag manager owner, vendor manager. - Create a single evidence index: decision table, CMP config snapshots, consent logs, test results. - Set change triggers: new vendor/tag/SDK, new purpose, new market -> requires review and release gate. ## Article 5(3) system: tracker inventory -> decision table -> release gate Treat the tracker decision table as a release gate that blocks production changes until mapped to consent/exemption. Version it like code. - Inventory continuously: tag manager exports + mobile SDK registry + network scan evidence. - Decision table: consent required vs exemption with documented reasoning and approvals. - Release gate: prevent non-exempt trackers from firing before consent; prove with tests. ## Banner/CMP implementation: design for proof (not just UX) Banner UX must produce a clear, logged outcome and enforce it across all trackers. Build both UI-level tests and network-level tests. - UX: accept/reject parity, granularity, clear purposes, easy withdrawal, no dark patterns. - CMP config management: snapshot exports; vendor lists and purposes versioned per release. - Testing: automated regression tests across locales and devices; canary checks after deploy. ## Marketing controls (Article 13): consent model + suppression governance Direct marketing controls should be measurable: opt-out performance, suppression integrity, and vendor propagation. Treat suppression lists as safety-critical data. - Define consent vs soft opt-in approach per channel/market and document it. - Proof: consent wording versions, capture events, withdrawals, and suppression list audit logs. - Vendor enforcement: contracts + audits; ensure suppression is honored across tools. ## Enforcement readiness: build an export pack and rehearse it The fastest way to reduce enforcement risk is to be able to export coherent evidence quickly. Treat this like incident readiness. - Export pack: tracker decision table + CMP snapshot + consent log schema + sample exports + test results. - Complaint workflow: triage -> reproduce user experience -> extract evidence -> remediate and re-test. - Continuous improvement: quarterly review of exemptions, banner UX, and vendor ecosystem. *Recommended next step* *Placement: after the compliance steps* ## Turn EU ePrivacy Directive Compliance Program into an operational assessment Assessment Autopilot can take EU ePrivacy Directive Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU ePrivacy Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU ePrivacy Directive Compliance Program](/solutions/assessment.md): Start from EU ePrivacy Directive Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU ePrivacy Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU ePrivacy Directive Compliance Program. ## Primary sources - [Directive 2002/58/EC (ePrivacy Directive) - consolidated text (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02002L0058-20091219&ref=sorena.io) - Directive framework for terminal equipment access and direct marketing rules. - [EDPB Report - Cookie Banner Taskforce (Jan 2023)](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Enforcement learnings and common denominator positions for cookie banner complaints. - [EDPB Opinion 5/2019 on ePrivacy Directive and GDPR interplay](https://edpb.europa.eu/sites/edpb/files/files/file1/201905_edpb_opinion_eprivacydir_gdpr_interplay_en.pdf?ref=sorena.io) - Interplay model used in many practical cookie-stack compliance approaches. ## Related Topic Guides - [Confidentiality of Communications (ePrivacy Directive) | Traffic Data, Location Data, Content, and the OTT Gap](/artifacts/eu/eprivacy-directive/confidentiality-of-communications.md): A practical guide to communications confidentiality under the current ePrivacy Directive, Directive 2002/58/EC: how to classify content, traffic data. - [Cookies & Consent (ePrivacy Directive Article 5(3)) | Exemptions Test, Analytics, CMP Implementation](/artifacts/eu/eprivacy-directive/cookies-and-consent.md): An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage. - [Direct Marketing Consent Checklist (ePrivacy Article 13) | Proof, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist.md): A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control. - [Direct Marketing Rules (ePrivacy Directive Article 13) | Consent, Soft Opt-In, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-rules.md): A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed. - [ePrivacy Applicability Test (Directive 2002/58/EC) | Cookies Article 5(3), Marketing Article 13, Metadata](/artifacts/eu/eprivacy-directive/applicability-test.md): A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting. - [ePrivacy Checklist (Directive 2002/58/EC) | Cookie Banner, Consent Logs, Exemptions, Marketing Evidence](/artifacts/eu/eprivacy-directive/checklist.md): An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions). - [ePrivacy Deadlines and Compliance Calendar | Directive Baseline, Banner Audits, Marketing Audits](/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar.md): A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment. - [ePrivacy Directive Enforcement (Cookies + Marketing) | How Regulators Assess Cookie Banners, Consent, and Evidence](/artifacts/eu/eprivacy-directive/enforcement-and-fines.md): An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX. - [ePrivacy Directive Penalties and Fines | What "Effective, Proportionate, Dissuassive" Means + Risk Reduction Controls](/artifacts/eu/eprivacy-directive/penalties-and-fines.md): Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC). - [ePrivacy Directive Requirements (2002/58/EC) | Article 5(3) Cookies, Article 13 Marketing, Metadata + Evidence Map](/artifacts/eu/eprivacy-directive/requirements.md): A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3)). - [ePrivacy Directive vs GDPR | Which Law Applies to Cookies, Tracking, Communications Metadata, and Marketing?](/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr.md): A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality. - [ePrivacy FAQ (Directive 2002/58/EC) | Cookies, Consent Exemptions, Cookie Walls, Marketing, Enforcement](/artifacts/eu/eprivacy-directive/faq.md): High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194). - [ePrivacy vs GDPR (Cookie Stack Blueprint) | Align Consent UX, Tag Firing, Processing Purposes, and Evidence](/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr.md): A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing. - [EU Cookie Banner Requirements | ePrivacy Directive + GDPR Consent (EDPB) | UX Patterns + Test Cases](/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements.md): A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eprivacy-directive/compliance --- --- title: "Confidentiality of Communications (ePrivacy Directive)" canonical_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/confidentiality-of-communications" source_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/confidentiality-of-communications" author: "Sorena AI" description: "A practical guide to communications confidentiality under the current ePrivacy Directive, Directive 2002/58/EC: how to classify content, traffic data." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "confidentiality of communications EU" - "Directive 2002/58/EC confidentiality" - "traffic data ePrivacy" - "location data ePrivacy" - "communications metadata retention EU" - "Article 6 traffic data" - "Article 9 location data" - "ePrivacy OTT gap" - "communications confidentiality" - "metadata" - "OTT messaging" - "ePrivacy Regulation proposal" - "use cases" - "retention" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Confidentiality of Communications (ePrivacy Directive) A practical guide to communications confidentiality under the current ePrivacy Directive, Directive 2002/58/EC: how to classify content, traffic data. *Deep Dive* *EU* ## EU ePrivacy Directive Confidentiality of Communications How to treat communications content, traffic data, and location data as privacy-critical product surfaces. Focus: Articles 5, 6, and 9, retention and access controls, GDPR interplay, and the current OTT coverage gap. For communications products, confidentiality is a product-architecture constraint, not a checkbox. Under the current directive, the baseline rules sit in Article 5 for confidentiality, Article 6 for traffic data, and Article 9 for location data other than traffic data, all as implemented in national law. The safest operational approach is a strict use-case register: what you do with content, traffic data, or location data, why, who can access it, for how long, and how users are informed. ## Start with the current directive baseline, content, traffic data, and location data The current legal baseline is still Directive 2002/58/EC, not the proposed regulation. That means you should classify your communications data against the current directive text and national implementation first. The most useful split in practice is content, traffic data, and location data other than traffic data, because the directive treats them differently. - Content, message bodies, call content, attachments, and payloads. Treat this as the most sensitive layer. - Traffic data, routing, time, duration, recipients, network identifiers, and related service-delivery metadata. - Location data other than traffic data, process only where national law and the directive conditions permit, and keep anonymization or consent logic explicit. ## Build a communications use-case register around Articles 5, 6, and 9 A use-case register is your core control. It prevents scope creep and forces teams to justify why communications data is being used at all. Make it audit-ready with owners, approval dates, retention windows, and testable access controls. - For each use case, data type, purpose, necessity, alternatives considered, national-law constraint, and legal-review outcome. - Controls, access roles, logging, retention window, deletion trigger, and user-transparency reference. - Review triggers, new feature, new analytics purpose, new vendor, or longer retention period requires fresh review. ## Common product patterns that need tight controls Most communications products hit the same pressure points. Treat these as risk hotspots and keep the controls product-specific. The operational question is not only whether a use case is useful. It is whether the use case is permitted, necessary, minimized, and explainable. - Service delivery and billing, keep traffic-data use limited to what is needed for transmission, billing, interconnection, fraud handling, and closely related operational needs allowed by law. - Spam, security, and abuse prevention, define the signal set narrowly, retain only what is needed, and keep access controls strict. - Product analytics or personalization, treat any reuse of communications-related data as a specific use case that needs documented legal review and minimization. ## The GDPR layer and the remaining OTT gap The GDPR still matters because many communications datasets include personal data and because the ePrivacy Directive is implemented alongside GDPR-era consent and transparency standards. The proposed regulation is still useful as reform context, especially because it was designed to address the uneven treatment of OTT services, but you should not present it as current law. - Document the split clearly, ePrivacy or national telecom-privacy rules for communications secrecy and sector-specific limits, GDPR for broader personal-data processing obligations. - If your service is an OTT or adjacent service, record the specific national-law position rather than assuming the proposal text already applies. - Keep proposal-only concepts in a watchlist, not in your current-state control matrix. ## Evidence pack for confidentiality reviews Your evidence should answer what data you use, for what purpose, under which controls, and how you prevent repurposing or excessive retention. Make the pack exportable for internal audits, regulator questions, and product reviews. - Use-case register, approvals, and change history. - Retention schedule per data type and deletion-verification evidence. - Access controls, access logs, and periodic-access-review records. - Transparency mapping showing where each use case is communicated to users and where the GDPR layer is documented. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU ePrivacy Directive Confidentiality of Communications as a cited research workflow Research Copilot can take EU ePrivacy Directive Confidentiality of Communications from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU ePrivacy Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ePrivacy Directive Confidentiality of Communications](/solutions/research-copilot.md): Start from EU ePrivacy Directive Confidentiality of Communications and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ePrivacy Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU ePrivacy Directive Confidentiality of Communications. ## Primary sources - [Directive 2002/58/EC (ePrivacy Directive) - consolidated text (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02002L0058-20091219&ref=sorena.io) - Primary source for communications confidentiality, traffic data, and location data rules. - [EDPB Opinion 5/2019 on ePrivacy Directive and GDPR interplay](https://edpb.europa.eu/sites/edpb/files/files/file1/201905_edpb_opinion_eprivacydir_gdpr_interplay_en.pdf?ref=sorena.io) - Explains the relationship between ePrivacy and GDPR and the competence split for enforcement. - [Commission proposal for an ePrivacy Regulation (COM(2017) 10 final)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52017PC0010&ref=sorena.io) - Reform context only, useful for understanding the unresolved OTT-coverage gap and proposed modernization. ## Related Topic Guides - [Cookies & Consent (ePrivacy Directive Article 5(3)) | Exemptions Test, Analytics, CMP Implementation](/artifacts/eu/eprivacy-directive/cookies-and-consent.md): An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage. - [Direct Marketing Consent Checklist (ePrivacy Article 13) | Proof, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist.md): A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control. - [Direct Marketing Rules (ePrivacy Directive Article 13) | Consent, Soft Opt-In, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-rules.md): A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed. - [ePrivacy Applicability Test (Directive 2002/58/EC) | Cookies Article 5(3), Marketing Article 13, Metadata](/artifacts/eu/eprivacy-directive/applicability-test.md): A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting. - [ePrivacy Checklist (Directive 2002/58/EC) | Cookie Banner, Consent Logs, Exemptions, Marketing Evidence](/artifacts/eu/eprivacy-directive/checklist.md): An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions). - [ePrivacy Compliance Program | Cookies, Consent UX, Evidence, Marketing Controls (Directive 2002/58/EC)](/artifacts/eu/eprivacy-directive/compliance.md): A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design. - [ePrivacy Deadlines and Compliance Calendar | Directive Baseline, Banner Audits, Marketing Audits](/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar.md): A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment. - [ePrivacy Directive Enforcement (Cookies + Marketing) | How Regulators Assess Cookie Banners, Consent, and Evidence](/artifacts/eu/eprivacy-directive/enforcement-and-fines.md): An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX. - [ePrivacy Directive Penalties and Fines | What "Effective, Proportionate, Dissuassive" Means + Risk Reduction Controls](/artifacts/eu/eprivacy-directive/penalties-and-fines.md): Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC). - [ePrivacy Directive Requirements (2002/58/EC) | Article 5(3) Cookies, Article 13 Marketing, Metadata + Evidence Map](/artifacts/eu/eprivacy-directive/requirements.md): A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3)). - [ePrivacy Directive vs GDPR | Which Law Applies to Cookies, Tracking, Communications Metadata, and Marketing?](/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr.md): A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality. - [ePrivacy FAQ (Directive 2002/58/EC) | Cookies, Consent Exemptions, Cookie Walls, Marketing, Enforcement](/artifacts/eu/eprivacy-directive/faq.md): High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194). - [ePrivacy vs GDPR (Cookie Stack Blueprint) | Align Consent UX, Tag Firing, Processing Purposes, and Evidence](/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr.md): A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing. - [EU Cookie Banner Requirements | ePrivacy Directive + GDPR Consent (EDPB) | UX Patterns + Test Cases](/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements.md): A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eprivacy-directive/confidentiality-of-communications --- --- title: "Cookies & Consent (ePrivacy Directive Article 5(3))" canonical_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/cookies-and-consent" source_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/cookies-and-consent" author: "Sorena AI" description: "An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "cookie consent EU" - "ePrivacy Directive cookies" - "Article 5(3) cookie consent" - "strictly necessary cookies exemption" - "cookie consent exemption WP29 WP194" - "analytics cookies consent" - "CMP implementation EU" - "cookie banner compliance" - "Article 5(3)" - "cookie consent" - "strictly necessary cookies" - "analytics cookies" - "CMP" - "cookie banner enforcement" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Cookies & Consent (ePrivacy Directive Article 5(3)) An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage. *Deep Dive* *EU* ## EU ePrivacy Directive Cookies and Consent How to implement Article 5(3) as an engineering and evidence system. Focus: exemptions test, analytics/ads trackers, CMP configuration, and proof. Cookie compliance fails when teams treat consent as a UI pop-up instead of a controlled system. Article 5(3) requires a tracker-by-tracker decision: consent or exemption. WP29 guidance gives a practical test for the exemption criteria. This page shows how to operationalize that test, design a CMP that enforces outcomes, and maintain evidence that stands up to enforcement. ## Article 5(3) in practice: treat "terminal equipment access" as a tracker decision table Start with a full inventory across web and apps (cookies, local storage, SDK identifiers, pixels, fingerprinting-like techniques). For each tracker, you need a defensible "consent required vs exemption" decision and proof that implementation matches. - Inventory: every tag, cookie, SDK, and storage/access mechanism. - Fields: purpose, category, lifetime, who sets it, recipients, and markets. - Decision: consent required vs exemption; store reasoning and approvals. ## Consent exemptions test (WP29): transmission vs strictly necessary WP29 Opinion 04/2012 analyzes the two exemption criteria and emphasizes narrow interpretation. Use the test below as an internal acceptance checklist before classifying anything as exempt. - Transmission exemption: the transmission of the communication must not be possible without the cookie/technique ("sole purpose" is restrictive). - Strictly necessary exemption: required to provide a service explicitly requested by the user (not merely useful, not "nice to have"). - Exempt does not mean uncontrolled: document, monitor, and keep it stable across releases. ## Analytics: the most common misclassification Most analytics cookies/SDKs are not "strictly necessary" for providing the service explicitly requested by the user. If you want a low-risk posture, treat analytics as consent-based unless you have a very specific, defensible exemption rationale. - Define analytics scope: first-party vs third-party, identifiers used, sharing, retention, and cross-site behavior. - Design measurement alternatives: server-side aggregated metrics or privacy-preserving analytics where appropriate. - Prove enforcement: analytics trackers must not fire until consent outcome is recorded. *Recommended next step* *Placement: after the scope or definition section* ## Use EU ePrivacy Directive Cookies and Consent as a cited research workflow Research Copilot can take EU ePrivacy Directive Cookies and Consent from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU ePrivacy Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ePrivacy Directive Cookies and Consent](/solutions/research-copilot.md): Start from EU ePrivacy Directive Cookies and Consent and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ePrivacy Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU ePrivacy Directive Cookies and Consent. ## CMP implementation: design for proof Your CMP must (1) collect a clear choice, (2) enforce it across all trackers, and (3) log enough to prove what happened. Make your CMP configuration exportable and versioned so you can answer complaints quickly. - Enforcement: block non-exempt trackers pre-consent (web + app). - Versioning: store banner/CMP version, vendor list, purpose mapping, and locale-specific text per release. - Evidence: consent and withdrawal logs + automated tests of key flows. ## Evidence pack (what to keep so you can respond in days, not weeks) Enforcement is evidence-driven. If you can't export your decisions and logs, you will struggle. Build an evidence index and rehearse exports. - Tracker decision table (consent vs exemption) with reasoning and approvals. - CMP config snapshot exports + banner UX spec. - Consent/withdrawal log schema + sample exports. - Regression test results (UI + network-level) proving pre-consent blocking. ## Primary sources - [Directive 2002/58/EC (ePrivacy Directive) - consolidated text (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02002L0058-20091219&ref=sorena.io) - Article 5(3) terminal equipment access framework. - [WP29 Opinion 04/2012 on Cookie Consent Exemption (WP194)](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf?ref=sorena.io) - Detailed exemptions test and examples for Article 5(3). - [EDPB Report - Cookie Banner Taskforce (Jan 2023)](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Common enforcement pain points for cookie banners and consent implementation. ## Related Topic Guides - [Confidentiality of Communications (ePrivacy Directive) | Traffic Data, Location Data, Content, and the OTT Gap](/artifacts/eu/eprivacy-directive/confidentiality-of-communications.md): A practical guide to communications confidentiality under the current ePrivacy Directive, Directive 2002/58/EC: how to classify content, traffic data. - [Direct Marketing Consent Checklist (ePrivacy Article 13) | Proof, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist.md): A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control. - [Direct Marketing Rules (ePrivacy Directive Article 13) | Consent, Soft Opt-In, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-rules.md): A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed. - [ePrivacy Applicability Test (Directive 2002/58/EC) | Cookies Article 5(3), Marketing Article 13, Metadata](/artifacts/eu/eprivacy-directive/applicability-test.md): A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting. - [ePrivacy Checklist (Directive 2002/58/EC) | Cookie Banner, Consent Logs, Exemptions, Marketing Evidence](/artifacts/eu/eprivacy-directive/checklist.md): An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions). - [ePrivacy Compliance Program | Cookies, Consent UX, Evidence, Marketing Controls (Directive 2002/58/EC)](/artifacts/eu/eprivacy-directive/compliance.md): A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design. - [ePrivacy Deadlines and Compliance Calendar | Directive Baseline, Banner Audits, Marketing Audits](/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar.md): A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment. - [ePrivacy Directive Enforcement (Cookies + Marketing) | How Regulators Assess Cookie Banners, Consent, and Evidence](/artifacts/eu/eprivacy-directive/enforcement-and-fines.md): An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX. - [ePrivacy Directive Penalties and Fines | What "Effective, Proportionate, Dissuassive" Means + Risk Reduction Controls](/artifacts/eu/eprivacy-directive/penalties-and-fines.md): Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC). - [ePrivacy Directive Requirements (2002/58/EC) | Article 5(3) Cookies, Article 13 Marketing, Metadata + Evidence Map](/artifacts/eu/eprivacy-directive/requirements.md): A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3)). - [ePrivacy Directive vs GDPR | Which Law Applies to Cookies, Tracking, Communications Metadata, and Marketing?](/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr.md): A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality. - [ePrivacy FAQ (Directive 2002/58/EC) | Cookies, Consent Exemptions, Cookie Walls, Marketing, Enforcement](/artifacts/eu/eprivacy-directive/faq.md): High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194). - [ePrivacy vs GDPR (Cookie Stack Blueprint) | Align Consent UX, Tag Firing, Processing Purposes, and Evidence](/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr.md): A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing. - [EU Cookie Banner Requirements | ePrivacy Directive + GDPR Consent (EDPB) | UX Patterns + Test Cases](/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements.md): A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eprivacy-directive/cookies-and-consent --- --- title: "ePrivacy Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "ePrivacy compliance calendar" - "Directive 2002/58/EC timeline" - "Directive 2009/136/EC cookie amendment" - "EDPB cookie banner taskforce 2023" - "EDPB consent guidelines 2020" - "cookie banner audit cadence" - "suppression list audit cadence" - "ePrivacy timeline" - "COM(2017)10" - "ST 6087/21" - "cookie banner" - "CMP governance" - "direct marketing" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ePrivacy Deadlines and Compliance Calendar A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment. *Calendar* *EU* ## EU ePrivacy Directive Deadlines and Compliance Calendar Current-state milestones plus a recurring cadence for cookies and marketing compliance. Focus: directive baseline, guidance milestones, and evidence freshness. ePrivacy compliance does not end after a banner redesign. It breaks when trackers change, consent logging drifts, or suppression lists stop propagating. Use this page to anchor on the current directive baseline and major guidance milestones, then run a repeatable cadence for tracker audits, CMP QA, consent-log verification, and direct-marketing suppression audits. This page does not modify the underlying timeline or dataflow artifacts - it gives you an operational calendar. ## Current baseline and guidance milestones Your day-to-day obligations still come from the directive as implemented in national law, not from the proposed regulation. The most useful timeline points are therefore the current directive baseline and the major GDPR-era guidance documents. Use these milestones to frame your documentation, training, and annual legal review checkpoints. - 12 July 2002, Directive 2002/58/EC entered into force as the sector-specific privacy framework for electronic communications. - 25 November 2009, Directive 2009/136/EC updated Article 5(3) and strengthened the consent model for storing or accessing information on terminal equipment. - 25 May 2018, the GDPR started applying, which made the GDPR conditions for valid consent central to many ePrivacy implementations. - 12 March 2019, EDPB Opinion 5/2019 clarified the ePrivacy and GDPR interplay and competence split. - 4 May 2020, EDPB Guidelines 05/2020 on consent reinforced the positions on valid consent and cookie walls. - 18 January 2023, the EDPB Cookie Banner Taskforce report summarized common enforcement positions on reject options, pre-consent firing, and withdrawal. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU ePrivacy Directive Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take EU ePrivacy Directive Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU ePrivacy Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU ePrivacy Directive Deadlines and Compliance Calendar](/solutions/assessment.md): Start from EU ePrivacy Directive Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU ePrivacy Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU ePrivacy Directive Deadlines and Compliance Calendar. ## Quarterly cadence - tracker governance Most compliance failures happen through silent drift: new tags, new SDKs, new vendors, and new purposes that bypass review. Run quarterly tracker audits the way you would run a security or release-control review. - Run a tracker scan, tag-manager export, network scan, and mobile SDK list diff. - Update the Article 5(3) decision table, consent versus exemption, and re-approve any changes. - Verify pre-consent blocking with automated tests and spot checks in production. ## Monthly cadence - CMP configuration and consent-logging QA Consent systems often fail silently through broken logging, vendor-mapping errors, or locale mismatches. Monthly QA is the easiest way to avoid enforcement surprises and evidence gaps. - Export and diff the CMP configuration, then validate vendor and purpose mappings. - Check consent-log completeness, missing events, unexpected spikes, and locale problems. - Test withdrawal propagation so suppression and firing changes take effect across systems. ## Biannual cadence - direct-marketing suppression audit Direct-marketing complaints often come down to suppression failures, not policy wording. Treat suppression integrity as a control that needs recurring testing. - Audit suppression-list governance, access, approvals, and change logs. - Test vendor propagation end to end, unsubscribe to suppression to no further send. - Reconcile CRM and ESP segments against the suppression source of truth. ## Annual cadence - enforcement readiness rehearsal You should be able to answer what trackers you run, why, how consent works, and what logs prove it. Rehearse evidence exports like an incident tabletop exercise. - Export pack, tracker decision table, CMP snapshots, consent-log schema, and test results. - Marketing pack, consent model, capture logs, suppression governance, and vendor list. - Annual legal review, confirm national guidance updates, DPA positions, and any legislative reform movement, then document what changed and who approved it. ## Primary sources - [Directive 2002/58/EC (ePrivacy Directive) - consolidated text (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02002L0058-20091219&ref=sorena.io) - Current directive baseline. - [Directive 2009/136/EC (cookie amendment) - EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32009L0136&ref=sorena.io) - Amendment that strengthened the Article 5(3) consent model. - [EDPB Opinion 5/2019 on ePrivacy Directive and GDPR interplay](https://edpb.europa.eu/sites/edpb/files/files/file1/201905_edpb_opinion_eprivacydir_gdpr_interplay_en.pdf?ref=sorena.io) - Interplay model and enforcement competence. - [EDPB Guidelines 05/2020 on consent under GDPR](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_202005_consent_en.pdf?ref=sorena.io) - Consent validity and cookie-wall guidance used in ePrivacy implementations. - [EDPB Cookie Banner Taskforce report (18 January 2023)](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Current enforcement learnings that should drive operational audit cadence. ## Related Topic Guides - [Confidentiality of Communications (ePrivacy Directive) | Traffic Data, Location Data, Content, and the OTT Gap](/artifacts/eu/eprivacy-directive/confidentiality-of-communications.md): A practical guide to communications confidentiality under the current ePrivacy Directive, Directive 2002/58/EC: how to classify content, traffic data. - [Cookies & Consent (ePrivacy Directive Article 5(3)) | Exemptions Test, Analytics, CMP Implementation](/artifacts/eu/eprivacy-directive/cookies-and-consent.md): An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage. - [Direct Marketing Consent Checklist (ePrivacy Article 13) | Proof, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist.md): A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control. - [Direct Marketing Rules (ePrivacy Directive Article 13) | Consent, Soft Opt-In, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-rules.md): A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed. - [ePrivacy Applicability Test (Directive 2002/58/EC) | Cookies Article 5(3), Marketing Article 13, Metadata](/artifacts/eu/eprivacy-directive/applicability-test.md): A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting. - [ePrivacy Checklist (Directive 2002/58/EC) | Cookie Banner, Consent Logs, Exemptions, Marketing Evidence](/artifacts/eu/eprivacy-directive/checklist.md): An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions). - [ePrivacy Compliance Program | Cookies, Consent UX, Evidence, Marketing Controls (Directive 2002/58/EC)](/artifacts/eu/eprivacy-directive/compliance.md): A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design. - [ePrivacy Directive Enforcement (Cookies + Marketing) | How Regulators Assess Cookie Banners, Consent, and Evidence](/artifacts/eu/eprivacy-directive/enforcement-and-fines.md): An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX. - [ePrivacy Directive Penalties and Fines | What "Effective, Proportionate, Dissuassive" Means + Risk Reduction Controls](/artifacts/eu/eprivacy-directive/penalties-and-fines.md): Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC). - [ePrivacy Directive Requirements (2002/58/EC) | Article 5(3) Cookies, Article 13 Marketing, Metadata + Evidence Map](/artifacts/eu/eprivacy-directive/requirements.md): A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3)). - [ePrivacy Directive vs GDPR | Which Law Applies to Cookies, Tracking, Communications Metadata, and Marketing?](/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr.md): A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality. - [ePrivacy FAQ (Directive 2002/58/EC) | Cookies, Consent Exemptions, Cookie Walls, Marketing, Enforcement](/artifacts/eu/eprivacy-directive/faq.md): High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194). - [ePrivacy vs GDPR (Cookie Stack Blueprint) | Align Consent UX, Tag Firing, Processing Purposes, and Evidence](/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr.md): A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing. - [EU Cookie Banner Requirements | ePrivacy Directive + GDPR Consent (EDPB) | UX Patterns + Test Cases](/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements.md): A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar --- --- title: "Direct Marketing Consent Checklist (ePrivacy Article 13)" canonical_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist" source_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist" author: "Sorena AI" description: "A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "direct marketing consent checklist EU" - "ePrivacy Article 13 checklist" - "email marketing consent evidence" - "SMS marketing consent evidence" - "unsubscribe requirements EU" - "suppression list governance checklist" - "marketing consent log schema" - "Article 13" - "marketing consent" - "unsubscribe" - "suppression list" - "evidence" - "audit" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Direct Marketing Consent Checklist (ePrivacy Article 13) A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control. *Checklist* *EU* ## EU ePrivacy Directive Direct Marketing Consent Checklist A checklist you can hand to marketing ops, product, and legal and actually implement. Focus: proof, opt-out, suppression governance, and vendor enforcement. Marketing compliance is evidence compliance. This checklist is designed to make Article 13 operational: you can prove consent (or a documented soft opt-in model where applicable), you can prove withdrawals, and your suppression list is enforced across all vendors and tools. ## 1) Define your marketing model per channel and market Do not use one global policy statement. Different channels and markets require explicit decisions and controls. Document the model and store it in your evidence index. - Channels: email, SMS, IM/push, automated calling (as applicable). - Model: consent vs soft opt-in (where applicable) + constraints and fallback path. - Owner: marketing ops owner + legal reviewer + system owner (CRM/ESP). ## 2) Consent capture: make it provable and versioned Consent without proof is a liability. Capture enough to reproduce what the user saw and agreed to. Version the wording like code. - Log fields: identifier, timestamp, channel(s), locale, capture source, and wording/version ID. - If using double opt-in: record confirmation timestamp and method. - Store the consent UI/screenshots/spec and link them to the wording version. ## 3) Opt-out: design for speed and propagation Opt-out must work in practice across tools. The failure mode is partial suppression (one tool honors, another doesn't). Build opt-out propagation as a measurable pipeline. - One-click unsubscribe for email; clear STOP flows for SMS where applicable. - Withdrawal event log: timestamp, channel, and tool propagation evidence. - Time-to-suppress KPI: how quickly withdrawal is enforced across vendors. ## 4) Suppression list governance (treat as safety-critical) Suppression lists prevent repeated violations and complaints. They need access controls, audit logs, and vendor propagation guarantees. - Single source of truth suppression list; no ad-hoc overrides. - Access controls + audit logs + approval workflow for exceptional cases. - Vendors: contract clauses + technical enforcement + periodic tests. ## 5) Export pack (what to produce during an inquiry) Build and rehearse an export pack so you can respond coherently within days. Your export pack should be consistent and defensible. - Consent logs (schema + sample exports) tied to wording versions. - Withdrawal logs + suppression list governance evidence. - Campaign approval records and compliance checks. - Vendor list + suppression propagation tests. *Recommended next step* *Placement: after the checklist block* ## Use EU ePrivacy Directive Direct Marketing Consent Checklist as a cited research workflow Research Copilot can take EU ePrivacy Directive Direct Marketing Consent Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU ePrivacy Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ePrivacy Directive Direct Marketing Consent Checklist](/solutions/research-copilot.md): Start from EU ePrivacy Directive Direct Marketing Consent Checklist and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ePrivacy Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU ePrivacy Directive Direct Marketing Consent Checklist. ## Primary sources - [Directive 2002/58/EC (ePrivacy Directive) - consolidated text (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02002L0058-20091219&ref=sorena.io) - Article 13 rules on unsolicited communications for direct marketing. ## Related Topic Guides - [Confidentiality of Communications (ePrivacy Directive) | Traffic Data, Location Data, Content, and the OTT Gap](/artifacts/eu/eprivacy-directive/confidentiality-of-communications.md): A practical guide to communications confidentiality under the current ePrivacy Directive, Directive 2002/58/EC: how to classify content, traffic data. - [Cookies & Consent (ePrivacy Directive Article 5(3)) | Exemptions Test, Analytics, CMP Implementation](/artifacts/eu/eprivacy-directive/cookies-and-consent.md): An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage. - [Direct Marketing Rules (ePrivacy Directive Article 13) | Consent, Soft Opt-In, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-rules.md): A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed. - [ePrivacy Applicability Test (Directive 2002/58/EC) | Cookies Article 5(3), Marketing Article 13, Metadata](/artifacts/eu/eprivacy-directive/applicability-test.md): A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting. - [ePrivacy Checklist (Directive 2002/58/EC) | Cookie Banner, Consent Logs, Exemptions, Marketing Evidence](/artifacts/eu/eprivacy-directive/checklist.md): An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions). - [ePrivacy Compliance Program | Cookies, Consent UX, Evidence, Marketing Controls (Directive 2002/58/EC)](/artifacts/eu/eprivacy-directive/compliance.md): A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design. - [ePrivacy Deadlines and Compliance Calendar | Directive Baseline, Banner Audits, Marketing Audits](/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar.md): A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment. - [ePrivacy Directive Enforcement (Cookies + Marketing) | How Regulators Assess Cookie Banners, Consent, and Evidence](/artifacts/eu/eprivacy-directive/enforcement-and-fines.md): An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX. - [ePrivacy Directive Penalties and Fines | What "Effective, Proportionate, Dissuassive" Means + Risk Reduction Controls](/artifacts/eu/eprivacy-directive/penalties-and-fines.md): Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC). - [ePrivacy Directive Requirements (2002/58/EC) | Article 5(3) Cookies, Article 13 Marketing, Metadata + Evidence Map](/artifacts/eu/eprivacy-directive/requirements.md): A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3)). - [ePrivacy Directive vs GDPR | Which Law Applies to Cookies, Tracking, Communications Metadata, and Marketing?](/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr.md): A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality. - [ePrivacy FAQ (Directive 2002/58/EC) | Cookies, Consent Exemptions, Cookie Walls, Marketing, Enforcement](/artifacts/eu/eprivacy-directive/faq.md): High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194). - [ePrivacy vs GDPR (Cookie Stack Blueprint) | Align Consent UX, Tag Firing, Processing Purposes, and Evidence](/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr.md): A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing. - [EU Cookie Banner Requirements | ePrivacy Directive + GDPR Consent (EDPB) | UX Patterns + Test Cases](/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements.md): A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist --- --- title: "Direct Marketing Rules (ePrivacy Directive Article 13)" canonical_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/direct-marketing-rules" source_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/direct-marketing-rules" author: "Sorena AI" description: "A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "ePrivacy direct marketing" - "Article 13 ePrivacy" - "email marketing consent EU" - "SMS marketing consent EU" - "soft opt-in EU" - "opt-out unsubscribe requirements EU" - "suppression list governance" - "Article 13" - "direct marketing" - "email marketing consent" - "SMS marketing consent" - "soft opt-in" - "suppression list" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Direct Marketing Rules (ePrivacy Directive Article 13) A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed. *Ops Guide* *EU* ## EU ePrivacy Directive Direct Marketing Rules Build a provable marketing consent system: capture, withdrawal, and suppression. Focus: consent vs soft opt-in model, opt-out UX, and evidence exports. Marketing compliance is usually broken by operations, not policy: missing proof, inconsistent wording, and weak suppression-list governance. Article 13 obligations are best implemented as a system: capture model, evidence logs, withdrawal propagation, vendor enforcement, and routine audits. The current baseline is the directive as implemented in national law, so keep the per-channel and per-market model explicit. ## Start with a channel-by-channel model Define the legal model separately for each channel and market because national implementations and expectations can vary. Your evidence must answer: who did you contact, why were you allowed, and how could they stop it? - Channels, email, SMS, instant messaging, push, and automated calls where applicable. - Model, prior consent or soft opt-in where national law allows it, with the specific constraints written down per market. - Always, opt-out must be easy and recorded, and suppression must be honored across every tool and vendor. ## Consent: design for proof and repeatability Consent is not a checkbox - it's a record. Store wording versions and capture context so you can prove what the user agreed to. Align consent UX with GDPR consent conditions when GDPR consent is also the downstream lawful basis, and keep wording versions tied to market and channel. - Log: timestamp, source (form/app flow), locale, consent wording version, and channel scope. - Withdrawal: timestamp, method, and propagation evidence to all marketing systems. - Quality: periodic audits for missing logs and "orphaned" contacts. ## Suppression lists: treat them as safety-critical data Suppression lists are the control that prevents repeated violations. They need access control, audit logs, and vendor propagation guarantees. - One suppression source of truth; no ad-hoc lists per tool. - Access controls + change logs; approvals for overrides (rare). - Vendors: contracts and technical integrations that enforce suppression. ## Evidence pack (what you should be able to export) When questioned, speed matters. Build an export pack so you can respond with coherent evidence quickly. Exportability is a measurable capability. - Consent capture flows + wording versions (screenshots/specs). - Consent and withdrawal logs (schema + sample exports). - Suppression governance SOP + vendor propagation evidence. - Campaign approval workflow and compliance checks. *Recommended next step* *Placement: after the scope or definition section* ## Use EU ePrivacy Directive Direct Marketing Rules as a cited research workflow Research Copilot can take EU ePrivacy Directive Direct Marketing Rules from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU ePrivacy Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ePrivacy Directive Direct Marketing Rules](/solutions/research-copilot.md): Start from EU ePrivacy Directive Direct Marketing Rules and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ePrivacy Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU ePrivacy Directive Direct Marketing Rules. ## Primary sources - [Directive 2002/58/EC (ePrivacy Directive) - consolidated text (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02002L0058-20091219&ref=sorena.io) - Article 13 rules on unsolicited communications for direct marketing. - [EDPB Guidelines 05/2020 on consent under GDPR](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_202005_consent_en.pdf?ref=sorena.io) - Consent validity standards used when ePrivacy direct-marketing programs rely on consent. ## Related Topic Guides - [Confidentiality of Communications (ePrivacy Directive) | Traffic Data, Location Data, Content, and the OTT Gap](/artifacts/eu/eprivacy-directive/confidentiality-of-communications.md): A practical guide to communications confidentiality under the current ePrivacy Directive, Directive 2002/58/EC: how to classify content, traffic data. - [Cookies & Consent (ePrivacy Directive Article 5(3)) | Exemptions Test, Analytics, CMP Implementation](/artifacts/eu/eprivacy-directive/cookies-and-consent.md): An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage. - [Direct Marketing Consent Checklist (ePrivacy Article 13) | Proof, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist.md): A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control. - [ePrivacy Applicability Test (Directive 2002/58/EC) | Cookies Article 5(3), Marketing Article 13, Metadata](/artifacts/eu/eprivacy-directive/applicability-test.md): A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting. - [ePrivacy Checklist (Directive 2002/58/EC) | Cookie Banner, Consent Logs, Exemptions, Marketing Evidence](/artifacts/eu/eprivacy-directive/checklist.md): An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions). - [ePrivacy Compliance Program | Cookies, Consent UX, Evidence, Marketing Controls (Directive 2002/58/EC)](/artifacts/eu/eprivacy-directive/compliance.md): A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design. - [ePrivacy Deadlines and Compliance Calendar | Directive Baseline, Banner Audits, Marketing Audits](/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar.md): A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment. - [ePrivacy Directive Enforcement (Cookies + Marketing) | How Regulators Assess Cookie Banners, Consent, and Evidence](/artifacts/eu/eprivacy-directive/enforcement-and-fines.md): An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX. - [ePrivacy Directive Penalties and Fines | What "Effective, Proportionate, Dissuassive" Means + Risk Reduction Controls](/artifacts/eu/eprivacy-directive/penalties-and-fines.md): Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC). - [ePrivacy Directive Requirements (2002/58/EC) | Article 5(3) Cookies, Article 13 Marketing, Metadata + Evidence Map](/artifacts/eu/eprivacy-directive/requirements.md): A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3)). - [ePrivacy Directive vs GDPR | Which Law Applies to Cookies, Tracking, Communications Metadata, and Marketing?](/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr.md): A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality. - [ePrivacy FAQ (Directive 2002/58/EC) | Cookies, Consent Exemptions, Cookie Walls, Marketing, Enforcement](/artifacts/eu/eprivacy-directive/faq.md): High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194). - [ePrivacy vs GDPR (Cookie Stack Blueprint) | Align Consent UX, Tag Firing, Processing Purposes, and Evidence](/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr.md): A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing. - [EU Cookie Banner Requirements | ePrivacy Directive + GDPR Consent (EDPB) | UX Patterns + Test Cases](/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements.md): A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eprivacy-directive/direct-marketing-rules --- --- title: "ePrivacy Directive Enforcement (Cookies + Marketing)" canonical_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/enforcement-and-fines" source_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/enforcement-and-fines" author: "Sorena AI" description: "An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "ePrivacy Directive enforcement" - "cookie banner enforcement EU" - "ePrivacy cookie consent enforcement" - "no reject button cookie banner" - "cookie wall ePrivacy" - "consent withdrawal as easy as giving" - "CMP configuration evidence" - "ePrivacy Directive fines enforcement" - "cookie banner enforcement" - "consent UX" - "CMP configuration" - "evidence pack" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ePrivacy Directive Enforcement (Cookies + Marketing) An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX. *Deep Dive* *EU* ## EU ePrivacy Directive Enforcement How regulators assess cookie banners, consent UX, and evidence. Focus: enforcement triggers, investigation readiness, and an evidence pack you can export fast. ePrivacy enforcement is rarely about legal theory in isolation. It is about observable outcomes: did your site/app place or read trackers without valid consent (or without a valid exemption)? Did users have a real reject option? Can users withdraw as easily as they consented? And can you prove it with repeatable evidence (CMP configuration exports, logs, and tests)? This page shows how enforcement typically works and how to be investigation-ready. ## Who enforces the ePrivacy Directive (and why enforcement is fragmented) The ePrivacy Directive is implemented through national laws. Enforcement competence is therefore national and can involve different bodies depending on the Member State (e.g., telecom regulators, DPAs, or other authorities). EDPB guidance emphasizes that the Directive explicitly allows more than one national body to be competent and requires Member States to provide effective enforcement powers (cessation orders, investigative powers, cross-border cooperation). - Expect enforcement to be market-specific: the same banner pattern can be assessed differently across Member States. - Build a single evidence pack, but add country overlays (local guidance, language, and implementation nuances). - Plan for cross-border cooperation expectations for widespread services. *Recommended next step* *Placement: after the enforcement section* ## Use EU ePrivacy Directive Enforcement as a cited research workflow Research Copilot can take EU ePrivacy Directive Enforcement from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU ePrivacy Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ePrivacy Directive Enforcement](/solutions/research-copilot.md): Start from EU ePrivacy Directive Enforcement and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ePrivacy Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU ePrivacy Directive Enforcement. ## What triggers enforcement in cookie banner cases (common denominator positions) The EDPB Cookie Banner Taskforce report reflects the shared interpretation used to handle cookie-banner complaints across multiple authorities (with national requirements still applying). Treat it as an enforcement-oriented checklist for banner UX, consent validity, and withdrawal. - No consent-by-default: consent-requiring cookies/trackers must not be set before consent is expressed by a positive action. - No "accept only" pattern: a majority of authorities considered missing reject/refuse options (on any layer that offers consent) not in line with valid consent requirements. - No confusing "double refusal" patterns: users should not have to refuse multiple times due to mixed ePrivacy and GDPR framing in deeper layers. - No legitimate interest for placement/reading: the legal basis for the placement/reading under Article 5(3) cannot be legitimate interests. - Withdrawal needs to be easy and accessible (e.g., persistent link/icon to reopen choices), assessed case-by-case. ## Investigation-ready evidence pack (what you should export in < 48 hours) Enforcement becomes painful when teams cannot prove what happened in production. Build evidence that is attributable, versioned, and reproducible. Design your proof so it answers: what was deployed, what users saw, what choices were available, and what trackers actually fired. - Tracker inventory and decision table: purpose, exemption rationale, vendors, and markets. - CMP/banner configuration export: purposes, vendors, default states, geo rules, and UI variants. - Consent log schema: timestamp, locale, user choice per purpose/vendor, banner version, and proof of withdrawal. - Tag manager and SDK enforcement evidence: pre-consent blocking rules and post-consent activation mapping. - Automated tests: screenshots/flows verifying "reject all", "save preferences", and "withdraw" paths. ## How to respond to a complaint or regulator inquiry (fast, consistent, and calm) Treat enforcement response like an incident: intake -> triage -> evidence export -> remediation -> follow-up. Your goal is controlled, explainable change rather than rushed edits. If the allegation is about cookie banners, validate production behavior with real network traces and device tests (not only CMP screenshots). - Freeze the deployed config (export CMP + tag manager settings and store them with a timestamp). - Reproduce key flows with fresh devices/browsers and capture trace evidence (what fired pre-consent vs post-consent). - Document root cause and remediate with a measured release (include regression tests). - Update your decision table and evidence index; communicate changes internally and to vendors. ## Primary sources - [Directive 2002/58/EC (ePrivacy Directive) - consolidated text (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02002L0058-20091219&ref=sorena.io) - National implementation and enforcement framework (including Article 15a). - [EDPB Report - Cookie Banner Taskforce (Jan 2023)](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Common denominator enforcement positions used when handling cookie-banner complaints. - [EDPB Opinion 5/2019 on ePrivacy Directive and GDPR interplay](https://edpb.europa.eu/sites/edpb/files/files/file1/201905_edpb_opinion_eprivacydir_gdpr_interplay_en.pdf?ref=sorena.io) - Competence and enforcement where GDPR and national ePrivacy law intersect. - [EDPB Guidelines 05/2020 on consent under GDPR](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_202005_consent_en.pdf?ref=sorena.io) - Consent validity conditions used when assessing ePrivacy consent references. - [WP29 Opinion 04/2012 on Cookie Consent Exemption (WP194)](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf?ref=sorena.io) - Practical test for Article 5(3) exemptions (transmission / strictly necessary). ## Related Topic Guides - [Confidentiality of Communications (ePrivacy Directive) | Traffic Data, Location Data, Content, and the OTT Gap](/artifacts/eu/eprivacy-directive/confidentiality-of-communications.md): A practical guide to communications confidentiality under the current ePrivacy Directive, Directive 2002/58/EC: how to classify content, traffic data. - [Cookies & Consent (ePrivacy Directive Article 5(3)) | Exemptions Test, Analytics, CMP Implementation](/artifacts/eu/eprivacy-directive/cookies-and-consent.md): An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage. - [Direct Marketing Consent Checklist (ePrivacy Article 13) | Proof, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist.md): A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control. - [Direct Marketing Rules (ePrivacy Directive Article 13) | Consent, Soft Opt-In, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-rules.md): A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed. - [ePrivacy Applicability Test (Directive 2002/58/EC) | Cookies Article 5(3), Marketing Article 13, Metadata](/artifacts/eu/eprivacy-directive/applicability-test.md): A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting. - [ePrivacy Checklist (Directive 2002/58/EC) | Cookie Banner, Consent Logs, Exemptions, Marketing Evidence](/artifacts/eu/eprivacy-directive/checklist.md): An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions). - [ePrivacy Compliance Program | Cookies, Consent UX, Evidence, Marketing Controls (Directive 2002/58/EC)](/artifacts/eu/eprivacy-directive/compliance.md): A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design. - [ePrivacy Deadlines and Compliance Calendar | Directive Baseline, Banner Audits, Marketing Audits](/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar.md): A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment. - [ePrivacy Directive Penalties and Fines | What "Effective, Proportionate, Dissuassive" Means + Risk Reduction Controls](/artifacts/eu/eprivacy-directive/penalties-and-fines.md): Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC). - [ePrivacy Directive Requirements (2002/58/EC) | Article 5(3) Cookies, Article 13 Marketing, Metadata + Evidence Map](/artifacts/eu/eprivacy-directive/requirements.md): A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3)). - [ePrivacy Directive vs GDPR | Which Law Applies to Cookies, Tracking, Communications Metadata, and Marketing?](/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr.md): A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality. - [ePrivacy FAQ (Directive 2002/58/EC) | Cookies, Consent Exemptions, Cookie Walls, Marketing, Enforcement](/artifacts/eu/eprivacy-directive/faq.md): High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194). - [ePrivacy vs GDPR (Cookie Stack Blueprint) | Align Consent UX, Tag Firing, Processing Purposes, and Evidence](/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr.md): A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing. - [EU Cookie Banner Requirements | ePrivacy Directive + GDPR Consent (EDPB) | UX Patterns + Test Cases](/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements.md): A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eprivacy-directive/enforcement-and-fines --- --- title: "ePrivacy Directive vs GDPR" canonical_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr" source_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr" author: "Sorena AI" description: "A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "ePrivacy Directive vs GDPR" - "cookies ePrivacy vs GDPR" - "Article 5(3) GDPR" - "cookie consent ePrivacy GDPR interplay" - "communications metadata ePrivacy GDPR" - "direct marketing Article 13 GDPR" - "ePrivacy vs GDPR" - "Article 5(3) cookies" - "communications confidentiality" - "metadata" - "direct marketing" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ePrivacy Directive vs GDPR A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality. *Explainer* *EU* ## EU ePrivacy Directive vs GDPR Which law applies, when, and how to document the split. Use the two-layer model: placement/reading and communications confidentiality (ePrivacy), subsequent processing (GDPR). Teams get stuck because cookies, ads, and analytics happen in one user journey but sit in a multi-layer legal model. The practical approach endorsed in EDPB guidance: ePrivacy national law governs the placement/reading of information on the device (Article 5(3)) and communications confidentiality; GDPR governs subsequent processing of personal data derived from that access. This page turns that principle into scenarios and concrete documentation patterns. ## The two-layer model (the easiest way to stay consistent) Layer A (ePrivacy): placement/reading and communications confidentiality. This is where cookie banner UX and consent/exemption decisions live. Layer B (GDPR): what you do with data after placement/reading - profiling, measurement, ad selection, sharing, retention, rights, transfers. - If a tracker is set/read: assess ePrivacy first (consent vs exemption). - If the tracker produces or enables personal data processing: assess GDPR lawful basis and transparency for that subsequent processing. - Keep choices aligned: the user should not "reject" trackers but still be profiled downstream due to engineering gaps. ## Common scenarios: which rules bite where? Use this as a mental model for product, legal, and engineering reviews. The scenarios are phrased like real backlog tickets. - Analytics cookie: ePrivacy decides if consent is needed to place/read; GDPR decides lawful basis and transparency for analytics processing. - Advertising pixel: ePrivacy governs placement/reading; GDPR governs profiling/targeting and sharing. - Device fingerprinting technique: ePrivacy-style device access logic applies; GDPR applies to resulting personal data processing. - Email marketing: ePrivacy Article 13 governs consent/soft opt-in and opt-out requirements; GDPR governs personal data processing aspects and records. - Communications metadata: ePrivacy confidentiality constraints apply; GDPR applies to subsequent processing and retention justification. ## The three mistakes that create enforcement risk Most "ePrivacy vs GDPR" failures are not legal nuance; they are mismatches between UI, system behavior, and documentation. - Using legitimate interests for placement/reading under Article 5(3): EDPB positions indicate this is not the basis for placement/reading. - Banner says "manage choices" but does not offer a real reject option (or hides it): a majority view treated this as invalid consent. - Engineering mismatch: tags/SDKs still fire before consent due to tag manager misconfiguration or asynchronous loads. ## Documentation that survives audits (what to write down, and where) Make the split explicit in your internal documentation and your external notices. Don't force one policy to do two different jobs. A good evidence set demonstrates consistent user choice handling across both layers. - Tracker decision table (ePrivacy): consent vs exemption per tracker, per market, with rationale and approvals. - Processing register (GDPR): purposes, lawful basis, recipients, retention, transfers, DPIA/LIAs where relevant. - CMP and tag manager mapping: choices -> runtime behavior -> downstream systems (analytics, ads, CDP). - Consent logs + withdrawal logs: link the banner version to the processing purposes in effect at the time. *Recommended next step* *Placement: after the comparison section* ## Use EU ePrivacy Directive vs GDPR as a cited research workflow Research Copilot can take EU ePrivacy Directive vs GDPR from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU ePrivacy Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ePrivacy Directive vs GDPR](/solutions/research-copilot.md): Start from EU ePrivacy Directive vs GDPR and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ePrivacy Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU ePrivacy Directive vs GDPR. ## Primary sources - [EDPB Opinion 5/2019 on ePrivacy Directive and GDPR interplay](https://edpb.europa.eu/sites/edpb/files/files/file1/201905_edpb_opinion_eprivacydir_gdpr_interplay_en.pdf?ref=sorena.io) - Interplay model and enforcement competence when ePrivacy and GDPR intersect. - [EDPB Report - Cookie Banner Taskforce (Jan 2023)](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Explains how authorities interpret banner UX, consent validity, and the placement/reading vs subsequent processing split. - [Directive 2002/58/EC (ePrivacy Directive) - consolidated text (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02002L0058-20091219&ref=sorena.io) - Primary framework for communications confidentiality and device access rules. - [EDPB Guidelines 05/2020 on consent under GDPR](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_202005_consent_en.pdf?ref=sorena.io) - Consent validity conditions used when ePrivacy references GDPR consent concepts. ## Related Topic Guides - [Confidentiality of Communications (ePrivacy Directive) | Traffic Data, Location Data, Content, and the OTT Gap](/artifacts/eu/eprivacy-directive/confidentiality-of-communications.md): A practical guide to communications confidentiality under the current ePrivacy Directive, Directive 2002/58/EC: how to classify content, traffic data. - [Cookies & Consent (ePrivacy Directive Article 5(3)) | Exemptions Test, Analytics, CMP Implementation](/artifacts/eu/eprivacy-directive/cookies-and-consent.md): An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage. - [Direct Marketing Consent Checklist (ePrivacy Article 13) | Proof, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist.md): A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control. - [Direct Marketing Rules (ePrivacy Directive Article 13) | Consent, Soft Opt-In, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-rules.md): A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed. - [ePrivacy Applicability Test (Directive 2002/58/EC) | Cookies Article 5(3), Marketing Article 13, Metadata](/artifacts/eu/eprivacy-directive/applicability-test.md): A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting. - [ePrivacy Checklist (Directive 2002/58/EC) | Cookie Banner, Consent Logs, Exemptions, Marketing Evidence](/artifacts/eu/eprivacy-directive/checklist.md): An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions). - [ePrivacy Compliance Program | Cookies, Consent UX, Evidence, Marketing Controls (Directive 2002/58/EC)](/artifacts/eu/eprivacy-directive/compliance.md): A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design. - [ePrivacy Deadlines and Compliance Calendar | Directive Baseline, Banner Audits, Marketing Audits](/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar.md): A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment. - [ePrivacy Directive Enforcement (Cookies + Marketing) | How Regulators Assess Cookie Banners, Consent, and Evidence](/artifacts/eu/eprivacy-directive/enforcement-and-fines.md): An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX. - [ePrivacy Directive Penalties and Fines | What "Effective, Proportionate, Dissuassive" Means + Risk Reduction Controls](/artifacts/eu/eprivacy-directive/penalties-and-fines.md): Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC). - [ePrivacy Directive Requirements (2002/58/EC) | Article 5(3) Cookies, Article 13 Marketing, Metadata + Evidence Map](/artifacts/eu/eprivacy-directive/requirements.md): A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3)). - [ePrivacy FAQ (Directive 2002/58/EC) | Cookies, Consent Exemptions, Cookie Walls, Marketing, Enforcement](/artifacts/eu/eprivacy-directive/faq.md): High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194). - [ePrivacy vs GDPR (Cookie Stack Blueprint) | Align Consent UX, Tag Firing, Processing Purposes, and Evidence](/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr.md): A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing. - [EU Cookie Banner Requirements | ePrivacy Directive + GDPR Consent (EDPB) | UX Patterns + Test Cases](/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements.md): A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr --- --- title: "ePrivacy vs GDPR (Cookie Stack Blueprint)" canonical_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr" source_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr" author: "Sorena AI" description: "A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "ePrivacy vs GDPR" - "cookie stack compliance" - "CMP enforcement" - "pre-consent blocking tag manager" - "consent logs GDPR ePrivacy" - "consent withdrawal icon" - "cookie banner audit evidence" - "ePrivacy GDPR alignment" - "cookie stack blueprint" - "consent logs" - "withdrawal UX" - "ePrivacy and GDPR alignment" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ePrivacy vs GDPR (Cookie Stack Blueprint) A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing. *Blueprint* *EU* ## ePrivacy + GDPR How to Align the Stack Turn consent into a system that actually controls what your product does. Focus: UX -> configuration -> runtime enforcement -> processing purposes -> audit evidence. The fastest way to fail "ePrivacy vs GDPR" is to build a nice banner that does not control runtime behavior. The enforcement mindset is simple: if consent was required and you didn't get valid consent, the placement/reading is unlawful and the downstream processing is not safe either. This page gives you a practical blueprint for aligning ePrivacy (device access + communications confidentiality) with GDPR (subsequent processing) so you can prove outcomes with logs and tests. ## Blueprint overview: 6 layers to keep consistent Think in layers. Each layer has an owner, an artifact, and a test. If any layer is missing, you'll have "consent theater". - Layer 1 (Inventory): tracker + SDK + storage inventory with markets, purposes, and vendors. - Layer 2 (Legal model): ePrivacy decision table (consent vs exemption) + GDPR processing-purpose map. - Layer 3 (UX): banner and settings UI that makes refusal and withdrawal realistic and understandable. - Layer 4 (Enforcement): CMP config + tag manager rules + SDK gating to prevent pre-consent firing. - Layer 5 (Logging): consent and withdrawal logs that link to banner version and purpose/vendor choices. - Layer 6 (Evidence export): repeatable export pack for audits and regulator inquiries. ## Aligning choices to runtime behavior (the part regulators and auditors actually care about) Most findings are caused by mismatches between "what the banner says" and "what scripts did". Solve that with a deterministic mapping from consent choices to runtime outcomes. The Cookie Banner Taskforce positions highlight common issues: lack of reject option, confusing flows, pre-consent placement, and withdrawal friction. - Define acceptance criteria: "no consent = no firing" for consent-requiring trackers, verified via network traces. - Implement hard blocks: do not rely only on vendor promises; enforce in tag manager and SDK initialization. - Keep geo rules explicit: EU vs non-EU experiences must be intentional and testable. - Make withdrawal easy: persistent entry point to settings and immediate effect on firing. ## Consent alignment between ePrivacy and GDPR (when consent is used downstream) ePrivacy governs placement/reading; GDPR governs subsequent processing. If your downstream processing uses GDPR consent, align the conditions so users are not misled and so consent remains "freely given, specific, informed, unambiguous". Document the link between what the user chose (purposes/vendors) and what processing is enabled. - One consent taxonomy: align CMP purposes to GDPR purposes (avoid vague "improve experience" buckets). - Version consent wording and purpose definitions; store the version in logs. - Do not introduce hidden lawful bases in deeper layers that contradict top-layer refusal choices. - Make "reject all" and "save preferences" work equivalently to "accept all" (no degraded UX that pressures consent). ## Audit evidence: what "good" looks like (practical checklist) If you can produce the list below quickly and consistently, you're ahead of most teams. Treat evidence as product output - generated, not manually assembled. - Tracker decision table (ePrivacy): consent vs exemption per tracker, with rationale and approvals. - CMP export: purposes/vendors, default states, UI layers, and geo rules. - Runtime proof: automated tests and traces demonstrating "no pre-consent firing" and correct withdrawal behavior. - Consent/withdrawal logs: timestamp, locale, purpose/vendor selections, banner version, and change history. - GDPR processing map: purposes, lawful basis, recipients, retention, transfers, and DPIA/records where needed. *Recommended next step* *Placement: after the comparison section* ## Use ePrivacy + GDPR How to Align the Stack as a cited research workflow Research Copilot can take ePrivacy + GDPR How to Align the Stack from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on ePrivacy + GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ePrivacy + GDPR How to Align the Stack](/solutions/research-copilot.md): Start from ePrivacy + GDPR How to Align the Stack and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ePrivacy + GDPR](/contact.md): Review your current process, evidence gaps, and next steps for ePrivacy + GDPR How to Align the Stack. ## Primary sources - [EDPB Report - Cookie Banner Taskforce (Jan 2023)](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Practical positions on cookie banner UX, consent validity, and withdrawal patterns. - [EDPB Opinion 5/2019 on ePrivacy Directive and GDPR interplay](https://edpb.europa.eu/sites/edpb/files/files/file1/201905_edpb_opinion_eprivacydir_gdpr_interplay_en.pdf?ref=sorena.io) - Explains the placement/reading vs subsequent processing model and enforcement competence. - [EDPB Guidelines 05/2020 on consent under GDPR](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_202005_consent_en.pdf?ref=sorena.io) - Consent validity criteria used when ePrivacy references GDPR consent concepts. - [Directive 2002/58/EC (ePrivacy Directive) - consolidated text (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02002L0058-20091219&ref=sorena.io) - Primary legal framework for device access and communications confidentiality. ## Related Topic Guides - [Confidentiality of Communications (ePrivacy Directive) | Traffic Data, Location Data, Content, and the OTT Gap](/artifacts/eu/eprivacy-directive/confidentiality-of-communications.md): A practical guide to communications confidentiality under the current ePrivacy Directive, Directive 2002/58/EC: how to classify content, traffic data. - [Cookies & Consent (ePrivacy Directive Article 5(3)) | Exemptions Test, Analytics, CMP Implementation](/artifacts/eu/eprivacy-directive/cookies-and-consent.md): An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage. - [Direct Marketing Consent Checklist (ePrivacy Article 13) | Proof, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist.md): A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control. - [Direct Marketing Rules (ePrivacy Directive Article 13) | Consent, Soft Opt-In, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-rules.md): A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed. - [ePrivacy Applicability Test (Directive 2002/58/EC) | Cookies Article 5(3), Marketing Article 13, Metadata](/artifacts/eu/eprivacy-directive/applicability-test.md): A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting. - [ePrivacy Checklist (Directive 2002/58/EC) | Cookie Banner, Consent Logs, Exemptions, Marketing Evidence](/artifacts/eu/eprivacy-directive/checklist.md): An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions). - [ePrivacy Compliance Program | Cookies, Consent UX, Evidence, Marketing Controls (Directive 2002/58/EC)](/artifacts/eu/eprivacy-directive/compliance.md): A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design. - [ePrivacy Deadlines and Compliance Calendar | Directive Baseline, Banner Audits, Marketing Audits](/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar.md): A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment. - [ePrivacy Directive Enforcement (Cookies + Marketing) | How Regulators Assess Cookie Banners, Consent, and Evidence](/artifacts/eu/eprivacy-directive/enforcement-and-fines.md): An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX. - [ePrivacy Directive Penalties and Fines | What "Effective, Proportionate, Dissuassive" Means + Risk Reduction Controls](/artifacts/eu/eprivacy-directive/penalties-and-fines.md): Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC). - [ePrivacy Directive Requirements (2002/58/EC) | Article 5(3) Cookies, Article 13 Marketing, Metadata + Evidence Map](/artifacts/eu/eprivacy-directive/requirements.md): A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3)). - [ePrivacy Directive vs GDPR | Which Law Applies to Cookies, Tracking, Communications Metadata, and Marketing?](/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr.md): A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality. - [ePrivacy FAQ (Directive 2002/58/EC) | Cookies, Consent Exemptions, Cookie Walls, Marketing, Enforcement](/artifacts/eu/eprivacy-directive/faq.md): High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194). - [EU Cookie Banner Requirements | ePrivacy Directive + GDPR Consent (EDPB) | UX Patterns + Test Cases](/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements.md): A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr --- --- title: "EU Cookie Banner Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements" source_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements" author: "Sorena AI" description: "A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU cookie banner requirements" - "cookie banner compliant EU" - "reject cookies button required" - "cookie wall consent EU" - "CMP best practices EU" - "cookie banner testing checklist" - "EDPB cookie banner taskforce" - "cookie banner requirements" - "CMP" - "consent UX" - "cookie walls" - "EDPB" - "enforcement" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Cookie Banner Requirements A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes. *UX + QA Guide* *EU* ## EU ePrivacy Directive Cookie Banner Requirements Design banner UX that produces valid choice and audit-ready proof. Focus: consent UX patterns, cookie walls, and testing against common enforcement findings. Cookie banners fail when they look compliant but don't enforce outcomes. Enforcement is increasingly evidence-driven: regulators and complainants assess whether non-exempt trackers fire before consent and whether the user had a real choice. This page translates common denominator guidance into UI/UX patterns and test cases you can ship safely. ## Minimum banner outcomes (what your banner must be able to prove) Your banner must produce a clear decision and enforce it across trackers. The best way to reduce risk is to define outcomes as acceptance criteria and test them automatically. - Pre-consent: only exempt trackers run (transmission / strictly necessary). - Accept all: mapped trackers run per declared purposes/vendors. - Reject all: non-exempt trackers do not run; no shadow firing via tag managers. - Granular choices: partial consent mapped correctly; withdrawal updates firing behavior. ## UI/UX requirements: choice must be real (not nudged into one outcome) A banner is a choice interface. When "reject" is hidden or made difficult, enforcement risk rises. Design for clarity and symmetry. - Parity: reject must be as easy as accept (no multi-click reject vs one-click accept). - Granularity: provide purpose-level (and where relevant vendor-level) controls without burying them. - Plain language: purposes and consequences explained; avoid vague "improve your experience" phrasing. - No pre-ticked boxes; defaults must not enable non-exempt trackers. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU ePrivacy Directive Cookie Banner Requirements into an operational assessment Assessment Autopilot can take EU ePrivacy Directive Cookie Banner Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU ePrivacy Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU ePrivacy Directive Cookie Banner Requirements](/solutions/assessment.md): Start from EU ePrivacy Directive Cookie Banner Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU ePrivacy Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU ePrivacy Directive Cookie Banner Requirements. ## Cookie walls and conditionality When access to a service is conditioned on consent to non-essential tracking, consent validity can be challenged. Treat cookie walls as high-risk and require explicit legal review before deploying. - Document whether the service can be reasonably accessed without consenting to non-essential tracking. - Provide an alternative if you rely on consent for non-essential purposes in a way that could be considered conditional. - Store rationale and approval in your evidence index. ## Implementation checklist (engineering + evidence) Design for proof: you should be able to export CMP config and reproduce behavior. Build a release gate so new tags can't ship without mapping. - CMP config snapshots versioned (purposes, vendors, mapping rules). - Consent/withdrawal logs include banner version, locale, purposes/vendors, timestamp. - Automated tests: UI tests + network-level tests verifying no pre-consent firing. - Tag manager governance: approvals, change logs, and environment separation. ## Primary sources - [EDPB Report - Cookie Banner Taskforce (Jan 2023)](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Common denominator positions and recurring issues observed in cookie banner complaints. - [EDPB Guidelines 05/2020 on consent under GDPR](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_202005_consent_en.pdf?ref=sorena.io) - Consent validity guidance, including conditionality/cookie-wall discussion. - [WP29 Opinion 04/2012 on Cookie Consent Exemption (WP194)](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf?ref=sorena.io) - Exemptions test for transmission and strictly necessary cookies (helps define what can run pre-consent). ## Related Topic Guides - [Confidentiality of Communications (ePrivacy Directive) | Traffic Data, Location Data, Content, and the OTT Gap](/artifacts/eu/eprivacy-directive/confidentiality-of-communications.md): A practical guide to communications confidentiality under the current ePrivacy Directive, Directive 2002/58/EC: how to classify content, traffic data. - [Cookies & Consent (ePrivacy Directive Article 5(3)) | Exemptions Test, Analytics, CMP Implementation](/artifacts/eu/eprivacy-directive/cookies-and-consent.md): An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage. - [Direct Marketing Consent Checklist (ePrivacy Article 13) | Proof, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist.md): A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control. - [Direct Marketing Rules (ePrivacy Directive Article 13) | Consent, Soft Opt-In, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-rules.md): A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed. - [ePrivacy Applicability Test (Directive 2002/58/EC) | Cookies Article 5(3), Marketing Article 13, Metadata](/artifacts/eu/eprivacy-directive/applicability-test.md): A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting. - [ePrivacy Checklist (Directive 2002/58/EC) | Cookie Banner, Consent Logs, Exemptions, Marketing Evidence](/artifacts/eu/eprivacy-directive/checklist.md): An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions). - [ePrivacy Compliance Program | Cookies, Consent UX, Evidence, Marketing Controls (Directive 2002/58/EC)](/artifacts/eu/eprivacy-directive/compliance.md): A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design. - [ePrivacy Deadlines and Compliance Calendar | Directive Baseline, Banner Audits, Marketing Audits](/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar.md): A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment. - [ePrivacy Directive Enforcement (Cookies + Marketing) | How Regulators Assess Cookie Banners, Consent, and Evidence](/artifacts/eu/eprivacy-directive/enforcement-and-fines.md): An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX. - [ePrivacy Directive Penalties and Fines | What "Effective, Proportionate, Dissuassive" Means + Risk Reduction Controls](/artifacts/eu/eprivacy-directive/penalties-and-fines.md): Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC). - [ePrivacy Directive Requirements (2002/58/EC) | Article 5(3) Cookies, Article 13 Marketing, Metadata + Evidence Map](/artifacts/eu/eprivacy-directive/requirements.md): A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3)). - [ePrivacy Directive vs GDPR | Which Law Applies to Cookies, Tracking, Communications Metadata, and Marketing?](/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr.md): A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality. - [ePrivacy FAQ (Directive 2002/58/EC) | Cookies, Consent Exemptions, Cookie Walls, Marketing, Enforcement](/artifacts/eu/eprivacy-directive/faq.md): High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194). - [ePrivacy vs GDPR (Cookie Stack Blueprint) | Align Consent UX, Tag Firing, Processing Purposes, and Evidence](/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr.md): A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements --- --- title: "ePrivacy FAQ (Directive 2002/58/EC)" canonical_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/faq" source_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/faq" author: "Sorena AI" description: "High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "ePrivacy FAQ" - "cookie consent FAQ EU" - "strictly necessary cookies exemption FAQ" - "cookie walls EDPB" - "ePrivacy vs GDPR cookie consent" - "ePrivacy one stop shop" - "ePrivacy enforcement cookie banner complaints" - "cookie consent" - "strictly necessary cookies" - "cookie walls" - "Article 13" - "enforcement" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ePrivacy FAQ (Directive 2002/58/EC) High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194). *FAQ* *EU* ## EU ePrivacy Directive FAQ Fast answers with practical next steps and evidence guidance. Grounded in ePrivacy Directive text plus EDPB/WP29 enforcement learnings. This FAQ is written for teams shipping products. Each answer focuses on what to do next and what evidence to keep. Always validate against national implementation and counsel. ## Do analytics cookies require consent? In many implementations, analytics trackers are treated as requiring consent because they are not strictly necessary to provide the service explicitly requested by the user. If you want a low-risk posture, treat analytics as consent-based unless you have a narrow, defensible exemption rationale. - Document analytics purpose, data, recipients, and retention. - Prove enforcement: analytics must not fire pre-consent. - Keep evidence: CMP config snapshots + consent logs + tests. ## What does "strictly necessary" mean for cookie exemptions? WP29 guidance emphasizes narrow interpretation: "useful" or "improves performance" is not the same as strictly necessary. Treat exemptions as a legal decision with acceptance criteria and approvals. - Transmission exemption: communication must not be possible without the cookie/technique. - Strictly necessary: required to provide the service explicitly requested by the user. - Exempt trackers still need governance and monitoring. ## Do cookie walls invalidate consent? Consent validity can be challenged when access to a service is conditioned on consent to non-essential tracking. Treat cookie walls as high-risk and require explicit legal review and alternatives. - Document conditionality risk and alternative access paths (if any). - Make choices and consequences transparent. - Store rationale and approvals in the evidence index. ## ePrivacy vs GDPR: what law applies when? A common model: ePrivacy national law governs placement/reading of trackers; GDPR governs subsequent processing of personal data collected via those trackers. Your documentation should separate these layers and ensure consent conditions and information duties are aligned. - Layer A (ePrivacy): tracker decision table + banner behavior. - Layer B (GDPR): lawful basis and transparency for subsequent processing. - Enforcement: one-stop-shop often does not apply to ePrivacy matters. ## What should we be able to export during a complaint/inquiry? Enforcement is evidence-driven. Your capability is "exportability": can you produce coherent proof quickly? Build an export pack and rehearse it annually. - Tracker decision table + CMP config snapshot + consent log schema + sample exports. - Automated test results proving pre-consent blocking and withdrawal propagation. - Marketing evidence pack: consent capture, withdrawals, suppression governance, vendor list. *Recommended next step* *Placement: after the FAQ section* ## Use EU ePrivacy Directive FAQ as a cited research workflow Research Copilot can take EU ePrivacy Directive FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU ePrivacy Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ePrivacy Directive FAQ](/solutions/research-copilot.md): Start from EU ePrivacy Directive FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ePrivacy Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU ePrivacy Directive FAQ. ## Primary sources - [Directive 2002/58/EC (ePrivacy Directive) - consolidated text (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02002L0058-20091219&ref=sorena.io) - Directive framework including Article 5(3) and Article 13. - [WP29 Opinion 04/2012 on Cookie Consent Exemption (WP194)](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf?ref=sorena.io) - Exemption criteria analysis for Article 5(3). - [EDPB Report - Cookie Banner Taskforce (Jan 2023)](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Enforcement learnings from coordinated cookie banner complaints. ## Related Topic Guides - [Confidentiality of Communications (ePrivacy Directive) | Traffic Data, Location Data, Content, and the OTT Gap](/artifacts/eu/eprivacy-directive/confidentiality-of-communications.md): A practical guide to communications confidentiality under the current ePrivacy Directive, Directive 2002/58/EC: how to classify content, traffic data. - [Cookies & Consent (ePrivacy Directive Article 5(3)) | Exemptions Test, Analytics, CMP Implementation](/artifacts/eu/eprivacy-directive/cookies-and-consent.md): An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage. - [Direct Marketing Consent Checklist (ePrivacy Article 13) | Proof, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist.md): A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control. - [Direct Marketing Rules (ePrivacy Directive Article 13) | Consent, Soft Opt-In, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-rules.md): A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed. - [ePrivacy Applicability Test (Directive 2002/58/EC) | Cookies Article 5(3), Marketing Article 13, Metadata](/artifacts/eu/eprivacy-directive/applicability-test.md): A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting. - [ePrivacy Checklist (Directive 2002/58/EC) | Cookie Banner, Consent Logs, Exemptions, Marketing Evidence](/artifacts/eu/eprivacy-directive/checklist.md): An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions). - [ePrivacy Compliance Program | Cookies, Consent UX, Evidence, Marketing Controls (Directive 2002/58/EC)](/artifacts/eu/eprivacy-directive/compliance.md): A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design. - [ePrivacy Deadlines and Compliance Calendar | Directive Baseline, Banner Audits, Marketing Audits](/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar.md): A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment. - [ePrivacy Directive Enforcement (Cookies + Marketing) | How Regulators Assess Cookie Banners, Consent, and Evidence](/artifacts/eu/eprivacy-directive/enforcement-and-fines.md): An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX. - [ePrivacy Directive Penalties and Fines | What "Effective, Proportionate, Dissuassive" Means + Risk Reduction Controls](/artifacts/eu/eprivacy-directive/penalties-and-fines.md): Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC). - [ePrivacy Directive Requirements (2002/58/EC) | Article 5(3) Cookies, Article 13 Marketing, Metadata + Evidence Map](/artifacts/eu/eprivacy-directive/requirements.md): A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3)). - [ePrivacy Directive vs GDPR | Which Law Applies to Cookies, Tracking, Communications Metadata, and Marketing?](/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr.md): A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality. - [ePrivacy vs GDPR (Cookie Stack Blueprint) | Align Consent UX, Tag Firing, Processing Purposes, and Evidence](/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr.md): A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing. - [EU Cookie Banner Requirements | ePrivacy Directive + GDPR Consent (EDPB) | UX Patterns + Test Cases](/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements.md): A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eprivacy-directive/faq --- --- title: "ePrivacy Directive Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/penalties-and-fines" author: "Sorena AI" description: "Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "ePrivacy Directive fines" - "ePrivacy Directive penalties" - "ePrivacy Directive enforcement fines" - "cookie banner fines EU" - "direct marketing fines EU" - "ePrivacy cookie consent penalties" - "effective proportionate dissuasive penalties" - "ePrivacy penalties" - "ePrivacy fines" - "cookie banner enforcement" - "direct marketing consent" - "risk reduction" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ePrivacy Directive Penalties and Fines Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC). *Risk Guide* *EU* ## EU ePrivacy Directive Penalties and Fines Penalty exposure varies by Member State. Your job is to reduce enforceability risk. Focus: what the Directive requires for sanctions + practical controls that prevent the most common violations. The ePrivacy Directive does not set a single EU-wide fine schedule. Instead, Member States implement ePrivacy via national laws and must define penalties that are effective, proportionate, and dissuasive, with real enforcement powers (cessation orders, investigative powers, resources, and cross-border cooperation). The result: penalty exposure is country-specific, while the core compliance failures are remarkably consistent across cookie banner complaints and direct marketing campaigns. ## What the Directive requires on penalties (and what that means for your risk model) Article 15a (Implementation and enforcement) requires Member States to lay down rules on penalties (including criminal sanctions where appropriate) and to ensure enforcement powers such as the ability to order cessation of infringements and to obtain relevant information for monitoring and enforcement. Treat this as a design constraint: your compliance system must support fast remediation (stop the violation) and fast explanation (export evidence). - Country-by-country penalty models: do not assume GDPR-style administrative fine levels, but assume meaningful sanctions exist. - Cessation power is central: the ability to stop cookie placement/marketing flows quickly is a core control. - Investigation readiness reduces secondary damage: delays, inconsistent evidence, and unclear ownership often worsen outcomes. *Recommended next step* *Placement: after the enforcement section* ## Use EU ePrivacy Directive Penalties and Fines as a cited research workflow Research Copilot can take EU ePrivacy Directive Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU ePrivacy Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ePrivacy Directive Penalties and Fines](/solutions/research-copilot.md): Start from EU ePrivacy Directive Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ePrivacy Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU ePrivacy Directive Penalties and Fines. ## Penalty drivers in real-world cookie banner cases (what usually goes wrong) Cookie enforcement focuses on consent validity and on whether consent-requiring trackers were set before consent. The Cookie Banner Taskforce positions give a practical baseline of what many authorities consider unacceptable patterns. - No reject/refuse option while offering accept: common reason for "invalid consent" findings. - Dark patterns: visually pushing consent, hiding refusal, unreadable refusal buttons, or misleading UI flows. - Consent not respected technically: tags and SDKs firing before consent (implementation gap between UI and runtime). - Withdrawal friction: users cannot easily change or withdraw consent after initial choice. - "Legitimate interest" used to justify placement/reading: not acceptable for Article 5(3) placement/reading. ## Direct marketing penalty drivers (Article 13) - why evidence matters Marketing enforcement often becomes a recordkeeping problem: you need to prove consent/soft opt-in conditions, opt-out handling, and suppression list governance. Design campaigns and tooling so consent state is consistent across vendors, channels, and versions of copy. - Consent proof: what users were told, when they opted in, and what purpose/channel was covered. - Opt-out execution: every message includes an opt-out; opt-out is honored quickly and permanently via suppression lists. - Vendor control: processors and platforms are configured to respect consent state; you can audit and export their settings. - Change control: message templates and consent wording are versioned so you can match events to the wording in use. ## Risk reduction controls (the shortlist that prevents the most expensive failures) Penalties are a lagging indicator. The leading indicators are engineering enforcement and governance: can the system prevent pre-consent placement and can you demonstrate that it did? Build controls that turn ePrivacy into repeatable product requirements, not ad-hoc banner edits. - Pre-consent blocking: tag manager/CMP enforcement that prevents scripts and SDKs from running before consent. - Tracker decision table: every tracker is mapped to consent vs exemption with documented rationale and approvals. - Release gates: CI/regression checks for "reject all", "accept all", and withdrawal flows; monitor runtime tag firing. - Evidence index: one place to export CMP config, consent logs, and tests for the current and previous versions. - Incident playbook: complaint intake -> freeze config -> reproduce -> remediate -> communicate. ## Primary sources - [Directive 2002/58/EC (ePrivacy Directive) - consolidated text (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02002L0058-20091219&ref=sorena.io) - Sets national implementation model, including Article 15a requirements for penalties and enforcement powers. - [EDPB Opinion 5/2019 on ePrivacy Directive and GDPR interplay](https://edpb.europa.eu/sites/edpb/files/files/file1/201905_edpb_opinion_eprivacydir_gdpr_interplay_en.pdf?ref=sorena.io) - Explains competence, tasks, and powers where ePrivacy and GDPR overlap; references Article 15a enforcement structure. - [EDPB Report - Cookie Banner Taskforce (Jan 2023)](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Minimum threshold positions used when analyzing cookie banner complaints (reject options, dark patterns, withdrawal, etc.). - [EDPB Guidelines 05/2020 on consent under GDPR](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_202005_consent_en.pdf?ref=sorena.io) - Consent validity framework referenced when ePrivacy relies on GDPR consent concepts. ## Related Topic Guides - [Confidentiality of Communications (ePrivacy Directive) | Traffic Data, Location Data, Content, and the OTT Gap](/artifacts/eu/eprivacy-directive/confidentiality-of-communications.md): A practical guide to communications confidentiality under the current ePrivacy Directive, Directive 2002/58/EC: how to classify content, traffic data. - [Cookies & Consent (ePrivacy Directive Article 5(3)) | Exemptions Test, Analytics, CMP Implementation](/artifacts/eu/eprivacy-directive/cookies-and-consent.md): An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage. - [Direct Marketing Consent Checklist (ePrivacy Article 13) | Proof, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist.md): A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control. - [Direct Marketing Rules (ePrivacy Directive Article 13) | Consent, Soft Opt-In, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-rules.md): A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed. - [ePrivacy Applicability Test (Directive 2002/58/EC) | Cookies Article 5(3), Marketing Article 13, Metadata](/artifacts/eu/eprivacy-directive/applicability-test.md): A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting. - [ePrivacy Checklist (Directive 2002/58/EC) | Cookie Banner, Consent Logs, Exemptions, Marketing Evidence](/artifacts/eu/eprivacy-directive/checklist.md): An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions). - [ePrivacy Compliance Program | Cookies, Consent UX, Evidence, Marketing Controls (Directive 2002/58/EC)](/artifacts/eu/eprivacy-directive/compliance.md): A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design. - [ePrivacy Deadlines and Compliance Calendar | Directive Baseline, Banner Audits, Marketing Audits](/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar.md): A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment. - [ePrivacy Directive Enforcement (Cookies + Marketing) | How Regulators Assess Cookie Banners, Consent, and Evidence](/artifacts/eu/eprivacy-directive/enforcement-and-fines.md): An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX. - [ePrivacy Directive Requirements (2002/58/EC) | Article 5(3) Cookies, Article 13 Marketing, Metadata + Evidence Map](/artifacts/eu/eprivacy-directive/requirements.md): A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3)). - [ePrivacy Directive vs GDPR | Which Law Applies to Cookies, Tracking, Communications Metadata, and Marketing?](/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr.md): A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality. - [ePrivacy FAQ (Directive 2002/58/EC) | Cookies, Consent Exemptions, Cookie Walls, Marketing, Enforcement](/artifacts/eu/eprivacy-directive/faq.md): High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194). - [ePrivacy vs GDPR (Cookie Stack Blueprint) | Align Consent UX, Tag Firing, Processing Purposes, and Evidence](/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr.md): A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing. - [EU Cookie Banner Requirements | ePrivacy Directive + GDPR Consent (EDPB) | UX Patterns + Test Cases](/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements.md): A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eprivacy-directive/penalties-and-fines --- --- title: "ePrivacy Directive Requirements (2002/58/EC)" canonical_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/requirements" source_url: "https://www.sorena.io/artifacts/eu/eprivacy-directive/requirements" author: "Sorena AI" description: "A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3))." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "ePrivacy Directive requirements" - "Directive 2002/58/EC requirements" - "Article 5(3) cookie consent" - "cookie consent exemptions strictly necessary" - "ePrivacy metadata rules" - "ePrivacy direct marketing Article 13" - "ePrivacy vs GDPR requirements" - "cookie banner compliance evidence" - "Directive 2002/58/EC" - "Article 5(3)" - "cookies" - "direct marketing" - "metadata" - "evidence map" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ePrivacy Directive Requirements (2002/58/EC) A practical ePrivacy Directive requirements breakdown: terminal equipment access and cookie consent/exemptions (Article 5(3)). *Requirements Guide* *EU* ## EU ePrivacy Directive Requirements A requirements breakdown you can implement: controls, UX, and evidence. Focus: Article 5(3) device access + Article 13 marketing + GDPR interplay. ePrivacy compliance works when it is engineered like a system: inventory -> legal model -> UX and controls -> logs and evidence -> continuous monitoring. This page breaks ePrivacy into implementable workstreams and shows what "done looks like" for cookie stacks, communications confidentiality/metadata, and direct marketing. ## Terminal equipment access (Article 5(3)) - the cookie/SDK decision table Article 5(3) is the center of most product ePrivacy work. It requires a clear mapping of each tracker/technique to consent or an exemption. The fastest way to reduce risk is to build a tracker-by-tracker decision table and keep it versioned. - Inventory everything: cookies, pixels, local storage, mobile SDK identifiers, and fingerprinting-like techniques. - For each: purpose, necessity, lifetime, who sets it, recipients, and markets. - Decision: consent required vs exemption (transmission / strictly necessary) with documented reasoning. ## Cookie consent exemptions - "strictly necessary" is narrower than teams think WP29 guidance provides a practical test for the two main exemption criteria and emphasizes how narrow "sole purpose" and "strictly necessary" should be interpreted. Treat exemptions as a legal decision with acceptance criteria, not a product preference. - Transmission exemption: the communication must not be possible without the cookie/technique. - Strictly necessary exemption: needed to provide a service explicitly requested by the user (not merely useful/efficient). - Even when exempt, information duties and governance still matter (document and monitor). ## Direct marketing (Article 13) - operational rules + proof Direct marketing compliance is an operational system: consent capture, opt-out, and suppression lists. Design evidence so you can answer: who consented, when, to what wording, and how withdrawal was honored. - Consent model + soft opt-in model (where applicable) documented per channel and market. - Opt-out in every message + suppression list governance (never re-add without documented reason). - Evidence: consent logs, wording versioning, withdrawal logs, and vendor/processor controls. ## GDPR interplay - ePrivacy for device access, GDPR for subsequent processing A common pattern: ePrivacy national law governs placement/reading; GDPR governs subsequent processing of personal data derived from that access. Your documentation should explicitly separate these layers and keep consent conditions aligned where GDPR consent is used. - Layer A: placement/reading (ePrivacy) - tracker mapping table and banner/CMP behavior. - Layer B: subsequent processing (GDPR) - lawful basis, transparency, retention, and data subject rights. - Evidence: show consistency between banner choices and downstream processing purposes. ## Evidence map (requirement -> owner -> artifact) Build a single evidence index. It is the fastest way to respond to regulators, auditors, and partner due diligence. Aim for coherence, not volume. - Tracker inventory + decision table (consent vs exemption) with approvals and version history. - Banner UX spec + CMP configuration export + automated regression tests (key flows). - Consent logs (timestamp, locale, purposes, vendors, banner version) + withdrawal logs. - Direct marketing evidence pack: consent capture flows, suppression list controls, vendor controls. - Enforcement response pack: how to export evidence quickly and consistently. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU ePrivacy Directive Requirements into an operational assessment Assessment Autopilot can take EU ePrivacy Directive Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU ePrivacy Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU ePrivacy Directive Requirements](/solutions/assessment.md): Start from EU ePrivacy Directive Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU ePrivacy Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU ePrivacy Directive Requirements. ## Primary sources - [Directive 2002/58/EC (ePrivacy Directive) - consolidated text (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02002L0058-20091219&ref=sorena.io) - Directive framework for communications privacy, terminal equipment access (Article 5(3)), and direct marketing (Article 13). - [WP29 Opinion 04/2012 on Cookie Consent Exemption (WP194)](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf?ref=sorena.io) - Detailed analysis of Article 5(3) consent exemption criteria. - [EDPB Opinion 5/2019 on ePrivacy Directive and GDPR interplay](https://edpb.europa.eu/sites/edpb/files/files/file1/201905_edpb_opinion_eprivacydir_gdpr_interplay_en.pdf?ref=sorena.io) - Interplay model and enforcement competence when ePrivacy and GDPR intersect. - [EDPB Report - Cookie Banner Taskforce (Jan 2023)](https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_20230118_report_cookie_banner_taskforce_en.pdf?ref=sorena.io) - Common denominator positions from coordinated handling of cookie banner complaints. ## Related Topic Guides - [Confidentiality of Communications (ePrivacy Directive) | Traffic Data, Location Data, Content, and the OTT Gap](/artifacts/eu/eprivacy-directive/confidentiality-of-communications.md): A practical guide to communications confidentiality under the current ePrivacy Directive, Directive 2002/58/EC: how to classify content, traffic data. - [Cookies & Consent (ePrivacy Directive Article 5(3)) | Exemptions Test, Analytics, CMP Implementation](/artifacts/eu/eprivacy-directive/cookies-and-consent.md): An advanced guide to cookie consent under the ePrivacy Directive (Directive 2002/58/EC): how Article 5(3) applies to cookies/SDKs/local storage. - [Direct Marketing Consent Checklist (ePrivacy Article 13) | Proof, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-consent-checklist.md): A practical direct marketing consent checklist for ePrivacy (Directive 2002/58/EC, Article 13): consent capture fields, wording/version control. - [Direct Marketing Rules (ePrivacy Directive Article 13) | Consent, Soft Opt-In, Opt-Out, Suppression Lists](/artifacts/eu/eprivacy-directive/direct-marketing-rules.md): A practical guide to ePrivacy direct marketing rules (Directive 2002/58/EC, Article 13): when prior consent is needed. - [ePrivacy Applicability Test (Directive 2002/58/EC) | Cookies Article 5(3), Marketing Article 13, Metadata](/artifacts/eu/eprivacy-directive/applicability-test.md): A practical EU ePrivacy applicability test: decide whether your product triggers terminal equipment access rules (cookies/SDKs/local storage/fingerprinting. - [ePrivacy Checklist (Directive 2002/58/EC) | Cookie Banner, Consent Logs, Exemptions, Marketing Evidence](/artifacts/eu/eprivacy-directive/checklist.md): An audit-ready ePrivacy checklist: build a tracker inventory and Article 5(3) decision table (consent vs exemptions). - [ePrivacy Compliance Program | Cookies, Consent UX, Evidence, Marketing Controls (Directive 2002/58/EC)](/artifacts/eu/eprivacy-directive/compliance.md): A practical ePrivacy implementation playbook: governance, tracker inventory and Article 5(3) decision table, cookie banner and CMP design. - [ePrivacy Deadlines and Compliance Calendar | Directive Baseline, Banner Audits, Marketing Audits](/artifacts/eu/eprivacy-directive/deadlines-and-compliance-calendar.md): A practical ePrivacy calendar built around the current directive baseline and recurring controls: the 2002 directive, the 2009 cookie amendment. - [ePrivacy Directive Enforcement (Cookies + Marketing) | How Regulators Assess Cookie Banners, Consent, and Evidence](/artifacts/eu/eprivacy-directive/enforcement-and-fines.md): An advanced guide to ePrivacy Directive enforcement: who enforces national ePrivacy laws, what regulators look for in cookie banners and consent UX. - [ePrivacy Directive Penalties and Fines | What "Effective, Proportionate, Dissuassive" Means + Risk Reduction Controls](/artifacts/eu/eprivacy-directive/penalties-and-fines.md): Understand penalties and fine exposure under national laws implementing the ePrivacy Directive (Directive 2002/58/EC). - [ePrivacy Directive vs GDPR | Which Law Applies to Cookies, Tracking, Communications Metadata, and Marketing?](/artifacts/eu/eprivacy-directive/eprivacy-directive-vs-gdpr.md): A practical, source-grounded split between the ePrivacy Directive and GDPR: ePrivacy for placement/reading on devices and communications confidentiality. - [ePrivacy FAQ (Directive 2002/58/EC) | Cookies, Consent Exemptions, Cookie Walls, Marketing, Enforcement](/artifacts/eu/eprivacy-directive/faq.md): High-signal ePrivacy answers: when cookies/SDKs need consent (Article 5(3)), what counts as strictly necessary (WP29 WP194). - [ePrivacy vs GDPR (Cookie Stack Blueprint) | Align Consent UX, Tag Firing, Processing Purposes, and Evidence](/artifacts/eu/eprivacy-directive/eprivacy-vs-gdpr.md): A combined ePrivacy + GDPR implementation blueprint for cookies, tracking, and marketing. - [EU Cookie Banner Requirements | ePrivacy Directive + GDPR Consent (EDPB) | UX Patterns + Test Cases](/artifacts/eu/eprivacy-directive/eu-cookie-banner-requirements.md): A practical cookie banner and CMP requirements guide: acceptance/reject parity, granularity, clear purposes, vendor transparency, no pre-ticked boxes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/eprivacy-directive/requirements --- --- title: "ESPR Applicability Test (Regulation (EU) 2024/1781)" canonical_url: "https://www.sorena.io/artifacts/eu/espr/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/espr/applicability-test" author: "Sorena AI" description: "A practical applicability test for the EU Ecodesign for Sustainable Products Regulation." keywords: - "ESPR applicability test" - "is ESPR applicable" - "ESPR scope" - "Regulation (EU) 2024/1781 scope" - "ESPR delegated acts scope" - "digital product passport scope" - "ESPR" - "applicability test" - "delegated acts" - "DPP" - "scope" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR Applicability Test (Regulation (EU) 2024/1781) A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. *Applicability Test* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Applicability Test Decide whether ESPR belongs on your active product roadmap and what should be built before product-specific rules land. Use Article 1 scope, Article 18 priorities, current delegated-act timing, and DPP dependencies to turn a legal screen into an implementation plan. ESPR applicability is not a single yes or no answer. The regulation applies as a framework to almost all physical products, but the operational duties that determine what you must build arrive through Article 4 delegated acts. A useful applicability test therefore does four things: it screens Article 1 exclusions, maps your economic-operator role, checks whether legacy ecodesign rules already apply to the product, and ranks the product family against the 2025 to 2030 working-plan priorities and DPP dependencies. ## Step 1: Screen the legal perimeter before you do any detailed work Start with Article 1, not with a marketing category. ESPR is broad, but it is not universal. The fastest way to avoid wasted work is to remove excluded products and identify products still governed by older implementing measures. - Article 1 scope is broad and covers almost all physical goods placed on the EU market or put into service. - Article 1 exclusions include food and feed, living plants, animals and microorganisms, products of human origin, medicinal products, veterinary medicinal products, and certain vehicles already regulated under separate Union vehicle law. - Products whose sole purpose is defence or national security are excluded from product groups under Article 5(5). - Existing ecodesign implementing measures adopted under Directive 2009/125/EC continue to apply until they are repealed or declared obsolete, so some energy-related products remain on a carry-over compliance path. ## Step 2: Map the operator role that will own the evidence ESPR duties attach to real operators placing products on the market, importing them, distributing them, or handling fulfilment. That role mapping decides who must hold the technical file, who must upload registry data, and who needs supplier evidence on hand. If your company uses multiple go-to-market models, do the mapping per product family and market. - Manufacturer route: strongest control over design choices, conformity evidence, DPP creation, and product-data quality. - Importer route: must obtain and verify upstream evidence before the product is placed on the EU market. - Distributor and dealer route: must manage disclosure consistency and react to non-compliance signals, recalls, or corrective actions. - Fulfilment-service route: warehousing and dispatch cannot jeopardise compliance for products covered by a delegated act. ## Step 3: Rank urgency against Article 18 priorities and the first working plan A product can be inside the ESPR framework even when no delegated act exists yet. The next question is whether it is an early priority or a later wave. Use both the regulation and the adopted 2025 to 2030 working plan to decide whether the product family belongs on a live watchlist. - Article 18 required the first working plan to prioritise iron and steel, aluminium, textiles with a focus on garments and footwear, furniture including mattresses, tyres, detergents, paints, lubricants, and chemicals. - The Commission adopted the first ESPR and Energy Labelling Working Plan on 16 April 2025. - The first Article 4 delegated act cannot enter into force before 19 July 2025. - If your product family overlaps those priority groups or depends on the same data architecture, treat ESPR as active program work now. ## Step 4: Decide whether DPP readiness is a dependency or the main workstream A DPP is not required for every product today, but DPP capability is the shared infrastructure for many ESPR measures and connected regulations. Applicability therefore includes a data and architecture assessment, not just a scope memo. - Check whether the future product family is likely to need a DPP or another digital information route under a delegated act. - Assess identifier consistency across PLM, ERP, supplier systems, product pages, QR carriers, and future registry uploads. - Assess whether you can publish accurate, complete, and up-to-date product information at model, batch, or item level. - Assess whether the same evidence pack could support market surveillance, customs checks, customer due diligence, and internal product governance. ## Outputs: what a finished ESPR applicability test should produce The output should be operational. If the result is only a legal sentence, the work is incomplete. Your final output should tell engineering, product, supply chain, and legal teams what to do next. - Product-family map with Article 1 exclusions, role mapping, and legacy-rule status. - Working-plan watchlist with confidence level, owner, and next regulatory signal to monitor. - DPP and disclosure readiness gap list, including identifiers, data quality, and supplier dependencies. - Initial evidence index showing what can already be proven and what still needs to be built. *Recommended next step* *Placement: after the applicability result* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Applicability Test across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Applicability Test](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Applicability Test and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Applicability Test. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Article 1 scope, Article 5 exclusions, Article 18 priorities, and the delegated-act timing floor. - [European Commission: Ecodesign for Sustainable Products Regulation overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/sustainable-products/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Official implementation overview and current Commission guidance page. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official Commission communication adopted on 16 April 2025. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/applicability-test --- --- title: "ESPR Applicability Test (Regulation (EU) 2024/1781)" canonical_url: "https://www.sorena.io/artifacts/eu/espr/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/espr/applicability-test" author: "Sorena AI" description: "A practical applicability test for the EU Ecodesign for Sustainable Products Regulation." keywords: - "ESPR applicability test" - "is ESPR applicable" - "ESPR scope" - "Regulation (EU) 2024/1781 scope" - "ESPR delegated acts scope" - "digital product passport scope" - "ESPR" - "applicability test" - "delegated acts" - "DPP" - "scope" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR Applicability Test (Regulation (EU) 2024/1781) A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. *Applicability Test* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Applicability Test Decide whether ESPR belongs on your active product roadmap and what should be built before product-specific rules land. Use Article 1 scope, Article 18 priorities, current delegated-act timing, and DPP dependencies to turn a legal screen into an implementation plan. ESPR applicability is not a single yes or no answer. The regulation applies as a framework to almost all physical products, but the operational duties that determine what you must build arrive through Article 4 delegated acts. A useful applicability test therefore does four things: it screens Article 1 exclusions, maps your economic-operator role, checks whether legacy ecodesign rules already apply to the product, and ranks the product family against the 2025 to 2030 working-plan priorities and DPP dependencies. ## Step 1: Screen the legal perimeter before you do any detailed work Start with Article 1, not with a marketing category. ESPR is broad, but it is not universal. The fastest way to avoid wasted work is to remove excluded products and identify products still governed by older implementing measures. - Article 1 scope is broad and covers almost all physical goods placed on the EU market or put into service. - Article 1 exclusions include food and feed, living plants, animals and microorganisms, products of human origin, medicinal products, veterinary medicinal products, and certain vehicles already regulated under separate Union vehicle law. - Products whose sole purpose is defence or national security are excluded from product groups under Article 5(5). - Existing ecodesign implementing measures adopted under Directive 2009/125/EC continue to apply until they are repealed or declared obsolete, so some energy-related products remain on a carry-over compliance path. ## Step 2: Map the operator role that will own the evidence ESPR duties attach to real operators placing products on the market, importing them, distributing them, or handling fulfilment. That role mapping decides who must hold the technical file, who must upload registry data, and who needs supplier evidence on hand. If your company uses multiple go-to-market models, do the mapping per product family and market. - Manufacturer route: strongest control over design choices, conformity evidence, DPP creation, and product-data quality. - Importer route: must obtain and verify upstream evidence before the product is placed on the EU market. - Distributor and dealer route: must manage disclosure consistency and react to non-compliance signals, recalls, or corrective actions. - Fulfilment-service route: warehousing and dispatch cannot jeopardise compliance for products covered by a delegated act. ## Step 3: Rank urgency against Article 18 priorities and the first working plan A product can be inside the ESPR framework even when no delegated act exists yet. The next question is whether it is an early priority or a later wave. Use both the regulation and the adopted 2025 to 2030 working plan to decide whether the product family belongs on a live watchlist. - Article 18 required the first working plan to prioritise iron and steel, aluminium, textiles with a focus on garments and footwear, furniture including mattresses, tyres, detergents, paints, lubricants, and chemicals. - The Commission adopted the first ESPR and Energy Labelling Working Plan on 16 April 2025. - The first Article 4 delegated act cannot enter into force before 19 July 2025. - If your product family overlaps those priority groups or depends on the same data architecture, treat ESPR as active program work now. ## Step 4: Decide whether DPP readiness is a dependency or the main workstream A DPP is not required for every product today, but DPP capability is the shared infrastructure for many ESPR measures and connected regulations. Applicability therefore includes a data and architecture assessment, not just a scope memo. - Check whether the future product family is likely to need a DPP or another digital information route under a delegated act. - Assess identifier consistency across PLM, ERP, supplier systems, product pages, QR carriers, and future registry uploads. - Assess whether you can publish accurate, complete, and up-to-date product information at model, batch, or item level. - Assess whether the same evidence pack could support market surveillance, customs checks, customer due diligence, and internal product governance. ## Outputs: what a finished ESPR applicability test should produce The output should be operational. If the result is only a legal sentence, the work is incomplete. Your final output should tell engineering, product, supply chain, and legal teams what to do next. - Product-family map with Article 1 exclusions, role mapping, and legacy-rule status. - Working-plan watchlist with confidence level, owner, and next regulatory signal to monitor. - DPP and disclosure readiness gap list, including identifiers, data quality, and supplier dependencies. - Initial evidence index showing what can already be proven and what still needs to be built. *Recommended next step* *Placement: after the applicability result* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Applicability Test across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Applicability Test](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Applicability Test and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Applicability Test. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Article 1 scope, Article 5 exclusions, Article 18 priorities, and the delegated-act timing floor. - [European Commission: Ecodesign for Sustainable Products Regulation overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/sustainable-products/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Official implementation overview and current Commission guidance page. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official Commission communication adopted on 16 April 2025. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/applicability-test --- --- title: "EU ESPR Checklist (Regulation (EU) 2024/1781)" canonical_url: "https://www.sorena.io/artifacts/eu/espr/checklist" source_url: "https://www.sorena.io/artifacts/eu/espr/checklist" author: "Sorena AI" description: "An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring." keywords: - "ESPR checklist" - "ESPR compliance checklist" - "Regulation (EU) 2024/1781 checklist" - "digital product passport checklist" - "DPP readiness checklist" - "ESPR delegated acts tracker" - "ESPR requirements checklist" - "Digital Product Passport" - "delegated acts" - "information requirements" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU ESPR Checklist (Regulation (EU) 2024/1781) An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. *Checklist* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Checklist Use this checklist to convert ESPR into named owners, live controls, and evidence you can actually export. The checklist is built around the framework duties that already exist before your product-specific delegated act is final. ESPR compliance is not a single launch event. The checklist that works is the one that covers framework obligations that already exist today, plus the controls needed to absorb future delegated acts with minimal reinvention. Use this page as a program checklist for scope, watchlist governance, DPP architecture, supplier evidence, unsold-products reporting, and enforcement readiness. ## 1) Scope and carry-over rules Start by confirming what belongs inside the ESPR program and what stays outside it. This is where many teams either overbuild or miss legacy obligations. - Screen Article 1 exclusions and document the reason for every excluded product family. - Check whether the product is still governed by an older ecodesign implementing measure carried over from Directive 2009/125/EC. - Map manufacturer, importer, distributor, dealer, and fulfilment roles per product family. - Assign one accountable owner for conformity evidence and one for DPP or disclosure operations. ## 2) Delegated-acts watchlist and working-plan control The watchlist is the control that turns ESPR from passive monitoring into active delivery. Without it, the program will always start too late. - Track Article 18 priority groups and the 2025 to 2030 working-plan items relevant to your portfolio. - Log every consultation, preparatory study, Ecodesign Forum signal, and adopted delegated act with an internal owner. - Record the earliest possible entry-into-force date and the planned application lag for each item. - Review the watchlist monthly and force an engineering impact assessment for every status change. ## 3) DPP and disclosure readiness Article 9 to Article 14 create the backbone for future DPP delivery. Even before your product group measure lands, the architecture can be prepared. Treat DPP as a governed service, not a static file. - Define the information model, provenance rules, versioning logic, and retention expectations. - Choose and govern unique identifiers and data carriers across product, packaging, documentation, and registry flows. - Plan audience-specific access rights for customers, repairers, authorities, and business users. - Prepare for the EU DPP registry and public web-portal model due by 19 July 2026. ## 4) Information requirements, labels, and evidence Article 7 and Article 16 make product information a compliance surface. Claims, labels, and DPP data must stay aligned. Do not let marketing or ecommerce introduce parallel truth sets. - Create a disclosure library that maps every claim to an owner, evidence source, and verification rule. - Document how label content, QR placement, and online presentation will be controlled if a delegated act requires a label. - Track substances-of-concern information where relevant and ensure traceability across the product life cycle. - Keep historical versions of DPP and label content so you can reproduce what was shown for a given product version. ## 5) Unsold-products controls ESPR is not only about performance and information requirements. Chapter VI creates separate duties around unsold consumer products. These duties need their own data owners and year-end workflow. - Decide whether the business discards unsold consumer products directly or through third parties. - Prepare annual website disclosure of numbers, weight, reasons, and prevention measures under Article 24. - Account for Implementing Regulation (EU) 2026/2, which applies from 2 March 2027. - If the business handles apparel, clothing accessories, or footwear, prepare for the prohibition and derogation rules applying from 19 July 2026. ## 6) Market-surveillance and response readiness The cleanest compliance program still needs a response plan. ESPR enforcement will test whether your evidence can be reproduced fast. Build that response capability before you need it. - Set an evidence-export SLA for a product model, batch, or item. - Keep a release log tying the product version to the applicable delegated act, DPP version, and supporting records. - Define a corrective-action workflow for non-compliance findings, withdrawals, or authority requests. - Review penalty exposure at Member State level and track public-procurement consequences where relevant. *Recommended next step* *Placement: after the checklist block* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Checklist across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Checklist](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Checklist and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Checklist. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Articles 1, 7, 9 to 18, 23 to 25, and 74. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official Commission communication that helps prioritise portfolio work. - [Commission Implementing Regulation (EU) 2026/2](https://eur-lex.europa.eu/eli/reg_impl/2026/2/oj?ref=sorena.io) - Official disclosure format for discarded unsold consumer products, applying from 2 March 2027. - [European Commission: New EU rules to stop destruction of unsold clothes and shoes](https://environment.ec.europa.eu/news/new-eu-rules-stop-destruction-unsold-clothes-and-shoes-2026-02-09_en?ref=sorena.io) - Official Commission summary of the unsold-products delegated and implementing acts adopted on 9 February 2026. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/checklist --- --- title: "EU ESPR Checklist (Regulation (EU) 2024/1781)" canonical_url: "https://www.sorena.io/artifacts/eu/espr/checklist" source_url: "https://www.sorena.io/artifacts/eu/espr/checklist" author: "Sorena AI" description: "An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring." keywords: - "ESPR checklist" - "ESPR compliance checklist" - "Regulation (EU) 2024/1781 checklist" - "digital product passport checklist" - "DPP readiness checklist" - "ESPR delegated acts tracker" - "ESPR requirements checklist" - "Digital Product Passport" - "delegated acts" - "information requirements" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU ESPR Checklist (Regulation (EU) 2024/1781) An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. *Checklist* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Checklist Use this checklist to convert ESPR into named owners, live controls, and evidence you can actually export. The checklist is built around the framework duties that already exist before your product-specific delegated act is final. ESPR compliance is not a single launch event. The checklist that works is the one that covers framework obligations that already exist today, plus the controls needed to absorb future delegated acts with minimal reinvention. Use this page as a program checklist for scope, watchlist governance, DPP architecture, supplier evidence, unsold-products reporting, and enforcement readiness. ## 1) Scope and carry-over rules Start by confirming what belongs inside the ESPR program and what stays outside it. This is where many teams either overbuild or miss legacy obligations. - Screen Article 1 exclusions and document the reason for every excluded product family. - Check whether the product is still governed by an older ecodesign implementing measure carried over from Directive 2009/125/EC. - Map manufacturer, importer, distributor, dealer, and fulfilment roles per product family. - Assign one accountable owner for conformity evidence and one for DPP or disclosure operations. ## 2) Delegated-acts watchlist and working-plan control The watchlist is the control that turns ESPR from passive monitoring into active delivery. Without it, the program will always start too late. - Track Article 18 priority groups and the 2025 to 2030 working-plan items relevant to your portfolio. - Log every consultation, preparatory study, Ecodesign Forum signal, and adopted delegated act with an internal owner. - Record the earliest possible entry-into-force date and the planned application lag for each item. - Review the watchlist monthly and force an engineering impact assessment for every status change. ## 3) DPP and disclosure readiness Article 9 to Article 14 create the backbone for future DPP delivery. Even before your product group measure lands, the architecture can be prepared. Treat DPP as a governed service, not a static file. - Define the information model, provenance rules, versioning logic, and retention expectations. - Choose and govern unique identifiers and data carriers across product, packaging, documentation, and registry flows. - Plan audience-specific access rights for customers, repairers, authorities, and business users. - Prepare for the EU DPP registry and public web-portal model due by 19 July 2026. ## 4) Information requirements, labels, and evidence Article 7 and Article 16 make product information a compliance surface. Claims, labels, and DPP data must stay aligned. Do not let marketing or ecommerce introduce parallel truth sets. - Create a disclosure library that maps every claim to an owner, evidence source, and verification rule. - Document how label content, QR placement, and online presentation will be controlled if a delegated act requires a label. - Track substances-of-concern information where relevant and ensure traceability across the product life cycle. - Keep historical versions of DPP and label content so you can reproduce what was shown for a given product version. ## 5) Unsold-products controls ESPR is not only about performance and information requirements. Chapter VI creates separate duties around unsold consumer products. These duties need their own data owners and year-end workflow. - Decide whether the business discards unsold consumer products directly or through third parties. - Prepare annual website disclosure of numbers, weight, reasons, and prevention measures under Article 24. - Account for Implementing Regulation (EU) 2026/2, which applies from 2 March 2027. - If the business handles apparel, clothing accessories, or footwear, prepare for the prohibition and derogation rules applying from 19 July 2026. ## 6) Market-surveillance and response readiness The cleanest compliance program still needs a response plan. ESPR enforcement will test whether your evidence can be reproduced fast. Build that response capability before you need it. - Set an evidence-export SLA for a product model, batch, or item. - Keep a release log tying the product version to the applicable delegated act, DPP version, and supporting records. - Define a corrective-action workflow for non-compliance findings, withdrawals, or authority requests. - Review penalty exposure at Member State level and track public-procurement consequences where relevant. *Recommended next step* *Placement: after the checklist block* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Checklist across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Checklist](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Checklist and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Checklist. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Articles 1, 7, 9 to 18, 23 to 25, and 74. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official Commission communication that helps prioritise portfolio work. - [Commission Implementing Regulation (EU) 2026/2](https://eur-lex.europa.eu/eli/reg_impl/2026/2/oj?ref=sorena.io) - Official disclosure format for discarded unsold consumer products, applying from 2 March 2027. - [European Commission: New EU rules to stop destruction of unsold clothes and shoes](https://environment.ec.europa.eu/news/new-eu-rules-stop-destruction-unsold-clothes-and-shoes-2026-02-09_en?ref=sorena.io) - Official Commission summary of the unsold-products delegated and implementing acts adopted on 9 February 2026. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/checklist --- --- title: "ESPR Compliance Program Operating Model" canonical_url: "https://www.sorena.io/artifacts/eu/espr/compliance-program-operating-model" source_url: "https://www.sorena.io/artifacts/eu/espr/compliance-program-operating-model" author: "Sorena AI" description: "Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance." keywords: - "ESPR operating model" - "ESPR compliance program" - "delegated acts intake process" - "digital product passport governance" - "DPP data governance" - "ESPR RACI" - "operating model" - "ESPR governance" - "delegated acts" - "DPP governance" - "evidence exports" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR Compliance Program Operating Model Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. *Operating Model* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Program Operating Model An ESPR operating model is a release process for regulatory change, product data, and evidence. Design the program around the framework duties that already exist, not around a single future delegated act. ESPR programs break when responsibility is split across policy, product, data, supply chain, and compliance with no single delivery rhythm. The operating model that works has one intake path for regulatory signals, one design path for DPP and disclosure changes, and one evidence path that can answer market-surveillance or customs questions without a war room. ## Core principle: one intake path for every ESPR signal Every working-plan update, preparatory study, consultation, or adopted delegated act should enter the program the same way. That intake path is what stops the program from becoming ad hoc. - Single backlog item per regulatory signal with product-family mapping and owner assignment. - Mandatory legal and engineering impact summary before prioritisation. - Shared date fields for entry into force, expected application, and internal release milestones. - Escalation rule for any signal affecting an Article 18 priority group or a product already sold in the EU. ## RACI: minimum owner set that keeps ESPR executable Do not make every function jointly accountable. Shared accountability is usually another name for drift. Assign one decision owner per workstream and keep the interfaces explicit. - Policy or legal owner: owns the watchlist, primary-source interpretation, and trigger for impact review. - Product owner: owns scope mapping, release timing, and product-family prioritisation. - Data or platform owner: owns the DPP information model, identifiers, validation, registry integration, and access controls. - Supply-chain owner: owns supplier onboarding, evidence intake, remediation plans, and update cadence. - Assurance owner: owns conformity records, test evidence, export packs, and response to authority inquiries. ## Cadence: the minimum governance rhythm that works ESPR needs more than an annual legal review and less than a daily steering committee. The right cadence is steady and boring. Make the operating rhythm visible on the calendar and treat it like a product release cycle. - Weekly watchlist maintenance for signals, consultations, and source updates. - Monthly impact and prioritisation review across policy, product, data, and supply chain owners. - Quarterly architecture review for DPP, identifiers, access rights, and evidence exports. - Annual unsold-products disclosure cycle aligned to Article 24 and the Implementing Regulation (EU) 2026/2 format. ## Program artifacts that should exist before the first delegated act hits your product The operating model should produce tangible artifacts, not just meetings and slide decks. If a new delegated act landed tomorrow, these artifacts are what would let you move quickly. - Portfolio scope map and carry-over rules register. - Delegated-acts watchlist with working-plan references and internal milestones. - DPP data dictionary, identifier policy, and audience-access matrix. - Disclosure library tied to evidence, approval, and version history. - Evidence export specification for model, batch, and item investigations. *Recommended next step* *Placement: after the compliance steps* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Program Operating Model across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Program Operating Model from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Program Operating Model](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Program Operating Model and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Program Operating Model. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for the framework duties that shape the operating model. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official prioritisation and planning anchor for governance cadence. - [CEN-CENELEC CWA 18186:2025](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Useful implementation guidance for DPP governance, architecture, and accessibility. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/compliance-program-operating-model --- --- title: "ESPR Compliance Program Operating Model" canonical_url: "https://www.sorena.io/artifacts/eu/espr/compliance-program-operating-model" source_url: "https://www.sorena.io/artifacts/eu/espr/compliance-program-operating-model" author: "Sorena AI" description: "Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance." keywords: - "ESPR operating model" - "ESPR compliance program" - "delegated acts intake process" - "digital product passport governance" - "DPP data governance" - "ESPR RACI" - "operating model" - "ESPR governance" - "delegated acts" - "DPP governance" - "evidence exports" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR Compliance Program Operating Model Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. *Operating Model* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Program Operating Model An ESPR operating model is a release process for regulatory change, product data, and evidence. Design the program around the framework duties that already exist, not around a single future delegated act. ESPR programs break when responsibility is split across policy, product, data, supply chain, and compliance with no single delivery rhythm. The operating model that works has one intake path for regulatory signals, one design path for DPP and disclosure changes, and one evidence path that can answer market-surveillance or customs questions without a war room. ## Core principle: one intake path for every ESPR signal Every working-plan update, preparatory study, consultation, or adopted delegated act should enter the program the same way. That intake path is what stops the program from becoming ad hoc. - Single backlog item per regulatory signal with product-family mapping and owner assignment. - Mandatory legal and engineering impact summary before prioritisation. - Shared date fields for entry into force, expected application, and internal release milestones. - Escalation rule for any signal affecting an Article 18 priority group or a product already sold in the EU. ## RACI: minimum owner set that keeps ESPR executable Do not make every function jointly accountable. Shared accountability is usually another name for drift. Assign one decision owner per workstream and keep the interfaces explicit. - Policy or legal owner: owns the watchlist, primary-source interpretation, and trigger for impact review. - Product owner: owns scope mapping, release timing, and product-family prioritisation. - Data or platform owner: owns the DPP information model, identifiers, validation, registry integration, and access controls. - Supply-chain owner: owns supplier onboarding, evidence intake, remediation plans, and update cadence. - Assurance owner: owns conformity records, test evidence, export packs, and response to authority inquiries. ## Cadence: the minimum governance rhythm that works ESPR needs more than an annual legal review and less than a daily steering committee. The right cadence is steady and boring. Make the operating rhythm visible on the calendar and treat it like a product release cycle. - Weekly watchlist maintenance for signals, consultations, and source updates. - Monthly impact and prioritisation review across policy, product, data, and supply chain owners. - Quarterly architecture review for DPP, identifiers, access rights, and evidence exports. - Annual unsold-products disclosure cycle aligned to Article 24 and the Implementing Regulation (EU) 2026/2 format. ## Program artifacts that should exist before the first delegated act hits your product The operating model should produce tangible artifacts, not just meetings and slide decks. If a new delegated act landed tomorrow, these artifacts are what would let you move quickly. - Portfolio scope map and carry-over rules register. - Delegated-acts watchlist with working-plan references and internal milestones. - DPP data dictionary, identifier policy, and audience-access matrix. - Disclosure library tied to evidence, approval, and version history. - Evidence export specification for model, batch, and item investigations. *Recommended next step* *Placement: after the compliance steps* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Program Operating Model across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Program Operating Model from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Program Operating Model](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Program Operating Model and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Program Operating Model. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for the framework duties that shape the operating model. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official prioritisation and planning anchor for governance cadence. - [CEN-CENELEC CWA 18186:2025](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Useful implementation guidance for DPP governance, architecture, and accessibility. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/compliance-program-operating-model --- --- title: "EU ESPR Compliance Guide (Regulation (EU) 2024/1781)" canonical_url: "https://www.sorena.io/artifacts/eu/espr/compliance" source_url: "https://www.sorena.io/artifacts/eu/espr/compliance" author: "Sorena AI" description: "An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification." keywords: - "ESPR compliance" - "Regulation (EU) 2024/1781 compliance" - "ESPR implementation guide" - "ESPR compliance program" - "digital product passport compliance" - "DPP implementation" - "delegated acts" - "DPP" - "program operating model" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU ESPR Compliance Guide (Regulation (EU) 2024/1781) An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. *Compliance Playbook* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Compliance Build ESPR as a repeatable compliance pipeline, not as one project per product group. The framework already gives you enough to build the operating system before product-specific measures are final. The most reliable ESPR program is built around repeatable framework controls. Scope products correctly, monitor delegated acts continuously, design DPP and disclosure infrastructure once, control supplier evidence, and maintain a response pack for authorities. That approach works whether the next pressure point is a delegated act, an unsold-products disclosure cycle, or a customs check after the registry is operational. ## Program structure: the five workstreams that must stay connected ESPR creates cross-functional duties. The workstream split is useful only if the handoffs are explicit. A mature program makes those handoffs visible. - Scope and legal watchlist. - Product and engineering delivery. - DPP and disclosure architecture. - Supplier evidence and verification. - Unsold-products reporting and enforcement response. ## Delegated-act delivery pipeline Treat an Article 4 delegated act the way a software team treats a release branch. It needs scoping, design, testing, and versioned evidence. That discipline is what makes later product-group waves cheaper. - Map the delegated act to product families, markets, and economic-operator roles. - Extract performance requirements, information requirements, conformity route, and transition dates from Article 8 elements. - Update the DPP information model, label logic, and supplier-data requirements. - Run release verification and export evidence tied to the affected model, batch, or item. ## DPP capability: what must be true before you call it ready Article 9 and Article 10 set a high bar. The passport data must be accurate, complete, and up to date, and the architecture has to survive operator change and access-right rules. A QR code leading to an uncontrolled page is not ESPR readiness. - Identifier strategy is stable across internal systems and external product information. - Access rights are defined for customers, authorities, repairers, business users, and internal operators. - Changes are versioned, attributable, and reproducible. - Registry upload, public-web-portal expectations, and customs handoff are part of the design, not an afterthought. ## Supplier evidence and unsold-products data are the common bottlenecks In practice, delayed supplier data and weak year-end reporting are what create operational pain. Solve those bottlenecks centrally so each delegated act does not rebuild the same process. - Create a supplier minimum dataset and verification rules for sustainability attributes. - Create an unsold-products dataset for number, weight, reasons, and prevention measures. - Use one evidence taxonomy so both product claims and unsold-products disclosures point back to controlled records. - Set remediation deadlines and exceptions for missing or disputed upstream data. ## Evidence and response readiness You should be able to answer three questions quickly: what rule applied, what did we publish, and what evidence supported it. Everything else is a derivative of that capability. - Evidence pack per product version, including source data, validation results, approvals, and published outputs. - Corrective-action workflow for authority findings or internal defect reports. - Penalty and escalation map for the Member States where the product is sold. - Response playbook for registry, market-surveillance, or customs questions once the relevant delegated act applies. *Recommended next step* *Placement: after the compliance steps* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Compliance across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Compliance](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Compliance and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Compliance. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Articles 8 to 14, 23 to 25, and 74. - [European Commission: Ecodesign for Sustainable Products Regulation overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/sustainable-products/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Official implementation overview. - [Commission Implementing Regulation (EU) 2026/2](https://eur-lex.europa.eu/eli/reg_impl/2026/2/oj?ref=sorena.io) - Official disclosure-format rule that should be built into compliance operations. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/compliance --- --- title: "EU ESPR Compliance Guide (Regulation (EU) 2024/1781)" canonical_url: "https://www.sorena.io/artifacts/eu/espr/compliance" source_url: "https://www.sorena.io/artifacts/eu/espr/compliance" author: "Sorena AI" description: "An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification." keywords: - "ESPR compliance" - "Regulation (EU) 2024/1781 compliance" - "ESPR implementation guide" - "ESPR compliance program" - "digital product passport compliance" - "DPP implementation" - "delegated acts" - "DPP" - "program operating model" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU ESPR Compliance Guide (Regulation (EU) 2024/1781) An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. *Compliance Playbook* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Compliance Build ESPR as a repeatable compliance pipeline, not as one project per product group. The framework already gives you enough to build the operating system before product-specific measures are final. The most reliable ESPR program is built around repeatable framework controls. Scope products correctly, monitor delegated acts continuously, design DPP and disclosure infrastructure once, control supplier evidence, and maintain a response pack for authorities. That approach works whether the next pressure point is a delegated act, an unsold-products disclosure cycle, or a customs check after the registry is operational. ## Program structure: the five workstreams that must stay connected ESPR creates cross-functional duties. The workstream split is useful only if the handoffs are explicit. A mature program makes those handoffs visible. - Scope and legal watchlist. - Product and engineering delivery. - DPP and disclosure architecture. - Supplier evidence and verification. - Unsold-products reporting and enforcement response. ## Delegated-act delivery pipeline Treat an Article 4 delegated act the way a software team treats a release branch. It needs scoping, design, testing, and versioned evidence. That discipline is what makes later product-group waves cheaper. - Map the delegated act to product families, markets, and economic-operator roles. - Extract performance requirements, information requirements, conformity route, and transition dates from Article 8 elements. - Update the DPP information model, label logic, and supplier-data requirements. - Run release verification and export evidence tied to the affected model, batch, or item. ## DPP capability: what must be true before you call it ready Article 9 and Article 10 set a high bar. The passport data must be accurate, complete, and up to date, and the architecture has to survive operator change and access-right rules. A QR code leading to an uncontrolled page is not ESPR readiness. - Identifier strategy is stable across internal systems and external product information. - Access rights are defined for customers, authorities, repairers, business users, and internal operators. - Changes are versioned, attributable, and reproducible. - Registry upload, public-web-portal expectations, and customs handoff are part of the design, not an afterthought. ## Supplier evidence and unsold-products data are the common bottlenecks In practice, delayed supplier data and weak year-end reporting are what create operational pain. Solve those bottlenecks centrally so each delegated act does not rebuild the same process. - Create a supplier minimum dataset and verification rules for sustainability attributes. - Create an unsold-products dataset for number, weight, reasons, and prevention measures. - Use one evidence taxonomy so both product claims and unsold-products disclosures point back to controlled records. - Set remediation deadlines and exceptions for missing or disputed upstream data. ## Evidence and response readiness You should be able to answer three questions quickly: what rule applied, what did we publish, and what evidence supported it. Everything else is a derivative of that capability. - Evidence pack per product version, including source data, validation results, approvals, and published outputs. - Corrective-action workflow for authority findings or internal defect reports. - Penalty and escalation map for the Member States where the product is sold. - Response playbook for registry, market-surveillance, or customs questions once the relevant delegated act applies. *Recommended next step* *Placement: after the compliance steps* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Compliance across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Compliance](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Compliance and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Compliance. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Articles 8 to 14, 23 to 25, and 74. - [European Commission: Ecodesign for Sustainable Products Regulation overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/sustainable-products/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Official implementation overview. - [Commission Implementing Regulation (EU) 2026/2](https://eur-lex.europa.eu/eli/reg_impl/2026/2/oj?ref=sorena.io) - Official disclosure-format rule that should be built into compliance operations. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/compliance --- --- title: "EU ESPR Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/espr/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/espr/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024." keywords: - "ESPR deadlines" - "ESPR compliance calendar" - "Regulation (EU) 2024/1781 timeline" - "ESPR delegated acts timeline" - "digital product passport timeline" - "DPP implementation timeline" - "deadlines" - "compliance calendar" - "delegated acts" - "DPP milestones" - "supplier onboarding" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU ESPR Deadlines and Compliance Calendar A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. *Calendar* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Deadlines and Compliance Calendar A planning calendar for delegated acts, DPP readiness, registry readiness, unsold-products compliance, and evidence delivery. Use fixed ESPR milestones as anchors, then add internal delivery gates for each product group and disclosure stream. ESPR has more fixed dates than many teams realise. The framework still depends on delegated acts, but the regulation and the Commission implementation program already set enough milestones to drive real planning: entry into force, the first working plan, the delegated-act timing floor, the DPP registry deadline, the unsold-products prohibition date, and the first disclosure-format application date. Use those anchors to build a delivery calendar for product, data, supply chain, and reporting teams. ## Known legal and implementation milestones These dates are already fixed by law or by adopted Commission measures. They belong in your central regulatory calendar now. They are the baseline dates for board reporting, budget planning, and internal dependency management. - 28 June 2024, Regulation (EU) 2024/1781 was published in the Official Journal. - 18 July 2024, ESPR entered into force. - 16 April 2025, the Commission adopted the first ESPR and Energy Labelling Working Plan 2025-2030. - 19 July 2025, the first Article 4 delegated act may enter into force, but not earlier. - 9 April 2025, the Commission launched the DPP consultation on service-provider and implementation design questions. - 1 July 2025, the DPP consultation closed. - 9 February 2026, the Commission adopted the unsold-products delegated and implementing acts. - 19 July 2026, the EU DPP registry must be set up and the prohibition on destroying Annex VII unsold consumer products starts to apply. - 2 March 2027, Implementing Regulation (EU) 2026/2 starts to apply for disclosure-format reporting on discarded unsold consumer products. - 19 July 2030, the Commission must evaluate the regulation. *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Deadlines and Compliance Calendar across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Deadlines and Compliance Calendar](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Deadlines and Compliance Calendar and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Deadlines and Compliance Calendar. ## Suggested milestone set for each delegated act Use one internal milestone model for every product-group measure. Consistency matters more than complexity. The point is to connect external law to internal build, verify, and publish dates. - M1, portfolio scope and carry-over-rule check complete. - M2, delegated-act impact brief complete and approved. - M3, DPP and disclosure design updated, including identifiers and access rights. - M4, supplier data onboarding and remediation started. - M5, implementation complete across product, data, and publication systems. - M6, verification complete, including registry-readiness and evidence-export testing. - M7, release and response pack signed off for the affected product version. ## Parallel calendar for unsold consumer products Do not hide unsold-products work inside the delegated-acts calendar. It has its own triggers, evidence, and annual reporting cycle. This stream affects logistics, finance, sustainability reporting, and legal teams as much as product teams. - Annual disclosure preparation for number, weight, reasons, and prevention measures. - Control design for derogation handling where destruction may still be permitted under the delegated act. - Website publication and sign-off workflow aligned to the first full financial year that falls under the rule. - Audit trail for stock-management decisions, donations, reuse, resale, or remanufacturing alternatives. ## Calendar template fields that make the plan auditable A good calendar is also a control register. Every date should have a source and owner. That prevents deadline drift and undocumented assumptions. - External date, legal source, and confidence level. - Affected product group or reporting stream. - Internal owner and dependent systems or suppliers. - Evidence or deliverable required by the date. - Risk notes, blockers, and fallback plan. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for entry into force, delegated-act floor, registry deadline, prohibition date, and review timing. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official Commission communication adopted on 16 April 2025. - [European Commission: Digital Product Passport consultation](https://single-market-economy.ec.europa.eu/news/commission-launches-consultation-digital-product-passport-2025-04-09_en?ref=sorena.io) - Official DPP consultation launch and deadline. - [Commission Implementing Regulation (EU) 2026/2](https://eur-lex.europa.eu/eli/reg_impl/2026/2/oj?ref=sorena.io) - Official disclosure format for discarded unsold consumer products, applying from 2 March 2027. - [European Commission: New EU rules to stop destruction of unsold clothes and shoes](https://environment.ec.europa.eu/news/new-eu-rules-stop-destruction-unsold-clothes-and-shoes-2026-02-09_en?ref=sorena.io) - Official Commission summary of the unsold-products acts adopted on 9 February 2026. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/deadlines-and-compliance-calendar --- --- title: "EU ESPR Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/espr/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/espr/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024." keywords: - "ESPR deadlines" - "ESPR compliance calendar" - "Regulation (EU) 2024/1781 timeline" - "ESPR delegated acts timeline" - "digital product passport timeline" - "DPP implementation timeline" - "deadlines" - "compliance calendar" - "delegated acts" - "DPP milestones" - "supplier onboarding" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU ESPR Deadlines and Compliance Calendar A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. *Calendar* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Deadlines and Compliance Calendar A planning calendar for delegated acts, DPP readiness, registry readiness, unsold-products compliance, and evidence delivery. Use fixed ESPR milestones as anchors, then add internal delivery gates for each product group and disclosure stream. ESPR has more fixed dates than many teams realise. The framework still depends on delegated acts, but the regulation and the Commission implementation program already set enough milestones to drive real planning: entry into force, the first working plan, the delegated-act timing floor, the DPP registry deadline, the unsold-products prohibition date, and the first disclosure-format application date. Use those anchors to build a delivery calendar for product, data, supply chain, and reporting teams. ## Known legal and implementation milestones These dates are already fixed by law or by adopted Commission measures. They belong in your central regulatory calendar now. They are the baseline dates for board reporting, budget planning, and internal dependency management. - 28 June 2024, Regulation (EU) 2024/1781 was published in the Official Journal. - 18 July 2024, ESPR entered into force. - 16 April 2025, the Commission adopted the first ESPR and Energy Labelling Working Plan 2025-2030. - 19 July 2025, the first Article 4 delegated act may enter into force, but not earlier. - 9 April 2025, the Commission launched the DPP consultation on service-provider and implementation design questions. - 1 July 2025, the DPP consultation closed. - 9 February 2026, the Commission adopted the unsold-products delegated and implementing acts. - 19 July 2026, the EU DPP registry must be set up and the prohibition on destroying Annex VII unsold consumer products starts to apply. - 2 March 2027, Implementing Regulation (EU) 2026/2 starts to apply for disclosure-format reporting on discarded unsold consumer products. - 19 July 2030, the Commission must evaluate the regulation. *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Deadlines and Compliance Calendar across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Deadlines and Compliance Calendar](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Deadlines and Compliance Calendar and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Deadlines and Compliance Calendar. ## Suggested milestone set for each delegated act Use one internal milestone model for every product-group measure. Consistency matters more than complexity. The point is to connect external law to internal build, verify, and publish dates. - M1, portfolio scope and carry-over-rule check complete. - M2, delegated-act impact brief complete and approved. - M3, DPP and disclosure design updated, including identifiers and access rights. - M4, supplier data onboarding and remediation started. - M5, implementation complete across product, data, and publication systems. - M6, verification complete, including registry-readiness and evidence-export testing. - M7, release and response pack signed off for the affected product version. ## Parallel calendar for unsold consumer products Do not hide unsold-products work inside the delegated-acts calendar. It has its own triggers, evidence, and annual reporting cycle. This stream affects logistics, finance, sustainability reporting, and legal teams as much as product teams. - Annual disclosure preparation for number, weight, reasons, and prevention measures. - Control design for derogation handling where destruction may still be permitted under the delegated act. - Website publication and sign-off workflow aligned to the first full financial year that falls under the rule. - Audit trail for stock-management decisions, donations, reuse, resale, or remanufacturing alternatives. ## Calendar template fields that make the plan auditable A good calendar is also a control register. Every date should have a source and owner. That prevents deadline drift and undocumented assumptions. - External date, legal source, and confidence level. - Affected product group or reporting stream. - Internal owner and dependent systems or suppliers. - Evidence or deliverable required by the date. - Risk notes, blockers, and fallback plan. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for entry into force, delegated-act floor, registry deadline, prohibition date, and review timing. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official Commission communication adopted on 16 April 2025. - [European Commission: Digital Product Passport consultation](https://single-market-economy.ec.europa.eu/news/commission-launches-consultation-digital-product-passport-2025-04-09_en?ref=sorena.io) - Official DPP consultation launch and deadline. - [Commission Implementing Regulation (EU) 2026/2](https://eur-lex.europa.eu/eli/reg_impl/2026/2/oj?ref=sorena.io) - Official disclosure format for discarded unsold consumer products, applying from 2 March 2027. - [European Commission: New EU rules to stop destruction of unsold clothes and shoes](https://environment.ec.europa.eu/news/new-eu-rules-stop-destruction-unsold-clothes-and-shoes-2026-02-09_en?ref=sorena.io) - Official Commission summary of the unsold-products acts adopted on 9 February 2026. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/deadlines-and-compliance-calendar --- --- title: "ESPR and Digital Product Passport (DPP) Connection" canonical_url: "https://www.sorena.io/artifacts/eu/espr/espr-and-dpp-connection" source_url: "https://www.sorena.io/artifacts/eu/espr/espr-and-dpp-connection" author: "Sorena AI" description: "Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements." keywords: - "ESPR digital product passport" - "DPP requirements" - "DPP information model" - "DPP identifiers GS1" - "DPP system architecture" - "ESPR information requirements" - "Digital Product Passport" - "identifiers" - "supplier data" - "versioning" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR and Digital Product Passport (DPP) Connection Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. *DPP Blueprint* *EU* ## EU ESPR (Regulation (EU) 2024/1781) ESPR and DPP Connection DPP under ESPR is a compliance system with identifiers, access rights, registry uploads, and lifecycle controls. Use Articles 9 to 14 to design the architecture before your product-group delegated act fixes the detailed payload. The DPP is the part of ESPR most likely to force system change. Under the regulation, products covered by a delegated act can only be placed on the market or put into service if a digital product passport is available and the data are accurate, complete, and up to date. That makes DPP an operational control surface across product data, identifiers, access rights, registry uploads, service-provider arrangements, and customs workflows. ## Article 9: what a delegated act can require your DPP to specify The product-group delegated act decides the detailed DPP payload, but the regulation already tells you the categories of design decisions you must be ready to absorb. This is why waiting for the final delegated act before doing architecture is a mistake. - The delegated act can define the information content and the level of granularity, for example model, batch, or item level. - It can specify the data carrier, its layout, and its position on the product, packaging, or accompanying documentation. - It can define who may access which data and under what rights model. - It can define how long the passport must remain available after the product is placed on the market. ## Article 10: essential DPP requirements that already exist now Article 10 is the architecture section many teams skip on first read. It already tells you the qualities the system must meet. These qualities should shape platform design and vendor selection now. - DPPs must be interoperable across technical, semantic, and organisational aspects of end-to-end communication and data transfer. - Different stakeholder groups must have free and easy access according to their delegated-act access rights. - Rights to introduce, modify, or update data must be restricted and controlled. - Passport availability must survive insolvency, liquidation, or cessation of activity for the operator that created it. ## Article 11 and Article 12: service providers, backups, identifiers, and credentials ESPR assumes that a DPP ecosystem may involve specialist service providers, backup arrangements, and credentialed access. This is not a single static website model. Those provisions matter for procurement, contracting, and resilience design. - The Commission may set requirements for DPP service providers and may establish a certification scheme for them. - The regulation contemplates backup copies of the most up-to-date DPP version held by a DPP service provider. - The Commission may adopt rules for unique identifiers and data-carrier lifecycle management. - The Commission may adopt implementing acts for issuing and verifying digital credentials for operators and other actors with access rights. ## Article 13 and Article 14: registry and customs are part of the design The registry is not optional background infrastructure. It is a legal mechanism with customs implications. If the product is intended for release for free circulation, the customs handoff has to work once the registry is operational. - By 19 July 2026 the Commission must set up a digital registry storing at least the unique identifiers and, for customs products, the commodity code. - The operator placing the product on the market or putting it into service uploads the required registry data. - The registry returns a unique registration identifier, but that identifier is not proof of legal compliance by itself. - Once the registry is operational, customs authorities can require the registration identifier and verify it against registry data. ## What a practical DPP build should include now Even before a product-group delegated act is final, you can build the stable parts of the system. That early work reduces delivery risk across multiple product families. - Canonical product and operator identifiers across PLM, ERP, supplier, and public-facing systems. - Versioned attribute model with provenance, approval workflow, and controlled updates. - Audience-specific access design and access logging. - Registry-ready export logic and customs-facing data fields where relevant. - Business-continuity and backup model that keeps the latest valid passport accessible. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) ESPR and DPP Connection across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) ESPR and DPP Connection from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) ESPR and DPP Connection](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) ESPR and DPP Connection and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) ESPR and DPP Connection. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Articles 9 to 14 governing DPP, service providers, registry, and customs use. - [European Commission: Digital Product Passport consultation](https://single-market-economy.ec.europa.eu/news/commission-launches-consultation-digital-product-passport-2025-04-09_en?ref=sorena.io) - Official Commission consultation on DPP implementation design and service-provider questions. - [CEN-CENELEC CWA 18186:2025](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Implementation guidance on DPP design choices, accessibility, and interoperability. - [GS1: Digital Product Passport standards and emerging regulations](https://www.gs1.org/standards/standards-emerging-regulations/DPP?ref=sorena.io) - Practical identifier and interoperability patterns often used in DPP implementations. ## Related Topic Guides - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/espr-and-dpp-connection --- --- title: "ESPR and Digital Product Passport (DPP) Connection" canonical_url: "https://www.sorena.io/artifacts/eu/espr/espr-and-dpp-connection" source_url: "https://www.sorena.io/artifacts/eu/espr/espr-and-dpp-connection" author: "Sorena AI" description: "Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements." keywords: - "ESPR digital product passport" - "DPP requirements" - "DPP information model" - "DPP identifiers GS1" - "DPP system architecture" - "ESPR information requirements" - "Digital Product Passport" - "identifiers" - "supplier data" - "versioning" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR and Digital Product Passport (DPP) Connection Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. *DPP Blueprint* *EU* ## EU ESPR (Regulation (EU) 2024/1781) ESPR and DPP Connection DPP under ESPR is a compliance system with identifiers, access rights, registry uploads, and lifecycle controls. Use Articles 9 to 14 to design the architecture before your product-group delegated act fixes the detailed payload. The DPP is the part of ESPR most likely to force system change. Under the regulation, products covered by a delegated act can only be placed on the market or put into service if a digital product passport is available and the data are accurate, complete, and up to date. That makes DPP an operational control surface across product data, identifiers, access rights, registry uploads, service-provider arrangements, and customs workflows. ## Article 9: what a delegated act can require your DPP to specify The product-group delegated act decides the detailed DPP payload, but the regulation already tells you the categories of design decisions you must be ready to absorb. This is why waiting for the final delegated act before doing architecture is a mistake. - The delegated act can define the information content and the level of granularity, for example model, batch, or item level. - It can specify the data carrier, its layout, and its position on the product, packaging, or accompanying documentation. - It can define who may access which data and under what rights model. - It can define how long the passport must remain available after the product is placed on the market. ## Article 10: essential DPP requirements that already exist now Article 10 is the architecture section many teams skip on first read. It already tells you the qualities the system must meet. These qualities should shape platform design and vendor selection now. - DPPs must be interoperable across technical, semantic, and organisational aspects of end-to-end communication and data transfer. - Different stakeholder groups must have free and easy access according to their delegated-act access rights. - Rights to introduce, modify, or update data must be restricted and controlled. - Passport availability must survive insolvency, liquidation, or cessation of activity for the operator that created it. ## Article 11 and Article 12: service providers, backups, identifiers, and credentials ESPR assumes that a DPP ecosystem may involve specialist service providers, backup arrangements, and credentialed access. This is not a single static website model. Those provisions matter for procurement, contracting, and resilience design. - The Commission may set requirements for DPP service providers and may establish a certification scheme for them. - The regulation contemplates backup copies of the most up-to-date DPP version held by a DPP service provider. - The Commission may adopt rules for unique identifiers and data-carrier lifecycle management. - The Commission may adopt implementing acts for issuing and verifying digital credentials for operators and other actors with access rights. ## Article 13 and Article 14: registry and customs are part of the design The registry is not optional background infrastructure. It is a legal mechanism with customs implications. If the product is intended for release for free circulation, the customs handoff has to work once the registry is operational. - By 19 July 2026 the Commission must set up a digital registry storing at least the unique identifiers and, for customs products, the commodity code. - The operator placing the product on the market or putting it into service uploads the required registry data. - The registry returns a unique registration identifier, but that identifier is not proof of legal compliance by itself. - Once the registry is operational, customs authorities can require the registration identifier and verify it against registry data. ## What a practical DPP build should include now Even before a product-group delegated act is final, you can build the stable parts of the system. That early work reduces delivery risk across multiple product families. - Canonical product and operator identifiers across PLM, ERP, supplier, and public-facing systems. - Versioned attribute model with provenance, approval workflow, and controlled updates. - Audience-specific access design and access logging. - Registry-ready export logic and customs-facing data fields where relevant. - Business-continuity and backup model that keeps the latest valid passport accessible. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) ESPR and DPP Connection across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) ESPR and DPP Connection from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) ESPR and DPP Connection](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) ESPR and DPP Connection and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) ESPR and DPP Connection. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Articles 9 to 14 governing DPP, service providers, registry, and customs use. - [European Commission: Digital Product Passport consultation](https://single-market-economy.ec.europa.eu/news/commission-launches-consultation-digital-product-passport-2025-04-09_en?ref=sorena.io) - Official Commission consultation on DPP implementation design and service-provider questions. - [CEN-CENELEC CWA 18186:2025](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Implementation guidance on DPP design choices, accessibility, and interoperability. - [GS1: Digital Product Passport standards and emerging regulations](https://www.gs1.org/standards/standards-emerging-regulations/DPP?ref=sorena.io) - Practical identifier and interoperability patterns often used in DPP implementations. ## Related Topic Guides - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/espr-and-dpp-connection --- --- title: "ESPR Delegated Acts Watchlist" canonical_url: "https://www.sorena.io/artifacts/eu/espr/espr-delegated-acts-watchlist" source_url: "https://www.sorena.io/artifacts/eu/espr/espr-delegated-acts-watchlist" author: "Sorena AI" description: "A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments." keywords: - "ESPR delegated acts watchlist" - "ESPR delegated acts tracker" - "ESPR consultations" - "Regulation (EU) 2024/1781 delegated acts" - "delegated act impact assessment template" - "delegated acts" - "watchlist" - "impact assessment" - "ESPR" - "DPP readiness" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR Delegated Acts Watchlist A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. *Template* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Delegated Acts Watchlist A watchlist turns ESPR from monitoring work into release planning. Base the watchlist on Article 18 priorities, the adopted working plan, and the DPP implementation pipeline. ESPR is a framework regulation, so your real delivery risk sits in delegated-act detection and response. A proper watchlist is more than a regulatory inbox. It is the live control that ties the Article 18 working plan, preparatory studies, Ecodesign Forum discussion, DPP implementation signals, and internal milestones to actual product families and owners. ## What to monitor first: signals with legal or delivery weight Not every news item belongs on the watchlist. Focus on the sources that change scope, timing, or architecture. The goal is to catch the signals that force action. - Article 18 working-plan updates and the official 2025 to 2030 working plan. - Preparatory studies and consultation documents for specific product groups. - Ecodesign Forum agendas and outputs, because Article 19 feeds directly into policy development. - DPP implementation consultations, registry decisions, and service-provider rules. - Related measures on labels, standards requests, and unsold-products rules where they affect the product family. ## Priority rows you should create immediately The best watchlist is not generic. It starts with rows that reflect the legal priorities already visible in the regulation and the adopted working plan. Even if a product family is not yet fully specified, it should still have a row with a confidence score. - Iron and steel. - Aluminium. - Textiles with a focus on garments and footwear. - Furniture including mattresses. - Tyres, detergents, paints, lubricants, and chemicals. - Carried-over energy-related products and horizontal measures where the working plan signals repairability or recyclability changes. ## Template fields that make the watchlist actionable A row should be detailed enough to create work and simple enough to update every week. Do not bury the delivery-critical fields. - Product family, market, and operator role. - Legal source, signal date, and status from monitoring to adopted. - Expected effect on performance requirements, information requirements, DPP, labels, and unsold-products controls. - Owner, target milestone, blocking dependencies, and evidence impact. - Confidence level and next review date. ## Impact workflow when a row changes status A watchlist without a status-triggered workflow is just record keeping. Status changes must produce action. Tie every material status change to the same impact template. - Confirm portfolio relevance and operator role. - Extract likely changes to DPP fields, labels, supplier data, and evidence requirements. - Estimate build effort and whether shared infrastructure can absorb the change. - Assign deadlines for design, implementation, verification, and release evidence. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Delegated Acts Watchlist across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Delegated Acts Watchlist from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Delegated Acts Watchlist](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Delegated Acts Watchlist and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Delegated Acts Watchlist. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Article 18 working-plan duties and Article 19 Ecodesign Forum role. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official Commission communication adopted on 16 April 2025. - [Green Forum: 2025-2030 working plan](https://green-forum.ec.europa.eu/news/2025-2030-working-plan-2025-07-11_en?ref=sorena.io) - Official Commission summary of the adopted working plan and the current product focus. - [European Commission: Digital Product Passport consultation](https://single-market-economy.ec.europa.eu/news/commission-launches-consultation-digital-product-passport-2025-04-09_en?ref=sorena.io) - Official signal for DPP implementation planning. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/espr-delegated-acts-watchlist --- --- title: "ESPR Delegated Acts Watchlist" canonical_url: "https://www.sorena.io/artifacts/eu/espr/espr-delegated-acts-watchlist" source_url: "https://www.sorena.io/artifacts/eu/espr/espr-delegated-acts-watchlist" author: "Sorena AI" description: "A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments." keywords: - "ESPR delegated acts watchlist" - "ESPR delegated acts tracker" - "ESPR consultations" - "Regulation (EU) 2024/1781 delegated acts" - "delegated act impact assessment template" - "delegated acts" - "watchlist" - "impact assessment" - "ESPR" - "DPP readiness" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR Delegated Acts Watchlist A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. *Template* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Delegated Acts Watchlist A watchlist turns ESPR from monitoring work into release planning. Base the watchlist on Article 18 priorities, the adopted working plan, and the DPP implementation pipeline. ESPR is a framework regulation, so your real delivery risk sits in delegated-act detection and response. A proper watchlist is more than a regulatory inbox. It is the live control that ties the Article 18 working plan, preparatory studies, Ecodesign Forum discussion, DPP implementation signals, and internal milestones to actual product families and owners. ## What to monitor first: signals with legal or delivery weight Not every news item belongs on the watchlist. Focus on the sources that change scope, timing, or architecture. The goal is to catch the signals that force action. - Article 18 working-plan updates and the official 2025 to 2030 working plan. - Preparatory studies and consultation documents for specific product groups. - Ecodesign Forum agendas and outputs, because Article 19 feeds directly into policy development. - DPP implementation consultations, registry decisions, and service-provider rules. - Related measures on labels, standards requests, and unsold-products rules where they affect the product family. ## Priority rows you should create immediately The best watchlist is not generic. It starts with rows that reflect the legal priorities already visible in the regulation and the adopted working plan. Even if a product family is not yet fully specified, it should still have a row with a confidence score. - Iron and steel. - Aluminium. - Textiles with a focus on garments and footwear. - Furniture including mattresses. - Tyres, detergents, paints, lubricants, and chemicals. - Carried-over energy-related products and horizontal measures where the working plan signals repairability or recyclability changes. ## Template fields that make the watchlist actionable A row should be detailed enough to create work and simple enough to update every week. Do not bury the delivery-critical fields. - Product family, market, and operator role. - Legal source, signal date, and status from monitoring to adopted. - Expected effect on performance requirements, information requirements, DPP, labels, and unsold-products controls. - Owner, target milestone, blocking dependencies, and evidence impact. - Confidence level and next review date. ## Impact workflow when a row changes status A watchlist without a status-triggered workflow is just record keeping. Status changes must produce action. Tie every material status change to the same impact template. - Confirm portfolio relevance and operator role. - Extract likely changes to DPP fields, labels, supplier data, and evidence requirements. - Estimate build effort and whether shared infrastructure can absorb the change. - Assign deadlines for design, implementation, verification, and release evidence. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Delegated Acts Watchlist across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Delegated Acts Watchlist from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Delegated Acts Watchlist](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Delegated Acts Watchlist and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Delegated Acts Watchlist. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Article 18 working-plan duties and Article 19 Ecodesign Forum role. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official Commission communication adopted on 16 April 2025. - [Green Forum: 2025-2030 working plan](https://green-forum.ec.europa.eu/news/2025-2030-working-plan-2025-07-11_en?ref=sorena.io) - Official Commission summary of the adopted working plan and the current product focus. - [European Commission: Digital Product Passport consultation](https://single-market-economy.ec.europa.eu/news/commission-launches-consultation-digital-product-passport-2025-04-09_en?ref=sorena.io) - Official signal for DPP implementation planning. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/espr-delegated-acts-watchlist --- --- title: "ESPR vs Ecodesign Directive (2009/125/EC)" canonical_url: "https://www.sorena.io/artifacts/eu/espr/espr-vs-ecodesign-directive" source_url: "https://www.sorena.io/artifacts/eu/espr/espr-vs-ecodesign-directive" author: "Sorena AI" description: "Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans." keywords: - "ESPR vs Ecodesign Directive" - "Regulation (EU) 2024/1781 vs 2009/125/EC" - "ecodesign regulation EU" - "digital product passport vs ecodesign directive" - "delegated acts ecodesign" - "ESPR" - "Ecodesign Directive" - "delegated acts" - "Digital Product Passport" - "scope" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR vs Ecodesign Directive (2009/125/EC) Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. *Comparison* *EU* ## EU ESPR vs Ecodesign Directive What Changes ESPR is not just a refreshed ecodesign directive. It is a broader product-sustainability framework with digital, enforcement, and unsold-products layers. The biggest mistake is assuming the old energy-only program model still covers what ESPR now requires. The old Ecodesign Directive and ESPR are related, but they are not the same operating model. Directive 2009/125/EC focused on energy-related products and required national transposition. ESPR is a directly applicable regulation with a much wider product perimeter, a stronger information and DPP layer, a formal working-plan mechanism, and a separate chapter on unsold consumer products. At the same time, legacy implementing measures remain relevant until they are repealed or declared obsolete. ## Scope and legal form The first difference is structural. The old regime was a directive for energy-related products. The new regime is a regulation for almost all physical products, with listed exclusions. That changes both legal analysis and operating scope. - Directive 2009/125/EC applied to energy-related products. - Regulation (EU) 2024/1781 applies to almost all physical products, subject to specific exclusions in Article 1. - As a regulation, ESPR applies directly across Member States without national transposition of the core framework. - Existing ecodesign implementing measures continue during the transition until repealed or obsolete. ## Requirement model: from energy performance to broader product sustainability The second difference is substantive. ESPR can target far more product aspects than classic energy efficiency. That expands the data and evidence burden. - Article 5 allows delegated acts to address durability, reparability, upgradeability, recycled content, remanufacturing, resource use, environmental footprint, and related product aspects where relevant. - Article 6 and Article 7 separate performance requirements from information requirements. - Horizontal measures can now span multiple product groups where the same product aspect can be improved effectively. - The compliance burden therefore moves from pure technical testing toward product, data, and lifecycle evidence. ## Digital Product Passport and registry: the biggest architecture change The old directive did not create a DPP system. ESPR does. That single change is often what forces major systems work. - Products covered by a delegated act may need a DPP before they can be placed on the market or put into service. - The DPP must be accurate, complete, and up to date, with controlled access rights and lifecycle rules. - The Commission must set up the DPP registry by 19 July 2026. - Customs use of the registry and unique registration identifier is built into the law. ## New policy layers under ESPR ESPR also reaches beyond classic ecodesign by covering unsold consumer products and by formalising working-plan governance. Those are net-new obligations for many teams. - Article 18 requires a published working plan and regular updates. - Chapter VI introduces annual disclosure obligations and a ban on destroying certain unsold consumer products from 19 July 2026. - Article 74 requires national penalties that are effective, proportionate, and dissuasive, and at least include fines and time-limited exclusion from public procurement. - Market-surveillance coordination is embedded through Regulation (EU) 2019/1020 mechanisms. *Recommended next step* *Placement: after the comparison section* ## Use EU ESPR vs Ecodesign Directive What Changes as a cited research workflow Research Copilot can take EU ESPR vs Ecodesign Directive What Changes from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU ESPR vs Ecodesign Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ESPR vs Ecodesign Directive What Changes](/solutions/research-copilot.md): Start from EU ESPR vs Ecodesign Directive What Changes and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ESPR vs Ecodesign Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR vs Ecodesign Directive What Changes. ## Primary sources - [Directive 2009/125/EC (Ecodesign Directive)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0125&ref=sorena.io) - Legacy framework for energy-related products. - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for the new ESPR structure and transition rules. - [European Commission: Ecodesign for Sustainable Products Regulation overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/sustainable-products/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Official explanation of how ESPR expands the old framework. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/espr-vs-ecodesign-directive --- --- title: "ESPR vs Ecodesign Directive (2009/125/EC)" canonical_url: "https://www.sorena.io/artifacts/eu/espr/espr-vs-ecodesign-directive" source_url: "https://www.sorena.io/artifacts/eu/espr/espr-vs-ecodesign-directive" author: "Sorena AI" description: "Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans." keywords: - "ESPR vs Ecodesign Directive" - "Regulation (EU) 2024/1781 vs 2009/125/EC" - "ecodesign regulation EU" - "digital product passport vs ecodesign directive" - "delegated acts ecodesign" - "ESPR" - "Ecodesign Directive" - "delegated acts" - "Digital Product Passport" - "scope" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR vs Ecodesign Directive (2009/125/EC) Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. *Comparison* *EU* ## EU ESPR vs Ecodesign Directive What Changes ESPR is not just a refreshed ecodesign directive. It is a broader product-sustainability framework with digital, enforcement, and unsold-products layers. The biggest mistake is assuming the old energy-only program model still covers what ESPR now requires. The old Ecodesign Directive and ESPR are related, but they are not the same operating model. Directive 2009/125/EC focused on energy-related products and required national transposition. ESPR is a directly applicable regulation with a much wider product perimeter, a stronger information and DPP layer, a formal working-plan mechanism, and a separate chapter on unsold consumer products. At the same time, legacy implementing measures remain relevant until they are repealed or declared obsolete. ## Scope and legal form The first difference is structural. The old regime was a directive for energy-related products. The new regime is a regulation for almost all physical products, with listed exclusions. That changes both legal analysis and operating scope. - Directive 2009/125/EC applied to energy-related products. - Regulation (EU) 2024/1781 applies to almost all physical products, subject to specific exclusions in Article 1. - As a regulation, ESPR applies directly across Member States without national transposition of the core framework. - Existing ecodesign implementing measures continue during the transition until repealed or obsolete. ## Requirement model: from energy performance to broader product sustainability The second difference is substantive. ESPR can target far more product aspects than classic energy efficiency. That expands the data and evidence burden. - Article 5 allows delegated acts to address durability, reparability, upgradeability, recycled content, remanufacturing, resource use, environmental footprint, and related product aspects where relevant. - Article 6 and Article 7 separate performance requirements from information requirements. - Horizontal measures can now span multiple product groups where the same product aspect can be improved effectively. - The compliance burden therefore moves from pure technical testing toward product, data, and lifecycle evidence. ## Digital Product Passport and registry: the biggest architecture change The old directive did not create a DPP system. ESPR does. That single change is often what forces major systems work. - Products covered by a delegated act may need a DPP before they can be placed on the market or put into service. - The DPP must be accurate, complete, and up to date, with controlled access rights and lifecycle rules. - The Commission must set up the DPP registry by 19 July 2026. - Customs use of the registry and unique registration identifier is built into the law. ## New policy layers under ESPR ESPR also reaches beyond classic ecodesign by covering unsold consumer products and by formalising working-plan governance. Those are net-new obligations for many teams. - Article 18 requires a published working plan and regular updates. - Chapter VI introduces annual disclosure obligations and a ban on destroying certain unsold consumer products from 19 July 2026. - Article 74 requires national penalties that are effective, proportionate, and dissuasive, and at least include fines and time-limited exclusion from public procurement. - Market-surveillance coordination is embedded through Regulation (EU) 2019/1020 mechanisms. *Recommended next step* *Placement: after the comparison section* ## Use EU ESPR vs Ecodesign Directive What Changes as a cited research workflow Research Copilot can take EU ESPR vs Ecodesign Directive What Changes from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU ESPR vs Ecodesign Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ESPR vs Ecodesign Directive What Changes](/solutions/research-copilot.md): Start from EU ESPR vs Ecodesign Directive What Changes and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ESPR vs Ecodesign Directive](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR vs Ecodesign Directive What Changes. ## Primary sources - [Directive 2009/125/EC (Ecodesign Directive)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0125&ref=sorena.io) - Legacy framework for energy-related products. - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for the new ESPR structure and transition rules. - [European Commission: Ecodesign for Sustainable Products Regulation overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/sustainable-products/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Official explanation of how ESPR expands the old framework. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/espr-vs-ecodesign-directive --- --- title: "ESPR vs PPWR" canonical_url: "https://www.sorena.io/artifacts/eu/espr/espr-vs-ppwr" source_url: "https://www.sorena.io/artifacts/eu/espr/espr-vs-ppwr" author: "Sorena AI" description: "Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design." keywords: - "ESPR vs PPWR" - "packaging and packaging waste regulation vs ESPR" - "product sustainability requirements EU" - "packaging compliance EU" - "DPP packaging data" - "evidence export product packaging" - "ESPR" - "PPWR" - "product sustainability" - "packaging compliance" - "data and evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR vs PPWR Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. *Comparison* *EU* ## EU ESPR vs PPWR How to Align ESPR and PPWR touch different legal objects, but they often collide inside the same product-data and packaging-data stack. The implementation goal is one evidence architecture with separate legal triggers, not two disconnected compliance programs. ESPR and PPWR are easy to confuse because both talk about circularity, information, and product-market obligations. The legal objects are different. ESPR is a framework for product sustainability requirements and product information, including DPP where a delegated act requires it. PPWR is a packaging lifecycle regulation with its own design, reuse, recyclability, and information duties. Companies selling packaged goods usually need one shared data architecture that can answer both laws without pretending they are the same rule set. ## Scope split that keeps teams out of trouble The cleanest way to separate the laws is to ask whether the obligation targets the product or the packaging. That split should be explicit in your system model. - ESPR focuses on the product and, through delegated acts, the product aspects relevant to sustainability and circularity. - PPWR focuses on packaging placed on the EU market and packaging waste across the lifecycle. - A single commercial item can be affected by both laws at the same time, but not by the same control set. - Create separate legal requirement objects even when the same supplier or material dataset feeds both. ## Where the data overlaps in practice The operational overlap is real even though the laws are different. This is where shared architecture saves time. - Material composition and recycled-content evidence. - Supplier declarations and chain-of-custody data. - Identifiers, QR or digital-access mechanisms, and versioned disclosures. - Language control, artwork control, and online presentation of regulated information. ## What should stay separate Shared architecture is useful, but merged legal logic is risky. Keep the compliance decisions separate. That is the only way to preserve auditability. - ESPR delegated-act scope, conformity route, DPP payload, and registry dependencies should remain product-law logic. - PPWR recyclability, minimisation, reuse, and packaging-format rules should remain packaging-law logic. - Do not assume that a PPWR digital disclosure automatically satisfies an ESPR DPP requirement, or the reverse. - Maintain separate evidence indexes even if they are built on a shared data lake or product master. ## Execution plan that avoids duplicated work The practical goal is one shared platform with two requirement maps. That setup lets you reuse data without losing legal precision. - Build one canonical identifier model across product, packaging, supplier, and web channels. - Use one disclosure governance process with separate legal approval rules for ESPR and PPWR outputs. - Reuse supplier evidence intake and validation services for both laws. - Keep route-to-market testing separate so product and packaging releases can be audited independently. *Recommended next step* *Placement: after the comparison section* ## Use EU ESPR vs PPWR How to Align as a cited research workflow Research Copilot can take EU ESPR vs PPWR How to Align from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU ESPR vs PPWR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ESPR vs PPWR How to Align](/solutions/research-copilot.md): Start from EU ESPR vs PPWR How to Align and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ESPR vs PPWR](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR vs PPWR How to Align. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for product-focused sustainability requirements and DPP structure. - [Regulation (EU) 2025/40 (PPWR)](https://eur-lex.europa.eu/eli/reg/2025/40/oj/eng?ref=sorena.io) - Primary source for packaging and packaging-waste rules. - [CEN-CENELEC CWA 18186:2025](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Useful implementation guidance for digital information architecture that may sit alongside packaging disclosures. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/espr-vs-ppwr --- --- title: "ESPR vs PPWR" canonical_url: "https://www.sorena.io/artifacts/eu/espr/espr-vs-ppwr" source_url: "https://www.sorena.io/artifacts/eu/espr/espr-vs-ppwr" author: "Sorena AI" description: "Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design." keywords: - "ESPR vs PPWR" - "packaging and packaging waste regulation vs ESPR" - "product sustainability requirements EU" - "packaging compliance EU" - "DPP packaging data" - "evidence export product packaging" - "ESPR" - "PPWR" - "product sustainability" - "packaging compliance" - "data and evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR vs PPWR Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. *Comparison* *EU* ## EU ESPR vs PPWR How to Align ESPR and PPWR touch different legal objects, but they often collide inside the same product-data and packaging-data stack. The implementation goal is one evidence architecture with separate legal triggers, not two disconnected compliance programs. ESPR and PPWR are easy to confuse because both talk about circularity, information, and product-market obligations. The legal objects are different. ESPR is a framework for product sustainability requirements and product information, including DPP where a delegated act requires it. PPWR is a packaging lifecycle regulation with its own design, reuse, recyclability, and information duties. Companies selling packaged goods usually need one shared data architecture that can answer both laws without pretending they are the same rule set. ## Scope split that keeps teams out of trouble The cleanest way to separate the laws is to ask whether the obligation targets the product or the packaging. That split should be explicit in your system model. - ESPR focuses on the product and, through delegated acts, the product aspects relevant to sustainability and circularity. - PPWR focuses on packaging placed on the EU market and packaging waste across the lifecycle. - A single commercial item can be affected by both laws at the same time, but not by the same control set. - Create separate legal requirement objects even when the same supplier or material dataset feeds both. ## Where the data overlaps in practice The operational overlap is real even though the laws are different. This is where shared architecture saves time. - Material composition and recycled-content evidence. - Supplier declarations and chain-of-custody data. - Identifiers, QR or digital-access mechanisms, and versioned disclosures. - Language control, artwork control, and online presentation of regulated information. ## What should stay separate Shared architecture is useful, but merged legal logic is risky. Keep the compliance decisions separate. That is the only way to preserve auditability. - ESPR delegated-act scope, conformity route, DPP payload, and registry dependencies should remain product-law logic. - PPWR recyclability, minimisation, reuse, and packaging-format rules should remain packaging-law logic. - Do not assume that a PPWR digital disclosure automatically satisfies an ESPR DPP requirement, or the reverse. - Maintain separate evidence indexes even if they are built on a shared data lake or product master. ## Execution plan that avoids duplicated work The practical goal is one shared platform with two requirement maps. That setup lets you reuse data without losing legal precision. - Build one canonical identifier model across product, packaging, supplier, and web channels. - Use one disclosure governance process with separate legal approval rules for ESPR and PPWR outputs. - Reuse supplier evidence intake and validation services for both laws. - Keep route-to-market testing separate so product and packaging releases can be audited independently. *Recommended next step* *Placement: after the comparison section* ## Use EU ESPR vs PPWR How to Align as a cited research workflow Research Copilot can take EU ESPR vs PPWR How to Align from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU ESPR vs PPWR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ESPR vs PPWR How to Align](/solutions/research-copilot.md): Start from EU ESPR vs PPWR How to Align and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ESPR vs PPWR](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR vs PPWR How to Align. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for product-focused sustainability requirements and DPP structure. - [Regulation (EU) 2025/40 (PPWR)](https://eur-lex.europa.eu/eli/reg/2025/40/oj/eng?ref=sorena.io) - Primary source for packaging and packaging-waste rules. - [CEN-CENELEC CWA 18186:2025](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Useful implementation guidance for digital information architecture that may sit alongside packaging disclosures. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/espr-vs-ppwr --- --- title: "EU ESPR FAQ (Regulation (EU) 2024/1781)" canonical_url: "https://www.sorena.io/artifacts/eu/espr/faq" source_url: "https://www.sorena.io/artifacts/eu/espr/faq" author: "Sorena AI" description: "Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work." keywords: - "ESPR FAQ" - "Regulation (EU) 2024/1781 FAQ" - "digital product passport FAQ" - "ESPR delegated acts FAQ" - "ESPR scope FAQ" - "delegated acts" - "Digital Product Passport" - "scope" - "implementation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU ESPR FAQ (Regulation (EU) 2024/1781) Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. *FAQ* *EU* ## EU ESPR (Regulation (EU) 2024/1781) FAQ Practical answers for product, data, and compliance teams. Focus: delegated acts, DPP readiness, supplier data, and evidence. This FAQ focuses on the questions teams ask once they move from awareness to implementation. The answers below are grounded in the current regulation, the adopted 2025 to 2030 working plan, the DPP rollout path, and the February 2026 unsold-products acts. ## Is ESPR already law even if my product-specific delegated act is not final? Yes. Regulation (EU) 2024/1781 entered into force on 18 July 2024. The framework is already law, even though many detailed product obligations will arrive later through Article 4 delegated acts. That is why companies should already be running scope, watchlist, DPP, and evidence work. ## Which product groups are supposed to move first? Article 18 required the first working plan to prioritise iron and steel, aluminium, textiles with a focus on garments and footwear, furniture including mattresses, tyres, detergents, paints, lubricants, and chemicals. The Commission adopted the first ESPR and Energy Labelling Working Plan on 16 April 2025 and also signalled horizontal workstreams and carried-over energy-related product work. ## Will every product need a Digital Product Passport? No. A DPP becomes mandatory where the applicable delegated act requires it. The law creates the DPP framework, but the product-group measure decides the detailed trigger and payload. That said, DPP-ready architecture is often still worth building early because the same platform can support multiple future measures. ## What is the most important thing to build before the delegated act lands? Build the shared infrastructure: a delegated-acts watchlist, a controlled product identifier model, a DPP-ready information model, supplier evidence intake, and a versioned disclosure and evidence-export process. Those are the long-lead items that are hardest to deliver under time pressure. ## Are the unsold-products rules separate from delegated-act compliance? Yes. The unsold-products disclosure and prohibition duties live in Chapter VI and are not the same thing as a product-group delegated act. Treat them as a separate compliance stream with its own owners, evidence, and annual calendar. ## What happens if a company gets ESPR wrong? Member States set penalties, but Article 74 requires them to be effective, proportionate, and dissuasive and to include at least fines and time-limited exclusion from public procurement. In practice, exposure is driven by market-surveillance findings, inability to prove what was published, missing DPP controls, and weak supplier evidence. *Recommended next step* *Placement: after the FAQ section* ## Use EU ESPR (Regulation (EU) 2024/1781) FAQ as a cited research workflow Research Copilot can take EU ESPR (Regulation (EU) 2024/1781) FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ESPR (Regulation (EU) 2024/1781) FAQ](/solutions/research-copilot.md): Start from EU ESPR (Regulation (EU) 2024/1781) FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) FAQ. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary legal source for the FAQ answers. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official Commission communication for current priorities. - [Commission Implementing Regulation (EU) 2026/2](https://eur-lex.europa.eu/eli/reg_impl/2026/2/oj?ref=sorena.io) - Official disclosure-format rule for unsold consumer products. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/faq --- --- title: "EU ESPR FAQ (Regulation (EU) 2024/1781)" canonical_url: "https://www.sorena.io/artifacts/eu/espr/faq" source_url: "https://www.sorena.io/artifacts/eu/espr/faq" author: "Sorena AI" description: "Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work." keywords: - "ESPR FAQ" - "Regulation (EU) 2024/1781 FAQ" - "digital product passport FAQ" - "ESPR delegated acts FAQ" - "ESPR scope FAQ" - "delegated acts" - "Digital Product Passport" - "scope" - "implementation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU ESPR FAQ (Regulation (EU) 2024/1781) Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. *FAQ* *EU* ## EU ESPR (Regulation (EU) 2024/1781) FAQ Practical answers for product, data, and compliance teams. Focus: delegated acts, DPP readiness, supplier data, and evidence. This FAQ focuses on the questions teams ask once they move from awareness to implementation. The answers below are grounded in the current regulation, the adopted 2025 to 2030 working plan, the DPP rollout path, and the February 2026 unsold-products acts. ## Is ESPR already law even if my product-specific delegated act is not final? Yes. Regulation (EU) 2024/1781 entered into force on 18 July 2024. The framework is already law, even though many detailed product obligations will arrive later through Article 4 delegated acts. That is why companies should already be running scope, watchlist, DPP, and evidence work. ## Which product groups are supposed to move first? Article 18 required the first working plan to prioritise iron and steel, aluminium, textiles with a focus on garments and footwear, furniture including mattresses, tyres, detergents, paints, lubricants, and chemicals. The Commission adopted the first ESPR and Energy Labelling Working Plan on 16 April 2025 and also signalled horizontal workstreams and carried-over energy-related product work. ## Will every product need a Digital Product Passport? No. A DPP becomes mandatory where the applicable delegated act requires it. The law creates the DPP framework, but the product-group measure decides the detailed trigger and payload. That said, DPP-ready architecture is often still worth building early because the same platform can support multiple future measures. ## What is the most important thing to build before the delegated act lands? Build the shared infrastructure: a delegated-acts watchlist, a controlled product identifier model, a DPP-ready information model, supplier evidence intake, and a versioned disclosure and evidence-export process. Those are the long-lead items that are hardest to deliver under time pressure. ## Are the unsold-products rules separate from delegated-act compliance? Yes. The unsold-products disclosure and prohibition duties live in Chapter VI and are not the same thing as a product-group delegated act. Treat them as a separate compliance stream with its own owners, evidence, and annual calendar. ## What happens if a company gets ESPR wrong? Member States set penalties, but Article 74 requires them to be effective, proportionate, and dissuasive and to include at least fines and time-limited exclusion from public procurement. In practice, exposure is driven by market-surveillance findings, inability to prove what was published, missing DPP controls, and weak supplier evidence. *Recommended next step* *Placement: after the FAQ section* ## Use EU ESPR (Regulation (EU) 2024/1781) FAQ as a cited research workflow Research Copilot can take EU ESPR (Regulation (EU) 2024/1781) FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ESPR (Regulation (EU) 2024/1781) FAQ](/solutions/research-copilot.md): Start from EU ESPR (Regulation (EU) 2024/1781) FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) FAQ. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary legal source for the FAQ answers. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official Commission communication for current priorities. - [Commission Implementing Regulation (EU) 2026/2](https://eur-lex.europa.eu/eli/reg_impl/2026/2/oj?ref=sorena.io) - Official disclosure-format rule for unsold consumer products. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/faq --- --- title: "ESPR Information Requirements, Labeling, and Disclosure" canonical_url: "https://www.sorena.io/artifacts/eu/espr/information-requirements-labeling-and-disclosure" source_url: "https://www.sorena.io/artifacts/eu/espr/information-requirements-labeling-and-disclosure" author: "Sorena AI" description: "A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements." keywords: - "ESPR information requirements" - "ESPR labeling" - "digital product passport information requirements" - "DPP labeling" - "QR code product passport" - "product disclosure governance" - "sustainability claims evidence" - "information requirements" - "digital labeling" - "Digital Product Passport" - "QR codes" - "disclosure governance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR Information Requirements, Labeling, and Disclosure A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. *Deep Dive* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Information Requirements Under ESPR, information is a regulated product capability. It has to be designed, governed, and provable. Use Articles 7, 9, 10, and 16 to keep DPP, labels, and digital disclosures aligned. Information requirements are where ESPR becomes operational. Once a delegated act sets Article 7 information duties, those data points may have to appear in the DPP, on a label, on a product webpage, or through another digital channel. The compliance task is not just to publish the information, but to make sure the information is accurate, complete, up to date, audience-appropriate, and linked back to evidence. ## Article 7: what information requirements are designed to do Article 7 allows the Commission to require information that supports sustainable choices, use, maintenance, repair, end-of-life treatment, and traceability of substances of concern. The practical implication is that the information surface can be wide, even if the consumer-facing view is simple. - Information can relate to product performance and circularity aspects. - Information can include substances-of-concern tracking through the product life cycle where relevant. - Information must be clear, understandable, and tailored to the product group and intended recipients. - The delegated act decides the exact information payload and presentation route. *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Information Requirements across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Information Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Information Requirements](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Information Requirements and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Information Requirements. ## DPP and labels serve different jobs The DPP is not the same thing as a label. The label is the compressed view. The DPP is the structured, richer information layer. Design them as connected outputs from one controlled source. - Use the DPP as the source of truth for structured product information and history. - Use labels to display the subset of information that the delegated act requires to be shown in a simplified format. - Keep online product pages aligned with both outputs so customers do not see conflicting claims. - Version labels and DPP outputs together whenever the underlying evidence changes. ## Article 16: if a label is required, the delegated act must specify how it works Article 16 is more detailed than many teams expect. If a delegated act requires a label, it must specify core mechanics of the label itself. That means label governance belongs inside the engineering and release process. - The delegated act must specify content, design, and where applicable the means for generating the label electronically. - The label must stay visible and legible across selling channels, including online contexts. - Products must not be accompanied by lookalike labels or other information that misleads customers about the regulated label. - For some energy-related products, the Commission can assess whether ESPR label logic should replace or complement existing energy-label logic. ## QR, data carriers, and audience-specific disclosure Data carriers should be treated as controlled interfaces. Placement, persistence, and scan experience affect both compliance and usability. Design for multiple audiences from the start, including accessibility and authority use cases. - Define where the data carrier lives on the product, packaging, or accompanying documentation. - Use stable identifiers so the scan resolves to the right model, batch, or item context. - Support consumer, repairer, recycler, and authority views without mixing access rights. - Design disclosure pages so they remain readable and useful on mobile and desktop, not just legally complete. ## The control model that keeps disclosures defensible A reliable disclosure system uses one chain from source evidence to published output. That chain should be demonstrable on demand. - Source evidence linked to each field or claim. - Validation rules for units, completeness, and provenance. - Approval history for every publication or update. - Historical views and export pack for investigations or authority questions. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Articles 7, 9, 10, and 16. - [European Commission factsheet on QR codes on products](https://commission.europa.eu/document/download/4d15c905-cd5b-4ae9-8b23-7eb6ce1b478f_en?ref=sorena.io) - Official Commission material on digital information and QR-code use cases. - [CEN-CENELEC CWA 18186:2025](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Implementation guidance for DPP design, access, and accessibility. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/information-requirements-labeling-and-disclosure --- --- title: "ESPR Information Requirements, Labeling, and Disclosure" canonical_url: "https://www.sorena.io/artifacts/eu/espr/information-requirements-labeling-and-disclosure" source_url: "https://www.sorena.io/artifacts/eu/espr/information-requirements-labeling-and-disclosure" author: "Sorena AI" description: "A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements." keywords: - "ESPR information requirements" - "ESPR labeling" - "digital product passport information requirements" - "DPP labeling" - "QR code product passport" - "product disclosure governance" - "sustainability claims evidence" - "information requirements" - "digital labeling" - "Digital Product Passport" - "QR codes" - "disclosure governance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR Information Requirements, Labeling, and Disclosure A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. *Deep Dive* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Information Requirements Under ESPR, information is a regulated product capability. It has to be designed, governed, and provable. Use Articles 7, 9, 10, and 16 to keep DPP, labels, and digital disclosures aligned. Information requirements are where ESPR becomes operational. Once a delegated act sets Article 7 information duties, those data points may have to appear in the DPP, on a label, on a product webpage, or through another digital channel. The compliance task is not just to publish the information, but to make sure the information is accurate, complete, up to date, audience-appropriate, and linked back to evidence. ## Article 7: what information requirements are designed to do Article 7 allows the Commission to require information that supports sustainable choices, use, maintenance, repair, end-of-life treatment, and traceability of substances of concern. The practical implication is that the information surface can be wide, even if the consumer-facing view is simple. - Information can relate to product performance and circularity aspects. - Information can include substances-of-concern tracking through the product life cycle where relevant. - Information must be clear, understandable, and tailored to the product group and intended recipients. - The delegated act decides the exact information payload and presentation route. *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Information Requirements across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Information Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Information Requirements](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Information Requirements and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Information Requirements. ## DPP and labels serve different jobs The DPP is not the same thing as a label. The label is the compressed view. The DPP is the structured, richer information layer. Design them as connected outputs from one controlled source. - Use the DPP as the source of truth for structured product information and history. - Use labels to display the subset of information that the delegated act requires to be shown in a simplified format. - Keep online product pages aligned with both outputs so customers do not see conflicting claims. - Version labels and DPP outputs together whenever the underlying evidence changes. ## Article 16: if a label is required, the delegated act must specify how it works Article 16 is more detailed than many teams expect. If a delegated act requires a label, it must specify core mechanics of the label itself. That means label governance belongs inside the engineering and release process. - The delegated act must specify content, design, and where applicable the means for generating the label electronically. - The label must stay visible and legible across selling channels, including online contexts. - Products must not be accompanied by lookalike labels or other information that misleads customers about the regulated label. - For some energy-related products, the Commission can assess whether ESPR label logic should replace or complement existing energy-label logic. ## QR, data carriers, and audience-specific disclosure Data carriers should be treated as controlled interfaces. Placement, persistence, and scan experience affect both compliance and usability. Design for multiple audiences from the start, including accessibility and authority use cases. - Define where the data carrier lives on the product, packaging, or accompanying documentation. - Use stable identifiers so the scan resolves to the right model, batch, or item context. - Support consumer, repairer, recycler, and authority views without mixing access rights. - Design disclosure pages so they remain readable and useful on mobile and desktop, not just legally complete. ## The control model that keeps disclosures defensible A reliable disclosure system uses one chain from source evidence to published output. That chain should be demonstrable on demand. - Source evidence linked to each field or claim. - Validation rules for units, completeness, and provenance. - Approval history for every publication or update. - Historical views and export pack for investigations or authority questions. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Articles 7, 9, 10, and 16. - [European Commission factsheet on QR codes on products](https://commission.europa.eu/document/download/4d15c905-cd5b-4ae9-8b23-7eb6ce1b478f_en?ref=sorena.io) - Official Commission material on digital information and QR-code use cases. - [CEN-CENELEC CWA 18186:2025](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Implementation guidance for DPP design, access, and accessibility. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/information-requirements-labeling-and-disclosure --- --- title: "ESPR Penalties and Enforcement" canonical_url: "https://www.sorena.io/artifacts/eu/espr/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/espr/penalties-and-fines" author: "Sorena AI" description: "A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence." keywords: - "ESPR penalties" - "ESPR enforcement" - "Regulation (EU) 2024/1781 penalties" - "market surveillance ESPR" - "Digital Product Passport enforcement" - "DPP evidence export" - "penalties" - "market surveillance" - "DPP governance" - "evidence export" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR Penalties and Enforcement A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. *Risk Guide* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Penalties and Enforcement Penalties sit at the end of the chain. The controls that matter most are the ones that prove what was placed on the market and why. Article 74 sets the penalty baseline, but market-surveillance and evidence speed decide how painful enforcement becomes. ESPR penalties are set nationally, but the regulation already tells you what Member States must be able to impose: effective, proportionate, and dissuasive penalties that include at least fines and time-limited exclusion from public procurement procedures. In practice, exposure is driven by whether the company can prove the applicable rule, the published information, the supporting records, and the corrective actions taken after a non-compliance signal. ## Article 74: what the regulation requires from national penalties The exact amount of fines is national, but the structure of the penalty regime is not unconstrained. Article 74 gives you the baseline enforcement logic. - Member States must set penalties that are effective, proportionate, and dissuasive. - Authorities must be able to impose fines. - Authorities must also be able to impose time-limited exclusion from public procurement procedures. - Penalty decisions should take account of gravity, duration, intent, financial situation, economic benefit, environmental damage, mitigation, and repeat behaviour. *Recommended next step* *Placement: after the enforcement section* ## Use EU ESPR (Regulation (EU) 2024/1781) Penalties and Enforcement as a cited research workflow Research Copilot can take EU ESPR (Regulation (EU) 2024/1781) Penalties and Enforcement from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ESPR (Regulation (EU) 2024/1781) Penalties and Enforcement](/solutions/research-copilot.md): Start from EU ESPR (Regulation (EU) 2024/1781) Penalties and Enforcement and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Penalties and Enforcement. ## How enforcement works in practice Most cases start with observable non-compliance: wrong or missing information, weak conformity evidence, inconsistent identifiers, or failure to support an authority inquiry. Once a delegated act applies, the question is rarely theoretical. Authorities test the product version on the market. - Market-surveillance authorities can require corrective action within a reasonable period. - Registry and customs checks increase practical detectability once the relevant DPP and registry flows are operational. - Unsold-products disclosures can also become an enforcement surface if website reporting is incomplete or inconsistent. - Cross-border information sharing under the market-surveillance framework can widen the impact of one finding. ## Failure modes that create exposure fastest You do not need to predict every national penalty number to reduce risk. Focus on the failure modes that make non-compliance obvious and hard to defend. Those are usually data and control failures, not just legal interpretation errors. - A DPP or digital disclosure that cannot be tied back to controlled source evidence. - Inconsistent identifiers across product, packaging, DPP, and registry records. - Supplier evidence gaps or undocumented overrides of missing data. - No historical record showing what was published for the affected product version. - Slow or improvised response to an authority request. ## Controls that reduce enforcement pain The same controls that support smooth implementation also reduce enforcement risk. Build them once and keep them current. - Evidence pack export by model, batch, or item with source references and approvals. - DPP and disclosure version history with effective dates. - Supplier verification log with exceptions and remediation actions. - Corrective-action workflow that links defect, decision, update, and verification. - Member State penalty tracker for the jurisdictions where you actually sell. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Article 74 penalties and the market-surveillance architecture. - [European Commission: Ecodesign for Sustainable Products Regulation overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/sustainable-products/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Official policy overview and implementation context. - [Commission Implementing Regulation (EU) 2026/2](https://eur-lex.europa.eu/eli/reg_impl/2026/2/oj?ref=sorena.io) - Relevant where enforcement touches unsold-products disclosure obligations. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/penalties-and-fines --- --- title: "ESPR Penalties and Enforcement" canonical_url: "https://www.sorena.io/artifacts/eu/espr/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/espr/penalties-and-fines" author: "Sorena AI" description: "A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence." keywords: - "ESPR penalties" - "ESPR enforcement" - "Regulation (EU) 2024/1781 penalties" - "market surveillance ESPR" - "Digital Product Passport enforcement" - "DPP evidence export" - "penalties" - "market surveillance" - "DPP governance" - "evidence export" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR Penalties and Enforcement A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. *Risk Guide* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Penalties and Enforcement Penalties sit at the end of the chain. The controls that matter most are the ones that prove what was placed on the market and why. Article 74 sets the penalty baseline, but market-surveillance and evidence speed decide how painful enforcement becomes. ESPR penalties are set nationally, but the regulation already tells you what Member States must be able to impose: effective, proportionate, and dissuasive penalties that include at least fines and time-limited exclusion from public procurement procedures. In practice, exposure is driven by whether the company can prove the applicable rule, the published information, the supporting records, and the corrective actions taken after a non-compliance signal. ## Article 74: what the regulation requires from national penalties The exact amount of fines is national, but the structure of the penalty regime is not unconstrained. Article 74 gives you the baseline enforcement logic. - Member States must set penalties that are effective, proportionate, and dissuasive. - Authorities must be able to impose fines. - Authorities must also be able to impose time-limited exclusion from public procurement procedures. - Penalty decisions should take account of gravity, duration, intent, financial situation, economic benefit, environmental damage, mitigation, and repeat behaviour. *Recommended next step* *Placement: after the enforcement section* ## Use EU ESPR (Regulation (EU) 2024/1781) Penalties and Enforcement as a cited research workflow Research Copilot can take EU ESPR (Regulation (EU) 2024/1781) Penalties and Enforcement from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ESPR (Regulation (EU) 2024/1781) Penalties and Enforcement](/solutions/research-copilot.md): Start from EU ESPR (Regulation (EU) 2024/1781) Penalties and Enforcement and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Penalties and Enforcement. ## How enforcement works in practice Most cases start with observable non-compliance: wrong or missing information, weak conformity evidence, inconsistent identifiers, or failure to support an authority inquiry. Once a delegated act applies, the question is rarely theoretical. Authorities test the product version on the market. - Market-surveillance authorities can require corrective action within a reasonable period. - Registry and customs checks increase practical detectability once the relevant DPP and registry flows are operational. - Unsold-products disclosures can also become an enforcement surface if website reporting is incomplete or inconsistent. - Cross-border information sharing under the market-surveillance framework can widen the impact of one finding. ## Failure modes that create exposure fastest You do not need to predict every national penalty number to reduce risk. Focus on the failure modes that make non-compliance obvious and hard to defend. Those are usually data and control failures, not just legal interpretation errors. - A DPP or digital disclosure that cannot be tied back to controlled source evidence. - Inconsistent identifiers across product, packaging, DPP, and registry records. - Supplier evidence gaps or undocumented overrides of missing data. - No historical record showing what was published for the affected product version. - Slow or improvised response to an authority request. ## Controls that reduce enforcement pain The same controls that support smooth implementation also reduce enforcement risk. Build them once and keep them current. - Evidence pack export by model, batch, or item with source references and approvals. - DPP and disclosure version history with effective dates. - Supplier verification log with exceptions and remediation actions. - Corrective-action workflow that links defect, decision, update, and verification. - Member State penalty tracker for the jurisdictions where you actually sell. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Article 74 penalties and the market-surveillance architecture. - [European Commission: Ecodesign for Sustainable Products Regulation overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/sustainable-products/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Official policy overview and implementation context. - [Commission Implementing Regulation (EU) 2026/2](https://eur-lex.europa.eu/eli/reg_impl/2026/2/oj?ref=sorena.io) - Relevant where enforcement touches unsold-products disclosure obligations. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/penalties-and-fines --- --- title: "ESPR Product Priorities + Delegated Acts Tracker" canonical_url: "https://www.sorena.io/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker" source_url: "https://www.sorena.io/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker" author: "Sorena AI" description: "A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP)." keywords: - "ESPR delegated acts tracker" - "ESPR product priorities" - "ESPR portfolio mapping" - "DPP readiness scoring" - "Regulation (EU) 2024/1781 tracker" - "delegated acts monitoring" - "tracker" - "portfolio mapping" - "readiness scoring" - "delegated acts" - "DPP" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR Product Priorities + Delegated Acts Tracker A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). *Tracker* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Product Priorities Tracker Use the tracker to decide which product families deserve budget, data cleanup, and supplier work first. The tracker should combine Article 18 priorities, the adopted working plan, and your internal readiness score. A delegated-acts watchlist tells you what the EU may regulate. A product-priorities tracker tells you what your business needs to build first. Use it to combine legal priority, portfolio exposure, supplier complexity, DPP dependence, and evidence maturity so your roadmap follows the real risk, not whoever shouts loudest in the meeting. ## Start with the legally signalled product groups Your first tracker rows should follow the legal and policy priorities already visible in the regulation and the 2025 to 2030 working plan. This is the fastest way to focus the roadmap. - Iron and steel. - Aluminium. - Textiles, especially garments and footwear. - Furniture and mattresses. - Tyres, detergents, paints, lubricants, and chemicals. - Energy-related product lines affected by the continuation and migration of earlier ecodesign work. ## Scoring model that predicts effort rather than optimism The best tracker score is the one that predicts implementation drag. Legal urgency alone is not enough. Use a small number of dimensions and score them consistently. - Regulatory urgency and confidence. - Supplier-data difficulty and verification burden. - DPP or digital-information complexity. - Identifier and systems-integration maturity. - Evidence-export maturity and enforcement sensitivity. ## How to pick the first pilot product family Choose a pilot that is difficult enough to test the operating model but not so complex that it stalls the whole program. You want a pilot that proves the shared platform. - Prefer a product family with meaningful supplier depth and real disclosure needs. - Prefer a family where DPP or digital disclosure architecture will be reused by later waves. - Avoid a pilot that depends on unresolved master-data basics unless fixing those basics is itself the program objective. - Make the pilot produce a full evidence pack and post-release review. ## How to keep the tracker useful after the first year Trackers fail when they become static inventories. They stay useful when they are tied to delivery outcomes. Every status change should be visible in the release plan. - Link each row to active work items, owners, and target milestone dates. - Update readiness scores after every release or architecture milestone. - Keep a note of which shared controls were strengthened by each product-family wave. - Retire or downgrade rows only when the legal basis for doing so is clear. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Product Priorities Tracker across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Product Priorities Tracker from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Product Priorities Tracker](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Product Priorities Tracker and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Product Priorities Tracker. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Article 18 product priorities. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official Commission communication for the current planning horizon. - [Green Forum: 2025-2030 working plan](https://green-forum.ec.europa.eu/news/2025-2030-working-plan-2025-07-11_en?ref=sorena.io) - Official Commission summary highlighting current product focus and horizontal measures. - [CEN-CENELEC CWA 18186:2025](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Useful for judging DPP-related readiness and interoperability complexity. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker --- --- title: "ESPR Product Priorities + Delegated Acts Tracker" canonical_url: "https://www.sorena.io/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker" source_url: "https://www.sorena.io/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker" author: "Sorena AI" description: "A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP)." keywords: - "ESPR delegated acts tracker" - "ESPR product priorities" - "ESPR portfolio mapping" - "DPP readiness scoring" - "Regulation (EU) 2024/1781 tracker" - "delegated acts monitoring" - "tracker" - "portfolio mapping" - "readiness scoring" - "delegated acts" - "DPP" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR Product Priorities + Delegated Acts Tracker A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). *Tracker* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Product Priorities Tracker Use the tracker to decide which product families deserve budget, data cleanup, and supplier work first. The tracker should combine Article 18 priorities, the adopted working plan, and your internal readiness score. A delegated-acts watchlist tells you what the EU may regulate. A product-priorities tracker tells you what your business needs to build first. Use it to combine legal priority, portfolio exposure, supplier complexity, DPP dependence, and evidence maturity so your roadmap follows the real risk, not whoever shouts loudest in the meeting. ## Start with the legally signalled product groups Your first tracker rows should follow the legal and policy priorities already visible in the regulation and the 2025 to 2030 working plan. This is the fastest way to focus the roadmap. - Iron and steel. - Aluminium. - Textiles, especially garments and footwear. - Furniture and mattresses. - Tyres, detergents, paints, lubricants, and chemicals. - Energy-related product lines affected by the continuation and migration of earlier ecodesign work. ## Scoring model that predicts effort rather than optimism The best tracker score is the one that predicts implementation drag. Legal urgency alone is not enough. Use a small number of dimensions and score them consistently. - Regulatory urgency and confidence. - Supplier-data difficulty and verification burden. - DPP or digital-information complexity. - Identifier and systems-integration maturity. - Evidence-export maturity and enforcement sensitivity. ## How to pick the first pilot product family Choose a pilot that is difficult enough to test the operating model but not so complex that it stalls the whole program. You want a pilot that proves the shared platform. - Prefer a product family with meaningful supplier depth and real disclosure needs. - Prefer a family where DPP or digital disclosure architecture will be reused by later waves. - Avoid a pilot that depends on unresolved master-data basics unless fixing those basics is itself the program objective. - Make the pilot produce a full evidence pack and post-release review. ## How to keep the tracker useful after the first year Trackers fail when they become static inventories. They stay useful when they are tied to delivery outcomes. Every status change should be visible in the release plan. - Link each row to active work items, owners, and target milestone dates. - Update readiness scores after every release or architecture milestone. - Keep a note of which shared controls were strengthened by each product-family wave. - Retire or downgrade rows only when the legal basis for doing so is clear. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Product Priorities Tracker across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Product Priorities Tracker from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Product Priorities Tracker](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Product Priorities Tracker and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Product Priorities Tracker. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Article 18 product priorities. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official Commission communication for the current planning horizon. - [Green Forum: 2025-2030 working plan](https://green-forum.ec.europa.eu/news/2025-2030-working-plan-2025-07-11_en?ref=sorena.io) - Official Commission summary highlighting current product focus and horizontal measures. - [CEN-CENELEC CWA 18186:2025](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Useful for judging DPP-related readiness and interoperability complexity. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker --- --- title: "EU ESPR Requirements (Regulation (EU) 2024/1781)" canonical_url: "https://www.sorena.io/artifacts/eu/espr/requirements" source_url: "https://www.sorena.io/artifacts/eu/espr/requirements" author: "Sorena AI" description: "A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781." keywords: - "ESPR requirements" - "Regulation (EU) 2024/1781 requirements" - "Ecodesign for Sustainable Products Regulation requirements" - "ESPR delegated acts requirements" - "Digital Product Passport requirements" - "DPP information requirements" - "delegated acts" - "Digital Product Passport" - "information requirements" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU ESPR Requirements (Regulation (EU) 2024/1781) A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. *Requirements Guide* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Requirements ESPR requirements are a mix of performance rules, information rules, conformity mechanics, and digital infrastructure. Build the reusable controls now so later delegated acts change parameters, not the whole operating model. ESPR requirements are easier to manage when you separate the framework from the product-group measure. The framework already tells you what kinds of requirements the Commission can impose, how delegated acts are structured, how DPP and labels work, and how conformity routes are chosen. The product-group delegated act then fills in the actual thresholds, payloads, and dates. That means you can build much of the compliance machinery before your exact product rule lands. ## 1) Article 5 product aspects: what the Commission can target Article 5 is the requirement universe. It explains the kinds of product aspects delegated acts may improve where relevant to the product group. Use it as a design checklist for potential impact. - Durability, reliability, reusability, upgradeability, reparability, and maintenance. - Presence of substances of concern and resource use efficiency. - Recycled content, remanufacturing, recyclability, and recovery. - Environmental footprint, carbon footprint, and waste generation. ## 2) Article 6 and Article 7: performance requirements versus information requirements Keep these two buckets separate in your system design. They often need different evidence and publication paths. Delegated acts can use both at the same time. - Article 6 covers performance requirements linked to the relevant product aspects. - Article 7 covers information requirements, including DPP information and, where relevant, labels. - Classes of performance can be set for some information requirements. - Substances-of-concern tracking can become part of the information layer where relevant. *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Requirements across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Requirements](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Requirements and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Requirements. ## 3) Article 8: what every delegated act has to spell out Article 8 is the table of contents for a serious implementation review. It tells you what to expect inside a product-group measure. Use it to structure your delegated-act impact template. - Product groups covered and ecodesign requirements imposed. - Relevant parameters from Annex I and any that are not needed. - Information requirements, including DPP and labels where relevant. - Conformity-assessment module and transitional period. - Review timing for the delegated act itself. ## 4) DPP, labels, and conformity are requirement layers too Many teams treat DPP and labels as communication extras. Under ESPR they are part of the requirement stack. The same applies to conformity-route design. - Products covered by a delegated act can only be placed on the market or put into service if a DPP is available where required. - Article 16 labels must be controlled if the delegated act requires them. - Article 4 lets the Commission specify the conformity-assessment procedure, including Module A or other recognised modules where justified. - Evidence architecture should therefore link performance tests, DPP fields, labels, and conformity records. ## 5) Timing rules you should build into the requirements model Timing is part of the requirement, not just a project-management detail. Your requirement model should store the timing logic as first-class data. - The first delegated act cannot enter into force before 19 July 2025. - Delegated acts normally leave at least 18 months between entry into force and application, unless justified otherwise. - The DPP registry must be set up by 19 July 2026. - Unsold-products prohibition and disclosure streams have their own dates and should be modelled separately. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Articles 4 to 10, 16, and Annex I. - [European Commission: Ecodesign for Sustainable Products Regulation overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/sustainable-products/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Official implementation overview. - [CEN-CENELEC CWA 18186:2025](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Useful implementation guidance on DPP and label-related design decisions. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/requirements --- --- title: "EU ESPR Requirements (Regulation (EU) 2024/1781)" canonical_url: "https://www.sorena.io/artifacts/eu/espr/requirements" source_url: "https://www.sorena.io/artifacts/eu/espr/requirements" author: "Sorena AI" description: "A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781." keywords: - "ESPR requirements" - "Regulation (EU) 2024/1781 requirements" - "Ecodesign for Sustainable Products Regulation requirements" - "ESPR delegated acts requirements" - "Digital Product Passport requirements" - "DPP information requirements" - "delegated acts" - "Digital Product Passport" - "information requirements" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU ESPR Requirements (Regulation (EU) 2024/1781) A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. *Requirements Guide* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Requirements ESPR requirements are a mix of performance rules, information rules, conformity mechanics, and digital infrastructure. Build the reusable controls now so later delegated acts change parameters, not the whole operating model. ESPR requirements are easier to manage when you separate the framework from the product-group measure. The framework already tells you what kinds of requirements the Commission can impose, how delegated acts are structured, how DPP and labels work, and how conformity routes are chosen. The product-group delegated act then fills in the actual thresholds, payloads, and dates. That means you can build much of the compliance machinery before your exact product rule lands. ## 1) Article 5 product aspects: what the Commission can target Article 5 is the requirement universe. It explains the kinds of product aspects delegated acts may improve where relevant to the product group. Use it as a design checklist for potential impact. - Durability, reliability, reusability, upgradeability, reparability, and maintenance. - Presence of substances of concern and resource use efficiency. - Recycled content, remanufacturing, recyclability, and recovery. - Environmental footprint, carbon footprint, and waste generation. ## 2) Article 6 and Article 7: performance requirements versus information requirements Keep these two buckets separate in your system design. They often need different evidence and publication paths. Delegated acts can use both at the same time. - Article 6 covers performance requirements linked to the relevant product aspects. - Article 7 covers information requirements, including DPP information and, where relevant, labels. - Classes of performance can be set for some information requirements. - Substances-of-concern tracking can become part of the information layer where relevant. *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Requirements across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Requirements](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Requirements and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Requirements. ## 3) Article 8: what every delegated act has to spell out Article 8 is the table of contents for a serious implementation review. It tells you what to expect inside a product-group measure. Use it to structure your delegated-act impact template. - Product groups covered and ecodesign requirements imposed. - Relevant parameters from Annex I and any that are not needed. - Information requirements, including DPP and labels where relevant. - Conformity-assessment module and transitional period. - Review timing for the delegated act itself. ## 4) DPP, labels, and conformity are requirement layers too Many teams treat DPP and labels as communication extras. Under ESPR they are part of the requirement stack. The same applies to conformity-route design. - Products covered by a delegated act can only be placed on the market or put into service if a DPP is available where required. - Article 16 labels must be controlled if the delegated act requires them. - Article 4 lets the Commission specify the conformity-assessment procedure, including Module A or other recognised modules where justified. - Evidence architecture should therefore link performance tests, DPP fields, labels, and conformity records. ## 5) Timing rules you should build into the requirements model Timing is part of the requirement, not just a project-management detail. Your requirement model should store the timing logic as first-class data. - The first delegated act cannot enter into force before 19 July 2025. - Delegated acts normally leave at least 18 months between entry into force and application, unless justified otherwise. - The DPP registry must be set up by 19 July 2026. - Unsold-products prohibition and disclosure streams have their own dates and should be modelled separately. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for Articles 4 to 10, 16, and Annex I. - [European Commission: Ecodesign for Sustainable Products Regulation overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/sustainable-products/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Official implementation overview. - [CEN-CENELEC CWA 18186:2025](https://www.cencenelec.eu/media/CEN-CENELEC/CWAs/RI/2025/cwa18186_2025.pdf?ref=sorena.io) - Useful implementation guidance on DPP and label-related design decisions. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/requirements --- --- title: "ESPR Timeline (Regulation (EU) 2024/1781)" canonical_url: "https://www.sorena.io/artifacts/eu/espr/timeline" source_url: "https://www.sorena.io/artifacts/eu/espr/timeline" author: "Sorena AI" description: "A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024." keywords: - "ESPR timeline" - "Regulation (EU) 2024/1781 timeline" - "ESPR delegated acts timeline" - "ESPR milestones" - "digital product passport timeline" - "timeline" - "ESPR" - "delegated acts" - "DPP" - "planning" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR Timeline (Regulation (EU) 2024/1781) A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. *Timeline Guide* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Timeline Use the timeline to anchor delivery work before product-group dates compress the program. The framework dates are already enough to sequence scope, DPP, supplier, registry, and unsold-products work. ESPR is a framework regulation, but the timeline is not empty. You already know when the law entered into force, when the first working plan was adopted, when the first delegated act is legally allowed to enter into force, when the DPP registry must exist, when the first unsold-products prohibition starts, and when the disclosure-format rule begins to apply. That is enough to build a real program timeline now. ## Milestone anchors that are already known These are the dates every ESPR program should carry in its core calendar. They give you the minimum sequence for capability building. - 28 June 2024, publication in the Official Journal. - 18 July 2024, ESPR entered into force. - 16 April 2025, first ESPR and Energy Labelling Working Plan adopted. - 19 July 2025, first Article 4 delegated act may enter into force, but not earlier. - 9 February 2026, Commission acts adopted on derogations and disclosure format for unsold consumer products. - 19 July 2026, DPP registry deadline and start of the Annex VII destruction prohibition. - 2 March 2027, disclosure-format implementing regulation starts applying. - 19 July 2030, Commission evaluation deadline. *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Timeline across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Timeline from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Timeline](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Timeline and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Timeline. ## What each milestone should trigger internally The value of a milestone comes from the work it triggers. Make that trigger explicit. This avoids passive date tracking. - Entry into force should trigger portfolio scope and carry-over-rule mapping. - Working-plan adoption should trigger product-family prioritisation and budget review. - Delegated-act floor should trigger design-complete readiness for likely early product groups. - Registry deadline should trigger identifier, export, and customs-readiness testing. - Unsold-products dates should trigger year-end disclosure and stock-management controls. ## What to do next if your product is on the near-term path If the product family overlaps a priority group, the next work should be architecture and supplier work, not more abstract horizon scanning. Those streams create the longest delays. - Freeze the canonical product taxonomy. - Build the delegated-acts watchlist and impact template. - Start DPP data-model and identifier design. - Launch supplier evidence intake and remediation for the first pilot family. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary legal source for milestone dates. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official Commission communication adopted on 16 April 2025. - [Commission Implementing Regulation (EU) 2026/2](https://eur-lex.europa.eu/eli/reg_impl/2026/2/oj?ref=sorena.io) - Official source for the 2 March 2027 application date. - [European Commission: New EU rules to stop destruction of unsold clothes and shoes](https://environment.ec.europa.eu/news/new-eu-rules-stop-destruction-unsold-clothes-and-shoes-2026-02-09_en?ref=sorena.io) - Official summary of the 9 February 2026 unsold-products acts. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/timeline --- --- title: "ESPR Timeline (Regulation (EU) 2024/1781)" canonical_url: "https://www.sorena.io/artifacts/eu/espr/timeline" source_url: "https://www.sorena.io/artifacts/eu/espr/timeline" author: "Sorena AI" description: "A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024." keywords: - "ESPR timeline" - "Regulation (EU) 2024/1781 timeline" - "ESPR delegated acts timeline" - "ESPR milestones" - "digital product passport timeline" - "timeline" - "ESPR" - "delegated acts" - "DPP" - "planning" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ESPR Timeline (Regulation (EU) 2024/1781) A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. *Timeline Guide* *EU* ## EU ESPR (Regulation (EU) 2024/1781) Timeline Use the timeline to anchor delivery work before product-group dates compress the program. The framework dates are already enough to sequence scope, DPP, supplier, registry, and unsold-products work. ESPR is a framework regulation, but the timeline is not empty. You already know when the law entered into force, when the first working plan was adopted, when the first delegated act is legally allowed to enter into force, when the DPP registry must exist, when the first unsold-products prohibition starts, and when the disclosure-format rule begins to apply. That is enough to build a real program timeline now. ## Milestone anchors that are already known These are the dates every ESPR program should carry in its core calendar. They give you the minimum sequence for capability building. - 28 June 2024, publication in the Official Journal. - 18 July 2024, ESPR entered into force. - 16 April 2025, first ESPR and Energy Labelling Working Plan adopted. - 19 July 2025, first Article 4 delegated act may enter into force, but not earlier. - 9 February 2026, Commission acts adopted on derogations and disclosure format for unsold consumer products. - 19 July 2026, DPP registry deadline and start of the Annex VII destruction prohibition. - 2 March 2027, disclosure-format implementing regulation starts applying. - 19 July 2030, Commission evaluation deadline. *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU ESPR (Regulation (EU) 2024/1781) Timeline across ESG workflows ESG Compliance can take EU ESPR (Regulation (EU) 2024/1781) Timeline from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU ESPR (Regulation (EU) 2024/1781) Timeline](/solutions/esg-compliance.md): Start from EU ESPR (Regulation (EU) 2024/1781) Timeline and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) Timeline. ## What each milestone should trigger internally The value of a milestone comes from the work it triggers. Make that trigger explicit. This avoids passive date tracking. - Entry into force should trigger portfolio scope and carry-over-rule mapping. - Working-plan adoption should trigger product-family prioritisation and budget review. - Delegated-act floor should trigger design-complete readiness for likely early product groups. - Registry deadline should trigger identifier, export, and customs-readiness testing. - Unsold-products dates should trigger year-end disclosure and stock-management controls. ## What to do next if your product is on the near-term path If the product family overlaps a priority group, the next work should be architecture and supplier work, not more abstract horizon scanning. Those streams create the longest delays. - Freeze the canonical product taxonomy. - Build the delegated-acts watchlist and impact template. - Start DPP data-model and identifier design. - Launch supplier evidence intake and remediation for the first pilot family. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary legal source for milestone dates. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official Commission communication adopted on 16 April 2025. - [Commission Implementing Regulation (EU) 2026/2](https://eur-lex.europa.eu/eli/reg_impl/2026/2/oj?ref=sorena.io) - Official source for the 2 March 2027 application date. - [European Commission: New EU rules to stop destruction of unsold clothes and shoes](https://environment.ec.europa.eu/news/new-eu-rules-stop-destruction-unsold-clothes-and-shoes-2026-02-09_en?ref=sorena.io) - Official summary of the 9 February 2026 unsold-products acts. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. - [What Is the EU ESPR? (Regulation (EU) 2024/1781) | Ecodesign Requirements + Digital Product Passport (DPP) Explained](/artifacts/eu/espr/what-is-espr-and-why-it-matters.md): A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/timeline --- --- title: "What Is the EU ESPR? (Regulation (EU) 2024/1781)" canonical_url: "https://www.sorena.io/artifacts/eu/espr/what-is-espr-and-why-it-matters" source_url: "https://www.sorena.io/artifacts/eu/espr/what-is-espr-and-why-it-matters" author: "Sorena AI" description: "A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters." keywords: - "ESPR Regulation (EU) 2024/1781" - "Ecodesign for Sustainable Products Regulation explained" - "what is ESPR" - "ESPR delegated acts" - "ESPR compliance" - "Digital Product Passport DPP" - "DPP requirements" - "sustainable products regulation EU" - "ESPR" - "Regulation (EU) 2024/1781" - "Digital Product Passport" - "delegated acts" - "ecodesign requirements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # What Is the EU ESPR? (Regulation (EU) 2024/1781) A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. *Explainer* *EU* ## EU ESPR (Regulation (EU) 2024/1781) What It Is and Why It Matters ESPR is the EU framework that turns product sustainability into enforceable design, information, and data obligations. What matters most in practice is not the label of the law but the operating model it forces companies to build. ESPR, Regulation (EU) 2024/1781, is the EU framework for setting ecodesign requirements for sustainable products. It matters because it expands the old energy-related ecodesign model into a broader product-sustainability regime, lets the Commission set both performance and information requirements through delegated acts, creates the Digital Product Passport architecture, and adds separate obligations on unsold consumer products. For companies, that means compliance shifts from isolated product testing to a combination of product design, product data, supplier evidence, and release governance. ## What ESPR is in practical terms The regulation is a framework law. It does not impose the same finished checklist on every product today. Instead, it gives the Commission a structured way to create product-group rules over time. - The law covers almost all physical products, subject to listed exclusions. - Article 4 delegated acts are the instruments that create product-group-specific duties. - Article 5, Article 6, and Article 7 define the kinds of product aspects, performance requirements, and information requirements that can be imposed. - Article 18 forces priority-setting through a published working plan. ## Why ESPR matters more than a normal product-rule update Many product rules change one technical standard or one marking requirement. ESPR changes the operating model behind compliance. That is why it matters to functions well beyond legal and product-compliance teams. - Product teams face new design and lifecycle constraints. - Data teams must support structured, versioned, accessible product information. - Supply-chain teams need repeatable evidence intake and verification. - Commerce and disclosure teams must keep labels, webpages, and DPP outputs aligned. - Leadership teams need a working-plan-based prioritisation model, not reactive fire drills. ## The Digital Product Passport is one of the biggest changes The DPP turns product information into a governed digital service. It is not just a QR code or downloadable PDF. That is why ESPR often becomes a systems program as much as a regulatory one. - The law requires passport data to be accurate, complete, and up to date. - The passport model includes identifiers, data carriers, access rights, and lifecycle controls. - A Commission registry must be set up by 19 July 2026. - Customs and market-surveillance uses are built into the framework. ## What companies should do now The best early work is shared infrastructure that can support multiple future delegated acts. This is where most time can be saved. - Map portfolio scope and carry-over rules. - Create a live delegated-acts watchlist tied to the 2025 to 2030 working plan. - Design DPP and disclosure architecture before product-specific payloads are final. - Create supplier evidence controls and an exportable response pack. - Prepare separate controls for unsold-products disclosure and prohibition duties. *Recommended next step* *Placement: after the scope or definition section* ## Use EU ESPR (Regulation (EU) 2024/1781) What It Is and Why It Matters as a cited research workflow Research Copilot can take EU ESPR (Regulation (EU) 2024/1781) What It Is and Why It Matters from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ESPR (Regulation (EU) 2024/1781) What It Is and Why It Matters](/solutions/research-copilot.md): Start from EU ESPR (Regulation (EU) 2024/1781) What It Is and Why It Matters and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) What It Is and Why It Matters. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for the framework and its main mechanisms. - [European Commission: Ecodesign for Sustainable Products Regulation overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/sustainable-products/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Official Commission explainer for ESPR objectives and implementation. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official current planning baseline for ESPR implementation. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/what-is-espr-and-why-it-matters --- --- title: "What Is the EU ESPR? (Regulation (EU) 2024/1781)" canonical_url: "https://www.sorena.io/artifacts/eu/espr/what-is-espr-and-why-it-matters" source_url: "https://www.sorena.io/artifacts/eu/espr/what-is-espr-and-why-it-matters" author: "Sorena AI" description: "A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters." keywords: - "ESPR Regulation (EU) 2024/1781" - "Ecodesign for Sustainable Products Regulation explained" - "what is ESPR" - "ESPR delegated acts" - "ESPR compliance" - "Digital Product Passport DPP" - "DPP requirements" - "sustainable products regulation EU" - "ESPR" - "Regulation (EU) 2024/1781" - "Digital Product Passport" - "delegated acts" - "ecodesign requirements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # What Is the EU ESPR? (Regulation (EU) 2024/1781) A practical explainer of the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, why it matters. *Explainer* *EU* ## EU ESPR (Regulation (EU) 2024/1781) What It Is and Why It Matters ESPR is the EU framework that turns product sustainability into enforceable design, information, and data obligations. What matters most in practice is not the label of the law but the operating model it forces companies to build. ESPR, Regulation (EU) 2024/1781, is the EU framework for setting ecodesign requirements for sustainable products. It matters because it expands the old energy-related ecodesign model into a broader product-sustainability regime, lets the Commission set both performance and information requirements through delegated acts, creates the Digital Product Passport architecture, and adds separate obligations on unsold consumer products. For companies, that means compliance shifts from isolated product testing to a combination of product design, product data, supplier evidence, and release governance. ## What ESPR is in practical terms The regulation is a framework law. It does not impose the same finished checklist on every product today. Instead, it gives the Commission a structured way to create product-group rules over time. - The law covers almost all physical products, subject to listed exclusions. - Article 4 delegated acts are the instruments that create product-group-specific duties. - Article 5, Article 6, and Article 7 define the kinds of product aspects, performance requirements, and information requirements that can be imposed. - Article 18 forces priority-setting through a published working plan. ## Why ESPR matters more than a normal product-rule update Many product rules change one technical standard or one marking requirement. ESPR changes the operating model behind compliance. That is why it matters to functions well beyond legal and product-compliance teams. - Product teams face new design and lifecycle constraints. - Data teams must support structured, versioned, accessible product information. - Supply-chain teams need repeatable evidence intake and verification. - Commerce and disclosure teams must keep labels, webpages, and DPP outputs aligned. - Leadership teams need a working-plan-based prioritisation model, not reactive fire drills. ## The Digital Product Passport is one of the biggest changes The DPP turns product information into a governed digital service. It is not just a QR code or downloadable PDF. That is why ESPR often becomes a systems program as much as a regulatory one. - The law requires passport data to be accurate, complete, and up to date. - The passport model includes identifiers, data carriers, access rights, and lifecycle controls. - A Commission registry must be set up by 19 July 2026. - Customs and market-surveillance uses are built into the framework. ## What companies should do now The best early work is shared infrastructure that can support multiple future delegated acts. This is where most time can be saved. - Map portfolio scope and carry-over rules. - Create a live delegated-acts watchlist tied to the 2025 to 2030 working plan. - Design DPP and disclosure architecture before product-specific payloads are final. - Create supplier evidence controls and an exportable response pack. - Prepare separate controls for unsold-products disclosure and prohibition duties. *Recommended next step* *Placement: after the scope or definition section* ## Use EU ESPR (Regulation (EU) 2024/1781) What It Is and Why It Matters as a cited research workflow Research Copilot can take EU ESPR (Regulation (EU) 2024/1781) What It Is and Why It Matters from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU ESPR (Regulation (EU) 2024/1781) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU ESPR (Regulation (EU) 2024/1781) What It Is and Why It Matters](/solutions/research-copilot.md): Start from EU ESPR (Regulation (EU) 2024/1781) What It Is and Why It Matters and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU ESPR (Regulation (EU) 2024/1781)](/contact.md): Review your current process, evidence gaps, and next steps for EU ESPR (Regulation (EU) 2024/1781) What It Is and Why It Matters. ## Primary sources - [Regulation (EU) 2024/1781 (ESPR) - Official Journal via ELI](https://data.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for the framework and its main mechanisms. - [European Commission: Ecodesign for Sustainable Products Regulation overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/sustainable-products/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Official Commission explainer for ESPR objectives and implementation. - [Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025-2030](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=celex:52025DC0187&ref=sorena.io) - Official current planning baseline for ESPR implementation. ## Related Topic Guides - [ESPR and Digital Product Passport (DPP) Connection | How to Turn Information Requirements into a DPP System](/artifacts/eu/espr/espr-and-dpp-connection.md): Understand how ESPR turns Digital Product Passport into an operational system: Article 9 passport duties, Article 10 essential requirements. - [ESPR Applicability Test (Regulation (EU) 2024/1781) | Is My Product In Scope + What to Do Next](/artifacts/eu/espr/applicability-test.md): A practical applicability test for the EU Ecodesign for Sustainable Products Regulation. - [ESPR Compliance Program Operating Model | RACI, Cadence, Delegated Acts Intake, DPP Data Governance, Evidence Exports](/artifacts/eu/espr/compliance-program-operating-model.md): Build an ESPR operating model around Regulation (EU) 2024/1781: role clarity, watchlist intake, delegated-act delivery, DPP governance. - [ESPR Delegated Acts Watchlist | How to Monitor Product Group Measures + Turn Signals into Delivery Plans](/artifacts/eu/espr/espr-delegated-acts-watchlist.md): A practical delegated acts watchlist for EU ESPR (Regulation (EU) 2024/1781): what to monitor, how to structure your watchlist, how to run impact assessments. - [ESPR Information Requirements, Labeling, and Disclosure | Digital Product Passport (DPP), QR Codes, Data Governance, Evidence](/artifacts/eu/espr/information-requirements-labeling-and-disclosure.md): A grounded guide to ESPR information requirements, labels, and disclosure: Article 7 information duties, Article 9 DPP requirements. - [ESPR Penalties and Enforcement | Market Surveillance Readiness, Evidence Export Pack, and Risk Reduction Controls](/artifacts/eu/espr/penalties-and-fines.md): A grounded ESPR penalties and enforcement guide covering Article 74 penalties, market-surveillance workflows, corrective action, DPP and registry evidence. - [ESPR Product Priorities + Delegated Acts Tracker | Portfolio Mapping, Readiness Scoring, and DPP Delivery Planning](/artifacts/eu/espr/product-priorities-and-delegated-acts-tracker.md): A practical tracker for ESPR product priorities and delegated acts: map product families to likely product groups, score readiness (data, suppliers, DPP). - [ESPR Timeline (Regulation (EU) 2024/1781) | Key Milestones + How to Build a Delegated Acts Delivery Calendar](/artifacts/eu/espr/timeline.md): A practical ESPR timeline guide built around the known milestones in Regulation (EU) 2024/1781: entry into force on 18 July 2024. - [ESPR vs Ecodesign Directive (2009/125/EC) | What Changes Under Regulation (EU) 2024/1781 + How to Prepare](/artifacts/eu/espr/espr-vs-ecodesign-directive.md): Compare ESPR with the older Ecodesign Directive 2009/125/EC: broader scope, direct-applicability as a regulation, Article 18 working plans. - [ESPR vs PPWR | Product Sustainability Requirements vs Packaging Rules + How to Align Data, DPP, and Evidence](/artifacts/eu/espr/espr-vs-ppwr.md): Compare ESPR and PPWR with a practical implementation lens: product design versus packaging design. - [EU ESPR Checklist (Regulation (EU) 2024/1781) | Delegated Acts, DPP Readiness, Information Requirements, Evidence Pack](/artifacts/eu/espr/checklist.md): An audit-ready ESPR checklist covering Article 1 scoping, Article 18 product-priority screening, delegated-acts monitoring. - [EU ESPR Compliance Guide (Regulation (EU) 2024/1781) | Program Setup, Delegated Acts Delivery, DPP Readiness, Evidence](/artifacts/eu/espr/compliance.md): An implementation-oriented ESPR compliance guide for Regulation (EU) 2024/1781 covering scope, delegated-act intake, DPP readiness, supplier verification. - [EU ESPR Deadlines and Compliance Calendar | Delegated Acts Timeline, DPP Milestones, Supplier Onboarding, Evidence Exports](/artifacts/eu/espr/deadlines-and-compliance-calendar.md): A practical ESPR compliance calendar built around the current law baseline and the real implementation milestones: entry into force on 18 July 2024. - [EU ESPR FAQ (Regulation (EU) 2024/1781) | Delegated Acts, DPP, Scope, and Implementation Questions](/artifacts/eu/espr/faq.md): Frequently asked questions about the EU Ecodesign for Sustainable Products Regulation (ESPR), Regulation (EU) 2024/1781: what it is, how delegated acts work. - [EU ESPR Requirements (Regulation (EU) 2024/1781) | What to Build Before Delegated Acts Land: Controls, DPP Data, Evidence](/artifacts/eu/espr/requirements.md): A practical ESPR requirements guide: understand the framework regulation (EU) 2024/1781. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/espr/what-is-espr-and-why-it-matters --- --- title: "GDPR Applicability Test (Article 2-3)" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/gdpr/applicability-test" author: "Sorena AI" description: "A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting." keywords: - "GDPR applicability test" - "GDPR territorial scope Article 3" - "GDPR material scope Article 2" - "GDPR establishment criterion" - "GDPR targeting criterion" - "GDPR representative Article 27" - "controller vs processor GDPR" - "GDPR applicability" - "territorial scope" - "Article 3" - "controller vs processor" - "representative" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR Applicability Test (Article 2-3) A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. *Applicability Test* *EU* ## EU GDPR Applicability Test Decide whether GDPR applies, which role you have, and what to document. Focus: Article 2 (material scope), Article 3 (territorial scope), Article 27 (representative), and practical outcomes. A GDPR applicability decision must be defensible: it should be tied to facts (where processing happens, who is established, and what data subjects you target) and it should produce a concrete output (what controls and evidence you need). This page provides an execution-ready applicability test and the deliverables that make the decision auditable. ## Step 1 - Material scope (Article 2): are you processing personal data? Start with the core question: is there processing of personal data (automated or part of a filing system) in your activity? Then validate whether any Article 2 exclusions are relevant (these often appear in public sector or law enforcement contexts). - List processing activities (products, HR, marketing, analytics, support, vendor operations). - Identify data categories (identifiers, usage, location, sensitive/special category). - Check for exclusions in Article 2(2) and document your reasoning if you rely on one. ## Step 2 - Territorial scope (Article 3): establishment vs targeting Article 3 has three key paths: (1) processing in the context of an EU establishment, (2) targeting EU data subjects (goods/services or monitoring behavior), and (3) Member State law applying by public international law. Your goal is not to win a debate-it's to map facts to the Article 3 path and keep evidence of that mapping. - Establishment criterion (Article 3(1)): document EU presence and whether processing is in the context of EU activities. - Targeting criterion (Article 3(2)): document intentional offering of goods/services to EU data subjects or monitoring behavior in the EU. - Representative (Article 27): if you're not established in the EU but Article 3(2) applies, assess representative obligations and exceptions. ## Step 3 - Role mapping: controller vs processor (what changes in practice) Role mapping is a control design step: it determines who owns transparency, DSAR handling, DPIAs, and vendor oversight. Most failures happen when teams label themselves a processor but behave like a controller, or the reverse. - Controller: determines purposes and essential means; owns lawful basis, notices, DSAR outcomes, and DPIA decisions. - Processor: processes on behalf of a controller; must follow Article 28 contract requirements and implement appropriate security. - Joint controllers: if purposes/means are decided together, you likely need a joint-controller arrangement and allocation of responsibilities. ## Borderline scenarios (fast checks that prevent scope mistakes) Use these as red flag prompts in scoping workshops. If any apply, you likely need deeper analysis and stronger documentation. - US company with EU customers and localized EU marketing pages (targeting signals). - Analytics/behavioral monitoring of EU visitors for profiling or advertising (monitoring). - EU-based employees or contractors with HR systems hosted outside the EU (establishment context + transfers). - B2B SaaS with EU accounts where usage data and support tickets include personal data. - Vendor ecosystem where sub-processors are in third countries (transfer chain risk). ## Outputs: what you should produce after the applicability test A good applicability test ends with artifacts, not a sentence. These outputs are what make the decision explainable and actionable. - Applicability memo: the Article 3 path (with facts and evidence) and the role mapping per processing activity. - Processing inventory scope baseline: which systems and teams are in scope now. - Control backlog: DSAR workflow, breach playbook, DPIA triggers, transfer safeguards, vendor contract updates. - Evidence index: where your key compliance evidence lives and how fast it can be exported. *Recommended next step* *Placement: after the applicability result* ## Turn EU GDPR Applicability Test into an operational assessment Assessment Autopilot can take EU GDPR Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GDPR Applicability Test](/solutions/assessment.md): Start from EU GDPR Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Applicability Test. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary legal text for Articles 2, 3, and 27. - [EDPB Guidelines 3/2018 on territorial scope](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-32018-territorial-scope-gdpr-article-3-version_en?ref=sorena.io) - Official guidance on establishment, targeting, and monitoring under Article 3. - [EDPB Guidelines 07/2020 on controller and processor concepts](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor-gdpr_en?ref=sorena.io) - Official guidance for role mapping once scope is established. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/applicability-test --- --- title: "GDPR Applicability Test (Article 2-3)" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/gdpr/applicability-test" author: "Sorena AI" description: "A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting." keywords: - "GDPR applicability test" - "GDPR territorial scope Article 3" - "GDPR material scope Article 2" - "GDPR establishment criterion" - "GDPR targeting criterion" - "GDPR representative Article 27" - "controller vs processor GDPR" - "GDPR applicability" - "territorial scope" - "Article 3" - "controller vs processor" - "representative" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR Applicability Test (Article 2-3) A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. *Applicability Test* *EU* ## EU GDPR Applicability Test Decide whether GDPR applies, which role you have, and what to document. Focus: Article 2 (material scope), Article 3 (territorial scope), Article 27 (representative), and practical outcomes. A GDPR applicability decision must be defensible: it should be tied to facts (where processing happens, who is established, and what data subjects you target) and it should produce a concrete output (what controls and evidence you need). This page provides an execution-ready applicability test and the deliverables that make the decision auditable. ## Step 1 - Material scope (Article 2): are you processing personal data? Start with the core question: is there processing of personal data (automated or part of a filing system) in your activity? Then validate whether any Article 2 exclusions are relevant (these often appear in public sector or law enforcement contexts). - List processing activities (products, HR, marketing, analytics, support, vendor operations). - Identify data categories (identifiers, usage, location, sensitive/special category). - Check for exclusions in Article 2(2) and document your reasoning if you rely on one. ## Step 2 - Territorial scope (Article 3): establishment vs targeting Article 3 has three key paths: (1) processing in the context of an EU establishment, (2) targeting EU data subjects (goods/services or monitoring behavior), and (3) Member State law applying by public international law. Your goal is not to win a debate-it's to map facts to the Article 3 path and keep evidence of that mapping. - Establishment criterion (Article 3(1)): document EU presence and whether processing is in the context of EU activities. - Targeting criterion (Article 3(2)): document intentional offering of goods/services to EU data subjects or monitoring behavior in the EU. - Representative (Article 27): if you're not established in the EU but Article 3(2) applies, assess representative obligations and exceptions. ## Step 3 - Role mapping: controller vs processor (what changes in practice) Role mapping is a control design step: it determines who owns transparency, DSAR handling, DPIAs, and vendor oversight. Most failures happen when teams label themselves a processor but behave like a controller, or the reverse. - Controller: determines purposes and essential means; owns lawful basis, notices, DSAR outcomes, and DPIA decisions. - Processor: processes on behalf of a controller; must follow Article 28 contract requirements and implement appropriate security. - Joint controllers: if purposes/means are decided together, you likely need a joint-controller arrangement and allocation of responsibilities. ## Borderline scenarios (fast checks that prevent scope mistakes) Use these as red flag prompts in scoping workshops. If any apply, you likely need deeper analysis and stronger documentation. - US company with EU customers and localized EU marketing pages (targeting signals). - Analytics/behavioral monitoring of EU visitors for profiling or advertising (monitoring). - EU-based employees or contractors with HR systems hosted outside the EU (establishment context + transfers). - B2B SaaS with EU accounts where usage data and support tickets include personal data. - Vendor ecosystem where sub-processors are in third countries (transfer chain risk). ## Outputs: what you should produce after the applicability test A good applicability test ends with artifacts, not a sentence. These outputs are what make the decision explainable and actionable. - Applicability memo: the Article 3 path (with facts and evidence) and the role mapping per processing activity. - Processing inventory scope baseline: which systems and teams are in scope now. - Control backlog: DSAR workflow, breach playbook, DPIA triggers, transfer safeguards, vendor contract updates. - Evidence index: where your key compliance evidence lives and how fast it can be exported. *Recommended next step* *Placement: after the applicability result* ## Turn EU GDPR Applicability Test into an operational assessment Assessment Autopilot can take EU GDPR Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GDPR Applicability Test](/solutions/assessment.md): Start from EU GDPR Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Applicability Test. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary legal text for Articles 2, 3, and 27. - [EDPB Guidelines 3/2018 on territorial scope](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-32018-territorial-scope-gdpr-article-3-version_en?ref=sorena.io) - Official guidance on establishment, targeting, and monitoring under Article 3. - [EDPB Guidelines 07/2020 on controller and processor concepts](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor-gdpr_en?ref=sorena.io) - Official guidance for role mapping once scope is established. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/applicability-test --- --- title: "GDPR Breach Notification (72 Hours)" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/breach-notification-72-hours" source_url: "https://www.sorena.io/artifacts/eu/gdpr/breach-notification-72-hours" author: "Sorena AI" description: "An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines." keywords: - "GDPR breach notification 72 hours" - "Article 33 notification" - "Article 34 communication" - "GDPR awareness timestamp" - "personal data breach definition" - "phased breach notification" - "breach risk assessment GDPR" - "GDPR breach notification" - "Article 33" - "Article 34" - "72 hours" - "incident response" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR Breach Notification (72 Hours) An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. *Incident Playbook* *EU* ## EU GDPR 72-hour Breach Notification Breach notification under GDPR depends on timekeeping discipline, risk logic, and evidence quality. Use controller awareness, phased notifications, and Article 34 exception analysis to keep the workflow defensible. GDPR breach response works only if controller and processor obligations are separated clearly and the timeline is documented from the first signal forward. The processor must notify the controller without undue delay. The controller then decides whether the incident is a personal data breach, whether it is likely to result in a risk to rights and freedoms, whether supervisory-authority notification is required within 72 hours, and whether Article 34 communication to affected individuals is necessary. The evidence file has to show that logic, not just the final conclusion. ## 1) Classification and controller awareness The 72-hour clock is tied to controller awareness, so the workflow needs a precise awareness rule and a record of who made the call. Do not confuse first suspicion, processor escalation, and controller awareness. - Define the minimum fact pattern for awareness and record it in the incident log. - Record when the processor informed the controller and what information was available at that point. - Separate confidentiality, integrity, and availability impacts so risk can be assessed consistently. - Preserve the evolving incident timeline because phased notifications are expressly allowed when all facts are not yet available. ## 2) Article 33 supervisory-authority notification Notification is required unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. That means the controller needs a repeatable risk rubric, not an improvised legal debate. - Assess categories of personal data, number of affected individuals, ease of identification, likely consequences, and the effectiveness of technical mitigations such as encryption. - If notification is required, capture the nature of the breach, likely consequences, measures taken, and the contact point for follow-up. - If complete information is not yet available, send the initial notification and supplement it without undue delay. - If the controller decides not to notify, keep the written rationale as part of the breach register. *Recommended next step* *Placement: after the workflow or playbook section* ## Turn EU GDPR 72-hour Breach Notification into an operational assessment Assessment Autopilot can take EU GDPR 72-hour Breach Notification from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GDPR 72-hour Breach Notification](/solutions/assessment.md): Start from EU GDPR 72-hour Breach Notification and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR 72-hour Breach Notification. ## 3) Article 34 communication to individuals Article 34 is about likely high risk, which is a narrower and more serious threshold than Article 33 risk. You need explicit reasoning for both the communication decision and any exception relied upon. - Document whether the breach creates likely high risk, for example fraud, identity theft, discrimination, or safety impact. - Check the Article 34 exceptions, including effective technical protection, measures that remove the high risk, or disproportionate effort paired with public communication. - Prepare plain-language templates that explain the breach, the likely consequences, and the steps individuals should take. - Keep the approval chain and the communication channel log as part of the incident evidence pack. ## 4) Processor, vendor, and sub-processor readiness Many breach failures are really Article 28 failures. The processor contract does not just allocate risk, it determines how fast the controller can make a lawful notification decision. Make the breach workflow visible in vendor diligence and contracts. - Require processors to notify without undue delay and provide structured facts, not generic alerts. - Define escalation routes, named contacts, and evidence items expected from processors and sub-processors. - Align incident-reporting clauses with the controller breach workflow and regulator deadlines. - Test the process with key vendors rather than assuming the DPA wording is enough. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for Articles 33 and 34. - [EDPB Guidelines 9/2022 on personal data breach notification under GDPR](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-92022-personal-data-breach-notification-under-gdpr_en?ref=sorena.io) - Official EDPB guidance on awareness, risk assessment, and notification practice. - [European Commission Implementing Decision (EU) 2021/915](https://eur-lex.europa.eu/eli/dec_impl/2021/915/oj/eng?ref=sorena.io) - Official controller-processor clauses that include breach-assistance mechanics. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/breach-notification-72-hours --- --- title: "GDPR Breach Notification (72 Hours)" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/breach-notification-72-hours" source_url: "https://www.sorena.io/artifacts/eu/gdpr/breach-notification-72-hours" author: "Sorena AI" description: "An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines." keywords: - "GDPR breach notification 72 hours" - "Article 33 notification" - "Article 34 communication" - "GDPR awareness timestamp" - "personal data breach definition" - "phased breach notification" - "breach risk assessment GDPR" - "GDPR breach notification" - "Article 33" - "Article 34" - "72 hours" - "incident response" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR Breach Notification (72 Hours) An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. *Incident Playbook* *EU* ## EU GDPR 72-hour Breach Notification Breach notification under GDPR depends on timekeeping discipline, risk logic, and evidence quality. Use controller awareness, phased notifications, and Article 34 exception analysis to keep the workflow defensible. GDPR breach response works only if controller and processor obligations are separated clearly and the timeline is documented from the first signal forward. The processor must notify the controller without undue delay. The controller then decides whether the incident is a personal data breach, whether it is likely to result in a risk to rights and freedoms, whether supervisory-authority notification is required within 72 hours, and whether Article 34 communication to affected individuals is necessary. The evidence file has to show that logic, not just the final conclusion. ## 1) Classification and controller awareness The 72-hour clock is tied to controller awareness, so the workflow needs a precise awareness rule and a record of who made the call. Do not confuse first suspicion, processor escalation, and controller awareness. - Define the minimum fact pattern for awareness and record it in the incident log. - Record when the processor informed the controller and what information was available at that point. - Separate confidentiality, integrity, and availability impacts so risk can be assessed consistently. - Preserve the evolving incident timeline because phased notifications are expressly allowed when all facts are not yet available. ## 2) Article 33 supervisory-authority notification Notification is required unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. That means the controller needs a repeatable risk rubric, not an improvised legal debate. - Assess categories of personal data, number of affected individuals, ease of identification, likely consequences, and the effectiveness of technical mitigations such as encryption. - If notification is required, capture the nature of the breach, likely consequences, measures taken, and the contact point for follow-up. - If complete information is not yet available, send the initial notification and supplement it without undue delay. - If the controller decides not to notify, keep the written rationale as part of the breach register. *Recommended next step* *Placement: after the workflow or playbook section* ## Turn EU GDPR 72-hour Breach Notification into an operational assessment Assessment Autopilot can take EU GDPR 72-hour Breach Notification from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GDPR 72-hour Breach Notification](/solutions/assessment.md): Start from EU GDPR 72-hour Breach Notification and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR 72-hour Breach Notification. ## 3) Article 34 communication to individuals Article 34 is about likely high risk, which is a narrower and more serious threshold than Article 33 risk. You need explicit reasoning for both the communication decision and any exception relied upon. - Document whether the breach creates likely high risk, for example fraud, identity theft, discrimination, or safety impact. - Check the Article 34 exceptions, including effective technical protection, measures that remove the high risk, or disproportionate effort paired with public communication. - Prepare plain-language templates that explain the breach, the likely consequences, and the steps individuals should take. - Keep the approval chain and the communication channel log as part of the incident evidence pack. ## 4) Processor, vendor, and sub-processor readiness Many breach failures are really Article 28 failures. The processor contract does not just allocate risk, it determines how fast the controller can make a lawful notification decision. Make the breach workflow visible in vendor diligence and contracts. - Require processors to notify without undue delay and provide structured facts, not generic alerts. - Define escalation routes, named contacts, and evidence items expected from processors and sub-processors. - Align incident-reporting clauses with the controller breach workflow and regulator deadlines. - Test the process with key vendors rather than assuming the DPA wording is enough. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for Articles 33 and 34. - [EDPB Guidelines 9/2022 on personal data breach notification under GDPR](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-92022-personal-data-breach-notification-under-gdpr_en?ref=sorena.io) - Official EDPB guidance on awareness, risk assessment, and notification practice. - [European Commission Implementing Decision (EU) 2021/915](https://eur-lex.europa.eu/eli/dec_impl/2021/915/oj/eng?ref=sorena.io) - Official controller-processor clauses that include breach-assistance mechanics. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/breach-notification-72-hours --- --- title: "EU GDPR Checklist (Regulation (EU) 2016/679)" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/checklist" source_url: "https://www.sorena.io/artifacts/eu/gdpr/checklist" author: "Sorena AI" description: "An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures." keywords: - "GDPR checklist" - "GDPR compliance checklist" - "GDPR audit checklist" - "GDPR readiness checklist" - "GDPR DSAR checklist" - "GDPR DPIA checklist" - "GDPR SCC checklist" - "GDPR processor contract checklist" - "audit readiness" - "DSAR" - "DPIA" - "international transfers" - "vendor management" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GDPR Checklist (Regulation (EU) 2016/679) An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. *Checklist* *EU* ## EU GDPR Checklist A checklist designed for execution: owners, evidence, acceptance criteria. Use it to build a compliance program that is provable under pressure. GDPR is not a policy exercise. It is a set of controls, registers, and timed workflows that need to survive product change, vendor change, transfer change, and incident pressure. This checklist is strongest when used as a program backbone: scope and role mapping, lawful-basis control, rights workflows, RoPA upkeep, DPIA governance, breach readiness, vendor clauses, transfer packs, and a single evidence index. ## 1) Scope, roles, and inventory (foundation) Goal: a defensible applicability decision and a processing inventory baseline. If you cannot explain scope, everything else becomes inconsistent. - Article 2-3 applicability memo (material + territorial scope) with facts and evidence. - Role mapping per activity: controller vs processor vs joint controller (owners and obligations). - Processing inventory: systems, data categories, purposes, recipients, and retention (baseline). ## 2) Lawful basis, consent, and transparency (make the legal model real) Goal: each processing purpose has a lawful basis and a corresponding transparency record. Avoid lawful basis drift where teams change the purpose but keep the old basis. - Lawful basis map per purpose (Article 6) with decision rationale and owner. - Consent design (where used): capture, withdrawal, versioning (Article 7) + consent proof schema. - Privacy notices and layered transparency (Articles 12-14) tied to product flows and data collection points. ## 3) DSAR workflow (Articles 12-22) - operationalize requests Goal: DSAR handling is measurable, consistent, and explainable across systems and vendors. DSAR failures are usually process failures: intake, identity checks, search scope, and deadline tracking. - DSAR intake channels and identity verification rules with abuse protections. - Search playbook: systems to search, log formats, and response format standards. - SLA tracking: 1-month target + extension criteria and notification templates. - Evidence: request logs, decisions, response packages, and escalation approvals. ## 4) DPIA and risk management (Articles 35-36) - high-risk governance Goal: identify high-risk processing early and control it with documented assessments. DPIAs must be usable by engineering teams: controls, mitigations, and residual risk decisions. - DPIA triggers and screening checklist; DPIA template and review workflow. - Mitigation tracking linked to product backlog (privacy by design controls). - If needed: prior consultation process artifacts and decision records. - Evidence: DPIA register, approvals, and residual risk sign-offs. ## 5) Security of processing + breach response (Articles 32-34) Goal: security controls are mapped to personal data processing risks and are testable. Breach response must be executable: awareness timekeeping, risk tests, and notification templates. - Security controls mapped to data and threats (access control, encryption, logging, monitoring). - Breach workflow: classification, awareness timestamp, Article 33 risk test, Article 34 high-risk test. - Evidence pack: incident timeline, logs, decisions, communications, and remediation. ## 6) Vendor/processor contracts (Article 28) + ongoing vendor governance Goal: vendor contracts and oversight reflect actual processing and transfer reality. A signed DPA without operational controls is a common enforcement failure. - Article 28 contract clauses present and tailored to processing reality (sub-processors, audits, security). - Vendor inventory mapped to processing purposes, data categories, and transfer destinations. - Ongoing monitoring: SOC/ISO evidence, incident reporting, sub-processor change notifications. ## 7) International transfers (Chapter V) - SCCs, TIA, supplementary measures Goal: Chapter V compliance is engineered: transfer map, mechanism choice, and operational controls. Treat SCCs as an implementation project: configuration, logging, and governance-not a legal PDF. - Transfer map: exporters/importers, data categories, destinations, and onward transfers. - Mechanism selection: adequacy vs SCCs vs other safeguards; document decisions. - TIA + supplementary measures playbook; evidence of implementation and monitoring. ## Evidence index (the fastest way to be audit-ready) Goal: export evidence quickly and consistently. Aim for coherence, not volume. - Scope memo + role mapping + processing inventory baseline. - Lawful basis map + notice versions + consent logs (if applicable). - DSAR logs + response packages + search playbooks. - DPIA register + mitigations + approvals. - Breach playbook + incident logs + notification artifacts. - Vendor contracts + sub-processor list + audit evidence. - Transfer map + SCC packs + TIA + supplementary measures evidence. *Recommended next step* *Placement: after the checklist block* ## Turn EU GDPR Checklist into an operational assessment Assessment Autopilot can take EU GDPR Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GDPR Checklist](/solutions/assessment.md): Start from EU GDPR Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Checklist. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary legal baseline for the checklist. - [EDPB Guidelines 01/2022 on the right of access](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-012022-data-subject-rights-right-access_en?ref=sorena.io) - Useful official guide for DSAR workflow design. - [EDPB Guidelines 9/2022 on breach notification](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-92022-personal-data-breach-notification-under-gdpr_en?ref=sorena.io) - Useful official guide for incident workflow design. - [European Commission: Standard Contractual Clauses overview](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en?ref=sorena.io) - Official transfer-tool baseline for Chapter V checklist items. ## Related Topic Guides - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/checklist --- --- title: "EU GDPR Checklist (Regulation (EU) 2016/679)" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/checklist" source_url: "https://www.sorena.io/artifacts/eu/gdpr/checklist" author: "Sorena AI" description: "An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures." keywords: - "GDPR checklist" - "GDPR compliance checklist" - "GDPR audit checklist" - "GDPR readiness checklist" - "GDPR DSAR checklist" - "GDPR DPIA checklist" - "GDPR SCC checklist" - "GDPR processor contract checklist" - "audit readiness" - "DSAR" - "DPIA" - "international transfers" - "vendor management" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GDPR Checklist (Regulation (EU) 2016/679) An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. *Checklist* *EU* ## EU GDPR Checklist A checklist designed for execution: owners, evidence, acceptance criteria. Use it to build a compliance program that is provable under pressure. GDPR is not a policy exercise. It is a set of controls, registers, and timed workflows that need to survive product change, vendor change, transfer change, and incident pressure. This checklist is strongest when used as a program backbone: scope and role mapping, lawful-basis control, rights workflows, RoPA upkeep, DPIA governance, breach readiness, vendor clauses, transfer packs, and a single evidence index. ## 1) Scope, roles, and inventory (foundation) Goal: a defensible applicability decision and a processing inventory baseline. If you cannot explain scope, everything else becomes inconsistent. - Article 2-3 applicability memo (material + territorial scope) with facts and evidence. - Role mapping per activity: controller vs processor vs joint controller (owners and obligations). - Processing inventory: systems, data categories, purposes, recipients, and retention (baseline). ## 2) Lawful basis, consent, and transparency (make the legal model real) Goal: each processing purpose has a lawful basis and a corresponding transparency record. Avoid lawful basis drift where teams change the purpose but keep the old basis. - Lawful basis map per purpose (Article 6) with decision rationale and owner. - Consent design (where used): capture, withdrawal, versioning (Article 7) + consent proof schema. - Privacy notices and layered transparency (Articles 12-14) tied to product flows and data collection points. ## 3) DSAR workflow (Articles 12-22) - operationalize requests Goal: DSAR handling is measurable, consistent, and explainable across systems and vendors. DSAR failures are usually process failures: intake, identity checks, search scope, and deadline tracking. - DSAR intake channels and identity verification rules with abuse protections. - Search playbook: systems to search, log formats, and response format standards. - SLA tracking: 1-month target + extension criteria and notification templates. - Evidence: request logs, decisions, response packages, and escalation approvals. ## 4) DPIA and risk management (Articles 35-36) - high-risk governance Goal: identify high-risk processing early and control it with documented assessments. DPIAs must be usable by engineering teams: controls, mitigations, and residual risk decisions. - DPIA triggers and screening checklist; DPIA template and review workflow. - Mitigation tracking linked to product backlog (privacy by design controls). - If needed: prior consultation process artifacts and decision records. - Evidence: DPIA register, approvals, and residual risk sign-offs. ## 5) Security of processing + breach response (Articles 32-34) Goal: security controls are mapped to personal data processing risks and are testable. Breach response must be executable: awareness timekeeping, risk tests, and notification templates. - Security controls mapped to data and threats (access control, encryption, logging, monitoring). - Breach workflow: classification, awareness timestamp, Article 33 risk test, Article 34 high-risk test. - Evidence pack: incident timeline, logs, decisions, communications, and remediation. ## 6) Vendor/processor contracts (Article 28) + ongoing vendor governance Goal: vendor contracts and oversight reflect actual processing and transfer reality. A signed DPA without operational controls is a common enforcement failure. - Article 28 contract clauses present and tailored to processing reality (sub-processors, audits, security). - Vendor inventory mapped to processing purposes, data categories, and transfer destinations. - Ongoing monitoring: SOC/ISO evidence, incident reporting, sub-processor change notifications. ## 7) International transfers (Chapter V) - SCCs, TIA, supplementary measures Goal: Chapter V compliance is engineered: transfer map, mechanism choice, and operational controls. Treat SCCs as an implementation project: configuration, logging, and governance-not a legal PDF. - Transfer map: exporters/importers, data categories, destinations, and onward transfers. - Mechanism selection: adequacy vs SCCs vs other safeguards; document decisions. - TIA + supplementary measures playbook; evidence of implementation and monitoring. ## Evidence index (the fastest way to be audit-ready) Goal: export evidence quickly and consistently. Aim for coherence, not volume. - Scope memo + role mapping + processing inventory baseline. - Lawful basis map + notice versions + consent logs (if applicable). - DSAR logs + response packages + search playbooks. - DPIA register + mitigations + approvals. - Breach playbook + incident logs + notification artifacts. - Vendor contracts + sub-processor list + audit evidence. - Transfer map + SCC packs + TIA + supplementary measures evidence. *Recommended next step* *Placement: after the checklist block* ## Turn EU GDPR Checklist into an operational assessment Assessment Autopilot can take EU GDPR Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GDPR Checklist](/solutions/assessment.md): Start from EU GDPR Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Checklist. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary legal baseline for the checklist. - [EDPB Guidelines 01/2022 on the right of access](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-012022-data-subject-rights-right-access_en?ref=sorena.io) - Useful official guide for DSAR workflow design. - [EDPB Guidelines 9/2022 on breach notification](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-92022-personal-data-breach-notification-under-gdpr_en?ref=sorena.io) - Useful official guide for incident workflow design. - [European Commission: Standard Contractual Clauses overview](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en?ref=sorena.io) - Official transfer-tool baseline for Chapter V checklist items. ## Related Topic Guides - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/checklist --- --- title: "EU GDPR Compliance Guide" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/compliance" source_url: "https://www.sorena.io/artifacts/eu/gdpr/compliance" author: "Sorena AI" description: "An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports." keywords: - "GDPR compliance guide" - "GDPR compliance program" - "GDPR implementation guide" - "GDPR roadmap" - "GDPR operating model" - "GDPR evidence pack" - "GDPR compliance" - "operating model" - "DSAR" - "DPIA" - "breach response" - "transfers" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GDPR Compliance Guide An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. *Compliance Playbook* *EU* ## EU GDPR Compliance A practical program blueprint: owners, workflows, evidence, cadence. Focus: build repeatable DSAR, breach, DPIA, vendor, and transfer controls. GDPR compliance is a live operating system for personal-data processing. The most resilient programs share a single evidence spine across scope, lawful basis, DSARs, breaches, DPIAs, vendors, RoPAs, and transfers, and they review changes through a repeatable cadence rather than a one-time remediation project. That is what keeps the program coherent when products, vendors, and regulatory expectations evolve. ## Program structure: 5 workstreams that must be connected GDPR becomes manageable when responsibilities are explicit and artifacts are shared across teams. Most compliance failures are interface bugs between these workstreams. - Inventory & scope: applicability memo, role mapping, processing inventory, RoPA fields and owners. - Legal model: lawful basis map, transparency record, consent model (where used), retention rules. - Operational workflows: DSAR intake/search/response, breach response, DPIA screening and review. - Vendors & transfers: Article 28 contracts, sub-processor governance, transfer map, SCC/TIA packs. - Assurance & evidence: validation checks, logs, versioning, and exportable evidence index. ## Delivery pipeline: how to turn requirements into shipped controls Treat GDPR like product delivery: requirements -> acceptance criteria -> implementation -> tests -> evidence export. This approach prevents policy drift and makes audits faster. - Define acceptance criteria for each workflow (DSAR, breach, DPIA, transfers). - Build automation where possible: DSAR tracking, breach evidence capture, transfer mapping. - Version key artifacts: notices, consent wording, DPIA templates, SCC packs, vendor DPAs. ## Operating cadence (minimum rhythm that works) A governance rhythm prevents surprises and keeps evidence fresh. Use cadence to enforce consistency across business units and vendors. - Weekly: DSAR queue review and escalations; active incident tracking. - Monthly: vendor and transfer changes review (new vendors, sub-processors, new destinations). - Quarterly: DPIA review and high-risk processing inventory refresh; notice and consent version audit. - Semi-annual: tabletop exercises (DSAR and breach) + evidence export drills (time-to-export SLA). ## Evidence index (what audit-ready means in practice) Audit readiness is the ability to export coherent evidence quickly. Build an evidence index and keep it current. Aim for a single index that links each requirement area to artifacts and owners. - Applicability memo + role mapping + processing inventory baseline. - Lawful basis decisions + notices + consent logs and withdrawal logs (if applicable). - DSAR logs + response packages + search playbooks and identity verification rules. - DPIA register + mitigations + residual risk approvals. - Breach response artifacts + awareness timestamps + notifications (if sent). - Vendor DPAs + sub-processor lists + security evidence + transfer packs. *Recommended next step* *Placement: after the compliance steps* ## Turn EU GDPR Compliance into an operational assessment Assessment Autopilot can take EU GDPR Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GDPR Compliance](/solutions/assessment.md): Start from EU GDPR Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Compliance. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for the overall operating model. - [ENISA Handbook on the security of personal data processing](https://www.enisa.europa.eu/publications/handbook-on-security-of-personal-data-processing?ref=sorena.io) - Useful official guidance for operational security controls. - [Irish DPC guidance on Records of Processing under Article 30](https://www.dataprotection.ie/en/dpc-guidance/records-of-processing-article-30-guidance?ref=sorena.io) - Useful accountability guidance for keeping the evidence spine current. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/compliance --- --- title: "EU GDPR Compliance Guide" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/compliance" source_url: "https://www.sorena.io/artifacts/eu/gdpr/compliance" author: "Sorena AI" description: "An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports." keywords: - "GDPR compliance guide" - "GDPR compliance program" - "GDPR implementation guide" - "GDPR roadmap" - "GDPR operating model" - "GDPR evidence pack" - "GDPR compliance" - "operating model" - "DSAR" - "DPIA" - "breach response" - "transfers" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GDPR Compliance Guide An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. *Compliance Playbook* *EU* ## EU GDPR Compliance A practical program blueprint: owners, workflows, evidence, cadence. Focus: build repeatable DSAR, breach, DPIA, vendor, and transfer controls. GDPR compliance is a live operating system for personal-data processing. The most resilient programs share a single evidence spine across scope, lawful basis, DSARs, breaches, DPIAs, vendors, RoPAs, and transfers, and they review changes through a repeatable cadence rather than a one-time remediation project. That is what keeps the program coherent when products, vendors, and regulatory expectations evolve. ## Program structure: 5 workstreams that must be connected GDPR becomes manageable when responsibilities are explicit and artifacts are shared across teams. Most compliance failures are interface bugs between these workstreams. - Inventory & scope: applicability memo, role mapping, processing inventory, RoPA fields and owners. - Legal model: lawful basis map, transparency record, consent model (where used), retention rules. - Operational workflows: DSAR intake/search/response, breach response, DPIA screening and review. - Vendors & transfers: Article 28 contracts, sub-processor governance, transfer map, SCC/TIA packs. - Assurance & evidence: validation checks, logs, versioning, and exportable evidence index. ## Delivery pipeline: how to turn requirements into shipped controls Treat GDPR like product delivery: requirements -> acceptance criteria -> implementation -> tests -> evidence export. This approach prevents policy drift and makes audits faster. - Define acceptance criteria for each workflow (DSAR, breach, DPIA, transfers). - Build automation where possible: DSAR tracking, breach evidence capture, transfer mapping. - Version key artifacts: notices, consent wording, DPIA templates, SCC packs, vendor DPAs. ## Operating cadence (minimum rhythm that works) A governance rhythm prevents surprises and keeps evidence fresh. Use cadence to enforce consistency across business units and vendors. - Weekly: DSAR queue review and escalations; active incident tracking. - Monthly: vendor and transfer changes review (new vendors, sub-processors, new destinations). - Quarterly: DPIA review and high-risk processing inventory refresh; notice and consent version audit. - Semi-annual: tabletop exercises (DSAR and breach) + evidence export drills (time-to-export SLA). ## Evidence index (what audit-ready means in practice) Audit readiness is the ability to export coherent evidence quickly. Build an evidence index and keep it current. Aim for a single index that links each requirement area to artifacts and owners. - Applicability memo + role mapping + processing inventory baseline. - Lawful basis decisions + notices + consent logs and withdrawal logs (if applicable). - DSAR logs + response packages + search playbooks and identity verification rules. - DPIA register + mitigations + residual risk approvals. - Breach response artifacts + awareness timestamps + notifications (if sent). - Vendor DPAs + sub-processor lists + security evidence + transfer packs. *Recommended next step* *Placement: after the compliance steps* ## Turn EU GDPR Compliance into an operational assessment Assessment Autopilot can take EU GDPR Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GDPR Compliance](/solutions/assessment.md): Start from EU GDPR Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Compliance. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for the overall operating model. - [ENISA Handbook on the security of personal data processing](https://www.enisa.europa.eu/publications/handbook-on-security-of-personal-data-processing?ref=sorena.io) - Useful official guidance for operational security controls. - [Irish DPC guidance on Records of Processing under Article 30](https://www.dataprotection.ie/en/dpc-guidance/records-of-processing-article-30-guidance?ref=sorena.io) - Useful accountability guidance for keeping the evidence spine current. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/compliance --- --- title: "GDPR Data Subject Rights + DSAR Workflow" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow" source_url: "https://www.sorena.io/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow" author: "Sorena AI" description: "A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope." keywords: - "GDPR DSAR workflow" - "GDPR data subject rights" - "Article 15 access request" - "GDPR right to erasure Article 17" - "GDPR portability Article 20" - "GDPR objection Article 21" - "DSAR 1 month deadline" - "DSAR" - "data subject rights" - "Article 12" - "Article 15" - "deletion" - "portability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR Data Subject Rights + DSAR Workflow A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. *Workflow* *EU* ## EU GDPR DSAR Workflow A defensible DSAR workflow depends on identity checks, complete search scope, and disciplined timekeeping. Use Articles 12 to 22 and the EDPB access guidance to separate what must be returned from what may be withheld or redacted. DSAR compliance is not just about the right of access. It is a rights workflow that has to handle access, rectification, erasure, restriction, portability, objection, and automated-decision information without losing track of deadlines or over-disclosing third-party data. The operational baseline is one month to respond, with a possible two-month extension for complexity or volume, but the extension has to be justified and communicated within the first month. ## 1) Intake, triage, and request normalization Rights requests often arrive through support, privacy inboxes, product UIs, or legal contacts. Normalization prevents requests from disappearing into the wrong queue. One request can trigger multiple GDPR rights at once, so the intake form should not force a single-label view. - Assign one request ID and log the request date, channel, and requested rights. - Normalize the request into access, deletion, rectification, portability, objection, restriction, or automated-decision information. - Log whether the request concerns the data subject directly, a parent, a legal representative, or another authorised party. - Trigger a deadline clock immediately and track any pause caused by identity clarification separately from the main compliance record. ## 2) Identity verification and scope control The controller must verify identity where it has reasonable doubts, but cannot routinely demand excessive proof. The verification rule should match the risk of the data that will be disclosed or altered. - Use authenticated-account evidence where possible, and add stronger checks for raw exports or sensitive data. - Document the reason for any additional information requested under Article 12(6). - Maintain a search map showing which systems, logs, warehouses, and processors fall within the scope for each data subject identifier. - Record any limitations, such as archived systems or legal-hold constraints, and how they affected the response. *Recommended next step* *Placement: after the scope or definition section* ## Use EU GDPR DSAR Workflow as a cited research workflow Research Copilot can take EU GDPR DSAR Workflow from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU GDPR DSAR Workflow](/solutions/research-copilot.md): Start from EU GDPR DSAR Workflow and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR DSAR Workflow. ## 3) Response packaging by right Rights responses should be templated but not mechanical. The response pack has to match the legal right invoked and the actual processing context. Article 15 access requests are the most common, but they are not the only workflow to design. - For access, provide the data plus the Article 15 information set in a clear and intelligible format. - For rectification and erasure, confirm what was changed, what remains, and why anything was retained. - For portability, limit the output to data provided by the data subject and processed by automated means on the relevant legal basis. - For objection and restriction, document how systems and downstream processors will implement the request going forward. ## 4) Extensions, refusals, and third-party rights The highest-friction DSAR cases are usually complex, repetitive, or intertwined with the rights of other people. You need rules for when to extend, narrow, redact, or refuse. - Use the two-month extension only where the complexity or number of requests justifies it, and notify the data subject within the initial month. - Document any reliance on manifestly unfounded or manifestly excessive grounds and route it through legal approval. - Protect the rights and freedoms of other individuals through redaction or withholding where necessary. - Keep an exceptions log so repeated edge cases can be reviewed and improved instead of re-litigated each time. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for Articles 12 to 22. - [EDPB Guidelines 01/2022 on data subject rights - right of access](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-012022-data-subject-rights-right-access_en?ref=sorena.io) - Official EDPB guidance on access scope, copies, and practical handling. - [EDPB Guidelines 07/2020 on controller and processor concepts](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor-gdpr_en?ref=sorena.io) - Helpful for deciding who owns and answers the rights workflow. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow --- --- title: "GDPR Data Subject Rights + DSAR Workflow" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow" source_url: "https://www.sorena.io/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow" author: "Sorena AI" description: "A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope." keywords: - "GDPR DSAR workflow" - "GDPR data subject rights" - "Article 15 access request" - "GDPR right to erasure Article 17" - "GDPR portability Article 20" - "GDPR objection Article 21" - "DSAR 1 month deadline" - "DSAR" - "data subject rights" - "Article 12" - "Article 15" - "deletion" - "portability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR Data Subject Rights + DSAR Workflow A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. *Workflow* *EU* ## EU GDPR DSAR Workflow A defensible DSAR workflow depends on identity checks, complete search scope, and disciplined timekeeping. Use Articles 12 to 22 and the EDPB access guidance to separate what must be returned from what may be withheld or redacted. DSAR compliance is not just about the right of access. It is a rights workflow that has to handle access, rectification, erasure, restriction, portability, objection, and automated-decision information without losing track of deadlines or over-disclosing third-party data. The operational baseline is one month to respond, with a possible two-month extension for complexity or volume, but the extension has to be justified and communicated within the first month. ## 1) Intake, triage, and request normalization Rights requests often arrive through support, privacy inboxes, product UIs, or legal contacts. Normalization prevents requests from disappearing into the wrong queue. One request can trigger multiple GDPR rights at once, so the intake form should not force a single-label view. - Assign one request ID and log the request date, channel, and requested rights. - Normalize the request into access, deletion, rectification, portability, objection, restriction, or automated-decision information. - Log whether the request concerns the data subject directly, a parent, a legal representative, or another authorised party. - Trigger a deadline clock immediately and track any pause caused by identity clarification separately from the main compliance record. ## 2) Identity verification and scope control The controller must verify identity where it has reasonable doubts, but cannot routinely demand excessive proof. The verification rule should match the risk of the data that will be disclosed or altered. - Use authenticated-account evidence where possible, and add stronger checks for raw exports or sensitive data. - Document the reason for any additional information requested under Article 12(6). - Maintain a search map showing which systems, logs, warehouses, and processors fall within the scope for each data subject identifier. - Record any limitations, such as archived systems or legal-hold constraints, and how they affected the response. *Recommended next step* *Placement: after the scope or definition section* ## Use EU GDPR DSAR Workflow as a cited research workflow Research Copilot can take EU GDPR DSAR Workflow from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU GDPR DSAR Workflow](/solutions/research-copilot.md): Start from EU GDPR DSAR Workflow and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR DSAR Workflow. ## 3) Response packaging by right Rights responses should be templated but not mechanical. The response pack has to match the legal right invoked and the actual processing context. Article 15 access requests are the most common, but they are not the only workflow to design. - For access, provide the data plus the Article 15 information set in a clear and intelligible format. - For rectification and erasure, confirm what was changed, what remains, and why anything was retained. - For portability, limit the output to data provided by the data subject and processed by automated means on the relevant legal basis. - For objection and restriction, document how systems and downstream processors will implement the request going forward. ## 4) Extensions, refusals, and third-party rights The highest-friction DSAR cases are usually complex, repetitive, or intertwined with the rights of other people. You need rules for when to extend, narrow, redact, or refuse. - Use the two-month extension only where the complexity or number of requests justifies it, and notify the data subject within the initial month. - Document any reliance on manifestly unfounded or manifestly excessive grounds and route it through legal approval. - Protect the rights and freedoms of other individuals through redaction or withholding where necessary. - Keep an exceptions log so repeated edge cases can be reviewed and improved instead of re-litigated each time. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for Articles 12 to 22. - [EDPB Guidelines 01/2022 on data subject rights - right of access](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-012022-data-subject-rights-right-access_en?ref=sorena.io) - Official EDPB guidance on access scope, copies, and practical handling. - [EDPB Guidelines 07/2020 on controller and processor concepts](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor-gdpr_en?ref=sorena.io) - Helpful for deciding who owns and answers the rights workflow. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow --- --- title: "GDPR Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/gdpr/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul." keywords: - "GDPR deadlines" - "GDPR compliance calendar" - "DSAR one month deadline" - "GDPR breach notification 72 hours" - "GDPR DPIA review cadence" - "GDPR vendor audit cadence" - "GDPR transfer monitoring" - "compliance calendar" - "DSAR SLA" - "breach 72 hours" - "DPIA cadence" - "vendor audits" - "transfers" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR Deadlines and Compliance Calendar A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. *Calendar* *EU* ## EU GDPR Compliance Calendar GDPR deadlines are part legal history and part live operating discipline. Use both the fixed legal milestones and the recurring workflow SLAs to keep the privacy program current. GDPR is mature law, but the calendar still matters. The most useful GDPR calendar includes both the fixed regulatory milestones that explain the current legal state and the recurring operational deadlines that determine day to day compliance. That means combining the adoption and application dates, SCC and adequacy milestones, and the ongoing clocks for DSARs, breach notification, DPIA review, RoPA maintenance, vendor oversight, and transfer reassessment. ## Fixed legal milestones you should keep in the program timeline These dates explain why certain transfer tools, guidance, and workflows look the way they do today. They also help prevent stale documentation and outdated contract packs. - 27 April 2016, GDPR was adopted. - 4 May 2016, GDPR was published in the Official Journal. - 25 May 2018, GDPR became applicable. - 4 June 2021, the Commission adopted the new controller to processor standard clauses under Article 28 and the modern SCC decisions used in transfer programs. - 27 December 2022, the transition period for replacing the old transfer SCCs ended. - 10 July 2023, the Commission adopted the EU-US Data Privacy Framework adequacy decision. - 18 and 19 July 2024, the Commission and EDPB representatives held the first periodic review meeting for the EU-US DPF. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU GDPR Compliance Calendar into an operational assessment Assessment Autopilot can take EU GDPR Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GDPR Compliance Calendar](/solutions/assessment.md): Start from EU GDPR Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Compliance Calendar. ## Always-on operational deadlines These are the deadlines that most often create enforcement pain because they are measured in hours or weeks, not years. Treat them as service levels with owners, escalation, and evidence outputs. - DSARs: respond without undue delay and in any event within one month, with a documented basis for any two-month extension. - Breach notification: notify the supervisory authority within 72 hours of awareness unless the breach is unlikely to result in a risk to rights and freedoms. - Processor breach escalation: processors must notify the controller without undue delay after becoming aware. - Article 34 communications: where high risk exists, communicate to affected individuals without undue delay unless a legal exception applies. ## Monthly and quarterly governance cadence GDPR failures often come from drift rather than from one missed incident. Governance cadence prevents that drift. Build these recurring checks into the privacy operating calendar. - Monthly transfer and vendor change review for new destinations, sub-processors, and cloud-region changes. - Monthly notice and lawful-basis review for new product flows, cookies, analytics, and marketing changes. - Quarterly RoPA refresh for changed purposes, recipients, retention, security measures, and transfer mechanisms. - Quarterly DPIA screening for new or materially changed high-risk processing and automation use cases. - Quarterly DSAR and breach tabletop exercises in at least one live business area. ## Annual checkpoints that catch stale evidence A privacy program without annual evidence refresh turns into archive theater. Use annual checkpoints to remove outdated transfer, vendor, and retention assumptions. - Annual transfer review for high-risk routes, including TIAs, adequacy reliance, and supplementary measures where relevant. - Annual vendor review of Article 28 clauses, sub-processor lists, incident obligations, and security evidence. - Annual policy and notice version cleanup so old wording does not survive in live channels. - Annual training and escalation-path refresh for privacy, security, support, and procurement teams. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for DSAR, breach, DPIA, and accountability deadlines. - [European Commission: Standard Contractual Clauses overview](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en?ref=sorena.io) - Official SCC resource hub and current contract baseline. - [European Commission: EU-US data transfers](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers_en?ref=sorena.io) - Official Commission page for the 2023 adequacy decision and later review context. - [Report on the first periodic review of the EU-US Data Privacy Framework](https://commission.europa.eu/document/download/5a6570d0-64f7-4d16-9505-f15128eef4f8_en?ref=sorena.io) - Commission report following the July 2024 first review meeting. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/deadlines-and-compliance-calendar --- --- title: "GDPR Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/gdpr/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul." keywords: - "GDPR deadlines" - "GDPR compliance calendar" - "DSAR one month deadline" - "GDPR breach notification 72 hours" - "GDPR DPIA review cadence" - "GDPR vendor audit cadence" - "GDPR transfer monitoring" - "compliance calendar" - "DSAR SLA" - "breach 72 hours" - "DPIA cadence" - "vendor audits" - "transfers" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR Deadlines and Compliance Calendar A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. *Calendar* *EU* ## EU GDPR Compliance Calendar GDPR deadlines are part legal history and part live operating discipline. Use both the fixed legal milestones and the recurring workflow SLAs to keep the privacy program current. GDPR is mature law, but the calendar still matters. The most useful GDPR calendar includes both the fixed regulatory milestones that explain the current legal state and the recurring operational deadlines that determine day to day compliance. That means combining the adoption and application dates, SCC and adequacy milestones, and the ongoing clocks for DSARs, breach notification, DPIA review, RoPA maintenance, vendor oversight, and transfer reassessment. ## Fixed legal milestones you should keep in the program timeline These dates explain why certain transfer tools, guidance, and workflows look the way they do today. They also help prevent stale documentation and outdated contract packs. - 27 April 2016, GDPR was adopted. - 4 May 2016, GDPR was published in the Official Journal. - 25 May 2018, GDPR became applicable. - 4 June 2021, the Commission adopted the new controller to processor standard clauses under Article 28 and the modern SCC decisions used in transfer programs. - 27 December 2022, the transition period for replacing the old transfer SCCs ended. - 10 July 2023, the Commission adopted the EU-US Data Privacy Framework adequacy decision. - 18 and 19 July 2024, the Commission and EDPB representatives held the first periodic review meeting for the EU-US DPF. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU GDPR Compliance Calendar into an operational assessment Assessment Autopilot can take EU GDPR Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GDPR Compliance Calendar](/solutions/assessment.md): Start from EU GDPR Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Compliance Calendar. ## Always-on operational deadlines These are the deadlines that most often create enforcement pain because they are measured in hours or weeks, not years. Treat them as service levels with owners, escalation, and evidence outputs. - DSARs: respond without undue delay and in any event within one month, with a documented basis for any two-month extension. - Breach notification: notify the supervisory authority within 72 hours of awareness unless the breach is unlikely to result in a risk to rights and freedoms. - Processor breach escalation: processors must notify the controller without undue delay after becoming aware. - Article 34 communications: where high risk exists, communicate to affected individuals without undue delay unless a legal exception applies. ## Monthly and quarterly governance cadence GDPR failures often come from drift rather than from one missed incident. Governance cadence prevents that drift. Build these recurring checks into the privacy operating calendar. - Monthly transfer and vendor change review for new destinations, sub-processors, and cloud-region changes. - Monthly notice and lawful-basis review for new product flows, cookies, analytics, and marketing changes. - Quarterly RoPA refresh for changed purposes, recipients, retention, security measures, and transfer mechanisms. - Quarterly DPIA screening for new or materially changed high-risk processing and automation use cases. - Quarterly DSAR and breach tabletop exercises in at least one live business area. ## Annual checkpoints that catch stale evidence A privacy program without annual evidence refresh turns into archive theater. Use annual checkpoints to remove outdated transfer, vendor, and retention assumptions. - Annual transfer review for high-risk routes, including TIAs, adequacy reliance, and supplementary measures where relevant. - Annual vendor review of Article 28 clauses, sub-processor lists, incident obligations, and security evidence. - Annual policy and notice version cleanup so old wording does not survive in live channels. - Annual training and escalation-path refresh for privacy, security, support, and procurement teams. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for DSAR, breach, DPIA, and accountability deadlines. - [European Commission: Standard Contractual Clauses overview](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en?ref=sorena.io) - Official SCC resource hub and current contract baseline. - [European Commission: EU-US data transfers](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers_en?ref=sorena.io) - Official Commission page for the 2023 adequacy decision and later review context. - [Report on the first periodic review of the EU-US Data Privacy Framework](https://commission.europa.eu/document/download/5a6570d0-64f7-4d16-9505-f15128eef4f8_en?ref=sorena.io) - Commission report following the July 2024 first review meeting. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/deadlines-and-compliance-calendar --- --- title: "GDPR DPIA (Article 35) + Risk Management" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/dpia-and-risk-management" source_url: "https://www.sorena.io/artifacts/eu/gdpr/dpia-and-risk-management" author: "Sorena AI" description: "A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms." keywords: - "GDPR DPIA" - "Article 35 DPIA" - "GDPR prior consultation Article 36" - "DPIA template" - "GDPR risk assessment rights and freedoms" - "privacy by design controls" - "DPIA" - "Article 35" - "prior consultation" - "risk management" - "privacy by design" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR DPIA (Article 35) + Risk Management A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. *Risk Playbook* *EU* ## EU GDPR DPIA and Risk Management A DPIA is a decision record for high-risk processing, not a formality after build is complete. Use Article 35, Article 36, the WP29 trigger criteria, and CNIL methodology to make DPIAs usable by product and security teams. A good DPIA is built early enough to change the product, not late enough to merely describe it. The legal core is Article 35 and Article 36, but the operational core is a screening workflow, a consistent set of high-risk criteria, a structured assessment of necessity and proportionality, a risk analysis focused on rights and freedoms, and a mitigation plan with real owners. If residual high risk remains, the workflow has to escalate to prior consultation rather than pretending the file is complete. ## 1) Screening: decide early whether a DPIA is required The fastest way to waste DPIA effort is to run them too late or for the wrong things. Screening should happen at idea, procurement, and major-change stages. Use a stable checklist so teams are not guessing from memory. - Check for large-scale monitoring, profiling, special-category data, vulnerable populations, innovative technology, or processing that could have significant effects on individuals. - Use the WP29 high-risk criteria and any local supervisory-authority lists as the screen, not an internal folk test. - Store both positive and negative screening outcomes in a DPIA register. - Re-screen when the purpose, dataset, vendor chain, or transfer route changes materially. ## 2) Build the DPIA around necessity, proportionality, and rights impact A DPIA that only lists security threats is incomplete. It must also explain why the processing is needed and whether less intrusive options were considered. This is where privacy by design becomes a documented engineering constraint. - Describe the processing, data flows, recipients, retention, and international transfers clearly enough that another reviewer can understand the system. - Assess necessity and proportionality against the purpose, not just technical convenience. - Identify risks to confidentiality, integrity, availability, fairness, autonomy, non-discrimination, and other rights impacts as relevant. - Seek DPO advice and, where appropriate, the views of data subjects or their representatives. ## 3) Mitigation library and residual-risk decision A useful DPIA ends with measures that can be assigned, built, tested, and verified. Residual risk should never be a vague sentence without an owner. - Translate each mitigation into a control with an owner, target date, and verification method. - Map security measures to Article 32 and business-process controls to notice, choice, review, and governance obligations. - Track open issues and accepted residual risks in the same register as the DPIA decision. - Escalate for prior consultation under Article 36 where residual high risk remains after planned measures. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU GDPR DPIA and Risk Management in one governed evidence system SSOT can take EU GDPR DPIA and Risk Management from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU GDPR DPIA and Risk Management](/solutions/ssot.md): Start from EU GDPR DPIA and Risk Management and keep documents, evidence, and control records in one governed system. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR DPIA and Risk Management. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for Articles 35 and 36. - [CNIL Privacy Impact Assessment resources](https://www.cnil.fr/en/privacy-impact-assessments-pia?ref=sorena.io) - Widely used official methodology and templates for structuring DPIAs. - [ENISA Handbook on the security of personal data processing](https://www.enisa.europa.eu/publications/handbook-on-security-of-personal-data-processing?ref=sorena.io) - Supports the security and risk-mitigation portions of DPIA work. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/dpia-and-risk-management --- --- title: "GDPR DPIA (Article 35) + Risk Management" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/dpia-and-risk-management" source_url: "https://www.sorena.io/artifacts/eu/gdpr/dpia-and-risk-management" author: "Sorena AI" description: "A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms." keywords: - "GDPR DPIA" - "Article 35 DPIA" - "GDPR prior consultation Article 36" - "DPIA template" - "GDPR risk assessment rights and freedoms" - "privacy by design controls" - "DPIA" - "Article 35" - "prior consultation" - "risk management" - "privacy by design" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR DPIA (Article 35) + Risk Management A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. *Risk Playbook* *EU* ## EU GDPR DPIA and Risk Management A DPIA is a decision record for high-risk processing, not a formality after build is complete. Use Article 35, Article 36, the WP29 trigger criteria, and CNIL methodology to make DPIAs usable by product and security teams. A good DPIA is built early enough to change the product, not late enough to merely describe it. The legal core is Article 35 and Article 36, but the operational core is a screening workflow, a consistent set of high-risk criteria, a structured assessment of necessity and proportionality, a risk analysis focused on rights and freedoms, and a mitigation plan with real owners. If residual high risk remains, the workflow has to escalate to prior consultation rather than pretending the file is complete. ## 1) Screening: decide early whether a DPIA is required The fastest way to waste DPIA effort is to run them too late or for the wrong things. Screening should happen at idea, procurement, and major-change stages. Use a stable checklist so teams are not guessing from memory. - Check for large-scale monitoring, profiling, special-category data, vulnerable populations, innovative technology, or processing that could have significant effects on individuals. - Use the WP29 high-risk criteria and any local supervisory-authority lists as the screen, not an internal folk test. - Store both positive and negative screening outcomes in a DPIA register. - Re-screen when the purpose, dataset, vendor chain, or transfer route changes materially. ## 2) Build the DPIA around necessity, proportionality, and rights impact A DPIA that only lists security threats is incomplete. It must also explain why the processing is needed and whether less intrusive options were considered. This is where privacy by design becomes a documented engineering constraint. - Describe the processing, data flows, recipients, retention, and international transfers clearly enough that another reviewer can understand the system. - Assess necessity and proportionality against the purpose, not just technical convenience. - Identify risks to confidentiality, integrity, availability, fairness, autonomy, non-discrimination, and other rights impacts as relevant. - Seek DPO advice and, where appropriate, the views of data subjects or their representatives. ## 3) Mitigation library and residual-risk decision A useful DPIA ends with measures that can be assigned, built, tested, and verified. Residual risk should never be a vague sentence without an owner. - Translate each mitigation into a control with an owner, target date, and verification method. - Map security measures to Article 32 and business-process controls to notice, choice, review, and governance obligations. - Track open issues and accepted residual risks in the same register as the DPIA decision. - Escalate for prior consultation under Article 36 where residual high risk remains after planned measures. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU GDPR DPIA and Risk Management in one governed evidence system SSOT can take EU GDPR DPIA and Risk Management from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU GDPR DPIA and Risk Management](/solutions/ssot.md): Start from EU GDPR DPIA and Risk Management and keep documents, evidence, and control records in one governed system. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR DPIA and Risk Management. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for Articles 35 and 36. - [CNIL Privacy Impact Assessment resources](https://www.cnil.fr/en/privacy-impact-assessments-pia?ref=sorena.io) - Widely used official methodology and templates for structuring DPIAs. - [ENISA Handbook on the security of personal data processing](https://www.enisa.europa.eu/publications/handbook-on-security-of-personal-data-processing?ref=sorena.io) - Supports the security and risk-mitigation portions of DPIA work. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/dpia-and-risk-management --- --- title: "EU GDPR FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/faq" source_url: "https://www.sorena.io/artifacts/eu/gdpr/faq" author: "Sorena AI" description: "Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data." keywords: - "GDPR FAQ" - "GDPR explained" - "GDPR consent FAQ" - "GDPR DSAR FAQ" - "GDPR DPIA FAQ" - "GDPR breach notification FAQ" - "GDPR SCC transfers FAQ" - "DSAR" - "consent" - "DPIA" - "breach notification" - "SCCs" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GDPR FAQ Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. *FAQ* *EU* ## EU GDPR FAQ Practical answers for teams building GDPR controls and evidence. Use this page as a navigation map to the deeper implementation subpages. These are the GDPR questions that recur in real implementation work: scope, timing, lawful basis, DSAR extensions, breach awareness, Chapter V transfers, DPF reliance, vendor clauses, and RoPA upkeep. The answers below focus on what teams actually need to build and preserve as evidence. ## Does GDPR apply to my company if we're not in the EU? GDPR can apply based on territorial scope (Article 3), including targeting EU data subjects or monitoring behavior in the EU. The right output is an Article 3 mapping with facts and evidence, not a vague conclusion. - Run the applicability test and document the Article 3 path. - If Article 3(2) applies, assess representative obligations (Article 27). - If you have transfers, plan Chapter V safeguards early. ## When do we need consent vs another lawful basis? Consent is one lawful basis among several (Article 6). It is not always required and can be operationally costly to maintain. If you use consent, the system must support withdrawal and proof. - Create a lawful basis map per purpose and keep it versioned. - If using consent, store consent logs that link to wording version and user choice. - Align notices and downstream processing to the chosen lawful basis. ## How do we meet DSAR deadlines in practice? DSAR compliance is a workflow: intake -> identity -> search -> response -> evidence. Most failures come from missing systems in the search scope and weak deadline tracking. - Build a DSAR data map (systems + identifiers + vendor scope). - Standardize response packages per right and track the 1-month SLA. - Keep an evidence pack per request (logs, decisions, delivered response). ## When do we need a DPIA? DPIAs are for high-risk processing. Use a screening checklist so you decide early. A good DPIA produces mitigations engineering teams can ship and residual risk sign-offs. - Run screening on new features that introduce monitoring, profiling, sensitive data, or large-scale processing. - Keep a DPIA register and link mitigations to backlog items. - If residual high risk remains, evaluate prior consultation (Article 36). ## How does the 72-hour breach notification work? The core operational problem is timekeeping: when the controller became aware of a personal data breach. Use an awareness criteria checklist, document the timestamp, and notify in phases if needed. - Build a breach classification and risk rubric aligned to Articles 33-34. - Prepare notification and communication templates in advance. - Keep an incident evidence pack: timeline, logs, decisions, communications, remediation. ## Do SCCs automatically make transfers compliant? SCCs are a mechanism, not a magic shield. You still need to map transfers, assess risks, and implement supplementary measures where appropriate. Treat SCCs as an implementation project: configuration, logging, and governance. - Build a transfer map (destinations, vendors, onward transfers). - Use Commission SCC resources and maintain packs per vendor/destination. - Run TIAs and monitor changes in destination risk and vendor practices. *Recommended next step* *Placement: after the FAQ section* ## Use EU GDPR FAQ as a cited research workflow Research Copilot can take EU GDPR FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU GDPR FAQ](/solutions/research-copilot.md): Start from EU GDPR FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR FAQ. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary legal baseline for the FAQ. - [European Commission: EU-US data transfers](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers_en?ref=sorena.io) - Official source for current DPF context. - [Irish DPC guidance on Records of Processing under Article 30](https://www.dataprotection.ie/en/dpc-guidance/records-of-processing-article-30-guidance?ref=sorena.io) - Useful official guidance for accountability questions that frequently arise. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/faq --- --- title: "EU GDPR FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/faq" source_url: "https://www.sorena.io/artifacts/eu/gdpr/faq" author: "Sorena AI" description: "Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data." keywords: - "GDPR FAQ" - "GDPR explained" - "GDPR consent FAQ" - "GDPR DSAR FAQ" - "GDPR DPIA FAQ" - "GDPR breach notification FAQ" - "GDPR SCC transfers FAQ" - "DSAR" - "consent" - "DPIA" - "breach notification" - "SCCs" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GDPR FAQ Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. *FAQ* *EU* ## EU GDPR FAQ Practical answers for teams building GDPR controls and evidence. Use this page as a navigation map to the deeper implementation subpages. These are the GDPR questions that recur in real implementation work: scope, timing, lawful basis, DSAR extensions, breach awareness, Chapter V transfers, DPF reliance, vendor clauses, and RoPA upkeep. The answers below focus on what teams actually need to build and preserve as evidence. ## Does GDPR apply to my company if we're not in the EU? GDPR can apply based on territorial scope (Article 3), including targeting EU data subjects or monitoring behavior in the EU. The right output is an Article 3 mapping with facts and evidence, not a vague conclusion. - Run the applicability test and document the Article 3 path. - If Article 3(2) applies, assess representative obligations (Article 27). - If you have transfers, plan Chapter V safeguards early. ## When do we need consent vs another lawful basis? Consent is one lawful basis among several (Article 6). It is not always required and can be operationally costly to maintain. If you use consent, the system must support withdrawal and proof. - Create a lawful basis map per purpose and keep it versioned. - If using consent, store consent logs that link to wording version and user choice. - Align notices and downstream processing to the chosen lawful basis. ## How do we meet DSAR deadlines in practice? DSAR compliance is a workflow: intake -> identity -> search -> response -> evidence. Most failures come from missing systems in the search scope and weak deadline tracking. - Build a DSAR data map (systems + identifiers + vendor scope). - Standardize response packages per right and track the 1-month SLA. - Keep an evidence pack per request (logs, decisions, delivered response). ## When do we need a DPIA? DPIAs are for high-risk processing. Use a screening checklist so you decide early. A good DPIA produces mitigations engineering teams can ship and residual risk sign-offs. - Run screening on new features that introduce monitoring, profiling, sensitive data, or large-scale processing. - Keep a DPIA register and link mitigations to backlog items. - If residual high risk remains, evaluate prior consultation (Article 36). ## How does the 72-hour breach notification work? The core operational problem is timekeeping: when the controller became aware of a personal data breach. Use an awareness criteria checklist, document the timestamp, and notify in phases if needed. - Build a breach classification and risk rubric aligned to Articles 33-34. - Prepare notification and communication templates in advance. - Keep an incident evidence pack: timeline, logs, decisions, communications, remediation. ## Do SCCs automatically make transfers compliant? SCCs are a mechanism, not a magic shield. You still need to map transfers, assess risks, and implement supplementary measures where appropriate. Treat SCCs as an implementation project: configuration, logging, and governance. - Build a transfer map (destinations, vendors, onward transfers). - Use Commission SCC resources and maintain packs per vendor/destination. - Run TIAs and monitor changes in destination risk and vendor practices. *Recommended next step* *Placement: after the FAQ section* ## Use EU GDPR FAQ as a cited research workflow Research Copilot can take EU GDPR FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU GDPR FAQ](/solutions/research-copilot.md): Start from EU GDPR FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR FAQ. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary legal baseline for the FAQ. - [European Commission: EU-US data transfers](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers_en?ref=sorena.io) - Official source for current DPF context. - [Irish DPC guidance on Records of Processing under Article 30](https://www.dataprotection.ie/en/dpc-guidance/records-of-processing-article-30-guidance?ref=sorena.io) - Useful official guidance for accountability questions that frequently arise. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/faq --- --- title: "GDPR vs CCPA/CPRA" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/gdpr-vs-ccpa" source_url: "https://www.sorena.io/artifacts/eu/gdpr/gdpr-vs-ccpa" author: "Sorena AI" description: "A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models." keywords: - "GDPR vs CCPA" - "GDPR vs CPRA" - "CCPA GDPR difference" - "privacy rights GDPR CCPA" - "DSAR vs consumer request" - "GDPR lawful basis vs CCPA sale share" - "GDPR processor vs CCPA service provider" - "CPRA" - "DSAR" - "consumer rights" - "vendor contracts" - "privacy compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR vs CCPA/CPRA A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. *Comparison* *EU / US* ## GDPR vs CCPA/CPRA What Changes Operationally A comparison designed for implementation teams (not just legal summaries). Focus: scope triggers, rights workflows, vendor contracts, and shared evidence infrastructure. GDPR and California privacy law can share some operational plumbing, but they are not the same legal architecture. GDPR is built around lawful basis, purpose limitation, international-transfer controls, and regulator-facing accountability documents such as RoPAs and DPIAs. California law focuses more heavily on notice, sale and sharing controls, sensitive-information limits, opt-out mechanics, and contract distinctions such as service provider, contractor, and third party. Shared workflows work best when they are built on one data map and two legal views. ## Scope model: what makes you in scope GDPR scope is based on processing and territorial scope (Article 3). CCPA/CPRA scope is tied to business criteria and regulated activity types (e.g., selling/sharing personal information). Operational outcome: you need a jurisdiction and product mapping layer. - GDPR: establishment/targeting/monitoring logic (Article 3) and role mapping (controller/processor). - CCPA/CPRA: business scope thresholds and definitions; focus on sale/share and service providers or contractors. - Shared control: a scope matrix per product/market that drives which workflow applies. ## Legal model: lawful bases vs notice/opt-out constructs GDPR requires a lawful basis per purpose (Article 6) and strict consent conditions where used (Article 7). CCPA/CPRA emphasizes transparency and consumer choices around sale/sharing and certain sensitive uses. - GDPR: purpose -> lawful basis map + proof; consent requires withdrawal and enforcement capability. - CCPA/CPRA: build a disclosure and choice system tied to sale/share/sensitive data requirements. - Shared control: a purpose registry and disclosure library that can generate both EU and CA notices. *Recommended next step* *Placement: after the comparison section* ## Use GDPR vs CCPA/CPRA What Changes Operationally as a cited research workflow Research Copilot can take GDPR vs CCPA/CPRA What Changes Operationally from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on GDPR vs CCPA/CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for GDPR vs CCPA/CPRA What Changes Operationally](/solutions/research-copilot.md): Start from GDPR vs CCPA/CPRA What Changes Operationally and answer scope, timing, and interpretation questions with cited outputs. - [Talk through GDPR vs CCPA/CPRA](/contact.md): Review your current process, evidence gaps, and next steps for GDPR vs CCPA/CPRA What Changes Operationally. ## Rights workflows: DSAR vs consumer requests Both regimes require request handling, but timelines, response content, and exception structures differ. Operationally, you can share the workflow engine but parameterize the rules by regime. - Shared components: intake channels, request IDs, identity verification, system search map, response packaging. - GDPR: Articles 12-22 structure (access, deletion, rectification, portability, objection, etc.). - CCPA/CPRA: access/know, delete, correct, opt-out of sale/share, limit sensitive use (depending on context). ## Vendors: processor vs service provider/contractor (contract implications) The terminology differs, but the engineering reality is the same: vendor data use must be restricted, audited, and controllable. Build one vendor governance system with regime-specific contract clauses. - GDPR: Article 28 processor contracts + sub-processor governance + transfer safeguards. - CCPA/CPRA: service provider/contractor contract restrictions + purpose limitation and onward sharing controls. - Shared control: vendor inventory + data flows + sub-vendor tracking + evidence refresh cadence. ## Shared evidence infrastructure (high leverage) You can reduce cost and risk by building a unified evidence index and export system. The evidence can be reused across audits and regulator inquiries with different legal views. - Unified request logs and response packages (EU/CA views). - Unified vendor evidence packs (contracts, security evidence, sub-vendor list, transfer packs where relevant). - Unified disclosure library with version history (what users were told, when, and why). ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for the EU side of the comparison. - [California Department of Justice: CCPA overview](https://oag.ca.gov/privacy/ccpa?ref=sorena.io) - Official California overview used for the US side of the comparison. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/gdpr-vs-ccpa --- --- title: "GDPR vs CCPA/CPRA" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/gdpr-vs-ccpa" source_url: "https://www.sorena.io/artifacts/eu/gdpr/gdpr-vs-ccpa" author: "Sorena AI" description: "A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models." keywords: - "GDPR vs CCPA" - "GDPR vs CPRA" - "CCPA GDPR difference" - "privacy rights GDPR CCPA" - "DSAR vs consumer request" - "GDPR lawful basis vs CCPA sale share" - "GDPR processor vs CCPA service provider" - "CPRA" - "DSAR" - "consumer rights" - "vendor contracts" - "privacy compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR vs CCPA/CPRA A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. *Comparison* *EU / US* ## GDPR vs CCPA/CPRA What Changes Operationally A comparison designed for implementation teams (not just legal summaries). Focus: scope triggers, rights workflows, vendor contracts, and shared evidence infrastructure. GDPR and California privacy law can share some operational plumbing, but they are not the same legal architecture. GDPR is built around lawful basis, purpose limitation, international-transfer controls, and regulator-facing accountability documents such as RoPAs and DPIAs. California law focuses more heavily on notice, sale and sharing controls, sensitive-information limits, opt-out mechanics, and contract distinctions such as service provider, contractor, and third party. Shared workflows work best when they are built on one data map and two legal views. ## Scope model: what makes you in scope GDPR scope is based on processing and territorial scope (Article 3). CCPA/CPRA scope is tied to business criteria and regulated activity types (e.g., selling/sharing personal information). Operational outcome: you need a jurisdiction and product mapping layer. - GDPR: establishment/targeting/monitoring logic (Article 3) and role mapping (controller/processor). - CCPA/CPRA: business scope thresholds and definitions; focus on sale/share and service providers or contractors. - Shared control: a scope matrix per product/market that drives which workflow applies. ## Legal model: lawful bases vs notice/opt-out constructs GDPR requires a lawful basis per purpose (Article 6) and strict consent conditions where used (Article 7). CCPA/CPRA emphasizes transparency and consumer choices around sale/sharing and certain sensitive uses. - GDPR: purpose -> lawful basis map + proof; consent requires withdrawal and enforcement capability. - CCPA/CPRA: build a disclosure and choice system tied to sale/share/sensitive data requirements. - Shared control: a purpose registry and disclosure library that can generate both EU and CA notices. *Recommended next step* *Placement: after the comparison section* ## Use GDPR vs CCPA/CPRA What Changes Operationally as a cited research workflow Research Copilot can take GDPR vs CCPA/CPRA What Changes Operationally from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on GDPR vs CCPA/CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for GDPR vs CCPA/CPRA What Changes Operationally](/solutions/research-copilot.md): Start from GDPR vs CCPA/CPRA What Changes Operationally and answer scope, timing, and interpretation questions with cited outputs. - [Talk through GDPR vs CCPA/CPRA](/contact.md): Review your current process, evidence gaps, and next steps for GDPR vs CCPA/CPRA What Changes Operationally. ## Rights workflows: DSAR vs consumer requests Both regimes require request handling, but timelines, response content, and exception structures differ. Operationally, you can share the workflow engine but parameterize the rules by regime. - Shared components: intake channels, request IDs, identity verification, system search map, response packaging. - GDPR: Articles 12-22 structure (access, deletion, rectification, portability, objection, etc.). - CCPA/CPRA: access/know, delete, correct, opt-out of sale/share, limit sensitive use (depending on context). ## Vendors: processor vs service provider/contractor (contract implications) The terminology differs, but the engineering reality is the same: vendor data use must be restricted, audited, and controllable. Build one vendor governance system with regime-specific contract clauses. - GDPR: Article 28 processor contracts + sub-processor governance + transfer safeguards. - CCPA/CPRA: service provider/contractor contract restrictions + purpose limitation and onward sharing controls. - Shared control: vendor inventory + data flows + sub-vendor tracking + evidence refresh cadence. ## Shared evidence infrastructure (high leverage) You can reduce cost and risk by building a unified evidence index and export system. The evidence can be reused across audits and regulator inquiries with different legal views. - Unified request logs and response packages (EU/CA views). - Unified vendor evidence packs (contracts, security evidence, sub-vendor list, transfer packs where relevant). - Unified disclosure library with version history (what users were told, when, and why). ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for the EU side of the comparison. - [California Department of Justice: CCPA overview](https://oag.ca.gov/privacy/ccpa?ref=sorena.io) - Official California overview used for the US side of the comparison. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/gdpr-vs-ccpa --- --- title: "GDPR vs UK GDPR" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/gdpr-vs-uk-gdpr" source_url: "https://www.sorena.io/artifacts/eu/gdpr/gdpr-vs-uk-gdpr" author: "Sorena AI" description: "A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications." keywords: - "GDPR vs UK GDPR" - "EU GDPR vs UK GDPR" - "UK GDPR compliance" - "ICO UK GDPR guidance" - "EU GDPR one stop shop" - "EU SCCs vs UK IDTA" - "UK Addendum to EU SCCs" - "international data transfers EU UK" - "EU compliance" - "international data transfers" - "EU SCCs" - "UK IDTA" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR vs UK GDPR A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. *Comparison* *EU / UK* ## GDPR vs UK GDPR What Changes Operationally A comparison designed for implementation teams (not just legal summaries). Focus: scope triggers, regulator structure, transfer tools (EU SCCs vs UK IDTA/Addendum), and a shared evidence model. EU GDPR and UK GDPR are still structurally close, which is why one privacy operating model can often serve both. The main practical differences show up in regulator interaction, transfer instruments, and local guidance. The EU program relies on EDPB positions and EU SCC or adequacy routes, while the UK program relies on the ICO, UK-specific transfer tools such as the IDTA and UK Addendum, and UK legal overlays. The most efficient design is one evidence spine with separate EU and UK legal outputs. ## Quick orientation: same roots, different governance context UK GDPR is the UK's retained version of the GDPR text, operating alongside UK domestic law and UK regulator guidance. EU GDPR is the GDPR as applied in the EU/EEA with EU-wide cooperation mechanisms and EDPB guidance. Operational outcome: you can reuse many controls (records, DSAR workflow, vendor governance, security measures) but you still need jurisdiction-aware decisions, especially for transfers and regulator interactions. - Build one control library and generate separate EU and UK views (owners, evidence, and legal hooks). - Keep a change log for divergence (UK amendments and ICO guidance vs EDPB positions). - Treat transfers as the highest-leverage divergence area (tools and documentation differ). ## Scope triggers: establishment, targeting, monitoring (and why Article 3 still matters) Both regimes are designed to apply beyond borders in certain situations. The practical work is to maintain a product-and-market map that drives which workflows apply (EU, UK, both). If you rely on a we are only in one market assumption, your highest risk is usually marketing, analytics or monitoring, support operations, and vendor processing locations. - Maintain a scope matrix: product -> user base -> establishment -> targeting/monitoring signals -> applicable regime(s). - Define roles per processing: controller/processor (and joint-controller where relevant) and mirror those roles into contracts and DSAR operations. - Use the same evidence spine for both: RoPA, DPIA decisions, vendor register, DSAR logs, incident register. ## Regulator model: one-stop-shop (EU) vs UK ICO (and what it changes) In the EU, cross-border processing can involve cooperation across supervisory authorities (including a lead authority concept). In the UK, the ICO is the primary privacy regulator for UK GDPR and UK domestic data protection rules. Operational outcome: when you run a multi-market product, your incident response, DSAR escalation paths, and accountability evidence should be built to support both an EU supervisory authority inquiry and an ICO inquiry-without reinventing the pack. - Create a regulator-ready evidence index: where each artifact lives, who owns it, update cadence, and export format. - Use consistent definitions and policy language, but keep jurisdiction-specific annexes (EU vs UK) for divergences. - For cross-border operations, predefine primary contacts and escalation paths per market (EU vs UK). *Recommended next step* *Placement: after the comparison section* ## Use GDPR vs UK GDPR What Changes Operationally as a cited research workflow Research Copilot can take GDPR vs UK GDPR What Changes Operationally from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on GDPR vs UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for GDPR vs UK GDPR What Changes Operationally](/solutions/research-copilot.md): Start from GDPR vs UK GDPR What Changes Operationally and answer scope, timing, and interpretation questions with cited outputs. - [Talk through GDPR vs UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for GDPR vs UK GDPR What Changes Operationally. ## International transfers: EU SCCs vs UK IDTA / UK Addendum (the main divergence) Transfers are where the two regimes most commonly force different paperwork. The EU frequently uses Standard Contractual Clauses (SCCs) as a transfer tool; the UK uses its own instruments (IDTA) and also provides a UK Addendum that can be used with EU SCCs in many contracting setups. If your vendor stack is global, build one transfer program that can output: EU SCC package + Transfer Impact Assessment (TIA) approach, and UK IDTA/UK Addendum package where applicable. - EU: SCCs + supplementary measures assessment (and keep the decision memo and evidence). - UK: IDTA or UK Addendum to EU SCCs (choose based on your contracting pattern and counterparties). - Shared control: one vendor inventory + one data flow map + two transfer templates (EU and UK). ## Design a single privacy operating model (two jurisdictional outputs) Most mature programs separate controls from legal views. Controls are stable (security measures, DSAR workflow engine, vendor governance), while legal views are parameterized (deadlines, wording, regulator touchpoints, transfer tools). This reduces cost and risk: you avoid running two programs, but you can still answer what this means for EU users versus UK users with traceable evidence. - Evidence spine: RoPA, DPIAs, policies, training, DSAR logs, breach logs, vendor packs, transfer packs. - Jurisdiction parameters: regulator contacts, response timelines/format expectations, transfer tool selection, notices wording. - Outputs: EU pack (EU GDPR + EDPB guidance), UK pack (UK GDPR + ICO guidance + UK transfer instruments). ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for EU GDPR. - [UK GDPR official text](https://www.legislation.gov.uk/eur/2016/679/contents?ref=sorena.io) - Official source for UK GDPR. - [European Commission: Adequacy decisions](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/adequacy-decisions_en?ref=sorena.io) - Official EU source relevant to EU to UK transfers. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/gdpr-vs-uk-gdpr --- --- title: "GDPR vs UK GDPR" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/gdpr-vs-uk-gdpr" source_url: "https://www.sorena.io/artifacts/eu/gdpr/gdpr-vs-uk-gdpr" author: "Sorena AI" description: "A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications." keywords: - "GDPR vs UK GDPR" - "EU GDPR vs UK GDPR" - "UK GDPR compliance" - "ICO UK GDPR guidance" - "EU GDPR one stop shop" - "EU SCCs vs UK IDTA" - "UK Addendum to EU SCCs" - "international data transfers EU UK" - "EU compliance" - "international data transfers" - "EU SCCs" - "UK IDTA" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR vs UK GDPR A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. *Comparison* *EU / UK* ## GDPR vs UK GDPR What Changes Operationally A comparison designed for implementation teams (not just legal summaries). Focus: scope triggers, regulator structure, transfer tools (EU SCCs vs UK IDTA/Addendum), and a shared evidence model. EU GDPR and UK GDPR are still structurally close, which is why one privacy operating model can often serve both. The main practical differences show up in regulator interaction, transfer instruments, and local guidance. The EU program relies on EDPB positions and EU SCC or adequacy routes, while the UK program relies on the ICO, UK-specific transfer tools such as the IDTA and UK Addendum, and UK legal overlays. The most efficient design is one evidence spine with separate EU and UK legal outputs. ## Quick orientation: same roots, different governance context UK GDPR is the UK's retained version of the GDPR text, operating alongside UK domestic law and UK regulator guidance. EU GDPR is the GDPR as applied in the EU/EEA with EU-wide cooperation mechanisms and EDPB guidance. Operational outcome: you can reuse many controls (records, DSAR workflow, vendor governance, security measures) but you still need jurisdiction-aware decisions, especially for transfers and regulator interactions. - Build one control library and generate separate EU and UK views (owners, evidence, and legal hooks). - Keep a change log for divergence (UK amendments and ICO guidance vs EDPB positions). - Treat transfers as the highest-leverage divergence area (tools and documentation differ). ## Scope triggers: establishment, targeting, monitoring (and why Article 3 still matters) Both regimes are designed to apply beyond borders in certain situations. The practical work is to maintain a product-and-market map that drives which workflows apply (EU, UK, both). If you rely on a we are only in one market assumption, your highest risk is usually marketing, analytics or monitoring, support operations, and vendor processing locations. - Maintain a scope matrix: product -> user base -> establishment -> targeting/monitoring signals -> applicable regime(s). - Define roles per processing: controller/processor (and joint-controller where relevant) and mirror those roles into contracts and DSAR operations. - Use the same evidence spine for both: RoPA, DPIA decisions, vendor register, DSAR logs, incident register. ## Regulator model: one-stop-shop (EU) vs UK ICO (and what it changes) In the EU, cross-border processing can involve cooperation across supervisory authorities (including a lead authority concept). In the UK, the ICO is the primary privacy regulator for UK GDPR and UK domestic data protection rules. Operational outcome: when you run a multi-market product, your incident response, DSAR escalation paths, and accountability evidence should be built to support both an EU supervisory authority inquiry and an ICO inquiry-without reinventing the pack. - Create a regulator-ready evidence index: where each artifact lives, who owns it, update cadence, and export format. - Use consistent definitions and policy language, but keep jurisdiction-specific annexes (EU vs UK) for divergences. - For cross-border operations, predefine primary contacts and escalation paths per market (EU vs UK). *Recommended next step* *Placement: after the comparison section* ## Use GDPR vs UK GDPR What Changes Operationally as a cited research workflow Research Copilot can take GDPR vs UK GDPR What Changes Operationally from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on GDPR vs UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for GDPR vs UK GDPR What Changes Operationally](/solutions/research-copilot.md): Start from GDPR vs UK GDPR What Changes Operationally and answer scope, timing, and interpretation questions with cited outputs. - [Talk through GDPR vs UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for GDPR vs UK GDPR What Changes Operationally. ## International transfers: EU SCCs vs UK IDTA / UK Addendum (the main divergence) Transfers are where the two regimes most commonly force different paperwork. The EU frequently uses Standard Contractual Clauses (SCCs) as a transfer tool; the UK uses its own instruments (IDTA) and also provides a UK Addendum that can be used with EU SCCs in many contracting setups. If your vendor stack is global, build one transfer program that can output: EU SCC package + Transfer Impact Assessment (TIA) approach, and UK IDTA/UK Addendum package where applicable. - EU: SCCs + supplementary measures assessment (and keep the decision memo and evidence). - UK: IDTA or UK Addendum to EU SCCs (choose based on your contracting pattern and counterparties). - Shared control: one vendor inventory + one data flow map + two transfer templates (EU and UK). ## Design a single privacy operating model (two jurisdictional outputs) Most mature programs separate controls from legal views. Controls are stable (security measures, DSAR workflow engine, vendor governance), while legal views are parameterized (deadlines, wording, regulator touchpoints, transfer tools). This reduces cost and risk: you avoid running two programs, but you can still answer what this means for EU users versus UK users with traceable evidence. - Evidence spine: RoPA, DPIAs, policies, training, DSAR logs, breach logs, vendor packs, transfer packs. - Jurisdiction parameters: regulator contacts, response timelines/format expectations, transfer tool selection, notices wording. - Outputs: EU pack (EU GDPR + EDPB guidance), UK pack (UK GDPR + ICO guidance + UK transfer instruments). ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for EU GDPR. - [UK GDPR official text](https://www.legislation.gov.uk/eur/2016/679/contents?ref=sorena.io) - Official source for UK GDPR. - [European Commission: Adequacy decisions](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/adequacy-decisions_en?ref=sorena.io) - Official EU source relevant to EU to UK transfers. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/gdpr-vs-uk-gdpr --- --- title: "GDPR International Transfers (Chapter V) + SCCs" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/international-transfers-and-sccs" source_url: "https://www.sorena.io/artifacts/eu/gdpr/international-transfers-and-sccs" author: "Sorena AI" description: "A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs)." keywords: - "GDPR international transfers" - "GDPR Chapter V" - "SCCs GDPR" - "standard contractual clauses EU" - "transfer impact assessment TIA" - "supplementary measures GDPR" - "adequacy decisions GDPR" - "EU US data transfers GDPR" - "international transfers" - "Chapter V" - "SCCs" - "adequacy decisions" - "TIA" - "supplementary measures" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR International Transfers (Chapter V) + SCCs A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). *Deep Dive* *EU* ## EU GDPR Transfers and SCCs International transfers under GDPR are an operating model, not a clause library. Use adequacy, SCCs, TIAs, supplementary measures, and current EU-US DPF status as parts of one monitored transfer program. Chapter V compliance fails when teams treat a transfer mechanism as a one-time document. Real transfer compliance requires a living map of exporters, importers, destinations, onward transfers, access paths, and the mechanism relied upon for each route. Today that means combining adequacy decisions, the 2021 SCC architecture, transfer impact assessments, supplementary measures where needed, and the current status of frameworks such as the EU-US Data Privacy Framework. ## 1) Start with the transfer map, not the clause pack You cannot choose a lawful transfer mechanism until you know what is actually being transferred, by whom, to where, and with what onward access. The map should be linked to systems, vendors, and sub-processors rather than staying in legal prose. - List exporter, importer, destination country, processing purpose, data categories, and onward transfer chain. - Record whether the transfer is direct, remote access, support access, backup access, or sub-processing. - Tie the transfer route to the relevant processor agreement, SCC module, or adequacy decision. - Keep the map aligned with vendor onboarding, architecture changes, and cloud-region changes. ## 2) Mechanism choice: adequacy first, SCCs where needed, derogations only in limited cases Adequacy decisions are the cleanest transfer route because they remove the need for Article 46 safeguards for the relevant route. Where adequacy is not available, the 2021 SCCs remain the main operational fallback, and Article 49 derogations should stay exceptional. - Check whether the destination benefits from a current adequacy decision before defaulting to SCCs. - Where SCCs are used, pick the correct module and make sure the annexes match the actual processing and sub-processing reality. - Keep TIAs and supplementary-measure decisions with the same route record as the SCCs. - Use Article 49 derogations only for occasional and exceptional cases, not as a standing architecture choice. ## 3) Schrems II means the assessment cannot stop at signature The Court of Justice made clear that controllers and processors must verify whether the recipient can comply with the clauses in the destination country context. That is why TIAs and supplementary measures exist. - Assess local law and practice relevant to government access and enforceability of the safeguards. - Decide whether technical, organisational, or contractual supplementary measures are needed. - Suspend or redesign the route if the safeguards cannot produce an essentially equivalent level of protection. - Review high-risk routes periodically instead of assuming the original assessment stays valid forever. ## 4) Current US transfer context: the EU-US Data Privacy Framework For eligible transfers to participating US organisations, the 10 July 2023 adequacy decision created a current adequacy route. That does not remove the need to verify whether the recipient is actually covered and whether your route matches the framework. - Confirm that the US recipient is certified and appears on the DPF list for the relevant data flows. - Keep evidence of the recipient status and any fallback route if that status changes. - Track the outcome of the first periodic review, which the Commission concluded after the July 2024 review meeting. - Do not leave old Privacy Shield references in RoPAs, notices, or contract annexes. *Recommended next step* *Placement: after the scope or definition section* ## Use EU GDPR Transfers and SCCs as a cited research workflow Research Copilot can take EU GDPR Transfers and SCCs from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU GDPR Transfers and SCCs](/solutions/research-copilot.md): Start from EU GDPR Transfers and SCCs and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Transfers and SCCs. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for Chapter V. - [European Commission: Adequacy decisions](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/adequacy-decisions_en?ref=sorena.io) - Official list of current adequacy routes. - [European Commission: Standard Contractual Clauses overview](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en?ref=sorena.io) - Official SCC resource hub and explanatory material. - [European Commission: EU-US data transfers](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers_en?ref=sorena.io) - Official page for the EU-US Data Privacy Framework. - [Report on the first periodic review of the EU-US Data Privacy Framework](https://commission.europa.eu/document/download/5a6570d0-64f7-4d16-9505-f15128eef4f8_en?ref=sorena.io) - Commission report after the July 2024 first review. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/international-transfers-and-sccs --- --- title: "GDPR International Transfers (Chapter V) + SCCs" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/international-transfers-and-sccs" source_url: "https://www.sorena.io/artifacts/eu/gdpr/international-transfers-and-sccs" author: "Sorena AI" description: "A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs)." keywords: - "GDPR international transfers" - "GDPR Chapter V" - "SCCs GDPR" - "standard contractual clauses EU" - "transfer impact assessment TIA" - "supplementary measures GDPR" - "adequacy decisions GDPR" - "EU US data transfers GDPR" - "international transfers" - "Chapter V" - "SCCs" - "adequacy decisions" - "TIA" - "supplementary measures" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR International Transfers (Chapter V) + SCCs A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). *Deep Dive* *EU* ## EU GDPR Transfers and SCCs International transfers under GDPR are an operating model, not a clause library. Use adequacy, SCCs, TIAs, supplementary measures, and current EU-US DPF status as parts of one monitored transfer program. Chapter V compliance fails when teams treat a transfer mechanism as a one-time document. Real transfer compliance requires a living map of exporters, importers, destinations, onward transfers, access paths, and the mechanism relied upon for each route. Today that means combining adequacy decisions, the 2021 SCC architecture, transfer impact assessments, supplementary measures where needed, and the current status of frameworks such as the EU-US Data Privacy Framework. ## 1) Start with the transfer map, not the clause pack You cannot choose a lawful transfer mechanism until you know what is actually being transferred, by whom, to where, and with what onward access. The map should be linked to systems, vendors, and sub-processors rather than staying in legal prose. - List exporter, importer, destination country, processing purpose, data categories, and onward transfer chain. - Record whether the transfer is direct, remote access, support access, backup access, or sub-processing. - Tie the transfer route to the relevant processor agreement, SCC module, or adequacy decision. - Keep the map aligned with vendor onboarding, architecture changes, and cloud-region changes. ## 2) Mechanism choice: adequacy first, SCCs where needed, derogations only in limited cases Adequacy decisions are the cleanest transfer route because they remove the need for Article 46 safeguards for the relevant route. Where adequacy is not available, the 2021 SCCs remain the main operational fallback, and Article 49 derogations should stay exceptional. - Check whether the destination benefits from a current adequacy decision before defaulting to SCCs. - Where SCCs are used, pick the correct module and make sure the annexes match the actual processing and sub-processing reality. - Keep TIAs and supplementary-measure decisions with the same route record as the SCCs. - Use Article 49 derogations only for occasional and exceptional cases, not as a standing architecture choice. ## 3) Schrems II means the assessment cannot stop at signature The Court of Justice made clear that controllers and processors must verify whether the recipient can comply with the clauses in the destination country context. That is why TIAs and supplementary measures exist. - Assess local law and practice relevant to government access and enforceability of the safeguards. - Decide whether technical, organisational, or contractual supplementary measures are needed. - Suspend or redesign the route if the safeguards cannot produce an essentially equivalent level of protection. - Review high-risk routes periodically instead of assuming the original assessment stays valid forever. ## 4) Current US transfer context: the EU-US Data Privacy Framework For eligible transfers to participating US organisations, the 10 July 2023 adequacy decision created a current adequacy route. That does not remove the need to verify whether the recipient is actually covered and whether your route matches the framework. - Confirm that the US recipient is certified and appears on the DPF list for the relevant data flows. - Keep evidence of the recipient status and any fallback route if that status changes. - Track the outcome of the first periodic review, which the Commission concluded after the July 2024 review meeting. - Do not leave old Privacy Shield references in RoPAs, notices, or contract annexes. *Recommended next step* *Placement: after the scope or definition section* ## Use EU GDPR Transfers and SCCs as a cited research workflow Research Copilot can take EU GDPR Transfers and SCCs from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU GDPR Transfers and SCCs](/solutions/research-copilot.md): Start from EU GDPR Transfers and SCCs and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Transfers and SCCs. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for Chapter V. - [European Commission: Adequacy decisions](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/adequacy-decisions_en?ref=sorena.io) - Official list of current adequacy routes. - [European Commission: Standard Contractual Clauses overview](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en?ref=sorena.io) - Official SCC resource hub and explanatory material. - [European Commission: EU-US data transfers](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers_en?ref=sorena.io) - Official page for the EU-US Data Privacy Framework. - [Report on the first periodic review of the EU-US Data Privacy Framework](https://commission.europa.eu/document/download/5a6570d0-64f7-4d16-9505-f15128eef4f8_en?ref=sorena.io) - Commission report after the July 2024 first review. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/international-transfers-and-sccs --- --- title: "GDPR Lawful Basis (Article 6) + Consent (Article 7)" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/lawful-basis-and-consent" source_url: "https://www.sorena.io/artifacts/eu/gdpr/lawful-basis-and-consent" author: "Sorena AI" description: "A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky." keywords: - "GDPR lawful basis Article 6" - "GDPR consent Article 7" - "legitimate interests GDPR" - "contract necessity GDPR" - "consent withdrawal GDPR" - "consent logs GDPR" - "lawful basis mapping" - "lawful basis" - "consent" - "Article 6" - "Article 7" - "transparency" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR Lawful Basis (Article 6) + Consent (Article 7) A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. *Deep Dive* *EU* ## EU GDPR Lawful Basis and Consent Lawful basis should be mapped per purpose, system behaviour, and notice, not chosen once and forgotten. Consent is only one Article 6 route, and where it is used the proof and withdrawal model must be as strong as the collection flow. The most common lawful-basis failure is not choosing the wrong label once. It is letting the purpose, the actual system behaviour, the notice, and the evidence drift apart over time. A workable GDPR model starts with a purpose register, assigns the lawful basis for each purpose, records why that basis is appropriate, and forces changes through the same review path that governs product and marketing changes. Where consent is used, you also need a proof, withdrawal, and downstream-enforcement model. ## 1) Article 6 basis selection is purpose-specific Do not assign lawful basis by product or by team. Assign it by concrete processing purpose. That is the only way to keep the register aligned with notices, retention, and rights handling. - Maintain a purpose register and attach one lawful basis to each discrete purpose. - Document why contract, legal obligation, legitimate interests, consent, vital interests, public task, or another basis applies. - Review basis selection whenever the purpose, recipient set, analytics pattern, or marketing use changes. - Store the decision with the relevant system owner and policy owner. ## 2) Consent is a workflow, not a banner Where consent is the chosen basis, the organisation must be able to prove what the user was told, what choice they made, and how that choice is enforced across systems. If any of those are missing, the consent design is incomplete. - Capture the consent text version, time, channel, subject identifier, and preference state. - Make withdrawal as easy as giving consent and propagate it to downstream systems without delay. - Separate consent for distinct purposes rather than bundling unrelated choices. - Do not retrofit consent where another basis is more coherent and defensible. ## 3) Legitimate interests needs a balancing record Legitimate interests is often operationally useful, but it needs a real balancing assessment and a clear objection path. Without that record, the basis tends to collapse under scrutiny. - State the legitimate interest pursued, why the processing is necessary, and why the impact on individuals is proportionate. - Check whether children, vulnerable individuals, or unexpected uses change the balance. - Connect the balancing record to the notice and objection workflow. - Review the assessment when profiling, monitoring, or marketing intensity changes. *Recommended next step* *Placement: after the scope or definition section* ## Use EU GDPR Lawful Basis and Consent as a cited research workflow Research Copilot can take EU GDPR Lawful Basis and Consent from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU GDPR Lawful Basis and Consent](/solutions/research-copilot.md): Start from EU GDPR Lawful Basis and Consent and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Lawful Basis and Consent. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for Articles 5 to 7 and related transparency duties. - [EDPB Guidelines 05/2020 on consent](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en?ref=sorena.io) - Official EDPB guidance on valid consent mechanics. - [Irish DPC Article 30 guidance](https://www.dataprotection.ie/en/dpc-guidance/records-of-processing-article-30-guidance?ref=sorena.io) - Useful official guidance for recording Article 6 legal basis in accountability records. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/lawful-basis-and-consent --- --- title: "GDPR Lawful Basis (Article 6) + Consent (Article 7)" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/lawful-basis-and-consent" source_url: "https://www.sorena.io/artifacts/eu/gdpr/lawful-basis-and-consent" author: "Sorena AI" description: "A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky." keywords: - "GDPR lawful basis Article 6" - "GDPR consent Article 7" - "legitimate interests GDPR" - "contract necessity GDPR" - "consent withdrawal GDPR" - "consent logs GDPR" - "lawful basis mapping" - "lawful basis" - "consent" - "Article 6" - "Article 7" - "transparency" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR Lawful Basis (Article 6) + Consent (Article 7) A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. *Deep Dive* *EU* ## EU GDPR Lawful Basis and Consent Lawful basis should be mapped per purpose, system behaviour, and notice, not chosen once and forgotten. Consent is only one Article 6 route, and where it is used the proof and withdrawal model must be as strong as the collection flow. The most common lawful-basis failure is not choosing the wrong label once. It is letting the purpose, the actual system behaviour, the notice, and the evidence drift apart over time. A workable GDPR model starts with a purpose register, assigns the lawful basis for each purpose, records why that basis is appropriate, and forces changes through the same review path that governs product and marketing changes. Where consent is used, you also need a proof, withdrawal, and downstream-enforcement model. ## 1) Article 6 basis selection is purpose-specific Do not assign lawful basis by product or by team. Assign it by concrete processing purpose. That is the only way to keep the register aligned with notices, retention, and rights handling. - Maintain a purpose register and attach one lawful basis to each discrete purpose. - Document why contract, legal obligation, legitimate interests, consent, vital interests, public task, or another basis applies. - Review basis selection whenever the purpose, recipient set, analytics pattern, or marketing use changes. - Store the decision with the relevant system owner and policy owner. ## 2) Consent is a workflow, not a banner Where consent is the chosen basis, the organisation must be able to prove what the user was told, what choice they made, and how that choice is enforced across systems. If any of those are missing, the consent design is incomplete. - Capture the consent text version, time, channel, subject identifier, and preference state. - Make withdrawal as easy as giving consent and propagate it to downstream systems without delay. - Separate consent for distinct purposes rather than bundling unrelated choices. - Do not retrofit consent where another basis is more coherent and defensible. ## 3) Legitimate interests needs a balancing record Legitimate interests is often operationally useful, but it needs a real balancing assessment and a clear objection path. Without that record, the basis tends to collapse under scrutiny. - State the legitimate interest pursued, why the processing is necessary, and why the impact on individuals is proportionate. - Check whether children, vulnerable individuals, or unexpected uses change the balance. - Connect the balancing record to the notice and objection workflow. - Review the assessment when profiling, monitoring, or marketing intensity changes. *Recommended next step* *Placement: after the scope or definition section* ## Use EU GDPR Lawful Basis and Consent as a cited research workflow Research Copilot can take EU GDPR Lawful Basis and Consent from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU GDPR Lawful Basis and Consent](/solutions/research-copilot.md): Start from EU GDPR Lawful Basis and Consent and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Lawful Basis and Consent. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for Articles 5 to 7 and related transparency duties. - [EDPB Guidelines 05/2020 on consent](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en?ref=sorena.io) - Official EDPB guidance on valid consent mechanics. - [Irish DPC Article 30 guidance](https://www.dataprotection.ie/en/dpc-guidance/records-of-processing-article-30-guidance?ref=sorena.io) - Useful official guidance for recording Article 6 legal basis in accountability records. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/lawful-basis-and-consent --- --- title: "GDPR Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/gdpr/penalties-and-fines" author: "Sorena AI" description: "A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift." keywords: - "GDPR fines" - "GDPR penalties" - "Article 83 GDPR fines" - "GDPR enforcement" - "GDPR risk reduction controls" - "GDPR evidence pack" - "GDPR compliance proof" - "administrative fines" - "enforcement" - "risk reduction" - "evidence pack" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR Penalties and Fines A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. *Risk Guide* *EU* ## EU GDPR Penalties and Fines Penalty exposure under GDPR is shaped by both the fine tiers in Article 83 and the quality of your evidence when something goes wrong. The fastest way to reduce enforcement pain is to control the common failure modes and keep the response file ready. Articles 83 and 84 set the penalty structure, but the real driver of outcomes is whether the organisation can show coherent control over the processing in question. GDPR fines operate in two principal tiers, up to EUR 10 million or 2 percent of worldwide annual turnover for one set of infringements, and up to EUR 20 million or 4 percent for the more serious set, with the higher amount applying where relevant. Authorities also consider factors such as gravity, duration, categories of data, intent, mitigation, prior infringements, and cooperation. That means your best penalty-reduction tool is not optimism, it is evidence. ## 1) The Article 83 fine tiers The law does not use one flat fine ceiling. It distinguishes between lower-tier and higher-tier infringements. Your control map should understand which failures sit in which tier. - Lower-tier exposure can reach EUR 10 million or 2 percent of worldwide annual turnover, whichever is higher. - Higher-tier exposure can reach EUR 20 million or 4 percent of worldwide annual turnover, whichever is higher. - Article 84 allows Member States to set additional penalties for infringements not already subject to administrative fines. - Supervisory-authority corrective powers under Article 58 matter alongside fines and often shape the business impact immediately. ## 2) Failure patterns that repeatedly increase exposure The most expensive cases usually combine a substantive failure with poor accountability evidence. The pattern is familiar: the processing is weak, and the file explaining it is worse. - No clear lawful-basis or purpose record for the processing in question. - Broken DSAR workflow or inability to explain what data was searched and disclosed. - Weak vendor and transfer governance, especially around sub-processors and third-country routes. - Poor incident timekeeping and unclear awareness logic in breach cases. - No up-to-date RoPA or DPIA for the activity under scrutiny. ## 3) What the enforcement-ready pack should contain If you can export this pack quickly, enforcement discussions stay factual rather than chaotic. The goal is coherence, not volume. - RoPA extract for the processing activity and the relevant lawful-basis record. - Current and historical notice text, consent evidence where relevant, and policy versions. - DSAR logs or breach file if the case involves rights handling or incident response. - Vendor contract, sub-processor list, transfer mechanism, and TIA or adequacy evidence where relevant. - DPIA, mitigation tracking, and sign-off record for high-risk processing. *Recommended next step* *Placement: after the enforcement section* ## Use EU GDPR Penalties and Fines as a cited research workflow Research Copilot can take EU GDPR Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU GDPR Penalties and Fines](/solutions/research-copilot.md): Start from EU GDPR Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Penalties and Fines. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for Articles 58, 83, and 84. - [European Commission: EU data protection rules overview](https://commission.europa.eu/law/law-topic/data-protection/eu-data-protection-rules_en?ref=sorena.io) - Official Commission overview of the GDPR enforcement framework. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/penalties-and-fines --- --- title: "GDPR Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/gdpr/penalties-and-fines" author: "Sorena AI" description: "A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift." keywords: - "GDPR fines" - "GDPR penalties" - "Article 83 GDPR fines" - "GDPR enforcement" - "GDPR risk reduction controls" - "GDPR evidence pack" - "GDPR compliance proof" - "administrative fines" - "enforcement" - "risk reduction" - "evidence pack" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR Penalties and Fines A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. *Risk Guide* *EU* ## EU GDPR Penalties and Fines Penalty exposure under GDPR is shaped by both the fine tiers in Article 83 and the quality of your evidence when something goes wrong. The fastest way to reduce enforcement pain is to control the common failure modes and keep the response file ready. Articles 83 and 84 set the penalty structure, but the real driver of outcomes is whether the organisation can show coherent control over the processing in question. GDPR fines operate in two principal tiers, up to EUR 10 million or 2 percent of worldwide annual turnover for one set of infringements, and up to EUR 20 million or 4 percent for the more serious set, with the higher amount applying where relevant. Authorities also consider factors such as gravity, duration, categories of data, intent, mitigation, prior infringements, and cooperation. That means your best penalty-reduction tool is not optimism, it is evidence. ## 1) The Article 83 fine tiers The law does not use one flat fine ceiling. It distinguishes between lower-tier and higher-tier infringements. Your control map should understand which failures sit in which tier. - Lower-tier exposure can reach EUR 10 million or 2 percent of worldwide annual turnover, whichever is higher. - Higher-tier exposure can reach EUR 20 million or 4 percent of worldwide annual turnover, whichever is higher. - Article 84 allows Member States to set additional penalties for infringements not already subject to administrative fines. - Supervisory-authority corrective powers under Article 58 matter alongside fines and often shape the business impact immediately. ## 2) Failure patterns that repeatedly increase exposure The most expensive cases usually combine a substantive failure with poor accountability evidence. The pattern is familiar: the processing is weak, and the file explaining it is worse. - No clear lawful-basis or purpose record for the processing in question. - Broken DSAR workflow or inability to explain what data was searched and disclosed. - Weak vendor and transfer governance, especially around sub-processors and third-country routes. - Poor incident timekeeping and unclear awareness logic in breach cases. - No up-to-date RoPA or DPIA for the activity under scrutiny. ## 3) What the enforcement-ready pack should contain If you can export this pack quickly, enforcement discussions stay factual rather than chaotic. The goal is coherence, not volume. - RoPA extract for the processing activity and the relevant lawful-basis record. - Current and historical notice text, consent evidence where relevant, and policy versions. - DSAR logs or breach file if the case involves rights handling or incident response. - Vendor contract, sub-processor list, transfer mechanism, and TIA or adequacy evidence where relevant. - DPIA, mitigation tracking, and sign-off record for high-risk processing. *Recommended next step* *Placement: after the enforcement section* ## Use EU GDPR Penalties and Fines as a cited research workflow Research Copilot can take EU GDPR Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU GDPR Penalties and Fines](/solutions/research-copilot.md): Start from EU GDPR Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Penalties and Fines. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for Articles 58, 83, and 84. - [European Commission: EU data protection rules overview](https://commission.europa.eu/law/law-topic/data-protection/eu-data-protection-rules_en?ref=sorena.io) - Official Commission overview of the GDPR enforcement framework. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/penalties-and-fines --- --- title: "GDPR Processor Contracts (Article 28) + Vendor Management" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/processor-contracts-and-vendor-management" source_url: "https://www.sorena.io/artifacts/eu/gdpr/processor-contracts-and-vendor-management" author: "Sorena AI" description: "A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles." keywords: - "GDPR Article 28 processor contract" - "GDPR DPA checklist" - "sub-processor management GDPR" - "vendor risk management GDPR" - "SCCs vendor contracts" - "processor audit rights GDPR" - "GDPR vendor due diligence" - "Article 28" - "processor contract" - "vendor management" - "sub-processors" - "SCCs" - "security evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR Processor Contracts (Article 28) + Vendor Management A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. *Deep Dive* *EU* ## EU GDPR Vendor Management Article 28 compliance is a contract and operations discipline, not just a procurement checkbox. Use the 2021 controller-processor clauses, sub-processor governance, breach-assistance rules, and transfer mapping to keep vendor reality aligned with the paper. Vendor compliance fails when contracts say one thing and systems do another. The GDPR standard for processors is not just to sign a DPA. Controllers must use processors providing sufficient guarantees, the contract must contain the Article 28 elements, sub-processor use must be controlled, and the operational reality, security, incident escalation, remote access, transfer routes, retention, and deletion, has to match the contract pack. That is why vendor management under GDPR is a live control framework rather than a procurement document set. ## 1) Role and service-model check before contract drafting The first failure mode is role confusion. Some service providers act as processors for some tasks and independent controllers for others. Map the service model before you negotiate clauses. - Identify the subject matter, duration, nature, and purpose of the processing. - Map data categories, data-subject categories, and whether the supplier determines any purposes or essential means itself. - Separate processor services from controller-controlled analytics, benchmarking, or service-improvement uses. - Tie the role map to procurement and security review so the contract follows the real service design. ## 2) Article 28 clause set and the 2021 standard clauses The contract needs the Article 28(3) and (4) elements, but many organisations still use stale or incomplete clause packs. The Commission adopted standard controller-processor clauses on 4 June 2021 that can be used or incorporated in broader contracts. - Make sure the agreement covers instructions, confidentiality, security, assistance, deletion or return, audits, and sub-processor controls. - Where the Commission 2021/915 clauses are used, align the annexes with the actual service and data flow. - Remember that the Article 28 standard clauses are not the same thing as Chapter V transfer SCCs. - Keep one source of truth for signed DPA versions and annexes. ## 3) Sub-processor governance and change control Sub-processor management is often the point where the paper trail breaks. Article 28 requires prior specific or general written authorisation and meaningful change notice. That needs more than a hidden webpage link. - Maintain the authorised sub-processor list and the notice period for changes. - Require the processor to impose equivalent obligations on each sub-processor. - Check how transfer routes change when new sub-processors or support regions are added. - Keep objection decisions and remediation actions in the vendor record. ## 4) Ongoing monitoring: prove the processor still provides sufficient guarantees Processor diligence does not end at signature. The controller must keep checking that the practical guarantees still exist. This is where audit evidence, security evidence, and incident performance matter. - Refresh security evidence, certifications, penetration-test summaries, and incident history on a defined cadence. - Test breach-assistance and escalation performance, not just the contractual wording. - Map each processor to its transfer mechanism, cloud-region choices, and onward transfers. - Retire or renegotiate stale clauses, including any packs that still mention Privacy Shield or obsolete SCC models. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU GDPR Vendor Management in one governed evidence system SSOT can take EU GDPR Vendor Management from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU GDPR Vendor Management](/solutions/ssot.md): Start from EU GDPR Vendor Management and keep documents, evidence, and control records in one governed system. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Vendor Management. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for Article 28 and related processor duties. - [European Commission Implementing Decision (EU) 2021/915](https://eur-lex.europa.eu/eli/dec_impl/2021/915/oj/eng?ref=sorena.io) - Official standard contractual clauses for controller-processor relationships under Article 28(7). - [EDPB Guidelines 07/2020 on controller and processor concepts](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor-gdpr_en?ref=sorena.io) - Official guidance on role determination and processor boundaries. - [European Commission: Standard Contractual Clauses overview](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en?ref=sorena.io) - Official resource for Chapter V clauses where transfers are embedded in the vendor relationship. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/processor-contracts-and-vendor-management --- --- title: "GDPR Processor Contracts (Article 28) + Vendor Management" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/processor-contracts-and-vendor-management" source_url: "https://www.sorena.io/artifacts/eu/gdpr/processor-contracts-and-vendor-management" author: "Sorena AI" description: "A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles." keywords: - "GDPR Article 28 processor contract" - "GDPR DPA checklist" - "sub-processor management GDPR" - "vendor risk management GDPR" - "SCCs vendor contracts" - "processor audit rights GDPR" - "GDPR vendor due diligence" - "Article 28" - "processor contract" - "vendor management" - "sub-processors" - "SCCs" - "security evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR Processor Contracts (Article 28) + Vendor Management A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. *Deep Dive* *EU* ## EU GDPR Vendor Management Article 28 compliance is a contract and operations discipline, not just a procurement checkbox. Use the 2021 controller-processor clauses, sub-processor governance, breach-assistance rules, and transfer mapping to keep vendor reality aligned with the paper. Vendor compliance fails when contracts say one thing and systems do another. The GDPR standard for processors is not just to sign a DPA. Controllers must use processors providing sufficient guarantees, the contract must contain the Article 28 elements, sub-processor use must be controlled, and the operational reality, security, incident escalation, remote access, transfer routes, retention, and deletion, has to match the contract pack. That is why vendor management under GDPR is a live control framework rather than a procurement document set. ## 1) Role and service-model check before contract drafting The first failure mode is role confusion. Some service providers act as processors for some tasks and independent controllers for others. Map the service model before you negotiate clauses. - Identify the subject matter, duration, nature, and purpose of the processing. - Map data categories, data-subject categories, and whether the supplier determines any purposes or essential means itself. - Separate processor services from controller-controlled analytics, benchmarking, or service-improvement uses. - Tie the role map to procurement and security review so the contract follows the real service design. ## 2) Article 28 clause set and the 2021 standard clauses The contract needs the Article 28(3) and (4) elements, but many organisations still use stale or incomplete clause packs. The Commission adopted standard controller-processor clauses on 4 June 2021 that can be used or incorporated in broader contracts. - Make sure the agreement covers instructions, confidentiality, security, assistance, deletion or return, audits, and sub-processor controls. - Where the Commission 2021/915 clauses are used, align the annexes with the actual service and data flow. - Remember that the Article 28 standard clauses are not the same thing as Chapter V transfer SCCs. - Keep one source of truth for signed DPA versions and annexes. ## 3) Sub-processor governance and change control Sub-processor management is often the point where the paper trail breaks. Article 28 requires prior specific or general written authorisation and meaningful change notice. That needs more than a hidden webpage link. - Maintain the authorised sub-processor list and the notice period for changes. - Require the processor to impose equivalent obligations on each sub-processor. - Check how transfer routes change when new sub-processors or support regions are added. - Keep objection decisions and remediation actions in the vendor record. ## 4) Ongoing monitoring: prove the processor still provides sufficient guarantees Processor diligence does not end at signature. The controller must keep checking that the practical guarantees still exist. This is where audit evidence, security evidence, and incident performance matter. - Refresh security evidence, certifications, penetration-test summaries, and incident history on a defined cadence. - Test breach-assistance and escalation performance, not just the contractual wording. - Map each processor to its transfer mechanism, cloud-region choices, and onward transfers. - Retire or renegotiate stale clauses, including any packs that still mention Privacy Shield or obsolete SCC models. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU GDPR Vendor Management in one governed evidence system SSOT can take EU GDPR Vendor Management from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU GDPR Vendor Management](/solutions/ssot.md): Start from EU GDPR Vendor Management and keep documents, evidence, and control records in one governed system. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Vendor Management. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for Article 28 and related processor duties. - [European Commission Implementing Decision (EU) 2021/915](https://eur-lex.europa.eu/eli/dec_impl/2021/915/oj/eng?ref=sorena.io) - Official standard contractual clauses for controller-processor relationships under Article 28(7). - [EDPB Guidelines 07/2020 on controller and processor concepts](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor-gdpr_en?ref=sorena.io) - Official guidance on role determination and processor boundaries. - [European Commission: Standard Contractual Clauses overview](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en?ref=sorena.io) - Official resource for Chapter V clauses where transfers are embedded in the vendor relationship. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/processor-contracts-and-vendor-management --- --- title: "GDPR RoPA Template (Article 30)" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/record-of-processing-activities-template" source_url: "https://www.sorena.io/artifacts/eu/gdpr/record-of-processing-activities-template" author: "Sorena AI" description: "A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields." keywords: - "GDPR RoPA template" - "Article 30 RoPA" - "record of processing activities template" - "GDPR Article 30 fields" - "RoPA example" - "GDPR accountability documentation" - "RoPA" - "Article 30" - "record of processing" - "template" - "accountability" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR RoPA Template (Article 30) A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. *Template* *EU* ## EU GDPR RoPA Template A RoPA is the accountability spine for GDPR, not a decorative spreadsheet. Use Article 30, the narrow Article 30(5) exemption, and the Irish DPC guidance to build a standalone record that can be produced quickly on request. A good RoPA is self-contained, current, and useful. It should let the organisation explain what it processes, why it processes it, who receives it, how long it keeps it, what transfers occur, and which security measures protect it. The Irish DPC guidance is especially useful because it makes clear that a RoPA should be a standalone record, not a web of hyperlinks or a bundle of separate DPIAs, and that many smaller organisations still need one because the Article 30(5) exemption is much narrower than teams assume. ## 1) Article 30 controller and processor minimum fields The law specifies mandatory fields for controllers and a parallel set for processors. Start there, then add helpful extras without burying the required core. Treat controller and processor RoPAs as different record types, not a single blended table. - Controller fields include names and contacts, purposes, categories of data subjects and data, recipients, transfers and safeguards, retention periods, and a general description of security measures. - Processor records must identify each controller, the categories of processing, transfers and safeguards, and security measures. - Keep the mandatory fields visually obvious even if you add helpful extras such as legal basis or risk references. - Store the record in writing, including electronic form, and ensure it can be produced on request. ## 2) The Article 30(5) exemption is limited Many teams overread the fewer-than-250-persons exemption and assume no RoPA is needed. That is often wrong. The exemption falls away where the processing is not occasional, involves special-category or criminal-offence data, or is likely to risk rights and freedoms. - Do not rely on headcount alone to skip a RoPA. - Document exactly which activities, if any, qualify for the exemption and why. - Remember that many ordinary functions such as HR, payroll, security monitoring, and customer operations will still trigger a record. - Use one register to track both full and limited-exemption reasoning so the position stays defensible. ## 3) What makes a RoPA usable in practice A usable RoPA supports DSARs, DPIAs, breach response, vendor reviews, and transfer mapping. A weak RoPA slows all of them down. The DPC guidance is particularly clear about the patterns that fail. - Keep the RoPA as a standalone document or system report that can be exported cleanly. - Do not leave obsolete transfer mechanisms or stale recipients in the record. - Assign process owners in each business function rather than leaving the whole record to the DPO alone. - Make sure the record can be delivered quickly; the Irish DPC guidance notes that ten days should generally be sufficient notice. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU GDPR RoPA Template in one governed evidence system SSOT can take EU GDPR RoPA Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU GDPR RoPA Template](/solutions/ssot.md): Start from EU GDPR RoPA Template and keep documents, evidence, and control records in one governed system. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR RoPA Template. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for Article 30 and the Article 30(5) exemption. - [Irish DPC guidance on Records of Processing under Article 30](https://www.dataprotection.ie/en/dpc-guidance/records-of-processing-article-30-guidance?ref=sorena.io) - Detailed official guidance on practical RoPA structure and common failures. - [EDPB Guidelines 07/2020 on controller and processor concepts](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor-gdpr_en?ref=sorena.io) - Useful for structuring separate controller and processor records correctly. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/record-of-processing-activities-template --- --- title: "GDPR RoPA Template (Article 30)" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/record-of-processing-activities-template" source_url: "https://www.sorena.io/artifacts/eu/gdpr/record-of-processing-activities-template" author: "Sorena AI" description: "A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields." keywords: - "GDPR RoPA template" - "Article 30 RoPA" - "record of processing activities template" - "GDPR Article 30 fields" - "RoPA example" - "GDPR accountability documentation" - "RoPA" - "Article 30" - "record of processing" - "template" - "accountability" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GDPR RoPA Template (Article 30) A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. *Template* *EU* ## EU GDPR RoPA Template A RoPA is the accountability spine for GDPR, not a decorative spreadsheet. Use Article 30, the narrow Article 30(5) exemption, and the Irish DPC guidance to build a standalone record that can be produced quickly on request. A good RoPA is self-contained, current, and useful. It should let the organisation explain what it processes, why it processes it, who receives it, how long it keeps it, what transfers occur, and which security measures protect it. The Irish DPC guidance is especially useful because it makes clear that a RoPA should be a standalone record, not a web of hyperlinks or a bundle of separate DPIAs, and that many smaller organisations still need one because the Article 30(5) exemption is much narrower than teams assume. ## 1) Article 30 controller and processor minimum fields The law specifies mandatory fields for controllers and a parallel set for processors. Start there, then add helpful extras without burying the required core. Treat controller and processor RoPAs as different record types, not a single blended table. - Controller fields include names and contacts, purposes, categories of data subjects and data, recipients, transfers and safeguards, retention periods, and a general description of security measures. - Processor records must identify each controller, the categories of processing, transfers and safeguards, and security measures. - Keep the mandatory fields visually obvious even if you add helpful extras such as legal basis or risk references. - Store the record in writing, including electronic form, and ensure it can be produced on request. ## 2) The Article 30(5) exemption is limited Many teams overread the fewer-than-250-persons exemption and assume no RoPA is needed. That is often wrong. The exemption falls away where the processing is not occasional, involves special-category or criminal-offence data, or is likely to risk rights and freedoms. - Do not rely on headcount alone to skip a RoPA. - Document exactly which activities, if any, qualify for the exemption and why. - Remember that many ordinary functions such as HR, payroll, security monitoring, and customer operations will still trigger a record. - Use one register to track both full and limited-exemption reasoning so the position stays defensible. ## 3) What makes a RoPA usable in practice A usable RoPA supports DSARs, DPIAs, breach response, vendor reviews, and transfer mapping. A weak RoPA slows all of them down. The DPC guidance is particularly clear about the patterns that fail. - Keep the RoPA as a standalone document or system report that can be exported cleanly. - Do not leave obsolete transfer mechanisms or stale recipients in the record. - Assign process owners in each business function rather than leaving the whole record to the DPO alone. - Make sure the record can be delivered quickly; the Irish DPC guidance notes that ten days should generally be sufficient notice. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU GDPR RoPA Template in one governed evidence system SSOT can take EU GDPR RoPA Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU GDPR RoPA Template](/solutions/ssot.md): Start from EU GDPR RoPA Template and keep documents, evidence, and control records in one governed system. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR RoPA Template. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for Article 30 and the Article 30(5) exemption. - [Irish DPC guidance on Records of Processing under Article 30](https://www.dataprotection.ie/en/dpc-guidance/records-of-processing-article-30-guidance?ref=sorena.io) - Detailed official guidance on practical RoPA structure and common failures. - [EDPB Guidelines 07/2020 on controller and processor concepts](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor-gdpr_en?ref=sorena.io) - Useful for structuring separate controller and processor records correctly. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [EU GDPR Requirements (Regulation (EU) 2016/679) | Obligations Map: Scope, Rights, Security, DPIA, Vendors, Transfers + Evidence Index](/artifacts/eu/gdpr/requirements.md): A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/record-of-processing-activities-template --- --- title: "EU GDPR Requirements (Regulation (EU) 2016/679)" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/requirements" source_url: "https://www.sorena.io/artifacts/eu/gdpr/requirements" author: "Sorena AI" description: "A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14)." keywords: - "GDPR requirements" - "GDPR obligations" - "GDPR requirements checklist" - "GDPR evidence index" - "GDPR Article 30 RoPA" - "GDPR Article 28 processor contract" - "GDPR Chapter V transfers" - "GDPR DSAR requirements" - "obligations map" - "evidence index" - "DSAR" - "DPIA" - "transfers" - "vendors" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GDPR Requirements (Regulation (EU) 2016/679) A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). *Requirements Guide* *EU* ## EU GDPR Requirements A requirements-to-controls map you can implement and prove. Focus: obligations, owners, evidence artifacts, and operational workflows. GDPR requirements become manageable when they are translated into controls and evidence tied to the real processing landscape. The core map should connect scope and roles, Article 5 principles, Article 6 lawful-basis choices, transparency and rights handling, accountability and RoPA maintenance, Article 28 vendor controls, Article 32 security, Article 33 and 34 breach handling, Article 35 DPIAs, and Chapter V transfers. Each requirement area should have an owner, a workflow, and an exportable proof set. ## Scope, principles, and legal basis The foundation is a coherent scope and purpose model. Without that, everything downstream drifts. Tie each purpose to the role, lawful basis, notice, retention, and key systems. - Article 2 to 4 applicability and definitions. - Article 5 principles and accountability evidence. - Article 6 lawful basis per purpose and Article 7 consent proof where relevant. - Article 27 representative analysis where territorial scope requires it. ## Rights, accountability, and operations GDPR is operational law. The requirements only become real when you can execute them at system level. This is where RoPA, DSAR workflows, and processor management connect. - Articles 12 to 22 rights workflows and logging. - Article 24 accountability and governance ownership. - Article 28 processor contracts and sub-processor controls. - Article 30 RoPA maintenance, including transfers and security measures. - Article 31 cooperation readiness for supervisory-authority requests. ## Security, risk, transfers, and enforcement The highest-pressure GDPR moments are usually incidents, DPIAs, and transfer escalations. Build those as disciplined systems, not ad hoc legal projects. Your evidence map should make those moments easier, not harder. - Article 32 security controls tied to risk and system design. - Articles 33 and 34 incident classification, timing, and communication rules. - Articles 35 and 36 DPIA and prior consultation workflow. - Articles 44 to 49 transfer mechanisms, adequacy, SCCs, TIAs, and derogations. - Articles 58, 83, and 84 enforcement and penalty context. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU GDPR Requirements into an operational assessment Assessment Autopilot can take EU GDPR Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GDPR Requirements](/solutions/assessment.md): Start from EU GDPR Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Requirements. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for the obligations map. - [EDPB Guidelines 07/2020 on controller and processor concepts](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor-gdpr_en?ref=sorena.io) - Useful official interpretation for role allocation. - [European Commission: Standard Contractual Clauses overview](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en?ref=sorena.io) - Official source for current transfer-tool implementation. - [Irish DPC guidance on Records of Processing under Article 30](https://www.dataprotection.ie/en/dpc-guidance/records-of-processing-article-30-guidance?ref=sorena.io) - Useful official accountability guidance for RoPA design. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/requirements --- --- title: "EU GDPR Requirements (Regulation (EU) 2016/679)" canonical_url: "https://www.sorena.io/artifacts/eu/gdpr/requirements" source_url: "https://www.sorena.io/artifacts/eu/gdpr/requirements" author: "Sorena AI" description: "A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14)." keywords: - "GDPR requirements" - "GDPR obligations" - "GDPR requirements checklist" - "GDPR evidence index" - "GDPR Article 30 RoPA" - "GDPR Article 28 processor contract" - "GDPR Chapter V transfers" - "GDPR DSAR requirements" - "obligations map" - "evidence index" - "DSAR" - "DPIA" - "transfers" - "vendors" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GDPR Requirements (Regulation (EU) 2016/679) A practical GDPR requirements breakdown: scope (Articles 2-3), principles (Article 5), lawful basis (Article 6-7), transparency (Articles 12-14). *Requirements Guide* *EU* ## EU GDPR Requirements A requirements-to-controls map you can implement and prove. Focus: obligations, owners, evidence artifacts, and operational workflows. GDPR requirements become manageable when they are translated into controls and evidence tied to the real processing landscape. The core map should connect scope and roles, Article 5 principles, Article 6 lawful-basis choices, transparency and rights handling, accountability and RoPA maintenance, Article 28 vendor controls, Article 32 security, Article 33 and 34 breach handling, Article 35 DPIAs, and Chapter V transfers. Each requirement area should have an owner, a workflow, and an exportable proof set. ## Scope, principles, and legal basis The foundation is a coherent scope and purpose model. Without that, everything downstream drifts. Tie each purpose to the role, lawful basis, notice, retention, and key systems. - Article 2 to 4 applicability and definitions. - Article 5 principles and accountability evidence. - Article 6 lawful basis per purpose and Article 7 consent proof where relevant. - Article 27 representative analysis where territorial scope requires it. ## Rights, accountability, and operations GDPR is operational law. The requirements only become real when you can execute them at system level. This is where RoPA, DSAR workflows, and processor management connect. - Articles 12 to 22 rights workflows and logging. - Article 24 accountability and governance ownership. - Article 28 processor contracts and sub-processor controls. - Article 30 RoPA maintenance, including transfers and security measures. - Article 31 cooperation readiness for supervisory-authority requests. ## Security, risk, transfers, and enforcement The highest-pressure GDPR moments are usually incidents, DPIAs, and transfer escalations. Build those as disciplined systems, not ad hoc legal projects. Your evidence map should make those moments easier, not harder. - Article 32 security controls tied to risk and system design. - Articles 33 and 34 incident classification, timing, and communication rules. - Articles 35 and 36 DPIA and prior consultation workflow. - Articles 44 to 49 transfer mechanisms, adequacy, SCCs, TIAs, and derogations. - Articles 58, 83, and 84 enforcement and penalty context. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU GDPR Requirements into an operational assessment Assessment Autopilot can take EU GDPR Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GDPR Requirements](/solutions/assessment.md): Start from EU GDPR Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GDPR](/contact.md): Review your current process, evidence gaps, and next steps for EU GDPR Requirements. ## Primary sources - [GDPR full text - Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504&ref=sorena.io) - Primary source for the obligations map. - [EDPB Guidelines 07/2020 on controller and processor concepts](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor-gdpr_en?ref=sorena.io) - Useful official interpretation for role allocation. - [European Commission: Standard Contractual Clauses overview](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en?ref=sorena.io) - Official source for current transfer-tool implementation. - [Irish DPC guidance on Records of Processing under Article 30](https://www.dataprotection.ie/en/dpc-guidance/records-of-processing-article-30-guidance?ref=sorena.io) - Useful official accountability guidance for RoPA design. ## Related Topic Guides - [EU GDPR Checklist (Regulation (EU) 2016/679) | Audit-Ready Controls, Owners, Evidence, and Common Pitfalls](/artifacts/eu/gdpr/checklist.md): An audit-ready GDPR checklist: scope and role mapping, lawful basis and consent, transparency and notices, DSAR workflows, DPIA governance, security measures. - [EU GDPR Compliance Guide | Build a Repeatable Program: Inventory, Controls, Evidence, and Operating Cadence](/artifacts/eu/gdpr/compliance.md): An execution-oriented GDPR compliance guide for Regulation (EU) 2016/679: program setup, governance, control design, evidence exports. - [EU GDPR FAQ | Practical Answers: Scope, Consent, DSAR, DPIA, Breach (72h), Transfers/SCCs, Vendor Contracts](/artifacts/eu/gdpr/faq.md): Frequently asked GDPR questions answered with practical implementation guidance: does GDPR apply (Article 3), what counts as personal data. - [GDPR Applicability Test (Article 2-3) | Territorial Scope, Establishment vs Targeting, Roles, and Edge Cases](/artifacts/eu/gdpr/applicability-test.md): A practical GDPR applicability test for Regulation (EU) 2016/679: check material scope (Article 2), territorial scope (Article 3), establishment vs targeting. - [GDPR Breach Notification (72 Hours) | Article 33-34 Workflow, Awareness Timestamp, Risk Test, and Evidence Pack](/artifacts/eu/gdpr/breach-notification-72-hours.md): An execution-ready guide to GDPR breach notification built on Articles 33 and 34, the EDPB breach-notification guidelines. - [GDPR Data Subject Rights + DSAR Workflow | Articles 12-22 Playbook: Intake, Identity, Search, Response, Exceptions, Evidence](/artifacts/eu/gdpr/data-subject-rights-and-dsar-workflow.md): A practical DSAR (data subject access request) playbook for GDPR Articles 12-22: build intake and identity verification, define system search scope. - [GDPR Deadlines and Compliance Calendar | DSAR 1-Month SLA, Breach 72 Hours, DPIA Cadence, Vendor Reviews, Transfer Monitoring](/artifacts/eu/gdpr/deadlines-and-compliance-calendar.md): A grounded GDPR compliance calendar that combines fixed legal milestones, 27 April 2016 adoption, 25 May 2018 application, the 2021 SCC overhaul. - [GDPR DPIA (Article 35) + Risk Management | Triggers, Template, Controls, Residual Risk Sign-off, and Prior Consultation (Article 36)](/artifacts/eu/gdpr/dpia-and-risk-management.md): A practical DPIA guide for GDPR Articles 35-36: how to screen for DPIA triggers, run a risk assessment focused on rights/freedoms. - [GDPR International Transfers (Chapter V) + SCCs | Transfer Map, Adequacy, SCC Packs, TIA, Supplementary Measures, and Monitoring](/artifacts/eu/gdpr/international-transfers-and-sccs.md): A practical guide to GDPR international transfers (Chapter V): how to build a transfer map, choose mechanisms (adequacy vs SCCs). - [GDPR Lawful Basis (Article 6) + Consent (Article 7) | How to Choose, Document, Implement, and Prove Compliance](/artifacts/eu/gdpr/lawful-basis-and-consent.md): A practical guide to GDPR lawful bases (Article 6) and consent (Article 7): how to select a lawful basis per purpose, when consent is appropriate vs risky. - [GDPR Penalties and Fines | Articles 83-84 Explained + Risk Reduction Controls and Evidence](/artifacts/eu/gdpr/penalties-and-fines.md): A practical penalties guide for GDPR enforcement: how administrative fines work under Articles 83-84, what factors drive exposure (purpose drift. - [GDPR Processor Contracts (Article 28) + Vendor Management | DPA Checklist, Sub-processors, Security Evidence, Transfers/SCCs](/artifacts/eu/gdpr/processor-contracts-and-vendor-management.md): A practical vendor management guide for GDPR: how to operationalize Article 28 processor contracts, define controller vs processor roles. - [GDPR RoPA Template (Article 30) | Record of Processing Activities: Fields, Examples, and Evidence Tips](/artifacts/eu/gdpr/record-of-processing-activities-template.md): A practical Record of Processing Activities (RoPA) template for GDPR Article 30: controller and processor fields. - [GDPR vs CCPA/CPRA | Key Differences in Scope, Rights, Legal Bases, and Operational Compliance (DSAR, Vendors, Transfers)](/artifacts/eu/gdpr/gdpr-vs-ccpa.md): A practical comparison of GDPR (EU) and CCPA/CPRA (California): differences in applicability triggers, roles, legal bases versus sale/share models. - [GDPR vs UK GDPR | Practical Differences for Scope, Enforcement, Transfers (EU SCCs vs UK IDTA/Addendum), and Evidence](/artifacts/eu/gdpr/gdpr-vs-uk-gdpr.md): A practical comparison of EU GDPR and UK GDPR: territorial scope triggers, regulator structure (one-stop-shop vs ICO), cross-border processing implications. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/gdpr/requirements --- --- title: "EU GPSR Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/applicability-test" author: "Sorena AI" description: "A step-by-step EU GPSR applicability test for Regulation (EU) 2023/988: confirm whether your products are covered, whether exclusions apply." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU GPSR applicability test" - "is GPSR applicable" - "Regulation (EU) 2023/988 applicability" - "GPSR scope test" - "GPSR exclusions" - "GPSR online marketplace scope" - "economic operator role GPSR" - "product safety regulation EU" - "GPSR applicability" - "scope" - "covered products" - "economic operators" - "online marketplaces" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GPSR Applicability Test A step-by-step EU GPSR applicability test for Regulation (EU) 2023/988: confirm whether your products are covered, whether exclusions apply. *Scope* *EU* ## EU GPSR Applicability Test A decision-grade scoping test: covered product, exclusion, channel, and role. Outcome: which GPSR workflows you must implement (documentation, notifications, recall readiness). Use this applicability test to produce a reproducible decision: in scope / out of scope / partially in scope (GPSR complements sector rules). Document your answers and evidence links-this is what authorities and partners ask for when product safety is questioned. ## Step 1 - Identify the product and the consumer context GPSR is centered on products made available to consumers. The tricky cases are products designed for professional use that later reach the consumer market, and mixed-use products. Write down a plain-language intended use statement and the expected user population. - What is the product category and intended use (consumer / professional / mixed)? - Does the product reasonably end up with consumers (secondary market, resale, rental, services)? - What are the key hazards across the lifecycle (design, manufacturing, distribution, use, end-of-life)? ## Step 2 - Check exclusions and sector-rule overlap Don't treat exclusions as assumptions. You need a traceable rationale: what is excluded, and which legal framework governs instead. Many real products are 'partial overlap': sector rules govern core specs, but GPSR still drives operational duties (monitoring, corrective actions, recall execution). - Is there sector-specific EU product legislation covering the product's key risks? - If yes: what risks/processes remain that GPSR still influences (recall comms, notification workflows)? - Do you sell used/repaired/reconditioned goods, and can you evidence safety checks and traceability? ## Step 3 - Map channel + role (this changes obligations) GPSR obligations are role-aware. The same company can hold multiple roles across products and channels (manufacturer for one line, importer for another, distributor in some markets). Treat this as an operating model problem: build a RACI map and assign evidence owners. - Which economic operator role(s) apply for this product and channel? - Is the product offered via an online marketplace (additional operational obligations and interfaces)? - Who owns: risk assessment, documentation, notifications, listing removal, recall execution? ## Step 4 - Output: pick your path + evidence inputs Your result should be a short decision memo with evidence links, not a vague conclusion. If you are in scope, the minimum viable program is: safe product controls + documentation + incident/recall readiness + Safety Gate notification capability. - Outcome A: out of scope - documented exclusion + alternate framework + review triggers. - Outcome B: in scope - implement requirements, role duties, documentation/traceability, Safety Gate workflow, recall readiness. - Outcome C: partial overlap - implement GPSR operational workflows while sector rules govern core product specs. *Recommended next step* *Placement: after the applicability result* ## Turn EU GPSR Applicability Test into an operational assessment Assessment Autopilot can take EU GPSR Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU GPSR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GPSR Applicability Test](/solutions/assessment.md): Start from EU GPSR Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GPSR](/contact.md): Review your current process, evidence gaps, and next steps for EU GPSR Applicability Test. ## Primary sources - [GPSR full text - Regulation (EU) 2023/988 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02023R0988-20230523&ref=sorena.io) - Primary source for scope, definitions, and role-based obligations. - [Market surveillance framework - Regulation (EU) 2019/1020 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02019R1020-20240523&ref=sorena.io) - Useful context for authority powers and enforcement posture when you're in scope. ## Related Topic Guides - [EU GPSR Checklist | Audit-Ready Compliance Checklist for Regulation (EU) 2023/988 (Safety Gate, Recalls, Marketplaces, Evidence)](/artifacts/eu/general-product-safety-regulation/checklist.md): An audit-ready EU GPSR checklist for Regulation (EU) 2023/988: scope and role mapping, documentation and traceability, supplier evidence. - [EU GPSR Compliance Program | Operating Model, Governance, Controls, and Evidence for Regulation (EU) 2023/988](/artifacts/eu/general-product-safety-regulation/compliance.md): A practical EU GPSR compliance playbook for Regulation (EU) 2023/988: program setup, governance cadence, risk assessment controls. - [EU GPSR Deadlines and Compliance Calendar | Key Dates, Workstreams, and Operational Milestones (Safety Gate, Recalls, Marketplaces)](/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar.md): A practical EU GPSR calendar for Regulation (EU) 2023/988: key dates and operational milestones, with a workstream-based plan covering scope and role mapping. - [EU GPSR Economic Operator Duties | Manufacturer vs Importer vs Distributor vs Fulfilment vs Marketplace Roles + Evidence](/artifacts/eu/general-product-safety-regulation/economic-operator-duties.md): A practical guide to EU GPSR economic operator duties under Regulation (EU) 2023/988: how to map roles across your supply chain. - [EU GPSR FAQ | Common Questions About Regulation (EU) 2023/988 (Scope, Online Marketplaces, Safety Gate, Recalls)](/artifacts/eu/general-product-safety-regulation/faq.md): Answers to common EU GPSR questions: scope and exclusions, used/repaired products, online marketplaces, Safety Gate/Safety Business Gateway notifications. - [EU GPSR Online Marketplace Obligations | Safety Gate Interface (2024/1459), Unsafe Product Removal, Notices, and Evidence](/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations.md): A practical guide for online marketplaces under EU GPSR (Regulation (EU) 2023/988): who is a 'provider of an online marketplace'. - [EU GPSR Penalties and Enforcement | Market Surveillance, Corrective Actions, and How to Reduce Risk With Evidence](/artifacts/eu/general-product-safety-regulation/penalties-and-fines.md): A practical guide to enforcement under EU GPSR (Regulation (EU) 2023/988): how market surveillance works, what enforcement actions look like (restrictions. - [EU GPSR Product Recall Notice Template | How to Use Implementing Regulation (EU) 2024/1435 (Article 36)](/artifacts/eu/general-product-safety-regulation/product-recall-notice-template.md): A practical guide to the EU GPSR recall notice template: when it applies, how to fill it correctly, what evidence to retain. - [EU GPSR Recalls and Incident Management | Corrective Actions, Safety Gate Notifications, Recall Effectiveness, Playbooks](/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management.md): A practical recall and incident management playbook for EU GPSR (Regulation (EU) 2023/988): build a triage workflow, decide corrective actions vs recall. - [EU GPSR Requirements (Regulation (EU) 2023/988) | Obligations, Controls, Safety Gate Notifications, and Evidence](/artifacts/eu/general-product-safety-regulation/requirements.md): An implementation-grade breakdown of EU GPSR requirements under Regulation (EU) 2023/988: safe product lifecycle controls, risk assessment. - [EU GPSR Scope and Covered Products | What's In/Out, Overlap With Sector Rules, Online Sales, Used/Reconditioned Goods](/artifacts/eu/general-product-safety-regulation/scope-and-covered-products.md): A practical GPSR scope guide for Regulation (EU) 2023/988: what products are covered, common exclusions. - [EU GPSR Traceability and Documentation | Product Safety Evidence Packs, Supplier Data, and Audit-Ready Records](/artifacts/eu/general-product-safety-regulation/traceability-and-documentation.md): A practical GPSR documentation and traceability guide for Regulation (EU) 2023/988: what information to maintain. - [GPSR vs Market Surveillance Regulation (EU) 2019/1020 | What's Different, What Overlaps, and What to Build](/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Market Surveillance Regulation (EU) 2019/1020: what each governs. - [GPSR vs Product Liability Directive (85/374/EEC) | Safety Obligations vs Liability Risk, Recalls, Evidence, and Claims Readiness](/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Product Liability Directive (85/374/EEC). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/general-product-safety-regulation/applicability-test --- --- title: "EU GPSR Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/checklist" source_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/checklist" author: "Sorena AI" description: "An audit-ready EU GPSR checklist for Regulation (EU) 2023/988: scope and role mapping, documentation and traceability, supplier evidence." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU GPSR checklist" - "Regulation (EU) 2023/988 checklist" - "product safety compliance checklist EU" - "Safety Gate checklist" - "Safety Business Gateway checklist" - "recall readiness checklist" - "online marketplace GPSR checklist" - "GPSR checklist" - "product safety compliance" - "Safety Gate" - "recall readiness" - "marketplaces" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GPSR Checklist An audit-ready EU GPSR checklist for Regulation (EU) 2023/988: scope and role mapping, documentation and traceability, supplier evidence. *Checklist* *EU* ## EU GPSR Checklist An audit-ready checklist with owners, evidence, and acceptance criteria. Use this to run a GPSR readiness review and build a repeatable safety operating model. A useful GPSR checklist is not a list of obligations-it's a set of deliverables. Use this checklist to assign owners, define acceptance criteria, and build a single evidence pack that supports authority inquiries and marketplace escalations. ## 1) Scope + role mapping (foundation) Goal: a documented scope decision per product category and a role map per channel. Done looks like: a scope memo + RACI that another reviewer can reproduce. - Product taxonomy -> applicable rule sets (GPSR + sector overlaps + exclusions rationale). - Economic operator role map per product/channel (manufacturer/importer/distributor/fulfilment/marketplace). - Escalation list and backups (product safety lead, legal, comms, ops, marketplace). ## 2) Documentation + traceability (make evidence exportable) Goal: reduce time-to-evidence. A real incident will demand identifiers, markets, actions, and proof quickly. Done looks like: an evidence index + traceability schema across systems. - Evidence index: artifact -> owner -> system-of-record -> refresh cadence. - Traceability schema: SKU/model + batch/lot/serial (as applicable) + supplier linkage + channel linkage. - Supplier evidence request template + change notification requirements. ## 3) Incident and recall readiness (execution capability) Goal: triage -> decide corrective action -> execute recall/withdrawal -> measure effectiveness. Done looks like: a tested playbook and prebuilt comms. - Triage workflow with severity tiers and decision memo template. - Corrective action catalog (stop-ship, delist, quarantine, repair/replace/refund). - Recall comms library + call center scripts + localization plan + effectiveness metrics. ## 4) Safety Gate readiness (tooling + data packs + logs) Goal: you can submit required notifications without scrambling for access or missing data. Done looks like: access provisioning + data pack templates + submission logs. - Safety Business Gateway access (primary + backup users) and drill evidence. - Notification data pack template (identifiers, risk description, corrective actions, markets, contacts). - Notification log linking to incident records and evidence artifacts. ## 5) Online marketplaces (if you operate one or sell through one) Goal: platform-level notice handling and rapid removal capability with audit logs. Done looks like: a notice-to-action workflow and interface readiness evidence where required. - Notice-to-action state machine with timestamps and removal proof. - Safety Gate interface plan/monitoring for marketplace obligations (where applicable). - Seller governance and listing validation rules for high-risk categories. *Recommended next step* *Placement: after the checklist block* ## Turn EU GPSR Checklist into an operational assessment Assessment Autopilot can take EU GPSR Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU GPSR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GPSR Checklist](/solutions/assessment.md): Start from EU GPSR Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GPSR](/contact.md): Review your current process, evidence gaps, and next steps for EU GPSR Checklist. ## Primary sources - [GPSR full text - Regulation (EU) 2023/988 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02023R0988-20230523&ref=sorena.io) - Primary source for scope, duties, corrective actions, and notification expectations. - [Recall notice template - Implementing Regulation (EU) 2024/1435 (EUR-Lex consolidated HTML)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02024R1435-20240527&ref=sorena.io) - Recall notice template that should be integrated into your playbook. - [Online marketplace interface rules - Implementing Regulation (EU) 2024/1459 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1459&ref=sorena.io) - Marketplace interoperability and interface requirements tied to Safety Gate Portal. ## Related Topic Guides - [EU GPSR Applicability Test | Is Regulation (EU) 2023/988 Applicable to Your Product, Channel, and Role?](/artifacts/eu/general-product-safety-regulation/applicability-test.md): A step-by-step EU GPSR applicability test for Regulation (EU) 2023/988: confirm whether your products are covered, whether exclusions apply. - [EU GPSR Compliance Program | Operating Model, Governance, Controls, and Evidence for Regulation (EU) 2023/988](/artifacts/eu/general-product-safety-regulation/compliance.md): A practical EU GPSR compliance playbook for Regulation (EU) 2023/988: program setup, governance cadence, risk assessment controls. - [EU GPSR Deadlines and Compliance Calendar | Key Dates, Workstreams, and Operational Milestones (Safety Gate, Recalls, Marketplaces)](/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar.md): A practical EU GPSR calendar for Regulation (EU) 2023/988: key dates and operational milestones, with a workstream-based plan covering scope and role mapping. - [EU GPSR Economic Operator Duties | Manufacturer vs Importer vs Distributor vs Fulfilment vs Marketplace Roles + Evidence](/artifacts/eu/general-product-safety-regulation/economic-operator-duties.md): A practical guide to EU GPSR economic operator duties under Regulation (EU) 2023/988: how to map roles across your supply chain. - [EU GPSR FAQ | Common Questions About Regulation (EU) 2023/988 (Scope, Online Marketplaces, Safety Gate, Recalls)](/artifacts/eu/general-product-safety-regulation/faq.md): Answers to common EU GPSR questions: scope and exclusions, used/repaired products, online marketplaces, Safety Gate/Safety Business Gateway notifications. - [EU GPSR Online Marketplace Obligations | Safety Gate Interface (2024/1459), Unsafe Product Removal, Notices, and Evidence](/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations.md): A practical guide for online marketplaces under EU GPSR (Regulation (EU) 2023/988): who is a 'provider of an online marketplace'. - [EU GPSR Penalties and Enforcement | Market Surveillance, Corrective Actions, and How to Reduce Risk With Evidence](/artifacts/eu/general-product-safety-regulation/penalties-and-fines.md): A practical guide to enforcement under EU GPSR (Regulation (EU) 2023/988): how market surveillance works, what enforcement actions look like (restrictions. - [EU GPSR Product Recall Notice Template | How to Use Implementing Regulation (EU) 2024/1435 (Article 36)](/artifacts/eu/general-product-safety-regulation/product-recall-notice-template.md): A practical guide to the EU GPSR recall notice template: when it applies, how to fill it correctly, what evidence to retain. - [EU GPSR Recalls and Incident Management | Corrective Actions, Safety Gate Notifications, Recall Effectiveness, Playbooks](/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management.md): A practical recall and incident management playbook for EU GPSR (Regulation (EU) 2023/988): build a triage workflow, decide corrective actions vs recall. - [EU GPSR Requirements (Regulation (EU) 2023/988) | Obligations, Controls, Safety Gate Notifications, and Evidence](/artifacts/eu/general-product-safety-regulation/requirements.md): An implementation-grade breakdown of EU GPSR requirements under Regulation (EU) 2023/988: safe product lifecycle controls, risk assessment. - [EU GPSR Scope and Covered Products | What's In/Out, Overlap With Sector Rules, Online Sales, Used/Reconditioned Goods](/artifacts/eu/general-product-safety-regulation/scope-and-covered-products.md): A practical GPSR scope guide for Regulation (EU) 2023/988: what products are covered, common exclusions. - [EU GPSR Traceability and Documentation | Product Safety Evidence Packs, Supplier Data, and Audit-Ready Records](/artifacts/eu/general-product-safety-regulation/traceability-and-documentation.md): A practical GPSR documentation and traceability guide for Regulation (EU) 2023/988: what information to maintain. - [GPSR vs Market Surveillance Regulation (EU) 2019/1020 | What's Different, What Overlaps, and What to Build](/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Market Surveillance Regulation (EU) 2019/1020: what each governs. - [GPSR vs Product Liability Directive (85/374/EEC) | Safety Obligations vs Liability Risk, Recalls, Evidence, and Claims Readiness](/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Product Liability Directive (85/374/EEC). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/general-product-safety-regulation/checklist --- --- title: "EU GPSR Compliance Program" canonical_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/compliance" source_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/compliance" author: "Sorena AI" description: "A practical EU GPSR compliance playbook for Regulation (EU) 2023/988: program setup, governance cadence, risk assessment controls." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU GPSR compliance program" - "Regulation (EU) 2023/988 compliance" - "product safety operating model EU" - "Safety Gate workflow" - "Safety Business Gateway" - "recall readiness program" - "online marketplace compliance GPSR" - "product safety governance" - "GPSR compliance" - "product safety program" - "governance" - "Safety Gate" - "recall readiness" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GPSR Compliance Program A practical EU GPSR compliance playbook for Regulation (EU) 2023/988: program setup, governance cadence, risk assessment controls. *Playbook* *EU* ## EU GPSR Compliance Program Turn GPSR into an operating model: controls, workflows, owners, and evidence. Best practice: one product safety system that scales across product lines and channels. Compliance is not a document set-it's a product safety operating system. GPSR forces cross-functional coordination (product, quality, legal, operations, support, marketplaces). This page outlines a program structure you can implement: governance, controls, workflows, and evidence exports. ## Program structure (workstreams and owners) Start by splitting GPSR into workstreams with clear owners and measurable acceptance criteria. The 'owner' is the person accountable for evidence freshness, not just a stakeholder. Use a RACI for each product category and channel. - Workstream A: scope + role mapping (catalog + exclusions + RACI). - Workstream B: risk assessment + safe product lifecycle controls. - Workstream C: documentation + traceability + supplier evidence governance. - Workstream D: incident/recall capability + comms + effectiveness measurement. - Workstream E: Safety Gate/Safety Business Gateway + marketplace obligations (where applicable). ## Governance cadence (keep the program alive) GPSR programs degrade when they are 'one-time projects'. Build a cadence with defined inputs and outputs. Governance should be lightweight but non-negotiable: evidence freshness is a recurring responsibility. - Quarterly review: scope changes, new markets/channels, supplier changes, incident trends. - Monthly review: open actions, test evidence refresh, marketplace notices, Safety Gate monitoring. - Post-incident review: what worked, what failed, and what the evidence pack lacked. ## Controls that matter (what auditors and authorities focus on) The most valuable controls are those that prevent unsafe products and those that ensure rapid action when issues arise. Prioritize controls that reduce time-to-detection and time-to-action. - Risk assessment method per product family (including vulnerable users and foreseeable misuse). - Change control gates (supplier/component/firmware changes trigger review). - Post-market monitoring and signal triage (support + returns + marketplace). ## Evidence operating system (build once, reuse everywhere) Your evidence system should allow exports by view: product view, market view, channel view, incident view. This reduces friction across regulators, marketplaces, partners, and internal leadership. - Evidence index + owners + refresh cadence (single source-of-truth). - Standard templates: decision memos, notification packs, recall notice generator, comms library. - Logs: incident timeline, notifications submitted, takedowns/delisting proof, effectiveness metrics. *Recommended next step* *Placement: after the compliance steps* ## Turn EU GPSR Compliance Program into an operational assessment Assessment Autopilot can take EU GPSR Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU GPSR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GPSR Compliance Program](/solutions/assessment.md): Start from EU GPSR Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GPSR](/contact.md): Review your current process, evidence gaps, and next steps for EU GPSR Compliance Program. ## Primary sources - [GPSR full text - Regulation (EU) 2023/988 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02023R0988-20230523&ref=sorena.io) - Primary source for GPSR program obligations and role-based expectations. - [Safety Business Gateway (tool)](https://webgate.ec.europa.eu/safety-business-gateway/?ref=sorena.io) - Operational tooling for certain submissions referenced in Commission material. ## Related Topic Guides - [EU GPSR Applicability Test | Is Regulation (EU) 2023/988 Applicable to Your Product, Channel, and Role?](/artifacts/eu/general-product-safety-regulation/applicability-test.md): A step-by-step EU GPSR applicability test for Regulation (EU) 2023/988: confirm whether your products are covered, whether exclusions apply. - [EU GPSR Checklist | Audit-Ready Compliance Checklist for Regulation (EU) 2023/988 (Safety Gate, Recalls, Marketplaces, Evidence)](/artifacts/eu/general-product-safety-regulation/checklist.md): An audit-ready EU GPSR checklist for Regulation (EU) 2023/988: scope and role mapping, documentation and traceability, supplier evidence. - [EU GPSR Deadlines and Compliance Calendar | Key Dates, Workstreams, and Operational Milestones (Safety Gate, Recalls, Marketplaces)](/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar.md): A practical EU GPSR calendar for Regulation (EU) 2023/988: key dates and operational milestones, with a workstream-based plan covering scope and role mapping. - [EU GPSR Economic Operator Duties | Manufacturer vs Importer vs Distributor vs Fulfilment vs Marketplace Roles + Evidence](/artifacts/eu/general-product-safety-regulation/economic-operator-duties.md): A practical guide to EU GPSR economic operator duties under Regulation (EU) 2023/988: how to map roles across your supply chain. - [EU GPSR FAQ | Common Questions About Regulation (EU) 2023/988 (Scope, Online Marketplaces, Safety Gate, Recalls)](/artifacts/eu/general-product-safety-regulation/faq.md): Answers to common EU GPSR questions: scope and exclusions, used/repaired products, online marketplaces, Safety Gate/Safety Business Gateway notifications. - [EU GPSR Online Marketplace Obligations | Safety Gate Interface (2024/1459), Unsafe Product Removal, Notices, and Evidence](/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations.md): A practical guide for online marketplaces under EU GPSR (Regulation (EU) 2023/988): who is a 'provider of an online marketplace'. - [EU GPSR Penalties and Enforcement | Market Surveillance, Corrective Actions, and How to Reduce Risk With Evidence](/artifacts/eu/general-product-safety-regulation/penalties-and-fines.md): A practical guide to enforcement under EU GPSR (Regulation (EU) 2023/988): how market surveillance works, what enforcement actions look like (restrictions. - [EU GPSR Product Recall Notice Template | How to Use Implementing Regulation (EU) 2024/1435 (Article 36)](/artifacts/eu/general-product-safety-regulation/product-recall-notice-template.md): A practical guide to the EU GPSR recall notice template: when it applies, how to fill it correctly, what evidence to retain. - [EU GPSR Recalls and Incident Management | Corrective Actions, Safety Gate Notifications, Recall Effectiveness, Playbooks](/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management.md): A practical recall and incident management playbook for EU GPSR (Regulation (EU) 2023/988): build a triage workflow, decide corrective actions vs recall. - [EU GPSR Requirements (Regulation (EU) 2023/988) | Obligations, Controls, Safety Gate Notifications, and Evidence](/artifacts/eu/general-product-safety-regulation/requirements.md): An implementation-grade breakdown of EU GPSR requirements under Regulation (EU) 2023/988: safe product lifecycle controls, risk assessment. - [EU GPSR Scope and Covered Products | What's In/Out, Overlap With Sector Rules, Online Sales, Used/Reconditioned Goods](/artifacts/eu/general-product-safety-regulation/scope-and-covered-products.md): A practical GPSR scope guide for Regulation (EU) 2023/988: what products are covered, common exclusions. - [EU GPSR Traceability and Documentation | Product Safety Evidence Packs, Supplier Data, and Audit-Ready Records](/artifacts/eu/general-product-safety-regulation/traceability-and-documentation.md): A practical GPSR documentation and traceability guide for Regulation (EU) 2023/988: what information to maintain. - [GPSR vs Market Surveillance Regulation (EU) 2019/1020 | What's Different, What Overlaps, and What to Build](/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Market Surveillance Regulation (EU) 2019/1020: what each governs. - [GPSR vs Product Liability Directive (85/374/EEC) | Safety Obligations vs Liability Risk, Recalls, Evidence, and Claims Readiness](/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Product Liability Directive (85/374/EEC). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/general-product-safety-regulation/compliance --- --- title: "EU GPSR Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A practical EU GPSR calendar for Regulation (EU) 2023/988: key dates and operational milestones, with a workstream-based plan covering scope and role mapping." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU GPSR deadlines" - "GPSR compliance calendar" - "Regulation (EU) 2023/988 key dates" - "GPSR applies 13 December 2024" - "Safety Gate deadlines" - "online marketplace interface 2024/1459" - "recall notice template 2024/1435" - "GPSR deadlines" - "compliance calendar" - "Safety Gate" - "online marketplaces" - "recall readiness" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GPSR Deadlines and Compliance Calendar A practical EU GPSR calendar for Regulation (EU) 2023/988: key dates and operational milestones, with a workstream-based plan covering scope and role mapping. *Calendar* *EU* ## EU GPSR Deadlines and Compliance Calendar Turn key dates into a workstream plan with owners and evidence outputs. Focus: documentation, Safety Gate workflows, marketplaces, and recall readiness. Dates alone do not deliver compliance. Workstreams do. Use this page to translate GPSR milestones into an execution calendar: what must be ready in product, ops, marketplace, and legal workflows, and what evidence you should be able to export at each stage. This complements the timeline view on the main GPSR hub. ## Key dates to anchor your plan The GPSR text and related implementing and delegated measures drive concrete readiness points, including recall notices, online marketplace registration, Safety Gate workflows, and later Commission reviews. Treat these as forcing functions to build capabilities, not as simple go live checkboxes. - 10 May 2023: GPSR adopted. 23 May 2023: published in the Official Journal. 13 December 2024: GPSR applies and repeals the old GPSD. - 27 May 2024 and 28 May 2024: recall notice template (EU) 2024/1435 and marketplace interface rules (EU) 2024/1459 published, both applying from 13 December 2024. - 24 June 2024 and 10 October 2024: consumer-reporting rules (EU) 2024/1740 and single-contact-point rules (EU) 2024/2639 published for the broader Safety Gate system. - 13 December 2026: Commission report due on the interconnection between the market-surveillance information system and the Safety Gate Portal. - 13 December 2027: Commission assessment due on the Union notification system for illegal content removal by online marketplaces. - 13 December 2029: Commission evaluation due on the Regulation overall and on the effectiveness of penalties. ## Workstream calendar (what to build first) Most teams should sequence work by dependency: you can't execute a recall without traceability, and you can't notify without a data pack and tooling access. Use a workstream calendar with named owners and measurable acceptance criteria. - Workstream A: scope + role mapping (catalog, exclusions, RACI). - Workstream B: documentation + traceability (evidence pack + supplier inputs). - Workstream C: incident/recall playbook (triage, comms, effectiveness). - Workstream D: Safety Gate/Safety Business Gateway readiness (access, templates, logging). - Workstream E: marketplace program (Article 22 registration, optional 2024/1459 interface linkage, notice and takedown SLAs, logs). *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU GPSR Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take EU GPSR Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU GPSR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GPSR Deadlines and Compliance Calendar](/solutions/assessment.md): Start from EU GPSR Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GPSR](/contact.md): Review your current process, evidence gaps, and next steps for EU GPSR Deadlines and Compliance Calendar. ## Evidence you should have ready by each milestone GPSR programs get tested during incidents. Your calendar should include evidence readiness checkpoints. If you can't export evidence quickly, you haven't built the program yet. - Evidence index + owners + refresh cadence (single source-of-truth). - Recall notice template generator inputs (identifiers, hazards, Article 37 remedies, channels, accessibility checks). - Notification packs and submission logs (what was submitted, when, completeness checks, and follow-up handling). ## Primary sources - [GPSR full text - Regulation (EU) 2023/988 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02023R0988-20230523&ref=sorena.io) - Primary text for GPSR obligations and timelines. - [Recall notice template - Implementing Regulation (EU) 2024/1435 (EUR-Lex consolidated HTML)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02024R1435-20240527&ref=sorena.io) - Template for recall notices; includes application date in the legal text. - [Online marketplace interface rules - Implementing Regulation (EU) 2024/1459 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1459&ref=sorena.io) - Marketplace interoperability and interface requirements tied to Safety Gate Portal. - [Commission Q&A on GPSR implementing and delegated regulations](https://webgate.ec.europa.eu/safety-gate-screen/webReport/guide/qaImplementingAndDelegatedRegulations?ref=sorena.io) - Useful Commission explanation of how the 2024 implementing and delegated acts fit together. - [Safety Business Gateway (tool)](https://webgate.ec.europa.eu/safety-business-gateway/?ref=sorena.io) - Operational tooling for submissions referenced in Commission material. ## Related Topic Guides - [EU GPSR Applicability Test | Is Regulation (EU) 2023/988 Applicable to Your Product, Channel, and Role?](/artifacts/eu/general-product-safety-regulation/applicability-test.md): A step-by-step EU GPSR applicability test for Regulation (EU) 2023/988: confirm whether your products are covered, whether exclusions apply. - [EU GPSR Checklist | Audit-Ready Compliance Checklist for Regulation (EU) 2023/988 (Safety Gate, Recalls, Marketplaces, Evidence)](/artifacts/eu/general-product-safety-regulation/checklist.md): An audit-ready EU GPSR checklist for Regulation (EU) 2023/988: scope and role mapping, documentation and traceability, supplier evidence. - [EU GPSR Compliance Program | Operating Model, Governance, Controls, and Evidence for Regulation (EU) 2023/988](/artifacts/eu/general-product-safety-regulation/compliance.md): A practical EU GPSR compliance playbook for Regulation (EU) 2023/988: program setup, governance cadence, risk assessment controls. - [EU GPSR Economic Operator Duties | Manufacturer vs Importer vs Distributor vs Fulfilment vs Marketplace Roles + Evidence](/artifacts/eu/general-product-safety-regulation/economic-operator-duties.md): A practical guide to EU GPSR economic operator duties under Regulation (EU) 2023/988: how to map roles across your supply chain. - [EU GPSR FAQ | Common Questions About Regulation (EU) 2023/988 (Scope, Online Marketplaces, Safety Gate, Recalls)](/artifacts/eu/general-product-safety-regulation/faq.md): Answers to common EU GPSR questions: scope and exclusions, used/repaired products, online marketplaces, Safety Gate/Safety Business Gateway notifications. - [EU GPSR Online Marketplace Obligations | Safety Gate Interface (2024/1459), Unsafe Product Removal, Notices, and Evidence](/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations.md): A practical guide for online marketplaces under EU GPSR (Regulation (EU) 2023/988): who is a 'provider of an online marketplace'. - [EU GPSR Penalties and Enforcement | Market Surveillance, Corrective Actions, and How to Reduce Risk With Evidence](/artifacts/eu/general-product-safety-regulation/penalties-and-fines.md): A practical guide to enforcement under EU GPSR (Regulation (EU) 2023/988): how market surveillance works, what enforcement actions look like (restrictions. - [EU GPSR Product Recall Notice Template | How to Use Implementing Regulation (EU) 2024/1435 (Article 36)](/artifacts/eu/general-product-safety-regulation/product-recall-notice-template.md): A practical guide to the EU GPSR recall notice template: when it applies, how to fill it correctly, what evidence to retain. - [EU GPSR Recalls and Incident Management | Corrective Actions, Safety Gate Notifications, Recall Effectiveness, Playbooks](/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management.md): A practical recall and incident management playbook for EU GPSR (Regulation (EU) 2023/988): build a triage workflow, decide corrective actions vs recall. - [EU GPSR Requirements (Regulation (EU) 2023/988) | Obligations, Controls, Safety Gate Notifications, and Evidence](/artifacts/eu/general-product-safety-regulation/requirements.md): An implementation-grade breakdown of EU GPSR requirements under Regulation (EU) 2023/988: safe product lifecycle controls, risk assessment. - [EU GPSR Scope and Covered Products | What's In/Out, Overlap With Sector Rules, Online Sales, Used/Reconditioned Goods](/artifacts/eu/general-product-safety-regulation/scope-and-covered-products.md): A practical GPSR scope guide for Regulation (EU) 2023/988: what products are covered, common exclusions. - [EU GPSR Traceability and Documentation | Product Safety Evidence Packs, Supplier Data, and Audit-Ready Records](/artifacts/eu/general-product-safety-regulation/traceability-and-documentation.md): A practical GPSR documentation and traceability guide for Regulation (EU) 2023/988: what information to maintain. - [GPSR vs Market Surveillance Regulation (EU) 2019/1020 | What's Different, What Overlaps, and What to Build](/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Market Surveillance Regulation (EU) 2019/1020: what each governs. - [GPSR vs Product Liability Directive (85/374/EEC) | Safety Obligations vs Liability Risk, Recalls, Evidence, and Claims Readiness](/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Product Liability Directive (85/374/EEC). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar --- --- title: "EU GPSR Economic Operator Duties" canonical_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/economic-operator-duties" source_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/economic-operator-duties" author: "Sorena AI" description: "A practical guide to EU GPSR economic operator duties under Regulation (EU) 2023/988: how to map roles across your supply chain." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU GPSR economic operator duties" - "manufacturer importer distributor obligations GPSR" - "fulfilment service provider GPSR" - "online marketplace provider duties GPSR" - "Regulation (EU) 2023/988 roles" - "product safety responsibilities EU" - "Safety Gate notification duties" - "economic operator" - "manufacturer" - "importer" - "distributor" - "fulfilment service provider" - "online marketplaces" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GPSR Economic Operator Duties A practical guide to EU GPSR economic operator duties under Regulation (EU) 2023/988: how to map roles across your supply chain. *Roles* *EU* ## EU GPSR Economic Operator Duties Role mapping is the foundation of a defensible product safety program. Outcome: clear owners, contracts, and evidence responsibilities per product and channel. Most GPSR failures are ownership failures: nobody is sure who must act, what evidence is required, or who can trigger corrective actions. Use this page to map economic operator roles and turn them into a RACI, contracts, and a single evidence spine that supports both authority inquiries and marketplace escalations. ## Start with a role map (per product, per channel) GPSR obligations attach to roles. The same company can hold multiple roles across products and channels (e.g., manufacturer for one line, importer for another, distributor in certain markets). Operational outcome: build a role map that is explicit, versioned, and tied to product identifiers and sales channels. - Per product family: who is manufacturer, importer, distributor, fulfilment service provider, marketplace (if applicable). - Per channel: direct sales, marketplace sales, resellers, cross-border shipments, returns/refurbishment flows. - Per duty: who owns risk assessment, documentation, monitoring, notifications, corrective actions, and recalls. ## Manufacturer duties (control the safety lifecycle) Manufacturers typically own product design safety, risk assessment, technical documentation, and corrective action initiation. The practical requirement is not 'have a document'-it's 'can you prove your safety decisions and act quickly when signals appear?'. Build a manufacturer evidence pack that is exportable and can be shared with importers/distributors when needed. - Design controls: hazard analysis, foreseeable misuse, vulnerable user considerations, warnings/instructions. - Change control: supplier/component changes trigger safety review gates. - Corrective action: decision criteria, recall triggers, and effectiveness measurement. ## Importer and distributor duties (gatekeeping + monitoring) Importers and distributors are not passive. They act as gatekeepers: ensure documentation and safety signals are handled, and coordinate corrective action and notifications when problems arise in their markets. Operational outcome: define 'release to market' checks and post-market monitoring responsibilities for each role. - Inbound checks: documentation presence, product identifiers, traceability fields, warnings/instructions availability. - Market monitoring: complaints, returns, authority notices, and Safety Gate alerts relevant to your catalog. - Escalation: structured handoffs to manufacturers and internal product safety owners. ## Fulfilment and marketplaces (don't ignore these roles) GPSR recognizes modern supply chains. Fulfilment providers can be key points of control for cross-border e-commerce. Online marketplaces have platform-level duties and system interfaces. Operational outcome: integrate product safety into platform operations: listing governance, notice processing, and rapid removal/recall execution. - Fulfilment: ensure traceability and process readiness for corrective actions and notifications. - Marketplace: implement interface readiness and internal SLAs for unsafe product actions. - Shared evidence: one product safety pack, two operational views (seller vs platform). ## Build one evidence spine (so the program scales) A scalable program uses one evidence spine: every role contributes to the same evidence index, with clearly owned responsibilities and refresh cadence. This reduces incident-time conflict: instead of debating responsibility, you follow a pre-agreed RACI and playbook. - Role map + RACI + escalation list (backups included). - Documentation pack + traceability data + supplier evidence requests. - Incident/recall playbook + Safety Gate notification workflow + logs. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU GPSR Economic Operator Duties as a cited research workflow Research Copilot can take EU GPSR Economic Operator Duties from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU GPSR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU GPSR Economic Operator Duties](/solutions/research-copilot.md): Start from EU GPSR Economic Operator Duties and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU GPSR](/contact.md): Review your current process, evidence gaps, and next steps for EU GPSR Economic Operator Duties. ## Primary sources - [GPSR full text - Regulation (EU) 2023/988 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02023R0988-20230523&ref=sorena.io) - Primary source for role-based obligations and corrective action/notification expectations. - [Safety Business Gateway (tool)](https://webgate.ec.europa.eu/safety-business-gateway/?ref=sorena.io) - Operational reference for notification submission tooling used by economic operators and online marketplaces. ## Related Topic Guides - [EU GPSR Applicability Test | Is Regulation (EU) 2023/988 Applicable to Your Product, Channel, and Role?](/artifacts/eu/general-product-safety-regulation/applicability-test.md): A step-by-step EU GPSR applicability test for Regulation (EU) 2023/988: confirm whether your products are covered, whether exclusions apply. - [EU GPSR Checklist | Audit-Ready Compliance Checklist for Regulation (EU) 2023/988 (Safety Gate, Recalls, Marketplaces, Evidence)](/artifacts/eu/general-product-safety-regulation/checklist.md): An audit-ready EU GPSR checklist for Regulation (EU) 2023/988: scope and role mapping, documentation and traceability, supplier evidence. - [EU GPSR Compliance Program | Operating Model, Governance, Controls, and Evidence for Regulation (EU) 2023/988](/artifacts/eu/general-product-safety-regulation/compliance.md): A practical EU GPSR compliance playbook for Regulation (EU) 2023/988: program setup, governance cadence, risk assessment controls. - [EU GPSR Deadlines and Compliance Calendar | Key Dates, Workstreams, and Operational Milestones (Safety Gate, Recalls, Marketplaces)](/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar.md): A practical EU GPSR calendar for Regulation (EU) 2023/988: key dates and operational milestones, with a workstream-based plan covering scope and role mapping. - [EU GPSR FAQ | Common Questions About Regulation (EU) 2023/988 (Scope, Online Marketplaces, Safety Gate, Recalls)](/artifacts/eu/general-product-safety-regulation/faq.md): Answers to common EU GPSR questions: scope and exclusions, used/repaired products, online marketplaces, Safety Gate/Safety Business Gateway notifications. - [EU GPSR Online Marketplace Obligations | Safety Gate Interface (2024/1459), Unsafe Product Removal, Notices, and Evidence](/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations.md): A practical guide for online marketplaces under EU GPSR (Regulation (EU) 2023/988): who is a 'provider of an online marketplace'. - [EU GPSR Penalties and Enforcement | Market Surveillance, Corrective Actions, and How to Reduce Risk With Evidence](/artifacts/eu/general-product-safety-regulation/penalties-and-fines.md): A practical guide to enforcement under EU GPSR (Regulation (EU) 2023/988): how market surveillance works, what enforcement actions look like (restrictions. - [EU GPSR Product Recall Notice Template | How to Use Implementing Regulation (EU) 2024/1435 (Article 36)](/artifacts/eu/general-product-safety-regulation/product-recall-notice-template.md): A practical guide to the EU GPSR recall notice template: when it applies, how to fill it correctly, what evidence to retain. - [EU GPSR Recalls and Incident Management | Corrective Actions, Safety Gate Notifications, Recall Effectiveness, Playbooks](/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management.md): A practical recall and incident management playbook for EU GPSR (Regulation (EU) 2023/988): build a triage workflow, decide corrective actions vs recall. - [EU GPSR Requirements (Regulation (EU) 2023/988) | Obligations, Controls, Safety Gate Notifications, and Evidence](/artifacts/eu/general-product-safety-regulation/requirements.md): An implementation-grade breakdown of EU GPSR requirements under Regulation (EU) 2023/988: safe product lifecycle controls, risk assessment. - [EU GPSR Scope and Covered Products | What's In/Out, Overlap With Sector Rules, Online Sales, Used/Reconditioned Goods](/artifacts/eu/general-product-safety-regulation/scope-and-covered-products.md): A practical GPSR scope guide for Regulation (EU) 2023/988: what products are covered, common exclusions. - [EU GPSR Traceability and Documentation | Product Safety Evidence Packs, Supplier Data, and Audit-Ready Records](/artifacts/eu/general-product-safety-regulation/traceability-and-documentation.md): A practical GPSR documentation and traceability guide for Regulation (EU) 2023/988: what information to maintain. - [GPSR vs Market Surveillance Regulation (EU) 2019/1020 | What's Different, What Overlaps, and What to Build](/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Market Surveillance Regulation (EU) 2019/1020: what each governs. - [GPSR vs Product Liability Directive (85/374/EEC) | Safety Obligations vs Liability Risk, Recalls, Evidence, and Claims Readiness](/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Product Liability Directive (85/374/EEC). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/general-product-safety-regulation/economic-operator-duties --- --- title: "EU GPSR FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/faq" source_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/faq" author: "Sorena AI" description: "Answers to common EU GPSR questions: scope and exclusions, used/repaired products, online marketplaces, Safety Gate/Safety Business Gateway notifications." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU GPSR FAQ" - "GPSR questions" - "Regulation (EU) 2023/988 explained" - "Safety Gate FAQ" - "Safety Business Gateway FAQ" - "online marketplace GPSR FAQ" - "product recall GPSR FAQ" - "GPSR scope exclusions" - "FAQ" - "GPSR" - "Safety Gate" - "online marketplaces" - "recalls" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GPSR FAQ Answers to common EU GPSR questions: scope and exclusions, used/repaired products, online marketplaces, Safety Gate/Safety Business Gateway notifications. *FAQ* *EU* ## EU GPSR FAQ Implementation-focused answers to common GPSR questions. Plus links to checklists, templates, and deep-dive subpages. Teams fail GPSR by treating it as an abstract legal text. These FAQs answer the questions that come up in real implementations: scope decisions, channel impacts, who owns duties, what Safety Gate means operationally, and what evidence you need during incidents and recalls. ## Scope and coverage GPSR scope questions are almost always about exclusions and overlap: which framework governs, and what GPSR still requires operationally. If you operate across multiple product categories, build a scope matrix per category and channel. - Does GPSR cover products sold online? Yes-treat online distribution and marketplace workflows as core scope. - Are used/repaired/reconditioned products covered? Often yes depending on how they reach consumers-document your rationale and controls. - How does GPSR interact with sector rules? Often as a complement for operational duties; document overlap and boundaries. ## Online marketplaces and Safety Gate Marketplace compliance is measured by response capability: notice intake, takedown SLAs, and logs. Safety Gate is not just a portal-it is an operational workflow and data pack requirement. - If you run a marketplace: treat obligations as product integrations + workflow engines with audit logs. - If you sell through marketplaces: ensure your traceability and recall comms can run through marketplace channels. - Plan Safety Business Gateway access and notification data packs before incidents happen. ## Recalls and consumer communication Recalls fail when notices are unclear or execution is slow. Use the recall notice template as a structured output from your incident workflow. Measure recall effectiveness: reach, responses, remedy completion, and residual risk decisions. - What is a 'good' recall notice? Clear action, clear remedy, clear identifiers, minimal friction. - Do corrective actions imply liability? Safety actions and legal liability are different questions-document decisions and evidence carefully. - What evidence should we keep? Incident timeline, notifications, comms logs, delisting proof, and effectiveness metrics. *Recommended next step* *Placement: after the FAQ section* ## Use EU GPSR FAQ as a cited research workflow Research Copilot can take EU GPSR FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU GPSR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU GPSR FAQ](/solutions/research-copilot.md): Start from EU GPSR FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU GPSR](/contact.md): Review your current process, evidence gaps, and next steps for EU GPSR FAQ. ## Primary sources - [GPSR full text - Regulation (EU) 2023/988 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02023R0988-20230523&ref=sorena.io) - Primary text for GPSR scope, duties, recalls, and Safety Gate context. - [Safety Business Gateway (tool)](https://webgate.ec.europa.eu/safety-business-gateway/?ref=sorena.io) - Operational interface for certain submissions by economic operators and marketplaces. ## Related Topic Guides - [EU GPSR Applicability Test | Is Regulation (EU) 2023/988 Applicable to Your Product, Channel, and Role?](/artifacts/eu/general-product-safety-regulation/applicability-test.md): A step-by-step EU GPSR applicability test for Regulation (EU) 2023/988: confirm whether your products are covered, whether exclusions apply. - [EU GPSR Checklist | Audit-Ready Compliance Checklist for Regulation (EU) 2023/988 (Safety Gate, Recalls, Marketplaces, Evidence)](/artifacts/eu/general-product-safety-regulation/checklist.md): An audit-ready EU GPSR checklist for Regulation (EU) 2023/988: scope and role mapping, documentation and traceability, supplier evidence. - [EU GPSR Compliance Program | Operating Model, Governance, Controls, and Evidence for Regulation (EU) 2023/988](/artifacts/eu/general-product-safety-regulation/compliance.md): A practical EU GPSR compliance playbook for Regulation (EU) 2023/988: program setup, governance cadence, risk assessment controls. - [EU GPSR Deadlines and Compliance Calendar | Key Dates, Workstreams, and Operational Milestones (Safety Gate, Recalls, Marketplaces)](/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar.md): A practical EU GPSR calendar for Regulation (EU) 2023/988: key dates and operational milestones, with a workstream-based plan covering scope and role mapping. - [EU GPSR Economic Operator Duties | Manufacturer vs Importer vs Distributor vs Fulfilment vs Marketplace Roles + Evidence](/artifacts/eu/general-product-safety-regulation/economic-operator-duties.md): A practical guide to EU GPSR economic operator duties under Regulation (EU) 2023/988: how to map roles across your supply chain. - [EU GPSR Online Marketplace Obligations | Safety Gate Interface (2024/1459), Unsafe Product Removal, Notices, and Evidence](/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations.md): A practical guide for online marketplaces under EU GPSR (Regulation (EU) 2023/988): who is a 'provider of an online marketplace'. - [EU GPSR Penalties and Enforcement | Market Surveillance, Corrective Actions, and How to Reduce Risk With Evidence](/artifacts/eu/general-product-safety-regulation/penalties-and-fines.md): A practical guide to enforcement under EU GPSR (Regulation (EU) 2023/988): how market surveillance works, what enforcement actions look like (restrictions. - [EU GPSR Product Recall Notice Template | How to Use Implementing Regulation (EU) 2024/1435 (Article 36)](/artifacts/eu/general-product-safety-regulation/product-recall-notice-template.md): A practical guide to the EU GPSR recall notice template: when it applies, how to fill it correctly, what evidence to retain. - [EU GPSR Recalls and Incident Management | Corrective Actions, Safety Gate Notifications, Recall Effectiveness, Playbooks](/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management.md): A practical recall and incident management playbook for EU GPSR (Regulation (EU) 2023/988): build a triage workflow, decide corrective actions vs recall. - [EU GPSR Requirements (Regulation (EU) 2023/988) | Obligations, Controls, Safety Gate Notifications, and Evidence](/artifacts/eu/general-product-safety-regulation/requirements.md): An implementation-grade breakdown of EU GPSR requirements under Regulation (EU) 2023/988: safe product lifecycle controls, risk assessment. - [EU GPSR Scope and Covered Products | What's In/Out, Overlap With Sector Rules, Online Sales, Used/Reconditioned Goods](/artifacts/eu/general-product-safety-regulation/scope-and-covered-products.md): A practical GPSR scope guide for Regulation (EU) 2023/988: what products are covered, common exclusions. - [EU GPSR Traceability and Documentation | Product Safety Evidence Packs, Supplier Data, and Audit-Ready Records](/artifacts/eu/general-product-safety-regulation/traceability-and-documentation.md): A practical GPSR documentation and traceability guide for Regulation (EU) 2023/988: what information to maintain. - [GPSR vs Market Surveillance Regulation (EU) 2019/1020 | What's Different, What Overlaps, and What to Build](/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Market Surveillance Regulation (EU) 2019/1020: what each governs. - [GPSR vs Product Liability Directive (85/374/EEC) | Safety Obligations vs Liability Risk, Recalls, Evidence, and Claims Readiness](/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Product Liability Directive (85/374/EEC). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/general-product-safety-regulation/faq --- --- title: "GPSR vs Market Surveillance Regulation (EU) 2019/1020" canonical_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation" source_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation" author: "Sorena AI" description: "A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Market Surveillance Regulation (EU) 2019/1020: what each governs." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "GPSR vs market surveillance regulation" - "Regulation (EU) 2023/988 vs 2019/1020" - "market surveillance EU product compliance" - "Safety Gate market surveillance" - "product safety vs market surveillance" - "comparison" - "market surveillance" - "GPSR" - "Safety Gate" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GPSR vs Market Surveillance Regulation (EU) 2019/1020 A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Market Surveillance Regulation (EU) 2019/1020: what each governs. *Comparison* *EU* ## GPSR vs Market Surveillance Regulation Product safety obligations vs the enforcement and surveillance framework. Outcome: one evidence system that supports both operational safety and market surveillance expectations. Teams often treat GPSR and market surveillance as separate domains. In reality, they converge during incidents, authority inquiries, and product withdrawals/recalls. This comparison explains what each instrument is 'for', where they overlap operationally, and what evidence you should standardize so responses are fast and consistent. ## What GPSR governs (operator obligations and operations) GPSR focuses on product safety obligations for products made available to consumers on the EU market, including corrective actions, recalls, and Safety Gate-related expectations. Operational outcome: you build controls and workflows (risk assessment, documentation, monitoring, corrective actions). - Scope and role mapping across economic operators and channels. - Incident/recall readiness (communications, remedies, effectiveness measurement). - Safety Gate and notification workflows where applicable. ## What the Market Surveillance Regulation governs (authority powers and coordination) The market surveillance framework governs how authorities coordinate and enforce product compliance, including investigations and actions against unsafe/non-compliant products. Operational outcome: you need to respond quickly to authority requests with coherent evidence. - Authority inquiry response: evidence retrieval and data quality. - Traceability and distribution mapping to identify affected units and markets. - Proof of corrective actions and their effectiveness. ## Shared evidence (high leverage): build it once The best implementation approach is one evidence spine and two views: GPSR operational obligations and market surveillance inquiry readiness. Standardize artifacts and logs so they can be exported without manual scrambling. - Evidence index with owners and refresh cadence. - Incident timeline + decision memos + notification logs. - Corrective action execution proof (delisting, stop-ship, recall comms, remedy completion metrics). *Recommended next step* *Placement: after the comparison section* ## Use GPSR vs Market Surveillance Regulation as a cited research workflow Research Copilot can take GPSR vs Market Surveillance Regulation from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on GPSR vs can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for GPSR vs Market Surveillance Regulation](/solutions/research-copilot.md): Start from GPSR vs Market Surveillance Regulation and answer scope, timing, and interpretation questions with cited outputs. - [Talk through GPSR vs](/contact.md): Review your current process, evidence gaps, and next steps for GPSR vs Market Surveillance Regulation. ## Primary sources - [GPSR full text - Regulation (EU) 2023/988 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02023R0988-20230523&ref=sorena.io) - GPSR obligations, roles, and product safety operational expectations. - [Market surveillance framework - Regulation (EU) 2019/1020 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02019R1020-20240523&ref=sorena.io) - Market surveillance and enforcement coordination context. ## Related Topic Guides - [EU GPSR Applicability Test | Is Regulation (EU) 2023/988 Applicable to Your Product, Channel, and Role?](/artifacts/eu/general-product-safety-regulation/applicability-test.md): A step-by-step EU GPSR applicability test for Regulation (EU) 2023/988: confirm whether your products are covered, whether exclusions apply. - [EU GPSR Checklist | Audit-Ready Compliance Checklist for Regulation (EU) 2023/988 (Safety Gate, Recalls, Marketplaces, Evidence)](/artifacts/eu/general-product-safety-regulation/checklist.md): An audit-ready EU GPSR checklist for Regulation (EU) 2023/988: scope and role mapping, documentation and traceability, supplier evidence. - [EU GPSR Compliance Program | Operating Model, Governance, Controls, and Evidence for Regulation (EU) 2023/988](/artifacts/eu/general-product-safety-regulation/compliance.md): A practical EU GPSR compliance playbook for Regulation (EU) 2023/988: program setup, governance cadence, risk assessment controls. - [EU GPSR Deadlines and Compliance Calendar | Key Dates, Workstreams, and Operational Milestones (Safety Gate, Recalls, Marketplaces)](/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar.md): A practical EU GPSR calendar for Regulation (EU) 2023/988: key dates and operational milestones, with a workstream-based plan covering scope and role mapping. - [EU GPSR Economic Operator Duties | Manufacturer vs Importer vs Distributor vs Fulfilment vs Marketplace Roles + Evidence](/artifacts/eu/general-product-safety-regulation/economic-operator-duties.md): A practical guide to EU GPSR economic operator duties under Regulation (EU) 2023/988: how to map roles across your supply chain. - [EU GPSR FAQ | Common Questions About Regulation (EU) 2023/988 (Scope, Online Marketplaces, Safety Gate, Recalls)](/artifacts/eu/general-product-safety-regulation/faq.md): Answers to common EU GPSR questions: scope and exclusions, used/repaired products, online marketplaces, Safety Gate/Safety Business Gateway notifications. - [EU GPSR Online Marketplace Obligations | Safety Gate Interface (2024/1459), Unsafe Product Removal, Notices, and Evidence](/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations.md): A practical guide for online marketplaces under EU GPSR (Regulation (EU) 2023/988): who is a 'provider of an online marketplace'. - [EU GPSR Penalties and Enforcement | Market Surveillance, Corrective Actions, and How to Reduce Risk With Evidence](/artifacts/eu/general-product-safety-regulation/penalties-and-fines.md): A practical guide to enforcement under EU GPSR (Regulation (EU) 2023/988): how market surveillance works, what enforcement actions look like (restrictions. - [EU GPSR Product Recall Notice Template | How to Use Implementing Regulation (EU) 2024/1435 (Article 36)](/artifacts/eu/general-product-safety-regulation/product-recall-notice-template.md): A practical guide to the EU GPSR recall notice template: when it applies, how to fill it correctly, what evidence to retain. - [EU GPSR Recalls and Incident Management | Corrective Actions, Safety Gate Notifications, Recall Effectiveness, Playbooks](/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management.md): A practical recall and incident management playbook for EU GPSR (Regulation (EU) 2023/988): build a triage workflow, decide corrective actions vs recall. - [EU GPSR Requirements (Regulation (EU) 2023/988) | Obligations, Controls, Safety Gate Notifications, and Evidence](/artifacts/eu/general-product-safety-regulation/requirements.md): An implementation-grade breakdown of EU GPSR requirements under Regulation (EU) 2023/988: safe product lifecycle controls, risk assessment. - [EU GPSR Scope and Covered Products | What's In/Out, Overlap With Sector Rules, Online Sales, Used/Reconditioned Goods](/artifacts/eu/general-product-safety-regulation/scope-and-covered-products.md): A practical GPSR scope guide for Regulation (EU) 2023/988: what products are covered, common exclusions. - [EU GPSR Traceability and Documentation | Product Safety Evidence Packs, Supplier Data, and Audit-Ready Records](/artifacts/eu/general-product-safety-regulation/traceability-and-documentation.md): A practical GPSR documentation and traceability guide for Regulation (EU) 2023/988: what information to maintain. - [GPSR vs Product Liability Directive (85/374/EEC) | Safety Obligations vs Liability Risk, Recalls, Evidence, and Claims Readiness](/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Product Liability Directive (85/374/EEC). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation --- --- title: "GPSR vs Product Liability Directive (85/374/EEC)" canonical_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive" source_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive" author: "Sorena AI" description: "A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Product Liability Directive (85/374/EEC)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "GPSR vs product liability directive" - "85/374/EEC defective products" - "product safety vs product liability" - "EU recalls and liability" - "product recall evidence" - "claims readiness product safety" - "comparison" - "product liability" - "recalls" - "evidence" - "claims readiness" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # GPSR vs Product Liability Directive (85/374/EEC) A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Product Liability Directive (85/374/EEC). *Comparison* *EU* ## GPSR vs Product Liability Directive Safety obligations and operational response vs liability and claims logic. Outcome: one incident record that supports both compliance and claims readiness. During an incident, teams often mix two questions: (1) what safety actions must we take now, and (2) what does this mean for liability and claims. GPSR is about product safety obligations and corrective action execution. Product liability frameworks govern civil liability exposure. The correct approach is to build a unified incident record with a clear separation of 'safety operations' and 'legal positions'. ## Different goals: safety control vs liability allocation GPSR's goal is to reduce risk to consumers and ensure unsafe products are addressed through corrective actions, communication, and (where required) notifications. The Product Liability Directive framework is about civil liability for defective products. Operationally, it influences how you retain evidence and manage claims readiness. - GPSR: prevention + monitoring + corrective actions + recall execution + communications. - PLD: defect/liability concepts, damages exposure, and claims handling posture. - Shared need: consistent incident record and traceability of decisions and actions. *Recommended next step* *Placement: after the comparison section* ## Use GPSR vs Product Liability Directive as a cited research workflow Research Copilot can take GPSR vs Product Liability Directive from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on GPSR vs can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for GPSR vs Product Liability Directive](/solutions/research-copilot.md): Start from GPSR vs Product Liability Directive and answer scope, timing, and interpretation questions with cited outputs. - [Talk through GPSR vs](/contact.md): Review your current process, evidence gaps, and next steps for GPSR vs Product Liability Directive. ## What changes operationally during incidents GPSR requires execution: identify affected units, remove unsafe listings, communicate to consumers, and implement remedies. Liability readiness requires evidence preservation and consistent narratives across stakeholders. Build a playbook with two tracks: operational safety actions and legal/claims coordination. - Safety track: triage, corrective action decision, recall notice generation, notifications, effectiveness measurement. - Claims track: evidence preservation, privilege strategy (where applicable), insurer and counsel coordination, communications alignment. - Avoid confusion: corrective action is safety control; liability is a separate assessment-keep documentation structured. ## Unified evidence model (supports both without mixing them) A strong evidence model reduces both compliance and liability risk: you can show what you knew, what you did, and why your actions were reasonable and effective. Design an exportable incident pack that contains: facts, timelines, actions, and supporting artifacts. - Incident timeline + decision memos + corrective action logs. - Product identifiers + traceability + distribution mapping. - Communications evidence + remedy completion metrics + residual risk decisions. ## Primary sources - [GPSR full text - Regulation (EU) 2023/988 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02023R0988-20230523&ref=sorena.io) - Primary text for safety obligations, corrective actions, and recall context. - [Product Liability Directive - Council Directive 85/374/EEC (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A31985L0374&ref=sorena.io) - Primary legal text for defective product liability framework. ## Related Topic Guides - [EU GPSR Applicability Test | Is Regulation (EU) 2023/988 Applicable to Your Product, Channel, and Role?](/artifacts/eu/general-product-safety-regulation/applicability-test.md): A step-by-step EU GPSR applicability test for Regulation (EU) 2023/988: confirm whether your products are covered, whether exclusions apply. - [EU GPSR Checklist | Audit-Ready Compliance Checklist for Regulation (EU) 2023/988 (Safety Gate, Recalls, Marketplaces, Evidence)](/artifacts/eu/general-product-safety-regulation/checklist.md): An audit-ready EU GPSR checklist for Regulation (EU) 2023/988: scope and role mapping, documentation and traceability, supplier evidence. - [EU GPSR Compliance Program | Operating Model, Governance, Controls, and Evidence for Regulation (EU) 2023/988](/artifacts/eu/general-product-safety-regulation/compliance.md): A practical EU GPSR compliance playbook for Regulation (EU) 2023/988: program setup, governance cadence, risk assessment controls. - [EU GPSR Deadlines and Compliance Calendar | Key Dates, Workstreams, and Operational Milestones (Safety Gate, Recalls, Marketplaces)](/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar.md): A practical EU GPSR calendar for Regulation (EU) 2023/988: key dates and operational milestones, with a workstream-based plan covering scope and role mapping. - [EU GPSR Economic Operator Duties | Manufacturer vs Importer vs Distributor vs Fulfilment vs Marketplace Roles + Evidence](/artifacts/eu/general-product-safety-regulation/economic-operator-duties.md): A practical guide to EU GPSR economic operator duties under Regulation (EU) 2023/988: how to map roles across your supply chain. - [EU GPSR FAQ | Common Questions About Regulation (EU) 2023/988 (Scope, Online Marketplaces, Safety Gate, Recalls)](/artifacts/eu/general-product-safety-regulation/faq.md): Answers to common EU GPSR questions: scope and exclusions, used/repaired products, online marketplaces, Safety Gate/Safety Business Gateway notifications. - [EU GPSR Online Marketplace Obligations | Safety Gate Interface (2024/1459), Unsafe Product Removal, Notices, and Evidence](/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations.md): A practical guide for online marketplaces under EU GPSR (Regulation (EU) 2023/988): who is a 'provider of an online marketplace'. - [EU GPSR Penalties and Enforcement | Market Surveillance, Corrective Actions, and How to Reduce Risk With Evidence](/artifacts/eu/general-product-safety-regulation/penalties-and-fines.md): A practical guide to enforcement under EU GPSR (Regulation (EU) 2023/988): how market surveillance works, what enforcement actions look like (restrictions. - [EU GPSR Product Recall Notice Template | How to Use Implementing Regulation (EU) 2024/1435 (Article 36)](/artifacts/eu/general-product-safety-regulation/product-recall-notice-template.md): A practical guide to the EU GPSR recall notice template: when it applies, how to fill it correctly, what evidence to retain. - [EU GPSR Recalls and Incident Management | Corrective Actions, Safety Gate Notifications, Recall Effectiveness, Playbooks](/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management.md): A practical recall and incident management playbook for EU GPSR (Regulation (EU) 2023/988): build a triage workflow, decide corrective actions vs recall. - [EU GPSR Requirements (Regulation (EU) 2023/988) | Obligations, Controls, Safety Gate Notifications, and Evidence](/artifacts/eu/general-product-safety-regulation/requirements.md): An implementation-grade breakdown of EU GPSR requirements under Regulation (EU) 2023/988: safe product lifecycle controls, risk assessment. - [EU GPSR Scope and Covered Products | What's In/Out, Overlap With Sector Rules, Online Sales, Used/Reconditioned Goods](/artifacts/eu/general-product-safety-regulation/scope-and-covered-products.md): A practical GPSR scope guide for Regulation (EU) 2023/988: what products are covered, common exclusions. - [EU GPSR Traceability and Documentation | Product Safety Evidence Packs, Supplier Data, and Audit-Ready Records](/artifacts/eu/general-product-safety-regulation/traceability-and-documentation.md): A practical GPSR documentation and traceability guide for Regulation (EU) 2023/988: what information to maintain. - [GPSR vs Market Surveillance Regulation (EU) 2019/1020 | What's Different, What Overlaps, and What to Build](/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Market Surveillance Regulation (EU) 2019/1020: what each governs. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive --- --- title: "EU GPSR Online Marketplace Obligations" canonical_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations" source_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations" author: "Sorena AI" description: "A practical guide for online marketplaces under EU GPSR (Regulation (EU) 2023/988): who is a 'provider of an online marketplace'." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU GPSR online marketplace obligations" - "provider of online marketplace GPSR" - "Safety Gate Portal interface 2024/1459" - "GPSR unsafe product removal" - "marketplace product safety compliance EU" - "Safety Gate interoperable interface" - "product recall marketplace coordination" - "online marketplaces" - "Safety Gate" - "unsafe product takedown" - "interoperable interface" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GPSR Online Marketplace Obligations A practical guide for online marketplaces under EU GPSR (Regulation (EU) 2023/988): who is a 'provider of an online marketplace'. *Marketplace* *EU* ## EU GPSR Online Marketplace Obligations Build a marketplace safety operating model that works under pressure. Focus: Safety Gate interface readiness, notice handling, takedown SLAs, and audit-ready logs. If you run an online marketplace, GPSR is not just policy language. It is systems, registration, and response time. You need a safe-listing model (product IDs and traceability data), a notice-to-action workflow (remove or disable offers for dangerous products), Safety Gate Portal registration with a single contact point, and an evidence log that can be exported during authority or consumer-protection scrutiny. ## Define 'provider of an online marketplace' (then scope the platform) Start with a clear definition: which parts of your product are the online interface that allows consumers to conclude distance contracts with traders for the sale of products. Operational outcome: create a platform scope boundary, register with the Safety Gate Portal under Article 22(1), and assign owners for product safety operations including the single contact point and on-call escalation. - Which interfaces are in scope: web, app, APIs, embedded purchase flows, white-label surfaces. - Which actors exist: marketplace provider, traders/sellers, fulfilment partners, payment/identity vendors. - Which product categories are higher risk and need stronger listing gates. ## Safety Gate Portal registration and optional interface linkage The first mandatory step is registration with the Safety Gate Portal and publication of your single contact point information there. The interoperable interface under (EU) 2024/1459 is optional, not mandatory. If you do use the interoperable interface, treat it as a product integration with engineering ownership, release management, security review, and monitoring. - Register the marketplace and verify the single contact point details are current and tested. - If linking your systems, remember the interface only provides information already made public on the Safety Gate Portal under Article 34(1). - Configure the frequency and content of downloads in line with Commission instructions and monitor failures. - Maintain integration evidence: logs, dashboards, change history, and proof of contact-point testing. ## Unsafe product notices -> takedown workflow (the core operational loop) Marketplace compliance is largely measured by what you do when you learn something is unsafe. You need to act quickly, consistently, and in a way that is explainable after the fact. Design this as a workflow engine with clear states and audit logs. - Intake sources: authority notices, Safety Gate alerts, consumer reports, internal detection, seller disclosures. - State machine: received -> triaged -> validated -> actioned (remove/disable) -> notified -> follow-up -> closed. - Evidence: timestamps, decision memo, approver, what content was removed, and what users were informed. ## Audit-ready evidence pack (what regulators and partners expect) Your best defense is a consistent evidence pack. Without it, every incident becomes a bespoke investigation. Build an exportable 'marketplace safety pack' and refresh it continuously. - Marketplace governance: contact points, escalation paths, on-call coverage, and training. - Listing governance: required product identifiers/traceability fields and enforcement rules. - Notice logs: intake channels, actions taken, removal proof, and communication records. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU GPSR Online Marketplace Obligations as a cited research workflow Research Copilot can take EU GPSR Online Marketplace Obligations from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU GPSR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU GPSR Online Marketplace Obligations](/solutions/research-copilot.md): Start from EU GPSR Online Marketplace Obligations and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU GPSR](/contact.md): Review your current process, evidence gaps, and next steps for EU GPSR Online Marketplace Obligations. ## Primary sources - [GPSR full text - Regulation (EU) 2023/988 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02023R0988-20230523&ref=sorena.io) - Primary legal text for marketplace obligations and operational requirements. - [Online marketplace interface rules - Implementing Regulation (EU) 2024/1459 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1459&ref=sorena.io) - Rules for implementing the interoperable interface of the Safety Gate Portal for online marketplace providers. - [Commission Q&A on GPSR implementing and delegated regulations](https://webgate.ec.europa.eu/safety-gate-screen/webReport/guide/qaImplementingAndDelegatedRegulations?ref=sorena.io) - Confirms that registration is mandatory, while use of the interoperable interface is optional. - [Safety Gate Portal (public site)](https://ec.europa.eu/safety-gate/?ref=sorena.io) - Public-facing Safety Gate portal used for alerts and recall-related resources. ## Related Topic Guides - [EU GPSR Applicability Test | Is Regulation (EU) 2023/988 Applicable to Your Product, Channel, and Role?](/artifacts/eu/general-product-safety-regulation/applicability-test.md): A step-by-step EU GPSR applicability test for Regulation (EU) 2023/988: confirm whether your products are covered, whether exclusions apply. - [EU GPSR Checklist | Audit-Ready Compliance Checklist for Regulation (EU) 2023/988 (Safety Gate, Recalls, Marketplaces, Evidence)](/artifacts/eu/general-product-safety-regulation/checklist.md): An audit-ready EU GPSR checklist for Regulation (EU) 2023/988: scope and role mapping, documentation and traceability, supplier evidence. - [EU GPSR Compliance Program | Operating Model, Governance, Controls, and Evidence for Regulation (EU) 2023/988](/artifacts/eu/general-product-safety-regulation/compliance.md): A practical EU GPSR compliance playbook for Regulation (EU) 2023/988: program setup, governance cadence, risk assessment controls. - [EU GPSR Deadlines and Compliance Calendar | Key Dates, Workstreams, and Operational Milestones (Safety Gate, Recalls, Marketplaces)](/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar.md): A practical EU GPSR calendar for Regulation (EU) 2023/988: key dates and operational milestones, with a workstream-based plan covering scope and role mapping. - [EU GPSR Economic Operator Duties | Manufacturer vs Importer vs Distributor vs Fulfilment vs Marketplace Roles + Evidence](/artifacts/eu/general-product-safety-regulation/economic-operator-duties.md): A practical guide to EU GPSR economic operator duties under Regulation (EU) 2023/988: how to map roles across your supply chain. - [EU GPSR FAQ | Common Questions About Regulation (EU) 2023/988 (Scope, Online Marketplaces, Safety Gate, Recalls)](/artifacts/eu/general-product-safety-regulation/faq.md): Answers to common EU GPSR questions: scope and exclusions, used/repaired products, online marketplaces, Safety Gate/Safety Business Gateway notifications. - [EU GPSR Penalties and Enforcement | Market Surveillance, Corrective Actions, and How to Reduce Risk With Evidence](/artifacts/eu/general-product-safety-regulation/penalties-and-fines.md): A practical guide to enforcement under EU GPSR (Regulation (EU) 2023/988): how market surveillance works, what enforcement actions look like (restrictions. - [EU GPSR Product Recall Notice Template | How to Use Implementing Regulation (EU) 2024/1435 (Article 36)](/artifacts/eu/general-product-safety-regulation/product-recall-notice-template.md): A practical guide to the EU GPSR recall notice template: when it applies, how to fill it correctly, what evidence to retain. - [EU GPSR Recalls and Incident Management | Corrective Actions, Safety Gate Notifications, Recall Effectiveness, Playbooks](/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management.md): A practical recall and incident management playbook for EU GPSR (Regulation (EU) 2023/988): build a triage workflow, decide corrective actions vs recall. - [EU GPSR Requirements (Regulation (EU) 2023/988) | Obligations, Controls, Safety Gate Notifications, and Evidence](/artifacts/eu/general-product-safety-regulation/requirements.md): An implementation-grade breakdown of EU GPSR requirements under Regulation (EU) 2023/988: safe product lifecycle controls, risk assessment. - [EU GPSR Scope and Covered Products | What's In/Out, Overlap With Sector Rules, Online Sales, Used/Reconditioned Goods](/artifacts/eu/general-product-safety-regulation/scope-and-covered-products.md): A practical GPSR scope guide for Regulation (EU) 2023/988: what products are covered, common exclusions. - [EU GPSR Traceability and Documentation | Product Safety Evidence Packs, Supplier Data, and Audit-Ready Records](/artifacts/eu/general-product-safety-regulation/traceability-and-documentation.md): A practical GPSR documentation and traceability guide for Regulation (EU) 2023/988: what information to maintain. - [GPSR vs Market Surveillance Regulation (EU) 2019/1020 | What's Different, What Overlaps, and What to Build](/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Market Surveillance Regulation (EU) 2019/1020: what each governs. - [GPSR vs Product Liability Directive (85/374/EEC) | Safety Obligations vs Liability Risk, Recalls, Evidence, and Claims Readiness](/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Product Liability Directive (85/374/EEC). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations --- --- title: "EU GPSR Penalties and Enforcement" canonical_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/penalties-and-fines" author: "Sorena AI" description: "A practical guide to enforcement under EU GPSR (Regulation (EU) 2023/988): how market surveillance works, what enforcement actions look like (restrictions." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU GPSR penalties" - "GPSR enforcement" - "Regulation (EU) 2023/988 enforcement" - "market surveillance EU 2019/1020" - "product recall enforcement EU" - "Safety Gate enforcement" - "product safety penalties EU" - "enforcement" - "penalties" - "market surveillance" - "recalls" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GPSR Penalties and Enforcement A practical guide to enforcement under EU GPSR (Regulation (EU) 2023/988): how market surveillance works, what enforcement actions look like (restrictions. *Enforcement* *EU* ## EU GPSR Penalties and Enforcement Enforcement is driven by evidence, responsiveness, and corrective action effectiveness. Focus: market surveillance posture, what actions authorities take, and how to reduce risk with defensible artifacts. GPSR enforcement is not only about whether a product is unsafe. It is also about how the economic operator or online marketplace responds. Article 44 leaves the exact penalty amounts to Member States, but it requires penalties to be effective, proportionate, and dissuasive. Programs that can produce evidence quickly and execute corrective actions consistently tend to reduce escalation risk, delays, and reputational damage. ## How enforcement typically unfolds (practical sequence) Enforcement usually starts with a signal: consumer complaints, incident reports, marketplace reports, authority investigations, or Safety Gate alerts. Your goal is to compress time-to-triage and time-to-action with a consistent workflow and evidence pack. - Signal intake -> triage -> investigation memo -> action decision -> execution -> evidence export. - Cross-channel coordination: distributors, marketplaces, and fulfillment providers need aligned actions. - Post-action review: effectiveness evidence and residual risk decisions. *Recommended next step* *Placement: after the enforcement section* ## Use EU GPSR Penalties and Enforcement as a cited research workflow Research Copilot can take EU GPSR Penalties and Enforcement from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU GPSR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU GPSR Penalties and Enforcement](/solutions/research-copilot.md): Start from EU GPSR Penalties and Enforcement and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU GPSR](/contact.md): Review your current process, evidence gaps, and next steps for EU GPSR Penalties and Enforcement. ## What authorities look for (the evidence-first view) Authorities need to understand what happened and whether you can control the risk. That requires clear, dated artifacts. The most important evidence is often operational: logs, decisions, and proof of effective corrective actions. - Traceability: affected units, markets, and channels identified clearly. - Corrective action evidence: delisting, stop-ship, withdrawal/recall, consumer comms and remedies. - Notification evidence: what was submitted, when, and how follow-ups were handled. ## Risk reduction actions that work (and are defensible) You cannot eliminate all product safety risk, but you can build a defensible posture: documented controls, rapid response capability, and measurable effectiveness. Treat this as an operating system with KPIs. - KPIs: time-to-triage, time-to-action, recall reach and completion rates, evidence retrieval time. - Governance: quarterly scope refresh, supplier change gates, and post-incident reviews. - Evidence spine: single index that can be exported during authority or marketplace escalation. - Track national penalty exposure by market because Article 44 is implemented at Member State level, not in one EU-wide fine schedule. - Plan for 13 December 2029, when the Commission must evaluate the effectiveness and deterrent effect of Member State penalties. ## Primary sources - [GPSR full text - Regulation (EU) 2023/988 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02023R0988-20230523&ref=sorena.io) - Primary source for GPSR obligations, corrective actions, and Safety Gate context. - [Market surveillance framework - Regulation (EU) 2019/1020 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02019R1020-20240523&ref=sorena.io) - Framework context for market surveillance and enforcement operations interacting with GPSR. - [GPSR official journal text](https://eur-lex.europa.eu/eli/reg/2023/988/oj/eng?ref=sorena.io) - Official source for Article 44 and the Commission's 13 December 2029 penalty evaluation requirement. ## Related Topic Guides - [EU GPSR Applicability Test | Is Regulation (EU) 2023/988 Applicable to Your Product, Channel, and Role?](/artifacts/eu/general-product-safety-regulation/applicability-test.md): A step-by-step EU GPSR applicability test for Regulation (EU) 2023/988: confirm whether your products are covered, whether exclusions apply. - [EU GPSR Checklist | Audit-Ready Compliance Checklist for Regulation (EU) 2023/988 (Safety Gate, Recalls, Marketplaces, Evidence)](/artifacts/eu/general-product-safety-regulation/checklist.md): An audit-ready EU GPSR checklist for Regulation (EU) 2023/988: scope and role mapping, documentation and traceability, supplier evidence. - [EU GPSR Compliance Program | Operating Model, Governance, Controls, and Evidence for Regulation (EU) 2023/988](/artifacts/eu/general-product-safety-regulation/compliance.md): A practical EU GPSR compliance playbook for Regulation (EU) 2023/988: program setup, governance cadence, risk assessment controls. - [EU GPSR Deadlines and Compliance Calendar | Key Dates, Workstreams, and Operational Milestones (Safety Gate, Recalls, Marketplaces)](/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar.md): A practical EU GPSR calendar for Regulation (EU) 2023/988: key dates and operational milestones, with a workstream-based plan covering scope and role mapping. - [EU GPSR Economic Operator Duties | Manufacturer vs Importer vs Distributor vs Fulfilment vs Marketplace Roles + Evidence](/artifacts/eu/general-product-safety-regulation/economic-operator-duties.md): A practical guide to EU GPSR economic operator duties under Regulation (EU) 2023/988: how to map roles across your supply chain. - [EU GPSR FAQ | Common Questions About Regulation (EU) 2023/988 (Scope, Online Marketplaces, Safety Gate, Recalls)](/artifacts/eu/general-product-safety-regulation/faq.md): Answers to common EU GPSR questions: scope and exclusions, used/repaired products, online marketplaces, Safety Gate/Safety Business Gateway notifications. - [EU GPSR Online Marketplace Obligations | Safety Gate Interface (2024/1459), Unsafe Product Removal, Notices, and Evidence](/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations.md): A practical guide for online marketplaces under EU GPSR (Regulation (EU) 2023/988): who is a 'provider of an online marketplace'. - [EU GPSR Product Recall Notice Template | How to Use Implementing Regulation (EU) 2024/1435 (Article 36)](/artifacts/eu/general-product-safety-regulation/product-recall-notice-template.md): A practical guide to the EU GPSR recall notice template: when it applies, how to fill it correctly, what evidence to retain. - [EU GPSR Recalls and Incident Management | Corrective Actions, Safety Gate Notifications, Recall Effectiveness, Playbooks](/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management.md): A practical recall and incident management playbook for EU GPSR (Regulation (EU) 2023/988): build a triage workflow, decide corrective actions vs recall. - [EU GPSR Requirements (Regulation (EU) 2023/988) | Obligations, Controls, Safety Gate Notifications, and Evidence](/artifacts/eu/general-product-safety-regulation/requirements.md): An implementation-grade breakdown of EU GPSR requirements under Regulation (EU) 2023/988: safe product lifecycle controls, risk assessment. - [EU GPSR Scope and Covered Products | What's In/Out, Overlap With Sector Rules, Online Sales, Used/Reconditioned Goods](/artifacts/eu/general-product-safety-regulation/scope-and-covered-products.md): A practical GPSR scope guide for Regulation (EU) 2023/988: what products are covered, common exclusions. - [EU GPSR Traceability and Documentation | Product Safety Evidence Packs, Supplier Data, and Audit-Ready Records](/artifacts/eu/general-product-safety-regulation/traceability-and-documentation.md): A practical GPSR documentation and traceability guide for Regulation (EU) 2023/988: what information to maintain. - [GPSR vs Market Surveillance Regulation (EU) 2019/1020 | What's Different, What Overlaps, and What to Build](/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Market Surveillance Regulation (EU) 2019/1020: what each governs. - [GPSR vs Product Liability Directive (85/374/EEC) | Safety Obligations vs Liability Risk, Recalls, Evidence, and Claims Readiness](/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Product Liability Directive (85/374/EEC). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/general-product-safety-regulation/penalties-and-fines --- --- title: "EU GPSR Product Recall Notice Template" canonical_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/product-recall-notice-template" source_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/product-recall-notice-template" author: "Sorena AI" description: "A practical guide to the EU GPSR recall notice template: when it applies, how to fill it correctly, what evidence to retain." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU GPSR recall notice template" - "Implementing Regulation (EU) 2024/1435" - "GPSR Article 36 recall notice" - "product recall notice EU" - "recall communication template" - "Safety Gate recalls" - "product safety recall notice" - "recall notice template" - "recalls" - "consumer communication" - "corrective actions" - "Safety Gate" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GPSR Product Recall Notice Template A practical guide to the EU GPSR recall notice template: when it applies, how to fill it correctly, what evidence to retain. *Template* *EU* ## EU GPSR Product Recall Notice Template Use the required template without turning it into generic legal text. Focus: correct fields, clear consumer actions, remedies, localization, and evidence retention. Under GPSR, recall communication is an operational and compliance artifact. The recall notice template in Implementing Regulation (EU) 2024/1435 provides a structured format. The fastest way to fail a recall is a notice that is technically sent but not understood or acted on by consumers. ## When the recall notice template applies (and how to operationalize it) Treat the template as a standardized output from your incident workflow, not a one-off PDF. Build a generator process: incident data to template fields to review to publish to measure. The Commission Q and A clarifies an important nuance: the format of the template is recommended, but the use of a recall notice and the minimum elements listed in Article 36(2) are mandatory. - Prebuild a field mapping from your systems (SKU/batch/serial, supplier, markets, customer lists). - Define who owns each mandatory field: identifiers, risk statement, affected period, consumer action, and Article 37 remedy. - Create approval SLAs (who must sign off, and within what timeframe). - Maintain a recall notice log (versions, timestamps, distribution channels). *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU GPSR Product Recall Notice Template in one governed evidence system SSOT can take EU GPSR Product Recall Notice Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU GPSR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU GPSR Product Recall Notice Template](/solutions/ssot.md): Start from EU GPSR Product Recall Notice Template and keep documents, evidence, and control records in one governed system. - [Talk through EU GPSR](/contact.md): Review your current process, evidence gaps, and next steps for EU GPSR Product Recall Notice Template. ## How to fill the template: data quality and completeness Most recall notices fail due to missing identifiers and unclear consumer instructions. The template is a forcing function, so make sure your data model supports it. Design a minimum viable recall dataset that can be assembled within hours. - Product identifiers: model, SKU, batch/lot/serial (and where to find them on the product). - Risk description: what can happen, severity, and who is most at risk. - Remedies and steps: stop using, return, repair, replacement, refund, and how to obtain the remedy in line with Article 37. ## Write for action: recall messaging that consumers actually follow A recall notice is a safety instruction. Use plain language and reduce friction. If the process is hard, consumers won't comply, and the risk remains in the market. Coordinate messaging across channels: email/SMS, website landing page, marketplace messaging, call center scripts. - Put the action in the first screen: what to do now, and how to get remedy. - Use visuals: where to find model/batch, what the hazard looks like, which variants are affected. - Localize: languages, accessibility, and time zones for customer support coverage. ## Evidence to retain (so your recall is defensible) Authorities and partners will ask: what did you communicate, to whom, when, and what happened next. Keep evidence from day one. Treat recall evidence as part of the incident record. - Notice versions and distribution logs (channels, timestamps, recipients). - Marketplace actions (delisting/removal proof) and coordination communications. - Effectiveness metrics: reach, responses, remedy completion rates, residual risk decisions. ## Primary sources - [Recall notice template - Implementing Regulation (EU) 2024/1435 (EUR-Lex consolidated HTML)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02024R1435-20240527&ref=sorena.io) - Establishes the template for recall notices in accordance with GPSR Article 36. - [Commission Q&A on GPSR implementing and delegated regulations](https://webgate.ec.europa.eu/safety-gate-screen/webReport/guide/qaImplementingAndDelegatedRegulations?ref=sorena.io) - Explains that the template format is recommended, but the recall notice and its minimum elements are mandatory. - [Safety Gate Portal - effective recalls resources](https://ec.europa.eu/safety-gate/#/screen/pages/effectiveRecalls?ref=sorena.io) - Recall resources referenced in Commission material (useful for effectiveness planning). ## Related Topic Guides - [EU GPSR Applicability Test | Is Regulation (EU) 2023/988 Applicable to Your Product, Channel, and Role?](/artifacts/eu/general-product-safety-regulation/applicability-test.md): A step-by-step EU GPSR applicability test for Regulation (EU) 2023/988: confirm whether your products are covered, whether exclusions apply. - [EU GPSR Checklist | Audit-Ready Compliance Checklist for Regulation (EU) 2023/988 (Safety Gate, Recalls, Marketplaces, Evidence)](/artifacts/eu/general-product-safety-regulation/checklist.md): An audit-ready EU GPSR checklist for Regulation (EU) 2023/988: scope and role mapping, documentation and traceability, supplier evidence. - [EU GPSR Compliance Program | Operating Model, Governance, Controls, and Evidence for Regulation (EU) 2023/988](/artifacts/eu/general-product-safety-regulation/compliance.md): A practical EU GPSR compliance playbook for Regulation (EU) 2023/988: program setup, governance cadence, risk assessment controls. - [EU GPSR Deadlines and Compliance Calendar | Key Dates, Workstreams, and Operational Milestones (Safety Gate, Recalls, Marketplaces)](/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar.md): A practical EU GPSR calendar for Regulation (EU) 2023/988: key dates and operational milestones, with a workstream-based plan covering scope and role mapping. - [EU GPSR Economic Operator Duties | Manufacturer vs Importer vs Distributor vs Fulfilment vs Marketplace Roles + Evidence](/artifacts/eu/general-product-safety-regulation/economic-operator-duties.md): A practical guide to EU GPSR economic operator duties under Regulation (EU) 2023/988: how to map roles across your supply chain. - [EU GPSR FAQ | Common Questions About Regulation (EU) 2023/988 (Scope, Online Marketplaces, Safety Gate, Recalls)](/artifacts/eu/general-product-safety-regulation/faq.md): Answers to common EU GPSR questions: scope and exclusions, used/repaired products, online marketplaces, Safety Gate/Safety Business Gateway notifications. - [EU GPSR Online Marketplace Obligations | Safety Gate Interface (2024/1459), Unsafe Product Removal, Notices, and Evidence](/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations.md): A practical guide for online marketplaces under EU GPSR (Regulation (EU) 2023/988): who is a 'provider of an online marketplace'. - [EU GPSR Penalties and Enforcement | Market Surveillance, Corrective Actions, and How to Reduce Risk With Evidence](/artifacts/eu/general-product-safety-regulation/penalties-and-fines.md): A practical guide to enforcement under EU GPSR (Regulation (EU) 2023/988): how market surveillance works, what enforcement actions look like (restrictions. - [EU GPSR Recalls and Incident Management | Corrective Actions, Safety Gate Notifications, Recall Effectiveness, Playbooks](/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management.md): A practical recall and incident management playbook for EU GPSR (Regulation (EU) 2023/988): build a triage workflow, decide corrective actions vs recall. - [EU GPSR Requirements (Regulation (EU) 2023/988) | Obligations, Controls, Safety Gate Notifications, and Evidence](/artifacts/eu/general-product-safety-regulation/requirements.md): An implementation-grade breakdown of EU GPSR requirements under Regulation (EU) 2023/988: safe product lifecycle controls, risk assessment. - [EU GPSR Scope and Covered Products | What's In/Out, Overlap With Sector Rules, Online Sales, Used/Reconditioned Goods](/artifacts/eu/general-product-safety-regulation/scope-and-covered-products.md): A practical GPSR scope guide for Regulation (EU) 2023/988: what products are covered, common exclusions. - [EU GPSR Traceability and Documentation | Product Safety Evidence Packs, Supplier Data, and Audit-Ready Records](/artifacts/eu/general-product-safety-regulation/traceability-and-documentation.md): A practical GPSR documentation and traceability guide for Regulation (EU) 2023/988: what information to maintain. - [GPSR vs Market Surveillance Regulation (EU) 2019/1020 | What's Different, What Overlaps, and What to Build](/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Market Surveillance Regulation (EU) 2019/1020: what each governs. - [GPSR vs Product Liability Directive (85/374/EEC) | Safety Obligations vs Liability Risk, Recalls, Evidence, and Claims Readiness](/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Product Liability Directive (85/374/EEC). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/general-product-safety-regulation/product-recall-notice-template --- --- title: "EU GPSR Recalls and Incident Management" canonical_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management" source_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management" author: "Sorena AI" description: "A practical recall and incident management playbook for EU GPSR (Regulation (EU) 2023/988): build a triage workflow, decide corrective actions vs recall." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU GPSR recall" - "product recall EU" - "GPSR corrective actions" - "Safety Gate notification" - "Safety Business Gateway notification" - "recall effectiveness" - "recall playbook" - "Regulation (EU) 2023/988 recalls" - "recall notice template" - "product recalls" - "corrective actions" - "Safety Gate" - "Safety Business Gateway" - "incident management" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GPSR Recalls and Incident Management A practical recall and incident management playbook for EU GPSR (Regulation (EU) 2023/988): build a triage workflow, decide corrective actions vs recall. *Playbook* *EU* ## EU GPSR Recalls and Incident Management Build an execution-ready corrective action and recall capability. Focus: triage -> decide action -> notify -> execute -> measure effectiveness -> retain evidence. Recalls are not a PDF. They are a cross-functional operation with deadlines, risk decisions, and consumer impact. GPSR expects you to identify dangerous products, take corrective actions, communicate effectively, notify through Safety Gate tooling, and prove what happened with logs and evidence. ## Triage workflow (signals -> validated incident) Start with an intake queue that captures all safety signals: complaints, returns, test failures, marketplace reports, authority notices, and Safety Gate alerts. Design triage as a workflow with explicit states and handoffs so incidents don't stall in someone's inbox. - Define severity tiers (potential harm, affected populations, scale, uncertainty). - Assign an incident commander role and backups (product safety lead, not just legal). - Capture a decision memo: what is known, what is unknown, and what is being done next. *Recommended next step* *Placement: after the workflow or playbook section* ## Turn EU GPSR Recalls and Incident Management into an operational assessment Assessment Autopilot can take EU GPSR Recalls and Incident Management from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on EU GPSR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GPSR Recalls and Incident Management](/solutions/assessment.md): Start from EU GPSR Recalls and Incident Management and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GPSR](/contact.md): Review your current process, evidence gaps, and next steps for EU GPSR Recalls and Incident Management. ## Corrective action vs recall (choose the minimal effective action) Not every issue is a recall, but every dangerous product needs decisive action. Build decision criteria and pre-approved actions (withdrawal, repair, replacement, refund, consumer instructions). Operational outcome: consistent actions across regions and channels, with evidence that the action is effective. - Action catalog: stop-ship, delist, quarantine inventory, patch/repair program, replacement, refund. - Channel plan: direct customers vs distributors vs marketplaces (each needs a different execution path). - Effectiveness plan: how you will measure reach and completion. ## Safety Gate / Safety Business Gateway notifications (build muscle memory) Do not learn notification tooling during a crisis. Provision accounts, define data fields, and run drills. Maintain a notification log that links to incident artifacts and corrective actions. - Access provisioning + backups (who can submit, who can approve). - Standard data pack: product identifiers, risk description, corrective actions, affected markets, contact points. - Post-submission workflow: follow-ups, authority questions, and evidence updates. ## Consumer communication: use the recall notice template effectively The recall notice template is not a marketing email. It is a safety communication with structured content requirements. Article 35 requires direct notification without undue delay where affected consumers can be identified. If they cannot all be identified, the recall notice or safety warning must still be disseminated through the widest appropriate channels and be accessible to persons with disabilities. - Minimize friction for consumers (simple steps, clear remedies, cost-free and timely outcomes under Article 37). - Use direct contact where possible, including customer accounts, registration systems, or loyalty data kept for safety communications. - Localize: languages, channels, accessibility, and call center scripts. - Keep proof: communications sent, landing pages, call logs, and outcome metrics. ## Evidence pack (what you need ready within hours) During incidents, authorities and partners will ask for the same evidence categories. Prepare a standard evidence pack so responses are consistent and fast. Treat the evidence pack as an exportable bundle (PDF + links + logs). - Incident timeline: detection, decisions, actions, notifications, communications, closure. - Affected product identification: SKU/batch/serial mapping + distribution channels. - Corrective action effectiveness: reach metrics, completion rates, and residual risk decisions. ## Primary sources - [GPSR full text - Regulation (EU) 2023/988 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02023R0988-20230523&ref=sorena.io) - Primary source for corrective actions, accident notification context, and recall-related obligations. - [Recall notice template - Implementing Regulation (EU) 2024/1435 (EUR-Lex consolidated HTML)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02024R1435-20240527&ref=sorena.io) - Establishes the recall notice template referenced for recall communications. - [CASP 2020 recall effectiveness guide](https://webgate.ec.europa.eu/safety-gate-screen/webReport/guide/recallProcessGuide?ref=sorena.io) - Practical recall-effectiveness guidance on direct contact, channels, and measurement. - [Safety Business Gateway (tool)](https://webgate.ec.europa.eu/safety-business-gateway/?ref=sorena.io) - Submission interface for certain notifications by economic operators and online marketplaces. - [Safety Gate Portal - effective recalls resources](https://ec.europa.eu/safety-gate/#/screen/pages/effectiveRecalls?ref=sorena.io) - Recall-related resources referenced in Commission material. ## Related Topic Guides - [EU GPSR Applicability Test | Is Regulation (EU) 2023/988 Applicable to Your Product, Channel, and Role?](/artifacts/eu/general-product-safety-regulation/applicability-test.md): A step-by-step EU GPSR applicability test for Regulation (EU) 2023/988: confirm whether your products are covered, whether exclusions apply. - [EU GPSR Checklist | Audit-Ready Compliance Checklist for Regulation (EU) 2023/988 (Safety Gate, Recalls, Marketplaces, Evidence)](/artifacts/eu/general-product-safety-regulation/checklist.md): An audit-ready EU GPSR checklist for Regulation (EU) 2023/988: scope and role mapping, documentation and traceability, supplier evidence. - [EU GPSR Compliance Program | Operating Model, Governance, Controls, and Evidence for Regulation (EU) 2023/988](/artifacts/eu/general-product-safety-regulation/compliance.md): A practical EU GPSR compliance playbook for Regulation (EU) 2023/988: program setup, governance cadence, risk assessment controls. - [EU GPSR Deadlines and Compliance Calendar | Key Dates, Workstreams, and Operational Milestones (Safety Gate, Recalls, Marketplaces)](/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar.md): A practical EU GPSR calendar for Regulation (EU) 2023/988: key dates and operational milestones, with a workstream-based plan covering scope and role mapping. - [EU GPSR Economic Operator Duties | Manufacturer vs Importer vs Distributor vs Fulfilment vs Marketplace Roles + Evidence](/artifacts/eu/general-product-safety-regulation/economic-operator-duties.md): A practical guide to EU GPSR economic operator duties under Regulation (EU) 2023/988: how to map roles across your supply chain. - [EU GPSR FAQ | Common Questions About Regulation (EU) 2023/988 (Scope, Online Marketplaces, Safety Gate, Recalls)](/artifacts/eu/general-product-safety-regulation/faq.md): Answers to common EU GPSR questions: scope and exclusions, used/repaired products, online marketplaces, Safety Gate/Safety Business Gateway notifications. - [EU GPSR Online Marketplace Obligations | Safety Gate Interface (2024/1459), Unsafe Product Removal, Notices, and Evidence](/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations.md): A practical guide for online marketplaces under EU GPSR (Regulation (EU) 2023/988): who is a 'provider of an online marketplace'. - [EU GPSR Penalties and Enforcement | Market Surveillance, Corrective Actions, and How to Reduce Risk With Evidence](/artifacts/eu/general-product-safety-regulation/penalties-and-fines.md): A practical guide to enforcement under EU GPSR (Regulation (EU) 2023/988): how market surveillance works, what enforcement actions look like (restrictions. - [EU GPSR Product Recall Notice Template | How to Use Implementing Regulation (EU) 2024/1435 (Article 36)](/artifacts/eu/general-product-safety-regulation/product-recall-notice-template.md): A practical guide to the EU GPSR recall notice template: when it applies, how to fill it correctly, what evidence to retain. - [EU GPSR Requirements (Regulation (EU) 2023/988) | Obligations, Controls, Safety Gate Notifications, and Evidence](/artifacts/eu/general-product-safety-regulation/requirements.md): An implementation-grade breakdown of EU GPSR requirements under Regulation (EU) 2023/988: safe product lifecycle controls, risk assessment. - [EU GPSR Scope and Covered Products | What's In/Out, Overlap With Sector Rules, Online Sales, Used/Reconditioned Goods](/artifacts/eu/general-product-safety-regulation/scope-and-covered-products.md): A practical GPSR scope guide for Regulation (EU) 2023/988: what products are covered, common exclusions. - [EU GPSR Traceability and Documentation | Product Safety Evidence Packs, Supplier Data, and Audit-Ready Records](/artifacts/eu/general-product-safety-regulation/traceability-and-documentation.md): A practical GPSR documentation and traceability guide for Regulation (EU) 2023/988: what information to maintain. - [GPSR vs Market Surveillance Regulation (EU) 2019/1020 | What's Different, What Overlaps, and What to Build](/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Market Surveillance Regulation (EU) 2019/1020: what each governs. - [GPSR vs Product Liability Directive (85/374/EEC) | Safety Obligations vs Liability Risk, Recalls, Evidence, and Claims Readiness](/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Product Liability Directive (85/374/EEC). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management --- --- title: "EU GPSR Requirements (Regulation (EU) 2023/988)" canonical_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/requirements" source_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/requirements" author: "Sorena AI" description: "An implementation-grade breakdown of EU GPSR requirements under Regulation (EU) 2023/988: safe product lifecycle controls, risk assessment." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU GPSR requirements" - "Regulation (EU) 2023/988 requirements" - "general product safety regulation obligations" - "Safety Gate notification requirements" - "Safety Business Gateway" - "product recall requirements EU" - "online marketplace obligations GPSR" - "economic operator duties GPSR" - "product safety documentation evidence" - "GPSR requirements" - "product safety" - "Safety Gate" - "recalls" - "online marketplaces" - "economic operators" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GPSR Requirements (Regulation (EU) 2023/988) An implementation-grade breakdown of EU GPSR requirements under Regulation (EU) 2023/988: safe product lifecycle controls, risk assessment. *Requirements* *EU* ## EU GPSR Requirements Turn GPSR obligations into controls, owners, and evidence you can export. Focus: safe product lifecycle, documentation, Safety Gate notifications, online marketplaces, and recalls. GPSR compliance is operational. You need repeatable controls (risk assessment, documentation, monitoring, corrective actions) and a notification and recall capability that works under time pressure. This page organizes key GPSR requirements into workflows you can assign to owners and prove with evidence. ## 1) Safe product lifecycle controls (baseline program) Treat GPSR as a lifecycle system: design -> production -> distribution -> post-market monitoring -> corrective action. Most failures happen when teams only focus on pre-market checks and forget monitoring and action loops. Build a single source-of-truth for product safety decisions: risk assessments, test evidence, supplier evidence, incidents, and actions. - Risk assessment method per product family (hazards, vulnerable users, foreseeable misuse). - Supplier and change-control gates (component changes trigger safety review). - Post-market signal intake (support tickets, returns, complaints, marketplace signals). ## 2) Documentation and traceability (make safety provable) Authorities and marketplaces expect you to produce information quickly: product identifiers, batch/lot information, safety warnings, contact points, and supporting documentation. Your goal is to compress time-to-evidence: answer 'what is the risk, who is affected, what did we do, and what did we notify?' in minutes, not days. - Maintain traceability fields across systems (SKU -> batch/lot -> supplier -> channel). - Define a documentation pack format and refresh cadence (quarterly + on major changes). - Create an evidence index for rapid export (authority inquiry or marketplace escalation). ## 3) Safety Gate / Safety Business Gateway notifications (dangerous products + accidents) GPSR and Delegated Regulation (EU) 2024/3173 introduce structured notification categories, detailed data fields, and risk-assessment expectations. If you wait until you have a dangerous product event to learn the tools, you will fail response expectations. Implement the process now: roles, templates, access provisioning, and an internal triage policy for what qualifies as a dangerous product, a serious risk, or an accident trigger. - Provision Safety Business Gateway access for the right owners (and create backups). - Standardize notification data fields (product identifiers, risk description, corrective actions, affected markets, supply-chain actors, online offer URLs where relevant). - Understand the notification classes used in Safety Gate: serious risk notification, other risk notification, notification for information, and follow-up notification. - Keep a notification log: submissions, completeness checks, Commission responses, follow-ups, and evidence. ## 4) Corrective actions and recalls (plan for execution, not theory) Corrective action is a capability. You need prebuilt playbooks, approved messaging, and data to reach affected consumers. Use the recall notice template as an operational artifact: your comms team should be able to produce a compliant notice in hours. - Recall decision criteria and escalation path (who can trigger a recall). - Recall comms library (channels, languages, customer segmentation, remedies). - Effectiveness measurement (how you know the recall reached and was acted on). ## 5) Online marketplaces (if you operate one or sell through one) Online marketplaces face additional interface and operational duties. Even if you are not a marketplace, your listings and seller operations can be impacted by marketplace safety processes. Align product safety work with marketplace operations: listing governance, rapid takedown, and communication workflows. - Maintain listing governance and product identifiers for fast removal/correction. - Integrate with Safety Gate tooling where required and monitor alerts relevant to your catalog. - Define response SLAs for unsafe product notices and internal escalation. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU GPSR Requirements into an operational assessment Assessment Autopilot can take EU GPSR Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU GPSR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU GPSR Requirements](/solutions/assessment.md): Start from EU GPSR Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU GPSR](/contact.md): Review your current process, evidence gaps, and next steps for EU GPSR Requirements. ## Primary sources - [GPSR full text - Regulation (EU) 2023/988 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02023R0988-20230523&ref=sorena.io) - Primary legal text for GPSR obligations, roles, corrective actions, and notification expectations. - [Recall notice template - Implementing Regulation (EU) 2024/1435 (EUR-Lex consolidated HTML)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02024R1435-20240527&ref=sorena.io) - Establishes the template for recall notices under GPSR Article 36. - [Online marketplace interface rules - Implementing Regulation (EU) 2024/1459 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1459&ref=sorena.io) - Rules for implementing the interoperable interface of the Safety Gate Portal for online marketplace providers. - [Safety Gate access/operation rules - Delegated Regulation (EU) 2024/3173 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R3173&ref=sorena.io) - Details on Safety Gate system access and notification information requirements. ## Related Topic Guides - [EU GPSR Applicability Test | Is Regulation (EU) 2023/988 Applicable to Your Product, Channel, and Role?](/artifacts/eu/general-product-safety-regulation/applicability-test.md): A step-by-step EU GPSR applicability test for Regulation (EU) 2023/988: confirm whether your products are covered, whether exclusions apply. - [EU GPSR Checklist | Audit-Ready Compliance Checklist for Regulation (EU) 2023/988 (Safety Gate, Recalls, Marketplaces, Evidence)](/artifacts/eu/general-product-safety-regulation/checklist.md): An audit-ready EU GPSR checklist for Regulation (EU) 2023/988: scope and role mapping, documentation and traceability, supplier evidence. - [EU GPSR Compliance Program | Operating Model, Governance, Controls, and Evidence for Regulation (EU) 2023/988](/artifacts/eu/general-product-safety-regulation/compliance.md): A practical EU GPSR compliance playbook for Regulation (EU) 2023/988: program setup, governance cadence, risk assessment controls. - [EU GPSR Deadlines and Compliance Calendar | Key Dates, Workstreams, and Operational Milestones (Safety Gate, Recalls, Marketplaces)](/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar.md): A practical EU GPSR calendar for Regulation (EU) 2023/988: key dates and operational milestones, with a workstream-based plan covering scope and role mapping. - [EU GPSR Economic Operator Duties | Manufacturer vs Importer vs Distributor vs Fulfilment vs Marketplace Roles + Evidence](/artifacts/eu/general-product-safety-regulation/economic-operator-duties.md): A practical guide to EU GPSR economic operator duties under Regulation (EU) 2023/988: how to map roles across your supply chain. - [EU GPSR FAQ | Common Questions About Regulation (EU) 2023/988 (Scope, Online Marketplaces, Safety Gate, Recalls)](/artifacts/eu/general-product-safety-regulation/faq.md): Answers to common EU GPSR questions: scope and exclusions, used/repaired products, online marketplaces, Safety Gate/Safety Business Gateway notifications. - [EU GPSR Online Marketplace Obligations | Safety Gate Interface (2024/1459), Unsafe Product Removal, Notices, and Evidence](/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations.md): A practical guide for online marketplaces under EU GPSR (Regulation (EU) 2023/988): who is a 'provider of an online marketplace'. - [EU GPSR Penalties and Enforcement | Market Surveillance, Corrective Actions, and How to Reduce Risk With Evidence](/artifacts/eu/general-product-safety-regulation/penalties-and-fines.md): A practical guide to enforcement under EU GPSR (Regulation (EU) 2023/988): how market surveillance works, what enforcement actions look like (restrictions. - [EU GPSR Product Recall Notice Template | How to Use Implementing Regulation (EU) 2024/1435 (Article 36)](/artifacts/eu/general-product-safety-regulation/product-recall-notice-template.md): A practical guide to the EU GPSR recall notice template: when it applies, how to fill it correctly, what evidence to retain. - [EU GPSR Recalls and Incident Management | Corrective Actions, Safety Gate Notifications, Recall Effectiveness, Playbooks](/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management.md): A practical recall and incident management playbook for EU GPSR (Regulation (EU) 2023/988): build a triage workflow, decide corrective actions vs recall. - [EU GPSR Scope and Covered Products | What's In/Out, Overlap With Sector Rules, Online Sales, Used/Reconditioned Goods](/artifacts/eu/general-product-safety-regulation/scope-and-covered-products.md): A practical GPSR scope guide for Regulation (EU) 2023/988: what products are covered, common exclusions. - [EU GPSR Traceability and Documentation | Product Safety Evidence Packs, Supplier Data, and Audit-Ready Records](/artifacts/eu/general-product-safety-regulation/traceability-and-documentation.md): A practical GPSR documentation and traceability guide for Regulation (EU) 2023/988: what information to maintain. - [GPSR vs Market Surveillance Regulation (EU) 2019/1020 | What's Different, What Overlaps, and What to Build](/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Market Surveillance Regulation (EU) 2019/1020: what each governs. - [GPSR vs Product Liability Directive (85/374/EEC) | Safety Obligations vs Liability Risk, Recalls, Evidence, and Claims Readiness](/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Product Liability Directive (85/374/EEC). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/general-product-safety-regulation/requirements --- --- title: "EU GPSR Scope and Covered Products" canonical_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/scope-and-covered-products" source_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/scope-and-covered-products" author: "Sorena AI" description: "A practical GPSR scope guide for Regulation (EU) 2023/988: what products are covered, common exclusions." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU GPSR scope" - "general product safety regulation scope" - "Regulation (EU) 2023/988 scope" - "GPSR covered products" - "GPSR exclusions" - "GPSR online sales" - "GPSR used products" - "GPSR repaired reconditioned products" - "product safety compliance EU" - "GPSR scope" - "covered products" - "exclusions" - "online sales" - "market surveillance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GPSR Scope and Covered Products A practical GPSR scope guide for Regulation (EU) 2023/988: what products are covered, common exclusions. *Scope* *EU* ## EU GPSR Scope and Covered Products Turn 'are we in scope?' into a repeatable scoping decision with evidence. Focus: covered products, exclusions, overlap with sector rules, and what changes for online sales and marketplaces. Scope mistakes are the fastest way to build the wrong product safety program. Under the EU General Product Safety Regulation (GPSR), scoping is not just 'is this a consumer product?'-it's also: which risks are governed by sector-specific EU rules, what role you play in the supply chain, and whether your sales channel (especially online marketplaces) triggers additional operational duties. ## What the GPSR covers (the practical view) The GPSR sets baseline consumer product safety rules for products made available on the EU market, including products sold online. It is designed to cover gaps that aren't fully addressed by sector-specific EU product legislation. Operational outcome: maintain a product catalog map (product families/categories) to 'applicable rule sets' and 'responsible economic operator' assignments. - Covered products by channel: in-store, direct-to-consumer, cross-border e-commerce, marketplace listings. - Lifecycle states: new, used, repaired, and reconditioned goods can still be in scope depending on how they reach consumers. - Role-aware obligations: manufacturer/importer/distributor/fulfilment/marketplace duties differ. *Recommended next step* *Placement: after the scope or definition section* ## Use EU GPSR Scope and Covered Products as a cited research workflow Research Copilot can take EU GPSR Scope and Covered Products from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU GPSR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU GPSR Scope and Covered Products](/solutions/research-copilot.md): Start from EU GPSR Scope and Covered Products and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU GPSR](/contact.md): Review your current process, evidence gaps, and next steps for EU GPSR Scope and Covered Products. ## Exclusions and overlap with sector rules (avoid double-counting) Don't treat exclusions as assumptions. You need a traceable rationale: what is excluded, and which legal framework governs instead. In real products, GPSR is often partially applicable as a 'gap-filler' for operational duties (monitoring, corrective actions, consumer reach) even when sector rules govern core technical specs. - Create a product taxonomy -> governing rules mapping (primary rule + GPSR add-ons). - Document exclusions: what is excluded, why, and what alternate framework applies. - Define review triggers: design change, new market, new channel, new supplier, incident signal. ## Channels: online sales and marketplaces change your operating model Online distribution introduces 'speed and scale' risk: listings propagate fast, unsafe products must be removed quickly once identified, and recalls require consumer reach across channels. Design an incident-to-action workflow: detect -> validate -> notify -> remove/recall -> measure effectiveness. - Maintain listing governance: product identifiers, traceability data, and contacts for rapid action. - Prebuild recall communications and Safety Gate notification packs before you need them. - Integrate product safety signals from support/returns/marketplace tooling into a single triage queue. ## Audit-ready scoping checklist (what 'done' looks like) A good GPSR scoping decision is reproducible: another reviewer should reach the same answer using your evidence. Treat scoping as a controlled artifact: versioned, owner-assigned, and refreshed on product/channel change. - Product scope memo per category (coverage rationale + exclusions). - Economic operator role map (who owns what duties for each channel). - Evidence index: risk assessment approach, documentation/traceability, recall playbook, notification workflow. - Change triggers and review cadence (quarterly + on major product/channel change). ## Primary sources - [GPSR full text - Regulation (EU) 2023/988 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02023R0988-20230523&ref=sorena.io) - Primary legal text for scope, definitions, economic operator duties, corrective actions, and Safety Gate obligations. - [Market surveillance framework - Regulation (EU) 2019/1020 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02019R1020-20240523&ref=sorena.io) - Context for enforcement and market surveillance operations that interact with GPSR obligations. - [Safety Gate access/operation rules - Delegated Regulation (EU) 2024/3173 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R3173&ref=sorena.io) - Details on Safety Gate Rapid Alert System access, information requirements, and risk assessment criteria. ## Related Topic Guides - [EU GPSR Applicability Test | Is Regulation (EU) 2023/988 Applicable to Your Product, Channel, and Role?](/artifacts/eu/general-product-safety-regulation/applicability-test.md): A step-by-step EU GPSR applicability test for Regulation (EU) 2023/988: confirm whether your products are covered, whether exclusions apply. - [EU GPSR Checklist | Audit-Ready Compliance Checklist for Regulation (EU) 2023/988 (Safety Gate, Recalls, Marketplaces, Evidence)](/artifacts/eu/general-product-safety-regulation/checklist.md): An audit-ready EU GPSR checklist for Regulation (EU) 2023/988: scope and role mapping, documentation and traceability, supplier evidence. - [EU GPSR Compliance Program | Operating Model, Governance, Controls, and Evidence for Regulation (EU) 2023/988](/artifacts/eu/general-product-safety-regulation/compliance.md): A practical EU GPSR compliance playbook for Regulation (EU) 2023/988: program setup, governance cadence, risk assessment controls. - [EU GPSR Deadlines and Compliance Calendar | Key Dates, Workstreams, and Operational Milestones (Safety Gate, Recalls, Marketplaces)](/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar.md): A practical EU GPSR calendar for Regulation (EU) 2023/988: key dates and operational milestones, with a workstream-based plan covering scope and role mapping. - [EU GPSR Economic Operator Duties | Manufacturer vs Importer vs Distributor vs Fulfilment vs Marketplace Roles + Evidence](/artifacts/eu/general-product-safety-regulation/economic-operator-duties.md): A practical guide to EU GPSR economic operator duties under Regulation (EU) 2023/988: how to map roles across your supply chain. - [EU GPSR FAQ | Common Questions About Regulation (EU) 2023/988 (Scope, Online Marketplaces, Safety Gate, Recalls)](/artifacts/eu/general-product-safety-regulation/faq.md): Answers to common EU GPSR questions: scope and exclusions, used/repaired products, online marketplaces, Safety Gate/Safety Business Gateway notifications. - [EU GPSR Online Marketplace Obligations | Safety Gate Interface (2024/1459), Unsafe Product Removal, Notices, and Evidence](/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations.md): A practical guide for online marketplaces under EU GPSR (Regulation (EU) 2023/988): who is a 'provider of an online marketplace'. - [EU GPSR Penalties and Enforcement | Market Surveillance, Corrective Actions, and How to Reduce Risk With Evidence](/artifacts/eu/general-product-safety-regulation/penalties-and-fines.md): A practical guide to enforcement under EU GPSR (Regulation (EU) 2023/988): how market surveillance works, what enforcement actions look like (restrictions. - [EU GPSR Product Recall Notice Template | How to Use Implementing Regulation (EU) 2024/1435 (Article 36)](/artifacts/eu/general-product-safety-regulation/product-recall-notice-template.md): A practical guide to the EU GPSR recall notice template: when it applies, how to fill it correctly, what evidence to retain. - [EU GPSR Recalls and Incident Management | Corrective Actions, Safety Gate Notifications, Recall Effectiveness, Playbooks](/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management.md): A practical recall and incident management playbook for EU GPSR (Regulation (EU) 2023/988): build a triage workflow, decide corrective actions vs recall. - [EU GPSR Requirements (Regulation (EU) 2023/988) | Obligations, Controls, Safety Gate Notifications, and Evidence](/artifacts/eu/general-product-safety-regulation/requirements.md): An implementation-grade breakdown of EU GPSR requirements under Regulation (EU) 2023/988: safe product lifecycle controls, risk assessment. - [EU GPSR Traceability and Documentation | Product Safety Evidence Packs, Supplier Data, and Audit-Ready Records](/artifacts/eu/general-product-safety-regulation/traceability-and-documentation.md): A practical GPSR documentation and traceability guide for Regulation (EU) 2023/988: what information to maintain. - [GPSR vs Market Surveillance Regulation (EU) 2019/1020 | What's Different, What Overlaps, and What to Build](/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Market Surveillance Regulation (EU) 2019/1020: what each governs. - [GPSR vs Product Liability Directive (85/374/EEC) | Safety Obligations vs Liability Risk, Recalls, Evidence, and Claims Readiness](/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Product Liability Directive (85/374/EEC). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/general-product-safety-regulation/scope-and-covered-products --- --- title: "EU GPSR Traceability and Documentation" canonical_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/traceability-and-documentation" source_url: "https://www.sorena.io/artifacts/eu/general-product-safety-regulation/traceability-and-documentation" author: "Sorena AI" description: "A practical GPSR documentation and traceability guide for Regulation (EU) 2023/988: what information to maintain." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU GPSR documentation" - "GPSR traceability" - "Regulation (EU) 2023/988 documentation requirements" - "product safety evidence pack" - "supplier documentation GPSR" - "batch lot traceability EU" - "product recall traceability" - "Safety Gate evidence" - "documentation" - "traceability" - "evidence" - "supplier governance" - "product safety" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU GPSR Traceability and Documentation A practical GPSR documentation and traceability guide for Regulation (EU) 2023/988: what information to maintain. *Evidence* *EU* ## EU GPSR Traceability and Documentation Make product safety provable, exportable, and fast under pressure. Focus: documentation pack, traceability fields, supplier evidence, and evidence exports. GPSR documentation isn't a compliance binder-it's an operational system. When a safety signal appears, you must quickly identify affected products, markets, and consumers, and then execute corrective actions and notifications. That only works if traceability and documentation are designed into your product lifecycle and tooling. ## Design the 'evidence pack' first (then fill it) Start by defining the evidence pack structure you will export during an incident, authority inquiry, or marketplace escalation. Then map each section to an owner, system-of-record, and refresh cadence. Operational outcome: time-to-evidence becomes a KPI you can measure and improve. - Pack index: where each artifact lives, owner, last updated date, export format. - Decision memos: scope/role mapping, risk assessment approach, corrective action rationale. - Execution logs: incidents, investigations, notifications, recalls, effectiveness evidence. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU GPSR Traceability and Documentation in one governed evidence system SSOT can take EU GPSR Traceability and Documentation from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU GPSR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU GPSR Traceability and Documentation](/solutions/ssot.md): Start from EU GPSR Traceability and Documentation and keep documents, evidence, and control records in one governed system. - [Talk through EU GPSR](/contact.md): Review your current process, evidence gaps, and next steps for EU GPSR Traceability and Documentation. ## Traceability model (SKU -> batch/lot -> supplier -> channel) Build a minimal traceability schema that works across ERP/PLM, supplier management, customer support, and marketplace operations. Your goal is to answer: which units are affected, where were they sold, and how do we reach consumers? - Core identifiers: product family, SKU, model, batch/lot/serial where applicable. - Supplier linkage: supplier ID, component versions, change history, test evidence references. - Channel linkage: direct, distributor, marketplace listings, fulfillment nodes, returns/refurbishment flows. ## Supplier evidence requests (make them repeatable) Supplier documentation becomes your evidence. Without a standard request package, every supplier engagement becomes a custom negotiation. Build a 'supplier evidence request' template and apply it consistently by risk tier. - Required evidence by category: test results, safety warnings, materials/composition where relevant, traceability fields. - Change notification requirements: what changes must be reported before shipment. - Right-to-audit and corrective action cooperation clauses. ## What 'audit-ready' looks like Audit readiness is not volume. It's clarity, traceability, and the ability to retrieve evidence quickly. Aim for: a coherent narrative of safety decisions and actions, supported by dated artifacts and logs. - Evidence index is current and includes backups/secondary owners. - Incident/recall playbook is versioned and has last-run drill evidence. - Notification workflow has access provisioning tested (not assumed). ## Primary sources - [GPSR full text - Regulation (EU) 2023/988 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02023R0988-20230523&ref=sorena.io) - Primary source for GPSR obligations and role-based documentation expectations. - [Market surveillance framework - Regulation (EU) 2019/1020 (EUR-Lex consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02019R1020-20240523&ref=sorena.io) - Context for how authorities request and use documentation and evidence. - [CEN-CENELEC - consumer product safety standardization work (consumer sector page)](https://www.cencenelec.eu/areas-of-work/cen-sectors/consumer/?ref=sorena.io) - Standardization context supporting implementation of product safety requirements (useful for documentation and evidence planning). ## Related Topic Guides - [EU GPSR Applicability Test | Is Regulation (EU) 2023/988 Applicable to Your Product, Channel, and Role?](/artifacts/eu/general-product-safety-regulation/applicability-test.md): A step-by-step EU GPSR applicability test for Regulation (EU) 2023/988: confirm whether your products are covered, whether exclusions apply. - [EU GPSR Checklist | Audit-Ready Compliance Checklist for Regulation (EU) 2023/988 (Safety Gate, Recalls, Marketplaces, Evidence)](/artifacts/eu/general-product-safety-regulation/checklist.md): An audit-ready EU GPSR checklist for Regulation (EU) 2023/988: scope and role mapping, documentation and traceability, supplier evidence. - [EU GPSR Compliance Program | Operating Model, Governance, Controls, and Evidence for Regulation (EU) 2023/988](/artifacts/eu/general-product-safety-regulation/compliance.md): A practical EU GPSR compliance playbook for Regulation (EU) 2023/988: program setup, governance cadence, risk assessment controls. - [EU GPSR Deadlines and Compliance Calendar | Key Dates, Workstreams, and Operational Milestones (Safety Gate, Recalls, Marketplaces)](/artifacts/eu/general-product-safety-regulation/deadlines-and-compliance-calendar.md): A practical EU GPSR calendar for Regulation (EU) 2023/988: key dates and operational milestones, with a workstream-based plan covering scope and role mapping. - [EU GPSR Economic Operator Duties | Manufacturer vs Importer vs Distributor vs Fulfilment vs Marketplace Roles + Evidence](/artifacts/eu/general-product-safety-regulation/economic-operator-duties.md): A practical guide to EU GPSR economic operator duties under Regulation (EU) 2023/988: how to map roles across your supply chain. - [EU GPSR FAQ | Common Questions About Regulation (EU) 2023/988 (Scope, Online Marketplaces, Safety Gate, Recalls)](/artifacts/eu/general-product-safety-regulation/faq.md): Answers to common EU GPSR questions: scope and exclusions, used/repaired products, online marketplaces, Safety Gate/Safety Business Gateway notifications. - [EU GPSR Online Marketplace Obligations | Safety Gate Interface (2024/1459), Unsafe Product Removal, Notices, and Evidence](/artifacts/eu/general-product-safety-regulation/online-marketplace-obligations.md): A practical guide for online marketplaces under EU GPSR (Regulation (EU) 2023/988): who is a 'provider of an online marketplace'. - [EU GPSR Penalties and Enforcement | Market Surveillance, Corrective Actions, and How to Reduce Risk With Evidence](/artifacts/eu/general-product-safety-regulation/penalties-and-fines.md): A practical guide to enforcement under EU GPSR (Regulation (EU) 2023/988): how market surveillance works, what enforcement actions look like (restrictions. - [EU GPSR Product Recall Notice Template | How to Use Implementing Regulation (EU) 2024/1435 (Article 36)](/artifacts/eu/general-product-safety-regulation/product-recall-notice-template.md): A practical guide to the EU GPSR recall notice template: when it applies, how to fill it correctly, what evidence to retain. - [EU GPSR Recalls and Incident Management | Corrective Actions, Safety Gate Notifications, Recall Effectiveness, Playbooks](/artifacts/eu/general-product-safety-regulation/recalls-and-incident-management.md): A practical recall and incident management playbook for EU GPSR (Regulation (EU) 2023/988): build a triage workflow, decide corrective actions vs recall. - [EU GPSR Requirements (Regulation (EU) 2023/988) | Obligations, Controls, Safety Gate Notifications, and Evidence](/artifacts/eu/general-product-safety-regulation/requirements.md): An implementation-grade breakdown of EU GPSR requirements under Regulation (EU) 2023/988: safe product lifecycle controls, risk assessment. - [EU GPSR Scope and Covered Products | What's In/Out, Overlap With Sector Rules, Online Sales, Used/Reconditioned Goods](/artifacts/eu/general-product-safety-regulation/scope-and-covered-products.md): A practical GPSR scope guide for Regulation (EU) 2023/988: what products are covered, common exclusions. - [GPSR vs Market Surveillance Regulation (EU) 2019/1020 | What's Different, What Overlaps, and What to Build](/artifacts/eu/general-product-safety-regulation/gpsr-vs-market-surveillance-regulation.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Market Surveillance Regulation (EU) 2019/1020: what each governs. - [GPSR vs Product Liability Directive (85/374/EEC) | Safety Obligations vs Liability Risk, Recalls, Evidence, and Claims Readiness](/artifacts/eu/general-product-safety-regulation/gpsr-vs-product-liability-directive.md): A practical comparison of EU GPSR (Regulation (EU) 2023/988) and the Product Liability Directive (85/374/EEC). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/general-product-safety-regulation/traceability-and-documentation --- --- title: "EU Green Claims Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/applicability-test" author: "Sorena AI" description: "A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "green claims applicability test" - "is this a green claim" - "environmental claim scope" - "greenwashing compliance checklist" - "carbon neutral claim scope" - "EU green claims directive scope" - "applicability test" - "green claims" - "greenwashing" - "substantiation" - "marketing compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Green Claims Applicability Test A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim. *Scope* *EU* ## EU Green Claims Applicability Test A decision-grade test for whether a claim is in scope and what to do next. Output: publish / revise / block / escalate + evidence pack requirements. This applicability test is designed for real workflows: marketing drafts a claim, reviewers need a fast answer, and the organization needs consistent evidence. Use it to decide scope, identify risky claim patterns (especially offset-based climate claims), and trigger the right substantiation template and verification path. ## Step 1 - Define the claim object Start with the actual claim text and where it appears. Don't review a screenshot without knowing the channel and the implied messaging. A claim is more than text: visuals, icons, and badges can create implied environmental messaging. - Exact claim text + any headline/subheadline variants. - Channel: product page, ads, packaging, app UI, investor deck, CSR report. - Is it explicit or implied (imagery, seals, ratings, 'eco' cues)? ## Step 2 - Classify scope: product vs company, absolute vs comparative Classification determines evidence. Absolute claims and corporate claims typically require the strongest substantiation and clearest boundaries. Comparative claims require a defensible baseline and like-for-like methodology. - Product claim vs corporate claim (brand/company-level). - Absolute ('carbon neutral') vs comparative ('30% lower emissions'). - Trade-off risk (improves one impact category while worsening another). ## Step 3 - Check overlaps and exclusions (labels and sector rules) Many claims are governed by sector-specific rules and established EU labels. Reviewers should identify when a claim is already regulated or when a label scheme governs the messaging. Operational outcome: point to the governing framework and avoid double standards. - Is the claim tied to an established label (e.g., EU Ecolabel) or scheme rules? - Is there a sector-specific EU framework that governs claim content or measurement? - Is the claim actually a label-like claim (badge/rating) that needs scheme governance review? ## Step 4 - High-risk triggers (escalate, don't 'approve' casually) Some claim patterns deserve automatic escalation: they are frequently challenged, require complex evidence, or are easily misunderstood by consumers. Offset-based climate claims are the classic example. - Offset-based claims: 'carbon neutral', 'climate positive', 'net zero product'. - Vague/undefined terms: 'eco-friendly', 'green', 'sustainable' without quantified scope. - Claims that imply future performance or targets without a plan and evidence. ## Output - Publish / revise / block / escalate The best outcome is a simple decision with a reason and next steps, linked to evidence artifacts. Treat each high-impact claim as a versioned asset with a claim card and an evidence pack. - Publish: claim card + evidence pack exists and passes verification checklist. - Revise: missing boundary/disclosure; update wording and evidence; re-review. - Block: claim cannot be substantiated to the required standard; remove messaging. - Escalate: offsets, complex trade-offs, label scheme issues, or high-reach campaigns. *Recommended next step* *Placement: after the applicability result* ## Operationalize EU Green Claims Applicability Test across ESG workflows ESG Compliance can take EU Green Claims Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU Green Claims can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Green Claims Applicability Test](/solutions/esg-compliance.md): Start from EU Green Claims Applicability Test and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Green Claims](/contact.md): Review your current process, evidence gaps, and next steps for EU Green Claims Applicability Test. ## Primary sources - [European Commission - Questions and Answers on European Green Claims (QANDA/23/1693)](https://ec.europa.eu/commission/presscorner/detail/en/qanda_23_1693?ref=sorena.io) - Official Commission explanation of scope, claim types, and intent for ex ante verification. - [EU Ecolabel (official page)](https://environment.ec.europa.eu/topics/circular-economy/eu-ecolabel_en?ref=sorena.io) - Example of an EU label regime that can govern label-based messaging and scheme criteria. ## Related Topic Guides - [EU Green Claims Checklist | Audit-Ready Checklist for Environmental Claims (Substantiation, Verification, Labels, Offsets)](/artifacts/eu/green-claims-directive/checklist.md): An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality. - [EU Green Claims Compliance Program | Operating Model for Marketing Claims: Governance, Evidence Packs, Verification, and Labels](/artifacts/eu/green-claims-directive/compliance.md): A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards. - [EU Green Claims FAQ | Greenwashing Questions, Offsets, Labels, Evidence Packs, and Claim Approval Workflows](/artifacts/eu/green-claims-directive/faq.md): Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims. - [EU Green Claims Timeline and Readiness Calendar | Key Policy Dates + Operational Milestones for Evidence, Verification, and Labels](/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar.md): A practical timeline and readiness calendar for green claims. - [EU Green Claims vs UK Green Claims Code | Practical Differences for Substantiation, Disclosures, Verification, and Enforcement](/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code.md): A practical comparison for teams operating in both the EU and UK. - [Green Claims Substantiation Template | Evidence Pack Structure, Life-Cycle Thinking, Data Quality, and Disclosures](/artifacts/eu/green-claims-directive/green-claims-substantiation-template.md): A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective. - [Green Claims Templates | Claim Card, Substantiation Pack, Verification Checklist, Disclosures, and Approval Logs](/artifacts/eu/green-claims-directive/templates.md): A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist. - [Greenwashing Risk Checklist | EU Green Claims | Pre-Publication Review for Ads, Packaging, Product Pages, and Corporate Claims](/artifacts/eu/green-claims-directive/greenwashing-risk-checklist.md): A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims. - [Labels and Certification Schemes | EU Green Claims | How to Govern Eco-Labels, Badges, Seals, and Scheme Evidence](/artifacts/eu/green-claims-directive/labels-and-certification-schemes.md): A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims. - [Penalties and Enforcement | EU Green Claims | How Greenwashing is Enforced, What Evidence Reduces Risk, and What to Do During Challenges](/artifacts/eu/green-claims-directive/penalties-and-enforcement.md): A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for. - [Penalties and Fines | EU Green Claims | Penalty Drivers, Aggravating Factors, and How to Reduce Exposure With Evidence](/artifacts/eu/green-claims-directive/penalties-and-fines.md): A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries. - [Requirements | EU Green Claims Directive (Proposal) | Substantiation, Verification, Labels Governance, and Disclosures](/artifacts/eu/green-claims-directive/requirements.md): An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build). - [Substantiation and Evidence Pack | EU Green Claims | How to Build Audit-Ready Evidence for Environmental Claims](/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack.md): A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation. - [Verification and Audit Readiness | EU Green Claims | Reviewer Checklist, Sampling, Evidence Logs, and Common Findings](/artifacts/eu/green-claims-directive/verification-and-audit-readiness.md): A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios. - [What Counts as a Green Claim? | EU Green Claims Directive (Proposal) | Examples, Claim Types, Boundaries, and Common Traps](/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim.md): A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/green-claims-directive/applicability-test --- --- title: "EU Green Claims Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/checklist" source_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/checklist" author: "Sorena AI" description: "An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "green claims checklist" - "environmental claims compliance checklist" - "greenwashing checklist" - "claim substantiation checklist" - "green claims verification checklist" - "offsets disclosure checklist" - "eco label governance checklist" - "checklist" - "green claims" - "greenwashing" - "verification" - "evidence packs" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Green Claims Checklist An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality. *Checklist* *EU* ## EU Green Claims Checklist An audit-ready checklist with acceptance criteria and evidence outputs. Use it to build a claims program marketing can run without chaos. A green claims checklist should produce artifacts: claim cards, evidence packs, reviewer logs, and disclosure text. Use this checklist to implement a repeatable green claims operating model across product pages, ads, packaging, and corporate messaging. ## 1) Claim inventory and classification (foundation) Goal: every high-impact claim is classified and owned. If you can't list your claims, you can't govern them. Done looks like: claim inventory + taxonomy + claim cards with version history. - Claim inventory (product pages, ads, packaging, corporate statements, investor/CSR materials). - Claim taxonomy: product vs company; absolute vs comparative; label-like; offset-based. - Claim card per claim version: boundary, channels, owner, storage links. ## 2) Substantiation evidence packs (make claims provable) Goal: evidence is exportable and reproducible. Reviewers can replay calculations and understand boundaries. Done looks like: evidence pack templates + dataset inventory + trade-off handling notes. - Boundary statement: lifecycle stages, exclusions, geography/timeframe, variants. - Method + datasets: rationale, sources, versions, data quality criteria. - Trade-offs and uncertainty: sensitivity notes and limitations documented. ## 3) Verification workflow and approvals (controls + logs) Goal: approvals are consistent and logged. Claims don't pass without reviewer checks. Done looks like: verification checklist + approval log stored with evidence packs. - Verification checklist completed for Tier 1 and Tier 2 claims (risk-tiered). - Approval log: who reviewed, when, outcome (approve/revise/block), follow-ups. - Retention policy: where evidence lives, how long it's stored, access controls. ## 4) Offsets and climate neutrality claims (special gate) Goal: avoid ambiguous 'neutrality' messaging. Separate reductions and compensation clearly. Done looks like: offsets disclosure template + retirement evidence + boundary clarity. - Claim language separates reductions vs compensation (no implied absolutes). - Offset evidence: integrity criteria, retirement/cancellation records, assumptions. - Value-chain boundary and timeframe are stated and consumer-facing. ## 5) Labels and certification scheme governance (badge control) Goal: labels don't become implied claims without evidence. Scheme criteria and eligibility are current. Done looks like: scheme due diligence checklist + label evidence pack + usage log. - Scheme due diligence: criteria transparency, verification, non-compliance handling. - Label evidence pack: eligibility proof, audits, criteria version used, renewal cadence. - Label inventory: where badges appear and who approved usage. *Recommended next step* *Placement: after the checklist block* ## Operationalize EU Green Claims Checklist across ESG workflows ESG Compliance can take EU Green Claims Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Green Claims can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Green Claims Checklist](/solutions/esg-compliance.md): Start from EU Green Claims Checklist and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Green Claims](/contact.md): Review your current process, evidence gaps, and next steps for EU Green Claims Checklist. ## Primary sources - [European Commission - Questions and Answers on European Green Claims (QANDA/23/1693)](https://ec.europa.eu/commission/presscorner/detail/en/qanda_23_1693?ref=sorena.io) - Commission source explaining substantiation and verification intent and common greenwashing issues. - [European Parliament Think Tank - Green claims directive briefing (EPRS_BRI(2023)753958)](https://www.europarl.europa.eu/thinktank/en/document/EPRS_BRI(2023)753958?ref=sorena.io) - Policy summary and implementation context for environmental claims governance. ## Related Topic Guides - [EU Green Claims Applicability Test | Is This Environmental Claim In Scope (Product vs Company, Labels, Offsets)?](/artifacts/eu/green-claims-directive/applicability-test.md): A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim. - [EU Green Claims Compliance Program | Operating Model for Marketing Claims: Governance, Evidence Packs, Verification, and Labels](/artifacts/eu/green-claims-directive/compliance.md): A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards. - [EU Green Claims FAQ | Greenwashing Questions, Offsets, Labels, Evidence Packs, and Claim Approval Workflows](/artifacts/eu/green-claims-directive/faq.md): Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims. - [EU Green Claims Timeline and Readiness Calendar | Key Policy Dates + Operational Milestones for Evidence, Verification, and Labels](/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar.md): A practical timeline and readiness calendar for green claims. - [EU Green Claims vs UK Green Claims Code | Practical Differences for Substantiation, Disclosures, Verification, and Enforcement](/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code.md): A practical comparison for teams operating in both the EU and UK. - [Green Claims Substantiation Template | Evidence Pack Structure, Life-Cycle Thinking, Data Quality, and Disclosures](/artifacts/eu/green-claims-directive/green-claims-substantiation-template.md): A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective. - [Green Claims Templates | Claim Card, Substantiation Pack, Verification Checklist, Disclosures, and Approval Logs](/artifacts/eu/green-claims-directive/templates.md): A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist. - [Greenwashing Risk Checklist | EU Green Claims | Pre-Publication Review for Ads, Packaging, Product Pages, and Corporate Claims](/artifacts/eu/green-claims-directive/greenwashing-risk-checklist.md): A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims. - [Labels and Certification Schemes | EU Green Claims | How to Govern Eco-Labels, Badges, Seals, and Scheme Evidence](/artifacts/eu/green-claims-directive/labels-and-certification-schemes.md): A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims. - [Penalties and Enforcement | EU Green Claims | How Greenwashing is Enforced, What Evidence Reduces Risk, and What to Do During Challenges](/artifacts/eu/green-claims-directive/penalties-and-enforcement.md): A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for. - [Penalties and Fines | EU Green Claims | Penalty Drivers, Aggravating Factors, and How to Reduce Exposure With Evidence](/artifacts/eu/green-claims-directive/penalties-and-fines.md): A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries. - [Requirements | EU Green Claims Directive (Proposal) | Substantiation, Verification, Labels Governance, and Disclosures](/artifacts/eu/green-claims-directive/requirements.md): An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build). - [Substantiation and Evidence Pack | EU Green Claims | How to Build Audit-Ready Evidence for Environmental Claims](/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack.md): A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation. - [Verification and Audit Readiness | EU Green Claims | Reviewer Checklist, Sampling, Evidence Logs, and Common Findings](/artifacts/eu/green-claims-directive/verification-and-audit-readiness.md): A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios. - [What Counts as a Green Claim? | EU Green Claims Directive (Proposal) | Examples, Claim Types, Boundaries, and Common Traps](/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim.md): A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/green-claims-directive/checklist --- --- title: "EU Green Claims Compliance Program" canonical_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/compliance" source_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/compliance" author: "Sorena AI" description: "A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "green claims compliance program" - "greenwashing compliance program" - "environmental claims governance" - "marketing compliance workflow sustainability claims" - "green claims approval workflow" - "verification and substantiation program" - "compliance program" - "governance" - "marketing approvals" - "verification" - "evidence packs" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Green Claims Compliance Program A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards. *Playbook* *EU* ## EU Green Claims Compliance Program Turn green claims into a repeatable operating model (not a legal fire drill). Focus: governance, evidence, verification, labels, and training. The highest-performing green claims programs reduce friction: marketing moves faster because the process is predictable, and reviewers trust the evidence pack system. This playbook shows how to build that operating model across product pages, ads, packaging, and corporate statements. ## Workstreams (build the program like a product) Split the program into workstreams with named owners, acceptance criteria, and artifacts. The owner is responsible for evidence freshness and auditability. Design the system so it scales: portfolios of claims, multiple product lines, multiple markets. - Workstream A: claim inventory + taxonomy + claim cards. - Workstream B: substantiation standards + evidence pack templates + dataset governance. - Workstream C: verification workflow + approvals + logs (risk-tiered). - Workstream D: labels and scheme governance (inventory, due diligence, evidence packs). - Workstream E: training + content QA + continuous improvement loop. ## Governance cadence (keep evidence and claims current) Claims decay as products and supply chains change. Build a cadence that refreshes evidence and prevents stale messaging. Include 'policy change review' and 'incident review' as recurring inputs. - Monthly: new claims intake, open review actions, high-risk claim monitoring. - Quarterly: evidence refresh, supplier data updates, label renewals, baseline updates for comparisons. - Post-campaign: sampling audit and lessons learned (update templates and training). ## Risk tiers (review depth matches risk and reach) Not all claims deserve the same review depth. Use tiers by risk and audience reach. Absolute and offset-based climate claims should be Tier 1 by default. - Tier 1: absolute/offset-based climate claims, corporate claims, label-like claims, high-reach campaigns. - Tier 2: comparative claims, multi-impact claims, claims with known trade-offs. - Tier 3: narrow, specific claims with stable data and low reach. ## Evidence operating system (single source-of-truth) Make evidence exportable. Every claim should point to a pack with datasets, calculations, and disclosures. Define KPIs that reflect operational readiness, not just number of approved claims. - Evidence index + owners + refresh cadence. - Approval logs and version history for each claim used publicly. - KPIs: time-to-evidence, time-to-approval, % claims with complete packs, sampling audit findings. *Recommended next step* *Placement: after the compliance steps* ## Operationalize EU Green Claims Compliance Program across ESG workflows ESG Compliance can take EU Green Claims Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Green Claims can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Green Claims Compliance Program](/solutions/esg-compliance.md): Start from EU Green Claims Compliance Program and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Green Claims](/contact.md): Review your current process, evidence gaps, and next steps for EU Green Claims Compliance Program. ## Primary sources - [European Commission - Green claims policy overview](https://environment.ec.europa.eu/topics/circular-economy/green-claims_en?ref=sorena.io) - Policy context for environmental claims and supporting materials. - [European Commission - Questions and Answers on European Green Claims (QANDA/23/1693)](https://ec.europa.eu/commission/presscorner/detail/en/qanda_23_1693?ref=sorena.io) - Commission explanation of why substantiation and verification workflows are needed. ## Related Topic Guides - [EU Green Claims Applicability Test | Is This Environmental Claim In Scope (Product vs Company, Labels, Offsets)?](/artifacts/eu/green-claims-directive/applicability-test.md): A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim. - [EU Green Claims Checklist | Audit-Ready Checklist for Environmental Claims (Substantiation, Verification, Labels, Offsets)](/artifacts/eu/green-claims-directive/checklist.md): An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality. - [EU Green Claims FAQ | Greenwashing Questions, Offsets, Labels, Evidence Packs, and Claim Approval Workflows](/artifacts/eu/green-claims-directive/faq.md): Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims. - [EU Green Claims Timeline and Readiness Calendar | Key Policy Dates + Operational Milestones for Evidence, Verification, and Labels](/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar.md): A practical timeline and readiness calendar for green claims. - [EU Green Claims vs UK Green Claims Code | Practical Differences for Substantiation, Disclosures, Verification, and Enforcement](/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code.md): A practical comparison for teams operating in both the EU and UK. - [Green Claims Substantiation Template | Evidence Pack Structure, Life-Cycle Thinking, Data Quality, and Disclosures](/artifacts/eu/green-claims-directive/green-claims-substantiation-template.md): A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective. - [Green Claims Templates | Claim Card, Substantiation Pack, Verification Checklist, Disclosures, and Approval Logs](/artifacts/eu/green-claims-directive/templates.md): A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist. - [Greenwashing Risk Checklist | EU Green Claims | Pre-Publication Review for Ads, Packaging, Product Pages, and Corporate Claims](/artifacts/eu/green-claims-directive/greenwashing-risk-checklist.md): A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims. - [Labels and Certification Schemes | EU Green Claims | How to Govern Eco-Labels, Badges, Seals, and Scheme Evidence](/artifacts/eu/green-claims-directive/labels-and-certification-schemes.md): A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims. - [Penalties and Enforcement | EU Green Claims | How Greenwashing is Enforced, What Evidence Reduces Risk, and What to Do During Challenges](/artifacts/eu/green-claims-directive/penalties-and-enforcement.md): A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for. - [Penalties and Fines | EU Green Claims | Penalty Drivers, Aggravating Factors, and How to Reduce Exposure With Evidence](/artifacts/eu/green-claims-directive/penalties-and-fines.md): A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries. - [Requirements | EU Green Claims Directive (Proposal) | Substantiation, Verification, Labels Governance, and Disclosures](/artifacts/eu/green-claims-directive/requirements.md): An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build). - [Substantiation and Evidence Pack | EU Green Claims | How to Build Audit-Ready Evidence for Environmental Claims](/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack.md): A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation. - [Verification and Audit Readiness | EU Green Claims | Reviewer Checklist, Sampling, Evidence Logs, and Common Findings](/artifacts/eu/green-claims-directive/verification-and-audit-readiness.md): A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios. - [What Counts as a Green Claim? | EU Green Claims Directive (Proposal) | Examples, Claim Types, Boundaries, and Common Traps](/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim.md): A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/green-claims-directive/compliance --- --- title: "EU Green Claims Timeline and Readiness Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A practical timeline and readiness calendar for green claims." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU green claims timeline" - "green claims readiness calendar" - "green claims directive timeline" - "greenwashing compliance calendar" - "environmental claims verification timeline" - "substantiation evidence pack calendar" - "timeline" - "compliance calendar" - "green claims" - "verification" - "evidence packs" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Green Claims Timeline and Readiness Calendar A practical timeline and readiness calendar for green claims. *Calendar* *EU* ## EU Green Claims Timeline and Readiness Calendar Use policy context, but build operational readiness first. Focus: claim inventory, evidence packs, verification workflows, and labels governance. Green claims readiness is mostly operational: evidence packs, reviewer workflows, and labels governance. Use policy milestones for context, but run a readiness calendar that improves your program regardless of legislative status. ## Key policy milestones (context) The Green Claims Directive started as a Commission proposal in March 2023. The European Parliament adopted a first-reading position in March 2024 and the Council approved a general approach in June 2024. Status note: Parliament reported on 20 June 2025 that the Commission intended to withdraw the proposal. The proposal has not been adopted, so the practical value here is operational readiness rather than a live transposition countdown. - 2023-03-22: Commission proposal and Q&A publication. - 2024-03-12: European Parliament first-reading position (P9_TA(2024)0131). - 2024-06-17: Council general approach referenced in Parliament/EPRS material. - 2025-06-20: Parliament reported the Commission's intention to withdraw the proposal. - 2025-06-23: the scheduled trilogue was cancelled according to parliamentary reporting. *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU Green Claims Timeline and Readiness Calendar across ESG workflows ESG Compliance can take EU Green Claims Timeline and Readiness Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Green Claims can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Green Claims Timeline and Readiness Calendar](/solutions/esg-compliance.md): Start from EU Green Claims Timeline and Readiness Calendar and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Green Claims](/contact.md): Review your current process, evidence gaps, and next steps for EU Green Claims Timeline and Readiness Calendar. ## Readiness calendar (what to build in 30-90 days) Most teams can build an initial operating model quickly if they focus on the highest-leverage artifacts: claim inventory, templates, and approval logs. Sequence work by dependency: you can't verify a claim without a claim card and evidence pack structure. - Days 0-14: claim inventory + taxonomy + risk tiers + claim card template. - Days 15-45: substantiation template + evidence index + dataset governance rules. - Days 46-75: verification checklist + approval workflow + audit log storage. - Days 76-90: labels governance policy + training + sampling audit program. ## Ongoing cadence (keep claims current) Claims decay with supplier changes, product changes, and new markets. Build a recurring cadence. Treat evidence freshness as an operational KPI. - Monthly: new claims intake, Tier 1 review queue, offsets/label monitoring. - Quarterly: evidence pack refresh, supplier dataset updates, baseline updates for comparisons. - Semi-annual: sampling audit of published claims and template/process improvements. ## Primary sources - [European Commission - Questions and Answers on European Green Claims (QANDA/23/1693)](https://ec.europa.eu/commission/presscorner/detail/en/qanda_23_1693?ref=sorena.io) - Commission publication date and scope context for the proposal. - [European Parliament - First reading position (P9_TA(2024)0131)](https://www.europarl.europa.eu/doceo/document/TA-9-2024-0131_EN.html?ref=sorena.io) - Parliament milestone and text reference. - [European Parliament Think Tank - Green claims directive briefing (EPRS_BRI(2023)753958)](https://www.europarl.europa.eu/thinktank/en/document/EPRS_BRI(2023)753958?ref=sorena.io) - Procedure context and Council general approach mention. - [European Parliament - News on the Commission's withdrawal intention](https://www.europarl.europa.eu/news/en/press-room/20250620IPR29523/commission-intends-to-withdraw-greenwashing-proposal?ref=sorena.io) - Official parliamentary reporting on the Commission's announced intention to withdraw the proposal. - [European Parliament Legislative Observatory - Procedure 2023/0085(COD)](https://oeil.secure.europarl.europa.eu/oeil/popups/ficheprocedure.do?reference=2023/0085(COD)&l=en&ref=sorena.io) - Official procedure file for the legislative status of the proposal. ## Related Topic Guides - [EU Green Claims Applicability Test | Is This Environmental Claim In Scope (Product vs Company, Labels, Offsets)?](/artifacts/eu/green-claims-directive/applicability-test.md): A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim. - [EU Green Claims Checklist | Audit-Ready Checklist for Environmental Claims (Substantiation, Verification, Labels, Offsets)](/artifacts/eu/green-claims-directive/checklist.md): An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality. - [EU Green Claims Compliance Program | Operating Model for Marketing Claims: Governance, Evidence Packs, Verification, and Labels](/artifacts/eu/green-claims-directive/compliance.md): A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards. - [EU Green Claims FAQ | Greenwashing Questions, Offsets, Labels, Evidence Packs, and Claim Approval Workflows](/artifacts/eu/green-claims-directive/faq.md): Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims. - [EU Green Claims vs UK Green Claims Code | Practical Differences for Substantiation, Disclosures, Verification, and Enforcement](/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code.md): A practical comparison for teams operating in both the EU and UK. - [Green Claims Substantiation Template | Evidence Pack Structure, Life-Cycle Thinking, Data Quality, and Disclosures](/artifacts/eu/green-claims-directive/green-claims-substantiation-template.md): A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective. - [Green Claims Templates | Claim Card, Substantiation Pack, Verification Checklist, Disclosures, and Approval Logs](/artifacts/eu/green-claims-directive/templates.md): A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist. - [Greenwashing Risk Checklist | EU Green Claims | Pre-Publication Review for Ads, Packaging, Product Pages, and Corporate Claims](/artifacts/eu/green-claims-directive/greenwashing-risk-checklist.md): A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims. - [Labels and Certification Schemes | EU Green Claims | How to Govern Eco-Labels, Badges, Seals, and Scheme Evidence](/artifacts/eu/green-claims-directive/labels-and-certification-schemes.md): A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims. - [Penalties and Enforcement | EU Green Claims | How Greenwashing is Enforced, What Evidence Reduces Risk, and What to Do During Challenges](/artifacts/eu/green-claims-directive/penalties-and-enforcement.md): A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for. - [Penalties and Fines | EU Green Claims | Penalty Drivers, Aggravating Factors, and How to Reduce Exposure With Evidence](/artifacts/eu/green-claims-directive/penalties-and-fines.md): A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries. - [Requirements | EU Green Claims Directive (Proposal) | Substantiation, Verification, Labels Governance, and Disclosures](/artifacts/eu/green-claims-directive/requirements.md): An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build). - [Substantiation and Evidence Pack | EU Green Claims | How to Build Audit-Ready Evidence for Environmental Claims](/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack.md): A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation. - [Verification and Audit Readiness | EU Green Claims | Reviewer Checklist, Sampling, Evidence Logs, and Common Findings](/artifacts/eu/green-claims-directive/verification-and-audit-readiness.md): A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios. - [What Counts as a Green Claim? | EU Green Claims Directive (Proposal) | Examples, Claim Types, Boundaries, and Common Traps](/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim.md): A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar --- --- title: "EU Green Claims FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/faq" source_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/faq" author: "Sorena AI" description: "Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU green claims FAQ" - "greenwashing FAQ" - "environmental claims substantiation FAQ" - "carbon neutral claim FAQ" - "net zero claim evidence FAQ" - "offsets disclosure FAQ" - "eco label governance FAQ" - "FAQ" - "greenwashing" - "environmental claims" - "offsets" - "labels" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Green Claims FAQ Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims. *FAQ* *EU* ## EU Green Claims FAQ Answers for marketing, legal, and sustainability teams. Plus links to templates and the full claims workflow. Most green claims issues repeat: vague language, unclear boundaries, offset-heavy climate claims, and badges that imply more than they prove. These FAQs focus on implementation decisions and what evidence you need to publish and defend claims consistently. ## Scope and claim classification Start by classifying the claim. Evidence depends on whether it's product vs company, absolute vs comparative, or label-like. If you can't write a boundary statement in plain language, the claim is not ready. - What counts as a green claim? Any messaging about environmental impact/aspect/performance (explicit or implied). - Do badges and icons count? Yes-badges can create implied claims and require governance and evidence. - What's the fastest way to reduce risk? Claim cards + evidence packs + approval logs. ## Substantiation and evidence Substantiation is an evidence pack: method, data, calculations, trade-offs, and disclosures. Build an evidence index so you can export substantiation quickly when challenged. - Do we need a life-cycle view? Often, yes for broad claims-document lifecycle scope and exclusions. - How do we handle trade-offs? Explain what improved and what worsened; avoid cherry-picking. - What should we store? Claim card, datasets, calculation artifacts, reviewer checklist, approval log, disclosures. ## Offsets and climate neutrality claims Offset-based claims are high-risk because they are easily misunderstood. Separate reductions and compensation clearly. If your claim relies on offsets, treat it as a disclosure-heavy claim with extra evidence requirements. - Should we say 'carbon neutral'? Only if the boundary and reductions vs offsets are explicit and defensible. - What evidence is needed? Offset integrity criteria, retirement/cancellation records, and accounting assumptions. - What's a safer pattern? 'We reduced X and compensated Y' with a clear explanation and link to evidence. ## Legislative status changes (what should teams do?) Even when legislative status shifts, enforcement risk and consumer expectations remain. The safe strategy is to keep your internal controls stable: classify, substantiate, verify, log. Use policy updates to adjust documentation and disclosures, not to abandon the operating model. - Maintain claim inventory and evidence packs as a baseline control system. - Update templates and reviewer checklists when policy or guidance changes. - Run sampling audits of published claims and fix systemic issues. *Recommended next step* *Placement: after the FAQ section* ## Use EU Green Claims FAQ as a cited research workflow Research Copilot can take EU Green Claims FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU Green Claims can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Green Claims FAQ](/solutions/research-copilot.md): Start from EU Green Claims FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Green Claims](/contact.md): Review your current process, evidence gaps, and next steps for EU Green Claims FAQ. ## Primary sources - [European Commission - Questions and Answers on European Green Claims (QANDA/23/1693)](https://ec.europa.eu/commission/presscorner/detail/en/qanda_23_1693?ref=sorena.io) - Commission source for scope, claim examples, and substantiation/verification intent. - [European Parliament Think Tank - Green claims directive briefing (EPRS_BRI(2023)753958)](https://www.europarl.europa.eu/thinktank/en/document/EPRS_BRI(2023)753958?ref=sorena.io) - Policy and procedure context for the proposal and its focus areas. ## Related Topic Guides - [EU Green Claims Applicability Test | Is This Environmental Claim In Scope (Product vs Company, Labels, Offsets)?](/artifacts/eu/green-claims-directive/applicability-test.md): A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim. - [EU Green Claims Checklist | Audit-Ready Checklist for Environmental Claims (Substantiation, Verification, Labels, Offsets)](/artifacts/eu/green-claims-directive/checklist.md): An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality. - [EU Green Claims Compliance Program | Operating Model for Marketing Claims: Governance, Evidence Packs, Verification, and Labels](/artifacts/eu/green-claims-directive/compliance.md): A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards. - [EU Green Claims Timeline and Readiness Calendar | Key Policy Dates + Operational Milestones for Evidence, Verification, and Labels](/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar.md): A practical timeline and readiness calendar for green claims. - [EU Green Claims vs UK Green Claims Code | Practical Differences for Substantiation, Disclosures, Verification, and Enforcement](/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code.md): A practical comparison for teams operating in both the EU and UK. - [Green Claims Substantiation Template | Evidence Pack Structure, Life-Cycle Thinking, Data Quality, and Disclosures](/artifacts/eu/green-claims-directive/green-claims-substantiation-template.md): A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective. - [Green Claims Templates | Claim Card, Substantiation Pack, Verification Checklist, Disclosures, and Approval Logs](/artifacts/eu/green-claims-directive/templates.md): A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist. - [Greenwashing Risk Checklist | EU Green Claims | Pre-Publication Review for Ads, Packaging, Product Pages, and Corporate Claims](/artifacts/eu/green-claims-directive/greenwashing-risk-checklist.md): A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims. - [Labels and Certification Schemes | EU Green Claims | How to Govern Eco-Labels, Badges, Seals, and Scheme Evidence](/artifacts/eu/green-claims-directive/labels-and-certification-schemes.md): A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims. - [Penalties and Enforcement | EU Green Claims | How Greenwashing is Enforced, What Evidence Reduces Risk, and What to Do During Challenges](/artifacts/eu/green-claims-directive/penalties-and-enforcement.md): A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for. - [Penalties and Fines | EU Green Claims | Penalty Drivers, Aggravating Factors, and How to Reduce Exposure With Evidence](/artifacts/eu/green-claims-directive/penalties-and-fines.md): A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries. - [Requirements | EU Green Claims Directive (Proposal) | Substantiation, Verification, Labels Governance, and Disclosures](/artifacts/eu/green-claims-directive/requirements.md): An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build). - [Substantiation and Evidence Pack | EU Green Claims | How to Build Audit-Ready Evidence for Environmental Claims](/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack.md): A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation. - [Verification and Audit Readiness | EU Green Claims | Reviewer Checklist, Sampling, Evidence Logs, and Common Findings](/artifacts/eu/green-claims-directive/verification-and-audit-readiness.md): A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios. - [What Counts as a Green Claim? | EU Green Claims Directive (Proposal) | Examples, Claim Types, Boundaries, and Common Traps](/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim.md): A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/green-claims-directive/faq --- --- title: "EU Green Claims vs UK Green Claims Code" canonical_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code" source_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code" author: "Sorena AI" description: "A practical comparison for teams operating in both the EU and UK." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU green claims vs UK green claims code" - "CMA green claims code comparison" - "greenwashing UK EU differences" - "environmental claims substantiation UK EU" - "carbon neutral claims UK EU" - "offsets disclosure UK EU" - "comparison" - "UK Green Claims Code" - "CMA" - "greenwashing" - "substantiation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Green Claims vs UK Green Claims Code A practical comparison for teams operating in both the EU and UK. *Comparison* *EU / UK* ## EU vs UK Green Claims A comparison designed for implementation teams (not just legal summaries). Focus: substantiation, disclosures, offsets, labels, and evidence you can reuse. Teams operating across the EU and UK should avoid two separate claims programs. Build one claims operating model (claim cards, evidence packs, verification checklists, approval logs), then create two jurisdictional 'views' for wording, disclosure emphasis, and enforcement posture. ## Shared foundation (works in both EU and UK) The core operational controls are the same: define the claim precisely, set boundaries, substantiate with credible evidence, and log approvals. These controls reduce risk regardless of how specific legislation evolves. - Claim taxonomy + claim cards with boundaries and versions. - Evidence packs (datasets, calculations, trade-offs, uncertainty). - Verification checklist + approval logs + retention policy. ## Where teams usually diverge (and should parameterize) Differences are often in enforcement and guidance emphasis: how claims are interpreted, how offsets are treated in messaging, and expectations around label governance and consumer clarity. Operational outcome: keep one evidence pack, but tailor the disclosure layer. - Offsets and 'carbon neutral/net zero': keep reduction vs compensation separation clear in both regimes. - Comparatives: baseline and comparability statements should be explicit and stored with the pack. - Badges/labels: scheme due diligence and evidence packs reduce implied-claim risk. ## Build one workflow engine, two outputs (EU/UK views) A mature approach separates controls from outputs: controls are stable, outputs are parameterized. This lets marketing move fast while keeping reviewers confident. - One intake form: generates claim card + required templates by claim type. - One evidence pack store: links to datasets and calculations. - Two disclosure renderers: EU view and UK view (wording, disclaimers, and references). *Recommended next step* *Placement: after the comparison section* ## Use EU vs UK Green Claims as a cited research workflow Research Copilot can take EU vs UK Green Claims from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU vs UK can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU vs UK Green Claims](/solutions/research-copilot.md): Start from EU vs UK Green Claims and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU vs UK](/contact.md): Review your current process, evidence gaps, and next steps for EU vs UK Green Claims. ## Primary sources - [European Commission - Questions and Answers on European Green Claims (QANDA/23/1693)](https://ec.europa.eu/commission/presscorner/detail/en/qanda_23_1693?ref=sorena.io) - EU proposal context and claim examples, including offsets scrutiny and label scheme concerns. - [UK Competition and Markets Authority (CMA) - Green Claims Code (official guidance page)](https://www.gov.uk/government/publications/green-claims-code-making-environmental-claims?ref=sorena.io) - Official UK guidance for making environmental claims and avoiding misleading messaging. ## Related Topic Guides - [EU Green Claims Applicability Test | Is This Environmental Claim In Scope (Product vs Company, Labels, Offsets)?](/artifacts/eu/green-claims-directive/applicability-test.md): A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim. - [EU Green Claims Checklist | Audit-Ready Checklist for Environmental Claims (Substantiation, Verification, Labels, Offsets)](/artifacts/eu/green-claims-directive/checklist.md): An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality. - [EU Green Claims Compliance Program | Operating Model for Marketing Claims: Governance, Evidence Packs, Verification, and Labels](/artifacts/eu/green-claims-directive/compliance.md): A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards. - [EU Green Claims FAQ | Greenwashing Questions, Offsets, Labels, Evidence Packs, and Claim Approval Workflows](/artifacts/eu/green-claims-directive/faq.md): Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims. - [EU Green Claims Timeline and Readiness Calendar | Key Policy Dates + Operational Milestones for Evidence, Verification, and Labels](/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar.md): A practical timeline and readiness calendar for green claims. - [Green Claims Substantiation Template | Evidence Pack Structure, Life-Cycle Thinking, Data Quality, and Disclosures](/artifacts/eu/green-claims-directive/green-claims-substantiation-template.md): A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective. - [Green Claims Templates | Claim Card, Substantiation Pack, Verification Checklist, Disclosures, and Approval Logs](/artifacts/eu/green-claims-directive/templates.md): A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist. - [Greenwashing Risk Checklist | EU Green Claims | Pre-Publication Review for Ads, Packaging, Product Pages, and Corporate Claims](/artifacts/eu/green-claims-directive/greenwashing-risk-checklist.md): A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims. - [Labels and Certification Schemes | EU Green Claims | How to Govern Eco-Labels, Badges, Seals, and Scheme Evidence](/artifacts/eu/green-claims-directive/labels-and-certification-schemes.md): A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims. - [Penalties and Enforcement | EU Green Claims | How Greenwashing is Enforced, What Evidence Reduces Risk, and What to Do During Challenges](/artifacts/eu/green-claims-directive/penalties-and-enforcement.md): A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for. - [Penalties and Fines | EU Green Claims | Penalty Drivers, Aggravating Factors, and How to Reduce Exposure With Evidence](/artifacts/eu/green-claims-directive/penalties-and-fines.md): A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries. - [Requirements | EU Green Claims Directive (Proposal) | Substantiation, Verification, Labels Governance, and Disclosures](/artifacts/eu/green-claims-directive/requirements.md): An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build). - [Substantiation and Evidence Pack | EU Green Claims | How to Build Audit-Ready Evidence for Environmental Claims](/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack.md): A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation. - [Verification and Audit Readiness | EU Green Claims | Reviewer Checklist, Sampling, Evidence Logs, and Common Findings](/artifacts/eu/green-claims-directive/verification-and-audit-readiness.md): A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios. - [What Counts as a Green Claim? | EU Green Claims Directive (Proposal) | Examples, Claim Types, Boundaries, and Common Traps](/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim.md): A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code --- --- title: "Green Claims Substantiation Template" canonical_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/green-claims-substantiation-template" source_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/green-claims-substantiation-template" author: "Sorena AI" description: "A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "green claims substantiation template" - "environmental claims evidence pack template" - "greenwashing substantiation template" - "product environmental footprint PEF template" - "sustainability claim evidence template" - "carbon neutral claim evidence template" - "template" - "substantiation" - "evidence pack" - "PEF" - "verification" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Green Claims Substantiation Template A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective. *Template* *EU* ## EU Green Claims Substantiation Template A structured template that turns claim language into an evidence pack. Outcome: reviewers can validate scope, methods, data quality, and disclosures fast. The fastest way to lose a green claims challenge is a scattered substantiation file: some PDFs, a few spreadsheets, and no boundary statement. This template structures substantiation so it can be verified, repeated, and exported during audits and disputes. ## Section A - Claim card (the claim as an object) Write the claim card first. Reviewers cannot validate evidence if they don't know what the claim means and where it appears. Treat the claim card as versioned: each campaign variant should map to a claim version. - Claim text (all variants) + channels + intended audience. - Claim type: product vs company; absolute vs comparative; label-like claim; offset-based claim. - Scope: geography, timeframe, product variants/SKUs, functional unit. ## Section B - Boundary statement (life-cycle and exclusions) Boundaries are where most greenwashing disputes happen. State what is included and excluded, and why. If the claim is comparative, define baseline boundary and ensure comparability. - Life-cycle stages included (materials, production, transport, use, end-of-life). - Materiality: which impact categories are considered and why. - Exclusions: what is excluded, materiality justification, and residual risk. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Green Claims Substantiation Template in one governed evidence system SSOT can take EU Green Claims Substantiation Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Green Claims can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Green Claims Substantiation Template](/solutions/ssot.md): Start from EU Green Claims Substantiation Template and keep documents, evidence, and control records in one governed system. - [Talk through EU Green Claims](/contact.md): Review your current process, evidence gaps, and next steps for EU Green Claims Substantiation Template. ## Section C - Methodology and datasets (how results are produced) Pick a method appropriate to the claim. For claims tied to life-cycle performance, PEF/OEF can provide a robust reference approach. Document datasets, assumptions, and data quality requirements. 'We used industry averages' is not a method. - Method chosen (e.g., Environmental Footprint/PEF where relevant) + rationale. - Dataset inventory: primary vs secondary data; sources; representativeness; versioning. - Data quality: completeness, temporal/geographic relevance, uncertainty handling. ## Section D - Calculations and results (and how you avoid cherry-picking) Provide calculation artifacts that can be replayed: spreadsheets with locked inputs, scripts, or model exports, plus a narrative summary. Address trade-offs: improvements in one category can be offset by worsening in another. - Results summary with units, baselines, and comparators (if any). - Trade-off section: what improved, what worsened, and how you communicate that. - Sensitivity/uncertainty: key assumptions and their impact on outcomes. ## Section E - Disclosures (consumer-facing clarity) A claim is not complete until you define what consumers must be told for the claim to be non-misleading. Write disclosure text that can be reused across product pages and ads. - Plain-language boundary statement (one paragraph). - Comparative disclosures: baseline definition and comparability statement. - Offset disclosures (if used): reductions vs compensation and evidence references. ## Section F - Verification checklist + approval log Verification is about repeatability and auditability. Create a checklist and log who reviewed what and when. Store the final pack and approval record in a system with retention and access controls. - Verification checklist completed (methods, datasets, boundaries, trade-offs, disclosures). - Approval log: reviewer roles, timestamps, decision outcomes, and follow-up tasks. - Retention: evidence pack location, version history, and access rules. ## Primary sources - [European Commission - Questions and Answers on European Green Claims (QANDA/23/1693)](https://ec.europa.eu/commission/presscorner/detail/en/qanda_23_1693?ref=sorena.io) - Official Commission context on substantiation and ex ante verification intent. - [JRC Environmental Footprint (PEF/OEF) - Commission Recommendation 2021/2279 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32021H2279&ref=sorena.io) - EU-recommended life-cycle based measurement approach often referenced for substantiation method design. ## Related Topic Guides - [EU Green Claims Applicability Test | Is This Environmental Claim In Scope (Product vs Company, Labels, Offsets)?](/artifacts/eu/green-claims-directive/applicability-test.md): A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim. - [EU Green Claims Checklist | Audit-Ready Checklist for Environmental Claims (Substantiation, Verification, Labels, Offsets)](/artifacts/eu/green-claims-directive/checklist.md): An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality. - [EU Green Claims Compliance Program | Operating Model for Marketing Claims: Governance, Evidence Packs, Verification, and Labels](/artifacts/eu/green-claims-directive/compliance.md): A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards. - [EU Green Claims FAQ | Greenwashing Questions, Offsets, Labels, Evidence Packs, and Claim Approval Workflows](/artifacts/eu/green-claims-directive/faq.md): Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims. - [EU Green Claims Timeline and Readiness Calendar | Key Policy Dates + Operational Milestones for Evidence, Verification, and Labels](/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar.md): A practical timeline and readiness calendar for green claims. - [EU Green Claims vs UK Green Claims Code | Practical Differences for Substantiation, Disclosures, Verification, and Enforcement](/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code.md): A practical comparison for teams operating in both the EU and UK. - [Green Claims Templates | Claim Card, Substantiation Pack, Verification Checklist, Disclosures, and Approval Logs](/artifacts/eu/green-claims-directive/templates.md): A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist. - [Greenwashing Risk Checklist | EU Green Claims | Pre-Publication Review for Ads, Packaging, Product Pages, and Corporate Claims](/artifacts/eu/green-claims-directive/greenwashing-risk-checklist.md): A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims. - [Labels and Certification Schemes | EU Green Claims | How to Govern Eco-Labels, Badges, Seals, and Scheme Evidence](/artifacts/eu/green-claims-directive/labels-and-certification-schemes.md): A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims. - [Penalties and Enforcement | EU Green Claims | How Greenwashing is Enforced, What Evidence Reduces Risk, and What to Do During Challenges](/artifacts/eu/green-claims-directive/penalties-and-enforcement.md): A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for. - [Penalties and Fines | EU Green Claims | Penalty Drivers, Aggravating Factors, and How to Reduce Exposure With Evidence](/artifacts/eu/green-claims-directive/penalties-and-fines.md): A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries. - [Requirements | EU Green Claims Directive (Proposal) | Substantiation, Verification, Labels Governance, and Disclosures](/artifacts/eu/green-claims-directive/requirements.md): An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build). - [Substantiation and Evidence Pack | EU Green Claims | How to Build Audit-Ready Evidence for Environmental Claims](/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack.md): A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation. - [Verification and Audit Readiness | EU Green Claims | Reviewer Checklist, Sampling, Evidence Logs, and Common Findings](/artifacts/eu/green-claims-directive/verification-and-audit-readiness.md): A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios. - [What Counts as a Green Claim? | EU Green Claims Directive (Proposal) | Examples, Claim Types, Boundaries, and Common Traps](/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim.md): A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/green-claims-directive/green-claims-substantiation-template --- --- title: "Greenwashing Risk Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/greenwashing-risk-checklist" source_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/greenwashing-risk-checklist" author: "Sorena AI" description: "A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "greenwashing risk checklist" - "environmental claims checklist" - "green claims approval checklist" - "carbon neutral claim checklist" - "net zero claim checklist" - "sustainability marketing compliance checklist" - "greenwashing red flags" - "greenwashing" - "checklist" - "environmental claims" - "marketing compliance" - "substantiation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Greenwashing Risk Checklist A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims. *Checklist* *EU* ## EU Green Claims Greenwashing Risk Checklist A pre-publication checklist for claims, labels, and sustainability messaging. Outcome: reduce enforcement risk, improve consumer clarity, and standardize approvals. Greenwashing failures are usually predictable: vague language, undefined boundaries, hidden trade-offs, and offset-heavy climate claims presented as absolute outcomes. Use this checklist as a gate in your marketing workflow-if any red flag hits, the claim should be revised, escalated, or blocked until evidence and disclosures are fixed. ## 1) Clarity and meaning (vagueness is the #1 risk) If a consumer can't tell what the claim means, you can't substantiate it. Define the claim as a structured object: text -> type -> boundary -> evidence. Ban undefined words in high-reach campaigns unless they are immediately quantified and scoped. - Is the claim specific and measurable (not just 'eco-friendly', 'green', 'sustainable')? - Does it say what aspect is improved (materials, durability, emissions, water, packaging, biodiversity)? - Is it product-level or company-level (and is that distinction clear)? ## 2) Boundaries and trade-offs (what's included/excluded) Most disputes are boundary disputes. If you don't state the boundary, reviewers assume you're implying more than you can prove. Trade-offs must be handled explicitly: improvement in one impact category doesn't automatically mean overall better. - Life-cycle boundary is documented (raw materials -> production -> use -> end-of-life). - Geographic and temporal scope are stated (which markets, which timeframe, which model variants). - Trade-offs are disclosed (what improved, what worsened, what was not measured). ## 3) Comparative claims (baseline and comparability) Comparative claims need a baseline and a like-for-like methodology. Without it, comparisons are easy targets. Keep the baseline artifacts: prior model definitions, datasets, and change rationale. - Baseline and comparator are defined and relevant (same functional unit / comparable product use). - Methods and datasets are consistent across baseline and new claim. - Results are not cherry-picked (no selective impact categories). ## 4) Offset-based climate claims (auto-escalate) Offset-based claims are frequently challenged because they conflate reductions and compensation. Treat them as high-risk claims requiring extra disclosure and stronger evidence. If the claim relies on offsets/credits, separate what was reduced vs what was offset and retain accounting evidence. - Claim language separates reductions vs compensation (no 'neutral' implied without clarity). - Offset evidence exists: project type, integrity criteria, retirement/cancellation records, assumptions. - Value-chain boundary is stated (operations vs upstream/downstream). ## 5) Labels and schemes (badge governance) Badges and seals create implied claims. They must be governed like claims: transparent criteria, controls, and enforcement rules. If you reference third-party labels, keep scheme rules and proof of eligibility current. - Label criteria and eligibility evidence are stored and versioned. - Scheme governance is reviewed (who runs it, how non-compliance is handled). - Internal policy exists for creating new labels/badges (avoid 'label proliferation'). ## 6) Evidence and approvals (audit-ready) A claim that can't be exported as evidence is not ready. Build an evidence pack and approval log for each high-impact claim. Define acceptance criteria: what minimum artifacts must exist before publication. - Claim card exists: claim text, type, boundary, channels, owner, version history. - Substantiation pack exists and links to datasets, methods, and calculations. - Verification checklist completed + approval log exists (who approved, when, and why). *Recommended next step* *Placement: after the checklist block* ## Operationalize EU Green Claims Greenwashing Risk Checklist across ESG workflows ESG Compliance can take EU Green Claims Greenwashing Risk Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Green Claims can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Green Claims Greenwashing Risk Checklist](/solutions/esg-compliance.md): Start from EU Green Claims Greenwashing Risk Checklist and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Green Claims](/contact.md): Review your current process, evidence gaps, and next steps for EU Green Claims Greenwashing Risk Checklist. ## Primary sources - [European Commission - Questions and Answers on European Green Claims (QANDA/23/1693)](https://ec.europa.eu/commission/presscorner/detail/en/qanda_23_1693?ref=sorena.io) - Official Commission source for greenwashing statistics, scope intent, and emphasis on substantiation and ex ante verification. - [European Parliament Think Tank - Green claims directive briefing (EPRS_BRI(2023)753958)](https://www.europarl.europa.eu/thinktank/en/document/EPRS_BRI(2023)753958?ref=sorena.io) - Policy briefing summarizing the proposal and key risk areas for environmental claims. ## Related Topic Guides - [EU Green Claims Applicability Test | Is This Environmental Claim In Scope (Product vs Company, Labels, Offsets)?](/artifacts/eu/green-claims-directive/applicability-test.md): A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim. - [EU Green Claims Checklist | Audit-Ready Checklist for Environmental Claims (Substantiation, Verification, Labels, Offsets)](/artifacts/eu/green-claims-directive/checklist.md): An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality. - [EU Green Claims Compliance Program | Operating Model for Marketing Claims: Governance, Evidence Packs, Verification, and Labels](/artifacts/eu/green-claims-directive/compliance.md): A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards. - [EU Green Claims FAQ | Greenwashing Questions, Offsets, Labels, Evidence Packs, and Claim Approval Workflows](/artifacts/eu/green-claims-directive/faq.md): Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims. - [EU Green Claims Timeline and Readiness Calendar | Key Policy Dates + Operational Milestones for Evidence, Verification, and Labels](/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar.md): A practical timeline and readiness calendar for green claims. - [EU Green Claims vs UK Green Claims Code | Practical Differences for Substantiation, Disclosures, Verification, and Enforcement](/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code.md): A practical comparison for teams operating in both the EU and UK. - [Green Claims Substantiation Template | Evidence Pack Structure, Life-Cycle Thinking, Data Quality, and Disclosures](/artifacts/eu/green-claims-directive/green-claims-substantiation-template.md): A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective. - [Green Claims Templates | Claim Card, Substantiation Pack, Verification Checklist, Disclosures, and Approval Logs](/artifacts/eu/green-claims-directive/templates.md): A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist. - [Labels and Certification Schemes | EU Green Claims | How to Govern Eco-Labels, Badges, Seals, and Scheme Evidence](/artifacts/eu/green-claims-directive/labels-and-certification-schemes.md): A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims. - [Penalties and Enforcement | EU Green Claims | How Greenwashing is Enforced, What Evidence Reduces Risk, and What to Do During Challenges](/artifacts/eu/green-claims-directive/penalties-and-enforcement.md): A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for. - [Penalties and Fines | EU Green Claims | Penalty Drivers, Aggravating Factors, and How to Reduce Exposure With Evidence](/artifacts/eu/green-claims-directive/penalties-and-fines.md): A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries. - [Requirements | EU Green Claims Directive (Proposal) | Substantiation, Verification, Labels Governance, and Disclosures](/artifacts/eu/green-claims-directive/requirements.md): An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build). - [Substantiation and Evidence Pack | EU Green Claims | How to Build Audit-Ready Evidence for Environmental Claims](/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack.md): A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation. - [Verification and Audit Readiness | EU Green Claims | Reviewer Checklist, Sampling, Evidence Logs, and Common Findings](/artifacts/eu/green-claims-directive/verification-and-audit-readiness.md): A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios. - [What Counts as a Green Claim? | EU Green Claims Directive (Proposal) | Examples, Claim Types, Boundaries, and Common Traps](/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim.md): A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/green-claims-directive/greenwashing-risk-checklist --- --- title: "Labels and Certification Schemes" canonical_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/labels-and-certification-schemes" source_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/labels-and-certification-schemes" author: "Sorena AI" description: "A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "eco labels governance" - "environmental labels compliance" - "certification scheme evidence" - "EU Ecolabel criteria" - "green labels credibility" - "label proliferation greenwashing" - "sustainability badges compliance" - "eco-labels" - "certification" - "labels governance" - "greenwashing" - "marketing compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Labels and Certification Schemes A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims. *Labels* *EU* ## EU Green Claims Labels and Certification Schemes Badges and seals are claims. Govern them like claims. Outcome: transparent criteria, credible verification, and audit-ready scheme evidence. Labels are high-risk because they compress complex criteria into a badge that consumers interpret as a broad environmental guarantee. A mature program treats labels and certification schemes as governed assets: eligibility evidence, criteria transparency, audit records, and non-compliance handling-plus a policy to avoid creating internal 'fake labels'. ## Why labels increase greenwashing risk (even when intentions are good) A label can create implied claims far broader than your evidence. Consumers often read a badge as 'overall sustainable', even if it only covers one attribute. Operational outcome: define what the label means, what it does not mean, and what evidence supports it. - Badges imply scope; define and disclose actual scope. - Third-party labels still require your internal due diligence and evidence storage. - Internal labels require the strongest governance (avoid uncontrolled proliferation). ## Scheme due diligence checklist (before you use a label) Evaluate a label scheme like a supplier: governance, criteria, verification, and enforcement posture. If you can't explain scheme criteria and verification, don't put the badge in front of consumers. - Criteria transparency: publicly available criteria and version history. - Verification: independent review, audit approach, and frequency. - Non-compliance handling: suspension/withdrawal rules and enforcement track record. - Conflicts of interest: who funds the scheme and how governance works. - Check whether the scheme is already covered by a specific EU regime, such as the EU Ecolabel, instead of treating it as a free-form marketing badge. ## Evidence to retain (label evidence pack) Create a label evidence pack that can be exported during disputes: eligibility proof, audit reports, and scheme criteria version used. Link label evidence packs to the specific products/SKUs and claims where the label appears. - Eligibility evidence: certificates, audit reports, and criteria mapping. - Scope statement: what the label covers and what it does not cover. - Usage log: where the label appears (channels), approval record, and review cadence. ## Prevent label proliferation (the governance policy you need) Proliferation of labels (internal and external) is a core consumer confusion driver and increases enforcement risk. Create a policy: when labels are allowed, who approves them, and what evidence is required. - Single owner: labels governance role (marketing + sustainability + legal). - Standard label requirements: criteria transparency, verification approach, and non-compliance handling. - Decommissioning: how to retire labels and update materials and product pages. - Treat aggregate scoring labels as a special-risk category because the Commission proposal and Parliament text both pushed hard against broad composite environmental scores unless they are grounded in EU rules. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU Green Claims Labels and Certification Schemes across ESG workflows ESG Compliance can take EU Green Claims Labels and Certification Schemes from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU Green Claims can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Green Claims Labels and Certification Schemes](/solutions/esg-compliance.md): Start from EU Green Claims Labels and Certification Schemes and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Green Claims](/contact.md): Review your current process, evidence gaps, and next steps for EU Green Claims Labels and Certification Schemes. ## Primary sources - [European Commission - EU Ecolabel (official page)](https://environment.ec.europa.eu/topics/circular-economy/eu-ecolabel_en?ref=sorena.io) - Official EU Ecolabel page describing criteria-based environmental excellence labeling and governance context, including current scale and SME participation. - [European Commission - Questions and Answers on European Green Claims (QANDA/23/1693)](https://ec.europa.eu/commission/presscorner/detail/en/qanda_23_1693?ref=sorena.io) - Commission explanation includes label scheme proliferation concerns and governance direction. ## Related Topic Guides - [EU Green Claims Applicability Test | Is This Environmental Claim In Scope (Product vs Company, Labels, Offsets)?](/artifacts/eu/green-claims-directive/applicability-test.md): A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim. - [EU Green Claims Checklist | Audit-Ready Checklist for Environmental Claims (Substantiation, Verification, Labels, Offsets)](/artifacts/eu/green-claims-directive/checklist.md): An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality. - [EU Green Claims Compliance Program | Operating Model for Marketing Claims: Governance, Evidence Packs, Verification, and Labels](/artifacts/eu/green-claims-directive/compliance.md): A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards. - [EU Green Claims FAQ | Greenwashing Questions, Offsets, Labels, Evidence Packs, and Claim Approval Workflows](/artifacts/eu/green-claims-directive/faq.md): Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims. - [EU Green Claims Timeline and Readiness Calendar | Key Policy Dates + Operational Milestones for Evidence, Verification, and Labels](/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar.md): A practical timeline and readiness calendar for green claims. - [EU Green Claims vs UK Green Claims Code | Practical Differences for Substantiation, Disclosures, Verification, and Enforcement](/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code.md): A practical comparison for teams operating in both the EU and UK. - [Green Claims Substantiation Template | Evidence Pack Structure, Life-Cycle Thinking, Data Quality, and Disclosures](/artifacts/eu/green-claims-directive/green-claims-substantiation-template.md): A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective. - [Green Claims Templates | Claim Card, Substantiation Pack, Verification Checklist, Disclosures, and Approval Logs](/artifacts/eu/green-claims-directive/templates.md): A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist. - [Greenwashing Risk Checklist | EU Green Claims | Pre-Publication Review for Ads, Packaging, Product Pages, and Corporate Claims](/artifacts/eu/green-claims-directive/greenwashing-risk-checklist.md): A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims. - [Penalties and Enforcement | EU Green Claims | How Greenwashing is Enforced, What Evidence Reduces Risk, and What to Do During Challenges](/artifacts/eu/green-claims-directive/penalties-and-enforcement.md): A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for. - [Penalties and Fines | EU Green Claims | Penalty Drivers, Aggravating Factors, and How to Reduce Exposure With Evidence](/artifacts/eu/green-claims-directive/penalties-and-fines.md): A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries. - [Requirements | EU Green Claims Directive (Proposal) | Substantiation, Verification, Labels Governance, and Disclosures](/artifacts/eu/green-claims-directive/requirements.md): An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build). - [Substantiation and Evidence Pack | EU Green Claims | How to Build Audit-Ready Evidence for Environmental Claims](/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack.md): A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation. - [Verification and Audit Readiness | EU Green Claims | Reviewer Checklist, Sampling, Evidence Logs, and Common Findings](/artifacts/eu/green-claims-directive/verification-and-audit-readiness.md): A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios. - [What Counts as a Green Claim? | EU Green Claims Directive (Proposal) | Examples, Claim Types, Boundaries, and Common Traps](/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim.md): A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/green-claims-directive/labels-and-certification-schemes --- --- title: "Penalties and Enforcement" canonical_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/penalties-and-enforcement" source_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/penalties-and-enforcement" author: "Sorena AI" description: "A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "green claims enforcement" - "greenwashing enforcement EU" - "environmental claims penalties" - "greenwashing investigation response" - "claim substantiation evidence for regulators" - "green claims compliance enforcement" - "enforcement" - "penalties" - "greenwashing" - "response playbook" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Penalties and Enforcement A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for. *Enforcement* *EU* ## EU Green Claims Penalties and Enforcement Enforcement is driven by evidence quality, clarity, and response speed. Focus: response playbook and the artifacts that reduce escalation risk. Greenwashing enforcement often starts as a challenge: consumer complaint, competitor complaint, NGO scrutiny, platform review, or authority inquiry. The teams that perform best can export an evidence pack quickly, explain claim boundaries in plain language, and show a logged approval process with defined acceptance criteria. ## How enforcement typically unfolds (practical sequence) Most enforcement situations follow a similar pattern: a claim is questioned, the organization must explain meaning and evidence, and then revise or defend the claim based on documentation. Your goal is to compress time-to-evidence and reduce ambiguity. - Signal intake: complaint, inquiry, platform flag, media scrutiny. - Triage: classify claim type and risk tier; decide whether to pause the claim. - Evidence export: claim card + boundary statement + substantiation pack + approval log. - Outcome: revise, remove, or defend with clarifying disclosures and evidence. *Recommended next step* *Placement: after the enforcement section* ## Use EU Green Claims Penalties and Enforcement as a cited research workflow Research Copilot can take EU Green Claims Penalties and Enforcement from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Green Claims can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Green Claims Penalties and Enforcement](/solutions/research-copilot.md): Start from EU Green Claims Penalties and Enforcement and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Green Claims](/contact.md): Review your current process, evidence gaps, and next steps for EU Green Claims Penalties and Enforcement. ## What reviewers and authorities ask for (the evidence-first view) The fastest way to fail is to answer with marketing language instead of evidence. Prepare a standard response bundle. Many questions are about boundaries and comparability, not about calculation mechanics. - What does the claim mean (product vs company, absolute vs comparative)? - What is the boundary (life-cycle stage, variants, geography, timeframe)? - What method and data supports it (datasets, quality criteria, assumptions)? - What trade-offs exist and how were they communicated? - Who approved it and what checks were performed (logs)? ## Controls that reduce escalation and penalty risk A defensible program reduces both enforcement and reputational risk. The best controls are those that prevent ambiguous claims and create exportable evidence. Make these controls measurable and repeatable. - Claim taxonomy + claim cards for every high-impact claim version. - Evidence pack templates + dataset governance + reproducible calculations. - Verification checklist + approval logs + retention policy. - Sampling audits of published claims and systematic remediation. ## Response playbook (when a claim is challenged) Treat challenges like incidents: one owner, one timeline, one evidence bundle, one decision log. Avoid ad-hoc messaging; use the disclosure layer aligned to the evidence pack. - Assign an incident owner and a cross-functional triage group (marketing, sustainability, legal). - Pause or limit the claim if evidence is incomplete (reduce ongoing exposure). - Export the evidence pack and produce a plain-language boundary statement. - Decide: revise claim wording, add disclosures, or remove claim and update assets. ## Primary sources - [European Commission - Questions and Answers on European Green Claims (QANDA/23/1693)](https://ec.europa.eu/commission/presscorner/detail/en/qanda_23_1693?ref=sorena.io) - Commission context on the problem of vague and unsubstantiated claims and the intent for substantiation and verification. - [European Commission - Green claims policy overview](https://environment.ec.europa.eu/topics/circular-economy/green-claims_en?ref=sorena.io) - Policy context and supporting materials for environmental claims. ## Related Topic Guides - [EU Green Claims Applicability Test | Is This Environmental Claim In Scope (Product vs Company, Labels, Offsets)?](/artifacts/eu/green-claims-directive/applicability-test.md): A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim. - [EU Green Claims Checklist | Audit-Ready Checklist for Environmental Claims (Substantiation, Verification, Labels, Offsets)](/artifacts/eu/green-claims-directive/checklist.md): An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality. - [EU Green Claims Compliance Program | Operating Model for Marketing Claims: Governance, Evidence Packs, Verification, and Labels](/artifacts/eu/green-claims-directive/compliance.md): A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards. - [EU Green Claims FAQ | Greenwashing Questions, Offsets, Labels, Evidence Packs, and Claim Approval Workflows](/artifacts/eu/green-claims-directive/faq.md): Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims. - [EU Green Claims Timeline and Readiness Calendar | Key Policy Dates + Operational Milestones for Evidence, Verification, and Labels](/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar.md): A practical timeline and readiness calendar for green claims. - [EU Green Claims vs UK Green Claims Code | Practical Differences for Substantiation, Disclosures, Verification, and Enforcement](/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code.md): A practical comparison for teams operating in both the EU and UK. - [Green Claims Substantiation Template | Evidence Pack Structure, Life-Cycle Thinking, Data Quality, and Disclosures](/artifacts/eu/green-claims-directive/green-claims-substantiation-template.md): A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective. - [Green Claims Templates | Claim Card, Substantiation Pack, Verification Checklist, Disclosures, and Approval Logs](/artifacts/eu/green-claims-directive/templates.md): A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist. - [Greenwashing Risk Checklist | EU Green Claims | Pre-Publication Review for Ads, Packaging, Product Pages, and Corporate Claims](/artifacts/eu/green-claims-directive/greenwashing-risk-checklist.md): A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims. - [Labels and Certification Schemes | EU Green Claims | How to Govern Eco-Labels, Badges, Seals, and Scheme Evidence](/artifacts/eu/green-claims-directive/labels-and-certification-schemes.md): A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims. - [Penalties and Fines | EU Green Claims | Penalty Drivers, Aggravating Factors, and How to Reduce Exposure With Evidence](/artifacts/eu/green-claims-directive/penalties-and-fines.md): A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries. - [Requirements | EU Green Claims Directive (Proposal) | Substantiation, Verification, Labels Governance, and Disclosures](/artifacts/eu/green-claims-directive/requirements.md): An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build). - [Substantiation and Evidence Pack | EU Green Claims | How to Build Audit-Ready Evidence for Environmental Claims](/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack.md): A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation. - [Verification and Audit Readiness | EU Green Claims | Reviewer Checklist, Sampling, Evidence Logs, and Common Findings](/artifacts/eu/green-claims-directive/verification-and-audit-readiness.md): A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios. - [What Counts as a Green Claim? | EU Green Claims Directive (Proposal) | Examples, Claim Types, Boundaries, and Common Traps](/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim.md): A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/green-claims-directive/penalties-and-enforcement --- --- title: "Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/penalties-and-fines" author: "Sorena AI" description: "A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "green claims penalties" - "greenwashing fines EU" - "environmental claims fines" - "sustainability marketing penalties" - "carbon neutral claim penalties" - "green label penalties" - "greenwashing risk management" - "penalties" - "fines" - "greenwashing" - "risk management" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Penalties and Fines A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries. *Risk* *EU* ## EU Green Claims Penalties and Fines Penalty exposure is driven by ambiguity and missing evidence. Focus: what increases risk and what controls reduce it. Penalty risk in greenwashing enforcement is usually a function of three things: claim reach (how many consumers saw it), claim ambiguity (how broadly it can be interpreted), and evidence weakness (how hard it is to prove). The best risk reduction strategy is a stable control system: claim cards, evidence packs, verification checklists, and logged approvals. ## Penalty drivers (what creates exposure) Most exposure comes from claims that are broad but weakly defined: consumers interpret them as overall environmental benefit while evidence only covers a narrow attribute. Offset-based neutrality claims and label-like messaging are frequent high-risk areas. - Vague terms ('eco-friendly', 'sustainable') without quantified scope and boundaries. - Absolute claims without clear boundary and method ('carbon neutral', 'zero emissions'). - Comparative claims without baseline and comparability statement. - Badges/seals implying certification or scheme criteria that you can't prove. ## Aggravating factors (what makes enforcement harder) Aggravating factors usually reflect poor governance: no logs, no owners, inconsistent messaging across channels, and slow remediation. Treat these as control failures you can fix. - No claim inventory and no version control (can't tell what was published when). - No evidence pack or evidence scattered across teams and vendors. - No verification checklist or approval log (decisions are untraceable). - Slow corrective action (claims remain live during challenges). *Recommended next step* *Placement: after the enforcement section* ## Use EU Green Claims Penalties and Fines as a cited research workflow Research Copilot can take EU Green Claims Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Green Claims can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Green Claims Penalties and Fines](/solutions/research-copilot.md): Start from EU Green Claims Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Green Claims](/contact.md): Review your current process, evidence gaps, and next steps for EU Green Claims Penalties and Fines. ## Risk reduction controls (the evidence-led posture) You reduce penalty risk by reducing ambiguity and increasing proof. Build controls that make evidence exportable and decisions explainable. Make risk reduction measurable (KPIs). - Claim cards + boundary statements + disclosure components. - Evidence packs with reproducible calculations and dataset governance. - Verification checklist + approval logs + retention policy. - KPIs: time-to-evidence, time-to-remediation, sampling audit findings. ## Primary sources - [European Commission - Questions and Answers on European Green Claims (QANDA/23/1693)](https://ec.europa.eu/commission/presscorner/detail/en/qanda_23_1693?ref=sorena.io) - Commission source describing why unsubstantiated and vague claims are a core consumer protection problem and the intended control approach. ## Related Topic Guides - [EU Green Claims Applicability Test | Is This Environmental Claim In Scope (Product vs Company, Labels, Offsets)?](/artifacts/eu/green-claims-directive/applicability-test.md): A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim. - [EU Green Claims Checklist | Audit-Ready Checklist for Environmental Claims (Substantiation, Verification, Labels, Offsets)](/artifacts/eu/green-claims-directive/checklist.md): An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality. - [EU Green Claims Compliance Program | Operating Model for Marketing Claims: Governance, Evidence Packs, Verification, and Labels](/artifacts/eu/green-claims-directive/compliance.md): A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards. - [EU Green Claims FAQ | Greenwashing Questions, Offsets, Labels, Evidence Packs, and Claim Approval Workflows](/artifacts/eu/green-claims-directive/faq.md): Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims. - [EU Green Claims Timeline and Readiness Calendar | Key Policy Dates + Operational Milestones for Evidence, Verification, and Labels](/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar.md): A practical timeline and readiness calendar for green claims. - [EU Green Claims vs UK Green Claims Code | Practical Differences for Substantiation, Disclosures, Verification, and Enforcement](/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code.md): A practical comparison for teams operating in both the EU and UK. - [Green Claims Substantiation Template | Evidence Pack Structure, Life-Cycle Thinking, Data Quality, and Disclosures](/artifacts/eu/green-claims-directive/green-claims-substantiation-template.md): A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective. - [Green Claims Templates | Claim Card, Substantiation Pack, Verification Checklist, Disclosures, and Approval Logs](/artifacts/eu/green-claims-directive/templates.md): A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist. - [Greenwashing Risk Checklist | EU Green Claims | Pre-Publication Review for Ads, Packaging, Product Pages, and Corporate Claims](/artifacts/eu/green-claims-directive/greenwashing-risk-checklist.md): A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims. - [Labels and Certification Schemes | EU Green Claims | How to Govern Eco-Labels, Badges, Seals, and Scheme Evidence](/artifacts/eu/green-claims-directive/labels-and-certification-schemes.md): A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims. - [Penalties and Enforcement | EU Green Claims | How Greenwashing is Enforced, What Evidence Reduces Risk, and What to Do During Challenges](/artifacts/eu/green-claims-directive/penalties-and-enforcement.md): A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for. - [Requirements | EU Green Claims Directive (Proposal) | Substantiation, Verification, Labels Governance, and Disclosures](/artifacts/eu/green-claims-directive/requirements.md): An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build). - [Substantiation and Evidence Pack | EU Green Claims | How to Build Audit-Ready Evidence for Environmental Claims](/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack.md): A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation. - [Verification and Audit Readiness | EU Green Claims | Reviewer Checklist, Sampling, Evidence Logs, and Common Findings](/artifacts/eu/green-claims-directive/verification-and-audit-readiness.md): A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios. - [What Counts as a Green Claim? | EU Green Claims Directive (Proposal) | Examples, Claim Types, Boundaries, and Common Traps](/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim.md): A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/green-claims-directive/penalties-and-fines --- --- title: "Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/requirements" source_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/requirements" author: "Sorena AI" description: "An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU green claims directive requirements" - "green claims substantiation requirements" - "environmental claim verification requirements" - "greenwashing compliance requirements" - "green labels governance requirements" - "offsets disclosure requirements" - "requirements" - "substantiation" - "verification" - "labels" - "greenwashing" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Requirements An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build). *Requirements* *EU* ## EU Green Claims Requirements Turn environmental claims into controls and evidence you can defend. Focus: substantiation, verification, labels governance, and audit-ready records. Even with shifting legislative status, the operational 'requirements' that matter for enforcement and consumer trust are stable: define the claim precisely, substantiate it with credible evidence and methods, verify it with a repeatable checklist, govern labels like claims, and keep logs. This page translates the proposal's intent into an implementable control set. ## 1) Claim classification and scope (what is the claim, exactly?) You cannot substantiate a claim you haven't defined. Build a claim taxonomy and classify every high-impact claim before publication. Operational output: a claim card per claim version used in campaigns. - Claim type: product vs company; absolute vs comparative; label-like; offset-based. - Boundary: lifecycle stages, geography, timeframe, variants/SKUs, functional unit. - Channels: where the claim appears and what implied messaging exists (visuals/badges). ## 2) Substantiation: life-cycle thinking, methods, and data quality Substantiation is an evidence pack, not a sentence. Use a method appropriate to the claim type and document datasets and assumptions. For lifecycle-based claims, EU Environmental Footprint methods (PEF/OEF) can provide a reference structure (where relevant). - Method rationale and reproducibility (calculation artifacts can be replayed). - Dataset inventory: primary vs secondary data, sources, versions, representativeness. - Data quality and uncertainty: sensitivity notes, limitations, and trade-off handling. ## 3) Trade-offs and comparatives (avoid cherry-picking) Claims that only show one impact category can mislead if other impacts worsen. Comparative claims require a baseline and comparability statement. Operational output: a standard comparative baseline template. - Trade-off disclosure: what improved, what worsened, what was not measured. - Comparative baseline: defined comparator, same functional unit, comparable use phase. - No selective framing: explain material impact categories, not only favorable ones. ## 4) Offset-based climate claims (special disclosure and evidence) Offset-based claims are commonly challenged. Separate reductions and compensation clearly and retain accounting evidence. If you cannot explain the claim without long footnotes, the claim language should be revised. - Separate reduction vs compensation in both claim language and substantiation. - Keep offset evidence: project integrity criteria, retirement/cancellation records, assumptions. - Define boundary: operational vs value-chain scope and timeframe. ## 5) Verification and approvals (controls + logs) Verification is a control. Build a reviewer checklist and store approval logs with evidence pack links. Audit readiness means exportable logs and version history. - Verification checklist: claim card, boundary, method, data quality, trade-offs, disclosures. - Approval log: who reviewed, when, outcome (approve/revise/block), and follow-ups. - Retention: evidence storage location, access controls, and update cadence. ## 6) Labels and certification schemes (govern badges like claims) Labels amplify risk because they imply broad guarantees. Treat them as governed assets with due diligence and evidence packs. Prevent label proliferation with a policy and a single owner. - Scheme due diligence: criteria transparency, verification approach, non-compliance handling. - Label evidence pack: eligibility proof, audit reports, criteria version used, usage log. - Governance: approval workflow and decommissioning process for outdated labels. *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU Green Claims Requirements across ESG workflows ESG Compliance can take EU Green Claims Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Green Claims can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Green Claims Requirements](/solutions/esg-compliance.md): Start from EU Green Claims Requirements and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Green Claims](/contact.md): Review your current process, evidence gaps, and next steps for EU Green Claims Requirements. ## Primary sources - [European Commission - Questions and Answers on European Green Claims (QANDA/23/1693)](https://ec.europa.eu/commission/presscorner/detail/en/qanda_23_1693?ref=sorena.io) - Commission source describing scope, substantiation, verification intent, offsets scrutiny, and label proliferation concerns. - [European Parliament - First reading position (P9_TA(2024)0131)](https://www.europarl.europa.eu/doceo/document/TA-9-2024-0131_EN.html?ref=sorena.io) - Parliament position text and proposed structure for substantiation, verification, and labels governance. - [JRC Environmental Footprint (PEF/OEF) - Commission Recommendation 2021/2279 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32021H2279&ref=sorena.io) - Reference method context for lifecycle-based substantiation design. ## Related Topic Guides - [EU Green Claims Applicability Test | Is This Environmental Claim In Scope (Product vs Company, Labels, Offsets)?](/artifacts/eu/green-claims-directive/applicability-test.md): A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim. - [EU Green Claims Checklist | Audit-Ready Checklist for Environmental Claims (Substantiation, Verification, Labels, Offsets)](/artifacts/eu/green-claims-directive/checklist.md): An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality. - [EU Green Claims Compliance Program | Operating Model for Marketing Claims: Governance, Evidence Packs, Verification, and Labels](/artifacts/eu/green-claims-directive/compliance.md): A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards. - [EU Green Claims FAQ | Greenwashing Questions, Offsets, Labels, Evidence Packs, and Claim Approval Workflows](/artifacts/eu/green-claims-directive/faq.md): Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims. - [EU Green Claims Timeline and Readiness Calendar | Key Policy Dates + Operational Milestones for Evidence, Verification, and Labels](/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar.md): A practical timeline and readiness calendar for green claims. - [EU Green Claims vs UK Green Claims Code | Practical Differences for Substantiation, Disclosures, Verification, and Enforcement](/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code.md): A practical comparison for teams operating in both the EU and UK. - [Green Claims Substantiation Template | Evidence Pack Structure, Life-Cycle Thinking, Data Quality, and Disclosures](/artifacts/eu/green-claims-directive/green-claims-substantiation-template.md): A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective. - [Green Claims Templates | Claim Card, Substantiation Pack, Verification Checklist, Disclosures, and Approval Logs](/artifacts/eu/green-claims-directive/templates.md): A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist. - [Greenwashing Risk Checklist | EU Green Claims | Pre-Publication Review for Ads, Packaging, Product Pages, and Corporate Claims](/artifacts/eu/green-claims-directive/greenwashing-risk-checklist.md): A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims. - [Labels and Certification Schemes | EU Green Claims | How to Govern Eco-Labels, Badges, Seals, and Scheme Evidence](/artifacts/eu/green-claims-directive/labels-and-certification-schemes.md): A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims. - [Penalties and Enforcement | EU Green Claims | How Greenwashing is Enforced, What Evidence Reduces Risk, and What to Do During Challenges](/artifacts/eu/green-claims-directive/penalties-and-enforcement.md): A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for. - [Penalties and Fines | EU Green Claims | Penalty Drivers, Aggravating Factors, and How to Reduce Exposure With Evidence](/artifacts/eu/green-claims-directive/penalties-and-fines.md): A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries. - [Substantiation and Evidence Pack | EU Green Claims | How to Build Audit-Ready Evidence for Environmental Claims](/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack.md): A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation. - [Verification and Audit Readiness | EU Green Claims | Reviewer Checklist, Sampling, Evidence Logs, and Common Findings](/artifacts/eu/green-claims-directive/verification-and-audit-readiness.md): A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios. - [What Counts as a Green Claim? | EU Green Claims Directive (Proposal) | Examples, Claim Types, Boundaries, and Common Traps](/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim.md): A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/green-claims-directive/requirements --- --- title: "Substantiation and Evidence Pack" canonical_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack" source_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack" author: "Sorena AI" description: "A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "green claims evidence pack" - "environmental claims substantiation" - "greenwashing evidence pack" - "sustainability claim audit evidence" - "product environmental footprint evidence" - "claim substantiation records" - "evidence pack" - "substantiation" - "verification" - "audit readiness" - "greenwashing" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Substantiation and Evidence Pack A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation. *Evidence* *EU* ## EU Green Claims Substantiation and Evidence Pack Design evidence so it is provable, exportable, and repeatable. Focus: evidence architecture, data quality, verification logs, and disclosures. A green claims program fails when evidence is scattered and reviewers can't reconstruct what the claim means and how it was calculated. Build an evidence pack system that answers: what is the claim, what is the boundary, what method was used, what data supports it, what trade-offs exist, who verified it, and what did consumers see. ## Start with an evidence architecture (don't start with PDFs) Define the evidence pack structure that you will export during disputes or regulator inquiries. Then map each section to an owner and a system-of-record. Measure time-to-evidence: how quickly can you export a complete pack for a high-impact claim? - Evidence index: artifact -> owner -> system-of-record -> refresh cadence -> export format. - Claim cards as the front door: claim text, channels, classification, boundary, and links. - Version control: every claim and dataset must have a version and a date. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Green Claims Substantiation and Evidence Pack in one governed evidence system SSOT can take EU Green Claims Substantiation and Evidence Pack from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Green Claims can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Green Claims Substantiation and Evidence Pack](/solutions/ssot.md): Start from EU Green Claims Substantiation and Evidence Pack and keep documents, evidence, and control records in one governed system. - [Talk through EU Green Claims](/contact.md): Review your current process, evidence gaps, and next steps for EU Green Claims Substantiation and Evidence Pack. ## Boundary + methodology (make assumptions explicit) Boundaries and assumptions are the main attack surface. If they are not explicit, consumers will assume the broadest interpretation. For claims tied to lifecycle performance, reference methods like PEF/OEF can improve consistency (where appropriate). - Boundary statement: lifecycle stages, geographic scope, timeframe, variants/SKUs. - Method rationale: why this method fits the claim type and audience. - Trade-off handling: which impact categories were considered and why. ## Datasets and data quality (make reviewers confident) 'We used supplier data' is not a data quality story. Maintain a dataset inventory and quality criteria. If you rely on secondary datasets or industry averages, document representativeness and uncertainty. - Dataset inventory: primary vs secondary, sources, versions, representativeness. - Quality gates: completeness, temporal/geographic relevance, uncertainty and sensitivity. - Reproducibility: calculations and models can be replayed. ## Verification records and approval logs (audit readiness) Verification is an operational control: checklists, reviewer roles, and logged decisions. Approval logs reduce chaos: you can explain who approved the claim and based on what evidence. - Verification checklist completed and stored with the pack. - Approval log: reviewers, timestamps, decisions, and required follow-ups. - Retention policy: how long evidence is stored and who can access it. ## Consumer-facing disclosures (what users must understand) A claim without disclosure is often misleading even if calculations are correct. Write disclosures as reusable components (one paragraph + a 'learn more' link) that match the evidence pack. - Plain-language boundary statement. - Comparative baseline and comparability statement (if comparative claim). - Offsets disclosure (if used): reductions vs compensation and evidence references. ## Primary sources - [European Commission - Questions and Answers on European Green Claims (QANDA/23/1693)](https://ec.europa.eu/commission/presscorner/detail/en/qanda_23_1693?ref=sorena.io) - Commission source describing the green claims proposal intent and substantiation/verification emphasis. - [JRC Environmental Footprint overview (PEF/OEF) - Commission Recommendation 2021/2279 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32021H2279&ref=sorena.io) - Life-cycle based reference method context for substantiation design. ## Related Topic Guides - [EU Green Claims Applicability Test | Is This Environmental Claim In Scope (Product vs Company, Labels, Offsets)?](/artifacts/eu/green-claims-directive/applicability-test.md): A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim. - [EU Green Claims Checklist | Audit-Ready Checklist for Environmental Claims (Substantiation, Verification, Labels, Offsets)](/artifacts/eu/green-claims-directive/checklist.md): An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality. - [EU Green Claims Compliance Program | Operating Model for Marketing Claims: Governance, Evidence Packs, Verification, and Labels](/artifacts/eu/green-claims-directive/compliance.md): A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards. - [EU Green Claims FAQ | Greenwashing Questions, Offsets, Labels, Evidence Packs, and Claim Approval Workflows](/artifacts/eu/green-claims-directive/faq.md): Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims. - [EU Green Claims Timeline and Readiness Calendar | Key Policy Dates + Operational Milestones for Evidence, Verification, and Labels](/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar.md): A practical timeline and readiness calendar for green claims. - [EU Green Claims vs UK Green Claims Code | Practical Differences for Substantiation, Disclosures, Verification, and Enforcement](/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code.md): A practical comparison for teams operating in both the EU and UK. - [Green Claims Substantiation Template | Evidence Pack Structure, Life-Cycle Thinking, Data Quality, and Disclosures](/artifacts/eu/green-claims-directive/green-claims-substantiation-template.md): A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective. - [Green Claims Templates | Claim Card, Substantiation Pack, Verification Checklist, Disclosures, and Approval Logs](/artifacts/eu/green-claims-directive/templates.md): A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist. - [Greenwashing Risk Checklist | EU Green Claims | Pre-Publication Review for Ads, Packaging, Product Pages, and Corporate Claims](/artifacts/eu/green-claims-directive/greenwashing-risk-checklist.md): A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims. - [Labels and Certification Schemes | EU Green Claims | How to Govern Eco-Labels, Badges, Seals, and Scheme Evidence](/artifacts/eu/green-claims-directive/labels-and-certification-schemes.md): A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims. - [Penalties and Enforcement | EU Green Claims | How Greenwashing is Enforced, What Evidence Reduces Risk, and What to Do During Challenges](/artifacts/eu/green-claims-directive/penalties-and-enforcement.md): A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for. - [Penalties and Fines | EU Green Claims | Penalty Drivers, Aggravating Factors, and How to Reduce Exposure With Evidence](/artifacts/eu/green-claims-directive/penalties-and-fines.md): A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries. - [Requirements | EU Green Claims Directive (Proposal) | Substantiation, Verification, Labels Governance, and Disclosures](/artifacts/eu/green-claims-directive/requirements.md): An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build). - [Verification and Audit Readiness | EU Green Claims | Reviewer Checklist, Sampling, Evidence Logs, and Common Findings](/artifacts/eu/green-claims-directive/verification-and-audit-readiness.md): A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios. - [What Counts as a Green Claim? | EU Green Claims Directive (Proposal) | Examples, Claim Types, Boundaries, and Common Traps](/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim.md): A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack --- --- title: "Green Claims Templates" canonical_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/templates" source_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/templates" author: "Sorena AI" description: "A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "green claims templates" - "environmental claim template" - "claim substantiation template" - "greenwashing checklist template" - "offset disclosure template" - "comparative claim baseline template" - "claim approval log template" - "templates" - "claim card" - "evidence pack" - "verification" - "approval logs" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Green Claims Templates A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist. *Templates* *EU* ## EU Green Claims Templates Templates that turn green claims into a repeatable workflow. Outcome: faster reviews, better evidence, fewer 'we need legal' bottlenecks. Templates reduce greenwashing risk because they force consistency: every claim gets classified the same way, every evidence pack contains the same key artifacts, and every approval is logged. Use these templates as building blocks for your internal green claims operating model. ## Core templates (use these for every high-impact claim) These templates create a baseline control system: claim definition, evidence, reviewer checks, and logs. Even if the Green Claims proposal status changes, these artifacts remain the most practical defense against enforcement and reputational risk. - Claim card template (claim text, type, boundary, channels, owner, version). - Substantiation/evidence pack template (method, data, calculations, trade-offs, disclosures). - Verification checklist + approval log template (reviewers, timestamps, decisions). *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Green Claims Templates in one governed evidence system SSOT can take EU Green Claims Templates from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Green Claims can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Green Claims Templates](/solutions/ssot.md): Start from EU Green Claims Templates and keep documents, evidence, and control records in one governed system. - [Talk through EU Green Claims](/contact.md): Review your current process, evidence gaps, and next steps for EU Green Claims Templates. ## Specialized templates (trigger-based) Some claim types require extra structure. Treat these as triggers: if the claim matches the pattern, the specialized template is required. Offset-based climate claims and comparative claims are the most common triggers. - Offsets disclosure template (reductions vs compensation, accounting, retirement evidence). - Comparative baseline template (baseline definition, comparability, functional unit). - Label/scheme governance template (criteria transparency, verification, non-compliance handling). ## How to implement templates (so teams actually use them) Templates fail when they are optional. Embed them into tooling: forms, required fields, and workflow gates. Create training and examples for common product categories and claim types. - Add a claim intake form that generates a claim card automatically. - Require evidence pack link before marketing approval can be granted. - Store approvals and evidence in one system-of-record with retention rules. ## Primary sources - [European Commission - Green claims policy overview](https://environment.ec.europa.eu/topics/circular-economy/green-claims_en?ref=sorena.io) - Official overview page providing context for environmental claims policy and supporting materials. - [European Commission - Questions and Answers on European Green Claims (QANDA/23/1693)](https://ec.europa.eu/commission/presscorner/detail/en/qanda_23_1693?ref=sorena.io) - Commission context explaining substantiation and verification intent. ## Related Topic Guides - [EU Green Claims Applicability Test | Is This Environmental Claim In Scope (Product vs Company, Labels, Offsets)?](/artifacts/eu/green-claims-directive/applicability-test.md): A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim. - [EU Green Claims Checklist | Audit-Ready Checklist for Environmental Claims (Substantiation, Verification, Labels, Offsets)](/artifacts/eu/green-claims-directive/checklist.md): An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality. - [EU Green Claims Compliance Program | Operating Model for Marketing Claims: Governance, Evidence Packs, Verification, and Labels](/artifacts/eu/green-claims-directive/compliance.md): A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards. - [EU Green Claims FAQ | Greenwashing Questions, Offsets, Labels, Evidence Packs, and Claim Approval Workflows](/artifacts/eu/green-claims-directive/faq.md): Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims. - [EU Green Claims Timeline and Readiness Calendar | Key Policy Dates + Operational Milestones for Evidence, Verification, and Labels](/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar.md): A practical timeline and readiness calendar for green claims. - [EU Green Claims vs UK Green Claims Code | Practical Differences for Substantiation, Disclosures, Verification, and Enforcement](/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code.md): A practical comparison for teams operating in both the EU and UK. - [Green Claims Substantiation Template | Evidence Pack Structure, Life-Cycle Thinking, Data Quality, and Disclosures](/artifacts/eu/green-claims-directive/green-claims-substantiation-template.md): A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective. - [Greenwashing Risk Checklist | EU Green Claims | Pre-Publication Review for Ads, Packaging, Product Pages, and Corporate Claims](/artifacts/eu/green-claims-directive/greenwashing-risk-checklist.md): A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims. - [Labels and Certification Schemes | EU Green Claims | How to Govern Eco-Labels, Badges, Seals, and Scheme Evidence](/artifacts/eu/green-claims-directive/labels-and-certification-schemes.md): A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims. - [Penalties and Enforcement | EU Green Claims | How Greenwashing is Enforced, What Evidence Reduces Risk, and What to Do During Challenges](/artifacts/eu/green-claims-directive/penalties-and-enforcement.md): A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for. - [Penalties and Fines | EU Green Claims | Penalty Drivers, Aggravating Factors, and How to Reduce Exposure With Evidence](/artifacts/eu/green-claims-directive/penalties-and-fines.md): A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries. - [Requirements | EU Green Claims Directive (Proposal) | Substantiation, Verification, Labels Governance, and Disclosures](/artifacts/eu/green-claims-directive/requirements.md): An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build). - [Substantiation and Evidence Pack | EU Green Claims | How to Build Audit-Ready Evidence for Environmental Claims](/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack.md): A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation. - [Verification and Audit Readiness | EU Green Claims | Reviewer Checklist, Sampling, Evidence Logs, and Common Findings](/artifacts/eu/green-claims-directive/verification-and-audit-readiness.md): A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios. - [What Counts as a Green Claim? | EU Green Claims Directive (Proposal) | Examples, Claim Types, Boundaries, and Common Traps](/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim.md): A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/green-claims-directive/templates --- --- title: "Verification and Audit Readiness" canonical_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/verification-and-audit-readiness" source_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/verification-and-audit-readiness" author: "Sorena AI" description: "A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "green claims verification" - "green claims audit readiness" - "environmental claims verification checklist" - "greenwashing audit checklist" - "claim approval workflow" - "substantiation verification evidence" - "verification" - "audit readiness" - "checklist" - "evidence logs" - "greenwashing" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Verification and Audit Readiness A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios. *Audit* *EU* ## EU Green Claims Verification and Audit Readiness A reviewer workflow: checklist, sampling, evidence logs, and common failure modes. Outcome: approvals become consistent and defensible across campaigns. Verification is an operational control: a structured review that checks claim meaning, boundaries, methods, data quality, trade-offs, and disclosures. Audit readiness means you can export evidence and show that approvals were deliberate, logged, and based on defined acceptance criteria. ## Verification checklist (minimum acceptance criteria) A claim should not pass review unless it has a claim card and a complete evidence pack. Reviewers should be able to reproduce the claim meaning and evidence path. Use a checklist that is consistent across product, legal, marketing, and sustainability reviewers. In the Parliament first-reading text, verification was expected within 30 days, subject to justified extensions, which is a useful operating target even though the proposal has not been adopted. - Claim card: claim text variants, channels, claim type, owner, and version history. - Boundary statement: lifecycle scope, exclusions, geography/timeframe, product variants. - Methods and datasets: rationale, data quality, and reproducibility. - Trade-offs and uncertainty: sensitivity notes and disclosure adequacy. - Disclosures: plain-language boundary and baseline statements; offsets disclosure if applicable. ## Sampling strategy (how to review a portfolio of claims) If you publish many claims, you can't deep-audit every sentence. Use sampling by risk and reach. Define claim risk tiers and review depth per tier. - Tier 1 (highest): absolute and offset-based climate claims; high-reach campaigns; label-like claims. - Tier 2: comparative claims; multi-impact claims; claims with known trade-offs. - Tier 3: narrow, specific, low-reach claims with well-defined boundaries. ## Evidence logs and approval records (what to store) Logs are the difference between 'we tried' and 'we operated a control system'. Store reviewer decisions and artifacts in a durable system. Design logs for export: who approved, when, and based on what evidence. - Approval log: reviewers, timestamps, outcomes (approve/revise/block), and follow-up tasks. - Evidence pack index: links to datasets, calculations, and disclosure text used in the published claim. - Retention and access controls: who can view and edit evidence; audit trail requirements. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Green Claims Verification and Audit Readiness in one governed evidence system SSOT can take EU Green Claims Verification and Audit Readiness from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Green Claims can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Green Claims Verification and Audit Readiness](/solutions/ssot.md): Start from EU Green Claims Verification and Audit Readiness and keep documents, evidence, and control records in one governed system. - [Talk through EU Green Claims](/contact.md): Review your current process, evidence gaps, and next steps for EU Green Claims Verification and Audit Readiness. ## Common findings (what reviewers flag most often) Most findings are structural-not 'your numbers are wrong', but 'your claim is ambiguous or implies more than you measured'. Use findings as feedback loops: update templates and training. - Undefined claim terms (eco/green/sustainable) without quantified scope. - Missing boundaries (only packaging measured, but claim implies full product). - Comparative baseline not defined or not comparable. - Offsets used but reductions vs compensation not separated. - Trade-offs not disclosed (one metric improved, another worsened). ## Primary sources - [European Commission - Questions and Answers on European Green Claims (QANDA/23/1693)](https://ec.europa.eu/commission/presscorner/detail/en/qanda_23_1693?ref=sorena.io) - Commission context for substantiation intent and ex ante verification approach. - [European Parliament Think Tank - Green claims directive briefing (EPRS_BRI(2023)753958)](https://www.europarl.europa.eu/thinktank/en/document/EPRS_BRI(2023)753958?ref=sorena.io) - Policy summary and common issues for environmental claims regulation. ## Related Topic Guides - [EU Green Claims Applicability Test | Is This Environmental Claim In Scope (Product vs Company, Labels, Offsets)?](/artifacts/eu/green-claims-directive/applicability-test.md): A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim. - [EU Green Claims Checklist | Audit-Ready Checklist for Environmental Claims (Substantiation, Verification, Labels, Offsets)](/artifacts/eu/green-claims-directive/checklist.md): An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality. - [EU Green Claims Compliance Program | Operating Model for Marketing Claims: Governance, Evidence Packs, Verification, and Labels](/artifacts/eu/green-claims-directive/compliance.md): A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards. - [EU Green Claims FAQ | Greenwashing Questions, Offsets, Labels, Evidence Packs, and Claim Approval Workflows](/artifacts/eu/green-claims-directive/faq.md): Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims. - [EU Green Claims Timeline and Readiness Calendar | Key Policy Dates + Operational Milestones for Evidence, Verification, and Labels](/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar.md): A practical timeline and readiness calendar for green claims. - [EU Green Claims vs UK Green Claims Code | Practical Differences for Substantiation, Disclosures, Verification, and Enforcement](/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code.md): A practical comparison for teams operating in both the EU and UK. - [Green Claims Substantiation Template | Evidence Pack Structure, Life-Cycle Thinking, Data Quality, and Disclosures](/artifacts/eu/green-claims-directive/green-claims-substantiation-template.md): A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective. - [Green Claims Templates | Claim Card, Substantiation Pack, Verification Checklist, Disclosures, and Approval Logs](/artifacts/eu/green-claims-directive/templates.md): A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist. - [Greenwashing Risk Checklist | EU Green Claims | Pre-Publication Review for Ads, Packaging, Product Pages, and Corporate Claims](/artifacts/eu/green-claims-directive/greenwashing-risk-checklist.md): A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims. - [Labels and Certification Schemes | EU Green Claims | How to Govern Eco-Labels, Badges, Seals, and Scheme Evidence](/artifacts/eu/green-claims-directive/labels-and-certification-schemes.md): A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims. - [Penalties and Enforcement | EU Green Claims | How Greenwashing is Enforced, What Evidence Reduces Risk, and What to Do During Challenges](/artifacts/eu/green-claims-directive/penalties-and-enforcement.md): A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for. - [Penalties and Fines | EU Green Claims | Penalty Drivers, Aggravating Factors, and How to Reduce Exposure With Evidence](/artifacts/eu/green-claims-directive/penalties-and-fines.md): A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries. - [Requirements | EU Green Claims Directive (Proposal) | Substantiation, Verification, Labels Governance, and Disclosures](/artifacts/eu/green-claims-directive/requirements.md): An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build). - [Substantiation and Evidence Pack | EU Green Claims | How to Build Audit-Ready Evidence for Environmental Claims](/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack.md): A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation. - [What Counts as a Green Claim? | EU Green Claims Directive (Proposal) | Examples, Claim Types, Boundaries, and Common Traps](/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim.md): A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/green-claims-directive/verification-and-audit-readiness --- --- title: "What Counts as a Green Claim?" canonical_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim" source_url: "https://www.sorena.io/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim" author: "Sorena AI" description: "A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "what is a green claim" - "environmental claim definition" - "green claims examples" - "carbon neutral claim substantiation" - "net zero claim evidence" - "greenwashing claims examples" - "EU green claims" - "green claims" - "environmental claims" - "greenwashing" - "marketing compliance" - "substantiation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # What Counts as a Green Claim? A practical guide to what counts as a green claim (explicit environmental claim): product and corporate claims, absolute vs comparative claims. *Classification* *EU* ## EU Green Claims What Counts as a Green Claim A claim classification framework marketing teams can actually use. Outcome: define the claim, boundaries, and evidence needs before you publish. Most greenwashing risk comes from misclassification: teams publish claim language without deciding what the claim actually means (product vs company, absolute vs comparative, life-cycle scope, reliance on offsets). Use this page to classify claims consistently and trigger the right evidence and approval workflow. ## Green claim vs marketing fluff (a practical definition) A green claim is a statement (or messaging) that communicates environmental impact, aspect, or performance of a product or trader. The risky part is that claims can be explicit ('carbon neutral') or implicit ('eco-friendly' imagery plus cues). Operational outcome: treat each claim as a structured object: claim text -> claim type -> scope -> boundary -> evidence pack. - Product claim: about a product, service, or product line (materials, durability, emissions, recyclability). - Corporate claim: about the company or brand ('net zero by 2030', 'climate positive company'). - Label-like claim: badges, icons, seals, rating-like labels, or scheme participation messaging. *Recommended next step* *Placement: after the scope or definition section* ## Use EU Green Claims What Counts as a Green Claim as a cited research workflow Research Copilot can take EU Green Claims What Counts as a Green Claim from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Green Claims can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Green Claims What Counts as a Green Claim](/solutions/research-copilot.md): Start from EU Green Claims What Counts as a Green Claim and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Green Claims](/contact.md): Review your current process, evidence gaps, and next steps for EU Green Claims What Counts as a Green Claim. ## Claim types that require different substantiation Not all claims are equal. Absolute claims usually need the strongest substantiation and the clearest boundaries. Comparative claims need a defensible baseline and comparable methodology. Build a claim taxonomy and map each type to an evidence template and reviewer. - Absolute claims: 'carbon neutral', 'zero emissions', '100% sustainable'. - Comparative claims: '30% lower emissions than previous model', 'more recyclable than X'. - Trade-off claims: improvements in one impact category that may worsen another (require transparency). ## Offset-based climate claims (high-risk, high-scrutiny) Claims relying on carbon offsets/credits are frequently challenged because they mix emissions reduction with compensation. The core risk is ambiguity: what was reduced vs what was offset, and how credible the offset is. If you use offsets, treat it as a disclosure-heavy claim: separate reduction and compensation clearly. - Define operational vs value-chain boundaries (what emissions are included). - Separate reductions vs compensation in the claim language and supporting materials. - Keep offset evidence: project quality, accounting, retirement/cancellation records, and assumptions. ## What 'done' looks like (classification outputs) A claim is publishable when a reviewer can understand the claim meaning and the evidence path without asking the author to explain it verbally. Create a one-page claim card for every high-impact claim used in campaigns. - Claim card: claim text, claim type, product/company scope, geographic scope, audience and channels. - Boundary statement: what is included and excluded (life-cycle stage, product variants, timeframe). - Evidence pointer: which substantiation template applies and where the pack is stored. ## Primary sources - [European Commission - Questions and Answers on European Green Claims (QANDA/23/1693)](https://ec.europa.eu/commission/presscorner/detail/en/qanda_23_1693?ref=sorena.io) - Official Commission explanation of the Green Claims proposal scope, claim examples, and substantiation/verification intent. - [European Commission - Green claims policy overview](https://environment.ec.europa.eu/topics/circular-economy/green-claims_en?ref=sorena.io) - Official overview page linking policy context and supporting documents. ## Related Topic Guides - [EU Green Claims Applicability Test | Is This Environmental Claim In Scope (Product vs Company, Labels, Offsets)?](/artifacts/eu/green-claims-directive/applicability-test.md): A step-by-step applicability test for green claims: decide whether a claim is a covered explicit environmental claim. - [EU Green Claims Checklist | Audit-Ready Checklist for Environmental Claims (Substantiation, Verification, Labels, Offsets)](/artifacts/eu/green-claims-directive/checklist.md): An audit-ready checklist for green claims programs: claim inventory and classification, substantiation evidence packs (life-cycle boundaries, data quality. - [EU Green Claims Compliance Program | Operating Model for Marketing Claims: Governance, Evidence Packs, Verification, and Labels](/artifacts/eu/green-claims-directive/compliance.md): A practical green claims compliance playbook: program setup, governance cadence, claim taxonomy and inventory, substantiation standards. - [EU Green Claims FAQ | Greenwashing Questions, Offsets, Labels, Evidence Packs, and Claim Approval Workflows](/artifacts/eu/green-claims-directive/faq.md): Implementation-focused answers to common green claims questions: what counts as a green claim, how to substantiate and verify claims. - [EU Green Claims Timeline and Readiness Calendar | Key Policy Dates + Operational Milestones for Evidence, Verification, and Labels](/artifacts/eu/green-claims-directive/deadlines-and-compliance-calendar.md): A practical timeline and readiness calendar for green claims. - [EU Green Claims vs UK Green Claims Code | Practical Differences for Substantiation, Disclosures, Verification, and Enforcement](/artifacts/eu/green-claims-directive/green-claims-directive-vs-uk-green-claims-code.md): A practical comparison for teams operating in both the EU and UK. - [Green Claims Substantiation Template | Evidence Pack Structure, Life-Cycle Thinking, Data Quality, and Disclosures](/artifacts/eu/green-claims-directive/green-claims-substantiation-template.md): A copy/paste-ready substantiation template for environmental claims: claim card, boundary definition, life-cycle perspective. - [Green Claims Templates | Claim Card, Substantiation Pack, Verification Checklist, Disclosures, and Approval Logs](/artifacts/eu/green-claims-directive/templates.md): A templates hub for environmental claims programs: claim card template, substantiation/evidence pack template, verification checklist. - [Greenwashing Risk Checklist | EU Green Claims | Pre-Publication Review for Ads, Packaging, Product Pages, and Corporate Claims](/artifacts/eu/green-claims-directive/greenwashing-risk-checklist.md): A practical greenwashing risk checklist to review environmental claims before publication: vagueness and ambiguity checks, absolute vs comparative claims. - [Labels and Certification Schemes | EU Green Claims | How to Govern Eco-Labels, Badges, Seals, and Scheme Evidence](/artifacts/eu/green-claims-directive/labels-and-certification-schemes.md): A practical guide to governing environmental labels and certification schemes: how label-like messaging creates implied claims. - [Penalties and Enforcement | EU Green Claims | How Greenwashing is Enforced, What Evidence Reduces Risk, and What to Do During Challenges](/artifacts/eu/green-claims-directive/penalties-and-enforcement.md): A practical enforcement guide for green claims: how challenges and investigations typically unfold, what authorities and platforms ask for. - [Penalties and Fines | EU Green Claims | Penalty Drivers, Aggravating Factors, and How to Reduce Exposure With Evidence](/artifacts/eu/green-claims-directive/penalties-and-fines.md): A practical penalties guide for green claims: what drives penalty exposure in greenwashing cases (ambiguity, lack of substantiation, missing boundaries. - [Requirements | EU Green Claims Directive (Proposal) | Substantiation, Verification, Labels Governance, and Disclosures](/artifacts/eu/green-claims-directive/requirements.md): An implementation-grade breakdown of what the EU Green Claims Directive proposal aimed to require (and what best-practice programs still build). - [Substantiation and Evidence Pack | EU Green Claims | How to Build Audit-Ready Evidence for Environmental Claims](/artifacts/eu/green-claims-directive/substantiation-and-evidence-pack.md): A practical evidence pack guide for environmental claims: claim inventory, evidence architecture, boundary and methodology documentation. - [Verification and Audit Readiness | EU Green Claims | Reviewer Checklist, Sampling, Evidence Logs, and Common Findings](/artifacts/eu/green-claims-directive/verification-and-audit-readiness.md): A practical verification and audit readiness guide for environmental claims: verification checklist, sampling strategy for claim portfolios. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/green-claims-directive/what-counts-as-a-green-claim --- --- title: "Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/applicability-test" author: "Sorena AI" description: "A step-by-step applicability test for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, product vs component." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Low Voltage Directive applicability test" - "is my product in scope LVD" - "Low Voltage Directive 2014/35/EU scope test" - "LVD Annex II exclusions" - "LVD voltage limits" - "LVD CE marking scope" - "LVD distance sales requirements" - "applicability" - "scope" - "LVD" - "Annex II" - "CE marking" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Applicability Test A step-by-step applicability test for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, product vs component. *Applicability* *EU* ## EU Low Voltage Directive (LVD) 2014/35/EU Applicability Test Decide if the product is in scope or excluded with audit-grade reasoning. Use this to create a reusable scope memo per product family covering voltage limits, Annex II exclusions, component status, and overlap with other CE regimes. An LVD applicability decision is only as good as the product facts behind it. This page turns the directive, the 2018 LVD Guide, and the Blue Guide into a practical scope test so you can document voltage limits, exclusions, component treatment, online sales exposure, and the economic operator role that carries the CE evidence burden. ## Before you start: capture the minimum product facts If you do not have these facts, you are guessing, and scope guesses cause expensive redesign and retesting later. Output: a one page scope memo and an initial applicable legislation list that engineering, compliance, and the commercial owner all use. - Rated voltage, AC or DC, frequency, mains connection method, external power supply strategy, and power class. - Intended use environment, user type, foreseeable misuse, installation conditions, and duty cycle. - Product form: finished equipment, sub assembly, component, kit, or spare part; variants and accessories included in the offer. - Sales model: Union manufacturer, importer, authorised representative, distributor, fulfilment service provider, and whether EU targeted online sales are in scope. ## Step 1 - Are you within the LVD voltage limits? The LVD covers electrical equipment designed for use at 50 to 1000 V for alternating current and 75 to 1500 V for direct current. Start with the rated input of the product you actually place on the market, not only the internal rails after conversion. Borderline trap: if you market a mains powered external power supply and a low voltage device together or separately, each item may need its own scope conclusion and evidence path. - Confirm rated input voltage and capture the exact power architecture from mains to downstream electronics. - Record whether the product is a finished electrical item, or only a basic component whose safety can only be assessed once incorporated. - If you sell the power supply, charger, or control panel separately, decide its LVD status separately. ## Step 2 - Explicitly test every Annex II exclusion The fastest scope failure is forgetting that Annex II excludes specific product categories even when they are electrical. The LVD Guide also clarifies that many basic components are not electrical equipment for LVD purposes, while some standalone electrical subassemblies such as transformers or electric motors can be. - Check and record exclusions for equipment intended for use in an explosive atmosphere, radiology and medical electrical equipment, electrical parts for goods and passenger lifts, electricity meters, domestic plugs and socket outlets, electric fence controllers, and radio electrical interference products. - Check whether the product is a custom built evaluation kit for professionals used solely at research and development facilities. - If the item is a basic component such as a semiconductor, resistor, or connector, document why it is not itself electrical equipment; if it is a transformer, motor, or similar standalone item, test whether it is independently in scope. ## Step 3 - Is another Union regime also relevant? Multi directive products are normal. LVD often sits beside EMC and may sit beside RED, RoHS, or machinery rules depending on product type and features. Use the Blue Guide approach: decide whether you have one finished product under several acts, or whether another regime governs the same safety issue for that product type. - If the product includes radio functions such as Wi-Fi or Bluetooth, test RED scope as well as LVD and EMC. - If the product is machinery, a lift related item, or another product governed by a more specific regime, document which act governs electrical risk conformity assessment. - If the product is offered online into the EU, treat EU targeted listings as making the product available on the Union market. ## Step 4 - Who is the manufacturer for compliance purposes? Scope is not only about the product. It is also about which economic operator must hold the technical file, sign the DoC, and cooperate with market surveillance authorities. Article 10 matters here: an importer or distributor becomes the manufacturer if it markets the product under its own name or modifies the product in a way that can affect conformity. - Manufacturer duties: design and manufacture to Annex I, carry out Module A, draw up technical documentation, sign the DoC, affix CE marking, and keep the file for 10 years. - Importer duties: place only compliant equipment on the market, keep a copy of the DoC for 10 years, and ensure technical documentation can be obtained on request. - Online and distance sales: identify the EU based economic operator that performs Article 4 tasks under Regulation (EU) 2019/1020 where required. ## Step 5 - If in scope, create the next three artifacts immediately Once scope is confirmed, stop debating and start building the evidence chain. Delay here usually means the release gate fails late and expensively. Use the linked pages to turn the scope outcome into engineering work, documentation, and post market readiness. - Annex I safety objective mapping with hazards, controls, standards clauses, and tests. - Conformity assessment plan covering Module A, DoC ownership, CE marking, traceability, and instruction language requirements. - Annex III technical documentation index with risk analysis, drawings, standards register, test reports, and a response pack export. *Recommended next step* *Placement: after the applicability result* ## Turn EU Low Voltage Directive (LVD) 2014/35/EU Applicability Test into an operational assessment Assessment Autopilot can take EU Low Voltage Directive (LVD) 2014/35/EU Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU Low Voltage Directive (LVD) 2014/35/EU can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Low Voltage Directive (LVD) 2014/35/EU Applicability Test](/solutions/assessment.md): Start from EU Low Voltage Directive (LVD) 2014/35/EU Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Low Voltage Directive (LVD) 2014/35/EU](/contact.md): Review your current process, evidence gaps, and next steps for EU Low Voltage Directive (LVD) 2014/35/EU Applicability Test. ## Primary sources - [Directive 2014/35/EU - Low Voltage Directive (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/35/oj?ref=sorena.io) - Primary legal text for voltage limits, Annex II exclusions, economic operator duties, Annex III technical documentation, and Annex IV DoC structure. - [LVD Guidelines (August 2018) - European Commission](https://ec.europa.eu/docsroom/documents/33107?ref=sorena.io) - Practical guidance on what counts as electrical equipment, components, instruction languages, importer and distributor duties, and standards governance. - [Blue Guide 2022 - Commission Notice 2022/C 247/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0628%2804%29&ref=sorena.io) - Guidance on making available on the market, finished products versus combinations of parts, substantial modification, and simultaneous application of Union product rules. - [Regulation (EU) 2019/1020 - Market surveillance and compliance of products (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Article 4 tasks, fulfilment service provider coverage, and online sales targeting rules relevant to LVD products sold into the EU. ## Related Topic Guides - [Checklist | EU Low Voltage Directive (LVD) 2014/35/EU | CE Marking Readiness Checklist (Technical File + DoC)](/artifacts/eu/low-voltage-directive/checklist.md): An audit-ready CE marking checklist for the EU Low Voltage Directive (LVD) 2014/35/EU: scope memo + Annex II exclusions, Annex I safety objectives mapping. - [Compliance Program | EU Low Voltage Directive (LVD) 2014/35/EU | Operating Model, Controls, and Evidence](/artifacts/eu/low-voltage-directive/compliance.md): Build a scalable compliance program for EU Low Voltage Directive (LVD) 2014/35/EU: product family strategy, scope control, Annex I hazard mapping. - [Conformity Assessment and CE Marking | EU Low Voltage Directive (LVD) 2014/35/EU | Module A, DoC, Technical File](/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce.md): A practical CE marking workflow for EU Low Voltage Directive (LVD) 2014/35/EU: Module A (internal production control), risk assessment. - [Deadlines and Compliance Calendar | EU Low Voltage Directive (LVD) 2014/35/EU | Release Gates, Evidence Cadence, Standards Updates](/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for EU Low Voltage Directive 2014/35/EU: legal milestones from adoption through current application, release gate timing. - [Essential Safety Requirements (Annex I) | EU Low Voltage Directive (LVD) 2014/35/EU | Hazards, Controls, and Test Evidence](/artifacts/eu/low-voltage-directive/essential-safety-requirements.md): Translate EU Low Voltage Directive (LVD) 2014/35/EU Annex I safety objectives into an engineering-ready hazard map: protection against electric shock. - [EU LVD vs EMC Directive | Low Voltage Directive 2014/35/EU vs EMC 2014/30/EU | What Changes for CE Marking?](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive.md): A practical comparison of the EU Low Voltage Directive (LVD) 2014/35/EU and the EMC Directive 2014/30/EU. - [EU LVD vs Machinery Regulation | Low Voltage Directive 2014/35/EU vs Machinery Regulation (EU) 2023/1230 | Electrical Risks and CE Evidence](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation.md): A practical overlap guide for Low Voltage Directive (LVD) 2014/35/EU and Machinery Regulation (EU) 2023/1230: when the product is machinery/related product. - [FAQ | EU Low Voltage Directive (LVD) 2014/35/EU | Scope, CE Marking, Technical File](/artifacts/eu/low-voltage-directive/faq.md): High-signal FAQ for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, do you need a notified body. - [Harmonised Standards | EU Low Voltage Directive (LVD) 2014/35/EU | Presumption of Conformity, OJ Lists, and Update Control](/artifacts/eu/low-voltage-directive/harmonized-standards.md): How harmonised standards work under the EU Low Voltage Directive (LVD) 2014/35/EU: presumption of conformity, Official Journal (OJ) references. - [Penalties and Fines | EU Low Voltage Directive (LVD) 2014/35/EU | Enforcement, Market Surveillance Actions, Risk Reduction](/artifacts/eu/low-voltage-directive/penalties-and-fines.md): Enforcement overview for the EU Low Voltage Directive (LVD) 2014/35/EU: what market surveillance authorities typically ask for. - [Requirements | EU Low Voltage Directive (LVD) 2014/35/EU | Manufacturer, Importer, Distributor Obligations](/artifacts/eu/low-voltage-directive/requirements.md): An implementation-grade requirements breakdown for the EU Low Voltage Directive (LVD) 2014/35/EU: obligations for manufacturers, authorised representatives. - [Scope and Products | EU Low Voltage Directive (LVD) 2014/35/EU | Voltage Limits, Exclusions (Annex II), and Examples](/artifacts/eu/low-voltage-directive/scope-and-products.md): A practical scope guide for the EU Low Voltage Directive 2014/35/EU: voltage limits at 50 to 1000 V AC and 75 to 1500 V DC. - [Technical Documentation (Technical File) | EU Low Voltage Directive (LVD) 2014/35/EU | Annex III Checklist and Structure](/artifacts/eu/low-voltage-directive/technical-documentation.md): Build an audit-ready LVD technical file for Directive 2014/35/EU: Annex III elements (product description, drawings/schematics, explanations, standards list. - [Templates | EU Low Voltage Directive (LVD) 2014/35/EU | Technical File Index, DoC Skeleton, Scope Memo, Evidence Pack](/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template.md): Copy/paste templates for EU Low Voltage Directive (LVD) 2014/35/EU compliance: scope memo (voltage + Annex II exclusions + overlap). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/low-voltage-directive/applicability-test --- --- title: "Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/checklist" source_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/checklist" author: "Sorena AI" description: "An audit-ready CE marking checklist for the EU Low Voltage Directive (LVD) 2014/35/EU: scope memo + Annex II exclusions, Annex I safety objectives mapping." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Low Voltage Directive checklist" - "LVD compliance checklist" - "CE marking checklist electrical equipment" - "LVD technical file checklist Annex III" - "EU declaration of conformity checklist LVD" - "LVD readiness checklist" - "checklist" - "CE marking" - "technical file" - "DoC" - "LVD compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Checklist An audit-ready CE marking checklist for the EU Low Voltage Directive (LVD) 2014/35/EU: scope memo + Annex II exclusions, Annex I safety objectives mapping. *Checklist* *EU* ## EU LVD 2014/35/EU Checklist A CE marking readiness checklist you can run before release. Each item should have an owner, evidence link, and acceptance criteria. This checklist is designed to survive two real tests: an internal release gate for shipping CE marked products and a market surveillance request for documentation. Use it per product family, link every item to evidence in your technical documentation index, and make sure importer and distributor touchpoints are covered as well as manufacturer tasks. ## A) Scope and applicability (don't build the wrong evidence pack) Scope is the highest leverage step. Document it once and reuse it across variants. - Rated voltage, power architecture, and finished product versus component status documented. - Annex II exclusions explicitly checked and recorded in a scope memo. - Applicable Union legislation list created, including LVD, EMC, RED, machinery, and other relevant acts where applicable. - Economic operator roles confirmed, including any Article 4 responsible economic operator for distance sales. - Type, batch, serial number, or other traceability identifier linked clearly to the technical documentation set. ## B) Safety objectives and risk assessment (Annex I -> hazards -> controls) Evidence must show how Annex I safety objectives are met - not just that tests were run. - Hazard log created (including non-electrical hazards caused by the equipment). - Environment assumptions documented (installation, humidity, overload, misuse). - Controls mapped to hazards (design features + protective measures). - Verification methods defined per hazard (tests, calculations, inspections). - Residual risks documented with warnings/instructions where needed. ## C) Standards governance (presumption of conformity done right) Standards are controls. Track versions, scope, and partial application. - Standards register per product family with decision reference, edition, hazards covered, and cessation date where relevant. - Clause mapping for partial application with justified exclusions and alternative controls. - Standards update review cadence defined around OJ decisions, including 2024 and 2025 amendments where relevant to the product. - Alternative technical solutions documented where harmonised standards are not used or are used only in part. ## D) Verification testing and engineering evidence Test evidence should be reproducible: configurations tested, limits, and results. - Test plan references hazards and standards clauses; includes abnormal/fault conditions where relevant. - Test reports available and linked (dielectric strength, leakage current, temperature rise, mechanical, etc. as applicable). - Critical components list maintained (safety-related parts, insulation system, protective devices). - Manufacturing controls documented for safety-critical steps (QA checks, calibration, process limits). ## E) Technical documentation (Annex III) and retention Your technical file index is the map. Without it, you can't respond fast. - Annex III technical documentation complete, including product description, drawings, explanations, risk analysis, standards list, calculations, and test reports where applicable. - Evidence pack export created with stable filenames and a response pack that can be shared quickly with authorities. - Technical file owner, storage location, retrieval SLA, and 10 year retention process defined. - Importer document holding requirement covered: copy of the DoC retained for 10 years and technical documentation availability contractually secured. ## F) EU Declaration of Conformity (DoC) + CE marking + traceability These are the first things checked. Treat them as release blockers if wrong. - DoC drafted in Annex IV model structure, lists all applicable legislation, and is continuously updated when product or standards references change. - CE marking affixed correctly and consistently across product, data plate, packaging, and accompanying documents where needed. - Manufacturer and importer traceability details present with a single contact point and legible postal address. - Where applicable, Article 4 economic operator details for the EU market are indicated on the product, packaging, parcel, or accompanying document. ## G) Instructions and safety information (language + clarity) Instruction quality is compliance quality. It must align to hazards and be understandable. - Instructions and safety information align to the hazard analysis and foreseeable misuse assumptions. - Language set for each target Member State is defined and translation ownership is contractually assigned. - Warnings, installation limits, maintenance conditions, and overload limitations are clear and intelligible. - Importer and distributor pre sale checks confirm that the required instructions and safety information are actually present. ## H) Post-market and market surveillance readiness Plan for enforcement before it happens: corrective actions, complaints, and rapid evidence retrieval. - Complaint, non conformity, and recall register maintained with named owners and escalation criteria. - Corrective action workflow defined for Article 19 risk cases, Article 21 compliant but risky products, and Article 22 formal non compliance findings. - Market surveillance response pack maintained with DoC, technical documentation index, key test reports, and contact point. - Supply chain traceability information retained for 10 years so affected units can be isolated during corrective action. *Recommended next step* *Placement: after the checklist block* ## Turn EU LVD 2014/35/EU Checklist into an operational assessment Assessment Autopilot can take EU LVD 2014/35/EU Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU LVD 2014/35/EU can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU LVD 2014/35/EU Checklist](/solutions/assessment.md): Start from EU LVD 2014/35/EU Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU LVD 2014/35/EU](/contact.md): Review your current process, evidence gaps, and next steps for EU LVD 2014/35/EU Checklist. ## Primary sources - [Directive 2014/35/EU - Low Voltage Directive (Annex I, III, IV; economic operator obligations) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/35/oj?ref=sorena.io) - Primary requirements for safety objectives, technical documentation, DoC model, CE marking, and supply chain duties. - [Regulation (EU) 2019/1020 - Market surveillance and compliance of products (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Market surveillance cooperation framework and documentation availability expectations, including online sales concepts. - [Blue Guide 2022 - Commission Notice 2022/C 247/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0628%2804%29&ref=sorena.io) - Cross-regime guidance on conformity assessment modules, CE marking, economic operator roles, and technical documentation practices. ## Related Topic Guides - [Applicability Test | EU Low Voltage Directive (LVD) 2014/35/EU | In Scope or Excluded?](/artifacts/eu/low-voltage-directive/applicability-test.md): A step-by-step applicability test for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, product vs component. - [Compliance Program | EU Low Voltage Directive (LVD) 2014/35/EU | Operating Model, Controls, and Evidence](/artifacts/eu/low-voltage-directive/compliance.md): Build a scalable compliance program for EU Low Voltage Directive (LVD) 2014/35/EU: product family strategy, scope control, Annex I hazard mapping. - [Conformity Assessment and CE Marking | EU Low Voltage Directive (LVD) 2014/35/EU | Module A, DoC, Technical File](/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce.md): A practical CE marking workflow for EU Low Voltage Directive (LVD) 2014/35/EU: Module A (internal production control), risk assessment. - [Deadlines and Compliance Calendar | EU Low Voltage Directive (LVD) 2014/35/EU | Release Gates, Evidence Cadence, Standards Updates](/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for EU Low Voltage Directive 2014/35/EU: legal milestones from adoption through current application, release gate timing. - [Essential Safety Requirements (Annex I) | EU Low Voltage Directive (LVD) 2014/35/EU | Hazards, Controls, and Test Evidence](/artifacts/eu/low-voltage-directive/essential-safety-requirements.md): Translate EU Low Voltage Directive (LVD) 2014/35/EU Annex I safety objectives into an engineering-ready hazard map: protection against electric shock. - [EU LVD vs EMC Directive | Low Voltage Directive 2014/35/EU vs EMC 2014/30/EU | What Changes for CE Marking?](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive.md): A practical comparison of the EU Low Voltage Directive (LVD) 2014/35/EU and the EMC Directive 2014/30/EU. - [EU LVD vs Machinery Regulation | Low Voltage Directive 2014/35/EU vs Machinery Regulation (EU) 2023/1230 | Electrical Risks and CE Evidence](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation.md): A practical overlap guide for Low Voltage Directive (LVD) 2014/35/EU and Machinery Regulation (EU) 2023/1230: when the product is machinery/related product. - [FAQ | EU Low Voltage Directive (LVD) 2014/35/EU | Scope, CE Marking, Technical File](/artifacts/eu/low-voltage-directive/faq.md): High-signal FAQ for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, do you need a notified body. - [Harmonised Standards | EU Low Voltage Directive (LVD) 2014/35/EU | Presumption of Conformity, OJ Lists, and Update Control](/artifacts/eu/low-voltage-directive/harmonized-standards.md): How harmonised standards work under the EU Low Voltage Directive (LVD) 2014/35/EU: presumption of conformity, Official Journal (OJ) references. - [Penalties and Fines | EU Low Voltage Directive (LVD) 2014/35/EU | Enforcement, Market Surveillance Actions, Risk Reduction](/artifacts/eu/low-voltage-directive/penalties-and-fines.md): Enforcement overview for the EU Low Voltage Directive (LVD) 2014/35/EU: what market surveillance authorities typically ask for. - [Requirements | EU Low Voltage Directive (LVD) 2014/35/EU | Manufacturer, Importer, Distributor Obligations](/artifacts/eu/low-voltage-directive/requirements.md): An implementation-grade requirements breakdown for the EU Low Voltage Directive (LVD) 2014/35/EU: obligations for manufacturers, authorised representatives. - [Scope and Products | EU Low Voltage Directive (LVD) 2014/35/EU | Voltage Limits, Exclusions (Annex II), and Examples](/artifacts/eu/low-voltage-directive/scope-and-products.md): A practical scope guide for the EU Low Voltage Directive 2014/35/EU: voltage limits at 50 to 1000 V AC and 75 to 1500 V DC. - [Technical Documentation (Technical File) | EU Low Voltage Directive (LVD) 2014/35/EU | Annex III Checklist and Structure](/artifacts/eu/low-voltage-directive/technical-documentation.md): Build an audit-ready LVD technical file for Directive 2014/35/EU: Annex III elements (product description, drawings/schematics, explanations, standards list. - [Templates | EU Low Voltage Directive (LVD) 2014/35/EU | Technical File Index, DoC Skeleton, Scope Memo, Evidence Pack](/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template.md): Copy/paste templates for EU Low Voltage Directive (LVD) 2014/35/EU compliance: scope memo (voltage + Annex II exclusions + overlap). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/low-voltage-directive/checklist --- --- title: "Compliance Program" canonical_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/compliance" source_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/compliance" author: "Sorena AI" description: "Build a scalable compliance program for EU Low Voltage Directive (LVD) 2014/35/EU: product family strategy, scope control, Annex I hazard mapping." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Low Voltage Directive compliance program" - "LVD compliance operating model" - "CE marking governance electrical equipment" - "LVD technical file process" - "LVD declaration of conformity workflow" - "LVD post market surveillance" - "compliance program" - "CE marking" - "governance" - "technical file" - "post-market" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Compliance Program Build a scalable compliance program for EU Low Voltage Directive (LVD) 2014/35/EU: product family strategy, scope control, Annex I hazard mapping. *Compliance* *EU* ## EU LVD 2014/35/EU Compliance Program Make LVD compliance repeatable across many SKUs. Focus: controls, release gates, evidence management, and post-market readiness. LVD compliance is not a one off certification event. It is a product lifecycle system. If you ship many variants or update hardware and firmware frequently, you need a control model for scope, standards governance, series production conformity, evidence retention, importer support, and corrective action. This page turns the directive and the 2018 LVD Guide into an operating model that scales. ## 1) Start with a product family strategy A product family approach lets you reuse evidence across variants while staying defensible. The key is to define what is genuinely shared and what needs a separate assessment. Output: a matrix of SKUs and variants showing shared design controls, shared standards, and variant specific evidence. - Define common design elements such as insulation system, power architecture, enclosure concept, and protective devices. - Choose representative worst case configurations for thermal, overload, abnormal operation, and foreseeable misuse testing. - Keep one technical file index with variant annexes for labels, instructions, and test deltas. ## 2) Core controls that keep series production compliant Article 6(4) matters as much as the initial assessment: manufacturers must keep procedures in place so series production remains in conformity. Treat each LVD obligation as a control with an owner, evidence location, and release gate. - Scope control for voltage limits, Annex II exclusions, and overlap with EMC, RED, machinery, and other applicable acts. - Annex I hazard map connecting safety objectives to design controls, verification methods, and warning content. - Standards governance with OJ decision references, clause mapping, and update review logs. - Manufacturing and supplier controls for safety critical parts, approved substitutions, and calibration of test equipment. ## 3) Release gate before placing the product on the market Most failures are release failures: the design changed, the DoC was not updated, or the instructions and labels did not match the shipped configuration. Block shipment, listing, or importer handoff until the evidence chain is complete. - Technical documentation updated to the shipped build and reviewed against the current standards register. - Signed DoC matches the shipped product, the applicable legislation list, and the standards actually relied on. - CE marking, manufacturer details, importer details, and any Article 4 economic operator details are present where required. - Instructions and safety information exist in the languages required for each target Member State. ## 4) Supplier, importer, and distributor control Supply chain controls are part of compliance, not an afterthought. Importers and distributors have real verification duties under the directive. You want contracts and operating procedures that make documentation availability routine instead of a scramble. - For safety critical components, define approved parts, substitution rules, and evidence required before change approval. - Importers keep a copy of the DoC for 10 years and ensure the technical documentation can be made available to authorities on request. - Distributors verify CE marking, manufacturer and importer details, and the presence of required instructions and safety information before making products available. - Where appropriate to the risk, importers run sample testing and maintain complaints, non conformities, and recall logs. ## 5) Change control and standards governance Not every standards update triggers immediate retesting, but every relevant change needs a documented impact review. This is especially important after the LVD standards amendments published in 2024 and 2025. - Trigger an impact review for product redesigns, firmware changes affecting safety functions, component substitutions, manufacturing process changes, and new sales markets. - Track implementing decisions such as 2024/1198, 2024/2764, 2025/1457, and 2025/1488, including restrictions and deferred withdrawal dates that may affect presumption of conformity. - Update the standards register, test matrix, DoC, and technical file history when the review concludes that evidence must change. - If you keep using an older standard during a transition window, document why the product remains safe and when migration will happen. ## 6) Post market surveillance readiness A compliant program includes a fast response path for complaints, incidents, and regulator requests. Articles 19 to 22 give authorities a structured escalation path, so your response should be equally structured. The goal is to reduce enforcement interactions to predictable evidence exchanges and corrective actions. - Maintain a response pack with the signed DoC, technical file index, scope memo, key test reports, and translation set. - Run periodic complaint and field issue reviews and decide whether additional testing, withdrawal, or recall planning is needed. - Retain supply chain traceability data for 10 years so affected units can be isolated. - Document named contacts for market surveillance requests, corrective action decisions, and authority communications. *Recommended next step* *Placement: after the compliance steps* ## Turn EU LVD 2014/35/EU Compliance Program into an operational assessment Assessment Autopilot can take EU LVD 2014/35/EU Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU LVD 2014/35/EU can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU LVD 2014/35/EU Compliance Program](/solutions/assessment.md): Start from EU LVD 2014/35/EU Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU LVD 2014/35/EU](/contact.md): Review your current process, evidence gaps, and next steps for EU LVD 2014/35/EU Compliance Program. ## Primary sources - [Directive 2014/35/EU - Low Voltage Directive (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/35/oj?ref=sorena.io) - Primary source for Article 6 manufacturer duties, Article 8 importer duties, Article 9 distributor duties, Annex III technical documentation, and Articles 19 to 24 enforcement mechanics. - [LVD Guidelines (August 2018) - European Commission](https://ec.europa.eu/docsroom/documents/33107?ref=sorena.io) - Practical guidance on components, instruction language responsibility, document holding, and standards governance. - [Regulation (EU) 2019/1020 - Market surveillance and compliance of products (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Article 4 economic operator tasks, online sales targeting, and current market surveillance framework since 16 July 2021. - [Blue Guide 2022 - Commission Notice 2022/C 247/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0628%2804%29&ref=sorena.io) - Cross regime guidance on product families, modification, making available on the market, and simultaneous application of Union acts. ## Related Topic Guides - [Applicability Test | EU Low Voltage Directive (LVD) 2014/35/EU | In Scope or Excluded?](/artifacts/eu/low-voltage-directive/applicability-test.md): A step-by-step applicability test for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, product vs component. - [Checklist | EU Low Voltage Directive (LVD) 2014/35/EU | CE Marking Readiness Checklist (Technical File + DoC)](/artifacts/eu/low-voltage-directive/checklist.md): An audit-ready CE marking checklist for the EU Low Voltage Directive (LVD) 2014/35/EU: scope memo + Annex II exclusions, Annex I safety objectives mapping. - [Conformity Assessment and CE Marking | EU Low Voltage Directive (LVD) 2014/35/EU | Module A, DoC, Technical File](/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce.md): A practical CE marking workflow for EU Low Voltage Directive (LVD) 2014/35/EU: Module A (internal production control), risk assessment. - [Deadlines and Compliance Calendar | EU Low Voltage Directive (LVD) 2014/35/EU | Release Gates, Evidence Cadence, Standards Updates](/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for EU Low Voltage Directive 2014/35/EU: legal milestones from adoption through current application, release gate timing. - [Essential Safety Requirements (Annex I) | EU Low Voltage Directive (LVD) 2014/35/EU | Hazards, Controls, and Test Evidence](/artifacts/eu/low-voltage-directive/essential-safety-requirements.md): Translate EU Low Voltage Directive (LVD) 2014/35/EU Annex I safety objectives into an engineering-ready hazard map: protection against electric shock. - [EU LVD vs EMC Directive | Low Voltage Directive 2014/35/EU vs EMC 2014/30/EU | What Changes for CE Marking?](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive.md): A practical comparison of the EU Low Voltage Directive (LVD) 2014/35/EU and the EMC Directive 2014/30/EU. - [EU LVD vs Machinery Regulation | Low Voltage Directive 2014/35/EU vs Machinery Regulation (EU) 2023/1230 | Electrical Risks and CE Evidence](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation.md): A practical overlap guide for Low Voltage Directive (LVD) 2014/35/EU and Machinery Regulation (EU) 2023/1230: when the product is machinery/related product. - [FAQ | EU Low Voltage Directive (LVD) 2014/35/EU | Scope, CE Marking, Technical File](/artifacts/eu/low-voltage-directive/faq.md): High-signal FAQ for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, do you need a notified body. - [Harmonised Standards | EU Low Voltage Directive (LVD) 2014/35/EU | Presumption of Conformity, OJ Lists, and Update Control](/artifacts/eu/low-voltage-directive/harmonized-standards.md): How harmonised standards work under the EU Low Voltage Directive (LVD) 2014/35/EU: presumption of conformity, Official Journal (OJ) references. - [Penalties and Fines | EU Low Voltage Directive (LVD) 2014/35/EU | Enforcement, Market Surveillance Actions, Risk Reduction](/artifacts/eu/low-voltage-directive/penalties-and-fines.md): Enforcement overview for the EU Low Voltage Directive (LVD) 2014/35/EU: what market surveillance authorities typically ask for. - [Requirements | EU Low Voltage Directive (LVD) 2014/35/EU | Manufacturer, Importer, Distributor Obligations](/artifacts/eu/low-voltage-directive/requirements.md): An implementation-grade requirements breakdown for the EU Low Voltage Directive (LVD) 2014/35/EU: obligations for manufacturers, authorised representatives. - [Scope and Products | EU Low Voltage Directive (LVD) 2014/35/EU | Voltage Limits, Exclusions (Annex II), and Examples](/artifacts/eu/low-voltage-directive/scope-and-products.md): A practical scope guide for the EU Low Voltage Directive 2014/35/EU: voltage limits at 50 to 1000 V AC and 75 to 1500 V DC. - [Technical Documentation (Technical File) | EU Low Voltage Directive (LVD) 2014/35/EU | Annex III Checklist and Structure](/artifacts/eu/low-voltage-directive/technical-documentation.md): Build an audit-ready LVD technical file for Directive 2014/35/EU: Annex III elements (product description, drawings/schematics, explanations, standards list. - [Templates | EU Low Voltage Directive (LVD) 2014/35/EU | Technical File Index, DoC Skeleton, Scope Memo, Evidence Pack](/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template.md): Copy/paste templates for EU Low Voltage Directive (LVD) 2014/35/EU compliance: scope memo (voltage + Annex II exclusions + overlap). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/low-voltage-directive/compliance --- --- title: "Conformity Assessment and CE Marking" canonical_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce" source_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce" author: "Sorena AI" description: "A practical CE marking workflow for EU Low Voltage Directive (LVD) 2014/35/EU: Module A (internal production control), risk assessment." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Low Voltage Directive CE marking" - "LVD conformity assessment Module A" - "EU declaration of conformity LVD" - "LVD technical documentation Annex III" - "Directive 2014/35/EU CE marking steps" - "no notified body LVD" - "LVD traceability labeling" - "CE marking" - "conformity assessment" - "Module A" - "DoC" - "technical documentation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Conformity Assessment and CE Marking A practical CE marking workflow for EU Low Voltage Directive (LVD) 2014/35/EU: Module A (internal production control), risk assessment. *CE Marking* *EU* ## EU LVD 2014/35/EU Conformity Assessment and CE Marking Build the evidence chain from Annex I to CE marking. Output: technical file + EU Declaration of Conformity + CE marking evidence you can retrieve fast. For the LVD, conformity assessment is normally the manufacturer's responsibility under Module A, internal production control. There is no routine notified body route under the directive itself. The real deliverable is an evidence chain that shows how Annex I safety objectives are met, how the technical file supports that conclusion, and how the DoC, CE marking, traceability, and language obligations are controlled at release. ## 1) The LVD conformity assessment model Directive 2014/35/EU uses Module A in Annex III. That means the manufacturer designs the conformity assessment system, performs or commissions the necessary assessment work, and holds the evidence. The main operational question is not whether a certificate exists. It is whether the evidence chain is coherent, current, and accessible. - Start with a scope memo confirming voltage limits, exclusions, and overlap with other acts. - Build an Annex I hazard map and choose the standards or other technical specifications used to meet each relevant safety objective. - Compile Annex III technical documentation and then draw up the DoC and affix CE marking. *Recommended next step* *Placement: after the main workflow section* ## Turn EU LVD 2014/35/EU Conformity Assessment and CE Marking into an operational assessment Assessment Autopilot can take EU LVD 2014/35/EU Conformity Assessment and CE Marking from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on EU LVD 2014/35/EU can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU LVD 2014/35/EU Conformity Assessment and CE Marking](/solutions/assessment.md): Start from EU LVD 2014/35/EU Conformity Assessment and CE Marking and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU LVD 2014/35/EU](/contact.md): Review your current process, evidence gaps, and next steps for EU LVD 2014/35/EU Conformity Assessment and CE Marking. ## 2) Step by step CE workflow Use this as the internal release sequence before shipping or listing products in the EU. Each step should have an owner, evidence location, and go or no go decision. - Confirm product scope and economic operator roles. - Lock the standards register and the test plan based on the actual shipped configuration. - Finish testing, calculations, and risk analysis, then update the technical file index. - Issue and sign the DoC, verify markings and instructions, and archive the release pack. ## 3) Technical documentation as the source of truth Annex III makes the technical documentation the core artifact. It must make it possible to assess conformity and include an adequate analysis and assessment of risk. If the technical file is weak, the DoC and CE mark are weak as well. - Include product description, drawings and schematics, explanations, standards list, calculations, examinations, and test reports where applicable. - Document standards applied in full or in part, and explain alternative solutions where harmonised standards are not used. - Keep the technical file version linked to the exact type, batch, serial logic, and shipped configuration. ## 4) EU Declaration of Conformity The DoC is issued under the sole responsibility of the manufacturer. Under Article 15 it must follow the Annex IV model structure, include the Module A elements, and be continuously updated. For products sold in multiple Member States, plan the translation workflow in the same way you plan instruction translation. - List the product clearly enough to link it to the technical file and the traceability identifiers on the product. - List all applicable Union harmonisation legislation, not only LVD. - Use the same standards references and versions that appear in the standards register and technical file. - Control signatory authority, version history, and translated versions. ## 5) CE marking, traceability, and accompanying information Market surveillance often starts with surface compliance: CE marking, manufacturer and importer details, and instruction language. These are also the easiest issues to prevent. The directive is precise about what must accompany the product and what must merely be held available. - Affix CE visibly, legibly, and indelibly to the product or data plate, or to packaging and documents where the product nature does not allow it. - Mark the product with type, batch, serial number, or another element that clearly links the unit to the evidence set. - Provide manufacturer and importer names and postal addresses with a single contact point. - Remember that the documents that must accompany the product for importer and distributor checks are the instructions and safety information, not the full technical file. ## 6) Online sales and EU based economic operator coverage Distance selling does not relax product obligations. If the offer targets EU end users, the product is deemed made available on the Union market. For products covered by Article 4 of Regulation (EU) 2019/1020, someone established in the EU must perform the required market surveillance support tasks. - Identify whether the role is carried by the EU manufacturer, importer, authorised representative, or fulfilment service provider. - Ensure the designated operator can keep the DoC available for the required period and ensure technical documentation can be produced on request. - Keep a response pack ready for online platform issues, customs questions, and authority requests. ## Primary sources - [Directive 2014/35/EU - Low Voltage Directive (Annex III Module A, Annex IV DoC model) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/35/oj?ref=sorena.io) - Primary requirements for design/manufacture to meet Annex I objectives, technical documentation content (Annex III), DoC model (Annex IV), retention period, and CE marking rules. - [Blue Guide 2022 - Commission Notice 2022/C 247/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0628%2804%29&ref=sorena.io) - Horizontal guidance on CE marking, conformity assessment modules, and economic operator responsibilities. - [Regulation (EU) 2019/1020 - Market surveillance and compliance of products (Article 4 economic operator tasks; distance sales) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - EU-based economic operator tasks and distance sales concepts relevant to online distribution models. - [European Commission - Low Voltage Directive (LVD) page (Single Market)](https://single-market-economy.ec.europa.eu/sectors/electrical-and-electronic-engineering-industries-eei/low-voltage-directive-lvd_en?ref=sorena.io) - Commission overview and references to standards lists and guidance. ## Related Topic Guides - [Applicability Test | EU Low Voltage Directive (LVD) 2014/35/EU | In Scope or Excluded?](/artifacts/eu/low-voltage-directive/applicability-test.md): A step-by-step applicability test for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, product vs component. - [Checklist | EU Low Voltage Directive (LVD) 2014/35/EU | CE Marking Readiness Checklist (Technical File + DoC)](/artifacts/eu/low-voltage-directive/checklist.md): An audit-ready CE marking checklist for the EU Low Voltage Directive (LVD) 2014/35/EU: scope memo + Annex II exclusions, Annex I safety objectives mapping. - [Compliance Program | EU Low Voltage Directive (LVD) 2014/35/EU | Operating Model, Controls, and Evidence](/artifacts/eu/low-voltage-directive/compliance.md): Build a scalable compliance program for EU Low Voltage Directive (LVD) 2014/35/EU: product family strategy, scope control, Annex I hazard mapping. - [Deadlines and Compliance Calendar | EU Low Voltage Directive (LVD) 2014/35/EU | Release Gates, Evidence Cadence, Standards Updates](/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for EU Low Voltage Directive 2014/35/EU: legal milestones from adoption through current application, release gate timing. - [Essential Safety Requirements (Annex I) | EU Low Voltage Directive (LVD) 2014/35/EU | Hazards, Controls, and Test Evidence](/artifacts/eu/low-voltage-directive/essential-safety-requirements.md): Translate EU Low Voltage Directive (LVD) 2014/35/EU Annex I safety objectives into an engineering-ready hazard map: protection against electric shock. - [EU LVD vs EMC Directive | Low Voltage Directive 2014/35/EU vs EMC 2014/30/EU | What Changes for CE Marking?](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive.md): A practical comparison of the EU Low Voltage Directive (LVD) 2014/35/EU and the EMC Directive 2014/30/EU. - [EU LVD vs Machinery Regulation | Low Voltage Directive 2014/35/EU vs Machinery Regulation (EU) 2023/1230 | Electrical Risks and CE Evidence](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation.md): A practical overlap guide for Low Voltage Directive (LVD) 2014/35/EU and Machinery Regulation (EU) 2023/1230: when the product is machinery/related product. - [FAQ | EU Low Voltage Directive (LVD) 2014/35/EU | Scope, CE Marking, Technical File](/artifacts/eu/low-voltage-directive/faq.md): High-signal FAQ for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, do you need a notified body. - [Harmonised Standards | EU Low Voltage Directive (LVD) 2014/35/EU | Presumption of Conformity, OJ Lists, and Update Control](/artifacts/eu/low-voltage-directive/harmonized-standards.md): How harmonised standards work under the EU Low Voltage Directive (LVD) 2014/35/EU: presumption of conformity, Official Journal (OJ) references. - [Penalties and Fines | EU Low Voltage Directive (LVD) 2014/35/EU | Enforcement, Market Surveillance Actions, Risk Reduction](/artifacts/eu/low-voltage-directive/penalties-and-fines.md): Enforcement overview for the EU Low Voltage Directive (LVD) 2014/35/EU: what market surveillance authorities typically ask for. - [Requirements | EU Low Voltage Directive (LVD) 2014/35/EU | Manufacturer, Importer, Distributor Obligations](/artifacts/eu/low-voltage-directive/requirements.md): An implementation-grade requirements breakdown for the EU Low Voltage Directive (LVD) 2014/35/EU: obligations for manufacturers, authorised representatives. - [Scope and Products | EU Low Voltage Directive (LVD) 2014/35/EU | Voltage Limits, Exclusions (Annex II), and Examples](/artifacts/eu/low-voltage-directive/scope-and-products.md): A practical scope guide for the EU Low Voltage Directive 2014/35/EU: voltage limits at 50 to 1000 V AC and 75 to 1500 V DC. - [Technical Documentation (Technical File) | EU Low Voltage Directive (LVD) 2014/35/EU | Annex III Checklist and Structure](/artifacts/eu/low-voltage-directive/technical-documentation.md): Build an audit-ready LVD technical file for Directive 2014/35/EU: Annex III elements (product description, drawings/schematics, explanations, standards list. - [Templates | EU Low Voltage Directive (LVD) 2014/35/EU | Technical File Index, DoC Skeleton, Scope Memo, Evidence Pack](/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template.md): Copy/paste templates for EU Low Voltage Directive (LVD) 2014/35/EU compliance: scope memo (voltage + Annex II exclusions + overlap). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce --- --- title: "Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A practical compliance calendar for EU Low Voltage Directive 2014/35/EU: legal milestones from adoption through current application, release gate timing." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Low Voltage Directive deadlines" - "LVD compliance calendar" - "LVD timeline" - "CE marking release gate calendar" - "LVD standards update monitoring" - "harmonised standards implementing decisions LVD" - "calendar" - "deadlines" - "release gate" - "standards updates" - "post-market" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Deadlines and Compliance Calendar A practical compliance calendar for EU Low Voltage Directive 2014/35/EU: legal milestones from adoption through current application, release gate timing. *Calendar* *EU* ## EU LVD 2014/35/EU Deadlines and Compliance Calendar A legal and operational calendar for LVD compliance. Focus: key dates since 2014, release gates before market placement, 10 year retention, and standards update monitoring. The LVD has applied since 20 April 2016, but compliance timing is not static. You have legal milestone dates, product release gates before placement on the market, 10 year retention obligations, and a live Official Journal update cycle for harmonised standards. This page combines those dates with a practical operating cadence. ## 1) Legal baseline dates you should know These are the fixed dates that still matter in documentation and transition analysis. They are especially useful when you review older DoCs, legacy stock, or inherited technical files. - 26 February 2014: Directive 2014/35/EU adopted. - 29 March 2014: published in the Official Journal. - 19 April 2016: Member State transposition deadline. - 20 April 2016: Directive 2014/35/EU applies and Directive 2006/95/EC is repealed for new placements on the market. ## 2) Legacy product and declaration timing The transition Q and A remains useful for inherited stock and old documentation. Declarations remain valid according to the legislation in force when the product was first placed on the market. That means you should not rewrite history in old files, but you should clearly separate pre 20 April 2016 and post 20 April 2016 placements. - Products lawfully placed on the market before 20 April 2016 could continue to be made available under the transition rule in Article 25. - Products first placed on the market on or after 20 April 2016 need an EU DoC aligned to Directive 2014/35/EU. - Legacy technical files should record the original placement date and the legal basis used at that time. ## 3) Market surveillance timing since 16 July 2021 Regulation (EU) 2019/1020 replaced the earlier horizontal market surveillance provisions as from 16 July 2021. This matters for online sales, Article 4 operator coverage, and enforcement practice. For LVD teams, the practical effect is that documentation availability and EU based operator coverage should be tested before launch, not after a request arrives. - Before launch: confirm Article 4 coverage where applicable and record who holds that role. - At every launch: create a response pack with the DoC, technical file index, and key reports. - Quarterly: confirm online listings, packaging, and accompanying documents still show the required contact information. ## 4) Harmonised standards update sequence The standards list is not frozen. Your governance process should log the key implementing decisions that publish, amend, restrict, or defer withdrawal of LVD standards references. Use these decisions as review triggers, not automatic retest triggers. - 26 November 2019: Decision (EU) 2019/1956 published the baseline list then used for LVD harmonised standards governance. - 4 May 2022: Decision (EU) 2022/713 amended that baseline for additional appliance and charger standards. - 19 April 2024 and 30 October 2024: Decisions (EU) 2024/1198 and 2024/2764 added updates, withdrawals, and deferred withdrawal dates. - 16 July 2025 and 22 July 2025: Decisions (EU) 2025/1457 and 2025/1488 added restrictions, new references, and further deferred withdrawals. ## 5) Forward looking dates that can force a standards review Some 2024 and 2025 standards decisions defer withdrawal to future dates so manufacturers can adapt. Those future dates should appear in your internal calendar now. If you use one of the affected standards, schedule the migration review well before the withdrawal takes effect. - 24 October 2025: deferred application point in Decision (EU) 2024/1198. - 30 April 2026: deferred application point in Decision (EU) 2024/2764. - 18 January 2027: deferred withdrawal or restriction point in Decision (EU) 2025/1457. - 23 January 2027: deferred withdrawal point in Decision (EU) 2025/1488. ## 6) Internal operating cadence for every product family Alongside legal dates, run a predictable internal rhythm so evidence stays current. This is the cadence that keeps release gates and post market response from drifting. - Pre design: scope memo, applicable legislation list, and initial standards shortlist. - Before design freeze: Annex I hazard map, test matrix, and component control decisions. - Before launch: signed DoC, CE and traceability checks, language complete instructions, and response pack export. - Quarterly or on change: complaints review, standards update review, and impact assessment for product or supplier changes. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU LVD 2014/35/EU Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take EU LVD 2014/35/EU Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU LVD 2014/35/EU can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU LVD 2014/35/EU Deadlines and Compliance Calendar](/solutions/assessment.md): Start from EU LVD 2014/35/EU Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU LVD 2014/35/EU](/contact.md): Review your current process, evidence gaps, and next steps for EU LVD 2014/35/EU Deadlines and Compliance Calendar. ## Primary sources - [Directive 2014/35/EU - LVD legal milestones and transition provisions (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/35/oj?ref=sorena.io) - Source for adoption, publication, transposition, application, repeal, Article 25 transition rule, Annex III retention, and Article 26 transposition timing. - [Transition Q and A on the Low Voltage Directive - European Commission](https://ec.europa.eu/docsroom/documents/11487?ref=sorena.io) - Useful for understanding old versus new declaration timing and the continuing validity of legacy declarations based on first placement on the market. - [Regulation (EU) 2019/1020 - Market surveillance and compliance of products (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Current horizontal market surveillance framework since 16 July 2021. - [Commission Implementing Decisions (EU) 2019/1956, 2022/713, 2024/1198, 2024/2764, 2025/1457, and 2025/1488 (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2019/1956/oj?ref=sorena.io) - Standards publication and amendment sequence used to run LVD OJ update reviews. ## Related Topic Guides - [Applicability Test | EU Low Voltage Directive (LVD) 2014/35/EU | In Scope or Excluded?](/artifacts/eu/low-voltage-directive/applicability-test.md): A step-by-step applicability test for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, product vs component. - [Checklist | EU Low Voltage Directive (LVD) 2014/35/EU | CE Marking Readiness Checklist (Technical File + DoC)](/artifacts/eu/low-voltage-directive/checklist.md): An audit-ready CE marking checklist for the EU Low Voltage Directive (LVD) 2014/35/EU: scope memo + Annex II exclusions, Annex I safety objectives mapping. - [Compliance Program | EU Low Voltage Directive (LVD) 2014/35/EU | Operating Model, Controls, and Evidence](/artifacts/eu/low-voltage-directive/compliance.md): Build a scalable compliance program for EU Low Voltage Directive (LVD) 2014/35/EU: product family strategy, scope control, Annex I hazard mapping. - [Conformity Assessment and CE Marking | EU Low Voltage Directive (LVD) 2014/35/EU | Module A, DoC, Technical File](/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce.md): A practical CE marking workflow for EU Low Voltage Directive (LVD) 2014/35/EU: Module A (internal production control), risk assessment. - [Essential Safety Requirements (Annex I) | EU Low Voltage Directive (LVD) 2014/35/EU | Hazards, Controls, and Test Evidence](/artifacts/eu/low-voltage-directive/essential-safety-requirements.md): Translate EU Low Voltage Directive (LVD) 2014/35/EU Annex I safety objectives into an engineering-ready hazard map: protection against electric shock. - [EU LVD vs EMC Directive | Low Voltage Directive 2014/35/EU vs EMC 2014/30/EU | What Changes for CE Marking?](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive.md): A practical comparison of the EU Low Voltage Directive (LVD) 2014/35/EU and the EMC Directive 2014/30/EU. - [EU LVD vs Machinery Regulation | Low Voltage Directive 2014/35/EU vs Machinery Regulation (EU) 2023/1230 | Electrical Risks and CE Evidence](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation.md): A practical overlap guide for Low Voltage Directive (LVD) 2014/35/EU and Machinery Regulation (EU) 2023/1230: when the product is machinery/related product. - [FAQ | EU Low Voltage Directive (LVD) 2014/35/EU | Scope, CE Marking, Technical File](/artifacts/eu/low-voltage-directive/faq.md): High-signal FAQ for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, do you need a notified body. - [Harmonised Standards | EU Low Voltage Directive (LVD) 2014/35/EU | Presumption of Conformity, OJ Lists, and Update Control](/artifacts/eu/low-voltage-directive/harmonized-standards.md): How harmonised standards work under the EU Low Voltage Directive (LVD) 2014/35/EU: presumption of conformity, Official Journal (OJ) references. - [Penalties and Fines | EU Low Voltage Directive (LVD) 2014/35/EU | Enforcement, Market Surveillance Actions, Risk Reduction](/artifacts/eu/low-voltage-directive/penalties-and-fines.md): Enforcement overview for the EU Low Voltage Directive (LVD) 2014/35/EU: what market surveillance authorities typically ask for. - [Requirements | EU Low Voltage Directive (LVD) 2014/35/EU | Manufacturer, Importer, Distributor Obligations](/artifacts/eu/low-voltage-directive/requirements.md): An implementation-grade requirements breakdown for the EU Low Voltage Directive (LVD) 2014/35/EU: obligations for manufacturers, authorised representatives. - [Scope and Products | EU Low Voltage Directive (LVD) 2014/35/EU | Voltage Limits, Exclusions (Annex II), and Examples](/artifacts/eu/low-voltage-directive/scope-and-products.md): A practical scope guide for the EU Low Voltage Directive 2014/35/EU: voltage limits at 50 to 1000 V AC and 75 to 1500 V DC. - [Technical Documentation (Technical File) | EU Low Voltage Directive (LVD) 2014/35/EU | Annex III Checklist and Structure](/artifacts/eu/low-voltage-directive/technical-documentation.md): Build an audit-ready LVD technical file for Directive 2014/35/EU: Annex III elements (product description, drawings/schematics, explanations, standards list. - [Templates | EU Low Voltage Directive (LVD) 2014/35/EU | Technical File Index, DoC Skeleton, Scope Memo, Evidence Pack](/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template.md): Copy/paste templates for EU Low Voltage Directive (LVD) 2014/35/EU compliance: scope memo (voltage + Annex II exclusions + overlap). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar --- --- title: "Essential Safety Requirements (Annex I)" canonical_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/essential-safety-requirements" source_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/essential-safety-requirements" author: "Sorena AI" description: "Translate EU Low Voltage Directive (LVD) 2014/35/EU Annex I safety objectives into an engineering-ready hazard map: protection against electric shock." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "LVD Annex I safety objectives" - "Low Voltage Directive essential safety requirements" - "Directive 2014/35/EU Annex I" - "electrical safety evidence" - "CE marking electrical safety tests" - "insulation suitability requirements" - "protection against electric shock LVD" - "Annex I" - "safety objectives" - "electrical safety" - "testing" - "technical file" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Essential Safety Requirements (Annex I) Translate EU Low Voltage Directive (LVD) 2014/35/EU Annex I safety objectives into an engineering-ready hazard map: protection against electric shock. *Safety Objectives* *EU* ## EU LVD 2014/35/EU Essential Safety Requirements (Annex I) Turn Annex I into a testable hazard and evidence map. Focus: hazards -> design controls -> verification tests -> technical file evidence. Annex I is the heart of LVD compliance. The 2018 LVD Guide describes the directive as a total harmonised safety regime, meaning it covers all safety aspects of in scope electrical equipment, not only pure electrical hazards. That is why your hazard map must address electric shock, temperature, arcs, radiation, fire, mechanical injury, and risks created by external influences. ## 1) Build the Annex I hazard map first Annex I is easier to apply when you turn it into a mapping table. Start from the product, its use conditions, and foreseeable misuse, then connect each relevant safety objective to the design controls and evidence that support it. Operational output: one mapping table per product family with objective, hazard, control, verification method, and evidence location. - Capture the marked essential characteristics needed for safe use and safe application. - Document safe assembly and connection assumptions for the product and any accessories. - Tie each hazard to a standard clause, calculation, inspection, or test report. ## 2) Protection against hazards arising from the electrical equipment Annex I point 2 focuses on hazards that arise from the equipment itself. That includes direct and indirect contact risks, dangerous temperatures, arcs, radiation, and non electrical dangers caused by the equipment. These are the issues most likely to show up in product testing and incident investigation. - Show how the design prevents direct and indirect contact injuries. - Show how temperatures, arcs, or radiation are kept below dangerous levels. - Show how non electrical dangers such as fire, sharp edges, or moving part injuries are controlled where revealed by experience. - Show that insulation remains suitable under foreseeable conditions. ## 3) External influences matter as much as internal design Annex I point 3 requires protection against hazards caused by external influences on the electrical equipment. This is where many technical files become too abstract. Translate the expected installation, environmental, and overload conditions into explicit assumptions and tests. - Define expected mechanical stress, ambient conditions, ventilation, humidity, and ingress assumptions. - Document overload, surge, abnormal operation, and foreseeable misuse scenarios where relevant. - Align instructions and warnings with the external influence assumptions used in the assessment. ## 4) Standards are useful only if they cover the right hazards Harmonised standards can provide presumption of conformity only for the Annex I objectives they actually cover and only to the extent they are applied. That means the hazard map should lead the standards choice, not the other way around. - List which Annex I objectives each harmonised standard is used for. - If a standard is used only in part, state what gaps remain and how you close them. - If you use no harmonised standard for a hazard, document the alternative technical solution and supporting evidence. ## 5) Instructions and markings are part of the safety solution Annex I starts with safe use conditions and marked essential characteristics. That means labels, instructions, warnings, and installation information are compliance controls, not marketing extras. Poor instructions often convert a technically sound design into a non compliant market product. - Mark the essential characteristics needed for safe use on the product or accompanying documents where appropriate. - Write warnings and limitations directly from the hazard analysis and residual risk decisions. - Ensure translated instructions remain clear, understandable, and intelligible in each target market. ## 6) What good evidence looks like Market surveillance questions are evidence questions. You need to show the reasoning, the control, the test method, and the result. If a reviewer cannot trace that chain quickly, the file is not ready. - Hazard log tied to standards clauses, design decisions, and test IDs. - Test reports with the exact configuration, limits, and acceptance criteria used. - Drawings, schematics, and component data that explain why the design is safe. - Instructions and labels that reflect the same assumptions used in the risk analysis. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU LVD 2014/35/EU Essential Safety Requirements (Annex I) into an operational assessment Assessment Autopilot can take EU LVD 2014/35/EU Essential Safety Requirements (Annex I) from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU LVD 2014/35/EU can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU LVD 2014/35/EU Essential Safety Requirements (Annex I)](/solutions/assessment.md): Start from EU LVD 2014/35/EU Essential Safety Requirements (Annex I) and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU LVD 2014/35/EU](/contact.md): Review your current process, evidence gaps, and next steps for EU LVD 2014/35/EU Essential Safety Requirements (Annex I). ## Primary sources - [Directive 2014/35/EU - Annex I safety objectives (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/35/oj?ref=sorena.io) - Primary legal text for the principal elements of the safety objectives that all in scope electrical equipment must satisfy. - [LVD Guidelines (August 2018) - European Commission](https://ec.europa.eu/docsroom/documents/33107?ref=sorena.io) - Explains the LVD as a total harmonised safety directive and gives practical interpretation support for Annex I application. - [Commission Implementing Decision (EU) 2019/1956 - harmonised standards under LVD (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2019/1956/oj?ref=sorena.io) - Examples of standards references used to support Annex I objectives. - [Blue Guide 2022 - Commission Notice 2022/C 247/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0628%2804%29&ref=sorena.io) - Background on essential requirements, standards use, and technical documentation evidence logic. ## Related Topic Guides - [Applicability Test | EU Low Voltage Directive (LVD) 2014/35/EU | In Scope or Excluded?](/artifacts/eu/low-voltage-directive/applicability-test.md): A step-by-step applicability test for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, product vs component. - [Checklist | EU Low Voltage Directive (LVD) 2014/35/EU | CE Marking Readiness Checklist (Technical File + DoC)](/artifacts/eu/low-voltage-directive/checklist.md): An audit-ready CE marking checklist for the EU Low Voltage Directive (LVD) 2014/35/EU: scope memo + Annex II exclusions, Annex I safety objectives mapping. - [Compliance Program | EU Low Voltage Directive (LVD) 2014/35/EU | Operating Model, Controls, and Evidence](/artifacts/eu/low-voltage-directive/compliance.md): Build a scalable compliance program for EU Low Voltage Directive (LVD) 2014/35/EU: product family strategy, scope control, Annex I hazard mapping. - [Conformity Assessment and CE Marking | EU Low Voltage Directive (LVD) 2014/35/EU | Module A, DoC, Technical File](/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce.md): A practical CE marking workflow for EU Low Voltage Directive (LVD) 2014/35/EU: Module A (internal production control), risk assessment. - [Deadlines and Compliance Calendar | EU Low Voltage Directive (LVD) 2014/35/EU | Release Gates, Evidence Cadence, Standards Updates](/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for EU Low Voltage Directive 2014/35/EU: legal milestones from adoption through current application, release gate timing. - [EU LVD vs EMC Directive | Low Voltage Directive 2014/35/EU vs EMC 2014/30/EU | What Changes for CE Marking?](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive.md): A practical comparison of the EU Low Voltage Directive (LVD) 2014/35/EU and the EMC Directive 2014/30/EU. - [EU LVD vs Machinery Regulation | Low Voltage Directive 2014/35/EU vs Machinery Regulation (EU) 2023/1230 | Electrical Risks and CE Evidence](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation.md): A practical overlap guide for Low Voltage Directive (LVD) 2014/35/EU and Machinery Regulation (EU) 2023/1230: when the product is machinery/related product. - [FAQ | EU Low Voltage Directive (LVD) 2014/35/EU | Scope, CE Marking, Technical File](/artifacts/eu/low-voltage-directive/faq.md): High-signal FAQ for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, do you need a notified body. - [Harmonised Standards | EU Low Voltage Directive (LVD) 2014/35/EU | Presumption of Conformity, OJ Lists, and Update Control](/artifacts/eu/low-voltage-directive/harmonized-standards.md): How harmonised standards work under the EU Low Voltage Directive (LVD) 2014/35/EU: presumption of conformity, Official Journal (OJ) references. - [Penalties and Fines | EU Low Voltage Directive (LVD) 2014/35/EU | Enforcement, Market Surveillance Actions, Risk Reduction](/artifacts/eu/low-voltage-directive/penalties-and-fines.md): Enforcement overview for the EU Low Voltage Directive (LVD) 2014/35/EU: what market surveillance authorities typically ask for. - [Requirements | EU Low Voltage Directive (LVD) 2014/35/EU | Manufacturer, Importer, Distributor Obligations](/artifacts/eu/low-voltage-directive/requirements.md): An implementation-grade requirements breakdown for the EU Low Voltage Directive (LVD) 2014/35/EU: obligations for manufacturers, authorised representatives. - [Scope and Products | EU Low Voltage Directive (LVD) 2014/35/EU | Voltage Limits, Exclusions (Annex II), and Examples](/artifacts/eu/low-voltage-directive/scope-and-products.md): A practical scope guide for the EU Low Voltage Directive 2014/35/EU: voltage limits at 50 to 1000 V AC and 75 to 1500 V DC. - [Technical Documentation (Technical File) | EU Low Voltage Directive (LVD) 2014/35/EU | Annex III Checklist and Structure](/artifacts/eu/low-voltage-directive/technical-documentation.md): Build an audit-ready LVD technical file for Directive 2014/35/EU: Annex III elements (product description, drawings/schematics, explanations, standards list. - [Templates | EU Low Voltage Directive (LVD) 2014/35/EU | Technical File Index, DoC Skeleton, Scope Memo, Evidence Pack](/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template.md): Copy/paste templates for EU Low Voltage Directive (LVD) 2014/35/EU compliance: scope memo (voltage + Annex II exclusions + overlap). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/low-voltage-directive/essential-safety-requirements --- --- title: "FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/faq" source_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/faq" author: "Sorena AI" description: "High-signal FAQ for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, do you need a notified body." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Low Voltage Directive FAQ" - "LVD 2014/35/EU FAQ" - "do I need a notified body for LVD" - "LVD technical file FAQ" - "LVD declaration of conformity FAQ" - "LVD scope exclusions Annex II" - "LVD voltage limits FAQ" - "FAQ" - "LVD" - "CE marking" - "technical documentation" - "scope" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FAQ High-signal FAQ for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, do you need a notified body. *FAQ* *EU* ## EU LVD 2014/35/EU FAQ Clear answers with practical next steps. Use this to unblock engineering, compliance, and operations teams. These answers are written for teams building CE marking evidence packs and technical files, not for academic interpretation. Where questions depend on product specifics, the answers tell you what facts to collect and which artifacts to produce. ## Scope and applicability ## Conformity assessment and notified bodies ## Technical file and document holding ## Instructions, labels, and languages ## Harmonised standards and updates ## Overlap with EMC, RED, and machinery *Recommended next step* *Placement: after the FAQ section* ## Use EU LVD 2014/35/EU FAQ as a cited research workflow Research Copilot can take EU LVD 2014/35/EU FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU LVD 2014/35/EU can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU LVD 2014/35/EU FAQ](/solutions/research-copilot.md): Start from EU LVD 2014/35/EU FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU LVD 2014/35/EU](/contact.md): Review your current process, evidence gaps, and next steps for EU LVD 2014/35/EU FAQ. ## Primary sources - [Directive 2014/35/EU - Low Voltage Directive (Annex II exclusions; Annex III technical documentation; Annex IV DoC model) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/35/oj?ref=sorena.io) - Primary legal text for scope, obligations, technical file elements, DoC model, and CE marking duties. - [Blue Guide 2022 - Commission Notice 2022/C 247/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0628%2804%29&ref=sorena.io) - Horizontal guidance on placing/making available on the market, economic operator roles, and CE marking concepts. - [Commission Implementing Decision (EU) 2019/1956 - harmonised standards under LVD (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2019/1956/oj?ref=sorena.io) - Baseline standards references list publication for presumption of conformity workflows. - [Directive 2014/30/EU - Electromagnetic Compatibility (EMC) Directive (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/30/oj?ref=sorena.io) - Primary text for EMC obligations when products are subject to both LVD and EMC. ## Related Topic Guides - [Applicability Test | EU Low Voltage Directive (LVD) 2014/35/EU | In Scope or Excluded?](/artifacts/eu/low-voltage-directive/applicability-test.md): A step-by-step applicability test for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, product vs component. - [Checklist | EU Low Voltage Directive (LVD) 2014/35/EU | CE Marking Readiness Checklist (Technical File + DoC)](/artifacts/eu/low-voltage-directive/checklist.md): An audit-ready CE marking checklist for the EU Low Voltage Directive (LVD) 2014/35/EU: scope memo + Annex II exclusions, Annex I safety objectives mapping. - [Compliance Program | EU Low Voltage Directive (LVD) 2014/35/EU | Operating Model, Controls, and Evidence](/artifacts/eu/low-voltage-directive/compliance.md): Build a scalable compliance program for EU Low Voltage Directive (LVD) 2014/35/EU: product family strategy, scope control, Annex I hazard mapping. - [Conformity Assessment and CE Marking | EU Low Voltage Directive (LVD) 2014/35/EU | Module A, DoC, Technical File](/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce.md): A practical CE marking workflow for EU Low Voltage Directive (LVD) 2014/35/EU: Module A (internal production control), risk assessment. - [Deadlines and Compliance Calendar | EU Low Voltage Directive (LVD) 2014/35/EU | Release Gates, Evidence Cadence, Standards Updates](/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for EU Low Voltage Directive 2014/35/EU: legal milestones from adoption through current application, release gate timing. - [Essential Safety Requirements (Annex I) | EU Low Voltage Directive (LVD) 2014/35/EU | Hazards, Controls, and Test Evidence](/artifacts/eu/low-voltage-directive/essential-safety-requirements.md): Translate EU Low Voltage Directive (LVD) 2014/35/EU Annex I safety objectives into an engineering-ready hazard map: protection against electric shock. - [EU LVD vs EMC Directive | Low Voltage Directive 2014/35/EU vs EMC 2014/30/EU | What Changes for CE Marking?](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive.md): A practical comparison of the EU Low Voltage Directive (LVD) 2014/35/EU and the EMC Directive 2014/30/EU. - [EU LVD vs Machinery Regulation | Low Voltage Directive 2014/35/EU vs Machinery Regulation (EU) 2023/1230 | Electrical Risks and CE Evidence](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation.md): A practical overlap guide for Low Voltage Directive (LVD) 2014/35/EU and Machinery Regulation (EU) 2023/1230: when the product is machinery/related product. - [Harmonised Standards | EU Low Voltage Directive (LVD) 2014/35/EU | Presumption of Conformity, OJ Lists, and Update Control](/artifacts/eu/low-voltage-directive/harmonized-standards.md): How harmonised standards work under the EU Low Voltage Directive (LVD) 2014/35/EU: presumption of conformity, Official Journal (OJ) references. - [Penalties and Fines | EU Low Voltage Directive (LVD) 2014/35/EU | Enforcement, Market Surveillance Actions, Risk Reduction](/artifacts/eu/low-voltage-directive/penalties-and-fines.md): Enforcement overview for the EU Low Voltage Directive (LVD) 2014/35/EU: what market surveillance authorities typically ask for. - [Requirements | EU Low Voltage Directive (LVD) 2014/35/EU | Manufacturer, Importer, Distributor Obligations](/artifacts/eu/low-voltage-directive/requirements.md): An implementation-grade requirements breakdown for the EU Low Voltage Directive (LVD) 2014/35/EU: obligations for manufacturers, authorised representatives. - [Scope and Products | EU Low Voltage Directive (LVD) 2014/35/EU | Voltage Limits, Exclusions (Annex II), and Examples](/artifacts/eu/low-voltage-directive/scope-and-products.md): A practical scope guide for the EU Low Voltage Directive 2014/35/EU: voltage limits at 50 to 1000 V AC and 75 to 1500 V DC. - [Technical Documentation (Technical File) | EU Low Voltage Directive (LVD) 2014/35/EU | Annex III Checklist and Structure](/artifacts/eu/low-voltage-directive/technical-documentation.md): Build an audit-ready LVD technical file for Directive 2014/35/EU: Annex III elements (product description, drawings/schematics, explanations, standards list. - [Templates | EU Low Voltage Directive (LVD) 2014/35/EU | Technical File Index, DoC Skeleton, Scope Memo, Evidence Pack](/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template.md): Copy/paste templates for EU Low Voltage Directive (LVD) 2014/35/EU compliance: scope memo (voltage + Annex II exclusions + overlap). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/low-voltage-directive/faq --- --- title: "Harmonised Standards" canonical_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/harmonized-standards" source_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/harmonized-standards" author: "Sorena AI" description: "How harmonised standards work under the EU Low Voltage Directive (LVD) 2014/35/EU: presumption of conformity, Official Journal (OJ) references." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "LVD harmonised standards" - "Low Voltage Directive harmonized standards list" - "presumption of conformity LVD" - "Official Journal harmonised standards LVD" - "Commission Implementing Decision 2019/1956 LVD" - "standards update management CE marking" - "harmonised standards" - "presumption of conformity" - "Official Journal" - "CE marking" - "LVD" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Harmonised Standards How harmonised standards work under the EU Low Voltage Directive (LVD) 2014/35/EU: presumption of conformity, Official Journal (OJ) references. *Standards* *EU* ## EU LVD 2014/35/EU Harmonised Standards Use presumption of conformity, but document it correctly. Focus: OJ references, versions, partial application, and update control in your technical file. Harmonised standards are the fastest route to defensible LVD compliance, but only when you treat them as legal references, not just engineering convenience. The LVD Guide is explicit: presumption of conformity exists only when the reference of the harmonised standard is published in the Official Journal, and only to the extent that the referenced standard or part covers the relevant Annex I safety objectives. ## 1) What presumption of conformity really means Presumption of conformity is an evidentiary benefit, not a substitute for scope analysis, design review, or testing. You still need to show that the chosen standard fits the product and that it was actually applied. If the standard is only partially applied, the presumption is only partial as well. - Link each standard to the Annex I objectives and hazards it supports. - Keep test reports, calculations, and design rationale that show how the standard was applied. - Do not rely on guidance documents alone for presumption of conformity. ## 2) Which documents govern the LVD standards list today For current practice, you should read the LVD standards list as a chain of Official Journal implementing decisions rather than a one time publication. The key compliance task is to record which decision set you relied on when assessing the product. - 2019/1956 created the baseline list of LVD harmonised standards references. - 2022/713 added and updated references for specific appliances and charger related standards. - 2024/1198 and 2024/2764 added further references and withdrawals, some with deferred withdrawal dates. - 2025/1457 and 2025/1488 introduced restrictions and new references with future effect dates in 2027. ## 3) Restrictions, withdrawals, and deferred withdrawal dates A standards governance process must track more than new publications. It also needs to capture when a reference is withdrawn, kept only with a restriction, or withdrawn only after a transition period. This is where many LVD files become stale while still appearing complete. - Decision (EU) 2024/1198 deferred certain withdrawals until 24 October 2025. - Decision (EU) 2024/2764 deferred certain withdrawals until 30 April 2026. - Decision (EU) 2025/1457 withdrew the reference to EN 60335-2-60:2003 on a deferred basis and kept EN 60335-1:2012 and EN 60335-2-27:2013 only with restrictions. - Decision (EU) 2025/1488 deferred withdrawal of older flat flexible cable and EV charging cable references until 23 January 2027. ## 4) Full versus partial application Annex III expects the technical file to list harmonised standards applied in full or in part. Partial application is acceptable, but only if you explain the gap honestly and close it with additional evidence. This should be managed at clause level, not only at document title level. - Create a clause mapping table for each relevant standard used. - If a clause is not applied, record why it is not relevant or how another control or test covers the requirement. - Keep the DoC references aligned with the standards register and the technical file history. ## 5) A practical standards governance loop You do not need panic retesting every time the Official Journal changes. You do need a repeatable review loop with a documented outcome. This review should sit in the change control process for every product family. - Trigger an update review when a new OJ decision is published, the product changes, a safety incident occurs, or a key supplier changes. - Assess whether hazards covered, test methods, limits, installation assumptions, labels, or instructions are affected. - Decide whether to adopt immediately, adopt at the next release, or document no impact, and record the reasoning in the file. - Keep a standards register, clause map, update log, and linked test matrix per product family. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU LVD 2014/35/EU Harmonised Standards as a cited research workflow Research Copilot can take EU LVD 2014/35/EU Harmonised Standards from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU LVD 2014/35/EU can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU LVD 2014/35/EU Harmonised Standards](/solutions/research-copilot.md): Start from EU LVD 2014/35/EU Harmonised Standards and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU LVD 2014/35/EU](/contact.md): Review your current process, evidence gaps, and next steps for EU LVD 2014/35/EU Harmonised Standards. ## Primary sources - [Directive 2014/35/EU - Annex III technical documentation requirements (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/35/oj?ref=sorena.io) - Annex III requires listing standards applied in full or in part and documenting alternatives where standards are not used. - [LVD Guidelines (August 2018) - European Commission](https://ec.europa.eu/docsroom/documents/33107?ref=sorena.io) - Explains that presumption of conformity exists only when the standard reference is published in the Official Journal and only for the standard itself. - [Commission Implementing Decision (EU) 2019/1956 (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2019/1956/oj?ref=sorena.io) - Baseline LVD harmonised standards list. - [Commission Implementing Decisions (EU) 2024/1198, 2024/2764, 2025/1457, and 2025/1488 (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2024/1198/oj?ref=sorena.io) - Recent updates showing new references, restrictions, and deferred withdrawals that should be tracked in standards governance. ## Related Topic Guides - [Applicability Test | EU Low Voltage Directive (LVD) 2014/35/EU | In Scope or Excluded?](/artifacts/eu/low-voltage-directive/applicability-test.md): A step-by-step applicability test for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, product vs component. - [Checklist | EU Low Voltage Directive (LVD) 2014/35/EU | CE Marking Readiness Checklist (Technical File + DoC)](/artifacts/eu/low-voltage-directive/checklist.md): An audit-ready CE marking checklist for the EU Low Voltage Directive (LVD) 2014/35/EU: scope memo + Annex II exclusions, Annex I safety objectives mapping. - [Compliance Program | EU Low Voltage Directive (LVD) 2014/35/EU | Operating Model, Controls, and Evidence](/artifacts/eu/low-voltage-directive/compliance.md): Build a scalable compliance program for EU Low Voltage Directive (LVD) 2014/35/EU: product family strategy, scope control, Annex I hazard mapping. - [Conformity Assessment and CE Marking | EU Low Voltage Directive (LVD) 2014/35/EU | Module A, DoC, Technical File](/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce.md): A practical CE marking workflow for EU Low Voltage Directive (LVD) 2014/35/EU: Module A (internal production control), risk assessment. - [Deadlines and Compliance Calendar | EU Low Voltage Directive (LVD) 2014/35/EU | Release Gates, Evidence Cadence, Standards Updates](/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for EU Low Voltage Directive 2014/35/EU: legal milestones from adoption through current application, release gate timing. - [Essential Safety Requirements (Annex I) | EU Low Voltage Directive (LVD) 2014/35/EU | Hazards, Controls, and Test Evidence](/artifacts/eu/low-voltage-directive/essential-safety-requirements.md): Translate EU Low Voltage Directive (LVD) 2014/35/EU Annex I safety objectives into an engineering-ready hazard map: protection against electric shock. - [EU LVD vs EMC Directive | Low Voltage Directive 2014/35/EU vs EMC 2014/30/EU | What Changes for CE Marking?](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive.md): A practical comparison of the EU Low Voltage Directive (LVD) 2014/35/EU and the EMC Directive 2014/30/EU. - [EU LVD vs Machinery Regulation | Low Voltage Directive 2014/35/EU vs Machinery Regulation (EU) 2023/1230 | Electrical Risks and CE Evidence](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation.md): A practical overlap guide for Low Voltage Directive (LVD) 2014/35/EU and Machinery Regulation (EU) 2023/1230: when the product is machinery/related product. - [FAQ | EU Low Voltage Directive (LVD) 2014/35/EU | Scope, CE Marking, Technical File](/artifacts/eu/low-voltage-directive/faq.md): High-signal FAQ for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, do you need a notified body. - [Penalties and Fines | EU Low Voltage Directive (LVD) 2014/35/EU | Enforcement, Market Surveillance Actions, Risk Reduction](/artifacts/eu/low-voltage-directive/penalties-and-fines.md): Enforcement overview for the EU Low Voltage Directive (LVD) 2014/35/EU: what market surveillance authorities typically ask for. - [Requirements | EU Low Voltage Directive (LVD) 2014/35/EU | Manufacturer, Importer, Distributor Obligations](/artifacts/eu/low-voltage-directive/requirements.md): An implementation-grade requirements breakdown for the EU Low Voltage Directive (LVD) 2014/35/EU: obligations for manufacturers, authorised representatives. - [Scope and Products | EU Low Voltage Directive (LVD) 2014/35/EU | Voltage Limits, Exclusions (Annex II), and Examples](/artifacts/eu/low-voltage-directive/scope-and-products.md): A practical scope guide for the EU Low Voltage Directive 2014/35/EU: voltage limits at 50 to 1000 V AC and 75 to 1500 V DC. - [Technical Documentation (Technical File) | EU Low Voltage Directive (LVD) 2014/35/EU | Annex III Checklist and Structure](/artifacts/eu/low-voltage-directive/technical-documentation.md): Build an audit-ready LVD technical file for Directive 2014/35/EU: Annex III elements (product description, drawings/schematics, explanations, standards list. - [Templates | EU Low Voltage Directive (LVD) 2014/35/EU | Technical File Index, DoC Skeleton, Scope Memo, Evidence Pack](/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template.md): Copy/paste templates for EU Low Voltage Directive (LVD) 2014/35/EU compliance: scope memo (voltage + Annex II exclusions + overlap). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/low-voltage-directive/harmonized-standards --- --- title: "EU LVD vs EMC Directive" canonical_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive" source_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive" author: "Sorena AI" description: "A practical comparison of the EU Low Voltage Directive (LVD) 2014/35/EU and the EMC Directive 2014/30/EU." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "LVD vs EMC Directive" - "Low Voltage Directive vs EMC Directive" - "Directive 2014/35/EU vs 2014/30/EU" - "CE marking LVD and EMC" - "multi directive declaration of conformity" - "LVD EMC testing strategy" - "LVD" - "EMC" - "comparison" - "CE marking" - "multi-directive" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU LVD vs EMC Directive A practical comparison of the EU Low Voltage Directive (LVD) 2014/35/EU and the EMC Directive 2014/30/EU. *Comparison* *EU* ## EU LVD vs EMC What changes operationally for CE marking Most electrical products must satisfy both safety and EMC. This page shows how to structure one technical file and DoC that covers both. LVD and EMC are complementary and often simultaneous. LVD addresses safety hazards such as shock, overheating, insulation, and external influences. EMC addresses emissions and immunity so the apparatus does not create or suffer unacceptable disturbance. The practical answer is not two separate compliance programs, but one technical file with two evidence threads and one DoC listing both acts when both apply. ## 1) What each directive covers (one-sentence test) LVD: safety objectives for electrical equipment within certain voltage limits (Annex I). EMC: electromagnetic disturbance and immunity requirements for apparatus and (in some contexts) fixed installations. - If the hazard is electric shock, overheating, insulation failure -> LVD evidence. - If the hazard is interference with other equipment or susceptibility -> EMC evidence. - Many products must satisfy both, and the CE mark signals conformity with all applicable acts listed in the DoC. ## 2) When both apply (typical product patterns) A mains-powered product that contains electronics will almost always have both safety hazards and EMC behaviors. Even simple devices can require EMC consideration if they contain switching power supplies or digital circuits. - Mains-powered consumer appliances and IT equipment. - Industrial control gear, power supplies, chargers, lighting control gear. - Products with external PSUs: both the PSU and the final apparatus may have EMC duties depending on architecture. ## 3) One technical file, two evidence threads (how to avoid duplication) Build one technical documentation index and tag evidence as LVD, EMC, or both. Use shared artifacts (product description, schematics, BOM, risk assessment) and attach directive-specific test evidence. Operational output: a test matrix with LVD/EMC columns and evidence IDs. - Shared: product description, schematics, critical components list, change history. - LVD thread: Annex I safety objectives mapping, safety tests, insulation and temperature evidence, instructions warnings. - EMC thread: emissions and immunity test plans/reports, configuration control, installation environment assumptions. ## 4) DoC and labeling (how to write the combined compliance statement) The DoC should list all applicable Union harmonisation legislation and reference standards used for each. This prevents 'partial compliance' accusations. Control: DoC must be updated when legislation or standards references change. - DoC lists LVD 2014/35/EU and EMC 2014/30/EU when both apply. - Standards references in DoC match standards register and clause mapping in the technical file. - CE marking and traceability labels are consistent across product/packaging/accompanying documents. ## 5) Testing strategy (practical planning) Plan tests together because design decisions (filters, grounding, enclosure materials) can affect both safety and EMC. Avoid last-minute EMC fixes that create safety or thermal issues. - Define representative worst-case configurations for both safety and EMC. - Freeze critical components and firmware versions for test reproducibility. - If you change power architecture, rerun an impact review for both directives. *Recommended next step* *Placement: after the comparison section* ## Use EU LVD vs EMC What changes operationally for CE marking as a cited research workflow Research Copilot can take EU LVD vs EMC What changes operationally for CE marking from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU LVD vs EMC can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU LVD vs EMC What changes operationally for CE marking](/solutions/research-copilot.md): Start from EU LVD vs EMC What changes operationally for CE marking and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU LVD vs EMC](/contact.md): Review your current process, evidence gaps, and next steps for EU LVD vs EMC What changes operationally for CE marking. ## Primary sources - [Directive 2014/35/EU - Low Voltage Directive (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/35/oj?ref=sorena.io) - Primary LVD scope and Annex I safety objectives. - [Directive 2014/30/EU - EMC Directive (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/30/oj?ref=sorena.io) - Primary EMC requirements for emissions and immunity. - [Blue Guide 2022 - Commission Notice 2022/C 247/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0628%2804%29&ref=sorena.io) - Guidance on simultaneous application of Union harmonisation acts and what CE marking indicates. ## Related Topic Guides - [Applicability Test | EU Low Voltage Directive (LVD) 2014/35/EU | In Scope or Excluded?](/artifacts/eu/low-voltage-directive/applicability-test.md): A step-by-step applicability test for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, product vs component. - [Checklist | EU Low Voltage Directive (LVD) 2014/35/EU | CE Marking Readiness Checklist (Technical File + DoC)](/artifacts/eu/low-voltage-directive/checklist.md): An audit-ready CE marking checklist for the EU Low Voltage Directive (LVD) 2014/35/EU: scope memo + Annex II exclusions, Annex I safety objectives mapping. - [Compliance Program | EU Low Voltage Directive (LVD) 2014/35/EU | Operating Model, Controls, and Evidence](/artifacts/eu/low-voltage-directive/compliance.md): Build a scalable compliance program for EU Low Voltage Directive (LVD) 2014/35/EU: product family strategy, scope control, Annex I hazard mapping. - [Conformity Assessment and CE Marking | EU Low Voltage Directive (LVD) 2014/35/EU | Module A, DoC, Technical File](/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce.md): A practical CE marking workflow for EU Low Voltage Directive (LVD) 2014/35/EU: Module A (internal production control), risk assessment. - [Deadlines and Compliance Calendar | EU Low Voltage Directive (LVD) 2014/35/EU | Release Gates, Evidence Cadence, Standards Updates](/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for EU Low Voltage Directive 2014/35/EU: legal milestones from adoption through current application, release gate timing. - [Essential Safety Requirements (Annex I) | EU Low Voltage Directive (LVD) 2014/35/EU | Hazards, Controls, and Test Evidence](/artifacts/eu/low-voltage-directive/essential-safety-requirements.md): Translate EU Low Voltage Directive (LVD) 2014/35/EU Annex I safety objectives into an engineering-ready hazard map: protection against electric shock. - [EU LVD vs Machinery Regulation | Low Voltage Directive 2014/35/EU vs Machinery Regulation (EU) 2023/1230 | Electrical Risks and CE Evidence](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation.md): A practical overlap guide for Low Voltage Directive (LVD) 2014/35/EU and Machinery Regulation (EU) 2023/1230: when the product is machinery/related product. - [FAQ | EU Low Voltage Directive (LVD) 2014/35/EU | Scope, CE Marking, Technical File](/artifacts/eu/low-voltage-directive/faq.md): High-signal FAQ for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, do you need a notified body. - [Harmonised Standards | EU Low Voltage Directive (LVD) 2014/35/EU | Presumption of Conformity, OJ Lists, and Update Control](/artifacts/eu/low-voltage-directive/harmonized-standards.md): How harmonised standards work under the EU Low Voltage Directive (LVD) 2014/35/EU: presumption of conformity, Official Journal (OJ) references. - [Penalties and Fines | EU Low Voltage Directive (LVD) 2014/35/EU | Enforcement, Market Surveillance Actions, Risk Reduction](/artifacts/eu/low-voltage-directive/penalties-and-fines.md): Enforcement overview for the EU Low Voltage Directive (LVD) 2014/35/EU: what market surveillance authorities typically ask for. - [Requirements | EU Low Voltage Directive (LVD) 2014/35/EU | Manufacturer, Importer, Distributor Obligations](/artifacts/eu/low-voltage-directive/requirements.md): An implementation-grade requirements breakdown for the EU Low Voltage Directive (LVD) 2014/35/EU: obligations for manufacturers, authorised representatives. - [Scope and Products | EU Low Voltage Directive (LVD) 2014/35/EU | Voltage Limits, Exclusions (Annex II), and Examples](/artifacts/eu/low-voltage-directive/scope-and-products.md): A practical scope guide for the EU Low Voltage Directive 2014/35/EU: voltage limits at 50 to 1000 V AC and 75 to 1500 V DC. - [Technical Documentation (Technical File) | EU Low Voltage Directive (LVD) 2014/35/EU | Annex III Checklist and Structure](/artifacts/eu/low-voltage-directive/technical-documentation.md): Build an audit-ready LVD technical file for Directive 2014/35/EU: Annex III elements (product description, drawings/schematics, explanations, standards list. - [Templates | EU Low Voltage Directive (LVD) 2014/35/EU | Technical File Index, DoC Skeleton, Scope Memo, Evidence Pack](/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template.md): Copy/paste templates for EU Low Voltage Directive (LVD) 2014/35/EU compliance: scope memo (voltage + Annex II exclusions + overlap). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive --- --- title: "EU LVD vs Machinery Regulation" canonical_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation" source_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation" author: "Sorena AI" description: "A practical overlap guide for Low Voltage Directive (LVD) 2014/35/EU and Machinery Regulation (EU) 2023/1230: when the product is machinery/related product." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "LVD vs Machinery Regulation" - "Low Voltage Directive vs Machinery Regulation 2023/1230" - "electrical risks machinery regulation" - "CE marking machinery electrical safety" - "conformity assessment electrical risks machinery" - "LVD safety objectives machinery" - "LVD" - "machinery regulation" - "overlap" - "electrical risks" - "CE marking" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU LVD vs Machinery Regulation A practical overlap guide for Low Voltage Directive (LVD) 2014/35/EU and Machinery Regulation (EU) 2023/1230: when the product is machinery/related product. *Overlap* *EU* ## EU LVD vs Machinery Regulation Electrical risks and evidence packs Avoid duplicate compliance by knowing what governs what. Focus: machinery/related products with an electricity supply and how electrical safety objectives are handled. LVD is a directive for electrical equipment within certain voltage limits. Machinery Regulation (EU) 2023/1230 is a product safety regime for machinery and related products. The overlap matters because electrical safety objectives still have to be met, but the governing conformity assessment path can sit under the machinery regime rather than a standalone LVD path for the same product. ## 1) The fast decision: is your product machinery/related product or standalone electrical equipment? If your product is a standalone piece of electrical equipment (e.g., power supply, control gear) sold as such, LVD is typically the primary safety directive for electrical hazards (plus EMC/RED where applicable). If your product is machinery or a related product, machinery rules can govern electrical risk conformity assessment and market placement obligations. - Standalone electrical equipment: LVD evidence pack (Annex I mapping, Annex III technical file, DoC, CE marking). - Machinery/related product: machinery evidence pack, with electrical hazards treated under machinery regime requirements. ## 2) Electrical safety objectives vs conformity assessment governance (the key nuance) Machinery rules can incorporate electrical safety objectives while still controlling the conformity assessment and placing on the market process for electrical risks. Operational implication: you should not run two separate conformity assessments for the same electrical risks; you should run the governing one and ensure the safety objectives are met and evidenced. - Document the governing regime in your scope memo and technical file index. - Map electrical hazards to the correct requirement set and tests under the governing regime. - Ensure the DoC lists applicable legislation correctly and consistently. *Recommended next step* *Placement: after the comparison section* ## Use EU LVD vs Machinery Regulation Electrical risks and evidence packs as a cited research workflow Research Copilot can take EU LVD vs Machinery Regulation Electrical risks and evidence packs from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU LVD vs Machinery Regulation can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU LVD vs Machinery Regulation Electrical risks and evidence packs](/solutions/research-copilot.md): Start from EU LVD vs Machinery Regulation Electrical risks and evidence packs and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU LVD vs Machinery Regulation](/contact.md): Review your current process, evidence gaps, and next steps for EU LVD vs Machinery Regulation Electrical risks and evidence packs. ## 3) Evidence pack implications (how to keep one coherent file) The biggest risk in overlap cases is an incoherent evidence pack: safety tests referenced under one regime, DoC referencing another, and missing traceability/labeling artifacts. Solve this by building a single index and tagging evidence by requirement origin (machinery vs LVD objectives) while keeping one narrative. - Single product description, drawings, schematics, and critical components list. - Single hazard log with electrical hazards clearly mapped to the governing requirements set. - Single change control log and response pack export. ## 4) Common scenarios and recommended approach Use these patterns to structure your internal guidance for product teams. If you are unsure, default to documenting product type classification and obtaining specialist review early - before testing and documentation are finalized. - Complete machine with integrated electrical system: treat as machinery; document electrical hazard controls within machinery evidence pack. - Electrical control panel sold separately as equipment: treat as electrical equipment (LVD + EMC). - Component/part sold only as part of machinery: document within machinery regime as relevant; don't assume separate LVD pack is needed. ## Primary sources - [Regulation (EU) 2023/1230 - Machinery Regulation (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/oj?ref=sorena.io) - Primary machinery regime; includes electrical supply risk requirements and clarifies governance of conformity assessment and placing on the market for electrical risks. - [Directive 2014/35/EU - Low Voltage Directive (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/35/oj?ref=sorena.io) - Primary LVD regime for standalone electrical equipment within certain voltage limits. - [Blue Guide 2022 - Commission Notice 2022/C 247/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0628%2804%29&ref=sorena.io) - Guidance on simultaneous application of Union harmonisation acts and finished products vs combinations of parts. ## Related Topic Guides - [Applicability Test | EU Low Voltage Directive (LVD) 2014/35/EU | In Scope or Excluded?](/artifacts/eu/low-voltage-directive/applicability-test.md): A step-by-step applicability test for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, product vs component. - [Checklist | EU Low Voltage Directive (LVD) 2014/35/EU | CE Marking Readiness Checklist (Technical File + DoC)](/artifacts/eu/low-voltage-directive/checklist.md): An audit-ready CE marking checklist for the EU Low Voltage Directive (LVD) 2014/35/EU: scope memo + Annex II exclusions, Annex I safety objectives mapping. - [Compliance Program | EU Low Voltage Directive (LVD) 2014/35/EU | Operating Model, Controls, and Evidence](/artifacts/eu/low-voltage-directive/compliance.md): Build a scalable compliance program for EU Low Voltage Directive (LVD) 2014/35/EU: product family strategy, scope control, Annex I hazard mapping. - [Conformity Assessment and CE Marking | EU Low Voltage Directive (LVD) 2014/35/EU | Module A, DoC, Technical File](/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce.md): A practical CE marking workflow for EU Low Voltage Directive (LVD) 2014/35/EU: Module A (internal production control), risk assessment. - [Deadlines and Compliance Calendar | EU Low Voltage Directive (LVD) 2014/35/EU | Release Gates, Evidence Cadence, Standards Updates](/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for EU Low Voltage Directive 2014/35/EU: legal milestones from adoption through current application, release gate timing. - [Essential Safety Requirements (Annex I) | EU Low Voltage Directive (LVD) 2014/35/EU | Hazards, Controls, and Test Evidence](/artifacts/eu/low-voltage-directive/essential-safety-requirements.md): Translate EU Low Voltage Directive (LVD) 2014/35/EU Annex I safety objectives into an engineering-ready hazard map: protection against electric shock. - [EU LVD vs EMC Directive | Low Voltage Directive 2014/35/EU vs EMC 2014/30/EU | What Changes for CE Marking?](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive.md): A practical comparison of the EU Low Voltage Directive (LVD) 2014/35/EU and the EMC Directive 2014/30/EU. - [FAQ | EU Low Voltage Directive (LVD) 2014/35/EU | Scope, CE Marking, Technical File](/artifacts/eu/low-voltage-directive/faq.md): High-signal FAQ for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, do you need a notified body. - [Harmonised Standards | EU Low Voltage Directive (LVD) 2014/35/EU | Presumption of Conformity, OJ Lists, and Update Control](/artifacts/eu/low-voltage-directive/harmonized-standards.md): How harmonised standards work under the EU Low Voltage Directive (LVD) 2014/35/EU: presumption of conformity, Official Journal (OJ) references. - [Penalties and Fines | EU Low Voltage Directive (LVD) 2014/35/EU | Enforcement, Market Surveillance Actions, Risk Reduction](/artifacts/eu/low-voltage-directive/penalties-and-fines.md): Enforcement overview for the EU Low Voltage Directive (LVD) 2014/35/EU: what market surveillance authorities typically ask for. - [Requirements | EU Low Voltage Directive (LVD) 2014/35/EU | Manufacturer, Importer, Distributor Obligations](/artifacts/eu/low-voltage-directive/requirements.md): An implementation-grade requirements breakdown for the EU Low Voltage Directive (LVD) 2014/35/EU: obligations for manufacturers, authorised representatives. - [Scope and Products | EU Low Voltage Directive (LVD) 2014/35/EU | Voltage Limits, Exclusions (Annex II), and Examples](/artifacts/eu/low-voltage-directive/scope-and-products.md): A practical scope guide for the EU Low Voltage Directive 2014/35/EU: voltage limits at 50 to 1000 V AC and 75 to 1500 V DC. - [Technical Documentation (Technical File) | EU Low Voltage Directive (LVD) 2014/35/EU | Annex III Checklist and Structure](/artifacts/eu/low-voltage-directive/technical-documentation.md): Build an audit-ready LVD technical file for Directive 2014/35/EU: Annex III elements (product description, drawings/schematics, explanations, standards list. - [Templates | EU Low Voltage Directive (LVD) 2014/35/EU | Technical File Index, DoC Skeleton, Scope Memo, Evidence Pack](/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template.md): Copy/paste templates for EU Low Voltage Directive (LVD) 2014/35/EU compliance: scope memo (voltage + Annex II exclusions + overlap). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation --- --- title: "Templates" canonical_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template" source_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template" author: "Sorena AI" description: "Copy/paste templates for EU Low Voltage Directive (LVD) 2014/35/EU compliance: scope memo (voltage + Annex II exclusions + overlap)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "LVD template" - "EU Low Voltage Directive templates" - "LVD technical file template" - "Annex III technical documentation index template" - "EU declaration of conformity template LVD" - "LVD scope memo template" - "LVD evidence pack template" - "templates" - "technical file" - "DoC" - "scope memo" - "evidence pack" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Templates Copy/paste templates for EU Low Voltage Directive (LVD) 2014/35/EU compliance: scope memo (voltage + Annex II exclusions + overlap). *Templates* *EU* ## EU LVD 2014/35/EU Templates Reusable artifacts for CE marking evidence packs. Copy/paste these into your technical file system and keep them versioned. These templates are designed to match how authorities and auditors actually review evidence: fast scope rationale, clear standards versions, hazard-to-test traceability, and an exportable technical file index. Use them per product family and link every field to evidence locations. ## 1) Scope memo template (one page per product family) Purpose: a defensible scope decision (voltage limits + Annex II exclusions + overlap list). - Product identification: model, variants, photos, intended use, target markets, and online sales channels. - Voltage: rated input, frequency, power architecture, external power supply strategy, and whether the marketed item is a finished product or component. - Scope outcome: in scope, excluded, or handled under another regime, with reasons. - Annex II exclusions checked: list each exclusion and mark not applicable with a short rationale. - Overlap list: LVD, EMC, RED, machinery, and Article 4 operator coverage where relevant. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU LVD 2014/35/EU Templates in one governed evidence system SSOT can take EU LVD 2014/35/EU Templates from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU LVD 2014/35/EU can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU LVD 2014/35/EU Templates](/solutions/ssot.md): Start from EU LVD 2014/35/EU Templates and keep documents, evidence, and control records in one governed system. - [Talk through EU LVD 2014/35/EU](/contact.md): Review your current process, evidence gaps, and next steps for EU LVD 2014/35/EU Templates. ## 2) Annex I mapping table (objective -> hazard -> control -> test -> evidence ID) Purpose: turn safety objectives into an engineering-ready and reviewable evidence map. - Safety objective (Annex I) | Hazard | Design control | Verification method | Test/report ID | Residual risk + warning (if any) - Include non-electrical hazards caused by the equipment (fire, mechanical hazards, sharp edges). - Reference standards clauses (full or partial application) next to each control/test. ## 3) Standards register + update review log template Purpose: manage harmonised standards like controls and document update decisions. - Standard | Edition or amendment set | OJ decision reference | Hazards covered | Applied fully? | Clauses applied | Evidence IDs | Notes - Update log: decision reference | date checked | restrictions or withdrawal dates | impact summary | decision | owner | due date ## 4) Test plan outline (make test evidence reproducible) Purpose: define configurations, limits, and acceptance criteria before you test. - Configurations tested: worst-case thermal, worst-case insulation, overload/abnormal conditions as applicable. - Environmental assumptions: temperature, humidity, installation, duty cycle, ventilation, IP rating assumptions. - Tests by hazard: dielectric strength, leakage current/touch current, temperature rise, mechanical strength, abnormal operation, etc. (as applicable). - Acceptance criteria: standard clause limits and internal criteria; deviations and rationale. ## 5) Annex III technical documentation index template Purpose: an exportable index that makes the technical file reviewable in minutes. - 00-Index with scope memo, applicable legislation list, and file index. - 01-Design with drawings, schematics, BOM, and critical components list. - 02-Risk with hazard log, Annex I mapping table, and residual risk decisions. - 03-Standards with register, clause mapping, and update review logs. - 04-Verification with test plan, test reports, and calculations or examinations. - 05-Labels-and-Instructions with labels, safety info, and translations. - 06-DoC with signed DoC, version history, and importer access notes. ## 6) EU Declaration of Conformity (DoC) skeleton (Annex IV-aligned) Purpose: a DoC that matches the technical file and can be kept continuously updated. - Product model identification and description linked to type, batch, or serial logic. - Manufacturer name and address, authorised representative if any, and Article 4 operator if relevant for the marketed product. - Statement that the declaration is issued under the sole responsibility of the manufacturer. - Applicable Union harmonisation legislation list, not just the LVD. - Standards and other technical specifications with versions and amendment sets. - Signatory name, function, place, date, signature, and translation control record. ## 7) Market surveillance response pack checklist (what to export on request) Purpose: a predictable, fast response that reduces escalation risk. - Signed DoC and version history. - Technical file index and scope memo. - Key test reports, hazard mapping summary, and standards register extract. - Labels, instructions, and translation set for affected markets. - Single contact point, response timeline commitment, and corrective action log if already opened. ## Primary sources - [Directive 2014/35/EU - Annex III (technical documentation) and Annex IV (DoC model) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/35/oj?ref=sorena.io) - Defines required technical documentation elements, DoC structure, and evidence retention obligations. - [Blue Guide 2022 - Commission Notice 2022/C 247/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0628%2804%29&ref=sorena.io) - Guidance on technical documentation, CE marking concepts, and multi-legislation compliance statements. ## Related Topic Guides - [Applicability Test | EU Low Voltage Directive (LVD) 2014/35/EU | In Scope or Excluded?](/artifacts/eu/low-voltage-directive/applicability-test.md): A step-by-step applicability test for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, product vs component. - [Checklist | EU Low Voltage Directive (LVD) 2014/35/EU | CE Marking Readiness Checklist (Technical File + DoC)](/artifacts/eu/low-voltage-directive/checklist.md): An audit-ready CE marking checklist for the EU Low Voltage Directive (LVD) 2014/35/EU: scope memo + Annex II exclusions, Annex I safety objectives mapping. - [Compliance Program | EU Low Voltage Directive (LVD) 2014/35/EU | Operating Model, Controls, and Evidence](/artifacts/eu/low-voltage-directive/compliance.md): Build a scalable compliance program for EU Low Voltage Directive (LVD) 2014/35/EU: product family strategy, scope control, Annex I hazard mapping. - [Conformity Assessment and CE Marking | EU Low Voltage Directive (LVD) 2014/35/EU | Module A, DoC, Technical File](/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce.md): A practical CE marking workflow for EU Low Voltage Directive (LVD) 2014/35/EU: Module A (internal production control), risk assessment. - [Deadlines and Compliance Calendar | EU Low Voltage Directive (LVD) 2014/35/EU | Release Gates, Evidence Cadence, Standards Updates](/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for EU Low Voltage Directive 2014/35/EU: legal milestones from adoption through current application, release gate timing. - [Essential Safety Requirements (Annex I) | EU Low Voltage Directive (LVD) 2014/35/EU | Hazards, Controls, and Test Evidence](/artifacts/eu/low-voltage-directive/essential-safety-requirements.md): Translate EU Low Voltage Directive (LVD) 2014/35/EU Annex I safety objectives into an engineering-ready hazard map: protection against electric shock. - [EU LVD vs EMC Directive | Low Voltage Directive 2014/35/EU vs EMC 2014/30/EU | What Changes for CE Marking?](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive.md): A practical comparison of the EU Low Voltage Directive (LVD) 2014/35/EU and the EMC Directive 2014/30/EU. - [EU LVD vs Machinery Regulation | Low Voltage Directive 2014/35/EU vs Machinery Regulation (EU) 2023/1230 | Electrical Risks and CE Evidence](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation.md): A practical overlap guide for Low Voltage Directive (LVD) 2014/35/EU and Machinery Regulation (EU) 2023/1230: when the product is machinery/related product. - [FAQ | EU Low Voltage Directive (LVD) 2014/35/EU | Scope, CE Marking, Technical File](/artifacts/eu/low-voltage-directive/faq.md): High-signal FAQ for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, do you need a notified body. - [Harmonised Standards | EU Low Voltage Directive (LVD) 2014/35/EU | Presumption of Conformity, OJ Lists, and Update Control](/artifacts/eu/low-voltage-directive/harmonized-standards.md): How harmonised standards work under the EU Low Voltage Directive (LVD) 2014/35/EU: presumption of conformity, Official Journal (OJ) references. - [Penalties and Fines | EU Low Voltage Directive (LVD) 2014/35/EU | Enforcement, Market Surveillance Actions, Risk Reduction](/artifacts/eu/low-voltage-directive/penalties-and-fines.md): Enforcement overview for the EU Low Voltage Directive (LVD) 2014/35/EU: what market surveillance authorities typically ask for. - [Requirements | EU Low Voltage Directive (LVD) 2014/35/EU | Manufacturer, Importer, Distributor Obligations](/artifacts/eu/low-voltage-directive/requirements.md): An implementation-grade requirements breakdown for the EU Low Voltage Directive (LVD) 2014/35/EU: obligations for manufacturers, authorised representatives. - [Scope and Products | EU Low Voltage Directive (LVD) 2014/35/EU | Voltage Limits, Exclusions (Annex II), and Examples](/artifacts/eu/low-voltage-directive/scope-and-products.md): A practical scope guide for the EU Low Voltage Directive 2014/35/EU: voltage limits at 50 to 1000 V AC and 75 to 1500 V DC. - [Technical Documentation (Technical File) | EU Low Voltage Directive (LVD) 2014/35/EU | Annex III Checklist and Structure](/artifacts/eu/low-voltage-directive/technical-documentation.md): Build an audit-ready LVD technical file for Directive 2014/35/EU: Annex III elements (product description, drawings/schematics, explanations, standards list. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template --- --- title: "Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/penalties-and-fines" author: "Sorena AI" description: "Enforcement overview for the EU Low Voltage Directive (LVD) 2014/35/EU: what market surveillance authorities typically ask for." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Low Voltage Directive penalties" - "LVD fines" - "LVD enforcement" - "market surveillance electrical equipment" - "LVD recall withdrawal" - "Directive 2014/35/EU penalties" - "Regulation 2019/1020 market surveillance penalties" - "penalties" - "enforcement" - "market surveillance" - "recall" - "corrective action" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Penalties and Fines Enforcement overview for the EU Low Voltage Directive (LVD) 2014/35/EU: what market surveillance authorities typically ask for. *Enforcement* *EU* ## EU LVD 2014/35/EU Penalties and Fines Penalties are national, but the enforcement path is predictable. Focus: market surveillance requests, corrective actions, and how to reduce risk with evidence. The directive does not create one EU wide fine table. Article 24 leaves penalties to Member State law, with the usual requirement that they be effective, proportionate, and dissuasive. What is harmonised is the enforcement path: Articles 19 to 22 describe how authorities react to risky products, compliant products that still present a risk, and formal non compliance such as missing CE marking, bad DoCs, or incomplete technical documentation. ## 1) Article 19: non compliant product presenting a risk If a national authority has sufficient reason to believe the product presents a risk, it evaluates the product against the directive and can require corrective action, withdrawal, or recall. The relevant economic operator must cooperate and ensure the corrective action reaches all affected products made available across the Union. - Authorities can ask for documentation, test evidence, traceability data, and corrective action plans. - If the operator does not act adequately, the authority can prohibit or restrict marketing, withdraw the product, or require recall. - If the issue is not limited to one Member State, the case is notified to the Commission and other Member States. ## 2) Article 20 and Article 21: Union safeguard and compliant but risky products Article 20 deals with disagreement about national measures. The Commission evaluates whether the measure is justified. Article 21 covers the harder case where the product is formally compliant but still presents a risk. That means a technically complete file does not end the inquiry if the product remains unsafe in practice. - A product can face restriction, withdrawal, or recall even when the original conformity assessment looked complete. - The Commission can adopt implementing acts in safeguard cases, including urgent cases. - Field incidents, complaints, and design assumptions that no longer hold can all trigger this path. ## 3) Article 22: formal non compliance findings Article 22 is the checklist authorities use when the problem is formal non compliance rather than an immediate product risk. This is why so many LVD cases start with surface compliance questions. - CE marking missing or incorrectly affixed. - DoC missing or incorrectly drawn up. - Technical documentation missing or incomplete. - Manufacturer or importer information absent, false, or incomplete, or other administrative duties under Articles 6 or 8 not fulfilled. ## 4) What is fixed versus what varies by Member State The fixed part is the duty set by the directive and the possible corrective actions under the market surveillance framework. The variable part is the actual national penalty regime, including whether administrative or criminal penalties are available and how often authorities escalate to them. For multinational teams, keep one universal evidence pack and a short national enforcement note only for priority markets. - Universal: scope memo, DoC, technical file index, standards register, key test reports, labels, and instructions pack. - Market specific: required languages, national authority contact patterns, and local penalty references. - Supply chain specific: make sure importer, distributor, and Article 4 operator responsibilities are operationally assigned. ## 5) Response checklist when an authority contacts you Fast, consistent responses reduce escalation. Slow or inconsistent responses often turn manageable cases into expensive ones. Treat this checklist as part of the release gate, not only as an incident tool. - Freeze the affected configuration and gather the signed DoC, technical file index, and key evidence set. - Confirm the exact operator role answering the request and who else in the chain must be involved. - Check whether the issue is a formal non compliance issue, a real product risk issue, or both. - Document every corrective action decision, communication, and evidence update so the file remains internally consistent. *Recommended next step* *Placement: after the enforcement section* ## Use EU LVD 2014/35/EU Penalties and Fines as a cited research workflow Research Copilot can take EU LVD 2014/35/EU Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU LVD 2014/35/EU can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU LVD 2014/35/EU Penalties and Fines](/solutions/research-copilot.md): Start from EU LVD 2014/35/EU Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU LVD 2014/35/EU](/contact.md): Review your current process, evidence gaps, and next steps for EU LVD 2014/35/EU Penalties and Fines. ## Primary sources - [Directive 2014/35/EU - Articles 19 to 24 (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/35/oj?ref=sorena.io) - Primary source for national risk procedure, Union safeguard procedure, compliant products that present a risk, formal non compliance, and penalties. - [Regulation (EU) 2019/1020 - Market surveillance and compliance of products (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Current horizontal market surveillance powers, including online interface measures and enforcement support mechanisms. - [Blue Guide 2022 - Commission Notice 2022/C 247/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0628%2804%29&ref=sorena.io) - Context on corrective actions, product compliance evidence, and the role of economic operators during enforcement. ## Related Topic Guides - [Applicability Test | EU Low Voltage Directive (LVD) 2014/35/EU | In Scope or Excluded?](/artifacts/eu/low-voltage-directive/applicability-test.md): A step-by-step applicability test for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, product vs component. - [Checklist | EU Low Voltage Directive (LVD) 2014/35/EU | CE Marking Readiness Checklist (Technical File + DoC)](/artifacts/eu/low-voltage-directive/checklist.md): An audit-ready CE marking checklist for the EU Low Voltage Directive (LVD) 2014/35/EU: scope memo + Annex II exclusions, Annex I safety objectives mapping. - [Compliance Program | EU Low Voltage Directive (LVD) 2014/35/EU | Operating Model, Controls, and Evidence](/artifacts/eu/low-voltage-directive/compliance.md): Build a scalable compliance program for EU Low Voltage Directive (LVD) 2014/35/EU: product family strategy, scope control, Annex I hazard mapping. - [Conformity Assessment and CE Marking | EU Low Voltage Directive (LVD) 2014/35/EU | Module A, DoC, Technical File](/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce.md): A practical CE marking workflow for EU Low Voltage Directive (LVD) 2014/35/EU: Module A (internal production control), risk assessment. - [Deadlines and Compliance Calendar | EU Low Voltage Directive (LVD) 2014/35/EU | Release Gates, Evidence Cadence, Standards Updates](/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for EU Low Voltage Directive 2014/35/EU: legal milestones from adoption through current application, release gate timing. - [Essential Safety Requirements (Annex I) | EU Low Voltage Directive (LVD) 2014/35/EU | Hazards, Controls, and Test Evidence](/artifacts/eu/low-voltage-directive/essential-safety-requirements.md): Translate EU Low Voltage Directive (LVD) 2014/35/EU Annex I safety objectives into an engineering-ready hazard map: protection against electric shock. - [EU LVD vs EMC Directive | Low Voltage Directive 2014/35/EU vs EMC 2014/30/EU | What Changes for CE Marking?](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive.md): A practical comparison of the EU Low Voltage Directive (LVD) 2014/35/EU and the EMC Directive 2014/30/EU. - [EU LVD vs Machinery Regulation | Low Voltage Directive 2014/35/EU vs Machinery Regulation (EU) 2023/1230 | Electrical Risks and CE Evidence](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation.md): A practical overlap guide for Low Voltage Directive (LVD) 2014/35/EU and Machinery Regulation (EU) 2023/1230: when the product is machinery/related product. - [FAQ | EU Low Voltage Directive (LVD) 2014/35/EU | Scope, CE Marking, Technical File](/artifacts/eu/low-voltage-directive/faq.md): High-signal FAQ for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, do you need a notified body. - [Harmonised Standards | EU Low Voltage Directive (LVD) 2014/35/EU | Presumption of Conformity, OJ Lists, and Update Control](/artifacts/eu/low-voltage-directive/harmonized-standards.md): How harmonised standards work under the EU Low Voltage Directive (LVD) 2014/35/EU: presumption of conformity, Official Journal (OJ) references. - [Requirements | EU Low Voltage Directive (LVD) 2014/35/EU | Manufacturer, Importer, Distributor Obligations](/artifacts/eu/low-voltage-directive/requirements.md): An implementation-grade requirements breakdown for the EU Low Voltage Directive (LVD) 2014/35/EU: obligations for manufacturers, authorised representatives. - [Scope and Products | EU Low Voltage Directive (LVD) 2014/35/EU | Voltage Limits, Exclusions (Annex II), and Examples](/artifacts/eu/low-voltage-directive/scope-and-products.md): A practical scope guide for the EU Low Voltage Directive 2014/35/EU: voltage limits at 50 to 1000 V AC and 75 to 1500 V DC. - [Technical Documentation (Technical File) | EU Low Voltage Directive (LVD) 2014/35/EU | Annex III Checklist and Structure](/artifacts/eu/low-voltage-directive/technical-documentation.md): Build an audit-ready LVD technical file for Directive 2014/35/EU: Annex III elements (product description, drawings/schematics, explanations, standards list. - [Templates | EU Low Voltage Directive (LVD) 2014/35/EU | Technical File Index, DoC Skeleton, Scope Memo, Evidence Pack](/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template.md): Copy/paste templates for EU Low Voltage Directive (LVD) 2014/35/EU compliance: scope memo (voltage + Annex II exclusions + overlap). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/low-voltage-directive/penalties-and-fines --- --- title: "Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/requirements" source_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/requirements" author: "Sorena AI" description: "An implementation-grade requirements breakdown for the EU Low Voltage Directive (LVD) 2014/35/EU: obligations for manufacturers, authorised representatives." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Low Voltage Directive requirements" - "Directive 2014/35/EU obligations" - "LVD manufacturer obligations" - "LVD importer obligations" - "LVD distributor obligations" - "LVD technical documentation Annex III" - "EU declaration of conformity LVD requirements" - "CE marking LVD requirements" - "requirements" - "manufacturer obligations" - "CE marking" - "technical documentation" - "market surveillance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Requirements An implementation-grade requirements breakdown for the EU Low Voltage Directive (LVD) 2014/35/EU: obligations for manufacturers, authorised representatives. *Requirements* *EU* ## EU LVD 2014/35/EU Requirements A clear duties map across the supply chain. Focus: manufacturers, importers, distributors - and the evidence each must be able to produce. LVD compliance is operational: who must do what, which artifacts must exist, and how quickly those artifacts can be produced when the product is placed on the EU market and throughout its lifecycle. This page turns Directive 2014/35/EU, the 2018 LVD Guide, and Regulation (EU) 2019/1020 into a requirements to evidence map you can apply per product family. ## 1) The three anchors of LVD compliance Most duties under the directive cluster around three anchors: meeting Annex I safety objectives, maintaining the Annex III evidence set, and controlling market placement through the DoC, CE marking, traceability, and instructions. When a program is weak, one of these anchors is usually unowned. - Annex I safety objectives and risk based design evidence. - Annex III technical documentation and 10 year retention. - DoC, CE marking, traceability, accompanying information, and corrective action readiness. ## 2) Manufacturer obligations Manufacturers carry the primary burden under Article 6. They design and manufacture to the Annex I objectives, carry out Module A, draw up the technical file, issue the DoC, and affix CE marking. They also have to maintain conformity in series production, not just at prototype stage. - Design and manufacture in accordance with Article 3 and Annex I. - Draw up Annex III technical documentation, including adequate risk analysis and assessment. - Keep the technical documentation and DoC for 10 years after placement on the market. - Ensure type, batch, serial, manufacturer contact details, instructions, and safety information are correct and present. ## 3) Authorised representative, importer, and distributor obligations The rest of the supply chain has real duties, not just commercial roles. The LVD Guide is especially useful on what importers and distributors must actually verify and hold. This is where many product teams under document their operating model. - Authorised representatives can be mandated to keep the DoC and technical file at the disposal of authorities for 10 years and to cooperate on corrective action. - Importers place only compliant products on the market, keep a copy of the DoC for 10 years, and ensure technical documentation can be obtained on request. - Distributors verify CE marking, manufacturer and importer details, and required instructions and safety information before making the product available. - Importers and distributors must not place or make available products they know or should know are non compliant. ## 4) Instructions, languages, and traceability Instruction and language duties are not cosmetic. They are part of the safety solution and are checked early in enforcement. Traceability duties determine how efficiently you can isolate affected products during corrective action. - Instructions and safety information must be in a language easily understood by consumers and other end users, as determined by the Member State concerned. - Manufacturer and importer postal addresses must identify a single contact point and be understandable to end users and market surveillance authorities. - Type, batch, serial number, or equivalent identifier must link the individual product to the evidence set. - Supply chain counterparties must remain identifiable for 10 years before and after supply. ## 5) Responsible economic operator coverage for EU sales Regulation (EU) 2019/1020 adds an extra operating layer for products within Article 4 scope. For many distance sold products, you need an EU based operator who can support market surveillance requests. This requirement should be solved in the business model, not left for later legal cleanup. - Confirm whether the role is carried by the EU manufacturer, importer, authorised representative, or fulfilment service provider. - Ensure the designated operator can keep the DoC available and ensure technical documentation can be made available on request. - Display the required operator details on the product, packaging, parcel, or accompanying document where the legislation requires it. ## 6) Evidence mapping: requirement to artifact to owner The compliance accelerator is a requirements map that links each obligation to an artifact and an owner. That removes ambiguity and keeps changes reviewable. Use it as the backbone of the release gate and the response pack. - Annex I objective -> hazard log -> design control -> test report owner. - Annex III documentation -> indexed file set -> technical file owner. - DoC and CE marking -> release gate checklist -> compliance or regulatory owner. - Complaints, CAPA, withdrawals, and recalls -> post market workflow owner. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU LVD 2014/35/EU Requirements into an operational assessment Assessment Autopilot can take EU LVD 2014/35/EU Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU LVD 2014/35/EU can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU LVD 2014/35/EU Requirements](/solutions/assessment.md): Start from EU LVD 2014/35/EU Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU LVD 2014/35/EU](/contact.md): Review your current process, evidence gaps, and next steps for EU LVD 2014/35/EU Requirements. ## Primary sources - [Directive 2014/35/EU - obligations of economic operators and Annexes I, III, and IV (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/35/oj?ref=sorena.io) - Primary source for manufacturers, authorised representatives, importers, distributors, safety objectives, technical documentation, DoC, and CE marking. - [LVD Guidelines (August 2018) - European Commission](https://ec.europa.eu/docsroom/documents/33107?ref=sorena.io) - Practical clarifications on document holding, instructions, language responsibility, and operator duties. - [Regulation (EU) 2019/1020 - Article 4 and distance sales rules (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - EU based economic operator coverage and market surveillance support obligations for products sold into the EU. - [Blue Guide 2022 - Commission Notice 2022/C 247/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0628%2804%29&ref=sorena.io) - Cross regime guidance on product roles, modification, traceability, and simultaneous application of Union acts. ## Related Topic Guides - [Applicability Test | EU Low Voltage Directive (LVD) 2014/35/EU | In Scope or Excluded?](/artifacts/eu/low-voltage-directive/applicability-test.md): A step-by-step applicability test for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, product vs component. - [Checklist | EU Low Voltage Directive (LVD) 2014/35/EU | CE Marking Readiness Checklist (Technical File + DoC)](/artifacts/eu/low-voltage-directive/checklist.md): An audit-ready CE marking checklist for the EU Low Voltage Directive (LVD) 2014/35/EU: scope memo + Annex II exclusions, Annex I safety objectives mapping. - [Compliance Program | EU Low Voltage Directive (LVD) 2014/35/EU | Operating Model, Controls, and Evidence](/artifacts/eu/low-voltage-directive/compliance.md): Build a scalable compliance program for EU Low Voltage Directive (LVD) 2014/35/EU: product family strategy, scope control, Annex I hazard mapping. - [Conformity Assessment and CE Marking | EU Low Voltage Directive (LVD) 2014/35/EU | Module A, DoC, Technical File](/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce.md): A practical CE marking workflow for EU Low Voltage Directive (LVD) 2014/35/EU: Module A (internal production control), risk assessment. - [Deadlines and Compliance Calendar | EU Low Voltage Directive (LVD) 2014/35/EU | Release Gates, Evidence Cadence, Standards Updates](/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for EU Low Voltage Directive 2014/35/EU: legal milestones from adoption through current application, release gate timing. - [Essential Safety Requirements (Annex I) | EU Low Voltage Directive (LVD) 2014/35/EU | Hazards, Controls, and Test Evidence](/artifacts/eu/low-voltage-directive/essential-safety-requirements.md): Translate EU Low Voltage Directive (LVD) 2014/35/EU Annex I safety objectives into an engineering-ready hazard map: protection against electric shock. - [EU LVD vs EMC Directive | Low Voltage Directive 2014/35/EU vs EMC 2014/30/EU | What Changes for CE Marking?](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive.md): A practical comparison of the EU Low Voltage Directive (LVD) 2014/35/EU and the EMC Directive 2014/30/EU. - [EU LVD vs Machinery Regulation | Low Voltage Directive 2014/35/EU vs Machinery Regulation (EU) 2023/1230 | Electrical Risks and CE Evidence](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation.md): A practical overlap guide for Low Voltage Directive (LVD) 2014/35/EU and Machinery Regulation (EU) 2023/1230: when the product is machinery/related product. - [FAQ | EU Low Voltage Directive (LVD) 2014/35/EU | Scope, CE Marking, Technical File](/artifacts/eu/low-voltage-directive/faq.md): High-signal FAQ for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, do you need a notified body. - [Harmonised Standards | EU Low Voltage Directive (LVD) 2014/35/EU | Presumption of Conformity, OJ Lists, and Update Control](/artifacts/eu/low-voltage-directive/harmonized-standards.md): How harmonised standards work under the EU Low Voltage Directive (LVD) 2014/35/EU: presumption of conformity, Official Journal (OJ) references. - [Penalties and Fines | EU Low Voltage Directive (LVD) 2014/35/EU | Enforcement, Market Surveillance Actions, Risk Reduction](/artifacts/eu/low-voltage-directive/penalties-and-fines.md): Enforcement overview for the EU Low Voltage Directive (LVD) 2014/35/EU: what market surveillance authorities typically ask for. - [Scope and Products | EU Low Voltage Directive (LVD) 2014/35/EU | Voltage Limits, Exclusions (Annex II), and Examples](/artifacts/eu/low-voltage-directive/scope-and-products.md): A practical scope guide for the EU Low Voltage Directive 2014/35/EU: voltage limits at 50 to 1000 V AC and 75 to 1500 V DC. - [Technical Documentation (Technical File) | EU Low Voltage Directive (LVD) 2014/35/EU | Annex III Checklist and Structure](/artifacts/eu/low-voltage-directive/technical-documentation.md): Build an audit-ready LVD technical file for Directive 2014/35/EU: Annex III elements (product description, drawings/schematics, explanations, standards list. - [Templates | EU Low Voltage Directive (LVD) 2014/35/EU | Technical File Index, DoC Skeleton, Scope Memo, Evidence Pack](/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template.md): Copy/paste templates for EU Low Voltage Directive (LVD) 2014/35/EU compliance: scope memo (voltage + Annex II exclusions + overlap). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/low-voltage-directive/requirements --- --- title: "Scope and Products" canonical_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/scope-and-products" source_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/scope-and-products" author: "Sorena AI" description: "A practical scope guide for the EU Low Voltage Directive 2014/35/EU: voltage limits at 50 to 1000 V AC and 75 to 1500 V DC." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Low Voltage Directive scope" - "Low Voltage Directive 2014/35/EU scope" - "LVD voltage limits 50 1000 VAC 75 1500 VDC" - "LVD Annex II exclusions" - "electrical equipment in scope LVD" - "in scope products LVD" - "out of scope equipment LVD" - "LVD vs EMC" - "LVD vs RED" - "CE marking LVD scope" - "LVD" - "scope" - "voltage limits" - "Annex II" - "electrical equipment" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Scope and Products A practical scope guide for the EU Low Voltage Directive 2014/35/EU: voltage limits at 50 to 1000 V AC and 75 to 1500 V DC. *Scope* *EU* ## EU Low Voltage Directive (LVD) 2014/35/EU Scope and Products Decide if your product is in scope, then document why. Focus: voltage limits, Annex II exclusions, borderline products, and overlap with other CE marking rules (EMC/RED/Machinery). The LVD is a safety directive for electrical equipment within defined voltage limits. The hard part is not reciting those limits. The hard part is classifying borderline products, components, kits, and combinations of equipment correctly, then documenting the reasons so the scope decision survives redesign, online sales expansion, and market surveillance review. ## 1) Start with the voltage limits and the actual marketed product The first scope test is whether the product is electrical equipment designed for use at 50 to 1000 V AC or 75 to 1500 V DC. Apply that to the item actually placed on the market, not just the internal electronics after conversion. This matters especially for chargers, power supplies, control panels, and bundled products. - Capture rated input, frequency, power architecture, and whether the offer includes an external power supply. - Decide whether the marketed item is one finished product or several separately assessed products sold together. - Record intended use environment, foreseeable misuse, and installation assumptions in the scope memo. ## 2) Understand what counts as electrical equipment The directive does not define electrical equipment in a narrow way, so the 2018 LVD Guide is useful here. It says the scope generally includes electrical equipment intended both for direct use and for incorporation into other equipment. At the same time, many basic components whose safety can only really be assessed after incorporation are not themselves LVD products. - Basic components such as many semiconductors, resistors, or simple connectors are usually not treated as standalone LVD equipment. - Standalone subassemblies such as transformers or electric motors can be covered and CE marked in their own right. - CE marked components do not automatically make the finished product compliant; the final product still needs its own scope and conformity assessment. ## 3) Annex II exclusions you should test explicitly Annex II exclusions should appear as a positive checklist in the scope memo, not as an assumption left in someone's head. That one page check prevents a lot of wasted testing. - Equipment for use in explosive atmospheres. - Radiology and medical electrical equipment. - Electrical parts for goods and passenger lifts, electricity meters, domestic plugs and socket outlets, electric fence controllers, and radio electrical interference products. - Custom built evaluation kits for professionals used solely at research and development facilities. ## 4) Multi directive and borderline cases Many electrical products fall under more than one Union act. LVD often sits beside EMC and may sit beside RED or machinery rules depending on product function. The goal is one coherent classification memo and one evidence file, not duplicate narratives. - LVD plus EMC is common for mains powered electronic products and control gear. - LVD plus RED is common where radio functionality such as Wi-Fi or Bluetooth is built in. - If another specific regime governs electrical risks for the product type, document that governance clearly and avoid double counting the same risk path. ## 5) Scope bundle output you can reuse across teams A strong scope decision is reusable. It reduces repeated debates across engineering, procurement, compliance, and sales. Make the output concrete enough that a new reviewer can understand it without oral history. - Scope memo with voltage basis, component logic, exclusions check, and overlap list. - Applicable legislation list and preliminary standards shortlist. - Initial risk assumptions, target markets, and language obligations. - Named owner for future review when the product, supplier set, or sales model changes. *Recommended next step* *Placement: after the scope or definition section* ## Use EU Low Voltage Directive (LVD) 2014/35/EU Scope and Products as a cited research workflow Research Copilot can take EU Low Voltage Directive (LVD) 2014/35/EU Scope and Products from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Low Voltage Directive (LVD) 2014/35/EU can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Low Voltage Directive (LVD) 2014/35/EU Scope and Products](/solutions/research-copilot.md): Start from EU Low Voltage Directive (LVD) 2014/35/EU Scope and Products and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Low Voltage Directive (LVD) 2014/35/EU](/contact.md): Review your current process, evidence gaps, and next steps for EU Low Voltage Directive (LVD) 2014/35/EU Scope and Products. ## Primary sources - [Directive 2014/35/EU - scope and Annex II exclusions (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/35/oj?ref=sorena.io) - Primary legal source for voltage limits, exclusions, safety objectives, and operator duties. - [LVD Guidelines (August 2018) - European Commission](https://ec.europa.eu/docsroom/documents/33107?ref=sorena.io) - Useful for component treatment, finished product logic, and practical scope interpretation. - [Blue Guide 2022 - Commission Notice 2022/C 247/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0628%2804%29&ref=sorena.io) - Guidance on finished products, combinations of parts, substantial modification, and simultaneous application of Union acts. - [Regulation (EU) 2019/1020 - distance sales and Article 4 operator rules (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Relevant when in scope LVD products are sold online into the EU. ## Related Topic Guides - [Applicability Test | EU Low Voltage Directive (LVD) 2014/35/EU | In Scope or Excluded?](/artifacts/eu/low-voltage-directive/applicability-test.md): A step-by-step applicability test for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, product vs component. - [Checklist | EU Low Voltage Directive (LVD) 2014/35/EU | CE Marking Readiness Checklist (Technical File + DoC)](/artifacts/eu/low-voltage-directive/checklist.md): An audit-ready CE marking checklist for the EU Low Voltage Directive (LVD) 2014/35/EU: scope memo + Annex II exclusions, Annex I safety objectives mapping. - [Compliance Program | EU Low Voltage Directive (LVD) 2014/35/EU | Operating Model, Controls, and Evidence](/artifacts/eu/low-voltage-directive/compliance.md): Build a scalable compliance program for EU Low Voltage Directive (LVD) 2014/35/EU: product family strategy, scope control, Annex I hazard mapping. - [Conformity Assessment and CE Marking | EU Low Voltage Directive (LVD) 2014/35/EU | Module A, DoC, Technical File](/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce.md): A practical CE marking workflow for EU Low Voltage Directive (LVD) 2014/35/EU: Module A (internal production control), risk assessment. - [Deadlines and Compliance Calendar | EU Low Voltage Directive (LVD) 2014/35/EU | Release Gates, Evidence Cadence, Standards Updates](/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for EU Low Voltage Directive 2014/35/EU: legal milestones from adoption through current application, release gate timing. - [Essential Safety Requirements (Annex I) | EU Low Voltage Directive (LVD) 2014/35/EU | Hazards, Controls, and Test Evidence](/artifacts/eu/low-voltage-directive/essential-safety-requirements.md): Translate EU Low Voltage Directive (LVD) 2014/35/EU Annex I safety objectives into an engineering-ready hazard map: protection against electric shock. - [EU LVD vs EMC Directive | Low Voltage Directive 2014/35/EU vs EMC 2014/30/EU | What Changes for CE Marking?](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive.md): A practical comparison of the EU Low Voltage Directive (LVD) 2014/35/EU and the EMC Directive 2014/30/EU. - [EU LVD vs Machinery Regulation | Low Voltage Directive 2014/35/EU vs Machinery Regulation (EU) 2023/1230 | Electrical Risks and CE Evidence](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation.md): A practical overlap guide for Low Voltage Directive (LVD) 2014/35/EU and Machinery Regulation (EU) 2023/1230: when the product is machinery/related product. - [FAQ | EU Low Voltage Directive (LVD) 2014/35/EU | Scope, CE Marking, Technical File](/artifacts/eu/low-voltage-directive/faq.md): High-signal FAQ for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, do you need a notified body. - [Harmonised Standards | EU Low Voltage Directive (LVD) 2014/35/EU | Presumption of Conformity, OJ Lists, and Update Control](/artifacts/eu/low-voltage-directive/harmonized-standards.md): How harmonised standards work under the EU Low Voltage Directive (LVD) 2014/35/EU: presumption of conformity, Official Journal (OJ) references. - [Penalties and Fines | EU Low Voltage Directive (LVD) 2014/35/EU | Enforcement, Market Surveillance Actions, Risk Reduction](/artifacts/eu/low-voltage-directive/penalties-and-fines.md): Enforcement overview for the EU Low Voltage Directive (LVD) 2014/35/EU: what market surveillance authorities typically ask for. - [Requirements | EU Low Voltage Directive (LVD) 2014/35/EU | Manufacturer, Importer, Distributor Obligations](/artifacts/eu/low-voltage-directive/requirements.md): An implementation-grade requirements breakdown for the EU Low Voltage Directive (LVD) 2014/35/EU: obligations for manufacturers, authorised representatives. - [Technical Documentation (Technical File) | EU Low Voltage Directive (LVD) 2014/35/EU | Annex III Checklist and Structure](/artifacts/eu/low-voltage-directive/technical-documentation.md): Build an audit-ready LVD technical file for Directive 2014/35/EU: Annex III elements (product description, drawings/schematics, explanations, standards list. - [Templates | EU Low Voltage Directive (LVD) 2014/35/EU | Technical File Index, DoC Skeleton, Scope Memo, Evidence Pack](/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template.md): Copy/paste templates for EU Low Voltage Directive (LVD) 2014/35/EU compliance: scope memo (voltage + Annex II exclusions + overlap). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/low-voltage-directive/scope-and-products --- --- title: "Technical Documentation (Technical File)" canonical_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/technical-documentation" source_url: "https://www.sorena.io/artifacts/eu/low-voltage-directive/technical-documentation" author: "Sorena AI" description: "Build an audit-ready LVD technical file for Directive 2014/35/EU: Annex III elements (product description, drawings/schematics, explanations, standards list." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "LVD technical documentation" - "LVD technical file Annex III" - "Directive 2014/35/EU Annex III checklist" - "CE marking technical file electrical equipment" - "LVD test reports requirements" - "EU declaration of conformity retention 10 years" - "technical documentation" - "technical file" - "Annex III" - "CE marking" - "evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Technical Documentation (Technical File) Build an audit-ready LVD technical file for Directive 2014/35/EU: Annex III elements (product description, drawings/schematics, explanations, standards list. *Technical File* *EU* ## EU LVD 2014/35/EU Technical Documentation A technical file structure you can hand to market surveillance in minutes. Focus: Annex III checklist + evidence indexing + retention and change control. Under the LVD, technical documentation is the core conformity artifact. Annex III is explicit that the file must make it possible to assess conformity and include an adequate analysis and assessment of risks. A good file is therefore not a dump of PDFs. It is a navigable evidence system that connects Annex I objectives, standards choices, tests, and released product configurations. ## 1) What the technical documentation must achieve A reviewer should be able to move quickly from product identity to hazard reasoning to evidence. If that path is not obvious, the file is incomplete even if the documents technically exist. Think of the technical file as the source of truth that supports the DoC, CE marking, importer support, and corrective action. - Clear product identity, variants, photos, labels, and traceability logic. - Explicit connection from Annex I objective to hazard, control, test method, and result. - A change history that explains why the current DoC is still valid. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU LVD 2014/35/EU Technical Documentation in one governed evidence system SSOT can take EU LVD 2014/35/EU Technical Documentation from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU LVD 2014/35/EU can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU LVD 2014/35/EU Technical Documentation](/solutions/ssot.md): Start from EU LVD 2014/35/EU Technical Documentation and keep documents, evidence, and control records in one governed system. - [Talk through EU LVD 2014/35/EU](/contact.md): Review your current process, evidence gaps, and next steps for EU LVD 2014/35/EU Technical Documentation. ## 2) Annex III minimum contents Annex III gives you the minimum schema for the file. Use it as the index, then attach additional documents where needed. Do not forget the risk analysis requirement hidden in the opening sentence of Annex III. - General description of the electrical equipment. - Design and manufacturing drawings, schemes of components, sub assemblies, circuits, and explanations needed to understand them. - Standards list showing what was applied in full or in part, plus alternative solutions where needed. - Results of design calculations, examinations, and test reports, supported by an adequate analysis and assessment of risks. ## 3) Standards and presumption of conformity inside the file The standards register inside the technical file should show the decision references, editions, and whether a standard is fully applied, partially applied, or only used as supporting material. This is the part of the file most likely to go stale after a product update. - Record the OJ or implementing decision context used for the standards set. - Add clause mapping for partial application and explain any gaps. - Keep update review memos for standards restrictions, withdrawals, or deferred withdrawal dates. ## 4) Risk analysis should be the navigation layer Risk analysis should not sit alone as a static spreadsheet. It should point the reviewer to the exact evidence item that closes each hazard. This is especially important where no harmonised standard exists or where standards are applied only in part. - Link each hazard to the design control, the verification method, and the evidence ID. - Capture foreseeable misuse and external influence assumptions, not only intended use. - Show where residual risk is accepted and how warnings or instructions address it. ## 5) Holding, retention, and availability rules Manufacturers keep the technical file and the DoC for 10 years after placement on the market. Importers must ensure the file can be made available on request, and an authorised representative can be mandated to hold it at the disposal of authorities. That means file ownership, storage, backup, and retrieval speed are compliance controls. - Assign one technical file owner and one backup owner per product family. - Keep a response pack export with the DoC, index, scope memo, and key reports. - Document retrieval SLAs and the path for getting the file from the manufacturer to the importer or authority quickly. ## 6) Suggested folder structure you can actually operate The best folder structure is boring, stable, and easy to export. It should support both routine releases and emergency authority requests. Use the same pattern across product families so everyone can find evidence quickly. - 00-Index for scope memo, applicable legislation list, and index file. - 01-Design for drawings, schematics, BOM, and critical components. - 02-Risk for hazard log, Annex I mapping, and residual risk decisions. - 03-Standards for standards register, clause maps, and update review logs. - 04-Verification for test plans, reports, and calculations. - 05-Labels-and-Instructions for markings, safety information, and translations. - 06-DoC for signed declarations and version history. - 07-Post-market for complaints, CAPA, withdrawals, and recalls. ## Primary sources - [Directive 2014/35/EU - Annex III technical documentation and retention duties (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/35/oj?ref=sorena.io) - Primary source for minimum file contents, risk analysis requirement, and 10 year retention. - [LVD Guidelines (August 2018) - European Commission](https://ec.europa.eu/docsroom/documents/33107?ref=sorena.io) - Useful on importer access to technical documentation, declaration holding, and the practical role of the file in enforcement. - [Blue Guide 2022 - Commission Notice 2022/C 247/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0628%2804%29&ref=sorena.io) - Cross regime guidance on technical documentation logic, standards use, and evidence expectations. - [Regulation (EU) 2019/1020 - market surveillance documentation expectations (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Current framework for documentation availability and market surveillance support. ## Related Topic Guides - [Applicability Test | EU Low Voltage Directive (LVD) 2014/35/EU | In Scope or Excluded?](/artifacts/eu/low-voltage-directive/applicability-test.md): A step-by-step applicability test for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, product vs component. - [Checklist | EU Low Voltage Directive (LVD) 2014/35/EU | CE Marking Readiness Checklist (Technical File + DoC)](/artifacts/eu/low-voltage-directive/checklist.md): An audit-ready CE marking checklist for the EU Low Voltage Directive (LVD) 2014/35/EU: scope memo + Annex II exclusions, Annex I safety objectives mapping. - [Compliance Program | EU Low Voltage Directive (LVD) 2014/35/EU | Operating Model, Controls, and Evidence](/artifacts/eu/low-voltage-directive/compliance.md): Build a scalable compliance program for EU Low Voltage Directive (LVD) 2014/35/EU: product family strategy, scope control, Annex I hazard mapping. - [Conformity Assessment and CE Marking | EU Low Voltage Directive (LVD) 2014/35/EU | Module A, DoC, Technical File](/artifacts/eu/low-voltage-directive/conformity-assessment-and-ce.md): A practical CE marking workflow for EU Low Voltage Directive (LVD) 2014/35/EU: Module A (internal production control), risk assessment. - [Deadlines and Compliance Calendar | EU Low Voltage Directive (LVD) 2014/35/EU | Release Gates, Evidence Cadence, Standards Updates](/artifacts/eu/low-voltage-directive/deadlines-and-compliance-calendar.md): A practical compliance calendar for EU Low Voltage Directive 2014/35/EU: legal milestones from adoption through current application, release gate timing. - [Essential Safety Requirements (Annex I) | EU Low Voltage Directive (LVD) 2014/35/EU | Hazards, Controls, and Test Evidence](/artifacts/eu/low-voltage-directive/essential-safety-requirements.md): Translate EU Low Voltage Directive (LVD) 2014/35/EU Annex I safety objectives into an engineering-ready hazard map: protection against electric shock. - [EU LVD vs EMC Directive | Low Voltage Directive 2014/35/EU vs EMC 2014/30/EU | What Changes for CE Marking?](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-emc-directive.md): A practical comparison of the EU Low Voltage Directive (LVD) 2014/35/EU and the EMC Directive 2014/30/EU. - [EU LVD vs Machinery Regulation | Low Voltage Directive 2014/35/EU vs Machinery Regulation (EU) 2023/1230 | Electrical Risks and CE Evidence](/artifacts/eu/low-voltage-directive/low-voltage-directive-vs-machinery-regulation.md): A practical overlap guide for Low Voltage Directive (LVD) 2014/35/EU and Machinery Regulation (EU) 2023/1230: when the product is machinery/related product. - [FAQ | EU Low Voltage Directive (LVD) 2014/35/EU | Scope, CE Marking, Technical File](/artifacts/eu/low-voltage-directive/faq.md): High-signal FAQ for the EU Low Voltage Directive (LVD) 2014/35/EU: voltage limits, Annex II exclusions, do you need a notified body. - [Harmonised Standards | EU Low Voltage Directive (LVD) 2014/35/EU | Presumption of Conformity, OJ Lists, and Update Control](/artifacts/eu/low-voltage-directive/harmonized-standards.md): How harmonised standards work under the EU Low Voltage Directive (LVD) 2014/35/EU: presumption of conformity, Official Journal (OJ) references. - [Penalties and Fines | EU Low Voltage Directive (LVD) 2014/35/EU | Enforcement, Market Surveillance Actions, Risk Reduction](/artifacts/eu/low-voltage-directive/penalties-and-fines.md): Enforcement overview for the EU Low Voltage Directive (LVD) 2014/35/EU: what market surveillance authorities typically ask for. - [Requirements | EU Low Voltage Directive (LVD) 2014/35/EU | Manufacturer, Importer, Distributor Obligations](/artifacts/eu/low-voltage-directive/requirements.md): An implementation-grade requirements breakdown for the EU Low Voltage Directive (LVD) 2014/35/EU: obligations for manufacturers, authorised representatives. - [Scope and Products | EU Low Voltage Directive (LVD) 2014/35/EU | Voltage Limits, Exclusions (Annex II), and Examples](/artifacts/eu/low-voltage-directive/scope-and-products.md): A practical scope guide for the EU Low Voltage Directive 2014/35/EU: voltage limits at 50 to 1000 V AC and 75 to 1500 V DC. - [Templates | EU Low Voltage Directive (LVD) 2014/35/EU | Technical File Index, DoC Skeleton, Scope Memo, Evidence Pack](/artifacts/eu/low-voltage-directive/lvd-conformity-assessment-template.md): Copy/paste templates for EU Low Voltage Directive (LVD) 2014/35/EU compliance: scope memo (voltage + Annex II exclusions + overlap). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/low-voltage-directive/technical-documentation --- --- title: "Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/applicability-test" author: "Sorena AI" description: "A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Machinery Regulation applicability test" - "machinery regulation scope test" - "Regulation (EU) 2023/1230 applicability" - "Annex I Part A Part B classification" - "Article 25 conformity assessment route" - "partly completed machinery declaration of incorporation" - "applicability" - "scope" - "Annex I" - "Article 25" - "CE marking" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Applicability Test A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery. *Applicability* *EU* ## EU Machinery Regulation (EU) 2023/1230 Applicability Test Decide scope, Annex I category, and conformity route - with defensible reasoning. Output: a scope memo + route decision + technical file plan per product family. Most compliance failures start with a bad classification: the product type (machinery vs partly completed machinery vs safety component), an overlooked exclusion, or a missed Annex I category that changes the conformity assessment route. This page gives you a practical, reviewable decision sequence that teams can run quickly and repeatably. ## Before you start: capture the minimum product facts A defensible scope outcome requires stable product facts. If you can't answer these, pause and collect the data before you start testing or drafting declarations. Output: a one-page scope memo per product family. - What is being placed on the market: complete machinery, related product, safety component (physical/digital), or partly completed machinery? - Intended use + reasonably foreseeable misuse; lifecycle phases (transport, assembly, maintenance, dismantling). - Energy source and moving parts; control system architecture (software, sensors, remote control, autonomy). - How it is supplied: standalone vs integrated; installed on a vehicle/vessel/aircraft? used in a nuclear installation? - Who is the manufacturer/economic operator (including branding and any substantial modifications)? ## Step 1 - Is it within the product scope (machinery + related products + partly completed machinery)? The Regulation covers machinery and specific related products (e.g., interchangeable equipment, safety components, lifting accessories, chains/ropes/webbing, removable mechanical transmission devices) and also partly completed machinery. Operational control: explicitly label the product type in your scope memo and technical file index. - Machinery can include assemblies missing only the uploading of software intended for the specific application foreseen by the manufacturer. - Safety components can be physical or digital (including software) if they perform a safety function and are independently placed on the market. - Partly completed machinery is not yet machinery and is intended to be incorporated into or assembled with machinery. ## Step 2 - Check exclusions (don't assume you are in scope) The Regulation does not apply to several categories (e.g., fairground equipment, weapons, certain transport means, research-only temporary lab machinery) and it excludes specified electrical/electronic products insofar as they fall under LVD/RED. Control: keep an 'exclusions checked' section in the scope memo with 1-2 sentence rationales. - Transport: means of transport by air/water/rail (except machinery mounted on them) and certain vehicle regimes. - Research-only: machinery specially designed and constructed for research purposes for temporary use in laboratories. - Electrical/electronic products: certain household appliances, A/V, IT, office machinery, low-voltage switchgear/control gear, and electric motors (when they fall under LVD/RED). ## Step 3 - Annex I classification: Part A vs Part B (changes the Article 25 route) Annex I lists categories of machinery or related products subject to specific conformity assessment routes. Part A categories require procedures under Article 25(2) (third-party routes). Part B categories can use Article 25(3) routes (including Module A in certain conditions). Operational output: an Annex I classification note that cites the exact category item (and sub-item) you match. - Part A examples include removable mechanical transmission devices and certain ML/self-evolving safety components and embedded safety systems. - Part B includes many high-risk machinery categories (e.g., various saws, presses, lifts, protective devices, logic units). - If you are not in Annex I, Article 25(4) points you to internal production control (Module A). ## Step 4 - Article 25 conformity assessment route (Module A vs notified body routes) Once Annex I status is known, you can choose the correct route: Module A for non-Annex I (and for some Annex I Part B conditions), or notified body routes (Modules B+C, H, or G) for Annex I categories and for Part B cases that do not meet the 'harmonised standards/common specs fully cover' condition. Control: keep a "route decision memo" that references Article 25 paragraph and the evidence you will build. - Annex I Part A: one of the procedures in Article 25(2) (B+C, H, or G). - Annex I Part B: Module A only if designed/constructed per relevant harmonised standards or common specifications covering all relevant EHSR for that category; otherwise use (B+C), H, or G. - Notified body involvement means CE marking is followed by the notified body identification number (per CE marking rules). ## Step 5 - Substantial modification: when you become the 'manufacturer' again If a product is modified after being placed on the market/put into service in a way that affects safety (creating a new hazard or increasing risk) and is not foreseen by the original manufacturer, it can trigger substantial modification duties. Operational output: a modification impact review that decides whether a new conformity assessment under Article 25 is needed. - Capture modifications by physical or digital means (including software/config changes). - Assess if new hazards are introduced or existing risks increase. - If substantial: treat the modifier as responsible for conformity and route application. ## If 'in scope': the next three artifacts to build Once the Regulation applies, move directly to the evidence chain: risk assessment -> technical documentation -> declaration(s) -> CE marking/availability requirements. Use the linked pages to convert this into an execution plan. - Risk assessment method (Annex III general principles) + hazard log. - Technical file index aligned to Annex IV (Part A or Part B). - Conformity assessment route workflow (Article 25) + DoC/DoI + CE marking controls. *Recommended next step* *Placement: after the applicability result* ## Turn EU Machinery Regulation (EU) 2023/1230 Applicability Test into an operational assessment Assessment Autopilot can take EU Machinery Regulation (EU) 2023/1230 Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU Machinery Regulation (EU) 2023/1230 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Machinery Regulation (EU) 2023/1230 Applicability Test](/solutions/assessment.md): Start from EU Machinery Regulation (EU) 2023/1230 Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Machinery Regulation (EU) 2023/1230](/contact.md): Review your current process, evidence gaps, and next steps for EU Machinery Regulation (EU) 2023/1230 Applicability Test. ## Primary sources - [Regulation (EU) 2023/1230 - Machinery Regulation (Scope/Definitions/Annex I/Article 25) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/oj?ref=sorena.io) - Primary legal text for scope, exclusions, definitions, Annex I categories, and Article 25 conformity assessment procedures. - [Regulation (EU) 2019/1020 - Market surveillance and compliance of products (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Horizontal market surveillance framework and EU-based economic operator task concepts relevant to documentation availability. - [Blue Guide 2022 - Commission Notice 2022/C 247/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0628%2804%29&ref=sorena.io) - Guidance on placing/making available on the market, multi-legislation products, and CE marking concepts. ## Related Topic Guides - [Checklist | EU Machinery Regulation (EU) 2023/1230 | CE Marking Readiness Checklist (Route + Technical File + Declarations)](/artifacts/eu/machinery-regulation/checklist.md): An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2). - [Compliance Program | EU Machinery Regulation (EU) 2023/1230 | Operating Model, Controls, Transition to 2027](/artifacts/eu/machinery-regulation/compliance.md): Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control. - [Conformity Assessment and CE Marking | EU Machinery Regulation (EU) 2023/1230 | Article 25 Modules, Annex I, DoC/DoI](/artifacts/eu/machinery-regulation/conformity-assessment-and-ce.md): A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H. - [Deadlines and Compliance Calendar | EU Machinery Regulation (EU) 2023/1230 | Transition to 14 Jan 2027 + Route and Evidence Milestones](/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar.md): A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. - [FAQ | EU Machinery Regulation (EU) 2023/1230 | Scope, Annex I, Article 25, Technical File, Software](/artifacts/eu/machinery-regulation/faq.md): High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route. - [Machinery Regulation vs EU AI Act | Smart machinery, safety components, high-risk AI](/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act.md): A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6). - [Machinery Regulation vs Machinery Directive | Regulation (EU) 2023/1230 vs Directive 2006/42/EC | Key Changes + Migration Plan](/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive.md): A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates. - [Penalties and Fines | EU Machinery Regulation (EU) 2023/1230 | Article 50, Enforcement, Corrective Actions](/artifacts/eu/machinery-regulation/penalties-and-fines.md): A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline. - [Requirements | EU Machinery Regulation (EU) 2023/1230 | EHSR (Annex III), Technical File (Annex IV), Article 25 Route](/artifacts/eu/machinery-regulation/requirements.md): An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence. - [Risk Assessment Method | EU Machinery Regulation (EU) 2023/1230 | Annex III General Principles Workflow](/artifacts/eu/machinery-regulation/risk-assessment-method.md): A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles. - [Scope and Machine Categories | EU Machinery Regulation (EU) 2023/1230 | Machinery, Related Products, Partly Completed Machinery, Annex I](/artifacts/eu/machinery-regulation/scope-and-machine-categories.md): A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment. - [Software and Cybersecurity Considerations | EU Machinery Regulation (EU) 2023/1230 | Control Systems, Protection Against Corruption, Logs](/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations.md): A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption. - [Technical Documentation and Technical File | EU Machinery Regulation (EU) 2023/1230 | Annex IV Part A/B Checklist + Structure](/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file.md): A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping. - [Templates | EU Machinery Regulation (EU) 2023/1230 | Route Memo, Annex IV Technical File Index, DoC/DoI, Risk Assessment Mapping](/artifacts/eu/machinery-regulation/machinery-ce-documentation-template.md): Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note. - [Timeline and Transition | EU Machinery Regulation (EU) 2023/1230 | From Machinery Directive 2006/42/EC to 14 Jan 2027](/artifacts/eu/machinery-regulation/timeline-and-transition.md): A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/machinery-regulation/applicability-test --- --- title: "Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/checklist" source_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/checklist" author: "Sorena AI" description: "An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Machinery Regulation checklist" - "machinery regulation compliance checklist" - "Regulation (EU) 2023/1230 checklist" - "Annex I classification checklist" - "Article 25 route checklist" - "Annex IV technical file checklist" - "declaration of incorporation checklist" - "checklist" - "Annex I" - "Article 25" - "technical file" - "CE marking" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Checklist An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2). *Checklist* *EU* ## EU Machinery Regulation (EU) 2023/1230 Checklist A CE marking readiness checklist you can run before release. Each item should have an owner, evidence link, and acceptance criteria. This checklist is designed to survive real audits and market surveillance requests. Use it per product family and link each checklist item to an evidence ID and file path in your Annex IV technical file index. ## A) Scope and product type classification (Article 2-3) Scope mistakes cause the biggest rework. Document this once and reuse it. - Product type labeled: machinery vs related product vs partly completed machinery vs safety component/software. - Exclusions checked and documented with rationale (transport regimes, research-only lab use, specified electrical products under LVD/RED, etc.). - Economic operator roles confirmed (manufacturer/importer/distributor/authorised representative). - Substantial modification policy defined (what changes trigger re-assessment). ## B) Annex I classification and Article 25 route decision Route selection determines notified body involvement and how CE marking is applied. - Annex I category decision memo stored (Part A / Part B / not listed) with exact category references. - Article 25 procedure selected and documented (Module A vs B+C vs H vs G). - If Part B + Module A used: evidence that harmonised standards/common specs for that category cover all relevant EHSR and are applied. - Notified body engagement plan created where required (lead time, scope, change control triggers). ## C) Annex III risk assessment and safety integration (the safety case) Risk assessment is mandatory and iterative; controls must follow the safety integration hierarchy. - Limits defined (intended use + foreseeable misuse + lifecycle phases). - Hazards and hazardous situations identified; risk estimation/evaluation documented. - Protective measures selected in priority order (inherently safe design -> protective measures -> information). - Residual risks documented and mapped to warnings/marking/instructions. - Special cases covered: autonomy/self-evolving behavior, interaction between machines, planned software updates. ## D) Annex IV technical documentation (Part A or Part B) and evidence indexing Your technical file must be exportable and reviewable. Build a stable index and link evidence. - Technical file index complete (scope memo, route memo, EHSR list, evidence map). - Design drawings/schematics + operation explanations stored and versioned. - Standards/common specifications register + partial application clause mapping maintained. - Verification evidence complete: test reports, inspections, examinations, calculations. - Series production controls documented (how you keep production conforming). - Instructions pack included (and assembly instructions + DoI for partly completed machinery). - Software/control-system evidence ready where relevant (safety software identification, intervention logs, reasoned-request bundles). ## E) Declarations, CE marking, and traceability These are the first things checked. Treat missing or inconsistent artifacts as release blockers. - EU Declaration of Conformity issued for machinery/related products; kept updated; translated as required. - EU Declaration of Incorporation issued for partly completed machinery; assembly instructions provided; digital access compliance implemented if used. - CE marking affixed visibly/legibly/indelibly (or packaging/docs if necessary); affixed before placing on market/putting into service. - Notified body identification number follows CE marking where required by the applied procedure. - Traceability labels and contact details verified on product/packaging/accompanying documents. ## F) Transition and compliance calendar (plan for 14 Jan 2027) Transition work is a project: route decisions, standards strategy, documentation modernization, and supplier alignment. - Transition plan created (Directive 2006/42/EC -> Regulation 2023/1230) with milestones and owners. - Notified body capacity planning for Annex I categories that require third-party procedures. - Digital instructions/declarations strategy defined (accessibility, print/download, retention). - Penalty rules monitoring and market surveillance readiness tested (response pack export). *Recommended next step* *Placement: after the checklist block* ## Turn EU Machinery Regulation (EU) 2023/1230 Checklist into an operational assessment Assessment Autopilot can take EU Machinery Regulation (EU) 2023/1230 Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Machinery Regulation (EU) 2023/1230 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Machinery Regulation (EU) 2023/1230 Checklist](/solutions/assessment.md): Start from EU Machinery Regulation (EU) 2023/1230 Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Machinery Regulation (EU) 2023/1230](/contact.md): Review your current process, evidence gaps, and next steps for EU Machinery Regulation (EU) 2023/1230 Checklist. ## Primary sources - [Regulation (EU) 2023/1230 - Machinery Regulation (Annex I; Article 25; Annex III; Annex IV; Article 54 dates) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/oj?ref=sorena.io) - Primary source for route selection, risk assessment duties, technical file requirements, and transition timeline. - [Regulation (EU) 2019/1020 - Market surveillance and compliance of products (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Market surveillance framework shaping response readiness and documentation availability expectations. ## Related Topic Guides - [Applicability Test | EU Machinery Regulation (EU) 2023/1230 | In Scope? Annex I? Article 25 Route?](/artifacts/eu/machinery-regulation/applicability-test.md): A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery. - [Compliance Program | EU Machinery Regulation (EU) 2023/1230 | Operating Model, Controls, Transition to 2027](/artifacts/eu/machinery-regulation/compliance.md): Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control. - [Conformity Assessment and CE Marking | EU Machinery Regulation (EU) 2023/1230 | Article 25 Modules, Annex I, DoC/DoI](/artifacts/eu/machinery-regulation/conformity-assessment-and-ce.md): A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H. - [Deadlines and Compliance Calendar | EU Machinery Regulation (EU) 2023/1230 | Transition to 14 Jan 2027 + Route and Evidence Milestones](/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar.md): A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. - [FAQ | EU Machinery Regulation (EU) 2023/1230 | Scope, Annex I, Article 25, Technical File, Software](/artifacts/eu/machinery-regulation/faq.md): High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route. - [Machinery Regulation vs EU AI Act | Smart machinery, safety components, high-risk AI](/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act.md): A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6). - [Machinery Regulation vs Machinery Directive | Regulation (EU) 2023/1230 vs Directive 2006/42/EC | Key Changes + Migration Plan](/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive.md): A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates. - [Penalties and Fines | EU Machinery Regulation (EU) 2023/1230 | Article 50, Enforcement, Corrective Actions](/artifacts/eu/machinery-regulation/penalties-and-fines.md): A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline. - [Requirements | EU Machinery Regulation (EU) 2023/1230 | EHSR (Annex III), Technical File (Annex IV), Article 25 Route](/artifacts/eu/machinery-regulation/requirements.md): An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence. - [Risk Assessment Method | EU Machinery Regulation (EU) 2023/1230 | Annex III General Principles Workflow](/artifacts/eu/machinery-regulation/risk-assessment-method.md): A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles. - [Scope and Machine Categories | EU Machinery Regulation (EU) 2023/1230 | Machinery, Related Products, Partly Completed Machinery, Annex I](/artifacts/eu/machinery-regulation/scope-and-machine-categories.md): A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment. - [Software and Cybersecurity Considerations | EU Machinery Regulation (EU) 2023/1230 | Control Systems, Protection Against Corruption, Logs](/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations.md): A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption. - [Technical Documentation and Technical File | EU Machinery Regulation (EU) 2023/1230 | Annex IV Part A/B Checklist + Structure](/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file.md): A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping. - [Templates | EU Machinery Regulation (EU) 2023/1230 | Route Memo, Annex IV Technical File Index, DoC/DoI, Risk Assessment Mapping](/artifacts/eu/machinery-regulation/machinery-ce-documentation-template.md): Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note. - [Timeline and Transition | EU Machinery Regulation (EU) 2023/1230 | From Machinery Directive 2006/42/EC to 14 Jan 2027](/artifacts/eu/machinery-regulation/timeline-and-transition.md): A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/machinery-regulation/checklist --- --- title: "Compliance Program" canonical_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/compliance" source_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/compliance" author: "Sorena AI" description: "Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Machinery Regulation compliance program" - "Regulation (EU) 2023/1230 operating model" - "machinery regulation transition 2027" - "Article 25 conformity assessment governance" - "Annex IV technical file process" - "notified body planning machinery" - "compliance program" - "transition" - "Article 25" - "technical file" - "notified body" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Compliance Program Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control. *Compliance* *EU* ## EU Machinery Regulation (EU) 2023/1230 Compliance Program Make route decisions and evidence packs repeatable across many machines. Focus: controls, release gates, transition milestones, and notified body capacity planning. Machinery compliance is a lifecycle system. It fails when route decisions are made late, when safety evidence isn't mapped to essential requirements, or when software/control-system changes are not governed. This page provides an operating model: a control library, a release gate, a transition plan to 14 January 2027, and a market surveillance response discipline. ## 1) Product family strategy (the scale lever) Define families so you can reuse evidence across variants without losing defensibility. Output: a matrix of variants with shared vs variant-specific hazards, controls, and evidence. - Family boundary: common architecture vs variant modules (control system, guards, energy sources). - Representative configurations for verification and notified body assessment reproducibility. - Documentation strategy: one Annex IV index with variant annexes and change logs. ## 2) Core control library (the minimum set that prevents rework) Treat the Regulation as controls with owners and evidence links. This is the practical way to maintain compliance across suppliers and updates. Controls should be stable; evidence updates as products evolve. - Scope control: exclusions checked and product type classification (machinery/related/partly completed/safety component). - Route governance: Annex I classification + Article 25 route memo + change triggers. - Safety case: Annex III risk assessment workflow + safety integration hierarchy + residual risk management. - Evidence system: Annex IV technical file index + standards register + verification reports + production controls. - Software integrity: protection against corruption controls + logging + update impact review for safety-relevant software. ## 3) Notified body capacity planning (avoid the 2026 bottleneck) Annex I Part A and many Part B scenarios can require notified body involvement. Capacity constraints are a practical risk for 2026-2027 timelines. Output: a notified body plan per product family (route, evidence readiness date, assessment window). - Identify Annex I categories early and lock the route decision. - Prepare a 'notified body pack': technical file index, hazard mapping summary, key test evidence, change history. - Define change control rules: what changes require re-assessment or notification. ## 4) Release gate ("CE-ready to place on the market" decision) Most failures are release failures: missing instructions, inconsistent declarations, or incomplete evidence indexing. Implement a gate that blocks shipping/listing until the evidence chain is complete. - Scope memo + route memo approved and stored in the technical file. - Risk assessment and EHSR mapping complete; residual risks reflected in instructions/warnings. - Technical file index complete (Annex IV Part A/B) with evidence links. - Declarations issued (DoC/DoI) and translated; CE marking applied; notified body number included when required. - Response pack export created and retrievable within a defined SLA. ## 5) Transition program to 14 January 2027 (a real project plan) The Regulation applies from 14 January 2027, but several provisions apply earlier. Treat transition as a multi-workstream program. Output: a transition roadmap with owners, milestones, and supplier deliverables. - Classification workstream: map current Directive 2006/42 assessments to Regulation scope and Annex I categories. - Route workstream: identify products that will require notified body involvement and schedule assessments. - Documentation modernization: digital instructions/declarations strategy; evidence indexing improvements; software evidence bundles. - Supplier alignment: evidence requests, change notification, and technical file contributions. ## 6) Market surveillance readiness (treat requests as routine) Market surveillance requests should be normal operations, not a crisis. This requires exportable evidence packs and a single communications owner. Output: a response playbook and a standard response pack format. - Maintain a product family response pack (DoC/DoI + index + key test reports + instructions). - Keep traceability and labeling evidence (photos, label files, serial/batch mapping). - Corrective action workflow defined (withdrawal/recall readiness, documentation updates, notifications where required). *Recommended next step* *Placement: after the compliance steps* ## Turn EU Machinery Regulation (EU) 2023/1230 Compliance Program into an operational assessment Assessment Autopilot can take EU Machinery Regulation (EU) 2023/1230 Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Machinery Regulation (EU) 2023/1230 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Machinery Regulation (EU) 2023/1230 Compliance Program](/solutions/assessment.md): Start from EU Machinery Regulation (EU) 2023/1230 Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Machinery Regulation (EU) 2023/1230](/contact.md): Review your current process, evidence gaps, and next steps for EU Machinery Regulation (EU) 2023/1230 Compliance Program. ## Primary sources - [Regulation (EU) 2023/1230 - Machinery Regulation (Annex I; Article 25; Annex III; Annex IV; Article 54 dates) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/oj?ref=sorena.io) - Primary source for route governance, safety case requirements, technical file obligations, and transition timeline. - [Commission Implementing Decision C(2025) 129 final - standardisation request for the Machinery Regulation (ibf-solutions.com)](https://ibf-solutions.com/wp-content/uploads/2025/02/standardisation-request-mr.pdf?ref=sorena.io) - Reference material for standards transition planning and gap analysis context. - [Regulation (EU) 2019/1020 - Market surveillance and compliance of products (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Horizontal market surveillance framework for response readiness and enforcement touchpoints. ## Related Topic Guides - [Applicability Test | EU Machinery Regulation (EU) 2023/1230 | In Scope? Annex I? Article 25 Route?](/artifacts/eu/machinery-regulation/applicability-test.md): A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery. - [Checklist | EU Machinery Regulation (EU) 2023/1230 | CE Marking Readiness Checklist (Route + Technical File + Declarations)](/artifacts/eu/machinery-regulation/checklist.md): An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2). - [Conformity Assessment and CE Marking | EU Machinery Regulation (EU) 2023/1230 | Article 25 Modules, Annex I, DoC/DoI](/artifacts/eu/machinery-regulation/conformity-assessment-and-ce.md): A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H. - [Deadlines and Compliance Calendar | EU Machinery Regulation (EU) 2023/1230 | Transition to 14 Jan 2027 + Route and Evidence Milestones](/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar.md): A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. - [FAQ | EU Machinery Regulation (EU) 2023/1230 | Scope, Annex I, Article 25, Technical File, Software](/artifacts/eu/machinery-regulation/faq.md): High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route. - [Machinery Regulation vs EU AI Act | Smart machinery, safety components, high-risk AI](/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act.md): A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6). - [Machinery Regulation vs Machinery Directive | Regulation (EU) 2023/1230 vs Directive 2006/42/EC | Key Changes + Migration Plan](/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive.md): A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates. - [Penalties and Fines | EU Machinery Regulation (EU) 2023/1230 | Article 50, Enforcement, Corrective Actions](/artifacts/eu/machinery-regulation/penalties-and-fines.md): A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline. - [Requirements | EU Machinery Regulation (EU) 2023/1230 | EHSR (Annex III), Technical File (Annex IV), Article 25 Route](/artifacts/eu/machinery-regulation/requirements.md): An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence. - [Risk Assessment Method | EU Machinery Regulation (EU) 2023/1230 | Annex III General Principles Workflow](/artifacts/eu/machinery-regulation/risk-assessment-method.md): A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles. - [Scope and Machine Categories | EU Machinery Regulation (EU) 2023/1230 | Machinery, Related Products, Partly Completed Machinery, Annex I](/artifacts/eu/machinery-regulation/scope-and-machine-categories.md): A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment. - [Software and Cybersecurity Considerations | EU Machinery Regulation (EU) 2023/1230 | Control Systems, Protection Against Corruption, Logs](/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations.md): A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption. - [Technical Documentation and Technical File | EU Machinery Regulation (EU) 2023/1230 | Annex IV Part A/B Checklist + Structure](/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file.md): A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping. - [Templates | EU Machinery Regulation (EU) 2023/1230 | Route Memo, Annex IV Technical File Index, DoC/DoI, Risk Assessment Mapping](/artifacts/eu/machinery-regulation/machinery-ce-documentation-template.md): Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note. - [Timeline and Transition | EU Machinery Regulation (EU) 2023/1230 | From Machinery Directive 2006/42/EC to 14 Jan 2027](/artifacts/eu/machinery-regulation/timeline-and-transition.md): A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/machinery-regulation/compliance --- --- title: "Conformity Assessment and CE Marking" canonical_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/conformity-assessment-and-ce" source_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/conformity-assessment-and-ce" author: "Sorena AI" description: "A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Machinery Regulation conformity assessment" - "Article 25 modules" - "Annex I Part A Part B route" - "Module A machinery regulation" - "EU type examination module B" - "full quality assurance module H" - "unit verification module G" - "CE marking notified body number" - "Article 25" - "Annex I" - "CE marking" - "notified body" - "technical documentation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Conformity Assessment and CE Marking A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H. *CE Marking* *EU* ## EU Machinery Regulation (EU) 2023/1230 Conformity Assessment and CE Marking A route-first workflow: Annex I -> Article 25 -> evidence -> CE marking. Output: technical file (Annex IV), declaration(s), and a market-ready labeling/instructions pack. Under Regulation (EU) 2023/1230, the conformity assessment route is not optional: Annex I classification and Article 25 determine whether you can use internal production control (Module A) or must involve a notified body (Modules B+C, H, or G). The fastest way to avoid expensive rework is to decide the route early and build the technical file and declarations to match that route from day one. ## 1) The route decision that matters: Annex I Part A vs Part B vs not listed Annex I categories trigger specific conformity assessment procedures. Part A categories must use Article 25(2) routes (third-party). Part B categories can use Article 25(3) routes (including Module A only under defined conditions). If the product is not listed in Annex I, Article 25(4) points to Module A (internal production control). - Part A: choose one of (B+C), H, or G (notified body involvement). - Part B: Module A only if designed/constructed per harmonised standards or common specifications for that category covering all relevant EHSR; otherwise use (B+C), H, or G. - Not listed: Module A under Article 25(4). ## 2) Article 25 procedures in plain language (what teams actually do) These modules are the 'compliance production line'. Pick the module, then build evidence and governance to fit it. Even with a notified body route, the manufacturer remains responsible for safety and evidence quality. - Module A (internal production control): you design/construct, test, compile technical file, issue DoC, affix CE mark. - Module B + C: notified body type-examines; you ensure production conforms to the examined type and control changes. - Module H (full quality assurance): quality system assessed; strong for complex/series production if implemented well. - Module G (unit verification): notified body verifies a specific unit; useful for bespoke/high-risk single machines. ## 3) Notified body implications: CE marking number and auditability When a notified body is involved in defined Article 25 procedures, the CE marking must be followed by the notified body identification number (per CE marking rules). Operational output: a clean audit trail of notified body engagement, decisions, and any conditions. - Plan notified body lead time early because Part A always needs a third-party route and many Part B families will also need one. - Freeze key hardware, software, and safety-function assumptions before assessment so the reviewed configuration is reproducible. - Keep a change-control rule set that tells you when new evidence is enough and when the notified body or route choice must be revisited. *Recommended next step* *Placement: after the main workflow section* ## Turn EU Machinery Regulation (EU) 2023/1230 Conformity Assessment and CE Marking into an operational assessment Assessment Autopilot can take EU Machinery Regulation (EU) 2023/1230 Conformity Assessment and CE Marking from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on EU Machinery Regulation (EU) 2023/1230 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Machinery Regulation (EU) 2023/1230 Conformity Assessment and CE Marking](/solutions/assessment.md): Start from EU Machinery Regulation (EU) 2023/1230 Conformity Assessment and CE Marking and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Machinery Regulation (EU) 2023/1230](/contact.md): Review your current process, evidence gaps, and next steps for EU Machinery Regulation (EU) 2023/1230 Conformity Assessment and CE Marking. ## 4) Technical documentation (Annex IV): build it as an evidence system Annex IV Part A sets technical documentation minimum elements for machinery/related products. Part B covers partly completed machinery. A high-quality technical file shows how risk assessment drives protective measures and how evidence maps to essential health and safety requirements (Annex III). - Description + intended use; design drawings/schematics; explanations of operation. - Risk assessment documentation: applicable EHSR list + protective measures + residual risks. - Standards/common specs references (full/partial application noted) + alternative specs where needed. - Verification evidence: tests/inspections/examinations; production controls to ensure series conformity. - Instructions pack and, where applicable, declarations for incorporated products under other EU acts. ## 5) Declarations: DoC vs Declaration of Incorporation (and digital access obligations) Machinery and related products ship with an EU declaration of conformity. Partly completed machinery ships with a declaration of incorporation and assembly instructions. Digital delivery is allowed in defined ways, but teams must test the access conditions instead of assuming a hosted PDF is enough. - The DoC may be delivered in the instructions by internet address or machine-readable code when Article 10 allows it. - Digital instructions must be printable, downloadable, and savable, and users may request paper copies free of charge within one month. - For partly completed machinery, digital assembly instructions and the declaration of incorporation must remain accessible online for 10 years. ## 6) Practical CE release gate (what to check before placing on the market) Use this as a release checklist regardless of module. It prevents the 'surface compliance' failures that trigger market surveillance escalations. If you cannot export the evidence pack quickly, your program is not operational. - Annex I classification + Article 25 route memo approved and stored. - Risk assessment complete (Annex III general principles) and mapped to EHSR evidence. - Technical file index complete (Annex IV Part A/B) with stable filenames and versions. - Declarations issued (DoC/DoI) and translated as required; CE mark applied correctly; notified body number included when required. - Instructions/assembly instructions included (paper or digital access compliant); traceability labeling verified. ## Primary sources - [Regulation (EU) 2023/1230 corrigendum - Article 25, Annex I, and declaration rules (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/corrigendum/2023-07-04/oj/eng?ref=sorena.io) - Primary source for Annex I route logic, conformity assessment modules, and digital declaration or instruction conditions. - [Regulation (EC) No 765/2008 - CE marking general principles (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2008/765/oj/eng?ref=sorena.io) - Primary source for CE marking general principles and placement rules. - [Regulation (EU) 2019/1020 - market surveillance (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Relevant horizontal framework for compliance evidence and corrective-action follow-through. ## Related Topic Guides - [Applicability Test | EU Machinery Regulation (EU) 2023/1230 | In Scope? Annex I? Article 25 Route?](/artifacts/eu/machinery-regulation/applicability-test.md): A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery. - [Checklist | EU Machinery Regulation (EU) 2023/1230 | CE Marking Readiness Checklist (Route + Technical File + Declarations)](/artifacts/eu/machinery-regulation/checklist.md): An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2). - [Compliance Program | EU Machinery Regulation (EU) 2023/1230 | Operating Model, Controls, Transition to 2027](/artifacts/eu/machinery-regulation/compliance.md): Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control. - [Deadlines and Compliance Calendar | EU Machinery Regulation (EU) 2023/1230 | Transition to 14 Jan 2027 + Route and Evidence Milestones](/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar.md): A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. - [FAQ | EU Machinery Regulation (EU) 2023/1230 | Scope, Annex I, Article 25, Technical File, Software](/artifacts/eu/machinery-regulation/faq.md): High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route. - [Machinery Regulation vs EU AI Act | Smart machinery, safety components, high-risk AI](/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act.md): A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6). - [Machinery Regulation vs Machinery Directive | Regulation (EU) 2023/1230 vs Directive 2006/42/EC | Key Changes + Migration Plan](/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive.md): A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates. - [Penalties and Fines | EU Machinery Regulation (EU) 2023/1230 | Article 50, Enforcement, Corrective Actions](/artifacts/eu/machinery-regulation/penalties-and-fines.md): A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline. - [Requirements | EU Machinery Regulation (EU) 2023/1230 | EHSR (Annex III), Technical File (Annex IV), Article 25 Route](/artifacts/eu/machinery-regulation/requirements.md): An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence. - [Risk Assessment Method | EU Machinery Regulation (EU) 2023/1230 | Annex III General Principles Workflow](/artifacts/eu/machinery-regulation/risk-assessment-method.md): A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles. - [Scope and Machine Categories | EU Machinery Regulation (EU) 2023/1230 | Machinery, Related Products, Partly Completed Machinery, Annex I](/artifacts/eu/machinery-regulation/scope-and-machine-categories.md): A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment. - [Software and Cybersecurity Considerations | EU Machinery Regulation (EU) 2023/1230 | Control Systems, Protection Against Corruption, Logs](/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations.md): A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption. - [Technical Documentation and Technical File | EU Machinery Regulation (EU) 2023/1230 | Annex IV Part A/B Checklist + Structure](/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file.md): A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping. - [Templates | EU Machinery Regulation (EU) 2023/1230 | Route Memo, Annex IV Technical File Index, DoC/DoI, Risk Assessment Mapping](/artifacts/eu/machinery-regulation/machinery-ce-documentation-template.md): Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note. - [Timeline and Transition | EU Machinery Regulation (EU) 2023/1230 | From Machinery Directive 2006/42/EC to 14 Jan 2027](/artifacts/eu/machinery-regulation/timeline-and-transition.md): A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/machinery-regulation/conformity-assessment-and-ce --- --- title: "Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Machinery Regulation deadlines" - "machinery regulation timeline 2027" - "Regulation (EU) 2023/1230 application date" - "penalties notification 14 October 2026" - "machinery regulation transition plan" - "Article 25 notified body lead time" - "deadlines" - "calendar" - "transition" - "notified body" - "technical file" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Deadlines and Compliance Calendar A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. *Calendar* *EU* ## EU Machinery Regulation (EU) 2023/1230 Deadlines and Compliance Calendar A transition and execution calendar from entry into force to 14 January 2027. Focus: Annex I routing, Article 6 reporting, digital-document readiness, notified body lead times, and market readiness gates. The corrigendum to Regulation (EU) 2023/1230 fixes the key transition dates: the Regulation entered into force on 19 July 2023 and applies from 14 January 2027. Several provisions apply earlier, Member States and the Commission have Article 6 reporting milestones in 2025 and 2026, and products already placed on the market under Directive 2006/42/EC need a defensible transition record. This page turns those dates into an execution plan. ## 1) Key dates you should put into the program plan Use absolute dates in your tracker and keep the corrigendum dates, not older summary-page dates, in the master schedule. The high-value control is one shared timeline used by engineering, regulatory, quality, and commercial teams. - 14 June 2023: Regulation (EU) 2023/1230 adopted. - 29 June 2023: Regulation published in the Official Journal. - 19 July 2023: Regulation entered into force; Article 6(7) and Articles 48 and 52 started to apply. - 14 January 2024: Articles 26 to 42 started to apply. - 20 July 2024: Article 6(2) to (6), (8) and (11), Article 47, and Article 53(3) started to apply. - 14 July 2025: Member States must provide Article 6(5) data and information, and repeat every five years. - 20 July 2026: Commission specific report on Article 6(4) and (5). - 14 October 2026: Member States notify penalty rules to the Commission. - 14 January 2027: main application date and repeal of Directive 2006/42/EC. ## 2) Transition handling for products already placed on the market Products lawfully placed on the market under Directive 2006/42/EC before 14 January 2027 can continue to circulate, but that only works if your placed-on-market evidence is complete. For legacy products, Chapter VI market-surveillance rules apply from 19 July 2023 mutatis mutandis instead of Directive Article 11. - Store the date of placing on the market, the directive-based declaration version, the technical-file snapshot, and the exact product identifier for each model. - Do not mix a directive-era declaration with Regulation 2023/1230 technical-file language in the same release pack. - Build a decision memo per family: continue under Directive 2006/42/EC until depletion, or migrate early to Regulation 2023/1230. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU Machinery Regulation (EU) 2023/1230 Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take EU Machinery Regulation (EU) 2023/1230 Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Machinery Regulation (EU) 2023/1230 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Machinery Regulation (EU) 2023/1230 Deadlines and Compliance Calendar](/solutions/assessment.md): Start from EU Machinery Regulation (EU) 2023/1230 Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Machinery Regulation (EU) 2023/1230](/contact.md): Review your current process, evidence gaps, and next steps for EU Machinery Regulation (EU) 2023/1230 Deadlines and Compliance Calendar. ## 3) 2024 and 2025 priorities: route discovery and evidence build The main schedule risk is late discovery that a family belongs in Annex I Part A or Part B and therefore needs a different Article 25 route. Finish classification and evidence architecture before you enter the 2026 bottleneck window. - Run scope and exclusion checks for each family: machinery, related product, or partly completed machinery. - Classify Annex I Part A, Part B, or not listed, and record why. - Map Article 25 route logic, including when Part B may still use Module A because harmonised standards or common specifications cover all relevant EHSR. - Build Annex III hazard and EHSR mappings plus Annex IV index structures while product knowledge is still current. - Stand up digital-instructions, declaration-link, and software-log retention controls in the same workstream. ## 4) 2026 priorities: finish the operating model, not just the documents 2026 is the year to prove the workflow is operational: document access, signatory control, technical-file retrieval, and notified body interaction all need dry runs. Treat 2026 as a systems-integration year for compliance. - Freeze route outcomes, complete notified body assessments where required, and control configuration changes. - Validate that digital instructions can be printed, downloaded, saved, and requested in paper within one month. - Verify that DoC or DoI links, machine-readable codes, and version histories match the shipped configuration. - Test a response pack export for market surveillance: index, declarations, instructions, core reports, and software evidence. ## Primary sources - [Regulation (EU) 2023/1230 corrigendum - Article 54 and Article 50 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/corrigendum/2023-07-04/oj/eng?ref=sorena.io) - Primary source for entry into force, application dates, earlier-applying provisions, and the Member State penalty notification deadline. - [Regulation (EU) 2023/1230 - Article 6 reporting obligations (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/corrigendum/2023-07-04/oj/eng?ref=sorena.io) - Primary source for Member State data reporting and Commission review timing under Article 6. - [Commission Implementing Regulation (EU) 2024/1922 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_impl/2024/1922/oj/eng?ref=sorena.io) - Official template for Article 6(5) Member State data collection. - [Directive 2006/42/EC - Machinery Directive (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2006/42/oj?ref=sorena.io) - Legacy framework relevant to products placed on the market before 14 January 2027. ## Related Topic Guides - [Applicability Test | EU Machinery Regulation (EU) 2023/1230 | In Scope? Annex I? Article 25 Route?](/artifacts/eu/machinery-regulation/applicability-test.md): A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery. - [Checklist | EU Machinery Regulation (EU) 2023/1230 | CE Marking Readiness Checklist (Route + Technical File + Declarations)](/artifacts/eu/machinery-regulation/checklist.md): An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2). - [Compliance Program | EU Machinery Regulation (EU) 2023/1230 | Operating Model, Controls, Transition to 2027](/artifacts/eu/machinery-regulation/compliance.md): Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control. - [Conformity Assessment and CE Marking | EU Machinery Regulation (EU) 2023/1230 | Article 25 Modules, Annex I, DoC/DoI](/artifacts/eu/machinery-regulation/conformity-assessment-and-ce.md): A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H. - [FAQ | EU Machinery Regulation (EU) 2023/1230 | Scope, Annex I, Article 25, Technical File, Software](/artifacts/eu/machinery-regulation/faq.md): High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route. - [Machinery Regulation vs EU AI Act | Smart machinery, safety components, high-risk AI](/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act.md): A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6). - [Machinery Regulation vs Machinery Directive | Regulation (EU) 2023/1230 vs Directive 2006/42/EC | Key Changes + Migration Plan](/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive.md): A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates. - [Penalties and Fines | EU Machinery Regulation (EU) 2023/1230 | Article 50, Enforcement, Corrective Actions](/artifacts/eu/machinery-regulation/penalties-and-fines.md): A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline. - [Requirements | EU Machinery Regulation (EU) 2023/1230 | EHSR (Annex III), Technical File (Annex IV), Article 25 Route](/artifacts/eu/machinery-regulation/requirements.md): An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence. - [Risk Assessment Method | EU Machinery Regulation (EU) 2023/1230 | Annex III General Principles Workflow](/artifacts/eu/machinery-regulation/risk-assessment-method.md): A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles. - [Scope and Machine Categories | EU Machinery Regulation (EU) 2023/1230 | Machinery, Related Products, Partly Completed Machinery, Annex I](/artifacts/eu/machinery-regulation/scope-and-machine-categories.md): A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment. - [Software and Cybersecurity Considerations | EU Machinery Regulation (EU) 2023/1230 | Control Systems, Protection Against Corruption, Logs](/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations.md): A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption. - [Technical Documentation and Technical File | EU Machinery Regulation (EU) 2023/1230 | Annex IV Part A/B Checklist + Structure](/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file.md): A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping. - [Templates | EU Machinery Regulation (EU) 2023/1230 | Route Memo, Annex IV Technical File Index, DoC/DoI, Risk Assessment Mapping](/artifacts/eu/machinery-regulation/machinery-ce-documentation-template.md): Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note. - [Timeline and Transition | EU Machinery Regulation (EU) 2023/1230 | From Machinery Directive 2006/42/EC to 14 Jan 2027](/artifacts/eu/machinery-regulation/timeline-and-transition.md): A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar --- --- title: "FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/faq" source_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/faq" author: "Sorena AI" description: "High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Machinery Regulation FAQ" - "Regulation (EU) 2023/1230 FAQ" - "Annex I Part A Part B FAQ" - "Article 25 modules FAQ" - "notified body required machinery regulation" - "technical file Annex IV FAQ" - "protection against corruption Annex III FAQ" - "FAQ" - "Annex I" - "Article 25" - "technical documentation" - "transition" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FAQ High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route. *FAQ* *EU* ## EU Machinery Regulation (EU) 2023/1230 FAQ Clear answers with practical next steps. Use this to unblock engineering, quality, and regulatory teams. This FAQ is written for teams building route decisions and technical files, not for academic interpretation. Where answers depend on product specifics, each response tells you what facts to collect and which artifacts to produce. ## Scope and exclusions Q: What products are in scope? A: The Regulation covers machinery, related products, and partly completed machinery. Related products include interchangeable equipment, safety components including software, lifting accessories, chains, ropes and webbing, and removable mechanical transmission devices. Q: What is excluded? A: Article 2 lists exclusions such as certain fairground equipment, weapons, some transport-sector products, and specified electrical or radio products where other EU sector legislation governs the risk. Keep a short exclusion memo and record why each likely exclusion does or does not apply. - Best practice: maintain a one-page scope memo with an 'exclusions checked' section. - Classify product type explicitly: machinery vs partly completed machinery changes declarations and documentation. ## Annex I and Article 25 (route selection) Q: Why does Annex I matter so much? A: Annex I controls the Article 25 route. Part A always goes to third-party routes. Part B may still use Module A, but only when harmonised standards or common specifications cover all relevant EHSR for that category and are fully applied. Q: When do we need a notified body? A: Always for Annex I Part A. Often for Part B unless the Module A condition is satisfied. When the chosen procedure involves a notified body, its identification number must follow the CE mark. - Notified body involved in defined procedures -> CE marking must be followed by the notified body ID number. - Keep a route decision memo with change triggers (what changes force re-assessment). ## Technical file and risk assessment Q: What has to be in the technical documentation? A: Annex IV is the minimum content list. The file must show the risk-assessment logic, the applicable EHSR, the protective measures, the verification evidence, and the controlled outputs such as instructions and declarations. Q: What is the practical risk-assessment method? A: Define limits and intended use, identify hazards and hazardous situations, estimate and evaluate risk, apply the safety-integration hierarchy, and record residual risks and verification evidence. - Index your technical file so a reviewer can trace EHSR -> protective measure -> test evidence. - Use stable filenames and keep a response pack export ready. ## Software and cybersecurity Q: What does the Regulation require for software? A: It requires protection against corruption, identification of installed software necessary for safe operation, evidence of legitimate or illegitimate intervention, and retention of certain software-related logs for fixed periods. Q: Can authorities ask for source code? A: Yes. Annex IV allows safety-related source code or programming logic to be requested where necessary to verify compliance with the relevant essential health and safety requirements. - Retain the tracing log of intervention data and uploaded safety-software versions for five years after upload. - Retain safety-related decision-making data for software-based safety systems for one year after collection. - Keep the software evidence bundle tied to the technical-file index and product version. ## Partly completed machinery Q: What ships with partly completed machinery? A: Assembly instructions, the declaration of incorporation, and the Annex IV Part B technical documentation set. Q: Can those documents be digital? A: Yes, but the access conditions matter. Assembly instructions must be printable, downloadable, and savable, paper copies must be available free of charge within one month on request, and digital access must remain online for 10 years. - Don't mix DoC and DoI workflows - keep separate templates and indexes. - Treat digital document delivery as part of product compliance (versioning and accessibility). ## Transition and timing Q: When does the Regulation apply? A: The corrigendum confirms entry into force on 19 July 2023 and general application from 14 January 2027, with several provisions applying earlier under Article 54. Q: What should teams do now? A: Finish product-family scope and Annex I classification, decide the Article 25 route, stand up digital-instructions and declaration controls, and make software evidence retrievable before 2027. - Use a product-family transition tracker and reach 'assessment-ready' state before 2026 ends. - Track penalty rules notification timing (Member States notify the Commission by 14 October 2026). *Recommended next step* *Placement: after the FAQ section* ## Use EU Machinery Regulation (EU) 2023/1230 FAQ as a cited research workflow Research Copilot can take EU Machinery Regulation (EU) 2023/1230 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU Machinery Regulation (EU) 2023/1230 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Machinery Regulation (EU) 2023/1230 FAQ](/solutions/research-copilot.md): Start from EU Machinery Regulation (EU) 2023/1230 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Machinery Regulation (EU) 2023/1230](/contact.md): Review your current process, evidence gaps, and next steps for EU Machinery Regulation (EU) 2023/1230 FAQ. ## Primary sources - [Regulation (EU) 2023/1230 corrigendum - machinery regulation (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/corrigendum/2023-07-04/oj/eng?ref=sorena.io) - Primary source for scope, Annex I routing, software duties, digital-document rules, and timing. - [Directive 2006/42/EC - Machinery Directive (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2006/42/oj?ref=sorena.io) - Legacy framework relevant to transition questions. ## Related Topic Guides - [Applicability Test | EU Machinery Regulation (EU) 2023/1230 | In Scope? Annex I? Article 25 Route?](/artifacts/eu/machinery-regulation/applicability-test.md): A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery. - [Checklist | EU Machinery Regulation (EU) 2023/1230 | CE Marking Readiness Checklist (Route + Technical File + Declarations)](/artifacts/eu/machinery-regulation/checklist.md): An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2). - [Compliance Program | EU Machinery Regulation (EU) 2023/1230 | Operating Model, Controls, Transition to 2027](/artifacts/eu/machinery-regulation/compliance.md): Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control. - [Conformity Assessment and CE Marking | EU Machinery Regulation (EU) 2023/1230 | Article 25 Modules, Annex I, DoC/DoI](/artifacts/eu/machinery-regulation/conformity-assessment-and-ce.md): A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H. - [Deadlines and Compliance Calendar | EU Machinery Regulation (EU) 2023/1230 | Transition to 14 Jan 2027 + Route and Evidence Milestones](/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar.md): A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. - [Machinery Regulation vs EU AI Act | Smart machinery, safety components, high-risk AI](/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act.md): A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6). - [Machinery Regulation vs Machinery Directive | Regulation (EU) 2023/1230 vs Directive 2006/42/EC | Key Changes + Migration Plan](/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive.md): A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates. - [Penalties and Fines | EU Machinery Regulation (EU) 2023/1230 | Article 50, Enforcement, Corrective Actions](/artifacts/eu/machinery-regulation/penalties-and-fines.md): A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline. - [Requirements | EU Machinery Regulation (EU) 2023/1230 | EHSR (Annex III), Technical File (Annex IV), Article 25 Route](/artifacts/eu/machinery-regulation/requirements.md): An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence. - [Risk Assessment Method | EU Machinery Regulation (EU) 2023/1230 | Annex III General Principles Workflow](/artifacts/eu/machinery-regulation/risk-assessment-method.md): A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles. - [Scope and Machine Categories | EU Machinery Regulation (EU) 2023/1230 | Machinery, Related Products, Partly Completed Machinery, Annex I](/artifacts/eu/machinery-regulation/scope-and-machine-categories.md): A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment. - [Software and Cybersecurity Considerations | EU Machinery Regulation (EU) 2023/1230 | Control Systems, Protection Against Corruption, Logs](/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations.md): A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption. - [Technical Documentation and Technical File | EU Machinery Regulation (EU) 2023/1230 | Annex IV Part A/B Checklist + Structure](/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file.md): A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping. - [Templates | EU Machinery Regulation (EU) 2023/1230 | Route Memo, Annex IV Technical File Index, DoC/DoI, Risk Assessment Mapping](/artifacts/eu/machinery-regulation/machinery-ce-documentation-template.md): Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note. - [Timeline and Transition | EU Machinery Regulation (EU) 2023/1230 | From Machinery Directive 2006/42/EC to 14 Jan 2027](/artifacts/eu/machinery-regulation/timeline-and-transition.md): A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/machinery-regulation/faq --- --- title: "Templates" canonical_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/machinery-ce-documentation-template" source_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/machinery-ce-documentation-template" author: "Sorena AI" description: "Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Machinery Regulation template" - "machinery regulation technical file template" - "Annex IV index template" - "Article 25 route memo template" - "EU declaration of conformity machinery template" - "declaration of incorporation template" - "EHSR mapping template" - "templates" - "Annex IV" - "DoC" - "DoI" - "Article 25" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Templates Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note. *Templates* *EU* ## EU Machinery Regulation (EU) 2023/1230 Templates Reusable artifacts for route decisions and CE evidence packs. Copy/paste these into your technical file system and keep them versioned. These templates reflect what reviewers actually look for: a defensible route decision, a risk assessment-to-EHSR map, and an exportable Annex IV technical file index. Use them per product family and link every field to evidence locations and versions. ## 1) Scope memo template (Article 2 + product type) Purpose: a one-page, defensible scope decision per product family. - Product ID: model(s), variants, intended use, environment, operators/exposed persons. - Product type: machinery / related product (which one) / partly completed machinery / safety component (incl. software). - Exclusions checklist (Article 2(2)): list each relevant exclusion and mark 'not applicable' with rationale. - Electrical products exclusion check: confirm whether the product is excluded insofar as it falls under LVD/RED categories. - Applicable legislation list: include other EU acts if incorporated products require them (for DoC/DoI statements). *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Machinery Regulation (EU) 2023/1230 Templates in one governed evidence system SSOT can take EU Machinery Regulation (EU) 2023/1230 Templates from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Machinery Regulation (EU) 2023/1230 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Machinery Regulation (EU) 2023/1230 Templates](/solutions/ssot.md): Start from EU Machinery Regulation (EU) 2023/1230 Templates and keep documents, evidence, and control records in one governed system. - [Talk through EU Machinery Regulation (EU) 2023/1230](/contact.md): Review your current process, evidence gaps, and next steps for EU Machinery Regulation (EU) 2023/1230 Templates. ## 2) Annex I classification note (Part A / Part B / not listed) Purpose: a precise category match that drives the Article 25 route. - Annex I match: exact item number and sub-item where applicable. - Rationale: product facts that match the category definition. - Boundary: which parts/systems are covered by the category match (especially for embedded systems). - Decision: Part A / Part B / not listed; link to route memo. ## 3) Article 25 route decision memo template Purpose: a route decision that is stable and reviewable (and defines change triggers). - Selected procedure: Article 25(2) (B+C / H / G) or Article 25(3) or 25(4) (Module A). - If Part B + Module A: evidence that harmonised standards/common specs for that category cover all relevant EHSR and are applied. - Notified body involvement plan (if applicable): scope, schedule, evidence readiness date, change control triggers. - CE marking implications: include notified body identification number when required. - Outputs: technical file index + declarations + release gate checklist. ## 4) Annex III risk assessment and EHSR mapping table (EHSR -> measures -> evidence) Purpose: a single mapping table that connects the safety case to evidence artifacts. - EHSR (Annex III) | Hazard/hazardous situation | Protective measure | Verification method | Evidence ID | Residual risk + instruction reference - Include lifecycle phases and foreseeable misuse assumptions in the header. - Include autonomy/self-evolving behavior and system interaction hazards where relevant. ## 5) Annex IV technical file index template (Part A/B) Purpose: an exportable index that makes the file reviewable in minutes. - 00-Index/: scope memo, Annex I note, route memo, index.pdf/json - 01-Risk/: hazard log, EHSR mapping table, residual risks register - 02-Design/: drawings, schematics, safety functions description - 03-Standards/: standards/common specs register, clause mapping, update log - 04-Verification/: test plan, test reports, inspections, calculations - 05-Production/: series conformity controls - 06-Instructions/: instructions for use, translations; assembly instructions if partly completed - 07-Declarations/: DoC/DoI, history, signatory evidence - 08-Software-Control/: software inventory, intervention logs, validation summaries (as applicable) ## 6) EU Declaration of Conformity (DoC) skeleton Purpose: a DoC that matches the route, evidence pack, and any incorporated-product obligations. - Product identification; manufacturer details; authorised representative (if any). - Statement of sole responsibility. - Applicable Union harmonisation legislation: include Regulation (EU) 2023/1230 and any other applicable acts for incorporated products (where relevant). - Standards/common specifications references (with versions). - If notified body involved: include certificate references and ensure CE marking number handling is consistent. - Signatory details (name, function, place/date, signature). ## 7) Partly completed machinery pack: Declaration of Incorporation + assembly instructions checklist Purpose: a coherent pack for incorporation customers and for authority requests. - Declaration of Incorporation (DoI) issued and kept updated; translated as required. - Assembly instructions provided and aligned to residual risks and incorporation conditions. - Digital provision policy defined where used: users must be able to print/download and access during breakdowns; online accessibility period tracked where applicable. - Annex IV Part B technical documentation index complete. ## 8) Notified body assessment pack outline (for Annex I routes) Purpose: reduce notified body cycle time with a clean evidence narrative. - Route memo + Annex I classification + system boundaries. - EHSR mapping summary and key protective measures narrative. - Key verification evidence set (representative tests, inspections, calculations). - Change history and configuration control (software versions, safety functions versions). ## Primary sources - [Regulation (EU) 2023/1230 - Annex I (categories), Article 25 (procedures), Annex III (EHSR), Annex IV (technical documentation) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/oj?ref=sorena.io) - Primary structure for route decisions, risk assessment mapping, and technical file content. - [European Commission - Machinery (Single Market) page](https://single-market-economy.ec.europa.eu/sectors/mechanical-engineering/machinery_en?ref=sorena.io) - Commission overview and entry point for notified bodies and sector resources. ## Related Topic Guides - [Applicability Test | EU Machinery Regulation (EU) 2023/1230 | In Scope? Annex I? Article 25 Route?](/artifacts/eu/machinery-regulation/applicability-test.md): A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery. - [Checklist | EU Machinery Regulation (EU) 2023/1230 | CE Marking Readiness Checklist (Route + Technical File + Declarations)](/artifacts/eu/machinery-regulation/checklist.md): An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2). - [Compliance Program | EU Machinery Regulation (EU) 2023/1230 | Operating Model, Controls, Transition to 2027](/artifacts/eu/machinery-regulation/compliance.md): Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control. - [Conformity Assessment and CE Marking | EU Machinery Regulation (EU) 2023/1230 | Article 25 Modules, Annex I, DoC/DoI](/artifacts/eu/machinery-regulation/conformity-assessment-and-ce.md): A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H. - [Deadlines and Compliance Calendar | EU Machinery Regulation (EU) 2023/1230 | Transition to 14 Jan 2027 + Route and Evidence Milestones](/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar.md): A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. - [FAQ | EU Machinery Regulation (EU) 2023/1230 | Scope, Annex I, Article 25, Technical File, Software](/artifacts/eu/machinery-regulation/faq.md): High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route. - [Machinery Regulation vs EU AI Act | Smart machinery, safety components, high-risk AI](/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act.md): A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6). - [Machinery Regulation vs Machinery Directive | Regulation (EU) 2023/1230 vs Directive 2006/42/EC | Key Changes + Migration Plan](/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive.md): A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates. - [Penalties and Fines | EU Machinery Regulation (EU) 2023/1230 | Article 50, Enforcement, Corrective Actions](/artifacts/eu/machinery-regulation/penalties-and-fines.md): A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline. - [Requirements | EU Machinery Regulation (EU) 2023/1230 | EHSR (Annex III), Technical File (Annex IV), Article 25 Route](/artifacts/eu/machinery-regulation/requirements.md): An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence. - [Risk Assessment Method | EU Machinery Regulation (EU) 2023/1230 | Annex III General Principles Workflow](/artifacts/eu/machinery-regulation/risk-assessment-method.md): A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles. - [Scope and Machine Categories | EU Machinery Regulation (EU) 2023/1230 | Machinery, Related Products, Partly Completed Machinery, Annex I](/artifacts/eu/machinery-regulation/scope-and-machine-categories.md): A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment. - [Software and Cybersecurity Considerations | EU Machinery Regulation (EU) 2023/1230 | Control Systems, Protection Against Corruption, Logs](/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations.md): A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption. - [Technical Documentation and Technical File | EU Machinery Regulation (EU) 2023/1230 | Annex IV Part A/B Checklist + Structure](/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file.md): A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping. - [Timeline and Transition | EU Machinery Regulation (EU) 2023/1230 | From Machinery Directive 2006/42/EC to 14 Jan 2027](/artifacts/eu/machinery-regulation/timeline-and-transition.md): A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/machinery-regulation/machinery-ce-documentation-template --- --- title: "Machinery Regulation vs EU AI Act" canonical_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act" source_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act" author: "Sorena AI" description: "A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Machinery Regulation vs EU AI Act" - "EU Machinery Regulation AI" - "AI safety component machinery" - "high-risk AI system safety component" - "EU AI Act Article 6 safety component" - "AI Act Article 25 value chain responsibilities" - "AI technical documentation for CE marking" - "machine safety AI compliance" - "EU compliance" - "EU Machinery Regulation compliance" - "high-risk AI system" - "safety component" - "technical documentation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Machinery Regulation vs EU AI Act A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6). *Artifact Guide* *EU* ## EU Machinery Regulation Machinery Regulation vs EU AI Act How to comply when AI is part of your machine's safety case. Classify the AI, map who is the provider, and build one evidence pack that works for both the Machinery Regulation and the EU AI Act. For connected or intelligent machinery, "EU Machinery Regulation compliance" is often inseparable from "EU AI Act compliance". The overlap is sharpest when an AI system is used as a safety component (or is itself a product) under EU harmonisation law and the product requires third-party conformity assessment: the AI Act treats that AI system as a high-risk AI system (Article 6). Your practical goal is to avoid duplicate work by aligning: (1) the Machinery Regulation risk assessment and technical file (Annex III + Annex IV) and (2) the AI Act's high-risk AI requirements (risk management, data governance, logs, human oversight, robustness/cybersecurity, conformity assessment and CE marking). ## 1) When does the EU AI Act apply to machinery? The EU AI Act creates a high-risk category for AI used as a safety component of a product covered by EU harmonisation law (Annex I) when that product requires third-party conformity assessment for placing on the market or putting into service (Article 6(1)). For machinery, this often maps to product families that fall into notified-body routes under the Machinery Regulation (Annex I + Article 25). In other words: if your "AI-enabled safety function" is part of a CE-marked machinery safety case and you need a third-party route for the product category, treat the AI as a high-risk AI system and plan to meet both evidence expectations. - High-risk trigger: AI is a safety component (or product) + product is in Annex I AI Act + product requires third-party conformity assessment under the sector law. - Don't confuse "smart features" with "safety components": focus on functions that reduce risk, prevent hazardous situations, or control protective measures. - Plan your route early: notified-body dependencies impact lead times, evidence depth, and change-control expectations. ## 2) Who is the AI Act "provider" in a machinery supply chain? For integrated products, the AI Act pushes responsibilities up the chain. In the case of high-risk AI systems that are safety components of products covered by certain EU harmonisation legislation, the product manufacturer is considered the provider of the high-risk AI system in specified circumstances (Article 25(3)). The AI Act also treats certain re-branding, intended-purpose changes, or substantial modifications as provider triggers (Article 25(1)). This matters for machinery manufacturers who fine-tune models, swap perception stacks, or change intended use (for example from "operator assistance" to "operator protection"). - Role map your product: machine manufacturer, safety integrator, AI component supplier, deployer/operator, importer/distributor. - Contract for compliance: require written commitments for technical access, documentation, and assistance so you can meet provider obligations (Article 25(4)). - Treat "model updates" as compliance events: define what counts as a substantial modification and enforce change-control gates. ## 3) Build one evidence pack: AI Act requirements inside the Machinery technical file A smart way to avoid duplicate work is to align your AI Act high-risk evidence with the Machinery Regulation's technical documentation and risk assessment structure. The AI Act requires a lifecycle risk management system (Article 9), data and data governance controls for trained systems (Article 10), and provider duties including documentation keeping, log retention, conformity assessment, declaration of conformity and CE marking for the high-risk AI system (Article 16). The Machinery Regulation technical file expects a coherent safety case: risk assessment, protective measures, residual risk rationale, tests/verification, and (when relevant) software and control-system evidence (Annex IV). For AI-driven safety functions, make the mapping explicit: hazard -> AI failure mode -> mitigation -> verification -> monitoring trigger. - Risk management: define AI safety hazards, autonomy boundaries, foreseeable misuse, and residual-risk acceptance criteria (AI Act Article 9 + Machinery risk assessment). - Data governance: document training/validation/test data provenance and quality controls for safety-relevant ML behavior (AI Act Article 10). - Logging + traceability: define what the system logs automatically, how logs are protected, and how you reconstruct safety-relevant events (AI Act Article 16(e) + Machinery software integrity and logging expectations). - Human oversight: specify where humans can override, stop, or degrade gracefully to a safe state; design alarms and "safe mode" behaviors for AI uncertainty. - Robustness + cybersecurity: unify your safety argument with corruption protection, update integrity, secure deployment pipelines, and monitored drift. ## 4) Conformity assessment and CE marking: reduce duplicate audits The Machinery Regulation route is selected via Annex I category logic and Article 25 modules; some categories require third-party involvement. The AI Act requires providers of high-risk AI systems to ensure the relevant conformity assessment procedure is completed before placing on the market or putting into service, and to draw up declarations and affix CE marking for the high-risk AI system (Article 16). For AI as a safety component in machinery, you want a single combined technical narrative: a product safety case with an embedded AI safety case. Practically, this means one cross-referenced evidence index, consistent versioning, and a change log that both machinery safety reviewers and AI compliance reviewers can follow. - Create a shared evidence index: map Machinery EHSR -> AI Act requirement -> artifact(s) -> owner -> update cadence. - Unify version control: release identifiers for model, data, software, and configuration; link them to test evidence and declarations. - Pre-align notified body expectations: share the AI safety architecture, logging strategy, and update-control rules early. ## 5) Combined timeline planning (don't get caught by staggered dates) The two frameworks phase in on different schedules. The AI Act entered into force on 1 August 2024 and applies on a staggered timetable, while the Machinery Regulation entered into force on 19 July 2023 and applies generally from 14 January 2027. If you ship AI-enabled machinery, run one roadmap: machinery route selection, software evidence, and technical-file modernization first, then AI Act high-risk controls layered into the same governed evidence system. - Now: inventory AI-enabled safety functions and classify which ones are safety components vs non-safety features. - Before 2027: modernize technical files and implement change-control + logging + cybersecurity baseline for AI safety functions. - By 2027+: be ready for AI Act high-risk obligations for AI safety components tied to third-party conformity assessment routes. *Recommended next step* *Placement: after the comparison section* ## Use EU Machinery Regulation Machinery Regulation vs EU AI Act as a cited research workflow Research Copilot can take EU Machinery Regulation Machinery Regulation vs EU AI Act from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Machinery Regulation can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Machinery Regulation Machinery Regulation vs EU AI Act](/solutions/research-copilot.md): Start from EU Machinery Regulation Machinery Regulation vs EU AI Act and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Machinery Regulation](/contact.md): Review your current process, evidence gaps, and next steps for EU Machinery Regulation Machinery Regulation vs EU AI Act. ## Primary sources - [Regulation (EU) 2023/1230 corrigendum - machinery regulation (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/corrigendum/2023-07-04/oj/eng?ref=sorena.io) - Primary source for machinery scope, Annex I and Article 25 route logic, Annex III and Annex IV evidence, and corrected timing. - [Regulation (EU) 2024/1689 - AI Act (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng?ref=sorena.io) - Primary source for high-risk AI classification, provider obligations, and staggered AI Act application timing. ## Related Topic Guides - [Applicability Test | EU Machinery Regulation (EU) 2023/1230 | In Scope? Annex I? Article 25 Route?](/artifacts/eu/machinery-regulation/applicability-test.md): A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery. - [Checklist | EU Machinery Regulation (EU) 2023/1230 | CE Marking Readiness Checklist (Route + Technical File + Declarations)](/artifacts/eu/machinery-regulation/checklist.md): An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2). - [Compliance Program | EU Machinery Regulation (EU) 2023/1230 | Operating Model, Controls, Transition to 2027](/artifacts/eu/machinery-regulation/compliance.md): Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control. - [Conformity Assessment and CE Marking | EU Machinery Regulation (EU) 2023/1230 | Article 25 Modules, Annex I, DoC/DoI](/artifacts/eu/machinery-regulation/conformity-assessment-and-ce.md): A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H. - [Deadlines and Compliance Calendar | EU Machinery Regulation (EU) 2023/1230 | Transition to 14 Jan 2027 + Route and Evidence Milestones](/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar.md): A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. - [FAQ | EU Machinery Regulation (EU) 2023/1230 | Scope, Annex I, Article 25, Technical File, Software](/artifacts/eu/machinery-regulation/faq.md): High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route. - [Machinery Regulation vs Machinery Directive | Regulation (EU) 2023/1230 vs Directive 2006/42/EC | Key Changes + Migration Plan](/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive.md): A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates. - [Penalties and Fines | EU Machinery Regulation (EU) 2023/1230 | Article 50, Enforcement, Corrective Actions](/artifacts/eu/machinery-regulation/penalties-and-fines.md): A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline. - [Requirements | EU Machinery Regulation (EU) 2023/1230 | EHSR (Annex III), Technical File (Annex IV), Article 25 Route](/artifacts/eu/machinery-regulation/requirements.md): An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence. - [Risk Assessment Method | EU Machinery Regulation (EU) 2023/1230 | Annex III General Principles Workflow](/artifacts/eu/machinery-regulation/risk-assessment-method.md): A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles. - [Scope and Machine Categories | EU Machinery Regulation (EU) 2023/1230 | Machinery, Related Products, Partly Completed Machinery, Annex I](/artifacts/eu/machinery-regulation/scope-and-machine-categories.md): A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment. - [Software and Cybersecurity Considerations | EU Machinery Regulation (EU) 2023/1230 | Control Systems, Protection Against Corruption, Logs](/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations.md): A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption. - [Technical Documentation and Technical File | EU Machinery Regulation (EU) 2023/1230 | Annex IV Part A/B Checklist + Structure](/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file.md): A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping. - [Templates | EU Machinery Regulation (EU) 2023/1230 | Route Memo, Annex IV Technical File Index, DoC/DoI, Risk Assessment Mapping](/artifacts/eu/machinery-regulation/machinery-ce-documentation-template.md): Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note. - [Timeline and Transition | EU Machinery Regulation (EU) 2023/1230 | From Machinery Directive 2006/42/EC to 14 Jan 2027](/artifacts/eu/machinery-regulation/timeline-and-transition.md): A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act --- --- title: "Machinery Regulation vs Machinery Directive" canonical_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive" source_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive" author: "Sorena AI" description: "A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Machinery Regulation vs Machinery Directive" - "Regulation (EU) 2023/1230 vs Directive 2006/42/EC" - "machinery regulation changes" - "Annex I Article 25 changes" - "software safety components machinery regulation" - "transition plan to 14 January 2027" - "comparison" - "transition" - "Directive 2006/42/EC" - "Regulation 2023/1230" - "Article 25" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Machinery Regulation vs Machinery Directive A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates. *Comparison* *EU* ## Machinery Regulation vs Machinery Directive What changes operationally A migration map from 2006/42/EC to 2023/1230. Focus: route changes, documentation modernization, and software/control-system evidence. Directive 2006/42/EC harmonized machinery safety through national transposition. Regulation (EU) 2023/1230 replaces it with directly applicable rules and adapts the framework to new risks, including software and connected machinery. The practical impact is not just legal references - it's route selection (Annex I + Article 25), evidence expectations (Annex IV), and safety-related software integrity and logging controls. ## 1) Directive vs Regulation (why it matters to operators) A directive required national transposition. A regulation is directly applicable across Member States. That reduces legal divergence but raises the bar for one consistent EU-wide evidence model. The migration should therefore be designed around one controlled technical-file and declaration architecture, not country-by-country rewrites. - Use one core technical file structure across markets; add language overlays where required. - Treat the CE marking evidence chain as the product lifecycle system, not an end-of-project document set. *Recommended next step* *Placement: after the comparison section* ## Use Machinery Regulation vs Machinery Directive What changes operationally as a cited research workflow Research Copilot can take Machinery Regulation vs Machinery Directive What changes operationally from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on Machinery Regulation vs Machinery Directive can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Machinery Regulation vs Machinery Directive What changes operationally](/solutions/research-copilot.md): Start from Machinery Regulation vs Machinery Directive What changes operationally and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Machinery Regulation vs Machinery Directive](/contact.md): Review your current process, evidence gaps, and next steps for Machinery Regulation vs Machinery Directive What changes operationally. ## 2) Scope and definitions updates (software is explicitly in frame) The Regulation adapts definitions to reflect digital machinery and software-driven safety functions. Operational implication: software can be a safety component; machinery can be in scope even when missing only the upload of software intended for the specific application. - Software can be a safety component when it is independently placed on the market and performs a safety function. - Machinery can remain in scope even when only the upload of software intended for the specific application is still missing. - Substantial modification is now defined explicitly and covers physical or digital changes that create a new hazard or increase an existing risk and require new significant protective measures. ## 3) Annex I + Article 25 route changes (what to re-check across your portfolio) The Regulation's Annex I categories and Article 25 procedures create clear route logic: Part A requires third-party routes; Part B has conditional Module A; not listed defaults to Module A. Operational implication: re-run Annex I classification for each product family - don't assume the directive-era route still holds. - Part A includes certain ML/self-evolving safety components and embedded systems ensuring safety functions. - Part B includes many high-risk machinery categories and safety devices; Module A is conditional on standards/common specifications coverage. - Plan notified body capacity early for families that now require third-party procedures. ## 4) Technical documentation modernization (Annex IV: evidence systems, not PDFs) Annex IV makes the technical documentation minimum elements explicit and includes software/control-system evidence items in certain contexts. Operational implication: build a stable index and evidence mapping (EHSR -> protective measures -> tests). - Risk-assessment documentation must show the applicable EHSR, the protective measures, and residual risks. - Safety-related software source code or programming logic may have to be provided on reasoned request where necessary to demonstrate compliance. - Digital instructions and declarations are more explicitly governed, including print, download, paper-on-request, and 10-year online access rules for partly completed machinery outputs. ## 5) Migration plan (how to move product families safely) A successful migration is product-family based: scope, route, safety case, evidence, and declarations move together. Operational output: a transition tracker with "done looks like" criteria. - Inventory families and freeze the directive-era placed-on-market evidence for legacy products. - Reclassify each family for Annex I and Article 25, including software-heavy and connected products. - Modernize the technical file, digital-document controls, and software logging before the 14 January 2027 application date. - Where necessary, book notified body capacity early and validate the new release gate with dry runs in 2026. ## Primary sources - [Regulation (EU) 2023/1230 corrigendum - machinery regulation (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/corrigendum/2023-07-04/oj/eng?ref=sorena.io) - Primary source for the new definitions, route logic, digital-document rules, software obligations, and corrected transition dates. - [Directive 2006/42/EC - Machinery Directive (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2006/42/oj?ref=sorena.io) - Primary source for the legacy directive framework that the Regulation replaces from 14 January 2027. ## Related Topic Guides - [Applicability Test | EU Machinery Regulation (EU) 2023/1230 | In Scope? Annex I? Article 25 Route?](/artifacts/eu/machinery-regulation/applicability-test.md): A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery. - [Checklist | EU Machinery Regulation (EU) 2023/1230 | CE Marking Readiness Checklist (Route + Technical File + Declarations)](/artifacts/eu/machinery-regulation/checklist.md): An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2). - [Compliance Program | EU Machinery Regulation (EU) 2023/1230 | Operating Model, Controls, Transition to 2027](/artifacts/eu/machinery-regulation/compliance.md): Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control. - [Conformity Assessment and CE Marking | EU Machinery Regulation (EU) 2023/1230 | Article 25 Modules, Annex I, DoC/DoI](/artifacts/eu/machinery-regulation/conformity-assessment-and-ce.md): A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H. - [Deadlines and Compliance Calendar | EU Machinery Regulation (EU) 2023/1230 | Transition to 14 Jan 2027 + Route and Evidence Milestones](/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar.md): A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. - [FAQ | EU Machinery Regulation (EU) 2023/1230 | Scope, Annex I, Article 25, Technical File, Software](/artifacts/eu/machinery-regulation/faq.md): High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route. - [Machinery Regulation vs EU AI Act | Smart machinery, safety components, high-risk AI](/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act.md): A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6). - [Penalties and Fines | EU Machinery Regulation (EU) 2023/1230 | Article 50, Enforcement, Corrective Actions](/artifacts/eu/machinery-regulation/penalties-and-fines.md): A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline. - [Requirements | EU Machinery Regulation (EU) 2023/1230 | EHSR (Annex III), Technical File (Annex IV), Article 25 Route](/artifacts/eu/machinery-regulation/requirements.md): An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence. - [Risk Assessment Method | EU Machinery Regulation (EU) 2023/1230 | Annex III General Principles Workflow](/artifacts/eu/machinery-regulation/risk-assessment-method.md): A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles. - [Scope and Machine Categories | EU Machinery Regulation (EU) 2023/1230 | Machinery, Related Products, Partly Completed Machinery, Annex I](/artifacts/eu/machinery-regulation/scope-and-machine-categories.md): A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment. - [Software and Cybersecurity Considerations | EU Machinery Regulation (EU) 2023/1230 | Control Systems, Protection Against Corruption, Logs](/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations.md): A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption. - [Technical Documentation and Technical File | EU Machinery Regulation (EU) 2023/1230 | Annex IV Part A/B Checklist + Structure](/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file.md): A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping. - [Templates | EU Machinery Regulation (EU) 2023/1230 | Route Memo, Annex IV Technical File Index, DoC/DoI, Risk Assessment Mapping](/artifacts/eu/machinery-regulation/machinery-ce-documentation-template.md): Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note. - [Timeline and Transition | EU Machinery Regulation (EU) 2023/1230 | From Machinery Directive 2006/42/EC to 14 Jan 2027](/artifacts/eu/machinery-regulation/timeline-and-transition.md): A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive --- --- title: "Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/penalties-and-fines" author: "Sorena AI" description: "A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Machinery Regulation penalties" - "machinery regulation fines" - "Article 50 penalties" - "machinery CE marking enforcement" - "market surveillance machinery regulation" - "corrective actions withdrawal recall machinery" - "penalties" - "enforcement" - "Article 50" - "market surveillance" - "recall" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Penalties and Fines A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline. *Enforcement* *EU* ## EU Machinery Regulation (EU) 2023/1230 Penalties and Fines Penalties are national - but enforcement questions are predictable. Focus: market surveillance requests, route correctness, and evidence pack readiness. Article 50 requires Member States to lay down penalties for infringements and ensures penalties are effective, proportionate and dissuasive (including potential criminal penalties for serious infringements). Exact fine amounts vary nationally, but the enforcement pattern is stable: authorities request documentation, inspect labeling and instructions, assess safety evidence, and require corrective actions (withdrawal/recall) where non-compliance or risk is found. ## 1) Article 50: what is fixed vs what varies by Member State Article 50 requires Member States to set penalties and notify those rules to the Commission by 14 October 2026. The penalty amounts are national, but the compliance artifacts that get enforced are set by the Regulation. Build one EU-wide evidence pack and only add local overlays where genuinely necessary. - Universal: route memo (Annex I + Article 25), risk assessment and EHSR mapping, technical file index, declarations, instructions, traceability labels. - Country overlays: language requirements for instructions, local enforcement contact points, national penalty references where needed. - Deadline: Member States notify the Commission of penalty rules by 14 October 2026 (Article 50). ## 2) Enforcement escalation pattern (what happens in practice) In practice, machinery enforcement often starts with an incident, complaint, customs or online-sales screening, or a targeted market-surveillance action. From there, authorities request the visible pack first and the deeper evidence second. Your goal is to make the first response coherent enough that the second request is manageable. - Surface checks: CE marking, notified body number where required, traceability, and instructions availability. - Documentation request: DoC or DoI, Annex IV index, key reports, route memo, and software-evidence bundle where relevant. - Technical assessment: review against Annex III, Annex I classification, Article 25 route choice, and any safeguard concerns. - Corrective measures: remediation, withdrawal or recall, and updated documentation and communications. *Recommended next step* *Placement: after the enforcement section* ## Use EU Machinery Regulation (EU) 2023/1230 Penalties and Fines as a cited research workflow Research Copilot can take EU Machinery Regulation (EU) 2023/1230 Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Machinery Regulation (EU) 2023/1230 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Machinery Regulation (EU) 2023/1230 Penalties and Fines](/solutions/research-copilot.md): Start from EU Machinery Regulation (EU) 2023/1230 Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Machinery Regulation (EU) 2023/1230](/contact.md): Review your current process, evidence gaps, and next steps for EU Machinery Regulation (EU) 2023/1230 Penalties and Fines. ## 3) What triggers serious outcomes (high-signal failure modes) Authorities escalate quickly when the failure is structural: wrong route, missing notified body involvement, or missing/contradictory technical documentation. Treat these as release blockers. - Annex I misclassification (Part A/Part B) leading to wrong Article 25 route. - Incomplete technical file: missing risk assessment mapping, missing test evidence, missing instructions pack. - CE marking issues: missing CE mark, wrong placement, missing notified body ID where required. - Software/control-system failures: lack of integrity controls or missing evidence of interventions where relevant to safety. ## 4) Risk reduction playbook (controls that prevent enforcement escalation) Most enforcement risk is preventable with a small set of high-signal controls and evidence discipline. Treat this list as your enforcement readiness baseline. - Exportable response pack per product family (DoC/DoI + technical file index + key evidence). - Route governance: Annex I + Article 25 route memo with change triggers; notified body plan where applicable. - Release gate: declarations, labels, and instruction availability checked before placing on the market. - Corrective action readiness: complaints register, CAPA workflow, withdrawal/recall procedures, and update communications. ## Primary sources - [Regulation (EU) 2023/1230 corrigendum - Article 50 and safeguard framework (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/corrigendum/2023-07-04/oj/eng?ref=sorena.io) - Primary source for Member State penalty duties and the regulation-specific obligations that enforcement tests. - [Regulation (EU) 2019/1020 - market surveillance (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Primary source for the horizontal market-surveillance and corrective-action framework. ## Related Topic Guides - [Applicability Test | EU Machinery Regulation (EU) 2023/1230 | In Scope? Annex I? Article 25 Route?](/artifacts/eu/machinery-regulation/applicability-test.md): A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery. - [Checklist | EU Machinery Regulation (EU) 2023/1230 | CE Marking Readiness Checklist (Route + Technical File + Declarations)](/artifacts/eu/machinery-regulation/checklist.md): An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2). - [Compliance Program | EU Machinery Regulation (EU) 2023/1230 | Operating Model, Controls, Transition to 2027](/artifacts/eu/machinery-regulation/compliance.md): Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control. - [Conformity Assessment and CE Marking | EU Machinery Regulation (EU) 2023/1230 | Article 25 Modules, Annex I, DoC/DoI](/artifacts/eu/machinery-regulation/conformity-assessment-and-ce.md): A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H. - [Deadlines and Compliance Calendar | EU Machinery Regulation (EU) 2023/1230 | Transition to 14 Jan 2027 + Route and Evidence Milestones](/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar.md): A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. - [FAQ | EU Machinery Regulation (EU) 2023/1230 | Scope, Annex I, Article 25, Technical File, Software](/artifacts/eu/machinery-regulation/faq.md): High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route. - [Machinery Regulation vs EU AI Act | Smart machinery, safety components, high-risk AI](/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act.md): A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6). - [Machinery Regulation vs Machinery Directive | Regulation (EU) 2023/1230 vs Directive 2006/42/EC | Key Changes + Migration Plan](/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive.md): A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates. - [Requirements | EU Machinery Regulation (EU) 2023/1230 | EHSR (Annex III), Technical File (Annex IV), Article 25 Route](/artifacts/eu/machinery-regulation/requirements.md): An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence. - [Risk Assessment Method | EU Machinery Regulation (EU) 2023/1230 | Annex III General Principles Workflow](/artifacts/eu/machinery-regulation/risk-assessment-method.md): A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles. - [Scope and Machine Categories | EU Machinery Regulation (EU) 2023/1230 | Machinery, Related Products, Partly Completed Machinery, Annex I](/artifacts/eu/machinery-regulation/scope-and-machine-categories.md): A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment. - [Software and Cybersecurity Considerations | EU Machinery Regulation (EU) 2023/1230 | Control Systems, Protection Against Corruption, Logs](/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations.md): A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption. - [Technical Documentation and Technical File | EU Machinery Regulation (EU) 2023/1230 | Annex IV Part A/B Checklist + Structure](/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file.md): A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping. - [Templates | EU Machinery Regulation (EU) 2023/1230 | Route Memo, Annex IV Technical File Index, DoC/DoI, Risk Assessment Mapping](/artifacts/eu/machinery-regulation/machinery-ce-documentation-template.md): Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note. - [Timeline and Transition | EU Machinery Regulation (EU) 2023/1230 | From Machinery Directive 2006/42/EC to 14 Jan 2027](/artifacts/eu/machinery-regulation/timeline-and-transition.md): A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/machinery-regulation/penalties-and-fines --- --- title: "Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/requirements" source_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/requirements" author: "Sorena AI" description: "An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Machinery Regulation requirements" - "Regulation (EU) 2023/1230 obligations" - "Annex III essential health and safety requirements" - "Annex IV technical documentation" - "Article 25 conformity assessment requirements" - "machinery declaration of conformity requirements" - "declaration of incorporation requirements partly completed machinery" - "requirements" - "Annex III" - "Annex IV" - "Article 25" - "economic operators" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Requirements An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence. *Requirements* *EU* ## EU Machinery Regulation (EU) 2023/1230 Requirements A supply-chain duties map plus the evidence artifacts each role must produce. Focus: route selection (Annex I + Article 25) + EHSR evidence (Annex III) + technical file (Annex IV). Machinery compliance is operational: you classify product type and Annex I category, choose the Article 25 route, run an Annex III risk assessment and protective measures design, compile Annex IV technical documentation, and issue the correct declaration(s). This page turns the Regulation into a requirements-to-evidence control set you can apply across many product families and suppliers. ## 1) Build the program around four control pillars A machinery program is easier to operate when every obligation falls into one of four buckets: classification, safety, evidence, and market readiness. Those pillars also make ownership and audit trails clearer. - Classification: scope, exclusions, product type, Annex I category, and Article 25 route memo. - Safety: Annex III risk assessment, safety integration hierarchy, protective measures, and residual-risk communication. - Evidence: Annex IV index, verification records, software and control-system evidence, and change history. - Market readiness: declarations, CE marking, traceability, instructions or assembly instructions, and corrective-action readiness. ## 2) Manufacturer obligations create the primary evidence chain Manufacturers remain responsible for conformity even where a notified body is involved. The job is to build the route logic and the evidence chain before placing on the market. That evidence chain should be exportable by product family. - Carry out the Annex III risk assessment and determine which essential health and safety requirements apply. - Classify Annex I Part A, Part B, or not listed, and apply the correct Article 25 procedure. - Compile Annex IV technical documentation and keep it updated. - Issue the EU declaration of conformity for machinery or related products, or the declaration of incorporation for partly completed machinery. - Affix CE marking where required and add the notified body number when the procedure requires it. - Provide instructions or assembly instructions in the required languages and in compliant digital or paper formats. ## 3) Digital-document duties are specific and testable The Regulation does not simply say digital delivery is allowed. It sets concrete conditions that teams can and should test. Treat those conditions as product requirements, not as a publishing afterthought. - Digital instructions must clearly match the product model and allow printing, downloading, and saving for use at all times, including during breakdowns. - Users may request paper instructions free of charge within one month. - For machinery intended for non-professional users, or reasonably foreseeable for them, essential safety information must be supplied in paper form. - Declarations may be delivered by internet address or machine-readable code when the Regulation allows it, but the link must remain reliable and version-controlled. ## 4) Importers and distributors are verification gates, not passive resellers Importers and distributors must verify the visible compliance pack and cooperate with authorities. They also need access to information in paper or digital form on reasoned request. A receiving checklist is usually the cleanest way to operationalize these duties. - Importers should verify that conformity assessment was completed, technical documentation exists, CE marking is present where required, and the manufacturer met traceability duties. - Distributors should verify CE marking, traceability, and the presence of required documents and instructions before making the product available. - Both roles need a process for authority requests, corrective action cooperation, and traceability-data retention. ## 5) Substantial modification and software change control can reset the role map A substantial modification is a physical or digital change after placing on the market or putting into service that was not foreseen or planned by the manufacturer, creates a new hazard or increases an existing risk, and requires new significant protective measures. When that happens, the modifier can become the manufacturer for the affected machinery or related product. - Cover software updates and configuration changes in the substantial-modification review process. - Keep a change log with the route memo, risk-assessment impact, and declaration impact. - Remember that a non-professional user modifying machinery for their own use is not treated as a manufacturer under this rule. ## 6) Software evidence needs exact controls and exact retention The Regulation is explicit about software identification, intervention evidence, and log retention. Those details should sit in the requirements matrix, not in an engineer's memory. Use the requirements matrix to connect each software obligation to an owner and a file path. - Identify installed software necessary for safe operation in an easily accessible form. - Collect evidence of legitimate or illegitimate intervention in relevant hardware, software, and configuration elements. - Retain the tracing log of intervention data and uploaded safety-software versions for five years after upload. - Retain safety-related decision-making data for software-based safety systems for one year after collection. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU Machinery Regulation (EU) 2023/1230 Requirements into an operational assessment Assessment Autopilot can take EU Machinery Regulation (EU) 2023/1230 Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Machinery Regulation (EU) 2023/1230 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Machinery Regulation (EU) 2023/1230 Requirements](/solutions/assessment.md): Start from EU Machinery Regulation (EU) 2023/1230 Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Machinery Regulation (EU) 2023/1230](/contact.md): Review your current process, evidence gaps, and next steps for EU Machinery Regulation (EU) 2023/1230 Requirements. ## Primary sources - [Regulation (EU) 2023/1230 corrigendum - Articles 2 to 3, 10 to 18, Annex I, Annex III, Annex IV, and Article 54 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/corrigendum/2023-07-04/oj/eng?ref=sorena.io) - Primary source for scope, operator obligations, Annex I routing, risk assessment, digital-document duties, software controls, and timing. - [Regulation (EU) 2019/1020 - market surveillance (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Horizontal framework relevant to operator cooperation and corrective-action expectations. - [European Commission machinery page](https://single-market-economy.ec.europa.eu/sectors/mechanical-engineering/machinery_en?ref=sorena.io) - Official Commission overview page for implementation materials and market-access context. ## Related Topic Guides - [Applicability Test | EU Machinery Regulation (EU) 2023/1230 | In Scope? Annex I? Article 25 Route?](/artifacts/eu/machinery-regulation/applicability-test.md): A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery. - [Checklist | EU Machinery Regulation (EU) 2023/1230 | CE Marking Readiness Checklist (Route + Technical File + Declarations)](/artifacts/eu/machinery-regulation/checklist.md): An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2). - [Compliance Program | EU Machinery Regulation (EU) 2023/1230 | Operating Model, Controls, Transition to 2027](/artifacts/eu/machinery-regulation/compliance.md): Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control. - [Conformity Assessment and CE Marking | EU Machinery Regulation (EU) 2023/1230 | Article 25 Modules, Annex I, DoC/DoI](/artifacts/eu/machinery-regulation/conformity-assessment-and-ce.md): A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H. - [Deadlines and Compliance Calendar | EU Machinery Regulation (EU) 2023/1230 | Transition to 14 Jan 2027 + Route and Evidence Milestones](/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar.md): A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. - [FAQ | EU Machinery Regulation (EU) 2023/1230 | Scope, Annex I, Article 25, Technical File, Software](/artifacts/eu/machinery-regulation/faq.md): High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route. - [Machinery Regulation vs EU AI Act | Smart machinery, safety components, high-risk AI](/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act.md): A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6). - [Machinery Regulation vs Machinery Directive | Regulation (EU) 2023/1230 vs Directive 2006/42/EC | Key Changes + Migration Plan](/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive.md): A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates. - [Penalties and Fines | EU Machinery Regulation (EU) 2023/1230 | Article 50, Enforcement, Corrective Actions](/artifacts/eu/machinery-regulation/penalties-and-fines.md): A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline. - [Risk Assessment Method | EU Machinery Regulation (EU) 2023/1230 | Annex III General Principles Workflow](/artifacts/eu/machinery-regulation/risk-assessment-method.md): A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles. - [Scope and Machine Categories | EU Machinery Regulation (EU) 2023/1230 | Machinery, Related Products, Partly Completed Machinery, Annex I](/artifacts/eu/machinery-regulation/scope-and-machine-categories.md): A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment. - [Software and Cybersecurity Considerations | EU Machinery Regulation (EU) 2023/1230 | Control Systems, Protection Against Corruption, Logs](/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations.md): A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption. - [Technical Documentation and Technical File | EU Machinery Regulation (EU) 2023/1230 | Annex IV Part A/B Checklist + Structure](/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file.md): A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping. - [Templates | EU Machinery Regulation (EU) 2023/1230 | Route Memo, Annex IV Technical File Index, DoC/DoI, Risk Assessment Mapping](/artifacts/eu/machinery-regulation/machinery-ce-documentation-template.md): Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note. - [Timeline and Transition | EU Machinery Regulation (EU) 2023/1230 | From Machinery Directive 2006/42/EC to 14 Jan 2027](/artifacts/eu/machinery-regulation/timeline-and-transition.md): A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/machinery-regulation/requirements --- --- title: "Risk Assessment Method" canonical_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/risk-assessment-method" source_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/risk-assessment-method" author: "Sorena AI" description: "A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Machinery Regulation risk assessment" - "Annex III general principles risk assessment" - "safety integration hierarchy" - "reasonably foreseeable misuse machinery" - "hazard log machinery regulation" - "risk reduction iterative process machinery" - "risk assessment" - "Annex III" - "safety integration" - "hazards" - "residual risk" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Risk Assessment Method A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles. *Risk Assessment* *EU* ## EU Machinery Regulation (EU) 2023/1230 Risk Assessment Method An Annex III-aligned workflow you can execute per product family. Output: hazard log + protective measures map + residual risk and instructions evidence. Annex III makes risk assessment the engine of compliance: you perform it to determine which essential health and safety requirements apply, then design and construct to eliminate or minimize risks using a defined priority order. The goal isn't a generic risk document - it's a reproducible chain: limits -> hazards -> risks -> controls -> verification evidence -> residual risk communication. ## 1) Define the limits (what the machine is, what it does, and where it lives) Start by defining boundaries. Most downstream disagreements come from undefined limits: intended use, environment, operators, and foreseeable misuse. Operational output: a 'limits' section that becomes the header for your hazard log. - Intended use and operating modes; reasonably foreseeable misuse patterns. - Lifecycle phases: transport, assembly, installation, commissioning, operation, maintenance, cleaning, disabling, scrapping. - People and access: operators, bystanders, exposed persons; danger zones. - Energy sources: electrical, hydraulic, pneumatic, mechanical, stored energy; control system architecture (software, sensors, remote control). ## 2) Identify hazards and hazardous situations (make it exhaustive, then prune) Hazards are potential sources of injury or damage to health; hazardous situations are how people end up exposed. Don't rely on a standard's checklist alone - map hazards to your specific configuration and work tasks. - Mechanical hazards: crushing, shearing, entanglement, impact, ejection, stability. - Electrical hazards (including control system failures) and energy isolation hazards. - Ergonomic, thermal, noise/vibration, radiation, hazardous substances, environmental hazards where applicable. - Software/autonomy hazards: unsafe states due to updates, data dependency, or interaction between machines. ## 3) Estimate and evaluate risks (severity x probability) and decide what must be reduced Estimate risk by combining severity and probability. Then evaluate whether risk reduction is required in line with the Regulation's objective. Operational output: a consistent scoring rubric and a 'risk acceptability' policy. - Use consistent scales (e.g., severity 1-5, probability 1-5) across product lines. - Document assumptions that affect probability (training, supervision, environment constraints). - Flag high-severity scenarios for design review, independent review, and test evidence focus. *Recommended next step* *Placement: after the main workflow section* ## Turn EU Machinery Regulation (EU) 2023/1230 Risk Assessment Method into an operational assessment Assessment Autopilot can take EU Machinery Regulation (EU) 2023/1230 Risk Assessment Method from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on EU Machinery Regulation (EU) 2023/1230 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Machinery Regulation (EU) 2023/1230 Risk Assessment Method](/solutions/assessment.md): Start from EU Machinery Regulation (EU) 2023/1230 Risk Assessment Method and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Machinery Regulation (EU) 2023/1230](/contact.md): Review your current process, evidence gaps, and next steps for EU Machinery Regulation (EU) 2023/1230 Risk Assessment Method. ## 4) Apply safety integration hierarchy (the order matters) Annex III sets a priority order for protective measures. Use this hierarchy as your control selection policy. Evidence should show the rationale for why a hazard wasn't eliminated and what was chosen instead. - 1) Inherently safe design: eliminate hazards or minimize risk by design and construction. - 2) Protective measures: guards, protective devices, control system safety functions. - 3) Information: residual risk warnings, training requirements, PPE needs, safe-use limitations. ## 5) Verify controls and document residual risks Controls are only as strong as their verification evidence. Tie each protective measure to tests/inspections/examinations and store evidence IDs in the hazard log. Residual risks must be communicated through marking and instructions where applicable. - Control -> verification method -> acceptance criteria -> evidence ID (test report, inspection record, calculation). - Residual risk register linked to instructions sections and warning labels. - Production controls for series production (how you ensure the built machine matches the assessed design). ## 6) Special cases: autonomy, self-evolving behavior, and system-of-systems interaction Annex III explicitly requires risk assessment to include hazards that might arise during the lifecycle due to intended evolution of behavior (including varying autonomy), and risks from interactions between machines arranged and controlled to function as an integral whole. Operational output: an 'evolution hazards' annex and a 'system interaction' hazard set. - Software update hazards: planned updates and configuration changes that affect safety behavior. - Data dependency/opacity/autonomy/connectivity: identify failure modes that increase probability/severity. - Interaction hazards: coupled machines where combined behavior introduces new hazards (coordination, deadlocks, emergent hazards). ## Primary sources - [Regulation (EU) 2023/1230 - Annex III general principles and safety integration hierarchy (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/oj?ref=sorena.io) - Annex III requires risk assessment and describes the iterative risk assessment and risk reduction process and the safety integration priority order. ## Related Topic Guides - [Applicability Test | EU Machinery Regulation (EU) 2023/1230 | In Scope? Annex I? Article 25 Route?](/artifacts/eu/machinery-regulation/applicability-test.md): A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery. - [Checklist | EU Machinery Regulation (EU) 2023/1230 | CE Marking Readiness Checklist (Route + Technical File + Declarations)](/artifacts/eu/machinery-regulation/checklist.md): An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2). - [Compliance Program | EU Machinery Regulation (EU) 2023/1230 | Operating Model, Controls, Transition to 2027](/artifacts/eu/machinery-regulation/compliance.md): Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control. - [Conformity Assessment and CE Marking | EU Machinery Regulation (EU) 2023/1230 | Article 25 Modules, Annex I, DoC/DoI](/artifacts/eu/machinery-regulation/conformity-assessment-and-ce.md): A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H. - [Deadlines and Compliance Calendar | EU Machinery Regulation (EU) 2023/1230 | Transition to 14 Jan 2027 + Route and Evidence Milestones](/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar.md): A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. - [FAQ | EU Machinery Regulation (EU) 2023/1230 | Scope, Annex I, Article 25, Technical File, Software](/artifacts/eu/machinery-regulation/faq.md): High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route. - [Machinery Regulation vs EU AI Act | Smart machinery, safety components, high-risk AI](/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act.md): A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6). - [Machinery Regulation vs Machinery Directive | Regulation (EU) 2023/1230 vs Directive 2006/42/EC | Key Changes + Migration Plan](/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive.md): A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates. - [Penalties and Fines | EU Machinery Regulation (EU) 2023/1230 | Article 50, Enforcement, Corrective Actions](/artifacts/eu/machinery-regulation/penalties-and-fines.md): A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline. - [Requirements | EU Machinery Regulation (EU) 2023/1230 | EHSR (Annex III), Technical File (Annex IV), Article 25 Route](/artifacts/eu/machinery-regulation/requirements.md): An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence. - [Scope and Machine Categories | EU Machinery Regulation (EU) 2023/1230 | Machinery, Related Products, Partly Completed Machinery, Annex I](/artifacts/eu/machinery-regulation/scope-and-machine-categories.md): A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment. - [Software and Cybersecurity Considerations | EU Machinery Regulation (EU) 2023/1230 | Control Systems, Protection Against Corruption, Logs](/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations.md): A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption. - [Technical Documentation and Technical File | EU Machinery Regulation (EU) 2023/1230 | Annex IV Part A/B Checklist + Structure](/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file.md): A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping. - [Templates | EU Machinery Regulation (EU) 2023/1230 | Route Memo, Annex IV Technical File Index, DoC/DoI, Risk Assessment Mapping](/artifacts/eu/machinery-regulation/machinery-ce-documentation-template.md): Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note. - [Timeline and Transition | EU Machinery Regulation (EU) 2023/1230 | From Machinery Directive 2006/42/EC to 14 Jan 2027](/artifacts/eu/machinery-regulation/timeline-and-transition.md): A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/machinery-regulation/risk-assessment-method --- --- title: "Scope and Machine Categories" canonical_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/scope-and-machine-categories" source_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/scope-and-machine-categories" author: "Sorena AI" description: "A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Machinery Regulation scope" - "Regulation (EU) 2023/1230 scope" - "machinery definition Article 3" - "related products machinery regulation" - "partly completed machinery definition" - "Annex I categories machinery regulation" - "exclusions Article 2 machinery regulation" - "scope" - "machinery" - "related products" - "partly completed machinery" - "Annex I" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Scope and Machine Categories A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment. *Scope* *EU* ## EU Machinery Regulation (EU) 2023/1230 Scope and Machine Categories Classify product type, exclusions, and Annex I categories fast. Focus: defensible scope memos and correct Article 25 route selection. Scope work is a compliance multiplier: it determines whether you need an EU Declaration of Conformity or a Declaration of Incorporation, what technical documentation applies (Annex IV Part A vs Part B), and whether Article 25 triggers notified body involvement. This page turns the Regulation's scope logic into an execution guide you can reuse across product families. ## 1) What the Regulation covers (product types in scope) The Regulation applies to machinery and specific 'related products' (and also to partly completed machinery). Operational output: every product family should be labeled as one of these types in the technical file index. - Machinery (including assemblies and assemblies missing only the upload of software intended for the specific application foreseen by the manufacturer). - Related products: interchangeable equipment, safety components (including software), lifting accessories, chains/ropes/webbing, removable mechanical transmission devices. - Partly completed machinery: assemblies intended to be incorporated into or assembled with machinery. *Recommended next step* *Placement: after the scope or definition section* ## Use EU Machinery Regulation (EU) 2023/1230 Scope and Machine Categories as a cited research workflow Research Copilot can take EU Machinery Regulation (EU) 2023/1230 Scope and Machine Categories from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Machinery Regulation (EU) 2023/1230 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Machinery Regulation (EU) 2023/1230 Scope and Machine Categories](/solutions/research-copilot.md): Start from EU Machinery Regulation (EU) 2023/1230 Scope and Machine Categories and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Machinery Regulation (EU) 2023/1230](/contact.md): Review your current process, evidence gaps, and next steps for EU Machinery Regulation (EU) 2023/1230 Scope and Machine Categories. ## 2) The biggest scope traps (and how to avoid them) Scope disputes usually happen for three reasons: the product is actually excluded, the product is an electrical product covered by LVD/RED, or the product is a safety component/software sold independently. Control: require a scope memo and an 'exclusions checked' section before any conformity testing begins. - Electrical product exclusions: certain household appliances, A/V, IT, office machinery, low-voltage switchgear/control gear, and electric motors when within LVD/RED scope. - Research-only temporary laboratory machinery: excluded. - Transport regimes: aircraft/water/rail and vehicle regimes (except machinery mounted on them). - Spare parts: safety components supplied as spare parts to replace identical components can be excluded in specific conditions. ## 3) Machinery vs partly completed machinery (evidence and declaration implications) This classification changes your required declarations, documentation, and customer-facing obligations. Treat it as a primary decision in your product compliance architecture. - Machinery/related products: CE marking, EU Declaration of Conformity, technical documentation (Annex IV Part A). - Partly completed machinery: EU Declaration of Incorporation, assembly instructions, technical documentation (Annex IV Part B). - Digital publication obligations can apply (e.g., online access to instructions/declarations for defined periods). ## 4) Annex I categories: why they matter Annex I lists categories that trigger specific conformity assessment routes. Part A categories require third-party procedures (Article 25(2)). Part B categories can use routes in Article 25(3) - including Module A only under defined conditions. Operational output: a classification note that cites the exact Annex I category item(s) that match. - Part A includes, among others, removable mechanical transmission devices and certain self-evolving ML safety components/systems ensuring safety functions. - Part B includes many high-risk categories (woodworking saws, presses, lifting of persons, protective devices, logic units for safety functions, etc.). - Not in Annex I: default route is internal production control (Module A) under Article 25(4). ## 5) Output artifacts to standardize across teams A repeatable scope bundle prevents rework during audits and notified body interactions. Build once per product family and update on changes. - Scope memo: product type + exclusions checked + applicable legislation list. - Annex I classification note + Article 25 route decision memo. - Initial risk assessment outline (Annex III general principles) and planned evidence pack index (Annex IV). ## Primary sources - [Regulation (EU) 2023/1230 - Machinery Regulation (Article 2 scope; Article 3 definitions; Annex I; Article 25) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/oj?ref=sorena.io) - Primary source for product types, exclusions, definitions, Annex I categories and conformity assessment route triggers. - [European Commission - Machinery (Single Market) page](https://single-market-economy.ec.europa.eu/sectors/mechanical-engineering/machinery_en?ref=sorena.io) - Commission overview and navigation to notified bodies, market surveillance, and sector guidance resources. - [Regulation (EU) 2019/1020 - Market surveillance and compliance of products (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Horizontal market surveillance framework relevant to documentation availability and economic operator tasks. ## Related Topic Guides - [Applicability Test | EU Machinery Regulation (EU) 2023/1230 | In Scope? Annex I? Article 25 Route?](/artifacts/eu/machinery-regulation/applicability-test.md): A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery. - [Checklist | EU Machinery Regulation (EU) 2023/1230 | CE Marking Readiness Checklist (Route + Technical File + Declarations)](/artifacts/eu/machinery-regulation/checklist.md): An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2). - [Compliance Program | EU Machinery Regulation (EU) 2023/1230 | Operating Model, Controls, Transition to 2027](/artifacts/eu/machinery-regulation/compliance.md): Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control. - [Conformity Assessment and CE Marking | EU Machinery Regulation (EU) 2023/1230 | Article 25 Modules, Annex I, DoC/DoI](/artifacts/eu/machinery-regulation/conformity-assessment-and-ce.md): A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H. - [Deadlines and Compliance Calendar | EU Machinery Regulation (EU) 2023/1230 | Transition to 14 Jan 2027 + Route and Evidence Milestones](/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar.md): A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. - [FAQ | EU Machinery Regulation (EU) 2023/1230 | Scope, Annex I, Article 25, Technical File, Software](/artifacts/eu/machinery-regulation/faq.md): High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route. - [Machinery Regulation vs EU AI Act | Smart machinery, safety components, high-risk AI](/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act.md): A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6). - [Machinery Regulation vs Machinery Directive | Regulation (EU) 2023/1230 vs Directive 2006/42/EC | Key Changes + Migration Plan](/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive.md): A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates. - [Penalties and Fines | EU Machinery Regulation (EU) 2023/1230 | Article 50, Enforcement, Corrective Actions](/artifacts/eu/machinery-regulation/penalties-and-fines.md): A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline. - [Requirements | EU Machinery Regulation (EU) 2023/1230 | EHSR (Annex III), Technical File (Annex IV), Article 25 Route](/artifacts/eu/machinery-regulation/requirements.md): An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence. - [Risk Assessment Method | EU Machinery Regulation (EU) 2023/1230 | Annex III General Principles Workflow](/artifacts/eu/machinery-regulation/risk-assessment-method.md): A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles. - [Software and Cybersecurity Considerations | EU Machinery Regulation (EU) 2023/1230 | Control Systems, Protection Against Corruption, Logs](/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations.md): A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption. - [Technical Documentation and Technical File | EU Machinery Regulation (EU) 2023/1230 | Annex IV Part A/B Checklist + Structure](/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file.md): A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping. - [Templates | EU Machinery Regulation (EU) 2023/1230 | Route Memo, Annex IV Technical File Index, DoC/DoI, Risk Assessment Mapping](/artifacts/eu/machinery-regulation/machinery-ce-documentation-template.md): Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note. - [Timeline and Transition | EU Machinery Regulation (EU) 2023/1230 | From Machinery Directive 2006/42/EC to 14 Jan 2027](/artifacts/eu/machinery-regulation/timeline-and-transition.md): A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/machinery-regulation/scope-and-machine-categories --- --- title: "Software and Cybersecurity Considerations" canonical_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations" source_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations" author: "Sorena AI" description: "A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Machinery Regulation cybersecurity" - "Annex III protection against corruption" - "safety reliability of control systems machinery regulation" - "safety related software logging requirements" - "evidence of software intervention machinery" - "Regulation (EU) 2023/1230 software requirements" - "software" - "control systems" - "cybersecurity" - "protection against corruption" - "logging" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Software and Cybersecurity Considerations A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption. *Software & Security* *EU* ## EU Machinery Regulation (EU) 2023/1230 Software and Cybersecurity Considerations Cybersecurity is treated as a safety control with exact logging and evidence duties. Focus: control system integrity, intervention logs, software identification, and technical file artifacts. The Regulation explicitly addresses safety risks stemming from malicious third-party actions that can impact the safety of machinery. It does not replace cybersecurity-specific EU acts, but it does impose safety-oriented control-system integrity requirements. Practically: you need engineering controls (integrity, access, logging), documentation artifacts, and a clear strategy for how software updates and autonomy affect safety over the lifecycle. ## 1) Treat software integrity as part of the safety case The Regulation is not a general cybersecurity law. Its software obligations are safety-scoped: prevent corruption or manipulation that would break compliance with essential health and safety requirements. The right output is a safety-software inventory tied to hazards, controls, and evidence. - List the software and configuration elements that are necessary for safe operation. - Map malicious or accidental corruption scenarios to concrete hazards and protective measures. - Link identity, access, update, rollback, and logging controls to the Annex III safety case. ## 2) Annex III protection against corruption is broader than a security checklist Annex III requires protection of hardware components that transmit signals or data relevant to software critical for compliance, and protection of the software and data themselves. The Regulation also requires the machinery or related product to identify installed software necessary for safe operation in an easily accessible form. - Protect safety-critical interfaces and data paths against accidental or intentional corruption. - Collect evidence of legitimate or illegitimate intervention in relevant hardware components when they matter for connection or access to compliance-critical software. - Collect evidence of legitimate or illegitimate intervention in the software, or modifications to the software or its configuration. - Make the installed safety-relevant software and version information easily retrievable by service and compliance teams. ## 3) Use the exact retention periods from Annex III Logging only helps if teams know exactly what must be kept and for how long. Annex III gives precise retention periods for two important software-evidence categories. These logs exist to demonstrate conformity further to a reasoned request from a competent authority, so design them for integrity and export. - Enable a tracing log of intervention data and versions of safety software uploaded after placing on the market or putting into service, and retain that tracing log for five years after the upload. - Enable recording of data on the safety-related decision-making process for software-based safety systems ensuring a safety function, including safety components, and retain that data for one year after collection. - Protect the logs against tampering, define who can export them, and connect each export to the product and software version. ## 4) Updates, autonomy, and self-evolving behaviour need route-aware change control Risk assessment must cover hazards that arise from intended evolution of behaviour and varying levels of autonomy, including foreseen updates. The change process should tell you when an update is still within the original safety case and when it risks substantial modification or route reassessment. - Define which updates are foreseen at placement and what verification is required before release. - Create escalation triggers for route review, new testing, or declaration updates when safety functions or assumptions change. - Keep configuration history in the technical file and in the operational log trail. ## 5) Use certification schemes carefully Relevant EU cybersecurity certification schemes may support presumption of conformity for the Annex III requirements they actually cover. They do not replace the machinery safety case. Treat scheme outputs as supporting evidence with defined boundaries. - Document exactly which Annex III requirements the certificate supports. - Keep the certificate, scope statement, and validity period in the technical file. - Do not let a certificate substitute for hazard analysis, protective measures, or intervention logging evidence. ## 6) Build an authority-ready software evidence bundle Annex IV allows competent authorities to request safety-related source code or programming logic where necessary to verify compliance. Some products also need sensor-system descriptions, limitations, and validation evidence. Prepare a bounded export that proves compliance without making every request an emergency. - Bundle architecture, safety-function mapping, software identification, version history, logging policy, and validation summaries. - Where safety operations are controlled by sensor data, keep system characteristics, limitations, capabilities, and development and validation records. - Document how you review and approve software evidence exports on a reasoned-request basis. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU Machinery Regulation (EU) 2023/1230 Software and Cybersecurity Considerations as a cited research workflow Research Copilot can take EU Machinery Regulation (EU) 2023/1230 Software and Cybersecurity Considerations from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU Machinery Regulation (EU) 2023/1230 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Machinery Regulation (EU) 2023/1230 Software and Cybersecurity Considerations](/solutions/research-copilot.md): Start from EU Machinery Regulation (EU) 2023/1230 Software and Cybersecurity Considerations and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Machinery Regulation (EU) 2023/1230](/contact.md): Review your current process, evidence gaps, and next steps for EU Machinery Regulation (EU) 2023/1230 Software and Cybersecurity Considerations. ## Primary sources - [Regulation (EU) 2023/1230 corrigendum - Annex III and Annex IV (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/corrigendum/2023-07-04/oj/eng?ref=sorena.io) - Primary source for protection against corruption, software identification, intervention evidence, exact retention periods, and authority-request software documentation. - [Regulation (EU) 2019/881 - EU Cybersecurity Act (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/881/oj/eng?ref=sorena.io) - Primary source for EU cybersecurity certification schemes that may support presumption of conformity where relevant. ## Related Topic Guides - [Applicability Test | EU Machinery Regulation (EU) 2023/1230 | In Scope? Annex I? Article 25 Route?](/artifacts/eu/machinery-regulation/applicability-test.md): A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery. - [Checklist | EU Machinery Regulation (EU) 2023/1230 | CE Marking Readiness Checklist (Route + Technical File + Declarations)](/artifacts/eu/machinery-regulation/checklist.md): An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2). - [Compliance Program | EU Machinery Regulation (EU) 2023/1230 | Operating Model, Controls, Transition to 2027](/artifacts/eu/machinery-regulation/compliance.md): Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control. - [Conformity Assessment and CE Marking | EU Machinery Regulation (EU) 2023/1230 | Article 25 Modules, Annex I, DoC/DoI](/artifacts/eu/machinery-regulation/conformity-assessment-and-ce.md): A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H. - [Deadlines and Compliance Calendar | EU Machinery Regulation (EU) 2023/1230 | Transition to 14 Jan 2027 + Route and Evidence Milestones](/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar.md): A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. - [FAQ | EU Machinery Regulation (EU) 2023/1230 | Scope, Annex I, Article 25, Technical File, Software](/artifacts/eu/machinery-regulation/faq.md): High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route. - [Machinery Regulation vs EU AI Act | Smart machinery, safety components, high-risk AI](/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act.md): A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6). - [Machinery Regulation vs Machinery Directive | Regulation (EU) 2023/1230 vs Directive 2006/42/EC | Key Changes + Migration Plan](/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive.md): A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates. - [Penalties and Fines | EU Machinery Regulation (EU) 2023/1230 | Article 50, Enforcement, Corrective Actions](/artifacts/eu/machinery-regulation/penalties-and-fines.md): A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline. - [Requirements | EU Machinery Regulation (EU) 2023/1230 | EHSR (Annex III), Technical File (Annex IV), Article 25 Route](/artifacts/eu/machinery-regulation/requirements.md): An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence. - [Risk Assessment Method | EU Machinery Regulation (EU) 2023/1230 | Annex III General Principles Workflow](/artifacts/eu/machinery-regulation/risk-assessment-method.md): A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles. - [Scope and Machine Categories | EU Machinery Regulation (EU) 2023/1230 | Machinery, Related Products, Partly Completed Machinery, Annex I](/artifacts/eu/machinery-regulation/scope-and-machine-categories.md): A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment. - [Technical Documentation and Technical File | EU Machinery Regulation (EU) 2023/1230 | Annex IV Part A/B Checklist + Structure](/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file.md): A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping. - [Templates | EU Machinery Regulation (EU) 2023/1230 | Route Memo, Annex IV Technical File Index, DoC/DoI, Risk Assessment Mapping](/artifacts/eu/machinery-regulation/machinery-ce-documentation-template.md): Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note. - [Timeline and Transition | EU Machinery Regulation (EU) 2023/1230 | From Machinery Directive 2006/42/EC to 14 Jan 2027](/artifacts/eu/machinery-regulation/timeline-and-transition.md): A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations --- --- title: "Technical Documentation and Technical File" canonical_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file" source_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file" author: "Sorena AI" description: "A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Machinery Regulation technical documentation" - "Annex IV technical file" - "machinery technical file checklist" - "risk assessment documentation Annex III" - "EU declaration of conformity machinery technical file" - "declaration of incorporation partly completed machinery technical file" - "safety related software source code authority request" - "technical documentation" - "technical file" - "Annex IV" - "risk assessment" - "control systems" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Technical Documentation and Technical File A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping. *Technical File* *EU* ## EU Machinery Regulation (EU) 2023/1230 Technical Documentation and Technical File Annex IV turned into a practical evidence index. Focus: risk assessment mapping, route-ready evidence, and exportable documentation packs. Annex IV makes the technical file explicit: it must specify the means used to ensure conformity with essential health and safety requirements (Annex III) and include a minimum set of evidence. The fastest way to build a strong file is to treat it as an evidence system: a stable index that links each requirement and hazard to protective measures and verification reports. ## 1) Pick the right Annex IV track first The technical documentation structure depends on whether you ship machinery or related products, or partly completed machinery. State that track at the top of the file index. This sounds basic, but it prevents declaration and instruction mistakes later. - Annex IV Part A applies to machinery and related products that will carry the CE mark and a DoC. - Annex IV Part B applies to partly completed machinery that ships with assembly instructions and a declaration of incorporation. - Use one shared evidence architecture with a clear branch for Part A vs Part B outputs. ## 2) Part A minimum elements should read like an audit index Annex IV Part A is the minimum content list, not an optional example. Treat each item as a section in the controlled index. The highest-value item is still the risk-assessment package because it links the rest of the evidence together. - Complete description, intended use, drawings, schematics, and explanations of operation. - Risk-assessment documentation showing the applicable Annex III requirements, the protective measures used for each, and residual risks. - References to harmonised standards and common specifications with full or partial application clearly identified. - Test, inspection, and examination results plus production controls that keep series production conforming. - Instructions, information set, declarations for incorporated products under other EU acts where applicable, and the declarations or assembly instructions of incorporated partly completed machinery where relevant. ## 3) Part B files need assembly logic, not a reduced Part A clone Partly completed machinery files should show which essential health and safety requirements were applied, what risks remain for the integrator, and how assembly must be done safely. Do not treat the declaration of incorporation as a lighter DoC. It serves a different legal function. - Describe intended function after incorporation or assembly. - Keep the relevant Annex III requirement set, risk-assessment outputs, drawings, standards references, and verification results. - Include assembly instructions and the declaration of incorporation as controlled outputs tied to the same version history. ## 4) Add the software and sensor-system items explicitly required by the Regulation Teams often miss the software-specific elements because they are not traditional mechanical-file artifacts. Build them into the index from day one. Competent authorities may ask for source code or programming logic where necessary to verify compliance, so you need a retrieval process before anyone asks. - Keep safety-related software architecture, logic descriptions, versioning, and the basis for safe operation identification. - Where relevant, keep descriptions of system characteristics, capabilities, limitations, and development, testing, and validation processes for sensor-fed, remotely driven, or autonomous safety functions. - Link these items to the Annex III corruption-protection and logging controls rather than storing them as disconnected attachments. ## 5) Digital instructions and declarations are part of the technical-file design If you use digital delivery, the access conditions become part of the compliance architecture. That means retention, accessibility, and version traceability belong in the file design. This is especially important when declarations are delivered via an internet address or machine-readable code. - Digital instructions for machinery or related products must be printable, downloadable, and savable, and users may request paper copies free of charge within one month. - For non-professional-use machinery, essential safety information must still be provided in paper form. - Digital assembly instructions and the declaration of incorporation for partly completed machinery must remain accessible online for 10 years. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Machinery Regulation (EU) 2023/1230 Technical Documentation and Technical File in one governed evidence system SSOT can take EU Machinery Regulation (EU) 2023/1230 Technical Documentation and Technical File from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Machinery Regulation (EU) 2023/1230 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Machinery Regulation (EU) 2023/1230 Technical Documentation and Technical File](/solutions/ssot.md): Start from EU Machinery Regulation (EU) 2023/1230 Technical Documentation and Technical File and keep documents, evidence, and control records in one governed system. - [Talk through EU Machinery Regulation (EU) 2023/1230](/contact.md): Review your current process, evidence gaps, and next steps for EU Machinery Regulation (EU) 2023/1230 Technical Documentation and Technical File. ## 6) Retrieval discipline is part of compliance A technical file that exists but cannot be exported quickly is not operational. Design ownership, storage, and service levels up front. The safest pattern is one stable folder structure and one response-pack export per family. - Assign a file owner and backup owner per product family. - Maintain a response pack with the current DoC or DoI, index, core reports, and instructions. - Track design changes, software updates, standards updates, route changes, and declaration revisions in a visible change log. ## Primary sources - [Regulation (EU) 2023/1230 corrigendum - Annex IV and digital-document provisions (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/corrigendum/2023-07-04/oj/eng?ref=sorena.io) - Primary source for Part A and Part B technical documentation, source-code or programming-logic requests, and digital instruction or declaration conditions. - [Regulation (EU) 2023/1230 corrigendum - Annex III general principles (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/corrigendum/2023-07-04/oj/eng?ref=sorena.io) - Primary source for the risk-assessment and safety-integration principles that structure the technical file. - [Regulation (EU) 2019/1020 - market surveillance (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Horizontal market-surveillance framework relevant to technical-file retrieval and authority response. ## Related Topic Guides - [Applicability Test | EU Machinery Regulation (EU) 2023/1230 | In Scope? Annex I? Article 25 Route?](/artifacts/eu/machinery-regulation/applicability-test.md): A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery. - [Checklist | EU Machinery Regulation (EU) 2023/1230 | CE Marking Readiness Checklist (Route + Technical File + Declarations)](/artifacts/eu/machinery-regulation/checklist.md): An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2). - [Compliance Program | EU Machinery Regulation (EU) 2023/1230 | Operating Model, Controls, Transition to 2027](/artifacts/eu/machinery-regulation/compliance.md): Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control. - [Conformity Assessment and CE Marking | EU Machinery Regulation (EU) 2023/1230 | Article 25 Modules, Annex I, DoC/DoI](/artifacts/eu/machinery-regulation/conformity-assessment-and-ce.md): A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H. - [Deadlines and Compliance Calendar | EU Machinery Regulation (EU) 2023/1230 | Transition to 14 Jan 2027 + Route and Evidence Milestones](/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar.md): A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. - [FAQ | EU Machinery Regulation (EU) 2023/1230 | Scope, Annex I, Article 25, Technical File, Software](/artifacts/eu/machinery-regulation/faq.md): High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route. - [Machinery Regulation vs EU AI Act | Smart machinery, safety components, high-risk AI](/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act.md): A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6). - [Machinery Regulation vs Machinery Directive | Regulation (EU) 2023/1230 vs Directive 2006/42/EC | Key Changes + Migration Plan](/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive.md): A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates. - [Penalties and Fines | EU Machinery Regulation (EU) 2023/1230 | Article 50, Enforcement, Corrective Actions](/artifacts/eu/machinery-regulation/penalties-and-fines.md): A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline. - [Requirements | EU Machinery Regulation (EU) 2023/1230 | EHSR (Annex III), Technical File (Annex IV), Article 25 Route](/artifacts/eu/machinery-regulation/requirements.md): An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence. - [Risk Assessment Method | EU Machinery Regulation (EU) 2023/1230 | Annex III General Principles Workflow](/artifacts/eu/machinery-regulation/risk-assessment-method.md): A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles. - [Scope and Machine Categories | EU Machinery Regulation (EU) 2023/1230 | Machinery, Related Products, Partly Completed Machinery, Annex I](/artifacts/eu/machinery-regulation/scope-and-machine-categories.md): A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment. - [Software and Cybersecurity Considerations | EU Machinery Regulation (EU) 2023/1230 | Control Systems, Protection Against Corruption, Logs](/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations.md): A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption. - [Templates | EU Machinery Regulation (EU) 2023/1230 | Route Memo, Annex IV Technical File Index, DoC/DoI, Risk Assessment Mapping](/artifacts/eu/machinery-regulation/machinery-ce-documentation-template.md): Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note. - [Timeline and Transition | EU Machinery Regulation (EU) 2023/1230 | From Machinery Directive 2006/42/EC to 14 Jan 2027](/artifacts/eu/machinery-regulation/timeline-and-transition.md): A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file --- --- title: "Timeline and Transition" canonical_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/timeline-and-transition" source_url: "https://www.sorena.io/artifacts/eu/machinery-regulation/timeline-and-transition" author: "Sorena AI" description: "A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Machinery Regulation transition" - "Regulation (EU) 2023/1230 timeline" - "Machinery Directive repeal 14 January 2027" - "transition plan machinery regulation" - "Annex I Article 25 migration" - "notified body capacity planning 2026" - "transition" - "timeline" - "Directive 2006/42/EC" - "Regulation 2023/1230" - "2027" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Timeline and Transition A grounded migration guide for Regulation (EU) 2023/1230 covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. *Transition* *EU* ## EU Machinery Regulation (EU) 2023/1230 Timeline and Transition A migration playbook to 14 January 2027. Focus: portfolio classification, route planning, evidence modernization, and notified body readiness. Transition is not just a legal-reference update. Regulation (EU) 2023/1230 changes route selection, software evidence, digital-document controls, and the meaning of substantial modification. The corrigendum also matters because it fixes the operative dates. This page gives you a product-family migration plan that matches the law and the real execution work. ## 1) Timeline snapshot with the corrected dates Use these dates as the top row of the portfolio migration tracker. - 14 June 2023 adopted, 29 June 2023 published, and 19 July 2023 entered into force. - 14 January 2024: Articles 26 to 42 started to apply. - 20 July 2024: Article 6(2) to (6), (8) and (11), Article 47, and Article 53(3) started to apply. - 14 July 2025: Member State Article 6 data reporting deadline. - 20 July 2026: Commission Article 6 report deadline. - 14 January 2027: main application date and repeal of Directive 2006/42/EC. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU Machinery Regulation (EU) 2023/1230 Timeline and Transition into an operational assessment Assessment Autopilot can take EU Machinery Regulation (EU) 2023/1230 Timeline and Transition from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Machinery Regulation (EU) 2023/1230 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Machinery Regulation (EU) 2023/1230 Timeline and Transition](/solutions/assessment.md): Start from EU Machinery Regulation (EU) 2023/1230 Timeline and Transition and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Machinery Regulation (EU) 2023/1230](/contact.md): Review your current process, evidence gaps, and next steps for EU Machinery Regulation (EU) 2023/1230 Timeline and Transition. ## 2) Transition principle: migrate by product family, not by document A family-based migration keeps route choice, risk assessment, software evidence, declarations, and instructions aligned. A document-only migration leaves contradictions in the shipped pack. The output should be one decision record per family, not a loose collection of updated PDFs. - Inventory product variants, safety functions, embedded or downloadable software, connected services, and intended users. - Freeze a directive-era baseline pack before you start rewriting it for the Regulation. - Define migration acceptance criteria: route approved, technical file indexed, declarations updated, and digital access controls tested. ## 3) Route discovery comes first Do not wait for late-stage CE release to classify Annex I. Part A and Part B logic changes timelines, notified body use, and evidence depth. The route decision memo should be versioned because it controls the rest of the program. - Check whether the family is machinery, a related product, or partly completed machinery. - Classify Annex I Part A, Annex I Part B, or not listed, and record the rationale and standards coverage assumptions. - For Part B families, document why Module A is or is not available based on full standards or common-specification coverage of the relevant EHSR. ## 4) Modernize the evidence system, not just the technical file headings Annex IV requires a retrievable evidence system. That includes software logic on reasoned request where needed, plus sensor-system descriptions and validation records in the relevant cases. If the evidence cannot be exported quickly, the technical file is not operational. - Map each applicable Annex III requirement to the hazard log, protective measure, test evidence, and owner. - Separate engineering evidence, software-integrity evidence, and declaration artifacts, but keep them tied by a common index. - Add document-access and version-retrieval tests to the migration exit criteria. ## 5) Digital instructions, declarations, and legacy support Digital delivery is allowed in defined situations, but the access conditions are strict enough that teams should treat them as product requirements. The transition plan should also include legacy products placed on the market before 14 January 2027. - Instructions in digital format must be printable, downloadable, and savable for use during breakdowns. - Users can ask for paper instructions free of charge within one month, and non-professional-use machinery must still include essential safety information in paper form. - For partly completed machinery, assembly instructions and the declaration of incorporation can be digital, but online access must remain available for 10 years. ## 6) What done looks like Mark a family migrated only when the workflow is stable, not merely when the wording is refreshed. - Scope memo, Annex I memo, and Article 25 route memo approved. - Annex III risk assessment updated for software, autonomy, and foreseeable misuse. - Annex IV evidence index complete and retrievable. - DoC or DoI, instructions, and digital access controls matched to the final configuration. - Substantial-modification triggers and software change controls are operating in production. ## Primary sources - [Regulation (EU) 2023/1230 corrigendum - Article 51 and Article 54 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/1230/corrigendum/2023-07-04/oj/eng?ref=sorena.io) - Primary source for the corrected transition dates, repeal of Directive 2006/42/EC, and earlier-applying provisions. - [Directive 2006/42/EC - Machinery Directive (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2006/42/oj?ref=sorena.io) - Legacy framework relevant to products placed on the market before 14 January 2027. - [European Commission machinery page](https://single-market-economy.ec.europa.eu/sectors/mechanical-engineering/machinery_en?ref=sorena.io) - Official Commission overview of the machinery framework, notified bodies, and implementation materials. ## Related Topic Guides - [Applicability Test | EU Machinery Regulation (EU) 2023/1230 | In Scope? Annex I? Article 25 Route?](/artifacts/eu/machinery-regulation/applicability-test.md): A step-by-step applicability test for EU Machinery Regulation (EU) 2023/1230: is it machinery / related product / partly completed machinery. - [Checklist | EU Machinery Regulation (EU) 2023/1230 | CE Marking Readiness Checklist (Route + Technical File + Declarations)](/artifacts/eu/machinery-regulation/checklist.md): An audit-ready CE marking checklist for EU Machinery Regulation (EU) 2023/1230: scope memo and exclusions (Article 2). - [Compliance Program | EU Machinery Regulation (EU) 2023/1230 | Operating Model, Controls, Transition to 2027](/artifacts/eu/machinery-regulation/compliance.md): Build a scalable compliance program for EU Machinery Regulation (EU) 2023/1230: product family strategy, scope and exclusions control. - [Conformity Assessment and CE Marking | EU Machinery Regulation (EU) 2023/1230 | Article 25 Modules, Annex I, DoC/DoI](/artifacts/eu/machinery-regulation/conformity-assessment-and-ce.md): A grounded guide to Article 25 conformity assessment under Regulation (EU) 2023/1230: Annex I Part A and Part B route selection, Module A versus B plus C, H. - [Deadlines and Compliance Calendar | EU Machinery Regulation (EU) 2023/1230 | Transition to 14 Jan 2027 + Route and Evidence Milestones](/artifacts/eu/machinery-regulation/deadlines-and-compliance-calendar.md): A grounded EU Machinery Regulation compliance calendar covering adoption on 14 June 2023, publication on 29 June 2023, entry into force on 19 July 2023. - [FAQ | EU Machinery Regulation (EU) 2023/1230 | Scope, Annex I, Article 25, Technical File, Software](/artifacts/eu/machinery-regulation/faq.md): High-signal FAQ for EU Machinery Regulation (EU) 2023/1230: what is in scope and excluded, how Annex I Part A/Part B changes the conformity assessment route. - [Machinery Regulation vs EU AI Act | Smart machinery, safety components, high-risk AI](/artifacts/eu/machinery-regulation/machinery-regulation-vs-eu-ai-act.md): A practical crosswalk for smart machinery: when the EU AI Act treats your AI as a high-risk safety component (Article 6). - [Machinery Regulation vs Machinery Directive | Regulation (EU) 2023/1230 vs Directive 2006/42/EC | Key Changes + Migration Plan](/artifacts/eu/machinery-regulation/machinery-regulation-vs-machinery-directive.md): A grounded comparison of Regulation (EU) 2023/1230 and Directive 2006/42/EC covering direct applicability, corrected transition dates. - [Penalties and Fines | EU Machinery Regulation (EU) 2023/1230 | Article 50, Enforcement, Corrective Actions](/artifacts/eu/machinery-regulation/penalties-and-fines.md): A practical enforcement guide for Regulation (EU) 2023/1230: Article 50 national penalties, the 14 October 2026 penalty-notification deadline. - [Requirements | EU Machinery Regulation (EU) 2023/1230 | EHSR (Annex III), Technical File (Annex IV), Article 25 Route](/artifacts/eu/machinery-regulation/requirements.md): An implementation-grade breakdown of Regulation (EU) 2023/1230 covering scope and definitions, Annex I routing, Annex III risk assessment, Annex IV evidence. - [Risk Assessment Method | EU Machinery Regulation (EU) 2023/1230 | Annex III General Principles Workflow](/artifacts/eu/machinery-regulation/risk-assessment-method.md): A practical risk assessment method aligned to EU Machinery Regulation (EU) 2023/1230 Annex III general principles. - [Scope and Machine Categories | EU Machinery Regulation (EU) 2023/1230 | Machinery, Related Products, Partly Completed Machinery, Annex I](/artifacts/eu/machinery-regulation/scope-and-machine-categories.md): A practical scope guide for EU Machinery Regulation (EU) 2023/1230: what counts as machinery, related products (interchangeable equipment. - [Software and Cybersecurity Considerations | EU Machinery Regulation (EU) 2023/1230 | Control Systems, Protection Against Corruption, Logs](/artifacts/eu/machinery-regulation/software-and-cybersecurity-considerations.md): A practical guide to software and cybersecurity-related safety duties under Regulation (EU) 2023/1230: Annex III protection against corruption. - [Technical Documentation and Technical File | EU Machinery Regulation (EU) 2023/1230 | Annex IV Part A/B Checklist + Structure](/artifacts/eu/machinery-regulation/technical-documentation-and-technical-file.md): A practical Annex IV guide for Regulation (EU) 2023/1230: Part A vs Part B file structure, risk-assessment content, standards mapping. - [Templates | EU Machinery Regulation (EU) 2023/1230 | Route Memo, Annex IV Technical File Index, DoC/DoI, Risk Assessment Mapping](/artifacts/eu/machinery-regulation/machinery-ce-documentation-template.md): Copy/paste templates for EU Machinery Regulation (EU) 2023/1230 compliance: scope memo (Article 2 exclusions), Annex I classification note. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/machinery-regulation/timeline-and-transition --- --- title: "EU Market Surveillance Regulation applicability test" canonical_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/applicability-test" author: "Sorena AI" description: "A practical applicability test for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Market Surveillance Regulation applicability test" - "Regulation (EU) 2019/1020 applicability" - "Article 6 distance sales EU" - "is my online offer targeted at EU end users" - "Article 4 economic operator EU" - "fulfilment service provider Article 4" - "Regulation (EU) 2019/1020" - "Article 6 distance sales" - "Article 4 economic operator" - "online sales" - "market surveillance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Market Surveillance Regulation applicability test A practical applicability test for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). *Applicability* *EU* ## EU Market Surveillance Regulation (EU) 2019/1020 Applicability test Decide if MSR enforcement workflows apply to your products and channels. Focus: online targeting (Article 6), economic operator setup (Article 4), and inspection-ready evidence. Regulation (EU) 2019/1020 (Market Surveillance Regulation, "MSR") is an enforcement framework: it shapes how market surveillance authorities check products, request evidence, and coordinate corrective action across Member States. Your practical applicability questions are: (1) are you making products available on the EU market, including through distance sales targeted at EU end users (Article 6)? (2) do you need an EU-based economic operator responsible for compliance tasks for certain product laws (Article 4)? and (3) can you produce declarations, technical documentation, and response actions fast when authorities ask? ## 1) Are you 'making products available' in the EU? For online sales and other distance sales, MSR treats the product as made available on the EU market if the offer is targeted at end users in the Union (Article 6). This is the central trigger for ecommerce sellers, marketplaces, and cross-border brands. Practical targeting indicators include: EU language and currencies, shipping to EU addresses, EU-localised marketing, EU domain/ads, and EU customer support channels. - Yes -> treat MSR as an operational enforcement requirement and build evidence-response readiness. - No -> MSR may still matter indirectly if you distribute via EU resellers/importers who do target the EU. - Unclear -> document your assessment and align your website, shipping, and marketing signals to your intended markets. ## 2) Does Article 4 require an EU economic operator for your product type? For products subject to certain EU harmonisation legislation, Article 4 says the product may be placed on the market only if there is an economic operator established in the Union responsible for specific compliance tasks (Article 4(1)). The operator can be: an EU manufacturer, an importer, an authorised representative (with a written mandate), or (if none of those exist in the EU) an EU fulfilment service provider for the products it handles (Article 4(2)). - If you are a non-EU brand shipping direct-to-consumer: Article 4 is often the first compliance gap. - If you rely on a fulfilment provider: verify they are established in the EU and contract for Article 4 task coverage. - Labeling/packaging check: the economic operator's name and EU contact address must be indicated on product/packaging/parcel/accompanying document (Article 4(4)). ## 3) Are you 'inspection-ready' on documentation and corrective action? Even if you are not explicitly "in scope" as an authority, MSR drives what authorities request and how fast you need to respond. Article 4 tasks include verifying declarations/technical documentation are drawn up and ensuring technical documentation can be made available on request (Article 4(3)(a)), providing information in a language easily understood by the authority (Article 4(3)(b)), and cooperating on corrective action (Article 4(3)(d)). Use this as a readiness bar: can you retrieve, package, and explain evidence within days - and can you execute corrective actions (withdrawal/recall, listing removals, shipment holds) when needed? - Create an evidence index per product family: DoC/DoP, technical file, test reports, traceability, change history. - Create an authority-response playbook: intake, triage, owner assignment, response templates, escalation, CAPA. - Create a serious-risk path: immediate risk assessment, withdrawal/recall decisioning, and reporting workflow. *Recommended next step* *Placement: after the applicability result* ## Turn EU Market Surveillance Regulation (EU) 2019/1020 Applicability test into an operational assessment Assessment Autopilot can take EU Market Surveillance Regulation (EU) 2019/1020 Applicability test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU Market Surveillance Regulation (EU) 2019/1020 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Market Surveillance Regulation (EU) 2019/1020 Applicability test](/solutions/assessment.md): Start from EU Market Surveillance Regulation (EU) 2019/1020 Applicability test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Market Surveillance Regulation (EU) 2019/1020](/contact.md): Review your current process, evidence gaps, and next steps for EU Market Surveillance Regulation (EU) 2019/1020 Applicability test. ## Primary sources - [Regulation (EU) 2019/1020 - Market Surveillance Regulation (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Primary source for Article 4 economic operator tasks, Article 6 distance sales targeting, authority activities (Article 11), information systems (Article 34), penalties (Article 41), and entry into application (Article 44). - [Commission guidelines on Article 4 (Docsroom, C(2021) 1461)](https://ec.europa.eu/docsroom/documents/44908?ref=sorena.io) - Practical guidance for economic operators and market surveillance authorities on implementing Article 4 (EU-based economic operator and tasks). - [Commission overview: Market surveillance for products](https://single-market-economy.ec.europa.eu/single-market/goods/building-blocks/market-surveillance_en?ref=sorena.io) - Commission overview page and ecosystem links for market surveillance (tools, networks, and related resources). ## Related Topic Guides - [Authority request response playbook | EU Market Surveillance Regulation (EU) 2019/1020 | Evidence requests, corrective action](/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook.md): An operational playbook for responding to authority requests under Regulation (EU) 2019/1020: first-24-hour triage, Article 4 evidence packs. - [Enforcement powers and penalties | EU MSR (Regulation (EU) 2019/1020) | Checks, serious risk, penalties](/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties.md): A practical enforcement guide for Regulation (EU) 2019/1020 covering Article 11 risk-based checks, Article 14 authority powers. - [EU Market Surveillance Regulation requirements | Regulation (EU) 2019/1020 (MSR) obligations](/artifacts/eu/market-surveillance-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2019/1020 covering Article 4 EU economic-operator tasks, Article 6 distance-sales targeting. - [EU MSR Article 4 economic operator duties and responsible-person setup | Regulation (EU) 2019/1020](/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties.md): A practical guide to Article 4 of Regulation (EU) 2019/1020: when an EU economic operator is required, who can act, what Article 4(3) tasks they perform. - [EU MSR checklist | Regulation (EU) 2019/1020 compliance checklist for inspections](/artifacts/eu/market-surveillance-regulation/checklist.md): An audit-ready checklist for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting and distance sales (Article 6). - [EU MSR compliance program | Regulation (EU) 2019/1020 implementation guide](/artifacts/eu/market-surveillance-regulation/compliance.md): A practical implementation guide for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU MSR deadlines and compliance calendar | Regulation (EU) 2019/1020 key dates (Article 44, Article 41)](/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar.md): Key dates for Regulation (EU) 2019/1020 covering early application from 1 January 2021 for Articles 29 to 33 and 36, general application from 16 July 2021. - [EU MSR FAQ | Regulation (EU) 2019/1020 questions (Article 4, Article 6, investigations)](/artifacts/eu/market-surveillance-regulation/faq.md): Answers to common questions about the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting (Article 6). - [EU MSR penalties and fines | Article 41 penalties (Regulation (EU) 2019/1020) | Reduce exposure](/artifacts/eu/market-surveillance-regulation/penalties-and-fines.md): Penalty exposure under Regulation (EU) 2019/1020: what Article 41 requires, why penalties differ by Member State. - [Investigations and evidence requests | EU Market Surveillance Regulation (EU) 2019/1020 | What authorities check](/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests.md): A practical guide to MSR investigations under Regulation (EU) 2019/1020 covering Article 11 risk-based checks. - [Market surveillance for online marketplaces | EU MSR (Regulation (EU) 2019/1020) | Operator controls](/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces.md): A practical guide for online marketplaces under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 7(2) cooperation. - [MSR vs GPSR | Market Surveillance Regulation (EU) 2019/1020 vs General Product Safety Regulation (EU) 2023/988](/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr.md): A grounded comparison of Regulation (EU) 2019/1020 and Regulation (EU) 2023/988: MSR as the enforcement and coordination framework. - [Online sales under the EU Market Surveillance Regulation | Article 6 distance sales + ecommerce controls](/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces.md): A practical guide for ecommerce sellers under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 4 operator identification. - [What changes with EU market surveillance | Regulation (EU) 2019/1020 (MSR) practical impact](/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes.md): A practical 'what changed' guide for Regulation (EU) 2019/1020: stronger EU-wide coordination, explicit online/distance sales targeting logic (Article 6). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/market-surveillance-regulation/applicability-test --- --- title: "Authority request response playbook" canonical_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook" source_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook" author: "Sorena AI" description: "An operational playbook for responding to authority requests under Regulation (EU) 2019/1020: first-24-hour triage, Article 4 evidence packs." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "market surveillance authority request response" - "EU MSR evidence request playbook" - "Regulation (EU) 2019/1020 evidence request" - "Article 4 technical documentation on request" - "Article 18 procedural rights economic operator" - "serious risk withdrawal recall" - "Regulation (EU) 2019/1020" - "Article 4" - "Article 11" - "Article 18" - "evidence request" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Authority request response playbook An operational playbook for responding to authority requests under Regulation (EU) 2019/1020: first-24-hour triage, Article 4 evidence packs. *Playbook* *EU* ## EU Market Surveillance Regulation (EU) 2019/1020 Authority response playbook How to respond fast without losing evidence quality. Designed for inspections and investigations: intake, evidence packs, corrective action, and post-closure CAPA. Under the MSR, "compliance" is tested when an authority asks questions: can you identify the economic operator, provide the declaration/technical documentation quickly, explain decisions in an auditable way, and execute corrective actions (including withdrawal/recall) when needed? This playbook converts MSR requirements into a repeatable, owner-driven response workflow that works across Member States and channels. ## 1) Intake and triage (first 24 hours) Start by classifying the request: documentary check, test/sample request, marketplace listing investigation, serious-risk escalation, or corrective-action follow-up. Confirm which product family/SKU and which Member State authority is involved. Decide who is the responsible economic operator contact (especially for Article 4 products) and assign a single case owner (legal/compliance) with a named technical evidence owner (product/quality). - Confirm whether the case is a documentary check, customs hold, marketplace investigation, safety incident, or serious-risk escalation. - Freeze product identifiers, listing URLs, batch or serial ranges, shipping records, and the current declaration version. - Assign one legal or compliance owner and one technical evidence owner, with a written response timetable. ## 2) Build the evidence pack (Article 4-style 'technical file on request') Article 4 focuses the pack on the declaration and technical documentation, but authorities also have broader investigative powers under Article 14. Build the pack so it can expand from a document response into a full investigation file without losing traceability. The most reliable pattern is one authority pack per product family with controlled variants and addenda. - Core artifacts: DoC/DoP, technical documentation index, standards list, test reports, traceability, change log, and risk/complaint history. - Language handling: include an executive summary in the authority's language where feasible; translate only what is required. - Provenance controls: tie each artifact to product version, date, owner, and storage location; prevent "orphan PDFs". ## 3) Procedural rights and safe communications Measures must state the exact grounds and be communicated without delay. Operators must be informed about remedies and time limits, and in normal cases should have at least 10 working days to be heard before a measure is taken. At the same time, authorities can move urgently and they can use broad investigative powers, so your communication model must combine speed with controlled evidence handling. - Use a single written record: timeline of events, requests, deliveries, and decisions with versioned attachments. - Separate facts from interpretations: keep technical analyses clearly attributed and dated. - Redaction policy: define what counts as trade secret, how to share securely, and how to justify redactions. ## 4) Corrective action: from listing controls to withdrawal/recall Authorities aim to ensure corrective action is taken by economic operators and can take measures when operators fail to act (Article 11(1)). For serious risk, authorities ensure withdrawal/recall or prohibition of making available on the market where needed (Article 19). Operationally, corrective action ranges from 'fix the documentation' to 'stop shipping now'. Your playbook must support both. - Immediate controls: pause shipments, block listings, quarantine stock, preserve evidence, and notify the Article 4 operator contact. - Article 14 online-interface path: prepare for removal requests, warning language, or access restrictions where no other effective means exist to eliminate a serious risk. - Customs path: if the case is tied to Article 26 suspension or Article 28 refusal of release, keep customs-facing documents and product identifiers aligned with the authority file. ## 5) Closeout and prevention (CAPA) Evidence from one Member State can be used in another without further formal requirements (Article 11(6)). That means the same underlying weakness will be found repeatedly unless you fix root causes. Close every case with prevention: update controls, train owners, and improve evidence retrieval so the next request is easier. - Root cause analysis: why did the issue exist (documentation, labeling, supplier evidence, listing governance)? - Control upgrades: add release gates, audits, and monitoring for the channel that triggered the case. - Metrics: time-to-acknowledge, time-to-evidence, time-to-control, and recurrence rate per product family. *Recommended next step* *Placement: after the workflow or playbook section* ## Turn EU Market Surveillance Regulation (EU) 2019/1020 Authority response playbook into an operational assessment Assessment Autopilot can take EU Market Surveillance Regulation (EU) 2019/1020 Authority response playbook from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on EU Market Surveillance Regulation (EU) 2019/1020 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Market Surveillance Regulation (EU) 2019/1020 Authority response playbook](/solutions/assessment.md): Start from EU Market Surveillance Regulation (EU) 2019/1020 Authority response playbook and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Market Surveillance Regulation (EU) 2019/1020](/contact.md): Review your current process, evidence gaps, and next steps for EU Market Surveillance Regulation (EU) 2019/1020 Authority response playbook. ## Primary sources - [Regulation (EU) 2019/1020 - Articles 4, 14, 17, 18, 19, 20, 25 to 28, and 34 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj/eng?ref=sorena.io) - Primary source for response obligations, investigative powers, procedural rights, serious-risk handling, customs coordination, and structured information flow. - [Commission Notice 2021/C 100/01 on Article 4 implementation (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=oj:JOC_2021_100_R_0001&ref=sorena.io) - Official practical guidance on how Article 4 evidence and cooperation duties should be handled. ## Related Topic Guides - [Enforcement powers and penalties | EU MSR (Regulation (EU) 2019/1020) | Checks, serious risk, penalties](/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties.md): A practical enforcement guide for Regulation (EU) 2019/1020 covering Article 11 risk-based checks, Article 14 authority powers. - [EU Market Surveillance Regulation applicability test | Regulation (EU) 2019/1020 scope, Article 6 distance sales](/artifacts/eu/market-surveillance-regulation/applicability-test.md): A practical applicability test for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU Market Surveillance Regulation requirements | Regulation (EU) 2019/1020 (MSR) obligations](/artifacts/eu/market-surveillance-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2019/1020 covering Article 4 EU economic-operator tasks, Article 6 distance-sales targeting. - [EU MSR Article 4 economic operator duties and responsible-person setup | Regulation (EU) 2019/1020](/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties.md): A practical guide to Article 4 of Regulation (EU) 2019/1020: when an EU economic operator is required, who can act, what Article 4(3) tasks they perform. - [EU MSR checklist | Regulation (EU) 2019/1020 compliance checklist for inspections](/artifacts/eu/market-surveillance-regulation/checklist.md): An audit-ready checklist for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting and distance sales (Article 6). - [EU MSR compliance program | Regulation (EU) 2019/1020 implementation guide](/artifacts/eu/market-surveillance-regulation/compliance.md): A practical implementation guide for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU MSR deadlines and compliance calendar | Regulation (EU) 2019/1020 key dates (Article 44, Article 41)](/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar.md): Key dates for Regulation (EU) 2019/1020 covering early application from 1 January 2021 for Articles 29 to 33 and 36, general application from 16 July 2021. - [EU MSR FAQ | Regulation (EU) 2019/1020 questions (Article 4, Article 6, investigations)](/artifacts/eu/market-surveillance-regulation/faq.md): Answers to common questions about the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting (Article 6). - [EU MSR penalties and fines | Article 41 penalties (Regulation (EU) 2019/1020) | Reduce exposure](/artifacts/eu/market-surveillance-regulation/penalties-and-fines.md): Penalty exposure under Regulation (EU) 2019/1020: what Article 41 requires, why penalties differ by Member State. - [Investigations and evidence requests | EU Market Surveillance Regulation (EU) 2019/1020 | What authorities check](/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests.md): A practical guide to MSR investigations under Regulation (EU) 2019/1020 covering Article 11 risk-based checks. - [Market surveillance for online marketplaces | EU MSR (Regulation (EU) 2019/1020) | Operator controls](/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces.md): A practical guide for online marketplaces under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 7(2) cooperation. - [MSR vs GPSR | Market Surveillance Regulation (EU) 2019/1020 vs General Product Safety Regulation (EU) 2023/988](/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr.md): A grounded comparison of Regulation (EU) 2019/1020 and Regulation (EU) 2023/988: MSR as the enforcement and coordination framework. - [Online sales under the EU Market Surveillance Regulation | Article 6 distance sales + ecommerce controls](/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces.md): A practical guide for ecommerce sellers under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 4 operator identification. - [What changes with EU market surveillance | Regulation (EU) 2019/1020 (MSR) practical impact](/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes.md): A practical 'what changed' guide for Regulation (EU) 2019/1020: stronger EU-wide coordination, explicit online/distance sales targeting logic (Article 6). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook --- --- title: "EU MSR checklist" canonical_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/checklist" source_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/checklist" author: "Sorena AI" description: "An audit-ready checklist for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting and distance sales (Article 6)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU MSR checklist" - "Regulation (EU) 2019/1020 checklist" - "market surveillance compliance checklist" - "inspection readiness checklist EU" - "Article 4 economic operator checklist" - "Article 6 distance sales checklist" - "checklist" - "inspection readiness" - "Article 4" - "Article 6" - "evidence pack" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU MSR checklist An audit-ready checklist for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting and distance sales (Article 6). *Checklist* *EU* ## EU Market Surveillance Regulation (EU) 2019/1020 Inspection-readiness checklist Owners, evidence, and 'done looks like' criteria. Designed for product, quality, legal, ecommerce, and marketplace operations teams. MSR compliance is proven under pressure: when authorities ask for evidence, when marketplaces require quick takedowns, and when a serious-risk case forces immediate corrective action. Use this checklist as an inspection-readiness baseline per product family and per sales channel. ## 1) Scope and channel triggers Decide where MSR enforcement exposure exists: online targeting, offline distribution, marketplaces, and fulfilment operations. Document the 'targeting' logic for each storefront and channel (Article 6). - Storefront targeting decision documented (languages, currencies, shipping, marketing signals). - Channel map maintained (DTC, distributors, marketplaces, fulfilment providers). - Product-family inventory tied to applicable EU harmonisation laws (for Article 4(5) products). ## 2) Article 4 economic operator setup (for applicable products) For product laws listed in Article 4(5), confirm there is an EU-established economic operator responsible for Article 4(3) tasks and that contracts/mandates cover evidence and assistance. Ensure the economic operator is identifiable on product/packaging/parcel/accompanying document (Article 4(4)). - Operator type confirmed (manufacturer/importer/authorised representative/fulfilment service provider) (Article 4(2)). - Written mandate/contract includes technical documentation access and response SLAs. - Packaging/parcel process verified with samples and QC checks (operator name + EU address). ## 3) Evidence pack readiness (what you can produce fast) Authorities perform documentary checks and may require tests/samples depending on risk (Article 11). Your goal is a stable evidence pack per product family that can be delivered quickly and consistently across Member States. Treat evidence as a system: indexing, versioning, ownership, and secure sharing. - DoC/DoP current and retrievable; technical documentation index maintained (Article 4(3)(a)). - Test reports and standards list current; change log ties tests to versions/batches. - Traceability: can map listing/SKU -> version -> batch/serial -> shipment/warehouse windows. - Authority pack summary available in a language easily understood by the authority (Article 4(3)(b)). ## 4) Investigation response and corrective action Cross-border evidence reuse means responses must be consistent and defensible (Article 11(6)). Ensure you can respond while respecting confidentiality and procedural rights (Articles 17-18). Corrective action must be executable quickly, from listing takedowns to withdrawals/recalls in serious-risk cases (Articles 19-20). - Authority intake playbook: case owner, approvals, secure sharing, and a single written record. - Procedural rights handled: grounds, remedies, hearing opportunity where applicable (Article 18). - Immediate controls: pause shipments, disable listings, quarantine stock, preserve evidence. - Serious-risk playbook: risk assessment -> withdrawal/recall -> reporting workflow (Articles 19-20). *Recommended next step* *Placement: after the checklist block* ## Turn EU Market Surveillance Regulation (EU) 2019/1020 Inspection-readiness checklist into an operational assessment Assessment Autopilot can take EU Market Surveillance Regulation (EU) 2019/1020 Inspection-readiness checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Market Surveillance Regulation (EU) 2019/1020 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Market Surveillance Regulation (EU) 2019/1020 Inspection-readiness checklist](/solutions/assessment.md): Start from EU Market Surveillance Regulation (EU) 2019/1020 Inspection-readiness checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Market Surveillance Regulation (EU) 2019/1020](/contact.md): Review your current process, evidence gaps, and next steps for EU Market Surveillance Regulation (EU) 2019/1020 Inspection-readiness checklist. ## Primary sources - [Regulation (EU) 2019/1020 - Market Surveillance Regulation (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Primary source for Article 4 operator duties, Article 6 distance sales, authority checks (Article 11), procedural rights (Article 18), serious risk (Articles 19-20), and penalties (Article 41). ## Related Topic Guides - [Authority request response playbook | EU Market Surveillance Regulation (EU) 2019/1020 | Evidence requests, corrective action](/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook.md): An operational playbook for responding to authority requests under Regulation (EU) 2019/1020: first-24-hour triage, Article 4 evidence packs. - [Enforcement powers and penalties | EU MSR (Regulation (EU) 2019/1020) | Checks, serious risk, penalties](/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties.md): A practical enforcement guide for Regulation (EU) 2019/1020 covering Article 11 risk-based checks, Article 14 authority powers. - [EU Market Surveillance Regulation applicability test | Regulation (EU) 2019/1020 scope, Article 6 distance sales](/artifacts/eu/market-surveillance-regulation/applicability-test.md): A practical applicability test for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU Market Surveillance Regulation requirements | Regulation (EU) 2019/1020 (MSR) obligations](/artifacts/eu/market-surveillance-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2019/1020 covering Article 4 EU economic-operator tasks, Article 6 distance-sales targeting. - [EU MSR Article 4 economic operator duties and responsible-person setup | Regulation (EU) 2019/1020](/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties.md): A practical guide to Article 4 of Regulation (EU) 2019/1020: when an EU economic operator is required, who can act, what Article 4(3) tasks they perform. - [EU MSR compliance program | Regulation (EU) 2019/1020 implementation guide](/artifacts/eu/market-surveillance-regulation/compliance.md): A practical implementation guide for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU MSR deadlines and compliance calendar | Regulation (EU) 2019/1020 key dates (Article 44, Article 41)](/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar.md): Key dates for Regulation (EU) 2019/1020 covering early application from 1 January 2021 for Articles 29 to 33 and 36, general application from 16 July 2021. - [EU MSR FAQ | Regulation (EU) 2019/1020 questions (Article 4, Article 6, investigations)](/artifacts/eu/market-surveillance-regulation/faq.md): Answers to common questions about the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting (Article 6). - [EU MSR penalties and fines | Article 41 penalties (Regulation (EU) 2019/1020) | Reduce exposure](/artifacts/eu/market-surveillance-regulation/penalties-and-fines.md): Penalty exposure under Regulation (EU) 2019/1020: what Article 41 requires, why penalties differ by Member State. - [Investigations and evidence requests | EU Market Surveillance Regulation (EU) 2019/1020 | What authorities check](/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests.md): A practical guide to MSR investigations under Regulation (EU) 2019/1020 covering Article 11 risk-based checks. - [Market surveillance for online marketplaces | EU MSR (Regulation (EU) 2019/1020) | Operator controls](/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces.md): A practical guide for online marketplaces under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 7(2) cooperation. - [MSR vs GPSR | Market Surveillance Regulation (EU) 2019/1020 vs General Product Safety Regulation (EU) 2023/988](/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr.md): A grounded comparison of Regulation (EU) 2019/1020 and Regulation (EU) 2023/988: MSR as the enforcement and coordination framework. - [Online sales under the EU Market Surveillance Regulation | Article 6 distance sales + ecommerce controls](/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces.md): A practical guide for ecommerce sellers under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 4 operator identification. - [What changes with EU market surveillance | Regulation (EU) 2019/1020 (MSR) practical impact](/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes.md): A practical 'what changed' guide for Regulation (EU) 2019/1020: stronger EU-wide coordination, explicit online/distance sales targeting logic (Article 6). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/market-surveillance-regulation/checklist --- --- title: "EU MSR compliance program" canonical_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/compliance" source_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/compliance" author: "Sorena AI" description: "A practical implementation guide for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU MSR compliance program" - "Regulation (EU) 2019/1020 compliance guide" - "market surveillance readiness program" - "Article 4 economic operator implementation" - "authority evidence request response" - "serious risk withdrawal recall workflow" - "implementation" - "inspection readiness" - "Article 4" - "evidence packs" - "corrective action" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU MSR compliance program A practical implementation guide for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). *Program* *EU* ## EU Market Surveillance Regulation (EU) 2019/1020 Compliance program Build an inspection-ready operating model. Owners, evidence, channel controls, and response playbooks that scale across products and Member States. MSR compliance is operational. Your program should treat enforcement as a lifecycle capability: prevent non-compliant offers, maintain a retrievable technical documentation system, respond to investigations with consistent evidence, and execute corrective actions quickly. The core program design is: product-family evidence packs + channel controls + authority response playbook + serious-risk workflow + KPIs and CAPA. ## 1) Program scope: products, channels, and targeting Start with a product-family inventory and channel map (DTC, distributors, marketplaces, fulfilment). Document your online targeting decisions: distance sales targeted at EU end users are treated as making products available on the EU market (Article 6). Use this to prioritise: high-volume EU channels and higher-risk categories get the strictest release gates and fastest evidence SLAs. - Channel map maintained and reviewed quarterly. - Storefront targeting rules documented and aligned to marketing + shipping settings. - Product-family risk scoring drives evidence depth and monitoring cadence. ## 2) Ownership and Article 4 setup (where applicable) Where Article 4 applies, confirm an EU-established economic operator is responsible for documentation and cooperation tasks (Article 4). Define ownership explicitly: who answers authorities, who provides evidence, and who executes corrective action. Contract for compliance: mandates and supplier agreements should guarantee technical access, evidence availability, and response SLAs. - Named case owner + named technical evidence owner per product family. - Operator contact details are consistently labeled on product/packaging/parcel/accompanying document where required (Article 4(4)). - Supplier and fulfilment contracts include evidence access and corrective action coordination clauses. ## 3) Evidence architecture: product-family dossiers and exportable packs Authorities perform documentary checks and may request tests/samples (Article 11). Treat evidence as a managed system: indexing, versioning, and traceability. Evidence collected in one Member State can be reused in another (Article 11(6)), so consistency is non-negotiable. Create a 'one-click export' authority pack per product family: DoC/DoP, technical documentation index, test reports, traceability, and corrective action history. - Evidence index per product family with owners and update cadence. - Secure sharing workflow and a 'what we told authorities' register for cross-border consistency. - Language workflow for evidence summaries (Article 4(3)(b)). ## 4) Response playbooks and serious-risk workflow Build a repeatable authority-response playbook that respects confidentiality and procedural rights (Articles 17-18) while delivering evidence quickly. Prepare a serious-risk workflow for withdrawals/recalls (Articles 19-20). The key is speed without chaos: immediate controls (shipments/listings) plus a stable evidence narrative. - Authority response playbook: intake -> triage -> evidence pack -> corrective action -> CAPA. - Serious-risk path: risk assessment -> withdrawal/recall -> notifications -> customer communications. - Tabletop exercises twice per year for investigations and serious-risk scenarios. *Recommended next step* *Placement: after the compliance steps* ## Turn EU Market Surveillance Regulation (EU) 2019/1020 Compliance program into an operational assessment Assessment Autopilot can take EU Market Surveillance Regulation (EU) 2019/1020 Compliance program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Market Surveillance Regulation (EU) 2019/1020 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Market Surveillance Regulation (EU) 2019/1020 Compliance program](/solutions/assessment.md): Start from EU Market Surveillance Regulation (EU) 2019/1020 Compliance program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Market Surveillance Regulation (EU) 2019/1020](/contact.md): Review your current process, evidence gaps, and next steps for EU Market Surveillance Regulation (EU) 2019/1020 Compliance program. ## Primary sources - [Regulation (EU) 2019/1020 - Articles 4, 6, 11, 17 to 20, 25 to 28, and 34 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj/eng?ref=sorena.io) - Primary source for operator setup, online targeting, enforcement checks, procedural requirements, customs controls, and cross-border information flow. - [Commission Notice 2021/C 100/01 on Article 4 implementation (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=oj:JOC_2021_100_R_0001&ref=sorena.io) - Official practical guidance for Article 4 operational design. - [European Commission market surveillance for products page](https://single-market-economy.ec.europa.eu/single-market/goods/building-blocks/market-surveillance/products_en?ref=sorena.io) - Official current overview of MSR implementation materials, Article 4 report, and supporting structures. ## Related Topic Guides - [Authority request response playbook | EU Market Surveillance Regulation (EU) 2019/1020 | Evidence requests, corrective action](/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook.md): An operational playbook for responding to authority requests under Regulation (EU) 2019/1020: first-24-hour triage, Article 4 evidence packs. - [Enforcement powers and penalties | EU MSR (Regulation (EU) 2019/1020) | Checks, serious risk, penalties](/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties.md): A practical enforcement guide for Regulation (EU) 2019/1020 covering Article 11 risk-based checks, Article 14 authority powers. - [EU Market Surveillance Regulation applicability test | Regulation (EU) 2019/1020 scope, Article 6 distance sales](/artifacts/eu/market-surveillance-regulation/applicability-test.md): A practical applicability test for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU Market Surveillance Regulation requirements | Regulation (EU) 2019/1020 (MSR) obligations](/artifacts/eu/market-surveillance-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2019/1020 covering Article 4 EU economic-operator tasks, Article 6 distance-sales targeting. - [EU MSR Article 4 economic operator duties and responsible-person setup | Regulation (EU) 2019/1020](/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties.md): A practical guide to Article 4 of Regulation (EU) 2019/1020: when an EU economic operator is required, who can act, what Article 4(3) tasks they perform. - [EU MSR checklist | Regulation (EU) 2019/1020 compliance checklist for inspections](/artifacts/eu/market-surveillance-regulation/checklist.md): An audit-ready checklist for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting and distance sales (Article 6). - [EU MSR deadlines and compliance calendar | Regulation (EU) 2019/1020 key dates (Article 44, Article 41)](/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar.md): Key dates for Regulation (EU) 2019/1020 covering early application from 1 January 2021 for Articles 29 to 33 and 36, general application from 16 July 2021. - [EU MSR FAQ | Regulation (EU) 2019/1020 questions (Article 4, Article 6, investigations)](/artifacts/eu/market-surveillance-regulation/faq.md): Answers to common questions about the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting (Article 6). - [EU MSR penalties and fines | Article 41 penalties (Regulation (EU) 2019/1020) | Reduce exposure](/artifacts/eu/market-surveillance-regulation/penalties-and-fines.md): Penalty exposure under Regulation (EU) 2019/1020: what Article 41 requires, why penalties differ by Member State. - [Investigations and evidence requests | EU Market Surveillance Regulation (EU) 2019/1020 | What authorities check](/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests.md): A practical guide to MSR investigations under Regulation (EU) 2019/1020 covering Article 11 risk-based checks. - [Market surveillance for online marketplaces | EU MSR (Regulation (EU) 2019/1020) | Operator controls](/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces.md): A practical guide for online marketplaces under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 7(2) cooperation. - [MSR vs GPSR | Market Surveillance Regulation (EU) 2019/1020 vs General Product Safety Regulation (EU) 2023/988](/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr.md): A grounded comparison of Regulation (EU) 2019/1020 and Regulation (EU) 2023/988: MSR as the enforcement and coordination framework. - [Online sales under the EU Market Surveillance Regulation | Article 6 distance sales + ecommerce controls](/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces.md): A practical guide for ecommerce sellers under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 4 operator identification. - [What changes with EU market surveillance | Regulation (EU) 2019/1020 (MSR) practical impact](/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes.md): A practical 'what changed' guide for Regulation (EU) 2019/1020: stronger EU-wide coordination, explicit online/distance sales targeting logic (Article 6). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/market-surveillance-regulation/compliance --- --- title: "EU MSR deadlines and compliance calendar" canonical_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Key dates for Regulation (EU) 2019/1020 covering early application from 1 January 2021 for Articles 29 to 33 and 36, general application from 16 July 2021." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU MSR deadlines" - "Regulation (EU) 2019/1020 key dates" - "MSR application date 16 July 2021" - "MSR early application 1 January 2021" - "MSR penalties notification 16 October 2021" - "MSR evaluation 31 December 2026" - "Article 44" - "application dates" - "penalties" - "evaluation" - "MSR timeline" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU MSR deadlines and compliance calendar Key dates for Regulation (EU) 2019/1020 covering early application from 1 January 2021 for Articles 29 to 33 and 36, general application from 16 July 2021. *Calendar* *EU* ## EU Market Surveillance Regulation (EU) 2019/1020 Key dates and calendar A calendar you can turn into workstreams and release gates. Focus: application dates, penalties notifications, and evaluation milestones that drive enforcement readiness planning. MSR enforcement is continuous, but the Regulation and the current Commission implementation material give you a small set of dates that matter operationally: early application of the cooperation and network structure, general application from 16 July 2021, penalty-notification timing, annual customs statistics and Commission reporting, and the later Commission follow-up on Article 4 implementation. ## 1) Application dates under Article 44 The Regulation applies from 16 July 2021, but Articles 29, 30, 31, 32, 33 and 36 applied earlier from 1 January 2021. Those earlier articles matter because they cover the Network, ADCOs, Commission support, and financing. Treat 1 January 2021 as the start of the coordinated-enforcement layer and 16 July 2021 as the point when the core operator and channel obligations became generally live. - 1 January 2021: Articles 29 to 33 and 36 started to apply. - 16 July 2021: general application date and replacement of the market-surveillance provisions of Regulation (EC) No 765/2008. - Use new product families, new storefronts, and new fulfilment models as re-check points against the live MSR baseline. ## 2) Penalties, annual customs reporting, and review milestones Article 41 required Member States to notify penalty rules by 16 October 2021. Article 25 adds a yearly customs-reporting cycle that is easy to miss but useful for understanding enforcement focus. These are the dates that show the Regulation is not static: Member States, customs authorities, and the Commission keep feeding the system. - 16 October 2021: Member States had to notify penalty rules to the Commission under Article 41(3). - 31 March each year: Member States submit Article 25 customs-control statistics for the previous calendar year. - 30 June each year: the Commission draws up and publishes the Article 25 customs-control report in the Article 34 system. - 16 July 2024: first regular Network evaluation of national market-surveillance strategies under Article 31(2)(o). *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU Market Surveillance Regulation (EU) 2019/1020 Key dates and calendar into an operational assessment Assessment Autopilot can take EU Market Surveillance Regulation (EU) 2019/1020 Key dates and calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Market Surveillance Regulation (EU) 2019/1020 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Market Surveillance Regulation (EU) 2019/1020 Key dates and calendar](/solutions/assessment.md): Start from EU Market Surveillance Regulation (EU) 2019/1020 Key dates and calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Market Surveillance Regulation (EU) 2019/1020](/contact.md): Review your current process, evidence gaps, and next steps for EU Market Surveillance Regulation (EU) 2019/1020 Key dates and calendar. ## 3) Article 4 follow-up and current-state milestones Article 42(3) set a 16 July 2023 deadline for the Commission report on Article 4 implementation. The official implementation report was published in 2025 and now gives the best current high-level view of how Article 4 worked in practice from 2021 to 2023. Use that report, together with the 2021 Article 4 guidance notice, as the current policy baseline for non-EU manufacturers, importers, authorised representatives, and fulfilment-service providers. - 16 July 2023: statutory deadline in Article 42(3) for the Article 4 implementation report. - 3 March 2025: Commission report on the implementation of Article 4 published on EUR-Lex. - 31 December 2026: broader Commission evaluation deadline under Article 42(1), then every five years. ## Primary sources - [Regulation (EU) 2019/1020 - Articles 25, 31, 41, 42, and 44 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj/eng?ref=sorena.io) - Primary source for application dates, annual customs reporting, penalties, and evaluation milestones. - [Report on the implementation of Article 4 of Regulation (EU) 2019/1020 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52025DC0063&ref=sorena.io) - Current official report on Article 4 implementation published in 2025. - [European Commission market surveillance for products page](https://single-market-economy.ec.europa.eu/single-market/goods/building-blocks/market-surveillance/products_en?ref=sorena.io) - Official implementation overview including the Article 4 report and current supporting materials. ## Related Topic Guides - [Authority request response playbook | EU Market Surveillance Regulation (EU) 2019/1020 | Evidence requests, corrective action](/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook.md): An operational playbook for responding to authority requests under Regulation (EU) 2019/1020: first-24-hour triage, Article 4 evidence packs. - [Enforcement powers and penalties | EU MSR (Regulation (EU) 2019/1020) | Checks, serious risk, penalties](/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties.md): A practical enforcement guide for Regulation (EU) 2019/1020 covering Article 11 risk-based checks, Article 14 authority powers. - [EU Market Surveillance Regulation applicability test | Regulation (EU) 2019/1020 scope, Article 6 distance sales](/artifacts/eu/market-surveillance-regulation/applicability-test.md): A practical applicability test for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU Market Surveillance Regulation requirements | Regulation (EU) 2019/1020 (MSR) obligations](/artifacts/eu/market-surveillance-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2019/1020 covering Article 4 EU economic-operator tasks, Article 6 distance-sales targeting. - [EU MSR Article 4 economic operator duties and responsible-person setup | Regulation (EU) 2019/1020](/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties.md): A practical guide to Article 4 of Regulation (EU) 2019/1020: when an EU economic operator is required, who can act, what Article 4(3) tasks they perform. - [EU MSR checklist | Regulation (EU) 2019/1020 compliance checklist for inspections](/artifacts/eu/market-surveillance-regulation/checklist.md): An audit-ready checklist for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting and distance sales (Article 6). - [EU MSR compliance program | Regulation (EU) 2019/1020 implementation guide](/artifacts/eu/market-surveillance-regulation/compliance.md): A practical implementation guide for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU MSR FAQ | Regulation (EU) 2019/1020 questions (Article 4, Article 6, investigations)](/artifacts/eu/market-surveillance-regulation/faq.md): Answers to common questions about the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting (Article 6). - [EU MSR penalties and fines | Article 41 penalties (Regulation (EU) 2019/1020) | Reduce exposure](/artifacts/eu/market-surveillance-regulation/penalties-and-fines.md): Penalty exposure under Regulation (EU) 2019/1020: what Article 41 requires, why penalties differ by Member State. - [Investigations and evidence requests | EU Market Surveillance Regulation (EU) 2019/1020 | What authorities check](/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests.md): A practical guide to MSR investigations under Regulation (EU) 2019/1020 covering Article 11 risk-based checks. - [Market surveillance for online marketplaces | EU MSR (Regulation (EU) 2019/1020) | Operator controls](/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces.md): A practical guide for online marketplaces under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 7(2) cooperation. - [MSR vs GPSR | Market Surveillance Regulation (EU) 2019/1020 vs General Product Safety Regulation (EU) 2023/988](/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr.md): A grounded comparison of Regulation (EU) 2019/1020 and Regulation (EU) 2023/988: MSR as the enforcement and coordination framework. - [Online sales under the EU Market Surveillance Regulation | Article 6 distance sales + ecommerce controls](/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces.md): A practical guide for ecommerce sellers under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 4 operator identification. - [What changes with EU market surveillance | Regulation (EU) 2019/1020 (MSR) practical impact](/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes.md): A practical 'what changed' guide for Regulation (EU) 2019/1020: stronger EU-wide coordination, explicit online/distance sales targeting logic (Article 6). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar --- --- title: "Enforcement powers and penalties" canonical_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties" source_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties" author: "Sorena AI" description: "A practical enforcement guide for Regulation (EU) 2019/1020 covering Article 11 risk-based checks, Article 14 authority powers." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU MSR enforcement powers" - "Regulation (EU) 2019/1020 enforcement" - "Article 11 market surveillance checks" - "serious risk withdrawal recall Article 19" - "Safety Gate RAPEX Article 20" - "MSR penalties Article 41" - "market surveillance authorities" - "serious risk" - "withdrawal recall" - "penalties" - "ICSMS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Enforcement powers and penalties A practical enforcement guide for Regulation (EU) 2019/1020 covering Article 11 risk-based checks, Article 14 authority powers. *Enforcement* *EU* ## EU Market Surveillance Regulation (EU) 2019/1020 Enforcement powers How checks and escalations actually happen. Risk-based checks, serious-risk actions, cross-border coordination, and penalty exposure drivers. MSR enforcement is designed to scale across borders and channels. Authorities check products made available online and offline (Article 11), share evidence across Member States (Article 11(6)), and escalate serious-risk cases into withdrawal/recall and rapid information exchange (Articles 19-20). The best way to reduce enforcement exposure is to treat evidence readiness and corrective action as core operating capabilities, not as legal documents. ## 1) Risk-based checks (Article 11) Authorities perform documentary checks and, where appropriate, physical and laboratory checks at adequate scale (Article 11(3)). They follow a risk-based approach that considers hazards/non-compliance, the operator's activities, past record, risk profiling, and complaints/other information sources (Article 11(3)). Evidence reuse across Member States means a single weak evidence pack can have EU-wide impact (Article 11(6)). - Authorities can check documents, inspect products physically, test samples, inspect under cover identity, and start investigations on their own initiative. - They can also require supply-chain information, technically similar model information, and access to embedded software where necessary. - The key preparation control is one evidence system that can support both a fast document response and a deeper investigation. ## 2) Serious risk escalation (Articles 19-20) For products presenting a serious risk, authorities ensure withdrawal/recall (where no other effective means exist) or prohibit making available on the market (Article 19(1)). The serious-risk decision must be based on an appropriate risk assessment (Article 19(2)). When measures go beyond a single Member State, authorities notify the Commission using rapid information exchange mechanisms (Article 20). - Serious-risk playbook: risk assessment -> decisioning -> withdrawal/recall -> communications -> evidence preservation. - Channel controls: immediate takedown and shipment holds for affected listings and warehouses. - Post-market monitoring: define triggers for re-testing, supplier audits, and category-wide checks. ## 3) Data-sharing and enforcement memory (Article 34) The Article 34 information and communication system is the enforcement memory that supports requests for information, testing, measures, customs coordination, and public-facing information. It reduces duplication for authorities and increases the cost of inconsistency for operators. Operationally, that means every submission should be versioned and reusable across countries. - Use a 'what we told authorities' register with versioned submissions and addenda. - Tie internal incident IDs to external case IDs for traceability. - Keep a CAPA record that maps corrective actions to root causes and prevention controls. *Recommended next step* *Placement: after the enforcement section* ## Use EU Market Surveillance Regulation (EU) 2019/1020 Enforcement powers as a cited research workflow Research Copilot can take EU Market Surveillance Regulation (EU) 2019/1020 Enforcement powers from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Market Surveillance Regulation (EU) 2019/1020 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Market Surveillance Regulation (EU) 2019/1020 Enforcement powers](/solutions/research-copilot.md): Start from EU Market Surveillance Regulation (EU) 2019/1020 Enforcement powers and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Market Surveillance Regulation (EU) 2019/1020](/contact.md): Review your current process, evidence gaps, and next steps for EU Market Surveillance Regulation (EU) 2019/1020 Enforcement powers. ## 4) Penalties (Article 41): what you can control Member States must set penalty rules for infringements of MSR and certain harmonisation legislation obligations and ensure they are implemented (Article 41). Penalties must be effective, proportionate and dissuasive (Article 41(2)). You can't control penalty tables, but you can control the behaviors that drive enforcement: documentation completeness, response speed, and corrective action quality. - Prevent: listing gates + packaging/labeling controls + supplier evidence requirements. - Detect: complaint triage + periodic evidence audits + channel monitoring. - Respond: authority-response playbook + serious-risk workflow + CAPA governance. ## Primary sources - [Regulation (EU) 2019/1020 - Articles 11, 14, 19, 20, 34, and 41 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj/eng?ref=sorena.io) - Primary source for checks, powers, serious-risk measures, coordinated data sharing, and penalties. ## Related Topic Guides - [Authority request response playbook | EU Market Surveillance Regulation (EU) 2019/1020 | Evidence requests, corrective action](/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook.md): An operational playbook for responding to authority requests under Regulation (EU) 2019/1020: first-24-hour triage, Article 4 evidence packs. - [EU Market Surveillance Regulation applicability test | Regulation (EU) 2019/1020 scope, Article 6 distance sales](/artifacts/eu/market-surveillance-regulation/applicability-test.md): A practical applicability test for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU Market Surveillance Regulation requirements | Regulation (EU) 2019/1020 (MSR) obligations](/artifacts/eu/market-surveillance-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2019/1020 covering Article 4 EU economic-operator tasks, Article 6 distance-sales targeting. - [EU MSR Article 4 economic operator duties and responsible-person setup | Regulation (EU) 2019/1020](/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties.md): A practical guide to Article 4 of Regulation (EU) 2019/1020: when an EU economic operator is required, who can act, what Article 4(3) tasks they perform. - [EU MSR checklist | Regulation (EU) 2019/1020 compliance checklist for inspections](/artifacts/eu/market-surveillance-regulation/checklist.md): An audit-ready checklist for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting and distance sales (Article 6). - [EU MSR compliance program | Regulation (EU) 2019/1020 implementation guide](/artifacts/eu/market-surveillance-regulation/compliance.md): A practical implementation guide for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU MSR deadlines and compliance calendar | Regulation (EU) 2019/1020 key dates (Article 44, Article 41)](/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar.md): Key dates for Regulation (EU) 2019/1020 covering early application from 1 January 2021 for Articles 29 to 33 and 36, general application from 16 July 2021. - [EU MSR FAQ | Regulation (EU) 2019/1020 questions (Article 4, Article 6, investigations)](/artifacts/eu/market-surveillance-regulation/faq.md): Answers to common questions about the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting (Article 6). - [EU MSR penalties and fines | Article 41 penalties (Regulation (EU) 2019/1020) | Reduce exposure](/artifacts/eu/market-surveillance-regulation/penalties-and-fines.md): Penalty exposure under Regulation (EU) 2019/1020: what Article 41 requires, why penalties differ by Member State. - [Investigations and evidence requests | EU Market Surveillance Regulation (EU) 2019/1020 | What authorities check](/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests.md): A practical guide to MSR investigations under Regulation (EU) 2019/1020 covering Article 11 risk-based checks. - [Market surveillance for online marketplaces | EU MSR (Regulation (EU) 2019/1020) | Operator controls](/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces.md): A practical guide for online marketplaces under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 7(2) cooperation. - [MSR vs GPSR | Market Surveillance Regulation (EU) 2019/1020 vs General Product Safety Regulation (EU) 2023/988](/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr.md): A grounded comparison of Regulation (EU) 2019/1020 and Regulation (EU) 2023/988: MSR as the enforcement and coordination framework. - [Online sales under the EU Market Surveillance Regulation | Article 6 distance sales + ecommerce controls](/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces.md): A practical guide for ecommerce sellers under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 4 operator identification. - [What changes with EU market surveillance | Regulation (EU) 2019/1020 (MSR) practical impact](/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes.md): A practical 'what changed' guide for Regulation (EU) 2019/1020: stronger EU-wide coordination, explicit online/distance sales targeting logic (Article 6). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties --- --- title: "EU MSR FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/faq" source_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/faq" author: "Sorena AI" description: "Answers to common questions about the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting (Article 6)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU MSR FAQ" - "Regulation (EU) 2019/1020 FAQ" - "Article 4 economic operator FAQ" - "Article 6 distance sales EU FAQ" - "market surveillance evidence request FAQ" - "Article 18 procedural rights FAQ" - "FAQ" - "Article 4" - "Article 6" - "evidence requests" - "procedural rights" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU MSR FAQ Answers to common questions about the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting (Article 6). *FAQ* *EU* ## EU Market Surveillance Regulation (EU) 2019/1020 FAQ Fast answers to the questions teams ask during investigations. Focus: online targeting, Article 4 operator duties, evidence requests, and procedural rights. MSR questions usually arrive in the middle of an operational incident: an authority email, a marketplace escalation, or a complaint that becomes a formal investigation. This FAQ is designed to be practical: what triggers scope, who must do what, and what evidence you should be able to produce quickly. ## Top questions (quick answers) Does MSR apply to online sales? Yes. Products offered online or via distance sales are deemed to be made available on the EU market if the offer is targeted at end users in the Union (Article 6). Do we need an EU 'responsible person' or economic operator? For products covered by the laws listed in Article 4(5), the product may be placed on the market only if there is an EU-established economic operator responsible for Article 4 tasks (Article 4(1)-(2)). What will authorities ask for first? Product identification + operator contact details, declarations (DoC/DoP), and an index to technical documentation and tests - plus what corrective actions you are taking. - Article 6 = online targeting trigger. - Article 4 = EU operator + documentation/cooperation tasks (for specific product laws). - Article 11 = risk-based checks; evidence can be reused cross-border. ## Article 4 questions (economic operator duties) Who can be the Article 4 economic operator? Article 4(2) lists: EU manufacturer, importer (if manufacturer not EU), authorised representative with written mandate, or (if none of those exist) an EU fulfilment service provider for the products it handles. What must they do? Article 4(3) tasks include verifying declarations/technical documentation exist and ensuring technical documentation can be provided on request; providing information in a language easily understood by the authority; informing authorities when there is reason to believe a product presents a risk; and cooperating to ensure corrective actions are taken. - Labeling/packaging: operator name + postal address must be indicated on product/packaging/parcel/accompanying document (Article 4(4)). - Treat Article 4 as a system: mandate + evidence index + response SLAs. ## Investigations and your rights How do checks work? Authorities perform documentary checks and may perform physical/lab checks using a risk-based approach (Article 11). Evidence can be reused across Member States without further formal requirements (Article 11(6)). Do we get a chance to respond? Measures/orders must state grounds and be communicated; operators must be informed of remedies (Article 18(1)-(2)). Operators should generally be given an opportunity to be heard for at least 10 working days unless urgent (Article 18(3)). - Keep responses consistent and versioned; assume cross-border reuse. - Use secure sharing and a clear redaction policy for trade secrets (Article 17). *Recommended next step* *Placement: after the FAQ section* ## Use EU Market Surveillance Regulation (EU) 2019/1020 FAQ as a cited research workflow Research Copilot can take EU Market Surveillance Regulation (EU) 2019/1020 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU Market Surveillance Regulation (EU) 2019/1020 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Market Surveillance Regulation (EU) 2019/1020 FAQ](/solutions/research-copilot.md): Start from EU Market Surveillance Regulation (EU) 2019/1020 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Market Surveillance Regulation (EU) 2019/1020](/contact.md): Review your current process, evidence gaps, and next steps for EU Market Surveillance Regulation (EU) 2019/1020 FAQ. ## Primary sources - [Regulation (EU) 2019/1020 - Market Surveillance Regulation (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj/eng?ref=sorena.io) - Primary source for Article 4, Article 6, investigation powers, procedural rights, customs controls, and penalties. - [Commission Notice 2021/C 100/01 on Article 4 implementation (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=oj:JOC_2021_100_R_0001&ref=sorena.io) - Official practical guidance on Article 4 implementation. - [Report on the implementation of Article 4 of Regulation (EU) 2019/1020 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52025DC0063&ref=sorena.io) - Official 2025 implementation report for current practice context. ## Related Topic Guides - [Authority request response playbook | EU Market Surveillance Regulation (EU) 2019/1020 | Evidence requests, corrective action](/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook.md): An operational playbook for responding to authority requests under Regulation (EU) 2019/1020: first-24-hour triage, Article 4 evidence packs. - [Enforcement powers and penalties | EU MSR (Regulation (EU) 2019/1020) | Checks, serious risk, penalties](/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties.md): A practical enforcement guide for Regulation (EU) 2019/1020 covering Article 11 risk-based checks, Article 14 authority powers. - [EU Market Surveillance Regulation applicability test | Regulation (EU) 2019/1020 scope, Article 6 distance sales](/artifacts/eu/market-surveillance-regulation/applicability-test.md): A practical applicability test for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU Market Surveillance Regulation requirements | Regulation (EU) 2019/1020 (MSR) obligations](/artifacts/eu/market-surveillance-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2019/1020 covering Article 4 EU economic-operator tasks, Article 6 distance-sales targeting. - [EU MSR Article 4 economic operator duties and responsible-person setup | Regulation (EU) 2019/1020](/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties.md): A practical guide to Article 4 of Regulation (EU) 2019/1020: when an EU economic operator is required, who can act, what Article 4(3) tasks they perform. - [EU MSR checklist | Regulation (EU) 2019/1020 compliance checklist for inspections](/artifacts/eu/market-surveillance-regulation/checklist.md): An audit-ready checklist for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting and distance sales (Article 6). - [EU MSR compliance program | Regulation (EU) 2019/1020 implementation guide](/artifacts/eu/market-surveillance-regulation/compliance.md): A practical implementation guide for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU MSR deadlines and compliance calendar | Regulation (EU) 2019/1020 key dates (Article 44, Article 41)](/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar.md): Key dates for Regulation (EU) 2019/1020 covering early application from 1 January 2021 for Articles 29 to 33 and 36, general application from 16 July 2021. - [EU MSR penalties and fines | Article 41 penalties (Regulation (EU) 2019/1020) | Reduce exposure](/artifacts/eu/market-surveillance-regulation/penalties-and-fines.md): Penalty exposure under Regulation (EU) 2019/1020: what Article 41 requires, why penalties differ by Member State. - [Investigations and evidence requests | EU Market Surveillance Regulation (EU) 2019/1020 | What authorities check](/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests.md): A practical guide to MSR investigations under Regulation (EU) 2019/1020 covering Article 11 risk-based checks. - [Market surveillance for online marketplaces | EU MSR (Regulation (EU) 2019/1020) | Operator controls](/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces.md): A practical guide for online marketplaces under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 7(2) cooperation. - [MSR vs GPSR | Market Surveillance Regulation (EU) 2019/1020 vs General Product Safety Regulation (EU) 2023/988](/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr.md): A grounded comparison of Regulation (EU) 2019/1020 and Regulation (EU) 2023/988: MSR as the enforcement and coordination framework. - [Online sales under the EU Market Surveillance Regulation | Article 6 distance sales + ecommerce controls](/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces.md): A practical guide for ecommerce sellers under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 4 operator identification. - [What changes with EU market surveillance | Regulation (EU) 2019/1020 (MSR) practical impact](/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes.md): A practical 'what changed' guide for Regulation (EU) 2019/1020: stronger EU-wide coordination, explicit online/distance sales targeting logic (Article 6). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/market-surveillance-regulation/faq --- --- title: "Investigations and evidence requests" canonical_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests" source_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests" author: "Sorena AI" description: "A practical guide to MSR investigations under Regulation (EU) 2019/1020 covering Article 11 risk-based checks." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "market surveillance investigation evidence request" - "EU MSR investigations" - "Regulation (EU) 2019/1020 Article 11 checks" - "technical documentation on request" - "declaration of conformity evidence pack" - "Article 18 procedural rights economic operator" - "Article 11 checks" - "evidence requests" - "technical documentation" - "procedural rights" - "ICSMS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Investigations and evidence requests A practical guide to MSR investigations under Regulation (EU) 2019/1020 covering Article 11 risk-based checks. *Artifact Guide* *EU* ## EU Market Surveillance Regulation (EU) 2019/1020 Investigations and evidence requests What authorities check and how to be ready. Risk-based checks, evidence packs, procedural rights, and cross-border coordination. MSR investigations are operationally predictable: authorities run risk-based checks, request documentary evidence, and may escalate to physical/lab checks. What changes outcomes is not "having documents somewhere", but being able to produce the right evidence quickly, in the right structure, with clear versioning and traceability - and being able to execute corrective actions when evidence shows non-compliance or risk. ## 1) How authorities conduct checks (Article 11) Authorities work on a risk basis, but the available power set is broad. The investigation may begin as a document check and quickly expand into testing, site access, online-interface measures, or customs coordination. Prepare for that expansion from the start instead of treating the first request as an isolated email. - Assume cross-border reuse: make evidence pack structure consistent and easy to interpret. - Keep a product-family dossier: what changed, when, and why (design, supplier, software, labeling, standards). - Treat marketplace and ecommerce as first-class channels: online and offline checks are explicitly in scope (Article 11(1)(a)). ## 2) What evidence is typically requested Article 4 economic operator tasks explicitly include verifying that declarations and technical documentation have been drawn up and ensuring technical documentation can be made available on request (Article 4(3)(a)). Authorities can request all information and documentation necessary to demonstrate conformity (Article 4(3)(b)). In practice, evidence requests usually aim to answer four questions: what is the product, what rules apply, what evidence shows conformity, and what actions are taken when risk/non-compliance exists. - Expect requests for declarations, technical documentation, tests, supply-chain information, quantities on the market, and information about technically similar models. - Expect requests relating to website ownership and operator identity where online offers are in scope. - Where necessary for compliance assessment, expect requests for access to embedded software and related technical information. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Market Surveillance Regulation (EU) 2019/1020 Investigations and evidence requests in one governed evidence system SSOT can take EU Market Surveillance Regulation (EU) 2019/1020 Investigations and evidence requests from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Market Surveillance Regulation (EU) 2019/1020 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Market Surveillance Regulation (EU) 2019/1020 Investigations and evidence requests](/solutions/ssot.md): Start from EU Market Surveillance Regulation (EU) 2019/1020 Investigations and evidence requests and keep documents, evidence, and control records in one governed system. - [Talk through EU Market Surveillance Regulation (EU) 2019/1020](/contact.md): Review your current process, evidence gaps, and next steps for EU Market Surveillance Regulation (EU) 2019/1020 Investigations and evidence requests. ## 3) Confidentiality and procedural rights Authorities must respect confidentiality, professional and commercial secrecy and protect personal data (Article 17). At the same time, measures/orders must state grounds and be communicated; operators must be informed of remedies and time limits (Article 18(1)-(2)). Before measures are taken, operators generally get an opportunity to be heard for at least 10 working days unless urgent (Article 18(3)). Build your response process around these procedural expectations. - Secure sharing: define channels for confidential evidence and how you track who received what. - Redaction policy: separate trade secrets from required conformity evidence; justify redactions consistently. - Response governance: single case owner, clear approvals, and a fixed evidence pack structure. ## 4) Data-sharing and coordination (Article 34) Article 34 is the structured system behind requests for information, measures, testing, and corrective action. Evidence from one Member State can shape action in another, and customs-related cases also feed into the same coordinated layer. This is why product-family evidence indexing matters more than ad hoc case folders. - Keep your evidence pack versioned and immutable after submission; issue addenda instead of overwriting. - Align internal incident IDs with external case IDs for traceability. - Maintain a "what we told authorities" register per product family. ## Primary sources - [Regulation (EU) 2019/1020 - Articles 11, 14, 17, 18, and 34 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj/eng?ref=sorena.io) - Primary source for investigation methods, evidence powers, confidentiality, procedural rights, and structured information sharing. ## Related Topic Guides - [Authority request response playbook | EU Market Surveillance Regulation (EU) 2019/1020 | Evidence requests, corrective action](/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook.md): An operational playbook for responding to authority requests under Regulation (EU) 2019/1020: first-24-hour triage, Article 4 evidence packs. - [Enforcement powers and penalties | EU MSR (Regulation (EU) 2019/1020) | Checks, serious risk, penalties](/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties.md): A practical enforcement guide for Regulation (EU) 2019/1020 covering Article 11 risk-based checks, Article 14 authority powers. - [EU Market Surveillance Regulation applicability test | Regulation (EU) 2019/1020 scope, Article 6 distance sales](/artifacts/eu/market-surveillance-regulation/applicability-test.md): A practical applicability test for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU Market Surveillance Regulation requirements | Regulation (EU) 2019/1020 (MSR) obligations](/artifacts/eu/market-surveillance-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2019/1020 covering Article 4 EU economic-operator tasks, Article 6 distance-sales targeting. - [EU MSR Article 4 economic operator duties and responsible-person setup | Regulation (EU) 2019/1020](/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties.md): A practical guide to Article 4 of Regulation (EU) 2019/1020: when an EU economic operator is required, who can act, what Article 4(3) tasks they perform. - [EU MSR checklist | Regulation (EU) 2019/1020 compliance checklist for inspections](/artifacts/eu/market-surveillance-regulation/checklist.md): An audit-ready checklist for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting and distance sales (Article 6). - [EU MSR compliance program | Regulation (EU) 2019/1020 implementation guide](/artifacts/eu/market-surveillance-regulation/compliance.md): A practical implementation guide for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU MSR deadlines and compliance calendar | Regulation (EU) 2019/1020 key dates (Article 44, Article 41)](/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar.md): Key dates for Regulation (EU) 2019/1020 covering early application from 1 January 2021 for Articles 29 to 33 and 36, general application from 16 July 2021. - [EU MSR FAQ | Regulation (EU) 2019/1020 questions (Article 4, Article 6, investigations)](/artifacts/eu/market-surveillance-regulation/faq.md): Answers to common questions about the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting (Article 6). - [EU MSR penalties and fines | Article 41 penalties (Regulation (EU) 2019/1020) | Reduce exposure](/artifacts/eu/market-surveillance-regulation/penalties-and-fines.md): Penalty exposure under Regulation (EU) 2019/1020: what Article 41 requires, why penalties differ by Member State. - [Market surveillance for online marketplaces | EU MSR (Regulation (EU) 2019/1020) | Operator controls](/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces.md): A practical guide for online marketplaces under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 7(2) cooperation. - [MSR vs GPSR | Market Surveillance Regulation (EU) 2019/1020 vs General Product Safety Regulation (EU) 2023/988](/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr.md): A grounded comparison of Regulation (EU) 2019/1020 and Regulation (EU) 2023/988: MSR as the enforcement and coordination framework. - [Online sales under the EU Market Surveillance Regulation | Article 6 distance sales + ecommerce controls](/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces.md): A practical guide for ecommerce sellers under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 4 operator identification. - [What changes with EU market surveillance | Regulation (EU) 2019/1020 (MSR) practical impact](/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes.md): A practical 'what changed' guide for Regulation (EU) 2019/1020: stronger EU-wide coordination, explicit online/distance sales targeting logic (Article 6). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests --- --- title: "Market surveillance for online marketplaces" canonical_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces" source_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces" author: "Sorena AI" description: "A practical guide for online marketplaces under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 7(2) cooperation." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU MSR online marketplace" - "market surveillance for online marketplaces EU" - "Regulation (EU) 2019/1020 Article 7 cooperation information society service providers" - "marketplace authority request response" - "marketplace product compliance takedown" - "online marketplaces" - "Article 7(2)" - "distance sales" - "market surveillance" - "takedown workflow" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Market surveillance for online marketplaces A practical guide for online marketplaces under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 7(2) cooperation. *Artifact Guide* *EU* ## EU Market Surveillance Regulation (EU) 2019/1020 Online marketplace readiness Cooperate with authorities and prevent repeat non-compliance at scale. Focus: Article 7(2) cooperation expectations, listing governance, seller traceability, and fast corrective action. Online marketplaces often sit at the "distribution channel" edge where MSR enforcement becomes visible: listings can be investigated, evidence can be requested, and corrective actions (takedowns, shipment holds) are expected quickly. MSR recognises that information society service providers may need to cooperate with market surveillance authorities, at the request of authorities and in specific cases, to facilitate actions to eliminate or mitigate risks presented by products offered for sale online (Article 7(2)). This page turns that into practical marketplace controls. ## 1) Scope trigger: distance sales targeting (Article 6) Products offered online are deemed to be made available on the EU market if the offer is targeted at EU end users (Article 6). Marketplaces operating EU storefronts, EU shipping, or EU-targeted marketing should assume investigations can be initiated based on listing information and consumer complaints. The operational implication is not only 'takedown ability' - it's 'evidence preservation + traceability + fast coordination'. - Ensure EU-facing listings include enough information for product identification and operator contact details where available. - Maintain seller and product identifiers that allow you to reproduce listing history after changes. - Prepare to coordinate with the economic operator responsible for the product's compliance evidence. ## 2) Cooperation with authorities (Article 7(2)) Article 7(2) requires information-society service providers to cooperate with authorities in specific cases at their request to facilitate action that eliminates or mitigates product risk. Article 14 adds sharper tools for serious-risk cases involving online interfaces. That means marketplaces need both a cooperation process and a serious-risk escalation path. - Keep a process for preserving listing evidence, seller identity, and order-flow data when an authority request arrives. - Prepare to remove content, display warnings, or support access restrictions when the legal thresholds are met. - Coordinate seller outreach, listing action, and fulfilment holds so the marketplace response is internally consistent. ## 3) Marketplace controls that reduce enforcement risk Market surveillance authorities conduct risk-based checks and can follow up on complaints (Article 11). Marketplaces can reduce repeated enforcement incidents by building controls that prevent re-listing of the same unsafe/non-compliant product and by requiring better seller evidence upfront for high-risk categories. Your goal is to make the marketplace 'compliance-aware' without becoming the product manufacturer: enforce process controls, preserve evidence, and cooperate in specific cases. - Listing governance: category-specific required fields (model/version, operator contact, manuals, warnings). - Seller traceability: KYC and contact points that remain stable across storefronts and rebrands. - Repeat offender controls: block sellers or SKUs after repeated serious-risk cases; require additional evidence before reactivation. - Evidence preservation: immutable snapshots of listing content, seller details, and transaction windows for investigations. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU Market Surveillance Regulation (EU) 2019/1020 Online marketplace readiness as a cited research workflow Research Copilot can take EU Market Surveillance Regulation (EU) 2019/1020 Online marketplace readiness from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU Market Surveillance Regulation (EU) 2019/1020 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Market Surveillance Regulation (EU) 2019/1020 Online marketplace readiness](/solutions/research-copilot.md): Start from EU Market Surveillance Regulation (EU) 2019/1020 Online marketplace readiness and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Market Surveillance Regulation (EU) 2019/1020](/contact.md): Review your current process, evidence gaps, and next steps for EU Market Surveillance Regulation (EU) 2019/1020 Online marketplace readiness. ## Primary sources - [Regulation (EU) 2019/1020 - Articles 6, 7(2), and 14(4)(k) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj/eng?ref=sorena.io) - Primary source for online-targeting logic, cooperation by information-society service providers, and serious-risk online-interface powers. ## Related Topic Guides - [Authority request response playbook | EU Market Surveillance Regulation (EU) 2019/1020 | Evidence requests, corrective action](/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook.md): An operational playbook for responding to authority requests under Regulation (EU) 2019/1020: first-24-hour triage, Article 4 evidence packs. - [Enforcement powers and penalties | EU MSR (Regulation (EU) 2019/1020) | Checks, serious risk, penalties](/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties.md): A practical enforcement guide for Regulation (EU) 2019/1020 covering Article 11 risk-based checks, Article 14 authority powers. - [EU Market Surveillance Regulation applicability test | Regulation (EU) 2019/1020 scope, Article 6 distance sales](/artifacts/eu/market-surveillance-regulation/applicability-test.md): A practical applicability test for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU Market Surveillance Regulation requirements | Regulation (EU) 2019/1020 (MSR) obligations](/artifacts/eu/market-surveillance-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2019/1020 covering Article 4 EU economic-operator tasks, Article 6 distance-sales targeting. - [EU MSR Article 4 economic operator duties and responsible-person setup | Regulation (EU) 2019/1020](/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties.md): A practical guide to Article 4 of Regulation (EU) 2019/1020: when an EU economic operator is required, who can act, what Article 4(3) tasks they perform. - [EU MSR checklist | Regulation (EU) 2019/1020 compliance checklist for inspections](/artifacts/eu/market-surveillance-regulation/checklist.md): An audit-ready checklist for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting and distance sales (Article 6). - [EU MSR compliance program | Regulation (EU) 2019/1020 implementation guide](/artifacts/eu/market-surveillance-regulation/compliance.md): A practical implementation guide for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU MSR deadlines and compliance calendar | Regulation (EU) 2019/1020 key dates (Article 44, Article 41)](/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar.md): Key dates for Regulation (EU) 2019/1020 covering early application from 1 January 2021 for Articles 29 to 33 and 36, general application from 16 July 2021. - [EU MSR FAQ | Regulation (EU) 2019/1020 questions (Article 4, Article 6, investigations)](/artifacts/eu/market-surveillance-regulation/faq.md): Answers to common questions about the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting (Article 6). - [EU MSR penalties and fines | Article 41 penalties (Regulation (EU) 2019/1020) | Reduce exposure](/artifacts/eu/market-surveillance-regulation/penalties-and-fines.md): Penalty exposure under Regulation (EU) 2019/1020: what Article 41 requires, why penalties differ by Member State. - [Investigations and evidence requests | EU Market Surveillance Regulation (EU) 2019/1020 | What authorities check](/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests.md): A practical guide to MSR investigations under Regulation (EU) 2019/1020 covering Article 11 risk-based checks. - [MSR vs GPSR | Market Surveillance Regulation (EU) 2019/1020 vs General Product Safety Regulation (EU) 2023/988](/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr.md): A grounded comparison of Regulation (EU) 2019/1020 and Regulation (EU) 2023/988: MSR as the enforcement and coordination framework. - [Online sales under the EU Market Surveillance Regulation | Article 6 distance sales + ecommerce controls](/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces.md): A practical guide for ecommerce sellers under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 4 operator identification. - [What changes with EU market surveillance | Regulation (EU) 2019/1020 (MSR) practical impact](/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes.md): A practical 'what changed' guide for Regulation (EU) 2019/1020: stronger EU-wide coordination, explicit online/distance sales targeting logic (Article 6). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces --- --- title: "MSR vs GPSR" canonical_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr" source_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr" author: "Sorena AI" description: "A grounded comparison of Regulation (EU) 2019/1020 and Regulation (EU) 2023/988: MSR as the enforcement and coordination framework." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "MSR vs GPSR" - "market surveillance regulation vs general product safety regulation" - "Regulation (EU) 2019/1020 vs 2023/988" - "EU product safety enforcement" - "online sales product safety EU" - "evidence requests product compliance EU" - "comparison" - "MSR" - "GPSR" - "product safety" - "enforcement" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # MSR vs GPSR A grounded comparison of Regulation (EU) 2019/1020 and Regulation (EU) 2023/988: MSR as the enforcement and coordination framework. *Comparison* *EU* ## MSR vs GPSR How they fit together Enforcement framework vs product safety duties. Use one operational readiness program: evidence packs, online controls, and corrective-action workflows. Teams often confuse 'market surveillance' with 'general product safety'. They work together, but they do different jobs. MSR (Regulation (EU) 2019/1020) is an enforcement framework for how authorities check products, request evidence, coordinate across borders, and handle serious risk. GPSR (Regulation (EU) 2023/988) focuses on general consumer product safety duties and related obligations. In practice, you implement them together: one evidence system, one investigation response playbook, and one corrective-action capability. ## 1) What MSR does vs what GPSR does MSR: defines how market surveillance authorities conduct checks (including online/offline), how evidence is shared, and how serious-risk cases are escalated and coordinated. It also introduces specific economic operator tasks for certain product laws (Article 4) and defines distance sales targeting logic (Article 6). GPSR: sets general product safety obligations for consumer products. Even when GPSR is your safety-duty baseline, MSR is often the mechanism that determines how your product will be investigated and what evidence you must produce. - Use MSR to design authority-response, customs-interaction, and cross-border evidence workflows. - Use GPSR to design consumer-product safety duties, warning and traceability content, and post-market safety management. - Keep one product-family dossier and one corrective-action playbook so the two regimes reinforce each other instead of diverging. *Recommended next step* *Placement: after the comparison section* ## Use MSR vs GPSR How they fit together as a cited research workflow Research Copilot can take MSR vs GPSR How they fit together from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on MSR vs GPSR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for MSR vs GPSR How they fit together](/solutions/research-copilot.md): Start from MSR vs GPSR How they fit together and answer scope, timing, and interpretation questions with cited outputs. - [Talk through MSR vs GPSR](/contact.md): Review your current process, evidence gaps, and next steps for MSR vs GPSR How they fit together. ## 2) Scope and channel overlaps (online sales is where confusion happens) MSR explicitly treats distance sales offers as 'made available' in the EU when targeted at EU end users (Article 6). That makes ecommerce and marketplaces enforcement-critical channels. Even if your product safety duties come from GPSR or sector-specific rules, MSR will drive how authorities request evidence and coordinate across borders. - Document targeting decisions per storefront and align marketing + shipping settings. - Implement listing gates to prevent non-compliant products from going live. - Maintain traceability from listing -> SKU version -> batch/serial -> shipments. ## 3) Practical implementation: one readiness program A good program avoids 'two parallel compliance stacks'. Build one operating model that satisfies both safety duties and enforcement demands: product-family dossiers, consistent evidence exports, rapid corrective actions, and cross-border consistency. Under MSR, evidence can be reused across Member States (Article 11(6)), so inconsistency becomes a direct risk. - Evidence packs: DoC/technical documentation index, tests, traceability, change log, complaint history, CAPA history. - Response playbook: intake -> evidence pack -> communications -> corrective action -> CAPA. - Serious-risk workflow: withdrawal/recall and rapid reporting readiness. ## Primary sources - [Regulation (EU) 2019/1020 - Market Surveillance Regulation (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj/eng?ref=sorena.io) - Primary source for enforcement structure, Article 4 duties, Article 6 targeting, and coordinated measures. - [Regulation (EU) 2023/988 - General Product Safety Regulation (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/988/oj/eng?ref=sorena.io) - Primary source for general consumer-product safety obligations. ## Related Topic Guides - [Authority request response playbook | EU Market Surveillance Regulation (EU) 2019/1020 | Evidence requests, corrective action](/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook.md): An operational playbook for responding to authority requests under Regulation (EU) 2019/1020: first-24-hour triage, Article 4 evidence packs. - [Enforcement powers and penalties | EU MSR (Regulation (EU) 2019/1020) | Checks, serious risk, penalties](/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties.md): A practical enforcement guide for Regulation (EU) 2019/1020 covering Article 11 risk-based checks, Article 14 authority powers. - [EU Market Surveillance Regulation applicability test | Regulation (EU) 2019/1020 scope, Article 6 distance sales](/artifacts/eu/market-surveillance-regulation/applicability-test.md): A practical applicability test for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU Market Surveillance Regulation requirements | Regulation (EU) 2019/1020 (MSR) obligations](/artifacts/eu/market-surveillance-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2019/1020 covering Article 4 EU economic-operator tasks, Article 6 distance-sales targeting. - [EU MSR Article 4 economic operator duties and responsible-person setup | Regulation (EU) 2019/1020](/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties.md): A practical guide to Article 4 of Regulation (EU) 2019/1020: when an EU economic operator is required, who can act, what Article 4(3) tasks they perform. - [EU MSR checklist | Regulation (EU) 2019/1020 compliance checklist for inspections](/artifacts/eu/market-surveillance-regulation/checklist.md): An audit-ready checklist for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting and distance sales (Article 6). - [EU MSR compliance program | Regulation (EU) 2019/1020 implementation guide](/artifacts/eu/market-surveillance-regulation/compliance.md): A practical implementation guide for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU MSR deadlines and compliance calendar | Regulation (EU) 2019/1020 key dates (Article 44, Article 41)](/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar.md): Key dates for Regulation (EU) 2019/1020 covering early application from 1 January 2021 for Articles 29 to 33 and 36, general application from 16 July 2021. - [EU MSR FAQ | Regulation (EU) 2019/1020 questions (Article 4, Article 6, investigations)](/artifacts/eu/market-surveillance-regulation/faq.md): Answers to common questions about the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting (Article 6). - [EU MSR penalties and fines | Article 41 penalties (Regulation (EU) 2019/1020) | Reduce exposure](/artifacts/eu/market-surveillance-regulation/penalties-and-fines.md): Penalty exposure under Regulation (EU) 2019/1020: what Article 41 requires, why penalties differ by Member State. - [Investigations and evidence requests | EU Market Surveillance Regulation (EU) 2019/1020 | What authorities check](/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests.md): A practical guide to MSR investigations under Regulation (EU) 2019/1020 covering Article 11 risk-based checks. - [Market surveillance for online marketplaces | EU MSR (Regulation (EU) 2019/1020) | Operator controls](/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces.md): A practical guide for online marketplaces under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 7(2) cooperation. - [Online sales under the EU Market Surveillance Regulation | Article 6 distance sales + ecommerce controls](/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces.md): A practical guide for ecommerce sellers under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 4 operator identification. - [What changes with EU market surveillance | Regulation (EU) 2019/1020 (MSR) practical impact](/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes.md): A practical 'what changed' guide for Regulation (EU) 2019/1020: stronger EU-wide coordination, explicit online/distance sales targeting logic (Article 6). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr --- --- title: "Online sales under the EU Market Surveillance Regulation" canonical_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces" source_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces" author: "Sorena AI" description: "A practical guide for ecommerce sellers under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 4 operator identification." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU MSR online sales" - "Regulation (EU) 2019/1020 distance sales" - "Article 6 targeted at end users in the Union" - "ecommerce product compliance evidence" - "technical documentation on request ecommerce" - "marketplace listing compliance EU" - "Article 6" - "distance sales" - "ecommerce compliance" - "marketplace listings" - "technical documentation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Online sales under the EU Market Surveillance Regulation A practical guide for ecommerce sellers under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 4 operator identification. *Ecommerce* *EU* ## EU Market Surveillance Regulation (EU) 2019/1020 Online sales controls Make ecommerce listings inspection-ready. Focus: Article 6 distance sales targeting, operator setup, and evidence retrieval for authority checks. MSR closes the gap between offline and online enforcement. If your online offer is targeted at EU end users, the product is deemed to be made available on the EU market (Article 6). That means your ecommerce operations must be able to answer authority questions quickly: who is the EU economic operator contact, what rules apply, where is the declaration/technical documentation, and what corrective actions can you execute immediately if a risk is identified. ## 1) Article 6: when an online offer is 'made available' in the EU MSR deems products offered for sale online (or through other distance sales) to be made available on the EU market if the offer is targeted at end users in the Union (Article 6). This is not about company incorporation; it's about how you direct activities to a Member State. For ecommerce, targeting signals are often created accidentally via shipping settings, marketing, and language/currency localisation. - Document targeting decisions per storefront: what countries you ship to and how you localise. - Align ads/SEO with your targeting decision (avoid mismatched EU targeting signals). - If you do target the EU: treat MSR as a required operational capability, not a legal memo. ## 2) Seller-side controls: prevent non-compliant listings Authorities conduct checks for products made available online and offline (Article 11(1)(a)). Your best strategy is prevention: make it difficult for a listing to go live without a complete evidence pack and a clear EU contact. For products where Article 4 applies, ensure an EU-established economic operator is responsible for documentation availability and cooperation tasks (Article 4). - Require a declaration link or controlled evidence reference before listing publication. - Map each listing to the Article 4 operator details, SKU version, and fulfilment path. - Keep listing content, parcel inserts, and warehouse labels synchronized so customs and end-user artifacts do not diverge. ## 3) Fast corrective action (what 'good' looks like in investigations) MSR expects corrective action when needed and provides mechanisms for serious-risk escalation (Articles 11, 19-20). Ecommerce teams must be able to execute immediate controls while legal/quality validate evidence and remediation. Treat "authority response" as a production workflow: your speed and evidence quality are part of your compliance posture. - Be able to pause listings, stop shipments, and preserve page content and order data immediately. - Route customs-hold cases and authority-request cases into the same evidence workflow rather than splitting them by team. - Close with CAPA so missing operator details, declaration gaps, or misleading listing content do not recur. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU Market Surveillance Regulation (EU) 2019/1020 Online sales controls as a cited research workflow Research Copilot can take EU Market Surveillance Regulation (EU) 2019/1020 Online sales controls from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU Market Surveillance Regulation (EU) 2019/1020 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Market Surveillance Regulation (EU) 2019/1020 Online sales controls](/solutions/research-copilot.md): Start from EU Market Surveillance Regulation (EU) 2019/1020 Online sales controls and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Market Surveillance Regulation (EU) 2019/1020](/contact.md): Review your current process, evidence gaps, and next steps for EU Market Surveillance Regulation (EU) 2019/1020 Online sales controls. ## Primary sources - [Regulation (EU) 2019/1020 - Articles 4, 6, 14, and 26 to 28 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj/eng?ref=sorena.io) - Primary source for online targeting, operator identification, online-interface powers, and customs escalation where online sales and import flows meet. ## Related Topic Guides - [Authority request response playbook | EU Market Surveillance Regulation (EU) 2019/1020 | Evidence requests, corrective action](/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook.md): An operational playbook for responding to authority requests under Regulation (EU) 2019/1020: first-24-hour triage, Article 4 evidence packs. - [Enforcement powers and penalties | EU MSR (Regulation (EU) 2019/1020) | Checks, serious risk, penalties](/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties.md): A practical enforcement guide for Regulation (EU) 2019/1020 covering Article 11 risk-based checks, Article 14 authority powers. - [EU Market Surveillance Regulation applicability test | Regulation (EU) 2019/1020 scope, Article 6 distance sales](/artifacts/eu/market-surveillance-regulation/applicability-test.md): A practical applicability test for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU Market Surveillance Regulation requirements | Regulation (EU) 2019/1020 (MSR) obligations](/artifacts/eu/market-surveillance-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2019/1020 covering Article 4 EU economic-operator tasks, Article 6 distance-sales targeting. - [EU MSR Article 4 economic operator duties and responsible-person setup | Regulation (EU) 2019/1020](/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties.md): A practical guide to Article 4 of Regulation (EU) 2019/1020: when an EU economic operator is required, who can act, what Article 4(3) tasks they perform. - [EU MSR checklist | Regulation (EU) 2019/1020 compliance checklist for inspections](/artifacts/eu/market-surveillance-regulation/checklist.md): An audit-ready checklist for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting and distance sales (Article 6). - [EU MSR compliance program | Regulation (EU) 2019/1020 implementation guide](/artifacts/eu/market-surveillance-regulation/compliance.md): A practical implementation guide for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU MSR deadlines and compliance calendar | Regulation (EU) 2019/1020 key dates (Article 44, Article 41)](/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar.md): Key dates for Regulation (EU) 2019/1020 covering early application from 1 January 2021 for Articles 29 to 33 and 36, general application from 16 July 2021. - [EU MSR FAQ | Regulation (EU) 2019/1020 questions (Article 4, Article 6, investigations)](/artifacts/eu/market-surveillance-regulation/faq.md): Answers to common questions about the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting (Article 6). - [EU MSR penalties and fines | Article 41 penalties (Regulation (EU) 2019/1020) | Reduce exposure](/artifacts/eu/market-surveillance-regulation/penalties-and-fines.md): Penalty exposure under Regulation (EU) 2019/1020: what Article 41 requires, why penalties differ by Member State. - [Investigations and evidence requests | EU Market Surveillance Regulation (EU) 2019/1020 | What authorities check](/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests.md): A practical guide to MSR investigations under Regulation (EU) 2019/1020 covering Article 11 risk-based checks. - [Market surveillance for online marketplaces | EU MSR (Regulation (EU) 2019/1020) | Operator controls](/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces.md): A practical guide for online marketplaces under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 7(2) cooperation. - [MSR vs GPSR | Market Surveillance Regulation (EU) 2019/1020 vs General Product Safety Regulation (EU) 2023/988](/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr.md): A grounded comparison of Regulation (EU) 2019/1020 and Regulation (EU) 2023/988: MSR as the enforcement and coordination framework. - [What changes with EU market surveillance | Regulation (EU) 2019/1020 (MSR) practical impact](/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes.md): A practical 'what changed' guide for Regulation (EU) 2019/1020: stronger EU-wide coordination, explicit online/distance sales targeting logic (Article 6). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces --- --- title: "EU MSR penalties and fines" canonical_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/penalties-and-fines" author: "Sorena AI" description: "Penalty exposure under Regulation (EU) 2019/1020: what Article 41 requires, why penalties differ by Member State." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU MSR penalties" - "Regulation (EU) 2019/1020 Article 41 penalties" - "market surveillance fines EU" - "MSR enforcement penalties" - "reduce market surveillance penalty exposure" - "serious risk withdrawal recall penalties" - "Article 41" - "penalties" - "enforcement" - "serious risk" - "market surveillance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU MSR penalties and fines Penalty exposure under Regulation (EU) 2019/1020: what Article 41 requires, why penalties differ by Member State. *Penalties* *EU* ## EU Market Surveillance Regulation (EU) 2019/1020 Penalties and fines What drives penalty exposure - and what reduces it. Penalty rules vary by Member State, but your controllable levers are evidence readiness, response speed, and corrective action quality. The MSR is an enforcement framework. Article 41 requires Member States to lay down penalty rules for infringements of the Regulation and certain harmonisation legislation obligations and to implement them. Penalties must be effective, proportionate and dissuasive (Article 41). You can't standardise penalty tables, but you can standardise the operational behavior that reduces enforcement exposure: prevent non-compliant listings, keep documentation retrievable, respond fast to authority requests, and execute serious-risk corrective actions correctly. ## 1) What Article 41 actually does (and doesn't do) Article 41 requires Member States to set effective, proportionate, and dissuasive penalties and notify those rules to the Commission. The tables differ by country, but the underlying exposure pattern is stable. The Commission market-surveillance page now links a consolidated overview of notified national penalties, which makes country-level exposure easier to check. - Penalty exposure increases with: repeated non-compliance, slow evidence delivery, poor corrective action, and serious-risk findings. - Evidence reuse across Member States means one poor response can have multi-country consequences (Article 11(6)). - Treat penalty risk as a prioritisation tool for which products/channels get the tightest controls. ## 2) Practical controls that reduce penalty exposure Authorities aim to ensure operators take corrective action and can take measures when they don't (Article 11(1)). Your best defense is a prevention-first operating model with fast response capability. Most penalty exposure is created by predictable operational failures: missing declarations/technical files, unclear EU operator contact, weak traceability, and slow execution of corrective actions. - Listing controls: block publication for EU-targeted offers unless evidence pack completeness checks pass (Article 6). - Article 4 readiness: ensure an EU economic operator exists where required and can produce documentation quickly (Article 4). - Authority response: use a single playbook with SLAs, secure sharing, and versioned evidence packs (Articles 17-18). - Serious-risk workflow: be able to pause sales and execute withdrawal/recall decisions when needed (Article 19). ## 3) Evidence you should have ready (penalty drivers) Penalty risk is higher when your evidence is inconsistent, missing, or not quickly retrievable. Build an evidence pack that is repeatable across product families and channels. Treat every investigation as durable: your response can be referenced later and across borders. - Product-family dossier: DoC/DoP, technical documentation index, standards/test reports, traceability, change log. - Channel evidence: listing history, targeting decision, shipment logs, marketplace actions (takedown, relisting blocks). - Corrective action evidence: CAPA records, verification tests, and closure criteria. *Recommended next step* *Placement: after the enforcement section* ## Use EU Market Surveillance Regulation (EU) 2019/1020 Penalties and fines as a cited research workflow Research Copilot can take EU Market Surveillance Regulation (EU) 2019/1020 Penalties and fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Market Surveillance Regulation (EU) 2019/1020 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Market Surveillance Regulation (EU) 2019/1020 Penalties and fines](/solutions/research-copilot.md): Start from EU Market Surveillance Regulation (EU) 2019/1020 Penalties and fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Market Surveillance Regulation (EU) 2019/1020](/contact.md): Review your current process, evidence gaps, and next steps for EU Market Surveillance Regulation (EU) 2019/1020 Penalties and fines. ## Primary sources - [Regulation (EU) 2019/1020 - Article 41 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj/eng?ref=sorena.io) - Primary source for Member State penalty obligations. - [European Commission market surveillance for products page](https://single-market-economy.ec.europa.eu/single-market/goods/building-blocks/market-surveillance/products_en?ref=sorena.io) - Official Commission page linking the notified-penalties overview for Regulation (EU) 2019/1020. ## Related Topic Guides - [Authority request response playbook | EU Market Surveillance Regulation (EU) 2019/1020 | Evidence requests, corrective action](/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook.md): An operational playbook for responding to authority requests under Regulation (EU) 2019/1020: first-24-hour triage, Article 4 evidence packs. - [Enforcement powers and penalties | EU MSR (Regulation (EU) 2019/1020) | Checks, serious risk, penalties](/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties.md): A practical enforcement guide for Regulation (EU) 2019/1020 covering Article 11 risk-based checks, Article 14 authority powers. - [EU Market Surveillance Regulation applicability test | Regulation (EU) 2019/1020 scope, Article 6 distance sales](/artifacts/eu/market-surveillance-regulation/applicability-test.md): A practical applicability test for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU Market Surveillance Regulation requirements | Regulation (EU) 2019/1020 (MSR) obligations](/artifacts/eu/market-surveillance-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2019/1020 covering Article 4 EU economic-operator tasks, Article 6 distance-sales targeting. - [EU MSR Article 4 economic operator duties and responsible-person setup | Regulation (EU) 2019/1020](/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties.md): A practical guide to Article 4 of Regulation (EU) 2019/1020: when an EU economic operator is required, who can act, what Article 4(3) tasks they perform. - [EU MSR checklist | Regulation (EU) 2019/1020 compliance checklist for inspections](/artifacts/eu/market-surveillance-regulation/checklist.md): An audit-ready checklist for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting and distance sales (Article 6). - [EU MSR compliance program | Regulation (EU) 2019/1020 implementation guide](/artifacts/eu/market-surveillance-regulation/compliance.md): A practical implementation guide for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU MSR deadlines and compliance calendar | Regulation (EU) 2019/1020 key dates (Article 44, Article 41)](/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar.md): Key dates for Regulation (EU) 2019/1020 covering early application from 1 January 2021 for Articles 29 to 33 and 36, general application from 16 July 2021. - [EU MSR FAQ | Regulation (EU) 2019/1020 questions (Article 4, Article 6, investigations)](/artifacts/eu/market-surveillance-regulation/faq.md): Answers to common questions about the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting (Article 6). - [Investigations and evidence requests | EU Market Surveillance Regulation (EU) 2019/1020 | What authorities check](/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests.md): A practical guide to MSR investigations under Regulation (EU) 2019/1020 covering Article 11 risk-based checks. - [Market surveillance for online marketplaces | EU MSR (Regulation (EU) 2019/1020) | Operator controls](/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces.md): A practical guide for online marketplaces under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 7(2) cooperation. - [MSR vs GPSR | Market Surveillance Regulation (EU) 2019/1020 vs General Product Safety Regulation (EU) 2023/988](/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr.md): A grounded comparison of Regulation (EU) 2019/1020 and Regulation (EU) 2023/988: MSR as the enforcement and coordination framework. - [Online sales under the EU Market Surveillance Regulation | Article 6 distance sales + ecommerce controls](/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces.md): A practical guide for ecommerce sellers under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 4 operator identification. - [What changes with EU market surveillance | Regulation (EU) 2019/1020 (MSR) practical impact](/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes.md): A practical 'what changed' guide for Regulation (EU) 2019/1020: stronger EU-wide coordination, explicit online/distance sales targeting logic (Article 6). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/market-surveillance-regulation/penalties-and-fines --- --- title: "EU Market Surveillance Regulation requirements" canonical_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/requirements" source_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/requirements" author: "Sorena AI" description: "A practical requirements breakdown for Regulation (EU) 2019/1020 covering Article 4 EU economic-operator tasks, Article 6 distance-sales targeting." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Market Surveillance Regulation requirements" - "Regulation (EU) 2019/1020 requirements" - "MSR obligations" - "Article 4 economic operator tasks" - "Article 6 distance sales EU" - "market surveillance authority evidence request" - "ICSMS Article 34" - "MSR penalties Article 41" - "Regulation (EU) 2019/1020" - "Article 4" - "Article 6" - "market surveillance authorities" - "ICSMS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Market Surveillance Regulation requirements A practical requirements breakdown for Regulation (EU) 2019/1020 covering Article 4 EU economic-operator tasks, Article 6 distance-sales targeting. *Requirements* *EU* ## EU Market Surveillance Regulation (EU) 2019/1020 Requirements What you must be able to do when authorities check your products. Focus: evidence readiness (DoC/technical documentation), online targeting, investigations, and corrective action. The EU Market Surveillance Regulation (Regulation (EU) 2019/1020, "MSR") is best implemented as an operational readiness program. It affects what authorities check (online and offline), what evidence you must produce, how cross-border investigations work, and how quickly you must execute corrective actions. The highest-impact requirements for most companies are: (1) Article 4 economic operator tasks (documentation verification, ability to produce technical documentation, cooperation and corrective action), (2) Article 6 distance sales targeting logic for ecommerce, and (3) authority checks, data-sharing and serious-risk workflows (Articles 11, 19-20, 34, 41). ## 1) Article 6 turns online targeting into EU market access MSR treats online and other distance-sales offers as products made available on the EU market when the offer is targeted at EU end users. In practice, storefront configuration is part of compliance, not just marketing. The operational question is not where your company sits. It is whether the offer is directed at EU users and therefore triggers the enforcement framework. - Document targeting signals such as EU shipping, EU languages, EU currencies, EU domain strategy, and EU-directed marketing. - Block listings that do not have the required declaration, operator identification, or evidence index behind them. - Treat marketplace and DTC storefront changes as compliance changes, not just commercial changes. ## 2) Article 4 requires an EU-based operator setup for listed product laws For products covered by the legislation listed in Article 4(5), a product may be placed on the market only if there is an EU-established economic operator responsible for the Article 4(3) tasks. That role can sit with the EU manufacturer, importer, authorised representative with written mandate, or in some cases a fulfilment-service provider. The tasks are concrete: keep the declaration available, ensure technical documentation can be supplied, cooperate with authorities, notify risk when you have reason to believe one exists, and ensure corrective action is taken. - Show the operator name and contact details, including postal address, on the product, packaging, parcel, or an accompanying document under Article 4(4). - Build an evidence-retrieval workflow that can package conformity documentation in a language the authority can easily understand. - Wire the operator role into the recall, withdrawal, listing-removal, and customer-communication process. ## 3) Articles 11 and 14 define the real enforcement power set Article 11 establishes risk-based checks. Article 14 sets the minimum powers Member States must give market-surveillance authorities. Together, they define what authorities can actually do when they investigate. This matters because many teams prepare only a document response, while the Regulation also allows site inspections, undercover sampling, access to embedded software where necessary, and online-interface measures. - Authorities can require documents, technical specifications, data, and information, including access to embedded software where necessary to assess compliance. - Authorities can require supply-chain and distribution-network information, conduct unannounced inspections, enter premises, and start investigations on their own initiative. - Where no other effective means are available to eliminate a serious risk, authorities can require removal of content from an online interface, explicit warnings, or restricted access through information-society service providers. ## 4) Articles 25 to 28 connect customs and market surveillance MSR is not only about products already circulating in the market. It also creates a customs-control workflow for products entering the Union market. This is the layer that catches missing documentation, missing Article 4 identification, false or misleading CE marking, and broader compliance concerns before release for free circulation. - Article 26 suspension triggers include missing or doubtful documentation, missing or false marking, non-identifiable Article 4 operator information, and other reasons to believe the product is non-compliant or risky. - Article 27 sets a four-working-day rule for release if the suspension is not maintained or release is approved. - Article 28 allows refusal of release, customs notices for dangerous or non-compliant products, and proportionate destruction or rendering inoperable in defined risk cases. ## 5) Article 34 makes evidence travel across the Union The Article 34 information and communication system is more than a database. It is the structured enforcement memory for authorities, single liaison offices, and customs-connected workflows. Once evidence enters the coordinated system, inconsistency across countries becomes a direct risk. - Expect information on measures, testing, corrective action, injuries, safeguard objections, and certain operator failures to be entered into the system. - Use one product-family evidence index and one version history so the same story can be told consistently across Member States. - Assume customs controls, mutual assistance, and product-market investigations can all connect through the same system. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU Market Surveillance Regulation (EU) 2019/1020 Requirements into an operational assessment Assessment Autopilot can take EU Market Surveillance Regulation (EU) 2019/1020 Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Market Surveillance Regulation (EU) 2019/1020 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Market Surveillance Regulation (EU) 2019/1020 Requirements](/solutions/assessment.md): Start from EU Market Surveillance Regulation (EU) 2019/1020 Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Market Surveillance Regulation (EU) 2019/1020](/contact.md): Review your current process, evidence gaps, and next steps for EU Market Surveillance Regulation (EU) 2019/1020 Requirements. ## Primary sources - [Regulation (EU) 2019/1020 - Articles 4, 6, 11, 14, 25 to 28, 34, 41, and 44 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj/eng?ref=sorena.io) - Primary source for channel triggers, operator tasks, authority powers, customs controls, coordinated data sharing, and penalties. - [Commission Notice 2021/C 100/01 on Article 4 implementation (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=oj:JOC_2021_100_R_0001&ref=sorena.io) - Official practical guidance on how Article 4 operator duties should work in practice. - [European Commission market surveillance for products page](https://single-market-economy.ec.europa.eu/single-market/goods/building-blocks/market-surveillance/products_en?ref=sorena.io) - Official implementation overview with current supporting materials and the 2025 Article 4 report. ## Related Topic Guides - [Authority request response playbook | EU Market Surveillance Regulation (EU) 2019/1020 | Evidence requests, corrective action](/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook.md): An operational playbook for responding to authority requests under Regulation (EU) 2019/1020: first-24-hour triage, Article 4 evidence packs. - [Enforcement powers and penalties | EU MSR (Regulation (EU) 2019/1020) | Checks, serious risk, penalties](/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties.md): A practical enforcement guide for Regulation (EU) 2019/1020 covering Article 11 risk-based checks, Article 14 authority powers. - [EU Market Surveillance Regulation applicability test | Regulation (EU) 2019/1020 scope, Article 6 distance sales](/artifacts/eu/market-surveillance-regulation/applicability-test.md): A practical applicability test for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU MSR Article 4 economic operator duties and responsible-person setup | Regulation (EU) 2019/1020](/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties.md): A practical guide to Article 4 of Regulation (EU) 2019/1020: when an EU economic operator is required, who can act, what Article 4(3) tasks they perform. - [EU MSR checklist | Regulation (EU) 2019/1020 compliance checklist for inspections](/artifacts/eu/market-surveillance-regulation/checklist.md): An audit-ready checklist for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting and distance sales (Article 6). - [EU MSR compliance program | Regulation (EU) 2019/1020 implementation guide](/artifacts/eu/market-surveillance-regulation/compliance.md): A practical implementation guide for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU MSR deadlines and compliance calendar | Regulation (EU) 2019/1020 key dates (Article 44, Article 41)](/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar.md): Key dates for Regulation (EU) 2019/1020 covering early application from 1 January 2021 for Articles 29 to 33 and 36, general application from 16 July 2021. - [EU MSR FAQ | Regulation (EU) 2019/1020 questions (Article 4, Article 6, investigations)](/artifacts/eu/market-surveillance-regulation/faq.md): Answers to common questions about the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting (Article 6). - [EU MSR penalties and fines | Article 41 penalties (Regulation (EU) 2019/1020) | Reduce exposure](/artifacts/eu/market-surveillance-regulation/penalties-and-fines.md): Penalty exposure under Regulation (EU) 2019/1020: what Article 41 requires, why penalties differ by Member State. - [Investigations and evidence requests | EU Market Surveillance Regulation (EU) 2019/1020 | What authorities check](/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests.md): A practical guide to MSR investigations under Regulation (EU) 2019/1020 covering Article 11 risk-based checks. - [Market surveillance for online marketplaces | EU MSR (Regulation (EU) 2019/1020) | Operator controls](/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces.md): A practical guide for online marketplaces under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 7(2) cooperation. - [MSR vs GPSR | Market Surveillance Regulation (EU) 2019/1020 vs General Product Safety Regulation (EU) 2023/988](/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr.md): A grounded comparison of Regulation (EU) 2019/1020 and Regulation (EU) 2023/988: MSR as the enforcement and coordination framework. - [Online sales under the EU Market Surveillance Regulation | Article 6 distance sales + ecommerce controls](/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces.md): A practical guide for ecommerce sellers under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 4 operator identification. - [What changes with EU market surveillance | Regulation (EU) 2019/1020 (MSR) practical impact](/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes.md): A practical 'what changed' guide for Regulation (EU) 2019/1020: stronger EU-wide coordination, explicit online/distance sales targeting logic (Article 6). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/market-surveillance-regulation/requirements --- --- title: "EU MSR Article 4 economic operator duties and responsible-person setup" canonical_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties" source_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties" author: "Sorena AI" description: "A practical guide to Article 4 of Regulation (EU) 2019/1020: when an EU economic operator is required, who can act, what Article 4(3) tasks they perform." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU MSR Article 4" - "Regulation (EU) 2019/1020 Article 4" - "economic operator established in the Union" - "fulfilment service provider Article 4" - "authorised representative mandate Article 4" - "market surveillance documentation request" - "technical documentation availability Article 4" - "Article 4" - "economic operator" - "authorised representative" - "fulfilment service provider" - "technical documentation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU MSR Article 4 economic operator duties and responsible-person setup A practical guide to Article 4 of Regulation (EU) 2019/1020: when an EU economic operator is required, who can act, what Article 4(3) tasks they perform. *Article 4* *EU* ## EU Market Surveillance Regulation (EU) 2019/1020 Economic operator duties (Article 4) How to set up an EU-based compliance contact and evidence workflow. Focus: who can act as the Article 4 economic operator and how to operationalise the tasks (documentation, cooperation, corrective action). Article 4 is one of the highest-impact MSR obligations for non-EU manufacturers, import-heavy portfolios, and DTC ecommerce. It is not a generic responsible-person concept. It is a specific Union-based economic-operator requirement for products covered by the legislation listed in Article 4(5), backed by duties that authorities can test in real investigations and customs holds. ## 1) When does Article 4 apply? Article 4 applies only to products covered by the Union harmonisation legislation listed in Article 4(5). The first operational step is to tag the portfolio correctly, because many businesses over-apply or under-apply the rule. The 2025 Commission implementation report confirms that scope analysis, contractual setup, and evidence access were among the main practical implementation issues in the first operating years. - Build a product-family inventory and tag which laws in Article 4(5) apply per SKU family. - Confirm whether your online offers are targeted at EU end users (Article 6) - that drives enforcement exposure. - Document the Article 4 approach per product family and make it auditable. ## 2) Who can be the Article 4 economic operator? Article 4(2) defines the eligible operator types in priority order. The correct choice depends on how you sell and where responsibilities naturally sit in your supply chain. If you are a non-EU manufacturer and there is no importer or authorised representative established in the EU, an EU fulfilment service provider can be the Article 4 operator for products it handles (Article 4(2)(d)). - EU manufacturer (Article 4(2)(a)) -> simplest if you manufacture in the EU. - Importer (Article 4(2)(b)) -> common for traditional distribution; ensure contract covers evidence SLAs. - Authorised representative (Article 4(2)(c)) -> requires written mandate; ensure capabilities to fulfil Article 4(3) tasks. - EU fulfilment service provider (Article 4(2)(d)) -> critical for DTC ecommerce; ensure they accept the role and can meet evidence delivery requirements. ## 3) What tasks must the economic operator perform (Article 4(3))? Article 4 tasks are directly operational: keep the declaration of conformity (or performance) available, ensure technical documentation can be provided on request, provide information in an easily understood language, inform authorities when there is a risk, and cooperate to ensure corrective action is taken (Article 4(3)). This is an evidence delivery system: if your technical file exists but cannot be retrieved and packaged quickly, you will fail the practical test. - Keep the declaration of conformity or declaration of performance available for the product family in scope. - Ensure technical documentation can be provided quickly, in a format and language the authority can use. - Escalate when there is reason to believe the product presents a risk, and support corrective action until it is actually carried through. - Prove the workflow with service-level targets, named owners, and a case log for authority interactions. ## 4) Labeling/packaging: make the economic operator identifiable Article 4(4) requires the economic operator's name and contact details (including postal address) to be indicated on the product, or its packaging, the parcel, or an accompanying document. Treat this as a release gate: if packaging/parcel inserts don't reliably include the information, your ecommerce channel will create systematic non-compliance. - Validate operator identification at every packaging level that may reach the customer or customs: product, packaging, parcel, and accompanying document. - Keep parcel-insert and warehouse process evidence for multi-warehouse and marketplace fulfilment models. - Make the operator details consistent across packaging, declarations, listing content, and authority-response templates. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU Market Surveillance Regulation (EU) 2019/1020 Economic operator duties (Article 4) as a cited research workflow Research Copilot can take EU Market Surveillance Regulation (EU) 2019/1020 Economic operator duties (Article 4) from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU Market Surveillance Regulation (EU) 2019/1020 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Market Surveillance Regulation (EU) 2019/1020 Economic operator duties (Article 4)](/solutions/research-copilot.md): Start from EU Market Surveillance Regulation (EU) 2019/1020 Economic operator duties (Article 4) and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Market Surveillance Regulation (EU) 2019/1020](/contact.md): Review your current process, evidence gaps, and next steps for EU Market Surveillance Regulation (EU) 2019/1020 Economic operator duties (Article 4). ## Primary sources - [Regulation (EU) 2019/1020 - Article 4 and Article 6 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj/eng?ref=sorena.io) - Primary legal text for Article 4 scope, eligible operator types, tasks, operator identification, and the online-targeting link. - [Commission Notice 2021/C 100/01 on Article 4 implementation (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=oj:JOC_2021_100_R_0001&ref=sorena.io) - Official guidance on practical implementation of Article 4 by operators and authorities. - [Report on the implementation of Article 4 of Regulation (EU) 2019/1020 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52025DC0063&ref=sorena.io) - Official 2025 report on how Article 4 worked in practice from 2021 to 2023. ## Related Topic Guides - [Authority request response playbook | EU Market Surveillance Regulation (EU) 2019/1020 | Evidence requests, corrective action](/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook.md): An operational playbook for responding to authority requests under Regulation (EU) 2019/1020: first-24-hour triage, Article 4 evidence packs. - [Enforcement powers and penalties | EU MSR (Regulation (EU) 2019/1020) | Checks, serious risk, penalties](/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties.md): A practical enforcement guide for Regulation (EU) 2019/1020 covering Article 11 risk-based checks, Article 14 authority powers. - [EU Market Surveillance Regulation applicability test | Regulation (EU) 2019/1020 scope, Article 6 distance sales](/artifacts/eu/market-surveillance-regulation/applicability-test.md): A practical applicability test for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU Market Surveillance Regulation requirements | Regulation (EU) 2019/1020 (MSR) obligations](/artifacts/eu/market-surveillance-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2019/1020 covering Article 4 EU economic-operator tasks, Article 6 distance-sales targeting. - [EU MSR checklist | Regulation (EU) 2019/1020 compliance checklist for inspections](/artifacts/eu/market-surveillance-regulation/checklist.md): An audit-ready checklist for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting and distance sales (Article 6). - [EU MSR compliance program | Regulation (EU) 2019/1020 implementation guide](/artifacts/eu/market-surveillance-regulation/compliance.md): A practical implementation guide for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU MSR deadlines and compliance calendar | Regulation (EU) 2019/1020 key dates (Article 44, Article 41)](/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar.md): Key dates for Regulation (EU) 2019/1020 covering early application from 1 January 2021 for Articles 29 to 33 and 36, general application from 16 July 2021. - [EU MSR FAQ | Regulation (EU) 2019/1020 questions (Article 4, Article 6, investigations)](/artifacts/eu/market-surveillance-regulation/faq.md): Answers to common questions about the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting (Article 6). - [EU MSR penalties and fines | Article 41 penalties (Regulation (EU) 2019/1020) | Reduce exposure](/artifacts/eu/market-surveillance-regulation/penalties-and-fines.md): Penalty exposure under Regulation (EU) 2019/1020: what Article 41 requires, why penalties differ by Member State. - [Investigations and evidence requests | EU Market Surveillance Regulation (EU) 2019/1020 | What authorities check](/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests.md): A practical guide to MSR investigations under Regulation (EU) 2019/1020 covering Article 11 risk-based checks. - [Market surveillance for online marketplaces | EU MSR (Regulation (EU) 2019/1020) | Operator controls](/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces.md): A practical guide for online marketplaces under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 7(2) cooperation. - [MSR vs GPSR | Market Surveillance Regulation (EU) 2019/1020 vs General Product Safety Regulation (EU) 2023/988](/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr.md): A grounded comparison of Regulation (EU) 2019/1020 and Regulation (EU) 2023/988: MSR as the enforcement and coordination framework. - [Online sales under the EU Market Surveillance Regulation | Article 6 distance sales + ecommerce controls](/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces.md): A practical guide for ecommerce sellers under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 4 operator identification. - [What changes with EU market surveillance | Regulation (EU) 2019/1020 (MSR) practical impact](/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes.md): A practical 'what changed' guide for Regulation (EU) 2019/1020: stronger EU-wide coordination, explicit online/distance sales targeting logic (Article 6). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties --- --- title: "What changes with EU market surveillance" canonical_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes" source_url: "https://www.sorena.io/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes" author: "Sorena AI" description: "A practical 'what changed' guide for Regulation (EU) 2019/1020: stronger EU-wide coordination, explicit online/distance sales targeting logic (Article 6)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "what changed market surveillance regulation" - "Regulation (EU) 2019/1020 changes" - "EU market surveillance online sales" - "MSR Article 4 economic operator changes" - "MSR Article 6 distance sales changes" - "MSR Article 34 ICSMS changes" - "Regulation (EU) 2019/1020" - "online sales" - "economic operators" - "investigations" - "evidence workflows" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # What changes with EU market surveillance A practical 'what changed' guide for Regulation (EU) 2019/1020: stronger EU-wide coordination, explicit online/distance sales targeting logic (Article 6). *Impact* *EU* ## EU Market Surveillance Regulation (EU) 2019/1020 What changes operationally How MSR changes your product compliance program in practice. Focus: online enforcement, operator duties, evidence packs, and cross-border investigations. MSR changes the 'operational reality' of EU product compliance: it makes online offers a first-class enforcement channel, tightens the expectation that authorities can quickly find an EU contact responsible for key tasks for certain products (Article 4), and makes evidence packs portable across Member States. If your compliance program is still "PDFs on a shared drive", MSR will expose the gap when an authority asks for evidence and corrective action. ## 1) Online offers are explicitly in scope (Article 6) MSR defines that products offered online or via distance sales are deemed to be made available on the market when the offer is targeted at EU end users (Article 6). Practical impact: ecommerce and marketplace operations become compliance-critical functions with release gates and evidence SLAs. - Document targeting signals and align storefront settings to your intended markets. - Implement listing controls to prevent publishing non-compliant products. - Build rapid takedown and evidence preservation workflows for investigations. *Recommended next step* *Placement: after the scope or definition section* ## Use EU Market Surveillance Regulation (EU) 2019/1020 What changes operationally as a cited research workflow Research Copilot can take EU Market Surveillance Regulation (EU) 2019/1020 What changes operationally from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Market Surveillance Regulation (EU) 2019/1020 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Market Surveillance Regulation (EU) 2019/1020 What changes operationally](/solutions/research-copilot.md): Start from EU Market Surveillance Regulation (EU) 2019/1020 What changes operationally and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Market Surveillance Regulation (EU) 2019/1020](/contact.md): Review your current process, evidence gaps, and next steps for EU Market Surveillance Regulation (EU) 2019/1020 What changes operationally. ## 2) Article 4 makes 'EU contact + evidence' a hard operational requirement For products under specific harmonisation laws, Article 4 requires an EU-established economic operator responsible for documentation and cooperation tasks (Article 4). Practical impact: non-EU brands selling into the EU need a dependable operator setup (importer/authorised rep/fulfilment provider) and a real evidence delivery system. - Define who is the operator per product family and contract for technical access and evidence delivery SLAs. - Ensure packaging/parcel information makes the operator identifiable (Article 4(4)). - Build a technical documentation index that can be exported quickly for authority requests. ## 3) Investigations scale across Member States (Article 11 + Article 34) Authorities run risk-based checks (Article 11) and can reuse evidence across Member States without further formal requirements (Article 11(6)). Enforcement information is also supported by an EU information and communication system for structured data-sharing (Article 34). Practical impact: your evidence pack needs stable versioning, clear product identification, and a 'single source of truth' index - otherwise inconsistencies will surface across investigations. - Standardise evidence packs per product family (DoC/DoP, tests, technical file index, traceability). - Maintain a 'what we told authorities' register for cross-border consistency. - Operationalise CAPA: fix root causes so enforcement doesn't repeat on the same defect. ## Primary sources - [Regulation (EU) 2019/1020 - Market Surveillance Regulation (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj/eng?ref=sorena.io) - Primary source for online offers, Article 4 operator duties, coordinated enforcement, and the information system. - [European Commission market surveillance for products page](https://single-market-economy.ec.europa.eu/single-market/goods/building-blocks/market-surveillance/products_en?ref=sorena.io) - Official implementation overview and current supporting materials. ## Related Topic Guides - [Authority request response playbook | EU Market Surveillance Regulation (EU) 2019/1020 | Evidence requests, corrective action](/artifacts/eu/market-surveillance-regulation/authority-request-response-playbook.md): An operational playbook for responding to authority requests under Regulation (EU) 2019/1020: first-24-hour triage, Article 4 evidence packs. - [Enforcement powers and penalties | EU MSR (Regulation (EU) 2019/1020) | Checks, serious risk, penalties](/artifacts/eu/market-surveillance-regulation/enforcement-powers-and-penalties.md): A practical enforcement guide for Regulation (EU) 2019/1020 covering Article 11 risk-based checks, Article 14 authority powers. - [EU Market Surveillance Regulation applicability test | Regulation (EU) 2019/1020 scope, Article 6 distance sales](/artifacts/eu/market-surveillance-regulation/applicability-test.md): A practical applicability test for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU Market Surveillance Regulation requirements | Regulation (EU) 2019/1020 (MSR) obligations](/artifacts/eu/market-surveillance-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2019/1020 covering Article 4 EU economic-operator tasks, Article 6 distance-sales targeting. - [EU MSR Article 4 economic operator duties and responsible-person setup | Regulation (EU) 2019/1020](/artifacts/eu/market-surveillance-regulation/responsible-person-and-economic-operator-duties.md): A practical guide to Article 4 of Regulation (EU) 2019/1020: when an EU economic operator is required, who can act, what Article 4(3) tasks they perform. - [EU MSR checklist | Regulation (EU) 2019/1020 compliance checklist for inspections](/artifacts/eu/market-surveillance-regulation/checklist.md): An audit-ready checklist for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting and distance sales (Article 6). - [EU MSR compliance program | Regulation (EU) 2019/1020 implementation guide](/artifacts/eu/market-surveillance-regulation/compliance.md): A practical implementation guide for the EU Market Surveillance Regulation (Regulation (EU) 2019/1020). - [EU MSR deadlines and compliance calendar | Regulation (EU) 2019/1020 key dates (Article 44, Article 41)](/artifacts/eu/market-surveillance-regulation/deadlines-and-compliance-calendar.md): Key dates for Regulation (EU) 2019/1020 covering early application from 1 January 2021 for Articles 29 to 33 and 36, general application from 16 July 2021. - [EU MSR FAQ | Regulation (EU) 2019/1020 questions (Article 4, Article 6, investigations)](/artifacts/eu/market-surveillance-regulation/faq.md): Answers to common questions about the EU Market Surveillance Regulation (Regulation (EU) 2019/1020): online targeting (Article 6). - [EU MSR penalties and fines | Article 41 penalties (Regulation (EU) 2019/1020) | Reduce exposure](/artifacts/eu/market-surveillance-regulation/penalties-and-fines.md): Penalty exposure under Regulation (EU) 2019/1020: what Article 41 requires, why penalties differ by Member State. - [Investigations and evidence requests | EU Market Surveillance Regulation (EU) 2019/1020 | What authorities check](/artifacts/eu/market-surveillance-regulation/investigations-and-evidence-requests.md): A practical guide to MSR investigations under Regulation (EU) 2019/1020 covering Article 11 risk-based checks. - [Market surveillance for online marketplaces | EU MSR (Regulation (EU) 2019/1020) | Operator controls](/artifacts/eu/market-surveillance-regulation/market-surveillance-for-online-marketplaces.md): A practical guide for online marketplaces under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 7(2) cooperation. - [MSR vs GPSR | Market Surveillance Regulation (EU) 2019/1020 vs General Product Safety Regulation (EU) 2023/988](/artifacts/eu/market-surveillance-regulation/market-surveillance-regulation-vs-gpsr.md): A grounded comparison of Regulation (EU) 2019/1020 and Regulation (EU) 2023/988: MSR as the enforcement and coordination framework. - [Online sales under the EU Market Surveillance Regulation | Article 6 distance sales + ecommerce controls](/artifacts/eu/market-surveillance-regulation/online-sales-and-marketplaces.md): A practical guide for ecommerce sellers under Regulation (EU) 2019/1020: Article 6 distance-sales targeting, Article 4 operator identification. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/market-surveillance-regulation/what-market-surveillance-changes --- --- title: "Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/applicability-test" author: "Sorena AI" description: "A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "EU MDR applicability test" - "MDR scope test" - "Regulation (EU) 2017/745 in scope" - "is it a medical device" - "MDR device definition" - "MDR intended purpose" - "Annex XVI products common specifications" - "software as a medical device MDR" - "MDR Rule 11 software classification" - "economic operator role MDR manufacturer importer distributor authorised representative" - "MDR conformity assessment route" - "CE marking medical devices" - "EU MDR" - "Regulation (EU) 2017/745" - "Applicability Test" - "Scope" - "Classification" - "EUDAMED" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Applicability Test A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions. *Applicability* *EU* ## EU Medical Device Regulation (MDR) Applicability Test Decide scope, role, and the next compliance workstream - with defensible reasoning. Output: a scope memo + classification hypothesis + conformity route shortlist + evidence plan (technical file, clinical evaluation, PMS, UDI/EUDAMED). Most MDR failures start with a weak scope decision: unclear intended purpose, confusing wellness vs medical claims, or missing the difference between medical device software and software that only supports an administrative process. This page gives you a practical, reviewable decision sequence you can run per product family and keep as a living scope memo in your technical documentation. ## Before you start: capture the minimum facts (so your scope decision survives review) A defensible MDR applicability decision depends on stable product facts. If you can't answer these, pause and collect the data before you contact a notified body or draft a clinical evaluation. Output: a one-page scope memo per product family (not per SKU). - Intended purpose and claims: what you say the product does (label, IFU, marketing, UI, sales collateral). - User + use environment: patient vs professional, clinical setting vs home, intended population and contraindications. - Mode of action: physical, mechanical, thermal, electromagnetic, software logic, decision support, monitoring/measurement. - What the product is: hardware, software (standalone or embedded), accessory, system/procedure pack, kit, combination product. - Supply chain reality: who places on the market under their name/trademark; who imports/distributes; who changes/relables. ## Step 1 - Does the intended purpose fit the MDR medical device definition? MDR scope hinges on intended purpose: prevention, diagnosis, monitoring, prediction/prognosis, treatment or alleviation of disease/injury/disability; investigation/replacement/modification of anatomy or a physiological process/state; or control/support of conception. Control: your scope memo should quote your intended purpose statement verbatim and map each claim to a clinical benefit and a risk control. - If you rely on wellness positioning, check every claim, UI string, and output label for diagnosis/monitoring language. - If the product influences clinical decisions (including algorithmic recommendations), define the decision context and harm scenario. - If you are an accessory, your intended purpose must support a medical device, and you still have MDR obligations. ## Step 2 - Borderline and exclusion checks (don't assume you're in scope) Borderline classification is common for apps, wearable platforms, laboratory workflow tools, and products with mixed consumer/clinical claims. Treat borderline analysis as a required artifact, not a debate. Control: include an exclusions checked subsection with 1-2 sentence rationales, and keep it updated when claims change. - Software: differentiate medical device software from software that only stores/transmits data without medical purpose. - Combination/dual-use: if you claim both consumer and medical use, MDR obligations follow the medical intended purpose. - Accessories and systems: check whether you're composing a system/procedure pack or integrating third-party devices. ## Step 3 - Annex XVI check: products without an intended medical purpose can still be in scope The MDR also covers certain product groups without an intended medical purpose (Annex XVI) when common specifications apply. This is where many consumer products get surprised by MDR-like duties. Control: if you match Annex XVI, record which group you match and which common specifications you will use. - If you sell cosmetic-style products in an Annex XVI group, plan risk management and (where required) clinical evaluation for safety. - Use the implementing regulation on common specifications to drive evidence expectations and labeling language. - Treat Annex XVI like MDR obligations with a different purpose statement and build the same operational capability. ## Step 4 - Identify your role (manufacturer vs importer vs distributor vs authorised representative) MDR obligations depend heavily on your role. Many teams discover too late that relabeling, translation, repackaging, or software updates can shift responsibilities. Control: include an economic operator map in your scope memo (legal entity, responsibilities, and handoffs). - Manufacturer obligations are the broadest: QMS, technical documentation, clinical evaluation, PMS, vigilance, UDI/EUDAMED. - Importers and distributors have specific verification duties (e.g., CE marking, DoC availability, storage/transport conditions). - Authorised representatives carry defined obligations; align contracts and change-control with your QMS. ## Step 5 - Classification hypothesis (Annex VIII): this drives cost, timelines, and notified body involvement Once you believe you are in scope, create a classification hypothesis and test it. Classification drives the conformity assessment route and evidence depth. Control: write a classification memo that cites the rules you used and the device characteristics that trigger them. - For software, pay special attention to MDR Rule 11 and MDCG guidance on qualification/classification of software. - For invasiveness and duration of contact, map device characteristics clearly and consistently across labeling, IFU, and clinical evaluation. - If your classification drives notified body involvement, plan lead times and application readiness early. ## Step 6 - Decide the next path: conformity assessment + evidence chain Applicability is not the end - it determines the workstream. Your next steps should be a route decision (Annex IX/X/XI), a technical file index (Annex II/III), and an evidence plan (clinical evaluation + PMS). Control: keep the route decision and evidence plan as living documents; update them when design, claims, or intended purpose changes. - Start with the MDR checklist and turn it into owners, evidence, and acceptance criteria. - Build technical documentation structure early; it reduces rework and speeds notified body interactions. - Operationalise PMS/vigilance and UDI/EUDAMED as product operations, not as paperwork at the end *Recommended next step* *Placement: after the applicability result* ## Turn EU Medical Device Regulation (MDR) Applicability Test into an operational assessment Assessment Autopilot can take EU Medical Device Regulation (MDR) Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Medical Device Regulation (MDR) Applicability Test](/solutions/assessment.md): Start from EU Medical Device Regulation (MDR) Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Medical Device Regulation (MDR)](/contact.md): Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) Applicability Test. ## Primary sources - [Regulation (EU) 2017/745 - Medical Device Regulation (MDR) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Primary legal text for scope/definitions, economic operators, classification framework, conformity assessment, technical documentation, clinical evaluation, PMS/vigilance, UDI and EUDAMED. - [Commission Implementing Regulation (EU) 2022/2346 - Common specifications for Annex XVI products (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_impl/2022/2346/oj?ref=sorena.io) - Common specifications for product groups without an intended medical purpose listed in MDR Annex XVI. - [MDCG 2019-11 rev.1 - Qualification and classification of software (MDR/IVDR) (European Commission)](https://health.ec.europa.eu/document/download/b45335c5-1679-4c71-a91c-fc7a4d37f12b%5Fen?filename=mdcg%5F2019%5F11%5Fen.pdf&ref=sorena.io) - High-signal guidance for deciding whether software is a medical device and for applying classification rules (including Rule 11 patterns and examples). - [MDCG 2021-24 - Guidance on classification of medical devices (European Commission)](https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en/document/download/cbb19821-a517-4e13-bf87-fdc6ddd1782e%5Fen?filename=mdcg%5F2021-24%5Fen.pdf&ref=sorena.io) - Practical guidance and examples for applying MDR Annex VIII classification rules. - [Blue Guide 2022 - Commission Notice 2022/C 247/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0628%2804%29&ref=sorena.io) - Guidance on intended purpose, placing/making available on the market, multi-legislation products, and compliance concepts. ## Related Topic Guides - [CER Template | EU Medical Device Regulation (MDR) 2017/745 | Clinical Evaluation Report Structure (Annex XIV)](/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template.md): A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV. - [Clinical Evaluation Overview | EU Medical Device Regulation (MDR) 2017/745 | CER, Clinical Evidence Strategy, PMCF](/artifacts/eu/medical-device-regulation/clinical-evaluation-overview.md): A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP). - [Compliance Checklist | EU Medical Device Regulation (MDR) 2017/745 | Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/checklist.md): An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl. - [Compliance Guide | EU Medical Device Regulation (MDR) 2017/745 | QMS, Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/compliance.md): A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment. - [Deadlines and Compliance Calendar | EU Medical Device Regulation (MDR) 2017/745 | Transition, Legacy Devices, EUDAMED](/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar.md): A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions. - [Device Classification Guide | EU Medical Device Regulation (MDR) 2017/745 | Annex VIII + Software Rule 11](/artifacts/eu/medical-device-regulation/device-classification-guide.md): A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration. - [FAQ | EU Medical Device Regulation (MDR) 2017/745 | Scope, Classification, Technical File, Clinical Evaluation, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/faq.md): High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file. - [MDR vs IVDR | EU Medical Device Regulation (MDR) 2017/745 vs IVDR 2017/746 | Classification, Evidence, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/mdr-vs-ivdr.md): A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches. - [Penalties and Fines | EU Medical Device Regulation (MDR) 2017/745 | Enforcement Risk + How to Reduce Exposure](/artifacts/eu/medical-device-regulation/penalties-and-fines.md): A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims. - [PMS and Vigilance | EU Medical Device Regulation (MDR) 2017/745 | PMS Plan, PSUR, Serious Incidents, FSCA](/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance.md): A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days. - [PMS Plan Template | EU Medical Device Regulation (MDR) 2017/745 | Annex III-Aligned Outline + Metrics](/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template.md): A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources. - [QMS and Technical File | EU Medical Device Regulation (MDR) 2017/745 | Annex II/III Technical Documentation + QMS Controls](/artifacts/eu/medical-device-regulation/qms-and-technical-file.md): A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability. - [Requirements | EU Medical Device Regulation (MDR) 2017/745 | Core Obligations + Evidence Outputs](/artifacts/eu/medical-device-regulation/requirements.md): A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance. - [Transition Timelines | EU Medical Device Regulation (MDR) 2017/745 | Legacy Devices, 2023/607 Extension, Significant Changes](/artifacts/eu/medical-device-regulation/transition-timelines.md): A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true. - [UDI and EUDAMED | EU Medical Device Regulation (MDR) 2017/745 | UDI-DI/PI, Basic UDI-DI, Actor Registration, Device Registration](/artifacts/eu/medical-device-regulation/udi-and-eudamed.md): A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/applicability-test --- --- title: "Compliance Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/checklist" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/checklist" author: "Sorena AI" description: "An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "EU MDR compliance checklist" - "MDR checklist" - "Regulation (EU) 2017/745 checklist" - "MDR technical documentation checklist" - "Annex II Annex III technical file checklist" - "GSPR checklist Annex I" - "MDR clinical evaluation checklist" - "MDR CER checklist" - "MDR PMS plan PSUR checklist" - "MDR vigilance checklist" - "UDI checklist MDR" - "EUDAMED registration checklist" - "notified body readiness checklist" - "CE marking medical devices checklist" - "EU MDR" - "Checklist" - "Technical documentation" - "Clinical evaluation" - "PMS" - "UDI" - "EUDAMED" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Compliance Checklist An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl. *Checklist* *EU* ## EU Medical Device Regulation (MDR) 2017/745 Compliance Checklist Turn MDR obligations into owners, evidence, and release gates. Use this checklist per device family to build an audit-ready MDR operating system (technical documentation, clinical evaluation, PMS/vigilance, UDI/EUDAMED). This MDR compliance checklist is designed for execution, not awareness. Use it to assign ownership, define evidence outputs, and create must be true release gates before placing a device on the market or shipping a software update. Treat it as a living control set that evolves with intended purpose, claims, design changes, suppliers, and post-market signals. ## How to run the checklist (so it produces audit-ready outputs) Run this checklist per device family. For each line item, record: owner, artifact link, last updated date, review/approval, and acceptance criteria. If you use a notified body route, this structure also helps you package an application that's coherent and reviewable. - Outcome-based: every item results in a concrete artifact (memo, procedure, report, registry record). - Traceable: link claims, risks, controls, tests, labeling, and PMS signals. - Release-gated: define conditions that must be met before each release, update, or market expansion. *Recommended next step* *Placement: after the checklist block* ## Turn EU Medical Device Regulation (MDR) 2017/745 Compliance Checklist into an operational assessment Assessment Autopilot can take EU Medical Device Regulation (MDR) 2017/745 Compliance Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) 2017/745 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Medical Device Regulation (MDR) 2017/745 Compliance Checklist](/solutions/assessment.md): Start from EU Medical Device Regulation (MDR) 2017/745 Compliance Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Medical Device Regulation (MDR) 2017/745](/contact.md): Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) 2017/745 Compliance Checklist. ## A. Scope, role, and classification (highest-leverage MDR decisions) Lock down the decisions that drive everything else: intended purpose, software qualification, economic operator role, and Annex VIII classification. Output: scope memo + classification memo + conformity assessment route decision. - Intended purpose statement + claim inventory (label, IFU, marketing, UI outputs). - Borderline/exclusion analysis; Annex XVI check + common specifications if applicable. - Economic operator role map (manufacturer/authorised representative/importer/distributor) and contracts. - Annex VIII classification memo (include software Rule 11 analysis where relevant). - Conformity assessment route decision (Annex IX/X/XI) + notified body engagement plan if required. ## B. QMS and governance (build a system that survives audits and change) MDR expects an operating system: documented processes, competent roles, change control, and post-market feedback loops. For software, your QMS must support frequent updates without losing traceability. Output: procedures + training + audit plan + management review inputs tied to PMS. - PRRC appointment and responsibilities (where required), including release sign-off gate. - Document control, design control, and change control (incl. software/cybersecurity changes). - Supplier controls (critical suppliers, subcontractors) and purchasing controls linked to risk. - Complaint handling and vigilance procedures with escalation paths and deadlines. - Internal audits and management review cadence based on risk and post-market signals. ## C. Technical documentation (Annex II/III) + GSPR checklist (Annex I) Technical documentation is your evidence backbone. Build an index that stays consistent across variants, accessories, and changes. Output: Annex II/III technical file + a traceable GSPR checklist (Annex I) linked to evidence. - Device description/specification, variants, accessories; intended purpose and indications/contraindications. - Design and manufacturing information (including critical processes and supplier dependencies). - GSPR checklist mapped to risk controls, V&V reports, and labeling/IFU claims. - Verification/validation evidence (bench, software, usability, performance, biocompatibility where applicable). - Labeling, IFU, packaging, and UDI carrier placement controls. ## D. Clinical evaluation and clinical evidence (Annex XIV) Clinical evaluation is the structured justification that your device is safe and performs as intended for the target population, with risks acceptable relative to benefits. Output: clinical evaluation plan + CER + PMCF plan/evaluation where required. - Clinical claims, endpoints, and state of the art baseline; acceptability thresholds and benefit-risk rationale. - Clinical data strategy: investigations, literature, real-world evidence; equivalence approach if used. - CER structure aligned to MDCG templates; update triggers and periodic review plan. - PMCF plan and evaluation report where required, with responsibilities and analysis methods. - SSCP content plan and publication workflow where applicable. ## E. Post-market surveillance (PMS) and vigilance PMS and vigilance are operational capabilities. They connect real-world signals back into design, labeling, risk management, and CAPA. Output: PMS plan, PMS report/PSUR, signal/trend reporting, and FSCA/recall readiness. - PMS plan (Annex III): data sources, KPIs, signal detection, responsibilities. - PSUR/PMS reporting cadence and review; management review inputs from PMS signals. - Vigilance reporting workflow for serious incidents and field safety corrective actions (FSCA). - Trend reporting and safety signal escalation integrated with CAPA effectiveness checks. - Post-market cybersecurity monitoring (for connected/software devices) integrated with change control. ## F. UDI and EUDAMED readiness UDI and EUDAMED impact traceability, labeling, and device data management. Plan these as operations, not as end-of-project paperwork. Output: actor registration, device/UDI records, submission and update governance, and periodic data quality checks. - UDI strategy: Basic UDI-DI, UDI-DI and UDI-PI assignment rules; labeling/packaging controls. - EUDAMED actor registration readiness (roles, delegates, identifiers). - Device/UDI database submissions and update procedures tied to design/change control. - Certificate and notified body data readiness (where applicable). - Internal audits on traceability data accuracy (label and registry and QMS). ## Primary sources - [Regulation (EU) 2017/745 - Medical Device Regulation (MDR) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Primary legal text for MDR scope, obligations, technical documentation, clinical evaluation, PMS/vigilance, and UDI/EUDAMED. - [MDCG guidance index - endorsed documents and downloads (European Commission)](https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en?ref=sorena.io) - Index page for MDCG guidance (clinical evaluation, PMS/vigilance, UDI/EUDAMED, classification and more). - [MDCG 2021-24 - Guidance on classification of medical devices (European Commission)](https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en/document/download/cbb19821-a517-4e13-bf87-fdc6ddd1782e%5Fen?filename=mdcg%5F2021-24%5Fen.pdf&ref=sorena.io) - Practical guidance and examples for applying MDR Annex VIII classification rules. ## Related Topic Guides - [Applicability Test | EU Medical Device Regulation (MDR) 2017/745 | Is it a Medical Device? Annex XVI? Software Rule 11?](/artifacts/eu/medical-device-regulation/applicability-test.md): A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions. - [CER Template | EU Medical Device Regulation (MDR) 2017/745 | Clinical Evaluation Report Structure (Annex XIV)](/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template.md): A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV. - [Clinical Evaluation Overview | EU Medical Device Regulation (MDR) 2017/745 | CER, Clinical Evidence Strategy, PMCF](/artifacts/eu/medical-device-regulation/clinical-evaluation-overview.md): A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP). - [Compliance Guide | EU Medical Device Regulation (MDR) 2017/745 | QMS, Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/compliance.md): A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment. - [Deadlines and Compliance Calendar | EU Medical Device Regulation (MDR) 2017/745 | Transition, Legacy Devices, EUDAMED](/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar.md): A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions. - [Device Classification Guide | EU Medical Device Regulation (MDR) 2017/745 | Annex VIII + Software Rule 11](/artifacts/eu/medical-device-regulation/device-classification-guide.md): A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration. - [FAQ | EU Medical Device Regulation (MDR) 2017/745 | Scope, Classification, Technical File, Clinical Evaluation, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/faq.md): High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file. - [MDR vs IVDR | EU Medical Device Regulation (MDR) 2017/745 vs IVDR 2017/746 | Classification, Evidence, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/mdr-vs-ivdr.md): A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches. - [Penalties and Fines | EU Medical Device Regulation (MDR) 2017/745 | Enforcement Risk + How to Reduce Exposure](/artifacts/eu/medical-device-regulation/penalties-and-fines.md): A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims. - [PMS and Vigilance | EU Medical Device Regulation (MDR) 2017/745 | PMS Plan, PSUR, Serious Incidents, FSCA](/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance.md): A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days. - [PMS Plan Template | EU Medical Device Regulation (MDR) 2017/745 | Annex III-Aligned Outline + Metrics](/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template.md): A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources. - [QMS and Technical File | EU Medical Device Regulation (MDR) 2017/745 | Annex II/III Technical Documentation + QMS Controls](/artifacts/eu/medical-device-regulation/qms-and-technical-file.md): A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability. - [Requirements | EU Medical Device Regulation (MDR) 2017/745 | Core Obligations + Evidence Outputs](/artifacts/eu/medical-device-regulation/requirements.md): A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance. - [Transition Timelines | EU Medical Device Regulation (MDR) 2017/745 | Legacy Devices, 2023/607 Extension, Significant Changes](/artifacts/eu/medical-device-regulation/transition-timelines.md): A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true. - [UDI and EUDAMED | EU Medical Device Regulation (MDR) 2017/745 | UDI-DI/PI, Basic UDI-DI, Actor Registration, Device Registration](/artifacts/eu/medical-device-regulation/udi-and-eudamed.md): A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/checklist --- --- title: "Clinical Evaluation Overview" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/clinical-evaluation-overview" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/clinical-evaluation-overview" author: "Sorena AI" description: "A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP)." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "MDR clinical evaluation overview" - "EU MDR clinical evidence" - "clinical evaluation plan MDR" - "CEP MDR" - "clinical evaluation report CER MDR" - "Annex XIV clinical evaluation" - "MDR clinical investigation vs clinical evaluation" - "equivalence MDR MDCG 2020-5" - "PMCF plan MDR" - "post-market clinical follow-up" - "clinical claims medical devices EU" - "EU MDR" - "Clinical evaluation" - "Clinical evidence" - "CER" - "PMCF" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Clinical Evaluation Overview A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP). *Clinical* *EU* ## EU Medical Device Regulation (MDR) 2017/745 Clinical Evaluation Overview Build a defensible clinical evidence strategy and CER. Connect clinical evaluation to intended purpose, risk management, GSPR, PMS/PMCF, and change control so updates don't break compliance. Under MDR, clinical evaluation is a lifecycle process: you justify safety and performance for the intended purpose using clinical data, you document the reasoning, and you update it when risks, claims, technology, or post-market signals change. Teams get stuck when clinical evaluation is treated as a document at the end rather than a system that drives product decisions. ## What clinical evaluation is (and what it is not) Clinical evaluation is the structured assessment of clinical data to verify that the device achieves its intended performance and that risks are acceptable relative to benefits for the target population. It is not a marketing story. It's a traceable argument that links intended purpose and claims to data quality, clinical relevance, and residual risk acceptability. - Clinical evaluation and risk management must agree: hazards, clinical risks, and residual risks must match across documents. - GSPR checklist (Annex I) should link to clinical evidence for claims and for risk/benefit justification where relevant. - If you ship software updates, your change control must include clinical impact assessment triggers. ## Step-by-step workflow you can execute A high-quality CER is the output of a repeatable workflow. Use the steps below as gates: do not write the CER until you can pass each gate. Output: clinical evaluation plan (CEP) + CER + update plan. - Define intended purpose and claims precisely (including performance claims shown in UI outputs). - Define clinical benefits, endpoints, and acceptability thresholds; document the current state of the art - Identify clinical risks and benefit-risk questions that evidence must answer. - Select clinical data sources and inclusion/exclusion criteria; plan evidence gaps and mitigations. - Appraise clinical data quality and relevance; synthesize conclusions; document limitations and residual uncertainties. ## Clinical data strategy: what counts as sufficient clinical evidence Your evidence strategy should be explicit: which data sources you rely on (and why), what you will collect post-market, and what triggers you to refresh the evaluation. Practical rule: if you can't explain why the data is representative of your device, indications, and users, it won't survive scrutiny. - Clinical investigations: highest signal, but expensive; plan early if needed. - Literature and existing clinical experience: works best when device and use context are truly comparable and claims are modest. - Real-world evidence and PMS data: necessary for lifecycle updates; treat data quality as a regulated output. - PMCF: use when residual uncertainty remains or when required by class/device type; define how PMCF closes specific evidence gaps. ## Equivalence is a strategy - but you must prove it (don't hand-wave) Equivalence is often misunderstood. If you claim equivalence, you need a structured, auditable demonstration that the comparable device truly matches your device in the relevant ways for the intended purpose and clinical claims. Control: write an equivalence dossier that is versioned and tied to change control. - Define equivalence criteria (technical, biological, clinical) and show how you meet them. - Prove access to sufficient data about the equivalent device; public info often isn't enough. - Re-run equivalence analysis when design, materials, software algorithms, or indications change. ## Common failure modes (use these as review questions) Use these questions to pre-review your CER and reduce rework with notified bodies and internal stakeholders. If you can't answer a question in one paragraph with evidence links, your CER likely needs more work. - Do the intended purpose and clinical claims match the label/IFU, UI outputs, and marketing materials exactly? - Is the clinical data appraisal method explicit and repeatable (not a vague statement that some papers were reviewed)? - Are limitations and residual uncertainties documented, with planned PMCF/PMS actions where needed? - Do risk management conclusions align with clinical conclusions (no contradictions)? - Are update triggers defined for software updates, new indications, new populations, or post-market signals? *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU Medical Device Regulation (MDR) 2017/745 Clinical Evaluation Overview as a cited research workflow Research Copilot can take EU Medical Device Regulation (MDR) 2017/745 Clinical Evaluation Overview from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) 2017/745 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Medical Device Regulation (MDR) 2017/745 Clinical Evaluation Overview](/solutions/research-copilot.md): Start from EU Medical Device Regulation (MDR) 2017/745 Clinical Evaluation Overview and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Medical Device Regulation (MDR) 2017/745](/contact.md): Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) 2017/745 Clinical Evaluation Overview. ## Primary sources - [Regulation (EU) 2017/745 - Medical Device Regulation (MDR) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Primary legal text for clinical evaluation duties, clinical investigation requirements, and Annex XIV clinical evaluation. - [MDCG 2020-5 - Guidance on clinical evaluation: equivalence (European Commission)](https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en/document/download/575a0f79-e3a0-4a96-9ce0-930576c12aa2%5Fen?filename=md%5Fmdcg%5F2020%5F5%5Fguidance%5Fclinical%5Fevaluation%5Fequivalence%5Fen.pdf&ref=sorena.io) - Practical guidance for using equivalence in clinical evaluation and what evidence is expected. - [MDCG 2020-6 - Guidance on sufficient clinical evidence for legacy devices (European Commission)](https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en/document/download/a6d29444-b5d5-4afb-8024-10be85256aa7%5Fen?filename=md%5Fmdcg%5F2020%5F6%5Fguidance%5Fsufficient%5Fclinical%5Fevidence%5Fen.pdf&ref=sorena.io) - Guidance on clinical evidence expectations and evaluation for legacy devices transitioning under MDR. - [MDCG 2020-13 - Clinical evaluation assessment report template (European Commission)](https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en/document/download/02f50abc-91db-4ad9-b137-6ffedb690716%5Fen?filename=md%5F2020-13-cea-report-template%5Fen.pdf&ref=sorena.io) - Template and expectations that help structure clinical evaluation assessment and reporting. ## Related Topic Guides - [Applicability Test | EU Medical Device Regulation (MDR) 2017/745 | Is it a Medical Device? Annex XVI? Software Rule 11?](/artifacts/eu/medical-device-regulation/applicability-test.md): A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions. - [CER Template | EU Medical Device Regulation (MDR) 2017/745 | Clinical Evaluation Report Structure (Annex XIV)](/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template.md): A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV. - [Compliance Checklist | EU Medical Device Regulation (MDR) 2017/745 | Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/checklist.md): An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl. - [Compliance Guide | EU Medical Device Regulation (MDR) 2017/745 | QMS, Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/compliance.md): A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment. - [Deadlines and Compliance Calendar | EU Medical Device Regulation (MDR) 2017/745 | Transition, Legacy Devices, EUDAMED](/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar.md): A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions. - [Device Classification Guide | EU Medical Device Regulation (MDR) 2017/745 | Annex VIII + Software Rule 11](/artifacts/eu/medical-device-regulation/device-classification-guide.md): A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration. - [FAQ | EU Medical Device Regulation (MDR) 2017/745 | Scope, Classification, Technical File, Clinical Evaluation, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/faq.md): High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file. - [MDR vs IVDR | EU Medical Device Regulation (MDR) 2017/745 vs IVDR 2017/746 | Classification, Evidence, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/mdr-vs-ivdr.md): A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches. - [Penalties and Fines | EU Medical Device Regulation (MDR) 2017/745 | Enforcement Risk + How to Reduce Exposure](/artifacts/eu/medical-device-regulation/penalties-and-fines.md): A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims. - [PMS and Vigilance | EU Medical Device Regulation (MDR) 2017/745 | PMS Plan, PSUR, Serious Incidents, FSCA](/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance.md): A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days. - [PMS Plan Template | EU Medical Device Regulation (MDR) 2017/745 | Annex III-Aligned Outline + Metrics](/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template.md): A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources. - [QMS and Technical File | EU Medical Device Regulation (MDR) 2017/745 | Annex II/III Technical Documentation + QMS Controls](/artifacts/eu/medical-device-regulation/qms-and-technical-file.md): A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability. - [Requirements | EU Medical Device Regulation (MDR) 2017/745 | Core Obligations + Evidence Outputs](/artifacts/eu/medical-device-regulation/requirements.md): A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance. - [Transition Timelines | EU Medical Device Regulation (MDR) 2017/745 | Legacy Devices, 2023/607 Extension, Significant Changes](/artifacts/eu/medical-device-regulation/transition-timelines.md): A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true. - [UDI and EUDAMED | EU Medical Device Regulation (MDR) 2017/745 | UDI-DI/PI, Basic UDI-DI, Actor Registration, Device Registration](/artifacts/eu/medical-device-regulation/udi-and-eudamed.md): A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/clinical-evaluation-overview --- --- title: "CER Template" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template" author: "Sorena AI" description: "A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "MDR CER template" - "clinical evaluation report template MDR" - "EU MDR clinical evaluation report structure" - "Annex XIV CER" - "clinical evaluation plan CEP" - "equivalence clinical evaluation MDR MDCG 2020-5" - "clinical evidence appraisal MDR" - "PMCF plan integration" - "notified body CER expectations" - "EU MDR" - "CER" - "Clinical evaluation" - "Clinical evidence" - "PMCF" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CER Template A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV. *Template* *EU* ## EU Medical Device Regulation (MDR) 2017/745 CER Template Write a Clinical Evaluation Report you can defend. This template focuses on traceability: claims to evidence to appraisal to conclusions to PMS/PMCF updates. A good CER is not long - it is reviewable. The fastest CERs to approve are structured, explicit about methods, and link each clinical claim to specific data and appraisal outcomes. Use this template as a copy-ready outline and as a review checklist before internal sign-off or notified body submission. ## How to use this CER template (quick rules that prevent rework) Write one CER per device family and intended purpose (not per marketing page). Keep a CER change log and tie it to change control and PMS signals. If you rely on equivalence, create a separate equivalence dossier and reference it consistently from the CER. - Keep methods explicit: search strategy, appraisal criteria, and synthesis logic must be repeatable. - Use traceability tables: claims and hazards and clinical endpoints and evidence sources and conclusions. - Document limitations and residual uncertainties, and tie them to PMCF/PMS actions. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Medical Device Regulation (MDR) 2017/745 CER Template in one governed evidence system SSOT can take EU Medical Device Regulation (MDR) 2017/745 CER Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) 2017/745 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Medical Device Regulation (MDR) 2017/745 CER Template](/solutions/ssot.md): Start from EU Medical Device Regulation (MDR) 2017/745 CER Template and keep documents, evidence, and control records in one governed system. - [Talk through EU Medical Device Regulation (MDR) 2017/745](/contact.md): Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) 2017/745 CER Template. ## CER structure (copy-ready outline) Use the headings below as your CER backbone. Add annexes for evidence tables and appraisal worksheets to keep the main CER readable. Goal: a reviewer can answer what is the claim, what is the evidence, and why is it sufficient without hunting. - 1) Administrative: device family, UDI/BUDI identifiers (where available), versions, authors/reviewers, approvals, change log. - 2) Device + intended purpose: indications, contraindications, user groups, use environment, variants/accessories, essential performance. - 3) Clinical claims and endpoints: what you claim, how it will be measured, and acceptability thresholds. - 4) State of the art: current clinical practice and alternatives; baseline risks/benefits and expected performance. - 5) Clinical evaluation plan summary: data sources, search strategy, inclusion/exclusion criteria, appraisal method, and synthesis approach. - 6) Clinical data identification: literature search results, clinical investigations, registries, PMS data, complaints and serious incidents. - 7) Appraisal: quality and relevance assessment per data source; bias and limitations; comparability to your device and indications. - 8) Analysis and conclusions: performance and safety conclusions per claim and per risk; benefit-risk rationale; residual risks. - 9) Equivalence (if used): criteria, evidence, data access justification, and why equivalence remains valid after changes. - 10) Residual uncertainty + PMCF/PMS updates: what's unknown, how you will monitor, update triggers, and reporting cadence. - 11) References and annexes: appraisal worksheets, evidence tables, device changes history, mapping to GSPR checklist. ## CER quality checklist (use as an internal review gate) Use these questions as acceptance criteria before you approve a CER. If the answer is it depends the CER should contain the missing reasoning and evidence links. Practical tip: reviewers should be able to trace each clinical claim to at least one primary evidence summary and a clear appraisal outcome. - Do intended purpose and claims match the label/IFU, marketing, and UI outputs exactly? - Is the clinical literature search strategy defined (databases, terms, dates, inclusion/exclusion) and repeatable? - Are appraisal criteria explicit and applied consistently (not a vague statement that only the best papers were selected)? - Are conclusions tied to endpoints and acceptability thresholds (not vague appears-safe statements)? - Do CER conclusions match risk management conclusions and GSPR evidence links (no contradictions)? - Are residual uncertainties documented with PMCF/PMS actions and time-bound update triggers? - If equivalence is used: is access to comparable device data demonstrated and is change impact addressed? ## Primary sources - [Regulation (EU) 2017/745 - Medical Device Regulation (MDR) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Primary legal text for clinical evaluation obligations and Annex XIV clinical evaluation requirements. - [MDCG 2020-13 - Clinical evaluation assessment report template (European Commission)](https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en/document/download/02f50abc-91db-4ad9-b137-6ffedb690716%5Fen?filename=md%5F2020-13-cea-report-template%5Fen.pdf&ref=sorena.io) - Template that helps structure clinical evaluation assessment and reporting. - [MDCG 2020-5 - Guidance on clinical evaluation: equivalence (European Commission)](https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en/document/download/575a0f79-e3a0-4a96-9ce0-930576c12aa2%5Fen?filename=md%5Fmdcg%5F2020%5F5%5Fguidance%5Fclinical%5Fevaluation%5Fequivalence%5Fen.pdf&ref=sorena.io) - Guidance on using equivalence and what evidence is expected. ## Related Topic Guides - [Applicability Test | EU Medical Device Regulation (MDR) 2017/745 | Is it a Medical Device? Annex XVI? Software Rule 11?](/artifacts/eu/medical-device-regulation/applicability-test.md): A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions. - [Clinical Evaluation Overview | EU Medical Device Regulation (MDR) 2017/745 | CER, Clinical Evidence Strategy, PMCF](/artifacts/eu/medical-device-regulation/clinical-evaluation-overview.md): A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP). - [Compliance Checklist | EU Medical Device Regulation (MDR) 2017/745 | Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/checklist.md): An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl. - [Compliance Guide | EU Medical Device Regulation (MDR) 2017/745 | QMS, Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/compliance.md): A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment. - [Deadlines and Compliance Calendar | EU Medical Device Regulation (MDR) 2017/745 | Transition, Legacy Devices, EUDAMED](/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar.md): A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions. - [Device Classification Guide | EU Medical Device Regulation (MDR) 2017/745 | Annex VIII + Software Rule 11](/artifacts/eu/medical-device-regulation/device-classification-guide.md): A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration. - [FAQ | EU Medical Device Regulation (MDR) 2017/745 | Scope, Classification, Technical File, Clinical Evaluation, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/faq.md): High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file. - [MDR vs IVDR | EU Medical Device Regulation (MDR) 2017/745 vs IVDR 2017/746 | Classification, Evidence, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/mdr-vs-ivdr.md): A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches. - [Penalties and Fines | EU Medical Device Regulation (MDR) 2017/745 | Enforcement Risk + How to Reduce Exposure](/artifacts/eu/medical-device-regulation/penalties-and-fines.md): A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims. - [PMS and Vigilance | EU Medical Device Regulation (MDR) 2017/745 | PMS Plan, PSUR, Serious Incidents, FSCA](/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance.md): A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days. - [PMS Plan Template | EU Medical Device Regulation (MDR) 2017/745 | Annex III-Aligned Outline + Metrics](/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template.md): A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources. - [QMS and Technical File | EU Medical Device Regulation (MDR) 2017/745 | Annex II/III Technical Documentation + QMS Controls](/artifacts/eu/medical-device-regulation/qms-and-technical-file.md): A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability. - [Requirements | EU Medical Device Regulation (MDR) 2017/745 | Core Obligations + Evidence Outputs](/artifacts/eu/medical-device-regulation/requirements.md): A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance. - [Transition Timelines | EU Medical Device Regulation (MDR) 2017/745 | Legacy Devices, 2023/607 Extension, Significant Changes](/artifacts/eu/medical-device-regulation/transition-timelines.md): A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true. - [UDI and EUDAMED | EU Medical Device Regulation (MDR) 2017/745 | UDI-DI/PI, Basic UDI-DI, Actor Registration, Device Registration](/artifacts/eu/medical-device-regulation/udi-and-eudamed.md): A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template --- --- title: "Compliance Guide" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/compliance" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/compliance" author: "Sorena AI" description: "A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "EU MDR compliance guide" - "MDR compliance steps" - "Regulation (EU) 2017/745 compliance" - "MDR QMS requirements" - "PRRC MDR" - "MDR technical documentation Annex II Annex III" - "GSPR checklist Annex I" - "MDR clinical evaluation Annex XIV" - "MDR PMS vigilance" - "UDI EUDAMED compliance" - "notified body readiness MDR" - "CE marking medical devices EU" - "EU MDR" - "Compliance" - "Technical documentation" - "Clinical evaluation" - "PMS" - "UDI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Compliance Guide A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment. *Compliance* *EU* ## EU Medical Device Regulation (MDR) 2017/745 Compliance Build an MDR operating model you can execute and maintain. This guide focuses on high-signal decisions and audit-ready evidence outputs: scope, classification, route, technical file, clinical evidence, PMS/vigilance, and UDI/EUDAMED. MDR compliance is a lifecycle system. The fastest way to get stuck is to treat MDR as a one-time documentation project. The fastest way to move is to build an operating model where scope and classification decisions drive a route, route drives evidence, and post-market signals drive updates - with clear owners, review gates, and traceability. ## The MDR compliance system (the evidence chain you must control) Think of MDR as a connected evidence chain. If one link is missing (e.g., claims not aligned to clinical evidence, PMS not tied to CAPA, or UDI records not tied to labeling), the whole chain becomes hard to defend. Practical output: a single device compliance dossier map that lists each required artifact and where it lives. - Scope memo plus economic-operator role map to avoid mis-scoping and mis-owned obligations. - Classification memo to determine the conformity-assessment route and notified-body involvement. - Technical documentation (Annex II and III) plus GSPR checklist (Annex I) as the evidence backbone. - Clinical evaluation (Annex XIV) plus PMCF where needed to support claim justification and residual-risk acceptability. - PMS and vigilance plus the CAPA feedback loop to control the lifecycle and trigger updates. - UDI and EUDAMED procedures plus data governance to support traceability and registry correctness. *Recommended next step* *Placement: after the compliance steps* ## Turn EU Medical Device Regulation (MDR) 2017/745 Compliance into an operational assessment Assessment Autopilot can take EU Medical Device Regulation (MDR) 2017/745 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) 2017/745 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Medical Device Regulation (MDR) 2017/745 Compliance](/solutions/assessment.md): Start from EU Medical Device Regulation (MDR) 2017/745 Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Medical Device Regulation (MDR) 2017/745](/contact.md): Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) 2017/745 Compliance. ## High-signal decisions that reduce time and rework Make these decisions early and document them. Each one eliminates weeks of churn later. Operational rule: every decision should have an owner, an artifact (memo), and a change trigger. - Intended purpose and claim set (including UI outputs and decision support language). - Qualification and classification (Annex VIII; software Rule 11 if relevant). - Conformity assessment route (Annex IX/X/XI) and notified body engagement plan (if required). - Clinical evidence strategy: what claims require what evidence; equivalence strategy (if any). - PMS and vigilance model: data sources, signal detection, and escalation workflows. - UDI and EUDAMED model: actor registration roles, device/UDI record lifecycle, and data quality controls. ## 30/60/90-day plan (practical sequencing for teams that need momentum) Your exact sequence depends on class and device type, but most teams benefit from a short, execution-oriented plan that produces artifacts early. Use this as a starting point and adapt based on route and notified body needs. - Days 0-30: scope memo, role map, classification hypothesis, route shortlist, technical file index draft, gaps list. - Days 30-60: QMS procedures and change control, GSPR checklist skeleton, risk management alignment, CER plan and evidence mapping, PMS plan draft. - Days 60-90: close evidence gaps, finalize CER (or plan investigations), implement PMS/vigilance workflows, prepare UDI/EUDAMED roles and data model, run internal audit-style review. ## Notified body readiness (if you need NB involvement) If your route requires a notified body, your goal is to submit a coherent, reviewable package - not a large folder of unrelated documents. Practical output: an NB submission pack index mapping Annex requirements to your evidence artifacts. - Keep device family boundaries consistent across technical file, CER, PMS plan, and labeling. - Make change history explicit (device versions, software releases, significant changes, rationale). - Ensure traceability from GSPR to risk controls, test evidence, clinical evidence, and labeling statements. - Include PMS readiness evidence (procedures, data sources, signal management) - not just a draft plan. - Prepare reviewer shortcuts such as claim-to-evidence tables, risk summary tables, and key conclusions. ## Primary sources - [Regulation (EU) 2017/745 - Medical Device Regulation (MDR) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Primary legal text for MDR obligations, conformity assessment, technical documentation, clinical evaluation, PMS/vigilance, and UDI/EUDAMED. - [Blue Guide 2022 - Commission Notice 2022/C 247/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0628%2804%29&ref=sorena.io) - Guidance on placing products on the market, economic operators, and compliance concepts used across EU product rules. - [Manufacturers and CE marking overview (European Commission)](https://single-market-economy.ec.europa.eu/single-market/goods/ce-marking/manufacturers_en?ref=sorena.io) - General guidance on manufacturer responsibilities, technical documentation, declaration of conformity, and CE marking concepts. ## Related Topic Guides - [Applicability Test | EU Medical Device Regulation (MDR) 2017/745 | Is it a Medical Device? Annex XVI? Software Rule 11?](/artifacts/eu/medical-device-regulation/applicability-test.md): A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions. - [CER Template | EU Medical Device Regulation (MDR) 2017/745 | Clinical Evaluation Report Structure (Annex XIV)](/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template.md): A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV. - [Clinical Evaluation Overview | EU Medical Device Regulation (MDR) 2017/745 | CER, Clinical Evidence Strategy, PMCF](/artifacts/eu/medical-device-regulation/clinical-evaluation-overview.md): A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP). - [Compliance Checklist | EU Medical Device Regulation (MDR) 2017/745 | Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/checklist.md): An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl. - [Deadlines and Compliance Calendar | EU Medical Device Regulation (MDR) 2017/745 | Transition, Legacy Devices, EUDAMED](/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar.md): A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions. - [Device Classification Guide | EU Medical Device Regulation (MDR) 2017/745 | Annex VIII + Software Rule 11](/artifacts/eu/medical-device-regulation/device-classification-guide.md): A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration. - [FAQ | EU Medical Device Regulation (MDR) 2017/745 | Scope, Classification, Technical File, Clinical Evaluation, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/faq.md): High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file. - [MDR vs IVDR | EU Medical Device Regulation (MDR) 2017/745 vs IVDR 2017/746 | Classification, Evidence, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/mdr-vs-ivdr.md): A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches. - [Penalties and Fines | EU Medical Device Regulation (MDR) 2017/745 | Enforcement Risk + How to Reduce Exposure](/artifacts/eu/medical-device-regulation/penalties-and-fines.md): A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims. - [PMS and Vigilance | EU Medical Device Regulation (MDR) 2017/745 | PMS Plan, PSUR, Serious Incidents, FSCA](/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance.md): A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days. - [PMS Plan Template | EU Medical Device Regulation (MDR) 2017/745 | Annex III-Aligned Outline + Metrics](/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template.md): A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources. - [QMS and Technical File | EU Medical Device Regulation (MDR) 2017/745 | Annex II/III Technical Documentation + QMS Controls](/artifacts/eu/medical-device-regulation/qms-and-technical-file.md): A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability. - [Requirements | EU Medical Device Regulation (MDR) 2017/745 | Core Obligations + Evidence Outputs](/artifacts/eu/medical-device-regulation/requirements.md): A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance. - [Transition Timelines | EU Medical Device Regulation (MDR) 2017/745 | Legacy Devices, 2023/607 Extension, Significant Changes](/artifacts/eu/medical-device-regulation/transition-timelines.md): A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true. - [UDI and EUDAMED | EU Medical Device Regulation (MDR) 2017/745 | UDI-DI/PI, Basic UDI-DI, Actor Registration, Device Registration](/artifacts/eu/medical-device-regulation/udi-and-eudamed.md): A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/compliance --- --- title: "Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "EU MDR deadlines" - "MDR compliance calendar" - "MDR transition deadlines" - "Regulation (EU) 2017/745 transition" - "legacy devices MDR 2023/607" - "MDR transitional provisions Article 120" - "notified body application deadline 26 May 2024" - "notified body agreement 26 September 2024" - "MDR transition end 31 December 2027 31 December 2028" - "EUDAMED mandatory modules 28 May 2026" - "MDR timeline" - "EU MDR" - "Deadlines and Compliance Calendar" - "Transition" - "Legacy devices" - "EUDAMED" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Deadlines and Compliance Calendar A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions. *Deadlines* *EU* ## EU Medical Device Regulation (MDR) 2017/745 Deadlines and Compliance Calendar Turn MDR dates into deliverables, owners, and gates. Focus: Article 120 legacy-device milestones, notified body and QMS cutoffs, class III custom-made implantable timing, and the staged EUDAMED rollout. Regulatory dates don't help unless they create action. Use this page as a planning layer: map each milestone to deliverables (technical file, clinical evaluation, PMS readiness), owners, and decision points (classification changes, notified body route, legacy device transition eligibility). ## Baseline MDR timeline (anchor dates you should use in planning) These are the dates that should anchor your planning assumptions. Your device-specific calendar still depends on classification, conformity route, certificate history, and whether you are relying on Article 120 legacy-device transition. Control: keep a date-assumptions section in your compliance plan so regulatory, quality, clinical, supply-chain, and product teams use the same calendar. - 26 May 2021: MDR date of application. Use this as the baseline for default MDR obligations and for identifying legacy devices. - 20 March 2023: Regulation (EU) 2023/607 entered into force. Recheck certificate status, pending applications, and transition assumptions from this date forward. - 9 July 2024: Regulation (EU) 2024/1860 entered into force and became the legal basis for the gradual EUDAMED rollout. - 28 May 2026: the first four EUDAMED modules become mandatory to use, so actor, device, certificate, and market-surveillance data readiness should be on your live compliance calendar. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU Medical Device Regulation (MDR) 2017/745 Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take EU Medical Device Regulation (MDR) 2017/745 Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) 2017/745 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Medical Device Regulation (MDR) 2017/745 Deadlines and Compliance Calendar](/solutions/assessment.md): Start from EU Medical Device Regulation (MDR) 2017/745 Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Medical Device Regulation (MDR) 2017/745](/contact.md): Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) 2017/745 Deadlines and Compliance Calendar. ## Legacy devices and transition milestones (practical calendar items) For legacy devices, dates only matter if you can prove the Article 120 conditions behind them. Missing one condition can collapse the whole transition path. Control: maintain a legacy-device eligibility dossier with certificate history, change assessments, QMS evidence, and notified-body documents. - 26 May 2024: the manufacturer needed to have an MDR QMS in place under Article 10(9) and, where Article 120(3c)(e) applied, a formal notified-body application lodged by this date. - 26 September 2024: the written agreement with the MDR notified body had to be signed by this date, and the incoming MDR notified body becomes responsible for the appropriate surveillance at the latest by then. - 31 December 2027 or 31 December 2028: the transition end date depends on MDR Annex VIII classification logic, not simply the old directive certificate label. - 26 May 2026: special transition endpoint for class III custom-made implantable devices if the manufacturer met the 2024 application and written-agreement deadlines. - No sell-off deadline: devices lawfully placed on the market before the end of transition may continue to be made available or put into service without a fixed sell-off end date, subject to shelf-life or expiry. ## What to deliver before each milestone (use as calendar tasks) Convert each date into a named evidence package. If you cannot attach a document list, owner, and review gate to the milestone, the calendar entry is too vague. Tip: schedule an internal audit-style review before each external deadline so date pressure does not hide evidence gaps. - Article 120 eligibility pack: certificate history, lawful placing-on-the-market evidence, significant-change assessments, and legacy-device scope statement. - QMS readiness pack: Article 10(9) procedures, PRRC coverage, PMS and vigilance procedures, UDI controls, and management-review records. - Notified-body application pack: scope memo, classification memo, technical-file index, CER status, PMS-plan status, and submitted-application evidence. - Surveillance-transfer pack: written agreement, tripartite transfer arrangements where relevant, and clear responsibility mapping after 26 September 2024. - UDI and EUDAMED readiness pack: SRN records, Basic UDI-DI strategy, device-master-data controls, and label-release checks tied to submissions. ## EUDAMED milestone planning (do not leave it to the end) EUDAMED is now a staged implementation program, not a distant future system. Your planning should distinguish the first four mandatory modules from the later clinical-investigation and vigilance milestones. Control: create one EUDAMED readiness board that tracks actor registration, UDI and device data, certificate references, and the interim process for modules that are not yet mandatory. - Plan actor registration first. Manufacturers, authorised representatives, and importers need the right legal-entity mapping and SRN governance before device records can stay clean. - Prepare master data for the first four mandatory modules: Actor Registration, UDI and Device Registration, Notified Bodies and Certificates, and Market Surveillance. - Keep an interim vigilance and PSUR visibility process with the notified body until the Post-market Surveillance and Vigilance module becomes mandatory to use. - Align label artwork, Basic UDI-DI governance, and software-version controls with the UDI and device-registration process. - Train backup users and access approvers now. EUDAMED access, delegation, and correction rights are operational controls, not admin detail. ## Primary sources - [Regulation (EU) 2017/745 - Medical Device Regulation (MDR) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2017/745/oj/eng?ref=sorena.io) - Primary legal text for MDR application, Article 120 transition rules, UDI, PMS, vigilance, and EUDAMED obligations. - [Regulation (EU) 2023/607 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/607/oj/eng?ref=sorena.io) - Amending regulation that extended MDR transition periods and removed the sell-off deadline. - [Q&A rev.2 on Regulation (EU) 2023/607 (European Commission)](https://health.ec.europa.eu/document/download/592008f6-3456-4afb-a13a-733a87da1b00_en?filename=mdr_proposal_extension-q-n-a_1.pdf&ref=sorena.io) - Official Commission Q and A used to map the 26 May 2024 and 26 September 2024 conditions, class III custom-made implantable timing, and sell-off removal. - [Medical Devices - EUDAMED overview (European Commission)](https://health.ec.europa.eu/medical-devices-eudamed_en?ref=sorena.io) - Official EUDAMED page covering module status and the 28 May 2026 mandatory-use announcement for the first four modules. ## Related Topic Guides - [Applicability Test | EU Medical Device Regulation (MDR) 2017/745 | Is it a Medical Device? Annex XVI? Software Rule 11?](/artifacts/eu/medical-device-regulation/applicability-test.md): A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions. - [CER Template | EU Medical Device Regulation (MDR) 2017/745 | Clinical Evaluation Report Structure (Annex XIV)](/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template.md): A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV. - [Clinical Evaluation Overview | EU Medical Device Regulation (MDR) 2017/745 | CER, Clinical Evidence Strategy, PMCF](/artifacts/eu/medical-device-regulation/clinical-evaluation-overview.md): A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP). - [Compliance Checklist | EU Medical Device Regulation (MDR) 2017/745 | Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/checklist.md): An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl. - [Compliance Guide | EU Medical Device Regulation (MDR) 2017/745 | QMS, Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/compliance.md): A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment. - [Device Classification Guide | EU Medical Device Regulation (MDR) 2017/745 | Annex VIII + Software Rule 11](/artifacts/eu/medical-device-regulation/device-classification-guide.md): A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration. - [FAQ | EU Medical Device Regulation (MDR) 2017/745 | Scope, Classification, Technical File, Clinical Evaluation, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/faq.md): High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file. - [MDR vs IVDR | EU Medical Device Regulation (MDR) 2017/745 vs IVDR 2017/746 | Classification, Evidence, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/mdr-vs-ivdr.md): A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches. - [Penalties and Fines | EU Medical Device Regulation (MDR) 2017/745 | Enforcement Risk + How to Reduce Exposure](/artifacts/eu/medical-device-regulation/penalties-and-fines.md): A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims. - [PMS and Vigilance | EU Medical Device Regulation (MDR) 2017/745 | PMS Plan, PSUR, Serious Incidents, FSCA](/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance.md): A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days. - [PMS Plan Template | EU Medical Device Regulation (MDR) 2017/745 | Annex III-Aligned Outline + Metrics](/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template.md): A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources. - [QMS and Technical File | EU Medical Device Regulation (MDR) 2017/745 | Annex II/III Technical Documentation + QMS Controls](/artifacts/eu/medical-device-regulation/qms-and-technical-file.md): A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability. - [Requirements | EU Medical Device Regulation (MDR) 2017/745 | Core Obligations + Evidence Outputs](/artifacts/eu/medical-device-regulation/requirements.md): A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance. - [Transition Timelines | EU Medical Device Regulation (MDR) 2017/745 | Legacy Devices, 2023/607 Extension, Significant Changes](/artifacts/eu/medical-device-regulation/transition-timelines.md): A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true. - [UDI and EUDAMED | EU Medical Device Regulation (MDR) 2017/745 | UDI-DI/PI, Basic UDI-DI, Actor Registration, Device Registration](/artifacts/eu/medical-device-regulation/udi-and-eudamed.md): A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar --- --- title: "Device Classification Guide" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/device-classification-guide" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/device-classification-guide" author: "Sorena AI" description: "A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "EU MDR device classification guide" - "MDR classification Annex VIII" - "Regulation (EU) 2017/745 classification" - "MDR class I IIa IIb III" - "MDR implementing rules classification" - "software classification MDR Rule 11" - "medical device software classification MDCG 2019-11" - "classification memo template MDR" - "notified body requirement by class" - "conformity assessment route MDR" - "EU MDR" - "Device Classification Guide" - "Annex VIII" - "Rule 11" - "Software" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Device Classification Guide A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration. *Classification* *EU* ## EU Medical Device Regulation (MDR) 2017/745 Device Classification Guide Classify your device with a memo reviewers can follow. Classification drives conformity route, notified body involvement, clinical evidence depth, and PMS/PSUR obligations - so treat it as a controlled decision. Device classification under MDR Annex VIII is not a best guess - it is a reasoning chain. The fastest path to approval is a classification memo that clearly states the device characteristics, which rules apply, and why alternative rules do not apply. This page gives you a practical, repeatable classification workflow, including software Rule 11 guidance. ## Start with a classification memo (the artifact that prevents churn) Write one classification memo per device family and intended purpose. Keep it versioned and tie it to change control (especially for software updates or material changes). A good memo is short, explicit, and cites the exact Annex VIII implementing rules and classification rules used. - Device facts: intended purpose, users, use environment, anatomical site, contact duration, invasiveness, energy sources, measurement/control functions. - Classification path: implementing rule or rules used, classification rule or rules applied, resulting class, and justification for non-applied rules. - Downstream impacts: conformity assessment route, notified body involvement, clinical evidence expectations, PMS/PSUR and vigilance planning. *Recommended next step* *Placement: after the scope or definition section* ## Use EU Medical Device Regulation (MDR) 2017/745 Device Classification Guide as a cited research workflow Research Copilot can take EU Medical Device Regulation (MDR) 2017/745 Device Classification Guide from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) 2017/745 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Medical Device Regulation (MDR) 2017/745 Device Classification Guide](/solutions/research-copilot.md): Start from EU Medical Device Regulation (MDR) 2017/745 Device Classification Guide and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Medical Device Regulation (MDR) 2017/745](/contact.md): Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) 2017/745 Device Classification Guide. ## A practical Annex VIII workflow (how to apply the rules without getting lost) Annex VIII has implementing rules (how to use the rules) and classification rules (what class results). Use this sequence to keep decisions consistent across documents. Output: a classification memo that your technical file and CER can reference consistently. - 1) Confirm qualification and intended purpose (classification is meaningless if scope is wrong). - 2) Determine device type: invasive/non-invasive, active/non-active, implantable, reusable surgical instrument, measuring function, sterile supply. - 3) Decide contact duration and anatomical site; be consistent with IFU and clinical evaluation population/use scenario. - 4) Apply relevant rule families (non-invasive, invasive, active, special rules) and document why others don't apply. - 5) Re-check edge cases: accessories, systems/procedure packs, software controlling/driving devices, and decision support outputs. ## Software classification: Rule 11 and the medical device software decision Software often fails classification reviews because the intended purpose and outputs are ambiguous. Make the clinical context explicit: what decision is being influenced and what harm could occur if the output is wrong. Control: include UI screenshots and output descriptions in the classification memo and keep them aligned to claims. - Decide whether the software itself has a medical purpose (vs administrative or general wellness). - If software drives/influences a device, document the relationship and shared risk controls. - Apply Rule 11 with explicit reasoning tied to the output's impact (information used for decisions, monitoring physiological processes, etc.). - Document change impact: algorithm updates, model retraining, new inputs, and performance changes should trigger reclassification review. - Tie software classification to clinical evaluation and PMS: model drift, false positives/negatives, and post-market monitoring plans. ## Common classification pitfalls (and how to avoid them) Most classification issues are consistency issues: labeling says one thing, UI outputs imply another, and the classification memo uses a third interpretation. Use these as pre-review checks before you lock the classification. - Claims creep: marketing adds diagnosis/monitoring language that changes classification. - Duration ambiguity across transient, short-term, and long-term use not defined consistently across documents. - Accessory vs device confusion: accessories have MDR obligations and can change route and evidence depth. - Software output ambiguity: for information only disclaimers don't help if users rely on outputs clinically. - Not capturing variants: family-level differences that trigger different rules should be documented explicitly. ## Primary sources - [Regulation (EU) 2017/745 - Medical Device Regulation (MDR) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Primary legal text for MDR Annex VIII classification rules and implementing rules. - [MDCG 2021-24 - Guidance on classification of medical devices (European Commission)](https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en/document/download/cbb19821-a517-4e13-bf87-fdc6ddd1782e%5Fen?filename=mdcg%5F2021-24%5Fen.pdf&ref=sorena.io) - Practical examples for applying MDR Annex VIII classification rules. - [MDCG 2019-11 rev.1 - Qualification and classification of software (MDR/IVDR) (European Commission)](https://health.ec.europa.eu/document/download/b45335c5-1679-4c71-a91c-fc7a4d37f12b%5Fen?filename=mdcg%5F2019%5F11%5Fen.pdf&ref=sorena.io) - Guidance for qualifying and classifying software under MDR, including Rule 11 patterns and examples. ## Related Topic Guides - [Applicability Test | EU Medical Device Regulation (MDR) 2017/745 | Is it a Medical Device? Annex XVI? Software Rule 11?](/artifacts/eu/medical-device-regulation/applicability-test.md): A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions. - [CER Template | EU Medical Device Regulation (MDR) 2017/745 | Clinical Evaluation Report Structure (Annex XIV)](/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template.md): A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV. - [Clinical Evaluation Overview | EU Medical Device Regulation (MDR) 2017/745 | CER, Clinical Evidence Strategy, PMCF](/artifacts/eu/medical-device-regulation/clinical-evaluation-overview.md): A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP). - [Compliance Checklist | EU Medical Device Regulation (MDR) 2017/745 | Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/checklist.md): An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl. - [Compliance Guide | EU Medical Device Regulation (MDR) 2017/745 | QMS, Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/compliance.md): A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment. - [Deadlines and Compliance Calendar | EU Medical Device Regulation (MDR) 2017/745 | Transition, Legacy Devices, EUDAMED](/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar.md): A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions. - [FAQ | EU Medical Device Regulation (MDR) 2017/745 | Scope, Classification, Technical File, Clinical Evaluation, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/faq.md): High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file. - [MDR vs IVDR | EU Medical Device Regulation (MDR) 2017/745 vs IVDR 2017/746 | Classification, Evidence, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/mdr-vs-ivdr.md): A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches. - [Penalties and Fines | EU Medical Device Regulation (MDR) 2017/745 | Enforcement Risk + How to Reduce Exposure](/artifacts/eu/medical-device-regulation/penalties-and-fines.md): A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims. - [PMS and Vigilance | EU Medical Device Regulation (MDR) 2017/745 | PMS Plan, PSUR, Serious Incidents, FSCA](/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance.md): A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days. - [PMS Plan Template | EU Medical Device Regulation (MDR) 2017/745 | Annex III-Aligned Outline + Metrics](/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template.md): A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources. - [QMS and Technical File | EU Medical Device Regulation (MDR) 2017/745 | Annex II/III Technical Documentation + QMS Controls](/artifacts/eu/medical-device-regulation/qms-and-technical-file.md): A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability. - [Requirements | EU Medical Device Regulation (MDR) 2017/745 | Core Obligations + Evidence Outputs](/artifacts/eu/medical-device-regulation/requirements.md): A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance. - [Transition Timelines | EU Medical Device Regulation (MDR) 2017/745 | Legacy Devices, 2023/607 Extension, Significant Changes](/artifacts/eu/medical-device-regulation/transition-timelines.md): A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true. - [UDI and EUDAMED | EU Medical Device Regulation (MDR) 2017/745 | UDI-DI/PI, Basic UDI-DI, Actor Registration, Device Registration](/artifacts/eu/medical-device-regulation/udi-and-eudamed.md): A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/device-classification-guide --- --- title: "FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/faq" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/faq" author: "Sorena AI" description: "High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "EU MDR FAQ" - "MDR questions" - "Regulation (EU) 2017/745 FAQ" - "is my product a medical device EU" - "is my software a medical device MDR" - "Rule 11 MDR explained" - "do I need a notified body MDR" - "MDR technical file Annex II Annex III" - "clinical evaluation report CER MDR" - "PMCF MDR" - "PMS PSUR MDR" - "UDI EUDAMED FAQ" - "legacy devices MDR transition 2023/607" - "EU MDR" - "FAQ" - "Rule 11" - "Technical documentation" - "Clinical evaluation" - "EUDAMED" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FAQ High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file. *FAQ* *EU* ## EU Medical Device Regulation (MDR) 2017/745 FAQ Fast answers to high-signal MDR questions. Use the linked topic pages for deep dives and templates (classification memo, technical file index, CER structure, PMS plan, UDI/EUDAMED). This FAQ focuses on the questions that materially change your MDR route, cost, and timelines. For edge cases (borderline products, novel software outputs, combination products), use the Applicability test and Device classification guide pages to document a defensible memo and update it when your claims or functionality changes. ## Scope and classification These questions decide whether MDR applies and what route you follow. Write the answer into a memo, not just a meeting note. If you only do one thing, keep a versioned scope memo and classification memo. - Is my product a medical device under MDR? Start with intended purpose and claims, not the technology or the marketing category. - Is my software a medical device? If it provides information used for diagnosis, monitoring, or treatment decisions, or drives a device, treat qualification and Rule 11 seriously. - Do I need a notified body? Usually yes for class Is, Im, and Ir devices and for class IIa, IIb, and III devices. Standard class I devices often self-declare, but still need the full technical file and PMS controls. - Which class decides the legacy transition end date? Use MDR Annex VIII classification logic for the 31 December 2027 or 31 December 2028 transition end-date analysis, even if the old directive certificate shows a different class. - What is the fastest way to avoid classification churn? Keep the label, IFU, UI output, clinical claims, and classification memo aligned under change control. ## Technical documentation and QMS These questions decide how defensible the file is when a notified body or competent authority asks for proof. Treat Annex II and III documentation and the QMS as live operating assets. - What goes in the technical file? Use Annex II and III as the index: device description, design and manufacturing information, GSPR checklist, V and V evidence, labeling, PMS plan, and PMS outputs. - What is PRRC? Under Article 15, manufacturers need at least one qualified person responsible for regulatory compliance. Micro and small enterprises may keep that person permanently and continuously at their disposal rather than inside the organisation. - What changed under Article 10(9)(h)? The QMS must verify UDI assignments and ensure consistency and validity of the Article 29 registration data. - What do importers need to verify? They verify required registrations and add their own details in Article 31 scope, so do not treat importer data as optional admin work. - What changes most often fail audits? Uncontrolled claim changes, undocumented software releases, stale GSPR traceability, and PMS outputs that do not update the rest of the file. ## Clinical evaluation, PMS, vigilance, and EUDAMED These questions decide whether you can justify safety and performance after launch, not just before launch. Operational rule: if post-market findings do not visibly update risk management, CER, and registration records, the system is not mature. - What is the PSUR cadence? Class IIb and class III at least annually, class IIa at least every two years. Class I devices use a PMS report instead of a PSUR. - What are the serious-incident timelines? Article 87 uses 15 days for a general serious incident, 2 days for a serious public-health threat, and 10 days for death or unanticipated serious deterioration in a person's state of health. - How do UDI and EUDAMED work together? UDI is the identification system, while EUDAMED is the database environment for actors, devices, certificates, and later full vigilance workflows. - What changes on 28 May 2026? The first four EUDAMED modules become mandatory to use, so actor, device, and certificate data quality must be operational before then. - What about legacy devices and transition? Transition only survives while the Article 120 conditions remain true, including no significant changes and, where relevant, the 2024 application and written-agreement milestones. *Recommended next step* *Placement: after the FAQ section* ## Use EU Medical Device Regulation (MDR) 2017/745 FAQ as a cited research workflow Research Copilot can take EU Medical Device Regulation (MDR) 2017/745 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) 2017/745 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Medical Device Regulation (MDR) 2017/745 FAQ](/solutions/research-copilot.md): Start from EU Medical Device Regulation (MDR) 2017/745 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Medical Device Regulation (MDR) 2017/745](/contact.md): Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) 2017/745 FAQ. ## Primary sources - [Regulation (EU) 2017/745 - Medical Device Regulation (MDR) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Primary legal text for scope, classification framework, obligations, technical documentation, clinical evaluation, PMS/vigilance, and UDI/EUDAMED. - [MDCG guidance index - endorsed documents and downloads (European Commission)](https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en?ref=sorena.io) - Index page for MDCG guidance (classification, clinical evaluation, PMS/vigilance, UDI/EUDAMED, transition). - [Medical Devices - EUDAMED overview (European Commission)](https://health.ec.europa.eu/medical-devices-eudamed_en?ref=sorena.io) - EUDAMED overview, modules, onboarding and operational readiness information. ## Related Topic Guides - [Applicability Test | EU Medical Device Regulation (MDR) 2017/745 | Is it a Medical Device? Annex XVI? Software Rule 11?](/artifacts/eu/medical-device-regulation/applicability-test.md): A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions. - [CER Template | EU Medical Device Regulation (MDR) 2017/745 | Clinical Evaluation Report Structure (Annex XIV)](/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template.md): A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV. - [Clinical Evaluation Overview | EU Medical Device Regulation (MDR) 2017/745 | CER, Clinical Evidence Strategy, PMCF](/artifacts/eu/medical-device-regulation/clinical-evaluation-overview.md): A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP). - [Compliance Checklist | EU Medical Device Regulation (MDR) 2017/745 | Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/checklist.md): An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl. - [Compliance Guide | EU Medical Device Regulation (MDR) 2017/745 | QMS, Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/compliance.md): A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment. - [Deadlines and Compliance Calendar | EU Medical Device Regulation (MDR) 2017/745 | Transition, Legacy Devices, EUDAMED](/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar.md): A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions. - [Device Classification Guide | EU Medical Device Regulation (MDR) 2017/745 | Annex VIII + Software Rule 11](/artifacts/eu/medical-device-regulation/device-classification-guide.md): A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration. - [MDR vs IVDR | EU Medical Device Regulation (MDR) 2017/745 vs IVDR 2017/746 | Classification, Evidence, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/mdr-vs-ivdr.md): A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches. - [Penalties and Fines | EU Medical Device Regulation (MDR) 2017/745 | Enforcement Risk + How to Reduce Exposure](/artifacts/eu/medical-device-regulation/penalties-and-fines.md): A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims. - [PMS and Vigilance | EU Medical Device Regulation (MDR) 2017/745 | PMS Plan, PSUR, Serious Incidents, FSCA](/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance.md): A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days. - [PMS Plan Template | EU Medical Device Regulation (MDR) 2017/745 | Annex III-Aligned Outline + Metrics](/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template.md): A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources. - [QMS and Technical File | EU Medical Device Regulation (MDR) 2017/745 | Annex II/III Technical Documentation + QMS Controls](/artifacts/eu/medical-device-regulation/qms-and-technical-file.md): A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability. - [Requirements | EU Medical Device Regulation (MDR) 2017/745 | Core Obligations + Evidence Outputs](/artifacts/eu/medical-device-regulation/requirements.md): A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance. - [Transition Timelines | EU Medical Device Regulation (MDR) 2017/745 | Legacy Devices, 2023/607 Extension, Significant Changes](/artifacts/eu/medical-device-regulation/transition-timelines.md): A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true. - [UDI and EUDAMED | EU Medical Device Regulation (MDR) 2017/745 | UDI-DI/PI, Basic UDI-DI, Actor Registration, Device Registration](/artifacts/eu/medical-device-regulation/udi-and-eudamed.md): A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/faq --- --- title: "MDR vs IVDR" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/mdr-vs-ivdr" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/mdr-vs-ivdr" author: "Sorena AI" description: "A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "MDR vs IVDR" - "Regulation (EU) 2017/745 vs 2017/746" - "EU medical device vs IVD" - "MDR vs IVDR classification" - "IVDR class A B C D" - "performance evaluation IVDR vs clinical evaluation MDR" - "technical documentation MDR IVDR" - "notified body MDR IVDR" - "UDI EUDAMED MDR IVDR" - "software qualification MDR IVDR MDCG 2019-11" - "MDR" - "IVDR" - "Classification" - "Clinical evaluation" - "Performance evaluation" - "UDI" - "EUDAMED" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # MDR vs IVDR A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches. *Artifact Guide* *EU* ## EU MDR vs IVDR What Changes A practical comparison for mixed device portfolios. Use this to decide which regulation applies, how classification differs, and what that means for evidence and operations. MDR and IVDR share concepts (economic operators, conformity assessment, technical documentation, UDI/EUDAMED), but they diverge in scope and evidence expectations. If you build software and diagnostics workflows, the intended-purpose question becomes the single most important decision. ## Scope: when you're in MDR vs when you're in IVDR MDR covers medical devices used on or in the human body (including many software functions) for prevention/diagnosis/monitoring/treatment-related intended purposes. IVDR covers in vitro diagnostic medical devices: products intended to examine specimens derived from the human body to provide information about physiological/pathological states, congenital abnormalities, safety/compatibility with recipients, or to predict treatment responses. - If you analyze a specimen (blood, saliva, tissue) and output diagnostic information: treat IVDR as the default. - If you monitor or influence a patient directly (including software decision support): treat MDR as the default. - If your software supports both: split intended purposes and assess whether you have two regulated functions. *Recommended next step* *Placement: after the comparison section* ## Use EU MDR vs IVDR What Changes as a cited research workflow Research Copilot can take EU MDR vs IVDR What Changes from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU MDR vs IVDR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU MDR vs IVDR What Changes](/solutions/research-copilot.md): Start from EU MDR vs IVDR What Changes and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU MDR vs IVDR](/contact.md): Review your current process, evidence gaps, and next steps for EU MDR vs IVDR What Changes. ## Classification: different systems, different consequences MDR classification uses Annex VIII rules (Classes I, IIa, IIb, III). IVDR uses a separate classification approach (Classes A, B, C, D) driven by diagnostic impact and public health risk. Operational impact: classification determines the conformity assessment route and the depth of evidence expected. - MDR: use an Annex VIII classification memo (include Rule 11 for software). - IVDR: classification often increases notified body involvement compared to the old IVD Directive regime; plan capacity early. - If you ship both: build a shared classification memo template but keep rule citations regulation-specific. ## Evidence: clinical evaluation (MDR) vs performance evaluation (IVDR) The evidence story differs: MDR focuses on clinical evaluation for safety and performance in patients/users; IVDR focuses on performance evaluation (scientific validity, analytical performance, clinical performance) tied to intended diagnostic use. Practical rule: write your claims as testable endpoints and build traceability from claims, evidence, and conclusions. - MDR: clinical evaluation plan + CER; PMCF where needed; PMS/PSUR and vigilance operations. - IVDR: performance evaluation plan + report; robust analytical/clinical performance studies; PMS and vigilance adapted to diagnostic contexts. - Software in both: ensure outputs, decision context, and harm scenarios are explicit; treat model changes as change-controlled events. ## Shared operational topics (where teams can reuse systems) You can often reuse the operating system even when evidence differs. Build shared QMS primitives and adapt regulation-specific procedures where needed. - Economic operator role mapping, document control, supplier control, and change control can be shared. - UDI and EUDAMED: shared data governance and submission processes, even if device data differs. - PMS and vigilance: shared signal/CAPA workflows with regulation-specific reporting obligations. - Training and internal audits: shared cadence with regulation-specific checklists. ## Primary sources - [Regulation (EU) 2017/745 - Medical Device Regulation (MDR) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Primary legal text for MDR scope, Annex VIII classification framework, and clinical evaluation obligations. - [Regulation (EU) 2017/746 - In Vitro Diagnostic Medical Devices Regulation (IVDR) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2017/746/oj?ref=sorena.io) - Primary legal text for IVDR scope, classification framework, and performance evaluation obligations. - [MDCG 2019-11 rev.1 - Qualification and classification of software (MDR/IVDR) (European Commission)](https://health.ec.europa.eu/document/download/b45335c5-1679-4c71-a91c-fc7a4d37f12b%5Fen?filename=mdcg%5F2019%5F11%5Fen.pdf&ref=sorena.io) - Software qualification and classification guidance covering both MDR and IVDR. ## Related Topic Guides - [Applicability Test | EU Medical Device Regulation (MDR) 2017/745 | Is it a Medical Device? Annex XVI? Software Rule 11?](/artifacts/eu/medical-device-regulation/applicability-test.md): A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions. - [CER Template | EU Medical Device Regulation (MDR) 2017/745 | Clinical Evaluation Report Structure (Annex XIV)](/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template.md): A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV. - [Clinical Evaluation Overview | EU Medical Device Regulation (MDR) 2017/745 | CER, Clinical Evidence Strategy, PMCF](/artifacts/eu/medical-device-regulation/clinical-evaluation-overview.md): A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP). - [Compliance Checklist | EU Medical Device Regulation (MDR) 2017/745 | Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/checklist.md): An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl. - [Compliance Guide | EU Medical Device Regulation (MDR) 2017/745 | QMS, Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/compliance.md): A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment. - [Deadlines and Compliance Calendar | EU Medical Device Regulation (MDR) 2017/745 | Transition, Legacy Devices, EUDAMED](/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar.md): A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions. - [Device Classification Guide | EU Medical Device Regulation (MDR) 2017/745 | Annex VIII + Software Rule 11](/artifacts/eu/medical-device-regulation/device-classification-guide.md): A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration. - [FAQ | EU Medical Device Regulation (MDR) 2017/745 | Scope, Classification, Technical File, Clinical Evaluation, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/faq.md): High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file. - [Penalties and Fines | EU Medical Device Regulation (MDR) 2017/745 | Enforcement Risk + How to Reduce Exposure](/artifacts/eu/medical-device-regulation/penalties-and-fines.md): A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims. - [PMS and Vigilance | EU Medical Device Regulation (MDR) 2017/745 | PMS Plan, PSUR, Serious Incidents, FSCA](/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance.md): A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days. - [PMS Plan Template | EU Medical Device Regulation (MDR) 2017/745 | Annex III-Aligned Outline + Metrics](/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template.md): A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources. - [QMS and Technical File | EU Medical Device Regulation (MDR) 2017/745 | Annex II/III Technical Documentation + QMS Controls](/artifacts/eu/medical-device-regulation/qms-and-technical-file.md): A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability. - [Requirements | EU Medical Device Regulation (MDR) 2017/745 | Core Obligations + Evidence Outputs](/artifacts/eu/medical-device-regulation/requirements.md): A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance. - [Transition Timelines | EU Medical Device Regulation (MDR) 2017/745 | Legacy Devices, 2023/607 Extension, Significant Changes](/artifacts/eu/medical-device-regulation/transition-timelines.md): A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true. - [UDI and EUDAMED | EU Medical Device Regulation (MDR) 2017/745 | UDI-DI/PI, Basic UDI-DI, Actor Registration, Device Registration](/artifacts/eu/medical-device-regulation/udi-and-eudamed.md): A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/mdr-vs-ivdr --- --- title: "Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/penalties-and-fines" author: "Sorena AI" description: "A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "EU MDR penalties" - "MDR fines" - "MDR enforcement" - "Regulation (EU) 2017/745 sanctions" - "MDR non-compliance consequences" - "MDR recall FSCA" - "vigilance reporting failures" - "PMS PSUR non-compliance" - "technical documentation missing MDR" - "misleading claims MDR" - "UDI EUDAMED non-compliance" - "notified body certificate suspension MDR" - "EU MDR" - "Penalties and Fines" - "Enforcement" - "PMS" - "Vigilance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Penalties and Fines A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims. *Enforcement* *EU* ## EU Medical Device Regulation (MDR) 2017/745 Penalties and Fines Understand enforcement risk and reduce exposure with evidence and controls. MDR penalties are set by Member States, but common triggers and mitigation patterns are predictable. MDR is enforced through competent authorities, notified bodies (where applicable), and market surveillance tools. While the exact fines and sanctions vary by Member State, most enforcement actions follow predictable patterns: a safety signal, a documentation gap, a misleading claim, or an uncontrolled change that breaks traceability. This page focuses on what you can control: evidence readiness and governance. ## How MDR penalties work (what's predictable vs what's local) MDR requires Member States to establish rules on penalties for infringements. That means the *exact* amounts and procedures are local. What's predictable: the types of non-compliance that trigger interventions (corrective actions, restrictions, withdrawals/recalls, certificate impacts, public communications). - You're exposed when you cannot show a coherent evidence chain (claims to risks to controls to tests to clinical evidence to labeling to PMS signals). - Enforcement escalates when issues are systemic (QMS failures) or repeated (missed reporting timelines, recurring CAPA failures). - For notified body routes, certificate suspension/withdrawal risk is often the largest business impact - bigger than fines. *Recommended next step* *Placement: after the enforcement section* ## Use EU Medical Device Regulation (MDR) 2017/745 Penalties and Fines as a cited research workflow Research Copilot can take EU Medical Device Regulation (MDR) 2017/745 Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) 2017/745 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Medical Device Regulation (MDR) 2017/745 Penalties and Fines](/solutions/research-copilot.md): Start from EU Medical Device Regulation (MDR) 2017/745 Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Medical Device Regulation (MDR) 2017/745](/contact.md): Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) 2017/745 Penalties and Fines. ## Common enforcement triggers (high-signal risk drivers) These are the patterns that frequently create regulator and notified body findings. Treat them as preventative controls in your MDR program. If you want one meta-control: change control plus traceability will prevent many failures. - Misleading or inconsistent claims across marketing, IFU, and UI outputs (scope/classification and evidence mismatch). - Missing or incoherent technical documentation (Annex II/III) and weak GSPR checklist traceability (Annex I). - Clinical evaluation weaknesses: unclear endpoints, weak appraisal methods, unjustified equivalence, or outdated CER after changes. - PMS and vigilance failures: poor complaint handling, missed reporting timelines, no trend/signal detection, weak CAPA effectiveness. - Uncontrolled changes: software updates, supplier changes, materials changes, cybersecurity patches not assessed for clinical/regulatory impact. - UDI/EUDAMED data problems: labels not matching registry data, missing updates, or unclear governance for submissions. ## Practical controls that reduce exposure (what to implement and keep current) The goal is not more documents The goal is fast, credible answers when asked: what is the device, what is the claim, what evidence supports it, what are the risks, and what changed? Use this list as your minimum defensibility pack for audits and incident reviews. - Scope and classification memos (versioned) with explicit change triggers. - Technical file index with artifact links; GSPR checklist with evidence references. - CER + equivalence dossier (if used) + update triggers tied to change control and PMS signals. - PMS plan + PSUR/PMS report workflow + vigilance log + trend/signal and CAPA effectiveness records. - Change control records for design/software/supplier changes, including impact assessments and release gates. - UDI/EUDAMED procedures and data quality checks (label and registry and QMS consistency). ## Primary sources - [Regulation (EU) 2017/745 - Medical Device Regulation (MDR) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Primary legal text defining obligations, market surveillance interactions, and penalty requirements at Member State level. - [Blue Guide 2022 - Commission Notice 2022/C 247/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52022XC0628%2804%29&ref=sorena.io) - Guidance on economic operators, compliance concepts, and market surveillance patterns used across EU product rules. ## Related Topic Guides - [Applicability Test | EU Medical Device Regulation (MDR) 2017/745 | Is it a Medical Device? Annex XVI? Software Rule 11?](/artifacts/eu/medical-device-regulation/applicability-test.md): A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions. - [CER Template | EU Medical Device Regulation (MDR) 2017/745 | Clinical Evaluation Report Structure (Annex XIV)](/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template.md): A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV. - [Clinical Evaluation Overview | EU Medical Device Regulation (MDR) 2017/745 | CER, Clinical Evidence Strategy, PMCF](/artifacts/eu/medical-device-regulation/clinical-evaluation-overview.md): A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP). - [Compliance Checklist | EU Medical Device Regulation (MDR) 2017/745 | Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/checklist.md): An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl. - [Compliance Guide | EU Medical Device Regulation (MDR) 2017/745 | QMS, Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/compliance.md): A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment. - [Deadlines and Compliance Calendar | EU Medical Device Regulation (MDR) 2017/745 | Transition, Legacy Devices, EUDAMED](/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar.md): A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions. - [Device Classification Guide | EU Medical Device Regulation (MDR) 2017/745 | Annex VIII + Software Rule 11](/artifacts/eu/medical-device-regulation/device-classification-guide.md): A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration. - [FAQ | EU Medical Device Regulation (MDR) 2017/745 | Scope, Classification, Technical File, Clinical Evaluation, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/faq.md): High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file. - [MDR vs IVDR | EU Medical Device Regulation (MDR) 2017/745 vs IVDR 2017/746 | Classification, Evidence, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/mdr-vs-ivdr.md): A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches. - [PMS and Vigilance | EU Medical Device Regulation (MDR) 2017/745 | PMS Plan, PSUR, Serious Incidents, FSCA](/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance.md): A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days. - [PMS Plan Template | EU Medical Device Regulation (MDR) 2017/745 | Annex III-Aligned Outline + Metrics](/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template.md): A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources. - [QMS and Technical File | EU Medical Device Regulation (MDR) 2017/745 | Annex II/III Technical Documentation + QMS Controls](/artifacts/eu/medical-device-regulation/qms-and-technical-file.md): A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability. - [Requirements | EU Medical Device Regulation (MDR) 2017/745 | Core Obligations + Evidence Outputs](/artifacts/eu/medical-device-regulation/requirements.md): A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance. - [Transition Timelines | EU Medical Device Regulation (MDR) 2017/745 | Legacy Devices, 2023/607 Extension, Significant Changes](/artifacts/eu/medical-device-regulation/transition-timelines.md): A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true. - [UDI and EUDAMED | EU Medical Device Regulation (MDR) 2017/745 | UDI-DI/PI, Basic UDI-DI, Actor Registration, Device Registration](/artifacts/eu/medical-device-regulation/udi-and-eudamed.md): A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/penalties-and-fines --- --- title: "PMS and Vigilance" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance" author: "Sorena AI" description: "A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "EU MDR PMS" - "post-market surveillance MDR" - "PMS plan Annex III" - "PSUR MDR" - "post-market surveillance report MDR" - "vigilance reporting MDR" - "serious incident reporting MDR" - "field safety corrective action FSCA MDR" - "trend reporting MDR" - "signal detection medical devices" - "CAPA PMS integration" - "post-market clinical follow-up PMCF MDR" - "EU MDR" - "PMS" - "PSUR" - "Vigilance" - "FSCA" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # PMS and Vigilance A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days. *Post-market* *EU* ## EU Medical Device Regulation (MDR) 2017/745 PMS and Vigilance Operational workflows for lifecycle monitoring and reporting. Build PMS/vigilance as an operating capability: signal detection to CAPA to risk + clinical evaluation updates. PMS and vigilance are where MDR becomes real. They define how you detect issues, how you decide whether they are reportable, how you correct them, and how you prove that the system is working. Teams that treat PMS as a report often fail audits because they cannot show a functioning signal to action to verification loop. ## PMS vs vigilance: what is different under MDR Post-market surveillance is the continuous system for collecting and analysing device experience. Vigilance is the regulated serious-incident and field-safety response layer that sits on top of that system. Operational outcome: PMS creates the evidence base. Vigilance decides reportability, sends the report, tracks the corrective action, and closes the loop back into risk management and clinical evaluation. - PMS inputs: complaints, service reports, trend data, literature, cybersecurity findings, returned-product analysis, user feedback, and supplier signals. - PMS outputs: PMS plan, PMS report for class I devices, PSUR for class IIa, IIb, and III devices, trend-analysis records, CAPA triggers, and management-review inputs. - Vigilance outputs: reportability decisions, MIR submissions, FSCA records, field safety notices, competent-authority correspondence, and effectiveness checks. ## Build the PMS system as an Annex III workflow, not a static document Article 83 requires a live PMS system, and Annex III requires a plan that describes how the system works. Reviewers will test whether the workflow is operating, not just whether the plan exists. Control: tie each PMS data source to an owner, a review cadence, a metric, and an escalation threshold. - For class I devices, prepare a PMS report under Article 85. For class IIa, IIb, and III devices, prepare a PSUR under Article 86. - PSUR cadence matters: class IIb and class III at least annually, class IIa at least every two years, with the PSUR kept as part of the technical documentation. - For class III and implantable devices, the PSUR is submitted through the Article 92 electronic system to the notified body. For other class IIa and IIb devices, keep it available for the notified body and competent authorities on request. - Use historical PMS data where relevant for the first PSUR, especially for legacy devices moving from directive-era surveillance into MDR-style reporting. - Make PMS outputs change the file: CAPA, risk-management updates, labeling changes, CER updates, and PMCF decisions should be traceable from the same dataset. ## Vigilance workflow: serious incident, timeline, report, FSCA Vigilance failures usually come from unclear ownership or weak clocks. Build one decision log that records awareness date, reportability reasoning, submission timing, and follow-up actions. Control: use a vigilance log with timestamps and backup owners. Vacation cover is a real audit point. - Article 87 timeline for a general serious incident: immediately and no later than 15 days after the manufacturer becomes aware of the incident. - Article 87 timeline for a serious public health threat: immediately and no later than 2 days after awareness. - Article 87 timeline for death or unanticipated serious deterioration in a person's state of health: immediately and no later than 10 days after awareness. - Use the UDI and relevant device identifiers in incident and FSCA records so complaints, field actions, and registry data can be reconciled quickly. - Until the EUDAMED Post-market Surveillance and Vigilance module becomes mandatory, agree with the notified body how vigilance visibility and PSUR-related updates will be shared. ## Minimum evidence pack to keep ready Auditors and competent authorities do not expect zero issues. They expect a functioning system that can show how issues are detected, assessed, corrected, and verified. If you cannot retrieve these records quickly, fix retrieval first. Slow retrieval is usually a QMS failure, not an IT inconvenience. - PMS plan with data sources, metrics, trend thresholds, and review cadence. - PMS report or PSUR with issue date, period covered, linked CAPA and risk updates, and management-review evidence. - Vigilance log with awareness date, reportability rationale, Article 87 timeline calculation, submission proof, and FSCA effectiveness records. - UDI-linked complaint and incident records so the affected device family, variant, and packaging level can be identified quickly. - CER, PMCF, and risk-management update records that show post-market findings actually changed the evidence chain. *Recommended next step* *Placement: near the end of the main content before related guides* ## Turn EU Medical Device Regulation (MDR) 2017/745 PMS and Vigilance into an operational assessment Assessment Autopilot can take EU Medical Device Regulation (MDR) 2017/745 PMS and Vigilance from turning this guidance into an operational assessment workflow to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) 2017/745 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Medical Device Regulation (MDR) 2017/745 PMS and Vigilance](/solutions/assessment.md): Start from EU Medical Device Regulation (MDR) 2017/745 PMS and Vigilance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Medical Device Regulation (MDR) 2017/745](/contact.md): Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) 2017/745 PMS and Vigilance. ## Primary sources - [Regulation (EU) 2017/745 - Medical Device Regulation (MDR) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2017/745/oj/eng?ref=sorena.io) - Primary legal text for Articles 83 to 89, Annex III PMS requirements, and Article 87 reporting timelines. - [MDCG 2022-21 - Guidance on PSUR according to Regulation (EU) 2017/745 (European Commission)](https://health.ec.europa.eu/document/download/3151c6e3-efec-44b6-8f7c-52ac44d18b65_en?filename=mdcg_2022-21_en.pdf&ref=sorena.io) - Operational PSUR guidance covering scope, cadence, grouping, leading device logic, and legacy-device handling. - [MDCG 2023-3 Rev.2 - Questions and answers on vigilance terms and concepts (European Commission)](https://health.ec.europa.eu/document/download/0cb3d036-ae6a-42b1-99bb-c670f8229f0c_en?filename=mdcg_2023-3_en.pdf&ref=sorena.io) - Current vigilance Q and A used for awareness-date logic, Article 87 timing, interim EUDAMED handling, and operational decision rules. - [MDCG 2020-7 - PMCF plan template (European Commission)](https://health.ec.europa.eu/document/download/a5cdb303-c782-4010-8723-7d389af678f7_en?filename=md_mdcg_2020_7_guidance_pmcf_plan_template_en.pdf&ref=sorena.io) - PMCF template used where PMS outputs need to drive additional clinical follow-up. ## Related Topic Guides - [Applicability Test | EU Medical Device Regulation (MDR) 2017/745 | Is it a Medical Device? Annex XVI? Software Rule 11?](/artifacts/eu/medical-device-regulation/applicability-test.md): A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions. - [CER Template | EU Medical Device Regulation (MDR) 2017/745 | Clinical Evaluation Report Structure (Annex XIV)](/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template.md): A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV. - [Clinical Evaluation Overview | EU Medical Device Regulation (MDR) 2017/745 | CER, Clinical Evidence Strategy, PMCF](/artifacts/eu/medical-device-regulation/clinical-evaluation-overview.md): A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP). - [Compliance Checklist | EU Medical Device Regulation (MDR) 2017/745 | Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/checklist.md): An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl. - [Compliance Guide | EU Medical Device Regulation (MDR) 2017/745 | QMS, Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/compliance.md): A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment. - [Deadlines and Compliance Calendar | EU Medical Device Regulation (MDR) 2017/745 | Transition, Legacy Devices, EUDAMED](/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar.md): A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions. - [Device Classification Guide | EU Medical Device Regulation (MDR) 2017/745 | Annex VIII + Software Rule 11](/artifacts/eu/medical-device-regulation/device-classification-guide.md): A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration. - [FAQ | EU Medical Device Regulation (MDR) 2017/745 | Scope, Classification, Technical File, Clinical Evaluation, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/faq.md): High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file. - [MDR vs IVDR | EU Medical Device Regulation (MDR) 2017/745 vs IVDR 2017/746 | Classification, Evidence, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/mdr-vs-ivdr.md): A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches. - [Penalties and Fines | EU Medical Device Regulation (MDR) 2017/745 | Enforcement Risk + How to Reduce Exposure](/artifacts/eu/medical-device-regulation/penalties-and-fines.md): A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims. - [PMS Plan Template | EU Medical Device Regulation (MDR) 2017/745 | Annex III-Aligned Outline + Metrics](/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template.md): A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources. - [QMS and Technical File | EU Medical Device Regulation (MDR) 2017/745 | Annex II/III Technical Documentation + QMS Controls](/artifacts/eu/medical-device-regulation/qms-and-technical-file.md): A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability. - [Requirements | EU Medical Device Regulation (MDR) 2017/745 | Core Obligations + Evidence Outputs](/artifacts/eu/medical-device-regulation/requirements.md): A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance. - [Transition Timelines | EU Medical Device Regulation (MDR) 2017/745 | Legacy Devices, 2023/607 Extension, Significant Changes](/artifacts/eu/medical-device-regulation/transition-timelines.md): A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true. - [UDI and EUDAMED | EU Medical Device Regulation (MDR) 2017/745 | UDI-DI/PI, Basic UDI-DI, Actor Registration, Device Registration](/artifacts/eu/medical-device-regulation/udi-and-eudamed.md): A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance --- --- title: "PMS Plan Template" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template" author: "Sorena AI" description: "A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "EU MDR PMS plan template" - "post-market surveillance plan template MDR" - "Annex III PMS plan" - "PSUR template MDR" - "PMS report template MDR" - "signal detection medical devices" - "complaint handling vigilance interface" - "trend reporting MDR" - "CAPA PMS integration" - "PMCF integration" - "post-market surveillance metrics KPIs" - "EU MDR" - "PMS plan" - "Annex III" - "PSUR" - "Vigilance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # PMS Plan Template A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources. *Template* *EU* ## EU Medical Device Regulation (MDR) 2017/745 PMS Plan Template Build a PMS plan you can execute (not just file). This outline focuses on operational details: data sources, owners, thresholds, actions, and report outputs. A PMS plan only helps if it describes a working system. Use this template as a copy-ready outline and fill it with specifics: who collects what data, how signals are detected, what thresholds trigger CAPA or vigilance actions, and how outputs (PMS report/PSUR) are produced and reviewed. ## PMS plan template (Annex III-aligned structure) Use this structure for one device family and intended purpose. Keep a change log and link updates to change control and PMS signals. Tip: put detailed evidence tables (data source definitions, KPIs, thresholds) in annexes so the main PMS plan stays readable. - 1) Scope: device family, intended purpose, variants/accessories, markets, user groups, use environments. - 2) PMS objectives: what safety/performance questions you must answer post-market; residual uncertainties from CER and risk management. - 3) PMS data sources: complaints, service, returns, user feedback, registries, literature monitoring, supplier data, cybersecurity inputs (if relevant). - 4) Data collection and quality: definitions, coding, de-duplication, minimum fields, privacy/data governance constraints. - 5) Signal detection and trending: thresholds, statistical methods (where appropriate), review cadence, escalation criteria. - 6) Analysis and actions: CAPA triggers, risk management updates, labeling/IFU updates, clinical evaluation updates, design changes. - 7) Vigilance interface: reportability decision workflow, serious incident handling, FSCA and field safety notice workflows. - 8) Reporting outputs: PMS report/PSUR responsibilities, cadence, and management review inputs. - 9) Roles and responsibilities: owners, deputies, review boards, escalation pathways, and training requirements. - 10) Effectiveness checks and audits: how you test the PMS system and track CAPA effectiveness. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Medical Device Regulation (MDR) 2017/745 PMS Plan Template in one governed evidence system SSOT can take EU Medical Device Regulation (MDR) 2017/745 PMS Plan Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) 2017/745 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Medical Device Regulation (MDR) 2017/745 PMS Plan Template](/solutions/ssot.md): Start from EU Medical Device Regulation (MDR) 2017/745 PMS Plan Template and keep documents, evidence, and control records in one governed system. - [Talk through EU Medical Device Regulation (MDR) 2017/745](/contact.md): Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) 2017/745 PMS Plan Template. ## Metrics and KPIs (examples that are actually usable) Pick metrics you can collect reliably. A smaller set of high-quality indicators beats a long list of noisy metrics. Control: define thresholds and the required action for each threshold (not just the metric). - Complaint rate per 1,000 uses/units and by failure mode; severity distribution and time-to-resolution. - Serious incident assessment turnaround time; vigilance submission timeliness; FSCA execution time and effectiveness rate. - Trend signals: increasing frequency of a specific harm scenario or near-miss; software anomaly rates where clinically relevant. - CAPA effectiveness: recurrence rate after corrective action; verification/validation completion time for fixes. - Data quality: missing-field rate in complaint records; linkage rate from complaints to UDI/device variant. ## Minimum artifacts to attach (your audit-ready PMS pack) Auditors look for records that prove the system is running. Attach or link to these artifacts and keep them current. If you can't retrieve them quickly, build retrieval first. - PMS plan (this document) + change log and approval history. - Complaint handling SOP + coding taxonomy and training records. - Signal/trend log + meeting minutes for review boards and escalations. - Vigilance log + reportability decisions + FSCA records and effectiveness checks. - PSUR/PMS report outputs + management review records + CAPA effectiveness evidence. ## Primary sources - [Regulation (EU) 2017/745 - Medical Device Regulation (MDR) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2017/745/oj?ref=sorena.io) - Primary legal text for PMS system requirements and Annex III PMS plan/report obligations. - [MDCG 2020-7 - PMCF plan template (European Commission)](https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en/document/download/a5cdb303-c782-4010-8723-7d389af678f7%5Fen?filename=md%5Fmdcg%5F2020%5F7%5Fguidance%5Fpmcf%5Fplan%5Ftemplate%5Fen.pdf&ref=sorena.io) - Useful template when PMS plan integrates PMCF as a clinical evidence workstream. ## Related Topic Guides - [Applicability Test | EU Medical Device Regulation (MDR) 2017/745 | Is it a Medical Device? Annex XVI? Software Rule 11?](/artifacts/eu/medical-device-regulation/applicability-test.md): A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions. - [CER Template | EU Medical Device Regulation (MDR) 2017/745 | Clinical Evaluation Report Structure (Annex XIV)](/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template.md): A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV. - [Clinical Evaluation Overview | EU Medical Device Regulation (MDR) 2017/745 | CER, Clinical Evidence Strategy, PMCF](/artifacts/eu/medical-device-regulation/clinical-evaluation-overview.md): A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP). - [Compliance Checklist | EU Medical Device Regulation (MDR) 2017/745 | Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/checklist.md): An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl. - [Compliance Guide | EU Medical Device Regulation (MDR) 2017/745 | QMS, Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/compliance.md): A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment. - [Deadlines and Compliance Calendar | EU Medical Device Regulation (MDR) 2017/745 | Transition, Legacy Devices, EUDAMED](/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar.md): A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions. - [Device Classification Guide | EU Medical Device Regulation (MDR) 2017/745 | Annex VIII + Software Rule 11](/artifacts/eu/medical-device-regulation/device-classification-guide.md): A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration. - [FAQ | EU Medical Device Regulation (MDR) 2017/745 | Scope, Classification, Technical File, Clinical Evaluation, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/faq.md): High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file. - [MDR vs IVDR | EU Medical Device Regulation (MDR) 2017/745 vs IVDR 2017/746 | Classification, Evidence, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/mdr-vs-ivdr.md): A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches. - [Penalties and Fines | EU Medical Device Regulation (MDR) 2017/745 | Enforcement Risk + How to Reduce Exposure](/artifacts/eu/medical-device-regulation/penalties-and-fines.md): A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims. - [PMS and Vigilance | EU Medical Device Regulation (MDR) 2017/745 | PMS Plan, PSUR, Serious Incidents, FSCA](/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance.md): A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days. - [QMS and Technical File | EU Medical Device Regulation (MDR) 2017/745 | Annex II/III Technical Documentation + QMS Controls](/artifacts/eu/medical-device-regulation/qms-and-technical-file.md): A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability. - [Requirements | EU Medical Device Regulation (MDR) 2017/745 | Core Obligations + Evidence Outputs](/artifacts/eu/medical-device-regulation/requirements.md): A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance. - [Transition Timelines | EU Medical Device Regulation (MDR) 2017/745 | Legacy Devices, 2023/607 Extension, Significant Changes](/artifacts/eu/medical-device-regulation/transition-timelines.md): A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true. - [UDI and EUDAMED | EU Medical Device Regulation (MDR) 2017/745 | UDI-DI/PI, Basic UDI-DI, Actor Registration, Device Registration](/artifacts/eu/medical-device-regulation/udi-and-eudamed.md): A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template --- --- title: "QMS and Technical File" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/qms-and-technical-file" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/qms-and-technical-file" author: "Sorena AI" description: "A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "EU MDR QMS" - "MDR quality management system requirements" - "MDR technical file" - "MDR technical documentation Annex II Annex III" - "GSPR checklist Annex I" - "technical file structure medical devices EU" - "MDR change control" - "software updates MDR" - "audit-ready technical documentation" - "notified body technical file expectations" - "EU MDR" - "QMS" - "Technical documentation" - "Annex II" - "Annex III" - "GSPR" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # QMS and Technical File A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability. *QMS* *EU* ## EU Medical Device Regulation (MDR) 2017/745 QMS and Technical File Build a technical file you can maintain through change. Focus: Annex II/III structure, GSPR traceability, and QMS controls that keep evidence coherent (especially for software updates). Under MDR, the technical file is not just a folder - it is the output of your QMS. The fastest way to reduce audit pain is to design a technical file index that matches Annex II/III and to build QMS processes (document control, change control, supplier control, PMS/vigilance) that continuously update the evidence chain. ## QMS controls that matter most under MDR You do not need a huge procedure library. You need a QMS that keeps the evidence chain coherent across design, clinical, post-market, labeling, and registration work. Control: every process should have an owner, required records, review cadence, and a retrieval path that works during an audit. - Article 10 manufacturer controls: document control, design and change control, supplier control, complaint handling, CAPA, internal audits, management review, and technical-documentation maintenance. - Article 15 PRRC coverage: name the responsible person, define release and escalation touchpoints, and keep expertise evidence current. Micro and small enterprises still need permanent and continuous access to a qualified PRRC. - UDI governance inside the QMS: Article 10(9)(h) requires verification of UDI assignments and consistency of Article 29 information. - PMS and vigilance integration: complaints, trend signals, serious incidents, and FSCA actions should feed CAPA, risk management, CER updates, and label changes. - Legacy-device transition control: significant-change assessments, application records, written agreements, and surveillance-transfer files should sit inside the QMS, not outside it. ## Annex II and III technical documentation: build an index before filling it A stable Annex II and III index reduces rework and makes reviews faster. The file should tell a consistent story even when the device changes over time. Output: a technical-file table of contents with document IDs, owner, approval status, and links to the current evidence record. - Annex II device description and specification, including intended purpose, variants, accessories, and family logic such as Basic UDI-DI. - Annex II design and manufacturing information, including critical suppliers, outsourced processes, and software build or deployment dependencies. - Annex II GSPR checklist with explicit evidence links to tests, risk controls, clinical evidence, labeling, usability, and cybersecurity material where relevant. - Annex II verification and validation set: bench, biocompatibility, software V and V, performance, usability, sterilisation, packaging, and shelf-life evidence as applicable. - Annex III PMS file: PMS plan, PMS report or PSUR, vigilance interfaces, CAPA linkage, and change records showing post-market feedback into the file. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Medical Device Regulation (MDR) 2017/745 QMS and Technical File in one governed evidence system SSOT can take EU Medical Device Regulation (MDR) 2017/745 QMS and Technical File from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) 2017/745 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Medical Device Regulation (MDR) 2017/745 QMS and Technical File](/solutions/ssot.md): Start from EU Medical Device Regulation (MDR) 2017/745 QMS and Technical File and keep documents, evidence, and control records in one governed system. - [Talk through EU Medical Device Regulation (MDR) 2017/745](/contact.md): Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) 2017/745 QMS and Technical File. ## GSPR checklist: make it the traceability backbone A strong GSPR checklist is the fastest way for a reviewer to understand whether the file is coherent. It should act as a map, not a text dump. Control: each GSPR row should show the requirement, the design control, the verification evidence, the residual risk treatment, and the linked labeling statement where relevant. - Map each released claim to the GSPR row and to the exact evidence that supports it. - Show where residual risks are communicated, including IFU warnings, training, contraindications, and device limitations. - Tie CER conclusions and PMCF decisions back into the GSPR rows that depend on clinical evidence. - Keep supplier and software changes visible so the checklist does not drift away from the current design. - Check UDI, label, and EUDAMED data consistency as part of the same release gate. ## Software and frequent updates: add a regulated release dossier Software devices and connected devices fail audits when releases are treated like routine engineering pushes rather than regulated changes. Build one repeatable release dossier for every production update. Control: no release closes until the release dossier shows what changed, why it was acceptable, and which downstream records were updated. - Define release gates for verification, validation, cybersecurity review, clinical-impact assessment, risk update, label and IFU review, and UDI or registration impact. - Keep version history tied to CER updates, risk-management updates, PMS findings, and the registered device identity. - For algorithmic software, record new inputs, model retraining, changed automation, new user populations, and changed output claims as explicit review items. - Control third-party software components with supplier notifications, vulnerability notices, patch timelines, and deployment verification. - Archive screenshots, user-facing output samples, and release notes as controlled evidence because they are often what reviewers use to test intended purpose and classification. ## Primary sources - [Regulation (EU) 2017/745 - Medical Device Regulation (MDR) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2017/745/oj/eng?ref=sorena.io) - Primary legal text for Article 10 manufacturer duties, Article 15 PRRC, and Annex II and III technical documentation. - [MDCG 2021-19 - UDI integration within an organisation's QMS (European Commission)](https://health.ec.europa.eu/document/download/64443e95-e1be-4ffd-80f7-9c6a1b0b99b6_en?filename=md_2021-19_en.pdf&ref=sorena.io) - Guidance for integrating UDI duties into QMS procedures, roles, and evidence handling. - [Blue Guide 2022 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52022XC0628(04)&ref=sorena.io) - Cross-cutting guidance on economic operators, compliance concepts, and product-rule implementation. ## Related Topic Guides - [Applicability Test | EU Medical Device Regulation (MDR) 2017/745 | Is it a Medical Device? Annex XVI? Software Rule 11?](/artifacts/eu/medical-device-regulation/applicability-test.md): A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions. - [CER Template | EU Medical Device Regulation (MDR) 2017/745 | Clinical Evaluation Report Structure (Annex XIV)](/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template.md): A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV. - [Clinical Evaluation Overview | EU Medical Device Regulation (MDR) 2017/745 | CER, Clinical Evidence Strategy, PMCF](/artifacts/eu/medical-device-regulation/clinical-evaluation-overview.md): A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP). - [Compliance Checklist | EU Medical Device Regulation (MDR) 2017/745 | Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/checklist.md): An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl. - [Compliance Guide | EU Medical Device Regulation (MDR) 2017/745 | QMS, Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/compliance.md): A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment. - [Deadlines and Compliance Calendar | EU Medical Device Regulation (MDR) 2017/745 | Transition, Legacy Devices, EUDAMED](/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar.md): A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions. - [Device Classification Guide | EU Medical Device Regulation (MDR) 2017/745 | Annex VIII + Software Rule 11](/artifacts/eu/medical-device-regulation/device-classification-guide.md): A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration. - [FAQ | EU Medical Device Regulation (MDR) 2017/745 | Scope, Classification, Technical File, Clinical Evaluation, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/faq.md): High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file. - [MDR vs IVDR | EU Medical Device Regulation (MDR) 2017/745 vs IVDR 2017/746 | Classification, Evidence, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/mdr-vs-ivdr.md): A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches. - [Penalties and Fines | EU Medical Device Regulation (MDR) 2017/745 | Enforcement Risk + How to Reduce Exposure](/artifacts/eu/medical-device-regulation/penalties-and-fines.md): A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims. - [PMS and Vigilance | EU Medical Device Regulation (MDR) 2017/745 | PMS Plan, PSUR, Serious Incidents, FSCA](/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance.md): A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days. - [PMS Plan Template | EU Medical Device Regulation (MDR) 2017/745 | Annex III-Aligned Outline + Metrics](/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template.md): A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources. - [Requirements | EU Medical Device Regulation (MDR) 2017/745 | Core Obligations + Evidence Outputs](/artifacts/eu/medical-device-regulation/requirements.md): A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance. - [Transition Timelines | EU Medical Device Regulation (MDR) 2017/745 | Legacy Devices, 2023/607 Extension, Significant Changes](/artifacts/eu/medical-device-regulation/transition-timelines.md): A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true. - [UDI and EUDAMED | EU Medical Device Regulation (MDR) 2017/745 | UDI-DI/PI, Basic UDI-DI, Actor Registration, Device Registration](/artifacts/eu/medical-device-regulation/udi-and-eudamed.md): A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/qms-and-technical-file --- --- title: "Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/requirements" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/requirements" author: "Sorena AI" description: "A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "EU MDR requirements" - "Regulation (EU) 2017/745 requirements" - "MDR obligations manufacturers" - "MDR requirements checklist" - "Annex II Annex III technical documentation requirements" - "GSPR Annex I requirements" - "Annex VIII classification requirements" - "Annex XIV clinical evaluation requirements" - "PMS plan Annex III requirements" - "PSUR MDR requirements" - "vigilance requirements MDR" - "UDI EUDAMED requirements MDR" - "EU MDR" - "Requirements" - "Technical documentation" - "Clinical evaluation" - "PMS" - "UDI" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Requirements A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance. *Requirements* *EU* ## EU Medical Device Regulation (MDR) 2017/745 Requirements Core obligations and the evidence you need to prove them. Use this page as a map: each requirement group links to a deeper guide or template. MDR requirements are easier to manage when you translate them into concrete outputs: memos, procedures, records, reports, and registry entries. Use the sections below as a minimum evidence map for audits, notified body reviews (where applicable), and market surveillance questions. ## 1) Scope, intended purpose, and economic-operator roles Your route starts with intended purpose and role. Scope determines whether MDR applies. Role determines which checks you perform yourself and which checks you must verify from somebody else. Evidence output: scope memo, role map, contract matrix, and borderline or Annex XVI analysis where relevant. - Define intended purpose in the label, IFU, UI outputs, and marketing so the same medical claim appears everywhere or nowhere. - Identify the role for each legal entity: manufacturer, authorised representative, importer, distributor, and where relevant system or procedure pack producer. - For software, document whether the software itself has a medical purpose, drives a device, or only supports an administrative process. - If you rely on legacy transition, remember that MDR post-market surveillance, vigilance, market-surveillance, and registration rules replace the corresponding directive rules for those legacy devices. - Keep change triggers in the scope memo: new indications, new users, new environments, new automation, new data inputs, or new claims should all force re-review. ## 2) Classification, conformity assessment, and transition route Classification drives route, lead time, and evidence depth. Transition status does not remove the need to know the current MDR class logic because some deadlines and obligations depend on it. Evidence output: Annex VIII classification memo, conformity-route memo, notified-body strategy, and where relevant an Article 120 legacy-device eligibility file. - Write an Annex VIII classification memo and make software Rule 11 reasoning explicit where relevant. - Choose the conformity-assessment route under Annex IX, X, or XI, and document why it fits the device and class. - If a notified body is required, map application readiness, review capacity, surveillance ownership, and transfer arrangements. - For legacy devices, keep the Article 120 conditions visible: continued directive compliance, no significant changes in design or intended purpose, QMS timing, and the application and written-agreement cutoffs where applicable. ## 3) QMS, PRRC, technical documentation, clinical evaluation, PMS, and UDI This is the real evidence chain. When one link is generic or stale, the rest of the file becomes hard to trust. Evidence output: Annex II and III technical file, GSPR checklist, CER, PMS report or PSUR, vigilance records, UDI and EUDAMED records, and PRRC or role-governance evidence. - Article 10 manufacturer controls: keep design and change control, supplier control, complaint handling, CAPA, internal audit, management review, and technical documentation current. - Article 15 PRRC: manufacturers need at least one person responsible for regulatory compliance with the required expertise. Micro and small enterprises may keep that person permanently and continuously at their disposal instead of inside the organisation. - Article 10(9)(h): the QMS must verify UDI assignments and ensure the consistency and validity of the information submitted under Article 29. - Article 86 and Article 87: class IIa, IIb, and III devices need PSUR on the required cadence, while serious incidents follow the 15-day, 2-day, and 10-day reporting clocks depending on the event type. - Article 29 and 31: device registration and actor registration need controlled master data, and importers must verify that required registrations were done and add their own details. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU Medical Device Regulation (MDR) 2017/745 Requirements into an operational assessment Assessment Autopilot can take EU Medical Device Regulation (MDR) 2017/745 Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) 2017/745 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Medical Device Regulation (MDR) 2017/745 Requirements](/solutions/assessment.md): Start from EU Medical Device Regulation (MDR) 2017/745 Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Medical Device Regulation (MDR) 2017/745](/contact.md): Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) 2017/745 Requirements. ## Primary sources - [Regulation (EU) 2017/745 - Medical Device Regulation (MDR) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2017/745/oj/eng?ref=sorena.io) - Primary legal text for Articles 10, 15, 27, 29, 31, 83 to 89, Annex II and III, Annex VIII, and Annex XIV. - [MDCG guidance index - endorsed documents and downloads (European Commission)](https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en?ref=sorena.io) - Index page for operational guidance on classification, clinical evaluation, vigilance, transition, UDI, and EUDAMED. ## Related Topic Guides - [Applicability Test | EU Medical Device Regulation (MDR) 2017/745 | Is it a Medical Device? Annex XVI? Software Rule 11?](/artifacts/eu/medical-device-regulation/applicability-test.md): A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions. - [CER Template | EU Medical Device Regulation (MDR) 2017/745 | Clinical Evaluation Report Structure (Annex XIV)](/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template.md): A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV. - [Clinical Evaluation Overview | EU Medical Device Regulation (MDR) 2017/745 | CER, Clinical Evidence Strategy, PMCF](/artifacts/eu/medical-device-regulation/clinical-evaluation-overview.md): A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP). - [Compliance Checklist | EU Medical Device Regulation (MDR) 2017/745 | Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/checklist.md): An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl. - [Compliance Guide | EU Medical Device Regulation (MDR) 2017/745 | QMS, Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/compliance.md): A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment. - [Deadlines and Compliance Calendar | EU Medical Device Regulation (MDR) 2017/745 | Transition, Legacy Devices, EUDAMED](/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar.md): A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions. - [Device Classification Guide | EU Medical Device Regulation (MDR) 2017/745 | Annex VIII + Software Rule 11](/artifacts/eu/medical-device-regulation/device-classification-guide.md): A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration. - [FAQ | EU Medical Device Regulation (MDR) 2017/745 | Scope, Classification, Technical File, Clinical Evaluation, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/faq.md): High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file. - [MDR vs IVDR | EU Medical Device Regulation (MDR) 2017/745 vs IVDR 2017/746 | Classification, Evidence, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/mdr-vs-ivdr.md): A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches. - [Penalties and Fines | EU Medical Device Regulation (MDR) 2017/745 | Enforcement Risk + How to Reduce Exposure](/artifacts/eu/medical-device-regulation/penalties-and-fines.md): A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims. - [PMS and Vigilance | EU Medical Device Regulation (MDR) 2017/745 | PMS Plan, PSUR, Serious Incidents, FSCA](/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance.md): A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days. - [PMS Plan Template | EU Medical Device Regulation (MDR) 2017/745 | Annex III-Aligned Outline + Metrics](/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template.md): A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources. - [QMS and Technical File | EU Medical Device Regulation (MDR) 2017/745 | Annex II/III Technical Documentation + QMS Controls](/artifacts/eu/medical-device-regulation/qms-and-technical-file.md): A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability. - [Transition Timelines | EU Medical Device Regulation (MDR) 2017/745 | Legacy Devices, 2023/607 Extension, Significant Changes](/artifacts/eu/medical-device-regulation/transition-timelines.md): A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true. - [UDI and EUDAMED | EU Medical Device Regulation (MDR) 2017/745 | UDI-DI/PI, Basic UDI-DI, Actor Registration, Device Registration](/artifacts/eu/medical-device-regulation/udi-and-eudamed.md): A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/requirements --- --- title: "Transition Timelines" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/transition-timelines" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/transition-timelines" author: "Sorena AI" description: "A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "EU MDR transition timelines" - "MDR transitional provisions" - "legacy devices MDR" - "Regulation (EU) 2023/607 MDR" - "MDR transition extension 2027 2028" - "notified body application deadline 26 May 2024" - "notified body agreement deadline 26 September 2024" - "significant changes MDR Article 120 MDCG 2020-3" - "sell-off period removed MDR" - "EU MDR" - "Transition Timelines" - "Legacy devices" - "2023/607" - "Significant changes" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Transition Timelines A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true. *Transition* *EU* ## EU Medical Device Regulation (MDR) 2017/745 Transition Timelines Legacy device transition is conditional - plan like it's a gated program. This guide focuses on Article 120 conditions, significant-change control, written-agreement and surveillance transfer mechanics, and the practical legacy-device evidence pack. Transition timelines are not just dates - they are conditions. The most common failure mode is assuming a transitional extension applies automatically. In practice, you need evidence that your device qualifies, that you met specific cut-offs (for notified body engagement where applicable), and that you avoided disqualifying changes. Use this page to turn transition rules into a timeline you can execute. ## Build a legacy-device transition dossier (the file you need when asked why the device is still moving under transition) If you rely on transition, keep one dossier that proves the device still qualifies. The core question is not whether the date exists. The core question is whether the Article 120 conditions still hold today. Control: version the dossier and require an update every time scope, design, intended purpose, notified-body status, or QMS status changes. - Certificate history and lawful placing-on-the-market evidence, including whether the device was already lawfully marketed before 22 June 2023 where that condition matters. - Directive-compliance evidence plus the statement that MDR post-market surveillance, vigilance, market-surveillance, and registration rules now replace the corresponding directive rules for legacy devices. - Significant-change assessments tied to design and intended-purpose changes, with cross-links to CER, risk management, labeling, and software-release records. - Article 10(9) QMS evidence, PRRC coverage, PMS and vigilance procedures, and proof that the QMS was in place by 26 May 2024 where Article 120(3c)(d) applied. - Formal application evidence, written agreement, and surveillance-transfer records for the notified body that became responsible by 26 September 2024. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU Medical Device Regulation (MDR) 2017/745 Transition Timelines into an operational assessment Assessment Autopilot can take EU Medical Device Regulation (MDR) 2017/745 Transition Timelines from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) 2017/745 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Medical Device Regulation (MDR) 2017/745 Transition Timelines](/solutions/assessment.md): Start from EU Medical Device Regulation (MDR) 2017/745 Transition Timelines and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Medical Device Regulation (MDR) 2017/745](/contact.md): Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) 2017/745 Transition Timelines. ## Key transition cutoffs to calendar (focus on conditions, not just dates) Transition is conditional. Strong technical documentation does not rescue a missed legal condition, and a calendar without evidence fields is not enough. Control: every transition milestone should link to the specific document set that proves the condition was met and remains met. - 20 March 2023: applications lodged before this date remain valid for Article 120(3c)(e) if they were not rejected, so do not duplicate paperwork without checking the existing file first. - 26 May 2024: the manufacturer or authorised representative needed to lodge the formal conformity-assessment application by this date where Article 120(3c)(e) applied, and the manufacturer needed the MDR QMS in place by this date under Article 120(3c)(d). - 26 September 2024: the written agreement under Annex VII section 4.3 had to be signed by this date, and the MDR notified body that signed it became responsible for the appropriate surveillance at the latest by then. - 31 December 2027 or 31 December 2028: the applicable end date depends on MDR Annex VIII classification logic, while some ongoing obligations such as PSUR may still use directive-era class logic for legacy devices. - 26 May 2026: class III custom-made implantable devices lose the special transition route after this date unless the device has already moved onto the full MDR conformity path. ## Significant changes during transition (make it a controlled decision) Significant changes can break transition eligibility. The practical answer is not to freeze the device forever. The practical answer is to make every design and intended-purpose change pass through a documented Article 120 review. Control: require a significant-change assessment before approving design changes, intended-purpose edits, claim changes, major supplier changes, or software releases. - Use MDCG 2020-3 Rev.1 as the baseline for deciding whether the change is significant, and keep the rationale inside the design-change record rather than in email threads. - Check software carefully. New data inputs, model retraining, new clinical outputs, automation changes, and changed user populations can all affect intended purpose or risk and force a deeper review. - Keep the evidence chain aligned: classification memo, CER, risk file, GSPR checklist, IFU, PMS plan, and UDI records should all reflect the same change decision. - If the manufacturer withdraws the application or the written agreement is terminated without a valid transfer to another notified body, the transition condition in Article 120(3c)(e) is no longer met. - If you transfer to another notified body, update the legacy-device transition dossier immediately so the new surveillance and agreement trail is complete. ## Primary sources - [Regulation (EU) 2017/745 - Medical Device Regulation (MDR) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2017/745/oj/eng?ref=sorena.io) - Primary legal text for Article 120, Article 10(9), and legacy-device obligations. - [Regulation (EU) 2023/607 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2023/607/oj/eng?ref=sorena.io) - Amending regulation that extended the transitional period and removed the sell-off deadline. - [Q&A rev.2 on Regulation (EU) 2023/607 (European Commission)](https://health.ec.europa.eu/document/download/592008f6-3456-4afb-a13a-733a87da1b00_en?filename=mdr_proposal_extension-q-n-a_1.pdf&ref=sorena.io) - Official Commission Q and A clarifying the 2024 application and written-agreement deadlines, QMS timing, class III custom-made implantable timing, and transfer between notified bodies. - [MDCG 2020-3 Rev.1 - Significant changes under MDR Article 120 (European Commission)](https://health.ec.europa.eu/document/download/800e8e87-d4eb-4cc5-b5ad-07a9146d7c90_en?filename=mdcg_2020-3_en_1.pdf&ref=sorena.io) - Operational guidance for deciding whether a design or intended-purpose change breaks transition eligibility. ## Related Topic Guides - [Applicability Test | EU Medical Device Regulation (MDR) 2017/745 | Is it a Medical Device? Annex XVI? Software Rule 11?](/artifacts/eu/medical-device-regulation/applicability-test.md): A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions. - [CER Template | EU Medical Device Regulation (MDR) 2017/745 | Clinical Evaluation Report Structure (Annex XIV)](/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template.md): A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV. - [Clinical Evaluation Overview | EU Medical Device Regulation (MDR) 2017/745 | CER, Clinical Evidence Strategy, PMCF](/artifacts/eu/medical-device-regulation/clinical-evaluation-overview.md): A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP). - [Compliance Checklist | EU Medical Device Regulation (MDR) 2017/745 | Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/checklist.md): An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl. - [Compliance Guide | EU Medical Device Regulation (MDR) 2017/745 | QMS, Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/compliance.md): A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment. - [Deadlines and Compliance Calendar | EU Medical Device Regulation (MDR) 2017/745 | Transition, Legacy Devices, EUDAMED](/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar.md): A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions. - [Device Classification Guide | EU Medical Device Regulation (MDR) 2017/745 | Annex VIII + Software Rule 11](/artifacts/eu/medical-device-regulation/device-classification-guide.md): A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration. - [FAQ | EU Medical Device Regulation (MDR) 2017/745 | Scope, Classification, Technical File, Clinical Evaluation, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/faq.md): High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file. - [MDR vs IVDR | EU Medical Device Regulation (MDR) 2017/745 vs IVDR 2017/746 | Classification, Evidence, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/mdr-vs-ivdr.md): A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches. - [Penalties and Fines | EU Medical Device Regulation (MDR) 2017/745 | Enforcement Risk + How to Reduce Exposure](/artifacts/eu/medical-device-regulation/penalties-and-fines.md): A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims. - [PMS and Vigilance | EU Medical Device Regulation (MDR) 2017/745 | PMS Plan, PSUR, Serious Incidents, FSCA](/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance.md): A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days. - [PMS Plan Template | EU Medical Device Regulation (MDR) 2017/745 | Annex III-Aligned Outline + Metrics](/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template.md): A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources. - [QMS and Technical File | EU Medical Device Regulation (MDR) 2017/745 | Annex II/III Technical Documentation + QMS Controls](/artifacts/eu/medical-device-regulation/qms-and-technical-file.md): A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability. - [Requirements | EU Medical Device Regulation (MDR) 2017/745 | Core Obligations + Evidence Outputs](/artifacts/eu/medical-device-regulation/requirements.md): A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance. - [UDI and EUDAMED | EU Medical Device Regulation (MDR) 2017/745 | UDI-DI/PI, Basic UDI-DI, Actor Registration, Device Registration](/artifacts/eu/medical-device-regulation/udi-and-eudamed.md): A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/transition-timelines --- --- title: "UDI and EUDAMED" canonical_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/udi-and-eudamed" source_url: "https://www.sorena.io/artifacts/eu/medical-device-regulation/udi-and-eudamed" author: "Sorena AI" description: "A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration." published_at: "2026-02-22" updated_at: "2026-02-22" keywords: - "EU MDR UDI" - "EUDAMED" - "Basic UDI-DI" - "UDI-DI UDI-PI" - "UDI carrier placement" - "direct marking UDI" - "actor registration EUDAMED SRN" - "EUDAMED device registration UDI database" - "EUDAMED modules actors devices certificates vigilance" - "UDI integration QMS" - "software UDI assignment MDCG 2018-5" - "basic UDI-DI changes MDCG 2018-1" - "EU MDR" - "UDI" - "Actor registration" - "Device registration" - "Traceability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UDI and EUDAMED A practical MDR UDI and EUDAMED guide: Basic UDI-DI, UDI-DI, UDI-PI, actor registration and SRN, Article 29 device registration. *UDI/EUDAMED* *EU* ## EU Medical Device Regulation (MDR) 2017/745 UDI and EUDAMED Traceability and registration you can operationalise. This guide focuses on execution: Basic UDI-DI strategy, SRN governance, Article 29 and 31 registration, software UDI rules, importer checks, and the 28 May 2026 mandatory-use milestone for the first four EUDAMED modules. UDI and EUDAMED touch product, ops, and compliance: label artwork, packaging, variant control, master data, and reporting workflows. Teams often fail here because UDI/EUDAMED is treated as a late-stage registration task Instead, treat it as a traceability operating system integrated into your QMS and release processes. ## UDI basics (what you must define before implementation works) UDI is a traceability system, not just a label field. The real work is deciding the device family, variant boundaries, packaging hierarchy, and change triggers that determine when identifiers must change. Control: write one UDI strategy memo per device family and keep it linked to change control, label approval, software release management, and complaint handling. - Assign a Basic UDI-DI before placing a device, other than a custom-made device, on the market. Use it as the family-level anchor for device records, certificates, declarations, PSUR grouping, and technical documentation. - Define when UDI-DI and UDI-PI change, including packaging, label, version, and software-release triggers where relevant. - Remember the scope limits: the MDR UDI system applies to devices other than custom-made and investigational devices. - For software, align UDI assignment with the released version and the actual distribution model so app-store, cloud, and on-premise releases can still be traced. - Connect UDI to complaints, vigilance, CAPA, and returned-product analysis so the same identifier set is used across the lifecycle. ## EUDAMED onboarding: Article 31 actor registration and SRN governance Actor registration is the first dependency. Manufacturers, authorised representatives, and importers in Article 31 scope need the right legal-entity setup and SRN governance before the rest of EUDAMED can stay clean. Control: create an EUDAMED roles and delegation SOP with named access approvers, backup owners, and periodic access review. - Before placing a device, other than a custom-made device, on the market, manufacturers, authorised representatives, and importers must register the required actor information and obtain the SRN. - If a notified body is required, the Article 31 information needs to be in the system before applying to that notified body. - Non-EU manufacturers need an active authorised representative and should control the mandate-summary evidence used for actor registration. - As from 28 May 2026, the Actor Registration module is mandatory to use under the gradual EUDAMED rollout. - Store SRNs in controlled master data and reuse them consistently in notified-body applications, device registration, vigilance records, and internal procedures. ## Article 29 device registration and importer verification Device registration becomes painful when the technical file, label, ERP master data, and EUDAMED entry disagree. Treat Article 29 registration as a master-data-governance process inside the QMS. Control: no new variant, label update, or software release should be approved until the registration impact has been assessed and documented. - Before placing a device, other than a custom-made device, on the market, the manufacturer must enter or verify the Article 29 device information in EUDAMED and keep it updated. - Importers have two linked checks: within two weeks of placing a device on the market they verify that the manufacturer or authorised representative provided the required device information, and they add their own details in accordance with Article 31. - Article 10(9)(h) also pulls UDI into the QMS: the manufacturer must verify UDI assignments and ensure consistency and validity of the information provided under Article 29. - As from 28 May 2026, the first four EUDAMED modules become mandatory to use, so actor, UDI and device, certificate, and market-surveillance records need production-grade data quality. - Keep an interim plan for modules that are not yet mandatory, especially where vigilance or clinical-investigation records still need parallel handling. ## Minimum evidence pack for audits and incident response The goal is fast, credible answers to basic questions: which device was placed on the market, under which identifiers, by which actor, and what changed since the last approved release. Attach links to these records in the technical documentation and the QMS procedures so retrieval does not depend on one person. - UDI strategy memo and mapping tables for Basic UDI-DI, UDI-DI, packaging levels, variants, and software releases. - Article 31 actor-registration file: SRN evidence, declaration on information-security responsibilities, mandate summary where relevant, and access-governance records. - Article 29 device-registration file: approved submission set, proof of submission, verification checks, correction log, and date-stamped change history. - Labeling and artwork approvals that prove the UDI carrier on the released label matches the registered data. - Periodic data-quality audits and CAPA records for mismatches between label, technical file, ERP or PLM, and EUDAMED. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Medical Device Regulation (MDR) 2017/745 UDI and EUDAMED in one governed evidence system SSOT can take EU Medical Device Regulation (MDR) 2017/745 UDI and EUDAMED from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Medical Device Regulation (MDR) 2017/745 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Medical Device Regulation (MDR) 2017/745 UDI and EUDAMED](/solutions/ssot.md): Start from EU Medical Device Regulation (MDR) 2017/745 UDI and EUDAMED and keep documents, evidence, and control records in one governed system. - [Talk through EU Medical Device Regulation (MDR) 2017/745](/contact.md): Review your current process, evidence gaps, and next steps for EU Medical Device Regulation (MDR) 2017/745 UDI and EUDAMED. ## Primary sources - [Regulation (EU) 2017/745 - Medical Device Regulation (MDR) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2017/745/oj/eng?ref=sorena.io) - Primary legal text for Articles 27, 29, and 31, importer verification, and UDI scope limits. - [Medical Devices - EUDAMED overview (European Commission)](https://health.ec.europa.eu/medical-devices-eudamed_en?ref=sorena.io) - Official EUDAMED page covering module status and the mandatory-use milestone for the first four modules from 28 May 2026. - [Actor registration module (European Commission)](https://health.ec.europa.eu/medical-devices-eudamed/actor-registration-module_en?ref=sorena.io) - Official actor-registration page for SRN workflow, required documents, and the Actor module mandatory-use milestone from 28 May 2026. - [Regulation (EU) 2024/1860 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1860&ref=sorena.io) - Regulation establishing the gradual EUDAMED rollout framework. - [MDCG 2018-1 Rev.4 - Basic UDI-DI and changes to UDI-DI (European Commission)](https://health.ec.europa.eu/document/download/cb1bf6e5-3972-4b3a-82d9-c5946738b2a5_en?filename=md_mdcg_2018-1_guidance_udi-di_en.pdf&ref=sorena.io) - Operational guidance on Basic UDI-DI and when UDI identifiers should change. - [MDCG 2018-5 - UDI assignment to medical device software (European Commission)](https://health.ec.europa.eu/document/download/4b5b2942-aaab-4b78-a188-df111a8d903e_en?filename=md_mdcg_2018_5_software_en.pdf&ref=sorena.io) - Guidance on UDI assignment for software devices and software releases. ## Related Topic Guides - [Applicability Test | EU Medical Device Regulation (MDR) 2017/745 | Is it a Medical Device? Annex XVI? Software Rule 11?](/artifacts/eu/medical-device-regulation/applicability-test.md): A step-by-step MDR applicability test for Regulation (EU) 2017/745: confirm intended purpose, device definition and exclusions. - [CER Template | EU Medical Device Regulation (MDR) 2017/745 | Clinical Evaluation Report Structure (Annex XIV)](/artifacts/eu/medical-device-regulation/clinical-evaluation-report-template.md): A practical Clinical Evaluation Report (CER) template for MDR (Regulation (EU) 2017/745): a copy-ready CER structure aligned to Annex XIV. - [Clinical Evaluation Overview | EU Medical Device Regulation (MDR) 2017/745 | CER, Clinical Evidence Strategy, PMCF](/artifacts/eu/medical-device-regulation/clinical-evaluation-overview.md): A practical MDR clinical evaluation overview: how to define clinical claims and intended purpose, plan the clinical evaluation (CEP). - [Compliance Checklist | EU Medical Device Regulation (MDR) 2017/745 | Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/checklist.md): An MDR compliance checklist you can run per device family: scope + role, classification and conformity assessment route, QMS controls (incl. - [Compliance Guide | EU Medical Device Regulation (MDR) 2017/745 | QMS, Technical Documentation, Clinical Evaluation, PMS, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/compliance.md): A practical EU MDR compliance guide for Regulation (EU) 2017/745: how to build an MDR operating model from scope and classification to conformity assessment. - [Deadlines and Compliance Calendar | EU Medical Device Regulation (MDR) 2017/745 | Transition, Legacy Devices, EUDAMED](/artifacts/eu/medical-device-regulation/deadlines-and-compliance-calendar.md): A practical MDR deadlines and compliance calendar: MDR application timing, Regulation (EU) 2023/607 transition conditions. - [Device Classification Guide | EU Medical Device Regulation (MDR) 2017/745 | Annex VIII + Software Rule 11](/artifacts/eu/medical-device-regulation/device-classification-guide.md): A practical MDR device classification guide for Annex VIII: how to write a classification memo, apply implementing rules, decide invasiveness and duration. - [FAQ | EU Medical Device Regulation (MDR) 2017/745 | Scope, Classification, Technical File, Clinical Evaluation, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/faq.md): High-signal EU MDR FAQ: Is my product a medical device? Is my software in scope? What is Rule 11? Do I need a notified body? What goes in the technical file. - [MDR vs IVDR | EU Medical Device Regulation (MDR) 2017/745 vs IVDR 2017/746 | Classification, Evidence, UDI/EUDAMED](/artifacts/eu/medical-device-regulation/mdr-vs-ivdr.md): A practical MDR vs IVDR comparison for mixed device portfolios: scope differences (medical devices vs in vitro diagnostics), classification approaches. - [Penalties and Fines | EU Medical Device Regulation (MDR) 2017/745 | Enforcement Risk + How to Reduce Exposure](/artifacts/eu/medical-device-regulation/penalties-and-fines.md): A practical MDR enforcement guide: how penalties work under EU MDR (sanctions set by Member States), common enforcement triggers (misleading claims. - [PMS and Vigilance | EU Medical Device Regulation (MDR) 2017/745 | PMS Plan, PSUR, Serious Incidents, FSCA](/artifacts/eu/medical-device-regulation/post-market-surveillance-and-vigilance.md): A practical MDR PMS and vigilance guide: build the Annex III PMS system, decide when PSUR or PMS report applies, meet serious-incident timelines of 15 days. - [PMS Plan Template | EU Medical Device Regulation (MDR) 2017/745 | Annex III-Aligned Outline + Metrics](/artifacts/eu/medical-device-regulation/post-market-surveillance-plan-template.md): A practical MDR Post-Market Surveillance (PMS) plan template aligned to MDR Annex III: copy-ready sections for device scope, data sources. - [QMS and Technical File | EU Medical Device Regulation (MDR) 2017/745 | Annex II/III Technical Documentation + QMS Controls](/artifacts/eu/medical-device-regulation/qms-and-technical-file.md): A practical MDR QMS and technical-file guide: Article 10 and 15 governance, Annex II and III file structure, GSPR traceability. - [Requirements | EU Medical Device Regulation (MDR) 2017/745 | Core Obligations + Evidence Outputs](/artifacts/eu/medical-device-regulation/requirements.md): A grounded MDR requirements guide for Regulation (EU) 2017/745: scope and role mapping, Annex VIII classification, Article 10 and 15 governance. - [Transition Timelines | EU Medical Device Regulation (MDR) 2017/745 | Legacy Devices, 2023/607 Extension, Significant Changes](/artifacts/eu/medical-device-regulation/transition-timelines.md): A practical MDR transition and legacy-device timeline guide: how Article 120 works after Regulation (EU) 2023/607, which conditions must stay true. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/medical-device-regulation/udi-and-eudamed --- --- title: "Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/nis2-directive/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/nis2-directive/applicability-test" author: "Sorena AI" description: "A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "NIS2 applicability test" - "EU NIS2 Directive scope" - "Directive (EU) 2022/2555 in scope" - "NIS2 essential entity important entity" - "Annex I Annex II NIS2 sectors" - "NIS2 size cap rule medium-sized enterprise" - "NIS2 regardless of size" - "NIS2 scope assessment" - "NIS2 compliance scoping" - "EU NIS2" - "Directive (EU) 2022/2555" - "Applicability Test" - "Scope" - "Essential entities" - "Important entities" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Applicability Test A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers. *Applicability* *EU* ## EU NIS2 Directive (EU) 2022/2555 Applicability Test Decide scope and entity status with defensible reasoning. Output: a scope memo + essential/important classification + jurisdiction mapping + next-step control plan. NIS2 scoping errors are expensive: teams build the wrong control baseline, report to the wrong authority, or miss transposition-specific requirements. Use this page to produce a defensible scope memo per legal entity: what sector you match, why you match it, whether the size-cap applies, whether a regardless-of-size trigger applies, and whether you are treated as an essential or important entity under the directive framework. ## Before you start: capture the minimum facts (so the result survives review) A defensible NIS2 applicability decision depends on stable facts. Scope should be decided per legal entity and per service line, then consolidated into one group view. Output: a 1-2 page scope memo per legal entity, with annex mappings and size-cap reasoning. - Legal entities and EU establishments: where services are provided and where decisions are made. - Services and sectors: map each service to a candidate Annex I/II sector entry (don't use marketing categories). - Size profile: employees + turnover/balance sheet for the legal entity (and group, where relevant). - Digital infrastructure roles: cloud/MSP/MSSP/CDN/DNS/TLD, online marketplace/search/social platform, trust service provider. - Criticality flags: sole provider, systemic risk, public safety/health impacts (used in certain regardless-of-size cases). ## Step 1 - Does NIS2 scope apply to your type of entity? (Annex I/II + size-cap rule) NIS2 applies to entities of a type referred to in Annex I or Annex II that are medium-sized enterprises or larger, unless a regardless-of-size rule applies. Control: cite the exact Annex entry you match and the reasoning for the match. - Map the entity to the closest Annex I or Annex II entry and record the service-level reasoning, not just a business label. - Apply the size-cap rule using the SME framework and the NIS2-specific adjustments in Article 2(2). - Document borderline cases, mixed portfolios, and shared service models so the scope decision can be defended later. ## Step 2 - Regardless-of-size triggers (the common "surprise scope" cases) Even if you're small, NIS2 can still apply to specific categories (notably certain digital infrastructure and trust services) and to certain public administration entities. Treat these as explicit checks. Control: record whether each regardless-of-size trigger applies or not, with a one-paragraph rationale. - Providers of public electronic communications networks or publicly available electronic communications services, trust service providers, TLD name registries, DNS service providers, and domain name registration service providers can be in scope regardless of size. - Public administration entities listed in the directive, and certain entities identified as critical under the CER framework, can also be pulled in regardless of size. - Member States can extend national coverage to additional public administration entities or sectors, so check national law before concluding you are out of scope. ## Step 3 - Essential vs important (changes supervision and enforcement posture) NIS2 distinguishes essential and important entities. This affects supervision intensity and the compliance posture you should design for. Output: a classification note with the Article 3 category you match and the consequences for supervision and evidence. - Essential status can attach to the categories listed in Article 3(1), including specific digital infrastructure and trust-service categories regardless of size in some cases. - Entities in scope that do not qualify as essential are treated as important under Article 3(2). - Keep the classification note versioned and rerun it whenever services, group structure, or national transposition changes. ## Step 4 - Jurisdiction and transposition (where you'll be supervised and how obligations get specified) NIS2 is a directive: obligations are transposed into national law and operationalised by competent authorities and CSIRTs. You need a jurisdiction map for where you provide services and where reporting will occur. Output: a "competent authority and CSIRT map" and an incident reporting contact list. - Identify the Member States where you provide services or have establishments relevant to NIS2 supervision. - Track national transposition status and country-specific requirements (registration, reporting portals, formats). - Set up a governance owner for maintaining the transposition tracker and authority contact list. ## If in scope: the next three artifacts to build Once you're in scope, move directly to execution: control baseline, reporting workflow, and evidence pack. Use the linked pages to convert this into owners, evidence, and acceptance criteria. - Article 21 control baseline mapped to your services and risk exposure. - Incident reporting workflow and templates aligned to 24h/72h/1 month obligations. - Audit-ready evidence pack: policies, risk register, third-party controls, training, and governance minutes. *Recommended next step* *Placement: after the applicability result* ## Turn EU NIS2 Directive (EU) 2022/2555 Applicability Test into an operational assessment Assessment Autopilot can take EU NIS2 Directive (EU) 2022/2555 Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU NIS2 Directive (EU) 2022/2555 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU NIS2 Directive (EU) 2022/2555 Applicability Test](/solutions/assessment.md): Start from EU NIS2 Directive (EU) 2022/2555 Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU NIS2 Directive (EU) 2022/2555](/contact.md): Review your current process, evidence gaps, and next steps for EU NIS2 Directive (EU) 2022/2555 Applicability Test. ## Primary sources - [Directive (EU) 2022/2555 - NIS2 Directive (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Primary legal text for scope (Article 2), essential vs important entities (Article 3), and core obligations (Articles 20-23). - [NIS2 Directive overview - securing network and information systems (European Commission)](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive?ref=sorena.io) - High-level overview of scope, sectors and governance (board accountability, supervision and cooperation structures). - [Commission Recommendation 2003/361/EC - SME definition (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32003H0361&ref=sorena.io) - Reference definition for micro/small/medium enterprises used in NIS2 size-cap logic (with NIS2-specific adjustments). - [Commission Guidelines on Article 3(4) of NIS2 (OJ C 324, 14 Sep 2023) (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ%3AC%3A2023%3A324%3AFULL&ref=sorena.io) - Commission guidelines clarifying aspects of entity categorisation under NIS2. - [Commission Guidelines on Article 4(1) and 4(2) of NIS2 (OJ C 328, 18 Sep 2023) (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ%3AC%3A2023%3A328%3AFULL&ref=sorena.io) - Commission guidelines clarifying interplay with sector-specific Union legal acts and NIS2 application. ## Related Topic Guides - [Article 21 Control Baseline | EU NIS2 Directive (EU) 2022/2555 | Cybersecurity Risk Management Measures](/artifacts/eu/nis2-directive/article-21-control-baseline.md): A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence. - [Checklist | EU NIS2 Directive (EU) 2022/2555 | Audit-Ready Owners, Evidence, Acceptance Criteria](/artifacts/eu/nis2-directive/checklist.md): An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline. - [Compliance Guide | EU NIS2 Directive (EU) 2022/2555 | Build an Audit-Ready Program](/artifacts/eu/nis2-directive/compliance.md): A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows. - [Deadlines and Compliance Calendar | EU NIS2 Directive (EU) 2022/2555 | 16 January 2023, 17 October 2024, 17 April 2025](/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar.md): A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023. - [FAQ | EU NIS2 Directive (EU) 2022/2555 | Scope, Essential vs Important, Article 21, Article 23 (24h/72h)](/artifacts/eu/nis2-directive/faq.md): High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires. - [Incident Reporting Workflow | EU NIS2 Directive (EU) 2022/2555 | 24h Early Warning, 72h Notification, Final Report (1 Month)](/artifacts/eu/nis2-directive/incident-reporting-workflow.md): A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents. - [Management Body Accountability | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Training, Liability](/artifacts/eu/nis2-directive/management-body-accountability.md): A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work. - [National Transposition Tracker | EU NIS2 Directive (EU) 2022/2555 | How to Track Local Laws, Authorities, Portals](/artifacts/eu/nis2-directive/national-transposition-tracker.md): A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes. - [NIS2 vs ISO/IEC 27001 | How to Reuse Your ISMS for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27001.md): A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review. - [NIS2 vs ISO/IEC 27017 | Cloud Security Mapping for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27017.md): A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations. - [NIS2 vs NIS1 | Directive (EU) 2022/2555 vs Directive (EU) 2016/1148 | Scope, Supervision, Reporting](/artifacts/eu/nis2-directive/nis2-vs-nis1.md): A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works. - [Penalties and Fines | EU NIS2 Directive (EU) 2022/2555 | Article 32-34 Enforcement + Fine Thresholds](/artifacts/eu/nis2-directive/penalties-and-fines.md): A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use. - [Requirements | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Article 21 Controls, Article 23 Reporting](/artifacts/eu/nis2-directive/requirements.md): A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690. - [Scope: Essential vs Important | EU NIS2 Directive (EU) 2022/2555 | Article 3 Classification + What Changes](/artifacts/eu/nis2-directive/scope-essential-vs-important.md): A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3). - [Supply Chain Security Program | EU NIS2 Directive (EU) 2022/2555 | Article 21(d) Supplier Risk + Evidence](/artifacts/eu/nis2-directive/supply-chain-security-program.md): A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/nis2-directive/applicability-test --- --- title: "Article 21 Control Baseline" canonical_url: "https://www.sorena.io/artifacts/eu/nis2-directive/article-21-control-baseline" source_url: "https://www.sorena.io/artifacts/eu/nis2-directive/article-21-control-baseline" author: "Sorena AI" description: "A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "NIS2 Article 21 controls" - "Article 21(2) cybersecurity risk management measures" - "NIS2 control baseline" - "EU NIS2 Directive control baseline" - "NIS2 cybersecurity risk management measures a to j" - "NIS2 incident handling" - "NIS2 business continuity backup disaster recovery" - "NIS2 supply chain security" - "NIS2 secure development vulnerability handling disclosure" - "NIS2 effectiveness assessment" - "NIS2 cyber hygiene training" - "NIS2 encryption cryptography" - "NIS2 identity access management MFA" - "Implementing Regulation (EU) 2024/2690" - "ENISA NIS2 technical implementation guidance" - "NIS2" - "Directive (EU) 2022/2555" - "Article 21" - "Cybersecurity risk management" - "ENISA guidance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Article 21 Control Baseline A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence. *Article 21* *Control Baseline* ## EU NIS2 Directive (EU) 2022/2555 Article 21 Control Baseline Convert Article 21(a) to (j) into controls you can implement and defend. Output: a control baseline with owners, KPIs, and evidence artifacts aligned to your services and risk exposure. Article 21 is the NIS2 control baseline. It is broad on purpose. Your job is to convert the legal measures into specific controls, measurable acceptance criteria, testing cadence, and evidence that show the controls actually work. ## What Article 21 requires (and what "appropriate and proportionate" means in practice) Article 21 requires essential and important entities to take technical, operational, and organisational measures to manage risks to the network and information systems used for operations or service delivery and to prevent or minimise incident impact. Appropriate and proportionate means risk-based implementation: state of the art, cost, size, exposure, likelihood, severity, and societal or economic impact all matter. - Scope the baseline per legal entity and per service: what systems, which recipients, which critical dependencies. - Define a measurable control baseline (not only policies): logging coverage, patch SLAs, restore tests, MFA coverage, supplier assurance coverage. - Treat physical environment as in-scope (Article 21 "all-hazards" approach): data centre access, environmental controls, resilience. - Prove effectiveness (Article 21(2)(f)): internal audit, control testing, metrics, and management review decisions. ## Article 21(2)(a) to (j) mapped to control families you can implement Use this mapping to build a control register. For each item: set an owner, define acceptance criteria, choose evidence, set a test cadence, and log exceptions. - (a) Risk analysis and security policies: service inventory, risk method, treatment plans, policy set, and review cadence. - (b) Incident handling: triage, escalation, containment, recovery, lessons learned, and evidence preservation. - (c) Business continuity and crisis management: backup strategy, recovery plans, restore testing, crisis roles, and communications. - (d) Supply chain security: supplier tiering, due diligence, contract controls, service monitoring, and supplier incident paths. - (e) Security in acquisition, development, and maintenance: secure design, change control, patching, vulnerability handling, and disclosure. - (f) Effectiveness assessment: control tests, scans, audits, tabletop exercises, and corrective action tracking. - (g) Basic cyber hygiene and training: secure configuration, asset hygiene, role-based awareness, and periodic refresh. - (h) Cryptography and, where appropriate, encryption: data classification, key management, certificate lifecycle, and exception handling. - (i) Human resources security, access control, and asset management: joiner-mover-leaver controls, privileged access, least privilege, and asset lifecycle. - (j) Multi-factor authentication, secure communications, and secure voice, video, and text communications where appropriate. ## Where Implementing Regulation (EU) 2024/2690 adds specificity The Commission adopted Implementing Regulation (EU) 2024/2690 on 17 October 2024 and it was published on 18 October 2024. It entered into force on 7 November 2024 and applies directly in Member States. It covers DNS service providers, TLD name registries, cloud providers, data centre providers, CDN providers, managed service providers, managed security service providers, online marketplace providers, online search engine providers, social networking services platforms, and trust service providers. - Confirm whether your entity is in one of the covered categories before using the regulation as a required baseline. - Use ENISA Technical Implementation Guidance version 1.0 from June 2025 as a non-binding implementation aid, not as a substitute for the law. - Map the implementing regulation controls to your evidence pack so significance decisions, logging, supplier controls, and recovery controls are consistent. ## Audit-ready evidence pack Supervision powers include requests for policies and evidence, security audits, scans, and enforcement actions. Your goal is to make compliance explainable in minutes, not weeks. - Control register: Article 21 mapping -> control IDs -> owners -> KPIs -> evidence links. - Risk assessment pack: methodology, risk register, treatment plans, and formal risk acceptance decisions. - Security operations evidence: monitoring coverage, alert triage SLAs, incident logs, and post-incident reviews. - Resilience evidence: backup inventory, restore-test results, DR exercises, and crisis management exercises. - Supplier assurance: tiering, due diligence records, contract clauses, periodic reviews, and supplier incident communications. - Training and governance: management approval minutes (Article 20), training records, and management oversight cadence. *Recommended next step* *Placement: after the main workflow section* ## Turn EU NIS2 Directive (EU) 2022/2555 Article 21 Control Baseline into an operational assessment Assessment Autopilot can take EU NIS2 Directive (EU) 2022/2555 Article 21 Control Baseline from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on EU NIS2 Directive (EU) 2022/2555 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU NIS2 Directive (EU) 2022/2555 Article 21 Control Baseline](/solutions/assessment.md): Start from EU NIS2 Directive (EU) 2022/2555 Article 21 Control Baseline and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU NIS2 Directive (EU) 2022/2555](/contact.md): Review your current process, evidence gaps, and next steps for EU NIS2 Directive (EU) 2022/2555 Article 21 Control Baseline. ## A 90 day implementation plan If you're starting from scratch, sequence the work to create immediate risk reduction and a defensible baseline quickly. - Days 0-14: scope memo + service inventory + essential/important classification + control register draft. - Days 15-30: incident workflow + reporting triggers + crisis comms + backup/restore baseline and restore test. - Days 31-60: supplier tiering + contract addenda + vulnerability handling program + privileged access/MFA coverage. - Days 61-90: effectiveness testing cadence (audits/scans/tabletops), KPI dashboards, and management review sign-off. ## Primary sources - [Directive (EU) 2022/2555 (NIS2) - Official Journal text (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Primary legal text for Article 21 cybersecurity risk management measures. - [Commission Implementing Regulation (EU) 2024/2690 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng?ref=sorena.io) - Binding technical and methodological requirements for covered digital providers and trust service providers, plus further specification of significant incident cases. - [ENISA - NIS2 Technical Implementation Guidance](https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance?ref=sorena.io) - Non-binding implementation aid that maps the implementing regulation requirements into practical evidence examples. ## Related Topic Guides - [Applicability Test | EU NIS2 Directive (EU) 2022/2555 | In Scope? Essential vs Important?](/artifacts/eu/nis2-directive/applicability-test.md): A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers. - [Checklist | EU NIS2 Directive (EU) 2022/2555 | Audit-Ready Owners, Evidence, Acceptance Criteria](/artifacts/eu/nis2-directive/checklist.md): An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline. - [Compliance Guide | EU NIS2 Directive (EU) 2022/2555 | Build an Audit-Ready Program](/artifacts/eu/nis2-directive/compliance.md): A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows. - [Deadlines and Compliance Calendar | EU NIS2 Directive (EU) 2022/2555 | 16 January 2023, 17 October 2024, 17 April 2025](/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar.md): A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023. - [FAQ | EU NIS2 Directive (EU) 2022/2555 | Scope, Essential vs Important, Article 21, Article 23 (24h/72h)](/artifacts/eu/nis2-directive/faq.md): High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires. - [Incident Reporting Workflow | EU NIS2 Directive (EU) 2022/2555 | 24h Early Warning, 72h Notification, Final Report (1 Month)](/artifacts/eu/nis2-directive/incident-reporting-workflow.md): A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents. - [Management Body Accountability | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Training, Liability](/artifacts/eu/nis2-directive/management-body-accountability.md): A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work. - [National Transposition Tracker | EU NIS2 Directive (EU) 2022/2555 | How to Track Local Laws, Authorities, Portals](/artifacts/eu/nis2-directive/national-transposition-tracker.md): A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes. - [NIS2 vs ISO/IEC 27001 | How to Reuse Your ISMS for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27001.md): A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review. - [NIS2 vs ISO/IEC 27017 | Cloud Security Mapping for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27017.md): A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations. - [NIS2 vs NIS1 | Directive (EU) 2022/2555 vs Directive (EU) 2016/1148 | Scope, Supervision, Reporting](/artifacts/eu/nis2-directive/nis2-vs-nis1.md): A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works. - [Penalties and Fines | EU NIS2 Directive (EU) 2022/2555 | Article 32-34 Enforcement + Fine Thresholds](/artifacts/eu/nis2-directive/penalties-and-fines.md): A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use. - [Requirements | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Article 21 Controls, Article 23 Reporting](/artifacts/eu/nis2-directive/requirements.md): A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690. - [Scope: Essential vs Important | EU NIS2 Directive (EU) 2022/2555 | Article 3 Classification + What Changes](/artifacts/eu/nis2-directive/scope-essential-vs-important.md): A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3). - [Supply Chain Security Program | EU NIS2 Directive (EU) 2022/2555 | Article 21(d) Supplier Risk + Evidence](/artifacts/eu/nis2-directive/supply-chain-security-program.md): A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/nis2-directive/article-21-control-baseline --- --- title: "Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/nis2-directive/checklist" source_url: "https://www.sorena.io/artifacts/eu/nis2-directive/checklist" author: "Sorena AI" description: "An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU NIS2 checklist" - "NIS2 compliance checklist" - "NIS2 readiness checklist" - "NIS2 audit checklist" - "Directive (EU) 2022/2555 checklist" - "Article 21 checklist" - "Article 23 incident reporting checklist 24h 72h 1 month" - "Article 20 management accountability checklist" - "essential entity vs important entity checklist" - "NIS2 evidence pack checklist" - "NIS2" - "Checklist" - "Audit readiness" - "Article 21" - "Article 23" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Checklist An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline. *Checklist* *EU* ## EU NIS2 Directive (EU) 2022/2555 Checklist A checklist you can assign to owners and verify with evidence. Use this as a readiness review: each line item should produce an artefact, a control metric, or an operational workflow. Compliance checklists fail when they're generic. This one is designed for execution: each step includes what "done" means and what evidence you should be able to produce under supervision. ## 1) Scope and classification (the output is a defensible scope memo) Start by scoping per legal entity and per service. Without a scope memo, downstream controls and reporting workflows are misaligned. - Map your sector/subsector to Annex I or Annex II; document any borderline cases. - Apply size-cap rules and any regardless-of-size triggers; keep an SME classification note where relevant. - Classify as essential or important (Article 3) and record the rationale and jurisdiction assumptions. - Identify sector-specific EU acts that may apply (Article 4) and document equivalence decisions. - Done looks like: a scope memo with entity list, sector mapping, size logic, classification, and national transposition assumptions. ## 2) Article 20 governance (management approval, oversight, and training) NIS2 explicitly pulls cybersecurity into the management body. Treat this as a governance system, not a policy signature. - Management body approves the cybersecurity risk management measures and oversees implementation. - Management body training: define curriculum, cadence, attendance tracking, and update loop after incidents. - Define a governance cadence: monthly metrics, quarterly risk reviews, annual crisis exercises. - Done looks like: board/management minutes, training evidence, and an accountability/RACI model. ## 3) Article 21 control baseline (owned controls with KPIs and evidence) Build a control register that maps Article 21(2) a-j to concrete controls with owners, metrics, and evidence. - Risk analysis + policies: risk method, asset/service inventory, treatment plans, risk acceptance decisions. - Incident handling: runbooks, escalation paths, forensic readiness, post-incident review cadence. - BC/DR: backup strategy, restore tests, DR exercises, crisis management playbooks. - Supply chain: vendor tiering, security clauses, onboarding/offboarding, supplier incident comms. - Secure development + vulnerability handling: secure SDLC, patching SLAs, disclosure process. - Effectiveness: audits, scans, control tests, corrective action tracking. - Done looks like: a control register + evidence vault (links to policies, logs, tests, audits, and training). ## 4) Article 23 incident reporting (a workflow you can execute at 02:00) Implement reporting as a pipeline with triggers, templates, and evidence capture so you can meet 24h/72h deadlines under uncertainty. - Define "significant incident" triage thresholds and keep a decision log (who decided, when, and why). - 24h early warning; 72h notification with initial assessment and IoCs; final report within 1 month. - Recipient communications playbook for incidents likely to adversely affect service provision. - Done looks like: templates, runbooks, authority contact paths, evidence capture process, and a tabletop exercise result. *Recommended next step* *Placement: after the checklist block* ## Turn EU NIS2 Directive (EU) 2022/2555 Checklist into an operational assessment Assessment Autopilot can take EU NIS2 Directive (EU) 2022/2555 Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU NIS2 Directive (EU) 2022/2555 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU NIS2 Directive (EU) 2022/2555 Checklist](/solutions/assessment.md): Start from EU NIS2 Directive (EU) 2022/2555 Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU NIS2 Directive (EU) 2022/2555](/contact.md): Review your current process, evidence gaps, and next steps for EU NIS2 Directive (EU) 2022/2555 Checklist. ## Primary sources - [Directive (EU) 2022/2555 (NIS2) - Official Journal text (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Primary source for scope, classification, governance (Article 20), controls (Article 21), and reporting (Article 23). - [European Commission - NIS2 Directive overview (policy page)](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive?ref=sorena.io) - Context and links to guidelines and implementation resources. ## Related Topic Guides - [Applicability Test | EU NIS2 Directive (EU) 2022/2555 | In Scope? Essential vs Important?](/artifacts/eu/nis2-directive/applicability-test.md): A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers. - [Article 21 Control Baseline | EU NIS2 Directive (EU) 2022/2555 | Cybersecurity Risk Management Measures](/artifacts/eu/nis2-directive/article-21-control-baseline.md): A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence. - [Compliance Guide | EU NIS2 Directive (EU) 2022/2555 | Build an Audit-Ready Program](/artifacts/eu/nis2-directive/compliance.md): A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows. - [Deadlines and Compliance Calendar | EU NIS2 Directive (EU) 2022/2555 | 16 January 2023, 17 October 2024, 17 April 2025](/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar.md): A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023. - [FAQ | EU NIS2 Directive (EU) 2022/2555 | Scope, Essential vs Important, Article 21, Article 23 (24h/72h)](/artifacts/eu/nis2-directive/faq.md): High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires. - [Incident Reporting Workflow | EU NIS2 Directive (EU) 2022/2555 | 24h Early Warning, 72h Notification, Final Report (1 Month)](/artifacts/eu/nis2-directive/incident-reporting-workflow.md): A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents. - [Management Body Accountability | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Training, Liability](/artifacts/eu/nis2-directive/management-body-accountability.md): A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work. - [National Transposition Tracker | EU NIS2 Directive (EU) 2022/2555 | How to Track Local Laws, Authorities, Portals](/artifacts/eu/nis2-directive/national-transposition-tracker.md): A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes. - [NIS2 vs ISO/IEC 27001 | How to Reuse Your ISMS for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27001.md): A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review. - [NIS2 vs ISO/IEC 27017 | Cloud Security Mapping for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27017.md): A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations. - [NIS2 vs NIS1 | Directive (EU) 2022/2555 vs Directive (EU) 2016/1148 | Scope, Supervision, Reporting](/artifacts/eu/nis2-directive/nis2-vs-nis1.md): A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works. - [Penalties and Fines | EU NIS2 Directive (EU) 2022/2555 | Article 32-34 Enforcement + Fine Thresholds](/artifacts/eu/nis2-directive/penalties-and-fines.md): A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use. - [Requirements | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Article 21 Controls, Article 23 Reporting](/artifacts/eu/nis2-directive/requirements.md): A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690. - [Scope: Essential vs Important | EU NIS2 Directive (EU) 2022/2555 | Article 3 Classification + What Changes](/artifacts/eu/nis2-directive/scope-essential-vs-important.md): A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3). - [Supply Chain Security Program | EU NIS2 Directive (EU) 2022/2555 | Article 21(d) Supplier Risk + Evidence](/artifacts/eu/nis2-directive/supply-chain-security-program.md): A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/nis2-directive/checklist --- --- title: "Compliance Guide" canonical_url: "https://www.sorena.io/artifacts/eu/nis2-directive/compliance" source_url: "https://www.sorena.io/artifacts/eu/nis2-directive/compliance" author: "Sorena AI" description: "A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU NIS2 compliance" - "NIS2 compliance guide" - "NIS2 compliance program" - "NIS2 audit readiness" - "Directive (EU) 2022/2555 compliance" - "Article 21 compliance controls" - "Article 23 incident reporting compliance 24h 72h 1 month" - "Article 20 management accountability compliance" - "essential vs important entity NIS2 compliance" - "NIS2" - "Compliance" - "Audit readiness" - "Cybersecurity risk management" - "Incident reporting" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Compliance Guide A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows. *Compliance* *EU* ## EU NIS2 Directive (EU) 2022/2555 Compliance Build an NIS2 compliance program that works during incidents and audits. Output: scoped program, owned controls, reporting workflows, and evidence packs aligned to supervision expectations. NIS2 compliance is the ability to demonstrate - quickly and credibly - that you govern cybersecurity at management level, that your controls reduce real risk, and that you can report significant incidents on time with evidence. Use this page as the operating model for your NIS2 program. ## Compliance operating model (what the program must produce) Treat compliance outputs as artefacts that can be audited: scope memo, control register, incident reporting workflow, and evidence vault. - Scope memo: per legal entity, sector mapping, size-cap logic, essential vs important classification, and jurisdiction assumptions. - Control baseline: Article 21 a-j mapped to control IDs, owners, KPIs, and evidence items (tests, logs, audits, training). - Incident reporting workflow: significant incident triage, 24h/72h/1 month templates, and authority contact routes. - Governance: management approval and oversight cadence (Article 20), training records, and risk acceptance decisions. *Recommended next step* *Placement: after the compliance steps* ## Turn EU NIS2 Directive (EU) 2022/2555 Compliance into an operational assessment Assessment Autopilot can take EU NIS2 Directive (EU) 2022/2555 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU NIS2 Directive (EU) 2022/2555 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU NIS2 Directive (EU) 2022/2555 Compliance](/solutions/assessment.md): Start from EU NIS2 Directive (EU) 2022/2555 Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU NIS2 Directive (EU) 2022/2555](/contact.md): Review your current process, evidence gaps, and next steps for EU NIS2 Directive (EU) 2022/2555 Compliance. ## Phased implementation plan (fast risk reduction + fast defensibility) Sequence matters. Prioritise controls that reduce impact and controls that enable reporting and evidence capture. - Phase 1 (0-30 days): scope memo, RACI, incident reporting workflow, backup/restore baseline + restore test, MFA for admin access. - Phase 2 (31-60 days): supplier tiering + contract clauses, vulnerability handling and patch SLAs, monitoring/logging coverage uplift. - Phase 3 (61-90 days): control effectiveness testing cadence (audits/scans/tabletops), KPI dashboards, and management review sign-off. - Phase 4 (ongoing): continuous risk cycles, supplier reviews, and recurring reporting drills. ## Audit and supervision readiness (design your evidence so it can be produced quickly) Supervision can involve audits, scans, and requests for policies and evidence. Build an evidence vault with tight access control and clear indexing. - Index evidence by requirement: Article 20, Article 21 a-j, Article 23 reporting, and national transposition specifics. - Maintain an exception register with expiry dates and management approval for risk acceptance. - Keep incident evidence separate from "policy evidence": timelines, logs, IoCs, and reporting submissions must be retrievable. - Prove effectiveness (Article 21(2)(f)) with test results, audit findings, remediation tracking, and KPI trends. ## Handle national transposition reality (how to stay consistent across jurisdictions) NIS2 is implemented through Member State transposition and supervision. Your program needs a central baseline with local overlays. - Keep a per-country overlay sheet: competent authority/CSIRT routes, reporting portals, and any additional requirements. - If you operate in multiple Member States, document how you will coordinate incident reporting across jurisdictions. - Track transposition updates and update your scope memo and reporting routes when national rules change. ## Primary sources - [Directive (EU) 2022/2555 (NIS2) - Official Journal text (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Primary source for Articles 20-23, supervision/enforcement, and incident reporting obligations. - [European Commission - NIS2 Directive overview (policy page)](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive?ref=sorena.io) - High-level context and links to guidelines and implementation resources. - [European Commission - NIS2 transposition tracker (interactive map)](https://digital-strategy.ec.europa.eu/en/policies/nis-transposition?ref=sorena.io) - Use this to validate transposition status and to navigate to Member State implementation pages. ## Related Topic Guides - [Applicability Test | EU NIS2 Directive (EU) 2022/2555 | In Scope? Essential vs Important?](/artifacts/eu/nis2-directive/applicability-test.md): A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers. - [Article 21 Control Baseline | EU NIS2 Directive (EU) 2022/2555 | Cybersecurity Risk Management Measures](/artifacts/eu/nis2-directive/article-21-control-baseline.md): A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence. - [Checklist | EU NIS2 Directive (EU) 2022/2555 | Audit-Ready Owners, Evidence, Acceptance Criteria](/artifacts/eu/nis2-directive/checklist.md): An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline. - [Deadlines and Compliance Calendar | EU NIS2 Directive (EU) 2022/2555 | 16 January 2023, 17 October 2024, 17 April 2025](/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar.md): A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023. - [FAQ | EU NIS2 Directive (EU) 2022/2555 | Scope, Essential vs Important, Article 21, Article 23 (24h/72h)](/artifacts/eu/nis2-directive/faq.md): High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires. - [Incident Reporting Workflow | EU NIS2 Directive (EU) 2022/2555 | 24h Early Warning, 72h Notification, Final Report (1 Month)](/artifacts/eu/nis2-directive/incident-reporting-workflow.md): A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents. - [Management Body Accountability | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Training, Liability](/artifacts/eu/nis2-directive/management-body-accountability.md): A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work. - [National Transposition Tracker | EU NIS2 Directive (EU) 2022/2555 | How to Track Local Laws, Authorities, Portals](/artifacts/eu/nis2-directive/national-transposition-tracker.md): A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes. - [NIS2 vs ISO/IEC 27001 | How to Reuse Your ISMS for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27001.md): A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review. - [NIS2 vs ISO/IEC 27017 | Cloud Security Mapping for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27017.md): A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations. - [NIS2 vs NIS1 | Directive (EU) 2022/2555 vs Directive (EU) 2016/1148 | Scope, Supervision, Reporting](/artifacts/eu/nis2-directive/nis2-vs-nis1.md): A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works. - [Penalties and Fines | EU NIS2 Directive (EU) 2022/2555 | Article 32-34 Enforcement + Fine Thresholds](/artifacts/eu/nis2-directive/penalties-and-fines.md): A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use. - [Requirements | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Article 21 Controls, Article 23 Reporting](/artifacts/eu/nis2-directive/requirements.md): A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690. - [Scope: Essential vs Important | EU NIS2 Directive (EU) 2022/2555 | Article 3 Classification + What Changes](/artifacts/eu/nis2-directive/scope-essential-vs-important.md): A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3). - [Supply Chain Security Program | EU NIS2 Directive (EU) 2022/2555 | Article 21(d) Supplier Risk + Evidence](/artifacts/eu/nis2-directive/supply-chain-security-program.md): A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/nis2-directive/compliance --- --- title: "Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU NIS2 deadlines" - "NIS2 compliance calendar" - "NIS2 transposition deadline 17 October 2024" - "NIS2 entry into force January 2023" - "NIS2 repeal NIS1 18 October 2024" - "NIS2 entity list 17 April 2025" - "Article 23 reporting 24 hours 72 hours 1 month" - "NIS2 timeline" - "NIS2 compliance milestones" - "NIS2" - "Deadlines" - "Transposition" - "Incident reporting" - "Article 21" - "Article 23" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Deadlines and Compliance Calendar A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023. *Deadlines* *EU* ## EU NIS2 Directive (EU) 2022/2555 Deadlines and Compliance Calendar Turn NIS2 dates into deliverables, owners, and escalation gates. Focus: legal anchor dates, transposition reality, entity listing milestones, and operational readiness for Article 21 and Article 23. Dates only help if they drive work. Use this page to convert NIS2 anchor dates into scope memos, entity registry submissions, management approvals, incident reporting tests, and evidence refresh cycles. ## EU-level anchor dates you should track These dates are in the directive or in official Commission material. National measures can add registration or reporting steps, but they do not replace these EU-level anchors. - 16 January 2023: NIS2 entered into force. - 17 October 2024: Member States had to adopt and publish transposition measures. - 18 October 2024: Member States had to apply those measures, and NIS1 was repealed. - 17 January 2025: entities within Article 27 had to submit core entity information to competent authorities, and Member States had to notify the Commission of national penalty rules under Article 36. - 17 April 2025: Member States had to establish lists of essential and important entities and notify key figures to the Commission. ## Current transposition milestones you should reflect in planning The Commission tracker is a state-of-play tool, not a formal legal assessment. It is still useful for planning because it shows where local overlays may still be moving. - 7 May 2025: the Commission sent reasoned opinions to 19 Member States for not notifying full transposition. - 1 July 2025: the Commission transposition tracker page showed its latest update date. - 20 January 2026: the Commission proposed targeted NIS2 amendments to simplify and clarify parts of the framework. This is a proposal, not current law. *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU NIS2 Directive (EU) 2022/2555 Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take EU NIS2 Directive (EU) 2022/2555 Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU NIS2 Directive (EU) 2022/2555 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU NIS2 Directive (EU) 2022/2555 Deadlines and Compliance Calendar](/solutions/assessment.md): Start from EU NIS2 Directive (EU) 2022/2555 Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU NIS2 Directive (EU) 2022/2555](/contact.md): Review your current process, evidence gaps, and next steps for EU NIS2 Directive (EU) 2022/2555 Deadlines and Compliance Calendar. ## What to deliver before each milestone Convert each date into a concrete output. If a calendar item does not point to a file, a register, or a tested workflow, it is too vague. - Before transposition review: scope memo, Annex I or Annex II mapping, essential or important classification note, and Article 4 overlap analysis. - Before Article 27 data collection: entity registry data set, legal-entity identifiers, contact points, and service mapping ready for authority submission. - Before operational go-live: authority and CSIRT route map, portal accounts, 24h and 72h templates, and a tested significant incident decision log. - Before supervisory contact: Article 21 control register, management approval evidence, and indexed evidence vault. ## Internal recurring calendar items NIS2 compliance is a repeating management system. Use recurring reviews to keep evidence current and reduce incident severity. - Monthly: vulnerability backlog review, patch SLA performance, and privileged access and MFA coverage checks. - Monthly: backup integrity and restore test review for critical systems. - Quarterly: supplier risk review, incident reporting tabletop, and management oversight meeting. - Annually: crisis simulation, evidence vault refresh, and scope memo revalidation after organisational changes. ## Primary sources - [Directive (EU) 2022/2555 (NIS2) - Official Journal text (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Primary legal text for Article 3, Article 27, Article 36, transposition timing, and the repeal of NIS1. - [European Commission - NIS2 Directive overview](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive?ref=sorena.io) - Official Commission policy page confirming entry into force on 16 January 2023 and linking to core implementation resources. - [European Commission - NIS2 transposition tracker](https://digital-strategy.ec.europa.eu/en/policies/nis-transposition?ref=sorena.io) - State-of-play page with the 7 May 2025 reasoned opinion update and the 1 July 2025 page update date. ## Related Topic Guides - [Applicability Test | EU NIS2 Directive (EU) 2022/2555 | In Scope? Essential vs Important?](/artifacts/eu/nis2-directive/applicability-test.md): A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers. - [Article 21 Control Baseline | EU NIS2 Directive (EU) 2022/2555 | Cybersecurity Risk Management Measures](/artifacts/eu/nis2-directive/article-21-control-baseline.md): A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence. - [Checklist | EU NIS2 Directive (EU) 2022/2555 | Audit-Ready Owners, Evidence, Acceptance Criteria](/artifacts/eu/nis2-directive/checklist.md): An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline. - [Compliance Guide | EU NIS2 Directive (EU) 2022/2555 | Build an Audit-Ready Program](/artifacts/eu/nis2-directive/compliance.md): A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows. - [FAQ | EU NIS2 Directive (EU) 2022/2555 | Scope, Essential vs Important, Article 21, Article 23 (24h/72h)](/artifacts/eu/nis2-directive/faq.md): High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires. - [Incident Reporting Workflow | EU NIS2 Directive (EU) 2022/2555 | 24h Early Warning, 72h Notification, Final Report (1 Month)](/artifacts/eu/nis2-directive/incident-reporting-workflow.md): A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents. - [Management Body Accountability | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Training, Liability](/artifacts/eu/nis2-directive/management-body-accountability.md): A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work. - [National Transposition Tracker | EU NIS2 Directive (EU) 2022/2555 | How to Track Local Laws, Authorities, Portals](/artifacts/eu/nis2-directive/national-transposition-tracker.md): A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes. - [NIS2 vs ISO/IEC 27001 | How to Reuse Your ISMS for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27001.md): A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review. - [NIS2 vs ISO/IEC 27017 | Cloud Security Mapping for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27017.md): A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations. - [NIS2 vs NIS1 | Directive (EU) 2022/2555 vs Directive (EU) 2016/1148 | Scope, Supervision, Reporting](/artifacts/eu/nis2-directive/nis2-vs-nis1.md): A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works. - [Penalties and Fines | EU NIS2 Directive (EU) 2022/2555 | Article 32-34 Enforcement + Fine Thresholds](/artifacts/eu/nis2-directive/penalties-and-fines.md): A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use. - [Requirements | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Article 21 Controls, Article 23 Reporting](/artifacts/eu/nis2-directive/requirements.md): A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690. - [Scope: Essential vs Important | EU NIS2 Directive (EU) 2022/2555 | Article 3 Classification + What Changes](/artifacts/eu/nis2-directive/scope-essential-vs-important.md): A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3). - [Supply Chain Security Program | EU NIS2 Directive (EU) 2022/2555 | Article 21(d) Supplier Risk + Evidence](/artifacts/eu/nis2-directive/supply-chain-security-program.md): A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar --- --- title: "FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/nis2-directive/faq" source_url: "https://www.sorena.io/artifacts/eu/nis2-directive/faq" author: "Sorena AI" description: "High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU NIS2 FAQ" - "NIS2 questions and answers" - "is my company in scope NIS2" - "essential vs important entity NIS2" - "NIS2 Article 21 requirements" - "NIS2 Article 23 reporting 24 hours 72 hours" - "NIS2 significant incident definition" - "NIS2 transposition FAQ" - "NIS2" - "FAQ" - "Scope" - "Article 21" - "Article 23" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FAQ High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires. *FAQ* *EU* ## EU NIS2 Directive (EU) 2022/2555 Frequently Asked Questions Practical, high-intent answers to NIS2 scope, controls, and reporting. Use this as a fast orientation, then follow the subpages for implementation details and evidence mapping. NIS2 questions are often answered incorrectly because people mix the directive text with national transposition details and sector guidance. This FAQ focuses on accurate baseline answers and the practical implications for your implementation program. ## Scope and classification Most search intent is: "Am I in scope?" and "Am I essential or important?" Start here. - Q: Who is in scope? A: Public or private entities of a type in Annex I or II that are at least medium-sized (or above), plus certain regardless-of-size cases (e.g., providers of public electronic communications networks/services, trust service providers, TLD registries and DNS service providers), subject to Directive scope conditions. - Q: What's essential vs important? A: NIS2 distinguishes entity types and uses Member State identification/lists; entities not qualifying as essential under Article 3(1) are treated as important under Article 3(2). - Q: Does being "small" mean out of scope? A: Not always. Certain entity types are in scope regardless of size (e.g., trust service providers; certain digital infrastructure providers). - Q: What if a sector-specific EU act applies? A: Article 4 provides a mechanism where equivalent sector-specific obligations can displace certain NIS2 provisions for the overlapping parts. ## Article 21 controls (risk management measures) The most common misunderstanding is treating Article 21 as "policy language". It's a control baseline that must be owned, measurable, and evidenced. - Q: What does Article 21 require? A: Appropriate and proportionate technical, operational, and organisational measures to manage risks and prevent/minimise incident impact. - Q: What are the minimum measures? A: Article 21(2) lists at least a-j measures (risk analysis/policies, incident handling, BC/DR, supply chain security, secure development + vulnerability handling, effectiveness assessment, cyber hygiene/training, cryptography, HR/access/asset management, MFA/secure communications). - Q: Do standards matter? A: Article 21 refers to state-of-the-art and (where applicable) relevant European and international standards; for certain entity types, an implementing regulation provides more prescriptive requirements. - Q: What evidence do we need? A: Control register, test results, audit evidence, supplier assurance records, training records, and incident post-mortems linked back to control improvements. ## Article 23 incident reporting (24h/72h/1 month) Reporting obligations fail when teams don't have triage rules and templates ready before an incident happens. - Q: What triggers reporting? A: Incidents that have a significant impact on the provision of services (significant incident). - Q: What is the timeline? A: Early warning within 24h of becoming aware; incident notification within 72h; final report within 1 month after the 72h notification (with intermediate/progress reports as applicable). - Q: Do we have to notify customers/recipients? A: Where appropriate, entities notify recipients of services of significant incidents likely to adversely affect service provision, and communicate measures recipients can take for significant cyber threats. - Q: Who do we report to? A: The CSIRT or (where applicable) competent authority - routes are defined in national transposition and should be validated per Member State. ## Transposition and enforcement NIS2 is implemented through Member State transposition and supervision. Your program must be stable across jurisdictions while allowing local overlays. - Q: How do we track transposition? A: Use the Commission's transposition tracker and Member State implementation pages, then validate with national competent authority guidance. - Q: What are the consequences of non-compliance? A: Supervision and enforcement powers include audits, scans, binding instructions, and administrative fines tied to Article 21/23 infringements (Article 34). - Q: What should we do first? A: Scope memo -> classification -> Article 21 control baseline -> Article 23 workflow and templates -> evidence vault and governance cadence. *Recommended next step* *Placement: after the FAQ section* ## Use EU NIS2 Directive (EU) 2022/2555 Frequently Asked Questions as a cited research workflow Research Copilot can take EU NIS2 Directive (EU) 2022/2555 Frequently Asked Questions from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU NIS2 Directive (EU) 2022/2555 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU NIS2 Directive (EU) 2022/2555 Frequently Asked Questions](/solutions/research-copilot.md): Start from EU NIS2 Directive (EU) 2022/2555 Frequently Asked Questions and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU NIS2 Directive (EU) 2022/2555](/contact.md): Review your current process, evidence gaps, and next steps for EU NIS2 Directive (EU) 2022/2555 Frequently Asked Questions. ## Primary sources - [Directive (EU) 2022/2555 (NIS2) - Official Journal text (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Primary source for scope, essential vs important logic (Article 3), Article 21 controls, and Article 23 reporting. - [European Commission - NIS2 Directive overview (policy page)](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive?ref=sorena.io) - Context and links to implementation resources, guidelines, and transposition materials. ## Related Topic Guides - [Applicability Test | EU NIS2 Directive (EU) 2022/2555 | In Scope? Essential vs Important?](/artifacts/eu/nis2-directive/applicability-test.md): A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers. - [Article 21 Control Baseline | EU NIS2 Directive (EU) 2022/2555 | Cybersecurity Risk Management Measures](/artifacts/eu/nis2-directive/article-21-control-baseline.md): A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence. - [Checklist | EU NIS2 Directive (EU) 2022/2555 | Audit-Ready Owners, Evidence, Acceptance Criteria](/artifacts/eu/nis2-directive/checklist.md): An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline. - [Compliance Guide | EU NIS2 Directive (EU) 2022/2555 | Build an Audit-Ready Program](/artifacts/eu/nis2-directive/compliance.md): A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows. - [Deadlines and Compliance Calendar | EU NIS2 Directive (EU) 2022/2555 | 16 January 2023, 17 October 2024, 17 April 2025](/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar.md): A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023. - [Incident Reporting Workflow | EU NIS2 Directive (EU) 2022/2555 | 24h Early Warning, 72h Notification, Final Report (1 Month)](/artifacts/eu/nis2-directive/incident-reporting-workflow.md): A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents. - [Management Body Accountability | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Training, Liability](/artifacts/eu/nis2-directive/management-body-accountability.md): A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work. - [National Transposition Tracker | EU NIS2 Directive (EU) 2022/2555 | How to Track Local Laws, Authorities, Portals](/artifacts/eu/nis2-directive/national-transposition-tracker.md): A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes. - [NIS2 vs ISO/IEC 27001 | How to Reuse Your ISMS for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27001.md): A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review. - [NIS2 vs ISO/IEC 27017 | Cloud Security Mapping for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27017.md): A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations. - [NIS2 vs NIS1 | Directive (EU) 2022/2555 vs Directive (EU) 2016/1148 | Scope, Supervision, Reporting](/artifacts/eu/nis2-directive/nis2-vs-nis1.md): A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works. - [Penalties and Fines | EU NIS2 Directive (EU) 2022/2555 | Article 32-34 Enforcement + Fine Thresholds](/artifacts/eu/nis2-directive/penalties-and-fines.md): A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use. - [Requirements | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Article 21 Controls, Article 23 Reporting](/artifacts/eu/nis2-directive/requirements.md): A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690. - [Scope: Essential vs Important | EU NIS2 Directive (EU) 2022/2555 | Article 3 Classification + What Changes](/artifacts/eu/nis2-directive/scope-essential-vs-important.md): A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3). - [Supply Chain Security Program | EU NIS2 Directive (EU) 2022/2555 | Article 21(d) Supplier Risk + Evidence](/artifacts/eu/nis2-directive/supply-chain-security-program.md): A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/nis2-directive/faq --- --- title: "Incident Reporting Workflow" canonical_url: "https://www.sorena.io/artifacts/eu/nis2-directive/incident-reporting-workflow" source_url: "https://www.sorena.io/artifacts/eu/nis2-directive/incident-reporting-workflow" author: "Sorena AI" description: "A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "NIS2 incident reporting" - "NIS2 reporting timeline" - "NIS2 24 hours early warning" - "NIS2 72 hours incident notification" - "NIS2 final report 1 month" - "Article 23 NIS2" - "NIS2 significant incident definition" - "CSIRT notification NIS2" - "NIS2 competent authority reporting" - "trust service provider NIS2 reporting 24 hours" - "NIS2 incident reporting workflow template" - "NIS2 incident report evidence" - "Implementing Regulation (EU) 2024/2690 significant incident cases" - "NIS2" - "Incident reporting" - "Article 23" - "CSIRT" - "Early warning 24h" - "Notification 72h" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Incident Reporting Workflow A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents. *Article 23* *EU* ## EU NIS2 Directive (EU) 2022/2555 Incident Reporting Workflow Implement 24h early warning, 72h notification, and 1 month final reporting. Output: a regulator-ready workflow with triggers, owners, evidence capture, trust-service handling, and recipient communications. Incident reporting under NIS2 is an operational capability, not a legal footnote. Article 23 requires entities to recognise when an incident is significant, trigger reporting quickly, preserve evidence, and communicate to authorities and affected recipients while facts are still developing. ## Reporting milestones under Article 23(4) The reporting clock starts when the entity becomes aware of a significant incident. Your workflow must support speed without forcing certainty that you do not yet have. - Within 24 hours: send the early warning to the CSIRT or, where applicable, the competent authority. - Within 72 hours: send the incident notification with an initial assessment of severity and impact and indicators of compromise where available. - If requested: provide intermediate status updates. - Within 1 month after the incident notification: send the final report with the likely root cause or threat type, mitigation measures, and cross-border impact where relevant. - If the incident is still ongoing at that deadline: send a progress report instead, then submit the final report within 1 month after the incident is handled. ## What the early warning and incident notification must contain Article 23 and the Commission guidance make the payload logic clear. The early warning is short and directional. The incident notification is the first structured assessment. - Early warning: whether the incident is suspected to be caused by unlawful or malicious acts and whether it is likely to have a cross-border impact, where applicable. - Incident notification: updates to the early warning, initial assessment of severity and impact, and indicators of compromise where available. - Final report: detailed description of severity and impact, likely root cause or threat type, mitigation measures, and any cross-border impact. *Recommended next step* *Placement: after the workflow or playbook section* ## Turn EU NIS2 Directive (EU) 2022/2555 Incident Reporting Workflow into an operational assessment Assessment Autopilot can take EU NIS2 Directive (EU) 2022/2555 Incident Reporting Workflow from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on EU NIS2 Directive (EU) 2022/2555 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU NIS2 Directive (EU) 2022/2555 Incident Reporting Workflow](/solutions/assessment.md): Start from EU NIS2 Directive (EU) 2022/2555 Incident Reporting Workflow and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU NIS2 Directive (EU) 2022/2555](/contact.md): Review your current process, evidence gaps, and next steps for EU NIS2 Directive (EU) 2022/2555 Incident Reporting Workflow. ## Trust service providers and entities covered by Implementing Regulation (EU) 2024/2690 Trust service providers have a faster incident notification rule in Article 23(4). Relevant cross-border digital providers also need to align significance decisions with Implementing Regulation (EU) 2024/2690. - Trust service providers must notify significant incidents affecting trust services within 24 hours of becoming aware of them. - Implementing Regulation (EU) 2024/2690 applies to DNS service providers, TLD name registries, cloud providers, data centre providers, CDN providers, managed service providers, managed security service providers, online marketplace providers, online search engine providers, social networking services platforms, and trust service providers. - For those entities, incident triage should map directly to the significance cases and technical requirements in the implementing regulation. ## Workflow blueprint for real operations Treat reporting as a pipeline with explicit checkpoints. You need clear accountability for awareness time, significance decisions, submissions, and recipient communications. - RACI: incident commander, SOC lead, service owner, legal or compliance, communications, DPO where personal data may be involved, and management escalation. - Evidence capture: awareness timestamp, affected services, logs, indicators of compromise, containment actions, and decision rationale for significance. - Authority route map: national CSIRT, competent authority, single point of contact, and portal access details by country. - Recipient communications: pre-approved notice flow for recipients likely to be adversely affected by the incident. - Post-incident review: corrective actions that feed back into Article 21 controls and management oversight. ## Operational artefacts you should keep ready The best reporting workflow is the one your team can execute at 02:00 without improvising or waiting for a legal rewrite. - Significant incident decision log with time of awareness, thresholds applied, approver, and submission timestamps. - 24h early warning template, 72h incident notification template, progress report template, and final report template. - Authority and portal runbook per jurisdiction, including access control and authentication steps. - Evidence vault structure for logs, screenshots, tickets, forensic records, and outbound notices. - Tabletop results showing that the workflow has been exercised and improved. ## Primary sources - [Directive (EU) 2022/2555 (NIS2) - Official Journal text (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Primary legal text for Article 23 reporting obligations, definitions, and timing. - [Commission Guidelines on Article 4(1) and 4(2) of NIS2 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ%3AC%3A2023%3A328%3AFULL&ref=sorena.io) - Useful explanation of the Article 23 reporting sequence and content when assessing equivalent sector-specific rules. - [Commission Implementing Regulation (EU) 2024/2690 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng?ref=sorena.io) - Further specifies significant incident cases and technical risk management requirements for covered digital providers and trust service providers. - [ENISA CIRAS consolidated reporting information](https://ciras.enisa.europa.eu/ciras-consolidated-reporting?ref=sorena.io) - Operational reference for incident reporting channels and consolidated reporting support. ## Related Topic Guides - [Applicability Test | EU NIS2 Directive (EU) 2022/2555 | In Scope? Essential vs Important?](/artifacts/eu/nis2-directive/applicability-test.md): A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers. - [Article 21 Control Baseline | EU NIS2 Directive (EU) 2022/2555 | Cybersecurity Risk Management Measures](/artifacts/eu/nis2-directive/article-21-control-baseline.md): A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence. - [Checklist | EU NIS2 Directive (EU) 2022/2555 | Audit-Ready Owners, Evidence, Acceptance Criteria](/artifacts/eu/nis2-directive/checklist.md): An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline. - [Compliance Guide | EU NIS2 Directive (EU) 2022/2555 | Build an Audit-Ready Program](/artifacts/eu/nis2-directive/compliance.md): A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows. - [Deadlines and Compliance Calendar | EU NIS2 Directive (EU) 2022/2555 | 16 January 2023, 17 October 2024, 17 April 2025](/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar.md): A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023. - [FAQ | EU NIS2 Directive (EU) 2022/2555 | Scope, Essential vs Important, Article 21, Article 23 (24h/72h)](/artifacts/eu/nis2-directive/faq.md): High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires. - [Management Body Accountability | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Training, Liability](/artifacts/eu/nis2-directive/management-body-accountability.md): A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work. - [National Transposition Tracker | EU NIS2 Directive (EU) 2022/2555 | How to Track Local Laws, Authorities, Portals](/artifacts/eu/nis2-directive/national-transposition-tracker.md): A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes. - [NIS2 vs ISO/IEC 27001 | How to Reuse Your ISMS for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27001.md): A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review. - [NIS2 vs ISO/IEC 27017 | Cloud Security Mapping for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27017.md): A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations. - [NIS2 vs NIS1 | Directive (EU) 2022/2555 vs Directive (EU) 2016/1148 | Scope, Supervision, Reporting](/artifacts/eu/nis2-directive/nis2-vs-nis1.md): A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works. - [Penalties and Fines | EU NIS2 Directive (EU) 2022/2555 | Article 32-34 Enforcement + Fine Thresholds](/artifacts/eu/nis2-directive/penalties-and-fines.md): A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use. - [Requirements | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Article 21 Controls, Article 23 Reporting](/artifacts/eu/nis2-directive/requirements.md): A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690. - [Scope: Essential vs Important | EU NIS2 Directive (EU) 2022/2555 | Article 3 Classification + What Changes](/artifacts/eu/nis2-directive/scope-essential-vs-important.md): A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3). - [Supply Chain Security Program | EU NIS2 Directive (EU) 2022/2555 | Article 21(d) Supplier Risk + Evidence](/artifacts/eu/nis2-directive/supply-chain-security-program.md): A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/nis2-directive/incident-reporting-workflow --- --- title: "Management Body Accountability" canonical_url: "https://www.sorena.io/artifacts/eu/nis2-directive/management-body-accountability" source_url: "https://www.sorena.io/artifacts/eu/nis2-directive/management-body-accountability" author: "Sorena AI" description: "A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "NIS2 management accountability" - "NIS2 Article 20 governance" - "management body approve cybersecurity measures NIS2" - "NIS2 board responsibility" - "NIS2 management training requirement" - "NIS2 management body liability" - "NIS2 governance evidence pack" - "NIS2" - "Article 20" - "Governance" - "Management accountability" - "Training" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Management Body Accountability A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work. *Article 20* *Governance* ## EU NIS2 Directive (EU) 2022/2555 Management Body Accountability Make NIS2 governance real: approval, oversight, training, and evidence. Output: a management operating model that survives audits, incidents, and authority questions. NIS2 moves cybersecurity into the management body. Article 20 requires management bodies to approve the measures taken to comply with Article 21, oversee implementation, and follow training so they can understand cyber risk and the impact on the entity's services. ## What Article 20 requires This is not a policy-signoff exercise. The management body has to show active direction and oversight of the NIS2 control baseline. - Approve the cybersecurity risk management measures taken to comply with Article 21. - Oversee implementation and review whether the measures remain appropriate and proportionate. - Understand that management body members can be held liable under national law for infringements by the entity. - Follow training that gives them sufficient knowledge and skills to identify risks and assess cybersecurity risk management practices and their impact on services. - Offer similar training regularly to employees where relevant. ## A management operating model that works The governance model should make decisions visible. Minutes should show what was reviewed, what risk was accepted, what remediation was ordered, and who owns follow-up. - Define decision rights for risk acceptance, funding, exceptions, and remediation priorities. - Review a cyber dashboard covering top risks, patching, MFA coverage, restore testing, supplier risk, and incident metrics. - Set cadence: monthly metrics review, quarterly risk review, and annual crisis simulation. - Align escalation thresholds with the Article 23 reporting workflow so reporting decisions do not wait for governance confusion. ## Training requirement and evidence Training is mandatory for management body members. Treat it as a recurring control with content that reflects the entity's actual exposure. - Curriculum: NIS2 scope, Article 21 measures, Article 23 reporting, supplier risk, crisis decision-making, and national supervisory context. - Cadence: onboarding, annual refresh, and targeted updates after major incidents or structural change. - Evidence: attendance logs, materials, assessments, and action items tracked in governance minutes. ## Evidence pack you should be able to produce quickly Governance evidence is often requested early because it shows whether cybersecurity is truly being steered at management level. - Minutes approving the Article 21 baseline and major changes to it. - RACI and delegated authority model for risk, exceptions, supplier approvals, and incident escalation. - Management review minutes with KPI trends, exceptions, and remediation decisions. - Training records, curriculum, and refresh schedule. - Post-incident reviews showing management decisions and follow-through. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU NIS2 Directive (EU) 2022/2555 Management Body Accountability as a cited research workflow Research Copilot can take EU NIS2 Directive (EU) 2022/2555 Management Body Accountability from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU NIS2 Directive (EU) 2022/2555 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU NIS2 Directive (EU) 2022/2555 Management Body Accountability](/solutions/research-copilot.md): Start from EU NIS2 Directive (EU) 2022/2555 Management Body Accountability and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU NIS2 Directive (EU) 2022/2555](/contact.md): Review your current process, evidence gaps, and next steps for EU NIS2 Directive (EU) 2022/2555 Management Body Accountability. ## Primary sources - [Directive (EU) 2022/2555 (NIS2) - Official Journal text (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Primary source for Article 20 governance requirements and management body training/liability language. - [European Commission - NIS2 Directive overview (policy page)](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive?ref=sorena.io) - Context and implementation resources; validate national liability rules and governance expectations through transposition. ## Related Topic Guides - [Applicability Test | EU NIS2 Directive (EU) 2022/2555 | In Scope? Essential vs Important?](/artifacts/eu/nis2-directive/applicability-test.md): A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers. - [Article 21 Control Baseline | EU NIS2 Directive (EU) 2022/2555 | Cybersecurity Risk Management Measures](/artifacts/eu/nis2-directive/article-21-control-baseline.md): A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence. - [Checklist | EU NIS2 Directive (EU) 2022/2555 | Audit-Ready Owners, Evidence, Acceptance Criteria](/artifacts/eu/nis2-directive/checklist.md): An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline. - [Compliance Guide | EU NIS2 Directive (EU) 2022/2555 | Build an Audit-Ready Program](/artifacts/eu/nis2-directive/compliance.md): A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows. - [Deadlines and Compliance Calendar | EU NIS2 Directive (EU) 2022/2555 | 16 January 2023, 17 October 2024, 17 April 2025](/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar.md): A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023. - [FAQ | EU NIS2 Directive (EU) 2022/2555 | Scope, Essential vs Important, Article 21, Article 23 (24h/72h)](/artifacts/eu/nis2-directive/faq.md): High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires. - [Incident Reporting Workflow | EU NIS2 Directive (EU) 2022/2555 | 24h Early Warning, 72h Notification, Final Report (1 Month)](/artifacts/eu/nis2-directive/incident-reporting-workflow.md): A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents. - [National Transposition Tracker | EU NIS2 Directive (EU) 2022/2555 | How to Track Local Laws, Authorities, Portals](/artifacts/eu/nis2-directive/national-transposition-tracker.md): A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes. - [NIS2 vs ISO/IEC 27001 | How to Reuse Your ISMS for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27001.md): A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review. - [NIS2 vs ISO/IEC 27017 | Cloud Security Mapping for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27017.md): A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations. - [NIS2 vs NIS1 | Directive (EU) 2022/2555 vs Directive (EU) 2016/1148 | Scope, Supervision, Reporting](/artifacts/eu/nis2-directive/nis2-vs-nis1.md): A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works. - [Penalties and Fines | EU NIS2 Directive (EU) 2022/2555 | Article 32-34 Enforcement + Fine Thresholds](/artifacts/eu/nis2-directive/penalties-and-fines.md): A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use. - [Requirements | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Article 21 Controls, Article 23 Reporting](/artifacts/eu/nis2-directive/requirements.md): A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690. - [Scope: Essential vs Important | EU NIS2 Directive (EU) 2022/2555 | Article 3 Classification + What Changes](/artifacts/eu/nis2-directive/scope-essential-vs-important.md): A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3). - [Supply Chain Security Program | EU NIS2 Directive (EU) 2022/2555 | Article 21(d) Supplier Risk + Evidence](/artifacts/eu/nis2-directive/supply-chain-security-program.md): A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/nis2-directive/management-body-accountability --- --- title: "National Transposition Tracker" canonical_url: "https://www.sorena.io/artifacts/eu/nis2-directive/national-transposition-tracker" source_url: "https://www.sorena.io/artifacts/eu/nis2-directive/national-transposition-tracker" author: "Sorena AI" description: "A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "NIS2 transposition tracker" - "NIS2 national implementation" - "NIS2 competent authority" - "NIS2 CSIRT reporting portal" - "NIS2 member state transposition status" - "NIS2 local law tracker" - "NIS2 multi country compliance" - "NIS2" - "Transposition" - "Competent authority" - "CSIRT" - "Multi-country compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # National Transposition Tracker A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes. *Transposition* *EU* ## EU NIS2 Directive (EU) 2022/2555 National Transposition Tracker Track Member State implementation, authorities, and reporting routes. Output: a repeatable country overlay tracker with legal status, authority routes, and portal details. NIS2 is implemented through national law and supervision. Even a strong EU baseline is not enough on its own. You need a country overlay that tracks local law, authority routes, incident portals, and any registration or listing mechanics that affect your entity. ## What the Commission tracker tells you and what it does not The Commission tracker is the right starting point for transposition monitoring, but the page itself says it is based on information provided by Member States and is without prejudice to the formal assessment of compliance. - 7 May 2025: the Commission sent reasoned opinions to 19 Member States for failing to notify full transposition. - Those 19 Member States were Bulgaria, Czechia, Denmark, Germany, Estonia, Ireland, Spain, France, Cyprus, Latvia, Luxembourg, Hungary, the Netherlands, Austria, Poland, Portugal, Slovenia, Finland, and Sweden. - 1 July 2025: the transposition tracker page showed its latest update date. - Use the tracker as the EU-level state-of-play page, then confirm the operational details on national authority and CSIRT pages. ## What to track per Member State A good country overlay is short, explicit, and operational. It should tell engineers, counsel, and incident responders exactly what changes in that country. - Competent authority, CSIRT, and single point of contact names, URLs, contacts, and submission channels. - Scope and identification mechanics: registration duty, entity-list logic, authority notices, or sector-specific designation model. - Reporting route: where early warnings, notifications, and final reports go, including language, format, and portal constraints. - Local penalties and enforcement approach, including whether national law adds periodic penalty payments or officer-level measures. - Any sector overlays or Article 4 equivalence issues that affect how NIS2 applies. ## How to maintain the tracker Tracking must have an owner and a review cycle. Otherwise, your runbooks drift away from the law and from the actual reporting channels. - Assign one accountable owner per country overlay and one backup owner. - Review high-risk countries monthly and all active countries at least quarterly. - When an overlay changes, update the scope memo, incident reporting runbook, and authority contact list immediately. - Store a last-verified date and source links for each overlay so the evidence survives scrutiny. *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU NIS2 Directive (EU) 2022/2555 National Transposition Tracker as a cited research workflow Research Copilot can take EU NIS2 Directive (EU) 2022/2555 National Transposition Tracker from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU NIS2 Directive (EU) 2022/2555 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU NIS2 Directive (EU) 2022/2555 National Transposition Tracker](/solutions/research-copilot.md): Start from EU NIS2 Directive (EU) 2022/2555 National Transposition Tracker and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU NIS2 Directive (EU) 2022/2555](/contact.md): Review your current process, evidence gaps, and next steps for EU NIS2 Directive (EU) 2022/2555 National Transposition Tracker. ## Primary sources - [European Commission - NIS2 transposition tracker](https://digital-strategy.ec.europa.eu/en/policies/nis-transposition?ref=sorena.io) - Official EU state-of-play page that records the 7 May 2025 reasoned opinions and the last update date shown on the page. - [Directive (EU) 2022/2555 (NIS2) - Official Journal text (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Primary legal baseline for transposition timing, entity lists, and supervisory architecture. - [European Commission - NIS2 Directive overview](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive?ref=sorena.io) - Official overview page and gateway to implementation resources. ## Related Topic Guides - [Applicability Test | EU NIS2 Directive (EU) 2022/2555 | In Scope? Essential vs Important?](/artifacts/eu/nis2-directive/applicability-test.md): A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers. - [Article 21 Control Baseline | EU NIS2 Directive (EU) 2022/2555 | Cybersecurity Risk Management Measures](/artifacts/eu/nis2-directive/article-21-control-baseline.md): A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence. - [Checklist | EU NIS2 Directive (EU) 2022/2555 | Audit-Ready Owners, Evidence, Acceptance Criteria](/artifacts/eu/nis2-directive/checklist.md): An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline. - [Compliance Guide | EU NIS2 Directive (EU) 2022/2555 | Build an Audit-Ready Program](/artifacts/eu/nis2-directive/compliance.md): A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows. - [Deadlines and Compliance Calendar | EU NIS2 Directive (EU) 2022/2555 | 16 January 2023, 17 October 2024, 17 April 2025](/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar.md): A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023. - [FAQ | EU NIS2 Directive (EU) 2022/2555 | Scope, Essential vs Important, Article 21, Article 23 (24h/72h)](/artifacts/eu/nis2-directive/faq.md): High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires. - [Incident Reporting Workflow | EU NIS2 Directive (EU) 2022/2555 | 24h Early Warning, 72h Notification, Final Report (1 Month)](/artifacts/eu/nis2-directive/incident-reporting-workflow.md): A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents. - [Management Body Accountability | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Training, Liability](/artifacts/eu/nis2-directive/management-body-accountability.md): A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work. - [NIS2 vs ISO/IEC 27001 | How to Reuse Your ISMS for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27001.md): A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review. - [NIS2 vs ISO/IEC 27017 | Cloud Security Mapping for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27017.md): A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations. - [NIS2 vs NIS1 | Directive (EU) 2022/2555 vs Directive (EU) 2016/1148 | Scope, Supervision, Reporting](/artifacts/eu/nis2-directive/nis2-vs-nis1.md): A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works. - [Penalties and Fines | EU NIS2 Directive (EU) 2022/2555 | Article 32-34 Enforcement + Fine Thresholds](/artifacts/eu/nis2-directive/penalties-and-fines.md): A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use. - [Requirements | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Article 21 Controls, Article 23 Reporting](/artifacts/eu/nis2-directive/requirements.md): A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690. - [Scope: Essential vs Important | EU NIS2 Directive (EU) 2022/2555 | Article 3 Classification + What Changes](/artifacts/eu/nis2-directive/scope-essential-vs-important.md): A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3). - [Supply Chain Security Program | EU NIS2 Directive (EU) 2022/2555 | Article 21(d) Supplier Risk + Evidence](/artifacts/eu/nis2-directive/supply-chain-security-program.md): A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/nis2-directive/national-transposition-tracker --- --- title: "NIS2 vs ISO/IEC 27001" canonical_url: "https://www.sorena.io/artifacts/eu/nis2-directive/nis2-vs-iso-27001" source_url: "https://www.sorena.io/artifacts/eu/nis2-directive/nis2-vs-iso-27001" author: "Sorena AI" description: "A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "NIS2 vs ISO 27001" - "ISO 27001 NIS2 mapping" - "NIS2 ISO 27001 compliance" - "reuse ISMS for NIS2" - "NIS2 Article 21 controls ISO 27001" - "NIS2 incident reporting ISO 27001" - "NIS2 governance Article 20 ISO 27001 management review" - "NIS2" - "ISO 27001" - "ISMS" - "Evidence mapping" - "Risk management" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIS2 vs ISO/IEC 27001 A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review. *Mapping* *ISO 27001* ## EU NIS2 Directive (EU) 2022/2555 NIS2 vs ISO/IEC 27001 Reuse your ISMS to implement NIS2 faster (without becoming generic). Output: an evidence reuse plan + a gap list for NIS2-specific obligations (especially reporting timelines and supervision readiness). If you already run an ISO/IEC 27001-style ISMS, you have an advantage: risk assessment, policies, internal audits, management reviews, and corrective actions are exactly the kinds of evidence regulators expect to see. The key is to map your ISMS into NIS2's Article 20 governance, Article 21 control baseline, and Article 23 incident reporting timelines. ## Where ISO/IEC 27001 evidence helps most for NIS2 NIS2 is not "ISO 27001 with a new label". But your ISMS can cover a large part of the control and evidence foundation. - Risk method + risk register: supports Article 21 risk analysis and proportionality decisions. - Policy framework + control statements: supports Article 21(2)(a) and broader control baseline documentation. - Internal audits + corrective actions: directly support Article 21(2)(f) effectiveness assessment expectations. - Management review minutes: supports Article 20 oversight evidence and accountability. - Supplier management artefacts: support Article 21(d) supply chain security (if scoped and evidenced). ## The usual gaps (what teams must add for NIS2-specific compliance) Most ISO programs fail NIS2 readiness in two places: reporting timelines and supervision readiness (evidence speed + completeness). - Incident reporting pipeline: Article 23 requires 24h early warning, 72h notification, and final report within 1 month - with templates and decision logs. - Authority routing: you must know your CSIRT/competent authority route and portal per Member State (transposition overlay). - Service-impact classification: define "significant incident" triage thresholds tied to service provision and user impact. - Evidence vault: ISO artefacts exist, but NIS2 supervision often expects fast retrieval and explicit linkage to Article 21 a-j measures. ## A practical mapping method (how to avoid "checkbox mapping") Map by outcomes and evidence, not by clause-to-clause guesswork. The goal is: every NIS2 requirement has an owner, KPI, and evidence link. - Build an Article 21 control register: a-j measures -> control IDs -> owners -> KPIs -> evidence links. - Attach existing ISMS artefacts as evidence where they truly demonstrate operation (audit results, tests, logs, training). - Add NIS2 reporting artefacts: 24h/72h/final templates, significant incident decision logs, and recipient communication playbooks. - Run an incident tabletop and a supervision readiness drill (produce evidence pack in < 24 hours). ## Special case: digital providers covered by Implementing Regulation (EU) 2024/2690 For certain digital infrastructure providers and trust service providers, the Commission adopted a more prescriptive implementing regulation. It references standards such as ISO/IEC 27001 as part of its baseline, but you still need to implement the specific technical/methodological requirements and significant-incident criteria. - Confirm whether your service model falls under the implementing regulation (DNS/TLD, cloud, data centres, CDNs, MSP/MSSP, marketplaces/search/social networks, trust services). - Use ENISA guidance to translate annex requirements into concrete evidence items. - Align incident classification triggers with the implementing regulation's "significant incident" cases and your Article 23 workflow. *Recommended next step* *Placement: after the comparison section* ## Use EU NIS2 Directive (EU) 2022/2555 NIS2 vs ISO/IEC 27001 as a cited research workflow Research Copilot can take EU NIS2 Directive (EU) 2022/2555 NIS2 vs ISO/IEC 27001 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU NIS2 Directive (EU) 2022/2555 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU NIS2 Directive (EU) 2022/2555 NIS2 vs ISO/IEC 27001](/solutions/research-copilot.md): Start from EU NIS2 Directive (EU) 2022/2555 NIS2 vs ISO/IEC 27001 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU NIS2 Directive (EU) 2022/2555](/contact.md): Review your current process, evidence gaps, and next steps for EU NIS2 Directive (EU) 2022/2555 NIS2 vs ISO/IEC 27001. ## Primary sources - [Directive (EU) 2022/2555 (NIS2) - Official Journal text (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Primary source for Articles 20-23 obligations and supervision structure that your ISMS evidence must support. - [Commission Implementing Regulation (EU) 2024/2690 (Official Journal via EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ%3AL_202402690&ref=sorena.io) - Prescriptive requirements for certain digital providers and trust services; references standards such as ISO/IEC 27001 in its baseline approach. - [ENISA - NIS2 technical implementation guidance](https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance?ref=sorena.io) - Actionable guidance for implementing the Commission implementing regulation requirements and building evidence. ## Related Topic Guides - [Applicability Test | EU NIS2 Directive (EU) 2022/2555 | In Scope? Essential vs Important?](/artifacts/eu/nis2-directive/applicability-test.md): A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers. - [Article 21 Control Baseline | EU NIS2 Directive (EU) 2022/2555 | Cybersecurity Risk Management Measures](/artifacts/eu/nis2-directive/article-21-control-baseline.md): A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence. - [Checklist | EU NIS2 Directive (EU) 2022/2555 | Audit-Ready Owners, Evidence, Acceptance Criteria](/artifacts/eu/nis2-directive/checklist.md): An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline. - [Compliance Guide | EU NIS2 Directive (EU) 2022/2555 | Build an Audit-Ready Program](/artifacts/eu/nis2-directive/compliance.md): A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows. - [Deadlines and Compliance Calendar | EU NIS2 Directive (EU) 2022/2555 | 16 January 2023, 17 October 2024, 17 April 2025](/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar.md): A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023. - [FAQ | EU NIS2 Directive (EU) 2022/2555 | Scope, Essential vs Important, Article 21, Article 23 (24h/72h)](/artifacts/eu/nis2-directive/faq.md): High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires. - [Incident Reporting Workflow | EU NIS2 Directive (EU) 2022/2555 | 24h Early Warning, 72h Notification, Final Report (1 Month)](/artifacts/eu/nis2-directive/incident-reporting-workflow.md): A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents. - [Management Body Accountability | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Training, Liability](/artifacts/eu/nis2-directive/management-body-accountability.md): A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work. - [National Transposition Tracker | EU NIS2 Directive (EU) 2022/2555 | How to Track Local Laws, Authorities, Portals](/artifacts/eu/nis2-directive/national-transposition-tracker.md): A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes. - [NIS2 vs ISO/IEC 27017 | Cloud Security Mapping for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27017.md): A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations. - [NIS2 vs NIS1 | Directive (EU) 2022/2555 vs Directive (EU) 2016/1148 | Scope, Supervision, Reporting](/artifacts/eu/nis2-directive/nis2-vs-nis1.md): A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works. - [Penalties and Fines | EU NIS2 Directive (EU) 2022/2555 | Article 32-34 Enforcement + Fine Thresholds](/artifacts/eu/nis2-directive/penalties-and-fines.md): A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use. - [Requirements | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Article 21 Controls, Article 23 Reporting](/artifacts/eu/nis2-directive/requirements.md): A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690. - [Scope: Essential vs Important | EU NIS2 Directive (EU) 2022/2555 | Article 3 Classification + What Changes](/artifacts/eu/nis2-directive/scope-essential-vs-important.md): A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3). - [Supply Chain Security Program | EU NIS2 Directive (EU) 2022/2555 | Article 21(d) Supplier Risk + Evidence](/artifacts/eu/nis2-directive/supply-chain-security-program.md): A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/nis2-directive/nis2-vs-iso-27001 --- --- title: "NIS2 vs ISO/IEC 27017" canonical_url: "https://www.sorena.io/artifacts/eu/nis2-directive/nis2-vs-iso-27017" source_url: "https://www.sorena.io/artifacts/eu/nis2-directive/nis2-vs-iso-27017" author: "Sorena AI" description: "A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "NIS2 vs ISO 27017" - "NIS2 cloud security" - "NIS2 cloud service provider requirements" - "NIS2 Article 21 cloud controls" - "NIS2 incident reporting cloud provider" - "Implementing Regulation (EU) 2024/2690 cloud requirements" - "ISO 27017 NIS2 mapping" - "NIS2" - "ISO 27017" - "Cloud security" - "Implementing Regulation (EU) 2024/2690" - "Evidence mapping" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIS2 vs ISO/IEC 27017 A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations. *Mapping* *Cloud* ## EU NIS2 Directive (EU) 2022/2555 NIS2 vs ISO/IEC 27017 Cloud security evidence mapping to NIS2 controls and reporting. Output: a practical gap list and evidence pack for cloud and cloud-dependent organisations. Cloud environments concentrate risk: identity, misconfiguration, shared responsibility, and supplier dependencies. NIS2 expects you to manage those risks through Article 21 controls and to report significant incidents under Article 23. If you already use ISO/IEC 27017-style cloud controls, you can reuse many artefacts - but you must align them to NIS2 reporting timelines and supervision readiness. ## How NIS2 applies to cloud realities (what to make explicit) Whether you are a cloud provider or a cloud customer in-scope under NIS2, you need clarity on responsibilities and evidence. - Define shared responsibility boundaries: who owns IAM, logging, vulnerability handling, backups, and incident communications. - Treat supply chain as first-class: managed services, SaaS dependencies, and critical cloud regions/providers are part of your Article 21(d) risk. - Make incident reporting operational: "becoming aware" starts the 24h/72h clock; evidence capture must work in distributed cloud systems. ## Evidence reuse patterns (what ISO/IEC 27017-style controls typically cover) Many cloud control artefacts are directly reusable as evidence - if they're operational and current. - Cloud IAM: MFA coverage, privileged access controls, and periodic access reviews support Article 21(i)/(j). - Logging/monitoring: central logging, detection rules, and alert triage support incident handling and effectiveness assessment. - Configuration management: hardened baselines and change control support secure acquisition/development/maintenance. - Resilience: backup/restore tests, region failover, and DR exercises support Article 21(c). ## Typical gaps to close for NIS2 (cloud context) The gaps are usually not technical - they're governance, reporting, and evidence linkage. - Explicit mapping to Article 21(2) a-j with owners, KPIs, and evidence links. - Supplier incident communications: contact paths, notification expectations, and required payload fields for providers. - Significant incident triage thresholds tied to service provision impact and user harm. - Supervision readiness: ability to produce evidence quickly (audit reports, logs, tests, training, and governance minutes). ## Implementing Regulation (EU) 2024/2690 overlay (for certain digital providers) For cloud computing service providers, data centre service providers, CDNs, managed service providers, managed security service providers, and certain other digital providers, the Commission adopted an implementing regulation specifying technical and methodological requirements and significant-incident cases. - If you are a covered provider, treat the implementing regulation as prescriptive baseline requirements layered on Article 21. - Use ENISA guidance to translate annex requirements into evidence items and testing procedures. - Align incident classification triggers with the implementing regulation's significant-incident cases and your Article 23 workflow. *Recommended next step* *Placement: after the comparison section* ## Use EU NIS2 Directive (EU) 2022/2555 NIS2 vs ISO/IEC 27017 as a cited research workflow Research Copilot can take EU NIS2 Directive (EU) 2022/2555 NIS2 vs ISO/IEC 27017 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU NIS2 Directive (EU) 2022/2555 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU NIS2 Directive (EU) 2022/2555 NIS2 vs ISO/IEC 27017](/solutions/research-copilot.md): Start from EU NIS2 Directive (EU) 2022/2555 NIS2 vs ISO/IEC 27017 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU NIS2 Directive (EU) 2022/2555](/contact.md): Review your current process, evidence gaps, and next steps for EU NIS2 Directive (EU) 2022/2555 NIS2 vs ISO/IEC 27017. ## Primary sources - [Directive (EU) 2022/2555 (NIS2) - Official Journal text (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Primary source for Article 21 controls and Article 23 reporting obligations that apply in cloud contexts. - [Commission Implementing Regulation (EU) 2024/2690 (Official Journal via EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ%3AL_202402690&ref=sorena.io) - Specifies requirements for certain digital providers including cloud/data centres/CDNs/MSPs/MSSPs and further specifies significant-incident cases. - [ENISA - NIS2 technical implementation guidance](https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance?ref=sorena.io) - Actionable guidance and evidence examples for entities covered by the implementing regulation. ## Related Topic Guides - [Applicability Test | EU NIS2 Directive (EU) 2022/2555 | In Scope? Essential vs Important?](/artifacts/eu/nis2-directive/applicability-test.md): A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers. - [Article 21 Control Baseline | EU NIS2 Directive (EU) 2022/2555 | Cybersecurity Risk Management Measures](/artifacts/eu/nis2-directive/article-21-control-baseline.md): A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence. - [Checklist | EU NIS2 Directive (EU) 2022/2555 | Audit-Ready Owners, Evidence, Acceptance Criteria](/artifacts/eu/nis2-directive/checklist.md): An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline. - [Compliance Guide | EU NIS2 Directive (EU) 2022/2555 | Build an Audit-Ready Program](/artifacts/eu/nis2-directive/compliance.md): A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows. - [Deadlines and Compliance Calendar | EU NIS2 Directive (EU) 2022/2555 | 16 January 2023, 17 October 2024, 17 April 2025](/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar.md): A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023. - [FAQ | EU NIS2 Directive (EU) 2022/2555 | Scope, Essential vs Important, Article 21, Article 23 (24h/72h)](/artifacts/eu/nis2-directive/faq.md): High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires. - [Incident Reporting Workflow | EU NIS2 Directive (EU) 2022/2555 | 24h Early Warning, 72h Notification, Final Report (1 Month)](/artifacts/eu/nis2-directive/incident-reporting-workflow.md): A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents. - [Management Body Accountability | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Training, Liability](/artifacts/eu/nis2-directive/management-body-accountability.md): A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work. - [National Transposition Tracker | EU NIS2 Directive (EU) 2022/2555 | How to Track Local Laws, Authorities, Portals](/artifacts/eu/nis2-directive/national-transposition-tracker.md): A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes. - [NIS2 vs ISO/IEC 27001 | How to Reuse Your ISMS for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27001.md): A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review. - [NIS2 vs NIS1 | Directive (EU) 2022/2555 vs Directive (EU) 2016/1148 | Scope, Supervision, Reporting](/artifacts/eu/nis2-directive/nis2-vs-nis1.md): A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works. - [Penalties and Fines | EU NIS2 Directive (EU) 2022/2555 | Article 32-34 Enforcement + Fine Thresholds](/artifacts/eu/nis2-directive/penalties-and-fines.md): A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use. - [Requirements | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Article 21 Controls, Article 23 Reporting](/artifacts/eu/nis2-directive/requirements.md): A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690. - [Scope: Essential vs Important | EU NIS2 Directive (EU) 2022/2555 | Article 3 Classification + What Changes](/artifacts/eu/nis2-directive/scope-essential-vs-important.md): A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3). - [Supply Chain Security Program | EU NIS2 Directive (EU) 2022/2555 | Article 21(d) Supplier Risk + Evidence](/artifacts/eu/nis2-directive/supply-chain-security-program.md): A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/nis2-directive/nis2-vs-iso-27017 --- --- title: "NIS2 vs NIS1" canonical_url: "https://www.sorena.io/artifacts/eu/nis2-directive/nis2-vs-nis1" source_url: "https://www.sorena.io/artifacts/eu/nis2-directive/nis2-vs-nis1" author: "Sorena AI" description: "A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "NIS2 vs NIS1" - "Directive 2022/2555 vs 2016/1148" - "NIS2 scope changes" - "NIS2 reporting 24 hours 72 hours" - "NIS2 Article 21 controls" - "NIS2 essential vs important" - "NIS2 supervision enforcement" - "migrate from NIS1 to NIS2" - "NIS2" - "NIS1" - "Comparison" - "Supervision" - "Incident reporting" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIS2 vs NIS1 A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works. *Comparison* *EU* ## EU Cybersecurity Law NIS2 vs NIS1 Understand what changed and how to migrate your program. Output: a migration plan that reuses NIS1 artefacts where possible and closes NIS2 gaps. NIS2 (Directive (EU) 2022/2555) replaced NIS1 (Directive (EU) 2016/1148) and raised the EU's cybersecurity ambition through wider scope, clearer requirements, stronger governance, and stronger supervision tools. Use this page to map changes into your implementation plan. ## What changed at a high level NIS2 is broader and more explicit. The biggest practical shift is that compliance must be evidenced with owned controls and repeatable reporting workflows. - Wider scope and more sectors: NIS2 extends coverage across more critical sectors and digital services. - Clearer classification: essential vs important entities, with Member State lists and identification mechanisms. - Stronger governance: management body accountability and training requirements (Article 20). - Stronger and more specific reporting: Article 23 timelines (24h early warning, 72h notification, final report within 1 month). - Stronger supervision/enforcement: explicit audit, scan, and enforcement powers with fine thresholds tied to Article 21/23 infringements. ## Controls and evidence (what you need to add if you had a "NIS1 policy binder") Most NIS1 programs are policy-heavy. NIS2 expects measurable controls, effectiveness testing, and evidence readiness. - Build an Article 21 control register mapping a-j measures to control IDs, owners, KPIs, and evidence links. - Add effectiveness testing cadence (Article 21(2)(f)): audits, scans, control tests, and remediation tracking. - Strengthen supply chain security as a first-class control domain (Article 21(d)). - Integrate incident reporting templates, decision logs, and evidence capture into operations (Article 23). ## Migration plan (what to reuse vs rebuild) You can reuse many artefacts - but you must tighten ownership, metrics, and reporting workflows. - Reuse: incident response policies, asset inventories, BC/DR plans, and vendor management structures. - Rebuild/upgrade: reporting timelines/templates and triage thresholds; management oversight cadence; evidence vault indexing; control KPIs. - Add: classification memo (essential vs important), transposition overlays per Member State, and audit-ready control testing evidence. - Validate: national authority/CSIRT reporting routes and portals before an incident happens. *Recommended next step* *Placement: after the comparison section* ## Use EU Cybersecurity Law NIS2 vs NIS1 as a cited research workflow Research Copilot can take EU Cybersecurity Law NIS2 vs NIS1 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Cybersecurity Law can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Cybersecurity Law NIS2 vs NIS1](/solutions/research-copilot.md): Start from EU Cybersecurity Law NIS2 vs NIS1 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Cybersecurity Law](/contact.md): Review your current process, evidence gaps, and next steps for EU Cybersecurity Law NIS2 vs NIS1. ## Primary sources - [Directive (EU) 2022/2555 (NIS2) - Official Journal text (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Primary source for NIS2 obligations, supervision, and reporting timelines. - [Directive (EU) 2016/1148 (NIS1) - Official Journal text (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2016/1148/oj/eng?ref=sorena.io) - Primary source for the predecessor framework (no longer in force). - [European Commission - NIS2 Directive overview (policy page)](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive?ref=sorena.io) - Implementation context and summary of major changes introduced by NIS2. ## Related Topic Guides - [Applicability Test | EU NIS2 Directive (EU) 2022/2555 | In Scope? Essential vs Important?](/artifacts/eu/nis2-directive/applicability-test.md): A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers. - [Article 21 Control Baseline | EU NIS2 Directive (EU) 2022/2555 | Cybersecurity Risk Management Measures](/artifacts/eu/nis2-directive/article-21-control-baseline.md): A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence. - [Checklist | EU NIS2 Directive (EU) 2022/2555 | Audit-Ready Owners, Evidence, Acceptance Criteria](/artifacts/eu/nis2-directive/checklist.md): An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline. - [Compliance Guide | EU NIS2 Directive (EU) 2022/2555 | Build an Audit-Ready Program](/artifacts/eu/nis2-directive/compliance.md): A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows. - [Deadlines and Compliance Calendar | EU NIS2 Directive (EU) 2022/2555 | 16 January 2023, 17 October 2024, 17 April 2025](/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar.md): A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023. - [FAQ | EU NIS2 Directive (EU) 2022/2555 | Scope, Essential vs Important, Article 21, Article 23 (24h/72h)](/artifacts/eu/nis2-directive/faq.md): High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires. - [Incident Reporting Workflow | EU NIS2 Directive (EU) 2022/2555 | 24h Early Warning, 72h Notification, Final Report (1 Month)](/artifacts/eu/nis2-directive/incident-reporting-workflow.md): A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents. - [Management Body Accountability | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Training, Liability](/artifacts/eu/nis2-directive/management-body-accountability.md): A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work. - [National Transposition Tracker | EU NIS2 Directive (EU) 2022/2555 | How to Track Local Laws, Authorities, Portals](/artifacts/eu/nis2-directive/national-transposition-tracker.md): A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes. - [NIS2 vs ISO/IEC 27001 | How to Reuse Your ISMS for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27001.md): A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review. - [NIS2 vs ISO/IEC 27017 | Cloud Security Mapping for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27017.md): A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations. - [Penalties and Fines | EU NIS2 Directive (EU) 2022/2555 | Article 32-34 Enforcement + Fine Thresholds](/artifacts/eu/nis2-directive/penalties-and-fines.md): A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use. - [Requirements | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Article 21 Controls, Article 23 Reporting](/artifacts/eu/nis2-directive/requirements.md): A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690. - [Scope: Essential vs Important | EU NIS2 Directive (EU) 2022/2555 | Article 3 Classification + What Changes](/artifacts/eu/nis2-directive/scope-essential-vs-important.md): A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3). - [Supply Chain Security Program | EU NIS2 Directive (EU) 2022/2555 | Article 21(d) Supplier Risk + Evidence](/artifacts/eu/nis2-directive/supply-chain-security-program.md): A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/nis2-directive/nis2-vs-nis1 --- --- title: "Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/nis2-directive/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/nis2-directive/penalties-and-fines" author: "Sorena AI" description: "A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "NIS2 fines" - "NIS2 penalties" - "NIS2 enforcement" - "Article 34 NIS2 fines 2% turnover 10 million" - "Article 34 NIS2 fines 1.4% turnover 7 million" - "Article 32 supervision essential entities" - "Article 33 supervision important entities" - "NIS2 enforcement measures" - "NIS2" - "Enforcement" - "Fines" - "Article 34" - "Supervision" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Penalties and Fines A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use. *Enforcement* *EU* ## EU NIS2 Directive (EU) 2022/2555 Penalties and Fines Understand supervision powers and fine thresholds tied to Article 21 and Article 23. Output: an enforcement-risk mitigation plan based on evidence, governance, and rapid incident reporting. Penalties are the "why" behind evidence. NIS2 gives competent authorities broad supervision and enforcement powers, and ties administrative fines to infringements of Article 21 (controls) and Article 23 (reporting). Use this page to understand the enforcement surface and to build an evidence-first mitigation plan. ## Supervision: essential vs important entities (what to expect) Both essential and important entities must implement Article 21 controls and Article 23 reporting. The difference is how supervision is applied. - Essential entities: authorities have powers including on-site inspections, off-site supervision, regular/targeted/ad hoc audits, security scans, information requests, and evidence requests (Article 32). - Important entities: authorities act when provided with evidence/indications of non-compliance and use ex post supervisory measures such as inspections, targeted audits, scans, and evidence requests (Article 33). - Practical implication: essential entities should assume more proactive interaction and maintain a continuously current evidence pack. ## Enforcement measures (what authorities can require) Authorities can issue warnings, adopt binding instructions, order remediation, require compliance with Article 21/23 in specified manner/timeframes, order communications to affected recipients, require implementation of audit recommendations, and make aspects of infringements public. - Authorities can order you to implement Article 21 measures or fulfil Article 23 reporting obligations within a specified period. - Authorities can request documented policies and evidence (including audit results and underlying evidence). - Authorities can designate a monitoring officer (for essential entities) to oversee compliance with Articles 21 and 23 for a determined period. - Enforcement actions consider seriousness, duration, repeat violations, failure to notify/remedy incidents, obstruction, and false information, among other factors. *Recommended next step* *Placement: after the enforcement section* ## Use EU NIS2 Directive (EU) 2022/2555 Penalties and Fines as a cited research workflow Research Copilot can take EU NIS2 Directive (EU) 2022/2555 Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU NIS2 Directive (EU) 2022/2555 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU NIS2 Directive (EU) 2022/2555 Penalties and Fines](/solutions/research-copilot.md): Start from EU NIS2 Directive (EU) 2022/2555 Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU NIS2 Directive (EU) 2022/2555](/contact.md): Review your current process, evidence gaps, and next steps for EU NIS2 Directive (EU) 2022/2555 Penalties and Fines. ## Administrative fines (Article 34) - the EU-level thresholds Article 34 sets minimum maxima for fines when essential or important entities infringe Article 21 or Article 23. National law transposition determines the final regime, but these thresholds anchor expectations. - Essential entities: maximum of at least EUR 10,000,000 or at least 2% of total worldwide annual turnover (whichever is higher). - Important entities: maximum of at least EUR 7,000,000 or at least 1.4% of total worldwide annual turnover (whichever is higher). - Fines are imposed in addition to other enforcement measures; some Member States may use periodic penalty payments to compel compliance. - Member States lay down penalties for national measures and notify the Commission by a specified date (Article 36). ## Mitigation playbook (reduce enforcement risk with evidence, not rhetoric) The fastest way to reduce enforcement risk is to build an evidence pack that demonstrates control effectiveness and rapid reporting capability. - Implement Article 21 control register with owners, KPIs, and control tests (Article 21(2)(f)). - Run incident reporting table-top exercises and keep decision logs (significant incident triggers + 24h/72h templates). - Maintain management oversight evidence (Article 20): approvals, training records, and risk acceptance decisions. - Keep remediation tracking and exception register with expiry dates and management approval. - Validate national reporting routes and portals via transposition overlays before an incident happens. ## Primary sources - [Directive (EU) 2022/2555 (NIS2) - Official Journal text (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Primary source for Articles 32-34 supervision, enforcement measures, and fine thresholds tied to Article 21/23 infringements. - [European Commission - NIS2 transposition tracker (interactive map)](https://digital-strategy.ec.europa.eu/en/policies/nis-transposition?ref=sorena.io) - Use to monitor national transposition and locate Member State implementation pages that define the local penalty regime. ## Related Topic Guides - [Applicability Test | EU NIS2 Directive (EU) 2022/2555 | In Scope? Essential vs Important?](/artifacts/eu/nis2-directive/applicability-test.md): A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers. - [Article 21 Control Baseline | EU NIS2 Directive (EU) 2022/2555 | Cybersecurity Risk Management Measures](/artifacts/eu/nis2-directive/article-21-control-baseline.md): A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence. - [Checklist | EU NIS2 Directive (EU) 2022/2555 | Audit-Ready Owners, Evidence, Acceptance Criteria](/artifacts/eu/nis2-directive/checklist.md): An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline. - [Compliance Guide | EU NIS2 Directive (EU) 2022/2555 | Build an Audit-Ready Program](/artifacts/eu/nis2-directive/compliance.md): A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows. - [Deadlines and Compliance Calendar | EU NIS2 Directive (EU) 2022/2555 | 16 January 2023, 17 October 2024, 17 April 2025](/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar.md): A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023. - [FAQ | EU NIS2 Directive (EU) 2022/2555 | Scope, Essential vs Important, Article 21, Article 23 (24h/72h)](/artifacts/eu/nis2-directive/faq.md): High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires. - [Incident Reporting Workflow | EU NIS2 Directive (EU) 2022/2555 | 24h Early Warning, 72h Notification, Final Report (1 Month)](/artifacts/eu/nis2-directive/incident-reporting-workflow.md): A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents. - [Management Body Accountability | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Training, Liability](/artifacts/eu/nis2-directive/management-body-accountability.md): A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work. - [National Transposition Tracker | EU NIS2 Directive (EU) 2022/2555 | How to Track Local Laws, Authorities, Portals](/artifacts/eu/nis2-directive/national-transposition-tracker.md): A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes. - [NIS2 vs ISO/IEC 27001 | How to Reuse Your ISMS for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27001.md): A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review. - [NIS2 vs ISO/IEC 27017 | Cloud Security Mapping for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27017.md): A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations. - [NIS2 vs NIS1 | Directive (EU) 2022/2555 vs Directive (EU) 2016/1148 | Scope, Supervision, Reporting](/artifacts/eu/nis2-directive/nis2-vs-nis1.md): A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works. - [Requirements | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Article 21 Controls, Article 23 Reporting](/artifacts/eu/nis2-directive/requirements.md): A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690. - [Scope: Essential vs Important | EU NIS2 Directive (EU) 2022/2555 | Article 3 Classification + What Changes](/artifacts/eu/nis2-directive/scope-essential-vs-important.md): A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3). - [Supply Chain Security Program | EU NIS2 Directive (EU) 2022/2555 | Article 21(d) Supplier Risk + Evidence](/artifacts/eu/nis2-directive/supply-chain-security-program.md): A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/nis2-directive/penalties-and-fines --- --- title: "Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/nis2-directive/requirements" source_url: "https://www.sorena.io/artifacts/eu/nis2-directive/requirements" author: "Sorena AI" description: "A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "EU NIS2 requirements" - "NIS2 Directive requirements" - "Directive (EU) 2022/2555 requirements" - "Article 20 governance NIS2" - "Article 21 cybersecurity risk management measures" - "Article 23 incident reporting 24 hours 72 hours 1 month" - "essential entity vs important entity NIS2 requirements" - "NIS2 compliance requirements checklist" - "NIS2 implementing regulation 2024/2690 requirements" - "NIS2 evidence pack" - "NIS2 audit readiness" - "NIS2" - "Directive (EU) 2022/2555" - "Article 20" - "Article 21" - "Article 23" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Requirements A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690. *Requirements* *EU* ## EU NIS2 Directive (EU) 2022/2555 Requirements Turn NIS2 obligations into owned controls, reporting workflows, and evidence packs. Focus: Article 20 governance, Article 21 controls, Article 23 reporting, and national overlays. NIS2 is a management, controls, and reporting system. Use this page as a structured breakdown of what you must implement, what changes for essential versus important entities, and what evidence you should hold so your compliance position is clear under supervision. ## The three obligations you must implement (most programs fail by missing one) NIS2 combines governance, risk management controls, and incident reporting into one system. If any leg is weak, the program collapses during incidents or audits. - Governance under Article 20: management bodies approve the cybersecurity measures, oversee implementation, follow training, and may face liability under national law. - Controls under Article 21: technical, operational, and organisational measures that are appropriate and proportionate, including the listed measures in Article 21(2)(a) to (j). - Reporting under Article 23: early warning within 24 hours, incident notification within 72 hours, final report within 1 month, plus recipient communications where relevant. ## Scope and classification drives what "good" looks like (essential vs important; sector overlays) Your implementation must be scoped per legal entity and per service. Classification affects supervision intensity, enforcement expectations, and how quickly you need to close gaps. - Run an applicability test based on Annex I or Annex II, size-cap logic, and regardless-of-size triggers, then document the outcome in a scope memo. - Determine whether the entity is essential or important under Article 3 and record how that changes your supervisory posture. - Check Article 4 overlap with sector-specific Union acts and keep the equivalence analysis in the scope file. - If you are in a category covered by Implementing Regulation (EU) 2024/2690, apply that act as a more prescriptive layer on top of Article 21 and Article 23. ## Evidence mapping (requirement -> evidence artefacts you should have) Supervision powers include requests for documented policies and evidence, audits, and scans. Build an "evidence pack" that can be produced quickly and confidently. - Article 20: management approval minutes, oversight cadence, training records, and governance RACI. - Article 21: control register mapping Article 21(a) to (j), risk assessments, supplier assurance evidence, restore tests, and vulnerability management records. - Article 23: significant incident decision log, 24h and 72h templates, final report template, submission records, and recipient communications playbook. - Transposition overlays: competent authority and CSIRT route map, portal details, and any national add-ons to scope or enforcement. *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU NIS2 Directive (EU) 2022/2555 Requirements into an operational assessment Assessment Autopilot can take EU NIS2 Directive (EU) 2022/2555 Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU NIS2 Directive (EU) 2022/2555 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU NIS2 Directive (EU) 2022/2555 Requirements](/solutions/assessment.md): Start from EU NIS2 Directive (EU) 2022/2555 Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU NIS2 Directive (EU) 2022/2555](/contact.md): Review your current process, evidence gaps, and next steps for EU NIS2 Directive (EU) 2022/2555 Requirements. ## Program architecture (a model that scales beyond "compliance sprint") Build your NIS2 program like an operating system: recurring risk cycles, recurring control tests, recurring training, and recurring reporting drills. - Quarterly: risk assessment updates for critical services, supplier reviews, and management review of control KPIs. - Monthly: vulnerability management metrics, patch SLA performance, backup/restore checks, access review completion. - Per incident: post-incident review feeding into Article 21 improvements and management reporting. - Annually: security audit/certification posture review, crisis simulations, and evidence pack refresh. ## Primary sources - [Directive (EU) 2022/2555 (NIS2) - Official Journal text (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Primary legal text for Articles 20 to 23, scope, classification, and enforcement architecture. - [Commission Guidelines on Article 3(4) of NIS2 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ%3AC%3A2023%3A324%3AFULL&ref=sorena.io) - Guidance on entity categorisation and the data used to build entity lists. - [Commission Guidelines on Article 4(1) and 4(2) of NIS2 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ%3AC%3A2023%3A328%3AFULL&ref=sorena.io) - Guidance on interaction with sector-specific Union legal acts and equivalent obligations. - [Commission Implementing Regulation (EU) 2024/2690 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng?ref=sorena.io) - Binding technical and methodological requirements for covered digital providers and trust service providers. ## Related Topic Guides - [Applicability Test | EU NIS2 Directive (EU) 2022/2555 | In Scope? Essential vs Important?](/artifacts/eu/nis2-directive/applicability-test.md): A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers. - [Article 21 Control Baseline | EU NIS2 Directive (EU) 2022/2555 | Cybersecurity Risk Management Measures](/artifacts/eu/nis2-directive/article-21-control-baseline.md): A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence. - [Checklist | EU NIS2 Directive (EU) 2022/2555 | Audit-Ready Owners, Evidence, Acceptance Criteria](/artifacts/eu/nis2-directive/checklist.md): An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline. - [Compliance Guide | EU NIS2 Directive (EU) 2022/2555 | Build an Audit-Ready Program](/artifacts/eu/nis2-directive/compliance.md): A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows. - [Deadlines and Compliance Calendar | EU NIS2 Directive (EU) 2022/2555 | 16 January 2023, 17 October 2024, 17 April 2025](/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar.md): A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023. - [FAQ | EU NIS2 Directive (EU) 2022/2555 | Scope, Essential vs Important, Article 21, Article 23 (24h/72h)](/artifacts/eu/nis2-directive/faq.md): High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires. - [Incident Reporting Workflow | EU NIS2 Directive (EU) 2022/2555 | 24h Early Warning, 72h Notification, Final Report (1 Month)](/artifacts/eu/nis2-directive/incident-reporting-workflow.md): A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents. - [Management Body Accountability | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Training, Liability](/artifacts/eu/nis2-directive/management-body-accountability.md): A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work. - [National Transposition Tracker | EU NIS2 Directive (EU) 2022/2555 | How to Track Local Laws, Authorities, Portals](/artifacts/eu/nis2-directive/national-transposition-tracker.md): A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes. - [NIS2 vs ISO/IEC 27001 | How to Reuse Your ISMS for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27001.md): A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review. - [NIS2 vs ISO/IEC 27017 | Cloud Security Mapping for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27017.md): A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations. - [NIS2 vs NIS1 | Directive (EU) 2022/2555 vs Directive (EU) 2016/1148 | Scope, Supervision, Reporting](/artifacts/eu/nis2-directive/nis2-vs-nis1.md): A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works. - [Penalties and Fines | EU NIS2 Directive (EU) 2022/2555 | Article 32-34 Enforcement + Fine Thresholds](/artifacts/eu/nis2-directive/penalties-and-fines.md): A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use. - [Scope: Essential vs Important | EU NIS2 Directive (EU) 2022/2555 | Article 3 Classification + What Changes](/artifacts/eu/nis2-directive/scope-essential-vs-important.md): A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3). - [Supply Chain Security Program | EU NIS2 Directive (EU) 2022/2555 | Article 21(d) Supplier Risk + Evidence](/artifacts/eu/nis2-directive/supply-chain-security-program.md): A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/nis2-directive/requirements --- --- title: "Scope: Essential vs Important" canonical_url: "https://www.sorena.io/artifacts/eu/nis2-directive/scope-essential-vs-important" source_url: "https://www.sorena.io/artifacts/eu/nis2-directive/scope-essential-vs-important" author: "Sorena AI" description: "A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3)." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "NIS2 essential vs important" - "essential entity NIS2" - "important entity NIS2" - "NIS2 Article 3 classification" - "NIS2 Annex I Annex II sectors" - "NIS2 scope essential important" - "NIS2 supervision essential entity" - "NIS2 supervision important entity" - "NIS2" - "Essential entity" - "Important entity" - "Article 3" - "Supervision" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Scope: Essential vs Important A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3). *Scope* *Classification* ## EU NIS2 Directive (EU) 2022/2555 Essential vs Important Understand classification and what changes operationally. Output: a defensible classification note + a supervision/evidence plan aligned to your entity type. NIS2 classification matters because it affects how supervision happens and what you must be ready to produce during audits and incidents. Use this page to structure a defensible essential vs important classification note and to design your evidence pack accordingly. ## Classification in NIS2 (what Article 3 says) NIS2 distinguishes essential and important entities and requires Member States to establish lists of essential and important entities. Entities not qualifying as essential under Article 3(1) are considered important under Article 3(2). - Essential entities include specific entity types and those identified by Member States as essential (including certain Annex I cases and other identified entities). - Important entities include Annex I/II entities that do not qualify as essential under Article 3(1), including those identified by Member States as important. - Member States establish and regularly update lists of essential and important entities (Article 3(3)); this is the operational "ground truth". ## A practical decision framework (how to write a defensible classification memo) Your memo should be short, explicit, and defensible. It should survive a regulator question like: "Why did you classify yourself this way?" - Step 1: map sector/subsector to Annex I or Annex II and document the mapping decision. - Step 2: apply size-cap rules and any regardless-of-size triggers (certain digital infrastructure and trust services). - Step 3: confirm how your Member State identifies your entity type (registration, designation, or list inclusion). - Step 4: record any sector-specific EU act equivalence decision (Article 4). - Step 5: document jurisdiction assumptions if you operate cross-border (where services are provided and where systems are located). ## What changes operationally (supervision + evidence expectations) Both essential and important entities must implement Article 21 controls and Article 23 reporting. The difference is how supervision and enforcement is applied and what intensity you should expect. - Essential entities: supervision includes on-site/off-site supervision, regular and targeted audits, ad hoc audits, scans, information and evidence requests, and enforcement measures (Article 32). - Important entities: supervision is generally ex post when evidence indicates non-compliance, with powers including inspections, targeted audits, scans, and evidence requests (Article 33). - Practical implication: essential entities should assume more proactive audit interaction and build a more continuously maintained evidence vault. - Build evidence so it answers: what controls exist, who owns them, how effectiveness is tested, and what changed after incidents. ## Checklist: what to document and keep current If any of these are missing, classification disputes and audit responses become slower and riskier. - Classification memo with Annex mapping, size logic, regardless-of-size triggers, and Member State identification references. - Scope memo per legal entity + per service with cross-border service mapping. - Article 21 control register with KPIs and evidence links. - Article 23 incident reporting workflow + 24h/72h/final templates + decision log. - National overlay sheet: competent authority/CSIRT routes, portals, and any additional local requirements. *Recommended next step* *Placement: after the comparison section* ## Use EU NIS2 Directive (EU) 2022/2555 Essential vs Important as a cited research workflow Research Copilot can take EU NIS2 Directive (EU) 2022/2555 Essential vs Important from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU NIS2 Directive (EU) 2022/2555 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU NIS2 Directive (EU) 2022/2555 Essential vs Important](/solutions/research-copilot.md): Start from EU NIS2 Directive (EU) 2022/2555 Essential vs Important and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU NIS2 Directive (EU) 2022/2555](/contact.md): Review your current process, evidence gaps, and next steps for EU NIS2 Directive (EU) 2022/2555 Essential vs Important. ## Primary sources - [Directive (EU) 2022/2555 (NIS2) - Official Journal text (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Primary source for Article 3 essential vs important logic and Articles 32-33 supervision approach. - [European Commission - NIS2 Directive overview (policy page)](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive?ref=sorena.io) - Implementation context; always confirm classification and identification via Member State transposition and lists. ## Related Topic Guides - [Applicability Test | EU NIS2 Directive (EU) 2022/2555 | In Scope? Essential vs Important?](/artifacts/eu/nis2-directive/applicability-test.md): A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers. - [Article 21 Control Baseline | EU NIS2 Directive (EU) 2022/2555 | Cybersecurity Risk Management Measures](/artifacts/eu/nis2-directive/article-21-control-baseline.md): A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence. - [Checklist | EU NIS2 Directive (EU) 2022/2555 | Audit-Ready Owners, Evidence, Acceptance Criteria](/artifacts/eu/nis2-directive/checklist.md): An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline. - [Compliance Guide | EU NIS2 Directive (EU) 2022/2555 | Build an Audit-Ready Program](/artifacts/eu/nis2-directive/compliance.md): A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows. - [Deadlines and Compliance Calendar | EU NIS2 Directive (EU) 2022/2555 | 16 January 2023, 17 October 2024, 17 April 2025](/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar.md): A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023. - [FAQ | EU NIS2 Directive (EU) 2022/2555 | Scope, Essential vs Important, Article 21, Article 23 (24h/72h)](/artifacts/eu/nis2-directive/faq.md): High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires. - [Incident Reporting Workflow | EU NIS2 Directive (EU) 2022/2555 | 24h Early Warning, 72h Notification, Final Report (1 Month)](/artifacts/eu/nis2-directive/incident-reporting-workflow.md): A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents. - [Management Body Accountability | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Training, Liability](/artifacts/eu/nis2-directive/management-body-accountability.md): A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work. - [National Transposition Tracker | EU NIS2 Directive (EU) 2022/2555 | How to Track Local Laws, Authorities, Portals](/artifacts/eu/nis2-directive/national-transposition-tracker.md): A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes. - [NIS2 vs ISO/IEC 27001 | How to Reuse Your ISMS for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27001.md): A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review. - [NIS2 vs ISO/IEC 27017 | Cloud Security Mapping for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27017.md): A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations. - [NIS2 vs NIS1 | Directive (EU) 2022/2555 vs Directive (EU) 2016/1148 | Scope, Supervision, Reporting](/artifacts/eu/nis2-directive/nis2-vs-nis1.md): A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works. - [Penalties and Fines | EU NIS2 Directive (EU) 2022/2555 | Article 32-34 Enforcement + Fine Thresholds](/artifacts/eu/nis2-directive/penalties-and-fines.md): A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use. - [Requirements | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Article 21 Controls, Article 23 Reporting](/artifacts/eu/nis2-directive/requirements.md): A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690. - [Supply Chain Security Program | EU NIS2 Directive (EU) 2022/2555 | Article 21(d) Supplier Risk + Evidence](/artifacts/eu/nis2-directive/supply-chain-security-program.md): A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/nis2-directive/scope-essential-vs-important --- --- title: "Supply Chain Security Program" canonical_url: "https://www.sorena.io/artifacts/eu/nis2-directive/supply-chain-security-program" source_url: "https://www.sorena.io/artifacts/eu/nis2-directive/supply-chain-security-program" author: "Sorena AI" description: "A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance." published_at: "2026-02-23" updated_at: "2026-02-23" keywords: - "NIS2 supply chain security" - "Article 21(d) NIS2" - "NIS2 supplier security requirements" - "NIS2 vendor risk management" - "NIS2 third party risk management" - "NIS2 managed service provider security" - "NIS2 supplier incident notification" - "NIS2 supply chain evidence pack" - "NIS2" - "Supply chain security" - "Article 21" - "Vendors" - "Managed services" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Supply Chain Security Program A practical NIS2 supply chain security program (Article 21(d)): vendor tiering, security requirements, onboarding/offboarding controls, continuous assurance. *Article 21* *Supply Chain* ## EU NIS2 Directive (EU) 2022/2555 Supply Chain Security Program Operationalise Article 21(d) with vendor tiering, assurance, and incident communications. Output: a repeatable third-party security program with audit-ready evidence. NIS2 explicitly requires supply chain security as part of Article 21 risk management measures. The fastest way to fail is to treat suppliers as "outside the perimeter". This page gives you a practical program structure you can implement and maintain. ## What Article 21(d) expects (and what it means operationally) Article 21 includes supply chain security, including security-related aspects of relationships between each entity and its direct suppliers or service providers. - Create supplier tiering based on impact: managed services, critical infrastructure, data access, and operational dependency. - Define security requirements per tier: authentication, logging, vulnerability handling, incident notification, and resilience expectations. - Build continuous assurance: not only a procurement questionnaire - you need evidence and recurring reviews. - Include supplier incident communications in your Article 23 incident workflow (timelines, contacts, and data requirements). ## Program design (the minimum components that make it work) A defensible supply chain program is simple but strict: tiering, controls, contracts, and evidence. - Inventory: maintain a live list of direct suppliers and service providers, with data access and criticality tagging. - Onboarding: due diligence + contract clauses + technical onboarding controls (SSO/MFA, network segmentation, least privilege). - Ongoing assurance: periodic reviews, evidence requests, and service-level security KPIs. - Offboarding: access removal, data return/destruction, and termination runbooks. - Incident communications: defined notification timelines, contact paths, and required incident payload fields. ## Evidence pack (what you should be able to show during audits) Supervisory authorities can request evidence of cybersecurity policies and implementation. Supply chain evidence should be indexed and easy to retrieve. - Supplier register with tiering rationale and periodic review dates. - Standard security clauses / addenda per tier (incident notification, vulnerability handling, access control, audit rights where appropriate). - Due diligence records and decisions (including exceptions and compensating controls). - Supplier performance KPIs and review minutes. - Supplier incident communications log and lessons learned integrated into Article 21 improvements. ## A 60-day rollout plan (pragmatic sequencing) Start with the suppliers that can cause the biggest operational impact, then expand. - Days 0-14: build tiering model + supplier inventory; identify "critical suppliers" list. - Days 15-30: implement contract addendum for critical tiers; define incident communications requirements. - Days 31-45: implement technical onboarding/offboarding controls; tighten privileged access and logging for supplier access. - Days 46-60: run first supplier reviews and document evidence pack; integrate into management reporting cadence. *Recommended next step* *Placement: near the end of the main content before related guides* ## Turn EU NIS2 Directive (EU) 2022/2555 Supply Chain Security Program into an operational assessment Assessment Autopilot can take EU NIS2 Directive (EU) 2022/2555 Supply Chain Security Program from turning this guidance into an operational assessment workflow to a reusable workflow inside Sorena. Teams working on EU NIS2 Directive (EU) 2022/2555 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU NIS2 Directive (EU) 2022/2555 Supply Chain Security Program](/solutions/assessment.md): Start from EU NIS2 Directive (EU) 2022/2555 Supply Chain Security Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU NIS2 Directive (EU) 2022/2555](/contact.md): Review your current process, evidence gaps, and next steps for EU NIS2 Directive (EU) 2022/2555 Supply Chain Security Program. ## Primary sources - [Directive (EU) 2022/2555 (NIS2) - Official Journal text (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Primary source for Article 21(d) supply chain security as part of cybersecurity risk management measures. - [European Commission - NIS2 Directive overview (policy page)](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive?ref=sorena.io) - Context and related resources; validate supply chain expectations via national transposition and sector guidance. ## Related Topic Guides - [Applicability Test | EU NIS2 Directive (EU) 2022/2555 | In Scope? Essential vs Important?](/artifacts/eu/nis2-directive/applicability-test.md): A grounded NIS2 applicability test: map each legal entity to Annex I or Annex II, apply the NIS2 size-cap rule and regardless-of-size triggers. - [Article 21 Control Baseline | EU NIS2 Directive (EU) 2022/2555 | Cybersecurity Risk Management Measures](/artifacts/eu/nis2-directive/article-21-control-baseline.md): A practical Article 21 control baseline for NIS2: translate Article 21(2)(a) to (j) into owned controls, KPIs, tests, and evidence. - [Checklist | EU NIS2 Directive (EU) 2022/2555 | Audit-Ready Owners, Evidence, Acceptance Criteria](/artifacts/eu/nis2-directive/checklist.md): An audit-ready EU NIS2 compliance checklist: scope (Annex I/II + size-cap rules), essential vs important classification, Article 21 control baseline. - [Compliance Guide | EU NIS2 Directive (EU) 2022/2555 | Build an Audit-Ready Program](/artifacts/eu/nis2-directive/compliance.md): A practical EU NIS2 compliance guide: how to run scope and classification, build Article 21 controls, implement Article 23 reporting workflows. - [Deadlines and Compliance Calendar | EU NIS2 Directive (EU) 2022/2555 | 16 January 2023, 17 October 2024, 17 April 2025](/artifacts/eu/nis2-directive/deadlines-and-compliance-calendar.md): A practical EU NIS2 deadlines and compliance calendar with the legal anchor dates that matter: entry into force on 16 January 2023. - [FAQ | EU NIS2 Directive (EU) 2022/2555 | Scope, Essential vs Important, Article 21, Article 23 (24h/72h)](/artifacts/eu/nis2-directive/faq.md): High-intent EU NIS2 FAQ: who is in scope, how essential vs important works, what Article 21 requires. - [Incident Reporting Workflow | EU NIS2 Directive (EU) 2022/2555 | 24h Early Warning, 72h Notification, Final Report (1 Month)](/artifacts/eu/nis2-directive/incident-reporting-workflow.md): A practical NIS2 incident reporting workflow grounded in Article 23 and Commission Implementing Regulation (EU) 2024/2690: define significant incidents. - [Management Body Accountability | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Training, Liability](/artifacts/eu/nis2-directive/management-body-accountability.md): A practical Article 20 governance guide for EU NIS2: what the management body must approve and oversee, how liability and training work. - [National Transposition Tracker | EU NIS2 Directive (EU) 2022/2555 | How to Track Local Laws, Authorities, Portals](/artifacts/eu/nis2-directive/national-transposition-tracker.md): A practical NIS2 national transposition tracker: monitor Member State implementation, find competent authority and CSIRT routes. - [NIS2 vs ISO/IEC 27001 | How to Reuse Your ISMS for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27001.md): A practical NIS2 vs ISO/IEC 27001 mapping: how to reuse an ISMS (risk assessment, policies, internal audits, management review. - [NIS2 vs ISO/IEC 27017 | Cloud Security Mapping for EU NIS2 Directive (EU) 2022/2555](/artifacts/eu/nis2-directive/nis2-vs-iso-27017.md): A practical mapping for cloud teams: how NIS2 Article 21 controls and Article 23 reporting apply to cloud service providers and cloud-dependent organisations. - [NIS2 vs NIS1 | Directive (EU) 2022/2555 vs Directive (EU) 2016/1148 | Scope, Supervision, Reporting](/artifacts/eu/nis2-directive/nis2-vs-nis1.md): A practical comparison of NIS2 vs NIS1: what changed in scope and sectors, how essential vs important works. - [Penalties and Fines | EU NIS2 Directive (EU) 2022/2555 | Article 32-34 Enforcement + Fine Thresholds](/artifacts/eu/nis2-directive/penalties-and-fines.md): A practical NIS2 enforcement guide: how supervision works for essential vs important entities (Articles 32-33), what enforcement measures authorities can use. - [Requirements | EU NIS2 Directive (EU) 2022/2555 | Article 20 Governance, Article 21 Controls, Article 23 Reporting](/artifacts/eu/nis2-directive/requirements.md): A practical EU NIS2 requirements breakdown grounded in Articles 20 to 23, the Article 3 and Article 4 guidelines, and Implementing Regulation (EU) 2024/2690. - [Scope: Essential vs Important | EU NIS2 Directive (EU) 2022/2555 | Article 3 Classification + What Changes](/artifacts/eu/nis2-directive/scope-essential-vs-important.md): A practical guide to NIS2 scope classification: how essential vs important entities work (Article 3). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/nis2-directive/supply-chain-security-program --- --- title: "Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/applicability-test" author: "Sorena AI" description: "A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "PPWR applicability test" - "PPWR scope" - "Regulation (EU) 2025/40 scope" - "is it packaging PPWR" - "packaging definition Article 3 PPWR" - "sales packaging grouped packaging transport packaging" - "e-commerce packaging PPWR" - "take-away packaging PPWR" - "PPWR obligations by role manufacturer importer distributor" - "PPWR" - "Regulation (EU) 2025/40" - "Scope" - "Packaging definition" - "Economic operators" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Applicability Test A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging. *Scope* *PPWR* ## EU Packaging and Packaging Waste Regulation (PPWR) Applicability Test Decide if it's packaging, your role, and which obligations apply. Output: a defensible scope note per packaging unit and per legal entity (with workstreams and owners). PPWR compliance starts with accurate scoping. Teams waste months redesigning the wrong things when they don't classify packaging units correctly, don't identify their economic-operator role, or don't separate EU-level requirements from delegated/implementing-act details. Use this page to produce a defensible "PPWR applies / does not apply / applies partially" scope note. ## Step 1 - Is the item 'packaging' under PPWR? Start with the PPWR definition of packaging and the indicative list of items in scope (Annex I). If it is packaging, the regulation applies to the packaging unit and, where relevant, to its components. - Does the item contain/support/preserve a product for handling, delivery, or presentation (without being an integral part of the product) and is it intended to be used/consumed/disposed with the product? - Is it service packaging filled at the point of sale (take-away packaging is explicitly defined)? - Is it a component/ancillary element that performs a packaging function (labels, hangers, attached elements)? - Result: packaging / not packaging / packaging component - record the rationale and an example photo or BOM line. ## Step 2 - Classify the packaging unit by format and use case Most PPWR requirements trigger by format and use case: sales vs grouped vs transport vs e-commerce, take-away, reusable, deposit-bearing, food-contact, etc. - Sales packaging vs grouped packaging vs transport packaging (define at unit level). - E-commerce packaging: transport packaging used to deliver products in the context of distance sales to end users. - Food-contact packaging (critical for PFAS thresholds). - Reusable packaging / closed-loop vs open-loop system (important for labelling, rotations, and reuse targets). - Packaging for HORECA take-away: triggers refill and reuse-offer obligations on final distributors. ## Step 3 - Identify your role (who must do what) PPWR obligations apply to economic operators (manufacturer, importer, distributor, final distributor, etc.). A single organisation can hold multiple roles across brands and markets. - Manufacturer: manufactures packaging or packaged product (including private label under own trademark, with SME nuance). - Importer: brings packaging/packaged products from outside the Union. - Distributor/final distributor: makes packaging/packaged products available on the market or to end users. - Packaging waste management operator: feeds reporting/data flows for EPR and waste obligations. - Result: write a one-page role map per legal entity and per channel (retail, e-commerce, HORECA, B2B logistics). ## Step 4 - Map the PPWR workstreams that apply (your obligations matrix) Use a workstream matrix so teams don't miss obligations that aren't 'design tasks' (labelling, data carriers, evidence, empty space, reuse targets). - Substances and PFAS (Article 5): substances of concern minimisation; heavy metals limit; PFAS thresholds for food-contact packaging from 12 Aug 2026. - Recyclability (Article 6): design-for-recycling criteria, recyclability grades, and 'recycled at scale' condition with phase-in dates. - Minimum recycled content (Article 7): PCR targets for plastic parts from 2030 and 2040 (by packaging type). - Labelling + digital marking (Articles 12-13): harmonised labels for composition + reusable labels + digital marking methodologies. - Packaging minimisation/excessive packaging (Article 24): empty-space ratios for grouped/transport/e-commerce packaging. - Format restrictions (Article 25 + Annex V): packaging formats and uses restricted from 1 Jan 2030. - Reuse/refill (Articles 28-33): refill rules, reuse targets, takeaway sector obligations and timelines. - Evidence pack: technical documentation (Annex VII) and 'who signs what' internally. ## Step 5 - Produce a defensible output (what you should write down) A good applicability output is short and reusable: it should be attachable to product documentation, supplier onboarding, and audit responses. - Packaging unit ID + photos + BOM, predominant material, components (integrated vs separate). - Format classification (sales/grouped/transport/e-commerce/take-away) + market/channel. - Role map (manufacturer/importer/distributor/final distributor) per legal entity. - Workstreams that apply + owners + earliest deadlines that matter for the unit. - Known unknowns: delegated/implementing acts you must track (design-for-recycling criteria, labelling specs, reuse calculation methodology). *Recommended next step* *Placement: after the applicability result* ## Operationalize EU Packaging and Packaging Waste Regulation (PPWR) Applicability Test across ESG workflows ESG Compliance can take EU Packaging and Packaging Waste Regulation (PPWR) Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU Packaging and Packaging Waste Regulation (PPWR) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Packaging and Packaging Waste Regulation (PPWR) Applicability Test](/solutions/esg-compliance.md): Start from EU Packaging and Packaging Waste Regulation (PPWR) Applicability Test and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Packaging and Packaging Waste Regulation (PPWR)](/contact.md): Review your current process, evidence gaps, and next steps for EU Packaging and Packaging Waste Regulation (PPWR) Applicability Test. ## Primary sources - [Regulation (EU) 2025/40 on packaging and packaging waste (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2025/40/oj?ref=sorena.io) - Primary legal text for scope, definitions, and obligations across substances, recyclability, recycled content, labelling, restrictions, and reuse/refill. - [European Commission - Packaging & Packaging Waste Regulation overview](https://environment.ec.europa.eu/topics/waste-and-recycling/packaging-waste/packaging-packaging-waste-regulation_en?ref=sorena.io) - High-level policy overview, key measures and implementation context. - [Register of delegated and implementing acts (European Commission)](https://webgate.ec.europa.eu/regdel/?ref=sorena.io) - Track secondary legislation that defines detailed technical criteria (DfR criteria, labelling specs, reuse calculation methodologies). ## Related Topic Guides - [Labelling and Consumer Information | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels, QR/Digital Marking, DRS](/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info.md): A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers. - [PFAS and Restricted Substances | EU PPWR (Regulation (EU) 2025/40) | Article 5 PFAS Thresholds for Food-Contact Packaging](/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances.md): A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits. - [PPWR Compliance Checklist | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40)](/artifacts/eu/packaging-waste-regulation/checklist.md): An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals. - [PPWR Compliance Guide | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40) | Evidence, Conformity, Enforcement](/artifacts/eu/packaging-waste-regulation/compliance.md): A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging. - [PPWR Deadlines and Compliance Calendar | Regulation (EU) 2025/40 | 11 February 2025, 12 August 2026, 1 January 2030](/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar.md): A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026. - [PPWR FAQ | Regulation (EU) 2025/40 Packaging and Packaging Waste Questions (Dates, PFAS, Labelling, Reuse Targets)](/artifacts/eu/packaging-waste-regulation/faq.md): A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions. - [PPWR Labelling Checklist | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels + QR/Digital Carriers](/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist.md): An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking. - [PPWR Penalties and Fines | Regulation (EU) 2025/40 Article 68 Enforcement and Administrative Fines](/artifacts/eu/packaging-waste-regulation/penalties-and-fines.md): A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027. - [PPWR Recyclability Assessment Template | Regulation (EU) 2025/40 | Article 6 Evidence Pack + Grade A/B/C](/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template.md): A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material). - [PPWR Timeline and Deadlines | Regulation (EU) 2025/40 Roadmap | 2025 to 2040](/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines.md): A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028. - [PPWR vs ESPR | Packaging and Packaging Waste Regulation (EU) 2025/40 vs Ecodesign for Sustainable Products Regulation (EU) 2024/1781](/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr.md): A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space. - [Recyclability and Design Requirements | EU PPWR (Regulation (EU) 2025/40) | Article 6 Recyclability Grades A/B/C + Design-for-Recycling](/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements.md): A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components. - [Requirements | EU PPWR (Regulation (EU) 2025/40) | Recyclability (Article 6), Recycled Content (Article 7), Labelling (Article 12), PFAS (Article 5)](/artifacts/eu/packaging-waste-regulation/requirements.md): A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits. - [Reuse and Refill Targets | EU PPWR (Regulation (EU) 2025/40) | Article 28-33 Refill Rules, Article 29 Reuse Targets (40% 2030, 70% 2040)](/artifacts/eu/packaging-waste-regulation/reuse-refill-targets.md): A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging. - [Scope and Packaging Definitions | EU PPWR (Regulation (EU) 2025/40) | Sales vs Grouped vs Transport vs E-commerce](/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions.md): A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/packaging-waste-regulation/applicability-test --- --- title: "PPWR Compliance Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/checklist" source_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/checklist" author: "Sorena AI" description: "An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "PPWR compliance checklist" - "EU packaging and packaging waste regulation checklist" - "Regulation (EU) 2025/40 checklist" - "PPWR audit checklist" - "PPWR implementation checklist" - "PPWR recyclability grading checklist" - "PPWR labelling checklist Article 12 Article 13" - "PPWR reuse targets checklist Article 29" - "PPWR refill obligations HORECA Article 32" - "PPWR" - "Compliance checklist" - "Recyclability grades" - "Labelling" - "Reuse and refill" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # PPWR Compliance Checklist An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals. *PPWR* *Checklist* ## EU Packaging and Packaging Waste Regulation (PPWR) Compliance Checklist Turn Regulation (EU) 2025/40 into owned workstreams, acceptance criteria, and evidence. Output: portfolio scope memo, packaging specs, supplier evidence pack, label release workflow, reuse/refill program plan. PPWR compliance fails in two predictable ways: (1) teams treat it as a legal memo instead of a portfolio program, and (2) teams can't produce evidence per packaging unit (materials, recyclability, label, and reuse/refill claims). Use this checklist to build a defensible PPWR program grounded in Regulation (EU) 2025/40. ## How to use this PPWR checklist (so it stays useful) Treat this as a packaging-portfolio checklist, not a single-product checklist. PPWR obligations vary by packaging format, material, use case (food contact, take-away), and whether the packaging is sales / grouped / transport / e-commerce. Make each checklist item evidence-backed: every claim needs an owner, a data source, and a retrievable record per packaging unit / SKU / market. - Define your packaging unit of control: packaging BOM + component-level specs + supplier chain - Assign workstreams: design-for-recycling, chemicals/PFAS, recycled content, labelling, reuse/refill, excessive packaging, reporting - Create an evidence vault structure and a release workflow for packaging changes (artwork + BOM + declarations) *Recommended next step* *Placement: after the checklist block* ## Operationalize EU Packaging and Packaging Waste Regulation (PPWR) Compliance Checklist across ESG workflows ESG Compliance can take EU Packaging and Packaging Waste Regulation (PPWR) Compliance Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Packaging and Packaging Waste Regulation (PPWR) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Packaging and Packaging Waste Regulation (PPWR) Compliance Checklist](/solutions/esg-compliance.md): Start from EU Packaging and Packaging Waste Regulation (PPWR) Compliance Checklist and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Packaging and Packaging Waste Regulation (PPWR)](/contact.md): Review your current process, evidence gaps, and next steps for EU Packaging and Packaging Waste Regulation (PPWR) Compliance Checklist. ## 1) Scope your packaging portfolio (fast, but correctly) Start with inventory and classification: PPWR compliance is impossible without a reliable view of packaging types and where they are placed on the EU market. Your goal is an applicability map that drives design changes and supplier evidence requests. - Inventory: list packaging units (sales, grouped, transport, e-commerce) and markets where placed on the market - Classify: material(s), components (labels/closures/inks/coatings), food-contact status, reuse vs single-use, DRS relevance - Decide: which units are high-risk (food contact, fluorinated coatings, composites, complex multi-material, take-away) ## 2) Build packaging specs that satisfy Article 5-7 and Article 6 Most PPWR effort happens in engineering + procurement: substances limits (including PFAS for food-contact), minimum recycled content for plastic parts, and recyclability performance and grading. Your deliverable is a spec package per packaging unit: measurable criteria + supplier obligations + test/verification expectations. - Chemicals: substance-of-concern minimisation controls + heavy metals limit + PFAS thresholds for food-contact packaging (from PPWR application date) - Recyclability: design-for-recycling criteria, recyclability performance assessment approach, and future grading readiness - Recycled content: map which packaging components are in-scope plastic parts and build supplier verification for post-consumer recycled content claims ## 3) Implement labelling + digital marking as a controlled release (Article 12-13) Labelling changes require repeatable governance: artwork approval, consumer-instruction validation, and (where used) QR/digital payload controls. Plan for implementing acts (specs/methodologies) and the phase-in dates for harmonised labels. - Define label variants per market: harmonised composition label, DRS marking, compostable packaging messaging, reusable packaging labelling - Build a digital data carrier (QR) governance model: payload content, languages, destinations, and change control - Maintain evidence: implementing-act references, internal sign-off, and samples/photos per SKU and market ## 4) Reduce packaging waste: empty space, format restrictions, reuse/refill PPWR is not only materials and labels. It also forces operational changes: excessive packaging limits, restrictions on certain packaging formats from 2030, and reuse/refill targets and take-away obligations. Treat these as cross-functional programs with data collection baked in. - Excessive packaging: prepare to meet empty space ratio requirements and methodology (Article 24) - Format restrictions: identify packaging potentially affected by Annex V restrictions from 1 Jan 2030 and design alternatives early - Reuse/refill: implement reuse targets (Article 29), refill rules (Article 28), and take-away refill/reuse offer obligations (Articles 32-33) ## 5) Evidence pack (what to store so you can defend decisions) PPWR enforcement will be national, but your defence strategy can be consistent: show a controlled system, retrievable evidence, and a decision record for each packaging unit. Build the pack once, reuse it for market surveillance requests, customer questionnaires, and procurement assurance. - Portfolio scope memo: definitions, classification logic, and owner responsibilities - Technical documentation per packaging unit: BOM, specs, test reports, supplier declarations, and compliance statements - Release governance: artwork approvals, label claims substantiation, and change-control records - Reuse/refill evidence: reuse system participation, trip/rotation data where applicable, and target-calculation method (once adopted) ## Primary sources - [Regulation (EU) 2025/40 on packaging and packaging waste (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2025/40/oj?ref=sorena.io) - Primary source for PPWR obligations, phase-in dates, and enforcement framework. - [European Commission - Packaging & Packaging Waste Regulation overview](https://environment.ec.europa.eu/topics/waste-and-recycling/packaging-waste/packaging-packaging-waste-regulation_en?ref=sorena.io) - Policy overview and implementation context. - [Register of delegated and implementing acts (European Commission)](https://webgate.ec.europa.eu/regdel/?ref=sorena.io) - Track delegated/implementing acts for labelling, digital marking, recyclability assessment, and reuse target calculations. - [JRC - Technical recyclability methodology (supporting evidence)](https://data.europa.eu/doi/10.2760/538070?ref=sorena.io) - Useful technical background when building recyclability assessment and acceptance criteria. - [Harmonised standards for packaging and packaging waste (EU Single Market)](https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards/packaging-and-packaging-waste_en?ref=sorena.io) - Find standards that support presumption of conformity for testing and verification approaches where referenced. ## Related Topic Guides - [Applicability Test | EU Packaging and Packaging Waste Regulation (PPWR) | Regulation (EU) 2025/40 Scope + Roles](/artifacts/eu/packaging-waste-regulation/applicability-test.md): A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging. - [Labelling and Consumer Information | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels, QR/Digital Marking, DRS](/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info.md): A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers. - [PFAS and Restricted Substances | EU PPWR (Regulation (EU) 2025/40) | Article 5 PFAS Thresholds for Food-Contact Packaging](/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances.md): A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits. - [PPWR Compliance Guide | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40) | Evidence, Conformity, Enforcement](/artifacts/eu/packaging-waste-regulation/compliance.md): A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging. - [PPWR Deadlines and Compliance Calendar | Regulation (EU) 2025/40 | 11 February 2025, 12 August 2026, 1 January 2030](/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar.md): A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026. - [PPWR FAQ | Regulation (EU) 2025/40 Packaging and Packaging Waste Questions (Dates, PFAS, Labelling, Reuse Targets)](/artifacts/eu/packaging-waste-regulation/faq.md): A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions. - [PPWR Labelling Checklist | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels + QR/Digital Carriers](/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist.md): An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking. - [PPWR Penalties and Fines | Regulation (EU) 2025/40 Article 68 Enforcement and Administrative Fines](/artifacts/eu/packaging-waste-regulation/penalties-and-fines.md): A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027. - [PPWR Recyclability Assessment Template | Regulation (EU) 2025/40 | Article 6 Evidence Pack + Grade A/B/C](/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template.md): A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material). - [PPWR Timeline and Deadlines | Regulation (EU) 2025/40 Roadmap | 2025 to 2040](/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines.md): A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028. - [PPWR vs ESPR | Packaging and Packaging Waste Regulation (EU) 2025/40 vs Ecodesign for Sustainable Products Regulation (EU) 2024/1781](/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr.md): A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space. - [Recyclability and Design Requirements | EU PPWR (Regulation (EU) 2025/40) | Article 6 Recyclability Grades A/B/C + Design-for-Recycling](/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements.md): A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components. - [Requirements | EU PPWR (Regulation (EU) 2025/40) | Recyclability (Article 6), Recycled Content (Article 7), Labelling (Article 12), PFAS (Article 5)](/artifacts/eu/packaging-waste-regulation/requirements.md): A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits. - [Reuse and Refill Targets | EU PPWR (Regulation (EU) 2025/40) | Article 28-33 Refill Rules, Article 29 Reuse Targets (40% 2030, 70% 2040)](/artifacts/eu/packaging-waste-regulation/reuse-refill-targets.md): A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging. - [Scope and Packaging Definitions | EU PPWR (Regulation (EU) 2025/40) | Sales vs Grouped vs Transport vs E-commerce](/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions.md): A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/packaging-waste-regulation/checklist --- --- title: "PPWR Compliance Guide" canonical_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/compliance" source_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/compliance" author: "Sorena AI" description: "A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "PPWR compliance guide" - "Regulation (EU) 2025/40 compliance" - "PPWR technical documentation" - "PPWR EU declaration of conformity" - "PPWR evidence pack" - "PPWR enforcement penalties Article 68" - "PPWR labelling compliance Article 12 Article 13" - "PPWR recyclability grading Article 6" - "PPWR PFAS food contact packaging Article 5" - "PPWR" - "Compliance" - "Technical documentation" - "EU declaration of conformity" - "Enforcement" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # PPWR Compliance Guide A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging. *PPWR* *Compliance* ## EU Packaging and Packaging Waste Regulation (PPWR) Compliance A defensible PPWR program is built on evidence, not slogans. Use this page to structure owners, acceptance criteria, and technical documentation per packaging unit. PPWR compliance is portfolio compliance: you need a controlled system that can explain, for each packaging unit, (1) what rules apply, (2) how you meet them, and (3) what evidence proves it. This page focuses on operational compliance for Regulation (EU) 2025/40: documentation, supplier controls, release governance, and enforcement readiness. ## What 'PPWR compliance' means in practice Think of PPWR as a set of outcomes you must be able to demonstrate. You can ship compliant packaging for years and still fail an authority request if you can't produce the evidence and decision record. A good PPWR program makes compliance measurable at the packaging-unit level (BOM, specs, claims, and reuse/refill facts). - Outcome-based: packaging meets Article 5-7 materials rules, Article 6 recyclability conditions, Article 12-13 labelling requirements, and the waste-prevention/reuse obligations that apply - Evidence-based: technical documentation and declarations are retrievable per packaging unit / SKU / market - Change-controlled: packaging redesign, material substitutions, label updates, and supplier changes follow a controlled release process *Recommended next step* *Placement: after the compliance steps* ## Operationalize EU Packaging and Packaging Waste Regulation (PPWR) Compliance across ESG workflows ESG Compliance can take EU Packaging and Packaging Waste Regulation (PPWR) Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Packaging and Packaging Waste Regulation (PPWR) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Packaging and Packaging Waste Regulation (PPWR) Compliance](/solutions/esg-compliance.md): Start from EU Packaging and Packaging Waste Regulation (PPWR) Compliance and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Packaging and Packaging Waste Regulation (PPWR)](/contact.md): Review your current process, evidence gaps, and next steps for EU Packaging and Packaging Waste Regulation (PPWR) Compliance. ## Conformity, testing, and documentation (how to make it defensible) PPWR expects reliable testing/measurement methods and a structured conformity approach. Even if you outsource testing, the compliance responsibility still sits with the economic operator placing packaging on the market. Design your documentation so you can answer: what was tested, what method was used, what the result was, and which packaging units it covers. - Technical documentation pack: packaging BOM, material specifications, supplier declarations, and verification/test results - EU declaration of conformity: a controlled, versioned statement that you can update when packaging changes - Presumption of conformity (where available): align tests and calculations to harmonised standards or common specifications when referenced ## Workstream map (owners + deliverables) Break PPWR into workstreams with clear deliverables. This prevents "compliance by PowerPoint" and lets you manage phase-in dates as release milestones. Use the linked subpages to implement each stream with acceptance criteria and an evidence checklist. - Scope + definitions: packaging classification, format mapping, food-contact and take-away identification - Materials + chemicals: substances of concern minimisation, heavy metals, PFAS for food-contact packaging, recycled content controls - Recyclability: design-for-recycling criteria, assessment workflow, and grading readiness - Labelling + digital marking: harmonised labels, DRS marking, reusable label, QR/digital payload governance - Waste prevention + reuse/refill: empty space ratio controls, format restrictions, reuse targets and take-away obligations - Reporting + governance: KPI cadence, supplier change control, internal approvals, and a reusable evidence vault ## Supplier and procurement controls (where most failures happen) PPWR compliance relies on upstream truth: material composition, recycled content, PFAS and heavy metals, inks/coatings, and component-level specs. Make supplier evidence contractually enforceable and operationally testable. - Supplier declaration pack: composition, restricted substances (including PFAS for food contact), heavy metals, and recycled content methodology - Change notification: formulation/coating/ink changes must be disclosed before shipment - Verification plan: define when lab tests are required and how sampling/acceptance works - Traceability: batch/lot traceability for high-risk packaging units (especially food-contact lines) ## Enforcement readiness (what to prepare before it hurts) Penalties are national, but your preparation can be consistent: the ability to respond quickly to authority requests and show a controlled compliance system. Assume enforcement will focus on easy-to-check signals first: labelling, empty space, restricted formats, and substantiated claims. - Pre-audit: run internal file checks per packaging unit (can you retrieve the pack in minutes?) - Controls: label release governance + packaging design sign-off + supplier evidence verification - Exception register: document deviations, expiry dates, and corrective actions - Readiness drill: simulate an authority request and time how fast you can respond ## Primary sources - [Regulation (EU) 2025/40 on packaging and packaging waste (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2025/40/oj?ref=sorena.io) - Primary source for PPWR obligations, conformity/documentation expectations, and enforcement framework. - [European Commission - Packaging & Packaging Waste Regulation overview](https://environment.ec.europa.eu/topics/waste-and-recycling/packaging-waste/packaging-packaging-waste-regulation_en?ref=sorena.io) - Policy overview and implementation context. - [Register of delegated and implementing acts (European Commission)](https://webgate.ec.europa.eu/regdel/?ref=sorena.io) - Track delegated/implementing acts that shape assessment methods, labelling specs, and reuse target calculations. - [Harmonised standards for packaging and packaging waste (EU Single Market)](https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards/packaging-and-packaging-waste_en?ref=sorena.io) - Standards can support testing and presumption of conformity where applicable. ## Related Topic Guides - [Applicability Test | EU Packaging and Packaging Waste Regulation (PPWR) | Regulation (EU) 2025/40 Scope + Roles](/artifacts/eu/packaging-waste-regulation/applicability-test.md): A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging. - [Labelling and Consumer Information | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels, QR/Digital Marking, DRS](/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info.md): A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers. - [PFAS and Restricted Substances | EU PPWR (Regulation (EU) 2025/40) | Article 5 PFAS Thresholds for Food-Contact Packaging](/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances.md): A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits. - [PPWR Compliance Checklist | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40)](/artifacts/eu/packaging-waste-regulation/checklist.md): An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals. - [PPWR Deadlines and Compliance Calendar | Regulation (EU) 2025/40 | 11 February 2025, 12 August 2026, 1 January 2030](/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar.md): A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026. - [PPWR FAQ | Regulation (EU) 2025/40 Packaging and Packaging Waste Questions (Dates, PFAS, Labelling, Reuse Targets)](/artifacts/eu/packaging-waste-regulation/faq.md): A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions. - [PPWR Labelling Checklist | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels + QR/Digital Carriers](/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist.md): An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking. - [PPWR Penalties and Fines | Regulation (EU) 2025/40 Article 68 Enforcement and Administrative Fines](/artifacts/eu/packaging-waste-regulation/penalties-and-fines.md): A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027. - [PPWR Recyclability Assessment Template | Regulation (EU) 2025/40 | Article 6 Evidence Pack + Grade A/B/C](/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template.md): A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material). - [PPWR Timeline and Deadlines | Regulation (EU) 2025/40 Roadmap | 2025 to 2040](/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines.md): A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028. - [PPWR vs ESPR | Packaging and Packaging Waste Regulation (EU) 2025/40 vs Ecodesign for Sustainable Products Regulation (EU) 2024/1781](/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr.md): A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space. - [Recyclability and Design Requirements | EU PPWR (Regulation (EU) 2025/40) | Article 6 Recyclability Grades A/B/C + Design-for-Recycling](/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements.md): A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components. - [Requirements | EU PPWR (Regulation (EU) 2025/40) | Recyclability (Article 6), Recycled Content (Article 7), Labelling (Article 12), PFAS (Article 5)](/artifacts/eu/packaging-waste-regulation/requirements.md): A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits. - [Reuse and Refill Targets | EU PPWR (Regulation (EU) 2025/40) | Article 28-33 Refill Rules, Article 29 Reuse Targets (40% 2030, 70% 2040)](/artifacts/eu/packaging-waste-regulation/reuse-refill-targets.md): A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging. - [Scope and Packaging Definitions | EU PPWR (Regulation (EU) 2025/40) | Sales vs Grouped vs Transport vs E-commerce](/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions.md): A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/packaging-waste-regulation/compliance --- --- title: "PPWR Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "PPWR deadlines" - "PPWR compliance calendar" - "Regulation (EU) 2025/40 timeline" - "PPWR 12 August 2026" - "PPWR 1 January 2030" - "PPWR empty space ratio 50% Article 24" - "PPWR Annex V restrictions Article 25" - "PPWR reuse targets Article 29 2030 2040" - "PPWR take-away refill obligation Article 32" - "PPWR take-away reusable offer Article 33" - "PPWR" - "Deadlines" - "Compliance calendar" - "Timeline" - "Regulation (EU) 2025/40" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # PPWR Deadlines and Compliance Calendar A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026. *PPWR* *Deadlines* ## EU Packaging and Packaging Waste Regulation (PPWR) Deadlines and Compliance Calendar Turn PPWR dates into owned milestones and release gates. Use this calendar to sequence portfolio scope, packaging redesign, labelling rollout, and reuse/refill program delivery. PPWR has hard legal dates and dates that depend on secondary acts. Use this calendar to separate what you can build now from what you need to track and integrate later, then attach each milestone to a file, owner, and release gate. ## Milestone: 11 February 2025 and 12 August 2026 The regulation entered into force on 11 February 2025 and applies from 12 August 2026. That gives teams time to build the operating system before the main obligations bite. - 11 February 2025: Regulation (EU) 2025/40 entered into force. - 12 August 2026: the regulation applies and Directive 94/62/EC is repealed, subject to Article 70 transitional carve-outs. - 12 August 2026: PFAS thresholds for food-contact packaging apply under Article 5. - 12 August 2026: Commission implementing acts are due for packaging labels, waste-receptacle labels, and digital marking methodology for material composition. *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU Packaging and Packaging Waste Regulation (PPWR) Deadlines and Compliance Calendar across ESG workflows ESG Compliance can take EU Packaging and Packaging Waste Regulation (PPWR) Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Packaging and Packaging Waste Regulation (PPWR) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Packaging and Packaging Waste Regulation (PPWR) Deadlines and Compliance Calendar](/solutions/esg-compliance.md): Start from EU Packaging and Packaging Waste Regulation (PPWR) Deadlines and Compliance Calendar and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Packaging and Packaging Waste Regulation (PPWR)](/contact.md): Review your current process, evidence gaps, and next steps for EU Packaging and Packaging Waste Regulation (PPWR) Deadlines and Compliance Calendar. ## Milestone: February and June 2027 This period matters because enforcement architecture, Annex V guidance, take-away refill, and reuse methodology all start to crystallise. - 12 February 2027: Member States must lay down and notify penalty rules under Article 68. - 12 February 2027: the Commission must publish Annex V guidance and establish the European observatory on reuse. - 12 February 2027: the take-away refill obligation begins under Article 32. - 30 June 2027: the Commission must adopt the implementing act for Article 29 reuse-target calculation methodology. ## Milestone: February 2028 to February 2029 This is the visible compliance window for empty-space methodology, take-away reusable offer, and the later label phase-in. - 12 February 2028: the Commission must adopt the Article 24 empty-space methodology. - 12 February 2028: final distributors in the HORECA take-away sector must offer reusable packaging under Article 33, unless exempt as micro-enterprises. - 12 August 2028 or later, depending on implementing-act timing: harmonised composition labels start to apply. - 12 February 2029: Article 67(5) starts to apply, and reusable-packaging label timing must be checked against the Article 12 phase-in rules. ## Milestone: 1 January 2030 and beyond 2030 is the main convergence point for design, format, reuse, and refill obligations. Work backwards from 2030 because packaging redesign and supplier changes take time. - 1 January 2030 or later if methodology timing pushes it out: maximum 50% empty space for grouped, transport, and e-commerce packaging under Article 24. - 1 January 2030: Annex V format restrictions start under Article 25. - 1 January 2030: Article 29 reuse targets start, and Article 28 refill-station endeavour language for larger retailers begins to matter. - 1 January 2030: the Commission must also adopt the digital-marking methodology for substances of concern. - 12 August 2034: Commission evaluation under Article 69. 1 January 2040: higher endeavour reuse shares apply under Article 29. ## Primary sources - [Regulation (EU) 2025/40 on packaging and packaging waste (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2025/40/oj?ref=sorena.io) - Primary source for PPWR application date, milestone dates, and the Article 24-33 and Article 68 deadlines referenced above. - [Register of delegated and implementing acts (European Commission)](https://webgate.ec.europa.eu/regdel/?ref=sorena.io) - Track when implementing acts and delegated acts are adopted (they can shift some phase-in dates). - [European Commission - Packaging & Packaging Waste Regulation overview](https://environment.ec.europa.eu/topics/waste-and-recycling/packaging-waste/packaging-packaging-waste-regulation_en?ref=sorena.io) - Policy overview and high-level implementation context. ## Related Topic Guides - [Applicability Test | EU Packaging and Packaging Waste Regulation (PPWR) | Regulation (EU) 2025/40 Scope + Roles](/artifacts/eu/packaging-waste-regulation/applicability-test.md): A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging. - [Labelling and Consumer Information | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels, QR/Digital Marking, DRS](/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info.md): A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers. - [PFAS and Restricted Substances | EU PPWR (Regulation (EU) 2025/40) | Article 5 PFAS Thresholds for Food-Contact Packaging](/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances.md): A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits. - [PPWR Compliance Checklist | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40)](/artifacts/eu/packaging-waste-regulation/checklist.md): An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals. - [PPWR Compliance Guide | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40) | Evidence, Conformity, Enforcement](/artifacts/eu/packaging-waste-regulation/compliance.md): A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging. - [PPWR FAQ | Regulation (EU) 2025/40 Packaging and Packaging Waste Questions (Dates, PFAS, Labelling, Reuse Targets)](/artifacts/eu/packaging-waste-regulation/faq.md): A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions. - [PPWR Labelling Checklist | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels + QR/Digital Carriers](/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist.md): An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking. - [PPWR Penalties and Fines | Regulation (EU) 2025/40 Article 68 Enforcement and Administrative Fines](/artifacts/eu/packaging-waste-regulation/penalties-and-fines.md): A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027. - [PPWR Recyclability Assessment Template | Regulation (EU) 2025/40 | Article 6 Evidence Pack + Grade A/B/C](/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template.md): A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material). - [PPWR Timeline and Deadlines | Regulation (EU) 2025/40 Roadmap | 2025 to 2040](/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines.md): A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028. - [PPWR vs ESPR | Packaging and Packaging Waste Regulation (EU) 2025/40 vs Ecodesign for Sustainable Products Regulation (EU) 2024/1781](/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr.md): A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space. - [Recyclability and Design Requirements | EU PPWR (Regulation (EU) 2025/40) | Article 6 Recyclability Grades A/B/C + Design-for-Recycling](/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements.md): A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components. - [Requirements | EU PPWR (Regulation (EU) 2025/40) | Recyclability (Article 6), Recycled Content (Article 7), Labelling (Article 12), PFAS (Article 5)](/artifacts/eu/packaging-waste-regulation/requirements.md): A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits. - [Reuse and Refill Targets | EU PPWR (Regulation (EU) 2025/40) | Article 28-33 Refill Rules, Article 29 Reuse Targets (40% 2030, 70% 2040)](/artifacts/eu/packaging-waste-regulation/reuse-refill-targets.md): A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging. - [Scope and Packaging Definitions | EU PPWR (Regulation (EU) 2025/40) | Sales vs Grouped vs Transport vs E-commerce](/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions.md): A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar --- --- title: "PPWR FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/faq" source_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/faq" author: "Sorena AI" description: "A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "PPWR FAQ" - "Regulation (EU) 2025/40 FAQ" - "PPWR when does it apply 12 August 2026" - "PPWR PFAS food contact packaging" - "PPWR labelling requirements Article 12 Article 13" - "PPWR empty space ratio 50% Article 24" - "PPWR Annex V restrictions Article 25" - "PPWR reuse targets Article 29 40% 2030 70% 2040" - "PPWR take-away refill obligation Article 32" - "PPWR" - "FAQ" - "Regulation (EU) 2025/40" - "Labelling" - "Reuse and refill" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # PPWR FAQ A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions. *PPWR* *FAQ* ## EU Packaging and Packaging Waste Regulation (PPWR) FAQ Fast answers to the PPWR questions that block delivery. Grounded in Regulation (EU) 2025/40, with practical implementation implications. This FAQ is written for implementation teams (packaging, procurement, compliance, and operations). It focuses on the decisions you need to make, the dates that drive them, and the evidence you should keep so your PPWR compliance is defensible. ## When does the PPWR apply? Regulation (EU) 2025/40 applies from 12 August 2026. Treat 12 Aug 2026 as the first day you need a working PPWR compliance system (scope map, supplier evidence controls, and retrievable documentation). - Date to remember: 12 Aug 2026 (application) - Practical implication: don't wait for 2030 - some controls and restrictions start earlier - Use: the timeline and calendar pages to plan phase-in ## Does PPWR replace the Packaging Directive (94/62/EC)? Yes. PPWR repeals Directive 94/62/EC with effect from 12 August 2026, with specific transitional provisions for some obligations. If you currently run a Directive 94/62/EC compliance program, plan a controlled transition (definitions, documentation, and labelling references can shift). - Replace old references in internal policies and supplier packs - Keep a crosswalk for auditors and internal stakeholders - Check the PPWR transitional provisions if you rely on legacy requirements ## What changes in 2030 under PPWR? 2030 is a concentration point: excessive packaging limits, restrictions on certain packaging formats, and reuse targets begin. If you wait until 2029, you will likely miss the redesign + supplier requalification window. - Empty space ratio max 50% for grouped/transport/e-commerce packaging (Article 24) (with timing linked to methodology) - Restrictions on certain packaging formats (Annex V) from 1 Jan 2030 (Article 25) - Reuse targets for transport packaging, grouped packaging, and beverages from 1 Jan 2030 (Article 29) - Retailers >400 m2 should endeavour to dedicate 10% sales area to refill stations from 1 Jan 2030 (Article 28) ## Do PFAS rules apply to all packaging? PPWR sets explicit PFAS thresholds for food-contact packaging and requires substances of concern to be minimised. In practice, treat PFAS as a critical characteristic for food-contact packaging and build a supplier evidence + verification plan. - Food-contact PFAS thresholds apply from 12 Aug 2026 (Article 5) - Heavy metals sum limit also applies (Article 5) - Operational requirement: declarations alone are rarely sufficient for high-risk materials - plan verification ## What are the reuse targets (Article 29) - are there numbers? Yes. PPWR sets numeric targets for certain packaging categories, with higher 'endeavour' shares in 2040. Targets vary by packaging type - build your packaging classification first so you know which targets apply. - Transport packaging (pallets, crates, drums, etc.): at least 40% reusable within a reuse system from 1 Jan 2030; endeavour 70% from 1 Jan 2040 - Grouped packaging boxes (excluding cardboard) used as distribution units: at least 10% reusable from 1 Jan 2030; endeavour 25% from 1 Jan 2040 - Beverages at final distributors: at least 10% available in reusable packaging from 1 Jan 2030; endeavour 40% from 1 Jan 2040 ## How will reuse targets be calculated and proved? PPWR requires implementing acts to set the methodology for calculating the Article 29 reuse targets. Even before the methodology is final, you can prepare your data model: count equivalent units, track reusable vs non-reusable, and map reuse systems. - By 30 Jun 2027: implementing acts establish the methodology (Article 30) - Proof obligation timing: demonstration applies from 1 Jan 2030 or 18 months after the implementing act enters into force (whichever is later) - Reporting: annual reporting to competent authorities, submitted within 6 months after year end; first reporting year is 2030 (Article 31) ## What are the take-away obligations for restaurants and cafes (HORECA)? PPWR introduces two distinct obligations: (1) a refill/BYO container system and (2) an option to obtain products in reusable packaging within a reuse system. These are operational obligations - plan signage, staff training, hygiene rules, and packaging system partners. - By 12 Feb 2027: provide a system for consumers to bring their own container for take-away beverages and ready-prepared food (Article 32) - By 12 Feb 2028: give consumers the option of reusable packaging within a reuse system (Article 33) - Pricing rule: no higher cost and no less favourable conditions for refill/reuse options ## When do harmonised labels apply (Article 12-13)? PPWR introduces harmonised composition labels and aligned waste receptacle labels. The phase-in is linked to implementing acts (specifications). Plan for label governance now (artwork control + QR/digital payload control) so you can adopt the harmonised specs without chaos. - Implementing acts due by 12 Aug 2026 for labelling specifications (Article 12-13) - Packaging composition label applies from 12 Aug 2028 or 24 months after implementing acts (whichever is later) - Reusable packaging label applies from 12 Feb 2029 or 30 months after implementing acts (whichever is later) ## What is the "empty space ratio" and why does it matter? PPWR sets a maximum empty space ratio for grouped, transport, and e-commerce packaging and requires empty space in sales packaging to be reduced to the minimum necessary. This is measurable and highly visible - expect it to be an enforcement focus. - Methodology: implementing acts due by 12 Feb 2028 (Article 24) - Max empty space ratio: 50% by 1 Jan 2030 (or later depending on methodology timing) for grouped/transport/e-commerce packaging - Filling materials count as empty space in the calculation ## What evidence should we keep for PPWR compliance? Your evidence should be retrievable per packaging unit (and for each market variant). If you can't retrieve the pack quickly, you won't be able to defend your claim. Make evidence storage part of the release workflow for packaging changes. - Packaging BOM + component specs + supplier chain - Supplier declarations and (where needed) test reports (PFAS/chemicals, recycled content verification) - Recyclability assessment results and decision records - Artwork approvals and label claim substantiation - Reuse/refill system participation evidence and target calculation files *Recommended next step* *Placement: after the FAQ section* ## Use EU Packaging and Packaging Waste Regulation (PPWR) FAQ as a cited research workflow Research Copilot can take EU Packaging and Packaging Waste Regulation (PPWR) FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU Packaging and Packaging Waste Regulation (PPWR) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Packaging and Packaging Waste Regulation (PPWR) FAQ](/solutions/research-copilot.md): Start from EU Packaging and Packaging Waste Regulation (PPWR) FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Packaging and Packaging Waste Regulation (PPWR)](/contact.md): Review your current process, evidence gaps, and next steps for EU Packaging and Packaging Waste Regulation (PPWR) FAQ. ## Primary sources - [Regulation (EU) 2025/40 on packaging and packaging waste (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2025/40/oj?ref=sorena.io) - Primary source for application date, empty space ratio, reuse/refill obligations, labelling phase-in, and penalty scaffolding. - [European Commission - Packaging & Packaging Waste Regulation overview](https://environment.ec.europa.eu/topics/waste-and-recycling/packaging-waste/packaging-packaging-waste-regulation_en?ref=sorena.io) - High-level overview and context. - [Register of delegated and implementing acts (European Commission)](https://webgate.ec.europa.eu/regdel/?ref=sorena.io) - Track implementing acts that affect labelling and calculation methodologies. ## Related Topic Guides - [Applicability Test | EU Packaging and Packaging Waste Regulation (PPWR) | Regulation (EU) 2025/40 Scope + Roles](/artifacts/eu/packaging-waste-regulation/applicability-test.md): A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging. - [Labelling and Consumer Information | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels, QR/Digital Marking, DRS](/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info.md): A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers. - [PFAS and Restricted Substances | EU PPWR (Regulation (EU) 2025/40) | Article 5 PFAS Thresholds for Food-Contact Packaging](/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances.md): A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits. - [PPWR Compliance Checklist | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40)](/artifacts/eu/packaging-waste-regulation/checklist.md): An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals. - [PPWR Compliance Guide | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40) | Evidence, Conformity, Enforcement](/artifacts/eu/packaging-waste-regulation/compliance.md): A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging. - [PPWR Deadlines and Compliance Calendar | Regulation (EU) 2025/40 | 11 February 2025, 12 August 2026, 1 January 2030](/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar.md): A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026. - [PPWR Labelling Checklist | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels + QR/Digital Carriers](/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist.md): An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking. - [PPWR Penalties and Fines | Regulation (EU) 2025/40 Article 68 Enforcement and Administrative Fines](/artifacts/eu/packaging-waste-regulation/penalties-and-fines.md): A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027. - [PPWR Recyclability Assessment Template | Regulation (EU) 2025/40 | Article 6 Evidence Pack + Grade A/B/C](/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template.md): A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material). - [PPWR Timeline and Deadlines | Regulation (EU) 2025/40 Roadmap | 2025 to 2040](/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines.md): A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028. - [PPWR vs ESPR | Packaging and Packaging Waste Regulation (EU) 2025/40 vs Ecodesign for Sustainable Products Regulation (EU) 2024/1781](/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr.md): A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space. - [Recyclability and Design Requirements | EU PPWR (Regulation (EU) 2025/40) | Article 6 Recyclability Grades A/B/C + Design-for-Recycling](/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements.md): A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components. - [Requirements | EU PPWR (Regulation (EU) 2025/40) | Recyclability (Article 6), Recycled Content (Article 7), Labelling (Article 12), PFAS (Article 5)](/artifacts/eu/packaging-waste-regulation/requirements.md): A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits. - [Reuse and Refill Targets | EU PPWR (Regulation (EU) 2025/40) | Article 28-33 Refill Rules, Article 29 Reuse Targets (40% 2030, 70% 2040)](/artifacts/eu/packaging-waste-regulation/reuse-refill-targets.md): A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging. - [Scope and Packaging Definitions | EU PPWR (Regulation (EU) 2025/40) | Sales vs Grouped vs Transport vs E-commerce](/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions.md): A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/packaging-waste-regulation/faq --- --- title: "Labelling and Consumer Information" canonical_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info" source_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info" author: "Sorena AI" description: "A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "PPWR labelling requirements" - "Article 12 labelling of packaging" - "harmonised label material composition PPWR 2028" - "reusable packaging label PPWR 2029" - "QR code digital data carrier PPWR" - "digital marking material composition PPWR 2026" - "substances of concern digital marking PPWR 2030" - "Article 13 waste receptacle labels" - "deposit return system label PPWR" - "PPWR" - "Labelling" - "Digital marking" - "Article 12" - "Article 13" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Labelling and Consumer Information A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers. *Article 12-13* *Labelling* ## EU Packaging and Packaging Waste Regulation (PPWR) Labelling and Consumer Information Build labels and digital marking workflows you can scale across SKUs. Output: compliant artwork, QR/digital payloads, and a release process with evidence. PPWR labelling is not just a marketing exercise - it is a harmonised system designed to improve sorting, enable reuse systems, and communicate deposit-and-return requirements. The risk is twofold: (1) non-compliant labels and (2) confusing or misleading labels that create enforcement and consumer-trust issues. Use this page to implement Article 12-13 as a release-ready workflow. ## What PPWR requires for packaging labels (Article 12) Article 12 introduces a harmonised label containing information on material composition to facilitate consumer sorting, plus specific requirements for compostable packaging messaging and deposit-bearing packaging labels. - Harmonised composition label: packaging placed on the market must carry the label from 12 Aug 2028 or 24 months after implementing acts (whichever is later). - Compostable packaging label: for specified compostable packaging, the label must indicate compostable, not suitable for home composting, and not to be discarded in nature. - DRS marking: packaging subject to deposit-and-return systems must be marked with a clear, unambiguous label; a harmonised colour label may be introduced via implementing acts. - Digital option: economic operators may include a QR code or other standardised, open digital data carrier with guidance on disposal destinations for components. ## Reusable packaging labelling (and why QR/digital carriers matter) Reusable packaging has additional labelling requirements and is expected to support tracking/rotation calculation where feasible. - Reusable label: reusable packaging placed on the market from 12 Feb 2029 (or 30 months after implementing acts) must bear a label informing users that it is reusable. - QR/digital carrier: provide information on reuse systems, collection points, and (where feasible) tracking of trips/rotations. - Point-of-sale differentiation: reusable sales packaging should be clearly distinguished from single-use packaging. - Edge case: open-loop systems without a system operator can have specific derogations; document which model you use. ## Digital marking methodologies (composition + substances of concern) PPWR anticipates standardised, open digital marking technologies to identify material composition and (later) substances of concern. Design your data model now so you're not rebuilding later. - By 12 Aug 2026: implementing acts establish methodology for identifying material composition via digital marking (including composite packaging and components). - By 1 Jan 2030: implementing acts establish methodology for identifying substances of concern via digital marking (including name and concentration per material). - Practical implication: build a packaging data model that can carry composition, component destination, and substances metadata per component. ## Waste receptacle labels (Article 13): align consumer labels with bin labels Member States must ensure harmonised labels are affixed/printed/engraved on packaging waste receptacles, aligned with packaging labels. - Phase-in: by 12 Aug 2028 or 30 months after implementing acts (whichever is later), receptacles must carry harmonised labels. - Implementing acts: by 12 Aug 2026, the Commission adopts specifications for receptacle labelling formats. - Operational implication: ensure packaging label claims and consumer instructions match actual collection systems in your target markets. ## Build a labelling release workflow (what 'done' means) Treat labelling as a controlled release: artwork is evidence. If you can't show a decision record and a data payload, you can't defend the label. - Artwork control: approved label variants per SKU/market, with versioning and traceability. - Digital payload control: QR/data carrier destinations, languages, and accessibility checks. - Claims control: avoid misleading labels; if you make environmental claims, ensure they exceed minimum legal requirements and are properly scoped. - Evidence pack: store implementing-act references used, internal approvals, and samples/photos for each released label variant. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU Packaging and Packaging Waste Regulation (PPWR) Labelling and Consumer Information across ESG workflows ESG Compliance can take EU Packaging and Packaging Waste Regulation (PPWR) Labelling and Consumer Information from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU Packaging and Packaging Waste Regulation (PPWR) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Packaging and Packaging Waste Regulation (PPWR) Labelling and Consumer Information](/solutions/esg-compliance.md): Start from EU Packaging and Packaging Waste Regulation (PPWR) Labelling and Consumer Information and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Packaging and Packaging Waste Regulation (PPWR)](/contact.md): Review your current process, evidence gaps, and next steps for EU Packaging and Packaging Waste Regulation (PPWR) Labelling and Consumer Information. ## Primary sources - [Regulation (EU) 2025/40 on packaging and packaging waste (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2025/40/oj?ref=sorena.io) - Primary source for Article 12 packaging labels, Article 13 waste receptacle labels, and the implementing act timelines. - [European Commission - Packaging & Packaging Waste Regulation overview](https://environment.ec.europa.eu/topics/waste-and-recycling/packaging-waste/packaging-packaging-waste-regulation_en?ref=sorena.io) - Policy overview and high-level implementation context. - [Register of delegated and implementing acts (European Commission)](https://webgate.ec.europa.eu/regdel/?ref=sorena.io) - Track labelling and digital marking implementing acts under PPWR. ## Related Topic Guides - [Applicability Test | EU Packaging and Packaging Waste Regulation (PPWR) | Regulation (EU) 2025/40 Scope + Roles](/artifacts/eu/packaging-waste-regulation/applicability-test.md): A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging. - [PFAS and Restricted Substances | EU PPWR (Regulation (EU) 2025/40) | Article 5 PFAS Thresholds for Food-Contact Packaging](/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances.md): A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits. - [PPWR Compliance Checklist | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40)](/artifacts/eu/packaging-waste-regulation/checklist.md): An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals. - [PPWR Compliance Guide | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40) | Evidence, Conformity, Enforcement](/artifacts/eu/packaging-waste-regulation/compliance.md): A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging. - [PPWR Deadlines and Compliance Calendar | Regulation (EU) 2025/40 | 11 February 2025, 12 August 2026, 1 January 2030](/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar.md): A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026. - [PPWR FAQ | Regulation (EU) 2025/40 Packaging and Packaging Waste Questions (Dates, PFAS, Labelling, Reuse Targets)](/artifacts/eu/packaging-waste-regulation/faq.md): A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions. - [PPWR Labelling Checklist | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels + QR/Digital Carriers](/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist.md): An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking. - [PPWR Penalties and Fines | Regulation (EU) 2025/40 Article 68 Enforcement and Administrative Fines](/artifacts/eu/packaging-waste-regulation/penalties-and-fines.md): A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027. - [PPWR Recyclability Assessment Template | Regulation (EU) 2025/40 | Article 6 Evidence Pack + Grade A/B/C](/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template.md): A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material). - [PPWR Timeline and Deadlines | Regulation (EU) 2025/40 Roadmap | 2025 to 2040](/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines.md): A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028. - [PPWR vs ESPR | Packaging and Packaging Waste Regulation (EU) 2025/40 vs Ecodesign for Sustainable Products Regulation (EU) 2024/1781](/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr.md): A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space. - [Recyclability and Design Requirements | EU PPWR (Regulation (EU) 2025/40) | Article 6 Recyclability Grades A/B/C + Design-for-Recycling](/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements.md): A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components. - [Requirements | EU PPWR (Regulation (EU) 2025/40) | Recyclability (Article 6), Recycled Content (Article 7), Labelling (Article 12), PFAS (Article 5)](/artifacts/eu/packaging-waste-regulation/requirements.md): A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits. - [Reuse and Refill Targets | EU PPWR (Regulation (EU) 2025/40) | Article 28-33 Refill Rules, Article 29 Reuse Targets (40% 2030, 70% 2040)](/artifacts/eu/packaging-waste-regulation/reuse-refill-targets.md): A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging. - [Scope and Packaging Definitions | EU PPWR (Regulation (EU) 2025/40) | Sales vs Grouped vs Transport vs E-commerce](/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions.md): A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info --- --- title: "PPWR Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/penalties-and-fines" author: "Sorena AI" description: "A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "PPWR penalties" - "PPWR fines" - "Regulation (EU) 2025/40 penalties" - "Article 68 PPWR" - "PPWR administrative fines Articles 24 to 29" - "PPWR enforcement" - "PPWR empty space ratio penalty risk" - "PPWR Annex V restrictions enforcement" - "PPWR reuse targets enforcement" - "PPWR" - "Penalties" - "Administrative fines" - "Enforcement" - "Article 68" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # PPWR Penalties and Fines A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027. *Article 68* *Enforcement* ## EU Packaging and Packaging Waste Regulation (PPWR) Penalties and Fines Reduce PPWR enforcement risk with evidence, not guesswork. Focus: Article 68 penalties scaffolding + what to build so you can defend compliance decisions. PPWR enforcement is national, but the failure patterns are universal: missing evidence per packaging unit, uncontrolled label claims, and "we thought 2030 was far away" planning. This page explains what Article 68 requires and how to design a compliance system that reduces penalty exposure and shortens authority-response time. ## What Article 68 says (and why it matters) Article 68 requires Member States to lay down penalties for infringements and ensure they are effective, proportionate and dissuasive. It also explicitly requires that penalties for failure to comply with Articles 24-29 include administrative fines (or an equivalent court-based fining mechanism where administrative fines don't exist). - By 12 Feb 2027: Member States must lay down penalties rules and notify the Commission - Administrative fines must exist for Articles 24-29 failures (excessive packaging / empty space, restricted formats, reuse targets, refill/reuse obligations) - Practical implication: 2026-2027 is when you should be able to prove compliance on request ## What regulators can check quickly (high-risk enforcement signals) Some PPWR topics are easy to see and measure, so they tend to become early enforcement focus areas. If you design controls around these, you also improve performance on the harder topics (recyclability grading, recycled content). - Labelling and consumer instructions: incorrect or misleading labels, missing mandatory labels, inconsistent disposal instructions - Empty space ratio: excessive packaging and void-fill that exceeds thresholds or fails methodology - Restricted formats: packaging formats covered by Annex V restrictions (from 2030) that remain in use - Reuse/refill obligations: take-away refill/reuse offer obligations and reuse target achievement evidence *Recommended next step* *Placement: after the enforcement section* ## Use EU Packaging and Packaging Waste Regulation (PPWR) Penalties and Fines as a cited research workflow Research Copilot can take EU Packaging and Packaging Waste Regulation (PPWR) Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Packaging and Packaging Waste Regulation (PPWR) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Packaging and Packaging Waste Regulation (PPWR) Penalties and Fines](/solutions/research-copilot.md): Start from EU Packaging and Packaging Waste Regulation (PPWR) Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Packaging and Packaging Waste Regulation (PPWR)](/contact.md): Review your current process, evidence gaps, and next steps for EU Packaging and Packaging Waste Regulation (PPWR) Penalties and Fines. ## Penalty drivers for Articles 24-29 (plan the controls now) Article 68 singles out Articles 24-29 for fines exposure. That should inform your compliance prioritisation. Build measurable controls and keep proof that your packaging and operations meet the thresholds and targets. - Article 24 excessive packaging: empty space ratio calculations, exemptions logic, and packaging design decisions - Article 25 restrictions: product/category mapping and documented justification for any exemptions - Article 28-33 refill/reuse: operational procedures, signage, pricing parity proof, and reuse system participation - Article 29 reuse targets: category classification, equivalent-unit counts, and data integrity checks ## A defensible risk-reduction plan (what to implement) Penalty exposure falls when you can show: a controlled system, owner accountability, and a retrievable evidence pack per packaging unit. The objective is not "perfect documentation", but "fast, consistent answers backed by records". - Evidence vault: packaging BOM + specs + supplier declarations + verification tests (where needed) - Controlled release: artwork approval workflow + label claims substantiation + QR/digital payload governance - Supplier controls: restricted substances (PFAS for food-contact), heavy metals, recycled content evidence, and change notification - Readiness drills: simulate authority requests and measure response time and completeness - Exception register: time-bound exceptions with corrective actions and approval logs ## If you receive an authority request: a fast response playbook Speed and consistency matter. The worst-case outcome is an inconsistent story across teams (legal says one thing, packaging says another, procurement can't provide evidence). Use a single "packaging unit file" as the source of truth for your response. - Identify the packaging unit(s) and market(s) in scope; freeze changes while responding - Export the evidence pack: BOM/specs, label variants, supplier declarations, tests, reuse system evidence (if applicable) - Provide a decision narrative: what applies, what was done, and why (with dates and approvals) - Log the request and update your controls if the request reveals gaps ## Primary sources - [Regulation (EU) 2025/40 on packaging and packaging waste (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2025/40/oj?ref=sorena.io) - Primary source for Article 68 penalties, the 12 Feb 2027 penalties deadline, and the Articles 24-29 topics called out for administrative fines. - [European Commission - Packaging & Packaging Waste Regulation overview](https://environment.ec.europa.eu/topics/waste-and-recycling/packaging-waste/packaging-packaging-waste-regulation_en?ref=sorena.io) - Policy overview and context for enforcement priorities. ## Related Topic Guides - [Applicability Test | EU Packaging and Packaging Waste Regulation (PPWR) | Regulation (EU) 2025/40 Scope + Roles](/artifacts/eu/packaging-waste-regulation/applicability-test.md): A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging. - [Labelling and Consumer Information | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels, QR/Digital Marking, DRS](/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info.md): A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers. - [PFAS and Restricted Substances | EU PPWR (Regulation (EU) 2025/40) | Article 5 PFAS Thresholds for Food-Contact Packaging](/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances.md): A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits. - [PPWR Compliance Checklist | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40)](/artifacts/eu/packaging-waste-regulation/checklist.md): An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals. - [PPWR Compliance Guide | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40) | Evidence, Conformity, Enforcement](/artifacts/eu/packaging-waste-regulation/compliance.md): A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging. - [PPWR Deadlines and Compliance Calendar | Regulation (EU) 2025/40 | 11 February 2025, 12 August 2026, 1 January 2030](/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar.md): A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026. - [PPWR FAQ | Regulation (EU) 2025/40 Packaging and Packaging Waste Questions (Dates, PFAS, Labelling, Reuse Targets)](/artifacts/eu/packaging-waste-regulation/faq.md): A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions. - [PPWR Labelling Checklist | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels + QR/Digital Carriers](/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist.md): An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking. - [PPWR Recyclability Assessment Template | Regulation (EU) 2025/40 | Article 6 Evidence Pack + Grade A/B/C](/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template.md): A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material). - [PPWR Timeline and Deadlines | Regulation (EU) 2025/40 Roadmap | 2025 to 2040](/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines.md): A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028. - [PPWR vs ESPR | Packaging and Packaging Waste Regulation (EU) 2025/40 vs Ecodesign for Sustainable Products Regulation (EU) 2024/1781](/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr.md): A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space. - [Recyclability and Design Requirements | EU PPWR (Regulation (EU) 2025/40) | Article 6 Recyclability Grades A/B/C + Design-for-Recycling](/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements.md): A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components. - [Requirements | EU PPWR (Regulation (EU) 2025/40) | Recyclability (Article 6), Recycled Content (Article 7), Labelling (Article 12), PFAS (Article 5)](/artifacts/eu/packaging-waste-regulation/requirements.md): A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits. - [Reuse and Refill Targets | EU PPWR (Regulation (EU) 2025/40) | Article 28-33 Refill Rules, Article 29 Reuse Targets (40% 2030, 70% 2040)](/artifacts/eu/packaging-waste-regulation/reuse-refill-targets.md): A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging. - [Scope and Packaging Definitions | EU PPWR (Regulation (EU) 2025/40) | Sales vs Grouped vs Transport vs E-commerce](/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions.md): A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/packaging-waste-regulation/penalties-and-fines --- --- title: "PFAS and Restricted Substances" canonical_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances" source_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances" author: "Sorena AI" description: "A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "PPWR PFAS" - "PFAS food contact packaging PPWR" - "Article 5 PFAS thresholds 25 ppb 250 ppb 50 ppm" - "PPWR restricted substances" - "heavy metals 100 mg/kg packaging" - "substances of concern minimisation PPWR" - "PPWR technical documentation Annex VII" - "PPWR" - "PFAS" - "Food contact packaging" - "Substances of concern" - "Article 5" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # PFAS and Restricted Substances A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits. *Article 5* *Chemicals* ## EU Packaging and Packaging Waste Regulation (PPWR) PFAS and Restricted Substances Meet PFAS thresholds for food-contact packaging and control substances of concern. Output: a supplier evidence strategy + testing plan + technical documentation pack you can defend. PPWR addresses chemicals in packaging from two angles: (1) minimise substances of concern and protect recycling loops, and (2) set explicit limits for certain substances, including PFAS thresholds for food-contact packaging from the regulation's application date. This page focuses on operational compliance: inventory, supplier controls, testing, and documentation. ## What Article 5 requires (practical interpretation) Article 5 requires packaging to be manufactured so the presence and concentration of substances of concern is minimised, including impacts on secondary raw materials and microplastics. It also sets specific limit values for certain substances and PFAS in food-contact packaging. - Substances-of-concern minimisation: treat as a design + procurement control, not only a compliance statement. - Heavy metals: the sum of lead, cadmium, mercury and hexavalent chromium in packaging/components must not exceed 100 mg/kg. - Food-contact PFAS: from 12 Aug 2026, food-contact packaging cannot be placed on the market if PFAS are at or above specified thresholds (unless prohibited under another EU act). ## PFAS thresholds for food-contact packaging (what to implement) PPWR defines PFAS thresholds using targeted analysis and total PFAS/fluorine metrics. Translate these into a supplier + testing control. Practical approach: treat PFAS as a critical characteristic for food-contact packaging and create an escalation path for exceptions and risk acceptance. - Thresholds include: 25 ppb for any PFAS (targeted analysis), 250 ppb for the sum of PFAS (targeted analysis, precursors where applicable), and 50 ppm for PFAS (including polymeric PFAS). - If total fluorine exceeds 50 mg/kg, upstream operators may need to provide proof of fluorine measured as PFAS or non-PFAS for technical documentation. - Action: define which packaging units are 'food-contact' and ensure suppliers can provide compliant declarations and test results. ## Supplier evidence strategy (what to require and how to verify) Most teams fail because they rely on generic declarations. Build tiered evidence requirements based on risk: food-contact, coatings, inks, and barrier materials should have higher evidence rigor. - Supplier declarations: material composition, PFAS statement, heavy metals statement, and substances-of-concern disclosures. - Testing strategy: define when you need lab tests (e.g., new supplier, material change, high-risk coatings). - Change control: require notification for changes in formulation, coating, ink systems, or fluorinated processing aids. - Corrective actions: what happens when a batch fails - quarantine, recall considerations, and customer/regulator comms. ## Technical documentation checklist (Annex VII mindset) Article 5 requires compliance to be demonstrated in technical documentation. The most important design decision is how you structure documentation so it is retrievable per packaging unit. - Unit-level dossier: BOM, suppliers, and material specifications. - Compliance evidence: declarations, test reports, sampling plan, and results. - Decision log: what thresholds apply, who approved, and what exceptions exist (with expiry dates). - Traceability: batch/lot traceability for high-risk components and food-contact lines. - Review cadence: align to supplier review cycles and any new EU restrictions or guidance. *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU Packaging and Packaging Waste Regulation (PPWR) PFAS and Restricted Substances across ESG workflows ESG Compliance can take EU Packaging and Packaging Waste Regulation (PPWR) PFAS and Restricted Substances from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU Packaging and Packaging Waste Regulation (PPWR) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Packaging and Packaging Waste Regulation (PPWR) PFAS and Restricted Substances](/solutions/esg-compliance.md): Start from EU Packaging and Packaging Waste Regulation (PPWR) PFAS and Restricted Substances and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Packaging and Packaging Waste Regulation (PPWR)](/contact.md): Review your current process, evidence gaps, and next steps for EU Packaging and Packaging Waste Regulation (PPWR) PFAS and Restricted Substances. ## Primary sources - [Regulation (EU) 2025/40 on packaging and packaging waste (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2025/40/oj?ref=sorena.io) - Primary source for Article 5 substances-of-concern minimisation, heavy metals limit, and PFAS thresholds for food-contact packaging. - [European Commission - Packaging & Packaging Waste Regulation overview](https://environment.ec.europa.eu/topics/waste-and-recycling/packaging-waste/packaging-packaging-waste-regulation_en?ref=sorena.io) - Context on the policy rationale and major measures (including PFAS focus). - [European Parliament - New EU rules to reduce, reuse and recycle packaging (press release)](https://www.europarl.europa.eu/news/en/press-room/20240419IPR20589/new-eu-rules-to-reduce-reuse-and-recycle-packaging?ref=sorena.io) - Summary of key measures including PFAS restrictions and the intent behind the requirements. ## Related Topic Guides - [Applicability Test | EU Packaging and Packaging Waste Regulation (PPWR) | Regulation (EU) 2025/40 Scope + Roles](/artifacts/eu/packaging-waste-regulation/applicability-test.md): A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging. - [Labelling and Consumer Information | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels, QR/Digital Marking, DRS](/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info.md): A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers. - [PPWR Compliance Checklist | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40)](/artifacts/eu/packaging-waste-regulation/checklist.md): An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals. - [PPWR Compliance Guide | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40) | Evidence, Conformity, Enforcement](/artifacts/eu/packaging-waste-regulation/compliance.md): A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging. - [PPWR Deadlines and Compliance Calendar | Regulation (EU) 2025/40 | 11 February 2025, 12 August 2026, 1 January 2030](/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar.md): A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026. - [PPWR FAQ | Regulation (EU) 2025/40 Packaging and Packaging Waste Questions (Dates, PFAS, Labelling, Reuse Targets)](/artifacts/eu/packaging-waste-regulation/faq.md): A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions. - [PPWR Labelling Checklist | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels + QR/Digital Carriers](/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist.md): An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking. - [PPWR Penalties and Fines | Regulation (EU) 2025/40 Article 68 Enforcement and Administrative Fines](/artifacts/eu/packaging-waste-regulation/penalties-and-fines.md): A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027. - [PPWR Recyclability Assessment Template | Regulation (EU) 2025/40 | Article 6 Evidence Pack + Grade A/B/C](/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template.md): A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material). - [PPWR Timeline and Deadlines | Regulation (EU) 2025/40 Roadmap | 2025 to 2040](/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines.md): A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028. - [PPWR vs ESPR | Packaging and Packaging Waste Regulation (EU) 2025/40 vs Ecodesign for Sustainable Products Regulation (EU) 2024/1781](/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr.md): A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space. - [Recyclability and Design Requirements | EU PPWR (Regulation (EU) 2025/40) | Article 6 Recyclability Grades A/B/C + Design-for-Recycling](/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements.md): A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components. - [Requirements | EU PPWR (Regulation (EU) 2025/40) | Recyclability (Article 6), Recycled Content (Article 7), Labelling (Article 12), PFAS (Article 5)](/artifacts/eu/packaging-waste-regulation/requirements.md): A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits. - [Reuse and Refill Targets | EU PPWR (Regulation (EU) 2025/40) | Article 28-33 Refill Rules, Article 29 Reuse Targets (40% 2030, 70% 2040)](/artifacts/eu/packaging-waste-regulation/reuse-refill-targets.md): A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging. - [Scope and Packaging Definitions | EU PPWR (Regulation (EU) 2025/40) | Sales vs Grouped vs Transport vs E-commerce](/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions.md): A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances --- --- title: "PPWR Labelling Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist" source_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist" author: "Sorena AI" description: "An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "PPWR labelling checklist" - "Article 12 checklist" - "Article 13 checklist" - "packaging composition label checklist" - "reusable packaging label checklist" - "QR code digital data carrier checklist" - "DRS label checklist" - "digital marking methodology checklist" - "PPWR" - "Checklist" - "Labelling" - "Digital marking" - "DRS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # PPWR Labelling Checklist An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking. *Checklist* *Labelling* ## EU Packaging and Packaging Waste Regulation (PPWR) Labelling Checklist Release packaging artwork with evidence and acceptance criteria. Use this checklist to prevent rework and avoid misleading labels. This checklist is designed for packaging engineering, regulatory, and brand teams releasing labels at scale. Each item includes what 'done' looks like and what evidence you should retain. ## 1) Governance and scope (owners + label inventory) Before you change labels, stabilise ownership and inventory. - Assign owners: packaging engineering, regulatory/compliance, artwork/brand, and market operations. - Create an SKU label inventory: packaging units, variants, markets, languages, and channels. - Define the label release process: approvals, versioning, sample retention, and audit trail. - Done looks like: a controlled register of label variants and release approvals. ## 2) Article 12 composition label (harmonised label readiness) Packaging must carry a harmonised label for material composition with phase-in timing defined by PPWR and implementing acts. - Confirm packaging composition per unit and per component (especially composites). - Confirm whether exemptions apply (e.g., certain transport packaging and packaging subject to DRS; check the specific rules per unit). - Ensure label uses pictograms and is understandable (including accessibility considerations). - Done looks like: artwork files + documented composition decision + sign-off record. ## 3) Reusable packaging label + QR/digital carrier Reusable packaging has additional labelling requirements and often requires a digital carrier for system information and tracking. - Confirm the packaging is reusable under PPWR criteria (rotations, reconditioning, end-of-life recyclability). - Implement reusable label and point-of-sale differentiation. - Define QR/digital payload: reuse system info, collection points, and (where feasible) tracking/rotation calculation. - Done looks like: reusable label artwork + QR payload spec + test scan report + approval record. ## 4) Deposit-and-return system (DRS) marking Deposit-bearing packaging needs clear and unambiguous marking; harmonised colour labels may be introduced via implementing acts. - Identify which SKUs/markets are DRS-covered. - Ensure DRS label is clear and unambiguous and does not create trade barriers across Member States. - If national plus harmonised colour labels apply, document how both are implemented. - Done looks like: DRS coverage matrix + artwork per market + compliance sign-off. ## 5) Digital marking readiness (composition + substances of concern) PPWR implementing acts define digital marking methodologies; build your data model and payload discipline early. - Packaging data model supports: component composition, component destination instructions, and substances-of-concern metadata. - QR/digital carrier is standardised, open, and usable across devices and accessibility contexts. - Substances-of-concern marking plan: how you will populate name + concentration per material once methodology is final. - Done looks like: payload schema + governance + test/validation procedure. ## 6) Claims control (avoid misleading environmental claims) PPWR restricts labels/marks/symbols that mislead or confuse consumers where harmonised labelling exists. - Inventory all sustainability-related claims and icons on-pack. - Validate claims exceed minimum legal requirements (where environmental claims are allowed). - Ensure claims specify scope: packaging unit vs component vs all packaging placed on the market. - Done looks like: claims register + legal review + evidence links. *Recommended next step* *Placement: after the checklist block* ## Operationalize EU Packaging and Packaging Waste Regulation (PPWR) Labelling Checklist across ESG workflows ESG Compliance can take EU Packaging and Packaging Waste Regulation (PPWR) Labelling Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Packaging and Packaging Waste Regulation (PPWR) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Packaging and Packaging Waste Regulation (PPWR) Labelling Checklist](/solutions/esg-compliance.md): Start from EU Packaging and Packaging Waste Regulation (PPWR) Labelling Checklist and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Packaging and Packaging Waste Regulation (PPWR)](/contact.md): Review your current process, evidence gaps, and next steps for EU Packaging and Packaging Waste Regulation (PPWR) Labelling Checklist. ## Primary sources - [Regulation (EU) 2025/40 on packaging and packaging waste (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2025/40/oj?ref=sorena.io) - Primary source for Article 12 packaging labels, Article 13 receptacle labels, and environmental claims constraints. - [Register of delegated and implementing acts (European Commission)](https://webgate.ec.europa.eu/regdel/?ref=sorena.io) - Track implementing acts for labelling specifications and digital marking methodologies. ## Related Topic Guides - [Applicability Test | EU Packaging and Packaging Waste Regulation (PPWR) | Regulation (EU) 2025/40 Scope + Roles](/artifacts/eu/packaging-waste-regulation/applicability-test.md): A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging. - [Labelling and Consumer Information | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels, QR/Digital Marking, DRS](/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info.md): A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers. - [PFAS and Restricted Substances | EU PPWR (Regulation (EU) 2025/40) | Article 5 PFAS Thresholds for Food-Contact Packaging](/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances.md): A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits. - [PPWR Compliance Checklist | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40)](/artifacts/eu/packaging-waste-regulation/checklist.md): An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals. - [PPWR Compliance Guide | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40) | Evidence, Conformity, Enforcement](/artifacts/eu/packaging-waste-regulation/compliance.md): A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging. - [PPWR Deadlines and Compliance Calendar | Regulation (EU) 2025/40 | 11 February 2025, 12 August 2026, 1 January 2030](/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar.md): A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026. - [PPWR FAQ | Regulation (EU) 2025/40 Packaging and Packaging Waste Questions (Dates, PFAS, Labelling, Reuse Targets)](/artifacts/eu/packaging-waste-regulation/faq.md): A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions. - [PPWR Penalties and Fines | Regulation (EU) 2025/40 Article 68 Enforcement and Administrative Fines](/artifacts/eu/packaging-waste-regulation/penalties-and-fines.md): A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027. - [PPWR Recyclability Assessment Template | Regulation (EU) 2025/40 | Article 6 Evidence Pack + Grade A/B/C](/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template.md): A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material). - [PPWR Timeline and Deadlines | Regulation (EU) 2025/40 Roadmap | 2025 to 2040](/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines.md): A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028. - [PPWR vs ESPR | Packaging and Packaging Waste Regulation (EU) 2025/40 vs Ecodesign for Sustainable Products Regulation (EU) 2024/1781](/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr.md): A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space. - [Recyclability and Design Requirements | EU PPWR (Regulation (EU) 2025/40) | Article 6 Recyclability Grades A/B/C + Design-for-Recycling](/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements.md): A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components. - [Requirements | EU PPWR (Regulation (EU) 2025/40) | Recyclability (Article 6), Recycled Content (Article 7), Labelling (Article 12), PFAS (Article 5)](/artifacts/eu/packaging-waste-regulation/requirements.md): A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits. - [Reuse and Refill Targets | EU PPWR (Regulation (EU) 2025/40) | Article 28-33 Refill Rules, Article 29 Reuse Targets (40% 2030, 70% 2040)](/artifacts/eu/packaging-waste-regulation/reuse-refill-targets.md): A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging. - [Scope and Packaging Definitions | EU PPWR (Regulation (EU) 2025/40) | Sales vs Grouped vs Transport vs E-commerce](/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions.md): A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist --- --- title: "PPWR Recyclability Assessment Template" canonical_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template" source_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template" author: "Sorena AI" description: "A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "PPWR recyclability assessment template" - "Article 6 evidence pack" - "recyclability grade A B C template" - "design for recycling assessment" - "recycled at scale assessment" - "packaging BOM recyclability" - "PPWR documentation" - "PPWR" - "Template" - "Recyclability assessment" - "Article 6" - "Evidence pack" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # PPWR Recyclability Assessment Template A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material). *Template* *Article 6* ## EU Packaging and Packaging Waste Regulation (PPWR) Recyclability Assessment Template A template you can reuse for every packaging unit. Output: a consistent assessment record with evidence links and sign-offs. This page gives you a structured template to document PPWR Article 6 recyclability. The goal is consistency: every packaging unit should produce the same sections, the same decision logic, and evidence that can be retrieved fast. ## Template: Packaging unit header (identity + scope) Use one record per packaging unit. If the packaging has variants (materials, labels, closures), treat them as separate variants with linked evidence. - Packaging unit ID, product/brand, market(s), and channel (retail/e-commerce/HORECA/B2B). - Format classification: sales / grouped / transport / e-commerce / take-away. - Use case flags: food-contact, reusable, deposit-bearing, hazardous goods transport. - Economic operator role(s): manufacturer/importer/distributor/final distributor (per legal entity). *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Packaging and Packaging Waste Regulation (PPWR) Recyclability Assessment Template in one governed evidence system SSOT can take EU Packaging and Packaging Waste Regulation (PPWR) Recyclability Assessment Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Packaging and Packaging Waste Regulation (PPWR) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Packaging and Packaging Waste Regulation (PPWR) Recyclability Assessment Template](/solutions/ssot.md): Start from EU Packaging and Packaging Waste Regulation (PPWR) Recyclability Assessment Template and keep documents, evidence, and control records in one governed system. - [Talk through EU Packaging and Packaging Waste Regulation (PPWR)](/contact.md): Review your current process, evidence gaps, and next steps for EU Packaging and Packaging Waste Regulation (PPWR) Recyclability Assessment Template. ## Template: Technical BOM and component model (integrated vs separate) Article 6 assessment differs depending on whether components are integrated or separate. Capture this explicitly. - BOM table (or link): predominant material, weights, polymers, coatings, inks, adhesives, barrier layers. - Component model: integrated components assessed together; separate components assessed separately. - Disassembly/separation assumptions: what separates under mechanical stress in transport/sorting? - Compatibility statement: do any components hinder recyclability of the main body? ## Template: Design-for-recycling (DfR) assessment (Article 6(2)(a)) Document how the unit meets the DfR criteria and which parameters were applied (category-specific). - Packaging category mapping (Annex II) + rationale. - DfR parameters applied (e.g., material separability, sorting compatibility, barrier/ink constraints, label/closure behavior). - Result: recyclability performance grade (A/B/C) per unit and per separate component. - Redesign backlog: changes required to reach target grade (ideally A/B). ## Template: Recycled-at-scale condition (Article 6(2)(b)) Capture the assumptions and evidence behind collection, sorting, and recycling at scale - and how you will update this when implementing acts are published. - Collection stream assumptions (separate collection route). - Sorting compatibility assumptions (what stream does it end up in; does it disrupt other streams). - Recycling technology maturity assumptions and output quality. - Evidence links: internal test results, external references, and supplier confirmations. ## Template: Evidence, sign-off, and change control Make the assessment auditable: who decided what, when, and based on which evidence. - Evidence links: tests, supplier declarations, design drawings, assessment worksheets. - Sign-off: packaging engineering owner + compliance owner + procurement owner. - Change control: what changes require reassessment (material change, label/ink change, closure change, supplier change). - Next review date: align to delegated/implementing act updates and product lifecycle changes. ## Primary sources - [Regulation (EU) 2025/40 on packaging and packaging waste (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2025/40/oj?ref=sorena.io) - Primary source for Article 6 recyclability conditions, component assessment rules, and grade model. - [JRC - Technical recommendations for a recyclability assessment methodology (doi:10.2760/538070)](https://data.europa.eu/doi/10.2760/538070?ref=sorena.io) - Useful technical basis for building a consistent DfR/recyclability assessment methodology. ## Related Topic Guides - [Applicability Test | EU Packaging and Packaging Waste Regulation (PPWR) | Regulation (EU) 2025/40 Scope + Roles](/artifacts/eu/packaging-waste-regulation/applicability-test.md): A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging. - [Labelling and Consumer Information | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels, QR/Digital Marking, DRS](/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info.md): A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers. - [PFAS and Restricted Substances | EU PPWR (Regulation (EU) 2025/40) | Article 5 PFAS Thresholds for Food-Contact Packaging](/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances.md): A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits. - [PPWR Compliance Checklist | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40)](/artifacts/eu/packaging-waste-regulation/checklist.md): An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals. - [PPWR Compliance Guide | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40) | Evidence, Conformity, Enforcement](/artifacts/eu/packaging-waste-regulation/compliance.md): A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging. - [PPWR Deadlines and Compliance Calendar | Regulation (EU) 2025/40 | 11 February 2025, 12 August 2026, 1 January 2030](/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar.md): A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026. - [PPWR FAQ | Regulation (EU) 2025/40 Packaging and Packaging Waste Questions (Dates, PFAS, Labelling, Reuse Targets)](/artifacts/eu/packaging-waste-regulation/faq.md): A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions. - [PPWR Labelling Checklist | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels + QR/Digital Carriers](/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist.md): An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking. - [PPWR Penalties and Fines | Regulation (EU) 2025/40 Article 68 Enforcement and Administrative Fines](/artifacts/eu/packaging-waste-regulation/penalties-and-fines.md): A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027. - [PPWR Timeline and Deadlines | Regulation (EU) 2025/40 Roadmap | 2025 to 2040](/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines.md): A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028. - [PPWR vs ESPR | Packaging and Packaging Waste Regulation (EU) 2025/40 vs Ecodesign for Sustainable Products Regulation (EU) 2024/1781](/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr.md): A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space. - [Recyclability and Design Requirements | EU PPWR (Regulation (EU) 2025/40) | Article 6 Recyclability Grades A/B/C + Design-for-Recycling](/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements.md): A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components. - [Requirements | EU PPWR (Regulation (EU) 2025/40) | Recyclability (Article 6), Recycled Content (Article 7), Labelling (Article 12), PFAS (Article 5)](/artifacts/eu/packaging-waste-regulation/requirements.md): A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits. - [Reuse and Refill Targets | EU PPWR (Regulation (EU) 2025/40) | Article 28-33 Refill Rules, Article 29 Reuse Targets (40% 2030, 70% 2040)](/artifacts/eu/packaging-waste-regulation/reuse-refill-targets.md): A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging. - [Scope and Packaging Definitions | EU PPWR (Regulation (EU) 2025/40) | Sales vs Grouped vs Transport vs E-commerce](/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions.md): A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template --- --- title: "PPWR vs ESPR" canonical_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr" source_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr" author: "Sorena AI" description: "A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "PPWR vs ESPR" - "Regulation (EU) 2025/40 vs Regulation (EU) 2024/1781" - "packaging waste regulation vs ecodesign regulation" - "PPWR and digital product passport" - "ESPR DPP and packaging data" - "PPWR labelling vs DPP" - "PPWR recyclability vs ESPR ecodesign" - "PPWR" - "ESPR" - "Digital Product Passport" - "Ecodesign" - "Packaging compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # PPWR vs ESPR A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space. *PPWR vs ESPR* *EU* ## EU Packaging and Packaging Waste Regulation (PPWR) PPWR vs ESPR Two EU regulations, one real-world delivery problem. Use this page to align packaging compliance (PPWR) with product ecodesign and DPP work (ESPR). Implementation teams often treat PPWR and ESPR as separate universes. In practice, both programs pull from the same foundation: a reliable product + packaging data model, supplier evidence, and controlled releases. This page clarifies what belongs to PPWR, what belongs to ESPR, where you can reuse work safely, and how to avoid mixing up packaging labels with product Digital Product Passports. ## Scope difference in one sentence PPWR (Regulation (EU) 2025/40) is packaging-specific: it regulates packaging design, materials, labelling, reuse/refill, and packaging waste prevention. ESPR (Regulation (EU) 2024/1781) is a framework for ecodesign requirements for products placed on the EU market and enables Digital Product Passports (DPP) for product groups via future delegated acts. - PPWR: packaging outcomes (recyclability, recycled content, substances constraints, labelling, empty space, restrictions, reuse/refill) - ESPR: product outcomes (ecodesign requirements by product group; information requirements; DPP infrastructure) - If you sell products with packaging, you may need both programs - but the deliverables differ *Recommended next step* *Placement: after the comparison section* ## Use EU Packaging and Packaging Waste Regulation (PPWR) PPWR vs ESPR as a cited research workflow Research Copilot can take EU Packaging and Packaging Waste Regulation (PPWR) PPWR vs ESPR from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Packaging and Packaging Waste Regulation (PPWR) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Packaging and Packaging Waste Regulation (PPWR) PPWR vs ESPR](/solutions/research-copilot.md): Start from EU Packaging and Packaging Waste Regulation (PPWR) PPWR vs ESPR and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Packaging and Packaging Waste Regulation (PPWR)](/contact.md): Review your current process, evidence gaps, and next steps for EU Packaging and Packaging Waste Regulation (PPWR) PPWR vs ESPR. ## Where teams get confused (and how to keep it clean) The confusion usually comes from mixing 'information about packaging' with 'product passport information'. PPWR has harmonised labels and digital marking methodologies for packaging composition and (later) substances of concern. ESPR can require product information and DPPs for certain product groups. - Packaging label vs product DPP: labels are consumer-facing packaging requirements; DPP is a product-information mechanism for supply chain and market surveillance - Recycled content: PPWR has packaging-specific recycled content targets for certain plastic packaging parts; ESPR may set product ecodesign requirements that include recycled content information - Substances disclosure: PPWR targets substances of concern in packaging and digital marking methodologies; ESPR can require product information disclosures - keep vocab and data definitions consistent ## How to run one combined program (without duplicating effort) You can share the foundation while keeping compliance outputs distinct. The foundation is data + governance. Build one 'product + packaging sustainability data backbone' and generate PPWR and ESPR outputs from it. - Shared foundation: product identifiers + packaging unit identifiers, BOMs, supplier declarations, test evidence, change-control history - PPWR outputs: packaging technical documentation, label variants and digital marking payloads, reuse/refill evidence, empty space ratio calculations - ESPR outputs: product ecodesign requirement compliance evidence and (where required) DPP datasets/registrations - Governance: one release gate that ensures packaging label changes and product DPP updates stay consistent ## A practical crosswalk (what to build first) If you need an execution order that works across both regulations, start with the parts that are always needed: inventory, classification, and evidence retrieval. Then add the regulation-specific layers (PPWR packaging workstreams; ESPR product group readiness). - Inventory: product portfolio + packaging portfolio (packaging as units with components) - Evidence: supplier declaration pack (materials, restricted substances, recycled content methodology) + verification plan - Packaging layer (PPWR): recyclability assessment workflow + label release governance + reuse/refill program planning - Product layer (ESPR): monitor delegated acts for your product groups and prepare DPP-capable data structures ## SEO-friendly takeaway: what to tell stakeholders If stakeholders ask "are PPWR and ESPR the same thing?", the correct answer is: no - but you should not run two separate data programs. Run one data and governance program, produce two sets of compliance outputs. - PPWR vs ESPR: different scopes, different outputs - One shared backbone: product + packaging data model and supplier evidence - Avoid rework: unify identifiers, declarations, and change control - Avoid confusion: separate consumer labels (PPWR) from product DPP artefacts (ESPR) ## Primary sources - [Regulation (EU) 2025/40 on packaging and packaging waste (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2025/40/oj?ref=sorena.io) - Primary source for packaging-specific obligations (PPWR). - [Regulation (EU) 2024/1781 establishing a framework for ecodesign requirements for sustainable products (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2024/1781/oj?ref=sorena.io) - Primary source for ESPR framework and Digital Product Passport enablement. - [European Commission - Ecodesign for Sustainable Products Regulation (ESPR) overview](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en?ref=sorena.io) - Policy overview and implementation context for ESPR and DPP. - [European Commission - Packaging & Packaging Waste Regulation overview](https://environment.ec.europa.eu/topics/waste-and-recycling/packaging-waste/packaging-packaging-waste-regulation_en?ref=sorena.io) - Policy overview and implementation context for PPWR. ## Related Topic Guides - [Applicability Test | EU Packaging and Packaging Waste Regulation (PPWR) | Regulation (EU) 2025/40 Scope + Roles](/artifacts/eu/packaging-waste-regulation/applicability-test.md): A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging. - [Labelling and Consumer Information | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels, QR/Digital Marking, DRS](/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info.md): A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers. - [PFAS and Restricted Substances | EU PPWR (Regulation (EU) 2025/40) | Article 5 PFAS Thresholds for Food-Contact Packaging](/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances.md): A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits. - [PPWR Compliance Checklist | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40)](/artifacts/eu/packaging-waste-regulation/checklist.md): An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals. - [PPWR Compliance Guide | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40) | Evidence, Conformity, Enforcement](/artifacts/eu/packaging-waste-regulation/compliance.md): A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging. - [PPWR Deadlines and Compliance Calendar | Regulation (EU) 2025/40 | 11 February 2025, 12 August 2026, 1 January 2030](/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar.md): A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026. - [PPWR FAQ | Regulation (EU) 2025/40 Packaging and Packaging Waste Questions (Dates, PFAS, Labelling, Reuse Targets)](/artifacts/eu/packaging-waste-regulation/faq.md): A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions. - [PPWR Labelling Checklist | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels + QR/Digital Carriers](/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist.md): An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking. - [PPWR Penalties and Fines | Regulation (EU) 2025/40 Article 68 Enforcement and Administrative Fines](/artifacts/eu/packaging-waste-regulation/penalties-and-fines.md): A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027. - [PPWR Recyclability Assessment Template | Regulation (EU) 2025/40 | Article 6 Evidence Pack + Grade A/B/C](/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template.md): A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material). - [PPWR Timeline and Deadlines | Regulation (EU) 2025/40 Roadmap | 2025 to 2040](/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines.md): A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028. - [Recyclability and Design Requirements | EU PPWR (Regulation (EU) 2025/40) | Article 6 Recyclability Grades A/B/C + Design-for-Recycling](/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements.md): A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components. - [Requirements | EU PPWR (Regulation (EU) 2025/40) | Recyclability (Article 6), Recycled Content (Article 7), Labelling (Article 12), PFAS (Article 5)](/artifacts/eu/packaging-waste-regulation/requirements.md): A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits. - [Reuse and Refill Targets | EU PPWR (Regulation (EU) 2025/40) | Article 28-33 Refill Rules, Article 29 Reuse Targets (40% 2030, 70% 2040)](/artifacts/eu/packaging-waste-regulation/reuse-refill-targets.md): A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging. - [Scope and Packaging Definitions | EU PPWR (Regulation (EU) 2025/40) | Sales vs Grouped vs Transport vs E-commerce](/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions.md): A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr --- --- title: "Recyclability and Design Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements" source_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements" author: "Sorena AI" description: "A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "PPWR recyclability" - "Article 6 recyclable packaging" - "design for recycling criteria PPWR" - "recyclability grades A B C" - "recycled at scale requirement PPWR 2035" - "PPWR delegated acts 2028 design for recycling" - "PPWR grade A B 2038" - "packaging components integrated separate recyclability" - "PPWR" - "Article 6" - "Recyclability grades" - "Design for recycling" - "Recycled at scale" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Recyclability and Design Requirements A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components. *Article 6* *Recyclability* ## EU Packaging and Packaging Waste Regulation (PPWR) Recyclability and Design Requirements Translate Article 6 into packaging specs and a recyclability grade. Output: a repeatable recyclability assessment workflow with evidence and sign-offs. Article 6 is the design engine of PPWR. It requires all packaging to be recyclable and defines recyclability conditions: (1) designed for material recycling (design-for-recycling) and (2) collected, sorted, and recycled at scale when it becomes waste. PPWR also introduces performance grades and phase-in dates that will materially affect packaging portfolios. ## What 'recyclable' means under PPWR (two conditions) PPWR does not treat recyclability as a vague marketing claim. It is a defined compliance outcome with a grading model and technical criteria. - Design-for-recycling: packaging is designed for material recycling so that secondary raw materials are of sufficient quality to substitute primary materials (defined via delegated acts). - Recycled at scale: when the packaging becomes waste, it can be collected separately, sorted into specific streams, and recycled at scale (defined via implementing acts). - Component logic matters: integrated components must be assessed together; separate components must be assessed separately. ## Recyclability grades A/B/C (what you should build your specs around) PPWR expresses recyclability performance in grades (A, B, C). These grades become market-access conditions over time. - From 1 Jan 2030 (or later depending on delegated-act timing), packaging cannot be placed on the market unless it is recyclable within grades A/B/C. - From 1 Jan 2038, packaging cannot be placed on the market unless it is recyclable within grades A or B. - Practical implication: treat grade A/B as the design target now for packaging that will live beyond 2038 or that has long qualification cycles. ## Key delegated/implementing acts and dates you must track The core criteria are finalised via delegated and implementing acts. Your compliance program must track these and translate them into internal specs and supplier requirements. - By 1 Jan 2028: Commission delegated acts establish design-for-recycling criteria and performance grades for packaging categories. - From 1 Jan 2030: design-for-recycling condition applies (or 24 months after delegated acts, whichever is later). - From 1 Jan 2035: collection/sorting/recycled-at-scale condition applies (or later depending on implementing-act timing). - From 1 Jan 2038: stricter grade threshold (A/B only). ## An assessment workflow that works (per packaging unit) Treat recyclability as an engineering workflow with gates, not as a PDF. The objective is: an auditable decision record and repeatable inputs/outputs. - Inputs: packaging BOM, predominant material, component separation logic, inks/adhesives/coatings, closures/labels, barrier layers. - Design-for-recycling assessment: evaluate design parameters per category; document why the unit meets the grade criteria. - Recycled-at-scale readiness: collection stream, sorting compatibility, recycling technology maturity and output quality assumptions. - Decisions: grade outcome, redesign actions, supplier requirements, and timeline gates. - Evidence: test reports (where relevant), supplier declarations, and a signed assessment summary stored in the evidence vault. ## Edge cases to plan for (innovative packaging, exemptions, and conflicts) Some packaging has special treatment. You need a process for these cases so they don't become hidden non-compliance. - Innovative packaging: PPWR includes a derogation path for innovative packaging that does not yet comply with recyclability requirements (with notification and a timeline to reach recycled-at-scale). - Sensitive packaging: certain immediate/outer packaging and contact-sensitive medical/food categories can have specific treatment. - Single-Use Plastics Directive interplay: for overlaps, the SUP directive can be lex specialis in its scope; document conflicts and which rule prevails for the packaging unit. *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU Packaging and Packaging Waste Regulation (PPWR) Recyclability and Design Requirements across ESG workflows ESG Compliance can take EU Packaging and Packaging Waste Regulation (PPWR) Recyclability and Design Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Packaging and Packaging Waste Regulation (PPWR) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Packaging and Packaging Waste Regulation (PPWR) Recyclability and Design Requirements](/solutions/esg-compliance.md): Start from EU Packaging and Packaging Waste Regulation (PPWR) Recyclability and Design Requirements and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Packaging and Packaging Waste Regulation (PPWR)](/contact.md): Review your current process, evidence gaps, and next steps for EU Packaging and Packaging Waste Regulation (PPWR) Recyclability and Design Requirements. ## Primary sources - [Regulation (EU) 2025/40 on packaging and packaging waste (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2025/40/oj?ref=sorena.io) - Primary source for Article 6 recyclability conditions, grades, component assessment logic, and phase-in dates. - [JRC - Technical recommendations for a recyclability assessment methodology (doi:10.2760/538070)](https://data.europa.eu/doi/10.2760/538070?ref=sorena.io) - Technical support on parameters and elements for recyclability assessment and design-for-recycling methodologies. - [Register of delegated and implementing acts (European Commission)](https://webgate.ec.europa.eu/regdel/?ref=sorena.io) - Track delegated/implementing acts that define the DfR criteria, grades, and recycled-at-scale methodology. ## Related Topic Guides - [Applicability Test | EU Packaging and Packaging Waste Regulation (PPWR) | Regulation (EU) 2025/40 Scope + Roles](/artifacts/eu/packaging-waste-regulation/applicability-test.md): A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging. - [Labelling and Consumer Information | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels, QR/Digital Marking, DRS](/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info.md): A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers. - [PFAS and Restricted Substances | EU PPWR (Regulation (EU) 2025/40) | Article 5 PFAS Thresholds for Food-Contact Packaging](/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances.md): A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits. - [PPWR Compliance Checklist | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40)](/artifacts/eu/packaging-waste-regulation/checklist.md): An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals. - [PPWR Compliance Guide | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40) | Evidence, Conformity, Enforcement](/artifacts/eu/packaging-waste-regulation/compliance.md): A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging. - [PPWR Deadlines and Compliance Calendar | Regulation (EU) 2025/40 | 11 February 2025, 12 August 2026, 1 January 2030](/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar.md): A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026. - [PPWR FAQ | Regulation (EU) 2025/40 Packaging and Packaging Waste Questions (Dates, PFAS, Labelling, Reuse Targets)](/artifacts/eu/packaging-waste-regulation/faq.md): A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions. - [PPWR Labelling Checklist | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels + QR/Digital Carriers](/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist.md): An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking. - [PPWR Penalties and Fines | Regulation (EU) 2025/40 Article 68 Enforcement and Administrative Fines](/artifacts/eu/packaging-waste-regulation/penalties-and-fines.md): A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027. - [PPWR Recyclability Assessment Template | Regulation (EU) 2025/40 | Article 6 Evidence Pack + Grade A/B/C](/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template.md): A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material). - [PPWR Timeline and Deadlines | Regulation (EU) 2025/40 Roadmap | 2025 to 2040](/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines.md): A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028. - [PPWR vs ESPR | Packaging and Packaging Waste Regulation (EU) 2025/40 vs Ecodesign for Sustainable Products Regulation (EU) 2024/1781](/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr.md): A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space. - [Requirements | EU PPWR (Regulation (EU) 2025/40) | Recyclability (Article 6), Recycled Content (Article 7), Labelling (Article 12), PFAS (Article 5)](/artifacts/eu/packaging-waste-regulation/requirements.md): A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits. - [Reuse and Refill Targets | EU PPWR (Regulation (EU) 2025/40) | Article 28-33 Refill Rules, Article 29 Reuse Targets (40% 2030, 70% 2040)](/artifacts/eu/packaging-waste-regulation/reuse-refill-targets.md): A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging. - [Scope and Packaging Definitions | EU PPWR (Regulation (EU) 2025/40) | Sales vs Grouped vs Transport vs E-commerce](/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions.md): A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements --- --- title: "Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/requirements" source_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/requirements" author: "Sorena AI" description: "A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "PPWR requirements" - "Regulation (EU) 2025/40 requirements" - "Article 6 recyclable packaging" - "recyclability grades A B C PPWR" - "design for recycling criteria PPWR 2028" - "Article 7 minimum recycled content targets 2030 2040" - "Article 12 packaging labelling 2028" - "PFAS food contact packaging limits Article 5" - "excessive packaging empty space ratio 50% Article 24" - "restrictions on packaging formats Annex V Article 25" - "reuse targets Article 29" - "PPWR" - "Regulation (EU) 2025/40" - "Recyclability" - "Recycled content" - "Labelling" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Requirements A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits. *Requirements* *PPWR* ## EU Packaging and Packaging Waste Regulation (PPWR) Requirements Turn Regulation (EU) 2025/40 into packaging specs and evidence. Output: a requirements matrix per packaging unit + an evidence pack that can be produced quickly. PPWR is not a single 'packaging redesign project'. It is a system of requirements across materials, design, labelling/digital marking, excessive packaging limits, restricted formats, and reuse/refill operations. Use this page to break the regulation into workstreams with owners, acceptance criteria, and evidence. ## 1) Substances and PFAS (Article 5) - material safety and recyclability compatibility Article 5 minimises substances of concern and sets explicit limits for certain substances (including heavy metals) and PFAS thresholds for food-contact packaging from the PPWR application date. - Build a packaging chemical inventory: substances of concern, inks/adhesives, coatings, and functional barriers. - Food-contact PFAS: if you place food-contact packaging on the market, you need supplier declarations and (where needed) testing to meet PFAS thresholds. - Evidence: technical documentation (Annex VII) should include how you demonstrate compliance with Article 5 limits and how suppliers support it. ## 2) Recyclability and design-for-recycling (Article 6 + Annex II) - the design engine Article 6 requires all packaging to be recyclable and defines conditions: designed for material recycling and recyclable at scale. It introduces recyclability performance grades (A/B/C) and links future restrictions to grades and timelines. - Create a recyclability assessment workflow: predominant material, integrated versus separate components, design-for-recycling parameters, and grade outcome. - Track delegated acts for design-for-recycling criteria and grading, and implementing acts for recycled-at-scale methodology. - Plan the phase-in: design-for-recycling grade rules apply from 1 January 2030, recycled-at-scale from 1 January 2035 or five years after the relevant implementing acts, whichever is later, and packaging must be at least grade B from 1 January 2038. ## 3) Minimum recycled content in plastic packaging (Article 7) - claims + supply chain evidence Article 7 sets minimum recycled content targets for any plastic part of packaging, calculated as an average per manufacturing plant and year, with different targets by packaging type and format. - Build post-consumer recycled-content evidence: supplier declarations, chain-of-custody logic, plant-level averaging, and claim controls. - Separate contact-sensitive and non-contact-sensitive applications early because Article 7 targets differ by packaging type. - Remember that PPWR does not regulate recycled content in plastic packaging before 1 January 2030. ## 4) Labelling, digital marking and consumer information (Articles 12-13) Article 12 introduces harmonised labels for packaging composition and additional labelling for reusable packaging and deposit-bearing packaging, with digital marking methodologies for composition and substances of concern. - Packaging composition labels: harmonised label from 12 August 2028 or 24 months after the Article 12 implementing acts, whichever is later. - Digital marking: composition methodology implementing acts due by 12 August 2026; substances-of-concern methodology due by 1 January 2030. - Reusable-packaging labels: check the 30-month phase-in linked to the Article 12 implementing acts. - Waste-receptacle labels: harmonised labels from 12 August 2028 or 30 months after the relevant implementing acts, whichever is later. ## 5) Waste prevention: excessive packaging, restricted formats, reuse/refill PPWR also regulates "how much packaging" and "which formats are allowed", and imposes operational obligations for reuse/refill in specific channels. - Excessive packaging (Article 24): empty space ratio 50% for grouped/transport/e-commerce packaging by 2030 (with implementing acts defining methodology). - Format restrictions (Article 25 + Annex V): certain formats and uses restricted from 1 Jan 2030. - Refill (Article 28) + reuse targets (Article 29) + takeaway obligations (Articles 32-33): build a channel-specific implementation plan (logistics, hygiene, reverse flows, data collection). ## Evidence mapping (what to keep ready for audits and customer requests) Your evidence should be indexed per packaging unit and per workstream so you can answer: what changed, why it's compliant, and what proof you have. - Scope memo + definitions + role map per legal entity. - Recyclability assessment (Article 6): grade outcome, component compatibility analysis, and DfR parameters. - PCR content evidence (Article 7): supplier evidence, averaging calculation, and controlled claims/labels. - Labelling specs (Articles 12-13): artwork, data carrier payload, and multilingual/market requirements. - Substances/PFAS (Article 5): testing strategy, supplier declarations, and technical documentation. - Preventive measures: empty space calculations, restricted format screening, and reuse/refill program evidence. *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU Packaging and Packaging Waste Regulation (PPWR) Requirements across ESG workflows ESG Compliance can take EU Packaging and Packaging Waste Regulation (PPWR) Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Packaging and Packaging Waste Regulation (PPWR) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Packaging and Packaging Waste Regulation (PPWR) Requirements](/solutions/esg-compliance.md): Start from EU Packaging and Packaging Waste Regulation (PPWR) Requirements and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Packaging and Packaging Waste Regulation (PPWR)](/contact.md): Review your current process, evidence gaps, and next steps for EU Packaging and Packaging Waste Regulation (PPWR) Requirements. ## Primary sources - [Regulation (EU) 2025/40 on packaging and packaging waste (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2025/40/oj?ref=sorena.io) - Primary source for all PPWR obligations and timelines (Articles 5-7, 12-13, 24-25, 28-33, 70-71). - [European Commission - Packaging & Packaging Waste Regulation overview](https://environment.ec.europa.eu/topics/waste-and-recycling/packaging-waste/packaging-packaging-waste-regulation_en?ref=sorena.io) - Policy overview, key measures and implementation context. - [Register of delegated and implementing acts (European Commission)](https://webgate.ec.europa.eu/regdel/?ref=sorena.io) - Track delegated/implementing acts for DfR criteria, labelling specifications, and calculation methodologies. - [European Parliament - New EU rules to reduce, reuse and recycle packaging (press release)](https://www.europarl.europa.eu/news/en/press-room/20240419IPR20589/new-eu-rules-to-reduce-reuse-and-recycle-packaging?ref=sorena.io) - Helpful summary of the main measures and the legislative intent behind the PPWR requirements. ## Related Topic Guides - [Applicability Test | EU Packaging and Packaging Waste Regulation (PPWR) | Regulation (EU) 2025/40 Scope + Roles](/artifacts/eu/packaging-waste-regulation/applicability-test.md): A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging. - [Labelling and Consumer Information | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels, QR/Digital Marking, DRS](/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info.md): A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers. - [PFAS and Restricted Substances | EU PPWR (Regulation (EU) 2025/40) | Article 5 PFAS Thresholds for Food-Contact Packaging](/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances.md): A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits. - [PPWR Compliance Checklist | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40)](/artifacts/eu/packaging-waste-regulation/checklist.md): An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals. - [PPWR Compliance Guide | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40) | Evidence, Conformity, Enforcement](/artifacts/eu/packaging-waste-regulation/compliance.md): A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging. - [PPWR Deadlines and Compliance Calendar | Regulation (EU) 2025/40 | 11 February 2025, 12 August 2026, 1 January 2030](/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar.md): A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026. - [PPWR FAQ | Regulation (EU) 2025/40 Packaging and Packaging Waste Questions (Dates, PFAS, Labelling, Reuse Targets)](/artifacts/eu/packaging-waste-regulation/faq.md): A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions. - [PPWR Labelling Checklist | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels + QR/Digital Carriers](/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist.md): An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking. - [PPWR Penalties and Fines | Regulation (EU) 2025/40 Article 68 Enforcement and Administrative Fines](/artifacts/eu/packaging-waste-regulation/penalties-and-fines.md): A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027. - [PPWR Recyclability Assessment Template | Regulation (EU) 2025/40 | Article 6 Evidence Pack + Grade A/B/C](/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template.md): A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material). - [PPWR Timeline and Deadlines | Regulation (EU) 2025/40 Roadmap | 2025 to 2040](/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines.md): A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028. - [PPWR vs ESPR | Packaging and Packaging Waste Regulation (EU) 2025/40 vs Ecodesign for Sustainable Products Regulation (EU) 2024/1781](/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr.md): A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space. - [Recyclability and Design Requirements | EU PPWR (Regulation (EU) 2025/40) | Article 6 Recyclability Grades A/B/C + Design-for-Recycling](/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements.md): A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components. - [Reuse and Refill Targets | EU PPWR (Regulation (EU) 2025/40) | Article 28-33 Refill Rules, Article 29 Reuse Targets (40% 2030, 70% 2040)](/artifacts/eu/packaging-waste-regulation/reuse-refill-targets.md): A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging. - [Scope and Packaging Definitions | EU PPWR (Regulation (EU) 2025/40) | Sales vs Grouped vs Transport vs E-commerce](/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions.md): A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/packaging-waste-regulation/requirements --- --- title: "Reuse and Refill Targets" canonical_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/reuse-refill-targets" source_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/reuse-refill-targets" author: "Sorena AI" description: "A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "PPWR reuse targets" - "PPWR refill rules" - "Article 29 reuse targets 40% 2030 70% 2040" - "Article 28 refill rules" - "PPWR take-away refill obligation 12 February 2027" - "PPWR take-away reusable offer 12 February 2028" - "PPWR grouped packaging reuse target 10% 2030" - "PPWR beverage reusable packaging target 10% 2030" - "PPWR" - "Reuse targets" - "Refill" - "Take-away sector" - "Article 29" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Reuse and Refill Targets A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging. *Article 28-33* *Reuse & Refill* ## EU Packaging and Packaging Waste Regulation (PPWR) Reuse and Refill Targets Turn targets into operational systems you can measure and prove. Output: reuse system design, refill procedures, take-away compliance, and reporting readiness. Reuse and refill compliance is operational compliance. You need real systems (collection, cleaning/reconditioning, tracking where required) and a measurement model that can survive audit scrutiny. This page translates Articles 28-33 of Regulation (EU) 2025/40 into implementable work items and evidence expectations. ## Refill rules (Article 28): what to implement PPWR requires clear 'rules for refill': what containers are acceptable, hygiene standards, and who is responsible for what. Design refill as a controlled process: signage, staff instructions, cleaning requirements, and incident handling. - Rules for refill must be provided to end users and kept up to date, covering container types, hygiene standards, and user responsibility. - Refill stations must comply with other applicable legal requirements, including hygiene and food-safety rules where relevant. - Operators may refuse refill if a container is unhygienic or unsuitable, but the refusal criteria should be documented and applied consistently. - From 1 January 2030, final distributors with a sales area of more than 400 m2 shall endeavour to dedicate 10% of that area to refill stations for food and non-food products. ## Reuse targets (Article 29): the key numbers to plan for PPWR sets numeric reuse targets for defined packaging categories, with higher 'endeavour' shares in 2040. Targets differ by packaging type - classification is the first step to avoid miscounting and misreporting. - Transport packaging: at least 40% reusable from 1 January 2030; endeavour 70% from 1 January 2040. - Grouped packaging boxes excluding cardboard: at least 10% reusable from 1 January 2030; endeavour 25% from 1 January 2040. - Beverages at final distributors: at least 10% made available in reusable packaging from 1 January 2030; endeavour 40% from 1 January 2040. - Use the derogations and carve-outs carefully and document why a packaging type falls in or out of scope. ## Take-away sector: refill (2027) and reusable offer (2028) PPWR introduces two concrete obligations for the HORECA take-away sector that have earlier dates than most reuse targets. Treat this as a front-of-house compliance program: signage, parity pricing, and staff training. - By 12 February 2027, HORECA final distributors must provide a bring-your-own-container system for take-away beverages and ready-prepared food under Article 32. - By 12 February 2028, HORECA final distributors must offer reusable packaging within a reuse system under Article 33, unless they qualify for the micro-enterprise exemption. - Refill or reusable options must not cost more or be offered under less favourable conditions than single-use packaging options. - From 2030, final distributors shall endeavour to offer 10% of products for sale in a reusable packaging format under Article 33(5). ## Measurement and reporting: what you need before 2030 You can't retrofit measurement in 2029. Build the data model early: equivalent units, packaging categories, reuse systems, and evidence links. PPWR requires an implementing act to define the calculation methodology - plan to adapt, not to start. - By 30 June 2027, the Commission must adopt the Article 30 methodology for calculating Article 29 reuse targets. - The obligation to demonstrate achievement starts from 1 January 2030 or 18 months after entry into force of that implementing act, whichever is later. - Annual reporting to the competent authority follows Article 31, with the first reporting year linked to the 2030 target start. - Evidence should include participation in reuse systems, equivalent-unit logic, data-quality checks, and exception handling. ## Implementation blueprint (deliverables + evidence) Treat reuse/refill as a program, not a policy. The deliverables are system-level: contracts, operations, data, and customer communication. Aim for an audit-ready "reuse/refill pack" per relevant packaging category and per market. - System design: choose closed-loop vs mutualised reuse system; define collection, reconditioning, and loss controls - Packaging design: design for rotations; document durability and reconditioning constraints; align with reuse system requirements - Contracts: reuse system terms, responsibilities, hygiene standards, and liability boundaries - Operations: signage, staff training, return incentives, and exception handling - Measurement: equivalent-unit counting, reusable share dashboards, and reporting exports - Evidence vault: system confirmations, process descriptions, and year-by-year target calculation files *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU Packaging and Packaging Waste Regulation (PPWR) Reuse and Refill Targets across ESG workflows ESG Compliance can take EU Packaging and Packaging Waste Regulation (PPWR) Reuse and Refill Targets from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU Packaging and Packaging Waste Regulation (PPWR) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Packaging and Packaging Waste Regulation (PPWR) Reuse and Refill Targets](/solutions/esg-compliance.md): Start from EU Packaging and Packaging Waste Regulation (PPWR) Reuse and Refill Targets and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Packaging and Packaging Waste Regulation (PPWR)](/contact.md): Review your current process, evidence gaps, and next steps for EU Packaging and Packaging Waste Regulation (PPWR) Reuse and Refill Targets. ## Primary sources - [Regulation (EU) 2025/40 on packaging and packaging waste (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2025/40/oj?ref=sorena.io) - Primary source for Articles 28-33 obligations and Article 29 reuse target percentages and dates. - [European Commission - Packaging & Packaging Waste Regulation overview](https://environment.ec.europa.eu/topics/waste-and-recycling/packaging-waste/packaging-packaging-waste-regulation_en?ref=sorena.io) - High-level overview of reuse/refill measures and implementation context. - [Register of delegated and implementing acts (European Commission)](https://webgate.ec.europa.eu/regdel/?ref=sorena.io) - Track implementing acts for the reuse target calculation methodology. ## Related Topic Guides - [Applicability Test | EU Packaging and Packaging Waste Regulation (PPWR) | Regulation (EU) 2025/40 Scope + Roles](/artifacts/eu/packaging-waste-regulation/applicability-test.md): A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging. - [Labelling and Consumer Information | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels, QR/Digital Marking, DRS](/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info.md): A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers. - [PFAS and Restricted Substances | EU PPWR (Regulation (EU) 2025/40) | Article 5 PFAS Thresholds for Food-Contact Packaging](/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances.md): A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits. - [PPWR Compliance Checklist | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40)](/artifacts/eu/packaging-waste-regulation/checklist.md): An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals. - [PPWR Compliance Guide | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40) | Evidence, Conformity, Enforcement](/artifacts/eu/packaging-waste-regulation/compliance.md): A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging. - [PPWR Deadlines and Compliance Calendar | Regulation (EU) 2025/40 | 11 February 2025, 12 August 2026, 1 January 2030](/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar.md): A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026. - [PPWR FAQ | Regulation (EU) 2025/40 Packaging and Packaging Waste Questions (Dates, PFAS, Labelling, Reuse Targets)](/artifacts/eu/packaging-waste-regulation/faq.md): A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions. - [PPWR Labelling Checklist | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels + QR/Digital Carriers](/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist.md): An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking. - [PPWR Penalties and Fines | Regulation (EU) 2025/40 Article 68 Enforcement and Administrative Fines](/artifacts/eu/packaging-waste-regulation/penalties-and-fines.md): A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027. - [PPWR Recyclability Assessment Template | Regulation (EU) 2025/40 | Article 6 Evidence Pack + Grade A/B/C](/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template.md): A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material). - [PPWR Timeline and Deadlines | Regulation (EU) 2025/40 Roadmap | 2025 to 2040](/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines.md): A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028. - [PPWR vs ESPR | Packaging and Packaging Waste Regulation (EU) 2025/40 vs Ecodesign for Sustainable Products Regulation (EU) 2024/1781](/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr.md): A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space. - [Recyclability and Design Requirements | EU PPWR (Regulation (EU) 2025/40) | Article 6 Recyclability Grades A/B/C + Design-for-Recycling](/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements.md): A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components. - [Requirements | EU PPWR (Regulation (EU) 2025/40) | Recyclability (Article 6), Recycled Content (Article 7), Labelling (Article 12), PFAS (Article 5)](/artifacts/eu/packaging-waste-regulation/requirements.md): A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits. - [Scope and Packaging Definitions | EU PPWR (Regulation (EU) 2025/40) | Sales vs Grouped vs Transport vs E-commerce](/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions.md): A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/packaging-waste-regulation/reuse-refill-targets --- --- title: "Scope and Packaging Definitions" canonical_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions" source_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions" author: "Sorena AI" description: "A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "PPWR definitions" - "packaging definition PPWR" - "sales packaging grouped packaging transport packaging" - "e-commerce packaging definition PPWR" - "take-away packaging definition" - "reusable packaging definition PPWR" - "Regulation (EU) 2025/40 Article 3 definitions" - "PPWR" - "Definitions" - "Scope" - "E-commerce packaging" - "Transport packaging" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Scope and Packaging Definitions A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging. *Definitions* *PPWR* ## EU Packaging and Packaging Waste Regulation (PPWR) Scope and Packaging Definitions Classification is the root cause of most PPWR mistakes. Output: a consistent packaging taxonomy you can use across product, procurement, labelling, and evidence packs. PPWR obligations trigger on what the packaging is (definition), how it is used (format and channel), and who is responsible (economic operator role). This page extracts the definitions you must get right and gives you a method to document them consistently across packaging units. ## What is 'packaging' under PPWR? PPWR defines packaging broadly: items that contain/support/preserve products for handling, delivery or presentation and that can be differentiated by format, material and design. Components and ancillary elements that perform a packaging function can be in scope. Use Annex I as a sanity check: it provides an indicative list of items in scope of the definition (good for borderline discussions). - Packaged product vs packaging: record whether the item is integral to the product or serves a packaging function. - Service packaging: designed/intended to be filled at point of sale (common for take-away and retail counters). - Single-serve beverage units: included in the definition where intended to be used and disposed with the product. ## Format definitions that drive obligations These definitions are operational: they determine which empty-space ratios apply, which reuse targets apply, and which labelling exemptions apply. - Sales packaging: the sales unit to the end user at point of sale. - Grouped packaging: groups a number of sales units at point of sale or for shelf restocking/distribution; can be removed without affecting the product. - Transport packaging: facilitates handling/transport of sales units or grouped units to prevent damage; excludes transport containers. - E-commerce packaging: transport packaging used to deliver products in distance sales to end users. - Take-away packaging: service packaging filled at attended points of sale for immediate consumption elsewhere. ## Reusable, refill, deposit-bearing: terms you must distinguish PPWR includes specific requirements for reusable packaging (design, rotations, labelling), refill obligations for certain sectors, and deposit-and-return system labelling requirements. - Reusable packaging: conceived/designed for multiple rotations, refill/reload, reconditioning, and still recyclable at end-of-life. - Refill (sale through refill stations): triggers "rules for refill", hygiene standards, and operational requirements for refill stations. - Deposit and return system (DRS): deposit-bearing packaging requires clear, unambiguous labels; DRS rules can include harmonised colour labels in implementing acts. ## How to document definitions (a defensible scope memo template) Make scope memos evidence-driven: if you can't attach an artefact link (BOM, drawing, photo, supplier declaration), the classification is usually too fuzzy. - Packaging unit ID + photo + BOM (integrated vs separate components). - Format classification: sales/grouped/transport/e-commerce/take-away. - Use case flags: food-contact, reusable, deposit-bearing, HORECA take-away, hazardous goods transport. - Role map: manufacturer/importer/distributor/final distributor per legal entity. - Obligations matrix: which PPWR articles/workstreams apply + earliest deadlines that matter. *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Use EU Packaging and Packaging Waste Regulation (PPWR) Scope and Packaging Definitions as a cited research workflow Research Copilot can take EU Packaging and Packaging Waste Regulation (PPWR) Scope and Packaging Definitions from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Packaging and Packaging Waste Regulation (PPWR) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Packaging and Packaging Waste Regulation (PPWR) Scope and Packaging Definitions](/solutions/research-copilot.md): Start from EU Packaging and Packaging Waste Regulation (PPWR) Scope and Packaging Definitions and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Packaging and Packaging Waste Regulation (PPWR)](/contact.md): Review your current process, evidence gaps, and next steps for EU Packaging and Packaging Waste Regulation (PPWR) Scope and Packaging Definitions. ## Primary sources - [Regulation (EU) 2025/40 on packaging and packaging waste (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2025/40/oj?ref=sorena.io) - Primary source for packaging definition, format definitions, and reusable/refill/DRS related terms. - [European Commission - Packaging & Packaging Waste Regulation overview](https://environment.ec.europa.eu/topics/waste-and-recycling/packaging-waste/packaging-packaging-waste-regulation_en?ref=sorena.io) - Policy overview and implementation context. ## Related Topic Guides - [Applicability Test | EU Packaging and Packaging Waste Regulation (PPWR) | Regulation (EU) 2025/40 Scope + Roles](/artifacts/eu/packaging-waste-regulation/applicability-test.md): A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging. - [Labelling and Consumer Information | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels, QR/Digital Marking, DRS](/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info.md): A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers. - [PFAS and Restricted Substances | EU PPWR (Regulation (EU) 2025/40) | Article 5 PFAS Thresholds for Food-Contact Packaging](/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances.md): A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits. - [PPWR Compliance Checklist | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40)](/artifacts/eu/packaging-waste-regulation/checklist.md): An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals. - [PPWR Compliance Guide | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40) | Evidence, Conformity, Enforcement](/artifacts/eu/packaging-waste-regulation/compliance.md): A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging. - [PPWR Deadlines and Compliance Calendar | Regulation (EU) 2025/40 | 11 February 2025, 12 August 2026, 1 January 2030](/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar.md): A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026. - [PPWR FAQ | Regulation (EU) 2025/40 Packaging and Packaging Waste Questions (Dates, PFAS, Labelling, Reuse Targets)](/artifacts/eu/packaging-waste-regulation/faq.md): A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions. - [PPWR Labelling Checklist | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels + QR/Digital Carriers](/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist.md): An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking. - [PPWR Penalties and Fines | Regulation (EU) 2025/40 Article 68 Enforcement and Administrative Fines](/artifacts/eu/packaging-waste-regulation/penalties-and-fines.md): A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027. - [PPWR Recyclability Assessment Template | Regulation (EU) 2025/40 | Article 6 Evidence Pack + Grade A/B/C](/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template.md): A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material). - [PPWR Timeline and Deadlines | Regulation (EU) 2025/40 Roadmap | 2025 to 2040](/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines.md): A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028. - [PPWR vs ESPR | Packaging and Packaging Waste Regulation (EU) 2025/40 vs Ecodesign for Sustainable Products Regulation (EU) 2024/1781](/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr.md): A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space. - [Recyclability and Design Requirements | EU PPWR (Regulation (EU) 2025/40) | Article 6 Recyclability Grades A/B/C + Design-for-Recycling](/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements.md): A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components. - [Requirements | EU PPWR (Regulation (EU) 2025/40) | Recyclability (Article 6), Recycled Content (Article 7), Labelling (Article 12), PFAS (Article 5)](/artifacts/eu/packaging-waste-regulation/requirements.md): A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits. - [Reuse and Refill Targets | EU PPWR (Regulation (EU) 2025/40) | Article 28-33 Refill Rules, Article 29 Reuse Targets (40% 2030, 70% 2040)](/artifacts/eu/packaging-waste-regulation/reuse-refill-targets.md): A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions --- --- title: "PPWR Timeline and Deadlines" canonical_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines" source_url: "https://www.sorena.io/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines" author: "Sorena AI" description: "A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "PPWR timeline" - "PPWR deadlines" - "Regulation (EU) 2025/40 timeline" - "PPWR 12 August 2026" - "PPWR 12 February 2027" - "PPWR 30 June 2027 reuse target calculation" - "PPWR 12 February 2028 empty space methodology" - "PPWR 1 January 2030 obligations" - "PPWR reuse targets 2030 2040" - "PPWR" - "Timeline" - "Deadlines" - "Roadmap" - "Regulation (EU) 2025/40" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # PPWR Timeline and Deadlines A phased PPWR roadmap for Regulation (EU) 2025/40: entry into force in February 2025, application from August 2026, key implementing acts in 2026 to 2028. *PPWR* *Timeline* ## EU Packaging and Packaging Waste Regulation (PPWR) Timeline and Deadlines A PPWR roadmap that your owners can execute. Use this page to sequence scope, specs, supplier evidence, labels, and reuse/refill programs into a phased plan. PPWR has several layers of timing: legal entry into force, application, implementing-act dependencies, and 2030 operational obligations. This roadmap turns those layers into a delivery plan and shows where early data and governance work reduce later redesign churn. ## Phase 0 - Foundations from entry into force From entry into force on 11 February 2025 until application on 12 August 2026, the right move is to build inventory, data, supplier evidence requirements, and release control. That groundwork supports every PPWR workstream and reduces late-stage packaging redesign. - Packaging portfolio inventory and classification (sales/grouped/transport/e-commerce; materials; food contact; reuse vs single-use) - Evidence vault structure (per packaging unit): BOM, specs, declarations, tests, label variants, decision logs - Supplier evidence contract pack: restricted substances (PFAS for food contact), heavy metals, recycled content, change notification - Release governance: packaging spec sign-off + artwork approval + QR/digital payload control ## Phase 1 - 12 August 2026 application Regulation (EU) 2025/40 applies from 12 August 2026. Treat this as your go-live date for core compliance controls. Also plan for implementing acts due by this date for labelling and digital marking methodologies. - 12 August 2026: PPWR applies. - 12 August 2026: PFAS thresholds for food-contact packaging apply under Article 5. - 12 August 2026: implementing acts are due for packaging labels, waste-receptacle labels, and digital marking for composition. - 12 August 2026: Article 70 starts the main repeal of Directive 94/62/EC, while some transitional provisions continue. ## Phase 2 - 2027 to early 2028 This period is where enforcement frameworks and calculation methodologies arrive. You should be ready to adapt - not scramble. Take-away obligations have explicit dates and are operationally visible. - 12 February 2027: Member States must lay down penalties and notify the Commission. - 12 February 2027: the Commission must publish Annex V guidance and establish the European observatory on reuse. - 12 February 2027: take-away refill begins under Article 32. - 30 June 2027: reuse-target calculation methodology is due under Article 30. - 12 February 2028: the Article 24 empty-space methodology is due and the take-away reusable-offer obligation begins. ## Phase 3 - label phase-in and Article 67(5) Harmonised labels phase in based on implementing acts. Plan your label governance, translation workflows, and SKU variant management early. If you use QR/digital carriers, treat payloads as regulated content with version control. - 12 August 2028 or 24 months after the Article 12 implementing acts, whichever is later: harmonised composition labels start to apply. - 12 August 2028 or 30 months after the Article 13 implementing acts, whichever is later: harmonised waste-receptacle labels start to apply. - 12 February 2029: Article 67(5) applies. - Decision 97/129/EC is repealed from 12 August 2028. ## Phase 4 - 2030 to 2040 2030 is where operational obligations converge. Work backwards: packaging redesign + supplier requalification takes time. Your 2030 readiness is determined by how early you standardise packaging data, specs, and evidence. - 1 January 2030 or later if methodology timing pushes it out: the Article 24 50% empty-space cap applies to grouped, transport, and e-commerce packaging. - 1 January 2030: Annex V format restrictions start. - 1 January 2030: Article 29 reuse targets start and Article 33(5) 10% endeavour language for take-away reusable offers becomes relevant. - 12 August 2034: Article 69 evaluation. - 1 January 2040: higher endeavour reuse shares apply under Article 29. ## Long horizon - 2034-2040 reviews and higher targets Long-term dates still matter for investment decisions (reuse system infrastructure, packaging redesign cadence, and supplier capacity). Use them to justify capex and operational changes early. - By 1 Jan 2034: Commission report reviewing implementation of 2030 reuse targets (Article 29) - By 12 Aug 2034: Commission evaluation of PPWR (Article 69) - From 1 Jan 2040: higher 'endeavour' reuse shares apply (Article 29) (e.g., transport packaging endeavour 70%) *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU Packaging and Packaging Waste Regulation (PPWR) Timeline and Deadlines across ESG workflows ESG Compliance can take EU Packaging and Packaging Waste Regulation (PPWR) Timeline and Deadlines from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Packaging and Packaging Waste Regulation (PPWR) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Packaging and Packaging Waste Regulation (PPWR) Timeline and Deadlines](/solutions/esg-compliance.md): Start from EU Packaging and Packaging Waste Regulation (PPWR) Timeline and Deadlines and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Packaging and Packaging Waste Regulation (PPWR)](/contact.md): Review your current process, evidence gaps, and next steps for EU Packaging and Packaging Waste Regulation (PPWR) Timeline and Deadlines. ## Primary sources - [Regulation (EU) 2025/40 on packaging and packaging waste (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2025/40/oj?ref=sorena.io) - Primary source for PPWR application date (12 Aug 2026), Articles 24-33 milestone obligations, and Article 68 penalties scaffolding. - [Register of delegated and implementing acts (European Commission)](https://webgate.ec.europa.eu/regdel/?ref=sorena.io) - Track implementing acts that define methods/specs and can affect phase-in timelines. - [European Commission - Packaging & Packaging Waste Regulation overview](https://environment.ec.europa.eu/topics/waste-and-recycling/packaging-waste/packaging-packaging-waste-regulation_en?ref=sorena.io) - Policy overview and context. ## Related Topic Guides - [Applicability Test | EU Packaging and Packaging Waste Regulation (PPWR) | Regulation (EU) 2025/40 Scope + Roles](/artifacts/eu/packaging-waste-regulation/applicability-test.md): A practical PPWR applicability test for Regulation (EU) 2025/40: determine whether an item is packaging. - [Labelling and Consumer Information | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels, QR/Digital Marking, DRS](/artifacts/eu/packaging-waste-regulation/labeling-and-consumer-info.md): A practical PPWR labelling guide for Regulation (EU) 2025/40: harmonised composition labels (Article 12), reusable packaging labels + QR/digital carriers. - [PFAS and Restricted Substances | EU PPWR (Regulation (EU) 2025/40) | Article 5 PFAS Thresholds for Food-Contact Packaging](/artifacts/eu/packaging-waste-regulation/pfas-and-restricted-substances.md): A practical PPWR chemicals guide for Regulation (EU) 2025/40 Article 5: minimise substances of concern, comply with heavy metals limits. - [PPWR Compliance Checklist | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40)](/artifacts/eu/packaging-waste-regulation/checklist.md): An audit-ready PPWR compliance checklist for Regulation (EU) 2025/40: scope your packaging portfolio, map Article 5-7 materials rules (PFAS, heavy metals. - [PPWR Compliance Guide | EU Packaging and Packaging Waste Regulation (Regulation (EU) 2025/40) | Evidence, Conformity, Enforcement](/artifacts/eu/packaging-waste-regulation/compliance.md): A practical PPWR compliance guide for Regulation (EU) 2025/40: how to structure a defensible compliance program, what 'conformity' means for packaging. - [PPWR Deadlines and Compliance Calendar | Regulation (EU) 2025/40 | 11 February 2025, 12 August 2026, 1 January 2030](/artifacts/eu/packaging-waste-regulation/deadlines-and-compliance-calendar.md): A practical PPWR deadlines and compliance calendar for Regulation (EU) 2025/40: entry into force on 11 February 2025, application from 12 August 2026. - [PPWR FAQ | Regulation (EU) 2025/40 Packaging and Packaging Waste Questions (Dates, PFAS, Labelling, Reuse Targets)](/artifacts/eu/packaging-waste-regulation/faq.md): A source-grounded PPWR FAQ for Regulation (EU) 2025/40: when it applies (12 Aug 2026), what changes in 2030 (empty space 50%, Annex V restrictions. - [PPWR Labelling Checklist | EU PPWR (Regulation (EU) 2025/40) | Article 12-13 Labels + QR/Digital Carriers](/artifacts/eu/packaging-waste-regulation/ppwr-labeling-checklist.md): An audit-ready PPWR labelling checklist: composition labels (Article 12), reusable packaging labels and QR/digital carriers, deposit-and-return marking. - [PPWR Penalties and Fines | Regulation (EU) 2025/40 Article 68 Enforcement and Administrative Fines](/artifacts/eu/packaging-waste-regulation/penalties-and-fines.md): A practical PPWR enforcement and penalties guide for Regulation (EU) 2025/40: what Article 68 requires (Member State penalties rules by 12 Feb 2027. - [PPWR Recyclability Assessment Template | Regulation (EU) 2025/40 | Article 6 Evidence Pack + Grade A/B/C](/artifacts/eu/packaging-waste-regulation/ppwr-recyclability-assessment-template.md): A copyable PPWR recyclability assessment template for Regulation (EU) 2025/40 Article 6: packaging unit inputs (BOM, components, predominant material). - [PPWR vs ESPR | Packaging and Packaging Waste Regulation (EU) 2025/40 vs Ecodesign for Sustainable Products Regulation (EU) 2024/1781](/artifacts/eu/packaging-waste-regulation/ppwr-vs-espr.md): A practical guide to PPWR vs ESPR: PPWR (Regulation (EU) 2025/40) sets packaging-specific rules (recyclability, labelling, PFAS, reuse/refill, empty space. - [Recyclability and Design Requirements | EU PPWR (Regulation (EU) 2025/40) | Article 6 Recyclability Grades A/B/C + Design-for-Recycling](/artifacts/eu/packaging-waste-regulation/recyclability-and-design-requirements.md): A practical Article 6 guide for PPWR recyclability: how to assess design-for-recycling, treat integrated vs separate components. - [Requirements | EU PPWR (Regulation (EU) 2025/40) | Recyclability (Article 6), Recycled Content (Article 7), Labelling (Article 12), PFAS (Article 5)](/artifacts/eu/packaging-waste-regulation/requirements.md): A practical PPWR requirements breakdown for Regulation (EU) 2025/40: Article 5 substance and PFAS limits. - [Reuse and Refill Targets | EU PPWR (Regulation (EU) 2025/40) | Article 28-33 Refill Rules, Article 29 Reuse Targets (40% 2030, 70% 2040)](/artifacts/eu/packaging-waste-regulation/reuse-refill-targets.md): A practical PPWR reuse and refill guide for Regulation (EU) 2025/40: Article 28 refill rules, Article 29 reuse targets for transport packaging. - [Scope and Packaging Definitions | EU PPWR (Regulation (EU) 2025/40) | Sales vs Grouped vs Transport vs E-commerce](/artifacts/eu/packaging-waste-regulation/scope-and-packaging-definitions.md): A practical PPWR scope and definitions guide: what counts as packaging, how to classify sales/grouped/transport/e-commerce packaging, take-away packaging. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/packaging-waste-regulation/timeline-and-deadlines --- --- title: "RED Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/applicability-test" author: "Sorena AI" description: "A structured RED applicability test for Directive 2014/53/EU: determine if your product is radio equipment, whether any exclusions apply." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RED applicability test" - "is my product radio equipment" - "Directive 2014/53/EU scope test" - "radio equipment directive scope" - "RED cybersecurity delegated regulation 2022/30 applicability" - "internet-connected radio equipment RED" - "RED" - "Applicability" - "Scope" - "Directive 2014/53/EU" - "Cybersecurity" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RED Applicability Test A structured RED applicability test for Directive 2014/53/EU: determine if your product is radio equipment, whether any exclusions apply. *RED* *Applicability* ## EU Radio Equipment Directive (RED) Applicability Test Decide scope and document it in under 15 minutes. Output: an in-scope / out-of-scope result plus a list of the next pages to use. Use this applicability test to lock down RED scope early. The goal is not just in scope or out of scope, but what is triggered and what evidence do we need. Save the output as a scope memo in your technical file. ## Step 1 - Is it radio equipment? (definition check) Start with the radio facts: does the equipment intentionally transmit and/or receive radio waves for radiocommunication or radiodetermination? If a radio module is integrated into a larger product, the product can still be in scope depending on how it is made available and intended to be used. - Does it intentionally transmit radio waves (Wi-Fi, cellular, Bluetooth, LPWAN, GNSS, etc.)? - Does it intentionally receive radio waves as part of its intended function? - Is the radio function part of the product placed on the market (not a lab-only prototype)? ## Step 2 - Are you excluded? (don't guess) RED has exclusions and special cases. If you claim an exclusion, document the legal basis and keep it with the technical file. If you are unsure, treat it as in-scope until proven otherwise - it prevents late-stage redesigns. - Is it fixed-line terminal equipment, marine equipment, or an airborne product covered by another Union regime? - Is it a custom-built evaluation kit for professionals used solely at a research and development facility? - Is it radio-amateur equipment that is not being made available on the market? - Is the radio function absent in the shipped configuration (and can end users enable it)? ## Step 3 - What essential requirements are triggered? All in-scope radio equipment must meet the core essential requirements (safety/health, EMC, spectrum efficiency). Additional requirements can apply depending on product characteristics and whether they have been activated via delegated acts (notably cybersecurity). - Core: safety/health, EMC, efficient use of spectrum - Additional: interworking, access to emergency services, privacy/data protection, fraud protection, software/feature-related requirements (depending on activation and product type) - Cybersecurity: check Delegated Regulation (EU) 2022/30 applicability (applies from 1 Aug 2025) ## Step 4 - Does the cybersecurity delegated act apply to you? (EU) 2022/30 Delegated Regulation (EU) 2022/30 activates the essential requirements in Article 3(3)(d), (e), and (f) for defined equipment categories. Treat this as a product classification exercise tied to your architecture and data flows. - Internet-connected radio equipment: network protection requirement (Article 3(3)(d)) - Equipment processing personal data / traffic data / location data: privacy/data protection requirement (Article 3(3)(e)) - Internet-connected equipment enabling transfer of money/monetary value/virtual currency: fraud protection requirement (Article 3(3)(f)) - Effective date: applies from 1 Aug 2025 after the postponement in Regulation (EU) 2023/2444 ## Outcome summary (copy/paste for your technical file) Write a short scope conclusion and list what you will use as evidence. This prevents rework later. If you are 'partially in scope' (variants differ), document which variants are in/out and why. - Scope conclusion: in scope / out of scope / mixed (variants) - Triggered requirements: core + any additional/cybersecurity triggers - Evidence route: harmonised standards used + test plan + conformity assessment module + documentation owner - Next pages: requirements -> standards/test plan -> conformity and CE -> cybersecurity guide (if triggered) *Recommended next step* *Placement: after the applicability result* ## Turn EU Radio Equipment Directive (RED) Applicability Test into an operational assessment Assessment Autopilot can take EU Radio Equipment Directive (RED) Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU Radio Equipment Directive (RED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Radio Equipment Directive (RED) Applicability Test](/solutions/assessment.md): Start from EU Radio Equipment Directive (RED) Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Radio Equipment Directive (RED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Radio Equipment Directive (RED) Applicability Test. ## Primary sources - [Directive 2014/53/EU (Radio Equipment Directive) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/53/oj?ref=sorena.io) - Primary source for scope, definitions and essential requirements. - [Delegated Regulation (EU) 2022/30 (cybersecurity essential requirements) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2022/30/oj?ref=sorena.io) - Activates Article 3(3)(d), (e), (f) for defined equipment categories. Use the consolidated text or the amending act for the current 1 Aug 2025 date. - [Delegated Regulation (EU) 2023/2444 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2023/2444/oj?ref=sorena.io) - Moves the application date of the RED cybersecurity delegated act from 1 Aug 2024 to 1 Aug 2025 and corrects Article 1(2). - [EU Single Market - Radio Equipment Directive overview](https://single-market-economy.ec.europa.eu/sectors/electrical-and-electronic-engineering-industries-eei/radio-equipment-directive-red_en?ref=sorena.io) - Official overview and links to guidance. ## Related Topic Guides - [Conformity Assessment and CE Marking | EU RED 2014/53/EU | Technical Documentation, EU DoC, Notified Bodies](/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce.md): A practical guide to RED conformity assessment and CE marking under Directive 2014/53/EU. - [Essential Requirements | EU Radio Equipment Directive (RED) 2014/53/EU | Safety, EMC, Spectrum, Cybersecurity (EU) 2022/30](/artifacts/eu/radio-equipment-directive/requirements.md): A practical RED essential requirements guide for Directive 2014/53/EU: map Article 3 requirements to product features and verification evidence for safety. - [Harmonised Standards and Test Plans | EU RED 2014/53/EU | Presumption of Conformity, OJ References, Verification Strategy](/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans.md): A practical guide to harmonised standards under the EU Radio Equipment Directive (RED) 2014/53/EU: how presumption of conformity works. - [RED Compliance Checklist | EU Radio Equipment Directive 2014/53/EU | CE Marking Evidence Pack](/artifacts/eu/radio-equipment-directive/checklist.md): An audit-ready RED compliance checklist for Directive 2014/53/EU: scope and classification, essential requirements mapping (safety/health, EMC, spectrum). - [RED Compliance Program | EU Radio Equipment Directive 2014/53/EU Implementation Playbook](/artifacts/eu/radio-equipment-directive/compliance.md): A practical RED compliance program playbook for Directive 2014/53/EU: set up governance, map essential requirements to standards and tests. - [RED Conformity Assessment Template | CE Technical File Structure for Directive 2014/53/EU](/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template.md): A practical RED conformity assessment template for Directive 2014/53/EU: a CE technical file structure with sections for scope memo. - [RED Cybersecurity Delegated Act Guide | Implement Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025)](/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide.md): Step-by-step implementation guide for the RED cybersecurity delegated act. - [RED Cybersecurity Requirements | Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025) | Article 3(3)(d)(e)(f)](/artifacts/eu/radio-equipment-directive/cybersecurity-requirements.md): A practical RED cybersecurity requirements guide: Delegated Regulation (EU) 2022/30 activates Article 3(3)(d) network protection. - [RED Deadlines and Compliance Calendar | Directive 2014/53/EU Key Dates (2016-2026) | Cybersecurity 2025, Common Charger 2024/2026](/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar.md): A practical RED deadlines and compliance calendar: core RED dates (transposition by 12 Jun 2016; measures apply from 13 Jun 2016. - [RED FAQ | EU Radio Equipment Directive 2014/53/EU Questions | Scope, CE Marking, Cybersecurity (EU) 2022/30, Standards](/artifacts/eu/radio-equipment-directive/faq.md): A practical RED FAQ for Directive 2014/53/EU: what is radio equipment, what is in scope, what happened in the 2016/2017 transition. - [RED Penalties and Enforcement | EU Radio Equipment Directive 2014/53/EU | Market Surveillance, CE Documentation Risk](/artifacts/eu/radio-equipment-directive/penalties-and-fines.md): A practical RED enforcement and penalties guide for Directive 2014/53/EU: how market surveillance works in practice. - [RED Timeline | EU Radio Equipment Directive 2014/53/EU Roadmap | Cybersecurity (EU) 2022/30, Common Charger (EU) 2022/2380](/artifacts/eu/radio-equipment-directive/timeline.md): A practical RED timeline and roadmap: the core RED transition dates. - [RED vs Cyber Resilience Act (CRA) | RED Cybersecurity (EU) 2022/30 vs CRA (EU) 2024/2847 | What Overlaps, What's Different](/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act.md): A practical comparison of RED vs CRA: RED (Directive 2014/53/EU) is radio-equipment-specific and. - [Scope and Classification | EU Radio Equipment Directive (RED) 2014/53/EU | What Is Radio Equipment? Exclusions, Borderline Cases](/artifacts/eu/radio-equipment-directive/scope-and-classification.md): A practical RED scope and classification guide for Directive 2014/53/EU: what counts as radio equipment, which Annex I exclusions take products out of scope. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/radio-equipment-directive/applicability-test --- --- title: "RED Compliance Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/checklist" source_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/checklist" author: "Sorena AI" description: "An audit-ready RED compliance checklist for Directive 2014/53/EU: scope and classification, essential requirements mapping (safety/health, EMC, spectrum)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RED compliance checklist" - "Radio Equipment Directive checklist" - "CE marking checklist RED" - "technical documentation checklist RED" - "EU declaration of conformity checklist RED" - "harmonised standards checklist RED" - "RED cybersecurity checklist 2022/30" - "RED" - "Checklist" - "CE marking" - "Technical documentation" - "Harmonised standards" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RED Compliance Checklist An audit-ready RED compliance checklist for Directive 2014/53/EU: scope and classification, essential requirements mapping (safety/health, EMC, spectrum). *RED* *Checklist* ## EU Radio Equipment Directive (RED) Compliance Checklist Turn RED into owned tasks and a retrievable CE evidence pack. Output: scope memo + requirements matrix + test plan + technical file + DoC. Use this checklist as your RED program spine. The objective is not only compliance, but evidence: for each product variant, you should be able to retrieve scope decisions, standards and tests used, and the exact CE documentation that matches the shipped configuration. ## 1) Scope and classification Lock scope early and document it. Scope drift is the most common cause of late rework. Save the scope memo in the technical documentation. - Classify the product as radio equipment (or document exclusion rationale) - List radio facts: bands, protocols, transmit power classes, receiver expectations - Identify variants (regional SKUs, firmware options, optional modules) ## 2) Essential requirements mapping (Article 3) Translate each essential requirement into acceptance criteria and verification evidence. If additional requirements are triggered (e.g., cybersecurity), document triggers and scope. - Core: safety/health, EMC, efficient use of spectrum - Additional triggers: privacy/data, fraud protection, interworking/emergency access (where relevant) - Cybersecurity: determine applicability of Delegated Regulation (EU) 2022/30 (applies from 1 Aug 2025) ## 3) Standards selection and verification test plan Use OJ-listed harmonised standards where possible and track updates. Build a requirements-to-standards matrix and a repeatable test plan. - Identify current harmonised standards references and applicability to your product - Define test cases, lab setup, and acceptance criteria per requirement - Plan variant coverage (which SKUs/firmware are covered by which tests) - Cybersecurity verification plan (if applicable): repeatable tests + evidence retention ## 4) Conformity assessment route and CE documentation Choose the route early. If a notified body is required, plan lead time. Treat the technical file and DoC as controlled release artifacts. - Route decision record: internal production control vs notified body route - Technical documentation: design evidence, standards matrix, test reports, change history - EU Declaration of Conformity: acts + standards referenced; model identifiers; version control - CE marking and labeling: ensure markings and user information match obligations ## 5) Timeline and release planning RED has key dates that affect product roadmaps (e.g., cybersecurity activation and charging interface amendments). Convert dates into release gates and procurement constraints. - Cybersecurity activation date: 1 Aug 2025 for (EU) 2022/30 after the postponement in Regulation (EU) 2023/2444 - Common charging interface: apply dates tied to Directive (EU) 2022/2380 annex categories - Harmonised standards updates: treat 2023/2392, 2023/2669, 2025/138, and 2025/893 as retest or evidence-review triggers ## 6) Audit and market surveillance readiness Most failures are evidence retrieval failures. Build a retrieval-first evidence vault. Run a drill: can you assemble the CE pack in hours? - Evidence vault: one folder per product family + variant appendices - Authority response playbook: owners and retrieval steps - Quarterly review: standards changes, firmware updates, supplier changes *Recommended next step* *Placement: after the checklist block* ## Turn EU Radio Equipment Directive (RED) Compliance Checklist into an operational assessment Assessment Autopilot can take EU Radio Equipment Directive (RED) Compliance Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Radio Equipment Directive (RED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Radio Equipment Directive (RED) Compliance Checklist](/solutions/assessment.md): Start from EU Radio Equipment Directive (RED) Compliance Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Radio Equipment Directive (RED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Radio Equipment Directive (RED) Compliance Checklist. ## Primary sources - [Directive 2014/53/EU (Radio Equipment Directive) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/53/oj?ref=sorena.io) - Primary source for essential requirements, conformity assessment, and CE obligations. - [EU Single Market - Radio equipment (harmonised standards)](https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards/radio-equipment_en?ref=sorena.io) - Official harmonised standards references and updates. - [Delegated Regulation (EU) 2022/30 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2022/30/oj?ref=sorena.io) - Cybersecurity activation scope. Use Regulation (EU) 2023/2444 for the current 1 Aug 2025 application date. - [Delegated Regulation (EU) 2023/2444 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2023/2444/oj?ref=sorena.io) - Moves the cybersecurity application date to 1 Aug 2025. ## Related Topic Guides - [Conformity Assessment and CE Marking | EU RED 2014/53/EU | Technical Documentation, EU DoC, Notified Bodies](/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce.md): A practical guide to RED conformity assessment and CE marking under Directive 2014/53/EU. - [Essential Requirements | EU Radio Equipment Directive (RED) 2014/53/EU | Safety, EMC, Spectrum, Cybersecurity (EU) 2022/30](/artifacts/eu/radio-equipment-directive/requirements.md): A practical RED essential requirements guide for Directive 2014/53/EU: map Article 3 requirements to product features and verification evidence for safety. - [Harmonised Standards and Test Plans | EU RED 2014/53/EU | Presumption of Conformity, OJ References, Verification Strategy](/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans.md): A practical guide to harmonised standards under the EU Radio Equipment Directive (RED) 2014/53/EU: how presumption of conformity works. - [RED Applicability Test | Is My Product in Scope of the EU Radio Equipment Directive (RED) 2014/53/EU?](/artifacts/eu/radio-equipment-directive/applicability-test.md): A structured RED applicability test for Directive 2014/53/EU: determine if your product is radio equipment, whether any exclusions apply. - [RED Compliance Program | EU Radio Equipment Directive 2014/53/EU Implementation Playbook](/artifacts/eu/radio-equipment-directive/compliance.md): A practical RED compliance program playbook for Directive 2014/53/EU: set up governance, map essential requirements to standards and tests. - [RED Conformity Assessment Template | CE Technical File Structure for Directive 2014/53/EU](/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template.md): A practical RED conformity assessment template for Directive 2014/53/EU: a CE technical file structure with sections for scope memo. - [RED Cybersecurity Delegated Act Guide | Implement Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025)](/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide.md): Step-by-step implementation guide for the RED cybersecurity delegated act. - [RED Cybersecurity Requirements | Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025) | Article 3(3)(d)(e)(f)](/artifacts/eu/radio-equipment-directive/cybersecurity-requirements.md): A practical RED cybersecurity requirements guide: Delegated Regulation (EU) 2022/30 activates Article 3(3)(d) network protection. - [RED Deadlines and Compliance Calendar | Directive 2014/53/EU Key Dates (2016-2026) | Cybersecurity 2025, Common Charger 2024/2026](/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar.md): A practical RED deadlines and compliance calendar: core RED dates (transposition by 12 Jun 2016; measures apply from 13 Jun 2016. - [RED FAQ | EU Radio Equipment Directive 2014/53/EU Questions | Scope, CE Marking, Cybersecurity (EU) 2022/30, Standards](/artifacts/eu/radio-equipment-directive/faq.md): A practical RED FAQ for Directive 2014/53/EU: what is radio equipment, what is in scope, what happened in the 2016/2017 transition. - [RED Penalties and Enforcement | EU Radio Equipment Directive 2014/53/EU | Market Surveillance, CE Documentation Risk](/artifacts/eu/radio-equipment-directive/penalties-and-fines.md): A practical RED enforcement and penalties guide for Directive 2014/53/EU: how market surveillance works in practice. - [RED Timeline | EU Radio Equipment Directive 2014/53/EU Roadmap | Cybersecurity (EU) 2022/30, Common Charger (EU) 2022/2380](/artifacts/eu/radio-equipment-directive/timeline.md): A practical RED timeline and roadmap: the core RED transition dates. - [RED vs Cyber Resilience Act (CRA) | RED Cybersecurity (EU) 2022/30 vs CRA (EU) 2024/2847 | What Overlaps, What's Different](/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act.md): A practical comparison of RED vs CRA: RED (Directive 2014/53/EU) is radio-equipment-specific and. - [Scope and Classification | EU Radio Equipment Directive (RED) 2014/53/EU | What Is Radio Equipment? Exclusions, Borderline Cases](/artifacts/eu/radio-equipment-directive/scope-and-classification.md): A practical RED scope and classification guide for Directive 2014/53/EU: what counts as radio equipment, which Annex I exclusions take products out of scope. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/radio-equipment-directive/checklist --- --- title: "RED Compliance Program" canonical_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/compliance" source_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/compliance" author: "Sorena AI" description: "A practical RED compliance program playbook for Directive 2014/53/EU: set up governance, map essential requirements to standards and tests." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RED compliance program" - "Radio Equipment Directive implementation" - "CE marking process RED" - "technical documentation process RED" - "EU declaration of conformity process" - "RED cybersecurity compliance 2022/30" - "RED" - "Compliance program" - "CE marking" - "Technical documentation" - "Cybersecurity" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RED Compliance Program A practical RED compliance program playbook for Directive 2014/53/EU: set up governance, map essential requirements to standards and tests. *RED* *Compliance* ## EU Radio Equipment Directive (RED) Compliance Program A release-ready compliance system beats one-off certification sprints. Build a repeatable process for standards, tests, documentation, and updates. A strong RED compliance program is a controlled pipeline: scope decisions -> requirements mapping -> standards/test plan -> conformity route -> technical file + DoC -> release gate. If you ship firmware updates or multiple SKUs, you need a compliance system that scales without rebuilding evidence every time. ## Program architecture (how to organise work) RED work breaks cleanly into workstreams: scope, essential requirements, standards and verification, conformity route, documentation, and lifecycle/change control. Assign owners per stream and define what 'done' means in evidence terms. - Scope owner: product classification and exclusions memo - Verification owner: standards matrix + test plan + lab coordination - Documentation owner: technical file structure + DoC generation/versioning - Security owner: cybersecurity controls and verification (if (EU) 2022/30 applies) - Supplier owner: module/vendor evidence, change notification, and traceability ## Release gating (the minimal set of gates that prevents rework) The best compliance gating is simple and strict: no shipping configuration without matching evidence. Treat firmware and radio configuration changes as compliance-impacting changes. - Gate 1: scope confirmed and documented - Gate 2: requirements-to-standards matrix complete and approved - Gate 3: verification tests passed for the shipped configuration/firmware - Gate 4: technical file updated and DoC regenerated (if needed) - Gate 5: labeling/user info reviewed and consistent with obligations ## Supplier and module evidence (where programs fail) Radio modules, chipsets, antennas, and firmware stacks are often supplied. Your technical file still needs evidence that covers the shipped integration. Make supplier evidence contractually enforceable and testable. - Module documentation: RF characteristics, compliance statements, and integration guidance - Change notifications: firmware, RF stack, antenna design, and component changes - Verification: integration tests that prove the final product meets requirements - Traceability: link supplier artifacts to product variants in your evidence vault ## Cybersecurity integration (if (EU) 2022/30 applies) Treat cybersecurity as a first-class essential requirement with tests and evidence, not as a generic security review. Build repeatable security verification tied to release cycles. - Applicability classification per product variant - Controls mapped to Article 3(3)(d)(e)(f) outcomes - Verification plan and repeatable tests (tools, versions, configs) - Lifecycle evidence: update policy, vulnerability response, and change logs ## Market surveillance readiness If you can export a complete evidence pack quickly, you reduce disruption and enforcement risk. Run a drill: simulate an authority request and time the response. - Evidence vault export: scope memo + standards matrix + test reports + DoC + labeling/user info - Single owner for responses and a clear internal escalation path - Quarterly maintenance: standards updates and product change review *Recommended next step* *Placement: after the compliance steps* ## Turn EU Radio Equipment Directive (RED) Compliance Program into an operational assessment Assessment Autopilot can take EU Radio Equipment Directive (RED) Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Radio Equipment Directive (RED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Radio Equipment Directive (RED) Compliance Program](/solutions/assessment.md): Start from EU Radio Equipment Directive (RED) Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Radio Equipment Directive (RED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Radio Equipment Directive (RED) Compliance Program. ## Primary sources - [Directive 2014/53/EU (Radio Equipment Directive) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/53/oj?ref=sorena.io) - Primary source for requirements, conformity assessment and documentation responsibilities. - [European Commission - Guide to the Radio Equipment Directive (RED Guide, 2018)](https://ec.europa.eu/growth/sectors/electrical-engineering/rtte-directive/?ref=sorena.io) - Practical program guidance: standards, notified bodies, and documentation expectations. - [Delegated Regulation (EU) 2022/30 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2022/30/oj?ref=sorena.io) - Cybersecurity activation scope. Use Regulation (EU) 2023/2444 for the current 1 Aug 2025 application date. - [Delegated Regulation (EU) 2023/2444 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2023/2444/oj?ref=sorena.io) - Moves the cybersecurity application date to 1 Aug 2025. ## Related Topic Guides - [Conformity Assessment and CE Marking | EU RED 2014/53/EU | Technical Documentation, EU DoC, Notified Bodies](/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce.md): A practical guide to RED conformity assessment and CE marking under Directive 2014/53/EU. - [Essential Requirements | EU Radio Equipment Directive (RED) 2014/53/EU | Safety, EMC, Spectrum, Cybersecurity (EU) 2022/30](/artifacts/eu/radio-equipment-directive/requirements.md): A practical RED essential requirements guide for Directive 2014/53/EU: map Article 3 requirements to product features and verification evidence for safety. - [Harmonised Standards and Test Plans | EU RED 2014/53/EU | Presumption of Conformity, OJ References, Verification Strategy](/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans.md): A practical guide to harmonised standards under the EU Radio Equipment Directive (RED) 2014/53/EU: how presumption of conformity works. - [RED Applicability Test | Is My Product in Scope of the EU Radio Equipment Directive (RED) 2014/53/EU?](/artifacts/eu/radio-equipment-directive/applicability-test.md): A structured RED applicability test for Directive 2014/53/EU: determine if your product is radio equipment, whether any exclusions apply. - [RED Compliance Checklist | EU Radio Equipment Directive 2014/53/EU | CE Marking Evidence Pack](/artifacts/eu/radio-equipment-directive/checklist.md): An audit-ready RED compliance checklist for Directive 2014/53/EU: scope and classification, essential requirements mapping (safety/health, EMC, spectrum). - [RED Conformity Assessment Template | CE Technical File Structure for Directive 2014/53/EU](/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template.md): A practical RED conformity assessment template for Directive 2014/53/EU: a CE technical file structure with sections for scope memo. - [RED Cybersecurity Delegated Act Guide | Implement Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025)](/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide.md): Step-by-step implementation guide for the RED cybersecurity delegated act. - [RED Cybersecurity Requirements | Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025) | Article 3(3)(d)(e)(f)](/artifacts/eu/radio-equipment-directive/cybersecurity-requirements.md): A practical RED cybersecurity requirements guide: Delegated Regulation (EU) 2022/30 activates Article 3(3)(d) network protection. - [RED Deadlines and Compliance Calendar | Directive 2014/53/EU Key Dates (2016-2026) | Cybersecurity 2025, Common Charger 2024/2026](/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar.md): A practical RED deadlines and compliance calendar: core RED dates (transposition by 12 Jun 2016; measures apply from 13 Jun 2016. - [RED FAQ | EU Radio Equipment Directive 2014/53/EU Questions | Scope, CE Marking, Cybersecurity (EU) 2022/30, Standards](/artifacts/eu/radio-equipment-directive/faq.md): A practical RED FAQ for Directive 2014/53/EU: what is radio equipment, what is in scope, what happened in the 2016/2017 transition. - [RED Penalties and Enforcement | EU Radio Equipment Directive 2014/53/EU | Market Surveillance, CE Documentation Risk](/artifacts/eu/radio-equipment-directive/penalties-and-fines.md): A practical RED enforcement and penalties guide for Directive 2014/53/EU: how market surveillance works in practice. - [RED Timeline | EU Radio Equipment Directive 2014/53/EU Roadmap | Cybersecurity (EU) 2022/30, Common Charger (EU) 2022/2380](/artifacts/eu/radio-equipment-directive/timeline.md): A practical RED timeline and roadmap: the core RED transition dates. - [RED vs Cyber Resilience Act (CRA) | RED Cybersecurity (EU) 2022/30 vs CRA (EU) 2024/2847 | What Overlaps, What's Different](/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act.md): A practical comparison of RED vs CRA: RED (Directive 2014/53/EU) is radio-equipment-specific and. - [Scope and Classification | EU Radio Equipment Directive (RED) 2014/53/EU | What Is Radio Equipment? Exclusions, Borderline Cases](/artifacts/eu/radio-equipment-directive/scope-and-classification.md): A practical RED scope and classification guide for Directive 2014/53/EU: what counts as radio equipment, which Annex I exclusions take products out of scope. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/radio-equipment-directive/compliance --- --- title: "Conformity Assessment and CE Marking" canonical_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce" source_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce" author: "Sorena AI" description: "A practical guide to RED conformity assessment and CE marking under Directive 2014/53/EU." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RED conformity assessment" - "CE marking radio equipment" - "EU declaration of conformity RED" - "technical documentation RED" - "notified body RED" - "Annex II Annex III Annex IV RED" - "RED" - "Conformity assessment" - "CE marking" - "EU declaration of conformity" - "Notified body" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Conformity Assessment and CE Marking A practical guide to RED conformity assessment and CE marking under Directive 2014/53/EU. *CE Marking* *RED* ## EU Radio Equipment Directive (RED) Conformity Assessment and CE Make CE evidence a controlled release artifact. Output: route decision + technical file + EU DoC with traceability to tests and standards. RED conformity assessment is about proving compliance, not stating it. The fastest path is to (1) use harmonised standards where possible, (2) choose the right conformity assessment module early, and (3) structure the technical documentation so you can answer market surveillance questions quickly. ## Choose the route: how teams decide correctly Your route depends on standards coverage, product complexity, and whether you need third-party assessment for parts of the design. Make route selection explicit in a short decision record: what standards you use, what gaps exist, and whether you involve a notified body. - For Article 3(1)(a) and 3(1)(b), manufacturers may use Annex II internal production control even without harmonised standards - For Article 3(2) and 3(3), Annex II is available only when OJ-listed harmonised standards are fully applied for the relevant requirements - If Article 3(2) or 3(3) coverage is incomplete, partly applied, or absent, use Annex III or Annex IV with a notified body - Cybersecurity (EU) 2022/30: treat cybersecurity evidence as part of the technical documentation when applicable ## Technical documentation (what it must do) The technical file should be a retrievable story: product facts -> requirements -> standards/tests -> results -> declarations. Structure it by product type and variant so you don't rebuild it for every SKU. - Product description + intended use + variants - Design evidence: schematics, BOM, firmware versions, radios/bands/protocols - Requirements mapping: Article 3 requirements to verification methods - Test evidence: EMC, spectrum, safety, and (if applicable) cybersecurity verification - Change control: what changed since last release and why it doesn't break compliance ## EU Declaration of Conformity (DoC): treat it like code The DoC is not a one-time PDF. It is a controlled compliance artifact that must match the shipped product and the standards/tests you used. Build DoC generation and maintenance into release processes. - List applicable legal acts (RED, plus any activated delegated acts) and the standards used - Ensure model identifiers and variant coverage match what is shipped - Version and retain the DoC and technical documentation for 10 years after the radio equipment is placed on the market - Update the DoC when design, firmware, radio characteristics, or standards references change ## Notified bodies: when they matter and how to use them effectively Notified body engagement is slowest when the evidence pack is incomplete. Prepare a review-ready package. Decide early which parts of the file are in scope for third-party assessment. - Plan lead time: notified body schedules can affect your launch date, especially where Article 3(2) or 3(3) cannot rely fully on harmonised standards - Prepare a review pack: requirements matrix, standards list, test reports, risk documentation, and change history - Keep alignment: the notified body view should match the DoC and product shipped ## Market surveillance readiness (your fastest ROI) Most enforcement pain is evidence retrieval, not technical non-compliance. Build a retrieval-first technical file. Run a drill: can you assemble the pack in hours, not weeks? - Evidence vault per product family and variant - Authority response playbook: owners, timelines, and export formats - Internal pre-audit checks: scope memo, DoC, standards references, test coverage *Recommended next step* *Placement: after the main workflow section* ## Turn EU Radio Equipment Directive (RED) Conformity Assessment and CE into an operational assessment Assessment Autopilot can take EU Radio Equipment Directive (RED) Conformity Assessment and CE from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on EU Radio Equipment Directive (RED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Radio Equipment Directive (RED) Conformity Assessment and CE](/solutions/assessment.md): Start from EU Radio Equipment Directive (RED) Conformity Assessment and CE and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Radio Equipment Directive (RED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Radio Equipment Directive (RED) Conformity Assessment and CE. ## Primary sources - [Directive 2014/53/EU (Radio Equipment Directive) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/53/oj?ref=sorena.io) - Primary source for conformity assessment, CE marking obligations, and documentation expectations. - [European Commission - Guide to the Radio Equipment Directive (RED Guide, 2018)](https://ec.europa.eu/growth/sectors/electrical-engineering/rtte-directive/?ref=sorena.io) - Practical guidance on Article 17 route selection, notified bodies, technical documentation, and the DoC. - [EU Single Market - Notified bodies (overview)](https://single-market-economy.ec.europa.eu/single-market/goods/building-blocks/notified-bodies_en?ref=sorena.io) - Official overview of notified bodies within EU product compliance frameworks. ## Related Topic Guides - [Essential Requirements | EU Radio Equipment Directive (RED) 2014/53/EU | Safety, EMC, Spectrum, Cybersecurity (EU) 2022/30](/artifacts/eu/radio-equipment-directive/requirements.md): A practical RED essential requirements guide for Directive 2014/53/EU: map Article 3 requirements to product features and verification evidence for safety. - [Harmonised Standards and Test Plans | EU RED 2014/53/EU | Presumption of Conformity, OJ References, Verification Strategy](/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans.md): A practical guide to harmonised standards under the EU Radio Equipment Directive (RED) 2014/53/EU: how presumption of conformity works. - [RED Applicability Test | Is My Product in Scope of the EU Radio Equipment Directive (RED) 2014/53/EU?](/artifacts/eu/radio-equipment-directive/applicability-test.md): A structured RED applicability test for Directive 2014/53/EU: determine if your product is radio equipment, whether any exclusions apply. - [RED Compliance Checklist | EU Radio Equipment Directive 2014/53/EU | CE Marking Evidence Pack](/artifacts/eu/radio-equipment-directive/checklist.md): An audit-ready RED compliance checklist for Directive 2014/53/EU: scope and classification, essential requirements mapping (safety/health, EMC, spectrum). - [RED Compliance Program | EU Radio Equipment Directive 2014/53/EU Implementation Playbook](/artifacts/eu/radio-equipment-directive/compliance.md): A practical RED compliance program playbook for Directive 2014/53/EU: set up governance, map essential requirements to standards and tests. - [RED Conformity Assessment Template | CE Technical File Structure for Directive 2014/53/EU](/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template.md): A practical RED conformity assessment template for Directive 2014/53/EU: a CE technical file structure with sections for scope memo. - [RED Cybersecurity Delegated Act Guide | Implement Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025)](/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide.md): Step-by-step implementation guide for the RED cybersecurity delegated act. - [RED Cybersecurity Requirements | Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025) | Article 3(3)(d)(e)(f)](/artifacts/eu/radio-equipment-directive/cybersecurity-requirements.md): A practical RED cybersecurity requirements guide: Delegated Regulation (EU) 2022/30 activates Article 3(3)(d) network protection. - [RED Deadlines and Compliance Calendar | Directive 2014/53/EU Key Dates (2016-2026) | Cybersecurity 2025, Common Charger 2024/2026](/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar.md): A practical RED deadlines and compliance calendar: core RED dates (transposition by 12 Jun 2016; measures apply from 13 Jun 2016. - [RED FAQ | EU Radio Equipment Directive 2014/53/EU Questions | Scope, CE Marking, Cybersecurity (EU) 2022/30, Standards](/artifacts/eu/radio-equipment-directive/faq.md): A practical RED FAQ for Directive 2014/53/EU: what is radio equipment, what is in scope, what happened in the 2016/2017 transition. - [RED Penalties and Enforcement | EU Radio Equipment Directive 2014/53/EU | Market Surveillance, CE Documentation Risk](/artifacts/eu/radio-equipment-directive/penalties-and-fines.md): A practical RED enforcement and penalties guide for Directive 2014/53/EU: how market surveillance works in practice. - [RED Timeline | EU Radio Equipment Directive 2014/53/EU Roadmap | Cybersecurity (EU) 2022/30, Common Charger (EU) 2022/2380](/artifacts/eu/radio-equipment-directive/timeline.md): A practical RED timeline and roadmap: the core RED transition dates. - [RED vs Cyber Resilience Act (CRA) | RED Cybersecurity (EU) 2022/30 vs CRA (EU) 2024/2847 | What Overlaps, What's Different](/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act.md): A practical comparison of RED vs CRA: RED (Directive 2014/53/EU) is radio-equipment-specific and. - [Scope and Classification | EU Radio Equipment Directive (RED) 2014/53/EU | What Is Radio Equipment? Exclusions, Borderline Cases](/artifacts/eu/radio-equipment-directive/scope-and-classification.md): A practical RED scope and classification guide for Directive 2014/53/EU: what counts as radio equipment, which Annex I exclusions take products out of scope. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce --- --- title: "RED Cybersecurity Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/cybersecurity-requirements" source_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/cybersecurity-requirements" author: "Sorena AI" description: "A practical RED cybersecurity requirements guide: Delegated Regulation (EU) 2022/30 activates Article 3(3)(d) network protection." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RED cybersecurity requirements" - "Delegated Regulation EU 2022/30" - "RED Article 3(3)(d)(e)(f)" - "radio equipment cybersecurity 1 August 2025" - "internet-connected radio equipment RED" - "wearable radio equipment RED cybersecurity" - "toy radio equipment RED cybersecurity" - "RED" - "Cybersecurity" - "Delegated Regulation (EU) 2022/30" - "Article 3(3)" - "CE evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RED Cybersecurity Requirements A practical RED cybersecurity requirements guide: Delegated Regulation (EU) 2022/30 activates Article 3(3)(d) network protection. *EU 2022/30* *Cybersecurity* ## EU Radio Equipment Directive (RED) Cybersecurity Requirements Treat RED cybersecurity like a certification-grade control set. Output: controls + tests + technical file evidence for 1 Aug 2025 applicability. Delegated Regulation (EU) 2022/30 activates cybersecurity-related essential requirements in the RED for defined radio equipment categories. If you ship internet-connected radio products, wearables, childcare products with radio, or devices handling sensitive data or value transfers, treat cybersecurity as part of your CE evidence pack, not as a separate security policy. ## What (EU) 2022/30 does (in plain language) The RED already contains cybersecurity-related essential requirements in Article 3(3)(d), (e) and (f). The delegated regulation makes them applicable to specific categories of radio equipment. It applies from 1 August 2025 because Regulation (EU) 2023/2444 postponed the original start date, and it does not prevent voluntary early compliance. - Date: applies from 1 Aug 2025 - It activates: network protection, privacy/personal data protection, and fraud protection - It is CE-relevant: you must be able to demonstrate compliance in your technical documentation ## Which products are in scope (the practical triggers) Scope is defined by product characteristics. Use architecture and data-flow facts, not marketing labels. If your product category is unclear, document your interpretation and keep it with the technical file. - Internet-connected radio equipment: triggers network protection (Article 3(3)(d)) - Equipment processing personal data or traffic/location data: triggers privacy/data protection (Article 3(3)(e)) - Internet-connected equipment enabling transfer of money/monetary value/virtual currency: triggers fraud protection (Article 3(3)(f)) - Special attention categories discussed in the delegated regulation include childcare products, toys, and wearable radio equipment - Check the consolidated derogations for products already subject to Regulation (EU) 2018/1139, Regulation (EU) 2019/2144, or Directive (EU) 2019/520 ## Translate requirements into controls (what 'good' looks like) Avoid generic statements like we are secure. Build a control set that maps to the three activated requirements and can be verified. Make controls measurable: configuration baselines, security objectives, and test evidence. - Network protection: secure boot chain, hardening, network-service minimisation, resilience against misuse (e.g., botnet enrolment patterns) - Privacy/data protection: data minimisation, secure storage, access control, secure communications, and privacy-by-design decisions documented - Fraud protection: strong authentication, transaction integrity, anti-tampering, and abuse monitoring for value transfer flows - Update and vulnerability handling: patchability and disclosure/response processes as part of lifecycle controls *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU Radio Equipment Directive (RED) Cybersecurity Requirements into an operational assessment Assessment Autopilot can take EU Radio Equipment Directive (RED) Cybersecurity Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Radio Equipment Directive (RED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Radio Equipment Directive (RED) Cybersecurity Requirements](/solutions/assessment.md): Start from EU Radio Equipment Directive (RED) Cybersecurity Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Radio Equipment Directive (RED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Radio Equipment Directive (RED) Cybersecurity Requirements. ## Evidence pack (what to keep for CE and market surveillance) Your evidence should be structured so you can answer authority questions quickly. Treat the cybersecurity pack as a module in the technical documentation: traceability matters. - Scope memo: why (EU) 2022/30 does/doesn't apply + which requirement(s) are triggered - Architecture + threat model: trust boundaries, data flows, security objectives - Verification: test plan and results (including negative tests and misuse cases) - Operational lifecycle: update policy, vulnerability intake/response, and change-control records ## Primary sources - [Delegated Regulation (EU) 2022/30 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2022/30/oj?ref=sorena.io) - Primary source for the cybersecurity activation scope. Read together with Regulation (EU) 2023/2444 for the current 1 Aug 2025 application date. - [Delegated Regulation (EU) 2023/2444 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2023/2444/oj?ref=sorena.io) - Postpones the cybersecurity application date to 1 Aug 2025 and corrects the wording for Article 3(3)(e) equipment. - [Directive 2014/53/EU (Radio Equipment Directive) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/53/oj?ref=sorena.io) - Primary source for Article 3 essential requirements and CE conformity framework. - [European Commission - Commission strengthens cybersecurity of wireless devices and products](https://ec.europa.eu/growth/news/commission-strengthens-cybersecurity-wireless-devices-and-products-2021-10-29_en?ref=sorena.io) - Commission communication about strengthening cybersecurity of wireless devices under RED. ## Related Topic Guides - [Conformity Assessment and CE Marking | EU RED 2014/53/EU | Technical Documentation, EU DoC, Notified Bodies](/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce.md): A practical guide to RED conformity assessment and CE marking under Directive 2014/53/EU. - [Essential Requirements | EU Radio Equipment Directive (RED) 2014/53/EU | Safety, EMC, Spectrum, Cybersecurity (EU) 2022/30](/artifacts/eu/radio-equipment-directive/requirements.md): A practical RED essential requirements guide for Directive 2014/53/EU: map Article 3 requirements to product features and verification evidence for safety. - [Harmonised Standards and Test Plans | EU RED 2014/53/EU | Presumption of Conformity, OJ References, Verification Strategy](/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans.md): A practical guide to harmonised standards under the EU Radio Equipment Directive (RED) 2014/53/EU: how presumption of conformity works. - [RED Applicability Test | Is My Product in Scope of the EU Radio Equipment Directive (RED) 2014/53/EU?](/artifacts/eu/radio-equipment-directive/applicability-test.md): A structured RED applicability test for Directive 2014/53/EU: determine if your product is radio equipment, whether any exclusions apply. - [RED Compliance Checklist | EU Radio Equipment Directive 2014/53/EU | CE Marking Evidence Pack](/artifacts/eu/radio-equipment-directive/checklist.md): An audit-ready RED compliance checklist for Directive 2014/53/EU: scope and classification, essential requirements mapping (safety/health, EMC, spectrum). - [RED Compliance Program | EU Radio Equipment Directive 2014/53/EU Implementation Playbook](/artifacts/eu/radio-equipment-directive/compliance.md): A practical RED compliance program playbook for Directive 2014/53/EU: set up governance, map essential requirements to standards and tests. - [RED Conformity Assessment Template | CE Technical File Structure for Directive 2014/53/EU](/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template.md): A practical RED conformity assessment template for Directive 2014/53/EU: a CE technical file structure with sections for scope memo. - [RED Cybersecurity Delegated Act Guide | Implement Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025)](/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide.md): Step-by-step implementation guide for the RED cybersecurity delegated act. - [RED Deadlines and Compliance Calendar | Directive 2014/53/EU Key Dates (2016-2026) | Cybersecurity 2025, Common Charger 2024/2026](/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar.md): A practical RED deadlines and compliance calendar: core RED dates (transposition by 12 Jun 2016; measures apply from 13 Jun 2016. - [RED FAQ | EU Radio Equipment Directive 2014/53/EU Questions | Scope, CE Marking, Cybersecurity (EU) 2022/30, Standards](/artifacts/eu/radio-equipment-directive/faq.md): A practical RED FAQ for Directive 2014/53/EU: what is radio equipment, what is in scope, what happened in the 2016/2017 transition. - [RED Penalties and Enforcement | EU Radio Equipment Directive 2014/53/EU | Market Surveillance, CE Documentation Risk](/artifacts/eu/radio-equipment-directive/penalties-and-fines.md): A practical RED enforcement and penalties guide for Directive 2014/53/EU: how market surveillance works in practice. - [RED Timeline | EU Radio Equipment Directive 2014/53/EU Roadmap | Cybersecurity (EU) 2022/30, Common Charger (EU) 2022/2380](/artifacts/eu/radio-equipment-directive/timeline.md): A practical RED timeline and roadmap: the core RED transition dates. - [RED vs Cyber Resilience Act (CRA) | RED Cybersecurity (EU) 2022/30 vs CRA (EU) 2024/2847 | What Overlaps, What's Different](/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act.md): A practical comparison of RED vs CRA: RED (Directive 2014/53/EU) is radio-equipment-specific and. - [Scope and Classification | EU Radio Equipment Directive (RED) 2014/53/EU | What Is Radio Equipment? Exclusions, Borderline Cases](/artifacts/eu/radio-equipment-directive/scope-and-classification.md): A practical RED scope and classification guide for Directive 2014/53/EU: what counts as radio equipment, which Annex I exclusions take products out of scope. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/radio-equipment-directive/cybersecurity-requirements --- --- title: "RED Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A practical RED deadlines and compliance calendar: core RED dates (transposition by 12 Jun 2016; measures apply from 13 Jun 2016." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RED deadlines" - "Radio Equipment Directive timeline" - "Directive 2014/53/EU apply date" - "RED transition period 2017" - "RED cybersecurity 2025" - "Delegated Regulation 2022/30 apply 1 August 2025" - "common charger RED 28 December 2024 28 April 2026" - "RED" - "Deadlines" - "Cybersecurity" - "Common charger" - "Compliance calendar" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RED Deadlines and Compliance Calendar A practical RED deadlines and compliance calendar: core RED dates (transposition by 12 Jun 2016; measures apply from 13 Jun 2016. *RED* *Deadlines* ## EU Radio Equipment Directive (RED) Deadlines and Compliance Calendar Turn dates into owned milestones and release gates. Use this page to plan test cycles, notified body lead time, and CE evidence updates. RED compliance isn't one date - it's a set of dates that drive product roadmaps: the core RED regime, the cybersecurity activation date, and device-category amendments (like the common charging interface). Use this calendar to schedule scope decisions, standards updates, verification cycles, and documentation releases. ## Recent standards update checkpoints The OJ list of RED standards did not stand still after 2022. Treat these publication and deferred-application dates as evidence-maintenance checkpoints. They matter most for labs, EMF files, and RED cybersecurity projects using the EN 18031 series. - 4 Apr 2025: Decision (EU) 2023/2392 deferred withdrawals start to apply - 1 Jun 2025: Decision (EU) 2023/2669 deferred withdrawals for EN 50360 and EN 50566 start to apply - 15 Nov 2026 and 15 May 2028: Decision (EU) 2025/893 deferred dates for some replaced radio-spectrum standards - 28 Jan 2025: Decision (EU) 2025/138 adds EN 18031-1, EN 18031-2, and EN 18031-3 with restrictions for RED cybersecurity work ## Core RED dates (2016-2017) RED replaced the previous regime with a transposition and transition timeline. These dates still matter for legacy products and for understanding how enforcement expectations evolved. Treat them as historical anchors and ensure your internal references are aligned to RED, not the older directive. - By 12 Jun 2016: Member States adopt and publish transposition measures - From 13 Jun 2016: measures apply and the previous directive was repealed - Transition ended 12 Jun 2017: new products placed on the market after this date should comply with RED requirements ## Cybersecurity date: 1 Aug 2025 (EU 2022/30) Delegated Regulation (EU) 2022/30 activates cybersecurity-related essential requirements for defined categories of radio equipment. Regulation (EU) 2023/2444 postponed the original 2024 start date to 1 Aug 2025 so standards and test programs could catch up. Schedule cybersecurity evidence the same way you schedule EMC and spectrum evidence: as part of a repeatable verification plan. - Applies from 1 Aug 2025 - Triggers depend on product characteristics (internet-connected, data-processing, value transfer) - Deliverables: applicability memo + controls mapping + verification plan + technical file module ## Common charging interface dates (Directive (EU) 2022/2380) Directive (EU) 2022/2380 amended RED to introduce common charging interface obligations for defined categories/classes of radio equipment listed in Annex Ia. Use these dates to drive connector design decisions and procurement constraints. - By 28 Dec 2023: Member States adopt and publish transposition measures - From 28 Dec 2024: measures apply for categories/classes in Annex Ia Part I points 1.1-1.12 - From 28 Apr 2026: measures apply for categories/classes in Annex Ia Part I point 1.13 ## Calendar-ready milestone checklist (what to schedule) Use this as your baseline project plan. If you have multiple SKUs, schedule per product family and then add variant-level tasks. Work backwards from the applicable dates to set lab booking and evidence preparation deadlines. - Scope lock: product classification memo and exclusions analysis - Requirements matrix: Article 3 mapping to standards/tests - Verification: EMC/spectrum/safety test plan and reports; cybersecurity tests if applicable - Conformity route: notified body engagement (if needed) and lead time buffer - Documentation release: technical file update + DoC regeneration + labeling/user info review *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU Radio Equipment Directive (RED) Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take EU Radio Equipment Directive (RED) Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Radio Equipment Directive (RED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Radio Equipment Directive (RED) Deadlines and Compliance Calendar](/solutions/assessment.md): Start from EU Radio Equipment Directive (RED) Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Radio Equipment Directive (RED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Radio Equipment Directive (RED) Deadlines and Compliance Calendar. ## Primary sources - [Directive 2014/53/EU (Radio Equipment Directive) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/53/oj?ref=sorena.io) - Primary source for RED transposition and transition timeline and core obligations. - [Delegated Regulation (EU) 2022/30 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2022/30/oj?ref=sorena.io) - Primary source for cybersecurity activation scope. Use the amending Regulation (EU) 2023/2444 for the current 1 Aug 2025 application date. - [Delegated Regulation (EU) 2023/2444 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2023/2444/oj?ref=sorena.io) - Moves the cybersecurity application date to 1 Aug 2025. - [Directive (EU) 2022/2380 (common charging interface amendments to RED) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2380/oj?ref=sorena.io) - Sets transposition and application dates for common charging interface measures via Annex Ia categories. ## Related Topic Guides - [Conformity Assessment and CE Marking | EU RED 2014/53/EU | Technical Documentation, EU DoC, Notified Bodies](/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce.md): A practical guide to RED conformity assessment and CE marking under Directive 2014/53/EU. - [Essential Requirements | EU Radio Equipment Directive (RED) 2014/53/EU | Safety, EMC, Spectrum, Cybersecurity (EU) 2022/30](/artifacts/eu/radio-equipment-directive/requirements.md): A practical RED essential requirements guide for Directive 2014/53/EU: map Article 3 requirements to product features and verification evidence for safety. - [Harmonised Standards and Test Plans | EU RED 2014/53/EU | Presumption of Conformity, OJ References, Verification Strategy](/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans.md): A practical guide to harmonised standards under the EU Radio Equipment Directive (RED) 2014/53/EU: how presumption of conformity works. - [RED Applicability Test | Is My Product in Scope of the EU Radio Equipment Directive (RED) 2014/53/EU?](/artifacts/eu/radio-equipment-directive/applicability-test.md): A structured RED applicability test for Directive 2014/53/EU: determine if your product is radio equipment, whether any exclusions apply. - [RED Compliance Checklist | EU Radio Equipment Directive 2014/53/EU | CE Marking Evidence Pack](/artifacts/eu/radio-equipment-directive/checklist.md): An audit-ready RED compliance checklist for Directive 2014/53/EU: scope and classification, essential requirements mapping (safety/health, EMC, spectrum). - [RED Compliance Program | EU Radio Equipment Directive 2014/53/EU Implementation Playbook](/artifacts/eu/radio-equipment-directive/compliance.md): A practical RED compliance program playbook for Directive 2014/53/EU: set up governance, map essential requirements to standards and tests. - [RED Conformity Assessment Template | CE Technical File Structure for Directive 2014/53/EU](/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template.md): A practical RED conformity assessment template for Directive 2014/53/EU: a CE technical file structure with sections for scope memo. - [RED Cybersecurity Delegated Act Guide | Implement Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025)](/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide.md): Step-by-step implementation guide for the RED cybersecurity delegated act. - [RED Cybersecurity Requirements | Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025) | Article 3(3)(d)(e)(f)](/artifacts/eu/radio-equipment-directive/cybersecurity-requirements.md): A practical RED cybersecurity requirements guide: Delegated Regulation (EU) 2022/30 activates Article 3(3)(d) network protection. - [RED FAQ | EU Radio Equipment Directive 2014/53/EU Questions | Scope, CE Marking, Cybersecurity (EU) 2022/30, Standards](/artifacts/eu/radio-equipment-directive/faq.md): A practical RED FAQ for Directive 2014/53/EU: what is radio equipment, what is in scope, what happened in the 2016/2017 transition. - [RED Penalties and Enforcement | EU Radio Equipment Directive 2014/53/EU | Market Surveillance, CE Documentation Risk](/artifacts/eu/radio-equipment-directive/penalties-and-fines.md): A practical RED enforcement and penalties guide for Directive 2014/53/EU: how market surveillance works in practice. - [RED Timeline | EU Radio Equipment Directive 2014/53/EU Roadmap | Cybersecurity (EU) 2022/30, Common Charger (EU) 2022/2380](/artifacts/eu/radio-equipment-directive/timeline.md): A practical RED timeline and roadmap: the core RED transition dates. - [RED vs Cyber Resilience Act (CRA) | RED Cybersecurity (EU) 2022/30 vs CRA (EU) 2024/2847 | What Overlaps, What's Different](/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act.md): A practical comparison of RED vs CRA: RED (Directive 2014/53/EU) is radio-equipment-specific and. - [Scope and Classification | EU Radio Equipment Directive (RED) 2014/53/EU | What Is Radio Equipment? Exclusions, Borderline Cases](/artifacts/eu/radio-equipment-directive/scope-and-classification.md): A practical RED scope and classification guide for Directive 2014/53/EU: what counts as radio equipment, which Annex I exclusions take products out of scope. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar --- --- title: "RED FAQ" canonical_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/faq" source_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/faq" author: "Sorena AI" description: "A practical RED FAQ for Directive 2014/53/EU: what is radio equipment, what is in scope, what happened in the 2016/2017 transition." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RED FAQ" - "Radio Equipment Directive questions" - "Directive 2014/53/EU explained" - "CE marking radio equipment FAQ" - "harmonised standards RED FAQ" - "notified body RED FAQ" - "RED cybersecurity 2022/30 FAQ" - "RED" - "FAQ" - "CE marking" - "Harmonised standards" - "Cybersecurity" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RED FAQ A practical RED FAQ for Directive 2014/53/EU: what is radio equipment, what is in scope, what happened in the 2016/2017 transition. *RED* *FAQ* ## EU Radio Equipment Directive (RED) FAQ Fast answers to scope and CE evidence questions. Grounded in official sources; use the linked deep-dive pages for implementation. This FAQ is for teams building or shipping radio products. It focuses on practical interpretations: scope, evidence, standards, and the cybersecurity activation requirements. ## What is 'radio equipment' under RED? In practical terms: equipment that intentionally transmits and/or receives radio waves for radiocommunication or radiodetermination. If the radio is integrated into a larger product, the final product can still be in scope depending on what is placed on the market and how it is intended to be used. - Start with facts: bands, protocols, emission characteristics, and intended use - Document borderline cases in a scope memo - Use the applicability test to get a structured outcome ## When did RED apply and what was the transition? Member States applied RED measures from 13 June 2016, with a transition period that ended on 12 June 2017. For legacy products, what matters is when the equipment was first placed on the market and which rules applied at that time. - Core dates: 13 Jun 2016 (apply) and 12 Jun 2017 (transition ends) - Keep evidence aligned to the applicable regime for legacy stock - For new launches, build a RED-native evidence pack ## Do we always need a notified body? Not always. Many products rely on harmonised standards and internal production control routes. If you can't rely on harmonised standards coverage (or you deviate materially), notified body involvement may become relevant depending on the conformity route you choose. - Use OJ-listed harmonised standards where possible - Document gaps and the chosen route - Plan notified body lead time early if needed ## What's the minimum CE evidence we need? The minimum is not just a DoC. You need technical documentation that proves conformity for the shipped configuration and variants. The evidence should be retrievable per product variant and match the standards/tests you used. - Scope memo and requirements mapping - Standards matrix and verification plan - Test reports (EMC/spectrum/safety) and configuration baselines - EU Declaration of Conformity (controlled, versioned) - Change history and update governance ## What changes with RED cybersecurity (EU) 2022/30? Delegated Regulation (EU) 2022/30 activates cybersecurity-related essential requirements for defined radio equipment categories. It applies from 1 August 2025 because Regulation (EU) 2023/2444 postponed the original 2024 date. If your product is internet-connected or handles personal data or enables value transfers, you should run the applicability classification and build a cybersecurity evidence module. - Applies from 1 Aug 2025 - Activates: network protection, privacy/personal data, fraud protection - Deliverable: controls + tests + technical documentation module ## How do we stay current on harmonised standards? Standards references are updated via Official Journal publications and implementing decisions. Treat changes as compliance-impacting events: updates can trigger retesting or evidence updates. - Use the official 'harmonised standards for radio equipment' page - Track OJ updates and withdrawn references - Review standards impact as part of release gating *Recommended next step* *Placement: after the FAQ section* ## Use EU Radio Equipment Directive (RED) FAQ as a cited research workflow Research Copilot can take EU Radio Equipment Directive (RED) FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU Radio Equipment Directive (RED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Radio Equipment Directive (RED) FAQ](/solutions/research-copilot.md): Start from EU Radio Equipment Directive (RED) FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Radio Equipment Directive (RED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Radio Equipment Directive (RED) FAQ. ## Primary sources - [Directive 2014/53/EU (Radio Equipment Directive) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/53/oj?ref=sorena.io) - Primary source for scope, essential requirements, and conformity framework. - [European Commission - Guide to the Radio Equipment Directive (RED Guide, 2018)](https://ec.europa.eu/growth/sectors/electrical-engineering/rtte-directive/?ref=sorena.io) - Practical guidance and examples used by implementation teams. - [EU Single Market - Harmonised standards for radio equipment](https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards/radio-equipment_en?ref=sorena.io) - Official consolidated references to harmonised standards and updates. - [Delegated Regulation (EU) 2022/30 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2022/30/oj?ref=sorena.io) - Cybersecurity activation scope. Read it with Regulation (EU) 2023/2444 for the current 1 Aug 2025 date. - [Delegated Regulation (EU) 2023/2444 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2023/2444/oj?ref=sorena.io) - Moves the cybersecurity application date to 1 Aug 2025. ## Related Topic Guides - [Conformity Assessment and CE Marking | EU RED 2014/53/EU | Technical Documentation, EU DoC, Notified Bodies](/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce.md): A practical guide to RED conformity assessment and CE marking under Directive 2014/53/EU. - [Essential Requirements | EU Radio Equipment Directive (RED) 2014/53/EU | Safety, EMC, Spectrum, Cybersecurity (EU) 2022/30](/artifacts/eu/radio-equipment-directive/requirements.md): A practical RED essential requirements guide for Directive 2014/53/EU: map Article 3 requirements to product features and verification evidence for safety. - [Harmonised Standards and Test Plans | EU RED 2014/53/EU | Presumption of Conformity, OJ References, Verification Strategy](/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans.md): A practical guide to harmonised standards under the EU Radio Equipment Directive (RED) 2014/53/EU: how presumption of conformity works. - [RED Applicability Test | Is My Product in Scope of the EU Radio Equipment Directive (RED) 2014/53/EU?](/artifacts/eu/radio-equipment-directive/applicability-test.md): A structured RED applicability test for Directive 2014/53/EU: determine if your product is radio equipment, whether any exclusions apply. - [RED Compliance Checklist | EU Radio Equipment Directive 2014/53/EU | CE Marking Evidence Pack](/artifacts/eu/radio-equipment-directive/checklist.md): An audit-ready RED compliance checklist for Directive 2014/53/EU: scope and classification, essential requirements mapping (safety/health, EMC, spectrum). - [RED Compliance Program | EU Radio Equipment Directive 2014/53/EU Implementation Playbook](/artifacts/eu/radio-equipment-directive/compliance.md): A practical RED compliance program playbook for Directive 2014/53/EU: set up governance, map essential requirements to standards and tests. - [RED Conformity Assessment Template | CE Technical File Structure for Directive 2014/53/EU](/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template.md): A practical RED conformity assessment template for Directive 2014/53/EU: a CE technical file structure with sections for scope memo. - [RED Cybersecurity Delegated Act Guide | Implement Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025)](/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide.md): Step-by-step implementation guide for the RED cybersecurity delegated act. - [RED Cybersecurity Requirements | Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025) | Article 3(3)(d)(e)(f)](/artifacts/eu/radio-equipment-directive/cybersecurity-requirements.md): A practical RED cybersecurity requirements guide: Delegated Regulation (EU) 2022/30 activates Article 3(3)(d) network protection. - [RED Deadlines and Compliance Calendar | Directive 2014/53/EU Key Dates (2016-2026) | Cybersecurity 2025, Common Charger 2024/2026](/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar.md): A practical RED deadlines and compliance calendar: core RED dates (transposition by 12 Jun 2016; measures apply from 13 Jun 2016. - [RED Penalties and Enforcement | EU Radio Equipment Directive 2014/53/EU | Market Surveillance, CE Documentation Risk](/artifacts/eu/radio-equipment-directive/penalties-and-fines.md): A practical RED enforcement and penalties guide for Directive 2014/53/EU: how market surveillance works in practice. - [RED Timeline | EU Radio Equipment Directive 2014/53/EU Roadmap | Cybersecurity (EU) 2022/30, Common Charger (EU) 2022/2380](/artifacts/eu/radio-equipment-directive/timeline.md): A practical RED timeline and roadmap: the core RED transition dates. - [RED vs Cyber Resilience Act (CRA) | RED Cybersecurity (EU) 2022/30 vs CRA (EU) 2024/2847 | What Overlaps, What's Different](/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act.md): A practical comparison of RED vs CRA: RED (Directive 2014/53/EU) is radio-equipment-specific and. - [Scope and Classification | EU Radio Equipment Directive (RED) 2014/53/EU | What Is Radio Equipment? Exclusions, Borderline Cases](/artifacts/eu/radio-equipment-directive/scope-and-classification.md): A practical RED scope and classification guide for Directive 2014/53/EU: what counts as radio equipment, which Annex I exclusions take products out of scope. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/radio-equipment-directive/faq --- --- title: "Harmonised Standards and Test Plans" canonical_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans" source_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans" author: "Sorena AI" description: "A practical guide to harmonised standards under the EU Radio Equipment Directive (RED) 2014/53/EU: how presumption of conformity works." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RED harmonised standards" - "radio equipment directive harmonised standards" - "presumption of conformity RED" - "OJ references RED" - "Commission Implementing Decision 2022/2191 RED" - "RED test plan" - "RED verification plan" - "RED" - "Harmonised standards" - "Presumption of conformity" - "Test plan" - "CE marking" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Harmonised Standards and Test Plans A practical guide to harmonised standards under the EU Radio Equipment Directive (RED) 2014/53/EU: how presumption of conformity works. *RED* *Standards* ## EU Radio Equipment Directive (RED) Harmonised Standards and Test Plans Use standards to reduce ambiguity and to defend your CE evidence. Output: requirements, standards, tests, and evidence mapping. Harmonised standards are the fastest way to build a defensible RED verification strategy, but only if you treat them as part of a controlled compliance system: you track the Official Journal references, document how you apply them, and keep test evidence retrievable per product variant. ## How presumption of conformity works under RED When you apply harmonised standards whose references are published in the Official Journal (OJ), you can rely on a presumption of conformity for the requirements covered by those standards. Presumption of conformity is not a free pass: you still need correct scope mapping, correct application, and test evidence. - Use OJ-listed references, not only an internal claim that you follow ETSI or Cenelec material - Document which clauses/parts you apply and why - Keep evidence: test reports, configurations, and variant coverage ## Where to find the current list of harmonised standards The list changes over time (new standards added, references withdrawn, transitional periods). Use the official EU Single Market harmonised standards page and the Commission Implementing Decisions for authoritative references. - Use the official harmonised standards page for radio equipment and track updates - Reference the latest Commission Implementing Decision(s) that publish OJ references - Treat updates as release-impacting events (retesting may be needed) ## Current OJ update sequence you should track The main RED standards list sits in Decision (EU) 2022/2191, but the live compliance picture now depends on later amendments. Use the decision chain, not a stale spreadsheet, when you decide which version gives presumption of conformity today. - Decision (EU) 2023/2392 updates several radio-spectrum standards and applies a deferred withdrawal from 4 Apr 2025 - Decision (EU) 2023/2669 updates EN 50360 and EN 50566 for devices used next to the ear or close to the body, with deferred withdrawal from 1 Jun 2025 - Decision (EU) 2025/138 adds EN 18031-1, EN 18031-2, and EN 18031-3 for RED cybersecurity, but with restrictions you must read carefully - Decision (EU) 2025/893 adds and revises more radio-spectrum standards and includes deferred dates of 15 Nov 2026 and 15 May 2028 ## Build a requirements-to-standards matrix (the core compliance artifact) A matrix prevents two common failures: missing requirements and duplicate testing. Use one row per essential requirement and one column per evidence type (standard, test, document). - Article 3 mapping: safety/health, EMC, spectrum efficiency, and any activated additional requirements - Standards mapping: which standard(s) provide coverage and what product variants they apply to - Verification: test cases, lab setup, acceptance criteria, and firmware/configuration baseline - Evidence location: technical file sections + test report references ## Cybersecurity testing (when (EU) 2022/30 applies) Cybersecurity under RED should be verified like other essential requirements: defined scope, defined methods, and retained evidence. Avoid one-off penetration tests with no repeatability. Treat cybersecurity verification as a program tied to release cycles, and check the EN 18031 restrictions before claiming presumption of conformity. - Classify applicability: internet-connected, data-processing, value-transfer equipment categories - Define a cybersecurity verification plan: authentication, update mechanism, communications security, misuse scenarios - Keep repeatability: tool versions, configurations, and pass/fail criteria - Store evidence as a module in the technical documentation - For EN 18031-1, EN 18031-2, and EN 18031-3, read the restrictions in Decision (EU) 2025/138 before you rely on presumption of conformity ## When a notified body becomes relevant If you cannot fully rely on harmonised standards coverage (or your product deviates materially), you may need additional assessment routes. Plan this early - notified body lead times can affect your release schedule. - Decide early: do harmonised standards cover your essential requirements and your intended use? - If not, plan for EU-type examination or full quality assurance routes where applicable - Maintain an evidence pack that a notified body can review without rework *Recommended next step* *Placement: near the end of the main content before related guides* ## Turn EU Radio Equipment Directive (RED) Harmonised Standards and Test Plans into an operational assessment Assessment Autopilot can take EU Radio Equipment Directive (RED) Harmonised Standards and Test Plans from turning this guidance into an operational assessment workflow to a reusable workflow inside Sorena. Teams working on EU Radio Equipment Directive (RED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Radio Equipment Directive (RED) Harmonised Standards and Test Plans](/solutions/assessment.md): Start from EU Radio Equipment Directive (RED) Harmonised Standards and Test Plans and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Radio Equipment Directive (RED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Radio Equipment Directive (RED) Harmonised Standards and Test Plans. ## Primary sources - [EU Single Market - Harmonised standards for radio equipment](https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards/radio-equipment_en?ref=sorena.io) - Official consolidated list and references of harmonised standards supporting RED. - [Commission Implementing Decision (EU) 2022/2191 (harmonised standards for radio equipment) (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2022/2191/oj?ref=sorena.io) - OJ references of harmonised standards for RED (updated via later decisions). - [Commission Implementing Decision (EU) 2023/2392 (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2023/2392/oj?ref=sorena.io) - Updates the OJ list and applies deferred withdrawals from 4 Apr 2025. - [Commission Implementing Decision (EU) 2023/2669 (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2023/2669/oj?ref=sorena.io) - Updates EN 50360 and EN 50566 for devices used next to the ear or close to the body, with deferred withdrawal from 1 Jun 2025. - [Commission Implementing Decision (EU) 2025/138 (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2025/138/oj?ref=sorena.io) - Adds EN 18031-1, EN 18031-2, and EN 18031-3 for RED cybersecurity with restrictions. - [Commission Implementing Decision (EU) 2025/893 (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2025/893/oj?ref=sorena.io) - Adds and revises more RED standards and includes deferred dates of 15 Nov 2026 and 15 May 2028. ## Related Topic Guides - [Conformity Assessment and CE Marking | EU RED 2014/53/EU | Technical Documentation, EU DoC, Notified Bodies](/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce.md): A practical guide to RED conformity assessment and CE marking under Directive 2014/53/EU. - [Essential Requirements | EU Radio Equipment Directive (RED) 2014/53/EU | Safety, EMC, Spectrum, Cybersecurity (EU) 2022/30](/artifacts/eu/radio-equipment-directive/requirements.md): A practical RED essential requirements guide for Directive 2014/53/EU: map Article 3 requirements to product features and verification evidence for safety. - [RED Applicability Test | Is My Product in Scope of the EU Radio Equipment Directive (RED) 2014/53/EU?](/artifacts/eu/radio-equipment-directive/applicability-test.md): A structured RED applicability test for Directive 2014/53/EU: determine if your product is radio equipment, whether any exclusions apply. - [RED Compliance Checklist | EU Radio Equipment Directive 2014/53/EU | CE Marking Evidence Pack](/artifacts/eu/radio-equipment-directive/checklist.md): An audit-ready RED compliance checklist for Directive 2014/53/EU: scope and classification, essential requirements mapping (safety/health, EMC, spectrum). - [RED Compliance Program | EU Radio Equipment Directive 2014/53/EU Implementation Playbook](/artifacts/eu/radio-equipment-directive/compliance.md): A practical RED compliance program playbook for Directive 2014/53/EU: set up governance, map essential requirements to standards and tests. - [RED Conformity Assessment Template | CE Technical File Structure for Directive 2014/53/EU](/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template.md): A practical RED conformity assessment template for Directive 2014/53/EU: a CE technical file structure with sections for scope memo. - [RED Cybersecurity Delegated Act Guide | Implement Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025)](/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide.md): Step-by-step implementation guide for the RED cybersecurity delegated act. - [RED Cybersecurity Requirements | Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025) | Article 3(3)(d)(e)(f)](/artifacts/eu/radio-equipment-directive/cybersecurity-requirements.md): A practical RED cybersecurity requirements guide: Delegated Regulation (EU) 2022/30 activates Article 3(3)(d) network protection. - [RED Deadlines and Compliance Calendar | Directive 2014/53/EU Key Dates (2016-2026) | Cybersecurity 2025, Common Charger 2024/2026](/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar.md): A practical RED deadlines and compliance calendar: core RED dates (transposition by 12 Jun 2016; measures apply from 13 Jun 2016. - [RED FAQ | EU Radio Equipment Directive 2014/53/EU Questions | Scope, CE Marking, Cybersecurity (EU) 2022/30, Standards](/artifacts/eu/radio-equipment-directive/faq.md): A practical RED FAQ for Directive 2014/53/EU: what is radio equipment, what is in scope, what happened in the 2016/2017 transition. - [RED Penalties and Enforcement | EU Radio Equipment Directive 2014/53/EU | Market Surveillance, CE Documentation Risk](/artifacts/eu/radio-equipment-directive/penalties-and-fines.md): A practical RED enforcement and penalties guide for Directive 2014/53/EU: how market surveillance works in practice. - [RED Timeline | EU Radio Equipment Directive 2014/53/EU Roadmap | Cybersecurity (EU) 2022/30, Common Charger (EU) 2022/2380](/artifacts/eu/radio-equipment-directive/timeline.md): A practical RED timeline and roadmap: the core RED transition dates. - [RED vs Cyber Resilience Act (CRA) | RED Cybersecurity (EU) 2022/30 vs CRA (EU) 2024/2847 | What Overlaps, What's Different](/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act.md): A practical comparison of RED vs CRA: RED (Directive 2014/53/EU) is radio-equipment-specific and. - [Scope and Classification | EU Radio Equipment Directive (RED) 2014/53/EU | What Is Radio Equipment? Exclusions, Borderline Cases](/artifacts/eu/radio-equipment-directive/scope-and-classification.md): A practical RED scope and classification guide for Directive 2014/53/EU: what counts as radio equipment, which Annex I exclusions take products out of scope. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans --- --- title: "RED Penalties and Enforcement" canonical_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/penalties-and-fines" author: "Sorena AI" description: "A practical RED enforcement and penalties guide for Directive 2014/53/EU: how market surveillance works in practice." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RED penalties" - "Radio Equipment Directive enforcement" - "market surveillance RED" - "CE marking enforcement radio equipment" - "technical documentation enforcement RED" - "EU declaration of conformity enforcement" - "RED" - "Penalties" - "Market surveillance" - "CE marking" - "Technical documentation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RED Penalties and Enforcement A practical RED enforcement and penalties guide for Directive 2014/53/EU: how market surveillance works in practice. *RED* *Enforcement* ## EU Radio Equipment Directive (RED) Penalties and Fines Most RED enforcement pain is missing evidence, not missing intent. Build an authority-response-ready CE evidence pack. Penalties and enforcement are set nationally, but enforcement triggers are predictable: missing CE evidence, inconsistent declarations, and claims that aren't backed by test results. Use this page to design a compliance system that reduces enforcement exposure and shortens response time when authorities ask questions. ## How RED enforcement typically happens Market surveillance authorities can request documentation, inspect products, and take measures if non-compliance is suspected. The most common failure mode is inability to produce the technical file and test evidence that matches the shipped product and variants. - Authority request: produce technical documentation and EU DoC - Product checks: markings, user information, and market access restrictions info - Follow-up: requests for additional tests or corrective actions *Recommended next step* *Placement: after the enforcement section* ## Use EU Radio Equipment Directive (RED) Penalties and Fines as a cited research workflow Research Copilot can take EU Radio Equipment Directive (RED) Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Radio Equipment Directive (RED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Radio Equipment Directive (RED) Penalties and Fines](/solutions/research-copilot.md): Start from EU Radio Equipment Directive (RED) Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Radio Equipment Directive (RED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Radio Equipment Directive (RED) Penalties and Fines. ## Common enforcement triggers (what to control) Treat these as your compliance risk register. They're the issues that get found fastest. If you control these, you usually control the rest. - CE marking or labeling errors - EU DoC mismatches (wrong models, wrong acts, wrong standards references) - Missing or incomplete technical documentation - Test evidence gaps (especially for spectrum/EMC and variant coverage) - Cybersecurity claims without a verifiable evidence module when (EU) 2022/30 applies ## How to reduce exposure (the evidence-first strategy) Penalty exposure drops when you can show: a controlled system, owner accountability, and retrievable evidence. Make evidence creation part of release processes rather than a one-time scramble. - Evidence vault per product family and variant appendices - Requirements-to-standards matrix + verification plan + test reports - DoC version control tied to releases - Supplier/module evidence and change-notification process - Authority-response playbook and periodic drills ## If you receive an authority request (response playbook) Speed and consistency matter. Assign a single owner for responses and a fixed export structure. Answer with evidence and traceability, not narratives. - Identify the exact model/SKU and shipped configuration - Export the technical file module set (scope memo, standards matrix, test reports, DoC, labeling/user info) - Explain changes since last release and why they do not break conformity - Log lessons learned and improve your release gates ## Primary sources - [EU Single Market - Radio Equipment Directive overview](https://single-market-economy.ec.europa.eu/sectors/electrical-and-electronic-engineering-industries-eei/radio-equipment-directive-red_en?ref=sorena.io) - Official overview and links to guidance. - [European Commission - Guide to the Radio Equipment Directive (RED Guide, 2018)](https://ec.europa.eu/growth/sectors/electrical-engineering/rtte-directive/?ref=sorena.io) - Includes market surveillance and enforcement guidance and practical examples. - [Directive 2014/53/EU (Radio Equipment Directive) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/53/oj?ref=sorena.io) - Legal basis for conformity and documentation obligations. ## Related Topic Guides - [Conformity Assessment and CE Marking | EU RED 2014/53/EU | Technical Documentation, EU DoC, Notified Bodies](/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce.md): A practical guide to RED conformity assessment and CE marking under Directive 2014/53/EU. - [Essential Requirements | EU Radio Equipment Directive (RED) 2014/53/EU | Safety, EMC, Spectrum, Cybersecurity (EU) 2022/30](/artifacts/eu/radio-equipment-directive/requirements.md): A practical RED essential requirements guide for Directive 2014/53/EU: map Article 3 requirements to product features and verification evidence for safety. - [Harmonised Standards and Test Plans | EU RED 2014/53/EU | Presumption of Conformity, OJ References, Verification Strategy](/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans.md): A practical guide to harmonised standards under the EU Radio Equipment Directive (RED) 2014/53/EU: how presumption of conformity works. - [RED Applicability Test | Is My Product in Scope of the EU Radio Equipment Directive (RED) 2014/53/EU?](/artifacts/eu/radio-equipment-directive/applicability-test.md): A structured RED applicability test for Directive 2014/53/EU: determine if your product is radio equipment, whether any exclusions apply. - [RED Compliance Checklist | EU Radio Equipment Directive 2014/53/EU | CE Marking Evidence Pack](/artifacts/eu/radio-equipment-directive/checklist.md): An audit-ready RED compliance checklist for Directive 2014/53/EU: scope and classification, essential requirements mapping (safety/health, EMC, spectrum). - [RED Compliance Program | EU Radio Equipment Directive 2014/53/EU Implementation Playbook](/artifacts/eu/radio-equipment-directive/compliance.md): A practical RED compliance program playbook for Directive 2014/53/EU: set up governance, map essential requirements to standards and tests. - [RED Conformity Assessment Template | CE Technical File Structure for Directive 2014/53/EU](/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template.md): A practical RED conformity assessment template for Directive 2014/53/EU: a CE technical file structure with sections for scope memo. - [RED Cybersecurity Delegated Act Guide | Implement Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025)](/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide.md): Step-by-step implementation guide for the RED cybersecurity delegated act. - [RED Cybersecurity Requirements | Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025) | Article 3(3)(d)(e)(f)](/artifacts/eu/radio-equipment-directive/cybersecurity-requirements.md): A practical RED cybersecurity requirements guide: Delegated Regulation (EU) 2022/30 activates Article 3(3)(d) network protection. - [RED Deadlines and Compliance Calendar | Directive 2014/53/EU Key Dates (2016-2026) | Cybersecurity 2025, Common Charger 2024/2026](/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar.md): A practical RED deadlines and compliance calendar: core RED dates (transposition by 12 Jun 2016; measures apply from 13 Jun 2016. - [RED FAQ | EU Radio Equipment Directive 2014/53/EU Questions | Scope, CE Marking, Cybersecurity (EU) 2022/30, Standards](/artifacts/eu/radio-equipment-directive/faq.md): A practical RED FAQ for Directive 2014/53/EU: what is radio equipment, what is in scope, what happened in the 2016/2017 transition. - [RED Timeline | EU Radio Equipment Directive 2014/53/EU Roadmap | Cybersecurity (EU) 2022/30, Common Charger (EU) 2022/2380](/artifacts/eu/radio-equipment-directive/timeline.md): A practical RED timeline and roadmap: the core RED transition dates. - [RED vs Cyber Resilience Act (CRA) | RED Cybersecurity (EU) 2022/30 vs CRA (EU) 2024/2847 | What Overlaps, What's Different](/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act.md): A practical comparison of RED vs CRA: RED (Directive 2014/53/EU) is radio-equipment-specific and. - [Scope and Classification | EU Radio Equipment Directive (RED) 2014/53/EU | What Is Radio Equipment? Exclusions, Borderline Cases](/artifacts/eu/radio-equipment-directive/scope-and-classification.md): A practical RED scope and classification guide for Directive 2014/53/EU: what counts as radio equipment, which Annex I exclusions take products out of scope. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/radio-equipment-directive/penalties-and-fines --- --- title: "RED Conformity Assessment Template" canonical_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template" source_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template" author: "Sorena AI" description: "A practical RED conformity assessment template for Directive 2014/53/EU: a CE technical file structure with sections for scope memo." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RED technical documentation template" - "RED conformity assessment template" - "CE marking technical file RED" - "EU declaration of conformity template RED" - "Directive 2014/53/EU technical file" - "RED" - "Template" - "Technical documentation" - "EU declaration of conformity" - "CE marking" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RED Conformity Assessment Template A practical RED conformity assessment template for Directive 2014/53/EU: a CE technical file structure with sections for scope memo. *Template* *RED* ## EU Radio Equipment Directive (RED) Conformity Assessment Template A CE technical file structure you can reuse across products. Output: an evidence pack layout that supports audits and market surveillance requests. Use this template to structure your RED technical documentation so it is traceable, retrievable, and consistent across product variants. The template is intentionally evidence-first: every requirement is mapped to a verification method and a stored artifact. ## How to use this template Create one technical file per product family, then add variant appendices (radio configuration, firmware differences, band/region differences). Treat it like a controlled document: version it, review it on every release, and keep it consistent with what is shipped. - Single source of truth: scope memo + requirements mapping + standards list + test evidence - Release gating: no shipment until the file is updated for the shipped configuration - Evidence retrieval: organise so you can export a complete pack quickly *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Radio Equipment Directive (RED) Conformity Assessment Template in one governed evidence system SSOT can take EU Radio Equipment Directive (RED) Conformity Assessment Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Radio Equipment Directive (RED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Radio Equipment Directive (RED) Conformity Assessment Template](/solutions/ssot.md): Start from EU Radio Equipment Directive (RED) Conformity Assessment Template and keep documents, evidence, and control records in one governed system. - [Talk through EU Radio Equipment Directive (RED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Radio Equipment Directive (RED) Conformity Assessment Template. ## Template sections (recommended structure) Use the following sections as folders or chapters in your technical documentation. If a section doesn't apply, include a short not applicable note with rationale. - 1. Product identification: model/SKU, variants, firmware versions, intended use, installation conditions - 2. Scope memo: why it is radio equipment + exclusions analysis (if any) - 3. Essential requirements map: Article 3 requirements -> acceptance criteria - 4. Standards matrix: harmonised standards used (OJ references) and clause coverage - 5. Verification plan: test plan, lab setup, configurations, acceptance criteria - 6. Test reports: EMC, spectrum, safety; include variant coverage and deviations - 7. Cybersecurity module (if (EU) 2022/30 applies): applicability, controls, tests, results, lifecycle processes - 8. Labeling and user information: markings, restrictions info (where applicable), manuals and safety info - 9. EU Declaration of Conformity (DoC): controlled DoC + referenced acts and standards - 10. Change history: what changed between releases and impact analysis ## Cybersecurity module (drop-in section for (EU) 2022/30) If the delegated cybersecurity regulation applies to your product, keep cybersecurity evidence in a dedicated section with clear traceability. Make it repeatable: store the test plan and how it is run on each release. - Applicability classification: which category triggers apply - Threat model and trust boundaries - Controls and design decisions (secure update, auth, comms, data protection) - Verification: tests, tools, results, and release gates - Vulnerability handling and update policy as lifecycle evidence ## Common mistakes (avoid them) Most technical files fail due to missing traceability or mismatched versions. Fix the process, not the PDF. - DoC references don't match the standards/test reports used - Firmware/configuration shipped differs from what was tested - Variant coverage is unclear (which SKUs are covered by which tests) - Cybersecurity evidence is a generic policy without verification artifacts ## Primary sources - [Directive 2014/53/EU (Radio Equipment Directive) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/53/oj?ref=sorena.io) - Legal basis for technical documentation, conformity assessment and EU declaration of conformity expectations. - [European Commission - Guide to the Radio Equipment Directive (RED Guide, 2018)](https://ec.europa.eu/growth/sectors/electrical-engineering/rtte-directive/?ref=sorena.io) - Practical guidance on technical file content, notified bodies, and CE workflows. - [Delegated Regulation (EU) 2022/30 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2022/30/oj?ref=sorena.io) - Cybersecurity activation scope. Use Regulation (EU) 2023/2444 for the current 1 Aug 2025 application date. - [Delegated Regulation (EU) 2023/2444 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2023/2444/oj?ref=sorena.io) - Moves the cybersecurity application date to 1 Aug 2025. ## Related Topic Guides - [Conformity Assessment and CE Marking | EU RED 2014/53/EU | Technical Documentation, EU DoC, Notified Bodies](/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce.md): A practical guide to RED conformity assessment and CE marking under Directive 2014/53/EU. - [Essential Requirements | EU Radio Equipment Directive (RED) 2014/53/EU | Safety, EMC, Spectrum, Cybersecurity (EU) 2022/30](/artifacts/eu/radio-equipment-directive/requirements.md): A practical RED essential requirements guide for Directive 2014/53/EU: map Article 3 requirements to product features and verification evidence for safety. - [Harmonised Standards and Test Plans | EU RED 2014/53/EU | Presumption of Conformity, OJ References, Verification Strategy](/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans.md): A practical guide to harmonised standards under the EU Radio Equipment Directive (RED) 2014/53/EU: how presumption of conformity works. - [RED Applicability Test | Is My Product in Scope of the EU Radio Equipment Directive (RED) 2014/53/EU?](/artifacts/eu/radio-equipment-directive/applicability-test.md): A structured RED applicability test for Directive 2014/53/EU: determine if your product is radio equipment, whether any exclusions apply. - [RED Compliance Checklist | EU Radio Equipment Directive 2014/53/EU | CE Marking Evidence Pack](/artifacts/eu/radio-equipment-directive/checklist.md): An audit-ready RED compliance checklist for Directive 2014/53/EU: scope and classification, essential requirements mapping (safety/health, EMC, spectrum). - [RED Compliance Program | EU Radio Equipment Directive 2014/53/EU Implementation Playbook](/artifacts/eu/radio-equipment-directive/compliance.md): A practical RED compliance program playbook for Directive 2014/53/EU: set up governance, map essential requirements to standards and tests. - [RED Cybersecurity Delegated Act Guide | Implement Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025)](/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide.md): Step-by-step implementation guide for the RED cybersecurity delegated act. - [RED Cybersecurity Requirements | Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025) | Article 3(3)(d)(e)(f)](/artifacts/eu/radio-equipment-directive/cybersecurity-requirements.md): A practical RED cybersecurity requirements guide: Delegated Regulation (EU) 2022/30 activates Article 3(3)(d) network protection. - [RED Deadlines and Compliance Calendar | Directive 2014/53/EU Key Dates (2016-2026) | Cybersecurity 2025, Common Charger 2024/2026](/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar.md): A practical RED deadlines and compliance calendar: core RED dates (transposition by 12 Jun 2016; measures apply from 13 Jun 2016. - [RED FAQ | EU Radio Equipment Directive 2014/53/EU Questions | Scope, CE Marking, Cybersecurity (EU) 2022/30, Standards](/artifacts/eu/radio-equipment-directive/faq.md): A practical RED FAQ for Directive 2014/53/EU: what is radio equipment, what is in scope, what happened in the 2016/2017 transition. - [RED Penalties and Enforcement | EU Radio Equipment Directive 2014/53/EU | Market Surveillance, CE Documentation Risk](/artifacts/eu/radio-equipment-directive/penalties-and-fines.md): A practical RED enforcement and penalties guide for Directive 2014/53/EU: how market surveillance works in practice. - [RED Timeline | EU Radio Equipment Directive 2014/53/EU Roadmap | Cybersecurity (EU) 2022/30, Common Charger (EU) 2022/2380](/artifacts/eu/radio-equipment-directive/timeline.md): A practical RED timeline and roadmap: the core RED transition dates. - [RED vs Cyber Resilience Act (CRA) | RED Cybersecurity (EU) 2022/30 vs CRA (EU) 2024/2847 | What Overlaps, What's Different](/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act.md): A practical comparison of RED vs CRA: RED (Directive 2014/53/EU) is radio-equipment-specific and. - [Scope and Classification | EU Radio Equipment Directive (RED) 2014/53/EU | What Is Radio Equipment? Exclusions, Borderline Cases](/artifacts/eu/radio-equipment-directive/scope-and-classification.md): A practical RED scope and classification guide for Directive 2014/53/EU: what counts as radio equipment, which Annex I exclusions take products out of scope. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template --- --- title: "RED Cybersecurity Delegated Act Guide" canonical_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide" source_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide" author: "Sorena AI" description: "Step-by-step implementation guide for the RED cybersecurity delegated act." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RED cybersecurity delegated act" - "EU 2022/30 implementation" - "Article 3(3)(d)(e)(f) RED" - "radio equipment cybersecurity CE marking" - "RED cybersecurity test plan" - "internet-connected radio equipment cybersecurity" - "RED" - "Cybersecurity" - "Delegated Regulation (EU) 2022/30" - "CE marking" - "Technical documentation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RED Cybersecurity Delegated Act Guide Step-by-step implementation guide for the RED cybersecurity delegated act. *EU 2022/30* *Implementation* ## EU Radio Equipment Directive (RED) Cybersecurity Delegated Act Guide Implement (EU) 2022/30 in a way you can prove. Output: a control set + tests + technical file module for CE marking. The delegated act is not a checklist you 'sign off'. It is a set of essential requirements that must be demonstrably met for in-scope equipment. This guide gives you a repeatable implementation pattern you can apply across product lines and firmware releases. ## 1) Applicability classification (the fastest, most important step) Start by classifying each product variant against the delegated regulation categories. Make the decision evidence-based (architecture + connectivity + data flow). Store the decision as a scope memo attached to the technical documentation. - Internet-connected radio equipment (network protection requirement) - Equipment processing personal data / traffic data / location data (privacy/data protection requirement) - Internet-connected equipment enabling value transfer (fraud protection requirement) - Date: applies from 1 Aug 2025 because Regulation (EU) 2023/2444 moved the start date - Check whether the consolidated derogations remove the Article 3(3)(e) or (f) trigger for your product type ## 2) Requirements-to-controls mapping (make it testable) Convert each activated requirement into controls with measurable acceptance criteria. Avoid control statements that can't be verified. Use a mapping matrix: requirement -> control objective -> design control -> verification method -> evidence location. - Network protection: prevent misuse (e.g., botnet patterns), service minimisation, secure comms, resilience - Privacy/data: data minimisation, access control, secure storage/transport, secure defaults - Anti-fraud: strong auth, integrity protections, anti-tampering, transaction safeguards where applicable - Lifecycle: update security, vulnerability intake and remediation timelines, and change control ## 3) Build a verification test plan (don't rely on 'we follow best practices') Verification is what makes the delegated act defensible. Build test cases that reflect misuse scenarios and negative testing. Treat cybersecurity tests like spectrum/EMC tests: documented setup, repeatable methods, and variant coverage. - Security requirements tests: authentication, authorisation, secure update path, secure communications - Abuse and misuse tests: default credentials, exposed services, insecure APIs, weak crypto configurations - Data protection tests: data at rest/in transit, deletion/retention controls, access logs - Release gating: security test results required before CE documentation is updated and shipped ## 4) Package evidence in the technical documentation (CE file-ready) Authorities and notified bodies will look for traceability: requirements -> controls -> tests -> results -> documentation. Your goal is a single cybersecurity module in the technical file that can be reused across variants. - Scope memo per variant + requirement triggers - Architecture, threat model, and security objectives - Test plan and reports (including tools, versions, and environment) - Update and vulnerability management process summary + change log - EU declaration of conformity updates referencing applicable acts and standards ## 5) Run it as a program (ownership and cadence) Cybersecurity compliance breaks when it isn't owned. Assign owners and a cadence aligned to release cycles. If firmware updates are delivered post-market, treat them as compliance-impacting changes. - Owners: product security, engineering, compliance/QA, and supplier management - Cadence: release gates + quarterly evidence reviews + vulnerability response SLAs - Supplier controls: module vendors, chipsets, and cloud services must provide evidence you can cite - Audit drill: simulate a market surveillance request and time your evidence retrieval *Recommended next step* *Placement: near the end of the main content before related guides* ## Use EU Radio Equipment Directive (RED) Cybersecurity Delegated Act Guide as a cited research workflow Research Copilot can take EU Radio Equipment Directive (RED) Cybersecurity Delegated Act Guide from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on EU Radio Equipment Directive (RED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Radio Equipment Directive (RED) Cybersecurity Delegated Act Guide](/solutions/research-copilot.md): Start from EU Radio Equipment Directive (RED) Cybersecurity Delegated Act Guide and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Radio Equipment Directive (RED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Radio Equipment Directive (RED) Cybersecurity Delegated Act Guide. ## Primary sources - [Delegated Regulation (EU) 2022/30 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2022/30/oj?ref=sorena.io) - Primary source for scope categories. Read it with Regulation (EU) 2023/2444 for the current application date and corrected Article 1(2) wording. - [Delegated Regulation (EU) 2023/2444 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2023/2444/oj?ref=sorena.io) - Moves the cybersecurity application date to 1 Aug 2025 and corrects the processing-data wording in Article 1(2). - [Directive 2014/53/EU (Radio Equipment Directive) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/53/oj?ref=sorena.io) - Legal basis for essential requirements and CE conformity framework. - [European Commission - Guide to the Radio Equipment Directive (RED Guide, 2018)](https://ec.europa.eu/growth/sectors/electrical-engineering/rtte-directive/?ref=sorena.io) - Practical compliance and documentation guidance (including standards and notified bodies). ## Related Topic Guides - [Conformity Assessment and CE Marking | EU RED 2014/53/EU | Technical Documentation, EU DoC, Notified Bodies](/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce.md): A practical guide to RED conformity assessment and CE marking under Directive 2014/53/EU. - [Essential Requirements | EU Radio Equipment Directive (RED) 2014/53/EU | Safety, EMC, Spectrum, Cybersecurity (EU) 2022/30](/artifacts/eu/radio-equipment-directive/requirements.md): A practical RED essential requirements guide for Directive 2014/53/EU: map Article 3 requirements to product features and verification evidence for safety. - [Harmonised Standards and Test Plans | EU RED 2014/53/EU | Presumption of Conformity, OJ References, Verification Strategy](/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans.md): A practical guide to harmonised standards under the EU Radio Equipment Directive (RED) 2014/53/EU: how presumption of conformity works. - [RED Applicability Test | Is My Product in Scope of the EU Radio Equipment Directive (RED) 2014/53/EU?](/artifacts/eu/radio-equipment-directive/applicability-test.md): A structured RED applicability test for Directive 2014/53/EU: determine if your product is radio equipment, whether any exclusions apply. - [RED Compliance Checklist | EU Radio Equipment Directive 2014/53/EU | CE Marking Evidence Pack](/artifacts/eu/radio-equipment-directive/checklist.md): An audit-ready RED compliance checklist for Directive 2014/53/EU: scope and classification, essential requirements mapping (safety/health, EMC, spectrum). - [RED Compliance Program | EU Radio Equipment Directive 2014/53/EU Implementation Playbook](/artifacts/eu/radio-equipment-directive/compliance.md): A practical RED compliance program playbook for Directive 2014/53/EU: set up governance, map essential requirements to standards and tests. - [RED Conformity Assessment Template | CE Technical File Structure for Directive 2014/53/EU](/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template.md): A practical RED conformity assessment template for Directive 2014/53/EU: a CE technical file structure with sections for scope memo. - [RED Cybersecurity Requirements | Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025) | Article 3(3)(d)(e)(f)](/artifacts/eu/radio-equipment-directive/cybersecurity-requirements.md): A practical RED cybersecurity requirements guide: Delegated Regulation (EU) 2022/30 activates Article 3(3)(d) network protection. - [RED Deadlines and Compliance Calendar | Directive 2014/53/EU Key Dates (2016-2026) | Cybersecurity 2025, Common Charger 2024/2026](/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar.md): A practical RED deadlines and compliance calendar: core RED dates (transposition by 12 Jun 2016; measures apply from 13 Jun 2016. - [RED FAQ | EU Radio Equipment Directive 2014/53/EU Questions | Scope, CE Marking, Cybersecurity (EU) 2022/30, Standards](/artifacts/eu/radio-equipment-directive/faq.md): A practical RED FAQ for Directive 2014/53/EU: what is radio equipment, what is in scope, what happened in the 2016/2017 transition. - [RED Penalties and Enforcement | EU Radio Equipment Directive 2014/53/EU | Market Surveillance, CE Documentation Risk](/artifacts/eu/radio-equipment-directive/penalties-and-fines.md): A practical RED enforcement and penalties guide for Directive 2014/53/EU: how market surveillance works in practice. - [RED Timeline | EU Radio Equipment Directive 2014/53/EU Roadmap | Cybersecurity (EU) 2022/30, Common Charger (EU) 2022/2380](/artifacts/eu/radio-equipment-directive/timeline.md): A practical RED timeline and roadmap: the core RED transition dates. - [RED vs Cyber Resilience Act (CRA) | RED Cybersecurity (EU) 2022/30 vs CRA (EU) 2024/2847 | What Overlaps, What's Different](/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act.md): A practical comparison of RED vs CRA: RED (Directive 2014/53/EU) is radio-equipment-specific and. - [Scope and Classification | EU Radio Equipment Directive (RED) 2014/53/EU | What Is Radio Equipment? Exclusions, Borderline Cases](/artifacts/eu/radio-equipment-directive/scope-and-classification.md): A practical RED scope and classification guide for Directive 2014/53/EU: what counts as radio equipment, which Annex I exclusions take products out of scope. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide --- --- title: "RED vs Cyber Resilience Act (CRA)" canonical_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act" source_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act" author: "Sorena AI" description: "A practical comparison of RED vs CRA: RED (Directive 2014/53/EU) is radio-equipment-specific and." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RED vs CRA" - "Radio Equipment Directive vs Cyber Resilience Act" - "EU 2022/30 vs EU 2024/2847" - "radio equipment cybersecurity requirements" - "products with digital elements cybersecurity requirements" - "CE marking cybersecurity" - "RED" - "CRA" - "Cybersecurity" - "Compliance" - "CE marking" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RED vs Cyber Resilience Act (CRA) A practical comparison of RED vs CRA: RED (Directive 2014/53/EU) is radio-equipment-specific and. *RED vs CRA* *Cybersecurity* ## EU Radio Equipment Directive (RED) RED vs Cyber Resilience Act One security program, two legal outputs. Use this page to align evidence and avoid duplicated testing and documentation. Teams often ask whether CRA compliance removes the need for RED cybersecurity. The safer answer is that you likely need both, but you should not run two separate security evidence programs. Run one engineering and evidence backbone, then generate RED and CRA compliance outputs from it. ## What each instrument is trying to do RED is radio-equipment-specific and focuses on essential requirements for making radio equipment available on the EU market. CRA is horizontal and sets cybersecurity requirements for products with digital elements across many product categories. - RED: radio equipment market access + CE marking evidence; cybersecurity essential requirements activated for defined equipment via (EU) 2022/30 - CRA: horizontal cybersecurity requirements (secure by design, vulnerability handling, updates, and information obligations) - If your product is both a radio device and a product with digital elements, plan for both compliance outputs ## Where RED cybersecurity overlaps with CRA The overlap is engineering reality: controls and evidence you build for one can usually support the other, if structured correctly. The trick is traceability: map the same control/test evidence to two legal requirement sets without copying and pasting. - Secure configuration and hardening: reducing attack surface - Authentication, access control, and secure communications - Security updates and change control - Vulnerability intake and remediation processes - Security verification and repeatable test evidence ## Where they differ (don't mix these up) The differences are legal scope and what you need to prove. RED cybersecurity activation is tied to radio equipment categories defined by (EU) 2022/30; CRA obligations apply via its own scope and classification logic. - RED output: CE technical file module + EU DoC references for RED and any activated delegated acts - CRA output: CRA-specific documentation and obligations tied to CRA categories and requirements - RED focus areas (EU 2022/30): network protection, privacy/personal data, fraud protection - CRA focus: broader lifecycle and vulnerability-handling obligations across products with digital elements ## A practical architecture: one evidence backbone Build one security evidence vault and index it by product variant and release. Then generate RED cybersecurity module and CRA compliance pack views from the same artifacts. - One threat model per product family + variant deltas - One verification plan with test results per release - One update and vulnerability management process with logs and evidence - Two mappings: evidence -> RED Article 3(3)(d)(e)(f) and evidence -> CRA requirements *Recommended next step* *Placement: after the comparison section* ## Use EU Radio Equipment Directive (RED) RED vs Cyber Resilience Act as a cited research workflow Research Copilot can take EU Radio Equipment Directive (RED) RED vs Cyber Resilience Act from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Radio Equipment Directive (RED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Radio Equipment Directive (RED) RED vs Cyber Resilience Act](/solutions/research-copilot.md): Start from EU Radio Equipment Directive (RED) RED vs Cyber Resilience Act and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Radio Equipment Directive (RED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Radio Equipment Directive (RED) RED vs Cyber Resilience Act. ## Primary sources - [Delegated Regulation (EU) 2022/30 (RED cybersecurity activation) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2022/30/oj?ref=sorena.io) - Activates RED Article 3(3)(d)(e)(f) for defined radio equipment categories. Read it with Regulation (EU) 2023/2444 for the current 1 Aug 2025 date. - [Delegated Regulation (EU) 2023/2444 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2023/2444/oj?ref=sorena.io) - Moves the RED cybersecurity application date to 1 Aug 2025. - [Directive 2014/53/EU (Radio Equipment Directive) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/53/oj?ref=sorena.io) - RED legal basis for essential requirements and CE framework. - [Regulation (EU) 2024/2847 (Cyber Resilience Act) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - CRA legal basis for horizontal cybersecurity requirements for products with digital elements. ## Related Topic Guides - [Conformity Assessment and CE Marking | EU RED 2014/53/EU | Technical Documentation, EU DoC, Notified Bodies](/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce.md): A practical guide to RED conformity assessment and CE marking under Directive 2014/53/EU. - [Essential Requirements | EU Radio Equipment Directive (RED) 2014/53/EU | Safety, EMC, Spectrum, Cybersecurity (EU) 2022/30](/artifacts/eu/radio-equipment-directive/requirements.md): A practical RED essential requirements guide for Directive 2014/53/EU: map Article 3 requirements to product features and verification evidence for safety. - [Harmonised Standards and Test Plans | EU RED 2014/53/EU | Presumption of Conformity, OJ References, Verification Strategy](/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans.md): A practical guide to harmonised standards under the EU Radio Equipment Directive (RED) 2014/53/EU: how presumption of conformity works. - [RED Applicability Test | Is My Product in Scope of the EU Radio Equipment Directive (RED) 2014/53/EU?](/artifacts/eu/radio-equipment-directive/applicability-test.md): A structured RED applicability test for Directive 2014/53/EU: determine if your product is radio equipment, whether any exclusions apply. - [RED Compliance Checklist | EU Radio Equipment Directive 2014/53/EU | CE Marking Evidence Pack](/artifacts/eu/radio-equipment-directive/checklist.md): An audit-ready RED compliance checklist for Directive 2014/53/EU: scope and classification, essential requirements mapping (safety/health, EMC, spectrum). - [RED Compliance Program | EU Radio Equipment Directive 2014/53/EU Implementation Playbook](/artifacts/eu/radio-equipment-directive/compliance.md): A practical RED compliance program playbook for Directive 2014/53/EU: set up governance, map essential requirements to standards and tests. - [RED Conformity Assessment Template | CE Technical File Structure for Directive 2014/53/EU](/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template.md): A practical RED conformity assessment template for Directive 2014/53/EU: a CE technical file structure with sections for scope memo. - [RED Cybersecurity Delegated Act Guide | Implement Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025)](/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide.md): Step-by-step implementation guide for the RED cybersecurity delegated act. - [RED Cybersecurity Requirements | Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025) | Article 3(3)(d)(e)(f)](/artifacts/eu/radio-equipment-directive/cybersecurity-requirements.md): A practical RED cybersecurity requirements guide: Delegated Regulation (EU) 2022/30 activates Article 3(3)(d) network protection. - [RED Deadlines and Compliance Calendar | Directive 2014/53/EU Key Dates (2016-2026) | Cybersecurity 2025, Common Charger 2024/2026](/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar.md): A practical RED deadlines and compliance calendar: core RED dates (transposition by 12 Jun 2016; measures apply from 13 Jun 2016. - [RED FAQ | EU Radio Equipment Directive 2014/53/EU Questions | Scope, CE Marking, Cybersecurity (EU) 2022/30, Standards](/artifacts/eu/radio-equipment-directive/faq.md): A practical RED FAQ for Directive 2014/53/EU: what is radio equipment, what is in scope, what happened in the 2016/2017 transition. - [RED Penalties and Enforcement | EU Radio Equipment Directive 2014/53/EU | Market Surveillance, CE Documentation Risk](/artifacts/eu/radio-equipment-directive/penalties-and-fines.md): A practical RED enforcement and penalties guide for Directive 2014/53/EU: how market surveillance works in practice. - [RED Timeline | EU Radio Equipment Directive 2014/53/EU Roadmap | Cybersecurity (EU) 2022/30, Common Charger (EU) 2022/2380](/artifacts/eu/radio-equipment-directive/timeline.md): A practical RED timeline and roadmap: the core RED transition dates. - [Scope and Classification | EU Radio Equipment Directive (RED) 2014/53/EU | What Is Radio Equipment? Exclusions, Borderline Cases](/artifacts/eu/radio-equipment-directive/scope-and-classification.md): A practical RED scope and classification guide for Directive 2014/53/EU: what counts as radio equipment, which Annex I exclusions take products out of scope. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act --- --- title: "Essential Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/requirements" source_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/requirements" author: "Sorena AI" description: "A practical RED essential requirements guide for Directive 2014/53/EU: map Article 3 requirements to product features and verification evidence for safety." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RED essential requirements" - "Article 3 RED" - "Directive 2014/53/EU requirements" - "EMC requirements radio equipment" - "spectrum efficiency RED" - "safety health RED" - "RED cybersecurity requirements 2022/30" - "RED" - "Essential requirements" - "Article 3" - "CE marking" - "Cybersecurity" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Essential Requirements A practical RED essential requirements guide for Directive 2014/53/EU: map Article 3 requirements to product features and verification evidence for safety. *Article 3* *Requirements* ## EU Radio Equipment Directive (RED) Essential Requirements Map requirements to features, then features to tests and evidence. Output: a requirements-to-standards matrix and an evidence pack for CE marking. RED is outcome-based: you must be able to demonstrate that your radio equipment meets the essential requirements. The fastest implementation path is to translate each requirement into acceptance criteria, then implement verification via harmonised standards (where available) and documented testing and technical documentation. ## The core RED essential requirements (always start here) Most products live or die on the core set: safety/health, EMC, and spectrum efficiency. Treat these as a requirements baseline and build a verification plan that matches intended use and installation conditions. - Safety and health: protect users and others (including safety objectives aligned to the applicable baseline directives) - Electromagnetic compatibility (EMC): radio equipment must not cause excessive disturbance and must have adequate immunity - Efficient use of radio spectrum: avoid harmful interference; include receiver performance expectations where relevant *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU Radio Equipment Directive (RED) Essential Requirements into an operational assessment Assessment Autopilot can take EU Radio Equipment Directive (RED) Essential Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Radio Equipment Directive (RED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Radio Equipment Directive (RED) Essential Requirements](/solutions/assessment.md): Start from EU Radio Equipment Directive (RED) Essential Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Radio Equipment Directive (RED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Radio Equipment Directive (RED) Essential Requirements. ## Additional essential requirements (feature- and act-driven) RED also contains additional essential requirements that may apply depending on the equipment category, functionality, and whether the requirement has been activated for your category via delegated measures. Implementation rule: never treat these as generic statements - map to concrete product features and a verification approach. - Interworking and access: interoperability and (where applicable) access to emergency services - Additional: interworking, access to emergency services, privacy and data protection, fraud protection, and software-combination requirements, but only where the Commission has activated them for the product category - Fraud: protections where the equipment enables value transfers - Software and updates: treat change control as part of compliance (updates can change radio performance and security posture) ## Cybersecurity under RED (Delegated Regulation (EU) 2022/30) Delegated Regulation (EU) 2022/30 activates the essential requirements in Article 3(3)(d), (e) and (f) for defined categories of radio equipment from 1 Aug 2025, because Regulation (EU) 2023/2444 postponed the start date. Treat this as a testable control set and note the category carve-outs. The consolidated text excludes the Article 3(3)(e) and (f) triggers where the same product also falls under certain transport and vehicle legislation. - Network protection (3(3)(d)): prevent harm to networks and misuse of network resources - Privacy/personal data (3(3)(e)): protect personal data and privacy of user/subscriber (for equipment processing such data) - Fraud protection (3(3)(f)): reduce the risk of fraud for equipment enabling money/monetary value/virtual currency transfers - Date: applies from 1 Aug 2025, but voluntary early compliance is allowed - Check the consolidated derogations for products already covered by Regulations (EU) 2018/1139 and (EU) 2019/2144 or Directive (EU) 2019/520 ## How to prove compliance (the evidence pattern) RED compliance is proven through a combination of standards-based verification, test results, and technical documentation and declarations. If you can't show traceability from requirement -> standard/test -> result -> technical file, you're not done. - Requirements-to-standards matrix: each Article 3 requirement mapped to standards and/or test methods - Test plan: test cases, lab setup, acceptance criteria, and coverage of variants - Technical documentation: architecture, schematics, BOM, risk analysis, test reports, and change history - EU declaration of conformity (DoC): controlled document referencing the legal acts and standards used ## Primary sources - [Directive 2014/53/EU (Radio Equipment Directive) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/53/oj?ref=sorena.io) - Primary source for Article 3 essential requirements and overall compliance framework. - [Delegated Regulation (EU) 2022/30 (cybersecurity essential requirements) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2022/30/oj?ref=sorena.io) - Activates Article 3(3)(d), (e), (f) for defined equipment categories. Read it together with the amending Regulation (EU) 2023/2444 for the current application date. - [Delegated Regulation (EU) 2023/2444 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2023/2444/oj?ref=sorena.io) - Moves the cybersecurity application date to 1 Aug 2025 and corrects the wording of Article 1(2). - [European Commission - Guide to the Radio Equipment Directive (RED Guide, 2018)](https://ec.europa.eu/growth/sectors/electrical-engineering/rtte-directive/?ref=sorena.io) - Practical guidance on requirements, standards, notified bodies, and documentation. - [EU Single Market - Radio Equipment Directive overview](https://single-market-economy.ec.europa.eu/sectors/electrical-and-electronic-engineering-industries-eei/radio-equipment-directive-red_en?ref=sorena.io) - Official overview and related resources. ## Related Topic Guides - [Conformity Assessment and CE Marking | EU RED 2014/53/EU | Technical Documentation, EU DoC, Notified Bodies](/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce.md): A practical guide to RED conformity assessment and CE marking under Directive 2014/53/EU. - [Harmonised Standards and Test Plans | EU RED 2014/53/EU | Presumption of Conformity, OJ References, Verification Strategy](/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans.md): A practical guide to harmonised standards under the EU Radio Equipment Directive (RED) 2014/53/EU: how presumption of conformity works. - [RED Applicability Test | Is My Product in Scope of the EU Radio Equipment Directive (RED) 2014/53/EU?](/artifacts/eu/radio-equipment-directive/applicability-test.md): A structured RED applicability test for Directive 2014/53/EU: determine if your product is radio equipment, whether any exclusions apply. - [RED Compliance Checklist | EU Radio Equipment Directive 2014/53/EU | CE Marking Evidence Pack](/artifacts/eu/radio-equipment-directive/checklist.md): An audit-ready RED compliance checklist for Directive 2014/53/EU: scope and classification, essential requirements mapping (safety/health, EMC, spectrum). - [RED Compliance Program | EU Radio Equipment Directive 2014/53/EU Implementation Playbook](/artifacts/eu/radio-equipment-directive/compliance.md): A practical RED compliance program playbook for Directive 2014/53/EU: set up governance, map essential requirements to standards and tests. - [RED Conformity Assessment Template | CE Technical File Structure for Directive 2014/53/EU](/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template.md): A practical RED conformity assessment template for Directive 2014/53/EU: a CE technical file structure with sections for scope memo. - [RED Cybersecurity Delegated Act Guide | Implement Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025)](/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide.md): Step-by-step implementation guide for the RED cybersecurity delegated act. - [RED Cybersecurity Requirements | Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025) | Article 3(3)(d)(e)(f)](/artifacts/eu/radio-equipment-directive/cybersecurity-requirements.md): A practical RED cybersecurity requirements guide: Delegated Regulation (EU) 2022/30 activates Article 3(3)(d) network protection. - [RED Deadlines and Compliance Calendar | Directive 2014/53/EU Key Dates (2016-2026) | Cybersecurity 2025, Common Charger 2024/2026](/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar.md): A practical RED deadlines and compliance calendar: core RED dates (transposition by 12 Jun 2016; measures apply from 13 Jun 2016. - [RED FAQ | EU Radio Equipment Directive 2014/53/EU Questions | Scope, CE Marking, Cybersecurity (EU) 2022/30, Standards](/artifacts/eu/radio-equipment-directive/faq.md): A practical RED FAQ for Directive 2014/53/EU: what is radio equipment, what is in scope, what happened in the 2016/2017 transition. - [RED Penalties and Enforcement | EU Radio Equipment Directive 2014/53/EU | Market Surveillance, CE Documentation Risk](/artifacts/eu/radio-equipment-directive/penalties-and-fines.md): A practical RED enforcement and penalties guide for Directive 2014/53/EU: how market surveillance works in practice. - [RED Timeline | EU Radio Equipment Directive 2014/53/EU Roadmap | Cybersecurity (EU) 2022/30, Common Charger (EU) 2022/2380](/artifacts/eu/radio-equipment-directive/timeline.md): A practical RED timeline and roadmap: the core RED transition dates. - [RED vs Cyber Resilience Act (CRA) | RED Cybersecurity (EU) 2022/30 vs CRA (EU) 2024/2847 | What Overlaps, What's Different](/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act.md): A practical comparison of RED vs CRA: RED (Directive 2014/53/EU) is radio-equipment-specific and. - [Scope and Classification | EU Radio Equipment Directive (RED) 2014/53/EU | What Is Radio Equipment? Exclusions, Borderline Cases](/artifacts/eu/radio-equipment-directive/scope-and-classification.md): A practical RED scope and classification guide for Directive 2014/53/EU: what counts as radio equipment, which Annex I exclusions take products out of scope. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/radio-equipment-directive/requirements --- --- title: "Scope and Classification" canonical_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/scope-and-classification" source_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/scope-and-classification" author: "Sorena AI" description: "A practical RED scope and classification guide for Directive 2014/53/EU: what counts as radio equipment, which Annex I exclusions take products out of scope." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Radio Equipment Directive scope" - "RED scope" - "what is radio equipment" - "Directive 2014/53/EU radio equipment definition" - "RED exclusions" - "RED borderline cases" - "WiFi Bluetooth RED" - "GPS RED" - "TV receiver RED" - "RED" - "Scope" - "Radio equipment definition" - "Classification" - "Directive 2014/53/EU" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Scope and Classification A practical RED scope and classification guide for Directive 2014/53/EU: what counts as radio equipment, which Annex I exclusions take products out of scope. *RED* *Scope* ## EU Radio Equipment Directive (RED) Scope and Classification Decide scope once, document it, and stop re-litigating it every release. Output: a scope memo + product classification record you can attach to your technical file. RED compliance starts with a clean scope decision. The fastest way to lose time is to argue about scope after test planning begins. Use this page to classify your product as radio equipment (or not), document exclusions and borderline cases, and create a traceable scope record that survives audits and market surveillance questions. ## What counts as radio equipment under RED In practical terms, radio equipment is equipment that intentionally transmits and/or receives radio waves for radiocommunication or radiodetermination. If the radio is a module inside a larger product, the final product can still be in scope. The decision turns on the radio function and on how the finished product is made available on the market. - Transmitters: intentional emission for communication such as Wi-Fi, cellular, Bluetooth, LPWAN, and similar functions - Receivers: intentional reception can still drive scope (e.g., broadcast receivers) depending on the equipment type - Radiodetermination: positioning and ranging functions (e.g., GNSS/GPS, certain radar/ranging implementations) - Composite products: document whether the radio function is integral, optional, or user-installable ## Annex I exclusions and common do not assume cases RED excludes some equipment because Annex I routes them to other Union regimes or treats them as out of scope. Do not guess: document the legal basis for an exclusion and keep it with the technical file. - Fixed-line terminal equipment is outside RED because the relevant safety and EMC requirements are covered elsewhere - Marine equipment within the marine-equipment regime is excluded - Airborne products, parts, and appliances within the aviation regime are excluded - Custom-built evaluation kits are excluded only when they are destined for professionals and used solely at research and development facilities - Radio-amateur equipment is outside RED only where it is not made available on the market in the Annex I sense - Accessories can still matter if they change radio performance, such as antennas or amplifiers supplied with the product ## Borderline examples teams ask about These are the cases that typically cause scope churn: receivers, partially-radio products, and embedded modules. Use these as a checklist for internal alignment, then run the applicability test page for a structured outcome. - TV and radio receivers: ensure you understand whether your receiver category is treated as radio equipment in your intended market context - Products with Wi-Fi, Bluetooth, or GNSS modules are usually in scope and the real work shifts to essential requirements and standards - RFID/NFC: scope depends on how the radio function is used and whether the equipment is made available as radio equipment - Infrared-only products: not radio equipment (but verify there is no intentional radio emission) - Construction kits and amateur-radio kits require a documented Annex I analysis before you treat them as excluded ## Classification record (what to write down) Your scope decision should be auditable: the facts, the conclusion, and the evidence. Treat this record like a controlled document and update it when the radio design changes. - Product identifiers: model/SKU, variants, firmware versions (where relevant) - Radio facts: bands, protocols, transmit power classes, receiver sensitivity expectations, intended installation - Exclusions analysis (if any): which exclusion and why it applies - Essential requirements map: which Article 3 requirements apply and the standards/test plan you use - Cybersecurity trigger check: whether Delegated Regulation (EU) 2022/30 categories apply *Recommended next step* *Placement: after the scope or definition section* ## Use EU Radio Equipment Directive (RED) Scope and Classification as a cited research workflow Research Copilot can take EU Radio Equipment Directive (RED) Scope and Classification from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Radio Equipment Directive (RED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Radio Equipment Directive (RED) Scope and Classification](/solutions/research-copilot.md): Start from EU Radio Equipment Directive (RED) Scope and Classification and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Radio Equipment Directive (RED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Radio Equipment Directive (RED) Scope and Classification. ## Primary sources - [Directive 2014/53/EU (Radio Equipment Directive) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/53/oj?ref=sorena.io) - Primary legal text for scope, definitions, and essential requirements. - [European Commission - Guide to the Radio Equipment Directive (RED Guide, 2018)](https://ec.europa.eu/growth/sectors/electrical-engineering/rtte-directive/?ref=sorena.io) - Practical guidance and examples on what is and is not radio equipment, including Annex I exclusions and amateur-radio treatment. - [EU Single Market - Radio Equipment Directive overview](https://single-market-economy.ec.europa.eu/sectors/electrical-and-electronic-engineering-industries-eei/radio-equipment-directive-red_en?ref=sorena.io) - Overview page with official context and links to related resources. ## Related Topic Guides - [Conformity Assessment and CE Marking | EU RED 2014/53/EU | Technical Documentation, EU DoC, Notified Bodies](/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce.md): A practical guide to RED conformity assessment and CE marking under Directive 2014/53/EU. - [Essential Requirements | EU Radio Equipment Directive (RED) 2014/53/EU | Safety, EMC, Spectrum, Cybersecurity (EU) 2022/30](/artifacts/eu/radio-equipment-directive/requirements.md): A practical RED essential requirements guide for Directive 2014/53/EU: map Article 3 requirements to product features and verification evidence for safety. - [Harmonised Standards and Test Plans | EU RED 2014/53/EU | Presumption of Conformity, OJ References, Verification Strategy](/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans.md): A practical guide to harmonised standards under the EU Radio Equipment Directive (RED) 2014/53/EU: how presumption of conformity works. - [RED Applicability Test | Is My Product in Scope of the EU Radio Equipment Directive (RED) 2014/53/EU?](/artifacts/eu/radio-equipment-directive/applicability-test.md): A structured RED applicability test for Directive 2014/53/EU: determine if your product is radio equipment, whether any exclusions apply. - [RED Compliance Checklist | EU Radio Equipment Directive 2014/53/EU | CE Marking Evidence Pack](/artifacts/eu/radio-equipment-directive/checklist.md): An audit-ready RED compliance checklist for Directive 2014/53/EU: scope and classification, essential requirements mapping (safety/health, EMC, spectrum). - [RED Compliance Program | EU Radio Equipment Directive 2014/53/EU Implementation Playbook](/artifacts/eu/radio-equipment-directive/compliance.md): A practical RED compliance program playbook for Directive 2014/53/EU: set up governance, map essential requirements to standards and tests. - [RED Conformity Assessment Template | CE Technical File Structure for Directive 2014/53/EU](/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template.md): A practical RED conformity assessment template for Directive 2014/53/EU: a CE technical file structure with sections for scope memo. - [RED Cybersecurity Delegated Act Guide | Implement Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025)](/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide.md): Step-by-step implementation guide for the RED cybersecurity delegated act. - [RED Cybersecurity Requirements | Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025) | Article 3(3)(d)(e)(f)](/artifacts/eu/radio-equipment-directive/cybersecurity-requirements.md): A practical RED cybersecurity requirements guide: Delegated Regulation (EU) 2022/30 activates Article 3(3)(d) network protection. - [RED Deadlines and Compliance Calendar | Directive 2014/53/EU Key Dates (2016-2026) | Cybersecurity 2025, Common Charger 2024/2026](/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar.md): A practical RED deadlines and compliance calendar: core RED dates (transposition by 12 Jun 2016; measures apply from 13 Jun 2016. - [RED FAQ | EU Radio Equipment Directive 2014/53/EU Questions | Scope, CE Marking, Cybersecurity (EU) 2022/30, Standards](/artifacts/eu/radio-equipment-directive/faq.md): A practical RED FAQ for Directive 2014/53/EU: what is radio equipment, what is in scope, what happened in the 2016/2017 transition. - [RED Penalties and Enforcement | EU Radio Equipment Directive 2014/53/EU | Market Surveillance, CE Documentation Risk](/artifacts/eu/radio-equipment-directive/penalties-and-fines.md): A practical RED enforcement and penalties guide for Directive 2014/53/EU: how market surveillance works in practice. - [RED Timeline | EU Radio Equipment Directive 2014/53/EU Roadmap | Cybersecurity (EU) 2022/30, Common Charger (EU) 2022/2380](/artifacts/eu/radio-equipment-directive/timeline.md): A practical RED timeline and roadmap: the core RED transition dates. - [RED vs Cyber Resilience Act (CRA) | RED Cybersecurity (EU) 2022/30 vs CRA (EU) 2024/2847 | What Overlaps, What's Different](/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act.md): A practical comparison of RED vs CRA: RED (Directive 2014/53/EU) is radio-equipment-specific and. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/radio-equipment-directive/scope-and-classification --- --- title: "RED Timeline" canonical_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/timeline" source_url: "https://www.sorena.io/artifacts/eu/radio-equipment-directive/timeline" author: "Sorena AI" description: "A practical RED timeline and roadmap: the core RED transition dates." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RED timeline" - "Radio Equipment Directive roadmap" - "RED cybersecurity timeline 2025" - "Delegated Regulation 2022/30 timeline" - "common charger RED timeline 2024 2026" - "CE marking timeline" - "RED" - "Timeline" - "Cybersecurity" - "Common charger" - "CE marking" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RED Timeline A practical RED timeline and roadmap: the core RED transition dates. *RED* *Timeline* ## EU Radio Equipment Directive (RED) Timeline A roadmap that matches how products actually ship. Use this page to plan verification cycles, documentation releases, and update governance. RED compliance is a lifecycle activity. The key dates (cybersecurity activation and common charger amendments) matter, but the bigger win is sequencing: build the scope memo and standards matrix early, then treat tests and CE documentation as release artifacts. ## Phase 0 - Foundations No matter which amendment date you care about, the same foundation prevents rework: scope decisions, requirements mapping, and a verification strategy. Build once per product family and reuse across variants. - Scope memo per product family + variant appendix - Article 3 requirements-to-standards matrix - Verification plan and release gates - Technical file structure and DoC versioning process ## Phase 1 - Cybersecurity activation (1 Aug 2025) If your radio equipment is internet-connected or processes sensitive data or enables value transfer, (EU) 2022/30 is likely relevant. The date matters because Regulation (EU) 2023/2444 postponed the original 2024 start date to 1 Aug 2025. Treat this as a test planning and evidence packaging milestone. - Classify applicability per variant - Implement controls mapped to Article 3(3)(d)(e)(f) - Run repeatable verification tests and store results in the technical file - Update DoC references if needed ## Phase 2 - Common charging interface amendments (28 Dec 2024 and 28 Apr 2026) Directive (EU) 2022/2380 amended RED with common charging interface obligations for defined radio equipment categories/classes. Use the Annex Ia category mapping as a product management checklist (connector decisions are expensive to change late). - From 28 Dec 2024: measures apply for Annex Ia Part I points 1.1-1.12 categories/classes - From 28 Apr 2026: measures apply for Annex Ia Part I point 1.13 category/class - Deliverables: category mapping, design decisions, and verification evidence ## Always-on maintenance - standards updates and firmware changes RED evidence becomes invalid when it no longer matches the shipped configuration or current standards references. Treat standards updates and firmware/radio configuration changes as triggers for reassessment. - Monitor OJ references of harmonised standards, including 2023/2392, 2023/2669, 2025/138, and 2025/893 - Re-run affected tests when radio stack, bands, power classes, or antennas change - Keep technical file and DoC in sync with shipped variants - Run periodic market surveillance readiness drills *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU Radio Equipment Directive (RED) Timeline into an operational assessment Assessment Autopilot can take EU Radio Equipment Directive (RED) Timeline from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Radio Equipment Directive (RED) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU Radio Equipment Directive (RED) Timeline](/solutions/assessment.md): Start from EU Radio Equipment Directive (RED) Timeline and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU Radio Equipment Directive (RED)](/contact.md): Review your current process, evidence gaps, and next steps for EU Radio Equipment Directive (RED) Timeline. ## Primary sources - [Directive 2014/53/EU (Radio Equipment Directive) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2014/53/oj?ref=sorena.io) - Core RED obligations and conformity framework. - [Delegated Regulation (EU) 2022/30 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2022/30/oj?ref=sorena.io) - Cybersecurity activation scope. Use Regulation (EU) 2023/2444 for the current 1 Aug 2025 application date. - [Delegated Regulation (EU) 2023/2444 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2023/2444/oj?ref=sorena.io) - Moves the cybersecurity application date to 1 Aug 2025. - [Directive (EU) 2022/2380 (common charging interface amendments) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2380/oj?ref=sorena.io) - Common charging interface transposition and application dates via Annex Ia categories. ## Related Topic Guides - [Conformity Assessment and CE Marking | EU RED 2014/53/EU | Technical Documentation, EU DoC, Notified Bodies](/artifacts/eu/radio-equipment-directive/conformity-assessment-and-ce.md): A practical guide to RED conformity assessment and CE marking under Directive 2014/53/EU. - [Essential Requirements | EU Radio Equipment Directive (RED) 2014/53/EU | Safety, EMC, Spectrum, Cybersecurity (EU) 2022/30](/artifacts/eu/radio-equipment-directive/requirements.md): A practical RED essential requirements guide for Directive 2014/53/EU: map Article 3 requirements to product features and verification evidence for safety. - [Harmonised Standards and Test Plans | EU RED 2014/53/EU | Presumption of Conformity, OJ References, Verification Strategy](/artifacts/eu/radio-equipment-directive/harmonized-standards-and-test-plans.md): A practical guide to harmonised standards under the EU Radio Equipment Directive (RED) 2014/53/EU: how presumption of conformity works. - [RED Applicability Test | Is My Product in Scope of the EU Radio Equipment Directive (RED) 2014/53/EU?](/artifacts/eu/radio-equipment-directive/applicability-test.md): A structured RED applicability test for Directive 2014/53/EU: determine if your product is radio equipment, whether any exclusions apply. - [RED Compliance Checklist | EU Radio Equipment Directive 2014/53/EU | CE Marking Evidence Pack](/artifacts/eu/radio-equipment-directive/checklist.md): An audit-ready RED compliance checklist for Directive 2014/53/EU: scope and classification, essential requirements mapping (safety/health, EMC, spectrum). - [RED Compliance Program | EU Radio Equipment Directive 2014/53/EU Implementation Playbook](/artifacts/eu/radio-equipment-directive/compliance.md): A practical RED compliance program playbook for Directive 2014/53/EU: set up governance, map essential requirements to standards and tests. - [RED Conformity Assessment Template | CE Technical File Structure for Directive 2014/53/EU](/artifacts/eu/radio-equipment-directive/red-conformity-assessment-template.md): A practical RED conformity assessment template for Directive 2014/53/EU: a CE technical file structure with sections for scope memo. - [RED Cybersecurity Delegated Act Guide | Implement Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025)](/artifacts/eu/radio-equipment-directive/red-cybersecurity-delegated-act-guide.md): Step-by-step implementation guide for the RED cybersecurity delegated act. - [RED Cybersecurity Requirements | Delegated Regulation (EU) 2022/30 (Applies 1 Aug 2025) | Article 3(3)(d)(e)(f)](/artifacts/eu/radio-equipment-directive/cybersecurity-requirements.md): A practical RED cybersecurity requirements guide: Delegated Regulation (EU) 2022/30 activates Article 3(3)(d) network protection. - [RED Deadlines and Compliance Calendar | Directive 2014/53/EU Key Dates (2016-2026) | Cybersecurity 2025, Common Charger 2024/2026](/artifacts/eu/radio-equipment-directive/deadlines-and-compliance-calendar.md): A practical RED deadlines and compliance calendar: core RED dates (transposition by 12 Jun 2016; measures apply from 13 Jun 2016. - [RED FAQ | EU Radio Equipment Directive 2014/53/EU Questions | Scope, CE Marking, Cybersecurity (EU) 2022/30, Standards](/artifacts/eu/radio-equipment-directive/faq.md): A practical RED FAQ for Directive 2014/53/EU: what is radio equipment, what is in scope, what happened in the 2016/2017 transition. - [RED Penalties and Enforcement | EU Radio Equipment Directive 2014/53/EU | Market Surveillance, CE Documentation Risk](/artifacts/eu/radio-equipment-directive/penalties-and-fines.md): A practical RED enforcement and penalties guide for Directive 2014/53/EU: how market surveillance works in practice. - [RED vs Cyber Resilience Act (CRA) | RED Cybersecurity (EU) 2022/30 vs CRA (EU) 2024/2847 | What Overlaps, What's Different](/artifacts/eu/radio-equipment-directive/red-vs-cyber-resilience-act.md): A practical comparison of RED vs CRA: RED (Directive 2014/53/EU) is radio-equipment-specific and. - [Scope and Classification | EU Radio Equipment Directive (RED) 2014/53/EU | What Is Radio Equipment? Exclusions, Borderline Cases](/artifacts/eu/radio-equipment-directive/scope-and-classification.md): A practical RED scope and classification guide for Directive 2014/53/EU: what counts as radio equipment, which Annex I exclusions take products out of scope. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/radio-equipment-directive/timeline --- --- title: "RoHS Applicability Test" canonical_url: "https://www.sorena.io/artifacts/eu/rohs-directive/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/rohs-directive/applicability-test" author: "Sorena AI" description: "A structured EU RoHS applicability test for Directive 2011/65/EU: determine if your product is electrical and electronic equipment (EEE)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RoHS applicability test" - "is my product RoHS compliant" - "RoHS scope EEE" - "RoHS open scope 2019" - "RoHS cables spare parts" - "Directive 2011/65/EU in scope" - "RoHS" - "Applicability" - "Scope" - "EEE" - "Directive 2011/65/EU" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RoHS Applicability Test A structured EU RoHS applicability test for Directive 2011/65/EU: determine if your product is electrical and electronic equipment (EEE). *RoHS* *Applicability* ## EU RoHS Directive (2011/65/EU) Applicability Test Decide scope early and stop losing time on rework. Output: an in-scope summary you can reuse in your EN IEC 63000 technical documentation pack. RoHS scope decisions drive everything: supplier evidence, testing, and exemption tracking. Use this applicability test to classify your product and its variants, document borderline logic, and produce a scope memo you can keep with your technical file. ## Step 1 - Is it EEE? (basic trigger) RoHS applies to electrical and electronic equipment (EEE) placed on the EU market. Start with product facts, not internal labels. If your product includes embedded electronics, treat it as a candidate for RoHS unless an exclusion clearly applies. - Does it depend on electric currents or electromagnetic fields to work? - Is it placed on the market as equipment (not only as a raw material)? - Do you ship variants (regions, power supplies, optional modules) that change scope? ## Step 2 - Category and 'open scope' checks Category mapping matters because Article 4 staged dates, exemption validity periods, and spare-parts rules can differ by category. Before you conclude that a product is in scope, run the Article 2(4) exclusions check and document the evidence for any exclusion you rely on. - Map to the relevant Annex I EEE category and record why that category applies - Check Article 2(4) exclusions such as equipment necessary for national security, space equipment, large-scale stationary industrial tools, and large-scale fixed installations - For products that were outside RoHS 1, remember the open-scope transition ended on 22 Jul 2019 for newly placed products - Capture borderlines: integrated electronics, industrial equipment, professional-only configurations, and cable assemblies ## Step 3 - Cables and spare parts (common scope surprises) RoHS scope often expands through what you ship with the product: cables, adapters, assemblies, and spare parts. Decide whether the cable or spare part is finished EEE, whether it is placed on the market as a stand-alone item, and whether the repair or reuse carve-outs apply. - Identify all shipped cables and wire harnesses and treat them as high-risk for phthalates and flame retardants - Classify spare parts: repair or reuse vs upgrade or new functionality - Remember that spare parts that are not finished EEE do not carry the same RoHS CE-marking and DoC duty as finished EEE - For phthalates: track the 22 Jul 2019 / 22 Jul 2021 split and the carve-out for cables/spare parts for older equipment ## Step 4 - If in scope: what you must do next Scope is only useful if it triggers a concrete work plan. Once in scope, RoHS becomes a portfolio program: restricted substances controls + supplier evidence + exemptions tracking + technical documentation. - Build a restricted-substances risk map (homogeneous materials, hotspots) - Set supplier declaration requirements and change-notification rules - Decide your verification strategy (risk-based testing + sampling) - If any restricted substance use is intentional: evaluate exemptions and track them with expiry risk - Build EN IEC 63000-aligned technical documentation and keep it retrievable per SKU/variant ## Outcome summary (copy/paste scope memo) Write a 5 - 10 line scope memo and store it with your technical documentation. If variants differ, list them explicitly (variant A in scope, variant B out of scope, etc.). - Product identification: model/SKU and variants - EEE facts and category mapping - Exclusions analysis (if any) - Cables/spare parts coverage and phthalates applicability date - Next steps: substances -> supplier declarations -> exemptions (if needed) -> technical documentation *Recommended next step* *Placement: after the applicability result* ## Turn EU RoHS Directive (2011/65/EU) Applicability Test into an operational assessment Assessment Autopilot can take EU RoHS Directive (2011/65/EU) Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU RoHS Directive (2011/65/EU) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU RoHS Directive (2011/65/EU) Applicability Test](/solutions/assessment.md): Start from EU RoHS Directive (2011/65/EU) Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU RoHS Directive (2011/65/EU)](/contact.md): Review your current process, evidence gaps, and next steps for EU RoHS Directive (2011/65/EU) Applicability Test. ## Primary sources - [Directive 2011/65/EU (RoHS 2) consolidated (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02011L0065-20250101&ref=sorena.io) - Primary source for RoHS scope, categories, exclusions, and obligations. - [RoHS FAQ and key guidance (DG Environment)](https://environment.ec.europa.eu/system/files/2021-01/FAQ%20key%20guidance%20document%20-%20RoHS.pdf?ref=sorena.io) - Practical Q&A on scope, exclusions, cables, spare parts, and CE/technical documentation expectations. - [DG Environment - RoHS Directive overview](https://environment.ec.europa.eu/topics/waste-and-recycling/rohs-directive_en?ref=sorena.io) - Official overview and links to implementation resources. ## Related Topic Guides - [EU RoHS FAQ (Scope, Exemptions, Phthalates, Technical File, CE) | RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/faq.md): High-signal EU RoHS FAQ grounded in official sources: what counts as EEE, staged applicability (22 July 2014/2017/2019). - [EU RoHS Timeline: RoHS 1 (2002) -> RoHS 2 (2011/2013) -> Open Scope (2019) -> Phthalates (2019/2021)](/artifacts/eu/rohs-directive/timeline.md): A date-by-date EU RoHS timeline for implementers: RoHS 1 (2002), RoHS 2 recast and transposition (2011 - 2013). - [Restricted Substances and Thresholds | EU RoHS Directive 2011/65/EU | Homogeneous Material Limits (0.1% / 0.01%) + Phthalates (2015/863)](/artifacts/eu/rohs-directive/restricted-substances-and-thresholds.md): A practical RoHS restricted substances guide for Directive 2011/65/EU: the 10 substances in Annex II, homogeneous material threshold logic (0.1% for most. - [RoHS Compliance Checklist | EU RoHS Directive 2011/65/EU | Supplier Evidence, Exemptions, EN IEC 63000 Technical File](/artifacts/eu/rohs-directive/checklist.md): An audit-ready RoHS compliance checklist for Directive 2011/65/EU: scope and EEE category mapping. - [RoHS Compliance Program | EU RoHS Directive 2011/65/EU Implementation Playbook | Supplier Controls, Exemptions, Evidence](/artifacts/eu/rohs-directive/compliance.md): A practical RoHS compliance program playbook for Directive 2011/65/EU: set up governance, map homogeneous material risks across your BOM. - [RoHS Deadlines and Compliance Calendar (2013, 2014, 2017, 2019, 2021) | EU RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar.md): A RoHS compliance calendar you can actually operationalize: staged applicability dates (22 July 2014/2017/2019). - [RoHS Enforcement, Penalties, and Fines | EU RoHS Directive 2011/65/EU (Member State rules)](/artifacts/eu/rohs-directive/penalties-and-fines.md): What EU RoHS enforcement looks like in practice: market surveillance checks, documentation requests, CE marking scrutiny. - [RoHS Exemptions Tracker Guide | How to Build an Exemption Register (Annex III/IV), Link to BOM, Monitor Expiry](/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide.md): A practical guide to building a RoHS exemptions tracker: recommended tracker fields (exemption reference, exact wording, scope conditions. - [RoHS Exemptions Tracking | Directive 2011/65/EU Annex III and Annex IV | Expiry Risk, Evidence, Renewal Strategy](/artifacts/eu/rohs-directive/exemptions-tracking.md): A practical RoHS exemptions tracking guide for Directive 2011/65/EU: how Annex III and Annex IV exemptions work. - [RoHS Requirements | EU RoHS Directive 2011/65/EU | Substance Restrictions (Annex II), Exemptions (Annex III/IV), CE Evidence](/artifacts/eu/rohs-directive/requirements.md): A practical RoHS requirements breakdown for Directive 2011/65/EU: restricted substances thresholds in homogeneous materials (Annex II). - [RoHS Supplier Declaration Template | Annex II Substances, Homogeneous Material Coverage, Exemptions Disclosure](/artifacts/eu/rohs-directive/rohs-supplier-declaration-template.md): A practical RoHS supplier declaration template for Directive 2011/65/EU. - [RoHS vs REACH | What's the Difference? | EU RoHS Directive 2011/65/EU vs REACH Regulation (EC) 1907/2006](/artifacts/eu/rohs-directive/rohs-vs-reach.md): A practical RoHS vs REACH guide: RoHS (Directive 2011/65/EU) restricts specific substances in EEE above thresholds in homogeneous materials and is tied to CE. - [Supplier Declarations and Verification | RoHS Compliance Program | Supplier Questionnaires, Change Control, Risk-Based Testing](/artifacts/eu/rohs-directive/supplier-declarations-and-verification.md): A practical supplier evidence playbook for EU RoHS Directive 2011/65/EU. - [Technical Documentation and CE | RoHS Directive 2011/65/EU | EN IEC 63000, EU Declaration of Conformity, Evidence Vault](/artifacts/eu/rohs-directive/technical-documentation-and-ce.md): A practical RoHS technical documentation guide for Directive 2011/65/EU. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/rohs-directive/applicability-test --- --- title: "RoHS Compliance Checklist" canonical_url: "https://www.sorena.io/artifacts/eu/rohs-directive/checklist" source_url: "https://www.sorena.io/artifacts/eu/rohs-directive/checklist" author: "Sorena AI" description: "An audit-ready RoHS compliance checklist for Directive 2011/65/EU: scope and EEE category mapping." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RoHS compliance checklist" - "RoHS audit checklist" - "Directive 2011/65/EU checklist" - "EN IEC 63000 checklist" - "RoHS exemptions tracking checklist" - "RoHS supplier declaration checklist" - "RoHS" - "Checklist" - "Restricted substances" - "Exemptions" - "EN IEC 63000" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RoHS Compliance Checklist An audit-ready RoHS compliance checklist for Directive 2011/65/EU: scope and EEE category mapping. *RoHS* *Checklist* ## EU RoHS Directive (2011/65/EU) Compliance Checklist Turn RoHS into owned tasks and a retrievable evidence pack. Output: scope memo, restricted substances risk map, supplier evidence pack, exemption register, EN IEC 63000 technical file. Use this checklist as your RoHS program spine. The goal is evidence-backed compliance: every claim should have an owner, an artifact, and a retrieval path per SKU/variant. ## 1) Scope and category mapping Lock scope early and document it. Scope drift causes expensive rework. Store the scope memo with your technical file. - Determine EEE status and category mapping - Identify variants (regional SKUs, cable kits, accessories, spare parts) - Document borderline logic and any exclusions ## 2) Restricted substances controls (Annex II) Build controls at the homogeneous material level and focus on hotspots. Treat phthalates as a procurement and cable/soft-plastic control. - Create a restricted-substances risk map across the BOM (homogeneous materials + hotspots) - Apply thresholds (0.1% generally; 0.01% cadmium) and document measurement logic - Phthalates: implement 22 Jul 2019 / 22 Jul 2021 applicability split and carve-outs for older equipment ## 3) Supplier declarations and verification Evidence starts with suppliers. Declarations must state coverage and change control. Verification should be targeted and trigger-based. - Collect supplier declarations covering Annex II substances at homogeneous material level - Require exemptions disclosure (if any) and scope mapping - Define verification triggers (new supplier, material change, process change, inconsistent declarations) - Implement change notification and traceability to SKUs and lots where feasible ## 4) Exemptions register (Annex III/IV) If you rely on exemptions, treat them like expiring certificates. The checklist item is not exemption exists, but exemption use is defensible. - Register each exemption use case: exemption -> application -> part/material -> supplier - Monitor expiry and initiate redesign/renewal decisions 18 - 24 months in advance - Store evidence packs per exemption use case and link to technical file ## 5) Technical documentation and CE evidence (EN IEC 63000) Build an EN IEC 63000-aligned technical documentation pack and keep it retrievable. Keep the EU Declaration of Conformity aligned to the shipped product and evidence, and retain the technical documentation and DoC for 10 years after placing on the market. - Technical file structure aligned to EN IEC 63000: scope, evidence sources, evaluation logic, conclusions - Store: declarations, test reports, exemption register, change logs, and the product identifiers used on the DoC - Confirm importer document access and distributor due-care checks before release - Run an evidence retrieval drill and fix gaps before an authority request arrives *Recommended next step* *Placement: after the checklist block* ## Turn EU RoHS Directive (2011/65/EU) Compliance Checklist into an operational assessment Assessment Autopilot can take EU RoHS Directive (2011/65/EU) Compliance Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU RoHS Directive (2011/65/EU) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU RoHS Directive (2011/65/EU) Compliance Checklist](/solutions/assessment.md): Start from EU RoHS Directive (2011/65/EU) Compliance Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU RoHS Directive (2011/65/EU)](/contact.md): Review your current process, evidence gaps, and next steps for EU RoHS Directive (2011/65/EU) Compliance Checklist. ## Primary sources - [Directive 2011/65/EU (RoHS 2) consolidated (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02011L0065-20250101&ref=sorena.io) - Primary source for RoHS restrictions and exemptions framework. - [Delegated Directive (EU) 2015/863 (phthalates) (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L0863&ref=sorena.io) - Adds four phthalates to Annex II and defines application dates and carve-outs. - [Commission Implementing Decision (EU) 2020/659 - EN IEC 63000 reference (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2020/659/oj?ref=sorena.io) - References EN IEC 63000:2018 for RoHS technical documentation. - [RoHS FAQ and key guidance (DG Environment)](https://environment.ec.europa.eu/system/files/2021-01/FAQ%20key%20guidance%20document%20-%20RoHS.pdf?ref=sorena.io) - Practical Q&A on scope, evidence, and CE expectations. ## Related Topic Guides - [EU RoHS FAQ (Scope, Exemptions, Phthalates, Technical File, CE) | RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/faq.md): High-signal EU RoHS FAQ grounded in official sources: what counts as EEE, staged applicability (22 July 2014/2017/2019). - [EU RoHS Timeline: RoHS 1 (2002) -> RoHS 2 (2011/2013) -> Open Scope (2019) -> Phthalates (2019/2021)](/artifacts/eu/rohs-directive/timeline.md): A date-by-date EU RoHS timeline for implementers: RoHS 1 (2002), RoHS 2 recast and transposition (2011 - 2013). - [Restricted Substances and Thresholds | EU RoHS Directive 2011/65/EU | Homogeneous Material Limits (0.1% / 0.01%) + Phthalates (2015/863)](/artifacts/eu/rohs-directive/restricted-substances-and-thresholds.md): A practical RoHS restricted substances guide for Directive 2011/65/EU: the 10 substances in Annex II, homogeneous material threshold logic (0.1% for most. - [RoHS Applicability Test | Is My Product In Scope of EU RoHS Directive 2011/65/EU? | EEE, Cables, Spare Parts, Open Scope](/artifacts/eu/rohs-directive/applicability-test.md): A structured EU RoHS applicability test for Directive 2011/65/EU: determine if your product is electrical and electronic equipment (EEE). - [RoHS Compliance Program | EU RoHS Directive 2011/65/EU Implementation Playbook | Supplier Controls, Exemptions, Evidence](/artifacts/eu/rohs-directive/compliance.md): A practical RoHS compliance program playbook for Directive 2011/65/EU: set up governance, map homogeneous material risks across your BOM. - [RoHS Deadlines and Compliance Calendar (2013, 2014, 2017, 2019, 2021) | EU RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar.md): A RoHS compliance calendar you can actually operationalize: staged applicability dates (22 July 2014/2017/2019). - [RoHS Enforcement, Penalties, and Fines | EU RoHS Directive 2011/65/EU (Member State rules)](/artifacts/eu/rohs-directive/penalties-and-fines.md): What EU RoHS enforcement looks like in practice: market surveillance checks, documentation requests, CE marking scrutiny. - [RoHS Exemptions Tracker Guide | How to Build an Exemption Register (Annex III/IV), Link to BOM, Monitor Expiry](/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide.md): A practical guide to building a RoHS exemptions tracker: recommended tracker fields (exemption reference, exact wording, scope conditions. - [RoHS Exemptions Tracking | Directive 2011/65/EU Annex III and Annex IV | Expiry Risk, Evidence, Renewal Strategy](/artifacts/eu/rohs-directive/exemptions-tracking.md): A practical RoHS exemptions tracking guide for Directive 2011/65/EU: how Annex III and Annex IV exemptions work. - [RoHS Requirements | EU RoHS Directive 2011/65/EU | Substance Restrictions (Annex II), Exemptions (Annex III/IV), CE Evidence](/artifacts/eu/rohs-directive/requirements.md): A practical RoHS requirements breakdown for Directive 2011/65/EU: restricted substances thresholds in homogeneous materials (Annex II). - [RoHS Supplier Declaration Template | Annex II Substances, Homogeneous Material Coverage, Exemptions Disclosure](/artifacts/eu/rohs-directive/rohs-supplier-declaration-template.md): A practical RoHS supplier declaration template for Directive 2011/65/EU. - [RoHS vs REACH | What's the Difference? | EU RoHS Directive 2011/65/EU vs REACH Regulation (EC) 1907/2006](/artifacts/eu/rohs-directive/rohs-vs-reach.md): A practical RoHS vs REACH guide: RoHS (Directive 2011/65/EU) restricts specific substances in EEE above thresholds in homogeneous materials and is tied to CE. - [Supplier Declarations and Verification | RoHS Compliance Program | Supplier Questionnaires, Change Control, Risk-Based Testing](/artifacts/eu/rohs-directive/supplier-declarations-and-verification.md): A practical supplier evidence playbook for EU RoHS Directive 2011/65/EU. - [Technical Documentation and CE | RoHS Directive 2011/65/EU | EN IEC 63000, EU Declaration of Conformity, Evidence Vault](/artifacts/eu/rohs-directive/technical-documentation-and-ce.md): A practical RoHS technical documentation guide for Directive 2011/65/EU. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/rohs-directive/checklist --- --- title: "RoHS Compliance Program" canonical_url: "https://www.sorena.io/artifacts/eu/rohs-directive/compliance" source_url: "https://www.sorena.io/artifacts/eu/rohs-directive/compliance" author: "Sorena AI" description: "A practical RoHS compliance program playbook for Directive 2011/65/EU: set up governance, map homogeneous material risks across your BOM." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RoHS compliance program" - "RoHS implementation playbook" - "RoHS supplier controls" - "RoHS exemption tracking program" - "EN IEC 63000 compliance documentation" - "RoHS audit readiness" - "RoHS" - "Compliance program" - "Supplier evidence" - "Exemptions" - "EN IEC 63000" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RoHS Compliance Program A practical RoHS compliance program playbook for Directive 2011/65/EU: set up governance, map homogeneous material risks across your BOM. *RoHS* *Program* ## EU RoHS Directive (2011/65/EU) Compliance A scalable RoHS system beats one-off material scrambles. Build a repeatable program for restricted substances, exemptions, supplier evidence, and technical documentation. RoHS compliance is portfolio compliance. If you ship multiple SKUs or update suppliers, the only sustainable approach is a program: define the unit of control (homogeneous materials), enforce supplier evidence and change control, track exemptions with expiry risk, and maintain technical documentation you can retrieve on request. ## Program architecture (workstreams that map to reality) RoHS work breaks into a small number of durable workstreams. Assign owners and define evidence deliverables per stream. Treat each workstream as part of release gating, not a separate compliance project. - Scope + category mapping: what is EEE, which variants, and any exclusions - Restricted substances control: thresholds and hotspots across homogeneous materials - Supplier evidence + verification: declarations, test triggers, change control - Exemptions management: register, evidence pack, expiry monitoring, redesign/renewal decisions - Technical documentation + CE evidence: EN IEC 63000-aligned technical file + DoC discipline - Operator duties: manufacturer, importer, and distributor checks under Articles 7, 9, and 10 ## Release gating (minimal gates that prevent rework) The easiest way to keep RoHS defensible is strict gating: no shipment without matching evidence. Treat supplier changes and polymer formulation changes as compliance-impacting changes. - Gate 1: scope memo updated for the shipped variant - Gate 2: restricted substances risk map complete for new/changed materials - Gate 3: supplier declarations collected (and verified when triggers apply) - Gate 4: exemption register updated (if used) and expiry risk reviewed - Gate 5: technical documentation pack updated (EN IEC 63000-aligned) and exportable ## Cadence (what to review and how often) Compliance breaks when it has no cadence. Put RoHS on a schedule. Your cadence should reflect risk: high-risk materials and exemptions need more frequent review. - Monthly: exemptions expiring within 24 months; redesign/renewal decisions - Quarterly: high-risk suppliers/materials (cables, soft plastics, solders, coatings) evidence refresh and sampling - Per release: BOM changes, supplier changes, and any exemption scope checks - Annually: program audit and evidence retrieval drill (can you export packs quickly?) ## What 'audit-ready' looks like Audit-ready means you can answer questions fast and consistently. Build a retrieval-first evidence vault and test it periodically. - Evidence vault index: product -> part -> homogeneous material -> evidence - Consistent artifacts: declarations, test reports, exemption evidence packs, and technical file - Clear ownership: who responds to authority requests and how information is validated - Version control: technical file and DoC aligned to shipped configurations - Retention control: manufacturer and importer copies of the technical documentation and DoC kept for 10 years *Recommended next step* *Placement: after the compliance steps* ## Turn EU RoHS Directive (2011/65/EU) Compliance into an operational assessment Assessment Autopilot can take EU RoHS Directive (2011/65/EU) Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU RoHS Directive (2011/65/EU) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU RoHS Directive (2011/65/EU) Compliance](/solutions/assessment.md): Start from EU RoHS Directive (2011/65/EU) Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU RoHS Directive (2011/65/EU)](/contact.md): Review your current process, evidence gaps, and next steps for EU RoHS Directive (2011/65/EU) Compliance. ## Primary sources - [Directive 2011/65/EU (RoHS 2) consolidated (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02011L0065-20250101&ref=sorena.io) - Primary source for RoHS compliance obligations and exemption framework. - [Commission Implementing Decision (EU) 2020/659 - EN IEC 63000 reference (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2020/659/oj?ref=sorena.io) - References EN IEC 63000:2018 for RoHS technical documentation. - [RoHS FAQ and key guidance (DG Environment)](https://environment.ec.europa.eu/system/files/2021-01/FAQ%20key%20guidance%20document%20-%20RoHS.pdf?ref=sorena.io) - Practical Q&A on implementing RoHS across scope, evidence, and CE expectations. ## Related Topic Guides - [EU RoHS FAQ (Scope, Exemptions, Phthalates, Technical File, CE) | RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/faq.md): High-signal EU RoHS FAQ grounded in official sources: what counts as EEE, staged applicability (22 July 2014/2017/2019). - [EU RoHS Timeline: RoHS 1 (2002) -> RoHS 2 (2011/2013) -> Open Scope (2019) -> Phthalates (2019/2021)](/artifacts/eu/rohs-directive/timeline.md): A date-by-date EU RoHS timeline for implementers: RoHS 1 (2002), RoHS 2 recast and transposition (2011 - 2013). - [Restricted Substances and Thresholds | EU RoHS Directive 2011/65/EU | Homogeneous Material Limits (0.1% / 0.01%) + Phthalates (2015/863)](/artifacts/eu/rohs-directive/restricted-substances-and-thresholds.md): A practical RoHS restricted substances guide for Directive 2011/65/EU: the 10 substances in Annex II, homogeneous material threshold logic (0.1% for most. - [RoHS Applicability Test | Is My Product In Scope of EU RoHS Directive 2011/65/EU? | EEE, Cables, Spare Parts, Open Scope](/artifacts/eu/rohs-directive/applicability-test.md): A structured EU RoHS applicability test for Directive 2011/65/EU: determine if your product is electrical and electronic equipment (EEE). - [RoHS Compliance Checklist | EU RoHS Directive 2011/65/EU | Supplier Evidence, Exemptions, EN IEC 63000 Technical File](/artifacts/eu/rohs-directive/checklist.md): An audit-ready RoHS compliance checklist for Directive 2011/65/EU: scope and EEE category mapping. - [RoHS Deadlines and Compliance Calendar (2013, 2014, 2017, 2019, 2021) | EU RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar.md): A RoHS compliance calendar you can actually operationalize: staged applicability dates (22 July 2014/2017/2019). - [RoHS Enforcement, Penalties, and Fines | EU RoHS Directive 2011/65/EU (Member State rules)](/artifacts/eu/rohs-directive/penalties-and-fines.md): What EU RoHS enforcement looks like in practice: market surveillance checks, documentation requests, CE marking scrutiny. - [RoHS Exemptions Tracker Guide | How to Build an Exemption Register (Annex III/IV), Link to BOM, Monitor Expiry](/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide.md): A practical guide to building a RoHS exemptions tracker: recommended tracker fields (exemption reference, exact wording, scope conditions. - [RoHS Exemptions Tracking | Directive 2011/65/EU Annex III and Annex IV | Expiry Risk, Evidence, Renewal Strategy](/artifacts/eu/rohs-directive/exemptions-tracking.md): A practical RoHS exemptions tracking guide for Directive 2011/65/EU: how Annex III and Annex IV exemptions work. - [RoHS Requirements | EU RoHS Directive 2011/65/EU | Substance Restrictions (Annex II), Exemptions (Annex III/IV), CE Evidence](/artifacts/eu/rohs-directive/requirements.md): A practical RoHS requirements breakdown for Directive 2011/65/EU: restricted substances thresholds in homogeneous materials (Annex II). - [RoHS Supplier Declaration Template | Annex II Substances, Homogeneous Material Coverage, Exemptions Disclosure](/artifacts/eu/rohs-directive/rohs-supplier-declaration-template.md): A practical RoHS supplier declaration template for Directive 2011/65/EU. - [RoHS vs REACH | What's the Difference? | EU RoHS Directive 2011/65/EU vs REACH Regulation (EC) 1907/2006](/artifacts/eu/rohs-directive/rohs-vs-reach.md): A practical RoHS vs REACH guide: RoHS (Directive 2011/65/EU) restricts specific substances in EEE above thresholds in homogeneous materials and is tied to CE. - [Supplier Declarations and Verification | RoHS Compliance Program | Supplier Questionnaires, Change Control, Risk-Based Testing](/artifacts/eu/rohs-directive/supplier-declarations-and-verification.md): A practical supplier evidence playbook for EU RoHS Directive 2011/65/EU. - [Technical Documentation and CE | RoHS Directive 2011/65/EU | EN IEC 63000, EU Declaration of Conformity, Evidence Vault](/artifacts/eu/rohs-directive/technical-documentation-and-ce.md): A practical RoHS technical documentation guide for Directive 2011/65/EU. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/rohs-directive/compliance --- --- title: "RoHS Deadlines and Compliance Calendar (2013, 2014, 2017, 2019, 2021)" canonical_url: "https://www.sorena.io/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A RoHS compliance calendar you can actually operationalize: staged applicability dates (22 July 2014/2017/2019)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RoHS deadlines" - "RoHS compliance calendar" - "RoHS open scope 22 July 2019" - "RoHS phthalates 22 July 2019" - "RoHS phthalates 22 July 2021" - "RoHS exemption renewal 18 months" - "RoHS staged applicability 2014 2017 2019" - "Open scope 2019" - "Phthalates 2019/2021" - "Exemption renewal" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RoHS Deadlines and Compliance Calendar (2013, 2014, 2017, 2019, 2021) A RoHS compliance calendar you can actually operationalize: staged applicability dates (22 July 2014/2017/2019). *RoHS* *Calendar* ## EU RoHS Directive (2011/65/EU) Deadlines and compliance calendar Put the real RoHS dates into your release calendar. Track staged applicability, RoHS 3 phthalates dates, and exemption renewals as expiring risk. RoHS is not a single deadline. It's a set of staged applicability dates, restricted-substance updates (notably the 4 RoHS 3 phthalates), and an exemptions lifecycle with strict renewal timing. This page turns those legal dates into calendar events your engineering, procurement, and compliance teams can run. ## The dates that drive RoHS planning (staged applicability) RoHS applies by EEE category and, for certain categories, enters via staged dates. Treat these as first-placed-on-the-market gates: you should be able to prove compliance for any product shipped after the relevant date. Use these dates to design your internal cutovers: supplier declaration collection, test triggers, and technical-file readiness. - By 2 January 2013: Member State transposition date (national rules live by this date) - 3 January 2013: RoHS 1 repealed; RoHS 2 regime fully takes over - 22 July 2014: medical devices enter RoHS (staged category applicability) - 22 July 2016: in vitro diagnostic medical devices enter RoHS - 22 July 2017: industrial monitoring and control instruments enter RoHS - 22 July 2019: open scope (Category 11) and remaining EEE staged into scope ## RoHS 3 phthalates: schedule the 2019 and 2021 cutovers Delegated Directive (EU) 2015/863 added four phthalates (DEHP, BBP, DBP, DIBP) to the restricted substances list (Annex II). The restrictions apply on different dates depending on the EEE category. Operationally: plan a supplier re-declaration and targeted testing wave (cables, plastics, adhesives, elastomers) before each cutover, then enforce it as a change-control gate. - 22 July 2019: phthalates restriction applies for most EEE - 22 July 2021: phthalates restriction applies for medical devices and monitoring/control instruments (including industrial) - Spare parts / repair carve-outs can apply for equipment placed on the market before the relevant cutover date (2019 or 2021) ## Exemptions: renewal timing is a hard calendar constraint Exemptions (Annex III and Annex IV) are time-limited and can expire or be narrowed. Treat them as expiring risk: if an exemption sunsets, you need a redesign path (substitution) or a renewal dossier. RoHS sets concrete timing rules for renewal and for what happens if a renewal is rejected - these should be calendar events, not forgotten footnotes. - Renewal application must be submitted no later than 18 months before the exemption expires - If renewal is requested in time, the existing exemption remains valid until the Commission decision - The Commission states that an exemption decision currently takes about 18 to 24 months from the application date - If a renewal is rejected or an exemption is revoked, expiry is typically 12 - 18 months after the decision (plan redesign capacity accordingly) - Track validity periods by category: generally 5 years for categories 1 to 7, 10 and 11, and 7 years for categories 8 and 9 *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU RoHS Directive (2011/65/EU) Deadlines and compliance calendar into an operational assessment Assessment Autopilot can take EU RoHS Directive (2011/65/EU) Deadlines and compliance calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU RoHS Directive (2011/65/EU) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU RoHS Directive (2011/65/EU) Deadlines and compliance calendar](/solutions/assessment.md): Start from EU RoHS Directive (2011/65/EU) Deadlines and compliance calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU RoHS Directive (2011/65/EU)](/contact.md): Review your current process, evidence gaps, and next steps for EU RoHS Directive (2011/65/EU) Deadlines and compliance calendar. ## A release-ready compliance cadence (what to schedule every quarter) RoHS compliance quality comes from repetition: make it part of release management. If you only do a one-time paper exercise, the next supplier change or BOM revision becomes a compliance incident. Schedule recurring checkpoints to keep your evidence pack (supplier declarations, tests, exemption status, technical file) aligned with what you actually ship. - Quarterly: refresh exemptions register and check expiry / renewal status (especially for Annex III/IV) - Per release: enforce a material-change gate (new supplier / new material / new part -> declaration + test decision) - Monthly: reconcile declared homogeneous materials vs BOM/PLM; close evidence gaps - Annually: audit a sample of SKUs end-to-end (declaration -> test -> technical file -> DoC) for audit readiness ## Copy/paste calendar template (events to add for each product family) Use relative timeboxes so teams can act before shipment. The goal is simple: you should never ship an EEE configuration whose RoHS status is unknown. Adjust lead times for your supply chain realities (molded parts, cable harnesses, PCBAs, plastics). - T-120 days: supplier re-confirmation for plastics/cables + updated declarations requested - T-90 days: targeted testing decision (screening vs lab) for high-risk parts/material changes - T-60 days: exemption check (still valid? renewal pending? scope matches product use?) - T-30 days: technical file completeness check (EN IEC 63000-aligned index + traceable evidence) - T-0: ship gate - DoC and evidence pack retrievable within hours, not weeks ## Primary sources - [Directive 2011/65/EU (RoHS 2) consolidated (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02011L0065-20250101&ref=sorena.io) - Primary source for staged applicability dates, exemptions renewal timing, and penalties framework (via Member State transposition). - [Delegated Directive (EU) 2015/863 (RoHS 3 phthalates) (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L0863&ref=sorena.io) - Adds DEHP, BBP, DBP, and DIBP to Annex II and sets staged applicability dates (2019/2021). - [RoHS implementation and exemptions (European Commission, DG Environment)](https://environment.ec.europa.eu/topics/waste-and-recycling/rohs-directive/rohs-directive-implementation_en?ref=sorena.io) - Tracks how exemptions are requested/evaluated and points to the current exemptions lists. - [RoHS FAQ and key guidance (European Commission, DG Environment)](https://environment.ec.europa.eu/system/files/2021-01/FAQ%20key%20guidance%20document%20-%20RoHS.pdf?ref=sorena.io) - Practical Q&A for scope and edge cases (components, cables, CE marking, evidence expectations). - [Oeko-Institut RoHS exemptions database](https://rohs.exemptions.oeko.info/?ref=sorena.io) - Operational tracking interface for exemptions status and updates (use alongside official annex texts). ## Related Topic Guides - [EU RoHS FAQ (Scope, Exemptions, Phthalates, Technical File, CE) | RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/faq.md): High-signal EU RoHS FAQ grounded in official sources: what counts as EEE, staged applicability (22 July 2014/2017/2019). - [EU RoHS Timeline: RoHS 1 (2002) -> RoHS 2 (2011/2013) -> Open Scope (2019) -> Phthalates (2019/2021)](/artifacts/eu/rohs-directive/timeline.md): A date-by-date EU RoHS timeline for implementers: RoHS 1 (2002), RoHS 2 recast and transposition (2011 - 2013). - [Restricted Substances and Thresholds | EU RoHS Directive 2011/65/EU | Homogeneous Material Limits (0.1% / 0.01%) + Phthalates (2015/863)](/artifacts/eu/rohs-directive/restricted-substances-and-thresholds.md): A practical RoHS restricted substances guide for Directive 2011/65/EU: the 10 substances in Annex II, homogeneous material threshold logic (0.1% for most. - [RoHS Applicability Test | Is My Product In Scope of EU RoHS Directive 2011/65/EU? | EEE, Cables, Spare Parts, Open Scope](/artifacts/eu/rohs-directive/applicability-test.md): A structured EU RoHS applicability test for Directive 2011/65/EU: determine if your product is electrical and electronic equipment (EEE). - [RoHS Compliance Checklist | EU RoHS Directive 2011/65/EU | Supplier Evidence, Exemptions, EN IEC 63000 Technical File](/artifacts/eu/rohs-directive/checklist.md): An audit-ready RoHS compliance checklist for Directive 2011/65/EU: scope and EEE category mapping. - [RoHS Compliance Program | EU RoHS Directive 2011/65/EU Implementation Playbook | Supplier Controls, Exemptions, Evidence](/artifacts/eu/rohs-directive/compliance.md): A practical RoHS compliance program playbook for Directive 2011/65/EU: set up governance, map homogeneous material risks across your BOM. - [RoHS Enforcement, Penalties, and Fines | EU RoHS Directive 2011/65/EU (Member State rules)](/artifacts/eu/rohs-directive/penalties-and-fines.md): What EU RoHS enforcement looks like in practice: market surveillance checks, documentation requests, CE marking scrutiny. - [RoHS Exemptions Tracker Guide | How to Build an Exemption Register (Annex III/IV), Link to BOM, Monitor Expiry](/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide.md): A practical guide to building a RoHS exemptions tracker: recommended tracker fields (exemption reference, exact wording, scope conditions. - [RoHS Exemptions Tracking | Directive 2011/65/EU Annex III and Annex IV | Expiry Risk, Evidence, Renewal Strategy](/artifacts/eu/rohs-directive/exemptions-tracking.md): A practical RoHS exemptions tracking guide for Directive 2011/65/EU: how Annex III and Annex IV exemptions work. - [RoHS Requirements | EU RoHS Directive 2011/65/EU | Substance Restrictions (Annex II), Exemptions (Annex III/IV), CE Evidence](/artifacts/eu/rohs-directive/requirements.md): A practical RoHS requirements breakdown for Directive 2011/65/EU: restricted substances thresholds in homogeneous materials (Annex II). - [RoHS Supplier Declaration Template | Annex II Substances, Homogeneous Material Coverage, Exemptions Disclosure](/artifacts/eu/rohs-directive/rohs-supplier-declaration-template.md): A practical RoHS supplier declaration template for Directive 2011/65/EU. - [RoHS vs REACH | What's the Difference? | EU RoHS Directive 2011/65/EU vs REACH Regulation (EC) 1907/2006](/artifacts/eu/rohs-directive/rohs-vs-reach.md): A practical RoHS vs REACH guide: RoHS (Directive 2011/65/EU) restricts specific substances in EEE above thresholds in homogeneous materials and is tied to CE. - [Supplier Declarations and Verification | RoHS Compliance Program | Supplier Questionnaires, Change Control, Risk-Based Testing](/artifacts/eu/rohs-directive/supplier-declarations-and-verification.md): A practical supplier evidence playbook for EU RoHS Directive 2011/65/EU. - [Technical Documentation and CE | RoHS Directive 2011/65/EU | EN IEC 63000, EU Declaration of Conformity, Evidence Vault](/artifacts/eu/rohs-directive/technical-documentation-and-ce.md): A practical RoHS technical documentation guide for Directive 2011/65/EU. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar --- --- title: "RoHS Exemptions Tracking" canonical_url: "https://www.sorena.io/artifacts/eu/rohs-directive/exemptions-tracking" source_url: "https://www.sorena.io/artifacts/eu/rohs-directive/exemptions-tracking" author: "Sorena AI" description: "A practical RoHS exemptions tracking guide for Directive 2011/65/EU: how Annex III and Annex IV exemptions work." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RoHS exemptions Annex III" - "RoHS exemptions Annex IV" - "RoHS exemption tracking" - "RoHS exemption expiry" - "RoHS exemption renewal" - "RoHS exemptions database" - "oeko RoHS exemptions" - "RoHS" - "Exemptions" - "Annex III" - "Annex IV" - "Compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RoHS Exemptions Tracking A practical RoHS exemptions tracking guide for Directive 2011/65/EU: how Annex III and Annex IV exemptions work. *Annex III/IV* *Exemptions* ## EU RoHS Directive (2011/65/EU) Exemptions Tracking Exemptions are product risk - manage them like expiring certificates. Output: an exemption register tied to part numbers, homogeneous materials, and redesign decisions. RoHS exemptions are not a blanket permission to use restricted substances in the product. They are narrowly scoped allowances for specific applications and conditions, typically time-limited and updated over time. If you can't trace an exemption to a specific homogeneous material and usage, you can't defend it. ## What a defensible exemption looks like A defensible exemption is specific, traceable, and evidence-backed. Your objective is to prove: which exemption applies, where it applies in the BOM (homogeneous material), and why you still meet the exemption conditions. - Traceability: exemption -> application -> part number -> homogeneous material - Time control: expiry/renewal dates and status (valid, renewed, sunset, replaced) - Evidence: technical justification, supplier confirmations, and change control ## Annex III vs Annex IV (practical difference) RoHS exemptions are listed in annexes and can differ by equipment category and application. Implementation tip: do not store exemptions only at the 'product' level - store them at the 'application' level. - Annex III: exemptions applicable across a broad set of EEE applications (application-specific allowances) - Annex IV: exemptions focused on certain categories (commonly medical devices and monitoring/control applications) - Maximum validity is usually 5 years for categories 1 to 7, 10 and 11, and 7 years for categories 8 and 9 unless a shorter period is specified - Many exemptions are revised: always check the latest official version and amendment history ## A tracking workflow that prevents surprises Build a simple, non-negotiable workflow: identification -> registration -> monitoring -> decision -> execution. Your surprise prevention is the monitoring and redesign decision timing. - Identify: which restricted substances exist and which uses rely on exemptions - Register: exemption ID, exact wording, scope conditions, affected parts/materials, suppliers - Monitor: expiry dates, renewal status, Commission timelines, and any official updates - Decide: renew vs redesign vs dual-source vs discontinue - Execute: redesign plan, supplier change, and evidence updates (technical file + declarations) ## Evidence pack per exemption (what to keep) The evidence pack makes the exemption defensible in audits and market surveillance requests. Keep it lightweight but complete: scope proof, technical justification, and current supplier confirmations. - Where used: BOM link and homogeneous material definition - Why needed: technical feasibility and substitution assessment (what alternatives were evaluated) - Supplier evidence: declarations for the specific application and change-notification duty - Release control: product variants affected and what changes require re-evaluation ## How to avoid an 'exemption cliff' Exemption cliffs happen when expiry is discovered too late to redesign. Prevent that with early trigger points. If your redesign cycle is 12 - 24 months, your trigger must be at least that early. - Set a trigger horizon: start redesign and renewal planning 18 to 24 months before expiry - File renewal applications no later than 18 months before expiry if you need continued use - If renewal is filed in time, the exemption remains valid until the Commission decision - If a renewal is rejected or an exemption is revoked, expect a 12 to 18 month transition window - Prioritise high-volume SKUs and single-source components - Decouple program work: redesign planning can run while you monitor renewal decisions - Keep a fallback: dual-source or alternative part qualified before sunset *Recommended next step* *Placement: after the scope or definition section* ## Use EU RoHS Directive (2011/65/EU) Exemptions Tracking as a cited research workflow Research Copilot can take EU RoHS Directive (2011/65/EU) Exemptions Tracking from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU RoHS Directive (2011/65/EU) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU RoHS Directive (2011/65/EU) Exemptions Tracking](/solutions/research-copilot.md): Start from EU RoHS Directive (2011/65/EU) Exemptions Tracking and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU RoHS Directive (2011/65/EU)](/contact.md): Review your current process, evidence gaps, and next steps for EU RoHS Directive (2011/65/EU) Exemptions Tracking. ## Primary sources - [Directive 2011/65/EU (RoHS 2) consolidated (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02011L0065-20250101&ref=sorena.io) - Primary source for exemption framework and annex structure. - [DG Environment - RoHS Directive implementation (exemption procedure)](https://environment.ec.europa.eu/topics/waste-and-recycling/rohs-directive/rohs-directive-implementation_en?ref=sorena.io) - Official overview of exemption procedure and implementation context. - [RoHS exemptions database (Oeko-Institut)](https://rohs.exemptions.oeko.info/?ref=sorena.io) - Practical place to track exemption status and history; validate against official EU acts for legal certainty. - [DG Environment - RoHS Directive overview](https://environment.ec.europa.eu/topics/waste-and-recycling/rohs-directive_en?ref=sorena.io) - Official overview and links to exemption request guidance and related resources. ## Related Topic Guides - [EU RoHS FAQ (Scope, Exemptions, Phthalates, Technical File, CE) | RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/faq.md): High-signal EU RoHS FAQ grounded in official sources: what counts as EEE, staged applicability (22 July 2014/2017/2019). - [EU RoHS Timeline: RoHS 1 (2002) -> RoHS 2 (2011/2013) -> Open Scope (2019) -> Phthalates (2019/2021)](/artifacts/eu/rohs-directive/timeline.md): A date-by-date EU RoHS timeline for implementers: RoHS 1 (2002), RoHS 2 recast and transposition (2011 - 2013). - [Restricted Substances and Thresholds | EU RoHS Directive 2011/65/EU | Homogeneous Material Limits (0.1% / 0.01%) + Phthalates (2015/863)](/artifacts/eu/rohs-directive/restricted-substances-and-thresholds.md): A practical RoHS restricted substances guide for Directive 2011/65/EU: the 10 substances in Annex II, homogeneous material threshold logic (0.1% for most. - [RoHS Applicability Test | Is My Product In Scope of EU RoHS Directive 2011/65/EU? | EEE, Cables, Spare Parts, Open Scope](/artifacts/eu/rohs-directive/applicability-test.md): A structured EU RoHS applicability test for Directive 2011/65/EU: determine if your product is electrical and electronic equipment (EEE). - [RoHS Compliance Checklist | EU RoHS Directive 2011/65/EU | Supplier Evidence, Exemptions, EN IEC 63000 Technical File](/artifacts/eu/rohs-directive/checklist.md): An audit-ready RoHS compliance checklist for Directive 2011/65/EU: scope and EEE category mapping. - [RoHS Compliance Program | EU RoHS Directive 2011/65/EU Implementation Playbook | Supplier Controls, Exemptions, Evidence](/artifacts/eu/rohs-directive/compliance.md): A practical RoHS compliance program playbook for Directive 2011/65/EU: set up governance, map homogeneous material risks across your BOM. - [RoHS Deadlines and Compliance Calendar (2013, 2014, 2017, 2019, 2021) | EU RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar.md): A RoHS compliance calendar you can actually operationalize: staged applicability dates (22 July 2014/2017/2019). - [RoHS Enforcement, Penalties, and Fines | EU RoHS Directive 2011/65/EU (Member State rules)](/artifacts/eu/rohs-directive/penalties-and-fines.md): What EU RoHS enforcement looks like in practice: market surveillance checks, documentation requests, CE marking scrutiny. - [RoHS Exemptions Tracker Guide | How to Build an Exemption Register (Annex III/IV), Link to BOM, Monitor Expiry](/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide.md): A practical guide to building a RoHS exemptions tracker: recommended tracker fields (exemption reference, exact wording, scope conditions. - [RoHS Requirements | EU RoHS Directive 2011/65/EU | Substance Restrictions (Annex II), Exemptions (Annex III/IV), CE Evidence](/artifacts/eu/rohs-directive/requirements.md): A practical RoHS requirements breakdown for Directive 2011/65/EU: restricted substances thresholds in homogeneous materials (Annex II). - [RoHS Supplier Declaration Template | Annex II Substances, Homogeneous Material Coverage, Exemptions Disclosure](/artifacts/eu/rohs-directive/rohs-supplier-declaration-template.md): A practical RoHS supplier declaration template for Directive 2011/65/EU. - [RoHS vs REACH | What's the Difference? | EU RoHS Directive 2011/65/EU vs REACH Regulation (EC) 1907/2006](/artifacts/eu/rohs-directive/rohs-vs-reach.md): A practical RoHS vs REACH guide: RoHS (Directive 2011/65/EU) restricts specific substances in EEE above thresholds in homogeneous materials and is tied to CE. - [Supplier Declarations and Verification | RoHS Compliance Program | Supplier Questionnaires, Change Control, Risk-Based Testing](/artifacts/eu/rohs-directive/supplier-declarations-and-verification.md): A practical supplier evidence playbook for EU RoHS Directive 2011/65/EU. - [Technical Documentation and CE | RoHS Directive 2011/65/EU | EN IEC 63000, EU Declaration of Conformity, Evidence Vault](/artifacts/eu/rohs-directive/technical-documentation-and-ce.md): A practical RoHS technical documentation guide for Directive 2011/65/EU. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/rohs-directive/exemptions-tracking --- --- title: "EU RoHS FAQ (Scope, Exemptions, Phthalates, Technical File, CE)" canonical_url: "https://www.sorena.io/artifacts/eu/rohs-directive/faq" source_url: "https://www.sorena.io/artifacts/eu/rohs-directive/faq" author: "Sorena AI" description: "High-signal EU RoHS FAQ grounded in official sources: what counts as EEE, staged applicability (22 July 2014/2017/2019)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU RoHS FAQ" - "RoHS scope what is EEE" - "RoHS open scope 2019" - "RoHS phthalates 2019 2021" - "RoHS exemptions Annex III Annex IV" - "RoHS exemption renewal 18 months" - "EN IEC 63000 RoHS technical file" - "RoHS vs REACH" - "RoHS FAQ" - "RoHS scope" - "RoHS exemptions" - "RoHS phthalates" - "RoHS technical documentation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU RoHS FAQ (Scope, Exemptions, Phthalates, Technical File, CE) High-signal EU RoHS FAQ grounded in official sources: what counts as EEE, staged applicability (22 July 2014/2017/2019). *RoHS* *FAQ* ## EU RoHS Directive (2011/65/EU) FAQ Answers for implementers, not summaries. Use these Q&As to build scope decisions, supplier controls, and evidence packs that survive audits. RoHS questions tend to cluster around four areas: scope (is this EEE and which category/date?), restricted substances (homogeneous material thresholds), exemptions (Annex III/IV and renewal timing), and evidence (supplier declarations, testing, and the technical file). Use this FAQ to answer what do we do next and link into the deep-dive subpages for execution. ## Scope and applicability (the questions that decide everything) Q: What is EEE under RoHS? A: If the product depends on electric currents or electromagnetic fields to work (or to generate, transfer, or measure), it is typically EEE; then you classify it into an Annex I category and check exclusions. Q: What does placed on the market mean for dates? A: RoHS uses placed on the market from staged dates for certain categories; treat the date as a ship gate for configurations first made available in the EU. Q: When does open scope (Category 11) start? A: RoHS staged remaining EEE into scope from 22 July 2019, while Directive (EU) 2017/2102 also fixed the secondary-market problem that had existed in the original RoHS 2 text. - Is my product EEE under RoHS? - Which Annex I category applies (and from which staged date)? - Do exclusions apply (and can we prove them)? - Are spare parts / repair scenarios treated differently? ## Restricted substances and the unit of control (homogeneous material) Q: What do the thresholds apply to? A: Implement RoHS at the homogeneous material level (the smallest material unit that can't be mechanically separated). That's what supplier evidence and testing should map to. Q: Do we need testing? A: Not always - but you need a defensible verification model. Many companies use risk-based testing on high-risk materials (cables, plastics, coatings) and when suppliers or materials change. Q: What changed with RoHS 3? A: Delegated Directive (EU) 2015/863 added four phthalates (DEHP, BBP, DBP, DIBP) with staged applicability dates. - Restricted substances and thresholds (incl. phthalates) - Supplier evidence model: declarations + test triggers - Change control: when a new part forces re-verification ## Phthalates: the two dates you must enforce (2019 and 2021) Q: When do the phthalates restrictions apply? A: For most EEE, from 22 July 2019; for medical devices and monitoring/control instruments, from 22 July 2021. Q: What about cables and spare parts? A: The legislation includes carve-outs for certain cables/spare parts used to repair/reuse/update equipment placed on the market before the relevant cutover dates (22 July 2019 or 22 July 2021). Implementation tip: run a plastics-and-cables supplier re-declaration wave before each cutover and enforce it as a release gate. - 22 July 2019: phthalates restrictions start for most EEE - 22 July 2021: phthalates restrictions start for medical + monitoring/control - High-risk materials: PVC, flexible polymers, elastomers, adhesives ## Exemptions (Annex III/IV): renewal timing and expiry risk Q: How long do exemptions last? A: RoHS sets maximum validity periods (often up to 5 years; longer for medical/monitoring categories), decided case-by-case and renewable. Q: When must we apply to renew? A: No later than 18 months before the exemption expires. If you apply in time, the exemption remains valid until the Commission decides. Q: What if a renewal is rejected? A: Expect a phase-out window (typically 12 - 18 months after the decision). That lead time is your redesign and supplier qualification runway. - Maintain an exemptions register mapped to SKUs and use-cases - Schedule renewal dossier work >=24 months ahead of expiry - Treat exemptions as expiring risk - not a permanent permission ## Technical documentation, DoC, and CE marking (what authorities ask for) Q: What does an authority request look like? A: Market surveillance authorities can ask for your Declaration of Conformity and technical documentation to substantiate RoHS compliance for a specific model/configuration. Q: What structure should the technical file have? A: EN IEC 63000 is referenced at EU level as a harmonised approach for RoHS technical documentation; build an index that maps each restricted substance to evidence (declarations, tests, exemptions) for each homogeneous material. Q: Can RoHS share a technical file with other CE legislation? A: Yes. Article 13 allows a single technical documentation set where another Union conformity-assessment procedure is at least as stringent. Q: How do we avoid paper compliance? A: Bind evidence to shipped configurations, retain the DoC and technical documentation for 10 years, and enforce change-control triggers for new suppliers, new materials, and new parts. - Technical file index aligned to EN IEC 63000 - Supplier declarations traceable to parts/materials and revisions - Spare parts that are not finished EEE do not follow the same CE-marking and DoC pattern as finished EEE - Audit-ready retrieval: answer authority questions in hours, not weeks *Recommended next step* *Placement: after the FAQ section* ## Use EU RoHS Directive (2011/65/EU) FAQ as a cited research workflow Research Copilot can take EU RoHS Directive (2011/65/EU) FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU RoHS Directive (2011/65/EU) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU RoHS Directive (2011/65/EU) FAQ](/solutions/research-copilot.md): Start from EU RoHS Directive (2011/65/EU) FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU RoHS Directive (2011/65/EU)](/contact.md): Review your current process, evidence gaps, and next steps for EU RoHS Directive (2011/65/EU) FAQ. ## Primary sources - [Directive 2011/65/EU (RoHS 2) consolidated (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02011L0065-20250101&ref=sorena.io) - Primary source for scope, staged applicability dates, exemptions renewal timing, and penalties framework. - [Delegated Directive (EU) 2015/863 (RoHS 3 phthalates) (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L0863&ref=sorena.io) - Adds DEHP, BBP, DBP, and DIBP to Annex II and sets staged applicability dates (2019/2021). - [RoHS FAQ and key guidance (European Commission, DG Environment)](https://environment.ec.europa.eu/system/files/2021-01/FAQ%20key%20guidance%20document%20-%20RoHS.pdf?ref=sorena.io) - Practical Q&A on implementation edge cases and evidence expectations. - [RoHS implementation and exemptions (European Commission, DG Environment)](https://environment.ec.europa.eu/topics/waste-and-recycling/rohs-directive/rohs-directive-implementation_en?ref=sorena.io) - Exemptions process overview and links to current annex content. - [Commission Implementing Decision (EU) 2020/659 - EN IEC 63000 reference (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2020/659/oj?ref=sorena.io) - References EN IEC 63000:2018 for RoHS technical documentation (presumption of conformity via harmonised standard). ## Related Topic Guides - [EU RoHS Timeline: RoHS 1 (2002) -> RoHS 2 (2011/2013) -> Open Scope (2019) -> Phthalates (2019/2021)](/artifacts/eu/rohs-directive/timeline.md): A date-by-date EU RoHS timeline for implementers: RoHS 1 (2002), RoHS 2 recast and transposition (2011 - 2013). - [Restricted Substances and Thresholds | EU RoHS Directive 2011/65/EU | Homogeneous Material Limits (0.1% / 0.01%) + Phthalates (2015/863)](/artifacts/eu/rohs-directive/restricted-substances-and-thresholds.md): A practical RoHS restricted substances guide for Directive 2011/65/EU: the 10 substances in Annex II, homogeneous material threshold logic (0.1% for most. - [RoHS Applicability Test | Is My Product In Scope of EU RoHS Directive 2011/65/EU? | EEE, Cables, Spare Parts, Open Scope](/artifacts/eu/rohs-directive/applicability-test.md): A structured EU RoHS applicability test for Directive 2011/65/EU: determine if your product is electrical and electronic equipment (EEE). - [RoHS Compliance Checklist | EU RoHS Directive 2011/65/EU | Supplier Evidence, Exemptions, EN IEC 63000 Technical File](/artifacts/eu/rohs-directive/checklist.md): An audit-ready RoHS compliance checklist for Directive 2011/65/EU: scope and EEE category mapping. - [RoHS Compliance Program | EU RoHS Directive 2011/65/EU Implementation Playbook | Supplier Controls, Exemptions, Evidence](/artifacts/eu/rohs-directive/compliance.md): A practical RoHS compliance program playbook for Directive 2011/65/EU: set up governance, map homogeneous material risks across your BOM. - [RoHS Deadlines and Compliance Calendar (2013, 2014, 2017, 2019, 2021) | EU RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar.md): A RoHS compliance calendar you can actually operationalize: staged applicability dates (22 July 2014/2017/2019). - [RoHS Enforcement, Penalties, and Fines | EU RoHS Directive 2011/65/EU (Member State rules)](/artifacts/eu/rohs-directive/penalties-and-fines.md): What EU RoHS enforcement looks like in practice: market surveillance checks, documentation requests, CE marking scrutiny. - [RoHS Exemptions Tracker Guide | How to Build an Exemption Register (Annex III/IV), Link to BOM, Monitor Expiry](/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide.md): A practical guide to building a RoHS exemptions tracker: recommended tracker fields (exemption reference, exact wording, scope conditions. - [RoHS Exemptions Tracking | Directive 2011/65/EU Annex III and Annex IV | Expiry Risk, Evidence, Renewal Strategy](/artifacts/eu/rohs-directive/exemptions-tracking.md): A practical RoHS exemptions tracking guide for Directive 2011/65/EU: how Annex III and Annex IV exemptions work. - [RoHS Requirements | EU RoHS Directive 2011/65/EU | Substance Restrictions (Annex II), Exemptions (Annex III/IV), CE Evidence](/artifacts/eu/rohs-directive/requirements.md): A practical RoHS requirements breakdown for Directive 2011/65/EU: restricted substances thresholds in homogeneous materials (Annex II). - [RoHS Supplier Declaration Template | Annex II Substances, Homogeneous Material Coverage, Exemptions Disclosure](/artifacts/eu/rohs-directive/rohs-supplier-declaration-template.md): A practical RoHS supplier declaration template for Directive 2011/65/EU. - [RoHS vs REACH | What's the Difference? | EU RoHS Directive 2011/65/EU vs REACH Regulation (EC) 1907/2006](/artifacts/eu/rohs-directive/rohs-vs-reach.md): A practical RoHS vs REACH guide: RoHS (Directive 2011/65/EU) restricts specific substances in EEE above thresholds in homogeneous materials and is tied to CE. - [Supplier Declarations and Verification | RoHS Compliance Program | Supplier Questionnaires, Change Control, Risk-Based Testing](/artifacts/eu/rohs-directive/supplier-declarations-and-verification.md): A practical supplier evidence playbook for EU RoHS Directive 2011/65/EU. - [Technical Documentation and CE | RoHS Directive 2011/65/EU | EN IEC 63000, EU Declaration of Conformity, Evidence Vault](/artifacts/eu/rohs-directive/technical-documentation-and-ce.md): A practical RoHS technical documentation guide for Directive 2011/65/EU. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/rohs-directive/faq --- --- title: "RoHS Enforcement, Penalties, and Fines" canonical_url: "https://www.sorena.io/artifacts/eu/rohs-directive/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/rohs-directive/penalties-and-fines" author: "Sorena AI" description: "What EU RoHS enforcement looks like in practice: market surveillance checks, documentation requests, CE marking scrutiny." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RoHS enforcement" - "RoHS penalties" - "RoHS fines" - "RoHS market surveillance" - "RoHS CE marking enforcement" - "RoHS technical documentation request" - "Regulation (EU) 2019/1020 market surveillance" - "RoHS audit readiness" - "Market surveillance" - "Technical file readiness" - "CE marking" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RoHS Enforcement, Penalties, and Fines What EU RoHS enforcement looks like in practice: market surveillance checks, documentation requests, CE marking scrutiny. *RoHS* *Enforcement* ## EU RoHS Directive (2011/65/EU) Penalties, fines, and enforcement Penalties are national - but the triggers are predictable. Reduce exposure with a release gate, an evidence pack, and fast response workflows. RoHS is enforced through Member State market surveillance and national penalty regimes. You rarely get fined because RoHS exists. You get fined because you cannot substantiate compliance for the product configuration you placed on the market. This page focuses on the real enforcement mechanics: what authorities ask for, what typically fails, and the controls that cut your penalty exposure. ## How RoHS enforcement works (what happens in reality) RoHS obligations are implemented in national law. Article 23 requires Member States to set effective, proportionate, and dissuasive penalties for infringements. Market surveillance authorities can request your Declaration of Conformity and technical documentation, sample products, and coordinate corrective actions when non-compliance is suspected. Regulation (EU) 2019/1020 is a core cross-cutting enforcement framework for EU product compliance; expect documentation requests to be time-bound and specific to a model/configuration. - Authority request: produce DoC + technical file quickly (and prove it matches the shipped configuration) - Substance failure: lab results contradict declarations (or homogeneous material mapping is missing) - Exemption failure: exemption expired, doesn't match the specific application, or renewal timing wasn't managed - Marking failure: improper CE marking use and inconsistent product documentation *Recommended next step* *Placement: after the enforcement section* ## Use EU RoHS Directive (2011/65/EU) Penalties, fines, and enforcement as a cited research workflow Research Copilot can take EU RoHS Directive (2011/65/EU) Penalties, fines, and enforcement from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU RoHS Directive (2011/65/EU) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU RoHS Directive (2011/65/EU) Penalties, fines, and enforcement](/solutions/research-copilot.md): Start from EU RoHS Directive (2011/65/EU) Penalties, fines, and enforcement and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU RoHS Directive (2011/65/EU)](/contact.md): Review your current process, evidence gaps, and next steps for EU RoHS Directive (2011/65/EU) Penalties, fines, and enforcement. ## What penalties can include (why evidence matters) RoHS requires Member States to set effective, proportionate, and dissuasive penalties for infringements. For serious cases (including improper CE marking use), national penalties can include criminal sanctions. The practical cost is often not only fines: withdrawals, recalls, sales bans, rework, and customer or retailer disruption can exceed any administrative penalty. - Administrative measures: corrective actions, withdrawal from the market, recall obligations - Commercial impact: blocked shipments, retailer delisting, lost tenders - Financial impact: administrative fines (amounts vary by Member State) - Serious infringements: penalties may include criminal sanctions for improper CE-marking use under national law implementation ## The penalty-exposure playbook (controls that prevent escalations) You reduce exposure by making non-compliance hard to ship. That means: supplier evidence as a gate, targeted testing for risk, exemption lifecycle control, and a technical file that is structured and retrievable. If you can answer an authority request quickly and coherently, enforcement often stays in the questions-and-corrective-actions lane instead of the sanctions lane. - Release gate: no ship without DoC + evidence pack tied to the shipped configuration - Supplier controls: declarations + change notifications + audit rights + escalation path - Verification: risk-based testing for high-risk materials and when suppliers/materials change - Exemptions control: register, expiry alerts, renewal dossier readiness, redesign plan - Technical file: EN IEC 63000-aligned index that maps substances -> homogeneous materials -> evidence ## If you receive an authority request (response workflow) Treat requests as incident-like events: assign an owner, freeze the configuration under review, and produce a coherent evidence pack with traceability. Do not assemble evidence from inboxes. Maintain a versioned evidence vault so you can respond consistently and quickly. - Day 0: confirm model/variant identifiers, dates placed on market, and applicable exemptions - Day 1 - 3: provide DoC + technical file index + supplier declarations and tests for the exact configuration - Root cause: if a gap exists, open CAPA and define corrective action (supplier, redesign, withdrawal) - Communications: align legal, product, and customer teams on a single story and action plan ## Primary sources - [Directive 2011/65/EU (RoHS 2) consolidated (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02011L0065-20250101&ref=sorena.io) - Requires Member States to establish penalties; also references penalties for improper CE marking use. - [Regulation (EU) 2019/1020 - market surveillance and compliance of products (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Core market surveillance framework that informs how authorities request and assess technical documentation. - [RoHS FAQ and key guidance (European Commission, DG Environment)](https://environment.ec.europa.eu/system/files/2021-01/FAQ%20key%20guidance%20document%20-%20RoHS.pdf?ref=sorena.io) - Implementation guidance that helps you build defensible evidence and avoid common misinterpretations. - [RoHS implementation and exemptions (European Commission, DG Environment)](https://environment.ec.europa.eu/topics/waste-and-recycling/rohs-directive/rohs-directive-implementation_en?ref=sorena.io) - Exemptions process and operational links for tracking annex changes. - [Commission Implementing Decision (EU) 2020/659 - EN IEC 63000 reference (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2020/659/oj?ref=sorena.io) - References EN IEC 63000:2018 for RoHS technical documentation (helps build audit-ready evidence). ## Related Topic Guides - [EU RoHS FAQ (Scope, Exemptions, Phthalates, Technical File, CE) | RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/faq.md): High-signal EU RoHS FAQ grounded in official sources: what counts as EEE, staged applicability (22 July 2014/2017/2019). - [EU RoHS Timeline: RoHS 1 (2002) -> RoHS 2 (2011/2013) -> Open Scope (2019) -> Phthalates (2019/2021)](/artifacts/eu/rohs-directive/timeline.md): A date-by-date EU RoHS timeline for implementers: RoHS 1 (2002), RoHS 2 recast and transposition (2011 - 2013). - [Restricted Substances and Thresholds | EU RoHS Directive 2011/65/EU | Homogeneous Material Limits (0.1% / 0.01%) + Phthalates (2015/863)](/artifacts/eu/rohs-directive/restricted-substances-and-thresholds.md): A practical RoHS restricted substances guide for Directive 2011/65/EU: the 10 substances in Annex II, homogeneous material threshold logic (0.1% for most. - [RoHS Applicability Test | Is My Product In Scope of EU RoHS Directive 2011/65/EU? | EEE, Cables, Spare Parts, Open Scope](/artifacts/eu/rohs-directive/applicability-test.md): A structured EU RoHS applicability test for Directive 2011/65/EU: determine if your product is electrical and electronic equipment (EEE). - [RoHS Compliance Checklist | EU RoHS Directive 2011/65/EU | Supplier Evidence, Exemptions, EN IEC 63000 Technical File](/artifacts/eu/rohs-directive/checklist.md): An audit-ready RoHS compliance checklist for Directive 2011/65/EU: scope and EEE category mapping. - [RoHS Compliance Program | EU RoHS Directive 2011/65/EU Implementation Playbook | Supplier Controls, Exemptions, Evidence](/artifacts/eu/rohs-directive/compliance.md): A practical RoHS compliance program playbook for Directive 2011/65/EU: set up governance, map homogeneous material risks across your BOM. - [RoHS Deadlines and Compliance Calendar (2013, 2014, 2017, 2019, 2021) | EU RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar.md): A RoHS compliance calendar you can actually operationalize: staged applicability dates (22 July 2014/2017/2019). - [RoHS Exemptions Tracker Guide | How to Build an Exemption Register (Annex III/IV), Link to BOM, Monitor Expiry](/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide.md): A practical guide to building a RoHS exemptions tracker: recommended tracker fields (exemption reference, exact wording, scope conditions. - [RoHS Exemptions Tracking | Directive 2011/65/EU Annex III and Annex IV | Expiry Risk, Evidence, Renewal Strategy](/artifacts/eu/rohs-directive/exemptions-tracking.md): A practical RoHS exemptions tracking guide for Directive 2011/65/EU: how Annex III and Annex IV exemptions work. - [RoHS Requirements | EU RoHS Directive 2011/65/EU | Substance Restrictions (Annex II), Exemptions (Annex III/IV), CE Evidence](/artifacts/eu/rohs-directive/requirements.md): A practical RoHS requirements breakdown for Directive 2011/65/EU: restricted substances thresholds in homogeneous materials (Annex II). - [RoHS Supplier Declaration Template | Annex II Substances, Homogeneous Material Coverage, Exemptions Disclosure](/artifacts/eu/rohs-directive/rohs-supplier-declaration-template.md): A practical RoHS supplier declaration template for Directive 2011/65/EU. - [RoHS vs REACH | What's the Difference? | EU RoHS Directive 2011/65/EU vs REACH Regulation (EC) 1907/2006](/artifacts/eu/rohs-directive/rohs-vs-reach.md): A practical RoHS vs REACH guide: RoHS (Directive 2011/65/EU) restricts specific substances in EEE above thresholds in homogeneous materials and is tied to CE. - [Supplier Declarations and Verification | RoHS Compliance Program | Supplier Questionnaires, Change Control, Risk-Based Testing](/artifacts/eu/rohs-directive/supplier-declarations-and-verification.md): A practical supplier evidence playbook for EU RoHS Directive 2011/65/EU. - [Technical Documentation and CE | RoHS Directive 2011/65/EU | EN IEC 63000, EU Declaration of Conformity, Evidence Vault](/artifacts/eu/rohs-directive/technical-documentation-and-ce.md): A practical RoHS technical documentation guide for Directive 2011/65/EU. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/rohs-directive/penalties-and-fines --- --- title: "RoHS Requirements" canonical_url: "https://www.sorena.io/artifacts/eu/rohs-directive/requirements" source_url: "https://www.sorena.io/artifacts/eu/rohs-directive/requirements" author: "Sorena AI" description: "A practical RoHS requirements breakdown for Directive 2011/65/EU: restricted substances thresholds in homogeneous materials (Annex II)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RoHS requirements" - "Directive 2011/65/EU requirements" - "RoHS Annex II restricted substances" - "RoHS Annex III exemptions" - "RoHS Annex IV exemptions" - "EN IEC 63000 technical documentation" - "CE marking RoHS" - "RoHS" - "Requirements" - "Annex II" - "Exemptions" - "EN IEC 63000" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RoHS Requirements A practical RoHS requirements breakdown for Directive 2011/65/EU: restricted substances thresholds in homogeneous materials (Annex II). *RoHS* *Requirements* ## EU RoHS Directive (2011/65/EU) Requirements RoHS requirements are simple to state and hard to prove without a system. Output: a requirements-to-evidence map you can operationalise across suppliers and SKUs. The core RoHS requirement is a materials requirement: EEE placed on the market must not exceed restricted substance thresholds in homogeneous materials unless a valid exemption applies. The operational requirement is evidence: you must be able to demonstrate compliance with a technical documentation pack and supplier-backed proof. ## 1) Substances restriction requirement (Annex II) EEE must not contain restricted substances above the maximum tolerated values in homogeneous materials. Implementation reality: your unit of control is the homogeneous material, not the part number. - Build a homogeneous-material model in your BOM and link evidence at that level - Maintain a restricted-substances risk map (hotspots like solders, cables, soft plastics) - Use supplier declarations and verification triggers; do not rely on compliant labels *Recommended next step* *Placement: after the requirement breakdown* ## Turn EU RoHS Directive (2011/65/EU) Requirements into an operational assessment Assessment Autopilot can take EU RoHS Directive (2011/65/EU) Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU RoHS Directive (2011/65/EU) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU RoHS Directive (2011/65/EU) Requirements](/solutions/assessment.md): Start from EU RoHS Directive (2011/65/EU) Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU RoHS Directive (2011/65/EU)](/contact.md): Review your current process, evidence gaps, and next steps for EU RoHS Directive (2011/65/EU) Requirements. ## 2) Exemptions logic (Annex III/IV) and expiry risk Exemptions are narrow allowances for specific applications and conditions, often time-limited and revised. The requirement is not to have an exemption, but to prove that the exact application in your product matches the exemption scope and is still valid. - Traceability: exemption -> application -> part/material -> supplier - Expiry monitoring: plan redesign or renewal work 18 - 24 months ahead - Evidence pack: technical justification, supplier confirmations, and release/change control ## 3) Supplier evidence and verification (your control layer) RoHS is enforced through the supply chain: if suppliers can't back their claims, you can't back yours. Implement supplier requirements as contractual and process controls. - Supplier declarations covering Annex II substances and homogeneous material scope - Change notification duties (material, process, formulation, plating, cable insulation changes) - Verification plan: when you test, how you sample, what you do with failures - Traceability: link supplier artifacts to specific SKUs/variants ## 4) Technical documentation and CE evidence (EN IEC 63000) A defensible RoHS program produces a technical documentation pack that is retrievable and consistent. EN IEC 63000 is the harmonised standard referenced for RoHS technical documentation; use it to structure your evidence. Article 13 also allows a single technical documentation set where another applicable Union conformity-assessment procedure is at least as stringent. - Technical file structure aligned to EN IEC 63000: evidence sources, evaluation logic, and conclusions - Evidence artifacts: declarations, test reports, exemption register, change history - Release governance: ensure the technical file matches the shipped configuration and suppliers - Retention: keep the technical documentation and DoC for 10 years and make sure importer copies remain available ## A simple requirements-to-evidence map (what 'done' means) Use this mapping to assign owners and define acceptance criteria. If you can't retrieve these artifacts quickly, your program is not operational. - Scope memo (owner: compliance/engineering): product category, variants, exclusions logic - Substances map (owner: engineering): homogeneous materials + hotspots + acceptance criteria - Supplier evidence pack (owner: procurement/quality): declarations + change controls + traceability - Exemption register (owner: compliance): applicability + expiry + redesign/renewal plan - Technical documentation pack (owner: compliance/QA): EN IEC 63000-aligned file + evidence links ## Primary sources - [Directive 2011/65/EU (RoHS 2) consolidated (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02011L0065-20250101&ref=sorena.io) - Primary source for substance restrictions, exemptions framework, and documentation responsibilities. - [Commission Implementing Decision (EU) 2020/659 - EN IEC 63000 reference (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2020/659/oj?ref=sorena.io) - References EN IEC 63000:2018 for RoHS technical documentation. - [DG GROW - Harmonised standards for RoHS](https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards/restriction-use-certain-hazardous-substances-rohs_en?ref=sorena.io) - Official entry point for harmonised standards supporting RoHS compliance evidence. - [RoHS FAQ and key guidance (DG Environment)](https://environment.ec.europa.eu/system/files/2021-01/FAQ%20key%20guidance%20document%20-%20RoHS.pdf?ref=sorena.io) - Practical Q&A on scope, exclusions, cables, spare parts, and CE expectations. ## Related Topic Guides - [EU RoHS FAQ (Scope, Exemptions, Phthalates, Technical File, CE) | RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/faq.md): High-signal EU RoHS FAQ grounded in official sources: what counts as EEE, staged applicability (22 July 2014/2017/2019). - [EU RoHS Timeline: RoHS 1 (2002) -> RoHS 2 (2011/2013) -> Open Scope (2019) -> Phthalates (2019/2021)](/artifacts/eu/rohs-directive/timeline.md): A date-by-date EU RoHS timeline for implementers: RoHS 1 (2002), RoHS 2 recast and transposition (2011 - 2013). - [Restricted Substances and Thresholds | EU RoHS Directive 2011/65/EU | Homogeneous Material Limits (0.1% / 0.01%) + Phthalates (2015/863)](/artifacts/eu/rohs-directive/restricted-substances-and-thresholds.md): A practical RoHS restricted substances guide for Directive 2011/65/EU: the 10 substances in Annex II, homogeneous material threshold logic (0.1% for most. - [RoHS Applicability Test | Is My Product In Scope of EU RoHS Directive 2011/65/EU? | EEE, Cables, Spare Parts, Open Scope](/artifacts/eu/rohs-directive/applicability-test.md): A structured EU RoHS applicability test for Directive 2011/65/EU: determine if your product is electrical and electronic equipment (EEE). - [RoHS Compliance Checklist | EU RoHS Directive 2011/65/EU | Supplier Evidence, Exemptions, EN IEC 63000 Technical File](/artifacts/eu/rohs-directive/checklist.md): An audit-ready RoHS compliance checklist for Directive 2011/65/EU: scope and EEE category mapping. - [RoHS Compliance Program | EU RoHS Directive 2011/65/EU Implementation Playbook | Supplier Controls, Exemptions, Evidence](/artifacts/eu/rohs-directive/compliance.md): A practical RoHS compliance program playbook for Directive 2011/65/EU: set up governance, map homogeneous material risks across your BOM. - [RoHS Deadlines and Compliance Calendar (2013, 2014, 2017, 2019, 2021) | EU RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar.md): A RoHS compliance calendar you can actually operationalize: staged applicability dates (22 July 2014/2017/2019). - [RoHS Enforcement, Penalties, and Fines | EU RoHS Directive 2011/65/EU (Member State rules)](/artifacts/eu/rohs-directive/penalties-and-fines.md): What EU RoHS enforcement looks like in practice: market surveillance checks, documentation requests, CE marking scrutiny. - [RoHS Exemptions Tracker Guide | How to Build an Exemption Register (Annex III/IV), Link to BOM, Monitor Expiry](/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide.md): A practical guide to building a RoHS exemptions tracker: recommended tracker fields (exemption reference, exact wording, scope conditions. - [RoHS Exemptions Tracking | Directive 2011/65/EU Annex III and Annex IV | Expiry Risk, Evidence, Renewal Strategy](/artifacts/eu/rohs-directive/exemptions-tracking.md): A practical RoHS exemptions tracking guide for Directive 2011/65/EU: how Annex III and Annex IV exemptions work. - [RoHS Supplier Declaration Template | Annex II Substances, Homogeneous Material Coverage, Exemptions Disclosure](/artifacts/eu/rohs-directive/rohs-supplier-declaration-template.md): A practical RoHS supplier declaration template for Directive 2011/65/EU. - [RoHS vs REACH | What's the Difference? | EU RoHS Directive 2011/65/EU vs REACH Regulation (EC) 1907/2006](/artifacts/eu/rohs-directive/rohs-vs-reach.md): A practical RoHS vs REACH guide: RoHS (Directive 2011/65/EU) restricts specific substances in EEE above thresholds in homogeneous materials and is tied to CE. - [Supplier Declarations and Verification | RoHS Compliance Program | Supplier Questionnaires, Change Control, Risk-Based Testing](/artifacts/eu/rohs-directive/supplier-declarations-and-verification.md): A practical supplier evidence playbook for EU RoHS Directive 2011/65/EU. - [Technical Documentation and CE | RoHS Directive 2011/65/EU | EN IEC 63000, EU Declaration of Conformity, Evidence Vault](/artifacts/eu/rohs-directive/technical-documentation-and-ce.md): A practical RoHS technical documentation guide for Directive 2011/65/EU. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/rohs-directive/requirements --- --- title: "Restricted Substances and Thresholds" canonical_url: "https://www.sorena.io/artifacts/eu/rohs-directive/restricted-substances-and-thresholds" source_url: "https://www.sorena.io/artifacts/eu/rohs-directive/restricted-substances-and-thresholds" author: "Sorena AI" description: "A practical RoHS restricted substances guide for Directive 2011/65/EU: the 10 substances in Annex II, homogeneous material threshold logic (0.1% for most." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RoHS restricted substances list" - "RoHS thresholds 0.1% homogeneous material" - "RoHS cadmium 0.01%" - "RoHS phthalates 2015/863 DEHP BBP DBP DIBP" - "EN IEC 63000 RoHS documentation" - "IEC 62321 RoHS testing" - "RoHS" - "Restricted substances" - "Homogeneous material" - "Phthalates" - "EN IEC 63000" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Restricted Substances and Thresholds A practical RoHS restricted substances guide for Directive 2011/65/EU: the 10 substances in Annex II, homogeneous material threshold logic (0.1% for most. *Annex II* *Thresholds* ## EU RoHS Directive (2011/65/EU) Restricted Substances and Thresholds 10 substances, 2 key thresholds, and the BOM reality behind them. Output: a restricted-substances risk map + evidence rules you can enforce on suppliers. RoHS compliance is measured at the homogeneous material level. That means a product-level compliant claim is never enough; you need a repeatable way to prove that each high-risk homogeneous material in your BOM meets the thresholds or is covered by a valid exemption. ## The RoHS thresholds (homogeneous material is the unit of control) Directive 2011/65/EU restricts substances in EEE when the concentration exceeds the maximum tolerated value in homogeneous materials. In practice, you need a design rule: define homogeneous materials in your BOM model (not just part numbers) and attach evidence at that level. - General threshold: 0.1% by weight in homogeneous material - Cadmium threshold: 0.01% by weight in homogeneous material - Homogeneous material means one material of uniform composition or a material that cannot be separated into different materials by mechanical actions - Evidence approach: supplier declarations + risk-based testing + technical documentation aligned to EN IEC 63000 *Recommended next step* *Placement: after the scope or definition section* ## Use EU RoHS Directive (2011/65/EU) Restricted Substances and Thresholds as a cited research workflow Research Copilot can take EU RoHS Directive (2011/65/EU) Restricted Substances and Thresholds from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU RoHS Directive (2011/65/EU) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU RoHS Directive (2011/65/EU) Restricted Substances and Thresholds](/solutions/research-copilot.md): Start from EU RoHS Directive (2011/65/EU) Restricted Substances and Thresholds and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU RoHS Directive (2011/65/EU)](/contact.md): Review your current process, evidence gaps, and next steps for EU RoHS Directive (2011/65/EU) Restricted Substances and Thresholds. ## The 10 restricted substances (Annex II) RoHS currently restricts six classic substances and four phthalates added by (EU) 2015/863. Treat this list as a procurement control: every supplier should be able to answer where these substances can appear in their materials. - Lead (Pb) - 0.1% - Mercury (Hg) - 0.1% - Cadmium (Cd) - 0.01% - Hexavalent chromium (Cr(VI)) - 0.1% - PBB - 0.1% - PBDE - 0.1% - DEHP - 0.1% - BBP - 0.1% - DBP - 0.1% - DIBP - 0.1% ## Where these substances hide in real BOMs (high-risk hotspots) Most RoHS failures come from predictable hotspots: solders, platings, cables, pigments, soft plastics, and legacy components. Use this list to prioritise evidence depth and decide where testing is worth the cost. - Solders and terminations: lead in solders; legacy components and rework - Platings and coatings: hexavalent chromium processes and surface treatments - Cables and wire insulation: plasticisers (phthalates) and pigments - Plastics and elastomers: phthalates as plasticisers; brominated flame retardants in legacy polymers - Displays and lamps: mercury historically (validate supplier controls for any relevant components) ## Phthalates: the implementation reality (EU) 2015/863 The phthalates restriction applies from 22 July 2019 for most EEE and from 22 July 2021 for medical devices and monitoring/control instruments (including industrial). Your program should separate: (1) phthalate exposure mapping and (2) spare parts/cables carve-outs for repair/reuse of older equipment. - Applies from 22 Jul 2019 (most EEE): DEHP, BBP, DBP, DIBP - Applies from 22 Jul 2021 (medical devices and monitoring/control): same four phthalates - Carve-out: cables/spare parts for repair/reuse/updating of equipment placed on the market before the applicable dates ## Evidence strategy: declarations, testing, and EN IEC 63000 documentation Declarations alone can be sufficient for low-risk materials and stable suppliers, but you need verification triggers for high-risk cases. EN IEC 63000 is the harmonised standard for RoHS technical documentation; use it to structure your file and avoid ad-hoc evidence formats. - Supplier declarations: substances list + homogeneous material coverage + change-notification duty - Risk-based testing: trigger tests for high-risk materials, supplier changes, or inconsistent declarations (use IEC 62321 methods as appropriate) - Technical documentation: maintain an EN IEC 63000-aligned evidence pack per product family and variant ## Primary sources - [Directive 2011/65/EU (RoHS 2) consolidated (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02011L0065-20250101&ref=sorena.io) - Primary source for Annex II restricted substances, threshold logic, and scope/exemptions framework. - [Delegated Directive (EU) 2015/863 (phthalates) (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L0863&ref=sorena.io) - Adds four phthalates to Annex II and defines the application dates (22 Jul 2019; 22 Jul 2021 for specific categories). - [Commission Implementing Decision (EU) 2020/659 - EN IEC 63000 reference (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2020/659/oj?ref=sorena.io) - Publishes the reference of EN IEC 63000:2018 for RoHS technical documentation. - [DG Environment - RoHS Directive overview](https://environment.ec.europa.eu/topics/waste-and-recycling/rohs-directive_en?ref=sorena.io) - Official overview and links to implementation resources. ## Related Topic Guides - [EU RoHS FAQ (Scope, Exemptions, Phthalates, Technical File, CE) | RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/faq.md): High-signal EU RoHS FAQ grounded in official sources: what counts as EEE, staged applicability (22 July 2014/2017/2019). - [EU RoHS Timeline: RoHS 1 (2002) -> RoHS 2 (2011/2013) -> Open Scope (2019) -> Phthalates (2019/2021)](/artifacts/eu/rohs-directive/timeline.md): A date-by-date EU RoHS timeline for implementers: RoHS 1 (2002), RoHS 2 recast and transposition (2011 - 2013). - [RoHS Applicability Test | Is My Product In Scope of EU RoHS Directive 2011/65/EU? | EEE, Cables, Spare Parts, Open Scope](/artifacts/eu/rohs-directive/applicability-test.md): A structured EU RoHS applicability test for Directive 2011/65/EU: determine if your product is electrical and electronic equipment (EEE). - [RoHS Compliance Checklist | EU RoHS Directive 2011/65/EU | Supplier Evidence, Exemptions, EN IEC 63000 Technical File](/artifacts/eu/rohs-directive/checklist.md): An audit-ready RoHS compliance checklist for Directive 2011/65/EU: scope and EEE category mapping. - [RoHS Compliance Program | EU RoHS Directive 2011/65/EU Implementation Playbook | Supplier Controls, Exemptions, Evidence](/artifacts/eu/rohs-directive/compliance.md): A practical RoHS compliance program playbook for Directive 2011/65/EU: set up governance, map homogeneous material risks across your BOM. - [RoHS Deadlines and Compliance Calendar (2013, 2014, 2017, 2019, 2021) | EU RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar.md): A RoHS compliance calendar you can actually operationalize: staged applicability dates (22 July 2014/2017/2019). - [RoHS Enforcement, Penalties, and Fines | EU RoHS Directive 2011/65/EU (Member State rules)](/artifacts/eu/rohs-directive/penalties-and-fines.md): What EU RoHS enforcement looks like in practice: market surveillance checks, documentation requests, CE marking scrutiny. - [RoHS Exemptions Tracker Guide | How to Build an Exemption Register (Annex III/IV), Link to BOM, Monitor Expiry](/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide.md): A practical guide to building a RoHS exemptions tracker: recommended tracker fields (exemption reference, exact wording, scope conditions. - [RoHS Exemptions Tracking | Directive 2011/65/EU Annex III and Annex IV | Expiry Risk, Evidence, Renewal Strategy](/artifacts/eu/rohs-directive/exemptions-tracking.md): A practical RoHS exemptions tracking guide for Directive 2011/65/EU: how Annex III and Annex IV exemptions work. - [RoHS Requirements | EU RoHS Directive 2011/65/EU | Substance Restrictions (Annex II), Exemptions (Annex III/IV), CE Evidence](/artifacts/eu/rohs-directive/requirements.md): A practical RoHS requirements breakdown for Directive 2011/65/EU: restricted substances thresholds in homogeneous materials (Annex II). - [RoHS Supplier Declaration Template | Annex II Substances, Homogeneous Material Coverage, Exemptions Disclosure](/artifacts/eu/rohs-directive/rohs-supplier-declaration-template.md): A practical RoHS supplier declaration template for Directive 2011/65/EU. - [RoHS vs REACH | What's the Difference? | EU RoHS Directive 2011/65/EU vs REACH Regulation (EC) 1907/2006](/artifacts/eu/rohs-directive/rohs-vs-reach.md): A practical RoHS vs REACH guide: RoHS (Directive 2011/65/EU) restricts specific substances in EEE above thresholds in homogeneous materials and is tied to CE. - [Supplier Declarations and Verification | RoHS Compliance Program | Supplier Questionnaires, Change Control, Risk-Based Testing](/artifacts/eu/rohs-directive/supplier-declarations-and-verification.md): A practical supplier evidence playbook for EU RoHS Directive 2011/65/EU. - [Technical Documentation and CE | RoHS Directive 2011/65/EU | EN IEC 63000, EU Declaration of Conformity, Evidence Vault](/artifacts/eu/rohs-directive/technical-documentation-and-ce.md): A practical RoHS technical documentation guide for Directive 2011/65/EU. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/rohs-directive/restricted-substances-and-thresholds --- --- title: "RoHS Exemptions Tracker Guide" canonical_url: "https://www.sorena.io/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide" source_url: "https://www.sorena.io/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide" author: "Sorena AI" description: "A practical guide to building a RoHS exemptions tracker: recommended tracker fields (exemption reference, exact wording, scope conditions." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RoHS exemption tracker" - "RoHS exemption register" - "Annex III exemption tracking" - "Annex IV exemption tracking" - "RoHS exemption expiry monitoring" - "oeko RoHS exemptions tracker" - "RoHS" - "Exemptions" - "Tracker" - "Annex III" - "Annex IV" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RoHS Exemptions Tracker Guide A practical guide to building a RoHS exemptions tracker: recommended tracker fields (exemption reference, exact wording, scope conditions. *Tracker* *Exemptions* ## EU RoHS Directive (2011/65/EU) Exemptions Tracker Guide A tracker model you can actually operate. Output: an exemption register tied to parts, materials, suppliers, and redesign decisions. A RoHS exemptions tracker is a compliance-critical system of record. It prevents two expensive failures: (1) using an exemption outside its scope, and (2) discovering expiry too late to redesign. This guide gives you a tracker schema and an operating cadence. ## Tracker schema (recommended columns) The tracker must support traceability and decisions. Keep it structured and enforceable. One row should represent one exemption 'use case' (exemption + application + product context), not just one exemption ID. - Exemption reference: Annex (III/IV), exemption number/reference, exact wording (copy from official text) - Scope conditions: equipment category constraints, application constraints, material constraints - Affected substance(s): which Annex II substance is allowed under the exemption - Where used: product family, SKU/variant, part number, homogeneous material, location in assembly - Supply chain: supplier(s), manufacturing site(s), sub-tier dependency, alternative parts - Validity: start date, expiry/review date, renewal status, sunset risk level - Decision: renew vs redesign vs dual-source vs discontinue, with owner and target date - Evidence links: technical justification, supplier confirmations, test reports, change logs ## Operating cadence (how to run the tracker) The tracker only works if it is reviewed on a cadence and connected to release/change control. Define 'triggers' that force review: supplier changes, product redesigns, and exemption updates. - Monthly: review expiries within 24 months and open redesign or renewal work items - Quarterly: validate high-risk exemptions with suppliers and refresh evidence - Per release: check whether any BOM change impacts exemption use cases - Per supplier change: require re-confirmation of exemption scope and evidence - Per renewal: file no later than 18 months before expiry and track the Commission decision timeline ## Link the tracker to BOM and technical documentation Exemptions must be defendable at homogeneous material level, so the tracker should link to the BOM model at that level. Store the tracker output as part of your EN IEC 63000-aligned technical documentation pack. - BOM linkage: part -> material -> exemption use case - Evidence vault linkage: each tracker row links to the evidence pack folder - DoC/technical file consistency: ensure exemptions evidence is consistent with declarations and test results ## Where to monitor updates Use a two-layer approach: (1) official EU sources for legal certainty and (2) practical databases to track status changes faster. Always validate decisions against official acts before release decisions. - Official: DG Environment RoHS implementation resources and EUR-Lex texts - Practical: Oeko-Institut RoHS exemptions database for status/history tracking - Internal: change control system and product roadmap integration ## Decision playbook (renew vs redesign) A good tracker forces a decision early. Treat exemptions as temporary risk acceptance. The earlier you choose a redesign path, the less you pay in certification and supplier churn. - Renewal path: evidence update + supplier confirmations + monitoring until decision is final; current Commission guidance says decisions take about 18 to 24 months - Continuity path: if renewal is filed in time, the existing exemption remains valid until the Commission decides - Redesign path: alternative material/process qualification + validation + technical file updates - Dual-source path: qualify an exemption-free alternative while maintaining current supply - Kill path: discontinue SKU or market variant if redesign is not feasible - Fallback if rejected: use the 12 to 18 month transition window to complete the redesign and draw down inventory *Recommended next step* *Placement: after the scope or definition section* ## Use EU RoHS Directive (2011/65/EU) Exemptions Tracker Guide as a cited research workflow Research Copilot can take EU RoHS Directive (2011/65/EU) Exemptions Tracker Guide from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU RoHS Directive (2011/65/EU) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU RoHS Directive (2011/65/EU) Exemptions Tracker Guide](/solutions/research-copilot.md): Start from EU RoHS Directive (2011/65/EU) Exemptions Tracker Guide and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU RoHS Directive (2011/65/EU)](/contact.md): Review your current process, evidence gaps, and next steps for EU RoHS Directive (2011/65/EU) Exemptions Tracker Guide. ## Primary sources - [Directive 2011/65/EU (RoHS 2) consolidated (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02011L0065-20250101&ref=sorena.io) - Primary source for exemption framework and annex structure. - [DG Environment - RoHS Directive implementation (exemption procedure)](https://environment.ec.europa.eu/topics/waste-and-recycling/rohs-directive/rohs-directive-implementation_en?ref=sorena.io) - Official overview and implementation context for exemption management. - [RoHS exemptions database (Oeko-Institut)](https://rohs.exemptions.oeko.info/?ref=sorena.io) - Operationally useful tracker for exemption status and history; confirm legal text via EUR-Lex. ## Related Topic Guides - [EU RoHS FAQ (Scope, Exemptions, Phthalates, Technical File, CE) | RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/faq.md): High-signal EU RoHS FAQ grounded in official sources: what counts as EEE, staged applicability (22 July 2014/2017/2019). - [EU RoHS Timeline: RoHS 1 (2002) -> RoHS 2 (2011/2013) -> Open Scope (2019) -> Phthalates (2019/2021)](/artifacts/eu/rohs-directive/timeline.md): A date-by-date EU RoHS timeline for implementers: RoHS 1 (2002), RoHS 2 recast and transposition (2011 - 2013). - [Restricted Substances and Thresholds | EU RoHS Directive 2011/65/EU | Homogeneous Material Limits (0.1% / 0.01%) + Phthalates (2015/863)](/artifacts/eu/rohs-directive/restricted-substances-and-thresholds.md): A practical RoHS restricted substances guide for Directive 2011/65/EU: the 10 substances in Annex II, homogeneous material threshold logic (0.1% for most. - [RoHS Applicability Test | Is My Product In Scope of EU RoHS Directive 2011/65/EU? | EEE, Cables, Spare Parts, Open Scope](/artifacts/eu/rohs-directive/applicability-test.md): A structured EU RoHS applicability test for Directive 2011/65/EU: determine if your product is electrical and electronic equipment (EEE). - [RoHS Compliance Checklist | EU RoHS Directive 2011/65/EU | Supplier Evidence, Exemptions, EN IEC 63000 Technical File](/artifacts/eu/rohs-directive/checklist.md): An audit-ready RoHS compliance checklist for Directive 2011/65/EU: scope and EEE category mapping. - [RoHS Compliance Program | EU RoHS Directive 2011/65/EU Implementation Playbook | Supplier Controls, Exemptions, Evidence](/artifacts/eu/rohs-directive/compliance.md): A practical RoHS compliance program playbook for Directive 2011/65/EU: set up governance, map homogeneous material risks across your BOM. - [RoHS Deadlines and Compliance Calendar (2013, 2014, 2017, 2019, 2021) | EU RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar.md): A RoHS compliance calendar you can actually operationalize: staged applicability dates (22 July 2014/2017/2019). - [RoHS Enforcement, Penalties, and Fines | EU RoHS Directive 2011/65/EU (Member State rules)](/artifacts/eu/rohs-directive/penalties-and-fines.md): What EU RoHS enforcement looks like in practice: market surveillance checks, documentation requests, CE marking scrutiny. - [RoHS Exemptions Tracking | Directive 2011/65/EU Annex III and Annex IV | Expiry Risk, Evidence, Renewal Strategy](/artifacts/eu/rohs-directive/exemptions-tracking.md): A practical RoHS exemptions tracking guide for Directive 2011/65/EU: how Annex III and Annex IV exemptions work. - [RoHS Requirements | EU RoHS Directive 2011/65/EU | Substance Restrictions (Annex II), Exemptions (Annex III/IV), CE Evidence](/artifacts/eu/rohs-directive/requirements.md): A practical RoHS requirements breakdown for Directive 2011/65/EU: restricted substances thresholds in homogeneous materials (Annex II). - [RoHS Supplier Declaration Template | Annex II Substances, Homogeneous Material Coverage, Exemptions Disclosure](/artifacts/eu/rohs-directive/rohs-supplier-declaration-template.md): A practical RoHS supplier declaration template for Directive 2011/65/EU. - [RoHS vs REACH | What's the Difference? | EU RoHS Directive 2011/65/EU vs REACH Regulation (EC) 1907/2006](/artifacts/eu/rohs-directive/rohs-vs-reach.md): A practical RoHS vs REACH guide: RoHS (Directive 2011/65/EU) restricts specific substances in EEE above thresholds in homogeneous materials and is tied to CE. - [Supplier Declarations and Verification | RoHS Compliance Program | Supplier Questionnaires, Change Control, Risk-Based Testing](/artifacts/eu/rohs-directive/supplier-declarations-and-verification.md): A practical supplier evidence playbook for EU RoHS Directive 2011/65/EU. - [Technical Documentation and CE | RoHS Directive 2011/65/EU | EN IEC 63000, EU Declaration of Conformity, Evidence Vault](/artifacts/eu/rohs-directive/technical-documentation-and-ce.md): A practical RoHS technical documentation guide for Directive 2011/65/EU. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide --- --- title: "RoHS Supplier Declaration Template" canonical_url: "https://www.sorena.io/artifacts/eu/rohs-directive/rohs-supplier-declaration-template" source_url: "https://www.sorena.io/artifacts/eu/rohs-directive/rohs-supplier-declaration-template" author: "Sorena AI" description: "A practical RoHS supplier declaration template for Directive 2011/65/EU." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RoHS supplier declaration template" - "RoHS declaration homogeneous material" - "RoHS Annex II declaration" - "RoHS exemptions disclosure" - "RoHS change notification supplier" - "EN IEC 63000 supplier evidence" - "RoHS" - "Supplier declaration" - "Template" - "Homogeneous material" - "Exemptions" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RoHS Supplier Declaration Template A practical RoHS supplier declaration template for Directive 2011/65/EU. *Template* *Suppliers* ## EU RoHS Directive (2011/65/EU) Supplier Declaration Template A declaration that maps to how RoHS is measured. Output: a supplier statement that is traceable to parts, homogeneous materials, and exemptions (if any). Most RoHS declarations are not defensible because they do not state what is covered. This template fixes that: it forces scope, homogeneous material coverage, exemptions disclosure, and a change notification commitment. ## How to use this template Send this template to suppliers for parts, materials, and subassemblies used in your EEE. Require a declaration per part family (or per material family) and tie it to part numbers and revision identifiers. - Use for: components, cable assemblies, plastics, coatings, solders, and subassemblies - Tie to: part numbers + supplier revision + date + manufacturing site(s) - Store in: your EN IEC 63000-aligned technical documentation evidence vault *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU RoHS Directive (2011/65/EU) Supplier Declaration Template in one governed evidence system SSOT can take EU RoHS Directive (2011/65/EU) Supplier Declaration Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU RoHS Directive (2011/65/EU) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU RoHS Directive (2011/65/EU) Supplier Declaration Template](/solutions/ssot.md): Start from EU RoHS Directive (2011/65/EU) Supplier Declaration Template and keep documents, evidence, and control records in one governed system. - [Talk through EU RoHS Directive (2011/65/EU)](/contact.md): Review your current process, evidence gaps, and next steps for EU RoHS Directive (2011/65/EU) Supplier Declaration Template. ## Template - supplier declaration (recommended fields) Below is a field list you can implement as a PDF, portal form, or contract annex. The key is specificity: what parts, what materials, what revisions, and what evidence. - Supplier identity: legal entity, address, contact, manufacturing site(s) - Covered items: part numbers, descriptions, revisions, date codes / lot range (if relevant) - Homogeneous materials statement: declaration applies at homogeneous material level for covered items - Annex II substances statement: concentrations below thresholds (0.1% generally; 0.01% cadmium) in homogeneous materials - Phthalates statement: DEHP/BBP/DBP/DIBP coverage for relevant polymers and cable insulation - Exemptions disclosure (if any): exact exemption reference, scope conditions, and which parts/materials rely on it - Change notification commitment: prior notice for material/process/sub-tier supplier changes - Document-control fields: issue date, version, and planned review date - Signature and authority: signer role/title and date ## Recommended attachments (make it verifiable) Attachments are optional for low-risk items, but required for high-risk hotspots or when exemptions are used. Define attachment rules by risk tier so suppliers aren't overwhelmed but you still get defensible evidence. - Material composition details for high-risk materials (polymers, coatings, solders) - Test reports or certificates where appropriate (especially for soft plastics/cable insulation and legacy materials) - Exemption evidence pack: technical justification and scope mapping - Internal supplier QA statement on change control and traceability ## Verification triggers (when you test anyway) A declaration is not the end of control. Define when you verify and what happens when results conflict. This protects you against silent changes. - Trigger verification on: new supplier, material change, process change, or inconsistent declarations - Target testing on homogeneous materials (not whole assemblies) - Define actions: quarantine, supplier corrective action, requalification, redesign decision ## Primary sources - [Directive 2011/65/EU (RoHS 2) consolidated (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02011L0065-20250101&ref=sorena.io) - Primary source for Annex II substances and compliance measurement principles (homogeneous materials). - [Commission Implementing Decision (EU) 2020/659 - EN IEC 63000 reference (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2020/659/oj?ref=sorena.io) - References EN IEC 63000:2018 for RoHS technical documentation and evidence sources. - [DG Environment - RoHS Directive overview](https://environment.ec.europa.eu/topics/waste-and-recycling/rohs-directive_en?ref=sorena.io) - Official overview and related resources. ## Related Topic Guides - [EU RoHS FAQ (Scope, Exemptions, Phthalates, Technical File, CE) | RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/faq.md): High-signal EU RoHS FAQ grounded in official sources: what counts as EEE, staged applicability (22 July 2014/2017/2019). - [EU RoHS Timeline: RoHS 1 (2002) -> RoHS 2 (2011/2013) -> Open Scope (2019) -> Phthalates (2019/2021)](/artifacts/eu/rohs-directive/timeline.md): A date-by-date EU RoHS timeline for implementers: RoHS 1 (2002), RoHS 2 recast and transposition (2011 - 2013). - [Restricted Substances and Thresholds | EU RoHS Directive 2011/65/EU | Homogeneous Material Limits (0.1% / 0.01%) + Phthalates (2015/863)](/artifacts/eu/rohs-directive/restricted-substances-and-thresholds.md): A practical RoHS restricted substances guide for Directive 2011/65/EU: the 10 substances in Annex II, homogeneous material threshold logic (0.1% for most. - [RoHS Applicability Test | Is My Product In Scope of EU RoHS Directive 2011/65/EU? | EEE, Cables, Spare Parts, Open Scope](/artifacts/eu/rohs-directive/applicability-test.md): A structured EU RoHS applicability test for Directive 2011/65/EU: determine if your product is electrical and electronic equipment (EEE). - [RoHS Compliance Checklist | EU RoHS Directive 2011/65/EU | Supplier Evidence, Exemptions, EN IEC 63000 Technical File](/artifacts/eu/rohs-directive/checklist.md): An audit-ready RoHS compliance checklist for Directive 2011/65/EU: scope and EEE category mapping. - [RoHS Compliance Program | EU RoHS Directive 2011/65/EU Implementation Playbook | Supplier Controls, Exemptions, Evidence](/artifacts/eu/rohs-directive/compliance.md): A practical RoHS compliance program playbook for Directive 2011/65/EU: set up governance, map homogeneous material risks across your BOM. - [RoHS Deadlines and Compliance Calendar (2013, 2014, 2017, 2019, 2021) | EU RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar.md): A RoHS compliance calendar you can actually operationalize: staged applicability dates (22 July 2014/2017/2019). - [RoHS Enforcement, Penalties, and Fines | EU RoHS Directive 2011/65/EU (Member State rules)](/artifacts/eu/rohs-directive/penalties-and-fines.md): What EU RoHS enforcement looks like in practice: market surveillance checks, documentation requests, CE marking scrutiny. - [RoHS Exemptions Tracker Guide | How to Build an Exemption Register (Annex III/IV), Link to BOM, Monitor Expiry](/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide.md): A practical guide to building a RoHS exemptions tracker: recommended tracker fields (exemption reference, exact wording, scope conditions. - [RoHS Exemptions Tracking | Directive 2011/65/EU Annex III and Annex IV | Expiry Risk, Evidence, Renewal Strategy](/artifacts/eu/rohs-directive/exemptions-tracking.md): A practical RoHS exemptions tracking guide for Directive 2011/65/EU: how Annex III and Annex IV exemptions work. - [RoHS Requirements | EU RoHS Directive 2011/65/EU | Substance Restrictions (Annex II), Exemptions (Annex III/IV), CE Evidence](/artifacts/eu/rohs-directive/requirements.md): A practical RoHS requirements breakdown for Directive 2011/65/EU: restricted substances thresholds in homogeneous materials (Annex II). - [RoHS vs REACH | What's the Difference? | EU RoHS Directive 2011/65/EU vs REACH Regulation (EC) 1907/2006](/artifacts/eu/rohs-directive/rohs-vs-reach.md): A practical RoHS vs REACH guide: RoHS (Directive 2011/65/EU) restricts specific substances in EEE above thresholds in homogeneous materials and is tied to CE. - [Supplier Declarations and Verification | RoHS Compliance Program | Supplier Questionnaires, Change Control, Risk-Based Testing](/artifacts/eu/rohs-directive/supplier-declarations-and-verification.md): A practical supplier evidence playbook for EU RoHS Directive 2011/65/EU. - [Technical Documentation and CE | RoHS Directive 2011/65/EU | EN IEC 63000, EU Declaration of Conformity, Evidence Vault](/artifacts/eu/rohs-directive/technical-documentation-and-ce.md): A practical RoHS technical documentation guide for Directive 2011/65/EU. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/rohs-directive/rohs-supplier-declaration-template --- --- title: "RoHS vs REACH" canonical_url: "https://www.sorena.io/artifacts/eu/rohs-directive/rohs-vs-reach" source_url: "https://www.sorena.io/artifacts/eu/rohs-directive/rohs-vs-reach" author: "Sorena AI" description: "A practical RoHS vs REACH guide: RoHS (Directive 2011/65/EU) restricts specific substances in EEE above thresholds in homogeneous materials and is tied to CE." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RoHS vs REACH" - "Directive 2011/65/EU vs Regulation 1907/2006" - "RoHS homogeneous material threshold" - "REACH SVHC communication" - "RoHS CE marking" - "EN IEC 63000 RoHS documentation" - "phthalates RoHS REACH" - "RoHS" - "REACH" - "Restricted substances" - "SVHC" - "Supplier evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # RoHS vs REACH A practical RoHS vs REACH guide: RoHS (Directive 2011/65/EU) restricts specific substances in EEE above thresholds in homogeneous materials and is tied to CE. *RoHS vs REACH* *EU* ## EU chemicals and product compliance RoHS vs REACH Different scopes, one supply chain. Use this page to separate obligations while sharing evidence and controls. RoHS and REACH are often confused because they both deal with hazardous substances. The fastest implementation approach is: keep the legal scopes separate, but build one shared supplier evidence backbone that can generate RoHS technical documentation and support REACH-related disclosures where relevant. ## Scope in one sentence RoHS is a product rule for electrical and electronic equipment (EEE): it restricts specific substances above thresholds in homogeneous materials and is tied to CE evidence and technical documentation. REACH is broader chemicals legislation covering substances, mixtures and articles through registration, authorisation, restriction, and SVHC communication obligations. - RoHS: EEE focus + Annex II substance thresholds + exemptions - REACH: chemicals lifecycle rules + restrictions and information duties - If you sell EEE, you may need both - but the evidence outputs differ ## Unit of control: homogeneous material vs article/chemical concepts RoHS compliance is assessed at the homogeneous material level (the part of the product that cannot be mechanically disjointed). REACH uses different concepts (substances/mixtures/articles) and different compliance mechanisms (e.g., restrictions and SVHC communication thresholds). - RoHS: thresholds applied to homogeneous materials in EEE - REACH: obligations depend on substance identity and use; article obligations can depend on SVHC concentration and tonnage/notification conditions - Practical takeaway: model your BOM to support both perspectives (material composition + article structure) *Recommended next step* *Placement: after the comparison section* ## Use EU chemicals and product compliance RoHS vs REACH as a cited research workflow Research Copilot can take EU chemicals and product compliance RoHS vs REACH from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU chemicals and product compliance can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU chemicals and product compliance RoHS vs REACH](/solutions/research-copilot.md): Start from EU chemicals and product compliance RoHS vs REACH and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU chemicals and product compliance](/contact.md): Review your current process, evidence gaps, and next steps for EU chemicals and product compliance RoHS vs REACH. ## Overlap: substances and supply chain evidence Substances can be regulated under both regimes (e.g., certain phthalates are SVHCs and also restricted in RoHS for EEE). The overlap is operational: supplier declarations, composition data, and change control. The overlap is also legal: Article 5 exemption decisions and Article 6 substance reviews under RoHS are supposed to stay coherent with REACH and should not weaken the environmental and health protection afforded by REACH. - Phthalates: added to RoHS Annex II by (EU) 2015/863; also regulated under REACH for some uses - Evidence backbone: supplier composition and restricted substances disclosures - Change control: prevent silent formulation changes in plastics, coatings, solders, and cable insulation - Exemptions are different: a RoHS Annex III or IV exemption does not remove separate REACH duties ## Different outputs (don't mix them up) RoHS deliverables are CE-facing and product-specific: technical documentation (often EN IEC 63000-aligned), exemption register, and evidence per product family and variant. REACH deliverables are chemicals-facing: restrictions compliance and information/communication obligations where relevant. - RoHS outputs: restricted substances evidence + exemptions tracking + EN IEC 63000 technical documentation - REACH outputs: restriction compliance evaluation + SVHC communication logic (where applicable) - One shared system: store composition and supplier evidence once; generate outputs for each regime ## One combined program architecture (recommended) Treat your supplier evidence and BOM model as the shared foundation. Then run two compliance 'views': RoHS view for EEE restrictions and evidence, and REACH view for chemicals obligations. - Shared data: composition, material declarations, exemptions used, test results, supplier change history - RoHS view: homogeneous material thresholds and EN IEC 63000 technical file - REACH view: substance identity and restrictions/SVHC communication where relevant - Governance: one change control that triggers both views when materials change ## Primary sources - [Directive 2011/65/EU (RoHS 2) consolidated (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02011L0065-20250101&ref=sorena.io) - Primary source for RoHS scope, Annex II thresholds and exemptions framework. - [Delegated Directive (EU) 2015/863 (phthalates) (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L0863&ref=sorena.io) - Adds four phthalates to RoHS Annex II and defines application dates. - [REACH Regulation (EC) No 1907/2006 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2006/1907/oj?ref=sorena.io) - Primary source for REACH registration/authorisation/restriction framework and article-related information duties. - [Commission Implementing Decision (EU) 2020/659 - EN IEC 63000 reference (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2020/659/oj?ref=sorena.io) - References EN IEC 63000 for structuring RoHS technical documentation. ## Related Topic Guides - [EU RoHS FAQ (Scope, Exemptions, Phthalates, Technical File, CE) | RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/faq.md): High-signal EU RoHS FAQ grounded in official sources: what counts as EEE, staged applicability (22 July 2014/2017/2019). - [EU RoHS Timeline: RoHS 1 (2002) -> RoHS 2 (2011/2013) -> Open Scope (2019) -> Phthalates (2019/2021)](/artifacts/eu/rohs-directive/timeline.md): A date-by-date EU RoHS timeline for implementers: RoHS 1 (2002), RoHS 2 recast and transposition (2011 - 2013). - [Restricted Substances and Thresholds | EU RoHS Directive 2011/65/EU | Homogeneous Material Limits (0.1% / 0.01%) + Phthalates (2015/863)](/artifacts/eu/rohs-directive/restricted-substances-and-thresholds.md): A practical RoHS restricted substances guide for Directive 2011/65/EU: the 10 substances in Annex II, homogeneous material threshold logic (0.1% for most. - [RoHS Applicability Test | Is My Product In Scope of EU RoHS Directive 2011/65/EU? | EEE, Cables, Spare Parts, Open Scope](/artifacts/eu/rohs-directive/applicability-test.md): A structured EU RoHS applicability test for Directive 2011/65/EU: determine if your product is electrical and electronic equipment (EEE). - [RoHS Compliance Checklist | EU RoHS Directive 2011/65/EU | Supplier Evidence, Exemptions, EN IEC 63000 Technical File](/artifacts/eu/rohs-directive/checklist.md): An audit-ready RoHS compliance checklist for Directive 2011/65/EU: scope and EEE category mapping. - [RoHS Compliance Program | EU RoHS Directive 2011/65/EU Implementation Playbook | Supplier Controls, Exemptions, Evidence](/artifacts/eu/rohs-directive/compliance.md): A practical RoHS compliance program playbook for Directive 2011/65/EU: set up governance, map homogeneous material risks across your BOM. - [RoHS Deadlines and Compliance Calendar (2013, 2014, 2017, 2019, 2021) | EU RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar.md): A RoHS compliance calendar you can actually operationalize: staged applicability dates (22 July 2014/2017/2019). - [RoHS Enforcement, Penalties, and Fines | EU RoHS Directive 2011/65/EU (Member State rules)](/artifacts/eu/rohs-directive/penalties-and-fines.md): What EU RoHS enforcement looks like in practice: market surveillance checks, documentation requests, CE marking scrutiny. - [RoHS Exemptions Tracker Guide | How to Build an Exemption Register (Annex III/IV), Link to BOM, Monitor Expiry](/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide.md): A practical guide to building a RoHS exemptions tracker: recommended tracker fields (exemption reference, exact wording, scope conditions. - [RoHS Exemptions Tracking | Directive 2011/65/EU Annex III and Annex IV | Expiry Risk, Evidence, Renewal Strategy](/artifacts/eu/rohs-directive/exemptions-tracking.md): A practical RoHS exemptions tracking guide for Directive 2011/65/EU: how Annex III and Annex IV exemptions work. - [RoHS Requirements | EU RoHS Directive 2011/65/EU | Substance Restrictions (Annex II), Exemptions (Annex III/IV), CE Evidence](/artifacts/eu/rohs-directive/requirements.md): A practical RoHS requirements breakdown for Directive 2011/65/EU: restricted substances thresholds in homogeneous materials (Annex II). - [RoHS Supplier Declaration Template | Annex II Substances, Homogeneous Material Coverage, Exemptions Disclosure](/artifacts/eu/rohs-directive/rohs-supplier-declaration-template.md): A practical RoHS supplier declaration template for Directive 2011/65/EU. - [Supplier Declarations and Verification | RoHS Compliance Program | Supplier Questionnaires, Change Control, Risk-Based Testing](/artifacts/eu/rohs-directive/supplier-declarations-and-verification.md): A practical supplier evidence playbook for EU RoHS Directive 2011/65/EU. - [Technical Documentation and CE | RoHS Directive 2011/65/EU | EN IEC 63000, EU Declaration of Conformity, Evidence Vault](/artifacts/eu/rohs-directive/technical-documentation-and-ce.md): A practical RoHS technical documentation guide for Directive 2011/65/EU. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/rohs-directive/rohs-vs-reach --- --- title: "Supplier Declarations and Verification" canonical_url: "https://www.sorena.io/artifacts/eu/rohs-directive/supplier-declarations-and-verification" source_url: "https://www.sorena.io/artifacts/eu/rohs-directive/supplier-declarations-and-verification" author: "Sorena AI" description: "A practical supplier evidence playbook for EU RoHS Directive 2011/65/EU." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "RoHS supplier declaration" - "RoHS supplier questionnaire" - "RoHS verification testing" - "RoHS change notification" - "EN IEC 63000 supplier evidence" - "RoHS homogeneous material evidence" - "RoHS" - "Supplier declarations" - "Verification" - "Testing" - "EN IEC 63000" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Supplier Declarations and Verification A practical supplier evidence playbook for EU RoHS Directive 2011/65/EU. *Suppliers* *Evidence* ## EU RoHS Directive (2011/65/EU) Supplier Declarations and Verification Declarations are a control, not a checkbox. Output: supplier requirements + test triggers + evidence vault links per part and homogeneous material. RoHS compliance is only as strong as your supplier evidence. The goal is not to collect a PDF, but to maintain a defensible chain of proof: where restricted substances could exist, why they do not exceed thresholds or are exempt, and how changes are controlled. ## What to request from suppliers (minimum viable RoHS evidence) Request evidence that maps to the RoHS unit of control: homogeneous materials. Avoid generic declarations that do not identify which parts or materials they cover. - Annex II substances declaration (all 10 substances) with statement of homogeneous material coverage - Exemptions disclosure: which exemption (exact wording) is relied upon, for which application/material - Material and process disclosure for hotspots: solders, platings, cable insulation, soft plastics, pigments - Change notification obligation: formulation, plating chemistry, resin system, or supplier chain changes must be disclosed - Document-control fields: supplier version, date, signer authority, and covered manufacturing site *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU RoHS Directive (2011/65/EU) Supplier Declarations and Verification in one governed evidence system SSOT can take EU RoHS Directive (2011/65/EU) Supplier Declarations and Verification from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU RoHS Directive (2011/65/EU) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU RoHS Directive (2011/65/EU) Supplier Declarations and Verification](/solutions/ssot.md): Start from EU RoHS Directive (2011/65/EU) Supplier Declarations and Verification and keep documents, evidence, and control records in one governed system. - [Talk through EU RoHS Directive (2011/65/EU)](/contact.md): Review your current process, evidence gaps, and next steps for EU RoHS Directive (2011/65/EU) Supplier Declarations and Verification. ## Evidence tiers (how to scale across thousands of BOM lines) Not every part needs the same evidence depth. Use tiers to scale: low risk gets declarations; high risk gets verification. Define tier rules and make them part of procurement onboarding. - Tier 1 (low risk): declaration + supplier change control + periodic refresh - Tier 2 (medium risk): declaration + material composition detail + targeted verification triggers - Tier 3 (high risk): declaration + test reports or verified material data + lot/batch traceability where feasible - High-risk flags: soft plastics (phthalates), legacy polymers (brominated FR), solders/terminations (lead), platings (Cr(VI)) ## Risk-based testing strategy (verification triggers) Testing is expensive; the right strategy is trigger-based and targeted to hotspots. Use testing to validate the supplier system and to catch changes, not to test every component forever. - Trigger tests on: new supplier, formulation change, process change, contradictory declarations, or new high-risk material - Target homogeneous materials, not assemblies (e.g., cable insulation polymer, solder alloy, plating layer) - Define actions on failure: quarantine, supplier corrective action, requalification, redesign, and customer impact assessment - Keep test evidence linked to the exact part/homogeneous material and time window ## Change control (the control that prevents 'silent non-compliance') The hardest RoHS failures are silent supplier changes: a resin system changes, a plating line changes, a sub-tier supplier changes. Solve this with contractual duty + operational monitoring + sample verification. - Contract clause: mandatory advance notice for material/process/supplier chain changes - Operational process: change intake -> risk review -> evidence update -> release approval - Monitoring: periodic declaration refresh and selective verification sampling - Traceability: map supplier changes to affected SKUs and production lots where possible ## How to store evidence (EN IEC 63000 mindset) Your evidence vault should match the RoHS documentation standard: organise evidence by product family/variant and link supplier artifacts at the right granularity. If you can't retrieve evidence quickly, you can't defend compliance. - Evidence index: product -> part -> homogeneous material -> supplier -> evidence artifact - Store: declarations, exemptions register entries, test reports, and change logs - Define a review cadence (quarterly for high-risk parts; annual for low-risk) - Make evidence creation a release gate (no new supplier/part without evidence) - Retain the documentation so the manufacturer and importer can satisfy their 10 year document duties ## Primary sources - [Directive 2011/65/EU (RoHS 2) consolidated (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02011L0065-20250101&ref=sorena.io) - Primary source for Annex II restrictions and the compliance framework that supplier evidence must support. - [Commission Implementing Decision (EU) 2020/659 - EN IEC 63000 reference (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2020/659/oj?ref=sorena.io) - References EN IEC 63000:2018 for structuring RoHS technical documentation and evidence sources. - [DG GROW - Harmonised standards for RoHS](https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards/restriction-use-certain-hazardous-substances-rohs_en?ref=sorena.io) - Official entry point for harmonised standards supporting RoHS evidence. ## Related Topic Guides - [EU RoHS FAQ (Scope, Exemptions, Phthalates, Technical File, CE) | RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/faq.md): High-signal EU RoHS FAQ grounded in official sources: what counts as EEE, staged applicability (22 July 2014/2017/2019). - [EU RoHS Timeline: RoHS 1 (2002) -> RoHS 2 (2011/2013) -> Open Scope (2019) -> Phthalates (2019/2021)](/artifacts/eu/rohs-directive/timeline.md): A date-by-date EU RoHS timeline for implementers: RoHS 1 (2002), RoHS 2 recast and transposition (2011 - 2013). - [Restricted Substances and Thresholds | EU RoHS Directive 2011/65/EU | Homogeneous Material Limits (0.1% / 0.01%) + Phthalates (2015/863)](/artifacts/eu/rohs-directive/restricted-substances-and-thresholds.md): A practical RoHS restricted substances guide for Directive 2011/65/EU: the 10 substances in Annex II, homogeneous material threshold logic (0.1% for most. - [RoHS Applicability Test | Is My Product In Scope of EU RoHS Directive 2011/65/EU? | EEE, Cables, Spare Parts, Open Scope](/artifacts/eu/rohs-directive/applicability-test.md): A structured EU RoHS applicability test for Directive 2011/65/EU: determine if your product is electrical and electronic equipment (EEE). - [RoHS Compliance Checklist | EU RoHS Directive 2011/65/EU | Supplier Evidence, Exemptions, EN IEC 63000 Technical File](/artifacts/eu/rohs-directive/checklist.md): An audit-ready RoHS compliance checklist for Directive 2011/65/EU: scope and EEE category mapping. - [RoHS Compliance Program | EU RoHS Directive 2011/65/EU Implementation Playbook | Supplier Controls, Exemptions, Evidence](/artifacts/eu/rohs-directive/compliance.md): A practical RoHS compliance program playbook for Directive 2011/65/EU: set up governance, map homogeneous material risks across your BOM. - [RoHS Deadlines and Compliance Calendar (2013, 2014, 2017, 2019, 2021) | EU RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar.md): A RoHS compliance calendar you can actually operationalize: staged applicability dates (22 July 2014/2017/2019). - [RoHS Enforcement, Penalties, and Fines | EU RoHS Directive 2011/65/EU (Member State rules)](/artifacts/eu/rohs-directive/penalties-and-fines.md): What EU RoHS enforcement looks like in practice: market surveillance checks, documentation requests, CE marking scrutiny. - [RoHS Exemptions Tracker Guide | How to Build an Exemption Register (Annex III/IV), Link to BOM, Monitor Expiry](/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide.md): A practical guide to building a RoHS exemptions tracker: recommended tracker fields (exemption reference, exact wording, scope conditions. - [RoHS Exemptions Tracking | Directive 2011/65/EU Annex III and Annex IV | Expiry Risk, Evidence, Renewal Strategy](/artifacts/eu/rohs-directive/exemptions-tracking.md): A practical RoHS exemptions tracking guide for Directive 2011/65/EU: how Annex III and Annex IV exemptions work. - [RoHS Requirements | EU RoHS Directive 2011/65/EU | Substance Restrictions (Annex II), Exemptions (Annex III/IV), CE Evidence](/artifacts/eu/rohs-directive/requirements.md): A practical RoHS requirements breakdown for Directive 2011/65/EU: restricted substances thresholds in homogeneous materials (Annex II). - [RoHS Supplier Declaration Template | Annex II Substances, Homogeneous Material Coverage, Exemptions Disclosure](/artifacts/eu/rohs-directive/rohs-supplier-declaration-template.md): A practical RoHS supplier declaration template for Directive 2011/65/EU. - [RoHS vs REACH | What's the Difference? | EU RoHS Directive 2011/65/EU vs REACH Regulation (EC) 1907/2006](/artifacts/eu/rohs-directive/rohs-vs-reach.md): A practical RoHS vs REACH guide: RoHS (Directive 2011/65/EU) restricts specific substances in EEE above thresholds in homogeneous materials and is tied to CE. - [Technical Documentation and CE | RoHS Directive 2011/65/EU | EN IEC 63000, EU Declaration of Conformity, Evidence Vault](/artifacts/eu/rohs-directive/technical-documentation-and-ce.md): A practical RoHS technical documentation guide for Directive 2011/65/EU. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/rohs-directive/supplier-declarations-and-verification --- --- title: "Technical Documentation and CE" canonical_url: "https://www.sorena.io/artifacts/eu/rohs-directive/technical-documentation-and-ce" source_url: "https://www.sorena.io/artifacts/eu/rohs-directive/technical-documentation-and-ce" author: "Sorena AI" description: "A practical RoHS technical documentation guide for Directive 2011/65/EU." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EN IEC 63000 RoHS technical documentation" - "RoHS technical file" - "CE marking RoHS" - "EU declaration of conformity RoHS" - "RoHS evidence pack" - "Regulation EU 2019/1020 market surveillance" - "RoHS" - "Technical documentation" - "EN IEC 63000" - "CE marking" - "EU declaration of conformity" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Technical Documentation and CE A practical RoHS technical documentation guide for Directive 2011/65/EU. *EN IEC 63000* *Evidence* ## EU RoHS Directive (2011/65/EU) Technical Documentation and CE RoHS compliance must be provable on request. Output: an EN IEC 63000-aligned technical documentation pack you can export in hours, not weeks. In RoHS, evidence is the product. If you cannot retrieve a coherent technical file that explains how restricted substance thresholds are met (or why exemptions apply), you are exposed during audits and market surveillance. EN IEC 63000 provides a structured way to build and maintain that documentation. ## Why EN IEC 63000 matters EN IEC 63000 is the harmonised standard referenced for RoHS technical documentation: it structures how manufacturers assess materials, components, and products against hazardous substance restrictions. Using a harmonised documentation approach reduces ambiguity, improves consistency across product families, and shortens authority-response time. - Use EN IEC 63000 as a file structure and evidence index - Article 7 requires manufacturers to draw up the technical documentation and carry out internal production control - Article 13 allows a single technical documentation set where another Union conformity-assessment procedure is at least as stringent - Keep evidence linked to homogeneous materials and part numbers - Maintain a change log that explains why updates do not break compliance ## What to include in a RoHS technical file (practical structure) A good technical file is traceable: scope -> risks -> controls -> evidence -> conclusions. Build it per product family and attach variant appendices (materials, suppliers, and configuration differences). - Scope memo: EEE category, variants, exclusions logic, cables/spare parts coverage - Restricted substances mapping: hotspots and homogeneous material definitions - Supplier evidence: declarations, material composition info, change controls - Verification evidence: test reports and sampling rationale (where used) - Exemption register: exemptions used, scope conditions, expiry monitoring and redesign decisions - Release governance: approvals, versions, and what changed between releases *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU RoHS Directive (2011/65/EU) Technical Documentation and CE in one governed evidence system SSOT can take EU RoHS Directive (2011/65/EU) Technical Documentation and CE from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU RoHS Directive (2011/65/EU) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU RoHS Directive (2011/65/EU) Technical Documentation and CE](/solutions/ssot.md): Start from EU RoHS Directive (2011/65/EU) Technical Documentation and CE and keep documents, evidence, and control records in one governed system. - [Talk through EU RoHS Directive (2011/65/EU)](/contact.md): Review your current process, evidence gaps, and next steps for EU RoHS Directive (2011/65/EU) Technical Documentation and CE. ## EU Declaration of Conformity (DoC): keep it in sync The DoC is only defensible if it matches the shipped product and the evidence in the technical file. Treat the DoC as a controlled artifact tied to product releases and supplier changes. - Reference the applicable legal acts and harmonised standards you rely on - Ensure model identifiers and variant coverage match the shipped product - Version and retain DoCs and supporting documentation with clear traceability for 10 years after placing on the market ## Market surveillance readiness (your fastest ROI) Market surveillance is mostly an evidence exercise: authorities will request documentation and expect fast, consistent responses. Build a response playbook and run drills: can you export the pack quickly and consistently? - Evidence vault export: technical file + DoC + key supplier and test artifacts - Authority-response owner and escalation path - Article 16 presumption of conformity is stronger when your file follows the published harmonised standard - Periodic reviews: standards updates, supplier changes, exemptions expiry - Importer readiness: keep a copy of the DoC and make sure the technical documentation can be made available for 10 years - Sampling and verification governance for high-risk materials ## Primary sources - [Commission Implementing Decision (EU) 2020/659 - EN IEC 63000 reference (EUR-Lex)](https://eur-lex.europa.eu/eli/dec_impl/2020/659/oj?ref=sorena.io) - Publishes the reference of EN IEC 63000:2018 as the harmonised standard for RoHS technical documentation. - [Directive 2011/65/EU (RoHS 2) consolidated (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02011L0065-20250101&ref=sorena.io) - Primary source for RoHS obligations and the compliance framework for EEE. - [Regulation (EU) 2019/1020 - Market surveillance (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2019/1020/oj?ref=sorena.io) - Framework for market surveillance and compliance of products, relevant to evidence requests and enforcement processes. - [DG GROW - Harmonised standards for RoHS](https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards/restriction-use-certain-hazardous-substances-rohs_en?ref=sorena.io) - Official entry point for harmonised standards supporting RoHS evidence. ## Related Topic Guides - [EU RoHS FAQ (Scope, Exemptions, Phthalates, Technical File, CE) | RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/faq.md): High-signal EU RoHS FAQ grounded in official sources: what counts as EEE, staged applicability (22 July 2014/2017/2019). - [EU RoHS Timeline: RoHS 1 (2002) -> RoHS 2 (2011/2013) -> Open Scope (2019) -> Phthalates (2019/2021)](/artifacts/eu/rohs-directive/timeline.md): A date-by-date EU RoHS timeline for implementers: RoHS 1 (2002), RoHS 2 recast and transposition (2011 - 2013). - [Restricted Substances and Thresholds | EU RoHS Directive 2011/65/EU | Homogeneous Material Limits (0.1% / 0.01%) + Phthalates (2015/863)](/artifacts/eu/rohs-directive/restricted-substances-and-thresholds.md): A practical RoHS restricted substances guide for Directive 2011/65/EU: the 10 substances in Annex II, homogeneous material threshold logic (0.1% for most. - [RoHS Applicability Test | Is My Product In Scope of EU RoHS Directive 2011/65/EU? | EEE, Cables, Spare Parts, Open Scope](/artifacts/eu/rohs-directive/applicability-test.md): A structured EU RoHS applicability test for Directive 2011/65/EU: determine if your product is electrical and electronic equipment (EEE). - [RoHS Compliance Checklist | EU RoHS Directive 2011/65/EU | Supplier Evidence, Exemptions, EN IEC 63000 Technical File](/artifacts/eu/rohs-directive/checklist.md): An audit-ready RoHS compliance checklist for Directive 2011/65/EU: scope and EEE category mapping. - [RoHS Compliance Program | EU RoHS Directive 2011/65/EU Implementation Playbook | Supplier Controls, Exemptions, Evidence](/artifacts/eu/rohs-directive/compliance.md): A practical RoHS compliance program playbook for Directive 2011/65/EU: set up governance, map homogeneous material risks across your BOM. - [RoHS Deadlines and Compliance Calendar (2013, 2014, 2017, 2019, 2021) | EU RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar.md): A RoHS compliance calendar you can actually operationalize: staged applicability dates (22 July 2014/2017/2019). - [RoHS Enforcement, Penalties, and Fines | EU RoHS Directive 2011/65/EU (Member State rules)](/artifacts/eu/rohs-directive/penalties-and-fines.md): What EU RoHS enforcement looks like in practice: market surveillance checks, documentation requests, CE marking scrutiny. - [RoHS Exemptions Tracker Guide | How to Build an Exemption Register (Annex III/IV), Link to BOM, Monitor Expiry](/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide.md): A practical guide to building a RoHS exemptions tracker: recommended tracker fields (exemption reference, exact wording, scope conditions. - [RoHS Exemptions Tracking | Directive 2011/65/EU Annex III and Annex IV | Expiry Risk, Evidence, Renewal Strategy](/artifacts/eu/rohs-directive/exemptions-tracking.md): A practical RoHS exemptions tracking guide for Directive 2011/65/EU: how Annex III and Annex IV exemptions work. - [RoHS Requirements | EU RoHS Directive 2011/65/EU | Substance Restrictions (Annex II), Exemptions (Annex III/IV), CE Evidence](/artifacts/eu/rohs-directive/requirements.md): A practical RoHS requirements breakdown for Directive 2011/65/EU: restricted substances thresholds in homogeneous materials (Annex II). - [RoHS Supplier Declaration Template | Annex II Substances, Homogeneous Material Coverage, Exemptions Disclosure](/artifacts/eu/rohs-directive/rohs-supplier-declaration-template.md): A practical RoHS supplier declaration template for Directive 2011/65/EU. - [RoHS vs REACH | What's the Difference? | EU RoHS Directive 2011/65/EU vs REACH Regulation (EC) 1907/2006](/artifacts/eu/rohs-directive/rohs-vs-reach.md): A practical RoHS vs REACH guide: RoHS (Directive 2011/65/EU) restricts specific substances in EEE above thresholds in homogeneous materials and is tied to CE. - [Supplier Declarations and Verification | RoHS Compliance Program | Supplier Questionnaires, Change Control, Risk-Based Testing](/artifacts/eu/rohs-directive/supplier-declarations-and-verification.md): A practical supplier evidence playbook for EU RoHS Directive 2011/65/EU. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/rohs-directive/technical-documentation-and-ce --- --- title: "EU RoHS Timeline: RoHS 1 (2002) -> RoHS 2 (2011/2013) -> Open Scope (2019) -> Phthalates (2019/2021)" canonical_url: "https://www.sorena.io/artifacts/eu/rohs-directive/timeline" source_url: "https://www.sorena.io/artifacts/eu/rohs-directive/timeline" author: "Sorena AI" description: "A date-by-date EU RoHS timeline for implementers: RoHS 1 (2002), RoHS 2 recast and transposition (2011 - 2013)." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU RoHS timeline" - "RoHS open scope 22 July 2019" - "RoHS staged applicability 2014 2017 2019" - "RoHS phthalates 22 July 2019" - "RoHS phthalates 22 July 2021" - "RoHS 2011/65/EU history" - "RoHS exemptions renewal timeline" - "RoHS timeline" - "Open scope 2019" - "Phthalates 2019/2021" - "Exemptions lifecycle" - "RoHS staged applicability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU RoHS Timeline: RoHS 1 (2002) -> RoHS 2 (2011/2013) -> Open Scope (2019) -> Phthalates (2019/2021) A date-by-date EU RoHS timeline for implementers: RoHS 1 (2002), RoHS 2 recast and transposition (2011 - 2013). *RoHS* *Timeline* ## EU RoHS Directive (2011/65/EU) Timeline The dates you must know - and what changed. Use this timeline to set cutovers, plan supplier re-verification, and avoid exemption expiry surprises. RoHS has multiple timelines running at once: (1) the legal evolution from RoHS 1 to the RoHS 2 recast, (2) staged applicability dates by EEE category, (3) substance list updates, especially the phthalates, and (4) exemptions that expire and must be renewed on time. This page collects the key dates and explains what to do at each inflection point. ## 2002 - 2013: RoHS 1 to RoHS 2 (recast) and national implementation RoHS began as Directive 2002/95/EC (RoHS 1). Directive 2011/65/EU (RoHS 2) recast the regime, updated scope, and set the modern exemptions process. Operational impact: by the time RoHS 2 took effect via national law, companies needed repeatable evidence packs, not one-time declarations. - By 2 January 2013: Member States adopt and publish transposition measures - 3 January 2013: RoHS 1 repealed; RoHS 2 framework becomes the baseline - 2013 onward: technical documentation, DoC, and CE marking expectations become the practical enforcement surface ## 2014 and 2017: staged category applicability expands (medical and monitoring) RoHS staged some categories into scope. Treat the staged dates as hard ship gates for those categories: you must have a defensible RoHS position for products first placed on the EU market after the relevant date. Use these dates to plan supplier re-verification, targeted testing, and technical file readiness ahead of time. - 22 July 2014: medical devices enter RoHS scope via staged applicability - 22 July 2016: in vitro diagnostic medical devices enter RoHS scope - 22 July 2017: industrial monitoring and control instruments enter RoHS scope - Practical action: pre-stage evidence packs for high-risk plastics, cables, coatings, and components ## 2019: open scope and the big classification shift RoHS moved to open scope for remaining EEE in Category 11 and staged additional products into scope from 22 July 2019. This is where many companies first discover that their non-EEE assumption was wrong. Operational action: run an applicability sweep across product lines, classify into Annex I categories, and create a defensible exclusions record where applicable. - 22 July 2019: open scope and remaining EEE staged into scope - Supplier impact: update contract clauses and evidence requirements (declarations + change notification) - Evidence impact: homogeneous material mapping becomes essential at portfolio scale ## 2019 and 2021: RoHS 3 phthalates restrictions (two cutovers) Delegated Directive (EU) 2015/863 added four phthalates (DEHP, BBP, DBP, DIBP) to the restricted substances list (Annex II) with staged applicability dates. This is often the highest-risk RoHS change for plastics and cables. Action: schedule supplier re-declarations and targeted testing ahead of each cutover, then enforce it as a release gate. - 22 July 2019: phthalates restrictions apply for most EEE - 22 July 2021: phthalates restrictions apply for medical devices + monitoring/control instruments - Carve-outs exist for certain cables/spare parts used to repair/reuse/update older equipment (placed on the market before the cutover dates) ## Ongoing: exemptions renewals and annex updates never stop Annex III/IV exemptions are time-limited and require proactive renewal dossiers. RoHS sets a strict renewal deadline (>=18 months before expiry) and defines what happens if a renewal is rejected (phase-out window). Treat exemptions as expiring risk: if an exemption disappears, your redesign path and supplier qualification plan must already exist. - Renewal submitted >=18 months before expiry; exemption remains valid until decision - Current Commission guidance says decisions typically take 18 to 24 months from application - If renewal rejected/revoked: expect 12 - 18 months to phase out (plan redesign capacity) - Track exemptions operationally (expiry alerts, product mapping, and evidence packs) *Recommended next step* *Placement: after the timeline or milestone section* ## Turn EU RoHS Directive (2011/65/EU) Timeline into an operational assessment Assessment Autopilot can take EU RoHS Directive (2011/65/EU) Timeline from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU RoHS Directive (2011/65/EU) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for EU RoHS Directive (2011/65/EU) Timeline](/solutions/assessment.md): Start from EU RoHS Directive (2011/65/EU) Timeline and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through EU RoHS Directive (2011/65/EU)](/contact.md): Review your current process, evidence gaps, and next steps for EU RoHS Directive (2011/65/EU) Timeline. ## Primary sources - [Directive 2011/65/EU (RoHS 2) consolidated (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02011L0065-20250101&ref=sorena.io) - Primary source for staged applicability dates and exemptions renewal timing. - [Delegated Directive (EU) 2015/863 (RoHS 3 phthalates) (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L0863&ref=sorena.io) - Sets staged applicability dates for phthalates restrictions (2019/2021). - [Directive (EU) 2017/2102 amending RoHS 2 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32017L2102&ref=sorena.io) - Amends scope and exemptions aspects of the RoHS 2 framework. - [RoHS FAQ and key guidance (European Commission, DG Environment)](https://environment.ec.europa.eu/system/files/2021-01/FAQ%20key%20guidance%20document%20-%20RoHS.pdf?ref=sorena.io) - Practical guidance for implementation and common edge cases. - [Commission Notice 2022/C 262/04 - RoHS implementation guidance (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52022XC0628%2804%29&ref=sorena.io) - Commission-level notice on RoHS implementation (use for interpretive guidance alongside the directive text). ## Related Topic Guides - [EU RoHS FAQ (Scope, Exemptions, Phthalates, Technical File, CE) | RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/faq.md): High-signal EU RoHS FAQ grounded in official sources: what counts as EEE, staged applicability (22 July 2014/2017/2019). - [Restricted Substances and Thresholds | EU RoHS Directive 2011/65/EU | Homogeneous Material Limits (0.1% / 0.01%) + Phthalates (2015/863)](/artifacts/eu/rohs-directive/restricted-substances-and-thresholds.md): A practical RoHS restricted substances guide for Directive 2011/65/EU: the 10 substances in Annex II, homogeneous material threshold logic (0.1% for most. - [RoHS Applicability Test | Is My Product In Scope of EU RoHS Directive 2011/65/EU? | EEE, Cables, Spare Parts, Open Scope](/artifacts/eu/rohs-directive/applicability-test.md): A structured EU RoHS applicability test for Directive 2011/65/EU: determine if your product is electrical and electronic equipment (EEE). - [RoHS Compliance Checklist | EU RoHS Directive 2011/65/EU | Supplier Evidence, Exemptions, EN IEC 63000 Technical File](/artifacts/eu/rohs-directive/checklist.md): An audit-ready RoHS compliance checklist for Directive 2011/65/EU: scope and EEE category mapping. - [RoHS Compliance Program | EU RoHS Directive 2011/65/EU Implementation Playbook | Supplier Controls, Exemptions, Evidence](/artifacts/eu/rohs-directive/compliance.md): A practical RoHS compliance program playbook for Directive 2011/65/EU: set up governance, map homogeneous material risks across your BOM. - [RoHS Deadlines and Compliance Calendar (2013, 2014, 2017, 2019, 2021) | EU RoHS Directive 2011/65/EU](/artifacts/eu/rohs-directive/deadlines-and-compliance-calendar.md): A RoHS compliance calendar you can actually operationalize: staged applicability dates (22 July 2014/2017/2019). - [RoHS Enforcement, Penalties, and Fines | EU RoHS Directive 2011/65/EU (Member State rules)](/artifacts/eu/rohs-directive/penalties-and-fines.md): What EU RoHS enforcement looks like in practice: market surveillance checks, documentation requests, CE marking scrutiny. - [RoHS Exemptions Tracker Guide | How to Build an Exemption Register (Annex III/IV), Link to BOM, Monitor Expiry](/artifacts/eu/rohs-directive/rohs-exemptions-tracker-guide.md): A practical guide to building a RoHS exemptions tracker: recommended tracker fields (exemption reference, exact wording, scope conditions. - [RoHS Exemptions Tracking | Directive 2011/65/EU Annex III and Annex IV | Expiry Risk, Evidence, Renewal Strategy](/artifacts/eu/rohs-directive/exemptions-tracking.md): A practical RoHS exemptions tracking guide for Directive 2011/65/EU: how Annex III and Annex IV exemptions work. - [RoHS Requirements | EU RoHS Directive 2011/65/EU | Substance Restrictions (Annex II), Exemptions (Annex III/IV), CE Evidence](/artifacts/eu/rohs-directive/requirements.md): A practical RoHS requirements breakdown for Directive 2011/65/EU: restricted substances thresholds in homogeneous materials (Annex II). - [RoHS Supplier Declaration Template | Annex II Substances, Homogeneous Material Coverage, Exemptions Disclosure](/artifacts/eu/rohs-directive/rohs-supplier-declaration-template.md): A practical RoHS supplier declaration template for Directive 2011/65/EU. - [RoHS vs REACH | What's the Difference? | EU RoHS Directive 2011/65/EU vs REACH Regulation (EC) 1907/2006](/artifacts/eu/rohs-directive/rohs-vs-reach.md): A practical RoHS vs REACH guide: RoHS (Directive 2011/65/EU) restricts specific substances in EEE above thresholds in homogeneous materials and is tied to CE. - [Supplier Declarations and Verification | RoHS Compliance Program | Supplier Questionnaires, Change Control, Risk-Based Testing](/artifacts/eu/rohs-directive/supplier-declarations-and-verification.md): A practical supplier evidence playbook for EU RoHS Directive 2011/65/EU. - [Technical Documentation and CE | RoHS Directive 2011/65/EU | EN IEC 63000, EU Declaration of Conformity, Evidence Vault](/artifacts/eu/rohs-directive/technical-documentation-and-ce.md): A practical RoHS technical documentation guide for Directive 2011/65/EU. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/rohs-directive/timeline --- --- title: "EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures" canonical_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/applicability-test" source_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/applicability-test" author: "Sorena AI" description: "A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Taxonomy applicability test" - "EU Taxonomy in scope" - "Article 8 EU Taxonomy disclosures" - "taxonomy eligibility test" - "taxonomy alignment test" - "EU Taxonomy Regulation 2020/852" - "technical screening criteria checklist" - "EU Taxonomy" - "Article 8 disclosure" - "Eligibility vs alignment" - "Technical screening criteria" - "Taxonomy KPIs" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose. *EU Taxonomy* *Applicability* ## EU Taxonomy Regulation (EU) 2020/852 Applicability test A scoping flow that ends with a concrete disclosure plan. Decide who must disclose (Article 8), what to classify, and what evidence you must maintain. EU Taxonomy applicability is two different questions: (1) are you required to disclose taxonomy KPIs (typically via Article 8 and the disclosures delegated act), and (2) even if not required, do you still need taxonomy classification because banks, investors, SFDR products, customers, or green bonds require it? Use this test to define your scope, your activity universe, and your KPI + evidence workflow. ## Step 1 - Are you required to disclose under Article 8? Start with your reporting regime: taxonomy disclosures are implemented via delegated acts and are commonly embedded into corporate sustainability / non-financial reporting cycles. Financial undertakings have their own KPI templates (including GAR) that depend on counterparty data flows. Output: confirm whether you must disclose taxonomy KPIs this year (and which phase-in period applies). - Non-financial undertaking: confirm KPI obligations (turnover, CapEx, OpEx) and reporting boundary - Financial undertaking: confirm KPI type (e.g., GAR) and counterparty data dependencies - Out of scope: decide whether to produce a counterparty data pack anyway for lenders and investors - Record the result: in scope / out of scope + why + which reporting year rules apply ## Step 2 - Define the activity universe you will classify Taxonomy classification is activity-based, not product-label-based. You need a stable inventory that bridges finance and operations: revenue lines, CapEx programs, and OpEx categories mapped to economic activities. A good activity universe survives reorganizations because it is tied to accounts and operational assets/projects, not org charts. - Revenue mapping: chart of accounts / product lines -> activities - CapEx mapping: projects and spend categories -> activities (plus CapEx plan logic where relevant) - OpEx mapping: relevant OpEx categories -> activities (per disclosure rules) - Boundary rules: which subsidiaries, JVs, and geographies are in the reporting perimeter ## Step 3 - Decide eligibility vs alignment (and avoid the classic trap) Eligibility means the activity is covered or listed by delegated acts. Alignment is the higher bar: meet technical screening criteria for substantial contribution, DNSH, and minimum safeguards - and you can prove it. Output: for each activity, record (a) eligible/not eligible, (b) aligned/not aligned, and (c) evidence requirements and owners. - Eligibility check: is there a delegated act activity definition that matches your activity boundary? - Alignment check: pass/fail for substantial contribution + DNSH criteria, with evidence pointers - Minimum safeguards check: due diligence baseline is in place for the reporting perimeter - Versioning: record which delegated act / criteria version you used for the reporting year ## Step 4 - Define the KPI workflow and evidence vault (so it's auditable) A disclosure that cannot be reproduced is a governance failure. Define ownership for each KPI input, review gates, and the evidence vault structure before reporting season. Treat taxonomy KPIs like a close process: controlled workbook, reconciliations, and sign-offs. - KPI workbook: controlled calculation model with audit trail and change log - Evidence packs: activity-level folders that map criteria -> evidence artifacts - Estimates policy: how you treat missing data, proxies, and limitations - Counterparty requests: standard response pack for banks/investors *Recommended next step* *Placement: after the applicability result* ## Operationalize EU Taxonomy Regulation (EU) 2020/852 Applicability test across ESG workflows ESG Compliance can take EU Taxonomy Regulation (EU) 2020/852 Applicability test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on EU Taxonomy Regulation (EU) 2020/852 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Taxonomy Regulation (EU) 2020/852 Applicability test](/solutions/esg-compliance.md): Start from EU Taxonomy Regulation (EU) 2020/852 Applicability test and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Taxonomy Regulation (EU) 2020/852](/contact.md): Review your current process, evidence gaps, and next steps for EU Taxonomy Regulation (EU) 2020/852 Applicability test. ## Primary sources - [Regulation (EU) 2020/852 (EU Taxonomy Regulation) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2020/852/oj?ref=sorena.io) - Core definitions: environmentally sustainable economic activity, six objectives, and delegated act framework. - [Disclosures Delegated Act (Article 8) - Commission Delegated Regulation (EU) 2021/2178 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Scope rules, KPI templates, and phase-in for non-financial and financial undertakings. - [EU Taxonomy for sustainable activities (European Commission hub)](https://finance.ec.europa.eu/sustainable-finance/tools-and-standards/eu-taxonomy-sustainable-activities_en?ref=sorena.io) - Official navigation point for legislation, FAQs, and supporting tools. ## Related Topic Guides - [EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs](/artifacts/eu/taxonomy-regulation/checklist.md): An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping. - [EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence](/artifacts/eu/taxonomy-regulation/compliance.md): A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register. - [EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR](/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar.md): A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases. - [EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73](/artifacts/eu/taxonomy-regulation/delegated-acts-tracker.md): Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts. - [EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link](/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards.md): A practical guide to EU Taxonomy DNSH and minimum safeguards. - [EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7)](/artifacts/eu/taxonomy-regulation/penalties-and-fines.md): How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7. - [EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification](/artifacts/eu/taxonomy-regulation/faq.md): A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice. - [EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8](/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow.md): Build an EU Taxonomy disclosure workflow that can survive review. - [EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs](/artifacts/eu/taxonomy-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means. - [EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8](/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities.md): Understand EU Taxonomy scope and reporting entities under Article 8. - [EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail](/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation.md): How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping. - [EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards)](/artifacts/eu/taxonomy-regulation/templates.md): Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register. - [EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting](/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd.md): Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system. - [EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests](/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr.md): Understand the practical relationship between EU Taxonomy and SFDR. - [Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove](/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained.md): A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/taxonomy-regulation/applicability-test --- --- title: "EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs" canonical_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/checklist" source_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/checklist" author: "Sorena AI" description: "An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Taxonomy checklist" - "Article 8 taxonomy checklist" - "taxonomy alignment checklist" - "taxonomy eligibility checklist" - "taxonomy KPIs checklist turnover CapEx OpEx GAR" - "taxonomy evidence pack checklist" - "Delegated Regulation 2021/2178 checklist" - "Article 8 KPIs" - "Eligibility vs alignment" - "DNSH and safeguards" - "Assurance readiness" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping. *EU Taxonomy* *Checklist* ## EU Taxonomy (Article 8) Checklist A checklist that maps work to owners and evidence. Use this to build a repeatable taxonomy reporting process - not a one-time spreadsheet. Taxonomy reporting breaks when it's treated as a one-off narrative. Use this checklist as an operating system: clear scope decisions, activity mapping to accounts, alignment evidence packs, KPI workbook controls, and a cadence that survives supplier changes, reorganizations, and delegated act updates. ## 1) Lock scope and reporting perimeter Scope and perimeter decisions prevent 80% of later KPI disputes. Define who must disclose, which templates apply, and which entities and activities are in the reporting boundary. Output: a scope memo and a perimeter register that ties to consolidation reporting. - Confirm whether Article 8 disclosures apply (and which phase-in year rules apply) - Define reporting perimeter: subsidiaries, JVs, associates, and consolidation method - Define activity boundary rules so the activity boundary is consistent for eligibility and alignment - Assign owners: sustainability, finance, operations, legal, and assurance liaison ## 2) Build the activity mapping register (the backbone of KPIs) Taxonomy is activity-based. Build a controlled register that maps revenue/CapEx/OpEx lines to taxonomy activities and records boundaries and assumptions. Output: a versioned activity register with account mappings and evidence pointers. - Revenue mapping: chart of accounts/product lines -> taxonomy activities - CapEx mapping: projects/spend categories -> taxonomy activities (plus CapEx plan logic where relevant) - OpEx mapping: relevant OpEx categories -> activities (per disclosure rules) - Data model: stable identifiers for activities so the same activity can be tracked year-over-year ## 3) Separate eligibility from alignment (and document both) Eligibility is a coverage check. Alignment is a compliance claim. Treat them as separate fields in your register with separate evidence expectations. Output: eligibility status per activity, plus alignment pass/fail per criterion with evidence pointers. - Eligibility: match activity definition in delegated acts; document the rationale and boundary - Alignment: substantial contribution + DNSH + minimum safeguards + TSC compliance - Non-alignment handling: ensure eligible-but-not-aligned stays out of aligned KPI numerators - Criteria versioning: record which delegated act version you used for the reporting year ## 4) Build alignment evidence packs (criteria-by-criteria) Alignment evidence is not one PDF. It is a criteria mapping file plus evidence artifacts attached to each criterion, including DNSH and safeguards. Output: activity-level evidence packs with traceability and owners. - Criteria mapping file: criterion -> pass/fail -> evidence link -> owner -> timestamp - DNSH evidence: assessments/permits/monitoring data where relevant - Minimum safeguards evidence: due diligence baseline, grievance mechanisms, remediation tracking - Continuous criteria: monitoring cadence and responsibilities defined ## 5) Build the KPI workbook and controls (turnover/CapEx/OpEx or GAR) KPI quality is reproducibility. Use a controlled workbook, reconciliations to audited numbers, and a documented estimates policy. Output: a KPI workbook you can re-run with the same inputs and get the same outputs. - Reconciliation: denominators tie to audited financial statement figures - Controls: review gates for activity mapping, evidence completeness, and KPI calculations - Estimates/proxies: defined policy + consistency across entities and periods - Narratives: methodology notes that match the numbers and don't over-claim alignment ## 6) Assurance readiness and reporting cadence Assurance teams usually challenge boundaries, traceability, and evidence - not the math. Design the process so those questions are answerable quickly. Output: a sign-off pack and a repeatable annual schedule. - Evidence vault index: KPI numerator -> activity -> criteria -> evidence -> owner - Perimeter change log: acquisitions/disposals/reorgs and KPI impact documented - Delegated acts tracker: changes monitored and versioning preserved - Dry-run and pre-assurance review scheduled before reporting deadlines *Recommended next step* *Placement: after the checklist block* ## Operationalize EU Taxonomy (Article 8) Checklist across ESG workflows ESG Compliance can take EU Taxonomy (Article 8) Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on EU Taxonomy (Article 8) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Taxonomy (Article 8) Checklist](/solutions/esg-compliance.md): Start from EU Taxonomy (Article 8) Checklist and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Taxonomy (Article 8)](/contact.md): Review your current process, evidence gaps, and next steps for EU Taxonomy (Article 8) Checklist. ## Primary sources - [Regulation (EU) 2020/852 (EU Taxonomy Regulation) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2020/852/oj?ref=sorena.io) - Core framework, alignment conditions, and objectives. - [Disclosures Delegated Act (Article 8) - Commission Delegated Regulation (EU) 2021/2178 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - KPI templates, calculation rules, and phase-in requirements. - [Commission Notice on the Disclosures Delegated Act (OJ C 2023/305) (EUR-Lex)](https://eur-lex.europa.eu/eli/C/2023/305/oj/eng?ref=sorena.io) - Practical interpretive guidance for taxonomy reporting. ## Related Topic Guides - [EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures](/artifacts/eu/taxonomy-regulation/applicability-test.md): A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose. - [EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence](/artifacts/eu/taxonomy-regulation/compliance.md): A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register. - [EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR](/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar.md): A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases. - [EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73](/artifacts/eu/taxonomy-regulation/delegated-acts-tracker.md): Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts. - [EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link](/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards.md): A practical guide to EU Taxonomy DNSH and minimum safeguards. - [EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7)](/artifacts/eu/taxonomy-regulation/penalties-and-fines.md): How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7. - [EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification](/artifacts/eu/taxonomy-regulation/faq.md): A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice. - [EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8](/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow.md): Build an EU Taxonomy disclosure workflow that can survive review. - [EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs](/artifacts/eu/taxonomy-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means. - [EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8](/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities.md): Understand EU Taxonomy scope and reporting entities under Article 8. - [EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail](/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation.md): How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping. - [EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards)](/artifacts/eu/taxonomy-regulation/templates.md): Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register. - [EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting](/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd.md): Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system. - [EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests](/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr.md): Understand the practical relationship between EU Taxonomy and SFDR. - [Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove](/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained.md): A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/taxonomy-regulation/checklist --- --- title: "EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence" canonical_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/compliance" source_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/compliance" author: "Sorena AI" description: "A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Taxonomy compliance program" - "EU Taxonomy implementation playbook" - "Article 8 taxonomy reporting program" - "taxonomy KPI program turnover CapEx OpEx GAR" - "taxonomy evidence pack program" - "delegated acts tracker program" - "Article 8 reporting" - "Evidence packs" - "KPIs" - "Delegated acts" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register. *EU Taxonomy* *Program* ## EU Taxonomy Regulation (EU) 2020/852 Compliance A scalable system beats one-off reporting scrambles. Build a program for classification, evidence, KPIs, and delegated act change control. EU Taxonomy is portfolio reporting: multiple activities, multiple entities, evolving criteria, and heavy data dependencies (especially for financial KPIs like GAR). A sustainable approach is a program: define the unit of control (activity boundary), enforce evidence and change control, maintain an auditable KPI workbook, and keep a cadence that updates with delegated acts. ## Program architecture (workstreams that map to reality) A useful program separates work into owned workstreams. Each workstream has a clear output artifact and acceptance criteria. When workstreams are owned, reporting becomes repeatable and less sensitive to team turnover. - Scope and perimeter: who must disclose; reporting boundary; phase-in year rules - Activity mapping: revenue/CapEx/OpEx mapped to taxonomy activity definitions (versioned) - Alignment evidence: criteria-by-criteria mapping + DNSH + minimum safeguards proof - KPI operations: workbook, reconciliations, estimates policy, and disclosure pack - Change control: delegated acts tracker + re-assessment triggers ## Evidence model (how to make alignment auditable) Alignment is evidence-driven. The evidence model should be activity-level and criterion-by-criterion, with stable identifiers so evidence survives reorganizations. Design for retrieval: respond to assurance questions quickly without reconstructing files from emails. - Evidence pack per activity with a stable index (criteria -> evidence -> owner -> timestamp) - DNSH register and safeguards register linked to activities and KPI numerators - Policy baseline: minimum safeguards due diligence documented and tested - Monitoring cadence for criteria that require ongoing performance ## KPI operations (run it like a close process) Taxonomy KPIs should be reproducible, reconcilable, and explainable. That requires a controlled workbook, input validation, and documented methodology choices. Financial undertakings should treat counterparty data intake as a governed process with exception handling. - KPI workbook with change log and controlled inputs - Reconciliations to audited numbers and consolidation rules - Estimates/proxies policy and consistent limitation disclosures - Counterparty data intake model and validation rules (for GAR and related KPIs) ## Cadence and governance (what you do every quarter) Cadence prevents drift. Without it, eligibility/alignment decisions and evidence go stale as operations change. Set recurring checkpoints that refresh evidence, track delegated act changes, and test the KPI workflow before reporting season. - Quarterly: delegated acts tracker refresh and criteria version review - Quarterly: sample-based evidence pack health check (completeness and traceability) - Pre-reporting: dry-run KPI calculation and reconciliation; fix breaks - Annual: assurance readiness review and methodology change log *Recommended next step* *Placement: after the compliance steps* ## Operationalize EU Taxonomy Regulation (EU) 2020/852 Compliance across ESG workflows ESG Compliance can take EU Taxonomy Regulation (EU) 2020/852 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on EU Taxonomy Regulation (EU) 2020/852 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Taxonomy Regulation (EU) 2020/852 Compliance](/solutions/esg-compliance.md): Start from EU Taxonomy Regulation (EU) 2020/852 Compliance and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Taxonomy Regulation (EU) 2020/852](/contact.md): Review your current process, evidence gaps, and next steps for EU Taxonomy Regulation (EU) 2020/852 Compliance. ## Primary sources - [Regulation (EU) 2020/852 (EU Taxonomy Regulation) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2020/852/oj?ref=sorena.io) - Core taxonomy framework and delegated act mechanism. - [Disclosures Delegated Act (Article 8) - Commission Delegated Regulation (EU) 2021/2178 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - KPI templates, computation rules, and phase-in. - [EU Taxonomy for sustainable activities (European Commission hub)](https://finance.ec.europa.eu/sustainable-finance/tools-and-standards/eu-taxonomy-sustainable-activities_en?ref=sorena.io) - Official access point for legislation, FAQs, and tools. ## Related Topic Guides - [EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures](/artifacts/eu/taxonomy-regulation/applicability-test.md): A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose. - [EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs](/artifacts/eu/taxonomy-regulation/checklist.md): An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping. - [EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR](/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar.md): A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases. - [EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73](/artifacts/eu/taxonomy-regulation/delegated-acts-tracker.md): Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts. - [EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link](/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards.md): A practical guide to EU Taxonomy DNSH and minimum safeguards. - [EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7)](/artifacts/eu/taxonomy-regulation/penalties-and-fines.md): How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7. - [EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification](/artifacts/eu/taxonomy-regulation/faq.md): A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice. - [EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8](/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow.md): Build an EU Taxonomy disclosure workflow that can survive review. - [EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs](/artifacts/eu/taxonomy-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means. - [EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8](/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities.md): Understand EU Taxonomy scope and reporting entities under Article 8. - [EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail](/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation.md): How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping. - [EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards)](/artifacts/eu/taxonomy-regulation/templates.md): Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register. - [EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting](/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd.md): Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system. - [EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests](/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr.md): Understand the practical relationship between EU Taxonomy and SFDR. - [Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove](/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained.md): A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/taxonomy-regulation/compliance --- --- title: "EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR" canonical_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar" author: "Sorena AI" description: "A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Taxonomy deadlines" - "EU Taxonomy calendar" - "Article 8 Taxonomy reporting dates" - "EU Taxonomy 2026 simplification" - "GAR reporting date" - "Taxonomy 2028 trading book KPI" - "Delegated Regulation 2026/73" - "Article 8 reporting" - "GAR" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases. *EU Taxonomy* *Calendar* ## EU Taxonomy Regulation (EU) 2020/852 Deadlines and disclosure calendar Put Taxonomy milestones into the close, assurance, and board calendar. Track Article 8 phases, the 2026 simplification package, and when financial KPI templates actually become mandatory. EU Taxonomy reporting is easier when the legal dates are translated into operational checkpoints. The important dates are not only the original phase-in years under Delegated Regulation (EU) 2021/2178, but also the current simplification changes in Delegated Regulation (EU) 2026/73, the 2025 Commission Notice, and the separate CSRD timing changes that affect who enters Article 8 scope next. ## Core regulation application dates Regulation (EU) 2020/852 introduced the six environmental objectives and staged the framework by objective. Climate objectives applied first, then the remaining four objectives followed. Use these dates to avoid mixing criteria from objectives that were not yet applicable in the reporting year you are analysing. - 12 July 2020: main Taxonomy framework starts applying, including the delegated-act engine - 1 January 2022: climate mitigation and climate adaptation framework starts applying - 1 January 2023: water, circular economy, pollution prevention, and biodiversity framework starts applying - 1 January 2023: non-financial undertakings begin KPI reporting under the Article 8 delegated act - 1 January 2024: financial undertakings begin KPI reporting, including GAR ## Article 8 phase-in and current scope timing The original Article 8 timetable was staged. Non-financial undertakings first reported eligibility, then alignment KPIs. Financial undertakings followed one year later because their metrics depend on counterparty data. Current scope timing now has two layers. First, use the Commission Notices for the Article 8 methodology. Second, read scope together with the current Accounting Directive and CSRD timing because Article 8 hooks into Articles 19a and 29a. - Reporting in 2022 for FY 2021: initial eligibility-only disclosures for climate activities - From 1 January 2023: non-financial undertakings report turnover, CapEx, and OpEx KPIs - From 1 January 2024: financial undertakings report GAR and other applicable financial KPIs - Commission Notice C/2025/1373 confirms that first-time reporters disclose only year N, with N-1 comparatives only from the second reporting year - Directive (EU) 2025/794 changes later CSRD entry dates, so newer Article 8 entrants should read scope together with the deferred CSRD wave timetable ## 2024 to 2026 changes you must schedule now The 2023 delegated-act package expanded the technical criteria and the reporting templates for the additional environmental objectives. The 2025 Commission Notice then clarified how those templates, enabling activities, comparatives, and materiality questions should work in practice. Delegated Regulation (EU) 2026/73 then simplified both disclosures and some DNSH-related screening work. For FY 2025, undertakings may still use the rules as they stood on 31 December 2025. - 1 January 2024: environmental objective reporting package starts applying for non-financial undertakings, with modified templates - 1 January 2025: non-financial undertakings report alignment for activities added by the 2023 package - 5 March 2025: Commission Notice C/2025/1373 published with current implementation guidance - 8 January 2026: Delegated Regulation (EU) 2026/73 published in the Official Journal and in force - 1 January 2026: the simplification amendments apply, but undertakings may keep the pre-2026 rules for financial years that started during 2025 ## Financial KPI deadlines that are easy to miss Financial institutions need a more detailed implementation calendar than non-financial undertakings because GAR, GIR, fee and commission metrics, and trading-book metrics do not all mature at the same time. The 2026 simplification act also adds temporary relief. That matters for budget, controls, and what you ask counterparties to provide. - Until 31 December 2027: certain financial undertakings that do not claim Taxonomy-associated activities may use the simplified statement route instead of the full templates - From 1 January 2028: Annex V Section 1.2.3 and Section 1.2.4 apply, which is when fees and commissions and trading-book templates start - 2026/73 introduces 10% non-materiality thresholds for certain fees and commissions, trading-book, and similar KPI assessments - Counterparty data requests should be refreshed before each reporting cycle, because GAR quality still depends on what the investee population discloses *Recommended next step* *Placement: after the timeline or milestone section* ## Operationalize EU Taxonomy Regulation (EU) 2020/852 Deadlines and disclosure calendar across ESG workflows ESG Compliance can take EU Taxonomy Regulation (EU) 2020/852 Deadlines and disclosure calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on EU Taxonomy Regulation (EU) 2020/852 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Taxonomy Regulation (EU) 2020/852 Deadlines and disclosure calendar](/solutions/esg-compliance.md): Start from EU Taxonomy Regulation (EU) 2020/852 Deadlines and disclosure calendar and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Taxonomy Regulation (EU) 2020/852](/contact.md): Review your current process, evidence gaps, and next steps for EU Taxonomy Regulation (EU) 2020/852 Deadlines and disclosure calendar. ## What to schedule every year A reliable Taxonomy calendar is not only a list of legal dates. It is a recurring work plan with owners, evidence deadlines, and a place where delegated-act changes become tracked tasks. The practical goal is simple: by the time the management report is drafted, the eligibility register, alignment evidence, and KPI workbook should already be frozen and reviewable. - Q1: confirm scope, reporting perimeter, and the delegated-act version set for the reporting year - Q2: refresh activity mapping, counterparty data requests, DNSH evidence, and minimum safeguards evidence - Q3: run a dry calculation, test reconciliations, and document estimates or non-assessed items - Q4: complete sign-off packs, assurance review, contextual disclosures, and board approval material ## Primary sources - [Regulation (EU) 2020/852 (EU Taxonomy Regulation) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2020/852/oj/eng?ref=sorena.io) - Core framework and staged application by environmental objective. - [Commission Delegated Regulation (EU) 2021/2178 (Article 8 disclosures) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Original Article 8 KPI templates, methodology, and phase-in structure. - [Commission Delegated Regulation (EU) 2026/73 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2026/73/oj/eng?ref=sorena.io) - Current simplification act. Applies from 1 January 2026, with optional use of the pre-2026 rules for FY 2025. - [Commission Notice C/2025/1373 (EUR-Lex)](https://eur-lex.europa.eu/eli/C/2025/1373/oj/eng?ref=sorena.io) - Current implementation guidance on comparatives, enabling activities, materiality handling, and updated templates. - [Commission Notice C/2023/305 (EUR-Lex)](https://eur-lex.europa.eu/eli/C/2023/305/oj/eng?ref=sorena.io) - Second Commission Notice with core Article 8 guidance for non-financial undertakings. ## Related Topic Guides - [EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures](/artifacts/eu/taxonomy-regulation/applicability-test.md): A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose. - [EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs](/artifacts/eu/taxonomy-regulation/checklist.md): An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping. - [EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence](/artifacts/eu/taxonomy-regulation/compliance.md): A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register. - [EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73](/artifacts/eu/taxonomy-regulation/delegated-acts-tracker.md): Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts. - [EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link](/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards.md): A practical guide to EU Taxonomy DNSH and minimum safeguards. - [EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7)](/artifacts/eu/taxonomy-regulation/penalties-and-fines.md): How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7. - [EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification](/artifacts/eu/taxonomy-regulation/faq.md): A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice. - [EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8](/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow.md): Build an EU Taxonomy disclosure workflow that can survive review. - [EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs](/artifacts/eu/taxonomy-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means. - [EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8](/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities.md): Understand EU Taxonomy scope and reporting entities under Article 8. - [EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail](/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation.md): How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping. - [EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards)](/artifacts/eu/taxonomy-regulation/templates.md): Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register. - [EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting](/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd.md): Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system. - [EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests](/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr.md): Understand the practical relationship between EU Taxonomy and SFDR. - [Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove](/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained.md): A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar --- --- title: "EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73" canonical_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/delegated-acts-tracker" source_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/delegated-acts-tracker" author: "Sorena AI" description: "Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Taxonomy delegated acts tracker" - "EU Taxonomy legal stack" - "Delegated Regulation 2026/73" - "Climate Delegated Act 2021/2139" - "Article 8 delegated act 2021/2178" - "Environmental Delegated Act 2023/2486" - "Taxonomy version control" - "EU Taxonomy delegated acts" - "Article 8" - "Technical screening criteria" - "DNSH" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73 Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts. *EU Taxonomy* *Tracker* ## EU Taxonomy Delegated acts tracker The framework is stable. The operational detail moves through delegated acts and notices. Track both criteria changes and disclosure changes so activity decisions stay reproducible. Taxonomy projects break when teams mix the framework regulation with the delegated acts that actually define the criteria and templates. A usable tracker separates the framework layer, the technical-screening layer, the disclosure layer, and the interpretation layer. That is what lets you defend which version you used for a given reporting year. ## The current legal stack Start with the framework regulation, then split the rest into three buckets: criteria acts, disclosure acts, and interpretation notices. This avoids the common mistake of citing the wrong act for the wrong question. In practical terms, teams usually need one column in the tracker for activity criteria and another for disclosure mechanics. - Framework: Regulation (EU) 2020/852 sets the six objectives, Article 3 alignment conditions, Article 8 disclosure hook, and Article 18 minimum safeguards - Climate criteria: Delegated Regulation (EU) 2021/2139 sets the main climate mitigation and adaptation screening criteria - Complementary climate criteria: Delegated Regulation (EU) 2022/1214 adds specific gas and nuclear activities - Environmental criteria: Delegated Regulation (EU) 2023/2486 adds screening criteria for water, circular economy, pollution, and biodiversity - Disclosure mechanics: Delegated Regulation (EU) 2021/2178 sets Article 8 templates and KPI methodology - Disclosure expansion: the 2023 package also updates Article 8 templates to cover the additional environmental objectives - Simplification layer: Delegated Regulation (EU) 2026/73 simplifies parts of 2021/2178, 2021/2139, and 2023/2486 ## What each act changes in practice Your tracker should answer four operational questions: does the act add activities, change thresholds, change DNSH work, or change disclosure templates. If the answer is yes, the impacted pages in your internal workbook and evidence vault should be listed immediately. This is especially important after the 2026 simplification act because it affects both what must be assessed and how it may be presented. - 2021/2139: determines whether a climate-related activity is eligible and what substantial contribution and DNSH tests apply - 2021/2178: determines how turnover, CapEx, OpEx, GAR, GIR, and other Article 8 outputs are calculated and shown - 2022/1214: changes climate activity coverage for certain gas and nuclear activities and adds related disclosure points - 2023/2486: brings the four non-climate objectives into the screening and disclosure system - 2026/73: adds simplification, non-materiality thresholds in certain cases, optional FY 2025 use of the pre-2026 rules, and pushes some financial templates to 2028 ## Interpretation notices belong in the same tracker EUR-Lex notices are not optional reading. They answer the implementation questions that repeatedly cause restatements, such as first-year comparatives, enabling-activity allocation, and how to treat not-material activities when evidence is missing. Treat each notice as a methodology source. Record which FAQs your team relied on and where the answer affects a workbook formula, narrative note, or evidence standard. - 2022/C 385/01: first notice focused on eligibility disclosures - C/2023/305: second notice focused on non-financial reporting of eligible and aligned activities - 2023/C 211/01: minimum safeguards notice explains Article 18 expectations and the link to OECD, UNGP, ILO, and SFDR social PAIs - C/2025/1373: current broad implementation notice covering climate, environmental, and disclosure questions ## Tracker fields that actually help Do not build a decorative tracker. Build one that triggers a task, identifies an owner, and points to the exact activity, note, or workbook tab that changes. A good tracker also separates the legal effective date from the first reporting year in which the change matters. - Act or notice ID and full title - Type: framework, criteria, disclosure, or interpretation - Publication date, entry into force, and application date - Affected activities, entities, and KPIs - Evidence impact: new criterion, removed criterion, or revised DNSH work - Disclosure impact: template, formula, contextual note, or comparative requirement - Internal actions, owner, due date, and methodology note reference *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU Taxonomy Delegated acts tracker across ESG workflows ESG Compliance can take EU Taxonomy Delegated acts tracker from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU Taxonomy can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Taxonomy Delegated acts tracker](/solutions/esg-compliance.md): Start from EU Taxonomy Delegated acts tracker and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Taxonomy](/contact.md): Review your current process, evidence gaps, and next steps for EU Taxonomy Delegated acts tracker. ## Primary sources - [Regulation (EU) 2020/852 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2020/852/oj/eng?ref=sorena.io) - Framework regulation. - [Commission Delegated Regulation (EU) 2021/2139 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2021/2139/oj/eng?ref=sorena.io) - Main climate screening criteria. - [Commission Delegated Regulation (EU) 2021/2178 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Article 8 disclosure methodology. - [Commission Delegated Regulation (EU) 2022/1214 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2022/1214/oj/eng?ref=sorena.io) - Complementary climate criteria for certain gas and nuclear activities. - [Commission Delegated Regulation (EU) 2023/2486 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2023/2486/oj/eng?ref=sorena.io) - Environmental objectives screening criteria and disclosure updates. - [Commission Delegated Regulation (EU) 2026/73 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2026/73/oj/eng?ref=sorena.io) - Current simplification act. - [Commission Notice C/2025/1373 (EUR-Lex)](https://eur-lex.europa.eu/eli/C/2025/1373/oj/eng?ref=sorena.io) - Current implementation notice for climate, environmental, and disclosure questions. ## Related Topic Guides - [EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures](/artifacts/eu/taxonomy-regulation/applicability-test.md): A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose. - [EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs](/artifacts/eu/taxonomy-regulation/checklist.md): An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping. - [EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence](/artifacts/eu/taxonomy-regulation/compliance.md): A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register. - [EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR](/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar.md): A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases. - [EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link](/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards.md): A practical guide to EU Taxonomy DNSH and minimum safeguards. - [EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7)](/artifacts/eu/taxonomy-regulation/penalties-and-fines.md): How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7. - [EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification](/artifacts/eu/taxonomy-regulation/faq.md): A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice. - [EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8](/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow.md): Build an EU Taxonomy disclosure workflow that can survive review. - [EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs](/artifacts/eu/taxonomy-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means. - [EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8](/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities.md): Understand EU Taxonomy scope and reporting entities under Article 8. - [EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail](/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation.md): How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping. - [EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards)](/artifacts/eu/taxonomy-regulation/templates.md): Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register. - [EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting](/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd.md): Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system. - [EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests](/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr.md): Understand the practical relationship between EU Taxonomy and SFDR. - [Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove](/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained.md): A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/taxonomy-regulation/delegated-acts-tracker --- --- title: "EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link" canonical_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards" source_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards" author: "Sorena AI" description: "A practical guide to EU Taxonomy DNSH and minimum safeguards." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Taxonomy DNSH" - "EU Taxonomy minimum safeguards" - "Article 18 Taxonomy" - "OECD UNGP ILO Taxonomy" - "Taxonomy safeguards evidence" - "DNSH evidence Taxonomy" - "2023 C 211 01 minimum safeguards" - "DNSH" - "Minimum safeguards" - "OECD" - "UNGP" - "ILO" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link A practical guide to EU Taxonomy DNSH and minimum safeguards. *EU Taxonomy* *Evidence* ## EU Taxonomy Regulation (EU) 2020/852 DNSH and minimum safeguards These are the parts of Taxonomy alignment that fail most often under review. Treat them as control systems with evidence, testing, remediation, and perimeter coverage. Most undertakings can list eligible activities. Far fewer can prove Taxonomy alignment. The gap is usually in DNSH and minimum safeguards. DNSH requires activity-specific evidence against the delegated-act criteria. Minimum safeguards require enterprise-level due diligence processes that actually operate in practice across the relevant perimeter. Both must be strong enough to support an Article 8 alignment claim. ## DNSH is activity-specific and evidence-heavy DNSH is not a narrative statement that the business is generally responsible. It is a set of negative-condition tests that sit inside the technical screening criteria for the activity you are claiming as aligned. That means the evidence must sit at activity level, site level, or asset level, depending on how the criteria are written. The more generic the claim, the weaker the file usually becomes. - Map each DNSH criterion to a pass or fail decision, the evidence item, the owner, and the review date - Keep boundary notes so the evidence clearly matches the exact activity, asset, site, or project in the KPI numerator - Where criteria require continued performance, define a monitoring cadence instead of treating the test as one-and-done - If one DNSH condition fails or cannot be evidenced, the activity stays out of aligned KPI numerators ## Minimum safeguards are not just a policy pack Article 18 and the 2023 Commission Notice make the standard clearer than many teams assume. Minimum safeguards are procedures implemented by the undertaking. That means the review needs to look at how the undertaking identifies, prevents, mitigates, tracks, communicates, and remediates adverse impacts. The safeguards baseline points to the OECD Guidelines for Multinational Enterprises on Responsible Business Conduct, the UN Guiding Principles on Business and Human Rights, the ILO fundamental principles and rights at work, and the International Bill of Human Rights. - OECD 2023: due diligence across business relationships, complaints channels, remediation, disclosure, and governance - UNGP: policy commitment, human-rights due diligence, leverage, tracking, and access to remedy - ILO 1998 Declaration as amended in 2022: forced labour, child labour, discrimination, freedom of association, collective bargaining, and safe and healthy working environment - The 2023 minimum-safeguards notice also links Article 18(2) to the SFDR DNSH principle through the social and governance principal adverse impact indicators ## What a reviewable safeguards file looks like A reviewable safeguards file is cross-functional. It is not owned by sustainability alone. Legal, procurement, HR, compliance, and internal audit usually each hold part of the evidence. The file must also show coverage. Reviewers will ask which entities, business relationships, and risk areas are actually captured by the procedures you say are in place. - Governance documents: policies, board or committee oversight, escalation routes, and management responsibilities - Due-diligence operation: risk assessments, supplier and partner screening, contract controls, training, and remediation workflows - Remedy and complaints: grievance mechanisms, case logs, investigations, corrective actions, and closure evidence - Coverage map: which entities, geographies, value-chain tiers, and activity owners are inside the procedures - Testing record: internal review, external assurance questions, and how open findings were resolved ## Common failure modes The same weaknesses appear in most failed files. The undertaking may have serious policies, but the evidence chain does not show whether those policies were implemented for the actual reporting perimeter or the reporting year. You should treat the red flags below as automatic triggers for deeper review before making any alignment claim. - DNSH reduced to a generic ESG statement rather than criterion-level evidence - Minimum safeguards shown through policies only, with no operating proof or remediation record - No linkage from aligned numerator to the exact DNSH and safeguards file used for that activity - Perimeter mismatch, where group disclosures cover more entities than the due-diligence procedures actually reach - Open severe incidents or unresolved remediation without clear treatment in the alignment decision *Recommended next step* *Placement: after the scope or definition section* ## Use EU Taxonomy Regulation (EU) 2020/852 DNSH and minimum safeguards as a cited research workflow Research Copilot can take EU Taxonomy Regulation (EU) 2020/852 DNSH and minimum safeguards from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Taxonomy Regulation (EU) 2020/852 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Taxonomy Regulation (EU) 2020/852 DNSH and minimum safeguards](/solutions/research-copilot.md): Start from EU Taxonomy Regulation (EU) 2020/852 DNSH and minimum safeguards and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Taxonomy Regulation (EU) 2020/852](/contact.md): Review your current process, evidence gaps, and next steps for EU Taxonomy Regulation (EU) 2020/852 DNSH and minimum safeguards. ## Primary sources - [Regulation (EU) 2020/852 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2020/852/oj/eng?ref=sorena.io) - Article 3 alignment conditions and Article 18 minimum safeguards. - [Commission Notice 2023/C 211/01 on minimum safeguards (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:JOC_2023_211_R_0001&ref=sorena.io) - Official Commission interpretation of Article 18 and the link to responsible business conduct and SFDR social PAIs. - [Commission Delegated Regulation (EU) 2021/2139 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2021/2139/oj/eng?ref=sorena.io) - Climate objective technical screening criteria, including DNSH conditions. - [Commission Delegated Regulation (EU) 2023/2486 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2023/2486/oj/eng?ref=sorena.io) - Environmental objective technical screening criteria, including DNSH conditions. - [OECD Guidelines for Multinational Enterprises on Responsible Business Conduct (2023)](https://doi.org/10.1787/8f192357-en?ref=sorena.io) - Primary responsible-business-conduct baseline referenced by Article 18. - [UN Guiding Principles on Business and Human Rights (OHCHR)](https://www.ohchr.org/sites/default/files/documents/publications/guidingprinciplesbusinesshr_en.pdf) - Primary human-rights due-diligence framework referenced by Article 18. - [ILO Declaration on Fundamental Principles and Rights at Work (2022 amendment)](https://www.ilo.org/publications/ilo-declaration-fundamental-principles-and-rights-work-and-its-follow) - Current ILO baseline referenced by the Taxonomy safeguards framework. ## Related Topic Guides - [EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures](/artifacts/eu/taxonomy-regulation/applicability-test.md): A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose. - [EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs](/artifacts/eu/taxonomy-regulation/checklist.md): An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping. - [EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence](/artifacts/eu/taxonomy-regulation/compliance.md): A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register. - [EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR](/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar.md): A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases. - [EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73](/artifacts/eu/taxonomy-regulation/delegated-acts-tracker.md): Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts. - [EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7)](/artifacts/eu/taxonomy-regulation/penalties-and-fines.md): How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7. - [EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification](/artifacts/eu/taxonomy-regulation/faq.md): A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice. - [EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8](/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow.md): Build an EU Taxonomy disclosure workflow that can survive review. - [EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs](/artifacts/eu/taxonomy-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means. - [EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8](/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities.md): Understand EU Taxonomy scope and reporting entities under Article 8. - [EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail](/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation.md): How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping. - [EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards)](/artifacts/eu/taxonomy-regulation/templates.md): Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register. - [EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting](/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd.md): Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system. - [EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests](/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr.md): Understand the practical relationship between EU Taxonomy and SFDR. - [Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove](/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained.md): A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards --- --- title: "EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification" canonical_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/faq" source_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/faq" author: "Sorena AI" description: "A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Taxonomy FAQ" - "Article 8 Taxonomy FAQ" - "EU Taxonomy GAR FAQ" - "EU Taxonomy eligibility vs alignment FAQ" - "EU Taxonomy minimum safeguards FAQ" - "Taxonomy 2026 simplification FAQ" - "Article 8" - "GAR" - "Minimum safeguards" - "Delegated Regulation 2026/73" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice. *EU Taxonomy* *FAQ* ## EU Taxonomy FAQ Short answers to the questions that usually slow implementation. Use this page to settle scope, KPI, and evidence questions before they become reporting errors. The questions below focus on the issues that actually affect reporting outcomes: who is in scope, when comparatives start, how enabling activities work, what minimum safeguards require, and what changed in the current simplification package. ## Eligibility vs alignment Q: Is Taxonomy-eligible the same thing as Taxonomy-aligned? A: No. Eligibility means the activity is covered by a Taxonomy activity definition. Alignment means the eligible activity also meets the technical screening criteria, DNSH conditions, and minimum safeguards. Q: Can an activity be eligible but not aligned? A: Yes. That is common, and it must stay out of aligned KPI numerators. - Use separate fields for eligible and aligned in every activity register - Do not let a positive eligibility result be treated as a proxy for alignment - If evidence is incomplete, the safer operational outcome is not aligned until the file is complete ## Scope and first-time reporting Q: Who has to disclose under Article 8? A: Undertakings subject to the sustainability-reporting hooks in Articles 19a or 29a of the Accounting Directive, as further specified by the Article 8 delegated act. Current scope timing should therefore be read together with the current CSRD timetable. Q: Do first-time reporters need N-1 comparatives? A: No. Commission Notice C/2025/1373 says first-time reporters disclose only year N. N-1 comparatives start from the second reporting year. - Large non-listed undertakings were described in Commission guidance as first reporting for FY 2025 with publication in 2026, but later timing should also be checked against Directive (EU) 2025/794 - If you enter scope for the first time, plan the first report as a single-year disclosure rather than a comparative exercise - Even out-of-scope undertakings often still need Taxonomy data because banks, investors, or SFDR products request it ## Article 8 KPIs and GAR Q: What do non-financial undertakings disclose? A: Turnover, CapEx, and OpEx proportions associated with eligible and aligned activities, plus the contextual information required by the templates. Q: What do financial undertakings disclose? A: GAR and other sector-specific KPIs under the delegated act, but the completeness of those KPIs depends heavily on counterparty data quality and coverage. - Financial teams should keep a counterparty data pack request ready before each reporting cycle - The 2026 simplification act delays the fees and commissions and trading-book template start to 2028 - Until 31 December 2027, some financial undertakings that do not claim Taxonomy-associated activities may use a simplified statement route ## Materiality, not-assessed activities, and the 2026 simplification Q: Can we ignore small activities? A: Not automatically. The 2025 Commission Notice said there is no exemption from the obligation to report, but it also clarified that not-material activities lacking data or evidence should be reported as not aligned without further assessment. Q: What changed in 2026? A: Delegated Regulation (EU) 2026/73 introduced targeted simplification, including certain 10% non-materiality thresholds for some financial KPI assessments and the option to apply the old rules for FY 2025. - Do not convert materiality into a silent omission rule unless the legal text expressly allows it - Record non-assessed items separately and explain the treatment in methodology notes - Keep a year-by-year note on whether you used the pre-2026 or post-2026 rule set for FY 2025 ## DNSH and minimum safeguards Q: What is the minimum safeguards test in practice? A: It is a due-diligence and remedy test, not a policy-only test. The evidence should show implemented procedures aligned with OECD, UNGP, ILO, and the International Bill of Human Rights baselines. Q: Can we claim alignment if one DNSH criterion or one safeguards condition is not demonstrated? A: No. A missing or failed condition breaks the alignment claim. - Keep activity-level DNSH evidence and enterprise-level safeguards evidence linked to the same reporting perimeter - Track remediation and unresolved incidents because open issues can affect whether the alignment claim is supportable - Use the 2023 minimum-safeguards notice as the anchor for review criteria *Recommended next step* *Placement: after the FAQ section* ## Use EU Taxonomy FAQ as a cited research workflow Research Copilot can take EU Taxonomy FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on EU Taxonomy can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Taxonomy FAQ](/solutions/research-copilot.md): Start from EU Taxonomy FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Taxonomy](/contact.md): Review your current process, evidence gaps, and next steps for EU Taxonomy FAQ. ## Primary sources - [Commission Notice C/2025/1373 (EUR-Lex)](https://eur-lex.europa.eu/eli/C/2025/1373/oj/eng?ref=sorena.io) - Current implementation notice for reporting questions, comparatives, enabling activities, and materiality handling. - [Commission Delegated Regulation (EU) 2026/73 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2026/73/oj/eng?ref=sorena.io) - Current simplification act for disclosures and parts of the screening criteria. - [Commission Notice C/2023/305 (EUR-Lex)](https://eur-lex.europa.eu/eli/C/2023/305/oj/eng?ref=sorena.io) - Core Article 8 notice for non-financial undertakings. - [Commission Notice 2023/C 211/01 (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:JOC_2023_211_R_0001&ref=sorena.io) - Official notice on minimum safeguards. ## Related Topic Guides - [EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures](/artifacts/eu/taxonomy-regulation/applicability-test.md): A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose. - [EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs](/artifacts/eu/taxonomy-regulation/checklist.md): An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping. - [EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence](/artifacts/eu/taxonomy-regulation/compliance.md): A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register. - [EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR](/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar.md): A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases. - [EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73](/artifacts/eu/taxonomy-regulation/delegated-acts-tracker.md): Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts. - [EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link](/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards.md): A practical guide to EU Taxonomy DNSH and minimum safeguards. - [EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7)](/artifacts/eu/taxonomy-regulation/penalties-and-fines.md): How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7. - [EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8](/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow.md): Build an EU Taxonomy disclosure workflow that can survive review. - [EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs](/artifacts/eu/taxonomy-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means. - [EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8](/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities.md): Understand EU Taxonomy scope and reporting entities under Article 8. - [EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail](/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation.md): How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping. - [EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards)](/artifacts/eu/taxonomy-regulation/templates.md): Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register. - [EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting](/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd.md): Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system. - [EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests](/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr.md): Understand the practical relationship between EU Taxonomy and SFDR. - [Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove](/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained.md): A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/taxonomy-regulation/faq --- --- title: "EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8" canonical_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow" source_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow" author: "Sorena AI" description: "Build an EU Taxonomy disclosure workflow that can survive review." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Taxonomy KPIs" - "Article 8 Taxonomy workflow" - "Taxonomy turnover KPI" - "Taxonomy CapEx KPI" - "Taxonomy OpEx KPI" - "GAR workflow" - "Taxonomy disclosure controls" - "Taxonomy 2026 simplification" - "Article 8 workflow" - "GAR" - "Turnover CapEx OpEx" - "Taxonomy controls" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8 Build an EU Taxonomy disclosure workflow that can survive review. *EU Taxonomy* *Workflow* ## EU Taxonomy KPIs and disclosure workflow Build the workflow backward from the published tables. That is the fastest way to see which data, criteria files, and approvals you actually need. The best Taxonomy workflow starts at the reporting output and works backward. Ask what tables and notes you must publish, what aligned and eligible numbers feed those tables, what activity decisions feed those numbers, and what evidence supports those decisions. When teams skip that chain, the KPI workbook becomes impossible to defend. ## The workflow end to end The sequence should be stable every year: scope, activity inventory, eligibility, alignment, evidence, KPI calculation, contextual note drafting, review, and sign-off. Do not calculate KPIs before the eligibility and alignment register is frozen. Otherwise the number owners and evidence owners are working from different populations. - Scope memo and entity perimeter confirmed - Activity register locked with revenue, CapEx, and OpEx mappings - Eligibility and alignment decisions completed with versioned legal references - DNSH and minimum-safeguards files linked to each aligned activity - KPI workbook calculated and reconciled - Contextual information and methodology notes drafted - Review, assurance challenge, and approval completed before publication ## Non-financial undertaking workflow Non-financial undertakings disclose turnover, CapEx, and OpEx. The hardest part is usually not the formula. It is deciding what belongs in the activity register, what belongs in the denominator, and which activities can truly be included as aligned. The 2025 Commission Notice also matters operationally because it clarifies first-year comparatives, enabling-activity allocation, and how to handle activities that are not material when evidence is missing. - Map audited denominators first so the reporting population is financially anchored - Build numerator populations only after eligibility and alignment are separately documented - Keep not-aligned and not-assessed activities out of the aligned numerator and explain the treatment clearly - For first-time reporting years, publish only year N and add N-1 comparatives from the second year onward - Where enabling activities are involved, use a verifiable allocation method and explain it in contextual notes ## Financial undertaking workflow For financial undertakings, the workflow depends on counterparty disclosures. That means the program needs both internal controls and a disciplined external data-request process. The 2026 simplification act adds two critical workflow changes. First, some financial undertakings may use a simplified statement route until the end of 2027 if they make no Taxonomy-associated activity claim. Second, fees and commissions and trading-book templates start only from 2028. - Refresh the counterparty population and identify which counterparties are in Article 8 scope, voluntarily reporting, or outside scope - Track data lineage from counterparty publication to GAR or other financial KPI workbook tabs - Use separate controls for missing, estimated, voluntary, and directly evidenced activity data - Document whether the undertaking uses the simplified statement route or the full template route during the transitional period - Prepare now for 2028 if fees and commissions or trading-book metrics will be relevant ## Controls that prevent rework and restatement Most Taxonomy errors are governance errors. They come from untracked scope changes, undocumented judgment calls, or workbook logic that cannot be reproduced after publication. The controls below are the minimum for a publication-grade process. - Freeze the delegated-act version set for the reporting year and log any permitted transitional election - Require a file reference for every aligned activity in the numerator - Reconcile every denominator to audited financial statement figures - Maintain a change log for activity mapping, formulas, assumptions, and reviewer decisions - Keep narrative notes in sync with the actual workbook logic and exception treatment *Recommended next step* *Placement: near the end of the main content before related guides* ## Operationalize EU Taxonomy KPIs and disclosure workflow across ESG workflows ESG Compliance can take EU Taxonomy KPIs and disclosure workflow from operationalizing this sustainability obligation across workflows and reporting to a reusable workflow inside Sorena. Teams working on EU Taxonomy can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Taxonomy KPIs and disclosure workflow](/solutions/esg-compliance.md): Start from EU Taxonomy KPIs and disclosure workflow and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Taxonomy](/contact.md): Review your current process, evidence gaps, and next steps for EU Taxonomy KPIs and disclosure workflow. ## Primary sources - [Commission Delegated Regulation (EU) 2021/2178 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Article 8 KPI methodology and core templates. - [Commission Notice C/2023/305 (EUR-Lex)](https://eur-lex.europa.eu/eli/C/2023/305/oj/eng?ref=sorena.io) - Non-financial reporting implementation guidance. - [Commission Notice C/2025/1373 (EUR-Lex)](https://eur-lex.europa.eu/eli/C/2025/1373/oj/eng?ref=sorena.io) - Current guidance on comparatives, enabling activities, and updated templates. - [Commission Delegated Regulation (EU) 2026/73 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2026/73/oj/eng?ref=sorena.io) - Current simplification act affecting disclosures, transitional options, and certain financial templates. ## Related Topic Guides - [EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures](/artifacts/eu/taxonomy-regulation/applicability-test.md): A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose. - [EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs](/artifacts/eu/taxonomy-regulation/checklist.md): An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping. - [EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence](/artifacts/eu/taxonomy-regulation/compliance.md): A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register. - [EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR](/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar.md): A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases. - [EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73](/artifacts/eu/taxonomy-regulation/delegated-acts-tracker.md): Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts. - [EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link](/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards.md): A practical guide to EU Taxonomy DNSH and minimum safeguards. - [EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7)](/artifacts/eu/taxonomy-regulation/penalties-and-fines.md): How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7. - [EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification](/artifacts/eu/taxonomy-regulation/faq.md): A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice. - [EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs](/artifacts/eu/taxonomy-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means. - [EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8](/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities.md): Understand EU Taxonomy scope and reporting entities under Article 8. - [EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail](/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation.md): How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping. - [EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards)](/artifacts/eu/taxonomy-regulation/templates.md): Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register. - [EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting](/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd.md): Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system. - [EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests](/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr.md): Understand the practical relationship between EU Taxonomy and SFDR. - [Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove](/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained.md): A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow --- --- title: "EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7)" canonical_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/penalties-and-fines" author: "Sorena AI" description: "How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Taxonomy penalties" - "EU Taxonomy fines" - "EU Taxonomy enforcement" - "EU Taxonomy measures and penalties" - "Article 5 6 7 EU Taxonomy disclosures enforcement" - "misleading sustainability disclosures taxonomy" - "competent authorities EU Taxonomy" - "Measures and penalties" - "Misleading disclosures" - "Competent authorities" - "Audit trail" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7) How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7. *EU Taxonomy* *Enforcement* ## EU Taxonomy Regulation (EU) 2020/852 Penalties and fines Penalties are national - but the triggers are predictable. Reduce exposure with scope controls, evidence packs, and reproducible KPI workflows. EU Taxonomy creates disclosure obligations and a framework that is monitored by competent authorities. In practice, enforcement risk arises when disclosures are misleading, inconsistent, or not substantiated. This page focuses on the issues authorities and reviewers tend to probe: scope discipline, evidence traceability, and KPI reproducibility. ## What EU Taxonomy enforcement targets (in practice) The Taxonomy Regulation requires Member States to ensure competent authorities monitor compliance for the relevant disclosure requirements, and to lay down rules on measures and penalties for infringements of specific disclosure provisions. In practice, exposure often comes from misleading or unsupported sustainability claims and inconsistent application of criteria across entities or periods. - Scope drift: unclear perimeter or activity boundaries leading to inconsistent KPIs - Eligibility and alignment confusion: eligible is reported as aligned without criteria evidence - DNSH/safeguards gaps: alignment claimed without safeguards due diligence proof - Reproducibility gaps: KPIs cannot be re-run or reconciled to audited numbers *Recommended next step* *Placement: after the enforcement section* ## Use EU Taxonomy Regulation (EU) 2020/852 Penalties and fines as a cited research workflow Research Copilot can take EU Taxonomy Regulation (EU) 2020/852 Penalties and fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on EU Taxonomy Regulation (EU) 2020/852 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Taxonomy Regulation (EU) 2020/852 Penalties and fines](/solutions/research-copilot.md): Start from EU Taxonomy Regulation (EU) 2020/852 Penalties and fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Taxonomy Regulation (EU) 2020/852](/contact.md): Review your current process, evidence gaps, and next steps for EU Taxonomy Regulation (EU) 2020/852 Penalties and fines. ## Measures and penalties (what the regulation requires Member States to provide) The regulation requires Member States to lay down rules on measures and penalties applicable to infringements of certain provisions. Those measures and penalties must be effective, proportionate and dissuasive. That means the exact fine numbers vary by Member State, but the compliance expectation is consistent: disclosures must be truthful, consistent, and substantiated. - National measures and penalties apply for disclosure-related infringements (Articles 5-7) - Penalties must be effective, proportionate, and dissuasive (national implementation varies) - Risk is not only fines: enforcement actions, restatements, and reputational impacts can be larger ## The penalty-exposure playbook (controls that prevent escalations) You reduce exposure by making unsupported claims hard to publish. That means: controlled scope, evidence packs, repeatable KPI workflows, and delegated act change control. If you can answer why an activity is aligned with a criteria mapping and evidence pointers, enforcement tends to stay manageable. - Release gate: no publish without scope memo + criteria mapping + evidence pack index - Evidence vault: activity-level folders with stable indexing and revision control - KPI controls: reconciliations, estimates policy, and change log - Delegated acts tracker: versioning and re-assessment triggers when criteria change - Pre-assurance review: catch scope/traceability issues before external scrutiny ## Primary sources - [Regulation (EU) 2020/852 (EU Taxonomy Regulation) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2020/852/oj?ref=sorena.io) - Competent authorities and measures/penalties provisions; also frames disclosure obligations. - [EU Taxonomy for sustainable activities (European Commission hub)](https://finance.ec.europa.eu/sustainable-finance/tools-and-standards/eu-taxonomy-sustainable-activities_en?ref=sorena.io) - Official access point for FAQs and supporting guidance. ## Related Topic Guides - [EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures](/artifacts/eu/taxonomy-regulation/applicability-test.md): A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose. - [EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs](/artifacts/eu/taxonomy-regulation/checklist.md): An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping. - [EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence](/artifacts/eu/taxonomy-regulation/compliance.md): A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register. - [EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR](/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar.md): A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases. - [EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73](/artifacts/eu/taxonomy-regulation/delegated-acts-tracker.md): Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts. - [EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link](/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards.md): A practical guide to EU Taxonomy DNSH and minimum safeguards. - [EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification](/artifacts/eu/taxonomy-regulation/faq.md): A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice. - [EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8](/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow.md): Build an EU Taxonomy disclosure workflow that can survive review. - [EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs](/artifacts/eu/taxonomy-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means. - [EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8](/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities.md): Understand EU Taxonomy scope and reporting entities under Article 8. - [EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail](/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation.md): How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping. - [EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards)](/artifacts/eu/taxonomy-regulation/templates.md): Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register. - [EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting](/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd.md): Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system. - [EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests](/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr.md): Understand the practical relationship between EU Taxonomy and SFDR. - [Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove](/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained.md): A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/taxonomy-regulation/penalties-and-fines --- --- title: "EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs" canonical_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/requirements" source_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/requirements" author: "Sorena AI" description: "A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Taxonomy requirements" - "EU Taxonomy Regulation 2020/852 requirements" - "taxonomy eligibility requirements" - "taxonomy alignment requirements" - "technical screening criteria documentation" - "DNSH requirements" - "minimum safeguards OECD UNGP ILO" - "Article 8 taxonomy KPIs turnover CapEx OpEx GAR" - "Technical screening criteria" - "DNSH" - "Minimum safeguards" - "Article 8 KPIs" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means. *EU Taxonomy* *Requirements* ## EU Taxonomy Regulation (EU) 2020/852 Requirements Eligibility is not enough - alignment and evidence decide disclosure quality. Use this as a requirements map for KPIs, delegated acts, and audit-ready evidence. EU Taxonomy requirements are easiest to implement as a chain: classify activities -> decide eligibility -> test alignment against technical screening criteria -> document DNSH + minimum safeguards -> compute and disclose Article 8 KPIs with traceable evidence. If any link is missing, the disclosure becomes fragile under assurance or stakeholder challenge. ## Alignment requirements: the four conditions you must satisfy Taxonomy alignment is defined by four conditions: (1) substantial contribution to at least one environmental objective, (2) do no significant harm (DNSH) to the others, (3) compliance with minimum safeguards, and (4) compliance with technical screening criteria (TSC) set in delegated acts. Operationally, this means you need an activity-level criteria mapping and evidence pack - not just a narrative. - Substantial contribution: meet the relevant TSC for the objective you claim - DNSH: meet DNSH criteria for the other objectives covered by that activity's criteria set - Minimum safeguards: responsible business conduct / human rights baseline is in place - TSC versioning: apply the criteria as defined for the reporting year and record the version *Recommended next step* *Placement: after the requirement breakdown* ## Operationalize EU Taxonomy Regulation (EU) 2020/852 Requirements across ESG workflows ESG Compliance can take EU Taxonomy Regulation (EU) 2020/852 Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on EU Taxonomy Regulation (EU) 2020/852 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open ESG Compliance for EU Taxonomy Regulation (EU) 2020/852 Requirements](/solutions/esg-compliance.md): Start from EU Taxonomy Regulation (EU) 2020/852 Requirements and manage cross team sustainability work, reporting, and evidence from one workflow. - [Talk through EU Taxonomy Regulation (EU) 2020/852](/contact.md): Review your current process, evidence gaps, and next steps for EU Taxonomy Regulation (EU) 2020/852 Requirements. ## Eligibility vs alignment: what you can claim and what you must prove Eligibility is a coverage check: the activity matches a taxonomy activity definition in delegated acts. Alignment is a compliance claim: you meet all criteria and can substantiate it. This distinction directly affects KPI numerators: only aligned activity components belong in aligned KPI numerators. - Eligibility register: activities mapped to accounts, sites, assets, and project boundaries - Alignment register: pass/fail per criterion with evidence pointers and owner - Non-alignment handling: a controlled way to keep eligible-but-not-aligned out of aligned KPI numerators - Change control: reassess when delegated acts expand/adjust criteria ## Disclosure requirements: Article 8 KPIs and accompanying information The disclosures delegated act defines KPI templates, calculation rules, and phase-in dates. Non-financial undertakings disclose turnover/CapEx/OpEx proportions related to taxonomy-aligned activities. Financial undertakings disclose their own taxonomy KPIs (including GAR) that depend on counterparty data flows. Treat KPI reporting as a recurring close process: a controlled workbook, reconciliations to audited numbers, and consistent methodological notes. - Non-financial KPIs: turnover KPI, CapEx KPI, OpEx KPI (aligned vs total) - Financial KPIs: GAR and other KPI templates; dependency on counterparty taxonomy KPIs - Accompanying information: narratives, methodology notes, estimates policy, and limitations - Audit trail: ability to reproduce KPI calculations and justify each numerator component ## Evidence and governance: what you need to make claims auditable Evidence quality is traceability: KPI numerator -> activity -> criteria -> evidence -> owner -> timestamp. Without that chain, assurance cost and reporting risk both rise. Define evidence packs per activity, and store them in a stable structure with a consistent index. - Criteria mapping file: criterion-by-criterion checklist with pass/fail and evidence links - DNSH evidence: assessments, permits, monitoring data, compliance attestations - Minimum safeguards evidence: due diligence processes, grievance mechanisms, remediation tracking - Controls: review gates and periodic refresh so evidence remains current ## Primary sources - [Regulation (EU) 2020/852 (EU Taxonomy Regulation) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2020/852/oj?ref=sorena.io) - Core definitions, objectives, and alignment conditions. - [Disclosures Delegated Act (Article 8) - Commission Delegated Regulation (EU) 2021/2178 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - KPI definitions, templates, and phase-in. - [Climate Delegated Act - Commission Delegated Regulation (EU) 2021/2139 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2021/2139/oj/eng?ref=sorena.io) - Technical screening criteria for climate objectives. - [Environmental Delegated Act - Commission Delegated Regulation (EU) 2023/2486 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2023/2486/oj/eng?ref=sorena.io) - Technical screening criteria for non-climate objectives. - [Commission Notice on the Disclosures Delegated Act (OJ C 2023/305) (EUR-Lex)](https://eur-lex.europa.eu/eli/C/2023/305/oj/eng?ref=sorena.io) - Interpretive guidance and practical reporting clarifications. ## Related Topic Guides - [EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures](/artifacts/eu/taxonomy-regulation/applicability-test.md): A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose. - [EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs](/artifacts/eu/taxonomy-regulation/checklist.md): An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping. - [EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence](/artifacts/eu/taxonomy-regulation/compliance.md): A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register. - [EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR](/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar.md): A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases. - [EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73](/artifacts/eu/taxonomy-regulation/delegated-acts-tracker.md): Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts. - [EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link](/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards.md): A practical guide to EU Taxonomy DNSH and minimum safeguards. - [EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7)](/artifacts/eu/taxonomy-regulation/penalties-and-fines.md): How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7. - [EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification](/artifacts/eu/taxonomy-regulation/faq.md): A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice. - [EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8](/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow.md): Build an EU Taxonomy disclosure workflow that can survive review. - [EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8](/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities.md): Understand EU Taxonomy scope and reporting entities under Article 8. - [EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail](/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation.md): How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping. - [EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards)](/artifacts/eu/taxonomy-regulation/templates.md): Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register. - [EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting](/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd.md): Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system. - [EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests](/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr.md): Understand the practical relationship between EU Taxonomy and SFDR. - [Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove](/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained.md): A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/taxonomy-regulation/requirements --- --- title: "EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8" canonical_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities" source_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities" author: "Sorena AI" description: "Understand EU Taxonomy scope and reporting entities under Article 8." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Taxonomy scope" - "Article 8 who must disclose" - "EU Taxonomy reporting entities" - "Taxonomy financial undertakings" - "Taxonomy non-financial undertakings" - "GAR data requests" - "Taxonomy CSRD linkage" - "Article 8" - "Reporting entities" - "CSRD linkage" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8 Understand EU Taxonomy scope and reporting entities under Article 8. *EU Taxonomy* *Scope* ## EU Taxonomy Scope and reporting entities Scope is not just a yes or no answer. You need to decide who must publish, which template family applies, and which non-reporters still need to produce Taxonomy data. Taxonomy scope has three layers. First, decide who is legally required to publish Article 8 disclosures through the Accounting Directive hooks. Second, decide whether the undertaking follows the non-financial or financial KPI model. Third, decide which entities, activities, and counterparties still need Taxonomy data even if they are not direct reporters. ## Who must disclose under Article 8 Article 8 disclosures are linked to undertakings subject to the sustainability-reporting hooks in Articles 19a or 29a of Directive 2013/34/EU, as further specified by the delegated act. That means scope must be read together with the current accounting and CSRD timing rules. As a practical matter, there are already-reporting entities and later-wave entities. The later waves should be checked against Directive (EU) 2025/794 because that directive deferred certain CSRD entry dates. This is a legal inference from the Accounting Directive hook, not a separate new Taxonomy rule. - Non-financial undertakings in scope publish turnover, CapEx, and OpEx Taxonomy outputs - Financial undertakings in scope publish GAR and other sector-specific KPI outputs - Later-wave entrants should read Article 8 scope together with the current deferred CSRD application dates - First-time reporters should plan a single-year first report, with comparatives only from the second reporting year ## Why out-of-scope companies still need Taxonomy data Many companies that are not direct Article 8 reporters still get pulled into Taxonomy work because a bank, insurer, asset manager, investor, customer, or green-finance framework asks for the data. This is especially common where a financial institution needs counterparty information to support GAR or other product and portfolio metrics. - Lenders ask for activity classification, eligibility, and sometimes alignment evidence - Investors and SFDR-linked products often ask for the same data in a more narrative form - Parent groups may request subsidiary-level Taxonomy data even where the subsidiary is not a stand-alone reporter - The clean answer is a counterparty Taxonomy data pack rather than repeated ad hoc questionnaires *Recommended next step* *Placement: after the scope or definition section* ## Use EU Taxonomy Scope and reporting entities as a cited research workflow Research Copilot can take EU Taxonomy Scope and reporting entities from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on EU Taxonomy can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Taxonomy Scope and reporting entities](/solutions/research-copilot.md): Start from EU Taxonomy Scope and reporting entities and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Taxonomy](/contact.md): Review your current process, evidence gaps, and next steps for EU Taxonomy Scope and reporting entities. ## Reporting perimeter and group boundary Once scope is decided, the next control is perimeter. The Taxonomy denominator and numerator population should follow the same entity boundary logic that the reporting regime requires. If the group boundary, consolidation method, or business-combination treatment is unclear, the KPIs will usually fail under assurance before any technical-screening issue is even reviewed. - Define the entity list and consolidation treatment for every included undertaking - Assign which entity owns the activity evidence and which team owns the KPI inputs - Keep an acquisition, disposal, and reorganization change log tied to the reporting year - Reconcile denominators to audited figures for the exact reporting perimeter ## Activity scope and template family The same legal entity can have several activity populations and more than one disclosure challenge. What matters is not only who the reporter is, but also whether the activity is mapped cleanly and whether the correct template family is being used. A good scope memo therefore includes both the legal conclusion and the operational conclusion. - Record whether the undertaking follows the non-financial KPI route or a financial KPI route - Map revenue lines, CapEx projects, and relevant OpEx categories to activity IDs - Record where the undertaking is relying on direct evidence, counterparty data, voluntary data, or no data - Keep scope decisions, workbook assumptions, and methodology notes aligned ## Primary sources - [Regulation (EU) 2020/852 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2020/852/oj/eng?ref=sorena.io) - Article 8 disclosure hook. - [Commission Delegated Regulation (EU) 2021/2178 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Scope of the disclosure methodology and KPI families. - [Commission Notice C/2023/305 (EUR-Lex)](https://eur-lex.europa.eu/eli/C/2023/305/oj/eng?ref=sorena.io) - Scope and implementation questions for non-financial undertakings. - [Commission Notice C/2025/1373 (EUR-Lex)](https://eur-lex.europa.eu/eli/C/2025/1373/oj/eng?ref=sorena.io) - Current implementation notice, including first-time comparative treatment and updated template use. - [Directive (EU) 2025/794 (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current deferred CSRD timetable. Its relevance to later Article 8 entrants is an inference from the Accounting Directive reporting hook. ## Related Topic Guides - [EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures](/artifacts/eu/taxonomy-regulation/applicability-test.md): A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose. - [EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs](/artifacts/eu/taxonomy-regulation/checklist.md): An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping. - [EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence](/artifacts/eu/taxonomy-regulation/compliance.md): A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register. - [EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR](/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar.md): A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases. - [EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73](/artifacts/eu/taxonomy-regulation/delegated-acts-tracker.md): Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts. - [EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link](/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards.md): A practical guide to EU Taxonomy DNSH and minimum safeguards. - [EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7)](/artifacts/eu/taxonomy-regulation/penalties-and-fines.md): How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7. - [EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification](/artifacts/eu/taxonomy-regulation/faq.md): A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice. - [EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8](/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow.md): Build an EU Taxonomy disclosure workflow that can survive review. - [EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs](/artifacts/eu/taxonomy-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means. - [EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail](/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation.md): How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping. - [EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards)](/artifacts/eu/taxonomy-regulation/templates.md): Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register. - [EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting](/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd.md): Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system. - [EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests](/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr.md): Understand the practical relationship between EU Taxonomy and SFDR. - [Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove](/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained.md): A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities --- --- title: "EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail" canonical_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation" source_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation" author: "Sorena AI" description: "How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Taxonomy technical screening criteria documentation" - "taxonomy evidence pack" - "taxonomy criteria mapping template" - "substantial contribution DNSH evidence" - "minimum safeguards evidence pack" - "EU Taxonomy alignment documentation" - "Article 8 taxonomy evidence" - "Technical screening criteria" - "Evidence packs" - "DNSH" - "Minimum safeguards" - "Assurance readiness" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping. *EU Taxonomy* *Evidence* ## EU Taxonomy Screening criteria and documentation Alignment is a documentation problem before it's a math problem. Build a criteria-by-criteria evidence pack that ties directly to KPI numerators. Technical screening criteria (TSC) are the operational core of EU Taxonomy alignment. If you cannot show criterion-by-criterion evidence - including DNSH and minimum safeguards - you don't have an alignment claim you can defend. This page describes an evidence model that is structured, versioned, and reproducible. ## Start with the activity boundary (or your evidence will not match your claim) Before reading criteria, define the activity boundary: what assets/sites/projects are covered, and how that maps to revenue/CapEx/OpEx lines. Most assurance issues start here: evidence exists, but it covers a different boundary than the disclosed activity. - Activity definition: map your activity to the delegated act definition with a written rationale - Boundary statement: what's included/excluded (sites, assets, subsidiaries, time period) - Data sources: which systems produce the metrics that will support criteria checks - Owner: who is accountable for maintaining the activity evidence pack *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Use EU Taxonomy Screening criteria and documentation as a cited research workflow Research Copilot can take EU Taxonomy Screening criteria and documentation from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Taxonomy can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Taxonomy Screening criteria and documentation](/solutions/research-copilot.md): Start from EU Taxonomy Screening criteria and documentation and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Taxonomy](/contact.md): Review your current process, evidence gaps, and next steps for EU Taxonomy Screening criteria and documentation. ## Build a criteria mapping file (the single source of truth) For each eligible activity, create a criteria mapping file: every criterion has a pass/fail, the metric/value, and an evidence pointer. This file is the bridge between operations and disclosure: it explains why a KPI numerator component is aligned. - Substantial contribution: criterion-by-criterion checks and evidence - DNSH: criterion-by-criterion checks across other objectives (as defined for the activity) - Minimum safeguards: due diligence evidence baseline and coverage statement - Evidence pointers: direct links/paths to documents (assessments, permits, monitoring, policies) - Versioning: delegated act version and reporting year recorded on the mapping file ## Evidence pack structure (what to store per activity) Store evidence in a stable structure so you can answer questions fast. Avoid ad-hoc attachments - use an evidence vault with an index. Evidence should be attributable (owner + timestamp), complete (covers the boundary), and durable (can be retrieved later). - Activity summary: boundary, rationale, and criteria version used - Metrics: source system extracts and calculation notes - Assessments and permits: technical reports, compliance permits, independent reviews where relevant - Monitoring: ongoing performance data for criteria that require continuous compliance - Safeguards: due diligence process docs, grievance mechanisms, remediation tracking ## Link evidence to KPIs (so Article 8 reporting stays defensible) The evidence model should connect directly to KPI workbook inputs: aligned numerator components must be traceable to aligned activities and their evidence packs. Build the link explicitly: KPI line items should reference activity IDs and evidence pack locations. - KPI workbook references activity IDs (not informal names) - Each numerator component has a criteria mapping reference and evidence pack pointer - Reconciliations: denominators tie to audited numbers and consolidation rules - Methodology notes: estimates/proxies policy and limitation disclosures stay consistent ## Primary sources - [Climate Delegated Act - Commission Delegated Regulation (EU) 2021/2139 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2021/2139/oj/eng?ref=sorena.io) - Technical screening criteria for climate objectives (substantial contribution + DNSH criteria). - [Environmental Delegated Act - Commission Delegated Regulation (EU) 2023/2486 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2023/2486/oj/eng?ref=sorena.io) - Technical screening criteria for non-climate objectives (substantial contribution + DNSH criteria). - [Regulation (EU) 2020/852 (EU Taxonomy Regulation) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2020/852/oj?ref=sorena.io) - Core alignment conditions including DNSH and minimum safeguards. - [Commission Notice on EU Taxonomy interpretation and implementation (CELEX:52023XC0616(01)) (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52023XC0616(01)&ref=sorena.io) - Commission guidance to support consistent interpretation and implementation. ## Related Topic Guides - [EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures](/artifacts/eu/taxonomy-regulation/applicability-test.md): A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose. - [EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs](/artifacts/eu/taxonomy-regulation/checklist.md): An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping. - [EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence](/artifacts/eu/taxonomy-regulation/compliance.md): A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register. - [EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR](/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar.md): A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases. - [EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73](/artifacts/eu/taxonomy-regulation/delegated-acts-tracker.md): Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts. - [EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link](/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards.md): A practical guide to EU Taxonomy DNSH and minimum safeguards. - [EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7)](/artifacts/eu/taxonomy-regulation/penalties-and-fines.md): How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7. - [EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification](/artifacts/eu/taxonomy-regulation/faq.md): A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice. - [EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8](/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow.md): Build an EU Taxonomy disclosure workflow that can survive review. - [EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs](/artifacts/eu/taxonomy-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means. - [EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8](/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities.md): Understand EU Taxonomy scope and reporting entities under Article 8. - [EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards)](/artifacts/eu/taxonomy-regulation/templates.md): Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register. - [EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting](/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd.md): Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system. - [EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests](/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr.md): Understand the practical relationship between EU Taxonomy and SFDR. - [Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove](/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained.md): A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation --- --- title: "Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove" canonical_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained" source_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained" author: "Sorena AI" description: "A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "taxonomy eligibility vs alignment" - "EU Taxonomy eligibility" - "EU Taxonomy alignment" - "taxonomy eligible vs taxonomy aligned" - "Article 8 taxonomy eligible vs aligned disclosures" - "EU Taxonomy Regulation 2020/852 explained" - "technical screening criteria DNSH minimum safeguards" - "Eligibility" - "Alignment" - "Article 8 KPIs" - "Technical screening criteria" - "Audit trail" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed. *EU Taxonomy* *Explainer* ## EU Taxonomy Eligibility vs alignment Eligibility is a scope check. Alignment is a compliance claim. Use this page to keep your KPI numerators defensible and your disclosures precise. This distinction drives many taxonomy reporting failures. Eligibility answers whether the activity is covered by Taxonomy criteria. Alignment answers whether it meets the technical screening criteria, DNSH, and minimum safeguards, and whether you can prove it. If you report eligibility as alignment, you inflate aligned KPIs and create assurance risk. ## Definitions you can operationalize Eligibility: the activity matches a Taxonomy activity definition in the delegated acts. You cannot be aligned if you are not eligible. Alignment: the eligible activity meets (a) substantial contribution criteria, (b) DNSH criteria, (c) minimum safeguards, and (d) any other conditions defined in the technical screening criteria. - Eligibility outputs: an activity mapping register and rationale for matching the activity definition - Alignment outputs: pass/fail per criterion with evidence pointers and owners - Disclosure impact: aligned KPIs should only include aligned activity components - Assurance impact: alignment claims require reproducible evidence packs ## How the difference shows up in Article 8 KPIs The disclosures delegated act phases in reporting. Early disclosures emphasize taxonomy-eligible proportions; later disclosures require aligned KPIs and accompanying information. If you get this distinction wrong, you will either under-report alignment (missing opportunities) or over-report alignment (assurance and credibility risk). - Eligibility phase: inventory and classify activities; disclose eligible vs non-eligible - Aligned KPI phase: implement criteria checks and evidence vault; compute aligned KPI numerators - Financial KPIs: banks/insurers' KPIs depend on investee/counterparty aligned KPIs - Comparability: keep a versioned record of criteria used for each reporting year *Recommended next step* *Placement: after the comparison section* ## Use EU Taxonomy Eligibility vs alignment as a cited research workflow Research Copilot can take EU Taxonomy Eligibility vs alignment from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Taxonomy can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Taxonomy Eligibility vs alignment](/solutions/research-copilot.md): Start from EU Taxonomy Eligibility vs alignment and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Taxonomy](/contact.md): Review your current process, evidence gaps, and next steps for EU Taxonomy Eligibility vs alignment. ## Decision table (copy/paste for internal reviews) Use this decision table to standardize language across finance, sustainability, and assurance. The goal is to make claims precise and evidence-backed. Tip: maintain this as a controlled register with links to the evidence pack for each activity. - Eligible + not aligned: disclose eligibility (where required), exclude from aligned KPI numerator - Eligible + aligned: include in aligned numerator, with criteria evidence and safeguards proof - Not eligible: classify as non-eligible; no alignment claim possible - Not assessed: treat as not aligned until the criteria mapping and evidence are complete ## Primary sources - [Regulation (EU) 2020/852 (EU Taxonomy Regulation) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2020/852/oj?ref=sorena.io) - Defines objectives and alignment conditions (substantial contribution, DNSH, minimum safeguards). - [Disclosures Delegated Act (Article 8) - Commission Delegated Regulation (EU) 2021/2178 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Requires eligibility vs alignment disclosures and defines KPI computation. - [Commission Notice on the Disclosures Delegated Act (OJ C 2023/305) (EUR-Lex)](https://eur-lex.europa.eu/eli/C/2023/305/oj/eng?ref=sorena.io) - Practical interpretive guidance for taxonomy-eligible vs taxonomy-aligned disclosures. ## Related Topic Guides - [EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures](/artifacts/eu/taxonomy-regulation/applicability-test.md): A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose. - [EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs](/artifacts/eu/taxonomy-regulation/checklist.md): An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping. - [EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence](/artifacts/eu/taxonomy-regulation/compliance.md): A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register. - [EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR](/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar.md): A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases. - [EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73](/artifacts/eu/taxonomy-regulation/delegated-acts-tracker.md): Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts. - [EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link](/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards.md): A practical guide to EU Taxonomy DNSH and minimum safeguards. - [EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7)](/artifacts/eu/taxonomy-regulation/penalties-and-fines.md): How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7. - [EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification](/artifacts/eu/taxonomy-regulation/faq.md): A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice. - [EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8](/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow.md): Build an EU Taxonomy disclosure workflow that can survive review. - [EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs](/artifacts/eu/taxonomy-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means. - [EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8](/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities.md): Understand EU Taxonomy scope and reporting entities under Article 8. - [EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail](/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation.md): How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping. - [EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards)](/artifacts/eu/taxonomy-regulation/templates.md): Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register. - [EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting](/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd.md): Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system. - [EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests](/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr.md): Understand the practical relationship between EU Taxonomy and SFDR. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained --- --- title: "EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting" canonical_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd" source_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd" author: "Sorena AI" description: "Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Taxonomy vs CSRD" - "Article 8 and CSRD" - "Taxonomy CSRD overlap" - "Taxonomy ESRS relationship" - "Taxonomy assurance CSRD" - "CSRD deferred reporting Taxonomy" - "Article 8" - "CSRD" - "ESRS" - "Assurance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system. *EU Taxonomy* *Comparison* ## EU Taxonomy vs CSRD Taxonomy is a classification and KPI regime. CSRD is the wider reporting architecture. The smart implementation move is to share controls and evidence without collapsing the two into one test. Taxonomy and CSRD meet in the same management report for many undertakings, but they do not ask the same question. Taxonomy asks whether specific economic activities meet technical conditions for environmental sustainability and how that shows up in KPIs. CSRD asks for a broader sustainability statement built on ESRS. The operational challenge is integration without confusion. ## What each regime is trying to do EU Taxonomy is activity-level, threshold-driven, and formula-based. It produces eligibility and alignment outputs and requires supporting evidence that can justify each aligned claim. CSRD is wider. It requires sustainability reporting across governance, strategy, impacts, risks, opportunities, and topic-specific metrics under ESRS. - Taxonomy: classification, technical screening criteria, DNSH, minimum safeguards, and Article 8 KPIs - CSRD: broad sustainability reporting architecture with ESRS-based disclosures - Taxonomy evidence is criterion-level and activity-level - CSRD evidence is broader and includes governance, policies, actions, targets, and topic metrics ## Where the overlap is real The overlap is not that Taxonomy replaces CSRD or vice versa. The overlap is that both rely on the same reporting perimeter, the same finance and operations mapping, the same change logs, and the same assurance discipline. If you build a clean activity register, denominator reconciliations, and a documented evidence vault, those controls support both reporting streams. - Shared perimeter logic and entity change log - Shared finance data and denominator reconciliations - Shared governance over methodologies, estimates, and controls - Shared evidence vault, with Taxonomy criteria files nested inside the broader sustainability evidence structure ## Where teams make the wrong assumption The most common error is to treat a CSRD sustainability disclosure as if it proves Taxonomy alignment. It does not. A broad environmental strategy or an ESRS data point is not enough to prove that a specific activity passes the technical screening criteria. The reverse mistake also happens. A well-documented Taxonomy activity file does not cover all the narrative and governance requirements that CSRD demands. - Do not infer Taxonomy alignment from a generic environmental narrative - Do not assume a strong Taxonomy file covers all ESRS disclosure needs - Keep separate sign-off questions for Taxonomy claims and for broader CSRD statements - Use shared controls, not shared legal conclusions ## Current timing point you should not ignore Because Article 8 scope is linked to the Accounting Directive sustainability-reporting hooks, the current CSRD timing matters to later Taxonomy reporters. Directive (EU) 2025/794 deferred certain later CSRD waves, and that affects when some undertakings newly enter the reporting perimeter. That timing interaction is an inference from the legal hook, not a stand-alone new Taxonomy act. Teams should therefore check both the Taxonomy delegated acts and the current CSRD timing law together when planning entry dates. - Already-reporting entities should focus on current Article 8 methodology and the 2026 simplification act - Later entrants should check both Article 8 methodology and the deferred CSRD wave timing - Do not rely on an older scope example without confirming whether the accounting-law trigger has since moved *Recommended next step* *Placement: after the comparison section* ## Use EU Taxonomy vs CSRD as a cited research workflow Research Copilot can take EU Taxonomy vs CSRD from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Taxonomy can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Taxonomy vs CSRD](/solutions/research-copilot.md): Start from EU Taxonomy vs CSRD and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Taxonomy](/contact.md): Review your current process, evidence gaps, and next steps for EU Taxonomy vs CSRD. ## Primary sources - [Regulation (EU) 2020/852 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2020/852/oj/eng?ref=sorena.io) - Taxonomy framework and Article 8 disclosure hook. - [Commission Delegated Regulation (EU) 2021/2178 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Taxonomy KPI methodology. - [Directive (EU) 2022/2464 (CSRD) (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2022/2464/oj/eng?ref=sorena.io) - Original CSRD reporting architecture. - [Directive (EU) 2025/794 (EUR-Lex)](https://eur-lex.europa.eu/eli/dir/2025/794/oj/eng?ref=sorena.io) - Current deferred CSRD timing that affects later Article 8 entrants by legal inference. - [Commission Notice C/2025/1373 (EUR-Lex)](https://eur-lex.europa.eu/eli/C/2025/1373/oj/eng?ref=sorena.io) - Current Taxonomy implementation notice, including first-time comparative treatment. ## Related Topic Guides - [EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures](/artifacts/eu/taxonomy-regulation/applicability-test.md): A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose. - [EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs](/artifacts/eu/taxonomy-regulation/checklist.md): An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping. - [EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence](/artifacts/eu/taxonomy-regulation/compliance.md): A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register. - [EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR](/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar.md): A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases. - [EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73](/artifacts/eu/taxonomy-regulation/delegated-acts-tracker.md): Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts. - [EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link](/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards.md): A practical guide to EU Taxonomy DNSH and minimum safeguards. - [EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7)](/artifacts/eu/taxonomy-regulation/penalties-and-fines.md): How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7. - [EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification](/artifacts/eu/taxonomy-regulation/faq.md): A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice. - [EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8](/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow.md): Build an EU Taxonomy disclosure workflow that can survive review. - [EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs](/artifacts/eu/taxonomy-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means. - [EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8](/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities.md): Understand EU Taxonomy scope and reporting entities under Article 8. - [EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail](/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation.md): How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping. - [EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards)](/artifacts/eu/taxonomy-regulation/templates.md): Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register. - [EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests](/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr.md): Understand the practical relationship between EU Taxonomy and SFDR. - [Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove](/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained.md): A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd --- --- title: "EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests" canonical_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr" source_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr" author: "Sorena AI" description: "Understand the practical relationship between EU Taxonomy and SFDR." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Taxonomy vs SFDR" - "Taxonomy and SFDR data flow" - "GAR counterparty data" - "Taxonomy investor requests" - "Taxonomy data pack" - "Taxonomy alignment evidence for lenders and investors" - "GAR" - "Counterparty data" - "Investor requests" - "Sustainable finance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests Understand the practical relationship between EU Taxonomy and SFDR. *EU Taxonomy* *Comparison* ## EU Taxonomy vs SFDR Taxonomy creates the activity-level environmental test. SFDR uses that data downstream. That is why so many non-reporters still receive lender and investor Taxonomy questionnaires. The most useful way to think about Taxonomy and SFDR is as a data chain. A reporting undertaking classifies activities, documents alignment, and publishes Taxonomy outputs. Financial undertakings then consume those outputs in GAR and related metrics. Those financial metrics, in turn, influence portfolio and product sustainability disclosures. If the company-side data pack is poor, the whole chain becomes expensive and inconsistent. ## What is different Taxonomy is a classification and KPI system. It decides whether specific economic activities meet environmental conditions and how that is shown in Article 8 disclosures. SFDR is a disclosure regime for financial-market participants and products. It uses investee and counterparty information, including Taxonomy information, to support broader sustainability disclosures. - Taxonomy asks whether an activity is eligible or aligned and what KPI share results from that conclusion - SFDR asks how financial products and market participants disclose sustainability characteristics and impacts - Taxonomy evidence is activity-level and criterion-level - SFDR users often need that evidence indirectly, through KPIs, methodology notes, and confidence in the source data ## Why lenders and investors ask for Taxonomy data Financial undertakings need reliable counterparty data to calculate GAR and related metrics. The Commission has repeatedly noted that financial KPI quality depends on data flows from non-financial undertakings. That is the direct reason many companies receive requests even when they are not themselves publishing Article 8 disclosures. - Banks ask for turnover, CapEx, OpEx, scope notes, and methodology explanations - Asset managers and product teams ask for aligned versus eligible breakdowns and evidence quality signals - Insurers and other financial actors may need the same information in different formats - A stable response pack reduces repetitive questionnaires and inconsistent answers ## What should be in a counterparty Taxonomy data pack A good counterparty data pack is compact, current, and reviewable. It should let the financial institution understand what the numbers mean without asking the company to resend everything from scratch. The goal is not to publish every evidence file externally. The goal is to make the methodology, perimeter, and confidence level clear enough that the numbers can be used responsibly. - Latest turnover, CapEx, and OpEx Taxonomy outputs with reporting year clearly stated - Eligibility versus alignment split, not just a single sustainability percentage - Perimeter note covering included entities, consolidation logic, and major year-on-year changes - Methodology note on estimates, voluntary data, non-assessed items, and the delegated-act version used - Evidence summary stating how criteria files, DNSH files, and safeguards files are maintained ## Current practical implications The 2026 simplification act does not remove the data-chain problem. Financial undertakings still depend on counterparties, even if some template burdens are deferred or simplified. That means company-side discipline still matters. Cleaner company data leads to fewer investor queries, fewer GAR challenges, and less manual rework. - Keep a reusable data pack rather than answering each questionnaire from scratch - Update the data pack after every reporting cycle and every major perimeter change - Record whether the data comes from mandatory Article 8 disclosures, voluntary reporting, or direct project evidence - Where evidence is incomplete, say so clearly rather than overstating alignment confidence *Recommended next step* *Placement: after the comparison section* ## Use EU Taxonomy vs SFDR as a cited research workflow Research Copilot can take EU Taxonomy vs SFDR from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Taxonomy can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for EU Taxonomy vs SFDR](/solutions/research-copilot.md): Start from EU Taxonomy vs SFDR and answer scope, timing, and interpretation questions with cited outputs. - [Talk through EU Taxonomy](/contact.md): Review your current process, evidence gaps, and next steps for EU Taxonomy vs SFDR. ## Primary sources - [Regulation (EU) 2020/852 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2020/852/oj/eng?ref=sorena.io) - Taxonomy framework and Article 8 disclosure hook. - [Commission Delegated Regulation (EU) 2021/2178 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - Article 8 KPI methodology used in sustainable-finance data flows. - [Commission Notice C/2023/305 (EUR-Lex)](https://eur-lex.europa.eu/eli/C/2023/305/oj/eng?ref=sorena.io) - Explains how non-financial disclosures feed financial metrics such as GAR. - [Commission Notice C/2025/1373 (EUR-Lex)](https://eur-lex.europa.eu/eli/C/2025/1373/oj/eng?ref=sorena.io) - Current implementation guidance relevant to reporting quality and updated templates. ## Related Topic Guides - [EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures](/artifacts/eu/taxonomy-regulation/applicability-test.md): A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose. - [EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs](/artifacts/eu/taxonomy-regulation/checklist.md): An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping. - [EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence](/artifacts/eu/taxonomy-regulation/compliance.md): A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register. - [EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR](/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar.md): A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases. - [EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73](/artifacts/eu/taxonomy-regulation/delegated-acts-tracker.md): Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts. - [EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link](/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards.md): A practical guide to EU Taxonomy DNSH and minimum safeguards. - [EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7)](/artifacts/eu/taxonomy-regulation/penalties-and-fines.md): How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7. - [EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification](/artifacts/eu/taxonomy-regulation/faq.md): A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice. - [EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8](/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow.md): Build an EU Taxonomy disclosure workflow that can survive review. - [EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs](/artifacts/eu/taxonomy-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means. - [EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8](/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities.md): Understand EU Taxonomy scope and reporting entities under Article 8. - [EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail](/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation.md): How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping. - [EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards)](/artifacts/eu/taxonomy-regulation/templates.md): Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register. - [EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting](/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd.md): Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system. - [Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove](/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained.md): A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr --- --- title: "EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards)" canonical_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/templates" source_url: "https://www.sorena.io/artifacts/eu/taxonomy-regulation/templates" author: "Sorena AI" description: "Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "EU Taxonomy templates" - "taxonomy activity mapping register template" - "taxonomy eligibility alignment register template" - "taxonomy criteria mapping template" - "taxonomy DNSH register template" - "taxonomy minimum safeguards evidence template" - "taxonomy KPI workbook template turnover CapEx OpEx GAR" - "taxonomy delegated acts tracker template" - "Activity register" - "KPI workbook" - "Evidence pack index" - "Delegated acts tracker" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # EU Taxonomy Templates (Activity Register, KPI Workbook, Evidence Pack Index, DNSH, Safeguards) Practical EU Taxonomy templates you can copy/paste: activity mapping register, eligibility/alignment register, criteria mapping template, DNSH register. *EU Taxonomy* *Templates* ## EU Taxonomy (Article 8) Templates Templates that make reporting repeatable. Use these to standardize activity mapping, evidence packs, and KPI computations. Taxonomy work scales only when it's templated. Use the templates below to build a controlled activity register, evidence packs tied to technical screening criteria, and a KPI workbook with reconciliations and change control. ## Activity mapping register (the backbone of classification) This register connects finance and operations. Treat it as a controlled dataset: versioned, owner-assigned, and mapped to accounts and reporting perimeter. Recommended columns: - Activity ID (stable identifier) - Entity / subsidiary, site / asset, geography - Taxonomy activity name and delegated act reference (version) - Boundary statement (included/excluded, time period) - Revenue/CapEx/OpEx mapping (accounts/projects/cost categories) - Eligibility status + rationale - Alignment status + evidence pack link ## Eligibility + alignment register (keep claims precise) Eligibility and alignment must be separate fields. This register is what drives aligned KPI numerators. Recommended fields: - Eligible? (Y/N) + rationale and boundary note - Aligned? (Y/N) + decision date + reviewer - Criteria mapping file link (substantial contribution + DNSH + safeguards) - Minimum safeguards coverage statement (perimeter coverage) - Re-assessment trigger (delegated act change / asset change / methodology change) ## Criteria mapping template (criterion-by-criterion evidence) This is the single most important template for auditability. It turns a claim into a reproducible set of checks with evidence pointers. Recommended rows/fields: - Criterion ID / text (substantial contribution and DNSH criteria) - Pass/Fail/Not applicable (with rationale if N/A) - Metric/value and measurement method - Evidence artifact link (assessment/permit/monitoring/source data) - Owner and timestamp - Notes (assumptions, estimates, limitations) *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep EU Taxonomy (Article 8) Templates in one governed evidence system SSOT can take EU Taxonomy (Article 8) Templates from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on EU Taxonomy (Article 8) can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for EU Taxonomy (Article 8) Templates](/solutions/ssot.md): Start from EU Taxonomy (Article 8) Templates and keep documents, evidence, and control records in one governed system. - [Talk through EU Taxonomy (Article 8)](/contact.md): Review your current process, evidence gaps, and next steps for EU Taxonomy (Article 8) Templates. ## DNSH register and minimum safeguards evidence register DNSH and safeguards are often the hardest to keep consistent across entities. Use registers that are linked to activity IDs and to KPI numerator components. Recommended fields: - Activity ID link + objective(s) claimed - DNSH criteria status and evidence pointers - Safeguards baseline: due diligence processes, grievance mechanism, remediation tracking - Coverage statement: which entities/suppliers are covered by safeguards checks - Refresh cadence and last review date ## Delegated acts tracker and KPI workbook structure These templates keep reporting consistent when the legal layer changes. Track acts by application date and link them to your activity register and KPI workbook change log. Recommended KPI workbook tabs: - Delegated acts tracker (act -> change summary -> application date -> impacted activities) - Inputs (source system extracts and mapping rules) - Activity-level calculations (numerators/denominators by activity ID) - Aggregations (entity and group totals) + reconciliations - Methodology notes + estimates/proxies policy + change log - Disclosure tables output (ready for reporting templates) ## Primary sources - [Disclosures Delegated Act (Article 8) - Commission Delegated Regulation (EU) 2021/2178 (EUR-Lex)](https://eur-lex.europa.eu/eli/reg_del/2021/2178/oj/eng?ref=sorena.io) - KPI templates and accompanying information requirements. - [Regulation (EU) 2020/852 (EU Taxonomy Regulation) (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2020/852/oj?ref=sorena.io) - Alignment conditions and delegated act framework. ## Related Topic Guides - [EU Taxonomy Applicability Test (Article 8): In-Scope Entities, Activities, and Disclosures](/artifacts/eu/taxonomy-regulation/applicability-test.md): A practical EU Taxonomy applicability test for Regulation (EU) 2020/852 and Article 8 disclosures: determine whether your entity must disclose. - [EU Taxonomy Checklist (Article 8): Audit-Ready Eligibility, Alignment, KPIs, Evidence Packs](/artifacts/eu/taxonomy-regulation/checklist.md): An audit-ready EU Taxonomy checklist for Regulation (EU) 2020/852 and Article 8 disclosures: scope/perimeter, activity mapping. - [EU Taxonomy Compliance Program (Article 8): Implementation Playbook for KPIs and Evidence](/artifacts/eu/taxonomy-regulation/compliance.md): A practical EU Taxonomy compliance program playbook for Regulation (EU) 2020/852: set governance, build an activity mapping register. - [EU Taxonomy Deadlines and Disclosure Calendar: Article 8 Reporting Dates, 2026 Simplification, GAR](/artifacts/eu/taxonomy-regulation/deadlines-and-compliance-calendar.md): A practical EU Taxonomy calendar covering Regulation (EU) 2020/852, the Article 8 disclosure timetable, the 2023 and 2024 reporting phases. - [EU Taxonomy Delegated Acts Tracker: 2021/2139, 2021/2178, 2022/1214, 2023/2485, 2023/2486, 2026/73](/artifacts/eu/taxonomy-regulation/delegated-acts-tracker.md): Track the full EU Taxonomy delegated-act stack, including the climate, environmental, disclosure, and 2026 simplification acts. - [EU Taxonomy DNSH and Minimum Safeguards: Evidence, OECD, UNGP, ILO, SFDR Link](/artifacts/eu/taxonomy-regulation/dnsh-and-minimum-safeguards.md): A practical guide to EU Taxonomy DNSH and minimum safeguards. - [EU Taxonomy Enforcement, Measures, Penalties and Fines (Articles 5-7)](/artifacts/eu/taxonomy-regulation/penalties-and-fines.md): How EU Taxonomy enforcement works in practice: competent authorities monitor compliance for disclosures under Articles 5 to 7. - [EU Taxonomy FAQ: Article 8, Eligibility vs Alignment, GAR, Minimum Safeguards, 2026 Simplification](/artifacts/eu/taxonomy-regulation/faq.md): A grounded EU Taxonomy FAQ covering Article 8 scope, eligibility vs alignment, turnover CapEx OpEx KPIs, GAR, minimum safeguards, the 2025 Commission Notice. - [EU Taxonomy KPIs and Disclosure Workflow: Turnover, CapEx, OpEx, GAR, Article 8](/artifacts/eu/taxonomy-regulation/kpis-and-disclosure-workflow.md): Build an EU Taxonomy disclosure workflow that can survive review. - [EU Taxonomy Requirements (2020/852): Eligibility, Alignment, DNSH, Minimum Safeguards, Article 8 KPIs](/artifacts/eu/taxonomy-regulation/requirements.md): A practical requirements breakdown for Regulation (EU) 2020/852 (EU Taxonomy): what environmentally sustainable means. - [EU Taxonomy Scope and Reporting Entities: Who Must Disclose Under Article 8](/artifacts/eu/taxonomy-regulation/scope-and-reporting-entities.md): Understand EU Taxonomy scope and reporting entities under Article 8. - [EU Taxonomy Technical Screening Criteria: Documentation, Evidence Packs, and Audit Trail](/artifacts/eu/taxonomy-regulation/screening-criteria-and-documentation.md): How to document EU Taxonomy alignment against technical screening criteria: build a criteria-by-criteria mapping. - [EU Taxonomy vs CSRD: How Article 8 Taxonomy Disclosures Fit Into CSRD Reporting](/artifacts/eu/taxonomy-regulation/taxonomy-vs-csrd.md): Compare EU Taxonomy and CSRD the practical way. Learn how Article 8 Taxonomy disclosures fit inside the broader CSRD reporting system. - [EU Taxonomy vs SFDR: How Taxonomy Data Flows Into GAR, Product Disclosures, and Investor Requests](/artifacts/eu/taxonomy-regulation/taxonomy-vs-sfdr.md): Understand the practical relationship between EU Taxonomy and SFDR. - [Taxonomy Eligibility vs Alignment (EU Taxonomy): What You Can Claim, What You Must Prove](/artifacts/eu/taxonomy-regulation/taxonomy-eligibility-vs-alignment-explained.md): A high-signal explainer of EU Taxonomy eligibility vs alignment: eligibility means the activity is covered/listed. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/taxonomy-regulation/templates --- --- title: "ETSI EN 303 645 Compliance & Conformance Assessment (ICS/IXIT Evidence)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/compliance" source_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/compliance" author: "Sorena AI" description: "How to operationalize ETSI EN 303 645 compliance for consumer IoT: conformance assessment approach (ETSI TS 103 701), ICS/IXIT-style evidence." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 303 645 compliance" - "ETSI TS 103 701" - "conformance assessment" - "ICS" - "IXIT" - "consumer IoT security assessment" - "conceptual tests" - "functional tests" - "evidence pack" - "vulnerability disclosure policy evidence" - "secure update evidence" - "audit readiness" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 303 645 Compliance & Conformance Assessment (ICS/IXIT Evidence) How to operationalize ETSI EN 303 645 compliance for consumer IoT: conformance assessment approach (ETSI TS 103 701), ICS/IXIT-style evidence. *Artifact Guide* *GLOBAL* ## ETSI EN 303 645 Compliance A compliance playbook for turning ETSI EN 303 645 into verifiable controls and repeatable evidence. Use ETSI TS 103 701 concepts (roles, ICS/IXIT, test groups and test cases) to structure your assessment, even if you are not pursuing formal certification. Standards compliance fails when teams treat it as a document exercise. ETSI EN 303 645 compliance is an engineering system: controls in product + services, tests that prove those controls work, and evidence that stays current as you ship updates and handle vulnerabilities. This page focuses on how to structure that system using ETSI's conformance assessment framing. ## What 'compliance' means for ETSI EN 303 645 ETSI EN 303 645 is a baseline consumer IoT security standard. In practice, teams use it to define minimum product security controls and to demonstrate due care to internal stakeholders, customers, procurement teams, and auditors. A strong compliance outcome is not a checklist. It is a traceable line from provision -> control -> verification -> evidence -> ongoing operation (patching, monitoring, incident response). - Define scope: device, firmware, mobile app, cloud services, and associated services - Turn each provision into testable acceptance criteria and an evidence artifact - Operate the controls continuously: updates, vulnerability handling, logging, and review cadence *Recommended next step* *Placement: after the compliance steps* ## Turn ETSI EN 303 645 Compliance into an operational assessment Assessment Autopilot can take ETSI EN 303 645 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on ETSI EN 303 645 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ETSI EN 303 645 Compliance](/solutions/assessment.md): Start from ETSI EN 303 645 Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ETSI EN 303 645](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 303 645 Compliance. ## Conformance assessment mindset (ETSI TS 103 701) ETSI TS 103 701 is a conformance assessment specification for baseline requirements of ETSI EN 303 645. It frames assessment around roles (e.g., Device Under Test, Supplier Organization, Test Laboratory), an assessment procedure, and structured documentation used to derive test plans. Even if you're doing first-party self-assessment, the same structure helps: you build a repeatable test plan, capture verdicts, and keep evidence consistent across versions and SKUs. - Treat your product as a Device Under Test (DUT) with a defined assessment environment - Maintain supplier/implementer declarations and extra info that drives test planning - Keep verdicts and findings tied to specific provisions and releases ## Build an ICS/IXIT-style evidence architecture ETSI TS 103 701 describes the use of an Implementation Conformance Statement (ICS) and Implementation eXtra Information for Testing (IXIT). The key idea: record what is implemented, plus the extra technical details a tester needs to assess it. Translate that into a practical product security evidence system: a structured 'what we implement' statement plus technical evidence that proves it. - ICS-like: per-provision claim statements, supported/unsupported features, and versioned scope - IXIT-like: interface inventory, update mechanism details, crypto and key-handling details, deletion/reset behavior - Evidence links: threat models, test plans, test results, release notes, and vulnerability handling records ## Conceptual vs functional verification (make it audit-proof) ETSI TS 103 701 distinguishes two common verification modes: conceptual checks (evidence of design and declared behavior) and functional checks (observable behavior under test). For high-confidence compliance, pair them: conceptual evidence shows intent and implementation approach; functional tests show the product actually behaves as claimed. - Conceptual: policies, architecture decisions, interface specs, update trust chain design, logs configuration - Functional: device-level tests (auth behavior, interface exposure, update verification, reset/delete) and service tests (VDP workflow, notifications, telemetry anomaly handling) - Regression: re-run critical security tests per release and keep historical results ## Use external evidence without weakening assurance ETSI TS 103 701 describes how external evidence can be used instead of performing certain test groups, when appropriate. This is powerful but risky if you accept 'paper' evidence that doesn't reflect reality. Use external evidence only when it is current, attributable, and clearly scoped to the exact version and configuration you ship. - Accept only evidence that is versioned and traceable to shipped builds and configurations - Prefer machine-verifiable artifacts: signed SBOM, build attestations, CI logs, and reproducible test runs - Document gaps and compensating controls when a provision is not applicable or not fully implemented ## Minimum evidence pack (what auditors and customers ask for) Build an evidence pack that answers the same questions repeatedly: what is implemented, how it is verified, and how it is operated over time (updates and vulnerability management). Keep it light, but complete: it should be easy to update every release and easy to share with procurement or internal security assurance teams. - VDP and CVD workflow evidence: contact channel, acknowledgement + status timelines, triage records, fix and disclosure records - Secure update evidence: signing/verification approach, anti-rollback approach, update rollout plan, update failure handling - Interface hardening evidence: disabled services list, debug lockdown evidence, unauthenticated info disclosure checks - Data lifecycle evidence: reset/delete behavior, user instructions, confirmation flows for associated services ## Common compliance pitfalls (and how to avoid them) Most ETSI EN 303 645 'failures' are not about intent; they're about operational reality. Teams document policies but can't produce proof at release time. Avoid fragile compliance by tying provisions to release gates and by keeping evidence generated automatically where possible. - Shipping an update mechanism without robust authenticity/integrity verification and anti-rollback - Publishing a VDP without running it (no triage, no status updates, no closure records) - Treating cloud services and mobile apps as 'out of scope' even when they are required to operate the device securely - Keeping evidence as static documents instead of versioned artifacts tied to builds ## Primary sources - [ETSI EN 303 645 V3.1.3 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf?ref=sorena.io) - Primary source for the current baseline security provisions in V3.1.3 (2024-09). - [ETSI TS 103 701 V2.1.1 (Conformance Assessment) (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Defines conformance assessment methodology and test scenarios structure (including ICS/IXIT concepts). - [ETSI IPR Database](https://ipr.etsi.org/?ref=sorena.io) - Use for due diligence when adopting ETSI deliverables in product programs and contractual statements. ## Related Topic Guides - [ETSI EN 303 645 FAQ (Consumer IoT Security Standard)](/artifacts/global/etsi-en-303-645/faq.md): Answering common product-team questions about ETSI EN 303 645: unique passwords, vulnerability disclosure policy requirements, secure software updates. - [ETSI EN 303 645 Requirements (Provision Map 5.1-5.13)](/artifacts/global/etsi-en-303-645/requirements.md): Provision-by-provision ETSI EN 303 645 requirements for consumer IoT: passwords, vulnerability disclosure policy, secure software updates, secure storage. - [ETSI EN 303 645 Secure Updates & Vulnerability Disclosure (VDP + CVD)](/artifacts/global/etsi-en-303-645/secure-update-and-vulnerability-disclosure.md): Deep implementation guide for ETSI EN 303 645 update security and vulnerability disclosure: publish a VDP, run coordinated vulnerability disclosure (CVD). - [ETSI EN 303 645 vs UK PSTI (Practical Mapping for Connectable Products)](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-uk-psti.md): Practical comparison of ETSI EN 303 645 baseline consumer IoT security provisions vs the UK PSTI security requirements regime. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-303-645/compliance --- --- title: "ETSI EN 303 645 vs UK PSTI (Practical Mapping for Connectable Products)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-uk-psti" source_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-uk-psti" author: "Sorena AI" description: "Practical comparison of ETSI EN 303 645 baseline consumer IoT security provisions vs the UK PSTI security requirements regime." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 303 645 vs UK PSTI" - "UK PSTI security requirements" - "connectable products UK" - "statement of compliance retention 10 years" - "defined support period" - "consumer IoT security standard" - "vulnerability disclosure policy" - "secure software updates" - "no universal default passwords" - "evidence pack" - "UK connectable products" - "Consumer IoT security" - "Vulnerability disclosure" - "Secure updates" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 303 645 vs UK PSTI (Practical Mapping for Connectable Products) Practical comparison of ETSI EN 303 645 baseline consumer IoT security provisions vs the UK PSTI security requirements regime. *Artifact Guide* *GLOBAL* ## ETSI EN 303 645 vs UK PSTI How EN 303 645 controls and evidence help you ship connectable products in the UK. This page is an implementation mapping, not legal advice. Validate UK PSTI obligations against the statutory instrument and schedules. UK PSTI introduces legally enforceable security requirements for relevant connectable products. ETSI EN 303 645 is a baseline consumer IoT security standard. Many teams use EN 303 645 to structure product security controls and evidence in a way that translates well to UK PSTI outcomes: strong passwords, vulnerability disclosure, secure updates, clear support periods, and defensible records. ## Quick take: how they fit together If you are building EN 303 645 controls properly (not as a checklist), you are already building the operational capabilities UK PSTI needs: a vulnerability disclosure process with timelines, a secure update mechanism, and support period transparency. UK PSTI obligations are defined in legislation and schedules. ETSI EN 303 645 is not the law, but it is a very practical blueprint for implementing and proving the security outcomes regulators and customers expect. - Use EN 303 645 as the engineering control baseline and UK PSTI as the legal requirement set - Keep an evidence pack that is versioned, attributable, and tied to the product you ship in the UK - Treat support period transparency as a first-class control (published, maintained, and contract-consistent) ## UK PSTI: key dates and records you must be able to produce The Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023 come into force on 29 April 2024 and extend across the UK. The regulations reference security requirements (Schedule 1) and 'deemed compliance' conditions (Schedule 2). They also cover statements of compliance and retention expectations for manufacturers and importers. - Plan your product security controls and evidence as ongoing operations, not one-time submissions - Prepare statement-of-compliance artifacts and retention processes (including support period linkage) - Document scope: which models/SKUs are relevant connectable products and what is included (device + associated services) ## Mapping the core themes: passwords, disclosure, updates, support periods ETSI EN 303 645 provisions map cleanly to the practical security outcomes UK PSTI is designed to achieve. The most important overlap is the operational loop: prevent weak defaults, handle vulnerabilities, ship updates, and communicate support commitments. Use EN 303 645 to make these outcomes testable and evidence-backed. - Passwords: EN 303 645 requires unique per-device or user-defined passwords (beyond factory defaults) and addresses how unique credentials are generated - Disclosure: EN 303 645 requires a public VDP with contact information and defined acknowledgement/status-update timelines - Updates: EN 303 645 sets detailed expectations for secure update mechanisms, authenticity/integrity verification, timeliness, notifications, and publishing a defined support period ## Evidence pack approach that satisfies both engineering and UK PSTI needs The best evidence is operational evidence: it shows that your organization can handle vulnerabilities and updates reliably, at scale, across versions and SKUs. ETSI TS 103 701 provides a helpful assessment structure (declarations/information used to derive a test plan, and conceptual vs functional checks). Even if UK PSTI doesn't require you to follow TS 103 701, the structure makes your evidence easier to defend. - VDP + CVD evidence: published policy, intake logs, acknowledgement timestamps, status updates, closure records - Update mechanism evidence: trust anchors, signing policy, verification logs, anti-rollback approach, staged rollout metrics - Support period evidence: published support matrix by SKU, change control, and consistency across packaging/procurement/docs - Retention process: store statements and security evidence in a way that survives team turnover and product evolution ## What to do if you ship in the UK (practical next steps) Start by validating whether your product is a relevant connectable product and then build your compliance program around the outcomes: strong default posture, reliable disclosure handling, secure updates, and support period transparency. Use EN 303 645 to standardize controls and tests, then tailor the documentation and statements to UK PSTI requirements and your supply chain (manufacturers, importers, distributors). - Create a product scope inventory (SKUs, versions, associated services) and map controls per product line - Publish and operate a VDP with measurable timelines and status updates - Harden the update mechanism (authenticity/integrity checks, trust relationship, anti-rollback) and track rollout coverage - Publish a defined support period and align it with compliance statements and retention processes *Recommended next step* *Placement: after the comparison section* ## Use ETSI EN 303 645 vs UK PSTI as a cited research workflow Research Copilot can take ETSI EN 303 645 vs UK PSTI from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on ETSI EN 303 645 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ETSI EN 303 645 vs UK PSTI](/solutions/research-copilot.md): Start from ETSI EN 303 645 vs UK PSTI and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ETSI EN 303 645](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 303 645 vs UK PSTI. ## Primary sources - [ETSI EN 303 645 V3.1.3 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf?ref=sorena.io) - Primary source for baseline security provisions referenced in the mapping. - [UK PSTI Security Requirements Regulations 2023 (legislation.gov.uk)](https://www.legislation.gov.uk/uksi/2023/1007/body?ref=sorena.io) - Primary legal source for commencement date, schedules references, and statement-of-compliance retention rules. - [OPSS enforcement policy (GOV.UK)](https://www.gov.uk/government/publications/opss-enforcement-policy/opss-enforcement-enforcement-policy?ref=sorena.io) - Context on enforcement approach by the UK Office for Product Safety and Standards (risk-based, proportionate, escalating interventions). ## Related Topic Guides - [ETSI EN 303 645 Compliance & Conformance Assessment (ICS/IXIT Evidence)](/artifacts/global/etsi-en-303-645/compliance.md): How to operationalize ETSI EN 303 645 compliance for consumer IoT: conformance assessment approach (ETSI TS 103 701), ICS/IXIT-style evidence. - [ETSI EN 303 645 FAQ (Consumer IoT Security Standard)](/artifacts/global/etsi-en-303-645/faq.md): Answering common product-team questions about ETSI EN 303 645: unique passwords, vulnerability disclosure policy requirements, secure software updates. - [ETSI EN 303 645 Requirements (Provision Map 5.1-5.13)](/artifacts/global/etsi-en-303-645/requirements.md): Provision-by-provision ETSI EN 303 645 requirements for consumer IoT: passwords, vulnerability disclosure policy, secure software updates, secure storage. - [ETSI EN 303 645 Secure Updates & Vulnerability Disclosure (VDP + CVD)](/artifacts/global/etsi-en-303-645/secure-update-and-vulnerability-disclosure.md): Deep implementation guide for ETSI EN 303 645 update security and vulnerability disclosure: publish a VDP, run coordinated vulnerability disclosure (CVD). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-uk-psti --- --- title: "ETSI EN 303 645 FAQ (Consumer IoT Security Standard)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/faq" source_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/faq" author: "Sorena AI" description: "Answering common product-team questions about ETSI EN 303 645: unique passwords, vulnerability disclosure policy requirements, secure software updates." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 303 645 FAQ" - "consumer IoT security standard" - "unique passwords per device" - "vulnerability disclosure policy requirements" - "coordinated vulnerability disclosure" - "secure update mechanism" - "authenticity integrity verification" - "anti-rollback" - "support period" - "constrained device updates" - "ETSI TS 103 701 conformance assessment" - "evidence pack" - "Consumer IoT security" - "Secure updates" - "Vulnerability disclosure policy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 303 645 FAQ (Consumer IoT Security Standard) Answering common product-team questions about ETSI EN 303 645: unique passwords, vulnerability disclosure policy requirements, secure software updates. *Artifact Guide* *GLOBAL* ## ETSI EN 303 645 FAQ Fast answers to the questions product, firmware, and security teams ask most. Grounded in ETSI EN 303 645 baseline provisions and ETSI TS 103 701 conformance assessment framing. This FAQ is written for teams implementing consumer IoT security controls. It focuses on operational clarity: what you need to build, how to prove it, and what typically breaks in real products. ## Is ETSI EN 303 645 a law or a standard? ETSI EN 303 645 is a security standard for consumer IoT devices and associated services. It is commonly used as a baseline for product security programs and as a reference point in procurement and assurance discussions. Your legal obligations depend on your markets and applicable regulations. Many regulations and schemes reference ETSI-style baseline controls, but you should validate legal requirements for your specific product and jurisdictions. - Use EN 303 645 as a control baseline and as a communication tool with customers and auditors - Treat conformance as an engineering capability: controls + tests + evidence over time ## Does ETSI EN 303 645 require unique passwords? Yes. Where passwords are used and in any state other than the factory default, the standard requires consumer IoT device passwords to be unique per device or defined by the user. Where pre-installed unique per-device passwords are used, they must be generated in a way that reduces the risk of automated attacks against a class or type of device. - Eliminate shared default passwords across a product line - Prove uniqueness at scale (manufacturing/provisioning evidence and field validation) ## What must a vulnerability disclosure policy (VDP) include? ETSI EN 303 645 requires a publicly available vulnerability disclosure policy with (1) contact information for reporting issues and (2) timelines for initial acknowledgement and status updates until resolution. A strong VDP also clarifies scope (device/app/service), reporting expectations, and how coordinated vulnerability disclosure works in your organization. - A stable reporting channel and measurable acknowledgement/status timelines - A workflow that produces evidence: triage records, remediation timelines, and release artifacts ## How fast is 'timely' for vulnerability handling and security updates? ETSI EN 303 645 notes that 'timely' varies by incident, and gives conventional expectations such as completing a vulnerability process within ~90 days for software, while recognizing hardware fixes and rollout constraints may take longer. The defensible approach is to define severity-based SLAs and then prove performance with timestamps and rollout metrics. - Define SLAs by severity (acknowledge, triage, fix, rollout) - Track patch coverage by cohort and version ## Do we need a secure update mechanism even if the device is constrained? ETSI EN 303 645 expects software components to be securely updateable, and it requires a secure installation update mechanism for non-constrained devices. For constrained devices that cannot be updated, the standard expects transparency: publish the rationale, replacement support approach, and a defined support period, and consider isolability and hardware replaceability. If a device cannot be patched, your vulnerability management burden increases: isolation guidance, replacement plans, and clear end-of-support communication become critical controls. - Publish support periods and end-of-support behavior - Document constrained-device replacement and isolation strategies ## What does ETSI EN 303 645 say about update authenticity and integrity? The standard expects devices to verify the authenticity and integrity of software updates, and it requires authenticity/integrity verification via a trust relationship when updates are delivered over a network interface. In practice, this means signed updates, protected trust anchors, and robust failure handling (reject invalid updates, log safely, notify trusted parties). - Use signed update artifacts and verify before install - Implement anti-rollback controls to prevent downgrade attacks ## Do automatic updates have to be enabled by default? ETSI EN 303 645 recommends automatic mechanisms for software updates and recommends that automatic updates and/or update notifications be enabled in the initialized state where supported, while still being configurable so users can enable/disable/postpone. A defensible design balances user control with security outcomes and includes recovery behavior for failed automatic updates. - Default to secure, reliable update behavior with clear user controls - Avoid coupling security patches to disruptive feature releases where possible ## What evidence do we need to prove conformance? Strong evidence is specific and versioned: it ties each provision to a control, a verification method, and a recorded result for the exact version and configuration you ship. ETSI TS 103 701 provides a useful assessment framing (including conceptual vs functional checks and structured declarations/information that drives test planning). - Per-provision claims, test results, and release gates - VDP/CVD operational records and secure update system evidence - Interface inventory and hardening evidence (disabled services, debug lockdown, leakage checks) *Recommended next step* *Placement: after the FAQ section* ## Use ETSI EN 303 645 FAQ as a cited research workflow Research Copilot can take ETSI EN 303 645 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on ETSI EN 303 645 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ETSI EN 303 645 FAQ](/solutions/research-copilot.md): Start from ETSI EN 303 645 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ETSI EN 303 645](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 303 645 FAQ. ## Primary sources - [ETSI EN 303 645 V3.1.3 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf?ref=sorena.io) - Primary source for baseline security provisions referenced in this FAQ. - [ETSI TS 103 701 V2.1.1 (Conformance Assessment) (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Supporting source for conformance assessment structure and test scenario framing. ## Related Topic Guides - [ETSI EN 303 645 Compliance & Conformance Assessment (ICS/IXIT Evidence)](/artifacts/global/etsi-en-303-645/compliance.md): How to operationalize ETSI EN 303 645 compliance for consumer IoT: conformance assessment approach (ETSI TS 103 701), ICS/IXIT-style evidence. - [ETSI EN 303 645 Requirements (Provision Map 5.1-5.13)](/artifacts/global/etsi-en-303-645/requirements.md): Provision-by-provision ETSI EN 303 645 requirements for consumer IoT: passwords, vulnerability disclosure policy, secure software updates, secure storage. - [ETSI EN 303 645 Secure Updates & Vulnerability Disclosure (VDP + CVD)](/artifacts/global/etsi-en-303-645/secure-update-and-vulnerability-disclosure.md): Deep implementation guide for ETSI EN 303 645 update security and vulnerability disclosure: publish a VDP, run coordinated vulnerability disclosure (CVD). - [ETSI EN 303 645 vs UK PSTI (Practical Mapping for Connectable Products)](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-uk-psti.md): Practical comparison of ETSI EN 303 645 baseline consumer IoT security provisions vs the UK PSTI security requirements regime. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-303-645/faq --- --- title: "ETSI EN 303 645 Requirements (Provision Map 5.1-5.13)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/requirements" source_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/requirements" author: "Sorena AI" description: "Provision-by-provision ETSI EN 303 645 requirements for consumer IoT: passwords, vulnerability disclosure policy, secure software updates, secure storage." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 303 645 requirements" - "ETSI EN 303 645 provisions 5.1-5.13" - "consumer IoT security standard" - "no universal default passwords" - "vulnerability disclosure policy" - "coordinated vulnerability disclosure" - "secure software updates" - "update mechanism security" - "secure storage of security parameters" - "secure communications" - "attack surface reduction" - "debug interface disabled" - "personal data confidentiality" - "telemetry security anomalies" - "user data deletion" - "secure setup guidance" - "input validation" - "Consumer IoT security" - "Secure updates" - "Vulnerability disclosure" - "Baseline requirements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 303 645 Requirements (Provision Map 5.1-5.13) Provision-by-provision ETSI EN 303 645 requirements for consumer IoT: passwords, vulnerability disclosure policy, secure software updates, secure storage. *Artifact Guide* *GLOBAL* ## ETSI EN 303 645 Requirements Provision-by-provision requirements mapping for consumer IoT security (5.1-5.13). Use this page to turn ETSI EN 303 645 into engineering controls, acceptance criteria, and evidence that survives audits and product iterations. ETSI EN 303 645 is easiest to operationalize when you treat each provision as a testable claim: (1) the control exists, (2) it works for your product and associated services, and (3) you can prove it with repeatable evidence. The sections below translate the baseline requirements into practical implementation and evidence expectations. ## How to operationalize ETSI EN 303 645 Treat each provision as a control statement you can verify. For product teams, this typically means: a design decision, an implementation pattern, a test plan (conceptual + functional), and an evidence artifact that stays current per release. When the standard says 'shall', plan for a durable control and objective evidence. When it says 'should', treat it as a risk-based requirement you either implement or explicitly justify with documented rationale and compensating controls. - Write a per-provision control narrative: intent -> design -> implementation -> verification -> evidence - Use release gates: security review, update signing verification, interface hardening checks, and regression tests - Store evidence like code, not like PDFs: versioned policies, versioned test results, and traceable tickets ## Provision 5.1 - No universal default passwords and strong authentication The standard requires that device passwords (once not in factory default) are unique per device or user-defined, and it sets expectations for password generation and cryptographic best practices for authentication mechanisms. This is where IoT security programs fail in practice: account provisioning, manufacturing flows, and support tooling must all align so that 'unique per device' is true in the field-not just in a requirement doc. - Eliminate shared default passwords across a product class; use per-device secrets or force user-set credentials - Generate pre-installed credentials using a mechanism that reduces automated attacks across a device class - Define authentication crypto and key management as a security parameter (owned, rotated, monitored) ## Provision 5.2 - Vulnerability disclosure policy (VDP) and timely remediation You must publish a vulnerability disclosure policy with contact information and defined timelines for acknowledgement and status updates until resolution. The standard also sets expectations for timely action on disclosed vulnerabilities. Operationally, this means you need an intake channel, triage workflow, remediation SLAs, and a way to communicate status updates to reporters and affected stakeholders. - Publish a VDP with a clear reporting channel and explicit acknowledgement + status-update timelines - Run a repeatable triage process (severity, exploitability, affected versions, mitigation options) - Maintain a vulnerability remediation playbook with release, communication, and rollout steps ## Provision 5.3 - Secure software updates and transparent support periods ETSI EN 303 645 sets detailed expectations for updateability, secure installation, usability of updates, automatic updates, update checks, cryptography, authenticity and integrity verification, user notifications, and publishing a defined support period. Build the update system as a security control: it must resist misuse, prevent downgrade attacks, verify trust relationships, and deliver timely security patches-even when supply-chain dependencies exist. - Implement a secure update mechanism (including anti-rollback) and make updates simple to apply - Use best-practice cryptography and verify authenticity + integrity of every update (device or trusted peer) - Publish a defined support period and communicate what happens at end-of-support (especially for constrained devices) ## Provision 5.4 - Secure storage of sensitive security parameters Sensitive security parameters stored persistently must be stored securely. The standard also sets expectations for resisting tampering when a hard-coded per-device identity is used for security purposes. In practice, this provision ties together secure storage, manufacturing provisioning, device identity, and incident response: if secrets are extractable, every other control becomes brittle. - Classify 'critical security parameters' (keys, tokens, secrets) and store them with platform protections - Protect device identity material against physical, electrical, and software tampering where applicable - Document provisioning and key lifecycle: generation, injection, backup/recovery, rotation, and revocation ## Provision 5.5 - Secure communications for critical security parameters The standard addresses securing communications of critical security parameters: encrypt in transit where appropriate and protect confidentiality over remotely accessible interfaces, with secure management processes around those parameters. This is not 'turn on TLS and forget it'. You need a threat model for your interfaces, certificate/key handling, and a plan for migration when crypto or endpoints change. - Encrypt critical security parameters in transit using cryptography appropriate to risk and technology - Harden remotely accessible interfaces so critical security parameters are never exposed in plaintext - Operate secure parameter management processes (issuance, access control, rotation, and incident handling) ## Provision 5.6 - Minimize attack surface (interfaces, debug, and information disclosure) ETSI EN 303 645 requires disabling unused network and logical interfaces and minimizing unauthenticated disclosure of security-relevant information. It also addresses physical interface exposure and disabling debug interfaces when physically accessible. This provision is where you win cheap security: if you ship less surface area, you have less to patch and less to explain in audits. - Disable unused network services, ports, protocols, and APIs in production builds - Avoid unauthenticated banners, version leakage, and verbose error messages on network interfaces - Disable or lock down debug interfaces (JTAG/UART) in software when physically accessible ## Provision 5.7 - Integrity of software and system operation The integrity provisions focus on preventing unauthorized modification and preserving a trustworthy runtime state. For IoT devices, this often translates into secure boot, signed firmware, and protection of critical runtime components. Integrity is also an evidence problem: you need to show how integrity is enforced and how integrity failures are detected and handled. - Implement signed firmware and verify before execution where your platform supports it - Define how integrity violations are handled (reject, fail-safe, report, recover) - Keep integrity evidence: signing keys policy, build pipeline attestations, verification logs ## Provision 5.8 - Personal data confidentiality and user transparency The standard sets expectations for protecting the confidentiality of personal data in transit (especially sensitive personal data) and for documenting external sensing capabilities in a clear, transparent, and accessible way for the user. A strong implementation links privacy engineering to product UX: data is protected, and the user can understand what the device can sense and transmit. - Protect personal data in transit with best-practice cryptography; apply stronger guarantees for sensitive personal data - Document external sensing capabilities in user-facing language (what is sensed, when, and why) - Align privacy controls with update and vulnerability processes (privacy bugs also need CVD and fixes) ## Provision 5.9 - Resilience to outages and clean recovery ETSI EN 303 645 recommends building resilience into devices and services, including local functionality during network outages and clean recovery after power loss. Resilience is security-relevant: unsafe failure modes become exploitable. Treat outage behavior, state recovery, and 'expected stable state' as part of your security acceptance criteria. - Define safe degraded modes for loss of network and loss of power - Implement clean recovery and orderly reconnection behavior - Test outage scenarios and capture evidence (power-cycle tests, network partition tests) ## Provision 5.10 - Telemetry and security anomaly detection If telemetry is collected, it should be examined for security anomalies. This pushes teams to treat telemetry as a security sensor, not only as a product analytics pipeline. Telemetry is also a trust boundary: collect minimally, protect it, and ensure anomaly detection does not leak sensitive information. - Define telemetry security signals: update failures, auth failures, integrity violations, interface scans - Create anomaly detection and response playbooks (triage, containment, remediation) - Retain evidence: alert rules, incident tickets, and post-incident corrective actions ## Provision 5.11 - User data deletion and clear instructions The standard requires simple deletion of user data from the device and expectations for removing personal data from associated services, with clear instructions and confirmation of deletion where applicable. Deletion is a lifecycle control: it must work on-device, in associated services, and across customer support flows (returns, resale, transfers). - Provide simple, reliable user data erasure on the device (reset that actually deletes) - Support deletion from associated services and provide user instructions and confirmations - Test reset flows across firmware versions and associated app/service versions ## Provision 5.12 - Secure installation and maintenance with usable security Installation and maintenance should involve minimal user decisions and follow security best practice on usability. The manufacturer should provide guidance on secure setup and how to check whether the device is securely set up. Usable security is a compliance multiplier: if secure setup is hard, the field reality will violate your intended controls. - Default to secure settings and minimize risky configuration choices during onboarding - Provide step-by-step secure setup guidance and a 'security status' check for users - Ensure guidance stays accurate across app versions, firmware versions, and SKUs ## Provision 5.13 - Input validation for UIs, APIs, and service-to-device flows The standard requires validating data input via user interfaces, APIs, and between networks in services and devices. This is the foundation for preventing common classes of vulnerabilities in IoT ecosystems. Make input validation measurable: schema validation, size and type limits, authentication and authorization checks, and security testing for all externally reachable surfaces. - Validate and sanitize inputs across device UIs, network APIs, and service integrations - Add security tests: fuzzing, boundary tests, authZ tests, and regression tests for prior vulnerabilities - Log validation failures safely (no sensitive data leakage) and monitor for abuse patterns *Recommended next step* *Placement: after the requirement breakdown* ## Turn ETSI EN 303 645 Requirements into an operational assessment Assessment Autopilot can take ETSI EN 303 645 Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on ETSI EN 303 645 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ETSI EN 303 645 Requirements](/solutions/assessment.md): Start from ETSI EN 303 645 Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ETSI EN 303 645](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 303 645 Requirements. ## Primary sources - [ETSI EN 303 645 V3.1.3 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf?ref=sorena.io) - Primary source for the current baseline provisions (5.1-5.13) in V3.1.3 (2024-09). - [ETSI TS 103 701 V2.1.1 (Conformance Assessment) (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Supporting source for how provisions are assessed (ICS/IXIT concepts, test groups and test cases). ## Related Topic Guides - [ETSI EN 303 645 Compliance & Conformance Assessment (ICS/IXIT Evidence)](/artifacts/global/etsi-en-303-645/compliance.md): How to operationalize ETSI EN 303 645 compliance for consumer IoT: conformance assessment approach (ETSI TS 103 701), ICS/IXIT-style evidence. - [ETSI EN 303 645 FAQ (Consumer IoT Security Standard)](/artifacts/global/etsi-en-303-645/faq.md): Answering common product-team questions about ETSI EN 303 645: unique passwords, vulnerability disclosure policy requirements, secure software updates. - [ETSI EN 303 645 Secure Updates & Vulnerability Disclosure (VDP + CVD)](/artifacts/global/etsi-en-303-645/secure-update-and-vulnerability-disclosure.md): Deep implementation guide for ETSI EN 303 645 update security and vulnerability disclosure: publish a VDP, run coordinated vulnerability disclosure (CVD). - [ETSI EN 303 645 vs UK PSTI (Practical Mapping for Connectable Products)](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-uk-psti.md): Practical comparison of ETSI EN 303 645 baseline consumer IoT security provisions vs the UK PSTI security requirements regime. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-303-645/requirements --- --- title: "ETSI EN 303 645 Secure Updates & Vulnerability Disclosure (VDP + CVD)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/secure-update-and-vulnerability-disclosure" source_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/secure-update-and-vulnerability-disclosure" author: "Sorena AI" description: "Deep implementation guide for ETSI EN 303 645 update security and vulnerability disclosure: publish a VDP, run coordinated vulnerability disclosure (CVD)." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 303 645 secure updates" - "ETSI EN 303 645 vulnerability disclosure policy" - "VDP" - "CVD" - "coordinated vulnerability disclosure" - "security updates timely" - "authenticity integrity verification" - "update trust relationship" - "anti-rollback policy" - "automatic updates" - "update notifications" - "publish support period" - "SBOM monitoring" - "IoT security update mechanism" - "Vulnerability disclosure policy" - "Software updates" - "SBOM" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 303 645 Secure Updates & Vulnerability Disclosure (VDP + CVD) Deep implementation guide for ETSI EN 303 645 update security and vulnerability disclosure: publish a VDP, run coordinated vulnerability disclosure (CVD). *Artifact Guide* *GLOBAL* ## ETSI EN 303 645 Secure Updates + Vulnerability Disclosure Build a VDP + CVD workflow and ship secure, verifiable, timely security updates. Aligned to ETSI EN 303 645 provisions 5.2 (vulnerability reporting/handling) and 5.3 (software updates and support periods). ETSI EN 303 645 treats vulnerability handling and software updates as core consumer IoT security controls. In practice, these two capabilities define whether your product security posture improves over time or silently degrades. This page focuses on implementable patterns, measurable timelines, and evidence you can generate continuously. ## Provision 5.2-1 - Publish a vulnerability disclosure policy (VDP) ETSI EN 303 645 requires manufacturers to make a vulnerability disclosure policy publicly available. At minimum it must include contact information for reporting issues and timelines for initial acknowledgement and status updates until resolution. A VDP is not a marketing page. It is a contract-like interface between your organization and security reporters: it defines how reports enter your system and what reporters can expect next. - Provide a stable reporting channel and make it easy to find from your product and website - Commit to acknowledgement and status update timelines (measurable, not vague) - Define scope (device, firmware, apps, cloud services, and associated services) and how to report affected versions ## Provision 5.2-2 - Act on disclosed vulnerabilities in a timely manner ETSI EN 303 645 expects disclosed vulnerabilities to be acted on in a timely manner, noting that 'timely' depends on the incident and that conventional disclosure processes often complete within ~90 days for software (with caveats for hardware fixes and rollout constraints). 'Timely' becomes real only when you instrument it: triage SLAs, fix lead time, rollout lead time, and user/partner communication lead time. - Define severity-based SLAs: acknowledgement, triage completion, fix availability, rollout completion - Track update coverage: what % of devices are patched, by version and cohort - Document exceptions (e.g., constrained devices) and mitigation plans (isolation, replacement, compensating controls) ## Provision 5.2-3 - Monitor, identify, and rectify vulnerabilities during the support period The standard recommends continual monitoring for vulnerabilities in products and services during the defined support period, including due care for third-party components and associated services. This is where SBOM and dependency monitoring become unavoidable: you can't fix what you can't inventory. - Maintain a component inventory (SBOM-style) for device firmware, apps, and cloud services - Monitor vulnerability sources relevant to your components and ecosystems; triage with affected versions - Keep remediation evidence: issue tracking, patch diffs, release notes, and rollout metrics ## Provision 5.3-1 and 5.3-2 - Securely updateable components and secure installation ETSI EN 303 645 expects software components to be securely updateable and, for non-constrained devices, requires an update mechanism for secure installation of updates. Secure installation means adequate measures prevent attackers from misusing the update mechanism. Build the update mechanism as a security boundary. If it can be subverted, an attacker can install malicious software, downgrade to vulnerable versions, or brick devices at scale. - Define update paths: OTA, mobile-app mediated, local/USB, and service-initiated; secure each path - Implement anti-rollback controls (version checks) to prevent downgrade attacks - Prove the trust chain: signed updates, protected channels, and device-side verification where feasible ## Provisions 5.3-3 to 5.3-6 - Usability, automatic updates, update checks, and configuration ETSI EN 303 645 expects updates to be simple for users to apply, recommends automatic update mechanisms, recommends periodic checking for security updates, and recommends that automatic updates/notifications be enabled by default (where supported) while remaining configurable. The operational goal: updates should happen reliably without demanding 'security expertise' from users, while still respecting user control and safety-critical product behavior. - Make security updates low-friction: safe defaults, clear prompts, and recovery behavior if an update fails - Use automatic update mechanisms where appropriate; separate security updates from risky feature changes when possible - Implement periodic update checks (device or associated service) and ensure users can postpone/disable where applicable ## Provisions 5.3-7, 5.3-9, 5.3-10 - Cryptography, authenticity/integrity verification, and trust relationships ETSI EN 303 645 requires using best-practice cryptography for secure update mechanisms and expects devices to verify authenticity and integrity of software updates. When updates are delivered over a network interface, authenticity and integrity verification must be done via a trust relationship (e.g., authenticated channels, signature verification, or other validated trust conditions). Design your update system so that verification is undeniable: either the device verifies signatures directly, or a trusted peer verifies and delivers over a secure channel, with strong safeguards against substitution and replay. - Use signed update artifacts and verify signatures; store verification results and failures as security telemetry - Protect the trust relationship: pin/update trust anchors safely and manage certificate/key rotation - Handle invalid updates safely: reject, avoid information leakage, log securely, and alert trusted administrators/services ## Provisions 5.3-8, 5.3-11, 5.3-12 - Timely updates and user-facing notifications Security updates must be timely, with priority for critical vulnerabilities and coordination across supply-chain stakeholders when necessary. The standard also recommends informing users when a security update is required and notifying users if an update will disrupt basic device functioning (unless handled by an associated service). Timely updates are a program capability: release engineering, staged rollout, monitoring, and rollback/recovery plans must exist before the incident happens. - Define how users are notified: device UI, app notifications, email-use recognizable, actionable messaging - Implement staged rollout with safety guards (health metrics, crash rates, rollback criteria) - Treat update disruption as safety/UX: estimate downtime, maintain minimal critical functions where applicable ## Provisions 5.3-13 to 5.3-15 - Publish support periods and handle constrained devices ETSI EN 303 645 requires publishing a defined support period in an accessible, clear, and transparent way. It also addresses constrained devices that cannot be updated: publish rationale, replacement support, and support period; and consider isolability and replaceability. Support period transparency is both a compliance control and a trust signal. It also drives your internal vulnerability handling obligations: if you commit to support, you must be able to patch. - Publish support period per model/SKU and define what 'end of support' means for security fixes - Create an end-of-support playbook: comms, replacement options, isolation guidance, and risk advisories - Keep support period claims consistent across packaging, websites, and procurement documents ## Evidence to keep (what proves you meet 5.2 and 5.3) Your strongest evidence is operational: it shows you do this continuously, not only when asked. Keep artifacts that prove the workflow works: intake, triage, remediation, release, rollout, and communication. Aim for evidence that is attributable (who approved), current (per release), and traceable (links to specific provisions and versions). - VDP page + historical versions, mailbox/form logs, acknowledgement and status update timestamps - Vulnerability records: triage notes, affected versions, fix commits, CVE advisories where applicable - Update system evidence: signing policies, key management policies, verification logs, rollout metrics - Support period publication evidence: user-facing pages, SKU matrices, and change control records *Recommended next step* *Placement: near the end of the main content before related guides* ## Turn ETSI EN 303 645 Secure Updates + Vulnerability Disclosure into an operational assessment Assessment Autopilot can take ETSI EN 303 645 Secure Updates + Vulnerability Disclosure from turning this guidance into an operational assessment workflow to a reusable workflow inside Sorena. Teams working on ETSI EN 303 645 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ETSI EN 303 645 Secure Updates + Vulnerability Disclosure](/solutions/assessment.md): Start from ETSI EN 303 645 Secure Updates + Vulnerability Disclosure and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ETSI EN 303 645](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 303 645 Secure Updates + Vulnerability Disclosure. ## Primary sources - [ETSI EN 303 645 V3.1.3 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf?ref=sorena.io) - Primary source for provisions 5.2 (vulnerability disclosure) and 5.3 (software updates and support period). - [ETSI TS 103 701 V2.1.1 (Conformance Assessment) (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Supporting source for how vulnerability and update provisions can be assessed using test groups and evidence. ## Related Topic Guides - [ETSI EN 303 645 Compliance & Conformance Assessment (ICS/IXIT Evidence)](/artifacts/global/etsi-en-303-645/compliance.md): How to operationalize ETSI EN 303 645 compliance for consumer IoT: conformance assessment approach (ETSI TS 103 701), ICS/IXIT-style evidence. - [ETSI EN 303 645 FAQ (Consumer IoT Security Standard)](/artifacts/global/etsi-en-303-645/faq.md): Answering common product-team questions about ETSI EN 303 645: unique passwords, vulnerability disclosure policy requirements, secure software updates. - [ETSI EN 303 645 Requirements (Provision Map 5.1-5.13)](/artifacts/global/etsi-en-303-645/requirements.md): Provision-by-provision ETSI EN 303 645 requirements for consumer IoT: passwords, vulnerability disclosure policy, secure software updates, secure storage. - [ETSI EN 303 645 vs UK PSTI (Practical Mapping for Connectable Products)](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-uk-psti.md): Practical comparison of ETSI EN 303 645 baseline consumer IoT security provisions vs the UK PSTI security requirements regime. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-303-645/secure-update-and-vulnerability-disclosure --- --- title: "ETSI EN 319 401 Audit & Conformity Assessment (Evidence Pack + Checklist)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-401/audit-and-conformity-assessment" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-401/audit-and-conformity-assessment" author: "Sorena AI" description: "Audit readiness guide for ETSI EN 319 401 Trust Service Providers: how conformity assessment works in practice, what auditors sample." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 319 401 audit" - "ETSI EN 319 401 conformity assessment" - "trust service provider audit readiness" - "evidence pack" - "monitoring and logging REQ-7.9.1" - "incident response REQ-7.9.2" - "24 hour incident reporting REQ-7.9.3" - "vulnerability scan evidence REQ-7.8-13" - "quarterly vulnerability scanning REQ-7.8-14" - "penetration test REQ-7.8-17" - "evidence retention REQ-7.10" - "audit log UTC synchronization REQ-7.10-06" - "Conformity assessment" - "Trust Service Provider" - "Evidence retention" - "Incident reporting" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 401 Audit & Conformity Assessment (Evidence Pack + Checklist) Audit readiness guide for ETSI EN 319 401 Trust Service Providers: how conformity assessment works in practice, what auditors sample. *Artifact Guide* *GLOBAL* ## ETSI EN 319 401 Audit + Conformity Assessment Audit readiness for TSPs: evidence packs, sampling, and common findings. If you can produce evidence for REQ-7.8/7.9/7.10 on demand, you can survive most audits and procurement security reviews. Most ETSI EN 319 401 audits fail on operational proof, not on policy intent. Auditors, conformity-assessment bodies, and relying parties ask the same core questions: do you continuously monitor, can you detect and classify incidents, can you report within 24 hours when required, do you scan and test on a defensible cadence, can you prove supplier oversight, and can you retain evidence with reliable UTC time. This page focuses on what gets sampled, what good evidence looks like, and how to avoid repeat findings. ## What auditors typically evaluate (the real scope) Audits focus on whether your control system works in practice and whether evidence is traceable to your scope. The most sampled areas are the operational clauses: network security, vulnerability management, monitoring/logging, incident response/reporting, and evidence retention. Policies matter only as far as they explain and govern the operating reality. A policy with no operational proof is a finding waiting to happen. - Scope: which trust services and systems are in-scope, including external supporting organizations (REQ-6.1-04) - Risk basis: risk assessment and risk treatment decisions driving controls (REQ-5-01 to REQ-5-05) - Operational proof: scans, logs, incident records, and retention integrity (REQ-7.8 to REQ-7.10) - Assessment context: a TSP conformity assessment will usually be framed through EN 319 403-1, so evidence should be structured for external review rather than only internal operations ## Evidence pack structure for defensible evidence Build a single evidence index that maps REQ categories to their proof. The index should be versioned and should link to the newest evidence, with historical evidence retained for trend and legal/procurement needs. Treat the evidence system as an internal product: it needs ownership, change control, and reliability. - REQ map: REQ -> control narrative -> verification method -> evidence links - System diagrams: network zones, trusted channels, production vs dev/test separation, admin network separation - Operations evidence: scan reports, monitoring dashboards, alert triage tickets, incident reports, and post-incident reviews - Retention evidence: log immutability controls, backups/off-site storage, and access control to archives - Supplier and component evidence: outsourcing agreements, cloud controls, and review records where third parties support the trust service *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep ETSI EN 319 401 Audit + Conformity Assessment in one governed evidence system SSOT can take ETSI EN 319 401 Audit + Conformity Assessment from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on ETSI EN 319 401 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for ETSI EN 319 401 Audit + Conformity Assessment](/solutions/ssot.md): Start from ETSI EN 319 401 Audit + Conformity Assessment and keep documents, evidence, and control records in one governed system. - [Talk through ETSI EN 319 401](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 319 401 Audit + Conformity Assessment. ## High-risk findings area #1: vulnerability scanning and penetration testing (REQ-7.8) ETSI EN 319 401 requires regular vulnerability scans on identified public and private IP addresses, with recorded evidence that scans were performed by a competent and independent party. It also recommends quarterly scanning and requires penetration testing after upgrades/modifications that you determine are significant. Auditors will ask two questions: (1) did you scan/test on a credible cadence and scope, and (2) did you remediate or formally accept risk with documented rationale. - Scan scope: inventory of IP ranges/assets included and excluded (with justification) - Competence/independence evidence: vendor qualifications, ethics/code of conduct, and independence statement - Quarterly cadence default: prove frequency or justify a different cadence via risk assessment - Pen test triggers: define what counts as a significant change and keep test + remediation records ## High-risk findings area #2: monitoring/logging and incident response (REQ-7.9) ETSI EN 319 401 expects continuous monitoring/logging, detection/alarms for abnormal activity, and automated processing of audit logs with alerting for critical security events. This means manual log review without tooling is rarely defensible. Incident response expectations include containment/eradication/recovery, communication plans, training/competence, documentation throughout detection/response, and explicit time-bound handling such as 48-hour critical vulnerability handling and 24-hour breach notification procedures for significant impact breaches. - Log coverage proof: network traffic, privileged actions, config changes, backups, and security-relevant logs (REQ-7.9.1-04) - Alerting proof: alarms for abnormal activity and automated log processing (REQ-7.9.1-03/05) - Critical vulnerability clock: prove how you meet 48-hour handling for critical vulnerabilities (REQ-7.9.2-09) - 24-hour reporting readiness: breach notification procedure and evidence of execution during incidents (REQ-7.9.3-01) ## High-risk findings area #3: evidence retention and time integrity (REQ-7.10) Evidence retention is both a security and legal/continuity requirement. ETSI EN 319 401 requires recording and keeping relevant information accessible for an appropriate period (including after TSP activities cease), while preserving confidentiality and integrity. A frequently missed detail: audit log event time must be synchronized with UTC at least once a day. If time integrity is weak, incident timelines and legal evidence become disputable. - Retention schedule: defined per log category and aligned to terms and conditions (REQ-6.2 and REQ-7.10-07) - Tamper resistance: logs/events cannot be easily deleted/destroyed; reliable transfer to long-term media (REQ-7.10-08) - UTC sync evidence: daily synchronization records and monitoring for drift (REQ-7.10-06) - Access governance: who can view archives/audit logs (system auditors) and how access is approved and reviewed ## Audit readiness checklist (copy/paste) Use this checklist as an internal readiness gate before a conformity assessment, customer audit, or supervisory review. Every item should map to evidence links in your evidence index. - Scope pack: service inventory, system boundary, external support obligations, and current diagrams - Risk pack: current risk assessment, risk treatment plan, and management approvals - Policy pack: practice statement, terms & conditions (incl. log retention), information security policy and change communications - Network security pack: zone segmentation, rule-set reviews, disabled services list, trusted channel proof - Security testing pack: vuln scan reports + independence evidence + remediation, pen test reports + remediation - Monitoring/incident pack: log coverage proof, alerting rules, incident runbooks, communication plans, incident records - Evidence retention pack: retention schedule, immutability controls, UTC sync logs, and archive access control records ## High-risk findings area #4: supplier and outsourced component governance Modern TSP environments rely on cloud infrastructure, managed services, external trust service components, and other outsourced support. EN 319 401 makes clear that the TSP retains overall responsibility for conformance when those arrangements exist. Auditors increasingly sample whether supplier controls are active in practice. They look for more than contracts. They want review records, service-level enforcement, and evidence that supplier cybersecurity practices are revisited after incidents and major changes. - Agreement evidence: contracts, service levels, security clauses, and audit rights where relevant - Operational oversight: review cadence, issue logs, supplier risk assessments, and change notifications - Incident linkage: proof that supplier-related incidents trigger reassessment and corrective action - Boundary clarity: which controls stay with the TSP and which controls are implemented by suppliers ## Primary sources - [ETSI EN 319 401 V3.1.1 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Primary source for audit-relevant requirements such as REQ-7.8 (scanning/pen testing), REQ-7.9 (monitoring/incidents/reporting), and REQ-7.10 (evidence retention and UTC sync). - [ETSI EN 319 403-1 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/319400_319499/31940301/01.05.01_60/en_31940301v010501p.pdf?ref=sorena.io) - Context for how conformity assessment bodies assess Trust Service Providers. - [ETSI IPR Database](https://ipr.etsi.org/?ref=sorena.io) - IPR due diligence reference for ETSI deliverables. ## Related Topic Guides - [ETSI EN 319 401 Compliance Playbook for Trust Service Providers (TSPs)](/artifacts/global/etsi-en-319-401/compliance.md): How to operationalize ETSI EN 319 401 compliance for Trust Service Providers: scope definition, governance, risk assessment to control mapping. - [ETSI EN 319 401 FAQ for Trust Service Providers (TSPs)](/artifacts/global/etsi-en-319-401/faq.md): Frequently asked questions about ETSI EN 319 401 for Trust Service Providers: what a Trust Service Practice Statement is, how risk assessment drives controls. - [ETSI EN 319 401 Requirements (REQ-5/6/7 Map for Trust Service Providers)](/artifacts/global/etsi-en-319-401/requirements.md): Clause-by-clause ETSI EN 319 401 requirements mapping for Trust Service Providers (TSPs): risk assessment (REQ-5). - [ETSI EN 319 401 vs eIDAS (Mapping to Article 19 & 24 TSP Obligations)](/artifacts/global/etsi-en-319-401/etsi-en-319-401-vs-eidas.md): Practical mapping of ETSI EN 319 401 requirements to the EU eIDAS Regulation (EU) No 910/2014. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-401/audit-and-conformity-assessment --- --- title: "ETSI EN 319 401 Compliance Playbook for Trust Service Providers (TSPs)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-401/compliance" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-401/compliance" author: "Sorena AI" description: "How to operationalize ETSI EN 319 401 compliance for Trust Service Providers: scope definition, governance, risk assessment to control mapping." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 319 401 compliance" - "trust service provider compliance program" - "TSP security policy" - "trust service practice statement" - "information security policy REQ-6.3" - "risk assessment REQ-5" - "monitoring and logging REQ-7.9.1" - "incident response REQ-7.9.2" - "24 hour breach notification REQ-7.9.3" - "vulnerability scan quarterly REQ-7.8-14" - "penetration testing REQ-7.8-17" - "evidence retention REQ-7.10" - "audit log UTC sync REQ-7.10-06" - "Trust Service Provider" - "Audit readiness" - "Monitoring and logging" - "Incident reporting" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 401 Compliance Playbook for Trust Service Providers (TSPs) How to operationalize ETSI EN 319 401 compliance for Trust Service Providers: scope definition, governance, risk assessment to control mapping. *Artifact Guide* *GLOBAL* ## ETSI EN 319 401 Compliance A compliance playbook for Trust Service Providers that produces defensible evidence by default. Focus: turn REQ-5/6/7 into operating controls, verification, and evidence that stays current as your services and infrastructure evolve. ETSI EN 319 401 compliance is an operating system: risk assessment drives security requirements, policies and practices define how you operate, monitoring and incident response prove you can detect and react, and evidence retention plus supply-chain governance show that the control system remains defensible over time. This page is written for TSP security, engineering, and audit teams who need a repeatable compliance program, not a one-time documentation sprint. ## 1) Define scope like an auditor (services, systems, and external support) Start with a scope definition that mirrors how trust services are actually delivered: production systems, management/admin networks, facilities, staff in trusted roles, and the external organizations that support the service. Your scope statement should be stable across audits and flexible across versions: it should reference service lines (e.g., certificates, timestamps, registered delivery) and the systems that implement them. - Inventory: trust services provided, relying parties/subscribers, and critical service dependencies - System boundary: trustworthy systems, admin systems, development/test segregation, and supporting networks/zones - External support: cloud providers, security tooling providers, subcontractors, and their obligations - Reference the current EN 319 401 V3.1.1 publication scope and record which services are qualified, non-qualified, or mixed in the same operating environment ## 2) Make risk assessment (REQ-5) the control engine REQ-5 requires a risk assessment that identifies/analyzes/evaluates trust service risks and drives risk treatment measures that are commensurate to risk. The compliance trick is to make risk outputs directly generate controls, procedures, and evidence requirements. If your risk assessment is not connected to control changes, you will fail on paper only compliance: policies exist but do not drive engineering or operations. - Risk register tied to assets and services: threats, vulnerabilities, impacts, and likelihoods - Risk treatment plan that maps to: policy updates (REQ-6) and operational controls (REQ-7) - Management approval and residual risk acceptance evidence (REQ-5-05) ## 3) Build a policy stack you can operate (REQ-6.1, 6.2, 6.3) ETSI EN 319 401 expects a Trust Service Practice Statement and Terms & Conditions that are approved, published, and communicated appropriately. It also requires an information security policy system that is documented, implemented, maintained, and reviewed. Treat policies as versioned system components: each policy has owners, review cadence, change control, and downstream operational procedures. - Practice statement: how you address applicable trust service policy requirements and external support obligations - Terms & conditions: including event log retention period, limitations, dispute process, and availability undertakings - Information security policy: third-party communications for relevant changes; planned reviews; configuration compliance checks ## 4) Operational controls that dominate audit outcomes (REQ-7.8 to 7.10) Most findings appear in the operational clauses: network security, vulnerability management, monitoring/logging, incident response and reporting, and evidence retention. The operational clauses extend beyond monitoring and logging. A mature EN 319 401 program also has to manage business continuity, cessation planning, and supplier controls where subcontracting, outsourcing, cloud use, or trust service components are involved. - Network security (REQ-7.8): zones, restricted communications, disabling unneeded services, and trusted channels between trustworthy systems - Security testing: vulnerability scanning with evidence of competence/independence; default quarterly cadence; pen tests after significant changes - Monitoring/logging (REQ-7.9.1): continuous monitoring, alarms, log coverage, automated log processing and alerting - Incident response/reporting (REQ-7.9.2-7.9.3): containment/eradication/recovery, comms plans, 48-hour critical vulnerability handling, 24-hour breach notification procedure - Evidence retention (REQ-7.10): integrity, confidentiality, availability for proceedings, and daily UTC sync for audit log time - Supplier and outsourcing controls (REQ-7.14.3): documented agreements, service levels, security obligations, and review of supplier cybersecurity practices ## 5) Operating cadence (what to do weekly, monthly, quarterly) Turn REQs into calendarized operations so compliance stays true between audits. A good program defines scheduled controls and can show evidence for every period. Use your risk assessment to tune cadence, but be careful: ETSI EN 319 401 contains concrete expectations (e.g., quarterly vulnerability scanning as a recommendation) that auditors will expect you to address explicitly. - Weekly: review critical alerts, privileged access changes, and key monitoring dashboards - Monthly: configuration compliance checks and policy-violation change detection reviews - Quarterly: vulnerability scanning evidence, risk assessment review delta, and incident tabletop exercises - Post-change: penetration testing triggers after significant upgrades/modifications and remediation follow-through - After significant service or infrastructure change: re-check pen test triggers, supplier dependencies, and whether conformity evidence needs refresh before the next audit window ## 6) Evidence pack structure (make it easy to share and hard to dispute) Evidence should be attributable (owner + timestamp), versioned (linked to services and system versions), and complete (covers scope). The best evidence is operational evidence generated by your systems. Avoid document sprawl. Build a single evidence index that links each REQ category to its artifacts and latest verification results. - REQ index: REQ -> control narrative -> verification method -> evidence link(s) - Operational evidence: monitoring/log summaries, scan reports, pen test reports, incident records, and post-incident reviews - Retention proof: log immutability controls, backups/off-site storage, and UTC time synchronization evidence - Conformity-assessment context: keep an assessor-friendly evidence index that aligns with EN 319 403-1 expectations for TSP assessments *Recommended next step* *Placement: after the compliance steps* ## Turn ETSI EN 319 401 Compliance into an operational assessment Assessment Autopilot can take ETSI EN 319 401 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on ETSI EN 319 401 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ETSI EN 319 401 Compliance](/solutions/assessment.md): Start from ETSI EN 319 401 Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ETSI EN 319 401](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 319 401 Compliance. ## Primary sources - [ETSI EN 319 401 V3.1.1 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Primary source for the requirements and operational expectations referenced in this compliance playbook. - [ETSI EN 319 403-1 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/319400_319499/31940301/01.05.01_60/en_31940301v010501p.pdf?ref=sorena.io) - Reference standard for conformity assessment bodies assessing Trust Service Providers. - [ETSI IPR Database](https://ipr.etsi.org/?ref=sorena.io) - IPR due diligence reference for ETSI deliverables. ## Related Topic Guides - [ETSI EN 319 401 Audit & Conformity Assessment (Evidence Pack + Checklist)](/artifacts/global/etsi-en-319-401/audit-and-conformity-assessment.md): Audit readiness guide for ETSI EN 319 401 Trust Service Providers: how conformity assessment works in practice, what auditors sample. - [ETSI EN 319 401 FAQ for Trust Service Providers (TSPs)](/artifacts/global/etsi-en-319-401/faq.md): Frequently asked questions about ETSI EN 319 401 for Trust Service Providers: what a Trust Service Practice Statement is, how risk assessment drives controls. - [ETSI EN 319 401 Requirements (REQ-5/6/7 Map for Trust Service Providers)](/artifacts/global/etsi-en-319-401/requirements.md): Clause-by-clause ETSI EN 319 401 requirements mapping for Trust Service Providers (TSPs): risk assessment (REQ-5). - [ETSI EN 319 401 vs eIDAS (Mapping to Article 19 & 24 TSP Obligations)](/artifacts/global/etsi-en-319-401/etsi-en-319-401-vs-eidas.md): Practical mapping of ETSI EN 319 401 requirements to the EU eIDAS Regulation (EU) No 910/2014. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-401/compliance --- --- title: "ETSI EN 319 401 vs eIDAS (Mapping to Article 19 & 24 TSP Obligations)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-401/etsi-en-319-401-vs-eidas" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-401/etsi-en-319-401-vs-eidas" author: "Sorena AI" description: "Practical mapping of ETSI EN 319 401 requirements to the EU eIDAS Regulation (EU) No 910/2014." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 319 401 vs eIDAS" - "eIDAS Article 19 security requirements trust service providers" - "eIDAS Article 24 qualified trust service provider requirements" - "trust service practice statement" - "incident notification within 24 hours" - "monitoring and logging" - "conformity assessment report" - "ETSI EN 319 401 Annex B mapping" - "eIDAS Article 19 security" - "eIDAS Article 24 qualified TSP" - "Trust Service Provider" - "Conformity assessment" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 401 vs eIDAS (Mapping to Article 19 & 24 TSP Obligations) Practical mapping of ETSI EN 319 401 requirements to the EU eIDAS Regulation (EU) No 910/2014. *Artifact Guide* *GLOBAL* ## ETSI EN 319 401 vs eIDAS How ETSI EN 319 401 requirements support eIDAS-aligned TSP compliance and evidence. This is an implementation mapping, not legal advice. Validate obligations against the eIDAS regulation, supervisory guidance, and your service qualification status. eIDAS sets legal obligations for trust services in the EU. ETSI EN 319 401 is a standards-based operational blueprint for implementing and proving those obligations. The goal is not to swap law for a standard, but to use EN 319 401 requirements on risk assessment, policies, monitoring, incident reporting, evidence retention, and supplier control as the execution layer under eIDAS and the related assessment ecosystem. ## Where the mapping is strongest (why auditors like EN 319 401 evidence) ETSI EN 319 401 structures security obligations as testable operational requirements (REQ-*), while eIDAS frames them as legal duties (risk-based technical/organizational measures, incident notification, qualified provider requirements, record keeping, etc.). This makes EN 319 401 a strong evidence generator: you can show how your policies and controls satisfy eIDAS outcomes with traceable artifacts. - Risk-based security: EN 319 401 clause 5 drives security requirements commensurate to risk - Operational controls: monitoring/logging + incident response/reporting are explicit and evidence-friendly - Documentation and evidence: practice statement + evidence retention requirements make claims defensible - Narrow but important point: Annex B is informative, so use it as a mapping aid rather than a substitute for reading the underlying eIDAS provisions ## eIDAS security and incident notification outcomes (operationalized by EN 319 401) eIDAS includes security requirements for trust service providers and expectations to prevent/minimize incident impact and inform stakeholders. EN 319 401 operationalizes this through monitoring/logging requirements, incident response procedures, stakeholder communication plans, and explicit notification procedures with time expectations. If you can produce EN 319 401 evidence for REQ-7.9, you can usually demonstrate you are capable of meeting eIDAS-style incident duties. - Continuous monitoring + logging (REQ-7.9.1): detect abnormal activity and generate alarms with automated processing - Incident response procedures (REQ-7.9.2): containment, eradication, recovery, documentation, and competence - Reporting procedures (REQ-7.9.3): notification procedures for significant-impact breaches with 24-hour readiness ## Terms, limitations, and relying party transparency eIDAS expects trust service providers to inform customers about limitations and related terms. EN 319 401 clause 6.2 requires Terms and Conditions to include key elements such as limitations of liability, retention period for event logs, procedures for complaints and dispute settlement, and whether the service has been assessed as conformant (and under which scheme). This is where many TSPs under-document: operational reality may be strong, but subscriber/relying party transparency is weak. - Publish clear terms, including retention periods for logs and service availability undertakings (REQ-6.2) - Tie limitations and relying party guidance to actual operational controls and evidence - Keep terms updated via change control and provide due notice where required (REQ-6.1-09 conditional) ## Evidence, record keeping, and time integrity (legal defensibility) eIDAS compliance often becomes a question of proof: can you show correct operation, integrity, and continuity over time? EN 319 401 clause 7.10 focuses on evidence collection, confidentiality/integrity of records, and making records available for legal proceedings and continuity. A very practical control is audit log time integrity: EN 319 401 requires synchronizing the time used to record audit log events with UTC at least once per day. - Evidence retention system that stays accessible even if services cease (REQ-7.10-01) - Tamper resistance for logs/events and reliable long-term storage (REQ-7.10-08) - Daily UTC synchronization evidence for audit log time (REQ-7.10-06) - Qualified and non-qualified TSPs should both document how EN 319 401 evidence supports article 19 security duties, even where article 24 obligations do not apply in full ## Conformity assessment: how to make assessments easier EN 319 401 includes an informative mapping to eIDAS in Annex B, and EN 319 403-1 provides the assessor-side context for TSP conformity assessment. The practical implication is straightforward: structure your evidence pack around EN 319 401 clauses, then reference the mapping and the assessment context when you need to show eIDAS alignment. This reduces audit friction: assessors can follow a predictable path from legal outcome -> EN 319 401 clause -> operational evidence. - Build an evidence index keyed by REQ categories with links to latest proof - Use mapping narrative: eIDAS outcome -> EN clause(s) -> control summary -> evidence links - Keep a versioned scope statement so assessments are reproducible across audits *Recommended next step* *Placement: after the comparison section* ## Use ETSI EN 319 401 vs eIDAS as a cited research workflow Research Copilot can take ETSI EN 319 401 vs eIDAS from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on ETSI EN 319 401 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ETSI EN 319 401 vs eIDAS](/solutions/research-copilot.md): Start from ETSI EN 319 401 vs eIDAS and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ETSI EN 319 401](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 319 401 vs eIDAS. ## Primary sources - [ETSI EN 319 401 V3.1.1 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Primary source for requirements and Annex B informative mapping between EN 319 401 and eIDAS. - [eIDAS Regulation (EU) No 910/2014 (EUR-Lex consolidated text)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02014R0910-20240520&ref=sorena.io) - Primary legal source for EU trust services framework and trust service provider obligations. - [ETSI IPR Database](https://ipr.etsi.org/?ref=sorena.io) - IPR due diligence reference for ETSI deliverables. - [ETSI EN 319 403-1 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/319400_319499/31940301/01.05.01_60/en_31940301v010501p.pdf?ref=sorena.io) - Assessment context for conformity assessment bodies reviewing TSP conformance. ## Related Topic Guides - [ETSI EN 319 401 Audit & Conformity Assessment (Evidence Pack + Checklist)](/artifacts/global/etsi-en-319-401/audit-and-conformity-assessment.md): Audit readiness guide for ETSI EN 319 401 Trust Service Providers: how conformity assessment works in practice, what auditors sample. - [ETSI EN 319 401 Compliance Playbook for Trust Service Providers (TSPs)](/artifacts/global/etsi-en-319-401/compliance.md): How to operationalize ETSI EN 319 401 compliance for Trust Service Providers: scope definition, governance, risk assessment to control mapping. - [ETSI EN 319 401 FAQ for Trust Service Providers (TSPs)](/artifacts/global/etsi-en-319-401/faq.md): Frequently asked questions about ETSI EN 319 401 for Trust Service Providers: what a Trust Service Practice Statement is, how risk assessment drives controls. - [ETSI EN 319 401 Requirements (REQ-5/6/7 Map for Trust Service Providers)](/artifacts/global/etsi-en-319-401/requirements.md): Clause-by-clause ETSI EN 319 401 requirements mapping for Trust Service Providers (TSPs): risk assessment (REQ-5). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-401/etsi-en-319-401-vs-eidas --- --- title: "ETSI EN 319 401 FAQ for Trust Service Providers (TSPs)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-401/faq" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-401/faq" author: "Sorena AI" description: "Frequently asked questions about ETSI EN 319 401 for Trust Service Providers: what a Trust Service Practice Statement is, how risk assessment drives controls." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 319 401 FAQ" - "trust service provider requirements" - "trust service practice statement" - "information security policy REQ-6.3" - "risk assessment REQ-5" - "quarterly vulnerability scanning REQ-7.8-14" - "vulnerability scan independence REQ-7.8-13" - "penetration testing REQ-7.8-17" - "monitoring and logging REQ-7.9.1" - "incident response REQ-7.9.2" - "incident notification within 24 hours REQ-7.9.3" - "evidence collection REQ-7.10" - "UTC sync audit logs REQ-7.10-06" - "Trust Service Provider" - "Audit readiness" - "Incident reporting" - "Evidence retention" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 401 FAQ for Trust Service Providers (TSPs) Frequently asked questions about ETSI EN 319 401 for Trust Service Providers: what a Trust Service Practice Statement is, how risk assessment drives controls. *Artifact Guide* *GLOBAL* ## ETSI EN 319 401 FAQ Fast, operational answers for TSP security, engineering, and audit teams. Focused on what you need to build, how to prove it, and what auditors sample most often. This FAQ focuses on practical implementation and evidence. It's written for teams responsible for trust service operations, security controls, incident handling, and audit readiness. ## What is ETSI EN 319 401 (in plain language)? ETSI EN 319 401 is a European Standard that defines general policy requirements for Trust Service Providers. It covers how a TSP should manage risk, define policies and practices, run secure operations, detect/respond/report incidents, and retain evidence. It's often used as an operational blueprint under legal frameworks like eIDAS and as a baseline for conformity assessment and procurement assurance. - Think of it as how a TSP should operate securely, not only what to document - Operational proof (scans, logs, incident records) matters more than paper policies ## What changed in the current V3.1.1 release? The current release is ETSI EN 319 401 V3.1.1 (2024-06), adopted on 30 May 2024, with national endorsement and withdrawal milestones falling on 28 February 2025. The standard also states that the 2024 revision updates the document to take NIS2 into account and refreshes references such as ISO/IEC 27002:2022. In practice, teams using older internal mappings should review requirement numbering, monitoring and incident-management language, and supply-chain expectations before reusing older audit packs. - Confirm that internal control matrices reference the current REQ numbering - Refresh legacy evidence packs that were built against older V2.x summaries - Make sure NIS2-aware incident and risk management language is reflected in procedures and reporting plans ## What is a Trust Service Practice Statement and why do auditors care? EN 319 401 requires the TSP to have a statement of practices and procedures addressing applicable trust service policy requirements and to make relevant documentation available to subscribers and relying parties as necessary to demonstrate conformance. Auditors care because it's the bridge between requirements and reality: it explains how your service is operated and what evidence exists (without exposing sensitive details). - Keep it versioned with a review cadence and change control - Tie it to operational procedures and evidence index links ## How should we use risk assessment (REQ-5) in practice? REQ-5 requires risk assessment and risk treatment measures commensurate to risk, with management approval and regular review. The common failure is treating risk as a standalone document. Make risk outputs drive control changes: monitoring coverage, scan cadence, segmentation changes, and incident response capacity. - Risk register -> risk treatment plan -> control implementation -> evidence generation - Use risk reviews to justify cadence changes (but document and defend them) ## Do we really need quarterly vulnerability scans? EN 319 401 requires regular vulnerability scans and evidence that scans were performed by a competent and independent party. It also recommends that the scan should be performed once per quarter. If you choose a different cadence, be prepared to justify it via risk assessment, exposure, and compensating controls. Quarterly is the defensible default for most TSP scopes. - Keep scan scope inventory (public/private IPs) and evidence of competence/independence - Track remediation outcomes and risk acceptance decisions when applicable ## When do we need penetration tests? EN 319 401 requires penetration testing after infrastructure or application upgrades/modifications that the TSP determines are significant. The key is to define significance in your program, for example new trust service components, major network changes, or privileged access redesign, and prove you applied the trigger consistently. - Define a change classification that triggers pen tests - Keep evidence: change ticket -> trigger decision -> pen test report -> remediation proof ## What does 24 hour reporting readiness mean here? EN 319 401 includes requirements to establish procedures to notify appropriate parties of significant-impact breaches within 24 hours of breach identification and to comply with reporting obligations in relevant legislative frameworks. Operationally: you need detection, categorization, escalation, and a prepared communication and reporting workflow that can execute within the time window. - Practice: tabletop exercises and post-incident reviews to prove the workflow works - Evidence: incident records, timestamps, stakeholder notifications, and supervisory reporting logs ## Why does UTC time synchronization matter for audit logs? EN 319 401 requires synchronizing the time used to record audit log events with UTC at least once per day. This is about legal defensibility and incident reconstruction. If time integrity is weak, your incident timelines and audit evidence can be challenged. - Keep daily UTC sync evidence and monitor for drift - Ensure time is consistent across systems, logs, and retained evidence archives ## How should we handle outsourcing and cloud providers? EN 319 401 does not let a TSP outsource responsibility. When suppliers, cloud providers, or external trust service components are used, the TSP remains responsible for conformance with the supply-chain policy, information security policy, and the applicable trust service policy. Operationally, that means contracts, service levels, review cycles, and incident-response interfaces must all be part of the evidence system. - Keep documented agreements and named security obligations for each relevant supplier - Review supplier cybersecurity practices at planned intervals and after relevant incidents - Record which controls are implemented by the TSP and which are implemented by the supplier *Recommended next step* *Placement: after the FAQ section* ## Use ETSI EN 319 401 FAQ as a cited research workflow Research Copilot can take ETSI EN 319 401 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on ETSI EN 319 401 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ETSI EN 319 401 FAQ](/solutions/research-copilot.md): Start from ETSI EN 319 401 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ETSI EN 319 401](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 319 401 FAQ. ## Primary sources - [ETSI EN 319 401 V3.1.1 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Primary source for REQ-5/6/7 obligations referenced in this FAQ. - [ETSI Coordinated Vulnerability Disclosure Program](https://www.etsi.org/standards/coordinated-vulnerability-disclosure?ref=sorena.io) - ETSI's reporting channel referenced in the standard's front matter. ## Related Topic Guides - [ETSI EN 319 401 Audit & Conformity Assessment (Evidence Pack + Checklist)](/artifacts/global/etsi-en-319-401/audit-and-conformity-assessment.md): Audit readiness guide for ETSI EN 319 401 Trust Service Providers: how conformity assessment works in practice, what auditors sample. - [ETSI EN 319 401 Compliance Playbook for Trust Service Providers (TSPs)](/artifacts/global/etsi-en-319-401/compliance.md): How to operationalize ETSI EN 319 401 compliance for Trust Service Providers: scope definition, governance, risk assessment to control mapping. - [ETSI EN 319 401 Requirements (REQ-5/6/7 Map for Trust Service Providers)](/artifacts/global/etsi-en-319-401/requirements.md): Clause-by-clause ETSI EN 319 401 requirements mapping for Trust Service Providers (TSPs): risk assessment (REQ-5). - [ETSI EN 319 401 vs eIDAS (Mapping to Article 19 & 24 TSP Obligations)](/artifacts/global/etsi-en-319-401/etsi-en-319-401-vs-eidas.md): Practical mapping of ETSI EN 319 401 requirements to the EU eIDAS Regulation (EU) No 910/2014. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-401/faq --- --- title: "ETSI EN 319 401 Requirements (REQ-5/6/7 Map for Trust Service Providers)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-401/requirements" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-401/requirements" author: "Sorena AI" description: "Clause-by-clause ETSI EN 319 401 requirements mapping for Trust Service Providers (TSPs): risk assessment (REQ-5)." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 319 401 requirements" - "ETSI EN 319 401 REQ-5 risk assessment" - "trust service practice statement REQ-6.1" - "information security policy REQ-6.3" - "terms and conditions REQ-6.2" - "network security REQ-7.8" - "vulnerability scan REQ-7.8-13" - "quarterly vulnerability scanning REQ-7.8-14" - "penetration test REQ-7.8-17" - "monitoring and logging REQ-7.9.1" - "incident response REQ-7.9.2" - "24 hour incident reporting REQ-7.9.3" - "evidence collection REQ-7.10" - "audit logs UTC synchronization REQ-7.10-06" - "trust service provider compliance" - "Trust Service Provider" - "Risk assessment" - "Monitoring and logging" - "Incident response" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 401 Requirements (REQ-5/6/7 Map for Trust Service Providers) Clause-by-clause ETSI EN 319 401 requirements mapping for Trust Service Providers (TSPs): risk assessment (REQ-5). *Artifact Guide* *GLOBAL* ## ETSI EN 319 401 Requirements A practical map of ETSI EN 319 401 requirements for Trust Service Providers (TSPs). Translate REQ-5/6/7 into controls, tests, and audit-ready evidence for trust services, relying parties, and supervisory scrutiny. ETSI EN 319 401 is easiest to implement when you treat each requirement (REQ-*) as a verifiable claim: (1) the control exists, (2) it operates continuously, and (3) you can prove it with evidence tied to your scope (trust services, systems, facilities, people, and suppliers). This page maps the most operationally important requirements into implementation and evidence expectations. ## How to use this requirements map (avoid checklist failure) Build your program around the standard structure: risk assessment in clause 5, policies and practices in clause 6, and TSP management and operation in clause 7. The current release is ETSI EN 319 401 V3.1.1 (2024-06), adopted on 30 May 2024, with national endorsement by 28 February 2025. For every REQ you claim, attach: control owner, operating procedure, verification method, and evidence location. Make evidence generation part of normal operations (monitoring, change management, releases, and incident response). - Scope first: define which trust services and systems are in-scope, including external supporting organizations - Evidence first: treat REQ-7.10 evidence collection and retention as a system design problem - Operate continuously: monitoring/logging and incident response should run every day, not only before audits *Recommended next step* *Placement: after the requirement breakdown* ## Turn ETSI EN 319 401 Requirements into an operational assessment Assessment Autopilot can take ETSI EN 319 401 Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on ETSI EN 319 401 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ETSI EN 319 401 Requirements](/solutions/assessment.md): Start from ETSI EN 319 401 Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ETSI EN 319 401](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 319 401 Requirements. ## Clause 5 - Risk assessment (REQ-5-01 to REQ-5-05) ETSI EN 319 401 requires the TSP to carry out a risk assessment covering business and technical issues, select risk treatment measures, determine security requirements and operational procedures to implement those measures, review and revise the risk assessment regularly, and have management approve and accept residual risk. Operationally, clause 5 is your control generator: it drives the minimum security baseline, the priorities, and the justification for why specific controls exist (or why certain controls are proportionate). - Risk assessment artifact: scope, assets, threats, vulnerabilities, impacts, likelihoods, and treatment decisions - Risk treatment plan: controls mapped to clause 6 policies and clause 7 operational controls - Management approval evidence: sign-off record and residual risk acceptance rationale ## Clause 6 - Policies and practices (REQ-6.1 and REQ-6.2) Clause 6 expects your policy layer to exist, be approved by management, published or communicated appropriately, and to be usable by subscribers and relying parties where required. This includes your Trust Service Practice Statement and your Terms and Conditions. A strong implementation turns these documents into operational interfaces: they describe how your service works, what relying parties can expect, and what evidence you can provide without exposing sensitive details. - Trust Service Practice Statement (REQ-6.1): practices/procedures addressing applicable trust service policy requirements and identifying external supporting organizations - Change notification (REQ-6.1-09 conditional): define when changes require notice and how you publish due notice - Terms and Conditions (REQ-6.2): include limitations, relying party info, retention periods for event logs, complaints/dispute processes, and availability undertakings ## Clause 6.3 - Information security policy (REQ-6.3-01 to REQ-6.3-09) ETSI EN 319 401 requires an information security policy approved by management, communicated to relevant third parties where applicable, documented/implemented/maintained with controls and operating procedures, and reviewed at planned intervals or after significant changes. The standard also expects configuration checks for policy violations with a documented maximum interval (in your practice statement), and approval for security-impacting changes by the management body. - Policy system: versioned security policy + topic policies + procedures that can be audited - Third-party comms: defined channels to communicate relevant policy changes to subscribers/relying parties/assessment bodies/supervisors - Configuration compliance: documented checking interval, detection of policy-violating changes, and follow-up actions ## Clause 7.8 - Network security, vulnerability scanning, and pen testing (REQ-7.8-01 to REQ-7.8-17) Clause 7.8 is unusually concrete for a policy standard: it covers segmentation into zones, restricting zone communications, disabling unneeded connections/services, separating production from dev/test, trusted channels between trustworthy systems, and security testing expectations. Two audit magnets: evidence of regular vulnerability scans (including independence/competence) and penetration tests after significant upgrades or modifications. - Zone design evidence: network diagrams, segmentation rules, and rule-set review records - Vulnerability scanning evidence (REQ-7.8-13): scan scope (public/private IPs), scan cadence, and competence/independence proof - Quarterly scan expectation (REQ-7.8-14): adopt quarterly as the default unless your risk model justifies otherwise - Pen testing (REQ-7.8-17): trigger criteria for significant changes, test scope, remediation tracking ## Clause 7.9 - Monitoring/logging, incident response, and 24-hour reporting (REQ-7.9.1-7.9.5) ETSI EN 319 401 expects continuous monitoring and logging, detection and alarming on abnormal activities, and regular review of logs with automatic processing and alerting for critical events. It also sets expectations for incident response procedures, communication plans, documentation, testing of roles/procedures, and specific time-bound handling such as addressing critical vulnerabilities within 48 hours after discovery and establishing notification procedures to appropriate parties within 24 hours for significant breaches. - Logging scope (REQ-7.9.1-04): network traffic, privileged activities, configuration changes, backups, physical access (where appropriate), and security-relevant logs - Critical vulnerability clock (REQ-7.9.2-09): 48-hour handling expectation for critical vulnerabilities - Breach notification readiness (REQ-7.9.3-01): procedures to notify appropriate parties within 24 hours for significant impact breaches - Post-incident reviews (REQ-7.9.5): root cause, recurrence mitigation, and ensuring reviews actually happen ## Clause 7.10 - Evidence collection and audit logs (REQ-7.10-01 to REQ-7.10-08) Clause 7.10 requires recording and keeping accessible relevant information for an appropriate period (including after TSP activities cease) to provide evidence and continuity, while maintaining confidentiality and integrity of records and ensuring availability for legal proceedings. A key detail: the time used to record events in the audit log must be synchronized with UTC at least once a day. - Evidence retention system: retention periods, integrity controls, and access governance - Audit log time integrity (REQ-7.10-06): daily UTC synchronization and proof that it occurs - Tamper resistance (REQ-7.10-08): design logs so they cannot be easily deleted/destroyed (or are safely transferred) ## Clause 7.14.3 - Supply chain and outsourcing controls The 2024 release gives more weight to supplier and third-party governance than many older EN 319 401 summaries show. When a TSP uses subcontracting, outsourcing, cloud providers, or external trust service components, the TSP keeps overall responsibility for conformance with its policy and security requirements. This is where many programs are too light. Contracts alone are not enough. You need review cycles, security expectations, and evidence that supplier cybersecurity practices are monitored and re-evaluated. - Document agreements and contractual relationships covering relevant security obligations and service levels - Define how external trust service components and cloud services are approved, monitored, and re-assessed after incidents or major changes - Keep evidence that direct suppliers and service providers take security measures aligned with the TSP risk assessment - Review supply-chain policy and supplier cybersecurity practices at planned intervals and after relevant incidents ## Primary sources - [ETSI EN 319 401 V3.1.1 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Primary source for REQ-5/6/7 requirements referenced throughout this requirements map. - [ETSI EN 319 403-1 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/319400_319499/31940301/01.05.01_60/en_31940301v010501p.pdf?ref=sorena.io) - Companion conformity-assessment standard for TSP assessors. - [ETSI Coordinated Vulnerability Disclosure Program](https://www.etsi.org/standards/coordinated-vulnerability-disclosure?ref=sorena.io) - ETSI's public reporting channel referenced in the standard's front matter. - [ETSI IPR Database](https://ipr.etsi.org/?ref=sorena.io) - Use for IPR due diligence when adopting ETSI deliverables in compliance statements or contracts. ## Related Topic Guides - [ETSI EN 319 401 Audit & Conformity Assessment (Evidence Pack + Checklist)](/artifacts/global/etsi-en-319-401/audit-and-conformity-assessment.md): Audit readiness guide for ETSI EN 319 401 Trust Service Providers: how conformity assessment works in practice, what auditors sample. - [ETSI EN 319 401 Compliance Playbook for Trust Service Providers (TSPs)](/artifacts/global/etsi-en-319-401/compliance.md): How to operationalize ETSI EN 319 401 compliance for Trust Service Providers: scope definition, governance, risk assessment to control mapping. - [ETSI EN 319 401 FAQ for Trust Service Providers (TSPs)](/artifacts/global/etsi-en-319-401/faq.md): Frequently asked questions about ETSI EN 319 401 for Trust Service Providers: what a Trust Service Practice Statement is, how risk assessment drives controls. - [ETSI EN 319 401 vs eIDAS (Mapping to Article 19 & 24 TSP Obligations)](/artifacts/global/etsi-en-319-401/etsi-en-319-401-vs-eidas.md): Practical mapping of ETSI EN 319 401 requirements to the EU eIDAS Regulation (EU) No 910/2014. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-401/requirements --- --- title: "ETSI EN 319 411-1 V1.5.1 Compliance Playbook (CA and TSP Certificate Issuance Operations)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/compliance" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/compliance" author: "Sorena AI" description: "How to operationalize ETSI EN 319 411-1 V1.5.1 for certificate issuing Trust Service Providers: CP and CPS governance, repository duties." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 319 411-1 compliance" - "ETSI EN 319 411-1 V1.5.1" - "CA compliance playbook" - "certification practice statement CPS" - "certificate policy CP" - "PKI disclosure statement" - "repository responsibilities" - "identity validation workflow" - "certificate issuance lifecycle" - "revocation management" - "OCSP CRL availability 24/7" - "audit logging procedures" - "records archival" - "retention seven years" - "EN 319 403-1" - "certificate status consistency" - "Certification Practice Statement" - "Identity validation" - "Revocation and status services" - "Audit logging" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 411-1 V1.5.1 Compliance Playbook (CA and TSP Certificate Issuance Operations) How to operationalize ETSI EN 319 411-1 V1.5.1 for certificate issuing Trust Service Providers: CP and CPS governance, repository duties. *Artifact Guide* *GLOBAL* ## ETSI EN 319 411-1 Compliance A compliance playbook for certificate issuing TSPs that produces defensible evidence by default. Focus: CP and CPS quality, repository governance, identity validation, lifecycle controls, revocation and status services, and evidence retention that withstands audits and relying-party scrutiny. ETSI EN 319 411-1 compliance is not a document exercise. It is a production system: you publish CP, CPS, and disclosure artifacts; run identity validation and authenticated requests; execute certificate lifecycle state transitions reliably; and prove it all through logs and archives that remain usable years later. This page translates the current V1.5.1 standard into a practical operating program for certificate issuing CAs and TSPs. ## 1) Define scope and services like a relying party would Start by explicitly scoping which certificate services you provide, which certificate policies you assert, and which operational components are in scope, including RA functions, CA signing systems, status infrastructure, repositories, and outsourced service components. Your scope statement is the foundation for every assessment and every customer assurance request. If you cannot state which policy identifiers map to which service instances and which systems support them, the rest of the compliance program will drift. - Service inventory: certificate types, policy identifiers asserted, relying-party communities, and whether the service is public web PKI or another trust model - System inventory: signing systems, issuance pipelines, identity-proofing systems, repositories, and status endpoints - Role inventory: registration officers, revocation officers, privileged operators, security administrators, and external service providers ## 2) Build the CP, CPS, and repository program EN 319 411-1 draws a clear boundary: CP communicates what requirements are adhered to, while CPS communicates how you adhere to them. Low-level operational procedures may remain internal, but the public set still has to be accurate, versioned, and easy to discover. Do not treat repository responsibilities as a publishing afterthought. The public repository is how subscribers, subjects, relying parties, and assessors understand what was in force when a certificate was issued, changed, or revoked. - CP and CPS versioning with effective dates, change history, stable URLs, and controlled approvals - Terms and conditions plus PKI disclosure content that accurately reflects revocation and status-service behavior - Change control and notice process for subscribers and relying parties when public documentation changes ## 3) Identity validation and authenticated requests as a control system Identity validation must be consistent with your policy and certificate type. EN 319 411-1 covers naming, initial identity validation, and identification and authentication for re-key and revocation requests. Treat request authentication as the heart of trust. Fraudulent re-key and fraudulent revocation are catastrophic failure modes. If identity proofing or RA work is delegated, the TSP still owns the policy outcome and the evidence trail. - Define validation depth by policy and record the evidence of checks performed for each issuance path - Authenticate re-key and revocation requests with strong controls, clear authorization rules, and tested exception handling - Log validation decisions, delegated-party involvement, and exceptions so disputes can be resolved years later ## 4) Lifecycle operations: make state transitions traceable EN 319 411-1 covers certificate application processing, issuance, acceptance, renewal, re-key, modification, revocation or suspension, and end of subscription. The compliance goal is a reliable state machine with evidence. If a certificate changes state, you should be able to reconstruct why, who authorized it, what checks were performed, and what was published to relying parties. - Workflow: request, validation, issuance, acceptance, monitoring, and change events with clear ownership - Separation of duties and privileged-access controls around issuance, re-key, modification, and revocation functions - Operational metrics: issuance lead time, re-key lead time, revocation lead time, status propagation delay, and repository update delay ## 5) Revocation and suspension program Revocation must be timely and based on authorized, validated requests. EN 319 411-1 includes detailed expectations for revocation handling and also addresses short-term certificates where certain revocation requirements may not apply. Even when certificates are non-revocable in a short-term model, you still need a problem-reporting channel, documented handling, and audit logging of notified problems. The compliance question is not just whether you revoked, but whether you can prove you handled the event correctly under the policy in force. - Revocation request intake: channels, authentication, authorization, escalation, and evidence-retention rules - Timeliness objectives with measured performance and exception handling when response targets are missed - Short-term certificates: explicit non-revocation model, problem-report workflow, and public status interpretation guidance ## 6) Status services are production infrastructure EN 319 411-1 expects revocation status information to be available 24 by 7 and for multi-method status offerings such as CRL and online status to stay consistent over time, with interpretation documented when delay windows exist. In practice, assessors will sample availability evidence, update propagation evidence, and failure behavior. Treat status endpoints as customer-facing infrastructure, not a side service hidden behind the CA. - Availability objectives: 24 by 7 with a CPS-defined maximum outage; monitor and report outages - Consistency controls: ensure revocation updates propagate across CRL and online-status paths and explain interpretation if a delay window exists - Public and international reach: treat endpoints as globally reachable dependencies with tested recovery ## 7) Underlying control environment: people, keys, resilience, and termination EN 319 411-1 also covers facility, management, and operational controls. That means physical security, personnel controls, procedural controls, key changeover, compromise handling, disaster recovery, and CA or RA termination are part of the compliance story. If your issuance workflow is strong but privileged access, key custody, or disaster recovery is weak, the certificate service is still weak. Evidence should show how trusted roles are governed and how the service survives compromise or major outage. - Trusted-role governance, least privilege, dual control, and secure onboarding and offboarding for sensitive operators - Key changeover, compromise response, and disaster-recovery plans that include repository and status-service continuity - Termination and transition procedures so certificates, archives, and relying-party information remain manageable if service ownership changes ## 8) Evidence operations: audit logging, archival, and retention EN 319 411-1 includes audit logging procedures and records archival as core controls. Evidence is the difference between thinking you comply and proving you complied. Retention has to be engineered into storage systems and procedures. The ETSI material anchors retention at at least seven years after any certificate based on the records ceases to be valid, so design archives around that floor where those records apply. - Audit logging: issuance actions, validation steps, re-key events, revocation events, repository changes, and status-service changes - Records archival: integrity, confidentiality, access governance, and retrieval procedures for proceedings and assessments - Retention schedule by record type with tested enforcement rather than a policy statement that storage systems ignore *Recommended next step* *Placement: after the compliance steps* ## Turn ETSI EN 319 411-1 Compliance into an operational assessment Assessment Autopilot can take ETSI EN 319 411-1 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on ETSI EN 319 411-1 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ETSI EN 319 411-1 Compliance](/solutions/assessment.md): Start from ETSI EN 319 411-1 Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ETSI EN 319 411-1](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 319 411-1 Compliance. ## Primary sources - [ETSI EN 319 411-1 V1.5.1 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Primary source for certificate policy and practice concepts, identity validation, lifecycle operations, revocation and status services, and operational control expectations. - [ETSI EN 319 403-1 V1.5.1](https://www.etsi.org/deliver/etsi_en/319400_319499/31940301/01.05.01_60/en_31940301v010501p.pdf?ref=sorena.io) - Useful for aligning EN 319 411-1 evidence packages with conformity-assessment expectations. - [ETSI Work Item REN/ESI-0019411-1v151](https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?SearchPage=TRUE&WKI_ID=70003&butSimple=Search&curItemNr=5&includeNonActiveTB=FALSE&includeSubProjectCode=&optDisplay=50&qACHIEVED_DAY=1&qACHIEVED_MONTH=2&qACHIEVED_YEAR=2024&qCLUSTER_BOOLEAN=&qETSI_ALL=&qFREQUENCIES_BOOLEAN=&qINCLUDE_MOVED_ON=&qINCLUDE_SUB_TB=True&qKEYWORD_BOOLEAN=&qMILESTONE=1&qREPORT_TYPE=SUMMARY&qSORT=HIGHVERSION&qSTOPPING_OUTDATED=&qSTOP_FLG=&totalNrItems=34&ref=sorena.io) - Official ETSI work item page for current-version and publication metadata. ## Related Topic Guides - [ETSI EN 319 411-1 V1.5.1 FAQ (CP vs CPS, TLS Policies, Revocation, OCSP/CRL)](/artifacts/global/etsi-en-319-411-1/faq.md): Answering real-world questions about ETSI EN 319 411-1 V1.5.1: CP vs CPS, policy families, identity validation, repository duties, revocation. - [ETSI EN 319 411-1 V1.5.1 Requirements (CP/CPS, Identity Validation, Revocation, OCSP/CRL)](/artifacts/global/etsi-en-319-411-1/requirements.md): ETSI EN 319 411-1 V1.5.1 requirements map for Trust Service Providers issuing certificates: CP vs CPS, policy OIDs, repository duties, identity validation. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-411-1/compliance --- --- title: "ETSI EN 319 411-1 V1.5.1 FAQ (CP vs CPS, TLS Policies, Revocation, OCSP/CRL)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/faq" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/faq" author: "Sorena AI" description: "Answering real-world questions about ETSI EN 319 411-1 V1.5.1: CP vs CPS, policy families, identity validation, repository duties, revocation." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 319 411-1 FAQ" - "ETSI EN 319 411-1 V1.5.1" - "CP vs CPS" - "certification practice statement" - "certificate policy" - "PKI disclosure statement" - "policy OID TLS certificates" - "NCP NCP+ LCP DVCP OVCP IVCP EVCP" - "CA Browser Forum baseline requirements" - "identity validation" - "revocation requests" - "OCSP CRL 24/7 availability" - "short-term certificates non-revocable" - "audit logging and archival" - "EN 319 403-1" - "Certificate Policy OID" - "Revocation and OCSP" - "TLS certificates" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 411-1 V1.5.1 FAQ (CP vs CPS, TLS Policies, Revocation, OCSP/CRL) Answering real-world questions about ETSI EN 319 411-1 V1.5.1: CP vs CPS, policy families, identity validation, repository duties, revocation. *Artifact Guide* *GLOBAL* ## ETSI EN 319 411-1 FAQ Fast answers for CA/TSP teams implementing certificate issuance and lifecycle controls. Grounded in ETSI EN 319 411-1 V1.5.1 and the current ETSI publication record for the 2025 edition. This FAQ is written for engineering, security, compliance, and audit teams running a certificate issuing service. It focuses on operational clarity: what to build, what to publish, what evidence to keep, and which parts of the current ETSI edition actually change day-to-day operations. ## What is the current edition of ETSI EN 319 411-1 and why should we care? The current official ETSI edition is V1.5.1 with cover date 2025-04. ETSI shows publication on 7 April 2025 and adoption on 24 March 2025 for this work item. You should care because internal control matrices, audit templates, and customer assurance packs often lag. If your documents still reference an older revision, your CP, CPS, and assessment evidence can drift out of sync with the edition assessors expect you to know. - Update document references, control mappings, and evidence templates to the current V1.5.1 edition - Check whether older internal guidance still points to withdrawn or superseded wording ## What is the difference between a Certificate Policy and a Certification Practice Statement? ETSI EN 319 411-1 treats the Certificate Policy as what is to be adhered to and the Certification Practice Statement as how it is adhered to. The CP sets the quality and applicability rules. The CPS explains the operating controls the TSP uses to meet them. A practical implementation uses the CP to define policy commitments, including policy identifiers, and uses the CPS to define operational controls, with sensitive internal procedures kept confidential where appropriate. - CP equals commitments and applicability; CPS equals operational reality and control implementation - The public CPS should help relying parties understand the service without exposing sensitive low-level procedures ## Can the CPS stay high level while internal procedures remain confidential? Yes. ETSI EN 319 411-1 allows low-level operational procedures to remain internal while the published CPS is limited to information useful for external parties and is complemented by confidential internal elements. The mistake is going too far in either direction. If the public CPS is too thin, relying parties and assessors cannot understand what is in force. If it exposes sensitive operational detail, you create unnecessary security and confidentiality risk. - Publish enough detail for scope, policy mapping, reliance conditions, status-service interpretation, and change history - Keep runbooks, privileged operational procedures, and sensitive recovery detail under controlled internal governance ## Do we need to publish a PKI disclosure statement? ETSI EN 319 411-1 requires terms and conditions and describes the PKI disclosure statement as the part that relates to PKI operation. The standard allows flexibility in form: it can be a standalone document or split across subscriber agreements and relying-party information. The operational goal is relying-party clarity: how the PKI operates, what is guaranteed, what limitations apply, and where status information can be obtained. - Ensure required disclosure elements exist, are easy to find, and are versioned - Tie disclosures to actual operational controls, repository URLs, and status-service behavior ## Which certificate policies does ETSI EN 319 411-1 define? ETSI EN 319 411-1 defines multiple reference certificate policies, including normalized and lightweight policies and TLS-focused policies aligned to CA Browser Forum expectations such as DVCP, OVCP, IVCP, and EVCP. Choosing a policy is a risk and assurance decision. Higher-assurance policies require stronger identity validation, stronger control evidence, and tighter change management because the policy identifier becomes a reliance signal in the certificate itself. - Map your relying-party risk and use cases to the right policy family before drafting certificate profiles - Treat policy selection as a control decision with documented rationale and ownership ## If we assert a policy OID in TLS certificates, what are we committing to? Policy identifiers in certificates are reliance signals. ETSI EN 319 411-1 notes that for TLS-focused policies, compliance requires following the full and latest relevant CA Browser Forum material, and in case of conflict those CA Browser Forum requirements take precedence in that context. Operationally, this means you need a compliance process that tracks external requirement updates, not a one-time CP and CPS drafting exercise. - Treat policy OID assertions as contract-like commitments - Maintain a change-tracking and remediation workflow for CA Browser Forum updates where applicable ## What does identity validation cover beyond initial issuance? ETSI EN 319 411-1 covers naming and initial identity validation and also identification and authentication for re-key requests and revocation requests. This matters because attackers often target re-key and revocation pathways. If you outsource part of identity proofing or RA operations, the issuing TSP still owns the policy outcome and still has to be able to reconstruct the evidence. - Protect re-key and revocation requests with strong authentication and authorization checks - Keep evidence of validation steps, supplier involvement, and who approved the action ## What is required for revocation and short-term certificates? EN 319 411-1 requires timely revocation based on authorized and validated revocation requests and defines expectations for revocation and suspension operations. Short-term certificates can change how revocation requirements apply. Even in non-revocable short-term cases, EN 319 411-1 still expects problem-notification handling and audit logging of notified problems, so non-revocable does not mean no operational duty. - Define revocation intake channels and authorization rules, then prove execution with logs - For short-term or non-revocable certificates, document the model and keep problem-report evidence ## Do we need status services 24 by 7? ETSI EN 319 411-1 expects revocation status information to be available 24 hours per day, 7 days per week, and it expects consistency across methods if you offer multiple methods such as CRL and online status, with delays and interpretation documented in the CPS when relevant. Treat status services as critical infrastructure: availability, latency, freshness, correctness, and global reach are all audit and relying-party concerns. - Define availability objectives and outage bounds in the CPS and monitor them continuously - Ensure revocation updates propagate consistently across CRL and online-status services ## What evidence should we retain and for how long? EN 319 411-1 includes audit logging and records archival controls. Evidence must remain usable long after issuance and revocation events because certificate disputes and investigations can happen years later. The ETSI material anchors retention at at least seven years after any certificate based on the records ceases to be valid. Use a retention schedule per record category and ensure storage and access controls actually enforce it. - Keep an evidence index: CP and CPS versions, identity-validation evidence, lifecycle logs, revocation logs, and status-service evidence - Design archives for integrity, confidentiality, and retrievability under legal and audit needs *Recommended next step* *Placement: after the FAQ section* ## Use ETSI EN 319 411-1 FAQ as a cited research workflow Research Copilot can take ETSI EN 319 411-1 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on ETSI EN 319 411-1 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ETSI EN 319 411-1 FAQ](/solutions/research-copilot.md): Start from ETSI EN 319 411-1 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ETSI EN 319 411-1](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 319 411-1 FAQ. ## Primary sources - [ETSI EN 319 411-1 V1.5.1 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Primary source for CP and CPS concepts, policy families, identity validation, revocation, and status-service expectations. - [ETSI Work Item REN/ESI-0019411-1v151](https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?SearchPage=TRUE&WKI_ID=70003&butSimple=Search&curItemNr=5&includeNonActiveTB=FALSE&includeSubProjectCode=&optDisplay=50&qACHIEVED_DAY=1&qACHIEVED_MONTH=2&qACHIEVED_YEAR=2024&qCLUSTER_BOOLEAN=&qETSI_ALL=&qFREQUENCIES_BOOLEAN=&qINCLUDE_MOVED_ON=&qINCLUDE_SUB_TB=True&qKEYWORD_BOOLEAN=&qMILESTONE=1&qREPORT_TYPE=SUMMARY&qSORT=HIGHVERSION&qSTOPPING_OUTDATED=&qSTOP_FLG=&totalNrItems=34&ref=sorena.io) - Official ETSI work item page confirming the current V1.5.1 publication record. - [ETSI EN 319 403-1 V1.5.1](https://www.etsi.org/deliver/etsi_en/319400_319499/31940301/01.05.01_60/en_31940301v010501p.pdf?ref=sorena.io) - Useful context for how assessors test the controls and evidence behind EN 319 411-1 implementations. ## Related Topic Guides - [ETSI EN 319 411-1 V1.5.1 Compliance Playbook (CA and TSP Certificate Issuance Operations)](/artifacts/global/etsi-en-319-411-1/compliance.md): How to operationalize ETSI EN 319 411-1 V1.5.1 for certificate issuing Trust Service Providers: CP and CPS governance, repository duties. - [ETSI EN 319 411-1 V1.5.1 Requirements (CP/CPS, Identity Validation, Revocation, OCSP/CRL)](/artifacts/global/etsi-en-319-411-1/requirements.md): ETSI EN 319 411-1 V1.5.1 requirements map for Trust Service Providers issuing certificates: CP vs CPS, policy OIDs, repository duties, identity validation. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-411-1/faq --- --- title: "ETSI EN 319 411-1 V1.5.1 Requirements (CP/CPS, Identity Validation, Revocation, OCSP/CRL)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/requirements" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/requirements" author: "Sorena AI" description: "ETSI EN 319 411-1 V1.5.1 requirements map for Trust Service Providers issuing certificates: CP vs CPS, policy OIDs, repository duties, identity validation." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 319 411-1 requirements" - "ETSI EN 319 411-1 V1.5.1" - "CP vs CPS" - "Certification Practice Statement" - "Certificate Policy" - "PKI disclosure statement" - "certificate policy OID" - "NCP NCP+ LCP" - "DVCP OVCP IVCP EVCP" - "CA Browser Forum mapping" - "identity validation requirements" - "revocation requests authentication" - "certificate revocation and suspension" - "certificate status service OCSP CRL 24/7" - "audit logging procedures" - "records archival" - "retention seven years" - "EN 319 403-1" - "certificate lifecycle management" - "Identity validation" - "Revocation and OCSP" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 411-1 V1.5.1 Requirements (CP/CPS, Identity Validation, Revocation, OCSP/CRL) ETSI EN 319 411-1 V1.5.1 requirements map for Trust Service Providers issuing certificates: CP vs CPS, policy OIDs, repository duties, identity validation. *Artifact Guide* *GLOBAL* ## ETSI EN 319 411-1 Requirements A practical requirements map for TSPs/Certification Authorities issuing certificates (general requirements). Use this current-edition guide to convert ETSI EN 319 411-1 V1.5.1 into CP/CPS content, lifecycle controls, repository duties, and evidence you can defend with auditors and relying parties. ETSI EN 319 411-1 V1.5.1 is operational by design: it defines policy and security requirements for certificate issuance, maintenance, and lifecycle management. The fastest way to implement it is to treat each requirement family as a control system with documented commitments, operational reality, and evidence trails that remain usable years later. The current edition was adopted on 24 March 2025 and published by ETSI on 7 April 2025, so update older internal cross references if they still point to prior versions. ## 1) Documentation stack: CP vs CPS vs terms & PKI disclosure statement ETSI EN 319 411-1 is built around how relying parties and auditors understand certificate services. The Certificate Policy communicates what quality and assurance you claim. The Certification Practice Statement communicates how you implement and operate that policy. Terms and conditions, including the PKI disclosure statement, communicate key reliance and operational information to subscribers, subjects, and relying parties. A compliance anti-pattern is oversharing internal procedures publicly. The standard allows low-level operational procedures to remain internal, while the published CPS can be limited to information useful for external parties and complemented by confidential internal elements. That split should be intentional, version-controlled, and reflected in your document hierarchy. - CP: what is adhered to, including policy scope, quality level, applicability, and identifiers - CPS: how it is adhered to, including the operational controls the issuing TSP actually runs - Terms and conditions plus PKI disclosure statement: concise relying-party information, liability framing, and service commitments ## 2) Policy identifiers and the reference certificate policies you must implement correctly Certificates communicate policy via a CP identifier and documentation references. ETSI EN 319 411-1 defines multiple reference certificate policies, including NCP, NCP+, LCP, and the TLS-focused DVCP, OVCP, IVCP, and EVCP variants. If you assert a policy identifier in publicly trusted TLS certificates, EN 319 411-1 expects you to adhere to the corresponding policy requirements and to track the full current CA Browser Forum baseline or extended validation material where the standard says those external requirements take precedence. - Define which CP families you support and how relying parties discover the applicable CP and CPS for each certificate type - Keep certificate profiles, subject-data rules, and documentation references aligned with the policy identifier you assert - Treat every policy OID as an auditable commitment that has to stay synchronized with external baseline requirements when applicable ## 3) Publication, repository, and reliance transparency Certificate ecosystems fail when relying parties cannot find authoritative information. EN 319 411-1 expects publication and repository responsibilities to be clear: what documentation is public, where it is hosted, how updates are communicated, and how historical versions are retained for reliance and legal evidence. Design the repository as a stable interface for subscribers, subjects, relying parties, and assessors. Version history, effective dates, and change notices should be easy to find and should match the documents actually in force at the time of issuance or revocation decisions. - Public repository with CP, CPS, terms and conditions, PKI disclosure content, and version history - Document how relying parties obtain status information and how to interpret delays or temporary inconsistencies across CRL and online status services - Retain historical public versions so investigations and legal reliance questions can be answered against the correct edition ## 4) Identity validation and authenticated requests (issuance, re-key, revocation) Identity validation is not only for issuance. EN 319 411-1 covers naming and initial identity validation and also identification and authentication for re-key requests and revocation requests. Treat request authentication as a high-risk control. Fraudulent re-key and fraudulent revocation can be as damaging as bad initial vetting. If identity proofing or RA activity is delegated to separate components or suppliers, the evidence still has to satisfy the policy you assert. - Define identity proofing depth by certificate policy and service risk, including natural-person, organization, and website-validation cases - Protect re-key and revocation requests with strong authentication, authorization checks, and clear exception handling - Log validation evidence, delegated-party roles, and approval decisions so later audits can reconstruct who verified what and when ## 5) Certificate lifecycle operational requirements (make it observable) EN 319 411-1 addresses certificate application and processing, issuance, acceptance, renewal, re-key, modification, and end of subscription, plus key escrow/recovery where applicable. The implementation goal is consistent state transitions with evidence: every certificate lifecycle event should be traceable to a request, an authorization decision, and an immutable audit record. - Lifecycle state machine defined in CPS: request, validation, issuance, acceptance, renewal, re-key, modification, revocation or suspension, and end of subscription - Separation of duties between registration, issuance, and revocation roles where applicable - Operational KPIs: validation lead time, issuance lead time, revocation lead time, status freshness, and repository update lag *Recommended next step* *Placement: after the requirement breakdown* ## Turn ETSI EN 319 411-1 Requirements into an operational assessment Assessment Autopilot can take ETSI EN 319 411-1 Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on ETSI EN 319 411-1 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ETSI EN 319 411-1 Requirements](/solutions/assessment.md): Start from ETSI EN 319 411-1 Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ETSI EN 319 411-1](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 319 411-1 Requirements. ## 6) Revocation and suspension (timeliness + authorization + evidence) Revocation controls must be both secure and fast. EN 319 411-1 requires timely revocation based on authorized and validated revocation requests, and it contains detailed expectations for how revocation is handled across different certificate types, including short-term certificates. One subtle but critical operational requirement is that short-term certificates do not remove your incident-handling burden. If you issue short-term certificates that cannot be revoked, you still need a documented way to handle and record reported problems, explain how issues can be notified, and publish how relying parties can obtain status information or no-revocation signaling. - Authorized request validation: clear rules for who can request revocation and how they authenticate - Timeliness targets for revocation processing and evidence of actual performance against those targets - Short-term certificates: explicit non-revocable model, problem-report intake, audit logging, and signaling design ## 7) Certificate status services (OCSP/CRL): availability, consistency, and interpretation Relying parties need reliable revocation status. EN 319 411-1 covers certificate status services and includes expectations such as 24 by 7 availability and consistency across methods when both CRL and online status are offered. Treat OCSP and CRL as critical production services. Monitor availability, latency, freshness, correctness, and propagation behavior, then explain in the CPS how relying parties should interpret any documented delay window between status channels. - Availability objective: status information available 24 by 7 with a CPS-defined maximum outage period - Multi-method consistency: if CRL and OCSP are both offered, ensure revocation updates propagate across methods and document the interpretation rules - Public reachability: treat status endpoints as internationally reachable dependencies with tested fallback and recovery paths ## 8) Control environment behind issuance and status services EN 319 411-1 is not limited to CP and CPS text. It also covers facility, management, and operational controls such as physical security, procedural controls, personnel controls, key changeover, compromise handling, disaster recovery, and CA or RA termination. This matters because a strong CP or CPS cannot compensate for weak production discipline. Your evidence set needs to show who was authorized, how privileged actions were controlled, how critical keys were protected, and how service continuity was maintained when things went wrong. - Personnel and procedural controls around trusted roles, dual control, least privilege, and background governance - Operational resilience for compromise response, disaster recovery, repository continuity, and status-service recovery - Termination and transition planning so certificates, archives, and relying-party information remain manageable if a CA or RA function stops operating ## 9) Audit logging, records archival, and retention (evidence that survives years) EN 319 411-1 includes facility, management, and operational controls such as audit logging procedures and records archival. Evidence quality is often the decisive factor in assessments: you cannot prove correct operation without reliable logs and archives. A practical retention anchor captured in the ETSI material is at least seven years after any certificate based on those records ceases to be valid. Treat retention as a design constraint for repositories, ticketing systems, identity-proofing evidence, revocation logs, and status-service telemetry. - Audit logs: issuance, validation, re-key, modification, revocation requests, actions taken, and status-service changes - Archival integrity: confidentiality, integrity controls, access governance, and retrieval procedures for legal proceedings and conformity assessment - Retention schedule: minimum retention aligned to certificate validity plus at least seven years after cessation where the record supports that certificate lifecycle ## Primary sources - [ETSI EN 319 411-1 V1.5.1 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Primary source for CP and CPS concepts, policy identifiers, lifecycle requirements, revocation and status services, and audit logging and archival expectations. - [ETSI EN 319 403-1 V1.5.1 (Conformity assessment requirements for trust service bodies)](https://www.etsi.org/deliver/etsi_en/319400_319499/31940301/01.05.01_60/en_31940301v010501p.pdf?ref=sorena.io) - Useful to align EN 319 411-1 controls and evidence with how conformity assessment bodies typically test them. - [ETSI Work Item REN/ESI-0019411-1v151](https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?SearchPage=TRUE&WKI_ID=70003&butSimple=Search&curItemNr=5&includeNonActiveTB=FALSE&includeSubProjectCode=&optDisplay=50&qACHIEVED_DAY=1&qACHIEVED_MONTH=2&qACHIEVED_YEAR=2024&qCLUSTER_BOOLEAN=&qETSI_ALL=&qFREQUENCIES_BOOLEAN=&qINCLUDE_MOVED_ON=&qINCLUDE_SUB_TB=True&qKEYWORD_BOOLEAN=&qMILESTONE=1&qREPORT_TYPE=SUMMARY&qSORT=HIGHVERSION&qSTOPPING_OUTDATED=&qSTOP_FLG=&totalNrItems=34&ref=sorena.io) - Official ETSI work item page showing the current V1.5.1 publication record and schedule metadata. ## Related Topic Guides - [ETSI EN 319 411-1 V1.5.1 Compliance Playbook (CA and TSP Certificate Issuance Operations)](/artifacts/global/etsi-en-319-411-1/compliance.md): How to operationalize ETSI EN 319 411-1 V1.5.1 for certificate issuing Trust Service Providers: CP and CPS governance, repository duties. - [ETSI EN 319 411-1 V1.5.1 FAQ (CP vs CPS, TLS Policies, Revocation, OCSP/CRL)](/artifacts/global/etsi-en-319-411-1/faq.md): Answering real-world questions about ETSI EN 319 411-1 V1.5.1: CP vs CPS, policy families, identity validation, repository duties, revocation. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-411-1/requirements --- --- title: "ETSI EN 319 411-2 V2.6.1 Compliance Playbook (EU Qualified Certificates and QSCD Operations)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-2/compliance" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-2/compliance" author: "Sorena AI" description: "How to operationalize ETSI EN 319 411-2 V2.6.1 for EU qualified certificates: policy OID governance, CP and CPS disclosures, identity verification workflows." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 319 411-2 compliance" - "ETSI EN 319 411-2 V2.6.1" - "EU qualified certificates compliance program" - "qualified trust service provider" - "QCP-n QCP-l QCP-qscd" - "QEVCP-w QNCP-w QNCP-w-gen" - "QSCD operations" - "sole control key management" - "identity verification natural person legal person" - "domain-link verification" - "qualified certificate policy OID" - "PKI disclosure statement qualified" - "audit evidence eIDAS" - "EU trusted list validation" - "EU qualified certificates" - "Identity verification" - "Evidence pack" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 411-2 V2.6.1 Compliance Playbook (EU Qualified Certificates and QSCD Operations) How to operationalize ETSI EN 319 411-2 V2.6.1 for EU qualified certificates: policy OID governance, CP and CPS disclosures, identity verification workflows. *Artifact Guide* *GLOBAL* ## ETSI EN 319 411-2 Compliance A compliance playbook for qualified certificate issuance that produces defensible evidence by default. Focus: current-edition policy OIDs, identity verification, QSCD boundaries, trusted-list operations, and operational proof for audits and supervisory reviews. Qualified certificate programs succeed when they treat policy identifiers and QSCD requirements as engineering constraints, not paperwork. EN 319 411-2 V2.6.1 adds qualified-specific requirements on top of EN 319 411-1 and ties them to eIDAS expectations. This page explains how to run EN 319 411-2 as an operating system: documentation, workflows, controls, trusted-list proof, monitoring, and evidence. ## 1) Start with policy strategy because the asserted OID defines the proof burden The qualified policy identifier you include in a certificate communicates assurance properties to relying parties. It also determines which requirement sets apply and what evidence you need to retain. Treat policy selection as a governance decision with documented rationale, clear service scope, and an owner who keeps CP, CPS, profile settings, and issuance operations synchronized. - Choose policies: QCP-n and QCP-l, QSCD variants, and qualified website-authentication policies such as QEVCP-w and QNCP-w - Define which customer segments and use cases map to each policy OID - Maintain a versioned mapping from policy OID to requirements, controls, and evidence ## 2) Build the qualified-documentation and repository program EN 319 411-2 requires policy documentation to say clearly that it is for EU qualified certificates and whether QSCD use is required. It also expects PKI disclosure support and builds on the publication and repository responsibilities inherited from EN 319 411-1. This is a common failure mode: documents exist, but they do not clearly communicate qualified status, QSCD expectations, or which version was in force when a certificate was issued. - CP: explicit EU-qualified statement plus explicit QSCD requirement statement where applicable - CPS: operational reality for identity verification, issuance, key boundaries, status services, and trusted-list interactions - Repository: stable URLs, version history, and change notices for relying parties and assessors ## 3) Identity verification workflows must produce reusable evidence EN 319 411-2 adds qualified identity-verification rules for natural persons and legal persons, and it defines a choice rule for qualified website-authentication policies depending on whether the subscriber is a natural or legal person. The compliance requirement is not just to verify identity. It is to be able to demonstrate that identity verification was performed correctly, with traceable evidence and approval records. - Natural-person qualified certificates: verification steps and retained evidence for the person and relevant attributes - Legal-person qualified certificates: verification steps and retained evidence for the entity and relevant attributes - Website authentication: verify subscriber identity and link to the domain name, then preserve the evidence path ## 4) QSCD boundaries need an explicit operating model QSCD-related policies require strong key-control boundaries. EN 319 411-2 includes conditional requirements for cases where the TSP manages the QSCD for the subject, and it pushes obligations into subscriber obligations when the subscriber or subject maintains the private key. Your assessment story must be consistent: who has control, what operations occur, what device or module is in scope, and what evidence proves that signing stays inside the permitted QSCD boundary. - Define the responsibility model: subject-controlled QSCD or TSP-managed QSCD - Enforce QSCD-only signing where required and log the enforcement evidence - Document sole-control or subject-control semantics and implement checks for violations or exceptions ## 5) Trusted-list operations are part of the compliance story Qualified status has to be externally verifiable. EN 319 411-2 points to the trusted-list ecosystem, including ETSI TS 119 612, ETSI TS 119 615, and ETSI TS 119 172-4, because relying parties validate qualified status against those materials. A mature qualified program knows exactly how each service maps to trusted-list entries, how relying parties validate that mapping, and how support teams explain it during customer due-diligence reviews. - Map each service and certificate type to the correct trusted-list entry and service digital identifier - Test certificate validation against EU trusted lists and keep evidence of the validation path - Coordinate trusted-list operations with CP, CPS, certificate-profile, and customer-support teams *Recommended next step* *Placement: after the compliance steps* ## Turn ETSI EN 319 411-2 Compliance into an operational assessment Assessment Autopilot can take ETSI EN 319 411-2 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on ETSI EN 319 411-2 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ETSI EN 319 411-2 Compliance](/solutions/assessment.md): Start from ETSI EN 319 411-2 Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ETSI EN 319 411-2](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 319 411-2 Compliance. ## 6) Revocation and status services still need relying-party-grade proof EN 319 411-2 inherits the EN 319 411-1 lifecycle and status-service expectations and also references status and certificate-profile mechanisms relevant to long-lived validation such as OCSP ArchiveCutOff and expired revoked certificates on CRLs. In practice, auditors and relying parties care about status freshness, availability, interpretation rules, and whether the infrastructure behaved consistently with the qualified policy in force. - Run revocation and online-status services as critical infrastructure with measured freshness and availability - Document any ArchiveCutOff or expired-revoked-certificate behavior and make sure profiles, CPS text, and operations match - Retain evidence that status information remained consistent with issuance, suspension, and revocation events ## 7) Manage CA Browser Forum precedence for qualified web policies For certain qualified website-authentication policies, EN 319 411-2 includes a conditional precedence rule: if there is conflict with the latest CA Browser Forum requirements, those CA Browser Forum requirements take precedence. Operationally, this forces a maintenance program. You must track changes, assess impact, implement updates, and refresh CPS and evidence accordingly. - Monitor CA Browser Forum changes relevant to the web-policy OIDs you assert - Maintain documented gap analysis and remediation tracking - Refresh evidence after control changes rather than relying on stale test results ## 8) Build the evidence pack for supervision and conformity assessment The strongest evidence is operational: logs, case records, configuration history, monitored controls, and trusted-list proof generated by your systems. Build an evidence index that links every requirement family to its proof and latest verification results. A qualified program should be able to answer quickly which policy was asserted, why it was appropriate, how identity was verified, how QSCD boundaries were enforced, how qualified status was validated, and how revocation and status services performed. - Policy evidence: OID usage inventory, CP and CPS versions, qualified statements, and repository change history - Identity evidence: verification case records with sources, decisions, and approvals - Qualified-status evidence: trusted-list mappings, validation tests, and profile or QCStatement checks - Lifecycle evidence: issuance, re-key, revocation events, status-service availability, and consistency checks ## Primary sources - [ETSI EN 319 411-2 V2.6.1 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/319400_319499/31941102/02.06.01_60/en_31941102v020601p.pdf?ref=sorena.io) - Primary source for qualified policy identifiers, identity verification rules, QSCD obligations, trusted-list references, and qualified disclosures. - [ETSI EN 319 411-1 V1.5.1](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Baseline CP and CPS and lifecycle requirements incorporated by EN 319 411-2. - [ETSI Work Item REN/ESI-0019411-2v261](https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=72255&ref=sorena.io) - Official ETSI work item page for current-version and publication metadata. - [eIDAS Regulation (EU) No 910/2014 (consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02014R0910-20240520&ref=sorena.io) - Legal framework referenced by EN 319 411-2 for qualified trust services and qualified certificates. ## Related Topic Guides - [ETSI EN 319 411-2 V2.6.1 FAQ (EU Qualified Certificates, QCP, QNCP, QEVCP, QSCD)](/artifacts/global/etsi-en-319-411-2/faq.md): Frequently asked questions about ETSI EN 319 411-2 V2.6.1 for qualified trust service providers: policy OIDs, QSCD requirements, trusted-list validation. - [ETSI EN 319 411-2 V2.6.1 Requirements (EU Qualified Certificates, QCP, QEVCP, QNCP, QSCD)](/artifacts/global/etsi-en-319-411-2/requirements.md): ETSI EN 319 411-2 V2.6.1 requirements map for EU qualified certificates under eIDAS: qualified policy OIDs, identity verification, QSCD obligations. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-411-2/compliance --- --- title: "ETSI EN 319 411-2 V2.6.1 FAQ (EU Qualified Certificates, QCP, QNCP, QEVCP, QSCD)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-2/faq" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-2/faq" author: "Sorena AI" description: "Frequently asked questions about ETSI EN 319 411-2 V2.6.1 for qualified trust service providers: policy OIDs, QSCD requirements, trusted-list validation." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 319 411-2 FAQ" - "ETSI EN 319 411-2 V2.6.1" - "EU qualified certificates" - "QCP-n QCP-l" - "QCP-n-qscd QCP-l-qscd" - "QEVCP-w" - "QNCP-w" - "QNCP-w-gen" - "QSCD requirements" - "sole control meaning" - "qualified website authentication certificate" - "identity verification natural person legal person" - "qualified certificate policy OID" - "PKI disclosure statement qualified" - "EU trusted list validation" - "ETSI TS 119 615" - "eIDAS qualified trust service provider" - "QSCD" - "Policy OIDs" - "eIDAS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 411-2 V2.6.1 FAQ (EU Qualified Certificates, QCP, QNCP, QEVCP, QSCD) Frequently asked questions about ETSI EN 319 411-2 V2.6.1 for qualified trust service providers: policy OIDs, QSCD requirements, trusted-list validation. *Artifact Guide* *GLOBAL* ## ETSI EN 319 411-2 FAQ Fast answers for teams issuing EU qualified certificates under eIDAS. Grounded in ETSI EN 319 411-2 V2.6.1 and the official ETSI publication record for the June 2025 edition. This FAQ focuses on operational decisions: which qualified policy OID to assert, what QSCD changes in key-control boundaries, how identity verification rules work, how qualified status is validated in practice, and what evidence you must keep to survive audits and relying-party scrutiny. ## What is the current edition of ETSI EN 319 411-2? The current official ETSI edition is V2.6.1 with June 2025 cover date. ETSI shows adoption on 3 June 2025 and publication on 6 June 2025 for this work item. This matters because qualified-service assessments and customer due-diligence packs often lag. If your internal mappings still point to older text, your policy assertions and evidence can drift out of sync with the current published standard. - Update internal control matrices, CP and CPS references, and assessment templates to V2.6.1 - Check older guidance for assumptions that predate the latest EN 319 411-1 and eIDAS updates reflected in V2.6.1 ## How is EN 319 411-2 different from EN 319 411-1? ETSI EN 319 411-2 specifies additional requirements for trust service providers issuing EU qualified certificates. It incorporates the general requirements of ETSI EN 319 411-1 and adds qualified-specific rules to align with eIDAS expectations. You need both layers: EN 319 411-1 for baseline CP and CPS and lifecycle operations, and EN 319 411-2 for qualified policy identifiers, QSCD constraints, trusted-list context, and qualified-specific disclosures and identity rules. - EN 319 411-1 equals baseline certificate issuance and lifecycle controls - EN 319 411-2 equals qualified-certificate deltas such as policy OIDs, QSCD obligations, and qualified disclosures ## Does conformance to EN 319 411-2 automatically mean our service is qualified under eIDAS? No. EN 319 411-2 conformance is important, but qualified status is a regulatory condition that also depends on conformity assessment, supervisory treatment, and the relevant trusted-list publication. In practice, you need both standard-conformance evidence and qualified-status evidence. Customers and relying parties often need the second one more urgently than the first. - Do not collapse standard conformance and regulatory qualification into the same claim - Prepare evidence for both assessment and trusted-list validation paths ## Which qualified certificate policy OIDs can we assert? EN 319 411-2 defines qualified certificate policy identifiers such as QCP-n, QCP-l, their QSCD variants, and qualified website-authentication policies such as QEVCP-w, QNCP-w, and QNCP-w-gen. Pick the policy based on what you are issuing, who the subscriber is, whether QSCD use is required, and what you can actually operate and prove. - QCP-n and QCP-l for natural-person and legal-person qualified certificates - QCP-n-qscd and QCP-l-qscd when the certified key is related to a QSCD - QEVCP-w, QNCP-w, and QNCP-w-gen for qualified website-authentication contexts ## When is QSCD required and what changes operationally? QSCD-related policies change key-control boundaries. EN 319 411-2 includes constraints such as preventing signing outside a QSCD and enforcing the required subject-control semantics for the asserted policy. Operationally, QSCD changes your threat model and your evidence. You must prove where the key lives, how it is used, and how the control boundary is enforced. - Define the responsibility model: subject-controlled QSCD or TSP-managed QSCD - Enforce QSCD-only signing and keep logs or attestations proving enforcement - Document obligations in subscriber terms or TSP obligations depending on who manages the QSCD ## How does identity verification differ for natural persons, legal persons, and websites? EN 319 411-2 adds identity-verification rules in REG-6.2.2. It distinguishes natural-person and legal-person identity verification and adds a choice rule for qualified website-authentication policies based on subscriber type. The audit requirement is evidence. You must be able to demonstrate what checks were performed, which sources were used, and why they were sufficient for the asserted policy. - QCP-n and QCP-n-qscd: verify the natural person and relevant attributes where applicable - QCP-l and QCP-l-qscd: verify the legal person and relevant attributes where applicable - Qualified website authentication: verify subscriber identity and the subscriber link to the domain name ## How do relying parties know we are really qualified? Relying parties do not rely only on CP and CPS language or marketing claims. The EN 319 411-2 reference set points to the EU trusted-list ecosystem and related validation specifications because qualified status is validated through those channels. That means your support and assurance teams should be ready to explain the trusted-list path, the relevant service digital identifier, and how certificate validation against trusted lists works in practice. - Map each qualified service to the correct trusted-list entry - Be ready to explain how trusted-list validation works for customers and assessors ## Do we need special qualified disclosures in CP and CPS? Yes. EN 319 411-2 requires the certificate policy to clearly state it is for EU qualified certificates and whether it requires QSCD use. It also requires PKI disclosure support and relies on certificate-profile material that expresses qualified semantics in certificates. Relying parties and auditors should not have to guess whether a policy is qualified, whether QSCD is required, or whether the certificate profile actually matches the claim. - Add explicit EU-qualified and QSCD statements and keep them consistent across documentation and certificate profiles - Publish disclosure documents with stable URLs, version dates, and change history ## What if CA Browser Forum requirements conflict with EN 319 411-2 web policies? EN 319 411-2 includes a conditional precedence rule for certain qualified website-authentication policies: if there is conflict with the latest CA Browser Forum requirements, those CA Browser Forum requirements take precedence. This means you need a maintenance program that tracks changes, runs gap assessments, updates controls, and refreshes evidence. - Track CA Browser Forum changes relevant to the web-policy OIDs you assert - Keep evidence of gap analysis, remediation decisions, and updated tests *Recommended next step* *Placement: after the FAQ section* ## Use ETSI EN 319 411-2 FAQ as a cited research workflow Research Copilot can take ETSI EN 319 411-2 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on ETSI EN 319 411-2 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ETSI EN 319 411-2 FAQ](/solutions/research-copilot.md): Start from ETSI EN 319 411-2 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ETSI EN 319 411-2](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 319 411-2 FAQ. ## Primary sources - [ETSI EN 319 411-2 V2.6.1 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/319400_319499/31941102/02.06.01_60/en_31941102v020601p.pdf?ref=sorena.io) - Primary source for qualified policy identifiers, identity-verification rules, QSCD obligations, trusted-list references, and qualified disclosures. - [ETSI Work Item REN/ESI-0019411-2v261](https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=72255&ref=sorena.io) - Official ETSI work item page confirming the current V2.6.1 publication record. - [ETSI EN 319 411-1 V1.5.1](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Baseline requirements incorporated by EN 319 411-2. - [eIDAS Regulation (EU) No 910/2014 (consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02014R0910-20240520&ref=sorena.io) - Legal framework for qualified trust services referenced by EN 319 411-2. ## Related Topic Guides - [ETSI EN 319 411-2 V2.6.1 Compliance Playbook (EU Qualified Certificates and QSCD Operations)](/artifacts/global/etsi-en-319-411-2/compliance.md): How to operationalize ETSI EN 319 411-2 V2.6.1 for EU qualified certificates: policy OID governance, CP and CPS disclosures, identity verification workflows. - [ETSI EN 319 411-2 V2.6.1 Requirements (EU Qualified Certificates, QCP, QEVCP, QNCP, QSCD)](/artifacts/global/etsi-en-319-411-2/requirements.md): ETSI EN 319 411-2 V2.6.1 requirements map for EU qualified certificates under eIDAS: qualified policy OIDs, identity verification, QSCD obligations. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-411-2/faq --- --- title: "ETSI EN 319 411-2 V2.6.1 Requirements (EU Qualified Certificates, QCP, QEVCP, QNCP, QSCD)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-2/requirements" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-2/requirements" author: "Sorena AI" description: "ETSI EN 319 411-2 V2.6.1 requirements map for EU qualified certificates under eIDAS: qualified policy OIDs, identity verification, QSCD obligations." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI EN 319 411-2 requirements" - "ETSI EN 319 411-2 V2.6.1" - "EU qualified certificates" - "qualified trust service provider" - "QCP-n QCP-l" - "QCP-n-qscd QCP-l-qscd" - "QEVCP-w" - "QNCP-w" - "QNCP-w-gen" - "qualified website authentication certificate" - "QSCD requirements" - "sole control" - "subject control" - "qualified electronic signature certificate" - "qualified electronic seal certificate" - "EU trusted list validation" - "ETSI TS 119 615" - "ETSI TS 119 172-4" - "qcStatements" - "certificate policy identifier OID" - "identity verification natural person legal person domain link" - "QSCD" - "eIDAS" - "Certificate policy OIDs" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 411-2 V2.6.1 Requirements (EU Qualified Certificates, QCP, QEVCP, QNCP, QSCD) ETSI EN 319 411-2 V2.6.1 requirements map for EU qualified certificates under eIDAS: qualified policy OIDs, identity verification, QSCD obligations. *Artifact Guide* *GLOBAL* ## ETSI EN 319 411-2 Requirements A practical requirements map for issuing EU qualified certificates under eIDAS. Focus: current V2.6.1 policy OIDs, identity verification rules, QSCD obligations, trusted-list validation, and audit-ready evidence for relying parties and supervisory scrutiny. ETSI EN 319 411-2 V2.6.1 builds on ETSI EN 319 411-1 and adds requirements to support EU qualified certificates under eIDAS. The operational trick is to treat the qualified policy identifier you assert as a contract: it determines what identity checks you must perform, what key-control boundaries you must enforce, how qualified status is signaled, and what you must be able to prove years later. The current edition was adopted on 3 June 2025 and published by ETSI on 6 June 2025. ## 1) What EN 319 411-2 is and what it is not EN 319 411-2 specifies additional requirements for trust service providers issuing EU qualified certificates. It incorporates the general requirements of EN 319 411-1 and adds qualified-specific rules to align with eIDAS expectations. Conformance to EN 319 411-2 alone does not automatically make your service or certificates qualified under eIDAS. Qualification is a regulatory status that also depends on conformity assessment, supervisory treatment, and the relevant trusted-list publication. - Use EN 319 411-2 as the operational baseline for qualified-certificate issuance controls - Keep a clear separation between standard-conformance evidence and regulatory qualification evidence ## 2) Qualified certificate policy identifiers you can assert EN 319 411-2 defines EU qualified certificate policy identifiers that can be included in certificates. Including one of these identifiers indicates the certificate is issued and managed according to EN 319 411-2 for that policy. Treat this as relying-party semantics. The policy identifier is used to determine suitability and trustworthiness in an eIDAS context, so CP, CPS, certificate profiles, and subscriber obligations all have to match the asserted OID. - QCP-n: EU qualified certificates issued to natural persons - QCP-l: EU qualified certificates issued to legal persons - QCP-n-qscd and QCP-l-qscd: qualified certificates where the private key is related to the certified public key in a QSCD - QEVCP-w, QNCP-w, and QNCP-w-gen: qualified website authentication certificate policies - Document which OIDs you assert, where they appear, and how relying parties find interpretation guidance ## 3) Requirement inheritance from EN 319 411-1 A large portion of EN 319 411-2 is composition. It says certain requirement sets in EN 319 411-1 apply, and then adds qualified-specific constraints. That means your compliance mapping has to include both documents, not one or the other. In practice, build a two-layer mapping so assessors can follow policy choice, inherited baseline requirements, and the qualified deltas without guessing. - Build a two-layer mapping: EN 319 411-2 policy choice to applicable EN 319 411-1 requirement sets to qualified deltas - Store evidence links in one place so inheritance is reviewable and not trapped in tribal knowledge *Recommended next step* *Placement: after the requirement breakdown* ## Turn ETSI EN 319 411-2 Requirements into an operational assessment Assessment Autopilot can take ETSI EN 319 411-2 Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on ETSI EN 319 411-2 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ETSI EN 319 411-2 Requirements](/solutions/assessment.md): Start from ETSI EN 319 411-2 Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ETSI EN 319 411-2](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 319 411-2 Requirements. ## 4) Identity verification rules: natural persons, legal persons, and websites EN 319 411-2 adds qualified identity-verification requirements. It distinguishes natural-person and legal-person verification and provides a choice-based rule for qualified website-authentication policies depending on subscriber type. Treat identity verification as a system that produces evidence. The output is not only a passed check but a reproducible record of sources used, checks performed, and who approved the decision. - QCP-n and QCP-n-qscd: verify identity of the natural person and relevant attributes where applicable - QCP-l and QCP-l-qscd: verify identity of the legal person and relevant attributes where applicable - QEVCP-w, QNCP-w, and QNCP-w-gen: verify subscriber identity and the subscriber link to the domain name using the right natural-person or legal-person path ## 5) QSCD obligations and key-control boundaries Qualified certificates with QSCD requirements introduce a hard boundary: the private key cannot be used for signing except within a QSCD, and the private key has to stay under the required subject-control model for the asserted policy. EN 319 411-2 also pushes obligations into subscriber obligations or TSP obligations when the TSP manages QSCD on behalf of the subject. Your documentation has to make those control flows explicit. - If the TSP manages the QSCD, private-key use stays restricted to QSCD operation and the control model still has to be provable - Subscriber obligations should require QSCD use where the asserted policy demands it - Define who controls the key, what operations are allowed, and what evidence proves QSCD-only signing ## 6) Qualified disclosures, certificate profiles, and QCStatements EN 319 411-2 requires the certificate policy to include a clear statement that the policy is for EU qualified certificates and whether it requires use of a QSCD. It also requires a PKI disclosure statement and relies on the ETSI certificate-profile stack, including QCStatements, to express qualified semantics in certificates. Do not let CP, CPS, PKI disclosure text, certificate-profile configuration, and actual certificates diverge. Relying parties and assessors will compare them. - Add explicit EU-qualified language and explicit QSCD statements to policy documentation - Keep CP, CPS, subscriber terms, PKI disclosure content, and certificate-profile settings synchronized - Verify that QCStatements and profile elements support the qualified assertions you make ## 7) Trusted-list validation and qualified-status proof Relying parties do not infer qualified status from marketing text. They validate against EU trusted lists and related profile material. The EN 319 411-2 reference set explicitly points to trusted-list and validation specifications such as ETSI TS 119 612, ETSI TS 119 615, and ETSI TS 119 172-4. Operationally, this means your evidence pack needs to show how your service is represented, how certificate validation against trusted lists works, and how you explain that validation path to relying parties and customers. - Map each qualified service to the correct trusted-list entry and service digital identifier - Test relying-party validation paths using the relevant trusted-list and validation specifications - Keep customer and auditor guidance for how qualified status is validated, not just how it is claimed ## 8) Revocation and status services for qualified certificates Qualified programs still inherit the EN 319 411-1 lifecycle and status-service expectations, but EN 319 411-2 also points directly to RFC 6960 and X.509 mechanisms relevant to long-lived relying-party validation. If you keep expired revoked certificates on CRLs or use OCSP ArchiveCutOff handling, document the behavior clearly and make sure the profile, CPS, and status infrastructure all tell the same story. - Run revocation and online-status services as critical infrastructure with monitored freshness and availability - Document any use of OCSP ArchiveCutOff or expired-revoked-certificate handling so relying parties can interpret status correctly - Retain evidence that shows status information remained consistent with the certificate lifecycle and qualified policy in force ## 9) CAB Forum conflict rule for web policies For qualified website-authentication policies, EN 319 411-2 includes a conditional conflict rule: if there is conflict between EN 319 411-2 requirements and the latest relevant CA Browser Forum requirements, the CA Browser Forum requirements take precedence. Operationally, you need a change-tracking process. You cannot freeze controls to a single version and assume continuing compliance for QNCP-w or QEVCP-w operations. - Track CA Browser Forum requirement updates relevant to the web-policy OIDs you assert - Maintain a remediation process with evidence from gap analysis through change validation and CPS updates ## Primary sources - [ETSI EN 319 411-2 V2.6.1 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/319400_319499/31941102/02.06.01_60/en_31941102v020601p.pdf?ref=sorena.io) - Primary source for qualified policy identifiers, identity verification rules, QSCD obligations, trusted-list references, and qualified disclosure requirements. - [ETSI EN 319 411-1 V1.5.1](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Baseline lifecycle and CP and CPS framework incorporated by EN 319 411-2. - [ETSI Work Item REN/ESI-0019411-2v261](https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=72255&ref=sorena.io) - Official ETSI work item page for the current V2.6.1 publication record and schedule metadata. - [eIDAS Regulation (EU) No 910/2014 (consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02014R0910-20240520&ref=sorena.io) - Legal framework for qualified certificates and qualified trust service providers referenced by EN 319 411-2. ## Related Topic Guides - [ETSI EN 319 411-2 V2.6.1 Compliance Playbook (EU Qualified Certificates and QSCD Operations)](/artifacts/global/etsi-en-319-411-2/compliance.md): How to operationalize ETSI EN 319 411-2 V2.6.1 for EU qualified certificates: policy OID governance, CP and CPS disclosures, identity verification workflows. - [ETSI EN 319 411-2 V2.6.1 FAQ (EU Qualified Certificates, QCP, QNCP, QEVCP, QSCD)](/artifacts/global/etsi-en-319-411-2/faq.md): Frequently asked questions about ETSI EN 319 411-2 V2.6.1 for qualified trust service providers: policy OIDs, QSCD requirements, trusted-list validation. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-411-2/requirements --- --- title: "Choose the Right ETSI Standard (EN 303 645 V3.1.3, TS 103 701, EN 319 401, EN 319 411)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-standards-hub/choose-the-right-etsi-standard" source_url: "https://www.sorena.io/artifacts/global/etsi-standards-hub/choose-the-right-etsi-standard" author: "Sorena AI" description: "A practical decision guide to choose the right ETSI cybersecurity standard by product versus service scope and assurance objective." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "choose the right ETSI standard" - "ETSI standards hub" - "ETSI cybersecurity standards" - "ETSI EN 303 645 V3.1.3" - "ETSI TS 103 701 V2.1.1" - "ETSI EN 319 401 V3.1.1" - "ETSI EN 319 411-1 V1.5.1" - "ETSI EN 319 411-2 V2.6.1" - "ETSI evidence pack" - "ETSI selection guide" - "ETSI standards" - "ETSI EN 303 645" - "ETSI TS 103 701" - "ETSI EN 319 401" - "ETSI EN 319 411" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Choose the Right ETSI Standard (EN 303 645 V3.1.3, TS 103 701, EN 319 401, EN 319 411) A practical decision guide to choose the right ETSI cybersecurity standard by product versus service scope and assurance objective. *Decision guide* *GLOBAL* ## ETSI Standards Hub Choose the right ETSI standard A practical decision tree in text: pick the ETSI standard that matches your product or trust service, then plan controls, tests, and evidence. This guide pins the current ETSI editions and uses object-of-assurance logic so teams do not choose the wrong standard or the wrong version. If you start with the wrong ETSI standard or the wrong ETSI edition, you usually end up with the wrong evidence. Use this page to choose the right ETSI cybersecurity standard by what you are building and what you need to prove, then pin the exact edition before implementation starts. ## Fast path: match your use case to the right current ETSI document Start by selecting the correct object of conformity: a consumer IoT product, a trust service provider, or a certificate issuance service. Then choose the ETSI document that directly targets that object. If your goal is independent assessment, choose both the baseline and the assessment method where ETSI separates them. - Consumer IoT product security baseline: ETSI EN 303 645 V3.1.3 - Consumer IoT assessment and test scenarios: ETSI TS 103 701 V2.1.1 - Trust Service Provider general policy and operational requirements: ETSI EN 319 401 V3.1.1 - Certificate policy requirements in general issuance contexts: ETSI EN 319 411-1 V1.5.1 - Qualified certificate policy and qualified certificate issuance: ETSI EN 319 411-2 V2.6.1 ## Step 1: define the object you need to assure ETSI documents are intentionally specific. You get faster clarity when you write the scope in one sentence and keep it consistent across engineering, security, legal, and assurance teams. For consumer IoT, scope usually means device, companion app, and backend services required for security functions such as updates, vulnerability reporting, authentication, and telemetry. For trust services, scope usually means the TSP organization, its policies and practices, and the service processes and security controls that make the trust service reliable and auditable. - Name the thing you must secure: device family, platform, service, or certificate issuance function - List the security-relevant interfaces and dependencies - Define responsibility boundaries between your team and third parties - Write the assurance boundary: what will be assessed, by whom, and against which ETSI edition ## Step 2: define what you need to prove Different ETSI documents lead to different evidence styles. Some are outcome-focused baselines you implement and document. Others are assessment specifications designed for repeatable evaluation. For example, TS 103 701 is explicitly the conformance-assessment method for EN 303 645 and sets out the structure, roles, and documentation inputs that make IoT product assessments repeatable. - Self-assurance goal: implement the EN requirements and keep evidence and rationale traceable - Independent assessment goal: plan for test scenarios, verdict logic, and lab-ready inputs - Audit or supervisory goal: ensure policy, logging, incident response, and governance evidence are repeatable and attributable ## Step 3: pin the edition before you build controls Version drift breaks audits. The ETSI stack in this hub spans current publications from 2024 and 2025, and some of the IoT and trust-service documents were revised recently enough that older internal mappings are likely stale. Pin the title, version, and publication date in scope documents, control matrices, and evidence packs before implementation begins. - EN 303 645 V3.1.3 replaces older hub assumptions based on V2.1.1 - TS 103 701 V2.1.1 aligns the assessment method to the newer EN 303 645 edition - EN 319 401 V3.1.1, EN 319 411-1 V1.5.1, and EN 319 411-2 V2.6.1 should be pinned explicitly in trust-service programs ## Common selection mistakes ETSI work goes off the rails when teams choose a document by name recognition instead of by object and assurance outcome. Avoid these predictable mistakes. - Treating EN 303 645 as a test plan instead of a baseline standard and forgetting TS 103 701 when assessment structure is needed - Using TSP policy requirements for product security or product standards for trust-service governance - Mixing qualified and non-qualified certificate-policy expectations without a clear boundary between EN 319 411-1 and EN 319 411-2 - Ignoring version pinning and discovering too late that the evidence pack maps to an older edition *Recommended next step* *Placement: near the end of the main content before related guides* ## Use ETSI Standards Hub Choose the right ETSI standard as a cited research workflow Research Copilot can take ETSI Standards Hub Choose the right ETSI standard from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on ETSI Standards Hub can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ETSI Standards Hub Choose the right ETSI standard](/solutions/research-copilot.md): Start from ETSI Standards Hub Choose the right ETSI standard and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ETSI Standards Hub](/contact.md): Review your current process, evidence gaps, and next steps for ETSI Standards Hub Choose the right ETSI standard. ## Primary sources - [ETSI EN 303 645 V3.1.3 (Baseline Requirements for Consumer IoT)](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf?ref=sorena.io) - Current ETSI EN 303 645 baseline document for consumer IoT security. - [ETSI TS 103 701 V2.1.1 (Conformance Assessment of Baseline Requirements)](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Current ETSI assessment specification aligned to EN 303 645 V3.1.3. - [ETSI EN 319 401 V3.1.1](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Current general policy requirements for trust service providers. - [ETSI EN 319 411-1 V1.5.1](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Current certificate policy requirements for general issuance contexts. - [ETSI EN 319 411-2 V2.6.1](https://www.etsi.org/deliver/etsi_en/319400_319499/31941102/02.06.01_60/en_31941102v020601p.pdf?ref=sorena.io) - Current qualified certificate policy and qualified certificate issuance requirements. - [ETSI Consumer IoT technologies page](https://www.etsi.org/newsroom/news/11-technologies-clusters/technologies?ref=sorena.io) - Official ETSI page summarizing the current EN 303 645, TS 103 701, and related implementation flow. ## Related Topic Guides - [ETSI Standards FAQ (Current EN 303 645, TS 103 701, EN 319 401, EN 319 411)](/artifacts/global/etsi-standards-hub/faq.md): ETSI standards FAQ for security, product, and assurance teams: current ETSI editions, how EN 303 645 and TS 103 701 relate, what EN 319 401 covers. - [ETSI vs ISO for Cybersecurity Standards: When to Use Each](/artifacts/global/etsi-standards-hub/etsi-vs-iso.md): ETSI vs ISO explained for cybersecurity and assurance teams using current ETSI examples such as EN 303 645 V3.1.3, TS 103 701 V2.1.1, EN 319 401 V3.1.1. - [What Is Included in ETSI Standards Hub (Current IoT and Trust Services Stack)](/artifacts/global/etsi-standards-hub/what-is-included.md): A coverage map of the ETSI cybersecurity standards included in this hub using current editions: EN 303 645 V3.1.3, TS 103 701 V2.1.1, EN 319 401 V3.1.1. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-standards-hub/choose-the-right-etsi-standard --- --- title: "ETSI vs ISO for Cybersecurity Standards: When to Use Each" canonical_url: "https://www.sorena.io/artifacts/global/etsi-standards-hub/etsi-vs-iso" source_url: "https://www.sorena.io/artifacts/global/etsi-standards-hub/etsi-vs-iso" author: "Sorena AI" description: "ETSI vs ISO explained for cybersecurity and assurance teams using current ETSI examples such as EN 303 645 V3.1.3, TS 103 701 V2.1.1, EN 319 401 V3.1.1." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI vs ISO" - "ETSI standards hub" - "ETSI cybersecurity standards" - "ISO cybersecurity standards" - "ETSI EN 303 645 vs ISO 27001" - "ETSI EN 319 401 vs ISO 27001" - "trust service provider ISO mapping" - "consumer IoT security ISO mapping" - "audit readiness ETSI ISO" - "ETSI standards" - "ISO standards" - "ETSI EN 303 645" - "ETSI EN 319 401" - "ISO/IEC 27001" - "ISO/IEC 27002" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI vs ISO for Cybersecurity Standards: When to Use Each ETSI vs ISO explained for cybersecurity and assurance teams using current ETSI examples such as EN 303 645 V3.1.3, TS 103 701 V2.1.1, EN 319 401 V3.1.1. *Comparison guide* *GLOBAL* ## ETSI Standards Hub ETSI vs ISO ETSI is usually a "what this product/service must do" standard; ISO is usually "how your security management system operates". In practice, strong assurance programs use both: ISO as the management-system backbone and ETSI as the product or service-specific assurance layer. People compare ETSI vs ISO as if one replaces the other. For cybersecurity, that mental model is usually wrong. ETSI and ISO often solve different problems: ETSI standards can be highly targeted to a product or trust service assurance context, while ISO standards often define management systems, control objectives, and organizational governance. The best implementation is typically additive: ISO gives you the operating system; ETSI gives you the service/product specification and audit questions. ## ETSI vs ISO in one page (the practical difference) ETSI standards are frequently written to be applied to a specific object with a concrete assurance target such as a consumer IoT product, a trust service provider, or a certificate-issuance service. ISO standards more often provide cross-domain management and governance patterns that can be applied across many organizations and services. If your stakeholders are asking what exactly must this product or service do, ETSI is usually closer to the answer. If they are asking how we run security consistently through governance, internal audit, and continual improvement, ISO is usually closer to the answer. - ETSI example: EN 303 645 V3.1.3 baseline requirements and TS 103 701 V2.1.1 assessment method for consumer IoT - ETSI example: EN 319 401 V3.1.1 and EN 319 411-1 and EN 319 411-2 for trust-service and certificate-issuance assurance - ISO example: ISO 27001 for ISMS governance and ISO 27002 for a reusable control catalogue *Recommended next step* *Placement: after the comparison section* ## Use ETSI Standards Hub ETSI vs ISO as a cited research workflow Research Copilot can take ETSI Standards Hub ETSI vs ISO from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on ETSI Standards Hub can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ETSI Standards Hub ETSI vs ISO](/solutions/research-copilot.md): Start from ETSI Standards Hub ETSI vs ISO and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ETSI Standards Hub](/contact.md): Review your current process, evidence gaps, and next steps for ETSI Standards Hub ETSI vs ISO. ## When ETSI should be your primary reference Use ETSI as the primary anchor when your assurance target is a specific ETSI-defined object. In that case, your audit questions, evidence style, and test expectations are usually shaped by the ETSI clauses and annexes. For example, ETSI EN 303 645 consolidates outcome-focused consumer IoT security and data protection provisions (vulnerability reporting, software updates, secure communications, attack surface reduction, software integrity, resilience, telemetry, user data deletion). ETSI EN 319 401 is structured around policy requirements and operational security for Trust Service Providers, including risk assessment, policies/practices, organizational reliability, segregation of duties, and incident management with monitoring and logging. - Your buyer or scheme references a specific ETSI EN/TS by name and version - You need clause-level traceability for product security or trust service operations - The evidence must map to ETSI requirements, not only to generic security controls ## When ISO should be your primary reference Use ISO as the primary anchor when the goal is to establish an organization-wide security management system with repeatable governance, risk management, internal audit, management review, and continual improvement. ISO is especially valuable when you need consistency across multiple products and services, or when customers and procurement require a recognizable management-system certification baseline. - You need a security management system (ISMS) backbone and governance cadence - You need a universal control catalogue to structure policies, procedures, and audits - You want a cross-product evidence system that can be reused and sampled ## How to combine ETSI and ISO (integration patterns that work) The most useful pattern is to use ISO to define the system, including risk, governance, internal audit, training, and improvement, and ETSI to define the service or product-specific requirements, tests, and assurance outputs. For example, an IoT team can use ISO governance to keep product-security evidence current while EN 303 645 and TS 103 701 define the baseline and the assessment method. A trust-service team can use ISO governance to support EN 319 401 and EN 319 411-series evidence without pretending ISO alone answers qualified-certificate or trusted-list questions. - ISO as the "policy and control framework"; ETSI as the "service/product evidence specification" - One evidence pack, two views: an ISO control view and an ETSI clause/test scenario view - Use ISO governance (internal audit, management review) to keep ETSI evidence current and attributable - Define a single terminology and RACI so ETSI technical owners and ISO governance owners do not drift apart ## Evidence strategy: make audits predictable Audit pain is usually evidence pain: missing traceability, stale artifacts, or unclear ownership. Whether your external assessor focuses on ETSI clauses or ISO controls, you win by structuring evidence around stable IDs, ownership, and review cadence. If you have to choose one thing to do today: create a mapping sheet with rows for ETSI requirements (or test scenarios) and columns for the ISO control(s) that keep each requirement operating over time, plus the concrete evidence artifacts your teams can reliably produce. - Traceability: ETSI clause -> control -> test/verification -> evidence artifact - Attribution: owner, approver, date, and scope/version pinned for every evidence item - Freshness: review cadence and triggers (release, incident, supplier change) to keep evidence current - Reusability: the same evidence artifact should serve multiple audits whenever possible ## Primary sources - [ETSI EN 303 645 V3.1.3](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf?ref=sorena.io) - Current ETSI example of a product-focused baseline. - [ETSI EN 319 401 V3.1.1](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Current ETSI example of a service-focused trust-services standard. - [ISO official standards catalogue](https://www.iso.org/standards.html) - Official ISO source for ISO standards and management-system references. - [eIDAS Regulation (EU) No 910/2014 (consolidated)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02014R0910-20240520&ref=sorena.io) - Useful where ETSI trust-service standards are being compared with regulatory obligations. ## Related Topic Guides - [Choose the Right ETSI Standard (EN 303 645 V3.1.3, TS 103 701, EN 319 401, EN 319 411)](/artifacts/global/etsi-standards-hub/choose-the-right-etsi-standard.md): A practical decision guide to choose the right ETSI cybersecurity standard by product versus service scope and assurance objective. - [ETSI Standards FAQ (Current EN 303 645, TS 103 701, EN 319 401, EN 319 411)](/artifacts/global/etsi-standards-hub/faq.md): ETSI standards FAQ for security, product, and assurance teams: current ETSI editions, how EN 303 645 and TS 103 701 relate, what EN 319 401 covers. - [What Is Included in ETSI Standards Hub (Current IoT and Trust Services Stack)](/artifacts/global/etsi-standards-hub/what-is-included.md): A coverage map of the ETSI cybersecurity standards included in this hub using current editions: EN 303 645 V3.1.3, TS 103 701 V2.1.1, EN 319 401 V3.1.1. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-standards-hub/etsi-vs-iso --- --- title: "ETSI Standards FAQ (Current EN 303 645, TS 103 701, EN 319 401, EN 319 411)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-standards-hub/faq" source_url: "https://www.sorena.io/artifacts/global/etsi-standards-hub/faq" author: "Sorena AI" description: "ETSI standards FAQ for security, product, and assurance teams: current ETSI editions, how EN 303 645 and TS 103 701 relate, what EN 319 401 covers." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ETSI standards FAQ" - "ETSI EN 303 645 FAQ" - "ETSI TS 103 701 FAQ" - "ETSI EN 319 401 FAQ" - "ETSI EN 319 411-1 vs 319 411-2" - "ETSI trust service provider requirements" - "ETSI qualified certificates" - "ETSI audit evidence" - "ETSI compliance checklist" - "ETSI FAQ" - "ETSI standards" - "ETSI EN 303 645" - "ETSI TS 103 701" - "ETSI EN 319 401" - "ETSI EN 319 411" - "Trust services" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI Standards FAQ (Current EN 303 645, TS 103 701, EN 319 401, EN 319 411) ETSI standards FAQ for security, product, and assurance teams: current ETSI editions, how EN 303 645 and TS 103 701 relate, what EN 319 401 covers. *FAQ* *GLOBAL* ## ETSI Standards Hub FAQ Frequently asked questions about ETSI cybersecurity standards, trust services standards, and audit-ready evidence. Grounded in the current ETSI publications linked from this hub and written for teams that need practical selection and evidence guidance. This FAQ focuses on implementation and evidence. It is not legal advice. Validate interpretation against current ETSI primary sources, because version drift is one of the easiest ways to make an ETSI evidence pack unreliable. ## What are the current ETSI editions covered by this hub? The hub is pinned to the current ETSI editions reflected in the linked standard pages: EN 303 645 V3.1.3 for the consumer IoT baseline, TS 103 701 V2.1.1 for the corresponding assessment method, EN 319 401 V3.1.1 for general TSP requirements, EN 319 411-1 V1.5.1 for general certificate issuance, and EN 319 411-2 V2.6.1 for qualified certificate issuance. That matters because older internal guides often still point to EN 303 645 V2.1.1 or earlier trust-service editions. If your control matrix and your cited edition do not match, audit confidence drops immediately. - Pin title, version, and publication date in scope documents and evidence packs - Monitor ETSI milestones or work-item pages for revisions before re-baselining ## Is ETSI a law or a standard? ETSI publishes standards and technical specifications. ETSI documents are not laws by themselves, but they are frequently referenced by laws, schemes, procurement requirements, certification programs, and audits. In practice, ETSI becomes "mandatory" when a regulation, customer, or assurance scheme requires you to follow a specific ETSI EN/TS (often pinned to a version). - Law/regulation: defines legal obligations and enforcement - ETSI standard/spec: defines technical or policy requirements and evidence expectations - Assurance scheme: decides how the standard is assessed and what evidence is acceptable ## Is ETSI EN 303 645 mandatory for IoT products? ETSI EN 303 645 is a baseline requirements standard for consumer IoT cybersecurity and data protection provisions. Whether it is "mandatory" depends on your market and assurance context. Many organizations adopt EN 303 645 as a practical baseline because it provides a consolidated set of outcome-focused requirements that can be translated into product security controls, tests, and evidence. - Treat it as a baseline: integrate into secure development, release gates, and update support policy - Make it auditable: map each requirement to an owner, verification method, and evidence artifact - Use the conformance assessment spec (TS 103 701) when assessment/test-case structure is required ## What is the difference between ETSI EN 303 645 and ETSI TS 103 701? Think of EN 303 645 as the baseline requirements for consumer IoT security outcomes and TS 103 701 as the conformance-assessment method for testing those outcomes in a structured, repeatable way. The current ETSI stack matters here: TS 103 701 V2.1.1 was updated to align the assessment method to EN 303 645 V3.1.3. Using a mismatched pair can invalidate your test assumptions. - EN 303 645: baseline requirements and provisions to implement and evidence - TS 103 701: assessment procedure, test scenarios, documentation inputs (ICS/IXIT), and verdict approach - Use both when you need baseline implementation plus lab-ready, repeatable assessment ## What does ETSI EN 319 401 cover for Trust Service Providers (TSPs)? ETSI EN 319 401 provides general policy requirements for Trust Service Providers relating to electronic signatures and trust infrastructures. It is organized around risk assessment, policies and practices, and TSP management and operation. Operationally, it reads like an audit blueprint: internal organization and reliability, segregation of duties, HR security, asset management, access control, cryptographic controls, physical security, operations and network security, and incident management with monitoring and logging. - Risk assessment and risk treatment approach for trust services - Policy documentation: trust service practice statement, terms and conditions, information security policy - Operational controls: monitoring/logging, incident response, reporting, post-incident review ## When do I need ETSI EN 319 411-1 vs ETSI EN 319 411-2? The EN 319 411 series focuses on certificate policy and certificate issuance expectations. Part 1 covers certificate policy requirements in general issuance contexts. Part 2 covers qualified certificate policy and qualified certificate issuance requirements under the eIDAS-aligned qualified context. If your assurance target involves qualified trust services, qualified certificates, QSCD obligations, and trusted-list validation, Part 2 is usually the right starting point. If you need general certificate-policy requirements outside that qualified context, Part 1 is usually the starting point. - Use EN 319 411-1 for certificate policy requirements (Part 1) when you are not in a qualified context - Use EN 319 411-2 for qualified certificate policy and qualified certificate issuance requirements (Part 2) - Keep your certificate policy boundary explicit: which certificates, which relying parties, which assurance statement ## How does ETSI relate to eIDAS? eIDAS (Regulation (EU) No 910/2014) is the legal framework for electronic identification and trust services in the EU. ETSI trust-service standards commonly include informative mapping and alignment to eIDAS concepts and expectations. In implementation terms, eIDAS defines what the trust service must achieve legally, while ETSI standards help translate that into policy requirements, operational controls, and evidence patterns that can be assessed. - Use eIDAS for legal obligations and definitions - Use ETSI EN 319 401 for TSP policy and operational control expectations - Use EN 319 411 series for certificate policy and certificate issuance requirements ## What evidence is usually expected for ETSI assessments and audits? The most common audit failure is not missing controls - it is missing proof. Evidence must be traceable to requirements, attributable to owners, and current enough to be credible. A good ETSI evidence pack looks like a system: clause-to-control mapping, verification approach, and a set of concrete artifacts (policies, configurations, logs, test reports, training records, drills, corrective actions) with review cadence. - Traceability: ETSI requirement/test scenario -> control -> verification -> evidence artifact - Attribution: owner, approver, scope, and version pinned for each artifact - Freshness: review cadence and triggers (release, incident, supplier change) - Repeatability: evidence is produced the same way every time (not one-off screenshots) ## Can ISO 27001 replace ETSI standards? Usually, no. ISO/IEC 27001 is a management system standard; ETSI standards are often product- or service-specific assurance specifications. They answer different questions. A strong approach is to combine them: ISO 27001/27002 provides the governance and control catalogue that keeps operations consistent, while ETSI provides the clause-level requirements, test scenarios, and assurance expectations for the specific product or trust service. - ISO = governance system and control catalogue - ETSI = domain-specific requirements and assurance questions - Best practice = one evidence pack with both an ISO view and an ETSI clause view ## Do ETSI standards include deadlines or timelines? ETSI standards are not project plans. They do not usually define "your deadline" for compliance. They define requirements, provisions, policy expectations, and (in some cases) assessment/test scenarios. Some ETSI EN documents include publication/adoption/transposition metadata and version change history. Treat that as document lifecycle information, not as your organizational compliance timeline. - Your timeline comes from: regulation/scheme deadlines, contracts, and your release cycle - Use ETSI for requirements and evidence expectations, then build your timeline internally - Pin the ETSI version you are implementing to avoid version drift in audits ## How do we keep up with ETSI revisions and version changes? For audit stability, always pin the ETSI document version in scope and in your evidence pack. Then decide how you will monitor updates and when you will re-baseline your implementation. A practical approach is to monitor ETSI milestones and key work-item pages, run a periodic delta review for standards in scope, and only adopt new versions through a controlled change process that updates the mapping, tests, and evidence pack. - Pin version in scope: title + version + publication date in your evidence pack - Monitor ETSI status/milestones and release notes - Run controlled change: delta mapping -> control/test updates -> evidence refresh *Recommended next step* *Placement: after the FAQ section* ## Use ETSI Standards Hub FAQ as a cited research workflow Research Copilot can take ETSI Standards Hub FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on ETSI Standards Hub can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ETSI Standards Hub FAQ](/solutions/research-copilot.md): Start from ETSI Standards Hub FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ETSI Standards Hub](/contact.md): Review your current process, evidence gaps, and next steps for ETSI Standards Hub FAQ. ## Primary sources - [ETSI EN 303 645 V3.1.3](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf?ref=sorena.io) - Current consumer IoT baseline requirements standard. - [ETSI TS 103 701 V2.1.1](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Current assessment methodology and test scenarios for EN 303 645. - [ETSI EN 319 401 V3.1.1](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Current general policy requirements for trust service providers. - [ETSI EN 319 411-1 V1.5.1](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Current certificate policy requirements for general issuance contexts. - [ETSI EN 319 411-2 V2.6.1](https://www.etsi.org/deliver/etsi_en/319400_319499/31941102/02.06.01_60/en_31941102v020601p.pdf?ref=sorena.io) - Current qualified certificate-policy requirements. - [ETSI milestones](https://www.etsi.org/milestones?ref=sorena.io) - Official ETSI revision and status page for monitoring version changes. ## Related Topic Guides - [Choose the Right ETSI Standard (EN 303 645 V3.1.3, TS 103 701, EN 319 401, EN 319 411)](/artifacts/global/etsi-standards-hub/choose-the-right-etsi-standard.md): A practical decision guide to choose the right ETSI cybersecurity standard by product versus service scope and assurance objective. - [ETSI vs ISO for Cybersecurity Standards: When to Use Each](/artifacts/global/etsi-standards-hub/etsi-vs-iso.md): ETSI vs ISO explained for cybersecurity and assurance teams using current ETSI examples such as EN 303 645 V3.1.3, TS 103 701 V2.1.1, EN 319 401 V3.1.1. - [What Is Included in ETSI Standards Hub (Current IoT and Trust Services Stack)](/artifacts/global/etsi-standards-hub/what-is-included.md): A coverage map of the ETSI cybersecurity standards included in this hub using current editions: EN 303 645 V3.1.3, TS 103 701 V2.1.1, EN 319 401 V3.1.1. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-standards-hub/faq --- --- title: "What Is Included in ETSI Standards Hub (Current IoT and Trust Services Stack)" canonical_url: "https://www.sorena.io/artifacts/global/etsi-standards-hub/what-is-included" source_url: "https://www.sorena.io/artifacts/global/etsi-standards-hub/what-is-included" author: "Sorena AI" description: "A coverage map of the ETSI cybersecurity standards included in this hub using current editions: EN 303 645 V3.1.3, TS 103 701 V2.1.1, EN 319 401 V3.1.1." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "what is included ETSI standards hub" - "ETSI EN 303 645 baseline requirements" - "ETSI TS 103 701 conformance assessment" - "ETSI EN 319 401 trust service provider requirements" - "ETSI EN 319 411 certificate policy requirements" - "ETSI qualified certificates" - "ETSI trust services eIDAS mapping" - "consumer IoT security requirements ETSI" - "ETSI standards hub" - "ETSI EN 303 645" - "ETSI TS 103 701" - "ETSI EN 319 401" - "ETSI EN 319 411" - "Consumer IoT security" - "Trust services" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # What Is Included in ETSI Standards Hub (Current IoT and Trust Services Stack) A coverage map of the ETSI cybersecurity standards included in this hub using current editions: EN 303 645 V3.1.3, TS 103 701 V2.1.1, EN 319 401 V3.1.1. *Coverage map* *GLOBAL* ## ETSI Standards Hub What's included A coverage map of ETSI cybersecurity standards for consumer IoT security and trust-service provider assurance. Use this page to understand what each included ETSI document covers, which edition is current in this hub, and how the pieces fit together. ETSI documents are easiest to implement when you treat them as a system: pick the document that matches the object you need to assure, pin the current edition, then build a clause-to-control-to-evidence mapping so audits become predictable. This page explains what is included in the ETSI Standards Hub and how the current ETSI documents relate to each other. ## Included ETSI standards (and what they are for) This hub focuses on ETSI cybersecurity documents commonly used in consumer IoT product-security programs and trust-service provider programs. Each included ETSI document has a different role: baseline requirements, conformance assessment method, general policy requirements for TSPs, and certificate policy or qualified-certificate requirements. - ETSI EN 303 645 V3.1.3: current baseline cybersecurity and data-protection provisions for consumer IoT devices - ETSI TS 103 701 V2.1.1: current conformance-assessment method and test scenarios for the consumer IoT baseline - ETSI EN 319 401 V3.1.1: current general policy requirements for trust service providers - ETSI EN 319 411-1 V1.5.1: current certificate policy requirements for general issuance contexts - ETSI EN 319 411-2 V2.6.1: current qualified certificate-policy and qualified-certificate issuance requirements *Recommended next step* *Placement: after the scope or definition section* ## Use ETSI Standards Hub What's included as a cited research workflow Research Copilot can take ETSI Standards Hub What's included from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on ETSI Standards Hub can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ETSI Standards Hub What's included](/solutions/research-copilot.md): Start from ETSI Standards Hub What's included and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ETSI Standards Hub](/contact.md): Review your current process, evidence gaps, and next steps for ETSI Standards Hub What's included. ## Consumer IoT security coverage (EN 303 645 + TS 103 701) EN 303 645 is written as an outcome-focused baseline that consolidates widely considered good practice for internet-connected consumer devices into high-level provisions. It addresses both cybersecurity and data-protection considerations for consumer IoT. TS 103 701 complements the baseline by adding the conformance-assessment structure. The current V2.1.1 edition aligns the assessment method to EN 303 645 V3.1.3 and defines the roles, assessment procedure, documentation inputs, verdict logic, and test scenarios that make evaluation repeatable. - Vulnerability handling and reporting process (how reports are received, triaged, and resolved) - Secure update capability and update support policy (how you patch, how long you support) - Credential security and protection of sensitive security parameters - Secure communications and minimized exposed attack surface - Software integrity and protection against unauthorized changes - Personal data protections, telemetry considerations, and user data deletion capability - Resilience to outages and input validation expectations ## Trust services and certificate coverage (EN 319 401 + EN 319 411 series) EN 319 401 sets general policy requirements for trust service providers. In practice, it becomes the audit checklist for whether a trust service is operated securely and consistently. The EN 319 411 series narrows that trust-services scope onto certificate policy and certificate issuance. Use Part 1 for general issuance contexts and Part 2 for qualified certificate policy and qualified certificate issuance, including QSCD and qualified-status concerns. - Risk assessment: how risks are identified, evaluated, and treated in the trust service context - Policies and practices: trust service practice statement, terms and conditions, information security policy - TSP management and operation: organizational reliability, segregation of duties, HR security - Asset management and access control for trust service infrastructure - Cryptographic controls and key material handling governance - Monitoring and logging, incident management, incident response, reporting, and post-incident review ## How to use this hub (workflow that produces usable outputs) Use the hub as a repeatable workflow, not a reading list. Your goal is to produce stable outputs: control definitions, test plans, and evidence artifacts with traceability and ownership. A simple, high-leverage workflow is: (1) choose the ETSI standard by object and assurance objective, (2) map requirements to controls and tests, (3) define an evidence pack that can be kept current, and (4) run governance cycles that keep evidence and controls aligned over time. - Pick the standard: EN 303 645 vs EN 319 401 vs EN 319 411-1/2 (and use TS 103 701 when assessment structure is required) - Create a mapping: ETSI requirement/test scenario -> control -> verification -> evidence artifact - Define evidence freshness: review cadence, release triggers, supplier-change triggers, and incident triggers - Run assurance: internal audit / management review for repeatability; external assessment where required ## What you should be able to produce (evidence outputs) If the hub is working, it produces artifacts that are easy to audit. The most valuable outputs are traceable, attributable, and stable across releases and organizational change. - A clause-to-control matrix (ETSI clause IDs pinned to owners and acceptance criteria) - A test plan that maps to ETSI test scenarios (where applicable) and product/service verification steps - An evidence pack: policies, configurations, logs, test reports, training records, incident drills, corrective actions - A governance cadence: internal audit, management review, and corrective action workflow that keeps evidence current ## Primary sources - [ETSI EN 303 645 V3.1.3](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf?ref=sorena.io) - Current baseline consumer IoT standard used in this hub. - [ETSI TS 103 701 V2.1.1](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Current assessment specification aligned to EN 303 645 V3.1.3. - [ETSI EN 319 401 V3.1.1](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Current general policy requirements for trust service providers. - [ETSI EN 319 411-1 V1.5.1](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Current certificate policy requirements for general issuance. - [ETSI EN 319 411-2 V2.6.1](https://www.etsi.org/deliver/etsi_en/319400_319499/31941102/02.06.01_60/en_31941102v020601p.pdf?ref=sorena.io) - Current qualified certificate-policy requirements. - [ETSI Consumer IoT technologies page](https://www.etsi.org/newsroom/news/11-technologies-clusters/technologies?ref=sorena.io) - Official ETSI page summarizing the current IoT stack and implementation flow. ## Related Topic Guides - [Choose the Right ETSI Standard (EN 303 645 V3.1.3, TS 103 701, EN 319 401, EN 319 411)](/artifacts/global/etsi-standards-hub/choose-the-right-etsi-standard.md): A practical decision guide to choose the right ETSI cybersecurity standard by product versus service scope and assurance objective. - [ETSI Standards FAQ (Current EN 303 645, TS 103 701, EN 319 401, EN 319 411)](/artifacts/global/etsi-standards-hub/faq.md): ETSI standards FAQ for security, product, and assurance teams: current ETSI editions, how EN 303 645 and TS 103 701 relate, what EN 319 401 covers. - [ETSI vs ISO for Cybersecurity Standards: When to Use Each](/artifacts/global/etsi-standards-hub/etsi-vs-iso.md): ETSI vs ISO explained for cybersecurity and assurance teams using current ETSI examples such as EN 303 645 V3.1.3, TS 103 701 V2.1.1, EN 319 401 V3.1.1. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-standards-hub/what-is-included --- --- title: "FIPS 140-3 Compliance (CMVP Validation Playbook, Approved Mode, Transition)" canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3/compliance" source_url: "https://www.sorena.io/artifacts/global/fips-140-3/compliance" author: "Sorena AI" description: "A practical FIPS 140-3 compliance and validation playbook for CMVP cryptographic module validation: boundary, security level selection, approved mode." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "FIPS 140-3 compliance" - "FIPS 140-3 validation" - "CMVP validation playbook" - "cryptographic module validation program" - "NVLAP CSTL" - "FIPS 140-3 approved mode" - "FIPS 140-3 security policy" - "FIPS 140-3 evidence pack" - "FIPS 140-3 documentation requirements" - "FIPS 140-2 transition 2026" - "GLOBAL compliance" - "FIPS 140-3" - "CMVP" - "Cryptographic module validation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FIPS 140-3 Compliance (CMVP Validation Playbook, Approved Mode, Transition) A practical FIPS 140-3 compliance and validation playbook for CMVP cryptographic module validation: boundary, security level selection, approved mode. *Playbook* *GLOBAL* ## FIPS 140-3 Compliance playbook A practical path from scope to CMVP-ready evidence: boundary, approved mode, services mapping, documentation, and lab readiness. Optimized for teams shipping crypto libraries, HSMs, secure elements, firmware, and embedded modules under the current CMVP program rules. FIPS 140-3 compliance is not a document-only exercise. It is an engineering and assurance program: you must define a defensible cryptographic module boundary, implement the required protections, and produce an evidence pack that an accredited CST laboratory can test and the CMVP can validate. This page gives a practical sequence that matches how strong teams actually get through validation. ## What FIPS 140-3 compliance means in practice FIPS PUB 140-3 specifies security requirements for cryptographic modules and defines four increasing, qualitative security levels across 11 requirement areas. In practice, teams use the term compliance in two different ways: a vendor may design to the standard and claim internal compliance, or the team may pursue formal CMVP validation through a CST laboratory and receive a CMVP certificate. That distinction matters because the CMVP FAQ expressly separates a vendor claim of compliance from a validated module. If a certificate does not exist, the module is not CMVP validated, even if the engineering team designed around FIPS 140-3 requirements. - Compliance is a design and evidence target - Validation is the formal CMVP outcome after CSTL testing and CMVP review - Current planning should assume FIPS 140-3, not FIPS 140-2, because FIPS 140-2 active use for new systems ends on 21 September 2026 *Recommended next step* *Placement: after the compliance steps* ## Turn FIPS 140-3 Compliance playbook into an operational assessment Assessment Autopilot can take FIPS 140-3 Compliance playbook from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on FIPS 140-3 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for FIPS 140-3 Compliance playbook](/solutions/assessment.md): Start from FIPS 140-3 Compliance playbook and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through FIPS 140-3](/contact.md): Review your current process, evidence gaps, and next steps for FIPS 140-3 Compliance playbook. ## Step 1: Define the module and freeze the boundary The module boundary is the foundation of the whole project. Interfaces, roles, services, SSP handling, self-tests, physical assumptions, and the Security Policy all depend on that boundary staying stable. If the boundary changes in the middle of lab work, you usually have to rework documentation, test procedures, and sometimes even the selected security level. Treat the boundary as an architecture decision with explicit change control. - Define what code, firmware, hardware, and services are inside the module - List every interface that crosses the boundary, including admin paths, debug paths, and API entry points - Pin the tested operational environments and build identifiers early - Document any embedded or bound modules with exact names, certificate numbers, and versions ## Step 2: Select the right security level and environment assumptions Security levels are not procurement labels. They are assurance decisions tied to real deployment conditions, physical access risk, operator model, and the impact of SSP compromise. Choose the level early because it changes engineering scope, evidence requirements, and lab expectations. A weak level decision usually shows up later as physical-security or operator-control rework. - Level 1 is the baseline entry point for many software modules and lower physical-risk deployments - Level 2 and Level 3 usually demand stronger physical and role-control discipline - Level 4 is for the harshest or least controlled environments and should be justified by actual threat assumptions - Write down the physical and operator assumptions so the level decision survives audit and customer review ## Step 3: Build an approved-mode design that you can prove Approved mode is an operational state, not a slogan. Your services map, approved algorithms, self-tests, SSP protections, and mode indicators all have to support the same approved-mode story. This is where current CMVP program material matters. The base standard is not enough by itself. Teams need the SP 800-140 series, the current Management Manual, and the current Implementation Guidance revision the lab will use. - Define approved mode entry and exit conditions - Map each service to approved security functions or clearly mark it as non-approved - Make service indicators and runtime behavior match the Security Policy - Ensure non-approved functions cannot be mistaken for approved security services ## Step 4: Build the documentation and test-evidence pack the CSTL will use Validation speed depends heavily on documentation quality. The Security Policy, boundary diagrams, service inventory, SSP handling description, self-test behavior, and operational-environment definition must all align with what the CSTL will test. Use version control and stable identifiers across the evidence pack. If the service list in the Security Policy does not match the code, logs, or test scripts, the CSTL will find it quickly and the project will slow down. - Prepare a Security Policy that matches the tested build and tested environments - Version every boundary diagram, service table, and build artifact - Package repeatable test materials, expected outputs, and failure-state evidence - Record the exact CMVP guidance baseline the submission was prepared against ## Step 5: Run the validation as a managed delivery process The practical flow is vendor scope and evidence, CSTL testing, then CMVP review and validation. Teams that treat the submission as an ongoing delivery program do better than teams that treat it as a one-time documentation drop. The current CMVP overview also distinguishes full five-year active validations from two-year interim validations. That matters for roadmap planning, customer messaging, and release governance. - Enter lab work only after the boundary, service map, and Security Policy are stable - Track CSTL questions and evidence deltas in a single controlled backlog - Keep validated version identifiers tied to release management and customer claims - Plan for certificate type, active-list duration, and any interim-validation implications ## Step 6: Protect the validated state after release The post-validation risk is uncontrolled change. Platform updates, compiler changes, dependency changes, and module refactors can break the evidence story even when the feature set looks similar. A practical maintenance model classifies changes, gates releases that affect boundary or approved mode, and keeps the evidence pack current enough that audits and customer reviews stay predictable. - Pin validated versions, environments, and toolchains internally - Run validation-impact review for boundary changes, algorithm changes, SSP changes, and major platform changes - Refresh evidence for self-tests, SSP handling, and lifecycle controls on a defined cadence - Keep marketing and procurement language aligned to the exact validated scope ## Primary sources - [FIPS PUB 140-3 (Security Requirements for Cryptographic Modules)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf?ref=sorena.io) - Primary standard defining the four qualitative levels and 11 requirement areas. - [NIST and CCCS Cryptographic Module Validation Program](https://csrc.nist.gov/projects/cryptographic-module-validation-program?ref=sorena.io) - Official CMVP overview and current transition status. - [CMVP FAQ](https://csrc.nist.gov/projects/cryptographic-module-validation-program/faqs?ref=sorena.io) - Official FAQ covering compliant versus validated claims and embedded-module treatment. - [FIPS 140-3 CMVP Management Manual](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS-140-3-CMVP%20Management%20Manual.pdf?ref=sorena.io) - Current management manual governing submission and maintenance expectations. - [Implementation Guidance for FIPS 140-3 and the CMVP](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Current guidance for issues such as embedding, approved security service indicators, SSP handling, and self-tests. ## Related Topic Guides - [FIPS 140-3 FAQ (CMVP Validation, Approved Mode, Embedded Modules, Transition)](/artifacts/global/fips-140-3/faq.md): FIPS 140-3 FAQ for cryptographic module teams: what FIPS 140-3 covers, how CMVP validation works, what approved mode means. - [FIPS 140-3 Module Boundary and Services Mapping (Approved Mode, Embedded Modules)](/artifacts/global/fips-140-3/module-boundary-and-service-mapping.md): Advanced guide to FIPS 140-3 cryptographic module boundary definition and services mapping: boundary diagrams, approved-mode indicators, SSP access. - [FIPS 140-3 Security Levels (Level 1 to Level 4) Explained](/artifacts/global/fips-140-3/security-levels-explained.md): FIPS 140-3 security levels explained: what Level 1, Level 2, Level 3, and Level 4 mean, how they affect boundary and deployment assumptions. - [FIPS 140-3 Validation Checklist (CMVP Lab Readiness, Approved Mode, Transition)](/artifacts/global/fips-140-3/fips-140-3-validation-checklist.md): A practical FIPS 140-3 validation checklist for CMVP lab readiness: boundary, services, approved mode, documentation, self-tests, SSP management. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-140-3/compliance --- --- title: "FIPS 140-3 FAQ (CMVP Validation, Approved Mode, Embedded Modules, Transition)" canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3/faq" source_url: "https://www.sorena.io/artifacts/global/fips-140-3/faq" author: "Sorena AI" description: "FIPS 140-3 FAQ for cryptographic module teams: what FIPS 140-3 covers, how CMVP validation works, what approved mode means." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "FIPS 140-3 FAQ" - "CMVP FAQ" - "cryptographic module validation FAQ" - "FIPS 140-3 approved mode FAQ" - "FIPS 140-3 Security Policy FAQ" - "FIPS 140-3 maintenance and updates" - "FIPS 140-3 vs 140-2" - "NVLAP CSTL" - "FIPS 140-2 transition 2026" - "FIPS 140 inside" - "GLOBAL compliance" - "FIPS 140-3" - "CMVP" - "FAQ" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FIPS 140-3 FAQ (CMVP Validation, Approved Mode, Embedded Modules, Transition) FIPS 140-3 FAQ for cryptographic module teams: what FIPS 140-3 covers, how CMVP validation works, what approved mode means. *FAQ* *GLOBAL* ## FIPS 140-3 FAQ Common questions about CMVP validation, approved mode, security levels, documentation, and maintenance. Written for engineering, security, and assurance teams building crypto libraries, HSMs, firmware, and embedded modules. This FAQ focuses on implementation and evidence. It is not legal advice. Validate interpretation against NIST and CCCS primary sources and the specific CMVP Implementation Guidance revision you are targeting. ## What is the current CMVP transition state? FIPS 140-3 has been the live CMVP path since submissions opened on 22 September 2020. According to the current CMVP overview page, FIPS 140-2 active modules remain acceptable for new systems only through 21 September 2026. On 22 September 2026, FIPS 140-2 validations move to the Historical list. That does not erase existing deployments, but it does mean new procurement and product planning should center on FIPS 140-3. - Plan new module work around FIPS 140-3 - Check whether your procurement, sales, or contract language still assumes a FIPS 140-2 active listing ## What does FIPS 140-3 cover? FIPS PUB 140-3 specifies security requirements for cryptographic modules and defines four increasing, qualitative security levels. It covers 11 requirement areas including interfaces, roles and services, software or firmware security, operating environment, physical security, non-invasive security, SSP management, self-tests, lifecycle assurance, and mitigation of other attacks. It is the baseline standard that federal agencies use when cryptography must provide actual protection instead of unvalidated plaintext-level assurance. ## What is the difference between compliant and validated? The CMVP FAQ separates these terms clearly. Compliant means a vendor believes its implementation meets the standard. Validated means the module has gone through CSTL testing and CMVP review and has a certificate. If there is no certificate number, do not describe the module as CMVP validated. That distinction matters in procurement language, product pages, and customer attestations. - Compliant is a vendor claim - Validated means independently tested and listed by CMVP ## What is the CMVP and how does validation work? The Cryptographic Module Validation Program is a joint effort between NIST and the Canadian Centre for Cyber Security. Vendors work with independent accredited Cryptographic and Security Testing laboratories, and the CMVP validates the results. Practically, that means the vendor owns the implementation and evidence pack, the CSTL executes test work against the current rules, and the CMVP reviews and issues the certificate. - Vendor builds the module and evidence pack - CSTL performs conformance testing - CMVP validates results and issues the certificate ## What does approved mode of operation mean? Approved mode is an operational claim about how the module behaves. It defines which services are approved, which security functions are approved, whether self-tests have run as required, and how the module signals that approved state. The current guidance treats approved mode as something you prove through implementation, documentation, and tests. If those three views do not match, the approved-mode claim is weak. - Define approved mode entry and exit conditions - Tie every approved service to approved functions, required self-tests, and a stable service identifier - Make sure the Security Policy and runtime indicators match the same story ## How important is the cryptographic module boundary? The boundary is the core scoping decision. It determines what is tested, what the Security Policy must describe, what SSP protections exist, and what services are actually inside the module. Most expensive rework comes from boundary drift. If architecture, documentation, and tests disagree about what is inside the module, the submission becomes unstable fast. ## What is the Security Policy and why does it matter so much? The Security Policy is the public-facing and lab-critical description of the module. It should describe the boundary, interfaces, roles, services, approved mode, SSP handling, self-tests, and operational environment accurately. In strong programs, the Security Policy is not a late-stage writing task. It is a controlled artifact tied directly to the tested build and evidence pack. ## If we use an embedded validated module, is our product also validated? No. The CMVP FAQ is explicit that a product using an embedded validated module cannot claim that the overall product is itself validated solely because it contains that embedded module. The safer claim is that the product uses an embedded validated module. The separate CMVP logo-and-phrases guidance also distinguishes between a validated module and a product containing a validated module. - Do not imply the outer product has its own CMVP certificate unless it actually has one - Keep product marketing and sales language aligned to the certificate scope ## How do we choose the right security level? Choose the level based on real deployment assumptions: physical access risk, operator model, environment control, and the impact of SSP compromise. Higher levels mean stronger proof obligations, not just more marketing value. If you cannot explain why the deployment needs a particular level, the level choice is probably not stable enough for audit or lab review. ## Can we expose non-approved algorithms and still claim approved mode? Sometimes yes, but only if the module keeps those capabilities clearly outside the approved-mode story and the applicable guidance allows that treatment. The dangerous pattern is exposing a cryptographic service that operators can confuse with an approved security function. If a service looks like security to the caller, you should assume the lab will require clean separation, explicit documentation, and unambiguous mode signaling. ## How should we handle release updates after validation? Treat the validated configuration like a controlled product line. Platform changes, compiler changes, dependency changes, and refactors can all affect the evidence story even when the feature set looks unchanged. Set a validation-impact review gate for boundary changes, algorithm changes, SSP changes, and major environment changes so you do not drift away from the certified scope. ## How often should we review Implementation Guidance? Continuously enough that your evidence pack always names the exact revision you implemented against. The local grounding set reflects an Implementation Guidance update dated 27 February 2026, and current CMVP work can turn on guidance details about embedding, service indicators, SSP handling, and self-tests. Treat a guidance revision like a controlled change. Reassess the service map, Security Policy, and tests together instead of updating one artifact at a time. *Recommended next step* *Placement: after the FAQ section* ## Use FIPS 140-3 FAQ as a cited research workflow Research Copilot can take FIPS 140-3 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on FIPS 140-3 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for FIPS 140-3 FAQ](/solutions/research-copilot.md): Start from FIPS 140-3 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through FIPS 140-3](/contact.md): Review your current process, evidence gaps, and next steps for FIPS 140-3 FAQ. ## Primary sources - [FIPS PUB 140-3 (Security Requirements for Cryptographic Modules)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf?ref=sorena.io) - Primary standard defining scope, levels, and requirement areas. - [CMVP FAQ](https://csrc.nist.gov/projects/cryptographic-module-validation-program/faqs?ref=sorena.io) - Official FAQ covering compliant versus validated claims and embedded-module treatment. - [NIST and CCCS CMVP program overview](https://csrc.nist.gov/projects/cryptographic-module-validation-program?ref=sorena.io) - Official CMVP overview with current active-list and transition information. - [Use of FIPS 140-3 or FIPS 140-2 Logo and Phrases](https://csrc.nist.gov/projects/cryptographic-module-validation-program/use-of-fips-140-2-logo-and-phrases?ref=sorena.io) - Official phrasing guidance for validated modules versus products containing embedded validated modules. - [FIPS 140-3 CMVP Management Manual](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS-140-3-CMVP%20Management%20Manual.pdf?ref=sorena.io) - Current management manual for CMVP operational expectations. ## Related Topic Guides - [FIPS 140-3 Compliance (CMVP Validation Playbook, Approved Mode, Transition)](/artifacts/global/fips-140-3/compliance.md): A practical FIPS 140-3 compliance and validation playbook for CMVP cryptographic module validation: boundary, security level selection, approved mode. - [FIPS 140-3 Module Boundary and Services Mapping (Approved Mode, Embedded Modules)](/artifacts/global/fips-140-3/module-boundary-and-service-mapping.md): Advanced guide to FIPS 140-3 cryptographic module boundary definition and services mapping: boundary diagrams, approved-mode indicators, SSP access. - [FIPS 140-3 Security Levels (Level 1 to Level 4) Explained](/artifacts/global/fips-140-3/security-levels-explained.md): FIPS 140-3 security levels explained: what Level 1, Level 2, Level 3, and Level 4 mean, how they affect boundary and deployment assumptions. - [FIPS 140-3 Validation Checklist (CMVP Lab Readiness, Approved Mode, Transition)](/artifacts/global/fips-140-3/fips-140-3-validation-checklist.md): A practical FIPS 140-3 validation checklist for CMVP lab readiness: boundary, services, approved mode, documentation, self-tests, SSP management. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-140-3/faq --- --- title: "FIPS 140-3 Validation Checklist (CMVP Lab Readiness, Approved Mode, Transition)" canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3/fips-140-3-validation-checklist" source_url: "https://www.sorena.io/artifacts/global/fips-140-3/fips-140-3-validation-checklist" author: "Sorena AI" description: "A practical FIPS 140-3 validation checklist for CMVP lab readiness: boundary, services, approved mode, documentation, self-tests, SSP management." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "FIPS 140-3 validation checklist" - "FIPS 140-3 compliance checklist" - "CMVP readiness checklist" - "cryptographic module validation checklist" - "NVLAP CSTL readiness" - "FIPS 140-3 Security Policy checklist" - "approved mode checklist" - "cryptographic module boundary checklist" - "GLOBAL compliance" - "FIPS 140-3" - "CMVP" - "Validation checklist" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FIPS 140-3 Validation Checklist (CMVP Lab Readiness, Approved Mode, Transition) A practical FIPS 140-3 validation checklist for CMVP lab readiness: boundary, services, approved mode, documentation, self-tests, SSP management. *Checklist* *GLOBAL* ## FIPS 140-3 Validation checklist A pre-validation checklist for engineering and CMVP lab readiness, optimized to reduce rework. Use this before you engage a CST laboratory or before you freeze your validation scope. This checklist is designed to catch the usual FIPS 140-3 validation failures early: boundary ambiguity, inconsistent approved-mode claims, incomplete services mapping, weak SSP evidence, and documentation that does not match what is tested. Use it as an internal gate before lab submission, and record the exact CMVP guidance baseline you are using. ## 1) Scope and boundary If the cryptographic boundary is unclear, interfaces, roles, services, SSP handling, self-tests, and documentation all become unstable. Freeze the boundary early and treat scope changes as architecture changes. - Boundary diagram is complete, versioned, and explicit about what is inside and outside the module - All interfaces crossing the boundary are enumerated, including admin paths and debug paths - Operational environments, platforms, firmware, and toolchain assumptions are pinned - Embedded or bound modules are identified with exact certificate and version information - Any remaining FIPS 140-2 dependency or transition assumption is explicitly recorded ## 2) Roles, services, and authentication Your services list is a key input to the lab test plan. Every security-relevant service should be complete, stable, and linked to SSP access and approved-mode behavior. - Roles are clearly defined and least-privilege oriented - Authentication behavior is documented and testable, including reset and replacement flows - Every service includes inputs, outputs, SSP access, approved-mode behavior, and error behavior - There is a reviewed services-to-approved-security-functions map - Non-approved services are clearly identified and cannot be confused with approved services ## 3) Approved mode of operation Approved mode is a proof problem. The implementation, documentation, and tests all need to show the same approved-mode story. - Approved mode entry and exit conditions are explicit and testable - Service indicator behavior is defined and matches runtime behavior - Approved and non-approved algorithms are separated in code paths and docs - The Security Policy, service map, and tests describe the same approved-mode scope - The current CMVP Implementation Guidance revision is named in the evidence pack ## 4) Algorithms and dependencies Teams often fail here by assuming an algorithm is approved without proving validation coverage or dependency control. Keep one authoritative source of truth for algorithm use per build and environment. - Approved security functions are enumerated and tied to concrete implementations - Build flags and configuration controls for cryptographic functions are auditable - Crypto dependencies are pinned and their provenance is recorded - Embedded or bound crypto components are documented precisely where used - Supporting certificates or dependency evidence are retained where the submission relies on them ## 5) Self-tests Self-tests are operational requirements, not theory. They must run in the right state, fail safely, and generate evidence a lab can inspect. - Pre-operational self-tests are implemented and evidenced - Conditional self-tests and error states are documented and tested - Failure behavior blocks cryptographic operation where required - Logs or indicators for self-test status are defined - Self-tests are exercised for each validated build and environment ## 6) SSP management and zeroization Sensitive Security Parameter handling is usually evidence-heavy. Plan the evidence before lab work, not after. - SSP lifecycle is documented from generation or establishment through storage, use, and destruction - Zeroization methods are defined per storage type and are testable - Entropy and SSP-establishment assumptions are documented against the applicable SP 800-140 and IG rules - SSP access is mapped by service and role - Backup and recovery flows do not create shadow SSP stores outside the boundary ## 7) Documentation pack The CSTL works from your documentation. If those artifacts do not line up with implementation reality, the project slows down. - Security Policy matches boundary, services, approved mode, SSP handling, and self-tests - Supporting documents reflect the SP 800-140 documentation and policy expectations the lab is using - Module and interface descriptions match the current code and hardware reality - Configuration-management and release-governance evidence exists for validated builds - Test scripts, configs, logs, and expected outputs are packaged and repeatable ## 8) Post-validation maintenance controls Validation is not the end of the problem. Protect the validated state with strict but lightweight change control. - Validated versions and tested environments are pinned internally - There is a change gate for boundary, algorithm, SSP, and platform changes - Dependency updates are classified for validation impact - Evidence refresh has an owner and cadence - Customer-facing claims are reviewed so validated, compliant, and embedded-module language stays accurate *Recommended next step* *Placement: after the checklist block* ## Turn FIPS 140-3 Validation checklist into an operational assessment Assessment Autopilot can take FIPS 140-3 Validation checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on FIPS 140-3 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for FIPS 140-3 Validation checklist](/solutions/assessment.md): Start from FIPS 140-3 Validation checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through FIPS 140-3](/contact.md): Review your current process, evidence gaps, and next steps for FIPS 140-3 Validation checklist. ## Primary sources - [FIPS PUB 140-3 (Security Requirements for Cryptographic Modules)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf?ref=sorena.io) - Primary standard driving the checklist. - [CMVP FAQ](https://csrc.nist.gov/projects/cryptographic-module-validation-program/faqs?ref=sorena.io) - Useful for checking claims around validated versus compliant status and embedded modules. - [FIPS 140-3 CMVP Management Manual](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS-140-3-CMVP%20Management%20Manual.pdf?ref=sorena.io) - Current operational manual that should inform readiness assumptions and submission planning. - [Implementation Guidance for FIPS 140-3 and the CMVP](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Current guidance set used for readiness decisions; pin the exact revision in your evidence pack. ## Related Topic Guides - [FIPS 140-3 Compliance (CMVP Validation Playbook, Approved Mode, Transition)](/artifacts/global/fips-140-3/compliance.md): A practical FIPS 140-3 compliance and validation playbook for CMVP cryptographic module validation: boundary, security level selection, approved mode. - [FIPS 140-3 FAQ (CMVP Validation, Approved Mode, Embedded Modules, Transition)](/artifacts/global/fips-140-3/faq.md): FIPS 140-3 FAQ for cryptographic module teams: what FIPS 140-3 covers, how CMVP validation works, what approved mode means. - [FIPS 140-3 Module Boundary and Services Mapping (Approved Mode, Embedded Modules)](/artifacts/global/fips-140-3/module-boundary-and-service-mapping.md): Advanced guide to FIPS 140-3 cryptographic module boundary definition and services mapping: boundary diagrams, approved-mode indicators, SSP access. - [FIPS 140-3 Security Levels (Level 1 to Level 4) Explained](/artifacts/global/fips-140-3/security-levels-explained.md): FIPS 140-3 security levels explained: what Level 1, Level 2, Level 3, and Level 4 mean, how they affect boundary and deployment assumptions. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-140-3/fips-140-3-validation-checklist --- --- title: "FIPS 140-3 Module Boundary and Services Mapping (Approved Mode, Embedded Modules)" canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3/module-boundary-and-service-mapping" source_url: "https://www.sorena.io/artifacts/global/fips-140-3/module-boundary-and-service-mapping" author: "Sorena AI" description: "Advanced guide to FIPS 140-3 cryptographic module boundary definition and services mapping: boundary diagrams, approved-mode indicators, SSP access." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "FIPS 140-3 module boundary" - "cryptographic boundary definition" - "FIPS 140-3 services mapping" - "approved mode of operation" - "approved security functions mapping" - "CMVP IG boundary guidance" - "FIPS 140-3 service indicator" - "FIPS 140-3 Security Policy boundary" - "FIPS 140-3 SSP mapping" - "FIPS 140-3" - "Cryptographic boundary" - "Approved mode" - "Services mapping" - "CMVP IG" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FIPS 140-3 Module Boundary and Services Mapping (Approved Mode, Embedded Modules) Advanced guide to FIPS 140-3 cryptographic module boundary definition and services mapping: boundary diagrams, approved-mode indicators, SSP access. *Deep dive* *GLOBAL* ## FIPS 140-3 Module boundary and services mapping Define the cryptographic boundary correctly and build a services map that makes approved mode provable. This is where many CMVP projects succeed or fail: boundary discipline plus service-to-function traceability. In FIPS 140-3, the module boundary and the services map are the backbone of the entire validation. The Security Policy, lab test plan, approved-mode story, SSP handling, self-tests, and operational-environment scope all have to match them. This guide explains how to define the boundary and services in a way that survives CSTL scrutiny and CMVP review. ## Start with the object of conformity FIPS 140-3 validates a cryptographic module. That module may be software, firmware, hardware, or a hybrid, but you must be able to describe exactly what that object is and where its boundary sits. Boundary mistakes are expensive because they force rework across documentation, testing, and release control. Treat boundary definition as an architecture decision with formal ownership. - Define the module embodiment: software, firmware, hardware, or hybrid - Define where approved security functions execute - Define what is explicitly excluded from the module - Pin versions and tested environments so the boundary maps to a specific release ## What a good boundary diagram must show A boundary diagram is not decorative. It is a contract between engineering, documentation, tests, and customer claims. It should be versioned and used consistently everywhere. - Clear perimeter showing in-scope and out-of-scope components - Every interface that crosses the boundary, including APIs, ports, admin channels, and debug paths - Roles and operator entry points - Where SSPs exist in memory, storage, or hardware-backed stores - What happens to module behavior when self-tests fail ## Build a services inventory before you argue about approved mode The services inventory should enumerate every callable service and every security-relevant function the module provides. Each service should have a stable identifier so the mapping remains consistent across code, documentation, and tests. The purpose of the inventory is to eliminate ambiguity. If a service could be interpreted as a security function, the inventory must classify it clearly and explain how it behaves in approved and non-approved states. - Service identifier, name, and short description - Roles allowed to invoke the service - Inputs and outputs, including any SSP exposure - Approved-mode behavior and non-approved behavior - Underlying approved security functions used by the service - Evidence links such as test case IDs, logs, config references, or policy sections ## Map services to approved security functions in a testable way A strong map lets the lab see which services are in scope, which are approved in approved mode, which algorithms and self-tests support them, and how SSP protection applies. Current Implementation Guidance places a lot of weight on consistency. Approved service indicators must not imply approval if the necessary conditions for approved operation are not actually met. - Map each service to approved functions or explicitly mark it non-approved - Tie each service to required self-tests and error-state behavior - Map each service to SSP access and zeroization expectations - Tie each service to the evidence artifacts that prove the claim - Define one approved-mode narrative and keep it consistent across all services ## Handle embedded or bound modules without overclaiming If you embed or bind to other validated modules, boundary clarity becomes even more important. Current CMVP FAQ and guidance materials distinguish your module under test from any embedded validated module it relies on. The common failure is overclaiming. A product that uses an embedded validated module is not automatically itself validated. Another failure is vague documentation that prevents the lab from telling what your own module actually does versus what the embedded module contributes. - Identify embedded or bound modules precisely with exact certificate and version information - Represent your module functionality separately from embedded functionality - Only cite embedded functionality the module actually uses - Keep marketing language aligned with the actual certificate scope ## Deliver a boundary-to-evidence blueprint The easiest way to reduce rework is to create a single boundary-to-evidence blueprint that engineering, documentation, QA, and the CSTL can all use. That blueprint should combine the boundary, services inventory, SSP map, approved-mode rules, and evidence references in one controlled place. - Boundary diagram and interface inventory - Roles, services, and authentication matrix - Approved-mode definition and service indicator behavior - SSP lifecycle map and zeroization evidence plan - Evidence register with ownership and update rules *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep FIPS 140-3 Module boundary and services mapping in one governed evidence system SSOT can take FIPS 140-3 Module boundary and services mapping from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on FIPS 140-3 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for FIPS 140-3 Module boundary and services mapping](/solutions/ssot.md): Start from FIPS 140-3 Module boundary and services mapping and keep documents, evidence, and control records in one governed system. - [Talk through FIPS 140-3](/contact.md): Review your current process, evidence gaps, and next steps for FIPS 140-3 Module boundary and services mapping. ## Primary sources - [FIPS PUB 140-3 (Security Requirements for Cryptographic Modules)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf?ref=sorena.io) - Primary requirement areas for module specification, interfaces, roles and services, and SSP management. - [CMVP FAQ](https://csrc.nist.gov/projects/cryptographic-module-validation-program/faqs?ref=sorena.io) - Official clarification that products using embedded validated modules are not automatically themselves validated. - [Implementation Guidance for FIPS 140-3 and the CMVP](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Current guidance for embedding, binding, approved security service indicators, and documentation expectations. - [NIST and CCCS CMVP program overview](https://csrc.nist.gov/projects/cryptographic-module-validation-program?ref=sorena.io) - Program context and supporting links for validation flow and accepted artifacts. ## Related Topic Guides - [FIPS 140-3 Compliance (CMVP Validation Playbook, Approved Mode, Transition)](/artifacts/global/fips-140-3/compliance.md): A practical FIPS 140-3 compliance and validation playbook for CMVP cryptographic module validation: boundary, security level selection, approved mode. - [FIPS 140-3 FAQ (CMVP Validation, Approved Mode, Embedded Modules, Transition)](/artifacts/global/fips-140-3/faq.md): FIPS 140-3 FAQ for cryptographic module teams: what FIPS 140-3 covers, how CMVP validation works, what approved mode means. - [FIPS 140-3 Security Levels (Level 1 to Level 4) Explained](/artifacts/global/fips-140-3/security-levels-explained.md): FIPS 140-3 security levels explained: what Level 1, Level 2, Level 3, and Level 4 mean, how they affect boundary and deployment assumptions. - [FIPS 140-3 Validation Checklist (CMVP Lab Readiness, Approved Mode, Transition)](/artifacts/global/fips-140-3/fips-140-3-validation-checklist.md): A practical FIPS 140-3 validation checklist for CMVP lab readiness: boundary, services, approved mode, documentation, self-tests, SSP management. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-140-3/module-boundary-and-service-mapping --- --- title: "FIPS 140-3 Security Levels (Level 1 to Level 4) Explained" canonical_url: "https://www.sorena.io/artifacts/global/fips-140-3/security-levels-explained" source_url: "https://www.sorena.io/artifacts/global/fips-140-3/security-levels-explained" author: "Sorena AI" description: "FIPS 140-3 security levels explained: what Level 1, Level 2, Level 3, and Level 4 mean, how they affect boundary and deployment assumptions." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "FIPS 140-3 security levels" - "FIPS 140-3 Level 1 Level 2 Level 3 Level 4" - "CMVP security level selection" - "FIPS 140-3 physical security level" - "FIPS 140-3 assurance level" - "cryptographic module security level" - "GLOBAL compliance" - "FIPS 140-3" - "Security levels" - "CMVP" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FIPS 140-3 Security Levels (Level 1 to Level 4) Explained FIPS 140-3 security levels explained: what Level 1, Level 2, Level 3, and Level 4 mean, how they affect boundary and deployment assumptions. *Explainer* *GLOBAL* ## FIPS 140-3 Security levels explained FIPS 140-3 defines four increasing, qualitative security levels. Choose the level like an assurance decision, not a marketing label. This guide focuses on practical selection signals and evidence implications. FIPS 140-3 provides four increasing, qualitative security levels and applies security requirements across 11 requirement areas. The level you target affects engineering scope, documentation, testing, and the evidence your CST laboratory will expect. This page explains how to select a level in a defensible way. ## What the security levels represent FIPS 140-3 security levels are qualitative and increasing. Higher levels generally require stronger protections and stronger proof across requirement areas, especially where physical access and tampering are realistic risks. Because the levels apply across multiple requirement areas, a level decision influences boundary design, physical assumptions, operator controls, SSP handling, and the final Security Policy. - Levels are assurance targets, not feature bundles - Higher levels usually mean stronger physical and operational controls - The chosen level should match the actual deployment environment and threat model ## How to choose a level that survives review The defensible way to choose a level is to tie it to measurable assumptions: physical access risk, operator access, attacker capability, and the impact of SSP compromise. Teams often get into trouble when they choose a level only because a customer asked for it. If the boundary, physical design, or operations model cannot support the choice, the level selection collapses under lab review. - Physical access: who can reach the module, host, ports, or debug surfaces? - Operator model: who administers the module and how are privileged actions controlled? - Impact: what happens if keys or other SSPs are extracted or corrupted? - Environment control: controlled facility, enterprise environment, field deployment, or hostile environment? ## What changes as you move up levels The difference between levels is not mainly more paperwork. It is stronger design constraints and stronger proof obligations. That affects physical security evidence, role and authentication evidence, SSP handling evidence, and sometimes the practicality of the chosen boundary. If you decide the target level late, you usually pay for it with redesign work and test-plan churn. - Boundary scrutiny increases because interface and trust assumptions matter more - Physical security evidence becomes more important as tamper risk increases - Role and authentication evidence usually becomes stricter - SSP protection and zeroization proof must be clearer and more attributable ## Practical starting heuristics These are not substitutes for CSTL advice, but they are useful early filters when you are deciding what is realistic. - If physical access risk is low and you need a baseline assurance target, evaluate Level 1 first - If you need stronger tamper evidence and stronger operator discipline, evaluate Level 2 - If you need stronger physical and logical protections in environments where tampering is plausible, evaluate Level 3 - If the module must resist the harshest or least controlled physical environments, evaluate Level 4 - If you cannot write down the physical and operator assumptions, the level selection is not defensible yet *Recommended next step* *Placement: near the end of the main content before related guides* ## Use FIPS 140-3 Security levels explained as a cited research workflow Research Copilot can take FIPS 140-3 Security levels explained from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on FIPS 140-3 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for FIPS 140-3 Security levels explained](/solutions/research-copilot.md): Start from FIPS 140-3 Security levels explained and answer scope, timing, and interpretation questions with cited outputs. - [Talk through FIPS 140-3](/contact.md): Review your current process, evidence gaps, and next steps for FIPS 140-3 Security levels explained. ## Primary sources - [FIPS PUB 140-3 (Security Requirements for Cryptographic Modules)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf?ref=sorena.io) - Defines the four qualitative security levels and the 11 requirement areas. - [NIST and CCCS CMVP program overview](https://csrc.nist.gov/projects/cryptographic-module-validation-program?ref=sorena.io) - Program context for how modules are tested and validated under FIPS 140-3. - [Implementation Guidance for FIPS 140-3 and the CMVP](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Current clarifications that affect how level expectations are interpreted in practice. ## Related Topic Guides - [FIPS 140-3 Compliance (CMVP Validation Playbook, Approved Mode, Transition)](/artifacts/global/fips-140-3/compliance.md): A practical FIPS 140-3 compliance and validation playbook for CMVP cryptographic module validation: boundary, security level selection, approved mode. - [FIPS 140-3 FAQ (CMVP Validation, Approved Mode, Embedded Modules, Transition)](/artifacts/global/fips-140-3/faq.md): FIPS 140-3 FAQ for cryptographic module teams: what FIPS 140-3 covers, how CMVP validation works, what approved mode means. - [FIPS 140-3 Module Boundary and Services Mapping (Approved Mode, Embedded Modules)](/artifacts/global/fips-140-3/module-boundary-and-service-mapping.md): Advanced guide to FIPS 140-3 cryptographic module boundary definition and services mapping: boundary diagrams, approved-mode indicators, SSP access. - [FIPS 140-3 Validation Checklist (CMVP Lab Readiness, Approved Mode, Transition)](/artifacts/global/fips-140-3/fips-140-3-validation-checklist.md): A practical FIPS 140-3 validation checklist for CMVP lab readiness: boundary, services, approved mode, documentation, self-tests, SSP management. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-140-3/security-levels-explained --- --- title: "AES (FIPS 197) - How to Use AES Safely" canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/aes-fips-197" source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/aes-fips-197" author: "Sorena AI" description: "Advanced implementation guide for AES under FIPS 197 upd1: AES-128, AES-192, AES-256, approved modes." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "AES FIPS 197" - "Advanced Encryption Standard" - "AES-128 AES-192 AES-256" - "FIPS approved encryption" - "AES implementation guide" - "AES modes of operation" - "AES key management" - "AES evidence pack" - "FIPS 140-3 approved mode AES" - "GLOBAL compliance" - "FIPS 197" - "AES" - "Symmetric encryption" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # AES (FIPS 197) - How to Use AES Safely Advanced implementation guide for AES under FIPS 197 upd1: AES-128, AES-192, AES-256, approved modes. *Implementation guide* *GLOBAL* ## FIPS Crypto Algorithms AES (FIPS 197) AES is the FIPS-approved block cipher for confidentiality, but most failures come from unsafe use around the cipher. This page explains what FIPS 197 specifies and how to use AES safely in real systems. FIPS 197, updated on 9 May 2023 as FIPS 197 upd1, specifies the Advanced Encryption Standard. It defines three members of the Rijndael family: AES-128, AES-192, and AES-256. All use a fixed 128-bit block size, and the key length determines the variant. The practical engineering problem is not the round function itself. It is safe usage: approved mode selection, IV or nonce rules, key handling, and evidence that your implementation matches your assurance claims. ## What FIPS 197 specifies and what it leaves to other guidance FIPS 197 is the algorithm standard. It defines AES as a symmetric block cipher with a fixed 128-bit block and key lengths of 128, 192, or 256 bits. It does not by itself specify a secure application profile for files, APIs, or network protocols. The standard says AES shall be used with a FIPS-approved or NIST-recommended mode of operation. That means teams have to govern the full bundle: AES plus mode plus IV or nonce rules plus key lifecycle. - Variants: AES-128, AES-192, AES-256 - Block size: 128 bits - Implementations may be software, firmware, hardware, or a combination - Mode selection and object identifiers are handled through related NIST resources such as CSOR ## Safe AES usage means controlling the full bundle Most AES failures are not failures of the cipher. They are failures of mode choice, IV reuse, weak key separation, or sloppy error handling. Treat AES usage as a controlled bundle. If any one part of the bundle is uncontrolled, the overall design can fail even when the algorithm is correct. - Use only approved or recommended modes that match the protocol and threat model - Define IV or nonce generation rules in code and tests, not only in documentation - Separate keys by purpose so encryption keys do not become general-purpose secrets - Make failure handling explicit so padding, tag, or decryption errors do not leak useful signals ## Implementation discipline that reduces audit and validation pain AES deployments go wrong when secure defaults are optional or when different runtimes quietly pick different configurations. The safest pattern is to publish a narrow approved-configuration set per supported product version and environment. That matters even more in FIPS 140-3 contexts, because the approved-mode story must be consistent across documentation, test evidence, and runtime behavior. - Pin libraries, firmware, accelerators, and build flags for the validated or reviewed configuration - Make configuration drift visible with manifests or startup checks - Retain test vectors, known-answer tests, and integration evidence for each supported build - Document where AES is used, for what purpose, and under which operational constraints ## What evidence is worth retaining Even if you are not pursuing immediate module validation, customers and internal reviewers will ask the same questions: where is AES used, what parameters are allowed, and how do you prevent misuse. Build the evidence pack as a byproduct of engineering work rather than as a late-stage audit exercise. - Crypto inventory entry showing service, mode, key size, and owner - Configuration evidence such as build flags, manifests, and runtime policy - Verification artifacts such as known-answer tests and interoperability tests - Key-management records covering generation, storage, rotation, and destruction - Change-control history for algorithm, mode, or dependency updates *Recommended next step* *Placement: near the end of the main content before related guides* ## Use FIPS Crypto Algorithms AES (FIPS 197) as a cited research workflow Research Copilot can take FIPS Crypto Algorithms AES (FIPS 197) from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on FIPS Crypto Algorithms can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for FIPS Crypto Algorithms AES (FIPS 197)](/solutions/research-copilot.md): Start from FIPS Crypto Algorithms AES (FIPS 197) and answer scope, timing, and interpretation questions with cited outputs. - [Talk through FIPS Crypto Algorithms](/contact.md): Review your current process, evidence gaps, and next steps for FIPS Crypto Algorithms AES (FIPS 197). ## Primary sources - [FIPS 197 upd1: Advanced Encryption Standard (AES)](https://doi.org/10.6028/NIST.FIPS.197-upd1?ref=sorena.io) - Primary source for AES definition, key sizes, and the requirement to use approved or recommended modes. - [NIST AES project page](https://csrc.nist.gov/projects/aes?ref=sorena.io) - Official AES project resources and examples. - [Computer Security Objects Register](https://csrc.nist.gov/projects/csor?ref=sorena.io) - Official source for AES object identifiers and associated parameters. - [FIPS 140-3 (Security Requirements for Cryptographic Modules)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf?ref=sorena.io) - Context for how AES is treated inside validated modules and approved-mode claims. ## Related Topic Guides - [Digital Signatures (FIPS 186-5 DSS and FIPS 204 ML-DSA)](/artifacts/global/fips-crypto-algorithms/digital-signatures-fips-186-5-and-fips-204.md): Advanced guide to FIPS digital signatures: RSA, ECDSA, deterministic ECDSA, EdDSA, and post-quantum ML-DSA. - [FIPS Crypto Algorithms FAQ (AES, SHA, Signatures, PQC)](/artifacts/global/fips-crypto-algorithms/faq.md): FAQ for FIPS crypto adoption: AES, SHA-2 and SHA-3, digital signatures, post-quantum standards. - [Post-Quantum Cryptography (FIPS 203, 204, 205) - Migration Guide](/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205.md): Practical post-quantum cryptography migration guidance grounded in FIPS 203, FIPS 204, and FIPS 205. - [Secure Hash (FIPS 180-4 SHA-2, FIPS 202 SHA-3, SHAKE)](/artifacts/global/fips-crypto-algorithms/secure-hash-fips-180-4-and-fips-202.md): Deep guide to FIPS secure hash standards: SHA-2 under FIPS 180-4 and SHA-3 plus SHAKE under FIPS 202. Learn digest selection, XOF rules, and evidence strategy. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-crypto-algorithms/aes-fips-197 --- --- title: "Digital Signatures (FIPS 186-5 DSS and FIPS 204 ML-DSA)" canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/digital-signatures-fips-186-5-and-fips-204" source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/digital-signatures-fips-186-5-and-fips-204" author: "Sorena AI" description: "Advanced guide to FIPS digital signatures: RSA, ECDSA, deterministic ECDSA, EdDSA, and post-quantum ML-DSA." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "FIPS 186-5" - "Digital Signature Standard" - "FIPS 204" - "ML-DSA" - "post-quantum digital signatures" - "ECDSA" - "EdDSA" - "RSA signatures" - "signature policy" - "signature interoperability" - "FIPS 140-3 signature evidence" - "GLOBAL compliance" - "Digital signatures" - "PQC" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Digital Signatures (FIPS 186-5 DSS and FIPS 204 ML-DSA) Advanced guide to FIPS digital signatures: RSA, ECDSA, deterministic ECDSA, EdDSA, and post-quantum ML-DSA. *Implementation guide* *GLOBAL* ## FIPS Crypto Algorithms Digital signatures Digital signatures are long-lived interoperability commitments with strong evidence expectations. This guide covers FIPS 186-5 and FIPS 204 with a practical selection and governance lens. FIPS 186-5, published on 3 February 2023, is the current Digital Signature Standard. It approves use of RSA signatures through RFC 8017, specifies ECDSA, approves deterministic ECDSA through RFC 6979, and approves EdDSA with additional requirements. FIPS 204, published on 13 August 2024, adds ML-DSA as a post-quantum digital signature standard. The engineering challenge is choosing the right scheme, controlling key purpose, pinning digest behavior, and keeping signatures verifiable for years. ## What FIPS 186-5 actually covers FIPS 186-5 is broader than older DSS summaries suggest. It approves RSA signature implementations based on RFC 8017, specifies ECDSA, includes deterministic ECDSA, and approves EdDSA with additional requirements. It also changes legacy assumptions. The standard no longer approves DSA for digital signature generation, although DSA may still be used to verify signatures generated before the implementation date under the older standard. - RSA signatures through RFC 8017 plus FIPS 186-5 requirements - ECDSA and deterministic ECDSA - EdDSA and HashEdDSA support - Legacy DSA verification only for older signatures ## Where FIPS 204 fits FIPS 204 specifies ML-DSA, a module-lattice-based digital signature algorithm published on 13 August 2024. It is part of the post-quantum transition stack and should be planned as a crypto-agility move, not just a library upgrade. For many teams, the real decision is not classic versus post-quantum. It is which verification domains need classic compatibility, which ones can move first, and where hybrid evidence or parallel support is required. - Use ML-DSA when you need post-quantum signature capability - Keep classic-verification dependencies visible during migration - Treat algorithm identifiers and parameter sets as part of the signature policy ## Key-purpose discipline matters more than teams expect FIPS 186-5 and FIPS 205 both reinforce a simple rule: digital signature key pairs are for signatures, not for unrelated purposes. This matters because key-purpose drift is a common production failure in complex systems. Use separate keys for code signing, document signing, identity assertions, and protocol authentication unless the policy explicitly justifies reuse. - Do not reuse signature keys for key establishment or generic secret storage - Separate keys by environment and signing purpose - Retain generation, access-control, rotation, and revocation evidence for each key class ## Hash and signature choices have to stay pinned Digest selection is part of signature-system interoperability. FIPS 186-5 references FIPS 180 and FIPS 202, and specific algorithms carry specific digest rules. For example, Ed25519 uses SHA-512 and Ed448 uses SHAKE256 inside the standard. If hash or XOF choices drift between signer and verifier, the result is broken verification or ambiguous evidence. Treat digest and parameter choices as policy, not as incidental implementation detail. - Publish a signature policy with scheme, digest, encoding, and verification rules - Do not change digests silently in deployed verifiers - Retain interoperability tests across runtimes and storage formats ## Evidence that makes signature reviews predictable Signature systems are often reviewed for non-repudiation, software integrity, identity, or procurement reasons. Good evidence proves the selected schemes, the key-purpose controls, and the long-term verification story. The evidence pack should be able to answer who signed, with which scheme and parameters, under which policy, and how the system proves that later. - Signature policy covering schemes, digests, encodings, and verifier behavior - Key-lifecycle evidence covering generation, storage, rotation, revocation, and destruction - Test evidence across signer and verifier implementations - Operational logs and approvals for signing workflows - Change control for scheme and parameter changes *Recommended next step* *Placement: near the end of the main content before related guides* ## Use FIPS Crypto Algorithms Digital signatures as a cited research workflow Research Copilot can take FIPS Crypto Algorithms Digital signatures from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on FIPS Crypto Algorithms can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for FIPS Crypto Algorithms Digital signatures](/solutions/research-copilot.md): Start from FIPS Crypto Algorithms Digital signatures and answer scope, timing, and interpretation questions with cited outputs. - [Talk through FIPS Crypto Algorithms](/contact.md): Review your current process, evidence gaps, and next steps for FIPS Crypto Algorithms Digital signatures. ## Primary sources - [FIPS 186-5 (Digital Signature Standard)](https://doi.org/10.6028/NIST.FIPS.186-5?ref=sorena.io) - Primary DSS source covering RSA, ECDSA, deterministic ECDSA, and EdDSA. - [FIPS 204 (Module-Lattice-Based Digital Signature Standard)](https://doi.org/10.6028/NIST.FIPS.204?ref=sorena.io) - Primary post-quantum digital signature source for ML-DSA. - [FIPS 180-4 (Secure Hash Standard)](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Hash reference for signature-system digest choices. - [FIPS 202 (SHA-3 Standard)](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Hash and XOF reference used by parts of modern signature systems. ## Related Topic Guides - [AES (FIPS 197) - How to Use AES Safely](/artifacts/global/fips-crypto-algorithms/aes-fips-197.md): Advanced implementation guide for AES under FIPS 197 upd1: AES-128, AES-192, AES-256, approved modes. - [FIPS Crypto Algorithms FAQ (AES, SHA, Signatures, PQC)](/artifacts/global/fips-crypto-algorithms/faq.md): FAQ for FIPS crypto adoption: AES, SHA-2 and SHA-3, digital signatures, post-quantum standards. - [Post-Quantum Cryptography (FIPS 203, 204, 205) - Migration Guide](/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205.md): Practical post-quantum cryptography migration guidance grounded in FIPS 203, FIPS 204, and FIPS 205. - [Secure Hash (FIPS 180-4 SHA-2, FIPS 202 SHA-3, SHAKE)](/artifacts/global/fips-crypto-algorithms/secure-hash-fips-180-4-and-fips-202.md): Deep guide to FIPS secure hash standards: SHA-2 under FIPS 180-4 and SHA-3 plus SHAKE under FIPS 202. Learn digest selection, XOF rules, and evidence strategy. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-crypto-algorithms/digital-signatures-fips-186-5-and-fips-204 --- --- title: "FIPS Crypto Algorithms FAQ (AES, SHA, Signatures, PQC)" canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/faq" source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/faq" author: "Sorena AI" description: "FAQ for FIPS crypto adoption: AES, SHA-2 and SHA-3, digital signatures, post-quantum standards." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "FIPS crypto algorithms FAQ" - "FIPS approved algorithms FAQ" - "AES FIPS 197 FAQ" - "SHA-2 FIPS 180-4 FAQ" - "SHA-3 FIPS 202 FAQ" - "FIPS 186-5 FAQ" - "FIPS 203 204 205 FAQ" - "post-quantum cryptography FIPS FAQ" - "FIPS 140-3 evidence" - "GLOBAL compliance" - "FIPS crypto" - "FAQ" - "AES" - "SHA" - "PQC" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FIPS Crypto Algorithms FAQ (AES, SHA, Signatures, PQC) FAQ for FIPS crypto adoption: AES, SHA-2 and SHA-3, digital signatures, post-quantum standards. *FAQ* *GLOBAL* ## FIPS Crypto Algorithms FAQ Common questions about adopting FIPS crypto standards in real products and protocols. Focused on practical selection, interoperability, and evidence, not generic crypto summaries. This FAQ is implementation guidance, not legal advice. Validate final decisions against NIST primary sources and the assurance scheme you are targeting. ## Do FIPS publications validate my implementation automatically? No. FIPS publications define standards and algorithms. They do not automatically validate a product implementation. In assurance contexts, the real question is whether you implement the algorithm correctly, constrain it safely, and can prove that with documentation, tests, and operational evidence. ## Does FIPS 197 tell me which AES mode to use? No. FIPS 197 defines AES itself. The standard says AES shall be used with a FIPS-approved or NIST-recommended mode of operation. That means the secure design choice is the whole bundle: AES plus mode plus IV or nonce rules plus key management plus error handling. ## What is the difference between FIPS 180-4 and FIPS 202? FIPS 180-4 specifies the Secure Hash Standard and includes SHA-1 and the SHA-2 family. FIPS 202 specifies SHA-3 and the XOFs SHAKE128 and SHAKE256. FIPS 202 explicitly says SHA-3 supplements FIPS 180-4 and that the two standards together provide resilience because they use fundamentally different design principles. ## Are SHAKE128 and SHAKE256 just hash functions? No. In FIPS 202 they are approved XOFs, not approved hash functions in the general sense. Their approved uses are specified in NIST Special Publications. That distinction matters because XOF output length is variable, which creates parameter and interoperability obligations that fixed-output hashes do not have. ## What changed in FIPS 186-5 compared with older DSS guidance? FIPS 186-5 is broader and more modern. It covers RSA signatures through RFC 8017, specifies ECDSA, approves deterministic ECDSA, and approves EdDSA with additional requirements. It also no longer approves DSA for new signature generation, although DSA may still be used to verify signatures generated before the new standard took effect. ## What do FIPS 203, 204, and 205 do? FIPS 203 specifies ML-KEM for post-quantum key establishment. FIPS 204 specifies ML-DSA for post-quantum digital signatures. FIPS 205 specifies SLH-DSA for stateless hash-based digital signatures. All three were published on 13 August 2024 and should be treated as part of a crypto-agility and migration program, not as isolated algorithm swaps. ## Do we need FIPS 140-3 to use FIPS algorithms? No. You can implement FIPS algorithms without pursuing FIPS 140-3 module validation. But if you do pursue FIPS 140-3, the algorithm choices have to line up with the module boundary, services mapping, approved mode behavior, self-tests, and documentation. ## What evidence should we retain as a minimum useful pack? Keep enough evidence to answer four questions quickly: where crypto is used, which algorithms and parameters are allowed, how misuse is prevented, and how changes are controlled. In practice that means a crypto inventory, configuration manifests, verification artifacts, key-management evidence, and change-control history. *Recommended next step* *Placement: after the FAQ section* ## Use FIPS Crypto Algorithms FAQ as a cited research workflow Research Copilot can take FIPS Crypto Algorithms FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on FIPS Crypto Algorithms can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for FIPS Crypto Algorithms FAQ](/solutions/research-copilot.md): Start from FIPS Crypto Algorithms FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through FIPS Crypto Algorithms](/contact.md): Review your current process, evidence gaps, and next steps for FIPS Crypto Algorithms FAQ. ## Primary sources - [FIPS 197 upd1: Advanced Encryption Standard (AES)](https://doi.org/10.6028/NIST.FIPS.197-upd1?ref=sorena.io) - Primary AES reference. - [FIPS 180-4 (Secure Hash Standard)](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Primary SHA-2 family reference. - [FIPS 202 (SHA-3 Standard)](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Primary SHA-3 and SHAKE reference. - [FIPS 186-5 (Digital Signature Standard)](https://doi.org/10.6028/NIST.FIPS.186-5?ref=sorena.io) - Primary signature-standard reference. - [FIPS 203 (ML-KEM)](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Primary post-quantum key-establishment reference. - [FIPS 140-3 (Security Requirements for Cryptographic Modules)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf?ref=sorena.io) - Context for algorithm use inside validated modules. ## Related Topic Guides - [AES (FIPS 197) - How to Use AES Safely](/artifacts/global/fips-crypto-algorithms/aes-fips-197.md): Advanced implementation guide for AES under FIPS 197 upd1: AES-128, AES-192, AES-256, approved modes. - [Digital Signatures (FIPS 186-5 DSS and FIPS 204 ML-DSA)](/artifacts/global/fips-crypto-algorithms/digital-signatures-fips-186-5-and-fips-204.md): Advanced guide to FIPS digital signatures: RSA, ECDSA, deterministic ECDSA, EdDSA, and post-quantum ML-DSA. - [Post-Quantum Cryptography (FIPS 203, 204, 205) - Migration Guide](/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205.md): Practical post-quantum cryptography migration guidance grounded in FIPS 203, FIPS 204, and FIPS 205. - [Secure Hash (FIPS 180-4 SHA-2, FIPS 202 SHA-3, SHAKE)](/artifacts/global/fips-crypto-algorithms/secure-hash-fips-180-4-and-fips-202.md): Deep guide to FIPS secure hash standards: SHA-2 under FIPS 180-4 and SHA-3 plus SHAKE under FIPS 202. Learn digest selection, XOF rules, and evidence strategy. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-crypto-algorithms/faq --- --- title: "Post-Quantum Cryptography (FIPS 203, 204, 205) - Migration Guide" canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205" source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205" author: "Sorena AI" description: "Practical post-quantum cryptography migration guidance grounded in FIPS 203, FIPS 204, and FIPS 205." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "post-quantum cryptography FIPS" - "PQC migration guide" - "FIPS 203 ML-KEM" - "FIPS 204 ML-DSA" - "FIPS 205 SLH-DSA" - "hybrid PQC deployment" - "crypto agility" - "PQC inventory" - "PQC evidence pack" - "GLOBAL compliance" - "PQC" - "FIPS 203" - "FIPS 204" - "FIPS 205" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Post-Quantum Cryptography (FIPS 203, 204, 205) - Migration Guide Practical post-quantum cryptography migration guidance grounded in FIPS 203, FIPS 204, and FIPS 205. *Migration guide* *GLOBAL* ## FIPS Crypto Algorithms Post-quantum cryptography PQC adoption is a systems project: inventory, protocols, interoperability, evidence, and long-lived verification. This page focuses on practical migration patterns grounded in the final 13 August 2024 FIPS releases. FIPS 203, FIPS 204, and FIPS 205 were all published on 13 August 2024. FIPS 203 specifies ML-KEM for post-quantum key establishment. FIPS 204 specifies ML-DSA for post-quantum digital signatures. FIPS 205 specifies SLH-DSA for stateless hash-based digital signatures. The migration challenge is not just picking a new primitive. It is building crypto agility so systems can support new algorithm identifiers, parameter sets, and verification rules without breaking interoperability or long-term trust. ## What each PQC FIPS standard is for FIPS 203 covers ML-KEM, a key-encapsulation mechanism used to establish a shared secret that other symmetric algorithms can then protect. It defines three parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. FIPS 204 and FIPS 205 cover signatures, but with different constructions. ML-DSA is module-lattice based. SLH-DSA is stateless hash based. They solve related problems with different tradeoffs in size, performance, and operational complexity. - Use ML-KEM for post-quantum key establishment - Use ML-DSA for module-lattice-based post-quantum signatures - Use SLH-DSA when stateless hash-based signatures fit the assurance and performance model ## Migration strategy that actually works Start with an inventory. Find every place public-key cryptography appears: TLS, device identity, firmware signing, code signing, document signing, certificate profiles, tokens, and hardware-backed stores. Then build crypto agility. The system should make algorithm identifiers, parameter sets, negotiation rules, and verification behavior explicit and testable. Only after that should you decide where hybrid deployments are necessary. - Inventory protocols, formats, libraries, hardware support, and stored signatures - Pin algorithm identifiers and parameter sets explicitly - Log and test negotiation behavior so downgrade is visible - Use hybrid deployments where compatibility and trust requirements demand parallel support ## Predictable PQC failure points PQC projects rarely fail because the primitive is mathematically unsound. They fail because systems assume legacy key sizes, signature sizes, field lengths, or verifier behavior. The right time to find those assumptions is before rollout. - Protocol size limits and storage-field limits - Certificate and token profiles that assume classic algorithms only - Long-lived verification records that need stable algorithm metadata - Hardware or dependency stacks that do not support the chosen parameter sets - Negotiation logic that silently falls back to classic-only behavior ## Evidence that proves PQC adoption was deliberate Security teams and procurement reviewers will want to know what you chose, where you deployed it, how you prevent downgrade, and how you plan to maintain it. Build that evidence as an engineering output. A strong evidence pack for PQC looks like a governed migration program, not a one-off library swap. - Crypto inventory entry per use case with scheme and parameter set - Interoperability tests across peers, languages, and runtimes - Negotiation and telemetry evidence that shows algorithm outcomes clearly - Key-management and signing-policy evidence for every PQC-enabled workflow - Change-control rules for parameter changes and deprecations *Recommended next step* *Placement: near the end of the main content before related guides* ## Use FIPS Crypto Algorithms Post-quantum cryptography as a cited research workflow Research Copilot can take FIPS Crypto Algorithms Post-quantum cryptography from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on FIPS Crypto Algorithms can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for FIPS Crypto Algorithms Post-quantum cryptography](/solutions/research-copilot.md): Start from FIPS Crypto Algorithms Post-quantum cryptography and answer scope, timing, and interpretation questions with cited outputs. - [Talk through FIPS Crypto Algorithms](/contact.md): Review your current process, evidence gaps, and next steps for FIPS Crypto Algorithms Post-quantum cryptography. ## Primary sources - [FIPS 203 (Module-Lattice-Based Key-Encapsulation Mechanism Standard)](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Primary source for ML-KEM and its parameter sets. - [FIPS 204 (Module-Lattice-Based Digital Signature Standard)](https://doi.org/10.6028/NIST.FIPS.204?ref=sorena.io) - Primary source for ML-DSA. - [FIPS 205 (Stateless Hash-Based Digital Signature Standard)](https://doi.org/10.6028/NIST.FIPS.205?ref=sorena.io) - Primary source for SLH-DSA. - [Cryptographic Standards and Guidelines example values](https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines/example-values?ref=sorena.io) - Official NIST example values page for supported standards. ## Related Topic Guides - [AES (FIPS 197) - How to Use AES Safely](/artifacts/global/fips-crypto-algorithms/aes-fips-197.md): Advanced implementation guide for AES under FIPS 197 upd1: AES-128, AES-192, AES-256, approved modes. - [Digital Signatures (FIPS 186-5 DSS and FIPS 204 ML-DSA)](/artifacts/global/fips-crypto-algorithms/digital-signatures-fips-186-5-and-fips-204.md): Advanced guide to FIPS digital signatures: RSA, ECDSA, deterministic ECDSA, EdDSA, and post-quantum ML-DSA. - [FIPS Crypto Algorithms FAQ (AES, SHA, Signatures, PQC)](/artifacts/global/fips-crypto-algorithms/faq.md): FAQ for FIPS crypto adoption: AES, SHA-2 and SHA-3, digital signatures, post-quantum standards. - [Secure Hash (FIPS 180-4 SHA-2, FIPS 202 SHA-3, SHAKE)](/artifacts/global/fips-crypto-algorithms/secure-hash-fips-180-4-and-fips-202.md): Deep guide to FIPS secure hash standards: SHA-2 under FIPS 180-4 and SHA-3 plus SHAKE under FIPS 202. Learn digest selection, XOF rules, and evidence strategy. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205 --- --- title: "Secure Hash (FIPS 180-4 SHA-2, FIPS 202 SHA-3, SHAKE)" canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/secure-hash-fips-180-4-and-fips-202" source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/secure-hash-fips-180-4-and-fips-202" author: "Sorena AI" description: "Deep guide to FIPS secure hash standards: SHA-2 under FIPS 180-4 and SHA-3 plus SHAKE under FIPS 202. Learn digest selection, XOF rules, and evidence strategy." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "FIPS 180-4" - "FIPS 202" - "SHA-2" - "SHA-3" - "SHAKE128" - "SHAKE256" - "secure hash standard" - "hash selection guide" - "cryptographic hash functions" - "XOF extendable-output function" - "GLOBAL compliance" - "SHAKE" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Secure Hash (FIPS 180-4 SHA-2, FIPS 202 SHA-3, SHAKE) Deep guide to FIPS secure hash standards: SHA-2 under FIPS 180-4 and SHA-3 plus SHAKE under FIPS 202. Learn digest selection, XOF rules, and evidence strategy. *Selection guide* *GLOBAL* ## FIPS Crypto Algorithms Secure hash Hashing affects signatures, integrity checks, KDFs, random generation, and protocol transcripts. Choose the digest deliberately. This page explains SHA-2, SHA-3, and SHAKE with practical selection rules. FIPS 180-4, published in August 2015, specifies the Secure Hash Standard and includes SHA-1 and the SHA-2 family. FIPS 202, also published in August 2015, specifies SHA-3 and the XOFs SHAKE128 and SHAKE256. FIPS 202 explicitly says SHA-3 supplements the functions in FIPS 180-4 and that the two standards together provide resilience because they rely on different design principles. The engineering challenge is choosing the right digest or XOF for the actual use case and then keeping those choices stable across implementations and time. ## What the two standards cover FIPS 180-4 covers SHA-1 and the SHA-2 family: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. It says either FIPS 180-4 or FIPS 202 must be implemented wherever a secure hash algorithm is required for Federal applications. FIPS 202 covers SHA3-224, SHA3-256, SHA3-384, SHA3-512, and the XOFs SHAKE128 and SHAKE256. It also defines the underlying Keccak-based structure and makes clear that the XOFs are different from fixed-output hash functions. - SHA-2 gives a mature fixed-output family with broad interoperability - SHA-3 adds design diversity and different implementation characteristics - SHAKE functions give variable-length output but come with additional parameter rules ## When SHAKE is useful and when it needs extra care SHAKE128 and SHAKE256 are approved XOFs under FIPS 202, but the standard says their approved uses are specified in NIST Special Publications. That matters because they are not simply drop-in replacements for every hash use case. Because output length is variable, teams have to pin output length and context explicitly. Otherwise, related outputs can create protocol or interoperability surprises. - Publish fixed output lengths per use case - Use explicit domain separation for structured or multi-role inputs - Test that every verifier and peer uses the same output-length rule - Keep XOF use aligned to an approved or documented application profile ## How hash choices affect signatures and protocols Hash functions are part of signature-system interoperability, not just internal plumbing. FIPS 186-5 references both FIPS 180 and FIPS 202 because digest choice affects signature validity, verification behavior, and security strength. The same problem appears in protocols. If one side upgrades or switches digests without explicit agreement, verification and transcript handling can fail. - Pin digest choice per signature scheme and protocol profile - Do not mix digests inside one profile unless the profile explicitly defines it - Treat digest changes as change-controlled compatibility events ## Evidence that proves hashing choices are controlled Hashing is easy to implement and easy to get subtly wrong. Reviewers will want to know where each hash or XOF is used, which parameters are allowed, and how mismatch or downgrade is prevented. A strong evidence pack makes those answers obvious. - Crypto inventory showing every SHA-2, SHA-3, and SHAKE use case - Algorithm and parameter registry, including SHAKE output length - Known-answer tests, integration tests, and interoperability tests - Domain-separation rules for protocols and structured data - Change-control history for digest or XOF changes *Recommended next step* *Placement: near the end of the main content before related guides* ## Use FIPS Crypto Algorithms Secure hash as a cited research workflow Research Copilot can take FIPS Crypto Algorithms Secure hash from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on FIPS Crypto Algorithms can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for FIPS Crypto Algorithms Secure hash](/solutions/research-copilot.md): Start from FIPS Crypto Algorithms Secure hash and answer scope, timing, and interpretation questions with cited outputs. - [Talk through FIPS Crypto Algorithms](/contact.md): Review your current process, evidence gaps, and next steps for FIPS Crypto Algorithms Secure hash. ## Primary sources - [FIPS 180-4 (Secure Hash Standard)](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Primary source for SHA-2 family hashes and federal applicability. - [FIPS 202 (SHA-3 Standard)](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Primary source for SHA-3 and the approved XOFs SHAKE128 and SHAKE256. - [FIPS 186-5 (Digital Signature Standard)](https://doi.org/10.6028/NIST.FIPS.186-5?ref=sorena.io) - Reference for how hash choices interact with signature systems. ## Related Topic Guides - [AES (FIPS 197) - How to Use AES Safely](/artifacts/global/fips-crypto-algorithms/aes-fips-197.md): Advanced implementation guide for AES under FIPS 197 upd1: AES-128, AES-192, AES-256, approved modes. - [Digital Signatures (FIPS 186-5 DSS and FIPS 204 ML-DSA)](/artifacts/global/fips-crypto-algorithms/digital-signatures-fips-186-5-and-fips-204.md): Advanced guide to FIPS digital signatures: RSA, ECDSA, deterministic ECDSA, EdDSA, and post-quantum ML-DSA. - [FIPS Crypto Algorithms FAQ (AES, SHA, Signatures, PQC)](/artifacts/global/fips-crypto-algorithms/faq.md): FAQ for FIPS crypto adoption: AES, SHA-2 and SHA-3, digital signatures, post-quantum standards. - [Post-Quantum Cryptography (FIPS 203, 204, 205) - Migration Guide](/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205.md): Practical post-quantum cryptography migration guidance grounded in FIPS 203, FIPS 204, and FIPS 205. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-crypto-algorithms/secure-hash-fips-180-4-and-fips-202 --- --- title: "FIPS Standards FAQ (Procurement, CMVP, Evidence)" canonical_url: "https://www.sorena.io/artifacts/global/fips-standards-hub/faq" source_url: "https://www.sorena.io/artifacts/global/fips-standards-hub/faq" author: "Sorena AI" description: "FIPS Standards FAQ for procurement, compliance, and crypto-engineering teams: what FIPS-compliant means, FIPS algorithms versus FIPS 140-3 validated modules." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "FIPS standards FAQ" - "FIPS 140-3 FAQ" - "CMVP FAQ" - "cryptographic module validation FAQ" - "FIPS approved algorithms FAQ" - "FIPS compliance evidence" - "approved mode of operation FAQ" - "cryptographic boundary FAQ" - "GLOBAL compliance" - "FIPS standards" - "CMVP" - "FIPS 140-3" - "FAQ" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FIPS Standards FAQ (Procurement, CMVP, Evidence) FIPS Standards FAQ for procurement, compliance, and crypto-engineering teams: what FIPS-compliant means, FIPS algorithms versus FIPS 140-3 validated modules. *FAQ* *GLOBAL* ## FIPS Standards Hub FAQ Answer procurement and audit questions without vague FIPS-compliant claims. This FAQ is written for teams that must ship products and defend claims under scrutiny. FIPS discussions fail when teams mix layers: algorithm standards, module security requirements, and validation certificates. This FAQ focuses on scoping and evidence: what the claim should mean, what to ask for, and how to avoid audit surprises. ## What does FIPS-compliant actually mean? It can mean different things. At the weakest level it can mean a team implements FIPS-approved algorithms. In stronger procurement contexts it often means the product uses a cryptographic module validated under FIPS 140-3 through the CMVP. The practical rule is simple: define the claim precisely, pin the version, and be ready to show evidence that matches the claim. - Algorithm claim: we implement approved algorithms - Module claim: we use a validated FIPS 140-3 cryptographic module - Evidence claim: we can prove configuration, approved mode, and change control ## What is the difference between FIPS 140-3 and FIPS crypto algorithm standards? FIPS 140-3 is about cryptographic modules. It defines four qualitative security levels and 11 requirement areas such as roles and services, SSP management, self-tests, lifecycle assurance, and mitigation of other attacks. Algorithm standards such as FIPS 197, FIPS 180-4, FIPS 202, FIPS 186-5, FIPS 203, FIPS 204, and FIPS 205 define algorithms and algorithm-level requirements. They do not by themselves create a validated-module procurement claim. - FIPS 140-3 governs module boundary and validation scope - FIPS algorithm standards govern primitives and algorithm usage - Buyers often care about the validated-module story, not only the algorithm story ## What is the CMVP and who is involved? The CMVP validates cryptographic modules to FIPS 140-3 and related standards. It is a joint effort between NIST and the Canadian Centre for Cyber Security. In practice, vendors work with accredited Cryptographic and Security Testing laboratories, and the CMVP validates the results and issues the certificate. - Vendor provides the module and evidence - CSTL performs testing - CMVP reviews results and issues the certificate ## Why does CMVP Implementation Guidance matter? Implementation Guidance exists because real modules have edge cases around embedding, service indicators, entropy, operational environments, and other issues that need practical interpretation. For audit stability, pin the guidance revision you implemented against and record it in the evidence pack. Treat guidance updates like controlled changes, not background reading. - Pin the guidance revision date - Monitor updates and run controlled delta reviews - Map procurement answers to the pinned guidance and tested scope ## What evidence should we ask a vendor for? Ask for evidence that matches the claim. If the claim is validated module, ask for the certificate scope, Security Policy, and tested operational environments. If the claim is algorithm usage, ask for the crypto inventory and configuration manifests that prove algorithm and parameter choices. If you cannot trace the claim to versions and scope, the claim is not procurement grade. - Validated module claim: certificate scope, Security Policy, tested environments - Approved-mode claim: services map, indicator behavior, self-test evidence - Algorithm claim: inventory, allowed algorithm identifiers, parameterization - Change control: how releases keep the validated or claimed configuration stable ## How do FIPS standards relate to NIST Special Publications? FIPS are standards. Many NIST Special Publications supply the cryptographic guidance that explains how to apply those standards in practice. In the FIPS 140-3 ecosystem, the SP 800-140 series modifies annex requirements for CMVP use. In other areas, publications such as SP 800-175B, SP 800-89, SP 800-208, and SP 800-227 guide how algorithms are applied in systems. Use the dedicated comparison page when you need a practical rule for which document family should lead the conversation. - Use FIPS for standards and validation scope - Use cryptographic NIST SPs for application guidance and assurance methods - One evidence pack can serve both if traceability is designed in from the start ## How does FIPS compare to Common Criteria? They answer different assurance questions. FIPS 140-3 focuses on cryptographic module security and approved-mode behavior. Common Criteria evaluates products against defined security requirements under product-evaluation schemes. Some programs require both. In that case, the strongest approach is to map the validated crypto module as a component within the broader product-evaluation scope. - FIPS 140-3 is module assurance - Common Criteria is product assurance - Reuse evidence by designing stable boundaries and artifact IDs *Recommended next step* *Placement: after the FAQ section* ## Use FIPS Standards Hub FAQ as a cited research workflow Research Copilot can take FIPS Standards Hub FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on FIPS Standards Hub can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for FIPS Standards Hub FAQ](/solutions/research-copilot.md): Start from FIPS Standards Hub FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through FIPS Standards Hub](/contact.md): Review your current process, evidence gaps, and next steps for FIPS Standards Hub FAQ. ## Primary sources - [FIPS 140-3 (Security Requirements for Cryptographic Modules)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf?ref=sorena.io) - Primary FIPS 140-3 source for levels and requirement areas. - [NIST and CCCS CMVP program overview](https://csrc.nist.gov/projects/cryptographic-module-validation-program?ref=sorena.io) - CMVP context: validation flow and roles. - [Implementation Guidance for FIPS 140-3 and the CMVP](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Current guidance used in practice by labs and vendors. - [CSRC FIPS publications index](https://csrc.nist.gov/publications/fips?ref=sorena.io) - Official index of FIPS publications. ## Related Topic Guides - [FIPS vs Common Criteria (CC) - What to Validate vs Evaluate](/artifacts/global/fips-standards-hub/fips-vs-common-criteria.md): Deep comparison of FIPS, especially FIPS 140-3 and CMVP, versus Common Criteria: scope differences, evidence overlap, and when procurement requires both. - [FIPS vs NIST SP Series (Standards vs Cryptographic Guidance)](/artifacts/global/fips-standards-hub/fips-vs-nist-sp-series.md): Deep comparison of FIPS standards versus NIST Special Publications in the cryptographic ecosystem: how they differ, how they are used together. - [What Is Included in FIPS Standards Hub (FIPS 140-3, CMVP, FIPS Crypto)](/artifacts/global/fips-standards-hub/what-is-included.md): Coverage map for the FIPS Standards Hub: FIPS 140-3 cryptographic module requirements, CMVP context and guidance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-standards-hub/faq --- --- title: "FIPS vs Common Criteria (CC) - What to Validate vs Evaluate" canonical_url: "https://www.sorena.io/artifacts/global/fips-standards-hub/fips-vs-common-criteria" source_url: "https://www.sorena.io/artifacts/global/fips-standards-hub/fips-vs-common-criteria" author: "Sorena AI" description: "Deep comparison of FIPS, especially FIPS 140-3 and CMVP, versus Common Criteria: scope differences, evidence overlap, and when procurement requires both." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "FIPS versus Common Criteria" - "FIPS 140-3 versus Common Criteria" - "CMVP versus Common Criteria" - "cryptographic module validation versus product evaluation" - "NIAP CCEVS" - "Common Criteria portal" - "GLOBAL compliance" - "FIPS 140-3" - "CMVP" - "Common Criteria" - "Assurance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FIPS vs Common Criteria (CC) - What to Validate vs Evaluate Deep comparison of FIPS, especially FIPS 140-3 and CMVP, versus Common Criteria: scope differences, evidence overlap, and when procurement requires both. *Comparison* *GLOBAL* ## FIPS Standards Hub FIPS versus Common Criteria FIPS 140-3 is about cryptographic modules and approved-mode behavior. Common Criteria is about product evaluation against defined security requirements. Some programs need both. The key is designing evidence so you reuse artifacts instead of rebuilding them twice. FIPS and Common Criteria are often bundled together in procurement language, but they solve different assurance problems. FIPS 140-3 and the CMVP validate cryptographic modules. Common Criteria evaluates products against defined evaluation targets and protection profiles under national schemes and mutual recognition arrangements. If you understand the scope boundary, you can build one evidence architecture that supports both tracks. ## Scope difference in one sentence FIPS 140-3 validates a cryptographic module: its boundary, roles and services, SSP management, self-tests, lifecycle assurance, and approved-mode behavior. Common Criteria evaluates a product or target of evaluation against a defined security target or protection profile and is broader than cryptography alone. - FIPS asks whether the crypto module is secure and validated within its defined scope - Common Criteria asks whether the product meets its defined security requirements - Procurement should always ask for the right certificate for the right scope *Recommended next step* *Placement: after the comparison section* ## Use FIPS Standards Hub FIPS versus Common Criteria as a cited research workflow Research Copilot can take FIPS Standards Hub FIPS versus Common Criteria from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on FIPS Standards Hub can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for FIPS Standards Hub FIPS versus Common Criteria](/solutions/research-copilot.md): Start from FIPS Standards Hub FIPS versus Common Criteria and answer scope, timing, and interpretation questions with cited outputs. - [Talk through FIPS Standards Hub](/contact.md): Review your current process, evidence gaps, and next steps for FIPS Standards Hub FIPS versus Common Criteria. ## What evidence overlaps and what does not Evidence overlap exists when you build disciplined boundaries and traceability. Configuration management, secure development evidence, vulnerability handling, and some test artifacts can often be reused. The part that does not overlap cleanly is certificate meaning. FIPS certificates speak about validated crypto modules. Common Criteria certificates speak about evaluated products. Mixing those certificate meanings creates procurement risk. - Overlaps: configuration management, secure development, vulnerability handling, change control - FIPS-specific: approved mode, services map, SSP lifecycle, self-tests, module boundary - CC-specific: TOE boundary, security target mapping, protection-profile claims beyond crypto ## When you need FIPS, Common Criteria, or both You need FIPS when the requirement is explicitly about cryptography assurance, especially validated cryptographic modules. You need Common Criteria when the procurement requires a product evaluation certificate for a class of products under a national scheme or protection profile. You need both when the product evaluation requires cryptographic functions and the procurement separately requires a validated crypto module story. In that case, treat the validated module as a component inside the broader product-evaluation scope. - FIPS-only: crypto module validation requirement is explicit - CC-only: product evaluation requirement is explicit - Both: the product must meet product-evaluation requirements and use validated crypto where required ## How to design one evidence blueprint for both The highest-leverage move is to build a stable artifact set with two mappings: a FIPS mapping around the module boundary and approved mode, and a Common Criteria mapping around the TOE boundary and security target. That lets different reviewers navigate the same evidence pack through different lenses without forcing the engineering team to duplicate every artifact. - Define both the cryptographic module boundary and the TOE boundary and explain how they relate - Create stable artifact IDs and version rules - Tie the crypto services map to the product security-function map - Run one change-control process that checks impact on both assurance tracks ## Primary sources - [FIPS 140-3 (Security Requirements for Cryptographic Modules)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf?ref=sorena.io) - Primary FIPS 140-3 source for module requirement areas and security levels. - [NIST and CCCS CMVP program overview](https://csrc.nist.gov/projects/cryptographic-module-validation-program?ref=sorena.io) - CMVP validation context and certificate meaning. - [Official Common Criteria Portal](https://www.commoncriteria.org/) - Official portal for Common Criteria information, schemes, and mutual recognition material. - [NIAP CCEVS](https://www.niap-ccevs.org/) - US scheme information for Common Criteria evaluations and requirements. ## Related Topic Guides - [FIPS Standards FAQ (Procurement, CMVP, Evidence)](/artifacts/global/fips-standards-hub/faq.md): FIPS Standards FAQ for procurement, compliance, and crypto-engineering teams: what FIPS-compliant means, FIPS algorithms versus FIPS 140-3 validated modules. - [FIPS vs NIST SP Series (Standards vs Cryptographic Guidance)](/artifacts/global/fips-standards-hub/fips-vs-nist-sp-series.md): Deep comparison of FIPS standards versus NIST Special Publications in the cryptographic ecosystem: how they differ, how they are used together. - [What Is Included in FIPS Standards Hub (FIPS 140-3, CMVP, FIPS Crypto)](/artifacts/global/fips-standards-hub/what-is-included.md): Coverage map for the FIPS Standards Hub: FIPS 140-3 cryptographic module requirements, CMVP context and guidance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-standards-hub/fips-vs-common-criteria --- --- title: "FIPS vs NIST SP Series (Standards vs Cryptographic Guidance)" canonical_url: "https://www.sorena.io/artifacts/global/fips-standards-hub/fips-vs-nist-sp-series" source_url: "https://www.sorena.io/artifacts/global/fips-standards-hub/fips-vs-nist-sp-series" author: "Sorena AI" description: "Deep comparison of FIPS standards versus NIST Special Publications in the cryptographic ecosystem: how they differ, how they are used together." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "FIPS versus NIST SP" - "FIPS standards versus NIST Special Publications" - "FIPS 140-3 versus SP 800-140 series" - "SP 800-175B" - "SP 800-89" - "SP 800-208" - "SP 800-227" - "GLOBAL compliance" - "FIPS standards" - "NIST Special Publications" - "Evidence" - "Assurance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # FIPS vs NIST SP Series (Standards vs Cryptographic Guidance) Deep comparison of FIPS standards versus NIST Special Publications in the cryptographic ecosystem: how they differ, how they are used together. *Comparison* *GLOBAL* ## FIPS Standards Hub FIPS versus NIST SP series FIPS usually defines the standard. NIST SP publications in this ecosystem often explain how to apply, validate, or operationalize it. The practical goal is one evidence system that satisfies both views: the standard and the application guidance around it. Teams waste time when they treat FIPS and NIST Special Publications as competing documents. In the cryptographic ecosystem they usually answer different questions. FIPS publications define algorithm standards and module requirements. NIST SP publications often give the application guidance, derived requirements, or assurance methods that make those standards usable in real systems. The best implementation is additive: use FIPS to define the requirement, then use the relevant SP publication to apply it safely and consistently. ## What changes operationally FIPS standards drive the core requirement or approval statement. FIPS 140-3 defines cryptographic module requirements. FIPS 197 defines AES. FIPS 180-4 and FIPS 202 define secure-hash families. FIPS 186-5, FIPS 203, FIPS 204, and FIPS 205 define signature and PQC standards. The NIST SP series often tells you how to apply those standards in practice. In the FIPS 140-3 ecosystem, the SP 800-140 series modifies annex requirements for CMVP use. In the algorithm ecosystem, publications such as SP 800-175B, SP 800-89, SP 800-208, SP 800-227, and SP 800-185 fill in application, assurance, or operational detail. - FIPS answers: what the standard requires - Relevant NIST SPs answer: how to apply or validate it in practice - Together they create the evidence story reviewers actually care about ## Examples that matter in real work FIPS 140-3 references the SP 800-140 series directly because CMVP uses those publications to modify annex requirements such as approved security functions, approved authentication mechanisms, approved SSP establishment methods, and Security Policy requirements. Recent algorithm standards do the same thing. FIPS 203 points implementers to SP 800-227 for KEM application guidance and to SP 800-108 and SP 800-56C for approved derivation methods. FIPS 204 and FIPS 205 point to SP 800-89 for signature-assurance methods. FIPS 204 and FIPS 205 also reference SP 800-175B, and FIPS 205 references SP 800-208 as an approved stateful-hash-signature alternative. - FIPS 140-3 plus SP 800-140A through F - FIPS 203 plus SP 800-227 and SP 800-56C family guidance - FIPS 204 and FIPS 205 plus SP 800-89 and SP 800-175B - FIPS 205 plus SP 800-208 for stateful hash-based alternatives ## Common failure mode: mixing evidence layers Conversations go wrong when a team answers a direct FIPS question with a generic guidance document, or answers an application-guidance question with a bare standards citation. The reviewer then still does not know what the system actually implements. The fix is to answer with the right document family first, then support it with the companion family. - If the question is about a validated module, lead with FIPS 140-3 and CMVP evidence - If the question is about algorithm use, lead with the relevant FIPS algorithm standard and your inventory - If the question is about safe application, lead with the relevant NIST SP guidance and supporting evidence ## How to combine them into one evidence architecture A strong evidence pack keeps one set of artifacts and exposes multiple mappings. One mapping ties artifacts to FIPS clauses or algorithm requirements. A second mapping ties the same artifacts to the SP guidance that explains how the system is operated or assessed. That makes reviews faster and prevents the team from rebuilding the same evidence for standards, labs, procurement, and engineering governance. - Use stable artifact IDs and owners - Map artifacts to both FIPS requirements and relevant SP guidance - Pin versions of standards and SPs used for decisions - Run one change-control process that evaluates impact on both mappings *Recommended next step* *Placement: after the comparison section* ## Use FIPS Standards Hub FIPS versus NIST SP series as a cited research workflow Research Copilot can take FIPS Standards Hub FIPS versus NIST SP series from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on FIPS Standards Hub can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for FIPS Standards Hub FIPS versus NIST SP series](/solutions/research-copilot.md): Start from FIPS Standards Hub FIPS versus NIST SP series and answer scope, timing, and interpretation questions with cited outputs. - [Talk through FIPS Standards Hub](/contact.md): Review your current process, evidence gaps, and next steps for FIPS Standards Hub FIPS versus NIST SP series. ## Primary sources - [FIPS 140-3 (Security Requirements for Cryptographic Modules)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf?ref=sorena.io) - Defines module requirements and references the SP 800-140 family used by CMVP. - [SP 800-175B Rev. 1](https://csrc.nist.gov/pubs/sp/800/175/b/r1/final) - Guideline for using cryptographic standards in the federal government. - [SP 800-89](https://csrc.nist.gov/pubs/sp/800/89/final) - Recommendation for obtaining assurances for digital signature applications. - [SP 800-208](https://csrc.nist.gov/pubs/sp/800/208/final) - Recommendation for stateful hash-based signature schemes. - [SP 800-227](https://csrc.nist.gov/pubs/sp/800/227/final) - Recommendations for key-encapsulation mechanisms. ## Related Topic Guides - [FIPS Standards FAQ (Procurement, CMVP, Evidence)](/artifacts/global/fips-standards-hub/faq.md): FIPS Standards FAQ for procurement, compliance, and crypto-engineering teams: what FIPS-compliant means, FIPS algorithms versus FIPS 140-3 validated modules. - [FIPS vs Common Criteria (CC) - What to Validate vs Evaluate](/artifacts/global/fips-standards-hub/fips-vs-common-criteria.md): Deep comparison of FIPS, especially FIPS 140-3 and CMVP, versus Common Criteria: scope differences, evidence overlap, and when procurement requires both. - [What Is Included in FIPS Standards Hub (FIPS 140-3, CMVP, FIPS Crypto)](/artifacts/global/fips-standards-hub/what-is-included.md): Coverage map for the FIPS Standards Hub: FIPS 140-3 cryptographic module requirements, CMVP context and guidance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-standards-hub/fips-vs-nist-sp-series --- --- title: "What Is Included in FIPS Standards Hub (FIPS 140-3, CMVP, FIPS Crypto)" canonical_url: "https://www.sorena.io/artifacts/global/fips-standards-hub/what-is-included" source_url: "https://www.sorena.io/artifacts/global/fips-standards-hub/what-is-included" author: "Sorena AI" description: "Coverage map for the FIPS Standards Hub: FIPS 140-3 cryptographic module requirements, CMVP context and guidance." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "what is included FIPS standards hub" - "FIPS 140-3 coverage" - "CMVP guidance" - "FIPS crypto algorithms coverage" - "AES FIPS 197" - "SHA-2 FIPS 180-4" - "SHA-3 FIPS 202" - "FIPS 186-5" - "FIPS 203" - "FIPS 204" - "FIPS 205" - "GLOBAL compliance" - "FIPS standards" - "FIPS 140-3" - "CMVP" - "FIPS crypto algorithms" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # What Is Included in FIPS Standards Hub (FIPS 140-3, CMVP, FIPS Crypto) Coverage map for the FIPS Standards Hub: FIPS 140-3 cryptographic module requirements, CMVP context and guidance. *Coverage map* *GLOBAL* ## FIPS Standards Hub What is included A coverage map for FIPS standards and validation reality: algorithms, modules, and evidence. Use this page to see which document to use for which question, and what evidence it tends to drive. FIPS-compliant is a phrase that hides multiple different things: using approved algorithms, building a cryptographic module that meets FIPS 140-3 requirements, and achieving validation through the CMVP. This hub is organized to remove that confusion. Below is what is included, what it is for, and how the pieces fit together into a defensible evidence and procurement story. ## The two layers: algorithms versus module validation Layer one is the algorithm layer. It includes AES, secure hash, digital signatures, and post-quantum primitives. These documents tell you what the primitive is and what algorithm-level requirements apply. Layer two is the module layer. FIPS 140-3 defines security requirements for cryptographic modules, and the CMVP validates modules against those requirements through labs, test evidence, and Security Policies. - Algorithm layer: what the primitive is and how it is specified - Module layer: how crypto is packaged, exposed as services, tested, and evidenced - Procurement reality: buyers often ask for the module-validation story, not just an algorithm name ## Included: FIPS 140-3 and CMVP program reality This hub includes FIPS 140-3, the CMVP program context, and the implementation-guidance layer that affects how real submissions are scoped and tested. That means you can use the hub to understand boundary, approved mode, services, self-tests, and the supporting SP 800-140 family used in the CMVP ecosystem. - FIPS 140-3 for module requirements and levels - CMVP for validation flow and certificate meaning - Implementation Guidance and SP 800-140 references for application detail *Recommended next step* *Placement: after the scope or definition section* ## Use FIPS Standards Hub What is included as a cited research workflow Research Copilot can take FIPS Standards Hub What is included from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on FIPS Standards Hub can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for FIPS Standards Hub What is included](/solutions/research-copilot.md): Start from FIPS Standards Hub What is included and answer scope, timing, and interpretation questions with cited outputs. - [Talk through FIPS Standards Hub](/contact.md): Review your current process, evidence gaps, and next steps for FIPS Standards Hub What is included. ## Included: the core FIPS crypto standards The hub includes the FIPS crypto standards most commonly referenced in product security, validation, and procurement work. Treat this as an implementation set: it helps you choose algorithms, set safe defaults, and create evidence-backed decisions. - FIPS 197 for AES - FIPS 180-4 and FIPS 202 for secure hash and XOF coverage - FIPS 186-5 for RSA, ECDSA, deterministic ECDSA, and EdDSA - FIPS 203, 204, and 205 for PQC key establishment and signatures ## Included: the related cryptographic NIST SP layer The hub also points to the cryptographic NIST SP ecosystem that makes the FIPS documents usable in practice. Those publications include the SP 800-140 family for CMVP use, SP 800-175B for applying cryptographic standards, SP 800-89 for signature-assurance methods, SP 800-208 for stateful hash-based signatures, and SP 800-227 for KEM guidance. These are not replacements for the FIPS standards. They are the companion guidance that helps teams implement, validate, and defend decisions. - SP 800-140 family for CMVP annex and documentation details - SP 800-175B for federal cryptographic standards usage guidance - SP 800-89 for digital-signature assurance - SP 800-208 and SP 800-227 for hash-based-signature and KEM guidance ## How to use this hub as a workflow This hub is designed as a workflow. If you follow it, you should end up with a crypto inventory, a list of allowed algorithms and parameters, an approved-mode story where relevant, and an evidence pack that makes audits and procurement responses predictable. Use the comparison pages to reduce program confusion: FIPS versus NIST SP and FIPS versus Common Criteria. - Inventory where crypto is used and who owns it - Select allowed algorithms, parameters, and migration patterns - Build evidence tied to scope and versions - Decide whether you need algorithm conformance evidence, module validation, product evaluation, or both ## Primary sources - [FIPS 140-3 (Security Requirements for Cryptographic Modules)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf?ref=sorena.io) - Primary standard defining security levels and requirement areas for cryptographic modules. - [NIST and CCCS CMVP program overview](https://csrc.nist.gov/projects/cryptographic-module-validation-program?ref=sorena.io) - Program context for how modules are tested and validated. - [Implementation Guidance for FIPS 140-3 and the CMVP](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Guidance used in practice by labs and vendors. - [FIPS 197 upd1 (AES)](https://doi.org/10.6028/NIST.FIPS.197-upd1?ref=sorena.io) - Primary AES algorithm standard reference. - [FIPS 180-4 (Secure Hash Standard)](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Primary SHA-2 family standard reference. - [FIPS 202 (SHA-3 Standard)](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Primary SHA-3 and SHAKE XOF standard reference. - [FIPS 186-5 (Digital Signature Standard)](https://doi.org/10.6028/NIST.FIPS.186-5?ref=sorena.io) - Primary signature standard reference. - [FIPS 203, 204, and 205](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - PQC FIPS entry point; see also FIPS 204 and FIPS 205. ## Related Topic Guides - [FIPS Standards FAQ (Procurement, CMVP, Evidence)](/artifacts/global/fips-standards-hub/faq.md): FIPS Standards FAQ for procurement, compliance, and crypto-engineering teams: what FIPS-compliant means, FIPS algorithms versus FIPS 140-3 validated modules. - [FIPS vs Common Criteria (CC) - What to Validate vs Evaluate](/artifacts/global/fips-standards-hub/fips-vs-common-criteria.md): Deep comparison of FIPS, especially FIPS 140-3 and CMVP, versus Common Criteria: scope differences, evidence overlap, and when procurement requires both. - [FIPS vs NIST SP Series (Standards vs Cryptographic Guidance)](/artifacts/global/fips-standards-hub/fips-vs-nist-sp-series.md): Deep comparison of FIPS standards versus NIST Special Publications in the cryptographic ecosystem: how they differ, how they are used together. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/fips-standards-hub/what-is-included --- --- title: "ISO 22301 Business Impact Analysis Template" canonical_url: "https://www.sorena.io/artifacts/global/iso-22301/business-impact-analysis-template" source_url: "https://www.sorena.io/artifacts/global/iso-22301/business-impact-analysis-template" author: "Sorena AI" description: "Use this ISO 22301 business impact analysis template to capture prioritized activities, impact tolerances, dependencies, recovery targets." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 22301 BIA template" - "ISO 22301 business impact analysis" - "business impact analysis template" - "BCMS BIA" - "continuity impact analysis" - "recovery target template" - "dependency mapping" - "continuity strategy inputs" - "ISO 22301 audit evidence" - "GLOBAL compliance" - "ISO 22301" - "Business impact analysis" - "BIA template" - "BCMS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 22301 Business Impact Analysis Template Use this ISO 22301 business impact analysis template to capture prioritized activities, impact tolerances, dependencies, recovery targets. *Template* *GLOBAL* ## ISO 22301 Business impact analysis template Use a BIA template that turns continuity interviews into defendable priorities, recovery targets, and strategy decisions. Aligned to Clause 8.2 so BIA outputs can flow into strategies, plans, exercises, and audit evidence. ISO 22301 puts business impact analysis inside the operational core of the BCMS. A useful BIA does three jobs at once: it identifies the activities and services that matter most, shows when disruption becomes unacceptable, and gives leadership enough evidence to approve continuity strategies and resource commitments. This template is designed for that outcome rather than for spreadsheet theater. ## What the ISO 22301 business impact analysis needs to produce The standard does not prescribe a single form, but the BIA has to create clear priorities that the organization can act on. Your template should therefore capture critical products and services, the activities and resources that support them, the consequences of disruption over time, and the points at which disruption becomes unacceptable. Keep one standard method across the BCMS scope. Consistent fields and scoring make it possible to compare business areas, justify strategy decisions, and show auditors that prioritization is controlled rather than subjective. - Link every row to the BCMS scope and named service or process owner - Capture impact over time, not only a generic criticality label - Record dependencies, assumptions, and known failure points alongside business impacts - Keep approval, review date, version, and evidence links on the same record ## Recommended BIA worksheet structure A strong ISO 22301 business impact analysis template usually works best as a short workbook with a controlled method tab and one repeatable analysis tab per service, process, or product line. Avoid oversized templates that invite inconsistent use across teams. Where teams already use terms such as recovery time objective or data loss tolerance, keep those definitions stable and document them once in the method tab so every assessment uses the same language. - Method tab: scope, definitions, scoring model, approval rules, and review triggers - Service inventory tab: product or service, supporting activities, owner, customer commitments, locations, and regulated obligations - Impact tab: financial, customer, safety, legal, operational, and reputational consequences at staged disruption intervals - Dependency tab: people, facilities, applications, infrastructure, suppliers, data, communications, and manual workarounds - Recovery tab: minimum acceptable delivery level, target restoration sequence, required resources, and strategy notes - Evidence tab: architecture links, incident history, supplier commitments, test results, and prior corrective actions ## Field set for each ISO 22301 business impact analysis entry The field list below is intentionally detailed. Most organizations can simplify it later, but starting with a richer template prevents the common failure mode where continuity priorities are based on opinion rather than evidence. Ask each owner to justify material ratings in plain language. That short explanation is often the most valuable audit evidence in the whole workbook because it shows why a priority exists and what assumptions support it. - Service or process name, description, owner, supporting teams, and in-scope locations - Primary customers or internal consumers, contractual commitments, and regulatory dependencies - Triggering events or disruption types that would materially affect delivery - Impacts at defined time intervals such as immediate, same day, next day, and multi-day disruption - Critical inputs and upstream dependencies, including single points of failure and fragile supplier dependencies - Fallback options, degraded service options, and manual workaround limits - Required recovery sequence, required skills, required systems access, and required supplier support - Assumptions, open risks, unresolved gaps, and date of last validation ## How to turn BIA outputs into continuity strategy A BIA is not complete when the worksheet is filled out. It becomes useful when the organization uses it to select continuity strategies and solutions under Clause 8.3. That means explicitly choosing what capacity to preserve, what alternate arrangements are needed, and what resources must be approved in advance. Keep a short decision record for each high-priority service. Note the selected strategy, rejected alternatives, budget or resource implications, and the plan or procedure that has been updated as a result. - Traceability path: BIA result to strategy selection to plan update to exercise scenario to corrective action - Record who approved each continuity strategy and what assumptions remain untested - Refresh the BIA after significant business, architecture, supplier, or incident changes - Use exercise results to verify whether BIA assumptions still hold in practice *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep ISO 22301 Business impact analysis template in one governed evidence system SSOT can take ISO 22301 Business impact analysis template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on ISO 22301 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for ISO 22301 Business impact analysis template](/solutions/ssot.md): Start from ISO 22301 Business impact analysis template and keep documents, evidence, and control records in one governed system. - [Talk through ISO 22301](/contact.md): Review your current process, evidence gaps, and next steps for ISO 22301 Business impact analysis template. ## Primary sources - [ISO 22301:2019 standard page](https://www.iso.org/standard/75106.html?ref=sorena.io) - Primary overview for ISO 22301, including the 2019 edition and lifecycle details. - [ISO 22313:2020 guidance page](https://www.iso.org/standard/75107.html?ref=sorena.io) - Guidance companion for applying ISO 22301. ISO states this guidance remained current when reviewed in 2025. - [ISO 22301 business continuity brochure](https://www.iso.org/files/live/sites/isoorg/files/store/en/PUB100442.pdf) - Public ISO brochure that explains who ISO 22301 is for, integration with other management systems, and implementation starting points. ## Related Topic Guides - [ISO 22301 Compliance Playbook](/artifacts/global/iso-22301/compliance.md): A practical ISO 22301 compliance playbook for implementing a business continuity management system: context, leadership, planning, support. - [ISO 22301 FAQ](/artifacts/global/iso-22301/faq.md): Direct answers to common ISO 22301 questions on BCMS scope, BIA, plans, exercises, certification, audit evidence. - [ISO 22301 Testing and Exercises](/artifacts/global/iso-22301/testing-and-exercises.md): Practical ISO 22301 testing and exercises guidance for designing an exercise programme, evaluating continuity documentation and capabilities. - [ISO 22301 vs DORA](/artifacts/global/iso-22301/iso-22301-vs-dora.md): Compare ISO 22301 and DORA to see where a business continuity management system supports digital operational resilience and where DORA adds binding ICT. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-22301/business-impact-analysis-template --- --- title: "ISO 22301 Compliance Playbook" canonical_url: "https://www.sorena.io/artifacts/global/iso-22301/compliance" source_url: "https://www.sorena.io/artifacts/global/iso-22301/compliance" author: "Sorena AI" description: "A practical ISO 22301 compliance playbook for implementing a business continuity management system: context, leadership, planning, support." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 22301 compliance" - "ISO 22301 implementation" - "ISO 22301 certification readiness" - "ISO 22301 audit readiness" - "BCMS implementation" - "business continuity management system" - "BIA" - "continuity strategy" - "exercise programme" - "management review" - "GLOBAL compliance" - "ISO 22301" - "BCMS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 22301 Compliance Playbook A practical ISO 22301 compliance playbook for implementing a business continuity management system: context, leadership, planning, support. *Playbook* *GLOBAL* ## ISO 22301 Compliance playbook Implement ISO 22301 as a real BCMS with clause-specific ownership, continuity decisions, and evidence that stays current. Built around the 2019 edition, where the continuity-specific requirements are concentrated in Clause 8. ISO 22301 compliance means more than keeping a business continuity plan in a shared folder. The standard expects a business continuity management system that is planned, implemented, operated, monitored, reviewed, maintained, and improved. The 2019 edition did not add new requirements compared with the 2012 edition, but it clarified them and restructured Clause 8 so teams can better understand how business impact analysis, risk assessment, continuity strategies, plans, exercises, and capability evaluation fit together. ## What ISO 22301 requires in practical terms ISO 22301 is a management system standard for business continuity. In practice, that means you need governance, objectives, controlled documentation, operational continuity processes, and a review and improvement loop. Certification is optional, but the standard's operating discipline is the same whether you certify or not. The fastest way to implement ISO 22301 well is to treat it as a delivery system for continuity decisions. Every clause should produce a tangible output that leaders can approve, operators can use, and auditors can trace. - Clauses 4 to 7 define the management system foundation - Clause 8 holds the continuity-specific operational work - Clauses 9 and 10 prove the BCMS is reviewed and improved over time - A strong evidence model links scope, priorities, plans, exercises, findings, and approvals ## Clauses 4 to 6: context, leadership, planning Start by defining the BCMS scope, the interested parties that matter to continuity decisions, and the products and services whose disruption would materially affect the organization. This is where weak programs usually fail first. If scope is vague, every later artifact becomes harder to justify. Leadership then has to approve policy, assign responsibilities and authorities, and set business continuity objectives. Planning should address both BCMS risks and opportunities, along with how changes to the BCMS will be controlled when the business, technology stack, or supplier landscape changes. - Core outputs: context summary, interested parties, scope statement, BC policy, responsibilities, objectives, BCMS change planning - Useful evidence: approval records, review cadence, objective tracking, and named owners for critical continuity activities - Implementation rule: scope the BCMS around real delivery commitments, not around generic organization charts ## Clause 7: support, competence, communication, documented information Support clauses are where a BCMS becomes operational rather than aspirational. People who will respond under disruption need defined competence, awareness, and access to the correct information at the right time. Communications also need explicit planning because many continuity failures are communication failures before they are technology failures. Treat documented information as controlled operational material. Plans, procedures, contact lists, and exercise records should have owners, versions, approval state, and review triggers. - Core outputs: resource model, competence matrix, awareness plan, communication model, document control rules - Evidence: training records, plan distribution controls, version history, communication drill outputs - Practical test: can the right team reach the right plan version quickly during a live disruption ## Clause 8: BIA, risk assessment, strategies, plans, exercises, capability evaluation Clause 8 is the operational center of ISO 22301. It starts with business impact analysis and risk assessment, then moves into business continuity strategies and solutions, implementation of those solutions, business continuity plans and procedures, the exercise programme, and evaluation of business continuity documentation and capabilities. This clause is where continuity work becomes concrete. The organization should be able to show how disruption priorities were identified, how recovery approaches were selected, what resources those approaches require, how plans are structured, how they are exercised, and how weaknesses are corrected. - BIA outputs: prioritized activities, consequence over time, key dependencies, recovery targets, and continuity assumptions - Risk assessment outputs: disruption scenarios, control gaps, residual exposure, and accepted assumptions - Strategy outputs: alternate arrangements, minimum capacity choices, supplier contingencies, and resource commitments - Plan outputs: response structure, warning and communication procedures, continuity procedures, recovery procedures - Proof outputs: exercise programme, documentation evaluation, capability findings, improvement actions ## Clauses 9 and 10: monitoring, internal audit, management review, improvement ISO 22301 expects the BCMS to be measured and reviewed. Monitoring and measurement should cover both programme health and operational readiness. Internal audit should test whether the BCMS is implemented and maintained as intended. Management review should examine performance, changes, findings, and improvement priorities. Clause 10 then expects you to handle nonconformities and continually improve the system. If you only update plans after a major incident, you are underusing the standard. The better pattern is to feed exercise results, audit findings, supplier changes, and architecture changes into a single improvement workflow with ownership and due dates. - Essential evidence: metrics, internal audit records, management review minutes, corrective actions, closure evidence - Low-friction operating model: one resilience action register used by continuity, technology, security, and risk owners - Audit-ready test: can you show the last review, the last finding, the owner, and the current closure status for each material gap *Recommended next step* *Placement: after the compliance steps* ## Turn ISO 22301 Compliance playbook into an operational assessment Assessment Autopilot can take ISO 22301 Compliance playbook from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on ISO 22301 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 22301 Compliance playbook](/solutions/assessment.md): Start from ISO 22301 Compliance playbook and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 22301](/contact.md): Review your current process, evidence gaps, and next steps for ISO 22301 Compliance playbook. ## Primary sources - [ISO 22301:2019 standard page](https://www.iso.org/standard/75106.html?ref=sorena.io) - Primary overview for ISO 22301, including publication date, lifecycle, and the current standard status page. - [ISO 22313:2020 guidance page](https://www.iso.org/standard/75107.html?ref=sorena.io) - Guidance on using ISO 22301. ISO states this publication remained current when reviewed in 2025. - [ISO 22301 business continuity brochure](https://www.iso.org/files/live/sites/isoorg/files/store/en/PUB100442.pdf) - Public brochure describing benefits, integration, implementation starting points, and certification context. ## Related Topic Guides - [ISO 22301 Business Impact Analysis Template](/artifacts/global/iso-22301/business-impact-analysis-template.md): Use this ISO 22301 business impact analysis template to capture prioritized activities, impact tolerances, dependencies, recovery targets. - [ISO 22301 FAQ](/artifacts/global/iso-22301/faq.md): Direct answers to common ISO 22301 questions on BCMS scope, BIA, plans, exercises, certification, audit evidence. - [ISO 22301 Testing and Exercises](/artifacts/global/iso-22301/testing-and-exercises.md): Practical ISO 22301 testing and exercises guidance for designing an exercise programme, evaluating continuity documentation and capabilities. - [ISO 22301 vs DORA](/artifacts/global/iso-22301/iso-22301-vs-dora.md): Compare ISO 22301 and DORA to see where a business continuity management system supports digital operational resilience and where DORA adds binding ICT. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-22301/compliance --- --- title: "ISO 22301 FAQ" canonical_url: "https://www.sorena.io/artifacts/global/iso-22301/faq" source_url: "https://www.sorena.io/artifacts/global/iso-22301/faq" author: "Sorena AI" description: "Direct answers to common ISO 22301 questions on BCMS scope, BIA, plans, exercises, certification, audit evidence." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 22301 FAQ" - "ISO 22301 questions" - "business continuity management system" - "BCMS" - "ISO 22301 certification" - "ISO 22301 audit" - "ISO 22301 BIA" - "ISO 22301 exercises" - "GLOBAL compliance" - "ISO 22301" - "FAQ" - "Business continuity" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 22301 FAQ Direct answers to common ISO 22301 questions on BCMS scope, BIA, plans, exercises, certification, audit evidence. *FAQ* *GLOBAL* ## ISO 22301 FAQ Clear answers to the ISO 22301 questions continuity teams, auditors, and leaders ask most often. Use the linked guides when you need implementation detail, templates, or mappings. Most ISO 22301 questions come down to two things: what the standard expects, and what evidence proves you are actually operating a BCMS. This FAQ focuses on both so teams can move quickly from clause reading to implementation decisions. ## What is ISO 22301? ISO 22301 is the international standard for a business continuity management system. It provides a framework to plan, establish, implement, operate, monitor, review, maintain, and continually improve documented business continuity capabilities. The current core edition is the second edition published in 2019. ISO states the standard remains published and is currently at a review stage in its lifecycle. - Use it to govern continuity across business, technology, suppliers, and recovery operations - Treat it as a management system, not only as a continuity plan requirement ## Does ISO 22301 require certification? No. Certification can be useful, but certification is not required by the standard itself. The real requirement is to operate the BCMS effectively and maintain evidence that it is controlled, reviewed, and improved. If certification is a goal, start by building traceability rather than by collecting templates. Auditors usually move from clause requirements to operating evidence and expect to see clear ownership and current records. - Certification is optional - Evidence discipline is not optional if you want the BCMS to be credible - Good audit evidence is current, attributable, controlled, and linked to scope and objectives ## Does ISO 22301 require business impact analysis and risk assessment? Yes. Clause 8 includes both business impact analysis and risk assessment. Together they support continuity strategy selection, plan content, and exercise design. A good implementation keeps the two distinct. The business impact analysis tells you what disruption matters most and when it becomes unacceptable. The risk assessment tells you what disruption scenarios and control weaknesses need to be addressed. - BIA drives priorities and recovery targets - Risk assessment drives scenario coverage and mitigation - Both should be refreshed when business, architecture, supplier, or incident conditions change ## What is the difference between a BCMS and a business continuity plan? A business continuity plan is only one output inside the BCMS. The BCMS includes governance, policy, scope, competence, documented information, BIA, risk assessment, strategies, plans, exercises, internal audit, management review, and continual improvement. If you only maintain plans and call trees, you do not yet have an ISO 22301 operating model. - Plans matter, but so do ownership, review cadence, and evidence of use - Exercises and corrective actions are what show the BCMS is alive ## How often should we run ISO 22301 exercises? ISO 22301 requires an exercise programme, but it does not prescribe a single universal frequency. The right cadence depends on criticality, change rate, supplier dependence, and how much untested recovery logic you carry. In practice, critical services and critical dependencies should be exercised more often than lower-impact areas. Tie exercise frequency to BIA priority and recent change. - Use an annual programme with differentiated coverage based on criticality - Exercise after major platform, supplier, location, or organizational changes - Keep results, findings, and plan updates under document control ## What evidence do ISO 22301 auditors usually request? Auditors usually want to see evidence across the full BCMS lifecycle. That includes scope and policy, roles and objectives, BIA and risk assessment outputs, strategy decisions, plans and procedures, exercise results, internal audits, management reviews, and corrective actions. The best evidence pack is clause-shaped and current. Each major clause should map to one or more owned artifacts plus proof of recent operation. - Scope statement, policy, roles, objectives, and controlled documents - BIA outputs, risk assessment outputs, strategy approvals, and implementation decisions - Response, warning, communication, continuity, and recovery procedures - Exercise reports, audit reports, management review minutes, and action closure evidence ## How does ISO 22301 support operational resilience and DORA work? ISO 22301 gives you the management system and continuity discipline that many resilience programs need. It is especially strong at prioritization, continuity strategy, recovery planning, and improvement loops. For financial entities, DORA adds binding ICT-specific obligations that ISO 22301 does not cover in the same detail, such as ICT incident reporting, ICT third-party oversight, and more specific testing requirements. - Use ISO 22301 as the continuity backbone - Layer DORA-specific ICT artifacts on top where required - Reuse dual-purpose evidence where scope and specificity are clear *Recommended next step* *Placement: after the FAQ section* ## Use ISO 22301 FAQ as a cited research workflow Research Copilot can take ISO 22301 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on ISO 22301 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO 22301 FAQ](/solutions/research-copilot.md): Start from ISO 22301 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO 22301](/contact.md): Review your current process, evidence gaps, and next steps for ISO 22301 FAQ. ## Primary sources - [ISO 22301:2019 standard page](https://www.iso.org/standard/75106.html?ref=sorena.io) - Primary overview for ISO 22301, including publication details, lifecycle, and amendment listing. - [ISO 22313:2020 guidance page](https://www.iso.org/standard/75107.html?ref=sorena.io) - Companion guidance for implementing ISO 22301. - [ISO 22301 business continuity brochure](https://www.iso.org/files/live/sites/isoorg/files/store/en/PUB100442.pdf) - Public brochure that explains intended users, implementation starting points, integration, and certification context. ## Related Topic Guides - [ISO 22301 Business Impact Analysis Template](/artifacts/global/iso-22301/business-impact-analysis-template.md): Use this ISO 22301 business impact analysis template to capture prioritized activities, impact tolerances, dependencies, recovery targets. - [ISO 22301 Compliance Playbook](/artifacts/global/iso-22301/compliance.md): A practical ISO 22301 compliance playbook for implementing a business continuity management system: context, leadership, planning, support. - [ISO 22301 Testing and Exercises](/artifacts/global/iso-22301/testing-and-exercises.md): Practical ISO 22301 testing and exercises guidance for designing an exercise programme, evaluating continuity documentation and capabilities. - [ISO 22301 vs DORA](/artifacts/global/iso-22301/iso-22301-vs-dora.md): Compare ISO 22301 and DORA to see where a business continuity management system supports digital operational resilience and where DORA adds binding ICT. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-22301/faq --- --- title: "ISO 22301 vs DORA" canonical_url: "https://www.sorena.io/artifacts/global/iso-22301/iso-22301-vs-dora" source_url: "https://www.sorena.io/artifacts/global/iso-22301/iso-22301-vs-dora" author: "Sorena AI" description: "Compare ISO 22301 and DORA to see where a business continuity management system supports digital operational resilience and where DORA adds binding ICT." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 22301 vs DORA" - "DORA vs ISO 22301" - "ISO 22301 DORA mapping" - "business continuity management system" - "digital operational resilience" - "DORA compliance" - "operational resilience framework" - "GLOBAL compliance" - "ISO 22301" - "DORA" - "Operational resilience" - "Business continuity" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 22301 vs DORA Compare ISO 22301 and DORA to see where a business continuity management system supports digital operational resilience and where DORA adds binding ICT. *Artifact Guide* *GLOBAL* ## ISO 22301 ISO 22301 vs DORA Use ISO 22301 for continuity governance and recovery discipline, then add the ICT-specific controls and regulatory obligations DORA requires. This page focuses on evidence reuse, scope boundaries, and where teams need separate DORA artifacts. ISO 22301 and DORA overlap, but they do different jobs. ISO 22301 is a voluntary management system standard for business continuity. DORA is an EU regulation for the financial sector that has applied since 17 January 2025 and sets binding requirements for digital operational resilience. A strong ISO 22301 implementation can carry a large part of the continuity workload for DORA, but it will not by itself satisfy DORA's ICT-specific incident, testing, and third-party obligations. ## What each framework is designed to do ISO 22301 is designed to establish and improve a business continuity management system. It focuses on scope, governance, business impact analysis, risk assessment, continuity strategies and solutions, business continuity plans and procedures, exercise programmes, and continual improvement. DORA is designed to make financial entities resilient against ICT-related disruption. It is more prescriptive about ICT risk management, major ICT-related incident management and reporting, digital operational resilience testing, and ICT third-party risk management. - ISO 22301 strength: continuity operating model and management system discipline - DORA strength: binding sector-specific ICT resilience obligations and supervisory oversight - Practical approach: use one resilience operating model, but keep DORA-specific artifacts where the regulation is more explicit ## Where ISO 22301 directly supports DORA A mature ISO 22301 program gives DORA programmes a strong base. It creates scope discipline, named responsibilities, prioritized services, recovery assumptions, documented response and recovery procedures, exercise evidence, and a management review loop. These outputs are directly useful because DORA also expects firms to know what matters most, recover in a controlled way, test capabilities, and demonstrate governance and oversight. - Governance and ownership for continuity and resilience activities - BIA-informed recovery priorities and service restoration logic - Documented response, communication, and recovery procedures - Exercise outputs, lessons learned, and tracked remediation actions ## Where DORA goes further than ISO 22301 DORA is narrower in sector scope but deeper in ICT detail. It requires financial entities to build ICT risk management capabilities, manage and report major ICT-related incidents, maintain specific third-party ICT risk controls, and in some cases conduct advanced testing such as threat-led penetration testing. These are not replaced by a BCMS. They have to be addressed as dedicated DORA workstreams, even if the continuity foundation comes from ISO 22301. - ICT incident classification, escalation, and regulatory reporting - Detailed ICT control environment and resilience governance - Third-party ICT registers, contractual controls, and oversight activities - DORA-specific testing expectations and supervisory evidence ## How to reuse evidence without creating parallel programs The cleanest implementation pattern is to maintain one resilience evidence set with two indexes. One index maps to ISO 22301 clauses. The second maps to DORA articles and relevant technical standards. Dual-use documents can then support both, while truly DORA-specific artifacts remain separate and explicit. This approach reduces duplication and avoids the common failure mode where teams rewrite the same continuity content three times for audit, resilience, and regulatory review. - Dual-use artifacts: governance model, RACI, BIA outputs, continuity strategies, response and recovery procedures, exercise reports, action register, management review - DORA-only artifacts: incident reporting procedure, major incident criteria, ICT third-party register, DORA testing records, supervisory submission artifacts - Control rule: if an artifact serves both regimes, state the scope and audience clearly in the document itself ## When ISO 22301 is enough, and when it is not For non-financial organizations, ISO 22301 may be the full target state for continuity governance. For financial entities in scope of DORA, ISO 22301 is best treated as a foundational standard that improves the quality and maturity of continuity work but does not replace the regulation. If your organization is pursuing both, use ISO 22301 to stabilize continuity and recovery practice, then use DORA to define the regulated ICT overlays and supervisory evidence requirements. - ISO 22301 alone can be a complete BCMS target for many organizations - DORA in-scope entities need additional regulated ICT controls and reporting layers - The strongest approach is integrated governance with explicit DORA overlays *Recommended next step* *Placement: after the comparison section* ## Use ISO 22301 ISO 22301 vs DORA as a cited research workflow Research Copilot can take ISO 22301 ISO 22301 vs DORA from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on ISO 22301 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO 22301 ISO 22301 vs DORA](/solutions/research-copilot.md): Start from ISO 22301 ISO 22301 vs DORA and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO 22301](/contact.md): Review your current process, evidence gaps, and next steps for ISO 22301 ISO 22301 vs DORA. ## Primary sources - [ISO 22301:2019 standard page](https://www.iso.org/standard/75106.html?ref=sorena.io) - Primary source for the ISO 22301 standard overview and lifecycle details. - [Regulation (EU) 2022/2554 on digital operational resilience](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32022R2554) - Official DORA legal text on EUR-Lex. - [EUR-Lex DORA summary](https://eur-lex.europa.eu/legal-content/EN/LSU/?uri=oj:JOL_2022_333_R_0001) - Official summary page stating that DORA has applied since 17 January 2025. ## Related Topic Guides - [ISO 22301 Business Impact Analysis Template](/artifacts/global/iso-22301/business-impact-analysis-template.md): Use this ISO 22301 business impact analysis template to capture prioritized activities, impact tolerances, dependencies, recovery targets. - [ISO 22301 Compliance Playbook](/artifacts/global/iso-22301/compliance.md): A practical ISO 22301 compliance playbook for implementing a business continuity management system: context, leadership, planning, support. - [ISO 22301 FAQ](/artifacts/global/iso-22301/faq.md): Direct answers to common ISO 22301 questions on BCMS scope, BIA, plans, exercises, certification, audit evidence. - [ISO 22301 Testing and Exercises](/artifacts/global/iso-22301/testing-and-exercises.md): Practical ISO 22301 testing and exercises guidance for designing an exercise programme, evaluating continuity documentation and capabilities. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-22301/iso-22301-vs-dora --- --- title: "ISO 22301 Testing and Exercises" canonical_url: "https://www.sorena.io/artifacts/global/iso-22301/testing-and-exercises" source_url: "https://www.sorena.io/artifacts/global/iso-22301/testing-and-exercises" author: "Sorena AI" description: "Practical ISO 22301 testing and exercises guidance for designing an exercise programme, evaluating continuity documentation and capabilities." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 22301 testing and exercises" - "ISO 22301 exercise programme" - "business continuity exercises" - "BCMS testing" - "continuity exercise evidence" - "recovery exercise" - "tabletop exercise" - "ISO 22301 audit evidence" - "GLOBAL compliance" - "ISO 22301" - "BCMS" - "Exercises" - "Audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 22301 Testing and Exercises Practical ISO 22301 testing and exercises guidance for designing an exercise programme, evaluating continuity documentation and capabilities. *Program* *GLOBAL* ## ISO 22301 Testing and exercises Build an ISO 22301 exercise programme that validates plans, tests capabilities, and drives measurable improvement. Centered on Clause 8.5 exercise programme and Clause 8.6 evaluation of documentation and capabilities. ISO 22301 does not stop at writing continuity procedures. It expects organizations to run an exercise programme and evaluate both the documentation and the actual capability to continue and recover. That is why exercises are some of the highest-value evidence in a BCMS. They show whether priorities are realistic, whether teams can coordinate under pressure, and whether the recovery design still works after business and technology changes. ## What ISO 22301 expects from testing and exercises The standard separates exercising from broader evaluation of documentation and capability. That matters in practice. A BCMS should test not only whether teams can perform a scenario, but also whether the underlying plans, call trees, assumptions, and procedures are current and usable. Treat the exercise programme as an operational control, not an annual ceremonial event. The programme should reflect BCMS scope, BIA priorities, major dependencies, and recent change. - Exercise the most important services and dependencies more often than lower-priority areas - Evaluate both document quality and real execution capability - Use results to update plans, training, ownership, and strategy assumptions *Recommended next step* *Placement: after the workflow or playbook section* ## Turn ISO 22301 Testing and exercises into an operational assessment Assessment Autopilot can take ISO 22301 Testing and exercises from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on ISO 22301 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 22301 Testing and exercises](/solutions/assessment.md): Start from ISO 22301 Testing and exercises and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 22301](/contact.md): Review your current process, evidence gaps, and next steps for ISO 22301 Testing and exercises. ## How to design an ISO 22301 exercise programme Start with the BIA and risk assessment. They tell you which services matter most, which dependencies are fragile, and what disruption scenarios are worth testing. From there, create an annual programme that balances coverage and depth. Avoid relying on one exercise type. Tabletop sessions are useful for decision-making and communication, but they do not prove technical or supplier recovery capability by themselves. - Use a named annual exercise plan with scope, owners, target dates, and target services - Mix exercise types such as tabletop, recovery drills, supplier disruption tests, crisis coordination simulations, and end-to-end restoration tests - Tie exercise frequency to service criticality, rate of change, and untested assumptions - Define what evidence must be produced for every exercise before the exercise starts ## Scenario design that produces useful evidence Exercise scenarios should reflect real constraints. If a scenario assumes unlimited staff, perfect communications, or instant supplier support, it is unlikely to prove much. Better scenarios stress the assumptions that matter to continuity outcomes. Keep each scenario linked to one or more BIA priorities and one or more risk assessment items. That makes coverage explainable and repeatable. - Document the affected services, dependencies, assumed constraints, decision points, and target restoration outcomes - Include communication triggers, leadership decisions, external dependencies, and fallback options - Record what was expected, what happened, what evidence was collected, and what remains unproven ## Minimum evidence set for each exercise You do not need a heavy reporting pack for every event, but you do need enough structure that an auditor or leader can understand what was tested, what happened, and what changed afterward. Standardize the format so your programme can be compared over time. That also makes internal audit and management review easier. - Exercise brief with scope, objectives, participants, and scenario summary - Execution record with timeline, key decisions, deviations, and observed issues - Results summary with what worked, what failed, and what remains partially tested - Corrective actions with owners, due dates, and linked plan or procedure updates - Version history showing the affected plans or procedures were updated after material findings ## How to convert exercise results into continual improvement Exercise value is realized only when findings drive changes. Feed each material gap into one action workflow with a named owner, target date, and closure evidence. Then bring those results into management review so leadership can make resourcing or strategy decisions where needed. This loop is where ISO 22301 becomes a management system rather than a testing calendar. - Track repeated failures or unclosed actions as BCMS risk indicators - Update the BIA, risk assessment, strategy assumptions, or training plan if exercise results show drift - Review coverage annually to confirm the exercise programme still reflects current scope and change ## Primary sources - [ISO 22301:2019 standard page](https://www.iso.org/standard/75106.html?ref=sorena.io) - Primary source for the ISO 22301 standard and its lifecycle details. - [ISO 22313:2020 guidance page](https://www.iso.org/standard/75107.html?ref=sorena.io) - Companion guidance for applying ISO 22301, useful for exercise and evaluation design. - [ISO 22301 business continuity brochure](https://www.iso.org/files/live/sites/isoorg/files/store/en/PUB100442.pdf) - Public brochure that recommends readiness assessment and recovery exercises as starting points for implementation. ## Related Topic Guides - [ISO 22301 Business Impact Analysis Template](/artifacts/global/iso-22301/business-impact-analysis-template.md): Use this ISO 22301 business impact analysis template to capture prioritized activities, impact tolerances, dependencies, recovery targets. - [ISO 22301 Compliance Playbook](/artifacts/global/iso-22301/compliance.md): A practical ISO 22301 compliance playbook for implementing a business continuity management system: context, leadership, planning, support. - [ISO 22301 FAQ](/artifacts/global/iso-22301/faq.md): Direct answers to common ISO 22301 questions on BCMS scope, BIA, plans, exercises, certification, audit evidence. - [ISO 22301 vs DORA](/artifacts/global/iso-22301/iso-22301-vs-dora.md): Compare ISO 22301 and DORA to see where a business continuity management system supports digital operational resilience and where DORA adds binding ICT. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-22301/testing-and-exercises --- --- title: "ISO 27001 Audit Readiness" canonical_url: "https://www.sorena.io/artifacts/global/iso-27001/audit-readiness" source_url: "https://www.sorena.io/artifacts/global/iso-27001/audit-readiness" author: "Sorena AI" description: "Prepare for ISO/IEC 27001 audits with a structured evidence pack, SoA traceability, internal audit and management review outputs." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27001 audit readiness" - "ISO 27001 certification readiness" - "ISO 27001 evidence pack" - "ISO 27001 Stage 1" - "ISO 27001 Stage 2" - "ISO 27001 multi-site audit" - "ISO 27001 remote audit" - "ISO 27001 SoA audit" - "GLOBAL compliance" - "ISO/IEC 27001" - "Audit readiness" - "Certification" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27001 Audit Readiness Prepare for ISO/IEC 27001 audits with a structured evidence pack, SoA traceability, internal audit and management review outputs. *Audit* *GLOBAL* ## ISO 27001 Audit readiness Build an evidence pack that an ISO 27001 auditor can sample quickly and trust. Updated for the 2022 edition, current certification guidance, multi-site audits, and the current IAF ICT auditing document. ISO 27001 audit readiness is a traceability problem before it is a documentation problem. Auditors want to see that scope, risk criteria, risk treatment, the Statement of Applicability, control operation records, internal audits, management reviews, and corrective actions all tell the same story. As of 2026, organizations should be preparing against ISO/IEC 27001:2022, because the transition from the 2013 edition is complete. ## Start with one audit index, not a folder maze The cleanest evidence model is one audit index document that maps Clauses 4 to 10 and the Statement of Applicability to named artifacts, evidence locations, owners, and last review dates. That gives auditors a stable way to sample and gives your team a stable way to maintain the ISMS between audits. Keep the index current. The most common readiness problem is not missing content but stale content that no longer reflects how the ISMS actually operates. - Clause view: scope, policy, risk method, objectives, support records, operational records, monitoring, internal audit, management review, corrective actions - SoA view: each selected control, implementation status, owner, evidence source, and linked treatment decision - Maintenance rule: every indexed artifact should show owner, version, approval state, and last review date ## What auditors usually test first Most ISO 27001 audits start with scope, risk methodology, risk register, risk treatment decisions, and the Statement of Applicability. Auditors then select samples from the SoA and trace them into records that prove the controls operate as claimed. The easiest way to reduce audit friction is to prepare a small set of end-to-end traceability walkthroughs for material risks. - Traceability walkthrough: risk to treatment option to selected control to implementation record to monitoring or review output - Priority checks: residual risk approval, justification for excluded Annex A controls, and evidence that implementation status matches reality - Readiness test: if a control is marked implemented in the SoA, the owner should be able to show current operation evidence immediately ## Current certification context in 2026 The transition document for ISO/IEC 27001:2022 treated the move from the 2013 edition as a 36-month transition. That period has now ended, so organizations presenting a certificate or preparing for surveillance or recertification should expect the 2022 edition to be the baseline. The certification-body side is now anchored by ISO/IEC 27006-1:2024, which sets the additional requirements for bodies that audit and certify ISMS in accordance with ISO/IEC 27001. - Audit preparation should assume the 2022 standard, not the 2013 control structure - Certification credibility depends on an accredited certification body operating under the relevant IAF and accreditation rules - Certificate checks can be verified through accreditation and certification lookup tools such as IAF CertSearch where available ## Multi-site and remote audit readiness If you operate one management system across multiple sites, audit planning may follow the IAF multi-site methodology. That means your central governance has to be strong enough that a sampled audit still gives confidence across the listed scope and sites. Remote auditing remains common, but it is not informal. The current IAF ICT document expects conformity assessment activities that use ICT to preserve security, confidentiality, and the integrity of the audit process. - Multi-site readiness: common processes, central oversight, clear local responsibilities, and site-specific evidence where needed - Remote audit readiness: secure evidence-sharing, controlled screen access, confidentiality protections, and a defined protocol for logs and sensitive records - Virtual-site readiness: know which processes can be audited effectively through ICT and which still require physical-site evidence ## Common findings to remove before the audit Most audit findings are consistency failures, not grand design failures. The SoA says one thing, the risk treatment plan says another, and the records show a third. Fix those alignment gaps before the auditor finds them. Run an internal audit or readiness review using external-auditor logic rather than using the internal team as a comfort check. - SoA implementation status does not match available records - Residual risk acceptance is missing or not attributable to the right risk owner - Scope, risk register, supplier inventory, and control evidence do not align - Internal audit and management review exist on paper but do not drive corrective actions to closure *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep ISO 27001 Audit readiness in one governed evidence system SSOT can take ISO 27001 Audit readiness from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on ISO 27001 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for ISO 27001 Audit readiness](/solutions/ssot.md): Start from ISO 27001 Audit readiness and keep documents, evidence, and control records in one governed system. - [Talk through ISO 27001](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27001 Audit readiness. ## Primary sources - [ISO/IEC 27001:2022 standard page](https://www.iso.org/standard/27001?ref=sorena.io) - Primary source for the current ISO/IEC 27001 edition, amendment listing, and lifecycle status. - [ISO/IEC 27006-1:2024 standard page](https://www.iso.org/standard/82908.html?ref=sorena.io) - Current standard for bodies providing audit and certification of ISMS. - [IAF MD 26 transition requirements for ISO/IEC 27001:2022](https://iaf.nu/en/iaf-documents/mandatory-documents/md-26-transition-requirements-for-iso-iec-270012022/) - Current transition document that defined the move from ISO/IEC 27001:2013 to ISO/IEC 27001:2022. - [IAF MD 1 multi-site audit document](https://iaf.nu/en/iaf-documents/mandatory-documents/iaf-md-12023-issue-3/) - Mandatory document for audit and certification of a management system operated by a multi-site organization. - [IAF MD 4 ICT use for conformity assessment](https://iaf.nu/en/iaf-documents/mandatory-documents/iaf-md-42025-issue-3/) - Current IAF document for using ICT in conformity assessment activities, with application date 30 January 2026. - [IAF CertSearch overview](https://iaf.nu/en/certsearch/) - IAF explains how accredited certificate checks and monitoring work through CertSearch. ## Related Topic Guides - [ISO 27001 Compliance Playbook](/artifacts/global/iso-27001/compliance.md): Implement ISO/IEC 27001:2022 with a practical ISMS playbook for scope, risk assessment, risk treatment, Statement of Applicability, Annex A alignment. - [ISO 27001 FAQ](/artifacts/global/iso-27001/faq.md): Clear answers to common ISO/IEC 27001:2022 questions on the Statement of Applicability, Annex A, risk treatment, certification, audit evidence. - [ISO 27001 Implementation Roadmap](/artifacts/global/iso-27001/implementation-roadmap.md): A practical ISO/IEC 27001:2022 implementation roadmap with phases, gates, scope decisions, risk and SoA milestones, control rollout priorities. - [ISO 27001 Requirements and Evidence](/artifacts/global/iso-27001/requirements.md): Understand ISO/IEC 27001:2022 requirements across Clauses 4 to 10, Annex A, risk treatment, and the Statement of Applicability. - [ISO 27001 vs NIS2](/artifacts/global/iso-27001/iso-27001-vs-nis2.md): See how ISO/IEC 27001:2022 supports NIS2 cybersecurity governance and where NIS2 adds legal obligations for incident reporting, supervision. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27001/audit-readiness --- --- title: "ISO 27001 Compliance Playbook" canonical_url: "https://www.sorena.io/artifacts/global/iso-27001/compliance" source_url: "https://www.sorena.io/artifacts/global/iso-27001/compliance" author: "Sorena AI" description: "Implement ISO/IEC 27001:2022 with a practical ISMS playbook for scope, risk assessment, risk treatment, Statement of Applicability, Annex A alignment." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27001 compliance" - "ISO 27001 implementation" - "ISO 27001 playbook" - "ISO 27001 SoA" - "risk treatment plan" - "Annex A controls" - "ISMS implementation" - "ISO 27001 certification readiness" - "GLOBAL compliance" - "ISO/IEC 27001" - "ISMS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27001 Compliance Playbook Implement ISO/IEC 27001:2022 with a practical ISMS playbook for scope, risk assessment, risk treatment, Statement of Applicability, Annex A alignment. *Playbook* *GLOBAL* ## ISO 27001 Compliance playbook Implement ISO/IEC 27001:2022 as a real information security management system, not as a policy-writing exercise. Built around scope discipline, risk treatment traceability, control ownership, and repeatable review cycles. ISO/IEC 27001 compliance means operating an information security management system that is established, implemented, maintained, and continually improved. The 2022 edition keeps the core discipline intact: risk-based decision-making, documented scope and governance, a Statement of Applicability tied to treatment decisions, control operation evidence, and formal review and improvement. If you claim conformity, you cannot exclude requirements from Clauses 4 to 10. ## What ISO/IEC 27001:2022 expects in practice The standard is generic and applies to organizations of any type, size, or sector. What changes from organization to organization is the scope, the risk method, the selected controls, and the operating cadence that keeps the ISMS alive. The strongest way to implement the standard is to treat every clause as a source of decisions and evidence. Scope should create a usable boundary. Risk treatment should produce a credible Statement of Applicability. Monitoring and review should generate real changes. - Core outputs: scope, governance, risk method, risk register, Statement of Applicability, treatment plan, operational records, review outputs - Core rule: Clauses 4 to 10 are mandatory and cannot be dropped from a conformity claim - Core mindset: implement controls because the ISMS needs them, not because the Annex A list exists ## Clauses 4 and 5: scope, interested parties, leadership, accountability Start by defining the boundaries and applicability of the ISMS. The scope has to account for internal and external issues, relevant interested parties, and interfaces and dependencies with other organizations. Weak scope statements are one of the fastest ways to create audit confusion. Leadership then has to make the ISMS real through policy, roles, responsibilities, and authorities. If ownership is vague, control operation evidence will be inconsistent no matter how polished the policy set looks. - Outputs: documented scope, context analysis, interested-party requirements, policy, governance roles, decision rights - Evidence: approvals, committee minutes, named owners, and consistent scope references across risk and control documents ## Clause 6: risk assessment, risk treatment, SoA, and objectives Clause 6 is where the ISMS becomes testable. You need defined risk criteria, a repeatable risk assessment process, a risk treatment process, selected treatment options, and a Statement of Applicability that shows necessary controls, justification for inclusion, implementation status, and justification for exclusion of Annex A controls. This is also where residual risk approval matters. A mature ISMS makes risk acceptance attributable, current, and clearly tied to the treatment decision that created it. - Outputs: risk methodology, risk register, treatment decisions, Statement of Applicability, treatment plan, risk owner approvals, security objectives - Traceability path: risk to treatment option to selected control to SoA entry to operation evidence - Grounding point: the 2022 reference control set aligns to the 93-control structure used in ISO/IEC 27002:2022 ## Clauses 7 and 8: support and operation Support clauses keep the ISMS usable. Competence, awareness, communication, and documented information are what make control operation repeatable rather than dependent on a few individuals who know where everything is. Operationally, the organization has to perform information security risk assessments at planned intervals or when significant changes occur, and then implement the risk treatment plan. That means risk review cannot be separated from change in any serious ISMS. - Outputs: training records, awareness activities, communications model, document control rules, change-triggered risk reassessment, treatment execution records - Control discipline: every material control should have an owner, a current operating mechanism, and a way to prove it was performed ## Clauses 9 and 10: monitoring, internal audit, management review, improvement Clauses 9 and 10 distinguish a living ISMS from a paper one. Monitoring and measurement should show whether controls and objectives are working. Internal audits should test the ISMS with enough independence and structure to surface real nonconformities. Management review should decide what changes or resources are needed next. Continual improvement is not abstract. It should show up in corrective actions, SoA updates, revised risk decisions, and changed control operation where evidence shows the current design is weak. - Outputs: monitoring results, internal audit programme, management review inputs and outputs, nonconformity records, corrective action closure evidence - Operating cadence: schedule reviews and audits as part of routine management, not as pre-certification panic work *Recommended next step* *Placement: after the compliance steps* ## Turn ISO 27001 Compliance playbook into an operational assessment Assessment Autopilot can take ISO 27001 Compliance playbook from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on ISO 27001 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 27001 Compliance playbook](/solutions/assessment.md): Start from ISO 27001 Compliance playbook and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 27001](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27001 Compliance playbook. ## Primary sources - [ISO/IEC 27001:2022 standard page](https://www.iso.org/standard/27001?ref=sorena.io) - Primary source for the current ISO/IEC 27001 edition and amendment status. - [ISO/IEC 27002:2022 standard page](https://www.iso.org/standard/75652.html?ref=sorena.io) - Current guidance standard for information security controls. - [ISO/IEC 27005:2022 standard page](https://www.iso.org/standard/80585.html?ref=sorena.io) - Current guidance standard for information security risk management in support of an ISMS. - [IAF MD 26 transition requirements for ISO/IEC 27001:2022](https://iaf.nu/en/iaf-documents/mandatory-documents/md-26-transition-requirements-for-iso-iec-270012022/) - Transition document that explains the practical impact of the 2022 edition and its Annex A alignment. ## Related Topic Guides - [ISO 27001 Audit Readiness](/artifacts/global/iso-27001/audit-readiness.md): Prepare for ISO/IEC 27001 audits with a structured evidence pack, SoA traceability, internal audit and management review outputs. - [ISO 27001 FAQ](/artifacts/global/iso-27001/faq.md): Clear answers to common ISO/IEC 27001:2022 questions on the Statement of Applicability, Annex A, risk treatment, certification, audit evidence. - [ISO 27001 Implementation Roadmap](/artifacts/global/iso-27001/implementation-roadmap.md): A practical ISO/IEC 27001:2022 implementation roadmap with phases, gates, scope decisions, risk and SoA milestones, control rollout priorities. - [ISO 27001 Requirements and Evidence](/artifacts/global/iso-27001/requirements.md): Understand ISO/IEC 27001:2022 requirements across Clauses 4 to 10, Annex A, risk treatment, and the Statement of Applicability. - [ISO 27001 vs NIS2](/artifacts/global/iso-27001/iso-27001-vs-nis2.md): See how ISO/IEC 27001:2022 supports NIS2 cybersecurity governance and where NIS2 adds legal obligations for incident reporting, supervision. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27001/compliance --- --- title: "ISO 27001 FAQ" canonical_url: "https://www.sorena.io/artifacts/global/iso-27001/faq" source_url: "https://www.sorena.io/artifacts/global/iso-27001/faq" author: "Sorena AI" description: "Clear answers to common ISO/IEC 27001:2022 questions on the Statement of Applicability, Annex A, risk treatment, certification, audit evidence." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27001 FAQ" - "ISO 27001 questions" - "Statement of Applicability" - "SoA" - "ISO 27001 Annex A" - "ISO 27001 certification" - "ISO 27001 audit" - "ISO 27002 vs ISO 27001" - "ISO 27005 risk management" - "GLOBAL compliance" - "ISO/IEC 27001" - "FAQ" - "ISMS" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27001 FAQ Clear answers to common ISO/IEC 27001:2022 questions on the Statement of Applicability, Annex A, risk treatment, certification, audit evidence. *FAQ* *GLOBAL* ## ISO 27001 FAQ Straight answers to the ISO 27001 questions teams ask when they are actually building an ISMS. Focused on current edition facts, audit traceability, and the decisions that usually create confusion. ISO 27001 questions usually sound simple but hide implementation traps. The recurring ones are about scope, what Annex A really means, how the Statement of Applicability should work, and what an auditor is going to expect to see. This FAQ answers those with the current 2022 edition and current certification context in mind. ## What is ISO/IEC 27001:2022? ISO/IEC 27001:2022 is the current third edition of the requirements standard for information security management systems. It was published in October 2022 and later received Amendment 1 in 2024 for climate action changes. The standard is a requirements document, not a library of example controls. It specifies what an ISMS has to do and how it has to be managed. - Current core edition: third edition, 2022-10 - If you claim conformity, requirements in Clauses 4 to 10 cannot be excluded - Use it as the governing requirements layer for the ISMS ## Do we have to implement every Annex A control? No. ISO 27001 is risk-based. You determine necessary controls through risk treatment, then compare them against Annex A so that no necessary control from the reference set has been omitted by mistake. That means exclusions are possible, but only with a defensible rationale and clear documentation in the Statement of Applicability. - Annex A is a normative reference set, not a blanket mandate to implement every item - The 2022 reference structure aligns to 93 controls used in ISO/IEC 27002:2022 - Weak exclusion reasoning is one of the most common audit issues ## What exactly must the Statement of Applicability include? The Statement of Applicability must identify the necessary controls, justify why they are included, state whether they are implemented, and justify exclusions of Annex A controls. It is one of the main outputs of risk treatment. In practice, the SoA is the shortest route from risk decisions to audit sampling. If it is sloppy, the whole audit gets slower. - Keep every SoA line tied to a risk treatment decision and a named owner - Implementation status in the SoA should match current records, not intention - Use one SoA, not multiple local copies with different truth states ## How do ISO 27002 and ISO 27005 fit in? ISO 27001 is the requirements standard. ISO 27002 gives guidance on information security controls, and ISO 27005 gives guidance on managing information security risks in support of the ISMS. A mature implementation uses ISO 27001 to define what must exist, ISO 27002 to improve control design, and ISO 27005 to strengthen the risk cycle. - Use ISO 27002 when teams need better control implementation guidance - Use ISO 27005 when teams need a stronger method for identifying, assessing, treating, communicating, monitoring, and reviewing risk ## What is current for certification in 2026? Certification work should now be anchored to ISO/IEC 27001:2022. The transition period from the 2013 edition has ended, so the old edition should not be your working assumption for current certification planning. On the certification-body side, ISO/IEC 27006-1:2024 is the current standard for bodies that audit and certify ISMS. - Expect certification and surveillance activity to be framed against the 2022 edition - Check certification status through accredited channels such as IAF CertSearch where applicable - If you operate across sites, multi-site rules can materially affect audit planning ## What do ISO 27001 auditors usually ask for first? Auditors typically start with scope, the risk methodology, risk assessment results, risk treatment decisions, the Statement of Applicability, and evidence that the selected controls operate. They then move into internal audits, management reviews, and corrective actions. What they are really testing is whether the ISMS tells one consistent story from decision to evidence. - Prepare scope, risk method, SoA, risk treatment plan, and a small set of traceability walkthroughs - Have management review and internal audit outputs ready, not just calendar placeholders - Be able to show current evidence for the controls you claim are implemented *Recommended next step* *Placement: after the FAQ section* ## Use ISO 27001 FAQ as a cited research workflow Research Copilot can take ISO 27001 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on ISO 27001 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO 27001 FAQ](/solutions/research-copilot.md): Start from ISO 27001 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO 27001](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27001 FAQ. ## Primary sources - [ISO/IEC 27001:2022 standard page](https://www.iso.org/standard/27001?ref=sorena.io) - Primary current ISO/IEC 27001 page, including amendment and lifecycle details. - [ISO/IEC 27002:2022 standard page](https://www.iso.org/standard/75652.html?ref=sorena.io) - Current controls guidance standard aligned with the ISO 27001 Annex A reference set. - [ISO/IEC 27005:2022 standard page](https://www.iso.org/standard/80585.html?ref=sorena.io) - Current information security risk guidance standard. - [ISO/IEC 27006-1:2024 standard page](https://www.iso.org/standard/82908.html?ref=sorena.io) - Current certification-body requirements for ISMS certification. ## Related Topic Guides - [ISO 27001 Audit Readiness](/artifacts/global/iso-27001/audit-readiness.md): Prepare for ISO/IEC 27001 audits with a structured evidence pack, SoA traceability, internal audit and management review outputs. - [ISO 27001 Compliance Playbook](/artifacts/global/iso-27001/compliance.md): Implement ISO/IEC 27001:2022 with a practical ISMS playbook for scope, risk assessment, risk treatment, Statement of Applicability, Annex A alignment. - [ISO 27001 Implementation Roadmap](/artifacts/global/iso-27001/implementation-roadmap.md): A practical ISO/IEC 27001:2022 implementation roadmap with phases, gates, scope decisions, risk and SoA milestones, control rollout priorities. - [ISO 27001 Requirements and Evidence](/artifacts/global/iso-27001/requirements.md): Understand ISO/IEC 27001:2022 requirements across Clauses 4 to 10, Annex A, risk treatment, and the Statement of Applicability. - [ISO 27001 vs NIS2](/artifacts/global/iso-27001/iso-27001-vs-nis2.md): See how ISO/IEC 27001:2022 supports NIS2 cybersecurity governance and where NIS2 adds legal obligations for incident reporting, supervision. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27001/faq --- --- title: "ISO 27001 Implementation Roadmap" canonical_url: "https://www.sorena.io/artifacts/global/iso-27001/implementation-roadmap" source_url: "https://www.sorena.io/artifacts/global/iso-27001/implementation-roadmap" author: "Sorena AI" description: "A practical ISO/IEC 27001:2022 implementation roadmap with phases, gates, scope decisions, risk and SoA milestones, control rollout priorities." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27001 implementation roadmap" - "ISO 27001 implementation plan" - "ISO 27001 roadmap" - "SoA milestone" - "ISO 27001 risk treatment plan" - "ISMS rollout" - "ISO 27001 certification roadmap" - "GLOBAL compliance" - "ISO/IEC 27001" - "ISMS" - "Implementation roadmap" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27001 Implementation Roadmap A practical ISO/IEC 27001:2022 implementation roadmap with phases, gates, scope decisions, risk and SoA milestones, control rollout priorities. *Roadmap* *GLOBAL* ## ISO 27001 Implementation roadmap Roll out ISO/IEC 27001 with gates that reflect how an ISMS actually matures. This roadmap is built around decision quality and evidence quality, not arbitrary countdowns. ISO 27001 implementations fail when they start at the wrong end. If you begin with a policy pack or a control checklist, you create an ISMS that looks busy but has weak traceability. The better pattern is phased: define scope and governance, run risk assessment, make treatment decisions, build the Statement of Applicability, implement the selected controls with evidence, and only then push hard on audit readiness and certification timing. ## Phase 0: define the audit boundary and operating model Your first milestone is a scope that can survive contact with the risk register, the Statement of Applicability, and the audit plan. This means documenting the ISMS boundary, relevant interested parties, dependencies on third parties, and the governance model that will own the system. Do not leave scope decisions ambiguous because you intend to clean them up later. ISO 27001 scope drift is expensive once control evidence starts accumulating. - Outputs: scope statement, context record, interested-party requirements, ISMS governance and RACI - Gate: risk assessment can now run against a stable boundary and named owners ## Phase 1: build the risk method and first full assessment Next, define risk criteria, risk acceptance logic, and the assessment method that will produce consistent and comparable results. Then run the first scoped assessment. Keep the method simple enough that teams can actually reuse it when changes occur. This phase should produce a clear baseline of material risks and decision points, not just a long list of issues. - Outputs: risk methodology, risk criteria, risk register, risk owners, review triggers - Gate: the organization has agreed which risks require treatment and which residual positions can be accepted ## Phase 2: complete risk treatment and the Statement of Applicability This is the structural center of the roadmap. Select treatment options, determine necessary controls, compare against Annex A to confirm nothing necessary has been missed, create the Statement of Applicability, and build the risk treatment plan. If the SoA and treatment plan are weak, every later phase is harder. This is where you want the most review discipline. - Outputs: SoA, treatment plan, residual risk approvals, initial control implementation backlog - Gate: every material risk has a treatment path, named owner, and evidence expectation *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep ISO 27001 Implementation roadmap in one governed evidence system SSOT can take ISO 27001 Implementation roadmap from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on ISO 27001 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for ISO 27001 Implementation roadmap](/solutions/ssot.md): Start from ISO 27001 Implementation roadmap and keep documents, evidence, and control records in one governed system. - [Talk through ISO 27001](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27001 Implementation roadmap. ## Phase 3: implement selected controls with evidence built in Implement the controls that the ISMS needs, in the order the ISMS needs them. That usually means tackling controls linked to high-risk items, cross-cutting governance controls, and controls whose evidence takes time to accumulate. Build implementation so it creates records naturally. Controls that work only when someone remembers to prepare evidence manually tend to fail under audit pressure. - Outputs: configured controls, operational procedures, review records, monitoring outputs, training and awareness records - Gate: selected controls are live, owned, and already producing evidence that matches the SoA ## Phase 4: run the operating cycle before the certification cycle Before certification planning becomes the main project, the ISMS should already have completed monitoring activity, internal audit, management review, and corrective action. That is the point where the system starts to look real to an auditor. The goal is not to look mature for one audit window. The goal is to show that the ISMS has entered a durable operating rhythm. - Outputs: monitoring results, internal audit programme and results, management review minutes, corrective action register - Gate: at least one full review and improvement cycle is complete and traceable ## Primary sources - [ISO/IEC 27001:2022 standard page](https://www.iso.org/standard/27001?ref=sorena.io) - Primary source for the current ISO/IEC 27001 edition and lifecycle. - [ISO/IEC 27002:2022 standard page](https://www.iso.org/standard/75652.html?ref=sorena.io) - Current guidance for information security controls used to support Annex A implementation. - [ISO/IEC 27005:2022 standard page](https://www.iso.org/standard/80585.html?ref=sorena.io) - Current guidance for information security risk management. ## Related Topic Guides - [ISO 27001 Audit Readiness](/artifacts/global/iso-27001/audit-readiness.md): Prepare for ISO/IEC 27001 audits with a structured evidence pack, SoA traceability, internal audit and management review outputs. - [ISO 27001 Compliance Playbook](/artifacts/global/iso-27001/compliance.md): Implement ISO/IEC 27001:2022 with a practical ISMS playbook for scope, risk assessment, risk treatment, Statement of Applicability, Annex A alignment. - [ISO 27001 FAQ](/artifacts/global/iso-27001/faq.md): Clear answers to common ISO/IEC 27001:2022 questions on the Statement of Applicability, Annex A, risk treatment, certification, audit evidence. - [ISO 27001 Requirements and Evidence](/artifacts/global/iso-27001/requirements.md): Understand ISO/IEC 27001:2022 requirements across Clauses 4 to 10, Annex A, risk treatment, and the Statement of Applicability. - [ISO 27001 vs NIS2](/artifacts/global/iso-27001/iso-27001-vs-nis2.md): See how ISO/IEC 27001:2022 supports NIS2 cybersecurity governance and where NIS2 adds legal obligations for incident reporting, supervision. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27001/implementation-roadmap --- --- title: "ISO 27001 vs NIS2" canonical_url: "https://www.sorena.io/artifacts/global/iso-27001/iso-27001-vs-nis2" source_url: "https://www.sorena.io/artifacts/global/iso-27001/iso-27001-vs-nis2" author: "Sorena AI" description: "See how ISO/IEC 27001:2022 supports NIS2 cybersecurity governance and where NIS2 adds legal obligations for incident reporting, supervision." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27001 vs NIS2" - "NIS2 vs ISO 27001" - "ISO 27001 NIS2 mapping" - "ISO 27001 for NIS2" - "NIS2 cybersecurity risk management measures" - "ENISA NIS2 guidance" - "GLOBAL compliance" - "ISO/IEC 27001" - "NIS2" - "Cybersecurity" - "EU compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27001 vs NIS2 See how ISO/IEC 27001:2022 supports NIS2 cybersecurity governance and where NIS2 adds legal obligations for incident reporting, supervision. *Artifact Guide* *GLOBAL* ## ISO 27001 ISO 27001 vs NIS2 Use ISO 27001 as the management-system backbone for cybersecurity, then add the legal and supervisory overlays NIS2 requires. This page focuses on what can be reused, what cannot, and how to avoid duplicate evidence programs. ISO 27001 and NIS2 are often implemented together because they address related but different problems. ISO/IEC 27001:2022 is a voluntary management-system standard for information security. NIS2 is an EU directive that creates legal obligations for in-scope entities through national law. A mature ISO 27001 program can support a large part of NIS2 readiness, but it cannot by itself satisfy NIS2 reporting, supervisory, and legal-accountability expectations. ## What each framework is meant to do ISO 27001 gives organizations a structured system for scope, risk assessment, risk treatment, control selection, performance evaluation, and continual improvement. It is excellent for making cybersecurity governance repeatable and auditable. NIS2 defines legal obligations for cybersecurity risk-management measures, incident handling and reporting, business continuity, supply-chain security, supervision, and enforcement for entities in scope. - ISO 27001 strength: management-system discipline and evidence structure - NIS2 strength: legal accountability, incident-reporting obligations, and regulatory oversight - Combined strategy: run one ISMS, then layer NIS2-specific legal artifacts on top ## What ISO 27001 evidence usually supports NIS2 well An operating ISMS already produces many of the artifacts regulators expect to see in some form: governance records, risk assessment outputs, treatment decisions, supplier controls, incident processes, monitoring evidence, and improvement actions. That means a strong Statement of Applicability and a well-kept treatment plan can become the backbone of your NIS2 evidence library. - Reusable artifacts: governance model, asset and dependency inventories, risk register, treatment plan, supplier controls, monitoring, internal audit, management review, corrective actions - Best practice: build an explicit crosswalk from each NIS2 requirement to the ISMS artifact that supports it ## Where NIS2 goes beyond ISO 27001 NIS2 is not only a cybersecurity standard. It is a legal regime. That means it adds areas ISO 27001 does not define at the same level, especially around incident reporting, supervisory interaction, management-body accountability, and national implementation detail. Some sectors and subsectors also have more detailed EU-level or national requirements that cannot be inferred from ISO 27001 alone. - Legal reporting and escalation requirements for significant incidents - Supervisory interfaces, evidence retention, and regulator-facing procedures - Management accountability obligations that depend on national transposition and sector context - Sector or subsector technical measures that need explicit implementation evidence ## How to structure one evidence pack instead of two The efficient model is one evidence repository with two indexes. The first index follows ISO 27001 clauses and the SoA. The second follows NIS2 obligations and any implementing guidance that applies to your sector. Shared artifacts can then be referenced from both indexes. This approach keeps the ISMS as the operating system while making NIS2-specific obligations visible rather than buried inside generic security documents. - ISO 27001 index: clauses, risk treatment, SoA, monitoring, internal audit, management review - NIS2 index: governance obligations, incident handling and reporting, supervisory communications, sector-specific measures - Document rule: shared artifacts should declare their scope and audience clearly so they remain defensible *Recommended next step* *Placement: after the comparison section* ## Use ISO 27001 ISO 27001 vs NIS2 as a cited research workflow Research Copilot can take ISO 27001 ISO 27001 vs NIS2 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on ISO 27001 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO 27001 ISO 27001 vs NIS2](/solutions/research-copilot.md): Start from ISO 27001 ISO 27001 vs NIS2 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO 27001](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27001 ISO 27001 vs NIS2. ## Primary sources - [ISO/IEC 27001:2022 standard page](https://www.iso.org/standard/27001?ref=sorena.io) - Primary source for the current ISO/IEC 27001 edition. - [Directive (EU) 2022/2555 consolidated link](https://data.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Official ELI link for the NIS2 directive. - [Commission Implementing Regulation (EU) 2024/2690](https://data.europa.eu/eli/reg_impl/2024/2690/oj?ref=sorena.io) - Official ELI link for EU-level technical and methodological requirements for certain NIS2 subsectors. - [ENISA technical implementation guidance on Regulation (EU) 2024/2690](https://www.enisa.europa.eu/publications/technical-implementation-guidance-on-commission-implementing-regulation-eu-2024-2690?ref=sorena.io) - Operational guidance with practical evidence expectations for relevant sectors. ## Related Topic Guides - [ISO 27001 Audit Readiness](/artifacts/global/iso-27001/audit-readiness.md): Prepare for ISO/IEC 27001 audits with a structured evidence pack, SoA traceability, internal audit and management review outputs. - [ISO 27001 Compliance Playbook](/artifacts/global/iso-27001/compliance.md): Implement ISO/IEC 27001:2022 with a practical ISMS playbook for scope, risk assessment, risk treatment, Statement of Applicability, Annex A alignment. - [ISO 27001 FAQ](/artifacts/global/iso-27001/faq.md): Clear answers to common ISO/IEC 27001:2022 questions on the Statement of Applicability, Annex A, risk treatment, certification, audit evidence. - [ISO 27001 Implementation Roadmap](/artifacts/global/iso-27001/implementation-roadmap.md): A practical ISO/IEC 27001:2022 implementation roadmap with phases, gates, scope decisions, risk and SoA milestones, control rollout priorities. - [ISO 27001 Requirements and Evidence](/artifacts/global/iso-27001/requirements.md): Understand ISO/IEC 27001:2022 requirements across Clauses 4 to 10, Annex A, risk treatment, and the Statement of Applicability. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27001/iso-27001-vs-nis2 --- --- title: "ISO 27001 Requirements and Evidence" canonical_url: "https://www.sorena.io/artifacts/global/iso-27001/requirements" source_url: "https://www.sorena.io/artifacts/global/iso-27001/requirements" author: "Sorena AI" description: "Understand ISO/IEC 27001:2022 requirements across Clauses 4 to 10, Annex A, risk treatment, and the Statement of Applicability." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27001 requirements" - "ISO 27001 clauses 4 to 10" - "ISO 27001 Annex A" - "ISO 27001 Statement of Applicability" - "SoA" - "ISO 27001 risk treatment" - "ISO 27001 evidence" - "GLOBAL compliance" - "ISO/IEC 27001" - "ISMS requirements" - "Statement of Applicability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27001 Requirements and Evidence Understand ISO/IEC 27001:2022 requirements across Clauses 4 to 10, Annex A, risk treatment, and the Statement of Applicability. *Requirements* *GLOBAL* ## ISO 27001 Requirements Clauses 4 to 10, Annex A, and the Statement of Applicability explained with an evidence-first lens. Use this page to see what the standard requires and what proof an operating ISMS should generate. ISO/IEC 27001:2022 is easiest to implement when you read it as a chain of decisions and evidence. Scope decisions determine the audit boundary. Risk decisions determine which controls are necessary. The Statement of Applicability captures the treatment logic. Monitoring, internal audit, and management review prove the ISMS keeps working. This page breaks that down clause by clause. ## Clauses 4 and 5: context, scope, policy, and accountability Clause 4 requires you to understand the organization, relevant interested parties, and the boundaries and applicability of the ISMS. The scope must be available as documented information. Clause 5 then requires leadership commitment, policy, and clear roles, responsibilities, and authorities. These clauses are easy to under-build because they look administrative. In reality, they are what make later risk and control evidence coherent. - Evidence examples: documented scope, context assessment, interested-party requirements, policy approval, governance structure, role assignments - Audit question: does the same scope appear consistently across the risk register, SoA, supplier records, and sampled control evidence ## Clause 6: planning, risk assessment, risk treatment, and objectives Clause 6.1.2 requires the organization to define and apply an information security risk assessment process that produces valid, consistent, and comparable results. Clause 6.1.3 then requires the risk treatment process, including determining necessary controls, comparing them to Annex A, producing the Statement of Applicability, creating the treatment plan, and obtaining residual risk approvals. This clause is where most implementations either become disciplined or become decorative. - Evidence examples: risk criteria, risk assessment method, risk register, treatment decisions, Statement of Applicability, treatment plan, residual risk approvals - Grounding point: comparison against Annex A exists so necessary reference controls are not omitted by mistake - 2022 context: the reference set aligns to the 93-control structure of ISO/IEC 27002:2022 ## Clauses 7 and 8: support and operation Clause 7 covers resources, competence, awareness, communication, and documented information. These are operational enablers. If they are weak, the ISMS will depend on heroics rather than system behavior. Clause 8 requires operational planning and control plus recurring information security risk assessment and information security risk treatment. The standard expects this work to happen at planned intervals and when significant changes occur. - Evidence examples: training records, awareness outputs, communications rules, document control records, change-driven risk reviews, treatment execution records - Operational test: can the organization show that major changes trigger risk review and treatment updates ## Clauses 9 and 10: performance evaluation and improvement Clause 9 requires monitoring, measurement, analysis, and evaluation, internal audit, and management review. Clause 10 requires continual improvement plus nonconformity and corrective action. Together, these clauses turn the ISMS into a living system. Most audit pain in this area comes from management review that is too generic, internal audits that do not challenge the system, or corrective actions that are logged but never meaningfully closed. - Evidence examples: dashboards, internal audit programmes and reports, management review inputs and outputs, nonconformity records, corrective action closure evidence - Operating rule: every meaningful weakness should have an owner, deadline, and proof of closure or escalation ## What Annex A does and does not do Annex A is a normative information security controls reference. It supports treatment comparison and the Statement of Applicability, but it is not a substitute for risk treatment logic. The ISMS still has to decide what is necessary in the organization's context. That is why a control cannot be marked implemented just because the organization likes the idea of it. It has to make sense in the treatment model and be supportable in evidence. - Use Annex A as the reference set for comparison, not as a generic to-do list - Use the SoA to explain inclusion, exclusion, and implementation status - Use ISO/IEC 27002 to deepen implementation where teams need control design guidance *Recommended next step* *Placement: after the requirement breakdown* ## Turn ISO 27001 Requirements into an operational assessment Assessment Autopilot can take ISO 27001 Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on ISO 27001 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 27001 Requirements](/solutions/assessment.md): Start from ISO 27001 Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 27001](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27001 Requirements. ## Primary sources - [ISO/IEC 27001:2022 standard page](https://www.iso.org/standard/27001?ref=sorena.io) - Primary current ISO/IEC 27001 page. - [ISO/IEC 27002:2022 standard page](https://www.iso.org/standard/75652.html?ref=sorena.io) - Current guidance standard for information security controls. - [ISO/IEC 27005:2022 standard page](https://www.iso.org/standard/80585.html?ref=sorena.io) - Current guidance standard for information security risk management. - [IAF MD 26 transition requirements for ISO/IEC 27001:2022](https://iaf.nu/en/iaf-documents/mandatory-documents/md-26-transition-requirements-for-iso-iec-270012022/) - Useful for understanding the 2022 Annex A alignment and transition impact. ## Related Topic Guides - [ISO 27001 Audit Readiness](/artifacts/global/iso-27001/audit-readiness.md): Prepare for ISO/IEC 27001 audits with a structured evidence pack, SoA traceability, internal audit and management review outputs. - [ISO 27001 Compliance Playbook](/artifacts/global/iso-27001/compliance.md): Implement ISO/IEC 27001:2022 with a practical ISMS playbook for scope, risk assessment, risk treatment, Statement of Applicability, Annex A alignment. - [ISO 27001 FAQ](/artifacts/global/iso-27001/faq.md): Clear answers to common ISO/IEC 27001:2022 questions on the Statement of Applicability, Annex A, risk treatment, certification, audit evidence. - [ISO 27001 Implementation Roadmap](/artifacts/global/iso-27001/implementation-roadmap.md): A practical ISO/IEC 27001:2022 implementation roadmap with phases, gates, scope decisions, risk and SoA milestones, control rollout priorities. - [ISO 27001 vs NIS2](/artifacts/global/iso-27001/iso-27001-vs-nis2.md): See how ISO/IEC 27001:2022 supports NIS2 cybersecurity governance and where NIS2 adds legal obligations for incident reporting, supervision. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27001/requirements --- --- title: "ISO 27005 Compliance Playbook" canonical_url: "https://www.sorena.io/artifacts/global/iso-27005/compliance" source_url: "https://www.sorena.io/artifacts/global/iso-27005/compliance" author: "Sorena AI" description: "Operationalize ISO/IEC 27005:2022 with a practical playbook for context, criteria, risk assessment, risk treatment, residual risk acceptance, communication." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27005 compliance" - "ISO 27005 implementation" - "ISO 27005 risk management" - "information security risk assessment" - "risk treatment plan" - "risk acceptance criteria" - "residual risk acceptance" - "GLOBAL compliance" - "ISO/IEC 27005" - "Risk management" - "Risk assessment" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27005 Compliance Playbook Operationalize ISO/IEC 27005:2022 with a practical playbook for context, criteria, risk assessment, risk treatment, residual risk acceptance, communication. *Playbook* *GLOBAL* ## ISO 27005 Compliance playbook Run ISO/IEC 27005 as a repeatable risk operating model that supports ISO/IEC 27001. Focus on criteria, ownership, treatment choices, and review loops rather than abstract methodology alone. ISO/IEC 27005 is guidance on managing information security risks to support an ISMS based on ISO/IEC 27001. In practice, good ISO 27005 implementation means the organization can explain how it defines risk, how it decides what is acceptable, how it assesses and treats risks, who approves residual exposure, and how those decisions stay current as systems, threats, and business priorities change. ## Start with context and decision policy The first thing ISO 27005 needs is context. That means scope, business dependencies, interested-party requirements, assumptions, and the decision boundaries that tell assessors what matters and why. Without context, risk scoring becomes arbitrary. Without decision policy, risk acceptance becomes inconsistent. - Core outputs: scope, key assets and services, dependencies, interested-party requirements, scenario framing - Decision policy: risk criteria, risk acceptance criteria, and authority levels for residual risk approval ## Run assessments that are consistent enough to compare ISO 27005 is not only about finding risks. It is about finding them in a way that different teams can compare and govern. That requires a common methodology, a defined risk model, and enough rationale in each record to understand why the result was reached. Do not optimize the method for speed alone. Optimize it for repeatability and clarity. - Assessment outputs: risk description, owner, consequence rationale, likelihood rationale, level of risk, and priority for treatment - Quality controls: shared scales, calibration sessions, peer review of high-risk items, and explicit uncertainty notes ## Translate assessed risk into treatment decisions ISO 27005 covers selecting treatment options, determining necessary controls or actions, building treatment plans, and obtaining approval. The useful distinction is that assessment tells you what matters, while treatment tells you what the organization will do about it. Treatment plans should be written as delivery plans with owners, milestones, evidence expectations, and clear acceptance criteria. - Treatment options usually include modifying, retaining, avoiding, or sharing risk - Every treatment item should state owner, deadline, success condition, and linked evidence source - Residual risk should be accepted explicitly, with conditions or review dates where needed ## Keep risk management inside the ISMS, not beside it ISO 27005 supports ISO 27001. It should not become a separate risk universe with its own vocabulary, owners, and review habits. The most useful model keeps one risk register, one treatment workflow, and one management reporting rhythm. When the ISMS and the risk process split apart, the Statement of Applicability, treatment plan, and control evidence drift out of alignment. - Integrate treatment decisions with control implementation and evidence under the ISMS - Bring top risks, exceptions, and stalled treatments into management review - Use corrective action when the risk process itself fails or becomes inconsistent ## Monitor, communicate, and review on purpose ISO 27005 explicitly covers communication, monitoring, and review. This is where many programs underperform. They assess once, create plans, and then let the risk picture age in place. Build a small number of review triggers that actually matter and use them rigorously. - Periodic review: revisit high-risk items on a defined cadence - Change triggers: incidents, control failures, architecture changes, new suppliers, or legal changes - Reporting outputs: treatment progress, accepted exceptions, aged risks, and overdue reviews *Recommended next step* *Placement: after the compliance steps* ## Turn ISO 27005 Compliance playbook into an operational assessment Assessment Autopilot can take ISO 27005 Compliance playbook from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on ISO 27005 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 27005 Compliance playbook](/solutions/assessment.md): Start from ISO 27005 Compliance playbook and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 27005](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27005 Compliance playbook. ## Primary sources - [ISO/IEC 27005:2022 standard page](https://www.iso.org/standard/80585.html?ref=sorena.io) - Primary current source for ISO/IEC 27005, including edition, publication timing, and scope of guidance. - [ISO/IEC 27001:2022 standard page](https://www.iso.org/standard/27001?ref=sorena.io) - Requirements standard that ISO/IEC 27005 supports. ## Related Topic Guides - [ISO 27005 FAQ](/artifacts/global/iso-27005/faq.md): Answers to common ISO/IEC 27005 questions on risk criteria, acceptance criteria, risk owners, treatment plans, residual risk, NIST comparisons. - [ISO 27005 Risk Assessment Template](/artifacts/global/iso-27005/risk-assessment-template.md): Use this ISO/IEC 27005 risk assessment template to capture context, criteria, scenario details, likelihood, consequence, uncertainty, risk owner, evaluation. - [ISO 27005 Risk Treatment Plan Template](/artifacts/global/iso-27005/risk-treatment-plan-template.md): Use this ISO/IEC 27005 risk treatment plan template to document treatment options, selected actions, owners, milestones, evidence links, acceptance criteria. - [ISO 27005 vs NIST SP 800-30](/artifacts/global/iso-27005/iso-27005-vs-nist-800-30.md): Compare ISO/IEC 27005 and NIST SP 800-30 to see how information security risk management guidance and risk assessment guidance fit together. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27005/compliance --- --- title: "ISO 27005 FAQ" canonical_url: "https://www.sorena.io/artifacts/global/iso-27005/faq" source_url: "https://www.sorena.io/artifacts/global/iso-27005/faq" author: "Sorena AI" description: "Answers to common ISO/IEC 27005 questions on risk criteria, acceptance criteria, risk owners, treatment plans, residual risk, NIST comparisons." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27005 FAQ" - "ISO 27005 questions" - "risk criteria" - "risk acceptance criteria" - "risk owner" - "residual risk acceptance" - "risk treatment plan" - "ISO 27005 certification" - "GLOBAL compliance" - "ISO/IEC 27005" - "FAQ" - "Risk management" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27005 FAQ Answers to common ISO/IEC 27005 questions on risk criteria, acceptance criteria, risk owners, treatment plans, residual risk, NIST comparisons. *FAQ* *GLOBAL* ## ISO 27005 FAQ Direct answers to the ISO 27005 questions teams ask when they need real risk decisions, not just terminology. Focused on current edition facts, governance decisions, and practical ISMS alignment. Most ISO 27005 questions show up when teams have to decide whether a risk is acceptable, who signs off, and how much detail is enough for audit or management review. This FAQ answers those questions from a practical implementation angle. ## Can you certify to ISO/IEC 27005? No. ISO/IEC 27005 is a guidance standard for managing information security risks. It supports an ISMS based on ISO/IEC 27001, but it is not itself the certification standard. That makes implementation discipline even more important, because the value comes from how well the method works in practice, not from the label on the document. - Use ISO 27005 to improve the quality of risk decisions - Use ISO 27001 if you need a requirements and certification baseline ## What is the difference between risk criteria and risk acceptance criteria? Risk criteria define how the organization determines levels of risk. They shape the scoring logic, comparisons, and thresholds used during analysis and evaluation. Risk acceptance criteria define when residual risk is acceptable, under what conditions, and who is allowed to approve that acceptance. - Criteria shape the assessment method - Acceptance criteria shape authority and decision thresholds - Strong programs document both separately and review both periodically ## Who should be the risk owner? The risk owner should be the person or role that can legitimately decide how the organization responds to the risk and whether the remaining exposure is acceptable. In practice, this is often a business owner, service owner, or accountable executive rather than only a security analyst. If the wrong level of the organization owns risk, residual acceptance becomes meaningless because the approver does not actually control the consequence. - Risk ownership should align to decision authority, not only to subject-matter expertise - Higher approval tiers may be needed for residual risk above standard thresholds ## What should a good risk treatment plan contain? A strong risk treatment plan should say what the chosen treatment option is, what controls or actions will be used, who owns delivery, what success looks like, when review happens, and what residual risk remains after treatment. The more concrete the plan, the easier it is to review later and the harder it is for the organization to lose the thread of the original decision. - Minimum fields: risk, treatment option, owner, milestones, acceptance criteria, evidence links, residual risk decision - Use treatment plans as execution artifacts, not as static approval forms ## How does ISO 27005 compare to NIST SP 800-30? ISO 27005 covers a broader information security risk-management cycle, including treatment, communication, monitoring, and review. NIST SP 800-30 is specifically guidance for conducting risk assessments and organizing those results. That means the two can work together well. ISO 27005 can provide the operating model, while NIST SP 800-30 can sharpen the assessment mechanics and reporting structure. - ISO 27005 is broader than assessment alone - NIST SP 800-30 is deeper on assessment structure and reporting guidance - Use one register and one vocabulary to avoid drift across frameworks ## How often should risks be reviewed? There is no single universal cadence. Review frequency should depend on criticality, change rate, threat exposure, and how much uncertainty remains in the current assessment. High-risk items and fast-changing environments should be reviewed more often than stable, low-exposure areas. - Use both scheduled reviews and change-triggered reviews - Reassess after incidents, major architecture changes, supplier changes, or control failures - Make overdue reviews visible in management reporting *Recommended next step* *Placement: after the FAQ section* ## Use ISO 27005 FAQ as a cited research workflow Research Copilot can take ISO 27005 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on ISO 27005 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO 27005 FAQ](/solutions/research-copilot.md): Start from ISO 27005 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO 27005](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27005 FAQ. ## Primary sources - [ISO/IEC 27005:2022 standard page](https://www.iso.org/standard/80585.html?ref=sorena.io) - Primary source for edition, scope, and positioning of ISO/IEC 27005 as guidance. - [ISO/IEC 27001:2022 standard page](https://www.iso.org/standard/27001?ref=sorena.io) - Requirements standard that ISO 27005 is designed to support. - [NIST SP 800-30 Rev. 1 PDF](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-30r1.pdf?ref=sorena.io) - Public risk assessment guidance used in many mixed-framework environments. ## Related Topic Guides - [ISO 27005 Compliance Playbook](/artifacts/global/iso-27005/compliance.md): Operationalize ISO/IEC 27005:2022 with a practical playbook for context, criteria, risk assessment, risk treatment, residual risk acceptance, communication. - [ISO 27005 Risk Assessment Template](/artifacts/global/iso-27005/risk-assessment-template.md): Use this ISO/IEC 27005 risk assessment template to capture context, criteria, scenario details, likelihood, consequence, uncertainty, risk owner, evaluation. - [ISO 27005 Risk Treatment Plan Template](/artifacts/global/iso-27005/risk-treatment-plan-template.md): Use this ISO/IEC 27005 risk treatment plan template to document treatment options, selected actions, owners, milestones, evidence links, acceptance criteria. - [ISO 27005 vs NIST SP 800-30](/artifacts/global/iso-27005/iso-27005-vs-nist-800-30.md): Compare ISO/IEC 27005 and NIST SP 800-30 to see how information security risk management guidance and risk assessment guidance fit together. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27005/faq --- --- title: "ISO 27005 vs NIST SP 800-30" canonical_url: "https://www.sorena.io/artifacts/global/iso-27005/iso-27005-vs-nist-800-30" source_url: "https://www.sorena.io/artifacts/global/iso-27005/iso-27005-vs-nist-800-30" author: "Sorena AI" description: "Compare ISO/IEC 27005 and NIST SP 800-30 to see how information security risk management guidance and risk assessment guidance fit together." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27005 vs NIST 800-30" - "NIST 800-30 vs ISO 27005" - "risk assessment methodology comparison" - "ISO 27005 risk management" - "NIST SP 800-30 risk assessment" - "GLOBAL compliance" - "ISO/IEC 27005" - "NIST SP 800-30" - "Risk assessment" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27005 vs NIST SP 800-30 Compare ISO/IEC 27005 and NIST SP 800-30 to see how information security risk management guidance and risk assessment guidance fit together. *Comparison* *GLOBAL* ## ISO 27005 ISO 27005 vs NIST SP 800-30 Use this mapping to unify ISO-style risk governance with NIST-style assessment detail. The goal is one risk story, not parallel methods that drift apart over time. ISO/IEC 27005 and NIST SP 800-30 are often used by the same organizations, but they sit at slightly different layers. ISO/IEC 27005 is guidance on managing information security risks in support of an ISMS. NIST SP 800-30 Rev. 1 is guidance for conducting risk assessments and maintaining the results of those assessments. That difference matters when you decide what one method should do for the organization and what the other should contribute. ## What each document is optimized for ISO/IEC 27005 covers the broader information security risk-management cycle. It includes context, criteria, risk assessment, treatment, communication, monitoring, and review, all in support of ISO/IEC 27001-based management systems. NIST SP 800-30 is more specific to risk assessment execution. It explains how to prepare for an assessment, conduct the assessment, communicate the results, and maintain the assessment over time. - ISO 27005 strength: broader operating model for information security risk decisions - NIST SP 800-30 strength: detailed public guidance for risk assessment structure and reporting - Important distinction: broader NIST risk management governance sits in SP 800-39, not in SP 800-30 ## How the process steps line up NIST SP 800-30 describes the risk assessment process as preparing for the assessment, conducting the assessment, communicating the results, and maintaining the assessment. Those stages line up well with ISO 27005, but ISO 27005 continues further into treatment choices, residual risk decisions, and ongoing review within the ISMS. That means ISO 27005 can usually serve as the program frame, while NIST SP 800-30 strengthens the assessment mechanics and reporting outputs. - NIST prepare aligns to ISO context establishment and criteria setting - NIST conduct aligns to ISO identification, analysis, evaluation, and prioritization - NIST communicate aligns to ISO communication and consultation with stakeholders and risk owners - NIST maintain aligns to ISO monitoring and review, but ISO continues into treatment and governance decisions ## Where evidence can be reused cleanly The most efficient model is one risk register and one treatment workflow with two reporting views. The ISO view emphasizes criteria, owners, treatment choices, and residual risk acceptance. The NIST view emphasizes assessment rationale, uncertainty, and structured communication of results. Both can share the same underlying evidence if the register is disciplined and each risk record captures enough reasoning and source material. - Shared artifacts: risk methodology, risk register, scoring rationale, uncertainty notes, treatment plans, review records - ISO-specific emphasis: acceptance criteria, residual risk approval, treatment ownership, ISMS integration - NIST-specific emphasis: explicit assessment preparation, communication outputs, and assessment maintenance logic ## How to avoid drift in mixed-framework environments The failure mode is running ISO and NIST as if they are separate risk universes. That creates two different descriptions of the same exposure and leads to conflicting treatment decisions. Prevent that by choosing one vocabulary and one source-of-truth register. If you need different report formats for different stakeholders, build them from the same underlying data instead of duplicating the risk analysis itself. - Use one risk owner model across both views - Standardize consequence and likelihood rationale so scores stay comparable - Keep residual risk acceptance in the core record even if the audience report changes *Recommended next step* *Placement: after the comparison section* ## Use ISO 27005 ISO 27005 vs NIST SP 800-30 as a cited research workflow Research Copilot can take ISO 27005 ISO 27005 vs NIST SP 800-30 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on ISO 27005 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO 27005 ISO 27005 vs NIST SP 800-30](/solutions/research-copilot.md): Start from ISO 27005 ISO 27005 vs NIST SP 800-30 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO 27005](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27005 ISO 27005 vs NIST SP 800-30. ## Primary sources - [ISO/IEC 27005:2022 standard page](https://www.iso.org/standard/80585.html?ref=sorena.io) - Primary source for the scope and positioning of ISO/IEC 27005. - [NIST SP 800-30 Rev. 1 PDF](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-30r1.pdf?ref=sorena.io) - Primary NIST source for preparing, conducting, communicating, and maintaining risk assessments. ## Related Topic Guides - [ISO 27005 Compliance Playbook](/artifacts/global/iso-27005/compliance.md): Operationalize ISO/IEC 27005:2022 with a practical playbook for context, criteria, risk assessment, risk treatment, residual risk acceptance, communication. - [ISO 27005 FAQ](/artifacts/global/iso-27005/faq.md): Answers to common ISO/IEC 27005 questions on risk criteria, acceptance criteria, risk owners, treatment plans, residual risk, NIST comparisons. - [ISO 27005 Risk Assessment Template](/artifacts/global/iso-27005/risk-assessment-template.md): Use this ISO/IEC 27005 risk assessment template to capture context, criteria, scenario details, likelihood, consequence, uncertainty, risk owner, evaluation. - [ISO 27005 Risk Treatment Plan Template](/artifacts/global/iso-27005/risk-treatment-plan-template.md): Use this ISO/IEC 27005 risk treatment plan template to document treatment options, selected actions, owners, milestones, evidence links, acceptance criteria. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27005/iso-27005-vs-nist-800-30 --- --- title: "ISO 27005 Risk Assessment Template" canonical_url: "https://www.sorena.io/artifacts/global/iso-27005/risk-assessment-template" source_url: "https://www.sorena.io/artifacts/global/iso-27005/risk-assessment-template" author: "Sorena AI" description: "Use this ISO/IEC 27005 risk assessment template to capture context, criteria, scenario details, likelihood, consequence, uncertainty, risk owner, evaluation." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27005 risk assessment template" - "ISO 27005 risk assessment" - "information security risk register template" - "likelihood consequence model" - "uncertainty field" - "risk owner template" - "GLOBAL compliance" - "ISO/IEC 27005" - "Risk assessment" - "Template" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27005 Risk Assessment Template Use this ISO/IEC 27005 risk assessment template to capture context, criteria, scenario details, likelihood, consequence, uncertainty, risk owner, evaluation. *Template* *GLOBAL* ## ISO 27005 Risk assessment template A practical risk assessment template that produces clearer decisions and better review conversations. Built for consistency, comparability, and later defensibility under audit or management challenge. A useful ISO 27005 assessment record does more than assign a score. It shows the scenario, the affected assets or services, the reasoning behind consequence and likelihood, the uncertainty in the assessment, the responsible risk owner, and whether the result crosses the acceptance threshold. This template is designed to capture all of that without turning the process into paperwork for its own sake. ## Recommended workbook structure Use one controlled workbook or system structure across the organization. If every team invents its own fields, risk reviews become argument sessions about format instead of decisions about exposure. Keep the method visible alongside the records so reviewers can see how the result was produced. - Method tab: scope, definitions, scoring scales, uncertainty rules, review triggers - Context tab: assets, services, owners, dependencies, external parties, assumptions - Assessment tab: one row or record per risk scenario - Evaluation tab: acceptance decision, priority, treatment requirement, and next action - Evidence tab: links to incidents, monitoring, audit findings, architecture notes, supplier information, or threat data ## Field set for each risk record The fields below are designed to make the record understandable six months later by someone who was not in the original workshop. That is the standard you should optimize for. Where evidence is thin, capture that uncertainty explicitly rather than hiding it behind a false sense of scoring precision. - Risk ID, short title, detailed scenario description, and affected business service or information asset - Risk owner, contributors, and any third-party dependencies involved in the scenario - Threat or event description, vulnerability or weakness, and preconditions or exposure path - Existing controls and their current effectiveness or limitations - Consequence rationale across the categories that matter to the organization - Likelihood rationale, supporting signals, and confidence level - Uncertainty notes explaining where the assessment is weak or assumption-dependent - Final level of risk, acceptance decision, and treatment priority *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep ISO 27005 Risk assessment template in one governed evidence system SSOT can take ISO 27005 Risk assessment template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on ISO 27005 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for ISO 27005 Risk assessment template](/solutions/ssot.md): Start from ISO 27005 Risk assessment template and keep documents, evidence, and control records in one governed system. - [Talk through ISO 27005](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27005 Risk assessment template. ## Quality checks that make the template usable A good template only stays good if it is governed. The fastest quality gain usually comes from calibration sessions, peer review of high-risk items, and forcing rationale fields to be written in plain language rather than shorthand. Use the same template in risk reviews, management reporting, and treatment planning so the handoff is clean. - Require written rationale for all high-risk or exception-based assessments - Review a sample of assessments periodically for scoring consistency - Carry the same risk ID into treatment plans, audit findings, and review records ## Primary sources - [ISO/IEC 27005:2022 standard page](https://www.iso.org/standard/80585.html?ref=sorena.io) - Primary current source for ISO/IEC 27005 positioning and scope. - [NIST SP 800-30 Rev. 1 PDF](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-30r1.pdf?ref=sorena.io) - Useful public guidance for assessment structure, risk factors, uncertainty, and communicating assessment results. ## Related Topic Guides - [ISO 27005 Compliance Playbook](/artifacts/global/iso-27005/compliance.md): Operationalize ISO/IEC 27005:2022 with a practical playbook for context, criteria, risk assessment, risk treatment, residual risk acceptance, communication. - [ISO 27005 FAQ](/artifacts/global/iso-27005/faq.md): Answers to common ISO/IEC 27005 questions on risk criteria, acceptance criteria, risk owners, treatment plans, residual risk, NIST comparisons. - [ISO 27005 Risk Treatment Plan Template](/artifacts/global/iso-27005/risk-treatment-plan-template.md): Use this ISO/IEC 27005 risk treatment plan template to document treatment options, selected actions, owners, milestones, evidence links, acceptance criteria. - [ISO 27005 vs NIST SP 800-30](/artifacts/global/iso-27005/iso-27005-vs-nist-800-30.md): Compare ISO/IEC 27005 and NIST SP 800-30 to see how information security risk management guidance and risk assessment guidance fit together. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27005/risk-assessment-template --- --- title: "ISO 27005 Risk Treatment Plan Template" canonical_url: "https://www.sorena.io/artifacts/global/iso-27005/risk-treatment-plan-template" source_url: "https://www.sorena.io/artifacts/global/iso-27005/risk-treatment-plan-template" author: "Sorena AI" description: "Use this ISO/IEC 27005 risk treatment plan template to document treatment options, selected actions, owners, milestones, evidence links, acceptance criteria." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27005 risk treatment plan template" - "ISO 27005 RTP" - "risk treatment plan" - "residual risk acceptance" - "risk owner approval" - "treatment option template" - "GLOBAL compliance" - "ISO/IEC 27005" - "Template" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27005 Risk Treatment Plan Template Use this ISO/IEC 27005 risk treatment plan template to document treatment options, selected actions, owners, milestones, evidence links, acceptance criteria. *Template* *GLOBAL* ## ISO 27005 Risk treatment plan template Use this template to turn assessed risks into owned action with explicit residual risk decisions. Designed for reviewability, accountability, and cleaner audit evidence. A risk treatment plan should do more than list controls. It should explain the chosen treatment option, the actions that will be taken, who owns delivery, what success looks like, what evidence will show progress, and what residual risk remains after treatment. This template is designed to make those elements visible in one place. ## Recommended structure for a treatment plan Keep one consistent structure across the organization so leadership and auditors can read treatment plans quickly. The plan should be understandable to risk owners, delivery teams, and governance reviewers without translation. Each plan should link back to the originating risk record so the treatment rationale stays visible. - Header: scope, owner, version, approval state, last update, next review date - Treatment rows: one row per risk or per major treatment stream depending on scale - Decision section: selected treatment option, expected residual risk, approver, and conditions ## Field set for each treatment item The fields below are designed to make treatment status auditable and useful in management review. If a field cannot be populated, you probably have an ownership or evidence problem rather than only a template problem. Write items as commitments that can be tested later, not as generic aspirations. - Risk ID and short description pulled directly from the assessment record - Selected treatment option such as modify, retain, avoid, or share, with rationale - Treatment owner and risk owner, with clear distinction where they differ - Specific actions or controls to be implemented or changed - Milestones, target dates, dependencies, and blockers - Acceptance criteria showing how success will be judged - Evidence links for tickets, test results, monitoring, approvals, or configuration proof - Expected residual risk and the authority level required for acceptance ## How to handle residual risk well Residual risk acceptance should not be implicit. The plan should say whether residual exposure will be accepted, under what conditions, by whom, and until when if the acceptance is time-bound. This is especially important where treatment is staged over time and the organization is temporarily accepting a higher level of exposure while the plan is still in flight. - Record the approver, the date, the conditions, and the re-review trigger - Escalate approvals that exceed the normal authority threshold - Treat missed milestones or failed controls as triggers for reassessment, not only project delays ## Tie the plan back into the ISMS Treatment plans should connect directly to the wider ISMS evidence model. If the treatment involves control implementation, the relevant control records, operating evidence, and later review outputs should all point back to the same risk identifier. This prevents treatment work from becoming detached from the risk decision that justified it. - Cross-link treatment items to the risk register, control evidence, audit findings, and management review outputs - Use one action status model across security, engineering, and governance teams so progress reads consistently *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep ISO 27005 Risk treatment plan template in one governed evidence system SSOT can take ISO 27005 Risk treatment plan template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on ISO 27005 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for ISO 27005 Risk treatment plan template](/solutions/ssot.md): Start from ISO 27005 Risk treatment plan template and keep documents, evidence, and control records in one governed system. - [Talk through ISO 27005](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27005 Risk treatment plan template. ## Primary sources - [ISO/IEC 27005:2022 standard page](https://www.iso.org/standard/80585.html?ref=sorena.io) - Primary current source for ISO/IEC 27005 and its risk treatment scope. - [ISO/IEC 27001:2022 standard page](https://www.iso.org/standard/27001?ref=sorena.io) - Useful requirements context for how treatment decisions support an ISMS. ## Related Topic Guides - [ISO 27005 Compliance Playbook](/artifacts/global/iso-27005/compliance.md): Operationalize ISO/IEC 27005:2022 with a practical playbook for context, criteria, risk assessment, risk treatment, residual risk acceptance, communication. - [ISO 27005 FAQ](/artifacts/global/iso-27005/faq.md): Answers to common ISO/IEC 27005 questions on risk criteria, acceptance criteria, risk owners, treatment plans, residual risk, NIST comparisons. - [ISO 27005 Risk Assessment Template](/artifacts/global/iso-27005/risk-assessment-template.md): Use this ISO/IEC 27005 risk assessment template to capture context, criteria, scenario details, likelihood, consequence, uncertainty, risk owner, evaluation. - [ISO 27005 vs NIST SP 800-30](/artifacts/global/iso-27005/iso-27005-vs-nist-800-30.md): Compare ISO/IEC 27005 and NIST SP 800-30 to see how information security risk management guidance and risk assessment guidance fit together. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27005/risk-treatment-plan-template --- --- title: "ISO 27017 Cloud Provider Checklist (Due Diligence + Evidence)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27017/cloud-provider-checklist" source_url: "https://www.sorena.io/artifacts/global/iso-27017/cloud-provider-checklist" author: "Sorena AI" description: "ISO/IEC 27017 cloud provider checklist for due diligence: what to ask, what evidence to request." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27017 cloud provider checklist" - "ISO 27017 vendor due diligence" - "ISO 27017 cloud security checklist" - "ISO 27017 audit evidence" - "ISO 27017 compliance checklist" - "cloud provider security questionnaire ISO 27017" - "shared responsibility model checklist" - "GLOBAL compliance" - "ISO/IEC 27017" - "Cloud provider checklist" - "Cloud security due diligence" - "Audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27017 Cloud Provider Checklist (Due Diligence + Evidence) ISO/IEC 27017 cloud provider checklist for due diligence: what to ask, what evidence to request. *Checklist* *GLOBAL* ## ISO 27017 Cloud Provider Checklist Due diligence questions and evidence artifacts for cloud provider selection and assurance. Aligned to ISO/IEC 27017 guidance for cloud service customers and cloud service providers. ISO/IEC 27017 is useful for cloud due diligence because it forces clarity on shared responsibility and cloud-specific control operation. The standard is explicit that responsibilities should be agreed and documented in the agreement, and it gives concrete guidance on areas such as geographical data locations, backup specifications, incident-notification allocation, return and removal of customer assets at termination, and segregation in shared virtual environments. ## What ISO 27017 adds to a cloud provider security review ISO/IEC 27017 provides additional cloud-specific implementation guidance for controls based on ISO/IEC 27002, plus additional controls that specifically relate to cloud services. The key outcome for due diligence is avoiding responsibility gaps. Responsibilities must be agreed and documented, and evidence should show that controls operate as promised. - Define responsibility allocation (provider vs customer) and embed it in the agreement - Validate cloud-specific technical controls (virtualization, tenant isolation, admin tooling) - Collect repeatable evidence (logs, test results, review records) instead of one-off statements ## Pre-contract due diligence checklist (what to ask and why) Use these categories as your top-level checklist, then tailor the questions to IaaS, PaaS, or SaaS. Ask for evidence, not only narratives, and record what is contractually guaranteed versus best effort. - Scope + service model: what you operate vs what the provider operates (IaaS/PaaS/SaaS boundary) - Shared responsibility: documented role allocation, support model, and escalation paths - Data location and jurisdictions: where data can be stored, processed, or transmitted and how that is disclosed to the customer - Virtualization and multi-tenancy: tenant isolation model, hypervisor security, and segregation mechanisms - Identity and access: privileged access management, customer admin roles, and access review cadence - Logging and monitoring: what telemetry exists, who logs what in IaaS or higher-level services, retention, customer access, and alerting expectations - Data lifecycle: backup and restore ownership, backup specifications, retention, secure deletion, and return or removal of customer assets at termination - Suppliers and sub-processors: transparency, contractual flow-down, and assurance reporting *Recommended next step* *Placement: after the checklist block* ## Turn ISO 27017 Cloud Provider Checklist into an operational assessment Assessment Autopilot can take ISO 27017 Cloud Provider Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on ISO 27017 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 27017 Cloud Provider Checklist](/solutions/assessment.md): Start from ISO 27017 Cloud Provider Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 27017](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27017 Cloud Provider Checklist. ## Contract and SLA clauses to align to ISO 27017 ISO 27017 guidance is easiest to operationalize when you translate it into enforceable obligations and measurable service requirements. Avoid ambiguous language; make responsibilities, disclosure duties, and evidence delivery explicit. - Responsibility allocation: who performs backups, recovery, logging, monitoring, and incident response steps under the service agreement - Provider disclosures: geographic data locations and service functionality that supports classification and labeling - Change and incident notifications: timelines, channels, scope of incidents reported, target notification timeframe, and post-incident artifacts - Secure deletion and termination: deletion method, verification or attestation, and data return or removal mechanisms - Customer access: admin access methods, audit logging, and limitations/constraints documented up-front ## Evidence artifacts to request (and keep current) A strong evidence pack is the fastest way to pass procurement, customer assurance, and audits. Keep it versioned and refresh it on material changes. Request provider evidence that maps to control operation, not only policy statements. - Responsibility matrix and cloud service agreement excerpts that implement it - Disclosures: data location, legal jurisdictions, subcontractors, and customer-facing security responsibilities - Procedures and proof: access administration records, change control, backup specifications, restore test results, and deletion attestations - Logs and monitoring: sample audit logs, retention settings, alerting runbooks, incident postmortems - Assurance reports: ISO 27001 certificates, SOC reports, penetration testing summaries (where available) ## Customer responsibilities checklist (what providers expect you to do) ISO 27017 is explicit that customers have responsibilities too. If customers don't operate their part of the model, controls fail even when the provider is strong. Make these responsibilities visible to engineering teams and include them in onboarding and change management. - Tenant IAM: MFA, privileged roles, access reviews, and break-glass procedures - Configuration baselines: network segmentation, encryption settings, and secure defaults - Data governance: classification and labeling procedures, retention, and secure handling requirements - Monitoring and incident response: what you will detect, how you will respond, and how you coordinate with the provider ## Primary sources - [ISO/IEC 27017:2015 - ISO standard page (Reference 43757)](https://www.iso.org/standard/43757.html?ref=sorena.io) - Primary source for ISO/IEC 27017 scope, abstract, and lifecycle information. - [ITU-T X.1631 - identical text to ISO/IEC 27017](https://www.itu.int/rec/T-REC-X.1631/en?ref=sorena.io) - ISO/IEC 27017 is published with identical text as ITU-T X.1631. - [ISO/IEC 27001 - ISO standard page](https://www.iso.org/standard/27001?ref=sorena.io) - ISMS requirements where ISO/IEC 27017 evidence is commonly mapped (SoA and audit readiness). ## Related Topic Guides - [ISO 27017 Compliance (Cloud Controls Implementation Playbook)](/artifacts/global/iso-27017/compliance.md): A practical ISO/IEC 27017 compliance playbook for cloud security controls: scope, shared responsibility, cloud-specific control implementation. - [ISO 27017 Control Mapping to ISO 27001 (SoA + Evidence)](/artifacts/global/iso-27017/control-mapping-to-iso-27001.md): How to map ISO/IEC 27017 cloud security guidance to an ISO/IEC 27001 ISMS: Statement of Applicability, control owners, shared responsibility. - [ISO 27017 FAQ (Cloud Security Controls, Audit, and Evidence)](/artifacts/global/iso-27017/faq.md): Frequently asked questions about ISO/IEC 27017: what it is, how it relates to ISO 27001 and ISO 27002, shared responsibility in cloud security. - [ISO 27017 Shared Responsibility Model (Provider vs Customer)](/artifacts/global/iso-27017/shared-responsibility-model.md): A practical ISO/IEC 27017 shared responsibility model for cloud services: who owns which security responsibilities in IaaS, PaaS, and SaaS. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27017/cloud-provider-checklist --- --- title: "ISO 27017 Compliance (Cloud Controls Implementation Playbook)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27017/compliance" source_url: "https://www.sorena.io/artifacts/global/iso-27017/compliance" author: "Sorena AI" description: "A practical ISO/IEC 27017 compliance playbook for cloud security controls: scope, shared responsibility, cloud-specific control implementation." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27017 compliance" - "ISO/IEC 27017 implementation guide" - "ISO 27017 audit readiness" - "ISO 27017 cloud security controls" - "ISO 27017 shared responsibility model" - "ISO 27017 evidence pack" - "ISO 27017 mapping to ISO 27001" - "GLOBAL compliance" - "ISO/IEC 27017" - "Cloud security controls" - "Compliance playbook" - "Audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27017 Compliance (Cloud Controls Implementation Playbook) A practical ISO/IEC 27017 compliance playbook for cloud security controls: scope, shared responsibility, cloud-specific control implementation. *Playbook* *GLOBAL* ## ISO 27017 Compliance An implementation playbook for cloud security controls based on ISO/IEC 27017. Designed for cloud security teams, ISMS owners, and anyone who needs audit-ready evidence for cloud services. ISO/IEC 27017 provides guidelines for information security controls applicable to the provision and use of cloud services by adding cloud-specific implementation guidance based on ISO/IEC 27002 and additional cloud-service controls. In practice, strong implementation means you can show clear shared responsibility in the agreement, cloud-specific control operation for multi-tenancy and virtualization, timely handling of asset return and deletion on termination, and evidence that both provider and customer responsibilities are actually operating. ## What ISO 27017 compliance should look like in practice ISO 27017 is a code of practice, so the practical goal is not checkbox compliance. The goal is control clarity and evidence quality in cloud environments. Teams succeed when they treat ISO 27017 as cloud-sector guidance that strengthens the ISO 27002 control baseline and supports ISO 27001 audit evidence. - Outcome to target: a documented shared responsibility model that is implemented in contracts and operating procedures - Cloud focus: secure multi-tenancy, virtualization security, admin operations, logging/monitoring, and data lifecycle controls - Audit reality: evidence must be attributable, current, and traceable to control operation *Recommended next step* *Placement: after the compliance steps* ## Turn ISO 27017 Compliance into an operational assessment Assessment Autopilot can take ISO 27017 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on ISO 27017 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 27017 Compliance](/solutions/assessment.md): Start from ISO 27017 Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 27017](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27017 Compliance. ## Step 1 - Define scope and shared responsibility Start with the service model boundary (IaaS/PaaS/SaaS) and define who is responsible for each security task. ISO 27017 guidance expects roles and responsibilities to be agreed and documented (typically in the agreement). Make responsibilities operational by assigning owners, escalation paths, and a review cadence. This is the fastest way to prevent gaps in backups, logging, deletion, and incident coordination. - Deliverables: responsibility matrix, RACI, and cloud service agreement clauses that reflect the allocation - Evidence: review records showing the matrix is updated when services change - Coordination: define how customer and provider coordinate on incidents, changes, investigations, and customer-support escalation ## Step 2 - Implement cloud-specific controls that commonly fail audits ISO 27017 guidance highlights cloud-specific risks that are easy to underestimate: multi-tenancy, virtualization security, and control operation across organizational boundaries. Prioritize a few control themes that create the most audit and customer risk if they are unclear. - Asset inventory and data categories: explicitly identify customer data and cloud service derived data; document ownership and handling rules - Virtualization and tenant isolation: document isolation approach, hardening practices, and monitoring for isolation failures - Identity and access administration: privileged role model, access review cadence, and customer admin guidance - Logging and monitoring: define which logs exist, who can access them, retention, and alerting/response procedures - Data lifecycle: backup and restore ownership and testing, retention rules, secure deletion, and asset return or removal at termination ## Step 3 - Build an evidence pack that maps to ISO 27001 Most organizations consume ISO 27017 guidance through an ISO 27001 ISMS. The evidence should map cleanly to your Statement of Applicability and control operation story. Build evidence once, reuse it for procurement, customer assurance, and audits. - Control mapping: map ISO 27017 guidance to your ISO 27002/ISO 27001 control set and SoA entries - Evidence standards: define what acceptable evidence is for each control, including logs, tests, approvals, and reviews - Operating cadence: periodic reviews, sampling, exception management, and corrective actions ## Step 4 - Operating cadence (keep the cloud control posture current) Cloud environments change constantly: services, regions, account structures, and platforms evolve. Compliance fails when evidence does not keep up with change. Define a cadence that ties change management, security monitoring, and periodic control reviews together. - Trigger-based reviews: reassess responsibility allocation and key controls on major cloud changes - Periodic testing: restore tests, privileged access reviews, logging pipeline checks, and incident response exercises - Management visibility: dashboards and reporting that tie cloud control operation to business risk ## Primary sources - [ISO/IEC 27017:2015 - ISO standard page (Reference 43757)](https://www.iso.org/standard/43757.html?ref=sorena.io) - Primary source for ISO/IEC 27017 scope, abstract, and lifecycle information. - [ITU-T X.1631 - identical text to ISO/IEC 27017](https://www.itu.int/rec/T-REC-X.1631/en?ref=sorena.io) - ISO/IEC 27017 is published with identical text as ITU-T X.1631. - [ISO/IEC 27001 - ISO standard page](https://www.iso.org/standard/27001?ref=sorena.io) - ISMS requirements where ISO/IEC 27017 guidance is commonly applied and evidenced. - [ISO/IEC 27002 - ISO standard page](https://www.iso.org/standard/75652.html?ref=sorena.io) - ISO/IEC 27017 provides cloud-specific implementation guidance based on ISO/IEC 27002 controls. ## Related Topic Guides - [ISO 27017 Cloud Provider Checklist (Due Diligence + Evidence)](/artifacts/global/iso-27017/cloud-provider-checklist.md): ISO/IEC 27017 cloud provider checklist for due diligence: what to ask, what evidence to request. - [ISO 27017 Control Mapping to ISO 27001 (SoA + Evidence)](/artifacts/global/iso-27017/control-mapping-to-iso-27001.md): How to map ISO/IEC 27017 cloud security guidance to an ISO/IEC 27001 ISMS: Statement of Applicability, control owners, shared responsibility. - [ISO 27017 FAQ (Cloud Security Controls, Audit, and Evidence)](/artifacts/global/iso-27017/faq.md): Frequently asked questions about ISO/IEC 27017: what it is, how it relates to ISO 27001 and ISO 27002, shared responsibility in cloud security. - [ISO 27017 Shared Responsibility Model (Provider vs Customer)](/artifacts/global/iso-27017/shared-responsibility-model.md): A practical ISO/IEC 27017 shared responsibility model for cloud services: who owns which security responsibilities in IaaS, PaaS, and SaaS. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27017/compliance --- --- title: "ISO 27017 Control Mapping to ISO 27001 (SoA + Evidence)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27017/control-mapping-to-iso-27001" source_url: "https://www.sorena.io/artifacts/global/iso-27017/control-mapping-to-iso-27001" author: "Sorena AI" description: "How to map ISO/IEC 27017 cloud security guidance to an ISO/IEC 27001 ISMS: Statement of Applicability, control owners, shared responsibility." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27017 mapping to ISO 27001" - "ISO 27017 control mapping" - "ISO 27017 SoA" - "ISO 27001 statement of applicability cloud" - "ISO 27017 audit evidence mapping" - "ISO 27017 shared responsibility model ISO 27001" - "GLOBAL compliance" - "ISO/IEC 27017" - "ISO/IEC 27001" - "Statement of Applicability" - "Control mapping" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27017 Control Mapping to ISO 27001 (SoA + Evidence) How to map ISO/IEC 27017 cloud security guidance to an ISO/IEC 27001 ISMS: Statement of Applicability, control owners, shared responsibility. *Mapping* *GLOBAL* ## ISO 27017 Control Mapping to ISO 27001 Map ISO/IEC 27017 cloud guidance into an ISO/IEC 27001 ISMS that auditors can follow. Focus on SoA entries, shared responsibility, and evidence artifacts - not generic mapping tables. Most organizations implement ISO/IEC 27017 as cloud-sector guidance on top of their ISO/IEC 27001 ISMS. A good mapping connects the cloud responsibility boundary to control ownership and evidence. This page gives a mapping method you can apply across IaaS, PaaS, and SaaS, and shows how to translate concrete ISO 27017 themes such as shared roles and responsibilities, asset return at termination, segregation in shared virtual environments, and alignment of virtual and physical network security into SoA wording and audit-ready artifacts. ## Mapping principle: ISO 27017 strengthens the cloud story for ISO 27001 ISO/IEC 27017 provides cloud-specific implementation guidance for controls based on ISO/IEC 27002, plus additional controls for cloud services. ISO/IEC 27001 auditors typically look for: defined scope, risk treatment, SoA justification, control operation, and evidence. ISO 27017 helps you make cloud-specific responsibility and control operation explicit. - Map cloud guidance into SoA language and control procedures (not just a spreadsheet) - Attach a responsibility matrix to each relevant control so ownership is unambiguous - Define evidence expectations per control (logs, tests, approvals, reviews) ## Step-by-step mapping method (repeatable for every cloud service) Use this method per cloud service or per cloud platform landing zone. Keep the mapping versioned and update it when the service model changes. Make the mapping operational: every mapped control should produce evidence on a cadence. - 1) Identify the cloud service model (IaaS/PaaS/SaaS) and define the responsibility boundary - 2) Select relevant ISO 27002 controls and add ISO 27017 cloud-specific guidance as implementation requirements - 3) Update SoA: applicability, justification, and reference to cloud procedures and agreements - 4) Assign owners: provider-side owner (where applicable), customer-side owner, and evidence producer - 5) Define evidence: what will be collected, where it lives, retention, and sampling approach - 6) Define operating cadence: reviews, tests, restore exercises, access reviews, and corrective actions ## Examples: cloud-specific mapping patterns that auditors understand These examples show how ISO 27017 guidance often appears in an ISO 27001 audit story. Use them as templates and tailor to your provider/customer split. Treat each example as a pattern: procedure + owner + evidence + cadence. - Asset inventory and data categories: explicitly identify cloud customer data and cloud-derived data; document ownership and handling - Information classification and labeling: customer procedure + provider functionality disclosures that support classification/labeling in the service - Access control for cloud network services: customer policy specifying access requirements per cloud service and evidence of enforcement - Geographic data locations: provider disclosures captured as evidence and assessed for jurisdiction and legal constraints - Backups, recovery, and secure deletion: ownership and verification method documented; restore tests and deletion attestations retained - Asset return and removal at termination: agreement clauses, termination procedure, and proof of timely return, removal, and deletion - Shared virtual environments: segregation controls, virtual-machine hardening, and evidence that customer and provider admin boundaries are protected ## Deliverables checklist (what to produce for audits and assurance) If you can produce these artifacts consistently, your ISO 27001 audits and customer assurance reviews become dramatically easier. Build once, reuse everywhere: procurement, security reviews, and audit cycles. - Cloud shared responsibility matrix (IaaS/PaaS/SaaS) tied to your control set - SoA entries that reference cloud procedures, agreements, and evidence locations - Evidence index: what exists, where it lives, and the review cadence - Exception register for cloud control deviations with approvals and remediation plans *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep ISO 27017 Control Mapping to ISO 27001 in one governed evidence system SSOT can take ISO 27017 Control Mapping to ISO 27001 from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on ISO 27017 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for ISO 27017 Control Mapping to ISO 27001](/solutions/ssot.md): Start from ISO 27017 Control Mapping to ISO 27001 and keep documents, evidence, and control records in one governed system. - [Talk through ISO 27017](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27017 Control Mapping to ISO 27001. ## Primary sources - [ISO/IEC 27017:2015 - ISO standard page (Reference 43757)](https://www.iso.org/standard/43757.html?ref=sorena.io) - Primary source for ISO/IEC 27017 scope, abstract, and lifecycle information. - [ISO/IEC 27001 - ISO standard page](https://www.iso.org/standard/27001?ref=sorena.io) - ISMS requirements and audit expectations where ISO/IEC 27017 guidance is commonly applied. - [ISO/IEC 27002 - ISO standard page](https://www.iso.org/standard/75652.html?ref=sorena.io) - ISO/IEC 27017 provides cloud-specific implementation guidance based on ISO/IEC 27002 controls. ## Related Topic Guides - [ISO 27017 Cloud Provider Checklist (Due Diligence + Evidence)](/artifacts/global/iso-27017/cloud-provider-checklist.md): ISO/IEC 27017 cloud provider checklist for due diligence: what to ask, what evidence to request. - [ISO 27017 Compliance (Cloud Controls Implementation Playbook)](/artifacts/global/iso-27017/compliance.md): A practical ISO/IEC 27017 compliance playbook for cloud security controls: scope, shared responsibility, cloud-specific control implementation. - [ISO 27017 FAQ (Cloud Security Controls, Audit, and Evidence)](/artifacts/global/iso-27017/faq.md): Frequently asked questions about ISO/IEC 27017: what it is, how it relates to ISO 27001 and ISO 27002, shared responsibility in cloud security. - [ISO 27017 Shared Responsibility Model (Provider vs Customer)](/artifacts/global/iso-27017/shared-responsibility-model.md): A practical ISO/IEC 27017 shared responsibility model for cloud services: who owns which security responsibilities in IaaS, PaaS, and SaaS. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27017/control-mapping-to-iso-27001 --- --- title: "ISO 27017 FAQ (Cloud Security Controls, Audit, and Evidence)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27017/faq" source_url: "https://www.sorena.io/artifacts/global/iso-27017/faq" author: "Sorena AI" description: "Frequently asked questions about ISO/IEC 27017: what it is, how it relates to ISO 27001 and ISO 27002, shared responsibility in cloud security." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27017 FAQ" - "ISO/IEC 27017 explained" - "ISO 27017 vs ISO 27001" - "ISO 27017 vs ISO 27002" - "ISO 27017 shared responsibility model" - "ISO 27017 audit" - "ISO 27017 compliance" - "cloud security controls ISO 27017" - "GLOBAL compliance" - "ISO/IEC 27017" - "Cloud security controls" - "FAQ" - "Shared responsibility model" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27017 FAQ (Cloud Security Controls, Audit, and Evidence) Frequently asked questions about ISO/IEC 27017: what it is, how it relates to ISO 27001 and ISO 27002, shared responsibility in cloud security. *FAQ* *GLOBAL* ## ISO 27017 FAQ Quick answers to real ISO/IEC 27017 implementation questions. Focus on shared responsibility, audit evidence, and what changes operationally in cloud environments. ISO/IEC 27017 provides guidelines for information security controls applicable to the provision and use of cloud services by adding cloud-specific implementation guidance (based on ISO/IEC 27002) and additional controls related to cloud services. These FAQs cover what teams actually need: how to use ISO 27017 with ISO 27001, how to define shared responsibility, and how to build evidence that survives audits and customer assurance reviews. ## What is ISO/IEC 27017? ISO/IEC 27017 is a code of practice for information security controls for cloud services. It provides additional cloud-specific implementation guidance for relevant controls specified in ISO/IEC 27002, and adds controls that specifically relate to cloud services. It is written for both cloud service providers and cloud service customers, with guidance that helps clarify roles and responsibilities across the shared responsibility boundary. - Best use: implementable guidance for cloud control operation rather than a generic checklist - Key value: responsibility clarity for multi-party cloud service delivery and use ## How does ISO 27017 relate to ISO 27001 and ISO 27002? ISO/IEC 27001 defines ISMS requirements. ISO/IEC 27002 provides a control catalogue and guidance. ISO/IEC 27017 adds cloud-specific guidance on top of the ISO/IEC 27002 control baseline for organizations that provide or use cloud services. In practice, many teams map ISO 27017 guidance into their ISO 27001 Statement of Applicability and cloud operating procedures. - Use ISO 27001 as the management system and audit structure - Use ISO 27002 as the baseline control set - Use ISO 27017 to make cloud responsibility boundaries and cloud-specific control operation explicit ## What is the ISO 27017 shared responsibility model in plain language? Shared responsibility means the provider and the customer each own some security responsibilities - and those responsibilities must be explicitly agreed and documented (often as part of the cloud service agreement). The biggest risk is a responsibility gap (e.g., both parties assume the other performs backups, logging, secure deletion, or incident notifications). - Create a responsibility matrix for IaaS/PaaS/SaaS and tie it to owners - Make operational tasks explicit: backups, logging, monitoring, change management, incident coordination, secure deletion - Treat the matrix as a living document updated on material cloud changes ## What evidence do auditors and customers expect for ISO 27017? ISO 27017 succeeds when you can show evidence that the responsibility model is operating in practice. Auditors and customer security reviewers tend to ask for the same artifacts. Evidence quality matters more than volume: it should be current, attributable, and traceable to control operation. - Responsibility matrix + RACI, plus agreement clauses that implement it - Cloud procedures: access administration, logging/monitoring, backup/restore, secure deletion, change and incident handling - Evidence samples: access reviews, restore test results, incident postmortems, monitoring alerts and response records ## Do cloud providers and cloud customers both use ISO 27017? Yes. ISO 27017 provides guidance for both cloud service providers and cloud service customers. Providers use it to define and operate cloud control responsibilities and disclosures. Customers use it to define what they must do inside their tenant and what they must require from providers (and validate with evidence). The most effective implementations use one shared responsibility model that both parties can explain. - Provider focus: transparency, platform control operation, and customer-facing guidance - Customer focus: tenant configuration, identity, monitoring, and coordinating with the provider ## Is ISO 27017 a certification standard? ISO 27017 is a code of practice and guidance standard. Organizations commonly use it to strengthen their ISO 27001 controls for cloud environments and to support assurance conversations with customers and procurement teams. If you need certification outcomes, the practical path is usually ISO 27001 certification with clear cloud scope and evidence that ISO 27017 guidance is implemented where relevant. - Avoid marketing-only claims: focus on demonstrable control operation and evidence - Anchor cloud claims in your ISO 27001 scope, SoA, and supporting procedures ## How do we handle data location and jurisdiction questions? Data location and jurisdiction questions are central in cloud risk and procurement. Providers should disclose relevant geographic locations where customer data can be stored or processed. Customers should use that disclosure to determine relevant supervisory authorities and legal constraints. Record the decision and refresh it when regions, services, or data classifications change. - Provider deliverable: clear data location disclosures and update mechanism - Customer deliverable: documented assessment and approval for the chosen regions/jurisdictions ## What are the biggest ISO 27017 implementation pitfalls? The most common pitfall is writing a responsibility matrix but not operating it. The second is collecting evidence without tying it to responsibilities and control operation. Treat ISO 27017 like an operating model for cloud controls and evidence, not a policy exercise. - Responsibility gaps (backup, logging, deletion, incident coordination) - Evidence gaps (no restore tests, no access reviews, no monitoring validation) - Stale documentation (service model changes without updating the matrix and SoA) ## Where should we start if we have limited time? Start with shared responsibility and three evidence-heavy control themes: access administration, logging/monitoring, and data lifecycle (backup/restore and deletion). Then expand outward. This creates immediate risk reduction and makes audits and procurement reviews much easier. - Build the responsibility matrix and embed it in agreements and procedures - Define evidence per control and put it on a cadence (monthly/quarterly, plus change-triggered) - Map the result to ISO 27001 SoA wording for audit traceability *Recommended next step* *Placement: after the FAQ section* ## Use ISO 27017 FAQ as a cited research workflow Research Copilot can take ISO 27017 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on ISO 27017 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO 27017 FAQ](/solutions/research-copilot.md): Start from ISO 27017 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO 27017](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27017 FAQ. ## Primary sources - [ISO/IEC 27017:2015 - ISO standard page (Reference 43757)](https://www.iso.org/standard/43757.html?ref=sorena.io) - Primary source for ISO/IEC 27017 scope, abstract, and lifecycle information. - [ITU-T X.1631 - identical text to ISO/IEC 27017](https://www.itu.int/rec/T-REC-X.1631/en?ref=sorena.io) - ISO/IEC 27017 is published with identical text as ITU-T X.1631. - [ISO/IEC 27001 - ISO standard page](https://www.iso.org/standard/27001?ref=sorena.io) - ISMS requirements where ISO/IEC 27017 guidance is commonly applied. ## Related Topic Guides - [ISO 27017 Cloud Provider Checklist (Due Diligence + Evidence)](/artifacts/global/iso-27017/cloud-provider-checklist.md): ISO/IEC 27017 cloud provider checklist for due diligence: what to ask, what evidence to request. - [ISO 27017 Compliance (Cloud Controls Implementation Playbook)](/artifacts/global/iso-27017/compliance.md): A practical ISO/IEC 27017 compliance playbook for cloud security controls: scope, shared responsibility, cloud-specific control implementation. - [ISO 27017 Control Mapping to ISO 27001 (SoA + Evidence)](/artifacts/global/iso-27017/control-mapping-to-iso-27001.md): How to map ISO/IEC 27017 cloud security guidance to an ISO/IEC 27001 ISMS: Statement of Applicability, control owners, shared responsibility. - [ISO 27017 Shared Responsibility Model (Provider vs Customer)](/artifacts/global/iso-27017/shared-responsibility-model.md): A practical ISO/IEC 27017 shared responsibility model for cloud services: who owns which security responsibilities in IaaS, PaaS, and SaaS. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27017/faq --- --- title: "ISO 27017 Shared Responsibility Model (Provider vs Customer)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27017/shared-responsibility-model" source_url: "https://www.sorena.io/artifacts/global/iso-27017/shared-responsibility-model" author: "Sorena AI" description: "A practical ISO/IEC 27017 shared responsibility model for cloud services: who owns which security responsibilities in IaaS, PaaS, and SaaS." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27017 shared responsibility model" - "ISO/IEC 27017 provider responsibilities" - "ISO/IEC 27017 customer responsibilities" - "cloud shared responsibility model IaaS PaaS SaaS" - "cloud security responsibility matrix" - "ISO 27017 compliance" - "ISO 27017 audit evidence" - "GLOBAL compliance" - "ISO/IEC 27017" - "Shared responsibility model" - "Cloud service provider" - "Cloud service customer" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27017 Shared Responsibility Model (Provider vs Customer) A practical ISO/IEC 27017 shared responsibility model for cloud services: who owns which security responsibilities in IaaS, PaaS, and SaaS. *Model* *GLOBAL* ## ISO 27017 Shared Responsibility Model Turn provider-versus-customer ambiguity into a responsibility matrix your engineers and auditors can use. Aligned to ISO/IEC 27017 guidance for cloud service customers and cloud service providers. ISO/IEC 27017 emphasizes that cloud security is a shared responsibility: cloud service customers and cloud service providers must agree, document, and operate an allocation of information security roles and responsibilities. The standard goes further than a generic matrix by grounding responsibility in the agreement, clarifying that the customer remains accountable for the decision to use the service while the provider is accountable for the security stated in the cloud service agreement, and tying that split to concrete areas such as incident handling, data location, backups, and termination. ## What ISO 27017 means by shared responsibility ISO/IEC 27017 provides cloud-specific implementation guidance for information security controls based on ISO/IEC 27002. A central theme is avoiding responsibility gaps between cloud service customers and cloud service providers. The standard's guidance expects both parties to agree on and document a clear allocation of roles and responsibilities (typically in the cloud service agreement), and to operate the service according to that allocation. - Write it down: responsibility allocation belongs in the agreement and supporting procedures - Be explicit about operational tasks (e.g., backups, recovery, logging, change management) so nothing falls between the cracks - Customer accountability still exists: the customer remains accountable for the decision to use the service; the provider is accountable for the security promised in the service agreement ## Responsibility matrix by service model (IaaS vs PaaS vs SaaS) A useful responsibility matrix is service-model specific. It should answer: who configures, who operates, who monitors, who approves changes, and who provides evidence. Start with a few control themes that frequently fail in cloud audits, then expand to the full control inventory. - Identity and access: provider identity plane vs customer tenant IAM, privileged roles, and admin tooling - Virtualization and tenant isolation: hypervisor/platform controls (provider) vs tenant configuration hardening (customer) - Logging and monitoring: provider platform telemetry vs customer security monitoring and incident handling in the tenant - Data lifecycle: classification and labelling, access controls, backups, retention, secure deletion, and return of assets - Geography and jurisdiction: provider disclosure of storage and processing locations and customer assessment of authorities and legal constraints ## Evidence artifacts that make shared responsibility auditable Auditors and customers don't only want a diagram. They want to see that responsibilities are understood, assigned, and operating (with measurable checks). Collect evidence that is attributable, current, and traceable to the responsibility matrix rows. - Responsibility matrix + RACI with owners, escalation paths, and review cadence - Cloud service agreement clauses (responsibilities, disclosure obligations, support model, change/incident notification) - Operating procedures: access admin, change management, backup/restore, logging/monitoring, secure deletion and asset return - Evidence samples: logs and alerts, access reviews, restore test results, incident postmortems, periodic control effectiveness checks ## Common failure modes (and how to prevent them) Most cloud security failures are not missing controls - they're missing boundaries. ISO 27017 is valuable because it forces you to define and document where the boundary is. Use these checks to prevent everyone-assumed-someone-else-did-it outcomes. - Backups and recovery: ownership and test cadence explicitly assigned; restore tests documented - Logging: define which logs the provider retains vs what the customer must collect and alert on - Secure deletion and termination: define deletion triggers, return or removal of customer assets, verification method, and customer-facing attestations - Geographic constraints: provider disclosures reviewed and recorded; exceptions approved *Recommended next step* *Placement: near the end of the main content before related guides* ## Use ISO 27017 Shared Responsibility Model as a cited research workflow Research Copilot can take ISO 27017 Shared Responsibility Model from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on ISO 27017 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO 27017 Shared Responsibility Model](/solutions/research-copilot.md): Start from ISO 27017 Shared Responsibility Model and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO 27017](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27017 Shared Responsibility Model. ## Primary sources - [ISO/IEC 27017:2015 - ISO standard page (Reference 43757)](https://www.iso.org/standard/43757.html?ref=sorena.io) - Primary source for ISO/IEC 27017 scope, abstract, and lifecycle information. - [ITU-T X.1631 - identical text to ISO/IEC 27017](https://www.itu.int/rec/T-REC-X.1631/en?ref=sorena.io) - ISO/IEC 27017 is published with identical text as ITU-T X.1631. - [ISO/IEC 27001 - ISO standard page](https://www.iso.org/standard/27001?ref=sorena.io) - ISMS requirements where ISO/IEC 27017 guidance is commonly applied to cloud environments. ## Related Topic Guides - [ISO 27017 Cloud Provider Checklist (Due Diligence + Evidence)](/artifacts/global/iso-27017/cloud-provider-checklist.md): ISO/IEC 27017 cloud provider checklist for due diligence: what to ask, what evidence to request. - [ISO 27017 Compliance (Cloud Controls Implementation Playbook)](/artifacts/global/iso-27017/compliance.md): A practical ISO/IEC 27017 compliance playbook for cloud security controls: scope, shared responsibility, cloud-specific control implementation. - [ISO 27017 Control Mapping to ISO 27001 (SoA + Evidence)](/artifacts/global/iso-27017/control-mapping-to-iso-27001.md): How to map ISO/IEC 27017 cloud security guidance to an ISO/IEC 27001 ISMS: Statement of Applicability, control owners, shared responsibility. - [ISO 27017 FAQ (Cloud Security Controls, Audit, and Evidence)](/artifacts/global/iso-27017/faq.md): Frequently asked questions about ISO/IEC 27017: what it is, how it relates to ISO 27001 and ISO 27002, shared responsibility in cloud security. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27017/shared-responsibility-model --- --- title: "ISO 27018 Compliance (Public Cloud PII Processor Playbook)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27018/compliance" source_url: "https://www.sorena.io/artifacts/global/iso-27018/compliance" author: "Sorena AI" description: "A practical ISO/IEC 27018 compliance playbook for public cloud PII processors." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27018 compliance" - "ISO/IEC 27018 implementation guide" - "public cloud PII processor" - "ISO 27018 disclosure requests" - "ISO 27018 breach notification" - "ISO 27018 subprocessor transparency" - "ISO 27018 deletion policy" - "ISO 27018 audit evidence" - "GLOBAL compliance" - "ISO/IEC 27018" - "Cloud privacy controls" - "Audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27018 Compliance (Public Cloud PII Processor Playbook) A practical ISO/IEC 27018 compliance playbook for public cloud PII processors. *Playbook* *GLOBAL* ## ISO 27018 Compliance An implementation playbook for public cloud PII processor privacy controls. Built for cloud providers, SaaS teams, procurement reviewers, and privacy teams that need contract-ready evidence. ISO/IEC 27018 is a code of practice for protecting personally identifiable information in public clouds acting as PII processors. In practice, strong implementation means you can show that personal data is processed only under customer instructions, that subprocessor use and storage countries are transparent, that disclosure requests are legally screened and logged, that breach notifications are prompt and evidence backed, and that deletion or return can be executed across production, backup, and business continuity environments. ## Status note: what to use today The ISO standard listing now identifies ISO/IEC 27018:2025 as the current edition, and the ISO/IEC 27018:2019 page is marked withdrawn. The control themes in this playbook are grounded in the 2019 control model because that is the local source pack available for detailed implementation review. Use this page to shape operating controls and evidence, then validate any final wording or certification claim against the current ISO listing and the edition you license internally. - Treat the current ISO listing as the lifecycle source of truth - Treat the 2019 control pack as detailed implementation guidance unless your licensed 2025 text requires a narrower interpretation ## Step 1: confirm you are acting as a public cloud PII processor ISO 27018 applies when a public cloud service provider processes PII for and according to the instructions of a cloud service customer. The distinction holds only if the provider has no processing objectives of its own beyond what is necessary to deliver the customer service. This boundary matters because the same provider can still act as a controller for separate data sets, such as billing, account ownership, fraud management, or its own HR records. - List each in-scope service and identify whether you act as processor, controller, or both in different workflows - Record the customer instructions that define purpose, timeframe, and processing outcomes - Document any provider-determined processing method and confirm it stays within the customer instruction boundary ## Step 2: lock down purpose limitation and marketing use The core ISO 27018 rule is simple: PII processed under contract should not be used for any purpose independent of the customer instruction. This is the processor control that procurement teams, privacy counsel, and auditors look for first. The standard also states that PII processed under contract should not be used for marketing or advertising without express consent, and that consent should not be a condition of receiving the service. - Write a processor purpose statement into the contract and the internal service standard - Block product analytics, machine learning reuse, or marketing workflows unless the legal basis and contract model clearly permit them - Maintain evidence that marketing or advertising use requires express consent and is not bundled into core service access ## Step 3: make subprocessor and country transparency operational ISO 27018 expects subprocessor use to be disclosed before use, with the names of relevant subprocessors, the countries where they can process data, and the means by which they are required to meet or exceed the processor's obligations. The contract should also support general authorization, timely notice of intended changes, and a customer ability to object or terminate. - Maintain a live subprocessor register with service, role, country, and flow-down obligation reference - Define a measurable customer notice window for changes and keep records of objections or approvals - Where public disclosure creates unacceptable risk, provide the information under NDA and make customers aware that it is available ## Step 4: build a disclosure request workflow with legal gates The standard requires notification of legally binding requests for disclosure of PII, unless notification is prohibited. It also requires the processor to reject requests that are not legally binding, consult the customer where legally permissible, and record disclosures. This cannot be handled as an ad hoc legal email thread. It needs a repeatable runbook with evidence fields. - Define what counts as legally binding in the jurisdictions where you operate - Log the source of the disclosure and the source of the authority for every disclosure event - Preserve the customer communication trail and any decision to delay or withhold notice because law prohibits it ## Step 5: make breach notification support fast and specific ISO 27018 says the processor should promptly notify the relevant cloud service customer when unauthorized access to PII, or to processing equipment or facilities, results in loss, disclosure, or alteration of PII. The contract should define the maximum notification delay and the information needed so the customer can assess its own legal notification duties. - Include event time, detection time, impact summary, data categories, likely consequences, containment actions, and customer contact path in the breach record - Retain evidence of whether the incident caused loss, disclosure, or alteration of PII - Where law requires direct regulator notice by the processor, document that obligation separately from the customer notice workflow ## Step 6: design deletion and return for the full service lifecycle ISO 27018 requires a policy for return, transfer, or disposal of PII and says the processor should provide information necessary for the customer to ensure that PII is erased wherever stored, including backup and business continuity environments, once it is no longer needed for the customer's purpose. Deletion is not credible if it only covers the primary environment. The contract and runbooks should specify the mechanism, timing, and verification method. - Cover export, transfer, secure deletion, destruction, anonymization, and archiving paths - State the retention period before destruction after contract end so accidental lapse does not destroy customer data unexpectedly - Flow the same disposal obligations to subprocessors, including backup storage providers ## Step 7: build an evidence model that can replace intrusive customer audits ISO 27018 recognizes that individual customer audits in a multi-tenant cloud can be impractical or can increase security risk. In those cases, the processor should make independent evidence available before contract signature and during the contract term. A strong evidence model shortens sales cycles and reduces repeated customer questionnaires. - Prepare an evidence index that maps each customer commitment to a control owner and evidence artifact - Keep prior policies and procedures for a documented retention period, with five years as the ISO 27018 recommended minimum when no stricter requirement applies - Use third-party assurance, transparency materials, procedure summaries, and sample records to support customer review without exposing multi-tenant risk *Recommended next step* *Placement: after the compliance steps* ## Turn ISO 27018 Compliance into an operational assessment Assessment Autopilot can take ISO 27018 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on ISO 27018 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 27018 Compliance](/solutions/assessment.md): Start from ISO 27018 Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 27018](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27018 Compliance. ## Primary sources - [ISO/IEC 27018 current standard listing](https://www.iso.org/standard/27018?ref=sorena.io) - Official ISO listing used to confirm the current edition and publication status. - [ISO/IEC 27018:2019 standard page](https://www.iso.org/standard/76559.html?ref=sorena.io) - Official ISO page showing the 2019 edition lifecycle and withdrawal status. - [GDPR consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02016R0679-20160504&ref=sorena.io) - Primary legal source for processor contract duties, security of processing, and breach notification obligations that ISO 27018 often supports in practice. ## Related Topic Guides - [ISO 27018 FAQ (Public Cloud PII Processor Controls)](/artifacts/global/iso-27018/faq.md): Frequently asked questions about ISO/IEC 27018 for public cloud PII processors. - [ISO 27018 Privacy Control Checklist (Public Cloud PII Processor)](/artifacts/global/iso-27018/privacy-control-checklist.md): An ISO/IEC 27018 privacy control checklist for public cloud PII processors. - [ISO 27018 Vendor Contract Requirements (Processor Clauses and Evidence)](/artifacts/global/iso-27018/vendor-contract-requirements.md): Processor contract requirements based on ISO/IEC 27018 and GDPR. - [ISO 27018 vs GDPR (Processor Controls and Evidence Mapping)](/artifacts/global/iso-27018/iso-27018-vs-gdpr.md): Compare ISO/IEC 27018 and GDPR for cloud processor operations. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27018/compliance --- --- title: "ISO 27018 FAQ (Public Cloud PII Processor Controls)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27018/faq" source_url: "https://www.sorena.io/artifacts/global/iso-27018/faq" author: "Sorena AI" description: "Frequently asked questions about ISO/IEC 27018 for public cloud PII processors." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27018 FAQ" - "ISO/IEC 27018 explained" - "ISO 27018 current edition" - "ISO 27018 public cloud PII processor" - "ISO 27018 subprocessor notice" - "ISO 27018 disclosure requests" - "ISO 27018 breach notification" - "ISO 27018 deletion evidence" - "GLOBAL compliance" - "ISO/IEC 27018" - "FAQ" - "Public cloud PII processor" - "Cloud privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27018 FAQ (Public Cloud PII Processor Controls) Frequently asked questions about ISO/IEC 27018 for public cloud PII processors. *FAQ* *GLOBAL* ## ISO 27018 FAQ Quick answers to the ISO/IEC 27018 questions that matter in cloud privacy reviews. Focus on scope, processor boundaries, disclosure, breach support, deletion, and customer evidence. ISO/IEC 27018 is a code of practice for protection of PII in public clouds acting as PII processors. Teams use it when they need a cloud specific processor control model that can be tied to contracts, operating procedures, and customer evidence. These answers focus on how the standard works in real procurement, privacy, and audit workflows. ## What is ISO/IEC 27018 in one sentence? It is a code of practice for protecting personally identifiable information in public cloud services that act as PII processors. It builds on ISO/IEC 27002 style controls and adds cloud specific guidance for processor obligations. The practical outcome is a processor control model for instructions, subprocessor management, disclosure handling, breach support, deletion, and customer assurance. - Use it to design controls and evidence for processor services - Do not treat it as a substitute for the law that applies to your contract or jurisdiction ## Who should care about ISO 27018? Public cloud providers, SaaS vendors, managed platforms, and hosting services should care when they process personal data on behalf of customers. Privacy teams and procurement teams should also use it to evaluate whether the provider can support processor obligations in practice. It is especially useful where a provider wants a repeatable answer to customer questions about subprocessors, countries, disclosure requests, incident handling, and deletion. - Cloud providers use it to structure controls and customer evidence - Customers use it to ask better due diligence questions and review contract commitments ## Is ISO 27018:2019 still current? No. The official ISO listing now shows ISO/IEC 27018:2025 as the current edition, and the ISO/IEC 27018:2019 page is marked withdrawn. The 2019 text still matters for implementation review because it contains the detailed control themes used in many existing programs, but the current ISO listing should control any claim about the active edition. - Current listing: ISO/IEC 27018:2025 - Detailed local control pack used here: ISO/IEC 27018:2019 ## What makes a provider a PII processor under ISO 27018? A provider is acting as a PII processor when it processes PII for and according to the instructions of the cloud service customer. The distinction depends on the provider not having independent processing objectives for that customer PII. A provider can still act as a controller for separate data sets, such as account ownership data or its own business records. - Write down the processor scope service by service - Separate customer instruction data from provider controlled business data ## Does ISO 27018 ban all provider use of customer data? It requires that PII processed under contract is not processed for any purpose independent of the customer instruction. That means independent product, marketing, or advertising use is a red flag unless the legal basis and contract structure clearly authorize it. The standard also says marketing or advertising use should not happen without express consent, and consent should not be made a condition of receiving the service. - Review analytics, product improvement, and model training workflows carefully - Keep evidence that optional marketing use is separated from core service access ## What does ISO 27018 expect for subprocessors? It expects disclosure before use, transparent contract treatment, notice of intended changes, and a customer ability to object or terminate. It also expects providers to identify the relevant subprocessor countries and explain how subprocessors are required to meet or exceed the processor's obligations. This is why a one line statement that subprocessors may change at any time is not enough. - Maintain a named subprocessor list - State the countries where subprocessors can process data - Keep the flow-down obligation model available for review ## How should disclosure requests be handled? The provider should notify the customer of legally binding disclosure requests unless notice is prohibited, reject requests that are not legally binding, consult the customer where legally permissible, and record disclosures. Records should capture both the source of the disclosure and the source of the authority for the disclosure. - Use a legal intake workflow, not ad hoc email handling - Preserve the evidence trail for every disclosure decision ## What does the standard expect for data breach support? It expects prompt notice to the relevant cloud service customer when unauthorized access to PII, or to processing equipment or facilities, results in loss, disclosure, or alteration of PII. The contract should define the maximum notification delay and the information required so the customer can perform its legal assessment and any regulator notification it owes. - Keep incident records with time period, consequences, data affected, reporting path, and remediation steps - Document direct regulator notice duties separately where local law imposes them on the processor ## What should the deletion policy cover? The deletion and return policy should address export, transfer, disposal, anonymization, and archiving, and it should explain how PII is erased from all relevant locations, including backup and business continuity storage, once it is no longer needed for the customer's purpose. The contract should also define the deletion mechanism or commercial standard used, and the retention period before destruction after contract termination. - Do not limit the policy to the primary production environment - Make the verification method explicit so deletion can be evidenced ## What records should be retained? The standard recommends keeping current and historical policies and procedures for a documented period. In the absence of a specific legal or contractual requirement, it recommends a minimum retention period of five years. This is especially useful for customer disputes, authority investigations, and proving that older commitments were in force at a specific time. - Retain superseded policies, procedures, and notification templates - Align the five year recommendation with any stricter legal, contractual, or certification requirement *Recommended next step* *Placement: after the FAQ section* ## Use ISO 27018 FAQ as a cited research workflow Research Copilot can take ISO 27018 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on ISO 27018 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO 27018 FAQ](/solutions/research-copilot.md): Start from ISO 27018 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO 27018](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27018 FAQ. ## Primary sources - [ISO/IEC 27018 current standard listing](https://www.iso.org/standard/27018?ref=sorena.io) - Official ISO listing for the current edition status. - [ISO/IEC 27018:2019 standard page](https://www.iso.org/standard/76559.html?ref=sorena.io) - Official ISO page for the withdrawn 2019 edition referenced by many existing programs. - [GDPR consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02016R0679-20160504&ref=sorena.io) - Processor legal duties that teams commonly map to ISO 27018 controls in practice. ## Related Topic Guides - [ISO 27018 Compliance (Public Cloud PII Processor Playbook)](/artifacts/global/iso-27018/compliance.md): A practical ISO/IEC 27018 compliance playbook for public cloud PII processors. - [ISO 27018 Privacy Control Checklist (Public Cloud PII Processor)](/artifacts/global/iso-27018/privacy-control-checklist.md): An ISO/IEC 27018 privacy control checklist for public cloud PII processors. - [ISO 27018 Vendor Contract Requirements (Processor Clauses and Evidence)](/artifacts/global/iso-27018/vendor-contract-requirements.md): Processor contract requirements based on ISO/IEC 27018 and GDPR. - [ISO 27018 vs GDPR (Processor Controls and Evidence Mapping)](/artifacts/global/iso-27018/iso-27018-vs-gdpr.md): Compare ISO/IEC 27018 and GDPR for cloud processor operations. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27018/faq --- --- title: "ISO 27018 vs GDPR (Processor Controls and Evidence Mapping)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27018/iso-27018-vs-gdpr" source_url: "https://www.sorena.io/artifacts/global/iso-27018/iso-27018-vs-gdpr" author: "Sorena AI" description: "Compare ISO/IEC 27018 and GDPR for cloud processor operations." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27018 vs GDPR" - "ISO 27018 GDPR mapping" - "GDPR Article 28 processor contract" - "ISO 27018 subprocessor transparency" - "ISO 27018 breach notification" - "GDPR Article 32" - "GDPR Article 33" - "cloud processor evidence pack" - "GLOBAL compliance" - "ISO/IEC 27018" - "GDPR" - "Processor obligations" - "Evidence mapping" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27018 vs GDPR (Processor Controls and Evidence Mapping) Compare ISO/IEC 27018 and GDPR for cloud processor operations. *Comparison* *GLOBAL* ## ISO 27018 ISO 27018 vs GDPR How ISO/IEC 27018 control themes support GDPR processor obligations in practice. Use one set of cloud processor controls and one evidence model wherever the obligations overlap. GDPR is law. ISO/IEC 27018 is a code of practice for public cloud providers acting as PII processors. They are used together because GDPR tells you what processor obligations exist, while ISO 27018 gives a cloud specific control model for how to operate many of those obligations and how to evidence them for customers. ## Start with the right distinction: law versus control model GDPR creates binding duties for controllers and processors. ISO 27018 does not replace those duties and does not decide whether you are legally a controller or processor. It gives a structured set of cloud privacy controls for providers acting as processors. A strong program uses GDPR to define the legal outcome and ISO 27018 to define the operational mechanism and the evidence trail. - Use GDPR to define contract, security, and breach obligations - Use ISO 27018 to decide what procedures, records, and customer notices prove those obligations are being met ## Processor instructions and purpose limitation GDPR Article 28 requires the processor to act only on documented instructions from the controller. ISO 27018 reinforces this in cloud specific terms by saying that PII under contract should not be processed for any purpose independent of customer instructions. This is the control area where teams usually discover hidden reuse of customer data for analytics, product features, or marketing. - GDPR Article 28(3)(a): act only on documented instructions - ISO 27018: no independent processing objective for contracted PII - Evidence: service description, processor clause, change records for instructions, and approval workflow for any exception ## Confidentiality, security, and access governance GDPR Article 28 requires confidentiality commitments for persons authorized to process personal data, and Article 32 requires appropriate security of processing. ISO 27018 adds cloud specific implementation guidance around access administration, confidentiality obligations that survive termination, logging, cryptography disclosures, and user control boundaries. The useful move is to treat confidentiality, access, logging, and cryptography as one evidence family rather than separate checklist items. - GDPR Article 28(3)(b): confidentiality commitments - GDPR Article 32: appropriate security measures - ISO 27018: enforceable confidentiality, access review evidence, cloud user administration, log availability criteria, and cryptography transparency ## Subprocessors and international processing locations GDPR requires prior specific or general written authorization for subprocessors and requires the same data protection obligations to flow down. ISO 27018 makes this operational by requiring disclosure before use, timely notice of intended changes, names of relevant subprocessors, and the countries where they can process data. That country level detail is where many processor programs are weak, especially when backup or support subprocessors are involved. - GDPR Article 28(2) and 28(4): authorization and flow-down - ISO 27018: named subprocessors, country transparency, change notice, objection or termination path - Evidence: subprocessor register, country matrix, notice archive, and subprocessor contract baseline ## Disclosure requests and regulator access GDPR does not give you a full operating procedure for law enforcement or other third party disclosure requests. ISO 27018 does. It requires notification of legally binding requests unless prohibited, rejection of requests that are not legally binding, consultation where lawful, and recording of the disclosure and the authority behind it. This is a major operational benefit of ISO 27018 because cloud providers receive these requests in many different forms and jurisdictions. - GDPR baseline: process lawfully and preserve contractual commitments - ISO 27018 detail: validate legal compulsion, record disclosure source and authority source, preserve customer notice trail - Evidence: disclosure runbook, legal review log, and per-request case file ## Breach handling and notification support GDPR Article 33 places the main regulator notification duty on the controller, while processors must notify the controller without undue delay after becoming aware of a personal data breach. ISO 27018 fits this well by requiring prompt customer notice and detailed incident records, plus the contract definition of the maximum delay and required information fields. The combination works well when the cloud provider maintains a breach record that already contains the information the customer needs for legal assessment. - GDPR Article 33(2): processor notifies the controller without undue delay - ISO 27018: prompt customer notice plus structured incident record - Evidence: detection timeline, impact summary, affected data description, containment actions, and notification log ## Deletion, return, and audit support GDPR Article 28 requires deletion or return of personal data at the end of the provision of services and requires the processor to make available information necessary to demonstrate compliance. ISO 27018 adds concrete cloud specific guidance for return, transfer, disposal, backup and business continuity erasure, and the use of independent assurance when direct customer audits are impractical. That makes ISO 27018 especially useful for multi-tenant services where customer audits need a controlled alternative. - GDPR Article 28(3)(g): delete or return personal data - GDPR Article 28(3)(h): make information available and allow audits - ISO 27018: disposal policy, backup and business continuity erasure logic, independent audit evidence, and documented record retention ## Best operating model: one evidence pack, not two parallel programs The most efficient approach is to build one processor evidence pack that satisfies customer legal review and customer security review at the same time. The pack should map contract clauses to control owners, procedures, and live records. If you split GDPR evidence and ISO 27018 evidence into separate repositories, the story will drift and customer trust will drop. - Map each GDPR processor clause to one or more ISO 27018 control themes - Keep versioned records for subprocessor notices, disclosure cases, breach cases, and deletion attestations - Retain superseded procedures for a documented period, with five years as the ISO 27018 recommended minimum where no stricter rule applies *Recommended next step* *Placement: after the comparison section* ## Use ISO 27018 ISO 27018 vs GDPR as a cited research workflow Research Copilot can take ISO 27018 ISO 27018 vs GDPR from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on ISO 27018 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO 27018 ISO 27018 vs GDPR](/solutions/research-copilot.md): Start from ISO 27018 ISO 27018 vs GDPR and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO 27018](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27018 ISO 27018 vs GDPR. ## Primary sources - [ISO/IEC 27018 current standard listing](https://www.iso.org/standard/27018?ref=sorena.io) - Official ISO lifecycle source for the current edition. - [ISO/IEC 27018:2019 standard page](https://www.iso.org/standard/76559.html?ref=sorena.io) - Official ISO page for the detailed prior edition used by many existing programs. - [GDPR consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02016R0679-20160504&ref=sorena.io) - Primary legal source for GDPR processor duties. - [EU controller processor SCCs](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32021D0915&ref=sorena.io) - Useful primary source for practical processor contract structure under GDPR Article 28(7). ## Related Topic Guides - [ISO 27018 Compliance (Public Cloud PII Processor Playbook)](/artifacts/global/iso-27018/compliance.md): A practical ISO/IEC 27018 compliance playbook for public cloud PII processors. - [ISO 27018 FAQ (Public Cloud PII Processor Controls)](/artifacts/global/iso-27018/faq.md): Frequently asked questions about ISO/IEC 27018 for public cloud PII processors. - [ISO 27018 Privacy Control Checklist (Public Cloud PII Processor)](/artifacts/global/iso-27018/privacy-control-checklist.md): An ISO/IEC 27018 privacy control checklist for public cloud PII processors. - [ISO 27018 Vendor Contract Requirements (Processor Clauses and Evidence)](/artifacts/global/iso-27018/vendor-contract-requirements.md): Processor contract requirements based on ISO/IEC 27018 and GDPR. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27018/iso-27018-vs-gdpr --- --- title: "ISO 27018 Privacy Control Checklist (Public Cloud PII Processor)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27018/privacy-control-checklist" source_url: "https://www.sorena.io/artifacts/global/iso-27018/privacy-control-checklist" author: "Sorena AI" description: "An ISO/IEC 27018 privacy control checklist for public cloud PII processors." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27018 checklist" - "ISO/IEC 27018 privacy control checklist" - "public cloud PII processor checklist" - "ISO 27018 disclosure records" - "ISO 27018 breach records" - "ISO 27018 subprocessor countries" - "ISO 27018 deletion evidence" - "GLOBAL compliance" - "ISO/IEC 27018" - "Privacy control checklist" - "Public cloud PII processor" - "Audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27018 Privacy Control Checklist (Public Cloud PII Processor) An ISO/IEC 27018 privacy control checklist for public cloud PII processors. *Checklist* *GLOBAL* ## ISO 27018 Privacy Control Checklist A control and evidence checklist for public cloud PII processor operations. Use it for gap assessment, procurement preparation, and internal audit readiness. ISO/IEC 27018 is most useful when each privacy control is tied to a contract commitment, an operating procedure, and a record you can actually produce during a customer review. This checklist focuses on the highest value processor controls and the evidence that proves they are not just policy text. ## How to use this checklist For every control area, collect three things: the contractual commitment, the operating method, and a live evidence sample. If any one of those is missing, the control will be weak under review. Run the checklist service by service, because processor boundaries and subprocessor use often vary between products. - Define the in-scope services and the processing role for each one - Assign an owner and review cadence for every control theme - Record where the current evidence lives and how long historical records are retained *Recommended next step* *Placement: after the checklist block* ## Turn ISO 27018 Privacy Control Checklist into an operational assessment Assessment Autopilot can take ISO 27018 Privacy Control Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on ISO 27018 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 27018 Privacy Control Checklist](/solutions/assessment.md): Start from ISO 27018 Privacy Control Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 27018](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27018 Privacy Control Checklist. ## Processor scope and customer instructions Verify that the service is operating as a public cloud PII processor and not quietly expanding into controller style reuse of customer data. Confirm that the customer instruction boundary is clear enough to govern purpose, timing, and method. This is the foundation for every downstream control. - Service description identifies processor activities and any separate controller activities - Customer instructions are documented and change controlled - Evidence exists for how provider chosen technical methods still remain within the customer purpose ## Purpose limitation and marketing restrictions Check that contracted PII is not used for independent purposes. Check separately that marketing or advertising use is either absent or supported by express consent that is not required to receive the service. This control should be reviewed with product, growth, and analytics teams, not only legal. - Policy prohibits independent processing of contracted PII - Marketing use requires express consent and is optional - Evidence includes feature gating, consent records, and internal review approvals ## Subprocessor transparency and country disclosure Review whether subprocessor use is disclosed before use, whether changes trigger timely notice, and whether the register includes the countries where data can be processed or stored. Do not forget backup, support, and infrastructure subprocessors. - Named subprocessor register is current - Customer notice and objection or termination workflow is documented - Flow-down obligation baseline exists for each subprocessor - Country list covers both primary processing and replicated or backup storage ## Disclosure request handling Check whether the provider can distinguish legally binding requests from informal requests, whether customer consultation is built into the runbook where lawful, and whether all disclosures are recorded with the source of the request and the source of authority. This is one of the easiest controls to test because the evidence trail should be explicit. - Disclosure runbook exists and includes legal review criteria - Records capture request source, authority source, customer notification, and actual disclosure content - Evidence shows rejection of requests that are not legally binding ## Breach notification support and incident records Check whether the contract defines maximum notification delay and required fields, and whether incident records are detailed enough for customer legal assessment. A simple ticket summary is rarely enough. - Runbook includes prompt customer notification path - Incident record includes time period, consequences, data affected, reporter, recipients, and remediation - Evidence shows whether loss, disclosure, or alteration of PII occurred ## Deletion, return, transfer, and backup handling Check whether the disposal policy covers return, transfer, deletion, destruction, anonymization, and archiving. Check whether the policy and contract explain how PII is erased from backup and business continuity environments. Deletion claims should always name the mechanism or standard used. - Policy is available to customers - Contract defines mechanism, timing, and verification method - Evidence includes export logs, deletion attestations, and subprocessor completion records ## Logs, temporary files, and record retention The standard expects criteria for how logs can be made available to customers, deletion of logged information within a specified and documented period, and periodic deletion of aged temporary files that are no longer needed. It also recommends a minimum five year retention period for current and historical policies and procedures when no stricter requirement applies. - Log availability criteria are documented and customer scoped - Temporary file cleanup period is defined and enforced - Historical policy and procedure retention is documented and tested ## Independent assurance evidence Check whether the service can satisfy customer review without unsafe direct inspection of multi-tenant systems. The standard expressly contemplates independent evidence where individual audits are impractical or increase risk. This evidence model should be prepared before large customers ask for it. - Evidence pack maps controls to documents and record samples - Independent assurance material is current and scoped to the relevant service - NDA pathway exists where sensitive subprocessor or architecture detail cannot be published openly ## Primary sources - [ISO/IEC 27018 current standard listing](https://www.iso.org/standard/27018?ref=sorena.io) - Official lifecycle source for the current edition. - [ISO/IEC 27018:2019 standard page](https://www.iso.org/standard/76559.html?ref=sorena.io) - Official prior edition source used with the local grounded control pack. - [GDPR consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02016R0679-20160504&ref=sorena.io) - Useful legal baseline for processor contracts, security, and breach support. ## Related Topic Guides - [ISO 27018 Compliance (Public Cloud PII Processor Playbook)](/artifacts/global/iso-27018/compliance.md): A practical ISO/IEC 27018 compliance playbook for public cloud PII processors. - [ISO 27018 FAQ (Public Cloud PII Processor Controls)](/artifacts/global/iso-27018/faq.md): Frequently asked questions about ISO/IEC 27018 for public cloud PII processors. - [ISO 27018 Vendor Contract Requirements (Processor Clauses and Evidence)](/artifacts/global/iso-27018/vendor-contract-requirements.md): Processor contract requirements based on ISO/IEC 27018 and GDPR. - [ISO 27018 vs GDPR (Processor Controls and Evidence Mapping)](/artifacts/global/iso-27018/iso-27018-vs-gdpr.md): Compare ISO/IEC 27018 and GDPR for cloud processor operations. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27018/privacy-control-checklist --- --- title: "ISO 27018 Vendor Contract Requirements (Processor Clauses and Evidence)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27018/vendor-contract-requirements" source_url: "https://www.sorena.io/artifacts/global/iso-27018/vendor-contract-requirements" author: "Sorena AI" description: "Processor contract requirements based on ISO/IEC 27018 and GDPR." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27018 vendor contract requirements" - "ISO 27018 processor clauses" - "ISO 27018 subprocessor contract" - "ISO 27018 disclosure clause" - "ISO 27018 breach clause" - "ISO 27018 deletion clause" - "GDPR Article 28 processor contract" - "GLOBAL compliance" - "ISO/IEC 27018" - "Vendor contract requirements" - "Processor contract" - "GDPR Article 28" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27018 Vendor Contract Requirements (Processor Clauses and Evidence) Processor contract requirements based on ISO/IEC 27018 and GDPR. *Clauses* *GLOBAL* ## ISO 27018 Vendor Contract Requirements A practical clause pack for public cloud PII processor contracts. Use it to tie processor obligations to the evidence you can actually provide. ISO/IEC 27018 is strongest when the contract defines the processor obligation, the operating mechanism, and the evidence model in the same place. This page turns the main ISO 27018 control themes into a processor clause checklist that also fits GDPR Article 28 style review. ## Clause family 1: processor role, scope, and instructions The agreement should identify the service, the categories of processing performed under customer instruction, and the boundary between processor activity and any separate controller activity of the provider. It should also define how instructions are issued, changed, and interpreted. This is the clause family that prevents later disputes about product improvement, troubleshooting, and optional service features. - State that contracted PII is processed only under documented customer instructions - Define the process for instruction changes and the technical method choices the provider may make within those instructions - Identify any provider controlled data sets that are outside the processor scope ## Clause family 2: confidentiality, security baseline, and unilateral change limits The contract should require confidentiality obligations for personnel with access to PII and minimum technical and organizational measures that cannot be reduced unilaterally by the provider. This aligns with both GDPR processor expectations and ISO 27018 guidance. Security commitments should be specific enough to support review without promising product features you do not operate. - Confidentiality obligations survive termination - Minimum security measures are documented and not subject to unilateral reduction - Customer facing security summary points to the detailed policy and evidence source ## Clause family 3: marketing restrictions and optional consent If the provider wants any marketing or advertising use of contracted PII, the contract and consent design must handle that explicitly. ISO 27018 says such use should not happen without express consent and that consent should not be a condition of receiving the service. Most providers should avoid this entirely for processor scoped PII because it creates unnecessary complexity. - Default rule: no marketing or advertising use of contracted PII - If consent based use exists, keep it separate from core service access and keep evidence of express consent - Map the exact data elements and processing path involved ## Clause family 4: subprocessors, countries, and change notices The agreement should disclose that subprocessors are used, define the authorization model, require timely notice of intended changes, and identify the countries where subprocessors may process or store PII. It should also explain how subprocessors are bound to meet or exceed the provider's obligations. This is the clause family most likely to be escalated by enterprise procurement. - Include a maintained subprocessor list or committed publication method - State notice timing, objection method, and termination path if objections cannot be resolved - Cover backup, support, and infrastructure subprocessors, not only core product vendors ## Clause family 5: disclosure requests The contract should define how the provider handles requests from law enforcement or other authorities. ISO 27018 expects notice of legally binding requests unless prohibited, rejection of requests that are not legally binding, customer consultation where lawful, and recorded disclosures. A strong clause does not rely on vague promises to comply with applicable law. It defines the workflow. - Define notice timing and the conditions where notice cannot be given - Commit to reject non-binding requests - Commit to record the disclosure, the source of the request, and the source of the authority ## Clause family 6: breach support and incident records The breach clause should define prompt customer notice, the maximum delay, the information fields to be provided, and the cooperation model for follow up questions. It should also require the provider to maintain incident records detailed enough for customer legal assessment. This clause should distinguish provider caused incidents from incidents caused solely by customer controlled components where responsibility is different. - State the notification trigger and maximum delay - List required information fields such as time period, consequences, data affected, and remediation - Explain how the provider supports authority notification duties where the customer has them *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep ISO 27018 Vendor Contract Requirements in one governed evidence system SSOT can take ISO 27018 Vendor Contract Requirements from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on ISO 27018 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for ISO 27018 Vendor Contract Requirements](/solutions/ssot.md): Start from ISO 27018 Vendor Contract Requirements and keep documents, evidence, and control records in one governed system. - [Talk through ISO 27018](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27018 Vendor Contract Requirements. ## Clause family 7: return, transfer, disposal, and backup erasure The contract should provide a return, transfer, and disposal model that covers primary systems, replicated systems, backup, and business continuity environments. It should describe the deletion mechanism or standard and the retention period before final destruction after contract end. If the contract says delete on termination but the backups are ignored, the clause is not operationally complete. - Offer export or transfer where appropriate before deletion - Name the erasure or destruction method and the verification model - Flow the same requirements to subprocessors and retain completion evidence ## Clause family 8: audit rights and independent evidence In multi-tenant cloud services, direct customer audits can be impractical or can increase security risk. ISO 27018 allows the use of independent evidence in those cases, provided sufficient transparency is given to the customer. The contract should explain what evidence the provider will make available and under what conditions. - Define the standard evidence package, refresh cadence, and NDA conditions - Keep historical policies and procedures for a documented retention period, with five years as the recommended minimum where no stricter rule applies - Make sure the contract promises only evidence you can sustain over time ## Primary sources - [ISO/IEC 27018 current standard listing](https://www.iso.org/standard/27018?ref=sorena.io) - Official lifecycle source for the current edition. - [ISO/IEC 27018:2019 standard page](https://www.iso.org/standard/76559.html?ref=sorena.io) - Official ISO page for the detailed prior edition reflected in many current contract models. - [GDPR consolidated text](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02016R0679-20160504&ref=sorena.io) - Primary legal source for processor contract obligations. - [EU controller processor SCCs](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32021D0915&ref=sorena.io) - Useful primary source for controller processor contract structure under GDPR Article 28(7). ## Related Topic Guides - [ISO 27018 Compliance (Public Cloud PII Processor Playbook)](/artifacts/global/iso-27018/compliance.md): A practical ISO/IEC 27018 compliance playbook for public cloud PII processors. - [ISO 27018 FAQ (Public Cloud PII Processor Controls)](/artifacts/global/iso-27018/faq.md): Frequently asked questions about ISO/IEC 27018 for public cloud PII processors. - [ISO 27018 Privacy Control Checklist (Public Cloud PII Processor)](/artifacts/global/iso-27018/privacy-control-checklist.md): An ISO/IEC 27018 privacy control checklist for public cloud PII processors. - [ISO 27018 vs GDPR (Processor Controls and Evidence Mapping)](/artifacts/global/iso-27018/iso-27018-vs-gdpr.md): Compare ISO/IEC 27018 and GDPR for cloud processor operations. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27018/vendor-contract-requirements --- --- title: "ISO 27035 Compliance (Incident Management Operating Model)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27035/compliance" source_url: "https://www.sorena.io/artifacts/global/iso-27035/compliance" author: "Sorena AI" description: "A practical ISO/IEC 27035 compliance playbook for incident management." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27035 compliance" - "ISO/IEC 27035 implementation guide" - "incident management operating model" - "incident coordinator" - "IMT" - "IRT" - "incident event report" - "incident management log" - "incident response metrics" - "learn lessons" - "GLOBAL compliance" - "ISO/IEC 27035" - "Incident management" - "Incident response" - "Audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27035 Compliance (Incident Management Operating Model) A practical ISO/IEC 27035 compliance playbook for incident management. *Playbook* *GLOBAL* ## ISO 27035 Compliance A practical operating model for incident management based on the ISO/IEC 27035 series. Built for security leaders, incident managers, SOC teams, CSIRTs, and ISMS owners who need a usable and auditable response capability. ISO/IEC 27035 is not a one page incident response policy. It is a full capability model. Part 1 defines the process and required documentation. Part 2 defines the planning and preparation work that makes response repeatable. Part 3 provides ICT response operations for detection, notification, triage, analysis, containment, eradication, and recovery. A compliant operating model proves that those pieces work together. ## Series baseline and what changed in the 2023 revisions The grounded series here is ISO/IEC 27035-1:2023 second edition, ISO/IEC 27035-2:2023 second edition, and ISO/IEC 27035-3:2020 first edition. The 2023 revisions matter because they formalize the incident management team and incident coordinator roles and strengthen the planning and lessons learned structure. If your program still reflects only the older 2016 framing, your team structure and documentation model are probably too thin. - Part 1: process and documentation baseline - Part 2: policy, plan, teams, external relationships, awareness, testing, metrics, and lessons learned - Part 3: ICT response operations with operational detail for triage, analysis, and response phases ## Step 1: build the policy and plan, not just a runbook Part 2 expects an information security incident management policy and an incident management plan that cover the process flow, classification and severity documents, post-resolution activities, external support, and information sharing rules. The plan should be a document set, not a single PDF. It should include forms, procedures, organizational elements, and the support tools needed for all phases. - Maintain a high level process flow that covers detect and report, assess and decide, respond, and learn lessons - Reference the classification scale, severity ratings, forms, and communications rules from the plan - Define rules and circumstances for information sharing with internal and external parties, including any TLP style handling model you adopt ## Step 2: define the team model and capability register Part 2 expects formal establishment of the incident management team, the incident response team, and the incident coordinator role. It also recognizes that the response capability often depends on specialists outside the core team, such as legal, forensics, facilities, cloud providers, or media relations. That means you need a living capability register, not just an org chart. - Document the terms of reference and responsibilities for IMT, IRT, incident coordinator, and point of contact - Track internal and external specialist capabilities in a register and keep escalation contacts current - Define when vulnerabilities are routed to vulnerability management rather than treated as active incidents ## Step 3: make event reporting and acceptance criteria explicit The standard does not treat event reporting as a vague mailbox function. It expects event reports to be completed immediately when a suspected incident may cause substantial loss or damage, and it expects defined criteria for accepting an event report based on its completeness. Poor intake quality is a root cause of poor triage. - Use a generic event report form that still captures enough detail for categorization and prioritization - Define minimum required fields and a process for requesting missing information - Keep event reporting channels and form handling aligned with your incident management plan ## Step 4: classify, evaluate, prioritize, and escalate consistently Annex C in Part 2 focuses on categorization, evaluation, and prioritization. It expects organizations to document incidents consistently so evaluation, reporting, and severity handling are comparable across cases. The scoring model should align with your information classification policy and should support decisions on priority and escalation level. - Classify event or incident type and affected asset or service consistently - Evaluate impacts and consequences, then set a priority to respond - Record severity rationale and the escalation level in the incident management log ## Step 5: run ICT response operations with evidence discipline Part 3 goes beyond generic incident response advice. It covers detection operations, notification operations, triage, analysis, evidence handling, and response operations for containment, eradication, and recovery. That means response should not only be fast. It should preserve analysis quality and evidence quality. - Use a defined point of contact model for incident notifications, whether single or multiple PoCs exist - Preserve evidence and analysis results consistently, especially where forensics or legal review can follow - Document containment, eradication, and recovery actions separately so post-incident review can evaluate each phase ## Step 6: learn lessons, evaluate the IMT, and update risk assumptions Part 2 makes lessons learned a structured phase, not an optional meeting. It expects improvement of the plan, evaluation of the IMT, improvement of control implementation, and review of risk assessment and management review results when incidents show reality differs from assumptions. This is where many programs fail. They close tickets but never update policy, plan, control design, or risk ratings. - Run a post-incident review after closure and record concrete improvement actions - Evaluate the IMT periodically, not only after severe incidents - Update risk assessments where real consequences differ materially from the prior scoring model ## Evidence pack: what auditors and regulators actually ask for A defensible ISO 27035 capability produces a repeatable evidence set. That evidence should prove process design, team readiness, incident execution, and improvement follow-through. If your evidence stops at an incident policy and a few tickets, the program is not mature. - Policy, plan, forms, classification scales, and communications rules - Event reports, incident management logs, severity rationale, and notification records - Exercise records, capability register reviews, IMT evaluations, and corrective action tracking *Recommended next step* *Placement: after the compliance steps* ## Turn ISO 27035 Compliance into an operational assessment Assessment Autopilot can take ISO 27035 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on ISO 27035 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 27035 Compliance](/solutions/assessment.md): Start from ISO 27035 Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 27035](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27035 Compliance. ## Primary sources - [ISO/IEC 27035-1:2023 standard page](https://www.iso.org/standard/78973.html?ref=sorena.io) - Official ISO page for Part 1 principles and process. - [ISO/IEC 27035-2:2023 standard page](https://www.iso.org/standard/78974.html?ref=sorena.io) - Official ISO page for Part 2 planning and preparation. - [ISO/IEC 27035-3:2020 standard page](https://www.iso.org/standard/74033.html?ref=sorena.io) - Official ISO page for Part 3 ICT response operations. - [ISO/IEC 27001 current listing](https://www.iso.org/standard/27001?ref=sorena.io) - Useful anchor for ISMS integration and audit context. ## Related Topic Guides - [ISO 27035 FAQ (Incident Management, Team Roles, and Evidence)](/artifacts/global/iso-27035/faq.md): Frequently asked questions about ISO/IEC 27035. Understand the 2023 series structure, IMT and IRT roles, event report forms, incident logs, prioritization. - [ISO 27035 Incident Response Playbook (Roles, Forms, and Operations)](/artifacts/global/iso-27035/incident-response-playbook.md): A practical ISO/IEC 27035 incident response playbook that covers event reporting, triage, analysis, containment, eradication, recovery, communications. - [ISO 27035 Incident Severity and Escalation Matrix (Classification and Priority Template)](/artifacts/global/iso-27035/incident-severity-and-escalation-matrix.md): A grounded ISO/IEC 27035 severity and escalation matrix template for classification, evaluation, prioritization, predetermined response times. - [ISO 27035 vs NIST SP 800-61r3 (Incident Response Mapping)](/artifacts/global/iso-27035/iso-27035-vs-nist-800-61r3.md): Compare ISO/IEC 27035 and NIST SP 800-61r3 for incident response. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27035/compliance --- --- title: "ISO 27035 FAQ (Incident Management, Team Roles, and Evidence)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27035/faq" source_url: "https://www.sorena.io/artifacts/global/iso-27035/faq" author: "Sorena AI" description: "Frequently asked questions about ISO/IEC 27035. Understand the 2023 series structure, IMT and IRT roles, event report forms, incident logs, prioritization." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27035 FAQ" - "ISO/IEC 27035 explained" - "IMT" - "IRT" - "incident coordinator" - "event report" - "incident management log" - "ISO 27035-1 2023" - "ISO 27035-2 2023" - "ISO 27035-3 2020" - "ISO 27035 vs NIST 800-61r3" - "GLOBAL compliance" - "ISO/IEC 27035" - "FAQ" - "Incident management" - "Incident response" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27035 FAQ (Incident Management, Team Roles, and Evidence) Frequently asked questions about ISO/IEC 27035. Understand the 2023 series structure, IMT and IRT roles, event report forms, incident logs, prioritization. *FAQ* *GLOBAL* ## ISO 27035 FAQ Quick answers to the ISO/IEC 27035 questions that matter in real incident programs. Focus on series structure, team roles, documentation, prioritization, testing, and improvement. ISO/IEC 27035 is a series, not a single playbook. That is why teams often misread it. The practical questions are usually about structure, ownership, records, and how to keep the capability current. These answers focus on those issues rather than generic incident response advice. ## What does the ISO 27035 series include today? The grounded series here consists of ISO/IEC 27035-1:2023 second edition for principles and process, ISO/IEC 27035-2:2023 second edition for planning and preparation, and ISO/IEC 27035-3:2020 first edition for ICT response operations. Use Part 1 as the overall process frame, Part 2 as the capability build guide, and Part 3 as the operational response guide. - Part 1: process, communication, and documentation - Part 2: policy, plan, teams, relationships, awareness, exercises, metrics, and lessons learned - Part 3: detection, notification, triage, analysis, containment, eradication, and recovery ## Why do the 2023 revisions matter? They strengthen the management model. Part 1 and Part 2 now explicitly define the incident management team and the incident coordinator, and Part 2 expands the planning and learning structure. If your current process only names a SOC and an on-call responder, you are likely missing the management and coordination layer the revised series expects. - Newer series framing makes team roles and governance more explicit - Lessons learned and evaluation are treated as formal capability activities, not optional extras ## What is the difference between IMT, IRT, incident coordinator, and point of contact? The incident management team handles coordination, governance, and the broader incident management process. The incident response team performs operational response actions. The incident coordinator drives investigations and decisions across teams. The point of contact handles intake and routing. In smaller organizations one person can fill more than one role, but the responsibilities still need to be separated conceptually. - IMT: oversight, coordination, records, escalations, and improvement - IRT: technical operations and response execution - Incident coordinator: cross-team decision coordination - PoC: intake, routing, and early handling discipline ## What records should we keep for each incident? At minimum, keep an event report and an incident management log. Part 2 also provides example forms and record items, and Part 1 makes documentation a core capability component. The log should capture decisions, actions, timestamps, ownership, severity rationale, and outcomes. - Event report for intake and early classification - Incident management log for the full case history - Post-incident review and corrective action tracking after closure ## How should we prioritize and escalate incidents? Part 2 expects a classification scale and includes example approaches to categorization, evaluation, and prioritization. The evaluation logic should fit your information classification policy and should support documented severity levels and escalation rules. Predetermined time frames only work if the prioritization model is explicit. - Use a small set of severity levels with explicit thresholds - Tie each level to response priority, leadership involvement, and communications cadence - Record the severity rationale so the decision can be reviewed later ## What does the standard expect for exercises and capability monitoring? Part 2 covers awareness, training, testing, exercises, and incident response capability monitoring with metrics and governance. It also expects periodic evaluation of the IMT and follow through on lessons learned. A mature program treats exercises and metrics as inputs to plan maintenance, not as separate compliance paperwork. - Exercise both technical response and management decision-making - Track metrics that show readiness and execution quality - Review the capability register and external support arrangements on a cadence ## How does ISO 27035 relate to NIST SP 800-61r3? They are compatible. ISO 27035 gives you the management process, team structure, and documentation model. NIST SP 800-61r3 gives you a current NIST incident response profile aligned to CSF 2.0 and published as a final document on April 3, 2025. Many organizations use ISO as the stable management backbone and NIST to enrich operational depth and CSF mapping. - Keep one set of playbooks and logs - Map the same records to both ISO and NIST review expectations *Recommended next step* *Placement: after the FAQ section* ## Use ISO 27035 FAQ as a cited research workflow Research Copilot can take ISO 27035 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on ISO 27035 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO 27035 FAQ](/solutions/research-copilot.md): Start from ISO 27035 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO 27035](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27035 FAQ. ## Primary sources - [ISO/IEC 27035-1:2023 standard page](https://www.iso.org/standard/78973.html?ref=sorena.io) - Official ISO page for Part 1. - [ISO/IEC 27035-2:2023 standard page](https://www.iso.org/standard/78974.html?ref=sorena.io) - Official ISO page for Part 2. - [ISO/IEC 27035-3:2020 standard page](https://www.iso.org/standard/74033.html?ref=sorena.io) - Official ISO page for Part 3. - [NIST SP 800-61 Rev. 3 final page](https://csrc.nist.gov/pubs/sp/800/61/r3/final) - Official NIST page confirming the final publication date and supersession of Rev. 2. ## Related Topic Guides - [ISO 27035 Compliance (Incident Management Operating Model)](/artifacts/global/iso-27035/compliance.md): A practical ISO/IEC 27035 compliance playbook for incident management. - [ISO 27035 Incident Response Playbook (Roles, Forms, and Operations)](/artifacts/global/iso-27035/incident-response-playbook.md): A practical ISO/IEC 27035 incident response playbook that covers event reporting, triage, analysis, containment, eradication, recovery, communications. - [ISO 27035 Incident Severity and Escalation Matrix (Classification and Priority Template)](/artifacts/global/iso-27035/incident-severity-and-escalation-matrix.md): A grounded ISO/IEC 27035 severity and escalation matrix template for classification, evaluation, prioritization, predetermined response times. - [ISO 27035 vs NIST SP 800-61r3 (Incident Response Mapping)](/artifacts/global/iso-27035/iso-27035-vs-nist-800-61r3.md): Compare ISO/IEC 27035 and NIST SP 800-61r3 for incident response. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27035/faq --- --- title: "ISO 27035 Incident Response Playbook (Roles, Forms, and Operations)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27035/incident-response-playbook" source_url: "https://www.sorena.io/artifacts/global/iso-27035/incident-response-playbook" author: "Sorena AI" description: "A practical ISO/IEC 27035 incident response playbook that covers event reporting, triage, analysis, containment, eradication, recovery, communications." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27035 incident response playbook" - "ISO/IEC 27035 incident response procedure" - "incident coordinator" - "IMT" - "IRT" - "event report" - "incident notification" - "incident triage" - "containment eradication recovery" - "incident communications" - "GLOBAL compliance" - "ISO/IEC 27035" - "Incident response playbook" - "Lessons learned" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27035 Incident Response Playbook (Roles, Forms, and Operations) A practical ISO/IEC 27035 incident response playbook that covers event reporting, triage, analysis, containment, eradication, recovery, communications. *Playbook* *GLOBAL* ## ISO 27035 Incident Response Playbook A step by step incident response playbook aligned to the ISO/IEC 27035 series. Built for speed, decision clarity, evidence quality, and clean handoffs between management and technical responders. The ISO/IEC 27035 series expects incident response to be run through structured intake, assessment, response operations, and learning. This playbook translates that into a usable operating sequence with defined forms, roles, escalation points, and evidence requirements. ## Phase 0: prepare the command structure before the incident Part 2 makes planning and preparation a first class activity. That means the playbook should already name the IMT, IRT, incident coordinator, point of contact, external support paths, and approval authorities before the first event arrives. If these choices are made during the incident, the response is already behind. - Publish role ownership and delegation rules - Maintain external support contacts for legal, forensics, providers, CERTs, regulators, and communications - Keep the capability register and the playbook version current *Recommended next step* *Placement: after the workflow or playbook section* ## Turn ISO 27035 Incident Response Playbook into an operational assessment Assessment Autopilot can take ISO 27035 Incident Response Playbook from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on ISO 27035 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 27035 Incident Response Playbook](/solutions/assessment.md): Start from ISO 27035 Incident Response Playbook and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 27035](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27035 Incident Response Playbook. ## Phase 1: detect and report with a usable event form Part 2 expects an event report form and criteria for accepting a report based on completeness. Reports should be completed immediately when a suspected event may cause substantial loss or damage to the organization. The goal is not a perfect report. The goal is a report that is complete enough to support routing and early assessment. - Capture reporter, time, suspected event type, affected asset or service, observed impact, and contact path - Define what makes a report acceptable for triage and how missing information is chased down - Record the intake channel and handoff time to the PoC or triage owner ## Phase 2: assess and decide using the classification scale Part 1 and Part 2 both expect organizations to decide whether an event is an incident and to do so within predetermined time frames. The incident coordinator should use the classification scale, affected service context, and severity logic to set the response path. This decision should be logged, not inferred later from chat history. - Classify the event type and affected resource - Assign severity, priority, and escalation level - Document who decided, when they decided, and what evidence they used ## Phase 3: triage and analysis Part 3 provides operational guidance for triage and analysis. The objective is to verify scope, understand what happened, and preserve evidence and analysis results in a way that supports later investigation and recovery. Analysis depth should match the incident severity and the need for containment speed. - Confirm scope, affected systems, affected users, and likely propagation path - Preserve volatile and durable evidence where needed for forensics or legal follow-up - Keep analysis results in a location that can be referenced from the incident log ## Phase 4: containment Containment is about preventing the incident from growing while protecting recovery options and investigation quality. Part 3 specifically distinguishes containment from eradication and recovery, which matters because each phase has different tradeoffs. Containment decisions should be explicit, because the fastest action is not always the best action. - State the containment goal before executing the action - Record the containment strategy chosen and the rejected alternatives if the decision was material - Track any customer, business, or legal impacts caused by the containment step itself ## Phase 5: eradication and recovery Eradication removes the root cause or the active foothold. Recovery restores normal operation safely. Part 3 expects these to be treated as separate operational concerns. Do not declare recovery complete until integrity and service objectives have been checked. - Record the root cause removal method and validation checks - Restore systems with explicit integrity and readiness criteria - Log any residual risk accepted at service restoration time ## Phase 6: communications and information sharing Part 2 expects rules and circumstances for internal and external information sharing. It also points to the need for legal review and for recognized information marking approaches such as traffic light protocol if your organization adopts them. Communications should be consistent with the classification policy and should not rely on improvised executive updates. - Use a fixed update cadence per severity level - Predefine who can notify customers, regulators, providers, CERTs, or law enforcement - Mark shared information according to your approved disclosure model ## Phase 7: close, learn, and improve Part 2 expects lessons learned, IMT evaluation, plan improvement, control improvement, and risk review where incident reality differs from prior assumptions. Closure should therefore produce more than a closed ticket status. The post-incident phase is where the incident becomes useful to the organization. - Complete the post-incident review and link corrective actions to owners and deadlines - Update the plan, forms, or team structure where the response exposed weaknesses - Review whether the incident changes risk ratings, control design, or training needs ## Primary sources - [ISO/IEC 27035-1:2023 standard page](https://www.iso.org/standard/78973.html?ref=sorena.io) - Official ISO page for Part 1 process and documentation. - [ISO/IEC 27035-2:2023 standard page](https://www.iso.org/standard/78974.html?ref=sorena.io) - Official ISO page for planning, forms, teams, and lessons learned. - [ISO/IEC 27035-3:2020 standard page](https://www.iso.org/standard/74033.html?ref=sorena.io) - Official ISO page for ICT incident response operations. ## Related Topic Guides - [ISO 27035 Compliance (Incident Management Operating Model)](/artifacts/global/iso-27035/compliance.md): A practical ISO/IEC 27035 compliance playbook for incident management. - [ISO 27035 FAQ (Incident Management, Team Roles, and Evidence)](/artifacts/global/iso-27035/faq.md): Frequently asked questions about ISO/IEC 27035. Understand the 2023 series structure, IMT and IRT roles, event report forms, incident logs, prioritization. - [ISO 27035 Incident Severity and Escalation Matrix (Classification and Priority Template)](/artifacts/global/iso-27035/incident-severity-and-escalation-matrix.md): A grounded ISO/IEC 27035 severity and escalation matrix template for classification, evaluation, prioritization, predetermined response times. - [ISO 27035 vs NIST SP 800-61r3 (Incident Response Mapping)](/artifacts/global/iso-27035/iso-27035-vs-nist-800-61r3.md): Compare ISO/IEC 27035 and NIST SP 800-61r3 for incident response. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27035/incident-response-playbook --- --- title: "ISO 27035 Incident Severity and Escalation Matrix (Classification and Priority Template)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27035/incident-severity-and-escalation-matrix" source_url: "https://www.sorena.io/artifacts/global/iso-27035/incident-severity-and-escalation-matrix" author: "Sorena AI" description: "A grounded ISO/IEC 27035 severity and escalation matrix template for classification, evaluation, prioritization, predetermined response times." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27035 incident severity matrix" - "ISO 27035 escalation matrix" - "ISO 27035 prioritization" - "incident classification scale" - "incident evaluation" - "incident prioritization" - "predetermined time frames" - "event report" - "incident management log" - "GLOBAL compliance" - "ISO/IEC 27035" - "Incident severity" - "Escalation matrix" - "Triage and decision-making" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27035 Incident Severity and Escalation Matrix (Classification and Priority Template) A grounded ISO/IEC 27035 severity and escalation matrix template for classification, evaluation, prioritization, predetermined response times. *Template* *GLOBAL* ## ISO 27035 Incident Severity and Escalation Matrix A practical severity and escalation template grounded in ISO/IEC 27035 classification and prioritization guidance. Use it to make assessment and decision-making faster, more consistent, and easier to review after the fact. Part 2 of ISO/IEC 27035 includes example approaches to categorization, evaluation, and prioritization of information security events and incidents. The purpose is consistency. A good severity matrix should let different responders reach the same answer about priority and escalation from the same facts. ## Start with the classification scale, not the pager labels The standard expects the incident management plan to reference a document describing event and incident classification and severity ratings if they are used. That means severity should be built on top of a stable classification scale, not invented separately by each team. Your matrix should classify the event type and the affected resource before assigning priority. - Classify the incident type consistently across reports - Identify the affected asset or service and the relevant business owner - Keep the scale aligned with the information classification policy ## Evaluation model: measure consequences, not only technical symptoms Part 2 states that incident evaluation determines impacts and consequences to the organization and the priority to respond. That means the matrix should consider business, legal, and service consequences as well as technical damage. Use a small number of dimensions with thresholds that can be applied quickly. - Confidentiality, integrity, and availability impact - Business service criticality and customer impact - Scope of affected systems, users, sites, or tenants - Regulatory, contractual, reputational, and recovery cost impact ## Prioritization model: tie the score to predetermined response time frames Part 1 expects incidents to be dealt with efficiently and within predetermined time frames. A severity matrix is incomplete if it only names a level and does not bind that level to a response expectation. Each priority should specify response ownership, approval authority, update cadence, and closure expectations. - Critical priority: immediate IMT and executive involvement with tight update cadence - High priority: incident coordinator led response with formal containment and business owner involvement - Medium priority: managed operational response with defined review triggers - Low priority: documented disposition or backlog handling with reassessment rules *Recommended next step* *Placement: after the workflow or playbook section* ## Turn ISO 27035 Incident Severity and Escalation Matrix into an operational assessment Assessment Autopilot can take ISO 27035 Incident Severity and Escalation Matrix from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on ISO 27035 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 27035 Incident Severity and Escalation Matrix](/solutions/assessment.md): Start from ISO 27035 Incident Severity and Escalation Matrix and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 27035](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27035 Incident Severity and Escalation Matrix. ## Escalation triggers: define the situations that override debate A stable matrix includes automatic escalation triggers so teams do not waste time renegotiating severity during a fast moving incident. These triggers should be tied to the event type, affected resource, and consequence pattern. The exact triggers vary by organization, but the logic should be deterministic. - Potential exposure of regulated or highly classified information - Compromise of privileged access or core identity systems - Broad customer or production outage that threatens recovery objectives - Evidence of active attacker persistence, lateral movement, or destructive action ## Required records: severity decisions should be reviewable later The standard expects documentation through event reports and incident management logs. Your matrix should require responders to record why a severity level was chosen, not only what the final label was. That record is what lets the organization improve the model later. - Record the observed facts used to classify the event - Record the consequence assumptions used in evaluation and prioritization - Record the escalation decision, decision maker, and time of decision ## Improve the matrix with actual incident outcomes Part 2 expects lessons learned and review of risk assessment results when incidents show actual consequences differ from prior expectations. Severity design should therefore be updated using real incident data, not only opinion. If the matrix regularly understates or overstates incidents, the governance loop is broken. - Compare predicted impact with actual impact after incident closure - Update thresholds where recurrence shows the model is off - Use recovery cost, restoration time, and customer effect data to recalibrate the matrix ## Primary sources - [ISO/IEC 27035-1:2023 standard page](https://www.iso.org/standard/78973.html?ref=sorena.io) - Official ISO page for process and predetermined time frame context. - [ISO/IEC 27035-2:2023 standard page](https://www.iso.org/standard/78974.html?ref=sorena.io) - Official ISO page for classification scales, forms, and prioritization guidance. ## Related Topic Guides - [ISO 27035 Compliance (Incident Management Operating Model)](/artifacts/global/iso-27035/compliance.md): A practical ISO/IEC 27035 compliance playbook for incident management. - [ISO 27035 FAQ (Incident Management, Team Roles, and Evidence)](/artifacts/global/iso-27035/faq.md): Frequently asked questions about ISO/IEC 27035. Understand the 2023 series structure, IMT and IRT roles, event report forms, incident logs, prioritization. - [ISO 27035 Incident Response Playbook (Roles, Forms, and Operations)](/artifacts/global/iso-27035/incident-response-playbook.md): A practical ISO/IEC 27035 incident response playbook that covers event reporting, triage, analysis, containment, eradication, recovery, communications. - [ISO 27035 vs NIST SP 800-61r3 (Incident Response Mapping)](/artifacts/global/iso-27035/iso-27035-vs-nist-800-61r3.md): Compare ISO/IEC 27035 and NIST SP 800-61r3 for incident response. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27035/incident-severity-and-escalation-matrix --- --- title: "ISO 27035 vs NIST SP 800-61r3 (Incident Response Mapping)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27035/iso-27035-vs-nist-800-61r3" source_url: "https://www.sorena.io/artifacts/global/iso-27035/iso-27035-vs-nist-800-61r3" author: "Sorena AI" description: "Compare ISO/IEC 27035 and NIST SP 800-61r3 for incident response." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27035 vs NIST 800-61r3" - "ISO 27035 NIST mapping" - "NIST SP 800-61r3 final" - "incident response framework comparison" - "CSF 2.0 incident response" - "incident management evidence" - "GLOBAL compliance" - "ISO/IEC 27035" - "NIST SP 800-61r3" - "Incident response" - "Mapping" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27035 vs NIST SP 800-61r3 (Incident Response Mapping) Compare ISO/IEC 27035 and NIST SP 800-61r3 for incident response. *Comparison* *GLOBAL* ## ISO 27035 ISO 27035 vs NIST SP 800-61r3 A practical mapping of ISO incident management and the current NIST incident response profile. Use it when your organization needs one response program that satisfies ISO style audits and NIST or CSF 2.0 operational expectations. ISO/IEC 27035 and NIST SP 800-61r3 are compatible, but they are not the same thing. ISO/IEC 27035 is a structured incident management series with explicit process phases, team roles, forms, and documentation expectations. NIST SP 800-61r3 is a CSF 2.0 community profile for incident response and cybersecurity risk management, finalized on April 3, 2025 and superseding Rev. 2. Use them together by keeping one operating model and one evidence set. ## What changed on the NIST side NIST SP 800-61r3 final was published on April 3, 2025. It superseded SP 800-61 Rev. 2 from August 2012 and reframed the guidance as incident response recommendations and considerations for cybersecurity risk management, aligned to CSF 2.0. That matters because many old comparison pages still treat Rev. 2 as current or still describe the older four phase handling model as the NIST baseline. - Current NIST reference: SP 800-61r3 final - Rev. 2 is withdrawn and no longer the current baseline - NIST now positions incident response explicitly within the six CSF 2.0 functions ## What ISO 27035 gives you that NIST does not emphasize in the same way ISO/IEC 27035 is stronger on the management system shape of incident handling. It gives you the process frame, team model, event report and incident log expectations, classification and prioritization hooks, and a formal learn lessons structure across the series. For organizations that need audit ready evidence, those features are extremely useful. - Defined phases: plan and prepare, detect and report, assess and decide, respond, learn lessons - Defined team concepts: IMT, IRT, incident coordinator, point of contact - Defined records: event reports, incident management logs, forms, and plan references ## What NIST SP 800-61r3 adds usefully NIST SP 800-61r3 is stronger on integrating incident response into broader cybersecurity risk management activities and CSF 2.0. It gives organizations a modern NIST structure for connecting response to governance, detection, recovery, and information sharing choices. That makes it useful for teams already using NIST CSF 2.0 or other NIST publications as the broader operating frame. - CSF 2.0 integration across all functions - Current NIST terminology and modernization beyond the 2012 guide - A practical bridge for organizations standardizing on NIST publications ## Best process mapping The cleanest mapping is to treat ISO 27035 as the stable process skeleton and NIST SP 800-61r3 as the current NIST overlay for risk management and CSF alignment. This keeps the response lifecycle stable while letting teams satisfy NIST oriented stakeholders. Do not create separate response processes for each framework. - ISO plan and prepare maps to NIST governance and readiness activities - ISO detect and report maps to NIST detection and incident intake activities - ISO assess and decide maps to NIST prioritization and response decision activities - ISO respond maps to technical and organizational response execution - ISO learn lessons maps to NIST improvement and risk management feedback ## Best artifact mapping Keep one set of records and map them across both frameworks. ISO 27035 is explicit enough about forms and logs that it can anchor the evidence model. NIST can then be satisfied by the same records plus any CSF specific reporting views you need. This is the fastest way to avoid duplicate work and contradictory records. - One incident management policy and plan - One event report form and one incident management log structure - One severity matrix and escalation model - One exercise program and one improvement tracker ## Recommendation for mixed ISO and NIST environments Use ISO 27035 to govern process design, team roles, and evidence. Use NIST SP 800-61r3 to express the same capability in NIST and CSF 2.0 terms. Then map the records to ISO 27001, customer assurance, and any NIST based internal reporting. If a team asks whether to choose ISO or NIST, the better question is whether your records and playbooks are coherent enough to satisfy both without duplication. - Keep ISO 27035 as the canonical response process frame - Use NIST SP 800-61r3 for current NIST and CSF 2.0 alignment - Review your artifacts once and map them many times *Recommended next step* *Placement: after the comparison section* ## Use ISO 27035 ISO 27035 vs NIST SP 800-61r3 as a cited research workflow Research Copilot can take ISO 27035 ISO 27035 vs NIST SP 800-61r3 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on ISO 27035 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO 27035 ISO 27035 vs NIST SP 800-61r3](/solutions/research-copilot.md): Start from ISO 27035 ISO 27035 vs NIST SP 800-61r3 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO 27035](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27035 ISO 27035 vs NIST SP 800-61r3. ## Primary sources - [ISO/IEC 27035-1:2023 standard page](https://www.iso.org/standard/78973.html?ref=sorena.io) - Official ISO page for Part 1 principles and process. - [ISO/IEC 27035-2:2023 standard page](https://www.iso.org/standard/78974.html?ref=sorena.io) - Official ISO page for Part 2 planning and preparation. - [ISO/IEC 27035-3:2020 standard page](https://www.iso.org/standard/74033.html?ref=sorena.io) - Official ISO page for Part 3 ICT response operations. - [NIST SP 800-61 Rev. 3 final page](https://csrc.nist.gov/pubs/sp/800/61/r3/final) - Official NIST page showing the April 3, 2025 final publication and supersession of Rev. 2. - [NIST notice on SP 800-61 revision](https://csrc.nist.gov/news/2025/nist-revises-sp-800-61) - Official NIST announcement describing the incident response and CSF 2.0 positioning of Rev. 3. ## Related Topic Guides - [ISO 27035 Compliance (Incident Management Operating Model)](/artifacts/global/iso-27035/compliance.md): A practical ISO/IEC 27035 compliance playbook for incident management. - [ISO 27035 FAQ (Incident Management, Team Roles, and Evidence)](/artifacts/global/iso-27035/faq.md): Frequently asked questions about ISO/IEC 27035. Understand the 2023 series structure, IMT and IRT roles, event report forms, incident logs, prioritization. - [ISO 27035 Incident Response Playbook (Roles, Forms, and Operations)](/artifacts/global/iso-27035/incident-response-playbook.md): A practical ISO/IEC 27035 incident response playbook that covers event reporting, triage, analysis, containment, eradication, recovery, communications. - [ISO 27035 Incident Severity and Escalation Matrix (Classification and Priority Template)](/artifacts/global/iso-27035/incident-severity-and-escalation-matrix.md): A grounded ISO/IEC 27035 severity and escalation matrix template for classification, evaluation, prioritization, predetermined response times. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27035/iso-27035-vs-nist-800-61r3 --- --- title: "ISO 27036 Compliance (Supplier Relationship Security Program)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27036/compliance" source_url: "https://www.sorena.io/artifacts/global/iso-27036/compliance" author: "Sorena AI" description: "A practical ISO/IEC 27036 compliance playbook for supplier relationship security: governance, lifecycle processes (planning, selection, agreement." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27036 compliance" - "ISO/IEC 27036 implementation guide" - "supplier relationship security" - "third party risk management program" - "supplier selection process" - "supplier agreement requirements" - "supplier relationship management process" - "indirect suppliers" - "subcontractor management" - "ICT supply chain security" - "cloud supply chain security" - "supplier monitoring cadence" - "supplier assurance evidence" - "GLOBAL compliance" - "ISO/IEC 27036" - "Third-party risk management" - "Audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27036 Compliance (Supplier Relationship Security Program) A practical ISO/IEC 27036 compliance playbook for supplier relationship security: governance, lifecycle processes (planning, selection, agreement. *Playbook* *GLOBAL* ## ISO 27036 Compliance A practical operating model for supplier relationship security based on ISO/IEC 27036. Designed for security, procurement, legal, and ISMS teams building third-party risk programs that scale. ISO/IEC 27036 is a multi-part standard that provides requirements and guidance for acquirers and suppliers on how to secure information in supplier relationships. ISO/IEC 27036-2 is the normative requirements part and provides the life cycle process framework that can be used as agreement requirements. ISO/IEC 27036-3 adds hardware, software, and services supply chain guidance, and ISO/IEC 27036-4 adds cloud service guidance. In practice, compliance means you can run supplier relationship planning, supplier selection, supplier agreements, supplier monitoring, and supplier exit as repeatable processes with audit-ready evidence. ## Use the right part of the series for the right risk problem Part 1 is the overview and concept layer. Part 2 is the normative requirements backbone. Part 3 adds deeper guidance for hardware, software, and services supply chain security, including life cycle process detail and essential supply chain practices. Part 4 addresses cloud service risks and acquisition controls. A mature supplier program uses Part 2 as the common operating model and then brings in Part 3 or Part 4 where the supplier relationship risk profile demands it. - Use Part 3 when product integrity, software components, services dependencies, or transition and disposal risks matter - Use Part 4 when cloud service location, limited auditability, multi-tenancy, and provider chain visibility matter - Keep one supplier process frame even when different parts of the series are applied ## What ISO 27036 compliance should look like in practice ISO 27036 is valuable because it turns third-party risk into lifecycle processes, not one-time questionnaires. It addresses both acquirers and suppliers, and explicitly acknowledges supply chain interdependencies and indirect suppliers. A strong program ties risk tiering to: due diligence depth, contract clause requirements, ongoing monitoring cadence, and remediation enforcement. - Outcome to target: supplier risks are assessed and treated across the supplier relationship life cycle - Contract reality: security expectations are expressed as agreement requirements with measurable evidence deliverables - Audit standard: you can show tiering, due diligence, monitoring, exceptions, and remediation tracking *Recommended next step* *Placement: after the compliance steps* ## Turn ISO 27036 Compliance into an operational assessment Assessment Autopilot can take ISO 27036 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on ISO 27036 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 27036 Compliance](/solutions/assessment.md): Start from ISO 27036 Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 27036](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27036 Compliance. ## Step 1 - Establish internal foundations (so supplier controls are enforceable) ISO/IEC 27036-2 expects organizations to have foundational processes implemented or planned (business management, risk management, operations, HR, and information security). Without internal foundations, supplier requirements cannot be enforced consistently. - Governance: define ownership across security, procurement, legal, and business owners - Risk model: tiering criteria and risk acceptance rules for third-party risk - Tooling: supplier inventory, evidence repository, and remediation tracking ## Step 2 - Run the supplier relationship life cycle as processes (not ad-hoc work) ISO/IEC 27036-2 structures requirements around a supplier relationship life cycle and organizes requirements by life cycle processes. The intent is repeatability and predictability at scale. Use the same process frame for every supplier relationship instance; adjust depth based on risk tier. - Supplier relationship planning: define goals, constraints, data types, and expected controls per tier - Supplier selection: due diligence and evidence requests based on risk; validate indirect suppliers where relevant - Supplier agreement: convert requirements into contract clauses + acceptance criteria + evidence delivery cadence - Supplier relationship management: monitor, reassess, handle changes, enforce remediation, and plan orderly transition or exit ## Step 3 - Manage indirect suppliers and supply chain visibility ISO/IEC 27036-1 highlights that ICT products and services are often not manufactured or operated solely by one supplier; successive supplier relationships form supply chains with interdependencies. Direct supplier controls can be insufficient; sometimes you need visibility into suppliers of the supplier (subcontractors/indirect suppliers). - Require disclosure of subcontractors where risk tier demands it (and define acceptable countries/locations where relevant) - Define flow-down obligations and ensure the supplier enforces them - Set audit and evidence models that balance transparency and supplier IP protection ## Step 4 - Cloud services supplier relationships (avoid responsibility gaps) ISO/IEC 27036-1 notes cloud computing introduces complex interconnectedness and risks, including unclear roles and responsibilities. ISO/IEC 27036-4 provides guidelines for cloud services throughout the supplier relationship life cycle. Treat cloud services as supply chains: multi-tenancy, virtualization, APIs, cross-border processing, limited customer audit rights, and provider-of-provider dependencies can introduce distinct risks and evidence needs. - Define roles and responsibilities clearly (customer vs provider) and bind them to contract clauses and evidence - Include cloud-specific evidence: access controls, segmentation/isolation, monitoring, and incident reporting responsibilities - Address cross-border and compliance constraints via provider disclosures and customer approvals - Use third-party assurance where individual customer audits are not practical for the service model ## Audit-ready evidence pack (what to keep current) ISO 27036 is easiest to audit when you keep a single evidence index that maps supplier tier -> required clauses -> required evidence -> refresh cadence. Build once, reuse: internal audit, customer assurance, regulator reviews, and procurement. - Supplier inventory with tiering and rationale (data types, system access, criticality) - Due diligence evidence: security questionnaires, certifications, reports, and gap remediation plans - Contract clause pack and deviations register (exceptions with approvals and compensating controls) - Ongoing monitoring: evidence refresh cadence, incident history, change notifications, and SLA performance ## Primary sources - [ISO/IEC 27036-2:2022 - ISO standard page (Reference 82060)](https://www.iso.org/standard/82060.html?ref=sorena.io) - Requirements framework and supplier relationship life cycle processes used as agreement requirements and for monitoring. - [ISO/IEC 27036-1:2021 - ISO standard page (Reference 82905)](https://www.iso.org/standard/82905.html?ref=sorena.io) - Overview and key concepts, including supply chain and cloud computing risk considerations. - [ISO/IEC 27036-3:2023 - ISO standard page](https://www.iso.org/standard/85200.html?ref=sorena.io) - Guidelines for hardware, software, and services supply chain security across life cycle processes. - [ISO/IEC 27036-4:2016 - ISO standard page (Reference 59689)](https://www.iso.org/standard/59689.html?ref=sorena.io) - Cloud services supplier relationship guidance across the lifecycle. - [ISO/IEC 27001:2022 - ISO standard page](https://www.iso.org/standard/27001?ref=sorena.io) - ISMS requirements and audit context where supplier security evidence is commonly required. - [ISO/IEC 27002 - ISO standard page](https://www.iso.org/standard/75652.html?ref=sorena.io) - Baseline controls where ISO 27036 provides more detailed supplier relationship guidance. ## Related Topic Guides - [ISO 27036 Contract Security Clauses (Supplier Agreements + Cloud)](/artifacts/global/iso-27036/contract-security-clauses.md): A practical ISO/IEC 27036 contract clause pack: supplier agreement requirements, audit and assurance evidence, subcontractor visibility. - [ISO 27036 FAQ (Supplier Security, Indirect Suppliers, Cloud Supply Chain)](/artifacts/global/iso-27036/faq.md): ISO/IEC 27036 FAQ for third-party risk management (TPRM): which parts to use across 27036-1, 27036-2, 27036-3, and 27036-4, supplier relationship life cycle. - [ISO 27036 Supplier Assurance Framework (Tiering, Evidence, Monitoring)](/artifacts/global/iso-27036/supplier-assurance-framework.md): Build an ISO/IEC 27036-aligned supplier assurance framework: tier suppliers, define supplier selection criteria and agreement requirements. - [ISO 27036 Third-Party Risk Checklist (Vendor Due Diligence + Monitoring)](/artifacts/global/iso-27036/third-party-risk-checklist.md): An ISO/IEC 27036-aligned third-party risk checklist: supplier tiering, vendor due diligence, supplier selection criteria, contract security clauses. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27036/compliance --- --- title: "ISO 27036 Contract Security Clauses (Supplier Agreements + Cloud)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27036/contract-security-clauses" source_url: "https://www.sorena.io/artifacts/global/iso-27036/contract-security-clauses" author: "Sorena AI" description: "A practical ISO/IEC 27036 contract clause pack: supplier agreement requirements, audit and assurance evidence, subcontractor visibility." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27036 contract security clauses" - "ISO/IEC 27036 supplier agreement requirements" - "supplier contract security clauses" - "vendor contract security clause pack" - "third party contract clauses" - "subcontractor clause" - "indirect supplier clause" - "audit rights clause" - "security assurance evidence clause" - "compliance monitoring and enforcement clause" - "corrective actions clause" - "incident notification clause" - "change management clause" - "data handling clause" - "secure deletion and return clause" - "cloud shared responsibility contract clauses" - "cloud supplier contract clauses" - "ISO 27036-4 cloud services clauses" - "GLOBAL compliance" - "ISO/IEC 27036" - "Contract security clauses" - "Supplier agreements" - "Cloud services" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27036 Contract Security Clauses (Supplier Agreements + Cloud) A practical ISO/IEC 27036 contract clause pack: supplier agreement requirements, audit and assurance evidence, subcontractor visibility. *Clauses* *GLOBAL* ## ISO 27036 Contract Security Clauses A contract clause pack to operationalize supplier security requirements and evidence deliverables. Aligned to ISO/IEC 27036 supplier relationship requirements, ICT supply chain guidance, and cloud services supplier guidance. ISO/IEC 27036-2 provides high-level requirements that acquirers can use as agreement requirements to define, manage, and monitor supplier agreements. ISO/IEC 27036-1 highlights supply chain interdependencies and indirect suppliers. ISO/IEC 27036-3 adds supply chain guidance for hardware, software, and services. ISO/IEC 27036-4 adds cloud service guidance where roles and responsibilities can be unclear. This page turns those ideas into clause patterns with measurable obligations and evidence artifacts. ## How to use this clause pack (tiered, evidence-first) Bind clauses to supplier tier. High-risk suppliers should accept stronger clauses and higher evidence cadence; low-risk suppliers can use lighter obligations. For each clause: define the obligation, define acceptance criteria, define the evidence deliverable, and define the refresh cadence. - Tiering: clause set varies by access, data sensitivity, and criticality - Evidence: require evidence artifacts that map to obligations (not marketing statements) - Exceptions: document deviations, approvals, and compensating controls *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep ISO 27036 Contract Security Clauses in one governed evidence system SSOT can take ISO 27036 Contract Security Clauses from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on ISO 27036 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for ISO 27036 Contract Security Clauses](/solutions/ssot.md): Start from ISO 27036 Contract Security Clauses and keep documents, evidence, and control records in one governed system. - [Talk through ISO 27036](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27036 Contract Security Clauses. ## Core agreement requirements (applies to most supplier relationships) These clause categories align to the supplier relationship life cycle: selection, agreement, and management. They are designed to be enforceable and auditable. If you adopt only a few clauses, start with: security responsibilities, incident notification, subcontractors, and audit/evidence model. - Scope and responsibilities: roles, boundaries, and supplier obligations for protecting acquirer information and systems - Information handling: data classification expectations, access controls, encryption expectations, retention, and secure deletion/return on termination - Incident notification: notification channels, maximum delay, required fields, and cooperation obligations - Change management: notification and approval requirements for material changes affecting security risk - Subcontractors/indirect suppliers: disclosure, approval model, flow-down obligations, and country/location constraints where relevant - Audit and assurance: audit rights model, transparency scope, independent assurance evidence, and audit safety limitations ## Hardware, software, and services supply chain clauses Part 3 of the series is where product and software supply chain issues should be made explicit. If the supplier provides software, firmware, hardware components, managed platforms, or critical service dependencies, the agreement should cover origin, integrity, transition, maintenance, and disposal expectations. This is also where software component transparency and secure update expectations belong if they materially affect the service risk profile. - Require supplier disclosure of critical dependencies and changes that materially affect supply chain risk - Require a secure development, update, and maintenance baseline where software or firmware is in scope - Define transition and disposal obligations so assets, components, and information are handled securely at exit ## Assurance evidence clauses (prove controls operate) Supplier controls must be evidencable. Build a clause that requires a reusable evidence pack for procurement and audits. Where invasive audits are risky or impractical, require independent evidence with sufficient transparency. - Evidence index: list required evidence artifacts and refresh cadence (e.g., annually + on material change) - Independent evidence: ISO 27001 certification scope, SOC reports, pen test summaries (where applicable) - Remediation: obligations to address findings with timelines and progress reporting ## Cloud services clauses (prevent responsibility gaps) ISO/IEC 27036-1 notes cloud services can create unclear roles and responsibilities; ISO/IEC 27036-4 provides cloud-specific supplier guidance across the supplier relationship life cycle. Treat cloud procurement like supply chain procurement: require explicit responsibility allocation and cloud-specific evidence. - Shared responsibility: define provider vs customer responsibilities for access, monitoring, backups, incident handling, and logging - Multi-tenancy and isolation: require isolation/segregation commitments and evidence of controls where relevant - Cross-border and jurisdiction: require disclosures of locations and constraints that affect compliance obligations - APIs and integrations: require security controls for interfaces and administrative access models - Transition and exit: require methods and acceptance criteria for moving customer assets to a different provider ## Clause-to-evidence mapping (what to retain internally) A clause pack only works if procurement and security can enforce it. Keep these internal artifacts as part of your supplier assurance operating model. Make it easy: one supplier record, one clause set, one evidence index. - Supplier tiering rationale + risk assessment summary - Signed contract clauses and negotiated deviations (exceptions register) - Evidence pack received + review notes + follow-up actions - Monitoring cadence records and remediation tracking ## Primary sources - [ISO/IEC 27036-2:2022 - ISO standard page (Reference 82060)](https://www.iso.org/standard/82060.html?ref=sorena.io) - High-level requirements used as agreement requirements and monitoring expectations. - [ISO/IEC 27036-1:2021 - ISO standard page (Reference 82905)](https://www.iso.org/standard/82905.html?ref=sorena.io) - Concepts: supply chain interdependencies, indirect suppliers, and cloud computing risks. - [ISO/IEC 27036-3:2023 - ISO standard page](https://www.iso.org/standard/85200.html?ref=sorena.io) - Guidance for hardware, software, and services supply chain clauses and life cycle responsibilities. - [ISO/IEC 27036-4:2016 - ISO standard page (Reference 59689)](https://www.iso.org/standard/59689.html?ref=sorena.io) - Cloud services supplier relationship guidance across acquisition lifecycle and operations. ## Related Topic Guides - [ISO 27036 Compliance (Supplier Relationship Security Program)](/artifacts/global/iso-27036/compliance.md): A practical ISO/IEC 27036 compliance playbook for supplier relationship security: governance, lifecycle processes (planning, selection, agreement. - [ISO 27036 FAQ (Supplier Security, Indirect Suppliers, Cloud Supply Chain)](/artifacts/global/iso-27036/faq.md): ISO/IEC 27036 FAQ for third-party risk management (TPRM): which parts to use across 27036-1, 27036-2, 27036-3, and 27036-4, supplier relationship life cycle. - [ISO 27036 Supplier Assurance Framework (Tiering, Evidence, Monitoring)](/artifacts/global/iso-27036/supplier-assurance-framework.md): Build an ISO/IEC 27036-aligned supplier assurance framework: tier suppliers, define supplier selection criteria and agreement requirements. - [ISO 27036 Third-Party Risk Checklist (Vendor Due Diligence + Monitoring)](/artifacts/global/iso-27036/third-party-risk-checklist.md): An ISO/IEC 27036-aligned third-party risk checklist: supplier tiering, vendor due diligence, supplier selection criteria, contract security clauses. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27036/contract-security-clauses --- --- title: "ISO 27036 FAQ (Supplier Security, Indirect Suppliers, Cloud Supply Chain)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27036/faq" source_url: "https://www.sorena.io/artifacts/global/iso-27036/faq" author: "Sorena AI" description: "ISO/IEC 27036 FAQ for third-party risk management (TPRM): which parts to use across 27036-1, 27036-2, 27036-3, and 27036-4, supplier relationship life cycle." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27036 FAQ" - "ISO/IEC 27036 questions" - "supplier relationship security FAQ" - "third party risk management FAQ" - "TPRM FAQ" - "supplier selection criteria ISO 27036" - "supplier agreement requirements ISO 27036" - "compliance monitoring and enforcement plan" - "corrective actions handling process" - "indirect suppliers and subcontractors ISO 27036" - "cloud supply chain security ISO 27036-4" - "shared responsibility ISO 27036" - "ISO 27036 vs ISO 27001" - "ISO 27036 vs ISO 27002" - "GLOBAL compliance" - "ISO/IEC 27036" - "Supplier relationship security" - "Third-party risk management" - "FAQ" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27036 FAQ (Supplier Security, Indirect Suppliers, Cloud Supply Chain) ISO/IEC 27036 FAQ for third-party risk management (TPRM): which parts to use across 27036-1, 27036-2, 27036-3, and 27036-4, supplier relationship life cycle. *FAQ* *GLOBAL* ## ISO 27036 FAQ Quick answers to real supplier security and third-party risk questions. Focused on ISO/IEC 27036 life cycle processes, contracts, evidence, monitoring, and cloud supply chains. ISO/IEC 27036 covers cybersecurity in supplier relationships. The standard is practical when you treat supplier security as a lifecycle and require evidence that controls operate: plan, select suppliers, bind requirements into agreements, and run ongoing monitoring and enforcement with corrective actions. Use this FAQ to navigate the parts, avoid common misunderstandings, and decide what to implement first. ## What is ISO/IEC 27036, and who is it for? ISO/IEC 27036 provides requirements and guidance for securing information and information systems in supplier relationships. It applies to both acquirers (customers) and suppliers, and it covers many supplier relationship types: products, services, ICT supply chains, and cloud computing. If you run procurement, security, legal, vendor management, or an ISMS program, ISO 27036 gives you a lifecycle structure for third-party risk management (TPRM) that can scale beyond questionnaires. - Best for: organizations that need repeatable supplier selection, enforceable agreements, and ongoing monitoring - Works with: ISO 27001/27002 (ISO 27036 provides deeper supplier-relationship guidance) - Key theme: evidence-first assurance and compliance monitoring/enforcement ## Which part should I use: ISO 27036-1 vs ISO 27036-2 vs ISO 27036-3 vs ISO 27036-4? Use ISO 27036-1 for overview and concepts. Use ISO 27036-2 for the normative requirements and lifecycle processes you can operationalize. Use ISO 27036-3 when you need deeper guidance for hardware, software, and services supply chain security. Use ISO 27036-4 when cloud services are in scope and you need supplier relationship guidance adapted to cloud service risks and cloud provider chains. In practice: read Part 1 to align stakeholders, implement Part 2 as your operating model, and apply Part 3 or Part 4 where the supplier type requires deeper controls. - ISO 27036-1: concepts and problem framing (indirect suppliers, cloud risk, relationship types) - ISO 27036-2: requirements + supplier relationship life cycle processes (planning/selection/agreement/management) - ISO 27036-3: hardware, software, and services supply chain guidance, including deeper life cycle process coverage - ISO 27036-4: cloud services supplier relationship guidance (acquisition lifecycle, chain-of-providers) ## What does supplier relationship life cycle mean in ISO 27036-2? ISO/IEC 27036-2 structures requirements using a supplier relationship life cycle: supplier relationship planning process, supplier selection process, supplier relationship agreement process, and supplier relationship management process. This is valuable because it forces a repeatable flow across every supplier relationship instance and makes it easier to create audit-ready evidence. - Planning: define requirements framework and constraints per tier - Selection: perform due diligence and evidence-backed risk decision - Agreement: bind requirements into contract clauses + evidence cadence + enforcement - Management: monitor compliance, manage incidents/changes, and track corrective actions ## How should we handle indirect suppliers, subcontractors, and supply chain dependencies? ISO 27036-1 highlights supply chain interdependencies: a direct supplier often relies on other suppliers. ISO 27036-3 goes further for hardware, software, and services chains where dependencies, originators, and life cycle controls can materially affect risk. A practical approach is tier-based visibility and flow-down. You do not need full transparency for every subcontractor, but you do need it when the risk tier requires it. - Require disclosure of material subcontractors (who they are, what they do, and where they operate) - Define approval rules for new subcontractors and location/jurisdiction changes - Flow-down obligations: require equivalent security controls, evidence cadence, and incident/change notification downstream - Keep an exceptions register when full flow-down is not achievable and document compensating controls ## What should be in a compliance monitoring and enforcement plan? ISO 27036-2 expects monitoring and enforcement during the supplier relationship execution period. The plan should define how you verify compliance, how you handle findings, and how you ensure corrective actions are closed. A monitoring plan is most effective when it includes trend tracking and event-driven reassessments (not only annual refresh). - Monitoring cadence: tier-based periodic review + triggers on material change - Evidence model: required evidence, quality expectations, reviewer ownership, and storage/traceability - Corrective actions handling process: target dates, verification, closure criteria, and escalation thresholds - Termination path: when risks cannot be reduced to acceptable levels, exit/transition is a valid control ## How does ISO 27036 address cloud services and shared responsibility problems? ISO 27036-1 notes cloud computing can create unclear roles and responsibilities. ISO/IEC 27036-4 provides guidance for information security in cloud services, including the idea that the same lifecycle steps should be repeated for each customer-provider link in a cloud supply chain. Practically, you want explicit responsibility allocation (provider vs customer) and cloud-specific evidence for isolation, identity, monitoring, and location controls. - Define shared responsibility boundaries in the contract and in operating procedures - Require evidence for cloud-specific controls (identity, logging, isolation, region/jurisdiction transparency) - Treat cloud providers as part of a supply chain and apply flow-down requirements when they rely on other providers - Use event-driven reassessment: major architecture changes, region changes, provider changes, or certification loss ## How does ISO 27036 relate to ISO 27001 and ISO 27002? Many organizations use ISO 27001/27002 as their baseline ISMS and controls library. ISO 27036 is complementary: it provides deeper, lifecycle-driven requirements and guidance specifically for supplier relationships, where ISO 27002 often provides more general recommendations. If you are ISO 27001-audited, ISO 27036 helps you create supplier assurance artifacts that map cleanly to audit evidence expectations. - ISO 27001: ISMS requirements and audit context - ISO 27002: baseline supplier relationship controls - ISO 27036: lifecycle processes, agreement requirements, monitoring and enforcement, and cloud supply chain guidance *Recommended next step* *Placement: after the FAQ section* ## Use ISO 27036 FAQ as a cited research workflow Research Copilot can take ISO 27036 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on ISO 27036 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO 27036 FAQ](/solutions/research-copilot.md): Start from ISO 27036 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO 27036](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27036 FAQ. ## Primary sources - [ISO/IEC 27036-1:2021 - ISO standard page (Reference 82905)](https://www.iso.org/standard/82905.html?ref=sorena.io) - Overview and concepts: supplier relationship types, risks, interdependencies, and indirect suppliers. - [ISO/IEC 27036-2:2022 - ISO standard page (Reference 82060)](https://www.iso.org/standard/82060.html?ref=sorena.io) - Normative requirements; defines supplier relationship life cycle processes and monitoring/enforcement expectations. - [ISO/IEC 27036-3:2023 - ISO standard page](https://www.iso.org/standard/85200.html?ref=sorena.io) - Guidelines for hardware, software, and services supply chain security and deeper life cycle coverage. - [ISO/IEC 27036-4:2016 - ISO standard page (Reference 59689)](https://www.iso.org/standard/59689.html?ref=sorena.io) - Cloud services supplier relationship guidance across lifecycle and supply chain links. - [ISO/IEC 27001:2022 - ISO standard page](https://www.iso.org/standard/27001?ref=sorena.io) - ISMS context where supplier assurance evidence is commonly required. - [ISO/IEC 27002 - ISO standard page](https://www.iso.org/standard/75652.html?ref=sorena.io) - Baseline controls; ISO 27036 provides more detailed supplier relationship guidance. ## Related Topic Guides - [ISO 27036 Compliance (Supplier Relationship Security Program)](/artifacts/global/iso-27036/compliance.md): A practical ISO/IEC 27036 compliance playbook for supplier relationship security: governance, lifecycle processes (planning, selection, agreement. - [ISO 27036 Contract Security Clauses (Supplier Agreements + Cloud)](/artifacts/global/iso-27036/contract-security-clauses.md): A practical ISO/IEC 27036 contract clause pack: supplier agreement requirements, audit and assurance evidence, subcontractor visibility. - [ISO 27036 Supplier Assurance Framework (Tiering, Evidence, Monitoring)](/artifacts/global/iso-27036/supplier-assurance-framework.md): Build an ISO/IEC 27036-aligned supplier assurance framework: tier suppliers, define supplier selection criteria and agreement requirements. - [ISO 27036 Third-Party Risk Checklist (Vendor Due Diligence + Monitoring)](/artifacts/global/iso-27036/third-party-risk-checklist.md): An ISO/IEC 27036-aligned third-party risk checklist: supplier tiering, vendor due diligence, supplier selection criteria, contract security clauses. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27036/faq --- --- title: "ISO 27036 Supplier Assurance Framework (Tiering, Evidence, Monitoring)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27036/supplier-assurance-framework" source_url: "https://www.sorena.io/artifacts/global/iso-27036/supplier-assurance-framework" author: "Sorena AI" description: "Build an ISO/IEC 27036-aligned supplier assurance framework: tier suppliers, define supplier selection criteria and agreement requirements." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27036 supplier assurance framework" - "ISO/IEC 27036 supplier relationship security" - "supplier tiering model" - "vendor tiering" - "supplier due diligence program" - "supplier monitoring cadence" - "third party risk management framework" - "TPRM operating model" - "supplier selection criteria" - "supplier agreement requirements" - "compliance monitoring and enforcement plan" - "corrective actions handling process" - "evidence-based assurance" - "audit-ready supplier assurance" - "ISO 27001 supplier evidence" - "indirect suppliers and subcontractors" - "cloud supply chain assurance" - "shared responsibility evidence" - "procurement security requirements" - "GLOBAL compliance" - "ISO/IEC 27036" - "Supplier assurance" - "Third-party risk management" - "Audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27036 Supplier Assurance Framework (Tiering, Evidence, Monitoring) Build an ISO/IEC 27036-aligned supplier assurance framework: tier suppliers, define supplier selection criteria and agreement requirements. *Framework* *GLOBAL* ## ISO 27036 Supplier Assurance Framework A practical operating model for supplier tiering, due diligence, evidence, and ongoing monitoring. For procurement, security, legal, and ISMS teams implementing ISO/IEC 27036 supplier relationship requirements at scale. ISO/IEC 27036-2 is the normative requirements part of ISO 27036. It structures supplier relationship security as lifecycle processes and expects compliance monitoring and enforcement with corrective actions. ISO/IEC 27036-3 adds deeper guidance for hardware, software, and services supply chain security, and ISO/IEC 27036-4 adds cloud service guidance. This page turns that series into a supplier assurance framework you can run repeatedly across vendors, subcontractors, and cloud providers. ## What ISO 27036 supplier assurance should achieve (outcomes, not checkboxes) In ISO 27036 terms, supplier assurance is how you maintain information security during the execution period of the supplier relationship in accordance with the supplier relationship agreement - and how you prove it via evidence. A high-performing supplier assurance framework connects four things: supplier tiering -> supplier selection criteria -> agreement requirements (contract clauses + evidence deliverables) -> monitoring and enforcement cadence. - Audit-ready by design: every obligation has acceptance criteria and evidence deliverables - Repeatable at scale: same process frame for every supplier, depth varies by tier - Enforceable in reality: monitoring plan + corrective actions workflow + termination path when risk is unacceptable *Recommended next step* *Placement: after the main workflow section* ## Turn ISO 27036 Supplier Assurance Framework into an operational assessment Assessment Autopilot can take ISO 27036 Supplier Assurance Framework from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on ISO 27036 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 27036 Supplier Assurance Framework](/solutions/assessment.md): Start from ISO 27036 Supplier Assurance Framework and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 27036](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27036 Supplier Assurance Framework. ## Step 1 - Tier suppliers (drive assurance depth with defensible risk criteria) Start with a tiering model that procurement can apply consistently and security can defend. Tiering should reflect what the supplier touches (information, systems, connectivity) and how critical the supplier is for business continuity and mission delivery. Use tiering to drive: due diligence depth, contract clause set, evidence cadence, and monitoring frequency. - Tier drivers: privileged access, network connectivity, regulated data, processing locations/jurisdiction, service criticality - Supplier types: products, services, ICT supply chain components, cloud services and SaaS - Visibility needs: indirect suppliers/subcontractors that become material to risk (flow-down obligations) ## Step 2 - Use ISO 27036-2 life cycle processes as your assurance backbone ISO/IEC 27036-2 structures requirements using the supplier relationship life cycle: supplier relationship planning, supplier selection, supplier relationship agreement, and supplier relationship management. Build your framework so each stage has defined inputs, activities, outputs, and owners. When auditors ask for the process, you can show the lifecycle and the evidence produced at each stage. - Planning: define security foundation, requirements framework, and constraints per tier - Selection: apply supplier selection criteria that includes security capabilities and commitment to compliance monitoring - Agreement: convert requirements into contract clauses, acceptance criteria, evidence deliverables, and enforcement plan - Management: monitor and enforce compliance, handle changes and incidents, track corrective actions to closure, and plan transition and disposal controls where needed ## Supply chain depth: when Part 3 needs to drive the assurance model For software, hardware, and critical service suppliers, Part 3 makes the assurance model deeper than a standard vendor review. The framework should look at life cycle activities such as design, implementation, transition, operation, maintenance, and disposal where those phases materially affect the risk. This is where software dependency transparency, secure update expectations, and supplier-of-supplier visibility usually become necessary. - Increase evidence depth for software intensive or component intensive suppliers - Ask for transition, maintenance, and disposal controls where product integrity or continuity matters - Tie assurance depth to the actual supply chain dependency, not only the contract value ## Step 3 - Build an evidence index (what evidence, what quality, what cadence) Supplier assurance fails when evidence is undefined, stale, or not attributable to the supplier relationship. Build an evidence index that is explicit and reusable: supplier tier -> required evidence artifacts -> cadence -> reviewer -> escalation path. Use multiple assurance channels. Certifications and third-party reports can be efficient, but you still need targeted evidence and change-driven refresh triggers. - Evidence quality: attributable (who/when), current (within cadence), traceable (maps to clause/control) - Cadence triggers: onboarding, periodic refresh (tier-based), and on material change (scope, location, ownership, certification loss) - Corrective actions handling process: findings -> owner -> target date -> verification -> closure - Exceptions register: negotiated deviations with approvals and compensating controls (kept current) ## Step 4 - Monitoring and enforcement (make compliance real) ISO 27036-2 expects compliance monitoring and enforcement activities and ongoing management of changes and incidents in accordance with agreed procedures. A mature framework makes monitoring operational, not aspirational. Define who monitors (acquirer team vs third party), what is reviewed, and how trends over time drive remediation and supplier decisions. - Compliance monitoring and enforcement plan: roles, scope, cadence, and escalation thresholds - Change monitoring: location changes, ownership changes, supplier ISMS changes, subcontractor changes, major architecture changes - Incident handling: notification windows, required fields, cooperation duties, and post-incident corrective actions - Termination decision: when risks cannot be reduced to an acceptable level, exit/transition is a valid control ## Indirect suppliers, subcontractors, and cloud supply chains (visibility + flow-down) ISO 27036-1 highlights supply chain interdependencies and indirect suppliers. ISO/IEC 27036-4 extends supplier relationship security to cloud services, where roles can be unclear and the same lifecycle steps should be repeated for each customer-provider link in the chain. Build a flow-down model that matches tier: require disclosure, approval, and evidence for material subcontractors, and require your supplier to enforce equivalent obligations downstream. - Disclosure: identify material subcontractors and what parts of the service they operate - Approval: define when acquirer approval is required (critical components, new regions, sensitive processing) - Flow-down: contractually require equivalent security obligations, monitoring support, and corrective actions downstream - Cloud specifics: shared responsibility boundaries, multi-tenancy isolation expectations, location and jurisdiction transparency, and third-party assurance where direct customer audit is limited ## Primary sources - [ISO/IEC 27036-2:2022 - ISO standard page (Reference 82060)](https://www.iso.org/standard/82060.html?ref=sorena.io) - Normative requirements; defines supplier relationship life cycle processes and compliance monitoring and enforcement expectations. - [ISO/IEC 27036-1:2021 - ISO standard page (Reference 82905)](https://www.iso.org/standard/82905.html?ref=sorena.io) - Overview and concepts: types of supplier relationships, risks, interdependencies, and indirect suppliers. - [ISO/IEC 27036-3:2023 - ISO standard page](https://www.iso.org/standard/85200.html?ref=sorena.io) - Guidelines for hardware, software, and services supply chain security, including deeper life cycle practices and software bill of materials context. - [ISO/IEC 27036-4:2016 - ISO standard page (Reference 59689)](https://www.iso.org/standard/59689.html?ref=sorena.io) - Guidelines for security of cloud services across acquisition lifecycle and supply chain links. - [ISO/IEC 27001:2022 - ISO standard page](https://www.iso.org/standard/27001?ref=sorena.io) - ISMS audit context where supplier assurance evidence is commonly required. - [ISO/IEC 27002 - ISO standard page](https://www.iso.org/standard/75652.html?ref=sorena.io) - Baseline supplier relationship controls; ISO 27036 provides more detailed lifecycle guidance. ## Related Topic Guides - [ISO 27036 Compliance (Supplier Relationship Security Program)](/artifacts/global/iso-27036/compliance.md): A practical ISO/IEC 27036 compliance playbook for supplier relationship security: governance, lifecycle processes (planning, selection, agreement. - [ISO 27036 Contract Security Clauses (Supplier Agreements + Cloud)](/artifacts/global/iso-27036/contract-security-clauses.md): A practical ISO/IEC 27036 contract clause pack: supplier agreement requirements, audit and assurance evidence, subcontractor visibility. - [ISO 27036 FAQ (Supplier Security, Indirect Suppliers, Cloud Supply Chain)](/artifacts/global/iso-27036/faq.md): ISO/IEC 27036 FAQ for third-party risk management (TPRM): which parts to use across 27036-1, 27036-2, 27036-3, and 27036-4, supplier relationship life cycle. - [ISO 27036 Third-Party Risk Checklist (Vendor Due Diligence + Monitoring)](/artifacts/global/iso-27036/third-party-risk-checklist.md): An ISO/IEC 27036-aligned third-party risk checklist: supplier tiering, vendor due diligence, supplier selection criteria, contract security clauses. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27036/supplier-assurance-framework --- --- title: "ISO 27036 Third-Party Risk Checklist (Vendor Due Diligence + Monitoring)" canonical_url: "https://www.sorena.io/artifacts/global/iso-27036/third-party-risk-checklist" source_url: "https://www.sorena.io/artifacts/global/iso-27036/third-party-risk-checklist" author: "Sorena AI" description: "An ISO/IEC 27036-aligned third-party risk checklist: supplier tiering, vendor due diligence, supplier selection criteria, contract security clauses." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 27036 third party risk checklist" - "ISO/IEC 27036 vendor risk checklist" - "third party risk management checklist" - "TPRM checklist" - "vendor due diligence checklist" - "supplier security checklist" - "supplier selection checklist" - "supplier agreement checklist" - "contract security clauses checklist" - "supplier assurance evidence checklist" - "compliance monitoring and enforcement plan" - "corrective actions workflow" - "indirect suppliers and subcontractors checklist" - "cloud vendor security checklist" - "SaaS due diligence checklist" - "supply chain security checklist" - "GLOBAL compliance" - "ISO/IEC 27036" - "Third-party risk management" - "Vendor due diligence" - "Supplier monitoring" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 27036 Third-Party Risk Checklist (Vendor Due Diligence + Monitoring) An ISO/IEC 27036-aligned third-party risk checklist: supplier tiering, vendor due diligence, supplier selection criteria, contract security clauses. *Checklist* *GLOBAL* ## ISO 27036 Third Party Risk Checklist A procurement + security operations checklist you can run repeatedly across suppliers and vendors. Aligned to ISO/IEC 27036-2 life cycle processes: planning, selection, agreement, and supplier relationship management. ISO/IEC 27036-2 structures supplier relationship security using a supplier relationship life cycle and expects compliance monitoring and enforcement with corrective actions. ISO/IEC 27036-3 adds deeper guidance for hardware, software, and services supply chain security, and ISO/IEC 27036-4 adds cloud service guidance. This checklist operationalizes those requirements as a repeatable third-party risk management flow across supplier onboarding, execution, change, and exit. ## How to use this ISO 27036 checklist (tiered, evidence-first) Run this checklist per supplier relationship instance, not once per year as a generic questionnaire. The goal is to produce a traceable evidence pack: tiering rationale, due diligence outputs, agreement clauses and deviations, monitoring records, and corrective actions. Apply depth based on tier. High-risk suppliers get deeper due diligence, stronger contract clauses, and tighter monitoring cadence. - Define owner per step: procurement owner, security reviewer, legal reviewer, service owner - Attach evidence to each checklist item and avoid unsupported yes-or-no answers - Document exceptions and compensating controls in an exceptions register *Recommended next step* *Placement: after the checklist block* ## Turn ISO 27036 Third Party Risk Checklist into an operational assessment Assessment Autopilot can take ISO 27036 Third Party Risk Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on ISO 27036 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 27036 Third Party Risk Checklist](/solutions/assessment.md): Start from ISO 27036 Third Party Risk Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 27036](/contact.md): Review your current process, evidence gaps, and next steps for ISO 27036 Third Party Risk Checklist. ## 1) Supplier relationship planning checklist (define requirements before choosing vendors) Planning prevents vendor lock-in to insecure choices. Define information security foundations, tiering criteria, and what an acceptable supplier looks like before you evaluate suppliers. Planning outputs become inputs to selection, agreement, and monitoring. - Define scope: what product/service is procured, what data types are involved, what systems are touched, what connectivity exists - Tier the supplier relationship instance (criticality + access + data sensitivity + jurisdiction) - Define baseline requirements framework per tier (minimum controls and evidence expectations) - Define monitoring expectations upfront (cadence, triggers, and enforcement model) ## 2) Supplier selection + due diligence checklist (evidence collection and risk decision) Supplier selection should be criteria-driven and evidence-backed. Collect proof that the supplier can meet agreement requirements and support compliance monitoring and enforcement. For higher tiers, include visibility into subcontractors and indirect suppliers when they materially affect risk. - Confirm governance: security ownership, escalation contacts, and incident response points of contact - Request assurance evidence: ISMS scope statements, independent assurance reports, control summaries tied to your requirements - Validate operational capabilities: vulnerability management, patching, secure update process, logging and monitoring, backup and restore testing - Assess supply chain: subcontractors, hosting providers, critical dependencies, and flow-down obligations - Software or component intensive suppliers: request dependency transparency, update process evidence, and transition or disposal controls where material - Cloud services: clarify shared responsibility (provider vs customer) and require cloud-specific evidence (isolation, identity, logging, region controls) ## 3) Supplier agreement checklist (bind requirements into enforceable clauses) ISO 27036-2 is often used as agreement requirements. The agreement should translate requirements into measurable obligations, acceptance criteria, evidence deliverables, and a compliance monitoring and enforcement plan. Avoid ambiguity: define timelines, required fields, and what happens on non-compliance. - Contract clause set by tier: responsibilities, data handling, access controls, change management, incident notification, termination/exit - Subcontractors: disclosure and approval model, flow-down obligations, location/jurisdiction constraints where applicable - Monitoring and enforcement: audit model, evidence cadence, corrective actions process, and escalation thresholds - Change and incident procedures: notification windows, required fields, cooperation duties, and post-incident actions ## 4) Onboarding + transition checklist (make controls real in operations) After signature, onboarding is where most supplier security breaks. Operationalize the agreement: provision least privilege access, configure integrations securely, and validate controls before full go-live. For complex services, require a transition plan and confirm unexpected-event handling during transition. - Access: least privilege roles, privileged access approval, and removal process - Security configuration baseline: logging, monitoring, encryption settings, and admin protections - Data flows: validate intended processing locations and storage/retention requirements - Transition plan: responsibilities, milestones, rollback, and communication paths for unexpected events - For product or software suppliers, confirm secure transition into operation and clear ownership of maintenance activities ## 5) Ongoing monitoring + enforcement checklist (the audit-proof part) ISO 27036-2 expects ongoing supplier relationship management: maintain information security, train impacted personnel, monitor and enforce compliance, and manage changes and incidents according to agreed procedures. Treat monitoring as a calendarized program with trend tracking and remediation closure, not an inbox of ad-hoc requests. - Evidence refresh cadence: periodic review plus event-driven review on material change - Compliance monitoring records: who reviewed what, findings, corrective actions, and closure proof - Change monitoring: location changes, ownership changes, certification loss/achievement, business continuity capability changes - Incident handling: notifications, containment collaboration, post-mortems, and corrective actions tracking - Escalation and termination: when risk cannot be reduced to acceptable levels, activate the exit plan ## 6) Offboarding + termination checklist (exit is a control) Termination is a security control when risks cannot be reduced. Plan exit early for high-tier suppliers: data return/deletion, access removal, and continuity of critical services. Keep evidence of termination actions and confirmations. - Access removal: disable accounts, revoke keys/tokens, rotate shared secrets - Data return/deletion: retention rules, deletion confirmations, backups handling, and residual data risks - Asset and documentation return: configurations, runbooks, logs per retention, and evidence index closure - Transition continuity: alternate supplier strategy and internal fallback plan - For hardware, software, or critical service suppliers, confirm disposal or decommissioning controls where assets or components remain in the environment ## Primary sources - [ISO/IEC 27036-2:2022 - ISO standard page (Reference 82060)](https://www.iso.org/standard/82060.html?ref=sorena.io) - Normative requirements; defines supplier relationship life cycle processes and monitoring/enforcement expectations. - [ISO/IEC 27036-1:2021 - ISO standard page (Reference 82905)](https://www.iso.org/standard/82905.html?ref=sorena.io) - Overview and concepts: supplier relationship types, risks, interdependencies, and indirect suppliers. - [ISO/IEC 27036-3:2023 - ISO standard page](https://www.iso.org/standard/85200.html?ref=sorena.io) - Guidance for hardware, software, and services supply chain security used when suppliers have deeper product or component risk. - [ISO/IEC 27036-4:2016 - ISO standard page (Reference 59689)](https://www.iso.org/standard/59689.html?ref=sorena.io) - Cloud services supplier relationship guidance across the lifecycle and supply chain. - [ISO/IEC 27001:2022 - ISO standard page](https://www.iso.org/standard/27001?ref=sorena.io) - ISMS context and audit expectations that typically require supplier assurance evidence. - [ISO/IEC 27002 - ISO standard page](https://www.iso.org/standard/75652.html?ref=sorena.io) - Baseline controls that ISO 27036 expands with supplier lifecycle requirements and guidance. ## Related Topic Guides - [ISO 27036 Compliance (Supplier Relationship Security Program)](/artifacts/global/iso-27036/compliance.md): A practical ISO/IEC 27036 compliance playbook for supplier relationship security: governance, lifecycle processes (planning, selection, agreement. - [ISO 27036 Contract Security Clauses (Supplier Agreements + Cloud)](/artifacts/global/iso-27036/contract-security-clauses.md): A practical ISO/IEC 27036 contract clause pack: supplier agreement requirements, audit and assurance evidence, subcontractor visibility. - [ISO 27036 FAQ (Supplier Security, Indirect Suppliers, Cloud Supply Chain)](/artifacts/global/iso-27036/faq.md): ISO/IEC 27036 FAQ for third-party risk management (TPRM): which parts to use across 27036-1, 27036-2, 27036-3, and 27036-4, supplier relationship life cycle. - [ISO 27036 Supplier Assurance Framework (Tiering, Evidence, Monitoring)](/artifacts/global/iso-27036/supplier-assurance-framework.md): Build an ISO/IEC 27036-aligned supplier assurance framework: tier suppliers, define supplier selection criteria and agreement requirements. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-27036/third-party-risk-checklist --- --- title: "ISO 42001 Compliance (AI Management System Playbook)" canonical_url: "https://www.sorena.io/artifacts/global/iso-42001/compliance" source_url: "https://www.sorena.io/artifacts/global/iso-42001/compliance" author: "Sorena AI" description: "A practical ISO/IEC 42001 compliance playbook to implement an AI Management System (AIMS): scope, AI policy, roles and responsibilities." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 42001 compliance" - "ISO/IEC 42001 compliance guide" - "AI management system compliance" - "AIMS implementation" - "ISO 42001 implementation guide" - "ISO 42001 audit readiness" - "ISO 42001 certification preparation" - "AI governance program" - "AI policy ISO 42001" - "AI risk assessment ISO 42001" - "AI risk treatment ISO 42001" - "AI system impact assessment" - "documented information ISO 42001" - "internal audit ISO 42001" - "management review ISO 42001" - "continual improvement ISO 42001" - "GLOBAL compliance" - "ISO/IEC 42001" - "AI management system" - "AI governance" - "Audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 42001 Compliance (AI Management System Playbook) A practical ISO/IEC 42001 compliance playbook to implement an AI Management System (AIMS): scope, AI policy, roles and responsibilities. *Playbook* *GLOBAL* ## ISO 42001 Compliance A practical implementation playbook for ISO/IEC 42001 AI Management System (AIMS) compliance. Designed for AI governance, risk, engineering, legal, and audit teams building repeatable evidence and accountability. ISO/IEC 42001 is a management system standard for organizations that develop, provide, or use AI systems. Compliance means more than drafting an AI policy. It means the organization can determine its role for each AI system, identify relevant interested parties, assess AI risks and impacts, select and justify controls, operate the system with documented information, and keep evidence current through monitoring, internal audit, management review, and corrective action. ## What ISO 42001 compliance looks like when it is actually grounded to the standard ISO 42001 is a management system for the organization role with respect to AI systems. The standard expects context, scope, leadership, planning, operation, evaluation, and improvement to work together as one system. A credible implementation shows how the organization develops, provides, or uses AI systems responsibly in pursuit of its objectives while meeting applicable requirements and expectations from relevant interested parties. - Outcome target: accountable AI governance across the full AI system life cycle - Audit target: documented scope, role determination, risk and impact records, operational evidence, and corrective-action closure - Practical target: one AIMS that works across product, engineering, compliance, procurement, and internal audit *Recommended next step* *Placement: after the compliance steps* ## Turn ISO 42001 Compliance into an operational assessment Assessment Autopilot can take ISO 42001 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on ISO 42001 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 42001 Compliance](/solutions/assessment.md): Start from ISO 42001 Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 42001](/contact.md): Review your current process, evidence gaps, and next steps for ISO 42001 Compliance. ## Step 1 - Define context, intended purpose, roles, and interested parties Clause 4 is more specific than generic management-system summaries suggest. The organization must consider the intended purpose of the AI systems it develops, provides, or uses and determine its roles with respect to those systems. The standard explicitly points to roles such as provider, customer or user, partner, integrator, and data provider. Those roles affect which requirements and controls apply and how deep the evidence needs to be. - Document the intended purpose of each in-scope AI system and the operating context - Identify relevant interested parties and their requirements, including legal, customer, and internal governance expectations - Keep the AIMS scope as documented information and revisit it when business context or AI use cases change ## Step 2 - Make leadership and AI policy operational Top management must establish an AI policy, assign responsibilities and authorities, and align the AIMS with strategic direction. The policy must exist as documented information and be available to interested parties as appropriate. Annex A and Annex B go further than a short policy statement. They expect review of the AI policy at planned intervals, reporting channels for concerns, and role allocation detailed enough to make accountability real. - Policy contents should reflect intended purpose, risk posture, interested-party expectations, and impact-assessment outputs - Roles should cover governance, human oversight, impact assessment, supplier relationships, and data quality management - Keep a reporting path for concerns about the organization role with respect to AI systems across the life cycle ## Step 3 - Run planning properly: AI risk, treatment, and impact assessment Clause 6 requires actions for risks and opportunities, AI risk assessment, AI risk treatment, AI system impact assessment, AI objectives, and planning of changes. This is where ISO 42001 becomes uniquely AI-specific. The standard requires documented information for the risk assessment process, the risk treatment process, and the results of impact assessments. Risk treatment must be checked against Annex A so necessary controls are not omitted, and exclusions should be justified. - Use AI system impact assessment results as an input to risk assessment, not a separate side document - Consider technical and societal context, intended use, foreseeable misuse, and applicable jurisdictions - Add discipline-specific impact work when safety, privacy, or security critical AI systems require it ## Step 4 - Operate the AIMS with documented information that is useful Clauses 7 and 8 expect resources, competence, awareness, communication, and controlled documented information, followed by operational planning and control. Evidence quality matters because the standard expects creation, updating, control, and retention of documented information. Annex A adds concrete operational expectations: AI system operation and monitoring, technical documentation for different interested parties, event-log recording, external reporting capability, incident communication, and supplier responsibility allocation. - Retain results of all AI risk assessments, AI risk treatments, and AI system impact assessments - Define operation and monitoring for each in-scope AI system, including repairs, updates, and support - Document technical information for users, partners, and supervisory authorities in the form each group needs - Record event logs at the relevant life-cycle phases and at minimum while the system is in use - Allocate responsibilities across suppliers, partners, customers, and other third parties where AI dependencies exist ## Step 5 - Build the audit and improvement loop around planned intervals and significant change ISO 42001 expects monitoring, measurement, analysis, evaluation, internal audit, management review, nonconformity handling, corrective action, and continual improvement. These are not optional finishing steps. They are the proof that the AIMS stays effective as AI systems, data, and contexts change. The standard is explicit that AI system impact assessments are not one-time. They must be performed at planned intervals or when significant changes are proposed to occur. - Define monitoring methods, timing, and evaluation cadence before the audit asks for them - Use management review to reassess changing interested-party expectations and monitoring results - Track nonconformities to closure and use recurrence to drive system-level improvement priorities ## Primary sources - [ISO/IEC 42001:2023 - ISO standard page](https://www.iso.org/standard/81230.html?ref=sorena.io) - Primary reference for ISO 42001 publication information and scope. - [Regulation (EU) 2024/1689 - Artificial Intelligence Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal source for EU AI Act comparison and evidence-reuse mapping. ## Related Topic Guides - [ISO 42001 Controls and Governance Model (Annex A + Operating Routines)](/artifacts/global/iso-42001/controls-and-governance-model.md): Turn ISO/IEC 42001 into an AI governance operating model: Annex A control objectives and controls, Annex B implementation guidance. - [ISO 42001 FAQ (AIMS, Risk Assessment, Impact Assessment, Audit)](/artifacts/global/iso-42001/faq.md): ISO/IEC 42001 FAQ for AI Management System (AIMS) implementation: what the standard covers, clause structure, Annex A controls. - [ISO 42001 Requirements (Clause-by-Clause Breakdown + Evidence)](/artifacts/global/iso-42001/requirements.md): An advanced ISO/IEC 42001 requirements breakdown: clauses 4-10 (context, leadership, planning, support, operation, performance evaluation, improvement). - [ISO 42001 vs EU AI Act (Mapping + Evidence Reuse)](/artifacts/global/iso-42001/iso-42001-vs-eu-ai-act.md): A practical ISO/IEC 42001 vs EU AI Act mapping: how an AI Management System (AIMS) supports AI Act obligations (risk management, data governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-42001/compliance --- --- title: "ISO 42001 Controls and Governance Model (Annex A + Operating Routines)" canonical_url: "https://www.sorena.io/artifacts/global/iso-42001/controls-and-governance-model" source_url: "https://www.sorena.io/artifacts/global/iso-42001/controls-and-governance-model" author: "Sorena AI" description: "Turn ISO/IEC 42001 into an AI governance operating model: Annex A control objectives and controls, Annex B implementation guidance." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 42001 controls" - "ISO 42001 Annex A controls" - "ISO/IEC 42001 controls and governance model" - "AI governance framework ISO 42001" - "AI management system controls" - "AIMS governance model" - "AI control objectives" - "ISO 42001 control testing" - "AI governance operating model" - "AI risk controls" - "AI lifecycle controls" - "model governance" - "data governance" - "human oversight controls" - "transparency controls" - "post deployment monitoring" - "internal audit ISO 42001" - "GLOBAL compliance" - "ISO/IEC 42001" - "AI governance" - "Controls" - "Operating model" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 42001 Controls and Governance Model (Annex A + Operating Routines) Turn ISO/IEC 42001 into an AI governance operating model: Annex A control objectives and controls, Annex B implementation guidance. *Governance* *GLOBAL* ## ISO 42001 Controls and Governance Model A practical governance model to operationalize Annex A controls with accountable owners and evidence. Use this to turn ISO/IEC 42001 into routines: approvals, control tests, monitoring, internal audit, and continual improvement. ISO/IEC 42001 combines management-system requirements with Annex A reference control objectives and controls, Annex B implementation guidance, Annex C example organizational objectives and risk sources, and Annex D sector and domain usage context. A workable governance model turns that structure into owners, decision rights, tests, evidence, and review cadence. ## Start with role-aware governance, not a generic AI committee The standard expects the organization to determine its role with respect to each AI system and then allocate responsibilities and authorities accordingly. Governance depth should change depending on whether the organization develops, provides, integrates, procures, or uses the system. Annex B emphasizes that accountability should cover impact assessment, supplier relationships, data quality management, and human oversight where relevant. - Define a governing body or equivalent decision forum with authority over approvals, restrictions, and corrective actions - Assign named roles for system owner, risk owner, oversight owner, supplier owner, and documentation owner - Provide a route to report concerns about the organization role with respect to AI systems through the life cycle ## Build the control library from Annex A, then use Annex B to make it real Annex A is not a marketing checklist. It includes concrete control areas for AI policy, roles, resources, impact assessment, AI system life cycle, data, information for interested parties, use of AI systems, and third-party relationships. Risk treatment under clause 6 must compare selected controls with Annex A to confirm that no necessary controls were omitted. Additional controls can be required beyond Annex A, and exclusions should be justified. - Policy and accountability: A.2 and A.3 - Impact governance: A.5.2 through A.5.5 - Life-cycle controls: A.6.2.6 operation and monitoring, A.6.2.7 technical documentation, A.6.2.8 event logs - Interested-party information: A.8.2 through A.8.5 - Third-party allocation: A.10.2 and A.10.3 ## Operating routines that keep the AIMS credible over time Annex B gives the practical detail most teams miss. Operation and monitoring should cover system and performance monitoring, repairs, updates, support, drift signals, incident handling, and communication to users when changes affect system behavior or intended use. The governance model should therefore be expressed as recurring routines, not static documents. - Planned intervals for impact reassessment and management review - Release criteria with verification, validation, performance thresholds, and management sign-off before deployment - Observability and event-log retention for in-use systems - Update, rollback, and incident-communication procedures tied to accountable owners - Supplier review cadence for third-party models, datasets, services, and cloud dependencies *Recommended next step* *Placement: after the main workflow section* ## Turn ISO 42001 Controls and Governance Model into an operational assessment Assessment Autopilot can take ISO 42001 Controls and Governance Model from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on ISO 42001 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 42001 Controls and Governance Model](/solutions/assessment.md): Start from ISO 42001 Controls and Governance Model and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 42001](/contact.md): Review your current process, evidence gaps, and next steps for ISO 42001 Controls and Governance Model. ## Primary sources - [ISO/IEC 42001:2023 - ISO standard page](https://www.iso.org/standard/81230.html?ref=sorena.io) - Primary reference for ISO 42001 management-system structure and annexes. - [Regulation (EU) 2024/1689 - Artificial Intelligence Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Useful for mapping governance evidence to regulatory obligations. ## Related Topic Guides - [ISO 42001 Compliance (AI Management System Playbook)](/artifacts/global/iso-42001/compliance.md): A practical ISO/IEC 42001 compliance playbook to implement an AI Management System (AIMS): scope, AI policy, roles and responsibilities. - [ISO 42001 FAQ (AIMS, Risk Assessment, Impact Assessment, Audit)](/artifacts/global/iso-42001/faq.md): ISO/IEC 42001 FAQ for AI Management System (AIMS) implementation: what the standard covers, clause structure, Annex A controls. - [ISO 42001 Requirements (Clause-by-Clause Breakdown + Evidence)](/artifacts/global/iso-42001/requirements.md): An advanced ISO/IEC 42001 requirements breakdown: clauses 4-10 (context, leadership, planning, support, operation, performance evaluation, improvement). - [ISO 42001 vs EU AI Act (Mapping + Evidence Reuse)](/artifacts/global/iso-42001/iso-42001-vs-eu-ai-act.md): A practical ISO/IEC 42001 vs EU AI Act mapping: how an AI Management System (AIMS) supports AI Act obligations (risk management, data governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-42001/controls-and-governance-model --- --- title: "ISO 42001 FAQ (AIMS, Risk Assessment, Impact Assessment, Audit)" canonical_url: "https://www.sorena.io/artifacts/global/iso-42001/faq" source_url: "https://www.sorena.io/artifacts/global/iso-42001/faq" author: "Sorena AI" description: "ISO/IEC 42001 FAQ for AI Management System (AIMS) implementation: what the standard covers, clause structure, Annex A controls." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 42001 FAQ" - "ISO/IEC 42001 questions" - "AI management system FAQ" - "AIMS FAQ" - "ISO 42001 certification FAQ" - "ISO 42001 audit FAQ" - "ISO 42001 scope definition" - "Annex A controls ISO 42001" - "AI risk assessment ISO 42001" - "AI risk treatment ISO 42001" - "AI system impact assessment ISO 42001" - "documented information ISO 42001" - "internal audit ISO 42001" - "ISO 42001 vs EU AI Act" - "GLOBAL compliance" - "ISO/IEC 42001" - "AIMS" - "AI governance" - "FAQ" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 42001 FAQ (AIMS, Risk Assessment, Impact Assessment, Audit) ISO/IEC 42001 FAQ for AI Management System (AIMS) implementation: what the standard covers, clause structure, Annex A controls. *FAQ* *GLOBAL* ## ISO 42001 FAQ Quick answers to real ISO/IEC 42001 AIMS implementation questions. Focused on scope, governance, AI risk and impact assessment, controls, evidence, and audit readiness. This FAQ answers the questions that matter when ISO/IEC 42001 moves from concept to implementation: who the standard applies to, what the AI system impact assessment really requires, how Annex A and Annex B should be used, what evidence auditors look for, and where ISO 42001 stops and the EU AI Act starts. ## Who is ISO/IEC 42001 actually for? ISO 42001 is intended for organizations that provide or use products or services that utilize AI systems. The standard is written for organizations that develop, provide, or use AI systems responsibly in pursuing their objectives. That means it is broader than only model developers. It can apply to providers, customers or users, partners, integrators, and data providers, depending on the organization role with respect to the AI system. - Use role determination early because it influences which controls and evidence matter most - Do not scope only engineering if business units or suppliers materially shape AI outcomes - Keep the scope and the role decisions as documented information ## What does the AI system impact assessment have to cover? The standard requires the impact assessment to determine the potential consequences that deployment, intended use, and foreseeable misuse can have on individuals, groups of individuals, and societies. It must account for the technical and societal context of deployment and applicable jurisdictions. The results must be documented and fed back into risk assessment. - Assess impacts on individuals and groups across the system life cycle - Assess societal impacts where relevant - Repeat the assessment at planned intervals or when significant changes are proposed - Add discipline-specific impact work for safety, privacy, or security critical contexts when needed ## How should Annex A and Annex B be used together? Annex A gives reference control objectives and controls. Annex B gives the implementation guidance that turns those controls into practical routines. The two should be used together during risk treatment and operational design. A good implementation selects relevant Annex A controls, justifies exclusions, adds extra controls where needed, and uses Annex B to define owners, procedures, documentation, and monitoring. - Annex A is not exhaustive, so additional controls can be necessary - Annex B explains how to operationalize policy, roles, impacts, monitoring, technical documentation, and supplier controls - Annex C helps define objectives and risk sources, while Annex D helps adapt the AIMS across sectors ## What evidence do auditors usually expect for ISO 42001? Auditors usually look for whether the AIMS operates as a system: scope and role clarity, interested-party requirements, policy and responsibilities, risk and impact work, operational controls, monitoring, internal audit, management review, and corrective action. The strongest evidence is traceable documented information that shows the management system is used in practice, not only declared. - Scope statement, AI system inventory, role determination, and interested-party register - AI policy, governance charter, assigned responsibilities, and concern-reporting route - Risk assessments, risk-treatment records, impact assessments, and justification for excluded controls - Technical documentation, event-log decisions, monitoring outputs, incident records, and supplier allocations - Internal audit outputs, management-review decisions, and corrective-action closure proof ## Does ISO 42001 make you compliant with the EU AI Act? No. ISO 42001 is a management system standard, while the EU AI Act is a regulation with role-specific and system-category-specific legal duties. ISO 42001 can provide the governance engine behind compliance, but it does not replace legal scoping or AI Act specific obligations. The efficient approach is to reuse ISO 42001 evidence for AI Act work where the underlying governance process overlaps, such as risk management, documentation control, monitoring, and supplier accountability. - ISO 42001 helps with governance and evidence discipline - The AI Act still requires provider or deployer scoping, category assessment, and legal obligation mapping - Design one evidence index so ISO audits and AI Act readiness use the same underlying artifacts *Recommended next step* *Placement: after the FAQ section* ## Use ISO 42001 FAQ as a cited research workflow Research Copilot can take ISO 42001 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on ISO 42001 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO 42001 FAQ](/solutions/research-copilot.md): Start from ISO 42001 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO 42001](/contact.md): Review your current process, evidence gaps, and next steps for ISO 42001 FAQ. ## Primary sources - [ISO/IEC 42001:2023 - ISO standard page](https://www.iso.org/standard/81230.html?ref=sorena.io) - Primary reference for ISO 42001 publication and scope. - [Regulation (EU) 2024/1689 - Artificial Intelligence Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal source for EU AI Act comparison questions. ## Related Topic Guides - [ISO 42001 Compliance (AI Management System Playbook)](/artifacts/global/iso-42001/compliance.md): A practical ISO/IEC 42001 compliance playbook to implement an AI Management System (AIMS): scope, AI policy, roles and responsibilities. - [ISO 42001 Controls and Governance Model (Annex A + Operating Routines)](/artifacts/global/iso-42001/controls-and-governance-model.md): Turn ISO/IEC 42001 into an AI governance operating model: Annex A control objectives and controls, Annex B implementation guidance. - [ISO 42001 Requirements (Clause-by-Clause Breakdown + Evidence)](/artifacts/global/iso-42001/requirements.md): An advanced ISO/IEC 42001 requirements breakdown: clauses 4-10 (context, leadership, planning, support, operation, performance evaluation, improvement). - [ISO 42001 vs EU AI Act (Mapping + Evidence Reuse)](/artifacts/global/iso-42001/iso-42001-vs-eu-ai-act.md): A practical ISO/IEC 42001 vs EU AI Act mapping: how an AI Management System (AIMS) supports AI Act obligations (risk management, data governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-42001/faq --- --- title: "ISO 42001 vs EU AI Act (Mapping + Evidence Reuse)" canonical_url: "https://www.sorena.io/artifacts/global/iso-42001/iso-42001-vs-eu-ai-act" source_url: "https://www.sorena.io/artifacts/global/iso-42001/iso-42001-vs-eu-ai-act" author: "Sorena AI" description: "A practical ISO/IEC 42001 vs EU AI Act mapping: how an AI Management System (AIMS) supports AI Act obligations (risk management, data governance." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 42001 vs EU AI Act" - "ISO/IEC 42001 vs AI Act" - "AI management system vs EU AI Act" - "AIMS EU AI Act mapping" - "EU AI Act compliance program ISO 42001" - "ISO 42001 mapping to EU AI Act requirements" - "AI Act risk management system" - "AI Act quality management system" - "AI Act technical documentation" - "AI Act data governance" - "AI Act transparency" - "AI Act human oversight" - "AI Act post market monitoring" - "ISO 42001 evidence reuse" - "GLOBAL compliance" - "ISO/IEC 42001" - "EU AI Act" - "AI governance" - "Mapping" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 42001 vs EU AI Act (Mapping + Evidence Reuse) A practical ISO/IEC 42001 vs EU AI Act mapping: how an AI Management System (AIMS) supports AI Act obligations (risk management, data governance. *Mapping* *GLOBAL* ## ISO 42001 ISO 42001 vs EU AI Act A practical mapping: how ISO/IEC 42001 supports EU AI Act obligations (and what it doesn't). Designed for teams building a regulation-ready AI governance program with reusable evidence. ISO/IEC 42001 is a management system standard for organizations that develop, provide, or use AI systems. The EU AI Act is a regulation with scope tests, role-based obligations, and system-category-specific duties. The practical question is not which one replaces the other. The practical question is how to use ISO 42001 to build a reusable governance and evidence layer that supports AI Act compliance without creating duplicate operating models. ## ISO 42001 and the EU AI Act solve different problems ISO 42001 tells an organization how to run an AI management system. It covers context, roles, interested parties, policy, risk and impact planning, operation, monitoring, audit, and continual improvement. The EU AI Act tells market actors what legal duties attach to specific roles and AI system categories. It is not a management system standard and it does not by itself tell organizations how to run the governance machinery behind those duties. - ISO 42001: operating model and evidence discipline - EU AI Act: legal scoping, role-specific duties, prohibited practices, and category-specific obligations - Best use together: ISO 42001 as the governance layer, AI Act as the legal obligation layer ## Where ISO 42001 directly strengthens AI Act readiness The strongest overlap is in governance mechanics. ISO 42001 requires role determination, interested-party analysis, AI policy, risk treatment, impact assessment, documented information, operation and monitoring, supplier accountability, and review cycles. Those are exactly the kinds of systems serious AI Act programs need. Annex A also includes practical control areas that align well with AI Act execution work, including technical documentation, event-log decisions, user information, incident communication, and supplier allocation. - Role and scope discipline supports provider or deployer analysis - Risk and impact processes support high-risk governance design - Technical documentation, monitoring, and event-log routines improve AI Act evidence quality - Supplier and partner responsibility allocation supports third-party AI component governance ## Evidence reuse model: one system, multiple obligations The efficient implementation pattern is to build one evidence index and map both standards and regulation into it. Evidence should be organized by AI system, role, risk category, required controls, required documentation, and review cadence. This prevents parallel ISO and AI Act workstreams that drift apart over time. - System inventory with intended purpose, role determination, and relevant interested parties - Risk assessments, treatment records, and AI system impact assessments - Technical documentation, monitoring outputs, change approvals, and event-log decisions - Incident communication plans, user information, and supplier responsibility allocations - Internal audit, management review, and corrective-action closure records ## What ISO 42001 does not replace under the EU AI Act ISO 42001 does not determine whether a use case is prohibited, high-risk, limited-risk, or outside scope. It does not replace role classification, conformity-assessment choices, or any other legal determination required by the EU AI Act. That means you should treat ISO 42001 as a strong governance foundation but still perform legal scoping against the regulation itself. - You still need AI Act role determination and category analysis - You still need AI Act specific legal review, timelines, and obligation mapping - You should not claim AI Act compliance from ISO 42001 certification alone *Recommended next step* *Placement: after the comparison section* ## Use ISO 42001 ISO 42001 vs EU AI Act as a cited research workflow Research Copilot can take ISO 42001 ISO 42001 vs EU AI Act from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on ISO 42001 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO 42001 ISO 42001 vs EU AI Act](/solutions/research-copilot.md): Start from ISO 42001 ISO 42001 vs EU AI Act and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO 42001](/contact.md): Review your current process, evidence gaps, and next steps for ISO 42001 ISO 42001 vs EU AI Act. ## Primary sources - [ISO/IEC 42001:2023 - ISO standard page](https://www.iso.org/standard/81230.html?ref=sorena.io) - Primary source for ISO 42001 publication and scope. - [Regulation (EU) 2024/1689 - Artificial Intelligence Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal source for EU AI Act obligations. - [European Commission - AI Act overview](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai?ref=sorena.io) - Implementation overview and policy context for the EU AI Act. ## Related Topic Guides - [ISO 42001 Compliance (AI Management System Playbook)](/artifacts/global/iso-42001/compliance.md): A practical ISO/IEC 42001 compliance playbook to implement an AI Management System (AIMS): scope, AI policy, roles and responsibilities. - [ISO 42001 Controls and Governance Model (Annex A + Operating Routines)](/artifacts/global/iso-42001/controls-and-governance-model.md): Turn ISO/IEC 42001 into an AI governance operating model: Annex A control objectives and controls, Annex B implementation guidance. - [ISO 42001 FAQ (AIMS, Risk Assessment, Impact Assessment, Audit)](/artifacts/global/iso-42001/faq.md): ISO/IEC 42001 FAQ for AI Management System (AIMS) implementation: what the standard covers, clause structure, Annex A controls. - [ISO 42001 Requirements (Clause-by-Clause Breakdown + Evidence)](/artifacts/global/iso-42001/requirements.md): An advanced ISO/IEC 42001 requirements breakdown: clauses 4-10 (context, leadership, planning, support, operation, performance evaluation, improvement). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-42001/iso-42001-vs-eu-ai-act --- --- title: "ISO 42001 Requirements (Clause-by-Clause Breakdown + Evidence)" canonical_url: "https://www.sorena.io/artifacts/global/iso-42001/requirements" source_url: "https://www.sorena.io/artifacts/global/iso-42001/requirements" author: "Sorena AI" description: "An advanced ISO/IEC 42001 requirements breakdown: clauses 4-10 (context, leadership, planning, support, operation, performance evaluation, improvement)." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO 42001 requirements" - "ISO/IEC 42001 requirements breakdown" - "ISO 42001 clauses 4-10" - "ISO 42001 context leadership planning support operation" - "ISO 42001 performance evaluation internal audit" - "ISO 42001 improvement corrective action" - "ISO 42001 Annex A controls" - "ISO 42001 Annex B guidance" - "AI management system requirements" - "AIMS requirements" - "ISO 42001 requirements checklist" - "ISO 42001 evidence mapping" - "ISO 42001 audit evidence" - "ISO 42001 certification requirements" - "GLOBAL compliance" - "ISO/IEC 42001" - "Requirements" - "AIMS" - "Audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO 42001 Requirements (Clause-by-Clause Breakdown + Evidence) An advanced ISO/IEC 42001 requirements breakdown: clauses 4-10 (context, leadership, planning, support, operation, performance evaluation, improvement). *Requirements* *GLOBAL* ## ISO 42001 Requirements Clause-by-clause ISO/IEC 42001 requirements breakdown with evidence mapping ideas. Use this to translate AIMS requirements into owners, controls, documented information, and audit-ready evidence. ISO/IEC 42001 follows the familiar ISO management-system structure in clauses 4 through 10, but it adds AI-specific planning and operational requirements and a deeper annex structure than many summaries mention. Clause work, Annex A controls, Annex B implementation guidance, Annex C example objectives and risk sources, and Annex D sector adaptation should be read together. ## How ISO 42001 is structured in practice Clauses 4 through 10 define the AIMS itself. Annex A gives reference control objectives and controls. Annex B gives implementation guidance for those controls. Annex C provides non-exclusive AI-related objectives and risk sources. Annex D explains how the AIMS can be used across domains or sectors. The implementation pattern is simple: build the management system first, then use Annex A and Annex B during risk treatment and operational design, and use Annex C and Annex D to improve applicability and completeness. - Clauses 4 to 10: mandatory management-system requirements - Annex A and Annex B: normative control layer and implementation guidance - Annex C and Annex D: informative support for objectives, risk sources, and sector use ## Clause 4 - Context, intended purpose, roles, and interested parties Clause 4 requires more than a scope paragraph. The organization shall consider the intended purpose of the AI systems it develops, provides, or uses and determine its roles with respect to those systems. It must also identify the interested parties relevant to the AIMS, their relevant requirements, and keep the AIMS scope available as documented information. - Evidence ideas: scope statement, intended-purpose register, role determination log, interested-party register - Practical effect: provider, user, integrator, data-provider, and supplier roles can change control depth and evidence needs ## Clause 5 - Leadership and AI policy Top management must establish the AI policy, align it with strategic direction, and assign responsibilities and authorities. The AI policy must be available as documented information and made available to interested parties as appropriate. Annex A and Annex B add two details many implementations miss: policy review at planned intervals and a process for reporting concerns about the organization role with respect to AI systems. - Evidence ideas: AI policy, policy review records, responsibility matrix, concern-reporting process - Operational point: role allocation should cover impact assessment, supplier relationships, and data quality management where relevant ## Clause 6 - Planning, risk treatment, and impact assessment Clause 6 includes AI risk assessment, AI risk treatment, AI system impact assessment, objectives, and planning of changes. The organization must retain documented information on actions taken to identify and address risks and opportunities. Risk treatment must compare chosen controls against Annex A to confirm that no necessary controls were omitted. Additional controls may be needed, and exclusions should be justified. - Evidence ideas: risk methodology, risk register, treatment plan, control-selection log, exclusion justifications - Impact assessments must consider technical and societal context, intended use, foreseeable misuse, and applicable jurisdictions - Impact-assessment results must be documented and considered in the risk assessment ## Clause 7 - Support and documented information control Clause 7 covers resources, competence, awareness, communication, and documented information. The extent of documented information can vary by organization, but the control discipline cannot be skipped. Documented information should be created, updated, controlled, and retained in a way that keeps evidence trustworthy and usable for audits and oversight. - Evidence ideas: competence records, communication plan, document-control procedure, retention and access rules - AI-specific point: resource documentation can inform impact assessments and risk understanding ## Clause 8 - Operation and the AI-specific control surface Clause 8 requires operational planning and control and retention of results for AI risk assessments, treatments, and impact assessments. It also requires impact assessments at planned intervals or when significant changes are proposed to occur. Annex A identifies the AI-specific operational surface most teams need to implement explicitly: operation and monitoring, technical documentation, event logs, information for users, incident communication, and supplier alignment. - Evidence ideas: operational procedures, monitoring plan, technical-documentation pack, event-log decision record, supplier-allocation records - Important control areas: A.6.2.6, A.6.2.7, A.6.2.8, A.8.2 through A.8.5, and A.10.2 through A.10.3 ## Clauses 9 and 10 - Evaluation, corrective action, and continual improvement Clause 9 requires monitoring, measurement, analysis, evaluation, internal audit, and management review. Clause 10 requires nonconformity handling, corrective action, and continual improvement. This is where the AIMS proves it is a living system. Monitoring results, interested-party changes, audit findings, and management-review outputs should feed back into policy, controls, and system operation. - Evidence ideas: monitoring and measurement plan, audit plan and reports, management-review minutes, corrective-action log - Practical metric set: corrective-action closure time, repeat findings, drift-triggered reassessments, and monitoring exception trends *Recommended next step* *Placement: after the requirement breakdown* ## Turn ISO 42001 Requirements into an operational assessment Assessment Autopilot can take ISO 42001 Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on ISO 42001 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for ISO 42001 Requirements](/solutions/assessment.md): Start from ISO 42001 Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through ISO 42001](/contact.md): Review your current process, evidence gaps, and next steps for ISO 42001 Requirements. ## Primary sources - [ISO/IEC 42001:2023 - ISO standard page](https://www.iso.org/standard/81230.html?ref=sorena.io) - Primary reference for ISO 42001 publication information and scope. - [Regulation (EU) 2024/1689 - Artificial Intelligence Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Useful for aligning AIMS evidence with regulatory obligations where relevant. ## Related Topic Guides - [ISO 42001 Compliance (AI Management System Playbook)](/artifacts/global/iso-42001/compliance.md): A practical ISO/IEC 42001 compliance playbook to implement an AI Management System (AIMS): scope, AI policy, roles and responsibilities. - [ISO 42001 Controls and Governance Model (Annex A + Operating Routines)](/artifacts/global/iso-42001/controls-and-governance-model.md): Turn ISO/IEC 42001 into an AI governance operating model: Annex A control objectives and controls, Annex B implementation guidance. - [ISO 42001 FAQ (AIMS, Risk Assessment, Impact Assessment, Audit)](/artifacts/global/iso-42001/faq.md): ISO/IEC 42001 FAQ for AI Management System (AIMS) implementation: what the standard covers, clause structure, Annex A controls. - [ISO 42001 vs EU AI Act (Mapping + Evidence Reuse)](/artifacts/global/iso-42001/iso-42001-vs-eu-ai-act.md): A practical ISO/IEC 42001 vs EU AI Act mapping: how an AI Management System (AIMS) supports AI Act obligations (risk management, data governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-42001/requirements --- --- title: "Choose the Right ISO Standard (27001, 27005, 27017, 27018, 27035, 27036, 22301, 42001)" canonical_url: "https://www.sorena.io/artifacts/global/iso-standards-hub/choose-the-right-standard" source_url: "https://www.sorena.io/artifacts/global/iso-standards-hub/choose-the-right-standard" author: "Sorena AI" description: "A practical decision guide to choose the right ISO standard by objective: ISMS certification (ISO 27001), risk management (ISO 27005)." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "choose ISO standard" - "which ISO standard do I need" - "ISO standards decision guide" - "ISO 27001 vs 27005" - "ISO 27001 vs 22301" - "ISO 27017 vs 27018" - "ISO 27035 incident response standard" - "ISO 27036 supplier security standard" - "ISO 42001 AI management system standard" - "ISO cybersecurity standards" - "ISO standards for cloud security" - "ISO standards for AI governance" - "ISO certification standards" - "GLOBAL compliance" - "ISO standards" - "Decision guide" - "Audit evidence" - "Implementation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Choose the Right ISO Standard (27001, 27005, 27017, 27018, 27035, 27036, 22301, 42001) A practical decision guide to choose the right ISO standard by objective: ISMS certification (ISO 27001), risk management (ISO 27005). *Decision Guide* *GLOBAL* ## ISO Standards Hub Choose the Right Standard Pick the ISO standard that matches your objective and evidence needs. Fast guide for security, procurement, resilience, and AI governance teams. Most teams waste months implementing the wrong standard first or treating a guidance standard like a certification standard. Use this guide to start with the real objective: certification-ready governance, risk method, cloud controls, incident response, supplier assurance, business continuity, or AI governance. Then choose the standard or bundle that creates the most reusable structure and evidence. ## Start with the objective, then check whether you need a management system or guidance standard The fastest way to choose well is to separate management-system needs from deep-practice needs. If you need a certifiable governance backbone, start with a management-system standard such as ISO/IEC 27001, ISO 22301, or ISO/IEC 42001. If you already have that backbone and need depth in a specific domain, add the right guidance standard or multi-part series rather than forcing one standard to do everything. - Management-system backbone: ISO/IEC 27001 for security governance, ISO 22301 for continuity, ISO/IEC 42001 for AI governance - Domain depth: ISO/IEC 27005 for risk method, ISO/IEC 27017 and 27018 for cloud, ISO/IEC 27035 for incident management, ISO/IEC 27036 for supplier security - Decision rule: choose the standard that creates the evidence the next audit, customer review, or governance decision will actually require ## Use the current series reality, not the short marketing label Several standards in this hub are series, not single-document answers. ISO/IEC 27035 is currently grounded here as Part 1:2023, Part 2:2023, and Part 3:2020. ISO/IEC 27036 is grounded here as Part 1:2021, Part 2:2022, Part 3:2023, and Part 4:2016. Cloud and AI standards also need version awareness. The ISO listing now shows ISO/IEC 27018:2025 as the active edition, while much operational guidance in practice still maps closely to the 2019 control themes. ISO/IEC 42001 is the 2023 AI management-system standard. - Do not buy or implement a standard from memory - verify the edition and whether it is a multi-part series - Use the series when the risk problem spans process, operations, contracts, or cloud allocation - Document edition assumptions in your evidence pack when your operating model depends on them ## Recommended bundles that produce reusable evidence Bundles work best when each standard contributes a clear layer instead of overlapping blindly. The right bundle creates a single evidence index with shared owners, cadence, and review triggers. The most useful bundles are the ones that mirror how real audits and customer assurance requests land on the team. - SaaS and public cloud: ISO/IEC 27001 + ISO/IEC 27005 + ISO/IEC 27017 + ISO/IEC 27018 when you process PII in public cloud - Incident-driven environment: ISO/IEC 27001 + ISO/IEC 27035 to connect governance, incident logs, playbooks, and lessons learned - Supplier-heavy environment: ISO/IEC 27001 + ISO/IEC 27036 for tiering, contracts, indirect suppliers, and monitoring cadence - AI governance: ISO/IEC 42001 plus your security baseline and, where relevant, legal mapping such as the EU AI Act - Resilience-led environment: ISO/IEC 27001 + ISO 22301 when service continuity and recovery governance are core business requirements *Recommended next step* *Placement: near the end of the main content before related guides* ## Use ISO Standards Hub Choose the Right Standard as a cited research workflow Research Copilot can take ISO Standards Hub Choose the Right Standard from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on ISO Standards Hub can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO Standards Hub Choose the Right Standard](/solutions/research-copilot.md): Start from ISO Standards Hub Choose the Right Standard and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO Standards Hub](/contact.md): Review your current process, evidence gaps, and next steps for ISO Standards Hub Choose the Right Standard. ## Primary sources - [ISO - Standards catalogue](https://www.iso.org/standards.html?ref=sorena.io) - Browse official ISO standards, scope statements, and publication information. - [ISO/IEC 27001:2022 - ISO standard page](https://www.iso.org/standard/27001?ref=sorena.io) - ISMS requirements and certification context. - [ISO/IEC 27005:2022 - ISO standard page](https://www.iso.org/standard/80585.html?ref=sorena.io) - Information security risk management guidance. - [ISO/IEC 27017 - ISO standard page](https://www.iso.org/standard/82878.html?ref=sorena.io) - Cloud security controls. - [ISO/IEC 27018 - ISO standard page](https://www.iso.org/standard/76559.html?ref=sorena.io) - PII protection in public cloud acting as a PII processor. - [ISO/IEC 42001:2023 - ISO standard page](https://www.iso.org/standard/81230.html?ref=sorena.io) - AI management system requirements and annexes. ## Related Topic Guides - [ISO Standards Hub FAQ (27001, 27005, 27017, 27018, 27035, 27036, 22301, 42001)](/artifacts/global/iso-standards-hub/faq.md): FAQ for ISO standards selection and implementation: what certification means, which standard to start with. - [ISO Standards vs Regulations (How to Combine Both)](/artifacts/global/iso-standards-hub/iso-standards-vs-regulations.md): Standards vs regulations explained: what ISO standards do (governance + controls + evidence) vs what laws require (scope + obligations + enforcement). - [What's Included in the ISO Standards Hub (Coverage + Bundles)](/artifacts/global/iso-standards-hub/what-is-included.md): Coverage map of key ISO standards for cybersecurity, privacy, resilience, and AI governance: ISO 27001, ISO 27005, ISO 27017, ISO 27018, ISO 27035, ISO 27036. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-standards-hub/choose-the-right-standard --- --- title: "ISO Standards Hub FAQ (27001, 27005, 27017, 27018, 27035, 27036, 22301, 42001)" canonical_url: "https://www.sorena.io/artifacts/global/iso-standards-hub/faq" source_url: "https://www.sorena.io/artifacts/global/iso-standards-hub/faq" author: "Sorena AI" description: "FAQ for ISO standards selection and implementation: what certification means, which standard to start with." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO standards FAQ" - "ISO 27001 FAQ" - "ISO 27001 certification FAQ" - "ISO 27005 risk management FAQ" - "ISO 27017 cloud security FAQ" - "ISO 27018 PII public cloud FAQ" - "ISO 27035 incident response FAQ" - "ISO 27036 supplier security FAQ" - "ISO 22301 business continuity FAQ" - "ISO 42001 AI management system FAQ" - "ISO standards evidence" - "ISO audit evidence" - "GLOBAL compliance" - "ISO standards" - "FAQ" - "Audit evidence" - "Implementation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO Standards Hub FAQ (27001, 27005, 27017, 27018, 27035, 27036, 22301, 42001) FAQ for ISO standards selection and implementation: what certification means, which standard to start with. *FAQ* *GLOBAL* ## ISO Standards Hub FAQ Quick answers to common ISO standards and certification questions. Focused on selection, implementation, evidence, and audit readiness. Use this FAQ to answer the practical selection questions teams hit after the first web search: which standards are management-system anchors, which are guidance series, what certification actually means, how current editions matter, and how to keep one evidence pack across standards and regulations. ## Which ISO standards in this hub are usually the governance anchors? In this hub, the clearest governance anchors are ISO/IEC 27001 for security management, ISO 22301 for business continuity management, and ISO/IEC 42001 for AI management systems. Those are the standards you use when you need structured scope, policy, roles, audit, management review, and continual improvement. Standards like ISO/IEC 27005, 27017, 27018, 27035, and 27036 are then used to sharpen the operating model in specific risk areas. - Start with the anchor when you need a system that can be governed and audited over time - Add domain standards when you need deeper practice for cloud, incidents, suppliers, or AI-specific execution - Avoid implementing only a specialist standard when the real gap is governance discipline ## Why do current editions and multi-part series matter so much? Because the shorthand name often hides important differences. ISO/IEC 27035 and ISO/IEC 27036 are series, not single short checklists. ISO/IEC 27018 now has an active 2025 edition on the ISO listing, while many teams still reference the earlier 2019 control model. If you do not pin the edition or part number, teams can end up talking past each other about different requirements, controls, or operating assumptions. - Write edition and part numbers into policies, evidence indexes, and procurement references - Recheck whether a standard is current, withdrawn, or revised before major adoption decisions - Use the series when the risk problem spans planning, operations, supplier depth, or cloud responsibilities ## What does ISO certification mean and what does it not mean? Certification normally means an accredited certification body audited a defined management-system scope against a certifiable standard. It is evidence of management-system maturity within that scope at the time of audit. It does not automatically mean all products, suppliers, or legal obligations are covered. It also does not turn a guidance standard into a certification result by itself. - Always read the scope statement - Treat certification as one assurance layer, not as a universal compliance claim - Keep evidence current between audits or certification value degrades quickly ## How should we keep one evidence pack across several standards? Maintain a single evidence index that maps each standard requirement or control area to the artifacts, owners, cadence, and storage location that prove it. That is how you stop standards work from turning into parallel document stacks. The same index can usually support audits, customer due diligence, and regulation mapping if it is built with enough specificity. - Keep scope, inventory, ownership, risk, control-operation, audit, and corrective-action artifacts in one map - Use periodic refresh plus material-change triggers - Record which standard edition or series part each artifact supports when that matters ## How do ISO standards help with regulations without replacing them? Standards are voluntary operating models. Regulations are mandatory legal obligations. The leverage point is evidence reuse: use the ISO operating model to produce governance, risk, monitoring, supplier, and corrective-action artifacts that can also support regulation programs. That does not remove the need for legal scoping, deadlines, or role-specific regulatory analysis. - Use ISO 27001 to strengthen baseline security governance - Use ISO 42001 to strengthen AI governance and documentation discipline - Still validate scope, timing, and legal obligations against the primary regulation text *Recommended next step* *Placement: after the FAQ section* ## Use ISO Standards Hub FAQ as a cited research workflow Research Copilot can take ISO Standards Hub FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on ISO Standards Hub can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO Standards Hub FAQ](/solutions/research-copilot.md): Start from ISO Standards Hub FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO Standards Hub](/contact.md): Review your current process, evidence gaps, and next steps for ISO Standards Hub FAQ. ## Primary sources - [ISO - Standards catalogue](https://www.iso.org/standards.html?ref=sorena.io) - Official ISO standards catalogue and scope statements. - [ISO/IEC 27001:2022 - ISO standard page](https://www.iso.org/standard/27001?ref=sorena.io) - ISMS requirements and certification context. - [ISO/IEC 42001:2023 - ISO standard page](https://www.iso.org/standard/81230.html?ref=sorena.io) - AI management system requirements and annexes. - [Regulation (EU) 2016/679 - GDPR (official text)](https://eur-lex.europa.eu/eli/reg/2016/679/oj?ref=sorena.io) - Primary legal source for the GDPR. ## Related Topic Guides - [Choose the Right ISO Standard (27001, 27005, 27017, 27018, 27035, 27036, 22301, 42001)](/artifacts/global/iso-standards-hub/choose-the-right-standard.md): A practical decision guide to choose the right ISO standard by objective: ISMS certification (ISO 27001), risk management (ISO 27005). - [ISO Standards vs Regulations (How to Combine Both)](/artifacts/global/iso-standards-hub/iso-standards-vs-regulations.md): Standards vs regulations explained: what ISO standards do (governance + controls + evidence) vs what laws require (scope + obligations + enforcement). - [What's Included in the ISO Standards Hub (Coverage + Bundles)](/artifacts/global/iso-standards-hub/what-is-included.md): Coverage map of key ISO standards for cybersecurity, privacy, resilience, and AI governance: ISO 27001, ISO 27005, ISO 27017, ISO 27018, ISO 27035, ISO 27036. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-standards-hub/faq --- --- title: "ISO Standards vs Regulations (How to Combine Both)" canonical_url: "https://www.sorena.io/artifacts/global/iso-standards-hub/iso-standards-vs-regulations" source_url: "https://www.sorena.io/artifacts/global/iso-standards-hub/iso-standards-vs-regulations" author: "Sorena AI" description: "Standards vs regulations explained: what ISO standards do (governance + controls + evidence) vs what laws require (scope + obligations + enforcement)." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO standards vs regulations" - "ISO compliance vs legal compliance" - "ISO 27001 vs GDPR" - "ISO 27001 vs NIS2" - "ISO 27001 vs DORA" - "ISO 42001 vs EU AI Act" - "standards mapping to regulations" - "audit evidence reuse" - "compliance operating model" - "ISO certification vs regulatory compliance" - "GLOBAL compliance" - "ISO standards" - "Regulations" - "Evidence" - "Mapping" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ISO Standards vs Regulations (How to Combine Both) Standards vs regulations explained: what ISO standards do (governance + controls + evidence) vs what laws require (scope + obligations + enforcement). *Explainer* *GLOBAL* ## ISO Standards Hub ISO Standards vs Regulations Understand the difference and build a mapping strategy that produces reusable evidence. For security, compliance, risk, and product teams combining audits and legal obligations. ISO standards and regulations solve different problems. Regulations define legal obligations (with scope tests, enforcement, and penalties). ISO standards define best-practice management systems and controls (with owners, cadence, and audit-ready evidence). The fastest strategy is to use ISO standards as the operating system and attach regulation-specific obligations as mapped requirements and evidence artifacts. ## Standards vs regulations: what's the difference in practice? Regulations answer: "What must we do, in which cases, by when, and what happens if we don't?" Standards answer: "How do we run a repeatable system that keeps controls effective and evidence current?" - Regulations: mandatory, jurisdiction-bound, role-based obligations, enforcement and penalties - ISO standards: voluntary (often market-driven), audit-able operating models, controls and evidence cadence - Key risk: confusing certification with legal compliance (they are not the same) *Recommended next step* *Placement: after the comparison section* ## Use ISO Standards Hub ISO Standards vs Regulations as a cited research workflow Research Copilot can take ISO Standards Hub ISO Standards vs Regulations from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on ISO Standards Hub can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO Standards Hub ISO Standards vs Regulations](/solutions/research-copilot.md): Start from ISO Standards Hub ISO Standards vs Regulations and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO Standards Hub](/contact.md): Review your current process, evidence gaps, and next steps for ISO Standards Hub ISO Standards vs Regulations. ## How to combine both (a mapping workflow that actually scales) Treat the ISO management system as your baseline governance engine: scope, ownership, risk management, documented information, monitoring and internal audit, and continual improvement. Then map regulatory obligations into your control library and evidence index. This avoids duplicate documentation and ensures you can answer regulators and auditors with the same evidence pack. - Step 1: scope determination (regulation applicability + ISO scope statements) - Step 2: obligations mapping (regulation requirements -> controls -> evidence artifacts) - Step 3: evidence index (artifact -> owner -> cadence -> storage location) - Step 4: monitoring and change triggers (material change forces reassessment and evidence refresh) ## Evidence reuse: what you can usually reuse across audits and laws Reusable evidence is the leverage point. If you can prove governance, risk management, and control operation, you can usually answer a large portion of regulatory questions faster. The goal is one evidence index, not parallel stacks of "ISO docs" and "regulatory docs." - Governance: policies, roles, RACI, decision logs, exceptions register - Risk management: risk assessments, treatment plans, residual risk acceptance decisions - Operations: change management approvals, monitoring dashboards, incident handling records, test results - Assurance: internal audit plan and reports, management review outputs, corrective action closure proof - Third parties: supplier contracts, assurance evidence, monitoring cadence and enforcement records ## Where standards won't save you (avoid false confidence) Regulations can require specific controls, notifications, documentation formats, and role-specific obligations that a standard does not guarantee by itself. Use ISO standards as a strong foundation, but validate regulation scope and obligations with primary legal sources and counsel where necessary. - You still need regulation-specific scoping and role determination (e.g., provider vs deployer, essential vs important entities) - You still need regulation-specific notifications and timelines where applicable - You still need regulation-specific documentation and reporting where applicable ## Primary sources - [ISO - Standards catalogue](https://www.iso.org/standards.html?ref=sorena.io) - Official ISO standards catalogue and scope statements. - [ISO/IEC 27001:2022 - ISO standard page](https://www.iso.org/standard/27001?ref=sorena.io) - ISMS requirements and audit context. - [ISO/IEC 42001:2023 - ISO standard page](https://www.iso.org/standard/81230.html?ref=sorena.io) - AI management system requirements and annexes. - [Regulation (EU) 2016/679 - GDPR (official text)](https://eur-lex.europa.eu/eli/reg/2016/679/oj?ref=sorena.io) - Primary legal source for the GDPR. - [Directive (EU) 2022/2555 - NIS2 (official text)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj?ref=sorena.io) - Primary legal source for NIS2. - [Regulation (EU) 2022/2554 - DORA (official text)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj?ref=sorena.io) - Primary legal source for DORA. - [Regulation (EU) 2024/1689 - Artificial Intelligence Act (official text)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?ref=sorena.io) - Primary legal source for the EU AI Act. ## Related Topic Guides - [Choose the Right ISO Standard (27001, 27005, 27017, 27018, 27035, 27036, 22301, 42001)](/artifacts/global/iso-standards-hub/choose-the-right-standard.md): A practical decision guide to choose the right ISO standard by objective: ISMS certification (ISO 27001), risk management (ISO 27005). - [ISO Standards Hub FAQ (27001, 27005, 27017, 27018, 27035, 27036, 22301, 42001)](/artifacts/global/iso-standards-hub/faq.md): FAQ for ISO standards selection and implementation: what certification means, which standard to start with. - [What's Included in the ISO Standards Hub (Coverage + Bundles)](/artifacts/global/iso-standards-hub/what-is-included.md): Coverage map of key ISO standards for cybersecurity, privacy, resilience, and AI governance: ISO 27001, ISO 27005, ISO 27017, ISO 27018, ISO 27035, ISO 27036. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-standards-hub/iso-standards-vs-regulations --- --- title: "What's Included in the ISO Standards Hub (Coverage + Bundles)" canonical_url: "https://www.sorena.io/artifacts/global/iso-standards-hub/what-is-included" source_url: "https://www.sorena.io/artifacts/global/iso-standards-hub/what-is-included" author: "Sorena AI" description: "Coverage map of key ISO standards for cybersecurity, privacy, resilience, and AI governance: ISO 27001, ISO 27005, ISO 27017, ISO 27018, ISO 27035, ISO 27036." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "ISO standards hub what is included" - "ISO cybersecurity standards list" - "ISO 27001 27005 27017 27018 27035 27036 22301 42001" - "ISO standards coverage matrix" - "ISO standards bundle" - "ISO standards for cloud security" - "ISO standards for incident response" - "ISO standards for supplier risk" - "ISO standards for business continuity" - "ISO standards for AI governance" - "ISO certification evidence artifacts" - "GLOBAL compliance" - "ISO standards" - "Coverage" - "Audit evidence" - "Implementation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # What's Included in the ISO Standards Hub (Coverage + Bundles) Coverage map of key ISO standards for cybersecurity, privacy, resilience, and AI governance: ISO 27001, ISO 27005, ISO 27017, ISO 27018, ISO 27035, ISO 27036. *Coverage* *GLOBAL* ## ISO Standards Hub What Is Included A coverage map of ISO standards and what they help you implement. Use this to pick the right standard (and bundle) based on your objective and evidence needs. This hub covers the ISO standards that most often show up when teams need a certifiable governance backbone plus deeper operating guidance for risk, cloud, incidents, suppliers, continuity, and AI. The point is not to collect standards. The point is to choose the right combination, use the current editions, and maintain evidence that stays useful. ## Coverage map: what each standard in this hub is actually best at Each standard in the hub solves a different class of problem. Some define management systems. Others add specialist control depth or process detail that the management system alone does not provide. Use the standard for its strongest job instead of forcing a single standard to cover governance, cloud, incident management, supplier assurance, and AI all at once. - ISO/IEC 27001: ISMS governance, audit structure, and certification-oriented evidence - ISO/IEC 27005: information security risk method and treatment structure - ISO/IEC 27017 and ISO/IEC 27018: cloud control depth and public-cloud PII processor expectations - ISO/IEC 27035: incident management series covering process, preparation, and ICT response operations - ISO/IEC 27036: supplier relationship security series covering overview, requirements, ICT supply chain depth, and cloud guidance - ISO 22301: business continuity management system - ISO/IEC 42001: AI management system and AI governance ## Current-series notes that matter before you adopt This hub is grounded to the current or current-series state reflected in the underlying pages. That matters because several of these standards are evolving or multi-part. Examples already reflected in the repo include ISO/IEC 27018:2025 on the ISO listing, ISO/IEC 27035-1:2023 and 27035-2:2023 with 27035-3:2020, ISO/IEC 27036-1:2021 through 27036-4:2016, and ISO/IEC 42001:2023. - Check edition and series part before procurement, policy references, or customer commitments - Where an implementation model uses an earlier grounded edition, record that assumption clearly - Do not summarize a multi-part standard as if it were a single flat checklist ## Evidence artifacts that travel well across the bundle The standards become economical when their evidence is shared. One index can support security audits, supplier reviews, customer questionnaires, and regulation mapping if it is organized well. The most reusable artifacts are the ones that show governance, risk decisions, operating control, and review cadence rather than polished narrative only. - Scope statements, inventories, owners, and edition assumptions - Risk assessments, treatment decisions, and residual-risk acceptance - Operational evidence such as monitoring outputs, incident records, change approvals, and supplier assurance records - Internal audit outputs, management-review decisions, corrective-action closure proof - Third-party evidence such as contracts, clause deviations, and monitoring cadence records *Recommended next step* *Placement: after the scope or definition section* ## Use ISO Standards Hub What Is Included as a cited research workflow Research Copilot can take ISO Standards Hub What Is Included from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on ISO Standards Hub can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ISO Standards Hub What Is Included](/solutions/research-copilot.md): Start from ISO Standards Hub What Is Included and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ISO Standards Hub](/contact.md): Review your current process, evidence gaps, and next steps for ISO Standards Hub What Is Included. ## Primary sources - [ISO - Standards catalogue](https://www.iso.org/standards.html?ref=sorena.io) - Browse official ISO standards and scope statements. - [ISO/IEC 27001:2022 - ISO standard page](https://www.iso.org/standard/27001?ref=sorena.io) - ISMS requirements and certification context. - [ISO/IEC 27005:2022 - ISO standard page](https://www.iso.org/standard/80585.html?ref=sorena.io) - Information security risk management guidance. - [ISO/IEC 27017 - ISO standard page](https://www.iso.org/standard/82878.html?ref=sorena.io) - Cloud security controls and shared responsibility guidance. - [ISO/IEC 27018 - ISO standard page](https://www.iso.org/standard/76559.html?ref=sorena.io) - PII protection in public cloud acting as a PII processor. - [ISO/IEC 42001:2023 - ISO standard page](https://www.iso.org/standard/81230.html?ref=sorena.io) - AI management system requirements and annexes. ## Related Topic Guides - [Choose the Right ISO Standard (27001, 27005, 27017, 27018, 27035, 27036, 22301, 42001)](/artifacts/global/iso-standards-hub/choose-the-right-standard.md): A practical decision guide to choose the right ISO standard by objective: ISMS certification (ISO 27001), risk management (ISO 27005). - [ISO Standards Hub FAQ (27001, 27005, 27017, 27018, 27035, 27036, 22301, 42001)](/artifacts/global/iso-standards-hub/faq.md): FAQ for ISO standards selection and implementation: what certification means, which standard to start with. - [ISO Standards vs Regulations (How to Combine Both)](/artifacts/global/iso-standards-hub/iso-standards-vs-regulations.md): Standards vs regulations explained: what ISO standards do (governance + controls + evidence) vs what laws require (scope + obligations + enforcement). --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/iso-standards-hub/what-is-included --- --- title: "NIST CSF 2.0 Compliance Playbook (Profiles, Tiers, GOVERN)" canonical_url: "https://www.sorena.io/artifacts/global/nist-csf-2-0/compliance" source_url: "https://www.sorena.io/artifacts/global/nist-csf-2-0/compliance" author: "Sorena AI" description: "A practical NIST CSF 2.0 compliance playbook: establish GOVERN, implement CSF Core outcomes, build Current and Target Organizational Profiles." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST CSF 2.0 compliance" - "NIST CSF 2.0 implementation guide" - "Cybersecurity Framework 2.0 playbook" - "GOVERN function NIST CSF" - "CSF Organizational Profile" - "CSF current profile" - "CSF target profile" - "CSF tiers" - "Tier 1 Partial Tier 2 Risk Informed Tier 3 Repeatable Tier 4 Adaptive" - "cybersecurity risk governance" - "cybersecurity risk management" - "CSF Core functions categories subcategories" - "CSF 2.0 evidence artifacts" - "CSF 2.0 executive reporting" - "CSF 2.0 roadmap" - "GLOBAL compliance" - "NIST CSF 2.0" - "Cyber risk governance" - "Profiles" - "Tiers" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST CSF 2.0 Compliance Playbook (Profiles, Tiers, GOVERN) A practical NIST CSF 2.0 compliance playbook: establish GOVERN, implement CSF Core outcomes, build Current and Target Organizational Profiles. *Playbook* *GLOBAL* ## NIST CSF 2.0 Compliance A practical operating model for NIST CSF 2.0 implementation with profiles, tiers, and evidence. Designed for security, risk, audit, and leadership teams that need repeatable outcomes and board-readable metrics. NIST CSF 2.0 is an outcomes-based framework for managing cybersecurity risk. It does not prescribe exactly how to achieve outcomes. Instead, it gives organizations a common structure for understanding, assessing, prioritizing, and communicating cybersecurity risk using the CSF Core, Organizational Profiles, Tiers, and a growing online CSF portfolio of informative references, implementation examples, quick-start guides, and profile resources. ## Use CSF 2.0 the way NIST wrote it: outcomes first, controls second CSF 2.0 describes desirable outcomes, not a mandatory task list. The Core is organized as Functions, Categories, and Subcategories, and the outcomes are sector-, country-, and technology-neutral so each organization can tailor them to its mission and risk profile. That means CSF 2.0 works best when you pair it with your chosen control sources and practices instead of mistaking it for a prescriptive control catalog. - Use the Core to describe what good looks like - Use informative references and implementation examples to decide how to achieve the outcomes - Use one evidence index so the outcome view and the control view stay aligned ## Step 1 - Start with GOVERN because it sets the tone for all other Functions NIST puts GOVERN in the center of the CSF wheel because it informs how the other five Functions are implemented. GOVERN covers organizational context, risk management strategy, roles and authorities, policy, oversight, and cybersecurity supply chain risk management. The Core makes this more concrete through GOVERN categories such as GV.OC for organizational context, GV.RM for risk management strategy, and GV.SC for cybersecurity supply chain risk management. - Define mission, stakeholder expectations, legal and contractual requirements, and key dependencies - Establish risk objectives, risk appetite and tolerance, and enterprise-risk integration - Treat supplier and third-party governance as part of the core cyber program, not a side process ## Step 2 - Build a Current Profile with actual scope and evidence A Current Profile specifies the Core outcomes the organization is currently achieving or attempting to achieve and characterizes the extent to which each outcome is achieved. NIST expects scope assumptions to be documented up front because an organization can have multiple profiles for different purposes. A good Current Profile is evidence-based and scoped. It can cover the whole enterprise, a single business unit, a technology environment, or a threat-driven use case such as ransomware. - Document scope facts and assumptions before scoring outcomes - Select relevant outcomes and capture current-state evidence and implementation notes - Use the Current Profile to communicate capabilities and improvement opportunities internally and externally ## Step 3 - Define a Target Profile and use gap analysis to build the action plan A Target Profile captures the desired and prioritized outcomes the organization selects to meet its cybersecurity risk management objectives. It should reflect mission needs, stakeholder expectations, legal and regulatory drivers, technology changes, and threat trends. NISTs profile workflow explicitly calls for analyzing the gaps between the Current and Target Profiles and creating a prioritized action plan such as a risk register, risk detail report, or POA&M. - Use Community Profiles when they help accelerate or normalize a target state - Tie each priority outcome to planned work, owner, and due date - Refresh Target Profiles when requirements, technologies, or threat intelligence change ## Step 4 - Use Tiers to characterize rigor, not to perform false maturity theater CSF Tiers characterize the rigor of cybersecurity risk governance and management practices. They complement a risk methodology rather than replace it and are explicitly described by NIST as a notional illustration. The value of Tiers is strategic alignment: they help the organization communicate how formal, repeatable, and adaptive its practices need to be given its risk exposure and assurance demands. - Tier 1 Partial: ad hoc practices with limited awareness and weak supplier-risk consistency - Tier 2 Risk Informed: management-approved but not fully institutionalized practices - Tier 3 Repeatable: formalized policies and organization-wide, consistently implemented practices - Tier 4 Adaptive: continuous improvement, strong executive integration, and near real-time awareness ## Step 5 - Use the CSF portfolio and keep the program alive CSF 2.0 is part of a larger portfolio. NIST explicitly points users to informative references, implementation examples, quick-start guides, and profile resources that are updated online. Those resources are what make the framework operational. The program stays credible when outcomes, action plans, and evidence are reviewed continuously, especially as supplier dependencies, cloud environments, and AI systems change. - Map outcomes to references such as NIST SP 800-53, ISO 27001, or other internal control libraries - Use board and management reporting to show movement from Current to Target Profile - Treat profile updates, action-plan closure, and evidence refresh as a continuous cycle *Recommended next step* *Placement: after the compliance steps* ## Turn NIST CSF 2.0 Compliance into an operational assessment Assessment Autopilot can take NIST CSF 2.0 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on NIST CSF 2.0 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for NIST CSF 2.0 Compliance](/solutions/assessment.md): Start from NIST CSF 2.0 Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through NIST CSF 2.0](/contact.md): Review your current process, evidence gaps, and next steps for NIST CSF 2.0 Compliance. ## Primary sources - [NIST CSF 2.0 (CSWP 29) - DOI](https://doi.org/10.6028/NIST.CSWP.29?ref=sorena.io) - Primary source describing CSF 2.0 components: Core, Profiles, Tiers, and implementation approach. - [NIST CSF 2.0 - PDF (CSWP 29)](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf?ref=sorena.io) - Official CSF 2.0 document (February 26, 2024). - [NIST Cybersecurity Framework Resource Center](https://www.nist.gov/cyberframework?ref=sorena.io) - Quick Start Guides, profiles, informative references, and implementation examples. - [NIST CSF 2.0 - Resource & Overview Guide (SP 1299)](https://csrc.nist.gov/pubs/sp/1299/final?ref=sorena.io) - Companion guide for using CSF 2.0 resources and portfolio. ## Related Topic Guides - [NIST CSF 2.0 Current vs Target Profile Template (Step-by-Step)](/artifacts/global/nist-csf-2-0/current-vs-target-profile-template.md): How to build a NIST CSF 2.0 Current Profile and Target Profile: template columns, prioritization method, evidence mapping. - [NIST CSF 2.0 FAQ (Profiles, Tiers, GOVERN, Evidence)](/artifacts/global/nist-csf-2-0/faq.md): NIST CSF 2.0 FAQ: what changed in CSF 2.0 (GOVERN, supply chain focus), how to build Organizational Profiles, how to choose CSF Tiers. - [NIST CSF 2.0 Governance and Metrics (GOVERN + Board Reporting)](/artifacts/global/nist-csf-2-0/governance-and-metrics.md): How to operationalize the NIST CSF 2.0 GOVERN function: decision rights, risk acceptance, enterprise risk integration, supplier risk governance. - [NIST CSF 2.0 vs ISO 27001 (Mapping + How to Run Both)](/artifacts/global/nist-csf-2-0/nist-csf-vs-iso-27001.md): NIST CSF 2.0 vs ISO/IEC 27001 explained: outcomes framework vs certifiable management system. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-csf-2-0/compliance --- --- title: "NIST CSF 2.0 Current vs Target Profile Template (Step-by-Step)" canonical_url: "https://www.sorena.io/artifacts/global/nist-csf-2-0/current-vs-target-profile-template" source_url: "https://www.sorena.io/artifacts/global/nist-csf-2-0/current-vs-target-profile-template" author: "Sorena AI" description: "How to build a NIST CSF 2.0 Current Profile and Target Profile: template columns, prioritization method, evidence mapping." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST CSF 2.0 profile template" - "CSF current profile template" - "CSF target profile template" - "current vs target profile NIST CSF" - "CSF Organizational Profile" - "CSF profile worksheet" - "CSF profile step by step" - "CSF 2.0 roadmap" - "CSF outcomes mapping" - "CSF evidence mapping" - "informative references CSF 2.0" - "implementation examples CSF 2.0" - "GOVERN ownership CSF" - "GLOBAL compliance" - "NIST CSF 2.0" - "Organizational Profile" - "Roadmap" - "Evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST CSF 2.0 Current vs Target Profile Template (Step-by-Step) How to build a NIST CSF 2.0 Current Profile and Target Profile: template columns, prioritization method, evidence mapping. *Template* *GLOBAL* ## NIST CSF 2.0 Current vs Target Profile Template A practical worksheet structure for Current Profile, Target Profile, and gap-to-roadmap conversion. Evidence-first and governance-driven: every selected outcome has an owner, priority, and proof. NIST CSF 2.0 Organizational Profiles are the practical mechanism that turns the Core into a usable program. A Current Profile describes the cybersecurity outcomes the organization currently achieves or attempts to achieve. A Target Profile describes the prioritized outcomes the organization wants to achieve. NISTs own workflow then uses the gap between them to build and run the action plan. ## Profile basics: what NIST expects a profile to do Profiles are used to understand, tailor, assess, prioritize, and communicate the Core outcomes in light of mission objectives, stakeholder expectations, threat landscape, and requirements. They are not only internal spreadsheets for audit prep. NIST also points out that Community Profiles can be used as the basis for an organizations own Target Profile when a shared use case or sector baseline already exists. - Current Profile: what outcomes are achieved now and to what extent - Target Profile: the desired and prioritized outcomes for the next state - Community Profile: optional shared baseline that can accelerate target-setting ## Step 1 - Scope the profile before you score anything NISTs first step is to scope the Organizational Profile and document the high-level facts and assumptions on which it will be based. An organization can have as many profiles as needed, each with a different scope. Scoping prevents false precision. A ransomware-focused profile, a cloud-platform profile, and an enterprise-wide profile will not select or prioritize outcomes in the same way. - Record business unit, service, system, geography, and dependency boundaries - State major assumptions and external dependencies up front - Decide whether the profile is enterprise-wide, service-specific, supplier-specific, or threat-specific ## Recommended worksheet columns that keep the profile usable The profile should be detailed enough to drive action but light enough to stay current. A spreadsheet or GRC sheet can work well if each row is a Core outcome with traceable ownership and evidence. The most useful fields are the ones that help you move from outcome selection to action planning and status communication. - Function, Category, Subcategory ID, and outcome text - Scope tag, owner, current status, supporting evidence, and implementation notes - Target state, priority, rationale, mapped controls or references, and planned action - Evidence cadence, reviewer, due date, and update trigger ## Use NISTs five-step workflow to move from profile to roadmap The CSF 2.0 document outlines a practical sequence: scope the profile, gather needed inputs, create the profile, analyze the gaps, and implement the action plan while updating the profile over time. That sequence matters because it keeps the profile tied to live program work instead of turning it into a one-time assessment artifact. - Scope the Organizational Profile - Gather organizational priorities, resources, and risk direction - Create the Current and Target views with the necessary information - Analyze gaps and create a prioritized action plan - Implement the plan and update the profile continuously ## Profile outputs should support both internal and external communication NIST notes that a Current Profile can help communicate cybersecurity capabilities and improvement opportunities to business partners or prospective customers. A Target Profile can also express cybersecurity requirements and expectations to suppliers, partners, and other third parties. That makes profiles useful beyond internal governance. They can become a shared language for assurance, contracting, and roadmap alignment. - Use the Current Profile to explain actual capabilities and known gaps - Use the Target Profile to set supplier or partner expectations where appropriate - Connect the profile to the action register so every external statement can be backed by evidence and status *Recommended next step* *Placement: after the comparison section* ## Use NIST CSF 2.0 Current vs Target Profile Template as a cited research workflow Research Copilot can take NIST CSF 2.0 Current vs Target Profile Template from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on NIST CSF 2.0 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for NIST CSF 2.0 Current vs Target Profile Template](/solutions/research-copilot.md): Start from NIST CSF 2.0 Current vs Target Profile Template and answer scope, timing, and interpretation questions with cited outputs. - [Talk through NIST CSF 2.0](/contact.md): Review your current process, evidence gaps, and next steps for NIST CSF 2.0 Current vs Target Profile Template. ## Primary sources - [NIST CSF 2.0 (CSWP 29) - DOI](https://doi.org/10.6028/NIST.CSWP.29?ref=sorena.io) - Primary source for CSF Core, Organizational Profiles, and Tiers. - [NIST CSF 2.0 - Resource & Overview Guide (SP 1299)](https://csrc.nist.gov/pubs/sp/1299/final?ref=sorena.io) - Guidance for using CSF 2.0 resources like informative references and implementation examples. - [NIST CSF 2.0 - Organizational Profiles Quick Start Guide (SP 1301)](https://csrc.nist.gov/pubs/sp/1301/final?ref=sorena.io) - Practical guidance for building and using Organizational Profiles. - [NIST Cybersecurity Framework Resource Center](https://www.nist.gov/cyberframework?ref=sorena.io) - Profiles, templates, and supporting resources. ## Related Topic Guides - [NIST CSF 2.0 Compliance Playbook (Profiles, Tiers, GOVERN)](/artifacts/global/nist-csf-2-0/compliance.md): A practical NIST CSF 2.0 compliance playbook: establish GOVERN, implement CSF Core outcomes, build Current and Target Organizational Profiles. - [NIST CSF 2.0 FAQ (Profiles, Tiers, GOVERN, Evidence)](/artifacts/global/nist-csf-2-0/faq.md): NIST CSF 2.0 FAQ: what changed in CSF 2.0 (GOVERN, supply chain focus), how to build Organizational Profiles, how to choose CSF Tiers. - [NIST CSF 2.0 Governance and Metrics (GOVERN + Board Reporting)](/artifacts/global/nist-csf-2-0/governance-and-metrics.md): How to operationalize the NIST CSF 2.0 GOVERN function: decision rights, risk acceptance, enterprise risk integration, supplier risk governance. - [NIST CSF 2.0 vs ISO 27001 (Mapping + How to Run Both)](/artifacts/global/nist-csf-2-0/nist-csf-vs-iso-27001.md): NIST CSF 2.0 vs ISO/IEC 27001 explained: outcomes framework vs certifiable management system. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-csf-2-0/current-vs-target-profile-template --- --- title: "NIST CSF 2.0 FAQ (Profiles, Tiers, GOVERN, Evidence)" canonical_url: "https://www.sorena.io/artifacts/global/nist-csf-2-0/faq" source_url: "https://www.sorena.io/artifacts/global/nist-csf-2-0/faq" author: "Sorena AI" description: "NIST CSF 2.0 FAQ: what changed in CSF 2.0 (GOVERN, supply chain focus), how to build Organizational Profiles, how to choose CSF Tiers." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST CSF 2.0 FAQ" - "Cybersecurity Framework 2.0 FAQ" - "NIST CSF GOVERN function" - "CSF Organizational Profile FAQ" - "CSF current profile" - "CSF target profile" - "CSF tiers explained" - "Tier 1 Partial Tier 2 Risk Informed Tier 3 Repeatable Tier 4 Adaptive" - "CSF informative references" - "CSF implementation examples" - "CSF evidence artifacts" - "CSF 2.0 adoption questions" - "GLOBAL compliance" - "NIST CSF 2.0" - "FAQ" - "Profiles" - "Tiers" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST CSF 2.0 FAQ (Profiles, Tiers, GOVERN, Evidence) NIST CSF 2.0 FAQ: what changed in CSF 2.0 (GOVERN, supply chain focus), how to build Organizational Profiles, how to choose CSF Tiers. *FAQ* *GLOBAL* ## NIST CSF 2.0 FAQ Quick answers to real NIST CSF 2.0 implementation questions. Focused on GOVERN, Profiles, Tiers, evidence, and executive reporting. NIST CSF 2.0 is flexible enough to be misused. This FAQ focuses on the grounded questions that determine whether the framework becomes a useful operating model: what changed in 2.0, how GOVERN works, what Profiles and Tiers are really for, and how the online CSF portfolio fits into the implementation. ## What materially changed in NIST CSF 2.0? The biggest visible change is GOVERN. NIST also sharpened the frameworks emphasis on supply chains and built out the online CSF portfolio with informative references, implementation examples, quick-start guides, and profile resources. The framework is no longer framed around critical infrastructure only. CSF 2.0 is written for organizations of all sizes and sectors. - New central Function: GOVERN - Stronger supply-chain emphasis across the framework - Broader audience across industry, government, academia, and nonprofit ## Is CSF 2.0 a control catalog or maturity model? No. The CSF Core is a taxonomy of outcomes organized as Functions, Categories, and Subcategories. It does not prescribe how to achieve those outcomes and does not replace a control catalog. The Tiers are also not a full maturity model. NIST describes them as a way to characterize the rigor of risk governance and management practices. - Use the Core for outcomes and communication - Use control sources and local procedures for implementation detail - Use Tiers for governance context, not vanity scoring ## How should we use Profiles in practice? Use a Current Profile to document what outcomes are achieved now and a Target Profile to document what outcomes are prioritized for the next state. Then run gap analysis and put the results into an action plan. Profiles should be scoped and evidence-backed. NIST explicitly allows multiple profiles for different scopes and use cases. - Profile scope can be enterprise-wide, service-specific, or threat-specific - Community Profiles can help accelerate Target Profile design - Profiles become useful when linked to actions, owners, due dates, and evidence ## What are the Tiers really telling us? The Tiers tell you how rigorous and institutionalized the organizations governance and management practices are, from Tier 1 Partial through Tier 4 Adaptive. They help set expectations for how structured, repeatable, and responsive the program should be. Higher tiers usually imply stronger policy formalization, wider organizational consistency, better supplier-risk handling, and more continuous improvement. - Tier 1: ad hoc and limited visibility - Tier 2: risk-aware but not fully institutionalized - Tier 3: formalized and consistently implemented - Tier 4: adaptive and continuously improved ## What evidence makes a CSF 2.0 program credible? Keep the artifacts that prove how the organization moved from Current to Target Profile and how the resulting decisions are governed, monitored, and reviewed. Executives and auditors generally trust consistent decision and action records more than polished narrative alone. The strongest evidence set links profile rows, risk decisions, action-plan items, control mappings, and management reporting into one traceable chain. - Profile records, scope assumptions, and priority rationales - Risk and action-plan records such as POAMs, registers, or tracked remediation work - Monitoring outputs, decision logs, supplier-risk records, and closure evidence - Management and board reporting tied to profile movement and risk posture *Recommended next step* *Placement: after the FAQ section* ## Use NIST CSF 2.0 FAQ as a cited research workflow Research Copilot can take NIST CSF 2.0 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on NIST CSF 2.0 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for NIST CSF 2.0 FAQ](/solutions/research-copilot.md): Start from NIST CSF 2.0 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through NIST CSF 2.0](/contact.md): Review your current process, evidence gaps, and next steps for NIST CSF 2.0 FAQ. ## Primary sources - [NIST CSF 2.0 (CSWP 29) - DOI](https://doi.org/10.6028/NIST.CSWP.29?ref=sorena.io) - Primary source for CSF 2.0 components and intended use. - [NIST Cybersecurity Framework Resource Center](https://www.nist.gov/cyberframework?ref=sorena.io) - Supplemental CSF resources: informative references, implementation examples, profiles, and QSGs. - [NIST CSF 2.0 - Resource & Overview Guide (SP 1299)](https://csrc.nist.gov/pubs/sp/1299/final?ref=sorena.io) - Companion guide for CSF 2.0 resources and implementation. ## Related Topic Guides - [NIST CSF 2.0 Compliance Playbook (Profiles, Tiers, GOVERN)](/artifacts/global/nist-csf-2-0/compliance.md): A practical NIST CSF 2.0 compliance playbook: establish GOVERN, implement CSF Core outcomes, build Current and Target Organizational Profiles. - [NIST CSF 2.0 Current vs Target Profile Template (Step-by-Step)](/artifacts/global/nist-csf-2-0/current-vs-target-profile-template.md): How to build a NIST CSF 2.0 Current Profile and Target Profile: template columns, prioritization method, evidence mapping. - [NIST CSF 2.0 Governance and Metrics (GOVERN + Board Reporting)](/artifacts/global/nist-csf-2-0/governance-and-metrics.md): How to operationalize the NIST CSF 2.0 GOVERN function: decision rights, risk acceptance, enterprise risk integration, supplier risk governance. - [NIST CSF 2.0 vs ISO 27001 (Mapping + How to Run Both)](/artifacts/global/nist-csf-2-0/nist-csf-vs-iso-27001.md): NIST CSF 2.0 vs ISO/IEC 27001 explained: outcomes framework vs certifiable management system. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-csf-2-0/faq --- --- title: "NIST CSF 2.0 Governance and Metrics (GOVERN + Board Reporting)" canonical_url: "https://www.sorena.io/artifacts/global/nist-csf-2-0/governance-and-metrics" source_url: "https://www.sorena.io/artifacts/global/nist-csf-2-0/governance-and-metrics" author: "Sorena AI" description: "How to operationalize the NIST CSF 2.0 GOVERN function: decision rights, risk acceptance, enterprise risk integration, supplier risk governance." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST CSF 2.0 governance" - "NIST CSF GOVERN function" - "cybersecurity risk governance" - "cybersecurity metrics board reporting" - "CSF tiers governance" - "enterprise risk management cybersecurity" - "cyber risk KPI model" - "executive cyber metrics" - "supplier risk governance CSF 2.0" - "CSF profile reporting" - "CSF evidence artifacts" - "GLOBAL compliance" - "NIST CSF 2.0" - "GOVERN" - "Metrics" - "Board reporting" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST CSF 2.0 Governance and Metrics (GOVERN + Board Reporting) How to operationalize the NIST CSF 2.0 GOVERN function: decision rights, risk acceptance, enterprise risk integration, supplier risk governance. *Governance* *GLOBAL* ## NIST CSF 2.0 Governance and Metrics A practical model for GOVERN decision rights and board-readable cybersecurity metrics. Tie governance to Profiles and Tiers so reporting reflects real outcomes and evidence, not vanity metrics. CSF 2.0 places GOVERN at the center because cyber risk management should be driven by strategy, stakeholder expectations, policy, oversight, and supply-chain-aware decision making. This page focuses on the parts of GOVERN that create visible governance: context, risk strategy, communication lines, supply chain risk, and reporting that executives can use. ## What GOVERN actually covers in the Core GOVERN is not one abstract leadership statement. The Core breaks it into categories such as Organizational Context, Risk Management Strategy, Roles Responsibilities and Authorities, Policy, Oversight, and Cybersecurity Supply Chain Risk Management. Those categories are what make board reporting and executive decisions defensible because they connect context, policy, risk appetite, communication, and oversight. - GV.OC: mission, stakeholder expectations, requirements, and dependencies - GV.RM: risk objectives, appetite, tolerance, and enterprise-risk integration - GV.SC: supplier roles, due diligence, contracts, monitoring, incident inclusion, and exit planning ## Governance model: decisions, communication, and escalation NIST describes CSF use as a communication model across executives, managers, and practitioners. Executives set priorities and expectations, managers translate them into target-state plans, and practitioners implement and measure the work. A strong governance model therefore needs clear decision rights, line-of-communication rules, and escalation points rather than only a monthly metrics pack. - Document who sets risk direction, who accepts residual risk, and who approves exceptions - Tie management forums to Target Profile priorities and action-plan closure - Make supplier and third-party risks visible in the same governance structure, not outside it ## Metrics that fit how CSF 2.0 is designed The most useful metrics show whether the organization is moving from its Current Profile to its Target Profile and whether its chosen Tier is supported by real governance and management behavior. They should make sense to executives, managers, and practitioners. Metrics should cover outcome progress, governance behavior, supply-chain exposure, and response capability rather than only operational volume. - Profile progress by Function and by highest-priority outcomes - Residual-risk acceptance volume, age, and expiry trends - Supplier due-diligence completion, contract-risk coverage, and evidence refresh compliance - Incident and recovery metrics tied to profile outcomes and management decisions - Corrective-action closure rate and recurrence of previously accepted risks ## Evidence that executives and auditors can both trust NISTs model works best when governance evidence is tied to profile movement, risk communication, and action plans. This allows leaders to see what is improving and auditors to see how decisions were justified. Use one evidence index rather than separate program decks and audit folders. - Profile snapshots, decision logs, and documented scope assumptions - Risk strategy, appetite statements, and enterprise-risk integration records - Supplier-tiering, due-diligence, contract, and monitoring records - Action-plan status, metrics sources, and closure proof for corrective work *Recommended next step* *Placement: near the end of the main content before related guides* ## Use NIST CSF 2.0 Governance and Metrics as a cited research workflow Research Copilot can take NIST CSF 2.0 Governance and Metrics from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on NIST CSF 2.0 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for NIST CSF 2.0 Governance and Metrics](/solutions/research-copilot.md): Start from NIST CSF 2.0 Governance and Metrics and answer scope, timing, and interpretation questions with cited outputs. - [Talk through NIST CSF 2.0](/contact.md): Review your current process, evidence gaps, and next steps for NIST CSF 2.0 Governance and Metrics. ## Primary sources - [NIST CSF 2.0 (CSWP 29) - DOI](https://doi.org/10.6028/NIST.CSWP.29?ref=sorena.io) - Primary source for CSF 2.0 components and governance emphasis. - [NIST Cybersecurity Framework Resource Center](https://www.nist.gov/cyberframework?ref=sorena.io) - Supplemental resources, informative references, and implementation examples. ## Related Topic Guides - [NIST CSF 2.0 Compliance Playbook (Profiles, Tiers, GOVERN)](/artifacts/global/nist-csf-2-0/compliance.md): A practical NIST CSF 2.0 compliance playbook: establish GOVERN, implement CSF Core outcomes, build Current and Target Organizational Profiles. - [NIST CSF 2.0 Current vs Target Profile Template (Step-by-Step)](/artifacts/global/nist-csf-2-0/current-vs-target-profile-template.md): How to build a NIST CSF 2.0 Current Profile and Target Profile: template columns, prioritization method, evidence mapping. - [NIST CSF 2.0 FAQ (Profiles, Tiers, GOVERN, Evidence)](/artifacts/global/nist-csf-2-0/faq.md): NIST CSF 2.0 FAQ: what changed in CSF 2.0 (GOVERN, supply chain focus), how to build Organizational Profiles, how to choose CSF Tiers. - [NIST CSF 2.0 vs ISO 27001 (Mapping + How to Run Both)](/artifacts/global/nist-csf-2-0/nist-csf-vs-iso-27001.md): NIST CSF 2.0 vs ISO/IEC 27001 explained: outcomes framework vs certifiable management system. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-csf-2-0/governance-and-metrics --- --- title: "NIST CSF 2.0 vs ISO 27001 (Mapping + How to Run Both)" canonical_url: "https://www.sorena.io/artifacts/global/nist-csf-2-0/nist-csf-vs-iso-27001" source_url: "https://www.sorena.io/artifacts/global/nist-csf-2-0/nist-csf-vs-iso-27001" author: "Sorena AI" description: "NIST CSF 2.0 vs ISO/IEC 27001 explained: outcomes framework vs certifiable management system." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST CSF 2.0 vs ISO 27001" - "NIST CSF vs ISO 27001 mapping" - "CSF outcomes vs ISO controls" - "ISO 27001 certification vs NIST CSF" - "CSF GOVERN function vs ISO governance" - "CSF profile vs ISO ISMS scope" - "evidence reuse ISO 27001 and NIST CSF" - "CSF to ISO 27001 crosswalk" - "cybersecurity framework mapping" - "GLOBAL compliance" - "NIST CSF 2.0" - "ISO 27001" - "Mapping" - "Audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST CSF 2.0 vs ISO 27001 (Mapping + How to Run Both) NIST CSF 2.0 vs ISO/IEC 27001 explained: outcomes framework vs certifiable management system. *Comparison* *GLOBAL* ## NIST CSF 2.0 NIST CSF vs ISO 27001 Outcomes framework vs certifiable ISMS - and how to run both without duplicate work. Designed for teams that need executive reporting (CSF) and audit-ready certification evidence (ISO 27001). NIST CSF 2.0 and ISO/IEC 27001 solve adjacent problems. CSF 2.0 gives a flexible outcomes taxonomy, Profiles, and Tiers for cybersecurity risk communication and prioritization. ISO 27001 gives a certifiable information security management system with explicit requirements for scope, documented information, internal audit, and management review. The most effective approach is to run one program with two views. ## The difference in one line: outcomes framework versus certifiable management system CSF 2.0 tells you what cybersecurity outcomes to manage and communicate. ISO 27001 tells you how to run a certifiable management system around information security. They overlap in purpose but not in format. That difference is why CSF is excellent for board-readable posture and roadmap work, while ISO 27001 is excellent for formal governance and certification evidence. - CSF 2.0: Functions, Categories, Subcategories, Profiles, Tiers, and online references - ISO 27001: ISMS requirements, Statement of Applicability logic, internal audit, and continual improvement - Combined use: shared governance and shared evidence, different reporting lenses *Recommended next step* *Placement: after the comparison section* ## Use NIST CSF 2.0 NIST CSF vs ISO 27001 as a cited research workflow Research Copilot can take NIST CSF 2.0 NIST CSF vs ISO 27001 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on NIST CSF 2.0 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for NIST CSF 2.0 NIST CSF vs ISO 27001](/solutions/research-copilot.md): Start from NIST CSF 2.0 NIST CSF vs ISO 27001 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through NIST CSF 2.0](/contact.md): Review your current process, evidence gaps, and next steps for NIST CSF 2.0 NIST CSF vs ISO 27001. ## How to connect a CSF Current or Target Profile to an ISO 27001 program Use the profile as the outcome and prioritization layer, then map each relevant CSF Subcategory to your ISO 27001 control environment, procedures, and evidence. This turns CSF into a reporting and prioritization layer on top of the ISMS. That mapping keeps the flexible CSF view anchored to the more formal ISO governance and audit engine. - Align scope once and reuse it in both the Profile and the ISMS - Map selected Subcategories to controls, procedures, and evidence sources - Use Target Profile gaps to drive ISO-aligned work items and improvement actions ## Governance alignment: GOVERN and ISO clauses 4 through 10 GOVERN makes cyber risk governance explicit in CSF 2.0. ISO 27001 distributes governance across context, leadership, planning, support, operation, evaluation, and improvement. The operating model can still be unified. The simplest pattern is one set of decision rights, one risk register, one exception process, one corrective-action workflow, and one management-review cadence. - Use CSF for posture communication and target-state prioritization - Use ISO 27001 for formal management-system evidence and certification readiness - Keep one risk, exception, audit, and corrective-action record set for both ## What evidence should be shared across both? The best shared evidence is the set that proves governance, scope, risk decisions, control operation, and improvement over time. That is the common language both models need. Avoid separate CSF and ISO document stacks. They diverge quickly and create audit friction. - Scope, inventories, owners, and dependency records - Risk assessments, treatment decisions, and residual-risk acceptance - Operational records such as monitoring, testing, incident handling, and supplier assurance - Internal audit, management review, roadmap status, and corrective-action closure ## Primary sources - [NIST CSF 2.0 (CSWP 29) - DOI](https://doi.org/10.6028/NIST.CSWP.29?ref=sorena.io) - Primary source for CSF 2.0: Core, Profiles, and Tiers. - [NIST Cybersecurity Framework Resource Center](https://www.nist.gov/cyberframework?ref=sorena.io) - CSF 2.0 resources such as informative references and implementation examples. - [ISO/IEC 27001:2022 - ISO standard page](https://www.iso.org/standard/27001?ref=sorena.io) - ISMS requirements and certification context. ## Related Topic Guides - [NIST CSF 2.0 Compliance Playbook (Profiles, Tiers, GOVERN)](/artifacts/global/nist-csf-2-0/compliance.md): A practical NIST CSF 2.0 compliance playbook: establish GOVERN, implement CSF Core outcomes, build Current and Target Organizational Profiles. - [NIST CSF 2.0 Current vs Target Profile Template (Step-by-Step)](/artifacts/global/nist-csf-2-0/current-vs-target-profile-template.md): How to build a NIST CSF 2.0 Current Profile and Target Profile: template columns, prioritization method, evidence mapping. - [NIST CSF 2.0 FAQ (Profiles, Tiers, GOVERN, Evidence)](/artifacts/global/nist-csf-2-0/faq.md): NIST CSF 2.0 FAQ: what changed in CSF 2.0 (GOVERN, supply chain focus), how to build Organizational Profiles, how to choose CSF Tiers. - [NIST CSF 2.0 Governance and Metrics (GOVERN + Board Reporting)](/artifacts/global/nist-csf-2-0/governance-and-metrics.md): How to operationalize the NIST CSF 2.0 GOVERN function: decision rights, risk acceptance, enterprise risk integration, supplier risk governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-csf-2-0/nist-csf-vs-iso-27001 --- --- title: "Choose the Right NIST Standard (CSF, RMF, 800-53, 800-61r3, 800-161r1, SSDF)" canonical_url: "https://www.sorena.io/artifacts/global/nist-frameworks-hub/choose-the-right-nist-standard" source_url: "https://www.sorena.io/artifacts/global/nist-frameworks-hub/choose-the-right-nist-standard" author: "Sorena AI" description: "Decision guide to choose the right NIST framework or publication by objective: governance and communication (CSF), control baseline depth (SP 800-53)." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "choose NIST standard" - "which NIST framework should I use" - "NIST CSF vs SP 800-53" - "NIST SP 800-61 rev 3 incident response" - "NIST SP 800-161 rev 1 supply chain" - "NIST SP 800-218 SSDF" - "NIST RMF vs CSF" - "NIST frameworks decision guide" - "NIST cybersecurity standards" - "GLOBAL compliance" - "NIST frameworks" - "Decision guide" - "SP 800" - "Implementation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Choose the Right NIST Standard (CSF, RMF, 800-53, 800-61r3, 800-161r1, SSDF) Decision guide to choose the right NIST framework or publication by objective: governance and communication (CSF), control baseline depth (SP 800-53). *Decision Guide* *GLOBAL* ## NIST Frameworks Hub Choose the Right NIST Standard Pick the NIST framework/publication that matches your objective and assurance needs. Avoid fragmented programs by sequencing frameworks intentionally. NIST has both frameworks and focused publications, and they do different jobs. The fastest route is to choose the artifact that matches the immediate decision you need to make: communicate and prioritize cyber risk, run a system lifecycle and authorization process, deepen the control baseline, modernize incident response, strengthen supply-chain governance, or improve software security practices. ## Framework first or publication first: the real choice CSF 2.0 is the best entry point when you need a common outcomes language, Current and Target Profiles, and executive reporting. RMF is the right lens when system lifecycle, authorization, and continuous monitoring decisions need a formal process context. Publication-first adoption is usually best only when a narrowly defined capability gap is urgent and well understood. - Start with CSF 2.0 for prioritization, communication, and governance across the enterprise - Use RMF when categorization, control selection, assessment, authorization, and monitoring form the main operating problem - Go publication-first when you need deep domain execution such as controls, incidents, supply chain, or software security ## Use the current NIST set, not shorthand labels Version awareness matters in NIST work too. The grounded set in this repo is CSF 2.0, SP 800-53 Rev. 5 Update 1, SP 800-61 Rev. 3, SP 800-161 Rev. 1 Update 1, and SP 800-218 SSDF v1.1. Calling something just 800-53 or SSDF is often not enough when policies, contracts, and evidence need to match a specific publication state. - Record publication version and update level in mappings and evidence indexes - Check whether you need framework guidance, assessment methods, or implementation examples before starting work - Treat CSF and RMF as structure layers and SP 800 publications as depth layers ## Decision guide by objective Once you know the operating objective, the sequence is usually straightforward. Pick the primary artifact that sets direction, then add the publication that supplies execution detail. This keeps the adoption model coherent and reduces duplicate documentation. - Need cyber risk communication and prioritization: start with CSF 2.0 - Need lifecycle risk governance and authorization context: use RMF with SP 800-53 support - Need control baseline depth and assessment rigor: use SP 800-53 Rev. 5 Update 1 - Need incident response redesign: use SP 800-61 Rev. 3 - Need supplier and third-party governance: use SP 800-161 Rev. 1 Update 1 - Need secure development and release discipline: use SP 800-218 SSDF v1.1 *Recommended next step* *Placement: near the end of the main content before related guides* ## Use NIST Frameworks Hub Choose the Right NIST Standard as a cited research workflow Research Copilot can take NIST Frameworks Hub Choose the Right NIST Standard from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on NIST Frameworks Hub can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for NIST Frameworks Hub Choose the Right NIST Standard](/solutions/research-copilot.md): Start from NIST Frameworks Hub Choose the Right NIST Standard and answer scope, timing, and interpretation questions with cited outputs. - [Talk through NIST Frameworks Hub](/contact.md): Review your current process, evidence gaps, and next steps for NIST Frameworks Hub Choose the Right NIST Standard. ## Primary sources - [NIST CSF Resource Center](https://www.nist.gov/cyberframework?ref=sorena.io) - CSF 2.0 overview and implementation resources. - [NIST CSRC Publications](https://csrc.nist.gov/publications?ref=sorena.io) - Primary NIST publication catalog. - [NIST SP 800-53 Rev. 5 (Update 1)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final?ref=sorena.io) - Control baseline and assessment details. - [NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final?ref=sorena.io) - Incident response lifecycle guidance. - [NIST SP 800-161 Rev. 1](https://csrc.nist.gov/pubs/sp/800/161/r1/final?ref=sorena.io) - Cyber supply-chain risk management practices. - [NIST SP 800-218 (SSDF)](https://csrc.nist.gov/pubs/sp/800/218/final?ref=sorena.io) - Secure software development practices. ## Related Topic Guides - [NIST Frameworks Hub FAQ (CSF, SP 800, RMF, NIST vs ISO)](/artifacts/global/nist-frameworks-hub/faq.md): FAQ for choosing and implementing NIST frameworks: CSF 2.0, SP 800 publications, RMF context, control mappings, evidence cadence. - [NIST vs ISO (Framework Mapping, Governance, and Evidence Reuse)](/artifacts/global/nist-frameworks-hub/nist-vs-iso.md): NIST vs ISO explained for practical implementation: outcomes-driven NIST frameworks vs certifiable ISO management systems. - [What Is Included in the NIST Frameworks Hub (CSF, RMF, SP 800)](/artifacts/global/nist-frameworks-hub/what-is-included.md): Coverage map for key NIST frameworks and publications: NIST CSF 2.0, RMF, SP 800-53, SP 800-61r3, SP 800-161r1, SP 800-218 SSDF. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-frameworks-hub/choose-the-right-nist-standard --- --- title: "NIST Frameworks Hub FAQ (CSF, SP 800, RMF, NIST vs ISO)" canonical_url: "https://www.sorena.io/artifacts/global/nist-frameworks-hub/faq" source_url: "https://www.sorena.io/artifacts/global/nist-frameworks-hub/faq" author: "Sorena AI" description: "FAQ for choosing and implementing NIST frameworks: CSF 2.0, SP 800 publications, RMF context, control mappings, evidence cadence." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST frameworks FAQ" - "NIST CSF 2.0 FAQ" - "SP 800-53 FAQ" - "SP 800-61 FAQ" - "SP 800-161 FAQ" - "SP 800-218 SSDF FAQ" - "NIST RMF FAQ" - "NIST vs ISO FAQ" - "NIST compliance evidence FAQ" - "GLOBAL compliance" - "NIST frameworks" - "FAQ" - "SP 800" - "Implementation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST Frameworks Hub FAQ (CSF, SP 800, RMF, NIST vs ISO) FAQ for choosing and implementing NIST frameworks: CSF 2.0, SP 800 publications, RMF context, control mappings, evidence cadence. *FAQ* *GLOBAL* ## NIST Frameworks Hub FAQ Quick answers to common NIST framework and implementation questions. Focused on practical adoption, control mapping, and evidence quality. This FAQ focuses on the selection and sequencing decisions that matter in real NIST programs: when to start with CSF instead of a publication, where RMF fits, how to distinguish control depth from governance structure, and how to keep one evidence model across the NIST stack. ## Should we start with CSF 2.0, RMF, or a specific SP 800 publication? Start with CSF 2.0 when you need a shared risk language, prioritization model, and executive reporting mechanism. Start with RMF when your main problem is governing the lifecycle of systems through categorization, control selection, assessment, authorization, and monitoring. Start with a specific publication when the capability gap is already clear, such as incident response, software development security, or supplier governance. - CSF 2.0: outcome communication and enterprise prioritization - RMF: system lifecycle risk governance and authorization context - SP 800 publications: focused implementation depth in a specific domain ## How do the main publications in this hub differ? SP 800-53 provides a broad control baseline and control-family structure. SP 800-61 Rev. 3 modernizes incident response around CSF 2.0 concepts. SP 800-161 Rev. 1 Update 1 provides cybersecurity supply chain risk management depth. SP 800-218 SSDF v1.1 focuses on secure software development practices. These publications do not compete with each other. They address different layers of the operating model. - SP 800-53: controls and assessment depth - SP 800-61r3: incident lifecycle and coordination model - SP 800-161r1 upd1: C-SCRM governance, contracts, and monitoring - SP 800-218 SSDF v1.1: secure software development and release discipline ## Does NIST give us certification the way ISO does? Not in the same way. NIST frameworks and publications are widely used for design, mapping, and assurance, but they are generally not certification standards like ISO 27001. A common pattern is to use NIST for operating depth and ISO for certifiable management-system structure where certification matters. - NIST is usually the execution and control-depth layer - ISO is often the certifiable governance layer - Shared evidence is the bridge that makes both workable together ## What evidence should every NIST program keep regardless of path? The universal evidence set is the one that proves governance decisions, scoped implementation, control operation, and continuous improvement. It should be attributable, current, and linked to the chosen NIST artifact. The biggest failure mode is evidence drift across separate teams and publications. - Scope and ownership records - Risk and decision records - Operational records such as tests, monitoring, incident data, supplier reviews, and release evidence - Assurance records such as findings, POAMs, and corrective-action closure *Recommended next step* *Placement: after the FAQ section* ## Use NIST Frameworks Hub FAQ as a cited research workflow Research Copilot can take NIST Frameworks Hub FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on NIST Frameworks Hub can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for NIST Frameworks Hub FAQ](/solutions/research-copilot.md): Start from NIST Frameworks Hub FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through NIST Frameworks Hub](/contact.md): Review your current process, evidence gaps, and next steps for NIST Frameworks Hub FAQ. ## Primary sources - [NIST Cybersecurity Framework Resource Center](https://www.nist.gov/cyberframework?ref=sorena.io) - Primary CSF 2.0 resource center. - [NIST CSRC Publications](https://csrc.nist.gov/publications?ref=sorena.io) - Primary catalog for NIST cybersecurity publications. - [NIST SP 800-218 (SSDF)](https://csrc.nist.gov/pubs/sp/800/218/final?ref=sorena.io) - Secure software development framework publication. - [NIST SP 800-161 Rev. 1](https://csrc.nist.gov/pubs/sp/800/161/r1/final?ref=sorena.io) - Cybersecurity supply chain risk management guidance. ## Related Topic Guides - [Choose the Right NIST Standard (CSF, RMF, 800-53, 800-61r3, 800-161r1, SSDF)](/artifacts/global/nist-frameworks-hub/choose-the-right-nist-standard.md): Decision guide to choose the right NIST framework or publication by objective: governance and communication (CSF), control baseline depth (SP 800-53). - [NIST vs ISO (Framework Mapping, Governance, and Evidence Reuse)](/artifacts/global/nist-frameworks-hub/nist-vs-iso.md): NIST vs ISO explained for practical implementation: outcomes-driven NIST frameworks vs certifiable ISO management systems. - [What Is Included in the NIST Frameworks Hub (CSF, RMF, SP 800)](/artifacts/global/nist-frameworks-hub/what-is-included.md): Coverage map for key NIST frameworks and publications: NIST CSF 2.0, RMF, SP 800-53, SP 800-61r3, SP 800-161r1, SP 800-218 SSDF. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-frameworks-hub/faq --- --- title: "NIST vs ISO (Framework Mapping, Governance, and Evidence Reuse)" canonical_url: "https://www.sorena.io/artifacts/global/nist-frameworks-hub/nist-vs-iso" source_url: "https://www.sorena.io/artifacts/global/nist-frameworks-hub/nist-vs-iso" author: "Sorena AI" description: "NIST vs ISO explained for practical implementation: outcomes-driven NIST frameworks vs certifiable ISO management systems." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST vs ISO" - "NIST CSF vs ISO 27001" - "SP 800-53 vs ISO 27001 controls" - "NIST and ISO mapping" - "NIST framework vs ISO certification" - "cybersecurity framework comparison" - "evidence reuse NIST ISO" - "dual-framework governance model" - "GLOBAL compliance" - "NIST" - "ISO" - "Mapping" - "Evidence reuse" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST vs ISO (Framework Mapping, Governance, and Evidence Reuse) NIST vs ISO explained for practical implementation: outcomes-driven NIST frameworks vs certifiable ISO management systems. *Comparison* *GLOBAL* ## NIST Frameworks Hub NIST vs ISO How to run NIST and ISO together without duplicate governance and evidence. For teams balancing executive reporting, technical depth, and certification pressure. NIST and ISO are easiest to combine when each is used for what it does best. NIST frameworks and SP 800 publications give outcome models, implementation depth, and technical detail. ISO standards give formal management-system structure and, in some cases, certification pathways. Strong programs combine both without duplicating governance and evidence. ## Use NIST for depth and ISO for management-system discipline NIST gives multiple layers: CSF 2.0 for outcomes and communication, RMF for lifecycle risk governance, SP 800-53 for controls, SP 800-61r3 for response, SP 800-161 for supply chain, and SSDF for software development security. ISO gives the formal management-system and certification discipline many organizations need for external assurance. - NIST strength: operational detail and implementation depth - ISO strength: certifiable management-system structure and audit rhythm - Best combined: one operating model with multiple framework views ## Practical mapping pattern that scales Let CSF or RMF define the high-level posture and lifecycle view, let SP 800 publications define implementation expectations, and let ISO absorb the shared governance, audit, and improvement cadence where needed. This pattern keeps technical teams close to the NIST detail while giving leadership and auditors the management-system structure they expect. - Profiles, risk registers, and action plans can be shared across NIST and ISO layers - Control mappings can connect SP 800 depth to ISO control and audit requirements - Supplier, incident, software, and monitoring evidence should be collected once and reused ## Evidence reuse is the real operating advantage The real win is not theoretical mapping. It is keeping one evidence model that supports NIST posture reporting, technical assurance, and ISO audits at the same time. That means one scope model, one risk and exception process, one corrective-action workflow, and one evidence cadence. - Keep publication and standard version assumptions explicit - Link evidence to both outcome views and audit views - Use change-triggered refresh so evidence stays valid across frameworks *Recommended next step* *Placement: after the comparison section* ## Use NIST Frameworks Hub NIST vs ISO as a cited research workflow Research Copilot can take NIST Frameworks Hub NIST vs ISO from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on NIST Frameworks Hub can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for NIST Frameworks Hub NIST vs ISO](/solutions/research-copilot.md): Start from NIST Frameworks Hub NIST vs ISO and answer scope, timing, and interpretation questions with cited outputs. - [Talk through NIST Frameworks Hub](/contact.md): Review your current process, evidence gaps, and next steps for NIST Frameworks Hub NIST vs ISO. ## Primary sources - [NIST Cybersecurity Framework Resource Center](https://www.nist.gov/cyberframework?ref=sorena.io) - CSF 2.0 framework and implementation resources. - [NIST CSRC Publications](https://csrc.nist.gov/publications?ref=sorena.io) - SP 800 series publication catalog. - [ISO/IEC 27001:2022 - ISO standard page](https://www.iso.org/standard/27001?ref=sorena.io) - ISMS certification and governance requirements. - [ISO - Standards catalogue](https://www.iso.org/standards.html?ref=sorena.io) - Official ISO standards catalog. ## Related Topic Guides - [Choose the Right NIST Standard (CSF, RMF, 800-53, 800-61r3, 800-161r1, SSDF)](/artifacts/global/nist-frameworks-hub/choose-the-right-nist-standard.md): Decision guide to choose the right NIST framework or publication by objective: governance and communication (CSF), control baseline depth (SP 800-53). - [NIST Frameworks Hub FAQ (CSF, SP 800, RMF, NIST vs ISO)](/artifacts/global/nist-frameworks-hub/faq.md): FAQ for choosing and implementing NIST frameworks: CSF 2.0, SP 800 publications, RMF context, control mappings, evidence cadence. - [What Is Included in the NIST Frameworks Hub (CSF, RMF, SP 800)](/artifacts/global/nist-frameworks-hub/what-is-included.md): Coverage map for key NIST frameworks and publications: NIST CSF 2.0, RMF, SP 800-53, SP 800-61r3, SP 800-161r1, SP 800-218 SSDF. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-frameworks-hub/nist-vs-iso --- --- title: "What Is Included in the NIST Frameworks Hub (CSF, RMF, SP 800)" canonical_url: "https://www.sorena.io/artifacts/global/nist-frameworks-hub/what-is-included" source_url: "https://www.sorena.io/artifacts/global/nist-frameworks-hub/what-is-included" author: "Sorena AI" description: "Coverage map for key NIST frameworks and publications: NIST CSF 2.0, RMF, SP 800-53, SP 800-61r3, SP 800-161r1, SP 800-218 SSDF." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST frameworks what is included" - "NIST CSF 2.0 coverage" - "NIST RMF overview" - "NIST SP 800-53 rev 5" - "NIST SP 800-61 rev 3" - "NIST SP 800-161 rev 1" - "NIST SP 800-218 SSDF" - "NIST cybersecurity guidance map" - "NIST framework implementation bundle" - "GLOBAL compliance" - "NIST frameworks" - "SP 800 series" - "Coverage" - "Implementation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # What Is Included in the NIST Frameworks Hub (CSF, RMF, SP 800) Coverage map for key NIST frameworks and publications: NIST CSF 2.0, RMF, SP 800-53, SP 800-61r3, SP 800-161r1, SP 800-218 SSDF. *Coverage* *GLOBAL* ## NIST Frameworks Hub What Is Included Coverage map of NIST frameworks and publications by use case. Use this to pick the right NIST guidance and build an evidence-first implementation plan. This hub covers the NIST layers most organizations combine in practice: CSF 2.0 for outcomes and communication, RMF for system lifecycle and authorization context, SP 800-53 Rev. 5 Update 1 for controls, SP 800-61 Rev. 3 for incident response, SP 800-161 Rev. 1 Update 1 for supply-chain risk, and SP 800-218 SSDF v1.1 for secure software development. ## Coverage map: what each NIST artifact is best used for Start with the decision problem. Different NIST artifacts are optimized for different layers of governance and implementation. This is why a good NIST program usually uses a stack, not a single document. The hub focuses on the artifacts that are most reusable for enterprise cybersecurity programs and assurance work. - CSF 2.0: cybersecurity outcomes, profiles, tiers, and risk communication - RMF: categorize, select, implement, assess, authorize, and monitor context - SP 800-53 Rev. 5 Update 1: controls and assessment depth - SP 800-61 Rev. 3: incident response lifecycle - SP 800-161 Rev. 1 Update 1: cybersecurity supply chain risk management - SP 800-218 SSDF v1.1: secure software development practices ## Recommended NIST stack patterns Most programs benefit from a repeatable stack: one artifact for communication, one for depth, and one shared evidence model. The right stack depends on the immediate risk pressure and the type of program being built. Use the patterns below as practical defaults, then tailor by scope and assurance demands. - Enterprise governance stack: CSF 2.0 plus targeted SP 800 depth publications - System-centric stack: RMF plus SP 800-53 assessment and monitoring depth - Software stack: CSF 2.0 plus SSDF v1.1 and release evidence - Supplier stack: CSF 2.0 plus SP 800-161 contract, due-diligence, and monitoring depth - Operational resilience stack: CSF 2.0 plus SP 800-61r3 incident metrics and improvement loops ## Evidence that should travel across the whole stack NIST adoption becomes manageable when evidence is collected once and reused across the stack. The same evidence should support governance, technical assurance, and customer or audit questions. The essential discipline is explicit ownership, refresh cadence, and linkage to the specific NIST layer it supports. - Scope, inventories, owners, and publication-version assumptions - Risk records, profile gaps, action plans, and approvals - Control, incident, supplier, and software-development evidence - Assessment, monitoring, and corrective-action closure records *Recommended next step* *Placement: after the scope or definition section* ## Use NIST Frameworks Hub What Is Included as a cited research workflow Research Copilot can take NIST Frameworks Hub What Is Included from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on NIST Frameworks Hub can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for NIST Frameworks Hub What Is Included](/solutions/research-copilot.md): Start from NIST Frameworks Hub What Is Included and answer scope, timing, and interpretation questions with cited outputs. - [Talk through NIST Frameworks Hub](/contact.md): Review your current process, evidence gaps, and next steps for NIST Frameworks Hub What Is Included. ## Primary sources - [NIST Cybersecurity Framework Resource Center](https://www.nist.gov/cyberframework?ref=sorena.io) - Primary source for CSF 2.0 and supplemental resources. - [NIST CSRC Publications](https://csrc.nist.gov/publications?ref=sorena.io) - Catalog of SP 800 publications and cybersecurity guidance. - [NIST SP 800-53 Rev. 5 (Update 1)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final?ref=sorena.io) - Security and privacy controls baseline details. - [NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final?ref=sorena.io) - Incident response recommendations and lifecycle guidance. - [NIST SP 800-161 Rev. 1](https://csrc.nist.gov/pubs/sp/800/161/r1/final?ref=sorena.io) - Cybersecurity supply-chain risk management practices. - [NIST SP 800-218 (SSDF)](https://csrc.nist.gov/pubs/sp/800/218/final?ref=sorena.io) - Secure software development framework practices. ## Related Topic Guides - [Choose the Right NIST Standard (CSF, RMF, 800-53, 800-61r3, 800-161r1, SSDF)](/artifacts/global/nist-frameworks-hub/choose-the-right-nist-standard.md): Decision guide to choose the right NIST framework or publication by objective: governance and communication (CSF), control baseline depth (SP 800-53). - [NIST Frameworks Hub FAQ (CSF, SP 800, RMF, NIST vs ISO)](/artifacts/global/nist-frameworks-hub/faq.md): FAQ for choosing and implementing NIST frameworks: CSF 2.0, SP 800 publications, RMF context, control mappings, evidence cadence. - [NIST vs ISO (Framework Mapping, Governance, and Evidence Reuse)](/artifacts/global/nist-frameworks-hub/nist-vs-iso.md): NIST vs ISO explained for practical implementation: outcomes-driven NIST frameworks vs certifiable ISO management systems. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-frameworks-hub/what-is-included --- --- title: "NIST SP 800-161 Rev. 1 Compliance Playbook (C-SCRM)" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-161-rev-1/compliance" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-161-rev-1/compliance" author: "Sorena AI" description: "Practical SP 800-161 Rev. 1 compliance playbook: integrate C-SCRM with enterprise risk management, define strategy and implementation plan." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST SP 800-161 Rev. 1 compliance" - "NIST SP 800-161r1-upd1 implementation" - "C-SCRM program" - "cybersecurity supply chain risk management" - "supply chain cyber risk governance" - "C-SCRM strategy and implementation plan" - "C-SCRM policy template" - "supplier risk assessment NIST" - "acquisition C-SCRM controls" - "supply chain assurance evidence" - "GLOBAL compliance" - "NIST SP 800-161 Rev. 1" - "C-SCRM" - "Supply chain security" - "Audit evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-161 Rev. 1 Compliance Playbook (C-SCRM) Practical SP 800-161 Rev. 1 compliance playbook: integrate C-SCRM with enterprise risk management, define strategy and implementation plan. *Playbook* *GLOBAL* ## NIST SP 800-161 Rev. 1 Compliance A practical operating model for cybersecurity supply chain risk management (C-SCRM). Designed for security, procurement, legal, risk, and assurance teams running supplier-dependent environments. NIST SP 800-161 Rev. 1 Update 1 provides guidance for identifying, assessing, and mitigating cybersecurity risks throughout the supply chain at all levels of an organization. The publication applies the multilevel risk management model from SP 800-39, aligns operational activities with RMF concepts from SP 800-37 Rev. 2, and builds on a C-SCRM overlay of controls related to SP 800-53 Rev. 5. In practice, compliance means the organization can run C-SCRM as a coordinated enterprise capability rather than a set of isolated procurement checks. ## Use the NIST multilevel model, not a flat vendor review process SP 800-161 is explicit that C-SCRM requires involvement at three levels: enterprise, mission and business process, and operational. Each level produces different artifacts and makes different decisions, and the process is meant to work across all three with continuous improvement and communication. That is the biggest implementation shift many teams miss. Supplier risk is not only a procurement or system-owner activity. - Level 1 enterprise: strategy, implementation plan, policy, governance structure, and risk framing - Level 2 mission and business process: tailored strategies, implementation plans, policies, procedures, and reporting - Level 3 operational: C-SCRM plans, tailored controls, acquisition integration, and system-level monitoring ## Step 1 - Stand up the enterprise artifacts that set tone and boundaries The publication repeatedly points to four enterprise artifacts: the C-SCRM strategy, implementation plan, policy, and supporting governance structure. These establish how the organization frames risk, allocates authority, and coordinates action across functions. NIST also notes that effective implementations often use a shared-responsibility model and a multidisciplinary team or PMO rather than relying on one function alone. - Create the enterprise C-SCRM strategy, implementation plan, and policy as explicit documented artifacts - Define a governance council or working group charter with goals, authorities, responsibilities, and meeting cadence - Establish a C-SCRM PMO or equivalent coordination model where scale and complexity justify it - Set enterprise risk appetite, decision rights, and communication paths for supplier risk ## Step 2 - Tailor C-SCRM at mission and business process level NIST does not stop at enterprise policy. Level 2 is where the organization tailors enterprise direction to specific missions, business processes, and acquisition contexts. This is where many operational constraints, supplier priorities, and implementation plans need to be refined. The publication also notes that small and mid-sized businesses may not have the same degree of stakeholder separation, but the underlying responsibilities still need to be covered. - Develop mission and business process strategies, implementation plans, policies, and procedures - Tailor enterprise risk tolerances and constraints to the business context - Reduce vulnerabilities early in new IT projects and acquisitions instead of waiting for operational review - Report upward to enterprise governance and act on reporting from operational teams ## Step 3 - Build operational C-SCRM plans into acquisition and the SDLC Operational C-SCRM plans are meant to be informed by cybersecurity supply chain risk assessments and tailored to specific mission and business needs, operational environments, and implementing technologies. NIST also recommends integrating these processes into existing SDLCs and enterprise environments. This means supplier security needs to be part of design, acquisition, deployment, operation, and disposal activities, not just onboarding forms. - Use product and service risk assessments to tailor operational plans and controls - Integrate C-SCRM into acquisition, system engineering, change management, and disposal processes - Use RMF-aligned operational activities where they help control selection, assessment, authorization, and monitoring - Make plans specific enough to determine whether systems and services meet business, functional, and technical requirements ## Step 4 - Measure capability implementation and performance like NIST expects SP 800-161 emphasizes both capability implementation measurement and broader C-SCRM performance measures. The point is not only to count activity, but to determine whether the organization is actually reducing risk and improving trust in products, services, and suppliers. Performance measures should support enterprise review, mission decisions, and operational remediation. - Track how fully strategy, policy, plans, and controls are implemented across the three levels - Measure supplier coverage, criticality-based prioritization, monitoring completeness, and remediation speed - Use risk registers and action plans to connect findings to decisions and resources - Review metrics on a fixed cadence and after significant supply-chain changes or incidents *Recommended next step* *Placement: after the compliance steps* ## Turn NIST SP 800-161 Rev. 1 Compliance into an operational assessment Assessment Autopilot can take NIST SP 800-161 Rev. 1 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on NIST SP 800-161 Rev. 1 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for NIST SP 800-161 Rev. 1 Compliance](/solutions/assessment.md): Start from NIST SP 800-161 Rev. 1 Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through NIST SP 800-161 Rev. 1](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-161 Rev. 1 Compliance. ## Primary sources - [NIST SP 800-161 Rev. 1 (Updated) - DOI](https://doi.org/10.6028/NIST.SP.800-161r1-upd1?ref=sorena.io) - Primary source for C-SCRM practices, multilevel model, controls, metrics, and templates. - [NIST SP 800-161 Rev. 1 publication page](https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final?ref=sorena.io) - Official publication details and document access. - [NIST CSRC Publications](https://csrc.nist.gov/publications?ref=sorena.io) - Related NIST publications used for mapping and implementation depth. ## Related Topic Guides - [NIST SP 800-161 Rev. 1 Contract and Monitoring Controls](/artifacts/global/nist-sp-800-161-rev-1/contract-and-monitoring-controls.md): Practical contract and monitoring controls for C-SCRM under SP 800-161 Rev. - [NIST SP 800-161 Rev. 1 FAQ (C-SCRM Implementation)](/artifacts/global/nist-sp-800-161-rev-1/faq.md): NIST SP 800-161 Rev. 1 FAQ: scope, applicability outside federal environments, supplier risk tiering, acquisition and contract controls, C-SCRM metrics. - [NIST SP 800-161 Rev. 1 Supplier Risk Tiering Model](/artifacts/global/nist-sp-800-161-rev-1/supplier-risk-tiering.md): Build a risk-based supplier tiering model aligned to SP 800-161 Rev. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-161-rev-1/compliance --- --- title: "NIST SP 800-161 Rev. 1 Contract and Monitoring Controls" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-161-rev-1/contract-and-monitoring-controls" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-161-rev-1/contract-and-monitoring-controls" author: "Sorena AI" description: "Practical contract and monitoring controls for C-SCRM under SP 800-161 Rev." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST SP 800-161 contract controls" - "C-SCRM contract clauses" - "supplier cybersecurity contract requirements" - "continuous supplier monitoring" - "supplier assurance evidence" - "third-party monitoring controls" - "remediation enforcement clauses" - "supply chain cybersecurity agreements" - "GLOBAL compliance" - "NIST SP 800-161 Rev. 1" - "C-SCRM" - "Supplier contracts" - "Monitoring" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-161 Rev. 1 Contract and Monitoring Controls Practical contract and monitoring controls for C-SCRM under SP 800-161 Rev. *Controls* *GLOBAL* ## NIST SP 800-161 Rev. 1 Contract and Monitoring Controls Contractual and continuous monitoring controls for cybersecurity supply chain risk management. For procurement, security, legal, and supplier assurance teams that need enforceable outcomes. SP 800-161 treats contract controls and monitoring as part of a broader C-SCRM lifecycle that spans pre-award planning, acquisition, operations, and post-relationship activities. The publication explicitly calls out contract requirements, due diligence, continuous monitoring, and even activities after a partnership or service agreement ends. That means clause packs and monitoring dashboards need to be tied to a multilevel governance model, not handled as standalone vendor paperwork. ## Pre-award and contract controls should reflect criticality, not boilerplate NISTs model expects planning and due diligence before entering into formal supplier or third-party relationships. Contract requirements should therefore be driven by criticality, risk scenario, and the role the supplier plays in the life cycle of the product or service. This is especially important for developers, integrators, external service providers, and other parties that can introduce hidden dependencies or significant blast radius. - Use pre-award due diligence and criticality analysis before finalizing agreements - Translate risk findings into contract requirements, reporting duties, and acceptance conditions - Address subcontractors, fourth parties, and downstream service dependencies where relevant - Include transition and post-agreement requirements when service continuity or secure exit matters ## Monitoring controls should follow the full relationship, not only onboarding SP 800-161 stresses that supplier risks should be understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship. Monitoring therefore needs to cover both static control evidence and changing business context. The strongest programs treat monitoring as part of the same C-SCRM cycle used for enterprise risk decisions and operational planning. - Monitor supplier controls, evidence freshness, incidents, service changes, and dependency changes - Include relevant suppliers and third parties in incident planning, response, and recovery activities when exposure justifies it - Use life-cycle-aware monitoring for technology products and services, not only annual questionnaire refreshes - Escalate recurring or high-impact findings into formal risk and corrective-action channels ## Build the remediation and enforcement path before the first incident NISTs shared-responsibility and multidisciplinary team model means contract enforcement and monitoring outcomes should be governed jointly by security, procurement, legal, business owners, and operational teams. Without that alignment, monitoring becomes informational only. The enforcement path should therefore be documented as part of the C-SCRM operating model, not improvised during a supplier event. - Define who owns findings, who approves exceptions, and who can impose contractual remedies - Tie remediation deadlines to supplier tier, service criticality, and business impact - Use evidence and decision logs so escalation and enforcement remain auditable - Plan for restrictions, transition, or exit when risk cannot be reduced to an acceptable level *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep NIST SP 800-161 Rev. 1 Contract and Monitoring Controls in one governed evidence system SSOT can take NIST SP 800-161 Rev. 1 Contract and Monitoring Controls from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on NIST SP 800-161 Rev. 1 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for NIST SP 800-161 Rev. 1 Contract and Monitoring Controls](/solutions/ssot.md): Start from NIST SP 800-161 Rev. 1 Contract and Monitoring Controls and keep documents, evidence, and control records in one governed system. - [Talk through NIST SP 800-161 Rev. 1](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-161 Rev. 1 Contract and Monitoring Controls. ## Primary sources - [NIST SP 800-161 Rev. 1 (Updated) - DOI](https://doi.org/10.6028/NIST.SP.800-161r1-upd1?ref=sorena.io) - Primary source for C-SCRM controls and implementation practices. - [NIST SP 800-161 Rev. 1 publication page](https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final?ref=sorena.io) - Official publication metadata and access. - [NIST SP 800-53 Rev. 5 (Update 1)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final?ref=sorena.io) - Control families and references commonly mapped for supplier and system assurance. ## Related Topic Guides - [NIST SP 800-161 Rev. 1 Compliance Playbook (C-SCRM)](/artifacts/global/nist-sp-800-161-rev-1/compliance.md): Practical SP 800-161 Rev. 1 compliance playbook: integrate C-SCRM with enterprise risk management, define strategy and implementation plan. - [NIST SP 800-161 Rev. 1 FAQ (C-SCRM Implementation)](/artifacts/global/nist-sp-800-161-rev-1/faq.md): NIST SP 800-161 Rev. 1 FAQ: scope, applicability outside federal environments, supplier risk tiering, acquisition and contract controls, C-SCRM metrics. - [NIST SP 800-161 Rev. 1 Supplier Risk Tiering Model](/artifacts/global/nist-sp-800-161-rev-1/supplier-risk-tiering.md): Build a risk-based supplier tiering model aligned to SP 800-161 Rev. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-161-rev-1/contract-and-monitoring-controls --- --- title: "NIST SP 800-161 Rev. 1 FAQ (C-SCRM Implementation)" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-161-rev-1/faq" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-161-rev-1/faq" author: "Sorena AI" description: "NIST SP 800-161 Rev. 1 FAQ: scope, applicability outside federal environments, supplier risk tiering, acquisition and contract controls, C-SCRM metrics." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST SP 800-161 FAQ" - "NIST SP 800-161 Rev 1 FAQ" - "C-SCRM FAQ" - "cybersecurity supply chain risk management FAQ" - "SP 800-161 implementation questions" - "SP 800-161 compliance FAQ" - "supplier risk tiering NIST" - "NIST supply chain contract controls" - "C-SCRM audit evidence" - "NIST SP 800-161 explained" - "GLOBAL compliance" - "NIST SP 800-161 Rev. 1" - "C-SCRM" - "Supply chain security" - "FAQ" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-161 Rev. 1 FAQ (C-SCRM Implementation) NIST SP 800-161 Rev. 1 FAQ: scope, applicability outside federal environments, supplier risk tiering, acquisition and contract controls, C-SCRM metrics. *FAQ* *GLOBAL* ## NIST SP 800-161 Rev. 1 Frequently Asked Questions High-signal answers for teams implementing cybersecurity supply chain risk management. Focused on governance, acquisition, supplier assurance, monitoring, and measurable evidence. This FAQ focuses on the parts of SP 800-161 Rev. 1 Update 1 that most teams oversimplify: the update status, the three-level operating model, the role of the C-SCRM PMO and council structure, how C-SCRM relates to RMF and SP 800-53, and how to decide what evidence and measurement actually matter. ## What is the current publication state of SP 800-161 Rev. 1? The grounded publication in this repo is NIST SP 800-161 Rev. 1 Update 1. The base publication is dated May 2022, and the document includes updates as of November 1, 2024. The NIST Editorial Review Board approval date shown in the grounded file is September 25, 2024. That matters because implementation references and citations should point to the updated publication state, not only the earlier Rev. 1 label. - Record the update level in policies, mappings, and source notes - Avoid citing only 800-161 Rev. 1 when the implementation is based on the updated document - Keep version assumptions visible in the evidence index ## Is SP 800-161 only about procurement? No. The publication presents C-SCRM as a systematic process integrated into enterprise risk management, acquisition, and the full system development life cycle. Procurement is important, but the guidance spans strategy, policy, planning, engineering, operations, monitoring, and disposal. That is why the stakeholder model includes executive leadership, business management, architects, developers, contracting personnel, QA or QC, legal, HR, and others. - Procurement is one control point, not the entire program - C-SCRM should exist across enterprise, mission, and operational levels - Cross-functional participation is a core design assumption in the NIST model ## What is the role of the C-SCRM PMO or governance council? NIST describes governance patterns such as a working group or council of senior leaders and explicitly mentions forming a C-SCRM PMO. The purpose is coordination, shared responsibility, and sustained execution across otherwise separate functions. The PMO or council does not replace local responsibilities. It aligns them, sets cadence, and keeps risk communication flowing across levels. - Use a charter with goals, authorities, responsibilities, and meeting cadence - Represent security, procurement, legal, engineering, business, and operational stakeholders - Tie the forum to strategy, implementation plans, metrics, and corrective-action review ## How does SP 800-161 connect to SP 800-39, SP 800-37, and SP 800-53? SP 800-161 explicitly applies the multilevel risk management approach of SP 800-39, uses RMF linkages from SP 800-37 Rev. 2, and builds on an enhanced overlay of C-SCRM controls related to SP 800-53 Rev. 5. A practical implementation therefore uses SP 800-161 as the C-SCRM operating model, SP 800-39 as the enterprise-risk hierarchy, RMF where operational lifecycle alignment matters, and SP 800-53 for control depth. - Use SP 800-39 for the hierarchy and risk-integration logic - Use SP 800-37 when system-level lifecycle and authorization context matters - Use SP 800-53 as the control and overlay depth layer ## What proves that C-SCRM is actually working? Working C-SCRM is visible in three things: documented multilevel artifacts, measurable performance, and decisions that remain traceable from enterprise strategy down to supplier and system actions. If the organization cannot show how enterprise strategy changed mission or operational controls, the program is not working the way NIST intends. - Keep strategy, implementation plans, policy, operational plans, and supplier evidence linked - Measure coverage, criticality-based prioritization, remediation, and monitoring performance - Use risk registers, action plans, and review records to show continuous improvement *Recommended next step* *Placement: after the FAQ section* ## Use NIST SP 800-161 Rev. 1 Frequently Asked Questions as a cited research workflow Research Copilot can take NIST SP 800-161 Rev. 1 Frequently Asked Questions from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on NIST SP 800-161 Rev. 1 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for NIST SP 800-161 Rev. 1 Frequently Asked Questions](/solutions/research-copilot.md): Start from NIST SP 800-161 Rev. 1 Frequently Asked Questions and answer scope, timing, and interpretation questions with cited outputs. - [Talk through NIST SP 800-161 Rev. 1](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-161 Rev. 1 Frequently Asked Questions. ## Primary sources - [NIST SP 800-161 Rev. 1 (Updated) - DOI](https://doi.org/10.6028/NIST.SP.800-161r1-upd1?ref=sorena.io) - Primary source for C-SCRM model, practices, controls, metrics, and templates. - [NIST SP 800-161 Rev. 1 publication page](https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final?ref=sorena.io) - Official publication details and document access. - [NIST SP 800-53 Rev. 5 (Update 1)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final?ref=sorena.io) - Control catalog commonly mapped to C-SCRM implementation. - [NIST Cybersecurity Framework Resource Center](https://www.nist.gov/cyberframework?ref=sorena.io) - Framework resources for risk communication and profile-based governance. ## Related Topic Guides - [NIST SP 800-161 Rev. 1 Compliance Playbook (C-SCRM)](/artifacts/global/nist-sp-800-161-rev-1/compliance.md): Practical SP 800-161 Rev. 1 compliance playbook: integrate C-SCRM with enterprise risk management, define strategy and implementation plan. - [NIST SP 800-161 Rev. 1 Contract and Monitoring Controls](/artifacts/global/nist-sp-800-161-rev-1/contract-and-monitoring-controls.md): Practical contract and monitoring controls for C-SCRM under SP 800-161 Rev. - [NIST SP 800-161 Rev. 1 Supplier Risk Tiering Model](/artifacts/global/nist-sp-800-161-rev-1/supplier-risk-tiering.md): Build a risk-based supplier tiering model aligned to SP 800-161 Rev. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-161-rev-1/faq --- --- title: "NIST SP 800-161 Rev. 1 Supplier Risk Tiering Model" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-161-rev-1/supplier-risk-tiering" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-161-rev-1/supplier-risk-tiering" author: "Sorena AI" description: "Build a risk-based supplier tiering model aligned to SP 800-161 Rev." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST SP 800-161 supplier risk tiering" - "SP 800-161 vendor risk model" - "C-SCRM supplier risk assessment" - "cybersecurity supply chain tiering" - "supplier due diligence by risk tier" - "supplier monitoring cadence model" - "NIST third-party risk controls" - "SP 800-161 supplier assurance" - "risk-based contract controls for suppliers" - "GLOBAL compliance" - "NIST SP 800-161 Rev. 1" - "C-SCRM" - "Supplier risk tiering" - "Third-party risk" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-161 Rev. 1 Supplier Risk Tiering Model Build a risk-based supplier tiering model aligned to SP 800-161 Rev. *Tiering Guide* *GLOBAL* ## NIST SP 800-161 Rev. 1 Supplier Risk Tiering A risk-depth model for supplier due diligence, contract controls, and monitoring cadence. Use tiering to match assurance effort to business impact and supply chain attack exposure. Under SP 800-161 Rev. 1 Update 1, supplier risk tiering should be an outcome of criticality analysis, product and service risk assessment, dependency mapping, and mission or business impact - not a generic vendor classification exercise. Tiering only matters if it changes due diligence depth, contract requirements, monitoring, and escalation. ## Base tiers on criticality analysis and multilevel risk context The publication points organizations toward criticality analysis and multilevel risk integration. A supplier should be tiered based on how failure, compromise, substitution, or hidden dependency could affect enterprise objectives, mission and business processes, and operational systems. This means supplier size alone is almost never a useful tiering variable. - Use mission and business impact, dependency concentration, and control over alternatives - Include product and service exposure, privileged access, software and hardware dependencies, and subcontractor depth - Use the same risk language across enterprise, mission, and operational levels so tiers remain consistent *Recommended next step* *Placement: after the main workflow section* ## Turn NIST SP 800-161 Rev. 1 Supplier Risk Tiering into an operational assessment Assessment Autopilot can take NIST SP 800-161 Rev. 1 Supplier Risk Tiering from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on NIST SP 800-161 Rev. 1 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for NIST SP 800-161 Rev. 1 Supplier Risk Tiering](/solutions/assessment.md): Start from NIST SP 800-161 Rev. 1 Supplier Risk Tiering and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through NIST SP 800-161 Rev. 1](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-161 Rev. 1 Supplier Risk Tiering. ## Tiering should drive planning, contracts, and monitoring intensity SP 800-161 expects tailored C-SCRM plans and control application. That means tiering must influence pre-award due diligence, contract controls, monitoring cadence, incident inclusion, and post-relationship requirements. If all tiers receive the same evidence requests and monitoring, the model is only cosmetic. - Higher tiers should trigger deeper due diligence, stronger clauses, and tighter monitoring cadence - Critical suppliers should be more tightly integrated into incident planning and recovery exercises - Lower tiers can use lighter controls but still need documented reassessment triggers ## Re-tiering is mandatory when the relationship changes The publication describes supply chain risk as dynamic and connected to the full life cycle. Supplier tiering therefore cannot be set once and forgotten. Ownership changes, new regions, new services, new subcontractors, and incident history can all change exposure materially. The organization should treat re-tiering as part of continuous improvement and documented risk management, not as an exception. - Define material-change triggers that force reassessment - Record re-tiering rationale, approvers, and control consequences - Use re-tiering to update contract, monitoring, and action-plan requirements ## Keep the evidence pack that makes tiering defensible Tiering decisions need to survive both incidents and audits. The evidence pack should show the criteria used, the analysis performed, the decision made, and the controls that followed from that decision. That linkage is what makes the model publication-grade rather than cosmetic. - Tiering register with rationale, risk factors, approvals, and review dates - Assessment and monitoring records linked to the tier assignment - Clause matrix and control requirements linked to each tier - Exception, re-tiering, and corrective-action records tied to the supplier history ## Primary sources - [NIST SP 800-161 Rev. 1 (Updated) - DOI](https://doi.org/10.6028/NIST.SP.800-161r1-upd1?ref=sorena.io) - Primary source for C-SCRM multilevel model, acquisition integration, metrics, and templates. - [NIST SP 800-161 Rev. 1 publication page](https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final?ref=sorena.io) - Official publication details and document access. - [NIST SP 800-53 Rev. 5 (Update 1)](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final?ref=sorena.io) - Reference control catalog used to map supplier assurance controls. ## Related Topic Guides - [NIST SP 800-161 Rev. 1 Compliance Playbook (C-SCRM)](/artifacts/global/nist-sp-800-161-rev-1/compliance.md): Practical SP 800-161 Rev. 1 compliance playbook: integrate C-SCRM with enterprise risk management, define strategy and implementation plan. - [NIST SP 800-161 Rev. 1 Contract and Monitoring Controls](/artifacts/global/nist-sp-800-161-rev-1/contract-and-monitoring-controls.md): Practical contract and monitoring controls for C-SCRM under SP 800-161 Rev. - [NIST SP 800-161 Rev. 1 FAQ (C-SCRM Implementation)](/artifacts/global/nist-sp-800-161-rev-1/faq.md): NIST SP 800-161 Rev. 1 FAQ: scope, applicability outside federal environments, supplier risk tiering, acquisition and contract controls, C-SCRM metrics. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-161-rev-1/supplier-risk-tiering --- --- title: "NIST SP 800-218 SSDF Compliance Playbook" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-218-ssdf/compliance" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-218-ssdf/compliance" author: "Sorena AI" description: "Task-level SSDF compliance playbook grounded to NIST SP 800-218: PO, PS, PW, and RV implementation, secure environments, release integrity." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST SP 800-218 compliance" - "SSDF compliance playbook" - "PO PS PW RV implementation" - "secure software development program" - "release integrity controls" - "provenance and SBOM controls" - "supplier software security requirements" - "vulnerability disclosure and remediation" - "GLOBAL compliance" - "NIST SP 800-218" - "SSDF" - "Secure SDLC" - "DevSecOps" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-218 SSDF Compliance Playbook Task-level SSDF compliance playbook grounded to NIST SP 800-218: PO, PS, PW, and RV implementation, secure environments, release integrity. *Playbook* *GLOBAL* ## NIST SP 800-218 SSDF Compliance A grounded implementation model for running SSDF as a real secure software development program. Built for engineering leadership, product security, platform teams, procurement, legal, and internal assurance. SSDF compliance is the disciplined implementation of NIST SP 800-218 task groups across the software life cycle. The practical goal is to reduce vulnerabilities in released software, limit the impact of undetected flaws, and prevent recurrence through root-cause learning. That means translating SSDF into named workflows, clear owners, secure environments, release criteria, supplier expectations, and evidence that can be reused in customer reviews and internal audits. ## Start with the actual SSDF structure, not a generic secure SDLC slogan NIST organizes SSDF v1.1 into four practice groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. Implementation should track the NIST task identifiers because that is where the operational detail lives. A strong rollout builds a crosswalk from each SSDF task to an internal control, owner, system of record, and recurring review point. That makes the program explainable to both engineers and software acquirers. - PO tasks cover requirements, roles, supporting toolchains, criteria, and secure development environments - PS tasks cover access control for code, release integrity verification, and release archival and provenance - PW tasks cover secure design, reuse of well-secured components, hardened builds, review and analysis, executable testing, and secure release - RV tasks cover ongoing identification, risk-based remediation, disclosure, and root-cause-driven SDLC improvement ## Use PO.1, PO.3, and PO.5 to create the operating baseline The highest-leverage early work sits in the Prepare the Organization practices. PO.1 requires defined security requirements from internal and external sources, including what third parties must provide. PO.3 requires deliberate toolchain design, maintenance, and artifact generation. PO.5 requires separation and protection of development environments and risk-based hardening of development endpoints. Without those controls, later security testing and release decisions become inconsistent because tools, environments, and requirements drift between teams. - Document software development security requirements once and maintain them over time - Communicate third-party requirements in contracts, supplier onboarding, and component approval workflows under PO.1.3 - Specify mandatory tools, integrations, audit logs, and artifact retention in PO.3.1 to PO.3.3 - Separate development, build, test, and release environments and harden developer endpoints under PO.5.1 and PO.5.2 ## Make release integrity, provenance, and third-party control non-negotiable SSDF is not limited to coding practices. PS.2 and PS.3 require a usable verification path for software acquirers and a protected archive of release files, integrity verification data, and provenance data. PW.4 requires organizations to acquire and maintain well-secured third-party components and verify that those components continue to meet requirements throughout their life cycles. This is where many teams stay shallow. NIST is explicit about cryptographic hashes, provenance information, and recurring checks for known vulnerabilities and supplier behavior. - Publish or otherwise provide software release integrity information that acquirers can verify under PS.2.1 - Archive release files, integrity data, and provenance data with strong access and integrity controls under PS.3.1 - Maintain and share provenance data, including SBOM-style component visibility, under PS.3.2 - Require vulnerability disclosure capability, provenance information, and life-cycle verification for third-party components under PW.4.1 and PW.4.4 ## Run PW and RV as a closed-loop engineering system PW.6 to PW.8 require up-to-date build tooling, approved compiler and interpreter settings, code review or code analysis, executable testing, and documented triage of findings in the development workflow. RV.1 to RV.3 then extend that discipline after release through vulnerability intake, disclosure, remediation, and root-cause analysis. A compliant SSDF program therefore needs release gates before shipment and learning loops after shipment. One without the other is incomplete. - Use approved compiler, interpreter, and build configurations that improve executable security under PW.6 - Record and triage code review, analysis, and testing findings inside the same workflow used to manage engineering work under PW.7 and PW.8 - Establish a vulnerability disclosure program and clear remediation decision path under RV.1.3 and RV.2 - Feed root-cause patterns and lessons learned back into coding standards, toolchain settings, and SDLC workflows under RV.3.1 to RV.3.4 *Recommended next step* *Placement: after the compliance steps* ## Turn NIST SP 800-218 SSDF Compliance into an operational assessment Assessment Autopilot can take NIST SP 800-218 SSDF Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on NIST SP 800-218 SSDF can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for NIST SP 800-218 SSDF Compliance](/solutions/assessment.md): Start from NIST SP 800-218 SSDF Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through NIST SP 800-218 SSDF](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-218 SSDF Compliance. ## Primary sources - [NIST SP 800-218, Secure Software Development Framework Version 1.1](https://doi.org/10.6028/NIST.SP.800-218?ref=sorena.io) - Primary source for SSDF practices, task identifiers, implementation examples, and Appendix A EO 14028 mapping. - [NIST SP 800-218 publication page](https://csrc.nist.gov/pubs/sp/800/218/final?ref=sorena.io) - Official publication record and download location. - [NIST EO 14028 resource page](https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity?ref=sorena.io) - Context for the SSDF update and related software supply chain deliverables. ## Related Topic Guides - [NIST SP 800-218 SSDF Evidence for Audits | Release Integrity and Provenance](/artifacts/global/nist-sp-800-218-ssdf/evidence-for-audits.md): Build an SSDF evidence pack grounded to NIST SP 800-218 with PO, PS, PW, and RV artifacts, release integrity data, provenance and SBOM records. - [NIST SP 800-218 SSDF FAQ | Practical SSDF Questions](/artifacts/global/nist-sp-800-218-ssdf/faq.md): Practical SSDF FAQ grounded to NIST SP 800-218: what SSDF is, how to phase PO PS PW RV, how to handle legacy products, what suppliers should provide. - [NIST SP 800-218 SSDF Secure Development Practices | Task Level Guide](/artifacts/global/nist-sp-800-218-ssdf/secure-development-practices.md): Task-level SSDF practice guide covering PO, PS, PW, and RV: secure toolchains, environment separation, release integrity, provenance, third-party components. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-218-ssdf/compliance --- --- title: "NIST SP 800-218 SSDF Evidence for Audits" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-218-ssdf/evidence-for-audits" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-218-ssdf/evidence-for-audits" author: "Sorena AI" description: "Build an SSDF evidence pack grounded to NIST SP 800-218 with PO, PS, PW, and RV artifacts, release integrity data, provenance and SBOM records." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "SSDF evidence for audits" - "NIST SP 800-218 audit evidence" - "release integrity evidence" - "provenance and SBOM evidence" - "supplier security evidence" - "secure SDLC audit readiness" - "vulnerability response audit evidence" - "GLOBAL compliance" - "NIST SP 800-218" - "SSDF audit evidence" - "Secure SDLC assurance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-218 SSDF Evidence for Audits Build an SSDF evidence pack grounded to NIST SP 800-218 with PO, PS, PW, and RV artifacts, release integrity data, provenance and SBOM records. *Audit Readiness* *GLOBAL* ## NIST SP 800-218 SSDF Evidence for Audits How to build an SSDF evidence pack that is current, traceable, and grounded to NIST task groups. Use this guide for customer security reviews, procurement diligence, internal audit, and release governance checks. SSDF assurance fails when evidence is generic, fragmented, or disconnected from the NIST task model. A defensible evidence pack should show how PO, PS, PW, and RV controls actually operated for real products and releases. The most important proof points are usually secure environments, toolchain-generated artifacts, release integrity data, provenance records, third-party component checks, vulnerability remediation, and management review. ## Index evidence by SSDF task group so reviewers can follow the logic Organize evidence by the practice groups and the tasks most likely to be tested. That usually means PO.1, PO.3, PO.5, PS.2, PS.3, PW.4, PW.6 to PW.8, and RV.1 to RV.3. For every artifact, record the owner, source system, release or time period covered, reviewer expectations, and freshness rule. Auditors trust structure and traceability more than large document dumps. - PO evidence: requirement register, role matrix, toolchain standards, environment segregation diagrams, endpoint hardening standards - PS evidence: repository permissions, signing or hashing outputs, release archive controls, provenance handling rules - PW evidence: approved component lists, provenance and SBOM reviews, build configurations, code review outputs, executable testing results - RV evidence: vulnerability intake logs, triage records, remediation decisions, advisories, root-cause reviews, corrective actions *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep NIST SP 800-218 SSDF Evidence for Audits in one governed evidence system SSOT can take NIST SP 800-218 SSDF Evidence for Audits from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on NIST SP 800-218 SSDF can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for NIST SP 800-218 SSDF Evidence for Audits](/solutions/ssot.md): Start from NIST SP 800-218 SSDF Evidence for Audits and keep documents, evidence, and control records in one governed system. - [Talk through NIST SP 800-218 SSDF](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-218 SSDF Evidence for Audits. ## Treat release integrity and provenance as first-class audit objects NIST is explicit that software acquirers should have a way to verify release integrity. PS.2.1 calls for integrity verification information, with cryptographic hashes as a notional example. PS.3.1 and PS.3.2 extend that into archived release records and maintained provenance data. In practice, auditors will ask whether a sampled release can be reconstructed as a trustworthy package of release files, integrity verification data, provenance data, and approval records. - Retain release hashes, signatures, or equivalent integrity-verification outputs in a controlled system - Retain archived release packages with read-only or tightly restricted access after release - Keep provenance data and SBOM-style component data current whenever components change - Show that operations and response teams can access provenance data when investigating newly disclosed vulnerabilities ## Sample third-party component evidence and life-cycle checks, not just internal builds SSDF explicitly covers acquired commercial software, open-source software, and other third-party components. Evidence should therefore include approval criteria, provenance collection, public vulnerability monitoring, supplier reassessment, and exceptions for components that do not fully meet requirements. A common gap is having a component policy without proof that component versions were verified continuously through their life cycles. - Sample approved component records and verify that provenance information was collected under PW.4.1 - Verify recurring checks for known public vulnerabilities and vendor fixes under PW.4.4 - Check supplier attestation refresh, disclosure commitments, and escalation paths for non-conforming components - Trace exceptions from approval through compensating controls, approval authority, and expiry ## Use readiness testing to prove the SSDF loop actually closes A pre-assessment should test whether findings from PW.7, PW.8, RV.1, and RV.2 flow into remediation and whether RV.3 produces durable SDLC improvements. That is how you distinguish an operational program from a static document set. The most persuasive evidence is a sampled issue that moved from discovery to remediation to release decision to root-cause lesson and then to a preventive control update. - Confirm that code review, code analysis, and executable testing findings are recorded and triaged in the engineering workflow - Confirm that vulnerability intake, risk analysis, and remediation decisions are time stamped and attributable - Confirm that advisories or customer communications exist where disclosure was required - Confirm that root-cause lessons changed a coding standard, build setting, test scope, or supplier requirement ## Primary sources - [NIST SP 800-218, Secure Software Development Framework Version 1.1](https://doi.org/10.6028/NIST.SP.800-218?ref=sorena.io) - Primary source for evidence-relevant SSDF tasks such as PO.3.3, PS.2.1, PS.3.1, PS.3.2, PW.4.4, and RV.1 to RV.3. - [NIST SP 800-218 publication page](https://csrc.nist.gov/pubs/sp/800/218/final?ref=sorena.io) - Official publication record and downloads. - [NIST National Vulnerability Database](https://nvd.nist.gov/?ref=sorena.io) - Example public source often referenced during RV.1.1 and component vulnerability monitoring. ## Related Topic Guides - [NIST SP 800-218 SSDF Compliance Playbook | PO PS PW RV Implementation](/artifacts/global/nist-sp-800-218-ssdf/compliance.md): Task-level SSDF compliance playbook grounded to NIST SP 800-218: PO, PS, PW, and RV implementation, secure environments, release integrity. - [NIST SP 800-218 SSDF FAQ | Practical SSDF Questions](/artifacts/global/nist-sp-800-218-ssdf/faq.md): Practical SSDF FAQ grounded to NIST SP 800-218: what SSDF is, how to phase PO PS PW RV, how to handle legacy products, what suppliers should provide. - [NIST SP 800-218 SSDF Secure Development Practices | Task Level Guide](/artifacts/global/nist-sp-800-218-ssdf/secure-development-practices.md): Task-level SSDF practice guide covering PO, PS, PW, and RV: secure toolchains, environment separation, release integrity, provenance, third-party components. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-218-ssdf/evidence-for-audits --- --- title: "NIST SP 800-218 SSDF FAQ" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-218-ssdf/faq" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-218-ssdf/faq" author: "Sorena AI" description: "Practical SSDF FAQ grounded to NIST SP 800-218: what SSDF is, how to phase PO PS PW RV, how to handle legacy products, what suppliers should provide." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST SP 800-218 FAQ" - "SSDF FAQ" - "SSDF supplier requirements" - "SSDF release integrity" - "SSDF provenance" - "SSDF legacy software" - "SSDF audit evidence" - "GLOBAL compliance" - "NIST SP 800-218" - "SSDF" - "FAQ" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-218 SSDF FAQ Practical SSDF FAQ grounded to NIST SP 800-218: what SSDF is, how to phase PO PS PW RV, how to handle legacy products, what suppliers should provide. *FAQ* *GLOBAL* ## NIST SP 800-218 SSDF FAQ Direct answers for secure software development leaders, platform teams, and assurance reviewers. Focused on sequencing, third-party software, release integrity, provenance, and audit expectations. Most SSDF questions are not about the document title. They are about operating choices: where to start, how much to automate, what software suppliers must provide, how to handle legacy products, and what evidence proves that the program is real. This FAQ answers those questions using the structure and examples NIST actually put into SP 800-218. ## Is SSDF a certification or a mandatory law No. NIST SP 800-218 is voluntary guidance. It is designed for software producers and software acquirers and can be used by organizations of different sizes and maturity levels. That said, SSDF became highly influential because NIST updated it in response to EO 14028 and Appendix A maps SSDF tasks to the EO Section 4e software supply chain expectations. - Use SSDF as a common vocabulary for engineering teams, procurement, and customers - Do not market it as a formal certification unless another program explicitly says so - Expect customers or regulators to use SSDF-style questions when reviewing software security posture ## Where should a smaller team start Start with the tasks that make later controls possible. In practice that means PO.1 for requirements, PO.3 for toolchains and artifact generation, PO.5 for secure environments, then PW.7 and PW.8 for review and testing, and RV.1 to RV.2 for vulnerability handling. That sequence gives a team a baseline that can produce evidence while still improving released software quickly. - Phase 1: define requirements, toolchains, secure environments, and release criteria - Phase 2: add code review, code analysis, executable testing, and release integrity controls - Phase 3: deepen supplier verification, provenance handling, and root-cause-based improvement ## How should SSDF apply to legacy software and long-lived products Apply SSDF incrementally based on risk. Legacy products usually need RV controls first because they already have released code and exposed components. That means better vulnerability intake, public-source monitoring, remediation decisions, and advisories. Then expand upstream into PW.4, PW.7, and PW.8 by tightening component visibility, code review, analysis, testing, and secure update handling for the highest-risk products first. - Prioritize internet-exposed, safety-relevant, or high-customer-impact products first - Use compensating controls and time-bound remediation plans where full modernization is not immediate - Document residual risk in release and support decisions rather than ignoring legacy gaps ## What should we require from software suppliers and component vendors NIST makes supplier expectations explicit in PO.1.3 and PW.4.1 to PW.4.4. The organization should define security requirements for supplied components, communicate them contractually, collect provenance information, and verify compliance through the component life cycle. A supplier questionnaire alone is not enough. You need evidence and a recurring re-check model. - Require vulnerability disclosure and product security incident response capability - Require provenance information and integrity verification mechanisms for delivered software - Require recurring checks for public vulnerabilities, support status, and remediation behavior - Require a defined exception path when a needed component falls short of requirements ## What do release integrity and provenance actually mean in SSDF Release integrity means the recipient can verify that the software release is legitimate and untampered. NIST gives cryptographic hashes for release files as a concrete example in PS.2.1. Provenance means retaining and sharing trustworthy information about the components and origins of the release. PS.3.2 explicitly calls for collecting, safeguarding, maintaining, and sharing provenance data, with SBOM-style visibility as an example. - Integrity focuses on whether the release package is authentic and unchanged - Provenance focuses on what is inside the release and where it came from - Both matter for software acquirers, customer trust, and faster vulnerability response ## What evidence do customers and auditors usually ask for Expect requests for governance artifacts, secure environment evidence, release integrity records, provenance data, component approval records, code review and test outputs, vulnerability handling records, and management review evidence. The strongest answer is not a slide deck. It is a sampled chain of proof from requirement to tool output to release decision to post-release response. - Governance: requirements, roles, policy, training, and review cadence - Engineering: toolchain standards, build settings, review findings, test results, release approvals - Supply chain and response: provenance data, supplier checks, advisories, remediation and root-cause actions *Recommended next step* *Placement: after the FAQ section* ## Use NIST SP 800-218 SSDF FAQ as a cited research workflow Research Copilot can take NIST SP 800-218 SSDF FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on NIST SP 800-218 SSDF can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for NIST SP 800-218 SSDF FAQ](/solutions/research-copilot.md): Start from NIST SP 800-218 SSDF FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through NIST SP 800-218 SSDF](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-218 SSDF FAQ. ## Primary sources - [NIST SP 800-218, Secure Software Development Framework Version 1.1](https://doi.org/10.6028/NIST.SP.800-218?ref=sorena.io) - Primary source for SSDF scope, audiences, tasks, notional implementation examples, and EO 14028 mapping. - [NIST SP 800-218 publication page](https://csrc.nist.gov/pubs/sp/800/218/final?ref=sorena.io) - Official publication record and downloads. - [NIST EO 14028 resource page](https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity?ref=sorena.io) - Background on the executive order that drove the SSDF update work. ## Related Topic Guides - [NIST SP 800-218 SSDF Compliance Playbook | PO PS PW RV Implementation](/artifacts/global/nist-sp-800-218-ssdf/compliance.md): Task-level SSDF compliance playbook grounded to NIST SP 800-218: PO, PS, PW, and RV implementation, secure environments, release integrity. - [NIST SP 800-218 SSDF Evidence for Audits | Release Integrity and Provenance](/artifacts/global/nist-sp-800-218-ssdf/evidence-for-audits.md): Build an SSDF evidence pack grounded to NIST SP 800-218 with PO, PS, PW, and RV artifacts, release integrity data, provenance and SBOM records. - [NIST SP 800-218 SSDF Secure Development Practices | Task Level Guide](/artifacts/global/nist-sp-800-218-ssdf/secure-development-practices.md): Task-level SSDF practice guide covering PO, PS, PW, and RV: secure toolchains, environment separation, release integrity, provenance, third-party components. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-218-ssdf/faq --- --- title: "NIST SP 800-218 SSDF Secure Development Practices" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-218-ssdf/secure-development-practices" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-218-ssdf/secure-development-practices" author: "Sorena AI" description: "Task-level SSDF practice guide covering PO, PS, PW, and RV: secure toolchains, environment separation, release integrity, provenance, third-party components." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "SSDF secure development practices" - "NIST SP 800-218 tasks" - "PO PS PW RV implementation" - "secure toolchains" - "secure development environments" - "release integrity and provenance" - "code review and executable testing" - "vulnerability root cause analysis" - "GLOBAL compliance" - "NIST SP 800-218" - "SSDF practices" - "Secure SDLC" - "DevSecOps" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-218 SSDF Secure Development Practices Task-level SSDF practice guide covering PO, PS, PW, and RV: secure toolchains, environment separation, release integrity, provenance, third-party components. *Practice Guide* *GLOBAL* ## NIST SP 800-218 SSDF Secure Development Practices How to implement SSDF practices with concrete task-level depth and operational consistency. Designed for product security, platform engineering, developers, release managers, and assurance teams. SSDF implementation becomes useful when teams operate the task groups as real engineering routines. NIST does not stop at broad outcomes. The framework points to requirements management, toolchain design, environment hardening, release integrity, provenance, component verification, code review, executable testing, and vulnerability root-cause learning. This page focuses on those practical mechanics. ## PO practices create the stable base for every later control Prepare the Organization is where teams define security requirements, assign responsibilities, implement supporting toolchains, define release and measurement criteria, and secure development environments. These controls reduce variation across teams and releases. The most important operational choice is to decide what must be standardized for everyone and what can be risk-based by product line. - Use PO.1 to maintain internal and external security requirements, including supplier requirements - Use PO.3 to define tool categories, integrations, audit trails, reproducible-build support, and artifact retention - Use PO.4 to set release criteria, measurement logic, and escalation paths - Use PO.5 to separate development environments and harden development endpoints based on risk ## PS practices protect code, releases, and verification data Protect the Software covers more than source-code permissions. PS.1 addresses least-privilege access to code. PS.2 requires a mechanism for software acquirers to verify release integrity. PS.3 requires secure archival of released software and its related integrity and provenance data. Teams that skip this work usually struggle during customer due diligence because they cannot prove that a release package is authentic or reconstruct its component history. - Protect all forms of code, including source code, executables, and configuration as code, under least privilege - Provide release integrity information such as cryptographic hashes or signatures under PS.2.1 - Archive release packages with associated verification and provenance data under PS.3.1 - Maintain and update provenance data, including SBOM-style component views, under PS.3.2 ## PW practices cover design, component reuse, builds, review, and testing Produce Well-Secured Software includes the day-to-day engineering work that most teams associate with secure development. The SSDF is explicit about well-secured third-party components, secure tool configuration, code review or code analysis, and executable testing. The task IDs matter because they clarify that secure development is not only about writing new code. It is also about deciding what software to reuse, what build settings to enforce, and how to record and triage discovered issues. - Use PW.4 to approve, monitor, and re-check third-party components, including provenance and public vulnerability review - Use PW.6 to require up-to-date compiler, interpreter, and build tools with approved secure settings - Use PW.7 to perform code review or code analysis and record discovered issues in the development workflow - Use PW.8 to scope, run, and document executable testing with triage and remediation tracking ## RV practices make the SDLC learn from released software Respond to Vulnerabilities is what keeps the framework credible after release. RV.1 requires gathering and investigating credible reports from users, acquirers, and public sources. RV.2 requires risk-based remediation decisions. RV.3 requires root-cause analysis and SDLC improvements to prevent recurrence. This is the difference between a team that only patches and a team that actually matures. - Monitor vulnerability databases, mailing lists, disclosures, and customer reports under RV.1.1 - Analyze each vulnerability for risk and plan remediation or other risk response under RV.2.1 and RV.2.2 - Issue advisories or direct communications that tell customers what is affected and how to respond - Use RV.3 findings to update coding standards, tests, component policies, and release criteria *Recommended next step* *Placement: near the end of the main content before related guides* ## Use NIST SP 800-218 SSDF Secure Development Practices as a cited research workflow Research Copilot can take NIST SP 800-218 SSDF Secure Development Practices from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on NIST SP 800-218 SSDF can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for NIST SP 800-218 SSDF Secure Development Practices](/solutions/research-copilot.md): Start from NIST SP 800-218 SSDF Secure Development Practices and answer scope, timing, and interpretation questions with cited outputs. - [Talk through NIST SP 800-218 SSDF](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-218 SSDF Secure Development Practices. ## Primary sources - [NIST SP 800-218, Secure Software Development Framework Version 1.1](https://doi.org/10.6028/NIST.SP.800-218?ref=sorena.io) - Primary source for PO, PS, PW, and RV practices, tasks, and notional implementation examples. - [NIST SP 800-218 publication page](https://csrc.nist.gov/pubs/sp/800/218/final?ref=sorena.io) - Official publication record and downloads. - [NIST SP 800-53 Rev. 5 publication page](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final?ref=sorena.io) - Referenced by NIST within SSDF mappings and often used for deeper control design. ## Related Topic Guides - [NIST SP 800-218 SSDF Compliance Playbook | PO PS PW RV Implementation](/artifacts/global/nist-sp-800-218-ssdf/compliance.md): Task-level SSDF compliance playbook grounded to NIST SP 800-218: PO, PS, PW, and RV implementation, secure environments, release integrity. - [NIST SP 800-218 SSDF Evidence for Audits | Release Integrity and Provenance](/artifacts/global/nist-sp-800-218-ssdf/evidence-for-audits.md): Build an SSDF evidence pack grounded to NIST SP 800-218 with PO, PS, PW, and RV artifacts, release integrity data, provenance and SBOM records. - [NIST SP 800-218 SSDF FAQ | Practical SSDF Questions](/artifacts/global/nist-sp-800-218-ssdf/faq.md): Practical SSDF FAQ grounded to NIST SP 800-218: what SSDF is, how to phase PO PS PW RV, how to handle legacy products, what suppliers should provide. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-218-ssdf/secure-development-practices --- --- title: "NIST SP 800-53A Rev. 5 Assessment Procedures" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/assessment-procedures-800-53a" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/assessment-procedures-800-53a" author: "Sorena AI" description: "Grounded guide to SP 800-53A Rev. 5 covering assessment objectives, determination statements, examine interview test methods, depth and coverage." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST SP 800-53A Rev 5" - "NIST assessment procedures" - "determination statements" - "assessment methods examine interview test" - "depth and coverage" - "common control assessment" - "ODP assessment" - "GLOBAL compliance" - "NIST SP 800-53A" - "Control assessment" - "Assurance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-53A Rev. 5 Assessment Procedures Grounded guide to SP 800-53A Rev. 5 covering assessment objectives, determination statements, examine interview test methods, depth and coverage. *Assessment* *GLOBAL* ## NIST SP 800-53 Rev. 5 Assessment Procedures (SP 800-53A) A practical method for running SP 800-53A with enough rigor to support real risk decisions. Focused on assessment objectives, method selection, depth and coverage, and reusable evidence. SP 800-53A Rev. 5 provides the methodology for assessing security and privacy controls in systems and organizations. The goal is not paperwork or simple pass-fail scoring. NIST frames control assessment as the main vehicle for determining whether selected controls are implemented correctly, operating as intended, and producing the desired outcome. That means assessment planning, method selection, and evidence coverage all need to be deliberate. ## Start from objectives and determination statements, not from a loose checklist An SP 800-53A procedure is built from assessment objectives, and each objective is expressed through determination statements tied back to the control text. Rev. 5 improved this structure by separating organization-defined parameter checks from the rest of the determination statements. That separation matters because it lets assessors verify first whether the organization has actually instantiated the variable parts of the control before judging effectiveness. - Use the assessment procedure as a starting point, then tailor it to the system and environment - Check organization-defined parameters explicitly before testing broader control effectiveness - Trace every finding back to a determination statement so results are explainable and repeatable - Use the same structure to support assurance cases and risk-based authorization decisions ## Choose methods and objects based on assurance needs SP 800-53A defines three assessment methods: examine, interview, and test. NIST is explicit that organizations are not expected to use every method and every object in every case. The right mix depends on risk, system categorization, prior evidence, and the assurance level required. Assessment objects include specifications, mechanisms, activities, records, and other artifacts. Good plans explain why the chosen methods and objects are sufficient. - Examine for policies, plans, configurations, records, logs, designs, and system representations - Interview for role execution, exception handling, and process consistency over time - Test for actual behavior of mechanisms and activities under specified conditions - Document why the chosen object set is adequate for the control and the system risk profile *Recommended next step* *Placement: after the main workflow section* ## Turn NIST SP 800-53 Rev. 5 Assessment Procedures (SP 800-53A) into an operational assessment Assessment Autopilot can take NIST SP 800-53 Rev. 5 Assessment Procedures (SP 800-53A) from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on NIST SP 800-53 Rev. 5 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for NIST SP 800-53 Rev. 5 Assessment Procedures (SP 800-53A)](/solutions/assessment.md): Start from NIST SP 800-53 Rev. 5 Assessment Procedures (SP 800-53A) and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through NIST SP 800-53 Rev. 5](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-53 Rev. 5 Assessment Procedures (SP 800-53A). ## Use depth and coverage to control rigor and cost Appendix C introduces depth and coverage as attributes of the assessment methods. Those attributes define the rigor and the scope of the work, ranging from basic to focused to comprehensive. This is one of the most important parts of SP 800-53A because it is how organizations avoid both shallow sampling and over-engineered testing. The right values should be tied to system categorization, risk tolerance, and assurance requirements. - Basic depth and coverage are often enough for lower-assurance checks and stable low-risk areas - Focused depth and coverage add specific high-value objects or individuals to the representative sample - Comprehensive depth and coverage require broader samples and deeper technical or procedural understanding - Record the rationale so the selected rigor can be defended later during review or audit ## Do not treat common controls and inherited controls as automatically done NIST states that common controls are not re-assessed inside every inheriting system unless those controls are part of the provider system itself. Instead, the assessor verifies that the inheriting system is actually using the common control and that the assessment results for the common control are available. This means assessment completion for a system may depend on assessment results that sit elsewhere. Teams need explicit dependency tracking. - Verify inheritance is real, not assumed, for each common or hybrid control - Track provider-system dependencies and do not close dependent assessments prematurely - Reuse prior evidence only when scope, implementation state, and timing still match - Send findings into formal risk response, not just local cleanup notes ## Primary sources - [NIST SP 800-53A Rev. 5, Assessing Security and Privacy Controls](https://doi.org/10.6028/NIST.SP.800-53Ar5?ref=sorena.io) - Primary source for assessment objectives, determination statements, methods, objects, and depth and coverage. - [NIST SP 800-53 Rev. 5](https://doi.org/10.6028/NIST.SP.800-53r5?ref=sorena.io) - Control catalog assessed through SP 800-53A procedures. - [NIST SP 800-37 Rev. 2](https://csrc.nist.gov/pubs/sp/800/37/r2/final?ref=sorena.io) - RMF context for assessment, authorization, and ongoing monitoring decisions. ## Related Topic Guides - [NIST SP 800-53 Rev. 5 Compliance Playbook | Rev. 5 Operating Model](/artifacts/global/nist-sp-800-53-rev-5/compliance.md): Grounded playbook for SP 800-53 Rev. 5 covering integrated security and privacy controls, control ownership at organization mission and system levels. - [NIST SP 800-53 Rev. 5 Control Tailoring Method | SP 800-53B Guide](/artifacts/global/nist-sp-800-53-rev-5/control-tailoring-method.md): Grounded control tailoring method for SP 800-53 Rev. - [NIST SP 800-53 Rev. 5 Evidence and Audit Readiness](/artifacts/global/nist-sp-800-53-rev-5/evidence-and-audit-readiness.md): Grounded SP 800-53 evidence guide covering control-to-evidence mapping, common-control inheritance, freshness and sampling, assessment findings. - [NIST SP 800-53 Rev. 5 FAQ | Practical Rev. 5 Questions](/artifacts/global/nist-sp-800-53-rev-5/faq.md): Practical FAQ on NIST SP 800-53 Rev. 5 covering federal and non-federal use, Rev. - [NIST SP 800-53 Rev. 5 vs ISO 27001 | Controls vs ISMS](/artifacts/global/nist-sp-800-53-rev-5/nist-800-53-vs-iso-27001.md): Grounded comparison of NIST SP 800-53 Rev. 5 and ISO 27001 covering control-catalog depth, ISMS governance, assessment style. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/assessment-procedures-800-53a --- --- title: "NIST SP 800-53 Rev. 5 Compliance Playbook" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/compliance" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/compliance" author: "Sorena AI" description: "Grounded playbook for SP 800-53 Rev. 5 covering integrated security and privacy controls, control ownership at organization mission and system levels." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST SP 800-53 compliance" - "NIST 800-53 Rev 5 implementation" - "integrated security and privacy controls" - "common controls" - "supply chain risk management family" - "continuous monitoring" - "control ownership" - "GLOBAL compliance" - "NIST SP 800-53 Rev. 5" - "Control implementation" - "RMF" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-53 Rev. 5 Compliance Playbook Grounded playbook for SP 800-53 Rev. 5 covering integrated security and privacy controls, control ownership at organization mission and system levels. *Playbook* *GLOBAL* ## NIST SP 800-53 Rev. 5 Compliance A grounded operating model for implementing security and privacy controls across organizations and systems. Designed for GRC, security engineering, privacy, platform, audit, and authorization stakeholders. SP 800-53 Rev. 5 compliance is not only about selecting controls. It is about governing an integrated catalog of security and privacy controls across organization, mission and business process, and system levels. Revision 5 strengthened that model by integrating privacy into the main catalog, establishing the SR supply chain risk management family, and moving baselines and tailoring guidance into SP 800-53B. A practical program needs to reflect those structural changes. ## Start with the real Rev. 5 architecture NIST describes the catalog as flexible and customizable, intended to support risk management across many kinds of platforms and environments. Rev. 5 is not just a federal paperwork set. It is a broad control architecture for security and privacy outcomes. The most important program decision is to define which controls are organization-wide, which are mission or business-process level, and which are system-specific. - Run a single control governance model across organization, mission, and system levels - Assign common, hybrid, and system-specific ownership explicitly - Use program-level policy and procedure documents where possible instead of duplicating system text - Treat security and privacy collaboration as part of the operating model, not an afterthought ## Use Rev. 5 family changes to improve program design Revision 5 integrated security and privacy controls into one consolidated catalog and established the SR supply chain risk management family. NIST also calls out developer-focused SA and SR controls because system and component development may happen internally or through external acquisition. Teams that still organize around a narrow infrastructure-only mindset usually miss the acquisition and supplier side of Rev. 5. - Use the SR family to govern supply chain risk tolerance, monitoring, and component trust decisions - Use SA and SR controls to express developer and supplier responsibilities clearly - Connect privacy controls to the same evidence and assessment model rather than running a separate shadow process - Review family coverage for cloud, mobile, IoT, industrial, and other platform types relevant to the environment ## Sequence implementation around dependencies, inheritance, and evidence High-performing programs implement foundational controls and shared services first because many system-level controls inherit from them. That means common-control governance, evidence access, and reassessment triggers need to be defined early. Implementation should also account for organization-defined parameters because controls are not fully operational until those values are instantiated and approved. - Prioritize common controls and shared services that support many systems - Maintain an ODP register or equivalent configuration record for instantiated parameter values - Link each implemented control to assessment evidence, owner, and review cadence - Track changes that force reassessment, especially when shared services or inherited controls change ## Use assessment and monitoring to keep the program honest NIST expects controls to be assessed for whether they are implemented correctly, operating as intended, and producing the desired outcome. SP 800-53A provides the detailed method. Continuous monitoring then keeps control state current after the initial assessment. Compliance therefore depends on recurring measurement, not just on an implementation milestone. - Build assessment plans and monitoring routines into the control lifecycle from the start - Feed findings into formal risk response and remediation tracking - Review repeated findings for design, ownership, or policy weaknesses - Use evidence freshness rules so authorizing officials and auditors see current control state, not stale history *Recommended next step* *Placement: after the compliance steps* ## Turn NIST SP 800-53 Rev. 5 Compliance into an operational assessment Assessment Autopilot can take NIST SP 800-53 Rev. 5 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on NIST SP 800-53 Rev. 5 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for NIST SP 800-53 Rev. 5 Compliance](/solutions/assessment.md): Start from NIST SP 800-53 Rev. 5 Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through NIST SP 800-53 Rev. 5](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-53 Rev. 5 Compliance. ## Primary sources - [NIST SP 800-53 Rev. 5](https://doi.org/10.6028/NIST.SP.800-53r5?ref=sorena.io) - Primary source for the integrated control catalog, Rev. 5 changes, and family structure. - [NIST SP 800-53A Rev. 5](https://doi.org/10.6028/NIST.SP.800-53Ar5?ref=sorena.io) - Assessment methodology used to judge control effectiveness. - [NIST SP 800-53B](https://doi.org/10.6028/NIST.SP.800-53B?ref=sorena.io) - Baselines and tailoring guidance used to build context-specific control sets. ## Related Topic Guides - [NIST SP 800-53 Rev. 5 Control Tailoring Method | SP 800-53B Guide](/artifacts/global/nist-sp-800-53-rev-5/control-tailoring-method.md): Grounded control tailoring method for SP 800-53 Rev. - [NIST SP 800-53 Rev. 5 Evidence and Audit Readiness](/artifacts/global/nist-sp-800-53-rev-5/evidence-and-audit-readiness.md): Grounded SP 800-53 evidence guide covering control-to-evidence mapping, common-control inheritance, freshness and sampling, assessment findings. - [NIST SP 800-53 Rev. 5 FAQ | Practical Rev. 5 Questions](/artifacts/global/nist-sp-800-53-rev-5/faq.md): Practical FAQ on NIST SP 800-53 Rev. 5 covering federal and non-federal use, Rev. - [NIST SP 800-53 Rev. 5 vs ISO 27001 | Controls vs ISMS](/artifacts/global/nist-sp-800-53-rev-5/nist-800-53-vs-iso-27001.md): Grounded comparison of NIST SP 800-53 Rev. 5 and ISO 27001 covering control-catalog depth, ISMS governance, assessment style. - [NIST SP 800-53A Rev. 5 Assessment Procedures](/artifacts/global/nist-sp-800-53-rev-5/assessment-procedures-800-53a.md): Grounded guide to SP 800-53A Rev. 5 covering assessment objectives, determination statements, examine interview test methods, depth and coverage. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/compliance --- --- title: "NIST SP 800-53 Rev. 5 Control Tailoring Method" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/control-tailoring-method" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/control-tailoring-method" author: "Sorena AI" description: "Grounded control tailoring method for SP 800-53 Rev." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST 800-53 tailoring" - "SP 800-53B" - "low moderate high baselines" - "privacy baseline" - "overlays" - "common controls" - "hybrid controls" - "ODP values" - "tailored control baseline" - "GLOBAL compliance" - "NIST SP 800-53 Rev. 5" - "Control tailoring" - "Risk management" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-53 Rev. 5 Control Tailoring Method Grounded control tailoring method for SP 800-53 Rev. *Tailoring* *GLOBAL* ## NIST SP 800-53 Rev. 5 Control Tailoring Method How to tailor Rev. 5 controls with defensible rationale, not ad hoc exceptions. Built for security architects, GRC teams, system owners, and authorizing officials. Tailoring is where the generic catalog becomes a system-specific security and privacy architecture. In Rev. 5, baseline and tailoring guidance moved out of SP 800-53 and into SP 800-53B. NIST gives organizations starting-point baselines, a privacy baseline, tailoring guidance, and overlay concepts. The result should be a tailored control baseline with explicit rationale, parameter values, and reassessment triggers. ## Start from the right baseline and understand what it is SP 800-53B provides three security control baselines for low-impact, moderate-impact, and high-impact systems, plus a privacy baseline applied irrespective of impact level. These baselines are starting points for tailoring, not universal end states. That distinction matters because teams often treat a baseline as a fixed compliance checklist when NIST intends it to be refined to mission, environment, and system characteristics. - Pick the initial low, moderate, or high security baseline using system categorization - Apply the privacy baseline where privacy risk and processing context make it relevant - Document why the starting baseline is appropriate before making changes - Remember that tailoring is expected, not a sign that the baseline was wrong ## Use overlays and scoping guidance to fit the environment NIST defines an overlay as a specification of controls, enhancements, guidance, and supporting information used during tailoring to complement and further refine a baseline. Overlays can be more stringent or less stringent than the original baseline and can apply to multiple systems. Tailoring guidance also considers policy, regulatory, technology, infrastructure, public access, scalability, common-control, and environmental factors. - Use overlays for specific technologies, communities of interest, or operating environments - Record scoping decisions tied to architecture, data, public access, and platform constraints - Check for control dependencies so one scoping decision does not silently break another control objective - Review whether high-value assets need stronger tailoring than raw impact levels suggest ## Instantiate ODPs and classify common, hybrid, and system-specific controls Tailoring is not complete when a control is marked applicable. Many controls require organization-defined parameter values or selections. Those values should be treated as governed decisions, not free-text leftovers. At the same time, each control needs a delivery model. NIST distinguishes common controls, system-specific controls, and hybrid controls. That affects ownership, inheritance, assessment, and evidence reuse. - Maintain a clear record of parameter assignments and selected values for ODPs - Classify each control as common, hybrid, or system-specific and record the provider - Verify that inherited protections and evidence are actually accessible to consuming systems - Set reassessment triggers when common-control providers or platform assumptions change ## Preserve the rationale so assessors and auditors can follow it A tailoring decision without rationale usually fails under assessment. Records should show the baseline, the change, the reason, the risk logic, the approver, and the evidence that supports the decision. This applies equally to exclusions, compensating controls, added enhancements, and overlay-driven refinements. - Maintain a tailoring register linked to system boundaries, risk decisions, and evidence - Document compensating controls in terms of the original control intent and expected assurance level - Review tailoring decisions on schedule and after significant system or mission changes - Expire exceptions deliberately instead of letting them become permanent by neglect *Recommended next step* *Placement: after the main workflow section* ## Turn NIST SP 800-53 Rev. 5 Control Tailoring Method into an operational assessment Assessment Autopilot can take NIST SP 800-53 Rev. 5 Control Tailoring Method from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on NIST SP 800-53 Rev. 5 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for NIST SP 800-53 Rev. 5 Control Tailoring Method](/solutions/assessment.md): Start from NIST SP 800-53 Rev. 5 Control Tailoring Method and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through NIST SP 800-53 Rev. 5](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-53 Rev. 5 Control Tailoring Method. ## Primary sources - [NIST SP 800-53B](https://doi.org/10.6028/NIST.SP.800-53B?ref=sorena.io) - Primary source for low, moderate, and high baselines, the privacy baseline, tailoring guidance, and overlays. - [NIST SP 800-53 Rev. 5](https://doi.org/10.6028/NIST.SP.800-53r5?ref=sorena.io) - Primary control catalog whose controls are selected and tailored. - [NIST SP 800-53A Rev. 5](https://doi.org/10.6028/NIST.SP.800-53Ar5?ref=sorena.io) - Assessment model used to validate tailored control effectiveness. ## Related Topic Guides - [NIST SP 800-53 Rev. 5 Compliance Playbook | Rev. 5 Operating Model](/artifacts/global/nist-sp-800-53-rev-5/compliance.md): Grounded playbook for SP 800-53 Rev. 5 covering integrated security and privacy controls, control ownership at organization mission and system levels. - [NIST SP 800-53 Rev. 5 Evidence and Audit Readiness](/artifacts/global/nist-sp-800-53-rev-5/evidence-and-audit-readiness.md): Grounded SP 800-53 evidence guide covering control-to-evidence mapping, common-control inheritance, freshness and sampling, assessment findings. - [NIST SP 800-53 Rev. 5 FAQ | Practical Rev. 5 Questions](/artifacts/global/nist-sp-800-53-rev-5/faq.md): Practical FAQ on NIST SP 800-53 Rev. 5 covering federal and non-federal use, Rev. - [NIST SP 800-53 Rev. 5 vs ISO 27001 | Controls vs ISMS](/artifacts/global/nist-sp-800-53-rev-5/nist-800-53-vs-iso-27001.md): Grounded comparison of NIST SP 800-53 Rev. 5 and ISO 27001 covering control-catalog depth, ISMS governance, assessment style. - [NIST SP 800-53A Rev. 5 Assessment Procedures](/artifacts/global/nist-sp-800-53-rev-5/assessment-procedures-800-53a.md): Grounded guide to SP 800-53A Rev. 5 covering assessment objectives, determination statements, examine interview test methods, depth and coverage. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/control-tailoring-method --- --- title: "NIST SP 800-53 Rev. 5 Evidence and Audit Readiness" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/evidence-and-audit-readiness" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/evidence-and-audit-readiness" author: "Sorena AI" description: "Grounded SP 800-53 evidence guide covering control-to-evidence mapping, common-control inheritance, freshness and sampling, assessment findings." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST SP 800-53 evidence" - "NIST audit readiness" - "common control evidence" - "SP 800-53A evidence" - "authorization package evidence" - "assurance case evidence" - "GLOBAL compliance" - "NIST SP 800-53 Rev. 5" - "Audit readiness" - "Evidence management" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-53 Rev. 5 Evidence and Audit Readiness Grounded SP 800-53 evidence guide covering control-to-evidence mapping, common-control inheritance, freshness and sampling, assessment findings. *Audit Readiness* *GLOBAL* ## NIST SP 800-53 Rev. 5 Evidence and Audit Readiness A practical evidence model for controls, assessments, authorizations, and recurring review. Built for GRC, audit, security operations, privacy teams, and common-control providers. SP 800-53 evidence should prove more than the existence of documents. It should help assessors and decision makers determine whether controls are implemented correctly, operating as intended, and producing the desired outcome. That requires a control-to-evidence map that covers common controls, inherited controls, system-specific implementations, and the findings and remediation flows that follow assessments. ## Map evidence to control intent, assessment methods, and ownership The strongest evidence libraries are organized so an assessor can move from a control to its assessment objective, then to examine, interview, and test artifacts, and then to the responsible owner. This reflects how SP 800-53A actually works. Evidence should be tagged by control, provider, system, time period, and whether it supports a common, hybrid, or system-specific implementation. - Use one evidence index that identifies source system, owner, refresh rule, and control linkage - Separate policy and design proof from operational records and direct test outputs - Label inherited evidence so consuming systems know exactly what they are relying on - Link findings, plans of action, and risk responses back to the evidence that triggered them *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep NIST SP 800-53 Rev. 5 Evidence and Audit Readiness in one governed evidence system SSOT can take NIST SP 800-53 Rev. 5 Evidence and Audit Readiness from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on NIST SP 800-53 Rev. 5 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for NIST SP 800-53 Rev. 5 Evidence and Audit Readiness](/solutions/ssot.md): Start from NIST SP 800-53 Rev. 5 Evidence and Audit Readiness and keep documents, evidence, and control records in one governed system. - [Talk through NIST SP 800-53 Rev. 5](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-53 Rev. 5 Evidence and Audit Readiness. ## Sample common controls and inherited controls carefully Inherited controls are a major efficiency gain, but only when the inheritance is demonstrable. SP 800-53A notes that systems depending on common controls cannot be considered fully assessed until the common-control assessment results are available. That means evidence programs need dependency tracking, not just file storage. - Maintain provider-side evidence bundles for common controls with version and timing metadata - Verify that each inheriting system is actually using the common control as designed - Track when provider changes force downstream reassessment or evidence refresh - Preserve hybrid-control splits so local and inherited evidence are not confused ## Set freshness and coverage rules that match system risk NIST ties assessment rigor to assurance needs, risk tolerance, and system characteristics. Evidence freshness and sample depth should follow the same logic. High-impact systems and high-value assets need stronger coverage than low-risk, stable areas. Event-driven refresh is often more credible than calendar-only refresh for rapidly changing systems. - Use tighter refresh windows after incidents, major changes, or control failures - Sample representative records plus especially important objects when higher assurance is needed - Keep timestamps, provenance, and owner attribution on all critical evidence objects - Document why the chosen sample and freshness model is sufficient for the system risk profile ## Package evidence for assessment and authorization decisions NIST describes assessment outputs as inputs to risk-based decisions about whether a system should operate or continue operating. Evidence packages therefore need to be understandable to authorizing officials, not just technical reviewers. A useful package combines control state, findings, remediation status, inherited-control dependencies, and clear decision implications. - Create assessor-ready bundles with direct links to control objectives and findings - Include current plans of action and milestones or equivalent remediation tracking - Show risk acceptance and tailoring decisions alongside the evidence they depend on - Version packages so reviewers can see significant control-state changes over time ## Primary sources - [NIST SP 800-53 Rev. 5](https://doi.org/10.6028/NIST.SP.800-53r5?ref=sorena.io) - Primary source for the control catalog and implementation context. - [NIST SP 800-53A Rev. 5](https://doi.org/10.6028/NIST.SP.800-53Ar5?ref=sorena.io) - Primary source for examine, interview, and test methods, common-control handling, and assessment findings. - [NIST SP 800-137](https://csrc.nist.gov/pubs/sp/800/137/final?ref=sorena.io) - Continuous monitoring guidance relevant to evidence freshness and ongoing assurance. ## Related Topic Guides - [NIST SP 800-53 Rev. 5 Compliance Playbook | Rev. 5 Operating Model](/artifacts/global/nist-sp-800-53-rev-5/compliance.md): Grounded playbook for SP 800-53 Rev. 5 covering integrated security and privacy controls, control ownership at organization mission and system levels. - [NIST SP 800-53 Rev. 5 Control Tailoring Method | SP 800-53B Guide](/artifacts/global/nist-sp-800-53-rev-5/control-tailoring-method.md): Grounded control tailoring method for SP 800-53 Rev. - [NIST SP 800-53 Rev. 5 FAQ | Practical Rev. 5 Questions](/artifacts/global/nist-sp-800-53-rev-5/faq.md): Practical FAQ on NIST SP 800-53 Rev. 5 covering federal and non-federal use, Rev. - [NIST SP 800-53 Rev. 5 vs ISO 27001 | Controls vs ISMS](/artifacts/global/nist-sp-800-53-rev-5/nist-800-53-vs-iso-27001.md): Grounded comparison of NIST SP 800-53 Rev. 5 and ISO 27001 covering control-catalog depth, ISMS governance, assessment style. - [NIST SP 800-53A Rev. 5 Assessment Procedures](/artifacts/global/nist-sp-800-53-rev-5/assessment-procedures-800-53a.md): Grounded guide to SP 800-53A Rev. 5 covering assessment objectives, determination statements, examine interview test methods, depth and coverage. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/evidence-and-audit-readiness --- --- title: "NIST SP 800-53 Rev. 5 FAQ" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/faq" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/faq" author: "Sorena AI" description: "Practical FAQ on NIST SP 800-53 Rev. 5 covering federal and non-federal use, Rev." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST 800-53 FAQ" - "Rev 5 changes" - "53A vs 53B" - "common controls" - "inherited controls" - "privacy controls" - "non federal use" - "GLOBAL compliance" - "NIST SP 800-53 Rev. 5" - "FAQ" - "Control assessment" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-53 Rev. 5 FAQ Practical FAQ on NIST SP 800-53 Rev. 5 covering federal and non-federal use, Rev. *FAQ* *GLOBAL* ## NIST SP 800-53 Rev. 5 FAQ Answers to the practical questions that slow down Rev. 5 implementation. Focused on tailoring, assessments, inheritance, privacy, and evidence. Teams usually get stuck on the same SP 800-53 questions: whether Rev. 5 is only for federal systems, what changed in the revision, how 53A and 53B fit with the main catalog, and how to manage common controls and evidence without creating false assurance. This FAQ answers those questions using the structure NIST actually uses. ## Is SP 800-53 only for U.S. federal systems It is federal guidance, but NIST designed the catalog to be flexible and customizable for many types of organizations and platforms. Private-sector and international teams often use it because of its depth, especially when they need a strong internal control architecture. Non-federal users still need to tailor the catalog to their legal obligations, risk tolerance, and operating model. - Use it as a control architecture, not as an untailored federal clone - Map it to applicable laws, contracts, and sector rules - Preserve rationale for exclusions, compensating controls, and added overlays ## What changed in Rev. 5 that matters most The most important changes are structural. NIST integrated security and privacy controls into one catalog, added the SR supply chain risk management family, and removed baselines and tailoring guidance from the main publication into SP 800-53B. Those changes affect how teams organize governance, select controls, and collaborate with privacy and supplier-risk stakeholders. - Integrated security and privacy control catalog - New supply chain risk management family - Baselines and tailoring moved to SP 800-53B - Assessment still handled through SP 800-53A, not the main catalog ## How do SP 800-53, 53A, and 53B fit together SP 800-53 is the control catalog. SP 800-53A explains how to assess those controls. SP 800-53B provides the starting baselines, tailoring guidance, and overlays used to build the selected control set. You need all three for a mature program: catalog, selection logic, and assessment rigor. - 53 defines what the control is - 53B helps decide whether and how the control applies - 53A explains how to test whether the applied control is effective ## How should we handle common controls and inheritance Inheritance only works when the provider and consumer responsibilities are clear and the evidence is actually available. SP 800-53A explicitly notes that systems relying on common controls cannot be treated as fully assessed until the common-control assessment results exist. That means common-control governance is a living dependency-management problem, not just a label in a spreadsheet. - Define each control as common, hybrid, or system-specific - Record provider, inheriting systems, evidence location, and reassessment triggers - Verify actual use of the inherited protection in the consuming system context ## What evidence should always be ready At minimum, keep current evidence for control implementation, control operation, assessment results, findings, remediation status, and tailoring decisions. The stronger the inheritance model, the more important provider-side evidence becomes. The goal is to support risk-based decisions, not merely to complete an audit request. - Policies, procedures, plans, and instantiated parameter values - Operational logs, configurations, review records, and monitoring outputs - Assessment results, plans of action, remediation verification, and current risk decisions *Recommended next step* *Placement: after the FAQ section* ## Use NIST SP 800-53 Rev. 5 FAQ as a cited research workflow Research Copilot can take NIST SP 800-53 Rev. 5 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on NIST SP 800-53 Rev. 5 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for NIST SP 800-53 Rev. 5 FAQ](/solutions/research-copilot.md): Start from NIST SP 800-53 Rev. 5 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through NIST SP 800-53 Rev. 5](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-53 Rev. 5 FAQ. ## Primary sources - [NIST SP 800-53 Rev. 5](https://doi.org/10.6028/NIST.SP.800-53r5?ref=sorena.io) - Primary source for the Rev. 5 control catalog and revision changes. - [NIST SP 800-53A Rev. 5](https://doi.org/10.6028/NIST.SP.800-53Ar5?ref=sorena.io) - Primary source for assessment methodology and inherited-control assessment mechanics. - [NIST SP 800-53B](https://doi.org/10.6028/NIST.SP.800-53B?ref=sorena.io) - Primary source for baselines, tailoring guidance, and overlays. ## Related Topic Guides - [NIST SP 800-53 Rev. 5 Compliance Playbook | Rev. 5 Operating Model](/artifacts/global/nist-sp-800-53-rev-5/compliance.md): Grounded playbook for SP 800-53 Rev. 5 covering integrated security and privacy controls, control ownership at organization mission and system levels. - [NIST SP 800-53 Rev. 5 Control Tailoring Method | SP 800-53B Guide](/artifacts/global/nist-sp-800-53-rev-5/control-tailoring-method.md): Grounded control tailoring method for SP 800-53 Rev. - [NIST SP 800-53 Rev. 5 Evidence and Audit Readiness](/artifacts/global/nist-sp-800-53-rev-5/evidence-and-audit-readiness.md): Grounded SP 800-53 evidence guide covering control-to-evidence mapping, common-control inheritance, freshness and sampling, assessment findings. - [NIST SP 800-53 Rev. 5 vs ISO 27001 | Controls vs ISMS](/artifacts/global/nist-sp-800-53-rev-5/nist-800-53-vs-iso-27001.md): Grounded comparison of NIST SP 800-53 Rev. 5 and ISO 27001 covering control-catalog depth, ISMS governance, assessment style. - [NIST SP 800-53A Rev. 5 Assessment Procedures](/artifacts/global/nist-sp-800-53-rev-5/assessment-procedures-800-53a.md): Grounded guide to SP 800-53A Rev. 5 covering assessment objectives, determination statements, examine interview test methods, depth and coverage. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/faq --- --- title: "NIST SP 800-53 Rev. 5 vs ISO 27001" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/nist-800-53-vs-iso-27001" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/nist-800-53-vs-iso-27001" author: "Sorena AI" description: "Grounded comparison of NIST SP 800-53 Rev. 5 and ISO 27001 covering control-catalog depth, ISMS governance, assessment style." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST 800-53 vs ISO 27001" - "control catalog vs ISMS" - "53A vs ISO audit" - "53B tailoring vs Statement of Applicability" - "evidence reuse" - "GLOBAL compliance" - "NIST SP 800-53 Rev. 5" - "ISO 27001" - "Framework mapping" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-53 Rev. 5 vs ISO 27001 Grounded comparison of NIST SP 800-53 Rev. 5 and ISO 27001 covering control-catalog depth, ISMS governance, assessment style. *Comparison* *GLOBAL* ## NIST SP 800-53 Rev. 5 vs ISO/IEC 27001 How to run NIST and ISO together without misunderstanding what each one is for. Designed for teams that need both deep controls and certifiable management-system governance. NIST SP 800-53 Rev. 5 and ISO 27001 are useful together, but they solve different parts of the problem. NIST gives a detailed control catalog with companion selection and assessment publications. ISO 27001 gives a certifiable information security management system with risk treatment, governance, and Annex A control references. Good dual-framework programs do not flatten those differences. They use them deliberately. ## The core difference is control architecture versus management system SP 800-53 is primarily a detailed control catalog used within a broader risk management approach. Rev. 5 adds integrated privacy and deeper supply chain content, and it relies on SP 800-53A and SP 800-53B for assessment and tailoring. ISO 27001 is primarily a management-system standard. It defines how an organization governs information security through scope, policy, risk treatment, internal audit, management review, and continual improvement. - NIST is stronger when you need detailed control granularity and formal assessment mechanics - ISO 27001 is stronger when you need a certifiable governance shell and management-system discipline - NIST uses 53A and 53B as companion publications; ISO uses risk treatment and the Statement of Applicability *Recommended next step* *Placement: after the comparison section* ## Use NIST SP 800-53 Rev. 5 vs ISO/IEC 27001 as a cited research workflow Research Copilot can take NIST SP 800-53 Rev. 5 vs ISO/IEC 27001 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on NIST SP 800-53 Rev. 5 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for NIST SP 800-53 Rev. 5 vs ISO/IEC 27001](/solutions/research-copilot.md): Start from NIST SP 800-53 Rev. 5 vs ISO/IEC 27001 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through NIST SP 800-53 Rev. 5](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-53 Rev. 5 vs ISO/IEC 27001. ## Tailoring and applicability are handled differently In the NIST model, you start from SP 800-53B baselines and tailor using overlays, scoping considerations, common-control decisions, and ODP values. In ISO 27001, you justify Annex A applicability and selected controls through the ISMS risk treatment process and the Statement of Applicability. Both require rationale, but the mechanics and document set are different. - NIST: baseline selection plus tailoring register and parameter values - ISO: risk treatment decisions plus Statement of Applicability - Both: documented rationale, ownership, and review when conditions change ## Assessment and audit style are not the same NIST SP 800-53A provides a method for assessing whether controls are implemented correctly, operating as intended, and producing the desired outcome. That is a detailed control-effectiveness model. ISO certification audits focus on whether the ISMS conforms to the standard and whether it is effective as a management system. The auditor may review control operation, but the audit structure is not the same as SP 800-53A. - Use 53A-style procedures where deep control testing is needed - Use ISO audit routines to demonstrate governance, risk treatment, and continual improvement - Do not assume passing one automatically proves the other ## The best operating model usually uses shared evidence with different views The efficiency gain comes from one internal control and evidence library that can serve both frameworks. Technical and operational evidence can support NIST controls, while the same evidence can be summarized through ISMS governance views for ISO 27001. The key is to preserve traceability so reviewers can move from a shared artifact to the specific NIST or ISO requirement it supports. - Use a canonical internal control library with NIST and ISO references - Keep one remediation backlog and one evidence index - Package evidence differently for 53A assessors and ISO auditors without duplicating the source artifacts - Review mappings whenever Rev. 5, 53A, 53B, or ISO guidance changes ## Primary sources - [NIST SP 800-53 Rev. 5](https://doi.org/10.6028/NIST.SP.800-53r5?ref=sorena.io) - Primary source for the NIST control catalog. - [NIST SP 800-53A Rev. 5](https://doi.org/10.6028/NIST.SP.800-53Ar5?ref=sorena.io) - Primary source for NIST control assessment methodology. - [NIST SP 800-53B](https://doi.org/10.6028/NIST.SP.800-53B?ref=sorena.io) - Primary source for NIST baselines and tailoring guidance. - [ISO/IEC 27001 standard page](https://www.iso.org/standard/27001?ref=sorena.io) - Official ISO page for the ISMS standard. ## Related Topic Guides - [NIST SP 800-53 Rev. 5 Compliance Playbook | Rev. 5 Operating Model](/artifacts/global/nist-sp-800-53-rev-5/compliance.md): Grounded playbook for SP 800-53 Rev. 5 covering integrated security and privacy controls, control ownership at organization mission and system levels. - [NIST SP 800-53 Rev. 5 Control Tailoring Method | SP 800-53B Guide](/artifacts/global/nist-sp-800-53-rev-5/control-tailoring-method.md): Grounded control tailoring method for SP 800-53 Rev. - [NIST SP 800-53 Rev. 5 Evidence and Audit Readiness](/artifacts/global/nist-sp-800-53-rev-5/evidence-and-audit-readiness.md): Grounded SP 800-53 evidence guide covering control-to-evidence mapping, common-control inheritance, freshness and sampling, assessment findings. - [NIST SP 800-53 Rev. 5 FAQ | Practical Rev. 5 Questions](/artifacts/global/nist-sp-800-53-rev-5/faq.md): Practical FAQ on NIST SP 800-53 Rev. 5 covering federal and non-federal use, Rev. - [NIST SP 800-53A Rev. 5 Assessment Procedures](/artifacts/global/nist-sp-800-53-rev-5/assessment-procedures-800-53a.md): Grounded guide to SP 800-53A Rev. 5 covering assessment objectives, determination statements, examine interview test methods, depth and coverage. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-53-rev-5/nist-800-53-vs-iso-27001 --- --- title: "NIST SP 800-61r3 Compliance Playbook" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3/compliance" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3/compliance" author: "Sorena AI" description: "Grounded incident-response playbook for NIST SP 800-61r3 covering the CSF 2.0 community-profile model, roles, risk-based incident management, communications." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST SP 800-61r3 compliance" - "CSF 2.0 incident response" - "incident management" - "response communication" - "incident mitigation" - "recovery criteria" - "NIST incident response governance" - "GLOBAL compliance" - "NIST SP 800-61r3" - "Incident response" - "CSF 2.0" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-61r3 Compliance Playbook Grounded incident-response playbook for NIST SP 800-61r3 covering the CSF 2.0 community-profile model, roles, risk-based incident management, communications. *Playbook* *GLOBAL* ## NIST SP 800-61r3 Compliance Build incident response as a continuous cybersecurity risk-management capability. Designed for SOC, IR, GRC, legal, privacy, business owners, recovery teams, and executive stakeholders. SP 800-61r3 shifts incident response away from the old model of a mostly separate technical lifecycle. Rev. 3 treats it as part of cybersecurity risk management across all six CSF 2.0 Functions. That means compliance is not only about detection and containment. It also includes governance, preparation, stakeholder coordination, evidence preservation, recovery sequencing, and rapid improvement based on lessons learned. ## Use the Rev. 3 incident model, not the old r2 mental model NIST explicitly says the scope changed significantly from r2 because static technical detail ages too quickly. Rev. 3 is organized as a CSF 2.0 community profile so organizations can use one common taxonomy and connect to wider implementation resources. The practical consequence is that Govern, Identify, and Protect are part of preparation, while Detect, Respond, and Recover handle active incidents, and Identify Improvement captures lessons learned across the whole system. - Treat preparation as broader cyber risk management, not as a narrow IR-only phase - Use Detect, Respond, and Recover for active response execution - Use Identify Improvement to push lessons learned back into all functions - Do not wait for a formal final postmortem before sharing important lessons ## Define cross-functional roles before the next incident NIST emphasizes that successful incident response now depends on many internal and external parties. Leadership, incident handlers, asset owners, legal, privacy, communications, human resources, facilities, suppliers, MSSPs, cloud providers, and law enforcement may all be involved depending on the incident. A practical program therefore needs pre-agreed decision rights, coordination paths, and notification responsibilities. - Designate incident handlers and consider assigning an incident lead for each significant incident - Define when asset owners and business owners shape response and recovery priorities - Predefine legal, privacy, media, supplier, and law-enforcement coordination points - Integrate business continuity and disaster recovery plans when incidents demand them ## Operationalize RS.MA, RS.AN, RS.CO, RS.MI, and RC The heart of Rev. 3 sits in its CSF categories. RS.MA covers incident management, RS.AN covers analysis, RS.CO covers reporting and communication, RS.MI covers mitigation, and RC covers recovery. Those categories are much more useful for implementation than generic lifecycle slogans. Teams should build procedures and ticket fields around those categories so the operational record mirrors the framework. - RS.MA: validate reports, categorize incidents, prioritize by risk, and decide when recovery starts - RS.AN: reconstruct what happened, identify root causes, estimate magnitude, and preserve investigation records - RS.CO: coordinate, notify, share information, and handle public communication by predefined rules - RS.MI and RC: contain, eradicate, restore, validate restored assets, and declare recovery complete against criteria ## Use records, evidence, and improvement loops as control mechanisms Rev. 3 explicitly calls for preserving the integrity and provenance of response records, incident data, and metadata. It also emphasizes that incident data is still evidence even when a full legal chain of custody is not needed. This means operational logging, ticketing, decision records, and after-action outputs are not just documentation. They are part of the control system. - Protect incident response records and limit access to authorized personnel - Preserve incident data and metadata using evidence-preservation and retention procedures - Use after-action reports to document response, recovery, and lessons learned - Convert lessons into updated detection logic, playbooks, controls, and training *Recommended next step* *Placement: after the compliance steps* ## Turn NIST SP 800-61r3 Compliance into an operational assessment Assessment Autopilot can take NIST SP 800-61r3 Compliance from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on NIST SP 800-61r3 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for NIST SP 800-61r3 Compliance](/solutions/assessment.md): Start from NIST SP 800-61r3 Compliance and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through NIST SP 800-61r3](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-61r3 Compliance. ## Primary sources - [NIST SP 800-61r3 - DOI](https://doi.org/10.6028/NIST.SP.800-61r3?ref=sorena.io) - Primary source for incident response recommendations and CSF 2.0 community profile guidance. - [NIST SP 800-61r3 publication page](https://csrc.nist.gov/pubs/sp/800/61/r3/final?ref=sorena.io) - Official publication details and related implementation resources. - [NIST CSF 2.0 (CSWP 29) - DOI](https://doi.org/10.6028/NIST.CSWP.29?ref=sorena.io) - Framework context used by SP 800-61r3 for organizing incident response outcomes. ## Related Topic Guides - [NIST SP 800-61r3 FAQ | Practical Incident Response Questions](/artifacts/global/nist-sp-800-61-rev-3/faq.md): Practical FAQ on NIST SP 800-61r3 covering what changed from r2, incident declaration, risk evaluation factors, containment versus observation. - [NIST SP 800-61r3 Incident Response Playbook Template](/artifacts/global/nist-sp-800-61-rev-3/incident-response-playbook-template.md): Grounded incident-response playbook template based on NIST SP 800-61r3 with incident criteria, incident lead, risk evaluation factors, communications tracks. - [NIST SP 800-61r3 Severity Classification and SLA Model](/artifacts/global/nist-sp-800-61-rev-3/severity-classification-and-sla-model.md): Grounded severity and SLA model for NIST SP 800-61r3 using NIST risk evaluation factors such as asset criticality, impact, scope, threat behavior. - [NIST SP 800-61r3 vs ISO 27035 | Incident Response Comparison](/artifacts/global/nist-sp-800-61-rev-3/nist-800-61-vs-iso-27035.md): Grounded comparison of NIST SP 800-61r3 and ISO 27035 covering the CSF 2.0 community-profile model, management-process structure, communications, recovery. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3/compliance --- --- title: "NIST SP 800-61r3 FAQ" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3/faq" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3/faq" author: "Sorena AI" description: "Practical FAQ on NIST SP 800-61r3 covering what changed from r2, incident declaration, risk evaluation factors, containment versus observation." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST SP 800-61r3 FAQ" - "incident declaration criteria" - "risk evaluation factors" - "containment versus observation" - "evidence integrity" - "incident notifications" - "recovery criteria" - "GLOBAL compliance" - "NIST SP 800-61r3" - "Incident response FAQ" - "CSF 2.0" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-61r3 FAQ Practical FAQ on NIST SP 800-61r3 covering what changed from r2, incident declaration, risk evaluation factors, containment versus observation. *FAQ* *GLOBAL* ## NIST SP 800-61r3 FAQ Answers to the operational questions that matter during real incidents. Focused on Rev. 3 changes, risk-based prioritization, evidence handling, and recovery. SP 800-61r3 raises practical questions that older incident-response guidance did not handle as directly: when to declare an incident, how to prioritize by risk, whether to delay containment for observation, what evidence needs stronger protection, and when recovery should begin or end. This FAQ answers those questions using NISTs actual Rev. 3 structure and recommendations. ## What changed most from SP 800-61r2 The biggest change is scope. Rev. 3 no longer tries to be a static procedural handbook for every technology. Instead, it provides recommendations and considerations for incorporating incident response throughout cybersecurity risk management as a CSF 2.0 community profile. That is why the document puts so much emphasis on all six CSF Functions and continuous improvement. - Published April 2025 and supersedes r2 from August 2012 - Moves from a narrow incident-handling focus to a broader cyber risk management model - Uses CSF 2.0 categories and subcategories as the organizing structure ## What should trigger incident declaration and escalation Rev. 3 says incidents are declared when adverse events meet defined incident criteria. Teams should not improvise these thresholds during a crisis. Escalation and prioritization should be based on risk evaluation factors instead of first-come-first-served handling. - Use predefined incident criteria and known false-positive patterns during declaration - Estimate severity and urgency during preliminary review - Base prioritization on factors such as asset criticality, functional impact, data impact, stage of activity, threat actor characterization, and recoverability ## Can we delay containment to observe an attacker Sometimes yes, but NIST warns that delaying containment to monitor an attacker can be dangerous because the attacker may escalate access or compromise additional systems. The document says the incident team should discuss that strategy with legal before executing it. - Use predefined criteria for investigative delay versus immediate containment - Document approvals and the business-risk tradeoff - Fall back to containment quickly if the risk exceeds tolerance ## Do we need full chain of custody for every incident No. Rev. 3 explicitly notes that formal evidence gathering and chain-of-custody procedures may not be used for every incident. However, collected incident data is still evidence. Even when prosecution is unlikely, teams should preserve integrity, provenance, and access control for incident records and data. - Protect records, evidence, and metadata from unauthorized access or alteration - Follow evidence-preservation and retention procedures appropriate to the incident - Scale formality by legal risk, regulatory risk, and likelihood of external investigation ## How should notification and information sharing work Rev. 3 separates communication into four categories: incident coordination, incident notification, public communication, and incident information sharing. Each needs its own procedures and approval paths. Organizations should perform notifications in line with current laws, regulations, contracts, and internal policy. - Define who is notified, when, and through which channel - Coordinate with affected third parties, regulators, and law enforcement where criteria require it - Use secure information-sharing methods and approved media procedures ## When should recovery start and finish Rev. 3 says recovery should start when incident recovery criteria are met, taking into account the possible operational disruption of the recovery actions themselves. Recovery ends when restoration criteria are met, restored assets are verified, normal operating status is confirmed, and the incident documentation is completed. - Select recovery actions based on timeliness, precision, reliability, and available resources - Verify restored assets for indicators of compromise before production use - Declare the end of recovery using predefined criteria and complete the after-action report *Recommended next step* *Placement: after the FAQ section* ## Use NIST SP 800-61r3 FAQ as a cited research workflow Research Copilot can take NIST SP 800-61r3 FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on NIST SP 800-61r3 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for NIST SP 800-61r3 FAQ](/solutions/research-copilot.md): Start from NIST SP 800-61r3 FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through NIST SP 800-61r3](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-61r3 FAQ. ## Primary sources - [NIST SP 800-61r3 - DOI](https://doi.org/10.6028/NIST.SP.800-61r3?ref=sorena.io) - Primary source for incident response recommendations and CSF 2.0 profile alignment. - [NIST SP 800-61r3 publication page](https://csrc.nist.gov/pubs/sp/800/61/r3/final?ref=sorena.io) - Official publication details, updates, and related resources. - [NIST CSF 2.0 (CSWP 29) - DOI](https://doi.org/10.6028/NIST.CSWP.29?ref=sorena.io) - Framework context referenced by SP 800-61r3. ## Related Topic Guides - [NIST SP 800-61r3 Compliance Playbook | CSF 2.0 Incident Response](/artifacts/global/nist-sp-800-61-rev-3/compliance.md): Grounded incident-response playbook for NIST SP 800-61r3 covering the CSF 2.0 community-profile model, roles, risk-based incident management, communications. - [NIST SP 800-61r3 Incident Response Playbook Template](/artifacts/global/nist-sp-800-61-rev-3/incident-response-playbook-template.md): Grounded incident-response playbook template based on NIST SP 800-61r3 with incident criteria, incident lead, risk evaluation factors, communications tracks. - [NIST SP 800-61r3 Severity Classification and SLA Model](/artifacts/global/nist-sp-800-61-rev-3/severity-classification-and-sla-model.md): Grounded severity and SLA model for NIST SP 800-61r3 using NIST risk evaluation factors such as asset criticality, impact, scope, threat behavior. - [NIST SP 800-61r3 vs ISO 27035 | Incident Response Comparison](/artifacts/global/nist-sp-800-61-rev-3/nist-800-61-vs-iso-27035.md): Grounded comparison of NIST SP 800-61r3 and ISO 27035 covering the CSF 2.0 community-profile model, management-process structure, communications, recovery. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3/faq --- --- title: "NIST SP 800-61r3 Incident Response Playbook Template" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3/incident-response-playbook-template" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3/incident-response-playbook-template" author: "Sorena AI" description: "Grounded incident-response playbook template based on NIST SP 800-61r3 with incident criteria, incident lead, risk evaluation factors, communications tracks." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST SP 800-61r3 playbook template" - "incident response playbook" - "incident lead template" - "risk evaluation factors" - "incident communication template" - "evidence handling template" - "recovery criteria" - "GLOBAL compliance" - "NIST SP 800-61r3" - "Playbook template" - "Incident response" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-61r3 Incident Response Playbook Template Grounded incident-response playbook template based on NIST SP 800-61r3 with incident criteria, incident lead, risk evaluation factors, communications tracks. *Template* *GLOBAL* ## NIST SP 800-61r3 Incident Response Playbook Template A playbook structure that matches the real Rev. 3 incident model. Use this as a base, then tailor it by incident type, asset criticality, and legal obligations. A strong playbook should reflect the structure NIST uses in Rev. 3. That means it needs more than containment and eradication steps. It should include incident declaration criteria, incident management, analysis, communication, mitigation, recovery, and evidence-preservation rules so the team can move quickly without losing control of decisions or records. ## Start each playbook with declaration and management fields The first section should capture whether the event meets incident criteria, who the incident lead is, how the incident is categorized, what the initial severity is, and which external plans or providers need to be activated. This mirrors the RS.MA category in Rev. 3 and prevents teams from starting technical action without governance context. - Incident criteria, incident type, declaration time, and incident lead - Initial risk evaluation factors such as asset criticality, impact, scope, and recoverability - Trigger points for MSSP, cloud provider, legal, privacy, or continuity-plan engagement - Recovery initiation criteria and decision authority *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep NIST SP 800-61r3 Incident Response Playbook Template in one governed evidence system SSOT can take NIST SP 800-61r3 Incident Response Playbook Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on NIST SP 800-61r3 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for NIST SP 800-61r3 Incident Response Playbook Template](/solutions/ssot.md): Start from NIST SP 800-61r3 Incident Response Playbook Template and keep documents, evidence, and control records in one governed system. - [Talk through NIST SP 800-61r3](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-61r3 Incident Response Playbook Template. ## Build analysis sections that preserve records and evidence quality The analysis section should help responders reconstruct what happened, estimate incident magnitude, and collect evidence without degrading integrity or provenance. Rev. 3 treats these as core investigation requirements. The template should therefore force structured recording, not optional notes. - Timeline of observed events, assets involved, and root-cause hypotheses - Investigation actions taken and by whom, with timestamps - Incident data and metadata collected, with integrity and provenance notes - Magnitude assessment, persistence checks, and search for spread to additional targets ## Separate communication into the four tracks NIST calls out Rev. 3 distinguishes incident coordination, incident notification, public communication, and incident information sharing. A good template gives each track its own decision point and record section. That separation reduces the common failure where teams treat every communication as one undifferentiated approval step. - Coordination log for internal and external response participants - Notification matrix for customers, employees, regulators, suppliers, and law enforcement - Public communication approvals and media messaging rules - Voluntary information-sharing fields for ISACs or other trusted communities ## Close with mitigation, recovery, and improvement checkpoints Containment and eradication actions should be recorded with rationale, including when automation or authorized third parties act on behalf of the organization. Recovery then needs criteria for restoration order, integrity verification, and declaring recovery complete. The template should end with an after-action section that turns lessons into concrete changes. - Containment and eradication actions, including reasons for any delayed action - Recovery actions selected, restored-asset verification, and return-to-normal checks - Criteria used to declare the end of recovery and close the incident - After-action report fields for lessons learned, remediation owners, and control updates ## Primary sources - [NIST SP 800-61r3 - DOI](https://doi.org/10.6028/NIST.SP.800-61r3?ref=sorena.io) - Primary source for incident response recommendations and response lifecycle concepts. - [NIST SP 800-61r3 publication page](https://csrc.nist.gov/pubs/sp/800/61/r3/final?ref=sorena.io) - Official publication details and related links. - [CISA Cybersecurity Incident & Vulnerability Response Playbooks](https://www.cisa.gov/sites/default/files/publications/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf?ref=sorena.io) - Reference playbook patterns for operational procedure design. ## Related Topic Guides - [NIST SP 800-61r3 Compliance Playbook | CSF 2.0 Incident Response](/artifacts/global/nist-sp-800-61-rev-3/compliance.md): Grounded incident-response playbook for NIST SP 800-61r3 covering the CSF 2.0 community-profile model, roles, risk-based incident management, communications. - [NIST SP 800-61r3 FAQ | Practical Incident Response Questions](/artifacts/global/nist-sp-800-61-rev-3/faq.md): Practical FAQ on NIST SP 800-61r3 covering what changed from r2, incident declaration, risk evaluation factors, containment versus observation. - [NIST SP 800-61r3 Severity Classification and SLA Model](/artifacts/global/nist-sp-800-61-rev-3/severity-classification-and-sla-model.md): Grounded severity and SLA model for NIST SP 800-61r3 using NIST risk evaluation factors such as asset criticality, impact, scope, threat behavior. - [NIST SP 800-61r3 vs ISO 27035 | Incident Response Comparison](/artifacts/global/nist-sp-800-61-rev-3/nist-800-61-vs-iso-27035.md): Grounded comparison of NIST SP 800-61r3 and ISO 27035 covering the CSF 2.0 community-profile model, management-process structure, communications, recovery. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3/incident-response-playbook-template --- --- title: "NIST SP 800-61r3 vs ISO 27035" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3/nist-800-61-vs-iso-27035" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3/nist-800-61-vs-iso-27035" author: "Sorena AI" description: "Grounded comparison of NIST SP 800-61r3 and ISO 27035 covering the CSF 2.0 community-profile model, management-process structure, communications, recovery." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST 800-61r3 vs ISO 27035" - "incident response framework comparison" - "CSF 2.0 community profile" - "ISO incident management" - "shared incident evidence" - "GLOBAL compliance" - "NIST SP 800-61r3" - "ISO/IEC 27035" - "Incident response comparison" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-61r3 vs ISO 27035 Grounded comparison of NIST SP 800-61r3 and ISO 27035 covering the CSF 2.0 community-profile model, management-process structure, communications, recovery. *Comparison* *GLOBAL* ## NIST SP 800-61r3 vs ISO/IEC 27035 How to align NIST Rev. 3 and ISO 27035 without flattening their real differences. For organizations using both NIST guidance and ISO-governed incident-management structures. NIST SP 800-61r3 and ISO 27035 are compatible, but they frame incident response differently. NIST Rev. 3 is a CSF 2.0 community profile that spreads incident-response considerations across governance, preparation, response, recovery, and improvement. ISO 27035 stays closer to a formal incident-management process and governance structure. Teams should use those differences intentionally instead of forcing one vocabulary onto the other. ## The main difference is profile-based guidance versus process standardization SP 800-61r3 is organized around the CSF 2.0 Functions and categories. It is strongest when you want a broad cyber-risk-management model that connects incident response to governance, detection, communications, and recovery. ISO 27035 is stronger when you want a more formal incident-management process structure aligned with ISO management-system thinking. - NIST Rev. 3: community profile and recommendation set mapped to CSF 2.0 - ISO 27035: structured process and governance guidance across the series - Both can support one operating model if terminology differences are mapped carefully *Recommended next step* *Placement: after the comparison section* ## Use NIST SP 800-61r3 vs ISO/IEC 27035 as a cited research workflow Research Copilot can take NIST SP 800-61r3 vs ISO/IEC 27035 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on NIST SP 800-61r3 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for NIST SP 800-61r3 vs ISO/IEC 27035](/solutions/research-copilot.md): Start from NIST SP 800-61r3 vs ISO/IEC 27035 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through NIST SP 800-61r3](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-61r3 vs ISO/IEC 27035. ## Operational depth differs in where it is expressed NIST Rev. 3 expresses operational depth through categories such as RS.MA, RS.AN, RS.CO, RS.MI, and RC.RP, plus linked external resources like SP 800-184 and CISA playbooks. ISO 27035 expresses depth more through its formal incident-management structure, governance expectations, and series-based decomposition. - Use NIST categories to organize tickets, playbooks, and evidence records - Use ISO governance language to align with wider ISMS and policy structures - Keep one shared severity, communication, and recovery model behind both ## Shared evidence works when you preserve both response detail and governance traceability Both frameworks benefit from a single evidence model containing incident timelines, decisions, communications, recovery records, and lessons learned. NIST adds strong emphasis on integrity and provenance of records and evidence. The same underlying artifacts can support both frameworks if they are tagged and packaged correctly. - Use one incident record with timestamps, owners, evidence links, and communication history - Preserve integrity and provenance for investigation actions, data, and metadata - Package the same artifacts differently for operational review versus formal audit or certification review ## A practical combined model uses one command system and one improvement loop The best combined model usually uses a single incident command structure, a single playbook library, and a single after-action process. NIST then provides the CSF 2.0-based organizing logic while ISO provides broader management-process discipline. This keeps teams fast during incidents and consistent during review. - Use one incident lead role, one escalation matrix, and one communications model - Use one remediation and lessons-learned backlog for both frameworks - Review mappings whenever Rev. 3, ISO 27035, or regulatory obligations change ## Primary sources - [NIST SP 800-61r3 - DOI](https://doi.org/10.6028/NIST.SP.800-61r3?ref=sorena.io) - Primary source for CSF 2.0-aligned incident response recommendations. - [NIST SP 800-61r3 publication page](https://csrc.nist.gov/pubs/sp/800/61/r3/final?ref=sorena.io) - Official source and supporting references. - [ISO/IEC 27035-1:2023 standard page](https://www.iso.org/standard/78973.html?ref=sorena.io) - ISO incident management principles and process baseline. ## Related Topic Guides - [NIST SP 800-61r3 Compliance Playbook | CSF 2.0 Incident Response](/artifacts/global/nist-sp-800-61-rev-3/compliance.md): Grounded incident-response playbook for NIST SP 800-61r3 covering the CSF 2.0 community-profile model, roles, risk-based incident management, communications. - [NIST SP 800-61r3 FAQ | Practical Incident Response Questions](/artifacts/global/nist-sp-800-61-rev-3/faq.md): Practical FAQ on NIST SP 800-61r3 covering what changed from r2, incident declaration, risk evaluation factors, containment versus observation. - [NIST SP 800-61r3 Incident Response Playbook Template](/artifacts/global/nist-sp-800-61-rev-3/incident-response-playbook-template.md): Grounded incident-response playbook template based on NIST SP 800-61r3 with incident criteria, incident lead, risk evaluation factors, communications tracks. - [NIST SP 800-61r3 Severity Classification and SLA Model](/artifacts/global/nist-sp-800-61-rev-3/severity-classification-and-sla-model.md): Grounded severity and SLA model for NIST SP 800-61r3 using NIST risk evaluation factors such as asset criticality, impact, scope, threat behavior. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3/nist-800-61-vs-iso-27035 --- --- title: "NIST SP 800-61r3 Severity Classification and SLA Model" canonical_url: "https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3/severity-classification-and-sla-model" source_url: "https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3/severity-classification-and-sla-model" author: "Sorena AI" description: "Grounded severity and SLA model for NIST SP 800-61r3 using NIST risk evaluation factors such as asset criticality, impact, scope, threat behavior." published_at: "2026-03-04" updated_at: "2026-03-04" keywords: - "NIST SP 800-61r3 severity model" - "risk evaluation factors" - "asset criticality" - "recoverability" - "incident triage" - "response SLA" - "recovery initiation criteria" - "GLOBAL compliance" - "NIST SP 800-61r3" - "Severity model" - "Incident SLA" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # NIST SP 800-61r3 Severity Classification and SLA Model Grounded severity and SLA model for NIST SP 800-61r3 using NIST risk evaluation factors such as asset criticality, impact, scope, threat behavior. *Prioritization* *GLOBAL* ## NIST SP 800-61r3 Severity Classification and SLA Model A severity model built from the risk factors NIST Rev. 3 actually names. Designed to improve prioritization, escalation, and recovery timing decisions. SP 800-61r3 says incidents should not be handled on a first-come, first-served basis. Instead, incident triage, prioritization, escalation, elevation, and decisions on when to initiate recovery should be based on risk evaluation factors. A usable severity and SLA model should therefore reflect those factors directly rather than relying on arbitrary severity labels. ## Base severity on the Rev. 3 risk evaluation factors NIST gives concrete examples of risk evaluation factors in RS.MA, including asset criticality, functional impact, data impact, stage of observed activity, threat actor characterization, and recoverability. Those factors are better building blocks for severity than generic medium-high labels alone. Teams should score or describe these factors explicitly during triage so later reviewers can see why the incident received its initial priority. - Asset criticality and mission importance - Functional impact and operational disruption - Data impact, including sensitivity and likely exposure - Stage of activity, threat behavior, and recoverability ## Map severity to response, escalation, and recovery decisions Severity should drive more than acknowledgment times. It should determine who is involved, how quickly validation happens, whether recovery planning begins immediately, and how often leadership updates are provided. A high-severity incident may still need a measured containment approach if observation is justified, but that decision should be explicit and approved. - Critical: immediate incident lead assignment, rapid validation, containment, and leadership coordination - High: accelerated triage, cross-team involvement, and defined legal or privacy review windows - Medium: scheduled response with monitored status and explicit reassessment triggers - Low: monitored handling with escalation if impact, scope, or evidence quality changes ## Use SLAs as internal operating targets, not as substitutes for judgment NIST does not prescribe universal timing numbers. That is appropriate because organizations have different resources and risk tolerances. The important point is to link timing targets to the same risk evaluation factors used in prioritization. This keeps the SLA model defensible when incidents vary widely in scope and complexity. - Set response targets for validation, containment start, recovery decision, and stakeholder update cadence - Allow justified overrides when new evidence changes magnitude or recoverability - Require documented rationale for severity changes and missed targets ## Measure severity quality, not just speed A severity model is only useful if it improves decisions. Review whether incidents were under-classified, over-classified, or reclassified too often, and whether recovery started too early or too late. These measures help refine the model as threats, technology, and dependencies change. - Track reclassification rates and reasons - Track SLA attainment by severity tier - Track whether magnitude estimates were later proven too low or too high - Track whether lessons learned changed scoring criteria or recovery thresholds *Recommended next step* *Placement: after the scope or definition section* ## Use NIST SP 800-61r3 Severity Classification and SLA Model as a cited research workflow Research Copilot can take NIST SP 800-61r3 Severity Classification and SLA Model from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on NIST SP 800-61r3 can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for NIST SP 800-61r3 Severity Classification and SLA Model](/solutions/research-copilot.md): Start from NIST SP 800-61r3 Severity Classification and SLA Model and answer scope, timing, and interpretation questions with cited outputs. - [Talk through NIST SP 800-61r3](/contact.md): Review your current process, evidence gaps, and next steps for NIST SP 800-61r3 Severity Classification and SLA Model. ## Primary sources - [NIST SP 800-61r3 - DOI](https://doi.org/10.6028/NIST.SP.800-61r3?ref=sorena.io) - Primary source for incident triage, prioritization, and response management considerations. - [NIST SP 800-61r3 publication page](https://csrc.nist.gov/pubs/sp/800/61/r3/final?ref=sorena.io) - Official publication details and additional resources. - [NIST CSF 2.0 (CSWP 29) - DOI](https://doi.org/10.6028/NIST.CSWP.29?ref=sorena.io) - Framework context for outcomes used in incident response prioritization. ## Related Topic Guides - [NIST SP 800-61r3 Compliance Playbook | CSF 2.0 Incident Response](/artifacts/global/nist-sp-800-61-rev-3/compliance.md): Grounded incident-response playbook for NIST SP 800-61r3 covering the CSF 2.0 community-profile model, roles, risk-based incident management, communications. - [NIST SP 800-61r3 FAQ | Practical Incident Response Questions](/artifacts/global/nist-sp-800-61-rev-3/faq.md): Practical FAQ on NIST SP 800-61r3 covering what changed from r2, incident declaration, risk evaluation factors, containment versus observation. - [NIST SP 800-61r3 Incident Response Playbook Template](/artifacts/global/nist-sp-800-61-rev-3/incident-response-playbook-template.md): Grounded incident-response playbook template based on NIST SP 800-61r3 with incident criteria, incident lead, risk evaluation factors, communications tracks. - [NIST SP 800-61r3 vs ISO 27035 | Incident Response Comparison](/artifacts/global/nist-sp-800-61-rev-3/nist-800-61-vs-iso-27035.md): Grounded comparison of NIST SP 800-61r3 and ISO 27035 covering the CSF 2.0 community-profile model, management-process structure, communications, recovery. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/nist-sp-800-61-rev-3/severity-classification-and-sla-model --- --- title: "ANPD Enforcement and Fines" canonical_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines" source_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines" author: "Sorena AI" description: "Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "ANPD enforcement" - "Brazil LGPD fines" - "ANPD inspection process" - "Resolution 1 2021 ANPD" - "Resolution 4 2023 ANPD" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ANPD Enforcement and Fines Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No. *Enforcement Guide* *Inspection and Sanctions* ## ANPD Enforcement and Fines Prepare for supervision before a case exists. The strongest defense is a current evidence file that shows scope analysis, rights handling, incident response, transfer controls, and prompt corrective action. ANPD enforcement is not only about the final fine. It begins with supervisory interaction, evidence requests, corrective measures, and process discipline under the inspection and sanctioning framework, then moves into the sanctions ladder and dosimetry analysis when ANPD finds an infringement. ## Expect procedure before penalty ANPD uses a fiscalization and sanctioning process framework that gives structure to inspection, preventive measures, corrective measures, and later sanctions. Organizations that answer quickly and coherently have a better chance to control escalation. Your case file should therefore be built for external review from the first rights complaint, incident, or transfer question. - Keep a designated regulator-response owner - Store the law, facts, and control evidence in one case folder - Record every remedial commitment and completion date ## Know what will shape sanctions severity When ANPD moves into sanctions, Article 52 and the dosimetry regulation focus on gravity, harm, recurrence, cooperation, governance, internal mechanisms to minimize damage, and prompt corrective action. That means the quality of your remediation response can materially change the outcome even when a violation exists. - Show good faith and cooperation with current records - Prove the existence of governance and security mechanisms before the case - Demonstrate prompt corrective action after the issue was found ## Prepare the evidence ANPD is likely to ask for The exact request varies by case, but recurring themes are scope rationale, lawful basis, request logs, DPO disclosure, incident chronology, transfer mechanism documentation, and remediation governance. Weak or contradictory evidence often does more damage than a bad fact pattern because it suggests the organization does not actually control the processing. - Processing records and role matrix - Rights workflow logs and denial rationale - Incident timeline and communications - Transfer register, clause set, and disclosures - Committee minutes and remediation closure proof ## Use post-case learning to harden the program A mature LGPD program treats every supervisory interaction as a test of the operating model. The right output is not only case closure, but also a stronger control system. Feed every enforcement lesson back into training, templates, monitoring, and board reporting. - Update templates and playbooks after each major issue - Refresh owner training where evidence failed - Track repeated weakness patterns so they do not become recurrence evidence *Recommended next step* *Placement: after the enforcement section* ## Use ANPD Enforcement and Fines as a cited research workflow Research Copilot can take ANPD Enforcement and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on ANPD Enforcement can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for ANPD Enforcement and Fines](/solutions/research-copilot.md): Start from ANPD Enforcement and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through ANPD Enforcement](/contact.md): Review your current process, evidence gaps, and next steps for ANPD Enforcement and Fines. ## Primary sources - [Lei No. 13.709/2018 (LGPD)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm?ref=sorena.io) - Primary legal text for Article 52 and ANPD competence provisions. - [Resolution CD/ANPD No. 4/2023](https://www.in.gov.br/web/dou/-/resolucao-cd/anpd-n-4-de-24-de-fevereiro-de-2023-466146077?ref=sorena.io) - Official ANPD dosimetry and sanctions rule. - [Resolution CD/ANPD No. 2/2022](https://www.in.gov.br/en/web/dou/-/resolucao-cd/anpd-n-2-de-27-de-janeiro-de-2022-376562019?ref=sorena.io) - Official ANPD rule for small-scale processing agents referenced in procedural and sanctions contexts. ## Related Topic Guides - [Brazil LGPD Applicability Test | Article 3 Scope, Article 4 Exclusions, Roles](/artifacts/latam/brazil-lgpd/applicability-test.md): Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation. - [Brazil LGPD Checklist | Scope, Rights, Incidents, Transfers, Evidence](/artifacts/latam/brazil-lgpd/checklist.md): Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting. - [Brazil LGPD Compliance Program Guide](/artifacts/latam/brazil-lgpd/compliance.md): Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence. - [Brazil LGPD Data Subject Rights | Articles 18 to 20 and 15 Day Access Rule](/artifacts/latam/brazil-lgpd/data-subject-rights.md): Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days. - [Brazil LGPD Deadlines and Compliance Calendar](/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar.md): Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training. - [Brazil LGPD DSAR Response Template | Immediate and 15 Day Response Logic](/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template.md): Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale. - [Brazil LGPD FAQ | Scope, Rights, Incidents, Transfers, Enforcement](/artifacts/latam/brazil-lgpd/faq.md): Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance. - [Brazil LGPD Incident Reporting and Breach Notification](/artifacts/latam/brazil-lgpd/breach-notification.md): Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No. - [Brazil LGPD International Transfers | Articles 33 to 35 and ANPD Transfer Mechanisms](/artifacts/latam/brazil-lgpd/international-transfers.md): Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules. - [Brazil LGPD Lawful Bases | Article 7, Article 11, Legitimate Interest](/artifacts/latam/brazil-lgpd/lawful-bases.md): Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data. - [Brazil LGPD Penalties and Fines | Article 52 and ANPD Dosimetry](/artifacts/latam/brazil-lgpd/penalties-and-fines.md): Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion. - [Brazil LGPD Requirements | Articles, Controls, Evidence, and ANPD Guidance](/artifacts/latam/brazil-lgpd/requirements.md): Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers. - [Brazil LGPD Templates | DSAR, Incident, Basis, Transfer, Governance](/artifacts/latam/brazil-lgpd/templates.md): Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments. - [Brazil LGPD vs CCPA and CPRA | Structure, Rights, Enforcement, and Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa.md): Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls. - [Brazil LGPD vs GDPR | Similarities, Differences, and Control Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr.md): Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines --- --- title: "Brazil LGPD Applicability Test" canonical_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/applicability-test" source_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/applicability-test" author: "Sorena AI" description: "Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Brazil LGPD applicability test" - "Article 3 LGPD" - "Article 4 LGPD" - "controller operator Brazil LGPD" - "LGPD territorial scope" - "Brazil LGPD applicability" - "controller operator LGPD" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Brazil LGPD Applicability Test Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation. *Scope Guide* *Articles 3 and 4* ## Brazil LGPD Applicability Test Run Article 3 territorial scope and Article 4 exclusions before you launch controls. A correct LGPD program starts with processing facts, entity reach, and role allocation, not with a generic privacy checklist. Article 3 makes LGPD apply regardless of headquarters location when processing is carried out in Brazil, goods or services are offered to individuals located in Brazil, or personal data is collected in Brazil. Article 4 then removes specific private, journalistic, artistic, academic, public security, national defense, state security, and criminal investigation contexts from the general LGPD regime. ## Step 1: Confirm there is personal data processing in scope of the law LGPD covers any processing operation involving personal data of a natural person, in digital or physical form. Start by identifying the actual processing operations, not only the product name or contract label. If the activity only handles anonymized data that cannot reasonably be re-identified, the scope analysis may narrow. If identifiable telemetry, support records, HR data, or user content remain, continue the test. - Map the natural persons whose data is processed - List the systems, vendors, and business functions involved - Separate personal data from truly anonymized datasets ## Step 2: Apply Article 3 territorial reach in order LGPD can apply even when the controller is outside Brazil. The decisive questions are where the operation occurs, whether the business offers or supplies goods or services to people located in Brazil, and whether the personal data was collected in Brazil. Foreign groups often fail this step by focusing only on corporate domicile. Article 3 is designed to reach processing that materially targets or involves people in Brazil. - Processing carried out in Brazil is enough to trigger Article 3 - Offering or supplying goods or services to people located in Brazil can trigger LGPD even from abroad - Collection of personal data in Brazil can also trigger the law regardless of server location ## Step 3: Test Article 4 exclusions carefully Article 4 exclusions are specific and should not be stretched. Private non-economic household activity, journalistic and artistic activity, academic activity with Articles 7 and 11 still relevant, and certain public security or criminal enforcement contexts are outside the ordinary LGPD track. A business cannot claim an exclusion just because one department has a public function or because a dataset is later reused for research. The actual purpose and legal context of the processing matter. - Document the exact exclusion claimed and the facts supporting it - Test mixed-use programs separately where only part of the activity may be excluded - Reassess exclusions when the same data moves into a commercial or operational workflow ## Step 4: Allocate controller, operator, and joint control roles The ANPD agents guide treats the controller as the party that makes the essential decisions on purpose and means, while the operator acts according to the controller instructions. Shared or joint decision patterns can produce joint controllership for part of a flow. Role labels in the contract help, but the factual allocation of decision-making authority matters more than contract vocabulary. - Identify who defines purpose, key means, and retention logic - Identify processors, suboperators, and onward vendor chains - Record role allocation by processing activity, not only by master agreement *Recommended next step* *Placement: after the applicability result* ## Turn Brazil LGPD Applicability Test into an operational assessment Assessment Autopilot can take Brazil LGPD Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on Brazil LGPD can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Brazil LGPD Applicability Test](/solutions/assessment.md): Start from Brazil LGPD Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Brazil LGPD](/contact.md): Review your current process, evidence gaps, and next steps for Brazil LGPD Applicability Test. ## Primary sources - [Lei No. 13.709/2018 (LGPD)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm?ref=sorena.io) - Primary legal text for Articles 3, 4, 5, 23, 39, and related scope rules. - [ANPD guide for controllers, processors, and DPOs (May 2021)](https://www.gov.br/anpd/pt-br/documentos-e-publicacoes/2021.05.27GuiaAgentesdeTratamento_Final.pdf?ref=sorena.io) - Official ANPD guide on controller, operator, suboperator, and DPO role allocation. - [Resolution CD/ANPD No. 2/2022](https://www.in.gov.br/en/web/dou/-/resolucao-cd/anpd-n-2-de-27-de-janeiro-de-2022-376562019?ref=sorena.io) - Official ANPD rule for small-scale processing agents and high-risk processing criteria. ## Related Topic Guides - [ANPD Enforcement and Fines | Brazil LGPD Inspection, Procedure, and Sanctions](/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines.md): Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No. - [Brazil LGPD Checklist | Scope, Rights, Incidents, Transfers, Evidence](/artifacts/latam/brazil-lgpd/checklist.md): Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting. - [Brazil LGPD Compliance Program Guide](/artifacts/latam/brazil-lgpd/compliance.md): Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence. - [Brazil LGPD Data Subject Rights | Articles 18 to 20 and 15 Day Access Rule](/artifacts/latam/brazil-lgpd/data-subject-rights.md): Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days. - [Brazil LGPD Deadlines and Compliance Calendar](/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar.md): Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training. - [Brazil LGPD DSAR Response Template | Immediate and 15 Day Response Logic](/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template.md): Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale. - [Brazil LGPD FAQ | Scope, Rights, Incidents, Transfers, Enforcement](/artifacts/latam/brazil-lgpd/faq.md): Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance. - [Brazil LGPD Incident Reporting and Breach Notification](/artifacts/latam/brazil-lgpd/breach-notification.md): Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No. - [Brazil LGPD International Transfers | Articles 33 to 35 and ANPD Transfer Mechanisms](/artifacts/latam/brazil-lgpd/international-transfers.md): Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules. - [Brazil LGPD Lawful Bases | Article 7, Article 11, Legitimate Interest](/artifacts/latam/brazil-lgpd/lawful-bases.md): Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data. - [Brazil LGPD Penalties and Fines | Article 52 and ANPD Dosimetry](/artifacts/latam/brazil-lgpd/penalties-and-fines.md): Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion. - [Brazil LGPD Requirements | Articles, Controls, Evidence, and ANPD Guidance](/artifacts/latam/brazil-lgpd/requirements.md): Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers. - [Brazil LGPD Templates | DSAR, Incident, Basis, Transfer, Governance](/artifacts/latam/brazil-lgpd/templates.md): Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments. - [Brazil LGPD vs CCPA and CPRA | Structure, Rights, Enforcement, and Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa.md): Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls. - [Brazil LGPD vs GDPR | Similarities, Differences, and Control Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr.md): Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam/brazil-lgpd/applicability-test --- --- title: "Brazil LGPD Incident Reporting and Breach Notification" canonical_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/breach-notification" source_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/breach-notification" author: "Sorena AI" description: "Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Brazil LGPD incident reporting" - "Article 48 LGPD" - "ANPD Resolution 15 2024" - "3 business day breach notification" - "ANPD incident form" - "3 business day incident rule" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Brazil LGPD Incident Reporting and Breach Notification Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No. *Incident Guide* *Article 48 and Resolution 15/2024* ## Brazil LGPD Incident Reporting Build the incident workflow around Article 48 and the current ANPD reporting rule. If the incident can create relevant risk or damage, the timing, content, and evidence trail now matter as much as the technical response. Article 48 requires the controller to notify ANPD and the affected data subjects when a security incident can create relevant risk or damage. The current ANPD incident communication flow uses a 3 business day deadline, allows preliminary communication when facts are still being established, and requires complement information within 20 business days. ## Start with the Article 48 threshold, not with panic notifications Not every security event is reportable. The threshold is an incident involving personal data that can create relevant risk or damage to data subjects. Your first decision record should therefore document the affected data, the likely consequences, whether confidentiality, integrity, or availability was compromised, and who approved the risk conclusion. - Separate confirmed personal data incidents from ordinary IT outages - Assess risk to rights and freedoms, not only business impact - Document the legal and technical rationale for notify or do not notify decisions *Recommended next step* *Placement: after the workflow or playbook section* ## Turn Brazil LGPD Incident Reporting into an operational assessment Assessment Autopilot can take Brazil LGPD Incident Reporting from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on Brazil LGPD can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Brazil LGPD Incident Reporting](/solutions/assessment.md): Start from Brazil LGPD Incident Reporting and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Brazil LGPD](/contact.md): Review your current process, evidence gaps, and next steps for Brazil LGPD Incident Reporting. ## Run the 3 business day communication clock with one case record The ANPD incident form and the transfer regulation annexes both reflect the current 3 business day communication rule under Resolution CD ANPD No. 15 of 24 April 2024. Teams need one record that shows when the incident occurred, when the controller learned of it, when ANPD was notified, and when data subjects were notified. Operator notice to the controller is a critical upstream dependency. If the operator is late or incomplete, preserve that evidence because it affects the controller timeline and vendor oversight record. - Timestamp occurrence, awareness, containment, ANPD notice, and data subject notice - Collect operator facts early and preserve vendor correspondence - Prepare a justification record if the 3 business day window cannot be met ## Use preliminary communication correctly The ANPD form supports a preliminary communication when all facts are not yet available or data subject communication has not yet occurred. That is a controlled exception, not a substitute for closing the investigation later. A preliminary communication must be followed by a complement submission in 20 business days, in the same process, with the missing facts and the final risk assessment. - Reserve preliminary communication for justified information gaps - Track the 20 business day complement deadline from the first communication date - Keep the preliminary and complementary filings tied to one case file ## Prepare the content ANPD and data subjects expect The current ANPD form expects controller identity, DPO or representative information, operator data when relevant, risk evaluation, incident type, affected categories of data and data subjects, likely consequences, and mitigation actions. Data subject communications should use clear language and explain what happened, what data was affected, the risks, the mitigation measures, and how to contact the controller for more information. - Keep a standard evidence pack with facts, risk analysis, communications, and remediation actions - Retain copies of the message actually sent to affected data subjects - Add post-incident control hardening and validation to the final case closure file ## Primary sources - [Lei No. 13.709/2018 (LGPD)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm?ref=sorena.io) - Primary legal text for Article 48 and related accountability duties. - [ANPD incident communication page](https://www.gov.br/anpd/pt-br/assuntos/incidente-de-seguranca?ref=sorena.io) - Official ANPD guidance page for incident assessment and communication. - [ANPD guide on information security for small-scale processing agents](https://www.gov.br/anpd/pt-br/documentos-e-publicacoes/guia_seguran%C3%A7a_da_informacao_para_atppss__defeso_eleitoral.pdf?ref=sorena.io) - Official ANPD guidance on security controls, training, access control, and incident-aware safeguards. ## Related Topic Guides - [ANPD Enforcement and Fines | Brazil LGPD Inspection, Procedure, and Sanctions](/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines.md): Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No. - [Brazil LGPD Applicability Test | Article 3 Scope, Article 4 Exclusions, Roles](/artifacts/latam/brazil-lgpd/applicability-test.md): Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation. - [Brazil LGPD Checklist | Scope, Rights, Incidents, Transfers, Evidence](/artifacts/latam/brazil-lgpd/checklist.md): Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting. - [Brazil LGPD Compliance Program Guide](/artifacts/latam/brazil-lgpd/compliance.md): Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence. - [Brazil LGPD Data Subject Rights | Articles 18 to 20 and 15 Day Access Rule](/artifacts/latam/brazil-lgpd/data-subject-rights.md): Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days. - [Brazil LGPD Deadlines and Compliance Calendar](/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar.md): Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training. - [Brazil LGPD DSAR Response Template | Immediate and 15 Day Response Logic](/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template.md): Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale. - [Brazil LGPD FAQ | Scope, Rights, Incidents, Transfers, Enforcement](/artifacts/latam/brazil-lgpd/faq.md): Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance. - [Brazil LGPD International Transfers | Articles 33 to 35 and ANPD Transfer Mechanisms](/artifacts/latam/brazil-lgpd/international-transfers.md): Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules. - [Brazil LGPD Lawful Bases | Article 7, Article 11, Legitimate Interest](/artifacts/latam/brazil-lgpd/lawful-bases.md): Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data. - [Brazil LGPD Penalties and Fines | Article 52 and ANPD Dosimetry](/artifacts/latam/brazil-lgpd/penalties-and-fines.md): Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion. - [Brazil LGPD Requirements | Articles, Controls, Evidence, and ANPD Guidance](/artifacts/latam/brazil-lgpd/requirements.md): Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers. - [Brazil LGPD Templates | DSAR, Incident, Basis, Transfer, Governance](/artifacts/latam/brazil-lgpd/templates.md): Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments. - [Brazil LGPD vs CCPA and CPRA | Structure, Rights, Enforcement, and Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa.md): Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls. - [Brazil LGPD vs GDPR | Similarities, Differences, and Control Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr.md): Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam/brazil-lgpd/breach-notification --- --- title: "Brazil LGPD Checklist" canonical_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/checklist" source_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/checklist" author: "Sorena AI" description: "Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Brazil LGPD checklist" - "LGPD audit checklist" - "ANPD readiness checklist" - "Brazil privacy controls" - "LGPD evidence checklist" - "ANPD evidence checklist" - "privacy checklist Brazil" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Brazil LGPD Checklist Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting. *Checklist* *Audit Ready Controls* ## Brazil LGPD Checklist Use the checklist to test whether the program can actually operate under scrutiny. Each line should end in a named owner, current evidence, and a clear pass or fail state. A useful LGPD checklist checks operational proof, not only document existence. The control should point to the article or ANPD expectation, the evidence location, and the person who can explain how it works today. ## Scope and governance checklist Start with the controls that explain why the organization believes LGPD applies and who is accountable for which processing decisions. - Article 3 and 4 scope memo exists and is current - Controller, operator, and suboperator roles are mapped by processing activity - DPO appointment is formalized and contact details are published - Processing records exist, especially for legitimate-interest processing *Recommended next step* *Placement: after the checklist block* ## Turn Brazil LGPD Checklist into an operational assessment Assessment Autopilot can take Brazil LGPD Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on Brazil LGPD can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Brazil LGPD Checklist](/solutions/assessment.md): Start from Brazil LGPD Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Brazil LGPD](/contact.md): Review your current process, evidence gaps, and next steps for Brazil LGPD Checklist. ## Lawful basis and transparency checklist The lawful basis register and the external notices need to stay aligned when products, vendors, or purposes change. - Every purpose has a recorded Article 7 or 11 basis - Consent proof exists where consent is used and withdrawal is easy - Legitimate-interest cases have a retained balancing record - Children and adolescents processing has a documented best-interest assessment ## Rights, incident, and transfer checklist These are the domains that create the most visible regulator and complaint risk when they fail. - Rights workflow supports immediate simplified responses and the 15 day complete declaration path - Incident workflow supports the 3 business day notification clock and the 20 business day complement path - Transfer register exists with mechanism, country, contract, and disclosure status - Shared-use corrections, deletions, anonymization, and blocking notifications are tracked ## Evidence and sanctions checklist Article 52 and the ANPD dosimetry rule make good-faith prevention and prompt corrective action legally relevant. - Control testing is scheduled and results are retained - Exceptions and remediation items have owners and due dates - Incident, rights, and transfer evidence is current and easy to retrieve - Management review records show cooperation, corrective action, and governance follow-through ## Primary sources - [Lei No. 13.709/2018 (LGPD)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm?ref=sorena.io) - Primary legal text for the checklist control domains. - [ANPD guide for controllers, processors, and DPOs (May 2021)](https://www.gov.br/anpd/pt-br/documentos-e-publicacoes/2021.05.27GuiaAgentesdeTratamento_Final.pdf?ref=sorena.io) - Official ANPD guide for role and DPO checklist items. - [Resolution CD/ANPD No. 4/2023](https://www.in.gov.br/web/dou/-/resolucao-cd/anpd-n-4-de-24-de-fevereiro-de-2023-466146077?ref=sorena.io) - Official ANPD rule relevant to sanctions-ready evidence. ## Related Topic Guides - [ANPD Enforcement and Fines | Brazil LGPD Inspection, Procedure, and Sanctions](/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines.md): Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No. - [Brazil LGPD Applicability Test | Article 3 Scope, Article 4 Exclusions, Roles](/artifacts/latam/brazil-lgpd/applicability-test.md): Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation. - [Brazil LGPD Compliance Program Guide](/artifacts/latam/brazil-lgpd/compliance.md): Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence. - [Brazil LGPD Data Subject Rights | Articles 18 to 20 and 15 Day Access Rule](/artifacts/latam/brazil-lgpd/data-subject-rights.md): Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days. - [Brazil LGPD Deadlines and Compliance Calendar](/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar.md): Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training. - [Brazil LGPD DSAR Response Template | Immediate and 15 Day Response Logic](/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template.md): Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale. - [Brazil LGPD FAQ | Scope, Rights, Incidents, Transfers, Enforcement](/artifacts/latam/brazil-lgpd/faq.md): Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance. - [Brazil LGPD Incident Reporting and Breach Notification](/artifacts/latam/brazil-lgpd/breach-notification.md): Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No. - [Brazil LGPD International Transfers | Articles 33 to 35 and ANPD Transfer Mechanisms](/artifacts/latam/brazil-lgpd/international-transfers.md): Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules. - [Brazil LGPD Lawful Bases | Article 7, Article 11, Legitimate Interest](/artifacts/latam/brazil-lgpd/lawful-bases.md): Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data. - [Brazil LGPD Penalties and Fines | Article 52 and ANPD Dosimetry](/artifacts/latam/brazil-lgpd/penalties-and-fines.md): Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion. - [Brazil LGPD Requirements | Articles, Controls, Evidence, and ANPD Guidance](/artifacts/latam/brazil-lgpd/requirements.md): Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers. - [Brazil LGPD Templates | DSAR, Incident, Basis, Transfer, Governance](/artifacts/latam/brazil-lgpd/templates.md): Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments. - [Brazil LGPD vs CCPA and CPRA | Structure, Rights, Enforcement, and Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa.md): Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls. - [Brazil LGPD vs GDPR | Similarities, Differences, and Control Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr.md): Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam/brazil-lgpd/checklist --- --- title: "Brazil LGPD Compliance Program Guide" canonical_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/compliance" source_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/compliance" author: "Sorena AI" description: "Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Brazil LGPD compliance program" - "ANPD compliance" - "LGPD operating model" - "Brazil privacy governance" - "LGPD evidence" - "Brazil LGPD compliance" - "ANPD program" - "privacy governance Brazil" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Brazil LGPD Compliance Program Guide Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence. *Program Guide* *Operating Model* ## Brazil LGPD Compliance Program Build LGPD as a repeatable operating model, not as a one-time policy project. The stable program is the one that can explain scope, legal basis, rights handling, incident decisions, and transfer safeguards with current evidence. A strong LGPD program ties the law, ANPD guidance, and business processes together. The minimum backbone is scope analysis, role allocation, lawful basis records, rights operations, security and incident controls, transfer governance, DPO contact management, and sanctions-ready documentation. ## Build the legal and operational record set first LGPD Articles 37, 38, 41, 48, and 50 reward organizations that can show how processing decisions are made and reviewed. Before polishing privacy notices, build the records that explain why processing exists and how it is controlled. That means a processing inventory, a role matrix, a lawful basis register, a rights log, an incident record, and a transfer register. - Maintain records of processing operations, especially when legitimate interest is used - Define controller, operator, suboperator, and DPO responsibilities per workflow - Keep one evidence location for policies, approvals, and operational logs ## Design controls around the most regulator-visible duties In practice, the most visible failures involve unclear lawful bases, weak rights handling, poor incident response, and unsupported transfers. Build those control domains before lower-risk optimizations. ANPD guidance also expects organizations to take security measures that are effective and proportionate to processing risk. - Lawful basis and transparency controls for each processing purpose - Article 18 and 19 rights controls with immediate and 15 day response logic - Article 48 incident controls with a live reporting and escalation workflow - Article 33 to 35 transfer controls with contract and disclosure management ## Make the DPO role operational, not symbolic Article 41 makes the controller responsible for designating a DPO, and the ANPD agents guide treats that as the general rule while allowing for later ANPD carve-outs. The contact details must be publicly disclosed, preferably on the controller website. The same guide also explains that the DPO can be internal or external, natural or legal person, but needs enough freedom, resources, and expertise to perform the function. - Formalize the DPO appointment and support model - Publish identity and contact details clearly - Give the DPO access to legal, security, product, and incident teams ## Review the program with sanctions in mind Article 52 and the dosimetry regulation show that ANPD looks at good faith, cooperation, preventive measures, governance policies, and prompt corrective action. A mature program records those facts before an investigation begins. Quarterly review cycles should therefore test not only whether a control exists, but whether the organization can prove operation and remediation. - Review evidence freshness and unresolved exceptions quarterly - Test rights, incidents, and transfer workflows with samples and tabletop exercises - Retain remediation records that show prompt corrective action *Recommended next step* *Placement: after the compliance steps* ## Turn Brazil LGPD Compliance Program into an operational assessment Assessment Autopilot can take Brazil LGPD Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on Brazil LGPD can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Brazil LGPD Compliance Program](/solutions/assessment.md): Start from Brazil LGPD Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Brazil LGPD](/contact.md): Review your current process, evidence gaps, and next steps for Brazil LGPD Compliance Program. ## Primary sources - [Lei No. 13.709/2018 (LGPD)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm?ref=sorena.io) - Primary legal text for Articles 37, 38, 41, 48, 50, and 52. - [ANPD guide for controllers, processors, and DPOs (May 2021)](https://www.gov.br/anpd/pt-br/documentos-e-publicacoes/2021.05.27GuiaAgentesdeTratamento_Final.pdf?ref=sorena.io) - Official ANPD guide on roles, DPO designation, and role allocation. - [Resolution CD/ANPD No. 4/2023](https://www.in.gov.br/web/dou/-/resolucao-cd/anpd-n-4-de-24-de-fevereiro-de-2023-466146077?ref=sorena.io) - Official ANPD dosimetry and sanctions regulation. ## Related Topic Guides - [ANPD Enforcement and Fines | Brazil LGPD Inspection, Procedure, and Sanctions](/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines.md): Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No. - [Brazil LGPD Applicability Test | Article 3 Scope, Article 4 Exclusions, Roles](/artifacts/latam/brazil-lgpd/applicability-test.md): Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation. - [Brazil LGPD Checklist | Scope, Rights, Incidents, Transfers, Evidence](/artifacts/latam/brazil-lgpd/checklist.md): Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting. - [Brazil LGPD Data Subject Rights | Articles 18 to 20 and 15 Day Access Rule](/artifacts/latam/brazil-lgpd/data-subject-rights.md): Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days. - [Brazil LGPD Deadlines and Compliance Calendar](/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar.md): Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training. - [Brazil LGPD DSAR Response Template | Immediate and 15 Day Response Logic](/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template.md): Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale. - [Brazil LGPD FAQ | Scope, Rights, Incidents, Transfers, Enforcement](/artifacts/latam/brazil-lgpd/faq.md): Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance. - [Brazil LGPD Incident Reporting and Breach Notification](/artifacts/latam/brazil-lgpd/breach-notification.md): Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No. - [Brazil LGPD International Transfers | Articles 33 to 35 and ANPD Transfer Mechanisms](/artifacts/latam/brazil-lgpd/international-transfers.md): Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules. - [Brazil LGPD Lawful Bases | Article 7, Article 11, Legitimate Interest](/artifacts/latam/brazil-lgpd/lawful-bases.md): Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data. - [Brazil LGPD Penalties and Fines | Article 52 and ANPD Dosimetry](/artifacts/latam/brazil-lgpd/penalties-and-fines.md): Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion. - [Brazil LGPD Requirements | Articles, Controls, Evidence, and ANPD Guidance](/artifacts/latam/brazil-lgpd/requirements.md): Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers. - [Brazil LGPD Templates | DSAR, Incident, Basis, Transfer, Governance](/artifacts/latam/brazil-lgpd/templates.md): Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments. - [Brazil LGPD vs CCPA and CPRA | Structure, Rights, Enforcement, and Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa.md): Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls. - [Brazil LGPD vs GDPR | Similarities, Differences, and Control Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr.md): Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam/brazil-lgpd/compliance --- --- title: "Brazil LGPD Data Subject Rights" canonical_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/data-subject-rights" source_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/data-subject-rights" author: "Sorena AI" description: "Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Brazil LGPD data subject rights" - "Article 18 LGPD" - "Article 19 LGPD" - "15 day access rule LGPD" - "Article 20 automated decisions" - "Brazil LGPD rights" - "Article 20 LGPD" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Brazil LGPD Data Subject Rights Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days. *Rights Guide* *Articles 18 to 20* ## Brazil LGPD Data Subject Rights Run rights operations around the actual LGPD response structure. The law expects free requests, immediate simplified confirmation or access when possible, a full declaration within 15 days, and a defensible workflow for denials and automated decision review. Articles 18 to 20 create the core rights stack. Controllers need to support confirmation of processing, access, correction, anonymization, blocking, deletion, portability, information on sharing, information about consent consequences, consent revocation, and review of decisions made solely by automated processing. ## Map every Article 18 right to one operational route Rights quality fails when the same request is handled differently across channels or business units. Build one taxonomy and one routing model for confirmation, access, correction, anonymization, blocking, deletion, portability, sharing information, consent information, and consent revocation. Keep special handling rules for requests involving processors, archived records, or legal retention constraints. - Tag the request with the specific right being exercised - Map the systems, processors, and teams needed for fulfillment - Record any legal basis for refusal, limitation, or deferred action ## Use the Article 19 response format correctly For confirmation of existence or access, Article 19 gives two formats. The controller can provide a simplified response immediately, or a clear and complete declaration within 15 days that explains origin of the data, existence or absence of records, criteria used, and processing purpose, subject to commercial and industrial secrecy. The right is exercised without cost to the data subject, and the information can be provided electronically or in printed form at the data subject choice. - Offer an immediate simplified response path when feasible - Maintain a 15 day full declaration path for complete responses - Store the evidence showing which systems and processors were checked ## Control deletion, portability, and revocation edge cases Deletion under Article 18 is not automatic in every case. Data processed under consent can be deleted subject to the Article 16 retention exceptions, and portability does not include data already anonymized by the controller. Consent revocation must be supported by a free and easy procedure, and changes should be communicated to other agents with whom the data was shared unless impossible or disproportionate. - Check Article 16 retention grounds before deleting data - Exclude already anonymized data from portability exports - Notify shared-use partners about correction, deletion, anonymization, or blocking when required ## Treat automated decision review as a separate workflow Article 20 gives the data subject the right to request review of decisions taken solely on automated processing that affect the data subject interests. The controller must also provide clear and adequate information on the criteria and procedures used, subject to commercial and industrial secrecy. If secrecy is invoked, ANPD can audit the system for discriminatory aspects. That makes model governance and review evidence essential. - Keep a trigger to identify purely automated decisions - Prepare explanation records about criteria and procedures used - Escalate secrecy-based refusals for legal review because ANPD can inspect *Recommended next step* *Placement: after the scope or definition section* ## Use Brazil LGPD Data Subject Rights as a cited research workflow Research Copilot can take Brazil LGPD Data Subject Rights from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on Brazil LGPD can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Brazil LGPD Data Subject Rights](/solutions/research-copilot.md): Start from Brazil LGPD Data Subject Rights and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Brazil LGPD](/contact.md): Review your current process, evidence gaps, and next steps for Brazil LGPD Data Subject Rights. ## Primary sources - [Lei No. 13.709/2018 (LGPD)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm?ref=sorena.io) - Primary legal text for Articles 18, 19, 20, and 21. - [ANPD guide for controllers, processors, and DPOs (May 2021)](https://www.gov.br/anpd/pt-br/documentos-e-publicacoes/2021.05.27GuiaAgentesdeTratamento_Final.pdf?ref=sorena.io) - Official ANPD guide for role allocation and DPO contact logic used in rights handling. - [ANPD Statement No. 1/2023](https://www.in.gov.br/web/dou/-/enunciado-cd/anpd-n-1-de-22-de-maio-de-2023-485306934?ref=sorena.io) - Official ANPD interpretation on legal bases for children and adolescents data under Article 14. ## Related Topic Guides - [ANPD Enforcement and Fines | Brazil LGPD Inspection, Procedure, and Sanctions](/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines.md): Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No. - [Brazil LGPD Applicability Test | Article 3 Scope, Article 4 Exclusions, Roles](/artifacts/latam/brazil-lgpd/applicability-test.md): Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation. - [Brazil LGPD Checklist | Scope, Rights, Incidents, Transfers, Evidence](/artifacts/latam/brazil-lgpd/checklist.md): Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting. - [Brazil LGPD Compliance Program Guide](/artifacts/latam/brazil-lgpd/compliance.md): Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence. - [Brazil LGPD Deadlines and Compliance Calendar](/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar.md): Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training. - [Brazil LGPD DSAR Response Template | Immediate and 15 Day Response Logic](/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template.md): Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale. - [Brazil LGPD FAQ | Scope, Rights, Incidents, Transfers, Enforcement](/artifacts/latam/brazil-lgpd/faq.md): Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance. - [Brazil LGPD Incident Reporting and Breach Notification](/artifacts/latam/brazil-lgpd/breach-notification.md): Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No. - [Brazil LGPD International Transfers | Articles 33 to 35 and ANPD Transfer Mechanisms](/artifacts/latam/brazil-lgpd/international-transfers.md): Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules. - [Brazil LGPD Lawful Bases | Article 7, Article 11, Legitimate Interest](/artifacts/latam/brazil-lgpd/lawful-bases.md): Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data. - [Brazil LGPD Penalties and Fines | Article 52 and ANPD Dosimetry](/artifacts/latam/brazil-lgpd/penalties-and-fines.md): Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion. - [Brazil LGPD Requirements | Articles, Controls, Evidence, and ANPD Guidance](/artifacts/latam/brazil-lgpd/requirements.md): Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers. - [Brazil LGPD Templates | DSAR, Incident, Basis, Transfer, Governance](/artifacts/latam/brazil-lgpd/templates.md): Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments. - [Brazil LGPD vs CCPA and CPRA | Structure, Rights, Enforcement, and Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa.md): Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls. - [Brazil LGPD vs GDPR | Similarities, Differences, and Control Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr.md): Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam/brazil-lgpd/data-subject-rights --- --- title: "Brazil LGPD Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Brazil LGPD deadlines" - "LGPD compliance calendar" - "ANPD timeline" - "LGPD recurring review cycle" - "Brazil privacy calendar" - "Brazil LGPD timeline" - "ANPD deadlines" - "LGPD recurring controls" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Brazil LGPD Deadlines and Compliance Calendar Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training. *Calendar Guide* *Timeline and Recurring Duties* ## Brazil LGPD Deadlines and Compliance Calendar LGPD is a live operating regime, not a one-time implementation date. Use the root timeline for legal milestones and build recurring rights, incident, transfer, and governance review dates around it. The Brazil LGPD timeline matters, but the ongoing calendar matters more. Your real program has to combine foundational dates such as the 2018 law, the 2021 sanctions start, the 2022 small-agent rule, the 2023 sanctions dosimetry rule, the 2023 children statement, and the 2024 legitimate interest and incident reporting materials with recurring operating reviews. ## Anchor the calendar to the legal and ANPD milestone sequence At minimum, your program calendar should reflect Law No. 13.709 publication on 14 August 2018, sanctions effectiveness for Articles 52 to 54 on 1 August 2021, Resolution CD ANPD No. 1 on 28 October 2021, Resolution CD ANPD No. 2 on 27 January 2022, Resolution CD ANPD No. 4 on 24 February 2023, Statement No. 1 on 22 May 2023, and Resolution CD ANPD No. 15 on 24 April 2024. These milestones explain why some controls now require sharper operational evidence than older generic privacy programs assumed. - Link internal policy and control revisions to published ANPD acts - Record which business units were affected by each milestone update - Reassess scope and evidence when a new ANPD rule changes timing or content *Recommended next step* *Placement: after the timeline or milestone section* ## Turn Brazil LGPD Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take Brazil LGPD Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on Brazil LGPD can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Brazil LGPD Deadlines and Compliance Calendar](/solutions/assessment.md): Start from Brazil LGPD Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Brazil LGPD](/contact.md): Review your current process, evidence gaps, and next steps for Brazil LGPD Deadlines and Compliance Calendar. ## Run recurring monthly and quarterly reviews LGPD does not prescribe one universal monthly routine, but the operational duties around rights, incidents, and transfers require a regular management cycle. Use a monthly working-level review and a quarterly steering review to keep the program current. Without recurring reviews, rights logs, incident cases, and vendor transfer records drift out of sync with actual systems. - Monthly: rights volumes, response timing, complaint trends, and open incident actions - Quarterly: lawful basis register refresh, transfer register review, and control testing - Semiannual or annual: training refresh, notice review, and program maturity assessment ## Treat hard statutory clocks as red-line dates Some LGPD clocks are immediate enough to deserve their own escalation lane. The best examples are the Article 19 immediate simplified response, the 15 day complete declaration, the 3 business day incident notice rule, and the 20 business day complement deadline after a preliminary incident communication. Misses on these clocks should move directly into management review because they affect regulator posture and complaint defensibility. - Track immediate and 15 day rights deadlines separately - Run a dedicated alert for the 3 business day incident clock - Track the 20 business day complement deadline from the first ANPD filing ## Close calendar items with evidence, not with optimism A compliance calendar becomes useful when each line item points to evidence, owner, and next review date. That applies equally to rights workflows, transfer contracts, DPO disclosures, and sanctions mitigation work. Closing dates without current proof creates false readiness and weakens any later ANPD response. - Attach evidence links and reviewer names to every closed item - Carry forward recurring review dates before the current cycle closes - Keep one exceptions log for missed or deferred calendar items ## Primary sources - [Lei No. 13.709/2018 (LGPD)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm?ref=sorena.io) - Primary legal text for rights, records, incidents, and sanctions timing context. - [Resolution CD/ANPD No. 4/2023](https://www.in.gov.br/web/dou/-/resolucao-cd/anpd-n-4-de-24-de-fevereiro-de-2023-466146077?ref=sorena.io) - Official sanctions dosimetry rule adopted on 24 February 2023 and in force from publication on 27 February 2023. - [ANPD incident communication page](https://www.gov.br/anpd/pt-br/assuntos/incidente-de-seguranca?ref=sorena.io) - Official ANPD incident reporting guidance and communication channel context. ## Related Topic Guides - [ANPD Enforcement and Fines | Brazil LGPD Inspection, Procedure, and Sanctions](/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines.md): Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No. - [Brazil LGPD Applicability Test | Article 3 Scope, Article 4 Exclusions, Roles](/artifacts/latam/brazil-lgpd/applicability-test.md): Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation. - [Brazil LGPD Checklist | Scope, Rights, Incidents, Transfers, Evidence](/artifacts/latam/brazil-lgpd/checklist.md): Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting. - [Brazil LGPD Compliance Program Guide](/artifacts/latam/brazil-lgpd/compliance.md): Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence. - [Brazil LGPD Data Subject Rights | Articles 18 to 20 and 15 Day Access Rule](/artifacts/latam/brazil-lgpd/data-subject-rights.md): Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days. - [Brazil LGPD DSAR Response Template | Immediate and 15 Day Response Logic](/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template.md): Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale. - [Brazil LGPD FAQ | Scope, Rights, Incidents, Transfers, Enforcement](/artifacts/latam/brazil-lgpd/faq.md): Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance. - [Brazil LGPD Incident Reporting and Breach Notification](/artifacts/latam/brazil-lgpd/breach-notification.md): Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No. - [Brazil LGPD International Transfers | Articles 33 to 35 and ANPD Transfer Mechanisms](/artifacts/latam/brazil-lgpd/international-transfers.md): Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules. - [Brazil LGPD Lawful Bases | Article 7, Article 11, Legitimate Interest](/artifacts/latam/brazil-lgpd/lawful-bases.md): Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data. - [Brazil LGPD Penalties and Fines | Article 52 and ANPD Dosimetry](/artifacts/latam/brazil-lgpd/penalties-and-fines.md): Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion. - [Brazil LGPD Requirements | Articles, Controls, Evidence, and ANPD Guidance](/artifacts/latam/brazil-lgpd/requirements.md): Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers. - [Brazil LGPD Templates | DSAR, Incident, Basis, Transfer, Governance](/artifacts/latam/brazil-lgpd/templates.md): Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments. - [Brazil LGPD vs CCPA and CPRA | Structure, Rights, Enforcement, and Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa.md): Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls. - [Brazil LGPD vs GDPR | Similarities, Differences, and Control Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr.md): Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar --- --- title: "Brazil LGPD FAQ" canonical_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/faq" source_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/faq" author: "Sorena AI" description: "Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Brazil LGPD FAQ" - "ANPD FAQ" - "LGPD scope questions" - "LGPD rights questions" - "LGPD incident questions" - "LGPD scope" - "LGPD rights and incidents" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Brazil LGPD FAQ Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance. *FAQ* *Implementation Answers* ## Brazil LGPD FAQ Use direct answers for the questions teams ask every week. These answers follow the law and current ANPD guidance, not generic privacy boilerplate. The questions below are the ones that repeatedly drive launch delays, legal escalations, and weak evidence. The safest practice is to answer them once in a governed standard and then reuse the same answer format across the program. ## Scope and role questions Does LGPD apply to a foreign company? Yes, if Article 3 connects the processing to Brazil through the operation itself, offering or supplying goods or services to individuals located in Brazil, or collection in Brazil. Can a vendor call itself only a processor and be done? No. The ANPD role analysis depends on who actually decides purpose and essential means in the real workflow. - Use Article 3 and 4 first, not corporate domicile alone - Map controller and operator roles by activity, not only by contract title - Reassess role allocation when affiliates or vendors start making their own purpose decisions ## Rights and timing questions How fast must access be provided? Article 19 allows a simplified response immediately or a complete declaration in up to 15 days. Can requests be charged? The law says the request route should be without cost to the data subject. - Build both the immediate and the 15 day response paths - Keep refusal and limitation reasons documented - Treat automated-decision review as a distinct workflow under Article 20 ## Lawful basis and children questions Can legitimate interest be used for sensitive data? No. The ANPD guide explains that legitimate interest is a basis for ordinary personal data under Article 7 and does not appear in Article 11 for sensitive data. Do children data always require consent? Article 14 paragraph 1 creates a highlighted-consent rule for children, but ANPD Statement No. 1 explains that children and adolescents data may also rely on Articles 7 or 11 when best interest prevails in the specific case. - Use a documented balancing test for legitimate-interest cases - Escalate child-data basis decisions for explicit best-interest review - Update notices and rights logic whenever the basis changes ## Incident, transfer, and sanctions questions When must an incident be reported? Under the current ANPD incident rule, reportable incidents need communication to ANPD and data subjects within 3 business days, with a 20 business day complement window for preliminary communication. What is the fine cap? Article 52 allows up to 2 percent of Brazilian revenue, excluding taxes, capped at R$50 million per infraction, plus other non-monetary sanctions. - Keep the 3 business day and 20 business day clocks visible in the case workflow - Choose transfer mechanisms only after confirming basis and scope - Build sanctions mitigation evidence before any case exists *Recommended next step* *Placement: after the FAQ section* ## Use Brazil LGPD FAQ as a cited research workflow Research Copilot can take Brazil LGPD FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on Brazil LGPD can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Brazil LGPD FAQ](/solutions/research-copilot.md): Start from Brazil LGPD FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Brazil LGPD](/contact.md): Review your current process, evidence gaps, and next steps for Brazil LGPD FAQ. ## Primary sources - [Lei No. 13.709/2018 (LGPD)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm?ref=sorena.io) - Primary legal text for the questions answered on this page. - [ANPD guide for controllers, processors, and DPOs (May 2021)](https://www.gov.br/anpd/pt-br/documentos-e-publicacoes/2021.05.27GuiaAgentesdeTratamento_Final.pdf?ref=sorena.io) - Official ANPD guide for role and DPO answers. - [ANPD Statement No. 1/2023](https://www.in.gov.br/web/dou/-/enunciado-cd/anpd-n-1-de-22-de-maio-de-2023-485306934?ref=sorena.io) - Official ANPD interpretation on children and adolescents data. - [Resolution CD/ANPD No. 4/2023](https://www.in.gov.br/web/dou/-/resolucao-cd/anpd-n-4-de-24-de-fevereiro-de-2023-466146077?ref=sorena.io) - Official ANPD sanctions and dosimetry rule. ## Related Topic Guides - [ANPD Enforcement and Fines | Brazil LGPD Inspection, Procedure, and Sanctions](/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines.md): Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No. - [Brazil LGPD Applicability Test | Article 3 Scope, Article 4 Exclusions, Roles](/artifacts/latam/brazil-lgpd/applicability-test.md): Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation. - [Brazil LGPD Checklist | Scope, Rights, Incidents, Transfers, Evidence](/artifacts/latam/brazil-lgpd/checklist.md): Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting. - [Brazil LGPD Compliance Program Guide](/artifacts/latam/brazil-lgpd/compliance.md): Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence. - [Brazil LGPD Data Subject Rights | Articles 18 to 20 and 15 Day Access Rule](/artifacts/latam/brazil-lgpd/data-subject-rights.md): Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days. - [Brazil LGPD Deadlines and Compliance Calendar](/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar.md): Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training. - [Brazil LGPD DSAR Response Template | Immediate and 15 Day Response Logic](/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template.md): Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale. - [Brazil LGPD Incident Reporting and Breach Notification](/artifacts/latam/brazil-lgpd/breach-notification.md): Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No. - [Brazil LGPD International Transfers | Articles 33 to 35 and ANPD Transfer Mechanisms](/artifacts/latam/brazil-lgpd/international-transfers.md): Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules. - [Brazil LGPD Lawful Bases | Article 7, Article 11, Legitimate Interest](/artifacts/latam/brazil-lgpd/lawful-bases.md): Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data. - [Brazil LGPD Penalties and Fines | Article 52 and ANPD Dosimetry](/artifacts/latam/brazil-lgpd/penalties-and-fines.md): Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion. - [Brazil LGPD Requirements | Articles, Controls, Evidence, and ANPD Guidance](/artifacts/latam/brazil-lgpd/requirements.md): Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers. - [Brazil LGPD Templates | DSAR, Incident, Basis, Transfer, Governance](/artifacts/latam/brazil-lgpd/templates.md): Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments. - [Brazil LGPD vs CCPA and CPRA | Structure, Rights, Enforcement, and Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa.md): Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls. - [Brazil LGPD vs GDPR | Similarities, Differences, and Control Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr.md): Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam/brazil-lgpd/faq --- --- title: "Brazil LGPD International Transfers" canonical_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/international-transfers" source_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/international-transfers" author: "Sorena AI" description: "Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Brazil LGPD international transfer" - "Article 33 LGPD" - "ANPD standard contractual clauses" - "Brazil binding corporate rules" - "Brazil transfer adequacy" - "Brazil LGPD transfers" - "ANPD standard clauses" - "binding corporate rules Brazil" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Brazil LGPD International Transfers Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules. *Transfer Guide* *Articles 33 to 35* ## Brazil LGPD International Transfers Treat cross-border transfer as a separate compliance decision with its own mechanism, disclosures, and contracts. You need both a valid domestic legal basis and a valid transfer mechanism. One does not replace the other. Articles 33 to 35 and the ANPD transfer regulation require more than a contract label. First confirm that the activity is an international transfer, that LGPD applies to the underlying processing, and that the transfer has a valid legal basis. Then choose the transfer mechanism and meet the transparency and contract duties that go with it. ## Confirm that the activity is actually an international transfer The ANPD transfer regulation distinguishes international transfer from international collection. A transfer exists when an exporter transmits, shares, or provides access to personal data to an importer in another country or to an international organization. That analysis should include onward transfers and subprocessor chains, not only the first foreign recipient. - Map exporter, importer, and onward recipient roles - Separate true transfers from mere collection abroad where no transfer occurs - Document the business purpose, data categories, and affected data subjects ## Choose the mechanism only after basis and scope are confirmed The transfer regulation requires the controller to verify that the operation is supported by both a legal basis and a valid transfer mechanism. Valid mechanisms include adequacy recognition by ANPD, standard contractual clauses, specific contractual clauses, binding corporate rules, and other Article 33 cases that do not depend on regulation. There is no hierarchy in principle, but some mechanisms can be used immediately while others require prior ANPD recognition or approval. - Use adequacy where ANPD has recognized equivalent protection - Use ANPD standard clauses in full and without modification when that route fits - Use specific clauses or binding corporate rules only when the circumstances justify the added approval burden *Recommended next step* *Placement: after the scope or definition section* ## Use Brazil LGPD International Transfers as a cited research workflow Research Copilot can take Brazil LGPD International Transfers from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on Brazil LGPD can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Brazil LGPD International Transfers](/solutions/research-copilot.md): Start from Brazil LGPD International Transfers and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Brazil LGPD](/contact.md): Review your current process, evidence gaps, and next steps for Brazil LGPD International Transfers. ## Meet the transparency duties to data subjects The controller must publish, on its website, a document in Portuguese, using simple, clear, precise, and accessible language, with information about the form, duration, and specific purpose of the transfer, the destination country, and the applicable rights and responsibilities. Data subjects can also request the full text of the clauses used for the transfer, subject to commercial and industrial secrecy. - Publish a transfer notice in Portuguese with the required elements - Prepare a response path for requests to see the clause text - Keep website disclosures aligned with the signed contract and actual data flow ## Operationalize ANPD clauses and BCR governance ANPD standard contractual clauses must be adopted in full and can be embedded in a dedicated transfer agreement or as an addendum to a broader contract. Binding corporate rules are only valid for the entities and countries they actually cover and need a responsible entity in Brazil that answers for violations. Both mechanisms need a process for updates, changes, legal conflicts, and rights handling within the deadlines already recognized by LGPD. - Track version control for contracts, addenda, and BCR documents - Create a legal-change process for foreign law conflicts and safeguard failures - Link transfer terms to incident, rights, and vendor oversight workflows ## Primary sources - [Lei No. 13.709/2018 (LGPD)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm?ref=sorena.io) - Primary legal text for Articles 33, 34, 35, 36, and 37. - [ANPD home page](https://www.gov.br/anpd/pt-br?ref=sorena.io) - Official ANPD portal used for transfer regulation updates and publication context. - [Resolution CD/ANPD No. 2/2022](https://www.in.gov.br/en/web/dou/-/resolucao-cd/anpd-n-2-de-27-de-janeiro-de-2022-376562019?ref=sorena.io) - Official ANPD rule for small-scale processing agents and high-risk criteria relevant to transfer governance. ## Related Topic Guides - [ANPD Enforcement and Fines | Brazil LGPD Inspection, Procedure, and Sanctions](/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines.md): Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No. - [Brazil LGPD Applicability Test | Article 3 Scope, Article 4 Exclusions, Roles](/artifacts/latam/brazil-lgpd/applicability-test.md): Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation. - [Brazil LGPD Checklist | Scope, Rights, Incidents, Transfers, Evidence](/artifacts/latam/brazil-lgpd/checklist.md): Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting. - [Brazil LGPD Compliance Program Guide](/artifacts/latam/brazil-lgpd/compliance.md): Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence. - [Brazil LGPD Data Subject Rights | Articles 18 to 20 and 15 Day Access Rule](/artifacts/latam/brazil-lgpd/data-subject-rights.md): Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days. - [Brazil LGPD Deadlines and Compliance Calendar](/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar.md): Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training. - [Brazil LGPD DSAR Response Template | Immediate and 15 Day Response Logic](/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template.md): Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale. - [Brazil LGPD FAQ | Scope, Rights, Incidents, Transfers, Enforcement](/artifacts/latam/brazil-lgpd/faq.md): Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance. - [Brazil LGPD Incident Reporting and Breach Notification](/artifacts/latam/brazil-lgpd/breach-notification.md): Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No. - [Brazil LGPD Lawful Bases | Article 7, Article 11, Legitimate Interest](/artifacts/latam/brazil-lgpd/lawful-bases.md): Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data. - [Brazil LGPD Penalties and Fines | Article 52 and ANPD Dosimetry](/artifacts/latam/brazil-lgpd/penalties-and-fines.md): Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion. - [Brazil LGPD Requirements | Articles, Controls, Evidence, and ANPD Guidance](/artifacts/latam/brazil-lgpd/requirements.md): Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers. - [Brazil LGPD Templates | DSAR, Incident, Basis, Transfer, Governance](/artifacts/latam/brazil-lgpd/templates.md): Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments. - [Brazil LGPD vs CCPA and CPRA | Structure, Rights, Enforcement, and Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa.md): Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls. - [Brazil LGPD vs GDPR | Similarities, Differences, and Control Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr.md): Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam/brazil-lgpd/international-transfers --- --- title: "Brazil LGPD Lawful Bases" canonical_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/lawful-bases" source_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/lawful-bases" author: "Sorena AI" description: "Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Brazil LGPD lawful bases" - "Article 7 LGPD" - "Article 11 LGPD" - "ANPD legitimate interest guide" - "Brazil LGPD consent" - "legitimate interest ANPD" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Brazil LGPD Lawful Bases Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data. *Legal Basis Guide* *Articles 7 and 11* ## Brazil LGPD Lawful Bases Select the basis by purpose, necessity, and risk, not by convenience. The lawful basis decision affects notices, rights logic, retention, incident analysis, transfer statements, and sanctions exposure. Article 7 contains the legal bases for ordinary personal data, while Article 11 does the same for sensitive personal data. The ANPD legitimate interest guide published in February 2024 adds a practical test for purpose, necessity, balancing, and safeguards, and also warns that legitimate interest is not available for sensitive personal data. ## Start with purpose and data type before choosing the basis Basis selection starts with the processing purpose and the nature of the data. If the processing involves sensitive personal data, the controller needs to move to Article 11, not Article 7. The same use case can change basis if the purpose changes. That is why the lawful basis register needs version control and review after product, HR, analytics, or vendor changes. - Write the purpose in concrete business and user terms - Classify whether the data includes sensitive personal data - Record why alternative bases were rejected ## Use consent with the actual Article 8 requirements Where consent is the basis, Article 8 requires written or otherwise provable manifestation of will, and if it is written it must appear in a clause highlighted from the rest of the contract. Generic authorizations are null. Consent can be revoked at any time by a free and easy procedure, and the controller bears the burden of proving that consent was obtained lawfully. - Capture consent by specific purpose and keep proof - Make withdrawal free and easy to use - Update notices and downstream sharing records when consent terms change ## Run legitimate interest with the ANPD balancing model The ANPD legitimate interest guide treats legitimate interest as a structured analysis, not as a fallback basis. The guide organizes the test around purpose, necessity, balancing, and safeguards. The same guide confirms that legitimate interest is not a basis for sensitive personal data because it appears only in Article 7 and not in Article 11. - Define the legitimate interest in concrete and non-speculative terms - Test whether a less intrusive means could achieve the same purpose - Document balancing, safeguards, and the final decision in a retained record ## Handle children and adolescents with the best-interest rule Article 14 requires processing of children and adolescents data to be in their best interest. Article 14 paragraph 1 specifically requires highlighted consent from at least one parent or legal guardian for children data, but ANPD Statement No. 1 of 2023 clarifies that the treatment of children and adolescents data may also rely on the legal bases in Articles 7 or 11 when the best interest requirement is observed in the concrete case. That means teams should not assume a single automatic basis for every youth-facing product flow. They should, however, expect stricter documentation and safeguards. - Assess best interest explicitly in every children or adolescents use case - Use child consent when that is the most appropriate basis and meet the highlighted-consent rule - Escalate uses of legitimate interest or other flexible bases for legal review and stronger safeguards *Recommended next step* *Placement: near the end of the main content before related guides* ## Use Brazil LGPD Lawful Bases as a cited research workflow Research Copilot can take Brazil LGPD Lawful Bases from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on Brazil LGPD can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Brazil LGPD Lawful Bases](/solutions/research-copilot.md): Start from Brazil LGPD Lawful Bases and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Brazil LGPD](/contact.md): Review your current process, evidence gaps, and next steps for Brazil LGPD Lawful Bases. ## Primary sources - [Lei No. 13.709/2018 (LGPD)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm?ref=sorena.io) - Primary legal text for Articles 7, 8, 9, 11, and 14. - [ANPD Statement No. 1/2023](https://www.in.gov.br/web/dou/-/enunciado-cd/anpd-n-1-de-22-de-maio-de-2023-485306934?ref=sorena.io) - Official ANPD interpretation on legal bases for children and adolescents data. - [ANPD home page](https://www.gov.br/anpd/pt-br?ref=sorena.io) - Official ANPD portal for the February 2024 legitimate interest guidance and related materials. ## Related Topic Guides - [ANPD Enforcement and Fines | Brazil LGPD Inspection, Procedure, and Sanctions](/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines.md): Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No. - [Brazil LGPD Applicability Test | Article 3 Scope, Article 4 Exclusions, Roles](/artifacts/latam/brazil-lgpd/applicability-test.md): Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation. - [Brazil LGPD Checklist | Scope, Rights, Incidents, Transfers, Evidence](/artifacts/latam/brazil-lgpd/checklist.md): Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting. - [Brazil LGPD Compliance Program Guide](/artifacts/latam/brazil-lgpd/compliance.md): Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence. - [Brazil LGPD Data Subject Rights | Articles 18 to 20 and 15 Day Access Rule](/artifacts/latam/brazil-lgpd/data-subject-rights.md): Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days. - [Brazil LGPD Deadlines and Compliance Calendar](/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar.md): Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training. - [Brazil LGPD DSAR Response Template | Immediate and 15 Day Response Logic](/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template.md): Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale. - [Brazil LGPD FAQ | Scope, Rights, Incidents, Transfers, Enforcement](/artifacts/latam/brazil-lgpd/faq.md): Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance. - [Brazil LGPD Incident Reporting and Breach Notification](/artifacts/latam/brazil-lgpd/breach-notification.md): Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No. - [Brazil LGPD International Transfers | Articles 33 to 35 and ANPD Transfer Mechanisms](/artifacts/latam/brazil-lgpd/international-transfers.md): Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules. - [Brazil LGPD Penalties and Fines | Article 52 and ANPD Dosimetry](/artifacts/latam/brazil-lgpd/penalties-and-fines.md): Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion. - [Brazil LGPD Requirements | Articles, Controls, Evidence, and ANPD Guidance](/artifacts/latam/brazil-lgpd/requirements.md): Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers. - [Brazil LGPD Templates | DSAR, Incident, Basis, Transfer, Governance](/artifacts/latam/brazil-lgpd/templates.md): Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments. - [Brazil LGPD vs CCPA and CPRA | Structure, Rights, Enforcement, and Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa.md): Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls. - [Brazil LGPD vs GDPR | Similarities, Differences, and Control Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr.md): Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam/brazil-lgpd/lawful-bases --- --- title: "Brazil LGPD DSAR Response Template" canonical_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template" source_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template" author: "Sorena AI" description: "Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Brazil LGPD DSAR template" - "Article 19 LGPD template" - "15 day access response LGPD" - "LGPD rights response template" - "Article 19 LGPD" - "15 day access response" - "LGPD rights response" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Brazil LGPD DSAR Response Template Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale. *Template Guide* *Articles 18 and 19* ## Brazil LGPD DSAR Response Template Use one response structure that matches the law and preserves evidence. The template should support both the immediate simplified route and the 15 day complete declaration route. A useful DSAR template is modular. It should capture identity verification, the right being exercised, the response format chosen, system coverage, legal rationale for any limitation, and the evidence needed to defend the answer later. ## Core response blocks Every response should be assembled from a few stable blocks so teams can work quickly without skipping legal essentials. - Case metadata: request date, channel, case number, identity verification status - Rights classification: Article 18 item requested and whether Article 19 access logic applies - Response path: immediate simplified response or full declaration within 15 days - System coverage: which systems, processors, and business units were searched ## Mandatory legal content blocks For access requests that go through the full declaration route, the response should state the origin of the data, whether records exist, the criteria used, and the purpose of processing, subject to commercial and industrial secrecy. - Origin of the data - Existence or absence of records - Criteria used for the processing or decision - Purpose of the processing - Explanation of any refusal, partial refusal, or delay ## Evidence blocks to retain with the sent response The external message is not enough. Retain the operational proof that the organization checked the right systems and applied the right rule. - Identity verification proof - Search log or extraction log for the systems checked - Legal review note for denials or automated-decision cases - Copy of the final message sent to the data subject *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep Brazil LGPD DSAR Response Template in one governed evidence system SSOT can take Brazil LGPD DSAR Response Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on Brazil LGPD can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for Brazil LGPD DSAR Response Template](/solutions/ssot.md): Start from Brazil LGPD DSAR Response Template and keep documents, evidence, and control records in one governed system. - [Talk through Brazil LGPD](/contact.md): Review your current process, evidence gaps, and next steps for Brazil LGPD DSAR Response Template. ## Template quality controls Review the template regularly against complaint patterns, reopened requests, and ANPD guidance updates so it stays usable and defensible. - Check whether teams are meeting the immediate and 15 day timing paths - Audit whether denials include lawful and clear reasons - Update child-data, processor, and automated-decision sections when guidance changes ## Primary sources - [Lei No. 13.709/2018 (LGPD)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm?ref=sorena.io) - Primary legal text for Articles 18, 19, and 20. - [ANPD guide for controllers, processors, and DPOs (May 2021)](https://www.gov.br/anpd/pt-br/documentos-e-publicacoes/2021.05.27GuiaAgentesdeTratamento_Final.pdf?ref=sorena.io) - Official ANPD guide relevant to DPO routing and role assignment in DSAR handling. ## Related Topic Guides - [ANPD Enforcement and Fines | Brazil LGPD Inspection, Procedure, and Sanctions](/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines.md): Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No. - [Brazil LGPD Applicability Test | Article 3 Scope, Article 4 Exclusions, Roles](/artifacts/latam/brazil-lgpd/applicability-test.md): Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation. - [Brazil LGPD Checklist | Scope, Rights, Incidents, Transfers, Evidence](/artifacts/latam/brazil-lgpd/checklist.md): Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting. - [Brazil LGPD Compliance Program Guide](/artifacts/latam/brazil-lgpd/compliance.md): Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence. - [Brazil LGPD Data Subject Rights | Articles 18 to 20 and 15 Day Access Rule](/artifacts/latam/brazil-lgpd/data-subject-rights.md): Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days. - [Brazil LGPD Deadlines and Compliance Calendar](/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar.md): Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training. - [Brazil LGPD FAQ | Scope, Rights, Incidents, Transfers, Enforcement](/artifacts/latam/brazil-lgpd/faq.md): Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance. - [Brazil LGPD Incident Reporting and Breach Notification](/artifacts/latam/brazil-lgpd/breach-notification.md): Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No. - [Brazil LGPD International Transfers | Articles 33 to 35 and ANPD Transfer Mechanisms](/artifacts/latam/brazil-lgpd/international-transfers.md): Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules. - [Brazil LGPD Lawful Bases | Article 7, Article 11, Legitimate Interest](/artifacts/latam/brazil-lgpd/lawful-bases.md): Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data. - [Brazil LGPD Penalties and Fines | Article 52 and ANPD Dosimetry](/artifacts/latam/brazil-lgpd/penalties-and-fines.md): Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion. - [Brazil LGPD Requirements | Articles, Controls, Evidence, and ANPD Guidance](/artifacts/latam/brazil-lgpd/requirements.md): Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers. - [Brazil LGPD Templates | DSAR, Incident, Basis, Transfer, Governance](/artifacts/latam/brazil-lgpd/templates.md): Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments. - [Brazil LGPD vs CCPA and CPRA | Structure, Rights, Enforcement, and Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa.md): Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls. - [Brazil LGPD vs GDPR | Similarities, Differences, and Control Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr.md): Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template --- --- title: "Brazil LGPD vs CCPA and CPRA" canonical_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa" source_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa" author: "Sorena AI" description: "Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Brazil LGPD vs CCPA" - "LGPD CPRA comparison" - "Brazil California privacy" - "privacy control reuse" - "LGPD versus CCPA" - "LGPD CCPA comparison" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Brazil LGPD vs CCPA and CPRA Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls. *Comparison Guide* *Brazil and California* ## Brazil LGPD vs CCPA and CPRA These laws protect individuals in different structural ways. LGPD is a general privacy law built around lawful bases and ANPD oversight. CCPA and CPRA use a consumer-rights and business-threshold model with different operating assumptions. A reusable control model is possible across Brazil and California, but only if the team respects the structural differences. The Brazil side is built around legal bases, DPO, transfer mechanisms, and ANPD procedure, while the California side emphasizes notice, opt-out, sale or share logic, and business thresholds. ## The legal architecture is different from the start LGPD applies through territorial and collection logic under Article 3 and regulates processing broadly. CCPA and CPRA rely on business thresholds and consumer-rights architecture rather than a lawful-basis system. That means the same inventory or retention control can be reused, but the legal explanation around it will differ. - LGPD asks which Article 7 or 11 basis supports the purpose - CCPA or CPRA asks whether the business meets threshold and notice or opt-out duties - One operating control can serve both only when the legal appendix stays distinct ## Rights handling overlaps but does not align perfectly Both regimes require intake, identity verification, search, response, and logging. LGPD then adds its own immediate or 15 day access logic and Article 20 automated-decision review route. California request categories and response logic need their own overlay even if the same case system is reused. - Reuse request intake tooling where possible - Separate timing, content, and denial rules by jurisdiction - Keep jurisdiction tags on every case record ## International transfer and vendor governance differ sharply Brazil requires a distinct transfer mechanism analysis under Article 33 and ANPD rules. California does not create an equivalent adequacy and clause system, but it does impose contract structure and downstream vendor restrictions. Vendor governance should therefore be shared at the control level and split at the legal language level. - Use one vendor inventory and risk review process - Keep Brazil transfer clauses and California service-provider logic separate - Document which vendor terms satisfy which jurisdictional duty ## Build one privacy program with jurisdiction overlays The efficient model is one baseline for inventory, rights tooling, security, incident management, and vendor review, plus jurisdiction-specific overlays for legal basis, opt-out logic, transfer rules, and regulator interaction. That lets teams reuse evidence while still answering ANPD and California questions in the correct legal language. - Centralize evidence and localize legal interpretation - Review the overlay set whenever a law or regulator guidance changes - Train teams on the points where reuse stops *Recommended next step* *Placement: after the comparison section* ## Use Brazil LGPD vs CCPA and CPRA as a cited research workflow Research Copilot can take Brazil LGPD vs CCPA and CPRA from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on Brazil LGPD can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Brazil LGPD vs CCPA and CPRA](/solutions/research-copilot.md): Start from Brazil LGPD vs CCPA and CPRA and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Brazil LGPD](/contact.md): Review your current process, evidence gaps, and next steps for Brazil LGPD vs CCPA and CPRA. ## Primary sources - [Lei No. 13.709/2018 (LGPD)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm?ref=sorena.io) - Primary legal text for the Brazil side of the comparison. - [ANPD guide for controllers, processors, and DPOs (May 2021)](https://www.gov.br/anpd/pt-br/documentos-e-publicacoes/2021.05.27GuiaAgentesdeTratamento_Final.pdf?ref=sorena.io) - Official ANPD guide relevant to role and governance comparison. ## Related Topic Guides - [ANPD Enforcement and Fines | Brazil LGPD Inspection, Procedure, and Sanctions](/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines.md): Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No. - [Brazil LGPD Applicability Test | Article 3 Scope, Article 4 Exclusions, Roles](/artifacts/latam/brazil-lgpd/applicability-test.md): Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation. - [Brazil LGPD Checklist | Scope, Rights, Incidents, Transfers, Evidence](/artifacts/latam/brazil-lgpd/checklist.md): Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting. - [Brazil LGPD Compliance Program Guide](/artifacts/latam/brazil-lgpd/compliance.md): Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence. - [Brazil LGPD Data Subject Rights | Articles 18 to 20 and 15 Day Access Rule](/artifacts/latam/brazil-lgpd/data-subject-rights.md): Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days. - [Brazil LGPD Deadlines and Compliance Calendar](/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar.md): Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training. - [Brazil LGPD DSAR Response Template | Immediate and 15 Day Response Logic](/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template.md): Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale. - [Brazil LGPD FAQ | Scope, Rights, Incidents, Transfers, Enforcement](/artifacts/latam/brazil-lgpd/faq.md): Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance. - [Brazil LGPD Incident Reporting and Breach Notification](/artifacts/latam/brazil-lgpd/breach-notification.md): Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No. - [Brazil LGPD International Transfers | Articles 33 to 35 and ANPD Transfer Mechanisms](/artifacts/latam/brazil-lgpd/international-transfers.md): Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules. - [Brazil LGPD Lawful Bases | Article 7, Article 11, Legitimate Interest](/artifacts/latam/brazil-lgpd/lawful-bases.md): Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data. - [Brazil LGPD Penalties and Fines | Article 52 and ANPD Dosimetry](/artifacts/latam/brazil-lgpd/penalties-and-fines.md): Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion. - [Brazil LGPD Requirements | Articles, Controls, Evidence, and ANPD Guidance](/artifacts/latam/brazil-lgpd/requirements.md): Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers. - [Brazil LGPD Templates | DSAR, Incident, Basis, Transfer, Governance](/artifacts/latam/brazil-lgpd/templates.md): Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments. - [Brazil LGPD vs GDPR | Similarities, Differences, and Control Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr.md): Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa --- --- title: "Brazil LGPD vs GDPR" canonical_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr" source_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr" author: "Sorena AI" description: "Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Brazil LGPD vs GDPR" - "LGPD GDPR comparison" - "ANPD versus GDPR" - "privacy control reuse" - "LGPD GDPR differences" - "cross-framework privacy controls" - "ANPD and EU comparison" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Brazil LGPD vs GDPR Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting. *Comparison Guide* *LGPD and GDPR* ## Brazil LGPD vs GDPR LGPD borrows heavily from GDPR, but the operating details still diverge. Use one control baseline where possible, then add region-specific overlays for timing, guidance, and regulator process. LGPD and GDPR share the controller-processor model, lawful bases, rights concepts, security duties, and transfer controls. The biggest implementation errors happen when teams assume identical timing, identical regulator expectations, or identical supporting documents. ## What is structurally similar Both regimes use a broad personal-data concept, controller and processor roles, transparency duties, rights handling, security obligations, and transfer restrictions. Much of the inventory, vendor, retention, and access-control stack can therefore be reused. - Shared need for processing records and role mapping - Shared need for lawful basis and notice discipline - Shared need for rights operations, incident response, and vendor control ## Where the operating details diverge LGPD Article 19 gives a specific immediate or 15 day access structure. LGPD incident reporting now uses the ANPD 3 business day rule under the current incident communication regulation. GDPR timing and supervisory practice follow a different structure. LGPD also uses ANPD-specific guidance such as Statement No. 1 for children and the February 2024 legitimate-interest guide, so the evidence pack cannot simply reuse EU wording without review. - Rights timing differs in structure and must be tracked separately - Incident reporting timing and form are not the same - Children-data and legitimate-interest analysis need Brazil-specific documentation ## Transfer and DPO overlays need local treatment GDPR transfer mechanisms and LGPD transfer mechanisms now look closer than before, but Brazil requires the Article 33 to 35 and ANPD route, including Portuguese website disclosures and ANPD-recognized or approved safeguards. DPO logic also needs local review because the ANPD guide treats designation as the general rule, subject to ANPD carve-outs. - Reuse transfer mapping logic but not the contract package blindly - Review DPO appointment and public disclosure requirements locally - Keep regulator-facing communications in the right language and format ## How to reuse controls safely Build one global baseline for inventory, vendor management, security, and governance, then attach LGPD and GDPR overlays for timing, forms, and local interpretations. That is faster and safer than maintaining two fully separate privacy programs or pretending one regime automatically satisfies the other. - Reuse the control objective, not the legal conclusion - Retain separate legal references and evidence appendices - Run periodic comparison reviews when ANPD or EU guidance changes *Recommended next step* *Placement: after the comparison section* ## Use Brazil LGPD vs GDPR as a cited research workflow Research Copilot can take Brazil LGPD vs GDPR from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on Brazil LGPD can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Brazil LGPD vs GDPR](/solutions/research-copilot.md): Start from Brazil LGPD vs GDPR and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Brazil LGPD](/contact.md): Review your current process, evidence gaps, and next steps for Brazil LGPD vs GDPR. ## Primary sources - [Lei No. 13.709/2018 (LGPD)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm?ref=sorena.io) - Primary legal text for the Brazil side of the comparison. - [ANPD guide for controllers, processors, and DPOs (May 2021)](https://www.gov.br/anpd/pt-br/documentos-e-publicacoes/2021.05.27GuiaAgentesdeTratamento_Final.pdf?ref=sorena.io) - Official ANPD role and DPO guidance. - [ANPD Statement No. 1/2023](https://www.in.gov.br/web/dou/-/enunciado-cd/anpd-n-1-de-22-de-maio-de-2023-485306934?ref=sorena.io) - Official ANPD children-data interpretation relevant to the comparison. ## Related Topic Guides - [ANPD Enforcement and Fines | Brazil LGPD Inspection, Procedure, and Sanctions](/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines.md): Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No. - [Brazil LGPD Applicability Test | Article 3 Scope, Article 4 Exclusions, Roles](/artifacts/latam/brazil-lgpd/applicability-test.md): Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation. - [Brazil LGPD Checklist | Scope, Rights, Incidents, Transfers, Evidence](/artifacts/latam/brazil-lgpd/checklist.md): Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting. - [Brazil LGPD Compliance Program Guide](/artifacts/latam/brazil-lgpd/compliance.md): Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence. - [Brazil LGPD Data Subject Rights | Articles 18 to 20 and 15 Day Access Rule](/artifacts/latam/brazil-lgpd/data-subject-rights.md): Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days. - [Brazil LGPD Deadlines and Compliance Calendar](/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar.md): Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training. - [Brazil LGPD DSAR Response Template | Immediate and 15 Day Response Logic](/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template.md): Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale. - [Brazil LGPD FAQ | Scope, Rights, Incidents, Transfers, Enforcement](/artifacts/latam/brazil-lgpd/faq.md): Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance. - [Brazil LGPD Incident Reporting and Breach Notification](/artifacts/latam/brazil-lgpd/breach-notification.md): Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No. - [Brazil LGPD International Transfers | Articles 33 to 35 and ANPD Transfer Mechanisms](/artifacts/latam/brazil-lgpd/international-transfers.md): Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules. - [Brazil LGPD Lawful Bases | Article 7, Article 11, Legitimate Interest](/artifacts/latam/brazil-lgpd/lawful-bases.md): Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data. - [Brazil LGPD Penalties and Fines | Article 52 and ANPD Dosimetry](/artifacts/latam/brazil-lgpd/penalties-and-fines.md): Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion. - [Brazil LGPD Requirements | Articles, Controls, Evidence, and ANPD Guidance](/artifacts/latam/brazil-lgpd/requirements.md): Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers. - [Brazil LGPD Templates | DSAR, Incident, Basis, Transfer, Governance](/artifacts/latam/brazil-lgpd/templates.md): Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments. - [Brazil LGPD vs CCPA and CPRA | Structure, Rights, Enforcement, and Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa.md): Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr --- --- title: "Brazil LGPD Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/penalties-and-fines" author: "Sorena AI" description: "Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Brazil LGPD penalties" - "Article 52 LGPD" - "ANPD fines" - "LGPD 2 percent fine" - "R$50 million LGPD" - "ANPD dosimetry" - "Brazil LGPD fines" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Brazil LGPD Penalties and Fines Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion. *Enforcement Guide* *Article 52 and Resolution 4/2023* ## Brazil LGPD Penalties and Fines The sanctions story is broader than a fine amount. Article 52 creates a ladder of sanctions, and ANPD dosimetry looks closely at good faith, cooperation, governance, and prompt corrective action. Article 52 authorizes warning, simple fine, daily fine, publicization, blocking, deletion, partial suspension of the database, suspension of processing activity, and partial or total prohibition of activities related to processing. Monetary fines can reach 2 percent of Brazilian revenue, excluding taxes, capped at R$50 million per infraction. ## Know the full sanctions ladder Many teams focus only on the 2 percent and R$50 million figures, but LGPD also permits publicization, blocking, deletion, and suspension-style sanctions that can disrupt operations and reputation. The heavier suspension and prohibition measures are not first-step sanctions. Article 52 requires at least one prior sanction from the monetary or corrective group for the same case before the most severe restrictions are used. - Warning with a corrective-action deadline - Simple fine and daily fine - Publicization, blocking, and deletion - Suspension of database, suspension of processing, and prohibition of related activities ## Track the factors ANPD will use in dosimetry Article 52 paragraph 1 and Resolution CD ANPD No. 4/2023 look at gravity, nature of the violation, affected rights, good faith, economic condition, recurrence, degree of harm, cooperation, internal mechanisms to minimize damage, governance policies, prompt corrective action, and proportionality. That means sanctions mitigation starts long before a case file exists. You need records that show prevention, review, and remediation were real. - Preserve evidence of cooperation and prompt corrective action - Keep records of internal mechanisms designed to minimize harm - Show that governance policies were implemented, not only approved ## Understand the specific payment and small-agent nuances Resolution CD ANPD No. 4/2023 also contains operational details around sanctions, including doubled payment time for small-scale processing agents as defined by Resolution CD ANPD No. 2/2022. That does not remove the obligation or the underlying compliance duty. It only changes a payment mechanics point for a specific category of regulated entity. - Check whether the organization actually qualifies as a small-scale processing agent under the ANPD rule - Do not confuse differentiated procedure with exemption from substantive duties - Keep financial exposure modeling separate from operational remediation planning ## Build the sanctions defense pack before you need it The best sanctions defense pack combines legal and operational proof. It should show basis selection, rights handling, incident response, transfer controls, training, risk decisions, and remediation history. Programs that cannot show this trail leave ANPD to infer governance quality from the violation alone. - Keep current evidence for high-risk processing, rights, incidents, and transfers - Store remediation records and closure verification results - Maintain committee records that show risk was reviewed and acted on *Recommended next step* *Placement: after the enforcement section* ## Use Brazil LGPD Penalties and Fines as a cited research workflow Research Copilot can take Brazil LGPD Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on Brazil LGPD can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Brazil LGPD Penalties and Fines](/solutions/research-copilot.md): Start from Brazil LGPD Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Brazil LGPD](/contact.md): Review your current process, evidence gaps, and next steps for Brazil LGPD Penalties and Fines. ## Primary sources - [Lei No. 13.709/2018 (LGPD)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm?ref=sorena.io) - Primary legal text for Article 52 and related sanctions factors. - [Resolution CD/ANPD No. 4/2023](https://www.in.gov.br/web/dou/-/resolucao-cd/anpd-n-4-de-24-de-fevereiro-de-2023-466146077?ref=sorena.io) - Official ANPD dosimetry and administrative sanctions regulation. - [Resolution CD/ANPD No. 2/2022](https://www.in.gov.br/en/web/dou/-/resolucao-cd/anpd-n-2-de-27-de-janeiro-de-2022-376562019?ref=sorena.io) - Official ANPD rule defining small-scale processing agents referenced in sanctions mechanics. ## Related Topic Guides - [ANPD Enforcement and Fines | Brazil LGPD Inspection, Procedure, and Sanctions](/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines.md): Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No. - [Brazil LGPD Applicability Test | Article 3 Scope, Article 4 Exclusions, Roles](/artifacts/latam/brazil-lgpd/applicability-test.md): Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation. - [Brazil LGPD Checklist | Scope, Rights, Incidents, Transfers, Evidence](/artifacts/latam/brazil-lgpd/checklist.md): Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting. - [Brazil LGPD Compliance Program Guide](/artifacts/latam/brazil-lgpd/compliance.md): Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence. - [Brazil LGPD Data Subject Rights | Articles 18 to 20 and 15 Day Access Rule](/artifacts/latam/brazil-lgpd/data-subject-rights.md): Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days. - [Brazil LGPD Deadlines and Compliance Calendar](/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar.md): Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training. - [Brazil LGPD DSAR Response Template | Immediate and 15 Day Response Logic](/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template.md): Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale. - [Brazil LGPD FAQ | Scope, Rights, Incidents, Transfers, Enforcement](/artifacts/latam/brazil-lgpd/faq.md): Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance. - [Brazil LGPD Incident Reporting and Breach Notification](/artifacts/latam/brazil-lgpd/breach-notification.md): Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No. - [Brazil LGPD International Transfers | Articles 33 to 35 and ANPD Transfer Mechanisms](/artifacts/latam/brazil-lgpd/international-transfers.md): Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules. - [Brazil LGPD Lawful Bases | Article 7, Article 11, Legitimate Interest](/artifacts/latam/brazil-lgpd/lawful-bases.md): Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data. - [Brazil LGPD Requirements | Articles, Controls, Evidence, and ANPD Guidance](/artifacts/latam/brazil-lgpd/requirements.md): Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers. - [Brazil LGPD Templates | DSAR, Incident, Basis, Transfer, Governance](/artifacts/latam/brazil-lgpd/templates.md): Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments. - [Brazil LGPD vs CCPA and CPRA | Structure, Rights, Enforcement, and Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa.md): Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls. - [Brazil LGPD vs GDPR | Similarities, Differences, and Control Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr.md): Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam/brazil-lgpd/penalties-and-fines --- --- title: "Brazil LGPD Requirements" canonical_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/requirements" source_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/requirements" author: "Sorena AI" description: "Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Brazil LGPD requirements" - "LGPD control mapping" - "ANPD evidence" - "Brazil privacy controls" - "LGPD article mapping" - "LGPD controls" - "privacy control mapping" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Brazil LGPD Requirements Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers. *Requirements Guide* *Article to Control Mapping* ## Brazil LGPD Requirements Use one register that links each LGPD requirement to a control, owner, and proof set. The most useful requirement map is the one a privacy lead, product lead, and ANPD reviewer can all follow without translation. LGPD implementation becomes manageable when the requirements are grouped into operating domains. The practical domains are scope and roles, lawful bases and transparency, rights, records and DPO, security and incidents, transfers, and sanctions mitigation. ## Scope, roles, and accountability requirements Articles 3 to 5, 37, 39, and 41 create the accountability spine. Controllers need defensible scope analysis, operator oversight, records of processing, and a designated DPO with public contact information. The ANPD agents guide adds useful operational detail on controller, operator, suboperator, and DPO allocation. - Requirement: scope memo covering Article 3 and Article 4 - Control: role matrix for controller, operator, suboperator, and DPO - Evidence: processing inventory, contracts, appointment act, website DPO disclosure *Recommended next step* *Placement: after the requirement breakdown* ## Turn Brazil LGPD Requirements into an operational assessment Assessment Autopilot can take Brazil LGPD Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on Brazil LGPD can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Brazil LGPD Requirements](/solutions/assessment.md): Start from Brazil LGPD Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Brazil LGPD](/contact.md): Review your current process, evidence gaps, and next steps for Brazil LGPD Requirements. ## Lawful basis, transparency, and rights requirements Articles 7 to 11, 14, 18, 19, and 20 drive the user-facing core of the regime. Teams need consistent basis selection, clear notices, rights intake, immediate or 15 day response logic, and automated decision review controls. Best-interest analysis for children and adolescents and legitimate-interest balancing are now specific evidence items, not informal assumptions. - Requirement: basis register and notice content by purpose - Control: request intake, verification, response, denial, and escalation workflow - Evidence: basis log, notice versions, request case files, balancing tests, child-data assessment notes ## Security, incident, and transfer requirements Articles 46 to 49 require technical and administrative measures, while Article 48 and the current ANPD rule create a live incident communication clock. Articles 33 to 35 then impose separate transfer controls with mechanism and transparency requirements. These duties need real operational evidence such as logs, contracts, forms, tabletop outcomes, and corrective actions. - Requirement: appropriate technical and administrative safeguards - Control: incident triage and 3 business day reporting workflow - Control: transfer register, contract clause governance, and website disclosures - Evidence: security policy, access logs, incident form, communications, signed clauses, transfer notice ## Good practices and sanctions requirements Articles 50 to 52 and Resolution CD ANPD No. 4/2023 reward good-faith governance, prompt corrective action, cooperation, and durable internal procedures. A sanctions-ready program keeps that evidence current even when there is no open case. This is where remediation tracking, training, and board reporting become legally relevant. - Requirement: good practices and governance program with internal supervision - Control: quarterly control testing, exception review, and remediation closure - Evidence: committee minutes, risk decisions, training completion, test results, corrective action records ## Primary sources - [Lei No. 13.709/2018 (LGPD)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm?ref=sorena.io) - Primary legal text for the requirement domains summarized here. - [ANPD guide for controllers, processors, and DPOs (May 2021)](https://www.gov.br/anpd/pt-br/documentos-e-publicacoes/2021.05.27GuiaAgentesdeTratamento_Final.pdf?ref=sorena.io) - Official ANPD guide on role and DPO expectations. - [Resolution CD/ANPD No. 4/2023](https://www.in.gov.br/web/dou/-/resolucao-cd/anpd-n-4-de-24-de-fevereiro-de-2023-466146077?ref=sorena.io) - Official ANPD rule on dosimetry and administrative sanctions. ## Related Topic Guides - [ANPD Enforcement and Fines | Brazil LGPD Inspection, Procedure, and Sanctions](/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines.md): Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No. - [Brazil LGPD Applicability Test | Article 3 Scope, Article 4 Exclusions, Roles](/artifacts/latam/brazil-lgpd/applicability-test.md): Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation. - [Brazil LGPD Checklist | Scope, Rights, Incidents, Transfers, Evidence](/artifacts/latam/brazil-lgpd/checklist.md): Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting. - [Brazil LGPD Compliance Program Guide](/artifacts/latam/brazil-lgpd/compliance.md): Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence. - [Brazil LGPD Data Subject Rights | Articles 18 to 20 and 15 Day Access Rule](/artifacts/latam/brazil-lgpd/data-subject-rights.md): Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days. - [Brazil LGPD Deadlines and Compliance Calendar](/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar.md): Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training. - [Brazil LGPD DSAR Response Template | Immediate and 15 Day Response Logic](/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template.md): Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale. - [Brazil LGPD FAQ | Scope, Rights, Incidents, Transfers, Enforcement](/artifacts/latam/brazil-lgpd/faq.md): Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance. - [Brazil LGPD Incident Reporting and Breach Notification](/artifacts/latam/brazil-lgpd/breach-notification.md): Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No. - [Brazil LGPD International Transfers | Articles 33 to 35 and ANPD Transfer Mechanisms](/artifacts/latam/brazil-lgpd/international-transfers.md): Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules. - [Brazil LGPD Lawful Bases | Article 7, Article 11, Legitimate Interest](/artifacts/latam/brazil-lgpd/lawful-bases.md): Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data. - [Brazil LGPD Penalties and Fines | Article 52 and ANPD Dosimetry](/artifacts/latam/brazil-lgpd/penalties-and-fines.md): Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion. - [Brazil LGPD Templates | DSAR, Incident, Basis, Transfer, Governance](/artifacts/latam/brazil-lgpd/templates.md): Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments. - [Brazil LGPD vs CCPA and CPRA | Structure, Rights, Enforcement, and Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa.md): Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls. - [Brazil LGPD vs GDPR | Similarities, Differences, and Control Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr.md): Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam/brazil-lgpd/requirements --- --- title: "Brazil LGPD Templates" canonical_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/templates" source_url: "https://www.sorena.io/artifacts/latam/brazil-lgpd/templates" author: "Sorena AI" description: "Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "Brazil LGPD templates" - "LGPD DSAR template" - "LGPD incident template" - "LGPD transfer assessment template" - "ANPD template set" - "LGPD transfer template" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Brazil LGPD Templates Practical Brazil LGPD template library priorities covering DSAR responses, incident communications, lawful basis records, transfer assessments. *Template Guide* *Operational Documents* ## Brazil LGPD Templates Templates save time only when they encode the real rule and the real evidence need. Build templates around the law, ANPD forms, and the internal approvals needed to defend the outcome later. Your template library should be built around the highest-friction workflows first. For LGPD, those are rights responses, incident communication, lawful basis approval, international transfer assessment, and governance or remediation logging. ## Highest-value templates to maintain These are the templates that cut the most time and risk when they are well designed. - DSAR response template with immediate and 15 day paths - Incident intake and ANPD communication template with 3 business day and 20 business day logic - Lawful basis and legitimate-interest assessment template - International transfer assessment and clause-selection template - Governance decision and remediation log template *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep Brazil LGPD Templates in one governed evidence system SSOT can take Brazil LGPD Templates from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on Brazil LGPD can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for Brazil LGPD Templates](/solutions/ssot.md): Start from Brazil LGPD Templates and keep documents, evidence, and control records in one governed system. - [Talk through Brazil LGPD](/contact.md): Review your current process, evidence gaps, and next steps for Brazil LGPD Templates. ## Fields every template should contain A template should make it hard to forget the critical facts. That means every template needs purpose, owner, trigger, legal hook, evidence fields, and review status. - Case or record identifier and date - Owner and reviewer names - Legal basis or article reference - System, vendor, or business-unit coverage - Evidence attachments and final approval ## Template quality controls A long template can still be a weak template. The real test is whether teams can use it quickly and whether the result survives legal and regulator review. - Retire fields nobody uses and add fields the regulator or legal team repeatedly asks for - Version-control every template and keep a change log - Run periodic reviews using real cases, complaints, and incidents ## How templates connect to the control system Templates should not live as isolated documents. Each one should map to a control owner, a system of record, and a retention rule. - Link each template to the requirement it supports - Store completed templates in a searchable case repository - Use training and tabletop exercises to test whether templates are still usable ## Primary sources - [Lei No. 13.709/2018 (LGPD)](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm?ref=sorena.io) - Primary legal text driving the template library content. - [ANPD incident communication page](https://www.gov.br/anpd/pt-br/assuntos/incidente-de-seguranca?ref=sorena.io) - Official ANPD guidance and channel for incident-related templates. - [ANPD guide for controllers, processors, and DPOs (May 2021)](https://www.gov.br/anpd/pt-br/documentos-e-publicacoes/2021.05.27GuiaAgentesdeTratamento_Final.pdf?ref=sorena.io) - Official ANPD guidance relevant to role, DPO, and governance templates. ## Related Topic Guides - [ANPD Enforcement and Fines | Brazil LGPD Inspection, Procedure, and Sanctions](/artifacts/latam/brazil-lgpd/anpd-enforcement-and-fines.md): Grounded ANPD enforcement guide covering inspection procedure, sanctions progression, Article 52 factors, Resolution CD ANPD No. - [Brazil LGPD Applicability Test | Article 3 Scope, Article 4 Exclusions, Roles](/artifacts/latam/brazil-lgpd/applicability-test.md): Grounded Brazil LGPD applicability test covering Article 3 territorial reach, Article 4 exclusions, controller versus operator allocation. - [Brazil LGPD Checklist | Scope, Rights, Incidents, Transfers, Evidence](/artifacts/latam/brazil-lgpd/checklist.md): Audit-ready Brazil LGPD checklist covering scope, role allocation, lawful bases, rights timing, DPO disclosure, security, incident reporting. - [Brazil LGPD Compliance Program Guide](/artifacts/latam/brazil-lgpd/compliance.md): Build a grounded Brazil LGPD compliance program around scope, lawful bases, rights, records, incident reporting, transfers, DPO, and ANPD-ready evidence. - [Brazil LGPD Data Subject Rights | Articles 18 to 20 and 15 Day Access Rule](/artifacts/latam/brazil-lgpd/data-subject-rights.md): Grounded Brazil LGPD rights guide covering Articles 18 to 20, free requests, immediate simplified confirmation, full access declaration within 15 days. - [Brazil LGPD Deadlines and Compliance Calendar](/artifacts/latam/brazil-lgpd/deadlines-and-compliance-calendar.md): Brazil LGPD compliance calendar covering key legal and ANPD milestones plus recurring duties for rights, incidents, transfers, training. - [Brazil LGPD DSAR Response Template | Immediate and 15 Day Response Logic](/artifacts/latam/brazil-lgpd/lgpd-dsar-response-template.md): Use a Brazil LGPD DSAR response template aligned to Articles 18 and 19, immediate simplified response, full declaration within 15 days, denial rationale. - [Brazil LGPD FAQ | Scope, Rights, Incidents, Transfers, Enforcement](/artifacts/latam/brazil-lgpd/faq.md): Practical Brazil LGPD FAQ answering common scope, lawful basis, rights, incident, transfer, DPO, and enforcement questions using the law and ANPD guidance. - [Brazil LGPD Incident Reporting and Breach Notification](/artifacts/latam/brazil-lgpd/breach-notification.md): Grounded Brazil LGPD incident reporting guide covering Article 48, ANPD Resolution CD ANPD No. - [Brazil LGPD International Transfers | Articles 33 to 35 and ANPD Transfer Mechanisms](/artifacts/latam/brazil-lgpd/international-transfers.md): Grounded Brazil LGPD transfer guide covering Articles 33 to 35, adequacy, ANPD standard contractual clauses, specific clauses, binding corporate rules. - [Brazil LGPD Lawful Bases | Article 7, Article 11, Legitimate Interest](/artifacts/latam/brazil-lgpd/lawful-bases.md): Grounded Brazil LGPD lawful basis guide covering Article 7 and 11 bases, consent rules, ANPD legitimate interest guide, sensitive data. - [Brazil LGPD Penalties and Fines | Article 52 and ANPD Dosimetry](/artifacts/latam/brazil-lgpd/penalties-and-fines.md): Grounded Brazil LGPD penalties guide covering Article 52 sanctions, 2 percent fine cap, R$50 million limit per infraction, publicization, blocking, deletion. - [Brazil LGPD Requirements | Articles, Controls, Evidence, and ANPD Guidance](/artifacts/latam/brazil-lgpd/requirements.md): Operational Brazil LGPD requirements map covering scope, lawful bases, transparency, rights, records, DPO, security, incidents, transfers. - [Brazil LGPD vs CCPA and CPRA | Structure, Rights, Enforcement, and Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-ccpa.md): Grounded comparison of Brazil LGPD and CCPA or CPRA covering scope logic, legal basis model, rights timing, cross-border governance, and reusable controls. - [Brazil LGPD vs GDPR | Similarities, Differences, and Control Reuse](/artifacts/latam/brazil-lgpd/lgpd-vs-gdpr.md): Grounded comparison of Brazil LGPD and GDPR covering scope, lawful bases, rights timing, DPO rules, transfer mechanisms, incident reporting. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/latam/brazil-lgpd/templates --- --- title: "UK Online Safety Act Age Assurance Options" canonical_url: "https://www.sorena.io/artifacts/uk/online-safety-act/age-assurance-options" source_url: "https://www.sorena.io/artifacts/uk/online-safety-act/age-assurance-options" author: "Sorena AI" description: "Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK Online Safety Act age assurance" - "highly effective age assurance" - "age verification UK" - "age estimation child safety" - "PAS 1296 withdrawn" - "age assurance" - "age verification" - "age estimation" - "child access controls" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK Online Safety Act Age Assurance Options Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance. *Control Guide* *Age Assurance* ## Age Assurance Options Age assurance should follow the harm profile of the service and the age exposure decision. Use stronger measures where the service carries pornography or very high child harm risk, and keep privacy, accessibility, and failure modes in the design review. Government implementation materials state that Ofcom published age assurance guidance for online pornography in January 2025 and that Part 5 services had to move immediately to robust age checks that meet that guidance. For broader UK OSA work, age assurance should be chosen only after the child access and child risk assessments are complete. ## Use the service risk to decide the strength of assurance The right question is not whether age assurance is available. It is what level of assurance is needed to stop children reaching the harmful surface in question. Pornography and other extremely harmful content require a stronger answer than low-risk community features. Age estimation, age verification, and layered models each have different privacy, usability, and evasion consequences. - Low to moderate risk: evaluate estimation or tiered access models carefully - High risk or pornography exposure: use robust checks that actually block underage access - Document why the chosen method is effective for the relevant harm path *Recommended next step* *Placement: after the main workflow section* ## Turn Age Assurance Options into an operational assessment Assessment Autopilot can take Age Assurance Options from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on Age Assurance can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Age Assurance Options](/solutions/assessment.md): Start from Age Assurance Options and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Age Assurance](/contact.md): Review your current process, evidence gaps, and next steps for Age Assurance Options. ## Test privacy, accuracy, and inclusion together The July 2025 strategic priorities statement pushes Ofcom toward effective deployment of age assurance while supporting continued innovation and privacy respectful standards. The ICO material also makes clear that age assurance cannot be separated from the wider child-data impact of profiling, consent, defaults, and transparency. A method that produces high friction, exclusion, or excessive data retention can still fail the wider governance test. - Run a DPIA and document retention, deletion, and vendor boundaries - Measure false positives, false negatives, and easy bypass routes - Check accessibility for users who lack standard identity documents or devices ## Do not over-rely on legacy standards labels PAS 1296:2018 was withdrawn on 5 January 2026, so it should not be treated as a current safe harbour by itself. It can still inform historical control thinking, but live programs should look at current regulatory guidance, measurable effectiveness, and newer standards work such as the IEEE child digital experience initiatives. In practice, Ofcom and ICO readiness comes from evidence of effectiveness and governance, not from dropping a standards name into a vendor contract. - Review vendor claims against current regulatory expectations, not only certificates - Retest assurance methods after product, policy, or threat changes - Keep an exit plan if a chosen method fails on privacy, accuracy, or scale ## Primary sources - [Online Safety Act explainer](https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io) - Current government implementation status, deadlines, and plain language explanation of the regime. - [Statement of Strategic Priorities for Online Safety](https://www.gov.uk/government/publications/statement-of-strategic-priorities-for-online-safety?ref=sorena.io) - July 2025 strategic priorities for Ofcom, including safety by design, age assurance, and small but risky services. - [ICO introduction to the Children's Code](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/introduction-to-the-childrens-code/?ref=sorena.io) - ICO explanation of scope for information society services likely to be accessed by children and the 15 standards. - [ICO profiling guidance for age appropriate design](https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/age-appropriate-design/profiling/?ref=sorena.io) - Detailed control guidance for profiling, DPIAs, age assurance, and child-safe defaults. - [BSI PAS 1296 publication record](https://knowledge.bsigroup.com/products/online-age-checking-provision-and-use-of-online-age-check-services-code-of-practice?ref=sorena.io) - Issuer record showing PAS 1296:2018 and its withdrawal on 5 January 2026. - [IEEE trustworthy digital experiences for children initiative](https://standards.ieee.org/initiatives/trustworthy-digital-experiences/?ref=sorena.io) - Background on IEEE 2089 and related age-appropriate digital service standards. ## Related Topic Guides - [UK Online Safety Act Applicability Test | Regulated Service, Exemptions, and UK Scope](/artifacts/uk/online-safety-act/applicability-test.md): Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope. - [UK Online Safety Act Checklist | Scope, Risk, Child Safety, Moderation, and Evidence](/artifacts/uk/online-safety-act/checklist.md): Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints. - [UK Online Safety Act Children Safety Duties | Child Access, Child Risk, and Age Assurance](/artifacts/uk/online-safety-act/children-safety-duties.md): Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments. - [UK Online Safety Act Compliance Program | Governance, Controls, and Ofcom Readiness](/artifacts/uk/online-safety-act/compliance.md): Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics. - [UK Online Safety Act Content Moderation and Appeals | Complaints, Terms Enforcement, and Redress](/artifacts/uk/online-safety-act/content-moderation-and-appeals.md): Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement. - [UK Online Safety Act Deadlines and Compliance Calendar | 2023 to 2026 Milestones](/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar.md): Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes. - [UK Online Safety Act Enforcement and Penalties | Ofcom Notices, Penalties, and Escalation](/artifacts/uk/online-safety-act/enforcement-and-penalties.md): Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions. - [UK Online Safety Act FAQ | Scope, Child Duties, Categories, and Ofcom Enforcement](/artifacts/uk/online-safety-act/faq.md): Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties. - [UK Online Safety Act Illegal Content Duties | Illegal Harms, Priority Offences, and Risk Assessments](/artifacts/uk/online-safety-act/illegal-content-duties-explained.md): Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments. - [UK Online Safety Act Penalties and Fines | GBP 18 Million, 10 Percent Revenue, and Liability](/artifacts/uk/online-safety-act/penalties-and-fines.md): Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap. - [UK Online Safety Act Requirements | Sections, Deadlines, Controls, and Evidence](/artifacts/uk/online-safety-act/requirements.md): Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation. - [UK Online Safety Act Risk Assessment Template | Illegal Content and Child Safety Template](/artifacts/uk/online-safety-act/online-safety-risk-assessment-template.md): Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety. - [UK Online Safety Act Risk Assessments Playbook | How to Run Illegal and Children Risk Reviews](/artifacts/uk/online-safety-act/risk-assessments-playbook.md): Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design. - [UK Online Safety Act Service Scope and Categorization | Category 1, 2A, 2B, and Part 3 Logic](/artifacts/uk/online-safety-act/service-scope-and-categorization.md): Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A. - [UK Online Safety Act vs EU Digital Services Act | Scope, Child Safety, and Enforcement Differences](/artifacts/uk/online-safety-act/online-safety-act-vs-dsa.md): Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/online-safety-act/age-assurance-options --- --- title: "UK Online Safety Act Applicability Test" canonical_url: "https://www.sorena.io/artifacts/uk/online-safety-act/applicability-test" source_url: "https://www.sorena.io/artifacts/uk/online-safety-act/applicability-test" author: "Sorena AI" description: "Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK Online Safety Act applicability" - "regulated user-to-user service" - "regulated search service" - "Online Safety Act exemptions" - "likely to be accessed by children" - "provider pornography scope" - "UK Online Safety Act scope" - "UK online safety exemptions" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK Online Safety Act Applicability Test Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope. *Applicability Guide* *Scope and Exemptions* ## UK Online Safety Act Applicability Test Start with the statutory service test before you build a controls program. Most wasted compliance work comes from treating a product family as one service when the Act is applied service by service and feature by feature. The right order is simple. First test whether you have a regulated user-to-user service, a regulated search service, or provider pornography duties. Then check the exemptions and mixed-service boundaries. Then run the child-access test and only after that move into risk assessment, age assurance, or categorisation work. ## Start with sections 3 to 5 and the service architecture The Act applies to search services and services that allow users to generate, upload, or share content or interact with one another. That analysis must be done at the actual service or relevant part of a service, not only at brand level. Where a product contains several surfaces, document which parts are user-to-user, which parts are search, and which parts are outside scope. - Map every product surface to user-to-user, search, provider content, or out of scope - Separate the core service from embedded community, chat, or content-sharing features - Record whether the duty falls on one service or on distinct service parts ## Check exclusions before you assume Part 3 duties Schedule 1 excludes certain services, including internal business services. The legislation also treats some provider pornography scenarios separately, so the right question is not only whether a service is social or searchable, but which chapter and schedule apply. This is where many teams over-scope the program or miss a narrow but important duty set. - Review Schedule 1 exemptions such as internal business services - Check whether provider pornography duties under sections 79 to 81 apply - Document why each exclusion or special regime does or does not apply ## Run the child-access test and note future category triggers If the service is likely to be accessed by children, the child access and child safety regime comes into play. The Act points to section 37 for the meaning of likely to be accessed by children, and the implementation sequence required services to complete children's access assessments before children's risk assessments. Separately, some services will later be categorised as Category 1, 2A, or 2B. The threshold regulations were laid on 16 December 2024, the register was expected in summer 2025, and further category specific codes were expected from early 2026. - Complete a child access assessment where the service could realistically attract children - Track category logic separately from base Part 3 duties - Reassess scope after product launches, mergers, market expansion, or major UX changes *Recommended next step* *Placement: after the applicability result* ## Turn UK Online Safety Act Applicability Test into an operational assessment Assessment Autopilot can take UK Online Safety Act Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on UK Online Safety Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK Online Safety Act Applicability Test](/solutions/assessment.md): Start from UK Online Safety Act Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK Online Safety Act](/contact.md): Review your current process, evidence gaps, and next steps for UK Online Safety Act Applicability Test. ## Primary sources - [Online Safety Act 2023](https://www.legislation.gov.uk/ukpga/2023/50/contents?ref=sorena.io) - Primary legislation for scope, duties, risk assessment, enforcement, transparency, and complaints provisions. - [Online Safety Act explainer](https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io) - Current government implementation status, deadlines, and plain language explanation of the regime. - [ICO introduction to the Children's Code](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/introduction-to-the-childrens-code/?ref=sorena.io) - ICO explanation of scope for information society services likely to be accessed by children and the 15 standards. ## Related Topic Guides - [UK Online Safety Act Age Assurance Options | Age Estimation, Verification, and Child Access Controls](/artifacts/uk/online-safety-act/age-assurance-options.md): Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance. - [UK Online Safety Act Checklist | Scope, Risk, Child Safety, Moderation, and Evidence](/artifacts/uk/online-safety-act/checklist.md): Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints. - [UK Online Safety Act Children Safety Duties | Child Access, Child Risk, and Age Assurance](/artifacts/uk/online-safety-act/children-safety-duties.md): Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments. - [UK Online Safety Act Compliance Program | Governance, Controls, and Ofcom Readiness](/artifacts/uk/online-safety-act/compliance.md): Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics. - [UK Online Safety Act Content Moderation and Appeals | Complaints, Terms Enforcement, and Redress](/artifacts/uk/online-safety-act/content-moderation-and-appeals.md): Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement. - [UK Online Safety Act Deadlines and Compliance Calendar | 2023 to 2026 Milestones](/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar.md): Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes. - [UK Online Safety Act Enforcement and Penalties | Ofcom Notices, Penalties, and Escalation](/artifacts/uk/online-safety-act/enforcement-and-penalties.md): Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions. - [UK Online Safety Act FAQ | Scope, Child Duties, Categories, and Ofcom Enforcement](/artifacts/uk/online-safety-act/faq.md): Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties. - [UK Online Safety Act Illegal Content Duties | Illegal Harms, Priority Offences, and Risk Assessments](/artifacts/uk/online-safety-act/illegal-content-duties-explained.md): Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments. - [UK Online Safety Act Penalties and Fines | GBP 18 Million, 10 Percent Revenue, and Liability](/artifacts/uk/online-safety-act/penalties-and-fines.md): Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap. - [UK Online Safety Act Requirements | Sections, Deadlines, Controls, and Evidence](/artifacts/uk/online-safety-act/requirements.md): Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation. - [UK Online Safety Act Risk Assessment Template | Illegal Content and Child Safety Template](/artifacts/uk/online-safety-act/online-safety-risk-assessment-template.md): Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety. - [UK Online Safety Act Risk Assessments Playbook | How to Run Illegal and Children Risk Reviews](/artifacts/uk/online-safety-act/risk-assessments-playbook.md): Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design. - [UK Online Safety Act Service Scope and Categorization | Category 1, 2A, 2B, and Part 3 Logic](/artifacts/uk/online-safety-act/service-scope-and-categorization.md): Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A. - [UK Online Safety Act vs EU Digital Services Act | Scope, Child Safety, and Enforcement Differences](/artifacts/uk/online-safety-act/online-safety-act-vs-dsa.md): Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/online-safety-act/applicability-test --- --- title: "UK Online Safety Act Checklist" canonical_url: "https://www.sorena.io/artifacts/uk/online-safety-act/checklist" source_url: "https://www.sorena.io/artifacts/uk/online-safety-act/checklist" author: "Sorena AI" description: "Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK Online Safety Act checklist" - "online safety act audit checklist" - "Ofcom readiness checklist" - "child safety checklist" - "UK OSA checklist" - "audit readiness" - "risk assessment" - "child safety" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK Online Safety Act Checklist Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints. *Checklist* *Execution and Evidence* ## UK Online Safety Act Checklist Use this checklist to confirm that the service is actually operating inside the regime. Each item should point to a dated artifact, a named owner, and a review trigger. The right UK OSA checklist is not a list of policy topics. It is a control register that proves the service has been scoped correctly, assessed on time, updated after changes, and supported by live moderation, child safety, and regulator-response processes. ## Scope and legal baseline checklist Confirm the service classification, exemption analysis, and child-access position before you test any downstream control items. The first evidence point should be a current scope memo and versioned service inventory. - Regulated service classification approved - Schedule 1 exemption analysis completed - Child access position documented - Category exposure noted separately from base duties *Recommended next step* *Placement: after the checklist block* ## Turn UK Online Safety Act Checklist into an operational assessment Assessment Autopilot can take UK Online Safety Act Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on UK Online Safety Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK Online Safety Act Checklist](/solutions/assessment.md): Start from UK Online Safety Act Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK Online Safety Act](/contact.md): Review your current process, evidence gaps, and next steps for UK Online Safety Act Checklist. ## Risk and control checklist Verify that the illegal content risk assessment, child access assessment, and children risk assessment were completed on time where required and that they now drive actual controls. Look for evidence of tuning, testing, and exception handling rather than only first-version signoff. - Illegal content risk assessment completed and refreshed - Children access and children risk assessments completed where relevant - Moderation, age assurance, complaints, and escalation controls tested - Terms enforcement QA and user-redress data retained ## Regulator readiness checklist Ofcom readiness means the service can answer information requests quickly, explain its risk logic, and produce current evidence for the controls it claims to run. A checklist item is not complete if the artifact exists but no one can locate or explain it. - Information notice response owner named - Senior management escalation path documented - Transparency and category reporting data sources identified - Evidence folder tested with a mock regulator request ## Primary sources - [Online Safety Act 2023](https://www.legislation.gov.uk/ukpga/2023/50/contents?ref=sorena.io) - Primary legislation for scope, duties, risk assessment, enforcement, transparency, and complaints provisions. - [Online Safety Act explainer](https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io) - Current government implementation status, deadlines, and plain language explanation of the regime. - [ICO audit guide for the Age Appropriate Design Code](https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/age-appropriate-design/?ref=sorena.io) - Audit scope and control themes for children's data, including age assurance, privacy settings, geolocation, profiling, and nudge techniques. ## Related Topic Guides - [UK Online Safety Act Age Assurance Options | Age Estimation, Verification, and Child Access Controls](/artifacts/uk/online-safety-act/age-assurance-options.md): Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance. - [UK Online Safety Act Applicability Test | Regulated Service, Exemptions, and UK Scope](/artifacts/uk/online-safety-act/applicability-test.md): Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope. - [UK Online Safety Act Children Safety Duties | Child Access, Child Risk, and Age Assurance](/artifacts/uk/online-safety-act/children-safety-duties.md): Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments. - [UK Online Safety Act Compliance Program | Governance, Controls, and Ofcom Readiness](/artifacts/uk/online-safety-act/compliance.md): Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics. - [UK Online Safety Act Content Moderation and Appeals | Complaints, Terms Enforcement, and Redress](/artifacts/uk/online-safety-act/content-moderation-and-appeals.md): Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement. - [UK Online Safety Act Deadlines and Compliance Calendar | 2023 to 2026 Milestones](/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar.md): Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes. - [UK Online Safety Act Enforcement and Penalties | Ofcom Notices, Penalties, and Escalation](/artifacts/uk/online-safety-act/enforcement-and-penalties.md): Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions. - [UK Online Safety Act FAQ | Scope, Child Duties, Categories, and Ofcom Enforcement](/artifacts/uk/online-safety-act/faq.md): Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties. - [UK Online Safety Act Illegal Content Duties | Illegal Harms, Priority Offences, and Risk Assessments](/artifacts/uk/online-safety-act/illegal-content-duties-explained.md): Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments. - [UK Online Safety Act Penalties and Fines | GBP 18 Million, 10 Percent Revenue, and Liability](/artifacts/uk/online-safety-act/penalties-and-fines.md): Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap. - [UK Online Safety Act Requirements | Sections, Deadlines, Controls, and Evidence](/artifacts/uk/online-safety-act/requirements.md): Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation. - [UK Online Safety Act Risk Assessment Template | Illegal Content and Child Safety Template](/artifacts/uk/online-safety-act/online-safety-risk-assessment-template.md): Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety. - [UK Online Safety Act Risk Assessments Playbook | How to Run Illegal and Children Risk Reviews](/artifacts/uk/online-safety-act/risk-assessments-playbook.md): Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design. - [UK Online Safety Act Service Scope and Categorization | Category 1, 2A, 2B, and Part 3 Logic](/artifacts/uk/online-safety-act/service-scope-and-categorization.md): Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A. - [UK Online Safety Act vs EU Digital Services Act | Scope, Child Safety, and Enforcement Differences](/artifacts/uk/online-safety-act/online-safety-act-vs-dsa.md): Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/online-safety-act/checklist --- --- title: "UK Online Safety Act Children Safety Duties" canonical_url: "https://www.sorena.io/artifacts/uk/online-safety-act/children-safety-duties" source_url: "https://www.sorena.io/artifacts/uk/online-safety-act/children-safety-duties" author: "Sorena AI" description: "Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK Online Safety Act children safety duties" - "children access assessment" - "children risk assessment" - "section 81 online safety act" - "age assurance children" - "children safety duties" - "age assurance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK Online Safety Act Children Safety Duties Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments. *Duty Guide* *Children Safety* ## Children Safety Duties The child safety regime had a staged rollout through 2025 and now needs to be live in operations. Services likely to be accessed by children need more than age gates. They need a documented child access decision, a children risk assessment, and controls that actually change the product experience. The government implementation materials make the sequence clear. Ofcom published age assurance guidance for online pornography in January 2025, section 81 came into force on 17 January 2025, child access assessments were due by 16 April 2025, and services likely to be accessed by children then had until 24 July 2025 to complete their children's risk assessment. ## Start with the children access assessment Before you apply child safety controls, determine whether the service is likely to be accessed by children. This assessment should consider the actual service experience, not only the intended audience in marketing copy. The output should be a documented yes or no decision with evidence and review triggers. - Record the age exposure evidence used for the decision - Note any features that materially increase the chance children will access the service - Set triggers for reassessment after major product or market changes ## Use the children risk assessment to drive design controls Services likely to be accessed by children then need a children risk assessment. Government materials highlight duties to stop children encountering harmful and age inappropriate content, including pornography and legal content that encourages, promotes, or instructs on suicide, self-harm, or eating disorders. This is a systems design exercise, not a disclosure exercise. - Map harm scenarios by age band and service feature - Set age restrictions and age assurance measures where the service relies on them - Link each child risk to a prevention, detection, response, and review control ## Bring ICO child-data controls into the same design review The ICO Children's Code applies to information society services likely to be accessed by children and sets out 15 standards of age-appropriate design. In practice, age assurance, privacy defaults, geolocation, profiling, and nudge techniques should be reviewed in the same product forum as UK OSA child safety controls. Doing this together reduces the risk of building a child safety control that creates a child privacy problem. - Default to high privacy and avoid harmful profiling patterns - Switch off geolocation by default unless there is a compelling reason not to - Use age assurance and age estimation in a way that is proportionate, privacy aware, and testable *Recommended next step* *Placement: near the end of the main content before related guides* ## Use Children Safety Duties as a cited research workflow Research Copilot can take Children Safety Duties from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on Children Safety can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Children Safety Duties](/solutions/research-copilot.md): Start from Children Safety Duties and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Children Safety](/contact.md): Review your current process, evidence gaps, and next steps for Children Safety Duties. ## Primary sources - [Online Safety Act explainer](https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io) - Current government implementation status, deadlines, and plain language explanation of the regime. - [ICO introduction to the Children's Code](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/introduction-to-the-childrens-code/?ref=sorena.io) - ICO explanation of scope for information society services likely to be accessed by children and the 15 standards. - [ICO audit guide for the Age Appropriate Design Code](https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/age-appropriate-design/?ref=sorena.io) - Audit scope and control themes for children's data, including age assurance, privacy settings, geolocation, profiling, and nudge techniques. ## Related Topic Guides - [UK Online Safety Act Age Assurance Options | Age Estimation, Verification, and Child Access Controls](/artifacts/uk/online-safety-act/age-assurance-options.md): Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance. - [UK Online Safety Act Applicability Test | Regulated Service, Exemptions, and UK Scope](/artifacts/uk/online-safety-act/applicability-test.md): Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope. - [UK Online Safety Act Checklist | Scope, Risk, Child Safety, Moderation, and Evidence](/artifacts/uk/online-safety-act/checklist.md): Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints. - [UK Online Safety Act Compliance Program | Governance, Controls, and Ofcom Readiness](/artifacts/uk/online-safety-act/compliance.md): Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics. - [UK Online Safety Act Content Moderation and Appeals | Complaints, Terms Enforcement, and Redress](/artifacts/uk/online-safety-act/content-moderation-and-appeals.md): Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement. - [UK Online Safety Act Deadlines and Compliance Calendar | 2023 to 2026 Milestones](/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar.md): Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes. - [UK Online Safety Act Enforcement and Penalties | Ofcom Notices, Penalties, and Escalation](/artifacts/uk/online-safety-act/enforcement-and-penalties.md): Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions. - [UK Online Safety Act FAQ | Scope, Child Duties, Categories, and Ofcom Enforcement](/artifacts/uk/online-safety-act/faq.md): Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties. - [UK Online Safety Act Illegal Content Duties | Illegal Harms, Priority Offences, and Risk Assessments](/artifacts/uk/online-safety-act/illegal-content-duties-explained.md): Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments. - [UK Online Safety Act Penalties and Fines | GBP 18 Million, 10 Percent Revenue, and Liability](/artifacts/uk/online-safety-act/penalties-and-fines.md): Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap. - [UK Online Safety Act Requirements | Sections, Deadlines, Controls, and Evidence](/artifacts/uk/online-safety-act/requirements.md): Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation. - [UK Online Safety Act Risk Assessment Template | Illegal Content and Child Safety Template](/artifacts/uk/online-safety-act/online-safety-risk-assessment-template.md): Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety. - [UK Online Safety Act Risk Assessments Playbook | How to Run Illegal and Children Risk Reviews](/artifacts/uk/online-safety-act/risk-assessments-playbook.md): Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design. - [UK Online Safety Act Service Scope and Categorization | Category 1, 2A, 2B, and Part 3 Logic](/artifacts/uk/online-safety-act/service-scope-and-categorization.md): Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A. - [UK Online Safety Act vs EU Digital Services Act | Scope, Child Safety, and Enforcement Differences](/artifacts/uk/online-safety-act/online-safety-act-vs-dsa.md): Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/online-safety-act/children-safety-duties --- --- title: "UK Online Safety Act Compliance Program" canonical_url: "https://www.sorena.io/artifacts/uk/online-safety-act/compliance" source_url: "https://www.sorena.io/artifacts/uk/online-safety-act/compliance" author: "Sorena AI" description: "Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK Online Safety Act compliance program" - "Ofcom readiness program" - "online safety governance" - "child safety governance" - "compliance program" - "governance" - "Ofcom readiness" - "online safety controls" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK Online Safety Act Compliance Program Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics. *Program Guide* *Governance and Operations* ## UK Online Safety Act Compliance Program A viable UK OSA program combines legal interpretation, product design, moderation execution, and evidence discipline. The goal is not to finish one assessment. It is to keep each service inside a defensible operating posture as the regime evolves. A strong UK OSA program has four layers: service scoping, risk assessment, live controls, and regulator response readiness. The same governance should also absorb strategic changes such as category determinations, Ofcom consultations, and updates that affect child safety or age assurance expectations. ## Set up governance by service, not only by company Each regulated service or service part should have a named accountable owner, a legal contact, a moderation or trust and safety lead, and a product lead. A central policy team alone is not enough because the Act works through service functionality and service-specific risk. This also makes reassessment after launches or incidents much faster. - Service owner, legal owner, and operational owner assigned - Quarterly governance cadence with urgent escalation criteria - One evidence location per service and duty set ## Keep controls tied to the assessed risk and duty sequence Illegal content duties, child access duties, child safety duties, terms duties, and category duties should each trace back to an assessed risk or a direct statutory trigger. This prevents over-control in low-risk areas and under-control in high-risk areas. The program should also show where ICO child-data controls intersect with child safety controls. - Control matrix linked to each assessment output - Change management for new features and policy shifts - Joint product, moderation, privacy, and legal review for child-facing changes ## Measure readiness through evidence retrieval, not policy volume Ofcom and internal reviewers will ask for evidence. That means the program should routinely test whether the service can produce scope decisions, assessments, moderation metrics, complaints records, and action logs quickly and coherently. If the evidence cannot be retrieved or explained, the control is weaker than it looks. - Run mock information notice exercises - Review evidence quality after major incidents - Maintain one remediation tracker across duty sets *Recommended next step* *Placement: after the compliance steps* ## Turn UK Online Safety Act Compliance Program into an operational assessment Assessment Autopilot can take UK Online Safety Act Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on UK Online Safety Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK Online Safety Act Compliance Program](/solutions/assessment.md): Start from UK Online Safety Act Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK Online Safety Act](/contact.md): Review your current process, evidence gaps, and next steps for UK Online Safety Act Compliance Program. ## Primary sources - [Online Safety Act 2023](https://www.legislation.gov.uk/ukpga/2023/50/contents?ref=sorena.io) - Primary legislation for scope, duties, risk assessment, enforcement, transparency, and complaints provisions. - [Online Safety Act explainer](https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io) - Current government implementation status, deadlines, and plain language explanation of the regime. - [Statement of Strategic Priorities for Online Safety](https://www.gov.uk/government/publications/statement-of-strategic-priorities-for-online-safety?ref=sorena.io) - July 2025 strategic priorities for Ofcom, including safety by design, age assurance, and small but risky services. - [ICO audit guide for the Age Appropriate Design Code](https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/age-appropriate-design/?ref=sorena.io) - Audit scope and control themes for children's data, including age assurance, privacy settings, geolocation, profiling, and nudge techniques. ## Related Topic Guides - [UK Online Safety Act Age Assurance Options | Age Estimation, Verification, and Child Access Controls](/artifacts/uk/online-safety-act/age-assurance-options.md): Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance. - [UK Online Safety Act Applicability Test | Regulated Service, Exemptions, and UK Scope](/artifacts/uk/online-safety-act/applicability-test.md): Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope. - [UK Online Safety Act Checklist | Scope, Risk, Child Safety, Moderation, and Evidence](/artifacts/uk/online-safety-act/checklist.md): Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints. - [UK Online Safety Act Children Safety Duties | Child Access, Child Risk, and Age Assurance](/artifacts/uk/online-safety-act/children-safety-duties.md): Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments. - [UK Online Safety Act Content Moderation and Appeals | Complaints, Terms Enforcement, and Redress](/artifacts/uk/online-safety-act/content-moderation-and-appeals.md): Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement. - [UK Online Safety Act Deadlines and Compliance Calendar | 2023 to 2026 Milestones](/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar.md): Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes. - [UK Online Safety Act Enforcement and Penalties | Ofcom Notices, Penalties, and Escalation](/artifacts/uk/online-safety-act/enforcement-and-penalties.md): Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions. - [UK Online Safety Act FAQ | Scope, Child Duties, Categories, and Ofcom Enforcement](/artifacts/uk/online-safety-act/faq.md): Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties. - [UK Online Safety Act Illegal Content Duties | Illegal Harms, Priority Offences, and Risk Assessments](/artifacts/uk/online-safety-act/illegal-content-duties-explained.md): Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments. - [UK Online Safety Act Penalties and Fines | GBP 18 Million, 10 Percent Revenue, and Liability](/artifacts/uk/online-safety-act/penalties-and-fines.md): Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap. - [UK Online Safety Act Requirements | Sections, Deadlines, Controls, and Evidence](/artifacts/uk/online-safety-act/requirements.md): Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation. - [UK Online Safety Act Risk Assessment Template | Illegal Content and Child Safety Template](/artifacts/uk/online-safety-act/online-safety-risk-assessment-template.md): Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety. - [UK Online Safety Act Risk Assessments Playbook | How to Run Illegal and Children Risk Reviews](/artifacts/uk/online-safety-act/risk-assessments-playbook.md): Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design. - [UK Online Safety Act Service Scope and Categorization | Category 1, 2A, 2B, and Part 3 Logic](/artifacts/uk/online-safety-act/service-scope-and-categorization.md): Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A. - [UK Online Safety Act vs EU Digital Services Act | Scope, Child Safety, and Enforcement Differences](/artifacts/uk/online-safety-act/online-safety-act-vs-dsa.md): Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/online-safety-act/compliance --- --- title: "UK Online Safety Act Content Moderation and Appeals" canonical_url: "https://www.sorena.io/artifacts/uk/online-safety-act/content-moderation-and-appeals" source_url: "https://www.sorena.io/artifacts/uk/online-safety-act/content-moderation-and-appeals" author: "Sorena AI" description: "Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK Online Safety Act complaints procedures" - "terms of service duties" - "content moderation online safety act" - "user redress Ofcom" - "content moderation" - "complaints procedures" - "terms of service" - "user redress" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK Online Safety Act Content Moderation and Appeals Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement. *Operations Guide* *Moderation and Redress* ## Content Moderation and Appeals The Act cares about process quality as much as headline policy text. If reporting is hard to find, complaints are weak, or terms are enforced inconsistently, the evidence will not support the program under scrutiny. The legislation includes dedicated duties about content reporting and complaints procedures for both user-to-user and search services. Category 1 services also face terms-of-service duties that require them to act in line with what they say they will do and to give users effective reporting and redress routes. ## Make reporting and complaints usable in practice Sections 21 and 32 signal that complaints procedure design is not optional decoration. It is part of the compliance model for user-to-user and search services. The strategic priorities statement also stresses simple, accessible complaints systems. Users should be able to report illegal content, challenge decisions, and understand what happens next. - Make reporting routes easy to find and easy to use - Set clear intake categories and routing rules - Track acknowledgement, decision, escalation, and closure timing ## Treat terms enforcement as an evidence problem For Category 1 services, sections 71 and 72 create obligations around acting in accordance with published terms and being transparent about how those terms are applied. A service that says it removes or restricts certain content must be able to prove that it applies those rules consistently. This means moderation logs, reviewer guidance, and QA data matter as much as the policy wording. - Align policy text, reviewer instructions, and automation thresholds - Retain decision logs and moderation QA samples - Explain major error patterns and corrective actions ## Design redress for users, parents, and high harm scenarios The July 2025 strategic priorities statement expects easy-to-find and humane systems, especially when parents or carers need information after a serious child harm event. That requires more than a generic support queue. Escalation design should therefore distinguish routine disputes from child safety, suicide, self-harm, fraud, or bereavement scenarios. - Create specialised escalation paths for severe child safety and suicide related issues - Give parents and carers a clear request route where the framework expects it - Review complaint outcomes for bias, inconsistency, and backlog risk *Recommended next step* *Placement: near the end of the main content before related guides* ## Use Content Moderation and Appeals as a cited research workflow Research Copilot can take Content Moderation and Appeals from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on Content Moderation can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Content Moderation and Appeals](/solutions/research-copilot.md): Start from Content Moderation and Appeals and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Content Moderation](/contact.md): Review your current process, evidence gaps, and next steps for Content Moderation and Appeals. ## Primary sources - [Online Safety Act 2023](https://www.legislation.gov.uk/ukpga/2023/50/contents?ref=sorena.io) - Primary legislation for scope, duties, risk assessment, enforcement, transparency, and complaints provisions. - [Online Safety Act explainer](https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io) - Current government implementation status, deadlines, and plain language explanation of the regime. - [Statement of Strategic Priorities for Online Safety](https://www.gov.uk/government/publications/statement-of-strategic-priorities-for-online-safety?ref=sorena.io) - July 2025 strategic priorities for Ofcom, including safety by design, age assurance, and small but risky services. ## Related Topic Guides - [UK Online Safety Act Age Assurance Options | Age Estimation, Verification, and Child Access Controls](/artifacts/uk/online-safety-act/age-assurance-options.md): Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance. - [UK Online Safety Act Applicability Test | Regulated Service, Exemptions, and UK Scope](/artifacts/uk/online-safety-act/applicability-test.md): Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope. - [UK Online Safety Act Checklist | Scope, Risk, Child Safety, Moderation, and Evidence](/artifacts/uk/online-safety-act/checklist.md): Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints. - [UK Online Safety Act Children Safety Duties | Child Access, Child Risk, and Age Assurance](/artifacts/uk/online-safety-act/children-safety-duties.md): Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments. - [UK Online Safety Act Compliance Program | Governance, Controls, and Ofcom Readiness](/artifacts/uk/online-safety-act/compliance.md): Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics. - [UK Online Safety Act Deadlines and Compliance Calendar | 2023 to 2026 Milestones](/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar.md): Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes. - [UK Online Safety Act Enforcement and Penalties | Ofcom Notices, Penalties, and Escalation](/artifacts/uk/online-safety-act/enforcement-and-penalties.md): Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions. - [UK Online Safety Act FAQ | Scope, Child Duties, Categories, and Ofcom Enforcement](/artifacts/uk/online-safety-act/faq.md): Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties. - [UK Online Safety Act Illegal Content Duties | Illegal Harms, Priority Offences, and Risk Assessments](/artifacts/uk/online-safety-act/illegal-content-duties-explained.md): Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments. - [UK Online Safety Act Penalties and Fines | GBP 18 Million, 10 Percent Revenue, and Liability](/artifacts/uk/online-safety-act/penalties-and-fines.md): Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap. - [UK Online Safety Act Requirements | Sections, Deadlines, Controls, and Evidence](/artifacts/uk/online-safety-act/requirements.md): Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation. - [UK Online Safety Act Risk Assessment Template | Illegal Content and Child Safety Template](/artifacts/uk/online-safety-act/online-safety-risk-assessment-template.md): Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety. - [UK Online Safety Act Risk Assessments Playbook | How to Run Illegal and Children Risk Reviews](/artifacts/uk/online-safety-act/risk-assessments-playbook.md): Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design. - [UK Online Safety Act Service Scope and Categorization | Category 1, 2A, 2B, and Part 3 Logic](/artifacts/uk/online-safety-act/service-scope-and-categorization.md): Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A. - [UK Online Safety Act vs EU Digital Services Act | Scope, Child Safety, and Enforcement Differences](/artifacts/uk/online-safety-act/online-safety-act-vs-dsa.md): Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/online-safety-act/content-moderation-and-appeals --- --- title: "UK Online Safety Act Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK Online Safety Act deadlines" - "24 July 2025 children risk assessment" - "16 March 2025 illegal risk assessment" - "section 81 17 January 2025" - "deadlines" - "compliance calendar" - "Ofcom milestones" - "children risk deadline" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK Online Safety Act Deadlines and Compliance Calendar Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes. *Calendar* *Implementation Milestones* ## Deadlines and Compliance Calendar Use the live implementation sequence, not an undated roadmap. The calendar matters because the regime did not switch on all at once. Different duties and codes arrived in stages. The UK OSA timeline is operationally important because the assessment and control duties arrived in waves. Teams that do not separate the illegal harms, provider pornography, children access, children risk, and category phases will mis-sequence controls and evidence. ## Core enacted and early implementation dates The Act passed on 26 October 2023. Criminal offences introduced by the Act came into effect on 31 January 2024. These early milestones matter because they set the baseline for enforcement culture and service awareness before the main codes landed. Treat them as the start of the regime, not historical background only. - 26 October 2023: Act passed into law - 31 January 2024: criminal offences took effect - 11 September 2024: Ofcom approach to small but risky services referenced by government ## Illegal harms and children rollout dates The illegal harms codes were approved after being laid on 16 December 2024 and Ofcom published illegal risk assessment guidance the same day. Government materials state that illegal risk assessments were due by 16 March 2025 and that Ofcom could enforce from 17 March 2025. For children, January 2025 brought age assurance guidance for online pornography and the section 81 commencement on 17 January 2025. Child access assessments were due by 16 April 2025. Children risk assessments were due by 24 July 2025 after the child safety codes were laid on 24 April 2025. - 16 December 2024: illegal harms codes and guidance published - 16 March 2025: illegal content risk assessment deadline - 17 January 2025: section 81 duty in force - 16 April 2025: children access assessment deadline - 24 April 2025: child safety codes laid and risk guidance published - 24 July 2025: children risk assessment deadline ## Category and strategic-priority milestones Threshold regulations for categories were laid on 16 December 2024. The government expected Ofcom to publish the register of categorised services in summer 2025 and to consult on additional duties from early 2026. The Statement of Strategic Priorities was designated on 2 July 2025 and should be tracked because it shapes Ofcom focus on safety by design, age assurance, and small but risky services. - 16 December 2024: category thresholds laid - 2 July 2025: strategic priorities statement designated - summer 2025: expected register of categorised services - early 2026: expected consultation on additional category duties *Recommended next step* *Placement: after the timeline or milestone section* ## Turn Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on Deadlines and can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Deadlines and Compliance Calendar](/solutions/assessment.md): Start from Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Deadlines and](/contact.md): Review your current process, evidence gaps, and next steps for Deadlines and Compliance Calendar. ## Primary sources - [Online Safety Act explainer](https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io) - Current government implementation status, deadlines, and plain language explanation of the regime. - [Statement of Strategic Priorities for Online Safety](https://www.gov.uk/government/publications/statement-of-strategic-priorities-for-online-safety?ref=sorena.io) - July 2025 strategic priorities for Ofcom, including safety by design, age assurance, and small but risky services. - [Explanatory Memorandum to the Statement of Strategic Priorities](https://assets.publishing.service.gov.uk/media/67aff474a4075fa7b985194c/Explanatory_Memorandum_to_the_Statement_of_Strategic_Priorities_for_Online_Safety.pdf?ref=sorena.io) - Consultation and policy context for the July 2025 strategic priorities statement. ## Related Topic Guides - [UK Online Safety Act Age Assurance Options | Age Estimation, Verification, and Child Access Controls](/artifacts/uk/online-safety-act/age-assurance-options.md): Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance. - [UK Online Safety Act Applicability Test | Regulated Service, Exemptions, and UK Scope](/artifacts/uk/online-safety-act/applicability-test.md): Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope. - [UK Online Safety Act Checklist | Scope, Risk, Child Safety, Moderation, and Evidence](/artifacts/uk/online-safety-act/checklist.md): Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints. - [UK Online Safety Act Children Safety Duties | Child Access, Child Risk, and Age Assurance](/artifacts/uk/online-safety-act/children-safety-duties.md): Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments. - [UK Online Safety Act Compliance Program | Governance, Controls, and Ofcom Readiness](/artifacts/uk/online-safety-act/compliance.md): Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics. - [UK Online Safety Act Content Moderation and Appeals | Complaints, Terms Enforcement, and Redress](/artifacts/uk/online-safety-act/content-moderation-and-appeals.md): Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement. - [UK Online Safety Act Enforcement and Penalties | Ofcom Notices, Penalties, and Escalation](/artifacts/uk/online-safety-act/enforcement-and-penalties.md): Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions. - [UK Online Safety Act FAQ | Scope, Child Duties, Categories, and Ofcom Enforcement](/artifacts/uk/online-safety-act/faq.md): Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties. - [UK Online Safety Act Illegal Content Duties | Illegal Harms, Priority Offences, and Risk Assessments](/artifacts/uk/online-safety-act/illegal-content-duties-explained.md): Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments. - [UK Online Safety Act Penalties and Fines | GBP 18 Million, 10 Percent Revenue, and Liability](/artifacts/uk/online-safety-act/penalties-and-fines.md): Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap. - [UK Online Safety Act Requirements | Sections, Deadlines, Controls, and Evidence](/artifacts/uk/online-safety-act/requirements.md): Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation. - [UK Online Safety Act Risk Assessment Template | Illegal Content and Child Safety Template](/artifacts/uk/online-safety-act/online-safety-risk-assessment-template.md): Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety. - [UK Online Safety Act Risk Assessments Playbook | How to Run Illegal and Children Risk Reviews](/artifacts/uk/online-safety-act/risk-assessments-playbook.md): Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design. - [UK Online Safety Act Service Scope and Categorization | Category 1, 2A, 2B, and Part 3 Logic](/artifacts/uk/online-safety-act/service-scope-and-categorization.md): Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A. - [UK Online Safety Act vs EU Digital Services Act | Scope, Child Safety, and Enforcement Differences](/artifacts/uk/online-safety-act/online-safety-act-vs-dsa.md): Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar --- --- title: "UK Online Safety Act Enforcement and Penalties" canonical_url: "https://www.sorena.io/artifacts/uk/online-safety-act/enforcement-and-penalties" source_url: "https://www.sorena.io/artifacts/uk/online-safety-act/enforcement-and-penalties" author: "Sorena AI" description: "Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK Online Safety Act enforcement" - "Ofcom information notices" - "senior manager online safety act" - "10 percent worldwide revenue online safety" - "Ofcom enforcement" - "information notices" - "UK OSA penalties" - "senior manager liability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK Online Safety Act Enforcement and Penalties Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions. *Enforcement Guide* *Ofcom Powers* ## Enforcement and Penalties The enforcement risk starts long before the final fine. Information notices, evidence failures, and non-compliance with enforcement action can create major escalation risk even before a maximum penalty is considered. The legislation provides Ofcom with information powers, enforcement decisions, penalty powers, and publication powers. Government materials also highlight that companies can be fined up to GBP 18 million or 10 percent of qualifying worldwide revenue, whichever is greater, and that senior managers face criminal exposure where the company fails in connection with certain information or child safety enforcement duties. ## Prepare for information notices first Part 7 of the Act includes information powers, information notices, and the requirement to name a senior manager. In practice, weak response discipline at this stage can escalate a manageable issue into a much larger case. The first defense is being able to identify the accountable service owner, legal owner, and evidence set quickly. - Maintain a notice-response workflow with legal and operational escalation - Keep a named senior manager process ready for the services in scope - Test whether evidence can be retrieved within the likely regulator timeframe ## Understand the confirmation and publication path The Act includes confirmation decisions, penalties, and publication of enforcement action. This matters because a provider may have to explain not only the underlying issue, but also its response to notices, undertakings, and corrective steps. Publication risk can become a reputational event even where the financial penalty is not the highest possible. - Track every commitment made to Ofcom and whether it was completed - Retain evidence of corrective action and control redesign - Prepare public communications and customer messaging in parallel ## Treat maximum penalty figures as the outer boundary, not the only risk The headline maximum of GBP 18 million or 10 percent of qualifying worldwide revenue should not distract from the operational consequences of enforcement, including publication, business disruption measures, and potential criminal exposure for senior managers in certain circumstances. The right program response is therefore a prevention and evidence discipline, not only a fine model. - Quantify financial exposure but also operational and reputational exposure - Run mock enforcement response exercises for high-risk services - Escalate child safety and information notice failures immediately *Recommended next step* *Placement: after the enforcement section* ## Use Enforcement and Penalties as a cited research workflow Research Copilot can take Enforcement and Penalties from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on Enforcement can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Enforcement and Penalties](/solutions/research-copilot.md): Start from Enforcement and Penalties and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Enforcement](/contact.md): Review your current process, evidence gaps, and next steps for Enforcement and Penalties. ## Primary sources - [Online Safety Act 2023](https://www.legislation.gov.uk/ukpga/2023/50/contents?ref=sorena.io) - Primary legislation for scope, duties, risk assessment, enforcement, transparency, and complaints provisions. - [Online Safety Act explainer](https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io) - Current government implementation status, deadlines, and plain language explanation of the regime. - [Statement of Strategic Priorities for Online Safety](https://www.gov.uk/government/publications/statement-of-strategic-priorities-for-online-safety?ref=sorena.io) - July 2025 strategic priorities for Ofcom, including safety by design, age assurance, and small but risky services. ## Related Topic Guides - [UK Online Safety Act Age Assurance Options | Age Estimation, Verification, and Child Access Controls](/artifacts/uk/online-safety-act/age-assurance-options.md): Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance. - [UK Online Safety Act Applicability Test | Regulated Service, Exemptions, and UK Scope](/artifacts/uk/online-safety-act/applicability-test.md): Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope. - [UK Online Safety Act Checklist | Scope, Risk, Child Safety, Moderation, and Evidence](/artifacts/uk/online-safety-act/checklist.md): Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints. - [UK Online Safety Act Children Safety Duties | Child Access, Child Risk, and Age Assurance](/artifacts/uk/online-safety-act/children-safety-duties.md): Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments. - [UK Online Safety Act Compliance Program | Governance, Controls, and Ofcom Readiness](/artifacts/uk/online-safety-act/compliance.md): Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics. - [UK Online Safety Act Content Moderation and Appeals | Complaints, Terms Enforcement, and Redress](/artifacts/uk/online-safety-act/content-moderation-and-appeals.md): Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement. - [UK Online Safety Act Deadlines and Compliance Calendar | 2023 to 2026 Milestones](/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar.md): Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes. - [UK Online Safety Act FAQ | Scope, Child Duties, Categories, and Ofcom Enforcement](/artifacts/uk/online-safety-act/faq.md): Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties. - [UK Online Safety Act Illegal Content Duties | Illegal Harms, Priority Offences, and Risk Assessments](/artifacts/uk/online-safety-act/illegal-content-duties-explained.md): Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments. - [UK Online Safety Act Penalties and Fines | GBP 18 Million, 10 Percent Revenue, and Liability](/artifacts/uk/online-safety-act/penalties-and-fines.md): Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap. - [UK Online Safety Act Requirements | Sections, Deadlines, Controls, and Evidence](/artifacts/uk/online-safety-act/requirements.md): Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation. - [UK Online Safety Act Risk Assessment Template | Illegal Content and Child Safety Template](/artifacts/uk/online-safety-act/online-safety-risk-assessment-template.md): Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety. - [UK Online Safety Act Risk Assessments Playbook | How to Run Illegal and Children Risk Reviews](/artifacts/uk/online-safety-act/risk-assessments-playbook.md): Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design. - [UK Online Safety Act Service Scope and Categorization | Category 1, 2A, 2B, and Part 3 Logic](/artifacts/uk/online-safety-act/service-scope-and-categorization.md): Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A. - [UK Online Safety Act vs EU Digital Services Act | Scope, Child Safety, and Enforcement Differences](/artifacts/uk/online-safety-act/online-safety-act-vs-dsa.md): Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/online-safety-act/enforcement-and-penalties --- --- title: "UK Online Safety Act FAQ" canonical_url: "https://www.sorena.io/artifacts/uk/online-safety-act/faq" source_url: "https://www.sorena.io/artifacts/uk/online-safety-act/faq" author: "Sorena AI" description: "Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK Online Safety Act FAQ" - "Ofcom online safety FAQ" - "child access assessment FAQ" - "category 1 FAQ" - "UK OSA FAQ" - "Ofcom FAQ" - "child access assessment" - "category duties" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK Online Safety Act FAQ Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties. *FAQ* *Implementation Questions* ## UK Online Safety Act FAQ Use this page to answer the recurring implementation questions with grounded dates and duty splits. Most confusion comes from mixing child access, child risk, category duties, and complaints duties into one undifferentiated program. These are the questions that usually slow programs down: what is in scope, what changed in 2025, when age assurance became urgent, how child duties relate to the ICO Children's Code, and where the largest penalty and evidence risks sit. ## Which services are in scope? Search services and services that allow user interaction or user-generated content can be in scope. The analysis must be done service by service, with exemptions and special cases checked before the duty set is finalised. Mixed products often need more than one scoped answer. - Check sections 3 to 5 first - Review Schedule 1 exemptions - Separate user-to-user, search, and provider pornography issues ## What were the key 2025 implementation deadlines? Government materials state that illegal content risk assessments were due by 16 March 2025, child access assessments by 16 April 2025, and children risk assessments by 24 July 2025. Section 81 also came into force on 17 January 2025 after January age assurance guidance for online pornography. Those dates should already be reflected in the evidence file for any relevant service. - 16 March 2025: illegal risk assessment - 16 April 2025: child access assessment - 24 July 2025: children risk assessment ## How does the ICO Children's Code fit with the Act? The Children's Code is a data protection code for information society services likely to be accessed by children. It does not replace UK OSA duties, but it strongly affects how a child-safe service should design privacy defaults, profiling, geolocation, transparency, and age assurance. Treat the regimes as overlapping design constraints, especially on child-facing features. - Use one joint review for child safety and child privacy changes - Check profiling, geolocation, nudge techniques, and defaults - Avoid implementing child safety controls that create new privacy risks *Recommended next step* *Placement: after the FAQ section* ## Use UK Online Safety Act FAQ as a cited research workflow Research Copilot can take UK Online Safety Act FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on UK Online Safety Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK Online Safety Act FAQ](/solutions/research-copilot.md): Start from UK Online Safety Act FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK Online Safety Act](/contact.md): Review your current process, evidence gaps, and next steps for UK Online Safety Act FAQ. ## Primary sources - [Online Safety Act 2023](https://www.legislation.gov.uk/ukpga/2023/50/contents?ref=sorena.io) - Primary legislation for scope, duties, risk assessment, enforcement, transparency, and complaints provisions. - [Online Safety Act explainer](https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io) - Current government implementation status, deadlines, and plain language explanation of the regime. - [ICO introduction to the Children's Code](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/introduction-to-the-childrens-code/?ref=sorena.io) - ICO explanation of scope for information society services likely to be accessed by children and the 15 standards. - [ICO profiling guidance for age appropriate design](https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/age-appropriate-design/profiling/?ref=sorena.io) - Detailed control guidance for profiling, DPIAs, age assurance, and child-safe defaults. ## Related Topic Guides - [UK Online Safety Act Age Assurance Options | Age Estimation, Verification, and Child Access Controls](/artifacts/uk/online-safety-act/age-assurance-options.md): Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance. - [UK Online Safety Act Applicability Test | Regulated Service, Exemptions, and UK Scope](/artifacts/uk/online-safety-act/applicability-test.md): Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope. - [UK Online Safety Act Checklist | Scope, Risk, Child Safety, Moderation, and Evidence](/artifacts/uk/online-safety-act/checklist.md): Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints. - [UK Online Safety Act Children Safety Duties | Child Access, Child Risk, and Age Assurance](/artifacts/uk/online-safety-act/children-safety-duties.md): Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments. - [UK Online Safety Act Compliance Program | Governance, Controls, and Ofcom Readiness](/artifacts/uk/online-safety-act/compliance.md): Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics. - [UK Online Safety Act Content Moderation and Appeals | Complaints, Terms Enforcement, and Redress](/artifacts/uk/online-safety-act/content-moderation-and-appeals.md): Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement. - [UK Online Safety Act Deadlines and Compliance Calendar | 2023 to 2026 Milestones](/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar.md): Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes. - [UK Online Safety Act Enforcement and Penalties | Ofcom Notices, Penalties, and Escalation](/artifacts/uk/online-safety-act/enforcement-and-penalties.md): Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions. - [UK Online Safety Act Illegal Content Duties | Illegal Harms, Priority Offences, and Risk Assessments](/artifacts/uk/online-safety-act/illegal-content-duties-explained.md): Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments. - [UK Online Safety Act Penalties and Fines | GBP 18 Million, 10 Percent Revenue, and Liability](/artifacts/uk/online-safety-act/penalties-and-fines.md): Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap. - [UK Online Safety Act Requirements | Sections, Deadlines, Controls, and Evidence](/artifacts/uk/online-safety-act/requirements.md): Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation. - [UK Online Safety Act Risk Assessment Template | Illegal Content and Child Safety Template](/artifacts/uk/online-safety-act/online-safety-risk-assessment-template.md): Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety. - [UK Online Safety Act Risk Assessments Playbook | How to Run Illegal and Children Risk Reviews](/artifacts/uk/online-safety-act/risk-assessments-playbook.md): Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design. - [UK Online Safety Act Service Scope and Categorization | Category 1, 2A, 2B, and Part 3 Logic](/artifacts/uk/online-safety-act/service-scope-and-categorization.md): Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A. - [UK Online Safety Act vs EU Digital Services Act | Scope, Child Safety, and Enforcement Differences](/artifacts/uk/online-safety-act/online-safety-act-vs-dsa.md): Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/online-safety-act/faq --- --- title: "UK Online Safety Act Illegal Content Duties" canonical_url: "https://www.sorena.io/artifacts/uk/online-safety-act/illegal-content-duties-explained" source_url: "https://www.sorena.io/artifacts/uk/online-safety-act/illegal-content-duties-explained" author: "Sorena AI" description: "Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK Online Safety Act illegal content duties" - "illegal content risk assessment" - "priority offences online safety act" - "Ofcom illegal harms" - "illegal content duties" - "priority offences" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK Online Safety Act Illegal Content Duties Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments. *Duty Guide* *Illegal Content* ## Illegal Content Duties Explained Illegal content duties are already in force and Ofcom can enforce them. Treat the illegal content risk assessment as the control design baseline for moderation, detection, escalation, and law enforcement cooperation. All in-scope user-to-user and search services need systems and processes to reduce the risk that their services are used for illegal activity and to take down illegal content when it appears. The government implementation materials state that the illegal risk assessment deadline was 16 March 2025 and that Ofcom could enforce the regime from 17 March 2025. ## Build around the illegal content risk assessment The assessment is not a policy summary. It should identify the illegal content and illegal activity risks created by service features, user behavior, recommendation logic, reporting paths, and abuse vectors. Controls should map directly to the risk scenarios the assessment identifies. - Document risk by feature, user group, and abuse pathway - Separate baseline detection, response, and escalation controls - Tie each risk to a named owner and review frequency ## Prioritise the priority offences and serious harm vectors Government materials highlight priority offences and high harm areas such as fraud, extreme pornography, harassment, stalking, and public order offences. Small but risky services remain a stated enforcement priority even where the service is not large. The right control set for a suicide forum, a general social platform, and a search service will not look the same. - Focus proactive measures on the most serious and prevalent risks for the service - Document where the service must act before a user report arrives - Review whether recommendation, ranking, or search design increases exposure ## Use March 2025 as the live baseline, not a future aspiration The illegal harms codes were approved after being laid on 16 December 2024, and Ofcom published risk assessment guidance and its policy statement on the same day. That means services should now be operating inside a live regime, not a draft one. Evidence should therefore show not only policy intent but actual execution since the March 2025 deadline. - Keep dated copies of risk assessments and post-assessment updates - Retain moderation metrics and enforcement QA from the live period - Capture changes made after the policy statement and code approval *Recommended next step* *Placement: near the end of the main content before related guides* ## Use Illegal Content Duties Explained as a cited research workflow Research Copilot can take Illegal Content Duties Explained from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on Illegal Content can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Illegal Content Duties Explained](/solutions/research-copilot.md): Start from Illegal Content Duties Explained and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Illegal Content](/contact.md): Review your current process, evidence gaps, and next steps for Illegal Content Duties Explained. ## Primary sources - [Online Safety Act 2023](https://www.legislation.gov.uk/ukpga/2023/50/contents?ref=sorena.io) - Primary legislation for scope, duties, risk assessment, enforcement, transparency, and complaints provisions. - [Online Safety Act explainer](https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io) - Current government implementation status, deadlines, and plain language explanation of the regime. - [Statement of Strategic Priorities for Online Safety](https://www.gov.uk/government/publications/statement-of-strategic-priorities-for-online-safety?ref=sorena.io) - July 2025 strategic priorities for Ofcom, including safety by design, age assurance, and small but risky services. ## Related Topic Guides - [UK Online Safety Act Age Assurance Options | Age Estimation, Verification, and Child Access Controls](/artifacts/uk/online-safety-act/age-assurance-options.md): Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance. - [UK Online Safety Act Applicability Test | Regulated Service, Exemptions, and UK Scope](/artifacts/uk/online-safety-act/applicability-test.md): Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope. - [UK Online Safety Act Checklist | Scope, Risk, Child Safety, Moderation, and Evidence](/artifacts/uk/online-safety-act/checklist.md): Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints. - [UK Online Safety Act Children Safety Duties | Child Access, Child Risk, and Age Assurance](/artifacts/uk/online-safety-act/children-safety-duties.md): Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments. - [UK Online Safety Act Compliance Program | Governance, Controls, and Ofcom Readiness](/artifacts/uk/online-safety-act/compliance.md): Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics. - [UK Online Safety Act Content Moderation and Appeals | Complaints, Terms Enforcement, and Redress](/artifacts/uk/online-safety-act/content-moderation-and-appeals.md): Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement. - [UK Online Safety Act Deadlines and Compliance Calendar | 2023 to 2026 Milestones](/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar.md): Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes. - [UK Online Safety Act Enforcement and Penalties | Ofcom Notices, Penalties, and Escalation](/artifacts/uk/online-safety-act/enforcement-and-penalties.md): Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions. - [UK Online Safety Act FAQ | Scope, Child Duties, Categories, and Ofcom Enforcement](/artifacts/uk/online-safety-act/faq.md): Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties. - [UK Online Safety Act Penalties and Fines | GBP 18 Million, 10 Percent Revenue, and Liability](/artifacts/uk/online-safety-act/penalties-and-fines.md): Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap. - [UK Online Safety Act Requirements | Sections, Deadlines, Controls, and Evidence](/artifacts/uk/online-safety-act/requirements.md): Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation. - [UK Online Safety Act Risk Assessment Template | Illegal Content and Child Safety Template](/artifacts/uk/online-safety-act/online-safety-risk-assessment-template.md): Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety. - [UK Online Safety Act Risk Assessments Playbook | How to Run Illegal and Children Risk Reviews](/artifacts/uk/online-safety-act/risk-assessments-playbook.md): Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design. - [UK Online Safety Act Service Scope and Categorization | Category 1, 2A, 2B, and Part 3 Logic](/artifacts/uk/online-safety-act/service-scope-and-categorization.md): Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A. - [UK Online Safety Act vs EU Digital Services Act | Scope, Child Safety, and Enforcement Differences](/artifacts/uk/online-safety-act/online-safety-act-vs-dsa.md): Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/online-safety-act/illegal-content-duties-explained --- --- title: "UK Online Safety Act vs EU Digital Services Act" canonical_url: "https://www.sorena.io/artifacts/uk/online-safety-act/online-safety-act-vs-dsa" source_url: "https://www.sorena.io/artifacts/uk/online-safety-act/online-safety-act-vs-dsa" author: "Sorena AI" description: "Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK Online Safety Act vs DSA" - "Ofcom vs DSA compliance" - "child safety UK OSA DSA" - "online platform regulation comparison" - "UK OSA vs DSA" - "Digital Services Act comparison" - "child safety comparison" - "platform compliance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK Online Safety Act vs EU Digital Services Act Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks. *Comparison Guide* *UK and EU Rules* ## Online Safety Act vs EU DSA The UK OSA and the DSA overlap, but they are not interchangeable compliance programs. A cross-border platform should reuse evidence where it can, while still keeping separate legal and operational mappings for UK child safety and EU intermediary rules. The UK OSA is built around regulated user-to-user and search services, strong child safety duties, age assurance, and Ofcom codes and notices. The DSA is built around the EU intermediary framework, transparency, notice and action, and extra systemic-risk obligations for very large platforms and search engines. Teams should reuse evidence cautiously rather than assuming one program automatically satisfies the other. ## Scope logic is similar in ambition but different in structure The UK OSA starts by asking whether a service is a regulated user-to-user or search service and then layers in child access, child safety, and categorisation. The DSA starts from intermediary service concepts and then layers special duties onto very large online platforms and search engines. That means a shared service inventory can help, but a shared legal memo usually is not enough. - Keep a shared service map but separate legal classification outputs - Document which evidence can be reused and which cannot - Do not assume a UK category result maps cleanly to an EU size tier ## The UK OSA is much more explicit on child safety and age assurance The UK OSA implementation sequence in 2025 put child access assessments, children risk assessments, pornography age assurance, and child-safe design at the center of operational work. The DSA also protects minors, but the UK regime is more operationally explicit on age assurance and child exposure control. For child-facing products, UK work often needs deeper product gating and age-design analysis. - Use the UK program to drive child access and age assurance decisions - Reuse moderation and transparency evidence into the EU program where appropriate - Keep child privacy review linked to the UK OSA child safety work ## Enforcement and reporting models also differ Ofcom uses a code, notice, and enforcement framework under the OSA, while the DSA uses a different supervisory and risk-management structure. Large cross-border services should therefore build a common evidence layer but separate regulator-response playbooks. The advantage is not a single merged program. It is a shared evidence backbone with jurisdiction-specific controls. - Reuse core moderation and risk evidence where the legal tests align - Maintain separate regulator contact and response procedures - Keep UK child safety dates and EU reporting timelines in different calendars *Recommended next step* *Placement: after the comparison section* ## Use Online Safety Act vs EU DSA as a cited research workflow Research Copilot can take Online Safety Act vs EU DSA from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on Online Safety Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Online Safety Act vs EU DSA](/solutions/research-copilot.md): Start from Online Safety Act vs EU DSA and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Online Safety Act](/contact.md): Review your current process, evidence gaps, and next steps for Online Safety Act vs EU DSA. ## Primary sources - [Online Safety Act 2023](https://www.legislation.gov.uk/ukpga/2023/50/contents?ref=sorena.io) - Primary legislation for scope, duties, risk assessment, enforcement, transparency, and complaints provisions. - [Online Safety Act explainer](https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io) - Current government implementation status, deadlines, and plain language explanation of the regime. - [Regulation (EU) 2022/2065 Digital Services Act](https://eur-lex.europa.eu/eli/reg/2022/2065/oj/eng) - Primary EU source used only for high level DSA comparison points. ## Related Topic Guides - [UK Online Safety Act Age Assurance Options | Age Estimation, Verification, and Child Access Controls](/artifacts/uk/online-safety-act/age-assurance-options.md): Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance. - [UK Online Safety Act Applicability Test | Regulated Service, Exemptions, and UK Scope](/artifacts/uk/online-safety-act/applicability-test.md): Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope. - [UK Online Safety Act Checklist | Scope, Risk, Child Safety, Moderation, and Evidence](/artifacts/uk/online-safety-act/checklist.md): Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints. - [UK Online Safety Act Children Safety Duties | Child Access, Child Risk, and Age Assurance](/artifacts/uk/online-safety-act/children-safety-duties.md): Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments. - [UK Online Safety Act Compliance Program | Governance, Controls, and Ofcom Readiness](/artifacts/uk/online-safety-act/compliance.md): Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics. - [UK Online Safety Act Content Moderation and Appeals | Complaints, Terms Enforcement, and Redress](/artifacts/uk/online-safety-act/content-moderation-and-appeals.md): Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement. - [UK Online Safety Act Deadlines and Compliance Calendar | 2023 to 2026 Milestones](/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar.md): Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes. - [UK Online Safety Act Enforcement and Penalties | Ofcom Notices, Penalties, and Escalation](/artifacts/uk/online-safety-act/enforcement-and-penalties.md): Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions. - [UK Online Safety Act FAQ | Scope, Child Duties, Categories, and Ofcom Enforcement](/artifacts/uk/online-safety-act/faq.md): Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties. - [UK Online Safety Act Illegal Content Duties | Illegal Harms, Priority Offences, and Risk Assessments](/artifacts/uk/online-safety-act/illegal-content-duties-explained.md): Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments. - [UK Online Safety Act Penalties and Fines | GBP 18 Million, 10 Percent Revenue, and Liability](/artifacts/uk/online-safety-act/penalties-and-fines.md): Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap. - [UK Online Safety Act Requirements | Sections, Deadlines, Controls, and Evidence](/artifacts/uk/online-safety-act/requirements.md): Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation. - [UK Online Safety Act Risk Assessment Template | Illegal Content and Child Safety Template](/artifacts/uk/online-safety-act/online-safety-risk-assessment-template.md): Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety. - [UK Online Safety Act Risk Assessments Playbook | How to Run Illegal and Children Risk Reviews](/artifacts/uk/online-safety-act/risk-assessments-playbook.md): Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design. - [UK Online Safety Act Service Scope and Categorization | Category 1, 2A, 2B, and Part 3 Logic](/artifacts/uk/online-safety-act/service-scope-and-categorization.md): Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/online-safety-act/online-safety-act-vs-dsa --- --- title: "UK Online Safety Act Risk Assessment Template" canonical_url: "https://www.sorena.io/artifacts/uk/online-safety-act/online-safety-risk-assessment-template" source_url: "https://www.sorena.io/artifacts/uk/online-safety-act/online-safety-risk-assessment-template" author: "Sorena AI" description: "Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK Online Safety Act risk assessment template" - "illegal content risk assessment template" - "children risk assessment template" - "child access assessment template" - "risk assessment template" - "illegal harms" - "child access assessment" - "children risk assessment" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK Online Safety Act Risk Assessment Template Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety. *Template* *Risk Assessments* ## Risk Assessment Template A useful template forces teams to connect harms, controls, metrics, and owners. Do not let the assessment become a static legal memo. It should be a working control document that changes product decisions. UK OSA implementation creates at least three distinct but linked assessment layers for many services: the illegal content risk assessment, the child access assessment, and where relevant the children risk assessment. One template can support all three if it preserves the differences between them. ## Template section one: service profile and scope logic Start with the service description, service parts, user base, UK link, likely-to-be-accessed-by-children logic, and category exposure assumptions. Without this, the rest of the assessment floats free from the statutory context. A reviewer should be able to understand exactly which service or service part the assessment covers. - Service name, owner, and assessed version - User-to-user, search, or provider pornography classification - Child access determination and rationale - Assessment date, approver, and next review trigger *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep Risk Assessment Template in one governed evidence system SSOT can take Risk Assessment Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on Risk Assessment can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for Risk Assessment Template](/solutions/ssot.md): Start from Risk Assessment Template and keep documents, evidence, and control records in one governed system. - [Talk through Risk Assessment](/contact.md): Review your current process, evidence gaps, and next steps for Risk Assessment Template. ## Template section two: harms, controls, and residual risk List the relevant illegal harms, child harms, or both. Then map the existing controls, identify control gaps, assign remediation owners, and record the residual risk position after those controls are considered. The best templates separate preventive, detective, responsive, and governance controls. - Harm scenario and affected users - Control mapping by product, moderation, and policy layer - Effectiveness evidence and known failure modes - Residual risk rating with remediation deadline ## Template section three: governance and evidence Record how the assessment will be kept live after approval. The regime moves quickly, so stale assessments are a major weakness. Metrics, change triggers, and evidence locations should be part of the template itself. This is what turns a template into an operating tool. - Owner for monthly or quarterly review - Data sources for moderation, complaints, age assurance, and trust signals - Board or committee escalation thresholds - Location of evidence, approvals, and follow-up actions ## Primary sources - [Online Safety Act 2023](https://www.legislation.gov.uk/ukpga/2023/50/contents?ref=sorena.io) - Primary legislation for scope, duties, risk assessment, enforcement, transparency, and complaints provisions. - [Online Safety Act explainer](https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io) - Current government implementation status, deadlines, and plain language explanation of the regime. - [ICO audit guide for the Age Appropriate Design Code](https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/age-appropriate-design/?ref=sorena.io) - Audit scope and control themes for children's data, including age assurance, privacy settings, geolocation, profiling, and nudge techniques. ## Related Topic Guides - [UK Online Safety Act Age Assurance Options | Age Estimation, Verification, and Child Access Controls](/artifacts/uk/online-safety-act/age-assurance-options.md): Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance. - [UK Online Safety Act Applicability Test | Regulated Service, Exemptions, and UK Scope](/artifacts/uk/online-safety-act/applicability-test.md): Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope. - [UK Online Safety Act Checklist | Scope, Risk, Child Safety, Moderation, and Evidence](/artifacts/uk/online-safety-act/checklist.md): Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints. - [UK Online Safety Act Children Safety Duties | Child Access, Child Risk, and Age Assurance](/artifacts/uk/online-safety-act/children-safety-duties.md): Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments. - [UK Online Safety Act Compliance Program | Governance, Controls, and Ofcom Readiness](/artifacts/uk/online-safety-act/compliance.md): Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics. - [UK Online Safety Act Content Moderation and Appeals | Complaints, Terms Enforcement, and Redress](/artifacts/uk/online-safety-act/content-moderation-and-appeals.md): Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement. - [UK Online Safety Act Deadlines and Compliance Calendar | 2023 to 2026 Milestones](/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar.md): Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes. - [UK Online Safety Act Enforcement and Penalties | Ofcom Notices, Penalties, and Escalation](/artifacts/uk/online-safety-act/enforcement-and-penalties.md): Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions. - [UK Online Safety Act FAQ | Scope, Child Duties, Categories, and Ofcom Enforcement](/artifacts/uk/online-safety-act/faq.md): Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties. - [UK Online Safety Act Illegal Content Duties | Illegal Harms, Priority Offences, and Risk Assessments](/artifacts/uk/online-safety-act/illegal-content-duties-explained.md): Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments. - [UK Online Safety Act Penalties and Fines | GBP 18 Million, 10 Percent Revenue, and Liability](/artifacts/uk/online-safety-act/penalties-and-fines.md): Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap. - [UK Online Safety Act Requirements | Sections, Deadlines, Controls, and Evidence](/artifacts/uk/online-safety-act/requirements.md): Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation. - [UK Online Safety Act Risk Assessments Playbook | How to Run Illegal and Children Risk Reviews](/artifacts/uk/online-safety-act/risk-assessments-playbook.md): Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design. - [UK Online Safety Act Service Scope and Categorization | Category 1, 2A, 2B, and Part 3 Logic](/artifacts/uk/online-safety-act/service-scope-and-categorization.md): Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A. - [UK Online Safety Act vs EU Digital Services Act | Scope, Child Safety, and Enforcement Differences](/artifacts/uk/online-safety-act/online-safety-act-vs-dsa.md): Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/online-safety-act/online-safety-risk-assessment-template --- --- title: "UK Online Safety Act Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/uk/online-safety-act/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/uk/online-safety-act/penalties-and-fines" author: "Sorena AI" description: "Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK Online Safety Act fines" - "GBP 18 million online safety act" - "10 percent worldwide revenue Ofcom" - "senior manager liability online safety" - "penalties" - "fines" - "10 percent worldwide revenue" - "senior manager liability" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK Online Safety Act Penalties and Fines Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap. *Penalty Guide* *Exposure and Mitigation* ## Penalties and Fines The headline penalty figure is only the end of the story. What matters operationally is whether the provider can show timely assessments, working controls, honest responses, and prompt remediation. Government materials state that companies can be fined up to GBP 18 million or 10 percent of qualifying worldwide revenue, whichever is greater. Senior managers can also face criminal action in connection with failures around Ofcom information requests and certain child safety enforcement scenarios. Providers should therefore manage penalty risk as a control and evidence problem, not only as a legal probability estimate. ## Quantify the exposure but focus on the failure path A fine model should start with service scope, user impact, child safety exposure, and the quality of the provider's response once concerns were known. The largest fines usually follow repeated control failures or failures to respond properly to the regulator. Financial modelling without root-cause analysis is not enough. - Identify which services create the highest revenue-linked exposure - Review where the control system depends on manual workarounds - Test which failures would also create child safety or notice-response exposure ## Reduce penalty risk with strong remediation records Penalty exposure falls when the provider can show that risks were assessed, controls were actually deployed, incidents were investigated, and gaps were corrected quickly. Weak documentation turns a fixable issue into evidence of poor governance. This is why every major issue should end with a remediation file, not only a ticket closure. - Keep dated proof of assessment, decision, fix, and retest - Show when senior management was informed and what was approved - Retain the metrics that prove the control improved after remediation ## Plan for communication as well as calculation Penalty events are usually accompanied by internal escalation, customer concern, and public scrutiny. The provider should therefore prepare both the legal response and the operational narrative about what went wrong and how it was fixed. This reduces confusion and lowers the chance of contradictory statements across teams. - Create a joint legal, policy, communications, and product response path - Align public statements to the documented facts - Keep leadership briefings current during an active case *Recommended next step* *Placement: after the enforcement section* ## Use Penalties and Fines as a cited research workflow Research Copilot can take Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on Penalties can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Penalties and Fines](/solutions/research-copilot.md): Start from Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Penalties](/contact.md): Review your current process, evidence gaps, and next steps for Penalties and Fines. ## Primary sources - [Online Safety Act 2023](https://www.legislation.gov.uk/ukpga/2023/50/contents?ref=sorena.io) - Primary legislation for scope, duties, risk assessment, enforcement, transparency, and complaints provisions. - [Online Safety Act explainer](https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io) - Current government implementation status, deadlines, and plain language explanation of the regime. ## Related Topic Guides - [UK Online Safety Act Age Assurance Options | Age Estimation, Verification, and Child Access Controls](/artifacts/uk/online-safety-act/age-assurance-options.md): Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance. - [UK Online Safety Act Applicability Test | Regulated Service, Exemptions, and UK Scope](/artifacts/uk/online-safety-act/applicability-test.md): Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope. - [UK Online Safety Act Checklist | Scope, Risk, Child Safety, Moderation, and Evidence](/artifacts/uk/online-safety-act/checklist.md): Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints. - [UK Online Safety Act Children Safety Duties | Child Access, Child Risk, and Age Assurance](/artifacts/uk/online-safety-act/children-safety-duties.md): Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments. - [UK Online Safety Act Compliance Program | Governance, Controls, and Ofcom Readiness](/artifacts/uk/online-safety-act/compliance.md): Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics. - [UK Online Safety Act Content Moderation and Appeals | Complaints, Terms Enforcement, and Redress](/artifacts/uk/online-safety-act/content-moderation-and-appeals.md): Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement. - [UK Online Safety Act Deadlines and Compliance Calendar | 2023 to 2026 Milestones](/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar.md): Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes. - [UK Online Safety Act Enforcement and Penalties | Ofcom Notices, Penalties, and Escalation](/artifacts/uk/online-safety-act/enforcement-and-penalties.md): Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions. - [UK Online Safety Act FAQ | Scope, Child Duties, Categories, and Ofcom Enforcement](/artifacts/uk/online-safety-act/faq.md): Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties. - [UK Online Safety Act Illegal Content Duties | Illegal Harms, Priority Offences, and Risk Assessments](/artifacts/uk/online-safety-act/illegal-content-duties-explained.md): Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments. - [UK Online Safety Act Requirements | Sections, Deadlines, Controls, and Evidence](/artifacts/uk/online-safety-act/requirements.md): Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation. - [UK Online Safety Act Risk Assessment Template | Illegal Content and Child Safety Template](/artifacts/uk/online-safety-act/online-safety-risk-assessment-template.md): Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety. - [UK Online Safety Act Risk Assessments Playbook | How to Run Illegal and Children Risk Reviews](/artifacts/uk/online-safety-act/risk-assessments-playbook.md): Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design. - [UK Online Safety Act Service Scope and Categorization | Category 1, 2A, 2B, and Part 3 Logic](/artifacts/uk/online-safety-act/service-scope-and-categorization.md): Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A. - [UK Online Safety Act vs EU Digital Services Act | Scope, Child Safety, and Enforcement Differences](/artifacts/uk/online-safety-act/online-safety-act-vs-dsa.md): Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/online-safety-act/penalties-and-fines --- --- title: "UK Online Safety Act Requirements" canonical_url: "https://www.sorena.io/artifacts/uk/online-safety-act/requirements" source_url: "https://www.sorena.io/artifacts/uk/online-safety-act/requirements" author: "Sorena AI" description: "Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK Online Safety Act requirements" - "Ofcom compliance controls" - "online safety act evidence" - "category 1 requirements" - "children safety requirements" - "UK OSA requirements" - "controls mapping" - "Ofcom readiness" - "compliance evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK Online Safety Act Requirements Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation. *Requirements Guide* *Control Mapping* ## UK Online Safety Act Requirements Translate the Act into control obligations, not generic compliance themes. This page maps the live duty set into owners, evidence, and review points so the work can be executed. The UK OSA requirements set is layered. Every program should map baseline scope and illegal harms duties first, then child-access and child-safety duties where relevant, then category-specific duties if the service is categorised, and finally the enforcement and information notice response capabilities that sit across the whole program. ## Base requirements for all in-scope services Base requirements include service scoping, illegal content risk assessment, systems and processes to mitigate illegal activity, takedown and moderation design, and usable reporting and complaints procedures. Search and user-to-user services share the same general structure but not identical section numbering. These controls should exist even if the service is not large. - Scope register and service classification memo - Illegal content risk assessment and updates - Moderation, reporting, and complaints procedures - Evidence retention for decisions, metrics, and control testing *Recommended next step* *Placement: after the requirement breakdown* ## Turn UK Online Safety Act Requirements into an operational assessment Assessment Autopilot can take UK Online Safety Act Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on UK Online Safety Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK Online Safety Act Requirements](/solutions/assessment.md): Start from UK Online Safety Act Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK Online Safety Act](/contact.md): Review your current process, evidence gaps, and next steps for UK Online Safety Act Requirements. ## Additional requirements where children are likely to access the service Where children are likely to access the service, the program must add child access analysis, children risk assessment, age assurance or age gating decisions where used, and product controls that actually prevent exposure to harmful content. This work should also account for ICO child-data expectations, especially around privacy defaults, profiling, and geolocation. - Child access assessment and rationale - Children risk assessment and age-banded harm analysis - Age assurance design, testing, and privacy review - Child-safe product defaults and high-risk feature controls ## Additional requirements for categorised services and enforcement readiness Category 1, 2A, and 2B services have additional transparency and accountability exposure once categorised. Across the program, providers also need to be ready for information notices, senior manager naming, transparency reporting, and financial penalty exposure. This means the controls map should include both duty controls and regulator-response controls. - Transparency reporting data definitions and ownership - Category 1 terms enforcement and user empowerment tooling where relevant - Information notice response workflow and named accountable senior manager - Penalty exposure register and enforcement communication plan ## Primary sources - [Online Safety Act 2023](https://www.legislation.gov.uk/ukpga/2023/50/contents?ref=sorena.io) - Primary legislation for scope, duties, risk assessment, enforcement, transparency, and complaints provisions. - [Online Safety Act explainer](https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io) - Current government implementation status, deadlines, and plain language explanation of the regime. - [Statement of Strategic Priorities for Online Safety](https://www.gov.uk/government/publications/statement-of-strategic-priorities-for-online-safety?ref=sorena.io) - July 2025 strategic priorities for Ofcom, including safety by design, age assurance, and small but risky services. - [ICO introduction to the Children's Code](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/introduction-to-the-childrens-code/?ref=sorena.io) - ICO explanation of scope for information society services likely to be accessed by children and the 15 standards. ## Related Topic Guides - [UK Online Safety Act Age Assurance Options | Age Estimation, Verification, and Child Access Controls](/artifacts/uk/online-safety-act/age-assurance-options.md): Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance. - [UK Online Safety Act Applicability Test | Regulated Service, Exemptions, and UK Scope](/artifacts/uk/online-safety-act/applicability-test.md): Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope. - [UK Online Safety Act Checklist | Scope, Risk, Child Safety, Moderation, and Evidence](/artifacts/uk/online-safety-act/checklist.md): Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints. - [UK Online Safety Act Children Safety Duties | Child Access, Child Risk, and Age Assurance](/artifacts/uk/online-safety-act/children-safety-duties.md): Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments. - [UK Online Safety Act Compliance Program | Governance, Controls, and Ofcom Readiness](/artifacts/uk/online-safety-act/compliance.md): Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics. - [UK Online Safety Act Content Moderation and Appeals | Complaints, Terms Enforcement, and Redress](/artifacts/uk/online-safety-act/content-moderation-and-appeals.md): Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement. - [UK Online Safety Act Deadlines and Compliance Calendar | 2023 to 2026 Milestones](/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar.md): Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes. - [UK Online Safety Act Enforcement and Penalties | Ofcom Notices, Penalties, and Escalation](/artifacts/uk/online-safety-act/enforcement-and-penalties.md): Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions. - [UK Online Safety Act FAQ | Scope, Child Duties, Categories, and Ofcom Enforcement](/artifacts/uk/online-safety-act/faq.md): Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties. - [UK Online Safety Act Illegal Content Duties | Illegal Harms, Priority Offences, and Risk Assessments](/artifacts/uk/online-safety-act/illegal-content-duties-explained.md): Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments. - [UK Online Safety Act Penalties and Fines | GBP 18 Million, 10 Percent Revenue, and Liability](/artifacts/uk/online-safety-act/penalties-and-fines.md): Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap. - [UK Online Safety Act Risk Assessment Template | Illegal Content and Child Safety Template](/artifacts/uk/online-safety-act/online-safety-risk-assessment-template.md): Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety. - [UK Online Safety Act Risk Assessments Playbook | How to Run Illegal and Children Risk Reviews](/artifacts/uk/online-safety-act/risk-assessments-playbook.md): Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design. - [UK Online Safety Act Service Scope and Categorization | Category 1, 2A, 2B, and Part 3 Logic](/artifacts/uk/online-safety-act/service-scope-and-categorization.md): Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A. - [UK Online Safety Act vs EU Digital Services Act | Scope, Child Safety, and Enforcement Differences](/artifacts/uk/online-safety-act/online-safety-act-vs-dsa.md): Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/online-safety-act/requirements --- --- title: "UK Online Safety Act Risk Assessments Playbook" canonical_url: "https://www.sorena.io/artifacts/uk/online-safety-act/risk-assessments-playbook" source_url: "https://www.sorena.io/artifacts/uk/online-safety-act/risk-assessments-playbook" author: "Sorena AI" description: "Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK Online Safety Act risk assessment playbook" - "illegal harms assessment process" - "child safety assessment process" - "Ofcom readiness playbook" - "risk assessments playbook" - "illegal harms" - "children safety" - "governance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK Online Safety Act Risk Assessments Playbook Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design. *Playbook* *Assessment Operations* ## Risk Assessments Playbook The output quality depends on process discipline, not on a single workshop. Run UK OSA assessments as a repeated cycle across product, moderation, privacy, trust and safety, and legal teams. A workable UK OSA playbook separates scoping, evidence gathering, assessment, control design, approval, and revalidation. It also keeps the illegal content assessment distinct from the child access and children risk workstreams while allowing shared evidence where appropriate. ## Phase one: scope and evidence collection Start by fixing the assessed service perimeter and collecting the data that actually describes the service. Good inputs include moderation trends, search logs, abuse reports, child usage indicators, age gate performance, and product design documentation. Avoid starting with a blank workshop and no evidence. - Lock the service perimeter and assessed release version - Pull abuse, moderation, and complaints data before the workshop - Collect product diagrams, terms, and age assurance design notes ## Phase two: harms analysis and control decisions Run structured sessions for illegal harms and child harms, but do not let the meeting end without named design actions. Each material risk should have a control decision, a temporary position, or an explicit escalation. This is where the program either becomes real or stays theoretical. - Score likelihood and impact using one internal method - Decide what changes in product, policy, moderation, or age assurance - Record residual risk and executive acceptances where needed ## Phase three: approval, implementation, and revalidation After approval, the assessment should feed release gates, training, and monitoring. Then set review triggers for product changes, threat shifts, enforcement updates, or major incident learnings. A static annual review is rarely enough for fast-moving services. - Link remediation actions to tracked work items - Reassess after material feature launches or major incidents - Keep one dated evidence package for each completed review cycle *Recommended next step* *Placement: after the workflow or playbook section* ## Turn Risk Assessments Playbook into an operational assessment Assessment Autopilot can take Risk Assessments Playbook from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on Risk Assessments can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Risk Assessments Playbook](/solutions/assessment.md): Start from Risk Assessments Playbook and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Risk Assessments](/contact.md): Review your current process, evidence gaps, and next steps for Risk Assessments Playbook. ## Primary sources - [Online Safety Act 2023](https://www.legislation.gov.uk/ukpga/2023/50/contents?ref=sorena.io) - Primary legislation for scope, duties, risk assessment, enforcement, transparency, and complaints provisions. - [Online Safety Act explainer](https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io) - Current government implementation status, deadlines, and plain language explanation of the regime. - [ICO audit guide for the Age Appropriate Design Code](https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/age-appropriate-design/?ref=sorena.io) - Audit scope and control themes for children's data, including age assurance, privacy settings, geolocation, profiling, and nudge techniques. - [ICO profiling guidance for age appropriate design](https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/age-appropriate-design/profiling/?ref=sorena.io) - Detailed control guidance for profiling, DPIAs, age assurance, and child-safe defaults. ## Related Topic Guides - [UK Online Safety Act Age Assurance Options | Age Estimation, Verification, and Child Access Controls](/artifacts/uk/online-safety-act/age-assurance-options.md): Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance. - [UK Online Safety Act Applicability Test | Regulated Service, Exemptions, and UK Scope](/artifacts/uk/online-safety-act/applicability-test.md): Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope. - [UK Online Safety Act Checklist | Scope, Risk, Child Safety, Moderation, and Evidence](/artifacts/uk/online-safety-act/checklist.md): Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints. - [UK Online Safety Act Children Safety Duties | Child Access, Child Risk, and Age Assurance](/artifacts/uk/online-safety-act/children-safety-duties.md): Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments. - [UK Online Safety Act Compliance Program | Governance, Controls, and Ofcom Readiness](/artifacts/uk/online-safety-act/compliance.md): Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics. - [UK Online Safety Act Content Moderation and Appeals | Complaints, Terms Enforcement, and Redress](/artifacts/uk/online-safety-act/content-moderation-and-appeals.md): Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement. - [UK Online Safety Act Deadlines and Compliance Calendar | 2023 to 2026 Milestones](/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar.md): Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes. - [UK Online Safety Act Enforcement and Penalties | Ofcom Notices, Penalties, and Escalation](/artifacts/uk/online-safety-act/enforcement-and-penalties.md): Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions. - [UK Online Safety Act FAQ | Scope, Child Duties, Categories, and Ofcom Enforcement](/artifacts/uk/online-safety-act/faq.md): Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties. - [UK Online Safety Act Illegal Content Duties | Illegal Harms, Priority Offences, and Risk Assessments](/artifacts/uk/online-safety-act/illegal-content-duties-explained.md): Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments. - [UK Online Safety Act Penalties and Fines | GBP 18 Million, 10 Percent Revenue, and Liability](/artifacts/uk/online-safety-act/penalties-and-fines.md): Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap. - [UK Online Safety Act Requirements | Sections, Deadlines, Controls, and Evidence](/artifacts/uk/online-safety-act/requirements.md): Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation. - [UK Online Safety Act Risk Assessment Template | Illegal Content and Child Safety Template](/artifacts/uk/online-safety-act/online-safety-risk-assessment-template.md): Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety. - [UK Online Safety Act Service Scope and Categorization | Category 1, 2A, 2B, and Part 3 Logic](/artifacts/uk/online-safety-act/service-scope-and-categorization.md): Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A. - [UK Online Safety Act vs EU Digital Services Act | Scope, Child Safety, and Enforcement Differences](/artifacts/uk/online-safety-act/online-safety-act-vs-dsa.md): Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/online-safety-act/risk-assessments-playbook --- --- title: "UK Online Safety Act Service Scope and Categorization" canonical_url: "https://www.sorena.io/artifacts/uk/online-safety-act/service-scope-and-categorization" source_url: "https://www.sorena.io/artifacts/uk/online-safety-act/service-scope-and-categorization" author: "Sorena AI" description: "Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A." published_at: "2026-02-21" updated_at: "2026-02-21" keywords: - "UK Online Safety Act category 1" - "category 2A" - "category 2B" - "Ofcom register categorised services" - "service scope online safety act" - "Online Safety Act categories" - "Category 1 service" - "Category 2A service" - "Category 2B service" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK Online Safety Act Service Scope and Categorization Grounded service scope and categorisation guide for the UK Online Safety Act covering Part 3 logic, likely to be accessed by children, Category 1, 2A. *Scope Guide* *Categories and Duty Layers* ## Service Scope and Categorization Do not mix baseline duties with categorised service duties. The first question is whether the service is a regulated Part 3 service. The second is whether it later enters Category 1, 2A, or 2B. UK OSA work gets cleaner when you split it into layers. Layer one is basic Part 3 coverage for regulated user-to-user and search services. Layer two is whether the service is likely to be accessed by children. Layer three is whether the service becomes a categorised service with extra transparency, accountability, or user empowerment duties. ## Treat categorisation as an overlay, not the starting point The Act imposes base duties on in-scope services before category-specific duties arrive. Many teams lose time by jumping straight to Category 1 debates instead of finishing the base illegal-content and child-safety analysis. Keep the base duties live even if the service is not yet on an Ofcom register. - Complete baseline Part 3 scope analysis first - Track category signals separately in governance reporting - Avoid delaying core controls while waiting for category confirmation ## Use the live implementation sequence The government states that the threshold regulations for Category 1, 2A, and 2B were laid on 16 December 2024. Ofcom expected to publish the register of categorised services in summer 2025 and to consult on additional duties from early 2026. That means teams should plan for category exposure before formal listing if the service is near threshold or strategically likely to be included. - Track user scale, functionality, and other threshold related characteristics - Prepare for annual transparency reporting if category exposure is realistic - Pre-build terms, complaints, and internal metrics needed for extra duties ## Watch the categories that change operational design Category 1 services carry the most visible extra user empowerment and terms of service duties. Category 2A covers major search services and Category 2B covers other categorised user-to-user services. The right preparation is not only legal analysis. It is building reporting, metrics, user controls, and complaints data in a way that can scale into the category regime. - Category 1: terms enforcement consistency and adult user control tooling - Category 2A and 2B: transparency and accountability planning - All categories: clean metrics definitions before reporting is mandated *Recommended next step* *Placement: after the scope or definition section* ## Use Service Scope and Categorization as a cited research workflow Research Copilot can take Service Scope and Categorization from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on Service Scope can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Service Scope and Categorization](/solutions/research-copilot.md): Start from Service Scope and Categorization and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Service Scope](/contact.md): Review your current process, evidence gaps, and next steps for Service Scope and Categorization. ## Primary sources - [Online Safety Act 2023](https://www.legislation.gov.uk/ukpga/2023/50/contents?ref=sorena.io) - Primary legislation for scope, duties, risk assessment, enforcement, transparency, and complaints provisions. - [Online Safety Act explainer](https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer?ref=sorena.io) - Current government implementation status, deadlines, and plain language explanation of the regime. - [Statement of Strategic Priorities for Online Safety](https://www.gov.uk/government/publications/statement-of-strategic-priorities-for-online-safety?ref=sorena.io) - July 2025 strategic priorities for Ofcom, including safety by design, age assurance, and small but risky services. ## Related Topic Guides - [UK Online Safety Act Age Assurance Options | Age Estimation, Verification, and Child Access Controls](/artifacts/uk/online-safety-act/age-assurance-options.md): Grounded age assurance guide for the UK Online Safety Act covering January 2025 pornography guidance, highly effective age assurance. - [UK Online Safety Act Applicability Test | Regulated Service, Exemptions, and UK Scope](/artifacts/uk/online-safety-act/applicability-test.md): Grounded UK Online Safety Act applicability test covering regulated user-to-user and search services, Schedule 1 exemptions, provider pornography scope. - [UK Online Safety Act Checklist | Scope, Risk, Child Safety, Moderation, and Evidence](/artifacts/uk/online-safety-act/checklist.md): Audit-ready UK Online Safety Act checklist covering service scope, illegal risk assessment, child access and child risk assessment, moderation, complaints. - [UK Online Safety Act Children Safety Duties | Child Access, Child Risk, and Age Assurance](/artifacts/uk/online-safety-act/children-safety-duties.md): Grounded guide to UK Online Safety Act children safety duties covering section 81 timing, children access assessments, children risk assessments. - [UK Online Safety Act Compliance Program | Governance, Controls, and Ofcom Readiness](/artifacts/uk/online-safety-act/compliance.md): Program design guide for UK Online Safety Act compliance covering governance, scope, assessments, moderation, age assurance, complaints, metrics. - [UK Online Safety Act Content Moderation and Appeals | Complaints, Terms Enforcement, and Redress](/artifacts/uk/online-safety-act/content-moderation-and-appeals.md): Grounded guide to UK Online Safety Act moderation and appeals requirements covering sections 21, 32, 71, and 72, complaints design, terms enforcement. - [UK Online Safety Act Deadlines and Compliance Calendar | 2023 to 2026 Milestones](/artifacts/uk/online-safety-act/deadlines-and-compliance-calendar.md): Grounded UK Online Safety Act calendar covering 26 October 2023 enactment, 31 January 2024 offences, 16 December 2024 illegal harms codes. - [UK Online Safety Act Enforcement and Penalties | Ofcom Notices, Penalties, and Escalation](/artifacts/uk/online-safety-act/enforcement-and-penalties.md): Grounded UK Online Safety Act enforcement guide covering Ofcom information notices, senior manager naming, confirmation decisions. - [UK Online Safety Act FAQ | Scope, Child Duties, Categories, and Ofcom Enforcement](/artifacts/uk/online-safety-act/faq.md): Practical FAQ on the UK Online Safety Act covering who is in scope, what changed in 2025, child access and risk assessments, age assurance, category duties. - [UK Online Safety Act Illegal Content Duties | Illegal Harms, Priority Offences, and Risk Assessments](/artifacts/uk/online-safety-act/illegal-content-duties-explained.md): Grounded guide to UK Online Safety Act illegal content duties covering user-to-user and search services, illegal content risk assessments. - [UK Online Safety Act Penalties and Fines | GBP 18 Million, 10 Percent Revenue, and Liability](/artifacts/uk/online-safety-act/penalties-and-fines.md): Grounded penalty guide for the UK Online Safety Act covering the GBP 18 million or 10 percent worldwide revenue cap. - [UK Online Safety Act Requirements | Sections, Deadlines, Controls, and Evidence](/artifacts/uk/online-safety-act/requirements.md): Detailed UK Online Safety Act requirements guide mapping scope, illegal content duties, child safety duties, terms enforcement, complaints, categorisation. - [UK Online Safety Act Risk Assessment Template | Illegal Content and Child Safety Template](/artifacts/uk/online-safety-act/online-safety-risk-assessment-template.md): Practical UK Online Safety Act risk assessment template covering service profile, harms inventory, controls, residual risk, child access, child safety. - [UK Online Safety Act Risk Assessments Playbook | How to Run Illegal and Children Risk Reviews](/artifacts/uk/online-safety-act/risk-assessments-playbook.md): Operational playbook for UK Online Safety Act risk assessments covering sequencing, ownership, evidence collection, control design. - [UK Online Safety Act vs EU Digital Services Act | Scope, Child Safety, and Enforcement Differences](/artifacts/uk/online-safety-act/online-safety-act-vs-dsa.md): Practical comparison of the UK Online Safety Act and the EU Digital Services Act covering regulated service models, illegal content frameworks. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/online-safety-act/service-scope-and-categorization --- --- title: "UK PSTI Act Applicability Test" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/applicability-test" source_url: "https://www.sorena.io/artifacts/uk/psti-act/applicability-test" author: "Sorena AI" description: "Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products." keywords: - "UK PSTI applicability" - "relevant connectable product" - "network connectable product" - "excepted products PSTI" - "UK consumer connectable product" - "UK PSTI scope" - "internet-connectable product" - "network-connectable product" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Act Applicability Test Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. *Applicability Guide* *Product Scope* ## UK PSTI Act Applicability Test Start with the product definition before you promise compliance or carve a product out. The PSTI scope test works at product level and depends on connectability, exclusions, and whether the product is made available to consumers in the United Kingdom. Section 4 says a relevant connectable product must meet condition A and condition B. Condition A is about whether the product is internet-connectable or network-connectable. Condition B is that it is not an excepted product. The current Schedule 3 list includes certain Northern Ireland products, EV smart charge points, medical devices, certain smart meter products, certain computers, and, since 25 February 2025, specified Great Britain vehicle categories. The analysis should be run product by product, including devices that rely on associated software or services. ## Apply the section 4 to 6 sequence in order Start by testing whether the product is internet-connectable or network-connectable. Then check the current Schedule 3 excepted product rules. Only after that should you move into role mapping, security requirements, or statement-of-compliance work. Mixed device ecosystems often fail because teams jump to the statement template before the scope logic is stable. - Identify whether the product connects to the internet directly or via another product - Check whether any current Schedule 3 exclusion changes the result, including the 2025 Great Britain vehicle additions - Document the marketed use, connectivity path, and UK consumer sales route ## Do not ignore software and associated services The Act allows security requirements to relate not only to the physical product, but also to software used for operation or use of the product and software or services used to provide services by means of the product. That means the scope memo should include the cloud, app, and support components that actually affect product security. - Map companion apps, onboarding flows, and cloud dependencies - Record which components affect passwords, vulnerability handling, and updates - Note where third-party services create evidence or control dependencies ## End with a role and evidence outcome The scope result is only useful if it tells the business which party acts as manufacturer, importer, or distributor for the UK route to market. That is what determines who prepares the statement, who retains it, and who must act when a compliance failure appears. One product can have different duty owners across different sales channels. - Produce a final scope and role memo for each product family - Set review triggers for firmware, service, packaging, or channel changes - Link the result directly to the product release checklist *Recommended next step* *Placement: after the applicability result* ## Turn UK PSTI Act Applicability Test into an operational assessment Assessment Autopilot can take UK PSTI Act Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on UK PSTI Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK PSTI Act Applicability Test](/solutions/assessment.md): Start from UK PSTI Act Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK PSTI Act](/contact.md): Review your current process, evidence gaps, and next steps for UK PSTI Act Applicability Test. ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [PSTI Act Commencement No. 2 Regulations 2023](https://www.legislation.gov.uk/uksi/2023/469/made?ref=sorena.io) - Brings Part 1 into force on 29 April 2024, so far as not already in force. ## Related Topic Guides - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/applicability-test --- --- title: "UK PSTI Act Applicability Test" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/applicability-test" source_url: "https://www.sorena.io/artifacts/uk/psti-act/applicability-test" author: "Sorena AI" description: "Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products." keywords: - "UK PSTI applicability" - "relevant connectable product" - "network connectable product" - "excepted products PSTI" - "UK consumer connectable product" - "UK PSTI scope" - "internet-connectable product" - "network-connectable product" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Act Applicability Test Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. *Applicability Guide* *Product Scope* ## UK PSTI Act Applicability Test Start with the product definition before you promise compliance or carve a product out. The PSTI scope test works at product level and depends on connectability, exclusions, and whether the product is made available to consumers in the United Kingdom. Section 4 says a relevant connectable product must meet condition A and condition B. Condition A is about whether the product is internet-connectable or network-connectable. Condition B is that it is not an excepted product. The current Schedule 3 list includes certain Northern Ireland products, EV smart charge points, medical devices, certain smart meter products, certain computers, and, since 25 February 2025, specified Great Britain vehicle categories. The analysis should be run product by product, including devices that rely on associated software or services. ## Apply the section 4 to 6 sequence in order Start by testing whether the product is internet-connectable or network-connectable. Then check the current Schedule 3 excepted product rules. Only after that should you move into role mapping, security requirements, or statement-of-compliance work. Mixed device ecosystems often fail because teams jump to the statement template before the scope logic is stable. - Identify whether the product connects to the internet directly or via another product - Check whether any current Schedule 3 exclusion changes the result, including the 2025 Great Britain vehicle additions - Document the marketed use, connectivity path, and UK consumer sales route ## Do not ignore software and associated services The Act allows security requirements to relate not only to the physical product, but also to software used for operation or use of the product and software or services used to provide services by means of the product. That means the scope memo should include the cloud, app, and support components that actually affect product security. - Map companion apps, onboarding flows, and cloud dependencies - Record which components affect passwords, vulnerability handling, and updates - Note where third-party services create evidence or control dependencies ## End with a role and evidence outcome The scope result is only useful if it tells the business which party acts as manufacturer, importer, or distributor for the UK route to market. That is what determines who prepares the statement, who retains it, and who must act when a compliance failure appears. One product can have different duty owners across different sales channels. - Produce a final scope and role memo for each product family - Set review triggers for firmware, service, packaging, or channel changes - Link the result directly to the product release checklist *Recommended next step* *Placement: after the applicability result* ## Turn UK PSTI Act Applicability Test into an operational assessment Assessment Autopilot can take UK PSTI Act Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on UK PSTI Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK PSTI Act Applicability Test](/solutions/assessment.md): Start from UK PSTI Act Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK PSTI Act](/contact.md): Review your current process, evidence gaps, and next steps for UK PSTI Act Applicability Test. ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [PSTI Act Commencement No. 2 Regulations 2023](https://www.legislation.gov.uk/uksi/2023/469/made?ref=sorena.io) - Brings Part 1 into force on 29 April 2024, so far as not already in force. ## Related Topic Guides - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/applicability-test --- --- title: "UK PSTI Act Checklist" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/checklist" source_url: "https://www.sorena.io/artifacts/uk/psti-act/checklist" author: "Sorena AI" description: "Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention." keywords: - "UK PSTI checklist" - "statement of compliance checklist" - "PSTI readiness checklist" - "OPSS readiness checklist" - "PSTI checklist" - "product security checklist" - "statement checklist" - "retention checklist" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Act Checklist Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. *Checklist* *Execution and Evidence* ## UK PSTI Act Checklist Use the checklist to verify that the product, statement, and support workflow all align. Each item should point to a dated artifact, a named owner, and a review trigger. A good PSTI checklist proves that the product was scoped correctly, the three mandatory duties were implemented, the statement or equivalent evidence file is complete for the legal route being used, and the post-market response path is ready before OPSS or a distributor asks questions. ## Scope and role checklist Start with the scope memo and role matrix. Without those two documents, the rest of the checklist can be assigned to the wrong party. Keep one checklist per product family or model group. - Relevant connectable product analysis approved - Exclusion and boundary rationale retained, including any current Schedule 3 category used - Manufacturer importer distributor roles documented - UK route to market and product identifiers confirmed *Recommended next step* *Placement: after the checklist block* ## Turn UK PSTI Act Checklist into an operational assessment Assessment Autopilot can take UK PSTI Act Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on UK PSTI Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK PSTI Act Checklist](/solutions/assessment.md): Start from UK PSTI Act Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK PSTI Act](/contact.md): Review your current process, evidence gaps, and next steps for UK PSTI Act Checklist. ## Control and statement checklist Check not only whether the three mandatory controls exist, but whether they match the product as shipped and the statement as issued. Misalignment between customer messaging and the statement is a common weakness. - No universal default passwords control verified - Public vulnerability reporting information published - Minimum security update period published and current - Statement of compliance or summary prepared and retained where required, or Schedule 2A evidence file checked where that route is used ## Post-market readiness checklist PSTI readiness includes the ability to handle compliance failures after launch. That means investigation logs, contact paths, and supply-stop decisions must be ready before a live issue appears. Test the evidence retrieval path as well as the control itself. - Compliance-failure escalation path documented - Importer and distributor notification templates prepared - Retention schedule set to 10 years or longer if the support period runs longer where a statement is required - Mock OPSS evidence retrieval exercise completed ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [OPSS enforcement policy](https://www.gov.uk/government/publications/safety-and-standards-enforcement-enforcement-policy/opss-enforcement-policy?ref=sorena.io) - Risk-based, proportionate, transparent, and escalating enforcement approach used by OPSS. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/checklist --- --- title: "UK PSTI Act Checklist" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/checklist" source_url: "https://www.sorena.io/artifacts/uk/psti-act/checklist" author: "Sorena AI" description: "Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention." keywords: - "UK PSTI checklist" - "statement of compliance checklist" - "PSTI readiness checklist" - "OPSS readiness checklist" - "PSTI checklist" - "product security checklist" - "statement checklist" - "retention checklist" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Act Checklist Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. *Checklist* *Execution and Evidence* ## UK PSTI Act Checklist Use the checklist to verify that the product, statement, and support workflow all align. Each item should point to a dated artifact, a named owner, and a review trigger. A good PSTI checklist proves that the product was scoped correctly, the three mandatory duties were implemented, the statement or equivalent evidence file is complete for the legal route being used, and the post-market response path is ready before OPSS or a distributor asks questions. ## Scope and role checklist Start with the scope memo and role matrix. Without those two documents, the rest of the checklist can be assigned to the wrong party. Keep one checklist per product family or model group. - Relevant connectable product analysis approved - Exclusion and boundary rationale retained, including any current Schedule 3 category used - Manufacturer importer distributor roles documented - UK route to market and product identifiers confirmed *Recommended next step* *Placement: after the checklist block* ## Turn UK PSTI Act Checklist into an operational assessment Assessment Autopilot can take UK PSTI Act Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on UK PSTI Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK PSTI Act Checklist](/solutions/assessment.md): Start from UK PSTI Act Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK PSTI Act](/contact.md): Review your current process, evidence gaps, and next steps for UK PSTI Act Checklist. ## Control and statement checklist Check not only whether the three mandatory controls exist, but whether they match the product as shipped and the statement as issued. Misalignment between customer messaging and the statement is a common weakness. - No universal default passwords control verified - Public vulnerability reporting information published - Minimum security update period published and current - Statement of compliance or summary prepared and retained where required, or Schedule 2A evidence file checked where that route is used ## Post-market readiness checklist PSTI readiness includes the ability to handle compliance failures after launch. That means investigation logs, contact paths, and supply-stop decisions must be ready before a live issue appears. Test the evidence retrieval path as well as the control itself. - Compliance-failure escalation path documented - Importer and distributor notification templates prepared - Retention schedule set to 10 years or longer if the support period runs longer where a statement is required - Mock OPSS evidence retrieval exercise completed ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [OPSS enforcement policy](https://www.gov.uk/government/publications/safety-and-standards-enforcement-enforcement-policy/opss-enforcement-policy?ref=sorena.io) - Risk-based, proportionate, transparent, and escalating enforcement approach used by OPSS. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/checklist --- --- title: "UK PSTI Act Compliance Program" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/compliance" source_url: "https://www.sorena.io/artifacts/uk/psti-act/compliance" author: "Sorena AI" description: "Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks." keywords: - "UK PSTI compliance program" - "product security governance PSTI" - "OPSS readiness program" - "PSTI compliance program" - "product security governance" - "OPSS readiness" - "supply chain governance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Act Compliance Program Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. *Program Guide* *Governance and Operations* ## UK PSTI Act Compliance Program A workable PSTI program connects legal duties to engineering, support, and channel operations. The goal is to keep each in-scope product inside a defensible security and documentation posture from launch through the support period. A strong PSTI program has four layers: product scope and role allocation, implementation of the three mandatory security duties, statement or deemed-compliance governance, and post-market compliance-failure response. The same governance should absorb firmware changes, support-period changes, label-status changes, and supply-chain escalation events. ## Set governance per product family, not only per brand Each product family should have a named owner for scope, controls, and the correct UK documentation route. The program should not rely on a single central policy team to interpret every product change after the fact. This is what keeps the support-period, statement, and any label-based deemed-compliance data current. - Product owner, legal owner, and evidence owner assigned - Quarterly review cadence across engineering, support, and compliance - One evidence location per product family ## Link the legal duties to real engineering and support controls The three mandatory requirements should appear in design reviews, release gates, support workflows, and product pages. This keeps the statement or equivalent UK evidence route grounded in actual operating practice rather than a separate compliance narrative. Importers and distributors should also see the outputs they depend on before a product reaches the UK market, whether that is a statement path or a Schedule 2A evidence path. - Release check for passwords, disclosure info, and support-period publication - Support and security intake linked to the public disclosure route - Channel and supply teams given current statement materials or current Schedule 2A evidence ## Measure readiness by evidence retrieval and failure handling OPSS readiness is not only whether the control exists. It is whether the business can retrieve the scope memo, the correct statement or Schedule 2A evidence set, any applicable retention record, and the compliance-failure file quickly and coherently. Run mock cases before a real issue appears. - Test statement or Schedule 2A evidence retrieval and any applicable retention controls - Run a mock compliance-failure escalation exercise - Review whether support-period promises still match live product support *Recommended next step* *Placement: after the compliance steps* ## Turn UK PSTI Act Compliance Program into an operational assessment Assessment Autopilot can take UK PSTI Act Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on UK PSTI Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK PSTI Act Compliance Program](/solutions/assessment.md): Start from UK PSTI Act Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK PSTI Act](/contact.md): Review your current process, evidence gaps, and next steps for UK PSTI Act Compliance Program. ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [OPSS enforcement policy](https://www.gov.uk/government/publications/safety-and-standards-enforcement-enforcement-policy/opss-enforcement-policy?ref=sorena.io) - Risk-based, proportionate, transparent, and escalating enforcement approach used by OPSS. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/compliance --- --- title: "UK PSTI Act Compliance Program" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/compliance" source_url: "https://www.sorena.io/artifacts/uk/psti-act/compliance" author: "Sorena AI" description: "Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks." keywords: - "UK PSTI compliance program" - "product security governance PSTI" - "OPSS readiness program" - "PSTI compliance program" - "product security governance" - "OPSS readiness" - "supply chain governance" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Act Compliance Program Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. *Program Guide* *Governance and Operations* ## UK PSTI Act Compliance Program A workable PSTI program connects legal duties to engineering, support, and channel operations. The goal is to keep each in-scope product inside a defensible security and documentation posture from launch through the support period. A strong PSTI program has four layers: product scope and role allocation, implementation of the three mandatory security duties, statement or deemed-compliance governance, and post-market compliance-failure response. The same governance should absorb firmware changes, support-period changes, label-status changes, and supply-chain escalation events. ## Set governance per product family, not only per brand Each product family should have a named owner for scope, controls, and the correct UK documentation route. The program should not rely on a single central policy team to interpret every product change after the fact. This is what keeps the support-period, statement, and any label-based deemed-compliance data current. - Product owner, legal owner, and evidence owner assigned - Quarterly review cadence across engineering, support, and compliance - One evidence location per product family ## Link the legal duties to real engineering and support controls The three mandatory requirements should appear in design reviews, release gates, support workflows, and product pages. This keeps the statement or equivalent UK evidence route grounded in actual operating practice rather than a separate compliance narrative. Importers and distributors should also see the outputs they depend on before a product reaches the UK market, whether that is a statement path or a Schedule 2A evidence path. - Release check for passwords, disclosure info, and support-period publication - Support and security intake linked to the public disclosure route - Channel and supply teams given current statement materials or current Schedule 2A evidence ## Measure readiness by evidence retrieval and failure handling OPSS readiness is not only whether the control exists. It is whether the business can retrieve the scope memo, the correct statement or Schedule 2A evidence set, any applicable retention record, and the compliance-failure file quickly and coherently. Run mock cases before a real issue appears. - Test statement or Schedule 2A evidence retrieval and any applicable retention controls - Run a mock compliance-failure escalation exercise - Review whether support-period promises still match live product support *Recommended next step* *Placement: after the compliance steps* ## Turn UK PSTI Act Compliance Program into an operational assessment Assessment Autopilot can take UK PSTI Act Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on UK PSTI Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK PSTI Act Compliance Program](/solutions/assessment.md): Start from UK PSTI Act Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK PSTI Act](/contact.md): Review your current process, evidence gaps, and next steps for UK PSTI Act Compliance Program. ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [OPSS enforcement policy](https://www.gov.uk/government/publications/safety-and-standards-enforcement-enforcement-policy/opss-enforcement-policy?ref=sorena.io) - Risk-based, proportionate, transparent, and escalating enforcement approach used by OPSS. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/compliance --- --- title: "UK PSTI Act Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/uk/psti-act/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force." keywords: - "UK PSTI deadlines" - "29 April 2024 PSTI" - "UKSI 2023 1007" - "first review report 2029 PSTI" - "PSTI deadlines" - "compliance calendar" - "29 April 2024" - "review report" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Act Deadlines and Compliance Calendar Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. *Calendar* *Implementation Milestones* ## Deadlines and Compliance Calendar Use the legal timeline as an operating calendar, not as background history. The commencement and review dates should drive statement, release, and record-retention planning. The PSTI regime has fewer implementation phases than some broader platform laws, but the dates still matter. The Act received Royal Assent in 2022, commencement moved in stages, the security requirements came into force on 29 April 2024, the first 2025 amendment came into force on 25 February 2025, the second 2025 amendment came into force on 4 December 2025, and the regulations require a first review report within five years of the 29 April 2024 commencement date. ## Key legal milestones through commencement The timeline starts with Royal Assent on 6 December 2022, then moves through the 2023 commencement regulations and the September 2023 security requirements regulations. The main compliance starting point for product security duties is 29 April 2024, but the current law also reflects the amendments that came into force on 25 February 2025 and 4 December 2025. Use that date as the baseline for product availability and statement readiness. - 6 December 2022: Royal Assent - 14 September 2023: security requirements regulations made - 29 April 2024: Part 1 and the regulations in force - 25 February 2025: Schedule 3 and support-period amendment in force - 4 December 2025: expanded deemed-compliance routes in force *Recommended next step* *Placement: after the timeline or milestone section* ## Turn Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on Deadlines and can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Deadlines and Compliance Calendar](/solutions/assessment.md): Start from Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Deadlines and](/contact.md): Review your current process, evidence gaps, and next steps for Deadlines and Compliance Calendar. ## Standards, amendments, and policy updates to watch The original regulations reference ETSI EN 303 645 V2.1.1 for one deemed-compliance route, while the current law also preserves an ISO/IEC 29147 route for vulnerability disclosure and, since 4 December 2025, recognizes current JC-STAR STAR-1 and Singapore Cybersecurity Labelling Scheme labels in Schedules 2 and 2A. OPSS enforcement policy updates also matter because they show how the authority frames risk, proportionality, and escalating intervention. These updates should be reflected in assurance and governance review, even if they do not automatically change the three statutory duties. - 19 June 2020: referenced ETSI V2.1.1 adoption date - 11 September 2024: ETSI V3.1.3 adoption date - 25 February 2025 and 4 December 2025: current amendment dates that change scope and deemed-compliance analysis - 27 January 2025 and 26 January 2026: later OPSS policy update points ## Review and retention planning dates Regulation 10 requires the first review report before the end of five years beginning with the date the regulations came into force. That puts the first review deadline by 28 April 2029. Statement retention also runs beyond standard document periods where the defined support period is longer, but only where the statement route is being used. These dates should be visible in the compliance calendar, not hidden in legal notes. - By 28 April 2029: first review report due - Statement retention: 10 years or the support period, whichever is longer, where a statement is required - Schedule support-period review before any product support commitment changes ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [PSTI Act Commencement No. 1 Regulations 2023](https://www.legislation.gov.uk/uksi/2023/109/made?ref=sorena.io) - First commencement stage for the PSTI Act. - [PSTI Act Commencement No. 2 Regulations 2023](https://www.legislation.gov.uk/uksi/2023/469/made?ref=sorena.io) - Brings Part 1 into force on 29 April 2024, so far as not already in force. - [OPSS enforcement policy](https://www.gov.uk/government/publications/safety-and-standards-enforcement-enforcement-policy/opss-enforcement-policy?ref=sorena.io) - Risk-based, proportionate, transparent, and escalating enforcement approach used by OPSS. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/deadlines-and-compliance-calendar --- --- title: "UK PSTI Act Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/uk/psti-act/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force." keywords: - "UK PSTI deadlines" - "29 April 2024 PSTI" - "UKSI 2023 1007" - "first review report 2029 PSTI" - "PSTI deadlines" - "compliance calendar" - "29 April 2024" - "review report" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Act Deadlines and Compliance Calendar Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. *Calendar* *Implementation Milestones* ## Deadlines and Compliance Calendar Use the legal timeline as an operating calendar, not as background history. The commencement and review dates should drive statement, release, and record-retention planning. The PSTI regime has fewer implementation phases than some broader platform laws, but the dates still matter. The Act received Royal Assent in 2022, commencement moved in stages, the security requirements came into force on 29 April 2024, the first 2025 amendment came into force on 25 February 2025, the second 2025 amendment came into force on 4 December 2025, and the regulations require a first review report within five years of the 29 April 2024 commencement date. ## Key legal milestones through commencement The timeline starts with Royal Assent on 6 December 2022, then moves through the 2023 commencement regulations and the September 2023 security requirements regulations. The main compliance starting point for product security duties is 29 April 2024, but the current law also reflects the amendments that came into force on 25 February 2025 and 4 December 2025. Use that date as the baseline for product availability and statement readiness. - 6 December 2022: Royal Assent - 14 September 2023: security requirements regulations made - 29 April 2024: Part 1 and the regulations in force - 25 February 2025: Schedule 3 and support-period amendment in force - 4 December 2025: expanded deemed-compliance routes in force *Recommended next step* *Placement: after the timeline or milestone section* ## Turn Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on Deadlines and can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Deadlines and Compliance Calendar](/solutions/assessment.md): Start from Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Deadlines and](/contact.md): Review your current process, evidence gaps, and next steps for Deadlines and Compliance Calendar. ## Standards, amendments, and policy updates to watch The original regulations reference ETSI EN 303 645 V2.1.1 for one deemed-compliance route, while the current law also preserves an ISO/IEC 29147 route for vulnerability disclosure and, since 4 December 2025, recognizes current JC-STAR STAR-1 and Singapore Cybersecurity Labelling Scheme labels in Schedules 2 and 2A. OPSS enforcement policy updates also matter because they show how the authority frames risk, proportionality, and escalating intervention. These updates should be reflected in assurance and governance review, even if they do not automatically change the three statutory duties. - 19 June 2020: referenced ETSI V2.1.1 adoption date - 11 September 2024: ETSI V3.1.3 adoption date - 25 February 2025 and 4 December 2025: current amendment dates that change scope and deemed-compliance analysis - 27 January 2025 and 26 January 2026: later OPSS policy update points ## Review and retention planning dates Regulation 10 requires the first review report before the end of five years beginning with the date the regulations came into force. That puts the first review deadline by 28 April 2029. Statement retention also runs beyond standard document periods where the defined support period is longer, but only where the statement route is being used. These dates should be visible in the compliance calendar, not hidden in legal notes. - By 28 April 2029: first review report due - Statement retention: 10 years or the support period, whichever is longer, where a statement is required - Schedule support-period review before any product support commitment changes ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [PSTI Act Commencement No. 1 Regulations 2023](https://www.legislation.gov.uk/uksi/2023/109/made?ref=sorena.io) - First commencement stage for the PSTI Act. - [PSTI Act Commencement No. 2 Regulations 2023](https://www.legislation.gov.uk/uksi/2023/469/made?ref=sorena.io) - Brings Part 1 into force on 29 April 2024, so far as not already in force. - [OPSS enforcement policy](https://www.gov.uk/government/publications/safety-and-standards-enforcement-enforcement-policy/opss-enforcement-policy?ref=sorena.io) - Risk-based, proportionate, transparent, and escalating enforcement approach used by OPSS. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/deadlines-and-compliance-calendar --- --- title: "UK PSTI Act FAQ" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/faq" source_url: "https://www.sorena.io/artifacts/uk/psti-act/faq" author: "Sorena AI" description: "Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention." keywords: - "UK PSTI FAQ" - "statement of compliance FAQ" - "support period FAQ" - "relevant connectable product FAQ" - "statement FAQ" - "product security FAQ" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Act FAQ Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. *FAQ* *Implementation Questions* ## UK PSTI Act FAQ Use this page to answer the PSTI questions that block launches and channel decisions. Most confusion comes from mixing product scope, role duties, statement drafting, and post-market failure handling into one undifferentiated issue. These are the questions that usually slow teams down: what counts as a relevant connectable product, what the three mandatory requirements really say, what the current excepted product and deemed-compliance routes are, how long statements must be retained when the statement route applies, and what importers or distributors must do when a defect appears. ## Which products are in scope? A relevant connectable product must meet the section 4 connectivity condition and must not be an excepted product. The answer should be reached product by product rather than only by brand or category label, using the current Schedule 3 list rather than the original 2023 list alone. Associated software and services still matter because security requirements can relate to them. - Run the section 4 to 6 logic in order - Check whether any current Schedule 3 category or 2025 Great Britain vehicle exception applies - Document associated service and app dependencies - Keep the scope memo with the product release file ## What exactly must the manufacturer publish? Under the regulations, the manufacturer must address three mandatory areas: no universal default passwords, vulnerability reporting information, and minimum security update period information. For most products, the statement of compliance is a separate duty layer that supports UK availability, but since 4 December 2025 some products can instead rely on the Schedule 2A deemed-compliance route tied to current JC-STAR STAR-1 or Singapore Cybersecurity Labelling Scheme labels. Do not confuse the public support-period information with the internal evidence file that supports it. - Publish disclosure information and support-period information - Prepare the statement or compliant summary where required, or keep the Schedule 2A evidence file where that route is used - Retain the supporting evidence behind those outputs ## Is ETSI mandatory, what other routes exist, and how long are records retained? No. The legal duties come from the Act and regulations. ETSI EN 303 645 V2.1.1 remains one deemed-compliance route, the regulations also keep an ISO/IEC 29147 route for vulnerability disclosure, and, since 4 December 2025, they also recognize current JC-STAR STAR-1 and Singapore Cybersecurity Labelling Scheme label routes. Statement retention for manufacturers and importers runs for the longer of 10 years from issue and the defined support period where a statement is required under section 9(2) or section 15(2). That is why a strong legal map and a strong assurance map should be kept side by side. - Use ETSI and related standards as assurance support, not as a replacement for the legal text - Check whether the product is using the statement route or a Schedule 2A route before setting retention duties - Calculate retention against the support period as well as the issue date where the statement route applies *Recommended next step* *Placement: after the FAQ section* ## Use UK PSTI Act FAQ as a cited research workflow Research Copilot can take UK PSTI Act FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on UK PSTI Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK PSTI Act FAQ](/solutions/research-copilot.md): Start from UK PSTI Act FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK PSTI Act](/contact.md): Review your current process, evidence gaps, and next steps for UK PSTI Act FAQ. ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [ETSI EN 303 645 V2.1.1 reference used in the regulations](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - One deemed-compliance standard named by the UK regulations; the current law also includes other deemed-compliance routes. - [ETSI TS 103 701 conformance assessment](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/01.01.01_60/ts_103701v010101p.pdf?ref=sorena.io) - Conformance assessment specification used to test and evidence EN 303 645 style requirements. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/faq --- --- title: "UK PSTI Act FAQ" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/faq" source_url: "https://www.sorena.io/artifacts/uk/psti-act/faq" author: "Sorena AI" description: "Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention." keywords: - "UK PSTI FAQ" - "statement of compliance FAQ" - "support period FAQ" - "relevant connectable product FAQ" - "statement FAQ" - "product security FAQ" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Act FAQ Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. *FAQ* *Implementation Questions* ## UK PSTI Act FAQ Use this page to answer the PSTI questions that block launches and channel decisions. Most confusion comes from mixing product scope, role duties, statement drafting, and post-market failure handling into one undifferentiated issue. These are the questions that usually slow teams down: what counts as a relevant connectable product, what the three mandatory requirements really say, what the current excepted product and deemed-compliance routes are, how long statements must be retained when the statement route applies, and what importers or distributors must do when a defect appears. ## Which products are in scope? A relevant connectable product must meet the section 4 connectivity condition and must not be an excepted product. The answer should be reached product by product rather than only by brand or category label, using the current Schedule 3 list rather than the original 2023 list alone. Associated software and services still matter because security requirements can relate to them. - Run the section 4 to 6 logic in order - Check whether any current Schedule 3 category or 2025 Great Britain vehicle exception applies - Document associated service and app dependencies - Keep the scope memo with the product release file ## What exactly must the manufacturer publish? Under the regulations, the manufacturer must address three mandatory areas: no universal default passwords, vulnerability reporting information, and minimum security update period information. For most products, the statement of compliance is a separate duty layer that supports UK availability, but since 4 December 2025 some products can instead rely on the Schedule 2A deemed-compliance route tied to current JC-STAR STAR-1 or Singapore Cybersecurity Labelling Scheme labels. Do not confuse the public support-period information with the internal evidence file that supports it. - Publish disclosure information and support-period information - Prepare the statement or compliant summary where required, or keep the Schedule 2A evidence file where that route is used - Retain the supporting evidence behind those outputs ## Is ETSI mandatory, what other routes exist, and how long are records retained? No. The legal duties come from the Act and regulations. ETSI EN 303 645 V2.1.1 remains one deemed-compliance route, the regulations also keep an ISO/IEC 29147 route for vulnerability disclosure, and, since 4 December 2025, they also recognize current JC-STAR STAR-1 and Singapore Cybersecurity Labelling Scheme label routes. Statement retention for manufacturers and importers runs for the longer of 10 years from issue and the defined support period where a statement is required under section 9(2) or section 15(2). That is why a strong legal map and a strong assurance map should be kept side by side. - Use ETSI and related standards as assurance support, not as a replacement for the legal text - Check whether the product is using the statement route or a Schedule 2A route before setting retention duties - Calculate retention against the support period as well as the issue date where the statement route applies *Recommended next step* *Placement: after the FAQ section* ## Use UK PSTI Act FAQ as a cited research workflow Research Copilot can take UK PSTI Act FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on UK PSTI Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK PSTI Act FAQ](/solutions/research-copilot.md): Start from UK PSTI Act FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK PSTI Act](/contact.md): Review your current process, evidence gaps, and next steps for UK PSTI Act FAQ. ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [ETSI EN 303 645 V2.1.1 reference used in the regulations](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - One deemed-compliance standard named by the UK regulations; the current law also includes other deemed-compliance routes. - [ETSI TS 103 701 conformance assessment](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/01.01.01_60/ts_103701v010101p.pdf?ref=sorena.io) - Conformance assessment specification used to test and evidence EN 303 645 style requirements. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/faq --- --- title: "UK PSTI OPSS Enforcement and Penalties" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/opss-enforcement-and-penalties" source_url: "https://www.sorena.io/artifacts/uk/psti-act/opss-enforcement-and-penalties" author: "Sorena AI" description: "Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations." keywords: - "OPSS enforcement PSTI" - "UK PSTI penalties" - "OPSS risk based enforcement" - "product security enforcement UK" - "OPSS enforcement" - "PSTI penalties" - "risk based regulation" - "product security enforcement" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI OPSS Enforcement and Penalties Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. *Enforcement Guide* *OPSS Readiness* ## OPSS Enforcement and Penalties OPSS describes its enforcement model as risk-based, proportionate, consistent, transparent, and escalating where necessary. That means product teams should expect the quality of their evidence and response behavior to matter just as much as the original defect. OPSS says its primary concerns when non-compliance or product safety risk is identified are protection and ensuring adequate steps are taken to address the issue and minimise recurrence. For a PSTI program, that means the evidence file should already show scope, the correct statement or deemed-compliance route, support-period, and compliance-failure handling maturity before OPSS ever asks for it. ## Expect evidence-led intervention first A regulator response usually starts with what the business can show about the product, the statement or other applicable UK evidence route, and the handling of the issue. Weak or contradictory records create unnecessary escalation risk. The best preparation is a clean product evidence file and a clear escalation owner. - Keep the scope memo, the statement or deemed-compliance evidence, and any applicable retention record together - Store compliance-failure investigations in one retrievable case file - Name the owner for regulator contact and evidence assembly ## Treat compliance failures as live regulatory events The Act requires action after launch when a duty holder becomes aware of a compliance failure. Those records will be central to any OPSS review because they show whether the business moved quickly, informed the right parties, and tried to prevent further availability where needed. Do not let these actions happen informally in email only. - Timestamp discovery, triage, contact, and notification actions - Record whether supply was paused and why - Retain remediation outcomes and whether they succeeded ## Plan for sustained and escalating intervention OPSS states that it will use the tools and powers available to hold businesses to their responsibilities and will undertake sustained and escalating interventions where necessary. The right response is to fix the underlying controls quickly and to prove that recurrence risk is falling. A purely defensive legal posture without operational correction is usually a weak strategy. - Escalate repeated statement, deemed-compliance, or support-period issues to senior management - Track recurring defect patterns across product families - Re-test the control after remediation and retain the proof *Recommended next step* *Placement: after the enforcement section* ## Use OPSS Enforcement and Penalties as a cited research workflow Research Copilot can take OPSS Enforcement and Penalties from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on OPSS Enforcement can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for OPSS Enforcement and Penalties](/solutions/research-copilot.md): Start from OPSS Enforcement and Penalties and answer scope, timing, and interpretation questions with cited outputs. - [Talk through OPSS Enforcement](/contact.md): Review your current process, evidence gaps, and next steps for OPSS Enforcement and Penalties. ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [OPSS enforcement policy](https://www.gov.uk/government/publications/safety-and-standards-enforcement-enforcement-policy/opss-enforcement-policy?ref=sorena.io) - Risk-based, proportionate, transparent, and escalating enforcement approach used by OPSS. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/opss-enforcement-and-penalties --- --- title: "UK PSTI OPSS Enforcement and Penalties" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/opss-enforcement-and-penalties" source_url: "https://www.sorena.io/artifacts/uk/psti-act/opss-enforcement-and-penalties" author: "Sorena AI" description: "Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations." keywords: - "OPSS enforcement PSTI" - "UK PSTI penalties" - "OPSS risk based enforcement" - "product security enforcement UK" - "OPSS enforcement" - "PSTI penalties" - "risk based regulation" - "product security enforcement" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI OPSS Enforcement and Penalties Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. *Enforcement Guide* *OPSS Readiness* ## OPSS Enforcement and Penalties OPSS describes its enforcement model as risk-based, proportionate, consistent, transparent, and escalating where necessary. That means product teams should expect the quality of their evidence and response behavior to matter just as much as the original defect. OPSS says its primary concerns when non-compliance or product safety risk is identified are protection and ensuring adequate steps are taken to address the issue and minimise recurrence. For a PSTI program, that means the evidence file should already show scope, the correct statement or deemed-compliance route, support-period, and compliance-failure handling maturity before OPSS ever asks for it. ## Expect evidence-led intervention first A regulator response usually starts with what the business can show about the product, the statement or other applicable UK evidence route, and the handling of the issue. Weak or contradictory records create unnecessary escalation risk. The best preparation is a clean product evidence file and a clear escalation owner. - Keep the scope memo, the statement or deemed-compliance evidence, and any applicable retention record together - Store compliance-failure investigations in one retrievable case file - Name the owner for regulator contact and evidence assembly ## Treat compliance failures as live regulatory events The Act requires action after launch when a duty holder becomes aware of a compliance failure. Those records will be central to any OPSS review because they show whether the business moved quickly, informed the right parties, and tried to prevent further availability where needed. Do not let these actions happen informally in email only. - Timestamp discovery, triage, contact, and notification actions - Record whether supply was paused and why - Retain remediation outcomes and whether they succeeded ## Plan for sustained and escalating intervention OPSS states that it will use the tools and powers available to hold businesses to their responsibilities and will undertake sustained and escalating interventions where necessary. The right response is to fix the underlying controls quickly and to prove that recurrence risk is falling. A purely defensive legal posture without operational correction is usually a weak strategy. - Escalate repeated statement, deemed-compliance, or support-period issues to senior management - Track recurring defect patterns across product families - Re-test the control after remediation and retain the proof *Recommended next step* *Placement: after the enforcement section* ## Use OPSS Enforcement and Penalties as a cited research workflow Research Copilot can take OPSS Enforcement and Penalties from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on OPSS Enforcement can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for OPSS Enforcement and Penalties](/solutions/research-copilot.md): Start from OPSS Enforcement and Penalties and answer scope, timing, and interpretation questions with cited outputs. - [Talk through OPSS Enforcement](/contact.md): Review your current process, evidence gaps, and next steps for OPSS Enforcement and Penalties. ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [OPSS enforcement policy](https://www.gov.uk/government/publications/safety-and-standards-enforcement-enforcement-policy/opss-enforcement-policy?ref=sorena.io) - Risk-based, proportionate, transparent, and escalating enforcement approach used by OPSS. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/opss-enforcement-and-penalties --- --- title: "UK PSTI Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/uk/psti-act/penalties-and-fines" author: "Sorena AI" description: "Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches." keywords: - "UK PSTI penalties" - "PSTI fines" - "OPSS penalty exposure" - "statement of compliance defect risk" - "PSTI penalties" - "financial exposure" - "OPSS enforcement" - "statement defects" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Penalties and Fines Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. *Penalty Guide* *Exposure and Mitigation* ## Penalties and Fines Penalty exposure under PSTI usually grows out of poor records and weak post-market handling. The right way to reduce exposure is to keep the legal duties, engineering reality, and supply-chain actions aligned from the start. PSTI penalty exposure should be analysed through the defects that are easiest to prove: a product wrongly treated as out of scope, a missing or weak statement where the statement route applies, missing or weak deemed-compliance evidence where that route is used, a support-period inconsistency, or a poor response after a compliance failure is identified. These are all control and evidence failures before they are penalty problems. ## Quantify the exposure by product family and route to market Start by identifying which product families have the largest volume, the broadest UK distribution, or the highest support-period complexity. Those are often the lines where statement, deemed-compliance, or scope defects are most damaging. This gives the business a rational remediation priority order. - Rank products by UK sales exposure and control maturity - Prioritise products with complex channel or importer arrangements - Flag products where support promises changed recently ## Reduce exposure with strong evidence and fast correction Businesses that can show they understood the scope, used the correct statement or deemed-compliance route, and took prompt steps after a failure was identified are better positioned than businesses with incomplete or contradictory files. That is why every serious issue should end with a remediation record and retest evidence. - Keep dated evidence of what changed and why - Update statements, support disclosures, or deemed-compliance evidence where required - Retain the retest or verification output after a fix ## Treat supply-chain coordination as part of exposure control Importer and distributor actions can increase or reduce the practical penalty risk. Where the channel continues to supply a product after a known defect without proper escalation, the case becomes harder to defend. A channel control gap is therefore part of the penalty model. - Train importers and distributors on statement, deemed-compliance, and failure signals - Keep contact trees and stop-supply criteria ready - Verify that channel partners can retrieve the current statement summary or the current deemed-compliance evidence they are expected to check *Recommended next step* *Placement: after the enforcement section* ## Use Penalties and Fines as a cited research workflow Research Copilot can take Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on Penalties can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Penalties and Fines](/solutions/research-copilot.md): Start from Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Penalties](/contact.md): Review your current process, evidence gaps, and next steps for Penalties and Fines. ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [OPSS enforcement policy](https://www.gov.uk/government/publications/safety-and-standards-enforcement-enforcement-policy/opss-enforcement-policy?ref=sorena.io) - Risk-based, proportionate, transparent, and escalating enforcement approach used by OPSS. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/penalties-and-fines --- --- title: "UK PSTI Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/uk/psti-act/penalties-and-fines" author: "Sorena AI" description: "Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches." keywords: - "UK PSTI penalties" - "PSTI fines" - "OPSS penalty exposure" - "statement of compliance defect risk" - "PSTI penalties" - "financial exposure" - "OPSS enforcement" - "statement defects" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Penalties and Fines Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. *Penalty Guide* *Exposure and Mitigation* ## Penalties and Fines Penalty exposure under PSTI usually grows out of poor records and weak post-market handling. The right way to reduce exposure is to keep the legal duties, engineering reality, and supply-chain actions aligned from the start. PSTI penalty exposure should be analysed through the defects that are easiest to prove: a product wrongly treated as out of scope, a missing or weak statement where the statement route applies, missing or weak deemed-compliance evidence where that route is used, a support-period inconsistency, or a poor response after a compliance failure is identified. These are all control and evidence failures before they are penalty problems. ## Quantify the exposure by product family and route to market Start by identifying which product families have the largest volume, the broadest UK distribution, or the highest support-period complexity. Those are often the lines where statement, deemed-compliance, or scope defects are most damaging. This gives the business a rational remediation priority order. - Rank products by UK sales exposure and control maturity - Prioritise products with complex channel or importer arrangements - Flag products where support promises changed recently ## Reduce exposure with strong evidence and fast correction Businesses that can show they understood the scope, used the correct statement or deemed-compliance route, and took prompt steps after a failure was identified are better positioned than businesses with incomplete or contradictory files. That is why every serious issue should end with a remediation record and retest evidence. - Keep dated evidence of what changed and why - Update statements, support disclosures, or deemed-compliance evidence where required - Retain the retest or verification output after a fix ## Treat supply-chain coordination as part of exposure control Importer and distributor actions can increase or reduce the practical penalty risk. Where the channel continues to supply a product after a known defect without proper escalation, the case becomes harder to defend. A channel control gap is therefore part of the penalty model. - Train importers and distributors on statement, deemed-compliance, and failure signals - Keep contact trees and stop-supply criteria ready - Verify that channel partners can retrieve the current statement summary or the current deemed-compliance evidence they are expected to check *Recommended next step* *Placement: after the enforcement section* ## Use Penalties and Fines as a cited research workflow Research Copilot can take Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on Penalties can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Penalties and Fines](/solutions/research-copilot.md): Start from Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Penalties](/contact.md): Review your current process, evidence gaps, and next steps for Penalties and Fines. ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [OPSS enforcement policy](https://www.gov.uk/government/publications/safety-and-standards-enforcement-enforcement-policy/opss-enforcement-policy?ref=sorena.io) - Risk-based, proportionate, transparent, and escalating enforcement approach used by OPSS. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/penalties-and-fines --- --- title: "UK PSTI Password and Update Policy Requirements" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/psti-password-and-update-policy-requirements" source_url: "https://www.sorena.io/artifacts/uk/psti-act/psti-password-and-update-policy-requirements" author: "Sorena AI" description: "Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information." keywords: - "UK PSTI password requirements" - "unique per device password" - "vulnerability disclosure information" - "minimum security update period" - "password requirements" - "security update period" - "vulnerability disclosure" - "PSTI controls" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Password and Update Policy Requirements Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. *Control Guide* *3 Mandatory Duties* ## Password and Update Policy Requirements The UK PSTI regime only mandates three security requirements, but each one needs real operational backing. The legal text is concise. The implementation challenge is making the controls provable for every product family and release stream. Schedule 1 to the regulations requires manufacturers to meet three baseline duties: no universal default passwords, publicly available vulnerability reporting information, and publicly available information about the minimum security update period. Every implementation question should be traced back to one of those three duties, while statement and retention duties should be checked separately. ## Password control means no shared defaults across a class of product The password duty is simple in wording but easy to fail in practice. If a product uses passwords, each password must either be unique per product or defined by the user of the product. That is tighter than a generic policy against weak defaults. If you use pre-installed unique passwords, do not derive them from an incremental counter, publicly available information, or a serial number unless the derivation method is protected so that a person who knows the serial number cannot practically work out the password. ETSI material remains useful for designing and testing that control. - Remove universal factory passwords from all customer-facing authentication paths - Ensure each password is unique per product or defined by the user - Do not rely on obvious derivations from counters, public information, or exposed serial numbers - Document the credential design for each product model and interface ## Vulnerability disclosure information must be public and usable The duty is not satisfied by an internal mailbox or an unpublished security page. The information must be publicly available, clear, transparent, in English, free of charge, and available without prior request or the collection of personal information before the person can read it. The published information must explain how to report issues and when the reporter should expect an acknowledgement of receipt and status updates. ETSI guidance is useful here because it helps teams operationalize those public commitments, even though the UK law does not impose a single fixed remediation deadline. - Publish a security contact path and disclosure information in English and free of charge - Include how to report issues, acknowledgement timing, and status-update timing - Route reports into triage, severity assessment, and remediation - Retain the handling record for later statement and enforcement evidence ## Support period information must be specific and durable The manufacturer must publish the defined support period in a way that is accessible, clear, transparent, in English, free of charge, and available without prior request or the collection of personal information. The published period is the minimum length of time, expressed as a period with an end date, for which security updates will be provided. Where the manufacturer publishes an invitation to purchase on its own website or another non-paid-for online sales channel it controls, the support-period information must appear there alongside the purchase information or with equivalent prominence. If the statement route is used, the defined support period also controls statement retention. - Publish the defined support period clearly for each product family and sales page you control - Keep support-period records aligned with the statement route or other UK evidence route being used - Review support claims when hardware, software, or service dependencies change *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep Password and Update Policy Requirements in one governed evidence system SSOT can take Password and Update Policy Requirements from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on Password and can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for Password and Update Policy Requirements](/solutions/ssot.md): Start from Password and Update Policy Requirements and keep documents, evidence, and control records in one governed system. - [Talk through Password and](/contact.md): Review your current process, evidence gaps, and next steps for Password and Update Policy Requirements. ## Primary sources - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [ETSI EN 303 645 V2.1.1 reference used in the regulations](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - One deemed-compliance standard named by the UK regulations; the current law also includes other deemed-compliance routes. - [ETSI TS 103 701 conformance assessment](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/01.01.01_60/ts_103701v010101p.pdf?ref=sorena.io) - Conformance assessment specification used to test and evidence EN 303 645 style requirements. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/psti-password-and-update-policy-requirements --- --- title: "UK PSTI Password and Update Policy Requirements" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/psti-password-and-update-policy-requirements" source_url: "https://www.sorena.io/artifacts/uk/psti-act/psti-password-and-update-policy-requirements" author: "Sorena AI" description: "Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information." keywords: - "UK PSTI password requirements" - "unique per device password" - "vulnerability disclosure information" - "minimum security update period" - "password requirements" - "security update period" - "vulnerability disclosure" - "PSTI controls" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Password and Update Policy Requirements Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. *Control Guide* *3 Mandatory Duties* ## Password and Update Policy Requirements The UK PSTI regime only mandates three security requirements, but each one needs real operational backing. The legal text is concise. The implementation challenge is making the controls provable for every product family and release stream. Schedule 1 to the regulations requires manufacturers to meet three baseline duties: no universal default passwords, publicly available vulnerability reporting information, and publicly available information about the minimum security update period. Every implementation question should be traced back to one of those three duties, while statement and retention duties should be checked separately. ## Password control means no shared defaults across a class of product The password duty is simple in wording but easy to fail in practice. If a product uses passwords, each password must either be unique per product or defined by the user of the product. That is tighter than a generic policy against weak defaults. If you use pre-installed unique passwords, do not derive them from an incremental counter, publicly available information, or a serial number unless the derivation method is protected so that a person who knows the serial number cannot practically work out the password. ETSI material remains useful for designing and testing that control. - Remove universal factory passwords from all customer-facing authentication paths - Ensure each password is unique per product or defined by the user - Do not rely on obvious derivations from counters, public information, or exposed serial numbers - Document the credential design for each product model and interface ## Vulnerability disclosure information must be public and usable The duty is not satisfied by an internal mailbox or an unpublished security page. The information must be publicly available, clear, transparent, in English, free of charge, and available without prior request or the collection of personal information before the person can read it. The published information must explain how to report issues and when the reporter should expect an acknowledgement of receipt and status updates. ETSI guidance is useful here because it helps teams operationalize those public commitments, even though the UK law does not impose a single fixed remediation deadline. - Publish a security contact path and disclosure information in English and free of charge - Include how to report issues, acknowledgement timing, and status-update timing - Route reports into triage, severity assessment, and remediation - Retain the handling record for later statement and enforcement evidence ## Support period information must be specific and durable The manufacturer must publish the defined support period in a way that is accessible, clear, transparent, in English, free of charge, and available without prior request or the collection of personal information. The published period is the minimum length of time, expressed as a period with an end date, for which security updates will be provided. Where the manufacturer publishes an invitation to purchase on its own website or another non-paid-for online sales channel it controls, the support-period information must appear there alongside the purchase information or with equivalent prominence. If the statement route is used, the defined support period also controls statement retention. - Publish the defined support period clearly for each product family and sales page you control - Keep support-period records aligned with the statement route or other UK evidence route being used - Review support claims when hardware, software, or service dependencies change *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep Password and Update Policy Requirements in one governed evidence system SSOT can take Password and Update Policy Requirements from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on Password and can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for Password and Update Policy Requirements](/solutions/ssot.md): Start from Password and Update Policy Requirements and keep documents, evidence, and control records in one governed system. - [Talk through Password and](/contact.md): Review your current process, evidence gaps, and next steps for Password and Update Policy Requirements. ## Primary sources - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [ETSI EN 303 645 V2.1.1 reference used in the regulations](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - One deemed-compliance standard named by the UK regulations; the current law also includes other deemed-compliance routes. - [ETSI TS 103 701 conformance assessment](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/01.01.01_60/ts_103701v010101p.pdf?ref=sorena.io) - Conformance assessment specification used to test and evidence EN 303 645 style requirements. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/psti-password-and-update-policy-requirements --- --- title: "UK PSTI Statement of Compliance Template" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/psti-statement-of-compliance-template" source_url: "https://www.sorena.io/artifacts/uk/psti-act/psti-statement-of-compliance-template" author: "Sorena AI" description: "Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls." keywords: - "UK PSTI statement of compliance template" - "section 9 statement template" - "defined support period statement" - "statement template" - "section 9" - "defined support period" - "PSTI documentation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Statement of Compliance Template Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. *Template* *Statement Drafting* ## PSTI Statement of Compliance Template A useful template reduces drafting drift across product lines. The template should pull information from the control and release workflow, not invent it at the last minute. The best statement template is one that only uses approved product identifiers, support-period values, and compliance conclusions taken from the product evidence file. That avoids the common failure where the statement and the product website describe different support periods or different security positions. It is also important to confirm that the product is actually using the section 9 statement route rather than the newer Schedule 2A deemed-compliance route. ## Template section one: product and manufacturer identity Start with the exact product identity, model references, and the manufacturer identity relevant to the UK route to market. Schedule 4 requires the product type plus any batch or serial number needed to identify the product, the manufacturer's name and address, and any authorised representative's name and address. If there are multiple manufacturers, the template must support the joint preparation position allowed by the Act. This is the anchor for every other statement field. - Product type, batch or serial number, and model or version identifiers - Manufacturer legal identity and address, plus any authorised representative details - Joint manufacturer logic where relevant *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep PSTI Statement of Compliance Template in one governed evidence system SSOT can take PSTI Statement of Compliance Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on PSTI Statement can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for PSTI Statement of Compliance Template](/solutions/ssot.md): Start from PSTI Statement of Compliance Template and keep documents, evidence, and control records in one governed system. - [Talk through PSTI Statement](/contact.md): Review your current process, evidence gaps, and next steps for PSTI Statement of Compliance Template. ## Template section two: applicable requirements and support period The template should identify the applicable security requirements and record the defined support period exactly as the customer-facing materials state it. Schedule 4 also requires the declaration that, in the manufacturer's opinion, the applicable security requirements have been complied with and that the support-period statement was correct when the manufacturer first supplied the product. Do not let teams type this freehand from memory. - List the applicable security requirements for the product - Include the manufacturer's compliance declaration in the Schedule 4 form - Pull the defined support period from the approved source of truth - Reference the supporting evidence file or release pack ## Template section three: approvals and recordkeeping The template should also support the internal approval path and retention calculation. Schedule 4 requires the name, function, and signature of the person signing, plus the place and date of issue. That means the template should capture the issue date and any links needed for later retrieval by the manufacturer and importer. A statement that cannot be version-controlled will eventually break the retention model, and if the product is on a Schedule 2A route the template should not be used as a substitute for checking those separate conditions. - Issue date, signatory name and function, signature, and place of issue - Evidence pack link or identifier - Retention schedule set to the longer of 10 years and the support period where the statement route applies ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/psti-statement-of-compliance-template --- --- title: "UK PSTI Statement of Compliance Template" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/psti-statement-of-compliance-template" source_url: "https://www.sorena.io/artifacts/uk/psti-act/psti-statement-of-compliance-template" author: "Sorena AI" description: "Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls." keywords: - "UK PSTI statement of compliance template" - "section 9 statement template" - "defined support period statement" - "statement template" - "section 9" - "defined support period" - "PSTI documentation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Statement of Compliance Template Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. *Template* *Statement Drafting* ## PSTI Statement of Compliance Template A useful template reduces drafting drift across product lines. The template should pull information from the control and release workflow, not invent it at the last minute. The best statement template is one that only uses approved product identifiers, support-period values, and compliance conclusions taken from the product evidence file. That avoids the common failure where the statement and the product website describe different support periods or different security positions. It is also important to confirm that the product is actually using the section 9 statement route rather than the newer Schedule 2A deemed-compliance route. ## Template section one: product and manufacturer identity Start with the exact product identity, model references, and the manufacturer identity relevant to the UK route to market. Schedule 4 requires the product type plus any batch or serial number needed to identify the product, the manufacturer's name and address, and any authorised representative's name and address. If there are multiple manufacturers, the template must support the joint preparation position allowed by the Act. This is the anchor for every other statement field. - Product type, batch or serial number, and model or version identifiers - Manufacturer legal identity and address, plus any authorised representative details - Joint manufacturer logic where relevant *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep PSTI Statement of Compliance Template in one governed evidence system SSOT can take PSTI Statement of Compliance Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on PSTI Statement can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for PSTI Statement of Compliance Template](/solutions/ssot.md): Start from PSTI Statement of Compliance Template and keep documents, evidence, and control records in one governed system. - [Talk through PSTI Statement](/contact.md): Review your current process, evidence gaps, and next steps for PSTI Statement of Compliance Template. ## Template section two: applicable requirements and support period The template should identify the applicable security requirements and record the defined support period exactly as the customer-facing materials state it. Schedule 4 also requires the declaration that, in the manufacturer's opinion, the applicable security requirements have been complied with and that the support-period statement was correct when the manufacturer first supplied the product. Do not let teams type this freehand from memory. - List the applicable security requirements for the product - Include the manufacturer's compliance declaration in the Schedule 4 form - Pull the defined support period from the approved source of truth - Reference the supporting evidence file or release pack ## Template section three: approvals and recordkeeping The template should also support the internal approval path and retention calculation. Schedule 4 requires the name, function, and signature of the person signing, plus the place and date of issue. That means the template should capture the issue date and any links needed for later retrieval by the manufacturer and importer. A statement that cannot be version-controlled will eventually break the retention model, and if the product is on a Schedule 2A route the template should not be used as a substitute for checking those separate conditions. - Issue date, signatory name and function, signature, and place of issue - Evidence pack link or identifier - Retention schedule set to the longer of 10 years and the support period where the statement route applies ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/psti-statement-of-compliance-template --- --- title: "UK PSTI vs EU Cyber Resilience Act" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act" source_url: "https://www.sorena.io/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act" author: "Sorena AI" description: "Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling." keywords: - "UK PSTI vs EU Cyber Resilience Act" - "PSTI CRA comparison" - "product security law comparison" - "PSTI vs CRA" - "Cyber Resilience Act comparison" - "product security comparison" - "market access" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI vs EU Cyber Resilience Act Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. *Comparison Guide* *UK and EU Product Security* ## UK PSTI vs EU Cyber Resilience Act The UK PSTI regime and the EU Cyber Resilience Act overlap, but they do not ask the same questions in the same way. A manufacturer selling into both markets should reuse evidence carefully while keeping separate legal mappings for UK consumer product duties and the broader EU framework. The UK PSTI regime is deliberately narrow and focused on consumer connectable products with three mandatory security requirements plus statement and supply-chain duties. The Cyber Resilience Act is broader, uses a different conformity and documentation structure, and reaches further into lifecycle and vulnerability-management obligations. Cross-market teams should therefore reuse evidence where it fits, not merge the laws into one unchecked program. ## PSTI is narrower and more explicit at the core control level PSTI focuses on relevant connectable products made available to consumers in the UK and on three mandatory security requirements. This makes the first compliance question very product-specific and channel-specific. The CRA takes a broader lifecycle and conformity route across connected products placed on the EU market. - Keep a UK product-scope file separate from the EU conformity file - Reuse engineering evidence only after checking the legal test on each side - Do not assume a UK statement satisfies EU conformity documentation ## Statements and conformity documents are not interchangeable For most products, PSTI relies on the section 9 statement of compliance and related summary and retention rules, but the current law also includes Schedule 2A cases where the section 9 accompaniment requirement is deemed to be met without that statement route. The CRA uses a different EU documentation and conformity structure. The practical result is that one evidence backbone can be shared, but the outward legal document set should remain jurisdiction-specific. This is especially important for support-period and post-market records. - Reuse product architecture, testing, and vulnerability evidence where valid - Draft UK and EU outward legal documents separately - Keep market-specific record-retention, deemed-compliance, and update workflows visible ## Use one engineering baseline with two legal wrappers The best pattern for dual-market products is one engineering baseline for passwords, vulnerability handling, updates, and release integrity, then a UK wrapper for PSTI and an EU wrapper for the CRA. This gives efficiency without masking legal differences. It also lets the business answer UK and EU regulator questions without contradictory paperwork. - Create one shared engineering evidence layer - Maintain separate UK and EU legal mappings and release outputs - Review support commitments for both markets before launch *Recommended next step* *Placement: after the comparison section* ## Use UK PSTI vs EU Cyber Resilience Act as a cited research workflow Research Copilot can take UK PSTI vs EU Cyber Resilience Act from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on UK PSTI can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK PSTI vs EU Cyber Resilience Act](/solutions/research-copilot.md): Start from UK PSTI vs EU Cyber Resilience Act and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK PSTI](/contact.md): Review your current process, evidence gaps, and next steps for UK PSTI vs EU Cyber Resilience Act. ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [Regulation (EU) 2024/2847 Cyber Resilience Act](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng) - Primary EU source used only for high level comparison with the UK PSTI regime. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act --- --- title: "UK PSTI vs EU Cyber Resilience Act" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act" source_url: "https://www.sorena.io/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act" author: "Sorena AI" description: "Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling." keywords: - "UK PSTI vs EU Cyber Resilience Act" - "PSTI CRA comparison" - "product security law comparison" - "PSTI vs CRA" - "Cyber Resilience Act comparison" - "product security comparison" - "market access" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI vs EU Cyber Resilience Act Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. *Comparison Guide* *UK and EU Product Security* ## UK PSTI vs EU Cyber Resilience Act The UK PSTI regime and the EU Cyber Resilience Act overlap, but they do not ask the same questions in the same way. A manufacturer selling into both markets should reuse evidence carefully while keeping separate legal mappings for UK consumer product duties and the broader EU framework. The UK PSTI regime is deliberately narrow and focused on consumer connectable products with three mandatory security requirements plus statement and supply-chain duties. The Cyber Resilience Act is broader, uses a different conformity and documentation structure, and reaches further into lifecycle and vulnerability-management obligations. Cross-market teams should therefore reuse evidence where it fits, not merge the laws into one unchecked program. ## PSTI is narrower and more explicit at the core control level PSTI focuses on relevant connectable products made available to consumers in the UK and on three mandatory security requirements. This makes the first compliance question very product-specific and channel-specific. The CRA takes a broader lifecycle and conformity route across connected products placed on the EU market. - Keep a UK product-scope file separate from the EU conformity file - Reuse engineering evidence only after checking the legal test on each side - Do not assume a UK statement satisfies EU conformity documentation ## Statements and conformity documents are not interchangeable For most products, PSTI relies on the section 9 statement of compliance and related summary and retention rules, but the current law also includes Schedule 2A cases where the section 9 accompaniment requirement is deemed to be met without that statement route. The CRA uses a different EU documentation and conformity structure. The practical result is that one evidence backbone can be shared, but the outward legal document set should remain jurisdiction-specific. This is especially important for support-period and post-market records. - Reuse product architecture, testing, and vulnerability evidence where valid - Draft UK and EU outward legal documents separately - Keep market-specific record-retention, deemed-compliance, and update workflows visible ## Use one engineering baseline with two legal wrappers The best pattern for dual-market products is one engineering baseline for passwords, vulnerability handling, updates, and release integrity, then a UK wrapper for PSTI and an EU wrapper for the CRA. This gives efficiency without masking legal differences. It also lets the business answer UK and EU regulator questions without contradictory paperwork. - Create one shared engineering evidence layer - Maintain separate UK and EU legal mappings and release outputs - Review support commitments for both markets before launch *Recommended next step* *Placement: after the comparison section* ## Use UK PSTI vs EU Cyber Resilience Act as a cited research workflow Research Copilot can take UK PSTI vs EU Cyber Resilience Act from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on UK PSTI can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK PSTI vs EU Cyber Resilience Act](/solutions/research-copilot.md): Start from UK PSTI vs EU Cyber Resilience Act and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK PSTI](/contact.md): Review your current process, evidence gaps, and next steps for UK PSTI vs EU Cyber Resilience Act. ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [Regulation (EU) 2024/2847 Cyber Resilience Act](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng) - Primary EU source used only for high level comparison with the UK PSTI regime. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act --- --- title: "UK PSTI Relevant Connectable Products Scope" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/relevant-connectable-products-scope" source_url: "https://www.sorena.io/artifacts/uk/psti-act/relevant-connectable-products-scope" author: "Sorena AI" description: "Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products." keywords: - "relevant connectable product scope" - "internet connectable product PSTI" - "network connectable product PSTI" - "PSTI exclusions" - "relevant connectable products" - "internet connectable product" - "network connectable product" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Relevant Connectable Products Scope Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. *Scope Guide* *Product Definition* ## Relevant Connectable Products Scope The UK PSTI regime is narrow in some places and wider than expected in others. The product definition captures direct and indirect connectivity paths, while the wider security obligation can still reach the surrounding software and services. A relevant connectable product is not only a device with a direct internet connection. The Act also covers some network-connectable products that connect through other products. At the same time, exclusion analysis still matters, and the duty map must reflect the actual UK consumer channel. ## Understand the two connectability routes Section 4 says condition A is met if the product is internet-connectable or network-connectable. Section 5 then defines those terms in more detail. That is why a gateway-dependent device can still be in scope even if it is not directly internet-capable on its own. This matters for smart home and accessory ecosystems where the security risk sits in the combined product experience. - Direct internet connection can be enough on its own - Indirect connection through another product can also bring the product into scope - Document the actual communication path used in the marketed product setup ## Bring in the associated software and service layer The Act makes clear that software and services connected to the operation or use of the product can sit inside the security requirement picture. That means a clean hardware-only analysis is often incomplete. App accounts, update services, cloud control panels, and vulnerability intake pages all affect compliance. - Include companion apps and account services in the control map - Include cloud update and support mechanisms in the evidence file - Keep the service inventory aligned to the physical product inventory ## Use exclusions carefully and keep them evidenced Exclusion questions should be answered from the regulations, not from sales intuition. The current Schedule 3 list covers certain Northern Ireland products, EV smart charge points, medical devices, certain smart meter products, certain computers, and, since 25 February 2025, specified Great Britain motor vehicles, two- or three-wheel vehicles and quadricycles, and agricultural and forestry vehicles. Where a boundary is genuinely difficult, record the reasoning and keep a review trigger rather than leaving the decision informal. This is especially important where one component is incorporated into a wider product or sold through multiple channels. - Retain the exclusion rationale in the scope file, including the exact Schedule 3 category used if any - Review the result after product bundling or channel changes - Keep the evidence with packaging, user instructions, and product architecture notes *Recommended next step* *Placement: after the scope or definition section* ## Use Relevant Connectable Products Scope as a cited research workflow Research Copilot can take Relevant Connectable Products Scope from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on Relevant Connectable can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Relevant Connectable Products Scope](/solutions/research-copilot.md): Start from Relevant Connectable Products Scope and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Relevant Connectable](/contact.md): Review your current process, evidence gaps, and next steps for Relevant Connectable Products Scope. ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/relevant-connectable-products-scope --- --- title: "UK PSTI Relevant Connectable Products Scope" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/relevant-connectable-products-scope" source_url: "https://www.sorena.io/artifacts/uk/psti-act/relevant-connectable-products-scope" author: "Sorena AI" description: "Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products." keywords: - "relevant connectable product scope" - "internet connectable product PSTI" - "network connectable product PSTI" - "PSTI exclusions" - "relevant connectable products" - "internet connectable product" - "network connectable product" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Relevant Connectable Products Scope Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. *Scope Guide* *Product Definition* ## Relevant Connectable Products Scope The UK PSTI regime is narrow in some places and wider than expected in others. The product definition captures direct and indirect connectivity paths, while the wider security obligation can still reach the surrounding software and services. A relevant connectable product is not only a device with a direct internet connection. The Act also covers some network-connectable products that connect through other products. At the same time, exclusion analysis still matters, and the duty map must reflect the actual UK consumer channel. ## Understand the two connectability routes Section 4 says condition A is met if the product is internet-connectable or network-connectable. Section 5 then defines those terms in more detail. That is why a gateway-dependent device can still be in scope even if it is not directly internet-capable on its own. This matters for smart home and accessory ecosystems where the security risk sits in the combined product experience. - Direct internet connection can be enough on its own - Indirect connection through another product can also bring the product into scope - Document the actual communication path used in the marketed product setup ## Bring in the associated software and service layer The Act makes clear that software and services connected to the operation or use of the product can sit inside the security requirement picture. That means a clean hardware-only analysis is often incomplete. App accounts, update services, cloud control panels, and vulnerability intake pages all affect compliance. - Include companion apps and account services in the control map - Include cloud update and support mechanisms in the evidence file - Keep the service inventory aligned to the physical product inventory ## Use exclusions carefully and keep them evidenced Exclusion questions should be answered from the regulations, not from sales intuition. The current Schedule 3 list covers certain Northern Ireland products, EV smart charge points, medical devices, certain smart meter products, certain computers, and, since 25 February 2025, specified Great Britain motor vehicles, two- or three-wheel vehicles and quadricycles, and agricultural and forestry vehicles. Where a boundary is genuinely difficult, record the reasoning and keep a review trigger rather than leaving the decision informal. This is especially important where one component is incorporated into a wider product or sold through multiple channels. - Retain the exclusion rationale in the scope file, including the exact Schedule 3 category used if any - Review the result after product bundling or channel changes - Keep the evidence with packaging, user instructions, and product architecture notes *Recommended next step* *Placement: after the scope or definition section* ## Use Relevant Connectable Products Scope as a cited research workflow Research Copilot can take Relevant Connectable Products Scope from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on Relevant Connectable can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Relevant Connectable Products Scope](/solutions/research-copilot.md): Start from Relevant Connectable Products Scope and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Relevant Connectable](/contact.md): Review your current process, evidence gaps, and next steps for Relevant Connectable Products Scope. ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/relevant-connectable-products-scope --- --- title: "UK PSTI Act Requirements" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/requirements" source_url: "https://www.sorena.io/artifacts/uk/psti-act/requirements" author: "Sorena AI" description: "Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies." keywords: - "UK PSTI requirements" - "statement of compliance requirements" - "minimum security update period" - "vulnerability disclosure information" - "no universal default passwords" - "PSTI requirements" - "security requirements" - "statement of compliance" - "product security controls" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Act Requirements Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. *Requirements Guide* *Controls and Evidence* ## UK PSTI Act Requirements The legal regime is short on the headline requirements and broader on the role and record obligations around them. A complete requirements map should therefore include both the three mandatory security duties and the surrounding statement or deemed-compliance, retention, investigation, and notification duties. The PSTI regime works in layers. The first layer is the three mandatory security requirements in Schedule 1 to the regulations. The second layer is the section 9 statement route for most products, alongside the current deemed-compliance routes in Schedules 2 and 2A. The third layer is the importer and distributor duty set, including what happens when a compliance failure is identified after products enter the UK market. ## Start with the three mandatory requirements The regulations specify three mandatory requirements for manufacturers of relevant connectable products. They are the practical core of the regime and should be built into release gates, customer communications, and support operations. Teams should not dilute them by mixing them with every recommended ETSI control. - No universal default passwords - Public vulnerability reporting information - Published minimum security update period information *Recommended next step* *Placement: after the requirement breakdown* ## Turn UK PSTI Act Requirements into an operational assessment Assessment Autopilot can take UK PSTI Act Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on UK PSTI Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK PSTI Act Requirements](/solutions/assessment.md): Start from UK PSTI Act Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK PSTI Act](/contact.md): Review your current process, evidence gaps, and next steps for UK PSTI Act Requirements. ## Then map the statement and retention duties For most products, section 9 of the Act requires the product to be accompanied by a statement of compliance or a summary when the statutory conditions apply. Since 4 December 2025, regulation 4A and Schedule 2A also create a deemed-compliance route for the section 9 requirement where the product carries a current JC-STAR STAR-1 or Singapore Cybersecurity Labelling Scheme label and the other specified conditions are met. The retention rule in regulations 8 and 9 runs for the longer of 10 years from issue and the defined support period, but only where a statement is required under section 9(2) or section 15(2). - Prepare the statement or compliant summary before UK availability unless a Schedule 2A route applies - Check whether importer or distributor gatekeeping is driven by section 15(2) and 22(2) or by section 15(5) and 22(3) - Include the minimum information set from the regulations - Retain statements for the longer of 10 years and the defined support period where the statement route applies ## Finish with post-market and supply-chain duties The Act does not stop at launch. Manufacturers, importers, and distributors each have duties when they become aware of compliance failures. That includes investigation, contact with the manufacturer where required, notification steps, and recordkeeping. A product security program that only covers pre-launch testing is therefore incomplete. - Maintain compliance-failure investigation records - Define importer and distributor escalation to the manufacturer - Stop UK supply where the duty holder concludes the failure is unlikely to be remedied in time ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [OPSS enforcement policy](https://www.gov.uk/government/publications/safety-and-standards-enforcement-enforcement-policy/opss-enforcement-policy?ref=sorena.io) - Risk-based, proportionate, transparent, and escalating enforcement approach used by OPSS. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/requirements --- --- title: "UK PSTI Act Requirements" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/requirements" source_url: "https://www.sorena.io/artifacts/uk/psti-act/requirements" author: "Sorena AI" description: "Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies." keywords: - "UK PSTI requirements" - "statement of compliance requirements" - "minimum security update period" - "vulnerability disclosure information" - "no universal default passwords" - "PSTI requirements" - "security requirements" - "statement of compliance" - "product security controls" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Act Requirements Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. *Requirements Guide* *Controls and Evidence* ## UK PSTI Act Requirements The legal regime is short on the headline requirements and broader on the role and record obligations around them. A complete requirements map should therefore include both the three mandatory security duties and the surrounding statement or deemed-compliance, retention, investigation, and notification duties. The PSTI regime works in layers. The first layer is the three mandatory security requirements in Schedule 1 to the regulations. The second layer is the section 9 statement route for most products, alongside the current deemed-compliance routes in Schedules 2 and 2A. The third layer is the importer and distributor duty set, including what happens when a compliance failure is identified after products enter the UK market. ## Start with the three mandatory requirements The regulations specify three mandatory requirements for manufacturers of relevant connectable products. They are the practical core of the regime and should be built into release gates, customer communications, and support operations. Teams should not dilute them by mixing them with every recommended ETSI control. - No universal default passwords - Public vulnerability reporting information - Published minimum security update period information *Recommended next step* *Placement: after the requirement breakdown* ## Turn UK PSTI Act Requirements into an operational assessment Assessment Autopilot can take UK PSTI Act Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on UK PSTI Act can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK PSTI Act Requirements](/solutions/assessment.md): Start from UK PSTI Act Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK PSTI Act](/contact.md): Review your current process, evidence gaps, and next steps for UK PSTI Act Requirements. ## Then map the statement and retention duties For most products, section 9 of the Act requires the product to be accompanied by a statement of compliance or a summary when the statutory conditions apply. Since 4 December 2025, regulation 4A and Schedule 2A also create a deemed-compliance route for the section 9 requirement where the product carries a current JC-STAR STAR-1 or Singapore Cybersecurity Labelling Scheme label and the other specified conditions are met. The retention rule in regulations 8 and 9 runs for the longer of 10 years from issue and the defined support period, but only where a statement is required under section 9(2) or section 15(2). - Prepare the statement or compliant summary before UK availability unless a Schedule 2A route applies - Check whether importer or distributor gatekeeping is driven by section 15(2) and 22(2) or by section 15(5) and 22(3) - Include the minimum information set from the regulations - Retain statements for the longer of 10 years and the defined support period where the statement route applies ## Finish with post-market and supply-chain duties The Act does not stop at launch. Manufacturers, importers, and distributors each have duties when they become aware of compliance failures. That includes investigation, contact with the manufacturer where required, notification steps, and recordkeeping. A product security program that only covers pre-launch testing is therefore incomplete. - Maintain compliance-failure investigation records - Define importer and distributor escalation to the manufacturer - Stop UK supply where the duty holder concludes the failure is unlikely to be remedied in time ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [OPSS enforcement policy](https://www.gov.uk/government/publications/safety-and-standards-enforcement-enforcement-policy/opss-enforcement-policy?ref=sorena.io) - Risk-based, proportionate, transparent, and escalating enforcement approach used by OPSS. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/requirements --- --- title: "UK PSTI Security Requirements in Practice" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/security-requirements-in-practice" source_url: "https://www.sorena.io/artifacts/uk/psti-act/security-requirements-in-practice" author: "Sorena AI" description: "Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling." keywords: - "UK PSTI security requirements in practice" - "engineering PSTI controls" - "vulnerability intake PSTI" - "support period implementation" - "security requirements in practice" - "engineering controls" - "vulnerability handling" - "support period" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Security Requirements in Practice Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. *Implementation Guide* *Engineering and Support* ## Security Requirements in Practice A compliant product line needs engineering execution, not just a statement draft. The control set should be visible in design reviews, release gates, support tooling, and post-market issue handling. The practical PSTI question is how to make three short statutory requirements work inside a complex product organization. The answer is to connect them to engineering ownership, support workflows, and product lifecycle controls rather than leaving them in policy space. ## Build the controls into product development Password design, disclosure endpoints, and support-period publication should be part of product definition and release readiness, not an afterthought before shipment. This avoids late-stage statement defects and missed Schedule 1 details such as password-generation restrictions or missing disclosure timelines. The same product review should also capture associated app and service dependencies. - Review password architecture against the unique-per-product or user-defined rule during product design - Create a vulnerability intake owner and monitored routing path with published acknowledgement and status-update timings - Approve support-period commitments before launch materials are finalised ## Run post-market security as an evidence-producing process ETSI materials emphasise continual monitoring, identifying, and rectifying vulnerabilities during the defined support period. While that broader discipline is not the exact legal wording of the UK regulation, it is the practical path to staying inside the published commitments and the minimum support period you have disclosed. Teams should therefore treat update and disclosure handling as a live operational process, with evidence of what was published, when it changed, and how issues were handled. - Track vulnerability intake, triage, fix, release, and customer communication - Review whether updates are being deployed with appropriate speed for the issue severity - Keep version, build, and notice records that show what was fixed when ## Use ETSI evidence carefully, not mechanically The UK regulations do still reference ETSI EN 303 645 V2.1.1 for one deemed-compliance route. But the current law also includes an ISO/IEC 29147 route for vulnerability disclosure and, since 4 December 2025, JC-STAR STAR-1 and Singapore Cybersecurity Labelling Scheme label routes in Schedules 2 and 2A. The latest ETSI publication is now V3.1.3, and ETSI TS 103 701 gives a conformance-assessment route. All of that can help evidence quality, but it does not replace reading the actual UK legal obligations for the product and route to market. Use the standard to strengthen assurance, not to obscure the three legal duties. - Document where ETSI or other route-specific evidence supports the legal requirement - Avoid claiming that ETSI is the only deemed-compliance route or that every ETSI provision is legally mandatory under PSTI - Keep the legal duty map and the standard-assurance map side by side *Recommended next step* *Placement: after the requirement breakdown* ## Turn Security Requirements in Practice into an operational assessment Assessment Autopilot can take Security Requirements in Practice from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on Security Requirements can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Security Requirements in Practice](/solutions/assessment.md): Start from Security Requirements in Practice and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Security Requirements](/contact.md): Review your current process, evidence gaps, and next steps for Security Requirements in Practice. ## Primary sources - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [ETSI EN 303 645 V2.1.1 reference used in the regulations](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - One deemed-compliance standard named by the UK regulations; the current law also includes other deemed-compliance routes. - [ETSI EN 303 645 V3.1.3 publication record](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf?ref=sorena.io) - Latest ETSI consumer IoT baseline requirements standard. The UK regulations still reference V2.1.1 for one deemed-compliance route. - [ETSI TS 103 701 conformance assessment](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/01.01.01_60/ts_103701v010101p.pdf?ref=sorena.io) - Conformance assessment specification used to test and evidence EN 303 645 style requirements. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/security-requirements-in-practice --- --- title: "UK PSTI Security Requirements in Practice" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/security-requirements-in-practice" source_url: "https://www.sorena.io/artifacts/uk/psti-act/security-requirements-in-practice" author: "Sorena AI" description: "Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling." keywords: - "UK PSTI security requirements in practice" - "engineering PSTI controls" - "vulnerability intake PSTI" - "support period implementation" - "security requirements in practice" - "engineering controls" - "vulnerability handling" - "support period" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Security Requirements in Practice Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. *Implementation Guide* *Engineering and Support* ## Security Requirements in Practice A compliant product line needs engineering execution, not just a statement draft. The control set should be visible in design reviews, release gates, support tooling, and post-market issue handling. The practical PSTI question is how to make three short statutory requirements work inside a complex product organization. The answer is to connect them to engineering ownership, support workflows, and product lifecycle controls rather than leaving them in policy space. ## Build the controls into product development Password design, disclosure endpoints, and support-period publication should be part of product definition and release readiness, not an afterthought before shipment. This avoids late-stage statement defects and missed Schedule 1 details such as password-generation restrictions or missing disclosure timelines. The same product review should also capture associated app and service dependencies. - Review password architecture against the unique-per-product or user-defined rule during product design - Create a vulnerability intake owner and monitored routing path with published acknowledgement and status-update timings - Approve support-period commitments before launch materials are finalised ## Run post-market security as an evidence-producing process ETSI materials emphasise continual monitoring, identifying, and rectifying vulnerabilities during the defined support period. While that broader discipline is not the exact legal wording of the UK regulation, it is the practical path to staying inside the published commitments and the minimum support period you have disclosed. Teams should therefore treat update and disclosure handling as a live operational process, with evidence of what was published, when it changed, and how issues were handled. - Track vulnerability intake, triage, fix, release, and customer communication - Review whether updates are being deployed with appropriate speed for the issue severity - Keep version, build, and notice records that show what was fixed when ## Use ETSI evidence carefully, not mechanically The UK regulations do still reference ETSI EN 303 645 V2.1.1 for one deemed-compliance route. But the current law also includes an ISO/IEC 29147 route for vulnerability disclosure and, since 4 December 2025, JC-STAR STAR-1 and Singapore Cybersecurity Labelling Scheme label routes in Schedules 2 and 2A. The latest ETSI publication is now V3.1.3, and ETSI TS 103 701 gives a conformance-assessment route. All of that can help evidence quality, but it does not replace reading the actual UK legal obligations for the product and route to market. Use the standard to strengthen assurance, not to obscure the three legal duties. - Document where ETSI or other route-specific evidence supports the legal requirement - Avoid claiming that ETSI is the only deemed-compliance route or that every ETSI provision is legally mandatory under PSTI - Keep the legal duty map and the standard-assurance map side by side *Recommended next step* *Placement: after the requirement breakdown* ## Turn Security Requirements in Practice into an operational assessment Assessment Autopilot can take Security Requirements in Practice from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on Security Requirements can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for Security Requirements in Practice](/solutions/assessment.md): Start from Security Requirements in Practice and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through Security Requirements](/contact.md): Review your current process, evidence gaps, and next steps for Security Requirements in Practice. ## Primary sources - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. - [ETSI EN 303 645 V2.1.1 reference used in the regulations](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - One deemed-compliance standard named by the UK regulations; the current law also includes other deemed-compliance routes. - [ETSI EN 303 645 V3.1.3 publication record](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf?ref=sorena.io) - Latest ETSI consumer IoT baseline requirements standard. The UK regulations still reference V2.1.1 for one deemed-compliance route. - [ETSI TS 103 701 conformance assessment](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/01.01.01_60/ts_103701v010101p.pdf?ref=sorena.io) - Conformance assessment specification used to test and evidence EN 303 645 style requirements. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/security-requirements-in-practice --- --- title: "UK PSTI Statement of Compliance and Evidence" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/statement-of-compliance-and-evidence" source_url: "https://www.sorena.io/artifacts/uk/psti-act/statement-of-compliance-and-evidence" author: "Sorena AI" description: "Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies." keywords: - "UK PSTI statement of compliance" - "statement of compliance evidence" - "10 year retention PSTI" - "defined support period retention" - "statement of compliance" - "statement evidence" - "retention" - "PSTI documentation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Statement of Compliance and Evidence Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. *Documentation Guide* *Statement and Evidence* ## Statement of Compliance and Evidence For products using the statement route, the statement is not a marketing summary. It is the formal compliance document that supports UK availability. The surrounding evidence file matters just as much because the statement expresses the manufacturer's opinion that the applicable security requirements have been met. For most products, section 9 says the manufacturer may not make a relevant connectable product available in the United Kingdom unless it is accompanied by a statement of compliance or a compliant summary. Since 4 December 2025, regulation 4A and Schedule 2A also provide a deemed-compliance route for that requirement in some labeled-product cases. Where the statement route is used, the regulations specify the minimum statement content and the retention periods for manufacturers and importers. ## Design the statement as a product-level compliance assertion The statement should be tied to a clearly identified product family or model set and to the specific applicable security requirements. It should not be a generic brand declaration detached from the actual product version and support commitment. Schedule 4 requires enough detail to identify the product and the responsible business: product type and batch or serial number, manufacturer name and address, any authorised representative name and address, the manufacturer's compliance declaration, the defined support period that was correct when the manufacturer first supplied the product, and the signatory and issue details. That is what makes later evidence retrieval possible. - Use product type and batch or serial identifiers that match the release record - Include manufacturer details and any authorised representative details - Retain signatory, issue-date, and approval history context *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep Statement of Compliance and Evidence in one governed evidence system SSOT can take Statement of Compliance and Evidence from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on Statement of Compliance can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for Statement of Compliance and Evidence](/solutions/ssot.md): Start from Statement of Compliance and Evidence and keep documents, evidence, and control records in one governed system. - [Talk through Statement of Compliance](/contact.md): Review your current process, evidence gaps, and next steps for Statement of Compliance and Evidence. ## Keep the supporting evidence file with the statement The Act lets regulations require a manufacturer to take specified steps to determine whether it has complied before preparing the statement. That means the evidence pack should show how the conclusion was reached, not only the final declaration. In practice that includes password design evidence, vulnerability disclosure publication proof, support-period publication proof, relevant testing or assurance records, and, where a Schedule 2 or 2A deemed-compliance route is being used, evidence that the route-specific conditions were met. - Store control design records, test outputs, and any label or route-specific evidence with the statement file - Retain publication evidence for disclosure information and support period information - Keep release and remediation records that confirm the product matches the stated position ## Follow the retention rule exactly The regulations say the manufacturer and importer each retain a copy of the statement for the longer of 10 years from issue and the defined support period, but only where a statement is required under section 9(2) or section 15(2). This is easy to miss when support periods extend beyond typical document retention defaults. If the product is using the Schedule 2A deemed-compliance route instead of the statement route, do not assume the statement-retention regulations apply. Retention design should therefore start with the actual legal route the product is using. - Calculate retention from both the issue date and the support period where a statement is required - Apply the longer period rather than the default policy period - Keep importer retention aligned with manufacturer document changes when section 15(2) applies ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/statement-of-compliance-and-evidence --- --- title: "UK PSTI Statement of Compliance and Evidence" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/statement-of-compliance-and-evidence" source_url: "https://www.sorena.io/artifacts/uk/psti-act/statement-of-compliance-and-evidence" author: "Sorena AI" description: "Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies." keywords: - "UK PSTI statement of compliance" - "statement of compliance evidence" - "10 year retention PSTI" - "defined support period retention" - "statement of compliance" - "statement evidence" - "retention" - "PSTI documentation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Statement of Compliance and Evidence Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. *Documentation Guide* *Statement and Evidence* ## Statement of Compliance and Evidence For products using the statement route, the statement is not a marketing summary. It is the formal compliance document that supports UK availability. The surrounding evidence file matters just as much because the statement expresses the manufacturer's opinion that the applicable security requirements have been met. For most products, section 9 says the manufacturer may not make a relevant connectable product available in the United Kingdom unless it is accompanied by a statement of compliance or a compliant summary. Since 4 December 2025, regulation 4A and Schedule 2A also provide a deemed-compliance route for that requirement in some labeled-product cases. Where the statement route is used, the regulations specify the minimum statement content and the retention periods for manufacturers and importers. ## Design the statement as a product-level compliance assertion The statement should be tied to a clearly identified product family or model set and to the specific applicable security requirements. It should not be a generic brand declaration detached from the actual product version and support commitment. Schedule 4 requires enough detail to identify the product and the responsible business: product type and batch or serial number, manufacturer name and address, any authorised representative name and address, the manufacturer's compliance declaration, the defined support period that was correct when the manufacturer first supplied the product, and the signatory and issue details. That is what makes later evidence retrieval possible. - Use product type and batch or serial identifiers that match the release record - Include manufacturer details and any authorised representative details - Retain signatory, issue-date, and approval history context *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep Statement of Compliance and Evidence in one governed evidence system SSOT can take Statement of Compliance and Evidence from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on Statement of Compliance can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for Statement of Compliance and Evidence](/solutions/ssot.md): Start from Statement of Compliance and Evidence and keep documents, evidence, and control records in one governed system. - [Talk through Statement of Compliance](/contact.md): Review your current process, evidence gaps, and next steps for Statement of Compliance and Evidence. ## Keep the supporting evidence file with the statement The Act lets regulations require a manufacturer to take specified steps to determine whether it has complied before preparing the statement. That means the evidence pack should show how the conclusion was reached, not only the final declaration. In practice that includes password design evidence, vulnerability disclosure publication proof, support-period publication proof, relevant testing or assurance records, and, where a Schedule 2 or 2A deemed-compliance route is being used, evidence that the route-specific conditions were met. - Store control design records, test outputs, and any label or route-specific evidence with the statement file - Retain publication evidence for disclosure information and support period information - Keep release and remediation records that confirm the product matches the stated position ## Follow the retention rule exactly The regulations say the manufacturer and importer each retain a copy of the statement for the longer of 10 years from issue and the defined support period, but only where a statement is required under section 9(2) or section 15(2). This is easy to miss when support periods extend beyond typical document retention defaults. If the product is using the Schedule 2A deemed-compliance route instead of the statement route, do not assume the statement-retention regulations apply. Retention design should therefore start with the actual legal route the product is using. - Calculate retention from both the issue date and the support period where a statement is required - Apply the longer period rather than the default policy period - Keep importer retention aligned with manufacturer document changes when section 15(2) applies ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI Supply Chain Roles | Manufacturer, Importer, and Distributor Duties](/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor.md): Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/statement-of-compliance-and-evidence --- --- title: "UK PSTI Supply Chain Roles" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor" source_url: "https://www.sorena.io/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor" author: "Sorena AI" description: "Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation." keywords: - "UK PSTI manufacturer duties" - "UK PSTI importer duties" - "UK PSTI distributor duties" - "compliance failure PSTI" - "manufacturer duties" - "importer duties" - "distributor duties" - "supply chain roles" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Supply Chain Roles Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. *Role Guide* *Supply Chain Duties* ## Manufacturer Importer Distributor Roles Role mapping is where many PSTI programs become inaccurate. The regime imposes related but distinct duties on manufacturers, importers, and distributors, especially after a compliance failure appears. The Act defines relevant persons to include manufacturers, importers, and distributors. Each role has its own entry duties, statement or deemed-compliance handling expectations, and post-market compliance-failure duties. Those duties should be reflected in contracts, playbooks, and incident response paths. ## Manufacturers carry the main product and statement burden Manufacturers must comply with the relevant security requirements where the Act says the duty is engaged. They also control the statement-of-compliance position or, where applicable, the newer Schedule 2A deemed-compliance position for the UK market. That means the manufacturer needs the strongest engineering and evidence link to the product itself. - Own the three mandatory security requirements - Prepare the statement or compliant summary path, or maintain the Schedule 2A evidence route where applicable - Maintain the product evidence file and support-period source of truth ## Importers and distributors have their own gatekeeping duties Importers and distributors are not passive logistics roles under PSTI. For most products they must not make products available in the UK unless the statement or summary conditions are met, but sections 15(5) and 22(3) switch the check to satisfaction of the specified deemed-compliance conditions where a section 9(7) route applies. They also have action duties when compliance failures surface. These checks should sit in onboarding, sourcing, and release-to-channel controls. - Verify statement availability or satisfaction of the applicable deemed-compliance conditions before UK placement - Escalate suspected compliance failures quickly - Stop supply where the law requires all reasonable steps to prevent further availability ## Post-market compliance-failure handling is shared and time-sensitive The Act sets out contact, notification, and recordkeeping duties when manufacturers, importers, or distributors become aware of compliance failures. These provisions are important because many real cases begin after launch rather than before it. The supply-chain response should therefore be pre-agreed before a failure occurs. - Create one compliance-failure contact tree across the UK supply chain - Record what was known, by whom, and what remedial steps were taken - Keep distributor and importer notification templates ready for use *Recommended next step* *Placement: after the scope or definition section* ## Use Manufacturer Importer Distributor Roles as a cited research workflow Research Copilot can take Manufacturer Importer Distributor Roles from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on Manufacturer Importer can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Manufacturer Importer Distributor Roles](/solutions/research-copilot.md): Start from Manufacturer Importer Distributor Roles and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Manufacturer Importer](/contact.md): Review your current process, evidence gaps, and next steps for Manufacturer Importer Distributor Roles. ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor --- --- title: "UK PSTI Supply Chain Roles" canonical_url: "https://www.sorena.io/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor" source_url: "https://www.sorena.io/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor" author: "Sorena AI" description: "Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation." keywords: - "UK PSTI manufacturer duties" - "UK PSTI importer duties" - "UK PSTI distributor duties" - "compliance failure PSTI" - "manufacturer duties" - "importer duties" - "distributor duties" - "supply chain roles" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK PSTI Supply Chain Roles Grounded guide to UK PSTI supply-chain roles covering manufacturer, importer, and distributor duties, statement handling, compliance-failure escalation. *Role Guide* *Supply Chain Duties* ## Manufacturer Importer Distributor Roles Role mapping is where many PSTI programs become inaccurate. The regime imposes related but distinct duties on manufacturers, importers, and distributors, especially after a compliance failure appears. The Act defines relevant persons to include manufacturers, importers, and distributors. Each role has its own entry duties, statement or deemed-compliance handling expectations, and post-market compliance-failure duties. Those duties should be reflected in contracts, playbooks, and incident response paths. ## Manufacturers carry the main product and statement burden Manufacturers must comply with the relevant security requirements where the Act says the duty is engaged. They also control the statement-of-compliance position or, where applicable, the newer Schedule 2A deemed-compliance position for the UK market. That means the manufacturer needs the strongest engineering and evidence link to the product itself. - Own the three mandatory security requirements - Prepare the statement or compliant summary path, or maintain the Schedule 2A evidence route where applicable - Maintain the product evidence file and support-period source of truth ## Importers and distributors have their own gatekeeping duties Importers and distributors are not passive logistics roles under PSTI. For most products they must not make products available in the UK unless the statement or summary conditions are met, but sections 15(5) and 22(3) switch the check to satisfaction of the specified deemed-compliance conditions where a section 9(7) route applies. They also have action duties when compliance failures surface. These checks should sit in onboarding, sourcing, and release-to-channel controls. - Verify statement availability or satisfaction of the applicable deemed-compliance conditions before UK placement - Escalate suspected compliance failures quickly - Stop supply where the law requires all reasonable steps to prevent further availability ## Post-market compliance-failure handling is shared and time-sensitive The Act sets out contact, notification, and recordkeeping duties when manufacturers, importers, or distributors become aware of compliance failures. These provisions are important because many real cases begin after launch rather than before it. The supply-chain response should therefore be pre-agreed before a failure occurs. - Create one compliance-failure contact tree across the UK supply chain - Record what was known, by whom, and what remedial steps were taken - Keep distributor and importer notification templates ready for use *Recommended next step* *Placement: after the scope or definition section* ## Use Manufacturer Importer Distributor Roles as a cited research workflow Research Copilot can take Manufacturer Importer Distributor Roles from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on Manufacturer Importer can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for Manufacturer Importer Distributor Roles](/solutions/research-copilot.md): Start from Manufacturer Importer Distributor Roles and answer scope, timing, and interpretation questions with cited outputs. - [Talk through Manufacturer Importer](/contact.md): Review your current process, evidence gaps, and next steps for Manufacturer Importer Distributor Roles. ## Primary sources - [Product Security and Telecommunications Infrastructure Act 2022](https://www.legislation.gov.uk/ukpga/2022/46/contents?ref=sorena.io) - Primary legislation for relevant connectable products, role duties, statements of compliance, compliance failures, and enforcement powers. - [PSTI Security Requirements for Relevant Connectable Products Regulations 2023](https://www.legislation.gov.uk/uksi/2023/1007/contents?ref=sorena.io) - Regulations that specify the three mandatory security requirements, current deemed-compliance routes, excepted products, statement-of-compliance details, and retention periods. ## Related Topic Guides - [UK PSTI Act Applicability Test | Relevant Connectable Product Scope and Exclusions](/artifacts/uk/psti-act/applicability-test.md): Grounded UK PSTI applicability test covering section 4 relevant connectable product logic, internet-connectable and network-connectable products. - [UK PSTI Act Checklist | Scope, Statements, Security Controls, and Records](/artifacts/uk/psti-act/checklist.md): Audit-ready UK PSTI checklist covering product scope, role allocation, the three mandatory security requirements, statement of compliance handling, retention. - [UK PSTI Act Compliance Program | Product Security Governance and OPSS Readiness](/artifacts/uk/psti-act/compliance.md): Program design guide for UK PSTI compliance covering product scope, engineering controls, statement governance, supply-chain checks. - [UK PSTI Act Deadlines and Compliance Calendar | Royal Assent, Commencement, and Review Dates](/artifacts/uk/psti-act/deadlines-and-compliance-calendar.md): Grounded UK PSTI calendar covering 6 December 2022 Royal Assent, 29 April 2024 commencement, and the 2025 amendments now in force. - [UK PSTI Act FAQ | Scope, Statements, Support Periods, and OPSS Questions](/artifacts/uk/psti-act/faq.md): Practical FAQ on the UK PSTI regime covering product scope, the three mandatory requirements, statement of compliance issues, role duties, retention. - [UK PSTI Act Requirements | Mandatory Security Duties, Statements, and Records](/artifacts/uk/psti-act/requirements.md): Detailed UK PSTI requirements guide covering the three mandatory security requirements, statement and deemed-compliance rules, and retention periods where the statement route applies. - [UK PSTI OPSS Enforcement and Penalties | Risk Based Intervention and Escalation](/artifacts/uk/psti-act/opss-enforcement-and-penalties.md): Grounded OPSS enforcement guide for the UK PSTI regime covering risk-based and proportionate intervention, escalating enforcement, evidence expectations. - [UK PSTI Password and Update Policy Requirements | Default Passwords, Disclosure, and Support Period](/artifacts/uk/psti-act/psti-password-and-update-policy-requirements.md): Grounded guide to UK PSTI password and update obligations covering unique or user-defined credentials, public vulnerability disclosure information. - [UK PSTI Penalties and Fines | Financial and Operational Exposure](/artifacts/uk/psti-act/penalties-and-fines.md): Practical guide to UK PSTI penalties and enforcement exposure covering why statement defects, support-period mismatches. - [UK PSTI Relevant Connectable Products Scope | Internet Connectable, Network Connectable, and Exclusions](/artifacts/uk/psti-act/relevant-connectable-products-scope.md): Detailed scope guide for UK PSTI relevant connectable products covering section 4 and 5 definitions, internet-connectable products. - [UK PSTI Security Requirements in Practice | Engineering and Support Implementation](/artifacts/uk/psti-act/security-requirements-in-practice.md): Operational guide for implementing UK PSTI security requirements in practice across engineering, firmware, support, vulnerability handling. - [UK PSTI Statement of Compliance and Evidence | Statements, Summaries, and Retention](/artifacts/uk/psti-act/statement-of-compliance-and-evidence.md): Grounded guide to UK PSTI statement-of-compliance obligations covering section 9, Schedule 2A alternatives, minimum information, and retention where the statement route applies. - [UK PSTI Statement of Compliance Template | Drafting Pattern and Evidence Inputs](/artifacts/uk/psti-act/psti-statement-of-compliance-template.md): Practical UK PSTI statement of compliance template guide covering product identification, applicable requirements, defined support period, drafting controls. - [UK PSTI vs EU Cyber Resilience Act | Product Scope, Duties, and Evidence Differences](/artifacts/uk/psti-act/psti-vs-eu-cyber-resilience-act.md): Practical comparison of the UK PSTI regime and the EU Cyber Resilience Act covering product scope, baseline security duties, vulnerability handling. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/psti-act/supply-chain-roles-manufacturer-importer-distributor --- --- title: "UK GDPR Applicability Test" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/applicability-test" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/applicability-test" author: "Sorena AI" description: "Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test." keywords: - "UK GDPR applicability test" - "UK GDPR territorial scope" - "article 3 UK GDPR" - "controller processor UK" - "UK GDPR applicability" - "Article 3" - "Controller and processor" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Applicability Test Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. *Applicability* *UK GDPR* ## UK GDPR Applicability Test Decide if UK GDPR applies and which obligations trigger first. Use Article 3 scope tests, role mapping, and risk triggers to avoid shallow or overbroad scoping. A good UK GDPR scope memo shows why the law applies, which entity acts as controller or processor, and which high risk workflows need follow up work. ## Article 3 territorial scope UK GDPR has applied in the United Kingdom since January 1, 2021. Start with whether the processing is tied to a UK establishment, offering goods or services to people in the UK, or monitoring behaviour in the UK. - Map each processing activity to the relevant UK entity, product, vendor, and destination country - Record why the activity is linked to a UK establishment, UK targeting, or UK behaviour monitoring - Capture out of scope activities with the legal rationale - Version the scope record after product or vendor changes ## Role and risk analysis For each activity, decide whether the organisation is a controller, joint controller, or processor and note whether children, profiling, special category data, or transfers are involved. - Assign controller or processor status per activity and contract - Escalate joint controller cases where purpose and means are shared - Flag DPIA triggers for profiling, children, or sensitive data uses - Identify restricted transfers and any adequacy, IDTA, or Addendum need ## Minimum evidence pack An applicability decision is useful only if it can be defended later. Keep the output close to the processing inventory and vendor register. - Applicability memo linked to the Article 30 style inventory - Role matrix for controllers, processors, and key subprocessors - Risk trigger register for DPIA, breach, child privacy, and transfer work - Review schedule tied to launches and major supplier changes *Recommended next step* *Placement: after the applicability result* ## Turn UK GDPR Applicability Test into an operational assessment Assessment Autopilot can take UK GDPR Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK GDPR Applicability Test](/solutions/assessment.md): Start from UK GDPR Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Applicability Test. ## Primary sources - [ICO UK GDPR guidance and resources](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/?ref=sorena.io) - Primary ICO guidance hub. - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. - [ICO documentation guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/documentation/?ref=sorena.io) - Article 30 and supporting documentation guidance. - [UK GDPR on legislation.gov.uk](https://www.legislation.gov.uk/eur/2016/679/contents?ref=sorena.io) - UK legislative text. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/applicability-test --- --- title: "UK GDPR Applicability Test" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/applicability-test" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/applicability-test" author: "Sorena AI" description: "Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test." keywords: - "UK GDPR applicability test" - "UK GDPR territorial scope" - "article 3 UK GDPR" - "controller processor UK" - "UK GDPR applicability" - "Article 3" - "Controller and processor" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Applicability Test Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. *Applicability* *UK GDPR* ## UK GDPR Applicability Test Decide if UK GDPR applies and which obligations trigger first. Use Article 3 scope tests, role mapping, and risk triggers to avoid shallow or overbroad scoping. A good UK GDPR scope memo shows why the law applies, which entity acts as controller or processor, and which high risk workflows need follow up work. ## Article 3 territorial scope UK GDPR has applied in the United Kingdom since January 1, 2021. Start with whether the processing is tied to a UK establishment, offering goods or services to people in the UK, or monitoring behaviour in the UK. - Map each processing activity to the relevant UK entity, product, vendor, and destination country - Record why the activity is linked to a UK establishment, UK targeting, or UK behaviour monitoring - Capture out of scope activities with the legal rationale - Version the scope record after product or vendor changes ## Role and risk analysis For each activity, decide whether the organisation is a controller, joint controller, or processor and note whether children, profiling, special category data, or transfers are involved. - Assign controller or processor status per activity and contract - Escalate joint controller cases where purpose and means are shared - Flag DPIA triggers for profiling, children, or sensitive data uses - Identify restricted transfers and any adequacy, IDTA, or Addendum need ## Minimum evidence pack An applicability decision is useful only if it can be defended later. Keep the output close to the processing inventory and vendor register. - Applicability memo linked to the Article 30 style inventory - Role matrix for controllers, processors, and key subprocessors - Risk trigger register for DPIA, breach, child privacy, and transfer work - Review schedule tied to launches and major supplier changes *Recommended next step* *Placement: after the applicability result* ## Turn UK GDPR Applicability Test into an operational assessment Assessment Autopilot can take UK GDPR Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK GDPR Applicability Test](/solutions/assessment.md): Start from UK GDPR Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Applicability Test. ## Primary sources - [ICO UK GDPR guidance and resources](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/?ref=sorena.io) - Primary ICO guidance hub. - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. - [ICO documentation guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/documentation/?ref=sorena.io) - Article 30 and supporting documentation guidance. - [UK GDPR on legislation.gov.uk](https://www.legislation.gov.uk/eur/2016/679/contents?ref=sorena.io) - UK legislative text. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/applicability-test --- --- title: "UK GDPR Breach Notification" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/breach-notification" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/breach-notification" author: "Sorena AI" description: "Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging." keywords: - "UK GDPR breach notification" - "ICO 72 hours" - "article 33 UK GDPR" - "article 34 UK GDPR" - "UK GDPR breach" - "72 hour ICO reporting" - "Article 33 and 34" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Breach Notification Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. *Incident Response* *UK GDPR* ## UK GDPR Breach Notification Run a breach process that can decide fast, notify the ICO in time, and preserve evidence. Article 33 and 34 duties depend on risk analysis, not on whether the full story is known in the first few hours. The ICO expects a controller to know when it became aware of a breach, whether the breach is notifiable, and what facts were sent in the initial and follow up reports. ## When notification is required A controller must notify the ICO without undue delay and where feasible within 72 hours of becoming aware of a notifiable personal data breach. If more time is needed, the report must explain the delay. - Record the time of awareness and the facts available at that moment - Assess confidentiality, integrity, and availability impacts separately - Decide whether ICO notification is required and who signs off - Keep an internal breach record even when the ICO is not notified *Recommended next step* *Placement: after the workflow or playbook section* ## Turn UK GDPR Breach Notification into an operational assessment Assessment Autopilot can take UK GDPR Breach Notification from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK GDPR Breach Notification](/solutions/assessment.md): Start from UK GDPR Breach Notification and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Breach Notification. ## Processor and controller workflow A processor must tell the controller about a breach without undue delay after becoming aware of it. That duty should appear in contracts, on call playbooks, and escalation paths. - Set contract language for processor notice and evidence - Collect categories of data, affected people, systems, and likely consequences - Prepare an initial ICO filing and a follow up evidence pack - Track remediation, root cause, and lessons learned ## Communication to individuals Article 34 requires communication to affected individuals without undue delay when the breach is likely to result in a high risk to their rights and freedoms. - Use plain language and tailor advice to the actual harm scenario - Document if encryption or later measures remove the need for direct notification - Retain copies of notices, scripts, and regulator submissions - Review security, vendor, or training changes after the incident ## Primary sources - [ICO personal data breaches guide](https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breaches-a-guide/?ref=sorena.io) - Article 33 and 34 operational guidance. - [ICO guide to data security](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/?ref=sorena.io) - Article 32 and security principle guidance. - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. - [UK GDPR on legislation.gov.uk](https://www.legislation.gov.uk/eur/2016/679/contents?ref=sorena.io) - UK legislative text. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/breach-notification --- --- title: "UK GDPR Breach Notification" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/breach-notification" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/breach-notification" author: "Sorena AI" description: "Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging." keywords: - "UK GDPR breach notification" - "ICO 72 hours" - "article 33 UK GDPR" - "article 34 UK GDPR" - "UK GDPR breach" - "72 hour ICO reporting" - "Article 33 and 34" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Breach Notification Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. *Incident Response* *UK GDPR* ## UK GDPR Breach Notification Run a breach process that can decide fast, notify the ICO in time, and preserve evidence. Article 33 and 34 duties depend on risk analysis, not on whether the full story is known in the first few hours. The ICO expects a controller to know when it became aware of a breach, whether the breach is notifiable, and what facts were sent in the initial and follow up reports. ## When notification is required A controller must notify the ICO without undue delay and where feasible within 72 hours of becoming aware of a notifiable personal data breach. If more time is needed, the report must explain the delay. - Record the time of awareness and the facts available at that moment - Assess confidentiality, integrity, and availability impacts separately - Decide whether ICO notification is required and who signs off - Keep an internal breach record even when the ICO is not notified *Recommended next step* *Placement: after the workflow or playbook section* ## Turn UK GDPR Breach Notification into an operational assessment Assessment Autopilot can take UK GDPR Breach Notification from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK GDPR Breach Notification](/solutions/assessment.md): Start from UK GDPR Breach Notification and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Breach Notification. ## Processor and controller workflow A processor must tell the controller about a breach without undue delay after becoming aware of it. That duty should appear in contracts, on call playbooks, and escalation paths. - Set contract language for processor notice and evidence - Collect categories of data, affected people, systems, and likely consequences - Prepare an initial ICO filing and a follow up evidence pack - Track remediation, root cause, and lessons learned ## Communication to individuals Article 34 requires communication to affected individuals without undue delay when the breach is likely to result in a high risk to their rights and freedoms. - Use plain language and tailor advice to the actual harm scenario - Document if encryption or later measures remove the need for direct notification - Retain copies of notices, scripts, and regulator submissions - Review security, vendor, or training changes after the incident ## Primary sources - [ICO personal data breaches guide](https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breaches-a-guide/?ref=sorena.io) - Article 33 and 34 operational guidance. - [ICO guide to data security](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/?ref=sorena.io) - Article 32 and security principle guidance. - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. - [UK GDPR on legislation.gov.uk](https://www.legislation.gov.uk/eur/2016/679/contents?ref=sorena.io) - UK legislative text. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/breach-notification --- --- title: "UK GDPR Checklist" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/checklist" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/checklist" author: "Sorena AI" description: "Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness." keywords: - "UK GDPR checklist" - "UK GDPR compliance checklist" - "article 30 checklist" - "UK GDPR transfer checklist" - "Accountability" - "Article 30" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Checklist Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. *Checklist* *UK GDPR* ## UK GDPR Checklist Use a practical UK GDPR checklist that tracks legal duties and the evidence behind them. A good checklist ties each requirement to an owner, proof artifact, and review cadence. The fastest way to miss a UK GDPR issue is to keep separate lists for legal, product, security, and procurement. Use one checklist that joins them. ## Governance and documentation Start with accountability documents. The ICO expects records that show what you process, why you process it, who you share it with, how long you keep it, and who is responsible. - Record lawful basis and transparency decisions - Maintain Article 30 records for controller or processor activities - Keep controller processor contracts and joint controller arrangements current - Track DPIAs, legitimate interests assessments, and retention decisions ## Operational rights and security The checklist should test whether requests can be received, verified, answered within one month, and closed with evidence. It should also test whether Article 32 security matches actual risk. - Confirm request channels, verification steps, and one month response metrics - Retain denial rationales, extension notices, and exception logs - Review security measures, access control, vendor oversight, and recovery capability - Check breach logging and the 72 hour notification workflow ## Transfers, children, and change management High risk gaps often sit at the edges of the programme. Transfer tools, child facing services, and product changes should appear on the checklist as recurring review items. - Inventory restricted transfers and the legal tool used for each one - Retain IDTA or Addendum packs and TRAs - Assess whether the service is likely to be accessed by children - Run change review when products, vendors, retention periods, or data uses change *Recommended next step* *Placement: after the checklist block* ## Turn UK GDPR Checklist into an operational assessment Assessment Autopilot can take UK GDPR Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK GDPR Checklist](/solutions/assessment.md): Start from UK GDPR Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Checklist. ## Primary sources - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. - [ICO documentation guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/documentation/?ref=sorena.io) - Article 30 and supporting documentation guidance. - [ICO personal data breaches guide](https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breaches-a-guide/?ref=sorena.io) - Article 33 and 34 operational guidance. - [ICO international transfers guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/?ref=sorena.io) - Adequacy, IDTA, Addendum, and TRA guidance. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/checklist --- --- title: "UK GDPR Checklist" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/checklist" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/checklist" author: "Sorena AI" description: "Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness." keywords: - "UK GDPR checklist" - "UK GDPR compliance checklist" - "article 30 checklist" - "UK GDPR transfer checklist" - "Accountability" - "Article 30" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Checklist Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. *Checklist* *UK GDPR* ## UK GDPR Checklist Use a practical UK GDPR checklist that tracks legal duties and the evidence behind them. A good checklist ties each requirement to an owner, proof artifact, and review cadence. The fastest way to miss a UK GDPR issue is to keep separate lists for legal, product, security, and procurement. Use one checklist that joins them. ## Governance and documentation Start with accountability documents. The ICO expects records that show what you process, why you process it, who you share it with, how long you keep it, and who is responsible. - Record lawful basis and transparency decisions - Maintain Article 30 records for controller or processor activities - Keep controller processor contracts and joint controller arrangements current - Track DPIAs, legitimate interests assessments, and retention decisions ## Operational rights and security The checklist should test whether requests can be received, verified, answered within one month, and closed with evidence. It should also test whether Article 32 security matches actual risk. - Confirm request channels, verification steps, and one month response metrics - Retain denial rationales, extension notices, and exception logs - Review security measures, access control, vendor oversight, and recovery capability - Check breach logging and the 72 hour notification workflow ## Transfers, children, and change management High risk gaps often sit at the edges of the programme. Transfer tools, child facing services, and product changes should appear on the checklist as recurring review items. - Inventory restricted transfers and the legal tool used for each one - Retain IDTA or Addendum packs and TRAs - Assess whether the service is likely to be accessed by children - Run change review when products, vendors, retention periods, or data uses change *Recommended next step* *Placement: after the checklist block* ## Turn UK GDPR Checklist into an operational assessment Assessment Autopilot can take UK GDPR Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK GDPR Checklist](/solutions/assessment.md): Start from UK GDPR Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Checklist. ## Primary sources - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. - [ICO documentation guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/documentation/?ref=sorena.io) - Article 30 and supporting documentation guidance. - [ICO personal data breaches guide](https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breaches-a-guide/?ref=sorena.io) - Article 33 and 34 operational guidance. - [ICO international transfers guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/?ref=sorena.io) - Adequacy, IDTA, Addendum, and TRA guidance. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/checklist --- --- title: "UK GDPR Children and Age Appropriate Design" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/children-and-age-appropriate-design" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/children-and-age-appropriate-design" author: "Sorena AI" description: "Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance." keywords: - "UK GDPR children data" - "age appropriate design code" - "likely to be accessed by children" - "Children's Code compliance" - "Children's Code" - "Age Appropriate Design" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Children and Age Appropriate Design Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. *Children's Data* *UK GDPR* ## UK GDPR Children and Age Appropriate Design Design online services for children using the ICO child first standards. If a service is likely to be accessed by children, the Children's Code affects defaults, profiling, geolocation, sharing, and transparency. The Children's Code changes product settings, feature design, vendor choices, and testing practices for online services likely to be accessed by children. ## Likely to be accessed analysis The first decision is whether children are likely to access the service. ICO guidance expects a real assessment of audience, features, marketing, and actual user patterns, not a simple statement that the service is intended for adults. - Document audience evidence from analytics, market, and product signals - Map the child journey across onboarding, content, messaging, ads, and support - Identify third party SDKs and data sharing dependencies that affect children - Record the age bands you design for and why ## Standards that usually require product changes The standards most often missed in practice are high privacy by default, data minimisation, avoiding detrimental uses, turning geolocation off by default, disabling profiling by default unless there is a compelling reason, and not using nudge techniques that push children toward weaker privacy. - Set high privacy defaults for collection and sharing - Turn precise geolocation off by default unless strongly justified - Avoid profiling or persuasive design that undermines privacy choices - Provide child appropriate explanations at the point of use ## Assurance and evidence The ICO AADC impact assessment template is a practical way to show how product and privacy teams considered harms, alternatives, and safeguards before launch. - Maintain a Children's Code control matrix against the 15 standards - Keep AADC impact assessments, design decisions, and testing evidence - Log approvals for exceptions and mitigations - Include child privacy checks in release governance and incident response *Recommended next step* *Placement: near the end of the main content before related guides* ## Use UK GDPR Children and Age Appropriate Design as a cited research workflow Research Copilot can take UK GDPR Children and Age Appropriate Design from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR Children and Age Appropriate Design](/solutions/research-copilot.md): Start from UK GDPR Children and Age Appropriate Design and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Children and Age Appropriate Design. ## Primary sources - [ICO age appropriate design code](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/age-appropriate-design-a-code-of-practice-for-online-services/?ref=sorena.io) - Children's Code standards. - [ICO AADC impact assessment template](https://ico.org.uk/media/for-organisations/documents/2615856/aadc-impact-assessment-v13.pdf?ref=sorena.io) - Child focused impact assessment template. - [ICO guide to the data protection principles](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/?ref=sorena.io) - Principles and fine tiers guidance. - [ICO UK GDPR guidance and resources](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/?ref=sorena.io) - Primary ICO guidance hub. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/children-and-age-appropriate-design --- --- title: "UK GDPR Children and Age Appropriate Design" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/children-and-age-appropriate-design" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/children-and-age-appropriate-design" author: "Sorena AI" description: "Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance." keywords: - "UK GDPR children data" - "age appropriate design code" - "likely to be accessed by children" - "Children's Code compliance" - "Children's Code" - "Age Appropriate Design" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Children and Age Appropriate Design Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. *Children's Data* *UK GDPR* ## UK GDPR Children and Age Appropriate Design Design online services for children using the ICO child first standards. If a service is likely to be accessed by children, the Children's Code affects defaults, profiling, geolocation, sharing, and transparency. The Children's Code changes product settings, feature design, vendor choices, and testing practices for online services likely to be accessed by children. ## Likely to be accessed analysis The first decision is whether children are likely to access the service. ICO guidance expects a real assessment of audience, features, marketing, and actual user patterns, not a simple statement that the service is intended for adults. - Document audience evidence from analytics, market, and product signals - Map the child journey across onboarding, content, messaging, ads, and support - Identify third party SDKs and data sharing dependencies that affect children - Record the age bands you design for and why ## Standards that usually require product changes The standards most often missed in practice are high privacy by default, data minimisation, avoiding detrimental uses, turning geolocation off by default, disabling profiling by default unless there is a compelling reason, and not using nudge techniques that push children toward weaker privacy. - Set high privacy defaults for collection and sharing - Turn precise geolocation off by default unless strongly justified - Avoid profiling or persuasive design that undermines privacy choices - Provide child appropriate explanations at the point of use ## Assurance and evidence The ICO AADC impact assessment template is a practical way to show how product and privacy teams considered harms, alternatives, and safeguards before launch. - Maintain a Children's Code control matrix against the 15 standards - Keep AADC impact assessments, design decisions, and testing evidence - Log approvals for exceptions and mitigations - Include child privacy checks in release governance and incident response *Recommended next step* *Placement: near the end of the main content before related guides* ## Use UK GDPR Children and Age Appropriate Design as a cited research workflow Research Copilot can take UK GDPR Children and Age Appropriate Design from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR Children and Age Appropriate Design](/solutions/research-copilot.md): Start from UK GDPR Children and Age Appropriate Design and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Children and Age Appropriate Design. ## Primary sources - [ICO age appropriate design code](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/age-appropriate-design-a-code-of-practice-for-online-services/?ref=sorena.io) - Children's Code standards. - [ICO AADC impact assessment template](https://ico.org.uk/media/for-organisations/documents/2615856/aadc-impact-assessment-v13.pdf?ref=sorena.io) - Child focused impact assessment template. - [ICO guide to the data protection principles](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/?ref=sorena.io) - Principles and fine tiers guidance. - [ICO UK GDPR guidance and resources](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/?ref=sorena.io) - Primary ICO guidance hub. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/children-and-age-appropriate-design --- --- title: "UK GDPR Compliance Program" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/compliance" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/compliance" author: "Sorena AI" description: "Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls." keywords: - "UK GDPR compliance program" - "UK GDPR operating model" - "UK GDPR governance" - "Article 30 records" - "Accountability" - "UK privacy operations" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Compliance Program Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. *Operating Model* *UK GDPR* ## UK GDPR Compliance Program Build a UK GDPR programme that legal, product, security, and vendor teams can actually run. Publication grade compliance needs traceability from legal interpretation to controls, tickets, and evidence. A credible UK GDPR programme is more than a policy set. It is a repeatable system for deciding, documenting, testing, and updating privacy controls. ## Programme foundation Use the ICO accountability model as the core design. Every processing activity should have a lawful basis, an accountable owner, a documentation trail, and a route for challenge and change. - Create a single processing inventory linked to purposes, data types, recipients, and retention - Assign control owners for transparency, rights, security, transfers, and incidents - Track lawful basis, legitimate interests, and consent dependencies - Define when a DPIA or legal escalation is mandatory ## Operational workstreams The programme should connect data subject rights, processor management, security, and engineering release controls. UK GDPR breaks down when these workstreams are run in isolation. - Run one month rights handling with proportionate verification and closure evidence - Keep Article 28 processor contracts and vendor controls current - Test security against Article 32 risk and recovery needs - Escalate breaches and transfer changes through named owners ## Review and assurance Use periodic reviews to detect drift. ICO investigations often expose that the original design was sound but the implementation was not kept current as products, vendors, or data uses changed. - Review records, notices, contracts, and transfer packs on a set cadence - Retain proof of training, audits, control tests, and remediation - Use internal audits before major launches - Keep a senior management view of unresolved privacy risk *Recommended next step* *Placement: after the compliance steps* ## Turn UK GDPR Compliance Program into an operational assessment Assessment Autopilot can take UK GDPR Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK GDPR Compliance Program](/solutions/assessment.md): Start from UK GDPR Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Compliance Program. ## Primary sources - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. - [ICO documentation guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/documentation/?ref=sorena.io) - Article 30 and supporting documentation guidance. - [ICO guide to data security](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/?ref=sorena.io) - Article 32 and security principle guidance. - [ICO international transfers guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/?ref=sorena.io) - Adequacy, IDTA, Addendum, and TRA guidance. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/compliance --- --- title: "UK GDPR Compliance Program" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/compliance" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/compliance" author: "Sorena AI" description: "Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls." keywords: - "UK GDPR compliance program" - "UK GDPR operating model" - "UK GDPR governance" - "Article 30 records" - "Accountability" - "UK privacy operations" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Compliance Program Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. *Operating Model* *UK GDPR* ## UK GDPR Compliance Program Build a UK GDPR programme that legal, product, security, and vendor teams can actually run. Publication grade compliance needs traceability from legal interpretation to controls, tickets, and evidence. A credible UK GDPR programme is more than a policy set. It is a repeatable system for deciding, documenting, testing, and updating privacy controls. ## Programme foundation Use the ICO accountability model as the core design. Every processing activity should have a lawful basis, an accountable owner, a documentation trail, and a route for challenge and change. - Create a single processing inventory linked to purposes, data types, recipients, and retention - Assign control owners for transparency, rights, security, transfers, and incidents - Track lawful basis, legitimate interests, and consent dependencies - Define when a DPIA or legal escalation is mandatory ## Operational workstreams The programme should connect data subject rights, processor management, security, and engineering release controls. UK GDPR breaks down when these workstreams are run in isolation. - Run one month rights handling with proportionate verification and closure evidence - Keep Article 28 processor contracts and vendor controls current - Test security against Article 32 risk and recovery needs - Escalate breaches and transfer changes through named owners ## Review and assurance Use periodic reviews to detect drift. ICO investigations often expose that the original design was sound but the implementation was not kept current as products, vendors, or data uses changed. - Review records, notices, contracts, and transfer packs on a set cadence - Retain proof of training, audits, control tests, and remediation - Use internal audits before major launches - Keep a senior management view of unresolved privacy risk *Recommended next step* *Placement: after the compliance steps* ## Turn UK GDPR Compliance Program into an operational assessment Assessment Autopilot can take UK GDPR Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK GDPR Compliance Program](/solutions/assessment.md): Start from UK GDPR Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Compliance Program. ## Primary sources - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. - [ICO documentation guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/documentation/?ref=sorena.io) - Article 30 and supporting documentation guidance. - [ICO guide to data security](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/?ref=sorena.io) - Article 32 and security principle guidance. - [ICO international transfers guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/?ref=sorena.io) - Adequacy, IDTA, Addendum, and TRA guidance. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/compliance --- --- title: "UK GDPR Data Subject Rights" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/data-subject-rights" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/data-subject-rights" author: "Sorena AI" description: "Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection." keywords: - "UK GDPR data subject rights" - "subject access request UK" - "UK GDPR one month response" - "UK GDPR rights workflow" - "UK GDPR rights" - "Subject access request" - "One month response" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Data Subject Rights Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. *Individual Rights* *UK GDPR* ## UK GDPR Data Subject Rights Run rights workflows that meet ICO timing, verification, and disclosure expectations. Good rights operations depend on searchability, ownership, and documented exceptions, not on ad hoc inbox handling. Under UK GDPR, rights handling is a core operational function. The business needs to know what right was invoked, what identity checks were appropriate, what exceptions apply, and when the response clock ends. ## Rights inventory and timing The main operational rights are access, rectification, erasure, restriction, portability, objection, and rights related to automated decision making. Most requests must be answered without undue delay and within one month. - Categorise requests by right invoked and the systems affected - Track the one month deadline from receipt of a valid request - Record any extension notice and why it was needed - Keep denial and partial disclosure rationales with the legal basis used ## Verification and search strategy The ICO expects verification to be proportionate. Ask only for what is needed to confirm identity or authority. Excessive verification creates its own compliance risk. - Use account authentication where appropriate - Avoid requesting data you do not actually need to verify the request - Search processors and key downstream systems as part of the standard workflow - Keep a clear audit trail of searches, exceptions, and disclosures made ## Common failure points The most common failures are weak search coverage, poor exception handling, and inconsistent coordination with vendors. - Maintain a rights playbook for legal, support, and engineering teams - Use templates for access packages, erasure outcomes, and refusal notices - Train vendors and internal teams on response timelines and escalation - Measure cycle time, backlog, refusal reasons, and repeat complaints *Recommended next step* *Placement: after the scope or definition section* ## Use UK GDPR Data Subject Rights as a cited research workflow Research Copilot can take UK GDPR Data Subject Rights from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR Data Subject Rights](/solutions/research-copilot.md): Start from UK GDPR Data Subject Rights and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Data Subject Rights. ## Primary sources - [ICO guide to individual rights](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/a-guide-to-individual-rights/?ref=sorena.io) - Operational rights guidance. - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. - [ICO documentation guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/documentation/?ref=sorena.io) - Article 30 and supporting documentation guidance. - [UK GDPR on legislation.gov.uk](https://www.legislation.gov.uk/eur/2016/679/contents?ref=sorena.io) - UK legislative text. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/data-subject-rights --- --- title: "UK GDPR Data Subject Rights" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/data-subject-rights" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/data-subject-rights" author: "Sorena AI" description: "Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection." keywords: - "UK GDPR data subject rights" - "subject access request UK" - "UK GDPR one month response" - "UK GDPR rights workflow" - "UK GDPR rights" - "Subject access request" - "One month response" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Data Subject Rights Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. *Individual Rights* *UK GDPR* ## UK GDPR Data Subject Rights Run rights workflows that meet ICO timing, verification, and disclosure expectations. Good rights operations depend on searchability, ownership, and documented exceptions, not on ad hoc inbox handling. Under UK GDPR, rights handling is a core operational function. The business needs to know what right was invoked, what identity checks were appropriate, what exceptions apply, and when the response clock ends. ## Rights inventory and timing The main operational rights are access, rectification, erasure, restriction, portability, objection, and rights related to automated decision making. Most requests must be answered without undue delay and within one month. - Categorise requests by right invoked and the systems affected - Track the one month deadline from receipt of a valid request - Record any extension notice and why it was needed - Keep denial and partial disclosure rationales with the legal basis used ## Verification and search strategy The ICO expects verification to be proportionate. Ask only for what is needed to confirm identity or authority. Excessive verification creates its own compliance risk. - Use account authentication where appropriate - Avoid requesting data you do not actually need to verify the request - Search processors and key downstream systems as part of the standard workflow - Keep a clear audit trail of searches, exceptions, and disclosures made ## Common failure points The most common failures are weak search coverage, poor exception handling, and inconsistent coordination with vendors. - Maintain a rights playbook for legal, support, and engineering teams - Use templates for access packages, erasure outcomes, and refusal notices - Train vendors and internal teams on response timelines and escalation - Measure cycle time, backlog, refusal reasons, and repeat complaints *Recommended next step* *Placement: after the scope or definition section* ## Use UK GDPR Data Subject Rights as a cited research workflow Research Copilot can take UK GDPR Data Subject Rights from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR Data Subject Rights](/solutions/research-copilot.md): Start from UK GDPR Data Subject Rights and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Data Subject Rights. ## Primary sources - [ICO guide to individual rights](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/a-guide-to-individual-rights/?ref=sorena.io) - Operational rights guidance. - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. - [ICO documentation guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/documentation/?ref=sorena.io) - Article 30 and supporting documentation guidance. - [UK GDPR on legislation.gov.uk](https://www.legislation.gov.uk/eur/2016/679/contents?ref=sorena.io) - UK legislative text. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/data-subject-rights --- --- title: "UK GDPR Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines." keywords: - "UK GDPR deadlines" - "UK GDPR calendar" - "72 hour breach deadline" - "one month subject rights" - "ICO reporting" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Deadlines and Compliance Calendar Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. *Calendar* *UK GDPR* ## UK GDPR Deadlines and Compliance Calendar Use a practical calendar for the deadlines that actually move UK GDPR work. The most important dates are the recurring ones attached to rights, incidents, and transfers. A useful UK GDPR calendar mixes legal milestones with the recurring deadlines and review events that keep the programme current. ## Core legal milestones UK GDPR has applied in the UK since January 1, 2021. The ICO issued the UK IDTA and UK Addendum on February 2, 2022 and the transfer tools came into force on March 21, 2022. - January 1, 2021: UK GDPR applies in the UK legal framework - February 2, 2022: ICO issues the IDTA and UK Addendum - March 21, 2022: IDTA and Addendum come into force - Keep a watch list for ICO guidance updates and UK legislative divergence *Recommended next step* *Placement: after the timeline or milestone section* ## Turn UK GDPR Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take UK GDPR Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK GDPR Deadlines and Compliance Calendar](/solutions/assessment.md): Start from UK GDPR Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Deadlines and Compliance Calendar. ## Recurring operational deadlines Most UK GDPR pressure comes from ongoing deadlines rather than one off commencement dates. - One month to answer most valid rights requests - Up to two additional months for complex or numerous requests, with notice in month one - 72 hours to notify the ICO of a notifiable breach where feasible - Notify affected individuals without undue delay where the breach is likely to create a high risk ## Recommended review cycle The law does not prescribe one annual master review, but programmes work better when documentation, vendors, transfers, and child assessments are revisited on a fixed cadence and after material change. - Quarterly review of processor list, transfer map, and high risk processing changes - Annual review of notices, retention logic, training, and rights metrics - Pre launch review for new profiling, AI, child, or cross border features - Post incident review after every material security or privacy event ## Primary sources - [ICO international data transfer agreement](https://ico.org.uk/media/for-organisations/documents/4019539/international-data-transfer-agreement.pdf?ref=sorena.io) - IDTA A1.0, in force March 21, 2022. - [ICO international data transfer addendum](https://ico.org.uk/media/for-organisations/documents/4019537/international-data-transfer-addendum.pdf?ref=sorena.io) - UK Addendum for EU SCC based contracts. - [ICO personal data breaches guide](https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breaches-a-guide/?ref=sorena.io) - Article 33 and 34 operational guidance. - [ICO guide to individual rights](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/a-guide-to-individual-rights/?ref=sorena.io) - Operational rights guidance. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar --- --- title: "UK GDPR Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines." keywords: - "UK GDPR deadlines" - "UK GDPR calendar" - "72 hour breach deadline" - "one month subject rights" - "ICO reporting" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Deadlines and Compliance Calendar Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. *Calendar* *UK GDPR* ## UK GDPR Deadlines and Compliance Calendar Use a practical calendar for the deadlines that actually move UK GDPR work. The most important dates are the recurring ones attached to rights, incidents, and transfers. A useful UK GDPR calendar mixes legal milestones with the recurring deadlines and review events that keep the programme current. ## Core legal milestones UK GDPR has applied in the UK since January 1, 2021. The ICO issued the UK IDTA and UK Addendum on February 2, 2022 and the transfer tools came into force on March 21, 2022. - January 1, 2021: UK GDPR applies in the UK legal framework - February 2, 2022: ICO issues the IDTA and UK Addendum - March 21, 2022: IDTA and Addendum come into force - Keep a watch list for ICO guidance updates and UK legislative divergence *Recommended next step* *Placement: after the timeline or milestone section* ## Turn UK GDPR Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take UK GDPR Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK GDPR Deadlines and Compliance Calendar](/solutions/assessment.md): Start from UK GDPR Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Deadlines and Compliance Calendar. ## Recurring operational deadlines Most UK GDPR pressure comes from ongoing deadlines rather than one off commencement dates. - One month to answer most valid rights requests - Up to two additional months for complex or numerous requests, with notice in month one - 72 hours to notify the ICO of a notifiable breach where feasible - Notify affected individuals without undue delay where the breach is likely to create a high risk ## Recommended review cycle The law does not prescribe one annual master review, but programmes work better when documentation, vendors, transfers, and child assessments are revisited on a fixed cadence and after material change. - Quarterly review of processor list, transfer map, and high risk processing changes - Annual review of notices, retention logic, training, and rights metrics - Pre launch review for new profiling, AI, child, or cross border features - Post incident review after every material security or privacy event ## Primary sources - [ICO international data transfer agreement](https://ico.org.uk/media/for-organisations/documents/4019539/international-data-transfer-agreement.pdf?ref=sorena.io) - IDTA A1.0, in force March 21, 2022. - [ICO international data transfer addendum](https://ico.org.uk/media/for-organisations/documents/4019537/international-data-transfer-addendum.pdf?ref=sorena.io) - UK Addendum for EU SCC based contracts. - [ICO personal data breaches guide](https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breaches-a-guide/?ref=sorena.io) - Article 33 and 34 operational guidance. - [ICO guide to individual rights](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/a-guide-to-individual-rights/?ref=sorena.io) - Operational rights guidance. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar --- --- title: "UK GDPR FAQ" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/faq" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/faq" author: "Sorena AI" description: "Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure." keywords: - "UK GDPR FAQ" - "UK GDPR questions" - "UK GDPR lawful basis" - "UK GDPR breach" - "UK GDPR IDTA" - "ICO guidance" - "UK privacy questions" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR FAQ Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. *FAQ* *UK GDPR* ## UK GDPR FAQ Answer the UK GDPR questions that usually block implementation decisions. Use these answers to align legal, engineering, procurement, and support teams before work starts. The same UK GDPR questions come up repeatedly in implementation work. Treat the answers as decision rules and link them to documented evidence. ## Scope and accountability questions Common questions include whether a non UK company is in scope, whether a vendor is a processor or a controller, and whether a small company must still keep Article 30 records. - Does the service target or monitor people in the UK - Who decides purpose and essential means for each processing activity - Is there special category data, child data, or profiling that increases risk - What documentation already exists to support the decision ## Transfer, rights, and incident questions Most practical disputes are about whether adequacy is enough, when to use the IDTA instead of the Addendum, whether a request can be extended, and what starts the 72 hour breach clock. - Use adequacy where available and a transfer tool where it is not - Use the Addendum if the EU SCCs already sit in the deal pack - Start the rights clock once you have a valid request - Start breach timing when the controller is aware a breach has occurred ## Children and enforcement questions If children are likely to use the service, the question is not whether the product is intended for children but whether the evidence shows that children are likely users. On enforcement, the ICO looks at whether the organisation can prove what it did and why. - Apply the Children's Code when services are likely to be accessed by children - Keep records of lawful basis, rights handling, transfers, and incidents - Expect higher fine exposure for principle failures and weak lawful processing - Use the programme to reduce complaint volume as well as fine risk *Recommended next step* *Placement: after the FAQ section* ## Use UK GDPR FAQ as a cited research workflow Research Copilot can take UK GDPR FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR FAQ](/solutions/research-copilot.md): Start from UK GDPR FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR FAQ. ## Primary sources - [ICO UK GDPR guidance and resources](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/?ref=sorena.io) - Primary ICO guidance hub. - [ICO guide to individual rights](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/a-guide-to-individual-rights/?ref=sorena.io) - Operational rights guidance. - [ICO international transfers guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/?ref=sorena.io) - Adequacy, IDTA, Addendum, and TRA guidance. - [ICO age appropriate design code](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/age-appropriate-design-a-code-of-practice-for-online-services/?ref=sorena.io) - Children's Code standards. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/faq --- --- title: "UK GDPR FAQ" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/faq" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/faq" author: "Sorena AI" description: "Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure." keywords: - "UK GDPR FAQ" - "UK GDPR questions" - "UK GDPR lawful basis" - "UK GDPR breach" - "UK GDPR IDTA" - "ICO guidance" - "UK privacy questions" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR FAQ Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. *FAQ* *UK GDPR* ## UK GDPR FAQ Answer the UK GDPR questions that usually block implementation decisions. Use these answers to align legal, engineering, procurement, and support teams before work starts. The same UK GDPR questions come up repeatedly in implementation work. Treat the answers as decision rules and link them to documented evidence. ## Scope and accountability questions Common questions include whether a non UK company is in scope, whether a vendor is a processor or a controller, and whether a small company must still keep Article 30 records. - Does the service target or monitor people in the UK - Who decides purpose and essential means for each processing activity - Is there special category data, child data, or profiling that increases risk - What documentation already exists to support the decision ## Transfer, rights, and incident questions Most practical disputes are about whether adequacy is enough, when to use the IDTA instead of the Addendum, whether a request can be extended, and what starts the 72 hour breach clock. - Use adequacy where available and a transfer tool where it is not - Use the Addendum if the EU SCCs already sit in the deal pack - Start the rights clock once you have a valid request - Start breach timing when the controller is aware a breach has occurred ## Children and enforcement questions If children are likely to use the service, the question is not whether the product is intended for children but whether the evidence shows that children are likely users. On enforcement, the ICO looks at whether the organisation can prove what it did and why. - Apply the Children's Code when services are likely to be accessed by children - Keep records of lawful basis, rights handling, transfers, and incidents - Expect higher fine exposure for principle failures and weak lawful processing - Use the programme to reduce complaint volume as well as fine risk *Recommended next step* *Placement: after the FAQ section* ## Use UK GDPR FAQ as a cited research workflow Research Copilot can take UK GDPR FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR FAQ](/solutions/research-copilot.md): Start from UK GDPR FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR FAQ. ## Primary sources - [ICO UK GDPR guidance and resources](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/?ref=sorena.io) - Primary ICO guidance hub. - [ICO guide to individual rights](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/a-guide-to-individual-rights/?ref=sorena.io) - Operational rights guidance. - [ICO international transfers guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/?ref=sorena.io) - Adequacy, IDTA, Addendum, and TRA guidance. - [ICO age appropriate design code](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/childrens-information/childrens-code-guidance-and-resources/age-appropriate-design-a-code-of-practice-for-online-services/?ref=sorena.io) - Children's Code standards. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/faq --- --- title: "IDTA vs EU SCCs" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/idta-vs-eu-sccs" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/idta-vs-eu-sccs" author: "Sorena AI" description: "Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments." keywords: - "IDTA vs EU SCCs" - "UK Addendum vs IDTA" - "UK GDPR transfer tools" - "UK standard contractual clauses" - "IDTA vs SCCs" - "UK Addendum" - "UK GDPR transfers" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # IDTA vs EU SCCs Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. *Transfer Tools* *UK GDPR* ## UK GDPR IDTA vs EU SCCs Choose the right UK transfer instrument without duplicating contracts or missing UK specific steps. The right answer depends on whether the transfer is UK only, EEA plus UK, and how the commercial paper is already structured. Most transfer confusion comes from mixing three questions: whether adequacy exists, whether a contractual tool is needed, and whether the existing EU SCC package should be extended for UK use or replaced by an IDTA. ## When to use each tool Use adequacy where the UK recognises the destination as adequate. If adequacy is not available, use the UK IDTA or use the UK Addendum to bolt UK language onto the EU SCCs. - Use the IDTA for UK only restricted transfers or simple UK vendor paper - Use the Addendum when EU SCCs already sit in the deal pack - Confirm controller, processor, and subprocessor roles before completing the tables - Keep the choice logic in a procurement ready playbook ## What does not change Neither the IDTA nor the Addendum removes the need for a transfer risk assessment, which ICO guidance also calls a data protection test in legislation. - Run a transfer risk assessment for each restricted transfer pattern - Document technical, organisational, and contractual supplementary measures - Link the transfer tool to the main services agreement and security schedule - Set review dates for destination law or vendor changes ## Practical selection checklist Keep the selection logic simple so procurement and legal teams do not reinvent it for every vendor. - Record whether the same vendor receives EEA data, UK data, or both - Check whether the destination already benefits from UK adequacy or a recognised bridge - Retain the signed tool, the linked commercial contract, and the TRA - Define who reopens the analysis when subprocessing or destination law changes *Recommended next step* *Placement: after the comparison section* ## Use UK GDPR IDTA vs EU SCCs as a cited research workflow Research Copilot can take UK GDPR IDTA vs EU SCCs from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR IDTA vs EU SCCs](/solutions/research-copilot.md): Start from UK GDPR IDTA vs EU SCCs and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR IDTA vs EU SCCs. ## Primary sources - [ICO international transfers guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/?ref=sorena.io) - Adequacy, IDTA, Addendum, and TRA guidance. - [ICO international data transfer agreement](https://ico.org.uk/media/for-organisations/documents/4019539/international-data-transfer-agreement.pdf?ref=sorena.io) - IDTA A1.0, in force March 21, 2022. - [ICO international data transfer addendum](https://ico.org.uk/media/for-organisations/documents/4019537/international-data-transfer-addendum.pdf?ref=sorena.io) - UK Addendum for EU SCC based contracts. - [UK GDPR on legislation.gov.uk](https://www.legislation.gov.uk/eur/2016/679/contents?ref=sorena.io) - UK legislative text. ## Related Topic Guides - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/idta-vs-eu-sccs --- --- title: "IDTA vs EU SCCs" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/idta-vs-eu-sccs" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/idta-vs-eu-sccs" author: "Sorena AI" description: "Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments." keywords: - "IDTA vs EU SCCs" - "UK Addendum vs IDTA" - "UK GDPR transfer tools" - "UK standard contractual clauses" - "IDTA vs SCCs" - "UK Addendum" - "UK GDPR transfers" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # IDTA vs EU SCCs Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. *Transfer Tools* *UK GDPR* ## UK GDPR IDTA vs EU SCCs Choose the right UK transfer instrument without duplicating contracts or missing UK specific steps. The right answer depends on whether the transfer is UK only, EEA plus UK, and how the commercial paper is already structured. Most transfer confusion comes from mixing three questions: whether adequacy exists, whether a contractual tool is needed, and whether the existing EU SCC package should be extended for UK use or replaced by an IDTA. ## When to use each tool Use adequacy where the UK recognises the destination as adequate. If adequacy is not available, use the UK IDTA or use the UK Addendum to bolt UK language onto the EU SCCs. - Use the IDTA for UK only restricted transfers or simple UK vendor paper - Use the Addendum when EU SCCs already sit in the deal pack - Confirm controller, processor, and subprocessor roles before completing the tables - Keep the choice logic in a procurement ready playbook ## What does not change Neither the IDTA nor the Addendum removes the need for a transfer risk assessment, which ICO guidance also calls a data protection test in legislation. - Run a transfer risk assessment for each restricted transfer pattern - Document technical, organisational, and contractual supplementary measures - Link the transfer tool to the main services agreement and security schedule - Set review dates for destination law or vendor changes ## Practical selection checklist Keep the selection logic simple so procurement and legal teams do not reinvent it for every vendor. - Record whether the same vendor receives EEA data, UK data, or both - Check whether the destination already benefits from UK adequacy or a recognised bridge - Retain the signed tool, the linked commercial contract, and the TRA - Define who reopens the analysis when subprocessing or destination law changes *Recommended next step* *Placement: after the comparison section* ## Use UK GDPR IDTA vs EU SCCs as a cited research workflow Research Copilot can take UK GDPR IDTA vs EU SCCs from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR IDTA vs EU SCCs](/solutions/research-copilot.md): Start from UK GDPR IDTA vs EU SCCs and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR IDTA vs EU SCCs. ## Primary sources - [ICO international transfers guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/?ref=sorena.io) - Adequacy, IDTA, Addendum, and TRA guidance. - [ICO international data transfer agreement](https://ico.org.uk/media/for-organisations/documents/4019539/international-data-transfer-agreement.pdf?ref=sorena.io) - IDTA A1.0, in force March 21, 2022. - [ICO international data transfer addendum](https://ico.org.uk/media/for-organisations/documents/4019537/international-data-transfer-addendum.pdf?ref=sorena.io) - UK Addendum for EU SCC based contracts. - [UK GDPR on legislation.gov.uk](https://www.legislation.gov.uk/eur/2016/679/contents?ref=sorena.io) - UK legislative text. ## Related Topic Guides - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/idta-vs-eu-sccs --- --- title: "UK GDPR Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/penalties-and-fines" author: "Sorena AI" description: "Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier." keywords: - "UK GDPR penalties" - "UK GDPR fines" - "ICO enforcement" - "article 83 UK GDPR" - "Article 83 penalties" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Penalties and Fines Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. *Enforcement* *UK GDPR* ## UK GDPR Penalties and Fines Understand the real enforcement exposure created by weak UK GDPR controls. Fine tiers matter, but so do complaints, orders, audits, and compensation claims that follow poor evidence or poor decisions. UK GDPR enforcement risk is not limited to a headline fine. The regulator can investigate, order changes, scrutinise your evidence, and compound the issue through public findings and complaint handling failures. ## Higher and standard fine tiers ICO guidance on the principles explains that infringements of the basic principles can reach the higher tier of up to 17.5 million pounds or 4 percent of worldwide annual turnover. Other failures can still attract major enforcement at up to 8.7 million pounds or 2 percent. - Treat lawful basis, fairness, transparency, and purpose limitation as board level issues - Document why each high risk activity is lawful and proportionate - Keep Article 30 records, contracts, DPIAs, and incident logs current - Assume missing evidence will worsen the outcome ## How enforcement escalates Fines usually follow a sequence of complaints, incidents, requests for information, or audit findings that expose a weak operating model. - Escalate repeat complaints and delay patterns before they harden into regulator issues - Retain remediation evidence after incidents or correspondence - Track whether vendors contribute to repeated problems - Use internal reviews to show the business identified and addressed weaknesses *Recommended next step* *Placement: after the enforcement section* ## Use UK GDPR Penalties and Fines as a cited research workflow Research Copilot can take UK GDPR Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR Penalties and Fines](/solutions/research-copilot.md): Start from UK GDPR Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Penalties and Fines. ## Non fine exposure Individuals may also seek compensation and the ICO may require corrective action. For many organisations, those outcomes are more disruptive than the monetary penalty. - Prepare for information notices and urgent remediation - Treat complaint logs and litigation hold decisions as part of the enforcement file - Ensure executive owners can explain risk acceptance decisions - Review communications plans for high profile incidents or investigations ## Primary sources - [ICO guide to the data protection principles](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/?ref=sorena.io) - Principles and fine tiers guidance. - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. - [Data Protection Act 2018](https://www.legislation.gov.uk/ukpga/2018/12/contents?ref=sorena.io) - UK statute supplementing the UK GDPR. - [UK GDPR on legislation.gov.uk](https://www.legislation.gov.uk/eur/2016/679/contents?ref=sorena.io) - UK legislative text. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/penalties-and-fines --- --- title: "UK GDPR Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/penalties-and-fines" author: "Sorena AI" description: "Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier." keywords: - "UK GDPR penalties" - "UK GDPR fines" - "ICO enforcement" - "article 83 UK GDPR" - "Article 83 penalties" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Penalties and Fines Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. *Enforcement* *UK GDPR* ## UK GDPR Penalties and Fines Understand the real enforcement exposure created by weak UK GDPR controls. Fine tiers matter, but so do complaints, orders, audits, and compensation claims that follow poor evidence or poor decisions. UK GDPR enforcement risk is not limited to a headline fine. The regulator can investigate, order changes, scrutinise your evidence, and compound the issue through public findings and complaint handling failures. ## Higher and standard fine tiers ICO guidance on the principles explains that infringements of the basic principles can reach the higher tier of up to 17.5 million pounds or 4 percent of worldwide annual turnover. Other failures can still attract major enforcement at up to 8.7 million pounds or 2 percent. - Treat lawful basis, fairness, transparency, and purpose limitation as board level issues - Document why each high risk activity is lawful and proportionate - Keep Article 30 records, contracts, DPIAs, and incident logs current - Assume missing evidence will worsen the outcome ## How enforcement escalates Fines usually follow a sequence of complaints, incidents, requests for information, or audit findings that expose a weak operating model. - Escalate repeat complaints and delay patterns before they harden into regulator issues - Retain remediation evidence after incidents or correspondence - Track whether vendors contribute to repeated problems - Use internal reviews to show the business identified and addressed weaknesses *Recommended next step* *Placement: after the enforcement section* ## Use UK GDPR Penalties and Fines as a cited research workflow Research Copilot can take UK GDPR Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR Penalties and Fines](/solutions/research-copilot.md): Start from UK GDPR Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Penalties and Fines. ## Non fine exposure Individuals may also seek compensation and the ICO may require corrective action. For many organisations, those outcomes are more disruptive than the monetary penalty. - Prepare for information notices and urgent remediation - Treat complaint logs and litigation hold decisions as part of the enforcement file - Ensure executive owners can explain risk acceptance decisions - Review communications plans for high profile incidents or investigations ## Primary sources - [ICO guide to the data protection principles](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/?ref=sorena.io) - Principles and fine tiers guidance. - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. - [Data Protection Act 2018](https://www.legislation.gov.uk/ukpga/2018/12/contents?ref=sorena.io) - UK statute supplementing the UK GDPR. - [UK GDPR on legislation.gov.uk](https://www.legislation.gov.uk/eur/2016/679/contents?ref=sorena.io) - UK legislative text. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/penalties-and-fines --- --- title: "UK GDPR Requirements" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/requirements" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/requirements" author: "Sorena AI" description: "Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs." keywords: - "UK GDPR requirements" - "UK GDPR controls" - "article 30 records" - "article 32 security" - "article 28 contracts" - "Accountability controls" - "Privacy requirements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Requirements Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. *Requirements* *UK GDPR* ## UK GDPR Requirements Translate UK GDPR duties into concrete controls, owners, tests, and evidence. A requirement matrix works when it is specific enough to drive design, implementation, and audit follow up. The UK GDPR requirement set is easiest to manage when grouped into control domains with clear evidence outputs. ## Core legal control domains Start with the principles, lawful basis, transparency, rights, and accountability. These domains shape nearly every other control decision. - Principles, lawful basis, and fairness for each processing activity - Privacy notice and transparency controls at collection and change points - Article 30 records and wider documentation obligations - Rights handling with timing, verification, and exception logic ## Operational control domains The operating model should then cover the system level controls that make the legal requirements real: security, processor governance, retention, incident response, and transfers. - Article 32 security measures matched to actual risk - Article 28 controller processor contracts and vendor oversight - Retention and deletion rules tied to purpose and legal hold needs - Breach escalation, notification, and post incident remediation ## High risk and change domains Some requirements activate only in certain scenarios but they need clear triggers in the matrix. That includes DPIAs, children, profiling, and restricted transfers. - DPIA triggers and approval workflow - Children's Code requirements for services likely to be accessed by children - International transfer tool selection and TRA - Change management checks before new products, vendors, or data uses go live *Recommended next step* *Placement: after the requirement breakdown* ## Turn UK GDPR Requirements into an operational assessment Assessment Autopilot can take UK GDPR Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK GDPR Requirements](/solutions/assessment.md): Start from UK GDPR Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Requirements. ## Primary sources - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. - [ICO documentation guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/documentation/?ref=sorena.io) - Article 30 and supporting documentation guidance. - [ICO guide to data security](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/?ref=sorena.io) - Article 32 and security principle guidance. - [ICO international transfers guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/?ref=sorena.io) - Adequacy, IDTA, Addendum, and TRA guidance. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/requirements --- --- title: "UK GDPR Requirements" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/requirements" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/requirements" author: "Sorena AI" description: "Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs." keywords: - "UK GDPR requirements" - "UK GDPR controls" - "article 30 records" - "article 32 security" - "article 28 contracts" - "Accountability controls" - "Privacy requirements" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Requirements Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. *Requirements* *UK GDPR* ## UK GDPR Requirements Translate UK GDPR duties into concrete controls, owners, tests, and evidence. A requirement matrix works when it is specific enough to drive design, implementation, and audit follow up. The UK GDPR requirement set is easiest to manage when grouped into control domains with clear evidence outputs. ## Core legal control domains Start with the principles, lawful basis, transparency, rights, and accountability. These domains shape nearly every other control decision. - Principles, lawful basis, and fairness for each processing activity - Privacy notice and transparency controls at collection and change points - Article 30 records and wider documentation obligations - Rights handling with timing, verification, and exception logic ## Operational control domains The operating model should then cover the system level controls that make the legal requirements real: security, processor governance, retention, incident response, and transfers. - Article 32 security measures matched to actual risk - Article 28 controller processor contracts and vendor oversight - Retention and deletion rules tied to purpose and legal hold needs - Breach escalation, notification, and post incident remediation ## High risk and change domains Some requirements activate only in certain scenarios but they need clear triggers in the matrix. That includes DPIAs, children, profiling, and restricted transfers. - DPIA triggers and approval workflow - Children's Code requirements for services likely to be accessed by children - International transfer tool selection and TRA - Change management checks before new products, vendors, or data uses go live *Recommended next step* *Placement: after the requirement breakdown* ## Turn UK GDPR Requirements into an operational assessment Assessment Autopilot can take UK GDPR Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for UK GDPR Requirements](/solutions/assessment.md): Start from UK GDPR Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Requirements. ## Primary sources - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. - [ICO documentation guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/documentation/?ref=sorena.io) - Article 30 and supporting documentation guidance. - [ICO guide to data security](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/?ref=sorena.io) - Article 32 and security principle guidance. - [ICO international transfers guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/?ref=sorena.io) - Adequacy, IDTA, Addendum, and TRA guidance. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/requirements --- --- title: "UK GDPR Transfers, IDTA, and UK Addendum" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum" author: "Sorena AI" description: "Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance." keywords: - "UK GDPR international transfers" - "UK IDTA" - "UK Addendum" - "transfer risk assessment" - "UK data bridge" - "UK GDPR transfers" - "IDTA" - "TRA" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Transfers, IDTA, and UK Addendum Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. *Cross Border Data* *UK GDPR* ## UK GDPR Transfers, IDTA, and UK Addendum Run UK transfer compliance with the right legal tool, the right supporting analysis, and the right vendor controls. The contract is only one part of the transfer pack. The rest is inventory, destination analysis, security, and review discipline. Restricted transfer compliance under UK GDPR is a repeatable workflow. Start by identifying where the personal data goes, then decide whether you rely on adequacy, the IDTA, the UK Addendum, or another UK recognised safeguard. ## Transfer discovery and mechanism selection Build a transfer inventory by system, vendor, country, recipient role, and legal basis for the transfer. Many programmes fail because they only track major cloud vendors and miss support tools, analytics, or customer success platforms. - Inventory every restricted transfer and the categories of data involved - Record adequacy, bridge, IDTA, or Addendum as the legal mechanism - Map exporter and importer roles correctly - Tie transfer approvals to procurement and subprocessor change alerts ## Transfer risk assessment and safeguards ICO guidance explains that the transfer risk assessment remains necessary even when the contract tool is correct. The assessment should address destination law, access risk, the importer's environment, and supplementary measures. - Keep a destination law and practical access analysis - Document technical, organisational, and contractual supplementary measures - Review importer security and onward transfer controls - Set revalidation triggers for country changes, vendor incidents, and legal updates ## Operations after signature Signing the tool is the start of transfer compliance, not the end. The exporter still needs to watch for destination law changes, vendor architecture changes, and new data uses that alter the original analysis. - Store the signed tool, linked contract, security schedule, and TRA together - Review transfers during renewals, incidents, and architecture changes - Ensure rights, deletion, and breach obligations flow to the importer - Define fallback actions if the legal basis or destination risk changes *Recommended next step* *Placement: after the scope or definition section* ## Use UK GDPR Transfers, IDTA, and UK Addendum as a cited research workflow Research Copilot can take UK GDPR Transfers, IDTA, and UK Addendum from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR Transfers, IDTA, and UK Addendum](/solutions/research-copilot.md): Start from UK GDPR Transfers, IDTA, and UK Addendum and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Transfers, IDTA, and UK Addendum. ## Primary sources - [ICO international transfers guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/?ref=sorena.io) - Adequacy, IDTA, Addendum, and TRA guidance. - [ICO international data transfer agreement](https://ico.org.uk/media/for-organisations/documents/4019539/international-data-transfer-agreement.pdf?ref=sorena.io) - IDTA A1.0, in force March 21, 2022. - [ICO international data transfer addendum](https://ico.org.uk/media/for-organisations/documents/4019537/international-data-transfer-addendum.pdf?ref=sorena.io) - UK Addendum for EU SCC based contracts. - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum --- --- title: "UK GDPR Transfers, IDTA, and UK Addendum" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum" author: "Sorena AI" description: "Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance." keywords: - "UK GDPR international transfers" - "UK IDTA" - "UK Addendum" - "transfer risk assessment" - "UK data bridge" - "UK GDPR transfers" - "IDTA" - "TRA" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR Transfers, IDTA, and UK Addendum Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. *Cross Border Data* *UK GDPR* ## UK GDPR Transfers, IDTA, and UK Addendum Run UK transfer compliance with the right legal tool, the right supporting analysis, and the right vendor controls. The contract is only one part of the transfer pack. The rest is inventory, destination analysis, security, and review discipline. Restricted transfer compliance under UK GDPR is a repeatable workflow. Start by identifying where the personal data goes, then decide whether you rely on adequacy, the IDTA, the UK Addendum, or another UK recognised safeguard. ## Transfer discovery and mechanism selection Build a transfer inventory by system, vendor, country, recipient role, and legal basis for the transfer. Many programmes fail because they only track major cloud vendors and miss support tools, analytics, or customer success platforms. - Inventory every restricted transfer and the categories of data involved - Record adequacy, bridge, IDTA, or Addendum as the legal mechanism - Map exporter and importer roles correctly - Tie transfer approvals to procurement and subprocessor change alerts ## Transfer risk assessment and safeguards ICO guidance explains that the transfer risk assessment remains necessary even when the contract tool is correct. The assessment should address destination law, access risk, the importer's environment, and supplementary measures. - Keep a destination law and practical access analysis - Document technical, organisational, and contractual supplementary measures - Review importer security and onward transfer controls - Set revalidation triggers for country changes, vendor incidents, and legal updates ## Operations after signature Signing the tool is the start of transfer compliance, not the end. The exporter still needs to watch for destination law changes, vendor architecture changes, and new data uses that alter the original analysis. - Store the signed tool, linked contract, security schedule, and TRA together - Review transfers during renewals, incidents, and architecture changes - Ensure rights, deletion, and breach obligations flow to the importer - Define fallback actions if the legal basis or destination risk changes *Recommended next step* *Placement: after the scope or definition section* ## Use UK GDPR Transfers, IDTA, and UK Addendum as a cited research workflow Research Copilot can take UK GDPR Transfers, IDTA, and UK Addendum from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR Transfers, IDTA, and UK Addendum](/solutions/research-copilot.md): Start from UK GDPR Transfers, IDTA, and UK Addendum and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR Transfers, IDTA, and UK Addendum. ## Primary sources - [ICO international transfers guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/?ref=sorena.io) - Adequacy, IDTA, Addendum, and TRA guidance. - [ICO international data transfer agreement](https://ico.org.uk/media/for-organisations/documents/4019539/international-data-transfer-agreement.pdf?ref=sorena.io) - IDTA A1.0, in force March 21, 2022. - [ICO international data transfer addendum](https://ico.org.uk/media/for-organisations/documents/4019537/international-data-transfer-addendum.pdf?ref=sorena.io) - UK Addendum for EU SCC based contracts. - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum --- --- title: "UK GDPR vs Data Protection Act 2018" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018" author: "Sorena AI" description: "Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it." keywords: - "UK GDPR vs Data Protection Act 2018" - "DPA 2018 vs UK GDPR" - "UK privacy law comparison" - "UK GDPR vs DPA 2018" - "Data Protection Act 2018" - "UK privacy law" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR vs Data Protection Act 2018 Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. *Comparison* *UK GDPR* ## UK GDPR vs Data Protection Act 2018 Understand how the UK GDPR and DPA 2018 fit together in practice. The UK GDPR carries the general rules, while the Data Protection Act 2018 fills in UK specific details and additional regimes. Many teams cite the UK GDPR and the Data Protection Act 2018 interchangeably, but they do different jobs. Good compliance work knows which source answers which question. ## What the UK GDPR does The UK GDPR is the main framework for principles, lawful basis, rights, transparency, security, records, transfers, and breaches. It is the starting point for most private sector compliance work. - Use the UK GDPR for principles, lawful basis, rights, security, and transfers - Treat Articles 30, 32, 33, 34, and 35 as core operational requirements - Use ICO guidance to interpret how those duties work - Build your control matrix around the UK GDPR first ## What the DPA 2018 adds The Data Protection Act 2018 supplements the UK GDPR with UK specific exemptions, conditions for certain processing, regulator powers, and separate regimes such as law enforcement processing. - Check the DPA 2018 for exemptions and restrictions to rights - Use it for law enforcement and intelligence services processing regimes - Review it when assessing regulator powers and procedural issues - Use it with the UK GDPR rather than instead of the UK GDPR ## Operational implication The practical lesson is simple: write policies, notices, and workflows so they reference the right authority. A weak legal map leads to weak exception handling and weak complaint responses. - Keep a legal interpretation log that cites the correct source - Train support teams on when a request is refused under a DPA 2018 exception - Escalate unusual sector specific processing for specialist review - Retain the legal rationale behind any rights restriction or exemption *Recommended next step* *Placement: after the comparison section* ## Use UK GDPR vs Data Protection Act 2018 as a cited research workflow Research Copilot can take UK GDPR vs Data Protection Act 2018 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR vs Data Protection Act 2018](/solutions/research-copilot.md): Start from UK GDPR vs Data Protection Act 2018 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR vs Data Protection Act 2018. ## Primary sources - [UK GDPR on legislation.gov.uk](https://www.legislation.gov.uk/eur/2016/679/contents?ref=sorena.io) - UK legislative text. - [Data Protection Act 2018](https://www.legislation.gov.uk/ukpga/2018/12/contents?ref=sorena.io) - UK statute supplementing the UK GDPR. - [ICO UK GDPR guidance and resources](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/?ref=sorena.io) - Primary ICO guidance hub. - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018 --- --- title: "UK GDPR vs Data Protection Act 2018" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018" author: "Sorena AI" description: "Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it." keywords: - "UK GDPR vs Data Protection Act 2018" - "DPA 2018 vs UK GDPR" - "UK privacy law comparison" - "UK GDPR vs DPA 2018" - "Data Protection Act 2018" - "UK privacy law" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR vs Data Protection Act 2018 Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. *Comparison* *UK GDPR* ## UK GDPR vs Data Protection Act 2018 Understand how the UK GDPR and DPA 2018 fit together in practice. The UK GDPR carries the general rules, while the Data Protection Act 2018 fills in UK specific details and additional regimes. Many teams cite the UK GDPR and the Data Protection Act 2018 interchangeably, but they do different jobs. Good compliance work knows which source answers which question. ## What the UK GDPR does The UK GDPR is the main framework for principles, lawful basis, rights, transparency, security, records, transfers, and breaches. It is the starting point for most private sector compliance work. - Use the UK GDPR for principles, lawful basis, rights, security, and transfers - Treat Articles 30, 32, 33, 34, and 35 as core operational requirements - Use ICO guidance to interpret how those duties work - Build your control matrix around the UK GDPR first ## What the DPA 2018 adds The Data Protection Act 2018 supplements the UK GDPR with UK specific exemptions, conditions for certain processing, regulator powers, and separate regimes such as law enforcement processing. - Check the DPA 2018 for exemptions and restrictions to rights - Use it for law enforcement and intelligence services processing regimes - Review it when assessing regulator powers and procedural issues - Use it with the UK GDPR rather than instead of the UK GDPR ## Operational implication The practical lesson is simple: write policies, notices, and workflows so they reference the right authority. A weak legal map leads to weak exception handling and weak complaint responses. - Keep a legal interpretation log that cites the correct source - Train support teams on when a request is refused under a DPA 2018 exception - Escalate unusual sector specific processing for specialist review - Retain the legal rationale behind any rights restriction or exemption *Recommended next step* *Placement: after the comparison section* ## Use UK GDPR vs Data Protection Act 2018 as a cited research workflow Research Copilot can take UK GDPR vs Data Protection Act 2018 from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR vs Data Protection Act 2018](/solutions/research-copilot.md): Start from UK GDPR vs Data Protection Act 2018 and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR vs Data Protection Act 2018. ## Primary sources - [UK GDPR on legislation.gov.uk](https://www.legislation.gov.uk/eur/2016/679/contents?ref=sorena.io) - UK legislative text. - [Data Protection Act 2018](https://www.legislation.gov.uk/ukpga/2018/12/contents?ref=sorena.io) - UK statute supplementing the UK GDPR. - [ICO UK GDPR guidance and resources](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/?ref=sorena.io) - Primary ICO guidance hub. - [ICO guide to accountability and governance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/?ref=sorena.io) - Accountability, records, and contracts guidance. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018 --- --- title: "UK GDPR vs EU GDPR" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr" author: "Sorena AI" description: "Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes." keywords: - "UK GDPR vs EU GDPR" - "UK vs EU GDPR" - "UK EU privacy differences" - "UK GDPR comparison" - "International privacy operations" - "UK and EU privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR vs EU GDPR Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. *Comparison* *UK GDPR* ## UK GDPR vs EU GDPR Separate the common core from the UK specific and EU specific operational differences. Most obligations still look familiar, but transfer tooling, regulator relationships, and future divergence are now separate programme issues. The UK GDPR and the EU GDPR still share a common structure, but privacy programmes that assume they are interchangeable will eventually miss UK specific transfer, regulator, or legislative details. ## Where they still align Both regimes keep the same basic architecture around principles, lawful basis, rights, security, breaches, records, and DPIAs. A well designed core privacy programme can support both with shared policies and controls. - Use shared control language for principles, lawful basis, rights, and security - Reuse records of processing and vendor governance where the facts are the same - Keep one evidence model with jurisdiction specific overlays - Track where local law changes alter the shared baseline ## Where they differ in practice The UK has its own regulator, its own transfer tools, and its own adequacy decisions. The EU uses the European Commission adequacy framework and the EU standard contractual clauses. - Separate UK and EU transfer inventories and mechanism libraries - Track whether a destination is adequate for the UK, the EU, or both - Use the UK Addendum or IDTA for UK restricted transfers where needed - Manage regulator contact and complaints through the correct authority ## How to run one programme The pragmatic approach is one common privacy operating model with a UK branch and an EU branch for transfers, regulator routing, and local legal updates. - Maintain a UK EU differences register - Train commercial teams on when the UK Addendum or IDTA must be added - Use notice language that reflects the correct regulator and transfer mechanism - Review cross border complaint and incident escalation paths regularly *Recommended next step* *Placement: after the comparison section* ## Use UK GDPR vs EU GDPR as a cited research workflow Research Copilot can take UK GDPR vs EU GDPR from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR vs EU GDPR](/solutions/research-copilot.md): Start from UK GDPR vs EU GDPR and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR vs EU GDPR. ## Primary sources - [UK GDPR on legislation.gov.uk](https://www.legislation.gov.uk/eur/2016/679/contents?ref=sorena.io) - UK legislative text. - [ICO international transfers guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/?ref=sorena.io) - Adequacy, IDTA, Addendum, and TRA guidance. - [ICO international data transfer agreement](https://ico.org.uk/media/for-organisations/documents/4019539/international-data-transfer-agreement.pdf?ref=sorena.io) - IDTA A1.0, in force March 21, 2022. - [EUR-Lex GDPR text](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng?ref=sorena.io) - Official EU GDPR text. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr --- --- title: "UK GDPR vs EU GDPR" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr" author: "Sorena AI" description: "Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes." keywords: - "UK GDPR vs EU GDPR" - "UK vs EU GDPR" - "UK EU privacy differences" - "UK GDPR comparison" - "International privacy operations" - "UK and EU privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK GDPR vs EU GDPR Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. *Comparison* *UK GDPR* ## UK GDPR vs EU GDPR Separate the common core from the UK specific and EU specific operational differences. Most obligations still look familiar, but transfer tooling, regulator relationships, and future divergence are now separate programme issues. The UK GDPR and the EU GDPR still share a common structure, but privacy programmes that assume they are interchangeable will eventually miss UK specific transfer, regulator, or legislative details. ## Where they still align Both regimes keep the same basic architecture around principles, lawful basis, rights, security, breaches, records, and DPIAs. A well designed core privacy programme can support both with shared policies and controls. - Use shared control language for principles, lawful basis, rights, and security - Reuse records of processing and vendor governance where the facts are the same - Keep one evidence model with jurisdiction specific overlays - Track where local law changes alter the shared baseline ## Where they differ in practice The UK has its own regulator, its own transfer tools, and its own adequacy decisions. The EU uses the European Commission adequacy framework and the EU standard contractual clauses. - Separate UK and EU transfer inventories and mechanism libraries - Track whether a destination is adequate for the UK, the EU, or both - Use the UK Addendum or IDTA for UK restricted transfers where needed - Manage regulator contact and complaints through the correct authority ## How to run one programme The pragmatic approach is one common privacy operating model with a UK branch and an EU branch for transfers, regulator routing, and local legal updates. - Maintain a UK EU differences register - Train commercial teams on when the UK Addendum or IDTA must be added - Use notice language that reflects the correct regulator and transfer mechanism - Review cross border complaint and incident escalation paths regularly *Recommended next step* *Placement: after the comparison section* ## Use UK GDPR vs EU GDPR as a cited research workflow Research Copilot can take UK GDPR vs EU GDPR from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR vs EU GDPR](/solutions/research-copilot.md): Start from UK GDPR vs EU GDPR and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR vs EU GDPR. ## Primary sources - [UK GDPR on legislation.gov.uk](https://www.legislation.gov.uk/eur/2016/679/contents?ref=sorena.io) - UK legislative text. - [ICO international transfers guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/?ref=sorena.io) - Adequacy, IDTA, Addendum, and TRA guidance. - [ICO international data transfer agreement](https://ico.org.uk/media/for-organisations/documents/4019539/international-data-transfer-agreement.pdf?ref=sorena.io) - IDTA A1.0, in force March 21, 2022. - [EUR-Lex GDPR text](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng?ref=sorena.io) - Official EU GDPR text. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK vs EU GDPR Differences | Operational Differences List](/artifacts/uk/uk-gdpr/uk-vs-eu-differences.md): Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr --- --- title: "UK vs EU GDPR Differences" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/uk-vs-eu-differences" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/uk-vs-eu-differences" author: "Sorena AI" description: "Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance." keywords: - "UK vs EU GDPR differences" - "UK EU privacy differences" - "UK transfer differences" - "ICO vs EU regulators" - "UK vs EU differences" - "Privacy operations" - "Transfer divergence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK vs EU GDPR Differences Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. *Differences* *UK GDPR* ## UK GDPR UK vs EU Differences Use a practical differences register instead of relying on memory or generic comparison slides. The differences that matter most are the ones that change contracts, notices, regulator routing, and technical controls. Global privacy teams need a short, maintained list of UK and EU differences that change real work. ## Transfer and adequacy differences The UK and EU each maintain their own adequacy decisions and transfer tool expectations. If you export data from both regions, treat the transfer package as jurisdiction specific work. - Keep separate UK and EU adequacy watch lists - Use UK IDTA or Addendum for UK restricted transfers - Use EU SCCs for EU exports where required - Record whether a vendor relationship carries UK data, EU data, or both *Recommended next step* *Placement: after the comparison section* ## Use UK GDPR UK vs EU Differences as a cited research workflow Research Copilot can take UK GDPR UK vs EU Differences from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR UK vs EU Differences](/solutions/research-copilot.md): Start from UK GDPR UK vs EU Differences and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR UK vs EU Differences. ## Regulator and legal update differences The ICO is the UK authority and publishes its own guidance. EU programmes still need to monitor EU supervisory authorities, EDPB positions, and European Commission activity. - Route UK complaints and incident issues to the ICO workflow - Track UK specific legislation and guidance updates separately from EU changes - Maintain notice language that names the correct authority and legal tools - Review whether internal templates cite UK or EU law correctly ## Programme design differences The simplest design is a shared baseline with explicit local overlays. Document the overlays once and make them reusable in notices, vendor contracts, rights playbooks, and product requirements. - Use one common control set for shared GDPR style obligations - Create UK specific overlays for transfers, regulator routing, and legislative supplements - Retain one evidence repository with jurisdiction tags - Review divergence after every major transfer, incident, or legal update ## Primary sources - [ICO international transfers guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/?ref=sorena.io) - Adequacy, IDTA, Addendum, and TRA guidance. - [ICO international data transfer agreement](https://ico.org.uk/media/for-organisations/documents/4019539/international-data-transfer-agreement.pdf?ref=sorena.io) - IDTA A1.0, in force March 21, 2022. - [ICO UK GDPR guidance and resources](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/?ref=sorena.io) - Primary ICO guidance hub. - [European Data Protection Board](https://www.edpb.europa.eu/?ref=sorena.io) - EU level regulator coordination source. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/uk-vs-eu-differences --- --- title: "UK vs EU GDPR Differences" canonical_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/uk-vs-eu-differences" source_url: "https://www.sorena.io/artifacts/uk/uk-gdpr/uk-vs-eu-differences" author: "Sorena AI" description: "Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance." keywords: - "UK vs EU GDPR differences" - "UK EU privacy differences" - "UK transfer differences" - "ICO vs EU regulators" - "UK vs EU differences" - "Privacy operations" - "Transfer divergence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # UK vs EU GDPR Differences Operational differences between the UK and EU privacy regimes, including transfer tools, adequacy lists, regulators, notices, and programme governance. *Differences* *UK GDPR* ## UK GDPR UK vs EU Differences Use a practical differences register instead of relying on memory or generic comparison slides. The differences that matter most are the ones that change contracts, notices, regulator routing, and technical controls. Global privacy teams need a short, maintained list of UK and EU differences that change real work. ## Transfer and adequacy differences The UK and EU each maintain their own adequacy decisions and transfer tool expectations. If you export data from both regions, treat the transfer package as jurisdiction specific work. - Keep separate UK and EU adequacy watch lists - Use UK IDTA or Addendum for UK restricted transfers - Use EU SCCs for EU exports where required - Record whether a vendor relationship carries UK data, EU data, or both *Recommended next step* *Placement: after the comparison section* ## Use UK GDPR UK vs EU Differences as a cited research workflow Research Copilot can take UK GDPR UK vs EU Differences from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on UK GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for UK GDPR UK vs EU Differences](/solutions/research-copilot.md): Start from UK GDPR UK vs EU Differences and answer scope, timing, and interpretation questions with cited outputs. - [Talk through UK GDPR](/contact.md): Review your current process, evidence gaps, and next steps for UK GDPR UK vs EU Differences. ## Regulator and legal update differences The ICO is the UK authority and publishes its own guidance. EU programmes still need to monitor EU supervisory authorities, EDPB positions, and European Commission activity. - Route UK complaints and incident issues to the ICO workflow - Track UK specific legislation and guidance updates separately from EU changes - Maintain notice language that names the correct authority and legal tools - Review whether internal templates cite UK or EU law correctly ## Programme design differences The simplest design is a shared baseline with explicit local overlays. Document the overlays once and make them reusable in notices, vendor contracts, rights playbooks, and product requirements. - Use one common control set for shared GDPR style obligations - Create UK specific overlays for transfers, regulator routing, and legislative supplements - Retain one evidence repository with jurisdiction tags - Review divergence after every major transfer, incident, or legal update ## Primary sources - [ICO international transfers guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/?ref=sorena.io) - Adequacy, IDTA, Addendum, and TRA guidance. - [ICO international data transfer agreement](https://ico.org.uk/media/for-organisations/documents/4019539/international-data-transfer-agreement.pdf?ref=sorena.io) - IDTA A1.0, in force March 21, 2022. - [ICO UK GDPR guidance and resources](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/?ref=sorena.io) - Primary ICO guidance hub. - [European Data Protection Board](https://www.edpb.europa.eu/?ref=sorena.io) - EU level regulator coordination source. ## Related Topic Guides - [IDTA vs EU SCCs | UK GDPR Transfer Tool Comparison](/artifacts/uk/uk-gdpr/idta-vs-eu-sccs.md): Compare the UK IDTA, UK Addendum, and EU standard contractual clauses for UK GDPR transfer compliance, contract selection, and transfer risk assessments. - [UK GDPR Applicability Test | Territorial Scope and Roles](/artifacts/uk/uk-gdpr/applicability-test.md): Assess UK GDPR territorial scope, controller or processor role, special category triggers, and UK transfer exposure with a defensible applicability test. - [UK GDPR Breach Notification | 72 Hour ICO Reporting Guide](/artifacts/uk/uk-gdpr/breach-notification.md): Operational guide to UK GDPR breach notification, including the 72 hour ICO deadline, processor escalation, breach logging. - [UK GDPR Checklist | Practical Compliance Checklist](/artifacts/uk/uk-gdpr/checklist.md): Practical UK GDPR checklist for accountability, lawful basis, Article 30 records, processor contracts, rights handling, transfers, and breach readiness. - [UK GDPR Children and Age Appropriate Design](/artifacts/uk/uk-gdpr/children-and-age-appropriate-design.md): Implement the UK Children's Code with grounded guidance on likely to be accessed tests, high privacy defaults, profiling limits, geolocation, age assurance. - [UK GDPR Compliance Program | Operating Model Guide](/artifacts/uk/uk-gdpr/compliance.md): Build a UK GDPR compliance program with accountability, Article 30 records, DPIAs, controller processor contracts, rights operations, transfer controls. - [UK GDPR Data Subject Rights | One Month Response Guide](/artifacts/uk/uk-gdpr/data-subject-rights.md): Operational guide to UK GDPR data subject rights, including access, rectification, erasure, restriction, portability, objection. - [UK GDPR Deadlines and Compliance Calendar](/artifacts/uk/uk-gdpr/deadlines-and-compliance-calendar.md): Calendar view of UK GDPR milestones, including January 1, 2021 applicability, March 2022 transfer tools, one month rights deadlines. - [UK GDPR FAQ | Practical Questions and Answers](/artifacts/uk/uk-gdpr/faq.md): Practical UK GDPR FAQ covering scope, lawful basis, rights timing, breach reporting, transfers, children, and enforcement exposure. - [UK GDPR Penalties and Fines | Enforcement Exposure Guide](/artifacts/uk/uk-gdpr/penalties-and-fines.md): Guide to UK GDPR penalties and fines, including the 17.5 million pounds or 4 percent upper tier, the 8.7 million pounds or 2 percent standard tier. - [UK GDPR Requirements | Control Level Requirements Guide](/artifacts/uk/uk-gdpr/requirements.md): Control level UK GDPR requirements covering principles, lawful basis, transparency, rights, Article 30 records, security, contracts, transfers, and DPIAs. - [UK GDPR Transfers, IDTA, and UK Addendum](/artifacts/uk/uk-gdpr/transfers-idta-and-uk-addendum.md): Detailed UK GDPR international transfers guide covering adequacy, UK IDTA, UK Addendum, transfer risk assessments, vendor governance, and UK bridge reliance. - [UK GDPR vs Data Protection Act 2018](/artifacts/uk/uk-gdpr/uk-gdpr-vs-data-protection-act-2018.md): Compare the UK GDPR and the Data Protection Act 2018, including what the UK GDPR does directly and where the DPA 2018 supplements, restricts, or extends it. - [UK GDPR vs EU GDPR | Practical Comparison](/artifacts/uk/uk-gdpr/uk-gdpr-vs-eu-gdpr.md): Practical comparison of the UK GDPR and EU GDPR, including scope, transfers, regulators, adequacy, and operational divergence for multinational programmes. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/uk/uk-gdpr/uk-vs-eu-differences --- --- title: "CCPA Applicability Test" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/applicability-test" source_url: "https://www.sorena.io/artifacts/us/ccpa/applicability-test" author: "Sorena AI" description: "Test whether a business is in scope under the current California threshold model." keywords: - "CCPA applicability test" - "CCPA thresholds" - "California privacy scope" - "CCPA business definition" - "CCPA" - "Applicability Test" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Applicability Test Test whether a business is in scope under the current California threshold model. *Applicability* *CCPA* ## California CCPA Applicability Test Grounded in the California statute, CPPA regulations, and current California enforcement themes. A defensible California scope memo should show both why the entity is a business and which threshold it meets, with calculations that can be rerun next year. ## Business status and threshold tests The main California thresholds are more than 25 million dollars in annual gross revenue, buying, selling, or sharing the personal information of 100,000 or more consumers or households, or deriving 50 percent or more of annual revenue from selling or sharing personal information. - Document which threshold is met and the evidence behind it - Use the finance source and counting method consistently - Measure consumers and households with a repeatable methodology - Check whether affiliates or common branding affect the analysis ## Exemptions and data context Even when the business is in scope, some data sets or regulated contexts may be exempt. Review exemptions carefully and write down exactly which data and workflows are carved out. - Map exemptions by dataset and processing purpose - Separate website tracking and marketing from sector specific exempt processing - Record whether the organisation acts as a business, service provider, contractor, or third party in each flow - Review whether employee or applicant data uses sit in a different California context ## Evidence and reassessment Scope decisions should be updated on a calendar and after trigger events such as acquisitions, new adtech, major volume growth, or entry into sharing relationships. - Keep a versioned scope register with approval history - Recalculate thresholds at least annually and after material business change - Link the scope memo to the data map and vendor inventory - Escalate threshold edge cases to legal and finance together *Recommended next step* *Placement: after the applicability result* ## Turn California CCPA Applicability Test into an operational assessment Assessment Autopilot can take California CCPA Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CCPA Applicability Test](/solutions/assessment.md): Start from California CCPA Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Applicability Test. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/applicability-test --- --- title: "CCPA Applicability Test" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/applicability-test" source_url: "https://www.sorena.io/artifacts/us/ccpa/applicability-test" author: "Sorena AI" description: "Test whether a business is in scope under the current California threshold model." keywords: - "CCPA applicability test" - "CCPA thresholds" - "California privacy scope" - "CCPA business definition" - "CCPA" - "Applicability Test" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Applicability Test Test whether a business is in scope under the current California threshold model. *Applicability* *CCPA* ## California CCPA Applicability Test Grounded in the California statute, CPPA regulations, and current California enforcement themes. A defensible California scope memo should show both why the entity is a business and which threshold it meets, with calculations that can be rerun next year. ## Business status and threshold tests The main California thresholds are more than 25 million dollars in annual gross revenue, buying, selling, or sharing the personal information of 100,000 or more consumers or households, or deriving 50 percent or more of annual revenue from selling or sharing personal information. - Document which threshold is met and the evidence behind it - Use the finance source and counting method consistently - Measure consumers and households with a repeatable methodology - Check whether affiliates or common branding affect the analysis ## Exemptions and data context Even when the business is in scope, some data sets or regulated contexts may be exempt. Review exemptions carefully and write down exactly which data and workflows are carved out. - Map exemptions by dataset and processing purpose - Separate website tracking and marketing from sector specific exempt processing - Record whether the organisation acts as a business, service provider, contractor, or third party in each flow - Review whether employee or applicant data uses sit in a different California context ## Evidence and reassessment Scope decisions should be updated on a calendar and after trigger events such as acquisitions, new adtech, major volume growth, or entry into sharing relationships. - Keep a versioned scope register with approval history - Recalculate thresholds at least annually and after material business change - Link the scope memo to the data map and vendor inventory - Escalate threshold edge cases to legal and finance together *Recommended next step* *Placement: after the applicability result* ## Turn California CCPA Applicability Test into an operational assessment Assessment Autopilot can take California CCPA Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CCPA Applicability Test](/solutions/assessment.md): Start from California CCPA Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Applicability Test. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/applicability-test --- --- title: "CCPA Privacy Policy Template" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/ccpa-privacy-policy-template" source_url: "https://www.sorena.io/artifacts/us/ccpa/ccpa-privacy-policy-template" author: "Sorena AI" description: "Write a California privacy policy that actually matches the statute and regulations." keywords: - "CCPA privacy policy template" - "California privacy policy" - "CCPA required disclosures" - "CCPA notice" - "CCPA" - "Privacy Policy Template" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Privacy Policy Template Write a California privacy policy that actually matches the statute and regulations. *Disclosures* *CCPA* ## California CCPA Privacy Policy Template Grounded in the California statute, CPPA regulations, and current California enforcement themes. The privacy policy is a control surface, not a branding page. California expects category level disclosures that let a consumer understand what you collect, why, with whom you disclose it, and what rights they can exercise. ## Mandatory content blocks A strong policy lists categories of personal information collected, categories of sources, business or commercial purposes, categories of third parties, and whether information was sold or shared in the preceding 12 months. - List each category of personal information in plain terms consumers can understand - Describe categories of sources such as consumers directly, ad networks, analytics providers, and data brokers - State categories of third parties and the purpose of selling, sharing, or disclosure - Explain each consumer right and how the request process works ## Content that is often missed The regulations expect operational detail, including how opt out preference signals are processed and whether the signal applies to a browser, device, account, or offline sharing context. - Explain how GPC or other opt out preference signals are handled - Describe verification practices for requests to know, delete, and correct - Include notice of financial incentive terms if incentives are offered - State the effective date and version so updates are easy to track ## Template governance The best template is populated from your data inventory and contract data, then reviewed after major product, vendor, or marketing changes. - Link every disclosure to the data map and a named owner - Review the policy after new tags, SDKs, or partners are introduced - Compare the policy against current rights metrics and notice at collection content - Retain prior versions and approval history *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep California CCPA Privacy Policy Template in one governed evidence system SSOT can take California CCPA Privacy Policy Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for California CCPA Privacy Policy Template](/solutions/ssot.md): Start from California CCPA Privacy Policy Template and keep documents, evidence, and control records in one governed system. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Privacy Policy Template. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/ccpa-privacy-policy-template --- --- title: "CCPA Privacy Policy Template" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/ccpa-privacy-policy-template" source_url: "https://www.sorena.io/artifacts/us/ccpa/ccpa-privacy-policy-template" author: "Sorena AI" description: "Write a California privacy policy that actually matches the statute and regulations." keywords: - "CCPA privacy policy template" - "California privacy policy" - "CCPA required disclosures" - "CCPA notice" - "CCPA" - "Privacy Policy Template" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Privacy Policy Template Write a California privacy policy that actually matches the statute and regulations. *Disclosures* *CCPA* ## California CCPA Privacy Policy Template Grounded in the California statute, CPPA regulations, and current California enforcement themes. The privacy policy is a control surface, not a branding page. California expects category level disclosures that let a consumer understand what you collect, why, with whom you disclose it, and what rights they can exercise. ## Mandatory content blocks A strong policy lists categories of personal information collected, categories of sources, business or commercial purposes, categories of third parties, and whether information was sold or shared in the preceding 12 months. - List each category of personal information in plain terms consumers can understand - Describe categories of sources such as consumers directly, ad networks, analytics providers, and data brokers - State categories of third parties and the purpose of selling, sharing, or disclosure - Explain each consumer right and how the request process works ## Content that is often missed The regulations expect operational detail, including how opt out preference signals are processed and whether the signal applies to a browser, device, account, or offline sharing context. - Explain how GPC or other opt out preference signals are handled - Describe verification practices for requests to know, delete, and correct - Include notice of financial incentive terms if incentives are offered - State the effective date and version so updates are easy to track ## Template governance The best template is populated from your data inventory and contract data, then reviewed after major product, vendor, or marketing changes. - Link every disclosure to the data map and a named owner - Review the policy after new tags, SDKs, or partners are introduced - Compare the policy against current rights metrics and notice at collection content - Retain prior versions and approval history *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep California CCPA Privacy Policy Template in one governed evidence system SSOT can take California CCPA Privacy Policy Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for California CCPA Privacy Policy Template](/solutions/ssot.md): Start from California CCPA Privacy Policy Template and keep documents, evidence, and control records in one governed system. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Privacy Policy Template. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/ccpa-privacy-policy-template --- --- title: "CCPA vs CPRA" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/ccpa-vs-cpra" source_url: "https://www.sorena.io/artifacts/us/ccpa/ccpa-vs-cpra" author: "Sorena AI" description: "Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work." keywords: - "CCPA vs CPRA" - "what changed under CPRA" - "California privacy amendments" - "CPRA changes" - "CCPA" - "vs CPRA" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA vs CPRA Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. *Comparison* *CCPA* ## California CCPA vs CPRA Grounded in the California statute, CPPA regulations, and current California enforcement themes. Many California privacy programmes still carry CCPA era assumptions from 2020 or 2021. The current regime is the CCPA as amended by the CPRA, and the operational differences are material. ## Rights and definitions that changed CPRA added the right to correct, created the right to limit certain uses of sensitive personal information, and expanded the concept of sharing for cross context behavioural advertising. - Update old rights portals so correction and limit flows are not missing - Replace opt out language that talks only about sale and ignores sharing - Review whether the old threshold analysis still uses the 50,000 figure - Refresh contract templates to include contractor and third party obligations ## Enforcement and governance changes CPRA created the California Privacy Protection Agency as a dedicated regulator and removed the guaranteed 30 day cure period. - Track CPPA rulemaking and not only Attorney General materials - Assume cure is discretionary and not a safe harbour - Keep enforcement evidence ready for requests, audits, or sweeps - Review old training that still describes the regulator structure inaccurately ## Why the distinction still matters Businesses still search for CCPA guidance and contracts still use CCPA terminology, but implementation work should be built to the current amended regime. - Treat the current law as one amended California privacy regime - Update policies, notices, and engineering tickets to current rights and definitions - Retire legacy references that ignore sharing, SPI, or the CPPA - Use the comparison page when cleaning up old privacy documentation *Recommended next step* *Placement: after the comparison section* ## Use California CCPA vs CPRA as a cited research workflow Research Copilot can take California CCPA vs CPRA from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CCPA vs CPRA](/solutions/research-copilot.md): Start from California CCPA vs CPRA and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA vs CPRA. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/ccpa-vs-cpra --- --- title: "CCPA vs CPRA" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/ccpa-vs-cpra" source_url: "https://www.sorena.io/artifacts/us/ccpa/ccpa-vs-cpra" author: "Sorena AI" description: "Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work." keywords: - "CCPA vs CPRA" - "what changed under CPRA" - "California privacy amendments" - "CPRA changes" - "CCPA" - "vs CPRA" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA vs CPRA Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. *Comparison* *CCPA* ## California CCPA vs CPRA Grounded in the California statute, CPPA regulations, and current California enforcement themes. Many California privacy programmes still carry CCPA era assumptions from 2020 or 2021. The current regime is the CCPA as amended by the CPRA, and the operational differences are material. ## Rights and definitions that changed CPRA added the right to correct, created the right to limit certain uses of sensitive personal information, and expanded the concept of sharing for cross context behavioural advertising. - Update old rights portals so correction and limit flows are not missing - Replace opt out language that talks only about sale and ignores sharing - Review whether the old threshold analysis still uses the 50,000 figure - Refresh contract templates to include contractor and third party obligations ## Enforcement and governance changes CPRA created the California Privacy Protection Agency as a dedicated regulator and removed the guaranteed 30 day cure period. - Track CPPA rulemaking and not only Attorney General materials - Assume cure is discretionary and not a safe harbour - Keep enforcement evidence ready for requests, audits, or sweeps - Review old training that still describes the regulator structure inaccurately ## Why the distinction still matters Businesses still search for CCPA guidance and contracts still use CCPA terminology, but implementation work should be built to the current amended regime. - Treat the current law as one amended California privacy regime - Update policies, notices, and engineering tickets to current rights and definitions - Retire legacy references that ignore sharing, SPI, or the CPPA - Use the comparison page when cleaning up old privacy documentation *Recommended next step* *Placement: after the comparison section* ## Use California CCPA vs CPRA as a cited research workflow Research Copilot can take California CCPA vs CPRA from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CCPA vs CPRA](/solutions/research-copilot.md): Start from California CCPA vs CPRA and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA vs CPRA. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/ccpa-vs-cpra --- --- title: "CCPA vs GDPR" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/ccpa-vs-gdpr" source_url: "https://www.sorena.io/artifacts/us/ccpa/ccpa-vs-gdpr" author: "Sorena AI" description: "Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable." keywords: - "CCPA vs GDPR" - "California privacy vs GDPR" - "CCPA GDPR differences" - "CCPA comparison" - "CCPA" - "vs GDPR" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA vs GDPR Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. *Comparison* *CCPA* ## California CCPA vs GDPR Grounded in the California statute, CPPA regulations, and current California enforcement themes. A team that knows GDPR will recognise many themes in California privacy, but the California approach remains threshold based, disclosure heavy, and opt out oriented in ways that require separate design choices. ## Different legal architecture The GDPR applies broadly to covered processing and requires a lawful basis for each activity. The California law applies to businesses that meet specific thresholds and focuses on disclosures, rights, and the ability to opt out of sale or sharing. - Use GDPR style data mapping and control ownership as a foundation - Do not assume a lawful basis analysis replaces California notice and opt out work - Keep separate California scope and threshold evidence - Design separate California consumer interfaces where required ## Rights, vendors, and transfers Processor agreements help in both regimes, but California service provider, contractor, and third party contracts have their own required clauses and due diligence expectations. - Use separate contract riders for California service provider and third party restrictions - Honor GPC and California opt out rules even if the global privacy centre was built for GDPR requests - Do not import GDPR transfer rules into California unless another law requires them - Keep a combined but jurisdiction tagged rights workflow ## Practical programme strategy The most efficient approach is one privacy operating model with distinct branches for threshold logic, legal basis, transfer rules, and consumer interfaces. - Reuse governance, security, and inventory layers across regimes - Separate California notices, opt out flows, and vendor clauses - Track which issues are GDPR only, California only, or both - Train teams on the differences before reusing templates across jurisdictions *Recommended next step* *Placement: after the comparison section* ## Use California CCPA vs GDPR as a cited research workflow Research Copilot can take California CCPA vs GDPR from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CCPA vs GDPR](/solutions/research-copilot.md): Start from California CCPA vs GDPR and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA vs GDPR. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/ccpa-vs-gdpr --- --- title: "CCPA vs GDPR" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/ccpa-vs-gdpr" source_url: "https://www.sorena.io/artifacts/us/ccpa/ccpa-vs-gdpr" author: "Sorena AI" description: "Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable." keywords: - "CCPA vs GDPR" - "California privacy vs GDPR" - "CCPA GDPR differences" - "CCPA comparison" - "CCPA" - "vs GDPR" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA vs GDPR Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. *Comparison* *CCPA* ## California CCPA vs GDPR Grounded in the California statute, CPPA regulations, and current California enforcement themes. A team that knows GDPR will recognise many themes in California privacy, but the California approach remains threshold based, disclosure heavy, and opt out oriented in ways that require separate design choices. ## Different legal architecture The GDPR applies broadly to covered processing and requires a lawful basis for each activity. The California law applies to businesses that meet specific thresholds and focuses on disclosures, rights, and the ability to opt out of sale or sharing. - Use GDPR style data mapping and control ownership as a foundation - Do not assume a lawful basis analysis replaces California notice and opt out work - Keep separate California scope and threshold evidence - Design separate California consumer interfaces where required ## Rights, vendors, and transfers Processor agreements help in both regimes, but California service provider, contractor, and third party contracts have their own required clauses and due diligence expectations. - Use separate contract riders for California service provider and third party restrictions - Honor GPC and California opt out rules even if the global privacy centre was built for GDPR requests - Do not import GDPR transfer rules into California unless another law requires them - Keep a combined but jurisdiction tagged rights workflow ## Practical programme strategy The most efficient approach is one privacy operating model with distinct branches for threshold logic, legal basis, transfer rules, and consumer interfaces. - Reuse governance, security, and inventory layers across regimes - Separate California notices, opt out flows, and vendor clauses - Track which issues are GDPR only, California only, or both - Train teams on the differences before reusing templates across jurisdictions *Recommended next step* *Placement: after the comparison section* ## Use California CCPA vs GDPR as a cited research workflow Research Copilot can take California CCPA vs GDPR from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CCPA vs GDPR](/solutions/research-copilot.md): Start from California CCPA vs GDPR and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA vs GDPR. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/ccpa-vs-gdpr --- --- title: "CCPA Checklist" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/checklist" source_url: "https://www.sorena.io/artifacts/us/ccpa/checklist" author: "Sorena AI" description: "Track the California controls that must actually exist in policy, product, and vendor operations." keywords: - "CCPA checklist" - "California privacy checklist" - "do not sell or share checklist" - "CCPA compliance checklist" - "CCPA" - "Checklist" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Checklist Track the California controls that must actually exist in policy, product, and vendor operations. *Checklist* *CCPA* ## California CCPA Checklist Grounded in the California statute, CPPA regulations, and current California enforcement themes. California compliance breaks when notices, request handling, opt out logic, and vendor contracts evolve separately. Use one checklist with owners and proof. ## Scope and notice controls Start with a threshold decision, then make sure every consumer facing disclosure reflects the real data map and the current California rules effective January 1, 2026. - Confirm in scope status and record the threshold calculation - Publish notice at collection where information is collected - Update the privacy policy with categories, purposes, rights, and sales or sharing disclosures - Review financial incentive disclosures if loyalty or data value exchange programmes exist ## Rights and opt out controls Rights handling and opt out controls should be tested together because California consumers move between those pathways and the regulations expect consistency. - Provide designated methods for requests and track the 45 day response clock - Honor GPC as a valid request to opt out of sale or sharing - Ensure the do not sell or share interface is symmetrical and not manipulative - Keep request records and response metrics for at least 24 months ## Contracts and evidence Contract terms, due diligence, and audit rights matter because California rules look beyond the paper and ask whether the business had reason to believe a vendor was misusing information. - Re paper service provider, contractor, and third party agreements - Track vendor due diligence and remediation rights exercised in practice - Retain training, request logs, policy versions, and testing results - Prepare an enforcement pack for agency requests or sweeps *Recommended next step* *Placement: after the checklist block* ## Turn California CCPA Checklist into an operational assessment Assessment Autopilot can take California CCPA Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CCPA Checklist](/solutions/assessment.md): Start from California CCPA Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Checklist. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/checklist --- --- title: "CCPA Checklist" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/checklist" source_url: "https://www.sorena.io/artifacts/us/ccpa/checklist" author: "Sorena AI" description: "Track the California controls that must actually exist in policy, product, and vendor operations." keywords: - "CCPA checklist" - "California privacy checklist" - "do not sell or share checklist" - "CCPA compliance checklist" - "CCPA" - "Checklist" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Checklist Track the California controls that must actually exist in policy, product, and vendor operations. *Checklist* *CCPA* ## California CCPA Checklist Grounded in the California statute, CPPA regulations, and current California enforcement themes. California compliance breaks when notices, request handling, opt out logic, and vendor contracts evolve separately. Use one checklist with owners and proof. ## Scope and notice controls Start with a threshold decision, then make sure every consumer facing disclosure reflects the real data map and the current California rules effective January 1, 2026. - Confirm in scope status and record the threshold calculation - Publish notice at collection where information is collected - Update the privacy policy with categories, purposes, rights, and sales or sharing disclosures - Review financial incentive disclosures if loyalty or data value exchange programmes exist ## Rights and opt out controls Rights handling and opt out controls should be tested together because California consumers move between those pathways and the regulations expect consistency. - Provide designated methods for requests and track the 45 day response clock - Honor GPC as a valid request to opt out of sale or sharing - Ensure the do not sell or share interface is symmetrical and not manipulative - Keep request records and response metrics for at least 24 months ## Contracts and evidence Contract terms, due diligence, and audit rights matter because California rules look beyond the paper and ask whether the business had reason to believe a vendor was misusing information. - Re paper service provider, contractor, and third party agreements - Track vendor due diligence and remediation rights exercised in practice - Retain training, request logs, policy versions, and testing results - Prepare an enforcement pack for agency requests or sweeps *Recommended next step* *Placement: after the checklist block* ## Turn California CCPA Checklist into an operational assessment Assessment Autopilot can take California CCPA Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CCPA Checklist](/solutions/assessment.md): Start from California CCPA Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Checklist. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/checklist --- --- title: "CCPA Compliance Program" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/compliance" source_url: "https://www.sorena.io/artifacts/us/ccpa/compliance" author: "Sorena AI" description: "Build a California privacy programme that survives regulator questions and product change." keywords: - "CCPA compliance program" - "California privacy operating model" - "CCPA governance" - "CCPA control framework" - "CCPA" - "Compliance Program" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Compliance Program Build a California privacy programme that survives regulator questions and product change. *Operating Model* *CCPA* ## California CCPA Compliance Program Grounded in the California statute, CPPA regulations, and current California enforcement themes. California compliance is easiest to sustain when the data map, notice content, request pipeline, and vendor governance all run from the same facts and owners. ## Programme foundation Use a single California data inventory that lists categories, sources, purposes, recipients, retention approach, and whether sale, sharing, or disclosure for business purpose occurs. - Assign owners for notices, request intake, GPC, vendor governance, and security - Link category level data inventory to every required disclosure - Record where sales, sharing, or advertising disclosures happen in practice - Set an annual and event driven review cadence ## Execution workstreams The programme should have named workstreams for rights, opt out, and vendor governance rather than a single generic privacy task list. - Run 45 day request workflows with identity verification and exception handling - Honor GPC and do not sell or share choices across websites, apps, and partner pipelines - Maintain service provider, contractor, and third party contract terms - Retain 24 month request records and programme evidence ## Testing and improvement A California programme should be tested like a consumer journey. If a request, opt out, or notice does not work end to end, the policy text will not save it. - Test notice at collection and privacy policy accuracy after data map changes - Run opt out and GPC regression tests after tag or partner updates - Review request quality metrics, backlog, and denials monthly - Track regulator updates and enforcement themes from the CPPA *Recommended next step* *Placement: after the compliance steps* ## Turn California CCPA Compliance Program into an operational assessment Assessment Autopilot can take California CCPA Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CCPA Compliance Program](/solutions/assessment.md): Start from California CCPA Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Compliance Program. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/compliance --- --- title: "CCPA Compliance Program" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/compliance" source_url: "https://www.sorena.io/artifacts/us/ccpa/compliance" author: "Sorena AI" description: "Build a California privacy programme that survives regulator questions and product change." keywords: - "CCPA compliance program" - "California privacy operating model" - "CCPA governance" - "CCPA control framework" - "CCPA" - "Compliance Program" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Compliance Program Build a California privacy programme that survives regulator questions and product change. *Operating Model* *CCPA* ## California CCPA Compliance Program Grounded in the California statute, CPPA regulations, and current California enforcement themes. California compliance is easiest to sustain when the data map, notice content, request pipeline, and vendor governance all run from the same facts and owners. ## Programme foundation Use a single California data inventory that lists categories, sources, purposes, recipients, retention approach, and whether sale, sharing, or disclosure for business purpose occurs. - Assign owners for notices, request intake, GPC, vendor governance, and security - Link category level data inventory to every required disclosure - Record where sales, sharing, or advertising disclosures happen in practice - Set an annual and event driven review cadence ## Execution workstreams The programme should have named workstreams for rights, opt out, and vendor governance rather than a single generic privacy task list. - Run 45 day request workflows with identity verification and exception handling - Honor GPC and do not sell or share choices across websites, apps, and partner pipelines - Maintain service provider, contractor, and third party contract terms - Retain 24 month request records and programme evidence ## Testing and improvement A California programme should be tested like a consumer journey. If a request, opt out, or notice does not work end to end, the policy text will not save it. - Test notice at collection and privacy policy accuracy after data map changes - Run opt out and GPC regression tests after tag or partner updates - Review request quality metrics, backlog, and denials monthly - Track regulator updates and enforcement themes from the CPPA *Recommended next step* *Placement: after the compliance steps* ## Turn California CCPA Compliance Program into an operational assessment Assessment Autopilot can take California CCPA Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CCPA Compliance Program](/solutions/assessment.md): Start from California CCPA Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Compliance Program. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/compliance --- --- title: "CCPA Consumer Rights Workflow" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/consumer-rights-workflow" source_url: "https://www.sorena.io/artifacts/us/ccpa/consumer-rights-workflow" author: "Sorena AI" description: "Run California rights operations with clear timing, verification, and downstream instructions." keywords: - "CCPA consumer rights workflow" - "CCPA 45 day response" - "California deletion request" - "California know request" - "CCPA" - "Consumer Rights Workflow" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Consumer Rights Workflow Run California rights operations with clear timing, verification, and downstream instructions. *Consumer Rights* *CCPA* ## California CCPA Consumer Rights Workflow Grounded in the California statute, CPPA regulations, and current California enforcement themes. California request handling works best when each right is treated as a specific workflow with its own timing, verification, and downstream propagation rules. ## Request intake and clock start Set designated methods to submit requests and confirm who owns the first review. Most substantive responses are due within 45 days, with one 45 day extension where reasonably necessary. - Classify requests to know, delete, correct, opt out, and limit where applicable - Start the 45 day clock when a valid request is received and routed - Use extension notices only when justified - Accept authorised agents with the evidence the regulations require ## Verification and search Verification must be reasonable and proportionate to the sensitivity of the data and the harm of a mistake. Requests to opt out of sale or sharing should be processed without forcing identity verification. - Use account authentication where possible - Avoid collecting more data than necessary for verification - Search systems, archives, and contracted service providers consistently - Delete new verification data as soon as practical after the request is processed ## Response, downstream instructions, and recordkeeping A California rights workflow should push deletion, correction, or opt out instructions to service providers, contractors, and third parties where the law or contract requires it. - Record deletion exceptions and what data was kept - Forward opt out and deletion instructions to downstream parties where required - Retain request logs, dates, and response outcomes for 24 months - Measure cycle time, denial reasons, and repeat requests *Recommended next step* *Placement: after the scope or definition section* ## Use California CCPA Consumer Rights Workflow as a cited research workflow Research Copilot can take California CCPA Consumer Rights Workflow from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CCPA Consumer Rights Workflow](/solutions/research-copilot.md): Start from California CCPA Consumer Rights Workflow and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Consumer Rights Workflow. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/consumer-rights-workflow --- --- title: "CCPA Consumer Rights Workflow" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/consumer-rights-workflow" source_url: "https://www.sorena.io/artifacts/us/ccpa/consumer-rights-workflow" author: "Sorena AI" description: "Run California rights operations with clear timing, verification, and downstream instructions." keywords: - "CCPA consumer rights workflow" - "CCPA 45 day response" - "California deletion request" - "California know request" - "CCPA" - "Consumer Rights Workflow" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Consumer Rights Workflow Run California rights operations with clear timing, verification, and downstream instructions. *Consumer Rights* *CCPA* ## California CCPA Consumer Rights Workflow Grounded in the California statute, CPPA regulations, and current California enforcement themes. California request handling works best when each right is treated as a specific workflow with its own timing, verification, and downstream propagation rules. ## Request intake and clock start Set designated methods to submit requests and confirm who owns the first review. Most substantive responses are due within 45 days, with one 45 day extension where reasonably necessary. - Classify requests to know, delete, correct, opt out, and limit where applicable - Start the 45 day clock when a valid request is received and routed - Use extension notices only when justified - Accept authorised agents with the evidence the regulations require ## Verification and search Verification must be reasonable and proportionate to the sensitivity of the data and the harm of a mistake. Requests to opt out of sale or sharing should be processed without forcing identity verification. - Use account authentication where possible - Avoid collecting more data than necessary for verification - Search systems, archives, and contracted service providers consistently - Delete new verification data as soon as practical after the request is processed ## Response, downstream instructions, and recordkeeping A California rights workflow should push deletion, correction, or opt out instructions to service providers, contractors, and third parties where the law or contract requires it. - Record deletion exceptions and what data was kept - Forward opt out and deletion instructions to downstream parties where required - Retain request logs, dates, and response outcomes for 24 months - Measure cycle time, denial reasons, and repeat requests *Recommended next step* *Placement: after the scope or definition section* ## Use California CCPA Consumer Rights Workflow as a cited research workflow Research Copilot can take California CCPA Consumer Rights Workflow from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CCPA Consumer Rights Workflow](/solutions/research-copilot.md): Start from California CCPA Consumer Rights Workflow and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Consumer Rights Workflow. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/consumer-rights-workflow --- --- title: "CCPA Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/us/ccpa/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Use the dates that actually shape California privacy work." keywords: - "CCPA deadlines" - "CCPA calendar" - "CPRA timeline" - "California privacy timeline" - "CCPA" - "Deadlines and Compliance Calendar" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Deadlines and Compliance Calendar Use the dates that actually shape California privacy work. *Calendar* *CCPA* ## California CCPA Deadlines and Compliance Calendar Grounded in the California statute, CPPA regulations, and current California enforcement themes. California privacy programmes need both legal milestone dates and recurring operational deadlines. One without the other does not keep the programme current. ## Core California milestones The original CCPA took effect on January 1, 2020. The CPRA amendments became operative on January 1, 2023 and CPPA enforcement began on July 1, 2023. The current rule set was updated again with regulations effective January 1, 2026. - January 1, 2020: original CCPA commencement - January 1, 2023: CPRA amendments operative - July 1, 2023: CPPA administrative enforcement begins - January 1, 2026: current updated regulations take effect *Recommended next step* *Placement: after the timeline or milestone section* ## Turn California CCPA Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take California CCPA Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CCPA Deadlines and Compliance Calendar](/solutions/assessment.md): Start from California CCPA Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Deadlines and Compliance Calendar. ## Recurring operational deadlines Most California pressure comes from rights timing and programme maintenance rather than from commencement anniversaries. - 45 days to respond to most consumer requests, with one 45 day extension where justified - Keep consumer request records and related process evidence for at least 24 months - Review privacy policy and notice at collection content after material data map changes - Retest GPC and do not sell or share flows after adtech or vendor changes ## Planning for newer obligations If the business is likely to fall into newer California cybersecurity audit or risk assessment rules, add forward looking dates now rather than waiting for the threshold year to pass. - Track whether risk assessment or cybersecurity audit triggers will apply in 2026 or 2027 - Watch the April 1 reporting cycle for the first newer California submissions where applicable - Plan annual January data broker registration if the business qualifies as a data broker - Tie board level privacy review to the yearly regulatory update cycle ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/deadlines-and-compliance-calendar --- --- title: "CCPA Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/us/ccpa/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Use the dates that actually shape California privacy work." keywords: - "CCPA deadlines" - "CCPA calendar" - "CPRA timeline" - "California privacy timeline" - "CCPA" - "Deadlines and Compliance Calendar" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Deadlines and Compliance Calendar Use the dates that actually shape California privacy work. *Calendar* *CCPA* ## California CCPA Deadlines and Compliance Calendar Grounded in the California statute, CPPA regulations, and current California enforcement themes. California privacy programmes need both legal milestone dates and recurring operational deadlines. One without the other does not keep the programme current. ## Core California milestones The original CCPA took effect on January 1, 2020. The CPRA amendments became operative on January 1, 2023 and CPPA enforcement began on July 1, 2023. The current rule set was updated again with regulations effective January 1, 2026. - January 1, 2020: original CCPA commencement - January 1, 2023: CPRA amendments operative - July 1, 2023: CPPA administrative enforcement begins - January 1, 2026: current updated regulations take effect *Recommended next step* *Placement: after the timeline or milestone section* ## Turn California CCPA Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take California CCPA Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CCPA Deadlines and Compliance Calendar](/solutions/assessment.md): Start from California CCPA Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Deadlines and Compliance Calendar. ## Recurring operational deadlines Most California pressure comes from rights timing and programme maintenance rather than from commencement anniversaries. - 45 days to respond to most consumer requests, with one 45 day extension where justified - Keep consumer request records and related process evidence for at least 24 months - Review privacy policy and notice at collection content after material data map changes - Retest GPC and do not sell or share flows after adtech or vendor changes ## Planning for newer obligations If the business is likely to fall into newer California cybersecurity audit or risk assessment rules, add forward looking dates now rather than waiting for the threshold year to pass. - Track whether risk assessment or cybersecurity audit triggers will apply in 2026 or 2027 - Watch the April 1 reporting cycle for the first newer California submissions where applicable - Plan annual January data broker registration if the business qualifies as a data broker - Tie board level privacy review to the yearly regulatory update cycle ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/deadlines-and-compliance-calendar --- --- title: "Do Not Sell or Share Implementation" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/do-not-sell-share-implementation" source_url: "https://www.sorena.io/artifacts/us/ccpa/do-not-sell-share-implementation" author: "Sorena AI" description: "Implement California opt out controls that actually work across websites, apps, and partner pipelines." keywords: - "do not sell or share implementation" - "Global Privacy Control implementation" - "CCPA GPC" - "California opt out controls" - "CCPA" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Do Not Sell or Share Implementation Implement California opt out controls that actually work across websites, apps, and partner pipelines. *Opt Out Controls* *CCPA* ## California CCPA Do Not Sell or Share Implementation Grounded in the California statute, CPPA regulations, and current California enforcement themes. California opt out implementation is an end to end system. The visible link is only the start. The harder work is how preferences are enforced across adtech, audience exports, customer profiles, and downstream partners. ## Consumer interface and choice architecture The interface must be easy to find and must not use manipulative or asymmetrical choice design. The regulations call out patterns that make opting out harder than opting in. - Provide a prominent do not sell or share link or a permitted alternative design - Make the opt out path symmetrical and no more burdensome than opt in paths - Avoid disruptive screens, hidden toggles, or bundled choices - Describe the flow clearly in the privacy policy and notice of right to opt out ## GPC and signal enforcement The business must treat an opt out preference signal such as GPC as a valid request to opt out of sale or sharing for the browser or device and associated pseudonymous profiles in the contexts the regulations describe. - Detect and process the Sec GPC signal or equivalent browser state - Apply the preference to browser, device, and linked profiles as required - Do not require identity verification to process the opt out signal - Propagate the opt out to partners, suppression lists, and audience systems ## Monitoring and downstream control A California opt out programme should confirm that suppression reaches every sale or sharing path and that vendors actually comply when the business forwards the request. - Run regression tests after tag, SDK, and vendor changes - Retain evidence of partner suppression and forwarded requests - Watch for reintroduction of sharing through new marketing tools - Log defects and remediation so the control improves over time *Recommended next step* *Placement: near the end of the main content before related guides* ## Turn California CCPA Do Not Sell or Share Implementation into an operational assessment Assessment Autopilot can take California CCPA Do Not Sell or Share Implementation from turning this guidance into an operational assessment workflow to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CCPA Do Not Sell or Share Implementation](/solutions/assessment.md): Start from California CCPA Do Not Sell or Share Implementation and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Do Not Sell or Share Implementation. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/do-not-sell-share-implementation --- --- title: "Do Not Sell or Share Implementation" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/do-not-sell-share-implementation" source_url: "https://www.sorena.io/artifacts/us/ccpa/do-not-sell-share-implementation" author: "Sorena AI" description: "Implement California opt out controls that actually work across websites, apps, and partner pipelines." keywords: - "do not sell or share implementation" - "Global Privacy Control implementation" - "CCPA GPC" - "California opt out controls" - "CCPA" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # Do Not Sell or Share Implementation Implement California opt out controls that actually work across websites, apps, and partner pipelines. *Opt Out Controls* *CCPA* ## California CCPA Do Not Sell or Share Implementation Grounded in the California statute, CPPA regulations, and current California enforcement themes. California opt out implementation is an end to end system. The visible link is only the start. The harder work is how preferences are enforced across adtech, audience exports, customer profiles, and downstream partners. ## Consumer interface and choice architecture The interface must be easy to find and must not use manipulative or asymmetrical choice design. The regulations call out patterns that make opting out harder than opting in. - Provide a prominent do not sell or share link or a permitted alternative design - Make the opt out path symmetrical and no more burdensome than opt in paths - Avoid disruptive screens, hidden toggles, or bundled choices - Describe the flow clearly in the privacy policy and notice of right to opt out ## GPC and signal enforcement The business must treat an opt out preference signal such as GPC as a valid request to opt out of sale or sharing for the browser or device and associated pseudonymous profiles in the contexts the regulations describe. - Detect and process the Sec GPC signal or equivalent browser state - Apply the preference to browser, device, and linked profiles as required - Do not require identity verification to process the opt out signal - Propagate the opt out to partners, suppression lists, and audience systems ## Monitoring and downstream control A California opt out programme should confirm that suppression reaches every sale or sharing path and that vendors actually comply when the business forwards the request. - Run regression tests after tag, SDK, and vendor changes - Retain evidence of partner suppression and forwarded requests - Watch for reintroduction of sharing through new marketing tools - Log defects and remediation so the control improves over time *Recommended next step* *Placement: near the end of the main content before related guides* ## Turn California CCPA Do Not Sell or Share Implementation into an operational assessment Assessment Autopilot can take California CCPA Do Not Sell or Share Implementation from turning this guidance into an operational assessment workflow to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CCPA Do Not Sell or Share Implementation](/solutions/assessment.md): Start from California CCPA Do Not Sell or Share Implementation and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Do Not Sell or Share Implementation. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/do-not-sell-share-implementation --- --- title: "CCPA Enforcement and Penalties" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/enforcement-and-penalties" source_url: "https://www.sorena.io/artifacts/us/ccpa/enforcement-and-penalties" author: "Sorena AI" description: "Understand how California enforcement usually starts and what evidence the agency will ask for." keywords: - "CCPA enforcement" - "CPPA penalties" - "California privacy enforcement" - "CCPA investigations" - "CCPA" - "Enforcement and Penalties" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Enforcement and Penalties Understand how California enforcement usually starts and what evidence the agency will ask for. *Enforcement* *CCPA* ## California CCPA Enforcement and Penalties Grounded in the California statute, CPPA regulations, and current California enforcement themes. California privacy enforcement is now a mature regulator workflow. It is no longer enough to wait for a complaint and hope to cure the issue quietly. ## Who enforces and how The CPPA can bring administrative enforcement actions and the Attorney General retains civil enforcement authority. The regulations also give the agency audit powers over businesses, service providers, contractors, and other persons covered by the law. - Track which parts of the programme the CPPA can test directly - Retain policies, logs, contracts, request records, and test evidence in one retrievable place - Treat regulatory correspondence as a board visible issue - Review public orders and advisories for new control expectations ## Penalty exposure and private claims California civil penalties can reach 2,500 dollars per violation or 7,500 dollars per intentional violation or violation involving minors under 16. Separate statutory damages may apply in private actions tied to certain security incidents. - Quantify per violation exposure for widespread notice or request failures - Treat child data as a higher enforcement risk area - Keep reasonable security evidence because private claims focus on security lapses - Do not rely on a cure strategy as the primary risk control ## Current enforcement themes Current California enforcement themes include weak GPC handling, misleading opt out flows, inaccurate notice claims, and poor contract governance with advertising and data sharing partners. - Retest GPC and opt out flows after every adtech or consent tool change - Review privacy claims for accuracy, not only readability - Exercise contract oversight rights instead of relying only on signature status - Use complaint and request trends to identify regulator visible defects early *Recommended next step* *Placement: after the enforcement section* ## Use California CCPA Enforcement and Penalties as a cited research workflow Research Copilot can take California CCPA Enforcement and Penalties from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CCPA Enforcement and Penalties](/solutions/research-copilot.md): Start from California CCPA Enforcement and Penalties and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Enforcement and Penalties. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/enforcement-and-penalties --- --- title: "CCPA Enforcement and Penalties" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/enforcement-and-penalties" source_url: "https://www.sorena.io/artifacts/us/ccpa/enforcement-and-penalties" author: "Sorena AI" description: "Understand how California enforcement usually starts and what evidence the agency will ask for." keywords: - "CCPA enforcement" - "CPPA penalties" - "California privacy enforcement" - "CCPA investigations" - "CCPA" - "Enforcement and Penalties" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Enforcement and Penalties Understand how California enforcement usually starts and what evidence the agency will ask for. *Enforcement* *CCPA* ## California CCPA Enforcement and Penalties Grounded in the California statute, CPPA regulations, and current California enforcement themes. California privacy enforcement is now a mature regulator workflow. It is no longer enough to wait for a complaint and hope to cure the issue quietly. ## Who enforces and how The CPPA can bring administrative enforcement actions and the Attorney General retains civil enforcement authority. The regulations also give the agency audit powers over businesses, service providers, contractors, and other persons covered by the law. - Track which parts of the programme the CPPA can test directly - Retain policies, logs, contracts, request records, and test evidence in one retrievable place - Treat regulatory correspondence as a board visible issue - Review public orders and advisories for new control expectations ## Penalty exposure and private claims California civil penalties can reach 2,500 dollars per violation or 7,500 dollars per intentional violation or violation involving minors under 16. Separate statutory damages may apply in private actions tied to certain security incidents. - Quantify per violation exposure for widespread notice or request failures - Treat child data as a higher enforcement risk area - Keep reasonable security evidence because private claims focus on security lapses - Do not rely on a cure strategy as the primary risk control ## Current enforcement themes Current California enforcement themes include weak GPC handling, misleading opt out flows, inaccurate notice claims, and poor contract governance with advertising and data sharing partners. - Retest GPC and opt out flows after every adtech or consent tool change - Review privacy claims for accuracy, not only readability - Exercise contract oversight rights instead of relying only on signature status - Use complaint and request trends to identify regulator visible defects early *Recommended next step* *Placement: after the enforcement section* ## Use California CCPA Enforcement and Penalties as a cited research workflow Research Copilot can take California CCPA Enforcement and Penalties from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CCPA Enforcement and Penalties](/solutions/research-copilot.md): Start from California CCPA Enforcement and Penalties and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Enforcement and Penalties. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/enforcement-and-penalties --- --- title: "CCPA FAQ" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/faq" source_url: "https://www.sorena.io/artifacts/us/ccpa/faq" author: "Sorena AI" description: "Answer the California privacy questions that usually stall implementation." keywords: - "CCPA FAQ" - "California privacy FAQ" - "GPC FAQ" - "do not sell or share questions" - "CCPA" - "FAQ" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA FAQ Answer the California privacy questions that usually stall implementation. *FAQ* *CCPA* ## California CCPA FAQ Grounded in the California statute, CPPA regulations, and current California enforcement themes. California privacy projects often stall on a small number of recurring questions. The safest approach is to answer them once, document the reasoning, and reuse the result consistently. ## Scope and threshold questions Frequent questions include whether a company is a business, how the 100,000 consumer or household threshold is measured, and when exemptions actually apply. - Which threshold is met and with what calculation method - Whether any affiliate relationship affects business status - Which data sets are exempt and which are not - How the scope decision will be reviewed next year ## Rights and opt out questions Teams often ask when identity verification is needed, how GPC works, whether a business must keep a do not sell or share link when GPC is supported, and how quickly downstream parties must be instructed. - Requests to opt out of sale or sharing should not require identity verification - GPC should be treated as a valid opt out preference signal - The rights process must distinguish delete, correct, know, and opt out flows - Request handling records should be kept for at least 24 months ## Vendor and enforcement questions Another common question is whether signing the right contract is enough to claim service provider or contractor status. The regulations say no. Due diligence and the right to stop and remediate misuse matter too. - Contract signatures are necessary but not sufficient - Businesses should explain how they monitor vendor compliance - Notice accuracy and GPC handling remain key enforcement themes - The current California rule set should be treated as the live baseline *Recommended next step* *Placement: after the FAQ section* ## Use California CCPA FAQ as a cited research workflow Research Copilot can take California CCPA FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CCPA FAQ](/solutions/research-copilot.md): Start from California CCPA FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA FAQ. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/faq --- --- title: "CCPA FAQ" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/faq" source_url: "https://www.sorena.io/artifacts/us/ccpa/faq" author: "Sorena AI" description: "Answer the California privacy questions that usually stall implementation." keywords: - "CCPA FAQ" - "California privacy FAQ" - "GPC FAQ" - "do not sell or share questions" - "CCPA" - "FAQ" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA FAQ Answer the California privacy questions that usually stall implementation. *FAQ* *CCPA* ## California CCPA FAQ Grounded in the California statute, CPPA regulations, and current California enforcement themes. California privacy projects often stall on a small number of recurring questions. The safest approach is to answer them once, document the reasoning, and reuse the result consistently. ## Scope and threshold questions Frequent questions include whether a company is a business, how the 100,000 consumer or household threshold is measured, and when exemptions actually apply. - Which threshold is met and with what calculation method - Whether any affiliate relationship affects business status - Which data sets are exempt and which are not - How the scope decision will be reviewed next year ## Rights and opt out questions Teams often ask when identity verification is needed, how GPC works, whether a business must keep a do not sell or share link when GPC is supported, and how quickly downstream parties must be instructed. - Requests to opt out of sale or sharing should not require identity verification - GPC should be treated as a valid opt out preference signal - The rights process must distinguish delete, correct, know, and opt out flows - Request handling records should be kept for at least 24 months ## Vendor and enforcement questions Another common question is whether signing the right contract is enough to claim service provider or contractor status. The regulations say no. Due diligence and the right to stop and remediate misuse matter too. - Contract signatures are necessary but not sufficient - Businesses should explain how they monitor vendor compliance - Notice accuracy and GPC handling remain key enforcement themes - The current California rule set should be treated as the live baseline *Recommended next step* *Placement: after the FAQ section* ## Use California CCPA FAQ as a cited research workflow Research Copilot can take California CCPA FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CCPA FAQ](/solutions/research-copilot.md): Start from California CCPA FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA FAQ. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/faq --- --- title: "CCPA Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/us/ccpa/penalties-and-fines" author: "Sorena AI" description: "Know the penalty ranges, then work backward to the controls that reduce them." keywords: - "CCPA penalties" - "CCPA fines" - "California privacy fines" - "CCPA private right of action" - "CCPA" - "Penalties and Fines" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Penalties and Fines Know the penalty ranges, then work backward to the controls that reduce them. *Penalties* *CCPA* ## California CCPA Penalties and Fines Grounded in the California statute, CPPA regulations, and current California enforcement themes. California penalty exposure is best understood as a function of scale and proof. Repeated failures in notices, opt out handling, or vendor governance can multiply quickly. ## Civil penalty framework California penalties can reach 2,500 dollars per violation or 7,500 dollars per intentional violation or violation involving minors under 16. - Count risk by affected consumers, affected interactions, and duration - Treat youth data and opt in rules as a higher consequence area - Retain proof that policies, notices, and controls matched practice at the time - Assume missing logs or stale notices will worsen the outcome ## Security breach exposure California also allows a private action for certain data breaches involving nonencrypted or nonredacted personal information where reasonable security was lacking. - Maintain reasonable security evidence and testing history - Track incident response, root cause analysis, and remediation proof - Link vendor security obligations to contract and oversight evidence - Review whether notice claims about security match technical reality ## How to reduce exposure The most effective penalty reduction work is usually operational: accurate notices, good request handling, fast defect correction, and real vendor oversight. - Fix recurring defects in GPC, deletion, and disclosure flows quickly - Keep 24 month records of requests and responses - Review marketing and adtech changes before launch - Retain a clean history of remediation and management review *Recommended next step* *Placement: after the enforcement section* ## Use California CCPA Penalties and Fines as a cited research workflow Research Copilot can take California CCPA Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CCPA Penalties and Fines](/solutions/research-copilot.md): Start from California CCPA Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Penalties and Fines. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/penalties-and-fines --- --- title: "CCPA Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/us/ccpa/penalties-and-fines" author: "Sorena AI" description: "Know the penalty ranges, then work backward to the controls that reduce them." keywords: - "CCPA penalties" - "CCPA fines" - "California privacy fines" - "CCPA private right of action" - "CCPA" - "Penalties and Fines" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Penalties and Fines Know the penalty ranges, then work backward to the controls that reduce them. *Penalties* *CCPA* ## California CCPA Penalties and Fines Grounded in the California statute, CPPA regulations, and current California enforcement themes. California penalty exposure is best understood as a function of scale and proof. Repeated failures in notices, opt out handling, or vendor governance can multiply quickly. ## Civil penalty framework California penalties can reach 2,500 dollars per violation or 7,500 dollars per intentional violation or violation involving minors under 16. - Count risk by affected consumers, affected interactions, and duration - Treat youth data and opt in rules as a higher consequence area - Retain proof that policies, notices, and controls matched practice at the time - Assume missing logs or stale notices will worsen the outcome ## Security breach exposure California also allows a private action for certain data breaches involving nonencrypted or nonredacted personal information where reasonable security was lacking. - Maintain reasonable security evidence and testing history - Track incident response, root cause analysis, and remediation proof - Link vendor security obligations to contract and oversight evidence - Review whether notice claims about security match technical reality ## How to reduce exposure The most effective penalty reduction work is usually operational: accurate notices, good request handling, fast defect correction, and real vendor oversight. - Fix recurring defects in GPC, deletion, and disclosure flows quickly - Keep 24 month records of requests and responses - Review marketing and adtech changes before launch - Retain a clean history of remediation and management review *Recommended next step* *Placement: after the enforcement section* ## Use California CCPA Penalties and Fines as a cited research workflow Research Copilot can take California CCPA Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CCPA Penalties and Fines](/solutions/research-copilot.md): Start from California CCPA Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Penalties and Fines. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/penalties-and-fines --- --- title: "CCPA Privacy Notices and Disclosures" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/privacy-notices-and-disclosures" source_url: "https://www.sorena.io/artifacts/us/ccpa/privacy-notices-and-disclosures" author: "Sorena AI" description: "Design the California notice stack so each disclosure appears in the right place and says the right thing." keywords: - "CCPA notice at collection" - "California privacy notices" - "CCPA disclosures" - "do not sell or share notice" - "CCPA" - "Privacy Notices and Disclosures" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Privacy Notices and Disclosures Design the California notice stack so each disclosure appears in the right place and says the right thing. *Notices* *CCPA* ## California CCPA Privacy Notices and Disclosures Grounded in the California statute, CPPA regulations, and current California enforcement themes. California compliance often fails because all disclosures are collapsed into one generic privacy policy. The regulations instead expect a notice architecture built around when and how personal information is collected and used. ## Notice at collection The notice at collection belongs at or before the point of collection. It should identify the categories of personal information to be collected, the purposes for which they will be used, and whether the information is sold or shared. - List categories of personal information and SPI in plain terms - State the business or commercial purposes for collection and use - Disclose whether the data is sold or shared and whether a limit notice is relevant - Provide the notice where collection actually happens, including apps and third party collection contexts ## Privacy policy and rights notices The privacy policy gives the broader picture, while the notice of right to opt out of sale or sharing and any notice of right to limit support specific consumer choices. - Describe rights, request methods, and verification practices - Explain how GPC or other opt out preference signals are processed - Link directly to the opt out flow and any limit flow that applies - Disclose 12 month look back information for sales, sharing, and business purpose disclosures ## Disclosure governance The same source data should drive the notice at collection, the privacy policy, and vendor disclosures. Otherwise the notices drift apart and become contradictory. - Use the same category dictionary across all consumer notices - Review disclosures after launching new tags, SDKs, or partners - Compare notices against the rights workflow and actual adtech behaviour - Retain prior versions and approval records *Recommended next step* *Placement: near the end of the main content before related guides* ## Turn California CCPA Privacy Notices and Disclosures into an operational assessment Assessment Autopilot can take California CCPA Privacy Notices and Disclosures from turning this guidance into an operational assessment workflow to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CCPA Privacy Notices and Disclosures](/solutions/assessment.md): Start from California CCPA Privacy Notices and Disclosures and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Privacy Notices and Disclosures. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/privacy-notices-and-disclosures --- --- title: "CCPA Privacy Notices and Disclosures" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/privacy-notices-and-disclosures" source_url: "https://www.sorena.io/artifacts/us/ccpa/privacy-notices-and-disclosures" author: "Sorena AI" description: "Design the California notice stack so each disclosure appears in the right place and says the right thing." keywords: - "CCPA notice at collection" - "California privacy notices" - "CCPA disclosures" - "do not sell or share notice" - "CCPA" - "Privacy Notices and Disclosures" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Privacy Notices and Disclosures Design the California notice stack so each disclosure appears in the right place and says the right thing. *Notices* *CCPA* ## California CCPA Privacy Notices and Disclosures Grounded in the California statute, CPPA regulations, and current California enforcement themes. California compliance often fails because all disclosures are collapsed into one generic privacy policy. The regulations instead expect a notice architecture built around when and how personal information is collected and used. ## Notice at collection The notice at collection belongs at or before the point of collection. It should identify the categories of personal information to be collected, the purposes for which they will be used, and whether the information is sold or shared. - List categories of personal information and SPI in plain terms - State the business or commercial purposes for collection and use - Disclose whether the data is sold or shared and whether a limit notice is relevant - Provide the notice where collection actually happens, including apps and third party collection contexts ## Privacy policy and rights notices The privacy policy gives the broader picture, while the notice of right to opt out of sale or sharing and any notice of right to limit support specific consumer choices. - Describe rights, request methods, and verification practices - Explain how GPC or other opt out preference signals are processed - Link directly to the opt out flow and any limit flow that applies - Disclose 12 month look back information for sales, sharing, and business purpose disclosures ## Disclosure governance The same source data should drive the notice at collection, the privacy policy, and vendor disclosures. Otherwise the notices drift apart and become contradictory. - Use the same category dictionary across all consumer notices - Review disclosures after launching new tags, SDKs, or partners - Compare notices against the rights workflow and actual adtech behaviour - Retain prior versions and approval records *Recommended next step* *Placement: near the end of the main content before related guides* ## Turn California CCPA Privacy Notices and Disclosures into an operational assessment Assessment Autopilot can take California CCPA Privacy Notices and Disclosures from turning this guidance into an operational assessment workflow to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CCPA Privacy Notices and Disclosures](/solutions/assessment.md): Start from California CCPA Privacy Notices and Disclosures and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Privacy Notices and Disclosures. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/privacy-notices-and-disclosures --- --- title: "CCPA Requirements" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/requirements" source_url: "https://www.sorena.io/artifacts/us/ccpa/requirements" author: "Sorena AI" description: "Translate California law into control statements that can be implemented, tested, and audited." keywords: - "CCPA requirements" - "California privacy requirements" - "CCPA controls" - "do not sell or share requirements" - "CCPA" - "Requirements" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Requirements Translate California law into control statements that can be implemented, tested, and audited. *Requirements* *CCPA* ## California CCPA Requirements Grounded in the California statute, CPPA regulations, and current California enforcement themes. A California requirement matrix should be specific enough to drive notice content, consumer interfaces, contract drafting, and technical testing. ## Scope and disclosure requirements The first requirement domain covers threshold analysis, business status, notice at collection, privacy policy content, and sale or sharing disclosures. - Threshold decision with documented calculations and annual reassessment - Notice at collection before or at the point of collection - Privacy policy disclosures for categories, purposes, recipients, and rights - Accurate opt out and financial incentive notices where relevant *Recommended next step* *Placement: after the requirement breakdown* ## Turn California CCPA Requirements into an operational assessment Assessment Autopilot can take California CCPA Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CCPA Requirements](/solutions/assessment.md): Start from California CCPA Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Requirements. ## Consumer choice and request requirements The second domain covers requests to know, delete, correct, opt out, and limit where the current rules require it. It also covers GPC and identity verification controls. - 45 day request workflow with documented extension logic - Proportionate verification for delete, correct, and know requests - No burdensome verification for opt out of sale or sharing - GPC support and downstream suppression logic where applicable ## Vendor, security, and evidence requirements The final domain covers service provider, contractor, and third party agreements, reasonable security, and evidence retention. - Service provider, contractor, and third party contract terms that match the regulations - Due diligence and remediation rights for vendor misuse - 24 month request records and wider programme evidence retention - Reasonable security linked to incident readiness and private claim exposure ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/requirements --- --- title: "CCPA Requirements" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/requirements" source_url: "https://www.sorena.io/artifacts/us/ccpa/requirements" author: "Sorena AI" description: "Translate California law into control statements that can be implemented, tested, and audited." keywords: - "CCPA requirements" - "California privacy requirements" - "CCPA controls" - "do not sell or share requirements" - "CCPA" - "Requirements" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Requirements Translate California law into control statements that can be implemented, tested, and audited. *Requirements* *CCPA* ## California CCPA Requirements Grounded in the California statute, CPPA regulations, and current California enforcement themes. A California requirement matrix should be specific enough to drive notice content, consumer interfaces, contract drafting, and technical testing. ## Scope and disclosure requirements The first requirement domain covers threshold analysis, business status, notice at collection, privacy policy content, and sale or sharing disclosures. - Threshold decision with documented calculations and annual reassessment - Notice at collection before or at the point of collection - Privacy policy disclosures for categories, purposes, recipients, and rights - Accurate opt out and financial incentive notices where relevant *Recommended next step* *Placement: after the requirement breakdown* ## Turn California CCPA Requirements into an operational assessment Assessment Autopilot can take California CCPA Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CCPA Requirements](/solutions/assessment.md): Start from California CCPA Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Requirements. ## Consumer choice and request requirements The second domain covers requests to know, delete, correct, opt out, and limit where the current rules require it. It also covers GPC and identity verification controls. - 45 day request workflow with documented extension logic - Proportionate verification for delete, correct, and know requests - No burdensome verification for opt out of sale or sharing - GPC support and downstream suppression logic where applicable ## Vendor, security, and evidence requirements The final domain covers service provider, contractor, and third party agreements, reasonable security, and evidence retention. - Service provider, contractor, and third party contract terms that match the regulations - Due diligence and remediation rights for vendor misuse - 24 month request records and wider programme evidence retention - Reasonable security linked to incident readiness and private claim exposure ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/requirements --- --- title: "CCPA Scope and Thresholds" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/scope-and-thresholds" source_url: "https://www.sorena.io/artifacts/us/ccpa/scope-and-thresholds" author: "Sorena AI" description: "Use the real California threshold tests instead of rough privacy folklore." keywords: - "CCPA scope and thresholds" - "CCPA 100000 consumers" - "CCPA 25 million revenue" - "California business threshold" - "CCPA" - "Scope and Thresholds" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Scope and Thresholds Use the real California threshold tests instead of rough privacy folklore. *Scope* *CCPA* ## California CCPA Scope and Thresholds Grounded in the California statute, CPPA regulations, and current California enforcement themes. California threshold analysis is one of the highest leverage steps in the whole programme. If it is wrong, notices, contract paper, and rights work will all be wrong too. ## The three core thresholds A business may be in scope if it has annual gross revenues over 25 million dollars, buys, receives, sells, or shares the personal information of 100,000 or more consumers or households, or derives 50 percent or more of annual revenue from selling or sharing personal information. - Use finance approved revenue figures and date the calculation - Define the counting method for consumers and households and keep it stable - Track where sale or sharing revenue is recognised and how it is measured - Review whether affiliates or brand structures affect the business analysis *Recommended next step* *Placement: after the scope or definition section* ## Use California CCPA Scope and Thresholds as a cited research workflow Research Copilot can take California CCPA Scope and Thresholds from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CCPA Scope and Thresholds](/solutions/research-copilot.md): Start from California CCPA Scope and Thresholds and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Scope and Thresholds. ## Exemptions and carve outs Even when the threshold is met, not every data set is treated the same. California exemptions can be sector specific, context specific, or limited to certain information uses. - Map exemptions by law, dataset, and processing purpose - Separate exempt regulated operations from website, marketing, or analytics activity - Record where employee, applicant, or contractor information is subject to different handling rules - Retest exemptions when the business expands into new channels or services ## How to keep the scope decision current The threshold answer can change as a company grows, adds advertising relationships, or acquires another business. - Review thresholds at least annually and after acquisitions or major growth - Link the decision to your category map and rights volume assumptions - Store calculations and source data used for the decision - Escalate borderline cases to finance, privacy, and product together ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/scope-and-thresholds --- --- title: "CCPA Scope and Thresholds" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/scope-and-thresholds" source_url: "https://www.sorena.io/artifacts/us/ccpa/scope-and-thresholds" author: "Sorena AI" description: "Use the real California threshold tests instead of rough privacy folklore." keywords: - "CCPA scope and thresholds" - "CCPA 100000 consumers" - "CCPA 25 million revenue" - "California business threshold" - "CCPA" - "Scope and Thresholds" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Scope and Thresholds Use the real California threshold tests instead of rough privacy folklore. *Scope* *CCPA* ## California CCPA Scope and Thresholds Grounded in the California statute, CPPA regulations, and current California enforcement themes. California threshold analysis is one of the highest leverage steps in the whole programme. If it is wrong, notices, contract paper, and rights work will all be wrong too. ## The three core thresholds A business may be in scope if it has annual gross revenues over 25 million dollars, buys, receives, sells, or shares the personal information of 100,000 or more consumers or households, or derives 50 percent or more of annual revenue from selling or sharing personal information. - Use finance approved revenue figures and date the calculation - Define the counting method for consumers and households and keep it stable - Track where sale or sharing revenue is recognised and how it is measured - Review whether affiliates or brand structures affect the business analysis *Recommended next step* *Placement: after the scope or definition section* ## Use California CCPA Scope and Thresholds as a cited research workflow Research Copilot can take California CCPA Scope and Thresholds from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CCPA Scope and Thresholds](/solutions/research-copilot.md): Start from California CCPA Scope and Thresholds and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Scope and Thresholds. ## Exemptions and carve outs Even when the threshold is met, not every data set is treated the same. California exemptions can be sector specific, context specific, or limited to certain information uses. - Map exemptions by law, dataset, and processing purpose - Separate exempt regulated operations from website, marketing, or analytics activity - Record where employee, applicant, or contractor information is subject to different handling rules - Retest exemptions when the business expands into new channels or services ## How to keep the scope decision current The threshold answer can change as a company grows, adds advertising relationships, or acquires another business. - Review thresholds at least annually and after acquisitions or major growth - Link the decision to your category map and rights volume assumptions - Store calculations and source data used for the decision - Escalate borderline cases to finance, privacy, and product together ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Service Provider and Contractor Contracts](/artifacts/us/ccpa/service-provider-contractor-contracts.md): Draft California vendor contracts that work in practice, not only on paper. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/scope-and-thresholds --- --- title: "CCPA Service Provider and Contractor Contracts" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/service-provider-contractor-contracts" source_url: "https://www.sorena.io/artifacts/us/ccpa/service-provider-contractor-contracts" author: "Sorena AI" description: "Draft California vendor contracts that work in practice, not only on paper." keywords: - "CCPA service provider contract" - "CCPA contractor contract" - "California vendor clauses" - "CCPA third party contract" - "CCPA" - "Service Provider and Contractor Contracts" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Service Provider and Contractor Contracts Draft California vendor contracts that work in practice, not only on paper. *Vendor Governance* *CCPA* ## California CCPA Service Provider and Contractor Contracts Grounded in the California statute, CPPA regulations, and current California enforcement themes. California contract design should classify each recipient correctly first. Service providers, contractors, and third parties are not interchangeable labels and they do not carry the same rule set. ## Required contract architecture Service provider and contractor agreements should identify the limited and specified business purposes, prohibit retention, use, or disclosure outside those purposes except where the law permits it, and require the recipient to provide the same level of privacy protection as the business owes. - Specify the exact business purpose instead of generic references - Prohibit use outside the direct business relationship unless permitted - Require assistance with consumer requests and reasonable security - Give the business the right to stop and remediate unauthorised use upon notice ## Due diligence and enforcement The California regulations say due diligence matters when assessing whether a business had reason to believe a vendor would misuse personal information. - Review vendor data flows and privileges before disclosure begins - Collect evidence that vendors can process deletion and opt out instructions - Re paper subcontractor chains where the vendor uses downstream providers - Keep remediation records when the business exercises its contract rights ## Where programmes fail The common failures are vague purpose clauses, missing third party terms, and a lack of any process to test or enforce the contract. - Check whether adtech recipients are truly service providers or actually third parties - Make sure forwarded opt out or deletion requests can be executed contractually - Align contract taxonomies with the privacy notice categories and data map - Retain versions, approvals, and vendor due diligence records together *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep California CCPA Service Provider and Contractor Contracts in one governed evidence system SSOT can take California CCPA Service Provider and Contractor Contracts from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for California CCPA Service Provider and Contractor Contracts](/solutions/ssot.md): Start from California CCPA Service Provider and Contractor Contracts and keep documents, evidence, and control records in one governed system. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Service Provider and Contractor Contracts. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/service-provider-contractor-contracts --- --- title: "CCPA Service Provider and Contractor Contracts" canonical_url: "https://www.sorena.io/artifacts/us/ccpa/service-provider-contractor-contracts" source_url: "https://www.sorena.io/artifacts/us/ccpa/service-provider-contractor-contracts" author: "Sorena AI" description: "Draft California vendor contracts that work in practice, not only on paper." keywords: - "CCPA service provider contract" - "CCPA contractor contract" - "California vendor clauses" - "CCPA third party contract" - "CCPA" - "Service Provider and Contractor Contracts" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA Service Provider and Contractor Contracts Draft California vendor contracts that work in practice, not only on paper. *Vendor Governance* *CCPA* ## California CCPA Service Provider and Contractor Contracts Grounded in the California statute, CPPA regulations, and current California enforcement themes. California contract design should classify each recipient correctly first. Service providers, contractors, and third parties are not interchangeable labels and they do not carry the same rule set. ## Required contract architecture Service provider and contractor agreements should identify the limited and specified business purposes, prohibit retention, use, or disclosure outside those purposes except where the law permits it, and require the recipient to provide the same level of privacy protection as the business owes. - Specify the exact business purpose instead of generic references - Prohibit use outside the direct business relationship unless permitted - Require assistance with consumer requests and reasonable security - Give the business the right to stop and remediate unauthorised use upon notice ## Due diligence and enforcement The California regulations say due diligence matters when assessing whether a business had reason to believe a vendor would misuse personal information. - Review vendor data flows and privileges before disclosure begins - Collect evidence that vendors can process deletion and opt out instructions - Re paper subcontractor chains where the vendor uses downstream providers - Keep remediation records when the business exercises its contract rights ## Where programmes fail The common failures are vague purpose clauses, missing third party terms, and a lack of any process to test or enforce the contract. - Check whether adtech recipients are truly service providers or actually third parties - Make sure forwarded opt out or deletion requests can be executed contractually - Align contract taxonomies with the privacy notice categories and data map - Retain versions, approvals, and vendor due diligence records together *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep California CCPA Service Provider and Contractor Contracts in one governed evidence system SSOT can take California CCPA Service Provider and Contractor Contracts from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on California CCPA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for California CCPA Service Provider and Contractor Contracts](/solutions/ssot.md): Start from California CCPA Service Provider and Contractor Contracts and keep documents, evidence, and control records in one governed system. - [Talk through California CCPA](/contact.md): Review your current process, evidence gaps, and next steps for California CCPA Service Provider and Contractor Contracts. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA Applicability Test | California Scope Test](/artifacts/us/ccpa/applicability-test.md): Test whether a business is in scope under the current California threshold model. - [CCPA Checklist | California Privacy Compliance Checklist](/artifacts/us/ccpa/checklist.md): Track the California controls that must actually exist in policy, product, and vendor operations. - [CCPA Compliance Program | California Operating Model](/artifacts/us/ccpa/compliance.md): Build a California privacy programme that survives regulator questions and product change. - [CCPA Consumer Rights Workflow | 45 Day Request Handling](/artifacts/us/ccpa/consumer-rights-workflow.md): Run California rights operations with clear timing, verification, and downstream instructions. - [CCPA Deadlines and Compliance Calendar](/artifacts/us/ccpa/deadlines-and-compliance-calendar.md): Use the dates that actually shape California privacy work. - [CCPA Enforcement and Penalties | CPPA and AG Exposure Guide](/artifacts/us/ccpa/enforcement-and-penalties.md): Understand how California enforcement usually starts and what evidence the agency will ask for. - [CCPA FAQ | Practical California Privacy Answers](/artifacts/us/ccpa/faq.md): Answer the California privacy questions that usually stall implementation. - [CCPA Penalties and Fines | California Exposure Summary](/artifacts/us/ccpa/penalties-and-fines.md): Know the penalty ranges, then work backward to the controls that reduce them. - [CCPA Privacy Notices and Disclosures | California Notice Architecture](/artifacts/us/ccpa/privacy-notices-and-disclosures.md): Design the California notice stack so each disclosure appears in the right place and says the right thing. - [CCPA Privacy Policy Template | Required California Disclosures](/artifacts/us/ccpa/ccpa-privacy-policy-template.md): Write a California privacy policy that actually matches the statute and regulations. - [CCPA Requirements | California Control Requirements](/artifacts/us/ccpa/requirements.md): Translate California law into control statements that can be implemented, tested, and audited. - [CCPA Scope and Thresholds | California Business Threshold Guide](/artifacts/us/ccpa/scope-and-thresholds.md): Use the real California threshold tests instead of rough privacy folklore. - [CCPA vs CPRA | What the California Amendments Changed](/artifacts/us/ccpa/ccpa-vs-cpra.md): Compare the original CCPA and the CPRA amendments using the deltas that change real implementation work. - [CCPA vs GDPR | California and EU Privacy Comparison](/artifacts/us/ccpa/ccpa-vs-gdpr.md): Compare California CCPA obligations with the GDPR without assuming the two models are interchangeable. - [Do Not Sell or Share Implementation | CCPA and GPC Guide](/artifacts/us/ccpa/do-not-sell-share-implementation.md): Implement California opt out controls that actually work across websites, apps, and partner pipelines. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/ccpa/service-provider-contractor-contracts --- --- title: "CPRA Applicability Test" canonical_url: "https://www.sorena.io/artifacts/us/cpra/applicability-test" source_url: "https://www.sorena.io/artifacts/us/cpra/applicability-test" author: "Sorena AI" description: "Confirm California scope and then identify which CPRA specific obligations activate." keywords: - "CPRA applicability test" - "CPRA scope" - "California privacy thresholds" - "CPRA SPI trigger" - "CPRA" - "Applicability Test" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Applicability Test Confirm California scope and then identify which CPRA specific obligations activate. *Applicability* *CPRA* ## California CPRA Applicability Test Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. A CPRA applicability test should answer both whether the business is in scope and which special California workstreams must be built on top of the baseline programme. ## Threshold analysis The same California business thresholds remain the starting point: more than 25 million dollars in annual gross revenue, 100,000 or more consumers or households, or 50 percent of annual revenue from selling or sharing personal information. - Record the threshold met and the underlying calculation - Check exemptions by dataset rather than assuming the whole business is exempt - Map affiliated entities that may affect the business analysis - Revalidate the result after acquisitions, new adtech, or rapid growth ## CPRA specific trigger review After scope is confirmed, identify whether the business uses or discloses sensitive personal information outside permitted purposes, sells or shares information, relies on service providers or contractors, or runs processing that may trigger risk assessment, cybersecurity audit, or ADMT obligations. - Identify all SPI categories and the purposes attached to them - List every sale, sharing, and cross context advertising flow - Review whether contract forms are current - Assess whether any processing appears in the California risk assessment or audit trigger set ## Evidence pack The output should be a living scope and trigger register that explains not only why the business is covered, but also why certain CPRA workstreams do or do not apply. - Maintain a versioned register for SPI, rights, contracts, and assessment triggers - Link the register to notices, contracts, and the data map - Escalate borderline assessment trigger decisions to privacy and security together - Review the register whenever California rulemaking changes *Recommended next step* *Placement: after the applicability result* ## Turn California CPRA Applicability Test into an operational assessment Assessment Autopilot can take California CPRA Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CPRA Applicability Test](/solutions/assessment.md): Start from California CPRA Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Applicability Test. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/applicability-test --- --- title: "CPRA Applicability Test" canonical_url: "https://www.sorena.io/artifacts/us/cpra/applicability-test" source_url: "https://www.sorena.io/artifacts/us/cpra/applicability-test" author: "Sorena AI" description: "Confirm California scope and then identify which CPRA specific obligations activate." keywords: - "CPRA applicability test" - "CPRA scope" - "California privacy thresholds" - "CPRA SPI trigger" - "CPRA" - "Applicability Test" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Applicability Test Confirm California scope and then identify which CPRA specific obligations activate. *Applicability* *CPRA* ## California CPRA Applicability Test Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. A CPRA applicability test should answer both whether the business is in scope and which special California workstreams must be built on top of the baseline programme. ## Threshold analysis The same California business thresholds remain the starting point: more than 25 million dollars in annual gross revenue, 100,000 or more consumers or households, or 50 percent of annual revenue from selling or sharing personal information. - Record the threshold met and the underlying calculation - Check exemptions by dataset rather than assuming the whole business is exempt - Map affiliated entities that may affect the business analysis - Revalidate the result after acquisitions, new adtech, or rapid growth ## CPRA specific trigger review After scope is confirmed, identify whether the business uses or discloses sensitive personal information outside permitted purposes, sells or shares information, relies on service providers or contractors, or runs processing that may trigger risk assessment, cybersecurity audit, or ADMT obligations. - Identify all SPI categories and the purposes attached to them - List every sale, sharing, and cross context advertising flow - Review whether contract forms are current - Assess whether any processing appears in the California risk assessment or audit trigger set ## Evidence pack The output should be a living scope and trigger register that explains not only why the business is covered, but also why certain CPRA workstreams do or do not apply. - Maintain a versioned register for SPI, rights, contracts, and assessment triggers - Link the register to notices, contracts, and the data map - Escalate borderline assessment trigger decisions to privacy and security together - Review the register whenever California rulemaking changes *Recommended next step* *Placement: after the applicability result* ## Turn California CPRA Applicability Test into an operational assessment Assessment Autopilot can take California CPRA Applicability Test from deciding whether these obligations apply in practice to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CPRA Applicability Test](/solutions/assessment.md): Start from California CPRA Applicability Test and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Applicability Test. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/applicability-test --- --- title: "CCPA vs CPRA What Changed" canonical_url: "https://www.sorena.io/artifacts/us/cpra/ccpa-vs-cpra-what-changed" source_url: "https://www.sorena.io/artifacts/us/cpra/ccpa-vs-cpra-what-changed" author: "Sorena AI" description: "Use the actual legal and operational deltas when upgrading an older California programme." keywords: - "CCPA vs CPRA what changed" - "CPRA changes" - "California privacy delta" - "CPRA update" - "CPRA" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA vs CPRA What Changed Use the actual legal and operational deltas when upgrading an older California programme. *Changes* *CPRA* ## California CPRA CCPA vs CPRA What Changed Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. A team that already implemented CCPA still needs a delta plan for CPRA. The cleanest way to build it is to focus on the parts that change systems, notices, and contracts. ## Rights and definitions CPRA added the right to correct, created the right to limit certain uses of sensitive personal information, and expanded opt out scope to sharing for cross context behavioural advertising. - Add correction and limit workflows to old CCPA portals - Treat sharing as a core regulated concept and not only sale - Refresh threshold analysis that still uses the 50,000 number - Reclassify recipients under the current service provider and contractor model ## Regulator and enforcement changes CPRA established the CPPA as a dedicated regulator and removed the guaranteed 30 day cure period. - Monitor CPPA rules and advisories as a first class source - Do not assume a cure period will save a weak implementation - Keep request logs, notices, contracts, and test evidence current - Review old governance papers for stale references ## 2026 programme impact The California rules effective January 1, 2026 take the CPRA model further by operationalising risk assessments, cybersecurity audits, ADMT, and other modern programme requirements. - Map the 2026 rules into backlog items rather than waiting for enforcement interest - Review whether the business will trigger risk assessment or cybersecurity audit duties - Update contract packs and SPI logic for the current rules - Use the delta list as the migration plan from legacy California controls *Recommended next step* *Placement: after the comparison section* ## Use California CPRA CCPA vs CPRA What Changed as a cited research workflow Research Copilot can take California CPRA CCPA vs CPRA What Changed from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CPRA CCPA vs CPRA What Changed](/solutions/research-copilot.md): Start from California CPRA CCPA vs CPRA What Changed and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA CCPA vs CPRA What Changed. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/ccpa-vs-cpra-what-changed --- --- title: "CCPA vs CPRA What Changed" canonical_url: "https://www.sorena.io/artifacts/us/cpra/ccpa-vs-cpra-what-changed" source_url: "https://www.sorena.io/artifacts/us/cpra/ccpa-vs-cpra-what-changed" author: "Sorena AI" description: "Use the actual legal and operational deltas when upgrading an older California programme." keywords: - "CCPA vs CPRA what changed" - "CPRA changes" - "California privacy delta" - "CPRA update" - "CPRA" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CCPA vs CPRA What Changed Use the actual legal and operational deltas when upgrading an older California programme. *Changes* *CPRA* ## California CPRA CCPA vs CPRA What Changed Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. A team that already implemented CCPA still needs a delta plan for CPRA. The cleanest way to build it is to focus on the parts that change systems, notices, and contracts. ## Rights and definitions CPRA added the right to correct, created the right to limit certain uses of sensitive personal information, and expanded opt out scope to sharing for cross context behavioural advertising. - Add correction and limit workflows to old CCPA portals - Treat sharing as a core regulated concept and not only sale - Refresh threshold analysis that still uses the 50,000 number - Reclassify recipients under the current service provider and contractor model ## Regulator and enforcement changes CPRA established the CPPA as a dedicated regulator and removed the guaranteed 30 day cure period. - Monitor CPPA rules and advisories as a first class source - Do not assume a cure period will save a weak implementation - Keep request logs, notices, contracts, and test evidence current - Review old governance papers for stale references ## 2026 programme impact The California rules effective January 1, 2026 take the CPRA model further by operationalising risk assessments, cybersecurity audits, ADMT, and other modern programme requirements. - Map the 2026 rules into backlog items rather than waiting for enforcement interest - Review whether the business will trigger risk assessment or cybersecurity audit duties - Update contract packs and SPI logic for the current rules - Use the delta list as the migration plan from legacy California controls *Recommended next step* *Placement: after the comparison section* ## Use California CPRA CCPA vs CPRA What Changed as a cited research workflow Research Copilot can take California CPRA CCPA vs CPRA What Changed from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CPRA CCPA vs CPRA What Changed](/solutions/research-copilot.md): Start from California CPRA CCPA vs CPRA What Changed and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA CCPA vs CPRA What Changed. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/ccpa-vs-cpra-what-changed --- --- title: "CPRA Checklist" canonical_url: "https://www.sorena.io/artifacts/us/cpra/checklist" source_url: "https://www.sorena.io/artifacts/us/cpra/checklist" author: "Sorena AI" description: "Track the California privacy workstreams that changed under CPRA and the 2026 rules." keywords: - "CPRA checklist" - "CPRA compliance checklist" - "California SPI checklist" - "CPRA risk assessment checklist" - "CPRA" - "Checklist" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Checklist Track the California privacy workstreams that changed under CPRA and the 2026 rules. *Checklist* *CPRA* ## California CPRA Checklist Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. The CPRA checklist should tell the team which tasks belong to every in scope business and which tasks depend on sale, sharing, SPI, or high risk processing triggers. ## Baseline California controls Every in scope business still needs current notices, request methods, request logging, and vendor paper that matches California categories and rights. - Confirm threshold status and update notices to the current California rules - Operate delete, correct, know, and opt out workflows within the required timelines - Honor GPC and keep 24 month records of requests and responses - Maintain service provider, contractor, and third party agreements ## CPRA specific controls The next layer covers sensitive personal information, right to limit, sharing, and the newer contract and due diligence expectations. - Classify SPI and decide whether right to limit notices are required - Treat sharing for cross context advertising as its own governed activity - Review contract and audit rights for all major recipients - Make sure rights portals and notices reflect correction and limitation rights ## Forward looking 2026 controls The final layer is the California rules effective January 1, 2026. Not every business will trigger them immediately, but the programme should know whether the business is on that path. - Assess whether risk assessment triggers apply to current processing - Assess whether cybersecurity audit thresholds will apply - Track any data broker registration or DROP related obligations - Monitor CPPA rule updates and add implementation dates to the control calendar *Recommended next step* *Placement: after the checklist block* ## Turn California CPRA Checklist into an operational assessment Assessment Autopilot can take California CPRA Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CPRA Checklist](/solutions/assessment.md): Start from California CPRA Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Checklist. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/checklist --- --- title: "CPRA Checklist" canonical_url: "https://www.sorena.io/artifacts/us/cpra/checklist" source_url: "https://www.sorena.io/artifacts/us/cpra/checklist" author: "Sorena AI" description: "Track the California privacy workstreams that changed under CPRA and the 2026 rules." keywords: - "CPRA checklist" - "CPRA compliance checklist" - "California SPI checklist" - "CPRA risk assessment checklist" - "CPRA" - "Checklist" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Checklist Track the California privacy workstreams that changed under CPRA and the 2026 rules. *Checklist* *CPRA* ## California CPRA Checklist Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. The CPRA checklist should tell the team which tasks belong to every in scope business and which tasks depend on sale, sharing, SPI, or high risk processing triggers. ## Baseline California controls Every in scope business still needs current notices, request methods, request logging, and vendor paper that matches California categories and rights. - Confirm threshold status and update notices to the current California rules - Operate delete, correct, know, and opt out workflows within the required timelines - Honor GPC and keep 24 month records of requests and responses - Maintain service provider, contractor, and third party agreements ## CPRA specific controls The next layer covers sensitive personal information, right to limit, sharing, and the newer contract and due diligence expectations. - Classify SPI and decide whether right to limit notices are required - Treat sharing for cross context advertising as its own governed activity - Review contract and audit rights for all major recipients - Make sure rights portals and notices reflect correction and limitation rights ## Forward looking 2026 controls The final layer is the California rules effective January 1, 2026. Not every business will trigger them immediately, but the programme should know whether the business is on that path. - Assess whether risk assessment triggers apply to current processing - Assess whether cybersecurity audit thresholds will apply - Track any data broker registration or DROP related obligations - Monitor CPPA rule updates and add implementation dates to the control calendar *Recommended next step* *Placement: after the checklist block* ## Turn California CPRA Checklist into an operational assessment Assessment Autopilot can take California CPRA Checklist from turning this checklist into an operational workflow to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CPRA Checklist](/solutions/assessment.md): Start from California CPRA Checklist and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Checklist. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/checklist --- --- title: "CPRA Compliance Program" canonical_url: "https://www.sorena.io/artifacts/us/cpra/compliance" source_url: "https://www.sorena.io/artifacts/us/cpra/compliance" author: "Sorena AI" description: "Run a California programme that can absorb ongoing CPPA rules without constant redesign." keywords: - "CPRA compliance program" - "California privacy operating model" - "CPRA governance" - "CPRA controls" - "CPRA" - "Compliance Program" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Compliance Program Run a California programme that can absorb ongoing CPPA rules without constant redesign. *Operating Model* *CPRA* ## California CPRA Compliance Program Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. The CPRA operating model should connect the consumer side of California privacy to the internal assurance side. Notices, rights, contracts, risk assessments, and security should all rely on the same facts. ## Programme architecture Start with a common California data and vendor inventory. Then add overlays for SPI, sharing, correction, and newer assessment obligations. - Use one category dictionary for notices, requests, and contract terms - Assign owners for rights, SPI, vendor governance, security, and rule tracking - Record where the business sells, shares, or limits use of personal information - Keep a single source of truth for California control status ## Execution workstreams The programme should run separate but connected workstreams for rights, opt out and limit, contracts, and assurance. - Operate delete, correct, know, opt out, and limit workflows - Honor GPC and downstream suppression obligations - Re paper and oversee service providers, contractors, and third parties - Connect privacy controls to security testing and incident readiness ## Continuous improvement California compliance does not stand still. The programme should absorb new CPPA rules, new adtech, and new data uses without forcing a total rewrite every year. - Watch the CPPA updates page and rulemaking materials regularly - Reassess notices and contracts after every major data use change - Measure request performance and defects in GPC or SPI flows - Prepare for future audit and risk assessment reporting where thresholds are met *Recommended next step* *Placement: after the compliance steps* ## Turn California CPRA Compliance Program into an operational assessment Assessment Autopilot can take California CPRA Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CPRA Compliance Program](/solutions/assessment.md): Start from California CPRA Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Compliance Program. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/compliance --- --- title: "CPRA Compliance Program" canonical_url: "https://www.sorena.io/artifacts/us/cpra/compliance" source_url: "https://www.sorena.io/artifacts/us/cpra/compliance" author: "Sorena AI" description: "Run a California programme that can absorb ongoing CPPA rules without constant redesign." keywords: - "CPRA compliance program" - "California privacy operating model" - "CPRA governance" - "CPRA controls" - "CPRA" - "Compliance Program" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Compliance Program Run a California programme that can absorb ongoing CPPA rules without constant redesign. *Operating Model* *CPRA* ## California CPRA Compliance Program Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. The CPRA operating model should connect the consumer side of California privacy to the internal assurance side. Notices, rights, contracts, risk assessments, and security should all rely on the same facts. ## Programme architecture Start with a common California data and vendor inventory. Then add overlays for SPI, sharing, correction, and newer assessment obligations. - Use one category dictionary for notices, requests, and contract terms - Assign owners for rights, SPI, vendor governance, security, and rule tracking - Record where the business sells, shares, or limits use of personal information - Keep a single source of truth for California control status ## Execution workstreams The programme should run separate but connected workstreams for rights, opt out and limit, contracts, and assurance. - Operate delete, correct, know, opt out, and limit workflows - Honor GPC and downstream suppression obligations - Re paper and oversee service providers, contractors, and third parties - Connect privacy controls to security testing and incident readiness ## Continuous improvement California compliance does not stand still. The programme should absorb new CPPA rules, new adtech, and new data uses without forcing a total rewrite every year. - Watch the CPPA updates page and rulemaking materials regularly - Reassess notices and contracts after every major data use change - Measure request performance and defects in GPC or SPI flows - Prepare for future audit and risk assessment reporting where thresholds are met *Recommended next step* *Placement: after the compliance steps* ## Turn California CPRA Compliance Program into an operational assessment Assessment Autopilot can take California CPRA Compliance Program from operationalizing the guidance into a tracked program to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CPRA Compliance Program](/solutions/assessment.md): Start from California CPRA Compliance Program and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Compliance Program. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/compliance --- --- title: "CPRA Consumer Rights Workflow" canonical_url: "https://www.sorena.io/artifacts/us/cpra/consumer-rights-workflow" source_url: "https://www.sorena.io/artifacts/us/cpra/consumer-rights-workflow" author: "Sorena AI" description: "Run California rights operations across delete, correct, know, opt out, and limit." keywords: - "CPRA consumer rights workflow" - "CPRA correction right" - "CPRA limit use workflow" - "California GPC workflow" - "CPRA" - "Consumer Rights Workflow" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Consumer Rights Workflow Run California rights operations across delete, correct, know, opt out, and limit. *Consumer Rights* *CPRA* ## California CPRA Consumer Rights Workflow Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. The CPRA rights workflow is broader than the original California set. It must now handle correction and limitation requests as well as the older know, delete, and opt out flows. ## Intake and routing by right type Do not run all California rights through the same decision tree. Each right has a different verification need, evidence burden, and downstream action set. - Separate requests to know, delete, correct, limit, and opt out on intake - Start the 45 day response clock and manage extensions centrally - Allow authorised agents where the regulations require it - Explain the current status of each request clearly to the consumer ## Verification and fulfilment The regulations require proportionate verification for delete, correct, and know requests and do not allow businesses to make opt out or limit requests burdensome. - Use reasonable or reasonably high assurance based on data sensitivity and harm - Do not require identity verification for opt out or limit requests - Delete extra verification data as soon as practical after use - Search internal systems and key downstream parties where needed ## Downstream propagation and records Deletion, correction, opt out, and limit outcomes often require action by service providers, contractors, or third parties. - Push deletion, correction, opt out, and limit instructions downstream where required - Keep 24 month records of the request, response, and downstream instructions - Track mean or median response time by request type - Use error logs and repeat contacts to improve the workflow *Recommended next step* *Placement: after the scope or definition section* ## Use California CPRA Consumer Rights Workflow as a cited research workflow Research Copilot can take California CPRA Consumer Rights Workflow from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CPRA Consumer Rights Workflow](/solutions/research-copilot.md): Start from California CPRA Consumer Rights Workflow and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Consumer Rights Workflow. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/consumer-rights-workflow --- --- title: "CPRA Consumer Rights Workflow" canonical_url: "https://www.sorena.io/artifacts/us/cpra/consumer-rights-workflow" source_url: "https://www.sorena.io/artifacts/us/cpra/consumer-rights-workflow" author: "Sorena AI" description: "Run California rights operations across delete, correct, know, opt out, and limit." keywords: - "CPRA consumer rights workflow" - "CPRA correction right" - "CPRA limit use workflow" - "California GPC workflow" - "CPRA" - "Consumer Rights Workflow" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Consumer Rights Workflow Run California rights operations across delete, correct, know, opt out, and limit. *Consumer Rights* *CPRA* ## California CPRA Consumer Rights Workflow Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. The CPRA rights workflow is broader than the original California set. It must now handle correction and limitation requests as well as the older know, delete, and opt out flows. ## Intake and routing by right type Do not run all California rights through the same decision tree. Each right has a different verification need, evidence burden, and downstream action set. - Separate requests to know, delete, correct, limit, and opt out on intake - Start the 45 day response clock and manage extensions centrally - Allow authorised agents where the regulations require it - Explain the current status of each request clearly to the consumer ## Verification and fulfilment The regulations require proportionate verification for delete, correct, and know requests and do not allow businesses to make opt out or limit requests burdensome. - Use reasonable or reasonably high assurance based on data sensitivity and harm - Do not require identity verification for opt out or limit requests - Delete extra verification data as soon as practical after use - Search internal systems and key downstream parties where needed ## Downstream propagation and records Deletion, correction, opt out, and limit outcomes often require action by service providers, contractors, or third parties. - Push deletion, correction, opt out, and limit instructions downstream where required - Keep 24 month records of the request, response, and downstream instructions - Track mean or median response time by request type - Use error logs and repeat contacts to improve the workflow *Recommended next step* *Placement: after the scope or definition section* ## Use California CPRA Consumer Rights Workflow as a cited research workflow Research Copilot can take California CPRA Consumer Rights Workflow from clarifying scope and applicability with cited answers to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CPRA Consumer Rights Workflow](/solutions/research-copilot.md): Start from California CPRA Consumer Rights Workflow and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Consumer Rights Workflow. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/consumer-rights-workflow --- --- title: "CPRA Contracts, Contractors, and Service Providers" canonical_url: "https://www.sorena.io/artifacts/us/cpra/contracts-contractors-and-service-providers" source_url: "https://www.sorena.io/artifacts/us/cpra/contracts-contractors-and-service-providers" author: "Sorena AI" description: "Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations." keywords: - "CPRA contracts" - "contractor agreement CPRA" - "service provider clauses CPRA" - "California third party contract" - "CPRA" - "Contracts, Contractors, and Service Providers" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Contracts, Contractors, and Service Providers Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. *Vendor Governance* *CPRA* ## California CPRA Contracts, Contractors, and Service Providers Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. The current California rules expect contracts to carry real operational obligations. In a mature CPRA programme, the contract is one of the main control surfaces for rights, security, and oversight. ## Required recipient restrictions Service provider and contractor contracts should identify limited and specified business purposes, prohibit use outside those purposes except where permitted, require the same level of privacy protection as the business owes, and require notice if the recipient can no longer comply. - Describe the purpose specifically rather than by generic contract reference - Prohibit retention, use, or disclosure outside the direct business relationship unless permitted - Require notice if the recipient can no longer meet California obligations - Flow the same obligations to subcontractors where used ## Operational assistance duties The updated California rules explicitly connect recipient contracts to the business rights, cybersecurity audit, risk assessment, and ADMT obligations. - Require assistance with consumer requests and downstream deletion or suppression - Require support for cybersecurity audit and risk assessment where applicable - Require reasonable security appropriate to the nature of the information - Retain evidence that the recipient can actually perform these duties ## Monitoring and remediation Due diligence is part of the legal model. The business should be able to take reasonable and appropriate steps to ensure compliant use and then stop and remediate misuse upon notice. - Use audit, testing, or attestation rights on a real schedule - Collect evidence that opt out and deletion instructions are honoured - Track remediation actions and contract escalations - Review whether the contract form still matches the recipient actual data use *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep California CPRA Contracts, Contractors, and Service Providers in one governed evidence system SSOT can take California CPRA Contracts, Contractors, and Service Providers from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for California CPRA Contracts, Contractors, and Service Providers](/solutions/ssot.md): Start from California CPRA Contracts, Contractors, and Service Providers and keep documents, evidence, and control records in one governed system. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Contracts, Contractors, and Service Providers. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/contracts-contractors-and-service-providers --- --- title: "CPRA Contracts, Contractors, and Service Providers" canonical_url: "https://www.sorena.io/artifacts/us/cpra/contracts-contractors-and-service-providers" source_url: "https://www.sorena.io/artifacts/us/cpra/contracts-contractors-and-service-providers" author: "Sorena AI" description: "Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations." keywords: - "CPRA contracts" - "contractor agreement CPRA" - "service provider clauses CPRA" - "California third party contract" - "CPRA" - "Contracts, Contractors, and Service Providers" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Contracts, Contractors, and Service Providers Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. *Vendor Governance* *CPRA* ## California CPRA Contracts, Contractors, and Service Providers Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. The current California rules expect contracts to carry real operational obligations. In a mature CPRA programme, the contract is one of the main control surfaces for rights, security, and oversight. ## Required recipient restrictions Service provider and contractor contracts should identify limited and specified business purposes, prohibit use outside those purposes except where permitted, require the same level of privacy protection as the business owes, and require notice if the recipient can no longer comply. - Describe the purpose specifically rather than by generic contract reference - Prohibit retention, use, or disclosure outside the direct business relationship unless permitted - Require notice if the recipient can no longer meet California obligations - Flow the same obligations to subcontractors where used ## Operational assistance duties The updated California rules explicitly connect recipient contracts to the business rights, cybersecurity audit, risk assessment, and ADMT obligations. - Require assistance with consumer requests and downstream deletion or suppression - Require support for cybersecurity audit and risk assessment where applicable - Require reasonable security appropriate to the nature of the information - Retain evidence that the recipient can actually perform these duties ## Monitoring and remediation Due diligence is part of the legal model. The business should be able to take reasonable and appropriate steps to ensure compliant use and then stop and remediate misuse upon notice. - Use audit, testing, or attestation rights on a real schedule - Collect evidence that opt out and deletion instructions are honoured - Track remediation actions and contract escalations - Review whether the contract form still matches the recipient actual data use *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep California CPRA Contracts, Contractors, and Service Providers in one governed evidence system SSOT can take California CPRA Contracts, Contractors, and Service Providers from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for California CPRA Contracts, Contractors, and Service Providers](/solutions/ssot.md): Start from California CPRA Contracts, Contractors, and Service Providers and keep documents, evidence, and control records in one governed system. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Contracts, Contractors, and Service Providers. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/contracts-contractors-and-service-providers --- --- title: "CPPA Regulations Tracker" canonical_url: "https://www.sorena.io/artifacts/us/cpra/cppa-regulations-tracker" source_url: "https://www.sorena.io/artifacts/us/cpra/cppa-regulations-tracker" author: "Sorena AI" description: "Track the California rules that changed the operating baseline in 2026 and the related regulator outputs." keywords: - "CPPA regulations tracker" - "California privacy rulemaking" - "CPRA regulations 2026" - "CPPA updates" - "CPRA" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPPA Regulations Tracker Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. *Rulemaking* *CPRA* ## California CPRA CPPA Regulations Tracker Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. The California rulemaking story now spans more than one wave of regulations. The tracker should show what is already effective, what has a future deadline, and what still needs monitoring. ## Already effective rule milestones The first major CPPA regulations took effect in 2023. A later package of California rules became effective on January 1, 2026 and now shapes the current baseline for many programmes. - January 1, 2023: CPRA changes operative - July 1, 2023: CPPA administrative enforcement begins - January 1, 2026: updated California regulations become effective - Tag each effective rule to the notices, rights, contracts, or assurance controls it changes ## High impact 2026 areas The highest impact current areas are cybersecurity audits, risk assessments, ADMT related rules, and California data broker developments including the DROP platform launched on January 1, 2026. - Track whether the business meets the conditions for annual cybersecurity audit duties - Track whether any processing requires a risk assessment before initiation - Watch ADMT related obligations where automated decision tools are used - Track data broker registration and DROP obligations if the model fits ## How to use the tracker The tracker should feed engineering, legal, and procurement backlogs. If it only lists dates without showing affected controls, it will not change implementation quality. - Map each rule update to a specific owner and delivery item - Review the CPPA updates page and OAL records regularly - Keep evidence of when each internal template was updated to the new rule - Use the tracker as the calendar source for California governance reviews *Recommended next step* *Placement: near the end of the main content before related guides* ## Use California CPRA CPPA Regulations Tracker as a cited research workflow Research Copilot can take California CPRA CPPA Regulations Tracker from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CPRA CPPA Regulations Tracker](/solutions/research-copilot.md): Start from California CPRA CPPA Regulations Tracker and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA CPPA Regulations Tracker. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/cppa-regulations-tracker --- --- title: "CPPA Regulations Tracker" canonical_url: "https://www.sorena.io/artifacts/us/cpra/cppa-regulations-tracker" source_url: "https://www.sorena.io/artifacts/us/cpra/cppa-regulations-tracker" author: "Sorena AI" description: "Track the California rules that changed the operating baseline in 2026 and the related regulator outputs." keywords: - "CPPA regulations tracker" - "California privacy rulemaking" - "CPRA regulations 2026" - "CPPA updates" - "CPRA" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPPA Regulations Tracker Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. *Rulemaking* *CPRA* ## California CPRA CPPA Regulations Tracker Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. The California rulemaking story now spans more than one wave of regulations. The tracker should show what is already effective, what has a future deadline, and what still needs monitoring. ## Already effective rule milestones The first major CPPA regulations took effect in 2023. A later package of California rules became effective on January 1, 2026 and now shapes the current baseline for many programmes. - January 1, 2023: CPRA changes operative - July 1, 2023: CPPA administrative enforcement begins - January 1, 2026: updated California regulations become effective - Tag each effective rule to the notices, rights, contracts, or assurance controls it changes ## High impact 2026 areas The highest impact current areas are cybersecurity audits, risk assessments, ADMT related rules, and California data broker developments including the DROP platform launched on January 1, 2026. - Track whether the business meets the conditions for annual cybersecurity audit duties - Track whether any processing requires a risk assessment before initiation - Watch ADMT related obligations where automated decision tools are used - Track data broker registration and DROP obligations if the model fits ## How to use the tracker The tracker should feed engineering, legal, and procurement backlogs. If it only lists dates without showing affected controls, it will not change implementation quality. - Map each rule update to a specific owner and delivery item - Review the CPPA updates page and OAL records regularly - Keep evidence of when each internal template was updated to the new rule - Use the tracker as the calendar source for California governance reviews *Recommended next step* *Placement: near the end of the main content before related guides* ## Use California CPRA CPPA Regulations Tracker as a cited research workflow Research Copilot can take California CPRA CPPA Regulations Tracker from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CPRA CPPA Regulations Tracker](/solutions/research-copilot.md): Start from California CPRA CPPA Regulations Tracker and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA CPPA Regulations Tracker. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/cppa-regulations-tracker --- --- title: "CPRA Risk Assessment Template" canonical_url: "https://www.sorena.io/artifacts/us/cpra/cpra-risk-assessment-template" source_url: "https://www.sorena.io/artifacts/us/cpra/cpra-risk-assessment-template" author: "Sorena AI" description: "Use a California specific template that matches the current rule structure instead of a generic DPIA form." keywords: - "CPRA risk assessment template" - "California risk assessment" - "CPRA 7152 template" - "CPRA risk report" - "CPRA" - "Risk Assessment Template" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Risk Assessment Template Use a California specific template that matches the current rule structure instead of a generic DPIA form. *Template* *CPRA* ## California CPRA Risk Assessment Template Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. A California risk assessment report should be written so the business can use it before launching the processing and then update it when the activity changes. ## Minimum report structure The current California model expects the risk assessment report to identify the specific purpose of the processing, the categories of personal information and any SPI involved, the collection, use, disclosure, sharing, and retention model, and the operational details of the processing. - State the exact processing purpose and the decision maker considering the activity - List categories of personal information and SPI involved - Describe collection sources, recipients, retention period, and technology used - Record the service providers, contractors, or third parties involved ## Balancing and safeguards The report should identify the likely negative impacts to consumers, the safeguards already planned, and whether those safeguards reduce the risks enough to justify proceeding. - Describe concrete negative impacts such as discrimination, financial harm, or unwanted disclosure - Document safeguards, alternatives considered, and residual risk - State whether the business will initiate the processing after review - Identify the people who supplied information and the person who approved the assessment ## Timing and maintenance The California rules require the assessment before initiating the relevant processing. They also require review at least once every three years and an update after material change as soon as feasible but no later than 45 calendar days from the change. - Run the first assessment before launch for new covered processing - Review at least every three years and faster after material change - Update within 45 calendar days if a material change creates new or greater impacts - Prepare for December 31, 2027 and April 1, 2028 timing where the transitional rules apply *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep California CPRA Risk Assessment Template in one governed evidence system SSOT can take California CPRA Risk Assessment Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for California CPRA Risk Assessment Template](/solutions/ssot.md): Start from California CPRA Risk Assessment Template and keep documents, evidence, and control records in one governed system. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Risk Assessment Template. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/cpra-risk-assessment-template --- --- title: "CPRA Risk Assessment Template" canonical_url: "https://www.sorena.io/artifacts/us/cpra/cpra-risk-assessment-template" source_url: "https://www.sorena.io/artifacts/us/cpra/cpra-risk-assessment-template" author: "Sorena AI" description: "Use a California specific template that matches the current rule structure instead of a generic DPIA form." keywords: - "CPRA risk assessment template" - "California risk assessment" - "CPRA 7152 template" - "CPRA risk report" - "CPRA" - "Risk Assessment Template" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Risk Assessment Template Use a California specific template that matches the current rule structure instead of a generic DPIA form. *Template* *CPRA* ## California CPRA Risk Assessment Template Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. A California risk assessment report should be written so the business can use it before launching the processing and then update it when the activity changes. ## Minimum report structure The current California model expects the risk assessment report to identify the specific purpose of the processing, the categories of personal information and any SPI involved, the collection, use, disclosure, sharing, and retention model, and the operational details of the processing. - State the exact processing purpose and the decision maker considering the activity - List categories of personal information and SPI involved - Describe collection sources, recipients, retention period, and technology used - Record the service providers, contractors, or third parties involved ## Balancing and safeguards The report should identify the likely negative impacts to consumers, the safeguards already planned, and whether those safeguards reduce the risks enough to justify proceeding. - Describe concrete negative impacts such as discrimination, financial harm, or unwanted disclosure - Document safeguards, alternatives considered, and residual risk - State whether the business will initiate the processing after review - Identify the people who supplied information and the person who approved the assessment ## Timing and maintenance The California rules require the assessment before initiating the relevant processing. They also require review at least once every three years and an update after material change as soon as feasible but no later than 45 calendar days from the change. - Run the first assessment before launch for new covered processing - Review at least every three years and faster after material change - Update within 45 calendar days if a material change creates new or greater impacts - Prepare for December 31, 2027 and April 1, 2028 timing where the transitional rules apply *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep California CPRA Risk Assessment Template in one governed evidence system SSOT can take California CPRA Risk Assessment Template from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for California CPRA Risk Assessment Template](/solutions/ssot.md): Start from California CPRA Risk Assessment Template and keep documents, evidence, and control records in one governed system. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Risk Assessment Template. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/cpra-risk-assessment-template --- --- title: "CPRA vs Colorado Privacy Act" canonical_url: "https://www.sorena.io/artifacts/us/cpra/cpra-vs-colorado-privacy-act" source_url: "https://www.sorena.io/artifacts/us/cpra/cpra-vs-colorado-privacy-act" author: "Sorena AI" description: "Compare the California and Colorado models before reusing a state privacy template across both." keywords: - "CPRA vs Colorado Privacy Act" - "California vs Colorado privacy" - "state privacy comparison" - "CPRA" - "vs Colorado Privacy Act" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA vs Colorado Privacy Act Compare the California and Colorado models before reusing a state privacy template across both. *Comparison* *CPRA* ## California CPRA vs Colorado Privacy Act Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. CPRA and the Colorado Privacy Act can share a control foundation, but a business should not assume a Colorado assessment, universal opt out, or notice design fully satisfies California. ## Where the two laws align Both laws use modern consumer privacy concepts such as access style rights, deletion, correction, contract restrictions on processors or recipients, and some form of risk assessment for high risk processing. - Reuse core data inventory and rights governance across both states - Reuse vendor oversight and security evidence where the facts match - Keep one common privacy engineering vocabulary where possible - Use state overlays for timing and interface differences ## Where California differs California remains threshold based and deeply tied to the CCPA and CPPA rulemaking structure. California also has its own concepts around SPI, do not sell or share, GPC handling, and California specific contract wording. - Do not assume a Colorado assessment automatically matches California section 7152 content - Retain California specific notices for sale, sharing, and SPI limitation - Keep separate California recipient clauses and remediation rights - Track GPC handling under California rather than relying on another state design ## Programme strategy The best state privacy design is one shared baseline plus state specific overlays for interfaces, deadlines, submission requirements, and regulator expectations. - Maintain a state by state differences register - Use one intake workflow with state specific right labels and timing - Keep California and Colorado assessment templates cross mapped but not identical - Train teams on where one state control does not satisfy the other *Recommended next step* *Placement: after the comparison section* ## Use California CPRA vs Colorado Privacy Act as a cited research workflow Research Copilot can take California CPRA vs Colorado Privacy Act from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CPRA vs Colorado Privacy Act](/solutions/research-copilot.md): Start from California CPRA vs Colorado Privacy Act and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA vs Colorado Privacy Act. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/cpra-vs-colorado-privacy-act --- --- title: "CPRA vs Colorado Privacy Act" canonical_url: "https://www.sorena.io/artifacts/us/cpra/cpra-vs-colorado-privacy-act" source_url: "https://www.sorena.io/artifacts/us/cpra/cpra-vs-colorado-privacy-act" author: "Sorena AI" description: "Compare the California and Colorado models before reusing a state privacy template across both." keywords: - "CPRA vs Colorado Privacy Act" - "California vs Colorado privacy" - "state privacy comparison" - "CPRA" - "vs Colorado Privacy Act" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA vs Colorado Privacy Act Compare the California and Colorado models before reusing a state privacy template across both. *Comparison* *CPRA* ## California CPRA vs Colorado Privacy Act Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. CPRA and the Colorado Privacy Act can share a control foundation, but a business should not assume a Colorado assessment, universal opt out, or notice design fully satisfies California. ## Where the two laws align Both laws use modern consumer privacy concepts such as access style rights, deletion, correction, contract restrictions on processors or recipients, and some form of risk assessment for high risk processing. - Reuse core data inventory and rights governance across both states - Reuse vendor oversight and security evidence where the facts match - Keep one common privacy engineering vocabulary where possible - Use state overlays for timing and interface differences ## Where California differs California remains threshold based and deeply tied to the CCPA and CPPA rulemaking structure. California also has its own concepts around SPI, do not sell or share, GPC handling, and California specific contract wording. - Do not assume a Colorado assessment automatically matches California section 7152 content - Retain California specific notices for sale, sharing, and SPI limitation - Keep separate California recipient clauses and remediation rights - Track GPC handling under California rather than relying on another state design ## Programme strategy The best state privacy design is one shared baseline plus state specific overlays for interfaces, deadlines, submission requirements, and regulator expectations. - Maintain a state by state differences register - Use one intake workflow with state specific right labels and timing - Keep California and Colorado assessment templates cross mapped but not identical - Train teams on where one state control does not satisfy the other *Recommended next step* *Placement: after the comparison section* ## Use California CPRA vs Colorado Privacy Act as a cited research workflow Research Copilot can take California CPRA vs Colorado Privacy Act from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CPRA vs Colorado Privacy Act](/solutions/research-copilot.md): Start from California CPRA vs Colorado Privacy Act and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA vs Colorado Privacy Act. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/cpra-vs-colorado-privacy-act --- --- title: "CPRA vs Virginia VCDPA" canonical_url: "https://www.sorena.io/artifacts/us/cpra/cpra-vs-virginia-vcdpa" source_url: "https://www.sorena.io/artifacts/us/cpra/cpra-vs-virginia-vcdpa" author: "Sorena AI" description: "Compare California and Virginia privacy models before reusing contracts or request flows across both." keywords: - "CPRA vs VCDPA" - "California vs Virginia privacy" - "state privacy law comparison" - "CPRA" - "vs Virginia VCDPA" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA vs Virginia VCDPA Compare California and Virginia privacy models before reusing contracts or request flows across both. *Comparison* *CPRA* ## California CPRA vs Virginia VCDPA Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. The Virginia VCDPA and California CPRA share modern privacy concepts, but California has a much more detailed notice, opt out, and rulemaking environment. ## Shared structure Both states use rights, processor style contracts, and high risk assessment concepts. That means a business can often reuse the same inventory, governance, and security backbone. - Reuse data mapping, retention, and vendor oversight foundations - Use one core workflow for access, deletion, and correction style requests - Share high risk processing review governance where possible - Maintain state specific overlays for notices and opt outs ## California specific complexity California adds a threshold based business test, a more detailed consumer notice architecture, GPC and do not sell or share mechanics, SPI limitation rules, and a more active specialised regulator with continuous rulemaking. - Keep California specific disclosures for sale, sharing, SPI, and GPC - Do not assume a Virginia processor contract is enough for California - Track California rule changes continuously through the CPPA - Use California as the stricter build pattern for opt out user journeys ## How to run both states If you support both states, keep one programme with clear state flags. Trying to remember the differences ad hoc will lead to the wrong notice or the wrong contract rider. - Tag request workflows by state and right type - Maintain separate notice text libraries by state - Cross map assessment templates so California specific fields are not lost - Review vendor clauses for each state when sharing or selling is involved *Recommended next step* *Placement: after the comparison section* ## Use California CPRA vs Virginia VCDPA as a cited research workflow Research Copilot can take California CPRA vs Virginia VCDPA from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CPRA vs Virginia VCDPA](/solutions/research-copilot.md): Start from California CPRA vs Virginia VCDPA and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA vs Virginia VCDPA. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/cpra-vs-virginia-vcdpa --- --- title: "CPRA vs Virginia VCDPA" canonical_url: "https://www.sorena.io/artifacts/us/cpra/cpra-vs-virginia-vcdpa" source_url: "https://www.sorena.io/artifacts/us/cpra/cpra-vs-virginia-vcdpa" author: "Sorena AI" description: "Compare California and Virginia privacy models before reusing contracts or request flows across both." keywords: - "CPRA vs VCDPA" - "California vs Virginia privacy" - "state privacy law comparison" - "CPRA" - "vs Virginia VCDPA" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA vs Virginia VCDPA Compare California and Virginia privacy models before reusing contracts or request flows across both. *Comparison* *CPRA* ## California CPRA vs Virginia VCDPA Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. The Virginia VCDPA and California CPRA share modern privacy concepts, but California has a much more detailed notice, opt out, and rulemaking environment. ## Shared structure Both states use rights, processor style contracts, and high risk assessment concepts. That means a business can often reuse the same inventory, governance, and security backbone. - Reuse data mapping, retention, and vendor oversight foundations - Use one core workflow for access, deletion, and correction style requests - Share high risk processing review governance where possible - Maintain state specific overlays for notices and opt outs ## California specific complexity California adds a threshold based business test, a more detailed consumer notice architecture, GPC and do not sell or share mechanics, SPI limitation rules, and a more active specialised regulator with continuous rulemaking. - Keep California specific disclosures for sale, sharing, SPI, and GPC - Do not assume a Virginia processor contract is enough for California - Track California rule changes continuously through the CPPA - Use California as the stricter build pattern for opt out user journeys ## How to run both states If you support both states, keep one programme with clear state flags. Trying to remember the differences ad hoc will lead to the wrong notice or the wrong contract rider. - Tag request workflows by state and right type - Maintain separate notice text libraries by state - Cross map assessment templates so California specific fields are not lost - Review vendor clauses for each state when sharing or selling is involved *Recommended next step* *Placement: after the comparison section* ## Use California CPRA vs Virginia VCDPA as a cited research workflow Research Copilot can take California CPRA vs Virginia VCDPA from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CPRA vs Virginia VCDPA](/solutions/research-copilot.md): Start from California CPRA vs Virginia VCDPA and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA vs Virginia VCDPA. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/cpra-vs-virginia-vcdpa --- --- title: "CPRA Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/us/cpra/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/us/cpra/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Use the dates that matter for the current California privacy regime." keywords: - "CPRA deadlines" - "CPRA calendar" - "California privacy timeline 2026" - "CPPA deadlines" - "CPRA" - "Deadlines and Compliance Calendar" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Deadlines and Compliance Calendar Use the dates that matter for the current California privacy regime. *Calendar* *CPRA* ## California CPRA Deadlines and Compliance Calendar Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. A good California privacy calendar keeps older commencement dates in view but also surfaces the first real operational deadlines created by the 2026 rules. ## Core regime dates CPRA changes became operative on January 1, 2023 and CPPA administrative enforcement began on July 1, 2023. A later California rule package became effective on January 1, 2026 and now shapes the live baseline. - January 1, 2023: CPRA changes operative - July 1, 2023: CPPA enforcement begins - January 1, 2026: updated California regulations effective - January 1, 2026: DROP launches for registered data brokers ## Recurring and future deadlines Consumer request timing remains central, but the newer California rules add transitional and recurring dates for risk assessments, cybersecurity audits, and data broker duties where applicable. - 45 days for most consumer rights responses, with one 45 day extension where justified - At least 24 months of request records and related programme evidence - December 31, 2027: transitional deadline identified in current materials for certain ongoing risk assessments - April 1, 2028: first risk assessment information submission deadline for 2026 and 2027 assessments *Recommended next step* *Placement: after the timeline or milestone section* ## Turn California CPRA Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take California CPRA Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CPRA Deadlines and Compliance Calendar](/solutions/assessment.md): Start from California CPRA Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Deadlines and Compliance Calendar. ## Planning dates for larger businesses Current California materials also point to phased first cybersecurity audit deadlines tied to revenue size. Larger businesses should build those dates into the governance calendar before the threshold year closes. - April 1, 2028: first audit report deadline for businesses above 100 million dollars in 2026 revenue - April 1, 2029: first audit report deadline for businesses between 50 million and 100 million dollars in 2027 revenue - Annual January data broker registration cycle where the business qualifies as a data broker - Annual rule and notice review each Q1 so California disclosures stay current ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/deadlines-and-compliance-calendar --- --- title: "CPRA Deadlines and Compliance Calendar" canonical_url: "https://www.sorena.io/artifacts/us/cpra/deadlines-and-compliance-calendar" source_url: "https://www.sorena.io/artifacts/us/cpra/deadlines-and-compliance-calendar" author: "Sorena AI" description: "Use the dates that matter for the current California privacy regime." keywords: - "CPRA deadlines" - "CPRA calendar" - "California privacy timeline 2026" - "CPPA deadlines" - "CPRA" - "Deadlines and Compliance Calendar" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Deadlines and Compliance Calendar Use the dates that matter for the current California privacy regime. *Calendar* *CPRA* ## California CPRA Deadlines and Compliance Calendar Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. A good California privacy calendar keeps older commencement dates in view but also surfaces the first real operational deadlines created by the 2026 rules. ## Core regime dates CPRA changes became operative on January 1, 2023 and CPPA administrative enforcement began on July 1, 2023. A later California rule package became effective on January 1, 2026 and now shapes the live baseline. - January 1, 2023: CPRA changes operative - July 1, 2023: CPPA enforcement begins - January 1, 2026: updated California regulations effective - January 1, 2026: DROP launches for registered data brokers ## Recurring and future deadlines Consumer request timing remains central, but the newer California rules add transitional and recurring dates for risk assessments, cybersecurity audits, and data broker duties where applicable. - 45 days for most consumer rights responses, with one 45 day extension where justified - At least 24 months of request records and related programme evidence - December 31, 2027: transitional deadline identified in current materials for certain ongoing risk assessments - April 1, 2028: first risk assessment information submission deadline for 2026 and 2027 assessments *Recommended next step* *Placement: after the timeline or milestone section* ## Turn California CPRA Deadlines and Compliance Calendar into an operational assessment Assessment Autopilot can take California CPRA Deadlines and Compliance Calendar from planning deadlines, owners, and milestones from this page to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CPRA Deadlines and Compliance Calendar](/solutions/assessment.md): Start from California CPRA Deadlines and Compliance Calendar and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Deadlines and Compliance Calendar. ## Planning dates for larger businesses Current California materials also point to phased first cybersecurity audit deadlines tied to revenue size. Larger businesses should build those dates into the governance calendar before the threshold year closes. - April 1, 2028: first audit report deadline for businesses above 100 million dollars in 2026 revenue - April 1, 2029: first audit report deadline for businesses between 50 million and 100 million dollars in 2027 revenue - Annual January data broker registration cycle where the business qualifies as a data broker - Annual rule and notice review each Q1 so California disclosures stay current ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/deadlines-and-compliance-calendar --- --- title: "CPRA FAQ" canonical_url: "https://www.sorena.io/artifacts/us/cpra/faq" source_url: "https://www.sorena.io/artifacts/us/cpra/faq" author: "Sorena AI" description: "Answer the California questions that stall CPRA implementation decisions." keywords: - "CPRA FAQ" - "California privacy FAQ" - "CPRA SPI questions" - "CPRA risk assessment FAQ" - "CPRA" - "FAQ" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA FAQ Answer the California questions that stall CPRA implementation decisions. *FAQ* *CPRA* ## California CPRA FAQ Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. The fastest way to improve a California programme is to answer the recurring edge case questions once and make those answers reusable. ## Scope and SPI questions Common questions include whether the business meets a threshold, whether a use of SPI falls inside the permitted purposes, and whether a limit right notice is required. - Confirm the threshold result with dated finance and volume evidence - Map SPI categories to the specific purpose that justifies each use - Check whether the use falls inside the permitted purpose list before assuming the right to limit does not apply - Record the answer in the notice and control register ## Rights and contract questions Teams also ask when GPC must be treated as a valid signal, how correction differs from access, and whether a vendor truly qualifies as a service provider or contractor. - Process GPC as a valid opt out preference signal in the California workflow - Treat correction as a separate request type with its own verification logic - Use contract purpose limits and due diligence to distinguish service providers, contractors, and third parties - Make sure downstream parties can execute deletion, opt out, and limit instructions ## Assessment and future rule questions Another frequent question is whether the business needs to prepare now for risk assessments, cybersecurity audits, or data broker obligations. - Watch the current California trigger categories for risk assessments - Review revenue size and data practices against the newer audit rules - Check whether the business acts as a California data broker - Use the rule tracker to turn future obligations into planned implementation work *Recommended next step* *Placement: after the FAQ section* ## Use California CPRA FAQ as a cited research workflow Research Copilot can take California CPRA FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CPRA FAQ](/solutions/research-copilot.md): Start from California CPRA FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA FAQ. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/faq --- --- title: "CPRA FAQ" canonical_url: "https://www.sorena.io/artifacts/us/cpra/faq" source_url: "https://www.sorena.io/artifacts/us/cpra/faq" author: "Sorena AI" description: "Answer the California questions that stall CPRA implementation decisions." keywords: - "CPRA FAQ" - "California privacy FAQ" - "CPRA SPI questions" - "CPRA risk assessment FAQ" - "CPRA" - "FAQ" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA FAQ Answer the California questions that stall CPRA implementation decisions. *FAQ* *CPRA* ## California CPRA FAQ Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. The fastest way to improve a California programme is to answer the recurring edge case questions once and make those answers reusable. ## Scope and SPI questions Common questions include whether the business meets a threshold, whether a use of SPI falls inside the permitted purposes, and whether a limit right notice is required. - Confirm the threshold result with dated finance and volume evidence - Map SPI categories to the specific purpose that justifies each use - Check whether the use falls inside the permitted purpose list before assuming the right to limit does not apply - Record the answer in the notice and control register ## Rights and contract questions Teams also ask when GPC must be treated as a valid signal, how correction differs from access, and whether a vendor truly qualifies as a service provider or contractor. - Process GPC as a valid opt out preference signal in the California workflow - Treat correction as a separate request type with its own verification logic - Use contract purpose limits and due diligence to distinguish service providers, contractors, and third parties - Make sure downstream parties can execute deletion, opt out, and limit instructions ## Assessment and future rule questions Another frequent question is whether the business needs to prepare now for risk assessments, cybersecurity audits, or data broker obligations. - Watch the current California trigger categories for risk assessments - Review revenue size and data practices against the newer audit rules - Check whether the business acts as a California data broker - Use the rule tracker to turn future obligations into planned implementation work *Recommended next step* *Placement: after the FAQ section* ## Use California CPRA FAQ as a cited research workflow Research Copilot can take California CPRA FAQ from cited answers to recurring questions on this topic to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CPRA FAQ](/solutions/research-copilot.md): Start from California CPRA FAQ and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA FAQ. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/faq --- --- title: "CPRA Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/us/cpra/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/us/cpra/penalties-and-fines" author: "Sorena AI" description: "Understand what makes California exposure larger, faster, and harder to defend." keywords: - "CPRA penalties" - "CPRA fines" - "California privacy fines" - "CPPA enforcement exposure" - "CPRA" - "Penalties and Fines" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Penalties and Fines Understand what makes California exposure larger, faster, and harder to defend. *Penalties* *CPRA* ## California CPRA Penalties and Fines Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. In California, penalty exposure is multiplied by volume, duration, and evidence quality. Programmes that cannot prove what they did often face higher practical risk than those with the same underlying defect but better records. ## Civil penalties California civil penalties can reach 2,500 dollars per violation or 7,500 dollars per intentional violation or violation involving consumers under 16. Large scale defects in notices, opt out mechanics, or contracts can therefore multiply quickly. - Count exposure by affected consumer interactions and duration - Treat youth data, sharing, and GPC defects as high attention issues - Retain evidence that notices and technical controls matched reality - Escalate repeat defects rather than accepting recurring exceptions *Recommended next step* *Placement: after the enforcement section* ## Use California CPRA Penalties and Fines as a cited research workflow Research Copilot can take California CPRA Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CPRA Penalties and Fines](/solutions/research-copilot.md): Start from California CPRA Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Penalties and Fines. ## Security and private action exposure California also creates security related private action exposure for certain incidents where reasonable security was lacking. - Keep evidence of reasonable security procedures and practices - Link incident response and remediation records to the privacy programme - Track vendor security obligations and testing results - Review whether California notice statements about security are supportable ## How to lower exposure The biggest reduction usually comes from accurate notices, functioning rights and GPC flows, real contract oversight, and forward planning for the newer California rules. - Fix stale notice and suppression defects before they become a pattern - Use contract rights to stop and remediate vendor misuse - Prepare for assessment and audit duties before the first filing date arrives - Retain a clean record of management review and remediation decisions ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/penalties-and-fines --- --- title: "CPRA Penalties and Fines" canonical_url: "https://www.sorena.io/artifacts/us/cpra/penalties-and-fines" source_url: "https://www.sorena.io/artifacts/us/cpra/penalties-and-fines" author: "Sorena AI" description: "Understand what makes California exposure larger, faster, and harder to defend." keywords: - "CPRA penalties" - "CPRA fines" - "California privacy fines" - "CPPA enforcement exposure" - "CPRA" - "Penalties and Fines" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Penalties and Fines Understand what makes California exposure larger, faster, and harder to defend. *Penalties* *CPRA* ## California CPRA Penalties and Fines Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. In California, penalty exposure is multiplied by volume, duration, and evidence quality. Programmes that cannot prove what they did often face higher practical risk than those with the same underlying defect but better records. ## Civil penalties California civil penalties can reach 2,500 dollars per violation or 7,500 dollars per intentional violation or violation involving consumers under 16. Large scale defects in notices, opt out mechanics, or contracts can therefore multiply quickly. - Count exposure by affected consumer interactions and duration - Treat youth data, sharing, and GPC defects as high attention issues - Retain evidence that notices and technical controls matched reality - Escalate repeat defects rather than accepting recurring exceptions *Recommended next step* *Placement: after the enforcement section* ## Use California CPRA Penalties and Fines as a cited research workflow Research Copilot can take California CPRA Penalties and Fines from understanding exposure and enforcement with cited answers to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CPRA Penalties and Fines](/solutions/research-copilot.md): Start from California CPRA Penalties and Fines and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Penalties and Fines. ## Security and private action exposure California also creates security related private action exposure for certain incidents where reasonable security was lacking. - Keep evidence of reasonable security procedures and practices - Link incident response and remediation records to the privacy programme - Track vendor security obligations and testing results - Review whether California notice statements about security are supportable ## How to lower exposure The biggest reduction usually comes from accurate notices, functioning rights and GPC flows, real contract oversight, and forward planning for the newer California rules. - Fix stale notice and suppression defects before they become a pattern - Use contract rights to stop and remediate vendor misuse - Prepare for assessment and audit duties before the first filing date arrives - Retain a clean record of management review and remediation decisions ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/penalties-and-fines --- --- title: "CPRA Requirements" canonical_url: "https://www.sorena.io/artifacts/us/cpra/requirements" source_url: "https://www.sorena.io/artifacts/us/cpra/requirements" author: "Sorena AI" description: "Translate the current California regime into control statements that teams can build and test." keywords: - "CPRA requirements" - "California privacy requirements" - "CPRA controls" - "CPRA SPI requirements" - "CPRA" - "Requirements" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Requirements Translate the current California regime into control statements that teams can build and test. *Requirements* *CPRA* ## California CPRA Requirements Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. The California requirement model is easier to run when it is grouped into control domains and each domain has a named owner and evidence output. ## Baseline California domains The baseline domains cover scope, notice architecture, rights workflows, GPC or opt out preference signals, recordkeeping, and recipient contracts. Every in scope business starts here. - Threshold and exemption analysis with annual review - Notice at collection, privacy policy, and opt out notice controls - Delete, correct, know, opt out, and limit workflows as applicable - 24 month request and response recordkeeping ## CPRA specific domains The second layer covers SPI, sharing, contractor and third party terms, due diligence, and notice details that became more important under the amended regime. - SPI classification and right to limit logic - Sharing and cross context advertising governance - Service provider, contractor, and third party clauses with enforcement rights - Due diligence and documentation showing the business did not ignore misuse risk ## 2026 assurance domains The latest California rules add or clarify risk assessments, cybersecurity audits, ADMT related duties, and new data broker workflows. - Risk assessment triggers, report content, and update timing - Cybersecurity audit thresholds, evidence, and reporting cycle - ADMT and related processing controls where the rules apply - Data broker registration and DROP obligations where relevant *Recommended next step* *Placement: after the requirement breakdown* ## Turn California CPRA Requirements into an operational assessment Assessment Autopilot can take California CPRA Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CPRA Requirements](/solutions/assessment.md): Start from California CPRA Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Requirements. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/requirements --- --- title: "CPRA Requirements" canonical_url: "https://www.sorena.io/artifacts/us/cpra/requirements" source_url: "https://www.sorena.io/artifacts/us/cpra/requirements" author: "Sorena AI" description: "Translate the current California regime into control statements that teams can build and test." keywords: - "CPRA requirements" - "California privacy requirements" - "CPRA controls" - "CPRA SPI requirements" - "CPRA" - "Requirements" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Requirements Translate the current California regime into control statements that teams can build and test. *Requirements* *CPRA* ## California CPRA Requirements Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. The California requirement model is easier to run when it is grouped into control domains and each domain has a named owner and evidence output. ## Baseline California domains The baseline domains cover scope, notice architecture, rights workflows, GPC or opt out preference signals, recordkeeping, and recipient contracts. Every in scope business starts here. - Threshold and exemption analysis with annual review - Notice at collection, privacy policy, and opt out notice controls - Delete, correct, know, opt out, and limit workflows as applicable - 24 month request and response recordkeeping ## CPRA specific domains The second layer covers SPI, sharing, contractor and third party terms, due diligence, and notice details that became more important under the amended regime. - SPI classification and right to limit logic - Sharing and cross context advertising governance - Service provider, contractor, and third party clauses with enforcement rights - Due diligence and documentation showing the business did not ignore misuse risk ## 2026 assurance domains The latest California rules add or clarify risk assessments, cybersecurity audits, ADMT related duties, and new data broker workflows. - Risk assessment triggers, report content, and update timing - Cybersecurity audit thresholds, evidence, and reporting cycle - ADMT and related processing controls where the rules apply - Data broker registration and DROP obligations where relevant *Recommended next step* *Placement: after the requirement breakdown* ## Turn California CPRA Requirements into an operational assessment Assessment Autopilot can take California CPRA Requirements from turning the requirements into assigned actions to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Assessment Autopilot for California CPRA Requirements](/solutions/assessment.md): Start from California CPRA Requirements and turn the guidance into owned tasks, evidence requests, and review checkpoints. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Requirements. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/requirements --- --- title: "CPRA Risk Assessments and Cybersecurity Audits" canonical_url: "https://www.sorena.io/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits" source_url: "https://www.sorena.io/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits" author: "Sorena AI" description: "Prepare for the California assurance duties that now have real structure, timing, and evidence requirements." keywords: - "CPRA risk assessments" - "CPRA cybersecurity audits" - "California privacy audit" - "California risk assessment" - "CPRA" - "Risk Assessments and Cybersecurity Audits" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Risk Assessments and Cybersecurity Audits Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. *Assurance* *CPRA* ## California CPRA Risk Assessments and Cybersecurity Audits Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. California has moved from abstract privacy risk language to more operational rules for risk assessments and cybersecurity audits. The result is a new assurance layer that privacy and security teams need to build together. ## Risk assessment duties Current California materials require a risk assessment before initiating covered high risk processing. The report should identify purpose, categories, SPI, methods, retention, recipients, likely negative impacts, safeguards, and the decision whether to proceed. - Run the assessment before launch for covered processing - Document categories, SPI, retention, recipients, safeguards, and residual risk - Review at least every three years and faster after material change - Track the current California transitional deadline of December 31, 2027 and the April 1, 2028 first submission date where applicable ## Cybersecurity audit duties Current California materials also set out annual cybersecurity audit duties for larger businesses, with phased first deadlines tied to revenue. The audit must be independent, evidence based, and supported by retained documents for five years. - Plan for April 1, 2028 or April 1, 2029 first audit timing if the revenue thresholds are met - Use a qualified and objective auditor and retain the evidence for five years - Cover identity and access management, logging, incident response, training, and vendor oversight - Keep signoff and management review evidence with the audit record ## How to operationalise the assurance layer The privacy team should not try to run these obligations alone. The best model is a joint privacy, security, engineering, and procurement workflow that uses the same inventory and vendor facts that already drive notices and contracts. - Use one intake path for new processing that may trigger assessments or audits - Reuse existing security and state law assessments only when the California content is complete - Prepare a regulator production pack in case the CPPA or Attorney General requests the underlying report - Map assessment and audit findings into remediation plans with named owners *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep California CPRA Risk Assessments and Cybersecurity Audits in one governed evidence system SSOT can take California CPRA Risk Assessments and Cybersecurity Audits from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for California CPRA Risk Assessments and Cybersecurity Audits](/solutions/ssot.md): Start from California CPRA Risk Assessments and Cybersecurity Audits and keep documents, evidence, and control records in one governed system. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Risk Assessments and Cybersecurity Audits. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits --- --- title: "CPRA Risk Assessments and Cybersecurity Audits" canonical_url: "https://www.sorena.io/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits" source_url: "https://www.sorena.io/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits" author: "Sorena AI" description: "Prepare for the California assurance duties that now have real structure, timing, and evidence requirements." keywords: - "CPRA risk assessments" - "CPRA cybersecurity audits" - "California privacy audit" - "California risk assessment" - "CPRA" - "Risk Assessments and Cybersecurity Audits" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Risk Assessments and Cybersecurity Audits Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. *Assurance* *CPRA* ## California CPRA Risk Assessments and Cybersecurity Audits Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. California has moved from abstract privacy risk language to more operational rules for risk assessments and cybersecurity audits. The result is a new assurance layer that privacy and security teams need to build together. ## Risk assessment duties Current California materials require a risk assessment before initiating covered high risk processing. The report should identify purpose, categories, SPI, methods, retention, recipients, likely negative impacts, safeguards, and the decision whether to proceed. - Run the assessment before launch for covered processing - Document categories, SPI, retention, recipients, safeguards, and residual risk - Review at least every three years and faster after material change - Track the current California transitional deadline of December 31, 2027 and the April 1, 2028 first submission date where applicable ## Cybersecurity audit duties Current California materials also set out annual cybersecurity audit duties for larger businesses, with phased first deadlines tied to revenue. The audit must be independent, evidence based, and supported by retained documents for five years. - Plan for April 1, 2028 or April 1, 2029 first audit timing if the revenue thresholds are met - Use a qualified and objective auditor and retain the evidence for five years - Cover identity and access management, logging, incident response, training, and vendor oversight - Keep signoff and management review evidence with the audit record ## How to operationalise the assurance layer The privacy team should not try to run these obligations alone. The best model is a joint privacy, security, engineering, and procurement workflow that uses the same inventory and vendor facts that already drive notices and contracts. - Use one intake path for new processing that may trigger assessments or audits - Reuse existing security and state law assessments only when the California content is complete - Prepare a regulator production pack in case the CPPA or Attorney General requests the underlying report - Map assessment and audit findings into remediation plans with named owners *Recommended next step* *Placement: after the template, evidence, or documentation block* ## Keep California CPRA Risk Assessments and Cybersecurity Audits in one governed evidence system SSOT can take California CPRA Risk Assessments and Cybersecurity Audits from reusing this material inside a governed evidence system to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open SSOT for California CPRA Risk Assessments and Cybersecurity Audits](/solutions/ssot.md): Start from California CPRA Risk Assessments and Cybersecurity Audits and keep documents, evidence, and control records in one governed system. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Risk Assessments and Cybersecurity Audits. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Sensitive Personal Information | California SPI Guide](/artifacts/us/cpra/sensitive-personal-information.md): Handle SPI with the level of design and evidence the California rules now expect. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits --- --- title: "CPRA Sensitive Personal Information" canonical_url: "https://www.sorena.io/artifacts/us/cpra/sensitive-personal-information" source_url: "https://www.sorena.io/artifacts/us/cpra/sensitive-personal-information" author: "Sorena AI" description: "Handle SPI with the level of design and evidence the California rules now expect." keywords: - "CPRA sensitive personal information" - "California SPI" - "right to limit CPRA" - "SPI notice California" - "CPRA" - "Sensitive Personal Information" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Sensitive Personal Information Handle SPI with the level of design and evidence the California rules now expect. *Sensitive Data* *CPRA* ## California CPRA Sensitive Personal Information Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. SPI is one of the clearest examples of how the California regime moved beyond a generic disclosure law. Businesses now need a working model for classification, permitted use analysis, notices, and limitation workflows. ## Classify SPI correctly The first step is to identify where California sensitive personal information appears in systems, profiles, logs, and vendor disclosures. That classification should be tied to the actual purpose for which the data is collected or used. - Create a SPI category inventory across customer, employee, and marketing systems - Map each SPI use to a specific purpose rather than a generic business label - Identify where SPI is exposed to service providers, contractors, or third parties - Review retention periods and masking or minimisation practices for each SPI category ## Permitted purposes and right to limit If the business uses or discloses SPI only for the permitted purposes in the regulations, the right to limit may not apply in the same way. If the business goes beyond those permitted purposes, it should provide the notice of right to limit and implement the workflow. - Test each SPI use against the permitted purpose list in the California rules - Provide the notice of right to limit where the right is triggered - Process requests to limit without making them burdensome - Push limitation instructions to service providers or contractors within the required workflow ## Monitoring and assurance SPI should appear in request metrics, contract reviews, and risk assessment decisions. It is one of the strongest signals that the business should be testing whether collection, use, and sharing remain reasonably necessary and proportionate. - Monitor where SPI is accessed, disclosed, or reused - Review contracts and due diligence for recipients handling SPI - Use SPI in risk assessment trigger analysis and control prioritisation - Retain evidence of limitation handling, notices, and remediation decisions *Recommended next step* *Placement: near the end of the main content before related guides* ## Use California CPRA Sensitive Personal Information as a cited research workflow Research Copilot can take California CPRA Sensitive Personal Information from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CPRA Sensitive Personal Information](/solutions/research-copilot.md): Start from California CPRA Sensitive Personal Information and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Sensitive Personal Information. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/sensitive-personal-information --- --- title: "CPRA Sensitive Personal Information" canonical_url: "https://www.sorena.io/artifacts/us/cpra/sensitive-personal-information" source_url: "https://www.sorena.io/artifacts/us/cpra/sensitive-personal-information" author: "Sorena AI" description: "Handle SPI with the level of design and evidence the California rules now expect." keywords: - "CPRA sensitive personal information" - "California SPI" - "right to limit CPRA" - "SPI notice California" - "CPRA" - "Sensitive Personal Information" - "California privacy" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CPRA Sensitive Personal Information Handle SPI with the level of design and evidence the California rules now expect. *Sensitive Data* *CPRA* ## California CPRA Sensitive Personal Information Grounded in the California statute, CPPA regulations, and the 2026 California rule changes. SPI is one of the clearest examples of how the California regime moved beyond a generic disclosure law. Businesses now need a working model for classification, permitted use analysis, notices, and limitation workflows. ## Classify SPI correctly The first step is to identify where California sensitive personal information appears in systems, profiles, logs, and vendor disclosures. That classification should be tied to the actual purpose for which the data is collected or used. - Create a SPI category inventory across customer, employee, and marketing systems - Map each SPI use to a specific purpose rather than a generic business label - Identify where SPI is exposed to service providers, contractors, or third parties - Review retention periods and masking or minimisation practices for each SPI category ## Permitted purposes and right to limit If the business uses or discloses SPI only for the permitted purposes in the regulations, the right to limit may not apply in the same way. If the business goes beyond those permitted purposes, it should provide the notice of right to limit and implement the workflow. - Test each SPI use against the permitted purpose list in the California rules - Provide the notice of right to limit where the right is triggered - Process requests to limit without making them burdensome - Push limitation instructions to service providers or contractors within the required workflow ## Monitoring and assurance SPI should appear in request metrics, contract reviews, and risk assessment decisions. It is one of the strongest signals that the business should be testing whether collection, use, and sharing remain reasonably necessary and proportionate. - Monitor where SPI is accessed, disclosed, or reused - Review contracts and due diligence for recipients handling SPI - Use SPI in risk assessment trigger analysis and control prioritisation - Retain evidence of limitation handling, notices, and remediation decisions *Recommended next step* *Placement: near the end of the main content before related guides* ## Use California CPRA Sensitive Personal Information as a cited research workflow Research Copilot can take California CPRA Sensitive Personal Information from getting cited answers and faster research on this topic to a reusable workflow inside Sorena. Teams working on California CPRA can keep owners, evidence, and next steps aligned without copying this guide into separate documents. - [Open Research Copilot for California CPRA Sensitive Personal Information](/solutions/research-copilot.md): Start from California CPRA Sensitive Personal Information and answer scope, timing, and interpretation questions with cited outputs. - [Talk through California CPRA](/contact.md): Review your current process, evidence gaps, and next steps for California CPRA Sensitive Personal Information. ## Primary sources - [CPPA regulations](https://cppa.ca.gov/regulations/?ref=sorena.io) - Official California regulations hub. - [California privacy statute effective January 1, 2026](https://cppa.ca.gov/regulations/pdf/ccpa_statute_2026.pdf?ref=sorena.io) - Current statutory text as reflected in CPPA materials. - [CPPA FAQ](https://cppa.ca.gov/faq.html?ref=sorena.io) - Official California FAQ. - [CPPA CCPA updates](https://cppa.ca.gov/ccpa_updates.html?ref=sorena.io) - Rulemaking and effective date updates. ## Related Topic Guides - [CCPA vs CPRA What Changed | California Delta Guide](/artifacts/us/cpra/ccpa-vs-cpra-what-changed.md): Use the actual legal and operational deltas when upgrading an older California programme. - [CPPA Regulations Tracker | California Rulemaking Tracker](/artifacts/us/cpra/cppa-regulations-tracker.md): Track the California rules that changed the operating baseline in 2026 and the related regulator outputs. - [CPRA Applicability Test | California Scope and Trigger Guide](/artifacts/us/cpra/applicability-test.md): Confirm California scope and then identify which CPRA specific obligations activate. - [CPRA Checklist | California Privacy Rights Act Checklist](/artifacts/us/cpra/checklist.md): Track the California privacy workstreams that changed under CPRA and the 2026 rules. - [CPRA Compliance Program | California Operating Model](/artifacts/us/cpra/compliance.md): Run a California programme that can absorb ongoing CPPA rules without constant redesign. - [CPRA Consumer Rights Workflow | California Rights Operations](/artifacts/us/cpra/consumer-rights-workflow.md): Run California rights operations across delete, correct, know, opt out, and limit. - [CPRA Contracts, Contractors, and Service Providers](/artifacts/us/cpra/contracts-contractors-and-service-providers.md): Draft California recipient contracts that support both baseline CPRA compliance and the newer assurance obligations. - [CPRA Deadlines and Compliance Calendar | California Privacy Calendar](/artifacts/us/cpra/deadlines-and-compliance-calendar.md): Use the dates that matter for the current California privacy regime. - [CPRA FAQ | Practical California Privacy Rights Answers](/artifacts/us/cpra/faq.md): Answer the California questions that stall CPRA implementation decisions. - [CPRA Penalties and Fines | California Enforcement Exposure](/artifacts/us/cpra/penalties-and-fines.md): Understand what makes California exposure larger, faster, and harder to defend. - [CPRA Requirements | California Control Requirements](/artifacts/us/cpra/requirements.md): Translate the current California regime into control statements that teams can build and test. - [CPRA Risk Assessment Template | California Risk Assessment Guide](/artifacts/us/cpra/cpra-risk-assessment-template.md): Use a California specific template that matches the current rule structure instead of a generic DPIA form. - [CPRA Risk Assessments and Cybersecurity Audits | California Assurance Guide](/artifacts/us/cpra/risk-assessments-and-cybersecurity-audits.md): Prepare for the California assurance duties that now have real structure, timing, and evidence requirements. - [CPRA vs Colorado Privacy Act | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-colorado-privacy-act.md): Compare the California and Colorado models before reusing a state privacy template across both. - [CPRA vs Virginia VCDPA | State Privacy Comparison](/artifacts/us/cpra/cpra-vs-virginia-vcdpa.md): Compare California and Virginia privacy models before reusing contracts or request flows across both. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/us/cpra/sensitive-personal-information --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54 --- --- title: "CRA FAQ Hub" canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq" source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54" author: "Sorena AI" description: "Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence." published_at: "2026-03-10" updated_at: "2026-03-10" keywords: - "CRA FAQ hub" - "Cyber Resilience Act FAQ" - "CRA Blue Guide" - "CRA CE marking FAQ" - "CRA component due diligence FAQ" - "Cyber Resilience Act" - "CRA FAQ" - "CE marking" - "Blue Guide" - "component due diligence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # CRA FAQ Hub Browse the CRA FAQ hub for Blue Guide market-access concepts, CE marking, and component due diligence. *FAQ Hub* *EU* *Cyber Resilience Act* ## EU Cyber Resilience Act FAQ Browse focused CRA FAQ modules built around the questions that usually slow market access, product launch, conformity work, and component governance. Each sub-FAQ is grounded in official sources and designed for legal, compliance, product, engineering, and security teams. Use this FAQ hub when the general CRA page is too broad and you need a tighter answer set. The sub-FAQs below group high-friction questions into practical modules so teams can move faster on interpretation, evidence design, and release decisions without losing source traceability. ## Browse sub-FAQ modules ### [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md) CRA FAQ on Blue Guide concepts used in Cyber Resilience Act interpretation: placing on the market, making available, putting into service, online sales. - 28 items ### [CRA CE Marking FAQ | Meaning, Placement Rules, Software Labeling, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md) CRA CE marking FAQ covering what the mark means, when it is mandatory, software and website placement rules, packaging fallback, notified body numbers. - 26 items ### [CRA Component Due Diligence FAQ | Third-Party Components, FOSS, SBOM, Vulnerabilities](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md) CRA component due diligence FAQ covering third-party components, FOSS, CE-marked components, SBOM review, risk-based checks, upstream vulnerability reporting. - 21 items ### [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Critical and Important Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md) CRA FAQ on conformity assessment routes covering module A, module B+C, module H, important and critical products, harmonised standards, certification schemes. - 25 items ### [CRA Core Functionality FAQ | Important Products, Critical Products, Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md) CRA FAQ on core functionality covering classification of important and critical products, ancillary functions, integrated components. - 21 items ### [CRA Cybersecurity Risk Assessment FAQ | Article 13, Threat Modelling, Variants, Constraints](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md) CRA FAQ on cybersecurity risk assessment covering Article 13, threat modelling, intended purpose, foreseeable misuse, external dependencies, documentation. - 26 items ### [CRA Declaration of Conformity FAQ | Full vs Simplified, Languages, Updates, Duties](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md) CRA FAQ on the EU declaration of conformity covering full and simplified formats, required contents, languages, updates, single declarations across EU laws. - 19 items ### [CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md) CRA FAQ on economic operators covering manufacturer, authorised representative, importer, distributor, responsible operator rules, checks, traceability. - 26 items ### [CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md) CRA FAQ on the essential cybersecurity requirements covering Annex I Part I and Part II, applicability, evidence, interoperability constraints. - 20 items ### [CRA Hardware and Software Boundaries FAQ | Product Scope, Combined Products, Source Code](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md) CRA FAQ on hardware and software boundaries covering combined products, standalone software, source code, companion apps, remote data processing. - 26 items ### [CRA Harmonised Standards and Common Specifications FAQ | Presumption of Conformity, OJ Publication](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md) CRA FAQ on harmonised standards, common specifications, and certification schemes covering presumption of conformity, Official Journal publication. - 24 items ### [CRA Important and Critical Products FAQ | Annex III, Annex IV, Core Functionality](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md) CRA FAQ on important and critical products covering Annex III and Annex IV classification, core functionality, conformity routes, FOSS rule limits. - 30 items ### [CRA Integrated Components and Dependencies FAQ | Due Diligence, RDPS, Third-Party Components](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md) CRA FAQ on integrated components and dependencies covering due diligence, third-party components, RDPS, cloud dependencies, upstream fixes, FOSS dependencies. - 21 items ### [CRA Interplay With Other EU Laws FAQ | RED, AI Act, GDPR, Data Act, EHDS, Machinery](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md) CRA FAQ on interplay with other EU laws covering exclusions, overlap with RED, AI Act, GDPR, Data Act, EHDS, Machinery, GPSR, NIS2, aviation, marine. - 25 items ### [CRA Known Exploitable Vulnerabilities at Launch FAQ | Placement on the Market, CVEs, Late Discoveries](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md) CRA FAQ on known exploitable vulnerabilities at launch covering the launch-time rule, exploitability, known vulnerabilities, CVEs, compensating controls. - 18 items ### [CRA Legacy Products FAQ | Pre-2027 Products, Reporting, Grandfathering, Substantial Modification](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md) CRA FAQ on legacy products covering pre-11 December 2027 products, Article 14 reporting, continued sale, substantial modification, spare parts, old designs. - 21 items ### [CRA Manufacturer Obligations FAQ | Article 13 Duties, Support Period, Reporting, Documentation](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md) CRA FAQ on manufacturer obligations covering Article 13 duties, risk assessment, support periods, vulnerability handling, reporting, documentation. - 41 items ### [CRA Market Surveillance and Enforcement FAQ | Authorities, Safeguards, Sweeps, Formal Non-Compliance](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md) CRA FAQ on market surveillance and enforcement covering authorities, investigations, safeguard procedures, formal non-compliance, sweeps, joint activities. - 39 items ### [CRA Module A FAQ | Internal Control, Self-Assessment, Eligibility, Documentation](/artifacts/eu/cyber-resilience-act/faq/module-a.md) CRA FAQ on module A covering internal control, eligible products, class I limits, FOSS exception, technical documentation, testing, CE marking. - 28 items ### [CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md) CRA FAQ on module B+C covering EU-type examination, conformity to type, notified-body role, certificate changes, production control, CE marking. - 32 items ### [CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking](/artifacts/eu/cyber-resilience-act/faq/module-h.md) CRA FAQ on module H covering full quality assurance, quality-system approval, notified-body surveillance, scope changes, CE marking, language rules, records. - 31 items ### [CRA Notified Bodies FAQ | Notification, Scope, NANDO, Independence, Competence](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md) CRA FAQ on notified bodies covering notification, competence, independence, NANDO scope, accreditation, cross-border choice, subcontracting. - 35 items ### [CRA Open-Source Software FAQ | FOSS, Commercial Activity, Stewards, Donations, Paid Editions](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md) CRA FAQ on open-source software covering FOSS qualification, commercial activity, donations, paid support, stewards, contributors, repositories. - 39 items ### [CRA Over-the-Air Updates FAQ | OTA, Automatic Updates, Secure Distribution, Offline Paths](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md) CRA FAQ on over-the-air updates covering OTA versus automatic updates, secure distribution, screenless products, gateways, offline update paths. - 25 items ### [CRA Penalties and Fines FAQ | Fine Tiers, Turnover Caps, SME Carve-Outs, Stewards](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md) CRA FAQ on penalties and fines covering Article 64 fine tiers, turnover caps, SME carve-outs, steward exemptions, cumulative fines, criminal sanctions. - 23 items ### [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md) CRA FAQ on product families covering shared risk assessments, family-wide documentation reuse, cybersecurity-relevant variant differences. - 16 items ### [CRA Remote Data Processing Solutions FAQ | RDPS Scope, Cloud Services, SaaS Boundaries, Documentation](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md) CRA FAQ on remote data processing solutions covering Article 3(2) RDPS tests, cloud-service boundaries, websites and portals, third-party SaaS, backend scope. - 21 items ### [CRA Repairs and Spare Parts FAQ | Repairs, Refurbishment, Spare-Part Exemption, Compatibility](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md) CRA FAQ on repairs and spare parts covering substantial modification, Article 2(6) identical spare parts, non-identical replacements. - 18 items ### [CRA Reporting Obligations FAQ | Article 14 Deadlines, CSIRT Filing, User Notices, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md) CRA FAQ on reporting obligations covering Article 14 deadlines, actively exploited vulnerabilities, severe incidents, CSIRT routing, user notifications. - 35 items ### [CRA Scope FAQ | Products with Digital Elements, Connections, Software, Exclusions](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md) CRA FAQ on scope and products with digital elements covering software, firmware, components, direct and indirect connections, offline products, exclusions. - 30 items ### [CRA Secure-by-Default FAQ | Default Configuration, Auto Updates, Tailor-Made Limits](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md) CRA FAQ on secure by default covering Annex I default configuration, automatic security updates, opt-outs, components, inapplicability. - 18 items ### [CRA Security Updates vs Functionality Updates FAQ | Separation, Free Updates, Article 13(10)](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md) CRA FAQ on security updates versus functionality updates covering separation where technically feasible, free security updates, automatic updates. - 24 items ### [CRA Substantial Modification FAQ | Post-Market Changes, New Manufacturer, Legacy Products](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md) CRA FAQ on substantial modification covering Article 3(30), software updates, repairs, new manufacturer status, conformity reassessment. - 27 items ### [CRA Support Period FAQ | Placement on the Market, Unit-Level Timing, Update Availability](/artifacts/eu/cyber-resilience-act/faq/support-period.md) CRA FAQ on support periods covering Article 13(8), placement on the market timing, unit-level support periods, standalone software, update availability. - 71 items ### [CRA Tailor-Made Products FAQ | Business-User Exception, Paid Updates, Evidence](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md) CRA FAQ on tailor-made products covering the narrow business-user carve-out, secure-by-default and paid-update deviations, required evidence. - 17 items ### [CRA Technical Documentation FAQ | Annex VII, Languages, Authority Access, Updates](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md) CRA FAQ on technical documentation covering Annex VII content, timing, languages, versioning, authority access, reused documentation, simplified formats. - 21 items ### [CRA Transition Period FAQ | Key Dates, Legacy Products, Pre-CRA Stock, RED Interplay](/artifacts/eu/cyber-resilience-act/faq/transition-period.md) CRA FAQ on the transition period covering entry into force, phased application dates, legacy products, stock and customs timing, standalone software. - 23 items ### [CRA Update Availability and Archives FAQ | Article 13(9), Archives, Historical Versions](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md) CRA FAQ on update availability and software archives covering Article 13(9), Article 13(10), Article 13(11), retention of issued security updates. - 24 items ### [CRA User Information and Transparency FAQ | Annex II, Support Disclosure, User Notices](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md) CRA FAQ on user information and transparency covering Annex II instructions, support-period disclosure, end-of-support notices, vulnerability notices. - 28 items ### [CRA Vulnerability Handling FAQ | Lifecycle Duties, Components, Disclosure, Fix Sharing](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md) CRA FAQ on vulnerability handling covering Annex I Part II duties, component vulnerabilities, upstream reporting and fix sharing. - 29 items Browse all indexed questions: [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) ## All FAQ items *Page 54 of 54. Showing 12 of 1072 items.* ### [Must manufacturers publicly disclose information about fixed vulnerabilities?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-publicly-disclose-information-about-fixed-vulnerabilities) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes, once a security update has been made available. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (4) ### [Must manufacturers have a coordinated vulnerability disclosure policy and a reporting contact?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-manufacturers-have-a-coordinated-vulnerability-disclosure-policy-and-a-reporting-contact) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(17), Annex I Part II points (5) and (6), Annex II points 1-2 ### [What happens if a vulnerability cannot be fixed adequately?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#what-happens-if-a-vulnerability-cannot-be-fixed-adequately) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The manufacturer must take the corrective measures necessary to bring the product back into conformity, or withdraw or recall it, as appropriate. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(21) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.3.4 ### [Must the manufacturer systematically document vulnerabilities it becomes aware of and update the risk assessment where necessary?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-the-manufacturer-systematically-document-vulnerabilities-it-becomes-aware-of-and-update-the-risk-assessment-where-necessary) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7), Annex I Part II point (3) - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - section 4.1.8 ### [Is CRA vulnerability handling broader than the mandatory reporting duties in Article 14?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-cra-vulnerability-handling-broader-than-the-mandatory-reporting-duties-in-article-14) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(7)-(8), Article 14(1), Article 14(3), Annex I Part II - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 4.3.1 and 5.1 ### [Can a manufacturer voluntarily report vulnerabilities even when Article 14 mandatory reporting does not apply?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#can-a-manufacturer-voluntarily-report-vulnerabilities-even-when-article-14-mandatory-reporting-does-not-apply) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6), Article 15 - [European Commission CRA FAQs (January 2026)](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - sections 5.1 and 5.4 ### [Do the manufacturer's vulnerability-handling procedures need to cover both internal findings and external reports?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#do-the-manufacturers-vulnerability-handling-procedures-need-to-cover-both-internal-findings-and-external-reports) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Yes. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(8), fourth subparagraph - [ISO/IEC 30111](https://www.iso.org/standard/69725.html?ref=sorena.io) - sections 7.1.3 and 7.1.4 ### [Does Article 13(6) require upstream reporting for every security issue involving an integrated component?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-article-136-require-upstream-reporting-for-every-security-issue-involving-an-integrated-component) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 201-202 ### [Is upstream reporting or fix-sharing still required if the component has no maintainer or the manufacturer uses its own independent fork?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#is-upstream-reporting-or-fix-sharing-still-required-if-the-component-has-no-maintainer-or-the-manufacturer-uses-its-own-independent-fork) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* Not in those cases. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - point 203 and footnote 24 ### [Must a security fix shared upstream be machine-readable, and does the CRA require the maintainer to accept it?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#must-a-security-fix-shared-upstream-be-machine-readable-and-does-the-cra-require-the-maintainer-to-accept-it) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* The fix should be shared in a machine-readable form where appropriate, but the CRA does not require maintainer acceptance. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 13(6) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 204-207 ### [Does the CRA require a bug bounty programme, and can vulnerability reporting be channelled anonymously via a CSIRT?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#does-the-cra-require-a-bug-bounty-programme-and-can-vulnerability-reporting-be-channelled-anonymously-via-a-csirt) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* A bug bounty is not mandatory, but the CRA framework does allow coordinated and even anonymous reporting paths. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Annex I Part II point (5), recital 76 ### [Are the public-disclosure rule for fixed vulnerabilities and the user-notice rule for actively exploited vulnerabilities or severe incidents the same obligation?](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md#are-the-public-disclosure-rule-for-fixed-vulnerabilities-and-the-user-notice-rule-for-actively-exploited-vulnerabilities-or-severe-incidents-the-same-obligation) *Module: [CRA Vulnerability Handling](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md)* No. Sources for this answer: - [Cyber Resilience Act](https://data.europa.eu/eli/reg/2024/2847/oj?ref=sorena.io) - Article 14(8), Annex I Part II point (4) - [Draft Commission guidance on the CRA (March 2026 draft)](https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en?ref=sorena.io) - points 198-200 ## FAQ Pagination - Canonical index (page 1): [/artifacts/eu/cyber-resilience-act/faq/items](/artifacts/eu/cyber-resilience-act/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 54 of 54 Pages: [1](/artifacts/eu/cyber-resilience-act/faq/items.md) | [2](/artifacts/eu/cyber-resilience-act/faq/items/page/2.md) | [3](/artifacts/eu/cyber-resilience-act/faq/items/page/3.md) | [4](/artifacts/eu/cyber-resilience-act/faq/items/page/4.md) | [5](/artifacts/eu/cyber-resilience-act/faq/items/page/5.md) | [6](/artifacts/eu/cyber-resilience-act/faq/items/page/6.md) | [7](/artifacts/eu/cyber-resilience-act/faq/items/page/7.md) | [8](/artifacts/eu/cyber-resilience-act/faq/items/page/8.md) | [9](/artifacts/eu/cyber-resilience-act/faq/items/page/9.md) | [10](/artifacts/eu/cyber-resilience-act/faq/items/page/10.md) | [11](/artifacts/eu/cyber-resilience-act/faq/items/page/11.md) | [12](/artifacts/eu/cyber-resilience-act/faq/items/page/12.md) | [13](/artifacts/eu/cyber-resilience-act/faq/items/page/13.md) | [14](/artifacts/eu/cyber-resilience-act/faq/items/page/14.md) | [15](/artifacts/eu/cyber-resilience-act/faq/items/page/15.md) | [16](/artifacts/eu/cyber-resilience-act/faq/items/page/16.md) | [17](/artifacts/eu/cyber-resilience-act/faq/items/page/17.md) | [18](/artifacts/eu/cyber-resilience-act/faq/items/page/18.md) | [19](/artifacts/eu/cyber-resilience-act/faq/items/page/19.md) | [20](/artifacts/eu/cyber-resilience-act/faq/items/page/20.md) | [21](/artifacts/eu/cyber-resilience-act/faq/items/page/21.md) | [22](/artifacts/eu/cyber-resilience-act/faq/items/page/22.md) | [23](/artifacts/eu/cyber-resilience-act/faq/items/page/23.md) | [24](/artifacts/eu/cyber-resilience-act/faq/items/page/24.md) | [25](/artifacts/eu/cyber-resilience-act/faq/items/page/25.md) | [26](/artifacts/eu/cyber-resilience-act/faq/items/page/26.md) | [27](/artifacts/eu/cyber-resilience-act/faq/items/page/27.md) | [28](/artifacts/eu/cyber-resilience-act/faq/items/page/28.md) | [29](/artifacts/eu/cyber-resilience-act/faq/items/page/29.md) | [30](/artifacts/eu/cyber-resilience-act/faq/items/page/30.md) | [31](/artifacts/eu/cyber-resilience-act/faq/items/page/31.md) | [32](/artifacts/eu/cyber-resilience-act/faq/items/page/32.md) | [33](/artifacts/eu/cyber-resilience-act/faq/items/page/33.md) | [34](/artifacts/eu/cyber-resilience-act/faq/items/page/34.md) | [35](/artifacts/eu/cyber-resilience-act/faq/items/page/35.md) | [36](/artifacts/eu/cyber-resilience-act/faq/items/page/36.md) | [37](/artifacts/eu/cyber-resilience-act/faq/items/page/37.md) | [38](/artifacts/eu/cyber-resilience-act/faq/items/page/38.md) | [39](/artifacts/eu/cyber-resilience-act/faq/items/page/39.md) | [40](/artifacts/eu/cyber-resilience-act/faq/items/page/40.md) | [41](/artifacts/eu/cyber-resilience-act/faq/items/page/41.md) | [42](/artifacts/eu/cyber-resilience-act/faq/items/page/42.md) | [43](/artifacts/eu/cyber-resilience-act/faq/items/page/43.md) | [44](/artifacts/eu/cyber-resilience-act/faq/items/page/44.md) | [45](/artifacts/eu/cyber-resilience-act/faq/items/page/45.md) | [46](/artifacts/eu/cyber-resilience-act/faq/items/page/46.md) | [47](/artifacts/eu/cyber-resilience-act/faq/items/page/47.md) | [48](/artifacts/eu/cyber-resilience-act/faq/items/page/48.md) | [49](/artifacts/eu/cyber-resilience-act/faq/items/page/49.md) | [50](/artifacts/eu/cyber-resilience-act/faq/items/page/50.md) | [51](/artifacts/eu/cyber-resilience-act/faq/items/page/51.md) | [52](/artifacts/eu/cyber-resilience-act/faq/items/page/52.md) | [53](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) | [54](/artifacts/eu/cyber-resilience-act/faq/items/page/54.md) [Previous page](/artifacts/eu/cyber-resilience-act/faq/items/page/53.md) *Recommended next step* *Placement: after the FAQ section* ## Use the CRA FAQ hub as a cited research workflow Research Copilot can turn recurring CRA interpretation questions into a reusable workflow tied to your products, evidence, and owners. - [Open Research Copilot](/solutions/research-copilot.md): Answer CRA scope, conformity, CE marking, and component questions with cited outputs. - [Talk through your CRA rollout](/contact.md): Review product decisions, evidence gaps, and launch blockers with the Sorena team. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/faq/items/page/54